開発モデルとは 代表的な7種類の特徴と比較・選び方と契約形態の注意点を解説

「ウォーターフォールとアジャイル、どちらで進めるべきか」。システム開発を発注する立場でも受ける立場でも、最初に決めなければならない問いです。

開発モデルとは、開発の工程をどの順序で、どの単位で進めるかを定義した型のことです。同じ機能を作る場合でも、選んだモデルによって進め方、必要な体制、そして契約の形まで変わります。

選択を誤ると、途中で行き詰まります。要件が固まっていないのにウォーターフォールで進める、逆に発注側が関与できない体制でアジャイルを選ぶ。どちらも現場で頻繁に起きている失敗です。

この記事では、代表的な7つの開発モデルの特徴から、向き不向き、選び方の判断軸、そして見落とされがちな契約形態との関係までを順に整理します。

確認したいポイント	結論	詳細
開発モデルとは？	開発の進め方を定義した型	工程をどの順序で、どの単位で繰り返すかを定めた枠組みです。技術や手法とは別の概念になります。
種類はいくつある？	主要なものは7種類	ウォーターフォール、V字、プロトタイプ、スパイラル、アジャイル、反復型、DevOpsが代表例です。
どう選べばよい？	要件の確定度と変更の頻度で決まる	要件が固まっていればウォーターフォール、変更が前提ならアジャイルが基本の判断になります。
見落としやすい点は？	モデルによって契約形態が変わる	アジャイルは成果物を先に確定できないため、請負ではなく準委任契約が前提になります。

この記事でわかること

• 開発モデルという言葉が指すものと、開発手法やプロセスとの違い
• ウォーターフォールからDevOpsまで、代表的な7種類の特徴とメリット・デメリット
• 要件の確定度や変更頻度など、モデルを選ぶための5つの判断軸
• 選んだモデルによって変わる契約形態と、事前に決めておくべき役割分担
• 全社で統一しない、上流と下流で使い分けるといった実務での組み合わせ方

システム開発とAI活用の進め方をまとめた資料を無料で配布しています 要件整理の進め方、開発の依頼範囲や体制の決め方、費用と期間の目安を1冊にまとめました。社内での検討材料としてご活用いただけます。 ▶ 資料請求はこちら ※オンライン完結／しつこい営業は一切いたしません

開発モデルとは

開発モデルは、ソフトウェアを開発する際の工程の並べ方と進め方を定義した枠組みです。要件定義、設計、実装、テストという工程をどの順序で行い、どの単位で繰り返すかを決めます。

同じシステムを作る場合でも、モデルが違えば進め方は大きく変わります。一度きりで最後まで通すのか、小さく作って繰り返すのかという違いです。

開発手法・開発プロセスとの違い

実務では、開発モデル、開発手法、開発プロセスという言葉がほぼ同じ意味で使われます。厳密に区別しなくても支障はありませんが、整理しておくと理解しやすくなります。

• 開発モデル：工程の進め方の型。ウォーターフォール、アジャイルなど
• 開発手法：モデルを具体化したやり方。スクラム、XPなど
• 開発プロセス：組織やプロジェクトで実際に定めた手順

IPAが公開する共通フレーム2013は、ソフトウェアやシステムの構想から開発、運用、保守、廃棄までのライフサイクルで必要な作業項目と役割を包括的に規定した枠組みです。関係者が同じ言葉で話せるようにすることを目的としています。

用語の定義が組織ごとに違うと、それだけで議論がかみ合わなくなります。プロジェクトの開始時に、何をどう呼ぶかを揃えておくと余計な混乱を避けられます。

なぜモデルを意識する必要があるのか

「とりあえず作り始める」という進め方でも、小規模なら形にはなります。しかし、関係者が増え、期間が長くなるほど、進め方の合意がないことのコストは膨らみます。

モデルを決めるということは、いつ何を確定させるか、変更をどう扱うか、誰がどのタイミングで関与するかを決めることです。ここが曖昧なままだと、認識の食い違いが繰り返し発生します。

