 |
|
|
| 前のページ 1 2
|
|
説明の中で、(I1)や(S2)などの記号が出てきますが、これは第1回で使ったプロジェクト管理状況チェック表のNo.と対応しています。チェック表で明らかになった問題点に対応する部分は、特に注意して読んでみてください。
|
|
| PMBOKの統合管理
|
これからPMBOKの9つの知識エリアについて順に説明します。PYRAMIDは、PMBOKの体系に対応していますので、説明に合せて管理テンプレートも紹介していきます。今回は、統合管理です。
|
| プロジェクト計画書
|
PMBOKではプロジェクト管理に関する知識を8つに分類していますが、それらを統合するものが「統合管理」という9つめのエリアです。統合管理の主役は「プロジェクト計画の策定」です。図2のプロジェクトの計画プロセス欄を見て分かるように、個別の知識エリアでそれぞれの計画アウトプットが作られます。例えばスケジュール管理エリアでは「スケジュール表」、コスト管理では「コスト見積書」、組織・要員管理では「プロジェクト体制図」や「リソースヒストグラム」という具合です。これらの計画は相互に関連を持ちますので、統合管理で各計画を統合したプロジェクト計画を策定し、各計画の整合性を保ちます。
プロジェクトのスタートにあたり、「プロジェクト計画書」を作成することは大切です（I2）。それは、プロジェクトリーダ自身の構想の整理でもありますが、プロジェクトメンバーやユーザーと方向性を共有するという大切な役目にもなります。統合管理における「プロジェクト計画書」は、他の8エリアの計画プロセスで作成する計画ドキュメントで策定される内容と重複しないようにします。例えば、「スケジュール表」「コスト見積書」「プロジェクト体制図」「リソースヒストグラム」などは重要なプロジェクト計画ですが、普通はそれぞれ専用のドキュメントで作成・管理されますので、統合管理のプロジェクト計画書には含めません。
表1は、PYRAMIDで用意している「プロジェクト計画書」のテンプレートです。このテンプレートでは、プロジェクトの目的、想定ユーザーや環境、そして本来はタスク管理の計画プロセスで規定するスコープ（成果物）の定義などを「プロジェクト計画書」の内容に盛り込んでいます。プロジェクトには必ず目的や目標があります。目的は暗黙の了解とされがちですが、それをきちんと明記しユーザーと確認するようにすることで、最初からとんでもない方向に進んでしまうリスクをヘッジできます（I1）。また、システムを使うユーザーがどういう業務の方々で、何名くらいで使われるかなど基本的な情報をメンバーと共有することも大切です。その想定を持って設計・開発するのと、持たないで進むのでは大きな違いが生じてきます。
|
|
表1：プロジェクト計画書
（画像をクリックするとEXCELファイルをダウンロードできます。/22KB）
|
| プロジェクト管理の管理
|
PMBOK 統合管理エリアの管理プロセスは"変更管理の統合"という項目だけですが、PYRAMIDでは、ここにプロジェクト管理をきちんとやっているかどうかを管理するための仕組みを追加しています。表2が、そのための「プロジェクト管理票」です。プロジェクト管理をどの程度厳格にやるべきかは、対象プロジェクトの規模や性質、ユーザー体制に応じて柔軟に対応すべきです。億を超える規模の開発プロジェクトと数百万の規模では期間や体制も大きく異なります。また、新規開発か既存改修か、上流工程からか下流工程だけか、請け元か二次請けか、などによっても管理のレベルが変わります。
そこで、プロジェクトのスタートにあたり「プロジェクト管理票」を作成し、そのプロジェクトにおける管理レベルを規定します。表2の中に記載されているドキュメントは、PYRAMIDで用意している管理テンプレートとDUNGEONで用意している開発標準ドキュメントです。これらのドキュメントに役割分担につきましては、第１回 図2に示すプロジェクト体系をご参照ください。計画プロセスの段階でPLとPMが協議して、今回はどのようなドキュメントを作成して、どうプロジェクトを管理するかを決めます。PYRAMIDでは、PLはプロジェクトを管理・遂行する人、PMはPLにプロジェクト管理をきちんとやらせる人という定義にしています。PMはこのプロジェクト管理票を使って、PLがプロジェクト管理をきちんとしているかをフォロー・管理するのです。
また、各ドキュメントにはユーザー共有という欄があります。これは、そのドキュメントをユーザーに見せるかどうかの方針となります。できるだけユーザーと情報共有した方が良いのは分かりきっていることですが、ビジネスの関係上それが難しいケースもあります。そのあたりの微妙な加減をPLとPMと協議して方針を決定するのです。
|
|
表2：プロジェクト管理票
（画像をクリックするとEXCELファイルをダウンロードできます。/28KB）
|
【コラム】PLとPMの役割の違いは
プロジェクト体制図を見ると、プロジェクトリーダー（PL）の上にプロジェクトマネージャ（PM）を置いているケースがよくあります。PMとPLの役割分担は、企業・組織によってまちまちのようです。メジャーリーグの監督とジェネラルマネージャのような役割分担のところもあれば、PMは単に部長や課長がなるというお飾り敵なものもあります。また、PMとPLの違いがよくわからないようなケースもあります。「PMの役目はプロジェクトの完成責任を持つこと」という定義がもっともらしく聞こえますが、部長や課長なら責任がかかるのは当たり前で、PMが何をすべきかを明示していることになりません。PLからの報告だけを聞いて管理した気になっているPMなら、いない方がましです。そこでPYRAMIDでは、PMは「PLにプロジェクト管理を徹底させること」を最低限の役割であると定義しています。
|
|
| まとめ
|
PMBOKは、プロジェクト管理におけるノウハウ・知識をまとめた国際標準で、プロジェクト管理を体系的に理解するのに適しています。ただし、あくまでもBOK（Body Of Knowledge）であり、そのままでは自社のプロジェクト管理に導入できません。そのため、ここではプロジェクト管理手法PYRAMIDのテンプレートを参考に使って、具体的なプロジェクト管理の方法まで掘り下げて説明しています。
|
PMBOK
・PMBOKは、プロジェクト管理に関する知識を「スコープ管理」「スケジュール管理」「コスト管理」「品質管理」「組織・要員管理」「リスク管理」「調達管理」「コミュニケーション管理」とそれらを統合した「統合管理」という9つのエリアに分類している。
・各知識エリアでは、「立上げ」「計画」「実行」「管理」「終結」という5つのプロセスに応じて、知識が分類されている。
・各プロセスでは、「入力」「ツールと実践技法」「出力」という3つのパートに分かれ、何をもとにどうやって何を出力するかが定義されている。
統合管理
・プロジェクトの最初に「プロジェクト計画書」を作成し、プロジェクトの目標や基礎情報（使う人が誰で何名くらいか、システム構成はどうかなど）をユーザーやメンバーと共有する。
・実際にプロジェクト管理をどの程度厳格に行うかは、プロジェクトの規模や性質により変わる。そのため、ＰＹＲＡＭＩＤでは最初に「プロジェクト管理票」を作成し、”プロジェクト管理の管理”を行う手法を取り入れている。
|
|
前のページ 1 2
|
|
|
|
|
著者プロフィール
株式会社システムインテグレータ 梅田 弘之
東芝、住商情報システムを経て1995年にシステムインテグレータ社を設立。
常駐・派遣主体の労働集約的な日本のソフトウェア業の中で、創造性にこだわってパッケージビジネスを行っている。
国際競争力のない日本のIT産業が、ここから巻き返しを図るための切り札は「プロジェクト管理」だと信じ、実践的なプロジェクト管理手法「PYRAMID」を自社開発している。
|
|
|
|
|
|
