gedoの日記： スキル診断調査，組み込み技術者 vs. IT技術者

今日CQ出版からきたメールで気になったのがスキル診断調査，組み込み技術者 vs. IT技術者という記事で、いわゆる組み込み系とIT系のキャリアや待遇の比較なんですが、常識と思われていた部分でその通りな部分と違う部分いろいろあって興味深い物があります。

• 組み込み系は全般的に学歴が高めで、理工系大卒が標準で修士もそれなりにいるのに対して、IT系は大学を出ていない人も多く、専攻分野も多岐に渡る。
• 就職サイトなどでは組み込み系は定年までキャリアを積めると言う所も多いが、実は組み込みの方が若年層が中心。一方組み込みは年齢とともにレベルが高くなるが、IT系は優秀な人が他業種や職種に流出するのか、30代あたりでガクッと落ちる。
• 前項とも関係しますがキャリアパスの面ではIT系の方が幅広く、一方組み込み系は管理職に上がれなければキャリアパスや能力を活かせる職種は限られており、全くの畑違い分野や最悪非正規雇用に落ちる者も少なくなさそうです。
• 「どちらも社内外において専門分野の技術，手法，ビジネスをリードできるレベル5注1以上」の人材が足りないのは組み込み、ITを問わない。
• 非技術職に行った同年齢の人に比べ、収入は低めで、不満も多い。
• レベルの低さを長時間労働でカバーする傾向はIT系の方が強い。一方ハイレベルクラスの労働時間も長い人が組み込み系IT系問わず多い。
• やはりIT系の方が女性が多いが、組み込み系の女性も増えつつある。しかし結婚や出産を機に離れる人は組み込みの方が多い。

やはり組み込み系は酬われない上に将来暗いのねぇ。そういうわけで人生踏み外したくないならやめましょうね。＞若い方

組み込み系の人は本当に心が荒むようですな

[oddmake (1445)]

一部の人なんでしょうが。
だいぶ以前のこと、私が「組み込み系に詳しくないのでこれはどういうことか詳しい方にコメントして欲しいところですが…」と（ネットで）質問というか感想をつけたところ。出てきた組み込み系技術者の人、「なんでこんないい加減なことを言っているんだ」「チップの技術とか無いんじゃないのか」（はい、組み込み系の技術に詳しくないって自分で言ってますよね）とかかなり悪罵の混じったコメントが。
参考になることもいっているので、その方の読解力とか諸々には文句をつけなかったわけではあるのですが、なんだか理解の足りない周囲に疲れているのでしょうか。と思ったことも確かですね。

--
/.configure;oddmake;oddmake install

Re:組み込み系の人は本当に心が荒むようですな

[gedo (7079)]

なんだか理解の足りない周囲に疲れているのでしょうか。

要因はいろいろ重なっていますけど、そうかもしれません。
やはり組み込み系は目立たない故に、IT系に比べて世間的にはあまり理解されていません。その結果そういう分野の技術者の仕事がやりにくい、やる気をなくさせる政策の政治家や行政委員が支持されるという困った状況もあります。(秋葉原を壊した某都知事や、民営化の掛け声の元に理系教育を破壊した元総理とか、解の公式不用論をブチ上げた某女性作家とか)

組み込み系はソフトハード両面やOSの中身の他に場合によってはメカとか、エンドユーザーの業務知識(これはIT系でも必要ですが)、守備範囲が広く高度なレベルが必要なのですが、一方それに見合った収入が得られているわけではありません。それに加えていわゆる「萌え」などのサブカルチャー系への反感から組み込みへ進んだ方もよくいて、そのためかIT系の人を見下して(精神の安定を図って)いる組み込みの人も良くいます。

IT系と違ってバグフィクスは簡単ではなく、さらに重電や輸送機械ではバグで人が死ぬこともあります。そこまで行かなくても何かの機械を制御するもの故に常にワーストケースで考えるように教育されていますので、どうしてもネガティブ思考になるという性があります。

さらに日本固有の問題として、ハード(アナログと言うべきか)とソフト(ロジックと言うべきか)のセクショナリズムからくる対立が強く、組み込み系は優秀であるほどゲゲゲの鬼太郎のネズミ男というか、四面楚歌になりやすく、人間関係のトラブルや感情的な対立に巻き込まれやすいので、トラブル対策のICレコーダーは必須アイテムです。(最近は持ち込みにくいそうですが、その頃には辞めてしまいましたので)
また、日本では当然よく使われる日本メーカー(ルネサスとか)のマイコンはハードとソフトのトレードオフが狂っていて(ちょっとハードを追加すれば...な部分がある一方でソフトでやった方が良さそうな物に妙なハードウェアアクセラレーターがついていたり)、組み込み技術者に理不尽な負担を強いる物が多いです。
加えて携帯電話が有名ですけど、コンピューター関連職種で良く言われるデスマが蔓延していたり、分野によっては(治安の悪い)海外を含めた各地を点々なので、かなり精神的にキます。

加えてキャリアパスがこれでは、組み込み技術者辞めますか、日本人辞めますか、それとも人間辞めますか...そんなフレーズがジョークでなくなりつつあります。

Re:組み込み系の人は本当に心が荒むようですな

[cyber205 (4374)]

>日本では当然よく使われる日本メーカー(ルネサスとか)のマイコンはハードとソフトのトレードオフが狂っていて
>(ちょっとハードを追加すれば...な部分がある一方でソフトでやった方が良さそうな物に
>妙なハードウェアアクセラレーターがついていたり)、組み込み技術者に理不尽な負担を強いる物が多いです。

