ビジネスガレージ株式会社

B'zine 2026年9月号（Automotive SPICE v4.０から v4.1への変更点について等）を発行しました

B'zine 9月号を発行いたしました。ショート動画も公開していますので、弊社公式YouTubeより是非ご視聴ください。B'zineは、１回/月のペースでの配信しています。ご興味のある方は、ここから登録をお願いいたします。 B'zineビジネスガレージ通信（2026年9月号） B’zine ビジネスガレージ通信（2026年9月号）お届けします。「暑さ寒さも彼岸まで」と言われますが、今夏の連日の猛暑も弱まって幾分しのぎやすくなりました。先月から各地で台風や線状降水帯による、洪水・浸水・がけ崩れ等の天災が継続発生しており、更に９月末にかけて台風や秋雨前線の影響による大雨洪水予報も出ていますので、十分ご注意ください。【今月のトピックス】イベント：９月３０日（水）B'live SEP2026 Webinar開催：「なぜ今、社内アセッサ育成なのか？」組織的改善の質を高めるチェンジメーカーのススメイベント：B'live NOV2026 Webinar：（予告）品質保証と品質管理の本質～ASPICE SQA活動を品質改善につなげるために～イベント：B'live 特別号2026 Webinar：（予告）「Automotive SPICE v4.０から v4.1への変更点について」コラム：Automotive SPICE：問題の本質を解くシリーズ～レビュー編～そのレビュー、本当に品質を上げていますか？コラム：Automotive SPICEが生んだ悪しき習慣～構成管理編～構成管理：「とりあえず一覧を作る」が現場を疲弊させるコラム：テスト文書に迷ったらISO 29119を参考にしようお知らせ：Automotive SPICE v4.1（英語版）がリリースされました【イベント】 2026年9月30日 B'live SEP2026 Webinar：「なぜ今、社内アセッサ育成なのか？」～組織的改善の質を高めるチェンジメーカーのススメ～「改善活動は行っているものの、なかなか成果につながらない」「成熟度レベルの達成が目的化し、その先の改善につながらない」そんな課題を感じていませんか？変化が激しく複雑化する時代において、企業には継続的に改善し続ける力が求められています。その中で重要な役割を担うのが、組織の課題を可視化し、現場と管理層をつなぎながら改善を促進する社内アセッサです。これからの社内アセッサに求められるのは、単なる「評価者」ではありません。改善の方向性を示し、関係者を巻き込みながら変革を推進するチェンジメーカーとしての役割が期待されています。日時：2026年9月30日（水）16:00-17:00参加申し込みはこちらから→https://www.bgarage.co.jp/event/2391/ B'live NOV2026 Webinar：（予告）品質保証と品質管理の本質～ASPICE SQA活動を品質改善につなげるために品質保証の仕事は、監査だけではありません。品質データを活用しながら、改善を後押しするSQAの役割を紹介します。AI時代だからこそ求められる、これからの品質保証のあり方を一緒に考えます。日時：2026年11月27日(金) 16:00 〜 17:00詳細およびお申し込みのご案内は、後日お知らせ致します。 B'live 特別号2026 Webinar：（予告）「Automotive SPICE v4.０から v4.1への変更点について」VDA QMCより、Automotive SPICE v4.1（英語版）が、2026年8月２４日付けでリリースされています。日本語版は現在翻訳作業中ですが、日本語版リリース後のなるべく早い時期にAutomotive SPICE v4.０から v4.1への変更点に関するWebinarの開催を計画しています。日時：別途ご案内いたします詳細およびお申し込みのご案内は、後日お知らせ致します。【コラム】 Automotive SPICE：問題の本質を解くシリーズ～レビュー編～そのレビュー、本当に品質を上げていますか？Automotive SPICEのアセスメントを実施していると、レビューに関するさまざまな状況を目にします。もちろんレビュー計画は存在します、レビュー記録も残されています、会議の開催履歴もあります。一見すると、レビューは適切に実施されているように見えます。しかし、その活動が本当に品質向上に貢献しているかというと、疑問を感じるケースが少なくありません。詳細はこちら→https://www.bgarage.co.jp/news/2497/ Automotive SPICEが生んだ悪しき習慣～構成管理編～構成管理：「とりあえず一覧を作る」が現場を疲弊させるAutomotive SPICE対応の現場で、いつの間にか「規格に対応すること」自体が目的になっていないでしょうか。構成管理も、その代表例の一つです。・構成品目一覧を作る・ステータス報告を用意する・成果物へのリンクを貼る・アセスメント前に、不足情報をかき集める一見すると、Automotive SPICEの要求に対応する活動に見えます。しかし、その一覧は現場で使われているでしょうか。ステータス報告は、日常の管理に役立っているでしょうか。もし、アセスメントのためだけに作っているのであれば、注意が必要です。それは構成管理ではなく、構成管理をしているように見せる作業かもしれません。詳細はこちら→https://www.bgarage.co.jp/news/2477/ テスト文書に迷ったらISO 29119を参考にしようISO 29119は、ソフトウェアテストに関する国際規格です。テスト計画書やテスト完了報告書を作成するとき、「何を書けばよいのだろう」と悩んだ経験はないでしょうか。社内標準が整備されていれば参考にできますが、常に適切な資料があるとは限りません。過去のプロジェクトの文書を参照しても、なぜその項目が必要なのか分からなかったり、開発手法やシステム規模の違いからそのまま使えなかったりすることがあります。私自身も、そのような場面で参考にしていたのがISO/IEC/IEEE 29119です。国際規格と聞くと、堅苦しいルールを思い浮かべるかもしれません。しかし、ISO 29119は準拠を目的とする場合だけでなく、テストで何を検討し、どのような情報を記録すべきかを考える際の参考資料としても活用できます。詳細はこちら→https://www.bgarage.co.jp/news/2451/ 【お知らせ】 Automotive SPICE v4.1（英語版）がリリースされました VDA QMCより、Automotive SPICE v4.1（英語版）がリリースされました。日本語版は現在翻訳作業中のため、後日リリースされる予定です。合わせて、Automotive SPICE v4.1に対応する英語版ガイドライン（Automotive SPICE Guidelines 3rd revised edition）も販売開始されました。詳細はこちらから→https://www.bgarage.co.jp/news/2460/ご不明点、ご質問、ご要望等ございましたら、下記までご連絡ください。

テスト文書に迷ったらISO 29119を参考にしよう

