Updates

新着情報

Webinar

B'live SEP2026 Webinar　「なぜ今、社内アセッサ育成なのか？」 ～組織的改善の質を高めるチェンジメーカーのススメ～

「改善活動は行っているものの、なかなか成果につながらない」 「成熟度レベルの達成が目的化し、その先の改善につながらない」 そんな課題を感じていませんか？ 変化が激しく複雑化する時代において、企業には継続的に改善し続ける力が求められています。その中で重要な役割を担うのが、組織の課題を可視化し、現場と管理層をつなぎながら改善を促進する社内アセッサです。 これからの社内アセッサに求められるのは、単なる「評価者」ではありません。改善の方向性を示し、関係者を巻き込みながら変革を推進するチェンジメーカーとしての役割が期待されています。 B'live SEP2026 Webinarでは、✅ なぜ今、社内アセッサ育成が求められるのか✅ チェンジメーカーとしての社内アセッサの役割✅ 組織的改善の質を高める社内アセスメント✅ ビジネスガレージが提供する社内アセッサ育成プログラムについて、実践的な視点から分かりやすく解説します。 「評価のためのアセスメント」から「改善を促進するアセスメント」へ。組織の改善力向上や、社内アセッサの育成・活用を検討されている皆さまのご参加をお待ちしております。 参加ご希望の方は、こちらのページからお申込みください。

お知らせ

「プロセスって何？」を改めて考える。B'talk #02動画をYouTubeに公開しました！

「うちにはプロセスがないんです。」改善活動や品質向上のご相談を受ける中で、この言葉を耳にすることがあります。しかし、本当にプロセスは存在しないのでしょうか。実は、成果物が生み出されている以上、そこには必ず何らかのプロセスが存在しています。問題は「ない」ことではなく、「見えていない」ことかもしれません。今回公開した動画シリーズ B'talk #02『プロセスとは何か？』 では、HPコラム執筆の背景を交えながら、 プロセスとはそもそも何か なぜプロセスが現場で使われなくなるのか 日本企業と海外企業の考え方の違い プロセス改善が失敗する本当の理由 良いプロセスを設計するために大切な視点について語っています。「プロセスを守りましょう」という話ではありません。私たちが伝えたいのは、『プロセスはルールではなく、結果をコントロールする仕組みである』という考え方です。 業務改善や品質向上に取り組む方はもちろん、組織運営やマネジメントに関わる方にもぜひご覧いただきたい内容です。▶本動画の元となったHPコラムはこちら⇒https://www.bgarage.co.jp/news/1223/▶B’talk #02（YouTube動画）はこちら⇒https://youtu.be/RYHnWOIQ_t0

コラム

構成管理の基本の「ほ」　～構成管理の要ベースライン／ブランチ／マージを正しく理解する～

