２．ETSS全体像

ETSSの全体像を以下のように分割します。

２．１　組込みソフト開発の実情

２．２　硬直した組込みエンジニアのスキル

２．３　組込みソフト開発の弊害

２．４　組込みソフト開発のあるべき姿としてのETSS

それでは、以下に解説します。

２．１　組込みソフト開発の実情

ご存知のように、組み込みソフト開発は多岐にわたっています。

私たちの身の回りの電気によって動作するほとんどすべての物に組込みソフトが使われています。例えば、家電製品、電話（携帯、その他）、自動車、事務機器（コピー、FAX、プリンタ）、カメラ、医療機器、自動販売機．．．．などは全てが組込みソフトによって動いています。さらに、公共的な、電車、駅の改札、交通信号なども組込みソフトでコントロールされています。パソコン自体（ハードウェアとして見た場合）も、組込みシステムと言えます。それだけ世の中に組込みソフトが普及している状況です。

もう少し内容を見るとその複雑さが分かります。

具体的な最終製品（電気釜や携帯電話など）の例を挙げてありますが、さらにメーカーによってマイコンの機種も変わります。同じ8bitCPUでも半導体メーカーによって、プログラミングは大きく異なります。

製品メーカと半導体メーカとの関係が強く反映されています。家電ではそれが顕著です。家電メーカが昔から半導体事業まで手掛けていたのですから当然です。最近は半導体業界の再編で少し事情が異なっていますが、H社、T社、M社など日本を代表する家電メーカは全て半導体事業をもっていました。その名残は今も続いています。

電気釜のような家電製品は、パソコンと異なりキーボードは何もありません。ソフトウェアをROM（リード・オンリー・メモリ）に焼き（電気的にですが）、搭載しているのです。そのためソフトウェアを開発する環境のみならず、出来上がったソフトウェアをテストするためのデバッグ環境が重要です。ITの世界ではあまり聞きなれない言葉です。テスト工程の環境です。ITの場合、ソフト開発の環境とテスト環境は、実際に稼働する環境（システム）と基本的には同じものです。ですから、デバッグ環境という概念そのものが希薄です。組込みシステム（特に電気釜のような家電）の場合では、特別なデバッグ環境（機材）が必要になります。例えば、ICE（インサーキットエミュレータ）、オシロスコープ、ロジック・アナライザなどです。

ICEはCPUチップの代わりに実際のプログラムをリアルタイムで走行してくれます。データの条件を変えたり、その場でリコンパイルし再度実行したりする事ができますから、きわめて便利です。ただし、かなり高価なものでCPUチップ毎に用意しなければいけません。機能や使い方がその機種（メーカ）によって異なるため、使うためのスキルもかなり必要です。

オシロスコープはアナログの波形を見せてくれますから、実際の信号レベルが正しいかの判断に不可欠です。特に高速ロジックの場合はクロックの波形そのものが崩れたりしますので、必須になります。正確な波形が見られる反面、同時に観察できるのは2チャンネル程度なので、多チャンネル（16ビット/32ビット）のデータバスの情報を見るには不向きです。そのような場合には、多チャンネルのデータを見ることのできるロジック・アナライザがもってこいです。ロジック・タイミング・アナライザとロジック・ステートアナライザの2種類あります。ロジック・タイミングアナライザはオシロスコープほど正確ではありませんが、任意の多チャンネルの波形表示ができデータのグリッジ検出までできますからハードとソフトが絡んだデバッグに便利です。ロジック・ステートアナライザはデータバス（多チャンネル）の状態（ステート）をニーモニック表示してくれます。高度なものになると、逆アセンブル機能までありますから、プログラムの流れをリアルタイムで観察できます。ICE同様に使うためのスキルも必要です。

自動車でも半導体メーカとのつながりがあります。トヨタ系はXX半導体メーカ、日産系はYY半導体メーカといった具体です（今は昔ほど強い結びつきではないかもしれませんが）。上（最終製品）から下（CPUチップ、OS、周辺デバイス）まで一連のつながりが形成されていました。さらに、開発手法（開発環境、デバッグ環境まで含めて）も強い関係を持っています。開発プロセスも当然ながら最終製品に依存しています。自動車（エンジン制御やブレーキ制御）の開発プロセスと携帯電話のプロセスは大幅に異なります。

自動車では最近のCAE技術を反映したモデリング手法から直接Cコードを作成してくれるようになってきました。しかしながら、リアルタイム制御という本来の使命が付きまとうため、シミュレーションのみならず、HW動作の確認も残っています。

