つぶやき
Automotive SPICE 4.0 日本語版発行
Automotive SPICE 4.0の日本語版が発行されました。VDAのホームページからダウンロード可能になっています。https://vda-qmc.de/en/automotive-spice/automotive-spice-veroeffentlichungen/
Updates
新着情報
コラム
Automotive SPICE プロビジョナルアセッサー資格更新要件の変更について
intacsから、プロビジョナルアセッサーの資格更新要件の変更についてアナウンスされています。従来、プロビジョナルアセッサーは、VDAに資格更新費用を払い込めば、資格の維持が可能でしたが、今後は 最低１つのType EE - AT（ = Assessment Team member Experience Evidence） が必要 になるようです。つまり、今後は3年毎に最低１回のアセスメントに参加することが資格更新の条件になってきます。まだ正式決定ではないようですが、Automotive SPICE Provisional Assessor 資格を保有されているかたは、ご注意ください。 弊社では、これまでも社内アセッサ育成プログラムをご提供しておりますので、こちらに参加することでEEの獲得が可能となります。社内アセッサ育成プログラムについては、弊社ホームページの導入事例をご参照ください。https://www.bgarage.co.jp/case/230/また、プロビジョナルアセッサー資格維持用のサービスも近々提供を予定しておりますので、ご興味のある方は弊社までお問合せください。 参考に、Type EE - ATの基準をintacs発行の「Concept Experience Evidence」から引用しておきます：ISO/IEC 33002に準拠したアセスメントのチームメンバとして活動することで、EE-ATを1つ獲得できる 50時間のアセスメント活動（準備、実行、報告を含む） リードアセッサーが、 対応するPAMのintacs™認定のコンピテントアセッサーまたはそれ以上（プリンシパル、インストラクタ）であること コアセッサーが、対応するPAMのintacs™認定のプロビジョナルアセッサーまたはそれ以上であること intacs™アセスメントログのテンプレートは最新版を使用し、全て記入すること アセスメントは、アセッサトレーニングコースで定義されたアセスメントプロセスに従って実施すること 関連する全てのBP、GP及びPAを、 N/P/L/F または N/P-/P+/L-/L+/Fで評価する アセスメント計画は、 ISO/IEC 33002（A-SPICEアセスメントの場合は、VDA Automotive SPICE® Guidelinesも含む）の要件に従って立案する アセスメント文書（評定及び、確証の指標とトレーサビリティの正当性を含むアセスメント記録）は、 ISO/IEC 33002に従って作成する アセスメントチームは、リードアセッサーと、最低1名～最大4名のコアセッサーで構成する備考: 認定には、全てのアセスメントにわたって、少なくとも3つのプロセスグループがアセスメント範囲に含まれる必要がある 1つのEE-ATのアセスメント時間は、複数のアセスメントにわたって合算することができる 50時間を超えるアセスメントは、複数のEE-ATにカウントすることができる intacs™アセスメントログのテンプレートには、4名のコアセッサーを列挙することができ、単一のアセスメントごとに、アセスメントチームメンバとしてのEE-ATを取得する資格があるとみなすことができる
コラム
Automotive SPICE 4.0における非機能要件の考え方
Automotive SPICE 4.0 に関するコラムの第２弾は、非機能要件とは？という話題でお届けいたします。 非機能要件については、そもそも非機能って何？どうのうに定義すれば良いの？と悩んできた方も多いと思います。私たちも、お客様から幾度となくご相談を受けてきました。Automotive SPICE Guidelines 2nd edition に記載されている説明を要約すると、Automotive SPICE4.0では、次のように解釈することがよさそうです。 ISO/IEC/IEEE 29148や他の世界標準を見ると、Quality(Non-Functional)Requirementsという記載になっていますので、非機能要件という言葉は将来的には使わなくなるかもしれません。Automotive SPICE Guideline 2nd editionでには、次のような説明もありますので参考にしてください。 「機能要件」、「非機能要件」という用語を明確に定義した標準は存在していないが、Automotive SPICEでは、以下の理由から２つの用語をあえて使用する： 開発担当者に、非機能という特性の重要性を知らしめるため アセッサーに、定義された要件に非機能に関する特性が定義されていない場合は、評価を落とすこと促すため 「機能要件」、「非機能要件」を要件種別として定義することは、適切ではない： BP2（SYS.2/SWE.1）：システム/ソフトウェア要件の構造化というプラクティスがあるが 要件の構造化は、機能や製品のバリアントなどでグルーピングするものである 機能要件の一部には、非機能要件の組み込まれて文書化されているのが一般的である このような特徴から、もし機能要件と非機能要件を要件種別として採用すると、同じ要件で複数の種別が存在してしまうことになってしまう。 今回のコラムはいかがでしたでしょうか？悩ましいトピックですが、皆様の疑問が少しでも解ければ嬉しいです。品質要件の定義方法も難しいトピックですので、次の機会にご紹介いたします。今後も数回にわたってAutomotive SPICE 4.0に関するコラムをお届けいたしますので、ご期待ください。 日吉昭彦
お知らせ
ホームページリニューアルのお知らせ
日頃より、ビジネスガレージ株式会社のホームページをご覧いただき、ありがとうございます。2023年1月25日より、ホームページのリニューアルを行いました。今回のリニューアルでは、情報閲覧の操作性を高めるとともに、プロセス改善の情報発信を目的とした機能も追加しております。皆様にとって、有益な情報を発信していきますので、引き続きご愛顧のほどよろしくお願いいたします。
コラム
Automotive SPICE 4.0における検証基準の考え方
皆様ご存じのように、Automotive SPICE4.0が2023.12にVDAから正式リリースされました。今回から数回に分けて、Automotive SPICE4.0で改版された主要なポイントについて記載いたします。初回は、「検証基準」の考え方について考察します。 検証基準については、その実装方法について困られていた方も多くいらっしゃると思います。アセスメントで検証基準が定義されていないという弱みを指摘され、検証基準という文書は作ってみたものの、ほとんど活用されていないという状況をよく見かけます。 アセッサーによっても見解に相違があり・検証基準という文書がないとダメ・検証可能な形式で要求仕様が書かれていればOKといった発言から、アセスメントで問題を指摘されないように「検証基準」を準備しておこうという状況が生まれていたと認識しています。 Automotive SPICE4.0では、Automotive SPICE 3.1で定義されていた「検証基準の作成」（SYS.2.BP5/SWE1.BP4）が削除されました。検証基準という言葉は、「要件の仕様化」（SYS.2.BP1/SWE.1.BP1/HWE.1.BP1）の備考に「検証可能性」を説明する例として唯一残っています。備考には、次のような説明が記載されています：・要求の持つべき特性は、ISO IEEE 29148, ISO/IEC IEEE 24765, ISO 26262-8, INCOSE Guide for Writing Requirementsに定義されている・定義された要求の持つべき特性とは、検証可能性（例：検証基準）、非曖昧性/わかりやすさ、設計を制限しないこと、他の要件と矛盾しないこと、など つまり、検証基準という文章そのものが必要なわけではなく、定義した要求仕様文書が検証可能な内容で書かれていることが重要ということなのです。要件を定義する際に従来から、EARS（Easy Approach to Requirements Syntax）や、要件定義用のボイラープレートを活用した構文形式で要求仕様を記述していた方々には、新たに検証基準という文章を作る必要はなかったわけです。 VDAガイドラインでは、Automotive SPICE4.0における変更の経緯を解説していますが、その概略をここに整理しておきます。 要求は検証可能な形で文書化されていなければならない これをアセスメントモデルとして強調するために、Automotve SPICE 3.1では「検証基準の作成」というBPを設けた しかしながら当初の思惑とは異なるPAMへの誤解が生じ、下記のような評定が行われる結果となった BP1（要件の仕様化） = F BP4（検証基準の作成）= N/P 検証可能な形で文書化されていない要求（BP4 = N/P）が、どうして要求全体（BP1 = F）と評定できてしまうのか？ 検証基準の作成というBPを定義したことが、要件とは別に文書化された情報が必要であると誤解された結果になってしまった Automotive SPICE Guidelines 1st edition では、「検証手法や検証手順、検証環境を特定するような検証基準を追加しても良い」と記載したが、これはあくまで「may」であって必須ではない 実際には、検証基準とは下記のように要件文書の中に（検証可能な形）で存在するものでり、下記のイタリックの部分が要求として検証可能な文書の例である ECUは、+0.2秒の許容範囲で1秒以内に100～110のバスメッセージを受信可能であること 更に詳細な記述が書かれていますので、原文を参照してください。この説明を読むと悲しくなりませんか？検証基準の作成という言葉だけに着目して無駄な作業をしてしまったという方も多くいらっしゃると思います。しかしながら、要求文書を見て設計者やテスト担当者が後戻りなく作業できることが本質であることは変わりません。 弊社では、要求定義に関するコンサルティングや文書作りのお手伝いもしておりますので、ご興味のある方は是非お問合せください。 日吉昭彦
お知らせ
年末年始休業のお知らせ
誠に勝手ながら、下記の期間を年末年始の休業とさせていただきます。お客様につきましてはご迷惑をおかけいたしますが、何卒ご理解いただきますようお願い申し上げます。 年末年始 休業期間：2023年12月29日（金）から2024年1月8日（月）まで 来年も弊社をご愛顧いただきますようお願いたします。
コラム
Automotive SPICE（プロセスアセスメントモデル）の功罪
Automotive SPICEを使われている方が多いと思いますが、活動は問題なく進んでいるでしょうか？Automotive SPICEをはじめとしてプロセスアセスメントモデルは、うまく活用できれば組織に大きな利益をもたらしますが、使い方の難しいモデルでもあります。 皆さん、下記の事例がいくつ当てはまるでしょうか？ アセスメントでドキュメントが無いと指摘され作ったが、誰も活用していないドキュメントができてしまっている 定義した組織（あるいはプロジェクト）のプロセスに、Automotive SPICEのプロセス名が使われている プロセス改善活動の目的がAutomotive SPICEの能力レベルになっている 組織のトップは、「レベルを取れ」とはいうが、日々の活動に関与してこない 改善活動に熟練者をアサインしてくれない プロセスは、Automotive SPICEで指摘されたことを取り組むだけで、生産性や品質の向上につながる活動は実施されていない 定義したプロセスは、Automotive SPICEプロセスと呼ばれ、Automotive SPICEを顧客が要求しているプロジェクトだけが、このプロセスを使用している アセスメントをするたびに、どんどんプロセスが重くなっている Automotive SPICEのBPをそのままプロセス定義している プロセスグループとプロジェクトグループとの関与がほとんどない ３つ該当すれば要注意、５つ以上該当する場合は重症だと思われますので、すぐに私たちにご連絡ください。きっとお役に立つアドバイスができると確信いたします。 プロセスアセスメントモデルと長く付き合ってきた我々の教訓をご紹介します。 従来の開発プロセスを尊重する 部門長、マネージャが率先して活動に取り組む 実現したいビジョンを確立して、計画およびリソースにコミットする Automotive SPICE（プロセスアセスメントモデル）の心を理解する 各プロセスの目的を理解する 誰が実施しても同じようにできるようにする プロセス間、能力レベル間のつながりを理解する 全プロジェクトとプロセスグループが協力しあう 継続できる改善施策を捻出する ツールを最大限活用する ただし、担当者にストレスを感じさせないツールとする 品質はただでは得られない 継続的なプロセス改善への投資を必要とするが、他の選択肢より安く済む 私たちは、開発の立場および品質保証部門などのスタッフの両方の立場で、開発活動とプロセス改善を両立してきました。成功体験もあれば、数多くの失敗も重ねてきました。アセスメントモデルは、アセスメントする側の観点で作成されていますので、「何ができているか？」ということをプラクティス（BP/GP）として定義したものであり、「どのように作業するか？」というものではありません。従って、アセスメントが終わって改善作業をする場合に、アセスメントモデルを参照するのではなく、作業の順番などを標準化してあるISO/IEEEなどの標準書を参考されると良いと思います。また、プロセスアセスメントモデルは欧米の慣習に基づいて作られており、日本独自の文化に合わせた対応をすることが重要です。 必ず私たちの経験が皆様の困りごとのお役に立てると信じています。お悩み事があれば、お気軽にお声がけください。 日吉昭彦
コラム
ソフトウェアドキュメント間のトレーサビリティについて
ソフトウェア開発で作成するドキュメント間のトレーサビリティについて悩まれている方が多いと思います。 本コラムでは、ソフトウェアで作成すべきドキュメントの構成を簡潔にまとめました。ソフトウェア開発現場では、日々エンジニアの方が多くの課題に立ち向かっています。 納期に追われ設計ドキュメントの作成が後回しになる 他のエンジニアが作成したソフトウェアを修正すると予想しない問題が発生する テストを十分したつはずなのに、顧客の受け入れ試験で多くの問題を指摘されるなどなど。まずは、ソフトウェア開発で文書を残しておく重要性を、簡単な図で理解していただきたいと思います。