発注側にとっても他人事ではありません。モデルによって、自社が費やす時間と関与の深さが変わります。契約形態も変わるため、選択には発注側の理解が必要です。

代表的な開発モデル7種類

ここからは、実務で名前が挙がる7つのモデルを整理します。それぞれに向く場面があり、優劣ではありません。

1. ウォーターフォールモデル

要件定義、基本設計、詳細設計、実装、テスト、リリースという工程を、上流から下流へ順に進め、原則として後戻りしないモデルです。滝の流れになぞらえてこの名前が付いています。

各工程の完了時に成果物をレビューし、承認を得てから次へ進みます。計画が立てやすく、進捗を管理しやすいことが最大の利点です。

• 向く場面：要件が明確、大規模、品質保証や監査対応が必要、複数社が関わる
• 向かない場面：要件が固まっていない、途中で変更が想定される、市場の反応を見ながら作りたい

難点は、変更への対応コストが高いことです。後の工程で仕様変更が発生すると、前の工程の成果物まで修正が波及します。

2. V字モデル

ウォーターフォールを発展させた考え方で、各設計工程と対応するテスト工程を対にして配置します。左側に設計、右側にテストを置き、V字の形で表現します。

要件定義には受け入れテスト、基本設計には結合テスト、詳細設計には単体テストがそれぞれ対応します。何をもってその工程が正しかったと判断するかが、設計の時点で決まります。

利点は、テストの抜けが減ることです。設計書を根拠にテストケースを作れるため、検証の網羅性が上がります。

実質的にはウォーターフォールの一種であり、変更への弱さという性質は引き継ぎます。品質を重視する組み込み系や金融系で広く採用されています。

3. プロトタイプモデル

本格的な開発に入る前に、動く試作品を作って関係者に確認してもらうモデルです。画面のイメージや操作感を早い段階で共有できます。

文書だけでは伝わらない部分が、実際に触ることで明らかになります。「思っていたものと違う」という認識の食い違いを、開発が進む前に潰せる点が最大の価値です。

• 向く場面：利用者の要望が言語化されていない、画面や操作性が重要、新規性が高い
• 向かない場面：試作にかける時間と費用が確保できない、要件が既に明確

注意点として、試作品をそのまま本番に使わないという前提を関係者で共有しておきます。動いているように見えると、あと少しで完成すると誤解されがちです。

4. スパイラルモデル

計画、リスク分析、開発、評価という一連のサイクルを、機能ごとに繰り返しながら完成度を高めていくモデルです。渦を巻くように進むことからこの名前が付いています。

特徴は、各サイクルの冒頭にリスク分析を置いている点です。技術的な不確実性が高い部分から先に着手し、早い段階でリスクを潰していきます。

プロトタイプの作成と評価を繰り返す点はプロトタイプモデルと似ていますが、リスク管理を軸に据えている点が異なります。大規模で不確実性の高いプロジェクトに向きます。

難点は、サイクルの回数が読めず、全体の期間と費用を見積もりにくいことです。反復の終わり方を最初に決めておく必要があります。

5. アジャイル開発

1週間から4週間程度の短い期間で、設計から実装、テストまでを一巡させ、動くソフトウェアを繰り返し提供するモデルです。代表的な手法にスクラムとXPがあります。

各回の終わりに成果物を確認し、そこで得たフィードバックを次の計画に反映します。要件の変更を前提として組み込んでいる点が、他のモデルとの根本的な違いです。

• 向く場面：要件が固まっていない、市場の反応を見ながら改善したい、自社サービスの開発
• 向かない場面：発注側が継続的に関与できない、成果物と金額を先に確定する必要がある

発注側の関与が必須である点を軽視すると失敗します。優先順位を決め、成果物を確認する役割を担う人が、継続的に時間を割ける体制が前提になります。

6. 反復型・インクリメンタル型

システムをいくつかの単位に分割し、単位ごとに設計から実装までを行って積み上げていくモデルです。アジャイルと似ていますが、全体の計画は先に立てます。

1回目で基本機能、2回目で拡張機能、3回目で外部連携という形で段階的に完成させます。早い段階から一部を使い始められる点が利点です。