ISO 29119は、ソフトウェアテストに関する国際規格です。テスト計画書やテスト完了報告書を作成するとき、「何を書けばよいのだろう」と悩んだ経験はないでしょうか。社内標準が整備されていれば参考にできますが、常に適切な資料があるとは限りません。過去のプロジェクトの文書を参照しても、なぜその項目が必要なのか分からなかったり、開発手法やシステム規模の違いからそのまま使えなかったりすることがあります。私自身も、そのような場面で参考にしていたのがISO/IEC/IEEE 29119です。国際規格と聞くと、堅苦しいルールを思い浮かべるかもしれません。しかし、ISO 29119は準拠を目的とする場合だけでなく、テストで何を検討し、どのような情報を記録すべきかを考える際の参考資料としても活用できます。ISO 29119とはISO 29119の各規格の概要や発行状況は、ISOの公式サイトで確認できます。本文では、実務で参照しやすいPartを中心に紹介します。ISO 29119はソフトウェアテストの国際規格群です。特定の業界に限定されず、さまざまな組織で活用できるよう整備されています。本記事で取り上げる主要なPartを、対象テーマ、実務で役立つ場面、現行版の観点で整理します。なお、ISO 29119シリーズには、ここに掲載していないPartもあります。本記事では、ソフトウェアテストの基本とテストドキュメントの作成に関係が深いPart 1～5に加え、AIベースシステムを扱うPart 11を取り上げます。 Part対象テーマ実務で役立つ場面現行版Part 1一般概念基本的な考え方や主要概念を確認し、関係者間で用語の意味を合わせたいときISO/IEC/IEEE 29119-1:2022Part 2テストプロセス組織、プロジェクト、個別のテスト活動をどのように統制・管理・実施するか整理したいときISO/IEC/IEEE 29119-2:2021Part 3テストドキュメントテスト計画や結果など、必要な情報とテンプレートを確認したいときISO/IEC/IEEE 29119-3:2021Part 4テスト技法テストケースを経験だけに頼らず、一定の根拠を持って設計したいときISO/IEC/IEEE 29119-4:2021Part 5キーワード駆動テスト操作などをキーワードとして定義し、その組み合わせでテストを表現したいときISO/IEC/IEEE 29119-5:2024Part 11AIを利用したシステムのテスト期待結果の一意性や学習データの品質など、AI特有の課題を踏まえてテスト環境や確認場面を検討したいときISO/IEC TR 29119-11:2020何を書けばよいか困ったときに使う私が実務で特に参考にしていたのは、テストドキュメントを扱うPart 3です。テスト計画書を白紙から作成すると、重要な項目を見落としがちです。経験だけに頼ると、抜け漏れが発生することがあります。例えば、テスト対象は記載していても対象外が明確でない、スケジュールはあっても完了条件がない、テスト環境は定めていても準備の担当者が決まっていない、といった抜けが生じます。ISO 29119 Part 3をチェックリストとして活用するそのようなとき、Part 3に示されたテストドキュメントの構成や情報項目を確認します。Part 3では、テスト方針やテスト計画、テスト状況報告、テスト完了報告のほか、テストケース、テスト手順、テストデータ要求、テスト環境要求などを扱っています。私はこれらを、規格どおりの文書を作るためではなく、検討項目のチェックリストとして活用していました。図：ISO 29119 Part 3で扱うテストドキュメントの構成私はこれらを、規格どおりの文書を作るためというより、検討項目のチェックリストとして利用していました。白紙から考えるより問いを立てる規格の項目を手掛かりに、次の観点を確認します。テストの目的と対象範囲テスト方法、必要な環境やデータ設計・実行・判定の担当者テストの開始条件と完了条件このように問いを立てることで、白紙の状態から考えるよりも効率よくテスト計画を整理できます。ISO 29119の項目をすべて書く必要はないISO 29119を参考にするときは、規格に示された情報をすべて個別の文書として作成する必要はありません。プロジェクトの規模やリスクに応じて必要な情報を選択します。例えば、小規模なプロジェクトでは、テスト計画とテスト戦略を一つの文書にまとめられます。テストケースとテスト手順を同じ管理表で管理することも可能です。テスト状況はダッシュボードで共有し、テスト完了報告をリリース判定資料に含める方法もあります。アジャイル開発では、Wikiやチケット管理ツール、テスト管理ツールなどで情報を管理することもあります。すでに他の文書に記載されている内容は転記せず、参照先を示せば十分です。重要なのは文書の数ではありません。テストの実施や意思決定に必要な情報が整理され、関係者が確認できることです。品質担当として開発者に勧めていたこと私は品質を担当する立場として、テスト計画やテストドキュメントの作成に迷っている開発者に、ISO 29119を参考にすることを勧めていました。品質担当者が規格を読み、作成したテンプレートを開発者に渡す方法もあります。しかし、実際にシステムを開発し、テストする開発者自身が規格の観点を知ることにも意味があります。テストドキュメントは、後から実績を残すためだけのものではありません。作成する過程で、テストの目的、範囲、方法、リスクを整理できます。何を、なぜ確認するのか。どこを重点的に確認するのか。どのような状態になったらテストを完了できるのか。確認できない領域には、どのようなリスクが残るのか。このような問いに答えることが、テスト計画を作るということです。ISO 29119は、そのための観点を与えてくれます。開発者に勧める際も、「規格に合わせて立派な文書を作ってください」という伝え方はしていませんでした。「何を書けばよいか分からなければ、まずPart 3を見てみるとよいですよ」と案内していました。規格を守ること自体を目的にするのではなく、考慮すべき事項の抜け漏れを減らすために利用します。ISO 29119で学んだ「テストしないこと」ISO 29119のテストドキュメントを参考にする中で、私が特に役立つと感じたのが、「何をテストしないのか」を明確にすることでした。テスト計画を作るときは、どうしても「何をテストするか」に意識が向きます。しかし、プロジェクトの期間、予算、要員には限りがあります。考えられるすべての条件を、同じ深さでテストすることはできません。テスト対象外を明確にするテスト対象を定義するだけでなく、どの領域をテスト対象外とするのかも明記します。例えば、今回変更していない機能、サポート対象外のブラウザ、外部サービスそのものの内部機能、大量アクセス時の性能、災害発生時の切り替え処理、特殊な運用条件などが挙げられます。テスト対象だけを記載する場合は注意が必要です。記載されていない項目が意図的な対象外なのか、単なる記載漏れなのか判断できません。テスト対象外を明記することで、今回のテストで確認する範囲と確認しない範囲の境界が明確になります。その結果、テストの目的や制約について関係者の認識を合わせやすくなります。また、複数の組織が開発や評価を分担するプロジェクトでは、テスト実施責任の境界を明確にすることも重要です。例えば、車両レベルで実施することが適切なテスト項目がある場合は、担当をOEMとして理由を明記するのも１つの方法です。対象外にする理由や実施主体を記載しておくことで、「誰が確認するのか分からないテスト」の発生を防ぐことができます。対象外にする理由を説明するただし、「対象外」と一言書くだけでは不十分です。対象外とする理由、残るリスク、別のチームや工程での確認の有無、運用監視などによる補完策、判断の承認者も併せて整理します。「時間がないからテストしない」という理由だけでは、品質上の判断として十分ではありません。時間が限られているのであれば、どのリスクを優先し、どのリスクを受け入れるのかを明確にする必要があります。テストしないことを書くのは、品質を諦めることではありません。むしろ、重要な領域にリソースを集中させるための判断です。残るリスクを可視化する効果もあります。テスト対象外項目をレビューするテスト対象外は、文書に書いただけでは十分な効果を発揮しません。記載内容を関係者とレビューする作成者は当然の対象外だと考えているかもしれません。一方で、利用部門はテストされると考えている可能性があります。また、開発チームと別チームが、互いに相手が確認すると思っている可能性もあります。レビューでは、対象外とする理由が妥当か、重要な機能を誤って除外していないか、残るリスクを関係者が理解しているかを確認します。別のチームや工程で確認する場合は、担当者と実施時期も明確にします。レビューの結果、対象外としていた項目をテスト対象へ戻すこともあります。反対に、優先度の低いテストを対象外とし、より重要なテストへ時間を振り向ける場合もあります。対象外のレビューは、単なる文書の添削ではありません。何を確認せず、どのリスクを受け入れるのかについて、関係者の認識をそろえる活動です。プロジェクト管理への応用私は「テストしないことを書く」という考え方を応用し、テスト以外の活動でも「実施しないこと」を記載するようにしました。プロジェクト計画書には実施する作業が詳しく書かれますが、実施しない作業は意外と明記されていません。その結果、プロジェクトが進んでから、「これもやってくれると思っていた」という期待のずれが生じます。この場合も、書くだけでは不十分です。実施しない理由と影響を関係者とレビューします。「書いていないから実施しない」のではなく、「実施しないことを明示し、その理由と影響について合意する」ことが大切です。ISO 29119は迷ったときに戻れる参考資料ISO 29119は、規格への準拠だけを目的としたものではありません。テスト計画やテストドキュメントの作成に迷ったとき、考慮すべき項目を整理するための参考資料として活用できます。私が実務で特に有効だと感じたのは、「何をテストするか」だけでなく、「何をテストしないか」を明確にすることでした。また、対象外とした理由や残るリスクを関係者とレビューし、認識をそろえることも重要です。テストドキュメントの目的は文書を増やすことではありません。テストの目的や範囲、リスクを整理し、関係者が適切な判断を行えるようにすることです。何を書けばよいか迷ったときは、まISO 29119 Part 3を開いてみてください。規格としてではなく、考えるための道具として活用できます。（佐野忠）

