DX(デジタルトランスフォーメーション)推進コンサルティング 株式会社アイ・ティ・イノベーション

ご訪問ありがとうございます！　　　　　　　　　　＜　前回　｜　目次　｜　次回　＞

高校野球の秋季大会が始まり、うちの二人の息子たち（現高２、高１）も東京と埼玉で、春の甲子園目指してがんばっています。どちらも早々に強豪校と対戦する組み合わせとなりましたが、新チームになって間もない時期なので、甲子園出場という目標に向けては逆にチャンスと考えられます！

システム開発のプロジェクトにおいても、リスクの高いタスクを早々に片づけるようにプロジェクト計画を組み立てた方が、プロジェクトの成功確率は高まるのではないでしょうか？（※１）

今回は、システム開発プロジェクトにおける「９０％シンドローム」の具体的な予防策について考察します。

【　ＰＭ必見！「９０％シンドローム」を撃退する３つのポイント　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・
前回　【第３６回】真夏のグレムリン～自己増殖するタスクたち～　では、「９０％シンドロームを予防するキーポイントは、プロジェクト計画の中にある！」ということを結論づけました。

「９０％シンドローム」は、スケジュールの最後の方にやっかいな問題が検知されることが大きな特徴です。

この特徴を踏まえたうえで「９０％シンドローム」の予防策を考えると、以下の３つのポイントを考慮して、プロジェクト計画を組み立てる必要があると考えられます。

＜９０％シンドロームを撃退する３つのポイント＞

1. やっかいな問題を早期に検知できるようにする（監視の仕組み）
2. やっかいな問題を早期にあぶりだすようにタスクを組み立てる（リスク予防策）
3. やっかいな問題の発生に備え、十分なリカバリ期間を確保（スケジュールバッファ）

【　９０％シンドローム撃退法（１）監視の仕組み　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・
当ブログの　【第３２回】準優勝！と決勝敗退！の微妙な違い　では、「９０％シンドローム」について、「その原因の多くは、的確な進捗管理ルールが無いか、報告された進捗状況を何もチェックせず鵜呑みにしてしまう丸投げマネジメント体質による。」とコメントしました。

つまり、プロジェクトの監視・コントロールの基本として、進捗管理ルールを明確にして、進捗報告内容に報告者の「さじ加減」ができるだけ入り込まないようにすることが、「９０％シンドローム」を招かないための重要なポイントであることは間違いありません。

そのうえで、早め早めにチェックポイントを設けて、問題が発生していないかを確認することは当然行う必要があります。前回とりあげた「９０％シンドローム」の具体例のうち、＜具体例３　本番稼働直前に大きなタスク漏れが発覚してプロジェクトがストップ＞の移行タスクの漏れなどは、早めに（たとえば移行計画書のレビュー時などに）カットオーバー・クライテリアに基づいて移行計画の点検を行っておけば、すぐに気が付くはずです。（※２）
ただし、その時点で有効なカットオーバー・クライテリアが存在していればの話ですが。。。

早め早めにチェックポイントを設けるためのテクニックとして、詳細ＷＢＳ上の最下位タスクの長さ（期間）を最大１週間とするようにルール決めすることもあります。進捗会議を週次で行うことが多いので、どこかのタスクで遅延が新たに発生した場合に、次週の進捗会議では必ず遅延を検知できるようにするための「監視の仕組み」です。

しかし、前回とりあげた＜具体例１　外部設計のタスクが進捗率９０％から進まない＞と＜具体例２　結合テスト工程が進捗率９０％から進まない＞では、週次の進捗会議でしっかり進捗状況をチェックできていたとしても、それだけでは問題の検知はできなかったことが想定されます。

逆に言えば「監視の仕組み」で解決できるのは、小学生が夏休みの最終日まで宿題をしないで遊びまくっていたときのような「夏休みの宿題症候群」だけであり、システム開発における「９０％シンドローム」のほとんどのケースは、それだけでは回避できないということをしっかりと認識する必要があるのです！

【　９０％シンドローム撃退法（２）リスク予防策　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・
前回ご紹介した＜具体例１　外部設計のタスクが進捗率９０％から進まない＞のイメージを表した図１の詳細ＷＢＳをもう一度確認してください。××機能の外部設計は、作成が７０％、内部レビューが２０％、外部レビューが１０％の進捗率の配分となっており、開発ベンダー内で行うタスクだけで全体の９０％の期間を費やすこととなっています。

