Updates

新着情報

B'zine

B'zine - 2026年2月号（構成管理の基本の「き」 など）を発行しました

B'zine 1月号を発行いたしました。動画版(約2分)も公開していますので、弊社公式YouTubeより是非ご視聴ください。https://youtu.be/UrJ9gq2mBJU     B'zineは、１回/月のペースでの配信しています。ご興味のある方は、ここから登録をお願いいたします。   B'zineビジネスガレージ通信（2026年2月号） B'zine 2月号をお届けします。太平洋側では乾燥による火事多発や取水制限のニュースが続いていました。ようやく待望のまとまった雨が降り、少し安心しましたが、まだダム貯水率はほとんど改善していないようです。もうすぐ春の行楽シーズン到来ですので、花粉対策や安全運転に十分留意され、観梅、観桜をお楽しみください。 【今月のトピックス】 イベント：第8回 ビジネスガレージオープンWebinar開催（2026/3/31） コラム：構成管理の基本の「き」～当たり前なことが難しい～ コラム：同じ失敗を繰り返さないプロジェクト管理 ─ 再発防止の実践ポイント 動画公開：なぜその要求は誤解されるのか？～ EARSで考える要求定義 ～ 【イベント】 2026年3月31日 Webinar（予定）：AIを活用した次世代要件分析プロセスの考察生成AIを活用したEARS形式の要求仕様作成手法を考察します。またAIを活用することで、従来手作業で実施していた要件分析プロセスが、どのように変更されるかを考えます。お申込みフォームは後日公開いたします。 今回のテーマ設定の背景 システム要求分析の基本フロー システム要求分析の生成AIを活用してみた 考察 最後に 【動画公開】 なぜその要求は誤解されるのか？先日開催した、「第7回 Webinar なぜその要求は誤解されるのか？～ EARSで考える要求定義 ～」の動画を、弊社公式 YouTube チャンネル に公開しましたのでお知らせいたします。ぜひ、ご視聴ください。詳細はこちらから→https://youtu.be/TbEu9Jwk5Ww 【コラム】 構成管理の基本の「き」～当たり前なことが難しい～システム開発／ソフトウェア開発の現場では、日々多くの変更が行われています。機能追加、バグ修正、設計変更。そのすべてがソースコードやドキュメントに影響を与えます。この変化の連続を“管理された状態”に保つための仕組みこそが 構成管理（CM） です。今回は、Automotive SPICEのプロセスの１つである、SUP.8：構成管理の基本について、IEEEなどの国際標準も交えて解説します。詳細はこちら→https://www.bgarage.co.jp/news/1725/ 同じ失敗を繰り返さないプロジェクト管理 ─ 再発防止の実践ポイント多くの開発現場では、重大な問題が発生した際に「過去にも似た状況があった」と振り返るケースが少なくないと言われています。もちろん、プロジェクトで起きる問題の形や影響はさまざまで、個別の技術的課題や外的要因によるトラブルも存在します。それでもなお、現場を振り返ると、同じような状況や判断の迷いが重なった結果として問題が再発しているケースが見受けられます。では、なぜ似たような失敗は繰り返されてしまうのでしょうか。詳細はこちら→https://www.bgarage.co.jp/news/1705/

お知らせ

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

Automotive SPICE 入門一般開催（４月分）の日程をご案内いたします。詳細およびお申込みは、下記リンクあるいは「イベント開催日程」からお願いいたします。 Automotive SPICE 超入門2026年4月02日詳細はこちらからAutomotive SPICE 入門 管理支援編2026年4月08日詳細はこちらからAutomotive SPICE 入門 システムエンジニアリング編2026年4月15日詳細はこちらからAutomotive SPICE 入門 ソフトウェアエンジニアリング編2026年4月21日詳細はこちらからAutomotive SPICE 入門 ハードウェアエンジニアリング編2026年4月22日詳細はこちらから  Teamsを使ったオンラインでの開催となります 教材は、原則開催日の５日前までにご指定場所に郵送いたします ご請求書はPDF版をメールで送付いたします お支払い期日は、ご請求書発行日の翌月末となります ご請求書発行後のキャンセルは、お断りしています（代理出席などの手配をお願いします） お申込者以外の方の聴講および録音は固く禁じます

