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

５．車載以外のソフトウェア開発では、なぜDRBFMは使われないのか

前編（こちらからご参照ください）では、日本の車載ソフトウェア開発の内部構造に焦点を当て、DRBFMがなぜ重く、そして終わらないプロセスとして運用されるようになったのかを見てきた。では、このような運用は、ソフトウェア開発全体に共通するものなのだろうか。結論から言えば、そうではない。車載以外のソフトウェア開発において、DRBFMはほとんど使われていない。これは欧米だけの話ではない。日本国内においても、Webサービス、業務システム、モバイルアプリケーション、さらには通信機器や一般的な組み込み分野において、DRBFMが品質保証の中心に据えられることは稀である。この事実は重要である。問題は、DRBFMが「普及していない」ことではない。むしろ、そもそも必要とされていないことにある。
 
車載以外のソフトウェア開発では、ハードウェアに起因する不確実性を、個々の変更レビューの場に持ち込まない。どこで何を扱うかという責任は分けられており、その前提の範囲で設計と検証が行われる。そのため、ある変更点からすべての影響を展開し続ける必要はない。議論は一定の範囲で止まり、それ以上は別の仕組みや責務に委ねられる。言い換えれば、一つの変更に対して、システム全体の成立まで人間が背負い続ける構造にはなっていないのである。
 
また、多くのソフトウェア開発では、変更は例外ではなく前提である。機能は継続的に追加・修正され、修正による影響は分割して扱われる。このような環境では、「変更のたびにすべての故障モードを列挙する」という方法論は成立しない。仮にそれを徹底すれば、開発そのものが止まってしまう。したがって、変更は小さく扱われ、その影響は段階的に確認される。一度の変更にすべてのリスクを集約するという発想そのものが選択されない。
 
もちろん、車載以外の分野でも品質を軽視しているわけではない。むしろ、DRBFMとは別の方法で品質を担保している。たとえば、アーキテクチャによって影響範囲を局所化し、自動テストによって継続的に影響を確認し、実装と検証を分離し、問題が起きた場合には迅速に検出・修正できる仕組みを整える。こうした、よりシステム化された方法が前提として存在している。ここには、ソフトウェア開発における重要な前提がある。それは、人間が事前にすべてを想定することはできないという前提である。したがって、「起こり得ることをすべて洗い出す」のではなく、「起きたときに制御できるようにしておく」という考え方が採用される。これは、DRBFM的な発想とは大きく異なる。
 
以上を踏まえると、車載以外のソフトウェア開発でDRBFMが使われない理由は明確である。

• 議論は一定の範囲で止まる
• 変更は分割されて扱われる
• 品質は個別の検討ではなく、仕組みで担保される

このような前提が成立しているため、「変更点からすべての故障モードを洗い出す」というアプローチ自体が成立しにくいのである。つまり、DRBFMは単に「使われていない」のではない。そもそも必要になる文脈が存在しないのである。
 
ここで一つ、整理しておきたい。車載以外のソフトウェア開発が特別なのではない。むしろ、車載ソフトウェア開発の方が、異なる前提の上に成り立っているのである。本来どこかで止まるはずの議論が止まらず、分割されるはずの問題が一箇所に集まる。その結果として、すべての不安がDRBFMに集約されていく。言い換えれば、DRBFMが必要なのではなく、DRBFMで受け止めるしかない構造になっているということである。

６．DRBFMは「工学の欠如」を埋めるための応急処置だった— なぜDRBFMは“原因”ではなく“結果”なのか

第5章で見てきたように、車載以外のソフトウェア開発では、DRBFMという手法はほとんど使われていない。これは単なる手法の違いではなく、開発の前提そのものが異なることを示している。では逆に問うべきである。なぜ車載ソフトウェア開発では、DRBFMが必要とされ続けてきたのか。この問いを手法の優劣として扱ってしまうと、本質を見誤る。DRBFMは問題の原因ではない。それが必要となる構造の中で生まれた結果である。

要求の変更意図が失われる

