Updates
VDA QMCより、Automotive SPICE v4.1（英語版）がリリースされました。日本語版は現在翻訳作業中のため、後日リリースされる予定です。合わせて、Automotive SPICE v4.1に対応する英語版ガイドライン（Automotive SPICE Guidelines 3rd revised edition）も販売開始されました。詳細は下記をご参照ください。https://vda-qmc.de/en/automotive-spice/automotive-spice-veroeffentlichungen/
B'zine 8月号を発行いたしました。ショート動画も公開していますので、弊社公式YouTubeより是非ご視聴ください。B'zineは、１回/月のペースでの配信しています。ご興味のある方は、ここから登録をお願いいたします。 B'zineビジネスガレージ通信（2026年8月号） B’zine ビジネスガレージ通信（2026年8月号） お届けします。夏季休暇が終わりましたが、皆様リフレッシュされたでしょうか？今夏は猛暑に加え、各地で地震発生、関東では台風や線状降水帯による洪水・浸水等の天災が頻発し、被災車両も計3,000台以上と報道されています。被害に遭われた皆様には心よりお見舞い申し上げますとともに、一日も早い復旧をお祈りいたします。 【今月のトピックス】 イベント：９月３０日（水）B'live SEP2026 Webinar開催：「なぜ今、社内アセッサ育成なのか？」組織的改善の質を高めるチェンジメーカーのススメ イベント：Automotive SPICE 入門一般開催トレーニング（9月開催）のご案内 コラム：プロジェクト管理トレーニングを「良かった」だけで終わらせない、3つの仕掛け コラム：コラム：構成管理の基本の「ほ」～ 構成管理の要ベースライン／ブランチ／マージを正しく理解する ～ コラム：技術は何を引き継ぐのか ～ 技術継承（後編）：AI時代に見えてきた「観点」の価値 ～ 動画公開：「プロセスって何？」を改めて考える。B'talk #02動画をYouTubeに公開しました！ お知らせ：新サービス「アセッサー育成プログラム」を開始しました 【イベント】 2026年9月B'live SEP2026 Webinar：「なぜ今、社内アセッサ育成なのか？」～組織的改善の質を高めるチェンジメーカーのすすめ～多くの企業において、改善活動が定着しないという課題が存在します。内部アセスメント活動そのものを育成の場とし、開発当事者がアセッサーとして「自ら考え、判断し、改善につなげる力」を持ったアセッサーを育成することで、組織プロセス成熟度の向上、品質および生産性の改善、さらには顧客からの信頼獲得といった、経営成果につながる価値創出を実現する方法をご紹介します。日時：2026年9月30日（水）16:00-17:00参加申し込みはこちらから→https://www.bgarage.co.jp/event/2391/ Automotive SPICE 入門一般開催トレーニング（9月開催）のご案内Automotive SPICE 入門一般開催（9月分）の日程をご案内いたします。詳細およびお申込みは、下記リンクあるいは「イベント開催日程」からお願いいたします。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日参加申し込みはこちらから→https://www.bgarage.co.jp/news/2345/ 【コラム】 プロジェクト管理トレーニングを「良かった」だけで終わらせない、3つの仕掛けプロジェクト管理トレーニングやAutomotive SPICE教育を実施しても、現場の行動がなかなか変わらない。車載システム・ソフトウェアの開発現場では、こうした悩みを抱える管理者や改善推進メンバーの方も多いのではないでしょうか。せっかく時間とコストをかけて実施するトレーニングです。できることなら、知識の習得だけで終わらせず、現場での行動変容や成果創出につなげたいものです。今回は、なぜトレーニング後に現場が変わらないのか、そして教育効果を現場へ定着させるために必要なことについてお伝えします。詳細はこちら→https://www.bgarage.co.jp/news/2310/ 構成管理の基本の「ほ」～構成管理の要ベースライン／ブランチ／マージを正しく理解する～DXやアジャイル開発が進展するなかで、多くの企業がGitやAzure DevOps、GitHubなどの構成管理ツールを活用しています。しかし、ツールを利用していても、「ベースライン」「ブランチ」「マージ」という基本概念を十分に理解していないために、手戻りや品質事故を招くケースは少なくありません。本稿では、過去のコラム「構成管理の基本の「き」～当たり前なことが難しい～に引き続き、構成管理の中核をなす3つの考え方について解説します。詳細はこちら→https://www.bgarage.co.jp/news/2367/ 技術は何を引き継ぐのか ～ 技術継承（後編）：AI時代に見えてきた「観点」の価値 ～前回のコラムでは、成果物だけでは技術は継承されず、判断の理由や背景を残すことが重要であると述べました。では、その判断の理由や背景とは何なのでしょうか。最近、様々な場面で生成AIを使うようになって、私はその答えが少し見えてきたように感じています。AIは知識や答えを提示してくれます。しかし、その答えを評価するために何を見るべきか、どこを疑うべきかまでは教えてくれません。だからこそ私は、技術継承で本当に引き継ぐべきものは、知識そのものではなく「判断軸」なのではないかと考えるようになりました。今回は、AIとの関わりを通して見えてきた技術継承の本質について考えてみたいと思います。詳細はこちら→https://www.bgarage.co.jp/news/2377/ 【動画公開】 B'talk#02：「プロセスって何？」を改めて考えるYoutube動画を公開しました「うちにはプロセスがないんです。」、改善活動や品質向上のご相談を受ける中で、この言葉を耳にすることがあります。しかし、本当にプロセスは存在しないのでしょうか。実は、成果物が生み出されている以上、そこには必ず何らかのプロセスが存在しています。問題は「ない」ことではなく、「見えていない」ことかもしれません。HP掲載コラム執筆の背景を交えながら、・ プロセスとはそもそも何か・ なぜプロセスが現場で使われなくなるのか・ 日本企業と海外企業の考え方の違い・ プロセス改善が失敗する本当の理由・ 良いプロセスを設計するために大切な視点について語っています。詳細はこちら→https://www.bgarage.co.jp/news/2396/ 【お知らせ】 「アセッサー育成プログラム」の提供を開始しました「アセッサー育成プログラム」として以下の２つのサービスを開始しました。１）社内アセッサー育成プログラム２）リードアセッサー育成プログラム詳細はこちら→https://www.bgarage.co.jp/news/2416/
※前編はこちら「技術が伝わらないのはなぜか ── 技術継承（前編）：なぜ技術が現場に残らないのか ──」 前回のコラムでは、成果物だけでは技術は継承されず、判断の理由や背景を残すことが重要であると述べました。では、その判断の理由や背景とは何なのでしょうか。最近、様々な場面で生成AIを使うようになって、私はその答えが少し見えてきたように感じています。AIは知識や答えを提示してくれます。しかし、その答えを評価するために何を見るべきか、どこを疑うべきかまでは教えてくれません。だからこそ私は、技術継承で本当に引き継ぐべきものは、知識そのものではなく「判断軸」なのではないかと考えるようになりました。今回は、AIとの関わりを通して見えてきた技術継承の本質について考えてみたいと思います。AIが見せてくれたもの生成AIに対しては、 なぜその答えになったのか分からない 結果が変わることがある 品質を保証しにくいといった声を耳にします。確かにその通りです。しかし考えてみると、私たちは人間の判断についても似たような状況を経験してきました。レビューの場で、ベテラン技術者から「その設計は危ない」と指摘されることがあります。その指摘は正しい場合が多いのですが、理由を聞くと、「以前、似たような案件で問題になった」「経験上、そのやり方はうまくいかないことが多い」といった説明になることも少なくありません。人間の判断もまた、完全に説明可能なものではありません。AIによって新しい問題が現れたというより、これまでも存在していた「判断の根拠」という課題が見えやすくなったのかもしれません。AIとの壁打ちで気付いたこと私の周囲でも、生成AIを使う際に「壁打ち」という言葉をよく耳にします。AIへ質問を投げ、自分の考えを整理しながら回答を改善していく使い方です。実際、この方法は非常に有効です。最初は曖昧だった考えが徐々に整理され、自分でも気付いていなかった論点が言語化されていきます。しかし一方で、AIとの壁打ちを重ねて自信を持って提出した成果物が、レビューであっさり否定されることもあります。むしろ、そのような経験の方が多いかもしれません。なぜでしょうか。それは壁打ちの出発点が常に自分だからです。AIとの対話は、自分の考えを深めることには適しています。しかし、自分が持っていない見方を発見することには限界があります。壁打ちは思考を深くしますが、必ずしも広くしてくれるわけではないのです。AIを使う中で私が強く感じたのは、良い答えを得るためには、良い知識以上に良い判断軸が必要だということでした。技術継承におけるレビューの本当の価値ここで改めてレビューの役割を考えてみます。前回、レビューは本来技術継承の場であったと述べました。現在のレビューは、記載漏れや規約違反の確認に重点が置かれることも少なくありません。しかし本来の価値はそこだけではありません。レビューの本質は、自分が持っていない見方と出会うことにあります。例えば、 開発者は性能を見る。 運用担当者は障害対応を見る。 保守担当者は将来の変更容易性を見る。 利用者は使いやすさを見る。それぞれ違う経験を持ち、違う切り口で成果物を見ています。だからこそ、一人では気付けない問題が見つかります。レビューについて議論する中で、「開発メンバだけによるレビューには限界がある。運用担当者や品質保証担当者、利用者など、異なる立場の人が参加することで初めて見えてくる課題もある」という考え方を耳にしたことがあります。当時はその重要性を十分理解できていませんでした。しかし今振り返ると、その本質は品質確認そのものではなく、多様な立場からの見方にあったように思います。レビューとは誤りを探す活動だけではありません。それぞれが持つ経験や着眼点を持ち寄り、自分一人では見えていなかった問題や課題に気付く活動でもあるのです。技術継承のために判断の背景を残すでは、そうした見方や考え方をどのように残していけばよいのでしょうか。必ずしも新しいツールや大掛かりな仕組みが必要なわけではありません。例えば設計書やレビュー記録に、「理由・根拠」欄を設けるだけでも状況は大きく変わります。多くのレビュー記録には、 指摘事項 対応内容 承認結果は残っています。しかし、 なぜその方式を選んだのか どのような代替案を検討したのか 何を重視して判断したのかといった情報は残らないことが少なくありません。例えば、以下の記載例のように、理由・根拠を一言記録するだけでも、その価値は大きく変わります。 【記載例】決定事項Redisによるキャッシュ方式を採用 理由・根拠非同期処理も検討したが、即時応答を優先するためキャッシュ方式を採用した。更新頻度が比較的低いことも判断材料とした。 後から参画した開発者は、採用された答えだけではなく、その背景にある考え方も理解できるからです。もちろん、これだけで十分というわけではありません。レビュー観点表やチェックシートを整備している現場は少なくありませんが、運用次第では単なる確認作業になってしまうこともあります。確認項目を一覧化することと、その背景にある考え方を理解することは同じではないからです。なぜその確認が必要なのか。どのような失敗や経験から生まれたものなのか。その背景まで共有されて初めて、本当の意味で技術継承につながります。しかし、その第一歩は判断や考え方を言語化し、残していくことだと思います。技術継承とは何を継承することなのか前回のコラムでは、「技術は成果物だけでは継承されない」という話をしました。今回さらに考えてみると、継承すべきものは知識やノウハウだけではないように思えてきます。近年では、ソフトウェア開発に限らず、様々な分野でベテラン技術者や熟練工のノウハウをAIへ残そうという取り組みも進んでいます。例えば設備保全の現場で、「この音がしたらベアリング交換だ」という熟練者の経験をAIへ学習させることは可能かもしれません。しかし本当に価値があるのは、その結論だけではありません。 なぜ異常だと判断したのか。 何を聞き分けていたのか。 他にどのような兆候を確認していたのか。そうした判断の背景や着眼点まで残せて初めて、技術継承として意味を持ちます。これはソフトウェア開発における設計判断とも本質的には同じです。もちろん知識は重要です。しかし知識だけでは、新しい問題には対応できません。本当に価値があるのは、 どのような前提を確認するのか 何を疑うのか どのような見方で捉えるのか どのように判断するのかという考え方です。つまり継承すべきものは、答えそのものではなく、それを導き出した判断の背景や見方なのではないでしょうか。技術継承とは、次の世代が自ら判断できる状態を作ることです。そのためには、結論だけではなく、 なぜそう考えたのか どのような選択肢を比較したのか 何を重視したのかを残していく必要があります。 まとめ前回のコラムでは、技術継承が進まない原因を開発の構造という観点から整理しました。今回のコラムでは、技術継承とは何を引き継ぐことなのかを改めて考えてみました。AIとの対話や人とのレビューを通じて見えてきたのは、技術継承の本質は知識や答えを残すことではなく、判断軸を残すことだということです。生成AIは多くの知識や答えを提供してくれます。しかし、何を問うべきか、どのような見方で物事を捉えるべきかといった判断軸までは与えてくれません。本当に重要なのは、何を見て、何を疑い、どのように判断するのかという考え方や観点を受け継ぐことです。技術を残すとは何を残すことなのか。もちろん、知識や答えを残すことは重要です。しかし、本当に継承したいのは、それらを生み出した人たちの考え方や観点なのではないでしょうか。次の世代が自ら考え、判断できるようになる。技術継承の本質は、そのための土台を残すことにあるように思います。 おわりに今回のコラムでは、技術継承の本質は知識や答えを引き継ぐことではなく、それらを生み出した判断の背景や観点を引き継ぐことにあるのではないか、という考えをお伝えしました。しかし、判断の背景や観点は、単に「残そう」と呼びかけるだけではなかなか組織に定着しません。実際には、 レビューの場が形骸化している 判断理由が成果物に残っていない ベテランの知見が属人化している 技術継承を進めたいが、何から着手すればよいか分からないといった課題を抱える組織も少なくありません。当社では、開発プロセスやレビューの進め方、ナレッジ共有の仕組みづくりなど、技術継承を支えるプロセス改善をご支援しています。「技術継承が人に依存している」「ベテランの退職が近づき不安を感じている」「AIを活用しながら知見を組織に残したい」そのような課題をお持ちでしたら、ぜひご相談ください。当社はプロセス改善の専門家として、技術継承が自然に行われる仕組みづくりをご支援します。知識や成果物だけでなく、判断の背景や観点まで組織の資産として残せるプロセスを共に考えていきます。（安部 宏典）
平素より格別のご愛顧を賜り、誠にありがとうございます。このたび当社では、Automotive SPICEに対応したアセスメント人材の育成と、お客様自身による継続的なプロセス改善を支援する新サービスとして、「アセッサー育成プログラム」の提供を開始いたしました。2つのサービスをご提供いたします。 社内アセッサー育成プログラム リードアセッサー育成プログラムアセッサー育成プログラムに込めた想いAutomotive SPICEへの対応において、アセスメントは単に顧客要求を満たすための審査ではありません。自社の開発プロセスの状態を客観的に把握し、本質的な課題を明らかにしたうえで、継続的な改善につなげるための重要な活動です。一方で、アセスメントやプロセス改善を外部の専門家に依存している場合、活動を通じて得られた知識や経験が社内に十分に蓄積されず、改善が一時的な取り組みにとどまってしまうことがあります。 私たちは、開発現場を理解する人材がアセッサーとして自ら考え、評価し、改善を推進することが、組織のプロセス成熟度を高めるうえで重要であると考えています。社内アセッサーとしてアセスメントに取り組むことで、Automotive SPICEというグローバルスタンダードを学ぶだけでなく、自社の開発プロセスを改めて理解し、世界標準とのギャップを認識できます。その過程で得られる知識、判断力、インタビュー経験は、座学だけでは身につけることのできない実践的な能力です。 さらに、社内アセッサーとして経験を積んだ人材や、intacs公認のプロビジョナルアセッサー資格を保有する人材が、公式アセスメントを主導できるリードアセッサーへと成長することで、社内におけるアセスメントとプロセス改善の推進力を一層高めることができます。リードアセッサーに求められるのは、Automotive SPICEの知識や評定技術だけではありません。プロジェクトの実態を正しく把握し、関係者との対話を通じて本質的な課題を明らかにするとともに、アセスメントチームをまとめ、組織をより良い方向へ導く力が必要です。 私たちは、単に資格を取得することをゴールとは考えていません。育成されたアセッサーが社内で継続的に活躍し、次のアセッサーを育て、改善の知識と経験を組織全体へ広げていくことを目指しています。外部に依存するアセスメントから、自社で考え、評価し、改善を主導する体制へ。アセッサー育成を通じて、お客様の組織に継続的な改善の文化を根づかせることが、私たちの提供するアセッサー育成プログラムの価値です。提供サービス■ 社内アセッサー育成プログラムAutomotive SPICEに対応したプロセス改善を、社内で自律的に推進するための人材育成プログラムです。実際の内部アセスメントを通じて、アセスメントの計画、インタビュー、評価、報告に必要な実践力を身につけます。社内アセッサーを中心とした継続的な改善体制を構築し、組織のプロセス成熟度向上と顧客対応力の強化を支援します。 ■ リードアセッサー育成プログラム社内アセッサーとして経験を積んだ方、またはintacs公認のプロビジョナルアセッサー資格を保有する方を対象に、公式アセスメントを主導できるリードアセッサーを育成するプログラムです。公式アセスメントへの参加を通じて、アセスメントチームの運営、インタビュー、評定の取りまとめ、結果報告などの実践力を養い、コンピテントアセッサー資格の取得を支援します。 アセッサー育成プログラムの詳細については、こちらのページをご覧ください。 今後も当社は、アセッサー人材の育成とプロセス改善に関する知見を活かし、お客様が自ら考え、評価し、改善を継続できる組織づくりを支援してまいります。Automotive SPICEへの対応、社内のプロセス改善体制の構築についても、ぜひお気軽にお問い合わせください。
「改善活動は行っているものの、なかなか成果につながらない」 「成熟度レベルの達成が目的化し、その先の改善につながらない」 そんな課題を感じていませんか？ 変化が激しく複雑化する時代において、企業には継続的に改善し続ける力が求められています。その中で重要な役割を担うのが、組織の課題を可視化し、現場と管理層をつなぎながら改善を促進する社内アセッサです。 これからの社内アセッサに求められるのは、単なる「評価者」ではありません。改善の方向性を示し、関係者を巻き込みながら変革を推進するチェンジメーカーとしての役割が期待されています。 B'live SEP2026 Webinarでは、✅ なぜ今、社内アセッサ育成が求められるのか✅ チェンジメーカーとしての社内アセッサの役割✅ 組織的改善の質を高める社内アセスメント✅ ビジネスガレージが提供する社内アセッサ育成プログラムについて、実践的な視点から分かりやすく解説します。 「評価のためのアセスメント」から「改善を促進するアセスメント」へ。組織の改善力向上や、社内アセッサの育成・活用を検討されている皆さまのご参加をお待ちしております。 参加ご希望の方は、こちらのページからお申込みください。
「うちにはプロセスがないんです。」改善活動や品質向上のご相談を受ける中で、この言葉を耳にすることがあります。しかし、本当にプロセスは存在しないのでしょうか。実は、成果物が生み出されている以上、そこには必ず何らかのプロセスが存在しています。問題は「ない」ことではなく、「見えていない」ことかもしれません。今回公開した動画シリーズ 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 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日（月）以降、順次対応させていただきます。