プロダクトマネジメントは、フレームワークの提案や発信は進んでいる一方で、明確な「型」がまだ広く浸透しているとは言い難い領域です。だからこそPdMには、通常の視点にとどまらない、より高い視座が求められます。特に大規模かつ多層的な事業においては、既存のフレームワークをなぞるだけでは突破できない壁が存在します。

リクルートには、多様な領域で“突き抜けた強み”を持つシニアPdMが在籍しています。彼らはいかにして複雑な事象を構造化し、最適解を導き出しているのか。本連載では、社内でも一目置かれる「異能」たちの独自の思考プロセスに焦点を当てます。

「絶対に失敗できない」というプレッシャーと、リスクを回避するための強固な社内ルール。歴史があり、社会的なインパクトを持つ巨大なプロダクトほど、重厚なプロセスに縛られて開発スピードが奪われていく。多くのシニアPdMが直面するこのジレンマを、現場のエンジニアリングの知見を活かして打ち破ってきたのが、リクルートの販促領域でプロダクトデザイン責任者（VP）を務める吉田麗央です。

第3回目となる今回は、開発手法のトレンドを追うだけでなく、組織の「ルールそのもの」を再設計する独自マネジメントの背景と、それが培われるに至った若手時代の“苦い経験”に迫ります。

プロダクトマネジメントを解く「2つの軸」

――巨大なプロダクトを維持しながら、同時に変革を推し進める。そんな難易度の高い仕事において、吉田さんが最も大切にしているPdMとしての姿勢とは何でしょうか？

吉田：大前提として、僕は「組織もプロダクトのコードと同じシステムである」と考えています。だからこそ、PdMとしての態度は大きく2つに集約されます。
1つは「設計」の側面。1つの進め方に固執せず、システムアーキテクチャと組織のルール（ガバナンス）を密接に連動させること。堅牢性とスピード、相反する2つを両立させるための「最適解」を設計し続けることです。

もう1つは「実行」の側面。どれほど完璧に設計しても、現場では必ず摩擦が起きます。だからこそ、自分の役割を決めきらず、チームというシステムのボトルネックを解消する「動的な触媒」として動き続けること。

この「構造を設計する視点」と「現場の空気を動かす視点」。この2つの軸を使い分けることこそが、僕のマネジメントの根幹にあります。

「アジャイルか、ウォーターフォールか」の二元論を捨てる＜設計の視点：システムと組織の連動＞

――吉田さんは現在VPとして『ゼクシィ』や『カーセンサー』といった社会的影響力の大きいプロダクトを牽引されています。規模が大きくなるほど「堅牢なガバナンス」と「開発スピード」の両立は難しくなると思いますが、吉田さんはこうした大企業や巨大プロダクト特有のジレンマにどうアプローチされているのでしょうか？

吉田：まさにそこが、巨大プロダクトにつきまとう最大の課題です。僕は常々、システムアーキテクチャと組織のルール（ガバナンス）は密接に連動させるべきだと考えています。僕はいつも、「システムが求める堅牢性」「検証速度」という2つの変数をおき、どの領域をアジャイルにし、どの領域をウォーターフォールにすべきかという「境界線」を設計しています。具体的には、「システムの不確実性」「影響範囲とリスク」「意思決定の速度」という3つの観点を掛け合わせて判断を下します。たとえば、技術的な検証が必須でとにかく早く試すことが重要な領域なのか、それとも停止が許されない基幹領域で半年かけて合意を取るべきなのか。この掛け合わせによって、各領域に適用すべきガバナンスの解像度を調整していく。大規模開発の停滞をハックするのは、こうした「プロジェクトの構造とルールを連動させる」という論理的なアプローチに他なりません。 

この考え方が明確に活きたのが、『スタディサプリ進路（旧：スタディサプリ for School）』で大規模なデジタル化のプロジェクトを任されたときでした。当時、高校生向けに配られていた「進学事典」という分厚い冊子がありました。これをすべてデジタル化し、学校現場に導入するというミッションです。これまで紙で行っていた進路選択の授業をアプリベースに切り替えるという新しい体験を提供するもので、不確実性が非常に高い側面がありました。その一方で、学校の先生や生徒が授業で使う重要な基盤であり、絶対に失敗やバグが許されないという要件も同時に抱えていたんです。

――そうした絶対に失敗できない開発の場合、どうしてもガチガチのウォーターフォール型になり、スピードが落ちてしまいがちです。

吉田：そうなんです。普通にやれば承認フローが重くなり、開発は間違いなく停滞します。それにも関わらず、開発期間はわずか半年という難易度の高いプロジェクトでした。そこで僕は、「守るべき裏側のシステム」と「攻めるべき表側のUX」で、プロジェクトのルールを完全に切り分けることにしたんです。

