この記事の内容
レガシーシステムの刷新、せっかくなら機能の追加をしたいですよね。けれど、それは「茨の道」になることが多いです。理由は、現行の仕様が可視化されていないことが多いからですね。改善しようにも、評価の軸がありません。
そういうときは、まずは「同じものを作る」のが合理的です。仕様が可視化されることで、本当の改善要望（要件）が出てくるものです。
※本記事は、Advent Calendar 2025：「レガシー」を保守したり、刷新したりするにあたり得られた知見・ノウハウ・苦労話 by Works Human Intelligence Advent Calendar 2025 の記事です。
--
レガシーシステムの刷新をするとき、たいてい「今と同じことができればそれでいい」という、どこか消極的な要件からはじまります。
それで、こんなお願いをされます。
- 機能の改善はいらない。
- 今とまったく同じものを作ってほしい。
物理ファイルサーバーをクラウドに移行するなどのインフラ系でも、システムを別のプラットフォームに刷新する開発系でも、共通する傾向だと感じます。私はこの方針が大正解だと思っています。
また、「製品サポートが切れてセキュリティリスクがある」という理由でから、やむを得ず、急いで刷新を進めているお客様もいます。
こんなお願いをされたりします。
- できるだけ早く導入したい。
- とりあえず動くものを作ってほしい。
このケースはだいたい納期まで時間がありません。しかし、新しい改善に手を出せないことがかえって功をそうし、移行自体は大成功を納めたりするのです。
同じものを作りたい人々
私が担当したプロジェクトに、ある申請フォームの刷新があります。そこでも、お客様からは「今とまったく同じものを作ってほしい」と依頼されました。
当時の私は、これをうまく理解できませんでした。
せっかく新しく作り直すのなら、いま不満に感じているデザインを改善したり、新しい機能を追加したりできるわけじゃないですか。なぜそれをしないのかと不思議だったのです。
それで、すでに要件はもらっているにも関わらず、必ず改良の要望があるはずだと思い、「なにか、デザイン変更の要望などはありますか？」と聞いたりしたものです。
結果はいつも同じで、あっさりと否定されるだけでした。
よけいなお世話なのは百も承知でしたが、それで入力フォームの "表記ゆれ" すらも直せないというのは、なにか未完成なものを納品するような気がして、やる気を削がれたものです。
───そのころの私は、自分の開発物に熱意をもっていたために、この「同じもの作る」という踏襲の方針に不満を感じていました。
その後、いくつかの刷新プロジェクトに参加するも、基本方針は「同じものを作る」でした。また、多くのレガシーシステムには "既存システムとの連携要件" もあり、システムやデータ構成を大きく見直す機会は得られませんでした。
しばらくは、モヤモヤした日々を過ごします。
ところが最近になって：①まず、同じものを作ってみる。②あとで気になる部分を改善していく。─── という進め方が、じつはとても合理的であることに気がついたのです。
「まず、同じものを作ってみる」理由
話は変わりますが、私の趣味は料理を作ることです。これまでに 300 食以上をつくり、ようやくそれなりに美味しいといえるものが作れるようになってきました。
─── で、その過程で強く感じたのが、「まず、レシピどおりに作ってみる」ことが上達への近道だということです。
有名な言葉（？）、だと思うのですが、『"レシピに従う" 料理のさしすせそ』があります。アレンジは基本ができてから。そんな心がまえを教えてくれます。
- さ：逆らうな。
- し：省略するな。
- す：好き嫌いするな。
- せ：センスに頼るな。
- そ：そのままでいいんだ。
料理がじょうずなひとに、「どうしたらオリジナルの料理が作れるようになりますか？」と聞くと、「まずはレシピどおりに作れるようになること」とかえってくることが多いそうです。
正解をそのまま再現するステップをふむことで、はじめて「ここは味を足しても大丈夫」「この工程は省略しても問題ない」という判断ができるようになる、という話です。
--
さて、このプロセスは料理にかぎったことではないでしょう。レガシーシステムの刷新も、同じ構造をもっていると思います。
最初から、「せっかくだから、気になっているところ全部を改善しよう！」とすると、よけいな調味料を入れてしまうかも恐れがあります。影響はすくないだろうと想定して排除した機能が、おもわぬ問題を発生させるかもしれません。
こうなると、もはや「システム刷新」の段階ではなくなります。最悪の場合、以前のシステムに戻ることを余儀なくされるかもしれません。これは大損害です。
これは珍しい話ではないと思います。
レガシーシステムの特徴として、当時の開発者がすでにいなかったり、仕様を知っているひとがいなかったり、設計書がどこにあるのか分からなかったりすることがあります。
そのような状態 ─── "システムが何をしているのか" が明確になっていない状態で、機能を改善しようとしても、その改善点を判断・評価する軸がないのです。結果、できあがったものが欠陥だらけというワケです。
そうならぬよう、まずは、新しいプラットフォームで「同じものを作る」ことです。すると、次のことが分かり、改善ポイントや追加機能が自然に浮かびあがるのです。
- 仕様の「核心」はどこなのか
- 変更すると影響が大きい機能はどれか
- 逆に、かんたんに変更できる機能はどれか
- ムダな処理や複雑さはどこにひそんでいるか
全員に「損」がないのでオススメかも
じつは、私は上記のプロセスをじっさいに経験しています。今日はその経験を書きたくて、この記事の執筆を決めました。
「同じもの作る」という踏襲の方針に不満を感じていた、その後 ─── 同じものができたあとに（仕様が整備された途端に）、お客様から追加の改善要望が続々とでてきたのです。
私が気にしていた、しょーもないデザインの修正だけではありません。もっと本質的な改善である、別システムとの連携ですとか、データの利活用ですとか、そういったまったく新しい観点の要望です。
新しいプラットフォームで仕様を可視化したことで、「本当はいままでやりたかったんですけど、古いシステムじゃ無理だと思っていて……でも！今だったらできるのでは？」という希望を引きだしたのだと思います。
─── 私は、お客様の前向きな「改善依頼」に応えるべく、急いでヒアリングシートを作成しました。
今度は "否定される" ことはありませんでした。丁寧に内容をみていただき、「影響範囲」「難易度」「優先度」など、改善・実装にむけた具体的な会話ができるようになったのです。
こんな風にプロジェクトが進み、個人的には "三方よし" であったと思っています。
✅ お客様は、安全にシステム移行ができ、あとでゆっくりと改善を検討できた。
✅ 自社も追加の発注をもらえることになった。プロジェクトが継続した。
✅ 私も納得のいく開発ができた。ﾁｮｯﾄﾜｶﾙ 有識者としての参画だった。
アレンジできるように作るのが大事
─── というわけで、レガシーシステムを刷新するときには、まず最初に「同じものを作る」ことが正解になる場合がある、という話でした。自信をもっては言えませんが、もしかしたら一般化されている方針に通じるところがあるかもしれません。
例えば、経済産業省が公開している「レガシーシステムのモダン化」に関する Web ページには、「企業が取るべき対策」として次のような内容が示されています。
具体的には、ユーザー企業はシステムの可視化と内製化を進め、現行踏襲を見直しつつ標準化対応を検討し、上流人材を育成・確保することが必要です。ベンダー企業はレガシーシステムのモダン化の生産性を向上させる技術の開発と、ユーザー企業の内製化の支援・伴走を行うことが必要です。
出典：経済産業省.「レガシーシステム脱却に向けた「レガシーシステムモダン化委員会総括レポート」を取りまとめました」（2025年5月28日）- https://www.meti.go.jp/press/2025/05/20250528003/20250528003.html
図では、このように表現されています。しかし、これは「現在の仕様が分かっている」という大前提がある気がします。（じっさいは、仕様を知っている人間がいなかったりする）
なので、仕様が分からない場合は、「システムの可視化、製化」を優先することになるのではないかと考えます。「システムの可視化、内製化」は、「標準化対応」「人材の確保、代替技術の開発」と並列のようですが、実はそれは難しくて、というよりできなくって……
むしろ、システムの可視化ができてはじめて話が進むところなのかなと。─── で、それがこの記事でいう「同じものを作る」なのかなぁと思ったりもします。
なにかと急かされるレガシーシステムの刷新ですが、最初の最初が一番肝心なのだと思います。「同じものを作る」にしても、今後の改善に向けて、機能拡張性の高いものになっていなければ後で困ったりしますからね。
そういう心がまえをもって取り組んでいると、導入後に「実はこんなこともやりたくって」という要件がでてきたとしても、「待ってました！」と言わんばかりにスムーズに動きだせるはずです。
以上です。