Updates

新着情報

コラム

プロジェクトマネージャーの成長を支える羅針盤──PMCDとは何か?

はじめに現在、車載システム/ソフトウェア開発の複雑な事業環境において、プロジェクトマネージャー(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は評価のための“物差し”であると同時に、成長のための“地図”でもあります。自らの強みや課題を客観的に把握し、戦略的にキャリアを築いていくうえで、非常に有用なツールといえるでしょう。 内山哲三

コラム

Automotive SPICE MAN.3 計画の計画(GP2.1.2)とは何か?

皆さんご承知のように、Automotive SPICE の能力レベル2では、プロセスに対する目標設定や計画、監視と制御などが求められています。例えばソフトウェア要求分析(SWE.1)では、要求分析の作業を計画的に進めるために、WBS(Work Breakdown Structure)などを使用して管理するわけですが、プロジェクト管理(MAN.3)の作業を計画的に進めるとなると、何を実施すればよいのかわからなくなってしまうケースが多いようです。そこで今回は、MAN.3の GP2.1.2 をどのように捉えればよいかを解説いたします。 ここでは、「計画の計画って何?」ということを良く耳にします。「プロジェクト計画策定計画」なる書類を作成しているプロジェクトも見たことがあります。おそらく、MAN.3 の主要成果物がプロジェクト計画書なので、プロジェクト計画を作成するための計画が MAN.3 の GP2.1.2 になると言いたいのだろうと思います。確かに、プロジェクト計画書はプロジェクトの初期に作成することが重要でありながら、タイムリーに作成されないことが多く、プロジェクト計画を作成するための計画が必要だということは間違っていないのかもしれません。しかしながら、あまりにも Automotive SPICE にこだわりすぎた事例だと思いませんか?プロジェクト計画作成というタスクが1つ(あるいは不随した複数のタスク:例えば日程計画、工数見積もりなど)あれば十分だと思います。  実際に実施している作業や、計画・管理として重要な側面を考えていくことで、実施すべき作業(あるいは Automotive SPICE への適用)が見えてくると思います。 実際に、計画に関連する作業を一般事例の中から抽出してみます: ウォーターフォール的なライフサイクルを適用している場合  プロジェクトの開始当初に、大日程を作成する- 機能一覧を作成し各機能に必要な概算工数を見積もる- 大日程上の各工程で必要となる作業を洗い出し中日程を作成する- 各工程に必要な概算工数を算出し、プロジェクト合計工数として積み上げる  各工程の開始時に、工程内で必要なタスクを抽出し、小日程を作成する- 各タスクに必要な工数を算出する- この際、当初算出した工程工数との差異を分析する- 必用に応じて対策を検討し、全体計画を修正する  各工程の終了時に、工程内で使用した実績工数を集計する- 工程開始時に算出した工程工数との差異を分析する- 必用に応じて対策を検討し、全体計画を修正する アジャイル的なライフサイクルを適用している場合 プロジェクトの開始当初にイテレーション数、スプリント回数・期間を決める- バックログを作成する- 各イテレーションに割り当てる要件を決定する  各イテレーションの開始時に、スプリントを計画する(スプリントプランニング)- 各スプリントに割り当てる要件を選択して、ストーリーポイントを算出する- 各スプリントに割り当てる要件をバックログから選択する- 要件毎に作業タスクを決定する 各スプリントの終了時に、スプリントの状況を評価する(スプリントレトロスペクティブ)- 次のスプリントに持ち越す要件、中止する要件などを精査しバックログを修正する 各イテレーションの終了時に、イテレーションの状況を評価する- バックログを精査し、全体の計画を見直す いかがでしょうか?ここに記載した内容はプロジェクトの中で当たり前のように実施している作業だと思います。計画の計画(MAN.3 のGP2.1.2)とは、これらの作業が実際に行われていれば良いのです。つまり、プロジェクト計画書作成計画というような計画書だけが焦点ではなく、都度進んでいく工程(アジャイルの場合はイテレーションやスプリント)ごとに、初期計画を詳細化する(あるいは見直す)ことが、計画作業そのものなのです。これらを計画的に進めるためには、WBSタスクの設定や作業者のアサイン、作業工数の見積もりなどが必要になってくることは言うまでもありません。 最後に余談ですが、MAN.3 GP2.1.3(リソースのニーズを決定する)/GP2.1.4(リソースを識別し、利用可能にする)について補足いたします。上記で説明した例のように開発ライフサイクルが異なってくると、人的リソースや物理的リソースへの要求事項も変わってきます。例えば、アジャイル手法を用いるプロジェクトでは、プロダクトオーナーやスクラムマスターといった役割が登場します。また、管理手法もカンバンやバーンダウンチャートなどを使用することになります。プロジェクトで採用するライフサイクルにより、計画・管理のタスクや役割・スキル要件、必要なツールが異なってくることを再認識できますね。例えば今回の計画の計画のように、一瞬戸惑うことがあるかもしれませんが、日々実施していることを整理することで、無駄な作業を追加することなくAutomotive SPICEへの適用ができるはずです。 日吉昭彦

コラム

Automotive SPICE 4.0 トレーサビリティと一貫性に関する変更点(SYS/HWE):HWE導入によるプロセスのギャップ解消

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 システムアーキテクチャ設計プロセスを実装する際に、参考にしていただければ幸いです。 内山哲三

コラム

Automotive SPICEの活動を効率良く進めるために

弊社では、これまで Automotive SPICE に関する取り組みを数多く支援してきました。残念なことに、組織的にプロセス改善に取り組めている組織は少なく、大半がプロジェクト個別の活動となってしまい、組織として多大な費用がかかってしまっています。今回は、このような状況から抜け出し、効果的な改善活動を実施するためのヒントをご提供いたします。 何故、プロジェクト個別の活動になってしまうのか?まずは、この理由について考察してみます。その最大の理由は、車両メーカーがプロジェクト要件として Automotive SPICE を要求していることだと考えています。具体的には、次の2点がその原因だと分析しています: Automotive SPICE には、プロセス改善に必要なプロセスが取り上げられていない VDAスコープに、プロセス改善に必要なプロセスが入っていない  ここで引用した ISO 15504 は、Automotive SPICE のベースモデルであり、ソフトウェア開発プロセスの評価と改善のために必要なプラクティスを定義した国際規格です。そもそも SPICE とは Software Process Improvement and Capability dEtermination の略であり、ISO15504 の原案作成をしていたプロジェクトに付けられた名前です。 一方で車両メーカーは、特定部品のサプライヤーを選定するためにAutomotive SPICE を使用しています。そのため、車両メーカーとしては組織的なプロセス改善より、むしろ発注を予定している(1つの)プロジェクトのプロセス能力を重要視しているのです。これは、Automotive SPICEに定義されているプロセスや、車輌メーカーがアセスメント対象のプロセスとして採用しているVDAスコープにも現れています。上図に示すように、組織的な改善活動を実施するために参考になる、PIM.1(プロセス確立)、PIM.2(プロセスアセスメント)、RIN.1(人的資源管理)、RIN.2(トレーニング)、RIN.3(知識管理)、RIN.4(環境整備)などは Automotive SPICE には定義されておりません。唯一、PIM.3 が Automotive SPICE に含まれていますが、VDA スコープには取り上げられていません。 従って、車両メーカーの指定するプロセス(一般的にはVDAスコープ)だけを対象にしても、組織的にプロセス能力を向上させることは困難です。プロセス能力を継続的に向上させていくためには、Automotive SPICE には定義されていない他のプロセスの導入を検討する必要があります。例えば、上図で示した ISO15504 や 最近発行された Organization SPICE (概要は、こちらを参考にしてください)などを取り入れると良いでしょう。これまで筆者が見てきた中では、1社だけ PIM や RIN を参考に組織プロセスを定義している組織がありました。さすがに、この組織では改善活動が組織的に運営されていました。 この結果、何が起こっているか?Automotive SPICE 対応をしているプロジェクトでは典型的に次のような課題が見られます: プロジェクトごとに、Automotive SPICE の対応が実施されており、組織として無駄な工数が発生しているプロセス改善活動とは)組織能力を高めるために組織としてのプロセスを定義し改善する活動である プロジェクト定例会議の中でプロセス活動の議論がされ、プロジェクト工数が圧迫されているプロジェクト定例会議では)プロジェクト計画に対する状況と課題の確認を実施する場である 本来どうあるべきか?本来、組織としてプロセス改善活動を運営していれば、新たなプロジェクトが発足しても、Automotive SPICE 要求への対応を新たに実施する必要はないはずです。では、そのような状況を作り上げるには、どのようにすればよいでしょうか?私たちは、これまでの経験から次のことが重要だと考えています。  プロセス改善活動のアプローチを明確にする プロセス改善活動の目的を明確にし動機づけを行う プロセス改善活動の役割と責任を明確にする プロセス改善活動のアプローチに関するヒント改善活動は、米国のカーネギーメロン大学ソフトウェア工学研究所(SEI)が開発した組織的改善活動モデルであるIDEAL(Initiating Diagnosing Establishing Acting Learning)を参考にすると良いでしょう。このモデルでは5つの活動フェーズが定義されています。このモデルは、いわゆるPDCA と同様のモデルですが、改善活動には活動開始時の行動が重要という考え方から、立上げフェーズI(Initiaging)が加えられています。改善活動は、基盤を形成することが重要であり、この段階で組織のトップが改善活動に対する態度を決めることが重要であるとされています。  もう一つ、プロセス改善において重要な活動を説明いたします。IDEALモデルでは、行動・学習フェーズの活動となります。 1つ目は、プロセスの試行と評価です改善施策を本運用する前に、試行するプロジェクトを選定して、試行することそして改善の効果が当初の目標と比べてどの程度になるかを評価することが重要となります 2つ目は、プロセストレーニングの提供です改善施策が出来上がったら、改善プロセスの内容や新しい活動の目的をメンバーに周知する必要がありますトレーニングプログラムを通してプロセスの目的や意図を説明することがプロセスの定着にも寄与することになります 最後に、プロセス展開計画の策定と、実装状況の評価です「改善プロセスが完成したから、あとはプロジェクトが使うはずだ」と思っていても、なかなかうまくいきませんプロセス策定は、プロセスを使ってもらうための計画と評価まで実施して終了となります特に車両メーカーの要求に応えるために活動を実施していると、Automotive SPICE の要求を満たすためにプロセスを定義することが最優先となり、プロセスの効果測定やトレーニングの実施まで手が回らないことが多いようです。学習フェーズにあるように改善の効果を評価して、次の改善活動サイクルにつなげていくことが、継続的な活動につながっていくことになります。 プロセス改善活動の目的を明確にし動機づけに関するヒント次に、立上げフェーズの主題である改善活動の目的と動機づけに関するヒントを紹介します。改善活動では、組織のトップの行動が活動の成否を決めると言っても過言ではありません。ここにトップが実施すべき行動概要を記載しますので、参考にしてください。 トップがやる気になって、率先する 方針と方向を提示する プロセス改善の諸原則をコミットする 全参加者にプロセス改善を周知する プロセス改善の責任者を選定する 活動に必要な資源(人やインフラ)に関してコミットする 配下全員の意識改革の風潮を絶やさない プロセス改善活動の役割と責任に関するヒント最後に、改善活動をうまく運営していくためのヒントを紹介します。下図にあるように、各グループの責務を明確にし、トップ主導のもと全員が協力して活動を遂行していくことが効率の良い改善活動への第一歩となるでしょう。   いかがでしたでしょうか?本コラムの最後に、弊社が実践してきた中で得た教訓をいくつか紹介しますので、参考にしてください。 従来の開発プロセスを尊重する マネージャが率先して取り組む プロセス改善モデルの心を理解する 目的を理解する 誰がやっても同じようにできるようにする プロセス間、能力レベル間のつながりを理解する 全プロジェクトと EPG が協力し合う 継続できる改善施策を捻出する ツールを最大限に活用する ただし、担当者にストレスを感じさせないツールとする 品質はただでは得られない 継続的なプロセス改善への投資を必要とするが、他の選択肢より安く済む 日吉昭彦

