レガシーシステム刷新の進め方7ステップ｜脱却が進まない原因と推進体制の作り方

基幹システムの保守費は年々膨らみ、ちょっとした改修にも影響調査で数か月かかる。ベンダーからはサポート終了の案内が届いているのに、刷新の話は「来期に改めて」と先送りされ続けている——この記事を開いた方の多くは、そんな状況の当事者だと思います。先に結論から書くと、レガシーシステム刷新の成否を分けるのは技術選定ではありません。「現行踏襲」という一見安全な前提を疑えるかどうか、そして計画を立て切る推進体制を作れるかどうか。この2つです。プロジェクトの失敗原因は発注側にも受注側にもあるというのが僕の持論ですが、刷新プロジェクトほどそれが露骨に出るテーマも珍しい。本記事では、刷新が進まない3つの原因、モダナイゼーション手法の選び方、進め方の7ステップ、そして推進体制の作り方を、発注側の視点で整理します。

レガシーシステムという言葉に、厳密な定義はありません。ただ実務上は「長年の改修を重ねた結果、中身がブラックボックス化し、変更したくても変更できなくなったシステム」と捉えるのが実態に近いと思っています。COBOLだから、メインフレームだからレガシーなのではない。10年前に構築したオープン系のシステムでも、ドキュメントが実態と乖離し、改修の影響範囲を誰も断言できなくなっていれば、それは立派なレガシーです。

経済産業省が2018年のDXレポートで警鐘を鳴らした「2025年の崖」はよく知られるようになりました。その2025年はもう過ぎましたが、崖は期限ではなく構造の話です。事業の変化速度にシステムが追随できないという構造は、放置した分だけ深くなる。崖の代表例が基幹システムのサポート終了です。だから刷新とは、古いものを新しくする作業ではなく、「変更できないシステム」を「変更し続けられるシステム」に変える営みだと僕は捉えています。この捉え方が、後述する手法選定にもスコープの決め方にも効いてきます。

刷新の必要性は社内の誰も否定しないのに、プロジェクトは一向に立ち上がらない。あるいは立ち上がっても要件定義で迷走する。発注側と受注側の両方に立った経験から言うと、原因は次の3つに集約されると考えています。いずれも根っこには推進体制の不在があります。

原因1：経営と現場で「刷新」の見ている景色が違う

僕は大手外食チェーンのCIOアシスタントとしてIT戦略に関わっていた時期があり、そこで経営と現場の「翻訳」作業がいかに重要かを痛感しました。経営が見ているのは事業構造の変革、現場が受け取るのは新しいツールの導入——同じ言葉なのに見ている景色が違う、という光景です。刷新プロジェクトでも構図は全く同じで、経営の刷新は事業変革、現場の刷新は「今の業務を新しい画面でやること」になりがちです。経営の意図を現場が動ける粒度に分解し、現場の制約を経営が判断できる形に整理する——この翻訳の工程を省略したプロジェクトは、ほぼ例外なく迷走します。目的がすり合わないまま要件定義に入ると、議論の着地点は決まって「とりあえず現行踏襲で」。これが後述する最大の罠への入口になります。

原因2：現行がブラックボックスで、投資判断の材料が作れない

刷新には大きな投資が要ります。ところが現行システムの中身が分からないと、見積もりの根拠が立たない。ベンダーに聞いても「調査しないと分かりません」と返ってくる。根拠の薄い金額では稟議が通らず、「もう少し情報を集めてから」とまた一年が過ぎる。ブラックボックスであること自体が、刷新を止める最大のブレーキとして働くわけです。

原因3：止まれない業務と、変えたくない心理

基幹システムは今日も動いていて、止めるわけにはいかない。情シスは日々の保守運用で手一杯で、刷新の検討に割く体力が残っていない。現場には「今のやり方を変えたくない」という心理も働く。この三つ巴の帰結として選ばれるのが、「今と同じように動けばいいから」という一見もっとも安全に見える要求、つまり現行踏襲です。

刷新と一口に言っても、手法にはグラデーションがあります。代表的なものを発注側の判断軸で整理します。

選び方の軸は、突き詰めると2つです。第一に、業務そのものを変えたいのか、今の業務を維持したいのか。第二に、現行システムのロジックに、作り直してまで引き継ぐ価値があるのか。この2軸で仮置きし、コスト・期間・リスクの制約で補正していくのが現実的な進め方です。

注意したいのは、コード変換ツールで済む「単純なマイグレーション」と、経営がレガシー脱却に期待しているものとのギャップ。経営が求めているのはたいてい「柔軟に変更できるシステム」です。スパゲッティ化したソースを機械変換しても、スパゲッティのまま言語が変わるだけで、柔軟性は手に入りません。手法選定で迷ったら、何のために刷新するのかに立ち返るしかない。なお、ERP導入型リプレースの体制詳細やSAPサポート終了（いわゆる2027年問題）への対応は、本記事では踏み込みません。

