標準とデータベースによるプロジェクト管理の改善

ときとして組織がプロジェクト管理の標準(スタンダード)を採用したがらないのは、実践的な応用方法を理解できていないか、不必要なオーバーヘッドを恐れているためだが、いずれは標準化が必要なことを思い知ることになる。しかし、比較的容易に標準に従えるようにする環境を作成することは可能だ。本稿では、プロジェクト管理手順の採用と高品質な製品やサービスの提供をより簡単に行うための実用的なタスクをいくつか紹介する。

まずは、プロジェクトマネージャとしての自らの責任をしっかりと受け止める必要がある。プロジェクトの対象範囲、時間、コストの各制約に関与するのは自分ひとりであるかのように振る舞うのだ。実際、標準を採り入れていない組織では、そうした制約が自分自身にはね返ってくることが多い。残念ながら、これら3つの制約の最低2つを定義できない限り、何も手をつけないうちにプロジェクトの命運が尽きてしまうおそれがある。当面は、持てる時間内で今ある仕事に対して最善を尽くすことだ。標準の確立に努めていれば、やがては課せられた責任に心地よささえ覚えるようになるだろう。自分のプロジェクト管理の進め方に手応えを感じたら、今度はそれを徐々に他の人々と共有していくとよい。

ただし、プロジェクト管理手順に対する部下たちの無関心な態度は決して変えられないことを心得ておかねばならない。また、あなたが成功させたやり方が経営陣によってすぐに採用されるとは思わないことだ。そうすれば、他の人々を教育する必要性を感じることなく、標準の確立に向けてうまく取り組めるだろう。ほとんどの人はあなたの采配ぶりを気にすることはないが、速やかに軌道に載せて予定通りに完了させ、余分なコストをかけないことを望んでいる。とりあえず、経営層が何らかの手順の導入に乗り気になるまでは、自らの手順を定義して従うことになる。

標準を採用する

プロジェクトマネージャに必要なのは、自らが手がける2つ以上のプロジェクトに共通するタスクのリストである。たとえば、どんなプロジェクトにも予めその活動範囲を示す一覧表が必要になり、そうした一覧表は特定のタスク群で構成される。わかりきったことを書き出す必要はないが、従うべきプロジェクト管理の標準は定めておかねばならない。以下に、とっかかりになる簡単な例を示そう。

意欲的に取り組みたい人を対象としたものとしては、Project Management Institute(PMI)が強く支持されており、各種標準の概要がわかりやすく説明されている。また『 A Guide to the Project Management Body of Knowledge, Third Edition 』(PMBOK)という専門書を1冊手元に置いておくとよい。多くの書店で手に入るはずだ。このPMBOKには、先に挙げた3つの制約の範囲内でプロジェクトを管理するのに必要なタスクが定義されている。ただし、PMBOKにはさしあたって必要なこと以上の情報が記されているので、初めて読む場合にはまず70ページを開いてシーケンスの考え方を理解すること。そのあ後、第4章から目を通し、各章のまとめに記されている「Outputs」を利用して、自らのプロジェクトのタスクを作成していく。

可能なら必ずテンプレートを利用する

1
「ProjectPlans」テーブルとその関連テーブルによって、プロジェクトタスクの管理とレポート作成が可能になる。また、「Phase」および「SubPhase」の各テーブルは自分用のテンプレートを構成している。「ProjectPlans」、「Projects」、「tblProducts」の各テーブルは、活動中のプロジェクトについて日々の作業用テーブルして機能する。

