スクラッチ開発は悪なのか？
スクラッチ開発とは、システムを自社に合わせて柔軟に構築する手法であり、特に業務の独自性が強い企業にとっては有力な選択肢となります。スクラッチ開発はオーダーメイド開発、個別開発ともいわれるスクラッチ開発ですが、延期やコスト超過といった失敗はパッケージやSaas（Software as a Sservice）の導入でも多く、一概にスクラッチ開発の特徴と言えるものではありません。スクラッチ開発にテキストプロジェクトの準備や進行を行う必要があります。
本記事では、クラウド導入やパッケージ導入と比較しながら、「スクラッチ開発」の本質と、その成否を分ける体制設計やRFPの意義、ITベンダーが提案するスクラッチ開発をどう理解し判断するか、向き不向き、求めるシステムを得るために必要な備えについて解説します。
スクラッチ開発とは：「ゼロから作る」は誤解
スクラッチ開発を既製品であるパッケージ製品の導入やSaas導入と対比して言われますが、これは常に正しいとは限りません。
実際の開発現場では、ベンダーはサインインやサインアウトなどどのシステムでも利用する機能、必須項目のチェックなど単純かつどこでも利用する処理、在庫の操作など多くの業界で本質的に同じ機能で実現できる要求などにを、すでに部品化しコピーなどにより再利用できる部品集であるフレームワークや共通部品などを利用します。
この場合、実態は所持している機能の組み合わせと、顧客特有の機能のみ個別に開発する、となり、ある意味「汎用パッケージのカスタマイズ」ともいえます。
本当にゼロから開発するベンダーやベンダー個別の事情で特別な案件のみゼロからの開発になる場合もあります（この場合の費用はベンダー側で負担するのか、見積もりに載せて提示するのかはベンダー次第となります）。
逆に、案件獲得のためにまるでパッケージがあるかのように見せるが、実態がスクラッチ開発という場合もあります。これは、
- 他案件で大きな赤字が出たため機能を流用して開発費用を回収したい
- 案件獲得のために、実績があるかのように見せるため
- なんでもできると思わせないための牽制
などベンダーの内部的な理由によりますが様々なケースがあります。
利用者には、ExcelやPower Pointなどで画面イメージだけ見せて、実際にその該当プログラムがなくてもパッケージ機能の範囲外とする。
不都合な機能に関しては、これで高額な追加費用になる根拠とすることができベンダー都合にあった機能で妥協させることも可能になります。
スクラッチ開発の実体は、ベンダーサイドの内部的な事情で多種多様であり、一般論だけで決めつけることはできません。
パッケージ/SaaS とスクラッチ開発の比較：お金と経験だけでは決まらない
| 比較項目 | パッケージ/SaaS | スクラッチ開発 |
|---|---|---|
| 初期コスト | 一見低く見えるが、カスタマイズ費用が高すぎて結局、スクラッチ開発よりも高くなった | 必要な機能のみに限定すれば実はパッケージよりも安くなる場合も（開発リーダーやSEのスキルやアイデアにより大きく変わる） |
| 導入期間 | 同上 | 同上 |
| 業務適合性 | Fit&Gapでは見えなかった操作性の悪さが問題になり業務負荷が大幅に増える場合、顧客サービスの質低下まで引き起こす場合も | 原則、期間・コストとベンダーのスキル次第で大抵対応可能 |
| 展開性 （技術面からの将来の拡張・連携のしやすさ／ 利用範囲・他業務への横展開のしやすさ） | ベンダーがデータベース、ならびにデータ連携機能を設けていない場合、実現不可能や高額な対応費用が発生する場合も。また、仕組み自体がブラックボックス化されている場合、ベンダーの言い値となるリスクもある（ベンダーロックイン問題） | 同上 |
Saas 導入、パッケージ導入、スクラッチ開発の比較については、関連記事である「デジタル化基礎 – システム形態」もご参照ください
スクラッチ開発にすべき／すべきでないパターンは？
■ スクラッチ開発を選ぶべきケース
スクラッチ開発が適しているのは、次のようなケースです：
- 顧客サービスや競争優位に直結する機能がある：
ビジネスの核となる部分は、他社と同じパッケージで代替すべきではない。ベンダーロックインの影響で自由に改善できなくなると、競争上不利になる。 - 業務に独自性が強く、現行業務を変更できない：
業界固有のプロセスや法令対応、現場の定着済み業務など、パッケージ側を業務に合わせることができない場合。 - カスタマイズ範囲が30％を超える見込みがある：
表面的な変更だけでなく、ワークフローやデータ構造、連携処理まで踏み込むなら、スクラッチのほうが結果的に安定・低コストになることも。 - パッケージの根幹となる設計思想と、自社業務の管理思想が明確に異なる：
例えば、在庫管理の概念が根本的に違うなど、合わせるには無理がある場合。 - ニッチ業種で良質なパッケージ製品が存在しない、かつその業務が重要である：
産業全体が小さい場合、そもそも対応製品がない。しかも社内にとって基幹的なシステムであればスクラッチ以外の選択肢がないことも。
■ スクラッチ開発を避けるべきケース
一方で、スクラッチ開発が適さないケースもあります：
- 業務が標準的で、パッケージに業務がすんなり適合する場合：
会計、人事、給与など、制度に準拠していれば基本的な要件は同じであるため、カスタマイズを避けた導入が可能。特に法規制がたびたび変わり、その対応が必要な場合、パッケージ製品やSaasの場合、ベンダーが無償（通常Saasは自動アップデート）または少額で対応しくれる場合もあります。 - 開発やプロジェクト管理に関して、利用者側にノウハウ・リソースがない：
利用者自身が要件整理やテスト、受け入れまで担う必要があるスクラッチは、準備や体制が不十分な状態では非常に高リスクになります。 - 導入スピードが重視されるが、ベンダーが未熟な場合：
スピード重視のプロジェクトでは、良質なフレームワークや経験豊富なベンダーがあればスクラッチでも十分対応可能だが、それが無い場合はSaaSやローコードの方が適していることもある。 - 社内で運用体制が確立していない、運用していくための工数が限られる場合：
スクラッチはプロジェクト設計や意思決定スキルを求められるため、運営に自信がない場合は慎重に判断すべき。これはシステム稼働後も含まれ、そのシステムを運用し続けることが出来る体制をベンダー、利用者サイドも維持し続ける必要がある。一方パッケージ製品やSaas提供の場合、ベンダーサイドが根幹となる仕様を抑えている（特にパッケージ）ことが多く、本当にいざというときでもベンダーサイドで仕様を抑えることが可能。
このように「何を実現したいか」「どれだけ変えられるか」「誰が主導できるか」によって、スクラッチ開発の是非は大きく変わってきます。 「どれだけ変えられるか」「誰が主導できるか」によって、スクラッチの是非は大きく変わってきます。
本当のリスク：開発方式ではなく「体制」の問題
スクラッチ開発に限らず、システム開発プロジェクトの成否を分けるのは、方式そのものではなく「体制の設計」と「その体制を適切に運営・管理する力」です。
特にスクラッチ開発の場合、以下のような体制的ケイパビリティが求められます：
- 業務要件（システム要求）定義能力：現場から業務要件を正確に引き出し、設計に反映できる能力
- 進行管理能力（PM/PMO）：ベンダーと利用者の間に立ち、計画・進捗・課題をコントロールする力
- 合意形成と意思決定の力：要件の優先順位や仕様変更時に現場と経営の合意を図る機能
- ベンダーマネジメント能力：情報の非対称性を前提とした提案内容の読み解き、指摘、交渉スキル
これらが社内で賄えない場合、外部のITコンサルやPMO支援を導入して「体制そのものの質」を補完することが必要です。
一方、体制を整えたつもりでも、以下のような“見落とし”によって現場では混乱が起こります：
- うわべの要件や形式的な要求の提示にこだわり本来必要な要求を提示できない
- 「使えるかどうか」を現場が実感できない段階での判断強要
- 理想だけを見て実行不可能な要求
- 利用者側の責任範囲や確認タイミングが不明確なまま進行する受け身のベンダー管理
RFPの意義：スクラッチ開発プロジェクト成功のための“設計図”
ベンダーへシステムの提案の依頼を行うためのシステムのRFP（提案依頼書、Request for Proposal）は単なる見積依頼ではなく、プロジェクトを計画的に進めるための“設計図”です。 特にスクラッチ開発では、利用者がベンダーに対して明確な期待と前提条件を伝え、プロジェクトの進め方や判断基準をあらかじめ整理しておく必要があります。
RFPがなければ、「目的が曖昧なまま」「想定の工数や範囲がズレたまま」プロジェクトがスタートし、手戻りや不満、予算超過の原因になります。
■ RFPに含めるべき観点（概要）
- 目的・背景・現行業務との関係性：なぜ導入するのか、どのような課題を解決したいのかを明記
- 要件の優先度と判断基準：Must / Want / Optional を明示し、ベンダーが判断しやすい情報を提供
- 開発～テスト～受入までの進め方と責任分担：誰が何をいつ確認するのか、ベンダーと利用者の役割を明文化
- ベンダー選定・提案比較の視点：提案内容を比較しやすくするための項目・評価基準を記載
これらを押さえたRFPこそが、プロジェクトの“共通言語”となり、全体の成功率を大きく高めます。
■ RFPは「誰に渡すか」によって内容も変える
| 想定ベンダー | RFPの設計方針 |
|---|---|
| 想定ベンダー | 適したRFPの設計方針 |
| 強者ベンダー | 抜けなくすべて文書化し、曖昧さを排除。交渉の余地を減らすことで主導権を維持 |
| 協力・グループ系ベンダー | ベンダー側が進めやすいように柔軟性・余白を残しつつ、前提の共有に注力 |
| 育成を前提とするベンダー | 分かりやすさ・構造化・背景情報の丁寧な提示により、ベンダー理解を支援 |
■ 体裁は立派でも“中身が使えない”RFPが多すぎる
実は、見た目は整っているが、実務で全く使えないRFPが多く存在します。 こうしたRFPの多くは、いわゆる“なんちゃってコンサル”によって作成されたものです。
| 表面上の特徴 | 実際の問題点 |
|---|---|
| 立派なフォーマット | 一見素晴らしく見えるが、実業務と整合せず、現場に確認していない机上の空論である |
| バラ色の未来が描かれているが、リスク分析や実行計画が薄い | 理想像ばかりで、実現可能性が低い |
| システム構成図や用語も専門的 | ベンダーへの“丸投げ”前提で、利用者視点の記述がない |
| システム要求のみ記載されており実効性に欠ける | テスト・受入・運用などプロジェクト推進に関する要求や、非機能などの要求が漏れているため、推進上の課題を押し付けられる・完成したシステムが利用できない |
| 漠然としすぎた要求仕様 | 実現可能性が薄かったり、あえて曖昧にし責任逃れをしている仕様 |
| 要件が過剰に網羅的 | 実現性の検討がされておらず、費用も納期も大幅にブレる |
■ 本当に使えるRFPには“リアルな経験”が必要
- 利用者側で何がボトルネックになるのか
- ベンダーがどこを読み違えるか
- 開発・テスト・運用で誰がどこでつまずくか
これらを把握したRFP作成者が必要です。
スクラッチ開発のための「作れるRFP」を作れる人を選ぶ
■ 外部支援が必要な理由
スクラッチ開発で実際に効果があるシステムの導入や構築を成功に導くRFPは単純な現場要求の整理整頓や、文書の編集・構成力だけでは作れません。 経営戦略、業務設計、システム知識、プロジェクト管理――これらを横断的に理解し、現場の温度感と整合した形で「提案が引き出せる」「リスクが見える」形に落とし込む必要があります。
そのためには、実務経験を持つ支援者の力が必要です。この実務経験者は一般的に、ITコンサルタント、ICTコンサルタント、システムコンサルタントがあたります。ではまた、現在注目されるDXコンサルタントの業務の一部にも含まれます。
IPA情報処理技術者試験区分であるITストラテジスト（→）やITコーディネータ（→）などの資格で規定される業務にも含まれます。
■ 外部専門家選定の注意点
パッケージ導入やSaas導入の場合、そのパッケージ製品やサービスに熟知したコンサルタントの力を借りれば成功に近づくケースが高いですが、スクラッチ開発はゼロからシステムを構築し難易度が大きく異なります。「IT/ICTコンサル」や「システムコンサル」「DXコンサル」の肩書きや資格の有無で、そのコンサルタントが本当に成功に導くことのできるRFPを策定できるかはわかりません。肩書きはどうでもつけることが可能であり、資格も最低限の知識などの有無を問うだけであり、ある程度の知識などがあることを示すのみのためです。
しっかり見抜く必要があります。
| 評価軸 | 見るべきポイント例 |
|---|---|
| 経験の具体性 | 実際にどんなRFPを書き、どう使われたかを確認する |
| 業種・業務への理解 | 自社と似た業種・業務規模での実績があるか （ちょうど経験があるコンサルタントが十分な数いるとは限らない。その場合、類似点の多いプロジェクトへどのような立場で参画していたかの確認が重要） |
| 実務対応力 | ドキュメント作成やベンダー対応など実作業に関わっているか |
| 戦略と整合性 | 経営戦略とのつながりを理解・説明できるか |
| 中立性 | 特定ベンダーに偏らない立場か（販売代理などとの兼業ではないか） |
特に中小企業の場合、「戦略策定」「RFP作成」「ベンダーマネジメント」までを一人で対応せざるを得ないケースが多いため、 それに応えられる人材が必要になります。
まとめ：スクラッチ開発は“体制と準備”で成否が決まる
スクラッチ開発は、単に「高コスト」「高リスク」といった印象で語られることが多いですが、実際には自社の業務や戦略に最適化されたシステムを構築できる有力な選択肢です。しかし、その成功には、以下の要素が不可欠です。
■ 体制設計の重要性
スクラッチ開発を成功させるためには、以下のような体制設計が求められます。
- 要件定義能力：現場から業務要件を正確に引き出し、設計に反映できる能力
- 進行管理能力（PM/PMO）：ベンダーと利用者の間に立ち、計画・進捗・課題をコントロールする力
- 合意形成と意思決定の力：要件の優先順位や仕様変更時に現場と経営の合意を図る機能
- ベンダーマネジメント能力：情報の非対称性を前提とした提案内容の読み解き、指摘、交渉スキル
これらの能力を備えた体制を構築することで、プロジェクトの成功確率を高めることができます。
■ RFPの活用
RFP（提案依頼書）は、プロジェクトの目的や要件を明確に伝えるための重要な文書です。特にスクラッチ開発においては、以下のような内容を含めることで、ベンダーとの認識のズレを防ぎ、プロジェクトの成功に寄与します。
- 目的・背景・現行業務との関係性：なぜ導入するのか、どのような課題を解決したいのかを明記
- 要件の優先度と判断基準：Must / Want / Optional を明示し、ベンダーが判断しやすい情報を提供
- 開発～テスト～受入までの進め方と責任分担：誰が何をいつ確認するのか、ベンダーと利用者の役割を明文化
- ベンダー選定・提案比較の視点：提案内容を比較しやすくするための項目・評価基準を記載
RFPを通じて、プロジェクトの進め方や判断基準をあらかじめ整理しておくことが、スクラッチ開発の成功に直結します。
※本記事の内容に関連したRFPテンプレート、体制構築チェックリストなどの実践資料も今後公開予定です。最新情報をご希望の方は、当サイトの更新情報をご確認ください。