ウォーターフォールとアジャイルの中間に位置づけられます。全体の枠は決めたいが、一括で作るのはリスクが高いという場合の折衷案として機能します。

7. DevOps

厳密には開発モデルというより、開発チームと運用チームが連携し、リリースと改善を継続的に回す考え方です。自動化されたビルド、テスト、デプロイの仕組みとセットで語られます。

アジャイルが開発工程の反復を扱うのに対し、DevOpsはリリースから運用、そして次の開発までを含めた流れ全体を対象にします。両者は対立するものではなく、組み合わせて使われます。

継続的に改善していくサービスに向く一方で、導入には自動化の基盤と組織の壁を越える体制が必要です。仕組みだけ入れても、部門が分断されたままでは機能しません。

自社に合う進め方の選定からご相談いただけます 違いは分かっても、自社の案件と体制にどれが合うかの判断は別の問題です。要件の整理からご一緒する30分の無料相談をご用意しています。 ▶ 相談予約はこちら ※オンライン完結／秘密厳守／助成金活用のご相談も歓迎

モデルごとの向き不向きを分ける要素

7種類を並べても、自社にどれが合うかはすぐには決まりません。判断を分ける要素は3つに整理できます。

要件がどこまで固まっているか

最も大きな分岐点です。作るものが明確に決まっているなら、順に進めるモデルが最も効率的です。手戻りが起きない前提であれば、反復するコストは無駄になります。

反対に、何を作るべきかを探りながら進める必要がある場合、ウォーターフォールは機能しません。要件定義の工程で決まらないものを、無理に決めたことにして先へ進むことになります。

既存業務の置き換えは要件が固まりやすく、新規サービスの立ち上げは固まりにくいという傾向があります。自社の案件がどちらに近いかを最初に判断します。

規模と関係者の数

参加人数が増えるほど、進め方の統制が必要になります。数十人規模になると、全員が同じサイクルで動くための仕組みが不可欠です。

複数のベンダーが関わる場合も、工程の区切りが明確なモデルのほうが管理しやすくなります。誰がいつまでに何を出すかを契約に落とし込めるためです。

一方、少人数で意思決定が速いチームでは、反復型の利点が出やすくなります。会議で調整するより、作って見せるほうが速いという状況が成立します。

品質要求と記録の必要性

医療機器、金融、公共インフラといった領域では、設計と検証の対応関係を文書で示す必要があります。この要求があるなら、V字モデルのように工程と成果物が明確なモデルが適します。

監査や第三者認証を受ける場合も同様です。どの要件がどのテストで検証されたかをたどれる状態を、開発の過程で作る必要があります。

この要求がない領域で、同じ水準の文書を作るのは過剰です。何のために文書を残すのかを確認したうえで、必要な範囲を決めます。

開発モデルの選び方｜5つの判断軸

実際に選ぶ際は、次の5点を確認します。すべてに答えられれば、選択肢はほぼ1つか2つに絞られます。

軸1｜要件が確定しているか

現時点で、作るべき機能の一覧を書き出せるかどうかを確認します。8割以上が書き出せるならウォーターフォール系、半分も書けないなら反復型が目安になります。

曖昧なまま「たぶん決まっている」と判断するのが最も危険です。実際に機能一覧を書いてみると、決まっていない部分が浮かび上がります。

要件の書き方や粒度については要件定義の例｜システム種類別の要件例と、機能要件・非機能要件の書き換え集も参考になります。

軸2｜変更にどこまで対応する必要があるか

開発期間中に、要件が変わる可能性がどの程度あるかを見積もります。法改正、競合の動き、経営方針の変更といった外部要因も含めて考えます。

変更がほぼないと言い切れるなら、順に進めるモデルで問題ありません。変更を織り込む必要があるなら、その前提で契約と体制を組みます。

「変更しない約束」で進めても、現実には変更は起こります。起きたときにどう扱うかを決めておくことが、モデルの選択と同じくらい重要です。

軸3｜発注側が関与できる体制があるか