Webinar

第８回 Webinar　AIを活用した次世代要件分析プロセスの考察　開催のご案内

第8回 Webinarは、生成AIを活用したEARS形式の要求仕様作成手法を考察します。またAIを活用することで、従来手作業で実施していた要件分析プロセスが、どのように変更されるかを考えます。 今回のテーマ設定の背景 システム要求分析の基本フロー システム要求分析の生成AIを活用してみた 考察 最後に 参加ご希望の方は、こちらのページからお申込みください。

コラム

同じ失敗を繰り返さないプロジェクト管理 ─ 再発防止の実践ポイント

■なぜ、あの失敗は何度も起きるのか？開発プロジェクトの合間に、こんな会話を耳にすることがあります。「この前も同じような問題があったよね？」「気を付けていたつもりだったけれど…また再発してしまった」こうした状況は決して珍しくありません。多くの開発現場では、重大な問題が発生した際に「過去にも似た状況があった」と振り返るケースが少なくないと言われています。もちろん、プロジェクトで起きる問題の形や影響はさまざまで、個別の技術的課題や外的要因によるトラブルも存在します。それでもなお、現場を振り返ると、同じような状況や判断の迷いが重なった結果として問題が再発しているケースが見受けられます。では、なぜ似たような失敗は繰り返されてしまうのでしょうか。 ■同じ失敗が起きる主な要因とは？ある車載ECU開発プロジェクトでの出来事です。当初のプロジェクトの目的は「画面表示の起動時間を短縮する」ことでした。ところが開発途中で、「起動時にロゴアニメーションを入れたい」「警告メッセージの表示仕様も変更したい」「診断ログも取得できるようにしてほしい」といった要望が追加され、チームは「せっかくなら対応しよう」と順次取り込みました。しかし、誰も「起動時間短縮が最優先なのか、それとも新機能追加なのか」を明確に整理しないまま進めたため、「あるメンバーは表示品質を優先」「別のメンバーは起動速度を優先」「別の担当は診断要件の網羅性を重視」と、目指すゴールが少しずつズレた状態で開発が進んでしまいました。その結果、統合テストの段階で「起動時間が目標を満たさない」「ログ取得時に表示が遅延する」といった問題が同時に発覚し、大きな手戻りが発生しました。さらに、スケジュール遅延の兆候は早い段階で見えていたにもかかわらず、「どの時点で誰に相談するか」「何を優先的に削るか」が決まっていなかったため、対応は常に後手に回りました。このような問題は以前にも何回か起きていたようです。 同じ失敗が繰り返される背景には、・目的と優先順位が共有されていない・問題発生時の動き方が決まっていないといった構造的な要因が背景にあるケースは少なくありません。目的が揃わないまま進めると、メンバーごとに判断基準がばらつき、問題が起きても対応の優先度や対処方針が統一されません。さらに、初動対応やエスカレーションのルールが明確でない場合、対応は場当たり的となり、問題の影響が拡大しやすくなります。その結果、納期や目先の対応を優先した暫定対処で収束させてしまい、根本原因が解消されないまま次のプロジェクトへ持ち越されます。そして同様の条件が重なったとき、類似したトラブルが再び発生する可能性が高まります。 ■成功するプロジェクトが共通して実践している取り組み前述の例のように、失敗の原因は個人の注意不足だけでなく、目的の共有不足や優先順位の不明確さ、問題発生時の対応ルールの欠如といった“進め方の仕組み”に起因しています。では、同じ状況に直面しても手戻りを最小限に抑え、着実に成果を出し続けるチームは、どのような工夫をしているのでしょうか。私の経験を基に、実際に効果のあった取り組みの一例をご紹介します。 1. 要求分析と優先順位決定プロセスを機能させる要求が増え続けること自体は珍しいことではありません。問題は、優先順位を判断する基準や変更時の意思決定プロセスが明確でない場合、チーム内で判断軸がばらつくことです。成功している組織では、 最優先事項を判断する基準を定める 要求変更時に影響範囲（品質・性能・日程）を確認する 優先順位を見直す意思決定ルールを設けるといった仕組みによって、要求分析プロセスが機能する状態を維持しています。例えば、変更要求が出た際に「最優先目標に影響しないか」を確認するチェック項目を設けるだけでも、判断のばらつきを抑えることができます。 2. 問題の早期解決を支える支援・エスカレーションの仕組みプロジェクトは計画通りに進まない状況が発生することを前提に運営する必要があります。重要なのは、問題が顕在化した際に 誰が・どの段階で・どこへ相談するのか が明確になっていることです。とある組織では、進捗管理・課題管理・リスク管理といった基本的なプロジェクト管理プロセスは整備されています。そのうえで、現場だけでは判断が難しい状況に備え、経験豊富なPMや技術リーダーが横断的に支援する仕組みを設けています。現場ではこれを通称「駆け込み寺」と呼んでいます。この仕組みの目的は属人的な助言ではなく、 進捗遅延や品質リスクの早期検知 判断に迷う局面での意思決定支援 問題対応の優先順位整理 組織としての対応方針の統一といった、プロジェクト運営プロセスを補完・強化することにあります。このような支援体制は大掛かりな組織でなくても導入可能です。例えば、 PM経験者が週1回相談枠を設ける リスク顕在化時の相談ルートを明文化する 重要課題をレビューする横断ミーティングを設けるといった小さな仕組みから始めることもできます。 3. 振り返りを“教訓化”につなげる仕組み振り返りの重要性は多くの現場で理解されています。しかし実際には、「事実の整理で終わってしまう」「個人の反省に留まる」「次のプロジェクトに活かされない」といったケースが少なくありません。効果的な振り返りを行う組織では、 結果の整理 原因の特定 再発防止策の決定 次回の実行ルールへの反映をセットで行います。例えば、再発防止策をチェックリストや標準手順に反映し、次プロジェクト開始時に確認する仕組みを設けることで、経験を組織の資産として蓄積できます。 ■あなたのチームでは、同じ兆候が起きていませんか？失敗の再発は偶然ではなく、進め方の仕組みに起因することが少なくありません。そして、その仕組みを整えることで、同じ問題が繰り返される可能性は大きく減らすことができます。ここまでお読みいただき、「自分たちの現場にも当てはまる」と感じられた方も多いのではないでしょうか。例えば、次のような兆候は見られませんか？☑ チーム内の意思疎通に不安がある☑ 課題が何度も再発し、改善が定着しない☑ プロジェクト管理が“実態と合っていない”と感じる☑ 組織としてのプロセスを整えたいが、どこから手を付けるべきかわからないもし一つでも思い当たる点があれば、それは個人の努力ではなく、仕組みを整えることで改善できる余地があるというサインかもしれません。 「自社ならどこから手を付けるのが最短か」を整理したい場合は、1～2週間のクイック診断からご支援することも可能です。小さく始めて、現場に無理なく定着させる改善をご一緒に進めていきます。まずは、現状の困りごとや課題をお聞かせいただくだけでも構いません。 ご相談・お問い合わせはこちらから→https://www.bgarage.co.jp/contact/ （長澤克仁）

