直し続けるか作り直すか｜レガシーシステムの判断軸5つ
また同じ画面で不具合の問い合わせ。原因を追って、似たような場所にもう一つパッチを当てる。 直し終えたあとに、ふと「これ、もう作り直したほうが早いんじゃないか」と思う。でも、誰かに言い出すほどの根拠もないし、作り直すと言ったら自分が全部背負うことになりそうで、結局また次のパッチに戻っていく——。そんな日、ありませんか。
その迷いは、システムを毎日見ているあなただからこそ持てる、大事な感覚です。ただ、感覚のままだと「好き嫌い」や「新しいものを触りたいだけ」と受け取られやすく、判断も説明もできないまま時間だけが過ぎてしまいます。
この記事では、レガシーシステムを「直し続ける」か「作り直す」かを、感覚ではなく5つの問いで整理する進め方を、一緒に見ていきます。
結論：判断は「古いかどうか」ではなく、①止められない期限があるか ②直すたびに壊れていないか ③直せる人がいるか ④業務とシステムがずれていないか ⑤作り直す体力（予算・期間・人）があるかの5つで見ます。そして答えは二択ではなく三択です。直し続ける／部分的に作り替える／作り直す。少人数の現場では多くの場合、「直し続けながら、期限や負担の大きい部分だけを切り出して作り替える」が現実的な落としどころになります。
どのくらいなら作り直すべきか、という正解の数字はありません。システムの規模や会社の事情で答えは変わります。ここで紹介する問いを、自分の現場の言葉に置き換えて使ってください。
何が起きているか：「作り直したい」が判断にならない理由
「作り直したい」という気持ちがあるのに、話が前に進まない。そこにはたいてい、次のような構造があります。あなたの説明が下手だからではありません。
- 比べる物差しがない：「直し続けるコスト」と「作り直すコスト」を同じ物差しで並べていないので、どちらが重いのか誰にも分からない。
- 二択で考えてしまう：「このまま」か「全部作り直し」かの二択だと、作り直しは大きすぎて決められず、結局「このまま」が選ばれ続ける。
- 作り直しの難しさが見えていない：仕様書がないシステムを作り直すには、まず今の動きを全部つかむ必要がある。そこを見積もらずに始めると、途中で「今のシステムと同じことができない」と止まりやすい。
つまり、足りないのは熱意ではなく、判断の材料をそろえて並べる手順です。ここからは、その材料を5つの問いで集めていきます。
直し続けるか作り直すかを決める5つの問い
ひとつずつ、今のシステムに当てはめて答えを書いていきます。答えは「はい／いいえ／分からない」と、理由を一言で十分です。
① 止められない「期限」があるか
まず確認したいのは、自分たちの都合では動かせない期限です。
- OS・言語・ミドルウェア・フレームワークのサポートが終わる、またはすでに終わっていて、セキュリティ更新が届かない。
- 使っている外部サービスや決済・連携先が、古い方式の受け付けを終える予定がある。
- サーバーやハードウェアの保守契約が切れる。
期限があるものは、「直し続ける」を選んでもその部分だけは何かしら手を打つ必要があるということです。どこに期限があるかは、サポート切れ（EOL）のOS・ミドルウェアを棚卸しする手順で洗い出しておくと、この問いにすぐ答えられます。逆に、期限がないなら、急いで作り直す理由は一つ減ります。
② 直すたびに、どこかが壊れていないか
次は、改修や修正にかかる手間が、だんだん重くなっていないかです。
- 小さな修正なのに、影響範囲の調査に何日もかかる。
- 直したら別の場所が壊れる、ということが続いている。
- 同じ種類の障害が、場所を変えて何度も起きる。
ここは感覚ではなく、過去の記録で見るのがおすすめです。問い合わせや改修の記録、障害の記録をざっと振り返って、「去年と今年で、1件あたりの手間は増えているか」を見ます。記録が手元になければ、今日から1行ずつ残しておくだけでも、数か月後には立派な判断材料になります。
③ 直せる人がいるか
3つ目は人の問いです。システムは、直せる人がいてはじめて「直し続ける」ことができます。
- 今のシステムの言語やフレームワークを、あなた以外に触れる人がいるか。
- あなたが休んだり異動したりしたら、誰が直すか。
- 外注先がいる場合、その技術を扱える会社が今後も見つかりそうか。
「自分しか触れない」は、それだけで作り直しの理由になるわけではありません。ドキュメントや引き継ぎで和らげられることも多いからです。ただ、人の問題は期限と同じくらい重い材料として、正直に書いておきましょう。
④ 業務とシステムがずれていないか
4つ目は、システムが今の仕事のやり方に合っているかです。
- システムでできないことを、Excelや手作業で補う運用が増えていないか。
- 使われていない画面や機能が多く、実際に使うのはごく一部になっていないか。
- 業務側から「本当はこうしたい」という声が、何年もたまっていないか。
業務とのずれが大きいなら、作り直すときに今のシステムをそのまま写す必要はない、ということでもあります。使われていない機能は、作り直しの対象から外せます（見極め方は使われていない機能を止めてよいか見極める手順が参考になります）。
⑤ 作り直す「体力」があるか
最後は、作り直しをやり切れるかの問いです。ここを抜かすと、どんなに①〜④がそろっていても途中で止まってしまいます。
- 予算と期間を確保できるか。作り直しの間も、今のシステムの保守は続く。
- 今のシステムの仕様を、作り直しに必要なだけつかめているか（仕様書がなければ、まず現状から仕様を起こすところから）。
- 新旧を並べて動かす期間や、データ移行を計画できるか。
一人運用では、ここがいちばん厳しい問いになりがちです。でも、体力が足りないことは「作り直しをあきらめる」理由ではなく、「全部ではなく、一部から」を選ぶ理由になります。
答えは三択：直し続ける／部分的に作り替える／作り直す
5つの問いに答えたら、選択肢を並べます。ポイントは、真ん中の道を必ず入れることです。
- 直し続ける：期限がなく、修正の手間も増えておらず、直せる人もいる。こういうときは、無理に作り直さず、今のシステムを丁寧に保守していくのがいちばん安全です。古いこと自体は、作り直す理由になりません。
- 一部を作り替える：期限がある部分や、修正のたびに壊れる部分など、負担が集中している場所だけを切り出して新しくする。残りは今のまま動かし続けます。古い仕組みの周りに新しい仕組みを少しずつ育て、置き換えた部分から古いほうを止めていく進め方（ストラングラーパターンと呼ばれます）も、この道の一つです。
- 作り直す：期限が迫っていて部分対応では間に合わない、業務とのずれが大きすぎる、直せる人がいない——といった材料がそろい、かつ⑤の体力も確保できるときの選択です。
少人数の現場では、「直し続けながら、一部を作り替える」が現実的な落としどころになることが多いです。全部を一度に背負わず、効果の大きいところから少しずつ新しくしていけるからです。
具体例：10年動いている受注管理システムの場合
たとえば、社内で10年使われている受注管理システムを、ひとりで保守している担当者がいるとします。5つの問いに答えると、こうなりました。
- ① 期限：はい。動いている言語のバージョンがサポート対象から外れていて、セキュリティ更新が届かない。
- ② 壊れやすさ：一部はい。帳票出力のまわりだけ、直すたびに別の帳票が崩れる。それ以外の画面はほぼ問い合わせがない。
- ③ 人：触れるのは自分だけ。外注先とは数年前に契約が終わっている。
- ④ 業務とのずれ：一部はい。帳票はExcelで手直しして送る運用になっている。受注入力の画面は今も業務に合っている。
- ⑤ 体力：全面作り直しの予算はつかない。ただ、帳票部分くらいなら数か月で作れそう。
並べてみると、答えは「全部作り直す」ではありませんでした。まず言語バージョンを上げる（①への対応）、次に帳票出力だけを切り出して作り替える（②④への対応）、受注入力は直し続ける。そして、③の「自分しか触れない」には、作業のたびに手順と判断理由を残していく。
「全部作り直したい」という気持ちのままでは動けなかったのが、順番のついた3つの仕事に変わりました。言語のバージョンアップについては、古いPHP/言語バージョンの上げ方とリスクの洗い出しで手順を整理しています。
影響：判断を言葉にしておくと、何が変わるか
5つの問いの答えを残しておくと、作り直すかどうかが決まる前から、いくつか変わることがあります。
- 上司や依頼者に説明できる：「古いから作り直したい」ではなく、「期限がこれ、修正の手間がこう増えている、だからまずこの部分から」と、材料を見せて相談できる。
- 「直し続ける」を選んでも、モヤモヤが減る：考えたうえで「今は直し続ける」と決めたなら、それは先送りではなく判断です。次に見直す時期を決めておけば、パッチを当てる毎日にも納得感が持てます。
- 状況の変化に気づける：半年後に同じ問いに答え直すと、「期限が近づいた」「修正の手間が増えた」といった変化が見えて、判断を変えるタイミングを逃しにくくなる。
反対に、判断が頭の中だけにあると、ある日の大きな障害をきっかけに、準備のないまま「急いで作り直す」ことになりがちです。言葉にしておくことは、そうした慌ただしい決断から、未来の自分を守ることにもつながります。
明日やること：5つの問いに1行ずつ答える
いきなり提案書を書く必要はありません。明日できる、いちばん小さな一歩はこれです。
- テキストファイルを1枚開き、名前を「直すか作り直すかメモ」にする。
- 5つの問い（期限／壊れやすさ／人／業務とのずれ／体力）を見出しにして並べる。
- それぞれに「はい・いいえ・分からない」と、理由を一言だけ書く。分からないものは「分からない」のままでかまいません。
- 「はい」が付いた問いについて、システムのどの部分の話かを書き添える（全体か、一部か）。
- 最後に「今の結論」を三択から1つ選び、次に見直す時期（たとえば半年後）を書いておく。
15分もあれば書けます。「分からない」が多くても大丈夫です。分からない項目こそが、次に調べることのリストになります。
「直し続けるか作り直すか」判断チェックリスト
判断を考えるとき・見直すときに当てる項目です。コピーして、さきほどのメモの下に貼っておいてください。全部を最初からそろえる必要はありません。
まず外せない最低ラインはこの3つです。
- 【最低ライン】サポート終了など、自分たちでは動かせない期限を確認したか
- 【最低ライン】「直し続ける・一部を作り替える・作り直す」の三択で考えたか
- 【最低ライン】今の結論と、次に見直す時期を書き残したか
次は、判断の精度を上げるための項目です。慣れてきたら足していきましょう。
- 修正や障害の記録から、手間が増えているかを確かめたか
- 自分以外に直せる人・頼める先がいるかを書き出したか
- Excelや手作業で補っている運用がないかを確認したか
- 使われていない機能を、作り直しの対象から外せるか考えたか
- 作り直す場合の予算・期間・並行稼働・データ移行を見積もったか
- 判断の材料を、上司や依頼者に見せられる形にまとめたか
全部に○が付かなくても大丈夫です。最低ラインの3つがあるだけで、「なんとなく作り直したい」から一歩、判断に近づいています。
よければ、こちらも
直すか作り直すかの判断は、負債の見える化や棚卸しとセットにすると、材料がぐっとそろいやすくなります。
- 技術的負債を「見える化」して優先順位をつける方法：どこに負担が集中しているかを、1枚の台帳で見渡すために。
- サポート切れ（EOL）のOS・ミドルウェアを棚卸しする手順：問い①「期限」に答えるための洗い出しです。
- 動いているが触れないコードに最初の一歩を入れる方法：「直し続ける」を選んだときの、安全な手の入れ方に。
- テストがないコードに手を入れる前にやる安全策：一部を作り替える前の備えとして。
古いシステムを守り続けてきたことは、何も間違っていません。毎日パッチを当ててきたあなたがいたから、そのシステムは今日も業務を支えています。 直し続けるのも、一部を作り替えるのも、作り直すのも、材料をそろえて選んだのなら、どれも立派な判断です。まずは5つの問いに1行ずつ答えるところから、始めてみましょう。
ほかの実務ヒントは記事一覧からどうぞ。保守運用の小さな備えを、メールでも少しずつお届けしています。