Updates

新着情報

コラム

Automotive SPICE4.0における「戦略」の考え方

Automotive SPICE 4.0 に関するコラム、今回は「戦略」BPについてお届けいたします。 はじめにこれまでのAutomotive SPICE v3.1では例えば「SUP.8.BP1:構成管理戦略の策定」の様に、特にSUPプロセス群において、そのプロセスの戦略を策定することをBPで求めていました。また、その際の作業成果物特性として「08-04 構成管理計画書」の様なプロセス活動の計画書が定義されていました。そのため、「構成管理計画書」や「構成管理戦略」といった名前の文書を作らないとSUP.8.BP1は満足できないのでは?と考えて来た方も多かったと思います。でも、A-SPICEの能力レベル1は「実施されたプロセス」なので、本来は計画が無くてもそのBPの内容が実施されていればOKのはず。プロセスの実行計画は能力レベル2で出てくるじゃない。なんでレベル1で計画書が必要なの?といった疑問も出てきますよね。 A-SPICE 3.1の誤解とガイドラインの主張Automotive SPICE v3.1のガイドラインでは、「SUPプロセスはレベル1において、すべてのプロセスを横断するため高い度合の形式化を必要とする。でもレベル2を達成するにはレベル1の戦略を超えて達成することがまだ多くある。戦略は「戦略」と名の付く文書を必要とはしない」とあります。この考えはSUPプロセスに限らずSWE.4/SWE.5/SWE.6/SYS.4/SYS.5のテストプロセスでも同様で、テストを行うためのテスト戦略がBPで定義されていました。 つまり、BPの活動を効果的に実施してもらうためには場当たり的にやるのではなく、最初にプロジェクトとしてどうやるかを考えてからやってね、という意味合いで「戦略」が必要と定義したのですが、結果的にはBPに書いてあるから「戦略」や「計画書」が無くちゃいけない、に捉えられてしまい、アセスメントでも例えば構成管理活動がキチンと行われているにも関わらず、ただ一点、「構成管理計画書」が無いという理由でレベル1に課題があるといった評価になってしまう様な事態が発生していました。 A-SPICE 4.0では戦略が不要か?Automotive SPICE 4.0では、そんな「戦略」BPが引き起こしていた混乱や誤解を避けるために、「戦略」と名の付くBPが全て無くなりました。また、併せてこれまで「戦略」BPのあったプロセスで定義されていた「08-04 構成管理計画書」の様なプロセス活動の計画書の定義も削除となりました。これで、レベル1はあくまでBPの活動がちゃんと出来ているかに焦点が当たる様になり、アセスメントでも構成管理計画書が無いからダメといった、本来の意図では無い評価を防ぐことになります。 でも、BPの活動を効果的に実施するには、プロジェクトのメンバーが各自で好きな様に実施するより、プロジェクトとして最初にどうやるかをキチンと考えて、プロジェクトの皆でそのやり方を守って実施した方が良い結果に繋がりますよね。なので「戦略」BPは無くなりましたが、最初にちゃんと考えることが大切!って部分は変わらないのだと思います。 さいごに今回のコラムはいかがでしたでしょうか?今後も数回にわたってAutomotive SPICE 4.0に関するコラムをお届けいたしますので、ご期待ください。(安部宏典)

コラム

Automotive SPICE SYS.1 設計レベルの顧客要求がある時のシステム要求の作り方

