ガイドライン: リスク リスト
トピック
「The readiness is all.」 - Hamlet V:ii:215
プロジェクトには、人生と同様に、不確かな面があります。私達はリスクを予想して、可能であればそれを緩和しようとします。また、十分にリスクを緩和できない場合、なんらかの対処策を取ります。
リスクは反復計画の基となります。リスクを局限するかまたは軽減するために、種々のリスクに対する計画を反復的に立てます。リスク軽減戦略の有効性を評価するために、リスク リストを定期的にレビューします。その結果、プロジェクト計画と以降の反復計画に改訂が及びます。
リスクを管理する鍵は、リスクが顕在化する (問題や障害が発生する) 以前に、対処策を決定することです。たとえば、大陸を横断する飛行機の進行方向をほんの数度変えただけで、飛行機が到着する場所は大きく違ってきます。それと同様に、早い段階からリスクを管理すればするほど、事後になって対処するよりもコストが安く苦痛が少なくなります。
主な戦略には下記の 3 つがあります。参考資料 [BOE91]
- リスクの回避: リスクの影響を受けないように、プロジェクトを編成し直します。
- リスクの転移: 誰かほかの人または何かほかもの (顧客、ベンダー、銀行、別の要素など) にリスクを負わせるように、プロジェクトを編成し直します。リスク回避の 1 つの特別な形態です。
- リスクの容認: リスクを不測の事態として受け入れることに します。リスクの兆候を監視して、リスクが発生したときに非常時計画を実施します。
直接的なリスクと間接的なリスクとを区別することが重要です。簡単に言うと、直接的なリスクとはある程度自分達で抑制できるものであり、間接的なリスクとは自分達では抑制できないものです。
間接的なリスクを無視すべきではありません。しかし、実際的には、間接的なリスクは重要ではありません。間接的なリスクを変えることはできないのですから、それについて心配しても得るものはほとんどありません。もしかしたら世界は明日終焉するかもしれません。しかし、終焉しないかもしれません。世界が終焉しなければ、手元の仕事を進めた方がよいでしょう。
ときには、間接的なリスクのように見えるものが、実際は直接的なリスクであることがあります。たとえば、外部の供給業者からコンポーネントの供給を受けているとします。これは間接的なリスクのように思えます。しかし、それらのコンポーネントに対する非常時計画を用意しておくことにより、リスクを制御できます。供給業者を変えることも可能ですし、自社でそのコンポーネントを製作することも可能です。多くの場合、思っている以上に管理手段があるものです。
間接的なリスクに関しては、ある程度リスクを抑制する方法を検討してもよいですし、単に実際に発生したリスクを記録するだけで先に進むのもよいでしょう。自分達で変えられないことを悔やんでも始まりません。
組織
- プロジェクトは関係者 (トップ マネジメント、テスト担当者、品質保証担当者、その他の関係者) の十分な支持を得ていますか。
- このプロジェクトは組織としてこれまでに経験する最大のものですか。
- ソフトウェア エンジニアリングに関するプロセスがしっかり定義されていますか。要求の把握と管理については、どうですか。
資金
- プロジェクトを完了させるのに十分な資金が用意されていますか。
- トレーニングと指導にも資金が配分されていますか。
- 予算が固定されていて、予算内でプロジェクトが完成しないならば、プロジェクトが取り消されることになりますか。
- コストの見積もりは正確ですか。
人
- 十分な人材が利用可能ですか。
- 要員は適切なスキルと経験を持っていますか。
- メンバーは以前に一緒に仕事をしたことがありますか。
- メンバーはプロジェクトの成功を信じていますか。
- ユーザーの代表にレビューに参加してもらえますか。
- 各分野の専門家に支援してもらえますか。
時間
- スケジュールは現実的ですか。
- スケジュールを守るために、機能の範囲を調整できますか。
- 納期はどのくらい厳しいですか。
- 「適正に処理」している時間がありますか。
- 競争相手が先に市場に進出したらどうなりますか。
- プロジェクトの資金が不足してきたらどうなりますか (これを別の面から見ると、「適切な資金供給はどのようにして保証されますか」ということです)。
- システムの予想値は予想コストよりも高いですか (物価変動と資本コストも計算に入れてください)。
- 主要な供給業者と契約できなかったらどうなりますか。
- 成功度合いを測定できますか。
- 成功度合いを測定する方法について合意されていますか。
- 要求はかなり安定しており、よく理解されていますか。
- プロジェクトの範囲は固まっていますか、それとも拡大し続けていますか。
- プロジェクト開発時間が不足し、柔軟にやりくりできないことはありませんか。
- 技術は実証されていますか。
- 再利用の目的は合理的ですか。
- 成果物を再利用するのは、一度使用した後にすべきです。
- 何回かのリリースを経ないと、コンポーネントは変更せずに再利用できるほど安定しない可能性があります。
- 要求におけるトランザクション量は妥当ですか。
- トランザクション率の見積もりは信用できますか。その見積もりは楽観的すぎませんか。
- データ量は合理的ですか。現在利用可能なメインフレーム上にデータを保持できますか。または、要求を実現するためにワークステーションか部門システムが必要と考えられる場合、データを合理的にそこへ移せますか。
- プロジェクト チームが不慣れな問題に取り組まなければならないような、異常または挑戦的な技術的要求がありますか。
- 新規または未経験の製品、サービス、技術、あるいは新規か実績のないハードウェア、ソフトウェア、技法に成功がかかっていませんか。
- 社外も含めて、ほかのシステムとのインターフェイスに関して、外部に依存することがありますか。必要なインターフェイスは既に存在しますか、それともこれから作成する必要がありますか。
- 可用性とセキュリティ上の毅然とした要求がありますか (たとえば、「システムは決して故障してはならない」というようなこと)。
- システムのユーザーは開発中のシステムのタイプに不慣れではありませんか。
- アプリケーションの規模、複雑性または技術の斬新性によって、リスクが高くなることはありませんか。
- 多言語サポートの必要はありますか。
- このシステムを設計・実装・稼働させることは可能ですか。システムの中には、適切に作業するためには巨大または複雑すぎるものがあります。
- プロジェクトはほかの (並行して行れている) 開発プロジェクトに依存しますか。
- 出来合いの製品または外部で開発されたコンポーネントに成功が依存しますか。
- 開発ツール (設計ツールやコンパイラなど) や実装技術 (オペレーティング システム、データベース、プロセス間通信メカニズムなど) の統合に成功するかどうかが、プロジェクトの決め手になりますか。それらの技術なしでプロジェクトを完成させるバックアップ計画を用意していますか。
経験によると、リスクの 85% が直接的または間接的にスケジュール、ひいてはコストに影響します。約 5% はコストだけに影響します。残りはコストまたはスケジュールには直接影響しませんが、品質などに影響します。
納期が絶対である場合、徐々に分納を重ねていくようにします。スケジュールを守ろうとして、全体を一度に納入することは避けます。
プロジェクトの中には、本当に納期を「死守」しなければならないものがあります。たとえば、投票日の夜に開票状況を「実況」分析するソフトウェアは、選挙の 1 週間後に完成しても何の価値もありません。自社が製品を開発中に、競合他社がもっとよい製品を先に発売することがあり得ます。突然、競争に敗退し、打つ手がなくなってしまうことがあります。しかし、一般的に言って、納期がそのように厳しいプロジェクトはきわめて少ないです。スケジュールの遅延はほとんどの場合コストに影響します。
一般に、確約スケジュールは最善の予測に多少の合理的な予備時間を加えたものとします。
確約スケジュール = 最善の見積もりスケジュール + 予備時間
一部には、期待するスケジュールを非常時の戦略に合わせるように勧める意見もあります。つまり、非常時計画に基づいて、スケジュールを設定しようというのです。しかし、これは悲観的にすぎます。なぜならば、すべてのリスクが実際に現実化するとは限らないからです。
スケジュールとコストの見積もりツールの中には、リスクが折り込まれているものがあります。たとえば、COCOMO (Constructive Cost Model) モデルでは、下記のようなコスト要因があります。
- 複雑性 (Cplx)
- リアルタイム制約 (Time)
- ストレージ制約 (Stor)
- 経験 (Vexp)
- 優れたツールの可用性 (Tool)
- スケジュール圧力 (Sced)
これらは、実際にはリスク要因でもあります。
さらに精巧なリスク管理技法にはモンテカルロ シミュレーションを含むものがあります。その場合、シミュレーション ツールを使用して膨大な数の「シナリオ」を実行し、全般的なリスクと非常時対策を計算します。参考資料 [KAR96]
|