新着情報

コラム

2025.01.22

RPAツールを使って業務効率化しよう！

弊社では2024年4月よりロボットプロセス技術部を新設し、RPA（Robotic Process Automation）を使いお客様の業務効率化の支援をさせていただいております。今回は、RPAとはどういったものか、どういう効果があるのか、といったお話をしたいと思います。RPAとは何か？RPAは、人間が行っている定型業務のタスクを自動化する技術です。これにより、企業は生産性を向上させ、エラーを減らし、従業員がより価値の高い業務に集中できるようになります。RPAはソフトウェア「ロボット」を使用して、データ入力、トランザクション処理、レポート作成などのタスクを自動化します。主にバックオフィス業務の自動化に活用されることが多く、生産性の向上や人材不足の解消に向けて導入する企業が増加しています。 RPAの導入メリットRPAツールの導入には以下のようなメリットがあります。・業務効率化とコスト削減・ミス防止や業務品質の均一化を実現・企業全体の生産性向上・従業員のモチベーション向上・労働環境の改善・業務スピードの向上により顧客満足度が向上 RPAツールを導入しやすい業務の例以下にRPAツールを導入して効果が得られやすい業務をあげてみました。・手順の決まっている定型業務・大量のデータを扱う業務・アプリケーションを横断する業務 導入のステップRPAツールの導入は手順に沿って進めるとよいでしょう。以下、一般的な導入手順をご紹介いたします。1. 社内の業務を可視化する2. RPA化できそうな業務をピックアップする3. RPAツールの導入目標を立てる4. 業務内容に合ったRPAツールを選定する5. 気になるRPAツールを無料トライアルで試す6. 簡単な業務から小規模でRPA化していく7. 改善事例を横展開してRPAを本格導入する8. RPAの効果測定をする9. RPAの運用と保守を継続して行う RPA導入の成功のポイントは、まず自身の業務を可視化することです。その中に必ず定型業務があるはずです。RPAツールは種類がいくつもあり、業務によって向き不向きがあります。まずは、Windows11に標準で搭載されているPAD（Power Automate Desktop）を使って自らの業務を効率化するところから始めてみてはいかがでしょうか。園田幸治

コラム

2025.01.20

Automotive SPICE GP 徹底解説 その２ ～ GP2.1.3（責任と権限）

