システム刷新ロードマップ策定法
システム刷新が遅れる最大の理由は「いつ、何を、どこまでやるか」が曖昧なまま着手してしまうことです。要件は増え、古い仕組みは残り、運用コストだけが膨らむ。打ち手は、先に“価値の地図”を描き、負債を数値化し、90日単位のウェーブ計画で意思決定を細かく刻むこと。ここまで落とし込めれば、巨額の一括投資に頼らず進められます。
価値の地図を先に描く：5枚の合意スライド
技術の前に、事業側が意思決定できる材料を作ります。A3〜5枚で十分です。
- ビジョン：3年後に顧客体験・業務効率がどう変わるか（数値と例で）
- KPI/制約：売上、在庫回転、リードタイム、SLO/セキュリティ、法令・繁忙期の制約
- 現状アーキ図：業務フロー、アプリ/データ/連携の依存関係（更新頻度と障害影響を色分け）
- 投資テーマ：3〜5個（例：在庫精度、データ統合、決済安定化、運用自動化）
- リスクと回避戦略：停止許容時間、データ整合、並行稼働の手当て
初稿はChatGPTやClaude、Geminiで叩き台を作り、現場ヒアリングで現実に寄せます。文書化は速く、合意形成は丁寧に。この順番が肝です。
現行の可視化と負債の数値化：捨てる/残す/伸ばすを決める
棚卸しの最小セット
- アプリごとに「機能・利用部門・変更頻度/月・障害件数・担当者・ライセンス/年・運用工数/月」
- DB/データフロー図に「作成元・参照先・遅延・整合性要件」
- インフラの運用作業と夜間/繁忙期の手当て一覧
2軸マトリクスで優先度を決める
変更頻度（高/低）× 障害影響（大/小）で4象限に配置します。右上（高×大）は最優先で分離や再構築、左下（低×小）は凍結・撤去候補。さらに「年間運用コスト＋障害損失見積（例：平均復旧時間×発生回数×影響金額）」で金額化し、経営と同じ軸で語ります。
移行難易度の見立て
- データ整合：二重書きが可能か、履歴保持の要否、ID正規化の有無
- 切替リスク：停止許容時間、バックアウト手順、段階移行の可否
- 外部接続：連携先との契約・仕様変更リードタイム
結果を「廃止/更改/再構築/維持」の4分類にし、アーキテクチャ決定記録（ADR）として残します。議論の履歴が、後戻りコストを劇的に下げます。
90日ウェーブで組み立てる：テーマ別に小さく届ける
ウェーブの骨子
- 期間：90日（企画2週・実装8週・リリース2週）。四半期末に成果レビュー
- 単位：エピック（価値/指標で定義）。完了条件はユーザ行動やSLOで測る
- 順序：価値/リスク/依存の3点で整列。緊急度はSLO逸脱と障害影響で判断
共存と切替の設計
- ストラングラーパターン：新機能を外付けしてトラフィックを徐々に切替
- データ二重化：一定期間は旧新へ二重書き→差分検証→新主系化→旧凍結
- リリース：カナリア/ブルーグリーン、機能フラグ、バックアウト手順の自動化
予算とリスクの扱い
- 予算はテーマ別のエンベロープで握る（S/M/LのTシャツサイズ＋20％バッファ）
- リスクは「発見→軽減→残存」をバーンダウンで可視化。ゲートで是正判断
- 運用KPI：MTTR、リリース成功率、変更リードタイム、SLO違反回数を固定指標に
設計書・テスト観点の草案はCopilotやChatGPTで補助しつつ、レビュー観点はチェックリスト化。自動テストが通らない変更はウェーブ内で必ず是正し、後送りにしないのがコツです。
身近な企業活用例：地方で20店舗を展開する中堅スーパーの場合
状況：レジ、在庫、発注が分断され、在庫差異と欠品が慢性化。基幹一括更改を計画し、3度延期。要件肥大で予算超過、夜間バッチが落ちるたびに現場が徹夜対応。
失敗の原因：全機能を一度に置き換える前提で、停止時間とデータ移行リスクを過小評価。価値の優先度が曖昧で、開発と現場の会話が合わない。
改善アプローチ：
- 価値の地図作成：KPIを「欠品率3％→1.5％、棚卸工数50％削減、夜間障害月1件以下」に設定。繁忙期（年末・夏）の凍結期間も明記。
- 負債の数値化：変更頻度×影響マトリクスで、発注ロジックと在庫集計を最優先。夜間バッチの復旧時間と売上影響を金額化。
- 90日ウェーブ×3本立て
- W1 在庫単位統合と実在庫API新設（旧システムへ二重書き）
- W2 発注アルゴリズム刷新と需要予測のABテスト（機能フラグで一部店舗のみ）
- W3 レジ連携改修とダッシュボード可視化（SLO監視とアラート導入）
- 運営：ステアリングコミッティは月1、現場マネージャーとPOがKPIで判断。移行手順とチェックリストはClaudeとChatGPTで文案化し、現場が赤入れ。ダッシュボードのプロトはGeminiで作図、テストコード雛形はCopilotで補助。
結果：6カ月で欠品率が3.2％→1.7％、誤発注30％減、夜間障害は四半期で1件に。旧在庫集計の撤去で運用工数は月80時間削減。大規模一括の再延期は回避し、次のウェーブへ投資判断が続けやすくなりました。
まとめ：受託開発と相性が良い進め方
システム刷新は、技術よりも「順番」と「合意形成」を設計する仕事です。価値の地図で目的を定め、負債を数値で並べ、90日ウェーブで小さく届ける。共存と切替の作法を用意し、KPIで是々非々に判断する。外部パートナーが入る受託開発ソリューション事業では、この型に沿って役割とゲートを明確化することで、現場が疲弊せず、成果を四半期ごとに積み上げられます。技術は手段、ロードマップは約束。約束を守れる設計にすることが、刷新成功の最短距離です。
