見積りも計画もバッチリだったのに問題が起きる理由

結論から言えば、それは

　変更管理

がずさんだからです。変更管理、変更依頼管理とも呼ばれますが「構成管理」や「問題解決管理」と並んで、プロジェクトマネジメントが嫌いな人の

　３大苦手管理

の１つとして位置づけされています。ほかにも「課題管理（orインシデント管理）」「リリース管理」などもありますが、これらは少し毛色が異なるため一旦度外視してください。

変更管理と他の管理の関係

ちなみに「構成管理」とは、SVNやGitなど構成管理ツールを使っているかどうかは関係ありません。資源構成を適切に"管理"できているかどうかを意味します。

ここで重要なのは、ベースラインから変更履歴のトレーサビリティを把握できているかどうかです。ツールの有無は関係ありません。

しかし、大抵のエンジニアはツールさえ使っていれば、

　「構成管理できている」

と誤解しています。運用は所詮「人」が行うものです。人が把握しきれていなければ管理・運用できているとは言えません。

また、「問題管理（問題解決管理）」はバグ管理、障害管理などとも言われていますがこちらもツールの有無は関係ありません。問題に対してその原因がどこにあって、解決するためにはどのような手段を用いるべきか、影響範囲は、類似で見直すべき観点はあるのか、期限は、担当は…などを整理し、
スケジュールと連動してプロジェクトの遅延や品質低下に紐づかないよう管理すると同時に、再発を防止するためそのデータをどう生かしていくかという取り組みが重要になってきます。

しかし、管理をしないどころかバグや不良を隠蔽し、こっそり修正しようとするエンジニアも多く、チームとしての成長を阻害する要因として常に問題が指摘される管理プロセスでもあります。

どちらも「人」の育成が追い付いていないプロセスをツールのおかげで何とか問題そのものを目に見えない程度に隠せて運用ができている、非常にリスクの大きな支援プロセス群となっています。

「変更管理」はそうした各種の支援プロセスと同じく、プロジェクトマネジメントにおいては必須とされる一管理体系です。

元来、プロジェクトマネジメントは

　計画を立てて、計画通りに実行する

が大前提ですが、残念ながらすべてが正しく計画できているプロジェクト、あるいはすべてが計画通りに侵攻できるプロジェクトと言うものはありません。現実はなかなか理想通りには上手くいかないものです。

　・仕様が未確定
　・顧客側のスケジュールがはっきりしない
　・技術的に調査してみないことにはわからない
　・エンジニアの力量が常に想定通りというわけではない

と言うケースは往々にして存在します。むしろ存在しないプロジェクトというほうが稀ではないでしょうか。というか、まれだと思ってマネジメントしなければリスク運用の面で心配になってしまいます。

それでも『わかっている範囲』で計画するわけですから、その『わかっている範囲』が変更されたり、追加されたりすれば当然ながら、計画は適宜見直さなければなりません。

変更管理とは、こうしたプロジェクトマネジメントにおける当初計画、あるいは確定／凍結した断面（スナップショット）からの変更部分に対して、

　「変更しても良いかどうか」
　「変更したことによる影響がマネジメントに影響を及ぼさないかどうか」
　「影響を及ぼす場合、ステークホルダーに調整は必要かどうか」
　「で、結局変更するのか、しないのか」

などを検討し、ステークホルダー全体が承認し、計画の再定義を行うものです。これを正しく実施しておかないと次のようなことが起こります。

　①スケジュール等が正しく管理されない
　②ステークホルダーに迷惑がかかる
　③契約内容に変更が無い場合、正しく支払いが行われない
　④納期に間に合わない

波及する問題は多岐にわたりますが、見ての通りわかりやすいトラブルを招くことになります。

②のステークホルダーには、ハードウェア業者やネットワークインフラなどの施工業者、調達や購買などの他部門、協力会社メンバー、そして当然顧客も含まれます。顧客だけをステークホルダーと勘違いしているといずれ手痛いしっぺ返しを食らうことになるでしょう。実際、そうしたプロジェクトを目の当たりにしたことも多々あります。

変更は、依頼者と実施者の双方だけで勝手に決めていいものではありません。変更には仕様変更だけでなく、計画にない作業依頼や、スケジュールそのものの見直し、(病欠等による)要員の変更など様々な理由がありますが、最低でも

・影響範囲の特定
・影響するものへの合意形成
・スケジュールやコスト面での合意

と言ったものを記録として残しておかなければ確実にもめごとを起こします。ビジネスに性善説を持ち込んだ時点で、その責任を一身に背負う覚悟が必要になります。それができないのであれば「契約書」の存在がそうであるように、性悪説に従って管理したほうがお互いに後腐れがなくてスムーズなビジネスを実行できることでしょう。

　

見積りや計画の精度が高ければ高いほど、もし問題や予期せぬトラブルが起きた場合はこの『変更管理』を疑ってみましょう。

十中八九ここに問題があるはずです。

そして、プロジェクトマネジメントを担うマネージャーやリーダーは、こうした"監視・コントロール"プロセスにおけるマネジメント（=やりくり）を疎かにしないようにしましょう。

重要なのは、"立上げ"プロセスや"計画"プロセスだけではないのです。