Automotive SPICEが生んだ悪しき習慣　～構成管理編～

構成管理：「とりあえず一覧を作る」が現場を疲弊させるAutomotive SPICE対応の現場で、いつの間にか「規格に対応すること」自体が目的になっていないでしょうか。構成管理も、その代表例の一つです。構成品目一覧を作る。ステータス報告を用意する。成果物へのリンクを貼る。アセスメント前に、不足情報をかき集める。一見すると、Automotive SPICEの要求に対応する活動に見えます。しかし、その一覧は現場で使われているでしょうか。ステータス報告は、日常の管理に役立っているでしょうか。もし、アセスメントのためだけに作っているのであれば、注意が必要です。それは構成管理ではなく、構成管理をしているように見せる作業かもしれません。「とりあえずリンクを貼る」ことは構成管理ではない構成管理では、要求仕様書や設計書などの文書を識別し、状態や保管場所を把握する必要があります。紙で文書を管理していた時代は、文書一覧を手掛かりに、書棚から目的の文書を綴じたバインダーを探していました。所定の場所にバインダーがなければ、必要な文書を探すだけでも大変でした。電子管理になった現在も、本質は同じです。文書一覧は台帳に、バインダーや書棚は電子ファイルや共有フォルダーに変わりました。台帳にリンクを貼っても、リンク先が最新版とは限りません。ファイルが移動され、リンクが切れることもあります。ところが、現場では次のように要求が単純化されることがあります。「一覧を作ればよい」「成果物へのリンクを貼ればよい」その結果、次のような状況が起こります。構成品目一覧はあるが、誰も日常的に見ていないステータス報告はあるが、更新されていないリンク先が最新版か分からない台帳にはあるが、所定の場所にファイルがないアセスメント直前に情報を整えている構成管理に必要なのは、一覧やリンクを作ることではありません。必要なときに、正しい文書を確実に取り出せる状態を保つことです。この状態を維持する仕組みがなければ、規程や一覧を整備しても、現場の運用は人の注意力に依存したままです。特定プロジェクトだけのプロセスになるさらに問題なのは、このような仕組みが特別扱いされることです。社内で「Automotive SPICE対応プロセス」や「A-SPICEプロセス」と呼ばれるようになります。そして、OEMから対応を要求されたプロジェクトだけが使います。本来、規格対応は組織の開発力を高めるためのものです。しかし、形式的な対応を続けると、特定プロジェクトだけが我慢して使うプロセスになってしまいます。当然、現場は進んで使おうとはしません。規程があっても現場では回らない構成管理が回らないのは、ルールがないからとは限りません。多くの会社には、次のようなルールや仕組みがあります。文書管理規程採番ルール文書の格納場所文書管理台帳それでも、採番ミスや登録漏れは発生します。台帳と実体ファイルが一致しないこともあります。過去文書を探す作業にも時間がかかります。ルールそのものは存在していました。しかし、ルールがあるだけでは、正しい運用は定着しません。Webinar「採番ミスから脱却する構成管理DX実践事例【Automotive SPICE SUP.8】」でも、この問題を取り上げました。人の注意力に依存した運用実際の構成管理では、多くの作業を人の注意力に頼っていました。具体的には、次のような作業です。採番ルールを思い出す正しい台帳を探す台帳へ情報を登録するフォルダを目視で確認する未格納を見つけて連絡する担当者が注意深く対応すれば、一定期間は問題を防げます。しかし、業務量の増加や担当者の変更によって、ミスや漏れが起こる可能性があります。問題は、担当者の意識や能力ではありません。規程を無理なく守れる仕組みがないことです。構成管理で本当に必要なこと構成管理で必要なのは、アセスメント用の帳票を増やすことではありません。まず、要求仕様書や設計書など、開発に必要な文書を確実に作成します。次に、その内容を関係者がレビューします。これにより、要求の抜けや設計上の問題を早期に発見できます。レビュー済みの文書を正しく管理することも重要です。古い版や未承認の文書を使用すると、設計、実装、テストに誤りが広がる可能性があります。つまり、文書管理は単なる事務作業ではありません。正しい文書を確実に使える状態にすることで、開発品質を支える活動です。日常業務の中で、自然に次のことができる状態を作ることです。文書や成果物を識別できる採番ルールに沿って番号を付けられる登録状態を確認できる必要な文書をすぐに探せる台帳と実体ファイルのズレに気付ける過去状態を必要に応じて確認できるAutomotive SPICEが求めているのも、現場から切り離された帳票づくりではありません。必要な成果物を作り、レビューし、正しい状態で管理することです。その積み重ねが、製品やソフトウェアの品質向上につながります。最初から完璧な仕組みを目指さない私たちは、構成（文書）管理を大規模な専用システムで解決しようとはしませんでした。まず、現場で負担になっている作業を整理しました。文書番号の採番過去文書の検索台帳情報の管理未格納文書の確認そして、優先順位の高いものから改善を始めました。重要なのは、最初から完璧な構成管理システムを作ることではありません。まず現場で使ってもらうことです。その後、利用者の声を聞きながら改善します。 Power Platformで一つずつ仕組み化具体的には、Power Apps、SharePoint、Power Automateを活用しました。文書番号の採番から始め、次の機能を段階的に追加しました。文書検索マイ文書管理ダッシュボード未格納監視メールやTeamsによる通知月次バックアップWebinarでは、これらの機能を段階的に追加した流れを紹介しています。その中で仕組み化した全体構成と各ツールの役割分担を示した図が以下となります。完成品を一度に導入したわけではありません。日常的な困りごとを、一つずつ仕組みに置き換えました。人が覚える運用から、仕組みが支える運用へ採番ルールを人に覚えさせるのではなく、画面上の選択肢に組み込みました。複数のExcel台帳を探す代わりに、検索画面から文書を探せるようにしました。未格納文書を人が目視確認するのではなく、仕組みで検知して通知するようにしました。台帳情報の保存も自動化しました。毎月、バックアップを作成する仕組みです。人が注意し続ける運用を、一つずつ仕組みに置き換える。この考え方が、現実的な構成管理DXにつながります。脱・Automotive SPICEごっこAutomotive SPICEが悪いわけではありません。問題は、規格を「現場を良くするための道具」として使わないことです。アセスメントを通すための作業リストとして扱うと、規格対応は形骸化します。構成品目一覧を作ることが目的ではありません。ステータス報告を整えることも目的ではありません。リンクを貼るだけでは、構成管理とはいえません。本来の目的は、現場の成果物を正しく管理することです。そして、必要なときに必要な情報を説明できる状態にすることです。まずは一つの困りごとから構成管理DXは、高価なツールを導入することではありません。人に依存していた判断や確認を、仕組みに置き換えることです。もし構成管理が回っていないなら、現場の困りごとを一つ選んでみてください。採番に時間がかかっていないか過去文書を探すのに苦労していないか台帳と実体ファイルがずれていないか未格納文書を目視で探していないかそこに、構成管理改善の入口があります。ビジネスガレージでは、文書管理や構成管理の現状を整理します。また、属人化している判断や確認作業を可視化します。さらに、Power Platformを活用した仕組みづくりも支援しています。Automotive SPICEやISO 9001を踏まえた運用改善にも対応します。「規格対応のための構成管理」ではなく、現場で使われ、継続して回る構成管理へ。それが、私たちが考える構成管理DXです。（鈴木功）構成管理改善をお考えの方へ文書管理や構成管理が形骸化している、アセスメント前の確認作業に負担がかかっているなどのお悩みがございましたら、お問い合わせフォームからお気軽にご相談ください。構成管理は、構成品目一覧を作るだけでなく、日常的に状態を把握し、継続して運用できる仕組みにすることが重要です。当社のロボットサービス（構成管理ロボ）もご覧ください。