自ら用意した標準を適用してテンプレートを作成すれば、想像以上に時間を節約することができる。作成したテンプレートをクッキーの型抜き器のように使ってプロジェクト遂行の管理に役立てれば、プロジェクトの計画やドキュメントの管理に時間をとられずに済むのだ。最初はMicrosoft Projectの大げさなテンプレートと、補助用のドキュメントとして有効なWordおよびExcel文書のいくつかを利用していたが、結局それらによって時間を大幅に節約できるのは、自分のテンプレート、プロジェクト管理計画、ドキュメント、プロジェクト計画、ステータスレポートをデータベースに移行するときだけであることがわかった。そこで、次のような機能を備えたプロジェクト管理のソフトウェア製品を検討するとよい。

  • テンプレートを使用してワンクリックでドキュメントや計画が作成可能
  • 日々のタスクに対するソート、フィルタリング、編集が容易
  • すべてのステータスレポートを同一の作業用データベースから作成
  • あるプロジェクトの活動が別のプロジェクトにどのように影響するかを確認できるレポートの作成
  • 完了したプロジェクトを振り返って将来のプロジェクトの見積りに活用できるレポートの作成

予算が十分になければ、自分でデータベースを構築してもよい。最初は、次の5つのテーブルがあれば十分である。

  • tblProducts ― 管理対象プロジェクトのリスト
  • Projects ― 実行中のプロジェクト計画のリスト
  • Phases ― 計画フェーズや実行フェーズなど、各種フェーズの標準リスト
  • SubPhases ― データベース設計やWebページ開発など、それぞれのフェーズを構成するタスクの標準リスト
  • ProjectPlans ― 日々それに関わる作業をして更新を行なうタスクのリスト

フェーズ

ソート順

プロジェクト事前立案

10

プロジェクト計画策定

20

ビジネス分析

30

技術的検討

40

データベース分析

50

開発

60

品質保証

70

ドキュメント整備

80

技術指導

90

導入

100

ユーザ教育

110

監視

120

メンテナンス

130

レポート

140

サポート

150

要求の変更

160

終了

170

表1:ITプロジェクトの各種フェーズの例

フェーズ

サブフェーズ

プロジェクト事前立案

後見担当役員の人選

プロジェクト事前立案

プロジェクト事前計画書(作業明細書)の作成

プロジェクト事前立案

プロジェクト事前計画書(作業明細書)の承認

プロジェクト事前立案

ビジネスのニーズおよび目的の定義

プロジェクト事前立案

プロジェクト全体の活動範囲/目的の定義

プロジェクト事前立案

戦略方針との整合化

プロジェクト事前立案

プロジェクトの構想設計

プロジェクト事前立案

主要な利害関係者の確認および説得

プロジェクト事前立案

主要な潜在的リスクの確認

プロジェクト事前立案

プロジェクトマネージャの役割定義

プロジェクト事前立案

コストおよびスケジュールの見積もり決定

プロジェクト事前立案

必要なリソース(人員)の確認

プロジェクト事前立案

プロジェクトマネージャの任命

プロジェクト事前立案

プロジェクト着手用文書の準備

あるプロジェクトにおけるプロジェクト事前立案フェーズを構成する一般的なタスクの例。こうしたタスクの内容および実行順序は企業によって異なる。

テンプレートがあれば、すぐにでも作業を始めることができ、タスクのとりこぼしが起こる可能性も低くなるが、テンプレートはきっかけになるものに過ぎない。プロジェクトは本質的にユニークな存在であるため、それぞれのフェーズには必要な独自のタスクが追加されることになる。

プロジェクトのドキュメントリポジトリを用意する

各種契約書やアーキテクチャ図など、どんなに努力しても自分ではデータベースに追加できないドキュメントのための領域を作成しておく必要がある。バックアップが行われる共有ネットワークドライブ上に”\MyProjects\\\00 Pre-Project Planning”のようなわかりやすいフォルダ構造を作成したものを使用する。

2
プロジェクト用ドキュメントのためのフォルダ構造の例
新しいプロジェクトに着手するときに新規プロジェクトフォルダにコピーできるように、空のフォルダテンプレートを作成しておき、自分のドキュメントがどのフォルダに入っているのか常に把握しておくこと。また、プロジェクト完了後にサポートチームが製品サポートに使用する教育およびサポート用ドキュメントのための「Support Docs」フォルダは削除せずにずっと残しておくこと。プロジェクト用の各フォルダはやがてアーカイブ化するか削除することになるが、「Support Docs」フォルダを削除する必要はないだろう。なお、サポート用のドキュメントは製品のバージョンが変わるたびに更新し続けなければならない。フォルダの直下にあるマスタの「Support Docs」フォルダであれば、こうしたリポジトリの機能を果たせるだろう。

