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

「何を作るか、まだ完全には決まっていない」「市場の反応を見ながら作り込んでいきたい」――こうした不確実性の高い、ゼロから一を生み出すフルスクラッチ・オーダーメイド開発において、アジャイル開発は極めて高い親和性を持ちます。スクラム、カンバン、エクストリーム・プログラミング（XP）といった手法の総称であるアジャイル開発は、そもそも「変化することを前提に、短い反復を繰り返しながらプロダクトを育てていく」というアプローチであり、要件が固まりきらない状態からスタートする独自システムの開発と、思想レベルで噛み合っています。一方で、フルスクラッチ・オーダーメイド開発は自由度が高い反面、メンバーの技術力やドキュメント管理によって品質が大きく左右され、進め方を誤ると属人化や技術的負債といった深刻な問題を抱え込むリスクもあります。アジャイルでフルスクラッチに取り組む際には、その強みを活かしつつ、潜むリスクを正しく管理する視点が欠かせません。

本記事では、アジャイル開発とフルスクラッチ・オーダーメイド開発の相性について、スクラムやカンバンといった個別手法を横断する「アジャイル全般」の視点から体系的に解説します。要件変更への強さと適応主義の思想、パッケージ・SaaS・ローコードとの比較、フルスクラッチ特有の属人化リスクとその対策、準委任契約や内製化との関係、そして規模見積もりの考え方まで、具体的な数値とともにお伝えします。アジャイルでフルスクラッチ開発を成功させるための判断軸を得られる内容です。

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

▼全体ガイドの記事
・アジャイル開発の完全ガイド

アジャイルとフルスクラッチの高い親和性

アジャイル開発がフルスクラッチ・オーダーメイド開発と相性が良い理由は、両者が向き合う「不確実性」の性質が一致しているからです。フルスクラッチ・オーダーメイド開発、特に新規プロダクトやスタートアップの事業では、開始時点で「何を作るべきか」が完全には決まっていません。成果物の姿も、最終的にかかるコストも、市場の反応を見ながら徐々に明らかになっていく、いわば「0から1を生み出す」開発です。こうした状況に対して、最初にすべての仕様を固めてから一気に作るウォーターフォール型を適用すると、開発が進むうちに当初の前提が崩れ、大きな手戻りが発生しがちです。一方アジャイル開発は、ビジネス環境の不確実性を前提とし、短いサイクルでのフィードバックをもとに計画を柔軟に見直していく「適応主義」の思想を持っています。「最初に詳細な計画を固める」のではなく、「作りながら学び、学びながら計画を更新する」というアプローチは、何を作るか決まりきっていないフルスクラッチ開発の進め方として理想的です。だからこそ、正解がわからない新規プロダクト開発において、アジャイルとフルスクラッチの組み合わせは強力な相乗効果を生むのです。

アジャイルとフルスクラッチの相性は良いものの、すべてのフルスクラッチ開発にアジャイルが最適とは限らない点には注意が必要です。フルスクラッチであっても、最初から作るべきものが完全に決まっており、途中で要件が変わる余地がほとんどないシステムであれば、必ずしもアジャイルが最善とは言えません。たとえば、法令で仕様が厳密に定められている業務システムや、既存システムの仕様をそのまま踏襲するリプレース案件などは、要件が固定的であるため、全体スケジュールの可視性が高いウォーターフォール型の方が管理しやすい場合があります。アジャイルの真価は「変化に適応できる」点にあるため、変化が想定されないプロジェクトでは、その柔軟性のための仕組み（短い反復や頻繁なレビュー）がかえってオーバーヘッドになることもあります。重要なのは、「フルスクラッチだからアジャイル」と短絡的に決めるのではなく、自社のプロジェクトが抱える不確実性の度合いを見極めることです。要件の変化が大きく見込まれる新規性の高い開発ならアジャイルが、要件が固まっていて予測可能性を重視するなら従来型やハイブリッド型が、それぞれ適しています。手法そのものを目的化せず、プロジェクトの性質から逆算して選定する姿勢が、フルスクラッチ開発の成否を分けます。

要件変更への強さと適応主義の思想

フルスクラッチ・オーダーメイド開発においてアジャイルが発揮する最大の強みが、要件変更への対応力です。アジャイル開発は「決定した事項も変更されることがある」という前提のもとで進められます。これは無計画という意味ではなく、開発途中で生じるユーザー要求の変化や、市場環境の変化、技術的な発見を、柔軟に受け入れて計画に織り込んでいくという積極的な姿勢を指します。ウォーターフォール型では、契約時に固めた仕様が「正」であり、途中の変更は例外的な事態として扱われ、追加費用や手戻りの原因になります。これに対してアジャイルでは、変化は織り込み済みの前提であり、各反復のレビューで得たフィードバックをもとに、次に何を作るかを優先順位を見直しながら決めていきます。フルスクラッチ開発では、実際に動くものを作って初めて「あれも必要だった」「これは思ったほど重要でなかった」という気づきが得られることが多く、この気づきをすぐに次の反復へ反映できるアジャイルの仕組みは、独自システムをユーザーにとって本当に価値あるものへと育てるうえで決定的に有利に働きます。仮説検証を繰り返しながら作り込んでいくアプローチは、フルスクラッチ開発の本質と深く合致しています。

