勘所がつかめればPdMにプログラミング力は必要ない　技術力よりも重要な“エンジニアと情報を出し合える関係性”

エンジニア出身PdM4名の自己紹介

横澤佑輔氏（以下、横澤）：本日は「エンジニア出身PdM/PjM/BizDevが集まる勉強会#2」です。前回はエンジニア出身のPdM（プロダクトマネージャー）4名に登壇してもらって、いろいろ深掘りして話を聞きました。今回はビジネスサイドから始まったPdM、エンジニアから始まったPdM2名ずつに登壇してもらって、ふだん聞けないあれやこれやを深掘りしていきたいと思いますので、よろしくお願いします。

さっそくですが、パネラーの自己紹介タイムです。じゃあ、永嶋さんからお願いします。

永嶋章弘氏（以下、永嶋）：不動産の賃貸領域のSaaSを作っているイタンジ株式会社で執行役員をやっている永嶋と申します。私はもともとエンジニアをやっていて、ビジネス側に侵食してきました。今はこの「OHEYAGO」という、新しいかたちの部屋探しサービスを作っています。メインがその業務で、その他にもいろいろな雑用もやっています。マルチで歌って踊れるエンジニアです。

横澤：すばらしいですね（笑）。

（一同拍手）

横澤：では、次に鈴木さんお願いします。

鈴木康弘氏（以下、鈴木）：鈴木康弘といいます。yappyと呼ばれています。

写真はみなさんに詐欺写真と言われていますが、ご了承いただければと（笑）。今は、脆弱性管理クラウドの「yamory」というサービスのプロダクトオーナーをしています。初期のタイミングでビズリーチに入り、5つの事業の立ち上げやクラウドプロダクトの開発組織もやってきました。

セキュリティに課題を感じて自らセキュリティSaaSを作ろうと考え、2018年にyamoryを起案して事業化しました。なので、キャリアとしてはエンジニアからPM系です。あとは、最近言われる言葉に近いものとしてPMM（プロダクトマーケティングマネージャー）もやっています。

横澤：その5つの事業は、エンジニアとして関わったのですか？

鈴木：そうですね。はじめの3つぐらいは、いわゆるリードエンジニア兼EMのような感じでした。

横澤：じゃあ、ガッツリとマネジメントしていたんですね。

鈴木：はい。それでだんだんとPMになっていったキャリアだと思います。事業の紹介を簡単にすると、実は昨日（※登壇当時）、記者発表会で新コンセプトを発表しました。システムを開発している人が非常に多いと思っていて、セキュリティ対策で何をどうやったらいいかわからないとの声が多いので、yamoryでオールインワンで実現しますというコンセプトを発表しました。

もともとは一部領域のセキュリティ問題を解決するプロダクトだったのですが、いろいろなレイヤーごとの課題をしっかりと解決できるサービスに拡張させています。（スライドを示して）ソフトウェア脆弱性管理と書かれたオレンジのところから始まっています。

みなさんがよく使っているクラウドインフラ、AWS、Azure、GCPなどの設定の不備を自動で検知して管理できるCSPMであったり、さまざまな診断結果を統合的に管理する診断結果管理までをやることで、検知から管理まですべてyamoryで行えます。そういったところを、この1年をかけて目指していきたいと思っています。

横澤：すごい。

鈴木：IT・Web系だけでなく、最近は大手でKDDIさまや、ちょっとここには載らなかったのですが、製造業系ですごく大きな会社も入ってきて、徐々に広がってきているところです。お客さまのセキュリティの課題に多く応えていけるように、サービスを拡大していきたいと思っています。

（一同拍手）

永嶋：もっとしゃべればよかった。

（一同笑）

鈴木：エンジニアのお客さまがコアターゲットなので話してしまいました（笑）。

横澤：じゃあ次は伊藤さん、お願いします。

