スクラム開発のフルスクラッチ・オーダーメイド開発について

スクラム開発は、変化を前提として短いサイクルで開発を進めるフレームワークであり、独自の価値を段階的に作り込んでいく新規プロダクト開発との相性が抜群です。とりわけ、既製品やパッケージでは実現できない独自要件を、ゼロからオーダーメイドで構築する「フルスクラッチ開発」において、スクラムはその真価を発揮します。要件をすべて固めてから作るのではなく、プロダクトオーナーが要件を「育てながら」プロダクトを作り込んでいけるからです。「フルスクラッチ開発とスクラムはなぜ相性が良いのか」「パッケージやSaaS、ローコードとどう使い分けるのか」「オーダーメイドで作る場合の契約形態や費用感はどうなるのか」「規模はどう見積もるのか」といった疑問は、独自システムの開発を検討する企業担当者が必ず直面する論点です。

本記事では、スクラム開発によるフルスクラッチ・オーダーメイド開発に焦点を当て、フルスクラッチとスクラムの相性、プロダクトオーナーが要件を育てながら作り込む進め方、パッケージ・SaaS・ローコードとの比較、内製化や準委任契約で進めるメリット、ベロシティに基づく規模見積もり、そしてフルスクラッチの費用感や期間目安までを、具体的な数値とともに体系的に解説します。最後までお読みいただくことで、独自プロダクトをスクラムでフルスクラッチ開発する際の判断軸が身に付くはずです。

本テーマに関する全体ガイドは、以下の記事をご覧ください。

▼全体ガイドの記事
・スクラム開発の完全ガイド

フルスクラッチ開発とスクラムの相性

フルスクラッチ開発とは、既存のパッケージソフトやテンプレートに頼らず、システムをゼロから独自に構築する開発スタイルを指します。オーダーメイドで顧客固有の要件を実現できる反面、開発の自由度が高いぶん「何を作るか」を開発の中で固めていく必要があります。ここでスクラムが極めて有効に機能します。スクラムは、開発途中で生じるユーザー要求の変化を柔軟に受け入れることを前提としたフレームワークであり、最初から「何を作るか完全に決まっていない（成果物が未定）」状態からスタートするフルスクラッチ・オーダーメイド開発とは、極めて相性が良いのです。要件が完全に固定されているシステム（仕様変更がほぼ発生しない定型業務システムなど）にはスクラムのメリットは薄れますが、変化が激しく、独自の顧客価値を段階的に生み出していく新規事業やプロダクト開発においては、スクラムのフルスクラッチ開発がその強みを最大限に発揮します。

なぜ両者の相性が良いのか、その理由をもう少し掘り下げてみましょう。フルスクラッチ開発の本質的な難しさは、「正解が分からない中で作り始めなければならない」点にあります。前例のない独自プロダクトでは、最初から完璧な仕様を描くことは不可能で、作って試して初めて「これは違った」「こうすべきだった」と分かることが大半です。ウォーターフォール型でこれをやろうとすると、最初に固めた仕様が現実とズレていた場合、終盤で大規模な手戻りが発生します。一方スクラムは、短いスプリントで動くものを作り、その都度フィードバックを得て方向を修正していくため、「正解を探りながら作る」というフルスクラッチの性質にぴったり合致します。不確実性が高いほどスクラムの価値が高まる、という原則は、まさにフルスクラッチ・オーダーメイド開発において最もよく当てはまります。

スクラムによるフルスクラッチ開発が特に向くのは、次のようなケースです。第一に、新規事業や新規プロダクトの立ち上げです。市場の反応が読めず、作りながら方向性を探る必要があるため、スプリントごとに軌道修正できるスクラムが適しています。第二に、競合との差別化のために独自機能が不可欠なケースです。既製品では実現できない独自の業務フローやユーザー体験を作り込むには、フルスクラッチでオーダーメイド開発する必要があります。第三に、長期的に成長させ続けるプロダクトです。リリース後も継続的に機能を追加・改善していく前提であれば、スクラムの継続開発モデルが効果を発揮します。逆に、要件が明確に固定されており変更がほぼ発生しない定型システムや、短期間・低予算で済ませたい小規模システムでは、後述するパッケージやSaaSの活用の方が合理的な場合もあります。自社のプロダクトがどちらの性質を持つかを見極めることが、開発手法選択の出発点です。

