2024.10.10
将来は卵1パックの価格が2倍に? 多くの日本人が知らない世界の新潮流、「動物福祉」とは
エンジニアリングとプロダクトの役割と連携(全1記事)
リンクをコピー
記事をブックマーク
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:ありがとうございました。
2024.11.13
週3日働いて年収2,000万稼ぐ元印刷屋のおじさん 好きなことだけして楽に稼ぐ3つのパターン
2024.11.11
自分の「本質的な才能」が見つかる一番簡単な質問 他者から「すごい」と思われても意外と気づかないのが才能
2024.11.13
“退職者が出た時の会社の対応”を従業員は見ている 離職防止策の前に見つめ直したい、部下との向き合い方
2024.11.12
自分の人生にプラスに働く「イライラ」は才能 自分の強みや才能につながる“良いイライラ”を見分けるポイント
2023.03.21
民間宇宙開発で高まる「飛行機とロケットの衝突」の危機...どうやって回避する?
2024.11.11
気づいたら借金、倒産して身ぐるみを剥がされる経営者 起業に「立派な動機」を求められる恐ろしさ
2024.11.11
「退職代行」を使われた管理職の本音と葛藤 メディアで話題、利用者が右肩上がり…企業が置かれている現状とは
2024.11.18
20名の会社でGoogleの採用を真似するのはもったいない 人手不足の時代における「脱能力主義」のヒント
2024.11.12
先週まで元気だったのに、突然辞める「びっくり退職」 退職代行サービスの影響も?上司と部下の“すれ違い”が起きる原因
2024.11.14
よってたかってハイリスクのビジネスモデルに仕立て上げるステークホルダー 「社会的理由」が求められる時代の起業戦略
2024.11.13
週3日働いて年収2,000万稼ぐ元印刷屋のおじさん 好きなことだけして楽に稼ぐ3つのパターン
2024.11.11
自分の「本質的な才能」が見つかる一番簡単な質問 他者から「すごい」と思われても意外と気づかないのが才能
2024.11.13
“退職者が出た時の会社の対応”を従業員は見ている 離職防止策の前に見つめ直したい、部下との向き合い方
2024.11.12
自分の人生にプラスに働く「イライラ」は才能 自分の強みや才能につながる“良いイライラ”を見分けるポイント
2023.03.21
民間宇宙開発で高まる「飛行機とロケットの衝突」の危機...どうやって回避する?
2024.11.11
気づいたら借金、倒産して身ぐるみを剥がされる経営者 起業に「立派な動機」を求められる恐ろしさ
2024.11.11
「退職代行」を使われた管理職の本音と葛藤 メディアで話題、利用者が右肩上がり…企業が置かれている現状とは
2024.11.18
20名の会社でGoogleの採用を真似するのはもったいない 人手不足の時代における「脱能力主義」のヒント
2024.11.12
先週まで元気だったのに、突然辞める「びっくり退職」 退職代行サービスの影響も?上司と部下の“すれ違い”が起きる原因
2024.11.14
よってたかってハイリスクのビジネスモデルに仕立て上げるステークホルダー 「社会的理由」が求められる時代の起業戦略