具体的には、すでに存在していたWeb版の『スタディサプリ進路』のシステム資産を「API（バックエンド）」として流用しました。データベースや重要なアクションに関わる部分は、絶対にミスが許されないため、既存の厳格な承認フロー（ウォーターフォール的な管理）を適用して安全性や堅牢性を担保しました。

一方で、高校生が直接触れるアプリの「フロントエンド（UI/UX）」の部分は完全にゼロから切り離して作り、ここは「現場の検証で即断即決していく（アジャイル開発）」で進めようと。

――プロジェクトの中で、堅牢性とスピードの両立を、システム構造レベルで切り分けたのですね。

吉田：はい。堅牢であるべき領域と不確実性の高い領域で「ルールの強度」を使い分ける。いわゆるBFF（Backend for Frontend）的なアプローチですが、この構造的な工夫によって、ほとんどの関係者から不可能と思われていた半年でのリリースを実現することができました。単にスピードが速かっただけでなく、実際に学校現場で使われ、生徒や先生から「授業がスムーズになった」「進路選びが楽しくなった」といった喜びの声を多数いただけるような、品質の高いプロダクトに仕上げることができました。

天狗だった若手時代。衝突を経てたどり着いた「チームの成果」を最大化する思考

――吉田さんはエンジニア出身ですが、そうした「システム構造と組織ルールをリンクさせる発想」は昔から得意だったのですか？

吉田：裏側の仕組みを理解しているからこそ「ここは切り離せる」と判断できたのは、間違いなくエンジニア出身であることの強みですね。ただ、最初から今のような考え方や立ち回りができたわけではありません。むしろ若手時代は、かなり尖っていて……いわゆる「天狗」になっていました（笑）。

英語学習プロダクトの開発に関わっていた若手の頃、自分より年上のシニアエンジニアが10人ほどいるチームでディレクター的な動きをしていました。当時の僕は「自分が一番イケてる。自分が考えるプロダクトこそ最高だ」と本気で思っていたんです。     自分が「正しい」と思うことを先輩たちにもストレートにぶつけて、とにかく激しく衝突していました。「ホームランバッター」として、自分一人で成果を出そうとしていたんですね。

――そこからどのようにして、現在のスタイルへと変化したのでしょうか？

吉田：一方的に自分がやりたいことを押し付けても、周囲は気持ちよく動いてくれないし、結果的にプロダクトは一歩も前に進まないという現実に直面したんです。英語学習プロダクトでは結局自分が空回りしてしまいました。
その後、別のチームに異動するのですが、そのチームはもっと規模が小さく、エンジニアやデザイナーとの距離感がとにかく近い環境でした。そこで得られたのは、「自分の価値観を一方的に押し付けていた」という強烈な反省でした。
コミュニケーションを重ねていく中で、「それぞれに想いや背景がある」という当たり前のことに気づかされたんです。自分が英語学習プロダクトを作っていたときを振り返ると、「自分の想い」や「なぜこれをやるのか」というコンテキストを周囲に全く伝えられていなかったことに気が付きました。

そこで、やり方を180度変えました。毎朝「デイリースクラム（朝会）」を開き、エンジニアやデザイナー全員でKPIを見るようにしたんです。やりたいことをただ一方的に伝えるのではなく、「今どんな課題があり、この機能がビジネスにどう貢献するのか」を共有しました。すると、チームメンバーから出てくる言葉や意見がビジネスゴールに沿ったものに変わってきたんです。

――チーム全体の視座が一段上がったのですね。

吉田：さらに、エンジニアやデザイナーを帯同して、高校などのクライアント先に直接訪問する機会を増やしていきました。自分たちが作ったものを実際のユーザーがどう使っているか。「生徒は喜ぶかもしれないけど、これでは先生は動かないよね」といったリアルな課題を目の当たりにすることで、アウトプットの質が「自分の理想やエゴを詰め込んだもの」から「ユーザーにとって価値があるもの」へと劇的に変わったんです。この原体験が、今のマネジメントのベースになっています。

「主役」を降り、チームの「足りないピース」になる＜実行の視点：摩擦の解消と動的なチーム運用＞

――設計したシステムが正しく機能し続けるためには、運用の視点も不可欠ですね。

吉田：そうですね。設計した理想と、現場で生じる現実。このギャップを埋めるのがPdMの腕の見せ所です。2つ目の「実行」という側面において、僕が意識しているのは、現場で生じる摩擦を解消し、チームが最大限に力を発揮できるようにすることです。ただ、最初から今のような立ち回りができたわけではありません。若手時代は、かなり尖っていましたから（笑）。