コラム

構成管理の基本の「き」　～当たり前なことが難しい～

はじめに システム開発／ソフトウェア開発の現場では、日々多くの変更が行われています。機能追加、バグ修正、設計変更。。。そのすべてがソースコードやドキュメントに影響を与えます。この変化の連続を“管理された状態”に保つための仕組みこそが 構成管理（CM） です。今回は、Automotive SPICEのプロセスの１つである、SUP.8：構成管理の基本について、IEEEなどの国際標準も交えて解説します。 なぜ構成管理が必要なのか 構成管理がうまく機能していない現場では、こんな光景がよく見られます。 “誰が”“いつ”“どこを”“なぜ”変更したのか追跡できない 昨日の動くバージョンに戻したいのに、戻せない ドキュメントと実物が噛み合わず、レビューで混乱 変更したつもりが、別の人の作業で上書きされていたこれらはすべて、生産性と品質を静かにむしばむ“構成管理不足”のサインです。構成管理の目的は一言でいえば、変更の見える化と安定した開発の継続です。 構成管理の主要な4つの活動 １．構成識別（Configuration Identification）まず管理対象となる作業成果物を明確にします。この管理対象を構成品目（Configuration Item：CI）と呼びます。ソースコードはもちろん、設計書、テスト仕様書、ビルド手順書など、作業成果物すべてが対象となり得ます。どこまでを管理するのか最初に決めておくことが、とても重要です。Automotive SPICE v4.0では以下のように解説しています。 構成品目とは、単一の実体として構成管理の対象となる作業成果物または作業成果物一式を指す。 構成品目は、システム、ハードウェア、およびソフトウェアのすべての文書を含むシステム全体から、単一のエレメントまたは文書に至るまで、複雑性、規模、および種類が異なる場合がある。  選定基準は、単一の作業成果物または作業成果物一式に適用してよい。また国際標準である、IEEE 828「IEEE Standard for Configuration Management in Systems and Software Engineering」では、以下のように定義しています。 構成管理のために指定され、構成管理プロセスにおいて単一のエンティティとして扱われる作業成果物の集合体。 構成品目は、その複雑さ、規模、種類が多岐にわたる場合があり、ハードウェア、ソフトウェア、ドキュメントをすべて含むシステム全体から、単一のモジュールやマイナーなハードウェアコンポーネントまで多岐にわたる。プロジェクトの範囲や、標準資産の再利用の考慮等によって、構成品目は様々ですが、必ずしも「１ファイル＝１構成品目」である必要がないことは上記からも理解できると思います。「単一の実態として扱われる作業成果物の集合体」が構成品目となります。 2. 構成制御（Configuration Control）構成管理の根幹となる活動は、変更手続きを管理し、変更を追跡することで、製品の構成が常に正確に把握されるようにすることです。構成制御は、ベースラインを完全に識別し、そのベースラインに対して行われたすべての変更を追跡することによって実現されます。Automotive SPICEではベースラインを以下のように定義しています。 1つまたは一連の作業成果物および生成物の一貫性が保たれ、かつ完成した状態であることを識別している。 次のプロセス段階および／または納入のためのベース。 一意であり、変更されてはならない。少しわかりづらいので、再びIEEE 828を参照してみましょう。以下のように定義しています。 正式にレビューされ合意された仕様または製品であり、その後は以降の開発の基礎となり、正式な手順を通じてのみ変更可能である。  媒体を問わず、構成アイテムのライフサイクル中の特定の時点で正式に指定及び確定された、構成アイテムの正式に承認されたバージョンである。 ソフトウェアベースラインとは、ソフトウェアライフサイクル中の特定の時点で正式に指定され、確定されたソフトウェア構成アイテムの集合（1つまたは複数）である。開発ライフサイクルのある時点（たとえば、要件が確定した時点や統合テストを始める時点）で、正式の合意された製品目一式がベースラインであり、以降の開発工程や納入の基となるものです。好き勝手に変更していけないのがベースラインであり、適切にベースライン（構成品目の集合体）を作成＆更新していくことが構成管理の根幹となります。この適切な作成＆更新を行うためには、正式な変更手順だけではなく、構成品目を格納する「ライブラリ」も重要となります。皆さんの中には既に、作業成果物の格納場所として、Git や Subversion などのツールを利用している方もいると思いますが、国際標準であるIEEE 1042「IEEE Guide to Software Configuration Management」で述べているライブラリの概念が基本となっています。   ダイナミックライブラリ（プログラマーズライブラリとも呼ばれる）： 新規作成または変更されたソフトウェアエンティティ（ユニット/モジュール、データファイル、および関連ドキュメント）を格納するために使用されるライブラリ。 これは、作業担当者がコード開発で使用するライブラリで、そのユニットを担当する作業者は、いつでも自由にアクセスできます。 これは作業者の作業スペースであり、作業者によって管理される。 管理ライブラリ（マスターライブラリとも呼ばれる）： 現在のベースラインを管理し、それらに加えられた変更を制御するために使用されるライブラリ。 これは、統合のために生成された構成品目のユニットとコンポーネントが保持されるライブラリ。 通常は検証後にエントリが認められる。 作業者やその他のユーザーが使用するために、コピーを作成できるが、このライブラリ内のユニットまたはコンポーネントへの変更は、責任部署（構成制御委員会または委任された権限を持つ機関）の承認が必要。 スタティックライブラリ（ソフトウェアリポジトリとも呼ばれる）： 一般利用のためにリリースされた様々なベースラインをアーカイブするために使用されるライブラリ。 これは、運用のためにリリースされた構成品目一式のマスターコピーが保管されるライブラリ。 これらのマスターのコピーは、要求する組織に提供される場合がある。 3. 構成ステータス記録（Status Accounting）構成管理下にある構成品目（作業成果物）に関する重要な情報を記録し、管理者と作業者に報告し、「構成品目が今現在どんな状態か」を共有することが、この活動の目的となります。IEEE 828では、構成品目のステータス情報は、以下のことに役立つと述べています。 ある期間における、プロジェクト作業の結果を把握し、とある時点での完了見込みを把握する。 例：要件の数と実装済みの数を比較することで、これまでの進捗状況を把握できる。  開発中の製品の安定性と機能の完成度に関する状態を把握する。 例：機能またはコンポーネントに対して、実装済みおよび保留中の変更の数は、安定性または変動性を示している。 構成品目の管理（構成管理活動自体）を検証する。 必要に応じて、外部コンプライアンス監査の要件（例：SOXなど）を満たす。「構成ステータス記録」は、構成管理活動自体を監視するプロジェクト管理機能でなく、あくまで構成品目（作業成果物）の状態を監視するものであることも理解しておく必要があります。 4. 構成監査（Configuration Audit）「管理されているはずの状態」が、本当に実態と一致しているかを確認する仕組みです。 ドキュメントの記載と成果物が一致しているか 承認フローが守られているか リリース物は正しい構成か監査は厳しいものではなく、「間違いが積み重なる前の安全装置」というイメージです。 構成管理はツールではなく「文化」Git や GitHub、Azure DevOps、Subversion などのツールは SCM を支える重要な存在ですが、ツールを導入しただけでは構成管理ができたとは言えません。大切なのは、そのツールを使って一貫したルールとプロセスを回し続ける文化があるかどうかです。例えば： ブランチ戦略をチームで統一する コードレビューをルール化する 変更理由を残す習慣をつける リリース手順を標準化するといった取り組みが、SCMの“文化”を育てます。 さいごに構成管理は、「開発を安定させるための基盤であり地盤」です。目立たない活動ですが、これがしっかりしているチームはトラブルに強く、改善サイクルも回しやすくなります。地盤が安定していれば、どんな大きな建物（＝プロジェクト）でも安心して積み上げることができます。  内山哲三 

