システム刷新は「言語選び」から始めない——作り替える前に見る7つの確認

無理しなくて大丈夫。あなたのペースで書いてみましょう。古いシステムを、このまま直し続けるべきか。
それとも、思い切って作り替えるべきか。

その判断を、開発言語の新しさから始めてしまうと、たいてい話がずれる。
原因は言語の年齢ではなく、更新し続ける仕組みが設計に入っていないことだからだ。

この記事では、刷新か延命かを決める前にそろえたい確認を、7つに整理する。
読了後に持ち帰れるのは、「どの言語が正解か」ではなく、自社がどちらへ進むべきかを話し合うための材料である。

対象は、刷新の要否を判断する開発・DX責任者。会議でそのまま読み上げられる形にしてある。

最初に結論を置く

新しい言語へ乗り換えても、更新しない運用を持ち越せば、数年後に同じ状態へ戻る。
反対に、長く使われている言語でも、現行の版へ追随し、依存関係の管理と自動テストが回っていれば、延命は十分に合理的な選択になる。

つまり問いは「古いか、新しいか」ではない。
「今の土台は、安全に直し続けられる状態か」である。

なぜ「直し続けるのがつらい」状態になるのか

現場で起きていることを分解すると、原因はひとつではない。

まず、更新は事業の成果として見えにくい。
機能追加は売上や契約につながって見えるが、版を上げる作業の成果は「何も起きなかったこと」だ。予算の話し合いでは毎回後ろへ回りやすい。

次に、危うさが事故まで見えない。
借金と違い、利息が数字で届かない。そのため「動いているのだから触らない」が、その時点では合理的な判断に見えてしまう。

そこへ依存関係の広さが重なる。
直接入れた部品だけでなく、その先の部品まで含めると数は大きくなる。長く更新されていない部品がひとつあるだけで、全体を前に進めにくくなる。

最後に、触るための材料が不足する。
自動テストや動作の記録がなければ、直したときに何が壊れるか分からない。分からないから触れない。触れないから、さらに古くなる。

負債の正体は「言語の年齢」ではなく、稼働した年数に、保守が止まっていた期間を掛けたものだと考えている。

これは言語批判ではない。更新を続ける予算、担当、検証の仕組みを、最初から運用に組み込めたかという設計の問題である。

作り替えが前に出るのは、どんなときか

次の3つがそろうと、延命より刷新の検討が現実味を帯びる。

ひとつ目は、使っている版や部品の公式な支援が終わっている、または終わる時期が確定していること。
塞ぐための材料自体が手に入らなければ、運用の工夫だけでは限界がある。

ふたつ目は、脆弱性への対応や障害対応に取られる時間が、本来の開発を継続的に圧迫していること。
一度の大きな事故ではなく、「塞ぐ作業で四半期が終わる」状態が続いているかを見る。

みっつ目は、機能や境界で分けて、少しずつ移れる構造があること。
移行を分けられない一枚岩では、全面刷新の危険が跳ね上がる。分けられるなら、影響の大きい部分から新土台へ寄せる段階移行も選べる。

反対に、更新の仕組みが回り、テストがあり、移行を分けられないなら、結論は急がない方がよい。
「作り替えるべきだ」という空気だけで決めるのが、いちばん危うい。

決める前に見る、7つの確認

責任者の会議で、そのまま読み上げられる形にしておく。

1. 支援の期限：土台と主要な部品について、公式な支援がいつまでか言えるか。すでに終わっているものはないか。
2. 塞ぐ作業の量：過去1年、脆弱性や不具合の対応にどれだけの時間を使ったか。増えているか。
3. 変更の事故率：変更のたびに手戻りや障害が起きていないか。起きるなら、どの境界で起きるか。
4. 安全に触れる材料：自動テスト、検証環境、変更前の状態へ戻す手順があるか。
5. 依存の広さ：その土台にぶら下がるサービスや業務はいくつあるか。波及範囲を数えられるか。
6. 移行を分ける余地：機能やデータの境界で切り分け、段階的に移せるか。
7. 機会費用：塞ぐ作業に取られて、止まっている本来の開発は何か。

