今回は、実践ケーススタディの2つ目、「プロジェクトを成功に導くコミュニケーションの勘所」の後編である。前編では、コミュニケーション管理の失敗事例における2つの失敗要因のうちの1つ「プロジェクトにおける共通言語が定義されていない」について対策例等詳細を解説させていただいた。今回は、2つ目の失敗要因である「プロジェクトマネジメント自体が可視化されていない」について解説しよう。

マネジメント自体を可視化するってどういうこと?

先ず、可視化の目的と、可視化の仕組みの設定タイミングについて解説していく。

プロジェクトマネジメントは、プロジェクトを、その目標へ導くための営みであり、それを司るのが、PMBOK※1等に基づく管理プロセスを遂行する読者諸兄つまりPMやPMOメンバー※2である。当然のこととして、管理プロセスの選択が不適切、PMOメンバーのスキルが足りないといった原因により、マネジメント自体がプロジェクトの足を引っ張るなどということはあってはならない。

※1: Project Management Body of Knowledge
※2: Program/Project Management Office

従って、そういった管理プロセスの不備等マネジメント自体のリスクを検知・分析し、是正措置をとることがPMには求められるわけである。しかし、そのために必要なインプットは管理プロセスを定量的に可視化することで初めて収集できるようになるものが多い(以下、QA形式の補足参照)、つまり、管理プロセスを定量的且つ日常的に可視化できるようにする仕組みがマネジメント自体のリスク対策において必要不可欠なのである。

補足: リスク検出へのアプローチ

Q: マネジメントのリスクはどうやったら検出できるだろうか
A: 管理プロセスの実績を可視化し、その変動に気付くこと

Q: 変動はどうやったら検出できるだろうか
A: 実績を継続的に蓄積し、過去の実績やKPI※3で設定した目標値や想定値と比較する

※3: Key Performance Indicator:　プロセスの実施状況を計測するために、実行の度合い(パフォーマンス)を定量的に示すもの

Q: 実績はどう蓄積したら良いのだろうか
A: 日頃から実績を定量的に蓄積する仕組みをつくる

次に、可視化の仕組みの設定タイミングについてだが、プロジェクト計画及び分析フェーズ迄には、必ず設定するようにしたい。図1に示すように、先ず、可視化対象とする管理プロセスの選定と、そのKPIの設定をし、次に、実績の集計やKPIの計算に必要なインプットを収集できるような報告フォーマットやレポートラインをコミュニケーション計画に組み込むのである。インプットの事後収集は困難だし、プロジェクト途中での変更も避けるべきなので、ここでしっかり検討しておこう。なお、KPIの例は後段の3項で、ご紹介する。

図1: 可視化対象プロセス選定とKPI設定のタイミング

無駄な会議を可視化して改善しよう

前置きが長くなってしまったが、管理プロセスを可視化する必要性はご理解いただけたと思う。いよいよ、具体的に可視化ターゲットとする管理プロセスとその効果について、事例を交え解説していく。

プロジェクト終結の感慨に浸りつつ、議事録ファイルを整理すると会議数の多さに驚き、そして、これら会議は効率的だったのだろうかと考えたことはないだろうか(話は反れるが、会議は結構コストがかかっている!)。

プロジェクト終結後ならば時間をみてそれら会議の有効性を分析してみるのもいいが、プロジェクトが進行中だった場合、決めるべきことを決めるべき時に決められない非効率な会議が多発し、スケジュールが遅延し、結果としてプロジェクト目標を達成することができないリスクが潜在しているかもしれない。

そこで、簡単にできて、効果が上がりやすい方法を1つ紹介しよう。

議事録シートに会議のゴール記入欄とその達成状況のチェック欄を設けるのである。これにより、会議の目的と達成状況が可視化されるので、会議の進行者はゴールに導くという自らの役割を認識し、参加者は議論の脱線を認識できるといった会議の品質の向上が望めるだろう。加えて、各会議のゴールと達成状況のみを転記した一覧表を作成しておけば、例えば以下のような観点でリスクの検出ができるようになり、必要な是正措置を講ずることができるであろう。

  • プロジェクトの進捗や状況に応じた適切なゴールが設定されているか
  • 放置されている未達ゴールはないか
  • ゴールが未設定、または、難易度が低いゴールが毎回設定されている会議(非効率且つ反復的な会議)は無いか

図2: 議事録のイメージ

課題管理活動を可視化してみよう

次は、課題管理における可視化の例である。

繰り返しになるが、プロジェクトマネジメント自体のリスクを検出するには、PMOメンバーが実施しているプロセスの実績を可視化し、その変動を認識することが重要である。課題管理においては以下のような実績値がKPIになりうるであろう。

  • 課題検出率(検出数)
  • 課題解決率(解決数)
  • 解決所要時間(累計・平均)

図3: 課題解決数の変動を検出する例

そして、上述のような実績値を集計し、(解決数が減っている等)変動をモニタリングするのである。この仕組みによって、前編であげた事例においては、「販売システムに課題は無い」というPMOメンバーAさんの報告について、プロジェクトのスケジュールが結合テストフェーズにあり、販売システムの連携先で、同じくPMOメンバーであるBさんが担当する会計システムではシステム連携に関する多数の課題が検出されていることから、一方のシステムだけ「課題が無い」という報告は"順調"ではなく、"怪しい"と感じることだろう。つまり、課題を見落とすというリスクを防止するとともに、Aさんの管理プロセスの問題を検出し是正することができるのである。

エピローグ － 加えて1つの勘所

さて、2つの例を紹介したところで、そろそろエピローグとしたい。

今回のケーススタディでは、コミュニケーション管理における2つの勘所を紹介させていただいたが、参考になっただろうか。

  • プロジェクトにおける共通用語を定義し、認識齟齬をなくそう(前編)
  • プロジェクトマネジメント自体を可視化し、管理プロセスのリスクを検出しよう(後編)

駆け足の解説であったが、これらノウハウは、読者諸兄が担うプロジェクトの目標達成に貢献するものと確信しているので、適用を検討してもらえると幸甚である。

そして、最後にもう1つ勘所を伝授したい。KPIももちろん必要であるが、メンバーが「明るく」コミュニケーションできる環境作りもプロジェクトを成功に導くための大切な要素である。

読者諸兄が率先して「前向き」に「明るく」プロジェクト管理に取り組まれることを、切に願う。

執筆者紹介

荒浪篤史(ARANAMI Atsushi) - 日立コンサルティング マネージャー


大手ネットワークベンダーを経て、ITコンサルティング会社の立上げに参画、同社のITアーキテクトとして様々な業種、官公庁におけるオープンシステムの設計、プロジェクトマネジメントをリーディング。その後、役員として新会社を立ち上げる。2008年に日立コンサルティングへ入社、現在に至る。


監修者紹介

篠昌孝(SHINO Masataka) - 日立コンサルティング ディレクター


国内最大手のファイナンシャルグループで、BPRプロジェクトや、数多くのEコマース構築プロジェクトにて、PMを歴任。2001年に外資系大手コンサルティングファームに入社、主にERP導入や、SOA技術を駆使した大規模SIプロジェクトを成功に導いた。同社のパートナー職を経て、2007年より現職。