車載ソフトウェアを扱う上で既に必要不可欠なものとなっているAUTOSAR。このAUTOSARを「使いこなす」にはどうすればいいのだろうか。第4回では、AUTOSARに何らかの期待を抱いて取り組みを進める上で、避けるべきことについて考えてみよう。
本連載をお読みいただいている皆さま、AUTOSARへの期待については十分に整理できたでしょうか。
もしも、本連載の以前の回をまだお読みではないならば、ぜひともそれらを先にお読みください。また、AUTOSARへの期待が整理できていない方は、そちらをまずは先に片付けてください。たとえ、実際のプロジェクトのご経験をお持ちであったとしてもです。まだ決して先を急ぐ必要はありません。
さて、AUTOSARへの期待を手にしている皆さんは、この先の進め方について何らかのイメージを既にお持ちなのではないかと思います。しかし、パッと思い付くアプローチの中には、行き止まりのもの、未来に続いていかないものも少なくありません。
今回は、避けるべきことの代表例として、「AUTOSARが不可避なプロジェクトの経験からその可能性を見限ってしまうこと」「安易な中間ソリューションの採用」「標準をただ従うものとして捉えること」について述べていきます。
これまでの国内での導入事例の多くは、「AUTOSARの採用」が「ECUプロジェクト受注の必須要件」として海外の自動車メーカーから要求されたのでやむなく対応した、といういわば外的要因による消極的/受動的なものでしょう。
確かに、このような外的要因があれば、ご自身でAUTOSARの必要性を説いて回る必要はありません。また、投資に対する承認などの周囲の説得は、相対的には容易でしょうから、ある意味では気が楽かもしれません。
でも、実際にやることになると大変で、「とにかく何とかやり遂げる、こなす」ということが重要視されたことと思います。そんな中では、AUTOSARの持つ可能性について思いをはせる余裕はなく、「期待」に関する十分な検討や議論を行う機会はまずなかったのではないでしょうか。
そして、「AUTOSARの採用」は、「AUTOSARベースのソフトウェアアーキテクチャの採用」(指定されたBSW/RTEを使用すること)という側面のみで捉えられることが多く、アーキテクチャの切り替えという側面以外に対しては、あまり目が向けられることはなかったように思います。
AUTOSARは決してソフトウェアアーキテクチャだけを決めているのではありません。もちろん、実際にプロジェクトに携わった方々は、「なじみのないXMLファイルを受け取ったり、作ったりしなければならなくなった」という追加の手間についてよくご存じでしょう。しかし、アーキテクチャ以外の部分についての、「なぜこんなアプローチを採用しているのか」というような質問や議論(考えてみること)については、アーキテクチャ(BSW機能など)に関するものに比べて、国内では相対的にとても少ないように思います。
そして、こんな風にして何とかプロジェクトを進めていったとき、現場には最後に何が残るのでしょうか。使いたくて使っているわけではないのに、従来と同じようなことを実現するために、なじみのない用語、アーキテクチャやワークフローへの切り替えを強いられ、「やりにくさ」や「やらされ感」だけが残ってしまっている、というのが実情ではないでしょうか。
Copyright © ITmedia, Inc. All Rights Reserved.