このテーマについて、僕のYouTubeチャンネルで、大規模刷新の現場を数多く経験してきたベテランPMの岡田さんと対談しました。岡田さん自身、現行踏襲型の刷新で失敗を経験し、そこから失敗のメカニズムを研究し尽くしてきた方です。対談の冒頭、問題の所在をこう言い切っていました。

format_quote

問題の本質がどこにあるかと言うと、現行の仕様を踏襲するというプロジェクトに対して難易度を見誤っている、ということにあると思うんです。

現行踏襲は、一見簡単そうに見えます。仕様はすでにそこに存在しているのだから、新しく企画するより楽なはずだ、と。僕も最初はそう答えました。でも「現行」とは、物理的にどこにあるのでしょうか。画面は見えても、ボタンを押したときの計算やチェックのロジックは画面からは見えない。では設計書を見ればいいのか。

format_quote

サービスインしてから5年も10年も経って、仕様変更しまくって、障害対応しまくって、ソースコードはぐちゃぐちゃになって——そんなシステムの設計書が、正しく現行を再現できた設計書になっていると思いますか？

結局、現行を正しく表しているのは、いま動いているソースコードだけです。そして数十万から数百万ステップにおよぶコードを隅から隅まで理解している人は、どこにもいない。「現行が分からない」という事実に気づけないこと——それが現行踏襲プロジェクトのつまずきの出発点だと岡田さんは言います。

刷新プロジェクトを狂わせる「2つの神話」

対談で特に唸ったのが、現場のゴーサインを支えてしまう「2つの神話」の話でした。

神話1：有識者がいるから大丈夫。 運用保守を10年担ってきたベテランがいるから現行は分かる、という期待です。しかし大量のソースコードの隅々まで分かる人は実在しないし、仮にいたとしても、その知識を再構築側の技術者に移す手段がありません。口伝えでは何年あっても足りず、ドキュメント化も現実には追いつかない。しかもそういう人ほど現行の保守で引っ張りだこで、稼働が取れないんです。

神話2：現新比較テストで潰せる。 現行と新システムに同じデータを流し、結果が一致すればOKとする方法です。安心材料としては有効ですが、本番から持ってきたデータは過去のデータであり、新システムが処理するのは未来のデータ。データにもオペレーションにも網羅性はなく、月次処理や特殊なデータ条件でだけ出る差異は必ず残ります。岡田さんの言葉を借りれば、こうです。

format_quote

現新比較テストで全部潰しますなんていうベンダーがいたら、ユーザー部門の方は、ちょっと怪しいなと思った方がいい。

処方箋は「現行の再定義」と要件の作り直し

では、どうするか。岡田さんの結論はシビアでした。

format_quote

本当にお客様が期待する現行踏襲はできません。その前提に立たなきゃいけないと思います。

そのうえでの現実解が、ソースコードをベースに現行調査を行い、「現行に近しいドキュメント」を作って発注側とベンダーで合意し、それを鏡として構築していくやり方です。稼働後に「現行と違う」箇所が出ても、合意したドキュメントの通りに作られていればOKとする。何を「現行」とみなすかの握りを、プロジェクトの最初に作ってしまうわけです。

発注側にとって重要なのは、この現行調査に相応の費用と期間がかかると理解し、予算に組み込むこと。「現行があるのに、なぜこんなにかかるのか」と削りたくなる気持ちは分かります。でも、問題への事後対処のコストは事前に手を打つコストの3〜5倍。失敗してから調査し直すより遥かに安いのです。社内の説得には、IPAが公開している刷新の失敗事例やハンドブックといった公的資料も助けになります。

もう一つ。現行踏襲を疑うことは、要件を作り直すチャンスでもあります。10年前の業務を写し取るのではなく、「この業務、そもそもまだ必要か」から問い直す。この「何を作らないか」まで合意する要件定義の進め方こそが、現行踏襲を防ぐ鍵になります。遅延やトラブルは症状にすぎず、真因はスコープのズレにあるというのが僕の経験則で、刷新のスコープを「現行のコピー」に置いた瞬間、そのズレは最初から仕込まれてしまいます。

対談では、失敗のメカニズムをさらに具体的に掘り下げています。動画で詳しく知りたい方は、以下もあわせてご覧ください。

「【必見】システム刷新の落とし穴！本当は危険な「現行踏襲」」

ここまでの論点を、実際の進め方に落とします。

ステップ1：刷新の目的を経営の言葉と現場の言葉で定義する

コスト削減か、事業スピードか、リスク解消か。目的によって選ぶ手法もスコープも変わります。「経営向けの一文」と「現場向けの一文」の両方で説明できて、初めて目的が定義できたと言えます。

ステップ2：現行資産と業務を棚卸しする（現行調査）

設計書ではなく、動いているソースコードと実際の業務を起点に調査します。ここに予算と期間を割けるかどうかが、後続すべての工程の精度を決めます。

