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

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 の記述にあるように組織ユニットのプロセスインスタンスを適切に代表するものでなければなりません。適切なインスタンスを選択をするためには、プロセスの履行にバラツキが出る要因を考慮しておくと良いでしょう：製品種別：開発する製品特性開発フェーズ：実施する作業工程、要求される期間、品質など組織体制：部門/課/グループの特徴プロジェクト規模：開発の大きさや、携わる人数ロケーション：仕事の実施される場所（国の習慣や、地域による人の風習など）顧客：開発要求元会社の文化ここに取り上げた例は、プロセス定義内容は同じにもかかわらず、作業上の違いが生まれてしまう可能性のある要因となるものです。成熟度レベルアセスメントの結果は、組織のベンチマークにも使われます。プロセスインスタンスの選定により評価結果が異なってしまうようでは、公平なベンチマークはできません。従って、成熟度レベルアセスメントにおいては、上記のような要因を考慮して、組織ユニットを代表するプロセスインスタンスを選定することが重要になってくるのです。選択したプロセスアセスメントモデルに、プロセスインスタンスの選定基準が定義されていれば、当然その基準を使用して選択する必要があります。アセスメントモデルに明確な定義がない場合は、選定した根拠を文書化しておくと良いでしょう。日吉昭彦

システム／ソフトウェア開発に品質保証活動は必要なのか？

