普段の生活の中で、複数の選択肢があり、かつ優劣付けがたい状況下において、いずれか一つを選択しなければならない場合、みなさんはどうやって決めるだろうか。これは、システム開発プロジェクトにおいてもしばしば見られる問題である。PMはプロジェクトの責任者である以上、何らかの選択をしなければならない。PMがどれを選択するかによって、その後のプロジェクト運営を大きく左右することになる。
複数の選択肢に対して、どれにするのか決められないということは、それぞれの価値が等価であるということだ。各選択肢を個別に見ると、どれもそれなりの価値と理由があるように見えてしまう。その結果、自分では決めることができず、「誰かに決めてほしい」と願いたくなる。
このような場合、PMに哲学があるかどうかで大きく異なる。自分の哲学に従って行動するPMは迷いが無く、どのような局面であっても自信を持ってプロジェクトの進むべき方向を示す。このようなPMは、結果としてうまくいかなかったとしても、その理由を人のせいにすること無く自身の成長へと結びつける。
哲学無きKさんの失敗
Kさんは以前から人当たりの良さが評価されていた。Kさんが担当することになったプロジェクトは、複数のユーザー部門が利用する営業系システム開発であり、ステークホルダーが多いことから仕様調整が難航すると思われていた。そこで、誰もが「どのような意見に対してもいつも物腰柔らかく接するＫさんはうってつけのPMだ」と思っていた。
周囲の予想通り、プロジェクトは順調な滑り出しを見せた。Kさんは全てのステークホルダーに対して人当たり良く、特に顧客との間で良好な関係を築いていた。ただ全く問題が無いかというと、そうではなかった。Ｋさんは人当たりこそ良いが、次のような言動が目立っていたのだ。
例えば設計フェーズで次のようなやりとりがあった。
SEのLさん「A案とB案の両方の案があります。どちらにしたら良いでしょうか」
Kさん「う～ん、どちらか片方と言われると厳しいな」
Lさん「時間的な制約もありますので両方は無理です」
Kさん「じゃぁ、A案にしよう。A案は先月号の○○という専門誌に紹介されていたし」
「B案は以前△△というWebであまり良くないと紹介されてたからね」
「だから、A案のほうがB案より良いと思うな」
また実装フェーズでは
SEのMさん「このタイミングで仕様変更を許すのですか？」
Kさん「お客さんがどうしてもと言っているから」
Mさん「ですが、この前の仕様変更要求は絶対に許さないとおっしゃってましたが」
Kさん「あのときは担当するメンバーがどうしても駄目だと言ってたからね」
「今回は、担当メンバーが何とかできそうだと言ってるから」
このように、自分の考えを前に出すのではなく、終始誰かの考えを立ててプロジェクトの方向性を決めていたのである。Ｋさんとしては、自分の考えを出すよりは書籍や担当者・顧客といった第三者の意見を尊重することで、プロジェクトにおける人間関係を円滑に進めるつもりだったのかもしれない。「意見の無いものとは意見の対立が無い」と言われる通り、自分の意見を押し殺した形であった。
これでプロジェクト自体がうまくいったのであれば問題にならなかっただろう。しかし、今回はそうは行かなかった。A案の選択は結果的に間違っていた。さらに、前述の仕様変更がスケジュールに影響してしまい、大きな遅延の原因となってしまったのだった。
PM初心者が起こしがちな良くあるミスといえばそれまでである。確かにミスのせいでプロジェクトは遅延してしまった。しかし、人間である以上ミスを犯すことは避けられない。ミスはミスとして認めた上で反省し、次の機会へ生かすのがPMである。
今回の件で、当然のことながらＫさんは顧客からPMとしての責任を問われた。しかしKさんは自分の責任について納得できていなかった。顧客にこそ反論しなかったが、社内の反省会では猛烈に反論したのだった。
「確かに全ての事柄の決定責任は自分にある。それは認める」
「しかし、当時の状況では最善策だったと思っている」
「自分は得られた情報を基に、最も適切と思われる解を選択したにすぎない」
「PMとしては当然の選択だった」
これに対して、「なぜそれが最適解であると思うのか」と聞かれるや、胸を張って主張した。
「多くの専門誌で紹介されていたり、社内の有識者がそう言ったりしているからだ」
これにはさすがに誰しもが絶句した。Kさんがこれまで社内で築き上げてきた「PMとしての信頼感」が一気に崩れ去っていく瞬間だった。そして、それ以降Ｋさんには大型プロジェクトや重要なプロジェクトのPMは回ってこなくなってしまったのである。