今回は、GP 徹底解説の第２段として、「責任と権限」についてお届けいたします。実は、この「責任と権限」に関するプラクティスは、Automotive SPICE 3.1 と4.0で GP の番号や記述内容が多少変わっています。アセスメントを実施していると、特に「権限」に関する考え方や、インタビューにおける受け答えが適切にできていないことが多い領域です。 当初、責任と権限に焦点を当ててコラムを書く予定でしたが、Automotive SPICE 4.0 で多少ニュアンスが変わっているようなので、まずは v3.1 と v4.0での記述の差分を確認してみることにします。   GP のタイトルは変わっているものの、「責任と権限」については意図の変更はありません。v4.0 では、プロセスの実行に関与する「人」だけでなく、「物理的・物質的」なリソースも含めてプロセスを実施するために必要な「リソース」に拡張されました。人的リソースに関しては、備考６にあるように「責任と権限」の定義については必ずしも正式な記述である必要はなく、決定されていれば良いと読み取れます。 人的リソースに課せられる要件；本コラムでは、「人的リソース」に焦点をあてて、何を決定しておけば良いかを考察していきます。ここで重要なのは、能力レベル２で求められる「繰り返し同様の成果を出す」ために必要なことは何かということです。つまり、人が作業を遂行するにあたり（同様の成果を確保するために）必要なことを決めておくこということになります。 その作業を実施するために必要な「経験」・「知識」・「スキル」 その作業に関する「責任」と「権限」 その作業を実施した際に作成される作業成果物を管理するたの「責任」と「権限」これらが、より良い作業成果を発揮するためには、重要な要素だと考えられています。 では、責任と権限では何が異なるのでしょうか？意外と説明しにくいのではないでしょうか？ 責任と権限の違いとは？以下のように整理するとわかりやすいと思います。（権限とは） 意思決定を行い、命令を下す（権力・権利） 権限は委譲できる 職制や組織構造に基づいて付与される 意思決定の結果について責任を負う （責任とは） タスクや職務を遂行し、その結果について責任を負う（義務） 責任は委譲できず、責任を負う個人にある 割り当てられた仕事や役割に付与される 割り当てられた仕事を成功裏に完了する責任を負う 責任は、プロセスとして考える！プロセス定義の観点からは、責任は（そのタスクを実施する）役割（ロール）に基づいて定義することが一般的です。  しかしながら日本においては、タスクをこなす役割というより、組織の職制の観点から実施できる範囲を定義していることが多いようです。今後、作業をプロセスという側面から定義していくことを考えると、タスクごとに「役割」を定義していくことは有意義だと思われます。   権限は、職制に基づいて定義する！一方で、「権限」については職位毎に定義した方が現実的ではないでしょうか？もし、部門規定などで既に定義されていれば、それを参照すれば良いでしょう。   日本と欧米の文化や習慣の違いを理解することが重要！役割と権限は、日本と欧米の仕事の仕方の違いを色濃く反映しているものだと理解しています。日本では、役割、責任、権限、スキルは組織論として取り上げられており、これらは職制に紐づいていることが多いのです。一方、欧米ではプロセスや Job Description の中で明確に文書化されています。 日本にある外資系企業で、コピーした際に用紙がなくなったので用紙を補充したら、「それはあたなたの役割ではなく私の作業だ！」と怒られた、という話を聞いたことがあります。文化的な違いは、プロジェクト発足時のプロセスにも表れています。日本ではプロジェクトは組織に紐づいていることが多く、新しいプロジェクトが発生した場合、その組織の中でメンバーを構築していきます。欧米では、プロジェクト発足時にプロジェクトマネージャが選任され、予算と権限が与えられます。マネージャは、プロジェクトに必要な技術やスキル要件を予算内で整理して、必要な人材を組織のヒューマンリソースグループに依頼し、プロジェクトメンバーを獲得していくのです。 欧米発の Automotive SPICE を上手く活用していくためには、日本文化における違いを明確にして、その違いに応じた対応をしていく必要があります。問題がなければ必ずしも Automotive SPICE の記述通りに現状の方法を変える必要はありません。ただし、相違点を明確にして自分達のプロセスで問題がないことをアセッサーに正しく伝えることが重要となります。日吉昭彦

コラム

2024.12.17

見えない相互作用を探る　～　システムコンテキストへの影響分析　～

