Updates

新着情報

コラム

“やりすぎFMEA”に終止符を ─ 生成AIを使ってもっと「創造」しよう ─

はじめにあるお客様から「FMEAの作成に膨大な労力を費やしており、作業を効率化したい。」というご相談をいただきました。これは、多くの開発現場に共通する悩みではないでしょうか。FMEAをはじめとした設計ドキュメントは、品質と安全を確保するうえで欠かせないものです。しかし実際の現場では、開発プロセスに則った各種設計ドキュメントの作成に多くの工数と時間が割かれ、「創造」よりも「作業」に没頭する比率が大きくなってしまうケースが少なくありません。そこで私たちは、生成AI(ChatGPT)を活用し、FMEA作成のプロセスをどこまで自動化・支援できるかを試行する取り組みを行いました。結果として、「FMEAとしてそのままでは使えない部分がある」という課題は残るものの、AIによるたたき台生成の有効性と工数削減効果は明らかであり、「生成AIは必ず使える、確信を持てた」という非常に前向きな評価をいただきました。このコラムでは、その検証結果とともに、FMEA作成に潜む根本的な課題と、それらに対する生成AIの有効性についてご紹介します。 FMEA作成における3つの課題ご承知の通り「FMEA(Failure Mode and Effects Analysis:故障モード影響解析)」は、車載システムの信頼性・安全性を向上させる必要不可欠な設計作業のひとつです。しかしその一方で、作成やレビューにかかる労力が大きく、多くの開発チームにとって「やりすぎになりがちな成果物」の代表格でもあります。実際の現場では、以下のような課題を抱えています。 経験と知識に大きく依存し、属人化しやすい機能安全やフェールセーフ設計など、FMEAには高度な専門知識が必要です。そのため、成果物の質が担当者のスキルや経験に左右されやすく、再利用性やナレッジ共有が難しくなる傾向があります。 組み合わせが膨大で、表の編集作業が重い制御ブロックと信号の組み合わせは膨大で、それぞれに対して故障モードや影響、対策を網羅的に記述しようとすると、膨大なセル数のFMEA表が出来上がります。手作業による展開は工数負荷が高く、更新ミスのリスクもあります。 多人数によるレビューが不可欠だが非効率FMEAの信頼性を担保するためには、複数の有識者を集めたワークショップ形式のレビューが必要となるケースも多く、調整と討議に時間も手間もかかり、調整に追われる場面も多く見受けられます。 生成AIは、これらの課題にどう貢献するのか?今回の検証では、ChatGPTに対して「構成ブロック図」「各ブロックの機能概要」「入力信号のリスト」を与えることで、自動的にFMEAのたたき台を生成するプロセスを試しました。その結果、以下のような具体的なメリットが得られました。 ナレッジの再利用・標準化が可能にChatGPTには、FMEAの基本構造や業界でよくある失敗事例、設計パターンがすでに学習されています。そのため、個人の経験に頼らず、一定の質で初期案を出力できるのが大きな強みです。もちろん、閉域ワークスペースで企業独自のテンプレートや言い回しをAIに学習させることで、自社専用のFMEAナレッジベースを築くことも可能です。 膨大な組み合わせを高速処理従来はエンジニアが手動で展開していたパターンを、AIが論理的に組み合わせて網羅的に出力します。これにより、記述作業にかかる時間を大幅に短縮し、レビューや検討といった本質的な作業に集中できます。今回はFMEA作成に必要な入力情報が準備できた状態から、設計者の手作業だと数週間必要な「FMEA初稿作成」が数時間で対応可能でした。(作業時間短縮試算:80時間(10日間)が4時間に!)実際の工程としては、FMEA初稿作成以降の作業工数(レビューや成果物としての仕上げ)が必要ですが、今回は未評価でした。 レビューを「ゼロからの作成」から「AI出力の確認」へシフト生成されたFMEAはあくまで「たたき台」であり、人による確認と修正は必須です。しかし、ゼロから考えるのではなく、AIが出力した案に対してレビューを行うスタイルに変えることで、ワークショップの効率が格段に向上します。 FMEAにとどまらない、生成AIのポテンシャルこの検証を通じて、私たちはFMEAだけでなく、他の設計成果物(機能仕様書、検証仕様書など)への展開可能性でも同様に大幅な効率改善ができると強く感じました。これからの開発プロセスとして、「まずAIにドラフトを書かせる→人がレビューして精緻化する」という流れが、従来の作業スタイルを大きく変える可能性を持っています。我々としては車載システム開発プロセスに生成AIの活用を組み込みたいといったご要望に対応していきたいと考えています。 おわりに創造的な開発のために開発現場はこれまで、品質を担保するために膨大なドキュメント作成やレビュー作業を背負ってきました。しかし、そのプロセスが目的化してしまえば、本来注力すべき設計検討や創造的な活動の時間が圧迫されてしまいます。生成AIは、こうした作業を効率化するだけでなく、エンジニアが本来注力すべき「創造」や「発想」に時間を取り戻すツールでもあります。「やりすぎ設計書」に終止符を打ち、知的資産を活かしたスマートな開発プロセスへ。生成AIとの協調は、技術者の働き方そのものを変える可能性を秘めています。今回のコラムはいかがでしたでしょうか?本コラムの内容が、生成AIの活用や開発プロセスの見直しのきっかけになれば幸いです。お客様のご相談内容に対する具体的な実施内容や効果を導入事例としてまとめました。こちらもお目通しいただければ幸いです。生成AIを活用した設計ドキュメント作成プロセス効率化支援ご相談いただければ、これまでの経験を活かしてお力になれることもあるかもしれません。どうぞお気軽にお問い合わせください。 (越智功)