はじめにDXやアジャイル開発が進展するなかで、多くの企業がGitやAzure DevOps、GitHubなどの構成管理ツールを活用しています。しかし、ツールを利用していても、「ベースライン」「ブランチ」「マージ」という基本概念を十分に理解していないために、手戻りや品質事故を招くケースは少なくありません。本稿では、過去のコラム「構成管理の基本の「き」～当たり前なことが難しい～」に引き続き、構成管理の中核をなす3つの考え方について解説します。 ベースラインとは何かベースラインとは、一言で言えば「正式に承認された基準点」です。システム／ソフトウェア開発では、 要件定義書 基本設計書 詳細設計書 ソースコード テスト仕様書などが特定の時点で確定し、「この版を正式版として扱う」と決定された状態を指します。例えば、要件定義が完了した時点で「Version 1.0」としてベースライン化すると、その後の変更はすべて変更管理プロセスを経て実施されます。 ベースラインの主な目的は以下の3つです。 変更点を明確にする基準となる版が存在するため、「何が変わったのか」を客観的に把握できます。 品質を保証するレビューや承認を経た成果物を固定化するため、品質が確認された状態を維持できます。 トレーサビリティを確保する障害発生時に「リリースされたどの版で障害発生したのか」を追跡できるようになります。 ベースラインがないプロジェクトでは、「最新版がどれかわからない」という事態が頻発し、品質問題の原因となります。成果物をベースライン対象とするかどうかを判断する決定要因は、その成果物の情報が、プロジェクトにおいてライフサイクル上の過去のベースライン状態へ戻して、そこから再び開発し直したり、再統合をする際に必要となるかどうかによります。 ブランチとは何かブランチ（Branch）は、ベースラインから派生した作業用の分岐です。道路に例えるなら、高速道路の本線から伸びる側道のようなものです。ブランチを利用することで、マスターとなるベースライン内の成果物に影響を与えず、新しい機能開発や不具合修正を進められます。ブランチを利用する理由例えば、製品バージョン1.0がテスト中の状況を考えます。同時に、「新機能開発」「緊急障害対応」「次期バージョン開発」を進める必要がある場合、単一のソースコードでは管理が困難になります。そのため、main├─ new_feature-A├─ Gen_X└─ hotfixのように作業内容ごとにブランチを分けます。ブランチのメリット 並行開発が可能複数の開発者が独立して作業できます。 リスクを低減できる開発途中のコードを本番環境に混在させる必要がなくなります。 変更管理がしやすい機能単位で変更履歴を追跡できます。近年ではGit FlowやGitHub Flowなどの運用モデルが広く採用され、ブランチ戦略そのものが開発プロセスの重要な要素となっています。 マージとは何かマージ（Merge）とは、分岐したブランチの成果を統合する作業です。ブランチで開発した機能を本流（マスタ）へ取り込むことで、成果物として正式版として利用可能になり、他プロジェクトへの転用等が可能な状態になります。マージで発生する課題マージは単純な結合作業ではありません。複数人が同じ成果物を修正している場合、変更競合が発生します。これを「コンフリクト（Conflict）」と呼びます。コンフリクトが起きた場合は、どちらの変更を採用するかを判断しなければなりません。良いマージのためのポイント 小さく頻繁に統合する長期間ブランチを放置すると差分が大きくなり、マージが困難になります。 コードレビューを実施するマージ前に内容を確認することで品質を向上できます。 自動テストを活用するマージによる不具合混入を防止できます。 ベースライン・ブランチ・マージの関係この3つは独立した概念ではなく、一連の流れとして機能します。 つまり、 ベースラインが基準を作る ブランチが変更作業を可能にする マージが変更を統合するという役割分担になっています。そして、マージ後に新たなベースラインを設定することで、次の開発へ進みます。 「ベースライン」「ブランチ」「マージ」を活用した事例は以下のようになります。 この例では、おおよそ以下のように活用しています。 マスターラインで正式なベースラインを作成し、次期バージョン用の開発ラインのブランチを作成する 開発ラインから、必要に応じて、機能追加や機能変更を並行開発するための開発ブランチ１＆２を作成する マスターラインの不具合対処するため、緊急対応するためのブランチを作成し、対応完了＆承認後にマージする レビューを経て、品質保証されたものを、開発ブランチから開発ラインにマージする リリースが認められたものを、開発ラインからリリース用のブランチを作成する リリースされたものをマスターラインにマージし、新しいベースラインを作成する さいごに構成管理は単なるバージョン管理ではありません。組織として成果物の品質と整合性を維持するための重要な仕組みです。 ベースラインは「公式な基準点」 ブランチは「安全な作業領域」 マージは「成果物の統合」という役割を理解することが重要です。プロジェクトの規模が大きくなるほど、この3つの適切な運用が、生産性と製品品質に直結します。構成管理ツールの機能を使いこなすだけではなく、その背景にある構成管理の考え方を理解することが、変化に強い開発組織への第一歩となるでしょう。 内山哲三

B'zine

B'zine 2026年7月号（B'liveJUL2026：構成管理DX等）を発行しました

