【Developers Summit 2025】 プロダクトエンジニアから学ぶ、 ユーザーにより高い価値を届ける技術 取締役CTO 丹羽健

主催 理事 丹羽 健 (Niwa Takeru) 取締役 CTO @niwa_takeru ＜ フォローお願いします！

3 3

私の開発への興味の変遷 ■ 大学院・研究室 研究の一環で10万Step規模の CADアプリケーションを独自開発 ■ 高校・大学時代 高校時代に情報系への興味から 自分で本を買ってプログラミング 4 4 明解C言語 入門編 柴田望洋 https://amzn.asia/d/2QWf5pL プログラミング って楽しい！ 複雑なアプリ開発は 難し過ぎる面白い

5 私の開発への興味の変遷 5 しかし…。 システム開発という関心だけでは 誰も幸せにならないのでは。 という問いだけが残った。 ■ 新卒 SIer 時代 １年弱におよぶ炎上案件を経験。 なんとか生き残り機能をリリース システム開発は大変。 ただ、これが 仕事というものか...? 仲良かった複数のメンバーは病み プロジェクトから離脱 そして、リリースした機能は 利用者のニーズを捉えておらず 全く利用されない

6 私の開発への興味の変遷 6 ■ 新規事業・プロダクト開発案件 飲食店向けの業務SaaSの新規開発案件に従事 全員が顧客志向で関係性も生産性も良いチーム 丹羽自身は２つの新規プロダクトの 中核メンバーとして立ち上げ事業化 着実に人を助ける プロダクトを 作れている 実際の飲食店に出向き ユーザーが使えるまで 徹底的に機能を磨き込む プロダクト開発 良い仲間と 良いプロダクトを作る経験 このプロダクトエンジニアリングの経験が 現在のスタートアップ CTOのキャリアに繋がる

プロダクトを通じて 顧客課題を解決すること その対価としてお金を受け取り、事業を営む 7 7

価値あるプロダクトを 作ることは、 エンジニア自身の幸せを 守ることでもある。 8 8 と、私は考えています。

プロダクト志向を 中心とした開発とは...? 9 9

No content

No content

12 12

海外では2018年より言われ始める 13 プロダクトエンジニアとは 13 “ Over my last ten years of product management, I’ve come to conclude that product engineers are a critical ingredient to helping you build a successful product, scale yourself and become a better product manager. 過去10年間のプロダクトマネジメントを振り返ってみると、 プロダクトエンジニアは 成功するプロダクトを構築し、自己拡大を遂げ、より良いプロダクトマネージャーに なるための重要な要素である という結論に至った。 https://sherifmansour.medium.com/product-engineers-f424da766871 Sherif Mansour: Atlassian, Product Manager 2018/12 Product engineers “ Most startups are looking for Fullstack Engineers but actually need Product Engineers. The best Product Engineers share two common qualities: 1. passion for building high-quality experiences 2. constant drive to learn and explore new ideas 多くのスタートアップはフルスタックエンジニアを求めていますが、 実際にはプロダクトエンジニアを必要としている 。 最高のプロダクトエンジニアには、共通して 2つの資質があります： 1. 高品質な体験を構築することへの情熱 2. 新しいアイデアを学び、探求することへの絶え間ないドライブ https://leerob.io/blog/product-engineers Lee Robinson: Vercel, VP of Product 2023/08 Product and Platform Engineers 国内では2023年の記事発信を機に 職種として設定する企業が拡大

14 14

■ エンジニア 「CSV読込時間が長く掛かるので 　非同期にしたらいいのでは？」 ■ デザイナー 「CSV読込は進捗率を表示して 　体感時間を軽減させたい。」 ■ プロダクトマネジャー 「そもそもCSV読込は利用頻度が 　低いので拘らなくてOK」 コミュニケーションの不足や 専門性・情報量の差によって 本来創れたはずの価値を逃す 15 領域の狭間で失われる価値 15 Technology Business UX Design

