第８回　大規模プロジェクトの体験を通して（その３：リスク管理について）

リスク管理がプロジェクト・マネジメントの重要な項目にクローズアップされ始めたのはここ１０年位のことですが、それ以前も「アローワンス」とか「誤差の範囲」という言葉で、密かにリスク対策を見込んでプロジェクトを計画していました。１９７０年代は、経験と直感で開発見積り規模に対して、１０％位は一般的にリスクを考えていたようです。様々なプロジェクトの実績データが収集されると、開発規模に対してのリスク以外に、作業内容（お客様との作業分担を含む）、新規技術(いわゆる初物)、負荷、業務の難易度、プロジェクト・メンバのスキル、開発期間等の各種項目に対してリスクを考慮するようになりました。最近ではリスク項目が更に詳細項目にブレークダウンされてきて、大規模プロジェクトのリスク項目を集計すると膨大なリスク項目数になってしまいます。個々のリスク項目に対してリスク量を定量化し、適切な予防策を立案し、最適なリスク管理をしょうと言うのが現在のリスク管理の考え方です。しかし、プロジェクト・マネジメントとして、「リスク定量化の妥当な数値」、「適切なリスク予防策」、「タイミングの良いリスク対策実行時期」を遂行していくことは、現実的には極めて難しい問題です。プロジェクト完了時の結果論として、その適切度や妥当性を出来ますが評価出来ますが、プロジェクト実行中に未来を適切に判断できるのか甚だ疑問です。

この章では、リスクの分析方法や定量化手法ではなく、過去のプロジェクトにおいて、曖昧なリスクに対してどのようにリスク・マネジメントをしてきたかを述べたいと思います。 最初の実例は、筆者が大失敗した最初の大規模プロジェクト（第３章～第５章で紹介）の次に経験したプロジェクトです。この前のプロジェクトが品質で大問題を発生した直後だったので、筆者にとっては是が非でも汚名挽回をしたいプロジェクトでした。前のプロジェクトの反省を踏まえて、このプロジェクトにおいては次のリスク対策を考えていました。

作業量にアローワンス（リスク対策量）を３０％見込む。
アローワンス分は、各種の開発支援ツール規模を正規納入プログラムとして承認して頂く。（当時は開発ソース行数をカウントして規模を検査していた）
お客様との公式スケジュール（公式報告）とリスク対応版スケジュールの２重のスケジュールを持ち、リスク対応版スケジュールで実態をマネジメントする。
異常処理や枝葉の仕様部分をシンプルに割切り、早期にお客様の要求仕様を決着するように誘導する
お客様にも作業（総合試験、性能評価）を分担して頂いて、リスクを分散させる。
先ずアローワンスの３０％確保の交渉では、開発支援ツールが部分的にしか承認されず、１５％分のアローワンスしか目処が立ちませんでした。当時は、見積り規模と実際に出来上がった開発規模の差分は、減額評価の対象になる方法だったので、納入までに何とか辻褄を合わせる宿題を持ったまま、とりあえず（１）、（２）を合意・承認して頂きました。

問題は、（３）の２重スケジュールのマネジメントでした。協力会社社員も含めてリスク対応版スケジュールで実行している実態をお客様に察知されないように、仕様検討会議や進捗管理会議で隠し通さねばなりません。これは大変難しいマネジメントでした。当時の筆者は、この２重スケジュール手法にこだわっていました。その理由は、それまでの経験から、プロジェクトを計画通りに完了する方法は、予定スケジュールよりも１０％～２０％程前倒しに実行して、諸問題を事前検出・早期対処することが最も有効な方法だと考えていたからでした。様々な事情でこのような方法は認めて頂けなかったので、お客様に内緒で実践するプロジェクトを狙っていました。２重スケジュールをお客様に察知されないためには「先ず見方を欺く」作戦を立て、お客様との設計会議や進捗会議に出席しないメンバ（協力会社メンバ含む）には、リスク対応型スケジュールだけを示してマネジメントしました。ユーザ要求仕様も早くかつ割切った仕様で決定し、この段階では開発規模が予定より縮小しました。細かな問題は幾つか発生しましたが、公式スケジュールの範囲内で解決するので、お客様には何の問題も発生していないように報告され、開発が順調に進捗していると思われていました。ところが、お客様参加の総合試験の準備作業が始まった頃、お客様の一部の方と内部のメンバが２重スケジュールの仕組みを感づくようになりました。

