プロジェクト・マネジャーが知るべき97のこと/「メッセンジャー」にならない
プロジェクト・マネジャーの一番重要な役割のひとつは、いろいろなチームメンバーが遠慮なく話し合えるようファシリテートすることです。残念ながら、私はこれとは逆のことが起こっているプロジェクトをいくつも経験してきました。プロジェクト・マネジャーがコミュニケーションの流れのボトルネックになっていたのです。そうしたプロジェクト・マネジャーは「メッセンジャー」です。チームメンバーからチームメンバーへと、重要な情報をそのまま伝えるだけの配達人です。
プロジェクトが進行するにつれて組織的に動けるようになるためには、最終的なミッション実現に向けて、情報を水や空気のようにプログラムコードへと提供できるよう成長しなくてはなりません。チームメンバーは絶えず情報交換しなくてはなりません。ところが、ステークホルダーがすべての情報をプロジェクト・マネジャー経由でしか伝えられないとすると、これは決して乗り越えることのできない問題になります。
プロジェクト・マネジャーは最新の情報を託されても、その情報を受け取るべき開発者全員を正しく理解していないかもしれません。メッセージの送り手はプロジェクト・マネジャーに伝えたことで、自分の義務を果たせたと思っています。あとになってコミュニケーション漏れが見つかっても、メッセージの送り手はすでに新しい課題に取り組んでいて、以前伝えたことを正確には思い出せないかもしれません。プロジェクト・マネジャーが自分では理解できない技術的報告に圧倒されているようだと、プロジェクトにおける情報伝達の司令塔としてはすぐに機能しなくなるでしょう。
メッセンジャーというよりも、むしろ有害な役割を果たすプロジェクト・マネジャーもいます。そういう悪意はないけれども無知なプロジェクト・マネジャーは「スクランブラー」です。プロジェクトが進むにつれ、プロジェクトを円滑に進めるために必要な非技術的な情報量も増えていきます。開発者はビジネスルールについて知る必要があり、ビジネス推進者は成果物の状態について知る必要があります。他の人たちもスケジュール、コスト、品質基準について、プロジェクトが今どんな状態にあるのか理解する必要があります。
情報量が増えるにつれて、プロジェクト・マネジャーも全知全能ではないため、間違って伝える可能性が増えてきます。こうしてプロジェクト・マネジャーはスクランブラーになります。例えば、一見するとプロジェクトにほとんど影響を及ぼさないように見えるビジネスルールでも、その真意がわかると実際には大きな障害になるものもあります。そして、そのダメージを修復するためには、コードベースにかなり大きな変更が必要になる場合もあるのです。
プロジェクト・マネジャーは、適切なときに、適切な話題について話すために、適切なステークホルダーを集める必要があります。このために他部門の人たちの都合のよい時間を見つけるのは大変だと思うかもしれません。実際のところ、あなたはどうしていますか？
プロジェクト・マネジャーは次のように言って、スケジューリング問題を解決しようとします。「シェリー、この件のことだけど、これからボブのところに行って回答をもらってくるよ」
ちょっとした非技術的な質問であれば、これでもうまくいくでしょう。しかし、こうした小さな成功は、気づかぬうちにあなたをメッセンジャーやスクランブラーに変えていくことに注意してください。通訳すると必ず何かが失われます。そして、その影響を収拾しようとすると、必要以上にムダな時間がかかるのです。
クリアでオープンなコミュニケーションのためのチャンネルを提供し、そこでなされた議論と判断を記録に残すことによって、チームメンバー全員が直接交流を深めることができます。これはプロジェクト・マネジャーがメッセンジャーやスクランブラーになるのを防ぎ、ソフトウェアプロジェクトを前進させる力となります。
この作品はクリエイティブ・コモンズ 表示 3.0 アメリカ合衆国ライセンスのもとに利用を許諾されています。
あなたは以下の条件に従う場合に限り、自由に
- 共有 – 本作品を複製、頒布、展示、実演できます。
- 再構成 – 二次的著作物を作成できます。
あなたの従うべき条件は以下の通りです。
- 表示 – あなたは適切なクレジットを表示し、ライセンスへのリンクを提供し、変更があったらその旨を示さなければなりません。これらは合理的であればどのような方法で行っても構いませんが、許諾者があなたやあなたの利用行為を支持していると示唆するような方法は除きます。