コラム

Automotive SPICEを使って業務は改善されているのか?

はじめに「Automotive SPICEを導入してプロセスを整備したけど、本当に現場の役に立っているの?」そんな声を、あなたの組織でも聞いたことはありませんか?たとえば「開発標準は整っているけれど、実際には形骸化していて使われていない」「レビューやチェックリストの数は増えたが、かえって手間が増えて効果が見えない」--こうした現場のモヤモヤは、多くの組織で共通しています。Automotive SPICEの導入やアセスメント対応を契機に、プロセスを整備したものの、「かえって開発がやりにくくなった」「成果が感じられない」という声が上がることも少なくありません。この背景には、“プロセスを定義すること”と“改善すること”が混同されているという問題があります。文書化や標準化はあくまでスタート地点。定義されたプロセスが現場に定着し、実際の課題に対応して見直されてこそ、本当の意味での「改善」と言えます。プロセス改善グループ(EPG:Engineering Process Group)は、開発組織のパフォーマンスを高めるために活動していますが、定めたルールや仕組みも、現場に馴染まなければ“形だけの改善”となり、かえって現場の負荷や反発を招く結果にもなりかねません。本コラムでは、Automotive SPICEなどの成熟度モデルを活用するうえで、プロセス改善が“やりっぱなし”にならず、継続的に成果へとつながっていくための鍵として、EPGと現場との対話、そして改善サイクルの回し方について考えてみます。「やりっぱなし」から脱するには、現場との対話が必要プロセス改善活動のなかで、ありがちな失敗の1つが「とにかく標準を整えよう」「レベルを上げよう」といった目的化の罠です。プロセスの完成度やドキュメントの網羅性を追い求めるあまり、現場の課題感や使い勝手が置き去りになる――その結果、「改善活動が負荷として認識されてしまう」という状況を招いてしまいます。こうした“やりっぱなし”の背景には、「変えたら終わり」という思い込みが潜んでいます。しかし本来、プロセス改善は「一度仕組みを作って終わり」ではありません。運用され、計測され、見直されるというサイクルを回してこそ、本当の意味での“改善”が成立するのです。たとえば、ある開発チームでは、レビューの指摘数や重大バグの混入率といったKPIを継続的に追跡していました。分析の結果、「アーキテクチャ設計レビューでの指摘が少ない一方で、後工程でのバグが多い」という傾向が明らかになり、EPGが設計レビューの観点やタイミングを見直す取り組みを支援しました。具体的には、レビュー観点にシナリオベースの確認を加えたり、関連ドキュメントの整合性チェックを強化するなどして、設計段階での問題発見率が向上。結果として、後工程での重大な不具合流出が有意に減少しました。このように、定量的な観測と実践的なフィードバックを通すことで、改善活動が“やりっぱなし”で終わらず、継続的に改善サイクルを回していく原動力になります。現場に「関わる」ことで、プロセスが生きてくる改善活動が現場に受け入れられ、成果につながるかどうかは、EPGがどれだけ現場に寄り添っているかにかかっています。ある組織では、EPGメンバーが現場のレビュー会議にオブザーバーとして参加することで、レビュー観点の形骸化やチェックリストの実態に合わない運用に気づくことができました。「この観点は、実際には誰も使っていない」「この手順は無理がある」――そんな声を拾い、現場とともにプロセスや観点を見直した結果、レビューの質が改善し、抜けや漏れが減るという成果が生まれました。これは、EPGが“改善する側”ではなく、“一緒に改善する仲間”になることで初めて得られた成果です。プロセス改善を“プロセスのための活動”にせず、現場の本音や実情を反映するためには、こうした「対話」「関わり」「フィードバック」が欠かせません。さいごに今回のコラムはいかがでしたでしょうか?Automotive SPICEは、業務をより良くするための仕組みであるはずです。しかし現実には、「形だけの対応」や「負担ばかり増える」といった声も少なくありません。本コラムが、「改善は本当に現場の役に立っているか?」という視点で、今一度プロセス改善のあり方を見直すきっかけになれば幸いです。EPGという立場だからこそできる“現場との対話”や、“小さな気づき”の積み重ねが、Automotive SPICEを「業務改善のためのツール」として真に機能させる第一歩になります。現場のリアルに触れながら、実践的な改善のヒントを共有できるよう、これからも発信していきたいと思います。(安部宏典)

コラム

プロジェクトマネージャーの成長を支える羅針盤──PMCDとは何か?