B'zine 7月号を発行いたしました。ショート動画も公開していますので、弊社公式YouTubeより是非ご視聴ください。B'zineは、１回/月のペースでの配信しています。ご興味のある方は、ここから登録をお願いいたします。  B'zineビジネスガレージ通信（2026年7月号） B’zine ビジネスガレージ通信（2026年7月号） お届けします。連日の酷暑日（40°C超）、集中豪雨による崖崩れや浸水、大地震発生等による体調不良や被害に遭われた皆様へ、心よりお見舞い申し上げます。一日も早い回復・復旧をお祈りいたします。 【今月のトピックス】 イベント：７月３０日（木）B'live JUL2026 Webinar開催：人手運用から脱却する構成管理DX ～ Power Platformで実現する構成管理ロボの導入事例 ～ イベント：B'live SEP2026 Webinar（予定）：なぜ今、社内アセッサ育成なのか？組織的改善の質を高めるチェンジメーカーのすすめ イベント：Automotive SPICE 入門一般開催トレーニング（8月開催）のご案内 コラム：技術が伝わらないのはなぜか -- 技術継承（前編）：なぜ技術が現場に残らないのか コラム：役割名ではなく行動を定義する -- 責任割当てを機能させる方法 コラム：日本の車載ソフトウェア開発では、何故いまだにDRBFMが使われているのか（後編）〜生産性向上と品質維持に向けた提言〜 お知らせ：「AI連携サービス」を開始しました お知らせ：夏季休業のお知らせ - 8月8日（土）から8月16日（日）まで 【イベント】 2026年7月30日 B'live JUL2026 Webinar：人手運用から脱却する構成管理DX〜 Power Platformで実現する構成管理ロボの導入事例 〜人手で行われがちな構成管理や文書管理の運用を、Power Platform （PowerApps, PowerAutomate）とSharePointを活用して、効率化・自動化する実践事例を紹介します。採番はPowerApps、台帳登録はPowerAppsとSharePoint、バックアップはSharePointとPowerAutomateを組み合わせて、日常業務をどのように改善できるのか、現場視点で分かりやすく解説します。Automotive SPICE SUP.8（構成管理）の要求事項も考慮しましたので、ライトなSUP.8対応が可能となっております。日時：2026年7月30日（木）16:00 - 17:00詳細、お申し込みはこちらから→https://www.bgarage.co.jp/event/2141/  2026年9月B'live SEP2026 Webinar（予定）：なぜ今、社内アセッサ育成なのか？組織的改善の質を高めるチェンジメーカーのすすめ多くの企業において、改善活動が定着しないという課題が存在します。内部アセスメント活動そのものを育成の場とし、開発当事者がアセッサーとして「自ら考え、判断し、改善につなげる力」を持ったアセッサーを育成することで、組織プロセス成熟度の向上、品質および生産性の改善、さらには顧客からの信頼獲得といった、経営成果につながる価値創出を実現する方法をご紹介します。  Automotive SPICE 入門一般開催トレーニング（8月開催）のご案内Automotive SPICE 入門一般開催（8月分）の日程をご案内いたします。詳細およびお申込みは、下記リンクあるいは「イベント開催日程」からお願いいたします。Automotive SPICE 入門 管理支援編 2026年8月17日Automotive SPICE 入門 システムエンジニアリング編 2026年8月19日Automotive SPICE 入門 ソフトウェアエンジニアリング編 2026年8月26日Automotive SPICE 入門 ハードウェアエンジニアリング編 2026年8月28日参加申し込みはこちらから→https://www.bgarage.co.jp/news/2162/ 【コラム】 技術が伝わらないのはなぜか ～ 技術継承（前編）：なぜ技術が現場に残らないのか ～ソフトウェア開発の現場で、近年よく聞かれるようになった言葉があります。「若手が育たない」、「技術継承が進まない」、「同じ問題が、何度も繰り返される」これは単なる人材や教育の問題ではありません。本質は、開発の進め方そのものにあります。技術継承が進まない理由としては、人材不足、教育不足、外注依存、技術の高度化など、様々な要因が指摘されています。しかし、それだけではこの問題の本質を説明することはできません。本コラムは前後編で構成しています。前編では、技術継承が進まない要因を整理し、後編では、AI時代も見据えた上で、どのようにこの課題に向き合うべきかを考えます。本編ではまず、この問題を人材や教育の観点ではなく、開発の進め方やプロセスの運用という観点から整理します。詳細はこちら→https://www.bgarage.co.jp/news/2121/  役割名ではなく行動を定義する：責任割当てを機能させる方法Automotive SPICEのアセスメントを行っていると、GP2.1.4（Assign Responsibility）は比較的達成しやすいプラクティスに見えます。組織図があり、役割一覧があり、RACI表も整備されている。Project Manager、Quality Assurance Manager、Configuration Managerといった役割も定義されている。そのため、多くの組織は「責任の割当てはできている」と考えます。しかし、インタビューを進めると次のような声を耳にすることがあります。「Project Managerを任されていますが、実際には何をすればよいのでしょうか。」「Configuration Managerになったのですが、どこまでやれば責任を果たしたことになるのでしょうか。」役割は存在しているのに、その役割を担う本人が何を行うべきか分からないのです。これは決して珍しい話ではありません。むしろ多くの組織が直面する共通の課題ではないでしょうか。詳細はこちら→https://www.bgarage.co.jp/news/2212/  日本の車載ソフトウェア開発では、何故いまだにDRBFMが使われているのか（後編）〜生産性向上と品質維持に向けた提言〜前編では、日本の車載ソフトウェア開発の内部構造に焦点を当て、DRBFMがなぜ重く、そして終わらないプロセスとして運用されるようになったのかを見てきた。では、このような運用は、ソフトウェア開発全体に共通するものなのだろうか。結論から言えば、そうではない。車載以外のソフトウェア開発において、DRBFMはほとんど使われていない。これは欧米だけの話ではない。日本国内においても、Webサービス、業務システム、モバイルアプリケーション、さらには通信機器や一般的な組み込み分野において、DRBFMが品質保証の中心に据えられることは稀である。この事実は重要である。問題は、DRBFMが「普及していない」ことではない。むしろ、そもそも必要とされていないことにある。詳細はこちら→https://www.bgarage.co.jp/news/2078/  【お知らせ】 「AI連携サービス」を開始しました「AI連携サービス」として以下の２つのサービスを開始しました。１）要求仕様書作成支援サービス２）FMEA作成支援サービス詳細はこちら→https://www.bgarage.co.jp/business/aiservices/  夏季休業のお知らせ2026年8月8日（土）から2026年8月16日（日）まで夏季休業とさせていただきます。休業期間中にいただきましたお問い合わせにつきましては、8月17日（月）以降、順次対応させていただきます。

