セッションレポート – Automotive SPICE最新動向と開発品質向上の取組事例

記事をシェアする:

 

11月20日に日本IBMにて開催された「CASE時代の自動車開発プロセス変革セミナー」は、自動運転車への変革という激動の中で必要となる「開発」に、複数の視点から焦点をあてる大変興味深いものとなりました。

今回は「変化拡大を続けるAutomotive SPICEの最新動向」と「開発プロセス変革を契機とした開発品質向上の取組事例」のという2つのセッションをダイジェスト版でご紹介します。

 

■ 変化拡大を続けるAutomotive SPICEの最新動向

 

* 自動車業界では、完成車メーカーのことをOEM（オーイーエム）と呼びます。そして部品を製造する部品メーカーをサプライヤーと呼び、OEMに直接納入するサプライヤーをTier1（ティアワン）、Tier1に部品を納入するサプライヤーをTier2（ティアツー）と呼びます。

 

「QualityからSafety&Securityへ、SoftからSystemへ」という副題がつけられたこのセッションでは、Automotive SPICEが誕生してからこれまでの経緯と、現在それがどのように捉えられて用いられているかを、世界の自動車開発事情に詳しくとりわけAutomotive SPICEに関しては第一人者であるビジネスキューブ・アンド・バートナーズ社の日吉 昭彦氏にご説明いただきました。

講演者: ビジネスキューブ・アンド・バートナーズ社  日吉 昭彦氏

 

・ Automotive SPICE – 概要

Automotive SPICEは、車載システム開発向けのプロセス改善、プロセスアセスメントを目的としたプロセスモデルです。

ソフトウェアのプロセス改善から、メカやハードウェアの領域に拡張させていることもあり、自動車業界では15年以上の長期にわたり用いられています。

 

・ Automotive SPICE – 特徴

ヨーロッパのOEMがTier1やTier2といったサプライヤーを選ぶ際の審査（プロセスアセスメント）基準として用いており、そのためOEM視点が色濃く反映されたプロセスモデルとなっています。プロセス改善には重要であるプロセス確立や人材育成に関するプロセス領域は含まれていません。

プロセスは全部で32個ありそれが8タイプに分けられています。アセスメントでは、それぞれのプロセスタイプに対する能力を、0から5までの6段階で表現します。

 

・ 本田技研のAutomotive SPICE活用事例

ドイツで毎年行われているVDA（ドイツ自動車工業会）Automotive SYS Conferenceで今年発表されていた、ホンダにおけるAutomotive SPICE活用事例をご紹介します。

ホンダの登壇者の方がまず背景として言われていたのは、開発スタイルが変化しており、一社で垂直統合型に行われていた時代は過ぎ水平分業型に変わっているということ。従来の自動車開発の範囲を大きく超えた、自動運転システム開発の影響がその大きな理由です。

ホンダでは、ヨーロッパのOEMが調達先選定に用いているAutomotive SPICEを、カイゼンに役立つ道具として用いているそうです。具体的な適用目的は下記3点とのことでした。

1  改善すべき項目を抽出するため

2  サプライヤーの弱みを把握するため

3  サプライヤーの「弱みに対する改善活動」を促進するため

 

・ Automotive SPICE導入ポイントと成功ポイント

Excel、Word、パワーポイントでも、プロセス管理をしたりトレーサビリティ・マトリックスを作ったりはできるでしょう。

しかし、今後はどんどん工数に対してのメリットが出せなくなっていきます。

開発エンジニアには他にもやることが無数にあります。プロセスを専用ツールに乗せることで、機械に任せられる部分は機械に任せ、本来やるべきことをやった方がよいということは間違いありません。

 

以前、Rational Method ComposerやRational Doorsとよばれたシステム開発管理製品群を用いれば、一つの作業を次のプロセスにそのまま引き継くことができます。また、現在回しているプロセスを、次回以降のプロジェクトに活用することもできます。これらを活用していくべきなのです。

ただ、こうした製品を選ぶ際には「自社の現場のやり方」との親和性を十分考慮することが重要です。その点は注意すべきでしょう。

以上となります。本日はありがとうございました。

 

 

■ 開発プロセス変革を契機とした開発品質向上の取組事例

日吉氏に続いて登壇したWatson IoT Lab Servicesの松下 望は、開発プロジェクトをお客さまと共に現場で進めてきた経験を豊富に持つエンジニアであり、プロジェクト・マネージャーです。

ここでは、松下が「お客さまがおっしゃっていた印象的な言葉」として紹介していた、取組事例に関係するいくつかのトピックをご紹介します。

講演者: 日本IBM Watson IoT  Lab Services  松下 望

 

日本でもAutomotive SPICEを取り入れようというOEMやTier1、Tier2が増えています。それは自動運転車やMaaS(Mobility as a Service)という新しいユーザー体験が求められている状況において、自社固有の進め方では相当厳しいということを実感しているお客様が多いからです。

