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

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

前回は「膨張するプロジェクト」への処方箋としての「トリアージ」について、用法や用量に気を付ける必要があるということを考察しました。 では、プロジェクトが膨張した場合には、いったいどうすれば良いのでしょうか？ ごく普通に考えて、膨張した要件やスコープに見合うようにプロジェクト計画を見直しするのが理にかなっているはずです。

【　コストやスケジュールは絶対的制約事項か？　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
―――　ベテランＰＭのＭ男氏がまゆをしかめて、ブツブツ文句を言っています。

＜ベテランＰＭのＭ男氏＞　：　「キックオフからカットオーバーまでプロジェクトは膨張し続けるんだから、その都度計画を見直してたら、一生プロジェクト計画を見直し続けることになるじゃないか！つまり、最初に作ったプロジェクト計画は無意味だってことで、無意味な計画を見直したって無意味に違いないから、やっぱりプロジェクト計画なんて放っておいて、開発作業に注力する方が効率的ということよ！」

＜新人Ｐ子さん＞　：　「うーん。確かに、何か問題が起きるたびにスケジュールや予算を見直して良いんだったら、プロジェクト計画の位置づけがよくわかんなくっちゃったわ。。。でも、最初に作った計画がダメダメだってことだから、もっとリスクを考慮した計画にしとけばよかったのかしら。。。」

＜ベテランＰＭのＭ男氏＞　：　「何をたわけたことを言っとるんだ！何度も言うように、システム開発のプロジェクトで起こるかもしれないリスクを全て洗い出して、全てを計画に盛り込むなんてことは不可能だろ？だから、俺たちのような経験豊富なＰＭがプロジェクトの陣頭指揮をとって、最初に決められたスケジュールやコストになんとか収められるようにプロジェクトを切り盛りしていくしかないんじゃ。（まあ、いつもはみ出るけどね）」

なかなか興味深い議論ですね。Ｍ男氏の言うように、多くのプロジェクトにおいて、最初に設定されたコストやスケジュールといったプロジェクト目標が、絶対に動かすことのできない、いわば「絶対的制約事項」とみなされることで、「その中でなんとかするしかない」という思考に陥ってしまいがちです。 プロジェクト目標のうち、コストやスケジュール（リリース日）は、明確な数値として表すことができるため、これが達成できないことは白黒がはっきりします。

一方、スコープや品質については、誰しもが納得できる数値として表すことが難しいため、無意識のうちに優先度が下がってしまう傾向があります。 その結果、「膨張するプロジェクト」において、コストやスケジュールを厳守するために、スコープを「トリアージ」し、品質を犠牲にするという間違ったアプローチをしてしまう危険性が出てきます。そうなってしまう原因は、最初に設定されたコストとスケジュールを達成したか否かをプロジェクトの成功と失敗の判断基準ととらえる習慣が根付いているためではないか、と私は考えています。（※１）

確かにコスト（プロジェクト予算）やスケジュール（リリース日）が「絶対的制約事項」となっているケースもありますが、スコープを削ってまで達成すべき制約では無いケースもあります。長期的に見て、そのプロジェクトで構築するシステムによってビジネスの目標達成に近づくことができるのなら、スコープを削るよりも、プロジェクト予算を追加したり、リリース日を延期するという選択肢を選んだ方が良いケースもあるはずです。

【　プロジェクト計画の見直しタイミング　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
さて、Ｍ男氏とＰ子さんの議論の中で、キックオフからカットオーバーまでプロジェクト計画を見直し続けなければならないという話がありました。確かに、何かあるたびにプロジェクト計画を見直していてはきりが無いので、あらかじめプロジェクト計画を見直すタイミングをマスタースケジュール上にマイルストーンとして置いておくのが良いでしょう。

要件定義前の初期見積り時点ではまだ見えていなかった部分が、要件定義、外部設計を通じて、少しずつ見えてくることにより、初期見積もり時に想定していたスコープとのずれが生じます。したがって、要件定義、および、外部設計の完了時点に、それぞれチェックポイントを置いて再見積りを行い、再見積り結果に基づいたプロジェクト全体計画の見直しを行うようにあらかじめ計画しておくのです。（※２）

それぞれの再見積りのタイミングでは、初期見積り時点で前提としたスコープとの差異を明確にして、ステークフォルダーに説明する必要があります。再見積りの結果、当初のスケジュールやコストのまま開発を進めることに無理があると見込まれる場合、あらためてスコープを削るのか、予算を追加するのか、スケジュールを見直しするのかの判断を行うことになります。