コラム

2026/09/23

Automotive SPICE：問題の本質を解くシリーズ　～レビュー編～

そのレビュー、本当に品質を上げていますか？1. はじめにAutomotive SPICEのアセスメントを実施していると、レビューに関するさまざまな状況を目にします。もちろんレビュー計画は存在します、レビュー記録も残されています、会議の開催履歴もあります。一見すると、レビューは適切に実施されているように見えます。しかし、その活動が本当に品質向上に貢献しているかというと、疑問を感じるケースが少なくありません。例えば次のような状況です。・100ページ以上ある設計書のレビュー時間が15分・レビュー参加者が作成者と承認者の2名のみ・指摘件数がゼロ、あるいは1件程度・指摘内容が誤字脱字や表記ゆれのみ・レビュー会議で初めて成果物を開いている・レビュー結果は毎回「問題なし」皆さんのプロジェクトではいかがでしょうか。もし、このようなレビューが日常的に行われているのであれば、一度立ち止まって考えてみる必要があります。果たして、そのレビューは本当に品質を確認できているのでしょうか。レビューとは、本来、成果物に潜む問題を早期に発見し、後工程への流出を防ぐための重要な品質保証活動です。にもかかわらず、レビューが単なる「実施記録を残すためのイベント」になってしまうと、品質向上効果はほとんど期待できません。今回は、Automotive SPICE対応でよく見られるレビューの形骸化について考えてみたいと思います。2. よくある形骸化したレビューアセスメントの現場では、レビュー活動に関して次のような状況を見かけます。レビュー時間が極端に短いレビュー対象が数十ページから百ページを超えるにもかかわらず、レビュー時間が15分から30分程度しか確保されていないケースがあります。もちろん成果物の内容や成熟度によって必要な時間は異なります。しかし、内容を理解し品質を確認し議論するためには一定の時間が必要です。短時間で終了するレビューが必ずしも悪いわけではありません。問題なのは、「短時間で終わることが目的になっている」ケースです。実際には十分な確認が行われていないにもかかわらず、「レビュー完了」という結果だけが残されてしまいます。レビュアーが少ないレビュー参加者が作成者と承認者の2名のみというケースも少なくありません。もちろん成果物の内容によっては少人数レビューが適切な場合もあります。しかし、以下のような多面的な視点が必要な成果物に対して、参加者が少なすぎる場合は注意が必要です。・要求を理解している人・設計を理解している人・テスト観点を持つ人・安全要求を理解している人レビューの価値は、作成者自身では気付けない問題を発見することにあります。同じ視点しか存在しないレビューでは、検出できる問題にも限界があります。指摘件数が極端に少ないレビュー件数が少ないことを品質が高い証拠と考える組織があります。しかし、これは必ずしも正しくありません。むしろ、以下のような理由で問題が見つかっていない可能性があります。・レビュー観点が曖昧・事前準備が行われていない・発言しにくい雰囲気がある特にレビューで発言することが否定的に受け止められる組織では、問題があっても指摘されないことがあります。ゼロ件という結果だけを見て安心するのではなく、「本当に確認した結果なのか」を考える必要があります。指摘内容が品質につながっていないレビュー記録を見ると、以下のような指摘ばかりが記載されていることがあります。・フォントサイズ・体裁・誤字脱字・表記ゆれもちろんこれらも必要です。しかし、本来レビューで重点的に確認すべきものは別にあります。例えば、以下のようなことなどです。・要求との整合性・設計妥当性・例外処理・異常系動作・安全要求への対応・テスト可能性レビューが体裁確認だけで終わっているならば、本質的な品質問題は見逃されているかもしれません。3. なぜレビューは形骸化するのかでは、なぜこのような状況が発生するのでしょうか。最も大きな理由は、「レビューを行う目的」が変わってしまうことです。本来の目的は、「成果物の品質向上」です。しかしプロジェクトが忙しくなるにつれて、以下のような意識が強くなります。・レビュー記録を残さなければならない・監査で指摘されたくない・Automotive SPICE対応でエビデンスが必要・スケジュールに遅れたくないすると次第に、「品質を確認する」よりも、「レビューを実施したことにする」ことが重要になります。この瞬間からレビューは形骸化を始めます。さらに悪いことに、レビューの効果は見えにくいという特徴があります。例えばレビューの場で、以下のようなことが指摘された場合、これらは「レビューで発見された問題」として記録に残ります。・要求の解釈ミス・設計漏れ・インターフェースの不整合・異常系の考慮不足一方で、本当に大きな価値を持つのは、それらの問題が製品やシステムに組み込まれる前に取り除かれることです。例えば、設計レビューで通信異常時の処理漏れが発見され修正されたとします。もしその問題が見逃されていたら、以下のようなことがおきるかもしれません。・ソースコードにも誤った内容が実装される・テストで不具合として検出される・修正のために設計まで戻る・スケジュール遅延が発生するさらに最悪の場合、市場出荷後に障害として発生する可能性もあります。しかし、その問題はレビュー段階で修正されたため、実際の不具合にはなりませんでした。つまり、「レビューで指摘された内容は見える」が、「レビューによって将来発生するはずだった不具合を防いだ効果は見えない」のです。レビューの価値は、指摘件数だけでは測れません。「もしレビューをしていなかったら発生していたかもしれない問題を、どれだけ未然に防げたか」にあります。ところが、この効果は数字として表れにくいため、「レビューに時間をかけても成果がよく分からない」という考えが生まれやすくなります。結果として、以下のような方向へ進んでしまいます。・レビュー時間を削る・参加人数を減らす・事前準備を省略する・指摘分析を行わない短期的には効率化したように見えますが、実際には後工程でより大きな手戻りを発生させるリスクを高めているだけなのです。4. 本来レビューで達成すべきことレビューの目的は、成果物の品質を評価し、そこに含まれる問題やリスクをできるだけ早い段階で発見することです。成果物が後工程へ進んでから問題が発覚すると、大きな手戻りが発生します。例えば要求仕様の誤りや設計上の考慮漏れは、設計レビューの段階で発見できれば数時間から数日の修正で済むかもしれません。しかし実装後や結合テストで発覚した場合には、設計の見直し、プログラム修正、テストのやり直しなど、多くの工数が必要になります。さらに市場出荷後に発覚すれば、顧客対応や信頼低下など、開発工数だけでは測れない影響を及ぼすこともあります。レビューは、このような後工程での手戻りや品質問題を未然に防ぐための重要な品質保証活動です。またレビューには、単に問題を探すだけでなく、以下のような役割もあります。・成果物の内容が妥当であることを確認する・関係者間で認識を合わせる・次工程へ進めてよい状態であることを判断するしたがって重要なのは、「レビューを実施したかどうか」ではありません。重要なのは、「レビューによって成果物の品質をどの程度高められたか」、「レビューによって品質リスクをどれだけ低減できたか」です。レビュー記録が残っていても、品質向上につながっていなければ、そのレビューは本来の目的を達成しているとは言えません。レビューは会議ではありません。品質を確認し、品質を高めるための活動です。では、そのレビューを品質向上活動として機能させるためには、何が必要なのでしょうか。 5. レビューを品質向上活動として機能させるためにレビューの形骸化を防ぐためには、「レビューを実施した」という事実だけではなく、品質向上につながる仕組みとして運用することが重要です。レビューは単発のイベントではありません。レビューを計画し、実施し、その結果を分析し、次の改善につなげていくことで初めて品質保証活動として機能します。ここでは、レビューを価値のある活動にするためのポイントを紹介します。レビューはプロジェクト開始時に計画するレビューは成果物が完成してから慌てて開催するものではありません。本来はプロジェクト計画の段階で、品質確保のための活動として組み込んでおくべきものです。例えば以下のような内容をあらかじめ決めておきます。・どの成果物をレビュー対象とするか・いつレビューを実施するか・誰が参加するか・どの観点を確認するか・どの状態になればレビュー完了とするかこれらが明確になっていないと、開発が忙しくなった際に真っ先にレビュー時間が削られてしまいます。また、「設計書ができたので明日レビューしましょう」といった場当たり的な進め方では、十分な準備ができず、効果的なレビューは期待できません。レビューは品質確保活動であり、スケジュールの余り時間で実施するイベントではないのです。レビュー会議は議論の場であり、閲覧の場ではないレビューが形骸化する組織では、「レビュー会議で初めて成果物を開く」という光景をよく見かけます。このような状態では、会議時間の大半が資料の読み合わせになってしまい、本当に議論すべき内容に時間を使うことができません。効果的なレビューでは、以下のような流れになります。・レビュアーが事前に成果物を確認する・気になった点を整理する・レビュー会議で認識合わせや議論を行うつまりレビュー会議は、「成果物を読む場」ではなく、「問題点について議論する場」であるべきです。事前レビューが十分に実施されるだけでも、レビューの質は大きく向上します。品質保証グループがレビュー品質を監視するレビュー品質を維持するためには、品質保証グループの関与も重要です。プロジェクト任せにしてしまうと、納期や工数の制約からレビュー活動が後回しになりやすくなります。品質保証グループは、レビューそのものを実施するというより、「レビューが適切に運用されているかを監視する立場」として機能します。例えば、以下のようなことを定期的に確認します。・レビュー計画が作成されているか・必須成果物がレビュー対象になっているか・規定された参加者が参加しているか・レビュー記録が残されているか・指摘事項が適切に是正されているかまた、レビューを実施したという事実だけでなく、その内容にも目を向ける必要があります。例えば、以下のような状況が続いているのであれば、レビューが本来の目的を果たしていない可能性があります。・毎回15分で終了している・指摘件数が極端に少ない・誤字脱字しか指摘されていない品質保証グループは、そのような兆候を早期に発見し、改善を促す役割を担います。レビュー結果は組織改善の重要な情報源であるレビューは実施して終わりではありません。むしろ本当に重要なのは、レビューで発見された問題から組織の弱点を読み取ることです。例えばレビュー指摘を分析すると、以下のような傾向が見えてくることがあります。・要求仕様の理解不足・設計ルールの不徹底・トレーサビリティ不足・異常系検討不足・安全要求の理解不足もし同じような指摘が繰り返し発生しているのであれば、それは個人のミスではなく、組織的な課題かもしれません。レビューデータを蓄積し、以下の分析することで、教育やプロセス改善につなげることができます。・どの工程で問題が混入したのか・なぜその問題が発生したのか・なぜ見逃されたのか指摘件数よりも指摘内容を見るレビュー結果を評価する際に、「何件指摘が出たか」だけに注目する組織があります。しかし件数だけではレビューの良し悪しは判断できません。10件の誤字脱字を見つけたレビューよりも、1件の重大な要求漏れを発見したレビューの方が価値が高い場合もあります。以下のようなことが重要です。・どのような問題が見つかったか・品質リスクをどの程度低減できたか・再発防止につながる知見が得られたかレビューを品質向上活動として活用するためには、件数ではなく内容に着目する視点が欠かせません。レビューを改善活動の起点にするレビューで発見された問題を修正して終わるだけでは、同じ問題が繰り返し発生します。例えば、以下のような問題があつた場合は、仕組みそのものを改善する必要があります。・要求記述ルールが曖昧だった・設計テンプレートが不十分だった・レビュー観点が不足していたまた、レビューで得られた知見は、以下のようなことに活用できます。・プロセス改善・標準類の見直し・チェックリストの改善・教育内容の見直しこのような継続的改善が行われることで、レビューは単なる確認作業ではなく、組織の品質向上を支える活動へと発展していきます。 6. まとめAutomotive SPICEはレビュー記録の存在を求めているわけではありません。品質を作り込む仕組みが機能していることを求めています。もし、以下のようなことが当たり前になっているのであれば、一度立ち止まって考えてみてください。・極端に短いレビュー・少人数レビュー・指摘ゼロのレビュー・体裁確認だけのレビューそのレビューは、品質向上活動でしょうか。それとも、レビューを実施したという証拠を作るための活動になっていないでしょうか。レビューはプロジェクトの負担ではなく、品質を守るための最も重要な投資の一つなのです。（佐藤崇）

