「PdMはエンジニアのやり方に口を出さないほうがいい」　成功の秘訣は“HOW”でなく“WHY”にエネルギーを向けること

Imgur社でプロダクトチームとエンジニアチームのリードを担当しているInayama氏

Ken Wakamatsu氏（以下、Wakamatsu）：本日は、日本CPO協会の初のオンラインイベント、「PRODUCT LEADERS 2021」に参加いただきありがとうございます。Inayamaさん、自己紹介をしてもらえますか？

Muts Inayama氏（以下、Inayama）：Inayama Mutsubuと申します。アメリカのバークレーに住んでいて、「Imgur」という会社にこの5年間勤めています。今は、プロダクトとエンジニアの両方を担当しています。

Wakamatsu：Mutsubuさんは、日本人の方だけどずっとアメリカに住んでいるんですか？

Inayama：小学校1年生の時からロサンゼルス育ちですね。

Wakamatsu：ちなみに今の会社で日本語を使うことはありますか？

Inayama：残念ながらないですね。完全に英語です。Imgurは、ローカライゼーションもぜんぜんしていなくて、サイトもアプリも全部英語だけなので、毎日英語です。

たまに、例えばおかしな漫画のスクリーンショットやミームが出てきたら、「これは、むっちゃんに聞いたらわかるんじゃない？」とか言われますが、それ以外は残念ながらほとんどないですね。

Wakamatsu：やはりシリコンバレーには、そんなに日本人はいないですよね。

Inayama：寂しいです。Imgurのトラフィックの6パーセントが日本なので、Imgurの将来のことを考えて、もっと日本に力を入れたいとも思っていますが、今のところは、国際的なことはあまりフォーカスしていません。

Wakamatsu：Imgurはたぶん、知る人ぞ知る会社名だと思うのですが、どういうことをやっている会社か説明してもらえますか？

Inayama：もともとは、画像をシェアするサイトで始まりました。ファウンダーのAlan Schaafが「Reddit」のユーザーですごくファンだったのですが、画像をシェアするのがとても難しかったので、彼が大学2年か3年の時にImgurを作って、それから伸びました。

今では、画像サイトというよりも、エンターテインメントサイトになってしまいましたね。英語では、エンターテインメントのデスティネーション（entertainment destination）と言います。

「今はエンジニア」「今はプロダクト」と頭を切り替えてアプローチしている

Wakamatsu：今、Mutsubuさんは、エンジニアリングとプロダクトの両方のロールを持っているわけですが、その役割分担について教えてもらえますか？

Inayama：例えば学校に行っていた時は、1時間目は算数・数学、2時間目は国語とか、考え方や話し方まで切り替えなければいけませんでしたが、今は、エンジニアの時は「自分はエンジニアだ」と自分に言い聞かせて、そういう考え方でアプローチしています。

一方、プロダクトの場合、プロダクトのミーティングや、そのプロダクトの問いを考える時は、切り替えて「エンジニアのように考えちゃ駄目だ」と自分に言い聞かせています。

日本語で北極星と言うのかな。プロダクトはシリコンバレーでは“ノース・スター”で、ビジョンなどハイレベルのことを考えなければならないし、一方、プロジェクトを実行する時には、エンジニアのように考えなければいけません。

Wakamatsu：そのノース・スターと、今日やらなければいけないこと、次のリリースまでにやらなければいけないことの両立というか、コラボレーションはどういうふうにやっているんですか？

Inayama：それはいい質問ですね。ハイレベルの考えや計画は、プロダクトのチームに任せなければいけなくて、フィーチャーのDevを作るのは、もちろんエンジニアです。

その間にちょうどオーバーラップみたいなものがあって、そこがちょっと微妙ですかね。（プロダクトのチームか、エンジニアか）どっちに任せたらいいのか（判断するのは）難しいかもしれませんが、できるだけインプリメンテーションはエンジニアに任せて、リクワイアメントはプロダクトのチームに任せるというやり方をしています。

前に立って指示はせず、できるだけ裏でアドバイスしている