16 開発プロセスの狭間で失われる価値 16 この難しい仕様 誰が考えたんだよ… 顧客状況的に この仕様とせざるを 得ない… 仕様を紐解くだけで 精一杯 お客さんは どう使ってるんだろう めちゃくちゃ サポート工数が かかる仕様になってる 自分が作っていないから 何か起きてもすぐには 分からない

17 プロダクトエンジニアの３領域 17 Technology Business UX Design 機能開発の全体にオーナーシップ ● Technology ○ １機能を単独で実装できる技術力（フルスタックさ ○ 技術力ゆえのソリューションの多様さ ○ 検証イテレーションを早く回す開発生産性 ● UX Design ○ 仮説検証、Lean開発、仕様策定 ○ 顧客体験のデザイン、OOUI、情報アーキテクチャ ● Business ○ 高い解像度での顧客理解・ドメイン理解 ○ 事業・KPI・ビジネスモデル Technology 外の領域へ越境する価値 プロダクト価値の減衰は領域の狭間で発生する。 ３領域の制約を１人格で理解することで、 一人の思考の中で全体最適が進み開発速度が向上 イテレーション

18 プロダクトエンジニアのコンピテンシー 18 課題解決に対する強いオーナーシップ 顧客課題の解決を自分事とするが故の 最高の体験の創出、領域を越境した個の成長 ● 越境とキャッチアップ ○ 技術を課題解決の為のツールと看做す ○ 実践的で目的意識のある技術学習 ● 探索的かつ迅速な仮説検証サイクル ○ プロダクト開発の不確実性を前提 ○ 全てを仮説と捉え検証に基づく学び ● Unlearn を受け入れるコミュニケーション ○ 課題解決を中心とした素直さ ● ドメインや事業に対する好奇心 ○ 努力する人は夢中な人に勝てない 越境と キャッチアップ アンラーンと コミュニケーション Product Engineer 迅速な 仮説検証 ドメインに対する 好奇心 課題への オーナーシップ

No content

No content

イメージアップ アセンドで活躍するプロダクトエンジニア 21 21

労務や請求管理などの 複数プロダクトを立ち上げ ● 当初からドメイン駆動設計が好きであり 顧客や産業の知識がプロダクト開発の 源泉としてキャッチアップ ● オーナーシップを推進力とし 立ち上げを担当 22 萌花：オーナーシップ 22 越境と キャッチアップ アンラーンと コミュニケーション Product Engineer 迅速な 仮説検証 ドメインに対する 好奇心 課題への オーナーシップ

23 坂本：ドメインへの好奇心 23 越境と キャッチアップ アンラーンと コミュニケーション Product Engineer 迅速な 仮説検証 ドメインに対する 好奇心 課題への オーナーシップ 24年10月入社。顧客と共に 車両管理プロダクトを立ち上げ中 ● 元UXリサーチャーのスキルを元に 顧客訪問を積極的に進め課題ヒアリング ● Figmaを使いモック画面を作成 迅速な仮説検証を推進

24 24

Four Keys 優秀な指標なので、指標改善を 愚直に進めるだけでも効果がある ● デプロイ頻度 ● 変更リードタイム ● 平均修復時間 ● 変更失敗率 デザインモックを利用する Figmaやパワポを利用し、実装前 に顧客からフィードバックを得る Feature Flags を利用する 開発途中や全体公開前に 一部顧客に対して先行公開する。 未完成品のハレーションを下げる と共に早期にFBを得る。 25 25 越境と キャッチアップ アンラーンと コミュニケーション Product Engineer 迅速な 仮説検証 ドメインに対する 好奇心 課題への オーナーシップ 検証の２つの ”はやさ” を上げる 顧客検証を早める 実装を速める