まず見なければならないのは、要求の扱いである。車載開発では、OEMから要求仕様書のアップデート版が頻繁に送付されることが多い。しかしその際、どこが変更されたのか、なぜ変更されたのか、その変更がどの範囲に影響するのか、といった情報が提供されないまま要求仕様書一式として送付されるケースが少なくない。本来であれば、要求の変更は、前バージョンとの差分を明示した「変更依頼文書」として提示されるべきである。その中には変更の目的、変更点、想定される影響範囲が明確に記述されている必要がある。しかし現実には、そのような情報が整備されないまま、更新版の要求のみが送付される。その結果、開発側では新旧要求を突き合わせ、差分を取り、どこが変わったのかを後から解釈する作業が発生する。
しかしこの時点で、すでに重要な情報は失われている。それは変更の意図である。変更理由が分からなければ、その変更がどこまで影響するべきものなのか、どこからが想定外の振る舞いなのかを判断することが難しくなる。結果として、影響範囲は保守的に広く見積もられ、検討範囲は自然と拡張されていく。

設計として影響範囲を説明できない

次に問題になるのが、設計側の責任である。本来、変更の影響範囲は設計によって限定されるべきである。つまり、その変更がどの機能に影響し、どのインターフェースを介して波及し、どの範囲で収まるのかを、設計として説明できる状態が求められる。そのためには、アーキテクチャ設計書や詳細設計書が整備されていることが不可欠である。これらの設計情報が存在してはじめて、影響範囲を論理的に説明することができる。しかし、それらが不十分な場合、影響範囲の判断は人の経験や勘に依存せざるを得ない。そうなると、「なぜそこまで影響しないと言えるのか」という根拠を明確に示すことができず、検討範囲を意図的に絞り込むことが難しくなる。
ここで重要なのは、要求の意図が不明確なことと、設計で影響範囲を限定できないことは、別々の問題であるという点である。要求の意図が失われている状態は上流の問題である。一方で、それを前提に設計を成立させることはサプライヤー側の責任である。しかし現実には、この二つが重なってしまう。変更の意図が分からないため影響範囲を広く見積もり、さらに設計としてその範囲を限定・説明できないため、検討はますます広がっていく。
こうして、「どこまで確認すれば十分か」を論理的に示せない状態が生まれる。その結果、念のため確認する、一応すべて見る、全体で問題がないことを保証する、という判断が積み重なり、検討は際限なく拡張されていく。これは前編で見た「無限深掘り」の構造そのものである。

DRBFMは設計で閉じられなかった問題を受け止めている

この状況において、DRBFMは何をしているのだろうか。それは、単なる品質手法というよりも、設計で限定・整理できなかった問題を受け止める場として機能している。変更点を列挙し、起こり得る影響を広く洗い出し、関係者同士で確認する。こうした活動は、本来であれば、要求で整理されるべき情報、設計で限定されるべき範囲、構造で制御されるべき影響を、会議によって補完している状態に近い。
設計として説明できない。影響範囲を限定できない。要求の意図も不明確である。このとき最後に残る根拠は、「全員で確認した」という事実である。その意味で、DRBFMは設計の代替であり、トレーサビリティの代替であり、境界定義の代替として機能している。だからこそ、負荷がどれほど大きくても簡単にやめることができない。DRBFMは、品質を支える最後の防衛ラインになってしまっているのである。

DRBFMは合理的な帰結である

ここで見方を変える必要がある。DRBFMは非効率であり、現場を疲弊させる。これは事実である。しかし、それだけではなぜDRBFMが使われ続けているのかを説明できない。変更の意図が分からない。影響範囲を限定できない。根拠を説明できない。この状態で品質を確保しようとすれば、人間が可能な限りリスクを洗い出す以外の方法が残されていない。その意味で、現在の前提のもとでは、DRBFMは合理的ですらある。問題はDRBFMそのものではない。DRBFMでしか品質を支えられない状態にあることが本質である。手法を変えるだけでは、この構造は変わらない。むしろ、DRBFMを単純に削減すれば、品質を支える手段そのものを失うことになりかねない。
本当に問うべきなのは、なぜ変更の意図が共有されないのか、なぜ設計で影響範囲を限定できないのか、なぜその範囲を説明できないのか、という開発の前提そのものである。では、これらの前提をどのように変えていくのか。車載以外のソフトウェア開発では、なぜこの問題を構造として解決できているのか。次章では視点をさらに外に移し、DRBFMに依存しない開発がどのように成立しているのかを見ていく。

