「組込み開発=C言語」というイメージはどこまで正しいか?

組込み開発でのプログラミング言語というとC言語(時にアセンブラ)が真っ先に挙げられる気がするのだが、実務的にどこまで正しいのか書いておこうと思う。

結論から言うと、組込みプログラマの立場としては「組込みプログラミング=C言語」は概ね正しいのだが、組込み業界という視点では「C言語以外も結構使われている」ということになる。

そもそも組込み業界ではどんなソフトウェアが作られているだろうか?

組込み業界と言っても結構広いので、分野によって色々と異なるものだが、私が関わっているのは「ガジェット・スマート家電」寄りの分野だ。作っているソフトウェアは、組込みシステム向け三層アーキテクチャ(ドライバ・ミドルウェア・アプリケーション)が適用される程度には大きい*1。OSはRTOSの類が大半だ。

で、外注も含めて、書かれているソフトウェアは以下のような感じだ。

  1. ハードウェア制御用のドライバ・ファームウェア
  2. 移植性のあるミドルウェア
  3. 組込み機器のアプリケーション層
  4. 組込み機器をパソコンと接続するためのWindowsデバイスドライバ
  5. 組込み機器と連携するWindowsアプリケーション
  6. 組込み機器と連携するmacOSアプリケーション
  7. 組込み機器と連携するAndroidアプリケーション
  8. 組込み機器と連携するiOSアプリケーション
  9. 組込み機器と連携するWebサービスのクライアントサイド
  10. 組込み機器と連携するWebサービスのサーバサイド

今の時代、リッチな組込み機器はUSBやネットワーク経由で他のサービスと連携する仕組みを備えている。で、連携先の数だけ必要なソフトウェアが増えている。

接続方式が一般的なプロトコルで十分であるとか、外部デバイス側のフレームワークで提供されている通信機能で十分な性能が得られるような場合は、外部デバイスとのやり取りの部分を仕様で定義した上で、外部デバイス側のソフトウェアの開発を外注することが多い。

例えばWebサービスのサーバサイドが一般的なRESTアーキテクチャのWebアプリケーションで十分ならば、Webアプリケーション側のWeb APIのURLや通信データの形式を決めた上で、Webアプリ専業の会社に発注してしまうのだ。

しかしちょっと特殊なことを実現しようとなると、サーバサイド側の実装も自分たちでコントロールしたくなるので、サーバサイドの初期実装まで自分たちで行うことになる。その後はシステムの性格次第で、運用だけ外注してしまうか、運用と改修を共に外注してしまうことになる。

同じことはモバイルアプリにも言える。機器との接続方法がSDKに用意されている一般的な機能で済むとか、アプリのUIが凝ったものでなくて普通のUI部品で済むようなケースでは、外注することが多い。しかし特殊なことを実現したいとか、UIを凝りに凝ったものにしたいとか、そういう事情がある場合は内製することが多い。

先の一覧でいうなら、(1)〜(3) はほぼ確実に自分たちで開発するが、(4) 以降は開発するシステムの性格次第だ。アプリのデザインや性能要求が絡んでくる場合は、自前のPCアプリ・モバイルアプリ開発部隊を持っていたりする。

実際に組込み機器内で動作するコンポーネントである (1)〜(3) のうち、ステレオタイプの組込みプログラミングに最も違いのは (1) だ。ドライバやファームウェアを担当している人は名実ともに組込みプログラマである。彼らの主要言語はC言語だ。その意味で、組込みプログラマの感覚では「組込みプログラミング=C言語」となる。

一方で (2) のミドルウェア屋は「ハードウェアから分離させた移植性のあるモジュール」を開発するのが主要業務なので、C言語使いではあるものの、組込みプログラマという意識はやや薄い。(3) の組込み機器のアプリケーション層担当ともなると、ミドルウェアやドライバのAPIを叩くのでハードウェアを直接制御することは無いし、LCD表示用のGUIツールキットとの絡みでC++を使うことも多々ある。

なので、組込み業界の中のどの分野かに依存する話ではあるが、組込み系の企業に就職した人が使うプログラミング言語C言語であるとは限らないし、誰もがハードウェア制御用のコードを書ける訳でもない、という現状がある。

サービス展開も含めて規模の大きなシステムの場合、そのシステムを開発している企業の中で分業化が進んでいるものだ。だから、若手の頃から組込み機器のアプリケーション層の開発をバリバリやってきて、C++ベースのオブジェクト指向プログラミングの手練れになった反面、ハードウェアを直接叩くドライバの開発経験がない――みたいな人が実在したりする。

私自身、キャリアの大半が三層アーキテクチャミドルウェア層の開発なので、組込みらしいハードウェア制御プログラムを書いたのは2度だけだし、その開発も業界に入ってから10年以上経ってから偶然遭遇したものだった。

ということで、分野を選ぶ必要はあるものの、C言語が使えなくても組込み業界に入ることは可能だ。結構、機器と連携するモバイルアプリ開発とかで、AndroidiOS向けアプリ開発の手練れを探している企業は多いと思う。

ただし、少し特殊な要件がある場合は、例えばモバイルアプリ開発でもC言語C++の知識が求められることがある。リアルタイム性に関する性能要件がやや厳しいので核となる部分をCやC++で実装する必要があるとか、機器とのTCP通信にて独自のプロトコルを使う必要があってクライアント側としてCやC++で実装されたモジュールが提供されるので組み込む必要があるとか、そんな感じ。なのでAndroidならNDKの、iOSならC++11のスマートポインタとObjective-C++の知見*2が要求されることになる。

(だから先の一覧のmacOSiOSAndroidアプリの開発言語にC++を含めている)

結論として、繰り返しになるが、組込みプログラマ的には「組込みプログラミング=C言語」という構図は概ね正しい。しかし組込み業界という俯瞰した視点では「C言語以外も結構使われている」ということになる。業界にはデバイス制御プログラム以外のソフトウェアを書いている人もそれなりにいるのだ。

なお、上記の議論は「製品としてリリースするソフトウェア」を前提としている。開発用の小ツール――内製ツールやプログラマの個人用ツールとしては、テキスト処理に長けたスクリプト言語Excel制御用の言語(VBAPowerShell)がごく普通に採用されているものだ。ただ、全般的にC言語C++(better C)畑の人が多いので、Windows向けデスクトップアプリ開発では(CやC++のモジュールをそのまま組み込むことができる)MFCやQtが選択されやすい傾向にはあると思う。

*1:規模の小さなマイコン・プログラミングだと、せいぜい「ドライバ・アプリケーション」の二層のアーキテクチャであるし、モノによっては明確な分離がされていないごった煮の実装となっている場合もある。

*2:CやC++のモジュールをObjective-C++でラッピングして、インタフェースをObjective-Cとして見せることで、Swiftから楽に使えるようにするのである。その際に、Objective-CのARCと歩調を合わせてリソース解放するように、C++11のスマートポインタを使う。