伊藤友也氏（以下、伊藤）：伊藤と申します。私は株式会社すむたすで取締役をしています。僕はBizサイド出身のキャリアです。大学を卒業したあとにリクルートに入社して、不動産メディアの「SUUMO」のビジネス側の仕事をしていました。インド発の不動産×ホテルのTech企業のOYOが日本に進出する時に、日本人1人目のプロダクトマネージャーとしてジョイン、2018年にすむたすを共同創業しました。

すむたすの紹介です。僕たちはテクノロジーを使ってマンションが手間なく確実に売れるサービスを提供しています。オンライン上でマンションの情報を入力すれば、その日中に確定した売れる価格が算出されて、ユーザーがスケジュールをコントロールして手間なくマンションが売れるというサービスを提供しています。

会社のフェーズは、2022年の3月にシリーズBラウンドを完了していて、絶賛事業拡大中です。本日はよろしくお願いします。

（一同拍手）

横澤：最後に明石さん、お願いします。

明石衛氏（以下、明石）：明石と申します。株式会社リテイギで、建設事業の事業立ち上げ責任者をやっています。僕も伊藤さんと同じく、ビジネスサイド一辺倒のキャリアです。もともとはコンサルから始まっていて、コンサルをやったあとにフロムスクラッチ、今のデータXに入りました。プロダクト開発の組織の立ち上げがあったので、そこでマネージャーなどを務めて、プロダクトにも絡むようになりました。

先ほどyappyさんが出ていましたが、僕もビズリーチに入ってyappyさんと一緒にサイバーセキュリティ事業のyamoryを立ち上げました。当時は、僕がビジネスサイドを見て、yappyさんがプロダクトサイドを見ていました。立ち上げを一緒にやってきた感じです。

2021年にそこを卒業して、株式会社デジタルホールディングスの関連企業・リテイギの新規事業の立ち上げ部隊にいます。1人の新規事業オーナーとして入り、そこの建設領域でSaaSを今まさに立ち上げている、そんなキャリアです。よろしくお願いします。

（一同拍手）

横澤：最後にモデレーターの私の簡単な自己紹介です。株式会社ソースメイカーの横澤と申します。細かいことはさておき、受託の会社をやっていて、スタートアップの新規事業の立ち上げや、大企業のPoCの立ち上げフェーズを担うことが多いです。プロダクトの立ち上げには関わるケースがけっこう多いので、そういった観点からモデレーターを務めます。よろしくお願いします。

（一同拍手）

PdMはどの程度プログラミングを理解すべきなのか？

横澤：ではさっそく、アジェンダに入っていきたいと思います。これはビジネスサイドからならではのよくある質問だと思いますが、プログラミングはどの程度理解すればいいのか、そもそも理解すべきなのか？　おそらく、いろいろなところで何度も聞かれている気がしますが、永嶋さんはどうですか？

永嶋：ずっと言っていますが、プログラミング自体は理解しなくていいです。むしろ、データベースのSQLや構造を読めるようになっておくと、プロダクトマネージャーとしてユーザーを解析したい時などにいちいちエンジニアに「こういうデータを出してください」と言わなくていいので、メチャクチャ捗ります。

横澤：なるほど。僕もエンジニアなのでなんとなく言いたいことはわかります。単純にプログラミングと言ってしまうとメチャクチャ広いじゃないですか。その中でもデータベースのデータ構造であったり、データを理解するところだけにフォーカスしていれば、細かいif文やfor文などのいわゆるプログラミングの部分はあまり関係ないということですね。

永嶋：そうですね。関係ないと思いますが、鈴木さんはどうですか？

鈴木：プロダクトマネージャーは別にプログラミングをできなくてもいいのではないか、という説を私も主張しています。

永嶋：ただ、これはできそう、できなさそうと判断する時に、データはそもそも持っているのか、そういう処理ができるのかという勘所があるとわりといいですよね。

鈴木：そうですね。

横澤：これを質問する背景は、まさに今話されたことだと思っています。軽い気持ちでエンジニアに頼んだら「3ヶ月かかります」と言われて、「え!?」となってしまう。そういったギャップを埋めたいという話だと思うんですよね。

