Updates

新着情報

コラム

エンジニアリングチーム(開発組織)の成長とスキル開発 ~成長する開発組織に必要なものは「個人」と「チーム」の両立~

1. 「成長したい」と「時間がない」のあいだでエンジニアとして仕事に取り組む中で、「継続的に成長すること」の重要性を感じている方は多いのではないでしょうか。技術の変化が速い領域において、学び続けることは避けて通れません。一方で、現実には日々の開発業務、障害対応、スケジュールへの追従といった目の前の作業に追われ、自己研鑽の時間を十分に確保できていないという状況も広く見られます。その結果、「成長の必要性は理解しているが、実践が難しい」という状態が生まれます。このギャップは個人の問題というより、開発組織全体に共通する構造的な課題と捉えるべきものとも考えられます。2. 個人の努力だけでは乗り越えられない壁スキル開発は、これまで個人の主体性に委ねられる側面が強くありました。自ら学び、試し、成長する—この姿勢自体は非常に重要です。しかし、個人の努力に依存した成長にはいくつかの限界があります。まず、学習への投資には個人差が生まれやすく、チーム内にスキルのばらつきが生じます。その結果、特定のメンバーに業務が集中しやすくなり、属人化のリスクが高まります。また、個人が獲得した知識やノウハウが共有されなければ、チーム全体の能力向上にはつながりません。さらに、せっかく学んだ内容も実務で活用する機会がなければ定着しにくく、学習の効果が十分に発揮されないケースも見られます。3. チームとして成長している状態とはでは、「チームとして成長している状態」とはどのような状態を指すのでしょうか。一つは、特定の個人に依存せずに開発が進められる状況です。誰かが不在でも業務が滞らないことは、知識やスキルがチームに分散・共有されていることの表れです。また、分からないことを気軽に相談できる関係性や、レビューや対話を通じて知識が自然に広がる環境も重要です。こうした状態では、個人が学んだことがチームに還元されやすくなります。さらに、経験の浅いメンバーが新しい技術や役割に挑戦できる機会があることも、チームの成長にとって不可欠です。 こうした状態は、次のような要素によって支えられており、これらが適切に組み合わさることで、個人の成長とチームの成長が相互に作用する状態が生まれると考えられます。<チームの成長を促進する主な要素>・学習機会が継続的に提供されていること・知識や経験がチーム内で共有される仕組みがあること・新しい役割や技術に挑戦できる機会が用意されていること・挑戦に伴う失敗が許容される心理的安全性が確保されていること・成長の方向性や期待値がある程度明確になっていること 4. 成長のための施策がうまく機能しない理由多くの組織では、研修や勉強会、スキル定義など、スキル開発を目的としたさまざまな施策が導入されています。しかし、それらが現場の実感として「意味のあるもの」として機能しているかというと、必ずしもそうとは限りません。その背景には、いくつかの共通した要因があります。まず一つは、「目的と手段の分離」です。研修やスキル定義が“何のために存在するのか”が十分に共有されていない場合、それらは単なる形式的な活動になりがちです。その結果、受講や記入そのものが目的化し、実際の成長につながらない状態が生まれます。次に、「業務との関係の弱さ」が挙げられます。学習した内容が日々の業務で活用される見通しが立たない場合、人は自然と優先順位を下げます。特に納期や品質に責任を持つ現場においては、直接成果に結びつかない活動は後回しにされやすいという現実があります。さらに、「一律性」も課題となります。エンジニアのキャリア志向やスキルレベルは多様であるにも関わらず、画一的な内容を一斉に適用しようとすると、誰にとっても中途半端なものになりやすくなります。その結果、主体的に取り組む動機が弱まり、「やらされ感」が強まります。これらの要因が重なることで、本来は成長を支援するはずの施策が、現場にとって負担や形骸化した活動として認識されてしまうことがあります。5. 自律性を尊重した成長の仕組みづくりこうした課題を踏まえると、スキル開発を機能させるためには、研修や育成制度といった個別の取り組みを増やすこと自体が解決になるわけではありません。重要なのは、それらの取り組みをどのような意図で設計し、どのように連動させるかという点です。特に鍵となるのが、個人の自律性との関係です。自律性とは、単に「自由に任せる」ということではありません。組織としての方向性や期待値をある程度示しつつ、その中で個々人が選択できる余地を持たせることが重要です。例えば、スキルの全体像や成長の方向性を可視化した上で、どの領域をどの程度深めるかは個人に委ねる、といった考え方です。このように「枠組み」と「自由度」を両立させることで、納得感のある成長につながります。また、学びと実務のつながりも重要なポイントです。新しく習得した知識や技術を試せる場がなければ、学習は一過性のものにとどまりがちです。プロジェクトの中で新しい役割に挑戦できる機会や、小さな改善活動に取り組める環境を整えることで、学びを実践へとつなげることができます。さらに、評価や役割との関係も無視できません。日々の業務成果だけでなく、知識共有や育成への貢献といった行動が適切に認識されることで、個人の取り組みは継続しやすくなります。このように、個人の自律性を尊重しながらも、組織として成長の方向性や機会を設計していくことが、スキル開発を持続的なものにするための重要なポイントとなります。6. 組織が担うべき「成長の土台づくり」個人の自律的な成長を支えるためには、それを下支えする「土台」が必要です。この土台は、単一の施策で成立するものではなく、複数の仕組みが連携することで初めて機能します。 具体的には、次のような施策が考えられますが、これらは組織として整備すべきものです。<スキル開発・チーム成長を促すための主な施策>・スキルマップの可視化(成長の方向性や現在地の理解を支援)・トレーニングカリキュラムの整備(基礎から応用までを体系化し段階的に学べる設計)・OJTによる実践的な育成(実務と学習の接続:業務を通じたスキル定着)・メンター制度(個別の相談や成長支援の強化)・学習支援制度(学習機会へのアクセス向上:書籍購入や研修参加などの後押し)・ナレッジ共有の仕組み(チームへの還元促進:レビュー・勉強会・ドキュメントなど) ここで重要なのは、「施策単体の良し悪し」だけではなく、「組み合わせ」です。例えば、研修だけが整備されていても、それを実務で試す場がなければ効果は限定的です。逆に、挑戦機会があっても基礎的な学習支援が不足していれば、取り組める人は限られます。また、ナレッジ共有の仕組みがあっても、それが評価や期待と結びついていなければ、継続的な活動にはなりにくいでしょう。このように、個々の施策は相互に補完し合う関係にあります。組織としての役割は、それらを全体として設計し、「自然に成長が生まれる状態」を作ることにあります。7. おわりに:成長を「個人任せ」にしないためにスキル開発は個人の主体的な取り組みによって成り立つ側面を持ちながらも、それだけに委ねてしまうと、組織としての成長には限界が生じます。個人の努力と、チームや組織による支援、この両方がかみ合ったとき、はじめて持続的な成長が可能になると考えます。成長は「個人で頑張るもの」でも、「組織から与えられるもの」でもなく、両者の相互作用によって実現されるものであり、その視点を持つことが、これからのエンジニアリング組織において、より一層重要になっていくのではないでしょうか。 (佐藤崇)

