AUTOSARの最新リリース「R23-11」（その1）＋SDVに取り組むための心構え：AUTOSARを使いこなす（31）（5/5 ページ）

[櫻井剛，MONOist]

3.3 必然以外を決め急がず、必然の種類も区別する／開発者だけではなく利用者もプレイヤー

　さて、ここからは少々抽象度の高い内容になりますので、読みにくいかもしれませんが、実は、アーキテクチャ設計の一般的な内容を述べているだけですので、我慢してしばしお付き合いいただければと思います。

　ある意図の実現手段は、その下の階層ではさらにさまざまな実現手段にブレークダウンされていきます。手段間は、必要があれば互いに連携しますし、各手段はさらに必要に応じてブレークダウンされ、下の階層に伸びていきます。逆に、下から上の方にたどって行けば、最後にはサービス利用者の意図（あるいはサービス提供側の想定に対する、それを利用すると決めた利用者の想定に対する肯定の意思決定）にたどり着きます。

　この一連のブレークダウン構造の一部分を開発する際、その「開発対象の領域」の中では、「周囲から与えられた要求／制約」を完全または限定的に満たしていくこととなります。何らかの限定をつければ、それは、他の階層や周囲のものに対する制約（周囲から見たら、使用上の指示）を付け加えることになります。周囲から見たら、「周囲から与えられた要求／制約と、その実現上の限定（制約）」が「サービス提供側の想定」となります。これは、「開発対象の領域」が、a）全体の階層構造の中にある階層の中で下位階層をブラックボックス化して開発する場合でも、また、b）同列の周囲のものとつながるものをブラックボックス化して開発する場合のいずれでも、同様です。

　また、パッケージング／リリース時（deployment時）には、そのパッケージのリリース先の都合（context）に合わせて、何らかの「限定」がさらに付加されます。使用するプロセッサやコンパイラ、プログラミング言語の決定などはそれらの「限定」の典型でしょう。

　しかし、それらの「限定」は、「開発対象の領域」の開発で必然の「限定」ではありません。パッケージング／リリース時に付加された「限定」です。それら2種類の限定を混同して「開発対象の領域」での「必然の限定」としてしまえば、そこでの成果物を「out-of-context」な汎用品として利用する場合に、利用可能な範囲が狭められてしまいます。

　さて、SDVが進めば、従来よりもさらに多くのプレイヤーが開発者として関係してくることになりますし、それぞれの成果物がcontextとは独立に開発される、つまり、「out-of-context」な汎用品として独立のサイクルを回しながら開発される、そんな部分の比率が圧倒的に多くなることは、すでに皆さまもご承知でしょう。

　ですから、「何かを決める」という場合には、その必然性が「開発対象の領域」の成果物固有のものなのか、それともそうではなくdeploymentで付加されたものなのかを見極めることが、これまで以上に求められるようになると言えます。また、必然性のない無思慮な決め急ぎは、もっての外でしょう^※15）。

※15）「今決める必要はないけれど、一見すると簡単に決められそうだから、決めてしまえ」という姿勢を、筆者はしばしば「決めたガリ」と呼んでいます。

　以前、とある大学で講演の機会をいただいた際、Q&Aの中で話が「必要もないのに決め急がない」につながったとき、「はぁっ？　何を言っているんだ、君は！」と、ある聴講者の方からお叱りをいただいたことがあります。「決めるということは、絶対的にpositiveなものであり、｛能力、勇気、やる気｝などの証」という価値観以外の根拠が見えてこない言葉をぶつけられるだけのやりとりに終始したのですが、「out-of-context」の開発の中では、「決めなくていいことを決めてしまうこと（特に範囲を狭めてしまう決定）」は、ここで述べているように、プラスに作用するとは限りません。その姿勢は、ISO 26262-8:2018 clause 6.4.2.4で示される、安全要件に関する「h）implementation free」という原則にも、結果的には反してしまうことになるでしょう。ましてや、「決めたいところは決めたので満足したよ、後はよろしくね」なんてのは一番困ります（「決定」という権利を行使することに伴う義務や、権限移譲に伴う資源の引き渡しなどはどこに行った？）。