Automotive SPICE 4.0 に関するコラム、今回は「システムコンテキスト」についてお届けいたします。 はじめに Automotive SPICE 4.0 でのシステム要求分析（SYS.2）プロセスにおけるポイントの一つとして、「システムコンテキスト」があります。その内容とシステムコンテキストへの影響を分析することの重要性について探ります。 Automotive 4.0におけるシステムコンテキスト システムコンテキストとは、検討中のシステムの「境界」を越えた外部のものを指す技術用語です。これが、システムコンテキストのイメージ図になりますが、システムの境界を越えた、システムとの相互作用、システムとの直接的または間接的なインタフェースをもつものがシステムコンテキストとなります。この図では、中央に示されたシステムと外部要素（ユーザー、規制、ハードウェアシステムなど）の相互作用が可視化されています。それぞれの要素がシステムに与える影響や、システムがそれらに与える影響を考慮することが重要です。 （V3.1）BP4：運用環境における影響の分析・ 運用環境における明記したシステムと他のエレメントとの間のインタフェースを識別する・ システム要件がこれらのインタフェースおよび運用環境に及ぼす影響を分析する （V4.0）BP4：システムコンテキストへの影響の分析・ システム要求が関連するシステムコンテキストのエレメントに与える影響を分析する V3.1では、BP4：運用環境における影響の分析、というのがシステムコンテキストを指していました。これがV4.0では、「システムコンテキストへの影響の分析」となり、V3.1よりも、「システムコンテキストのエレメントに、与える影響」を分析する、つまり、外部に与える影響を分析、というのをより明確にした表現になっています。例えば、車載電動モーターシステムのシステムコンテキストでは、車両のバッテリーシステム、制御ユニット、冷却システム等との相互作用が重要となります。 システムコンテキストに与える影響 では、具体的に、外部に対してどのような影響があるかというと、VDAガイドラインでは、次のような影響が考えられる、とあります。ユーザへの影響としては、HMI としてストレス、不快感や疲労など。他のメカトロニクスシステムへの影響としては、振動、音響、静電気、摩耗部品の断片など。他のコントロールデバイスへの影響としては、信号の品質、設計された取り付けスペースと矛盾するサイズなど、があります。そして、このような影響は、それぞれのエレメントの所有者にインプットする必要があります。 システムコンテキストはなぜ重要か システムコンテキストへの影響を分析する際は、まずシステム境界を明確にし、次に外部要素を洗い出し、各要素がシステムに与える影響（またはその逆）を定量的・定性的に評価します。その結果をもとに、システム要件の調整を行います。このシステムコンテキストの特定と、その影響分析が十分でないと、次のようなリスクが高くなります。・システム境界や相互作用の漏れによる問題発生リスク・設計段階での不具合検出遅延・修正コスト増大の可能性 そのため、この影響分析結果は、それぞれのエレメントの所有者にインプットする必要があります。その結果、その外部エレメントへの影響を考慮した場合に、システム要求そのものを変更する必要が出てくることもあるでしょう。例えば、電動モーターシステムの動作温度が、冷却システムの能力を超える熱を発生させる場合があると、モーター設計の発熱制限要件を見直し、冷却システムへの過剰な負荷を防ぐように調整する必要があります。 システムコンテキストの特定と影響分析の重要性は理解いただけたでしょうか？みなさんは、自分たちのプロジェクトでシステムコンテキストをどのように定義していますか？ おわりに 今回のコラムはいかがでしたでしょうか？今後も数回にわたってAutomotive SPICE 4.0に関するコラムをお届けいたしますので、ご期待ください。（安部宏典）

コラム

2024.11.30

SYS.3 のアーキテクチャ設計に関する Automotive SPICE v4.0 での主要変更点について

