アジャイルとフルスクラッチは、不確実性と要件の変化に向き合う点で相性が良く、独自システムを反復で育てる進め方になります。一方、要件が最初から固まっている案件では、必ずしも最善ではありません。
▼全体ガイドの記事
・アジャイル開発の完全ガイド
Webサービス開発の種類・工程・費用・会社選定までの全体像については、無料ホワイトペーパー「Webサービス開発の完全ガイドブック」で詳しく解説しています。
アジャイルとフルスクラッチの高い親和性
アジャイルとフルスクラッチが向き合う不確実性の性質は共通しています。新規プロダクトやスタートアップ、いわゆる「0から1を生み出す」開発では、開始時に作るものが決まらない場合があります。さらに、作るものの姿や最終コストは、市場の反応を見ながら明らかになります。
最初に仕様をすべて固めるウォーターフォール型では、進行中に前提が崩れ、大きな手戻りが起きがちです。一方、アジャイルは、作りながら学び、短いサイクルでフィードバックを得て計画を柔軟に見直す適応主義の考え方です。また、アジャイル開発には、スクラム、カンバン、エクストリーム・プログラミング（XP）などの手法があります。
アジャイルが向かないフルスクラッチ
アジャイルとフルスクラッチは相性が良い一方、すべての案件で最適とは限りません。最初から作るものが決まり、要件変更の余地がほとんどないシステムでは、アジャイルの強みが生きにくくなります。
要件が固定的なら、ウォーターフォール型の方が管理しやすい場合があります。たとえば、法令で仕様が厳密に決まる業務システムや、既存仕様を踏襲するリプレース案件が該当します。
アジャイルの強みは変化への適応です。ただし、変化がない案件では、短い反復や頻繁なレビューが負担になることもあります。
発注側は、フルスクラッチだからとアジャイルに決めず、案件の不確実性を見極めます。判断の基準は要件の変化と予測可能性で、手法を目的にせず、案件の性質から選ぶ姿勢が成否を分けます。
- 固定要件：従来型やハイブリッド型も候補になります。
- 変化が大きい要件：アジャイルが適しています。
要件変更への強さと適応主義の思想
アジャイルの強みは、フルスクラッチ開発で生じる要件変更への対応力です。決定事項も変わる前提で、開発を進めます。また、アジャイルは計画を捨てるのではなく、ユーザー要求や市場環境の変化、技術的な発見を計画に反映する姿勢です。
ウォーターフォール型では、契約時の仕様を正とし、変更を例外として扱います。このため、変更が追加費用や手戻りにつながります。
アジャイルでは、各反復のレビューをもとに、次に作るものの優先順位を見直します。さらに、動くものを作って初めて得られる気づきも、次の反復に反映できます。
仮説検証を重ねる仕組みは、独自システムをユーザーに価値あるものへ育てます。こうした進め方は、フルスクラッチ開発の本質にも合致します。
要件を決め切らずに育てる進め方
アジャイルでは要件を最初に決め切らないぶん、優先順位の管理と反復ごとの見直し、発注者の参加を組み合わせて、要件を開発の途中で具体化していきます。
- バックログ管理：POが要求に優先順位を付け、価値の高い項目から開発します。
- 最初に決める範囲：大枠の方向性と価値の順序を定め、詳細仕様は作り込みません。
- 反復と見直し：1〜4週間ごとに動くものを作り、レビューの反応から要件を具体化して、バックログを見直します。
- 要件の具体化：発注者は本当に欲しいものを当初から言語化できないことも多く、反復で引き出してシステムに反映します。
- 発注者の参加：優先順位を判断し、各レビューで率直な反応を返すことが成果を左右します。
パッケージ・SaaS・ローコードとの比較
フルスクラッチを検討するときは、パッケージソフト、SaaS、ローコードなど、作らない選択肢との比較が欠かせません。各方式で得意分野は異なります。
ローコードやSaaSは、MVP（Minimum Viable Product）構築などの検証を短期間・低コストで行える利点があります。この特性は、アジャイルの「早く小さく検証する」思想にも合います。そのため、ローコードで市場を素早く検証する進め方は有力です。
行政機関の調査では、自治体がローコードでシステムを構築したケースの64.0%（約3分の2）がアジャイルでした。両者の相性の良さが示されています。
ローコードの実現範囲は、比較的簡易な機能や、各プラットフォームが用意した枠組みに限られます。そのため、複雑な独自ロジックや競合と差別化する高度なUXでは、制約が壁になります。こうした要求に応えるのが、自由度の高いフルスクラッチ開発です。
ローコードとフルスクラッチは対立させず、事業の段階に応じて使い分けます。検証段階はローコードで素早く進め、本格的な差別化にはフルスクラッチを使います。
自由度の高さと諸刃の剣
フルスクラッチの自由度は魅力ですが、裏を返せばリスクの源となる「諸刃の剣」です。ローコードやSaaSのように品質が枠組みで担保される形とは異なり、品質は開発の進め方で守る必要があります。
- 技術力と品質：技術力の高いチームは独自性を出せますが、ばらつきは低品質なコードや保守難につながります。
- 設計の一貫性：指針や規約が曖昧だと作り方が分かれ、システム全体の一貫性を損ないます。
- 品質管理：コードレビュー、自動テスト、コーディング規約、設計レビューを組み込みます。
- XP：エクストリーム・プログラミングのテスト駆動開発とペアプログラミングは、品質規律に役立ちます。
ローコード検証からフルスクラッチへの段階移行
ローコード・SaaSからフルスクラッチへは、事業の段階に応じて移行できます。アジャイルで開発する際には、この段階的な進め方が現実的です。
- 初期検証：市場が不確かな初期は、ローコード、ノーコード、SaaSでMVPを素早く安価に作り、反応を確かめます。
- 初期投資：最初からフルスクラッチで多額を投じると、市場に受け入れられない場合の損失が大きくなります。
- 移行対象：事業化後は、独自性や拡張性が求められる中核を、一度に全てではなく段階的に作り替えます。
- 優先順位：ローコードでは難しい高度な検索や、競合と差別化する独自UXの画面から作り込みます。
最初から全てをフルスクラッチと決めず、検証と本格開発で手段を使い分けます。こうすると、初期投資のリスクを抑えながら、技術選択を進化させられます。
属人化リスクとドキュメントの罠
アジャイルでフルスクラッチを進めるとき、「アジャイルなら文書は不要」という誤解が属人化を招きます。こうした曲解の例は、後を絶ちません。
アジャイルソフトウェア開発宣言（アジャイルマニフェスト）は、「包括的なドキュメントよりも、動くソフトウェアを」と掲げています。これは、過剰な文書作成よりも動くソフトウェアを優先する意味で、ドキュメントを不要とする主張ではありません。
設計意図や全体構造を残さないまま独自システムを作ると、仕様がメンバーの頭の中だけに残ります。これが属人的な知識です。たとえば、中心メンバーが退職・休職すると、仕様を把握できる人がいなくなり、開発が止まるリスクがあります。
フルスクラッチは既製品と違い、参照できるマニュアルや一般的な知見が乏しく、属人化が特に深刻になります。さらに、作り込みの根拠を記録しないと、後から誰も変更できないブラックボックスになるおそれがあります。
完了の定義に組み込む最低限のドキュメント
属人化への対策として、必要最低限のドキュメントを「完了の定義（DoD＝Definition of Done）」に含めます。
- 完了の定義：チームで合意した完了条件を指し、機能動作・テスト・レビュー・設計要点を品質の基準にします。
- 方向性と構造：インセプションデッキは方向性を、アーキテクチャ図はシステム全体の構造を示します。
- 判断と運用：ADRに重要な技術判断の経緯を記録し、運用マニュアルも用意します。
- 必要な範囲：交代後も開発を続けられる情報に絞ります。過剰な文書は機動力を損ない、文書ゼロは属人化を招きます。
- 契約時の合意：発注者と開発会社で、文書を完了条件に含めると取り決めます。
このバランスを仕組みとして続けられるかどうかが、フルスクラッチ開発を長く続ける鍵になります。
発注者の関与と品質
属人化や品質の問題と並んで、発注者の関与度も成否を分けます。特に、優先順位や反応を担うプロダクトオーナーの役割が問われます。
- 任せきりのリスク：仕様書を渡して任せると、レビューで判断や反応を得られず、次の優先順位を見失います。
- 反復の停滞：せっかくの反復を活かせないと、価値の低い機能に時間を使い、手戻りが増えることがあります。
- レビュー参加：発注者が継続的に関わり、事業の視点で優先順位を判断して、率直な反応を返します。
- 優先順位の責務：バックログを任せきると、技術都合が優先されて、ビジネス価値とずれることがあります。
- 意思決定と協働：発注者が時間と権限を割き、開発会社と一緒に作るという認識が、品質と成果を支えます。
契約形態と規模見積もりの考え方
契約形態は、アジャイルによるフルスクラッチ開発の成否を左右します。要件を最初に完全固定しないため、請負契約とは相性が良くありません。
請負契約では、ベンダーが完成させる義務を負います。要件が頻繁に変わると、対象範囲の変更や再契約が必要になり、管理負担が膨らみます。
そのため、稼働時間に基づいて専門人材を確保する準委任契約が基本です。要件の変化に柔軟に対応し、契約上の摩擦を抑えられます。
内製化は、自社でエンジニアを雇用する方法です。この方法は、目標のずれを根本からなくし、最も力を発揮できる選択肢です。
内製化を目指すなら、立ち上げ期に外部のアジャイル開発会社と準委任で組み、ノウハウを移して内製比率を高める移行策も有効です。フルスクラッチの自由度と変化対応力を活かすため、発注側は契約でも柔軟性を保てる形態を選びます。
ストーリーポイントとバーンレートによる規模の見積もり
要件が固まらないフルスクラッチでは、ウォーターフォール型のように積み上げ式で総額を正確に出すのは困難です。
- 規模の予測：ストーリーポイントとベロシティで全体を見積もり、バーンダウンチャートで残作業の量を示して、リリース計画を共有します。
- 体制の目安：月次の体制維持コスト（バーンレート）を基準に考えるのが現実的です。
- 月額単価：2026年のフリーランス市場の目安は、開発メンバーが65万〜75万円、フルスタックエンジニアが70万〜100万円です。
- 専門職の月額単価：プロジェクトマネージャーが80万〜130万円、スクラムマスターが60万〜90万円、アジャイルコーチが80万〜120万円程度です。
- チーム費用：必要な人数と単価から算出します。エンジニア4名とスクラムマスター1名なら、月額300万円台が目安です。
国内のアジャイル開発の約8割は8名以下のチームで、開発期間の半数は2〜4ヶ月というデータがあります。
そのうえで、総額を先に固定せず、月額体制を何ヶ月続けるかで予算を組みます。反復ごとの価値を見ながら、投資を調整します。
まとめ
スクラムやカンバンを含むアジャイル全般から見ると、アジャイルとフルスクラッチは不確実性を前提とする点で親和性があります。何を作るか定まらない独自システムでは、反復で要件を育て、変化に適応できる進め方が合います。
ローコードやSaaSは、短期・低コストの検証に向きます。自治体のローコード開発の64.0%がアジャイルという調査もあります。
複雑な独自要件や高度なUXには、フルスクラッチが選択肢になります。ただし、その自由度は諸刃の剣で、品質規律と完了の定義への最低限の文書化が欠かせません。
契約は準委任が基本で、内製化も有力な選択肢です。規模の見積もりには、ストーリーポイントとバーンレートを使います。国内では約8割が8名以下のチームで、開発期間の半数は2〜4ヶ月です。
アジャイルでの開発を成功させるため、複数の開発会社に進め方と体制を相談してみましょう。
▼全体ガイドの記事
・アジャイル開発の完全ガイド
▼開発を相談する前に読みたい無料ホワイトペーパー
・Webサービス開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。