７．欧米の車載ソフトウェア開発はどうなっているのか　－　工学として扱うことで成立している世界

第5章では、車載以外のソフトウェア開発ではDRBFMがほとんど使われていないことを見てきた。そして第6章では、その理由が手法の違いではなく、ソフトウェアを工学として扱えているかどうかにあることを整理した。それでは、欧米の車載ソフトウェア開発はどのような状態にあるのだろうか。結論はシンプルである。ソフトウェアを工学として扱う前提が成立しているため、DRBFMに依存する必要がないのである。

設計が影響範囲を説明できる

欧米の車載ソフトウェア開発では、設計が単なる構成図ではなく、システムの振る舞いと影響の範囲を説明するための基盤として機能している。要求と設計の関係が整理され、機能ごとの責務と境界が明確に定義されているため、変更や検討が生じた場合でも、その影響がどこまで及ぶのかを設計として説明することができる。ここで重要なのは、経験や感覚に依存するのではなく、構造として根拠を示せることである。どこまで評価すべきか、なぜその範囲で十分なのかを、設計として説明できる。だからこそ、すべてを見直すという状況が発生しにくい。これは、日本の現場でしばしば見られる「どこまで見れば十分か分からない」という状態との大きな違いである。

分析は設計と論証の中で機能する

欧米の車載ソフトウェア開発では、品質や安全性は個別の検討の積み重ねだけで担保されるのではなく、設計結果を論証する枠組みの中で扱われる。ISO 26262に代表されるように、安全要求を定義し、それを設計として実装し、その成立を論証するという体系が前提となっている。この中で、FMEAやFTAといった分析は当然実施される。しかし、それらは単独の活動として完結するものではなく、設計と論証を成立させるための材料として位置付けられる。重要なのは、分析そのものではなく、分析結果が設計と論証の構造の中でどのように機能しているかである。
この前提のもとでは、分析はその場限りの検討として消費されることはない。設計の中に取り込まれ、境界や振る舞いとして固定され、その後の判断の前提として機能し続ける。ここで見落としてはならないのは、設計に対する考え方そのものの違いである。欧米のソフトウェア開発では、問題が発生したときに「なぜそれが起きるのか」を無限に掘り下げ続けることよりも、どう振る舞うべきか、どう実現するかに焦点が置かれる。もちろん原因分析は行われる。しかし、それは掘り続ける対象ではなく、設計を成立させるための入力として扱われる。その結果、議論は原因を網羅的に洗い出す方向ではなく、設計によって影響を制御する方向に収束する。不具合の可能性を会議で洗い出し続けるのではなく、設計として安全に制御できる状態を作る。この考え方が自然に成立しているのである。

設計が成立している世界では何が違うのか

設計がこのように機能している場合、不安やリスクが発生しても、それが無制限に広がることはない。影響が及ぶ範囲と収まる範囲があらかじめ定義されているため、検討は自然とその中で完結する。つまり、影響範囲が設計として限定され、その根拠を説明でき、検討すべき範囲があらかじめ定義されている。この前提が成立している限り、不安を網羅的に洗い出す場そのものが必要になりにくい。したがって、DRBFMは排除されたわけではない。単に、主役として必要になる場面が存在しないのである。
設計として影響範囲を限定できず、その根拠も説明できない場合、検討は人間の確認へと引き戻され、その受け皿としてDRBFMが必要になる。一方で、設計としてそれが成立している場合、検討は構造の中で完結する。欧米では特別なことをしているのではない。ソフトウェアを工学として扱っているだけである。そして、その前提が成立しているとき、DRBFMに依存しない開発が自然に成立する。次章では、この前提を踏まえ、DRBFMをどのように使い分けるべきかという現実的な問いに踏み込んでいく。

