【エンジニアの道は果てしない】組込みエンジニアの仕事

こんにちは。すうちです。

最初に余談です。
noteを始めるにあたり、何を発信するか？
自分にとって、これが最初のお題でした。

例えば、エンジニアとして細かい技術の話やシェアしたいことを書くとして、今は技術サイトや個人のブログ等でも良い記事が多くあるので、自分が似たようなこと書いてもなあ、という思いがありました。

まだ完全に固まったわけではないですが、これまで自分がエンジニアとして経験したことについて、今からエンジニアを目指す若い方やエンジニアの仕事に興味を持たれている方に、何かの参考になりそうな話を書ければと思っています。

前置き長くなりましたが、
今回は組込みエンジニアの仕事について、書きたいと思います。

１．組込みエンジニアってどういう仕事？

ひとことでいうと、ユーザに求められていること（顧客がやりたいこと）を形にして納める仕事だと思います。

こう書くとある意味ほとんどの仕事がそうかもしれないですが、その対象が家電やスマートフォン、最近は電気自動車などの”製品”や”機能”というとイメージわきやすいでしょうか。

こういった製品には、今は必ずといっていい程、マイコンやCPUと呼ばれる頭脳が入っています。この頭脳にお願いして実現したいことをやってもらわなければなりません。

それをやるためには、その頭脳にルールにそって命令を伝えること（設計・コーディング）や、できあがった製品が目的とおりに動くことを確認したり（デバッグ・テスト）、そもそも顧客がやりたいことが何なのかを明確にする（製品企画・仕様検討）作業が必要になります。

２．仕事の流れ（作業工程）ってどんな感じ？

2.1　製品企画・仕様検討

実際開発を進めるため、具体的にどういうものを作るかを顧客と打合せして決めたり、認識違いがないかを確認していく工程です。
顧客依頼ありきでなく、社内のマーケティングや企画部門と製品開発する場合もあります。

開発過程では、人間の言葉で書くあいまいな仕様と論理的に書かれたプログラムの間にギャップがあるので、エンジニアは関係者と意思疎通とれるように通訳する役割もあります。

仕様検討の結果は、会議録やＱ＆Ａのやりとりを残したり、製品仕様書を作成して目標とする形を共有していきます。ただし、全ての機能や動きを仕様書に残すことは現実的に難しい場合も多く、細かい所は実際に開発品をテストすることも含め最終的に詰めていきます。

2.2　設計・コーディング

仕様検討で議論した結果をもとに、実際の処理をどう作るかを考えてプログラムを組んでいく工程です。

コーディングは、プログラム言語を用いて処理をテキストで書きます。例えば、マイコンを制御したり、追加機能を実現する順序などです。
プログラムはコンパイルという手順によって、マイコン等で動作可能な実行ファイルを作ることができます。

ひとことでマイコン制御や機能追加といってもハードウェアからアプリ層まで様々な階層や連携して動くソフトウェアがあるのですぐにプログラムを作ることはまずないです。

追加機能に関係しそうな処理を調べたり、ハードウェア制御はデータシートというハードウェアの仕様書を理解したり、実際はプログラムを書くよりそれ以外の時間もそれなり多いです。

また、書いたプログラムが設計とおり動くかをテスト前に確認するため、設計にかかわるエンジニアとレビュー（問題点の洗い出しや対策を議論）することが一般的です。

組込み開発では、プログラム言語はC/C++が多く、OSは昔はリアルタイムOSのITRONや携帯向けOSのSymbian等もありましたが、今はスマートフォンだと基本的にAndroid（Linux）です。

iPhone（iOS）の場合は、Appleがハードウェアからソフトウェア全体を作っているので、開発委託がある場合はその上で動くアプリやサービスになると思います。

組込みIoT向け分野ではOSとして再びITRONが使われたり、私はまだ製品で使った経験はありませんが、Amazonが買収したFreeRTOSを使う等の話も最近聞くようになりました。

2.3　デバッグ・テスト

製品仕様や設計書をもとにプログラムしたものが目的とおりに動くことを確認する工程です。デバッグは、テストによって判明した不具合を取り除く（仕様と違う動きのプログラムを修正する）ことを指します。

今回の作業工程は、基本的にウォータフォールやV字型開発と呼ばれる流れを書いてますが、実際は2.1~2.3の工程を繰り返す事が一般的です。機能単位等で区切って複数回に分けて開発とリリースを繰り返す手法をアジャイル開発と呼びます。

アジャイルソフトウェア開発 - Wikipedia

というのも、最近のソフトウェアは開発規模が大きく、最初に決めた仕様で一回で完成することはまずないからです。

細かいリリースポイントを区切って開発元と顧客双方で段階的に確認していくのは、製品完成間際で要求と違うものができあがった時の手戻りが大きいため、早い段階で実際に動くものを見てお互いの認識をすりあわせていく意義があると思います。

じつは、設計やコーディングと並んでこのデバッグやテストの話は、リリース前のトラブルなどエンジニアならではの話もありますが、それはまた別の機会に書きたいと思います。

３．最後に

組込みエンジニアの仕事について、参考になる部分あれば幸いです。
もう少し別の視点の話も今後書いていきたいと思います。