デジタル方面だけじゃないっスね。
日本メーカーのアンプなんかも昔は相当使いにくいシロモノがゴロゴロしてたはず。

LM386なんかだと、驚くほど少ない部品点数でしっかりアンプが作れるのに、
国産メーカーのアンプICはやたらと外付け部品が必要で、組むのが大変だったりして。
設計センスの良し悪しというのはそういった所に現れるのかと思ったりしました。

>「萌え」などのサブカルチャー系への反感から組み込みへ進んだ方もよくいて、
>そのためかIT系の人を見下して(精神の安定を図って)いる組み込みの人も良くいます。

組み込みよりさらにハード寄りの情報を集めている「トラ技」とかでは
よくアニキャラを貼りこんだ自作ケースを投稿作品に見たりするんですけどね。
もちろん自分の作品をどう作るかは個人の好みだから別にいいんだけど。

うーむ、じゃぁ私は?

[okky (2487)]

プリンタのレンダラ、携帯内蔵アプリ、NASサーバ、3DCGボード、BIOS…うーむやはり組み込みなのかなぁ。確かにアプリ系はあまりやっていないような気がする。つーかそんなに長時間かけていない気がする。
チップセットとCPUとコンパイラの気持ちがわからない奴なんかプログラマじゃない、と思ってるしなぁ。

でも、力でコーディングするのも、プログラマとは呼べないと思ってるものなぁ。
「力でコーディングするプログラムを書くのだ。そう考えない奴は、キーボードの付属品だ!」
とか平気で言うしなぁ。

かといって、
「フレームワーク? 他人が作ったフレームワークなんぞゴミだ。フレームワークは、プロジェクトごとに練り上げていく楽しみの一部じゃないか。それを他人任せにしてどうする!!」
と言う発想は明らかに IT 系じゃないしなぁ。

.

まぁ、「クラウドコンピューターなんて大きな組み込みマシンだよ」と考えれば、組み込み系無敵って事で。

--
fjの教祖様

Re:うーむ、じゃぁ私は?

[gedo (7079)]

チップセットとCPUとコンパイラの気持ちがわからない奴なんかプログラマじゃない、と思ってるしなぁ。

かといって、
「フレームワーク? 他人が作ったフレームワークなんぞゴミだ。フレームワークは、プロジェクトごとに練り上げていく楽しみの一部じゃないか。それを他人任せにしてどうする!!」 と言う発想は明らかに IT 系じゃないしなぁ。

たしかに、組み込み系の場合、リアルタイム性への要求や信頼性確保の関連でITに比べてブラックボックスを嫌うことが多いかもしれません。
自分のしらない所で何かやっているのが嫌というか。
だから、Cであっても生成されるであろうアセンブラを意識してしまうのですよね。

Re:うーむ、じゃぁ私は?

[okky (2487)]

自分のしらない所で何かやっているのが嫌というか。
だから、Cであっても生成されるであろうアセンブラを意識してしまうのですよね。

もし、それが組み込み系技術者が生成されるアセンブラを意識する理由だとするなら、そこは私は違いますね。

私が「コンパイラの気持ちがわかる」といった場合、それは『コンパイラにとって、どれとどれが同じ内容で、どれとどれは違う内容なのか』を意識する、という事です。

一例ですが…最近は少ないでしょうが、昔の大抵のコンパイラは

a = x ? y : z;

と

if ( x ) {
   a = y;
} else {
   a = z;
}

を同じと見なす能力がありませんでした。それぞれに対応する中間コードがあって、それ故にその後の最適化が変わる。で、ごく初期のコンパイラを除いて、三項演算子の方が一般には『効率が悪い』コードを出したのです。gccが始めてこの2つを完全同一視してくれたときは感動したものです。

「同じ内容であってもどう書くかで最適化は変わる」ので、
「コンパイラにとって判りやすい書き方」
「不明瞭な点がなるべく少ない書き方」
という2つの条件を満たした方がコードは早くなりますし、コンパイラが進化したときにコードを書き直す必要性も減るのです。

.

厄介なのは「不明瞭な点がなるべく少ない書き方」という奴でして。「不明瞭な点」があると、コンパイラは最適化を諦めて安全サイドに出力を倒す必要があります。

言語規格上は別にそうしなくてもよい、という理由で gcc が安全サイドに倒さなかったために起こったバグの例としては Linux kernel 2.6.30 と 2.6.30.1 にだけある、セキュリティホールがあります。
http://kenichiokuyama.blogspot.com/2009/07/linux-kernel-zero-day-explo... [blogspot.com]
に説明を書いておきましたので内容に関してはそちらを見ていただくとして。ようするに、こういう問題が起こるので、コンパイラは「最適化をかけてよい条件」をかなり厳しく設定する必要がある。

わかりづらいコードを書くと、人間だけでなくコンパイラも「最適化をかけてよいかどうか」の判断に手間取ります。あまりにも最適化条件に合致しているかどうかの判断がかけずらい場合、コンパイラは「そのコードに、この最適化は適用しない」という判断を下す可能性がある。コンパイラ自身が使えるメモリも、CPUパワーも限界がありますからね。せっかく「早くなるに違いない」と思って駆使したコーディングテクニックが、コンパイラの最適化対象外になったために効率が相殺されてむしろ遅くなるのでは意味がありません。

また、逆にコンパイラの最適化適用規則が甘いとバグの元になる。

それらを可能な限り排除した書き方で書かれたコードが 良いコード なわけです。このような事も含めて、「コンパイラの気持ちがわかる」ようでなくては、プログラマとはいえない、というわけ。

--
fjの教祖様