伝統的な”変更管理”は未だ健在だが．．．

プロジェクト・マネジメントはまさに”変更との闘い”と言っても過言ではないくらい、変更管理の比重は高いと思います。ここをうまくやるかどうかで、他のプロジェクト・マネジメントへの対応負荷や精度も変わってきます。変更管理は決して難しいプロセスではありません。昔からある伝統的なプロセスで、アジャイル開発などでも本質は変わらないと私は考えています。ただ、実施を徹底することが難しいのです。

なぜ徹底が難しいのか

イマドキIT中間管理のためのスコープ・マネジメントで語りましたが、ベースラインはどんなに精査しても、曖昧さや流動性をなくすことはできません。さらに、

• 「当初のベースラインに入っていたべきだろう」
• 「これくらいの対応も追加コスト、スケジュール延長になるのか」
• 「営業や戦略的な値引きはないのか」

といった交渉は日常茶飯事です。そこへ変更管理などという面倒なプロセスを持ち込むと、変更を依頼する側としては手間はかかるし、交渉はやりにくくなるし、良いことがないやりとりになります。

面倒なことは最初にルール化し、後は徹底

とはいえ、変更管理をないがしろにしてベースラインを変えてていくと以下のようなことが起きます。

• 限られたリソース（コスト、スケジュール、人工）をオーバーする
• 仕様、ドキュメントの整合性がとれなくなり品質が悪化する
• ”本当に必要な”システム、サービスから逸脱する（個別機能の最適が進む）

そのため、変更管理プロセスの必要性と効果をステークホルダーの中できちんと認識ししつつ、プロセスの実施にはオーバーヘッドが少なくなるよう、最初にプロセス化＝ルール化し、PJの開始後は愚直にそれを徹底し続けることでベースラインを維持し、PJの方向性やリソースを制御下におくようにします。

変更管理で”ありがち”なこと（実体験に基づく）

私のPJ経験上、変更管理を実施体もなお、徹底が難しいポイントがあります。
以下のポイントには注意しましょう。

• 個別最適でビジネスプロセス全体の効果を考えていない
  PJがスタートした後の利用者側の視点は担当者レベルになります。当初、ビジネス戦略に基づいて検討されたビジネスプロセスに対し、個別最適な変更が次々と要望される場合があります。「今、それは本当に必要ですか？」を繰り返し、全体最適、効果を意識して変更を管理しましょう。
• 無償対応をどんどん押し込まれる
  イマドキIT中間管理のためのスコープ・マネジメントでも話題にしましたが、軽微な修正は誤差やサービス、当初提案されていたべきという名のもとにスコープを変えないまま、仕様だけが増えるケースが多いです。軽微な修正の無償対応をゼロ化することは難しいので、どれくらいの対応が現状のPJ活動に含めて対応できるのかを明文化し、感情、商売抜きでロジカルに判断するとよいでしょう。
• ベースラインがいつのまにか変わってゆく
  システム、サービス導入で、私の経験では外部委託、一括請負契約によるものがほとんどでした。そのため、ベースラインの合意形成と維持がとても重要なポイントになります。しかしながら、変更管理が面倒だからと口約束での微修正を行っていくと、いつのまにか仕様やドキュメントに不整合が埋め込まれ、最終的にPJに大きなインパクトを加えてしまったことが少なくありません。些細な変更もプロセスを通すべきで、さらに言うと、些細な変更が面倒にならないプロセスであるべきでしょう。
• 非機能要件が語られていない
  変更は導入するシステム、サービスが適用されるビジネスへの影響、効果を第一として語るべきですが、見落としがちなのが、性能や容量、画面構成、テスト、ドキュメンテーションといった非機能要件です。プロセスの中に非機能要件を確認、合意形成するポイントを設け、必ずチェックしましょう。
• 見積り根拠が合意できない
  変更管理で一番難しいポイントだと私は思います。ゼロベースの見積り手法はいくつもありますが、変更（ベースラインからの差分）の見積り手法が汎用的なメソッドとして確立された確立されたものをついぞ見たことがありません。工数を積み上げる、類似機能と同じ工数で見積もるなどを一つずつ丁寧にやるしかないと思います。また、比較的見積しやすい画面項目追加やユーザ追加、インフラ機器構成変更などは見積りの度に根拠が変わらぬよう、決まった従量で見積もるようにして下さい。

“俺なりの”変更管理プロセス

上記を踏まえ、過去に私が実際に使った変更管理プロセスをまとめてみました。
あくまで例です。プロセスや閾値、メンバー構成などはPJやシステム、サービス毎にきちんと検討してPJに適用してください。

• 変更管理プロセスフロー　（ppt file）
  
  
• 変更管理規定　（word file）
  
  
• 変更管理票　（word file）
  
  
• 変更一覧表 （excel file）
  
  

変更管理は構成管理のプロセスや成果物と密接な関係にあります。構成管理のツール、情報をうまくサマリして、ダッシュボード情報として共有すれば、成果物の構成や課題、進捗などが効率的に管理できます。PJの形態によってツール、情報をうまく使いましょう。

変更管理と構成管理の関係（ppt file）

まとめ

変更管理は開発手法やプラットフォームが進化した昨今でも根幹のやり方は変わっていないと私は思います。シンプルなプロセスをステークホルダーの中で共有し徹底することで、変更改善としての大きな効果と安定したPJ運用の両立を行うことができます。

• 変更管理はプロセス化し、徹底することでPJ全体の管理効率を向上させることができる
• プロセスは重厚になりがち、できるだけシンプルにして例外を作らず徹底する
• 変更管理において、改善すべきものはビジネスであり、システムやサービスではない
• 個別の改善にならぬよう、全体最適を認識して管理すること

中間管理職としてスコープ・マネジメントに如何に立ち向かうかも書いていますので、そちらも是非参照してください。
参考；イマドキIT中間管理のためのスコープ・マネジメント


– 11th Aug, 2016 / the 1st edition