IT部門におけるプロジェクト・マネジメント

第8回 大規模プロジェクトの体験を通して(その3:リスク管理について)

概要

IT部門におけるプロジェクト・マネジメントについて、大規模プロジェクトの実体験を基に、実際に有効な手法や方法論、重要な仕組みおよび配慮すべき事項等を具体的に展開していくとともに、筆者のプロジェクト・マネジメントに関する考え方を述べていきます。

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

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

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

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

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

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

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

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

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

連載一覧

コメント

筆者紹介

佐野詔一(さのしょういち)
1945年生まれ。
富士通㈱(OSの開発&大規模ITシステム構築に従事)および(株)アイネット(大規模ITシステム構築&ITシステム運用に従事)において、大規模ITシステム構築&大規模ITシステム運用経験を経て、現在はITプロジェクト・マネジメント関係を専門とするITコンサルタント。産業能率大学の非常勤講師(ITプロジェクト・マネジメント関係)を兼任。

バックナンバー