---
title: "アジャイル開発は組み込みでどこまで使えるか｜ハード制約下の適用範囲と判断基準"
url: "https://www.issoh.co.jp/column/details/16839/"
published: 2026-08-23
updated: 2026-08-23
categories: ["Webシステム"]
publisher: "株式会社一創"
---

# アジャイル開発は組み込みでどこまで使えるか｜ハード制約下の適用範囲と判断基準

基板が届くのは3か月先、量産開始日はすでに販社と約束済み、しかも出荷後にソフトを書き換える手段がない。この条件で2週間スプリントを回そうとすると、たいてい2回目のスプリントで止まります。アジャイル開発を組み込みに持ち込めるかどうかは、手法の良し悪しではなく、ハードウェア側の四つの制約が反復のどこを止めるかで決まります。この記事では、制約の中身、実機が無い期間を埋めるシミュレーション環境の作り分け、V字と反復を両立させるハイブリッド構成、機能安全と車載規格の2026年時点の状況、そして採用してよい案件と見送るべき案件の条件までを、発注と体制を決める立場から整理しました。

## まとめ｜組み込みでアジャイルを採用する条件と反復から外すべき三つの領域

組み込み案件で反復に載せられるのは、**ソフトウェア側で完結する振る舞い**だけです。ハードウェア仕様、安全要求、量産開始日の三つは反復の外に置いて先に固定します。ここを一緒に回そうとした瞬間、スプリントレビューが「基板待ち」の報告会に変わります。

採用してよいのは二条件がそろったときです。製品価値の大半がソフトウェアの振る舞いで決まること、そして出荷後にファームウェアを更新する手段があること。この二つが満たされるなら、UIや通信仕様の確定を後ろへずらしてでも反復で詰めたほうが手戻りは小さくなります。逆に、ハード仕様が凍結済みで、ROM容量に余裕がなく、認証審査が一発勝負の単発案件なら、反復を入れる利益はほぼありません。

現実解はハイブリッドです。要求定義とアーキテクチャ設計はV字の左側で固定し、詳細設計から結合テストまでを2週間前後で反復させる。実機が届く前の期間はモデルベースのシミュレーションと評価ボードで埋め、実機が入った時点で反復の単位を「実機での確認込み」に切り替えます。外部委託する場合は請負ではなく準委任が前提になり、発注側にプロダクトオーナーを立てられるかが成否を分けます。

## 組み込み開発でアジャイルが素直に回らない四つのハードウェア制約

