【ASPICE】MAN.3 プロジェクト管理 Basic Practices (BP) とは？基本プラクティスの解説と説明

2022年12月1日2024年6月20日

当記事のリンクには広告が含まれています

ASPICE解説は下記リンクよりアクセスください
プロセスアセスメントモデルはコチラから
※当該解説をより詳細に知りたい方はアセスメントモデルを参照ください

▶ASPICEの他解説ページへ

能力レベル3の取得を目標とした記事となります

General Practice とは？

既に説明を読んでいる人は飛ばしてください

全てのプロセスカテゴリーに当てはまる、共通の活動が記述される
BP（基本プラクティス）で実施されたプロセスを成熟させるために利用される

BP (Basic practices: 基本プラクティス)は能力レベル1（PA1.1）のみに適用され、それ以上の能力レベル（レベル2～5）ではGP (Ganeric Practices: 共通プラクティス)とGR（Generic Resources: 共通リソース）が適用されます。
より詳しく知りたい方は、アセスメントモデルの【5.3.1 実施管理プロセス属性】以降を参照ください。

能力レベル1-2-3を例えるのであれば、料理なんかが良い例だと思います。
レベル1：レシピ通りに作ってるが、何を調合したのかわからず同じ味を再現できるか不明な状態。
レベル2：レシピに何をどのタイミングで調合するのか記載され、似た味を再現できている状態。
レベル3：レシピがレストランの決まりに組み込まれ展開されており、誰でも同じくできる状態。

即ちの能力レベル1では何となく実施してリリースができている状態に対し、能力レベル2以上ではプロセス（レシピ）が存在して計画・実行・調整がかけられる状態を示します。

Generic Practices の構成

Generic Practicesを能力レベルで分けた表は以下の通りです。

能力レベル	プロセス属性	項	説明
L2	実施管理プロセス	GP2.1	プロセスの実施が管理されている程度を示す
L2	作業成果物管理プロセス	GP2.2	プロセスにより作成される作業成果物が管理されている程度を示す
L3	プロセス定義プロセス	GP3.1	定義されたプロセスが維持されている程度を示す
L3	プロセス展開プロセス	GP3.2	定義されたプロセスの展開されている程度を示す

MAN.3の基本プラクティス

基本プラクティスの詳しい説明へ

基本プラクティスに関する詳細な記述はプロセスアセスメントモデルを参照ください。
MAN.3 プロジェクト管理には合計10つの基本プラクティス（BP1～BP10）が存在します。

BP1

プロジェクトを開始するにあたって、そのプロジェクトの作業範囲を定義しなくてはなりません。プロジェクトの目標及び責任範囲、ステークホルダーと相互の境界を識別し、モチベーションを確立します。

プロジェクト計画書などの文書を作成し、プロジェクトの目標（ゴール）を明確にする必要があります。この目標を達成するためには、プロジェクト活動に関わるステークホルダーへプロジェクトの活動範囲を周知する必要があります。（BP2で記載されている作業範囲とはこれを示します）

実際にはプロジェクトがどのような素性なのか関係者へ周知徹底できている状態であることであったり、プロジェクト計画書に目標が記載され正式に管理されているのか、どの基準に従いプロジェクトを遂行するのか、開発戦略が掲げられているのか等を定義されなくてはなりません。

そのためには、プロジェクトの組織図が存在したり誰がアサインされているのか明確になったドキュメントが必要となります。またプロジェクトの特性からリスクアセスメントが行われていたり、必要とされる作業成果物の特定とスケジュールの計画、テーラリング有無などが明確になっている必要がある。

このような情報を社内ドキュメントに落とし込み承認回覧の上、文書を保持します。そしてそれが関係者間のモチベーション（動機付け／目的意識）となるのです。

BP2

プロジェクトを始めるにあたりライフサイクルを定義しなくてはなりません。ライフサイクルとはプロジェクト開始〜終了までの全体の段取りを示します。そのため、どのようなライフサイクルでプロジェクトを遂行するのかプロジェクト計画書に定義しなくてはならず、また使用する標準やプロセスとの乖離がある場合にはテーラリングを行わなくてはなりません。