はじめにAutomotive SPICEのSUP.1やCMMIのPPQAでは、システム開発／ソフトウェア開発の品質保証活動に対する要求事項をまとめています。しかしながら、そもそもなぜシステム開発／ソフトウェア開発に品質保証活動が必要なのかを考えたことがありますか？今回は、SUP.1やPPQAの元となっている規格や書籍を参考に、「品質保証活動の必要性」について考えていきます。品質保証の規格MIL規格（Military Standard）最初に品質保証が規格として体系化されたのは、MIL-STD-109で、1960年代後半に初版が制定されました。この中で「品質保証（Quality Assurance）」を以下のように定義しています。A planned and systematics pattern of all actions necessary to provide adequate confidence that management and technical planning and controls are adequate to: Established correct technical requirements for design and manufacturing. Create products and services that confirm to the established technical requirements.管理および技術計画と制御が次の事項に適切であるという十分な確信を与えるために必要なすべてのアクションの計画的かつ体系的なパターン。設計および製造に関する正しい技術要件を確立する。確立された技術要件に準拠する製品およびサービスを作成する。つまり「適切に正しい技術要件を定義して、適切にそれに準じた製品やサービスを作っている確信を得るための活動」が品質保証であるとしています。さらにその技術要件の重要な要素である品質要件についても以下のように定義しています。The technical requirements relating to the quality of the product (supply or service) and contract clauses prescribing quality standards, inspection, and other quality controls incumbent on the contractor, to assure that the product or service confirms to the contractual requirements.製品 (供給またはサービス) の品質に関する技術要件、および契約者に課せられた品質基準、検査、およびその他の品質管理を規定する契約条項で、製品またはサービスが契約要件に準拠していることを保証する。契約者（≒供給者）が、要件通りのモノを作ったことを保証するための契約事項（≒約束事）を品質要件と定めています。言い換えると、要件通りにモノを作ったことを対外的に保証する行為が品質保証活動だと言えるでしょう。ISO規格（国際標準規格）品質に関する国際標準は、皆さんもご存知のISO 9000シリーズです。1980年代に制定されましたが、その中のISO 9003が、特に「最終検査および試験における品質保証モデル」に焦点を当てた規格です。ISO 9003は、製品の最終検査と試験を通じて品質を保証するためのガイドラインを提供していました。ISO 9003は、長期間にわたって製造、設計、その他の使用方法が確立されている製品に対して、最終検査のみで品質を保証するための規格でしたが、2000年の改訂により、ISO 9001に統合され、より柔軟で包括的な品質マネジメントシステムの規格となりました。IEEE規格（電気・電子工学分野における国際標準規格）電気・電子工学分野における国際的な標準を策定するための組織であるIEEE（Institute of Electrical and Electronics Engineers）も、前述のMIL-STDをベースに1970年代後半に品質保証の国際標準を制定しました。IEEE Std 730IEEE Standard for Software Quality Assurance Processesがその規格であり、今もなお改版を続けています。この中で、Automotive SPICEやCMMI以上に詳細説明があるので、この規格を参考に必要性を整理していきます。この国際標準では、SQAプロセスの目的と以下のように定義しています。「ソフトウェア開発プロジェクトが SQA プロセスを使用して、ソフトウェア製品が確立された要件に準拠していることを正当に証明するための根拠となる証拠を作成および収集できるようにすること」やはり、品質保証を要件通りにモノを作ったことを対外的に保証する行為と位置付けています。 QAが準拠保証しなくてはならない要件とは Automotive SPICEのSUP.1でも定義されているように、成果物とプロセスの品質保証をする必要があるため、QAが遵守保証しなくてはならない要件は、プロダクト要件とプロセス要件になります。IEEE std 730では、契約事項である利害関係者要件から導出されたプロダクト要件とプロセス要件に対し、図にあるような適合関係の推移性に基づいて、1つ前の情報と比較し適合していることを確認することで、プロジェクト全体を通じて、「要件通りにモノを作ったことを保証する」こととしています。契約事項と導出されたプロセス要件の適合を確認するプロセス要件と導出された計画やプロセス、標準や手順の適合を確認する計画やプロセス、標準や手順と実際の活動結果の適合を確認するこのように、1つ前の情報との適合を確認することが、品質保証活動の基本的な考え方となります。プロジェクト内のレビューやチェックだけでは品質保証は十分なのか？契約事項に基づいた「要件通りにモノを作ったことを対外的に保証する」必要性は、開発に携わった人であれば理解できることかと思います。それでは、その対外的な保証はプロジェクト内の活動だけで十分であると考えることはできないのでしょうか？先のコラムAutomotive SPICE SUP.1 本当に品質は良くなるの？でも引用した「プロセス成熟度の改善」（Watts S. Humphrey著日本語訳：日科技連出版社発行）には、客観的な品質保証の必要性を以下のように説明しています。監査者に対し客観的になることは、誰にとっても難しい。一般に、我々はかなり注意深く仕事をやっており、そうでないように言われると不愉快に感ずる。しかし、「外側から」のレビューを行うのは、釣り合いのとれた見方が必要だからである。たとえば、あなたがこれからパラシュートを包み終えて跳ぼうとしているとする。有能な検査者があなたの1つ1つの動作を監視して本当に正しく行ったということを保証してくれるならば、あなたの幸せになれる勝算は大きくなる。品質が決定的に重要な場合は、なんらかの独立したチェックが必要である。それはその人たちが信頼できないからではなくて、その人たちが人間だからである。ソフトウェアにおける問題は、チェックが必要かどうかではなく、誰がどうやるかである。小規後な組織では、しばしば管理者自身が作業を直接に監視できるので、SQAの活動は必要がない。部下の数が多くなるにつれて管理者は他の業務に巻き込まれ、次第に日常の技術的作業ができなくなってしまう。このような時には、管理者は次の事項の1つを行うことが必要である。余分な負荷をうまく扱うなんらかの方法を見つけ、部下の仕事をより密接に監視できるようにする。監視する人を雇う。部下同士が互いに監視するように動機づける。技術的、経済的、そしてモラル上の観点から、最後の選択が一般には最も望ましい。残念ながら、歴史的にもソフトウェアの組織が数十人を越えてくると、この「ニ人一組方式」は崩壊してしまう。このような場合には、SQAによって解決しなければならないのである。規模が膨らみ、複雑なシステム／ソフトウェア開発を行っているからこそ、管理者に代わって、「要件通りにモノを作ったことを対外的に保証する」客観的な視点が必要になるのです。当然ながら、管理者のサポートが、効果的な品質保証活動を行う大前提となります。さいごにいかがだったでしょうか。今回は、改めて品質保証活動の必要性について考察してみました。皆さんの効果的な品質保証活動を行う動機付けになれば幸いです。内山哲三

Automotive SPICE GP 徹底解説その３～そもそも能力レベル２とは？