――若手時代の挫折から大きな視座の転換があったのですね。数々の大規模プロジェクトを経て、吉田さんが考える「PdMの真の価値」とは何でしょうか？

吉田：チームというシステムが最大出力を出すために、自らの役割を柔軟に変化させ続けることだと思っています。だからこそ、若手時代のように自分が「主役」になりたいとは考えていません。ビジネスサイドと開発現場で言葉が通じていなければ「翻訳者」になり、意思決定が滞っていれば「触媒」になり、利害が対立していれば「バッファ（緩衝材）」になる。リアルタイムでチームの「足りないピース」を見つけ出し、自分自身をそこにはめ込んでいくような感覚です。PdMの仕事とは、固定された役職をこなすことではなく、その時々のシステム（チーム）のボトルネックを解消するための「動的な触媒」となることなのです。

――現在取り組まれている『カーセンサー』の巨大刷新（リビルド）でも、そうしたチームを活かす立ち回りは実践されているのでしょうか？

吉田：もちろんです。『カーセンサー』は熱狂的なファンも多く、会社として大きな売上に直結する巨大なプロダクトです。ここでも、『スタディサプリ』の時と同様に「安全性・堅牢性と、不確実性へのチャレンジという相反する要素をいかに両立させるか」がテーマになっています。

これを一気に作り変えるのはリスクが高すぎるため、リスクを抑えつつ新しいチャレンジをするアプローチをとっています。具体的には、全く新しい体験を新しいアプリとして実装し、既存アプリと競わせながらUXを磨いていく。そして、遜色ない体験品質になった段階で統合していく、というプロセスを踏んでいます。

この大がかりな仕掛けを動かす上で、今の僕がチームに強く求めているのは、既存の常識を一旦外して、ゼロベースで柔軟に考えることです。長く運用されてきたシステム環境にいると、どうしても「今のシステムでは無理だ」という制約から入りがちですから。また、いざ実装フェーズに入れば、エンジニアリングの知見を総動員して、極めて泥臭く緻密に設計やステークホルダーとの折衝を行います。「発想の飛躍」と「実装力の泥臭さ」が両立して初めて、巨大組織に新しい仕組みを根付かせることができるんです。

――そうした開発手法が可能なのも、さまざまなアイデアや尖ったスキルを持った人材が集まるリクルートならではと言えるでしょうか？

吉田：そう思います。実際、僕自身もここは人並み以上にできるけれど、ここは驚くほどできないという凹凸を抱えています（笑）。でも、リクルートにはそうした個人の「デコボコ」を許容し、強みを掛け合わせる文化があります。僕が今VPとしてやるべきことは、自分がホームランを打つことではなく、多様なスペシャリストたちが互いの背中を預け合い、全力でバットを振れる「土壌」を作ることだと思っています。

——最後に、吉田さんの考えるこれからのプロダクトマネジメントについて教えてください。

吉田：開発手法のトレンドをただ追うだけのフェーズは、とうの昔に終わりました。それは、トレンドを知っていることや新しいツールを導入すること自体が、もはやゴールではないからです。
もちろん、技術的なトレンドを追うこと自体は今でも重要です。特にAIの進化は日進月歩なので、常にアンテナを張っておく必要があります。ただ、AI活用のハードルが下がったことで、誰でもさまざまなツールを使い、短時間でアウトプットを出せるようになりました。その結果、ツールや使い方が乱立し、アウトプットの品質や判断基準がばらつきやすくなっているとも感じています。
AIは良くも悪くもレバレッジです。良い問いや良いプロセスに乗れば価値創出を加速しますが、曖昧な課題設定や不十分な検証プロセスに乗ると、質の低いアウトプットや誤った意思決定も同じように加速してしまいます。だからこそ、AI時代には、アウトプットの品質を担保する土台づくりがこれまで以上に重要になると考えています。
また、AIによって一人あたりの業務スピードが上がると、これまで複数人で動くことを前提に設計されていた業務プロセスが、逆に足かせになることがあります。作業そのものよりも、ドキュメントのありかを探す、誰に確認するかを探す、承認を待つといったことの方が時間を使ってしまう場面が増えるからです。
そのため、AI時代には、これまでの当たり前を疑い、プロダクトや組織のあるべき構造に合わせてルールやプロセスを再設計できる人材が求められていると思っています。
『ゼクシィ』や『カーセンサー』のような、社会に巨大なインパクトを持つ領域だからこそ、ルールごと再設計して「ゲームチェンジ」を起こすダイナミズムが味わえます。自らの手で組織を動かし、未踏の領域でフルスイングしたいと思う方と、一緒に働けることを楽しみにしています。

▼ご興味のある方はこちら（吉田 麗央 - LinkedIn）
https://www.linkedin.com/in/reoy/