作業:
|
目的
|
|
ステップ | |
入力とする成果物:
|
結果となる成果物: |
役割: プロジェクト管理者 | |
ツール メンター: |
ワークフローの詳細: |
目的 | プロジェクトで「問題が起こりそうな箇所」の目録を作成すること |
プロジェクト チームを集めます (この時点では少人数にすべきです。プロジェクト チームの人数が 5 ~ 7 人以上であれば、リスク評価プロセスの参加者は作業リーダーに限定します)。
リスクを割り出す場合、「問題が起こりそうな箇所」を検討します。広範囲にわたって考慮すれば、どこでも問題が起こる可能性はあります。ここでは、プロジェクトに悲観的な考え方を持ち込むのではなく、成功を阻む潜在的な障壁を割り出し、それを削減または除去することが目的です。詳しくは、「ガイドライン: リスク リスト」を参照してください。
つまり、正しい機能、必要な品質の製品を、スケジュールどおりに予算内で納品できる可能性を低くする可能性のあるイベントを探します。
ブレーンストーミングを行い、各メンバーにプロジェクトのリスクを割り出すよう依頼します。状況を明確にするための質問はかまいませんが、リスクの評価やリスクへのコメントはすべきではありません。すべてのリスクが割り出されるまで繰り返します。
このプロセスでは関係者全員を含めて、形式や重複にはあまりこだわらないようにします。リストは後から整理できます。同種の人のグループを使用します (顧客、ユーザー、技術担当者など)。これによってリスクの収集が容易になります。(専門や階層において) 異種の人が混在する中よりは、対等な人々が集まっている中でのほうが自由な発想が得られます。
参加者に対しては、リスクを指摘しても、リスクへの対処を自ら志願することにはならないことを明確にしておきます。リスクの指摘により、リスクへの対処の責任が生じるのであれば、誰もリスクの割り出しを行わなくなります (指摘されるリスクは取るに足らないものばかりになるでしょう)。
呼び水となるように、Capers Jones の『ソフトウェア リスクの評価と管理』 [JON94] やカーネギーメロン大学ソフトウェア工学研究所がまとめた『分類法ベースのリスク抽出』 [CAR93] などの本に書かれている、一般的なリスクのリストから開始します。このリスク リストを回覧します。既に指摘されているリスクがわかると、さらに何を割り出せばよいのかを考えるヒントになります。
以上で説明されている方法で入力を求めることができます。しかし、一般的には、既存のリストの例に基づいてチーム メンバーが新しいリスクを割り出し、定期的なプロジェクト ステータス評価時にリスクを取得します。「作業: 反復の評価」を参照してください。
目的 | (リスク リストのサイズを削減するために) 類似のリスクを組み合わせること プロジェクトに与える影響という観点でのリスクのランク付けをすること |
これ以上リスクが見つからない場合は、リスク リスト全体に自然なグループ分け方法 (同一リスクの発生) がないかどうかを確認し、重複をなくすために可能な限りリスクを組み合わせます。割り出されたリスクが、さらに重要なリスクの兆候である場合があります。この場合には、関連したリスクをそのリスクの下にグループ分けします。
定量的なリスク管理技術では、プロジェクトに対するリスクの全体的な露出度に従って、リスクに優先順位を付けることが推奨されます。各リスクの露出度を決定するには、グループは以下の情報を評価します。
リスクの影響 | リスク発生時にスケジュール、作業、費用が計画から外れる程度 |
発生の可能性 | リスクが実際に起こりそうな可能性 (通常は % で表現) |
リスクの露出度 | 影響に発生可能性をかけ合わせて計算 |
グループとしては、各リスクの露出度は合意に基づいて決定します。意見にかなりの差がある場合には、全員のリスクの解釈が同じかどうかを議論します。この情報は、通常、リスク リストの表の列にあります。
最も影響が大きいリスクを心配するのは当然ですが、あまりにも発生しにくいリスクであれば、よく見逃してしまう中位のリスクよりも重要性は低くなります。リスクの大きさと発生の可能性の両方を考えることにより、プロジェクト管理者は製品提供に最も重大な影響がある分野のリスク管理に労力を集中できます。
それぞれのリスクについて露出度が決定されると、露出度の減少順にリスクをソートし、リスク リストの「トップ 10」を作成できます。
リスク発生の可能性とコストの見積もりにはそれ自体コストがかかります。また、リスク性があるため、通常、有効なのは上位 10 ~ 20 のリスクの影響の測定のみです。小規模のプロジェクトは検討するリスクも少なくてよいのですが、大規模プロジェクトでは「リスク対象」も大きくなり、関連するリスクの数も結果的に多くなります。
リスクの露出度の減少順にランク付けする以外に、プロジェクトへの影響度 (リスクの大きさ) に基づいてリスクをカテゴリにグループ化またはクラス分けするのも有用です。ほとんどの場合、次の 5 つのカテゴリで十分です。
リスクを文書化し、プロジェクトのチーム メンバーの間で回覧します。
目的 | プロジェクトを再編成してリスクを除去すること |
いつも可能とはかぎりませんが、リスクの回避が可能なことがあります。リスクはシステム範囲の設定がまずい場合に起きるケースが多いため、(必須ではない要求を除去することにより) システムの範囲を減らすことで、除去された要求と一緒にリスク リスト項目群も除去されます。これらのリスクで軽視してはいけないのは、作業を行うためのリソースの不足 (時間も含む) から生じるリスクです。
これ以外の場合には、特定の機能構築のリスクを減少させる技術を取得できます。これは一種のリスク回避で、あるリスクのセット (テクノロジーの構築) を、別のセットのリスク (自分の力が及ばないものへの依存) と交換するものです。
最終的にリスクはほかの組織へ移転できます。
目的 | リスクを緩和する計画の開発、つまりリスクの影響を減少させること |
直接的なリスク、つまりプロジェクトがある程度管理しているリスクについては、リスクの可能性を減少させる操作またはプロジェクトへの影響を減少させる操作 (緩和戦略) を割り出します。リスク自体が情報不足から派生することが多いので、緩和戦略自体も不確実性を減少させるトピックの調査を行うものになります。
リスクには、何らかのアクションを実行してリスクを実体化できるものと、除去できるものとがあります。反復開発のプロセスでは、このようなアクションは初期の反復に割り当てて、できるだけ早くリスクを緩和します。リスクにはなるべく早く対処します。「X が動作しないかもしれない」というリスクなら、できるだけ早く X を試みる計画を立てます。
例:
これらのアクションの結果は、特定のリスクが発生する確率をゼロに近くする結果をもたらすべきです。リスクが確認できたら、このリスクには緊急時対策を対応付けます (「緊急時対策の割り出し」を参照)。
目的 | 代替計画を作成すること |
リスクを積極的に軽減する計画があるかどうかに関係なく、リスクが実際に実体化したとき、またはリスクが実体化するような場合に、どのようなアクションを取るかを決定する必要があります。リスクの実体化とはリスクが問題になることで、保険業界の特殊用語で言えば、「事故発生」がこれにあたります。これは通常「プラン B」または緊急時対策と呼ばれます。リスク回避とリスク移転が失敗し、リスク軽減もうまく行かなかった場合には、緊急時対策が必要で、リスクには真正面から取り組む必要があります。これは間接的なリスクの場合によくあります。間接的なリスクとは、プロジェクトを管理できなかったり、緩和戦略に費用がかかり過ぎて実装できないリスクのことを言います。
緊急時対策では以下を検討します。
リスク |
インジケータ |
アクション |
リスクは何か。 | リスクが現実になったことは、どのようにしてわかるか。「事故発生」はどうやって認識するか。 | 「事故発生」の対処は何をすべきか (どうやれば「出血」を止められるか)。 |
リスクの中には、傾向や境界を見ながらプロジェクト メトリクスを使って監視できるものがあります。例を次にあげます。
リスクの中には、プロジェクト要求とテスト結果に基づいて監視できるものがあります。例を次にあげます。
リスクには、特定のイベントと関連しているものがあります。例を次にあげます:
ほかに多数の「よりソフトな」インジケータがありますが、どれも完全に問題を診断するものではありません。たとえば、士気が下がるというリスクが常にあります (実際に、プロジェクトのある時点ではほとんど予測可能です)。不平不満、「深刻な事態を茶化したユーモア」、期限遅れ、品質不良などのインジケータも多数あります。これらの「基準」のどれもが確かなインジケータではありません。特定の納品可能物の無用性について冗談を言うことは緊張をほぐす健康的な方法ですが、これが続けば、失敗が近づきつつあるのをチームが感じ取っている兆候であることがあります。
判断を下すことなくすべてのインジケータに耳を傾けます。「悪いニュース」を運んでくる人を、態度が悪い人と決めつけるのは簡単です。これには皮肉さを越えて一片の真実以上のものがあります。しばしば、「悪いニュースを運んでくる人」は「プロジェクトの良心」の役目を果たしています。ほとんどの人がプロジェクトの成功を望んでいるため、プロジェクトが違う方向に流されていくときには不満が募ります。
単純なケースでは、緊急時対策には代替解決法が列挙されます。通常この影響としては、現在の解決法を廃棄して新しい解決法を実装するのに費用がかかり、遅延をまねくことがあります。
その他の「よりソフトな」リスクの場合、事故が起きた場合に取るアクションは 1 つではなく、複数であることが多くなります。たとえば、士気が低下したときは、その状態を認識し、グループとして集まり、プロジェクト内に広まる態度について議論するのが最良です。心配事に耳を傾け、問題点を明確にし、鬱憤を晴らすのが一般的です。鬱憤を晴らすことが一段落したら、心配事の原因の対策に進みます。議論を絞り込むのにリスク リストを使います。リスクの優先順位を付け直し、最大のリスクに系統だって対処するために反復計画を作り直して、心配事を具体的なアクション計画に変換します。積極的なアクションは、積極的 (だが中身のない) な言葉よりも強い効果があります。
その時点のムードとは無関係に、事故発生にはプラスの作用があります。すなわち、アクションを引き出しますリスクを無視し、リスクを先延ばしにするのはとても簡単で、平静さを装うことで納得するようになります。事故が発生した場合にはアクションが必要です。リスクはもはやリスクではなく、発生についても疑う余地はありません。
しかし、事故発生はリスクを避けたり軽減したりするのに失敗したことでもあります。これを契機にリスク リストの再点検をして、プロジェクト チームにシステム的な盲点がないかを追求します。率直な自己評価は難しいですが、以後の問題発生を防止できることになります。
目的 | プロジェクトを通じてリスク リストの更新を保証すること |
リスク評価は、プロジェクトの中で決まった待ち時間でのみ発生するのではなく、実際には連続的なプロセスになります。最低限、以下のことを行います。
目的 | プロジェクトを通じてリスク リストの更新を保証すること |
反復の最後で、リスク リストに基づき反復の目標について再度検討します。具体的には、次のようになります。
方向づけフェーズと推敲フェーズ中にリスク リストが長くなりすぎているのに気づいても、あまり心配しないでください。プロジェクト メンバーが作業するにつれて、大したことはないと考えていたものに実際はリスクが含まれていることに気づきます。統合作業を始めると、隠れていた困難さを見つけることもあります。ただし、プロジェクトが推敲フェーズの終わりに達して作成フェーズに入っていくと、リスクは着実に減少していきます。減少しない場合は、リスクを適切に処理していないか、システムがあまりにも複雑すぎるか、系統的で予想可能な形にシステムを構築できない可能性があります。詳しくは、「ガイドライン: リスク リスト」を参照してください。
Rational Unified Process
|