Automotive SPICE v4.1（英語版）がリリースされました

VDA QMCより、Automotive SPICE v4.1（英語版）がリリースされました。日本語版は現在翻訳作業中のため、後日リリースされる予定です。合わせて、Automotive SPICE v4.1に対応する英語版ガイドライン（Automotive SPICE Guidelines 3rd revised edition）も販売開始されました。詳細は下記をご参照ください。https://vda-qmc.de/en/automotive-spice/automotive-spice-veroeffentlichungen/

B'zine 2026年8月号（B'liveSEP2026：なぜ今、社内アセッサ育成なのか？等）を発行しました

B'zine 8月号を発行いたしました。ショート動画も公開していますので、弊社公式YouTubeより是非ご視聴ください。B'zineは、１回/月のペースでの配信しています。ご興味のある方は、ここから登録をお願いいたします。 B'zineビジネスガレージ通信（2026年8月号） B’zine ビジネスガレージ通信（2026年8月号）お届けします。夏季休暇が終わりましたが、皆様リフレッシュされたでしょうか？今夏は猛暑に加え、各地で地震発生、関東では台風や線状降水帯による洪水・浸水等の天災が頻発し、被災車両も計3,000台以上と報道されています。被害に遭われた皆様には心よりお見舞い申し上げますとともに、一日も早い復旧をお祈りいたします。【今月のトピックス】イベント：９月３０日（水）B'live SEP2026 Webinar開催：「なぜ今、社内アセッサ育成なのか？」組織的改善の質を高めるチェンジメーカーのススメイベント：Automotive SPICE 入門一般開催トレーニング（9月開催）のご案内コラム：プロジェクト管理トレーニングを「良かった」だけで終わらせない、3つの仕掛けコラム：コラム：構成管理の基本の「ほ」～構成管理の要ベースライン／ブランチ／マージを正しく理解する～コラム：技術は何を引き継ぐのか～技術継承（後編）：AI時代に見えてきた「観点」の価値～動画公開：「プロセスって何？」を改めて考える。B'talk #02動画をYouTubeに公開しました！お知らせ：新サービス「アセッサー育成プログラム」を開始しました【イベント】 2026年9月B'live SEP2026 Webinar：「なぜ今、社内アセッサ育成なのか？」～組織的改善の質を高めるチェンジメーカーのすすめ～多くの企業において、改善活動が定着しないという課題が存在します。内部アセスメント活動そのものを育成の場とし、開発当事者がアセッサーとして「自ら考え、判断し、改善につなげる力」を持ったアセッサーを育成することで、組織プロセス成熟度の向上、品質および生産性の改善、さらには顧客からの信頼獲得といった、経営成果につながる価値創出を実現する方法をご紹介します。日時：2026年9月30日（水）16:00-17:00参加申し込みはこちらから→https://www.bgarage.co.jp/event/2391/ Automotive SPICE 入門一般開催トレーニング（9月開催）のご案内Automotive SPICE 入門一般開催（9月分）の日程をご案内いたします。詳細およびお申込みは、下記リンクあるいは「イベント開催日程」からお願いいたします。Automotive SPICE 超入門 2026年9月15日Automotive SPICE 入門管理支援編 2026年9月29日Automotive SPICE 入門システムエンジニアリング編 2026年9月16日Automotive SPICE 入門ソフトウェアエンジニアリング編 2026年9月25日Automotive SPICE 入門ハードウェアエンジニアリング編 2026年9月30日参加申し込みはこちらから→https://www.bgarage.co.jp/news/2345/ 【コラム】プロジェクト管理トレーニングを「良かった」だけで終わらせない、3つの仕掛けプロジェクト管理トレーニングやAutomotive SPICE教育を実施しても、現場の行動がなかなか変わらない。車載システム・ソフトウェアの開発現場では、こうした悩みを抱える管理者や改善推進メンバーの方も多いのではないでしょうか。せっかく時間とコストをかけて実施するトレーニングです。できることなら、知識の習得だけで終わらせず、現場での行動変容や成果創出につなげたいものです。今回は、なぜトレーニング後に現場が変わらないのか、そして教育効果を現場へ定着させるために必要なことについてお伝えします。詳細はこちら→https://www.bgarage.co.jp/news/2310/ 構成管理の基本の「ほ」～構成管理の要ベースライン／ブランチ／マージを正しく理解する～DXやアジャイル開発が進展するなかで、多くの企業がGitやAzure DevOps、GitHubなどの構成管理ツールを活用しています。しかし、ツールを利用していても、「ベースライン」「ブランチ」「マージ」という基本概念を十分に理解していないために、手戻りや品質事故を招くケースは少なくありません。本稿では、過去のコラム「構成管理の基本の「き」～当たり前なことが難しい～に引き続き、構成管理の中核をなす3つの考え方について解説します。詳細はこちら→https://www.bgarage.co.jp/news/2367/ 技術は何を引き継ぐのか～技術継承（後編）：AI時代に見えてきた「観点」の価値～前回のコラムでは、成果物だけでは技術は継承されず、判断の理由や背景を残すことが重要であると述べました。では、その判断の理由や背景とは何なのでしょうか。最近、様々な場面で生成AIを使うようになって、私はその答えが少し見えてきたように感じています。AIは知識や答えを提示してくれます。しかし、その答えを評価するために何を見るべきか、どこを疑うべきかまでは教えてくれません。だからこそ私は、技術継承で本当に引き継ぐべきものは、知識そのものではなく「判断軸」なのではないかと考えるようになりました。今回は、AIとの関わりを通して見えてきた技術継承の本質について考えてみたいと思います。詳細はこちら→https://www.bgarage.co.jp/news/2377/ 【動画公開】 B'talk#02：「プロセスって何？」を改めて考えるYoutube動画を公開しました「うちにはプロセスがないんです。」、改善活動や品質向上のご相談を受ける中で、この言葉を耳にすることがあります。しかし、本当にプロセスは存在しないのでしょうか。実は、成果物が生み出されている以上、そこには必ず何らかのプロセスが存在しています。問題は「ない」ことではなく、「見えていない」ことかもしれません。HP掲載コラム執筆の背景を交えながら、・プロセスとはそもそも何か・なぜプロセスが現場で使われなくなるのか・日本企業と海外企業の考え方の違い・プロセス改善が失敗する本当の理由・良いプロセスを設計するために大切な視点について語っています。詳細はこちら→https://www.bgarage.co.jp/news/2396/ 【お知らせ】「アセッサー育成プログラム」の提供を開始しました「アセッサー育成プログラム」として以下の２つのサービスを開始しました。１）社内アセッサー育成プログラム２）リードアセッサー育成プログラム詳細はこちら→https://www.bgarage.co.jp/news/2416/