はじめに現在、車載システム/ソフトウェア開発の複雑な事業環境において、プロジェクトマネージャー(PM)の役割はますます重要になっています。しかし、優れたPMになるために必要なスキルや知識とは、果たして何なのでしょうか?必要な知識をまとめたものとしてはPMBOK® が有名ですが、求められるスキルや育成については明確な定義がありません。そこで登場するのが「PMCD(Project Manager Competency Development Framework)」です。 PMCDの位置づけと背景PMCDは、PMI(Project Management Institute)によって開発されたフレームワークであり、プロジェクトマネージャーに求められる「能力」を体系的に整理したものです。単なる技術的なスキルセットではなく、「知識(Knowledge)」「パフォーマンス(Performance)」「個人特性(Personal Competencies)」の3側面から成り立っており、総合的なコンピテンシーを育成・評価することを目的としています。3つの柱:PMCDのコンピテンシー構造 知識(Knowledge):PMBOK® Guideをベースにしたプロジェクトマネジメント知識体系。プロセスやツール、手法の理解がここに含まれます。 パフォーマンス(Performance):知識を現場でどう活かすか。実際のプロジェクトで成果を出せるかが問われます。 個人特性(Personal Competencies):コミュニケーション能力、リーダーシップ、倫理観など、人物としての資質に関する領域です。この三位一体のアプローチは、単なる資格取得以上に、実務家としての進化に焦点を当てているのが特徴です。さらに、このコンピテンシー構造は、業界や組織が持つ固有のパフォーマンス要件によって、補完&拡張されること許容しています。それぞれのコンピテンスの程度は、コンピテンス指標によって5段階のレベルが定義されています。 3つの柱の内部構造知識のコンピテンスPMP試験や同等の資格認定に合格することで立証されるものとしており、PMCDの定義外ですが、PMに求められる知識を「人」「プロセス」「ビジネス環境」に分類しています。 実践のコンピテンスマネージャーが、プロジェクトマネジメント知識と個人のスキルによって、実施できるまたは達成できていることを評価する領域です。PMBOK® 第3版の知識エリアに基づいて、コンピテンス要素を定義しているだけでなく、パフォーマンス基準と証拠資料を使って、コンピテンス要素を評価する仕組みを提供しています。 個人特性のコンピテンスマネジメントする各プロジェクトメンバの能力に貢献する、振る舞い・態度・文化的な影響およびコアとなるパーソナリティ特性を定義しています。マネージャーは、他者と効果的なやりとりができるスキルをもつことは重要であるため、6つのコンピテンスユニット「コミュニケーション力」「リーダシップ力」「マネジメント力」「認識力」「実効力」「プロフェッショリズム」を定義しています。さらに、実践コンピテンスと同様に、コンピテンス要素を定義しているだけでなく、パフォーマンス基準と証拠資料を使って、コンピテンス要素を評価する仕組みを提供しています。 なぜPMCDが今、注目されるのか?変化の激しい時代において、プロジェクトマネジメントはもはや「計画を守る」だけでは不十分です。ステークホルダーの多様化やアジャイル型の開発環境では、「状況に応じて適応できる力」がPMに求められます。PMCDは、そうした多様な能力を総合的に見える化し、継続的な能力開発のガイドラインを提供する点で、非常に有効です。 ビジネスガレージが提供するPMスキル可視化サービスビジネスガレージでは、組織が求めるPMを育成するご支援の一環として、PMCDや他のフレームワークも活用した、皆さんの組織の特徴や文化に適合したPMスキル可視化をご支援しております。プロジェクト特性や組織特性を考慮して、「会社が期待するプロジェクトマネージャ像」を、お客様と一緒に作り上げます。弊社の熟練専門家が、ドキュメントやヒアリングを通じて、組織の特徴を整理するだけでなく、プロジェクトマネージャへの期待を明文化し、期待するプロジェクトマネージャが保有すべきスキルを言語化します。  既成のフレームワークに囚われない、実用的なスキル定義をご提供しておりますので、興味のある方は是非お問い合わせください。 さいごに自己評価と育成の道しるべとしてPMCDは評価のための“物差し”であると同時に、成長のための“地図”でもあります。自らの強みや課題を客観的に把握し、戦略的にキャリアを築いていくうえで、非常に有用なツールといえるでしょう。 内山哲三

コラム

Automotive SPICE MAN.3 計画の計画(GP2.1.2)とは何か?