お知らせ

労働者派遣事業許可取得のご案内

平素は格別のご愛顧を賜り、心より御礼申し上げます。 この度、弊社は厚生労働大臣より「労働者派遣事業」の許可を取得いたしましたのでお知らせいたします。 これにより、従来の契約形態(業務委託など)に加え、より柔軟で幅広い人材ソリューションのご提案が可能となります。これまで以上に法令遵守(コンプライアンス)を徹底し、労働者の皆様が安心して働ける環境づくりと、企業の皆様の多様な人材ニーズに応える最適なサービスの提供に努めてまいります。 今後とも変わらぬご愛顧を賜りますよう、何卒よろしくお願い申し上げます。 許可年月日:令和8年6月1日許可番号:派12 - 301828

WhitePaper

【資料公開】第9回無料Webinar AI時代のQA(品質保証活動)とは何か?

第9回無料Webinar「AI時代のQA(品質保証活動)とは何か?」で使用した資料を公開しました。下記、フォームにご記入の上ダウンロードしてください。  本来求められる品質保証活動 なぜ監査しかできていないのか AIで監査を自動化する 本来の品質保証活動へ セッションタイムアウトまでの時間が短いため、ダウンロードリンク表示後速やかにダウンロードしてください。当日の動画も公開しておりますので、こちらもご参照ください。  