コラム

Automotive SPICE 4.0 SYS.4の本質:つなげば終わりではない、”システム設計の整合性”を見極める

Automotive SPICE 4.0 に関するコラム、今回は SYS.4:システム統合および統合検証プロセスをテーマにお届けします。 はじめにAutomotive SPICE 4.0におけるSYS.4(システム統合および統合検証)とSYS.5(システム検証)は、システム開発の最終段階に位置づけられます。SYS.4では、SYS.3(システムアーキテクチャ設計)で設計したシステムエレメントを統合し、エレメント間のインタフェースや相互の振る舞いが設計通りに機能するかどうかを検証します。その後、SYS.5では、統合後のシステムが要求通りに動作するかどうかを確認することが求められます。しかし現場では、「システム要求に基づくテストは実施しているものの、設計されたシステム構造や振る舞いが正しく再現されているかを確認する視点が不足している」といった課題がしばしば見られます。表面的には動作しているように見えても、設計で意図されたインタフェース、動作シナリオが正しく実現されていないケースも少なくありません。たとえば、仕様通りに信号線が接続されていない、設計と異なる条件で処理が動いているといった状況です。 統合して明らかになる「設計と現実のギャップ」あるプロジェクトで、複数のECUやアクチュエータ、センサを含むシステムの統合工程に入りました。各チームは単体での試験を終えており、「統合しても問題なく動くだろう」と楽観視されていました。そして統合後すぐに、SYS.5で求められるシステム要求に対する検証が始まりました。ところが、ECUの起動タイミングが数百ミリ秒ずれただけで通信が確立せず、他のユニットが初期化エラーを起こすなど、思わぬ問題が発生しました。個別には正常だった電源ONシーケンスでも、統合環境では起動が不安定になる例もありました。さらに、擬似環境では正常に動いていたセンサとECUの接続も、実機では信号の立ち上がりや微小なノイズの影響で、ECUが信号を誤認識する事象が確認されました。仕様上問題ないはずの電圧レベルでも、実際にはセンサが“未接続”と誤判定するケースもありました。このように、統合して初めて明らかになる設計と現実のギャップは少なくありません。 「段階的統合」で見えてくる、システムとしての整合性SYS.4(システム統合および統合検証)では、「段階的な統合・検証」がキーワードです。具体的には、 システムエレメント間のインタフェースを確認しながらサブシステムを構築 サブシステム間を統合し、最終的なシステム全体を完成・検証というステップを踏み、システム全体の整合性を評価していきます。この過程では、電磁インタフェース、光インタフェース、コネクタや圧入、沿面距離・空間距離といった物理的な接続要素も重要です。なお、これらの項目には従来ハードウェアやメカ設計の領域と捉えられがちなものも含みますが、システムエレメント間のインタフェースの整合性として、システム統合の中で評価すべき重要な要素とされています。これらは仮想環境やシミュレーションでは評価が難しく、実際の統合(実統合)を行わなければ検証できません。製品が完成し、動作しているということは、どこかの工程で何らかの検証が行われているはずです。ただし、システムの視点をもつ担当者(いわゆる“システムグループ”)が不在であることもあり、Automotive SPICEで求められるような体系的かつ論理的な整合性の証明が行われていないケースも見受けられます。だからこそ、製品開発に関わる関係者がそれぞれどのような活動を行っているのかを全体として整理し、不足があれば補完していくような活動が重要です。このように、部分的な検証や整理されていない活動の積み重ねだけでは、システム全体の整合性を十分に評価することは困難です。すなわち、「統合検証」とは単に「最後にすべてを接続して動作確認する工程」ではなく、段階的な統合と検証を通じて、最終的に「アーキテクチャ設計で意図した接続関係やモード遷移が成立しているか」を評価する必要があります。たとえば次のような観点です: 運用モードの遷移(スタートアップ、スリープ、シャットダウンなど)が意図通りか 電源、CAN/LIN、アナログ信号など、物理インタフェースの整合性とタイミング 通信レイテンシやセンサ遅延による制御応答の影響これらはハードウェアやソフトウェア単独での試験では見えにくく、統合環境でこそ明らかになります。状態遷移ではなく、「モード挙動」として捉えるソフトウェアでは状態遷移表によって振る舞いを定義・検証することがありますが、SYS.4の観点では、「システムとしてのモード」とその全体挙動に注目します。たとえば以下のようなケース: システム起動時、すべてのシステムエレメントがタイミングよく初期化され、安定動作に入れるか? スリープ復帰後、センサや通信系が適切に再起動し、制御がスムーズに再開できるか? 異常発生後の復旧プロセスで、他のシステムエレメントに悪影響を及ぼさず、安全に切り替えられるか?これらは「状態遷移」だけでは捉えきれない、時間軸上の振る舞いや依存関係の問題です。こうした観点を踏まえ、設計意図をどのように検証へつなげていくかが問われます。設計意図を検証へつなぐためにこうしたSYS.4での検証を成立させるためには、前段階であるSYS.3において、システム全体の相互作用や外部環境要因による影響の検証に関する考慮がなされていることが前提となります。SYS.3でそれらが十分に記述されていない場合、SYS.4での整合性検証は困難になります。とはいえ、実際の車両開発の現場では、初回の開発フェーズからすべての外部環境要因による影響や振る舞いを設計に盛り込むのは困難なケースも多くあります。そうした場合は、SYS.5で得られた知見や不具合を、次の開発サイクルでのSYS.3およびSYS.4に反映させるという、継続的なV字開発の積み重ねが重要になります。また、SYS.3のシステム設計者とSYS.4のシステム検証者が異なる場合には、設計意図や想定されるシステム間の相互作用、起動シーケンスや電源設計上の前提などが十分に文書化・伝達されていなければ、SYS.4で本コラムで述べたような検証は難しくなります。設計と検証の橋渡しを行う情報伝達のプロセスも、品質保証の鍵となります。 まとめSYS.4の統合検証では、まず物理的な接続確認という基本を押さえたうえで、設計の意図や統合の前提が、システム全体として成立しているかを検証します。ここでの検証が不十分だと、最終段階や客先で重大な不具合が顕在化するリスクがあります。設計と検証は一方通行ではなく、相互に補完し合い循環的に成熟させるべき関係です。SYS.4を通じて、設計の妥当性を裏付け、次の開発サイクルへと知見をつなげていくことが、システム設計の真の“整合性”を育む鍵となるでしょう。あわせて、製品開発に関わる関係者がどのような活動を行っているのかを全体として整理し、不足があれば補っていくことも欠かせません。活動の連携や重複、見落としを明らかにすることで、統合検証の質はさらに高まります。今一度、自社のSYS.4プロセスを見直し、「設計者の意図や前提条件が、検証シナリオや試験条件にきちんと反映されているか」「想定されたモード挙動や副作用が試験されているか」といった観点から、検証の質を点検してみてはいかがでしょうか。 さいごに今回のコラムはいかがでしたでしょうか?本コラムの内容が、自社の開発プロセスの見直しや改善のきっかけになれば幸いです。現場で似たような悩みに直面している方にとっても、少しでもヒントになれば嬉しい限りです。ご相談いただければ、これまでの経験を活かしてお力になれることもあるかもしれません。どうぞお気軽にお問い合わせください。(安部宏典)