永嶋：エンジニアはけっこう保守的に工数の見積もりを出してくるじゃないですか。僕もエンジニアだったのでわかります。

横澤：あまり攻めたくはないですよね。

永嶋：「それって実際は、これでいけるでしょ」という感覚があると有利だとは思います。

横澤：なるほど。

鈴木：もう1つあるとすると、ドメインによってはやはりテクニカルに難しいものがあります。

横澤：確かに。セキュリティもまさにけっこう難しい。

鈴木：yamoryのセキュリティもそうです。例えば、GitHubやAWSなどのプロダクトをやろうとなったら、テクニカルを理解できていないとPMはできません。そういったドメインの知識は、場合によっては必要かもしれません。

横澤：そもそも、扱う領域がわかっていないと成り立ちませんよね。

鈴木：toCのサービスや普通の業務システムであれば、ぜんぜんいらないのではないかと。

エンジニアと情報を全部出し合える関係性を築くことのほうが重要

横澤：ちなみにビジネスサイドのお二人のうち、友也さんはどうですか？　プログラミングをやろうと思ったことはありますか？

伊藤：今までにやろうと思ったことはあります。プログラミングができるとはとても言えないレベルですが、自分で簡単なサイトを作ったり、NoCodeを触ったりしています。あとは「応用情報技術者」を持っています。

横澤：「応用情報技術者」を持っているんだ！　えらい！　メチャクチャえらい！　ちゃんとやっている。

伊藤：ただ、きれいなコードを書けるレベルではぜんぜんありません。エンジニアと会話する上では、エンジニアが考えていることを理解するために、サービスがどう動いているかを知らないといけないことがけっこうあると思っています。

特に、ビジネスサイドだと、ビジネス的なプライオリティだけで要件を主張しがちだと思いますが、どう動いているかがわかっていれば、「リファクタリングが大事だ！」「ここを解消しないと！」と、優先順位を一緒に決める時に目線が合うので、それぐらいのことは理解していてもいいと思っています。

永嶋：けっこう難しいですよね。

横澤：純粋なビジネスサイドの人からすると、正直リファクタリングは「なんやねん」みたいな話だと思います。その瞬間にエンハンスがされているわけではないので。そういったところは長くやっているので、実際に自社でプロダクトを生み出している中で出てくると思いますが、議論はするのですか？

伊藤：例えば、エンジニアが「こういうリファクタをしたい」と言った時、それに対して「このリファクタはそもそも必要なんでしたっけ？」などと僕が言うことはありません。

また、エンジニアが見積もった工数の内容に対して「いやいや、そんなにかからないでしょ」と僕が言うこともありません。エンジニアが必要だということに対して、ビジネス的な優先度と比較しながら検討できるというレベルですね。

横澤：リファクタの持っている価値と、ビジネス上でエンハンスする機能の価値がありますが、ビジネスサイドから見ると片方についてはわからないじゃないですか。そこはもう議論の中で擦り合わせて「こういうところは同じぐらいの価値だから、いったんここはリファクタを優先しよう」と意思決定する感じなのですね。

伊藤：そうですね。これは僕の場合なので、ぜひ意見を聞きたいです。ビジネス的には絶対にここまでやらないといけない、もしくはすごく効果がある蓋然性が高いものはやはり早くやりたいので、リファクタよりもこちらを優先してくれという話はします。そうでないものは、プロダクトを作っているのはエンジニアなので、中長期で考えたら彼らがやるべきだと思っていることをなるべく優先するようにしています。

横澤：ビジネス的に即効性があってインパクトがあることは、やはり先にやってしまいたいです。明石さんのところは、今まさにプロダクトを作っている0→1のフェーズだと思うので、あまりリファクタの話はないと思いますが、0→1のタイミングで、工数をなんでもかんでも最初に一気に詰め込むことはできないじゃないですか。そのあたりはどうしていますか？