Wakamatsu：Mutsubuさんには部下として、プロダクトマネージャーの人たちとエンジニアリングマネージャーの人たちがいると思いますが、その人たちと一緒に働いていくにあたって、ボスが1人の場合は、どうメンターしていくべきなんでしょうか？

Inayama：実はKenさんからのアドバイスで、プロダクトチームにはやはりプロダクトのリーダーが必要で、エンジニアのチームもリーダーが必要だから、1人の人から指示をするのは難しいんじゃないかと、僕も深く考えていました。

今は、プロダクトリーダーとエンジニアリングリーダーの両方がいないので、マネージャー同士で協力しています。僕はできるだけ裏でアドバイスして、あまり前で指示しないようにしているんです。

これはもしかしたら、日本人風のマネジメントスタイルかもしれません。表に出て「お前が間違っている」とか「プロダクト（チーム）が正しい」「エンジニアのほうが正しい」というのはあまり口を出さないようにして、マネージャーたちには「できるだけ自分たちで協力して、自分たちで解決しろ」と言っています。

Wakamatsu：Mutsubuさんのように両方できる人の強みは何でしょう？　

Inayama：プロダクトのほうは、いろいろな部門から出て、登って、成功できると思いますが、エンジニアはやはり技術的なところがあるから、まずそれがなければできないですよね。

それを基本としてプロダクトもやりたいという人がいる場合は、可能だと思いますが、エンジニアのバックグラウンドがなくて、そっち（プロダクト）に入っていくのは、ちょっと難しいかもしれませんね。

チーム全体のことを考えるのがマネージャーの役割

Wakamatsu：エンジニアリングマネージャーやプロダクトマネージャーで、コードを書きながらマネージしている人はいるんですか？

Inayama：エンジニアではいます。でも人数が増えていったら、できる時間はやはり少なくなってくるのではないでしょうか。もともとコーディングやものづくりが好きでエンジニアに入ったのであれば、それを手放すのは初めはすごくつらいと思います。今も若いマネージャーがいるのですが、それを手放すのをすごく嫌がっていますね。

Wakamatsu：そうですよね。

Inayama：でも、個人的な成功では足りないんですよ。チーム全体を成功させなければいけないので、自分1人でどうやって会社に利益を一番大きく与えられるかといったら、やはりマネージャーはチーム全体のことを考えなければいけないんですよね。

エンジニアリングには口を出さないほうがいいと思っている

Wakamatsu：Muts（Mutsubu氏のこと）はもともとエンジニアで、今はPMをやっていますが、PMはエンジニアリングのテクニカルな部分にどこまで入るべきだと思いますか？

Inayama：できるだけ入らないほうがいいんじゃないですか。クリアに、何が必要なのか、どういう問題を解きたいのかをベストにコミュニケーションする。そして先ほど話したように、なぜそのプロジェクトが大切なのか、なぜユーザーのためになるのか、そういうところにフォーカスする。

例えば、「なんでJavaScriptでやっているんだ。PHPでやったらもう2日前に終わっているぞ」とか、そういうインプリメンテーションのやり方には、本当に口を出さないほうがいいと思います。

なにかアイデアがあって、エンジニアにそれを相談したければ、許可を与えてもらえるように先に聞きます。「Can I have permission to speak？」と許可を求めて、許可が下りてから、「この新しいテクノロジーのことを先日聞いたのですが、これは使えますか？」と言ったりするのはいいと思います。

やり方にあまり口を出したら、本当にリレーションシップにひびが入ってしまうと思います。プロダクトのマネージャーが、「これが必要だ」と言って、エンジニアが「いや、そんなの意味がない」と言って勝手に決めて、別のものを作ったら、それも問題になりますよね。

プロダクトマネジメントを取り巻く環境の変化

Wakamatsu：確かにそうですね。とあるリサーチでは、日本の場合、プロダクトマネージャーの約7割が元エンジニアだという結果が出ています。

Inayama：7割？

Wakamatsu：7割。多いですよね。もともとエンジニアだった人が会社を立てて、プロダクトをリードしているのがたぶん多いんじゃないかなと思います。アメリカではどうですか？

Inayama：もう5年か10年前になると思いますが、ソフトウェアの会社では、コンピューターサイエンスを専攻した人たちでなければプロダクトマネージャーをさせてくれないという会社も多かったと思います。