これまで２回にわたって Automotive SPICE の GP（General Practice）について解説しましたが、今回は「能力レベル２って、どういう状態なの？」というテーマでお届けいたします。本題に入る前に、「プロセス」って何でしょうか？と聞かれても、皆さん明確には答えにくいのではないでしょうか？最近流行りの生成AI君に尋ねてみると：プロセスとは、物事がある結果に達するまでの道筋や手順、方法を意味します類義語には、「過程」、「経過」、「手順」、「工程」などがありますと答えてくれました。そもそもカタカナで書いてあることから「プロセス」は日本語由来のものではなく、類義語ででてくるように人によってそれぞれの解釈で日本語に当てはめているものと思います。アセスメントのインタビューで、「私達にはプロセスはありません」という発言を聞くことがありますが、この言い回しは正しくありません。アセスメントの場では、発言者は「プロセス」＝「手順を文書化したもの」と勘違いしてしまっているのです。何らかの成果物が生成されている限り、そこに至った過程、経過や手順は存在するはずです。次のような２つのグループがある場合、あなたならどちらのグループに仕事を依頼したいですか？グループA 計画書を作成して、作業状況を計画に照らしてチェックしているあらかじめ作成すべき作業成果物を決めて、ドキュメントを管理している作成したドキュメントは、必ずレビューを実施して誤りを訂正しているグループB 計画書はなく、グループ員にヒアリングしないと状況はわからない作業成果物は担当者の申告ベースで、何があるか、何処にあるかはわからないレビューは実施せず、担当者の力量に任せているこれだけでは、どちらのグループが良い成果物を納入する可能性があるか判断できませんが、グループBの方は、よっぽど優秀なメンバーが揃っていないと任せるのは怖い感じがしませんか？この２つのグループの違い、つまり仕事の仕方の違いがプロセス能力の違いなのです。アセスメントでは、プロジェクトにおける仕事の仕方および作成された成果物の十分性を判断して、プロセス能力を判定しています。ではプロセス能力レベル２とは、どんな状態なのでしょうか？次の２つがポイントとなります作業が計画的に実施できているか？作業成果物が管理され、成果物の品質がチェックされているか？つまり、この２つの仕組みができていれば、プロジェクトに携わる人が変わったとしても、繰り返し一定レベルの成果が期待できるということなのです。このようなプロセスの状態になっているプロジェクトを「能力レベル２」と呼ぶというのが、アセスメントの評価基準になります。アセッサーによっては重箱の隅をつつくように細かいことを指摘する人がいますが、極めて基本的なことだと思いませんか？Automotive SPICEでは、PA（Process Attribute）とGP（General Practice）を能力レベル２の判定基準として定めています。事例も含めて表にまとめてみました。それほど高い壁ではないと思いますので解釈の参考にしてください。また、GPとプロセスには上図に示すような密接な関係があります。GPを十分に実現するためには、対応するプロセスで定義されるBP（Base Practice）の内容を実施しておく必要があると読み替えてください。文書だけでは、わかりにくい領域だと思います。弊社ではAutomotive SPICEに関する無料相談会（ミニコンサル）も実施していますので、お気軽にご相談ください。日吉昭彦

Automotive SPICE SUP.1 本当に品質は良くなるの？

