Updates

新着情報

お知らせ

お詫び(1/29開催分 第2回 Automotive SPICE 変更点解説 Webinar 中止の件)

本日(2025年1月29日)開催を予定しておりました 第2回 Automotive SPICE 変更点解説 Webinarは、弊社の設定ミスにより「アクセス権がありません」というメッセージが出力され、皆様の参加をお受けすることができませんでした。 本件修正には、会議URLを変更する必要があることが判明したため、やむを得ず中止することにいたしました。本日開催分を、2025年2月5日(水曜日)に変更して再度下記のようにご案内させていただきたく存じます。また、2025年2月4日(火曜日)予定されているセッションへの振り替えもご検討いただければ幸いです。ご都合がつかない場合は、誠に恐縮ではございますが、後日 Youtube チャンネルに動画を公開いたしますので、ご視聴いただきたく存じます。 Webinar開催日程:2025年2月4日(火曜日)16:00 ~ 17:002025年2月5日(水曜日)16:00 ~ 17:00 本日(2025年1月29日)参加登録いただいていた皆様には、両日分の開催URLを記載したご案内を別途送付いたしますので、どちらかにご参加いただければと存じます。改めての参加登録は不要でございます。 本日は、皆様の貴重な時間をWebinar参加に調整していただいたにも関わらず、弊社のミスによりお時間を無駄にさせてしまいましたこと、改めてお詫び申し上げます。

コラム

Automotive SPICE 4.0 トレーサビリティと一貫性に関する変更点(SYS/SWE/VAL)

Automotive SPICE 4.0 に関するコラム、過去のコラムで諸々の変更点を解説してきましたが、今回はエンジニアリング系プロセス全般(SYS、SWE、VAL)のトレーサビリティと一貫性に関する括りで整理してみました。また、関連するこれまでのコラム解説へのリンクも掲載していますので、合わせてご確認ください。◆妥当性確認プロセス 一貫性の確保及び双方向トレーサビリティの確立:VAL.1v4.0で新たに追加されたVAL.1(妥当性確認)プロセスにより、これまで水平方向のトレーサビリティがなかったSYS.1(要求抽出)に対しても、妥当性確認手段との一貫性の確保と双方向トレーサビリティの確立が求められるようになりました。これにより、SYS.1に対応した評価が必要となり、プロジェクト全体のトレーサビリティが強化されました。v4.0でVAL.1(妥当性確認)プロセスが追加された背景の考察は、以下のコラムを参照してください。「Automotive 4.0のVAL.1プロセス:検証との違いとその重要性」(2024.09.20)トレーサビリティ図 ・v3.1とv4.0の差分_VAL.1:◆ソフトウェア要件とソフトウェアユニット間のトレーサビリティの廃止:SWE.3v3.1では、ソフトウェア要件とソフトウェアユニット間のトレーサビリティの確立の要求が存在していましたが、v4.0では、この記述が削除され、ソフトウェア要求とソフトウェア詳細設計の間のトレーサビリティの確立に変更になりました。「ソフトウェアユニット」とは、実装レベルの用語ではなく、論理的モデリングレベルの用語であり、ソフトウェア要件とのトレーサビリティとは何を意味するかが、わかりにくかった問題を解消しています。この変更の詳細に関しては、以下のコラムを参照してください。「ソフトウェア要件とソフトウェアユニット間のトレーサビリティの廃止」(2024.04.09)トレーサビリティ図・v3.1とv4.0の差分_SWE.3:◆ソフトウェア詳細設計とソフトウェアコンポーネント/統合検証手段の間のトレーサビリティの追加:SWE.5v4.0のSWE.5 BP6で、SWE.5の検証手段とSWE.3のソフトウェア詳細設計の静的および動的な側面との間の一貫性を確保し、双方向トレーサビリティを確立する要求が追加となっています。なお、SWE.5の検証手段、またSWE.2、SWE.3のソフトウェア設計工程の作業の詳細に関しては、それぞれ以下のコラムで解説しています。「Automotive SPICE 4.0 SWE.5 ソフトウェア統合テストの考え方」(2024.06.13)「ソフトウェアエレメント、ソフトウェアコンポーネント、ソフトウエアユニットの関係について」(2024.07.19)トレーサビリティ図・v3.1とv4.0の差分_SWE.5:◆トレーサビリティの対象外となる事例:SYS.2/3,SWE.1/2v4.0のSYS2 BP5の 備考8では、例えば「XXXプロセス標準への準拠」というプロセス要求のような利害関係者の非機能要求については、システム要求からはトレースできないが、検証の対象であるとしています。つまり、トレーサビリティは対象外ですが、例えば「監査報告書」によって、証拠付けされる必要があります。Automotive SPICE v4.0 SYS.2から引用:以下はSWE.1の例ですが、このほかにSYS.3、SWE.2にも、同じような備考が追加されていますので、ご確認ください。Automotive SPICE v4.0 SWE.1から引用:非機能要求でも、その内容によっては、トレーサビリティの対象なる場有もあります。以下のコラムで解説しています。「Automotive SPICE 4.0における非機能要件の考え方」(2024.01.30) ◆「検証手段」と「検証結果」の双方向トレーサビリティの確立:SYS.4~5,SWE.4~6v3.1のテスト系プロセスで要求されていた「テストケース」と「テスト結果」の間の双方向トレーサビリティの確立は、v4.0では「検証手段」と「検証結果」という用語に変更されています。単に用語の変更だけで、トレーサビリティの図的には差分はありません。用語が変更された背景などに関しては、以下のコラムを参照してください。「『テスト』から『検証』へ-Automotive SPICE 4.0の『検証』プロセス-」(2024.06.19) ◆双方向トレーサビリティと一貫性の概念の再統合:SYS.2~5、SWE1~6v3.1ではトレーサビリティと一貫性の要求は、2つBPに分離されていましたが、v4.0では1つのBPに再統合されました。具体的には、v3.0で1つのBPから2つのBPに分離されたものが、v4.0で再度1つのBPに統合されただけであり、トレーサビリティの図的には差分はありません。この変更により、トレーサビリティと一貫性の管理がよりシンプルかつ効率的になりました。最後に、Automotive SPICE 4.0のエンジニアリング系プロセスの一貫性とトレーサビリティの図を引用しておきます。佐藤崇

