フルスクラッチ

概要と技術的特性

既存の CMS（WordPress 等）やパッケージ、フレームワークなどを一切使わず、ゼロからすべてオリジナルでシステムを開発すること。

デザイン・機能・データベース構造のすべてを自社の思い通りに自由に設計できる反面、開発期間と初期予算が極めて大きく、リリース後の保守・改修コストも跳ね上がる。

現場の核心：「本当に必要か？」の厳格な見極め

最も重要なのは、担当者が「フルスクラッチが本当に必要か」を慎重かつ厳格に判断すること。

すでに世の中にある優れた仕組みをわざわざゼロから作り直す愚行を、現場では「車輪の再発明」と呼ぶ。WordPress などの CMS や既存の SaaS で要件を満たせる場合、フルスクラッチは明らかな「過剰投資」となる。逆に、自社の独自要件が強すぎる場合は、無理に CMS を入れるとカスタマイズの縛りで結局破綻することもあるため、要件の特殊性を冷静に見極める姿勢が基本になる。

実務における採用基準と RFP（提案依頼書）の設計

採用の目安：実務において、中小企業の一般的な Web サイトでフルスクラッチが必要になることは【ほぼ無い】。大規模な独自業務システムや、既存システムとの複雑な連携が必須な大規模 EC、あるいは極度に差別化要素が強いブランドサイトなどに限られる「最後の選択肢」と捉えるとよい。（※現在では大規模 EC でも Shopify などの高機能 SaaS で対応できることが多い）。
RFP での明文化：ベンダー（開発会社）へ要件を出す RFP の段階で、「なぜこの機能はフルスクラッチが必要なのか（＝既存システムでは絶対に代替できない理由）」を明確化しておくと、プロジェクト進行中の判断のブレを防げる。

やってはいけない「現場の落とし穴」と防衛策

業者提案の鵜呑み：開発会社からの「御社の要望を叶えるならフルスクラッチで対応します」という提案をそのまま受け入れ、本来 CMS で数百万で済む案件に数千万円の過剰投資をしてしまう。（※提案を受けたら「なぜ CMS や SaaS で代替できないのか？」を必ず先に問いただすこと）。
ベンダーロックイン（属人化の恐怖）：ゼロから独自の書き方でシステムを作られるため中身がブラックボックス化し、将来別の制作会社へ引き継ごうとしても「誰も触れない」と断られる。結果、作った業者に一生高額な保守費用を払い続ける「ベンダーロックイン（囲い込み）」状態に陥る。

言葉をよく利用する人

Web 担当者(発注側)
プロデューサー
バックエンドエンジニア
経営層

会話上での使用例

サイト構築方針を業者と詰める場面

営業
今回はフルスクラッチでの開発をご提案いたします。
Web担当者
フルスクラッチ が必要だと判断された理由を、具体的に三つほど教えていただけますか。WordPress で対応できる範囲なら、運用のしやすさを考えるとそちらを選びたいんです。
営業
かしこまりました。要件を整理して、CMS で難しい部分を明確にしてお持ちします。

独自機能の要望をプロデューサーと整理する場面

プロデューサー
独自の機能をいろいろ盛り込みたいので、フルスクラッチでしっかり作りたいんですよね。
Web担当者
フルスクラッチ は予算も保守コストも大きいので、最終手段に置きたいです。まずは CMS にプラグインを足してどこまで実現できるか、要望を一つずつ照らして検討しませんか。
プロデューサー
確かに全部ゼロから作る必要はないかもしれません。整理してみましょう。