現実のシステム開発は変化の連続
「書いてあることはやらなければならない、書いていないことはやってはいけない。」
要件定義の大原則ですね。要件定義は開発するシステムの設計図になるわけですから当然のことです。
しかし、実際のシステム開発では、開始時点で未確定要素を多く残したままスタートすることが多く、加えて、書いてあるものさえも、発注側、受注側、同床異夢であることが一般的です。「仮決め」という要件定義さえ存在します。仮決めでシステム開発をスタートさせるのですから、さて、これは先の航海が思いやられる…といったところでしょうか。
システム開発はこのように、常に準備万端、決めることを全て決めて始める、ということが出来ない仕事ですから、その程度に応じたリスク評価とリスク対策をしっかり行い、リスク解消を図っていかなくてはなりません。さらに、システム開発の状況は開発が進むに従って変化しますので、新しいリスクも発生します。
例えば、テストで期待されたパフォーマンスが出ない場合、その原因によっては稼働環境の変更、使い物になるシステムにするために設計の変更、はたまた一部機能の実施断念等々、様々な検討が必要になります。関係者の衆知を集め、お金をかけるか、時間をかけるか、なにかをあきらめるか検討し、場合によってはステークホルダーとの政治的な調整が必要になることもあります。つまり、リスクとしてノミネートされたことがクロスファンクショナルに適切に評価されないと正しい結論が導き出せないのであります。
従って、プロジェクトの最初からこういった開発プロセスの節目毎に、ステークホルダーも参加しリスクを評価、対策につなげるプロジェクトレビューを行う仕組みを組み込みませんと円滑な進捗は期待できません。
リスクの程度は、開発の進捗に従って変化します。小さくなることも、大きくなることもあります。プロジェクトリーダーは可能な限りリスクを洗い出し、きちんと管理するだけでなく、一つ一つのリスクを数値化し、プロジェクト全体のリスクについて積算し、その絶対値と共に変化を管理しなくてはいけません。
リスクを評価し、リスクの程度を数値化して管理するための「リスク管理チェックシート」については、「実務で役立つプロジェクトレビュー」の第3章「プロジェクトレビュー制度の実際」に掲載されています。ぜひお読みください。
プロジェクトの成功はそのシステムを利用しようとしている人にとってもっとも大切なものですから、プロジェクトリーダーは遠慮なくプロジェクトレビューで全てのステークホルダーにリスクを提示し、共同で評価を行い、対策を練り、リスクを軽減していく努力をしなくてはならないのです。
