新着情報

B'zine

2026/06/30

B'zine - 2026年6月号（B'live JUL2026 Webinar：人手運用から脱却する構成管理DXなど）を発行しました

B'zine 6月号を発行いたしました。ショート動画も公開していますので、弊社公式YouTubeより是非ご視聴ください。  B'zineは、１回/月のペースでの配信しています。ご興味のある方は、ここから登録をお願いいたします。B’zine ビジネスガレージ通信（2026年6月号） お届けします。エルニーニョ現象による海水温上昇もあって台風が発生しやすい環境が整っているようで、今年の台風は例年よりも多く、強力で、迷走しやすい傾向があるそうです。梅雨と台風が重なる線状降水帯発生リスクも高まるので、気象情報には十分注意が必要です。今回から、無料WebinarをB'liveという名前で配信いたします。引き続きご愛顧くださいますようお願いいたします。 【今月のトピックス】 イベント：７月３０日（木）B'live JUL2026 Webinar開催：人手運用から脱却する構成管理DX ～ Power Platformで実現する構成管理ロボの導入事例 ～ イベント：Automotive SPICE 入門一般開催トレーニング（7月開催）のご案内 コラム：エンジニアリングチーム（開発組織）の成長とスキル開発～ 成長する開発組織に必要なものは「個人」と「チーム」の両立 ～ コラム：Automotive SPICE アセスメント受審の心得～ 知っておきたい、アセッサーが見ている5つのポイント ～ コラム：なぜソフトウェアアーキテクチャ設計が重要か：車載開発における品質要求と設計の考え方 Youtube：第9回無料Webinar「AI時代のQA（品質保証活動）とは何か？」のアーカイブ動画をYouTubeに公開 【イベント】 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/  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日参加申し込みはこちらから→https://www.bgarage.co.jp/news/2020/ 【コラム】 エンジニアリングチーム（開発組織）の成長とスキル開発～成長する開発組織に必要なものは「個人」と「チーム」の両立～エンジニアとして仕事に取り組む中で、「継続的に成長すること」の重要性を感じている方は多いのではないでしょうか。技術の変化が速い領域において、学び続けることは避けて通れません。一方で、現実には日々の開発業務、障害対応、スケジュールへの追従といった目の前の作業に追われ、自己研鑽の時間を十分に確保できていないという状況も広く見られます。その結果、「成長の必要性は理解しているが、実践が難しい」という状態が生まれます。このギャップは個人の問題というより、開発組織全体に共通する構造的な課題と捉えるべきものとも考えられます。詳細はこちら→https://www.bgarage.co.jp/news/2110/  Automotive SPICE アセスメント受審の心得～ 知っておきたい、アセッサーが見ている5つのポイント ～Automotive SPICE アセスメントを初めて受けることになった時、多くの方が不安に感じることがあります。・ 「アセッサーからどんな質問をされるのだろうか」・「作業成果物はすべて揃えただろうか」・ 「記載不備を指摘されそうなところはどこか」・ 「説明担当者は何を準備すればよいのか」私自身が2025年当社へ転職する前は、車載部品メーカーのシステム開発部署 SEPG として組織プロセス改善活動に奮闘しており、アセスメントを受ける側の準備に日々悩んでいました。当時、Automotive SPICE コンサルタントからアセスメントの直前に教えていただいた受審の心得について、今も強く記憶に残っていることがあります。現在はアセッサー側の視点から多くの現場を見る中で、「評価されるポイント」と「準備が不足しがちなポイント」には明確な傾向があることにも気づきました。本コラムでは、Automotive SPICE PAM (Process Assessment Model) には記載されていないものの、初めてアセスメントを受ける方に知っておいていただきたいいくつかのポイントをご紹介します。詳細はこちら→https://www.bgarage.co.jp/news/2096/  なぜソフトウェアアーキテクチャ設計が重要か：車載開発における品質要求と設計の考え方車載ソフトウェア開発に関して、ソフトウェアアーキテクチャ設計の重要性と難しさについて、日頃から感じていることについて記述します。Automotive SPICE v4.0 の「SWE.2 ソフトウェアアーキテクチャ設計」 では、ソフトウェアアーキテクチャの仕様化に関して以下の２個の基本プラクティス（BP）が規定されています。・ BP1：ソフトウェアアーキテクチャの静的な側面の仕様化・ BP2：ソフトウェアアーキテクチャの動的な側面の仕様化ソフトウェア工学では、開発要求を総合的に分析して、ソフトウェア全体の構造（静的側面）や動作/アルゴリズム（動的側面）を決定して、ソフトウェアアーキテクチャ設計書を作成し、そのソフトウェアアーキテクチャの上で要求された機能を実現していくことが求められています。SDV時代になってソフトウェア規模は巨大化しており、高品質ソフトウェアを開発するためのソフトウェアアーキテクチャの重要性は増大しています。しかしながら、車載ソフトウェア開発では、母体とするソフトウェア全体に対するアーキテクチャ仕様書がないケースが見受けられます（システム制御仕様書がソフトウェアアーキテクチャ設計書代わりに参照されているケースもあります）。詳細はこちら→https://www.bgarage.co.jp/news/2111/  【YouTube】 第9回無料Webinar「AI時代のQA（品質保証活動）とは何か？」アーカイブ動画をYouTubeに公開しました。また、当日した資料も公開しましたので合わせてご活用ください。詳細はこちら→https://www.bgarage.co.jp/news/2058/詳細はこちら→https://www.bgarage.co.jp/news/2065/