反復型やアジャイルでは、発注側が優先順位を決め、成果物を確認する役割を継続的に担う必要があります。この時間を確保できるかどうかを、着手前に確認します。

「専任者は置けないが、アジャイルでお願いしたい」という依頼は成立しません。判断が遅れれば開発が止まり、結局は手戻りが発生します。

関与できる体制がないなら、ウォーターフォールで要件を固めてから任せるほうが現実的です。自社の体制に合わせて選ぶという判断が必要です。

軸4｜リリースの区切りをどう置くか

全機能が揃わないと使えないシステムか、一部の機能から使い始められるシステムかを確認します。段階的に使えるなら、反復型の利点が大きくなります。

基幹システムの入れ替えのように、一斉切り替えが必要な場合は分割が難しくなります。この場合は全体を一度に完成させる前提で計画します。

分割できるかどうかは業務の性質で決まります。技術的に可能でも、運用が二重になって現場が混乱するというケースもあるため、業務側と合わせて判断します。

軸5｜予算と期間をいつ確定させるか

「総額を先に確定させたい」という要求があるなら、成果物を先に定義できるモデルが必要になります。アジャイルでは、開始時点で総額を確定することは原理的に困難です。

予算の枠を決めて、その範囲でできることを優先順位順に進めるという考え方もあります。ただし、この進め方は社内の予算制度と整合するかを確認しておく必要があります。

この軸は、次章の契約形態と直結します。モデルの選択が費用の扱いを規定するという関係を理解しておきます。

契約形態との関係

見落とされやすく、後で問題になりやすい論点です。開発モデルを選ぶことは、契約形態を選ぶこととほぼ同義です。

請負契約と準委任契約

システム開発の委託契約は、大きく2つに分かれます。請負契約は成果物の完成に対して対価を支払い、準委任契約は業務を遂行すること自体に対価を支払うという違いです。

請負では、完成すべきものが契約時点で定義されている必要があります。何を作るかが決まっていなければ、完成したかどうかを判定できません。

準委任では、専門家として業務を遂行することが対価の対象になります。成果物を先に確定しない進め方と整合します。

アジャイルは準委任が前提

IPAが公開する情報システム・モデル取引・契約書（アジャイル開発版）では、あらかじめ特定した成果物の完成に対して対価を支払う請負契約ではなく、ベンダ企業が専門家として業務を遂行すること自体に対価を支払う準委任契約を前提としていると明記されています。

アジャイルは、そのプロセスの中で機能の追加や変更、優先順位の変更に柔軟に対応できる手法です。先に成果物を固定する請負契約とは、性質が根本的に合いません。

この点を理解せずに「アジャイルで、総額固定の請負で」という条件を出すと、実態はウォーターフォールになります。名前だけがアジャイルという状態です。

役割分担を先に決めておく

どのモデルを選ぶにせよ、発注側と受注側の役割分担を契約の段階で文書化しておきます。ここが曖昧だと、トラブル時に責任の所在が定まりません。

IPAのモデル契約書では、役割分担や連絡協議会といった条項が整理されています。ユーザ企業とITベンダのいずれにもメリットが偏らない中立的な内容を目指して作られており、発注側が読んでも得るものがあります。

外注する際の全体の進め方についてはシステム開発の外注とは｜メリット・デメリット、費用相場、外注先の種類と選び方で整理しています。

実務での組み合わせ方

教科書どおりに1つのモデルを適用するプロジェクトは、実際には多くありません。現場では組み合わせて使うのが普通です。

全社で1つに統一しなくてよい

「うちはウォーターフォールの会社だから」という理由で、すべての案件に同じモデルを当てるのは合理的ではありません。案件の性質ごとに選ぶのが本来の姿です。

基幹システムの刷新はウォーターフォール、社内の業務改善ツールは反復型、というように使い分けます。同じ組織の中で両方が動いていても問題はありません。

ただし、評価制度や予算制度がモデルに対応していないと、現場だけでは変えられません。反復型を導入するなら、予算の付け方も合わせて見直す必要があります。

上流はウォーターフォール、実装は反復