この判断は、そもそもプロジェクトを開始するきっかけとなったシステム化の目的を軸にして、さまざまな「絶対的制約事項」に立ち返って総合的に判断する必要があります。スコープを削れば当初スケジュールの通りにリリースできるかもしれないが、それではシステム化の目的を十分達成できないと考えれば、その時点でリリース日を延伸させるか、プロジェクトを中断し、システム企画に立ち戻ってやり直すということも視野に入れて考える必要があるかもしれません。

こうして考えてみると、プロジェクトが膨張する原因として、プロジェクトが発足する前のシステム企画段階での検討の不十分さが影響していることに、あらためて気づかされます。システム企画段階での検討が浅ければ、それだけプロジェクト初期見積り時点でまだ見えていない部分の面積が広くなり、見積りのブレ幅も大きくなって、キックオフ後にプロジェクトが膨張する可能性も大きくなってしまうことになります。（※３）

プロジェクトのコストやスケジュールの達成が成功判断基準とみなされ、キックオフ後にコストやスケジュールを見直しすることが許容しづらい雰囲気の中であれば、なおのことシステム企画段階に力を入れる必要があるということになります！

「コストやスケジュールの達成がプロジェクトの成功基準であるなら、システム企画段階にもっと重点を置くべきである！」

【　プロジェクト計画見直し時の落とし穴：リソース制約　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
さて、膨張し始めたプロジェクトにおいては、当然タスクが増えていくことになるので、タスクごとに割り当てたプロジェクト体制図も膨張していくことになります。

要件定義や外部設計完了時のチェックポイントで再見積りを行い、初期見積りとの差異を明確にしてステークフォルダーに追加予算とスケジュール見直しの承認を頂いたものの、追加されたタスクに割り当てるリソース（要員）の手当てができないということが往々にして発生します。 そもそもプロジェクトをキックオフする時点で、当初のプロジェクト計画を実行するためのリソースがぎりぎりであったり、キックオフ後に調達する予定にしていたのに、さらにスコープが膨張した場合には、リソースの不足は深刻化します。特にプロジェクト体制上のキーマンとなるリーダー、サブリーダの人材を確保することはなかなか難しいものです。

そんな状況でよく見かけるのは、プロジェクト体制図のあちこちに同じ人の名前が記載される現象です。まるで、ウルトラマンシリーズに出てくるバルタン星人のように分身の術をつかい、いくつものチームのリーダーとして活躍します。分身の術を使うことができるのはスキルの高いスーパーエンジニアであることが多く、確かに後で追加した要員にまかせるよりも、スキルの高いバルタン星人に分身の術を使ってもらう方が一時的にリソース不足の危機を乗り越えられる可能性は高いかもしれません。（※４）

しかし、いくらスキルの高いバルタン星人といえども、長丁場のプロジェクトにおいて、分身の術を続けることによりエネルギーを消耗すると、二度と立ち上がることができなくなってしまう危険性があります。そうなった場合には、そのプロジェクトの失敗につながるだけでなく、組織としての損失につながってしまう恐れもあるので、プロジェクト体制図にバルタン星人が出没し始めたときには注意が必要です！

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

工藤武久

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

※１　【第３５回】プロジェクト・サクセス・クライテリア（成功判断基準）

※２　プロジェクト計画書（全体計画）を見直しする際には、段階的詳細化の結果も合わせてフィードバックする必要があります。
【第２３回】プロジェクト計画書の段階的詳細化とは？
また、プロジェクト計画書を見直し続けることについては以下の回も参考に。
【第２２回】京都ひとり旅の計画は行き当りばったりが良いか？

※３　初期見積りに関しては、当ブログの以下の回もお見逃しなく！
【第２４回】プロジェクト初期見積りの不確かさ
【第２５回】プロジェクト初期見積り考古学
【第２６回】まだ見えていない部分をどうやって見積りに含めるのか？
【第２７回】「既知の未知」と「未知の未知」に備える！
【第２８回】ＲＦＰに隠された暗号を読み解け！
【第２９回】見積り前提は魔除けの呪文だった？

※４　「バルタン星人」『フリー百科事典　ウィキペディア日本語版』
2014年10月13日 (月) 04:01 utc http://ja.wikipedia.org/wiki/バルタン星人