老朽化した基幹システムのリプレイスを、全社横断チームで乗り切った事例

※本事例は特定の企業を指すものではなく、よくあるプロジェクト類型をもとに構成した参考ケースです。

背景・課題

ある企業では、20年以上運用してきた基幹システムが老朽化し、保守できる人材も限られている状態でした。大規模なリプレイスが必要でしたが、現場の業務を止めるわけにはいかず、スケジュール・品質・コストのバランスを取りながら進める必要がありました。計画だけを厳密に立てても、途中で形骸化してしまうリスクが大きいプロジェクトでした。

取り組み内容

要件定義に入る前に、影響を受ける各部門からキーパーソンを集めた横断チームを組成しました。プロジェクトを機能単位の小さなフェーズに分割し、まとめてリリースするのではなく段階的にリリースして早期にフィードバックを得る進め方に変更しました。また、週次の進捗共有ミーティングとは別に、リスクだけを扱う短いミーティングを設定し、問題を早期に発見できる体制を作りました。

① 部門横断チームの組成

情報システム部門だけでなく、経理・受発注・物流など実際にシステムを使う各部門からキーパーソンを1〜2名ずつ選出し、専任ではなく既存業務と兼務する形で横断チームを立ち上げました。キックオフでは「何を優先して守るか（業務を止めない／データを失わない／期限を守る、の優先順位）」をチーム全体で合意し、以降の判断基準として明文化しました。意思決定が現場に持ち帰られて止まらないよう、各部門代表に一定範囲の即時判断権限を与え、判断に迷うものだけをプロジェクトオーナーにエスカレーションするルールにしました。

② 機能単位でのフェーズ分割と段階的リリース

全機能を一度に移行するのではなく、影響範囲と業務への緊急度をもとに「マスタ管理」「受発注」「請求」「帳票・レポート」の4つの塊に分割し、優先度の高いものから6〜8週間サイクルで順にリリースしました。各フェーズの本番リリース前には、実際にその業務を担当する現場メンバーによる受け入れテスト期間を1〜2週間設け、机上のテストでは見つからない運用上の違和感を洗い出しました。最初のフェーズは影響範囲が比較的小さい1部門に絞ったパイロット導入とし、そこで得た手順書・問い合わせ対応の型を、以降のフェーズ展開にそのまま再利用しました。

③ リスク専用ミーティングの設置

進捗確認をメインとする週次定例とは別に、リスクだけを扱う30分間のミーティングを週1回設定しました。ここでは新規・更新・完了のリスクを一覧管理し、それぞれを「発生確率」と「影響度」の2軸で簡易にランク付けした上で、対応が必要なものには担当者と次のアクション期限を必ずその場で決めました。進捗会議で問題が発覚してから対応を検討するのではなく、兆候の段階で拾い上げる場を分けたことで、対応の初動が早くなりました。

成果・学び

全体のスケジュールを大きく崩すことなく、段階的に移行を完了できました。現場を巻き込んで進めたことで、リリース後の定着もスムーズでした。このプロジェクトを通じて、「計画通りに進めること」以上に「リスクを早く見つけて次の一手を打つこと」がプロジェクト成功の鍵になる、という学びが得られました。

こうした事例知見の共有や意見交換も、MiraiPMサークルの活動の一つです。皆さんの現場での経験もぜひ教えてください。