アジャイルによるフルスクラッチ開発では、要件を最初に「決め切る」のではなく、開発を進めながら「育てていく」という発想が中心になります。プロダクトオーナー（PO）が、システムに必要な要求を優先順位付きで並べた「プロダクトバックログ」を管理し、ビジネス価値の高いものから順に各反復で開発していきます。詳細な仕様書を最初にすべて作り込むのではなく、まず大枠の方向性とビジネス価値の優先順位を定め、1〜4週間の反復ごとに動くインクリメント（成果物）を作り、それをレビューして得たフィードバックをもとに、バックログの内容や優先順位を見直していきます。この「動くものを見ながら要件を精緻化していく」プロセスを通じて、要件は反復のたびに少しずつ明確に、そして実態に即したものへと育っていきます。フルスクラッチ開発では、発注者自身も「自分たちが本当に欲しいもの」を開発が進むまで明確に言語化できないことが多いものです。アジャイルの反復的なアプローチは、こうした「作ってみて初めてわかる」要件を段階的に引き出し、システムに反映していく仕組みとして機能します。発注者に求められるのは、最初にすべてを決めようとするのではなく、優先順位の判断にコミットし、各反復のレビューに積極的に参加して、率直なフィードバックを返し続けることです。この発注者側の関与の質が、フルスクラッチ開発の成果を大きく左右します。

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

フルスクラッチ・オーダーメイド開発を検討する際には、パッケージソフト、SaaS、ローコード開発といった「作らない／作り込まない」選択肢との比較が欠かせません。それぞれに得意・不得意があり、アジャイルとの組み合わせ方も異なります。興味深いデータとして、行政機関の調査では、自治体がローコード開発を用いてシステムを構築するケースの64.0%（約3分の2）がアジャイル開発で行われており、ローコードとアジャイルの相性の良さが示されています。ローコードやSaaSは、短期間・低コストで検証（MVP構築など）ができるという大きな利点があります。アジャイルの「早く小さく検証する」という思想とも噛み合い、まずローコードで素早く市場検証を行うという進め方は有力な選択肢です。しかしその一方で、ローコードやSaaSで実現できる範囲は、比較的簡易な機能や、そのプラットフォームがあらかじめ用意した枠組みの制約内に限られます。独自の複雑なビジネスロジックや、競合との差別化につながる高度なユーザー体験（UX）を実現したい場合には、こうした制約が壁になります。そうした要求に応えられるのが、自由度の高いフルスクラッチ・オーダーメイド開発です。重要なのは、両者を対立させるのではなく、検証段階ではローコードで素早く、本格的な差別化が必要な段階ではフルスクラッチで、というように事業のフェーズに応じて使い分ける視点を持つことです。

フルスクラッチ・オーダーメイド開発の最大の魅力は、何の制約もなく思い通りのシステムを作れる自由度の高さです。しかしこの自由度は、裏を返せばリスクの源泉でもある「諸刃の剣」だと理解しておく必要があります。ローコードやSaaSがプラットフォームの制約のなかで一定の品質を担保するのに対し、フルスクラッチではすべてを自分たちで設計・実装するため、開発を担うメンバーの技術力の差が、そのまま成果物の品質に直結します。優秀なチームが手がければ、競合を凌駕する独自性の高いシステムが生まれますが、技術力にばらつきのあるチームでは、品質の低いコードが積み上がり、保守困難なシステムになってしまうリスクがあります。また、自由であるがゆえに、設計の指針やコーディングのルールを明確に定めておかないと、メンバーそれぞれが好き勝手な作り方をして、システム全体の一貫性が失われます。アジャイルでフルスクラッチに取り組む場合、この自由度がもたらすリスクを管理するために、厳密な品質管理の仕組み——コードレビュー、自動テスト、コーディング規約、設計レビューなど——を意図的に組み込むことが不可欠です。「自由だから何でもできる」を「自由だからこそ規律が要る」へと発想を転換できるかどうかが、フルスクラッチ開発の品質を左右します。XP（エクストリーム・プログラミング）のテスト駆動開発やペアプログラミングといった技術プラクティスは、こうした品質規律をチームに根付かせる有効な手段です。

