現役エンジニアも、ままならないのに若手なんて・・・という声も聞こえてきそうな昨今である。オジサンたちの世代として期待したい若手からのリアクションなどどこ吹く風だとでもいうのだろうか。どこかでリングが途絶えてしまったようにも思えるし、リングが互いにつながる事を期待しているフシもある。新入社員全員にマイコンキットを配ったという時代もあった。といっても四半世紀以上も前の話である。かの日本電気が作り出した8ビットマイコンのトレーニングキットTK80というのがその内容だ。遅れて富士通もグループで開発した16ビットマイコンのトレーニングキットLKIT-16を安価に社員に配布したといわれている。EEPROMのメモリにモニタープログラムが書き込まれていて、若干のSRAMにソフトウェアを打ち込むことが出来る16進の入力キーが付いていた。表示できるのは7セグメントのLEDのみである。手足など何も無い・・・。出来るのは、機械語の書き込みと実行あるいは停止である。

そんな時代から四半世紀以上が流れて、千円たらずの雑誌の付録にボード搭載済みの16ビットシングルチップマイコンと開発支援用のソフトウェアCDROMが添付される時代となった。なにせ昨今の技術革新からシリアル接続さえすれば、内蔵のＦｌａｓｈメモリに書き込んだりデバッグするためのモニタープログラムが用意されている時代なのである。外付けするものといえば応用基板との接続のための連結コネクタや、そこに載せるシリアルレベル変換ユニットだろうか。TK80やらLKIT16を見てきた世代のおじさん達にしてみると、なんともうらやましい限りの環境といえるのだが、流行のRJ45コネクタサイズのEthernetユニットとシリアル接続させてみようとか、色々思索をするのである。一枚の基板とその雑誌に特集された記事などから期待されるのは日本のエンジニアの発奮なのだと思い至るのであるが、出版社が企画をしてチップベンダーや部品メーカーなどと協賛を募って起こそうとしていることに政府の援助の欠片すらないようだ。

こんな環境を提示してみても、最近の若者では何も興味も示さないというのだろうか。手足がない達磨のようなものを示してみても、自ら手足を拡張した姿を夢見るなんてことはないのだろうか。マイコンの本質であるところのプログラミングや機械語の動作原理などどこ吹く風で最近ではC言語あたりが機械語に相当するらしいのだ。ともすればスタックもFIFOもプログラミングテクニックの範疇としての理解でしかないのかも知れない。まあアーキテクチャとして機械語やアセンブラを習得する必要は無いのだとすれば、RTOSなどもC言語で書くという時代らしいので、教育不要ということなのかも知れない。そんな時代を反映してのことなのか、ソフトウェアの効率などドコカに消えてしまい高速マイコンのお世話になりマイコンとメモリーメーカーのWinWin路線によって成り立つような鈍重な時代となってしまったらしい。わざわざ、もっさりとしたJavaなどでソフトウェアを書かせるのもそうした時代背景なのかも知れない。

おじさんの感性には時々付いていけないような現実に出くわすのだが、悪い夢だと良いのだが・・・。どこかのメモリーメーカーが言っていたのは、これからの携帯電話には256Mが必要になるかも知れないといっていたのだが、てっきりビットの話をしていると思ったのだがバイトらしいのである。少なくとも現行でも128MバイトがRAM容量として必要らしいのである。鈍重なアプリケーションをさらにわざわざマルチタスクにして並行動作させるということらしい。複数のアプリケーションが一つの画面や端末をシェアリングしながら動くというのは実は大変なことなのだと思うのだが設計が単純化するので、マルチタスクにするのだという。確かにWindowsCEの画面ほどもあるような端末が登場してくるらしい時代が近いこともあってのことなのかも知れない。マルチタスクというのはWebサーフィン中に電話に応答したり、電話帳を広げたりすることを指すらしいのだ。果たして、それはマルチタスクというのだろうか。