皆さんご承知のように、Automotive SPICE の能力レベル2では、プロセスに対する目標設定や計画、監視と制御などが求められています。例えばソフトウェア要求分析(SWE.1)では、要求分析の作業を計画的に進めるために、WBS(Work Breakdown Structure)などを使用して管理するわけですが、プロジェクト管理(MAN.3)の作業を計画的に進めるとなると、何を実施すればよいのかわからなくなってしまうケースが多いようです。そこで今回は、MAN.3の GP2.1.2 をどのように捉えればよいかを解説いたします。 ここでは、「計画の計画って何?」ということを良く耳にします。「プロジェクト計画策定計画」なる書類を作成しているプロジェクトも見たことがあります。おそらく、MAN.3 の主要成果物がプロジェクト計画書なので、プロジェクト計画を作成するための計画が MAN.3 の GP2.1.2 になると言いたいのだろうと思います。確かに、プロジェクト計画書はプロジェクトの初期に作成することが重要でありながら、タイムリーに作成されないことが多く、プロジェクト計画を作成するための計画が必要だということは間違っていないのかもしれません。しかしながら、あまりにも Automotive SPICE にこだわりすぎた事例だと思いませんか?プロジェクト計画作成というタスクが1つ(あるいは不随した複数のタスク:例えば日程計画、工数見積もりなど)あれば十分だと思います。  実際に実施している作業や、計画・管理として重要な側面を考えていくことで、実施すべき作業(あるいは Automotive SPICE への適用)が見えてくると思います。 実際に、計画に関連する作業を一般事例の中から抽出してみます: ウォーターフォール的なライフサイクルを適用している場合  プロジェクトの開始当初に、大日程を作成する- 機能一覧を作成し各機能に必要な概算工数を見積もる- 大日程上の各工程で必要となる作業を洗い出し中日程を作成する- 各工程に必要な概算工数を算出し、プロジェクト合計工数として積み上げる  各工程の開始時に、工程内で必要なタスクを抽出し、小日程を作成する- 各タスクに必要な工数を算出する- この際、当初算出した工程工数との差異を分析する- 必用に応じて対策を検討し、全体計画を修正する  各工程の終了時に、工程内で使用した実績工数を集計する- 工程開始時に算出した工程工数との差異を分析する- 必用に応じて対策を検討し、全体計画を修正する アジャイル的なライフサイクルを適用している場合 プロジェクトの開始当初にイテレーション数、スプリント回数・期間を決める- バックログを作成する- 各イテレーションに割り当てる要件を決定する  各イテレーションの開始時に、スプリントを計画する(スプリントプランニング)- 各スプリントに割り当てる要件を選択して、ストーリーポイントを算出する- 各スプリントに割り当てる要件をバックログから選択する- 要件毎に作業タスクを決定する 各スプリントの終了時に、スプリントの状況を評価する(スプリントレトロスペクティブ)- 次のスプリントに持ち越す要件、中止する要件などを精査しバックログを修正する 各イテレーションの終了時に、イテレーションの状況を評価する- バックログを精査し、全体の計画を見直す いかがでしょうか?ここに記載した内容はプロジェクトの中で当たり前のように実施している作業だと思います。計画の計画(MAN.3 のGP2.1.2)とは、これらの作業が実際に行われていれば良いのです。つまり、プロジェクト計画書作成計画というような計画書だけが焦点ではなく、都度進んでいく工程(アジャイルの場合はイテレーションやスプリント)ごとに、初期計画を詳細化する(あるいは見直す)ことが、計画作業そのものなのです。これらを計画的に進めるためには、WBSタスクの設定や作業者のアサイン、作業工数の見積もりなどが必要になってくることは言うまでもありません。 最後に余談ですが、MAN.3 GP2.1.3(リソースのニーズを決定する)/GP2.1.4(リソースを識別し、利用可能にする)について補足いたします。上記で説明した例のように開発ライフサイクルが異なってくると、人的リソースや物理的リソースへの要求事項も変わってきます。例えば、アジャイル手法を用いるプロジェクトでは、プロダクトオーナーやスクラムマスターといった役割が登場します。また、管理手法もカンバンやバーンダウンチャートなどを使用することになります。プロジェクトで採用するライフサイクルにより、計画・管理のタスクや役割・スキル要件、必要なツールが異なってくることを再認識できますね。例えば今回の計画の計画のように、一瞬戸惑うことがあるかもしれませんが、日々実施していることを整理することで、無駄な作業を追加することなくAutomotive SPICEへの適用ができるはずです。 日吉昭彦

コラム

Automotive SPICE 4.0 トレーサビリティと一貫性に関する変更点(SYS/HWE):HWE導入によるプロセスのギャップ解消

