製品の中の小型コンピューターを動かすソフトの開発は、要求分析（製品に求められる機能や条件の整理）から、工場での量産、出荷後の保守まで、8つの工程で進みます。この開発を担うのが組込みエンジニアです。
プログラムを書く「実装」は、その中の一つの工程です。開発の初めに決めたことが、そのまま試作機で動きを確かめるときの評価基準になるため、コードを書く前後の工程にも同じくらいの時間と注意を払います。
この記事では、組込みエンジニアの仕事の流れを、要求分析から量産・保守までの各工程に分け、使う道具や書類、関わる人、よくある失敗とあわせて整理します。
組込みエンジニアの仕事の全体像
組込みソフトの開発は、次のような流れで進みます。
要求分析 → システム設計 → ソフトウェア設計 → 実装 → テスト → 実機評価 → 量産移行 → 保守・市場対応
上流の設計、実装と評価、量産と保守の3つの段階に分かれます。
※実際には、評価で見つかった問題を受けて設計や実装に戻る、行き来の多い流れになります。
この流れは、左側で設計を細かくしていき、右側でテストの範囲を広げていく形から「V字モデル」と呼ばれることもあります。
情報処理推進機構（IPA）の「組込みソフトウェア向け開発プロセスガイド（ESPR）」も、こうした工程ごとの標準的な作業を整理しています。
厚生労働省のjob tagでも、組込みエンジニアの仕事は次の流れで説明されています。
- ニーズの把握
- 要件定義
- 設計
- 開発
- テストと修正
- セキュリティの確認
- ドキュメントの作成
コードを書く前後の工程にも、同じくらいの時間と注意を払う仕事だと言えます。
大切なのは、上流で決めたことが、そのまま評価の基準になるという点です。要求仕様に書かれていないことは、正しく動いているかどうかを判断できません。
開発期間は製品によってさまざまで、小さな機能追加なら数週間、新しい製品を一からつくる場合は1年以上かかることもあります。いずれの場合も、工程の順番と考え方は共通です。段階ごとに順に見ていきます。
上流工程：要求分析から設計まで
上流工程は、製品として何をつくるかを決め、それをソフトウェアの形に落とし込む段階です。ここでの判断が、後の工程の手間とコストを大きく左右します。
設計の段階で、ソフトの骨格がほぼ決まります。
要求分析
最初の工程では、商品企画やシステム設計の担当者から製品の要求を聞き取り、ソフトウェアとして実現すべき機能を整理します。要求仕様書にまとめる内容の例は次のとおりです。
- ボタンを押したときの動き
- 表示の内容
- センサーの読み取り周期
- 異常が起きたときの止まり方
よくある失敗は、正常な使い方だけを書いて、電源が途中で切れた、センサーが外れたといった異常時の動きを決め忘れることです。組込み製品では、異常時の振る舞いが安全に直結するため、最初の段階で洗い出しておく必要があります。
要求仕様書は、企画や設計の担当者と何度も読み合わせて確定させます。曖昧な表現を数字に置き換えること、たとえば「すぐに反応する」を「100ミリ秒以内に応答する」と書き直すことが、後の評価をスムーズにします。
システム設計
次に、製品全体の中でハードウェアとソフトウェアの役割を分けます。どの処理を専用の回路で行い、どの処理をソフトで行うのか、どのマイコンやリアルタイムOSを使うのかを、電気・電子設計の担当者と一緒に決めていきます。
マイコンの性能やメモリ容量は部品コストに直結します。余裕を持たせすぎると原価が上がり、切り詰めすぎると後から機能を追加できなくなるため、性能とコストのバランスを見極める判断が求められます。
機械側の条件も、この段階で確認しておきます。モーターの種類や回転数、センサーの取り付け位置などは機械設計の担当者が決めるため、ソフトで実現できる制御の範囲を早めに共有しておくことが手戻りを防ぎます。
ソフトウェア設計
役割分担が決まったら、ソフトウェアの内部構造を設計します。設計書には、主に次のような内容を落とし込みます。
- 機能ごとのモジュール分割
- タスクの優先度
- 状態遷移図
- モジュール間でやり取りするデータの形式
この段階で、ハードウェアに依存する部分とそうでない部分を分けておくと、マイコンを変更したときや次の製品に流用するときに役立ちます。設計書はレビューを通して関係者で確認し、抜けや矛盾がないかをチェックします。
よくある失敗は、設計書を書かずに実装を始めてしまうことです。小さな製品なら動くものは早くできますが、担当者が変わったときに誰も全体を説明できなくなります。設計書は後の保守のための資料でもあると考えておくことが大切です。
実装・評価：コードを書いて実機で確かめる
設計が固まると、いよいよコードを書き、動かして確かめる段階に入ります。組込み開発では、パソコンの上だけでは確認できないことが多く、実機を使った評価に多くの時間を使います。
範囲を少しずつ広げながら、段階的に確かめていきます。
※テストの呼び方や区切り方は、会社や業界によって異なります。
実装
実装では、統合開発環境（IDE）やコンパイラを使い、C言語などでプログラムを書きます。書いたコードはバージョン管理ツールで管理し、他のメンバーによるコードレビューを受けるのが一般的です。
組込み開発では、コーディングのルールを社内で決めていることが多く、IPAの「組込みソフトウェア開発向けコーディング作法ガイド（ESCR）」を参考にする会社もあります。誰が読んでも分かるコードを書くことが、長く使われる製品の保守性を支えます。
レビューでは、処理の正しさだけでなく、割り込みとの競合やメモリの使い方など、組込み特有の観点も確認されます。指摘を受けて直す繰り返しの中で、先輩のノウハウを吸収できるのもレビューの価値です。
テスト
実装したコードは、まず関数やモジュールの単位でテストします。パソコン上でハードウェアの動きを模擬しながら確かめることもあり、この段階で見つけた不具合ほど、直すのにかかる手間は小さく済みます。
次に、モジュールをつないで結合テストを行います。単体では問題がなくても、タイミングの違いや、データの受け渡しの食い違いで不具合が起きることがあるためです。テストの結果は記録に残し、どこまで確認したかを説明できるようにしておきます。
テストの計画は、実装が終わってから考えるのではなく、設計の段階から並行して準備します。要求仕様の一つひとつに対応するテスト項目を用意しておくと、確認漏れを防ぐことができます。
実機評価
ソフトを試作機に書き込み、製品としての動作を確認します。デバッガやオシロスコープ、ロジックアナライザを使い、信号のタイミングや応答時間を測りながら、要求仕様どおりに動くかを確かめていきます。
実際の使用環境を想定した、次のような評価も欠かせません。
- 高温・低温
- 電源電圧の変動
- ノイズ
- 長時間の連続運転
よくある失敗は、試作機の個体差や配線の問題をソフトの不具合と取り違えることで、ハード担当者と一緒に原因を切り分ける姿勢が重要です。
評価で見つかった不具合は、管理表やチケット管理ツールに登録し、原因、対策、再確認の結果までを記録します。不具合の件数や傾向は、製品を量産に進めてよいかを判断する材料にもなります。
量産・保守：工場に引き継ぎ、出荷後も支える
評価を終えたソフトは、量産に向けて工場へ引き継がれます。組込みエンジニアの仕事は出荷で終わりではなく、製品が使われている間はずっと続くと言えます。
開発部門のソフトを、工場で同じ品質で再現できる状態にします。
※会社によっては、評価部門やサービス部門が間に入ることもあります。
量産移行
量産では、工場の生産ラインでマイコンにソフトを書き込み、出荷前に検査を行います。組込みエンジニアは、生産技術や品質保証の担当者と、書き込み手順、検査用のソフト、ソフトのバージョン管理の方法をすり合わせます。
どの製品にどのバージョンのソフトが書き込まれたかを追えるようにしておくことは、後の不具合対応で必ず役に立ちます。リリースしたソフトを確実に管理する仕組みづくりまでが、量産移行の仕事です。
試作の段階ではうまく書き込めていたのに、量産ラインでは時間がかかりすぎる、検査装置と通信できないといった問題が起きることもあります。工場の担当者と早めに試し書きを行うことで、量産直前の混乱を防げます。
保守・市場対応
出荷後に市場で不具合が報告されると、返品された製品やログを解析し、原因を特定して修正版を用意します。修正が他の機能に影響しないかを確認する回帰テストも行い、変更の内容を関係部署に説明します。
不具合の報告は、サービス部門や品質保証を通じて届くことが多く、症状の説明だけでは原因が分からない場面もあります。発生した条件や使われ方を丁寧に聞き取り、社内で再現させるところから調査が始まります。
ネットワークにつながる製品では、遠隔でソフトを更新できるものが増えています。便利な反面、更新に失敗して製品が動かなくならないような仕組みや、セキュリティへの配慮も必要になります。市場で得た情報は、次の製品の要求分析にも生かされます。
製品によっては、発売から10年以上にわたって部品の生産終了に合わせたソフト修正が必要になることもあります。保守のしやすさは設計段階で決まるため、ここでも上流の丁寧さが効いてきます。
業界・会社による違い
ここまでの流れはどの業界でも共通ですが、製品の種類や会社の立場によって、重点の置き方は大きく変わります。代表的な違いを見ておきます。
つくる台数と製品の使われ方で、開発の重点が変わります。
※同じ業界でも製品や会社によって異なります。目安として捉えてください。
量産品と受注生産品
家電や自動車のような量産品では、同じソフトが何十万台もの製品に書き込まれます。出荷後の修正は大きなコストにつながるため、量産前の評価に最も多くの時間をかけるのが特徴です。
特に車載分野では、機能安全の国際規格ISO 26262や、開発プロセスの評価モデルであるAutomotive SPICEに沿った進め方が求められることがあります。
一方、産業機械やFA機器の受注生産品では、顧客ごとに仕様が異なり、据付後に現地で調整を重ねることもあります。流れは同じでも、評価の一部が顧客先で行われる点が大きな違いです。
電機・精密業界の家電や計測機器のように、モデルチェンジの周期が短い製品では、前の機種のソフトをベースに差分を開発する進め方が一般的です。流用する部分と新しくつくる部分を最初に見極めることが、短い開発期間を乗り切る鍵になります。
大手メーカーと中小企業
大手メーカーでは工程ごとに担当が分かれ、要求分析はシステム設計の部署、テストは評価専門の部署が担うことも少なくありません。一つの工程を深く経験でき、開発のルールや手順書が整っているのが大手の特徴です。
中小企業では、一人の組込みエンジニアが要求分析から量産移行、保守まで一貫して担当することが多くなります。任される範囲が広い分、早い段階から製品全体を見渡す力が身につきやすいと言えます。
メーカーと受託開発会社
受託開発会社で働く場合、メーカーから依頼された工程を担当する形が中心です。設計と実装だけ、テストだけ、といった部分的な関わり方もあり、案件によって流れのどこに入るかが変わります。
客先に常駐して開発に加わる場合は、メーカーの開発ルールや書類の書式に合わせて仕事を進めます。複数の会社の進め方を経験できるのは、受託開発ならではの利点です。
どの立場でも、全体の流れを知っておくことで、自分の担当工程が前後の工程にどう影響するかを考えながら仕事を進められるようになります。
まとめ
- 組込みソフトの開発は、上流の設計、実装と評価、量産と保守の3段階で進む
- 上流で決めた要求仕様が、そのまま評価の基準になる
- 実装後は単体・結合テストを経て、試作機での実機評価に多くの時間を使う
- 量産移行ではソフトの書き込みとバージョン管理までを整え、出荷後も保守が続く
- 量産品か受注生産品か、会社の規模や立場によって工程の重点が変わる
組込みエンジニアの仕事内容や役割の全体像は組込みエンジニアとはで、必要なスキルやキャリアの道筋は組込みエンジニアに必要なスキル・資格とキャリアパスで詳しく解説しています。
組込みエンジニアの仕事の流れについては、ソフトウェア・組込みの職種ページから関連記事もあわせてご覧ください。
出典
出典・参考資料（2件）を開く出典・参考資料を閉じる
- 仕事の工程：厚生労働省 職業情報提供サイト（job tag）「システムエンジニア（組込み、IoT）」
- 開発プロセス・コーディング作法：独立行政法人情報処理推進機構「高品質な組込みソフトウェア開発（ESxR Series）」
NEWSLETTER
選んだ職種・業種に合わせた記事を、週1回メールで
週刊MONOSCOPEは、登録時に選んだ職種・業種に合わせた記事を週1回お届けする無料のメルマガです。
職種・業種を選んで登録へ ›
無料・週1回。登録後に届く確認メールのリンクを押すと登録が完了します。配信はメール内のリンクからいつでも停止できます。
WEEKLY NEWS
今週の製造業ニュース10選
メルマガは職種・業種に合わせた記事。LINEとnoteでは、全員共通の10本を毎週土曜の朝にお届けします。
LINEでニュース10選を受け取るnote今週のニュース10選をnoteで読む ›
コメント