Automotive SPICE v4.0 のシステムアーキテクチャ設計プロセス（SYS.3 ）に関して、Automotive SPICE v3.1 から SYS.3 の BP 構成やアウトプット成果物のイメージが変更されたので、その変化点について解説します。１．SYS.3 の基本プラクティス（BP）について Automotive SPICE v3.1 の SYS.3 のシステムアーキテクチャ作成に関する BP は以下の４個で構成されていました。BP1：システムアーキテクチャ設計書の作成BP2：システム要件の割り当てBP3：システムエレメントのインタフェースの定義BP4：動的な振る舞いの記述 ここでは BP1 がアーキテクチャ全体について記述している一方で、BP2、BP3、BP4 はアーキテクチャの側面を記述しています。 これによって、例えば BP1 が達成と評価されたにももかかわらず BP3 が未達成と評価された場合、BP1 達成と矛盾するため、混乱を招く恐れがありました。 上記混乱を防止するため、Automotive SPICE v4.0 のシステムアーキテクチャ作成に関する BP は２個に集約されました。BP1：システムアーキテクチャの静的な側面の仕様化BP2：システムアーキテクチャの動的な側面の仕様化２．SYS.3 の作業成果物（Automotuve SPICE v3.1）と情報項目（Automotive SPICE v4.0）について Automotive SPICE v3.1 ではエンジニアリング領域は SYS と SWE だけでしたので、システムアーキテクチャ設計のアウトプットである「作業成果物（04-06：システムアーキテクチャ設計書）」はシステムとソフトウェアを中心に記述されていました。 参考までに、Automotive SPICE v3.1 の作業成果物特性（04-06：システムアーキテクチャ設計書、17-08 インタフェース要件仕様書）を記載しておきます。 一方、Automotive SPICE v.4.0 では、エンジニアリング領域が SYS、SWE、HWE、MLE に拡張されたため、システムアーキテクチャ設計のアウトプットも、ハードウェアに関する、電気的、機械的（メカニカル）インタフェースの項目が追加されました。 参考までに、Automotive SPICE v4.0 の情報項目特性（04-06：システムアーキテクチャ）を記載します。 作業成果物と情報項目の違いについては、別コラムを参照して下さい 情報項目（04-06：システムアーキテクチャ）に基づいて、SWE 領域では情報項目（04-04：ソフトウェアアーキテクチャ）に、HWE 領域では情報項目（04-52：ハードウェアアーキテクチャ）に各々ブレークダウンして記載されています。 Automotive SPICE v3.1 の作業成果物であるインタフェース要件仕様書の作業成果物特性は、Automotive SPICE v4.0 ではシステムアーキテクチャの情報項目に記載されました。 MLE 領域に関するアーキテクチャは、Automotive SPICE v.4.0 では情報項目（04-51：ML アーキテクチャ）で追加されましたが、ML アーキテクチャはソフトウェアアーキテクチャのサブセットであるため、情報項目（04-06：システムアーキテクチャ）には記載されていません。Automotive SPICE v4.0 ではアーキテクチャに関する基本プラクティスが集約されたことでシンプル化され、理解し易くなったと思います。また、HWE 追加に伴ってシステムアーキテクチャの情報項目にハードウェアに関する項目が詳細に記載されたことで、SYS から SWE と HWE へとアーキテクチャ設計をブレークダウンする際に、これらの情報項目の記述内容はガイドラインとして活用できると思います。ご不明な点等あれば、弊社までお問合せください。 海農公宏

コラム

2024.10.25

HWE（ハードウェアエンジニアリング）とメカニカルの境目について

