ビジネスガレージ株式会社

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 – 2025年5月号（Automotive SPICE 入門一般開催日程など）発行

ゴールデンウィークで心身ともにリフレッシュされたでしょうか？B'zine ５月号を発行いたしました。B’zineは、１回/月のペースでの配信しています。ご興味のある方は、ここから登録をお願いいたします。 B'zineビジネスガレージ通信（2025年5月号）ゴールデンウィークで心身ともにリフレッシュされたでしょうか？このところ関東も断続的に雨模様ですが、今年は九州南部では例年より二週間程度早く、5月16日梅雨入りしたようです。【今月のトピックス】イベント：ミニコンサル（無料相談会）開催（６月）イベント：Automotive SPICE 入門（実務者向け）一般開催トレーニング（７月、８月）コラム：Organization SPICE 成熟度レベル４、５の評価で対象にするプロセスについてコラム：成熟度レベルアセスメントに必要なインスタンス（プロジェクト）の選び方コラム：Automotive SPICE 4.0SYS.4の本質：つなげば終わりではない、”システム設計の整合性”を見極めるコラム：Automotive SPICEの活動を効率良く進めるために【イベント】ミニコンサル（無料相談会）６月開催のご案内弊社では、皆様のお困りごとに対する相談会を実施しています。Automotive SPICE/プロセス改善/プロジェクト管理など、お気軽にご相談ください。お申込みはこちらから→https://www.bgarage.co.jp/news/1119/ Automotive SPICE入門（実務者向け）一般開催トレーニング開催のご案内（7月、8月開催決定）開発現場の実務者に役立つような具体的な事例を含めて、プロセス毎に解説します。詳細・お申込みはこちらから→https://www.bgarage.co.jp/news/1121/ ７月Webinar（予定）：Automotive SPICEプロセスと ISO26262/21434 の融合Automotive SPICEが規定する開発プロセスと、機能安全やサイバーセキュリティをどのように融合するかを解説します。９月Webinar（予定）：Modeling & Simulation SPICE 概説システム開発および運用において、高信頼性のモデルベース開発やシミュレーションの体系的なエンジニアリングプロセスについて解説します。【資料公開】 Modeling & Simulation SPICE 概説（近日公開予定）【コラム】成熟度レベル４、５を評価する際のプロセス選定の考え方Organization SPICE には、成熟度レベル４、５を評価する際に選定すべきプロセスが規定されています。特に成熟度レベル４，５においては、プロセスを統計的に制御することで事業実績に貢献することが求められています。そのため、全てのプロセスを能力レベル４，５にする必要はなく、事業目標の達成に必要なプロセスに絞って統計的な制御をすることになります。Organization SPICE の記述には、このような背景が記載されていないため、本コラムで詳細に解説を行います。詳細はこちら→https://www.bgarage.co.jp/news/1069/ 成熟度レベルアセスメントに必要なインスタンス（プロジェクト）の選び方Organization SPICE には、成熟度を評価する際に少なくとも４つのプロセスインスタンス（プロジェクト）を選定する必要があると規定されています。しかしながら、その選定基準は記載されていません。そもそもプロセスインスタンスとは何か、何故４つ選択する必要があるのか？なども含めて、具体的な選定方法に関するヒントをご提供いたします。詳細はこちら→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 入門（実務者向け）一般開催（７月、８月分）の日程をご案内いたします。お申込みは、下記リンクあるいは「トレーニングラインナップ」からお願いいたします。 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を使ったオンラインでの開催となります教材は、原則開催日の５日前までにご指定場所に郵送いたしますご請求書はPDF版をメールで送付いたしますお支払い期日は、ご請求書発行日の翌月末となりますご請求書発行後のキャンセルは、お断りしています（代理出席などの手配をお願いします）

ミニコンサル（無料相談会）６月開催分の日程が決定しました

弊社では、皆様のお困りごとに対する相談会を実施しています。 Automotive SPICEに関すること開発プロセスに関することプロジェクト管理に関することなど、限られた時間枠での対応になりますが、お気軽にご相談ください。

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