ステップ3：あるべき業務と要件を作り直す

現行踏襲を前提にしない。残す業務・変える業務・やめる業務を仕分けし、「何を作らないか」まで言語化します。ここで削れた分だけ、後の工程は軽くなります。

ステップ4：モダナイゼーション手法と移行方式を選定する

前章の2軸で手法を選び、一括移行か段階移行かを決めます。判断に迷ったら、ステップ1の目的に立ち返る。手法が先、目的が後、という逆転が起きたら黄信号です。

ステップ5：計画を立て切る

スコープ・体制・予算・リスクを洗い出し、行き当たりばったりの余地を潰します。僕は、3億円以下くらいの規模なら計画さえ立て切れば大コケはしないと考えています。逆に言えば、システム開発の成功率は3割と言われる状況を作っているのは、計画を立て切らないままの見切り発車です。計画にはコストがかかりますが、その分だけ品質が上がります。

ステップ6：ベンダーを選定し、「現行の定義」を合意する

提案金額だけでなく、現行調査の進め方とテストの考え方を必ず確認します。「現新比較で全部担保します」という説明を鵜呑みにしない。何をもって現行とみなすか、検収の基準をどこに置くかを、契約前に文書で握っておくことがトラブル予防の要です。

ステップ7：段階的に移行し、計画を見直し続ける

プロジェクトマネジメントとは、不確実性を段階的に減らす営みです。ビッグバン移行はできる限り避け、リリース単位を刻み、移行のたびに計画と現実の差分を補正する。合意した「現行の定義」も、鮮度が落ちる前提で定期的に見直します。

7ステップを眺めて気づいた方もいるかもしれません。この大半は、発注側にしかできない仕事です。目的の定義も、業務の仕分けも、現行の定義の合意も、ベンダーには代われない。ところが多くの会社では、これを情シス課長の兼務に載せてしまう。経営・業務部門・情シス・ベンダーの4者を数年がかりで束ねるプロジェクトが、片手間で回るはずがないんです。

だから僕は、刷新プロジェクトには専任の推進機能——PMOを最初に置くことを勧めています。役割は大きく3つ。

• 翻訳：経営の意図を現場が動ける粒度に分解し、現場の制約を経営が判断できる形に整理する（原因1への手当て）
• 合意の管理：「現行の定義」やスコープの合意を文書化し、更新し続ける（現行踏襲の罠への手当て）
• 判断の運営：会議を報告の場ではなく判断の場として設計し、意思決定の停滞を防ぐ（原因2・3への手当て）

開発プロジェクトの7割は上流で決まる、というのが僕の持論です。刷新プロジェクトにおける上流とは、ステップ1〜5のほぼすべて。ここを支える体制への投資は、後工程の火消しに払うコストに比べれば安いものです。刷新の経験者が社内にいないのは、10年に一度のプロジェクトである以上むしろ当然で、その場合は外部のPMO支援で経験を借りるのも現実的な選択肢になります。なお、DX推進組織全体の設計論は本記事のスコープ外とします。

• 刷新が進まない原因は「経営と現場の目的のズレ」「現行のブラックボックス化」「止まれない構造」の3つ
• 手法選定の軸は「業務を変えたいか」「現行ロジックに引き継ぐ価値があるか」の2つ
• 現行踏襲は最も簡単に見えて最も危険な前提。「現行＝ソースコード」と捉え、現行調査に投資する
• 成否の7割は上流で決まる。計画を立て切ってから走り出す
• 経営と現場を翻訳する専任の推進体制（PMO）を最初に作る

レガシーシステム刷新は、システムを入れ替えるプロジェクトではなく、会社が自分たちの業務を定義し直すプロジェクトです。だからこそ重いし、だからこそ効く。「うちは特殊だから」と先送りしてきた時間も、実は崖の一部です。大きな稟議の前に、まず現行調査という小さな一歩から動かしてみてください。

※本記事は一般的な情報提供を目的としたものであり、法的助言ではありません。

---

レガシー刷新の計画段階から、発注側の隣で伴走します

「刷新したいが、何から手をつければいいか分からない」「ベンダーの見積もりが妥当なのか判断できない」「現行踏襲でいけますと言われたが、読んでいて不安になった」——もし心当たりがあるなら、それは計画前夜のサインです。

クリエイティブテックスタジオでは、刷新プロジェクトの目的定義・現行調査の設計・ベンダー選定・推進体制（PMO）の立ち上げまで、発注側の立場で伴走しています。お話を伺った結果、「まだ刷新のタイミングではない」「この規模なら別の進め方がいい」と判断すれば、その旨を正直にお伝えしますし、他社のサービスが適していればそれも含めてお話しします。

刷新は10年に一度の意思決定です。社内に経験者がいないまま抱え込む前に、無料相談で現在地を整理するところから始めてみてください。