Embedded Systems Specialist Examination common mistakes
Embedded Systems Specialist Examination · Understand the traps and how to avoid them.
事業戦略の問題で、市場データや企業事例を「自社の状況」に置き換えず、一般論の戦略フレームワーク（SWOT、PPM、バリューチェーン）の用語説明だけで答案を埋めてしまう。
戦略系の用語を暗記しているため、用語を書けば点になると誤解している。問題文が与える自社の制約（開発リソース、既存顧客、収益構造）を読まずに、教科書的な一般論を展開してしまう。
What to do instead
答案の冒頭で問題文の与件（自社の強み・制約・市場環境）を1〜2文で要約し、その与件に紐づけてフレームワークを適用する。フレームワーク名を書いたら必ず「本件では〜という事実から〜と判断できる」と与件の記述を引用して根拠を示す。
製品戦略の設問で、ロードマップや差別化の提案をする際に、組込み製品特有の制約（量産コスト、BOM、認証・規制、サプライヤの調達リードタイム、長期供給責任）を織り込まず、汎用IT製品と同じ感覚で機能追加の提案だけを書く。
事業戦略の知識と組込みハードウェアの現実（部品の長期調達、認証取得コスト、量産立ち上げ期間）が頭の中で分離しており、戦略論の答案にハード制約を持ち込む発想がない。
What to do instead
戦略提案ごとに「実現に必要なハード変更・調達・認証・量産投資」を一行ずつ添える。特に部品の長期供給（EOL）と認証（車載・医療・無線など）のリードタイムを明記し、戦略の実行可能性を裏付ける。
要求仕様の設問で、顧客の要望をそのまま機能要求として列挙するだけで、非機能要求（応答時間、消費電力、信頼性、EMC、動作温度、セキュリティ）や制約条件を仕様として書き出さない。
要求仕様＝機能一覧という思い込みがあり、組込みシステムの品質特性が要求として明文化されることを知らない、または優先度が低いと感じている。
What to do instead
要求を「機能要求／非機能要求／設計制約」の3分類で必ず表形式に整理する。非機能要求には測定可能な目標値（例：起動時間○ms以内、消費電力○mW以下、動作温度範囲）を必ず添え、検証方法（測定・試験）までセットで書く。
要求仕様のトレーサビリティ設問で、要求IDと設計・テストの対応表を作らず、要求の変更が設計やテストに与える影響を説明できない。また、要求の優先度や根拠（なぜその値か）を書かない。
トレーサビリティを「管理のための書類」と捉えており、変更影響分析や検証の網羅性を担保する設計手段であることを理解していない。
What to do instead
要求ごとに一意のIDを付し、「要求→設計要素→テストケース」の双方向対応を表で示す。各要求には優先度（必須／望ましい）と根拠（顧客合意、法規制、過去障害）を添え、変更時に影響範囲を辿れる形にする。
アーキテクチャ設計の設問で、ハードウェアとソフトウェアの機能分担を検討する際、性能・コスト・消費電力・リアルタイム性のトレードオフを定量化せず、「ソフトで実装すれば柔軟」「ハードで実装すれば高速」という定性的な一般論で終わる。
機能分担の判断基準を数値で比較する訓練が不足しており、CPU負荷率やレイテンシ、追加部品コスト、消費電力の見積もり手法を知らない。
What to do instead
分担候補ごとに「処理時間、CPU負荷率、追加コスト、消費電力、変更柔軟性、検証難易度」を表にして比較する。少なくとも1つの機能について概算値（例：ソフト処理で○ms、ハード回路で○µs）を示し、その数値に基づく判断理由を書く。
アーキテクチャ設計で、割り込み処理・タスク設計・通信バッファなどの並行性を考慮せず、単一タスクの逐次処理として構成を描いてしまう。優先度逆転、共有資源の排他、デッドロック、バッファ溢れの検討が抜ける。
組込みのリアルタイムOSや割り込み駆動設計の実務経験が浅く、設計図を機能ブロックの接続図としてしか描けない。
What to do instead
アーキテクチャ図にタスク／割り込み／ISRと共有資源（キュー、セマフォ、共有メモリ）を明示する。各共有資源について排他方式と優先度設計を書き、最悪応答時間やバッファ枯渇時の挙動（オーバーラン処理）を仕様として記述する。
設計・構築・テストの設問で、テスト計画を「単体テスト→結合テスト→システムテスト」という段階名の羅列に留め、各段階で何を検証するか、どの欠陥を狙うか、カバレッジ基準や合否判定基準を書かない。
V字モデルの用語は知っていても、各テスト段階を要求や設計のどの成果物と対応させるかを意識していない。
What to do instead
各テスト段階について「対象成果物（要求仕様／設計書）、検証観点、手法（同値分割・境界値・状態遷移・故障注入など）、カバレッジ目標、合否基準」をセットで記述する。特にハードウェア依存の試験（電源変動、温度、EMC、長時間連続稼働）を計画に明記する。
テスト設問で、不具合の再現条件や環境依存（個体差、温度、電源投入順序、タイミング競合）を考慮せず、机上のロジック検証だけで「テスト完了」と結論する。また、テスト結果の記録や不具合管理のプロセスに触れない。
組込みの不具合は再現性が低く環境依存が大きいという特性への理解が薄く、ソフトウェア単体のテスト感覚で答案を書いてしまう。
What to do instead
再現性の低い不具合には「発生条件の特定、ログ・トレース取得、ストレス試験（温度・電圧・連続稼働）、統計的な発生率評価」を計画に含める。不具合管理は、起票・重要度分類・修正・回帰テスト・クローズの流れを明記する。
開発環境の設問で、CI/CDやバージョン管理、静的解析、自動テストの導入を提案する際、組込み特有の制約（実機・評価ボードが必要、クロスコンパイラ、HILテスト、ファームウェア書き込み時間、ライセンスコスト）を無視した理想論を書く。
Web系の開発プラクティスをそのまま当てはめており、組込みのビルド・書き込み・実機検証のサイクルが長いことを考慮していない。
What to do instead
提案ごとに「ホスト側で自動化できる範囲」と「実機・HILが必要な範囲」を分けて記述する。ビルド時間短縮（キャッシュ、並列化）、実機ファームの自動書き込み・自動試験、ライセンス費用と導入効果（工数削減）の概算を添える。
開発環境の改善設問で、ツール導入の効果を定量的に示さず、「効率化できる」「品質が向上する」といった抽象表現で終わる。また、現場のスキルや既存プロセスとの整合、移行リスクに触れない。
改善提案を技術選定の話として捉えており、効果測定の指標（ビルド失敗率、手戻り工数、不具合検出率、リリースまでのリードタイム）を設定する習慣がない。
What to do instead
現状値と目標値を指標で示す（例：ビルド失敗率○%→○%、手戻り工数○人日削減）。導入ステップを段階的に示し、パイロット適用→評価→全社展開の各段階で確認する指標と、教育・移行に必要な工数、失敗時のロールバック方針を明記する。