26 仮説・課題を再定義する 26 顧客や皆の固定観念から生まれたそれはそう Solution を 課題の再定義で Wow へ乗り越える ● 課題の再定義ステップを明示的に入れることで、 固定観念を振り払い、プリミティブな課題に定義し直す ● 本質的かつエレガントな課題解決 ＝ Wow Solution へと繋げること ● 技術の専門職として、 小さくまとまった考えに対して 技術の天井をアンロックさせる 越境と キャッチアップ アンラーンと コミュニケーション Product Engineer 迅速な 仮説検証 ドメインに対する 好奇心 課題への オーナーシップ 再定義 屈伸 プロダクトエンジニアの介在価値

27 自身が開発した機能に対して顧客の声を聴く 27 現場訪問はリリース後の方が学びに効く リリース後に実際に (使われている|使われていない) 現場 を見ることで、自身の立てた仮説の不確かさを痛感する。 ● アンラーンとは、これまでの知識や前提を一度手放し、新しい学び を受け入れるプロセス。脱学習や学びほぐしと呼ばれる。 ● 「正しいと思っていたこと」を疑い、ユーザーの声や実データから 最適な解を導くことで、より良いプロダクト開発につながる。 越境と キャッチアップ アンラーンと コミュニケーション Product Engineer 迅速な 仮説検証 ドメインに対する 好奇心 課題への オーナーシップ Unlearn: Let Go of Past Success to Achieve Extraordinary Results Barry O'Reilly (2018) 最近、翻訳版が出たので組織マネジメントに興味がある方はぜひ。 アンラーンとは何か？

28 ドメイン駆動設計を活かす 28 プロダクト（課題解決）の根源はドメインである プロダクト開発の本質は、特定の業界・業務の課題の解決 ドメイン（業務領域）の理解が深まるほど、顧客価値あるプロダクトへ デザイン・プロダクトマネジメント・ビジネスの領域へ越境するとき、 業務フロー理解や共通言語（ユビキタス言語）という点で助けとなる。 ● デザイン：UX/UX設計時に「この業務ではどの情報が重要か？」 ● プロダクトマネジメント：機能の優先順位を決められる。 ● ビジネス：競合や商談での差別化ポイントを明確化する 越境と キャッチアップ アンラーンと コミュニケーション Product Engineer 迅速な 仮説検証 ドメインに対する 好奇心 課題への オーナーシップ ドメイン知識が プロダクトエンジニアの越境を助ける

デザイン・ビジネスをキャッチアップすることで、 より価値の高いプロダクトを生み出す ● 各専門家とのコラボレーションの実現 ○ 相手の知識・共通言語を持つことで 速やかに本質的な議論をできる ● 技術との知識の掛け算 ○ 掛け算により発想の幅を広げ、 効果的なソリューションを生む 29 他領域への越境とキャッチアップ 29 越境と キャッチアップ アンラーンと コミュニケーション Product Engineer 迅速な 仮説検証 ドメインに対する 好奇心 課題への オーナーシップ Technology Business UX Design 越境の目的は何か？

30 🎨 デザインへの越境とキャッチアップ 30 ● デザインの多くは実はロジックで語ることができる。 ● プロダクト価値のラストワンマイルは UI/UX 。 Technology Business UX Design カテゴリ キャッチアップ内容 キャッチアップの伝手 Product 価値への寄与 タイポグラフィ＆ スペーシング ✅Font Size 基準の余白設計 ・em（文字高さベース）のサ イズ指定 視認性・可読性を向上し、 統一感のあるUIを実現 UI設計論 ✅ OOUI（オブジェクト指向UI） ✅ Fパターン / Zパターン ・書籍『オブジェクト指向 UI』 ・書籍『Form Design Pattern』 直感的な操作性を実現 ユーザーの離脱を防ぐ 情報設計 ✅ 情報アーキテクチャ (IA) ・既存プロダクトのIAを分解 ・ユーザーテストを実施 必要な情報を適切に整理 し、UXを改善

