平和裏にすすめる技術
こんにちは、はじめまして。kamyuです。
自己紹介
- 「B2B2C」のプロダクトばかりやってきているエンジニア出身PdMです。
- 職歴：ワークスアプリケーションズ → リクルート → 現職
- CRM → EC → CRM/MA → 採用管理 → 飲食モバイルオーダー
- PdM歴は5年くらい。(※1)
- 現在は 株式会社Showcase-gig という飲食DX系ベンチャーでPdMをしています。
プロダクトマネージャー Advent Calender 2021 7日目の記事となります。
この記事のテーマ
「ゴタゴタを起こさずにぬるっと調整している」という評価をいただくことが多く、ここが自分の強みだと思っています。でも、そうなるために、いろいろ考えているんだよ…！
「綺麗事なめんなよ、ボク」
―「十二大戦」"平和裏に○す" 砂粒 西尾維新著
というわけで今回は「プロダクトマネジメントを円滑に進めるためのコミュニケーション術」について書いてみようと思います。
ハレーションが起こりやすいタイミング
「PdMはWhy/What、エンジニア/デザイナーがHowだ」という言い方はよくされます。Why/Whatを考えるためのフレームワークが、ここ最近で確立されてきました。
いろいろな情報収集をして、考えて、誰かに当ててみて、議論して… と繰り返し、吐き気がするくらい考えた結果が「PRD」のような形の成果物としてまとまっていきます。
できたPRDを意気揚々とデザイナー/エンジニアに伝えるのですが…
この、「伝える」タイミングで、ハレーションが起こりやすいなと感じています。(※2)
原因:"モチベーションのズレ"と"具体化のズレ"
(1) モチベーションが違う問題
プロダクトマネジメントを勉強していると「PRDを渡したら、あとはエンジニア/デザイナーの責任領域」とするのが、分担として良さそうに思えます。
が、彼らは必ずしもプロダクトマネジメントの勉強をしているわけではないです(※3)。
また、伝えたとしても「この分担でやっていきたい！」と考える人は半分程度で、もう半分は職人気質な人となります。
職人気質な人とは
- 体験も大事だけど、ユニバーサルデザインや1pixelにこだわりたい
- "要件"に対して、良い設計をして良いパターンを使って新しい技術で解決したい
「How」の中にも幅があって、職人気質な人は「狭くて深いHow」にモチベーションを持っています。→「要求だけ渡されても困る、要件まで決めてもらいたい」となるわけです。
また、ジュニアメンバーだと「そんな上流まではまだ責任持てない…経験もないし…」という感情もあるかもしれません。
「どこからがhowなのか？ (広いhow/深いhow)」についての認識のズレ、それに伴うモチベーションのズレが、１つ目の問題です。
(2) 伝えきれていない問題
時間をかければかけるほど、成果物は短く洗練されたものになります。
「もっと時間があれば、もっと短い手紙を書いていただろう。」
― マーク・トウェイン
「考えが洗練されていれば、話す言葉は短くなるでしょ」
― Yuta Kanehara (※4)
あなたが作ったPRDも、エンジニア/デザイナーに渡る頃には、かなりまとまったきれいなものになっていることでしょう。洗練されるほどに、堂々と上手に説明ができるようになっていきます。
私も、洗練された短い文章にまとめたいなあと思うのですが…
"受け取った"側は、そこから自分なりに解釈をすることになります。
言葉の解釈というのはかなりブレやすいので、「そう来ちゃったか…これはちょっと許容できない、どう説明しよう」と悩んだ記憶がたくさんあります。また、許容できないものは氷山の一角で、「う… 書ききれてなかったな… まぁこれは我慢できるか…」というものは死ぬほど出てきます。
「言語化は難しいし、抽象化も難しい。そしてそれを正しく具体化するのも難しい」ということ。翻訳を2回かけているような感覚です。
とはいえ、これまでの流れをすべて記載した巻物のようなものを作っても、読んでもらえないでしょう。このような、通信不確実性から生じる具体化のズレが、2つ目の問題です。
解決法
これらのモチベーションのズレや具体化のズレが起こると、その解決にはかなりの痛みを伴うことになります。相手は「これが良い」と思っていて、それを否定することになるのですから…！
さらに、否定するときの根拠が「他のどこかにある正義/正論」になりがちなことにも注意です。
正論は正しい、だが正論を武器にするのは正しくない。お前が使っているのは、いったいどっちだ
- 「図書館戦争」
人は、正義が自分にあると思ったときに最も凶暴になる
- 誰か
正論をぶつけて相手を否定する＝「錯覚資産」を落とす＝チームの心理的安全を脅かすようなことは、「終わりのないマネジメント」であるプロダクトマネジメントに向いていません。
「もう○○会議で決まったので」のような言い回しは絶対ダメ
「ビジョンがこれだから」「ユーザーストーリー上…」のような"プロダクトマネジメント論"を武器にするのも危険。PdMの成果物は抽象度が高い場合が多いので、「俺の解釈が正義だから」みたいに聞こえます。
解決するには、丁寧に説明をしていくことになります。メンバーがどんなモチベーションを持っているか理解し、正義ではなく「自分の思い」に変換しつつ、相手のナラティブに寄り添って…。
pmconf2021でマクドナルドの飯沼さんが発表していた「Noを伝える技術」はお気に入りです。表現方法って本当に大事だと思います。
予防法
一度起こってしまうと解決コストが大きいので、「できるだけハレーションを起こさない」予防をすることが、平和裏なプロダクトマネジメントには必要かなと思っています。
(1) 個々のモチベーションを把握しておく
同じ会社にいる、同じプロジェクトをすすめる仲間なのですから、向かっている方向は同じはず、同じにできるはず。そのためには、相手が何にモチベーションを持っているのか、把握しておくことが重要です。
(2) 下手なワイヤーをつくる
通信不確実性の問題を解決するために、現時点で落とし所としてよさそうなのは「下手なワイヤーをつくる」ことです。PRDだけでなく、PdM側で「実現イメージ」を作って渡すことでかなり改善できます。
ただ、これは諸刃の剣でもあって… これをそのまま「要件」だと思われてしまわないように細心の注意が必要となります。
"オレならもっと良いものが作れる"と思わせられるようなものが良い
手書き風テンプレートを使うと、否が応でも考え直さなければならないのでおすすめ
案はできるかぎり複数持っていく。突飛な案も持っていっておくと、思考の幅が広がる。
(3) 信頼残高をためる
気をつけていても、ハレーションが起きてしまうことはあります。
そんなときにそなえて、普段から信頼残高を貯めておきましょう。
よく出会う「信頼残高を減らさないための注意ポイント」を挙げてみます。
80点vs81点で戦わない
エンジニアやデザイナーが決めきれないときに、「どっちがいい？」と質問されたんだが、正直PdMとしてはどっちでもいい…というシーンは多いです。
いつでも妥協せよというわけではないですが、ここでチャンスだと思って丁寧なコミュニケーションを心がけましょう
Agreeをつくっていく
おかしなことを言っている人がいても、「それはおかしいです」と論破するのではなく、「やりたいことは〜でしょうか？」「はい」「それならこっちのほうがいいかもしれませんね」などと「同意する/させる」を挟んでいくと良いです
(4) 情報伝達を過信しない
慣れてくると「あの人ならこの程度で伝わるだろう」という予想が当たるようになってきます。が、違ったときのno,notの説明コストは、これまでの信頼があるぶん余計に高い、ということを覚えておきましょう
「ビジョン/NSMを定めたんだから、みんなそこを向いているはず！」「○○MTGで伝えたので大丈夫なはず！」という感覚にも注意しましょう。「責任問題」になったら勝てるかもしれませんが、良いプロダクトからは遠ざかってしまいます。
まとめ
PdM → デザイナー/エンジニア のフェーズでハレーションは起こりやすい
原因は「モチベーションのズレ」「具体化のズレ」である
問題が起こってから解決するのはかなり骨が折れる
予防に努めましょう
方法論が確立しても、常に理想通りにはいかないと思います。
が、チームで一丸となって、くだらなくて楽しい冒険をしていきましょう。
最後に
12月はAdventCalendarのおかげで読み物が増えて楽しいですね。
私は初めて参加したのですが、最近教えてもらった下記の名言が1日100回くらい刺さっています。
頭の中にあるうちは、いつだって、何だって、傑作なんだよな
―「何者」 朝井リョウ著
みなさんの頭の中の傑作をたくさん聞いてみたいなと思ったので、Meetyはじめてみました！よかったら雑談しに来てください！
おわり。
（※1）「プロダクトマネージャー」という言葉が日本に浸透していない頃から似たような仕事をしていたので、よくわからなくなってきました。前職までは「コンサルタント」とか「ITプランナー」という肩書で働いていました。
(※2) 理想的にはデザイナー/エンジニアもずっとPdMに並走すべきですが…、実際、完璧に並走するのは難しいでしょう。PdMが考えるフェーズで、エンジニアは実装を進めているでしょうから…
(※3) むしろ、大抵の人はしていないはず。プログラミング手法、設計手法、デザイン手法などの勉強を優先しますからね
(※4) 弊社のエースPdMです。若くて超優秀。12/12にAdventCalendar記事を書いてくれるそうなので楽しみ！