今回はAutomotive SPICEの要求事項を満足するためのヒントとして、顧客要求の取り扱いについて説明いたします。特に自動車開発の場合、顧客の要求仕様に書かれている内容が、明らかにシステム要求レベルのものではなく、ソフトウェア要求(SWE.1)やハードウェア要求(HWE.1)レベルになっている場合や、設計上の制約(SWE.3:設計レベルの記述)となるレベルまで踏み込んで書かれているケースが多く見受けられます。このような詳細なレベルの要求の取り扱いに悩んでいませんか? 具体的な悩みとしては: 詳細な顧客要求を、システム要求仕様書(SYS.2)に、どのように落とし込めば良いのか? システム要求仕様書にソフトウェア要求やソフトウェア設計上の制約に相当するのものを記載した場合、ソフトウェア要求や設計書には、どのように記述すれば良いのか?(同じ文書を複数の文書にコピーするのか?) 顧客要求からシステム要求、ソフトウェア要求へのトレーサビリティは、どのように取るのか? 顧客要求が設計上の自由度が無いような詳細レベルの場合、システム要求仕様書にソフトウェア要求レベルや設計制約レベルの顧客要求を記述する必要はありません。顧客要求から、(システム要求をスキップして)ダイレクトにソフトウェア要求に組み込む、あるいは設計へのトレーサビリティを取れば良いのです。全ての顧客要求をシステム要求に組み込み、さらに同じ内容を後続の要求(例:ソフトウェア要求)にコピーするような無駄な作業をする必要はないのです。 ただし、1つだけ注意点があります。このように、システム要求をスキップして詳細レベルの書類に落とし込む場合、その要求や制約が、皆さんが開発するシステム要求やアーキテクチャレベルに影響がないことを評価した上で、判断することが重要です。詳細レベルの要求や設計制約と思える要求は、顧客の立場から主張する必要があるものであり、皆さんのシステム設計にはフィットしない場合もあるからです。その場合は、顧客と相談の上、詳細レベルの要求や設計制約を変更してもらう必要があります。 このような困りごとが多いことは、VDAも認識しているようで Automotive SPICE ガイドライン 改訂第2版のSYS.1に説明が記載されていますので参考にしてください。 Automotive SPICEを使っていると、「この作業無駄だなぁ」とか「非効率だ!」と思いながらも、Automotive SPICEの認証を受けるためには、仕方なく実施しているケースを数多く見ます。もし、「無駄」だと思った場合、あなたの感覚は正しく、それは無駄な作業なのだと思います。もう1歩踏み込んでAutomotive SPICEで記載している事項の本質的を考えてみることをお勧めします。きっと違う実装方法があるはずです。 とは言え、なかなか判断が難しいですよね。そのような時は、弊社までお問合せください。微力ながら皆様のお力になれることを願っています。 日吉昭彦

コラム

Automotive SPICE 4.0におけるSYS・HWE・MEEの適用範囲について

Automotive SPICE 4.0 に関するコラムの第3弾は、システム領域の適用範囲についてお届けいたします。 そもそもシステムとは?一言に「システム」といっても、人によってその定義や解釈は様々です。Automotive SPICEでは、システムを以下のように定義していました。※1 特定の環境内において、特定の機能または一連の機能を実現するために編成された相互作用のあるアイテムの集合。さらに、この相互作用のある「アイテム」を、Automotive SPICEでは、「識別可能なシステムの一部」とし、ハードウェアやソフトウェア、下位のシステムといった構成要素と位置付けていました。つまり、ハードウェアとソフトウェアを組み合わせたものをシステムとしています。しかし、この定義に準ずると、自動車もシステムであり、自動車を構成する駆動システムやECU、範囲を広がると車車間通信の仕組みも「システム」として解釈することができます。この解釈自体に間違いはありません。それでは、Automotive SPICEのシステムエンジニアリングプロセス(SYSプロセス)は、どんな製品を対象に、どのように適用すれば良いでしょうか? SYSプロセスの適用範囲Automotive SPICEは、様々な製品に対してアセスメントできるように考えられたプロセスモデルですので、製品の階層構造を表現したものにはなっていません。これは、ガイドラインでも明確に記述されています。しかし一方で、ガイドラインでは、「製品の階層構造の各レベルでシステムエンジニアリングプロセスを適用することができる」とも記述されています。少し具体的な例が掲載されているのでご紹介します。階層的なシステム開発の例: メカトロニクスシステムや駆動システムは、メカトロニクス製品であり、メカトロニクス製品を開発するサプライヤには、SYSプロセスが適用可能である ECUは制御デバイスであり、一般的にハードウェア、ソフトウェア、ケース、コネクタ等で構成されるため、ECUを開発するサプライヤには、SYSプロセスが適用可能である 完全に組み立てられたPCBを開発するサプライヤには、HWEプロセスを適用するべきである 半導体開発の例: マイコンやSoC等の半導体は、一般的にハードウェア、機械的な筐体、ファームウェア等で構成されるため、サプライヤには、SYSプロセスが適用可能である  さいごにいかがでしょうか?これらからもわかるように、ECUの開発だけでなく、複数のECUやセンサー、アクチュエータで構成される上位システムに対しても、SYSプロセスが適用可能であること、さらには、ECUの構成部品である半導体を開発する際にも、SYSプロセスが適用できることがわかると思います。皆さんが開発する製品の階層構造に合わせて、多段的にSYSプロセスを適用することを検討してみてください。内山哲三 ※1:Automotive SPICE  3.1における定義です。Automotive SPICE 4.0で明示的な定義がなくなりました。また国際標準である、ISO/IEC 26702 IEEE Std 1220-2005では、製品(ハードウェア+ソフトウェア)だけでなく、製品と使用する人や、使用する際に利用する設備や機材、手順もシステムの一部としていますが、今回はAutomotive SPICEでの定義を活用して、わかりやすく解説しています。