お知らせ

2026/06/29

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

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

Webinar

2026/06/26

B'live JUL2026 Webinar　人手運用から脱却する構成管理DX　～ Power Platformで実現する構成管理ロボの導入事例 ～

B'live JUL2026 Webinarは、人手運用から脱却する構成管理 DX について考察します。文書番号の採番ミス、台帳の更新漏れ、過去文書が見つからない――こうした“人手運用あるある”に悩んでいませんか？本Webinarでは、Power Platform (Power Apps・Power Automate・SharePoint) を使って、採番・検索・監視・通知・バックアップを段階的に仕組み化した事例をご紹介します。スモールスタートで始めた改善が、A-SPICE SUP.8 や ISO9001 の考え方にもどうつながるのかを、実際の取り組みをもとにお伝えします。 アジェンダ 自社で抱えていた文書管理・構成管理の課題 Power Platformを用いたスモールスタートの改善事例 採番・台帳登録・検索・監視・通知・バックアップの実装例 Automotive SPICE SUP.8 / ISO9001 の観点から見た運用改善の意味 参加ご希望の方は、こちらのページからお申込みください。

コラム

2026/06/23

なぜソフトウェアアーキテクチャ設計が重要か：車載開発における品質要求と設計の考え方

はじめに車載ソフトウェア開発に関して、ソフトウェアアーキテクチャ設計の重要性と難しさについて、日頃から感じていることについて記述します。Automotive SPICE v4.0 のソフトウェアアーキテクチャの仕様化に関する記述Automotive SPICE v4.0 の 「SWE.2 ソフトウェアアーキテクチャ設計」 では、ソフトウェアアーキテクチャの仕様化に関して以下の２個の基本プラクティス（BP）が規定されています。ソフトウェアアーキテクチャ設計とはソフトウェアアーキテクチャ設計は、エンジニアが実施すべき重要な作業であり、具体的には製品に必要な品質をバランスよく実装するために、すべての品質特性を考慮し、ソフトウェア全体をどんな構成にするか、どのようなメカニズムで動作させるかを設計する作業です。ソフトウェアに対する要求には大別して以下の２つのカテゴリーがあります。 機能要求 ：ソフトウェアが実現するべき機能（振る舞い）を規定したものです 非機能要求：包括的な用語であり、具体的には機能以外の品質要求や制約事項等が該当します非機能要求は機能以外のすべて要求を包含すると考えれば、概ね 「非機能要求＝品質要求」 と考えても良いでしょう。一般的に、非機能要求という言葉はあまり使われていませんが、Automotive SPICE では、あえて非機能要求という言葉を使っています。非機能要求に関しては、以下の記事も参考にしてください。 Automotive SPICE 4.0 における非機能要件の考え方ISO/IEC 25010：System and software quality models では品質を以下の８個の品質特性で定義しています。一般的に、ソフトウェア開発プロジェクトでエンジニアがまず最初に着目するのは、どんな機能（機能要求）を開発するかという事だと思います。機能要求はソフトウェアに要求する機能やサービスなので、利害関係者は明確に要求し、エンジニアは優先的に要求内容を確認すると思います。しかしながら、品質要求は抽象的な記述や省略されるケースもあるため、この場合はエンジニアが善意をもって開発する製品（ソフトウェア）に実装すべき品質要求定義し、利害関係者と合意しておく必要があります。車載ソフトウェア開発におけるアーキテクチャ設計に対する課題ソフトウェア工学では、開発要求を総合的に分析して、ソフトウェア全体の構造（静的側面）や動作/アルゴリズム（動的側面）を決定して、ソフトウェアアーキテクチャ設計書を作成し、そのソフトウェアアーキテクチャの上で要求された機能を実現していくことが求められています。SDV時代になってソフトウェア規模は巨大化しており、高品質ソフトウェアを開発するためのソフトウェアアーキテクチャの重要性は増大しています。しかしながら、車載ソフトウェア開発では、母体とするソフトウェア全体に対するアーキテクチャ仕様書がないケースが見受けられます（システム制御仕様書がソフトウェアアーキテクチャ設計書代わりに参照されているケースもあります）。信頼できるソフトウエアアーキテクチャ仕様書がない環境では、開発者は要求機能毎に個別ソフトウェアを設計するスタイルにならざるをえないというのが、車載ソフトウェア開発の現状課題のひとつではないでしょうか？。Automotive SPICEの要求に答えるために、無理やりソフトウェアを構造化しているような取り組みも見受けられます。ソフトウェアアーキテクチャ設計に関しては、以下の記事も参考にしてください。 Automotive SPICE 4.0 SWE.2 ソフトウェアアーキテクチャ設計とは？ 日本と欧米におけるソフトウェア開発アプローチの違い以下にアーキテクチャ設計事例（課題のあるアーキテクチャ設計事例と改善事例）を紹介します。ソフトウェアアーキテクチャ設計の事例紹介１（動的側面） 要求機能 ECU は空き状態で起動信号を受信したら機器１、２、３を起動する すべての機器の起動が成功した場合は緑ランプ点灯し、運用中状態にする 起動失敗機器がある場合、障害表示と赤ランプ点灯し、運用中状態にする 要求通りソフトウェア実装した、よくある事例 要求機能の順序通りにソフトウェア動作を設計する 複数機器をシーケンシャル起動する制御方式を採用する 筆者見解 この処理方式では３つの機器に対して順次起動するので、各機器に起動信号送信から応答信号を受信するまで、ECUでは計３回の機器起動待ち時間が発生するので、信号A 受信からランプ点灯までのレスポンスタイムが長くなるというデメリットがあります 要求機能に記載内容をそのまま上図のように単一タスクで実装すれば、ソフトウェアアーキテクチャを意識せず、要求機能を簡単にソフトウェアで実現できます ECUは、この単一タスク実行中（３回の機器起動待ち時間を含めて）は、他の処理を実行できません（タスク実行中のため、他の信号受信等のタスクはすべて待ち合わせになります） プロトタイプや PoC（Proof of Concept：概念実証） 開発では、正常機能の動作確認優先で、開発コスト削減/期間短縮のために動的側面を考慮しないケースでは、この処理方式でも問題ないでしょう 性能品質を考慮したソフトウェアアーキテクチャ設計の事例 信号A 受信からランプ点灯までのレスポンスタイムを短縮する 複数機器をパラレル起動する（機器起動待の発生箇所を１回にして待ち期間を短縮） パラレル制御を実現するアーキテクチャ（例：状態遷移モデル）を採用する 各機器からの起動完了信号をランダム受診時の処理を考慮する 起動 NG 受信、起動完了信号タイムアウトした時の処理を考慮する 筆者見解 ３つの機器を同時に起動して、一番起動時間の長くかかる機器からの応答を待ってランプ点灯できるので、ECU 待ち時間は、最大1/3 に短縮できるという大きなメリットがあります（ECU 自体の処理時間は起動待ち時間に比べて非常に短いため無視している） ３つの機器に対して処理を並行実施して応答待ちする必要があるため、これらの信号受信を並行処理するためにソフトウェアアーキテクチャが複雑になります ECUが起動待ち状態でも、他の信号受信やタイムアウト等発生時のタスクが実行可能です。 商用ソフトウェア開発では、エンドユーザの使い勝手や「性能を重視する必要があるので、レスポンスタイム短縮という品質（性能効率性）の実装は非常に重要ですソフトウェアアーキテクチャ設計の事例紹介２（静的側面） 要求機能例 信号 A を受信したら、処理 1、処理 2、処理 3 を実施する 信号 B を受信したら、処理 4、処理 5、処理 6 を実施する 信号 C を受信したら、処理 7、処理 8 を実施する ソフトウェアを単純構造化した、よくある事例 信号A、信号B、信号C 受信時のタスクを個別に順次作成する 各処理のかたまりを関数にして、「タスク群」と「関数群」に分離する 筆者見解 タスク群と関数群に分離して、見かけ上はソフトウェアを構造化しているように見えますが、実質的にはタスク中に各処理 BOX を、関数形式で埋め込んだだけです タスクで制御するデータと関数で制御するデータは、階層化されていません（すべての関数はタスク固有なので、タスクと関数でデータを階層化する必要性もありません） すべての関数はタスク固有処理となるため、ソフトウェア部品としての再利用性はありません 同じような処理が、複数の関数に存在してしまうことで、機能追加/変更時に影響範囲が発散する可能性が高いため、保守性に課題があります プロトタイプ開発/PoC 開発でのソフトウェアアーキテクチャを考慮しないケースでは、このような構造化でも問題ないでしょう 再利用性やデータ構造化を考慮したソフトウェアアーキテクチャ設計の事例 信号 A、B、C を受信時の処理１～８を総合的に分析し、共通処理/機能を抽出し、それらを４個の共通関数（W、X、Y、Z） にまとめ、定義する 共通関数で処理できない固有部分はタスク側で処理する 受信信号毎の処理差分を、関数側で制御できるように、タスク群と関数群間のインタフェース（共通関数の入出力パラメータ）を定義する タスク側で制御するデータと関数側で制御するデータを分離（階層化）する 筆者見解 タスク固有部から関数CALL時に、固有情報を入力パラメータとして引き渡すことで、共通関数化しているため、タスクと関数が階層化（構造化）されています。 タスク制御するデータと関数制御するデータは分離（構造化）されています 共通関数は独立したソフトウェア部品として、再利用性が高くなっています 個別タスク側の機能追加/変更と、共通関数側の機能追加/変更が、独立して実施できるので機能追加/変更の影響範囲が局所化され、保守性が高まっています 商用ソフトウェアでは、将来の機能追加/変更時の響範囲が局所化や保守性を重視し、個々の要求毎に逐次ソフトウェアを開発するのではなく、類似する要求を総合的に分析し、どのようなソフトウェアアーキテクチャにすべきかを決定する必要がありますソフトウェアアーキテクチャ設計における留意点個々の要求機能毎に逐次ソフトウェアを開発するのではなく、要求の集合ととらえて俯瞰し、どのようなソフトウェアアーキテクチャにすべきか決定する必要があります。参考までに、静的側面のアーキテクチャとして、AUTOSAR のレイヤー構造図とアプリケーションソフトウェアの構造図の事例を紹介します。さいごにAutomotive SPICEのSWE.2は、ソフトウェア工学をマスターしたエンジニアがソフトウェアを開発する際に、当然実施しているはずの活動や成果物を要求しているだけです。 ソフトウェア要求に基づいて、適切なソフトウェアアーキテクチャを採用している ソフトウェア全体の構造（ソフトウェア構成図 etc.）を設計する（静的側面） 外部インタフェース、コンポーネント間インタフェースを設計している（静的側面） ソフトウェア全体構造上での、ソフトウェア動作（シーケンスチャート、状態遷移図/遷移表 etc.）を設計している（動的側面） 上記のソフトウェアアーキテクチャ設計を文書化している運用実績のある既存ソフトウェアを母体として機能変更/追加する場合、あまりソフトウェアアーキテクチャを意識しなくても詳細設計を実施できることもありますが、既存ソフトウェアアーキテクチャが理解不十分だと、機能変更/追加に対する適切な追加/変更箇所の特定や影響範囲分析は困難です。また、Automotive SPICEの要求に答えるためだけに、ソフトウェア工学に基づかないアーキテクチャ設計（＝名ばかりのアーキテクチャ設計）を作成しても、利用価値がありません（誰も参照しない）。ソフトウェア工学に基づいた、信頼できるソフトウェアアーキテクチャ設計書を整備・更新しておくことは、追加/変更箇所の特定や影響範囲分析やソフトウェアの保守作業を効率化し、設計品質向上に大きく貢献します。ソフトウェアアーキテクチャ設計の重要性を認識し、要求された機能だけに着目するのではなく、他の機能要求や実現すべき品質要求もバランス良く考慮した上で、アーキテクチャを重視したソフトウェア開発を心がけてください。（海農 公宏）

