プロジェクトマネジメントにおけるプロセスとは何か？PMBOKと共通フレームのプロセスを解説
プロダクトの品質はプロセスの品質から
―プロセス改善の際に用いられる仮説
プロセスとは
プロジェクトマネジメントにおいて、プロセスとはプロジェクトの最終的な結果に向けて系統的に実行する一連のアクティビティのことを意味します。
もともと"process"は「工程」と訳されますが、プロジェクトの終了までの工程をイメージすればよいでしょう。
PMBOKにおけるプロセス
PMBOKでのプロセスの定義
PMBOKではプロセスを「最終的な結果に向けて系統的に実行する一連のアクティビティ」と定義しています[1]PMBOK第６版、732頁。。
さらにプロセスは、プロジェクトの全期間を通して生じる、相互に重なり合った活動であるとも言えます。
49のプロセス、５つのプロセス群
プロジェクトマネジメントのガイドラインであるPMBOKでは49のプロセスを定義し、さらにそれらのプロセスを５つのプロセス群に分類しています。
以下、プロセス群ごとにプロセスを列記していきます。
立上げプロセス群
立上げプロセス群ではプロジェクト憲章の作成などを通じて、プロジェクトやフェーズを開始する認可を得て、プロジェクトの新しいフェーズを定義するために実行されます。
- プロジェクト憲章の作成
- ステークホルダーの特定
計画プロセス群
計画プロセス群ではプロジェクトの目標を達成するために、どのような行動が必要なのかを定義していきます。
- プロジェクトマネジメント計画書の作成
- スコープ・マネジメントの計画
- 要求事項の収集
- スコープの定義
- WBSの作成
- スケジュール・マネジメントの計画
- アクティビティの定義
- アクティビティの順序設定
- アクティビティの所要期間見積り
- コスト・マネジメントの計画
- コストの見積り
- 予算の設定
- 品質マネジメントの計画
- 資源マネジメントの計画
- アクティビティの資源見積り
- コミュニケーション・マネジメントの計画
- リスク・マネジメントの計画
- リスクの特定
- リスクの定性的分析
- リスクの定量的分析
- リスク対応の計画
- 調達マネジメントの計画
- ステークホルダー・エンゲージメントの計画
実行プロセス群
実行プロセス群ではプロジェクトの要求事項を満たすために、計画された作業を実行に移していきます。
- プロジェクト作業の指揮・マネジメント
- プロジェクト知識のマネジメント
- 品質のマネジメント
- 資源の獲得
- チームの育成
- チームのマネジメント
- コミュニケーションのマネジメント
- リスク対応策の実行
- 調達の実行
- ステークホルダー・エンゲージメントのマネジメント
監視・コントロールプロセス群
- プロジェクト作業の監視・コントロール
- 統合変更管理
- スコープの妥当性確認
- スコープのコントロール
- スケジュールのコントロール
- コストのコントロール
- 品質のコントロール
- 資源のコントロール
- コミュニケーションの監視
- リスクの監視
- 調達のコントロール
- ステークホルダー・エンゲージメントの監視
終結プロセス群
PMBOKのプロセスは必要最低限
このようにPMBOKでは49のプロセスを定義しており、プロジェクト・マネジャーは少なくともこれら49のプロセスに対し、答えを出していかなければなりません。
しかし、PMBOKで定義されたこれらのプロセスはあくまで必要最低限のものであるという意識も持っておかなくてはなりません。なぜなら、PMBOKに掲載されているプロセスはあらゆる分野のプロジェクトで共通の事項を抽出したものであるため、どのようなプロジェクトでもある程度適用できる知識が詰まっているからです。
しかし、ITプロジェクトに照らし合わせて言えば、PMBOKには「開発をどのようにして進めていくか」というプロセスに対する言及はありません。ITプロジェクトを円滑に進めるためには、ITプロジェクト特有のプロセスも把握しておく必要があります。
共通フレームにおけるプロセス
共通フレームの８つのプロセス
システム及びソフトウェア開発とその取引の作業項目を定義した共通フレームでも、プロセスが定義されています。
共通フレームでも、PMBOKのプロセス群のように、プロセスを８つの大項目に分けています。
以下、８つの大項目に沿って、プロセスを列記していきましょう。
合意プロセス
- 取得プロセス
- 供給プロセス
- 合意・契約の変更管理プロセス
テクニカルプロセス
- 企画プロセス
- システム化構想の立案プロセス
- システム化計画の立案プロセス
- 要件定義プロセス
- システム開発プロセス
- システム開発プロセス開始の準備プロセス
- システム要件定義プロセス
- 実装プロセス
- システム結合プロセス
- システム適格性確認テストプロセス
- システム導入プロセス
- システム受入れ支援プロセス
- ソフトウェア実装プロセス
- ソフトウェア実装プロセス開始の準備プロセス
- ソフトウェア要件定義プロセス
- ソフトウェア方式設計プロセス
- ソフトウェア詳細設計プロセス
- ソフトウェア構築プロセス
- ソフトウェア結合プロセス
- ソフトウェア適格性確認テストプロセス
- ソフトウェア導入プロセス
- ソフトウェア受入れ支援プロセス
- ハードウェア実装プロセス
- 保守プロセス
運用・サービスプロセス
- 運用プロセス
- 廃棄プロセス
- サービスマネジメントプロセス
支援プロセス
- 文書化管理プロセス
- 品質保証プロセス
- 検証プロセス
- 妥当性確認プロセス
- 共同レビュープロセス
- 監査プロセス
- 問題解決プロセス
プロジェクトプロセス
- プロジェクト計画プロセス
- プロジェクトアセスメント及び制御プロセス
- 意思決定管理プロセス
- リスク管理プロセス
- 構成管理プロセス
- ソフトウェア構成管理プロセス
- 情報管理プロセス
- 測定プロセス
組織のプロジェクトイネーブリングプロセス
- ライフサイクルモデル管理プロセス
- インフラストラクチャ管理プロセス
- プロジェクトポートフォリオ管理プロセス
- 人的資源管理プロセス
- 品質管理プロセス
- 知識管理プロセス
- ソフトウェア再利用プロセス
- ドメイン（領域）エンジニアリングプロセス
- 再利用資産管理プロセス
- 再利用施策管理プロセス
- 「システム監査」プロセス
プロセスレビュー
- ユーザビリティプロセスビュー
テーラリング（修整）プロセス
- テーラリング（修整）
テクニカルプロセスが共通フレームの特長
共通フレームで定義されたプロセスの中には、PMBOKで定義されたプロセスとの重複も多く存在します。プロジェクトマネジメントという観点から見ると、共通フレームのプロジェクトプロセスの内容はそこまで充実しているとは言い難いものです。
しかし、共通フレームではPMBOKでは言及できなかった実際の開発に関するプロセスを「テクニカルプロセス」として定義しているのが特長だと言えましょう。
PMBOKと共通フレームの併用を推奨
プロジェクトマネジメントにおけるプロセスとはプロジェクトの最終的な結果に向けて系統的に実行する一連の作業のことであり、プロジェクトマネジメントのガイドラインであるPMBOKであっても、システム及びソフトウェア開発のガイドラインである共通フレームでもプロジェクトのプロセスを定義しています。
包括的にプロジェクトのプロセスをまとめたのがPMBOKであり、計画のプロセス群に最も重点が置かれています。
共通フレームではテクニカルプロセスの存在がPMBOKと比較したときの特色であり、PMBOKでは言及できなかった具体的な開発のプロセスをまとめてあります。
これら両者の特色を活かし、PMBOK・共通フレームを併用しながらプロジェクトのプロセスを考えると、過不足のないプロセスをそろえることが可能となるでしょう。
注
| ↑1 | PMBOK第６版、732頁。 |
|---|