コラム

Organization SPICE 成熟度レベル4、5の評価で対象にするプロセスについて

先日、Organization SPICE 概説資料を公開しました。この資料は、Organization SPICE PAM の記載事項をなるべく忠実に表現する方針で作成してあります。そのため、少し補足説明を入れないと理解しにくい部分が残ってしまっています。コラムでは、補足が必要だと思われる次の2点について解説いたします:  成熟度レベルアセスメントに必要なインスタンス(プロジェクト)の選び方 成熟度レベル4、5を評価する際のプロセス選定の考え方 前回のコラムでは、インスタンスの選び方をご紹介しましたので、今回は成熟度レベル4、5を評価する際のプロセス選定の考え方についてご説明いたします。PAM の記載事項を要約すると、次のようになります: 成熟度レベル4、5インスタンスの選定 高成熟度(レベル4、5)については、選択されたプロセスセットがそれぞれ能力レベル4および5を達成することが期待される。このセットには、必ずしもすべてのプロセスが含まれる必要ははない。プロセスによっては、能力レベル3を超える根拠やビジネス上のメリットが全くない場合があるからである。(例えば、統計的な手法が適用できないほどインスタンス数が少ないなど) とはいえ、能力レベル4/5に選択された一連のプロセスについては、それらがどのように業務に貢献しているのか、きちんとした分析が必要である。その分析に基づき、能力レベル4/5のプロセスが、大半のプロジェクト(成熟度レベル4の場合)または企業/組織/部門(成熟度レベル5の場合)において、かなりの量の業務成果に貢献していることを明確にする必要がある。 このプロセスセットには、少なくとも1つの基本プロセスが含まれている必要があるが、通常は相互に関連するプロセスグループが存在している。さらにこのプロセスセットには、成熟度レベル2以上の拡張プロセスを含むことができる。 これは、どういうことを言っているのでしょうか?成熟度レベル4以上の活動を経験された方には理解できると思いますが、補足説明がないとわかりにくい内容だと思います。ここからは、これらの背景について説明していきます。 なぜ能力レベル4、5を達成する必要のあるプロセスは限定的(このセットには、必ずしもすべてのプロセスが含まれる必要はない)で良いのか?レベル4、5は、プロセスが事業へ貢献することに焦点を当てているからです。つまり、事業目標を達成するためには、どのプロセスを統計的に制御すると効果があるかを分析する必要があるのです。言い換えれば、すべてのプロセスを統計的に制御しても意味がありません。例えば、品質の向上が事業遂行上の最優先課題とした場合に、MAN.3(プロジェクト管理プロセス)やSUP.8(構成管理プロセス)を統計的に制御することで品質向上に大きく寄与するでしょうか?これらのプロセスを選択するよりも、むしろ過去の不具合傾向を見て、例えば詳細設計プロセスやレビュープロセスに焦点を当てることの方が品質向上に貢献しそうだと思いませんか?つまり、プロセスによっては、能力レベル3を超える根拠(統計的にプロセスを制御する)やビジネス上のメリットが全くない場合があるということなのです。    次に、「能力レベル4および5を達成することが期待される」とは具体的にどのような状態なのでしょうか?レベル4と5では、期待値が多少異なるので2つに分けて説明します: レベル4が期待するプロセス制御レベル4においては、組織内のプロジェクトから収集した標準プロセスの実績データを活用して、プロジェクトを成功に導くことが期待されています。プロセスは、プロジェクトの実績向上に寄与することに焦点が当てられていますが、プロジェクト実績の向上は結果的に組織の事業実績に貢献することになります。 まずは、事業目標を達成するために各プロジェクトはプロジェクト目標を設定します。次に、プロジェクト目標を達成するためにキーとなるプロセスを選択し、このプロセスを統計的に制御(そのイメージは後述します)していきます。つまり、プロセス実績データを統計的に分析しながら、都度プロジェクト実績を予測して、早め早めに手を打つことでプロジェクト目標の達成に導いていくための手法なのです。 データの扱い方の観点から見ると、レベル3のプロセス状態におけるプロジェクト管理では、その時点までに収集したデータを使って状況を把握していると言えます。言い換えると、自動車のバックミラーに映し出された形跡(プロジェクトが実施してきた結果)を見てプロジェクトを管理していることになります。一方、レベル4では、組織内の過去プロジェクトが使用した標準プロセスの実績データの集合から予測モデルを作成して、都度プロジェクト実績をモデル式に当てはめ、プロジェクト終了時点の実績を予測しながらプロジェクトを制御しているのです。こちらは、航空機がランディングする際に自動操縦で滑走路(プロジェクトのゴール)にアプローチするような例えになります。  レベル5が期待するプロセス制御レベル5においては、組織内のプロジェクトから収集した標準プロセスの実績データを活用して、組織のプロセス革新を実現することが期待されています。プロセスは、組織の事業実績の向上に直接寄与することに焦点が当てられます。 レベル4の活動においてプロセスを統計的に制御することが可能になったプロセス実績データを組織改革に活用することがプロセス成熟度の考え方の最終ゴールとなります。ここでは、新しい技術を現在使用している標準プロセスに組み込んだ場合に、プロセス実績がどのように変化するかを予測モデルから評価します。 このようなことができるようになると、刻々と変化するビジネス環境に合わせてダイナミックにプロセスを改善・改革することが可能になり、競合他社に対して優位性を持つことができるわけです。 ここでの説明のとおり、成熟度レベル4の場合は活動の焦点がプロジェクトに向けられています。一方、成熟度レベル5の場合は企業/組織/部門の業績に焦点を当てていることになります。  最後に、「統計的な手法が適用できないほどインスタンス数が少ない」ということに関して補足しておきますこれは、実際にプロセスを統計的に制御する活動をしてみるとわかるのですが、プロセス実績データ(インスタンス)を数多く、かつ頻繁に入手・評価できないと、実際の制御には活用できないということなのです。 例えば、プロジェクトの生産性のような指標は、プロジェクトが終了しないと収集できません。また、このようなデータはプロジェクト1つで1点のデータとしてしか入手できません。プロセスを統計的に制御するためには、プロセス実績の中心値やバラツキを見ながらプロセス実績を評価することになるので、インスタンスが少ないとうまく活用できません。データの母集団を作成するためには、膨大なプロジェクトが必要になりますし、プロジェクトが終わってしまっては、そのプロジェクトの将来を予測できません。 わかりやすい例として、レビュープロセスの実績データがあります。レビューはプロジェクトの中でもかなりの回数実施されるでしょう。母集団の作成も容易にできますし、レビュー終了時点で実績値を予測モデルに当てはめれば、直近のレビュー結果がプロジェクトの将来に与える影響も判断することができます。  今回のコラムはいかがだったでしょうか?PAMには簡単に書かれていますが、なかなか奥の深いトピックだと思います。私たちは、実際の開発現場で成熟度レベル4、5の実装に長らく携わってきました。この活動では、多くの後戻りと苦悩がありました。一番つらかったのはレベル4、5の目指すところを理解できた時点で、それまで構築してきたレベル3プロセスの定義や実装を振り出しに戻す必要が出てきてしまったことです。それまでは、データの扱いや統計的にプロセスを制御するために適切なプロセス構造や活動になっていなかったのです。この時、プロセス改善モデルとの付き合い方として、その時点で目標とするレベルだけを意識するのではなく、一度高いレベルを学習した上で、上位レベルから下位レベルを俯瞰して活動する必要があることを学びました。 同様の悩みをお持ちの方も多いと思いますので、その際はぜひ弊社までお声がけいただければと思います。日吉昭彦