Automotive SPICE 4.0 では、従来のソフトウェア中心の構成から一歩進み、ハードウェアエンジニアリング(HWE)という新たなプロセス領域が追加されました。今回は、トレーサビリティと一貫性の観点から、SYS(システムエンジニアリング)とHWEの関係性に焦点を当て、HWE導入がもたらすプロセス上のギャップ解消について説明します。 ◆Ver3.1までの課題Ver3.1までは、ハードウェア開発に関するプロセスが明示的に定義されておらず、多くの組織では以下のような課題が見られました。 ハードウェア要求が体系的に管理されていない 設計と要求のトレーサビリティが不十分 ソフトウェアと比較してプロセス成熟度が低く、属人化しやすいこのような状況では、システム全体の整合性を保つことが難しく、特に安全性や信頼性が求められる領域では大きなリスクとなっていました。 ◆HWEの登場とその意義Ver4.0で新設されたHWEプロセス領域は、ハードウェア開発を「要求定義 → 設計 → 実装 → 検証」という一連のプロセスとして明確に定義しています。これにより、以下のような効果が期待されます。 ハードウェア要求の明文化と管理 設計成果物とのトレーサビリティ確保 SYSとの整合性チェックの仕組み化 ソフトウェア開発とのプロセス統一による連携強化特に、SYS-HWE間のトレーサビリティが明確になることで、システム全体の一貫性が担保されやすくなります。 ◆トレーサビリティと一貫性の実現HWE導入により、以下のようなトレーサビリティの流れが構築されました。  SYS.2(システム要求分析)で定義されたシステム要求が、 HWE.1(ハードウェア要求分析)に引き継がれ、 HWE.2(ハードウェア設計)で設計に反映され、 HWE.3(ハードウェア設計に対する検証)で設計が検証され、 HWE.4(ハードウェア要求に対する検証)で要求が検証されるこの一連の流れにおいて、各プロセス間で要求のトレーサビリティのリンクを明示的に管理することで、変更が発生した際にも影響範囲を迅速に把握でき、設計ミスや手戻りのリスクを低減できます。また、SYSとHWEの間で一貫性チェックを行うことで、要求の解釈違いや設計のズレを早期に発見することが可能になります。 ◆まとめVer4.0におけるHWEの導入は、これまで曖昧だったハードウェア開発プロセスに明確な枠組みを与え、SYSとの連携を強化する大きな一歩です。特にトレーサビリティと一貫性の観点から見ると、システム全体の品質向上とリスク低減に直結する重要な進化と言えるでしょう。今後は、HWEプロセスの実装と定着を通じて、ソフトウェアとハードウェアが真に連携した開発体制の構築が求められることになると思います。佐藤崇

コラム

システムの論理構成と物理構成について

はじめにAutomotive SPICEのプロセスである、SYS.3 システムアーキテクチャ設計プロセスでは、システムの機能要求と非機能要求に関して、静的/動的の両側面での設計が期待されています。 しかしながら、システムの構成要素であるセンサ・アクチュエータ・制御回路・マイコンなどに、システム要求をどのように割り当て、実装することが最適なのかを分析・検討することは難しいものです。単に、Automotive SPICEに期待されているように、静的な側面と動的な側面で設計結果を図案化しても、適切な設計をした根拠として少し心もとないですし、「流用元のシステムがこうなっているから」では説得力にも欠けます。今回は、システムエンジニアリングの国際標準である「ISO/IEC 26702 IEEE Std 1220-2005, Systems engineering – Application and management of the systems engineering process」を参考に、システム要求からシステムを設計する流れを解説していきます。 機能アーキテクチャと物理アーキテクチャシステム要求を実現するシステム構造は1つではありません。複数の実現案がある中から最適なシステム構造を決定していく必要があります。そのため、まずシステム要件を満たすために、システムが保有すべき、論理的な機能を定義し、それらの関係を整理していく必要があります。そして、これらの機能を、その後定義するシステムの構成要素(センサ・アクチュエータ・制御回路・マイコン)に割り当てていきます。システム構成要素を定義したものが物理アーキテクチャになります。システム設計の全体の流れを簡単に示すと下図のようになります。 機能分析機能アーキテクチャは、システム要件を満たすために、実行の順序、制御フローまたはデータフローを定義した機能・サブ機能および内部/外部インターフェースを整理したもので、システムの論理構成を示したものです。また機能アーキテクチャでは、システム機能をサブ機能に分解 (細分化) した結果生じる、サブ機能の機能的な配置と順序を検討する必要があります。この際、この後物理アーキテクチャを考慮せずに必要な機能配置を分析することがポイントになります。システム要件をインプットに、機能アーキテクチャを設計するためのプロセスは以下のようになります。  ここでの「振る舞いの分析」や「機能間インタフェース」の定義が、Automotive SPICEにおける静的な側面の仕様化の一部であり、「時系列の流れ」や「データフルーと制御フロー」の定義が、動的な側面の仕様化の一部となります。例えば、扇風機の機能アーキテクチャを設計した結果の一部である、論理構成のブロック図は以下のようになります。 ※具体的なやり方を知りたい方を知りたい方やトレーニングを受講されたい方は、是非お問い合わせください。 設計物理アーキテクチャは、機能アーキテクチャとシステム要件を満たすために、製品の設計結果提供する設計要素の配置を整理したものです。設計結果を定義し、検証された機能アーキテクチャの要件を満たす、システムの構成要素を特定します。機能アーキテクチャを元に、システム構成要素の配置、それらの分解、インターフェイス (内部および外部)、および設計制約を提供する物理(設計)アーキテクチャを設計していきます。この際、必要に応じて、複数の実現案を評価し、リスクを特定・評価・定量化し、適切なリスク軽減アプローチを選択した上で、コスト、スケジュール、およびパフォーマンスへの影響を分析することがポイントとなります。システム要件と機能アーキテクチャをインプットに、物理アーキテクチャを設計するためのプロセスは以下のようになります。    ここでの「機能をグルーピングし設計要素に割り当て」や「物理インタフェースの定義」が、Automotive SPICEにおける静的な側面の仕様化の一部であり、「設計特性や性能特性の定義」などが、動的な側面の仕様化の一部となります。例えば、扇風機の物理アーキテクチャを設計した結果の一部である、機能ブロックの設計要素への割り当て結果は以下のようになります。 ※具体的なやり方を知りたい方を知りたい方やトレーニングを受講されたい方は、是非お問い合わせください。 さいごにいかがでしょうか。単に、「システム要件をインプットに、静的設計と動的設計をして、システムアーキテクチャを設計しろ」と言われても、具体的に何すべきなのかはわかりにくと思います。しかしながら、システム要件を元に、必要なシステム機能を定義して、適切なシステム構成要素を定義する流れを想像してみれば、システムアーキテクチャ設計が少しイメージできるかと思います。SYS.3 システムアーキテクチャ設計プロセスを実装する際に、参考にしていただければ幸いです。 内山哲三