よく取られる折衷案です。要件定義と基本設計までは順に進めて全体を固め、実装以降は機能単位で反復します。

全体の枠と予算を確定しつつ、実装段階の細かい調整には柔軟に対応できます。発注側の関与も、実装段階に集中させられます。

注意点は、反復の中で要件そのものを変えないというルールを決めておくことです。ここが崩れると、上流で固めた意味がなくなります。

段階的リリースという選択

1つの大きなプロジェクトを、複数のリリースに分ける方法です。第1弾で必須機能、第2弾で拡張機能という区切り方をします。

各リリースの中身はウォーターフォールで進めつつ、全体としては反復の形になります。1回あたりの規模が小さくなるため、リスクが分散されます。

早い段階で一部が使えることは、社内の理解を得るうえでも有効です。数か月間まったく成果が見えない状態が続くと、プロジェクトへの支持は失われていきます。

よくある失敗と対策

モデルの選択そのものより、運用の仕方で失敗するケースが多く見られます。代表的なパターンを整理します。

名前だけアジャイルになる

最も多い失敗です。短い周期で区切ってはいるが、要件は最初に全部決まっていて、変更は認められないという状態です。

これは反復型のウォーターフォールであり、アジャイルの利点は得られません。むしろ、区切りごとの調整コストだけが増えます。

対策は、契約形態と発注側の体制を、選んだモデルに合わせることです。形式だけを真似ても機能しません。

要件が固まらないままウォーターフォールで進める

逆方向の失敗です。要件定義の工程で決めきれなかった部分を「後で決める」として先へ進み、設計や実装の段階で仕様が確定していくという状態になります。

この進め方では、後工程で必ず手戻りが発生します。しかも契約は請負のままなので、追加費用をめぐる交渉が発生します。

対策は、要件定義の完了条件を明確にすることです。決めきれないなら、その部分だけを別扱いにするか、モデルの選択自体を見直します。

発注側が関与しない

反復型を選んだにもかかわらず、発注側の担当者が確認の場に出てこないというケースです。フィードバックが得られなければ、反復する意味がありません。

結果として、最後にまとめて確認することになり、大量の手戻りが発生します。ウォーターフォールで進めたほうがまだ良かったという状態です。

対策は、着手前に発注側の稼働時間を見積もり、担当者の業務量に組み込むことです。「余った時間で対応する」という前提は成立しません。

途中でモデルを変える

うまくいかないからと、プロジェクトの中盤でモデルを切り替えるケースです。契約、体制、成果物の形がすべて噛み合わなくなります。

変えるのであれば、契約の巻き直しと役割分担の再定義をセットで行います。進め方だけを変えて、契約は元のままという対応が最も混乱を招きます。

そもそも変えなくて済むよう、着手前の判断に時間をかけることが最善の対策です。この判断に1週間かけても、後の手戻りに比べれば安いものです。

まとめ

開発モデルは、工程をどの順序で、どの単位で進めるかを定義した型です。代表的なものに、ウォーターフォール、V字、プロトタイプ、スパイラル、アジャイル、反復型、DevOpsの7種類があります。

選ぶ際の判断軸は5つです。要件の確定度、変更への対応の必要性、発注側の関与体制、リリースの区切り方、予算と期間の確定タイミング。この5点に答えられれば、選択肢は絞られます。

見落とされやすいのが契約形態との関係です。アジャイルは成果物を先に確定できないため、請負ではなく準委任契約が前提になります。ここを取り違えると、名前だけアジャイルという状態になります。

実務では1つのモデルに固執せず、上流はウォーターフォール、実装は反復といった組み合わせも有効です。案件の性質ごとに選ぶという姿勢が現実的です。

まずは自社の案件について、機能の一覧をどこまで書き出せるかを試してみてください。その結果が、選ぶべきモデルを最も正直に示してくれます。

システム開発の進め方から、無料で相談できます 進め方の選択に迷っている、社内に開発マネジメントの知見がなく不安があるといった段階のご相談も承っています。営業色は一切ありません。 ▶ 相談予約はこちら ※オンライン完結／秘密厳守／助成金活用のご相談も歓迎