やっぱこれかなって思う。
よくあるパターンなのですが、｢顧客側の意思決定者」⇔「顧客側の担当者」⇔「私たち」という構図。直接の対面する相手は担当者の方で、実際にプロジェクトの意思決定をされる方は後ろにいらっしゃるというパターン。逆にこういうのが多分一番多くていきなり最終的な意思決定者と直接コンタクトが取れる、意見を述べることが出来る、というのは少ないと思います。
こういう時に最も起こりやすい葛藤は「顧客の担当者がYESなんだけど、顧客の意思決定者がNoで巻き戻る」というもの。これを経験したことが無い人はいないと思うのです。また「自分のチームリーダーがYESなんだけど、他会社のPMがNoでしわ寄せが来る」なんていうケースも基本的なケースです。結構ウェットです。立場が違う複数の人間が交じり合った中で共通なYESを作ることが、どれほど難しいことか。
こういう状況には一貫した類似点があって、「問題」というボールを投げ合っているということです。私たちと私たちの上司のあいだ。私たちと顧客の担当者のあいだ。顧客の意思決定者と担当者のあいだ。顧客の意思決定者と私たちのあいだ。この中でボールを投げ合っているうちに、ボールのサイズが大きくなったり分裂したりしてどんどん肥大化していきます。問題の投げ合いが利害関係を硬直化させてしまい、お金ばかりが浪費されて、引くにも引けない状態にお互いが追い込まれる。こんなバカなことはない。
そういう時に僕のような立場の人間がやらなければならないのは、「問題 vs わたしたち」の構図を作ることです。
顧客も私たちも、本来やりたいことは問題解決です。問題というボールを投げあうことではありません。問題とは現実と理想のギャップであり、顧客は現実と理想の間にギャップを感じているから、私たちに発注頂いているのです。問題解決本は腐るほど売っていますが、そもそも「問題」というのは何かという問題発見能力が重要であり、それをテーブルに並べさえすればそこから時が動き出します。問題を解決することは難しくはありません。何が問題なのかを発見するのがずっと難しいのです。
これはスーツもギークも関係なく重要なことだと思いますが、多くの場合はステークホルダーと直接対面しているスーツな人のお仕事であることが多いです。この構図を作るために一番大事なのは、「わたしたち」というステークホルダーを見誤らないこと、そして彼らから逃げないことです。彼らを巻き込んで１つのテーブルの上で議論しなければこういった構図は作れません。自分たちでは作れないのなら、もっと上にエスカレーションするのもいいでしょう。意思決定権限のある方に、直接思いを伝えるのも良いでしょう。言葉に出さなければ、何にも前に進まないのです。
僕はこの構図を作ることが何よりも好きです。
コードを書くことだけでは味わえない達成感がそこにありますよ。
