無料相談会
ミニコンサル（無料相談会）３月開催分の日程が決定しました
弊社では、皆様のお困りごとに対する相談会を実施しています。 Automotive SPICEに関すること 開発プロセスに関すること プロジェクト管理に関することなど、限られた時間枠での対応になりますが、お気軽にご相談ください。
Updates
新着情報
コラム
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.0 G 未満の場合, システムはエアバッグを展開してはならない。」このように、EARSの形式を活用しつつも、要求の意味や影響を慎重に検討することが求められます。 EARSを活用する際の留意点 EARSを適用する際には、以下の点に注意することで、より適切な要求仕様を記述できます。 簡潔かつ明確に: 余計な修飾を避け、短く分かりやすい表現を心がける。 一貫性の確保: SHALL（〜しなければならない）の使い方を統一し、主語を明確にする。 必要十分な情報を含める: 曖昧な表現を避け、要求に不足がないようにする。 トレーサビリティを意識: システム仕様や上位要件との整合性を確保する。 まとめ EARSは、シンプルな構文によって要求の曖昧さを排除し、仕様の誤解や抜け漏れを防ぐのに有効な手法です。ただし、形式に従うだけでは不十分であり、意図や条件を明確に記述することが重要 です。特に、エアバッグのような安全性が求められるシステムでは、適切な要求仕様が欠かせません。皆さんのプロジェクトでは、要求仕様をどのように記述していますか？EARSの活用を検討してみてはいかがでしょうか？ おわりに 今回のコラムはいかがでしたでしょうか？今後も数回にわたってAutomotive SPICE 4.0に関するコラムをお届けいたしますので、ご期待ください。（安部宏典）
お知らせ
お客様の多種多様なプロジェクトをサポートした、プロジェクトマネージメント運営支援の導入事例を追加しました
各種プロジェクト管理サポート支援サービスの導入事例車載システム開発を行っているお客様に対して、システム／ソフトウェア開発のプロジェクト管理支援を行いました。お客様の部門では、Automotive SPICEのレベル達成を要求されているプロジェクトもあれば、そうではないプロジェクトもありました。管理レベルが異なる様々なプロジェクトの管理を効率的に行うために、幅広いご支援をさせていただきました。今回はそのご支援実績をまとめたものを掲載しています。少しでもご興味のある方は、是非ご覧ください。各種プロジェクト管理サポート支援サービスの導入事例
お知らせ
お客様の事業に貢献した、技術コンサルティングの導入事例を追加しました
製品プラットフォーム開発技術支援の導入事例プリンタ開発を行っているお客様に対して、システム／ソフトウェア開発の技術コンサルティングを行いました。新製品のプラットフォーム開発からプロジェクト管理の支援まで、幅広いご支援をさせていただきました。今回はそのご支援実績をまとめたものを掲載しています。少しでもご興味のある方は、是非ご覧ください。製品プラットフォーム開発技術支援
YouTube
第２回 Automotive SPICE 4.0 変更点解説（ハードウェア設計プロセス） Webinar 動画を公開しました
先日開催した、第２回 Automotive SPICE 4.0 変更点解説（ハードウェ設計プロセス）の Webinar動画を YouTube に公開しましたのでお知らせいたします。当日録画した動画ファイルを３分割して、YouTube にアップロードいたしましたので、ご視聴ください。SYS/HWE/メカの適用範囲 そもそもシステムとは？ SYSプロセスの適用範囲 HWEとメカニカルの境界についてHWE設計プロセス 一般的なハードウェア設計工程の流れ ハードウェアエンジニアリングプロセス群 ハードウェア要件分析（HWE.1） HWE設計プロセス ハードウェア設計（HWE.2）
お知らせ
Organization SPICE が公開されています
Organization SPICE ver.4.00 が、2024年12月13日にリリースされていますのでお知らせいたします。PDFファイルは、intacs のホームページからダウンロード可能となっています。intacs Organization SPICE PRM/PAM v4.00 Organization PAMの冒頭では、プロセスアセスメントは特に自動車業界で Automotive SPICE として定着してきたが、単一プロジェクトへの適用から組織的な範囲に拡張して取り組む必要性が生じている、という趣旨の導入説明が書かれています。この PAM が取り上げる主要トピックは、「成熟度レベルの考え方」と「４つの追加プロセス」となっています。特に、追加された２つのプロセス（PIM.1；プロセス確立、RIN.2：スキル開発）は、 ISO 15504 で定義されていながら、Automotive SPICE では取り上げられなかったプロセスだということをご存じでしたでしょうか？ PIM.1 ：プロセス確立（組織標準プロセス構築に関するプラクティス）RIN.2 ：スキル開発（組織的な人材育成に関するプラクティス）QNT.1 ：定量的実績管理（プロセスの統計的管理に関するプラクティス）QNT.2 ：プロセス革新（統計的プロセス実績を用いた改革に関するプラクティス） PIM.1/RIN.2は、成熟度（能力）レベル３を達成するために重要なプロセスであり、QNT.1およびQNT.2は、それぞれ成熟度（能力）レベル４、５を実現するために必要なプロセスです。これらは、自立的なプロセス改善を組織的に取り組んできた人たちが、組織学習をしながら実践してきたノウハウの集積であり、プロセス改善を推進していくために重要なプロセスだと認識しています。 特に自動車産業においては、欧米の車両メーカーがサプライヤーの選定用に Automotive SPICE を使ってきた経緯があります。そのため、車両メーカーの焦点は、発注する「プロジェクト」となり、Organization PAM にあるようなプロセス改善をうまく進めるために必要な活動は Automotive SPICE のプロセススコープには含まれていません。弊社では、この背景がプロセス改善活動に苦労しているプロジェクトが数多く発生している原因になっていると考えています。開発組織としてプロセスを時代や顧客のニーズに合わせて継続的に改善していくためには、プロジェクトだけに焦点を当てるのではなく、組織的な活動としていくことが重要であり、今回公開された Organization SPICE は、そのヒントになると思います。 弊社では、下記のトピックスも今後「コラム」に掲載予定です： Automotive SPICE の活動は、なぜプロジェクト毎に個別に実施され効率的ではないのか？ Organization SPICE 概説ぜひ、皆さんのお悩みごとの解決のヒントにしていただければと考えています。