Updates

新着情報

WhitePaper

Modeling & Simulation SPICE 概説資料を公開しました

Intacs から公開されている Modeling & Simulation SPICE の概説書を作成いたしましたので公開いたします。ご興味のあるかたは、是非ダウンロードして活用してください。 コンテンツに含まれるもの: Modeling & Simulation SPICE の構造  信用できる決定プロセス群(DEC) DEC.1 エンジニアリングおよび決定タスク分析 DEC.2 サブタスク定義 DEC.3 結果評価および決定 モデリングおよびシミュレーションエンジニアリングプロセス群(MSE) MSE.1 シミュレーションサブタスクおよび目標分析 MSE.2 シミュレーション設定要求分析 MSE.3 シミュレーション設定設計 MSE.4 シミュレーション設定実装(エレメント構築) MSE.5 シミュレーション設定エレメント検証 MSE.6 シミュレーション設定統合および検証 MSE.7 シミュレーション実施および評価 MSE.8 シミュレーションサブタスクおよび目標達成の決定 信憑性保証プロセス群(CRD) CRD.1 重要度特定 CRD.2 信憑性尺度および手法 

コラム

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 システムアーキテクチャ設計プロセスを実装する際に、参考にしていただければ幸いです。 内山哲三

B'zine

B'zine - 2025年5月号(Automotive SPICE 入門一般開催日程など)発行

ゴールデンウィークで心身ともにリフレッシュされたでしょうか?B'zine 5月号を発行いたしました。B'zineは、1回/月のペースでの配信しています。ご興味のある方は、ここから登録をお願いいたします。   B'zineビジネスガレージ通信(2025年5月号)  ゴールデンウィークで心身ともにリフレッシュされたでしょうか?このところ関東も断続的に雨模様ですが、今年は九州南部では例年より二週間程度早く、5月16日梅雨入りしたようです。 【今月のトピックス】 イベント:ミニコンサル(無料相談会)開催(6月) イベント:Automotive SPICE 入門(実務者向け)一般開催トレーニング(7月、8月) コラム:Organization SPICE 成熟度レベル4、5の評価で対象にするプロセスについて コラム:成熟度レベルアセスメントに必要なインスタンス(プロジェクト)の選び方 コラム:Automotive SPICE 4.0SYS.4の本質:つなげば終わりではない、”システム設計の整合性”を見極める コラム:Automotive SPICEの活動を効率良く進めるために 【イベント】 ミニコンサル(無料相談会)6月開催のご案内弊社では、皆様のお困りごとに対する相談会を実施しています。Automotive SPICE/プロセス改善/プロジェクト管理など、お気軽にご相談ください。お申込みはこちらから→https://www.bgarage.co.jp/news/1119/ Automotive SPICE入門(実務者向け)一般開催トレーニング開催のご案内(7月、8月開催決定)開発現場の実務者に役立つような具体的な事例を含めて、プロセス毎に解説します。詳細・お申込みはこちらから→https://www.bgarage.co.jp/news/1121/ 7月Webinar(予定):Automotive SPICEプロセスと ISO26262/21434 の融合Automotive SPICEが規定する開発プロセスと、機能安全やサイバーセキュリティをどのように融合するかを解説します。 9月Webinar(予定):Modeling & Simulation SPICE 概説システム開発および運用において、高信頼性のモデルベース開発やシミュレーションの体系的なエンジニアリングプロセスについて解説します。 【資料公開】 Modeling & Simulation SPICE 概説(近日公開予定) 【コラム】 成熟度レベル4、5を評価する際のプロセス選定の考え方Organization SPICE には、成熟度レベル4、5を評価する際に選定すべきプロセスが規定されています。特に成熟度レベル4,5においては、プロセスを統計的に制御することで事業実績に貢献することが求められています。そのため、全てのプロセスを能力レベル4,5にする必要はなく、事業目標の達成に必要なプロセスに絞って統計的な制御をすることになります。Organization SPICE の記述には、このような背景が記載されていないため、本コラムで詳細に解説を行います。詳細はこちら→https://www.bgarage.co.jp/news/1069/ 成熟度レベルアセスメントに必要なインスタンス(プロジェクト)の選び方Organization SPICE には、成熟度を評価する際に少なくとも4つのプロセスインスタンス(プロジェクト)を選定する必要があると規定されています。しかしながら、その選定基準は記載されていません。そもそもプロセスインスタンスとは何か、何故4つ選択する必要があるのか?なども含めて、具体的な選定方法に関するヒントをご提供いたします。詳細はこちら→https://www.bgarage.co.jp/news/1074/ Automotive SPICE 4.0SYS.4の本質:つなげば終わりではない、”システム設計の整合性”を見極めるSYS.4(システム統合および統合検証)とSYS.5(システム検証)は、システム開発の最終段階に位置づけられます。SYS.4では、SYS.3(システムアーキテクチャ設計)で設計したシステムエレメントを統合し、エレメント間のインタフェースや相互の振る舞いが設計通りに機能するかどうかを検証します。その後、SYS.5では、統合後のシステムが要求通りに動作するかどうかを確認することが求められます。詳細はこちら→https://www.bgarage.co.jp/news/1034/ Automotive SPICEの活動を効率良く進めるためにこれまで Automotive SPICEに関する取り組みを数多く支援してきましたが、大半がプロジェクト個別の活動となっており、組織的にプロセス改善に取り組まれているケースは少ないようです。何故、プロセス改善活動がプロジェクト個別の活動になってしまうのかの理由を含め、効果的なプロセス改善活動を実施するためのヒントをご提供いたします。詳細はこちら→https://www.bgarage.co.jp/news/1031/  

お知らせ

Automotive SPICE 入門 一般開催トレーニングのご案内

Automotive SPICE 入門(実務者向け)一般開催(7月、8月分)の日程をご案内いたします。お申込みは、下記リンクあるいは「トレーニングラインナップ」からお願いいたします。 Automotive SPICE 入門管理支援編2025年7月02日2025年7月30日詳細はこちらからAutomotive SPICE 入門システムエンジニアリング編2025年7月09日2025年8月06日詳細はこちらからAutomotive SPICE 入門ソフトウェアエンジニアリング編2025年7月16日2025年8月20日詳細はこちらからAutomotive SPICE 入門ハードウェアエンジニアリング編2025年7月23日2025年8月27日詳細はこちらから  Teamsを使ったオンラインでの開催となります 教材は、原則開催日の5日前までにご指定場所に郵送いたします ご請求書はPDF版をメールで送付いたします お支払い期日は、ご請求書発行日の翌月末となります ご請求書発行後のキャンセルは、お断りしています(代理出席などの手配をお願いします)

コラム

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 が協力し合う 継続できる改善施策を捻出する ツールを最大限に活用する ただし、担当者にストレスを感じさせないツールとする 品質はただでは得られない 継続的なプロセス改善への投資を必要とするが、他の選択肢より安く済む 日吉昭彦