プロダクトオーナーが要件を育てる進め方

フルスクラッチ・オーダーメイド開発をスクラムで進める際の中心人物が、プロダクトオーナー（PO）です。POは、最初から完璧な仕様書を用意するのではなく、開発を進めながら要件を「育てていく」という独特の役割を担います。ここでは、POがどのように要件を育て、プロダクトを作り込んでいくのか、その具体的な進め方を解説します。これはスクラムによるオーダーメイド開発の核心となるプロセスです。

オーダーメイド開発において、プロダクトオーナーはプロダクトの方向性を定め、ビジネス価値や市場ニーズを踏まえて「プロダクトバックログ」を作成し、優先順位を付けていきます。プロダクトバックログとは、これから作る機能や要求を優先度順に並べたリストのことで、フルスクラッチ開発における「作るものの源泉」です。重要なのは、このバックログが固定的な仕様書ではなく、生きたリストである点です。スクラムでは最初から詳細な仕様書を作り込むのではなく、1〜4週間のスプリントごとに動くソフトウェア（インクリメント）を構築し、スプリントレビューなどでステークホルダーからのフィードバックを得ます。POはこのフィードバックをもとに、ユーザーの課題や市場の変化に合わせてバックログを継続的に見直し（リファインメント）、要件をダイナミックに「育てていく」というアプローチをとります。「最初に全部決める」のではなく「作りながら正解に近づけていく」。この進め方が、オーダーメイドで独自価値を生み出すフルスクラッチ開発に最適なのです。

フルスクラッチ開発は自由度が高い反面、特有のリスクも抱えています。最大のデメリットは、「メンバーの技術力格差がプロジェクトに直撃しやすい」という点です。パッケージやローコードのように一定の枠組みが用意されている開発と違い、フルスクラッチではアーキテクチャの設計から実装方針まで、すべてをチームが自ら決めなければなりません。そのため、メンバーの技術力次第で品質に大きなばらつきが生まれます。加えて、「アジャイル＝ドキュメント不要」という誤解から設計書を残さないでいると、属人化が進み、後々の保守や引き継ぎが困難になる（技術的負債となる）リスクが、ローコード開発などよりも高くなります。これらのリスクに対処するには、フルスクラッチであるからこそ、ローコード等以上に厳密な品質管理やルール作りが求められます。具体的には、コードレビューの徹底、「完了の定義（Definition of Done）」への必要なドキュメント作成の組み込み、アーキテクチャ方針の明文化などです。自由度の高さを活かしつつ品質を担保するこのバランスが、スクラムによるフルスクラッチ開発を成功させる条件になります。

パッケージ・SaaS・ローコードとの比較

独自システムを構築する手段は、フルスクラッチだけではありません。パッケージソフト、SaaS、ローコード開発など、既存の基盤を活用する選択肢も存在します。それぞれにメリットとデメリットがあり、どれを選ぶかはプロジェクトの要件次第です。ここでは、フルスクラッチとこれらの手段を比較し、スクラムがどの選択肢とも組み合わせられることを含めて解説します。適切な手段選択が、コストと価値のバランスを最適化します。

パッケージ、SaaS、ローコード開発は、すでに基盤が用意されているため、短期間・低コストでの価値検証（MVP構築など）に向いています。たとえば、業務システムの標準的な機能であれば、SaaSを契約すればすぐに使い始められますし、ローコードツールを使えば限られた工数で動くものを作れます。一方で、これらは用意された機能の範囲内でしか実現できないため、独自の複雑な要件を実現しようとすると制約に突き当たります。「あと一歩、ここを変えたい」という独自要件が、プラットフォームの仕様上できない、という壁にぶつかるのです。これに対してフルスクラッチ（オーダーメイド）開発は、制約がなく自由度が極めて高いのが最大の強みです。どんな独自要件でも、技術的に可能であれば実現できます。ただし前章で述べた通り、自由度が高いぶんメンバーの技術力格差が品質に直結し、属人化のリスクも高いため、厳密な品質管理が必要になります。「短期・低コストだが制約あり」のパッケージ・SaaS・ローコードか、「自由度は高いが品質管理の負荷が大きい」フルスクラッチか。このトレードオフを理解して選択することが重要です。