コラム

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)を使って自らの業務を効率化するところから始めてみてはいかがでしょうか。園田幸治

コラム

Automotive SPICE GP 徹底解説 その2 ~ GP2.1.3(責任と権限)

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

コラム

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

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に関するコラムをお届けいたしますので、ご期待ください。(安部宏典)

コラム

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

Automotive SPICE v4.0 のシステムアーキテクチャ設計プロセス(SYS.3 )に関して、Automotive SPICE v3.1 から SYS.3 の BP 構成やアウトプット成果物のイメージが変更されたので、その変化点について解説します。1.SYS.3 の基本プラクティス(BP)について Automotive SPICE v3.1 の SYS.3 のシステムアーキテクチャ作成に関する BP は以下の4個で構成されていました。BP1:システムアーキテクチャ設計書の作成BP2:システム要件の割り当てBP3:システムエレメントのインタフェースの定義BP4:動的な振る舞いの記述 ここでは BP1 がアーキテクチャ全体について記述している一方で、BP2、BP3、BP4 はアーキテクチャの側面を記述しています。 これによって、例えば BP1 が達成と評価されたにももかかわらず BP3 が未達成と評価された場合、BP1 達成と矛盾するため、混乱を招く恐れがありました。 上記混乱を防止するため、Automotive SPICE v4.0 のシステムアーキテクチャ作成に関する BP は2個に集約されました。BP1:システムアーキテクチャの静的な側面の仕様化BP2:システムアーキテクチャの動的な側面の仕様化2.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 へとアーキテクチャ設計をブレークダウンする際に、これらの情報項目の記述内容はガイドラインとして活用できると思います。ご不明な点等あれば、弊社までお問合せください。 海農公宏