31 ⛰ プロダクトマネジメントへの越境とキャッチアップ 31 ● プロダクトの優先度を判断し、価値を最大化する ● 顧客課題の発見から仮説検証まで、 価値が創られるプロセスを理解し、より良いプロダクトを Technology Business UX Design カテゴリ キャッチアップ内容 キャッチアップの伝手 Product 価値への寄与 ロードマップ策定 ✅ 長期・短期の機能計画 ✅ 技術負債の管理 ・RMは結果よりも 　策定過程に学びがある 持続可能な開発計画を立 て、チームやアーキテク チャの一貫性を維持 ユーザーリサーチ インタビュー ✅ 課題の深掘り ✅ 仮説検証の設計 ✅ Minimum Viable Product ・商談や現場訪問に同席 ・書籍『Lean Startup』 ユーザーの本質的課題を 理解、開発の無駄を削減 顧客業務フロー ✅ 主要な業務プロセス ✅ 業務上のボトルネック把握 ✅ 法律や業界標準 ・フローチャート作成 ・Customer Successと議論 ・法律は公式Document ユーザーの実際の課題に 基づいたプロダクト設計が 可能に

32 📈 ビジネスへの越境とキャッチアップ 32 ● プロダクトは事業があるから顧客に届く ● ビジネス構造を理解し、より多くの顧客課題解決を Technology Business UX Design カテゴリ キャッチアップ内容 キャッチアップの伝手 Product 価値への寄与 事業戦略 事業ビジョン ✅ 企業が実現したい 　 ミッション・戦略 ・自社の事業戦略資料 ・経営陣の発信内容理解 開発が短期的なタスクにな らず、事業成長に直結した 開発判断ができる ビジネスモデル マネタイズ / KPI ✅ SaaS / Platform モデル ✅ バリュープロポジション ✅ 各種KPI (ARR / LTV / CAC) ・SaaSビジネスのKPI ・IR資料 ・BizDev との議論 収益に直結する機能や改 善施策を優先、プロダクト の持続可能性を高める 業界・市場 競合分析 ✅ 業界動向 / 商慣習 ✅ 競合プロダクトのリサーチ ・業界誌/ホワイトペーパー ・ ・カスタマレビュー 変化の激しい市場へ適応 長期的に競争力のあるプ ロダクトを開発できる

33 システム思考でプロダクトを考える 33 プロダクトは単なる機能の集合ではなく、 ユーザー・ビジネス・技術の関係性が絡み合う「システム」 越境と キャッチアップ アンラーンと コミュニケーション Product Engineer 迅速な 仮説検証 ドメインに対する 好奇心 課題への オーナーシップ ポイント ポイントの概要 具体例 全体最適を考える 機能単体ではなくシステム全体、さ らに顧客の業務フロー全体への影 響を考慮 ✅ 新機能追加 → 他のUXに影響は？ ✅ 費用削減 → 長期的な開発コストは？ フィードバックループ を意識する 機能改善による副次的（特にネガ ティブな）影響の波及を考える ✅ ユーザー増加→サーバー負荷増→UX低 下 ✅ 価格変更 → 利用率変化 → 収益変動 レバレッジポイント を見つける 小さな改善で大きな変化を生む部 分を特定する ✅ API最適化 → 複数機能の高速化 ✅ ボトルネックの特定 時間軸を考慮する 短期的な利益 vs. 長期的な成長の バランスを取る ✅ 技術負債を減らす設計 ✅ MVP開発と拡張性のバランス

アセンドで活躍する プロダクトエンジニア達 34 34

MISSION 物流の真価を開き、 あらゆる産業を支える。 トラック運送会社向けに All-in-One SaaS ロジックスを開発

36 物流の紹介 36

37 37

38 38

39 39

40 40

41 41

42 ロジックスの紹介 42

43 トラック運送会社のデジタル化・顧客課題解決 43

No content

