『プロジェクトマネジメント沼にハマろう!』〜顧客折衝編〜【最終更新 20191203】
「顧客折衝」は一種のスキルだ。営業職のノウハウに近いのかもしれない。
この5年強、私が参画させてもらったプロジェクトには、クライアントはもちろんのこと、その親会社やグループ組織、使用しているライブラリの開発ベンダー、フェーズを切り分けてアウトソーシングされているフリーランスや自分たちのチームにいる常駐パートナーまで、様々なレイヤーのステークホルダーが関わっていた。
中には、両目をつぶってもごまかしきれないくらい「失敗」といわざるを得なかった反省すべきプロジェクトもあったし、リリース後に美味しいビールを味わえるほどには「やったね!」と思えるプロジェクトも通ってきた。
(まぁ実際のところ100%「成功」なんて言えるプロジェクトはないのだけどね。リリースしてからが本当の戦い。)
何はともあれ、大規模なSIerもどきからWeb制作の受託、あるいは自社サービスも全て、決して一人で進められるわけではなく、周囲との調整や交渉、いわゆる「折衝」あってこその円滑なマネジメントであると思っているわけである。
ということで、今回はチームのマネジメントよりも前段にフォーカスして、“クライアントとのプロジェクトの進め方”について自分なりにやってきたことをまとめてみる。
※ここでいう「クライアント(顧客)」は技術者ではない想定のお話です。
※この記事は、Backlog Advent Calendar 2019 の 3日目としてお送りします。
※まいどるマガジン「プロジェクトマネジメント沼にハマろう」の1つとしても登録し、都度更新していきます。
顧客折衝ってなんなのか?
「顧客折衝(こきゃくせっしょう)」なんて言葉を初めて聞いたのは、SIer時代の請負プロジェクトでリーダーを任された時だったかと思う。
当時のPMはえらく仕事のできる人で、今でも尊敬の念は消えないわけだけど、私がクライアントワークをする上で「顧客折衝」にこだわるようになったのはこの人の教えから始まっていると言って間違いない。
「折衝」という言葉を辞書でそのまま引用すれば、
【折衝】
1. 《名・ス自》外交その他の交渉の、相手との談判・かけひき。
ということらしい。
私が感銘を受けたそれは見栄を張るとか嘘をつくとか、そういう話ではなくて、不要な情報を削ぎ落とし、そしてわかりやすく補足され、本来相手の知りたい情報を的確に伝える術の話だ。
伝え方が9割とはよく言ったもので、今までたくさんのPMを見てきたけど、この伝え方一つでクライアントの態度もこちらの手札も変わっていくのを感じるから面白い。
「談判・かけひき」などと聞くと、一見してよくないことに捉えがちだけれど、折衝はビジネスを進める上でお互いにとってメリットのあることであり、悪いことをしているわけではない。
関わる全ての人が気持ち良くプロジェクトに参加できて、ベストな形で完遂できたらそれが一番いいじゃない。
良い営業マンはファシリテートがうまい
はじめから結論を言うようだけれど、顧客折衝の良し悪しはファシリテートにかかってると思う。
売上成績の良い営業マンの共通点は、「相手に決めさせる(あるいは相手が決めたように思わせる)」ことができる人だ、なんて言われることがある。その空間づくりやペース配分を間違えると物は売れない。(私の新卒入社した楽器店調べw)
■ 距離感、テーブル配置への気遣い
俗に言う「パーソナルスペース」の心理を利用した手法。親密になりたい時は丸テーブルで斜め隣から話すのが良いとされるし、大きな決断を迫るときは角のあるテーブルで正面向かい合わせが良い、と言われたりする。
■ アイスブレイク
急に本題に入らない。基本的にはじめは自己開示。「私たちは敵同士ではない、味方同士である」ってことを回を重ねてじわじわと共有する。
■ 起承転結
課題感の共有→私たちがどうしようとしたか→しかし問題発生!→だからこうしたい、の提案という一連のストーリーを温度感と合わせて共有して自分ごとにしてもらう。
■ クロージング
最後のキメゼリフを相手から引き出す。「買います」「やります」「これでいきましょう」、最終決定を相手ボールとして証跡を残す。
打ち合わせなどで対面する場はもちろん、普段のメールやチャットでのやりとりにも意識して取り入れることで、最後には相手から気持ちよくGoを引き出す。こちらが誘導しすぎることなく、相手に決断させる。
余談だけれど、人は選択肢で尋ねられると「何かを選ぶ必要性」を感じてどれかしら「選ぶ」という決断をするので商談が進みやすい、ということはよくある。その選択肢を作るために、あえて捨て案を用意するというのは王道パターンかもしれない。
人は無意識に、自分の決断を正しかったと思いたい性分だ。だから、そういう状況を作り出せば、相手は自ら納得して私たちに委ねてくれる。(もちろん間違った方向で納得させるのはダメだけれど)
全体的に「とりまとめ力」なんて言われたりするスキルなんかな。
なんかこれ、洗脳ノウハウみたいでチョット危ない。笑
響く見積もり、響かない見積もり
内部的な工数見積もりと、顧客(非エンジニア)に見せる見積もりは違う。
技術的な仕事の成果にお金をお支払いいただく必要がある時、発注者側は何にお金を払いたいと思っているのか、をよく考えるようにしている。
顧客は本質的にUIの改善を望んでいるのに、一生懸命美しいログ設計やソースコードのリファクタに工数使ってお金をかけると伝えても相手がエンジニアじゃなければ、察してはくれない。もしそれが結果的にUI改善に繋がるとしても、だ。
「数字の見え方」には特に気を使う。全く同じトータル100万の作業をやるとして、実際には【設計】に90万、【デザイン】には10万の工数しかかかっていなかったとしても、顧客が【デザイン】に対して多くのお金を支払いたくて、それで決裁者が安心するならそう見える伝え方にすることもある。(これはちょっと極端すぎる例だけれど)
だから、裏で何にどれだけ時間を使っているのかは、知らせるタイミングを見誤らないようにする。「顧客が本当にほしかったもの」の分析次第で、アプローチが変わる。
ボールを誰に持たせるか?
プロジェクトを進めていると、双方への質問や確認、お伺いを立てなければいけないタイミングなどが発生する。
そういう時は、その課題のボールが誰マターなのかをクリアにすることで、常にプロジェクト全体の見通しをよくしておく。
これらは経験則からくる個人の見解だけど、なんとなく意識している切り分け。
*相手にボールを持たせない方が良いパターン
・言いなりになると設計や実装が複雑化しそうな機能
・複数パターンにおいて派閥ができそうな検討課題
要するに、話をややこしくしたくない時はなるべくこちらで課題のイニシアチブをとる。あまりに大きな検討課題は、相手を巻き込みつつも開発側である程度の道筋を示してあげたほうがハッピーに進められることのほうが多い。
*相手にボールを持たせた方が良いパターン
・後になって手戻りが発生しそうな仕様検討
・Bizサイドの意見や業務知識が必要になる課題
・実は少し進捗が遅れそうな課題
一方で、開発側でボールを持ちすぎるのもよくない。良い塩梅で課題をシェアすることで、全員が一緒にプロジェクトを進めている感を演出できるし、あるいは相手の回答待ちというステータスとすることで、開発完了までの時間稼ぎにもなるかもしれない。笑
上手に先回りして「ネゴる」力
ネゴる=ネゴシエーション、つまりこれも「折衝」と同じ意味で使われる言葉だ。「調整力」なんて言ったりもする。
ネゴる必要があるシチュエーションは多岐に渡るけれど、一番大切なのはタイミングだと思っている。
相手が知りたいと思ってからでは遅くて、知りたくなるであろう一歩手前でこちらから共有できるのがベスト。
「あ、それ今気になってたやつ!」というタイミングの良さと安心感の積み重ねが、信頼関係に繋がって来るから。
進捗・スケジュール報告、不具合報告、ちょっとした具体例を後で更新しようと思う・・・
先手を打った報告って、やりすぎるとちょっと言い訳みたいにも見えてしまうんだけれど、チーム全体に安心感(=心理的安全性)をもたらす上でもネゴり力は侮れないと思っている。
一番大事なのは、「参画者全員のプロジェクト」であること
色々と「対顧客」のあり方を書いてきたけれど、顧客と開発者とは決して敵対する関係であってはいけないと思ってる。
私たちは同じ目標に向かって進んでるチームであり、一緒になって課題を共有して解決していく仲間だ。
だからボールがどっちにあろうが不具合を指摘されようが提案が通らなかろうが関係ない。「顧客折衝」は誰かを責めるためにあるわけではない。
ビジネスである以上、お金のやりとりが発生するのは事実だし、そういう面で契約内容や金銭感覚はシビアになるべきだけれど、一度プロジェクトが走り出したのならそこに参画する全員が自覚をもってメンバーでいたいよね。
そして、宣伝
前回のnoteでは12/21(土)のTokyGirls.rb についてお知らせさせていただきましたが、12月はさらにもう1つ、PM関係で登壇します。
ここでは「こんなプロジェクトは嫌だ!〜アンチパターンから考えるPMの最適解〜」といったテーマでお話しできればと思っています。
と、いうことで今年もあと1ヶ月ちょっとですが、自分をグイグイ追い込んでいくスタイルで、ストイックに年を終えてまいりたいと思います!!