ハードウェアとは？一般的な「ハードウェア」とは、本来金物類全般を示す英語だと思います。コンピューターなどの世界では、プログラム群をソフトウェアと呼んでいることに対して、コンピューターの機械設備をハードウェアと呼ぶ呼称が定着しているのかと思います。よって、HWE（ハードウェアエンジニアリング）と聞いた時に、ハードウェアの何を対象としたものだろうか？メカニカルは含まれるのか？と疑問に思われる方もいるのではないでしょうか。 HWE（ハードウェアエンジニアリング）の範囲とは？Automotive SPICEでは、HWEプロセスの技術範囲を「電気又は電子のハードウェアエンジニアリング」と定義していて、以下は除外するとガイドラインには記載されています。 システムレベルのエンジニアリング、すなわち、メカトロニクスレベルでもなく、ECUレベルでもない。※1 用語集の「ハードウェア」の提供も参照 調達 ※2 メカニカル又はハードウェアのサンプル製造 生産プロセスまた、別のコラムにも記載していますが、システムの範囲に関して、「階層的なシステム開発の例」として以下の記載があり、Housing（ハウジング）は、HWEには含まれていません。 ECUは制御デバイスであり、一般的にハードウェア、ソフトウェア、ケース、コネクタ等で構成されるため、ECUを開発するサプライヤには、SYSプロセスが適用可能である 完全に組み立てられたPCBを開発するサプライヤには、HWEプロセスを適用すべきである上記から、Hosingのケース（筐体）やコネクタの外観形状などは、HWEではなく、機械（メカニカル）設計の中の構造（筐体）設計に含まれるものと考え、上図の「Mechanical」は機械設計の中の機構設計になるものと考えています。 ※1：PAMの「1.2 用語」には、以下の記載があります。ハードウェア：アナログまたはデジタルの機能または操作を実行する、組み立てられ相互接続された電気的または電子的なハードウェアのコンポーネントまたは部品。※2：「調達」をHWEの対象外としている理由は以下の２点だとガイドラインに定義されています。・ハードウェア開発は要求主導型でもある。したがって、重要なのはHW又は機械部品がどのようなソースから入手されたかは関係ないため・調達に関して、予め定義された規格にはIATF16949があるため調達に対する「プロセスインターフェース」はHWE.2におけるBP「ハードウェア詳細設計の仕様化」の備考3を参考にして下さい。 良くある質問以下のような質問を受けることがあります。 ノイズ対策のためのシールド構造の部品は、HWEの対象になるのか Housing（ハウジング）に、コネクタ部品は対象になるのか。その場合、HWEの対象外になるのか このような質問に対しては「電気又は電子」に関わるものは、HWEの中で関与すべきと回答しています。例えば、電子ノイズシールド特性を持つ構造部品について、機械設計側では構造面（空間的な構造設計）は責任は持てますが、その部品の材質等までは判断が難しい場合があると思います。電子ノイズなどの電気又は電子に関わる外的影響要因に対する設計要求に関しては、電気電子設計担当から、機械設計担当へノイズシールドの必要性や材質等の要求を伝えることが必要だと思います。また、コネクタ部品に関しては、構造的な外観形状はHWEには入りませんが、電気的な特性の要素も含まれるため、電気電子設計側で、製品化されている既存部品などから選定し、構造的な外観形状情報を機械設定担当へ伝えて、構造的に許容されるか検討する進め方になっているのではないでしょうか。もしくは、逆に機構的な設計制約が強い場合は、外観形状を先に決定した上で、コネクタ部品を新たにカスタム設計することも必要な場合もあるかと思います。このようなハードウェアに対する影響分析の実施はHWE.1 BP4（運用環境への影響分析）に、影響を受ける関係者に伝達することはHWE.1 BP6（合意されたハードウェア要求および運用環境への影響の伝達）に記載されていると思いますので、単純に縦割りに分担するのではなく、互いに共有すべき情報を伝達し合いながら設計を進めることが重要なのかと思います。 さいごにいかがでしょうか。ハードウェアエンジニアリング（HWE）とメカニカルの境界に関して、判断に悩む部分があるかと思います。「電気又は電子」と「機械（構造）的」な両面を持つコネクタやケーブルなどの部品に関しては、それぞれの設計担当者間にて、協力し合い、Automotive SPICEでは対象外となっている生産、製造プロセスを考慮した分担にするなど、皆さんが開発する製品開発の現場に合った方法を検討されてみてはいかがでしょうか。鈴木 功

コラム

2024.10.17

Automotive SPICE GP 徹底解説 その1 ～ GP2.1.1

