2024.12.19
システムの穴を運用でカバーしようとしてミス多発… バグが大量発生、決算が合わない状態から業務効率化を実現するまで
エンジニアリングとプロダクトの役割と連携(全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.12.20
日本の約10倍がん患者が殺到し、病院はキャパオーバー ジャパンハートが描く医療の未来と、カンボジアに新病院を作る理由
2024.12.19
12万通りの「資格の組み合わせ」の中で厳選された60の項目 532の資格を持つ林雄次氏の新刊『資格のかけ算』の見所
2024.12.16
32歳で成績最下位から1年でトップ営業になれた理由 売るテクニックよりも大事な「あり方」
2023.03.21
民間宇宙開発で高まる「飛行機とロケットの衝突」の危機...どうやって回避する?
PR | 2024.12.20
モンスター化したExcelが、ある日突然崩壊 昭和のガス工事会社を生まれ変わらせた、起死回生のノーコード活用術
2024.12.12
会議で発言しやすくなる「心理的安全性」を高めるには ファシリテーションがうまい人の3つの条件
2024.12.18
「社長以外みんな儲かる給与設計」にした理由 経営者たちが語る、優秀な人材集め・会社を発展させるためのヒント
2024.12.17
面接で「後輩を指導できなさそう」と思われる人の伝え方 歳を重ねるほど重視される経験の「ノウハウ化」
2024.12.13
ファシリテーターは「しゃべらないほうがいい」理由 入山章栄氏が語る、心理的安全性の高い場を作るポイント
2024.12.10
メールのラリー回数でわかる「評価されない人」の特徴 職場での評価を下げる行動5選
Climbers Startup JAPAN EXPO 2024 - 秋 -
2024.11.20 - 2024.11.21
『主体的なキャリア形成』を考える~資格のかけ算について〜
2024.12.07 - 2024.12.07
Startup CTO of the year 2024
2024.11.19 - 2024.11.19
社員の力を引き出す経営戦略〜ひとり一人が自ら成長する組織づくり〜
2024.11.20 - 2024.11.20
「確率思考」で未来を見通す 事業を成功に導く意思決定 ~エビデンス・ベースド・マーケティング思考の調査分析で事業に有効な予測手法とは~
2024.11.05 - 2024.11.05