第5回 コミュニケーション／まとめ
(8) 進捗管理、懸案事項管理、変更管理、障害管理を実施し、コミュニケーションをとる
PMは定期的に顧客企業にプロジェクトの進捗状況、懸案事項、予定などを報告しなければなりません。
特に懸案事項一覧を提出することにより、プロジェクト進行の阻害要因を明確にし、共有することができます。一見みっともないように思えますが、問題は隠すよりも明らかにしたほうが、解決の糸口が見えてくることがよくあります。隠しておくと誰からもヒントも助けも貰えません。
基本仕様を顧客企業に承認してもらうことは、その後の工程を進める上で重要なことです。承認してもらえないと、開発する側は何を拠り所にして開発していいのかが分かりません。ところが、承認する労を嫌い、仕様を曖昧にしたままにして、後工程で問題が出たら修正させようとする顧客企業があることは事実です。PMとしては、これに負けず承認を得て、開発スケジュール、開発品質を守ることが重要です。これも普段から顧客企業とのコミュニケーションがあればこそ可能なことです。
さらに、基本仕様の承認後の変更管理もPMの重要な仕事で、変更を変更として認めてもらうこと、逆に、曖昧な要件定義をすべて顧客企業にせいにしないことも重要です。「まずギブ、そしてテイク」の姿勢を忘れないことです。
また、総合テストフェーズ以降は、障害管理を積極的に行う必要があります。障害の傾向や原因を分析することにより、共通の作業ミスや設計ミスの発見ができ改善策も検討しやすくなります。
なお、大きなプロジェクトでは、進捗管理、懸案事項管理、変更管理、障害管理の資料はサブチームで分担作成するか管理チームで作成するようにし、PMは全体を通しての状況報告、主要な問題点の報告書だけを作るようにします。つまり、PMの重要な仕事は報告書を作ることではなく、これらの報告書を通して各リーダ、メンバー、顧客企業、関係企業とコミュニケーションを取ることです。
(9) 顧客企業、発注先企業との関係を維持する
顧客企業との関係も、発注先企業との関係も、必ず維持していくべき大切な関係です。そのためには、顧客企業に媚びてYESマンになることも、発注先企業に怒鳴って無理をさせることも、両方とも避けるべきことです。特に、顧客企業とは対等な関係になれるように、顧客の業務を理解し、プロジェクトの目標を正しく理解する努力しなければなりません。なぜならばそもそもITシステムは、企業の目標を実現するための手段に過ぎず、けっしてITシステムがあっての目標、企業ではないからです。ITシステムは所詮「使ってもらってナンボ」のものです。
プロジェクトが終わった後も、会社の垣根を越えたプロジェクト仲間で集まって、昔話、苦労話を共有する呑み会を持てたとすると、そのプロジェクトは本当の意味で成功したと言えます。逆に、お互い二度といっしょに仕事をしたくない、というような不幸な結果になってしまっては、幾らプロジェクトが終了して運用に入ったとしても成功とは言えません。
まとめ
近年、ITシステムのプロジェクトの失敗や、運用開始後の障害などが、深刻な社会的影響を及ぼすことが多くなってきました。このような背景により、IT技術教育だけでなく、PM教育も重要視されるようになってきました。しかし、教育を受けたからと言って、すぐにPMとして活躍できるものではありません。実際のプロジェクトの中でメンバーとして、あるいはリーダとして十数年に渡って揉まれた経験が無いと、自信を持ってPMできますと言えないのは、誰しも同じです。
最近では、米国のProject Management Instituteから出ているPMBOK（Project Management Book Of Knowledge 2000年版が最新）に基づいたPM講習会が流行っています。PMBOKの中では、一般的なプロジェクトを進める上で共通な必須作業項目を39個のプロセスとして明確にまとめ、体系化しています。PMIでは、PMBOKの理解度をテストするコンピュータ試験を実施しており、合格者にはPMP（Project Management Professional）の証書を発行しています。この体系化されたプロジェクトマネジメントの知識を吸収することは、PMにとってはひとつの拠り所を得ることになります。
しかしながらPMBOKの実践には、適切なPMIS（プロジェクト管理システム）と顧客企業側の心得、協力が不可欠で、また顧客企業側にもそれなりの覚悟が求められます。PMBOKは日本にも広まりつつありますが、「お客様は神様です」といった古い概念がはびこる社会でPMBOKが根付くには、まだかなりの時間がかかりそうです。
これで今回のお話を終わります。次回は、PMになるために身に付けるべきスキルについてお話します。