お知らせ
Automotive SPICE ガイドライン第３版のドラフトが公開されています
VDC QMDから Automotive SPICE Guidelines 3rd edition のYellow Book が一般レビュー用に公開されています。2026年5月12日までの期間でフィードバックを受け付けているようです。下記ページをご参照ください。
Updates
新着情報
B'zine
B'zine - 2026年3月号（Webinar：AIを活用した次世代要件分析など）を発行しました
B'zine 3月号を発行いたしました。動画版(約30秒)も公開していますので、弊社公式YouTubeより是非ご視聴ください。B'zineは、１回/月のペースでの配信しています。ご興味のある方は、ここから登録をお願いいたします。 B'zineビジネスガレージ通信（2026年3月号） B'zine 3月号をお届けします。お彼岸が過ぎて春らしい気候になり、桜も例年より若干早めに開花して本格的な行楽シーズン到来です。緊迫した中東情勢、エネルギー問題、物価高騰等、心配事は多いですが、美しい春の景色を眺めながらリフレッシュしたいですね。 【今月のトピックス】 イベント：3月31日（火）第8回 Webinar開催：AIを活用した次世代要件分析プロセスの考察 イベント：Automotive SPICE 入門一般開催トレーニングのご案内 コラム：ソフトウェア開発組織をどう評価するか ～エンジニアリングチーム全体を評価し、組織改善につなげるために ～ コラム：問題解決管理プロセスと変更依頼管理プロセスを両立させるために 【イベント】 2026年3月31日 Webinar：AIを活用した次世代要件分析プロセスの考察生成AIを活用したEARS形式の要求仕様作成手法を考察します。またAIを活用することで、従来手作業で実施していた要件分析プロセスが、どのように変更されるかを考えます。1. 今回のテーマ設定の背景2. システム要求分析の基本フロー3. システム要求分析の生成AIを活用してみた4. 考察5. 最後に詳細、お申し込みはこちらから→https://www.bgarage.co.jp/event/1774/ Automotive SPICE 入門一般開催トレーニングのご案内４月１５日（水）：Automotive SPICE入門システムエンジニアリング編４月２１日（火）：Automotive SPICE入門ソフトウェアエンジニアリング編４月２２日（水）：Automotive SPICE入門ハードウェアエンジニアリング編詳細、お申し込みはこちらから→https://www.bgarage.co.jp/event/ 【コラム】 ソフトウェア開発組織をどう評価するか ～エンジニアリングチーム全体を評価し、組織改善につなげるために ～ソフトウェア開発組織の改善を進めるうえで、 「何をもって良い組織と言えるのか」、「改善の効果をどう測るのか」は常に悩ましいテーマです。組織のエンジニアリングチームは「うまくいっているのか」,「何がボトルネックなのか」を感覚だけで語ることの限界を感じたことはないでしょうか。ソフトウェア開発は個人プレーではなく、プロセス・ツール・人の協働によって価値を生み出すチームスポーツと言ってもよく、改善の単位も「個人」ではなく、エンジニアリングチーム全体で捉える必要があります。詳細はこちら→https://www.bgarage.co.jp/news/1838/ 題解決管理プロセスと変更依頼管理プロセスを両立させるためにシステム開発／ソフトウェア開発は、一度作って終わりであることはまずありません。日々発生する不具合やトラブルへの対応と、顧客からの変更要求の対応や将来を見据えた改修の積み重ねによって支えられています。その中核を担うのが「問題解決管理プロセス」と「変更依頼管理プロセス」です。Automotive SPICEでは、支援プロセス「SUP.9」と「SUP.10」として定義されています。似ているようで役割の異なるこの2つを正しく理解し、連携させることが、システム開発／ソフトウェア開発プロジェクトの混乱と疲弊を避ける鍵となります。今回は「SUP.9」と「SUP.10」を両立させるヒントをお伝えします。詳細はこちら→https://www.bgarage.co.jp/news/1834/
コラム
Automotive SPICEは守っているのに、なぜ機能しないのか ― WhatとHowの混同から読み解く設計思想 ―
Automotive SPICE（A-SPICE）は、車載ソフトウェア開発におけるプロセス能力を評価するためのアセスメントモデルです。当社では先日、「ソフトウェア開発組織をどう評価するか ～エンジニアリングチーム全体を評価し、組織改善につなげるために～」というコラムの中で、SPICEを含む複数の枠組みを用いながら、開発組織をどのように評価し、改善につなげていくかを整理しました。また、これまでのコラムでも、「ドキュメントが作られているが活用されていない」「プロセスが形骸化している」といった課題が現場で起きやすいことを指摘してきました。 しかし、それらは“現象”としては共有されているものの、なぜ起きるのか、どうすれば防げるのかまでは十分に整理されていないケースも少なくありません。本コラムでは、これらの前提を踏まえたうえで、A-SPICEを「評価モデル」として説明するのではなく、「なぜその評価項目が定義されているのか」という観点から読み直します。言い換えると、A-SPICEを「評価のための枠組み」としてではなく、「開発で問題が起きやすいポイントを示した設計思想」として捉え直す試みです。現場でよく聞かれる、「やるべきことはやっているはずなのに、なぜかうまくいかない」という違和感を、この観点から整理していきます。 A-SPICEは「What」を定義するモデルであるA-SPICEはアセスメントモデルであり、「何ができているべきか（What）」を定義しています。例えば、 要求が適切に管理されていること レビューが実施されていること トレーサビリティが確保されていることといった状態が評価対象になります。一方で、A-SPICEは「それをどのように実現するか（How）」までは規定していません。 問題の本質：WhatをそのままHowにしてしまう現場でよく起きるのが、このWhatをそのままHowとして標準プロセスに落とし込んでしまうケースです。例えば、「レビューを実施する」という評価項目に対して、「レビューを実施する」という手順だけが定義される。一見すると問題はなさそうですが、ここには重要な抜けがあります。 具体例：レビューが“機能しない”ときに起きていることあるプロジェクトで、レビューは確実に実施されていました。チェックリストもあり、記録も残っています。しかし、後工程で仕様の解釈違いによる不具合が繰り返し発生していました。レビュー記録を見てみると、指摘の多くは 表記ゆれ 記述の抜け 軽微な整合性といったものでした。一方で、 前提条件の認識が揃っているか 想定しているユースケースが一致しているか 例外時の振る舞いが明確かといった観点は、レビューの中でほとんど扱われていませんでした。つまり、レビューは「実施されている」が、認識のずれを検出する仕組みとしては機能していなかったのです。これは、「レビューを実施する」というWhatに対して、「何を確認するのか」というHowが設計されていなかったことに起因します。 なぜ“認識のずれ”は起きるのかでは、なぜこのようなことが起きるのでしょうか。その背景には、人の認知の特性があります。本コラムで扱っている問題は、操作ミスのような単純な誤りではなく、仕様や前提の解釈違い、思い込み、見落としといった“認識のずれ”によって生じるものです。人は、書かれていない前提を無意識に補完して読みます。そのため、同じ文章を読んでも、前提や経験によって解釈がずれることがあります。本来、レビューやトレーサビリティといった活動は、こうした認識のずれを早期に検知し、修正するための仕組みです。しかし、その意図が共有されないまま形式だけが定義されると、「なぜやるのか」が抜け落ち、本来検出すべき認識のずれを見逃してしまいます。 なぜ再現性が生まれないのかこのWhatとHowの対応が曖昧なままでは、プロセスの再現性を確保することも難しくなります。同じ「レビューを実施する」という定義であっても、何を確認するのか、どのような観点で見るのかが人やプロジェクトごとに異なれば、結果は大きくばらつきます。つまり、「プロセスが定義されている」だけでは不十分で、「同じ結果を再現できる状態になっているか」が重要です。WhatとHowが適切に接続されていない状態では、プロセスは存在していても、安定した成果にはつながりません。 A-SPICEを「地図」として読むA-SPICEの評価項目は、単なるチェック項目ではありません。開発の中で問題が起きやすいポイントに対応して整理されています。 要求 レビュー トレーサビリティこれらはいずれも、認識のずれや思い込みが入り込みやすい地点です。その意味でA-SPICEは、アセスメントモデルであると同時に、「問題が起きやすい場所に印をつけた地図」として捉えることもできます。このように読むことで、「レビューを実施する」ではなく「どの前提が食い違いやすいのか」「トレーサビリティを確立する」ではなく「どの因果関係が切れやすいのか」といった問いに変わり、具体的な改善につながります。 問題が起きやすい地点から手当てする地図があるなら、すべてを同じ力でなぞる必要はありません。重要なのは、自分たちの現場で問題が起きやすい地点を見極め、そこから手当てすることです。例えば、 レビューの観点をあらかじめ定める（例：前提条件が明確か、ユースケースが具体化されているか、例外時の振る舞いが定義されているか） 要求を構文化し（例：EARSなどを活用する）、条件や例外を明示する 変更時に設計・テストまで影響を追う範囲を明確にするといった工夫は、認識のずれが入り込みやすいポイントに直接効きます。大きな仕組みを一気に導入する必要はありません。問題の芽を先に潰すことが重要です。 まとめA-SPICEはアセスメントモデルであり、「何ができているべきか（What）」を定義しています。一方で、それをどのように実現するか（How）は各組織に委ねられています。評価項目をそのまま作業として定義するだけでは、活動は形式化しやすく、プロセスの再現性にもつながりにくくなります。重要なのは、「なぜその項目が求められているのか」を理解し、自分たちの現場に合わせてHowを設計することです。どの工程で認識のずれや思い込みが入り込みやすいのか、という観点でA-SPICEを読み直すことで、問題が起きやすいポイントを把握し、改善の優先順位を見極めることができます。もし、 レビューが機能していないと感じる 要求の解釈が揺れてしまう 変更の影響が追いきれていないといった課題がある場合、それはプロセスが不足しているのではなく、WhatとHowのつながりが十分に設計されていない状態かもしれません。当社では、A-SPICEの評価項目をそのまま適用するのではなく、現場の実情に合わせて「どのように実現するか（How）」を整理し、運用できる形に落とし込む支援を行っています。どこから手を付けるべきかお悩みの際は、ぜひご相談ください。（安部宏典）
お知らせ
Automotive SPICE 入門 一般開催トレーニング（5月開催）のご案内
Automotive SPICE 入門一般開催（５月分）の日程をご案内いたします。詳細およびお申込みは、下記リンクあるいは「イベント開催日程」からお願いいたします。 Automotive SPICE 超入門2026年5月13日詳細はこちらからAutomotive SPICE 入門 管理支援編2026年5月18日詳細はこちらからAutomotive SPICE 入門 システムエンジニアリング編2026年5月20日詳細はこちらからAutomotive SPICE 入門 ソフトウェアエンジニアリング編2026年5月27日詳細はこちらからAutomotive SPICE 入門 ハードウェアエンジニアリング編2026年5月28日詳細はこちらから Teamsを使ったオンラインでの開催となります 教材は、原則開催日の５日前までにご指定場所に郵送いたします ご請求書はPDF版をメールで送付いたします お支払い期日は、ご請求書発行日の翌月末となります ご請求書発行後のキャンセルは、お断りしています（代理出席などの手配をお願いします） お申込者以外の方の聴講および録音は固く禁じます
コラム
問題解決管理プロセスと変更依頼管理プロセスを両立させるために
はじめにシステム開発／ソフトウェア開発は、一度作って終わりであることはまずありません。日々発生する不具合やトラブルへの対応と、顧客からの変更要求の対応や将来を見据えた改修の積み重ねによって支えられています。その中核を担うのが「問題解決管理プロセス」と「変更依頼管理プロセス」です。Automotive SPICEでは、支援プロセス「SUP.9」と「SUP.10」として定義されています。似ているようで役割の異なるこの2つを正しく理解し、連携させることが、システム開発／ソフトウェア開発プロジェクトの混乱と疲弊を避ける鍵となります。今回は「SUP.9」と「SUP.10」を両立させるヒントをお伝えします。 問題解決管理プロセスと変更依頼管理プロセスのおさらい問題解決管理プロセス：再発を防ぐための“根本治療”問題解決管理プロセスの目的は、単なる不具合対処や障害復旧ではありません。表面化した不具合や障害の背後にある真の原因（根本原因）を特定し、再発を防止することにあります。場当たり的な対応を繰り返していると、「同じ不具合が何度も起きる」「現場が疲弊する」といった悪循環に陥りがちです。問題解決管理は、なぜ起きたのかを構造的に分析し、恒久対策を設計するためのプロセスと言えるでしょう。それゆえ、SUP.9：問題解決管理プロセスでは、「問題が他のシステムや関係者に影響がある場合に通知」して、類似問題の発生を抑制したり、「データを収集＆分析し、傾向」を把握することで再発防止策を講じることが期待されています。変更依頼管理プロセス：リスクを制御しながら前に進む一方、変更依頼管理プロセスは、システムやソフトウェアの変更を秩序立てて、安全に、確実に実施するための仕組みです。変更は、改修や価値創出に不可欠ですが、同時に新たなリスクも伴います。影響範囲の評価、承認フロー、実施計画、リリース後の確認といったステップを踏むことで、「適切に変更を実装する」と同時に「良かれと思った変更が別の問題を生む」事態を防ぎます。それゆえ、SUP.10：変更依頼管理プロセスでは、「変更する作業成果物や他の変更依頼との関連を含めて分析」し、「実装前に、分析結果とリソースの利用可能性に基づいて優先順位を付け、承認」することが期待されています。 混同されがちな2つのプロセス開発現場では、「問題が起きたから変更する」「変更したら問題が起きた」という事象が発生すること、また、「どうせ変更するなら手続きは共通化したい」という理由から、両者が混同されることがあります。しかし本来は役割が異なります。 問題解決管理：なぜ問題が起きたのかを突き止める 変更依頼管理：対策や改善を、リスク管理しながら実装するつまり、問題解決管理の“アウトプット”として検討された対策が、変更依頼管理プロセスに引き渡される、という関係が理想です。仮に、両プロセスを共通の手続きに押し込んでしまった場合、原因分析や再発防止策の検討が、変更内容の検討と混同され、本来、問題解決管理でやるべき目的が希薄になる可能性が高まります。その結果、「問題」が「単に、作業成果物を変更するイベントの１つ」という誤解が生じ、「再発を防ぐための“根本治療”」ができなくなってしまいます。 成熟した組織が実践していることSUP.9とSUP.10をSUP.8：構成管理プロセスと合わせた関係図は以下になります。不具合や障害などの問題が発生した場合、その情報を問題管理データベースに登録後、内容を調査し、原因や影響を分析します。原因が、自分たちの開発対象であれば、変更する必要がありますが、テスト環境や関連する他システムに起因する場合もありますので、変更の必要がないケースもあります。原因＆影響分析の結果、変更が必要な問題であった場合、変更依頼管理票を起票し、その情報を変更管理データベースに登録し、変更管理していきます。問題管理と変更依頼管理を別々のデータベースとして管理していきたいのは、繰り返しになりますが、その役割が異なるからです。 問題解決管理：なぜ問題が起きたのかを突き止める 変更依頼管理：対策や改善を、リスク管理しながら実装する例えば、JIRAのようなチケット管理システムで両者を実現する場合でも、登録したい情報（フィールド）は異なりますので、チケットタイプは別々に定義して管理していきます。これらの情報は、単に、今起きている問題や変更への対応だけを考えると、「面倒だから記録したくない」「修正すれば良いので、適当な文章で書いておけば良い」など、疎かな活動になりがちです。しかしながら、我々のお客様でも「情報が正しく書けていないため、後になってみても、状況を理解できない」というような声を聞きます。特に、問題対処に変更を重ね、変更した箇所に更に問題対処を加えるソフトウェア開発では、記録する情報の正確性が重要となります。これら両プロセスをデータは、関連づけること、どの問題が、どの変更によって解消されたのか。逆に、どの変更が新たな問題を生んだのかを明らかにしておきます。こうした可視化が、組織の学習速度を高めます。変更依頼管理に基づき、実際に作業成果物に変更を加えていく場合は、SUP.8：構成管理プロセスの仕組みを利用することになるのです。 おわりに車載開発に限らず、システム／ソフトウェア開発では、問題解決管理プロセスは“守り”、変更依頼管理プロセスは“攻め”と表現されることがあります。しかし実際には、どちらも組織を前進させるために欠かせない車の両輪です。トラブルに強く、かつ変化を恐れない組織を目指すために、今一度この2つのプロセスの関係性を見直してみてはいかがでしょうか。 内山哲三
コラム
ソフトウェア開発組織をどう評価するか ～エンジニアリングチーム全体を評価し、組織改善につなげるために ～
はじめにソフトウェア開発組織の改善を進めるうえで、 「何をもって良い組織と言えるのか」、「改善の効果をどう測るのか」は常に悩ましいテーマです。組織のエンジニアリングチームは「うまくいっているのか」,「何がボトルネックなのか」を感覚だけで語ることの限界を感じたことはないでしょうか。ソフトウェア開発は個人プレーではなく、プロセス・ツール・人の協働によって価値を生み出すチームスポーツと言ってもよく、改善の単位も「個人」ではなく、エンジニアリングチーム全体で捉える必要があります。 本コラムでは、開発組織評価の代表的な枠組みである、以下のの3つを取り上げ、 それぞれの役割と、どう組み合わせて活用すべきかを解説します。 SPICE（プロセス成熟度） DORAメトリクス（デリバリーパフォーマンス） SPACEフレームワーク（人とチームの状態） 評価の前提：目的は「管理」ではなく「改善」最初に確認しておきたいのは、 評価は人やチームを序列化するためのものではないという点です。評価の目的は、 現状を正しく理解する（チームの強みと弱みの理解） 課題やボトルネックを可視化する（課題/ボトルネックの特定） 改善施策がチームにどのような影響を与えたかを確認する(効果を検証) エンジニア同士やマネジメントとの対話を深める（建設的な対話を促す）といった、継続的改善を支えることにあります。この前提を共有しないまま指標だけを導入すると、数字を守ること自体が目的化し、現場の疲弊を招きかねません。 SPICE：プロセス成熟度の評価SPICE（ISO/IEC 330xx） は、ソフトウェア開発プロセスの能力（Capability）を評価する枠組みです。要件定義、設計、実装、テストなどの工程が一定の成熟度レベルで統制されているかを測定します。SPICEで評価できること プロセスが標準化・管理されているか 組織内で再現性のある開発が実現できているか 継続的改善が文化として根付いているかSPICEの成熟度レベル（例） レベル 1：実行されているが管理されていない レベル 2：管理され、最低限のプロセスがある レベル 3：織標準プロセスが定義されている レベル 4：プロセスが定量的に管理されている レベル 5：プロセス改善が組織的に推進されているSPICEで利用できる具体的な評価指標の例プロセス運用に関する指標 要件レビュー実施率 変更管理プロセス遵守率 リスク管理票の更新頻度 プロジェクト計画の逸脱率（進捗・工数など）品質管理に関する指標 工程別の手戻り件数（要件→設計・設計→実装 など） レビュー指摘の再発率 テスト計画と実績の乖離率SPICEの指標は、プロセスが安定して回っているかを確認する際に非常に有効です。一方で、SPICEは人の心理的状態やチームの疲弊まではほとんど扱いません。 DORAメトリクス：デリバリーパフォーマンスの評価DORA（DevOps Research and Assessment）は、開発チームのパフォーマンスを測定するための指標群です。Google Cloud が主導する大規模調査に基づいており、“高いパフォーマンスを出すチームが共通して持っている特徴”として知られています。DORAの４つ主要指標（Four Keys） デプロイ頻度価値をユーザにどれだけ頻繁に届けられているか 変更リードタイムコード変更が本番環境に届くまでのスピード 変更失敗率リリース後に発生する障害の割合 復旧時間（MTTR）障害発生時の復旧までの時間DORAで使える具体的な評価指標の例 自動テスト実行率 CI/CD パイプライン成功率 プルリクエストの平均レビュー時間 リリースごとのバグ発生率これらは、スピードと安定性を同時に捉えられる点が特長です。 SPACE：人とチームの「状態」を可視化SPACEフレームワークは、Microsoft Research や GitHub などの研究者によって提唱された、 開発者生産性を多面的・人間中心に捉えるための枠組みです。SPACEの5つの観点 S：Satisfaction and Well-being（満足度・幸福度） P：Performance（成果・品質・価値） A：Activity（活動量） C：Communication and Collaboration（協働） E：Efficiency and Flow（効率性とフロー）SPACEの特徴SPACEは「この指標を使うべき」という規範的モデルではありません。組織のコンテキストに応じて、適切な指標を選び、組み合わせて使います。特に重要なのは、以下のような、DORAやSPICEでは見えにくい側面を補完できる点です。 数値改善の裏でエンジニアが疲弊していないか コミュニケーションが滞っていないか 割り込みが多く集中できていないのではないかDORA・SPACEだけでは測れない評価の視点（補足）フロー全体を見る指標 サイクルタイム WIP（仕掛かり作業数） フロー効率これらは SPACE の Efficiency and Flow を具体化したものです。チームが「どこで詰まっているか」を明確にします。 技術的健全性 技術的負債の増減 静的解析違反数 依存関係の陳腐化短期的な成果には表れにくいものの、 将来のパフォーマンスに大きく影響する要素です。 SPICE・DORA・SPACEの使いわけ組織／チームの改善では、SPICE・DORA・SPACEを必ずしも同時に評価する必要はありません。重要なのは、「いま何を知りたいのか」に応じて使い分けることです。①DORA：「何が起きているか」を知る改善の出発点として有効なのが、DORAメトリクスです。・リードタイムが長い・デプロイが滞っている・障害対応に追われているといった、チームの成果としての状態を客観的に把握できます。ただし、DORAが示すのはあくまで「結果」であり、なぜそうなっているかまでは分かりません。②SPACE：「チームの状態はどうか」を確かめるDORAで気になる結果が見えたら、次に見るべきは チームの状態です。SPACEフレームワークを使うことで、・無理をして改善していないか・コミュニケーションは機能しているか・集中して開発できているかといった、数値に表れにくい側面を確認できます。SPACEの役割は、改善がチームにとって健全かどうかを見極めることです。③SPICE：改善を「再現できる仕組み」にする最後に問うべきなのが、「このやり方は、チームの力として定着するか？」という点です。SPICEは、以下のような、チームを支える土台を評価します。・やり方が個人に依存していないか・プロセスが暗黙知になっていないか・改善が継続できる仕組みになっているか④改善では「流れ」で使うSPICE・DORA・SPACEは、次の順で使うと分かりやすくなります。改善後は再び DORA を確認し、この流れを繰り返します。 おわりに組織／エンジニアリングチームの評価は“目的”ではなく、“組織を強くするための手段”です。また評価指標は、エンジニアリングチームを縛るためのものではなく、チームと向き合い、より良くするための共通言語です。SPICE、DORA、SPACEを適切に組み合わせて得られた情報をもとに、 「なぜこうなっているのか」 「何から改善すべきか」 「人は無理をしていないか」を対話して共有化することが、重要です。評価を武器にするのではなく、 学習と改善を支える補助線として使うこと。それが、健全で持続可能なソフトウェア開発組織につながると考えます。 （佐藤崇）
B'zine
B'zine - 2026年2月号（構成管理の基本の「き」 など）を発行しました
B'zine 2月号を発行いたしました。動画版(約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版をメールで送付いたします お支払い期日は、ご請求書発行日の翌月末となります ご請求書発行後のキャンセルは、お断りしています（代理出席などの手配をお願いします） お申込者以外の方の聴講および録音は固く禁じます