開発工程が独自。
はまらない開発プロセス
一番直感的に理解できる開発プロセスはウォーターフォールだと思います。
仕様→設計/開発→評価→リリース
まずはまりません。
組み込みに限らないでしょうが、どんなプロジェクトでも、よほど小規模、か日程度外視的なものでなければ、このプロセスははまりません。
「はまらないプロセス」に現実に合わせようとすると、「評価後の変更は許さない」「仕様変更は受け付けない」とか無茶な建前も出てきます。建前と言えど、厳格に適用されてしまう瞬間は組織にはあるから、障害になりますよね。形態化すると機能不全に陥りますから。
「さすがに違う」というところで、最近はリーン開発、アジャイル開発という概念のほうがよく使われます。
ただ、概念を変えても、結局のところは大変。
変化する仕様
開発期間が年単位の製品は珍しくなく、３年、５年とかけているうちに、競合が出たり、環境規制が変わったりします。
そうなると、対応せざるを得ない。売れないから。
しかし、ハードに関しては「今さら変えられない」という「常識」があります。
ハード変更は開発の「やり直し」に近くなるから。
既に調達や工場も動いていたりします。
また、よく言えば「ハードはマージンを持った設計」ができている、ということもあります。
車も基本ベースはなかなか変えないですよね。
変更を吸収するのがソフト。開発全体から見ると「吸収」ですが、ソフト屋から見ると「ねじ込む」感覚。
同じ組み込みでも、モータやセンサを扱うメカトロ制御の分野でこの手の話は多いです。
あまり仕様が変わらない分野ももちろんあります。
組み込みのデータ通信機器開発をやっていた時期もありますが、それはあまりこの手の話はありませんでしたね。
ハードを変えない以上、工場は日程通り準備を始めます。
工場の日程を守るってのは、営業マンが予算を達成するのと同じく、エンジニアが厳守すべきことです。
日程を守るために、どう制御をねじ込んでいくか。
制御の複雑さによっては不具合の温床ですし、「日程遅延」にもつながります。
問題が発生するとメディアも含めて、対外的には「ソフト問題」となります。
このあたりの役回り、立ち回りは力の見せどころです。「目立てる」と前向きな人もいますし、「貧乏くじ」と考える人もいます。若いうちはなかなか「理不尽」に見えることもあります。