ローコード・SaaSとフルスクラッチを対立させるのではなく、事業のフェーズに応じて段階的に移行していくという戦略は、アジャイルでフルスクラッチ開発に取り組むうえで現実的かつ効果的なアプローチです。具体的には、事業の立ち上げ初期、まだ「この事業が市場に受け入れられるか」という根本的な不確実性が大きい段階では、まずローコードやノーコード、SaaSを組み合わせて素早く・安価にMVPを構築し、市場の反応を検証します。この段階で多額の費用をかけてフルスクラッチで作り込んでしまうと、もし市場に受け入れられなかった場合の損失が大きくなります。ローコードで素早く検証し、事業として成立する見込みが立った段階で、独自性や拡張性が求められる中核部分から順にフルスクラッチへと作り替えていくのです。この移行は一度に全部を置き換えるのではなく、アジャイルの反復のなかで、ビジネス価値とフルスクラッチ化の必要性が高い部分から段階的に進めるのが定石です。たとえば、ローコードでは実現できない高度な検索ロジックや、競合との差別化につながる独自のユーザー体験を提供する画面から、優先的にフルスクラッチで作り込んでいきます。この段階移行の発想を持つことで、不確実性の高い初期投資のリスクを抑えながら、事業の成長に合わせて最適な技術選択へと進化させていけます。重要なのは、最初から「すべてフルスクラッチ」と決めつけず、検証フェーズと本格開発フェーズで手段を使い分ける柔軟さを持つことです。

属人化リスクとドキュメントの罠

アジャイルでフルスクラッチ開発を進めるうえで、最大の罠とされるのが「アジャイル＝ドキュメント不要」という誤解による属人化です。アジャイル開発の価値観を示した「アジャイルソフトウェア開発宣言（アジャイルマニフェスト）」には、「包括的なドキュメントよりも、動くソフトウェアを」という一文があります。これを曲解して、「アジャイルではドキュメントを作らなくてよい」と捉えてしまうケースが後を絶ちません。しかしマニフェストが言っているのは、「過剰なドキュメント作成に時間をかけるよりも、動くソフトウェアを優先する」ということであって、決してドキュメントの不要論ではありません。設計の意図や全体構造を示す最低限のドキュメントを残さないまま、特にフルスクラッチで独自性の高いシステムを作り込んでいくと、その仕様はメンバーの頭の中だけに存在する「属人的な知識」になります。そして、キーとなるメンバーが退職・休職した途端、誰もシステムの仕様を把握できなくなり、開発が停止するという致命的なリスクが現実化します。フルスクラッチは既製品と違い参照できるマニュアルや一般的な知見が乏しいため、この属人化リスクは特に深刻です。自由に作り込めるからこそ、その作り込みの根拠を記録に残しておかないと、後から誰も手を入れられないブラックボックスを生み出してしまうのです。

属人化リスクを防ぐための実践的な対策が、必要最低限のドキュメントを「完了の定義（DoD＝Definition of Done）」に組み込むことです。完了の定義とは、ある作業を「完了した」と見なすための条件をチームで取り決めたもので、アジャイル開発における品質の拠り所です。たとえば「機能が動く」だけでなく「自動テストが通っている」「コードレビューが済んでいる」「設計の要点がドキュメント化されている」といった条件を完了の定義に含めることで、ドキュメント作成を「やればやるほど良いが、つい後回しにされがちな作業」から、「完了の条件として必ず実施される作業」へと格上げできます。具体的には、プロジェクトの方向性を示すインセプションデッキ、システムの全体構造を示すアーキテクチャ図、重要な技術判断の経緯を記録する意思決定ログ（ADR）、運用に必要なマニュアルなどを、過不足なく残していきます。ポイントは「最低限」という言葉どおり、網羅的で重厚なドキュメントを目指すのではなく、メンバーが入れ替わっても開発を継続できる必要十分な情報に絞ることです。過剰なドキュメントはアジャイルの機動力を損ないますが、ドキュメントゼロは属人化という致命的リスクを招きます。このバランスを完了の定義として仕組み化することが、フルスクラッチ開発を長期的に持続可能なものにする鍵です。発注者としては、契約時に「ドキュメントを完了の定義に含めること」を開発会社と合意しておくことを強く推奨します。

