Updates
平素は格別のご愛顧を賜り、心より御礼申し上げます。 この度、弊社は厚生労働大臣より「労働者派遣事業」の許可を取得いたしましたのでお知らせいたします。 これにより、従来の契約形態（業務委託など）に加え、より柔軟で幅広い人材ソリューションのご提案が可能となります。これまで以上に法令遵守（コンプライアンス）を徹底し、労働者の皆様が安心して働ける環境づくりと、企業の皆様の多様な人材ニーズに応える最適なサービスの提供に努めてまいります。 今後とも変わらぬご愛顧を賜りますよう、何卒よろしくお願い申し上げます。 許可年月日：令和８年６月１日許可番号：派１２ - ３０１８２８
第9回無料Webinar「AI時代のQA（品質保証活動）とは何か？」で使用した資料を公開しました。下記、フォームにご記入の上ダウンロードしてください。 本来求められる品質保証活動 なぜ監査しかできていないのか AIで監査を自動化する 本来の品質保証活動へ セッションタイムアウトまでの時間が短いため、ダウンロードリンク表示後速やかにダウンロードしてください。当日の動画も公開しておりますので、こちらもご参照ください。
第9回無料Webinar「AI時代のQA（品質保証活動）とは何か？」のアーカイブ動画をYouTubeに公開しました。▶Webinar動画はこちら（YouTube）https://youtu.be/4F0qgDGjTKo00:00 プレゼンター紹介・アジェンダ紹介02:55 本来求められる品質保証活動 17:56 なぜ監査しかできないのか 22:59 AIで監査を自動化する 33:44 本来の品質保証活動へ 51:42 まとめ 54:18 Q&A ■このWebinarで扱っているテーマ皆さまご存じの通り、近年生成AIの活用が急速に進んでいます。それに伴い、品質保証活動（QA）の役割も変化しています。本Webinarでは、「確認するQAから判断するQAへ」をテーマに、AI時代に求められる品質保証活動のあり方について解説しています。■このWebinarで学べること AI時代におけるQAの役割変化 確認作業から判断業務へのシフト リスク分析と意思決定支援の重要性■こんな方におすすめ 品質保証部門の担当者 開発責任者・プロジェクトマネージャー Automotive SPICE推進担当者■AI時代に求められるQAとは生成AIの普及により、従来のレビューやチェック業務は効率化が進んでいます。その結果、QAにはより高度な判断力が求められるようになっています。■関連記事品質保証活動に関連する記事は、コラムや導入事例としても掲載しております。ぜひあわせてご確認ください。 Automotive SPICE SUP.1 本当に品質は良くなるの？ システム／ソフトウェア開発に品質保証活動は必要なのか？ 車載システム開発における品質保証の進化 導入事例：品質保証活動の刷新 ※当日の投影資料は、近日中に弊社HPの「White Paper」にてダウンロード可能となる予定です。準備が整い次第ご案内いたします。 ぜひご視聴ください。
Automotive SPICE 入門一般開催（７月分）の日程をご案内いたします。詳細およびお申込みは、下記リンクあるいは「イベント開催日程」からお願いいたします。 Automotive SPICE 超入門2026年7月9日詳細はこちらからAutomotive SPICE 入門 管理支援編2026年7月15日詳細はこちらからAutomotive SPICE 入門 システムエンジニアリング編2026年7月16日詳細はこちらからAutomotive SPICE 入門 ソフトウェアエンジニアリング編2026年7月23日詳細はこちらからAutomotive SPICE 入門 ハードウェアエンジニアリング編2026年7月29日詳細はこちらから Teamsを使ったオンラインでの開催となります 教材は、原則開催日の５日前までにご指定場所に郵送いたします ご請求書はPDF版をメールで送付いたします お支払い期日は、ご請求書発行日の翌月末となります ご請求書発行後のキャンセルは、お断りしています（代理出席などの手配をお願いします） お申込者以外の方の聴講および録音は固く禁じます
B'zine ５月号を発行いたしました。ショート動画も公開していますので、弊社公式YouTubeより是非ご視聴ください。 B'zineは、１回/月のペースでの配信しています。ご興味のある方は、ここから登録をお願いいたします。 B'zineビジネスガレージ通信（2026年5月号） B’zine ビジネスガレージ通信（2026年5月号） お届けします。今年のゴールデンウィークは天候が安定せず、予定していた行楽を断念された方もいらっしゃったのではないでしょうか？また、ゴールデンウィーク後は断続的な真夏日と３月並み気温の訪れや関東地方の梅雨入りも控えており、体調管理には十分ご留意ください。 【今月のトピックス】 イベント：５月２８日（木）第９回Webinar開催：AI時代のQA（品質保証活動）とは何か？～ 人が行うQA、AIが行うQAを考える ～ イベント：人手運用から脱却する構成管理DX〜 現場を救う構成管理ロボの導入事例 〜（2026年7月開催予定） イベント：Automotive SPICE 入門一般開催トレーニング（6月開催）のご案内 コラム：Automotive SPICE 能力レベル３とは何か？ それは「プロセスの話」だけではない（後編） コラム：日本の車載ソフトウェア開発では、何故いまだにDRBFMが使われているのか（前編） YouTube：Automotive SPICE レベル3を“現場視点”で解説する動画コンテンツを公開 【イベント】 2026年5月28日 Webinar：AI時代のQA（品質保証活動）とは何か？～ 人が行うQA、AIが行うQAを考える ～生成AIをはじめとした技術の進展により、開発環境や仕事の進め方は大きく変わりつつあります。それに伴い、QA（品質保証活動）やQAグループに求められる役割や価値についても、見直す必要があるのではないでしょうか？本webinarでは、AI活用そのものを目的とするのではなく、AI時代にQAやQAグループが担うべき役割や価値を改めて整理します。１．期待されているQAとは２．現状の品質保証グループが抱える構造的な課題３．AIが得意なQA領域／人が担うべきQA領域４．AI時代におけるQAモデルの考察日時：2026年5月28日（木）16:00 - 17:00詳細、お申し込みはこちらから→https://www.bgarage.co.jp/event/1930/ 2026年7月Webinar（予定）：人手運用から脱却する構成管理DX〜 現場を救う構成管理ロボの導入事例 〜人手で行われがちな構成管理や文書管理の運用を、Power Platform （PowerApps, PowerAutomate）とSharePointを活用して、効率化・自動化する実践事例を紹介します。採番はPowerApps、台帳登録はPowerAppsとSharePoint、バックアップはSharePointとPowerAutomateを組み合わせて、日常業務をどのように改善できるのか、現場視点で分かりやすく解説します。Automotive SPICE SUP.8（構成管理）の要求事項も考慮しましたので、ライトなSUP.8対応が可能となっております。詳細は、B'zine 6月号でお知らせします。 Automotive SPICE 入門一般開催トレーニング（6月開催）のご案内Automotive SPICE 入門一般開催（6月分）の日程をご案内いたします。詳細およびお申込みは、下記リンクあるいは「イベント開催日程」からお願いいたします。Automotive SPICE 超入門 2026年6月10日Automotive SPICE 入門 管理支援編 2026年6月12日Automotive SPICE 入門 システムエンジニアリング編 2026年6月17日Automotive SPICE 入門 ソフトウェアエンジニアリング編 2026年6月25日Automotive SPICE 入門 ハードウェアエンジニアリング編 2026年6月24日詳細、お申し込みはこちらから→https://www.bgarage.co.jp/event/1949/ 【コラム】 Automotive SPICE 能力レベル３とは何か？ それは「プロセスの話」だけではない（後編）前編では、能力レベル3の本質が「プロセス定義」だけではなく、People・Process・Technology を通じて組織として改善が回り始める状態にあること、そしてAutomotive SPICE（以下、A-SPICE）の文脈では、なぜその本質が見えにくくなってきたのかを整理してきた。後編では、その理解を前提として、能力レベル3の先に位置づけられるレベル4・5が何を意味するのか、さらにそれが事業運営や競争力とどのようにつながっていくのかを考えてく。詳細はこちら→https://www.bgarage.co.jp/news/1969/ 日本の車載ソフトウェア開発では、何故いまだにDRBFMが使われているのか（前編）〜生産性向上と品質維持に向けた提言〜日本の車載ソフトウェア開発では、DRBFM（Design Review Based on Failure Mode）が当然のように使われている。これは筆者にとって、驚き以外の何ものでもない。そもそもDRBFMは、「機械部品」の設計変更や環境変化に伴うリスクを洗い出すために生まれた手法である。「ボルトの径を変えた」、「材質を変えた」、「使用条件が変わった」。そうした物理的な変化点を起点に、摩耗や破断といった実体のある故障モードを徹底的に深掘りすることに、その本質的な価値があった。ではなぜ、その手法がソフトウェア開発に使われ続けているのか。なぜ「コード一行の変更」を、「機械部品の設計変更」と同じ発想で扱わなければならないのか。この問いに、工学的に納得できる明確な説明を聞いたことがない。実際の開発現場では、今もなお多くの技術者が相当な時間と労力をかけてDRBFMを実施している。「故障モードを〇〇個出せ」「もっと深掘りできるはずだ」「宇宙線によるビット反転が起きたらどうするのか」。そうした指摘が飛び交い、現実にはほとんど起こらない事象まで含めて、延々と議論が続く。DRBFMは、本来の「変更点に着目した検討」という枠を超え、起こるかどうか分からない最悪事象を列挙する儀式になってしまっているのではないだろうか。詳細はこちら→https://www.bgarage.co.jp/news/1965/ 【YouTube】 Automotive SPICE レベル3を“現場視点”で解説する動画コンテンツを公開当社では、Automotive SPICEに関する知見を発信する取り組みとして、ショート動画シリーズの配信を開始しました。本シリーズは、「Automotive SPICE 能力レベル３とは何か？ ― それは『プロセスの話』だけではない」の記事内容をベースに、現場での実践を踏まえて再構成したものです。単なるモデル解説ではなく、・なぜ形式的な適用では評価につながらないのか・レベル3で問われる実態とは何か・組織として達成すべき状態とは何かといった観点から解説しています。現在3本を公開しており、今後もシリーズとして継続予定です。Automotive SPICEの導入・改善に取り組まれている方は、ぜひご覧ください。詳細はこちら→https://www.bgarage.co.jp/news/2010/
当社では、Automotive SPICEに関する知見を発信する取り組みとして、ショート動画シリーズの配信を開始しました。本シリーズは、「Automotive SPICE 能力レベル３とは何か？ ― それは『プロセスの話』だけではない」の記事内容をベースに、現場での実践を踏まえて再構成したものです。前編：Automotive SPICE 能力レベル３とは何か？ ー それは「プロセスの話」だけではない （前編） - ビジネスガレージ株式会社後編：Automotive SPICE 能力レベル３とは何か？ ー それは「プロセスの話」だけではない （後編） - ビジネスガレージ株式会社 単なるモデル解説ではなく、・なぜ形式的な適用では評価につながらないのか・レベル3で問われる実態とは何か・組織として達成すべき状態とは何かといった観点から解説しています。 現在3本を公開しており、今後もシリーズとして継続予定です。Automotive SPICEの導入・改善に取り組まれている方は、ぜひご覧ください。
１．なぜ、車載ソフトウェア開発にDRBFMが使われているのか日本の車載ソフトウェア開発では、DRBFM（Design Review Based on Failure Mode）が当然のように使われている。これは筆者にとって、驚き以外の何ものでもない。そもそもDRBFMは、「機械部品」の設計変更や環境変化に伴うリスクを洗い出すために生まれた手法である。「ボルトの径を変えた」、「材質を変えた」、「使用条件が変わった」。そうした物理的な変化点を起点に、摩耗や破断といった実体のある故障モードを徹底的に深掘りすることに、その本質的な価値があった。 ではなぜ、その手法がソフトウェア開発に使われ続けているのか。なぜ「コード一行の変更」を、「機械部品の設計変更」と同じ発想で扱わなければならないのか。この問いに、工学的に納得できる明確な説明を聞いたことがない。実際の開発現場では、今もなお多くの技術者が相当な時間と労力をかけてDRBFMを実施している。「故障モードを〇〇個出せ」「もっと深掘りできるはずだ」「宇宙線によるビット反転が起きたらどうするのか」。そうした指摘が飛び交い、現実にはほとんど起こらない事象まで含めて、延々と議論が続く。DRBFMは、本来の「変更点に着目した検討」という枠を超え、起こるかどうか分からない最悪事象を列挙する儀式になってしまっているのではないだろうか。 あまりに負担が大きいため、「ここまでやる必要が本当にあるのだろうか？」と疑問を投げかけると、返ってくる答えは、ほぼ決まっている。「上司の指示だから」、「会社のルールだから」。そこには、技術的な必然性よりも、慣習や前例を優先する空気が色濃く見て取れる。技術革新のスピードは年々加速し、開発は急速にグローバル化している。各国のエンジニアが分業し、並列に開発を進めることが当たり前になった現在、このような開発スタイルを続けていて、本当に日本製品の優位性は保てるのだろうか。ソフトウェアが車の価値を決め、ソフトウェアの開発スピードが競争力の源泉になるSDV時代において、「ソフトウェアの変更点を人間が集まって延々と深掘りする」という方法論は、生産性・品質の両面で限界に達していると筆者は考えている。問題は、個々の技術者の能力や意識ではない。前提としている開発思想そのものが、すでに時代と乖離し始めているのである。 本コラムで扱おうとしているテーマは、いわば「触れてはいけない」とされがちな領域である。日本の車載ソフトウェア開発において長年 “当たり前” として受け入れられてきたDRBFMを、工学的・構造的な視点から問い直すことは、少なからず反発を招く話でもある。しかし、この違和感に目をつぶり続けたままでは、議論はいつまで経っても現場の苦労話や精神論に留まり、何も変わらない。そこで今回は、この問題に正面から踏み込むため、あえて前編・後編の二部構成という形を取ることにした。 前編では、なぜソフトウェア開発においてDRBFMがここまで重く運用されるようになったのか、その技術的背景と、日本特有の開発文化・構造を整理する。現場で起きている「無限の深掘り」による疲弊が、個々の技術者の問題ではなく、どのような前提の上に生まれているのかを明らかにしていく。そして後編では、視点を一度外に移し、世界では同じ課題にどう向き合っているのか、なぜDRBFMがソフトウェア開発で使われていないのかを見ていく。その上で、この先どの地点を目指すべきなのかを考えたい。これは手法の是非を問う話ではない。日本の車載ソフトウェア開発が、これからも競争力を持ち続けるために、何を疑い、何を変えるべきかを考えるための議論である。 ２．DRBFMは本来ハードウェアの手法だった — メカ開発の成功体験が生んだミスマッチ前章では、ソフトウェア開発の現場でDRBFMが儀式化し、技術者を疲弊させている実態を見てきた。では、なぜそもそもこのような違和感が生じるのか。その答えは、DRBFMという手法のルーツにある。DRBFM（Design Review Based on Failure Mode）は、その名の通り「故障モード」を起点として設計変更のリスクを洗い出す手法である。そして重要なのは、この手法が機械部品を中心としたハードウェア開発のために生まれたという事実だ。 ハードウェアの世界では、DRBFMは極めて合理的に機能する。ボルトの径を細くした、材質を変えた、使用温度範囲が広がった。そうした「変化点」から、摩耗、クラック、破断、漏れといった物理的な故障モードを因果関係として追っていくことができる。部品は実体を持ち、力の流れや劣化のメカニズムも説明可能だ。この世界では、「どこまで深掘りすべきか」は明確であり、深掘りそのものが品質向上に直結する。 一方、ソフトウェアはまったく異なる性質を持つ。ソフトウェアには摩耗も劣化もない。故障の正体は、ほぼ例外なく設計ミス、すなわちバグである。「なぜ壊れたのか」を物理現象として説明できるハードウェアと違い、ソフトウェアの不具合は論理の誤り、前提の勘違い、仕様の曖昧さ、考慮漏れといった人間の思考に起因するものだ。 この本質的な違いを無視したまま、ハードウェア由来のDRBFMをソフトウェアに適用すると、問題が生じる。物理部品のDRBFMでは意味を持っていた「深掘り」が、ソフトウェアでは行き場を失うからだ。変数の型変更、条件分岐の追加、タイミングの微調整など、こうした変更点から「どの段階まで故障モードを掘り下げるべきか」を、物理的な根拠なしに決めることはできない。結果として、ソフトウェアDRBFMでは次のような現象が起きる。論理的にはあり得るが、確率的には極めて低い事象までが同列に扱われる。最終的には「宇宙線によるビット反転」や「OSの内部不具合」といった、設計者が制御不能な領域にまで議論が及ぶ。ハードウェアであれば「そこから先は部品設計や材料特性の問題」として切り分けられていた議論が、ソフトウェアでは切り分けられないままDRBFMの中に押し込まれてしまう。 本来、こうした問題の解決はソフトウェアアーキテクチャの役割である。エラー検知、フェイルセーフ、リカバリーの設計によって、「起きても安全に処理できる」状態を構造として担保するべき領域だ。しかし、アーキテクチャという抽象的な仕組みへの信頼が十分に確立されていない場合、その代替として「とにかく心配事を洗い出す」DRBFMが肥大化していく。ここで強調しておきたいのは、DRBFMそのものが悪いわけではない、という点である。DRBFMは本来、ハードウェア開発において大きな成果を上げてきた優れた手法だ。問題は、その成功体験をほぼ無批判にソフトウェアへと移植し、本質的な違いを考慮せずに運用してきたことにある。ソフトウェア開発におけるDRBFMは、ハードウェアの作法をそのまま当てはめた結果、生まれたミスマッチの産物と言える。そしてこのミスマッチこそが、現場で語られる「終わらない深掘り」「何のためのレビューなのか分からない」といった違和感の正体なのである。 では、なぜ日本の車載ソフトウェア開発では、このミスマッチを抱えたままDRBFMが使われ続けてきたのか。次章では、その背景にある日本特有の設計文化と意思決定構造について掘り下げていく。 ３．なぜ日本の車載ソフトウェアではDRBFMが生き残ったのか － すり合わせ文化とハード主導の設計思想前章で見てきたように、DRBFMは本来ハードウェア開発のための手法であり、ソフトウェア開発と相性が良いとは言えない。それにもかかわらず、日本の車載ソフトウェア開発では、DRBFMが長年にわたって当然のように使われ続けてきた。この背景を説明するために、「DRBFMの優劣」や「現場の努力不足」に話をすり替えてはいけない。ここで問うべきなのは、なぜ日本の開発現場では、この違和感を抱えたままでもDRBFMに頼らざるを得なかったのかという点である。ハード屋とソフト屋の「共通言語」としてのDRBFM日本の自動車メーカーでは、長年にわたってハードウェア中心の開発が行われてきた。品質保証、設計審査、意思決定の枠組みも、その多くはハードウェア開発で成功した方法論をベースに構築されている。その中でDRBFMは、「変更点に着目してリスクを洗い出す」という分かりやすい思想を持つ、極めて都合の良い共通言語だった。メカ設計者にも、電気設計者にも、そしてソフトウェア設計者にも、「今回どこを変えたのか」「それによって何が起き得るのか」を同じフォーマットで説明させることができる。本来であれば、ソフトウェアの機能や品質は要求仕様書やアーキテクチャ設計書を通じて説明されるべき存在だ。しかし、それらのドキュメント文化が十分に整備されていない環境では、DRBFMが部門を超えた意思疎通のための代替手段として機能してしまう。結果として、DRBFMは品質手法というよりも、「みんなが理解できる説明の形式」として定着していったのではないか。意思決定層がハード出身であるという構造的問題もう一つ無視できないのが、意思決定層のバックグラウンドである。日本の自動車開発において、開発責任者や品質保証部門の多くは、長年ハードウェア開発に携わってきた人たちである。彼らにとって、DRBFMは「品質を作り込むための正統な手法」であり、それによって数多くの成功体験を積み重ねてきた。一方で、ソフトウェアアーキテクチャや自動テスト、CI/CDといった概念は、必ずしも直感的に理解しやすいものではない。その結果、意思決定の場ではどうしても、「目に見える」「議論できる」「紙に書ける」DRBFMが重視される。ソフトウェア側が「アーキテクチャで担保している」と説明しても、それが完全には信用されず、「ではDRBFMで確認しよう」という結論に落ち着きやすい構造が生まれてしまう。「ネジ一本」と「コード一行」を同列に扱う設計変更思想車載ソフトウェアが問題をさらに複雑にしているのは、ソフトウェアがすでに車の中核機能を担っているという事実である。ブレーキ、ステアリング、パワートレイン制御など、「走る・曲がる・止まる」の多くがソフトウェアによって制御されている。このため、「ネジ一本を変えること」と「コード一行を変えること」を同じ重みの「設計変更」として扱わなければ危険だ、という考え方が強く根付いた。安全を最優先するという点では、この思想自体は理解できる。しかしその結果、ソフトウェア開発が本来前提としている「アーキテクチャによる影響範囲の局所化」、「テスト自動化による回帰検証」、「反復的な変更を許容する開発スタイル」といった要素が十分に考慮されないまま、「変更したのだから徹底的に不安を潰すべきだ」という発想だけが肥大化していった。 リコールコストという「恐怖」が生んだ過剰な保守性このような構造の背景には、車載開発特有の“恐怖”もある。一度市場に出た製品で不具合が見つかれば、数百万台規模のリコールにつながり、企業に甚大な損失をもたらす。この失敗コストの大きさが、「万が一を見逃すより、やり過ぎる方が安全だ」という判断を正当化してきた。そしてDRBFMは、その「やり過ぎ」を制度として固定化するための、極めて都合の良い枠組みだった。結果としてDRBFMは、リスクを減らすための工学的手法というよりも、 これだけやったのだから大丈夫だと言える材料 誰か一人の判断にしないための責任分散装置としての性格を強めていったのである ここまで見てきたように、DRBFMが日本の車載ソフトウェア開発に生き残ったのは、偶然ではない。文化、組織、意思決定構造、そして恐怖――それらが絡み合った結果として、DRBFMは“必要不可欠なもの”に見える存在へと変質していった。そしてこの構造の帰結として、現場には「どこまで深掘りすれば終わるのか分からない」DRBFMが残ることになった。 次章では、その象徴的な姿である「無限深掘り」という地獄について、さらに踏み込んでいく。 ４．ソフトウェアDRBFMが生む「無限深掘り」という地獄前章までで見てきたように、DRBFMは本来ハードウェア開発の文脈で成立してきた手法であり、日本の車載ソフトウェア開発では、その前提が十分に吟味されないまま持ち込まれてきた。その結果として現場に現れるのが、多くの技術者が口を揃えて語る「終わらないDRBFM」、すなわち無限深掘りという状態である。この無限深掘りは、単なる運用ミスや一部現場の暴走ではない。ソフトウェアという対象と、DRBFMという手法の組み合わせがもたらす構造的な帰結である。ハードウェアDRBFMとソフトウェアDRBFMの決定的な違いハードウェア開発におけるDRBFMでは、「深掘り」は品質向上に直結する行為だ。ボルトの径を細くする、材質を変える、使用条件を厳しくする。そうした変化点から、応力集中、疲労、破断といった故障モードを因果関係として追っていくことができる。物理現象に基づくため、「どこまで掘れば十分か」という判断にも、経験則や工学的裏付けが存在する。 一方、ソフトウェアにはこのような「物理的な終点」が存在しない。条件分岐の変更、変数型の変更、タイミング調整といった変更点から不具合を想像することはできるが、その連鎖は理論上いくらでも続いてしまう。ハードウェアDRBFMでは、「そこから先は現実的に起こらない」と線を引ける。しかしソフトウェアDRBFMでは、「理論上は起き得る」という一言で、議論を次の階層へ進めることができてしまう。この違いこそが、ソフトウェアDRBFMを終わりのない作業へと変質させる最大の要因である。 なぜ「何段階まで深掘りするのか」が決まらないのかソフトウェアDRBFMが最も苦しいのは、「どこで止めるべきか」を判断する共通基準が存在しない点にある。ハードウェアであれば、材料強度、設計マージン、規格といった形で、深掘りを打ち切るための工学的根拠が共有されている。しかしソフトウェアでは、「アーキテクチャで影響は限定されている」「この層でフェイルセーフする」といった説明が、必ずしもレビューの場で十分な納得材料として機能しない。結果として、「ではそれが壊れたらどうなるのか」「もし検知できなかったらどうするのか」という問いが繰り返され、議論は自然に次の階層へと進んでいく。問題は、この問い自体が論理的には正しいことだ。完全に間違っていないがゆえに、誰も「そこまでで十分だ」と言い切ることができず、深掘りを止める責任を取りたがらない。こうしてDRBFMは、不安が完全になくなるまで続けるべき検討へと変質していく。 宇宙線・ビット反転問題が象徴する「議論の暴走」ソフトウェアDRBFMの象徴的なトピックとして、しばしば持ち出されるのが「宇宙線によるビット反転」である。車載環境においてソフトエラーが実際に発生することは事実であり、この現象そのものを否定することはできない。しかし、この話題がDRBFMの場に登場した瞬間、議論の性質は変わる。それはもはや「今回の設計変更による影響」を検討する場ではなく、「このシステムは絶対に壊れないと言えるのか」という問いへとすり替わる。 ビット反転が起きたらどうするのか。 検知できなかったらどうなるのか。 検知機構自体が壊れたらどうなるのか。これらの問いは理論上いくらでも連鎖し、しかも設計担当者が直接制御できない領域へと踏み込んでいく。にもかかわらず、それらがDRBFMという枠組みの中で同一平面に並べられることで、現場には「どこまで考えれば許されるのか分からない」という疲弊だけが残る。 本来アーキテクチャで解決すべき問題まで、DRBFMに押し込めている現実ここで本来問われるべきなのは、役割分担である。宇宙線やランダムエラーへの対処は、個別機能のDRBFMで毎回検討すべき話ではない。それはプラットフォームやアーキテクチャの責務として、一度決めた前提のもとで扱われるべき問題だ。ソフトウェア開発が本来前提としているアーキテクチャによる影響範囲の局所化、テスト自動化による回帰検証、そして反復的な変更を許容する開発スタイルが十分に信頼されていれば、DRBFMが無限に深掘りされることはない。しかしその前提が共有されていない、あるいは信用されていない場合、あらゆる不安がDRBFMという一枚の表に集約される。アーキテクチャで扱うべき話も、運用ルールとして決めるべき話も、最終的には「DRBFMで説明してください」という形で押し戻されてしまう。こうしてDRBFMは、本来の役割である「変更点に着目した設計レビュー」を超え、あらゆる不確実性を一度の会議で解消しようとする万能装置になってしまう。結果として残るのは「終わらせたという安堵感」と引き換えに失われた膨大な時間だけである。 ここまで見てきたように、ソフトウェアDRBFMが「無限深掘り」という地獄に陥るのは、現場の技術者が未熟だからでも、真面目さが足りないからでもない。それは、ハードウェア起点で生まれた手法を、性質の異なるソフトウェアに適用し続けてきた結果として、ほぼ必然的に生じた現象である。DRBFMは本来、変更点に着目して設計上のリスクを洗い出すための手法だった。しかし日本の車載ソフトウェア開発では、アーキテクチャや工学的な前提への信頼が十分に共有されないまま、あらゆる不安をDRBFMという一つの場に集約しようとしてきた。その結果、DRBFMは「設計レビュー」ではなく、「起こり得るすべてを想像し尽くすための儀式」へと変質してしまったのである。 重要なのは、これはDRBFMそのものの是非を問う話ではない、という点だ。問われているのは、日本の車載ソフトウェア開発が、ソフトウェアをどのような工学対象として捉え、品質と安全性をどのレイヤーで担保するのかという前提そのものである。前編では、日本の車載ソフトウェア開発の内部構造に目を向け、なぜDRBFMがここまで重く運用され、現場を疲弊させる存在になったのかを整理してきた。では、同じ「ソフトウェア」という技術を扱いながら、世界はこの問題にどのように向き合ってきたのだろうか。なぜ車載以外のソフトウェア開発では、DRBFMのような手法が品質保証の中心に据えられることはないのか。そして日本の車載ソフトウェア開発は、この先どの地点を目指すべきなのか。 後編では視点を一度外に移し、グローバルなソフトウェア開発の前提や設計思想を踏まえながら、DRBFMを前提としない品質保証がどのように成立しているのか、そしてDRBFMと距離を取るための現実的な道筋について考えていく。 （日吉 昭彦）
前編では、能力レベル3の本質が「プロセス定義」だけではなく、People・Process・Technology を通じて組織として改善が回り始める状態にあること、そしてAutomotive SPICE（以下、A-SPICE）の文脈では、なぜその本質が見えにくくなってきたのかを整理してきた。前編はこちらから。後編では、その理解を前提として、能力レベル3の先に位置づけられるレベル4・5が何を意味するのか、さらにそれが事業運営や競争力とどのようにつながっていくのかを考えていく。 ５．レベル３はゴールではないーレベル４・５が示す世界能力レベル3は、組織として改善を回し始めるための重要な節目である。しかし、それは決して到達点ではない。むしろ、改善がようやく自律的に回り始めた状態に過ぎない。レベル3に到達した組織では、改善はもはや個々のプロジェクトの工夫に依存するものではなく、組織の仕組みとして回り始める。標準プロセスやプロセス資産が整備され、プロジェクトはそれを前提として運営され、実績は組織に還元される。前編で見てきたのは、まさにこの状態であった。しかし、改善が回り始めることと、組織がどこへ向かって進んでいるかは別の問題である。能力レベル3の段階では、関心の中心は依然として「やり方」にある。どのプロセスを使っているか、標準は守られているか、改善活動が実施されているかといった点が議論の主軸になる。 能力レベル4・5の世界では、この関心の置きどころが変わる。ここで重要なのは、改善がより高度になることではない。組織の視線そのものが変わるという点にある。この視線の違いは、データの使われ方に最も端的に現れる。能力レベル3までにおけるデータの扱いは、主として過去を振り返るためのものである。どのプロセスがうまく機能したのか、どこに問題があったのかを確認し、現状を把握するために用いられる。このデータの使い方は、自動車で言えばバックミラーを見る行為に近い。過去に何が起こったかを確認し、その結果をもとに現在の状況を判断する。 一方、能力レベル4に進むと、データの意味合いが変わる。レベル4では、プロジェクトやプロセスの実行結果が定量的に捉えられ、ばらつきが管理される。品質、工数、納期といった指標が過去の実績と結び付き、組織として「予測可能な状態」に近づいていく。ここでの特徴は、データが単なる記録ではなく、意思決定の材料として使われ始める点にある。この段階でのデータの役割は、バックミラーではなくナビゲーションに近い。過去の実績をモデル化することで、将来どのような結果が起こり得るのかを見通し、その上で進路を選択するために使われる。 さらにレベル5では、そのデータを用いて、組織としてどこを改善すべきか、どこに投資すべきかが議論されるようになる。改善は「現場の工夫」ではなく、組織として選択される活動になる。この段階では、改善テーマがプロジェクトの中だけで完結することはほとんどない。 重要なのは、ここで求められているのが「高度なプロセス技法」ではないという点である。レベル3まではプロセスの設計や運用が議論の中心だったのに対し、レベル4・5では、組織の視線がプロセスそのものから事業成果へと移っていく。改善はもはや目的ではなく、事業を成り立たせ、競争力を維持・強化するための手段として扱われるようになる。 この意味で、能力レベル3をゴールとして捉えてしまうと、組織は改善のやり方を洗練させるところで立ち止まりやすい。一方、能力レベル3を通過点と捉えた組織は、その先で「改善を何のために行うのか」という問いに直面することになる。次章では、この視点の違いが、実際の組織ではどのような差として現れるのかを、具体的な経験をもとに見ていく。 ６．20年後を語る企業と、目の前を語る企業能力レベル4・5が示している本質が、手法や技術の高度化ではなく「組織の視線の向き」であるとすれば、その差はどこに最もはっきりと現れるのだろうか。その一つの答えは、組織が何を語っているか、もう少し言えば、どれだけ先の話をしているかにある。筆者が北米のあるCMMIレベル5企業を訪問したのは、今から20年以上前のことである。先進的なプロセス改善の現場を見る機会を得て、多くの示唆を受けたが、今でも強く印象に残っているのは、プロセスそのものではなく、そこで交わされていた会話の内容である。 その企業では、SEPG（Software Engineering Process Group）に属する人材が、プロセスの話と同じ熱量で、事業の話をしていた。彼らが語っていたのは、「次のプロジェクトをどう回すか」ではなく、「この事業を10年後、20年後にどういう姿にしたいのか」という問いだった。プロセス改善は頻繁に話題に上ったが、それは決して目的ではなかった。改善は、商品競争力をどう高めるか、市場でどのポジションを取るのかといった議論の中に自然に組み込まれていた。プロセスは、事業の意思を実現するための手段として語られていたのである。興味深かったのは、こうした議論を主導していたSEPGのメンバーの多くが、経営学やビジネスの素養を持っていた点である。中にはMBAを取得している人材もおり、プロセスと事業の話を行き来しながら議論することが、ごく自然なこととして行われていた。 一方で、筆者がこれまでに見てきた多くの組織では、状況はかなり異なる。そこでは、SEPGはプロセスを定義し、維持し、評価対応を行う組織として位置づけられることが多い。語られる話題は、「このプロセスで問題はないか」「監査に耐えられるか」「定義が最新か」といったものが中心になる。もちろん、こうした活動自体が無意味なわけではない。前編で述べた通り、能力レベル3までの世界では、これらは不可欠な役割である。しかし、その状態に留まる限り、組織の議論はどうしてもプロセスの内側に閉じてしまう。 ここに、能力レベル3とレベル4・5の間に横たわる大きな断層がある。能力レベル3では、改善は回っている。しかし、その改善がどこへ向かうためのものなのかは、必ずしも明確ではないことが多い。改善は改善として正当化され、「なぜそれをやるのか」という問いは後回しにされがちになる。これに対し、能力レベル4・5の組織では、改善は常に別の問いと結び付けられている。「それは事業にどう寄与するのか」「競争力の源泉になるのか」「投資する価値があるのか」。プロセス改善は、こうした問いに答える一つの選択肢として扱われる。 この違いは、組織文化にも強く影響する。目の前のプロジェクトや、直近の評価結果を語る組織は、通常、改善の視野も短期に留まる。問題があれば対処するが、その積み重ねがどこへ向かうのかは共有されにくい。一方、長期の時間軸で話をする組織では、改善は最初から「積み上げていくもの」として位置づけられる。ここで注目すべきなのは、この差がプロセス技術の巧拙から生まれているわけではないという点である。多くの場合、違いを生んでいるのは、誰が改善を語っているのか、そして何の文脈で語っているのかである。能力レベル4・5に到達した組織では、改善を語るSEPGが、同時に事業の文脈を語ることができる。逆に言えば、改善の議論がプロセスの範囲に閉じている限り、組織は能力レベル3の先に進むことが難しい。 次章では、この問題を個々の人材の能力論としてではなく、組織構造や役割設計の問題として捉え直す。なぜ多くの組織は能力レベル3を維持できず、再びレベル1・2に戻ってしまうのか。一方で、なぜ一度能力レベル4に到達した組織は、その水準を下回ることがほとんどないのか。その違いを考えていく。 ７．プロジェクトフォーカスから、いつ抜け出すのか第6章では、能力レベル4・5に到達した組織の姿を見てきた。そこでは、改善は単なるプロジェクトの成果や品質向上としてではなく、組織や事業の言葉として語られていた。改善は、個々の善意や努力に委ねられる、いわゆるボトムアップ的なものではなく、経営の意図として位置づけられ、組織全体に引き受けられるべき営みとして扱われていた。 では、なぜ多くの組織は能力レベル3に一度は到達したように見えても、それを維持できず、再びレベル1・2に戻ってしまうのか。一方で、なぜ一度能力レベル4以上に到達した組織は、その水準をほとんど下回らないのか。この違いは、個々の人材の能力や現場の頑張りによって生じているものではない。能力レベル3の段階では、フォーカスはすでにプロジェクトから組織に移っている。標準プロセスは整備され、改善活動も行われている。「やっていない」わけではない。それにもかかわらず、能力レベル3は不安定になりがちで、維持されにくい。問題は、改善そのものの量や手法ではなく、改善とどう向き合ってきたか、その向き合い方にある。 日本の組織は、長年にわたり、課題が顕在化してから対処する「課題解決型の改善」に強みを持ってきた。品質問題が発生すれば徹底的に原因を究明し、個別のプロジェクトとしては高い完成度に持っていく。その力は、世界的に見ても極めて高い水準にあった。一方で、A-SPICE や CMMI に代表されるプロセス改善モデルに対して、世界で確立されつつあるベストプラクティスを、そのままの形で学び、自分たちの事業に引き直して引き受けるという向き合い方は、必ずしも強くなかった。これらのモデルは、もともと欧米の研究者が日本の製造業、とりわけ生産方式とカイゼンを徹底的に研究し、曖昧になりがちなノウハウや暗黙知を理論化・形式知化しようとした試みから生まれている。言い換えれば、CMMI や A-SPICE は、「日本のやり方を否定するためのもの」ではなく、日本の強みを世界基準で捉え直し、誰もが再現できる形にするためのグローバル標準として発展してきたものである。 しかし日本では、それらのモデルはしばしば評価対応や要求対応の道具として理解され、プロジェクト単位で真面目に適用されてきた。課題解決型の改善が得意であったがゆえに、目の前の問題に対応することに重心が置かれ、外部で積み重ねられてきた改善の知を、経営として引き受け続けるという営みは、必ずしも中心的な関心にはなりにくかった。その結果、改善は「できる人」「頑張る人」に依存しやすく、組織として守られるものにはならない。忙しさや人事異動、環境変化が起きれば、優先順位は下がり、能力レベル3の状態は容易に崩れてしまう。これは、改善が個人の姿勢や努力に委ねられ、 組織としての役割や責任として設計されていないことを意味している。 一方、能力レベル4以上に到達した組織では、改善は善意や努力に委ねられていない。改善は事業を回し続けるための前提条件として位置づけられ、経営の意思と役割の中に組み込まれている。だからこそ、一度その段階に入ると、元の状態に戻ることがほとんどない。日本の経営者が将来を考えていなかったわけではない。むしろ、日本の自動車産業は長年にわたり、世界的に見ても高い競争力を維持してきた。ただし、その成功体験があまりにも強かったがゆえに、ソフトウェアという分野において世界の最先端がどこまで進んでいるのかと、正面から向き合う必然性が見えにくかったという側面は否定できない。 能力レベル3が維持できない理由は、手法やプロセスが足りなかったからではない。グローバル標準として確立された改善モデルと、経営としてどこまで真剣に向き合い、それを自分たちの事業として引き受ける覚悟があったかどうかにある。 こうした違いを分けているのは、時間でも経験年数でもない。プロジェクトフォーカスから抜け出せるかどうかの分岐点は、経営層が A-SPICE のようなプロセス改善モデルを、評価対応ではなく、事業と組織を設計するためのグローバルスタンダードとして理解し、組織的な活動を自ら主導するかどうかである。 その前提に立った瞬間、能力レベル3は「分からない概念」ではなく、「組織の振る舞い」として認識できるようになる。 ８．このままで、本当にいいのか？ここまで、能力レベル3とは何か、そしてそれがなぜ分かりにくかったのかを見てきた。能力レベル3は、プロジェクトをうまく回すための段階ではなく、プロジェクトを素材として、組織としての仕事の仕方を設計し、学習を回し始める状態である。そして、その正体はプロジェクトの中では決して見えない。それでも、これまで多くの組織はプロジェクト中心の見方に留まり続けてきた。それは誤りだったからではない。組込みソフトウェアが長らく“無償に近いもの”として扱われ、製品価値の中心がハードウェアにあった時代には、その立ち位置で事業が成立してきたからである。 しかし、状況はすでに変わっている。Teslaを見れば分かるように、ソフトウェアは機能の集合体ではなく、事業そのものになりつつある。ADAS、そしてSDVの世界では、製品価値や競争力はソフトウェアによって定義される。ソフトウェアは価値として問われ、有償化の時代に入りつつあり、欧米との直接競争も、もはや避けられない現実である。この環境において、プロジェクト単位での対応を積み重ねるだけで十分なのか。評価要求に応え続けるだけで、事業としての競争力は維持できるのか。ここで問われているのは、やり方ではなく立ち位置である。 能力レベル3はゴールではない。それは、レベル4・5で事業を回すための最低限の土台に過ぎない。能力レベル3を「分からない概念」のままにしておくのか。それとも、組織として引き受け、次の段階へ進む準備を始めるのか。これは評価の都合や一部のプロジェクトの事情で決まる話ではない。組織としての意思決定を伴う選択である。 このままで、本当にいいのか。この問いに、今すぐ明確な答えが必要なわけではないかもしれない。しかし、プロジェクト中心の見方を続けるのか、それとも組織として仕事の仕方を設計する立場に立つのか。その選択を意識しないまま進むことだけは、避けるべきだろう。能力レベル3とは、何かを新しく付け加えた結果として得られる到達点ではない。どこに立って仕事を見るのか、その視点を選び直したときに、あとから振り返って「そこにあった」と気づく状態に過ぎない。答えは、モデルや評価の中にはない。組織自身の選択の中にしか存在しない。 （日吉 昭彦）