　「Quality／Cost／Delivery （QCD）で効果を出す」というのは典型的な目標であり、一見するとまっとうなものに見えるだろう。しかし、効果を出すために必要な権限や資源が与えられなければ、効果を出せるはずがない。また、導入後の運用（再利用や自動化など）で効果を出すものであるのにも拘らず「導入するだけで××円儲かる」のような期待を持つことや、そもそもAUTOSARに対して適切ではないことを期待する、あるいは、単に「サプライズ」を待つのは論外である。また、「どの程度の期間で効果を出す」という設定（一種のコンテキスト設定）が適切でなければ、効果が出る前に期間が終わることもあるだろう。

　加えて、「QCD」という結果につながる過程が、効果の有無を評価する側にとって許容されるものでなければ、効果として認められない場合も出てくるだろう。連載第8回で述べた、「基本的には内製を選ぶ」といった制約が、既定路線、不可侵のものとされているような場合には、さぞ苦労することになるであろう。今回までに述べてきたように、方向修正の余地は不可欠である。

　良く考えてみれば、「QCD」という結果につなげるために、組織の枠組み（部門や職位ごとの役割など）が決められているはずであるから、戦略／戦術にブレークダウンし^※1）、それぞれ割り付けを行わねばならないはずである。上位目標を示す前に、下位の手段を制約として課すのならば、両目標の一貫性を担保しなければならない。一貫性の担保なしで制約を提示しその修正を認めないとするのは、順序の面からは疑問がある。

　また、もちろん、従来の枠組みで既に決まっているものやカバーされているものは少なくないだろうが、AUTOSAR導入により、少なからず従来の枠組みでは収まらない部分も出てくるだろう。典型的には、再利用や自動化の推進体制に関するものだ（再利用を促し、支援し、それらを続けさせるマネジメント）。連載第7回で示したように、AUTOSAR導入による効果として期待すべきことは、再利用性向上と自動化促進（図1のPhase-B）や工数増大ペース抑制（同Phase-C）である。AUTOSARは、それらを可能にする「enabler」でしかなく、それらを活用しないのであれば、AUTOSAR導入で効果を出すことは難しい。

図1　AUTOSAR導入による効果（筆者作成、クリックで拡大）

　そして、連載第2回でも少し触れたが、再利用対象となりうる「ソフトウェア」は、プログラムコードだけに限らない。それを生み出す手順やスキルも対象であるし、テスト自動化の背後にあるテストケースなども対象に含めることができる（表1）。

　企業内の広い範囲に影響が及ぶ可能性もあるので、「今は変えられない」ということが多く出てくるだろう。第6回や第7回でも述べたように、「変えるための計画」を発動しなければならなくなる（ISO 26262-2：2011 clause 5.4.2.4 逸脱状態解決プロセス要求とも関連）。一部門、あるいは一担当者からのボトムアップでは、そこまで踏み込むのは難しい。与えられた権限の範囲で対応し、権限を越えるものは上位層のタスクとして明確にアサインする。こうして、現場では対応しきれない課題が、マネジメント層やさらにその上、場合によっては、経営課題としてトップにも上がってくるはずだ。その時こそが出番である。


	Reuse asset	Reuse entity	Domain scope	Development scope	Modification	Management	Approach
	Ideas, concepts	Architectures	Vertical	Internal	Adaptive	Accidental	Compositional
	Artefacts, components	Requirements	Horizontal	External	Black box	Systematic	Generative
	Procedures, skills	Designs			White box		Indirect
		Specifications					Direct
		Source code
		Object code
		Test cases
表1　ソフトウェア再利用形態の分類例出典：F. Belli: An Industrial Standard to Assure Dependability in Software Reuse

　なお、今回の冒頭で、機能／性能やリソース要求などに対する不満、導入におけるさまざまな壁（初期投資の費用の大きさや、大量の英語のドキュメントなど）、すぐに効果が出せないことに対する理解の得にくさ、インテグレーション作業の複雑さなど、幾つかの困難や課題を挙げたが、これらはおそらく永久に解決されることはないだろう。その理由は、解決の具体的な目標が示せないためである。

　例えば、初期投資はどの程度まで抑制できたらよいのだろうか。AUTOSAR導入そのものは何も生み出さないから、理想はタダだとおっしゃる極端な方もいらっしゃるが、「どの程度までなら良い」ということを示すことは難しいはずだ。

　プラットホームに関する投資の意思決定を時間軸で分類すると、以下の3つに分けることができるのではないだろうか。

過去の意思決定に対する継続的な投資（つまり維持／メンテナンス）
現在（あるいは任期中）の意思決定に対する投資（つまり独自色を出し任期中に回収を狙うもの）
未来に対する投資（つまり自分の任期中には回収できないが次世代以降で回収してもらうもの）

　「初期投資」という言葉そのままでは、実施やその額の妥当性についての議論は難しいかもしれないが、上記で分類することでもう少し説明や議論ができるようであれば、ぜひお試しいただきたい。

　ただ、到達可能な目標が設定できるものと、方向性を示すだけのものは区別しなければならない。後者について数値目標のような一見もっともらしい目標が設定されたときには、その妥当性に対して疑問を抱かねばならない。

注釈

※1）安全やセキュリティの分析でも広く使用されているGSN（Goal Structuring Notation）は、このような場面でも利用できる。なお、「Osによる処理オーバーヘッドをx「μs］までに抑制する」というような細目が何の脈絡もなく持ち出されるとしたら、その背後には何があるのかを、一度検討してみるべきであろう。脈絡を明らかにする際に、GSNのような表記法は極めて有効となる。