アジャイル開発とは？中小企業の発注ガイド — 費用目安・契約・向き不向き

アジャイル開発とは、システムの仕様を最初に全部決め切らず、1〜2週間ほどの短い期間（スプリント）で「作る → 見せる → 直す」を繰り返しながら、少しずつ完成に近づけていく開発の進め方です。結論から言うと、アジャイル開発が向いているのは「やりたいことの大枠はあるが、細部は使いながら決めたい」「市場や現場の反応を見て方向を変えたい」という案件です。費用は、完成品に対して総額を決める形ではなく、開発チームの月額費用（目安として2〜4名体制で月80万〜250万円程度）を、必要な期間だけ払う形になるのが一般的です。

一方で、仕様が固まっていて総額を先に決めたい案件や、発注側が打ち合わせに時間を割けない場合は、従来型のウォーターフォール開発のほうが安全なこともあります。本記事では、IT専門ではない経営者・担当者向けに、アジャイルとウォーターフォールの違い、費用の考え方、契約（準委任と請負）、向き不向き、発注側が担う役割、よくある失敗、発注前のチェックリスト、そして現実的な選択肢としてのハイブリッド型までを整理します。記載する金額はいずれも市場でよく見られる大まかな目安であり、依頼先・内容・体制によって大きく異なります。

ウォーターフォール開発は、要件定義 → 設計 → 開発 → テスト → 納品と、工程を上から下へ順番に進める方式です。最初に仕様と総額を固めるため、予算管理はしやすい反面、途中で「やっぱりこう変えたい」となると、手戻りで費用と期間が膨らみやすい特徴があります。アジャイルは逆に、「変わること」を前提にして、短いサイクルごとに動くものを確認しながら進めます。

どちらが優れているということではなく、案件の性質で使い分けるものです。実際には、純粋なアジャイルや純粋なウォーターフォールだけで進める案件は少なく、後述のハイブリッド型のように組み合わせるケースも多く見られます。

アジャイル開発では、「この機能一式でいくら」ではなく、「開発チームを1か月稼働させるといくら」という形で費用が決まるのが一般的です。体制は、開発者2〜3名に、進行役（スクラムマスターやPM）や設計・デザイン担当が部分的に加わる形がよく見られ、中小企業向けの案件では2〜4名体制で月80万〜250万円程度が一つの目安です。この金額は、後述する準委任契約のもとで、チームの作業時間に対して支払われます。

費用の根拠になる人月単価の考え方は、人月とはで詳しく整理しています。国内の受託開発では、役割やスキルによって人月単価に幅があり、同じ「3名体制」でも構成によって月額は変わります。見積もりを比べるときは、総額だけでなく、誰が何割の稼働で入るのかを確認してください。

また、アジャイルの強みは「小さく始められる」点にあります。最初から全機能を作るのではなく、最も価値の高い部分だけを形にしたMVP（実用最小限の製品）を先に作り、使われ方を見て追加投資を判断します。検証の考え方はPoCの費用の記事も参考になります。

上の表は、あくまで市場で見られる大まかな目安です。実際の金額は、機能の複雑さ、必要な品質水準、外部サービス連携の有無、依頼先の単価、チームの稼働率によって大きく変わります。複数社に同じ前提条件で相談し、前提と内訳を揃えて比較することをおすすめします。追加費用が発生する典型的なパターンは追加費用トラブルの防ぎ方で整理しています。

スプリントは、アジャイル開発の基本単位となる1〜2週間の作業期間です。1回のスプリントは、おおむね次の流れで進みます。

- 計画：やりたいこと（バックログ）のうち、今回のスプリントで作る範囲を、優先順位に従って決める
- 開発：決めた範囲を作る。毎日短い打ち合わせで進捗と課題を共有する
- レビュー：動くものを発注側に見せ、感想・修正点・次の優先順位をもらう
- ふりかえり：開発チームが進め方を振り返り、次のスプリントで改善する

発注側にとって重要なのは、レビューのたびに「動くもの」を実際に触って確認できる点です。完成間際になって初めて見て「違った」となるリスクを、小さく早く潰していけます。逆に言えば、このレビューに発注側が参加しないと、アジャイルの利点はほとんど失われます。

システム開発の契約は、大きく請負契約と準委任契約に分かれます。請負は「完成した成果物に対して報酬を払う」契約で、完成責任と契約不適合責任を受託側が負います。準委任は「業務を行うこと自体に対して報酬を払う」契約で、完成の責任は負わない代わりに、善良な管理者の注意をもって業務を遂行する義務があります。両者の違いは準委任と請負の違いで詳しく解説しています。

アジャイル開発で準委任契約が使われやすいのは、仕様が途中で変わる前提の開発では、あらかじめ「完成品」を定義して総額を決める請負契約がなじまないためです。IPA（情報処理推進機構）が公表している「アジャイル開発版 情報システム・モデル取引・契約書」のように、アジャイルを想定した契約のひな形も整備されています。契約書を用意する際は、こうした公的なモデルを参考にしつつ、自社の案件に合わせて弁護士や専門家に確認してもらうと安心です。