注目すべきは、スクラム（アジャイル）という進め方は、フルスクラッチ専用のものではないという点です。実際、自治体などのシステム開発において、用意された機能を用いる「ローコード開発」の約3分の2（64.0%）がアジャイル手法で行われているというデータがあります。これは、「アジャイルだからフルスクラッチでなければならない」「ローコードならウォーターフォール」という単純な対応関係はない、ということを示しています。スクラムという進め方は、フルスクラッチでもローコードでも、SaaSのカスタマイズでも適用できる汎用的なフレームワークです。したがって、開発手段（フルスクラッチかローコードか）と開発プロセス（スクラムかウォーターフォールか）は、独立して選択できます。実務的には、「独自性の高いコア部分はフルスクラッチでスクラム開発し、汎用的な周辺機能はSaaSやローコードで素早く組む」というハイブリッドな構成も有力な選択肢になります。重要なのは、自社の要件において「どこに独自性が必要で、どこは既製品で十分か」を見極め、それぞれに最適な手段を割り当てることです。スクラムは、そのいずれの構成でも開発を駆動する共通の進め方として機能します。

契約形態と規模見積もりの考え方

フルスクラッチ・オーダーメイド開発をスクラムで進める場合、契約形態と規模見積もりの考え方が従来型とは異なります。仕様を柔軟に変えながら進めるスクラムでは、成果物を固定する請負契約は使えず、規模見積もりもストーリーポイントとベロシティに基づく独特の手法を用います。ここでは、契約形態の選び方と、スクラムならではの規模見積もりの方法を解説します。これらは予算管理と進捗管理に直結する重要なポイントです。

仕様を柔軟に変更・育成していくフルスクラッチのスクラム開発は、ベンダーが「完成義務」を負う旧来の請負契約では実施不可能です。そこで採用されるのが準委任契約です。準委任契約は、専門人材の能力や稼働時間を調達する契約形態で、これを採用することで、仕様変更のたびに発生していた「契約手続きのやり直し」による管理オーバーヘッドが激減します。フルスクラッチ開発では仕様変更が頻繁に発生するため、この管理コストの削減効果は大きな意味を持ちます。そして、準委任契約以上に「ベスト」とされるのが、自社でエンジニアを直接雇用する内製化です。内製化のメリットは、外部ベンダーとの間に生じがちな「目指すゴールのズレ」がなくなり、プロダクトオーナーと開発チームが完全に同じチームとして協力し合える点にあります。これにより、スクラムが本来想定するパフォーマンスを発揮しやすくなります。フルスクラッチで独自プロダクトを長期的に育てていくのであれば、最終的には内製化を目指すのが、スクラムの価値を最大化する道筋といえます。ただし内製化には採用や育成のコストと時間がかかるため、立ち上げ期は準委任で外部の力を借り、徐々に内製比率を高めていく移行戦略が現実的です。

フルスクラッチ開発は全体像が見えにくくなりがちですが、スクラムには規模と進捗を管理する仕組みが備わっています。スクラムでは、絶対的な「時間（人月）」ではなく、労力や複雑さなどを総合した「ストーリーポイント」を用いた相対見積もりを行います。各機能の重さをポイントで表現し、プロダクトバックログ全体のポイント数で開発規模を把握します。そして、過去のスプリントでチームが完了できたポイント数の平均（ベロシティ）を算出し、「次のスプリントで実現可能な作業量」を決定します。このベロシティを使えば、バックログ全体のポイント数を平均ベロシティで割ることで、全体の完了予測（リリース計画）を立てられます。フルスクラッチ開発の「全体が見えにくい」という弱点を補うため、残りの作業量を可視化する「バーンダウンチャート」を用いて、完了予測をステークホルダーと定期的に共有することが推奨されます。これにより、ゴールが曖昧になりがちなオーダーメイド開発でも、「あとどれくらいで完成しそうか」を実績ベースで把握し続けられます。発注側にとっては、このベロシティとバーンダウンチャートが、フルスクラッチ開発の進捗を透明に把握するための重要な道具になります。