組み込みマイコンの歴史の中で、一本コーディングのソフトというものがあった。OSなどがなくずるずると芋づる式に長い長いロジックを書いてあるものである。驚いたことにマイコン黎明期のみならずに後年の電子交換機ソフトにもそうした構造のソフトウェアがあったらしいのである。ソフトウェアのカスタマイズはベースとなるソフトをだらだらと修正して仕上げていく方針らしいのである。まあこんなソフトウェアでも機能が満たされていればすばらしいソフトウェアといえたのかも知れない。自動車電話のソフトウェアもこうした時代があった、OSを持たずに割り込み処理とメイン処理とで処理分担動作しているのであった。私が設計した当初モデルなどもそうした構造だった、今ほどに複雑な機能もなく、ともかく呼処理と萬マシンが動作さえすればよいのであった。端末動作のシステムクロックが充分なものともいえなかったのでOSが動作する余地が無かったともいえるのだが。

ROM容量が16kBを越えるあたりからRTOSのことを考えるようになってきた。最初に採用したRTOSはマルチタスクではないもののシングルタスクで処理をキューイングしていくものだったが、実体としてのタスク設計には充分なものだったからでもある。その当時のRTOSのシステム設計をした人の言葉を借りれば、同時に物事が動作すると設計がめんどくさくなって仕方がないというのである。反論する人の意見の多くは優先する処理があるというのだが、「マイコンが動作するソフトでどれほど優先する仕事を待たせるというのだ。イベントが起きてマトリックスの処理をする、ただそれだけなのだから100uSも動作するはずが無いだろう」というのである。彼の設計したRTOSでは次に起動するタスクが最優先度のものとなる構造となっていたのである。メッセージパッシングのシンプルな構造とシングルタスクのシステム設計は最近の北欧メーカーの携帯電話にも構造といえる。イベントとマトリックスの処理という考え方をせずにだらだらと一本コーディングした複数のソフトウェアをそれぞれタスクとして位置づけるような輩もいるようであり、RTOSにシステム責任を委ねてしまっているようにも映るのだが、いかがなものだろうか。

おろかなコーディングをするものを許容するのがRTOSだというのであれば、それは一面正しいとも思うのだがまさかコンシューマ製品となっているような端末機器のソフトウェア設計にそんなものを許すはずは無いのではないだろうか。並行処理として動作しているかのように見せるという方法論は、シングルタスクという構成であっても書く工夫は出来る、ただしそうした工夫せずともできるのがRTOSに期待されていることなのでもあろう。最近では、DLLなどを書き起こしていくためにもC++などの仕組みが有効に活用できるという事例もあるし、実際問題組み込みだからといって昔ながらにCやアセンブラで汗をかきながらベタベタとリアルタイムタスク設計をしているということも無いだろうと思っているのだが。そんな話題を知己に振ってみてもさびしい返事が返ってきたりするのも時代なのだろうか。手配師となったメーカーでの技術者像から透けて見えてくるのは、ソフトウェア開発は工数計算して人月で手配するものだということなのだろうか。

進まない開発のなかで表面化した問題があれば共有してお馬鹿なコーディングはしないようにしましょうとチームにニュースを流し、同様な事例が無いことを確認させたりするようだ。こんなサイクルを回していても技術者としての生きがいなどがあるはずもないだろう、組み込み開発に魅力を感じないというのは、こうした現場エンジニアの環境からの反映なのではないだろうか。子供達に誇れるような仕事として紹介するのも憚られる忙殺される事態では、健康系の子供が溌剌と選択する職業候補になりようもない。夢を語れるエンジニアが仲間にいたりする環境下で働いた経験を持つと目を輝かす技術者になる素養は磨かれる。そうした技術者コミュニティがある会社には未来もあるだろう、しかし素養があるからといって自分自身の仕事の中で尊敬する仲間達の仕事ぶりを自分に当てはめることなく忙殺されていては曇ってしまうものである。磨かない原石が自分にある少し透けた部分を称して宝石だなどと考えているのでは先が思いやられるのである。

グループとしてのモチベーションを向上させていく術には何か秘策があるのだろうかと最近は考えたりもするのだが、伸び伸びと仕事をさせてあげて疲れるような仕様変更を繰り返しウォータフォールを破綻させるのではなく、少人数で試作を続けるスパイラルな開発スタイルなどが良いのかもしれないと極限状態で達観したようなお客様の事例などからは感じたりもするのである。失敗を恐れずに挑戦を続けていくというスタンスに必要なことは、自らの手で取り組んでいくと言うことなのだが、同じような境遇にあって全く別の答えが出てくる姿を見ているとプロパー社員で開発リーダーの主体を取らずに、すべて外注に任している会社と、自分達が設計していくという観点に立ちつつ開発リードをして手助けとして外注を使おうとしている会社との差らしい。何せプロパーでない外注会社の社員にしてみれば責任の一端までをとりたくはないというのが第一にあるだろう。そうした会社の多くが一つの外注会社だけで構成されているわけではないから、余計に人的な精神ネットワークに障害が生じやすいのである。

