「このシステム、もう誰も触りたがらないんです。いっそ作り直そうかと思っています」。こう話す経営者は、たいてい二種類の人にそれぞれ一度ずつ説得されています。ひとつは「これは触ってはいけない、触ったら壊れる」という声、もうひとつは「もう手遅れです、うちで作り直しましょう」という声です。どちらも正しい可能性がありますし、どちらも話している人にとって都合がいいだけの可能性もあります。判断を誤れば、1 年分の予算が間違った方向に使われてしまいます。判断できないのではなく、判断するための材料が手元にないだけです。以下の 4 つの判断点は、私たちがシステムを見るときに実際に確認している問いです。
「作り直し」はすっきり聞こえますが、見落とされがちな 3 つのコストがあります。
見積もりが 30 万と 300 万に分かれる理由という記事で、見積もりの差は要件の掘り下げ方の深さから生まれると説明しました。「今と同じだがもっと良いもの」を作り直す場合は、さらに要件を掘り下げにくくなります。だからこそ順序を逆にする必要があります。まず状況を判断し、それから作り直すかどうかを決めます。
4 つの問い、2 つの方向性。まず表で傾向をつかんでください。
| 判断点 | 残す方向 | 作り直す方向 |
|---|---|---|
| まだ読める状態か | 変更履歴があり、構造に規則性がある | 圧縮ファイル 1 つだけで、技術を扱える人がいない |
| データを取り出せるか | 標準的なデータベースにあり、完全にエクスポートできる | 複数の場所に散在し、1 つの項目が複数の用途に使われている |
| アーキテクチャは 2 年もつか | 必要なのは量の増加や細部の追加だけ | 今まったく存在しないことをやる必要がある |
| 修正と作り直しは同じ計算か | 修正後、毎月の保守コストが明らかに下がる | 修正後も変更のたびに同じくらい費用がかかる |
4 つとも同じ方向に傾けば、それが答えです。2 対 2 なら、さらに詳しく見る必要があります。
読める状態とは、プログラミング言語が読めるという意味ではなく、「ここを変えるとどこに影響するか」に誰かが答えられる状態のことです。次を確認します。
取り出せるかはさらに重要です。システムは作り直せますが、データはやり直せません。コードは単なる入れ物にすぎないからです。次を確認します。
エンジニアが辞めたばかりで、まだ材料が揃っていない場合は、まずエンジニア退職後に先に取り戻すべき 12 項目を確認して材料を揃えてください。そうしないと、この判断自体ができません。
アーキテクチャとはこのシステムの骨格であり、何人・どれだけのデータ量を想定して設計されたかです。この問いに答えられるのは経営者だけです。今後 2 年間、会社がどこへ向かうかを知っているのは経営者しかいないからです。
4 つめの判断点は最も計算を誤りやすいものです。よくある計算は「修正には X かかる、作り直しには Y かかる、Y のほうが大きいから修正しよう」というものですが、この計算には 4 つの抜けがあります。
これらを計算に戻してから比較してください。単発の外注がなぜ失敗するのかという記事で説明したとおり、本当に高くつくのは一度の見積もりではなく、毎回ゼロからやり直すことです。
4 つの判断点を確認し終えると、答えはたいてい健診レポートの 3 つの結論のいずれかに落ち着きます。
健診は 60 分のオンラインミーティングで、コードを見せていただくだけでよく、3～5 営業日以内に 1 ページのレポートをお渡しします。費用はシステムの規模に応じて見積もり、契約の縛りはありません。この判断を誰が担うべきかについてはHelper CTO とはという記事で解説しています。
この判断を一度正しく行うことで、その後何年分もの費用を節約できます。
残すべきか作り直すべきかは、私たちが Helper CTO として最もよく聞かれる最初の問いです。会社の技術責任者のような存在でありながら御社の社員ではなく、判断が終われば同じチームが引き継ぎまたは整理を行います。最初の一歩は 60 分のシステム健診です。コードを見せていただくだけでよく、本番環境のアカウント情報は不要です。3～5 営業日以内に、3 つの結論のうちどれに当たるかを明記した 1 ページのレポートをお渡しします。誰も触りたがらず、かといって作り直す踏ん切りもつかないシステムがあれば、まずはこちらからどうぞ：Helper CTO：システム保守プラン。
技術共有
エンジニアが退職してもシステムは通常どおり動き続けるため、経営者はそのままにしておきがちです。しかし証明書の期限切れやサーバーの引き落とし失敗、脆弱性の悪用が起きて初めて、パスワードすら会社の手元にないことに気づきます。本記事では先に取り戻すべき 12 項目、連絡が取れないときの 3 つの対処順序、取り戻した直後にやるべきことを解説します。
技術共有
多くのブランドはチャネルごとに別々のAIボットを設置し、音声・チャット・CRMがかみ合わず、同じ顧客がつながりのない断片に分割されています。本記事では、CXMのチャネル横断統合を三層——統一顧客ビュー、システム統合、チャネル横断のオーケストレーション——として実データとともに読み解き、あらゆる接点が同一の顧客レコードの上に成り立つ仕組みを示します。
技術共有
会話が長くなるほど AI はなぜ高く、そして散漫になるのでしょうか。本稿は Chroma や Anthropic などの最新研究データをもとに、スライディングウィンドウ、要約圧縮（compaction）、分割による外部退避、重要情報のピン留めという四つの戦略と、その組み合わせ方を解き明かします。
サポートが必要ですか？
ここをクリックしてお問い合わせください！