今ではいろいろなバックグラウンドから来ているので、何割がエンジニアというのはちょっと言いにくいかもしれませんが、半数ぐらいでしょうかね。半数以下かな。

アメリカではプロダクトマネージャーのことをPMと言いますが、ほかにもデザイナーからPMになった方や、データが得意でアナリシスにすごく優れていてPMになった人もいます。

ほかにも最近、APM（アソシエイトプロダクトマネージャープログラム）のようなプログラムも出てきたし、ブートキャンプやProduct Schoolなど、大学とは別のシステムで学んで、PMになった人たちもいます。

プロダクトマネージャーは白紙に自分で問題と解決策を書いていかなければならない

Wakamatsu：いろいろなパスがあると思うのですが、エンジニア出身のプロダクトリーダーが失敗しそうなことや、気をつけたほうがいいことはありますか？

Inayama：第1の落とし穴は、たいていのエンジニアは「プロダクトは簡単だ」と思って入っていくことではないでしょうか。フィーチャーのリクワイアメントを書いて、ほかの人に作ってもらう気楽なポジションじゃないかと思うのが、まず間違いやすい落とし穴だと思います。確かに僕もそう思ったことがあります。

ほかにも、エンジニアの場合は、ほとんどソリューションのことを考えていますが、プロダクトマネジメントで成功するには、ソリューションより問いのほうにエネルギーを入れなければいけないと思います。

ユーザーリサーチやデータを見ながら、ほかのコンペティションはどういうふうにユーザーにメリットを与えているのかとか、ユーザーが今求めているものは何か、そして来年、2、3年先を考えた時にどういうものが必要になるのかとか、本当にプロブレムのスペースに住んでいなければいけないと思います。

エンジニアは常にソリューションが必要で、プロジェクトの中でデッドラインまでに作り上げなければいけないので、本当に考え方を切り替えなければいけないと思います。そこが難しいかもしれません。

Wakamatsu：多くのエンジニアが将来PMになりたいとか、PMに興味があるという話を聞きますが、実際にどういうところが大変なのか、なにか例はありますか？

Inayama：どういうところが難しいかというと、プロブレムのスペースの大きさがぜんぜん違うところです。例えば英語で、Multiple choice test、日本語では多肢選択式試験かな。A、B、Cを選ぶような試験で100点を毎回取っている人たちは、エンジニアでもたぶん成功できると思います。

だけど、そういう試験に慣れた人たちが、「俺はもうエンジニアが飽きた」とか「これで成功したから次のことをやりたい」と思ってプロダクトのほうに入ったら、急に「じゃあ、エッセイを書いてください」と言われるので、イチからやり直さなきゃいけません。

Wakamatsu：ルールがないというか、答えがないというか。

Inayama：そうそう。さらに悪いことに問題が書いていない（笑）。ただ、白紙。

Wakamatsu：自分で問題を書いていく（笑）。

Inayama：そうそう、自分で問題を書いて、自分でソリューションを考えて、その上に、自分がエッセイを書くのではなくてほかの人にやらせるというのが、さらに難しいですよね。

エンジニアの人たちは、プロダクトのほうが楽だと思うかもしれませんが、いや、けっこう難しいですよ。

Wakamatsu：Imgurでは、そういうストーリーポイントはエンジニアがつけて、PMはまったくつけない感じですか？

Inayama：そうですね。そこでまたPMが口を出したら、トラブルが起きます。

でもプロダクトマネージャーは、なぜこのフィーチャーのほうがこっちのフィーチャーより難しいのか、なぜこっちのほうがスプリントのポイントが多いのかを、別に聞いてもいいと思います。

エンジニアがそのフィーチャーのサイズにポイントをつけて、それをPMが見て、「じゃあ、この小さいフィーチャー2つより、この大きいの1つのほうがいい」とか、そういうトレードオフは、PMに任せなければいけないですよね。

Wakamatsu：開発経験は、PMにとってはやはり重要なことなのでしょうか？

Inayama：もちろん、自分で作った経験は絶対に活かせるスキルだと思います。ただ、なくてもPMとしてやっていくことはできると思います。