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

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には簡単に書かれていますが、なかなか奥の深いトピックだと思います。私たちは、実際の開発現場で成熟度レベル４、５の実装に長らく携わってきました。この活動では、多くの後戻りと苦悩がありました。一番つらかったのはレベル４、５の目指すところを理解できた時点で、それまで構築してきたレベル３プロセスの定義や実装を振り出しに戻す必要が出てきてしまったことです。それまでは、データの扱いや統計的にプロセスを制御するために適切なプロセス構造や活動になっていなかったのです。この時、プロセス改善モデルとの付き合い方として、その時点で目標とするレベルだけを意識するのではなく、一度高いレベルを学習した上で、上位レベルから下位レベルを俯瞰して活動する必要があることを学びました。同様の悩みをお持ちの方も多いと思いますので、その際はぜひ弊社までお声がけいただければと思います。日吉昭彦

成熟度レベルアセスメントに必要なインスタンス（プロジェクト）の選び方

先日、Organization SPICE 概説資料を公開しました。この資料は、Organization SPICE PAM の記載事項をなるべく忠実に表現する方針で作成しております。そのため、少し補足説明を入れないと理解しにくい部分が残ってしまっています。コラムでは、補足が必要だと思われる次の２点について解説いたします：成熟度レベルアセスメントに必要なインスタンス（プロジェクト）の選び方成熟度レベル４、５を評価する際のプロセス選定の考え方今回は、成熟度レベルアセスメントをする際に必要となるプロセスインスタンス選び方についてご説明いたします。PAMの記載事項を要約すると、次のようになります：プロセスインスタンスの選定可能であれば、少なくとも４つのフォーカスプロジェクトを選択する必要がある。選択されたすべてのプロセスは、フォーカス内で分析する必要がある。十分なカバレッジを達成するために、さらにプロセスインスタンスを追加することもできる。フォーカスプロジェクトと選択されたプロセスインスタンス全体は、いずれも組織ユニットのプロセスインスタンスを適切に代表するものでなければならない。プロセスインスタンスの選択基準は、定義されたアセスメントプロセスに従う必要がある。具体的には、どのように選定すればよいのでしょうか？プロセスインスタンスの考え方や組織のプロセス成熟度に関する補足説明がないとわかりにくい内容だと思います。ここからは、これらの背景について説明していきます。プロセスインスタンスとは何を指しているのか？プロセスインスタンスとは、「組織ユニットの中で組織標準プロセスを使用して活動した実例を示すもの」と解釈するとのが良いと思います。基本的には、１つのプロジェクトが１つのインスタンスとなります。つまり、プロジェクトが組織標準プロセスを履行した結果（足跡）ということです。ただし、プロセス改善プロセス（PIM.3）やスキル開発（RIN.2）など、プロジェクト単位ではなく組織として活動するプロセスは、プロジェクト単位とはならないケースも出てきます。なぜ、少なくとも４つのフォーカスプロジェクト（プロセスインスタンス）が必要となるのか？成熟度レベルアセスメントは、Automotive SPICE が通常１つのプロジェクトを評価対象とするのに対し、組織のプロセス成熟度を評価対象とするものです。従って、組織ユニット内の限定的な（例えば１つの）プロセスインスタンスを評価しても、組織のプロセス成熟度を公平に表すことはできません。１つだけ良くできた（あるいはアセスメントのためだけに準備された）プロセスインスタンスが組織ユニット全体を表しているわけではないからです。フォーカスプロジェクトは、どのような基準で選べば良いか？フォーカスプロジェクトは、PAM の記述にあるように組織ユニットのプロセスインスタンスを適切に代表するものでなければなりません。適切なインスタンスを選択をするためには、プロセスの履行にバラツキが出る要因を考慮しておくと良いでしょう：製品種別：開発する製品特性開発フェーズ：実施する作業工程、要求される期間、品質など組織体制：部門/課/グループの特徴プロジェクト規模：開発の大きさや、携わる人数ロケーション：仕事の実施される場所（国の習慣や、地域による人の風習など）顧客：開発要求元会社の文化ここに取り上げた例は、プロセス定義内容は同じにもかかわらず、作業上の違いが生まれてしまう可能性のある要因となるものです。成熟度レベルアセスメントの結果は、組織のベンチマークにも使われます。プロセスインスタンスの選定により評価結果が異なってしまうようでは、公平なベンチマークはできません。従って、成熟度レベルアセスメントにおいては、上記のような要因を考慮して、組織ユニットを代表するプロセスインスタンスを選定することが重要になってくるのです。選択したプロセスアセスメントモデルに、プロセスインスタンスの選定基準が定義されていれば、当然その基準を使用して選択する必要があります。アセスメントモデルに明確な定義がない場合は、選定した根拠を文書化しておくと良いでしょう。日吉昭彦

