Updates
ビジネスガレージ株式会社が毎月メールでお届けしている月刊ニュースレター「B’zine（ビー・ジーン）」。今回は6月号の動画バージョンを公開しました！ 業界の最新動向や、開発現場での活用事例をわかりやすく解説しています。 Automotive SPICE一般開催トレーニング、Webinarのご案内 Modeling & Simulation SPICE 概説資料のご案内 公開中のコラム情報について 車載ソフトウェア開発に関わる方、業界の最新トレンドをキャッチしたい方におすすめの内容です。ぜひご覧ください！ ▶ 動画はこちらからご視聴いただけます：https://www.youtube.com/watch?v=4lXto-jehHg
はじめに現在、車載システム／ソフトウェア開発の複雑な事業環境において、プロジェクトマネージャー（PM）の役割はますます重要になっています。しかし、優れたPMになるために必要なスキルや知識とは、果たして何なのでしょうか？必要な知識をまとめたものとしてはPMBOK® が有名ですが、求められるスキルや育成については明確な定義がありません。そこで登場するのが「PMCD（Project Manager Competency Development Framework）」です。 PMCDの位置づけと背景PMCDは、PMI（Project Management Institute）によって開発されたフレームワークであり、プロジェクトマネージャーに求められる「能力」を体系的に整理したものです。単なる技術的なスキルセットではなく、「知識（Knowledge）」「パフォーマンス（Performance）」「個人特性（Personal Competencies）」の3側面から成り立っており、総合的なコンピテンシーを育成・評価することを目的としています。3つの柱：PMCDのコンピテンシー構造 知識（Knowledge）：PMBOK® Guideをベースにしたプロジェクトマネジメント知識体系。プロセスやツール、手法の理解がここに含まれます。 パフォーマンス（Performance）：知識を現場でどう活かすか。実際のプロジェクトで成果を出せるかが問われます。 個人特性（Personal Competencies）：コミュニケーション能力、リーダーシップ、倫理観など、人物としての資質に関する領域です。この三位一体のアプローチは、単なる資格取得以上に、実務家としての進化に焦点を当てているのが特徴です。さらに、このコンピテンシー構造は、業界や組織が持つ固有のパフォーマンス要件によって、補完＆拡張されること許容しています。それぞれのコンピテンスの程度は、コンピテンス指標によって5段階のレベルが定義されています。 3つの柱の内部構造知識のコンピテンスPMP試験や同等の資格認定に合格することで立証されるものとしており、PMCDの定義外ですが、PMに求められる知識を「人」「プロセス」「ビジネス環境」に分類しています。 実践のコンピテンスマネージャーが、プロジェクトマネジメント知識と個人のスキルによって、実施できるまたは達成できていることを評価する領域です。PMBOK® 第3版の知識エリアに基づいて、コンピテンス要素を定義しているだけでなく、パフォーマンス基準と証拠資料を使って、コンピテンス要素を評価する仕組みを提供しています。 個人特性のコンピテンスマネジメントする各プロジェクトメンバの能力に貢献する、振る舞い・態度・文化的な影響およびコアとなるパーソナリティ特性を定義しています。マネージャーは、他者と効果的なやりとりができるスキルをもつことは重要であるため、6つのコンピテンスユニット「コミュニケーション力」「リーダシップ力」「マネジメント力」「認識力」「実効力」「プロフェッショリズム」を定義しています。さらに、実践コンピテンスと同様に、コンピテンス要素を定義しているだけでなく、パフォーマンス基準と証拠資料を使って、コンピテンス要素を評価する仕組みを提供しています。 なぜPMCDが今、注目されるのか？変化の激しい時代において、プロジェクトマネジメントはもはや「計画を守る」だけでは不十分です。ステークホルダーの多様化やアジャイル型の開発環境では、「状況に応じて適応できる力」がPMに求められます。PMCDは、そうした多様な能力を総合的に見える化し、継続的な能力開発のガイドラインを提供する点で、非常に有効です。 ビジネスガレージが提供するPMスキル可視化サービスビジネスガレージでは、組織が求めるPMを育成するご支援の一環として、PMCDや他のフレームワークも活用した、皆さんの組織の特徴や文化に適合したPMスキル可視化をご支援しております。プロジェクト特性や組織特性を考慮して、「会社が期待するプロジェクトマネージャ像」を、お客様と一緒に作り上げます。弊社の熟練専門家が、ドキュメントやヒアリングを通じて、組織の特徴を整理するだけでなく、プロジェクトマネージャへの期待を明文化し、期待するプロジェクトマネージャが保有すべきスキルを言語化します。 既成のフレームワークに囚われない、実用的なスキル定義をご提供しておりますので、興味のある方は是非お問い合わせください。 さいごに自己評価と育成の道しるべとしてPMCDは評価のための“物差し”であると同時に、成長のための“地図”でもあります。自らの強みや課題を客観的に把握し、戦略的にキャリアを築いていくうえで、非常に有用なツールといえるでしょう。 内山哲三
先日梅雨入りしたと思ったら、まだ６月なのに連日の猛暑日が続いています。熱中症および体調管理には十分ご留意ください。B'zine ６月号を発行いたしました。B’zineは、１回/月のペースでの配信しています。ご興味のある方は、ここから登録をお願いいたします。 B'zineビジネスガレージ通信（2025年6月号） 先日梅雨入りしたと思ったら、まだ６月なのに連日の猛暑日が続いています。熱中症および体調管理には十分ご留意ください。 【今月のトピックス】 イベント：Automotive SPICE 入門（実務者向け）一般開催トレーニング（７月、８月） イベント：７月開催Webinar：Automotive SPICE/機能安全/サイバーセキュリティを両立する設計アプローチと事例紹介を開催 資料公開：Modeling & Simulation SPICE 概説資料を公開 コラム：システムの論理構成と物理構成について コラム：Automotive SPICE 4.0 トレーサビリティと一貫性に関する変更点（SYS/HWE）：HWE導入によるプロセスのギャップ解消 コラム：Automotive SPICE MAN.3計画の計画（GP2.1.2）とは何か？ 【イベント】 Automotive SPICE入門（実務者向け）一般開催トレーニング開催のご案内（7月、8月開催）開発現場の実務者に役立つような具体的な事例を含めて、プロセス毎に解説します。詳細・お申込みはこちらから→https://www.bgarage.co.jp/news/1121/ ７月30日Webinar開催：Automotive SPICE/機能安全/サイバーセキュリティを両立する設計アプローチと事例紹介Automotive SPICEが規定する開発プロセスと、機能安全やサイバーセキュリティをどのように融合するかを解説します。詳細・お申込みはこちらから→https://www.bgarage.co.jp/news/1199/ ９月Webinar（予定）：Modeling & Simulation SPICE 概説システム開発および運用において、高信頼性のモデルベース開発やシミュレーションの体系的なエンジニアリングプロセスについて解説します。 【資料公開】 Modeling & Simulation SPICE 概説intacs からModeling & Simulation SPICEが公開されましたが、その概説書を作成したので公開します。詳細はこちら→https://www.bgarage.co.jp/news/1197/ 【コラム】 システムの論理構成と物理構成についてAutomotive SPICEのプロセスであるSYS.3システムアーキテクチャ設計プロセスでは、システムの機能要求と非機能要求に関して、静的／動的の両側面での設計が期待されていますが、実際にシステム構成要素にシステム要求をどのように割り当て、実装することが最適なのかを分析・検討することは難しいものです。システムエンジニアリングの国際標準を参考に、システム要求からシステムを設計する流れを解説します。詳細はこちら→https://www.bgarage.co.jp/news/1137/ Automotive SPICE 4.0トレーサビリティと一貫性に関する変更点（SYS/HWE）：HWE導入によるプロセスのギャップ解消Automotive SPICE 4.0では、従来のソフトウェア中心の構成から一歩進み、ハードウェアエンジニアリング（HWE）という新たなプロセス領域が追加されました。トレーサビリティと一貫性の観点から、SYS（システムエンジニアリング）とHWEの関係性に焦点を当て、HWE導入がもたらすプロセス上のギャップ解消について説明します。詳細はこちら→https://www.bgarage.co.jp/news/1155/ Automotive SPICE MAN.3計画の計画（GP2.1.2）とは何か？Automotive SPICE の能力レベル２では、プロセスに対する目標設定や計画、監視と制御などが求められています。例えばソフトウェア要求分析（SWE.1）では、要求分析の作業を計画的に進めるためにWBSなどを使用して管理しますが、プロジェクト管理（MAN.3）の作業を計画的に進めるには何を実施すればよいのかわからないケースが多いようなので、MAN.3のGP2.1.2をどのように捉えればよいかを解説いたします。詳細はこちら→https://www.bgarage.co.jp/news/1144/
第4回 Webinarは、車載開発に要求されいてる２つの規格（ISO 26262 および ISO 21434）を効果的に適用するためのアプローチについてご紹介いたします。これらの要求は、既に開発済みの開発プロセス（車載開発組織では Automotive SPICE に準拠した形で作成するのが一般的）に共通の方針で取り組むことで、開発者へ効率的なプロセスを提供することが可能です。弊社では、サイバーセキュリティプロセス開発の事例や、ISO 26262・ISO/SAE 21434導入ガイドラインも発行していますので、是非こちらもご参照ください。 参加ご希望の方は、下記フォームからお申込みください。
Intacs から公開されている Modeling & Simulation SPICE の概説書を作成いたしましたので公開いたします。ご興味のあるかたは、是非ダウンロードして活用してください。 コンテンツに含まれるもの： Modeling & Simulation SPICE の構造 信用できる決定プロセス群（DEC） DEC.1 エンジニアリングおよび決定タスク分析 DEC.2 サブタスク定義 DEC.3 結果評価および決定 モデリングおよびシミュレーションエンジニアリングプロセス群（MSE） MSE.1 シミュレーションサブタスクおよび目標分析 MSE.2 シミュレーション設定要求分析 MSE.3 シミュレーション設定設計 MSE.4 シミュレーション設定実装（エレメント構築） MSE.5 シミュレーション設定エレメント検証 MSE.6 シミュレーション設定統合および検証 MSE.7 シミュレーション実施および評価 MSE.8 シミュレーションサブタスクおよび目標達成の決定 信憑性保証プロセス群（CRD） CRD.1 重要度特定 CRD.2 信憑性尺度および手法
皆さんご承知のように、Automotive SPICE の能力レベル２では、プロセスに対する目標設定や計画、監視と制御などが求められています。例えばソフトウェア要求分析（SWE.1）では、要求分析の作業を計画的に進めるために、WBS（Work Breakdown Structure）などを使用して管理するわけですが、プロジェクト管理（MAN.3）の作業を計画的に進めるとなると、何を実施すればよいのかわからなくなってしまうケースが多いようです。そこで今回は、MAN.3の GP2.1.2 をどのように捉えればよいかを解説いたします。 ここでは、「計画の計画って何？」ということを良く耳にします。「プロジェクト計画策定計画」なる書類を作成しているプロジェクトも見たことがあります。おそらく、MAN.3 の主要成果物がプロジェクト計画書なので、プロジェクト計画を作成するための計画が MAN.3 の GP2.1.2 になると言いたいのだろうと思います。確かに、プロジェクト計画書はプロジェクトの初期に作成することが重要でありながら、タイムリーに作成されないことが多く、プロジェクト計画を作成するための計画が必要だということは間違っていないのかもしれません。しかしながら、あまりにも Automotive SPICE にこだわりすぎた事例だと思いませんか？プロジェクト計画作成というタスクが１つ（あるいは不随した複数のタスク：例えば日程計画、工数見積もりなど）あれば十分だと思います。 実際に実施している作業や、計画・管理として重要な側面を考えていくことで、実施すべき作業（あるいは Automotive SPICE への適用）が見えてくると思います。 実際に、計画に関連する作業を一般事例の中から抽出してみます： ウォーターフォール的なライフサイクルを適用している場合 プロジェクトの開始当初に、大日程を作成する- 機能一覧を作成し各機能に必要な概算工数を見積もる- 大日程上の各工程で必要となる作業を洗い出し中日程を作成する- 各工程に必要な概算工数を算出し、プロジェクト合計工数として積み上げる 各工程の開始時に、工程内で必要なタスクを抽出し、小日程を作成する- 各タスクに必要な工数を算出する- この際、当初算出した工程工数との差異を分析する- 必用に応じて対策を検討し、全体計画を修正する 各工程の終了時に、工程内で使用した実績工数を集計する- 工程開始時に算出した工程工数との差異を分析する- 必用に応じて対策を検討し、全体計画を修正する アジャイル的なライフサイクルを適用している場合 プロジェクトの開始当初にイテレーション数、スプリント回数・期間を決める- バックログを作成する- 各イテレーションに割り当てる要件を決定する 各イテレーションの開始時に、スプリントを計画する（スプリントプランニング）- 各スプリントに割り当てる要件を選択して、ストーリーポイントを算出する- 各スプリントに割り当てる要件をバックログから選択する- 要件毎に作業タスクを決定する 各スプリントの終了時に、スプリントの状況を評価する（スプリントレトロスペクティブ）- 次のスプリントに持ち越す要件、中止する要件などを精査しバックログを修正する 各イテレーションの終了時に、イテレーションの状況を評価する- バックログを精査し、全体の計画を見直す いかがでしょうか？ここに記載した内容はプロジェクトの中で当たり前のように実施している作業だと思います。計画の計画（MAN.3 のGP2.1.2）とは、これらの作業が実際に行われていれば良いのです。つまり、プロジェクト計画書作成計画というような計画書だけが焦点ではなく、都度進んでいく工程（アジャイルの場合はイテレーションやスプリント）ごとに、初期計画を詳細化する（あるいは見直す）ことが、計画作業そのものなのです。これらを計画的に進めるためには、WBSタスクの設定や作業者のアサイン、作業工数の見積もりなどが必要になってくることは言うまでもありません。 最後に余談ですが、MAN.3 GP2.1.3（リソースのニーズを決定する）/GP2.1.4（リソースを識別し、利用可能にする）について補足いたします。上記で説明した例のように開発ライフサイクルが異なってくると、人的リソースや物理的リソースへの要求事項も変わってきます。例えば、アジャイル手法を用いるプロジェクトでは、プロダクトオーナーやスクラムマスターといった役割が登場します。また、管理手法もカンバンやバーンダウンチャートなどを使用することになります。プロジェクトで採用するライフサイクルにより、計画・管理のタスクや役割・スキル要件、必要なツールが異なってくることを再認識できますね。例えば今回の計画の計画のように、一瞬戸惑うことがあるかもしれませんが、日々実施していることを整理することで、無駄な作業を追加することなくAutomotive SPICEへの適用ができるはずです。 日吉昭彦
Automotive SPICE 4.0 では、従来のソフトウェア中心の構成から一歩進み、ハードウェアエンジニアリング（HWE）という新たなプロセス領域が追加されました。今回は、トレーサビリティと一貫性の観点から、SYS（システムエンジニアリング）とHWEの関係性に焦点を当て、HWE導入がもたらすプロセス上のギャップ解消について説明します。 ◆Ver3.1までの課題Ver3.1までは、ハードウェア開発に関するプロセスが明示的に定義されておらず、多くの組織では以下のような課題が見られました。 ハードウェア要求が体系的に管理されていない 設計と要求のトレーサビリティが不十分 ソフトウェアと比較してプロセス成熟度が低く、属人化しやすいこのような状況では、システム全体の整合性を保つことが難しく、特に安全性や信頼性が求められる領域では大きなリスクとなっていました。 ◆HWEの登場とその意義Ver4.0で新設されたHWEプロセス領域は、ハードウェア開発を「要求定義 → 設計 → 実装 → 検証」という一連のプロセスとして明確に定義しています。これにより、以下のような効果が期待されます。 ハードウェア要求の明文化と管理 設計成果物とのトレーサビリティ確保 SYSとの整合性チェックの仕組み化 ソフトウェア開発とのプロセス統一による連携強化特に、SYS-HWE間のトレーサビリティが明確になることで、システム全体の一貫性が担保されやすくなります。 ◆トレーサビリティと一貫性の実現HWE導入により、以下のようなトレーサビリティの流れが構築されました。 SYS.2（システム要求分析）で定義されたシステム要求が、 HWE.1（ハードウェア要求分析）に引き継がれ、 HWE.2（ハードウェア設計）で設計に反映され、 HWE.3（ハードウェア設計に対する検証）で設計が検証され、 HWE.4（ハードウェア要求に対する検証）で要求が検証されるこの一連の流れにおいて、各プロセス間で要求のトレーサビリティのリンクを明示的に管理することで、変更が発生した際にも影響範囲を迅速に把握でき、設計ミスや手戻りのリスクを低減できます。また、SYSとHWEの間で一貫性チェックを行うことで、要求の解釈違いや設計のズレを早期に発見することが可能になります。 ◆まとめVer4.0におけるHWEの導入は、これまで曖昧だったハードウェア開発プロセスに明確な枠組みを与え、SYSとの連携を強化する大きな一歩です。特にトレーサビリティと一貫性の観点から見ると、システム全体の品質向上とリスク低減に直結する重要な進化と言えるでしょう。今後は、HWEプロセスの実装と定着を通じて、ソフトウェアとハードウェアが真に連携した開発体制の構築が求められることになると思います。佐藤崇
はじめにAutomotive SPICEのプロセスである、SYS.3 システムアーキテクチャ設計プロセスでは、システムの機能要求と非機能要求に関して、静的／動的の両側面での設計が期待されています。 しかしながら、システムの構成要素であるセンサ・アクチュエータ・制御回路・マイコンなどに、システム要求をどのように割り当て、実装することが最適なのかを分析・検討することは難しいものです。単に、Automotive SPICEに期待されているように、静的な側面と動的な側面で設計結果を図案化しても、適切な設計をした根拠として少し心もとないですし、「流用元のシステムがこうなっているから」では説得力にも欠けます。今回は、システムエンジニアリングの国際標準である「ISO/IEC 26702 IEEE Std 1220-2005, Systems engineering – Application and management of the systems engineering process」を参考に、システム要求からシステムを設計する流れを解説していきます。 機能アーキテクチャと物理アーキテクチャシステム要求を実現するシステム構造は1つではありません。複数の実現案がある中から最適なシステム構造を決定していく必要があります。そのため、まずシステム要件を満たすために、システムが保有すべき、論理的な機能を定義し、それらの関係を整理していく必要があります。そして、これらの機能を、その後定義するシステムの構成要素（センサ・アクチュエータ・制御回路・マイコン）に割り当てていきます。システム構成要素を定義したものが物理アーキテクチャになります。システム設計の全体の流れを簡単に示すと下図のようになります。 機能分析機能アーキテクチャは、システム要件を満たすために、実行の順序、制御フローまたはデータフローを定義した機能・サブ機能および内部／外部インターフェースを整理したもので、システムの論理構成を示したものです。また機能アーキテクチャでは、システム機能をサブ機能に分解 (細分化) した結果生じる、サブ機能の機能的な配置と順序を検討する必要があります。この際、この後物理アーキテクチャを考慮せずに必要な機能配置を分析することがポイントになります。システム要件をインプットに、機能アーキテクチャを設計するためのプロセスは以下のようになります。 ここでの「振る舞いの分析」や「機能間インタフェース」の定義が、Automotive SPICEにおける静的な側面の仕様化の一部であり、「時系列の流れ」や「データフルーと制御フロー」の定義が、動的な側面の仕様化の一部となります。例えば、扇風機の機能アーキテクチャを設計した結果の一部である、論理構成のブロック図は以下のようになります。 ※具体的なやり方を知りたい方を知りたい方やトレーニングを受講されたい方は、是非お問い合わせください。 設計物理アーキテクチャは、機能アーキテクチャとシステム要件を満たすために、製品の設計結果提供する設計要素の配置を整理したものです。設計結果を定義し、検証された機能アーキテクチャの要件を満たす、システムの構成要素を特定します。機能アーキテクチャを元に、システム構成要素の配置、それらの分解、インターフェイス (内部および外部)、および設計制約を提供する物理（設計）アーキテクチャを設計していきます。この際、必要に応じて、複数の実現案を評価し、リスクを特定・評価・定量化し、適切なリスク軽減アプローチを選択した上で、コスト、スケジュール、およびパフォーマンスへの影響を分析することがポイントとなります。システム要件と機能アーキテクチャをインプットに、物理アーキテクチャを設計するためのプロセスは以下のようになります。 ここでの「機能をグルーピングし設計要素に割り当て」や「物理インタフェースの定義」が、Automotive SPICEにおける静的な側面の仕様化の一部であり、「設計特性や性能特性の定義」などが、動的な側面の仕様化の一部となります。例えば、扇風機の物理アーキテクチャを設計した結果の一部である、機能ブロックの設計要素への割り当て結果は以下のようになります。 ※具体的なやり方を知りたい方を知りたい方やトレーニングを受講されたい方は、是非お問い合わせください。 さいごにいかがでしょうか。単に、「システム要件をインプットに、静的設計と動的設計をして、システムアーキテクチャを設計しろ」と言われても、具体的に何すべきなのかはわかりにくと思います。しかしながら、システム要件を元に、必要なシステム機能を定義して、適切なシステム構成要素を定義する流れを想像してみれば、システムアーキテクチャ設計が少しイメージできるかと思います。SYS.3 システムアーキテクチャ設計プロセスを実装する際に、参考にしていただければ幸いです。 内山哲三