今回は、品質保証に関する話題をご提供いたします。プロセス改善モデルには、品質保証というプロセスが定義されています。Automotive SPICE では、SUP.1（品質保証）、CMMI v1.3では、PPQA（プロセスと成果物の品質保証）というプロセスが該当します。（CMMI v2.0/3.0では、品質保証の考え方が多少変わってきていますので、後述いたします）さて、これらのプロセスを実装することで、良い品質の製品をリリースできるでしょうか？筆者は、本件については甚だ懐疑的です。というのも、これまで自身の担当するプロジェクトで、単純にAutomotive SPICEのSUP.1プラクティスに記載されている内容を実施してきましたが、効果を感じられませんでした。また、多くの組織やプロジェクトを見ても、状況はあまり変わりません。はじめてSW-CMM（CMMIの前身モデルです）というモデルの導入を検討していたとき、SQA（ソフトウェア品質保証）プロセスとは、「プロジェクトが、決められた方法（約束事）に従って活動していることを評価する」ということだと知り、これで品質が担保できるのかと不思議に思ったものでした。これらの原因は、品質保証活動＝プロセス監査という考え方になってしまっていることにあると考えています。確かに Automotive SPICE SUP.1の各プラクティスを見ても、監査すれば十分であると読めてしまうところがあると思います。また、プロセスモデルでは「品質管理」というプロセスが別に定義されていることもあり、このような実装になってしまうことも仕方ないかもしれません。しかしながら、せっかく品質を保証する活動を導入するのであれば、もう少し実際の品質に寄与できる活動にしたいとは思いませんか？重箱の隅をつつくような作業や、不遵守が発見されない監査項目に多くの時間をかけて作業するのは勿体ないですよね。ここからは、こういった現象に気付いた私たちが実践してきた、品質保証活動の刷新についてご紹介いたします。まずは、本当の意味での品質保証活動について考え直すことから始めました。一番参考になったのは、「プロセス成熟度の改善」（Watts S. Humphrey著日本語訳：日科技連出版社発行）です。この本は、私たちが赤本と呼び、プロセス改善のバイブルとして長年使っているものです。品質保証として評価すべき観点を列挙し、それぞれの開発工程で確認すべき点をまとめました。下記に概略を記載しますので、参考にしてください。構成管理：計画とその遵守、設計書・ソースコード・テスト仕様、構成監査レビュー：レビュー計画と運営状況の確認、各工程のレビューへの参加と品質確認監査：プロセスの遵守性要求仕様：顧客要求の合意形成、要求のテスト可能性、要求毎の進捗状況設計：開発進捗、レビュー摘出率、コードメトリクス、トレーサビリティテスト：テスト計画、不具合発生と解決データのトレース、テスト報告書ツール：使用ツールの妥当性、ツール使用状況修正処置：変更依頼の状況、修正手順、各工程の修正の開始から完了までの状況、問題原因の傾向外注先：外注先の品質保証プロセス、設計標準の確認、品質データの把握計画：計画の妥当性、計画変更の妥当性、計画に対する進捗状況出荷：レビュー・テスト指摘解決状況、テスト報告書、出荷審査こうしてみると、かなり実施すべきことがあると思いませんか？次に品質保証活動の役割分担について考えました。本来の意味での品質保証活動を実施するにあたり、品質保証活動の役割を次のように細分化しました。品質システム担当：品質システムの構築・運用品質分析担当：各プロジェクト品質データの取りまとめ・分析・報告内部レビュー担当：プロジェクト内部のレビュー実施者（開発者）外部レビュー担当：プロジェクト外の開発者、品質保証グループによるレビュー実施者プロセス監査担当：プロジェクトの監査実施者品質保証活動プロセスの（再）定義品質保証活動の観点と役割から、品質保証グループとして実施すべき活動とプロジェクトの品質保証活動の２つに分けて、品質保証活動のプロセスを定義しました。プロセスの概要は、導入事例（品質保証活動の刷新）を参照してください。気が付いている人も多いようですが、監査だけでは品質は良くなりません。品質保証に携わる組織としては、プロジェクトの品質データを収集し、そのデータをもとに品質課題を解決する活動が重要です。長年の開発経験からわかることは、重大な不具合はソフトウェア全体が悪いわけではなく、ある特定のコンポーネントの不出来が起因して起こるということです。これらを如何に開発途中で見つけるかが品質保証活動のキーポイントとなるはずです。いつまでも設計が終わらない機能、規模が膨大になっているソフトウェアコンポーネント、コードメトリクスが例外値を示しているソフトウェアユニット、多くの不具合が発生している機能など、これらを調査することで未然に予防できることがあるはずです。 Automotive SPICE SUP.1や、CMMIを取り巻く環境も近年変化が見られるようです。欧州の自動車メーカーからは、プロジェクトの品質データを毎月提出することが求められるようになりました。CMMI v2.0/3.0では、「品質の確保」という属性の中に４つのプラクティス領域（ピアレビュー、プロセス品質保証、要件の開発と管理、検証と妥当性）を設け、従来のPPQAプロセスだけでなく他のプロセスを品質に結び付けています。皆さんも、監査だけの品質保証から、本質的な活動に移行してみませんか？日吉昭彦

見える化する要求仕様〜 EARS（Easy Approach to Requirements Syntax）を活用したシステム要求の書き方〜