B’zine – ビジネスガレージ通信の配信を開始しました

関東では桜の季節も終わり、もうすぐ待ちに待ったゴールデンウィークですね。今月より Automotive SPICE や開発プロセスに関するトピックをお伝えする「B'zine」を開始しました。今後、毎月１回配信を予定しています。ご興味のある方は、ここから登録をお願いいたします。第１号の内容は、次のようになっています。 B'zineビジネスガレージ通信（2025年4月号）関東では桜の季節も終わり、もうすぐ待ちに待ったゴールデンウィークですね。 Automotive SPICEや開発プロセスに関連するトピックスをお伝えするB'zine - ビジネスガレージ通信の配信を開始しましたので、ご一読下さい。今後１回/月のペースでの配信を予定しています。【今月のトピックス】イベント：Organization SPICE 解説の無料 Webinar 開催（2025/5/14）資料公開：Organization SPICE 概説資料を公開コラム：システム/ソフトウェア開発に品質保証活動は必要なのか？コラム：Automotive SPICE GP 徹底解説～そもそも能力レベル２とは？【イベント】 Organization SPICE 解説の無料 Webinar 開催のご案内（5月開催決定）プロセスアセスメントは自動車業界では Automotive SPICE として定着していますが、プロジェクト適用から組織的な適用に拡張するために、「成熟度レベルの考え方」や「４つの追加プロセス（PIM.1、RIN.2、QNT.1、QNT.2）」を中心に解説します。日時：2025年5月14日16:00～17:00詳細はこちらhttps://www.bgarage.co.jp/news/1061/ ７月Webinar（予定）：Automotive SPICEプロセスと ISO26262/21434 の融合９月Webinar（予定）：Modeling & Simulation SPICE 概説【資料公開】 Organization SPICE 概説資料を公開しました先日、Organization SPICE が intacs から公開されたことをお知らせしましたが、その概説書を作成したので公開します。詳細はこちらhttps://www.bgarage.co.jp/news/1001/ 【コラム】システム/ソフトウェア開発に品質保証活動は必要なのかAutomotive SPICEのSUP.1 や CMMI では、システム/ソフトウェア開発の品質保証活動に対する要求事項を規定しています。なぜシステム/ソフトウェア開発に品質保証活動が必要なのかを、元となる規格や書籍を参考に、「品質保証活動の必要性」について解説します。詳細はこちらhttps://www.bgarage.co.jp/news/984/ Automotive SPICE GP 徹底解説～そもそも能力レベル２とは？プロセス能力レベル２とは、具体的にはどういう状態なのかについて解説します。プロセス能力レベル２では、繰り返しでの一定レベルの成果を期待しており、以下の２つの仕組みが実施できているかが要求されています。作業が計画的に実施できているか？作業成果物が管理され、品質がチェックされているか？詳細はこちらhttps://www.bgarage.co.jp/news/903/ご不明点、ご質問、ご要望等ございましたら、下記までご連絡ください。

新着情報