00:03
皆さんこんにちは、クライス＆カンパニーの山本です。 この番組では、プロダクトマネージャーのキャリア全般についての情報を発信してまいります。
今回は、及川拓也によるインタビューの続きをお聞きいただきます。
はい、では続けて、サービスの紹介やビジョンのところ、ミッションのところという上位概念に近いところのお話を聞いてきましたけれども、
もう少し具体的なプロダクトの作り方というところをお聞かせいただければなと思います。
まず、これもちょっと明かせるとこ、明かせないとこあるかもしれないんですけれども、ログラスさんにはプロダクトマネージャーって今何人ぐらいいらっしゃるんですか?
10かな?ちょうど数えてたんですよ、さっき。10人のはずです。
10人というのは、組織全体から見たときに、どうなんだろう、ちょうどいいぐらいなのかな?
ただ、ログラスさんみたいにこれだけ勢いがあって事業が伸びている会社からすると、やや少ないんじゃないかなというふうに思うんですけれど、これはどういうふうに見ていらっしゃいますか?
やや少ないと思って見ています。
やっぱりSaaSの会社なので、すごいディストリビューションが大事なビジネスですので、ビジネス組織の方が大きいということはこれは別にベストだなと思っている中で、
250分の今開発が7、80なんですよね、プロダクト開発全体。
その中の10人がプロダクトマネージャーっていう状態ですので、ですと。
これやや少ないなと思っているところで言いますと、結構AI自体プロダクト開発のあり方がすごく変わってきているなと思っている中で、
秘書的に人間化のように最高のパートナーがプロダクトになるじゃないですか、今後。
ただのツールから最高のパートナーっていうプロダクトが再定義されていく中で、そこのディスカバリのマイルがすごく上がっているし、フィジビリティの重要度が上がっているっていう中において、
そこを開発しましょうというよりも考えましょう、試しましょうっていうフェーズの比率が上がっていくはずだとしたときに、
PDM対デザイナー対エンジニア対QAっていう比率で言うと、PDMデザイナーの比率は上がってしかるべしだと思っていますという観点で、
PDMやや少ないなと思っていますというところと、単純にエンジニア減らしましょうかっていうとそうではなくて、
今2年で10個、2027年4月までに20のプロダクトラインナップになりますっていうようなことを周りに話しているとおり、
実際今新規事業が7、8個並行開発しているんですよね。
そこはもうPDM1人、エンジニア2人で最速のスピードでコンテキスト以下のコストめちゃくちゃ下げて作りましょうみたいな作り方をしているんですけれども、
03:00
そこを支えるアーキテクチャチームだったりっていうところも含めるとエンジニアもシンプルにまだちょっと足りない。
ちょうどエンジニアが足りないという状態になっていますので、比率を上げたいという意味と総量を増やしたいという意味でPDMはダブルで足りないなというところです。
なるほど。やっぱり生成AI時代になって、最近一般のニュースも出てきているみたいに、
実はエンジニアも今までみたいに右肩上がりで需要が増えていくわけではなく、
何なら失業する人も出てくるんじゃないかっていうような悲観的な見通しもある中で、
斉藤さんもディープラーニングをやられていたのでご存知だと思いますけれども、一時Googleにも行った、
いつも発音が難しいアンドリュー・ウング先生でしたじゃないですか。
が、プロダクトマネージャーとエンジニアの比率っていうのを確か1対2とか1対3とかぐらいに上げて、
もうプロダクトマネージャー1人に対して2人エンジニア、3人エンジニアぐらいの割合でプロダクトマネージャーは増える。
エンジニアはおそらく簡単に言うとサチュレーションするかもしれないということを言われていて、
これが一番プロダクトマネージャー需要が多いっていうふうにお得されているデータかなと思うんですけれども、
なんか今の斉藤さんが言われたのと全く同じようなことを言われているのかなというふうには思いました。
なるほど。
たぶん2つの角度、2つの根拠があって、1つがさっきたぶんアンドリュー先生もおっしゃっている、
エンジニアのコーディングがすごく楽になったよね。
クロードコードだったりだとかいろんなものしかびでコーディングスピードが上がったよねという観点もそうなんですけど、
プロダクトを作るということの難易度が上がっているんですよね。
企画する難易度が上がっているように感じていまして、今までってどういうインターフェース、
基本PCベースのインターフェースにどう何が打ち込まれて何を返せばいいかっていう
非常にシンプルなインターフェースで管理されていたところから、
エージェントになって互換まで機能拡張されてカメラを使って音声を使って、
何し人間の生活の一部に入り込むにあたってマルチデバイスで
じゃあアレクサに経営管理って実は入ったほうがいいんじゃないかみたいな話。
Google Homeのほうがよかったですね。
Google Homeに経営管理ってインターフェース入ったほうがいいんじゃないかとか、
そういうところまで考えないといけないコンテキストが増えた。
でもそれをキュッとまとめていい体験を作らないといけなくなったというところで、
ディスカバリの難易度が上がったっていう、さっき申し上げたことの
両面ダブルパンチで比率は変動していくべき。
特に後者のところに関しては、
エンジニアリングの知識が前提にあるPDMってめちゃくちゃこれから強くなる。
何が作れるかっていうことを広くイメージしながら話せるPDMというのは
とても希少度が上がるので、
エンジニアのネクストキャリアとしてのプロダクトマネジメントということの
重要性も高まってきているなというのを同時に感じていますね。
そうですね。
IT業界っていうのは他の業界に比べると結構激動で変化が激しい。
06:03
自動車業界が今100年に1度って言われてて、
私は自動車業界のお手伝いもする中で
IT業界ではそのぐらいの変化は10年に1回起きてますよっていう風に言って
ちょっとあえて煽るような感じで
そんなゆるい流れで良かったですねみたいに言うんですけれども
とはいえここ10年、15年って
ウェブもスマホも結構固定化された状態になったと思うんですよね。
特にMacとかパソコンとかって見ると分かるように
普通にメニューがあってそこからあるコマンドを選んで行き
実行するっていう形で
いわゆるユーザーインターフェースって言われてるものは
そう大きく変わってないと。
音声でのコマンド指示っていうのも
もう少し伸びるかなと思ったけれども
そんなに今変わっていないんで
実はUIデザイナーって細かいデザインの変化はあれれど
やってることは変わらなかったと思うんですよ。
ただこれがやっぱり生成AIによって自然言語でっていう風になって
やっぱり改めて音声での指示っていうものが
本当に使えるようになってくるであろうっていうものも想像できるし
何ならチャットベースで全部行くべきじゃないかっていうのも出てくるし
あとエージェント向けになるとユーザーインターフェースじゃなくて
AIエージェント向けのインターフェースを考えなきゃいけない
っていう時代にもなってきたりということで
一気に変わるので
斉藤さんおっしゃるみたいに
物を作るの大前提として
そもそも何を作るのかっていうことを考えなきゃいけないような
時代になってきていて
とても面白いなと思うと
同時に大変だなというふうには感じますね
本当にそうです
ITツールの時代だとやっぱり
いい叩きは自分で作るしかなかったじゃないですか
基本的に考えるのは誰ですかっていったら自分で
入力しないといけない情報
結構多めのコンテキストを入れないと
物って動いてくれないよねっていう前提だったのが
AIエージェント時代に入って
9割ぐらいのもうあと
じゃあそれでよろしくって
イエスって言いさえすれば
仕事が進むとか物事が進むように変わったっていう
一番大きなパラダイムシフトだと思っていまして
音声解釈レベルが上がったから
音声インターフェースが上がる
もちろんそれもそうなんですけど
自分じゃないところで完結することが増えて
注入しなければならない
判断というか
その時々に必要な情報がすごく減ったので
今までだとできなかったこのスマートウォッチとか
でもはいって言うだけで仕事終わっちゃうみたいな世界が
消える状態になったので
インターフェースが拡張された
となると多分それこそグーグラス的なものも
今改めてXリアルバーンさんとか
私もこないだ買って売ってとかやってますけれども
ああいうインターフェースがどんどんどんどん
使いやすくなっていうことが起こってるんで
インターフェースレベルのパラダイムシフトを
保守するそのモデルレベルの
パラダイムシフトが起こったなっていうのが
生成AIの見方ですね
ですよね
この話出すとどんどんどんどん
この話だけで終わってしまいそうな
いや私も好きなんでこれは別途
09:00
個人的に続きやりたいなと思うんですが
そんな中
例えば10人今いらっしゃり
今後さらに増やしていくっていう時に
その今おっしゃったように
面白いけれどめちゃくちゃ難易度が高い
プロダクトマネジメント業務を
全員に期待するのか
それともグレードみたいなところで分けたり
もしくはその
ディスカバリーのところに担当したり
ある程度道筋が決まった後
プロセスをうまく回していくフェーズであったり
グロースさせるフェーズであったりっていう形で
フェーズを分けたりして
そこで要求されるスキルを別のものとする
その難易度が低いってわけじゃないですけれども
従来のグロース的なプロダクトマネジメント
っていうのはSaaSだとしたらある一定
ある程度決まったやり方がいくつかあり
それをどういうふうにデータを元にして
組み合わせていくかっていうようなやり方も
あるわけじゃないですか
なのでログラスさんの中で
質問を改めてしますと
今いったAI時代になりすごい難易度が上がっているもの
全員に期待されているのか
それともそういうようなある意味
部隊とそれ以外の部隊みたいな形で
いくつか分割されていらっしゃるのかというと
どんな組織構成をされていらっしゃいますか
まず大前提僕は全員に期待したい
っていうタイプのマネジメントをしています
じゃないと面白くないじゃないですか
プロダクトマネジメントやってるのに
っていう気持ちが前提あります
それこそその他機械的にできるってことは
Aで全部解釈できるんで
そっちに自動化していくべきだ
例えば数理的にできる話だったりだとか
バグの回収だったりっていうところは
どれだけAIで効率化するかって勝負だなと思っています
ので体制もですね
機能別っていう分け方はしておらず
今だとプロダクトマネジメント組織っていうのもないんですよ
実はPDM部っていうのをなくしていって
あなたはこのプロダクトのチームのトップです
っていう1人がいて
その人の下にそのプロダクトに関わる
エンジニアもデザイナーもQAもPDMも全員いる
っていう体制に変えましたっていうのは
実は直近変えたところでございまして
経営管理のプロダクトは
例えばスカさんっていう人が見てくれてますと
あとは人員計画ですね
リリースしてるプロダクトは木村さんっていう人が見てます
木村さんがエンジニアリングもデザイナーもPDMも見て
その中でちょっと未来のことを考える時間が減ってきたなと思ったら
PDMライクの人を採用しようだったりですとか
エンジニアがその部分をカバーしていこうっていうような
できるだけちっちゃい単位にして
この時代もう手動かすのみんな早くなったんで
できるだけチームをちっちゃい単位にしてコンテキストシェアリングを
最小限にして全部Googleドライブで
カーソルに食わせられるクロードコードに食わせられる形の
SIMリンク貼って管理してみたいなことをやりながら
チームとして作って役割の間の概念を
溶かすみたいなことを今はやってますね
12:01
なるほど その職能で組織を作るか
その事業ごとに作るかっていうのは
2つの流派があるなと思うんですけれども
ただ私も長くいた会社は
最終的にはその事業ごとのところで
チームが固まっていてプロダクトマネジメント部
みたいなものが独立してあるっていう形態じゃなくなっていることが
多かったので やっぱりある程度事業が多くなり
組織も大きくなる中でその事業ごと
っていうところでまとめていき そこで職能を超えた形で
グループとして一挙をしながら
全て正しいと思う 成功すると思うことを
試していくってやり方を取るっていうのは
ある一定のやり方なのかなというふうにお話を聞いていて
思いました ちょっと次にお聞きしたいのが
そんな形で事業ごとにプロダクトとか
エンジニアとかが固まって小さい組織で
プロダクト作りを進めていく中
じゃあ ある領域のところにおいて
1機能が
実際に企画から
お客さん先に届くまでの流れ
もともとアイディアもいくつかあってアイディア段階で
議論の末 進めないっていう風になるものも
あると思うんですけれども 要は
機能レベルだとか もうちょい大きい単位でもいいんですけれども
ログラフさんの中でどんなジャーニー
流れをたどって実際にお客さんの手元に
いくのかっていうところを教えてもらってもいいですか
ありがとうございます これはチームのサイズによって
違いますっていう回答にはなるんですけれども
まず すごいスモールな新規事業のチームで言うと
これはもう事業オーナーが
営業検証をするということがないし
顧客と理想を握るということを先にやって
それに必要なものをガチャガチャガチャっと作り上げていきます
っていうプロセスが近いなと思っています
例えば 新規事業少し掘り下げさせていただくと
われわれ新規事業って4つのフェーズに分けてるんだ
これあんまり外で話しないかもしれないんですけど
別にマルヒでもないんで 発出し情報ということで
素晴らしい ありがとうございます
4つのフェーズ フェーズ0 1 2 3っていうふうに分けてやってるんですが
フェーズ0はまず売りなさいっていうことをやるんですよ
コンセプトで信じてくれるお客様を探してきてください
ですね 言い換えると
なので 何を作るかっていうことを約束すると
良くないものを作ってしまうという制約になるので
これは良くないんですけれども この課題を僕は
あなたたちと解きたい 例えばこういうふうな解き方が
あり得ると思うっていう営業資料を作って
仲間集めをしてきてください 理想は3社
しかもペイド 物はないけどペイド
というオーダーをして
取りに行ってもらいます これを突破できると
フェーズ0初めて突破で もう仲間集め お客さんという
仲間集めが完了したと見出して 開発チームを
蘇生し始めますっていうのがフェーズ0の突破状態
で そのフェーズ1のタイミングで
エンジニア デザイナー プロダクトマネージャー 事業オーナーとお客様
15:01
で どんなプロダクトにしていくのが理想だろうか
っていうことを議論します ここはお客様からも
汚なき意見を お金も払っていただいてるんで
向こうも必死です これの
投資対効果を見出さねばならんっていうふうに
エンジンかかっていただいてる状態なんで
そこの皆さんに負けないように プロダクトチームのほうも仮説を
ちゃんと構築して こうすればあなたたちの状況 絶対に
良くなるに違いないかなっていうことを ご容疑するではなくて
ちゃんと仮説を持ってぶつかって
握りましょう これがフェーズ1
で フェーズ2が実開発ですね
を行って ぐっと開発して ああでもない こうでもない
例えば スプリントレビューにお客さんに聞いていただくなんてこと
全然ありですっていうような形で
入っていただいて フェーズ2を超えた後
最後 私のレビューが絶対に必要だっていうふうに してるんですけれども
私のレビューとお客様が実際に 使い始められる状態にあるか
ということを軸に プロダクトリリース
押し フェーズ3 ゴートマーケットフェーズ2
いうような形で動くというのが 新規事業開発のプロセスで
フェーズ0が早ければ
3ヶ月です
最初の検証 コンセプト検証が
捨てるのは3日で捨てたり4日で捨てたりするんですけれども
最終的に1つたどり着いて お客様とご一緒できるっていうところは
お金を出していただくっていうところも含めて
3ヶ月ぐらいかかるな
早いチームで2ヶ月っていうチームもありましたね
そういえば素晴らしいことです それぐらい
フェーズ1は ぐっと詰めて1ヶ月でやり切ろう
情報はあるんだから 仮説を構築する時間が短い方がいいというところで
すごく強力的なお客さんと一緒に1ヶ月でやり切ろう
フェーズ2は開発なんで これはまばらになるんですけれども
MVPと呼ばれるものは
6ヶ月あれば作れる時代になっているはずだ 長くても
というとこでMAX6ヶ月でリリースまでを目指しましょう
それだけ絞りましょう 尖らせましょう
魅力的品質がないプロダクトは本当にダメなんで
フェーズ2の突破の状況はシンプルで
これを使ったお客さんがパッと華やくような笑顔をするシーンが
本当に想像できるか 実際に起こるか
何か便利になりましたねと言って プロダクトはこの世から無くなればいい
というぐらいの激しい思想で
華やいた笑顔を見せるかというような 訂正的なところで
フェーズ2の突破状況を置いて
そうするとNPSも自然に高まるんで その後グロスしやすい
ジェレム持ちの素晴らしいものが出来上がるので フェーズ3に
広げていきましょうという形をしています
というのが まず新規事業のところですね
なるほど
同じかどうか分からないので ここで一旦質問させていただきたいんですけれど
その仲間集めという時に
その仲間が あえて分かりやすい言葉を言うと
良い仲間じゃないとダメなんじゃないかなと思うんですね
つまり マーケットを見た時に
ある特定のセグメントを代表する方々であるべきだと思うんですけれども
その特定のセグメントがめちゃくちゃニッチで
3社集まっても その3社って日本に3社
以外なく 3社以外全然広がりませんでしたよ
18:02
という可能性だって すごい分かりやすい極端な例を
出してますけど あるわけじゃないですか なので
どんな仲間を集めたかというとこも問われるのかな
もしくは問われるべきなのかなと思うんですけど
そこはどうされていらっしゃるんですか
これはイエスなんですが 実はその前に握ってますというのが近く
我々やっぱり管理会計領域のプロダクト群なんですよね
経営を良くしようというプロダクト群なので
管理会計というものはすごく抽象化すると
ポートフォリオマネジメントだと思っています
どこに人もの金を配付するのかというゲームだなと思っているので
これをやっている会社でないといけないというのは
もう大前提だと思っています
逆に3人のスタートアップ 当時僕がやってたみかんみたいなので
来週プロダクト潰して別のやろうと思ってるんですよね
という人たちが数字見るんじゃなくて顧客に向き合うべき
というフェーズなので 我々のお客様ではないですねと
そうじゃないところで頑張っていただく方がいい
というふうに割り切っているというところがありますので
そういう割り切り方で 実はログラスは
N1 ティア1 ティア2 ティア3というような形で
ティア分けをすでに会社としてしているところがございます
お役立ちできるところ
そこの中で探しましょう
そこが全く重ならないところで
管理会計が重ならない
管理会計で探すと必然的にそこになるんですよ
管理会計のお悩み事を持っている会社をティア1にした
なので必然的に顧客が重なる
になってますね
ターゲット顧客リストみたいなものがあって そこから選ぶという形になるということですね
基本的にそうなりますし
新規事業ってお客様から生まれることが多いんで
新規事業の最初のお客様も経営管理の既存のお客様が
ほぼ含まれてます
という状態になります
もう一つ大井川さんがおっしゃった中で
ランダマークがないといけない
プロダクトというのはモーテルマーケットまで考えると
この会社の真似をしたいと思ってくれているところと
思われるような会社さんと
ご一緒できると一気に広がる
ランダマーク性が高い会社を連れてきたら
もうそいつは英雄だと
もう素晴らしいよく
コンセプトしかない状態で売ってきたなというところで
より良いという評価をします
やっぱりその仲間というところは
ログラスが定義している仲間
それがかっちり言語化されているかどうかは別にして
もう皆さんが集めてくるものは
自然的にログラスがしっかりと顧客になってほしい
世界観を一緒に作っていきたいというところであるというところが
前提としてあるという話です
分かりました 既存の方も教えていただいてよろしいですか
分かりました 既存のプロダクトに関しては
既にお客さんもいらっしゃいます
さっきのTier1のセグメントもっと厳格に切られていて
バイネームでいうとこの数社を
メインユースケースとしておきましょうというところまで
グッと絞っています ログラスの場合は
21:02
管理会計って本当に会社さんによって
やり方が違うものです
例えば何だろうな
財務会計と対比するのが分かりやすいかもしれないですけど
財務会計だと税金計算をちゃんとしましょう
お国にちゃんと報告しましょう
記事会示のための情報を集約しましょうとなると
この基準に合わせてこういう数値をこの情報で持ってきてください
なぜなら原価消極の期限も
物によって決まってますという
すごい厳格なルールベースの世界なので
会社ごとに最大公約数が非常に
多い 広いものだなと思っています
ただし管理会計の最大公約数って本当に
ちっちゃいですよね なので
僕らが作るプロダクトは一定のセグメントを絞った上での
最小購買数を作る方がいいんじゃないかという仮説を持ってます
というのがログラスのプロダクト作りの
大方針を持っていることでございます これは新規事業
既存事業共有しているもので
既存事業の中でも最小購買数を作りましょうという時に
プロダクトマネージャーが一番意識しないといけないのは
顧客の業務プロセスであり
顧客の経営の成功イメージである
というふうに定義をしていまして
顧客はどういうふうな業務を今されていらっしゃるのか
どんな経営をしていきたいと思っているのか
それは今のプロセスだけではなくて 今後経営がこうあるべきだ
ということを考えましょう 一緒に語らえましょう
というようなプロセスを教えており そこから生まれた
この価値ベースのエピックですね
こういう 例えば
為替を加味して未来を予測しなければ
正しい利益喪失ができないのではないか
という課題が一つあった
としたらば 為替を見越して
自分たちの利益構造をフォーキャストし
その内容を改善するんだというアジェンダが生まれて
これを解決するというようなプロダクトが生まれる
ので そこのエピックですね
解決すべき課題の単位で管理し
そのベースのロードマップを敷きましょうというのがステップ1です
じゃあ そのエピックをどう倒していこうかというときに
広げる ティアワン以外の皆さまにも
お話を聞かせていただいて こういうふうに共通的に
倒したらいいのではないだろうかという機能仮説が生まれる
ので その機能仮説をおもとに
開発をしていきましょうというのが
機能別ロードマップというプロセスになります
これをもとに作っていきましょうというときに
優先順位に影響を与えるので
もちろんお客さまの声だったり 事業戦略だったり
様々なものが影響を与えますので ここはプロダクトの開発責任者
さっきの経営管理でシングルの人がいます
というふうに申し上げましたけれども
CSのトップとセールスのトップとで
いろんな要望だったり今のセールス状況
あとはストラテジーのトップですね 次が付き合わせて
優先順位を変えていくということは ロードマップに
縛られずに許容するというふうにしていますね
24:01
なるほど 分かりました
では今のところの続きでお話を聞きたいんですが
一旦ここで第3回目のところを終わりにして
次に移りたいと思います
いかがでしたでしょうか
今後もWebで掲載しているインタビューを
Podcastで配信していけますので 次の機会をお楽しみにしていてください
ご静聴いただきありがとうございました
