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

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

毎週の進捗会議でプロジェクトが計画通り進んでいるかどうかをチェックしているはずなのに、なぜあらためて工程完了判定会議を行う必要があるのでしょうか？システム開発プロジェクトの工程完了判定基準は、ひとことで言えば、その工程内でやるべきことについて「全てがきちんと」できたかどうかを判定するための物差しです。今回は、この工程完了判定基準について考えてみます。

【　工程完了判定基準が必要な理由　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・
たとえば要件定義が不十分だったことが原因で基本設計以降に手戻りが何度も発生し、スケジュールが大幅に遅延してプロジェクトが泥沼化した場合、要件定義工程の完了判定基準が不明確だったことが問題視されます。

確かに要件定義が不十分なまま基本設計以降を進めてしまったことがプロジェクト失敗の大きな要因であれば、その再発防止策として、要件定義工程の完了判定基準を明確化したうえで、その基準をクリアしない限り次工程には進めないようルール化する、という話は良く耳にします。

テスト工程でも同じようなことがあります。たとえば、単体テストを十分実施しないままユーザー受け入れテストまで進めてしまった場合、障害が多発して十分にユーザーがテストしきれないまま、本番まで障害が持ち込まれてしまう可能性が高くなります。このケースでも、単体テスト工程の「全てがきちんと」できてから、後続のテスト工程に進めるようにするという再発防止策が検討されます。

まあそれはそれで、システム開発プロジェクトのプロセス改善アプローチとして決して間違ったことでは無いでしょう。。。

しかし、ほとんどのプロジェクトでは工程完了時だけではなく、より頻繁に（たとえば毎週）、進捗会議を開催し、プロジェクトが計画通りに進んでいるかどうかを確認しているはずです。それなのに工程完了判定基準に従って確認したところ、実は「全てがきちんと」できていなかったという問題が起きてしまいます。いったい、どうしてその問題は毎週の進捗会議では検知できないのでしょうか？

【　工程完了判定基準はプロジェクト計画書のサマリー版である！　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・
当ブログの　【第４回】プロジェクトにおける問題とは何か？　を思い出してください。ここでは、プロジェクトにおける問題を発見するための物差しとして、プロジェクト計画書が使えるということを考察しました。

工程完了判定基準が各工程内でやるべきことの「全てがきちんと」できていることを判断するための物差しだとすると、プロジェクト計画書とまったく同じ使い方ができるということになります。

とすると、プロジェクト計画書よりも工程完了判定基準に記載されている情報量の方が少ないはずなので、工程完了判定基準はプロジェクト計画書のサマリー版であるという見方ができるはずです！

また、当ブログの　【第３０回】マスタースケジュール・フェチ　を思い出してください。ここでは、マスタースケジュールはプロジェクト計画書の要（かなめ）であり、マスタースケジュールを水晶玉のように眺めてあれこれ妄想することで、プロジェクトに内在しているリスクを識別することを推奨しています。つまり、マスタースケジュールはプロジェクトに内在しているリスクを洗い出すための物差しであり、こちらもプロジェクト計画書のサマリー版であるという見方ができるのです！

つまり、プロジェクト計画書、工程完了判定基準、マスタースケジュールの関係性は次のようなに整理できるのです。

•  プロジェクト計画書　＝　プロジェクトの問題発見やリスク識別のための物差し
•  工程完了判定基準　＝　過去に着目した物差し（問題の発見）
•  マスタースケジュール　＝　未来に着目した物差し（リスクの識別）

この関係性が見えてくれば、≪なぜ毎週進捗会議をやっているのに、工程完了時点で「全てがきちんと」出来ていないという現象がおきるのか？≫がわかるはずです。

それは工程完了判定基準、プロジェクト計画書、マスタースケジュールのそれぞれに記載されているポイント間の整合性が確保できていないためです。工程完了判定基準でせっかく達成目標を定義しているのに、それを実現するための具体的な計画がプロジェクト計画書やマスタースケジュールに書かれていない（書かれていたとしても不十分である）ことが原因だったのです！

「工程完了まで問題が検知できないのは、プロジェクト計画書が不十分だからだ！」

工程完了判定基準で設定した達成目標を実現するための具体的な計画が、プロジェクト計画書やマスタースケジュールに十分盛り込まれていて、それらを物差しとしたプロジェクトマネジメントが機能していれば、工程完了時まで「全てがきちんと」できていなかったことに気付かないことはないと思います。工程期間内のプロジェクトマネジメントがうまく機能していれば、工程完了判定会議をスムーズに運営することが可能となり、極端な話、工程完了判定会議など不要としても良いはずです！（ちょっと言い過ぎかな。。。）

このことから、要件定義が不十分で基本設計以降の手戻りが多発することや、単体テスト工程が不十分で本番まで障害が残存するというプロジェクト失敗の原因は、工程完了判定基準の不備というよりも、むしろプロジェクト計画書やマスタースケジュールの不備により、プロジェクトの問題発見やリスクの識別が不十分となっていたということに気付くでしょう！

【　工程完了判定基準にオフサイドトラップを仕掛ける！　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・
工程完了判定基準は過去に着目した物差し（問題の発見）です。既に起きてしまった問題を発見するというのは、なんとも後ろ向きで、私は個人的に大嫌いです。それに工程完了判定会議は、形式的な儀式に陥りがちです。

そこで、工程完了判定基準を活性化し、工程完了判定会議を有意義なものにするためのアプローチとして、次のような取り組みを行ってみてはどうでしょうか。

1.  プロジェクト開始時にプロジェクト全体に内在しているリスクを徹底的に洗い出す。
2.  洗い出したリスクをどの工程までに解消しておく必要があるか、期限設定を行う。
3.  これらのリスクが解消されているか否かの判定を各工程完了判定基準に追加する。

もちろん、洗い出したリスクの予防対策は、設定した期限より前に実施するよう計画に組み込んでおく必要があります。工程完了判定基準をこのように作成することで、お題目だけで実効性が薄くなりがちなリスク予防策について、その実施状況と効果を工程完了時に確認できるようになり、しっかりしたプロジェクト・リスク・マネジメントができるようになると思います。

将来発生するかもしれないリスクへの対策を、先々の工程の完了判定基準の中に罠（トラップ）を仕掛けて待ち伏せするような感じになるので、私はこれをサッカーのオフサイドトラップにたとえることがあります。（ちょっと意味合いが違いますが、語呂が良いので。。。）いかがでしょうか？（※１）

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

工藤武久

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

※１　「オフサイドトラップ」『フリー百科事典　ウィキペディア日本語版』　http://ja.wikipedia.org/wiki/オフサイド (サッカー)　 2014年7月6日 (日) 14:59