業務の要件定義を行いたい

チームの課題を可視化、管理して運営に役立てたい

プロジェクトでは予定外の課題が次々に発生します。これらの課題を漏れなく適切に解決するために実施するツールが課題管理表です。 なお、「課題」と「問題」「タスク」はそれぞれ意味が異なります。 「問題」は顕在化した都合の悪い事象そのもので抽象的ですが、「課題」は問題を解決するためのより具体化されたものです。 さらに、課題を解決するための個別の実施項目を「タスク」といいます。顕在化していない問題は「リスク」として課題管理とは別に管理します。継続して使うためにも以下を意識してください。 １．漏れなく登録する　２．優先順位をつける　３．タスク化する　４．日々更新する ※ブラウザでのExcelファイルのプレビューは仕様上1シートのみ表示となります。ダウンロードして確認ください。

QCDSのそれぞれの関係性

QCDSは互いに影響し合う関係にあるため、調整を行う際は、関係性を考慮しながらトレードオフをし調整を行っていきます。 影響範囲と、その調整方法をいくつかの例を用いてお伝えします。 例 　とある企業の情報システム部門で、社内で使用する業務システムの開発と運用を行っています。 　いくつかの部門向けに新たな業務システムの開発を行っていたところ、以下ケース①②のような状況があり、調整を行いました。 　ケース① 　　要望：経営層から業務システムの利用範囲を従来のいくつかの部門から、社内の全ての部門に変更して欲しいという要請がありました。 　　理由：社内の全部門で利用することで、部門間の連携がスムーズになり大きく生産性が上がるためです。 　　対応：全部門で使うためには再度機能の見直し等が必要となるため、まずは全部門共通の最低限の機能のみで利用を開始し 　　　　　後々機能をアップデートしていくことを提案し、その内容で進めることになりました。 　　このケースは対象の部門、つまり範囲(S)に関する要請に対して調整を行った例です。 　　どうにか要請に応えるために、予定の機能=品質(Q)を調整し、要請に応えることが出来ました。 　　コスト(C)の追加、納期(D)の延長で対応することもできますが、ここではコストと納期を守ることを優先しています。 　ケース② 　　要望：開発を進めていた業務システムについて、当初予定の機能だけでなく、追加の機能も入れて欲しいという要望がありました。 　　対応：この要望に応えるためには、開発人員の追加と利用開始日の後ろ倒しが必要ということを説明した結果、 　　　　　当初予定どおりの機能で進めることになりました。 　　このケースは品質(Q)に関する要請に対して、コスト(C)の増加と納期(D)の延長で実現することが出来る状態でしたが、 　　コストと納期の優先度が高く、当初の予定のとおりに進めることになったという例です。 　　今回は分かりやすく追加の要請というケースという例ですが、それ以外の理由でもQCDSのいずれかに変更が発生する場合は、必ず他の項目にも影響が出ます。 　どの項目を調整すれば変更に対応できるのか、QCDSのどの項目の優先度が高いのかを考えながら、トレードフしていくことが調整の重要なポイントです。

体制図の作成法

業務一覧やWBSを基に、体制全体の体制図や、担当ごとの役割内容を明確にした役割表を整備していきます。 体制図や役割表はチーム間の相互扶助の関係性を築くための基礎情報となり、チーム内の誰が何を担当しているかを把握しやすくする事を目的として作成していきます。 ・役割表 　チーム内で誰がどんな役割を担っているか、という全体の体制を明らかにして共有します。 　チーム内での担当や責任範囲がどのように設計されているかを把握することで、チームメンバーが見通しよく動けるとともに、 　何かあった際に誰が担当すべきかを見落とすリスクを減らすことができます。 　そしてこれは、互いが協力しあえる環境づくりにおいて大切です。 　また、体制づくりにおいては、業務の冗長化を行うことが有用です。 　具体的には、一つ一つの業務に対して「メイン担当とサブ担当」を設け、その業務に対して最低限２人が知っている状態をつくる、ということです。 　このことで、何かあった際にもサブ担当がフォローすることができ、また、一人で閉じた世界にならず互いに知恵を出し合うことで、業務をより良くすることにもつながります。 　役割表を作成するときは、業務一覧やWBSを基にして、担当や役割を割り振ります。 ・体制図 　体制図は、チーム間の相互扶助の関係性を築くための基礎情報となります。 　つまりはチーム内の誰が何を担当しているかを把握しやすくすることが目的です。 　また役割表に「メイン担当」「サブ担当」の表記を設けることにより、休暇取得時に誰がバックアップするのかが予め明確になり、 　「メイン担当」しかいないことが分かれば、リスク回避のためサブ担当を育成する必要性が明らかとなり、育成期間中の協力が得やすくなります。 最後に、作成した体制図と役割表は必ずチームメンバー全員に共有しましょう。 これによって少なくとも隣のメンバーが何の業務をしているか分からない、ということは無くなります。 互いの仕事の状態を見える化することは協力体制をつくる上で大切なことです。 体制図と役割表は管理者が管理するものではなく、チームメンバー全員で共有するものであると認識しておくと良いでしょう。 またこれらをメンバーに共有する際、体制の意図や役割配置の理由、背景等も併せて伝えることで、 各々の役割の納得感が上がることでチームメンバーそれぞれのモチベーション向上や、 意図や背景を理解していることによってより適切な相互協力に繋がります。 意図、背景の共有、これらを必ずセットで行った上で、体制図、役割表はメンバーがいつでも確認できるようにしておきましょう。

緊急連絡体制の強化

緊急連絡体制、エスカレーションフローの確立は、障害・インシデント・情報セキュリティ事案・社員保護の観点から重要です。作成時は、実際に機能するか、テストも忘れずに行いましょう。 そのあとは、定期的に以下4点を見直していくことで緊急連絡体制の強化ができます。 　1、報告対象の更新 　2、連絡フローの更新 　3、関係者とすり合わせ 　4、チーム内の展開 トラブルや事故は、頻繁には発生しませんが、いざというときにすぐに動けるようにしておくことが望ましいです。 そのためには、定期的にシミュレーションを行っておくことを推奨します。 トラブルや事故が万が一発生した場合、対象者は動揺してしまい、正常な判断が出来なくなる可能性があります。連絡を受ける上司も、突然の動揺した相手から、何が起きているのかをすぐに把握することは難しいです。 どんな事象が報告する対象であるか、初動のアクションは何をすればよいか、誰にどんなことを連絡をすればよいか、何分以内に行うのか。連絡を受ける側は、相手から何を確認すればよいか、を押さえておきましょう。 シミュレーションを行うことで、手順の確認だけではなく、実際に対処方法で事象が復旧するかどうかも確認することが出来ます。 一つの事例として、ある拠点でNW障害が発生しました。緊急対応フローに沿って、迂回先へ切替を行ったところ、迂回先のNW機器の電源が入っておらず、NWが全断になるというトラブルが発生しました。このようなことも、事前にシミュレーションをしていれば迂回先のNW機器に電源が入っていないことに気づけています。