本論に入る前に、先週の「MATLABのビジネスから見る知的生産性とは」の記事について、ある方からコメントをいただいた。【「MATLABのビジネスから見る知的生産性とは」の記事について】
ブログいつも拝読しております。
MATLAB と Simulink には上記のような試行錯誤で作り上げる職人芸のような要素はない。
とありますが，ここは私はちょっと別の感想を持ちました。
というのは，最近ではクルマの制御ソフト開発で，MATLAB/Simulinkからの自動コード生成がかなり普及していて一部のサプライヤでは，MATLAB/Simulinkの枠内で，職人芸的なことをやっていると思います。なので，一概に「ない」とも言い切れない状況かなと感じるのです。
MATLAB , Simulink が、研究者と開発現場のエンジニア、科学技術を必要としている企業の橋渡しとあるように，自動車業界でも，自動車メーカーとECUサプライヤの間では，MATLAB/Simulinkモデルが仕様書のスタンダートになっています。自動車メーカーが作ったモデルは確かにdoubleの世界ですが，これを受け取ったサプライヤは，モデルがマイコンで走る実際のソフトになるようfixed pointに書き換えるなど，実装に伴う苦労をしているわけです。
10年前は自動車業界でも，その苦労は一般の組み込みソフト開発と同じCプログラム上での試行錯誤でしたが，現在では自動コード生成が普及し，すっかりMATLAB上での試行錯誤に変わっています。
要は，『MATLAB/Simulinkだと職人芸がない』というよりも，『職人芸をインプリする抽象度が，より上のレイヤーに移っている業界も中にはある』というのが現実ではないでしょうか？
以下に詳しい資料があります。
●日経エレクトロニクス 2003年12月22日号，no. 863，What's New，p.27.
「ソフト開発でトヨタら先駆け，量産品に自動生成のコード」
●日経エレクトロニクス 2005年8月29日号，no. 907，What's New，p.42.
「自動コード生成の適用拡大，トヨタが来年開発車種から」，
【引用終わり】
メールをもらって、「なるほど、組込み業界の中でも自動車業界は進んでいる」と思った。でも、これって巨大な市場がある業界だからだろうなって気もした。いずれは多くの組込み業界もC言語プログラムをすり合わせるのではなくモデルをすり合わせるような方向に進んでいくのだろう。しかし、どんなに時代は進んでも組込みには職人芸が付きものっていうのがいいね。
さて、今回の記事の本題に入ろう。
このブログを読んでいるのは必ずしも組込みソフトエンジニアではないと思う。IT系のソフトウェアエンジニアもいるだろうし、学生やアカデミアンもいるだろう。
つい最近、組込みソフトを経験していないどころか、技術系でもない方に「いったい組込みソフトってなんですか」と聞かれたことがある。毎日毎日組込みソフトのことを考えていると、周りの人のが持っている組込みソフトの知識レベルは何ら変わっていないのに、自分の中だけで知らず知らずのうちに周りの人も組込みソフトについてよく知っているかのように思ってしまう。
何か一つのことにのめり込んで知識を蓄え、そのことについて友人からとんちんかんなつっこみをされるとつい「そんなことも知らないの？」とバカにしてしまう。その傾向がどんどん強まっていくとその人は周りの人からオタクと言われるようになる。
さて、組込みソフトエンジニアが外部のコミュニティで活動していると、組込みや組込みソフトのキーワードに触れる機会が多くなり、「組込みの認知度が高くなってきたから、組込み機器や組込みソフトに対する理解者は何もしなくても増えるだろう」と勝手に楽観的な未来を想像してしまうことがある。
でも、それは間違いだ。組込みや組込みソフトが世の中のどんなところで役に立っているのか、また、パソコンのアプリケーションソフトの作り方と何が違うのかについての説明を積極的に発信していかないと、組込みや組込みソフトの対する理解は深まらない。
そこで、今回は「組込みソフトはどのように作られてきたのか」について書いてみたいと思う。これは『組込みソフトエンジニアを極める』の第一章に書いてある内容に近いが、第一章に書いた視点とはまた別の視点で組込みソフトの原点を考えてみた。
[1] 組込みソフトの誕生
そもそもマイクロコンピュータが生まれる前は組込みソフトなるものは存在していなかった。現在の巨大化した組込みソフトは組込みソフトが誕生したときに比べると求められている役割が変わっている。現在、組込みソフト開発の現場で起こっている数々の問題は、組込みソフトに求められる役割の変化について組織の上位層やベテランエンジニアが理解できていないことに原因があるように思えてならない。
そう考えると、組込みソフトが誕生したときの最初の役割がなんだったのかについてきちんと理解しておかないと、現在の変容した役割との差異が明確にならないし、その差異を説明することもできない。
マイクロコンピュータが発明され一般の製造業種にも利用できるようになると、組込み機器の開発の中にこれまでにはなかった新しい環境が生まれた。当然だが、そのころ製造業の中には組込みソフトエンジニアどころかソフトウェアエンジニアと呼ばれる職種もなかった。もちろん、そんな昔でもメインフレームなど大型計算機の世界ではソフトウェアエンジニアは存在していたし、製造業に携わる技術者も大学なので大型計算機を使ってプログラムを書く経験はしている。（プログラムの一行一行を一枚のカードにパンチして読み取らせたりしていた） でも、メインフレームのソフトウェアを書くことを仕事をしていたエンジニアと組込み機器の開発から生まれた組込みソフトエンジニアの出発点は実はまったく異なる。極論を言えばメインフレームの世界で培われたソフトウェア工学の技術は組込みの世界でも使えるけれど組込み向けにテーラリングしないと現場に浸透しない場合が多い。その原因はこの出発点の違いだと常々思っている。
マイコンが初めて組込み機器に使われるようになったころ、ハードウェアエンジニア、特に電気系のエンジニアの中では、アナログ系とデジタル系という役割分担はおぼろげながらできあがってきていた。自然界に存在する情報はアナログ情報だからセンサでセンシングするときはアナログ設計の技術が必要だ。しかし、アナログ情報をデジタルに変換した後はデジタル系のハードウェアエンジニアの出番となる。デジタル系のハードウェアエンジニアは規格化されたロジックデバイスを組み合わせて目的のデジタル回路を設計していく。
マイコンが登場したときにマイコンをプリントP板上に配置し、他のロジックデバイスと接続したのはデジタル系のハードウェアエンジニアだ。そして組込みソフトエンジニアが誕生する以前はデジタル系のハードウェアエンジニアがマイコンのプログラムを書いた。
デジタル系のハードウェアエンジニアは当時どのように仕事をしていたのだろうか。だいたい、次のような手順で仕事をしていたと考えて大きな間違いはないだろう。
<昔のデジタル回路の設計手順>
- デジタル回路の使用目的を考え、必要なロジックデバイスが何か目星をつける
- ロジックデバイスには必ず部品メーカが作ったデータブックがある。このデータブックを読んで、使用目的に耐えうるかどうか調べる
- 選んだロジックデバイスをつなぎ合わせて回路図を作る
- 実際にロジックデバイスの部品を入手し、マルチP板（穴がいっぱいあいていてすべての配線を自分で半田付けして行うためのP版）に部品を配置し設計した回路図どおり配線する。
- 電源をつないで思った通りに動くかどうか試してみる
- ダメだ。動かない。3にもどって回路図や配線を見直し想定した動きになるまで繰り返す。
- マルチP板の試作ボードが動いたら、本番用の配線をプリントしたP板を設計し生産する。
- 上がってきたP板に部品を載せ半田付けして完成させる。
この流れのうち、3～6の繰り返しは非常に効率が悪い。場合によっては部品を壊してしまったりもするので、きちんと完成するまでにどんどん時間は過ぎていく。この失敗の繰り返しを積み重ねていくとその製品や製品群に合った回路のパターンが見えてきて、その回路のパターンを再利用することになる。実際にうまくいった実績を持つ回路は珍重されることになり、新人は一から回路を設計するのではなく、先輩達が作った実績のある回路を眺めて、それを参考にするという手順が生まれる。
こんなことを繰り返しているデジタル系のハードウェアエンジニアのところに、マイコンという電子部品が現れた。マイコンという部品は他のロジックデバイスの接続に成功していれば、プログラムを書き換えることで上記の3～6を繰り返す必要がなくなる。組込み機器への入力の変化に応じて出力を変えたいときなど非常に便利だ。電子回路で要求仕様を満たすすべての組み合わせを設計していたら配線が間違っていたり、仕様が変わったりして手戻りが非常に大きい。
でもマイコンを使えばプログラムを書き込んだROMを差し替えることで間違いや仕様の変更に対応ができる。このころマイコンは自由度の高いシーケンサーだった。デジタル系のハードウェアエンジニアはロジックデバイスの延長線上としてマイコンという部品を見ていたと考えられる。
当時ROMに書かれていたプログラムは処理の流れのシーケンスが書かれていたのであって、ソースコードが設計要素のすべてであり、設計仕様やテスト仕様などの情報は必ずしも必要ではなかった。仕様書やテストの結果がなくても、誰からも怒られることもなかった。 なぜか？ それはソースコードはたいした量ではなかったし、ちょっとだけコメント書いておけば、どんなシーケンスで動いていくのかソースコードを追うことで理解できたし、ソースコードを追っかけることは回路図の配線を確認することと対して違いがなかったのである。
また、電子回路のテストはよっぽどのことがなければ、シミュレーション環境を用意して事前に確認するような大がかりなことはしなかったから、回路図の見直しや配線のチェックは机上でしていたものの本当の思った通りに動くかどうかは試作用のP板を作るまではわからなかった。要するに動かしてみて、その動作から問題点を見つけて直すという手順だ。
マイコンが導入されたころは、これと同じ手順でプログラムが作られた。頭の中でシーケンスを思い浮かべながらコードを書き、プログラムをROMに書いて電源を投入し「さあ、動くか！」と息を飲む。
いろいろなパターンを想定してプログラムを作ったから、そのすべてのパターンを実際にテストしてみて、動作を確認しながら完成度を高めていく。
[2] そこで現役を卒業した技術者はソフトウェアはそういうものだと考え思考が止まる
シーケンスプログラムを実装し、試行錯誤で想定したパターンを実際にやってみて完成度を高めるという手順でプログラムを書いていたデジタル系のハードウェアエンジニアが管理職になって自称「ソフトウェアを作ったことのある」プロダクトマネージャや技術部長クラスになるとどうなるか。
<デジタル系ハードウェア技術者出身のプロダクトマネージャの頭の中>
- ソフトウェア（実際頭の中に浮かんでいるのはプログラムコードのこと）はソースコードが設計図
- 実装してからいろいろなパターン（テストケース）を試して完成度を高める
- バグが残るのは想定したパターン（テストケース）に抜けがあるからであり、パターン（テストケース）の想定漏れは経験のなさからくる
このような経験を持つ上司のもとで巨大化した組込みソフトウェアを作らなければならない組込みソフトエンジニアは間違いなく苦労することになる。
バグの原因はすべて「パターン（テストケース）の想定漏れ」であり、その原因は「エンジニアの経験不足」になってしまうからだ。
人間の脳の情報処理は具体的な体験、経験を階層的に抽象化しながら記憶していき、蓄積された記憶に新たに刺激を与えて出力されたアウトプットで思考が進む。だから、具体的な体験や経験の抽象化の階層が浅いと具体的な自分の経験に合致しない出来事は理解できないか、自分の体験に一番近いもので連想された答えが自分の感覚としてアウトプットされる。
だから、ソフトウェアのバグ＝経験不足が原因という結論になってしまうのだ。実際、20年以上前なら、試行錯誤の経験を積んでいけば想定するパターン（テストケース）の漏れがなくなり、不具合も減っていった。
その成功体験だけで、21世紀のソフトウェア開発を同じように考えられたらたまらない・・・ が、現実にはそういった現場はたくさんある。
教育の現場でも同じような環境が発生する可能性はある。
なぜなら、ソフトウェアの設計技術として、要求の分析やアーキテクチャ設計、検証、妥当性確認などの意味や考え方、方法論を学生に教えずに、プログラム言語のテクニックだけを教えていると前述の昔のデジタル系ハードウェア技術者と同じようにソフトウェアエンジニアではなくプログラマを作ってしまうからだ。
そうなると、次の思考の呪縛から抜けきれない。
- ソフトウェア（実際頭の中に浮かんでいるのはプログラムコードのこと）はソースコードが設計図
- 実装してからいろいろなパターン（テストケース）を試して完成度を高める
- バグが残るのは想定したパターンに抜けがあるからであり、パターン（テストケース）の想定漏れは経験のなさからくる
この問題を解決するために、次回の記事では、マイコンがシーケンスをトレースする役割から変革していった過程を書きたいと思う。