コラム

Automotive SPICE プロビジョナルアセッサー資格更新要件の変更について

intacsから、プロビジョナルアセッサーの資格更新要件の変更についてアナウンスされています。従来、プロビジョナルアセッサーは、VDAに資格更新費用を払い込めば、資格の維持が可能でしたが、今後は 最低1つのType EE - AT( = Assessment Team member Experience Evidence) が必要 になるようです。つまり、今後は3年毎に最低1回のアセスメントに参加することが資格更新の条件になってきます。まだ正式決定ではないようですが、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 に関するコラムの第2弾は、非機能要件とは?という話題でお届けいたします。 非機能要件については、そもそも非機能って何?どうのうに定義すれば良いの?と悩んできた方も多いと思います。私たちも、お客様から幾度となくご相談を受けてきました。Automotive SPICE Guidelines 2nd edition に記載されている説明を要約すると、Automotive SPICE4.0では、次のように解釈することがよさそうです。  ISO/IEC/IEEE 29148や他の世界標準を見ると、Quality(Non-Functional)Requirementsという記載になっていますので、非機能要件という言葉は将来的には使わなくなるかもしれません。Automotive SPICE Guideline 2nd editionでには、次のような説明もありますので参考にしてください。 「機能要件」、「非機能要件」という用語を明確に定義した標準は存在していないが、Automotive SPICEでは、以下の理由から2つの用語をあえて使用する: 開発担当者に、非機能という特性の重要性を知らしめるため アセッサーに、定義された要件に非機能に関する特性が定義されていない場合は、評価を落とすこと促すため 「機能要件」、「非機能要件」を要件種別として定義することは、適切ではない: BP2(SYS.2/SWE.1):システム/ソフトウェア要件の構造化というプラクティスがあるが 要件の構造化は、機能や製品のバリアントなどでグルーピングするものである 機能要件の一部には、非機能要件の組み込まれて文書化されているのが一般的である このような特徴から、もし機能要件と非機能要件を要件種別として採用すると、同じ要件で複数の種別が存在してしまうことになってしまう。 今回のコラムはいかがでしたでしょうか?悩ましいトピックですが、皆様の疑問が少しでも解ければ嬉しいです。品質要件の定義方法も難しいトピックですので、次の機会にご紹介いたします。今後も数回にわたってAutomotive SPICE 4.0に関するコラムをお届けいたしますので、ご期待ください。 日吉昭彦

コラム

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のバスメッセージを受信可能であること 更に詳細な記述が書かれていますので、原文を参照してください。この説明を読むと悲しくなりませんか?検証基準の作成という言葉だけに着目して無駄な作業をしてしまったという方も多くいらっしゃると思います。しかしながら、要求文書を見て設計者やテスト担当者が後戻りなく作業できることが本質であることは変わりません。 弊社では、要求定義に関するコンサルティングや文書作りのお手伝いもしておりますので、ご興味のある方は是非お問合せください。 日吉昭彦

