車載ソフトウェアを扱う上で既に必要不可欠なものとなっているAUTOSAR。このAUTOSARを「使いこなす」にはどうすればいいのだろうか。連載第36回は、人材育成の観点からAUTOSARを「学ぶ」ことについて考える。
これまで本連載では人材育成に関して第11回と第12回で取り上げたことがあります。
今回はあらためて人材育成をテーマに取り上げます。AUTOSAR内での教育関連の活動も紹介するなど内容をパワーアップしてお伝えしたいと思います。
「そんなの、AUTOSAR公式Webサイトで公開されているAUTOSAR文書を読み込めば、学べるはずだ」とお考えになる方もいらっしゃるかもしれません。
ですが、これは有識者からは一般に「適切なアプローチ」とは見なされていません。
適切ではないとされる理由の分かりやすい例を一つご紹介します。
最新リリースであるAUTOSAR R24-11の場合、CP(Classic Platform)で234個、AP(Adaptive Platform)で76個、CP/APに共通のFO(Foundation)で71個のファイルがあります。
さて、質問です。どこから読み始めればいいのでしょうか?
残念ながら、その答えがAUTOSAR文書のどこかに書いてあるわけではありません。
そもそも、知りたいこと次第で読むべき箇所は変わってきますし、必要な前提知識も異なります。
また、同じ文書内でも「初期に読むべき内容」「極めて特化された内容」が混在していますので、「この文書のこの章」の後は「別のある文書のこの章」というつながりも見つけ出していく必要があります※1)。
ですから、一般的には、いきなりAUTOSAR文書を読み込もうとするのではなく、「必須知識」を学べる研修が広く利用されています。
※1)実は、標準化活動の中でも、「このトピックでは、この文書のこの章を読んだら、別のある文書のこの章を読む必要がある」ということを、参加するメンバー間で教え合うことも珍しくありません(設立当初から参加の大ベテランからそういった質問が出てくることもあります)。
また、標準化活動に参加する人にそれなりの専門性/前提知識(文書構造含めて)を求めるのは当然ではありますが、標準化活動の中でAUTOSAR文書を執筆する際には、「それに基づく何らかの製品を作ろうとするなら、やはりそれなりの専門性/前提知識があるはず」と想定しているのも間違いありません。実際のところ、AUTOSARは巨大な知識体系であり、それを支える前提知識もまた膨大ですから、それを把握するだけでも一苦労です。
このように、AUTOSAR文書群は、「これからAUTOSARを始めようとする方々」向けに書かれているのでは決してありません。
また、AUTOSARの各種文書には、その成立過程などが分からないと、正しい解釈が難しいものもあります。
「確証」を得ないまま読み進めることで誤解の上に誤解が積み上がってしまうことや、あやふやな情報に振り回されることも珍しくありません(いまだに「AUTOSARは、標準機能SWモジュール/ライブラリ群である」という説明がなされるのを目にすることもありますが、これは、誤りとまでは言えなくとも、大きな誤解を与える/ミスリードするものだと断言できます)。
余談ですが、成立過程の記録や、それを知る人との議論のためには、標準化活動への参加(Associate Partnerではなく、Premium Partnerのようなパートナー資格の取得)が必要になります。
「確証」を得る手段の一つとしての「標準化活動の利活用」については、今回は深くは言及しませんが、BSW(Basic Software)/ツールなどの製品や「確証」を提供する上で、「標準化活動に参加できる資格を持たない」ということは大きなハンディになり得ます。
「基本」「入門」「概要」「最低限の知識」など、「必須知識」に関連した言葉はたくさんあります。
では、具体的に何を指すのでしょうか?
そして、受講後に何ができるようになるのでしょうか?
この問いを軽視するわけにはいきません。
というのも、例えば、Automotive SPICE v4.0では、人的リソースの量、経験、知識およびスキルというニーズの決定(GP 2.1.3)に基づき、割り当てられる(GP 2.1.4)とされていますし、ISO 9001:2015でも(clause 7.1.6)、ISO 26262-2:2018でも(clause 5.4.4)、またISO/SAE 21434:2021でも(clause 5.4.2[RQ-05-07])、必要な知識や能力の明確化が求められているからです。
さて、広く採用されている業界で共通のAUTOSAR教育カリキュラムのようなものがあれば、少なくとも「どのような教育研修を受けてきたのか」を示すことは可能でしょう。
しかし、そのカリキュラムによって「何ができるようになるのか」が明確でないとき、人的ニーズ(特に「○○できる」という要求)と対応付けることは容易でしょうか? もしそれが容易ではないのであれば、それはもう人的リソース面でのリスクそのものであり、また負担(説明コスト)にもなります。
また、AUTOSAR CPに関する多くの入門コースではRTE(Runtime Environment) APIの概要を解説していますが、実際にAUTOSARに関わる方々の「関わり方」は千差万別です。
例えば、AUTOSARのCPを用いた開発プロジェクトでBSWのサービスを利用しないApplication SW-C(Application Software Component)を、モデルベース開発ツールを用いて開発する」ということであれば、BSW機能に関する知識どころか、RTE APIについて知る必要もありません※2)。
※2)機能の実現のために、BSW機能が利用できないという判断(言い換えれば、Application SW-Cとして本当に実装という判断)のためには、BSWとしてどのような機能が提供されているのかを把握する必要はあります。
しかし、SWアーキテクチャ設計が適切に行われていて、単体SW-Cの開発だけを任されるのであれば、BSW機能の知識も必要ありません。
また、「インテグレーションテストのうち特に通信部分を担当する方」と絞り込んでみたとしても、必須の知識は異なります。
例えば、テスト仕様作成のためのインプットが通信マトリクスであり、それがAUTOSAR形式(ECU ExtractなどのAUTOSAR XML)である場合には、そのデータ構造やパラメータの意味(結果的には詳細な機能/振る舞い)をどの程度理解し解釈しなければならないのかは、ツールによる各種の「支援」の内容や程度(例:インプットデータ内容の表示や、テストケースの自動生成など)によって異なってくるでしょう。
つまり、「必須知識」は個々の役割で行う活動/作業に依存すると言えます。
役割名称(例:役職名)だけでは、その実際の活動/作業内容と必要な知識が明確になるとは限りませんし、それを定かにせずに決められた「基礎知識」と称するものを学べば十分だとは限りません。
もちろん、従事する業務内容によっては、さらに広い範囲の前提知識が求められることも少なくありません。
Copyright © ITmedia, Inc. All Rights Reserved.