日経エレクトロニクス（1998.3.23）に『ソフト危機』というタイトルで、２１世紀に向けて、民生機器の分野で爆発的にソフトの需要が発生すること、そのために開発期間を短くするための方法や環境の整備が求められること、などについての特集記事が掲載されている。
組み込みソフトを開発している組織であれば、多分、この雑誌は購読されていると思われるので、是非一読してソフト開発組織の行く道について考えて下さい。日本という国の現実を考えたとき、民生機器に組み込まれるソフトウェアが、市場の要請に応えられるかどうかは、国の将来を決する程の意味を持ってきます。
特に、昨今のこの国を取り巻く経済環境を考えると、ここに失敗したら、経済的な意味でこの国の存在基盤は一機に低下してしまいます。もちろん、「政治」の舵取りも大きな問題ではありますが、私たちの立場においては、如何に世界の市場の要請に応えていくかは、明日の日本を決める程の意味を持っています。世界の市場の求めるものを、我々が提供していくことが出来ないかぎり、この国は、あとから来る多くの国に、供給基地としての役割を奪われることになります。
この国は、アメリカのように「世界の頭脳」を持っているわけではありません。最近 IBM 社から発表された「TravelStar 6GT」というHDD の読み出し／書き込みセンサーでコンダクティブスペイサーとして使用されている銅の厚みは，わずか銅原子15個分でしかない、ということです。あるいは、HDD の記憶方法として、原子の単位で記憶させる方法も、実験室レベルでは見通しがついているようです。
残念ながら、このようなレベルの最新技術の供給基地としての役割は果せない以上、優れた「製品」の供給基地としての役割を果せなければ、この国の世界に果す役割は途絶えてしまいます。特に、日本の株式市場が、日本の政府を含む金融機関と海外の投資家によって支えられているという現実を考えると、この国に、投資対象としての魅力がなくなったとき、一気に崩壊する危険をはらんでいるのです。２１世紀の、我が国が提供する組み込みシステムのソフトウェアの出来、不出来は、それほどの意味を持っているのです。
脆弱な開発環境
ところが、組み込みソフトの開発現場は、今でもハードウェアの技術者から転向した人が中心で、ソフトウェア技術の習得が遅れています。つまり、「急造のソフトウェア・エンジニア」なのです。もっとも、厳密に言えば「エンジニア」と呼べるレベルではないのですが、日本では、プログラマーとソフトウェア・エンジニアしか区分されていないため、プログラマーでなければソフトウェア・エンジニアということになってしまいます。これも、問題の根底にあるといえます。
実際には、彼らの多くは「Technician」であって「Enginner」とはいえないのです。ソフトウェア・エンジニアに相応しい技術を持っていません。エンジニアというからには、問題の解決方法を幾つか持っていなければなりません。もちろん、時代に合うように、手持ちの解決方法も入れ換えなければなりません。しかしながら、そうでない人も含めて、すべてをまとめて“エンジニア”と呼んだことで、その時点からエンジニアとしての結果が求められることになります。問題解決の方法を持っていないため、彼らの多くは、「如何にして動かすか」というところに立つことが出来ず、「とにかく動かす」ことに全てが注がれることになります。そしてその代償は、時間の供出です。
ある程度は、それで対応できたことは確かです。特に、組み込みシステムの世界では、昔はソフトウェアのボリュームが小さく、関係者も少なかったため、必要な技術の不足は、持ち時間の供出と、それに支えられた度重なる試行でカバーできたのですが、最近の組み込みシステムのソフトウェアの規模は大きくなり、そこにいる「Engineer」のスキルが追い付かなくなっています。
こうなると、人海戦術は完全に「逆目」に出てしまいます。適切な「開発手法」や「管理技術」を持たない組織が人海戦術を採用すれば、混乱以外の結果は手に入らないことは言うまでもありません。でも、その組織には他に選択肢がないのです。残念ながらそれが現実なのです。「Engineer」に適切な技術を身に付けさせることを怠ったツケが、ここにきて払わされることになったのです。あるいは、エンジニアの立場からいえば、組織の求めるもの（とにかく動けばいいという要求）を満たすだけで、あえてそれ以上のものを身に付けようというしなかったことが、「ソフト危機」を招いているのです。
ＪＡＶＡの動き
組み込みシステムの世界では、急増するソフトウェアの開発需要に応えるには、明快な「方法」が必要です。今までのやり方（人海戦術、休出作戦など）では、品質と納期の両方を実現することは殆ど不可能であることは明らかですし、今後、その傾向がますます強くなっていくでしょう。
需要のあるところに供給がなされるというのは、最終製品の市場だけの話ではありません。ソフトウェアの開発環境も、最近の「Java」の動きを見ていると、そこに「需要」を見ることが出来ます。とくに、マイクロソフト社が、ＨＰで開発された Java の技術を入手したというニュースは、Sun に独占されていた状況に風穴を開ける効果が期待できます。マイクロソフト社は、以前から民生機器に触手を伸ばしていたのですが、これで、Windows CE と小型の Java という組み合わせで、民生機器の分野で Defact Standard を確保すべく動きだすことでしょう。
Java は、もともとオブジェクト指向言語としても洗練された言語であると言われています。開発の容易性などにも優れていることで、開発期間の短縮や、言語仕様の面からの品質の安定に寄与するものと期待されています。もちろん、「品質を織り込む」ためには、オブジェクト指向の概念や考え方は別に習得してもらう必要がありますが、それでも言語の容易性、間違いの入りにくい言語というのは、これからの市場の要請に応えるものであることは間違いありません。
したがって、Sun の Java のライセンス料の高さ(1000円〜2000円）に対抗して、マイクロソフト社が画期的なライセンス料を設定してくれば、組み込みシステムの世界に確実に広がる可能性を秘めています。特に、カーナビや携帯端末の世界では、Java の技術は商品の可能性を一気に広げることも考えられます。
転換を阻害するもの
しかしながら、ここに大きな「問題」が横たわっています。現実に、組み込みシステムのソフトウェアを開発しているエンジニアは、「現状のシステム」の開発に持ち時間の全てを投入していて、新しい、抽象化の概念や考え方、それに連動する新しい言語などを習得する時間が確保されないという問題があるのです。
新しい概念や言語は、それに相応しい開発体制や、それを活かす作業の流れの下ではじめて、その効果を発揮するものです。つまり、それに相応しものに変えなければならないのですが、持ち時間の全てを「今」に投入し、しかも、そこに居る「要員」の全てをも「今」に投入している今の状態は、このような方向転換を大きく阻害することになります。
組み込みシステムの開発現場では、もともと明確な設計手法や実装手法も持たないことが多く、そのうえ、適切な開発手法も手に入れていない状況であることを考えると、新しい概念の習得には大変なエネルギーとリソース（時間、資金など）が必要になることが予想されますが、どこかで大きな決断が為されないかぎり、方向転換が遅れてしまう可能性があります。
現場のエンジニアが、適切な設計手法や実装方法、あるいは開発手法を持たないだけでなく、チームリーダーやプロジェクトリーダーと呼ばれる立場の人たち、あるいは、シニア・マネージャーの立場にいる人たちも、その方向を見定めることが出来ないため、適切な指示を出せず、適確な施策を打つことが出来ない状態にあります。
実際、組み込みシステムのソフトウェアの開発組織で「デスマーチ」に陥っている組織は、少なくないと思われます。その多くは、一度の開発の遅れが、その後の悪循環の始まりとなっています。しかも、その組織には、その悪循環を止める方法をもたないため、一度狂った流れを正常な流れに戻すことができないのです。
組み込みシステムの開発組織は、２１世紀に向かって、時代に相応しい開発環境を手に入れなければならないにも関わらず、このような状況が足枷となって、うまく転換出来ないとすれば、そこにいる多くのソフトウェア・エンジニアも、運命を共にすることになりかねません。
会社の求めるまま？
今日まで、多くのソフトウェアのエンジニアの皆さんは、会社の求めるままに仕事をしてきました。「とにかく動けばいいんだ」と言われれば、そのようにしてきた。見積もり作業も、「ざっくりでいいんだ」と言われれば、本当に「ざっくり」見積もることしかしてこなかった。そこではそれで通用した。
上司の意向が「休出」を望んでいると感じたら、それに応えるように「休出」して対応してきた。もっとも、その代償として、「休出」しないでも同じ結果を出す方法を考えるのを放棄した。一度、身に付けた仕事の仕方（方法）や、一度擦り込まれた考え方が、いざというときに障害になることを想像もせず、兎に角「結果」よりも「努力」を見せることで誤魔化してきた節がある。
その組織も、うまく結果を出す方法を持っていないため、個々のエンジニアの（結果を生まない）努力を評価するしかない。そして、そのような行為（努力）が、それでも評価されることを知った「身体（からだ）」は、次の時も、それで応えようとする。実際、次のプロジェクトも、着手の遅れから前回と同じようにお尻に火が付き、先に身に付けた「努力」の発揮する場面は確実にそこにある。
こうして、多くのソフトウェア・エンジニアは、彼が属する組織の求めるもの「だけ」を提供することで、組織の構成員としての地位を獲得するが、そのことは同時に、エンジニアとしての「市場性」から遠ざかることであることに気付いていない。いや、少しは気付いている人もいるだろうが、具体的な対応方法を持たないかぎり、そのことに気付いても結果は同じである。
隣りの尾根
２１世紀には、民生機器に於けるソフトウェアの需要が爆発的に伸びることが予想される。そこでは、もっと効率的な開発現場になっているだろうし、そこで作業をしているエンジニアも、テクニシャンとの分業によって、より高度な設計作業をこなしているだろう。彼らエンジニアの守備範囲は広く、要件の整理から分析モデルの作成、そして設計作業まで、幾つかのツールを駆使しながら進めていく。ＣＡＳＥツールの発達によって、おそらく、その頃にはソースのコーディングも殆ど行なわれることはないだろう。
したがって、ソフトウェア・エンジニアの仕事は、適切なプロジェクトの開発手法に基づいて、必要な分析設計手法を駆使しながらの作業となるだろう。チームでの作業が増えていくことで、無駄な作業を減らすためにも「開発技法」がますます重要になってくる。
だが、このような流れも、「今」の開発作業もうまく出来ていないエンジニアにとって、その延長上にイメージできるだろうか。実際、２１世紀の尾根は、隣に見える尾根であって、彼らが今いるところの尾根とは繋がっていないのではないか。隣りの尾根に行くには、右手の沢を降りて、川を渡って谷を越え、隣りの尾根に繋がる急な坂道を登っていかなければならない。簡単ではないことは確かである。
多くのエンジニアは、その谷渡りの難しさを考えると、つい今いる尾根をそのまま行こうとする。当面は仕事はあるのだし。その向こうは薄い霧で良く見えないが、この尾根もどこかで右手の大きな尾根に繋がっているのではないかと思う。いや、そう思いたいのである。
だが、私の見たところ、今いる尾根は、そのまま麓の小さな村に降りていくだけで、右手の尾根には繋がっていない。適切な分析・設計手法も持っていない。実装上のノウハウも殆ど持っていない。モジュールの品質に関する知識もない。要求をまとめる力もなければ、分かり易い設計書を書くことも出来ない。プログラムを書かせば、あきれるようなバグを埋め込んでしまう。
それだけではない。プロジェクト管理や工程管理、スケジュール管理、要求管理、構成管理といった「管理」という言葉から逃げ回っているため仕事が約束できない。そしてこれらの不足を補うべく時間を獲得できる仕事の仕方も持っていない。そんなエンジニアでも歩くことの出来る尾根（今まで歩いてきた尾根）が、２１世紀に繋がっていると思うほうが可笑しい。冷静に考えたら、簡単に分かることである。
『ソフト危機』という日経エレクトロニクスの記事は、そのような時代の到来を予感させる。
組み込みシステムの開発に携わっているソフトウェア・エンジニアの皆さんは、新しい技術と適切な管理手法を身に付ける必要があります。それも、あまり時間に余裕はありません。そのためにも、ＣＭＭや約束できるスケジュールの立て方などを研究し、それを身に付けることでリワークを無くし、そうして手に入れた時間を使って新しい技術を習得することです。
現実の仕事を抱えながら新しいことを身に付けるには、８割ぐらいのリソースの投入で今の仕事をこなす必要があります。幸いにも、このような適切な方法を持たない人たち（組織）の作業には、多くのリワークや無駄な作業が含まれています。半年ぐらいの期間だと３割り程度の無駄が含まれているものです。兎に角、２１世紀の尾根に乗り換えるためにも、この無駄に消費されている時間を掻き集める方法を手に入れることです。