技術は何を引き継ぐのか　── 技術継承（後編）：AI時代に見えてきた「観点」の価値 ──

※前編はこちら「技術が伝わらないのはなぜか ── 技術継承（前編）：なぜ技術が現場に残らないのか ──」前回のコラムでは、成果物だけでは技術は継承されず、判断の理由や背景を残すことが重要であると述べました。では、その判断の理由や背景とは何なのでしょうか。最近、様々な場面で生成AIを使うようになって、私はその答えが少し見えてきたように感じています。AIは知識や答えを提示してくれます。しかし、その答えを評価するために何を見るべきか、どこを疑うべきかまでは教えてくれません。だからこそ私は、技術継承で本当に引き継ぐべきものは、知識そのものではなく「判断軸」なのではないかと考えるようになりました。今回は、AIとの関わりを通して見えてきた技術継承の本質について考えてみたいと思います。AIが見せてくれたもの生成AIに対しては、なぜその答えになったのか分からない結果が変わることがある品質を保証しにくいといった声を耳にします。確かにその通りです。しかし考えてみると、私たちは人間の判断についても似たような状況を経験してきました。レビューの場で、ベテラン技術者から「その設計は危ない」と指摘されることがあります。その指摘は正しい場合が多いのですが、理由を聞くと、「以前、似たような案件で問題になった」「経験上、そのやり方はうまくいかないことが多い」といった説明になることも少なくありません。人間の判断もまた、完全に説明可能なものではありません。AIによって新しい問題が現れたというより、これまでも存在していた「判断の根拠」という課題が見えやすくなったのかもしれません。AIとの壁打ちで気付いたこと私の周囲でも、生成AIを使う際に「壁打ち」という言葉をよく耳にします。AIへ質問を投げ、自分の考えを整理しながら回答を改善していく使い方です。実際、この方法は非常に有効です。最初は曖昧だった考えが徐々に整理され、自分でも気付いていなかった論点が言語化されていきます。しかし一方で、AIとの壁打ちを重ねて自信を持って提出した成果物が、レビューであっさり否定されることもあります。むしろ、そのような経験の方が多いかもしれません。なぜでしょうか。それは壁打ちの出発点が常に自分だからです。AIとの対話は、自分の考えを深めることには適しています。しかし、自分が持っていない見方を発見することには限界があります。壁打ちは思考を深くしますが、必ずしも広くしてくれるわけではないのです。AIを使う中で私が強く感じたのは、良い答えを得るためには、良い知識以上に良い判断軸が必要だということでした。技術継承におけるレビューの本当の価値ここで改めてレビューの役割を考えてみます。前回、レビューは本来技術継承の場であったと述べました。現在のレビューは、記載漏れや規約違反の確認に重点が置かれることも少なくありません。しかし本来の価値はそこだけではありません。レビューの本質は、自分が持っていない見方と出会うことにあります。例えば、開発者は性能を見る。運用担当者は障害対応を見る。保守担当者は将来の変更容易性を見る。利用者は使いやすさを見る。それぞれ違う経験を持ち、違う切り口で成果物を見ています。だからこそ、一人では気付けない問題が見つかります。レビューについて議論する中で、「開発メンバだけによるレビューには限界がある。運用担当者や品質保証担当者、利用者など、異なる立場の人が参加することで初めて見えてくる課題もある」という考え方を耳にしたことがあります。当時はその重要性を十分理解できていませんでした。しかし今振り返ると、その本質は品質確認そのものではなく、多様な立場からの見方にあったように思います。レビューとは誤りを探す活動だけではありません。それぞれが持つ経験や着眼点を持ち寄り、自分一人では見えていなかった問題や課題に気付く活動でもあるのです。技術継承のために判断の背景を残すでは、そうした見方や考え方をどのように残していけばよいのでしょうか。必ずしも新しいツールや大掛かりな仕組みが必要なわけではありません。例えば設計書やレビュー記録に、「理由・根拠」欄を設けるだけでも状況は大きく変わります。多くのレビュー記録には、指摘事項対応内容承認結果は残っています。しかし、なぜその方式を選んだのかどのような代替案を検討したのか何を重視して判断したのかといった情報は残らないことが少なくありません。例えば、以下の記載例のように、理由・根拠を一言記録するだけでも、その価値は大きく変わります。【記載例】決定事項Redisによるキャッシュ方式を採用理由・根拠非同期処理も検討したが、即時応答を優先するためキャッシュ方式を採用した。更新頻度が比較的低いことも判断材料とした。後から参画した開発者は、採用された答えだけではなく、その背景にある考え方も理解できるからです。もちろん、これだけで十分というわけではありません。レビュー観点表やチェックシートを整備している現場は少なくありませんが、運用次第では単なる確認作業になってしまうこともあります。確認項目を一覧化することと、その背景にある考え方を理解することは同じではないからです。なぜその確認が必要なのか。どのような失敗や経験から生まれたものなのか。その背景まで共有されて初めて、本当の意味で技術継承につながります。しかし、その第一歩は判断や考え方を言語化し、残していくことだと思います。技術継承とは何を継承することなのか前回のコラムでは、「技術は成果物だけでは継承されない」という話をしました。今回さらに考えてみると、継承すべきものは知識やノウハウだけではないように思えてきます。近年では、ソフトウェア開発に限らず、様々な分野でベテラン技術者や熟練工のノウハウをAIへ残そうという取り組みも進んでいます。例えば設備保全の現場で、「この音がしたらベアリング交換だ」という熟練者の経験をAIへ学習させることは可能かもしれません。しかし本当に価値があるのは、その結論だけではありません。なぜ異常だと判断したのか。何を聞き分けていたのか。他にどのような兆候を確認していたのか。そうした判断の背景や着眼点まで残せて初めて、技術継承として意味を持ちます。これはソフトウェア開発における設計判断とも本質的には同じです。もちろん知識は重要です。しかし知識だけでは、新しい問題には対応できません。本当に価値があるのは、どのような前提を確認するのか何を疑うのかどのような見方で捉えるのかどのように判断するのかという考え方です。つまり継承すべきものは、答えそのものではなく、それを導き出した判断の背景や見方なのではないでしょうか。技術継承とは、次の世代が自ら判断できる状態を作ることです。そのためには、結論だけではなく、なぜそう考えたのかどのような選択肢を比較したのか何を重視したのかを残していく必要があります。まとめ前回のコラムでは、技術継承が進まない原因を開発の構造という観点から整理しました。今回のコラムでは、技術継承とは何を引き継ぐことなのかを改めて考えてみました。AIとの対話や人とのレビューを通じて見えてきたのは、技術継承の本質は知識や答えを残すことではなく、判断軸を残すことだということです。生成AIは多くの知識や答えを提供してくれます。しかし、何を問うべきか、どのような見方で物事を捉えるべきかといった判断軸までは与えてくれません。本当に重要なのは、何を見て、何を疑い、どのように判断するのかという考え方や観点を受け継ぐことです。技術を残すとは何を残すことなのか。もちろん、知識や答えを残すことは重要です。しかし、本当に継承したいのは、それらを生み出した人たちの考え方や観点なのではないでしょうか。次の世代が自ら考え、判断できるようになる。技術継承の本質は、そのための土台を残すことにあるように思います。おわりに今回のコラムでは、技術継承の本質は知識や答えを引き継ぐことではなく、それらを生み出した判断の背景や観点を引き継ぐことにあるのではないか、という考えをお伝えしました。しかし、判断の背景や観点は、単に「残そう」と呼びかけるだけではなかなか組織に定着しません。実際には、レビューの場が形骸化している判断理由が成果物に残っていないベテランの知見が属人化している技術継承を進めたいが、何から着手すればよいか分からないといった課題を抱える組織も少なくありません。当社では、開発プロセスやレビューの進め方、ナレッジ共有の仕組みづくりなど、技術継承を支えるプロセス改善をご支援しています。「技術継承が人に依存している」「ベテランの退職が近づき不安を感じている」「AIを活用しながら知見を組織に残したい」そのような課題をお持ちでしたら、ぜひご相談ください。当社はプロセス改善の専門家として、技術継承が自然に行われる仕組みづくりをご支援します。知識や成果物だけでなく、判断の背景や観点まで組織の資産として残せるプロセスを共に考えていきます。（安部宏典）