説明に苦慮していたところ、お客様の上層部の方から「お客様の外部環境が変化した。サービス開始を３ケ月早めたいので、サービス開始を早めるための対策を提案して欲しい。」と要望されました。サービス開始予定の９ケ月前の時点でしたが、実態は公式スケジュールよりも２ケ月位先行していました。メンバを徐々に減員していく状態だったので、メンバ増強（減員予定のメンバを素早く試験要員に展開）および試験作業を効率化するツールを開発することによる試験期間短縮を提案し、サービス開始時期を公式スケジュール上では３ケ月間短縮して、プロジェクトは完了しました。サービス開始後にトラブルも無かったので、お客様の上層部の方から大変感謝をされました。このサービス開始の３ケ月前倒し事件のおかげで、お客様が２重スケジュール手法のことを気づかずにこのプロジェクトは完了しました。新たに開発した試験ツールは、既成のツール部品を大幅に再利用することにより総規模を大きく出来たので、規模不足問題も何とか解決しました。このプロジェクトでは、世の中は、「良い流れに乗ると、全てが良い流れになる」の言葉を実感しました。

２番目のプロジェクトは、激しい商談獲得競争の結果、廉価かつ短納期で受注したプロジェクトでした。類似プロジェクトの半分の工数と半分の納期で受注したために、「要注意プロジェクト」という噂が流れプロジェクトでした。このプロジェクトは、お客様　→　メインＳＩ会社　→　サブＳＩ会社　→　協力会社という構図でプロジェクトが組織化されていました。筆者は、サブＳＩ会社という立場で参加していました。メインＳＩ会社のリーダーの方と、業務仕様の範囲、サブＳＩ会社の工数、スケジュール、プロジェクトの進め方について、受注条件に捕らわれずに調整しようとしましたが、上手く調整できませんでした。メインＳＩ会社のリーダーの方は、お客様と我々（サブＳＩ会社）が直接会話することを嫌っていました。

仕方がないのでメインＳＩ会社の要請のままに、業務仕様の検討資料を２ケ月間に渡ってメインＳＩ会社に提出しましたが、回答が何にも-帰ってきませんでした。メインＳＩ会社のリーダーの方に苦情を申し上げましたが、一向に改善されませんでした。途方に暮れていた時、お客様の責任者の方が、メインのＳＩ会社に内緒で筆者に面会にいらっしゃいました。「検討資料がメインＳＩ会社から全く提出されないが、本当に検討しているのですか？」という疑問だったのです。お客様の責任者は開発期間が短いので非常に心配な様子でしたので、事実を正直に伝えて、プロジェクトの進め方について本音の意見を交換させて頂きました。とにかく、このプロジェクトは納期が最優先でした。お客様はサブＳＩ会社（業務ノウハウ有り）と直接打合せし、決定することが重要と考えていました。３社合同のユーザ仕様レビュー＆詳細設計レビューおよび３社合同の本音会議を設定しました。これにより３社の関係が親密になり、問題即決のタスクフォース設置、マシン試験と机上レビューの平行実施＆繰り返し実施による品質の早期向上策など多くの知恵を出し合い、プロジェクトは１年という短期間でサービスを開始できました。

このプロジェクトでは前倒しに公式スケジュールを設定していましたので、２重スケジュール手法は不要でした。このプロジェクトは参加メンバ全員が危機感を持ち、納期最優先という単純明快な方針の基に、一致団結して邁進したのが良かったと思います。お客様のリーダーの方が、納期最優先という単純明快な方針を自ら宣言・実行されたのが素晴らしかったと思います。

筆者は、「リスク管理とは、前倒しに作業を実行すること」だと思います。