チップセットビジネスを展開しつつ現実的な実装による仕様実現を考えつつ、効率的で競争力のある製品化の手助けとなるソリューションを提供していくことが求められていることなのである。残念ながら開発の仕組みや人材が育っているお客様ばかりではないので、つまらない質問や社内コミュニケーションの悪さの結果として同一プロジェクトの中ですらもハードとソフトあるいは無線などの担当者間での問題共有がはかられているわけでもない。しかし、自分達が提供しているビジネスの本質がテクノロジーを提供するサービス業なのであるという本質を忘れてしまっていてはこうしたお客様との間のインターフェースに支障が生じてしまうのである。自分達が理想と考える姿に、少しずつお客様自身の技術力や開発の仕方やコミュニケーションのイロハから含めて教育していくこともサービスの一環として捉えていくことが必要なのだと思う。お客様に対してのサービスとして教育していくことのビジネスの基本を忘れてしまっていると、お客様が受け取る印象が忽ちに悪くなってしまうのである。

まずはお客様の設計のスタンスを手続き型の考えから脱却させることへのリラクゼーションをせずに、単に方法論としてイベントドリブンなスタイルを押し付けてみても、お客様からの理解など得られよう筈もない。日本の携帯電話開発を蓄積してきたお客様の考えとのギャップを考えつつこなれたメッセージとしての教育を心がけない限り無駄になってしまうのである。教育という機会を通してお客様に与えるサービスと、サポートする自分達の技術力を高めるための契機として捉えて前向きに昇華することが求められているのである。アプリケーションエンジニアという仕事の内容が中々世の中に理解されないでいるのは、こうした前向きな方向での仕事としてやっていくのだという思いとは、別に現実として中々自分達自身で達成しえていないからなのだろうと思うのである。ただしそうした思いを絶えず気に掛けてフィードバックを果していくことが必要なのだと思う。四月になり新たなメンバーが加わったり、新たなお客様が増えたりという環境の変化の中でこそそうしたことの精査が必要だと思っている。

まあ、緻密に積み上げてきたと設計エンジニア達が考えているRTOSベースでのソフトウェアの構造はある意味で、通信キャリアの仕様を満たすための方策だったに違いない。きめ細かな工夫という名前のバグの温床だったりするグローバル変数などによる状態フラグなどによるコーディングスタイルで対処したりしつつ納期と品質という名前のバグ対処を行ってきたのが歴史でもある。グローバル変数のない、イベントドリブンなオブジェクト指向な設計方法で基本的にスムーズな開発であったとしても、まだまだ従来の手続き型のきめ細かさに追従していくためには蓄積が必要な状況でもあるだろう。これからの一年余りで天動説から地動説ともいえる全ての設計スタイルを切り替えて必要な部品や構造の改善などを図りつつ進めていくというのが我々が考えている進め方なのだが、果たして呼応するメーカーのエンジニアの方々が直面している個別環境の相違などで進め方にも結局二色の色分けに陥ってしまう可能性がある。幸いどちらのお客様も身近にサポートしていく立場でもあり不備を学びを成果を共有していくというスタイルを追及してきたいと思うのである。

こうしたチャレンジをしていく際に、出来る限りあらたなテーマに考えていくということを若手技術者に求めていくことこそ最良の教育であると思うし、そのための前段階の教育として現在までの設計思想を伝えるのも教育なのであると思う。教育という仕組みが学校にしかないと思い込んでいる政府だったり、子供が減少して教育機関としての存亡を賭けて最高学府の姿を目指している高等専門学校などの姿も見え隠れする。若手エンジニアやこれからエンジニアを目指す次代の子供達に対して、ソフトウェアエンジニアの楽しさを伝えていくことも大きなテーマだといえるのだが、この辺りは次の五年間のテーマとして考えていこうと思っている。残された半年の期間で現状からの舵取り切り替えを果していくことが最大の課題だと思っている。