冷静に考えれば、こんなスケジュールではうまく行くはずないのは一目瞭然です。要件定義でどこまで外部仕様を明確化していたかにもよりますが、一般的には新規に開発するシステムであれば、外部設計についてできるだけ発注側の意向とずれていないことをひんぱんに確認しながら進める必要があります。発注側の意向を全く確認しないまま、９０％の期間を費やしてしまったら、残りの１０％しかない期間で行われる外部レビューにおいて、発注側からのレビュー指摘が多発するリスクが高まるのは当然です。このケースは「監視の仕組み」の問題ではなく、タスクの組み立て方に問題があったことは明白です。

これを防止するためには「監視の仕組み」を強化するだけでなく、設計内容が発注側の意向とずれていないことを確認できるタイミングが早く訪れるようにタスクを組みなおす必要があるのです。具体的には、外部設計書のドラフト版を早めに提示するとか、外部設計書の中で一部の目次分だけ先に提示するとか、工夫すればいくらでも対応策はあるはずです。

前回ご紹介した＜具体例２　結合テスト工程が進捗率９０％から進まない＞の事例も同じです。機能に着目したテストケースだけでなく、性能など非機能系のテストケースのように初めて行うテストの種類は、できるだけ早いうちに少しだけでも実施するような予定を組んでおく必要があるのです。

以上のことをリスクマネジメントの視点で考えると、タスクや工程やプロジェクト全体の実施期間の中で、リスクの高い作業やタスクを洗い出し、リスクの高いタスクを早め早めにつぶしていくように計画する必要があるのです。そうすれば、やっかいな問題を早めに検知できるようになり、「９０％シンドローム」に陥るリスクが軽減されるのです！

【　９０％シンドローム撃退法（３）スケジュールバッファ　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・
そして3つ目のポイントです。いくらタスクを組み替えようとしても、どうしてもリスクの高いタスクを最後の方まで残さざるを得ないことは当然出てきます。たとえば、本番稼働中の外部システムとの接続テストなどは、自プロジェクトの都合だけでスケジュールを決められないこともあり、実際に接続してテストを行う時期が本番稼働直前になってしまうこともよくあります。

スケジュールが押し詰まってから問題が噴出すると、リカバリの時間がとれず、コントロールが利かなくなり、泥沼化する要因となります。このようにリスクの高いタスクがどうしても最後に固まってしまう場合には、仮にやっかいな問題が発生してから、それをリカバリするための期間、すなわち「スケジュールバッファ」をできるだけ確保する必要があります。

もし、リスクの高いタスクの後にリカバリのための「スケジュールバッファ」を十分確保することができれば、やっかいな問題が発生するかもしれないポイントを事実上前倒しすることになるのです。

既にお気づきの方もいらっしゃると思いますが、ポイントの２つ目（リスク予防策）と３つ目（スケジュールバッファ）をプロジェクト全体のレベルで計画に盛り込もうとしているのが、当ブログの　【第３１回】禁断の裏マスタースケジュール　でご紹介した「裏マスタースケジュール」＝「リスクへの対応計画を含んだマスタースケジュール」ということになります。

したがって、「９０％シンドローム」の賢い撃退法とは、タスクであれ、工程であれ、プロジェクト全体であれ、リスクの十分な洗い出しと洗い出したリスクに対する予防策をしっかりとプロジェクト計画の中に盛り込むことだったのです！

「９０％シンドロームの賢い撃退法は、リスクへの予防策をしっかりと計画に組み込むことだ！」

ご納得いただけたでしょうか？

それでは、次回もお楽しみに！　　　　　　　　　　＜　前回　｜　目次　｜　次回　＞

工藤武久

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
応援してくださる方は、クリックよろしくお願いします！
◆　人気ブログランキング
◆　にほんブログ村
～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～

※１　当ブログの　【第３１回】禁断の裏マスタースケジュール　では、マイナスの影響を及ぼすリスクの予防対策とプラスの影響を及ぼすリスクの強化策をプロジェクトの序盤で実施するようなマスタースケジュールを組むことを推奨しています。つまり、不確実性の高いタスクや検討事項を早めに片づけてしまえということです。
仮に不確実性の高い検討事項が当初見積りのスケジュールやコストで実現可能性が無いことが早めに明確になったとすれば、早い段階でプロジェクト全体計画のリプランについて、必要なステークフォルダーとの調整・交渉が可能となり、プロジェクト終盤でのドタバタ劇を回避することができるはずです。

※２　【第３４回】カットオーバー・クライテリアとは何か？