YouTube

【動画公開】第9回無料Webinar AI時代のQA(品質保証活動)とは何か?

第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 入門 一般開催トレーニング(7月開催)のご案内

Automotive SPICE 入門一般開催(7月分)の日程をご案内いたします。詳細およびお申込みは、下記リンクあるいは「イベント開催日程」からお願いいたします。 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を使ったオンラインでの開催となります 教材は、原則開催日の5日前までにご指定場所に郵送いたします ご請求書はPDF版をメールで送付いたします お支払い期日は、ご請求書発行日の翌月末となります ご請求書発行後のキャンセルは、お断りしています(代理出席などの手配をお願いします) お申込者以外の方の聴講および録音は固く禁じます

B'zine

B'zine - 2026年5月号(コラム:車載SW開発に何故いまだにDRBFMが使われているのか)を発行しました

B'zine 5月号を発行いたしました。ショート動画も公開していますので、弊社公式YouTubeより是非ご視聴ください。  B'zineは、1回/月のペースでの配信しています。ご興味のある方は、ここから登録をお願いいたします。 B'zineビジネスガレージ通信(2026年5月号) B’zine ビジネスガレージ通信(2026年5月号) お届けします。今年のゴールデンウィークは天候が安定せず、予定していた行楽を断念された方もいらっしゃったのではないでしょうか?また、ゴールデンウィーク後は断続的な真夏日と3月並み気温の訪れや関東地方の梅雨入りも控えており、体調管理には十分ご留意ください。 【今月のトピックス】 イベント:5月28日(木)第9回Webinar開催:AI時代のQA(品質保証活動)とは何か?~ 人が行うQA、AIが行うQAを考える ~ イベント:人手運用から脱却する構成管理DX〜 現場を救う構成管理ロボの導入事例 〜(2026年7月開催予定) イベント:Automotive SPICE 入門一般開催トレーニング(6月開催)のご案内 コラム:Automotive SPICE 能力レベル3とは何か? それは「プロセスの話」だけではない(後編) コラム:日本の車載ソフトウェア開発では、何故いまだにDRBFMが使われているのか(前編) YouTube:Automotive SPICE レベル3を“現場視点”で解説する動画コンテンツを公開 【イベント】 2026年5月28日 Webinar:AI時代のQA(品質保証活動)とは何か?~ 人が行うQA、AIが行うQAを考える ~生成AIをはじめとした技術の進展により、開発環境や仕事の進め方は大きく変わりつつあります。それに伴い、QA(品質保証活動)やQAグループに求められる役割や価値についても、見直す必要があるのではないでしょうか?本webinarでは、AI活用そのものを目的とするのではなく、AI時代にQAやQAグループが担うべき役割や価値を改めて整理します。1.期待されているQAとは2.現状の品質保証グループが抱える構造的な課題3.AIが得意なQA領域/人が担うべきQA領域4.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とは何か? それは「プロセスの話」だけではない(後編)前編では、能力レベル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で問われる実態とは何か・組織として達成すべき状態とは何かといった観点から解説しています。現在3本を公開しており、今後もシリーズとして継続予定です。Automotive SPICEの導入・改善に取り組まれている方は、ぜひご覧ください。詳細はこちら→https://www.bgarage.co.jp/news/2010/

YouTube

Automotive SPICE レベル3を“現場視点”で解説する動画コンテンツを公開

