AUTOSAR導入に対する「期待」を正しく見定め続けるために：AUTOSAR〜はじめの一歩、そしてその未来（6）（1/3 ページ）
「量産開発を通じてのAUTOSAR導入」は2つの部分に分けることができる。前回紹介した「量産開発プロジェクトを完了させる」に続き、今回は「AUTOSAR導入により、基本的な型や支援体制をどのように変えていくかの見極めと必要な活動の実施」について説明する。
はじめに
まず、前回から間が空いてしまったことに対するおわびと、「次回掲載はいつか？ 打ち切りか？」とご心配下さった皆さまに対する感謝をお伝えしたい。
年末、年度末、展示会シーズンと続き時間の確保が非常に難しいため、しばらくは少々ペースを落とすことになる見込みだが、お伝えしたい内容はまだたくさんあるので、いましばらくお付き合いをお願いしたい。
前回の第5回では、「量産開発を通じてのAUTOSAR導入」の1つ目の側面である「量産開発プロジェクトを完了させる」、つまり、実際に直面する「手を動かす作業」をごく粗い概要レベルでご紹介した。必要な作業を特定できなければ、必要な各種リソース／支援の特定や適切な計画立案は不可能であるから、最低でもその程度の把握は重要である※1）。そこで必要となる道具類についても、既に述べた（第4回）。
今回からは、2つ目の側面である「AUTOSAR導入により、基本的な型や支援体制をどのように変えていくかの見極めと必要な活動の実施」について考えていきたい。
AUTOSARへの「期待」を明文化し見直し続けることの重要性
まず、開発体制やその支援の具体的な内容の前に、まずは「AUTOSAR導入でどこまでを目指すのか？ 何に期待するのか？」についての明文化（既に明文化されているのであれば、できればその見直し）をあらためてお願いしたい。
従来と同じことができれば良いというのであれば、従来のやり方で良い。現状に困りごとがないというのならなおさらだ。そのような場合には、AUTOSARに対しては極めて限定的な投資や準備と検討しか行われないだろう。厳しいことを申し上げるが、当然、「その先にあるもの」には手が届かず、また目が向くはずもない。「導入しても効果がない」という結論にたどり着くのは最初から見えている。AUTOSARを導入した先に、一体何を期待するのだろうか。
AUTOSARベースの量産開発プロジェクトが終わればそれで満足ならば、優秀なインテグレーターを雇えばよい。プロジェクトをこなすうちに、組織的改善によりもっと効果を出せる可能性も見いだしてくれるかもしれない。ただし、優秀なインテグレーターはどこでも非常に不足しており、活躍の場はいくらでもある。知ってしまった組織的改善の可能性に目を向けてもらえない状況が続けば、結末の予想は容易だ。人は、一度知ってしまったら、知らないという状態には二度と戻れないからだ。
実はこれまで、AUTOSARに対する期待に関して、「不適切な期待」を排除しつつ「期待できること」を自ら見つけることの重要さを強調し、意図的に「期待できること」の具体的な内容にはできるだけ触れないようにしてきた。
過去幾度となく繰り返されてきた苦い失敗の反省を踏まえてのものである。「こういった期待ができる」ということが見え始めると、その実施やその最適化（短期的なコストの抑制など）にすぐに目が向いてしまい、「その先にあるもの」に目が向けられることはほとんどなくなる※2）。当然、投資や準備がされるはずもない。そして、AUTOSARのもたらす、さらなる価値や効用といったものの可能性の芽が摘み取られてしまう。これが、AUTOSAR導入が停滞する主な原因ではないかと筆者はみている。
「その先にあるもの」に目を向け続けること、そして向けさせ続けること。これがAUTOSAR導入の効果を確保するためには重要だと考える。「見る目」も育っていくから、続けることには価値がある※3）。
では、どのように「期待」を見いだせばよいのだろうか?
注釈
※1）インテグレーション作業の実務経験をお持ちの方であれば、前回の内容と「現場」の作業順序の間には異なる部分もあることに、すぐにお気付きになっただろう。しかし、前回示したのは、あくまでMethodology規格文書上の流れに沿ったものである。現実との差異の典型例は、必要なものがそろわなくとも作業開始しなければならないことによる、作業順序の入れ替えであろう。
優秀なインテグレーターは、プロジェクト全体を俯瞰し「今あるものやこれから手に入るものだけで、何が可能か」を見極め、開発の流れの合わせこみ（tailoring）を行う。全ての必要なものが、必要な時までにそろうなどという理想状態はまずありえないのだから当然であり、そのような状況に対応するためのフレキシブルなプロジェクトマネジメント能力が求められる。経験を通じて「現場での作業」を知り、規格に書かれているよりもさらにブレークダウンし具体的な作業に落とし込んだものを一連の流れに仕上げることができ、加えて、流れの見直しで対応できることとできないことの見極めをできるようになれば、プロジェクトマネジメント面では一応の成功であろう。
いきなりそのレベルに到達するのは現実的ではないかもしれない。しかし、まず少なくとも前回示した程度の内容（流れと、流れの各ステップでどのような情報や事前作業が必要か）を試作マイルストーンごとに考慮していかなければ、立てた計画は開始後すぐに破綻し、見直さなければならなくなるだろう。もちろん、必要なもの（第4回参照）の準備を考慮することについては言うまでもない。
※2）ISO/IEC Guide 51やISO 31000に基づくリスク対応／低減のプロセスでは、「特定→分析→評価→対応（リスク低減）」を繰り返す。評価の段階では、特定し分析されたリスクへの対応の要否や優先度といった意思決定（判断）が行われるが、その前は基本的に意思決定のための準備段階である。その準備段階でリスク低減手段が見えてくる、あるいは、判断ができる程度に情報が集まってくると、準備を切り上げ、先を急ぎたくなるのは人間の性である。必要な繰り返しも、行われないかもしれない。しかし、急ぐのをこらえなければ、リスク対応の過程の妥当性を後に説明することは、きっと難しくなるだろう。
※3）「いつ終わるのか」と思われる方は、ソフトウェアの「最終バージョン」の意味について考えてみていただきたい。最終だからといって完全無欠だろうか。更新を打ち切っただけ、あるいは、今後は別の名前を付けたものが出てくるというようなケースが多いのではないだろうか。
Copyright © ITmedia, Inc. All Rights Reserved.