アジャイルによるフルスクラッチ開発で、属人化や品質の問題と並んで成否を分けるのが、発注者側のコミットメントの度合いです。フルスクラッチ開発では「何を作るべきか」を反復のなかで育てていくため、優先順位の判断やフィードバックを担う発注者（プロダクトオーナー）の関与が、ウォーターフォール型以上に重要になります。仕様書を渡して「あとはお任せ」という従来型の発注スタイルのままアジャイルに取り組むと、各反復のレビューで適切な判断やフィードバックが得られず、開発チームは「次に何を優先すべきか」の方向性を見失います。その結果、せっかくの反復の機会が活かされず、価値の低い機能に時間が費やされたり、手戻りが増えたりします。フルスクラッチでアジャイルを成功させるには、発注者が各反復のレビューに継続的に参加し、ビジネス視点から優先順位を判断し、率直なフィードバックを返し続けることが不可欠です。特に、プロダクトバックログの優先順位付けは発注者の最重要の責務であり、ここを開発会社に丸投げしてしまうと、技術的な都合だけで開発が進み、ビジネス価値とのズレが生じます。発注者がこの役割の重さを理解し、相応の時間と意思決定の権限を割けるかどうかが、フルスクラッチ開発の品質と事業成果を大きく左右します。アジャイル開発は「開発会社に任せる」ものではなく、「発注者と開発会社が一体となって作り上げる」ものだという認識を持つことが、成功の前提条件になります。

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

アジャイルでフルスクラッチ開発を進める際、契約形態の選択は成否を左右する重要な要素です。フルスクラッチ・オーダーメイド開発は要件を最初に完全に固定しないため、ベンダーが成果物の完成義務を負う「請負契約」とは本質的に相性が良くありません。請負契約のもとで頻繁に要件が変わると、その都度「契約の対象範囲をどう変えるか」という契約のやり直しが発生し、管理のオーバーヘッドが膨大になります。そのためアジャイルでは、稼働時間に基づいて専門人材を確保する「準委任契約」が基本となります。準委任であれば、要件の変化に応じて柔軟に開発を進めながら、契約面での摩擦を最小化できます。そして、目指すゴールのズレを根本的になくし、最もパフォーマンスを引き出せる選択肢が「内製化（自社でエンジニアを雇用する）」です。立ち上げ期は外部のアジャイル開発会社と準委任で組み、徐々に自社にノウハウを移転して内製比率を高めていくという移行戦略も、フルスクラッチ開発では有効です。重要なのは、フルスクラッチの自由度と変化対応力を活かすために、契約面でもその柔軟性を担保できる形態を選ぶことです。

フルスクラッチ・オーダーメイド開発の規模見積もりは、要件が固まりきっていないために、ウォーターフォール型のような積み上げ式の正確な総額算出が難しいという特性があります。そこでアジャイルでは、作業量をストーリーポイントという相対的な大きさで見積もり、チームが1反復で消化できるポイント数（ベロシティ）と組み合わせて、全体の規模感を予測します。バーンダウンチャートで残作業を可視化しながら、リリース計画を関係者と共有していくのが基本です。費用面では、月次の体制維持コスト（バーンレート）をベースに考えるのが現実的です。国内のアジャイル開発の約8割が8名以下の小規模チームで行われており、開発期間は半数が2〜4ヶ月というデータがあります。単価の目安（2026年時点のフリーランス市場）としては、アジャイル型のフルスクラッチ開発メンバーが月額65万〜75万円、フルスタックエンジニアが月額70万〜100万円、プロジェクトマネージャーが月額80万〜130万円、スクラムマスターが月額60万〜90万円、アジャイルコーチが月額80万〜120万円程度です。これらの単価に必要な人数を掛けたものが、月次のバーンレート（資金燃焼率）の目安となります。たとえばエンジニア4名とスクラムマスター1名の小規模チームなら、月額300万円台が一つの目安です。フルスクラッチ開発では、総額を最初に固定するのではなく、「月いくらの体制を、何ヶ月続けるか」という発想で予算を組み、各反復で生まれる価値を見ながら投資を継続・調整していく考え方が、不確実性の高い開発に適しています。

まとめ

本記事では、アジャイル開発とフルスクラッチ・オーダーメイド開発の相性について、スクラムやカンバンを横断する「アジャイル全般」の視点から解説しました。アジャイルとフルスクラッチは、ともに「不確実性」を前提とする点で親和性が高く、適応主義の思想のもと、要件を最初に決め切るのではなく反復のなかで育てていくアプローチが、何を作るか決まりきらない独自システムの開発に理想的に機能します。一方で、ローコードやSaaSは短期・低コストの検証に適し（自治体のローコード開発の64.0%がアジャイル）、独自の複雑要件や高度なUXが必要な段階でフルスクラッチを選ぶという使い分けが現実的です。フルスクラッチの自由度は諸刃の剣であり、品質規律と、属人化を防ぐ最低限のドキュメント（完了の定義への組み込み）が不可欠です。契約形態は要件変化に対応できる準委任が基本で、最もパフォーマンスを引き出すのは内製化です。規模見積もりはストーリーポイントとバーンレートで捉え、国内のアジャイルの約8割が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を創業。