組織としてのプロダクト開発力の最大化を目的 ● 事業・マーケット全体を俯瞰整理して、 優先すべき顧客課題（ミッション）を策定 ● メンバーが作る仕様（ソリューション）の水準を 引き上げ、プロダクトとして満たすべき品質を担保 ● メンバーを育成し、組織のプロダクト開発力を向上 ● 開発機能に対してオーナーシップを持ち、 関係者を巻き込み頼りながら顧客へ価値を提供する 45 Product Management 各役職の責務 45 L M L M PM M Product Manager: 機能ミッションの策定 Lead PdE: 仕様品質の担保・メンバー育成 Member PdE: 仕様策定・機能開発の推進

46 プロダクトエンジニアの為の開発生産性への投資 46

47 プロダクトエンジニア組織が活躍するアーキテクチャ 47 検証ス ード Product Engineer 顧客理解 ドメイン理解 課題への オーナーシップ ● 顧客期待を超える機能には個人の熱量が最重要 ● 開発サイクル全体を担当しオーナーシップ醸成 ● ● SaaSとして顧客・業界理解の解像度を重視 ● 課題整理とソリューションの質の土台 ● 仮説検証のスピードが、事業成長の源泉 ● スピードが速い＝フィードバックの密度が高い 集中的に機能改善に取り組むことができる 課題へのオーナーシップ 顧客理解、ドメイン理解 検証スピード 組織をアーキテクチャとして考え、 ３要素を高めるために多面的な施策を実行する

48 プロダクト価値を高める施策 48 顧客理解 仕様策定 設計/実装 リリース 顧客サポート オーナー シップ ・現場訪問 ・PMロール ・PRD ・Lead PdE ・Full Stack TS ・ChatOps ・領域担当 顧客理解 ・商談動画/同席 ・顧客Channel ・全社共有会 ・VoC ・Backlog ・TS/DDD ・Redash ・繁忙期理解 ・依頼Channel 検証 スピード ー ・要望Channel ・Prototype ・Full Stack TS ・開発生産性 ・ChatOps ・Feature Flag ・Sentry フルサイクル開発 トランクベース開発 　　　で顧客課題からリリースまで管理

顧客理解 仕様策定 設計/実装 リリース 顧客サポート オーナー シップ ・現場訪問 ・PMロール ・PRD ・Lead PdE ・Full Stack TS ・ChatOps ・領域担当 49 オーナーシップを高める 49 ● アセンドでは入社オンボーディングで 各地域の運送会社様の現場を訪問 ● 課題の重要性を全身で感じ熱量を上げる ※顧客理解はオンラインの 　商談同席で数を重視 現場訪問で熱量を上げる ● 自身が最良と納得したものを 開発することのオーナーシップの強さ ● リードPdEは品質の底上げの手伝い 各メンバーが仕様を作る体制 自身が策定した仕様を実現する L M フルサイクル開発

顧客理解 仕様策定 設計/実装 リリース 顧客サポート オーナー シップ ・現場訪問 ・PMロール ・PRD ・Lead PdE ・Full Stack TS ・ChatOps ・領域担当 50 オーナーシップを高める 50 ● TypeScriptで言語統一し、 １エンジニアがフルスタックしやすく ● 技術的な分断によるサイロ化を阻止 ● 開発生産性の向上の効果も大きい Full Stack TypeScript ● プロダクト開発プロセスの全体に オーナーシップを持つフルサイクル開発 ● ChatOpsでSlackから15分でリリース 自分が作った機能を顧客に自分が提供し 顧客への価値提供の実感が醸成される フルサイクル開発 & ChatOps フルサイクル開発