YouTube

【Webinar動画公開】第7回 Webinar　なぜその要求は誤解されるのか？　～ EARSで考える要求定義 ～

先日開催した、「第7回 なぜその要求は誤解されるのか？～ EARSで考える要求定義 ～」の Webinar動画を、弊社公式 YouTube に公開しましたのでお知らせいたします。ぜひ、ご視聴ください。 ▼ご視聴はこちらから：https://youtu.be/TbEu9Jwk5Ww ▼タイムライン00:00 オープニング02:26 はじめに（なぜ要求は誤解されるのか）04:01 要求が誤解される典型パターン06:21 EARS記法とは何か（基本構造と考え方）33:59 誤解されやすい要求をEARSで書き直してみる49:21 EARSはどこまで使うべきか？（向き・不向き）50:58 要求定義改善への活かし方（現場適応のヒント）53:02 Q&A

B'zine

B'zine - 2026年1月号（Webinar開催～EARSで考える要求定義～など）を発行しました

B'zine 1月号を発行いたしました。動画版(約3分)も公開していますので、弊社公式YouTubeより是非ご視聴ください。https://youtu.be/oQXV0vb0hYU      B'zineは、１回/月のペースでの配信しています。ご興味のある方は、ここから登録をお願いいたします。   B'zineビジネスガレージ通信（2026年1月号） B'zine 1月号をお届けします。年が明けて一ヶ月弱経ちましたが、改めて新年明けましておめでとうございます。本年も引き続きB'zineご愛読の程、宜しくお願い致します。日本列島各地で大雪警報や寒波、乾燥による山火事を含む火災発生に加え、地震も頻発しています。皆様におかれましては災害、事故、健康には十分ご留意ください。 【今月のトピックス】 イベント：第７回 ビジネスガレージオープンWebinar開催（2026/1/27） イベント：2026年3月 Webinar（予定）：AIを活用した次世代要件分析プロセスの考察 資料公開：TestSPICE 概説資料を公開しました コラム：なぜ品質要件の問題はテスト段階で表面化するのか― 品質要件（非機能要件）の考え方と定義方法 ― コラム：プロセス改善コンサルティング、成功と失敗の分かれ道 【イベント】 2026年1月27日 Webinarなぜその要求は誤解されるのか？～ EARSで考える要求定義 ～ のご案内要求定義において「ちゃんと書いたはずなのに伝わらない」「レビューで解釈が割れる」といった課題に対し、要求が誤解される構造と、その解消手段としての EARS記法 を、事例を交えて解説します。日時：2026/1/27（火）16:00 – 17:00お申込みはこちらから→ https://www.bgarage.co.jp/news/1607/ 2026年3月 Webinar（予定）：AIを活用した次世代要件分析プロセスの考察生成AIを活用したEARS形式の要求仕様作成手法を考察します。またAIを活用することで、従来手作業で実施していた要件分析プロセスが、どのように変更されるかを考えます。詳細は、B’zineビジネスガレージ通信（2026年2月号）でお知らせします。 【資料公開】 TestSPICE概説資料を公開しましたIntacs から公開されている TestSPICE の概説書（テストに関わる人のための TestSPICE 概要）を作成いたしましたので公開いたします。ご興味のあるかたは、是非ダウンロードして活用してください。～「プロセス」から読み解くテストの極意～ はじめに TestSPICEの構成 プロセスアセスメント プロセス事例紹介4.1 テスト実行プロセス（TST）4.2 テスト自動化プロセス（TAU） おわりにダウンロードはこちらから→https://www.bgarage.co.jp/news/1651/ 【コラム】 なぜ品質要件の問題はテスト段階で表面化するのか  ─ 品質要件（非機能要件）の考え方と定義方法品質要件の問題は、なぜ見過ごされたまま進むのか組込み・車載ソフトウェア開発では、設計やテストの終盤になってから、・応答時間が間に合わない・負荷が高すぎて処理が破綻する・安全・セキュリティ要求が弱い・必要なログがなく原因が追えないといった問題が表面化することが少なくありません。実務を見ていると、その背景には大きく 2つのパターンがあります。パターンA：そもそも「ここで品質要件が必要だ」と気づけていないパターンB：品質要件は「あるが、疑われていない」品質要件の問題は、このように「書かなかった」からではなく、「気づけなかった／疑われなかった」ことによって起きているケースが多いと考えます。詳細はこちら→https://www.bgarage.co.jp/news/1643/ プロセス改善コンサルティング、成功と失敗の分かれ道Automotive SPICEやCMMIに準拠したプロセス改善を積極的に取り組む設計現場が広がってきている反面、改善の必要性を感じながらも、「本当にコンサルを入れるべきなのか」「また期待外れに終わってしまうのではないか」そんな迷いを抱えていらっしゃる方も多いのではないでしょうか。実際、私たちがこれまでご相談を受けてきた中でも、次のようなお声を耳にしてきました。「過去にコンサルを入れたが、やることだけが増えて楽にならなかった…」「立派な資料は残ったが、現場のやり方は結局変わらなかった…」「コンサルに頼ると、自分たちの力が育たない気がする…」これらは、決して珍しい意見ではありません。そして同時に、「コンサルティングサービスがうまく機能しなかった典型例」でもあります。詳細はこちら→https://www.bgarage.co.jp/news/1656/ 

トップ新着情報

Contact Us

お問い合わせ

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

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