当社では、Automotive SPICEに関する知見を発信する取り組みとして、ショート動画シリーズの配信を開始しました。本シリーズは、「Automotive SPICE 能力レベル3とは何か? ― それは『プロセスの話』だけではない」の記事内容をベースに、現場での実践を踏まえて再構成したものです。前編:Automotive SPICE 能力レベル3とは何か? ー それは「プロセスの話」だけではない (前編) - ビジネスガレージ株式会社後編:Automotive SPICE 能力レベル3とは何か? ー それは「プロセスの話」だけではない (後編) - ビジネスガレージ株式会社 単なるモデル解説ではなく、・なぜ形式的な適用では評価につながらないのか・レベル3で問われる実態とは何か・組織として達成すべき状態とは何かといった観点から解説しています。 現在3本を公開しており、今後もシリーズとして継続予定です。Automotive SPICEの導入・改善に取り組まれている方は、ぜひご覧ください。

コラム

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

1.なぜ、車載ソフトウェア開発にDRBFMが使われているのか日本の車載ソフトウェア開発では、DRBFM(Design Review Based on Failure Mode)が当然のように使われている。これは筆者にとって、驚き以外の何ものでもない。そもそもDRBFMは、「機械部品」の設計変更や環境変化に伴うリスクを洗い出すために生まれた手法である。「ボルトの径を変えた」、「材質を変えた」、「使用条件が変わった」。そうした物理的な変化点を起点に、摩耗や破断といった実体のある故障モードを徹底的に深掘りすることに、その本質的な価値があった。 ではなぜ、その手法がソフトウェア開発に使われ続けているのか。なぜ「コード一行の変更」を、「機械部品の設計変更」と同じ発想で扱わなければならないのか。この問いに、工学的に納得できる明確な説明を聞いたことがない。実際の開発現場では、今もなお多くの技術者が相当な時間と労力をかけてDRBFMを実施している。「故障モードを〇〇個出せ」「もっと深掘りできるはずだ」「宇宙線によるビット反転が起きたらどうするのか」。そうした指摘が飛び交い、現実にはほとんど起こらない事象まで含めて、延々と議論が続く。DRBFMは、本来の「変更点に着目した検討」という枠を超え、起こるかどうか分からない最悪事象を列挙する儀式になってしまっているのではないだろうか。 あまりに負担が大きいため、「ここまでやる必要が本当にあるのだろうか?」と疑問を投げかけると、返ってくる答えは、ほぼ決まっている。「上司の指示だから」、「会社のルールだから」。そこには、技術的な必然性よりも、慣習や前例を優先する空気が色濃く見て取れる。技術革新のスピードは年々加速し、開発は急速にグローバル化している。各国のエンジニアが分業し、並列に開発を進めることが当たり前になった現在、このような開発スタイルを続けていて、本当に日本製品の優位性は保てるのだろうか。ソフトウェアが車の価値を決め、ソフトウェアの開発スピードが競争力の源泉になるSDV時代において、「ソフトウェアの変更点を人間が集まって延々と深掘りする」という方法論は、生産性・品質の両面で限界に達していると筆者は考えている。問題は、個々の技術者の能力や意識ではない。前提としている開発思想そのものが、すでに時代と乖離し始めているのである。 本コラムで扱おうとしているテーマは、いわば「触れてはいけない」とされがちな領域である。日本の車載ソフトウェア開発において長年 “当たり前” として受け入れられてきたDRBFMを、工学的・構造的な視点から問い直すことは、少なからず反発を招く話でもある。しかし、この違和感に目をつぶり続けたままでは、議論はいつまで経っても現場の苦労話や精神論に留まり、何も変わらない。そこで今回は、この問題に正面から踏み込むため、あえて前編・後編の二部構成という形を取ることにした。 前編では、なぜソフトウェア開発においてDRBFMがここまで重く運用されるようになったのか、その技術的背景と、日本特有の開発文化・構造を整理する。現場で起きている「無限の深掘り」による疲弊が、個々の技術者の問題ではなく、どのような前提の上に生まれているのかを明らかにしていく。そして後編では、視点を一度外に移し、世界では同じ課題にどう向き合っているのか、なぜDRBFMがソフトウェア開発で使われていないのかを見ていく。その上で、この先どの地点を目指すべきなのかを考えたい。これは手法の是非を問う話ではない。日本の車載ソフトウェア開発が、これからも競争力を持ち続けるために、何を疑い、何を変えるべきかを考えるための議論である。 2.DRBFMは本来ハードウェアの手法だった — メカ開発の成功体験が生んだミスマッチ前章では、ソフトウェア開発の現場でDRBFMが儀式化し、技術者を疲弊させている実態を見てきた。では、なぜそもそもこのような違和感が生じるのか。その答えは、DRBFMという手法のルーツにある。DRBFM(Design Review Based on Failure Mode)は、その名の通り「故障モード」を起点として設計変更のリスクを洗い出す手法である。そして重要なのは、この手法が機械部品を中心としたハードウェア開発のために生まれたという事実だ。 ハードウェアの世界では、DRBFMは極めて合理的に機能する。ボルトの径を細くした、材質を変えた、使用温度範囲が広がった。そうした「変化点」から、摩耗、クラック、破断、漏れといった物理的な故障モードを因果関係として追っていくことができる。部品は実体を持ち、力の流れや劣化のメカニズムも説明可能だ。この世界では、「どこまで深掘りすべきか」は明確であり、深掘りそのものが品質向上に直結する。 一方、ソフトウェアはまったく異なる性質を持つ。ソフトウェアには摩耗も劣化もない。故障の正体は、ほぼ例外なく設計ミス、すなわちバグである。「なぜ壊れたのか」を物理現象として説明できるハードウェアと違い、ソフトウェアの不具合は論理の誤り、前提の勘違い、仕様の曖昧さ、考慮漏れといった人間の思考に起因するものだ。 この本質的な違いを無視したまま、ハードウェア由来のDRBFMをソフトウェアに適用すると、問題が生じる。物理部品のDRBFMでは意味を持っていた「深掘り」が、ソフトウェアでは行き場を失うからだ。変数の型変更、条件分岐の追加、タイミングの微調整など、こうした変更点から「どの段階まで故障モードを掘り下げるべきか」を、物理的な根拠なしに決めることはできない。結果として、ソフトウェアDRBFMでは次のような現象が起きる。論理的にはあり得るが、確率的には極めて低い事象までが同列に扱われる。最終的には「宇宙線によるビット反転」や「OSの内部不具合」といった、設計者が制御不能な領域にまで議論が及ぶ。ハードウェアであれば「そこから先は部品設計や材料特性の問題」として切り分けられていた議論が、ソフトウェアでは切り分けられないままDRBFMの中に押し込まれてしまう。 本来、こうした問題の解決はソフトウェアアーキテクチャの役割である。エラー検知、フェイルセーフ、リカバリーの設計によって、「起きても安全に処理できる」状態を構造として担保するべき領域だ。しかし、アーキテクチャという抽象的な仕組みへの信頼が十分に確立されていない場合、その代替として「とにかく心配事を洗い出す」DRBFMが肥大化していく。ここで強調しておきたいのは、DRBFMそのものが悪いわけではない、という点である。DRBFMは本来、ハードウェア開発において大きな成果を上げてきた優れた手法だ。問題は、その成功体験をほぼ無批判にソフトウェアへと移植し、本質的な違いを考慮せずに運用してきたことにある。ソフトウェア開発におけるDRBFMは、ハードウェアの作法をそのまま当てはめた結果、生まれたミスマッチの産物と言える。そしてこのミスマッチこそが、現場で語られる「終わらない深掘り」「何のためのレビューなのか分からない」といった違和感の正体なのである。 では、なぜ日本の車載ソフトウェア開発では、このミスマッチを抱えたままDRBFMが使われ続けてきたのか。次章では、その背景にある日本特有の設計文化と意思決定構造について掘り下げていく。 3.なぜ日本の車載ソフトウェアではDRBFMが生き残ったのか - すり合わせ文化とハード主導の設計思想前章で見てきたように、DRBFMは本来ハードウェア開発のための手法であり、ソフトウェア開発と相性が良いとは言えない。それにもかかわらず、日本の車載ソフトウェア開発では、DRBFMが長年にわたって当然のように使われ続けてきた。この背景を説明するために、「DRBFMの優劣」や「現場の努力不足」に話をすり替えてはいけない。ここで問うべきなのは、なぜ日本の開発現場では、この違和感を抱えたままでもDRBFMに頼らざるを得なかったのかという点である。ハード屋とソフト屋の「共通言語」としてのDRBFM日本の自動車メーカーでは、長年にわたってハードウェア中心の開発が行われてきた。品質保証、設計審査、意思決定の枠組みも、その多くはハードウェア開発で成功した方法論をベースに構築されている。その中でDRBFMは、「変更点に着目してリスクを洗い出す」という分かりやすい思想を持つ、極めて都合の良い共通言語だった。メカ設計者にも、電気設計者にも、そしてソフトウェア設計者にも、「今回どこを変えたのか」「それによって何が起き得るのか」を同じフォーマットで説明させることができる。本来であれば、ソフトウェアの機能や品質は要求仕様書やアーキテクチャ設計書を通じて説明されるべき存在だ。しかし、それらのドキュメント文化が十分に整備されていない環境では、DRBFMが部門を超えた意思疎通のための代替手段として機能してしまう。結果として、DRBFMは品質手法というよりも、「みんなが理解できる説明の形式」として定着していったのではないか。意思決定層がハード出身であるという構造的問題もう一つ無視できないのが、意思決定層のバックグラウンドである。日本の自動車開発において、開発責任者や品質保証部門の多くは、長年ハードウェア開発に携わってきた人たちである。彼らにとって、DRBFMは「品質を作り込むための正統な手法」であり、それによって数多くの成功体験を積み重ねてきた。一方で、ソフトウェアアーキテクチャや自動テスト、CI/CDといった概念は、必ずしも直感的に理解しやすいものではない。その結果、意思決定の場ではどうしても、「目に見える」「議論できる」「紙に書ける」DRBFMが重視される。ソフトウェア側が「アーキテクチャで担保している」と説明しても、それが完全には信用されず、「ではDRBFMで確認しよう」という結論に落ち着きやすい構造が生まれてしまう。「ネジ一本」と「コード一行」を同列に扱う設計変更思想車載ソフトウェアが問題をさらに複雑にしているのは、ソフトウェアがすでに車の中核機能を担っているという事実である。ブレーキ、ステアリング、パワートレイン制御など、「走る・曲がる・止まる」の多くがソフトウェアによって制御されている。このため、「ネジ一本を変えること」と「コード一行を変えること」を同じ重みの「設計変更」として扱わなければ危険だ、という考え方が強く根付いた。安全を最優先するという点では、この思想自体は理解できる。しかしその結果、ソフトウェア開発が本来前提としている「アーキテクチャによる影響範囲の局所化」、「テスト自動化による回帰検証」、「反復的な変更を許容する開発スタイル」といった要素が十分に考慮されないまま、「変更したのだから徹底的に不安を潰すべきだ」という発想だけが肥大化していった。 リコールコストという「恐怖」が生んだ過剰な保守性このような構造の背景には、車載開発特有の“恐怖”もある。一度市場に出た製品で不具合が見つかれば、数百万台規模のリコールにつながり、企業に甚大な損失をもたらす。この失敗コストの大きさが、「万が一を見逃すより、やり過ぎる方が安全だ」という判断を正当化してきた。そしてDRBFMは、その「やり過ぎ」を制度として固定化するための、極めて都合の良い枠組みだった。結果としてDRBFMは、リスクを減らすための工学的手法というよりも、 これだけやったのだから大丈夫だと言える材料 誰か一人の判断にしないための責任分散装置としての性格を強めていったのである ここまで見てきたように、DRBFMが日本の車載ソフトウェア開発に生き残ったのは、偶然ではない。文化、組織、意思決定構造、そして恐怖――それらが絡み合った結果として、DRBFMは“必要不可欠なもの”に見える存在へと変質していった。そしてこの構造の帰結として、現場には「どこまで深掘りすれば終わるのか分からない」DRBFMが残ることになった。 次章では、その象徴的な姿である「無限深掘り」という地獄について、さらに踏み込んでいく。 4.ソフトウェア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と距離を取るための現実的な道筋について考えていく。 (日吉 昭彦)