日本にありがちな“やらされAUTOSAR”による思考停止から解き放たれよ：AUTOSARを使いこなす（4）（2/3 ページ）

車載ソフトウェアを扱う上で既に必要不可欠なものとなっているAUTOSAR。このAUTOSARを「使いこなす」にはどうすればいいのだろうか。第4回では、AUTOSARに何らかの期待を抱いて取り組みを進める上で、避けるべきことについて考えてみよう。

[櫻井剛，MONOist]

利用が不可欠になってからではAUTOSARの持つ可能性は見えてこない

　前述のように、国内でのAUTOSAR導入の初期には、「ソフトウェアアーキテクチャをAUTOSARで規定されたものに切り替える」ということだけに目が向けられてきました。ですから、「従来、各社の固有プラットフォームでできていたことを、AUTOSARスタイルのアーキテクチャに切り替えて実現するだけなら、うれしいことは何もない」というご意見をしばしばいただきました。実際のプロジェクトをまだ手掛けたことのない方々からの事前の予想としてだけではなく、プロジェクトを終えられた方々からの実体験としても、です。

　「アーキテクチャのスタイルの切り替え」の面に限ってであれば、そのご意見はもちろん間違ってはいません。できることが変わらずにスタイルを変えるだけだったら、うれしいことなどほとんど何もありませんし、さまざまな手間や不自由さの方が目立ったとしても不思議ではないでしょう。

　ただ、短絡的に「（アーキテクチャの切り替えという側面以外を含めた）AUTOSAR導入には、うれしいことは何もない」という結論に短絡的に行き着くことは大いに問題です。なぜそうなってしまうのでしょうか。筆者に想像できるのは、失礼ながら、以下のような流れです。

なぜ「AUTOSAR導入には、うれしいことは何もない」と考えてしまうのか

　外的要因で、AUTOSARを使うことが不可欠になるのをただ待つ。実際に不可欠になってからは、可能性について思いをはせる余裕などあるはずもなく、「やりにくさ」に苦しみながらも、取りあえず何とかプロジェクトを仕上げなければならない。

　終わってみれば、「やらされ感」だけが残り、アーキテクチャ以外の面のさまざまな可能性について（考える気がうせる、あるいは、やり遂げたという自信から考える必要がないと思い込んでしまってか）十分に考える前に、「AUTOSARには、うれしいことは何もない」という言葉が出てきてしまう。

　そして、相対的に狭い理解しかできていない未経験者にとっての事前予想とその意見が矛盾しないので、「多数意見」として、「AUTOSAR導入には、うれしいことは何もない」という見方が一層補強されてしまうので、可能性について考えることをやめてしまう。さらに、異を唱えることが一層難しくなる……。

「AUTOSAR導入には、うれしいことは何もない」となってしまう構図（クリックで拡大） 出典：筆者作成

　あながち間違ってはいないのではないでしょうか。

　もし間違っていなければ、たとえ実際のプロジェクトの経験をお持ちの方であろうとも、「AUTOSAR導入の先にある可能性について十分に考えてみる」という機会がなかったのであれば、「AUTOSARを採用してもうれしいことはない」と断言するのはまだ早いということになります。

　もちろん、プロジェクトをやり遂げることは重要です。現場経験が無意味だといいたいわけではなく、むしろ逆です。目立ちにくいとは思いますが、実際には以下のようなことも成し遂げられていることが珍しくありません（他にも多数考えられます）。

• 標準規格の性質（制約など）の中での各種意思決定とあわせ込み
• 外部調達品の性質を考慮した中での各種意思決定とあわせ込み
• 自動車メーカー側のワークフローおよびそこで利用される情報の表現形式への対応

　これらの重要なインプット（現場からのフィードバック）を正確に把握することは、組織的な導入に際しては大変役立つはずです。見逃す手はありません。AUTOSAR導入に当たってはとても重要なことです。

　しかし、当事者がこの価値に気付けないでいること、ここが大きな問題なのです。気付くために十分に検討をする、これが欠かせません。

中間ソリューションの採用は慎重に

　AUTOSAR導入においては、手の付けやすい中間ソリューションを用意するという手法もしばしば採用されてきました。確かに、5〜10年ほど前は、そうするしかなかったこともありました。しかし、中間ソリューションを経るアプローチ（現行→中間→完全移行）に対しては、日に日に否定的な見解が多くなってきているように思いますし、筆者も同様です。その主な理由は以下の通りです。

• 「小さな変化」だけで実現できることだけにしか目が向かなくなってしまう（あるいは、組織が「大きな変化」を受け付けなくなってしまったり、中間ソリューションのようなものが常に存在し機能すると誤認してしまったりする）
• 各段階に特化したつもりで実施した局所最適化が、その次のステップでも制約として残り、レガシー問題化しやすい
• 過渡コストが1回分増えてしまう
• 保守対象のソリューションが1つ増えてしまう
• 過渡コストに対する回収期間は短くなる（場合によっては、回収が遅くなり、完全移行のタイミングが遅くなってしまいかねない）
• せっかくの「期待」が、「実現しやすさ」で極端に制限される（実現可能性による思考の制限）

　中間ソリューションは、あくまで手段の1つです。その段階を持つことで、ショックを和らげるという効果は期待できます。しかし、先に箇条書きで述べたような幾つかの問題点もあります。

　特に、箇条書きで挙げた最後の項目になる「実現可能性による思考の制限」は大きな問題です。下手をすると、期待について検討している中で、思い付いてしまった中間ソリューションに満足してしまい、可能性について考えることをやめてしまうかもしれません。もしもそうなってしまったなら、中間ソリューションとして利用可能な手段によって、期待の検討がズタズタに引き裂かれてしまったことになります。

　「今は大きく変えることはできない」という場面に直面することは少なくないでしょう。しかし、「今は変えられない」という言葉が浮かんだときには、「変えるための計画だけでも立ててみる」ということをどうかお試しいただきたいと思います。そうすることで、見えなかった長所/短所や不確定要素（リスク）といった全体像もある程度把握することができ、覚悟を決めた上での決断につながっていきます。