今回から数回にわたって、Automotive SPICEに定義されている General Practice（以下GPと記載） について書いてみます。皆様ご存じのように、Automotive SPICE のGPは、各プロセスに展開されるため日本語では「共通プラクティス」として翻訳されています。この共通プラクティス、わかるようでわからない。特に実際の作業になると、なかなか腹落ちしないと思われている方も多いのではないでしょうか？私は、その理由は次のような背景があると考えています。  各プロセスに展開できるように、プラクティスの文言を汎用的に記述している 管理に関するプラクティスにおいては、日本と欧米の文化の差が顕著に表れている この辺りを念頭におきながら、 第１弾としてGP2.1.1 についてお届けいたします。日本語の原文は、次のように書かれています：   まず、解釈が難しいのは「プロセス実施目標」ではないでしょうか？ プロジェクト作業をしている人にとって「プロセスの実施に対する」と言われた瞬間「何を言っているんだ？」となる方が多いと思います。更に、備考１では、予算目標や顧客納入日がプロセス実施目標の例として取り上げられています。各プロセスに対して実施目標を設定すると書かれているにもかかわらず、予算や納入となるとプロジェクト全体のことのように思えます。私も長い間上手い説明ができずに困っていたことがありました。それが、ひょんなことから自分たちが実践してきた作業に当てはめてみたら、解釈の仕方が見えてきたのです。最近は、下記のような流れで説明をしています。  プロジェクト計画立案時に、プロジェクト全体の目標を設定する例）生産性を前プロジェクトから10%向上する プロジェクト目標を達成するための中間目標を検討する例）設計への後戻りが多い傾向にあるため、設計手法を変更して後戻りを20%削減する例）ビルドエラーが多く結合開始が遅れるため、各モジュールのリリース状況の監視を強化し初期ビルド作業の期間を１週以内とするなど、中間目標を設定することにより、プロジェクト全体目標を達成するための論理的な裏付けをプロジェクト計画時点で明確にするという流れです。参考事例も記載しておきます。   いかがでしょうか？「私たちの事例」では GP2.1.1に書かれている文章を直接表現して言いませんが、各作業で実施すべき指標が明確になっていると思います一方、「良くある事例」では GP2.1.1で書かれていることを直接表現しており、一見良い方法に見えますが、この方法でQCD実績やプロジェクト目標に貢献できるでしょうか？ プロセス個別の目標としては良くても、プロセスが線でつながっていないため、プロジェクト全体の効果が予測できません このようにプロセスを断片的にとらえても、良い目標が浮かばないと思います Automotive SPICE は、「私たちの事例」でご紹介したような、各企業のノウハウを汎用的に、かつアセスメントで評価しやすいようにまとめたものです。しかしながら、Automotive SPICEのGPの表現からは、事例のような作業が想像しにくいものになってしまっているのです。 このような事例を見れば、皆さんのプロジェクトでも同様なことを実施していると思います。だだ、この流れだと全てのプロセスに目標が設定できないじゃないか！と言われる方が出てくると思います。上記のように重点的に目標設定して活動する作業と、単純に各プロセスの完了予定日や投入予定工数を計画しておけば、一通りのプロセスに目標が設定できているはずです。特に難しく特殊な事例ではないと思います。Automotive SPICE のプラクティスに書かれている文言にとらわれることなく、プロジェクトとして当たり前のことを実施すれば良いだけなのです。プロセスアセスメントモデルは、アセスメント時に評価しやすい項目として構成されていますが、世の中の開発・管理の流れから外れたものが書かれているわけではありません。自分たちが実施している作業になぞって解釈を考えてみることをお勧めします。アセスメントのためだけに無駄な作業をしても全く意味がありません。少しでも疑問がわいた場合は、このようなアプローチをすることで、解決策が見いだせるはずです。日吉 昭彦

コラム

2024.09.20

Automotive 4.0のVAL.1プロセス：検証との違いとその重要性

