Helper CTO シリーズ 25｜なぜ一部のシステムには「作り直したほうが安い」とお勧めするのか

「保守会社なのに、なぜ作り直せと言うんですか。」健診レポートに「作り直したほうが安く済みます」と書いたとき、私たちが一番よく受ける反応がこれです。私たちもこの一文は書きたくありません。当初かけた費用の大部分を手放すことになりますし、私たちにとっても引き継ぎ案件が一件減ることを意味します。お客様がカモにされたわけではなく、修正するより作り直したほうが安いシステムに出会っただけです。以下、判断基準となる4つをすべて公開します。

「作り直しをお勧めします」は健診レポートで一番書きにくい一文

健診の結論は3種類しかありません。そのまま引き継げる、整理してから引き継ぐ、作り直したほうが安く済む、のいずれかです。3つ目を書く前に、まず3つの偽の警報を除外します。

• 単に「他人のコードが気に入らない」だけ——どのエンジニアにもある癖で、それは理由になりません。
• 差がわずかなだけ——差がはっきりしないときは修正のほうに寄せます。リスクを抑えやすいからです。
• 単に古いだけ——何年か使われているからといって替える理由にはなりません。今も動いているなら、それだけの価値があります。

本当の理由はただ一つです。修正を続けたときの総コストが、作り直しより明らかに高いこと。ここでの「明らか」とは、細かく計算しなくても分かるほど差が大きいという意味です。救うべきか作り直すべきかの4つの判断基準の記事は自分で判断するための内容で、本記事では私たちが何を見ているかを解説します。

修正か作り直しか：私たちが見る4つの場所

左に寄るほど修正、右に寄るほど作り直しに傾きます。

すべてが右に寄る必要はなく、2つ以上が右に寄れば「作り直したほうが安く済む」と書きます。

「作り直し」に行き着く4つの状況

状況1：誰も理解できず、ドキュメントも補えない。理解できないこと自体は問題ではなく、問題は読み終えても全体像がつかめないことです。

• コードの中に用途不明の要素が大量にある。
• 同じことが3箇所で3通りのやり方で行われている。
• ある箇所を直すと別の場所でエラーが出るのに、なぜかを説明する記録がない。

状況2：データ構造が持ちこたえられない。データ構造とはデータベース内の「データの入れ方」の設計のことで、持ちこたえられない状態は見分けやすいです。

• 一つの項目に複数の意味が詰め込まれていて、誰も触れられない。
• 本来分けるべきデータがくっついていて、本来つなげるべきデータは人力で突き合わせている。
• 機能を追加するたびに元の設計を迂回する必要があり、迂回が増えるほどシステム全体が脆くなる。

状況3：修正費用が作り直しを明らかに上回る。健診の際、私たちは2つの数字を同時に見積もります。並べればひと目で分かることがほとんどです。

• 正常に公開できる状態まで整理するのに必要な投入の合計。
• 同じ機能範囲を作り直した場合の投入の合計。
• 差が大きいシステムは、たいてい設計されたのではなく機能を継ぎ足して出来上がっています。

外注の見積もりがなぜこんなに違うのかの記事で扱った差が、ここでは目に見える数字として現れます。

状況4：基盤技術がすでにメンテナンスされていない。システムは他者が作ったツールの上に構築されており、そのツール自体も作者によって終了することがあります。

• セキュリティの脆弱性が見つかっても、もう誰も修正してくれない。
• 新しいサーバー環境と互換性がなくなっても、誰も対応してくれない。
• それを使えるエンジニアが市場でどんどん減り、探すのがますます高くつく。

この場合の「修正」は基盤ごと入れ替えることを意味し、工数は作り直しとほぼ同じ、さらに「古いやり方との互換性を保つ」という制約まで加わります。

作り直すとき、何を残すべきか

作り直しを勧めることはゼロに戻すことではありません。次の3つは必ず残すべきです。

• データ：顧客、注文、履歴。まず完全にエクスポートして移行できるかを確認することが最初の一歩です。
• プロセス：旧システムには会社の実際の運用方法が隠れています。何を承認が必要とするか、何が例外か、先に書き出しておきます。
• アカウントとドメイン：URL、サーバー、外部サービスのアカウントは、作り直す前に御社名義であることを確認しておく必要があります。

アカウントは一番後回しにされがちです。元の制作会社が見つからないときの取り戻し方の記事で触れた通り、取り戻せていないと新システムの公開日に詰まってしまいます。

作り直しをお勧めすること＝私たちに依頼しなければならないわけではない

最後にはっきりさせておきます。レポートに「作り直しをお勧めします」と書かれていても、私たちに依頼する必要はありません。

• 健診は有料で、システム規模に応じて見積もり、契約縛りはありません。
• レポートは御社のものです。受け取った後で協力するかどうかを決めてください。
• レポートの内容は網羅的です。何を見たか、なぜその結論に至ったか、作り直す際に何を残すべきか。
• このレポートを持って、どの会社に相談しても構いません。誰が見ても通用する内容です。

理由は単純です。私たちが案件を取りたいから作り直しを勧めているのではと疑われるなら、健診そのものの意味がなくなってしまいます。健診では実際に何を見ているのかの記事で、見ている内容をすべて公開しているのも、検証に耐えられるようにするためです。

こうした場面でNerdtechnic（恩梯科技）が行う4つのこと

• まず結論と理由をお伝えします。専門用語で包み込まず、代わりに決めることもしません。
• レポートには3種類のうちどれに当たるか、次の一歩にそれぞれ何がかかるかを明記します。
• 作り直す場合、まずデータとプロセスを保護します。新しい画面を描くことから始めません。
• 誰に依頼するとしても、ドキュメントと記録は御社のものです。ブラックボックスにはなりません。

一番高くつくのは作り直しではなく、直らないシステムを直し続けることです。

作り直しをお勧めするのは一番言い出しにくい結論ですが、はっきり伝えることこそシステムを引き継ぐ者が持つべき姿勢です。Nerdtechnic（恩梯科技）は Helper CTO として、こうしたシステムを引き継ぐ、あるいは再構築をお手伝いします——社内の技術責任者のような存在ですが、御社の正社員ではありません。最初のステップは60分のシステム健診です。コードさえ見せていただければよく、本番環境のアカウントやパスワードは不要で、3～5営業日以内に読んで分かる1ページのレポートをお渡しします。何度も修正しているのにまだ調子が悪いシステムをお持ちなら、まずそれがもう一度直す価値があるかどうかを教えてもらってください。Helper CTO：システム保守プラン