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