裏で伴走しながら、自ら考え自ら判断するPMへ成長を促す
――石田さんもプロダクトマネージャーとしてすぐに機能するのは難しかったと思います。「権威付けをしっかり」というのは必須として、プロダクトマネージャーの育成という面からはどのようなことを行ったのでしょうか。
山本：プロダクトマネージャーに関わらず、権限委譲は難しいんです。ただ放り投げてしまうだけなら誰でもできますが、任された方は困るでしょう。判断基準なども明らかなようでいて暗黙知であることも多いです。
オフィシャルにはすべての決定はプロダクトマネージャーが行うと宣言しても、裏側では権限を渡す側も1on1を定期的に行ったり、アドバイスをしたり、伴走して支援する必要があります。そして、プロダクトマネージャーもアドバイスをそのまま実行するのではなく、取り入れつつも最終判断は自分で行うことが重要です。そうしたやり取りが、結果的に育成につながったのだと思います。
さらに、社内にも石田が確認・決定するというステップを浸透させるために、「石田PMが判断する＝石P判断」という言葉を流行らせました（笑）。ちょっとした工夫というか、意識付けですね。
石田：私も「（山本）正喜さんが言っていたので」という言葉遣いは絶対にしないように心がけていました。たとえ、山本のアドバイスをまるっと受け入れたとしても、自分で考えた自分の判断として、自分の言葉で語るようにしていました。それは、新たにプロダクトマネージャーになった人へのアドバイスとしても伝えています。
ただ、最初の頃は、プロダクトマネージャーをプロダクトオーナーや事業責任者と捉える人もいれば、プロジェクトマネジメント的な進行役を期待する人もいて、人によってかなり理解が異なる印象がありました。
もちろんプロジェクトマネージャーとは異なる職能ではありますが、多少はプロダクトマネージャーの範囲を逸脱しても、信頼を勝ち取るためにできる限り応えようと努力しました。その一方で、自分の得意領域においてプロダクトマネージャーとしてのパフォーマンスを上げることも意識しました。私の場合はUXデザインだったので、ユーザーインタビューやユーザーストーリーマッピングなどを提案して実行することを通じて、「プロダクトマネージャーとの仕事はこんなふうに進めるんだ」と認知してもらい、信頼を獲得していったように思います。
――プロジェクトマネージャーとは役割が異なっていても、最初は求められるとそうした動きもなさっていたのですね。
石田：領域を限定せずにあえてなんでもやったのは、社内初の「1人だけプロダクトマネージャー」だったからです。かたくなに領域を決めていたら仕事が回らなくなっていたので。その中で信頼を得ながら、「実行領域についてのプロジェクトマネージャーは開発チームの方でやってほしい、理由は……」と対話を通じて、役割や仕事の整理をしていきました。
エンジニアとの軋轢を経験。専門職としてのPMを確立するために
――石田さんがプロダクトマネージャーになられたばかりの頃で、一番ご苦労されていた部分はどんなことですか。
山本：横から見ていて、かなり苦労しているように見えたのは、エンジニアとのコミュニケーションでしょうか。仕様を決めるための話し合いの中で、理論的な正しさを求める彼らの議論に巻き込まれ、いつの間にか概念の話にまで膨らんでいたのを見かけたことがあります。
エンジニアも、自分でサービスをつくるなどの経験があって意志を持っていることが多く、つい口をはさんでしまうんですよね。でも、エンジニアも他の職能の人からライブラリの選定やコードの書き方に口を出されたら不快でしょうと。仕様決定や顧客価値設定はプロダクトマネージャーの領域であり、意見は述べても否定はしない、信じて任せるということを徹底しようと伝えました。プロダクトマネージャーが専門的な職能であることをしっかりと浸透させるのは、結構時間がかかりましたね。
石田：エンジニアとのコミュニケーションもそうなんですが、とにかくいろんな人がいろんな要望や調整事項を相談してきます。すべてに応えていたら決定できないので、いろんな意見を受け入れつつも、自分なりの「解」を見つけ、その裏付けを示すことが大切だと感じました。それはプロダクトのビジョンに基づくものだったり、ユーザーの一次情報だったりさまざまです。
山本：特にエンジニアはユーザーの一次情報に触れていないことが多く、自分をユーザーとする主観からの意見になることもあります。なので、プロダクトマネージャーがしっかりとユーザーニーズや評価をおさえてエビデンスとすることは、議論上大きな説得材料になると思います。ただ、石田はUI/UX出身だったこともあり、わりとビジョンドリブン、顧客優先なところがあり、どうしても主観合戦に巻き込まれる傾向がありました。
実はこの「テクノロジーの理解」というのがエンジニア出身ならば自然と備わるのですが、そうでないとプロダクトマネージャーのスキルセットとしてはすごく難しいところなんです。例えば、仕様変更が大変な部分とか、どうすればエンジニアを説得できるのかとか。そういう部分を石田はエンジニアとコミュニケーションしながら体得した印象があります。
石田：エンジニアにどうやって動いてもらうか、本当に悩みました。最初の頃は、エンジニアにヒアリングしたままで山本に上げて「エンジニアの言うがままになるな」と怒られたことがあります。その後は、想定を持ってエンジニアにヒアリングに行き、「なぜできないのか」「なぜできるのか」と、複数のエンジニアと答え合わせをするうちに、コミュニケーションのコツをだんだん掴めるようになってきたように思います。プロレスしながら学んだという感じでしょうか。
山本：「できるか、できないか」といわれれば、エンジニアは職人なので「できる」と答えるんですよね。でも、障壁があると「できない」という。だから、その理由や、費用や時間などの制約について聞くなど、聞き方に工夫があるんです。でも、プロダクトマネージャーに必要な技術知識をどう学ぶか、そこはまだ体系化できていないのですが、石田の変化を見ていると、そこを一定クリアするとプロダクトマネージャーとして急成長できる気がします。
一方で、エンジニアの方でもアジャイル開発の優先順位付けの型として「インセプションデッキ」が登場したり、「ドメイン駆動設計」として事業価値を意識したり、テックもまた極めてくるとビジネス分野へ近づいてくるんですね。違う言葉で同じことを話すという。プロダクトマネージャーが技術知識を身につけていくだけでなく、プロダクトマネージャー以外がプロダクトマネージャーを理解するという、そういうアプローチも重要かもしれませんね。
石田：最近、その瞬間が増えてきました。エンジニア側からプロダクトマネージャーっぽい提案があったり、こちらから提案したものが「エンジニア目線が入ってていい」と言われたり。お互いの領域に足を踏み入れると、コミュニケーションとしての密度がぐっと上がる感じがします。
山本：それでもやはり50人中エンジニアが30人という規模でプロダクトマネージャーが1人というのは、正直言って無理な話だと思ってはいたので、プロダクトマネージャーを増やしていく必要があるのは明白でした。
――PM組織についての取り組みが始まっていくわけですね。では、引き続き後編でChatworkにおけるPM組織づくりの経緯や施策などについて伺っていきます。