8. それでもDRBFMを全否定しない理由（使いどころを再定義するか）

ここまで述べてきた通り、DRBFMの問題を解くために最初に取り組むべきことは、DRBFMそのものの改善ではない。まず必要なのは、影響範囲を説明できるアーキテクチャを作り、ソフトウェアを工学として扱える状態に近づけることである。しかし、それはDRBFMを完全に不要にするという意味ではない。むしろ重要なのは、DRBFMを「常に実施する品質保証プロセス」から、必要な場面で使う補助的なリスク検討手段へと位置付け直すことである。

日本の車載ソフトウェア開発でまず進めるべきなのは、ソフトウェア開発の方法論を本格的に取り入れることである。要求の変更を正しく扱い、変更の影響範囲を設計として説明し、差分を局所的に管理する。こうした考え方なしに、DRBFMだけを軽くしようとしても、根本的な解決にはならない。この点で、XDDPのようなソフトウェア向けの派生開発プロセスは参考になる。XDDPは、変更要求、変更設計、影響範囲を整理し、派生開発における混乱を抑えるための考え方である。DRBFMのように心配事を広げていくのではなく、変更を構造的に扱い、影響を限定していく方向を持っている。もちろん、XDDPを導入すればすべてが解決するわけではない。重要なのは、特定の手法名ではなく、変更をソフトウェア工学の枠組みで扱うことである。DRBFMの前に、まず設計と変更管理を成立させる。この順序を間違えてはならない。

DRBFMを本来の役割に戻す

DRBFMは不要なものではない。しかし、ソフトウェア開発全体を支配する手法でもない。まずはアーキテクチャを成立させる。次に、XDDPを含むソフトウェア開発の考え方を取り入れ、変更を構造的に扱えるようにする。その上でなお残る不確実性に対して、DRBFMを使う。この順序が重要である。DRBFMを先に考えるのではない。ソフトウェア開発を工学として成立させることが先である。その状態に近づくほど、DRBFMの適用範囲は自然に小さくなる。そしてそのとき初めて、DRBFMは本来の価値を取り戻す。すべてを確認するための儀式としてではなく、設計だけでは扱いきれないリスクに向き合うための補助的な手段として。
DRBFMを完全に捨てる必要はない。しかし、DRBFMに依存し続ける開発からは脱却しなければならない。DRBFMがなくても成立する設計を目指し、その上で、本当に必要な場面にだけDRBFMを使う。その方向へ進むことが重要である。ただし、このような使い分けを実現するためには、単にDRBFMの運用ルールを変えるだけでは不十分である。必要なのは、ソフトウェアを工学として扱い、設計で説明できる領域を広げていく開発文化そのものへの転換である。では、日本の車載ソフトウェア開発は、何を残し、何を捨て、どの方向へ変わるべきなのか。最終章では、この問題を単なるDRBFMの是非ではなく、日本の車載ソフトウェア開発が世界で戦い続けるための課題として整理したい。

9. 変えなければ、世界では勝てない

ここまで見てきた通り、DRBFMの問題は、単なる手法の話ではない。DRBFMそのものが悪いのではなく、日本の車載ソフトウェア開発が、長い間ソフトウェアを「工学として設計する対象」として十分に扱い切れてこなかったことが、本質的な問題である。設計で説明すべきことがDRBFMに流れ込む。アーキテクチャで限定すべき影響範囲を、会議の中で洗い出そうとする。要求管理やトレーサビリティで扱うべきことまで、人間のレビューで補おうとする。そこに、日本の車載ソフトウェア開発が抱えてきた構造的な弱さが表れている。つまりDRBFMは、問題の原因というよりも、そうした開発文化を映し出す一つの象徴なのである。
 
