寒い日が続きましたが、今日は穏やかな日よりとなりそうな予報です。関西でこの時期になるとやはり阪神淡路の震災に思いを馳せることになります。
23年前の17日の午前5時47分発生した地震でご存知の大きな被害が出たのですが、あの日のことは今でも忘れられません。幸いキットPMの周辺では、揺れは大きかったものの大した被害は出ませんでしたが、その頃努めていた会社の同僚には被災した人も多数いました。
たまたまこの日、１．１７はキットＰＭの誕生日なのですが、23年前からは鎮魂の日となり、あの日のことを想い、死ぬことと生きることについて考える日となりました。
プロジェクトでＰＭが直面する「合意形成」の在り方について考えています。前回はユーザーのＩＴ部門と開発ベンダーののＰＭ間の合意形成と、それがもたらすことになるユーザー部門との良好な合意形成について考えました。
今回はＰＭと一緒にプロジェクトを切り盛りする、プロジェクトメンバーとの合意形成について考えることにします。
プロジェクトメンバーとは、プロジェクトの全ての面でＰＭとの合意が必要となります。またメンバーは例えＰＭの言うことに納得できなくとも、少なくとも合意を前提とした行動を取る必要があります。
メンバーがＰＭの方針について、自己のポリシーや論理性に反して従うのが難しい場合は自分の想いを率直にＰＭに伝え、納得がいくまで議論することが必要です。まぁ、これがなかなか簡単ではないことはキットＰＭも承知しているのですが。
言いたいのは、ＰＭとメンバーの間に明確に意識できない意識の齟齬があることは避けなければならないと言うことです。もう少し嚙み砕くと、メンバーが納得できなくともＰＭとの考えの違いを認識して、ＰＭに従って仕事をする限りそれは大きな問題にならないと言うことです。
逆に言うと、認識の違いを意識せず、双方が同じ方向を向いて仕事をしていると信じていたとき、実は双方に認識の齟齬がある場合、プロジェクトに計り知れない良くない影響をもたらす可能性があると言うことです。
これを防ぐ方法は、ＰＭとメンバーの効果的で密接なコミュニケーションに尽きます。これも「言うは易し、行うは難し」なのですが、ここを乗り切るのはＰＭの責務とスキルとなります。
ＰＭはプロジェクトが始まる前に、プロジェクトメンバー候補と面談を行います。その面談では”プロジェクト憲章”を示し、プロジェクトの目的とその達成のための方針や前提条件、リスクなどプロジェクトの概要を説明します。
この段階でプロジェクトの内容や実施方針について意見を交わし、納得できるかが一つのハードルとなります。普通はここで問題になることはまずありません。問題になるのはこの後です。
プロジェクトにおけるメンバーの役割について、個別にＰＭから説明することになります。
通常この”役割”についての提示には多くの意味を持つことになります。主な意味としてあるのは、一つは”期待”でありもう一つは”教育”です。
プロジェクトを遂行する上で、どのような役割と成果を期待するのか。またメンバーの経験と力量を勘案して、メンバーへの期待値をどこに設定するのかをＰＭは考え、それをメンバーに伝えるます。
この時メンバーへの少し過剰かもしれない期待を、メンバーが受け入れるのかどうかが大きな問題になる場合があります。ＰＭは特定のメンバーのサポート体制やセーフティを提案することで、メンバーのモチベーションを高め、不安を取り除くことが必要となります。
さて、これで上手くプロジェクトチームを立ち上げることができるのでしょうか。次回もこのテーマを続けることにします。