コラム

プロジェクト管理トレーニングを「良かった」だけで終わらせない、3つの仕掛け

プロジェクト管理トレーニングやAutomotive SPICE教育を実施しても、現場の行動がなかなか変わらない。車載システム・ソフトウェアの開発現場では、こうした悩みを抱える管理者や改善推進メンバーの方も多いのではないでしょうか。せっかく時間とコストをかけて実施するトレーニングです。できることなら、知識の習得だけで終わらせず、現場での行動変容や成果創出につなげたいものです。今回は、なぜトレーニング後に現場が変わらないのか、そして教育効果を現場へ定着させるために必要なことについてお伝えします。 ◇「トレーニングは良かった。でも現場は変わらなかった。」Automotive SPICEやプロジェクト管理のトレーニングを受講したエンジニアが職場へ戻ると、気づけば以前と同じ仕事の進め方に戻っている。そんな経験はありませんか。トレーニング受講直後のアンケートでは、受講者から・「内容が分かりやすかった」・「新たな気づきがあった」・「業務に役立つ知識を得られた」といった前向きな評価が並びます。しかし数か月後になると、現場では大きな変化が見られない。結果として、・「トレーニングの効果が見えない」・「教育投資が成果につながらない」・「また単なるトレーニングイベントで終わってしまった」という声が聞かれるようになります。 ◇現場が変わらないのは、受講者の問題ではないこのような状況になると、「学んだことを実践しなかったのではないか」「受講者の意識が低かったのではないか」という話になりがちです。しかし、多くの場合、受講者個人の問題ではありません。トレーニングで学んだ内容を現場で試す機会がなく、周囲も同じ考え方や共通言語を持っていない環境では、行動を変えることは容易ではないからです。たとえば、プロジェクト管理トレーニングでリスク管理やスコープ管理の重要性を学んだとしても、実際のプロジェクトで活用するきっかけがなければ、その知識は定着しません。また、受講者が新しい考え方を持ち帰ったとしても、・上司が同じ概念を理解していない・チーム内で共通認識がない・実践を振り返る場がないという状況では、学びを継続的な行動へつなげることは難しくなります。車載システムやソフトウェアを含む自動車開発の現場では、品質問題への対応や開発スケジュールの遵守が優先されます。そのため、新しい取り組みを試そうとしても、目の前の業務に追われて従来のやり方へ戻ってしまうケースは少なくありません。つまり、現場が変わらない原因を個人に求めるのではなく、学びを定着させる仕組みの有無に目を向けることが重要なのです。 ◇トレーニング効果の定着に必要なのは「仕掛け」プロジェクト管理トレーニングを実施しても現場が変わらない理由は、受講者の問題ではなく定着の仕組みにあります。Automotive SPICE教育にも通じる、現場で使える3つの仕掛けを解説します。 ① トレーニング直後に小さく試せる実践の場をつくる学んだ知識は、できるだけ早く現場で使うことが重要です。例えば、・WBSを見直す・スコープを整理する・リスク一覧を作成する・ステークホルダーを洗い出すといった小さな取り組みでも構いません。知識を実際の業務へ適用することで、「知っている」が「使える」に変わります。 ② 管理職も同じ共通言語を持つ受講者だけが学んでも、現場での実践につながらないことがあります。たとえば、受講者がスコープ管理やリスク管理の考え方を学んでも、上司やプロジェクトマネージャーがその考え方を理解していなければ、日常業務の中で活用する機会は限られてしまいます。そのため、管理職向けにも同じ概念を理解する機会を設けることが重要です。必ずしも受講者と同じ内容をすべて受ける必要はありません。管理職向けの短時間セッションや事前説明会を通じて、現場で使う言葉をそろえるだけでも効果があります。例えば、日常のレビューや進捗確認の場で、・「スコープは明確になっているか」・「リスクは可視化されているか」・「この報告から何を判断するのか」といった会話ができるようになると、トレーニングで学んだ内容が現場に定着しやすくなります。 ③ 定期的な振り返りの場を設ける人は学んだ内容を時間とともに忘れてしまいます。そのため、「1か月後」、「3か月後」、「半年後」といったタイミングで実践状況を確認し、振り返る機会を設けることが重要です。取り組みの成功事例や課題を共有することで、知識が経験となり、組織に定着していきます。 ◇私たちが目指すのは「受講前後で成長を実感できるトレーニング」先日、ある企業様向けにプロジェクト管理トレーニングを実施しました。このトレーニングでは、プロジェクト管理に必要な6つの要素について講義を行うだけでなく、実際の業務を題材としたワークショップも実施しました。ワークショップでは、実際の開発プロジェクトを想定して、スコープの整理やリスクの洗い出し等をグループで検討し、受講者同士で議論をする場を設けました。各自が自身のプロジェクトに置き換えて考えることで、一方的に知識を受け取るのではなく、「自分ならどう活用するか」を深く考えていただくことができました。受講者からは、・「スコープ管理をする中で、やることとやらないことを明確にする重要性を学べた」・「各種報告は義務ではなく、自身の判断精度を高めるためのものであることを理解できた」といった声をいただいています。私たちが大切にしているのは、講師から受講者への一方通行の座学ではありません。受講者の皆さまと一緒に考え、議論し、気づきを得ながら学ぶことです。そして、受講前と受講後で何が変わったのかを実感できるトレーニングを提供することです。 ◇トレーニングを「イベント」で終わらせないために教育の目的は、トレーニングを実施することではありません。現場の行動が変わり、プロジェクトの成果につながることです。もし、・「Automotive SPICE教育を実施しているが定着しない」・「プロジェクト管理スキルを向上させたい」・「トレーニング効果を現場改善につなげたい」・「開発組織の共通言語を作りたい」そんな場合は、まずはお気軽にご相談ください。私たちはトレーニング単体ではなく、現場への定着までを含めて一体で設計します。「またトレーニングが無駄になった」と感じる前に、教育を成果へ変える仕組みづくりを一緒に考えてみませんか。 ▼プライベートトレーニングラインナップはこちらから→https://www.bgarage.co.jp/service/training/ ▼ご相談・お問い合わせはこちらから→https://www.bgarage.co.jp/contact/ （長澤克仁）

