日本の車載ソフトウェア開発では、何故いまだにDRBFMが使われているのか（前編）　〜　生産性向上と品質維持に向けた提言　〜

そもそもDRBFMは、「機械部品」の設計変更や環境変化に伴うリスクを洗い出すために生まれた手法である。「ボルトの径を変えた」、「材質を変えた」、「使用条件が変わった」。そうした物理的な変化点を起点に、摩耗や破断といった実体のある故障モードを徹底的に深掘りすることに、その本質的な価値があった。

 

ではなぜ、その手法がソフトウェア開発に使われ続けているのか。なぜ「コード一行の変更」を、「機械部品の設計変更」と同じ発想で扱わなければならないのか。この問いに、工学的に納得できる明確な説明を聞いたことがない。実際の開発現場では、今もなお多くの技術者が相当な時間と労力をかけてDRBFMを実施している。「故障モードを〇〇個出せ」「もっと深掘りできるはずだ」「宇宙線によるビット反転が起きたらどうするのか」。そうした指摘が飛び交い、現実にはほとんど起こらない事象まで含めて、延々と議論が続く。DRBFMは、本来の「変更点に着目した検討」という枠を超え、起こるかどうか分からない最悪事象を列挙する儀式になってしまっているのではないだろうか。

 

あまりに負担が大きいため、「ここまでやる必要が本当にあるのだろうか？」と疑問を投げかけると、返ってくる答えは、ほぼ決まっている。「上司の指示だから」、「会社のルールだから」。そこには、技術的な必然性よりも、慣習や前例を優先する空気が色濃く見て取れる。技術革新のスピードは年々加速し、開発は急速にグローバル化している。各国のエンジニアが分業し、並列に開発を進めることが当たり前になった現在、このような開発スタイルを続けていて、本当に日本製品の優位性は保てるのだろうか。

ソフトウェアが車の価値を決め、ソフトウェアの開発スピードが競争力の源泉になるSDV時代において、「ソフトウェアの変更点を人間が集まって延々と深掘りする」という方法論は、生産性・品質の両面で限界に達していると筆者は考えている。問題は、個々の技術者の能力や意識ではない。前提としている開発思想そのものが、すでに時代と乖離し始めているのである。

 

本コラムで扱おうとしているテーマは、いわば「触れてはいけない」とされがちな領域である。日本の車載ソフトウェア開発において長年 “当たり前” として受け入れられてきた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は「品質を作り込むための正統な手法」であり、それによって数多くの成功体験を積み重ねてきた。一方で、ソフトウェアアーキテクチャや自動テスト、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と距離を取るための現実的な道筋について考えていく。