ネットプロテクションズでPMをやっている松本禎大です。
決済事業の特性上、運用や業法対応が複雑になりやすいため、PMはエンジニアだけでなく、法務やCS等専門ナレッジのあるメンバーとの議論が多くなります。
決済を担当するPMとして、普段心がけていることを言語化してみます。
1,既存の仕組みに対して敬意を払う
私が今担当してるatoneというサービスは2017年ローンチで、現在提供開始から5年ほど経っています。
新しい機能を作ることと並行して、元々あるものを改良･修正してより良いものを作っていく仕事も多く存在します。
やってはいけないのが課題設定の一環として、〇〇ってイケてないよねを強く強調してしまうことです。
元々あるものの課題を洗い出し、改善するので当然悪い部分は目につき、「なんでこんなイケてないもの作ったの?」と思っちゃうこともあります。
でも、作ったときはそれが最善だったかもしれないし、見えてない背景がある可能性もあります。
今あるものの否定は、前任者たちの頑張りの否定にも聞こえちゃうケースも多いと認識できると良いです。
また、自分が過去作ったものが改善される立場になる場合もあります。
昔自分が作ったものに対して、修正されたり意見されたりすると、むかつきますよね
自分の力作が否定されることを人格の否定のように認識してしまうことは、どんな人もアタリマエに起こる反応です。
↓お互いのリスペクトがかけた結果うまくいかなくなるの図
この場合作る人、作ってもらう人はこのような気持ちであるべきだと思っています。
まずは仕組みを作ってくれた先人に感謝を
今、より良いものを作ってくれる人には敬意と応援を
改善するPM
・今のサービスを如何に無駄があるか、イケてないかを強調するのはやめましょう
・ 今まで頑張ってくれた感謝の念を伝えつつ、屍を超えていきましょう
・そしていつか自分の作ったものが改善されたときには「より良くしてくれてありがとう」という準備をすること
改善されるプロダクトの製作者、PM
・力作の改善を感謝しよう
・そして過去は振り返らずに今の担当プロダクトに注力しましょう
2,自分で解決策を決めない、出さない
ざっくり一般化してしまいますが、同じPJTにアサインされた場合のPMと専門家の立場の違いについて、以下のように捉えています。
PM
・やりたいこと/最終的なゴールの解像度は高い
・どうやるか？どう実現するか？の解像度は低い
・何故やらなければいけないか、目的や背景は捉えられているはず
専門家
・最終的なゴールや経営･事業の解像度は高くない
・解決手法への知見や手段は豊富
避けなければいけないのは 「安易な発言で、専門家の思考に制約をかけること」 です。
人間はつい知っている言葉、過去に見知ったワードで話してしまいます。「○○みたいな〜」という例え話も該当します。
PMからすると分かりやすく伝えたつもりかもしれませんが、エンジニア目線では、「あ、○○はこのやり方だからそれに沿わなきゃ、、」などと思考を誘導してしまいます。
PMは選択肢を作るための前提情報、選ぶための判断基準と思想だけを伝えることを心がけ、解決手段についてはできるだけ言及しない、聞かれたら答える程度に留めると良いと思います。
あえて言わない、という選択肢もあるということを知っているといいかもしれません。
ただしどの情報を渡せば適切な選択肢と判断基準を作れるか？を知るために、専門的なナレッジを勉強することも必要です。
知らないことによるコミュニケーションエラーや情報選定のミスを防ぎ、共通の言語を使うことで信頼感の獲得に努めるのは案外重要な仕事の一つだと思います。
3,ドキュメントに落とした上で、コミュニケーションを取る
口頭で合意を取ると必ず「わかった気」を生みます。
例え口頭でMTGし、後からドキュメントに落としたとしても、「わかった気」を言語化しているだけで、
必ずドキュメント作成側の都合の良い解釈を含みます。
MTGを組むにしろSlackを送るにしろ、必ず先にドキュメントに落とし、事前に送付することができるとベストです。
ドキュメントに落とし、分からない部分･曖昧な部分を可視化していくとコミュニケーションにおける曖昧さを回避できると思っています。
ネットプロテクションズでは事前にドキュメントに落とした上で、MTG中でも文章によるコミュニケーションを必ず行うことで、認識の齟齬、曖昧さを回避するようにしています。
4,「可変条件か、前提条件か、今は前提条件だが変わりうる前提か？」を伝える
解決策の話と近いものですが、既に決まっているもの・まだこれから検討するものは分けて伝えます。
決まっていないものだけでなく、既に決まっている手段、やらなきゃいけないことは理由も含めて強調して伝えることも重要です。
あるあるなのが、PM側があいまいな状態で適当に伝えたものが、要件の一部として取り入れられててしまう。 エンジニアが所与の条件として考えて詰まってしまう。後ほどすり合わせたら別にいらない前提だった！差し戻し！ という現象です。
起きているのはこんな事態です。
PM：自分が話すことの確度を意識していない
エンジニア：どこまでが前提で、どこからが変えていいかの解釈を間違えた
PMがやるべきなのは、以下を3つを分けて話すことです。
- 既に要件として確定していて、変更がない部分
- 7-8割決まっているが、変更可能性がある部分
- 決まっていなくて、自由に決めてほしい部分
特に変更可能性がある部分については変更する際の発生条件と、変更した場合の選択肢も合わせて話せるとベストです。
5,定義が曖昧な言葉を作らない、使わない
曖昧な言葉を使って話している事柄は、実は自分も理解できていない部分です。
ざっくりした理解の場合、ざっくりした言葉やそれっぽいワードで話すため、話された側の解釈もバラバラになり、認識齟齬が生じます。
「自分曖昧な理解してるな〜〜」と早めに気づくことが大事です。
6,抽象度の高い定性目標や判断基準を伝える
大変ではありますが、抽象的な情報をきちんと渡しておいたほうが、PMとエンジニアの判断基準が揃えられます。
曖昧な部分が残っていたときに、判断基準が揃っていれば同じ意思決定ができる。
判断基準を揃えないor共通認識を取らないとすべての意思決定がPM→エンジニア間でやり取りが発生し、スピード感が落ちてしまいます。
結局上段から伝えたほうが、スピーディで質が高い結果になることも多いです。
具体的に渡す情報のチェックリストを作るならこんな感じです
- 前提として成し遂げたいこと、抽象的な達成条件
- 他に取れた選択肢と、判断の意思決定基準
- 絶対になってはならないこと(想定バッドケース)
最後に
PMは経営と顧客の情報を深く捉えて、チームでなすべきことを決める仕事だと思います。
キャッチアップする情報量も多く、ともすれば調整仕事になりがちです。
だからこそ自分のやりたいことを実現するために周りに敬意を払い、正しく伝えていくことが重要なのかなと思っています。