　残念ながら、integration現場では今でもしばしばあると各所でお聞きしていますし、昨今の不祥事の報告書での「上の決めたことは絶対」に類する風土問題がしばしば現れることは、「master-slave」という不適切な関係が、表現だけを変えて生き続けてしまうのではないか、と懸念せざるを得ない原因の1つなのです。根本的な姿勢の変化が求められるのです。

　もちろん、パッケージング／リリース時のcontextに合わせて作られる部分もあるでしょうし、contextに合わせた最適化もゼロにはならないでしょう。しかし、毎回、筆者がAUTOSAR CP研修を行う際には申し上げていることですが、「contextへの合わせ込み」（個別最適化）に手間をかけても、異なるcontextではその手間の結果を再利用できない部分がありますし、そこで必要となる検証などの手間のうち自動化（Variantも考慮した自動化）ができない部分は、全体としてのパッケージング／リリース（deployment）のボトルネックとなり、deploymentのサイクルを回すスピードを律速しかねません。

　このように、S10）の中の「より汎化されたプレイヤー／アクターの巻き込みと相互の存在承認」を踏まえた（つまり、周囲に影響を与える部分をよりあらためてシステマチックに考慮した）、S8）「より汎化されたプレイヤー／アクターの集団による、複雑なシステムの取り扱い方や期待の進化（作る側と利用する側双方において）」が、さまざまなところで登場することとなります。

　なお、本節の冒頭では、以下の2つについて申し上げました。

• 1）ある意図の実現手段は、その下の階層ではさらにさまざまな実現手段にブレークダウンされていきます。手段間は必要があれば互いに連携しますし、各手段はさらに必要に応じてブレークダウンされ、下の階層が伸びていきます。逆に、下から上の方にたどっていけば、最後にはサービス利用者の意図（あるいはサービス提供側の想定に対する、それを利用すると決めた利用者の想定に対する肯定の意思決定）にたどり着きます
• 2）「周囲から与えられた要求／制約と、その実現上の限定（制約）」が「サービス提供側の想定」となります

　そこからは、一つ面白いことが見えてくるかもしれません。それは、「設計／開発での各種意思決定」と「サービス利用者の意図（あるいはサービス提供側の想定に対する、それを利用すると決めた利用者の想定に対する肯定の意思決定）」の間に、根本的な違いは見当たらない、ということです。そうすると、開発者とサービス利用者をまるっきり区別して考える必要はないというわけです。安全やセキュリティも含む、広義の「品質保証」やその他各種の意味での「ホショウ」の存在を考えれば、暴論に聞こえるかもしれませんが、一方、「ホショウ」などの具体的な内容は、提供／利用する「ミクロなサービス」のそれぞれで具体化されると考えればいかがでしょうか。多階層のサービスプラットフォームというインフラの性質を考えたら、もともと、userとproviderは、その中でのプレイヤーあるいはアクターの間の受け渡しの相対関係を表すだけのものですから、これまた自然なことと考えることもできます。

　AI倫理など、これまでは考慮の範囲外だった要素にも今後直面することになります。「普遍の原則などを根拠としない、気分次第のアドホックな意思決定」を繰り返していては、「必要な変化」にすら気付くことすら難しくなるでしょう。もちろん、もはやそれでどうにかなったのは既に過去の話ですが、さらに進めて、「AUTOSARを使いこなす」に限らず、多義性への考慮と、抽象化（捨象と具象化の行き来）を交えて見直し続けることは、SDVというキーワードの意味ですらまだ変わっていくこの100年に一度の変化を歩む中でも、矛盾の少ない一貫した戦略立案とその継続的改善に寄与することでしょう。

次回に続く

　次回は、R23-11の内容紹介の後半部分となります。

筆者プロフィール

櫻井 剛（さくらい つよし）イーソル株式会社 ソフトウェア事業部 エンジニアリング本部 エンジニアリング管理部 Safety/Security シニア・エキスパート

自動車分野のECU開発やそのソフトウェアプラットフォーム開発／導入支援に20年以上従事。現在は、システム安全（機能安全、サイバーセキュリティ含む）とAUTOSARを柱とした現場支援活動や研修サービス提供が中心（導入から量産開発、プロセス改善、理論面まで幅広く）。標準化活動にも積極的に参加（JASPAR AUTOSAR標準化WG副主査、AUTOSAR文書執筆責任者の一人）。