日本人と仕事

久しぶりの投稿です。「組込みソフトウェア工房」の投稿ルールを2007年からちょっとだけ変更することにします。

変更前：投稿は基本的にあるテーマについて分析・検討した記事で、「である」調で書く。
変更後：投稿はあるテーマについて分析・検討した記事と､四方山話を書いた日記の2種類とし､前者は「である」調、後者は「ですます」調で書く。

ということで「である」調なら記事､「ですます」調なら日記になります。今回はですます調なので日記です。

さて、昨日 EEBOFのイベントで福岡システムLSI総合開発センターにてプロダクトラインワークショップに参加してきました。

プロダクトラインワークショップの中身については EEBOF のサイトに載ることを期待しつつ、今日は別の話題について書きます。

【九州の産業について】

日経ビジネスのポッドキャストで聞いたのですが、今門司税関で取り扱われている物品の金額が非常に伸びているそうです。門司から輸出する金額はもちろん輸入も増えているとのこと。

それをふまえて、福岡システムLSI総合開発センターを訪ねるにあたって福岡システムLSI総合開発センターのWEBサイトを眺めてみました。すると、アジア地域(京畿道（韓国）、九州、上海、新竹（台湾）、香港、シンガポール等を結ぶシリコンシーベルト地帯というくくりがあって、シリコンシーベルトの中でサミットやワークショップが開催されていることがわかりました。

世の中東京中心に回っているような感覚もありましたが、九州が独自に経済活動の範囲を作って活動されていることに驚かされました。

福岡システムLSI総合開発センターも非常にきれいな建物でヤフードームも近くにあり、九州に拠点を置きたい企業のためのオフィススペースを用意するなど、いろいろなくふうをかいま見ることができました。

【日本人と仕事について】

九州のプロダクトラインワークショップが終わって羽田に着いたのが PM8:15。ここから電車で帰るか、リムジンバスで帰るのかが迷うところ。どっちも自宅までは2時間くらいはかかるので、乗り換えの回数を考えて今回はリムジンバスを選びました。羽田からリムジンバスで帰るのは初めてです。

非常に幸運なことに首都高は渋滞なし。首都高では環状線を通り5号池袋線に抜けて外環道方面に向かいます。

環状線を通るときに東京の都心のオフィスビルを30分近く眺めていました。オフィスビルで働いている人たちとそれをリムジンバスの窓から眺めている自分、このシーンがおもしろかったです。

火曜日の夜9時ごろ、10階建て以上の高層ビル、なぜかブラインドで中を隠していないオフィスがたくさんあります。夜9時だと、ほとんどの社員が帰っているのかと思うと、ある島だけは男女あわせてまだ帰宅しそうにない人たちもいます。オフィスに10～20%くらい人が残っているビルがたくさんあります。

不夜城というほどのイメージはありませんが、やっぱり日本人は夜遅くまで働いている・・・「エコノミックアニマル」と言われるのもしょうがないのかなあと思いました。

この働いている人たちとそれを眺めている自分という構図がおもしろいと思ったのは、オフィスの中で火曜日の夜9時に働いている人を瞬間的にリムジンバスに移動させて、自分たちの様子を客観的に見てもらうと「俺たちはなんでこんな時間まで働いているんだろう」とつぶやく人もいるだろうなと感じたからです。

組織という閉鎖された空間では当たり前となってしまっているいろいろな事柄が、組織の外から見ると普通ではなく見えることはよくあります。

日本人が働きすぎているということをイメージでとらえたいときには、夜9時ごろ首都高速をリムジンバスで走るといいですよ。

そのイメージをつかむと、自分や自分の組織を外から客観的に見たときの違和感みたいなものが見えてくるかもしれません。

今後の予定

組込みソフトウェア工房の読者のみなさま、明けましておめでとうございます。

2007年になって、みなさまにお知らせすることがあります。このブログは2006年の下半期から毎週末更新することを目標にして、実際にそのペースで記事を書いてきました。

ブログだけが原因ではないのですが、2006年を振り返ると家庭と仕事とコミュニティ活動のバランスが均等ではなく、家族と過ごす時間が十分でなかったと反省しています。週一回のブログの更新を実現しないといけないという目標が他のいろいろなことの優先度を下げることになっていたことは事実です。

そこで2007年の年初の抱負として家庭と仕事とコミュニティ活動のあんばいがよい状態を保つことを考えることにしました。

これは家庭と仕事とコミュニティ活動をそれぞれちょうど1/3になるようにするということではありません。どれかを集中的に行うこともあると思います。

ということで、本ブログの更新は状況によって不定期になります。

ご面倒ではありますが、RSSを登録していただき更新があったかどうか定期的にチェックしていただきますようお願いいたします。

P.S.

睡眠時間を増やすと頭がスッキリし、体調がよくなることが正月休みでわかりました。テレビやインターネット、パソコンもしばらく触らないでいると、これまで見えていなかったものが見えてきたりもします。

ネット中毒というのも恐ろしいものです。人間らしさを維持することで人間の役に立つものづくりができるの考えると、たまにはネットから距離を置く、積極的に休むということも組込みソフトエンジニアに科せられた使命ではないかと休みの間、考えていました。

目に見えぬ読者がこのブログの記事を待っていると思って記事を書いてきましたが、これからは自分のひらめきを忘れないようにメモしておくのだと考えたいと思います。

バーチャルな世界が大きくなっても、現実世界は必ず存在し、現実世界は自分だけで動いているのではないということを常に認識していないといけませんね。

組込みソフトの作り方[1]

本論に入る前に、先週の「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板上に配置し、他のロジックデバイスと接続したのはデジタル系のハードウェアエンジニアだ。そして組込みソフトエンジニアが誕生する以前はデジタル系のハードウェアエンジニアがマイコンのプログラムを書いた。

デジタル系のハードウェアエンジニアは当時どのように仕事をしていたのだろうか。だいたい、次のような手順で仕事をしていたと考えて大きな間違いはないだろう。

<昔のデジタル回路の設計手順>

1. デジタル回路の使用目的を考え、必要なロジックデバイスが何か目星をつける
2. ロジックデバイスには必ず部品メーカが作ったデータブックがある。このデータブックを読んで、使用目的に耐えうるかどうか調べる
3. 選んだロジックデバイスをつなぎ合わせて回路図を作る
4. 実際にロジックデバイスの部品を入手し、マルチP板（穴がいっぱいあいていてすべての配線を自分で半田付けして行うためのP版）に部品を配置し設計した回路図どおり配線する。
5. 電源をつないで思った通りに動くかどうか試してみる
6. ダメだ。動かない。3にもどって回路図や配線を見直し想定した動きになるまで繰り返す。
7. マルチP板の試作ボードが動いたら、本番用の配線をプリントしたP板を設計し生産する。
8. 上がってきたP板に部品を載せ半田付けして完成させる。
   

この流れのうち、3～6の繰り返しは非常に効率が悪い。場合によっては部品を壊してしまったりもするので、きちんと完成するまでにどんどん時間は過ぎていく。この失敗の繰り返しを積み重ねていくとその製品や製品群に合った回路のパターンが見えてきて、その回路のパターンを再利用することになる。実際にうまくいった実績を持つ回路は珍重されることになり、新人は一から回路を設計するのではなく、先輩達が作った実績のある回路を眺めて、それを参考にするという手順が生まれる。

こんなことを繰り返しているデジタル系のハードウェアエンジニアのところに、マイコンという電子部品が現れた。マイコンという部品は他のロジックデバイスの接続に成功していれば、プログラムを書き換えることで上記の3～6を繰り返す必要がなくなる。組込み機器への入力の変化に応じて出力を変えたいときなど非常に便利だ。電子回路で要求仕様を満たすすべての組み合わせを設計していたら配線が間違っていたり、仕様が変わったりして手戻りが非常に大きい。

でもマイコンを使えばプログラムを書き込んだROMを差し替えることで間違いや仕様の変更に対応ができる。このころマイコンは自由度の高いシーケンサーだった。デジタル系のハードウェアエンジニアはロジックデバイスの延長線上としてマイコンという部品を見ていたと考えられる。

当時ROMに書かれていたプログラムは処理の流れのシーケンスが書かれていたのであって、ソースコードが設計要素のすべてであり、設計仕様やテスト仕様などの情報は必ずしも必要ではなかった。仕様書やテストの結果がなくても、誰からも怒られることもなかった。　なぜか？　それはソースコードはたいした量ではなかったし、ちょっとだけコメント書いておけば、どんなシーケンスで動いていくのかソースコードを追うことで理解できたし、ソースコードを追っかけることは回路図の配線を確認することと対して違いがなかったのである。

また、電子回路のテストはよっぽどのことがなければ、シミュレーション環境を用意して事前に確認するような大がかりなことはしなかったから、回路図の見直しや配線のチェックは机上でしていたものの本当の思った通りに動くかどうかは試作用のP板を作るまではわからなかった。要するに動かしてみて、その動作から問題点を見つけて直すという手順だ。

マイコンが導入されたころは、これと同じ手順でプログラムが作られた。頭の中でシーケンスを思い浮かべながらコードを書き、プログラムをROMに書いて電源を投入し「さあ、動くか！」と息を飲む。

いろいろなパターンを想定してプログラムを作ったから、そのすべてのパターンを実際にテストしてみて、動作を確認しながら完成度を高めていく。

[2] そこで現役を卒業した技術者はソフトウェアはそういうものだと考え思考が止まる

シーケンスプログラムを実装し、試行錯誤で想定したパターンを実際にやってみて完成度を高めるという手順でプログラムを書いていたデジタル系のハードウェアエンジニアが管理職になって自称「ソフトウェアを作ったことのある」プロダクトマネージャや技術部長クラスになるとどうなるか。

<デジタル系ハードウェア技術者出身のプロダクトマネージャの頭の中>

1. ソフトウェア（実際頭の中に浮かんでいるのはプログラムコードのこと）はソースコードが設計図
2. 実装してからいろいろなパターン（テストケース）を試して完成度を高める
3. バグが残るのは想定したパターン（テストケース）に抜けがあるからであり、パターン（テストケース）の想定漏れは経験のなさからくる
   

このような経験を持つ上司のもとで巨大化した組込みソフトウェアを作らなければならない組込みソフトエンジニアは間違いなく苦労することになる。

バグの原因はすべて「パターン（テストケース）の想定漏れ」であり、その原因は「エンジニアの経験不足」になってしまうからだ。

人間の脳の情報処理は具体的な体験、経験を階層的に抽象化しながら記憶していき、蓄積された記憶に新たに刺激を与えて出力されたアウトプットで思考が進む。だから、具体的な体験や経験の抽象化の階層が浅いと具体的な自分の経験に合致しない出来事は理解できないか、自分の体験に一番近いもので連想された答えが自分の感覚としてアウトプットされる。

だから、ソフトウェアのバグ＝経験不足が原因という結論になってしまうのだ。実際、20年以上前なら、試行錯誤の経験を積んでいけば想定するパターン（テストケース）の漏れがなくなり、不具合も減っていった。

その成功体験だけで、21世紀のソフトウェア開発を同じように考えられたらたまらない・・・　が、現実にはそういった現場はたくさんある。

教育の現場でも同じような環境が発生する可能性はある。

なぜなら、ソフトウェアの設計技術として、要求の分析やアーキテクチャ設計、検証、妥当性確認などの意味や考え方、方法論を学生に教えずに、プログラム言語のテクニックだけを教えていると前述の昔のデジタル系ハードウェア技術者と同じようにソフトウェアエンジニアではなくプログラマを作ってしまうからだ。

そうなると、次の思考の呪縛から抜けきれない。

1. ソフトウェア（実際頭の中に浮かんでいるのはプログラムコードのこと）はソースコードが設計図
2. 実装してからいろいろなパターン（テストケース）を試して完成度を高める
3. バグが残るのは想定したパターンに抜けがあるからであり、パターン（テストケース）の想定漏れは経験のなさからくる
   

このような経験しかしていない技術者の卵の軍団が会社に入ってきて、プロダクトマネージャや技術部長クラスのの思考回路もこんな感じだったら、サンドイッチになったソフトウェアエンジニアはどうすればいい？

この問題を解決するために、次回の記事では、マイコンがシーケンスをトレースする役割から変革していった過程を書きたいと思う。