コラム

Automotive SPICEの活動を効率良く進めるために

弊社では、これまで Automotive SPICE に関する取り組みを数多く支援してきました。残念なことに、組織的にプロセス改善に取り組めている組織は少なく、大半がプロジェクト個別の活動となってしまい、組織として多大な費用がかかってしまっています。今回は、このような状況から抜け出し、効果的な改善活動を実施するためのヒントをご提供いたします。 何故、プロジェクト個別の活動になってしまうのか?まずは、この理由について考察してみます。その最大の理由は、車両メーカーがプロジェクト要件として Automotive SPICE を要求していることだと考えています。具体的には、次の2点がその原因だと分析しています: Automotive SPICE には、プロセス改善に必要なプロセスが取り上げられていない VDAスコープに、プロセス改善に必要なプロセスが入っていない  ここで引用した ISO 15504 は、Automotive SPICE のベースモデルであり、ソフトウェア開発プロセスの評価と改善のために必要なプラクティスを定義した国際規格です。そもそも SPICE とは Software Process Improvement and Capability dEtermination の略であり、ISO15504 の原案作成をしていたプロジェクトに付けられた名前です。 一方で車両メーカーは、特定部品のサプライヤーを選定するためにAutomotive SPICE を使用しています。そのため、車両メーカーとしては組織的なプロセス改善より、むしろ発注を予定している(1つの)プロジェクトのプロセス能力を重要視しているのです。これは、Automotive SPICEに定義されているプロセスや、車輌メーカーがアセスメント対象のプロセスとして採用しているVDAスコープにも現れています。上図に示すように、組織的な改善活動を実施するために参考になる、PIM.1(プロセス確立)、PIM.2(プロセスアセスメント)、RIN.1(人的資源管理)、RIN.2(トレーニング)、RIN.3(知識管理)、RIN.4(環境整備)などは Automotive SPICE には定義されておりません。唯一、PIM.3 が Automotive SPICE に含まれていますが、VDA スコープには取り上げられていません。 従って、車両メーカーの指定するプロセス(一般的にはVDAスコープ)だけを対象にしても、組織的にプロセス能力を向上させることは困難です。プロセス能力を継続的に向上させていくためには、Automotive SPICE には定義されていない他のプロセスの導入を検討する必要があります。例えば、上図で示した ISO15504 や 最近発行された Organization SPICE (概要は、こちらを参考にしてください)などを取り入れると良いでしょう。これまで筆者が見てきた中では、1社だけ PIM や RIN を参考に組織プロセスを定義している組織がありました。さすがに、この組織では改善活動が組織的に運営されていました。 この結果、何が起こっているか?Automotive SPICE 対応をしているプロジェクトでは典型的に次のような課題が見られます: プロジェクトごとに、Automotive SPICE の対応が実施されており、組織として無駄な工数が発生しているプロセス改善活動とは)組織能力を高めるために組織としてのプロセスを定義し改善する活動である プロジェクト定例会議の中でプロセス活動の議論がされ、プロジェクト工数が圧迫されているプロジェクト定例会議では)プロジェクト計画に対する状況と課題の確認を実施する場である 本来どうあるべきか?本来、組織としてプロセス改善活動を運営していれば、新たなプロジェクトが発足しても、Automotive SPICE 要求への対応を新たに実施する必要はないはずです。では、そのような状況を作り上げるには、どのようにすればよいでしょうか?私たちは、これまでの経験から次のことが重要だと考えています。  プロセス改善活動のアプローチを明確にする プロセス改善活動の目的を明確にし動機づけを行う プロセス改善活動の役割と責任を明確にする プロセス改善活動のアプローチに関するヒント改善活動は、米国のカーネギーメロン大学ソフトウェア工学研究所(SEI)が開発した組織的改善活動モデルであるIDEAL(Initiating Diagnosing Establishing Acting Learning)を参考にすると良いでしょう。このモデルでは5つの活動フェーズが定義されています。このモデルは、いわゆるPDCA と同様のモデルですが、改善活動には活動開始時の行動が重要という考え方から、立上げフェーズI(Initiaging)が加えられています。改善活動は、基盤を形成することが重要であり、この段階で組織のトップが改善活動に対する態度を決めることが重要であるとされています。  もう一つ、プロセス改善において重要な活動を説明いたします。IDEALモデルでは、行動・学習フェーズの活動となります。 1つ目は、プロセスの試行と評価です改善施策を本運用する前に、試行するプロジェクトを選定して、試行することそして改善の効果が当初の目標と比べてどの程度になるかを評価することが重要となります 2つ目は、プロセストレーニングの提供です改善施策が出来上がったら、改善プロセスの内容や新しい活動の目的をメンバーに周知する必要がありますトレーニングプログラムを通してプロセスの目的や意図を説明することがプロセスの定着にも寄与することになります 最後に、プロセス展開計画の策定と、実装状況の評価です「改善プロセスが完成したから、あとはプロジェクトが使うはずだ」と思っていても、なかなかうまくいきませんプロセス策定は、プロセスを使ってもらうための計画と評価まで実施して終了となります特に車両メーカーの要求に応えるために活動を実施していると、Automotive SPICE の要求を満たすためにプロセスを定義することが最優先となり、プロセスの効果測定やトレーニングの実施まで手が回らないことが多いようです。学習フェーズにあるように改善の効果を評価して、次の改善活動サイクルにつなげていくことが、継続的な活動につながっていくことになります。 プロセス改善活動の目的を明確にし動機づけに関するヒント次に、立上げフェーズの主題である改善活動の目的と動機づけに関するヒントを紹介します。改善活動では、組織のトップの行動が活動の成否を決めると言っても過言ではありません。ここにトップが実施すべき行動概要を記載しますので、参考にしてください。 トップがやる気になって、率先する 方針と方向を提示する プロセス改善の諸原則をコミットする 全参加者にプロセス改善を周知する プロセス改善の責任者を選定する 活動に必要な資源(人やインフラ)に関してコミットする 配下全員の意識改革の風潮を絶やさない プロセス改善活動の役割と責任に関するヒント最後に、改善活動をうまく運営していくためのヒントを紹介します。下図にあるように、各グループの責務を明確にし、トップ主導のもと全員が協力して活動を遂行していくことが効率の良い改善活動への第一歩となるでしょう。   いかがでしたでしょうか?本コラムの最後に、弊社が実践してきた中で得た教訓をいくつか紹介しますので、参考にしてください。 従来の開発プロセスを尊重する マネージャが率先して取り組む プロセス改善モデルの心を理解する 目的を理解する 誰がやっても同じようにできるようにする プロセス間、能力レベル間のつながりを理解する 全プロジェクトと EPG が協力し合う 継続できる改善施策を捻出する ツールを最大限に活用する ただし、担当者にストレスを感じさせないツールとする 品質はただでは得られない 継続的なプロセス改善への投資を必要とするが、他の選択肢より安く済む 日吉昭彦

