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

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

前回は「プロジェクトにおける問題とは、プロジェクト計画と現状とのギャップである！」と宣言しました。そのことをわかりやすく説明するために、今回は「プロジェクトにおける問題」の具体例について考えたいと思います。

【　典型的なプロジェクトにおける問題の具体例　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
具体例１　××サブシステムの単体テストの進捗が遅れている

具体例２　ＹＹサブシステムの品質が悪く、ユーザテストで障害が多発している

具体例３　まだ結合テスト段階なのに、プロジェクト予算を使いきってしまった

どれも良く聞くような問題ですね。まずはいつものごとく、＜目標（あるべき姿）＞と<現状＞が何か、＜問題＞を因数分解してみましょう。

【　具体例１　進捗が遅れている　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
「××サブシステムの単体テストの進捗が遅れている」

＜目標（あるべき姿）＞　＝　「単体テストの進捗が進んでいる」
＜　　現　　　状　　＞　＝　「単体テストの進捗が遅れている」
＜　　問　　　題　　＞　＝　「進んでいる」ことと「遅れていること」のギャップ

具体例１のステートメントは、何か問題がぼやけてるように感じますねえ。確かにギャップがあるようですが、これでは先に進みません。そこで、プロジェクトにおける目標（あるべき姿）を示しているはずのプロジェクト計画書を見てみましょう。進捗の問題ですから、スケジュール表を見れば良いでしょうか。。。

そうですね。このスケジュール表を見れば、だいたい問題は把握できそうです。プロジェクト計画段階で立てたスケジュール（あるべき姿）に対して、赤い線（イナズマ線）（※１）が現状を示しており、ＸＸサブシステムの内部設計~結合テストがだいたい１ヶ月程度遅れているということ（ギャップ＝問題）が、とてもわかりやすくなりました。

しかし、これだけでは具体的な対策に結びつかないので、実際のプロジェクトにおいては詳細なスケジュール表（詳細ＷＢＳ）などを使って、具体的な問題箇所を特定、原因を追究した上で、対策していくことになります。ここでは、プロジェクト計画がプロジェクトにおける目標（あるべき姿）を示しているはずだということだけ、しっかりと頭にたたきこんでください。

蛇足ですが、この例ではちょうどイナズマ線のひかれているあたりのマイルストーンに、第３回目のステコミ（ステアリング・コミッティ）を実施したことを示す▲マークが示されており、きっとそのステコミでは進捗遅れの問題で紛糾したことが想像できますねえ。。。

【　具体例２　品質が悪い　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
「ＹＹサブシステムの品質が悪く、ユーザテストで障害が多発している」

＜目標（あるべき姿）＞　＝　「ユーザテストで障害が出ない」
＜　　現　　　状　　＞　＝　「ユーザテストで障害が多発」
＜　　問　　　題　　＞　＝　「障害が出ない」ことと「障害が多発」のギャップ

具体例２のステートメントは、具体例１のステートメントに比べれば問題が明確なように見えます。しかし、あるべき姿の「ユーザテストで障害が出ない」ことは、プロジェクト計画書に明記されているでしょうか？

開発担当者の立場からすると、「ユーザテストは本番でもないし、少しぐらい障害が出ても良いじゃん。連絡あったらすぐに対応してるし。」って口には出さずともそう思っている人が多いのではないでしょうか？

一方のユーザの立場からすると、「ベンダーのテストが終わっているのに、なんで障害が残っているんだ！もしユーザがその障害に気付かなかったら、それは本番事故だったんだぞ！」と言われるのが落ちです。リリース前には障害とか不具合と言えたものが、リリース後は事故として扱われますよね。

この開発担当者とユーザのように置かれている立場の違いによって、あるべき姿について思い浮かべることが全く異なるのです。「問題認識の相対性理論」（※２）の実例です。だからこそ、こういう状況に陥らないために、プロジェクト計画書でユーザテストの品質目標を具体的に定義しておくことがとても重要となってきます。計画段階で品質目標をきっちり合意しておくことはなかなか難しいのですが、計画段階で合意しておかないと実行段階ではもっと苦しい状況に追い込まれることを理解してください。発注側と受注側の両方が納得する品質目標を合意しておくことが理想です。

