当記事のリンクには広告が含まれています
ASPICE解説は下記リンクよりアクセスください
プロセスアセスメントモデルはコチラから
※当該解説をより詳細に知りたい方はアセスメントモデルを参照ください
能力レベル3の取得を目標とした記事となります
Generic 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 | プロセスの実施が管理されている程度を示す |
| 作業成果物管理プロセス | GP2.2 | プロセスにより作成される作業成果物が管理されている程度を示す | |
| L3 | プロセス定義プロセス | GP3.1 | 定義されたプロセスが維持されている程度を示す |
| プロセス展開プロセス | GP3.2 | 定義されたプロセスの展開されている程度を示す |
SUP.8の基本プラクティス
基本プラクティスに関する詳細な記述はプロセスアセスメントモデルを参照ください。
SUP.8 構成管理には合計9つの基本プラクティス（BP1～BP9）が存在します。
SUP.8（構成管理）の目的はプロジェクトで作成した作業成果物が確かに確立及び維持され、いつでも利用できる状態にすることである。
BP1
BP1では作業成果物の構成管理戦略を策定することが求められています。この構成管理戦略とはプロジェクトチームが作成した作業成果物を適切に管理・維持するためのものになります。
例えば、作業成果物の制御方法やシステム閲覧方法、命名規則等がこれに該当し、構成管理計画としてまとめられる必要があります。
構成管理戦略の事例
- 人的リソース（役割、責任、権限の付与）
- 構成管理システムの構築（ドキュメント管理システム、社内フォルダ等）
- 作業成果物の命名規則（電子ファイル名、文書名）
- 文書管理システムのアクセス権
- 作成及び更新した作業成果物のリリース方法
- 作業成果物の更新もしくは発行ステータス（version情報、未承認or承認済等）
このような仕組みの構築を行い文書化して保持しなくてはなりません。
BP2
プロジェクトの開発マイルストンを通し作成される作業成果物の内容を明確にすることが求められています。どのマイルストンまでに何の作業成果物を作成しなくてはならないのか、明確に定義され文書化されなくてはなりません。
この作業成果物は、組織が独自に作成するものだけではなく、顧客やサプライヤから受領もしくは授与しなくてはならないものも含まれ、ステークホルダーのみならず法規や規格といった第三者から要求されるものも含まなくてはなりません。
これらの作業成果物は、単純なドキュメントだけではなくパラメータ値やデータといった電子媒体も含まれなくてはなりません。
BP3
BP2で明確となった作業成果物を、実際に管理するための社内インフラを構築することが求められています。この社内インフラとは文書管理システムなどの、作業成果物を管理するための仕組みを意味しており、プロジェクトのマイルストンや構成メンバーに合わせてライブラリの構成やアクセス権などを設定しなくてはなりません。
この社内インフラは文書管理システムのみならず、例えば紙媒体を管理する社内のキャビネットであったり、電子ファイルを保存するための社内サーバーであったり、組織が必要なあらゆる管理システムを考慮しなくてはなりません。
BP4
BP4では作業成果物のブランチ管理が求められています。ブランチとは、システム配下に存在するオブジェクト（作業成果物やデータ等）を同時に複数人で変更を行えるようにしたものです。
このブランチを管理することが求められています。正式登録されていないドキュメントをシステム内で管理できるようにするイメージです。
例えば下記のような仕組みです。
ver1.0（新規作成）
↓ ↓
ver1.1（Aさん編集） ver1.1.1（Bさん編集）
↓
ver1.2（A/Bさん編集を統合）
このように、新規作成したドキュメントを同時に二人が編集し結合されたドキュメントをver1.2として正式登録して管理するといった仕組みを、文書管理システム他の方法で実現できるようにしなくてはなりません。
プロジェクトの活動において様々な作業成果物が作成されますが、更新の役割が割り当てられているオブジェクトもあれば、複数人が同時に編集できる状態にあるものもあります。その際にドキュメント同士の不整合を防ぐため、文書管理システムや共有サーバー内で【チェックイン】【チェックアウト】【ロック】の機能などを実装する必要があります。
【チェックイン】: 作業成果物をシステムへ登録した状態
【チェックアウト】: 作業成果物をシステムから取り出した状態
【ロック】: チェックアウト中の作業成果物を編集できなくした状態
システムに作業成果物を格納する際にチェックインを行い、チェックアウトをしてドキュメントを編集、編集したドキュメントを再度アップロードする際にチェックインを行いシステムへ反映する。チェックアウト時（編集時）にロックをかけ、チェックインで解除する仕組みを構築すれば、二重編集を防ぐことができ作業成果物の不整合を防ぐことができます。
BP5
BP5では作業成果物の修正・リリースの仕組みを構築する必要があります。BP4で記載したような、チェックイン／チェックアウトの仕組みや、作成した作業成果物を他者へ共有できるように、システムのリンクを作成できるような仕組みが必要となってきます。
BP6
ベースラインの確立が求められています。このベースラインとは作業成果物の完全性（ここではデータや作業成果物等が全て揃っていて欠損や不整合がないことを保証すること）を意味しています。即ちプロジェクトチームや顧客等のステークホルダーが、各マイルストンにおいてその内容に合意している状態を示します。
プロジェクトの各マイルストンで段階的にこのベースラインを確立し、各イベント毎で関係者間で合意をしながらプロジェクトを遂行していく必要があります。このベースラインがプロジェクトにおける主軸となり、プロジェクトを遂行していくうえでの拠り所となります。
このベースラインはプロジェクト全体で作成するのではなく、各ドメイン（SW, HW, System等）毎に作成されることが望ましいです。
BP7
文書管理システム上の作業成果物の状態を監視し、作業成果物のドキュメント名や名称、バージョンやステータスをシステムから抽出し報告書にまとめ、報告を行う必要があります。
この報告書によりプロジェクトの実態が作業成果物観点で確認できるため、プロジェクト管理（MAN.3）における重要な情報となります。
作業成果物の一覧表等に、その作業成果物のレビュー状況がまとめられ、文書管理システム等のリンクやドキュメントバージョン、作成者といった情報が一元管理されていることが望ましいです。また報告書のなかには、作業成果物の状況（更新中、チェックイン/アウト中、リリース済）といった情報もまとめられプロジェクト管理を支援していかなくてはなりません。
BP8
BP6で要求されている確立されたベースラインの検証が求められています。検証というと難しく聞こえますが、作業成果物の完全性を目的とした監査を行い、実際に作成された作業成果物の確認を行います。
ベースラインの一貫性を担保するためにも、文書管理システムに格納された作業成果物の完全性（バージョン管理、システム自体の構造等）や作業成果物が定義されたマイルストン毎に完全に作成され、レビューなどを通して見つかった問題点が是正されているのかを監査で確認を行います。
作業成果物およびベースラインの保管管理について要求を受けています。サイバー攻撃やサーバー障害、地震といった自然災害が発生しても、作成した作業成果物を長期保管できる環境を構築しなくてはなりません。
例えば、バックアップを作成し、障害が発生した場合でも迅速に復旧できる環境を構築することが求められています。
コメント