第３回　プロジェクトマネージメント方法論を学ぶ

• #プロジェクトマネージャー

これもプロジェクトに参加していれば自然とプロジェクトの進め方が分かってきますが、時々は、プロジェクト管理についての本を読んだり講習会に参加したりして、体系的に学ぶ機会を持つべきです。

今回は見積り手法、品質管理手法、コミュニケーション、及び、PMP国際標準について言及しますが、ご承知のように、これらのほかにもリーダシップやマネージメント、組織論など多くの関連する書物が出ていますので、いろいろ勉強してください。

見積もり手法

最近、1970年代に提唱されていたファンクションポイント法が見積り手法として見直されているようです。サーバの分散化でプログラムがどのサーバで動き、どの言語で開発するのかなどが見積り時点で決められない場合が多く、純粋に機能から工数を推測する方法を取らざるを得なくなって来ているようです。

一方で、できるだけ細かい作業タスクを洗い出し、期間を考えて人を山積みして工数を集計する従来の見積り方法も有用です。何かの作業を見積るときには、少なくとも上記２つの手法を使用して見積ると良いでしょう。

品質管理手法

社会生活のほとんどの場面でコンピュータとそれに搭載されたソフトウェアが登場するため、今やソフトウェアの品質は社会的な問題となっています。ソフトウェアの品質は、結局はバグの影響度と個数、処理内容とレスポンス時間の相関関係で計られるものだと思われます。ただし、もっと広義には、ソフトウェアの必要動作環境の費用とソフトウェアの価値の相関関係とか、ソフトウェアの拡張性などが品質メトリックスになるのかも知れません。

「品質は検査で計るものでなく、設計で向上させるものである」という言葉がありますが、第2回で述べたような「プログラム規約とガイドライン」の存在が、まさに品質向上に大きな役割を果たします。

コミュニケーション

特に大きなプロジェクトでは、コミュニケーションをどう取るかは重要な課題です。

コミュニケーションカテゴリとしては、主にプロジェクト計画情報、設計情報、開発規約情報、開発ガイドライン情報、進捗情報、障害情報などがあります。

コミュニケーションパスとしては、サブチーム内、サブチーム間、対協力会社、対上司、対社内他部門、対顧客などがあります。

また、コミュニケーション手段としては、フォーラム、メール、フォルダ書類配布、書類回覧などがあります。

PMにとって最も重要なコミュニケーションは、サブチームからの進捗報告を確認し、全体の進捗報告としてまとめて報告することです。特に我が国の場合、進捗報告の場は議論の場でなく丸く納める場になっていることが多く、結局、関係者が問題を認識するまでに非常に時間が掛かってしまいます。事なかれ主義を決め込むか、物議を醸してでも会議の場で議論して時間を節約するか、ＰＭとして難しい判断を迫られることもあるでしょう。

いろいろな意見を認める自由があることが欧米の強さの基だと思われますが、まだまだ我が国はそこまで行っていないようです。

PMP国際標準

米国PMI（Project Management Institute）の発行しているPMBOKには、プロジェクトの定義に始まって、プロジェクトに共通の５つのフェーズ、９つの知識エリア、39個のプロセスをきっちりと定義しています。これからPMを目指す人にとっては最低限必要な知識となるでしょう。

５つのフェーズは、下記の通りです。

1. 立ち上げ
2. 計画
3. 実行
4. コントロール
5. 終結

９つの知識エリアは、下記のとおりです。

1. Integration：統合プロジェクト管理
2. Scope：スコープ管理
3. Cost：コスト管理
4. Time：スケジュール管理
5. Human resource：人的資源管理
6. Communication：コミュニケ−ション管理
7. Quality：品質管理
8. Risk：リスク管理
9. Procurement：調達管理

39個のプロセスとそれぞれがどのフェーズと知識エリアに含まれるかを下図にまとめました。

組織

PMBOKにはプロジェクト遂行チームを支える組織のタイプと、それぞれの長所短所について記述があります。ここではプロジェクトチームを支える組織について、触れてみたいと思います。

今まで申し上げたように、凄まじいIT技術の進歩やビジネスニーズの多様化などによりITプロジェクトは益々複雑、難解になってきています。もはや、単純にPMが優秀であればプロジェクトがうまく行くような時代ではありません。プロジェクトに必要な技術、ノウハウ、リソースの組織的なバックアップが無ければ、プロジェクトの成功はおぼつかなくなって来ています。

では、現代の複雑、難解なITプロジェクトを遂行するプロジェクトチームを支える組織は、どうあるべきでしょうか。たとえば、以下の図のように顧客対応の縦割り組織と技術対応の横割組織のミックスが、理想的な姿ではないでしょうか。

この例では、プロジェクトチームを構成する主要なメンバー（PMとサブチームリーダ）は、顧客対応組織に所属しています。主要メンバーはプロジェクト計画を策定し、アプリケーションニーズを正確に把握してプロジェクトチームを構成し、プロジェクトを進めて行きます。この際、顧客対応組織のメンバーだけでなく、必要な技術を担当する技術対応組織からもメンバーを入れて、チームを構成します。

技術対応組織のメンバーは積極的にプロジェクトに参加し、開発プロセスをリードしたり、設計書を作成したり、インプリメントをリードします。なお、技術対応組織のメンバーは、複数のプロジェクトに同時に参加することもあり、メンバー同士のノウハウ交換も頻繁に行って技術革新に追従しなければなりません。

このような組織には、顧客対応組織と技術対応組織の役割範囲を明確にしづらいという短所もありますが、もし顧客対応の縦割り組織だけしかなければ、複雑、難解、大規模なプロジェクトには十分には対応できません。

まとめ

これで3章に渡ったプロジェクトマネージャについてのお話を終わります。このお話しを読まれた皆さんは、どのような感想をもたれたでしょうか？

「自分の持っていたイメージとは違った」と思われた方、「なんだか大変そうだから、ＰＭなどになって苦労したくはない」と思われた方、「これは自分のやりたいことではない」と思われた方など、いろいろな感想を持たれたのではないかと思います。

もし、「よし、PMになるぞ」と思われた方がいらっしゃれば、その人達には、最後に一つアドバイスを申し上げておきます。

PMになるということは、ある意味でジェネラリストになることです。PMは、プロジェクトチーム内のすべての人たちが力をスムースに発揮できるように環境、スキル、人材、そして人間関係を整えなければなりません。そのため、プロジェクトに関係するあらゆる人がどんな役割を果たしているのか、そして何か支障がないかを観察していなければなりません。

たまには、プロジェクト途中でキーとなっていたメンバーが辞めて行ったり、納期を優先して赤字になったり、顧客が仕様変更を認めてくれず変更作業の費用が取れないなど、うまく行かないことも有り得ます。そんなときは、まず原点に戻って、プロジェクトの問題に対して正直であること、嘘を嘘で塗り固めるようなことをしないことです。そしてプロジェクトの問題点を明らかにして関係者と共有し、一つ一つ解決していく努力をすることです。やるだけのことをやったら、天命を待つしかありません。皆さんの幸運を祈ります。