フルスクラッチの費用感と期間目安

フルスクラッチ・オーダーメイド開発をスクラムで進める場合の費用感と期間目安について解説します。スクラムの費用は「チームの人数×月額単価×稼働月数」というバーンレート（月次消費額）の考え方が基本になるため、まずチーム規模と期間の相場、次に各ロールの単価を押さえることで、おおよその総額を見積もれます。ここでは具体的な数値とともに、その算出の考え方を示します。

国内のアジャイル開発プロジェクトの実態データを見ると、開発の規模感がつかめます。国内のアジャイル開発プロジェクトの約8割が「8名以下」の比較的小規模なチームで行われており、開発期間については、その半数が「2〜4か月」というデータがあります。この期間内で、通常1〜4週間単位の短いスプリントを反復していきます。つまり、フルスクラッチのスクラム開発における初回リリースの一つの目安は、「8名以下のチームで2〜4か月」ということになります。もちろん、これはあくまで一つの典型例であり、プロダクトの複雑さや独自要件の多さによって、より長期・大規模になることもあります。重要なのは、スクラムでは全機能を完成させてからリリースするのではなく、コア機能（MVP）を早期にリリースし、その後も継続的にスプリントを回して育てていく点です。したがって、フルスクラッチ開発の費用と期間を考える際は、「初回リリースまでの期間・費用」と「その後の継続開発のランニングコスト」を分けて捉える必要があります。

フルスクラッチのスクラム開発に必要な人材は市場価値が高騰しており、各ロールの月額単価の目安は次の通りです。アジャイル型フルスクラッチ開発のメンバーエンジニアは月額65万〜75万円程度（年収換算で約780万〜900万円）。スクラム経験のあるフルスタックエンジニアは月額70万〜100万円程度。スクラム経験のあるプロジェクトマネージャーは月額80万〜130万円程度。スクラムマスターは月額60万〜90万円程度。アジャイルコーチ（導入支援）は月額80万〜120万円程度です。これらの単価感に、チームの人数を乗じた金額が、1か月あたりのランニングコスト（バーンレート）の目安となります。たとえば、メンバーエンジニア3名（各70万円＝210万円）＋スクラムマスター1名（80万円）という構成であれば、月次のバーンレートは約290万円となり、4か月の開発では約1,160万円が初回リリースまでの概算費用になります。ここにプロダクトオーナー（発注側が担当する場合は社内コスト）やインフラ・ツールのライセンス費用が加わります。フルスクラッチ開発の総額を見積もる際は、こうした人月単価とチーム規模、開発期間を掛け合わせて算出するのが、スクラムにおける費用見積もりの基本的な考え方です。正確な金額は、PoCや準備フェーズを経て初期のベロシティが安定してから、より精度高く見通せるようになります。

まとめ

本記事では、スクラム開発によるフルスクラッチ・オーダーメイド開発について、両者の相性、プロダクトオーナーが要件を育てる進め方、パッケージ・SaaS・ローコードとの比較、契約形態と規模見積もりの考え方、そしてフルスクラッチの費用感と期間目安までを体系的に解説しました。スクラムは「何を作るか完全には決まっていない」状態からスタートするフルスクラッチ開発と極めて相性が良く、プロダクトオーナーがフィードバックを受けながらプロダクトバックログを育て、要件をダイナミックに作り込んでいけるのが最大の強みです。一方で、自由度が高いぶんメンバーの技術力格差や属人化のリスクがあり、ローコード等以上に厳密な品質管理が求められます。契約は請負ではなく準委任が基本で、最終的には内製化がスクラムの価値を最大化します。規模はストーリーポイントとベロシティで見積もり、バーンダウンチャートで進捗を透明化します。費用は人月単価×チーム規模×期間で算出し、国内では8名以下・2〜4か月での初回リリースが一つの目安です。独自プロダクトをスクラムでフルスクラッチ開発する際は、これらの考え方を踏まえ、複数の開発会社に体制と進め方を相談してみることをお勧めします。

▼全体ガイドの記事
・スクラム開発の完全ガイド

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。