Automotive SPICE 4.0 に関するコラム、今回は「EARSを活用した要求文の書き方」についてお届けいたします。はじめにシステム開発において、明確で一貫性のある要求仕様を書くことは極めて重要です。しかし、要求の記述が曖昧であったり、解釈の余地が大きいと、後の開発フェーズで認識のズレや仕様変更が発生し、コストや工数の増加につながります。そこで、本コラムでは「EARS（Easy Approach to Requirements Syntax）」という手法を紹介します。EARSは要求を定義するためのテンプレートで、要求をシンプルかつ明確に記述するための構文を提供し、解釈のブレを防ぐことができます。 EARSの基本構造 EARSは要求の表現方法を体系化し、以下の６つの基本パターンを定義しています。１．Ubiquitous（一般的な要求）: 常に適用される要求に使用します形式: 「The [システム] shall [動作]」例: 「システムは、車両の衝突が検知された場合、適切なエアバッグを30ミリ秒以内に展開しなければならない」２．Event-driven（イベント駆動要求）: あるイベントが発生した場合に適用される要求に使用します形式: 「When [イベント], the [システム] shall [動作]」例: 「正面衝突を検知した場合、システムは30ミリ秒以内にフロントエアバッグを展開しなければならない」３．State-driven（状態駆動要求）: システムが特定の状態にある場合に適用される要求に使用します形式: 「While [状態], the [システム] shall [動作]」例: 「車両が走行中である間、システムは衝突を検知するために衝撃センサーを監視しなければならない」４．Optional（オプション要求）: 追加機能やオプションの機能に関する要求に使用します形式: 「Where [条件], the [システム] shall [動作]」例: 「車両が助手席用エアバッグを搭載している場合、システムは助手席の占有センサーを監視しなければならない」５．Unwanted Behavior（望ましくない動作の要求）: 望ましくない状況を回避するための要求に使用します形式: 「If [条件], the [システム] shall not [動作]」例：「助手席に乗員がいない場合、システムは助手席エアバッグは展開してはならない。」6．Complex（複雑な要求）: 複数の条件やイベントを組み合わせて記述する要求に使用します形式: 「When [イベント], if [条件], then the [システム] shall [動作]」例: 「正面衝突が検知され、かつ助手席が占有されている場合、システムは助手席のエアバッグを展開しなければならない。」 EARSの適用時に注意すべきポイント EARSを活用すると、要求の曖昧さを減らし、明確な仕様を記述できます。しかし、EARSの形式に従っているだけでは、必ずしも適切な仕様になるとは限りません。要求の内容そのものが不適切だと、意図しない動作を引き起こす可能性があります。例えば、Unwanted Behavior（望ましくない動作の要求）として以下のような仕様を考えてみます。「車両が静止している間, システムはエアバッグを展開してはならない。」この要求の意図が「エアバッグ誤展開の防止」だとしても、そのままでは停車中に衝突された場合でもエアバッグが展開しない可能性があります。本来ならエアバッグが展開すべき状況でも、要求の誤解によって安全性が損なわれる恐れがあります。こうした問題を防ぐためには、要求の意図を明確にし、条件を具体的に記述することが重要です。例えば、以下のように修正すると、誤展開を防ぎながら、必要な場合には展開できる仕様になります。「車両が静止中かつ衝突の加速度が 1.0g 未満の場合, システムはエアバッグを展開してはならない。」このように、EARSの形式を活用しつつも、要求の意味や影響を慎重に検討することが求められます。 EARSを活用する際の留意点 EARSを適用する際には、以下の点に注意することで、より適切な要求仕様を記述できます。簡潔かつ明確に: 余計な修飾を避け、短く分かりやすい表現を心がける。一貫性の確保: SHALL（〜しなければならない）の使い方を統一し、主語を明確にする。必要十分な情報を含める: 曖昧な表現を避け、要求に不足がないようにする。トレーサビリティを意識: システム仕様や上位要件との整合性を確保する。まとめ EARSは、シンプルな構文によって要求の曖昧さを排除し、仕様の誤解や抜け漏れを防ぐのに有効な手法です。ただし、形式に従うだけでは不十分であり、意図や条件を明確に記述することが重要です。特に、エアバッグのような安全性が求められるシステムでは、適切な要求仕様が欠かせません。皆さんのプロジェクトでは、要求仕様をどのように記述していますか？EARSの活用を検討してみてはいかがでしょうか？おわりに今回のコラムはいかがでしたでしょうか？今後も数回にわたってAutomotive SPICE 4.0に関するコラムをお届けいたしますので、ご期待ください。（安部宏典）

新着情報

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

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