 |
|
|
| 前のページ 1 2 3 4 次のページ
|
|
説明の中で、(I1)や(S2)などの記号が出てきますが、これは第1回で使ったプロジェクト管理状況チェック表のNo.と対応しています。チェック表で明らかになった問題点に対応する部分は、特に注意して読んでみてください。
|
|
| 管理ツール利用を積極的に推奨
|
PYRAMIDは、PMBOKの体系をベースにした実践的なプロジェクト管理手法です。方法論だけでなくプロジェクト管理に必要なドキュメントテンプレートを用意していることを特徴としています。これまでに紹介したようにドキュメントテンプレートはExcelをベースに作成されています。しかし、紙ベースのものよりもWebツールなどを使った方が効率が良いと考え、管理ツールの利用を積極的に推奨しています。
最終的には、PYRAMIDを丸ごと管理システム化したいと考えていますが、現時点では表3のように効果の大きなものからツールを採用しています。紙ベースまたはツール利用、どちらも許可するという方針にしています。
例えば、総合スケジュール表や機能別スケジュール表など、ガントチャート方式の管理ドキュメントの作成では、マイクロソフト社の「MS Project」の採用もOKとしています。社内の利用状況を見ると、Excelベース派が半分、MS Project派が半分といったところのようです。また、プログラムソースの管理には、同じくマイクロソフト社の「MS Visual Source Safe」を採用しています。プロジェクトチームによっては、プログラムだけでなく仕様書のバージョン管理にもこのツールを使っています。
品質管理で使う「障害報告書」は、第5回で紹介したようにWebベースの「障害管理システム」を自社開発して利用しています。同様に、コミュニケーション管理における「質問管理票」の代わりとして、Webベースの「質問管理システム」を用意しています。どちらも企業単位のログイン管理ができるようになっていますので、開発メンバーだけでなく、協力会社やユーザー企業も一緒に利用できます。
|
| 管理タスク |
Excelベースの
テンプレート |
管理ツール |
| スケジュール管理 |
総合スケジュール表
機能別スケジュール表 |
MS Project |
| 品質管理 |
障害報告書 |
障害管理システム |
結合テストスケジュール表
総合テストスケジュール表 |
MS Project |
| コミュニケーション管理 |
質問管理票 |
質問管理システム |
| 変更管理 |
MS Visual Source Safe
PVCS Tracker |
|
表3：PYRAMIDで採用している管理ツール
|
| 情報の配付プロセス
|
PMBOKの実行プロセスでは、「プロジェクトの記録」「プロジェクト報告書」「プレゼンテーション」などが出力として定義されています。PYRAMIDでは、これら実行プロセスを支援するドキュメントテンプレートとして、打合せの記録を行う「打合議事録」とレビュー結果をまとめる「レビュー報告書」を用意しています。
なお、レビュー報告書のテンプレートは、第5回「品質管理」のページで紹介しています。
|
| 打合議事録
|
コミュニケーション管理の中で最も基本的なことは、打合せを行ったら"打合議事録"を残すということです（M1）。しかし、プロジェクトの中には、この当たり前のことがきちんと実行できていないものがあります。これは"打合議事録を書く"というルールが明確化されてなく、その実施をプロジェクトリーダー個人の判断にまかせているような場合に生じます。プロジェクトリーダもいろいろな考え方を持っていますので、スケジュールに追われると、つい打合議事録を書く時間を惜しんでしまうのです。
以前、弊社のプロジェクトマネージャ（PM）の最低限の役割は、プロジェクトリーダ（PL）にプロジェクト管理を遂行させることと述べました。つまり、「打合を行ったら、必ず打合議事録を書く」ことをルールとして明確にし、「きちんと打合せ議事録を書いているかフォローする」こともPMの役割としています。このような体制にしていれば、PMかPLかどちらがしっかりしていればプロジェクトはきちんとする"はず"なのです。
また、打合議事録の様式がプロジェクトごとにまちまちということも良くあります。全プロジェクトで完全に統一させるべきとまでは言いませんが、プロジェクトリーダ個人単位ではなく、組織として標準ドキュメントを用意しておきましょう。
打合議事録のポイントは、「迅速に」「ポイントを絞って」書くということです。よく、打合日から1週間以上たって打合議事録が書かれるケースがありますが、日が経つにつれ内容が薄くなり、漏れも大きくなります。打合議事録は鮮度が命なので、1日以内に書くという原則を定めて遵守させるようにしてください。
打合議事録の書き方の指導してください。国際会議などでは打合での発言を全部速記しますが、システム開発における打合議事録は要点をまとめて書くことが大切です。だらだらと書くのではなく、方針決定に関わる重要なことに的を絞って書くコツを教えてあげましょう。
結論だけを書くのか議論の過程も書くのかも焦点となります。後から見て、どうしてこう決まったか分からなくなることがあります。そのため、打合議事録に議論の過程も書くことはもちろん大切です。しかし、打合せ内容を全部書くと大変な作業になってしまいますし、分厚い議事録は読む側にしても大変です。
そこで私は、"結論だけを書き、必要に応じて決定に至った理由も書く"というスタイルにしています。結論だけを書き、議論の過程がないと後で分からなくなりそうな事項だけ、○○という理由で△△とする」というように決定理由を書くのです。
図2は、PYRAMIDにおける打合議事録のテンプレートです。打合議事録には、"決まったことの記録"という役割だけでなく、両者の宿題（ペンディング事項）を書き留めて、相互にフォローするという重要な役割があります。そのため、本テンプレートでは「保留」という欄を設け、担当と期限を書けるような様式にしています（M2）。
|
図2：打合議事録のテンプレート
（画像をクリックするとEXCELファイルをダウンロードできます。/35.5KB）
|
 Excel派かWord派か
PYRAMIDのドキュメントテンプレートを作成するに当たり、Excelが良いかWordが良いかのアンケートおよびヒアリングを社内で行いました。その結果は、表形式の管理資料が多い、複数Sheetを1つのBookにまとめられる、などの利点からExcel派の方が若干多いという程度でした。どちらかに決めないとやりにくいので、最初のテンプレートはこれまで紹介した通り全てExcelをベースに作成しました。
しかし、「打合議事録」や「レビュー報告書」などの文章主体のドキュメントは、やっぱりWordの方が使いやすいという意見も多くあり、これらについてはExcelのほかにWordのテンプレートも用意しています。
サイズはA4に統一ということで異論は少なかったのですが、用紙の縦か横かでも意見が分かれました。これに関しては"原則は横"としたのですが、やはり「打合議事録」や「レビュー報告書」などは縦の方が書きやすく、いくつかのドキュメントは縦型も併用可能として用意しています。このように、標準テンプレートをどこまでそのまま使わせるかは常に問題となります。PYRAMIDでは、「様式の変更に関しては寛容、運用の徹底に関しては厳しく」という姿勢を基本原則としています。
|
|
前のページ 1 2 3 4 次のページ
|
|
|
|
|
著者プロフィール
株式会社システムインテグレータ 梅田 弘之
東芝、住商情報システムを経て1995年にシステムインテグレータ社を設立。
常駐・派遣主体の労働集約的な日本のソフトウェア業の中で、創造性にこだわってパッケージビジネスを行っている。
国際競争力のない日本のIT産業が、ここから巻き返しを図るための切り札は「プロジェクト管理」だと信じ、実践的なプロジェクト管理手法「PYRAMID」を自社開発している。
|
|
|
|
|
|