計画ではなくプロジェクトを管理する

プロジェクトデータベースのリポジトリ、テンプレート、共有ドキュメントフォルダが用意できたら、プロジェクトの計画を作成する準備が整ったことになる。テンプレートから計画を作成すると、プロジェクトデータベースが、日常的にその計画を利用できる環境を提供してくれる。ただし、テンプレートの粒度が細かすぎると、タスクの監視や更新に支障をきたすおそれがある。タスクの進捗の追跡に手がかかり過ぎる場合は、各タスクの期間を長めにとるとよい。私の扱うタスクのほとんどは、必要な工数に関係なく、期間を1週間に設定している。私の場合、タスクの更新や終了は毎日行うが、プロジェクト計画のレビューとステータスレポートの作成は週の終わりに行なっている。残念ながら、この方法ではスケジュールの遅れを十分に把握できず、リスクが高くなってしまう。だが、計画の管理にかける時間を減らせるため、より多くの時間をプロジェクトの管理に費やせる。この方法はかえって問題を引き起こすこともあるので、プロジェクトのマイルストーンに影響する可能性のあるタスクはしっかりと監視しておく必要がある。

混乱のない状態を維持する

3
プロジェクト計画作成後のプロセスの流れ。電話や電子メールなどで寄せられる要求がプロジェクトデータベース内のタスクに変わる点に注目。
プロジェクト計画のカスタマイズや、独自性を持つプロジェクトに必要な詳細情報の追加、それに日付、マイルストーン、タスク実行期間、リソース等の設定を済ませて、その内容に満足したら、プロジェクト計画の承認を行なう。こうして承認された計画が、あなたが仕事を進めるうえでのベースラインとなる。だがすぐに、さまざまな形の要求によってこのベースラインは変貌し始める。

こうした要求は、ドキュメントリポジトリやプロジェクトデータベースに流し込む。また、受信ボックスを空っぽの状態に保つために、さまざまな取り組みが必要になる。新たに生じるタスクを把握したければ、ボイスメールや電子メール、議事録をタスクのリストとして利用してはならない。決まった日時までに終わらせる必要のある会議やタスクはすべて、携帯情報通信端末(PDA)のカレンダーやプロジェクト計画に登録して、受信ボックスから削除するのだ。PDAを持っていない場合は、Palm Desktopが無料でダウンロードできる。残しておきたい添付ファイルやメールの本文は、ドキュメントリポジトリに移せば、受信ボックスから削除できる。

これらのプロジェクト管理のわずかな標準を適用するだけでも、きっと仕事を始めるのに役立つだろう。あなたの思い描く理想とのギャップを埋めるとともに、可能ならいつでもプロセスの改善点をテンプレートに追加することができる。テンプレートを作成しておけば、新規プロジェクトの実行許可が出る前に何を定義すべきかといったことは、大した問題ではなくなるはずだ。たとえば、サポートスタッフの研修が自分用のプロジェクト計画テンプレートに含まれていれば、スケジュールに入れ忘れるなどということは決して起こらないだろう。

また、プロジェクトデータベースを利用するときは、PMBOKやその他のプロジェクト管理システムから追加の詳細情報をテンプレートに追加する。たとえば、PMBOKの173ページに定義されているコストパフォーマンス指標(CPI)やスケジュールパフォーマンス指標(SPI)を計算するための情報などだ。もっと踏み込んで、時間の集計や、プロジェクトのリソース配分の現状に基づいてリソースが利用できるかどうかの予測を行なうこともできる。また、バグの追跡や知識ベースの各項目に対応したテーブルを検討してもよいだろう。一度データベースに移行してしまえば、その可能性に際限はないのだ。

NewsForge.com 原文