たとえば、Automotive SPICEでは、「要件間のトレーサビリティ」「要件と設計間のトレーサビリティ」「要件・設計とテスト間のトレーサビリティ」が求められています。これらが担保できなければ、適切な設計に基づいて製品開発を行ったか証明しづらくなり、製品不具合があった時に説明責任を果たせなくなります。その結果、ビジネスを続けることが難しくなります。

業界の標準プロセスやベストプラティクスを取り入れなければ、市場への「入場券」を獲得できない時代となっているのです。

 

「V字の左側だけではなく、右側に対するトレーサビリティも注目されるようになった。」

— V字開発モデルは元々ソフトウェア開発工程の規定に用いられていましたが、現在ではメカ・エレキをも含む自動車開発全体を包括し、PDM（製品データ管理）やPLM（製品ライフサイクル管理）とも連携したトレーサビリティが必要となっています。

お客さまのこの言葉は、V字開発モデルの「左側」の中だけではなく、設計からテストの流れを示す「左側」から「右側」へのトレーサビリティも重要視されているということを表しています。

たとえば、設計部隊から実験部隊になかなか設計情報が連携されてこないため、実験部隊はスケジュールを遵守するために、既存の実験項目を中心に実験計画を作るケースがあります。しかし、後から連携されてきた設計情報に対する実験漏れが発生してしまうと、後で不具合が発覚した時に多大な修復コストが必要になります。そのため、設計情報が連携されたタイミングで設計項目に対して実験項目を起こしたことを確実に担保する仕組みが大切になります。

 

特に自動運転車においては、自社が責任を持つべき部分において、どのような理由で設計し、それに対して実験結果は問題なかったのか、重大度の高い障害は解決できているのかを確実に証明できることが非常に重要になります。それを担保するためには、ITシステムを用いたトレーサビリティ管理が必須になります。

複雑性が増せば増すほど、ITシステムを使った管理が求められるのです。

 

「うちの会社ではV字開発ではなく、N字開発になってしまっている」

— この言葉は、とある電動化部品を作っているTier1のお客さまの言葉です。

本来は「V字開発モデルに従い、顧客要求や車両要求からシステム要件を明確にして開発を進めるべき」ですが、ここでいうN字開発というのは、「まず既に存在している要素部品を集め、その機能性からボトムアップでシステム要件をすり合わせて明確化し、そこから開発が進められている」という現状を示しています。これにより、要求を適切にとらえて開発できているか、要求に対して正しく設計できているか、そのあたりの証明が難しいことを問題視されていました。

 

また「開発成果物そのものは監査するが、開発活動をどう行ったか証跡が取られていないため、いざというときに説明責任を果たせないのではないか」という危機感も強く感じているとのことでした。

これらについては、Automotive SPICEで求められる要件を満たすと解消できるのではないかという考えに至り、規格対応を契機とした開発プロセス変革のチャレンジが始まりました。

 

「PDCA（プラン・ドゥ・チェック・アクション）が重要なのは分かっているが、自分たちの位置を把握することができるCAPD（チェック・アクション・プラン・ドゥ）の方がやりやすいのではないか」

— 開発力強化ロードマップを描くのは重要だが、初めにどこからどうやって手を付けたらいいのかは分かりづらく難しい。業界標準であるAutomotive SPICEを基にして自社の立ち位置をチェックすることで、何がうまくいっていて何がうまく行っていないのかを理解することができるので、そこから始めてはどうだろうかというお客さまの言葉でした。「納得感が高い」という方も多いのではないでしょうか。

 

最後に、開発品質向上に向けた取組を推進する上で、ポイントとなる点をお伝えします。

それは、トップダウンかボトムアップのどちらかではなく、両者を合わせて推進する体制づくりが大切だということです。

トップが掲げる製品開発のビジョンとボトムから沸き起こる改善活動。ビジョンに基づいたガバナンス・システムとそれに対する現場からの意見収集。この両者をバランスよく合わせこむことで、適切な開発管理のもとでエンジニアが創造性を発揮しやすい環境が醸成されていきます。

その結果、開発品質向上や開発競争力強化に結び付くことになるでしょう。

本日はありがとうございました。

 

---

松下のセッション後には、ビジネスゴールである「品質向上」に対して「プロセスのサポート」を、「開発効率の向上」に対しては「戦略的再利用」を、「計画通りのリリース」に対しては「大規模アジャイル（SAFeのサポート）」をという、IBMのアプローチをが具体化するELMソリューションを紹介するセッションが開催されました。

ELMソリューションについては、以下のソリューション紹介およびセミナーレポート記事にてご確認ください。

ソリューション紹介ページ: デジタル時代のものづくりを、統合された設計・開発基盤が支える

 

関連記事: 「CASE時代のクルマづくり基盤」セッションレポート @東京モーターショー

関連記事: 開発セッションレポート – Cognitive Manufacturing Forum（8月29日開催）

 

 

問い合わせ情報

お問い合わせやご相談は、Congitive Applications事業 cajp@jp.ibm.com にご連絡ください。