新サービス「アセッサー育成プログラム」提供開始のお知らせ

平素より格別のご愛顧を賜り、誠にありがとうございます。このたび当社では、Automotive SPICEに対応したアセスメント人材の育成と、お客様自身による継続的なプロセス改善を支援する新サービスとして、「アセッサー育成プログラム」の提供を開始いたしました。2つのサービスをご提供いたします。社内アセッサー育成プログラムリードアセッサー育成プログラムアセッサー育成プログラムに込めた想いAutomotive SPICEへの対応において、アセスメントは単に顧客要求を満たすための審査ではありません。自社の開発プロセスの状態を客観的に把握し、本質的な課題を明らかにしたうえで、継続的な改善につなげるための重要な活動です。一方で、アセスメントやプロセス改善を外部の専門家に依存している場合、活動を通じて得られた知識や経験が社内に十分に蓄積されず、改善が一時的な取り組みにとどまってしまうことがあります。私たちは、開発現場を理解する人材がアセッサーとして自ら考え、評価し、改善を推進することが、組織のプロセス成熟度を高めるうえで重要であると考えています。社内アセッサーとしてアセスメントに取り組むことで、Automotive SPICEというグローバルスタンダードを学ぶだけでなく、自社の開発プロセスを改めて理解し、世界標準とのギャップを認識できます。その過程で得られる知識、判断力、インタビュー経験は、座学だけでは身につけることのできない実践的な能力です。さらに、社内アセッサーとして経験を積んだ人材や、intacs公認のプロビジョナルアセッサー資格を保有する人材が、公式アセスメントを主導できるリードアセッサーへと成長することで、社内におけるアセスメントとプロセス改善の推進力を一層高めることができます。リードアセッサーに求められるのは、Automotive SPICEの知識や評定技術だけではありません。プロジェクトの実態を正しく把握し、関係者との対話を通じて本質的な課題を明らかにするとともに、アセスメントチームをまとめ、組織をより良い方向へ導く力が必要です。私たちは、単に資格を取得することをゴールとは考えていません。育成されたアセッサーが社内で継続的に活躍し、次のアセッサーを育て、改善の知識と経験を組織全体へ広げていくことを目指しています。外部に依存するアセスメントから、自社で考え、評価し、改善を主導する体制へ。アセッサー育成を通じて、お客様の組織に継続的な改善の文化を根づかせることが、私たちの提供するアセッサー育成プログラムの価値です。提供サービス■ 社内アセッサー育成プログラムAutomotive SPICEに対応したプロセス改善を、社内で自律的に推進するための人材育成プログラムです。実際の内部アセスメントを通じて、アセスメントの計画、インタビュー、評価、報告に必要な実践力を身につけます。社内アセッサーを中心とした継続的な改善体制を構築し、組織のプロセス成熟度向上と顧客対応力の強化を支援します。 ■ リードアセッサー育成プログラム社内アセッサーとして経験を積んだ方、またはintacs公認のプロビジョナルアセッサー資格を保有する方を対象に、公式アセスメントを主導できるリードアセッサーを育成するプログラムです。公式アセスメントへの参加を通じて、アセスメントチームの運営、インタビュー、評定の取りまとめ、結果報告などの実践力を養い、コンピテントアセッサー資格の取得を支援します。アセッサー育成プログラムの詳細については、こちらのページをご覧ください。今後も当社は、アセッサー人材の育成とプロセス改善に関する知見を活かし、お客様が自ら考え、評価し、改善を継続できる組織づくりを支援してまいります。Automotive SPICEへの対応、社内のプロセス改善体制の構築についても、ぜひお気軽にお問い合わせください。

新着情報

B'zine 2026年9月号（Automotive SPICE v4.０から v4.1への変更点について等）を発行しました

テスト文書に迷ったらISO 29119を参考にしよう

Automotive SPICEが生んだ悪しき習慣 ～構成管理編～

Automotive SPICE：問題の本質を解くシリーズ ～レビュー編～