お知らせ

Automotive SPICE 入門　一般開催トレーニング（９月開催）のご案内

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

お知らせ

新サービス「AI連携サービス（要求仕様書作成、FMEA作成支援など）」提供開始のお知らせ

平素より格別のご愛顧を賜り、誠にありがとうございます。このたび当社では、開発現場における品質向上と業務効率化を支援する新サービスとして、「AI連携サービス」の提供を開始いたしました。第一弾として、以下のサービスをご提供いたします。 要求仕様書作成支援サービス FMEA作成支援サービスまた、現在、要求仕様書検証サービスのリリースに向けて準備を進めております。AI連携サービスに込めた想い生成AIの進化により、開発現場ではさまざまな業務を効率化できる時代になりました。しかし、私たちはAIが人の知識や経験、判断そのものを置き換えるとは考えていません。AIは優れた文章生成や分析支援の能力を持つ一方で、本当に重要なのは、その結果をどのように活用し、品質向上やより良い意思決定につなげるかです。私たちは、長年培ってきた要求分析、品質・安全分析、開発プロセス改善の知見と生成AIを組み合わせ、お客様の業務に無理なく定着する実践的なAI活用を支援します。単にAIを導入するのではなく、現場で発生している課題の本質を捉え、人とAIがそれぞれの強みを活かしながら成果を生み出せる環境を構築することを目指しています。 私たちは、単にドキュメント作成や分析業務の工数を削減することだけを目的にしていません。本当に目指しているのは、エンジニアや開発担当者が定型的な作業に追われる時間を減らし、本来注力すべき課題解決や意思決定、品質向上のための検討に集中できる状態をつくることです。AIのスピードと、弊社コンサルタントが持つ品質・安全分析や開発プロセス改善の知見を組み合わせることで、これまで負荷の高かった業務を、より高い価値を生み出す活動へと変革していきます。 私たちの強みはAIそのものではありません。開発現場を深く理解したコンサルタントが、AIを実務で成果につながる形に落とし込み、お客様の開発プロセス全体の進化を支援できることです。AIを導入することが目的ではありません。AIを活用しながら、お客様の開発プロセスそのものを進化させること。それが私たちの提供するAI連携サービスの価値です。提供サービス■ 要求仕様書作成支援サービス生成AIと要求分析の専門知見を組み合わせ、顧客要求や企画書、既存資料などをもとに要求仕様書のドラフト作成を支援するサービスです。要求の抜け漏れや曖昧さの早期発見を促し、レビューの効率化や品質向上、開発期間の短縮に貢献します。 ■ FMEA作成支援サービス生成AIと品質・安全分析の知見を組み合わせ、FMEAの初期案作成やリスク分析を支援するサービスです。故障モードや故障原因、影響分析などの検討を効率化しながら、エンジニアが本来注力すべき重大リスクの見極めや対策検討に集中できる環境づくりを支援します ■ 要求仕様書検証サービス（近日リリース予定）要求仕様書に含まれる曖昧な表現や記載漏れ、不整合などを分析し、上流工程での品質向上を支援するサービスです。開発後の手戻りや認識齟齬の低減に貢献します。 AI連携サービスの詳細については、こちらのページをご覧ください。 今後も当社は、AI技術と開発現場で培った知見を融合し、お客様の開発プロセス改革と品質向上に貢献してまいります。お気軽にお問い合わせください。