弊社では、これまで Automotive SPICE に関する取り組みを数多く支援してきました。残念なことに、組織的にプロセス改善に取り組めている組織は少なく、大半がプロジェクト個別の活動となってしまい、組織として多大な費用がかかってしまっています。今回は、このような状況から抜け出し、効果的な改善活動を実施するためのヒントをご提供いたします。何故、プロジェクト個別の活動になってしまうのか？まずは、この理由について考察してみます。その最大の理由は、車両メーカーがプロジェクト要件として Automotive SPICE を要求していることだと考えています。具体的には、次の２点がその原因だと分析しています： Automotive SPICE には、プロセス改善に必要なプロセスが取り上げられていない VDAスコープに、プロセス改善に必要なプロセスが入っていないここで引用した ISO 15504 は、Automotive SPICE のベースモデルであり、ソフトウェア開発プロセスの評価と改善のために必要なプラクティスを定義した国際規格です。そもそも SPICE とは Software Process Improvement and Capability dEtermination の略であり、ISO15504 の原案作成をしていたプロジェクトに付けられた名前です。一方で車両メーカーは、特定部品のサプライヤーを選定するためにAutomotive SPICE を使用しています。そのため、車両メーカーとしては組織的なプロセス改善より、むしろ発注を予定している（１つの）プロジェクトのプロセス能力を重要視しているのです。これは、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 （概要は、こちらを参考にしてください）などを取り入れると良いでしょう。これまで筆者が見てきた中では、１社だけ PIM や RIN を参考に組織プロセスを定義している組織がありました。さすがに、この組織では改善活動が組織的に運営されていました。この結果、何が起こっているか？Automotive SPICE 対応をしているプロジェクトでは典型的に次のような課題が見られます：プロジェクトごとに、Automotive SPICE の対応が実施されており、組織として無駄な工数が発生しているプロセス改善活動とは）組織能力を高めるために組織としてのプロセスを定義し改善する活動であるプロジェクト定例会議の中でプロセス活動の議論がされ、プロジェクト工数が圧迫されているプロジェクト定例会議では）プロジェクト計画に対する状況と課題の確認を実施する場である本来どうあるべきか？本来、組織としてプロセス改善活動を運営していれば、新たなプロジェクトが発足しても、Automotive SPICE 要求への対応を新たに実施する必要はないはずです。では、そのような状況を作り上げるには、どのようにすればよいでしょうか？私たちは、これまでの経験から次のことが重要だと考えています。プロセス改善活動のアプローチを明確にするプロセス改善活動の目的を明確にし動機づけを行うプロセス改善活動の役割と責任を明確にするプロセス改善活動のアプローチに関するヒント改善活動は、米国のカーネギーメロン大学ソフトウェア工学研究所（SEI）が開発した組織的改善活動モデルであるIDEAL（Initiating Diagnosing Establishing Acting Learning）を参考にすると良いでしょう。このモデルでは5つの活動フェーズが定義されています。このモデルは、いわゆるPDCA と同様のモデルですが、改善活動には活動開始時の行動が重要という考え方から、立上げフェーズI（Initiaging）が加えられています。改善活動は、基盤を形成することが重要であり、この段階で組織のトップが改善活動に対する態度を決めることが重要であるとされています。もう一つ、プロセス改善において重要な活動を説明いたします。IDEALモデルでは、行動・学習フェーズの活動となります。１つ目は、プロセスの試行と評価です改善施策を本運用する前に、試行するプロジェクトを選定して、試行することそして改善の効果が当初の目標と比べてどの程度になるかを評価することが重要となります２つ目は、プロセストレーニングの提供です改善施策が出来上がったら、改善プロセスの内容や新しい活動の目的をメンバーに周知する必要がありますトレーニングプログラムを通してプロセスの目的や意図を説明することがプロセスの定着にも寄与することになります最後に、プロセス展開計画の策定と、実装状況の評価です「改善プロセスが完成したから、あとはプロジェクトが使うはずだ」と思っていても、なかなかうまくいきませんプロセス策定は、プロセスを使ってもらうための計画と評価まで実施して終了となります特に車両メーカーの要求に応えるために活動を実施していると、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プロセスを見直し、「設計者の意図や前提条件が、検証シナリオや試験条件にきちんと反映されているか」「想定されたモード挙動や副作用が試験されているか」といった観点から、検証の質を点検してみてはいかがでしょうか。さいごに今回のコラムはいかがでしたでしょうか？本コラムの内容が、自社の開発プロセスの見直しや改善のきっかけになれば幸いです。現場で似たような悩みに直面している方にとっても、少しでもヒントになれば嬉しい限りです。ご相談いただければ、これまでの経験を活かしてお力になれることもあるかもしれません。どうぞお気軽にお問い合わせください。（安部宏典）

