はじめに
基幹システム刷新は、構想から本番稼働まで2〜3年、場合によってはそれ以上かかることも珍しくありません。プロジェクトが年度をまたいで続く中で、年度末には来年度の予算申請や体制の見直しが必要になりますが、その時点でプロジェクトの「これまで」がきちんと整理されていないケースは多く見られます。
基幹刷新プロジェクトの振り返り（ポストモーテム）のやり方では、本番稼働後にプロジェクト全体を振り返る方法を整理しました。今回扱うのは、それとは別の、プロジェクトの途中で年に一度行う振り返りです。年次の振り返りは、終わったプロジェクトの教訓を残すためではなく、進行中のプロジェクトを来年度にどう進めるかを判断するために行います。
今回は、基幹刷新プロジェクトの年次振り返りで何を記録すべきかを、発注側の視点で整理します。
なぜ年次の振り返りが必要なのか
複数年にわたるプロジェクトでは、次のような問題が起きやすくなります。
- 当初の目的が薄れる：プロジェクトが長くなるほど、目の前のタスクをこなすことが目的化し、「何のために刷新するのか」が共有されなくなる
- 判断の経緯が分からなくなる：1年前に「なぜその方式を選んだのか」を説明できる人が、異動や退職でいなくなる
- 計画とのズレが常態化する：遅延や予算超過が少しずつ積み重なり、気づいたときには当初計画が形だけのものになっている
- 来年度の予算説明ができない：今年度に何が達成できて、来年度に何にいくら必要なのかを、経営層に根拠をもって説明できない
年次の振り返りは、これらを1年に1度リセットする機会です。プロジェクトの最終的なポストモーテムで「振り返る材料がない」という事態を防ぐ意味でも、途中の記録を年単位で残しておくことには大きな価値があります。
年次振り返りで記録すべき5つの項目
① 目的と成果指標の再確認
まず、プロジェクトの目的と、それを測る成果指標が今も有効かを確認します。基幹刷新の場合、当初は「保守切れ対応」が主目的だったものが、途中で「業務の標準化」や「データ活用基盤の整備」といった目的が加わることがあります。目的が変わったのであれば、それを正式に記録し、成果指標も更新しておく必要があります。
プロジェクト憲章（プロジェクトチャーター）はなぜ必要かで触れたとおり、目的の文書化はプロジェクトの判断の拠り所になります。年次振り返りでは、憲章の内容と現在の実態がずれていないかを点検してください。
② 計画と実績の差分
スケジュール・予算・スコープそれぞれについて、年度初めの計画と年度末の実績を並べて記録します。
- スケジュール：主要マイルストーンの計画日と実績日、遅延があればその原因
- 予算：今年度の予算と執行額、追加費用の発生件数と金額
- スコープ：今年度に追加・削除された機能や対象業務、変更管理表に記録された変更の件数
ここで大切なのは、差分の数字だけでなく「なぜ差分が生じたか」を一緒に残すことです。基幹刷新の予算超過はなぜ起きるのかで整理したような、見落とされがちなコストが原因だったのか、要件の追加だったのかによって、来年度の対策はまったく変わります。
③ 主要な意思決定の記録
年次振り返りで特に意識して残してほしいのが、その年に行った主要な意思決定の記録です。
- 何を決めたのか（例：移行方式を段階移行に決定、パッケージの標準機能に業務を合わせる範囲を決定）
- いつ、誰が決めたのか
- どのような選択肢があり、なぜその選択肢を選んだのか
- 決定の前提条件は何だったのか
基幹刷新では、ビッグバン移行と段階移行の選択や、パッケージ導入かフルスクラッチかといった、後から覆すのが難しい判断が数多くあります。決定事項そのものは議事録に残っていても、「なぜそう決めたか」「何を前提に決めたか」は散逸しがちです。前提条件が崩れたときに判断を見直せるよう、年に一度、意思決定の一覧として整理しておくことをお勧めします。
④ リスク・課題の棚卸し
- 今年度に顕在化したリスクと、その対応結果
- 長期間クローズされていない課題と、その理由
- 来年度に新たに想定されるリスク（例：データ移行の本番リハーサル、現場への展開、保守担当者の退職など）
長期間放置された課題は、それ自体がプロジェクトの弱点を示しています。「誰も持ち主がいない課題」「判断待ちのまま止まっている課題」が残っていれば、年度の区切りでオーナーと期限を決め直してください。
⑤ 体制と関係者の変化
1年の間に、プロジェクトの体制は少しずつ変わっていきます。
- 発注側メンバーの異動・増減
- ベンダー側のキーパーソンの交代
- 経営層の担当役員の変更、業務部門の責任者の変更
体制の変化は、プロジェクトの知識が失われるリスクと直結します。経営層の関わり方が担当役員の交代で変わってしまうこともあります。誰が抜けて、その人が持っていた知識や判断の経緯がどこに引き継がれたのかを、年次で確認しておくことが重要です。
振り返りの進め方
年次振り返りは、大がかりなイベントにする必要はありません。実務では、次のような流れで進めると負担が少なく済みます。
1. PMO・発注側事務局が材料を集める：管理表、議事録、予算執行データから、上記5項目の事実部分を整理する
2. 関係者で半日程度のレビューを行う：発注側のPM・業務部門の代表・ベンダーの責任者が集まり、事実の確認と「なぜそうなったか」を議論する
3. 振り返り結果を1つの文書にまとめる：5項目を数ページ程度にまとめ、プロジェクトの共有フォルダに年度ごとに保存する
4. 来年度計画に反映する：振り返りで出た課題と対策を、来年度のスケジュール・予算・体制計画に反映する
振り返りを「犯人探し」にしないという原則は、年次の振り返りでも同じです。特に進行中のプロジェクトでは、メンバーがこの先も一緒に仕事を続けるため、個人の責任追及ではなく仕組みの改善に焦点を当てることが欠かせません。
記録は「次の担当者」が読める形で残す
年次振り返りの記録を作るときに意識してほしいのは、「来年このプロジェクトに初めて参加する人が読んで理解できるか」という基準です。関係者だけに通じる略語や、背景説明のない決定事項の羅列では、担当者が替わったときに役に立ちません。
現行システムの「ブラックボックス化」を防ぐにはで触れたブラックボックス化は、システムだけでなくプロジェクトそのものにも起こります。年次の記録が積み重なっていれば、プロジェクトの経緯そのものがブラックボックスになることを防げますし、最終的な本番稼働後のポストモーテムでも、年ごとの記録をそのまま振り返りの材料として使えます。
まとめ
基幹刷新プロジェクトの年次振り返りは、終わったプロジェクトを総括するポストモーテムとは異なり、進行中のプロジェクトを来年度にどう進めるかを判断するためのものです。目的と成果指標の再確認、計画と実績の差分、主要な意思決定、リスク・課題の棚卸し、体制の変化という5つの項目を、年に一度、次の担当者が読める形で記録しておくことで、来年度の予算説明や計画の見直しに根拠をもって臨めるようになります。
執筆者プロフィール：SIer（元請け）とITコンサルファーム（発注側支援）、両方の立場でプロジェクトに従事（通算9年）。要件定義からベンダーマネジメントまで一貫して対応し、基幹システム刷新・DX推進プロジェクトに多数従事。
コメント