組み込みでアジャイルが回らない本当の理由
組み込み開発の現場でアジャイル開発を導入しても、思うように回らないという声をよく聞きます。原因はチームの努力不足ではなく、ハードウェアに依存する構造そのものにあります。本記事では回らない理由を4つの構造的な壁として整理し、量産後に修正できない製品という制約を踏まえたうえで、層ごとにプロセスを使い分ける現実的な折衷案と、実機を待たずに検証する方法までを解説します。
- 組み込みでアジャイル開発の採用が進まない現実 - IPA調査が示す導入率
- 回らない原因を分解する - 4つの構造的な壁
- 量産後に直せない製品とアジャイルの相性 - フィードバックが効きにくい構造
- 現実的な折衷案 - 層で分けるハイブリッド開発
- スプリントを回す前提条件 - 毎回テストできる環境
- 実機を待たずに反復検証する手段 - 模擬環境という選択肢
- まとめ
組み込みでアジャイル開発の採用が進まない現実 - IPA調査が示す導入率
組み込みソフトウェア開発の現場でも、アジャイル開発という言葉は広く浸透しました。要求仕様の変化に素早く対応できる手法として、多くの技術記事や勉強会で取り上げられています。しかし実際の採用状況を見ると、普及の実態はまだ限定的です。
業界内での評価も一様ではありません。ソフトウェア専業のコンサルティング企業や有識者の間では、組み込み分野でもアジャイル開発を積極的に取り入れるべきだという意見があります。一方で、ハードウェアと密接に結びついた開発の現場からは、そのまま適用するのは難しいという指摘も根強くあります。本記事では、どちらかの立場を断定するのではなく、条件によって成否が分かれる構造を整理します。
IPA（情報処理推進機構）が実施した「2022年度組込み/IoT産業の動向把握等に関する調査」では、開発プロジェクトの6割以上でアジャイル開発を採用していると回答した企業は12%にとどまりました。同じ基準でウォーターフォール開発またはV字開発を採用していると答えた企業は34%に達しており、従来型の開発スタイルが依然として主流であることがわかります。
この調査は組込み/IoT産業に関わる企業の経営者や事業部門責任者を対象に実施されました。調査全体では1,214件の回答が寄せられ、このうち開発スタイルに関する設問には1,077件の有効回答が得られています。
別の調査データの分析でも、アジャイル開発は組み込みソフトウェア業界において、普及期に位置づけられる開発スタイルとされています。同じ分析では、ノーコード/ローコード開発やDevOps、OSSの活用は、普及期より一段手前の発展期に分類されており、普及期に入るのはまだ難しいと評価されています。アジャイル開発はそれらより浸透が進んでいるものの、定着はこれからの段階にあります。
同じ章の記事（「ウォーターフォールとアジャイル開発」参照）では、両手法の一般的な違いを解説しています。本記事では組み込み特有の事情に絞り込み、なぜ現場でアジャイル開発が回りにくいのかを掘り下げます。
この壁の正体を理解しておくことは、開発リーダーがプロセスを設計するうえでも、品質保証担当が検証計画を立てるうえでも役立ちます。以降では、原因の分解から折衷案までを順を追って整理します。
回らない原因を分解する - 4つの構造的な壁
組み込み開発でアジャイル開発が定着しにくい背景には、主に4つの構造的な壁があります。
- 試作サイクルのズレ：ハードウェアの試作サイクルは、基板の設計から部品調達、実装、動作確認まで含めると数週間から数か月かかることが珍しくありません。ソフトウェア側の1〜2週間スプリントとは、周期がまったく合わない状態が生まれます。
- 実機なしでは価値を確認できない：動くソフトウェアを毎スプリント完成させても、載せる実機がなければ本当の価値を確認できません。画面上のシミュレーションだけではセンサの応答や振動、温度変化といった実環境の影響を確認できず、レビューの場でも動作を示せずフィードバックが得にくくなります。
- 量産後に直せない：量産後に基板や筐体を修正できない製品が数多く存在します。金型を起こした筐体や、現地で書き換えられないファームウェアを持つ機器では、「後で直せばよい」という前提が成立しにくく、初期段階での作り込みが求められます。
- 認証対応の文書化負荷：安全規格や認証への対応が必要な領域では、開発の過程を追跡できるトレーサビリティ文書の整備が必須になります。要求仕様から設計、テストまでの対応関係を記録する必要があり、反復のたびに仕様を変える進め方とは相性がよくありません。
これら4つの要因は独立しているわけではなく、相互に絡み合って現場の身動きを取りにくくしています。試作の遅れが実機不足を招き、量産後の修正制約が仕様の作り込みを厳格にし、認証対応の文書化がさらに変更のハードルを上げるという連鎖が起こりやすい状況です。組み込み開発に共通する制約の全体像は、他章の記事（「組み込み開発における制約事項」参照）でも取り上げています。
量産後に直せない製品とアジャイルの相性 - フィードバックが効きにくい構造
アジャイル開発の考え方には、まず動くものを作り、フィードバックを受けて直すという前提があります。ソフトウェアだけで完結する製品であれば、この前提は無理なく成立し、リリース後の修正も比較的低コストで行えます。
ところが組み込み機器の多くは、出荷後に内部のソフトウェアを容易に書き換えられません。センサや制御回路が固定されている製品や、通信手段を持たない機器では、量産開始後の設計変更が事実上不可能な場合もあります。書き換えの手段があっても、現地でのアップデート作業自体にコストと時間がかかります。
医療機器や産業用ロボットのように、機能安全規格への適合が求められる製品では、変更の影響範囲を都度評価しなおす作業が発生します。この評価コストの高さが、計画的な開発との相性がよい理由の一つです。
手戻りを防ぐ設計をあらかじめ作り込む工程は、同じ章の記事（「開発の全体像と手戻りを防ぐ設計」参照）で解説しています。量産後に直せないという制約は、その工程の重要性を裏づけるものです。
品質保証の観点からも、テスト工程を後回しにする進め方には危険が伴います。V字モデルに基づく検証の考え方は、記事（「V字モデルで学ぶテスト工程と品質保証」参照）にまとめています。アジャイル開発を採用する場合でも、検証の網羅性を犠牲にしてはいけません。
現実的な折衷案 - 層で分けるハイブリッド開発
組み込み開発の現場で機能しているのは、純粋なアジャイル開発でも純粋なウォーターフォール開発でもありません。両者を層ごとに使い分けるハイブリッド開発が、現実的な折衷案として広がりつつあります。
ハードウェアの仕様が確定している基板設計や回路構成、量産部品の選定といった領域は、ウォーターフォール型で計画的に進めます。仕様変更のコストが大きい部分ほど、前工程での要件定義や設計レビューを重視する進め方が適しています。
一方、表示画面のレイアウトや設定メニュー、通信ログの見せ方といったユーザインターフェース、アプリケーション層、通信プロトコルの上位部分は、実機への依存度が比較的低い領域です。この層は反復型の進め方と相性がよく、短いサイクルで機能を追加しながら仕様を磨き込めます。
実際に層別の進め方を採用している現場では、ハードウェア確定前の段階からアプリケーション層の設計だけを先行して反復させることもあります。ハードウェアの完成を待たずに、UIの操作性や設定項目の妥当性を早期に検証できる利点があります。
層を分ける境界線は、製品ごとに個別の判断が必要です。ハードウェアの確定度合いと修正コストの大きさを基準に線引きすることが、現実的な進め方になります。境界を明確にしないまま両方式を混在させると、かえって混乱を招く点には注意が必要です。
スプリントを回す前提条件 - 毎回テストできる環境
層別のプロセスを採用しても、アプリケーション層で反復開発を機能させるための前提条件があります。それは、毎スプリントの終わりに動作を確認できるテスト環境が用意されていることです。
実機の台数が不足していると、開発チームの人数分のスプリントを並行して回せません。試作機の完成待ちで次の反復に着手できない状態や、限られた台数の実機を複数チームで奪い合う状態も頻繁に発生します。
テスト環境が整っていないままスプリントだけを形式的に導入すると、動くはずのないタスクが積み上がり、チームの士気が下がる結果になりかねません。スプリントの長さを決める前に、確認可能な環境が整っているかを点検する必要があります。
テスト環境の不足は、自動テストの整備状況にも直結します。手動での実機確認に頼る体制では、スプリントのたびに確認作業が積み重なり、開発速度がしだいに落ちていきます。確認に時間がかかるほど、次のスプリント計画にも遅れが波及します。
継続的にテストと統合を繰り返す仕組みを組み込み開発へ適用する考え方は、記事（「組み込みCI/CD入門」参照）で解説しています。テストできる環境を整えることは、スプリントを回すための出発点であり、体制づくりの優先順位として位置づける価値があります。
実機を待たずに反復検証する手段 - 模擬環境という選択肢
実機不足という前提条件の壁を越えるために、現場で広がっている工夫があります。接続する機器やセンサの入出力をソフトウェア的に模擬する仕組み、いわゆるエミュレーションを使い、実機がなくてもソフトウェアの動作を検証する方法です。
センサの信号やアクチュエータへの出力、通信インターフェースの応答を模擬できれば、試作機の完成を待たずに反復検証を進められます。想定外の入力や異常値を意図的に発生させて動作を確かめることもできるようになり、試作待ちの期間をスプリントの停滞につなげずに済みます。
こうした模擬環境は、量産後に修正できない製品においても有効です。実機に近い条件で早期に不具合を洗い出せるため、量産前の作り込みの精度が高まり、認証対応に必要な検証記録も早い段階から蓄積できます。
模擬環境の整備には初期コストがかかりますが、その分だけスプリントを止めずに回し続けられるという効果が見込めます。ハード依存の壁を完全になくすことはできなくても、壁の高さを下げる手段として検討する価値があります。
実機を用いた最終確認そのものを省略できるわけではありません。模擬環境はあくまで反復のサイクルを止めないための補助であり、量産前には実機による最終検証を必ず組み込む必要があります。
まとめ
組み込み開発でアジャイルが回らない背景には、ハードウェアの試作周期や量産後の修正制約、認証対応といった構造的な壁があります。ハード確定部分はウォーターフォールで、アプリケーション層は反復型で進める層別の設計と、実機を待たずに検証できる環境づくりが、現実的な打開策になります。条件を見極めたうえでの使い分けが鍵です。
