TOPプロジェクト管理> どんな「進捗報告」が必要なのかは対話からみつかる
Win - Winプロジェクト管理
ユーザ納得のWin - Winプロジェクト管理

第4回:中身の濃い進捗報告会を作るには〜後編〜

著者:ウルシステムズ  村上 歴   2007/8/31
前のページ  1  2  3
どんな「進捗報告」が必要なのかは対話からみつかる

   弁田氏は「これは少々手強いな」と思いながらも話を進める。

   結佐氏「で、最後の課題の話なのですが、課題を報告するときは、課題の内容よりも、それに対して我々が何をしたらよいかに重点を置いた報告をもらえるのが一番ありがたいです。ただ、それも、もちろん、こちらが受けられる提案にしていただくかないといけないのですが……」

   弁田氏「了解です。課題は課題一覧にあげる際、それを解決するためのアクション案もあわせて明確にしておきます。ただ……1つ相談があるのですが」

   結佐氏「?」

   弁田氏「結佐さんだから相談してしまいますが、正直にいうと、課題への対処として御社にお願いしたいことをきちんと書こうとすると、どうしても追加費用の話にならざるを得ないことがあります。お金の話になると、定例会資料には書きづらいですね……」

   結佐氏「書きづらいのはわかりますよ。ただ、追加費用云々の話と、今のプロジェクトがどうなっていて、どうしなければならないかを一緒にして語ると実態がみえなくなってしまいます。これらは切り離して考えたいです。なので、問題があった時の対処案として、単に人を追加させてください(お金をだしてください)というのではなく、人を追加するとこう、追加しない場合はこう、とはっきりしていただいた上でどっちがお勧め、というところまでだしていただければこちらも判断しやすいです」

   弁田氏「なかなか厳しい要求ですけど……なんとか応えますよ」

   結佐氏「ある程度営業的な思惑が双方にあるのは仕方ないですが、腹の探り合いや営業交渉でプロジェクトに手を打つのが遅れたらバカらしいですからね……。こちらの立場で考えてくれている、と感じられれば判断も早くなりますし、払うべき時にはちゃんと決裁をあげますよ。本当にそうするしかないのか納得いかないまま追加費用をだすのが一番やりにくいです」

   弁田氏「なるほど。ただ、実際、やっぱりその辺の話は定例会というよりは別途打ち合わせでもいいですかね?」

   結佐氏「そうしましょう。定例会では『別途調整する予定』のように書いていただいて、別途やる打ち合わせでは、きちんと対処案をだしてもらえればよいです」

   弁田氏「了解です……。意識あわせしたかったのはこれくらいです。意外と時間がかかってしまいましたが、ありがとうございました」

   結佐氏「こちらにも、しっかり伝えた感がありますよ。では、次回の進捗、よろしくお願いします……おっと、次の打ち合わせに行かなくては。では!」

   席に戻った弁田氏は、迷ったときはやはり顧客と直接会話するのが一番早いということを実感した。そして、結佐氏がいろいろ指示してくるのはそれだけ真剣にこのプロジェクトの管理をしっかりやるという気持ちのあらわれであるように感じ、それに応えなければという思いを新たにしたのだった。

   報告資料を作り終え、最終電車で帰宅した弁田氏は、ゆっくり風呂に入りながらこんなことを考えていた。

   弁田氏「リアリティのある進捗報告を行おうとすると、課題や進捗に対して、プロジェクトマネージャー自身がプロジェクトの実態を正確に掴んでいなければならない。そして、それができていれば、こちらも素人じゃないし、上司や顧客にいわれなくても対策を打てるようになる。だとすると、リアリティの追求は、プロジェクトをうまく回していくための考え方として、実はものすごく基本的なことなのかも知れないな……」

   今回の内容をまとめると以下のようになる。
  • 進捗報告へのユーザの興味は、次のマイルストーンが無事達成できるか、に尽きる
  • 遅れるにせよ問題なしにせよ、進捗状況の詳細は成果物の完成数で表現すると現実と合う
  • 遅れに対して「がんばります」ではなく、どうがんばるかを線表に反映するべき
  • 問題への対処に追加費用がかかる場合には、費用をかけない案もあれば、ユーザは検討しやすい

表2:第4回のまとめ


最後に

   弁田氏と結佐氏の苦労話はここで一旦終わりになります。彼らの例に限らず、ユーザ企業と開発ベンダーの対立を解消するには、リアリティのある資料を基に、同じ認識の上で地に足のついた議論を進めていく、というやり方が非常に効果的です。

   資料にリアリティをだすための工夫は、プロジェクトの現状を客観的に掴み、それを決まった表記ルールで表現することからはじまります。

   このようないわば「見える化」の作業は、実はシステム開発、特に上流で行うモデリング手法に通じるところが多くあります。その意味では、ユーザ企業よりも開発ベンダーの側に、リアリティのあるプロジェクトを描くためのスキル的な土壌があります。また、立場的にも、開発ベンダーにはお客様と一体になってプロジェクトを運営していくことが求められます。

   ということで、これからも、結佐氏よりは弁田氏の方にいろいろ頭を絞ってもらうことが多いのかも知れません。

   今回の連載では、プロジェクトマネージャーの活動のごく一部しか取り上げることが出来ませんでしたが、リアリティのあるプロジェクト像を描くということがどういうものであるかは、多少なりともお伝えすることができたと思っています。機会があれば、その他のプロジェクト管理のシーンにおいても、リアリティのあるプロジェクト像の描き方をご紹介できればと思っています。

前のページ  1  2  3


ウルシステムズ株式会社 村上 歴
著者プロフィール
ウルシステムズ株式会社  村上 歴
シニアコンサルタント。8bit時代からのコアな技術屋であり今でもそのつもりだが、最近はパワーポイントの方が主な成果物になっている。「この矢印の意味は何ですか?」のように、文書を添削してくれるツールがつくれないか思案中。


INDEX
第4回:中身の濃い進捗報告会を作るには〜後編〜
  課題管理表・ToDo管理表だけではみえない進捗状況を共有する
  進捗状況や遅れへの対処は具体的に
どんな「進捗報告」が必要なのかは対話からみつかる