明石：そこはお互いに情報を出し尽くして話し合ってやっています。たぶん、僕はプログラミングのことをこの中で一番わかっていないと思うのですが、別にわからなくてもいいと正直思っています。むしろそこはエンジニアを信じています。先ほど、「工数は保守的に出す」と言っていましたが、それはそれでいいと思っています。

その代わり、こちらの思っていることを全部出すようにしています。例えば先ほど言ったように「ここまでにこれが出せたら、絶対に事業的には大きいんです」「このお客さまに最初に使ってもらいたいから、こういうものを作ってほしいです。なぜならば、この事業をこう成長させていきたいから」などです。それを全部言えれば、わりとエンジニアも「だったらこうですね」と提案してくれることがけっこうあると思っています。

だから、プログラミングを理解するというより、互いに情報を全部出し合える関係性を築くことのほうが重要だと思っていました。

横澤：なるほど。明石さんはプログラミングを勉強しようと思ったことはありませんか？

明石：ありますが、yamory時代、ビジネスサイドは最初僕1人でした。スーパーエンジニアばかりだったから「どうやったらそこは学べますか？」と聞いてみたら「そんなものはメモ帳にコードを書けばいいんだよ。それでできるんだよ」と言われて……。

（一同笑）

明石：「わかりました。僕に理解は無理だな」と思って諦めた経緯があります。

横澤：なるほど。

明石：それでも結局、全部話せば通じます。

永嶋：確かに、その時点で「学ばなくていいや」って思っちゃう。

横澤：学ぶ背景や理由は、歩み寄ったりエンジニアの理解を高めたりするためです。

永嶋：確かに。

明石：「勘所」の話が出たのですが、まさにそうだと思っています。きちんと話し合えたり、情報を出し合えたりする関係性があれば、それはできると思っています。

横澤：相手は専門職なので、コミュニケーションをきちんと取れているのであれば別に（プログラミングのスキルは）不要だと思います。

明石：そうですね。

横澤：「数ヶ月やって、具体的なプロダクトを作れますか？」と言ったら、それはぜんぜん無理じゃないですか。ホームページを作るぐらいであればできると思いますが。そういう意味でも、ビジネスサイドは他に力を使うところがあると思うので、個人的にはあまりやる必要はないと思います。

分析という意味でSQLはやっておいたほうがいい

明石：ちょっと教えてほしいのですが、それでも勘所をつかむにはなにかコツがありますか？　例えば、SQLや言語の特徴を知っておくべきなど、なにかありますか？

鈴木：いらないと思います。

横澤：言語の特徴はエンジニアも究極わからないですよね。

鈴木：流派みたいなものですよね。

横澤：それでいうと、確かにデータベースなどが互いに見えている中で、どのようなデータがあるかを前提に話せるのはかなり価値がある気がします。そこにないものを議論に出されても、正直やはり工数の面で相当大きくなってしまう。

鈴木：CSが気楽に「この数字が見たいです」と言っても「ねぇよ」みたいな。

（一同笑）

鈴木：SQLは本当に分析という意味で、きちんとやったほうがいいかもしれないですね。

横澤：それこそ、Excelを使ってビジネスサイドが語ったら、SQLはすんなり入る気がします。

明石：僕はSQLもまったく書けません。全部お任せしていました。

横澤：なるほど。じゃあ『初めてのSQL』などを買っていただいて。

明石：買ってきます。

（一同笑）

鈴木：ビズリーチのマーケティングチームはデータ分析を自分たちでやるので、ビジネスサイドでもSQLをやらないといけない環境になっているケースもあります。

横澤：yamoryマーケもいますか？

鈴木：います。

横澤：すごいですね。

永嶋：メルカリもそうです。

横澤：メルカリは……。

鈴木：みんなできそう。

永嶋：メルカリはけっこうみんなSQLをバリバリ書いていましたね。

横澤：なるほど。そこを深掘りしてもいいのですが、やるならいったんSQLぐらいにしておきましょう。

（一同笑）

（次回へつづく）