手法の問題として語られがちですが、詰まる箇所はほぼ決まっているのが実情です。四つの制約を先に見ておくと、どこを反復から外すべきかが見えます。手法そのものの進め方は[アジャイル開発の基本とスクラムの回し方](https://www.issoh.co.jp/column/details/12850/)で整理しているため、ここでは組み込み固有の効き方だけを扱います。

### 試作基板のリビジョン交代がスプリント開始日を先に決めてしまう制約

組み込み案件では、ソフトの着手可能日を決めるのはチームではなく基板です。試作は一般に、動作確認用の初期試作から、設計検証、量産試作へと数回のリビジョンを踏みます。各リビジョンの入手は数週間から数か月おきで、初期試作の台数は2〜5台ということも珍しくありません。

台数が足りないと、開発者が同時に実機を触れないという物理的な上限が生まれます。5人のチームで実機が2台なら、実機依存のタスクは常に2人分しか並行しません。スプリント計画をベロシティだけで組むと、この上限を無視した計画になります。実機を要するタスクとそうでないタスクを別々に見積もり、実機タスクの総量を台数で割って上限を先に置くほうが計画は当たります。

### 金型製作と部品調達が作る、後ろへ動かせない量産開始日という締切

Web系の案件ならリリース日を1か月ずらす交渉が成り立ちます。組み込みでは成り立たないことが多い。金型は製作に数か月かかり、部品は発注ロットと納期が先に確定し、量産ラインの枠は他製品と取り合いになるためです。

この締切は反復の性質を変えます。アジャイルの本来の姿は「スコープを可変にして日程を守る」ですが、組み込みでは日程が動かせないうえ、ハードに紐づく機能はスコープからも外せません。結果として、可変にできるのはソフトウェア側の追加機能だけになります。優先順位づけの対象を最初から「ソフト側で削れる機能」に限定しておくと、バックログの並べ替えが実務として機能します。

### 出荷後に更新できるかどうかで変わる、動くソフトウェアの定義を決める条件

アジャイルソフトウェア開発宣言（2001年）が価値の中心に置いた「動くソフトウェア」は、更新できる前提の上に成り立っています。出荷後にファームウェアを書き換えられない機器では、出荷時点の品質が製品寿命ぶんの品質になります。

この差は反復の目的を変える要因です。更新手段がある機器なら、最小構成で出して市場の反応で直す進め方が成立します。更新手段がない機器では、反復は「早く出すため」ではなく「早く失敗を見つけるため」に使うことになります。同じスプリントでも、前者は市場投入の前倒し、後者は不具合検出の前倒しが成果指標です。ここを取り違えると、経営層への説明が噛み合いません。

### 機能安全規格が要求する文書の追跡可能性と反復開発の間に生じる摩擦

機能安全の認証が絡む案件では、要求から設計、実装、テストまでの追跡可能性を文書で示すことが要件です。反復のたびに要求が変われば、その紐づけも作り直しになります。認証機関の審査はスプリント単位では来ないため、審査に出す版を別に固定する運用が要ります。詳しい許容範囲は後述しますが、この摩擦は運用でしか吸収できません。

## 実機が揃わない期間を埋めるシミュレーション環境と反復単位の設計

基板を待つ期間をそのまま空けると、アジャイルの利点が消えます。実機以外で回せる範囲を先に作っておくのが実務の要点です。工程全体の流れや費用の内訳は[組み込みソフトウェア開発の工程と費用相場の解説](https://www.issoh.co.jp/column/details/16837/)に譲り、ここでは反復を成立させる環境設計だけを扱います。

### MILS・SILS・HILSの三段階で実機到着前から反復を始める環境の作り分け

実機なしで検証する手段は、抽象度の高い順に三つあります。制御ロジックをモデルのまま検証するMILS、実装コードをPC上で動かすSILS、実際の制御装置を模擬信号につなぐHILSです。

| 環境   | 検証できる範囲    | 着手できる時期  |
| ---- | ---------- | -------- |
| MILS | 制御ロジックの妥当性 | 回路設計と並行  |
| SILS | 実装コードの振る舞い | 試作基板の到着前 |
| HILS | 実時間の入出力応答  | 制御装置の入手後 |
| 実機   | 電気特性と熱・機構  | 試作基板の到着後 |

初期スプリントをSILSで回し、HILSが立ち上がった時点で受け入れ条件を引き上げる。この二段構えなら、基板待ちの数か月を空白にせずに済みます。ただしHILS環境の構築自体が数百万円規模の投資になるため、量産台数の少ない案件では投資が回収できません。モデル側の考え方は[モデルベース開発とV字開発での使い方](https://www.issoh.co.jp/column/details/1466/)で整理しています。

### ハードウェア依存層を切り離すHAL設計とテストダブルの置きどころ

実機なしで反復するには、ハードウェアに触る部分をコードの一箇所に閉じ込める必要があります。レジスタ操作やペリフェラル制御をハードウェア抽象化層にまとめ、アプリケーション層からはその関数だけを呼ぶ構成です。

抽象化層の下をテスト用の偽実装に差し替えれば、アプリケーション層はPC上のテストで回せます。センサー値を返す関数を固定値や記録済みの波形に置き換えると、異常系の再現も容易になります。注意点は、この分離を後から入れるのが極めて高くつくことです。最初のスプリントで層の境界を決め、以降のコードレビューで境界越えを弾く運用にしておきます。

### スプリントで何を完成とみなすかの受け入れ条件と実機確認タスクの扱い

組み込みでは「完成」の定義が二段になります。SILS上で受け入れ条件を満たした状態と、実機で満たした状態は別物です。前者だけで完成扱いにすると、実機投入時に大量の手戻りが出ます。

実務では、スプリントの完成定義を「SILSで受け入れ条件を満たし、実機確認タスクがバックログに積まれている」までとし、実機確認を別レーンで追跡する形が現実的です。バックログの書き方そのものは[アジャイル開発の要件定義の進め方](https://www.issoh.co.jp/column/details/16313/)に整理があります。完成の二段構えを最初に関係者と合意しておかないと、進捗率の解釈が部門ごとにずれます。

## V字モデルと反復を両立させるハイブリッド開発の工程設計と成果物対応

組み込みで実際に採られているのは、純粋なアジャイルではなくハイブリッドです。V字のどこを固定し、どこを反復させるかの線引きが設計の中身になります。

### 上流を固定して下流だけを反復させる二段構えの工程設計と凍結ポイント

システム要求とハードウェアアーキテクチャは、基板設計の入力になるため反復させられません。回路図を引き始めた後に「センサーをもう1個足す」は、基板のリビジョンを1回増やすのと同義です。

そこで、システム要求からハード・ソフト分割までをV字の左側で固定し、ソフトウェア詳細設計から結合テストまでを反復に載せます。凍結ポイントは基板の設計着手日に置くのが実務的です。この日を境に、ハードに影響する変更は変更管理のプロセスへ回し、ソフト内で閉じる変更だけをバックログで扱う。V字側の工程の考え方は[ウォーターフォール開発の工程とV字モデルの解説](https://www.issoh.co.jp/column/details/13140/)にまとめています。

### スプリント成果物をV字右側のテスト工程へ引き渡す対応づけの作り方

反復で作った成果物は、最終的にV字右側の各テストで受け止める必要があります。スプリントごとの単体テストと結合テストは反復内で完結させ、システムテストと受入テストは反復の外に置いて、リリース候補版に対してまとめて実施する形が扱いやすい構成です。

この対応づけを文書化しておくと、認証や顧客監査の場面で「反復で作ったから検証が抜けている」という指摘を避けられます。テスト工程の区分そのものは既存の枠組みで足ります。段階ごとの位置づけは[システム開発のテスト工程とV字モデルの判断軸](https://www.issoh.co.jp/column/details/13445/)を参照してください。

### ハード確定の前後で変わる変更コストの差と変更管理へ切り替える条件

ソフトウェアの変更コストはほぼ一定ですが、ハードウェアの変更コストは基板設計の着手を境に跳ね上がる構造です。回路図段階なら図面の修正だけ、パターン設計後は基板の作り直し、金型製作後は金型修正まで波及します。桁が二つ変わることもあります。

この非対称性から、ハイブリッド構成の切り替え条件は「変更がハードに波及するか」の一点で決められます。波及しないならバックログで扱い、波及するなら変更管理へ回す。判断を担当者の裁量に委ねず、影響範囲の判定基準をプロジェクト開始時に文書化しておくと、後半の混乱が減ります。

## 機能安全と車載規格の下でアジャイルが許容される範囲と2026年時点の前提

規格が反復を禁じているわけではありません。ただし要求される記録の粒度が、反復の運用に条件をつけます。2026年8月時点の規格の状況から確認します。

### Automotive SPICEが4.0で広げた範囲と4.1がプレビュー段階という現状

車載ソフトの開発プロセス評価で使われるAutomotive SPICEは、VDA QMCの配布文書によると4.0が2023年10月20日にプロセスアセスメントモデルの全面改訂として出ています。4.0ではハードウェアエンジニアリングと機械学習エンジニアリングのプロセス群が加わり、対象がソフトウェア中心からシステム全体へ広がりました。

後継の4.1は、同文書の版履歴で日付が2026年4月16日、ステータスがPreviewと記されています。正式版として確定した扱いではないため、2026年8月時点で調達要求に4.1を前提として書き込むのは早い段階です。取引先から4.1準拠を求められた場合は、どの版を評価基準にするかを契約前に文書で確認しておくべきです。

### IEC 61508が第2版のまま推移する状況と第3版の審議が計画へ与える影響

産業機器の機能安全の基本規格であるIEC 61508は、2010年の第2版が現行です。The 61508 Associationの規格開発ページによると、第3版は委員会原案の公開とコメント対応が済み、投票用委員会原案が2026年前半、規格の入手可能時期は2027年初頭という見通しが示されています。

2026年から2027年にかけて開発が続く案件では、途中で参照規格が切り替わる可能性を計画に織り込む判断が要ります。とはいえ、規格改訂を待って着手を遅らせる合理性はありません。現行の第2版で認証を取り、改訂後の差分対応を別プロジェクトとして見積もるほうが、日程の見通しは立ちます。

### 安全要求を反復から外す切り分けと監査に耐える記録の残し方の設計

安全関連機能と非安全機能を同じバックログで扱うと、安全要求の変更履歴が他の変更に埋もれます。安全要求は反復の外で管理し、変更時は影響分析を経て正式な改訂として扱う。反復に載せるのは非安全側の機能と、安全要求を満たす実装の内部改善だけに限ります。

記録面では、スプリントレビューの議事録をそのまま設計根拠の証跡に使わないことです。ISO 26262は2018年の第2版で、要求と検証の対応づけを求めています。反復の運用記録とは別に、リリース候補版ごとの要求追跡表を成果物として定義し、監査対象をそちらに一本化しておくと、審査時の説明が簡単になります。

## アジャイルを採用してよい組み込み案件と見送るべき案件の具体条件

ここは条件を付けて言い切ります。組み込みだからアジャイルが向かない、という一般論は成り立ちませんが、向く案件の範囲は狭いというのが実際のところです。

### 反復を採用してよい三条件と、そのうち一つでも欠けたときの扱い方

採用してよいのは次の三条件がそろう案件です。

- 製品価値の大半がソフトウェアの振る舞いで決まり、ハードは既製の汎用品で足りる
- 出荷後にファームウェアを更新する手段が製品仕様に入っている
- 発注側に意思決定できるプロダクトオーナーを1名専任で置ける

三つそろえば、UI仕様や通信プロトコルの確定を後ろにずらしてでも反復で詰めるほうが得です。一つ欠けた場合は全面採用をやめ、次に述べる部分適用に落とします。特に三つ目が欠けている状態、つまり発注側の意思決定者が週次で出てこない体制では、反復は必ず停滞します。手法以前の問題として、この一点だけは代替手段がありません。

### 反復を見送るべき四つの案件条件と、無理に導入したときの損失の出方

次の条件に当てはまる案件では、反復を入れない判断が正しい。単発の受託でハードウェア仕様が契約時点で凍結済み、ROM・RAMの残容量が1割を切っている、認証審査の枠が一度しか取れない、そして開発期間が3か月未満のいずれかです。

これらの案件で反復を導入すると、損失はスプリント運営の間接工数として出ます。プランニング、レビュー、レトロスペクティブに毎回半日を使い、開発期間が3か月なら6スプリントで3人日以上が会議に消えます。仕様が固定されていて学習すべき未知がない案件では、この投資は回収できません。V字で一直線に進めたほうが早く、品質も落ちません。失敗の起き方は[アジャイル開発が失敗する原因の分析](https://www.issoh.co.jp/column/details/2645/)に整理があります。

### アプリケーション層だけを反復させる部分適用という中間パターン

実務でもっとも使えるのが部分適用です。ドライバ層とハードウェア抽象化層はV字で一度作り切り、その上のアプリケーション層だけを反復で作ります。層の境界がそのまま手法の境界になる構成です。

この形なら、実機が届く前にアプリ層の反復を開始でき、ドライバ層の完成を待つ間もチームが止まりません。境界を守るための条件は一つ、アプリ層からレジスタを直接叩かせないことです。ここが崩れると、ドライバの改修がアプリ層の全面再テストを呼び、反復の速度が出なくなります。

## 外部委託で反復開発を回すための契約形態・体制と発注側に必要な準備

社内に組み込みの反復開発を回せる人員がいない場合は外部委託になりますが、契約の形を間違えると反復そのものが成立しません。

### 準委任契約が前提になる理由とIPAのモデル契約が定めるPOの役割

反復開発は、あらかじめ特定した成果物の完成に対価を払う請負契約と噛み合いません。IPAが2020年3月31日に公開した「情報システム・モデル取引・契約書（アジャイル開発版）」も、請負ではなく準委任契約を前提として作られています。

同モデル契約は、ユーザ企業がプロダクトオーナーを選任し、開発チームが必要とする情報と意思決定を適時に提供する役割分担を明示した契約モデルです。組み込みの場合、この役割にはハードウェア側の仕様変更情報の連携も含まれます。基板のリビジョン計画を委託先に共有していないと、スプリント計画が現実と乖離します。契約書に成果物の完成を書き込むのではなく、実施体制と情報提供の義務を書き込む形に切り替えてください。

### ハードとソフトを別会社へ分けたときに反復が止まる仕組みと一社化の判断

回路設計をA社、制御ソフトをB社に分けて出すと、反復のたびに会社をまたいだ調整が発生します。不具合が出たときの切り分けもハード側とソフト側で押し合いになり、原因究明の工数が追加費用として跳ね返ります。

年に何機種も出す製品群を持ち、社内にハード設計チームがあるなら分割発注でも運用可能です。数年に一度の単発案件で社内に組み込み経験者がいないなら、回路設計から制御ソフトまでを一社にまとめたほうが総額は下がります。内製と外注の分岐そのものは[組み込みソフトウェア開発の内製・外注の判断基準](https://www.issoh.co.jp/column/details/16837/)で詳しく扱っています。

### 発注側が着手前に用意しておく実機・治具・回路情報という三点セット

委託先が初回スプリントから動くために、発注側が用意すべきものは三つです。開発用の実機または評価ボードを人数分に近い台数、入出力を模擬する治具、そして回路図とデータシートを含むハードウェア情報一式。これらが揃わないまま契約すると、最初の1か月が環境構築だけで消えます。

IoT機器やエッジ側の制御ソフトを外部と組んで進める場合の体制づくりは、[AI・IoTソリューションの受託開発](https://www.issoh.co.jp/service/ai/iot/)で相談を受け付けています。ハードウェアの制約を踏まえた反復単位の設計から、実機到着前の検証環境の組み立てまでを含めて整理できます。

## よくある質問

組み込み案件でアジャイルを検討する際に多い質問をまとめました。

### 組み込み開発でもスクラムをそのまま適用できますか？

そのままでは運用困難です。scrumguides.orgが配布している現行のスクラムガイドは2020年版で、実機やハードウェア日程を前提にした記述はありません。特に「スプリント終了時に出荷可能な増分を作る」という定義が、基板が届いていない期間には満たせません。完成の定義をシミュレーション環境での達成に置き換え、実機確認を別レーンで追跡する運用に読み替えたうえで導入してください。役割やイベントの構成自体は組み込みでもそのまま使えます。

### ハードウェアが未完成のうちからスプリントを始められますか？

始められます。制御ロジックをモデル上で検証するMILS、実装コードをPC上で動かすSILSを使えば、基板到着前でも反復が回せます。着手時に必要なのは、ハードウェア抽象化層の境界を先に決めることと、センサー入力を模擬する仕組みを用意することの二点です。ただしHILS環境の構築には数百万円規模の投資が要るため、量産台数の少ない案件ではSILSまでに留める判断もあります。

### 機能安全の認証が必要な製品でもアジャイルは認められますか？

安全関連機能を反復の外に置く前提であれば成立します。IEC 61508やISO 26262が求めるのは要求から検証までの追跡可能性であり、開発手法そのものを指定してはいません。実務では、安全要求は正式な変更管理で扱い、非安全機能と内部実装の改善だけを反復に載せます。監査対象はリリース候補版ごとの要求追跡表に一本化し、スプリントの運用記録とは分けて管理してください。

### アジャイルで進める組み込み案件の見積りはどう取ればよいですか？

成果物一式の総額ではなく、体制と期間で取ります。準委任契約が前提になるため、参画するエンジニアの人数と単価、スプリント期間、想定する反復回数を並べた形の見積書になります。比較の際は、実機確認の工数がどちらの持ち分かと、基板リビジョン交代時の再テスト費用の扱いを各社に確認してください。工程別の費用相場は組み込みソフトウェア開発の解説記事にまとめています。

### ウォーターフォールとの違いは組み込みではどこに出ますか？

違いが出るのは、仕様変更が発生したときの吸収先です。ウォーターフォールでは変更管理のプロセスを通して工期と費用を再交渉しますが、反復では次スプリントの優先順位づけで吸収する形です。ただし組み込みでは量産開始日が動かせないため、吸収できるのはソフト側で削れる機能に限られます。手法ごとの構造的な差は、3手法の比較記事で整理しています。

## 関連記事

- [アジャイル開発とは？スクラムの進め方・ウォーターフォールとの違いをわかりやすく解説](https://www.issoh.co.jp/column/details/12850/)：手法そのものの構造とスクラムの回し方を扱っています
- [ウォーターフォール・アジャイル・スクラムの違い｜3つの開発手法の比較と使い分け](https://www.issoh.co.jp/column/details/1348/)：3手法の構造的な差と使い分けの基準を扱っています
- [組み込みソフトウェア開発とは？工程・費用相場と内製・外注の判断基準を解説](https://www.issoh.co.jp/column/details/16837/)：組み込み側の工程・費用相場と外注判断を扱っています
- [システム開発のテスト工程とは？種類・流れとV字モデル・発注者が見る判断軸](https://www.issoh.co.jp/column/details/13445/)：V字右側のテスト区分と判断軸を扱っています
- [組み込みOSとは？3分類の境界とITRON系の位置づけ・選定判断を実装者向けに解説](https://www.issoh.co.jp/tech/details/16820/)：OSを載せるかどうかの選定判断を実装者向けに扱っています

---

出典: [アジャイル開発は組み込みでどこまで使えるか｜ハード制約下の適用範囲と判断基準](<https://www.issoh.co.jp/column/details/16839/>)（株式会社一創）