前回はプロジェクト・ライフサイクルと変更が起きたときに掛かるコストとの関係について解説しました。
「プロジェクト・ライフサイクルの特性。変更コスト。二次曲線になるそのワケ」

変更が起案された場合、それを反映するときはもちろん、却下するにしても検討や説明、起案者との調整のコストが発生し、それはプロジェクトが進むに連れて二次曲線的に増大します。

ではPMBOKはこの特性で何を言おうとしているのでしょうか？
これがこの記事のテーマです。

PMBOKのメッセージは、変更はできるだけプロジェクト・ライフサイクルの始めの方で発生させるということです。

私たちは以前、段階的詳細化のところで、計画の変更はプロジェクトにつきものであって、ネガティブ一辺倒ではないということを学びました。
「段階的詳細化。求められるパラダイムシフト。計画は死ぬまで改善し続ける」

どうせ起きる変更であれば、後に発生してコストがかさむよりも、少しでも先立って発生させた方が、プロジェクトへの負担は軽くて済むというわけです。

とはいっても、将来起こる変更を予測して前倒しで発生させるなんてことは時空を無視した絵空事です。

PMBOKがプロジェクト・マネジャーに求めているのは、変更を先立って発生させるための、仕組みづくり、ムード作り、そしてスタッフのマインドです。

テスト駆動

計画変更の原因には様々なものがあります。

実装ミス、誤解や見落としによるエラー、予想外の環境の変化・・

このうち、例えば実装ミスに対する変更を前倒しで発生させるやり方として、IT業界限定の話になりますが、「テスト駆動」と呼ばれるライフサイクル・モデルが提唱されていて、実際に採用されています。

従来は、コーディング・フェーズが終わってからテストフェーズに移っていたのを、コーディングとテストを一体化するやり方です。(*)

(*)ここで言うテストとは従来からコーディングの後に行っていた単体テストのことではありません。
ユーザにリリースできる機能単位のテストのことで、まずテストを企画してからコーディングに着手します。

考え方としては、動くプログラム、動く機能こそが進捗であって、コーディングをいくら積み上げてもそれは進捗ではないというものです。

このテスト駆動の考え方はPMBOK®ガイドで紹介されるアジャイルにつながっています。

プロジェクトへの影響が大きい要求変更

変更のうち比較的影響の大きいのが要求(*)の変更です。

(*)要求：　詳しくはスコープ・マネジメントで学びますが、プロジェクトの成果物に対する基本的な要望、仕様のことです。
ここから次第に具体化、詳細化されていきます。

計画は要求を土台に策定されるからです。

外部環境が急変したために要求が変更されるのはどうしようもありませんが、プロジェクトでコントロールできることがあります。

一言で言うとコミュニケーション・エラー。
完成形のないプロジェクトの初期には、これを起因とする成果物上のエラーが潜在化します。

成果物の形が見えてきた段階で、依頼側とプロジェクト・チームとの認識のズレ、誤解が顕在化するわけです。

このズレを正そうとするのが要求変更なのですが、変更というのは作り手の言い方であって、依頼者側に言わせれば、変更なんてした覚えはないと言うかもしれません。

こうした要求に関する齟齬を減らすには、要求を収集するプロジェクト・ライフサイクルの初期に、要求元であるステークホルダーとプロジェクト・チームが密接なコミュニケーションを図らなければならないというのがPMBOKのメッセージです。

ただ、言うは易く行うは難しです。
プロジェクトの初期にはそれを阻む以下のような状況があるからです。

・よそよそしい。

臨時の仕事、臨時の組織であるがゆえに、人間関係ができていませんので、ストレートに要求が出てきません。

・依頼者側はデビュー戦

外部プロジェクトの場合、作り手はプロジェクトに慣れていますが、顧客側にとってはめったあることではありません。
一大イベント、まさにプロジェクトです。
プロジェクト・ライフサイクルと変更コストの関係なんて知るよしもありません。

・要求は購入者からすべて明示される

納入者であるプロジェクト・チームに、こうした誤解があります。
実際はそうではなく、プロジェクトの初期に要求は潜在化しています。
これを顕在化し、取りに行かないといけません。

・納入者は自分たちの要求を理解してくれている

購入者にはこうした美しい誤解をしている人がいます。
プロジェクト・チームと依頼者側では文化が違います。
依頼側が常識だと思っていて口に出さないことは、プロジェクト・チームにとって常識ではありません。
暗黙の了解は長いつきあいの中でしか培われません。

プロジェクト・マネジャーは、コミュニケーション・エラーの元となるこうした状況を打破しなければならないということです。

その結果、もしかしたら、プロジェクトの初期に大きな認識違いが判明して、プロジェクトが中断するかもしれません。
でも、最初に分かって良かったねということです。

プロジェクトの初期に静かに進むプロジェクトが良いプロジェクトではありません。

PMP試験向けにもここはしっかり押さえておいてください。

「おい、知ってる？、あのプロジェクト、始まったばかりで顧客と揉めてるんだってさ（笑）」

ひょっとしてそれは、上手くマネジメントされたプロジェクトなのかもしれません。