コラム

成熟度レベルアセスメントに必要なインスタンス(プロジェクト)の選び方

先日、Organization SPICE 概説資料を公開しました。この資料は、Organization SPICE PAM の記載事項をなるべく忠実に表現する方針で作成しております。そのため、少し補足説明を入れないと理解しにくい部分が残ってしまっています。コラムでは、補足が必要だと思われる次の2点について解説いたします:  成熟度レベルアセスメントに必要なインスタンス(プロジェクト)の選び方 成熟度レベル4、5を評価する際のプロセス選定の考え方 今回は、成熟度レベルアセスメントをする際に必要となるプロセスインスタンス選び方についてご説明いたします。PAMの記載事項を要約すると、次のようになります: プロセスインスタンスの選定 可能であれば、少なくとも4つのフォーカスプロジェクトを選択する必要がある。選択されたすべてのプロセスは、フォーカス内で分析する必要がある。十分なカバレッジを達成するために、さらにプロセスインスタンスを追加することもできる。 フォーカスプロジェクトと選択されたプロセスインスタンス全体は、いずれも組織ユニットのプロセスインスタンスを適切に代表するものでなければならない。 プロセスインスタンスの選択基準は、定義されたアセスメントプロセスに従う必要がある。  具体的には、どのように選定すればよいのでしょうか?プロセスインスタンスの考え方や組織のプロセス成熟度に関する補足説明がないとわかりにくい内容だと思います。ここからは、これらの背景について説明していきます。 プロセスインスタンスとは何を指しているのか?プロセスインスタンスとは、「組織ユニットの中で組織標準プロセスを使用して活動した実例を示すもの」と解釈するとのが良いと思います。基本的には、1つのプロジェクトが1つのインスタンスとなります。つまり、プロジェクトが組織標準プロセスを履行した結果(足跡)ということです。ただし、プロセス改善プロセス(PIM.3)やスキル開発(RIN.2)など、プロジェクト単位ではなく組織として活動するプロセスは、プロジェクト単位とはならないケースも出てきます。 なぜ、少なくとも4つのフォーカスプロジェクト(プロセスインスタンス)が必要となるのか?成熟度レベルアセスメントは、Automotive SPICE が通常1つのプロジェクトを評価対象とするのに対し、組織のプロセス成熟度を評価対象とするものです。従って、組織ユニット内の限定的な(例えば1つの)プロセスインスタンスを評価しても、組織のプロセス成熟度を公平に表すことはできません。1つだけ良くできた(あるいはアセスメントのためだけに準備された)プロセスインスタンスが組織ユニット全体を表しているわけではないからです。 フォーカスプロジェクトは、どのような基準で選べば良いか?フォーカスプロジェクトは、PAM の記述にあるように組織ユニットのプロセスインスタンスを適切に代表するものでなければなりません。適切なインスタンスを選択をするためには、プロセスの履行にバラツキが出る要因を考慮しておくと良いでしょう: 製品種別:開発する製品特性 開発フェーズ:実施する作業工程、要求される期間、品質など 組織体制:部門/課/グループの特徴 プロジェクト規模:開発の大きさや、携わる人数 ロケーション:仕事の実施される場所(国の習慣や、地域による人の風習など) 顧客:開発要求元会社の文化ここに取り上げた例は、プロセス定義内容は同じにもかかわらず、作業上の違いが生まれてしまう可能性のある要因となるものです。成熟度レベルアセスメントの結果は、組織のベンチマークにも使われます。プロセスインスタンスの選定により評価結果が異なってしまうようでは、公平なベンチマークはできません。従って、成熟度レベルアセスメントにおいては、上記のような要因を考慮して、組織ユニットを代表するプロセスインスタンスを選定することが重要になってくるのです。選択したプロセスアセスメントモデルに、プロセスインスタンスの選定基準が定義されていれば、当然その基準を使用して選択する必要があります。アセスメントモデルに明確な定義がない場合は、選定した根拠を文書化しておくと良いでしょう。日吉昭彦