■プロジェクトにも絶対ある対立関係

　プロジェクトにおいても、このような関係者間の意識のギャップは起こることが多い。いや、表面化はしていないが、確実に起こっています。システム開発を例にとると、ベンダやSIerはシステム導入やシステム開発をしたくてたまらない、ユーザーはできることなら、慣れ親しんだシステムを替えてほしくない、システム部はお題目のように「コスト削減」を唱えている。

　そして、システム開発が始まると、ユーザーは使いやすいUI（User Interface）を求め、ベンダは最初に決まった仕様を変更したくない。システム部は、仕様はどっちでもいいが、コストをもっと削減させて自分の手柄にしたい。ついでにIT専門誌の記者は、システムトラブルが起こるとウハウハです。

　本当に、各社・各者の想いが入り乱れ、会議は踊るだけではなくブレイクダンス。コンサルタントは、関係者間の「Win-Win」を目指しましょうと語ってくれるが、そうそう「Win-Win」などにはなるものではない。中途半端な妥協は、お互いストレスがたまっていくだけです。勝つか負けるか、のバトルが繰り広げられているのです。

■PMBOKの「ステークホルダー特定」というプロセス

　プロジェクトマネジメントのグローバルスタンダードであるPMBOKには、「ステークホルダー特定（Identify Stakeholders）」というプロセスがあります。このプロセスの中で、ステークホルダー分析などを行い、ステークホルダー分析マトリクスなどを作成する（らしい）。また、「ステークホルダーの期待のマネジメント（Management of stakeholder expectations ）」というプロセスで、ステークホルダーのニーズに応えるために、話合いや対処を行うとあります。

　蛇足ですが、ステークホルダー（stakeholder）とは、関係者のことです。「プロジェクトのメンバー自体もステークホルダーに含まれるんですよ！」とPMBOKファンダメンタリストは力説しますが、そんなことはどうでもいいこと。

　このステークホルダー分析というプロセス、そしてステークホルダー分析マトリクスは役に立つのでしょうか？ いいえ、結局、形だけです。

　こんな表を作って、書かれた対策をやったところで、意味がないです。そんなことでステークホルダーをコントロールできるのであれば、苦労はしない。どこにでもモンスターペアレンツやモンスターステークホルダーは、いるのです。「こんなプロジェクト、俺の趣味じゃない」の一言で、プロジェクトをズタズタにするシステム部部長や、なかなか検収印を押してくれない購買担当者、「仕様ですから」を毎回繰り返すベンダのエンジニアや営業、彼らをどうコントロールすればいいのだ？ ステークホルダー分析をやれば、何とかなるのか？ 説得術や交渉術を磨けばいいのか？ それとも金か？ 金なのか？ 運次第か？ ステークホルダーの応援している球団が勝たないと駄目なのか？ もしかして、AKBのチケットが必要なのか？

　ステークホルダーの意見は絶対に一致することはなく、立ち位置や状況によって、その意見はくるくる変わる。関係者で集まって多数決で決めるのも民主的だが、声の大きいステークホルダーを無視すると後が怖い。自分の正義を貫いて、自分の所属する会社の利益に反することも問題だ。かといって、上司の言ったとおりに伝言しても相手はOKと言ってくれない。いったいどうすればいいのか？

■PMが神になれば解決する、のか？

　あるPMは語ります。

　「プロジェクトマネジメントっていっても、最後は品格や徳だよね」

　なんだ、それ？ プロジェクトマネジメントって工学じゃなかったのか？ まるで宗教じゃないか？ しかし、ある意味納得。講演などで有名なPMのいうことをホイホイきく観衆（という顧客）。プロジェクトの現場で、PMのいうことは絶対服従。顧客はひざまずき、メンバーはPMが語るとおりに作業をすすめ、「カラスが白い」と言われれば、「もしかしたら自分の目がおかしいのではないか」と考える。

　そして、もし、もし、プロジェクトが失敗した場合、それはPM以外のステークホルダーが悪いことになる！

　そう、PMにステークホルダーを説得・感化・いいくるめるパワーがあれば、プロジェクトはなんとかなります。カリスマ性を持たしてもよい。有名コンサル出身というブランド属性も有効だ。関係者を煙にまくために、英語で語るのもポイントが高い。しかし、そんなプロジェクトには、絶対参加したくない。PM神に仕えるくらいなら、自分が神になってやる。

　そして、さまざまな宗教が生まれたのです。

　それでは、また別のお話で。