********************************************************************** SWEST基調講演テーマ：組込みシステム開発の次の10年を考える講師: 高田広章（名古屋大学　大学院情報科学研究科教授）日時：2008/9/04 13:10〜14:30 聴講者：200名程度 ********************************************************************** みなさん改めてこんにちは、名古屋大学の高田です。 SWESTも10回目だということで、私に基調講演の依頼がきました。ここで私が話をさせて頂くのもはじめてです。頂いたお題は、組込みシステム開発の今後10年を考えるです。今年のSWESTのテーマ自体が過去の10年を踏まえて今後10年どうなっていくか考える。ちょっとこの話に入る前に、過去10年の話もありまして、ふと思いおこして、10年前の1998年当時スライドを探してみました。当時は、ほとんど、私OSの話しかしていないことが判明しました。ご存じの方も多いと思いますが、私自身ITRONを中心にリアルタイムOSの研究開発をやってきましたので、 1999年はITRONのバージョン4の仕様書を書き上げた年ですね。これを見て何を思ったかというと、 10年たつと自分のポジションが変わるんだなぁ〜ということで、これは、私だけじゃなく、みなさんもそうだと思います。今後10年の自分のキャリアパスを考えて、10年後何をやっているのかのサンプルになればと思います。これは8年前のスライドですが、OSの話ばっかりしてますが、当時どんな話をしていたかというと、 10年たっても、あまり変わってないんじゃないかという気持ちも片一方であります。こんなスライドを書いてます。組込みシステムはどんなものかの話をしていて炊飯器から原子力発電の制御まで組込みシステムは幅がある。あとは、組込みシステムの特性などがありますね。次に8年前の動向的なスライドが入ってますね。制御対象機器の変化している。これは、今も変わっていないですね。・高機能化・デジタル化・ネットワーク化・開発期間の短縮それによりシステムの大規模化が起きています。これは、当時私が強調していたようですが「組込みシステム開発のオープン化」当時の組込みシステムは規模が小さくてですね。セットメーカがOSからアプリまで全部作っていたことが多かったですね。それなので、品質保証がしやすかった、バグがあっても自分達で探せる。当時言われていたのが、今まではやれてこれたが、もう無理ですよ。開発期間が非常に厳しくなってきて、今までみたいに自分達で全部作っていると間に合わない。それから、いろんな技術がでてきて、やっぱりネットワークがでてきたことで、いろんなネットワーク技術がどんどんでてきて、 UNIXも作ったTCP/IPも自分たちで実装しました。でもJavaを作れと言われるとちょっとつらいねぁ〜と言う声があって。それで、組込みシステムのオープン化というのが言われてきている・話題になっている。この辺りは、今も昔も変わらないなぁ〜と思って過去のスライドを見ていました。 ○組込みシステム開発を取り巻く状況 10年前から、基本的に変わっていない。従来からの組込みシステムの大規模化・複雑化がどんどん進んでいる。それから組込みシステムの適用分野が拡大している。その結果QCDを同時にすべて満たすのは困難になってきている。クオリティも保て・コストを抑えろ・開発期間も短くしろと言われて 3つ全部満たすのは無理でしょう。というのが現状なんではないでしょうか？分野によって3つのどれを重視して、犠牲にするかが違うと思います。例えば、車載の分野では、クオリティを落とすと危険ですので、コストを犠牲にしている。デジタル家電ではコストを上げると利益がなくなってしまうのでクオリティを犠牲にする。今は、不具合があってもネットワーク経由でアップデートすることができる。それから、少し技術的な話をしますと、パソコンでも同じことが起きてますが、単一のプロセッサでの高速化の限界がきている。ソフトウェア屋が何もしなくても、システムの性能が上がっていく楽に稼げる時代は終わりつつある。性能を上げるためには、ソフトウェアもちゃんと実装していかないとだめ。単一プロセッサで動いていたソフトウェアが、そのままマルチプロセッサでも動いてくれればいいのですが、そう話しはうまくいかない ○組込みシステムソフトウェア開発課題ひとつひとつ言うまでもないけれど・設計品質・信頼性・安全性の確保/向上・設計資産の再利用の促進・新しいハードウェア技術への対応・高信頼性技術・低消費電力・エネルギーシステム技術・組込みセキュリティ技術たくさん問題や課題もありますが、一番深刻なのが、組込みシステム技術者の人材不足なんじゃないかなぁ〜と思います。 ○組込みソフトウェアに関する政府の動き 10年前は、国があまりみていなかったけれど、 5年ほど前から雲行きが変わり、ご存じのとおり、4,5年前にIPA-SECのような組織ができて国も組込みシステムに取り組むようになってきています。今日ご紹介したいのは、総合科学技術会議です。その会議で今年5月に採択された革新的記述戦略があります。これは、今後日本が科学技術の分野で、何をやらなきゃいけないという戦略をまとめたものです。資料はWebからとれますので、興味ある方は、この辺のキーワードで探してみてください、すぐでてきます。産業国際競争力強化の中に組込みシステムソフトウェアが書いてきています。ついに、組込みも国の制作レベルの一番上に書かれるところまできている。 ○組込みシステムソフトウェアの多様化と分類 SWEST1をやっているころからの課題ですが、組込みシステムのひとつのカテゴリですべてを語るのは難しい。 OSでも機械を制御するOSと、情報処理を行うOSでは OSに対する要件がまるっきり違うので当然使う技術が違ってくる。さらに、複雑なのが、実際に組込みシステムを作ろうとするといくつかの技術領域にまたがる。例えば、携帯電話を作ろうとすると、アプリケーションプロセッサの部分は、情報系の組込みシステムの技術だけれども、コミュニケーションの部分はシステムLSIの技術が必要になってくる。 ○組込みソフトウェア開発の方向性 OS屋としてずっと言ってきたことは、応用分野毎にプラットフォームの構築して、そのプラットフォーム上でアプリケーション開発をして現状のC/C++などのプログラミング言語から一つ抽象度の高いモデルベースで設計する方向で進んで行く。これが、ひとつのトレンドなんではないでしょうか？ ○組込みシステム開発のアチーブメント今後の方向性を語る上で課題がたくさんあります。いずれも、雑誌による情報ですが、レクサスLS460に100以上のECU・車載用のコンピュータが積まれている。それから、組み込まれたソフトウェアの総ライン数が700万行にもなっている。開発に6000人年ぐらいかかってらしいことを聞いています。これが、大きなトラブルなしでちゃんと動いている。ヨーロッパで同じようなものを作ろうとして不良がたくさん出た。やや大げさだけれど、日本の組込みシステム開発・日本のエンジニアリングにとってのアチーブメントではないかと思う。月にアポロを降ろしたぐらいのアチーブメントといっていいのではないか？ここから先が問題です。この方法はもう限界で、同じことをやるのは、もう嫌だ。次はもっと複雑になる。 ○近付く組込みシステム開発の限界会社や業界で違うが、納期を守るために、人をどんどんを投入せぜるを得ない。そのための管理オーバヘッドが大きい。そういう開発をやるとセットメーカの社員がソフトウェアを開発がするのはかなりレアケースで、子会社、協力会社、派遣会社がやっていることが多い。ソフトウェアの開発能力が人によって開きがある。人によって10倍ぐらいは違う。 ○次に起こると思われることメカ屋さんにぶつけるつもりで、最初このスライドを作ったんですが、今までは、組込みシステムの開発期間は、まずは製品の出荷時期、製品を2年後のこの時期に出す、ハードの設計期間はここまで、ソフトの設計期間はここまで検証期間ここまでと線表後ろから手前に引かれていました。ですけども、限界にきています。組込みシステムソフトの開発期間が製品の開発期間を決めている。つまり製品の開発期間を決めるボトルネックは、組込みシステムソフトの開発期間になっている。これは、メカ屋さんにはショッキングなことだと思うのですが、 IT業界では当たり前の現象なんですね。例えば、銀行の合併を検証期間の遅れで3ヶ月遅らせるということが起きている。 ○日本のものづくりの特性我々の強みと弱みを整理した上で今後10年の話を進めたいと思います。 ○製品アーキテクチャと比較優位よく組み合わせ型と擦り合わせという議論を耳にされることが多いと思います。興味がある方は藤本先生の本を読んで頂きたい。どういう議論かといいますと、製品のアーキテクチャには組み合わせ型と擦り合わせ型がある。組み合わせ型の典型例はパソコンです。演算性能はマザーボードで決まるし表示性能はディスプレイで決まるし記憶の容量はハードディスクで決まる。それらを繋ぐインタフェースは業界標準になっている。マザーボードとディスプレイは、よほど相性が悪くなければ繋がる。一方で擦り合わせ型のアーキテクチャの典型は自動車です。走行・安定性を保つには、サスペンション・ボディ・エンジンなどその他がうまく設計されて初めて実現できる。乗り心地・燃費も同じです。それぞれの設計を擦り合わせて最適な設計を探り出す必要がある。 ○製品アーキテクチャと比較優位日本のものづくりは擦り合わせと相性がいい。海外を分析するとアメリカ・中国・韓国は組み合わせが得意。ヨーロッパは擦り合わせが得意。 ○組込みソフトウェアと擦り合わせソフトウェアには物理的な形がないので、ある意味どんな方にも設計できる。設計として、組み合わせ型と擦り合わせ型のどちらにもなりうる。放置すると擦り合わせ型になる、つまりこれがスパゲッティプログラムです。それでは大変なので、組み合わせ型しようとすると努力がモジュラプログラムです。組込みソフトウェアは擦り合わせ型に近い。というのは、組込みソフトウェアの特性として非機能制約がある。例えば、リアルタイム制約・メモリ制約・消費電力制約、高信頼性・安全性などがある。非機能制約をモジュール化するのは難しい。 ○日本のものづくりはなぜ品質が高いか？二つ目は、品質です。いろんな方から伺っていると、日本で開発の品質は高いのではないかと思います。だだ一方で、日本のソフトウェア開発のプロジェクト管理は海外に比べるとできているとは言えない。技術者の教育レベルが他国に比べて高いわけでもない。 →技術者の品質意識や士気に支えられているとしか考えられない。どうして日本の技術者はなぜ品質意識・士気が高いか？といろんな方に議論をふっかけて、納得した答えはこれ。設計者での研究者でも製品に不具合が出た場合には、ものづくりの現場までフォローさせられる。欧米は、部署毎のミッションがはっきりしていて、設計部門は、設計をして、設計検証して次に渡したらそれ以降は、自分たちの責任ではない。という会社多いそうです。ものづくりの現場までフォローを経験すると、品質意識が高まる。なぜ、欧米は違うのか？これは、擦り合わせ型であるから。つまり、部署毎のミッションがはっきりしていなくて責任意識を共有している。となりの部署との境界線があまり明確でない。悪い面　責任の押しつけあいこれはよくない。うまくいくと、擦り合わせによる最適設計や高品質化に貢献できる。アメリカのフォードでは、全行程は全員専属スタッフ。日本は一つの工程の専属ではなくて多能工。なぜなぜ分析をもう一段やると単一民族・島国であること。口に出さなくても通じる・阿吽の呼吸が尊重される。つまり、隣の部署との境界を明文化しなくてよい。 ○部分から全体へ鈴木敏夫さんの「映画道楽」の本で、彼の本のなかで、日本の芸術は部分から全体へ作られている。例ででていたのが、江戸時代の武家屋敷で、まずは、床の間から作りだしてから段々と全体へと広げる。宮崎駿の映画は、キャラが先にできてそのキャラを活かすストーリーは何だろうと逆に進んだりする。できたものは建て増し構造（的）になる。このままでは大変。そう言われてみれば、TOPPERS/JSPは、ディスパッチャの呼びだしから作っていた。 ○組込みソフトウェア開発の目指すべき方向日本の組込み開発はボトムアップは得意だが、トップダウンは苦手。お客さまを大事にしすぎではないか？ 9割8割のニーズを満たせばいいのではないか？でないとトップダウンのきれいなアーキテクチャを作れないのではないか？ ○強いところを活かす擦り合わせ型ソフトウェアの開発能力は一段高い技術者の品質意識・士気が高い建て増し構造のものを開発する能力もあるようだ。擦り合わせ型でないと品質があげられない部分を見極める。　プロダクトライン開発手法でいうコア資産　どこがコアかを見極める組み合わせ型のアーキテクチャに中に、擦り合わせができる仕組みを残しておく。ボトムアップ領域を広げる。 ○過剰な擦り合わせに注意日本は擦り合わせは得意だが、裏表に強みと弱みがある。過剰品質に陥っている。日本は擦り合わせは得意だが、やり過ぎてはだめ。 ○次の10年のために課題解決のためのヒント人の重視　プロセスの重視することも、もちろんだが　アジャイルを組込みシステムを適用するのが難しい。職人的技術者の活用すること。　職人的技術者を組織の中で活用しにくい、　それもよく分かるのですが、じゃ〜そういう人を買い殺しにしていいのか？　そうではなくて、そういう人の技能をうまく使うことが大事。　優秀なエンジニアだけを集めて仕事ができるのであれば、　それは、管理も楽だし、うまくいって当たりまえ。　よほど、学生に人気がある会社でもない限り、　なんでもできるオールマイティな技術者だけで仕事をするのは、　普通できませんよね。　人材の得意な部分を活かせるマネージメントができる会社が　いい成果を挙げられる会社であると思います。　職人的技術者がいて、欠点を持っていたとしても、　うまくそういうエンジニアをうまく活かせるように考えなくてはいけない。ファシリテーションも重要。 ○開発できる部分は先に開発しておくソフトウェアの開発期間が商品の開発期間を決めるとなっていいいかというと、よくない。製品の競争力が落ちてしまう。開発管理業務の定式ができれば、開発管理をアウトソースすることができる。優秀なエンジニアがその下に入って、ソフトウェア開発を行うことができる。アメリカのベンチャー企業では、よく技術屋さんが会社を起こして、社長を雇ってくるっていうのが、割とよくある話ですので、そうおかしくはないのではないかと思います。組込みシステムの分類　昔は、分類軸が多くて整理仕切れなかった。開発できる部分は先に開発しておくという考えかたですが、製品のtime-to-marketを短縮するためには、製品開発の開始前にできるソフトウェアは、先行して開発しておく。やっぱりこれしかないんじゃないかと思います。先行開発ですから、納期管理をそんなにきっちりしなくてもいい。そうすると、アジャイル的なものも適用できるかもしれない。そういう意味で開発効率の向上の余地があるのではないかと思います。当たり前ですが先行開発はそんなに簡単ではない。先行開発をしている段階では、製品規格がない。トップダウンに要求してものを作るということができない。将来のアプリケーションの要求と使用できるハードウェア技術の予測を元に開発する。ですから、課題は、予測をはずすリスクも残っているところです。 ○先行開発できる部分 OSやミドルウェアコア資産　何が大事かを分析ができれば、そこを先行開発できる。 ○先行開発促進のためのソフトウェア技術開発期間を守ることは、強く求められない。全体の品質が上がる。本当に大事な部分は、ボトムアップに開発できる。少数精鋭で開発もできる。職人的・芸術的ソフトウェア開発が許容される。アジャイル開発もできる。何を先行開発するか？を分析をすることが重要。 ○先行開発震度をみて製品企画を決める（追加スライド）製品企画において、ハードウェアの技術トレンドをみるのは当然。ソフトウェアの先行開発の進度も見るようにする。　開発期間を守ることが可能になってくる。 ○先行開発のためのソフトウェア技術　プロダクトライン開発　　コア資産　　再利用性の高いソフトウェアの部品化技術が重要。 ○職人的・芸術的ソフトウェア開発の見直し　ソフトウェアの生産性がきわめて高い職人参考：　芸術：人に教えられない、　職人芸：見習うことしかできない　工学：教えられる　芸術は作品を作る　職人は商品を作る　　商品にはQCDがある（作品にはない）作るのが速いけど、バグが多いものを作る学生もいる。でも、ああいう能力も結構大事です。プロトタイプ開発みたいな場面で、そういう人材を使うとすごく有用な気がします。信頼性・保守性を確保するための施策が必要。職人芸で作るのはいいけど、ちゃんと保守できないといけない。職人的・芸術的な技術者が自身が意識改革する必要がある。ツールをうまく使っていくことが大事。 ○取り組み紹介-TECS 　TECS（TOPPERS組込みコンポーネントシステム）ソフトウェア部品を箱にして繋いでいくとシステムを構築していく。特徴は、コンポーネントの粒度が非常に小さい、粒度を大きくしていくのが、コンポーネントと思われるんですが、逆転していていて粒度が非常に小さいです。 ○ASPカーネルの周辺ドライバ等のTECS図これは、OSのシリアルドライバなどの周辺部品をコンポーネントの図にしてみたものです。通常シリアルI/Oドライバでひとつの部品だと思うのですが、ここでは、シリアルドライバをさらにシリアルI/Oコントローラのチップに依存した部分とチップに依存しない部分に分類して作っている。このように、粒度を小さくすると、当然繋ぐオーバヘッドを大きいとですね、影響が大きいわけですが、繋ぐオーバヘッドを小さくするために静的にコンポーネント間を繋ぐというアプローチをとっています。 ○おわりに整理：従来通りの組込みソフトウェア開発手法を続けていると、ソフトウェア開発期間が製品出荷期間を決める。もちろん従来からの開発手法も重視しないといけないし、今やっていることが間違いということは全くないですけど、逆の視点もあるのではないかと思い提案させて頂きました。 ■質疑応答 Q1：職人的・芸術的ソフトウェア開発というところで、話していたと思うのですが、　　工学にするための技術的側面はどういうものですか？ A1：工学にした方がいいが、必ずしも職人芸が工学にできるとは限らない。　　ただここで書いたのは、できたソフトウェアは保守できるものになっている。　　職人芸を工学的支援できることは必要である。　　　　私にとってソフトウェアレビューは工学になっていないんですよ。　　人にソフトウェアレビュー技術を教えろと言われても無理なんですよ。　　ですが、レビューやれって言われればできるんですよ。　　私にとっては職人芸なんです。　　見る視点やテクニック、見ていれば、あぁやってソフトって確認してんだなぁ〜　　ていうのが分かるのかなぁ〜って思います。　　なかなか教えられないというのが本音です。　　きれいなプログラムってなんですがというと、結局ロジックの筋の通って読みやすいもの。　　じゃ〜どうやったらそうかけるかと言うと難しいですね。　　人のプログラムを読んでいてロジックが歪んでいるよ、きれいなのは、こうだと　　直すことはできるんですが、じゃ〜どうやったら最初からそう書けますかというと、　　どうやったらいいかは正直教えられない。　　　　いつも言ってるんですが、「ドキュメントは3年後の自分のために書け」　　人にために書いていると気が進まないんですが、3年後の自分のために書くをわりと書けます。　　一つの意識改革かなぁ〜と思います。 Q2：ソフトの開発だけでなくて　　ソフトを作成した人以外の利用技術や抽象的レベルのもの大事なのでは？ A2：おっしゃる通りで、　　ソースコード以外に、ソフトのアーキテクチャがより大事で　　その中でキーの部分がソースまでちゃんとできている。　　コア資産を作ったらそれをどう活用していくかを含めて開発していくべき。 Q3：コア資産を開発したらまた各会社で閉じこもることにならないでしょうか？ A3：両面あると思います。　　本当に品質のキーとなるコア資産は、自分で握らないといけないでしょうね。　　ただ、これも分野によると思うんですが、OSやミドルやソフトウェアのアーキテクチャは　　ある程度標準が進んでいかないと、自社だけとだと難しいと思います。　　自動車の例でいうとAUTOSARという団体がソフトのアーキテクチャを作ろうとしてます。　　全体はそれに乗りつつ、品質のキーとなるものがこれだと思えば、そこだけは自社で握る。　　棲み分けが必要であると思います。　　あともう一つ、コア資産を売るというのも大事だと思います。　　いくらいいコア資産でも、自社で独占していい場合と、　　やっぱり外にでないといけない場合がある。　　 Q4：職人芸を教えられないだろうか？　　ひとつ何かお考えがないでしょうか？　　レビューをして何かヒントはないでしょか？　　何か統計的にまとめられるものはないでしょうか？　　 A4：はい、アドバイスありがとうございます。　　一度レビューの時に、レビューされた人に何が参考になったかをレポートしてもらう。 Q5：学術的な立場から質問させて頂きたい。　　日本はものを作るものは、うまいと思うのですが、　　国際会議などに出ていると、日本は新規な技術は少ないと思います。　　新規な技術を開発していくことが必要かどうか？　　学術的な立場からお聞きしたいです。 A5：当然必要だと思います。　　どうして、少ないのかというと、　　いろいろ理由があると思いいますが、私が心がけていることは、問題輸出型でいきましょう。　　つまり、多くの日本の大学の研究は、海外の国際会議に出て、今これが流行っているから、　　これをやろうとすると、彼らは、数年間この研究をやっているから、発表しているわけで、　　彼らに勝つには、5倍10倍努力しかない。　　自分で問題を見付けて、まだこの問題に誰も取り組んでいない研究をすることが大事。　　どっから見付けるかは難しいですね。　　我々の場合は、産業界で何が本当に困っているかをよく分析して、　　自分たちの問題を見付ける。　　もう一つは、やや流行の分野に飛びつく傾向がある。　　基本を押さえてからやらないと、インパクトが薄い。　　 Q6：今後10年の新規技術はありますか？ A6：マルチプロセッサ用のRTOSの決定版がまだできていないですね。