コラム

Automotive SPICE(プロセスアセスメントモデル)の功罪

Automotive SPICEを使われている方が多いと思いますが、活動は問題なく進んでいるでしょうか?Automotive SPICEをはじめとしてプロセスアセスメントモデルは、うまく活用できれば組織に大きな利益をもたらしますが、使い方の難しいモデルでもあります。 皆さん、下記の事例がいくつ当てはまるでしょうか? アセスメントでドキュメントが無いと指摘され作ったが、誰も活用していないドキュメントができてしまっている 定義した組織(あるいはプロジェクト)のプロセスに、Automotive SPICEのプロセス名が使われている プロセス改善活動の目的がAutomotive SPICEの能力レベルになっている 組織のトップは、「レベルを取れ」とはいうが、日々の活動に関与してこない 改善活動に熟練者をアサインしてくれない プロセスは、Automotive SPICEで指摘されたことを取り組むだけで、生産性や品質の向上につながる活動は実施されていない 定義したプロセスは、Automotive SPICEプロセスと呼ばれ、Automotive SPICEを顧客が要求しているプロジェクトだけが、このプロセスを使用している アセスメントをするたびに、どんどんプロセスが重くなっている Automotive SPICEのBPをそのままプロセス定義している プロセスグループとプロジェクトグループとの関与がほとんどない 3つ該当すれば要注意、5つ以上該当する場合は重症だと思われますので、すぐに私たちにご連絡ください。きっとお役に立つアドバイスができると確信いたします。 プロセスアセスメントモデルと長く付き合ってきた我々の教訓をご紹介します。 従来の開発プロセスを尊重する 部門長、マネージャが率先して活動に取り組む 実現したいビジョンを確立して、計画およびリソースにコミットする Automotive SPICE(プロセスアセスメントモデル)の心を理解する 各プロセスの目的を理解する 誰が実施しても同じようにできるようにする プロセス間、能力レベル間のつながりを理解する 全プロジェクトとプロセスグループが協力しあう 継続できる改善施策を捻出する ツールを最大限活用する ただし、担当者にストレスを感じさせないツールとする 品質はただでは得られない 継続的なプロセス改善への投資を必要とするが、他の選択肢より安く済む 私たちは、開発の立場および品質保証部門などのスタッフの両方の立場で、開発活動とプロセス改善を両立してきました。成功体験もあれば、数多くの失敗も重ねてきました。アセスメントモデルは、アセスメントする側の観点で作成されていますので、「何ができているか?」ということをプラクティス(BP/GP)として定義したものであり、「どのように作業するか?」というものではありません。従って、アセスメントが終わって改善作業をする場合に、アセスメントモデルを参照するのではなく、作業の順番などを標準化してあるISO/IEEEなどの標準書を参考されると良いと思います。また、プロセスアセスメントモデルは欧米の慣習に基づいて作られており、日本独自の文化に合わせた対応をすることが重要です。 必ず私たちの経験が皆様の困りごとのお役に立てると信じています。お悩み事があれば、お気軽にお声がけください。 日吉昭彦

コラム

ソフトウェアドキュメント間のトレーサビリティについて

ソフトウェア開発で作成するドキュメント間のトレーサビリティについて悩まれている方が多いと思います。 本コラムでは、ソフトウェアで作成すべきドキュメントの構成を簡潔にまとめました。ソフトウェア開発現場では、日々エンジニアの方が多くの課題に立ち向かっています。 納期に追われ設計ドキュメントの作成が後回しになる 他のエンジニアが作成したソフトウェアを修正すると予想しない問題が発生する テストを十分したつはずなのに、顧客の受け入れ試験で多くの問題を指摘されるなどなど。まずは、ソフトウェア開発で文書を残しておく重要性を、簡単な図で理解していただきたいと思います。