ソフトウェア品質シンポジウムの基調講演でトヨタ自動車常務役員の重松崇氏の話を聞いた。トヨタの重松氏はESECなどの組込み系、ソフトウェア系のイベントでよく講演しているのを見掛ける。
もともと重松氏はソフトウェア技術者としてのたたき上げではなく、根っからの車屋から車載ソフトウェアを任されたという経歴を持つ。では、なぜバリバリのソフトウェア技術者ではない重松氏が組込みソフトウェア系、品質系のイベントに呼ばれるのか？ それはもちろんトヨタ自動車が日本だけでなく世界的に高い業績を上げている企業であり、トヨタ式と呼ばれるハードウェアの生産方式と同じように、ソフトウェアの開発にもトヨタ式と呼ばれるものが存在し、それを真似すれば高品質のソフトウェアをアウトプットできるだろうと多くの人が期待しているからだ。
さて、重松氏は90分の講演時間のうち、半分以上を使って現在と未来の自動車に求められること（エネルギー効率のよいモビリティの追求と安全の確保）を語った。さすがだと思う。つい最近、JR のSuicaのプロジェクトを牽引した椎橋氏の話を聞いたが、椎橋氏も講演のほとんどの時間、鉄道を利用するお客さんの利便性を向上するために自分がやってきたことをとうとうと語っていた。
ようするに組込みは業務ドメインを知り尽くし、顧客要求（トヨタの場合は顧客というより地球や人類のことを考えているとのこと）を高める意志と戦略を持った者が、ソフトウェア開発のどこに力を入れればよいのかわかるということだ。（これはビジネス系のソフトも同じか）
でも、なぜ重松氏は車に特化したソフトウェア開発戦略をわざわざあっちこっちでレクチャーするのだろうか。その情報の公開はトヨタにとってどんなメリットがあるのか？
これは予想だが、トヨタはトヨタのソフトウェア戦略を公の場でしゃべることで、トヨタ社内やサプライヤのソフトウェアエンジニアに対して自分達の考え方を浸透させたいのだと思う。トップの方針を末端まで届けたいという意志があるに違いない。それに重松氏がしゃべった内容は、すぐに日経エレクトロニクスなどに取り上げられちまたの話題となる。なぜなら、冒頭で書いたように日経エレの読者はトヨタ式のソフトウェア開発方式がすべての業務ドメインに使えるだとうと期待しているからだ。
でも、特に組込みソフトの世界ではすべてのドメインに共通して有効な解法はない。なぜなら、業務ドメインや組織によって、市場要求や得意な技術、リアルタイム性などの性能要件、メモリ、CPUパフォーマンスなどの制約条件、組織成熟度、エンジニアのスキルがバラバラだからだ。でも、ツールベンダーやプラットフォーム提供者は、必ず自分たちのソリューションがすべて組込み開発に有効であるかのように宣伝するので気をつけた方がいい。こういうのにコロッとやられてしまう鴨ネギタイプのエンジニアやマネージャは組織の中に必ずひとりやふたりはいるものだ。
さて、重松氏は自動車に搭載する約60のECU群を今後4群に減らしていくと言っていた。自動車におけるECUのプラットフォームを共通化し、ソフトウェアの連携によって多様な要求（交通インフラから上がってくる情報を使って危険回避するような要求）に対応していくそうだ。
この施策の最大のリスクは、エネルギー効率のよいモビリティの追求と安全の確保のうち「安全の確保」の方が危うくなる可能性があるという点だ。
ECUが物理的に分かれ責務分割されている状態では、各ECUが起こす不具合、バグの責任は明確で、ECU別に責務の重さやソフトウェア品質の検証のハードルの高さを変えることができた。でもECUの数が少なくなってしまうと、責務の分割や安全の重要性はソフトウェアの中を見ないと分からなくなる。アーキテクチャを可視化して、システムの安全を確保するための安全アーキテクチャが確立されていることをソフトウェアの範疇で証明しなければいけない。安全クラスの低いアプリケーションソフトがメモリリークを繰り返して、重要なソフトに影響を与えないことを証明しなければいけない。ソフトウェアは人間が作っているモノなので絶対大丈夫とは言い切れないし、誰かがちょこっとなおした1行の変更がシステムに大打撃を与える可能性も否定できない。
ECUの数を極力少なくするのなら、ソフトウェアの安全設計、安全アーキテクチャが絶対に必要だと思う。大規模・複雑化したクリティカルデバイスにおいては、安全アーキテクチャは今後重要なテーマになっていくだろう。また、プラットフォームの共通化のメリットがデメリットを上まわる自信がないといけない。組込みソフトはいろいろなトレードオフのバランスの上で顧客満足を確保しているのだ。
さて、重松氏はモデル駆動開発についてサラッと問題点を口にしたが、自分は大事なその一言を聞き逃さなかった。それは「戦略なきプラットフォームの共通化は失敗（プラットフォームベンダにいいようにやられる）する」ということばだ。
プラットフォームの共通化・モデル駆動開発ということばに踊らされて、商品の価値を高めることができるという確信がないままに、共通プラットフォームを採用してしまうと後々商品開発の基盤をプラットフォーム提供者に握られてしまうことに気がつく。重松氏はこの例として、ヨーロッパの共通規格団体 AUTOSAR が Windows を車載ソフトの共通プラットフォームとして採用する提案をしてきたので、日本の共通化団体の JasPar で使えない部分があることを証明してAUTOSARに進言したという例で語っていた。
重松氏の話を聞いていてトヨタは自前で自動車のソフトウェア全部を作り上げるつもりはないように聞こえた。サプライヤからのソフトウェア供給は今後も続くという考えのようだ。そうなると、クライアントとなる自動車メーカは難しくなっていくソフトウェアの理論についてどんどんうとくなり、サプライヤ側は自動車を取り巻く環境の詳細を把握しきれなくなる。トヨタの重松氏やJRの椎橋氏のように車や鉄道のことを知り尽くし、ソフトウェアの品質がどうあるべきかがわかる技術者がだんだんいなくなって顧客要求をよく理解しないソフトウェア技術者が作ったプログラムを自分たちの商品に実装せざるを得なくなってくると思う。
これはかなり危ない。車や鉄道の特性やリスクを知らない、意識しない技術者が作ったソフトウェアは間違いなく危ない。その機器が使われる場面においてどんな危険やリスクがあるのか知らないツールメーカのツールやプラットフォームも危ない。どうしてもそれらを使うのなら、それらが危なくないことを証明する責任は採用した側にある。それだけは忘れてはいけない。
P.S.
「トヨタはソフトウェアでもトヨタ式を提唱していくつもりなのか？」という会場からの質問（電通大のにしさんより）に対して、重松氏は「生産方式には自信があるが、ソフトウェアについてはむしろ外部の知恵（例えばソフトウェア工学で培われたプロセスアプローチなど）を取り入れていきたいというようなことを語っていた。トヨタ式ソフトウェア開発は参考にするべきもので、生産方式のように安易に真似してはいけないということだ。Blogger のコメントは読みにくいので本文の方に入れてしまいました。
自動車エンジニアさん さんは書きました...
もともと重松氏はソフトウェア技術者としてのたたき上げではなく、根っからの車屋から車載ソフトウェアを任されたという経歴を持つ。では、なぜバリバリのソフトウェア技術者ではない重松氏が組込みソフトウェア系、品質系のイベントに呼ばれるのか？ それはもちろんトヨタ自動車が日本だけでなく世界的に高い業績を上げている企業であり、トヨタ式と呼ばれるハードウェアの生産方式と同じように、ソフトウェアの開発にもトヨタ式と呼ばれるものが存在し、それを真似すれば高品質のソフトウェアをアウトプットできるだろうと多くの人が期待しているからだ。
さて、重松氏は90分の講演時間のうち、半分以上を使って現在と未来の自動車に求められること（エネルギー効率のよいモビリティの追求と安全の確保）を語った。さすがだと思う。つい最近、JR のSuicaのプロジェクトを牽引した椎橋氏の話を聞いたが、椎橋氏も講演のほとんどの時間、鉄道を利用するお客さんの利便性を向上するために自分がやってきたことをとうとうと語っていた。
ようするに組込みは業務ドメインを知り尽くし、顧客要求（トヨタの場合は顧客というより地球や人類のことを考えているとのこと）を高める意志と戦略を持った者が、ソフトウェア開発のどこに力を入れればよいのかわかるということだ。（これはビジネス系のソフトも同じか）
でも、なぜ重松氏は車に特化したソフトウェア開発戦略をわざわざあっちこっちでレクチャーするのだろうか。その情報の公開はトヨタにとってどんなメリットがあるのか？
これは予想だが、トヨタはトヨタのソフトウェア戦略を公の場でしゃべることで、トヨタ社内やサプライヤのソフトウェアエンジニアに対して自分達の考え方を浸透させたいのだと思う。トップの方針を末端まで届けたいという意志があるに違いない。それに重松氏がしゃべった内容は、すぐに日経エレクトロニクスなどに取り上げられちまたの話題となる。なぜなら、冒頭で書いたように日経エレの読者はトヨタ式のソフトウェア開発方式がすべての業務ドメインに使えるだとうと期待しているからだ。
でも、特に組込みソフトの世界ではすべてのドメインに共通して有効な解法はない。なぜなら、業務ドメインや組織によって、市場要求や得意な技術、リアルタイム性などの性能要件、メモリ、CPUパフォーマンスなどの制約条件、組織成熟度、エンジニアのスキルがバラバラだからだ。でも、ツールベンダーやプラットフォーム提供者は、必ず自分たちのソリューションがすべて組込み開発に有効であるかのように宣伝するので気をつけた方がいい。こういうのにコロッとやられてしまう鴨ネギタイプのエンジニアやマネージャは組織の中に必ずひとりやふたりはいるものだ。
さて、重松氏は自動車に搭載する約60のECU群を今後4群に減らしていくと言っていた。自動車におけるECUのプラットフォームを共通化し、ソフトウェアの連携によって多様な要求（交通インフラから上がってくる情報を使って危険回避するような要求）に対応していくそうだ。
この施策の最大のリスクは、エネルギー効率のよいモビリティの追求と安全の確保のうち「安全の確保」の方が危うくなる可能性があるという点だ。
ECUが物理的に分かれ責務分割されている状態では、各ECUが起こす不具合、バグの責任は明確で、ECU別に責務の重さやソフトウェア品質の検証のハードルの高さを変えることができた。でもECUの数が少なくなってしまうと、責務の分割や安全の重要性はソフトウェアの中を見ないと分からなくなる。アーキテクチャを可視化して、システムの安全を確保するための安全アーキテクチャが確立されていることをソフトウェアの範疇で証明しなければいけない。安全クラスの低いアプリケーションソフトがメモリリークを繰り返して、重要なソフトに影響を与えないことを証明しなければいけない。ソフトウェアは人間が作っているモノなので絶対大丈夫とは言い切れないし、誰かがちょこっとなおした1行の変更がシステムに大打撃を与える可能性も否定できない。
ECUの数を極力少なくするのなら、ソフトウェアの安全設計、安全アーキテクチャが絶対に必要だと思う。大規模・複雑化したクリティカルデバイスにおいては、安全アーキテクチャは今後重要なテーマになっていくだろう。また、プラットフォームの共通化のメリットがデメリットを上まわる自信がないといけない。組込みソフトはいろいろなトレードオフのバランスの上で顧客満足を確保しているのだ。
さて、重松氏はモデル駆動開発についてサラッと問題点を口にしたが、自分は大事なその一言を聞き逃さなかった。それは「戦略なきプラットフォームの共通化は失敗（プラットフォームベンダにいいようにやられる）する」ということばだ。
プラットフォームの共通化・モデル駆動開発ということばに踊らされて、商品の価値を高めることができるという確信がないままに、共通プラットフォームを採用してしまうと後々商品開発の基盤をプラットフォーム提供者に握られてしまうことに気がつく。重松氏はこの例として、ヨーロッパの共通規格団体 AUTOSAR が Windows を車載ソフトの共通プラットフォームとして採用する提案をしてきたので、日本の共通化団体の JasPar で使えない部分があることを証明してAUTOSARに進言したという例で語っていた。
重松氏の話を聞いていてトヨタは自前で自動車のソフトウェア全部を作り上げるつもりはないように聞こえた。サプライヤからのソフトウェア供給は今後も続くという考えのようだ。そうなると、クライアントとなる自動車メーカは難しくなっていくソフトウェアの理論についてどんどんうとくなり、サプライヤ側は自動車を取り巻く環境の詳細を把握しきれなくなる。トヨタの重松氏やJRの椎橋氏のように車や鉄道のことを知り尽くし、ソフトウェアの品質がどうあるべきかがわかる技術者がだんだんいなくなって顧客要求をよく理解しないソフトウェア技術者が作ったプログラムを自分たちの商品に実装せざるを得なくなってくると思う。
これはかなり危ない。車や鉄道の特性やリスクを知らない、意識しない技術者が作ったソフトウェアは間違いなく危ない。その機器が使われる場面においてどんな危険やリスクがあるのか知らないツールメーカのツールやプラットフォームも危ない。どうしてもそれらを使うのなら、それらが危なくないことを証明する責任は採用した側にある。それだけは忘れてはいけない。
P.S.
「トヨタはソフトウェアでもトヨタ式を提唱していくつもりなのか？」という会場からの質問（電通大のにしさんより）に対して、重松氏は「生産方式には自信があるが、ソフトウェアについてはむしろ外部の知恵（例えばソフトウェア工学で培われたプロセスアプローチなど）を取り入れていきたいというようなことを語っていた。トヨタ式ソフトウェア開発は参考にするべきもので、生産方式のように安易に真似してはいけないということだ。Blogger のコメントは読みにくいので本文の方に入れてしまいました。
自動車エンジニアさん さんは書きました...
先日、コメントを書かせて頂きました『自動車エンジニア』です。
また、コメントさせて頂きます。
-----------------------------------
プラットフォームの共通化・モデル駆動開発ということばに踊らされて、商品の価値を高めることができるという確信がないままに、共通プラットフォームを採用してしまうと後々商品開発の基盤をプラットフォーム提供者に握られてしまうことに気がつく。
----------------------------------
確かにそのとおりだと思います。
自動車業界でいうと、モデルベース開発がMATLABという１つのツールに依存しすぎると、ツールベンダーに主導権を握られるリスク当然はあります。
実際そうなりつつありますが...
MathWorksがマイクロソフト状態にならないように、MAAB、J-MAABなんかでも、MathWorksにソフト改良への要求などを（強気に?）行って、かなり牽制しようとしてますが...
デンソーなんかは、ツールベンダーに依存しなくてよいような方向を志向しているのかどうかわかりませんが、最近はプラットフォーム環境を内製化しようとしてしいる感じは、各公演等から感じられます。
トヨタでも同じようなことは考えられているかもしれません。
----------------------------------
重松氏の話を聞いていてトヨタは自前で自動車のソフトウェア全部を作り上げるつもりはないように聞こえた。サプライヤからのソフトウェア供給は今後も続くという考えのようだ。
----------------------------------
参考までに、トヨタは自前で組み込み用のＯＳの開発を行っているようです
あくまで、メディアの情報です。
【トヨタ、「クルマＯＳ」独自開発】
【50人体制の開発組織・トヨタ正発表】
【経済産業省、車載標準OSを開発へ--トヨタや日産らが参加】
トヨタも現状は、サプライヤーにソフトの供給を依存しているかもしれませんが、もしかしたら、将来的に自前でいくことも考えているのかしれませんね。
ただ、本当の戦略？？です
-----------------------------------
これはかなり危ない。車や鉄道の特性やリスクを知らない、意識しない技術者が作ったソフトウェアは間違いなく危ない。その機器が使われる場面においてどんな危険やリスクがあるのか知らないツールメーカのツールやプラットフォームも危ない。
----------------------------------
自動車業界にいる者として、真摯にご指摘を受け止めなければなならないと思います。
現状、車メーカー側には組み込みのエキスパートは少ないように感じます。
いくつかの車メーカーはグループ内にＥＣＵメーカーをもっていて、組み込みは子会社のＥＣＵメーカーに任せて、車メーカーはシステムのアルゴリズム開発に注力するという方向かもしれませんが、それが、大問題の原因になるとのご指摘かと思います。
車メーカー：組み込みの素人、制御アルゴリズムや車両の特性には詳しく、ロジック開発のみやる
⇒どんどん、組み込みに疎くなる。
⇒【組み込み技術】と【制御ロジック/制御対象特性】の両方を把握するエンジニアがいなくなる。
システム/組み込み開発で全体を把握でる人がいなくなり、部分分のみの知識/経験しかない人だけになると絶望的になる。
さらに、自動車の特性に関する知識に疎いツールベンダーが、人命を預かって走る車において、ＥＣＵの組み込みの根幹を握るようにると、さらに怖いというご指摘かと思います。
（間違っていたらご容赦ください）
車メーカー側は組み込み技術の向上（組み込みエンジニアの育成も含めて）を真剣に考えていかなければいけなかと思います。
最後は車メーカーが全ての責任をとらなければいけませんので、組み込みＥＣＵの責任も最後は車メーカーが持たなければなりません。
私も、組み込みに関する知識不足を痛感しています。
最近、組み込み関連の本を何冊か購入して勉強していますが...
『組込みソフトエンジニアを極める』も今、読ませて頂いております！
ＥＣＵメーカーの組み込みエンジニアとも情報交換及び、今後のシステム/組み込み開発のやり方を議論する場なども定期的にもっていたりします。
----------------------------------
こういうのにコロッとやられてしまう鴨ネギタイプのエンジニアやマネージャは組織の中に必ずひとりやふたりはいるものだ。
----------------------------------
私もそんな１人ですね（笑）
ベンダーの営業トーク（いいことしか言わない）によくコロッといったりします（笑）
9月 08, 2007
自動車エンジニアさん、コメントありがとうございます。
自動車エンジニアさんは本当に自動車のソフトウェア開発にお詳しいですね。
自動車のソフトウェア安全については、ISO 26262 の策定が進んでいると思いますが、ソフトウェアの安全性を分析する考え方として MISRA-SA というのもあります。
どっちにしても、ソフトウェアの安全性は電気的安全性のようにはっきりと白黒つけることは難しいので、エンジニアがどれだけ客観的な根拠・証拠をもってシステムの安全性や信頼性を証明できるかどうかにかかっていると思います。
自動車ソフトウェアの安全性は、これまでソフトウェアエンジニアがユーザーの要求や機器のメカニズムを熟知しており、どんな風に使われるのか、どんな風に ハードソフトが動くのか知っていてソフトウェアを作っているということで担保されていた部分が大きかったと思いますが、これからは誰がどんなソフトウェア を作り込んでしまうか分からないという前提で、ソフトウェアの安全性や信頼性が確保されていることを客観的に示していかないといけないと思います。
モデルベース開発は安全を客観的に示すための有力な方策の一つだと思いますが、モデル変換のソフトウェアを作っているエンジニアが特に車のメカニズムを意識していない場合、意図しない洩れや抜けにより変なコードが埋め込まれてしまう可能性はあると思います。
ただ、「理系白書から考えるソフトウェア工学」で書いたように、モデルベース開発が自然科学を相手にしているうちは正しく変換できているという信頼性をVerification（検証）することは難しくないと思います。
しかし、自然科学以外のすり合わせ的ソフトウェアアーキテクチャをモデル駆動開発に取り込んでいった場合は、信頼性の証明やシステム全体のValidation（妥当性確認）は難しくなってくると予想します。
組織内部の Closed のすり合わせ的アーキテクチャ・アルゴリズムの安全性や信頼性は、そのハード・ソフトが使われる場面や要求を実現するメカニズムを熟知しているソフトウェ アエンジニアの「慎重さ」「そのソフトウェアが安全を担っているという使命感」のようなものが確保していたのが本当のところでしょう。（要求通りに作られ ているかどうかを検証するのは Verification です）
これからは、その安全アーキテクチャ、安全ソフトウェアをカプセル化して、他の安全クラスの低いソフトウェアから隔離し、影響を受けにくいソフトウェアの構造を作っていかないといけないと思います。
これは ECUが物理的に分かれていることで責任分担され証明しやすかった状態に比べると、自信を持って「安全です」と言えるところまで持っていくのに時間も手間やソフトウェア的工夫もいるだろうと予想しています。
自分は自動車ドメインのエンジニアではありませんが、このブログでもその方策について考えていきたいと思います。
9月 08, 2007