開発モデル徹底比較

開発モデルの全体像 - 5種類をひとつの軸で整理

開発モデルとは、要件定義や設計、実装、テストといった工程を、どの順序で、どう繰り返すかを定めた進め方です（「開発の全体像と手戻りを防ぐ設計」参照）。代表的な開発モデルには、ウォーターフォール、アジャイル、スパイラル、プロトタイピング、インクリメンタルの5種類があります。これらとしばしば混同されるイテレーティブモデルについては、独立した6つ目の型としてではなく、スパイラルモデルやインクリメンタルモデルとの違いを整理する中で後述します。

5つのモデルは、工程を一度だけ順に進めるか、繰り返すかで大きく分かれます。繰り返す場合も、何を単位に繰り返すのかが、モデルごとに異なります。機能ごとに繰り返すのか、リスクの大きさに応じて繰り返すのか、試作品を軸に繰り返すのかという違いが、モデルの選び方を左右します。本記事では、この5種類を横断して比較し、組み込み開発での使い分けまでを扱います。

ウォーターフォールモデルとアジャイルモデル - 基本の2択のおさらい

ウォーターフォールモデルは、要件定義、設計、実装、テストという工程を、後戻りせずに順番に進める開発モデルです。進捗を管理しやすく、各工程の成果物が文書として残るため、品質保証の記録も残しやすくなります。一方で、後工程になるほど、手戻りにかかるコストが大きくなる弱点があります。品質保証の観点では、ウォーターフォールモデルはV字モデルと組み合わせて運用されることが一般的です（「V字モデルで学ぶテスト工程と品質保証」参照）。

アジャイルモデルは、計画、設計、実装、テストという工程を、短い期間の反復で繰り返す開発モデルです。1回の反復は、数週間程度に区切られることが一般的です。動くソフトウェアを少しずつ提供しながら、利用者の反応を次の反復に反映できる点が強みです。反面、全体の計画や完成時期の見通しは、ウォーターフォールモデルに比べて立てにくくなります。

この2つのモデルの定義や適用場面は、より詳しく解説した記事があります（「ウォーターフォールとアジャイル開発」参照）。本記事では、この2択に加わる、残り3つのモデルを中心に取り上げます。

• テスト支援システムの商品情報はこちら
• PDFで詳しく見る

スパイラルモデルとは - リスク分析を繰り返しながら拡大する開発

スパイラルモデルは、1986年にバリー・ベーム氏が提唱した開発モデルです。システムを部分ごとに分け、計画、リスク分析、開発とテスト、評価という4つの工程を繰り返しながら、対象を段階的に広げていきます。1回のサイクルの中で、要件定義から設計、実装、テストまでの一連の工程が実施される点が特徴です。

最大の特徴は、サイクルごとにリスク分析を明示的に組み込む点です。技術的な難易度やスケジュールの遅れといったリスクを、サイクルの序盤で洗い出し、対策を講じてから開発とテストへ進みます。この手順によって、要件が固まっていない大規模なプロジェクトでも、不確実性に対応しやすくなります。技術的な不確実性が大きい、大規模で複雑なプロジェクトに、特に向いている開発モデルです。

デメリットとしては、リスクを適切に評価できる、経験豊富な技術者が必要になる点が挙げられます。また、サイクルを重ねるたびに要件が膨らみやすく、予算やスケジュールが超過する場合もあります。完成形が早い段階では見えにくいため、固定価格の契約にはなじみにくいモデルです。

プロトタイピングモデルとは - 試作で要求の認識を合わせる開発

プロトタイピングモデルは、開発の早い段階で、実際に動作する試作品を作成する開発モデルです。この試作品はプロトタイプと呼ばれます。利用者にプロトタイプを操作してもらいながら、要求を具体的に引き出し、開発者と利用者の認識のずれを早期にすり合わせます。

プロトタイプの扱い方には、大きく2つの型があります。1つは、要求が固まった時点でプロトタイプを廃棄し、本番用のシステムを新たに作る型です。もう1つは、プロトタイプに手を加えながら、そのまま本番用のシステムへ発展させる型です。

メリットは、完成イメージのずれを早期に解消できる点です。仕様変更や機能追加にも柔軟に対応できます。デメリットは、試作品自体の作成にも時間とコストがかかる点です。製品の規模が大きく複雑になるほど、試作の修正にかかる負担も大きくなります。

組み込み開発では、操作パネルの画面デザインのように、利用者の操作感を確かめながら仕様を固めたい部分に向いています。実機の試作品を使わずとも、画面遷移だけを再現した試作品で、認識合わせを進められる場合もあります。

• テスト支援システムの商品情報はこちら
• PDFで詳しく見る

インクリメンタルモデルとは - 機能を段階的に追加する開発

インクリメンタルモデルは、要件定義を最初に一度だけ行い、機能や範囲をいくつかの部分に分けて、段階的に設計、実装、提供していく開発モデルです。最初に、中核となる機能を持つ版を開発してリリースします。そのうえで、優先度の高い機能から順に追加していきます。

メリットは、早い段階で使える版を利用者に提供できる点です。優先度の高い機能から着手できるため、限られた予算や期間でも、重要な機能を確実に届けられます。デメリットは、後から追加する機能によって、前段で確定させた設計に手戻りが生じる場合がある点です。部分ごとの独立性を保つ設計にも、相応の工数がかかります。

