CLOSE

エンジニアリングとプロダクトの役割と連携(全1記事)

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

​⽇本と世界のプロダクト開発をつなぎ、⽇本のソフトウェアプロダクトをグローバルで通じる⽔準へ引き上げることを⽬指し、設立された「日本CPO協会」。今回のゲストは、Imgur社のMuts Inayama氏(Inayama Mutsubu氏)。プロダクトチームとエンジニアチームのリードを担当している同氏が、それぞれの目的を持った組織間ですれ違いを起こさないためのコミュニケーションについて話しました。

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としてやっていくことはできると思います。

長い間エンジニアと一緒に協力しながら働いていたら、どういう答えが出てくるかとか、だいたいわかってくると思います。

プロダクトに対する問いのスペースが無限に広がった

Wakamatsu:Mutsはもともとエンジニアリングのマネージャーで、今はプロダクトの両方を持っていますが、それによって自分の中で仕事が楽しくなった部分はありますか?

Inayama:やはり問いのスペースが本当に無限に広がったのが、自分自身にとってエキサイティングです。

それから、エンジニアと話している時は本当にはっきり言わなければやってくれなかったり、「また説明しなさい」とか「言っていることがわからない」とか、本当に正直なフィードバックが来るので、そこにすごく気を使います。

でも、プロダクトのチームと話していると、はっきりと言わなくても、「ああ、わかってくれたんだ」と、すぐわかってくれるところがすごく楽しくて、楽ですね。

自分でも、「説明の仕方が下手だったな」と反省しながらも、「相手は言っていることをわかってくれたんだ」というのが本当にうれしいです。

Wakamatsu:それはうれしいですね。

Inayama:なんと言うのかな。キョッカン?

Wakamatsu:直感?

Inayama:シックス・センス。直感? 優れているPMは直感が鋭いですよね。

Wakamatsu:最後の質問になりますが、今、日本ではソフトウェアがすごく盛り上がってきていると思いますが、シリコンバレーから見た時に、日本の業界やエンジニアやプロダクトに、なにかメッセージはありますか?

Inayama:日本で開発されたソフトをアメリカではまだあまり見ないのですが、これからが楽しみだと思います。これからもいろいろな新しいプロダクトを開発してもらって、アメリカのマーケットでもぜひ見たいと思っています。

Wakamatsu:ありがとうございます。Inayamaさん、本日はお時間ありがとうございました。

Inayama:ありがとうございました。

続きを読むには会員登録
(無料)が必要です。

会員登録していただくと、すべての記事が制限なく閲覧でき、
著者フォローや記事の保存機能など、便利な機能がご利用いただけます。

無料会員登録

会員の方はこちら

この記事のスピーカー

同じログの記事

コミュニティ情報

Brand Topics

Brand Topics

  • 今までとこれからで、エンジニアに求められる「スキル」の違い AI時代のエンジニアの未来と生存戦略のカギとは

人気の記事

新着イベント

ログミーBusinessに
記事掲載しませんか?

イベント・インタビュー・対談 etc.

“編集しない編集”で、
スピーカーの「意図をそのまま」お届け!