● 商談/課題ヒアリングの動画を データとして蓄積し誰でも参照可能に ● 顧客ごとのSlack Channelで 背景情報も収集可 ● 週次の全社共有会で、 事業状況や重要顧客を確認 顧客理解 仕様策定 設計/実装 リリース 顧客サポート 顧客理解 ・商談動画/同席 ・顧客Channel ・全社共有会 ・VoC ・Backlog ・TS/DDD ・Redash ・繁忙期理解 ・依頼Channel 51 顧客理解を高める 51 顧客情報・事業状況の透明性 ● TypeScriptでのドメイン駆動開発を推進中 ● プロダクトエンジニアだからこその コードへの再現性の高さがある ※TS強化ロードマップ 　登壇資料はこちら👉 ドメインを表したコードを保つ 　　　で顧客課題からリリースまで管理

顧客理解 仕様策定 設計/実装 リリース 顧客サポート 顧客理解 ・商談動画/同席 ・顧客Channel ・全社共有会 ・VoC ・Backlog ・TS/DDD ・Redash ・繁忙期理解 ・依頼Channel 52 顧客理解を高める 52 ● プロダクト開発のために作られた チケット管理 SaaS Linear で顧客課題を管理 ● チケットの操作体験も格段に良く Slack, GitHub 連携のシームレスさは抜群 機能に関する情報を Linear に集約。 ● Linearはいいぞ。 　　　　　で一気通貫に管理 　　　で顧客課題からリリースまで管理

顧客理解 仕様策定 設計/実装 リリース 顧客サポート 検証 スピード ー ・要望Channel ・Prototype ・Full Stack TS ・開発生産性 ・ChatOps ・Feature Flag ・Sentry 53 検証スピードを高める 53 ● 改善要望をSlack Channel上に起票し 日常的に要望を見れる状態に ● 最短8分でリリースできるDevOps基盤 ● Streamingで改善を実行 要望チャンネル x 日時デプロイ ● Feature Flag を利用し機能の限定公開 特定顧客のみで事前に検証を実施 ● トランクベース開発により 検証から全体公開までの流れが滑らか Feature Flag & Prototype トランクベース開発 顧客要望を受けて20分で改善した事例も

54 プロダクト価値を高める施策 54 顧客理解 仕様策定 設計/実装 リリース 顧客サポート オーナー シップ ・現場訪問 ・PMロール ・PRD ・Lead PdE ・Full Stack TS ・ChatOps ・領域担当 顧客理解 ・商談動画/同席 ・顧客Channel ・全社共有会 ・VoC ・Backlog ・TS/DDD ・繁忙期理解 ・依頼Channel 検証 スピード ー ・要望Channel ・Prototype ・Full Stack TS ・開発生産性 ・ChatOps ・Feature Flag ・Sentry フルサイクル開発 トランクベース開発 　　　で顧客課題からリリースまで管理

No content

56 56

57 コミュニティ・勉強会に関して 57 プロダクトエンジニアが学び繋がる コミュニティ・勉強会を開催 1. 15分のセッション発表 2. グループディスカッション 3. 懇親会

■ 各界での開催テーマ #1 Minimum Viable Product #2 DomainへのDeep Dive ! #3 プロダクトの0→1開発秘話 #4 ドメインのキャッチアップ #5 プロダクト志向の 　 組織・カルチャー形成 #6 プロダクトエンジニアを 　 育む仕組み・施策 58 過去の開催内容 58 ⛈ 第１回から 順調に拡大し 100名超の参加 🎉

59 今後の予定 59 次回、 2月21日(金) 開催 📣 プロダクトエンジニアに 興味を持った方、ご参加ください！ 〜 LTテーマ 〜 1. プロダクトエンジニアの経験の成長編 2. 価値を創る技術・プロセス編 3. プロダクト志向な組織形成

Message

61 61

Summary 62 CTO 丹羽 の 𝕏 (@niwa_takeru) お気軽にフォローください。 プロダクトを社会に実装していこう！ ● プロダクト志向を持って 顧客課題の解決を中心とした開発へ ● 技術・デザイン・事業の３領域を 積極的に越境して価値を最大化する ● オーナーシップとドメインへの好奇心を 大切にしてプロダクト開発を楽しもう

No content