最近、転職して開発スタイルが色々あることを再認識しました。今までのスタイルとは全然違っていたので、今までやってきた組み込み開発のV字モデルをまとめ直してみました。
要件定義から受入テストまでの対応関係、各工程の成果物、チェックリスト、トレーサビリティの作り方を紹介しています。
V字モデルとは？（組み込み機器開発の基本形）
V字モデルは、左側＝上流工程（要件〜設計）と右側＝下流工程（テスト）を“鏡合わせ”で対比させた開発プロセスです。
左で定めた内容は、右で対応するテストで検証されます。
ポイント
- 左で“決める” → 右で“確かめる”
- それぞれの工程には対応する成果物があり、次工程の入力になります
- 組み込みではハードとソフトが絡むため、I/F設計・検証が肝
左右の対応（なにを決めて、なにで確かめる？）
| 左：設計工程 | 右：検証工程 | テストで確かめる観点 |
|---|---|---|
| 要件定義 | 受入テスト | 顧客が本当に欲しかった動作／環境条件を満たすか |
| システム設計 | システムテスト | 全機能・性能・EMC/環境試験・安全性 |
| SW/HW設計 | 結合テスト | モジュール間I/F、ドライバ—アプリ間の連携 |
| 実装 | 単体テスト | 関数・モジュールの正しさ、異常時の処理 |
各工程と代表的な成果物（アウトプット）
要件定義（System Requirements）
- 製品要求仕様書（PRS）／ユースケース一覧
- 規格・法規（CE/FCC/RoHS/医療/電波など）
- 環境条件（温度・湿度・振動・EMC）
- セーフティ要求（ISO 26262 / IEC 61508 等）
チェック：曖昧表現（「できるだけ」「なるべく」）を禁止。測定可能な指標（例：応答時間≤100ms@25℃）に。
個人的には要求仕様の背景が頭にないと後々のリリース後に苦労するイメージです。なぜ開発するのか？が明確でないと微妙な感じになる印象です。また、役割分担と工程はざっくりでも良いから早い段階で共有。
システム設計（System Design）
- システムアーキテクチャ図／ネットワーク構成図／機能ブロック図
- I/F一覧（電源、通信、GPIO、センサ、アクチュエータ）
- システム要求仕様書（SRS）
- 性能・電力・コスト予算
チェック：後戻りを減らすため、データフローと例外系の流れ（フェールセーフ、リカバリ）を明記。
全ての資料を洩れなく作成するのが理想ですが、開発担当者が1人とかだと難しい印象です。会社のスタイル、製品によるとは思いますが…
ソフト／ハード設計
ソフトウェア
- ソフト要求仕様（SRS for SW）
- SWアーキ設計（モジュール構成、状態遷移、タスク分割）
- API仕様書／詳細設計（シーケンス・フローチャート）
ハードウェア
- 回路図（Schematic）、BOM
- FPGA仕様（必要時）、PCBレイアウト（層構成・インピーダンス）
チェック：SW/HWのI/F合意（電圧レベル、タイミング、誤接続の保護）を表で固定。
会社によってまちまちだと思いますが、個人的には、組織(チーム)で開発している場合は密に連携を取って仕様に沿った各資料を作成していくのが理想かと思います。横展開とかモジュールの共通化を意識した設計仕様にして次の開発に繋がりを作っておく。外に設計依頼を出すなら尚更、ただ依頼するのではなく、色々と考えて出す。
実装（Implementation）
- コード（C/C++/Rust等）、ドライバ、ミドルウェア
- 回路基板データ（Gerber）、FPGAビットストリーム
- リポジトリ（Git）／ブランチ戦略、CI設定（ビルド・静的解析）
チェック：コミット規約とコード規約（MISRA-C等）をリポジトリの根に置く。
実装部分はエンジニアとしては、1番面白いのかなと感じます。仕様を落とし込み、手元にモノがあって動かして実装していくのはやはり楽しい。しかし、工程が進まなくなる度に焦るのが開発かなと感じます。全て上手くいくのが理想ですが…
単体テスト（Unit Test）
- 単体テスト仕様／テストコード（Unity/CppUTest/GoogleTest）
- カバレッジ（命令/分岐）レポート
- 静的解析レポート（lint、MISRA、CERT）
コツ：正常系＋異常系＋境界値。IO依存部はインタフェースを抽象化し、モックで検証。
個人的な印象ですが、ここは意外とサクッと済ませてしまう印象です。テスト内容が浅いことが多く、後々、重大な欠陥になる印象です。個人的には結構注意して進める工程です。
結合テスト（Integration Test）
- 結合テスト計画／I/Fテスト結果
- ドライバ×アプリ、SW×HW統合レポート
- 通信周り（UART/I2C/SPI/CAN/BLE）のタイミング波形証跡
コツ：ロジアナ/オシロで根拠（波形）を残す。誤配線・プルアップ忘れは早期に潰す。
制御基板と通信基板などの繋がり、処理系をテストする印象です。タイミングが合ってないなど、色々と苦労する印象です。
システムテスト（System Test）
- テスト計画／全機能テストケース
- 性能・電力・長時間試験、EMC/環境試験
- フェールセーフ／ウォッチドッグ／リカバリ試験
コツ：実使用シナリオ（ユーザー操作列＋電源断＋復帰）をシナリオテスト化。
システムテストなので、この段階で動かないことはほとんどない印象です。しかし、とある条件下だとログが残っていないなど、運用上困ることの多くを何故かこの段階で気づくことが多い印象です。
受入テスト（Acceptance Test）
- 受入テスト仕様（顧客と合意）
- 検収チェックリスト／試験成績書
- 承認（サインオフ）記録
コツ：要件IDにテストIDを紐づけ（トレーサビリティ）、「誰が・どこで・どう測るか」を明確化。
検収に向けてのテスト。どれだけ設計の穴を埋めた状態で挑めるかが鍵かと。自信があれば大抵の場合、検収サインをもらえて、リリースできる印象です。
トレーサビリティ（要件→テスト）テンプレ
要件がどのテストで検証されたかを追えるようにします。
| 要件ID | 要件概要 | 関連設計（章/図） | テストID | 試験結果 |
|---|---|---|---|---|
| REQ-001 | 電源投入からUI応答≤100ms | SRS 3.2 / 図5 | SYS-012 | Pass |
| REQ-002 | -20〜60℃で動作 | SRS 4.1 | ENV-003 | Pass |
| REQ-003 | UART 115200 8N1 | I/F表 §2.3 | INT-021 | Pass |
表はGoogleスプレッドシートでもOK。IDで結ぶのがコツ
会社でフォーマットが決まっていると思うので、要件を記入して、テスト結果を記入するだけです。フォーマットが担当者によって違う場合は、信頼できる先輩のフォーマットを利用させてもらえば良いと思います。
組み込みならではの注意点
- 物理世界のばらつき：温度・電源・ノイズで挙動が変わる
- EMC：レイアウト・GND設計・シールドは早期に検討
- 安全：フェールセーフ／ウォッチドッグ／電源瞬断時のリカバリ
- 製造：BOM管理、代替部品、基板リビジョンの構成管理
まとめ
- V字モデルは「左で決めたことを、右で対応するテストで確かめる」フレーム
- 各工程の成果物を揃え、トレーサビリティで要件→テストを結ぶ
- 組み込みはSW/HW/I/F/EMC/安全が鍵。I/F合意と証跡が品質を決める
よくある質問（FAQ）
Q. アジャイルでもV字は必要？
A. 必要です。スプリント内で小さなV字を回す“V字×反復”が現実的。
Q. どの工程から文書化すべき？
A. 要件定義とI/F。ここが曖昧だと全工程がブレます。
Q. 規格対応はいつから？
A. 最初から。後入れは設計の手戻りが大きくなります。