コラム

2026/06/22

Automotive SPICE アセスメント受審の心得　～ 知っておきたい、アセッサーが見ている5つのポイント ～

はじめにAutomotive SPICE アセスメントを初めて受けることになった時、多くの方が不安に感じることがあります。 「アセッサーからどんな質問をされるのだろうか」 「作業成果物はすべて揃えただろうか」 「記載不備を指摘されそうなところはどこか」 「説明担当者は何を準備すればよいのか」私自身が2025年当社へ転職する前は、車載部品メーカーのシステム開発部署 SEPG として組織プロセス改善活動に奮闘しており、アセスメントを受ける側の準備に日々悩んでいました。当時、Automotive SPICE コンサルタントからアセスメントの直前に教えていただいた受審の心得について、今も強く記憶に残っていることがあります。現在はアセッサー側の視点から多くの現場を見る中で、「評価されるポイント」と「準備が不足しがちなポイント」には明確な傾向があることにも気づきました。本コラムでは、Automotive SPICE PAM (Process Assessment Model) には記載されていないものの、初めてアセスメントを受ける方に知っておいていただきたいいくつかのポイントをご紹介します。１．アセッサーが見ているのは「成果物」だけではないAutomotive SPICE では、各プロセスで期待されるアウトプットや活動が定義されています。そのため、受審準備では、 「必要な作業成果物やプロセス文書が存在しているか」 「指定された記載項目が含まれているか」に意識が向きがちです。一方でアセッサーが確認したいことは、それだけではありません。本当に確認したいのは、「その成果物がどのような開発活動によって作られ、実際の開発現場で活用されているのか」という点です。例えば、要求仕様書が存在しても、 「誰がレビューしていつ承認されたか」 「その要求仕様書が次フェーズの設計へどのように繋がったか」 「要求仕様や設計書が変更されたときにどのように影響分析したか」つまり、これらの How をアセッサーへ説明できなければ、プロセスが有効に実施されていることを伝えることは難しくなります。さらにアセッサーは、プロセス文書の改版履歴も重要な確認対象としています。「そのプロセス文書がいつ作成され、どの程度の頻度で更新されているか」を見ることで、そのプロセスが一時的な準備物ではなく、継続的に運用されているかを判断します。この改版履歴は、プロセスの定着度を測る一つの指標であると同時に、その後のインタビューで確認すべきポイントを見極める材料にもなっています。２．「60秒ルール」－ 必要な情報へアクセスできる準備アセスメント準備で特に印象に残った助言の一つが、「指定されたドキュメントを60秒以内に提示できる状態にしておく」というものでした。これは、Automotive SPICE のプラクティスとして明文化されているものではありません。しかし、アセッサーとの限られた時間の中では非常に重要なポイントになります。例えば、「SYS.2 の要求分析結果を確認できますか？」と依頼された際に、「少々お待ちください」という沈黙の状況が続くと、アセッサーは成果物の存在だけでなく、プロジェクト内でその成果物が認知されているか、開発現場でどの程度管理・活用されているかを深掘りすることになるでしょう。もちろん、すべてを暗記する必要はありません。重要なのは、 「どこにあるか」 「誰が管理しているか」 「関連成果物とどのようにつながっているか」を見せながら説明できる状態にしておくことです。リファレンスリストを準備する「60秒ルール」を実現するための有効な手段として、リファレンスリストの整備があります。これは、Automotive SPICE の各プロセスで要求される成果物と、プロジェクトで実際に作成している成果物を対応付けた一覧です。成果物が格納されているリポジトリ情報のリンクを整理しておくことで、アセッサーからの依頼に対して即答できるようになります。このリストの作成には、Automotive SPICE への理解がある程度必要ですが、単なる準備資料にとどまらず、自分たちの活動とモデルとの対応関係を整理するうえでも大変有効です。構成品目一覧から説明できる状態にするもう一つの実践的な方法として、成果物を単体で探して提示するのではなく、「構成品目一覧」から辿って説明する方法があります。例えば、プロジェクトの構成品目一覧を表示し、紐づいたリンクから対象の成果物を提示することで、「どの成果物がどの位置づけで管理されているのか」を説明することができます。この方法の前提として、構成品目一覧が適切に整備・運用されている必要はありますが、単に成果物を提示するだけでなく、構成管理の観点も含めて説明できる点が大きなメリットです。結果として、このような説明ができる状態にしておくことは、SUP.8（構成管理）の観点からも評価されやすくなります。リファレンスリストのような整理された資料だけでなく、日常のSUP.8運用の仕組みをそのまま使い説明できることが理想です。３．「できていない」と自己判断しない重要性他にも、当時教えていただいた重要なポイントがあります。それは、「Automotive SPICE の用語で実施していないからといって、”できていない”と自己判断しない」ということです。実際の開発現場では、Automotive SPICE のプラクティス名やアウトプット（情報項目）名とは異なる、企業固有の名称や現場の呼び方で活動していることがあります。例えば、 要求レビュー 設計検討会 品質確認会議 不具合分析会など、現場独自の活動の中で Automotive SPICE が求める活動を実施しているケースがあります。そのため、アセッサーから質問された際には、「Automotive SPICE の SYS.2 のシステム要求の構造化という活動は実施していません」とすぐに回答するのではなく、「名称は異なりますが、見積検討会という活動で要求の構造を確認しています」というように、自分たちの開発活動との対応関係を説明することが大切です。４．アセスメントは「試験」ではなく「開発活動の確認会」初めてアセスメントを受ける方ほど、 「正解を答えなければ減点される」 「指摘されないようにしなければならない」というネガティブな心境になりがちです。しかし、アセスメントの本来の目的は、できている・できていないを単純なものさしで判定することではありません。アセッサーは、 「開発プロセスが Automotive SPICE の意図した建付けで機能しているか」 「リスクを早期に発見できる仕組みになっているか」 「チェック機構と改善活動が連動している状態か」を確認しています。説明担当者に求められるのは「完璧な回答」ではなく、「自分たちの開発活動をアセッサーに正しく説明すること」です。５．準備の差がアセスメントの結果を左右するアセスメントは組織やプロジェクトにとって重要なイベントであるにもかかわらず、十分な準備が行われていないケースが少なくありません。例えば、アセッサーからレビュー記録の開示を求められた際に、 参加者が2名のみ 実施時間が15分程度 指摘事項がゼロといった記録を見せられることがあります。もちろん、それ自体が必ずしも問題とは限りません。しかし、アセッサーの視点では「本当に有効なレビューが行われているのか」という疑問につながります。また、事前に説明担当者が回答の予行演習（リハーサル）を実施している組織は意外と少なく、結果として説明が不十分になってしまう傾向が見受けられます。一方で、アセスメントの要求事項を理解するための勉強会や、想定問答を準備している組織では、インタビューが非常にスムーズに進む傾向があります。このように、アセスメントの結果は「準備の質」に大きく依存します。単に成果物を揃えただけでは、十分とは言えません。 説明の一貫性 成果物の選定 想定問答の整理といった観点で事前準備を行うことが非常に重要と言わざるを得ません。おわりにAutomotive SPICE アセスメントでは、PAM に記載されたプラクティスを理解することはもちろん重要です。一方で、初めて受審するチームにとって重要なのは、 必要な情報へ素早くアクセスできること 自分たちの開発活動を現場の言葉で説明できること 十分な準備を行い、自信を持って受審に臨むことです。本記事で紹介した内容はPAMに明示されているものではありませんが、実際のアセスメント現場では非常に重要なポイントです。アセスメントは「試験」ではなく、自分たちの開発活動を確認し、より良いプロセスへつなげる貴重な機会でもあります。これから初めて Automotive SPICE アセスメントを受審される方にとって、本コラムが少しでも参考になれば幸いです。弊社では、開発現場に伴走できる経験豊富なコンサルタントが在籍し、みなさまのお困りごとに対応しております。今回のコラムで取り上げた内容は、Automotive SPICE トレーニングや入門教材でもカバーしています。関心をお持ちの方は、ぜひ弊社までお問い合わせください。（越智功）

コラム

2026/06/22

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

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

お知らせ

2026/06/11

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

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

WhitePaper

2026/06/05

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

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