一方携帯電話では、電話、メール機能（インターネット接続）、カメラ機能に加えて、音楽受信・再生、ワンセグサービス（TV受信）などの機能の多様化によるコード量が膨大化しています。銀行のオンラインシステム並みの大きさになってしまい、大型システムと同様の開発プロセスが使われています。そして、HWとSWの分業がすすんでいますのでSWエンジニアはHWをあまり気にする必要はありません。ITシステムの開発プロセスとほとんど変わりません。

一言で言うと、多様なCPU、多様なOS、多様な開発環境・デバッグ環境、多様な開発プロセス．．．、過剰なまでの組込みシステムにおける多様性が物事を複雑にしています。

さらに、製品競合が激しい分野が多く、製品そのものの多様化、高機能化（コード量の増大）でSWエンジニアの仕事量は増すばかりです。それだけではありません、品質面でのETソフトとITソフトとの違いを認識する必要もあります。

組み込みソフトは最終製品（家電製品、自動車、携帯電話など）として量産され出荷されます。出荷後に不具合（バグ）が発生すると、製品のリコールに発展してしまいます。その影響は最終製品メーカの財務状況を圧迫するのみならず、イメージダウンを免れません。そのため組込みソフトの方がより高い品質を要求されています。

２．２　硬直化するエンジニアのスキル

上記のような組込みソフト開発の状況では、エンジニアのスキルとキャリアはかなり硬直してしまいます。前述のように、同じ担当でも以前に比べて、コード量が増大していますからエンジニアのスキルは最終製品に依存しがちです。

エンジン制御の組込みソフトを作成しているエンジニアが、携帯電話のソフト開発に変更することは至難のワザです。異なるCPU、異なるOS、異なる開発環境、異なるリアルタイム性の要求度．．．、エンジン制御開発の高度なノウハウやスキルは携帯電話のソフト開発ではほとんど役に立ちません（この例はあまり現実的ではないかもしれませんが、趣旨はご理解いただけると思います）。

同じ会社でありながら、組込みソフト開発エンジニアはロテーションしづらく、一度配属された職場（特定の組込みソフト開発）から離れにくいのです。そしてその職場では一種の徒弟制度のように、先輩のノウハウをそのまま引き継いでいる状況が多く見受けられます。エンジニアのスキルとキャリアは、たまたま配属された特定の組込みシステムに固定されてしまいがちです。果たしてこれで良いのでしょうか。

２．３　ETソフト開発の弊害

製品にもよりますが、技術やスキルが属人化しやすい業界といえます。その弊害は並大抵のものではありません。会社ですから、これから伸びる分野に投資（人材を教育したり、異動させたり）したいと思うでしょう。ところが、そのロテーションが至難のワザなのです。その結果人材が偏在し、特定の部署では人材が余剰し、伸ばしたいビジネス分野では人材が不足してしまいます。

すでに陳腐化した商品でもサポートせざるを得ない場合もあり、市場で使われている限り、組込みソフト（コード）のみならず、古い開発環境、古いデバッグ環境を維持する必要もあります。そのためのコストもばかになりません。

個人のキャリア計画もあまり考えられていません。別の職種（他の製品開発）に変わろうとしても、障壁がきわめて高い状況です。転職しようにも、保有しているスキルは社内の特定部署でしか価値を認めてもらえません。その結果、エンジニア個人としてのモチベーションにも影響します。

２．４　組込みソフト開発のあるべき姿としてのETSS

上記の問題を解決するために、IPAソフトエンジニアリングセンターが提案しているのが、主題のETSS（組込みスキル標準）です。全てを標準化するのではなく、標準化できる部分としづらい部分を分離し、標準化できる部分にフォーカスするというアプローチです。極めて大胆なチャレンジだと思います。ITSS（ITスキル標準）よりはるかに難しいスキルの標準化と言えます。では、どのように標準化しているのでしょうか。

簡単に図示すると上の図のようになります。

従来は、製品/技術（CPU、OS、など）の下にあった、開発プロセスと管理技術を、製品/技術から切り離し、開発プロセス、管理技術のスキルを格上げした形にしました。技術（CPU、OS）は製品に従属しますが、開発プロセスや管理技術は製品とは関係なしに、すべてのソフト開発で共通、すなわち標準化しようとしているのです。

ETSS（組込みスキル標準）として、次の3種類の基準を策定しています。

−スキル基準

−キャリア基準

−教育研修基準

次号以降、この3つの基準の各論について解説します。