【　具体例３　コスト超過　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
「まだ結合テスト段階なのに、プロジェクト予算を使いきってしまった」

＜目標（あるべき姿）＞　＝　「本番稼働までプロジェクト予算内でおさめる」
＜　　現　　　状　　＞　＝　「結合テストでプロジェクト予算を使いきった」
＜　　問　　　題　　＞　＝　「予算内でおさめる」ことと「予算を使い切った」のギャップ

具体例３のステートメントでは、明らかにあるべき姿と現状にギャップ（問題）があることがわかります。でも、なんでこんなに大きなギャップになってしまったのでしょうか？おそらく「予算内でおさめる」ということについて、計画の具体性が無かったのではないでしょうか？月ごとの要員計画、機能ごとの発注計画・・・プロジェクトスタートからカットオーバーまでのコスト計画が具体的になっていないと、定常的な（たとえば月ごとの）計画と実績の差異、総コストの見通しのチェックができず、いつの間にか「コストを使い切る」ということになってしまいます。開発規模と標準生産性で総コストを出すところまではいいのですが、その総コストをどうやって切り崩していくか、マスタースケジュールや工程ごとの体制図、要員山積み表などを使ってプロジェクト全体のコストの使い方をしっかり監視できるようにするためにも、具体的な（ポイントを押さえた）プロジェクト計画が欠かせないということが理解できますね。

【　プロジェクト計画の具体化とコミットメントの重要性　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
これらの具体例からわかるように、プロジェクト計画が具体的でないと次のような「悪いこと」が起きてしまいます。なお、この脈絡の中で「問題」という言葉を使うと混乱するかもしれませんので、ここではあえて「悪いこと」という言葉にして、使い分けさせてもらいます。

Ａ．問題の検知ができない（または、遅れる）
具体例３のように、コスト計画が具体的でないとコスト超過の傾向の検知が遅れ、問題が発覚した段階ではすでに手遅れということになりかねません。

Ｂ．問題認識が異なることによる無用なコンフリクトが発生（問題認識の相対性理論）
具体例２のように、ユーザテストにおける品質目標が明確に定義されて合意されていないと、発注側、受注側お互いが疑心暗鬼になって、プロジェクトがとん挫してしまうかもしれません。

Ｃ．問題の原因や深刻度が良くわからない（あいまい）
具体例１ではマスタースケジュールを物差しにしていますが、これだけでは「遅れている」ことはわかりますが、どの作業で遅れている（たとえば内部設計のレビューが進んでいないとか、単体テストの環境構築に時間がかかっているとか・・・）のか、また、どの担当の作業が遅れているのかなど、問題の原因や深刻度が判断できません。

これらの「悪いこと」の結果、しかるべき対策（アクション）が遅れてしまい、プロジェクトの成功確率は下がってしまうことになります。このように、「プロジェクトにおける問題」を早期に発見し、しかるべき対策を早期に打つための大切な物差しとして、ポイントを押さえた具体的なプロジェクト計画を策定することがとても重要になってくるのです。

そして、「問題認識の相対性理論」によるステークフォルダー間の無用なコンフリクトを無くすためには、策定したプロジェクト計画について、ステークフォルダー間（発注側と受注側）で十分議論した上で、コミットメント（みんなが納得）することもとても重要であることが理解できると思います。

「プロジェクトにおける問題を的確に把握するには、プロジェクト計画の具体化とコミットメントが必要である！」

ご納得頂けたでしょうか？

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

工藤武久

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

※１　「イナズマ線」については、「ＩＴの達人」ブログの先輩である弘中伸典氏がわかりやすく解説しているので、そちらも参考にしてください。
「PM力であなたも組織も強くなる！【第24回】作業の進み具合を確認する」

※２　問題認識の相対性理論については、当ブログ「【第３回】問題とは何か？」を参照願います。

※３　図１～３で示す具体例はあくまでも架空のプロジェクトのものであり、その数値や内容について実プロジェクトにそのまま適用することはできませんので、ご注意願います。