コラム

Automotive SPICE 4.0 SYS.4の本質:つなげば終わりではない、”システム設計の整合性”を見極める

Automotive SPICE 4.0 に関するコラム、今回は SYS.4:システム統合および統合検証プロセスをテーマにお届けします。 はじめにAutomotive SPICE 4.0におけるSYS.4(システム統合および統合検証)とSYS.5(システム検証)は、システム開発の最終段階に位置づけられます。SYS.4では、SYS.3(システムアーキテクチャ設計)で設計したシステムエレメントを統合し、エレメント間のインタフェースや相互の振る舞いが設計通りに機能するかどうかを検証します。その後、SYS.5では、統合後のシステムが要求通りに動作するかどうかを確認することが求められます。しかし現場では、「システム要求に基づくテストは実施しているものの、設計されたシステム構造や振る舞いが正しく再現されているかを確認する視点が不足している」といった課題がしばしば見られます。表面的には動作しているように見えても、設計で意図されたインタフェース、動作シナリオが正しく実現されていないケースも少なくありません。たとえば、仕様通りに信号線が接続されていない、設計と異なる条件で処理が動いているといった状況です。 統合して明らかになる「設計と現実のギャップ」あるプロジェクトで、複数のECUやアクチュエータ、センサを含むシステムの統合工程に入りました。各チームは単体での試験を終えており、「統合しても問題なく動くだろう」と楽観視されていました。そして統合後すぐに、SYS.5で求められるシステム要求に対する検証が始まりました。ところが、ECUの起動タイミングが数百ミリ秒ずれただけで通信が確立せず、他のユニットが初期化エラーを起こすなど、思わぬ問題が発生しました。個別には正常だった電源ONシーケンスでも、統合環境では起動が不安定になる例もありました。さらに、擬似環境では正常に動いていたセンサとECUの接続も、実機では信号の立ち上がりや微小なノイズの影響で、ECUが信号を誤認識する事象が確認されました。仕様上問題ないはずの電圧レベルでも、実際にはセンサが“未接続”と誤判定するケースもありました。このように、統合して初めて明らかになる設計と現実のギャップは少なくありません。 「段階的統合」で見えてくる、システムとしての整合性SYS.4(システム統合および統合検証)では、「段階的な統合・検証」がキーワードです。具体的には、 システムエレメント間のインタフェースを確認しながらサブシステムを構築 サブシステム間を統合し、最終的なシステム全体を完成・検証というステップを踏み、システム全体の整合性を評価していきます。この過程では、電磁インタフェース、光インタフェース、コネクタや圧入、沿面距離・空間距離といった物理的な接続要素も重要です。なお、これらの項目には従来ハードウェアやメカ設計の領域と捉えられがちなものも含みますが、システムエレメント間のインタフェースの整合性として、システム統合の中で評価すべき重要な要素とされています。これらは仮想環境やシミュレーションでは評価が難しく、実際の統合(実統合)を行わなければ検証できません。製品が完成し、動作しているということは、どこかの工程で何らかの検証が行われているはずです。ただし、システムの視点をもつ担当者(いわゆる“システムグループ”)が不在であることもあり、Automotive SPICEで求められるような体系的かつ論理的な整合性の証明が行われていないケースも見受けられます。だからこそ、製品開発に関わる関係者がそれぞれどのような活動を行っているのかを全体として整理し、不足があれば補完していくような活動が重要です。このように、部分的な検証や整理されていない活動の積み重ねだけでは、システム全体の整合性を十分に評価することは困難です。すなわち、「統合検証」とは単に「最後にすべてを接続して動作確認する工程」ではなく、段階的な統合と検証を通じて、最終的に「アーキテクチャ設計で意図した接続関係やモード遷移が成立しているか」を評価する必要があります。たとえば次のような観点です: 運用モードの遷移(スタートアップ、スリープ、シャットダウンなど)が意図通りか 電源、CAN/LIN、アナログ信号など、物理インタフェースの整合性とタイミング 通信レイテンシやセンサ遅延による制御応答の影響これらはハードウェアやソフトウェア単独での試験では見えにくく、統合環境でこそ明らかになります。状態遷移ではなく、「モード挙動」として捉えるソフトウェアでは状態遷移表によって振る舞いを定義・検証することがありますが、SYS.4の観点では、「システムとしてのモード」とその全体挙動に注目します。たとえば以下のようなケース: システム起動時、すべてのシステムエレメントがタイミングよく初期化され、安定動作に入れるか? スリープ復帰後、センサや通信系が適切に再起動し、制御がスムーズに再開できるか? 異常発生後の復旧プロセスで、他のシステムエレメントに悪影響を及ぼさず、安全に切り替えられるか?これらは「状態遷移」だけでは捉えきれない、時間軸上の振る舞いや依存関係の問題です。こうした観点を踏まえ、設計意図をどのように検証へつなげていくかが問われます。設計意図を検証へつなぐためにこうしたSYS.4での検証を成立させるためには、前段階であるSYS.3において、システム全体の相互作用や外部環境要因による影響の検証に関する考慮がなされていることが前提となります。SYS.3でそれらが十分に記述されていない場合、SYS.4での整合性検証は困難になります。とはいえ、実際の車両開発の現場では、初回の開発フェーズからすべての外部環境要因による影響や振る舞いを設計に盛り込むのは困難なケースも多くあります。そうした場合は、SYS.5で得られた知見や不具合を、次の開発サイクルでのSYS.3およびSYS.4に反映させるという、継続的なV字開発の積み重ねが重要になります。また、SYS.3のシステム設計者とSYS.4のシステム検証者が異なる場合には、設計意図や想定されるシステム間の相互作用、起動シーケンスや電源設計上の前提などが十分に文書化・伝達されていなければ、SYS.4で本コラムで述べたような検証は難しくなります。設計と検証の橋渡しを行う情報伝達のプロセスも、品質保証の鍵となります。 まとめSYS.4の統合検証では、まず物理的な接続確認という基本を押さえたうえで、設計の意図や統合の前提が、システム全体として成立しているかを検証します。ここでの検証が不十分だと、最終段階や客先で重大な不具合が顕在化するリスクがあります。設計と検証は一方通行ではなく、相互に補完し合い循環的に成熟させるべき関係です。SYS.4を通じて、設計の妥当性を裏付け、次の開発サイクルへと知見をつなげていくことが、システム設計の真の“整合性”を育む鍵となるでしょう。あわせて、製品開発に関わる関係者がどのような活動を行っているのかを全体として整理し、不足があれば補っていくことも欠かせません。活動の連携や重複、見落としを明らかにすることで、統合検証の質はさらに高まります。今一度、自社のSYS.4プロセスを見直し、「設計者の意図や前提条件が、検証シナリオや試験条件にきちんと反映されているか」「想定されたモード挙動や副作用が試験されているか」といった観点から、検証の質を点検してみてはいかがでしょうか。 さいごに今回のコラムはいかがでしたでしょうか?本コラムの内容が、自社の開発プロセスの見直しや改善のきっかけになれば幸いです。現場で似たような悩みに直面している方にとっても、少しでもヒントになれば嬉しい限りです。ご相談いただければ、これまでの経験を活かしてお力になれることもあるかもしれません。どうぞお気軽にお問い合わせください。(安部宏典)