Helper CTO シリーズ 05｜誰も触りたがらないシステム、残すべきか作り直すべきか：4 つの判断点

「このシステム、もう誰も触りたがらないんです。いっそ作り直そうかと思っています」。こう話す経営者は、たいてい二種類の人にそれぞれ一度ずつ説得されています。ひとつは「これは触ってはいけない、触ったら壊れる」という声、もうひとつは「もう手遅れです、うちで作り直しましょう」という声です。どちらも正しい可能性がありますし、どちらも話している人にとって都合がいいだけの可能性もあります。判断を誤れば、1 年分の予算が間違った方向に使われてしまいます。判断できないのではなく、判断するための材料が手元にないだけです。以下の 4 つの判断点は、私たちがシステムを見るときに実際に確認している問いです。

「作り直すべきか」を急いで問わない

「作り直し」はすっきり聞こえますが、見落とされがちな 3 つのコストがあります。

• 作り直している間も旧システムは誰かが見続ける必要があり、両方に費用がかかります。
• 途中で、旧フローの中に理由の分からない特殊処理が何十個も見つかります。
• データを移す段階になって初めて、想定していた形式と違うことがわかります。

見積もりが 30 万と 300 万に分かれる理由という記事で、見積もりの差は要件の掘り下げ方の深さから生まれると説明しました。「今と同じだがもっと良いもの」を作り直す場合は、さらに要件を掘り下げにくくなります。だからこそ順序を逆にする必要があります。まず状況を判断し、それから作り直すかどうかを決めます。

4 つの判断点、まず表で傾向を見る

4 つの問い、2 つの方向性。まず表で傾向をつかんでください。

4 つとも同じ方向に傾けば、それが答えです。2 対 2 なら、さらに詳しく見る必要があります。

判断点一・二：読める状態か、取り出せるか

読める状態とは、プログラミング言語が読めるという意味ではなく、「ここを変えるとどこに影響するか」に誰かが答えられる状態のことです。次を確認します。

• 誰がいつ何を変更したか確認できる変更履歴があるか。
• 同じ種類のものが同じ場所にまとまっているか、命名から意味が読み取れるか。
• 使われている技術がまだ保守されているか、扱える人材が見つかるか。

取り出せるかはさらに重要です。システムは作り直せますが、データはやり直せません。コードは単なる入れ物にすぎないからです。次を確認します。

• データが標準的なデータベースにあり、完全にエクスポートできるか。
• 同じ種類のデータがデータベース、表計算、外部サービスの 3 か所に散らばっていないか。
• コード内のルールに頼らないと読み解けない項目がないか。

エンジニアが辞めたばかりで、まだ材料が揃っていない場合は、まずエンジニア退職後に先に取り戻すべき 12 項目を確認して材料を揃えてください。そうしないと、この判断自体ができません。

判断点三・四：もつかどうか、本当に同じ計算か

アーキテクチャとはこのシステムの骨格であり、何人・どれだけのデータ量を想定して設計されたかです。この問いに答えられるのは経営者だけです。今後 2 年間、会社がどこへ向かうかを知っているのは経営者しかいないからです。

• もつ場合：今後起きるのは量の増加だけです。項目の追加、レポートの追加、決済方法の追加といった程度です。
• もたない場合：今の設計にまったく存在しないことをやる必要がある場合です。例えば社内利用から顧客向けに開放するといった変化です。
• 方向性がずれた時点で、無理に追加する機能はどれも割高になり、追加するほど不安定になっていきます。

4 つめの判断点は最も計算を誤りやすいものです。よくある計算は「修正には X かかる、作り直しには Y かかる、Y のほうが大きいから修正しよう」というものですが、この計算には 4 つの抜けがあります。

• 修正後の毎月の保守コスト。誰も読めないシステムは、直した後も変更のたびに割高なままです。
• 修正の過程で見つかる、見積もりに入っていなかった問題の数。古いシステムの見積もりはほぼ必ず低く見積もられます。
• 作り直し期間の二重コスト。旧システムは動かし続け、新システムは開発する必要があり、両方に人員が必要です。
• 作り直しはゼロからではありません。データ、業務フロー、検証済みのビジネスロジックは引き継げます。

これらを計算に戻してから比較してください。単発の外注がなぜ失敗するのかという記事で説明したとおり、本当に高くつくのは一度の見積もりではなく、毎回ゼロからやり直すことです。

健診の結論は 3 通りしかない

4 つの判断点を確認し終えると、答えはたいてい健診レポートの 3 つの結論のいずれかに落ち着きます。

• そのまま引き継げる：最も多いパターンです。「誰も触りたがらない」は、実は誰も見ていないだけということがほとんどです。
• 先に整理してから引き継ぐ：コード自体は問題ないものの、バックアップ・デプロイ・ドキュメントが欠けていて先に補う必要があり、この部分は状況に応じて別途見積もります。
• 作り直しを勧める：率直にお伝えし、作り直す際に必ず残すべきものもお伝えします。

健診は 60 分のオンラインミーティングで、コードを見せていただくだけでよく、3～5 営業日以内に 1 ページのレポートをお渡しします。費用はシステムの規模に応じて見積もり、契約の縛りはありません。この判断を誰が担うべきかについてはHelper CTO とはという記事で解説しています。

Nerdtechnic（恩梯科技）がこの判断をする際の 3 つの原則

• 答えを先に決めない：私たちが受けるのは長期的な関係であり、単発の作り直し案件ではないため、作り直しへ誘導する動機がありません。
• まず見てから話す：健診なしに見積もりを求める依頼は受けません。見てから初めて費用の話をする資格があると考えています。
• レポートは御社のもの：契約の縛りはなく、それを持って他社に相談していただいても構いません。契約終了時にはドキュメントと記録も同様にお渡しします。

この判断を一度正しく行うことで、その後何年分もの費用を節約できます。

残すべきか作り直すべきかは、私たちが Helper CTO として最もよく聞かれる最初の問いです。会社の技術責任者のような存在でありながら御社の社員ではなく、判断が終われば同じチームが引き継ぎまたは整理を行います。最初の一歩は 60 分のシステム健診です。コードを見せていただくだけでよく、本番環境のアカウント情報は不要です。3～5 営業日以内に、3 つの結論のうちどれに当たるかを明記した 1 ページのレポートをお渡しします。誰も触りたがらず、かといって作り直す踏ん切りもつかないシステムがあれば、まずはこちらからどうぞ：Helper CTO：システム保守プラン。