「期限が来ている」「分けて移せる」「機会費用が大きい」がそろえば刷新寄り。
「更新が回っている」「テストがある」なら、延命に段階移行を混ぜる方が堅い。

数字が手元にない項目は、推測で埋めない。
「今は測れていない」こと自体が、最初の確認結果である。測れるようにすることから始めるのが順序になる。

では、言語や土台は何を選ぶのか

会議でよく出るこの問いには、「万能の正解はない」と答えるしかない。
ただし、選び方には筋の良し悪しがある。

見るべきは、支援期間の分かりやすさ、安全な更新を小さく当てられるか、部品の保守が続いているか、数年後に保守できる人を確保できるか、そして離れる必要が生じたときにデータを持ち出せるか、である。

用途ごとの現実解は、おおよそこうなる。

・Webの業務システムやSaaS：TypeScriptで画面とAPIの言語をそろえると、小さな体制でも保守が回しやすい。すでにLaravel、Rails、Djangoなどの資産があるなら、現行の版へ追随できているかが先で、言語を替える理由にはなりにくい。
・業務自動化やAI連携：業務の判断そのものはテストできるコード側に置き、連携のつなぎ役と分ける。全てをつなぎ役の側へ寄せると、後から検証しにくくなる。
・長く使う基幹系：支援期間と人材の厚みを優先する。流行より、10年先の保守を想像できるかが大切だ。
・高い信頼性が要る基盤寄りの領域：運用のしやすさや安全性の特性で限定して選ぶ。全領域へ広げると、学習と採用の負担が過大になりやすい。

PHPについても同じ物差しで見たい。
長く使われていることは、それだけで欠点にはならない。問題になるのは、支援の終わった版と更新されていない部品が放置された状態であり、それはどの言語でも起きる。

言語選びより先に決めたい、運用の約束

刷新でも延命でも、次を最初に決めておくと、数年後の景色が変わる。

・版を追い続ける前提で、更新の時間を工程と予算へ最初から入れる
・依存関係を棚卸しし、小さな更新を検証と一緒にこまめに取り込む。大きくためない
・最小限の自動テストと、動作を見る仕組みを先に置く
・最初から細かく分けすぎず、境界のある一つの仕組みとして育てる
・認証、決済、暗号のような横断する機能は、実績のある部品と標準のやり方へ寄せ、自作しない
・捨てる、移す必要が生じたときのために、データを取り出せる形と外部との境界を残す
・壊れない前提をやめ、戻す手順と復旧の練習まで含めて土台と呼ぶ

壊れないものを作る、ではなく、壊れても気づき、切り分け、戻せるものを作る。
AIが古い欠陥を見つけやすくなった今、この差がそのまま対応の速さになる。見つかること自体は、棚卸しが進む機会でもある。

明日からの一歩は、棚卸し表を1枚作ること

いきなり刷新の見積もりを取る必要はない。
まずは主要な土台と部品について、「名前／今の版／支援の期限／担当／最後に更新した日」を1枚に並べてみる。

期限が言えないもの、担当が空欄のものがあれば、そこが議論の入口だ。
そのうえで、塞ぐ作業に使った時間と、止まっている開発を並べる。刷新か延命かの話は、それからで遅くない。

判断に迷う場合は、対象を小さく区切って、延命と段階移行の両方で「次に何を確認すれば決められるか」を先にそろえることを勧める。
結論を急ぐより、決めるための材料をそろえる順序を間違えないことが、結果的にいちばん速い。

この記事の位置づけ

本稿は、特定の製品や言語を推奨するものでも、個別の会社の状況を診断したものでもありません。一般的な判断の枠組みを、開発・DX責任者の会議で使える形に整理した意見です。実際の選定では、自社の支援期限、依存関係、検証環境を確認してから当てはめてください。

似た状況で「刷新か、延命か」の材料のそろえ方に迷う場合は、対象と現在の制約をそろえたうえで相談できます。支援の範囲と進め方は、ITPRODX.comの案内で確認できます。

次回は、移行を分けて進める方法と、最初に切り出す境界の決め方を取り上げる予定です。