エンジニアがPdM領域に踏み込む挑戦 - 10%ルールの実践と学び -

Transcript

1. エンジニアがPdM領域に踏み込む挑戦 - 10%ルールの実践と学び - ACES, Inc. AIソフトウェア事業部 奥田 真也
2. 自己紹介 2 • 株式会社ACES • 所属: AIソフトウェア事業部 • ポジション: ソフトウェアエンジニア ◦ フロントエンド領域のテックリード • 最近の活動 ◦ TSKaigi 2025の運営スタッフ ◦ https://2025.tskaigi.org/ 奥田 真也 （X: @masaya_okuda）
3. 宣伝 3 • エンジニアリングだけでなくチー ム開発やプロダクトとの向き合 い方についても ◦ プロダクトエンジニアってなん だろう？ ◦ エンジニアはなぜビジネスを 学べと言われる？ youtubeでエンジニア向けのラジオを配信しています！（@dialog-radio） よかったらご視聴ください👍
4. 4 CONFIDENTIAL AI研究と社会実装をリードする東大松尾研究室メンバーを中心に創業。 AIアルゴリズムという独自の視点から事業を創出 東大松尾研AIスタートアップ …
5. 5 CONFIDENTIAL 活用が困難だったお客様とのやり取りをデータベース化し、 営業力を強化する活動に活用できる営業支援AIツールです。 ACES Meetとは お客様とのやり取り お客様とのやり取りをDB化･活用する 営業支援AIツール 営業力の強化 DB 人材育成・OJT 商談記録･引継ぎ 勝ちパターン 活用
6. フルサイクルエンジニアが多く所属するチーム 6 • ほとんどのエンジニアがフルスタック • 仕様整理から設計、実装、テスト、リリース、リリース後のまで一貫して開発 チームが担当する • 開発生産性の改善を重ね、前Qと比較してPR数が1.5倍に（爆速開発） • 要件定義やデザインはPdMが事前準備
7. 生産性が高まった結果... 7 PdMがボトルネックに ...😇
8. 意思決定がPdMに集中 8 • プロダクトロードマップ等の長期的な開発スケジュールの策定/調整 • 営業からの受注シーンでの機能要望 • 既存顧客からのVoC
9. 10%ルールの導入 9 • エンジニアの毎月のリソースの10%を「エンジニア主体でプロダクト価値向上 の仮説検証」ための時間に充てる • エンジニアが主体となり、プロダクトやユーザーの課題に対してどのような打 ち手が有効かを提案し、要求定義も行う。 この実験的な取り組みを、まずは僕が3ヶ月実践しチームにFBすることに
10. 1ヶ月目: 顧客課題の把握 10 作った方が良さそうな機能はたくさんあるが、どのように優先順位を決めれば 良いんだろう？🤔 行ったアクション • プロダクトロードマップを確認し、大きな方向性を改めて理解 • 過去数ヶ月のユーザーからのお問い合わせをすべて読む • 営業、カスタマーサクセス（CS）、社内のユーザーから課題をヒアリング
11. 1ヶ月目: 顧客課題の把握 11 課題や解決策としての機能について考える際に、以下の視点で考えてみる • 短期的な価値 ◦ 目先の受注やチャーンに対して効果があるか？ • 中長期的な価値 ◦ 1年後もほしいと思うような、サービスの基盤価値を強化に繋がるか？
12. 2ヶ月目: 既存機能の価値向上 12 「MVPとしてリリースしたが、その後の改善が滞っている機能」に注目👀 ファーストリリース後、ユーザーにとって使いにくいまま他の開発に埋もれている機 能はないか？ グループの一括変更機能がない ことで、CSやCREの対応工数が 高いことがわかった
13. 2ヶ月目: 既存機能の価値向上 13 デザイナーやBizチームとUI/UXの意思決定時にはAIツールのBoltを使うことで、 実際に操作した時の動きまで含めてイメージを揃えられた！
14. 3ヶ月目: データに基づく意思決定 14 CS: 「xxxの機能がないか？ってよく相談を受けます」 僕: 「開発チームでは想定してなかったリアクション、なぜだ？🤔」 CS: 「yyyの機能をリリースした影響で、利用率が上がってます」 RedashやGAで定量分析する と、利用率が右肩上がりで増えて いることがわかった
15. 開発コストを調査 15 もともと開発コストが高く、ずっと劣後している機能だったが... 実際に調べてみると • 近い箇所の実装を直近で行なっており、コードの知識が深くなっていた • リファクタリングによって複雑性が軽減され、コンポーネントの共通利用がで きる状態になっていた わずか3日間で設計〜実装まで完了してスピードリリース！👍
16. 3ヶ月取り組んでみて 16 PdMの仕事の難しさを痛感... 「作った方が良さそうなこと」は無限にあるが、その中で優先順位やスコープを 決めるには、多くの時間をインプットにあてる必要がある。 • プロダクトロードマップなど大きな方向性を意思決定/都度調整 • 日々お問い合わせの確認 • Bizサイドとのmtgを通して情報の収集/把握/深掘り
17. エンジニアがPdM領域に越境した時の強み 17 エンジニアが課題や要求定義を深く理解できれば、以下の問いを考えることが できる • どうすればユーザーの課題を埋められるのか？ • どの選択肢が最もコストパフォーマンスが良いのか？ • 将来の開発のしやすさを考慮した際に最適な設計は何か？ エンジニアとPdMが適切に噛み合うことで、プロダクト開発はよりスピーディーに、 品質の高いものになっていくと感じた👍