コラム

日本の車載ソフトウェア開発では、何故いまだに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が価値を持つ場面は残る。たとえば、プラットフォーム変更のように設計の前提そのものが変わる場合である。既存のアーキテクチャや過去の実績が、そのまま使えるとは限らない。このような場面では、関係者の知見を集め、想定外の影響を広く検討することに意味がある。また、これまでにない新規機能を導入する場合も同様である。既存の設計に収まらない新しい振る舞いが入る場合、影響範囲を設計だけで完全に説明しきれないことがある。さらに、安全クリティカルな領域では、設計として説明できていても、追加的なリスク検討が求められる場合がある。こうした場面では、DRBFMのような多面的な議論が有効に働く余地はある。つまり、DRBFMが価値を持つのは、設計や通常の変更管理だけでは扱いきれない不確実性が残る場面である。 「全部やる」から「必要なところだけやる」へ問題は、DRBFMが存在することではない。問題は、それが本来の使いどころを超えて、あらゆる変更に適用されていることである。設計で説明できることまでDRBFMに流れ込めば、議論は重くなる。検討範囲の境界が曖昧になり、完了条件も見えにくくなる。その結果として、現場は「念のため」の検討に追われる。これから必要なのは、DRBFMをやめることではない。DRBFMを必要なところだけに戻すことである。通常の派生開発や局所的な変更は、アーキテクチャ設計、変更管理、テスト、トレーサビリティで扱うべきである。一方で、設計前提そのものが変わる変更や、安全上の不確実性が大きい変更については、DRBFMで補完する価値がある。このように位置付け直せば、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は、日本独特の開発文化が生み出した産物である。そしてその存在は、私たちがまだソフトウェアを十分に工学として扱い切れていないことを映し出している。 だからこそ、変えなければならない。あなたの現場は、工学に向かっているだろうか。それとも、儀式を続けているだろうか。（日吉昭彦）

トップ新着情報

Contact Us

お問い合わせ

お客様のニーズに応じて、最適なサービスを展開しております。
まずはお気軽にご相談ください。

お問い合わせフォームはこちら