はじめに
基幹システム刷新プロジェクトが本番稼働を迎えると、多くの現場では安堵とともにプロジェクトチームが解散し、振り返りが十分に行われないまま次の業務に戻っていきます。しかし、大規模な投資を伴うプロジェクトだからこそ、きちんとした振り返り（ポストモーテム）を行い、得られた教訓を組織の資産として残すことには大きな価値があります。振り返りの具体的なやり方を整理します。
なぜ振り返りが省略されやすいのか
基幹刷新プロジェクトは長期間にわたることが多く、本番稼働を迎えた時点で、関係者の多くは疲弊しています。「無事に終わったのだから、もう振り返らなくていい」という空気が自然と生まれやすく、振り返りの優先順位は下がりがちです。また、基幹刷新の本当のゴールは「稼働」ではなく「定着」でも触れたとおり、稼働直後はまだ定着フェーズの対応に追われているため、振り返りに割く余裕がないという事情もあります。
しかし、振り返りを行わないままプロジェクトチームが解散してしまうと、せっかくの経験が組織の知見として蓄積されず、次のプロジェクトで同じ問題を繰り返すことになります。
振り返りで扱うべき3つの観点
① プロジェクト運営面の振り返り
スケジュール・予算の計画と実績の乖離、体制やコミュニケーションの課題など、プロジェクトマネジメントの観点での振り返りです。「ついでにこれも」が積み重なってスコープが崩壊する前に｜変更管理表の作り方で記録してきた変更履歴を見返すことで、どの時点でどんな判断ミスがあったのかを具体的に振り返ることができます。
変更管理表は、noteで配布しています。プロジェクト中の記録を振り返りの材料としてそのまま活用できます。
② 成果物・品質面の振り返り
受け入れテストや本番稼働後に発生した不具合の傾向を分析し、どのフェーズでの見落としが原因だったのかを振り返ります。進捗報告の「大丈夫です」を鵜呑みにしないための4つのチェック方法で触れたような、進捗報告の実態と現場の実態にズレがなかったかも、重要な振り返りポイントです。
③ 組織・人の面の振り返り
現場の巻き込み方、経営層の関与のあり方、DX推進担当者やプロジェクトメンバーの負荷など、組織や人に関わる観点での振り返りです。基幹刷新で「現場の抵抗」が起きる本当の理由で触れたような問題が実際にどの程度発生したか、どう対応したかを振り返ります。
振り返りを「犯人探し」にしないための工夫
振り返りが機能しなくなる最大の原因は、特定の個人や部門の責任を追及する「犯人探し」になってしまうことです。これが起きると、参加者は本音を話さなくなり、振り返りが形骸化します。振り返りの目的はあくまで「次に同じ問題を繰り返さないための教訓を得ること」であると冒頭で明確に共有し、個人の責任追及ではなく、仕組みやプロセスの改善点として議論する姿勢を徹底することが重要です。
振り返りの結果を次のプロジェクトに引き継ぐ
振り返りで得られた教訓は、報告書を作って終わりにするのではなく、組織として今後のプロジェクトで参照できる形で残しておく必要があります。次に類似のプロジェクトを立ち上げる際のキックオフ資料に、過去の振り返り結果を明示的に反映させる運用にしておくと、教訓が実際に活かされやすくなります。
まとめ
基幹刷新プロジェクトの振り返りは、プロジェクト運営面・成果物品質面・組織人の面という3つの観点から行うことが重要です。犯人探しにならないよう目的を明確に共有し、得られた教訓を次のプロジェクトに引き継ぐ仕組みを作ることが、組織としての学習を積み重ねるための鍵になります。
執筆者プロフィール：SIer（元請け）とITコンサルファーム（発注側支援）、両方の立場でプロジェクトに従事（通算9年）。要件定義からベンダーマネジメントまで一貫して対応し、基幹システム刷新・DX推進プロジェクトに多数従事。
コメント