準委任契約は柔軟な反面、「完成しなくても費用は発生する」という性質があります。発注者が何もしなければ、費用だけがかさんで成果が出ない、という事態もあり得ます。次の4つの手当てで、リスクを現実的な範囲に抑えられます。

- 上限予算を決める：全体の予算上限と、超えそうなときは必ず事前に相談する取り決めを入れる
- スプリントごとのレビューを必須にする：成果の確認と、継続・修正・中止の判断を毎回行う
- 解約条件を決めておく：「次のスプリントから停止する」「1か月前の通知で終了」など、途中終了のルールと精算方法を明記する
- 成果物の権利を明記する：ソースコード、設計書、データの権利が発注者に帰属するか、第三者が作った部品の利用条件はどうか、を書面で確認する

とくに成果物の権利と、納品物に含まれる範囲（ソースコード一式、設計資料、環境構築手順など）は、後から揉めやすい点です。契約書のほかに、スプリントごとの成果物をリポジトリなど発注側もアクセスできる場所に置いてもらうよう依頼しておくと、依頼先を変える際にも困りません。

アジャイル開発が向いているのは、次のような案件です。

- 新規事業・新サービスなど、やってみないと正解がわからない案件
- 現場の業務改善で、使いながら使い勝手を磨いていきたい案件
- 市場や顧客の反応を見て、機能の優先順位を入れ替えたい案件
- 最初は小さく始めて、効果が見えたら追加投資したい案件
- 発注側に、継続的に確認・判断できる担当者がいる案件

反対に、アジャイルを選ぶと難しくなりやすいのは、次のような案件です。

- 仕様が法令や契約で厳密に決まっており、変更の余地が小さい案件
- 総額を先に確定させなければ予算承認が下りない案件
- 発注側が、打ち合わせに週数時間の時間を取れない案件
- 既存システムとの接続が多く、全体設計を最初に固める必要がある大規模な基幹系
- 社内で意思決定者が複数に分かれ、優先順位の合意に時間がかかる案件

「向いていない」に当てはまっても、アジャイルが不可能というわけではありません。ただし、その場合は後述のハイブリッド型のように、固める部分と柔軟にする部分を分ける工夫が必要になります。

アジャイル開発の成否を左右するのが、発注側の「プロダクトオーナー」です。プロダクトオーナーとは、何を作るか・どの順番で作るかを決める責任者のことで、ITの専門家である必要はありませんが、業務をよく理解し、社内で意思決定できる立場の人が望ましいとされます。開発会社の側に任せきりにしてはいけない役割です。

時間の目安として、プロダクトオーナーは週に数時間（スプリントの計画・レビューへの参加と、開発チームからの質問への回答）を確保する必要があります。案件の規模や体制によってはもっと必要になることもあります。「通常業務の合間に対応できる」と考えていると、回答が遅れて開発が止まり、結果として費用だけがかさむため、事前に業務時間を空けておくことが大切です。

- 丸投げ：「アジャイルなら柔軟に作ってくれる」と考え、要望も判断も開発会社に任せてしまい、実態のないものができあがる
- ゴールが不明確：「何ができたら成功か」を決めないまま始め、スプリントを重ねても終わりが見えず、費用だけが続く
- 予算の上限がない：月額払いのため、上限や見直しのタイミングを決めないと、総額が想定を大きく超える
- レビュー不参加：忙しさでレビューに出られず、方向のずれに気づくのが遅れ、後半に大きな手戻りが発生する
- ドキュメント不足：「アジャイルは文書を作らない」と誤解し、設計書や操作手順が残らず、担当者や依頼先が変わると誰も保守できなくなる

アジャイルは「ドキュメントより動くソフトウェアを重視する」考え方ですが、ドキュメントが不要という意味ではありません。後から保守や引き継ぎができる最低限の記録（構成図、主要な仕様、運用手順）は、契約時に成果物として求めておくことをおすすめします。

「総額の見通しは欲しいが、細部は柔軟に決めたい」という中小企業では、ハイブリッド型が現実的な選択肢になります。これは、要件定義や基本設計の段階は比較的しっかり固め（ここを請負または短期の準委任で行う）、その後の開発はアジャイルで、優先度の高い機能から小さく作って確認していく進め方です。

この形なら、経営判断に必要な概算予算と全体像を先に持ちつつ、開発の途中で見つかった課題には柔軟に対応できます。要件定義書や依頼書の作り方はRFPの基本も参考になります。

- 解決したい課題と、「何ができたら成功か」を一文で言える
- 社内にプロダクトオーナー役を決め、週に数時間の確保を上司も了承している
- 全体の予算上限と、見直しのタイミング（例：3か月ごと）を決めている
- 最初は小さなMVPで始め、追加投資は結果を見て決める方針になっている
- 契約形態（準委任か請負か）と、その理由を依頼先から説明してもらった
- 途中解約の条件と、精算のルールが契約書に書かれている
- ソースコード・設計書・データの権利が自社に帰属すると確認した
- スプリントごとのレビューの頻度と、参加者を決めている
- 引き継ぎに必要な最低限のドキュメントが成果物に含まれている
- 担当者が交代しても、体制が維持される仕組みを確認した