この問題は、DRBFMだけに閉じた話ではない。筆者が以前から問題視してきた「制御仕様書」も、同じ根を持っている。詳しくは、こちらのコラム「制御仕様書という怪物」を参照してほしい。本来であれば、要求、アーキテクチャ、詳細設計、テスト、安全論証は、それぞれ異なる役割を持つべきである。要求は何を実現すべきかを示し、アーキテクチャは責務と境界を定義し、詳細設計は実現方法を具体化する。テストはそれらが成立していることを確認し、安全論証はその根拠を示す。ところが現実には、それらの境界が曖昧になり、一つの巨大な仕様書や、一つのレビュー会議に多くの責任が押し込まれてしまう。制御仕様書には、要求も設計も実装都合も検証観点も混在する。DRBFMには、変更点の確認も、影響範囲の推測も、安全上の不安も、責任分散のための確認も入り込む。どちらも、本来は分けて扱うべきものを分けられなかった結果として生まれた、巨大な受け皿である。問題の本質は、帳票でも会議体でもない。ソフトウェアを分解し、構造化し、説明可能にする設計文化が十分に根付いてこなかったことにある。
 
だからといって、日本の品質文化をすべて否定する必要はない。変化点に敏感であること、安全に対して妥協しないこと、関係者の知見を持ち寄り、リスクを見逃さないようにすること。これらは、日本のものづくりが持ってきた強みであり、ソフトウェア開発においても失ってよいものではない。しかし、捨てるべきものも明確である。手続きの量が品質を保証するという考え方、帳票を厚くすれば安心できるという発想、人間が集まって議論すれば設計の弱さを補えるという期待。これらは、ソフトウェアが大規模化し、複雑化した現在では、もはや通用しない。人間の知見は重要である。しかし、それは設計を補うために使われるべきものであり、設計そのものの代替にしてはならない。すり合わせを捨てる必要はない。だが、すり合わせを主役にしてはならない。主役は、アーキテクチャであり、要求管理であり、トレーサビリティであり、テストであり、安全論証である。その上で、人間のレビューやDRBFMが補助的に機能する。この順序を取り戻すことが重要である。
 
自動車は、もはやメカ中心の製品ではない。車の価値は、確実にソフトウェアによって決まりつつある。この時代に、ソフトウェアをハードウェア開発の流儀で扱い続ければ、競争力は確実に低下する。開発速度は上がらない。変更に弱い。現場は疲弊する。優秀なソフトウェアエンジニアにとって魅力のある開発環境にもなりにくい。品質を守ろうとしてプロセスを重くした結果、変化に対応できなくなるのであれば、それは本末転倒である。これから必要なのは、品質を軽視することではない。むしろ逆である。品質を守るためにこそ、開発を工学化しなければならない。アーキテクチャによって影響範囲を説明し、要求と設計をつなぎ、テストで検証し、安全性を論証する。その上で、なお残る不確実性に対して、人間の知見を活かす。DRBFMも、その文脈の中で使われるべきである。DRBFMを完全に捨てる必要はない。しかし、DRBFMに依存し続ける開発からは脱却しなければならない。DRBFMがなくても成立する設計を目指し、その上で、本当に必要な場面にだけDRBFMを使う。その方向へ進まなければ、日本の車載ソフトウェア開発は、グローバルな競争の中で次第に厳しい立場に置かれていくだろう。変えるべきなのは、品質へのこだわりではない。品質を支える方法である。
 
DRBFMを続けるか、やめるか。本質的な問いは、そこではない。問うべきなのは、自分たちの開発が工学に向かっているのか、それとも儀式に向かっているのかである。設計で説明できない不安を、これからも会議で埋め続けるのか。それとも、設計で説明できる領域を増やし、DRBFMを本来の使いどころに戻していくのか。これは、単なる開発プロセスの話ではない。日本の車載ソフトウェア開発が、これからも世界で戦っていけるかどうかの話である。DRBFMは、日本独特の開発文化が生み出した産物である。そしてその存在は、私たちがまだソフトウェアを十分に工学として扱い切れていないことを映し出している。
 
だからこそ、変えなければならない。
あなたの現場は、工学に向かっているだろうか。それとも、儀式を続けているだろうか。

（日吉　昭彦）