コラム

2025/04/22

Organization SPICE 成熟度レベル４、５の評価で対象にするプロセスについて

先日、Organization SPICE 概説資料を公開しました。この資料は、Organization SPICE PAM の記載事項をなるべく忠実に表現する方針で作成してあります。そのため、少し補足説明を入れないと理解しにくい部分が残ってしまっています。コラムでは、補足が必要だと思われる次の２点について解説いたします：成熟度レベルアセスメントに必要なインスタンス（プロジェクト）の選び方成熟度レベル４、５を評価する際のプロセス選定の考え方前回のコラムでは、インスタンスの選び方をご紹介しましたので、今回は成熟度レベル４、５を評価する際のプロセス選定の考え方についてご説明いたします。PAM の記載事項を要約すると、次のようになります：成熟度レベル４、５インスタンスの選定高成熟度（レベル４、５）については、選択されたプロセスセットがそれぞれ能力レベル４および５を達成することが期待される。このセットには、必ずしもすべてのプロセスが含まれる必要ははない。プロセスによっては、能力レベル３を超える根拠やビジネス上のメリットが全くない場合があるからである。（例えば、統計的な手法が適用できないほどインスタンス数が少ないなど）とはいえ、能力レベル4/5に選択された一連のプロセスについては、それらがどのように業務に貢献しているのか、きちんとした分析が必要である。その分析に基づき、能力レベル4/5のプロセスが、大半のプロジェクト（成熟度レベル４の場合）または企業/組織/部門（成熟度レベル５の場合）において、かなりの量の業務成果に貢献していることを明確にする必要がある。このプロセスセットには、少なくとも１つの基本プロセスが含まれている必要があるが、通常は相互に関連するプロセスグループが存在している。さらにこのプロセスセットには、成熟度レベル２以上の拡張プロセスを含むことができる。これは、どういうことを言っているのでしょうか？成熟度レベル４以上の活動を経験された方には理解できると思いますが、補足説明がないとわかりにくい内容だと思います。ここからは、これらの背景について説明していきます。なぜ能力レベル4、5を達成する必要のあるプロセスは限定的（このセットには、必ずしもすべてのプロセスが含まれる必要はない）で良いのか？レベル４、５は、プロセスが事業へ貢献することに焦点を当てているからです。つまり、事業目標を達成するためには、どのプロセスを統計的に制御すると効果があるかを分析する必要があるのです。言い換えれば、すべてのプロセスを統計的に制御しても意味がありません。例えば、品質の向上が事業遂行上の最優先課題とした場合に、MAN.3（プロジェクト管理プロセス）やSUP.8（構成管理プロセス）を統計的に制御することで品質向上に大きく寄与するでしょうか？これらのプロセスを選択するよりも、むしろ過去の不具合傾向を見て、例えば詳細設計プロセスやレビュープロセスに焦点を当てることの方が品質向上に貢献しそうだと思いませんか？つまり、プロセスによっては、能力レベル３を超える根拠（統計的にプロセスを制御する）やビジネス上のメリットが全くない場合があるということなのです。次に、「能力レベル４および５を達成することが期待される」とは具体的にどのような状態なのでしょうか？レベル４と５では、期待値が多少異なるので２つに分けて説明します：レベル４が期待するプロセス制御レベル４においては、組織内のプロジェクトから収集した標準プロセスの実績データを活用して、プロジェクトを成功に導くことが期待されています。プロセスは、プロジェクトの実績向上に寄与することに焦点が当てられていますが、プロジェクト実績の向上は結果的に組織の事業実績に貢献することになります。まずは、事業目標を達成するために各プロジェクトはプロジェクト目標を設定します。次に、プロジェクト目標を達成するためにキーとなるプロセスを選択し、このプロセスを統計的に制御（そのイメージは後述します）していきます。つまり、プロセス実績データを統計的に分析しながら、都度プロジェクト実績を予測して、早め早めに手を打つことでプロジェクト目標の達成に導いていくための手法なのです。データの扱い方の観点から見ると、レベル３のプロセス状態におけるプロジェクト管理では、その時点までに収集したデータを使って状況を把握していると言えます。言い換えると、自動車のバックミラーに映し出された形跡（プロジェクトが実施してきた結果）を見てプロジェクトを管理していることになります。一方、レベル４では、組織内の過去プロジェクトが使用した標準プロセスの実績データの集合から予測モデルを作成して、都度プロジェクト実績をモデル式に当てはめ、プロジェクト終了時点の実績を予測しながらプロジェクトを制御しているのです。こちらは、航空機がランディングする際に自動操縦で滑走路（プロジェクトのゴール）にアプローチするような例えになります。レベル５が期待するプロセス制御レベル５においては、組織内のプロジェクトから収集した標準プロセスの実績データを活用して、組織のプロセス革新を実現することが期待されています。プロセスは、組織の事業実績の向上に直接寄与することに焦点が当てられます。レベル４の活動においてプロセスを統計的に制御することが可能になったプロセス実績データを組織改革に活用することがプロセス成熟度の考え方の最終ゴールとなります。ここでは、新しい技術を現在使用している標準プロセスに組み込んだ場合に、プロセス実績がどのように変化するかを予測モデルから評価します。このようなことができるようになると、刻々と変化するビジネス環境に合わせてダイナミックにプロセスを改善・改革することが可能になり、競合他社に対して優位性を持つことができるわけです。ここでの説明のとおり、成熟度レベル４の場合は活動の焦点がプロジェクトに向けられています。一方、成熟度レベル５の場合は企業/組織/部門の業績に焦点を当てていることになります。最後に、「統計的な手法が適用できないほどインスタンス数が少ない」ということに関して補足しておきますこれは、実際にプロセスを統計的に制御する活動をしてみるとわかるのですが、プロセス実績データ（インスタンス）を数多く、かつ頻繁に入手・評価できないと、実際の制御には活用できないということなのです。例えば、プロジェクトの生産性のような指標は、プロジェクトが終了しないと収集できません。また、このようなデータはプロジェクト１つで１点のデータとしてしか入手できません。プロセスを統計的に制御するためには、プロセス実績の中心値やバラツキを見ながらプロセス実績を評価することになるので、インスタンスが少ないとうまく活用できません。データの母集団を作成するためには、膨大なプロジェクトが必要になりますし、プロジェクトが終わってしまっては、そのプロジェクトの将来を予測できません。わかりやすい例として、レビュープロセスの実績データがあります。レビューはプロジェクトの中でもかなりの回数実施されるでしょう。母集団の作成も容易にできますし、レビュー終了時点で実績値を予測モデルに当てはめれば、直近のレビュー結果がプロジェクトの将来に与える影響も判断することができます。今回のコラムはいかがだったでしょうか？PAMには簡単に書かれていますが、なかなか奥の深いトピックだと思います。私たちは、実際の開発現場で成熟度レベル４、５の実装に長らく携わってきました。この活動では、多くの後戻りと苦悩がありました。一番つらかったのはレベル４、５の目指すところを理解できた時点で、それまで構築してきたレベル３プロセスの定義や実装を振り出しに戻す必要が出てきてしまったことです。それまでは、データの扱いや統計的にプロセスを制御するために適切なプロセス構造や活動になっていなかったのです。この時、プロセス改善モデルとの付き合い方として、その時点で目標とするレベルだけを意識するのではなく、一度高いレベルを学習した上で、上位レベルから下位レベルを俯瞰して活動する必要があることを学びました。同様の悩みをお持ちの方も多いと思いますので、その際はぜひ弊社までお声がけいただければと思います。日吉昭彦

新着情報