Automotive SPICE 4.0 に関するコラム、今回は「妥当性確認」プロセスについてお届けいたします。 はじめに Automotive 4.0では新たにVAL.1（妥当性確認）プロセスが追加されました。これまでのV3.1では「検証」が中心でしたが、なぜV4.0で妥当性確認プロセスが追加されたのか、その背景と共にVAL.1プロセスの意義を探ります。 Automotive 4.0のVAL.1プロセス 4.0で新設されたVAL.1プロセスは、エンドユーザとの直接のやり取りを可能にする最終製品が、その運用対象環境において意図した使用上の期待を満足しているという証拠を提供することを目的としています。基本プラクティスは5つ。BP1：製品の妥当性を確認するための妥当性確認手段の仕様化BP2：妥当性確認手段の選定BP3：妥当性確認の実施および結果の評価BP4：一貫性の確保および双方向性トレーサビリティの確立BP5：結果の要約および伝達 SWE.6（ソフトウェア検証）やSYS.5（システム検証）といった「検証」プロセスと比べてみると、「検証」という用語が「妥当性確認」に変わっただけで後はほぼ同じだということが分かります。ではそもそも「検証」と「妥当性確認」の違いとは何なのでしょう。 検証と妥当性確認の違い 検証（Verification）とは、システムや製品が設計仕様を正確に満たしているかを確認するプロセスです。検証は、各開発段階で仕様通りに設計されているか、ソフトやシステムが設計通りに動作するかをチェックします。一方、妥当性確認（Validation）は、前述の通り、システムや製品が実際の使用環境下でユーザーの期待に応えているかを確認するプロセスです。具体的には、システムが設計の意図通りに現実の条件で機能するかを確認します。 例えば、自動運転車の開発において、検証プロセスでは、車両のセンサーが適切に動作し、設計されたアルゴリズム通りに動作しているかを確認します。しかし、VAL.1プロセスでは、実際の道路環境やさまざまな天候条件下で、センサーがどれだけ正確に機能し、システム全体が意図通りに動作するかを確認します。このように、検証は「設計仕様通りに動くか」に焦点を当て、妥当性確認は「実際に期待通りに動くか」に焦点を当てている点が異なります。 なぜV4.0まで妥当性確認プロセスが無かったのか V3.1までの開発プロセスにおいて、妥当性確認プロセスが明確に定義されていなかった理由はいくつかあると考えます。まず、技術的背景です。従来の自動車システムは、比較的シンプルな構造を持ち、個々の部品やシステムが設計通りに動作するかを確認する検証プロセスだけで、十分な品質と安全性を確保できると考えられていました。しかし、自動運転技術などの様々な技術の進化とともに、自動車のシステムがより複雑化し、相互に依存する要素が増えたことにより、設計通りに動くことの他に、様々な条件下でシステムや製品がユーザーの期待に応えるかを探索的に確認することも必要となりました。 次に、ユーザー中心の設計が強調されるようになったことも一因と考えられます。V3.1までのプロセスでは、技術的な仕様に焦点が当てられていましたが、V4.0では、ユーザー体験や実際の使用環境がより重視されるようになり、システムや製品が現実の使用条件下で快適に動作するかを確認する妥当性確認作業の必要性が高まりました。こうした理由により、これまでの検証活動とは別に妥当性確認が重要視され、V4.0でVAL.1プロセスが組み込まれることになったのだと思います。 なぜVAL.1は独立した妥当性確認プロセス群として位置づけられているのか V4.0では、VAL.1が独立したプロセスとして強調されています。その理由は、妥当性確認がエンドユーザーの期待に応えるかどうかをシステム全体の視点で確認する必要があるからです。SYS.5のような検証プロセスは要件通り・設計通りの動作を確認しますが、VAL.1は開発のすべての局面で、実際の運用環境下でシステムがユーザーのニーズに応えるかどうかを評価することが求められます。 例えばソフトウェア開発においては、動作検証だけではなく、モデリングとシュミレーション、プロトタイピング、レビュー等の手法により、要求や設計段階において、実際の使用環境で意図通りに動作するかを評価します。ハードウェア開発においても同様に、熱、振動・衝撃、電気的変動がハードウェアに与える影響を設計段階でシュミレーションする、設計段階での簡易プロトタイピング、レビュー等の手法により、全ての開発段階で、運用条件における信頼性や耐久性を評価します。このように、早期開発段階からの妥当性確認は、後の開発段階での手戻りを減らし、ユーザーの期待に応える製品を効率よく作り上げるために重要です。 ソフトウェア単体、ECU単体の開発ではVAL.1プロセスは関係ない？ VDAガイドラインによれば、VAL.1プロセスはエンドユーザーと直接関係するシステムや製品が対象であり、純粋な組込みソフトウェアやECU単体、モーターとECUの駆動システムなどは対象外とされています。これは、エンドユーザー視点での妥当性確認を重視しているためです。しかし、ECUやソフトウェア単体も、システム全体の一部として運用条件下での技術的な妥当性確認が必要です。例えば、温度範囲や電力供給の変動に対して適切に動作するかどうかの評価は、技術的な観点での妥当性確認に該当します。エンドユーザーとの直接の関わりはなくとも、システム全体の妥当性確認には重要な要素です。 技術の進化に伴い、自動車システムが複雑化し、ユーザーの期待が高まる中で、VAL.1プロセスの役割は今後さらに重要になっていくでしょう。 さいごに 今回のコラムはいかがでしたでしょうか？今後も数回にわたってAutomotive SPICE 4.0に関するコラムをお届けいたしますので、ご期待ください。（安部宏典）

コラム

2024.08.25

