2024.12.10
“放置系”なのにサイバー攻撃を監視・検知、「統合ログ管理ツール」とは 最先端のログ管理体制を実現する方法
エンジニアリングとプロダクトの役割と連携(全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.10
メールのラリー回数でわかる「評価されない人」の特徴 職場での評価を下げる行動5選
2024.12.09
10点満点中7点の部下に言うべきこと 部下を育成できない上司の特徴トップ5
2024.12.09
国内の有名ホテルでは、マグロ丼がなんと1杯「24,000円」 「良いものをより安く」を追いすぎた日本にとって値上げが重要な理由
2023.03.21
民間宇宙開発で高まる「飛行機とロケットの衝突」の危機...どうやって回避する?
2024.12.10
職場であえて「不機嫌」を出したほうがいいタイプ NOと言えない人のための人間関係をラクにするヒント
2024.12.12
会議で発言しやすくなる「心理的安全性」を高めるには ファシリテーションがうまい人の3つの条件
2024.12.06
嫌いな相手の行動が気になって仕方ない… 臨床心理士が教える、人間関係のストレスを軽くする知恵
PR | 2024.11.26
なぜ電話営業はなくならない?その要因は「属人化」 通話内容をデータ化するZoomのクラウドサービス活用術
2024.12.11
大企業への転職前に感じた、「なんか違うかも」の違和感の正体 「親が喜ぶ」「モテそう」ではない、自分の判断基準を持つカギ
PR | 2024.11.22
「闇雲なAI導入」から脱却せよ Zoom・パーソル・THE GUILD幹部が語る、従業員と顧客体験を高めるAI戦略の要諦