組み込みソフトでは、まず必須の制御機能を実装し、そのうえでログ機能や通信機能を段階的に追加していく進め方が、インクリメンタルモデルの典型例です。

スパイラル・インクリメンタル・イテレーティブの違い - 混同されやすい3つを整理

この3つの開発モデルは、いずれも工程を繰り返す点が共通するため、混同されやすい用語です。整理の軸になるのは、何のために、何を単位に繰り返すのかという点です。

インクリメンタルモデルは、機能や範囲を分割し、段階的に追加していくことに重点を置きます。要件定義は最初の一度だけです。イテレーティブモデルは、同じ範囲を短いサイクルで繰り返し、完成度を段階的に高めていくことに重点を置きます。前のサイクルの成果物を見直し、改善を重ねる進め方です。スパイラルモデルは、サイクルごとにリスク分析を明示的に組み込み、リスクを評価しながら開発の対象を広げていく開発モデルです。1回のサイクルの期間も、数か月単位と比較的長くなります。

たとえば、既存の計測機器に、新しい通信規格への対応機能を追加する案件で考えてみます。通信機能という単位を切り出し、既存機能に追加する進め方が、インクリメンタルモデルです。切り出した通信機能を、動作確認と修正を繰り返しながら完成させていく進め方が、イテレーティブモデルです。採用する通信規格の実現性そのものに不確実性が大きい場合は、試作と評価を繰り返してリスクを見極めるスパイラルモデルの考え方が加わります。

この整理は、情報源によって異なる場合があります。スパイラルモデルを、インクリメンタル型とイテレーティブ型という2つのアプローチを含む、上位の枠組みとして説明する文献も存在します。用語の定義が一つに定まっていない領域であるため、資料を確認する際は、どの立場に立った説明なのかを意識する必要があります。

実務では、これらの考え方を組み合わせて運用することが一般的です。機能を段階的に追加しながら、各段階を短いサイクルで反復し、リスクの大きい部分は重点的に評価するという進め方も、珍しくありません。

• テスト支援システムの商品情報はこちら
• PDFで詳しく見る

組み込み開発でのモデル選定 - 適用場面と判断軸、そしてハイブリッド運用

組み込みソフト開発では、案件の性質によって、向いているモデルが異なります。安全規格への対応が求められる製品や、量産を前提とした製品では、ウォーターフォールモデルやV字モデルが基本になります。業界横断の機能安全規格であるIEC 61508や、医療機器ソフトウェアを対象とするIEC 62304でも、開発プロセスは一般的にV字モデルで説明されます。要求から設計、実装、検証までの対応関係を、記録として残せる点が、規格対応で重視されるためです。

量産後の設計変更は、金型や部品の調達にまで影響が及ぶため、後工程での手戻りを避けられる進め方が求められます。

一方、操作パネルのUIやアプリケーション層のように、利用者の反応を見ながら改善を重ねる部分は、アジャイルモデルやイテレーティブモデルによる反復が向いています。新規性が高く、要求そのものが固まっていない製品では、プロトタイピングモデルによって、早い段階で認識を合わせる進め方が効果を発揮します。ソフトウェアがハードウェアの仕様やタイミングにどれだけ依存するかも、モデル選びを左右します（「組み込みソフトと汎用ソフトの違い」参照）。

• 要求の確定度：開発を始める時点で、要求がどこまで固まっているか
• ハード依存度：ソフトウェアが、ハードウェアの仕様やタイミングにどれだけ依存するか（「組み込み開発における制約事項」参照）
• 規格要求の有無：機能安全規格など、開発プロセスの記録や証跡が求められるか
• 変更の起きやすさ：開発の途中や、市場投入後に、要求や仕様が変わる頻度
• チーム規模：開発チームの人数や、拠点をまたぐ体制かどうか

実際の組み込み開発の現場では、単一のモデルだけで進む案件はまれです。設計とテストは計画性の高いウォーターフォールモデルで進め、実装工程はアジャイルモデルの反復で進めるという組み合わせも見られます。安全に関わる基幹機能はウォーターフォールモデルで、利用者向けの機能はアジャイルモデルで開発するという使い分けも、実際の製品開発で採用されています。

モデルの選定では、ここまでの5つの判断軸に加え、テストを繰り返し実行できる環境があるかどうかが、6つ目の観点になります。どのモデルを選んでも、この観点が開発の実行可能性を左右します（「ソフトウェアテストの種類」参照）。組み込み開発では、実機の試作品や量産部品がそろうまで、テストを実行できない期間が生じがちです。接続機器や入出力信号を模擬する検証環境を使えば、実機がそろう前からでも、検証に着手できます。

まとめ

開発モデルには、ウォーターフォール、アジャイル、スパイラル、プロトタイピング、インクリメンタルの5種類があります。組み込み開発では、単一モデルだけで進む案件はまれで、案件の特性に応じたハイブリッド運用が現実的です。モデルの選定に加え、テストを繰り返し実行できる環境を整えることが、開発を計画どおりに進めるうえで欠かせません。

• テスト支援システムの商品情報はこちら
• PDFで詳しく見る