スクラッチで作り込んだシステムの再構築──Fit to Standardにできる機能、してはいけない機能

結論の要約

スクラッチの作り込みは、悪ではありません。独自機能が顧客接点で使われている場合、それが競争優位の源泉になっているケースがあるからです。再構築の原則は、競争優位を生んでいる機能はコストをかけてでもスクラッチで作り直し、価値を生んでいない機能はFit to Standardで標準機能に戻すこと。この見分けは、既存顧客の実績データと事業への直感の両方が必要で、AIに聞いても答えは出ません。そして最大の難所は、現行システムの「なぜそう作られているのか(Why)」が記録に残っていないことです。AIはソースコードからWhat(何であるか)を読み取れますが、Why(なぜか)は読めません。Whyを復元できる経験が、再構築の成否を分けます。

作り込み＝悪、ではない

「標準化」の号令のもと、スクラッチの作り込みは負の遺産のように語られがちです。しかし顧客接点で使われている独自機能には、別の顔があります。他社にはない使い勝手、独自の業務との結びつき──その作り込みこそが、顧客に選ばれ続けてきた理由になっているケースが実際にあるのです。

もちろん、価値を生んでいない作り込みも大量にあります。問題は「作り込み全体」を一括りに評価してしまうことです。再構築の出発点は、機能を1つずつ「競争優位を生んでいるか」で仕分けすることにあります。

見分け方──データ半分、直感半分。AIには答えられない

では、どの機能が競争優位の源泉なのか。これは、今の顧客が誰で、その機能が実際にどんな成果に繋がっているかを見ないと分かりません。AIに「この機能は競争優位ですか」と聞いても、答えは出ないのです。AIは自社の顧客と事業の文脈を持っていないからです。

実務的な見分け方は、データドリブン半分、直感半分です。利用ログや既存顧客の実績から「使われているか・成果に繋がっているか」を客観的に見る。同時に、事業を知る人間の「この機能はうちの商売にとって重要だ」という直感を重ねる。担当者の思い込みだけでも、データだけでも偏ります。両方を合わせて初めて、「残す機能」と「標準に戻す機能」のリストができあがります。

仕分けた後の方針はシンプルです。競争優位を生む機能は、コストをかけてでもスクラッチで丁寧に作り直す。価値を生んでいない機能・コストだけがかかっている作り込みは、Fit to Standardで一般的な機能に戻す。全体を標準化するのでも、全体を作り込むのでもなく、機能単位で投資のメリハリをつけるのが正解です。

「全部Fit to Standardでいい」の危険

経営層は物事を大きく捉えるため、「もう全部標準にして、SaaSやパッケージで一気に作り直せばいいじゃないか」という方針が出がちです。コスト削減の文脈では魅力的に聞こえます。

しかし、ここには実例に基づく警告があります。Fit to Standardの号令で簡素なシステムに移行し、大失敗したお客様が実在します。そして、この種の失敗は取り返しがつきません。10年かけて築いてきた顧客接点の価値が、一度の移行で失われると、元には戻せないのです。顧客は「前はできたことができなくなったシステム」から静かに離れていきます。

全部標準化すべきかどうかは、スローガンではなく、自分たちのシステムが何であるかの分析から導くべき結論です。丁寧に見る工程を飛ばした標準化は、コスト削減ではなく価値の削減になりかねません。

最大の難所──「Why」が、どこにも書かれていない

再構築の実務で必ずぶつかる壁があります。現行システムの仕様の「理由」が分からないことです。

設計書が残っていても、そこに書かれているのはWhat──どういう仕様であるか──だけです。エンジニアは設計書にWhatは書きますが、Why──なぜその仕様にしたのか、どんな経緯・背景でその機能が生まれたのか──はほとんど書きません。設計としてはWhatで足りるからです。しかし再構築では、このWhyこそが要否の判断材料になります。理由が分かれば「その前提はもうないから不要」「この理由は今も生きているから残す」と判断できる。理由が分からなければ、怖くて消せない機能が積み上がるだけです。

ここで覚えておいてほしいのが、「AIはWhatを読めるが、Whyは読めない」ということです。ソースコードをAIに解析させれば、「今こうなっている」は分かります。しかし「なぜそうしたのか」はコードのどこにも書かれていません。Whyの復元は、業務の文脈、当時の技術的制約、よくある設計パターンの知識から推測する作業であり、多くのシステムを見てきた経験がものを言う領域です。再構築のパートナーを選ぶときは、「このシステム、なぜこう作られていると思いますか」と聞いてみてください。仮説を立てて語れる会社は、信頼に値します。

まとめ

スクラッチの作り込みには、競争優位を生んでいる機能と、コストだけの機能が混在しています。データ×直感で仕分けし、前者はスクラッチで作り直し、後者は標準へ。「全部標準化」のスローガンには実例に基づく危険があります。そして判断の鍵はWhyの復元です。まずは、現行システムの機能一覧に「この機能がある理由を知っている人は誰か」という欄を作ってみてください。Whyの空白がどれだけあるかが、再構築の難易度をそのまま表します。

作り込まれたシステムの分析・仕分けからご一緒します。会員サイト構築のご相談はこちら

よくある質問

Q1. Fit to Standardにする部分は、どの標準に合わせればいいですか？

再構築後の土台(CMS・パッケージ・SaaS)の標準機能です。土台の選定と仕分けは相互に影響するため、「どの土台なら、残したい機能を無理なく載せられるか」という順番で検討するのが現実的です。

Q2. 当時の担当者が退職していて、Whyを知る人が誰もいません。

珍しくない状況です。その場合は、利用ログ・データの中身・業務ヒアリングからWhyを推測して復元します。精度は落ちますが、経験のある会社なら「この作りは、おそらくこういう事情」という仮説をかなりの確度で立てられます。

Q3. 新しい技術(フレームワーク)への乗り換えも同時にやるべきですか？

再構築はフレームワークを刷新する絶好のタイミングです。技術トレンドは必ず変わるため、再構築時に新しい土台へ移り、以後は少しずつ更新し続けられる設計にしておくと、技術的な負の遺産が溜まりにくくなります。

関連記事

• 増改築を繰り返したシステムは作り直すべきか
• 会員サイトのリニューアルはどこに頼む？