ライフサイクルを定義するにあたり、プロジェクトの全体スケジュールが記載されたドキュメントも必要となってきます。このドキュメントが存在することで、プロジェクトに必要なタスクと各マイルストンにおけるイベントが明確となりエビデンスが残せます。これが無くては、全体の開発費見積もりを算出できないことにも繋がるため、単純なスケジュール表という意味合い以上の価値を持つこととなります。

なおライフサイクルを定義する際には、自社製品の開発マイルストンの他にも車輛開発マイルストンも加味し、スケジュールや品質レベルに一貫性を持たなくてはなりません。車輛開発におけるイベント納入も自社製品の開発マイルストンに落とし込み、それぞれの品質要件を満たすレベルの開発実現性を担保します。

BP3

BP1及び2でプロジェクトにおける作業範囲と目標設定、マイルストンの定義ができあがりました。またプロジェクトのKick-offなどから遂行するプロジェクトの前提条件が明確となります。そして次に行わなくてはならないのは、プロジェクトが現実的に実現可能か検討となります。プロジェクトを遂行するにあたり必要な人員やツール／コストや情報を特定し見積りを行います。

必要なリソースがプロジェクト計画書に定義され、現実的にプロジェクトが達成可能なのか評価を行います。これら実現可能性の検討は、専門知識を持つ人にも協力を仰ぎ技術的観点も交え評価する必要があります。

BP4

実際にプロジェクトを進めていくうえで、進捗状況を監視するためにプロジェクトの活動が定義され、何か問題が生じた場合には調整することが求められています。具体的に、誰が何をしなくてはならないのかWBS（Work Breakdown Structure）に落とし込まれ管理される必要があります。

何か問題が生じて調整の必要性が出てきた場合は、このドキュメントをアップデートして維持していく必要があります。各イベント（マイルストンやDR、定期的な確認等）で実際のスケジュールとプロジェクト開発状況の実態がマッチしているのかを確認します。

このような環境を作り上げることで、もし不整合がある場合は是正できる状態を整えます。

BP5

BP4ではプロジェクト自体の活動の監視及び調整が求められていることに対し、BP5では見積もりとリソースの監視及び調整が求められます。BP4で活動のタスクをWBSで抽出したら、実際にどういったチームがプロジェクトに必要で、そのチームはどこのロケーションに所属し、実際にどれくらいのマンパワーが必要なのか等を明確にしておく必要があります。

またマンパワー以外にも設備やテストツール、情報伝達の仕組みやシステムなども考慮されなくてはなりません。このリソースにはSUP.1で定める品質目標が考慮され達成されなくてはなりません。

実際に見積もりを算出した場合に、なぜその金額になっているのか、金額が何に紐づいて算出されているのか根拠まで説明をできる状態でないといけません。そのためにパラメーターを設定し、いわゆる古き『鉛筆なめなめ』のようなコスト算出ではなく自動的に算出されるような仕組みが必要です。ロジック立てて見積もりを説明できるような環境を整える必要があります。

その他、BP4にも共通することになりますが、突発的なミーティングに加え、週次ミーティングやマイルストンミーティングでプロジェクトの進捗を監視します。週次ミーティングでは細かな進捗刈り取りを行い、マイルストンミーティングでは次のマイルストンへ移行できるかの審議が行われます。

BP6

実際にリソースが確保できても、それを活用するためのスキルや知識、経験を積まなくてはいけません。そのため組織図でプロジェクトの関係者を明確にしたうえで、各々どのようなトレーニングが必要なのかプロジェクト計画書などに落とし込まれていなくてはなりません。

そのうえで必要なトレーニングを各関係者が受けるようにした状態に整えたうえでプロジェクトを遂行していきます。このトレーニングは、例えばプロジェクトマネージャーが独断で決めてはならず、レベル３以上でプロセスや標準で定義されている必要があります。（レベル１では不要）

BP7

プロジェクトにおける窓口を授け、合意したコミットメントを達成するための識別・監視及び調整が求められます。実際に作業を行う人に加えリードエンジニアなどを授け、各ドメインの窓口となる人物を配置します。これはプロジェクトチームリスト（組織図）などで明確化されるよう定義されなくてはなりません。要はコミュニケーションインターフェイスが円滑化される環境を構築します。

この窓口を通し各ドメインは合意したコミットメントを達成するよう促進しなくてなりません。