作業成果物と情報項目　Automotive SPICE 4.0のアセスメント指標の変化

Automotive SPICE V4.0に更新され、アセスメント指標が変更されたことをご存知ですか？今回のAutomotive SPICEV4.0に関するコラムは、アセスメント指標についてお届けします。  アセスメント指標とはプロセスアセスメントの関する国際規格の1つである、ISO/IEC 33004では、プロセスアセスメントモデルは、能力レベルを評価するために、アセッサの判断の拠り所として「アセスメント指標」を定義することを要求しています。プロセス成果やプロセス属性達成成果の有無を判断するために、対象プロジェクトの作業成果物や管理者・開発者の証言を、この「アセスメント指標」にマッピングすることで、達成度合いを評価します。Automotive SPICEにおいてもアセスメント指標を定義していますが、V4.0への更新に伴い内容が更新されましたので、ご紹介します。  Automotive SPICE V4.0におけるアセスメント指標V4.0では、プロセス実施指標とプロセス能力指標の定義がなくなり、単に2つの指標として、プラクティスと情報項目を定義しています。 プラクティス：活動重視の指標 情報項目：結果重視の指標プラクティスは、V3.1と同様に、基本プラクティスと共通プラクティスの2種類となっています。 基本プラクティス（BP）：能力レベル1に適用。プロセス成果の達成程度を示し、プロセス固有のものである。 共通プラクティス（GP）：能力レベル2～5に適用。プロセス属性の達成成果の程度を示し、全プロセス共通のものである。情報項目（II）は、プロセス成果およびプロセス属性の達成成果の達成を構成するものとしており、情報項目特性（IIC）含まれます。V4.0では、アセスメント指標がシンプルになり、理解しやすい構造になっていますね。  作業成果物と情報項目の違いプラクティスに変更はありませんが、V3.１で定義されていた作業成果物や共通リソースが、情報項目に変更されました。それでは、作業成果物と情報項目にはどのような違いがあるのでしょうか？V4.0では、以下のように定義しています。 情報項目：アセッサーがプロセス属性の達成成果を判断するために使用される関連情報の一部分を定義している。 作業成果物：プロセスを実施、管理、確立、分析、および革新する際に、アセスメント対象組織によって生成されるものである。情報項目（II）は、アセッサーがアセスメントにおいて、作業成果物を調査する際に、「何を見るべきか」のガイダンスとして提供されているものであり、作業成果物そのものではありません。また、情報項目に含まれる情報項目特性は、情報項目の潜在的な特性の例を示しており、作業成果物のチェックリストとして使用されることを意図していません。言い換えると、作業成果物はプロジェクトが生成した（生成すべき）ものであり、情報項目はアセッサーが調査の拠り所をするものなので、両者を同一と理解してはいけないことになります。作業成果物と情報項目（情報項目特性）の関係は以下のように整理されています。 作業成果物は、複数の情報項目特性から構成される場合がある。 複数の作業成果物が同一の情報項目特性を有する場合もある。 作業成果物は、情報項目とは別の名称で呼んでもよい（名称は重要ではない）。 構造や帳票が異なる作業成果物が存在しても良い。（例：課題をエクセルとチケットシステムで管理）例えば、V3.1の作業成果物「ソフトウェア要件仕様書」は、V4.0では、「要求」と「要求の属性」に変更されています。これは「ソフトウェア要件仕様書という文書が存在しないといけない」ということではなく、基本プラクティスを満たした結果として、情報項目や情報項目特性が含まれているのであれば、「ソフトウェア要求仕様書」や「ソフトウェア仕様書」でも良く、複数の「ソフトウェア仕様書」に分冊されていても良いことを示しています。  さいごにいかがでしょうか？システム開発やソフトウェア開発に携わっている方にとって、V3.1で求められていた作業成果物を生成することを意識するのではなく、皆さんの組織や開発している製品の特長に合わせて、V4.0で求めれている情報項目や情報項目特性を満たした作業成果物の構成や形を検討してみることが大切なことだと思います。内山哲三