変更要求に対し常に分析し、真摯に対応
変更要求は常にプロジェクトのメンバーをとことん苦しめ、時に混乱に陥れるものです。……いきなりネガティブな出だしになってしまいましたが、「変更要求をいかに上手く確実に処理していくか」がプロジェクト成功の鍵になることは間違いありません。
変更要求が発生した場合、まず変更による影響を分析し、影響が発生する各種ベースライン、成果物を漏れなく修正する必要があります。
ここがプロジェクトの勝敗を左右すると言っても過言ではありません。
例えば、変更要求によりソースコードは修正しても設計書の修正が漏れてしまった場合、両者の整合性が崩れます。そして、後々になって発見された場合、「他にも絶対ある」と見なされ全面的な見直しを求められてしまいます。こうなるとデスマーチに向かって一直線です。
変更管理の最も難しい点としては「対応フローを複雑にすると多くの時間が奪われる」ところにあります。私が過去に参画していたプロジェクトでも影響分析→成果物の修正→メンバー間クロスチェック→リーダーレビュー→管理者レビュー→顧客レビューと、1つの変更を処理するためにとてつもなく長いステップを踏むようにルール化した（実際は親会社が強引に決めた）結果、実に多くの時間を浪費してしまいました。スケジュールはどんどん遅延し、最後に待っていたのは部長による容赦ない怒号の嵐でした。
何に時間がかかっていたかと言うと資料の印刷・準備、レビュー記録票の作成、レビューアのスケジュール確保等、コアではない部分ばかりとなります。コアとなる作業である成果物の修正にかかる時間は正直なところ全体の1割にも満たない、という感じでした。
さらに、どこかのレビューポイントでNGになると振り出しに戻ります。
当時は紙文化が常識であり、Googleカレンダーのようなツールも浸透していない時代でしたのである程度は致し方無いのですが、これでは最初から自分たちで自分たちの首を絞めるだけでした。当然のことながらプロジェクトは大赤字の大失敗に終わりました。
「変更要求に真摯に対応する」とは、必要最小限の工数で全ての変更要求を迅速かつ的確に処理できるような仕組みを作り、運用に乗せることがゴールであると考えます。方法としてはチケットツールの導入、ペーパレス化の推進、レビューをできるだけ複数件まとめて実施する等が考えられますが、無駄な時間をいかに省けるか?を考える必要があります。ここは手動でやっていることを自動化する、つまり解としては「自動化を実現できるツールを導入する」所に着地します。
例えば、Confluenceを導入してドキュメントのマスタをこちらに統合しますとドキュメントの作成・レビュー・指摘取込を全て同じ場所で実施できますし、レビュー時のコメントがそのままレビュー記録票になります。さらに変更履歴も個別に書く必要もありません。
また、変更要求をjiraやBacklogのチケットで管理すれば発生から完了までの経緯を自動的に蓄積できます。このように、手作業で実施すると面倒かつ作業漏れが発生しやすい部分に対し、いかにツールを適用して自動化するか、ここを提案し、運用していくことがPMOに求められていると考えます。
私自身、変更要求を捌くことに対するベストプラクティスには辿り着けていない状態ですので、引き続きいろいろと経験を積みながら、そしてトライ&エラーを繰り返しながら最適解を探していきたいと思います！