営業・CSを「開発の当事者」にする～少人数チームで複数プロダクトを動かすDev<>Ops連携の方法～

by yama-cha-n

Embed

Start on current slide

Slide 1

Slide 1 text

Product Engineering Conference 2026 営業・CSを「開発の当事者」にする少人数チームで複数プロダクトを動かすDev<>Ops連携の方法山本龍平北村大助 © estie Inc. 1

Slide 2

Slide 2 text

自己紹介経歴 2022/04 - 2025/01 株式会社SHIFT 新卒でQAエンジニアとして品質保証に従事プロジェクトリーダーとして活動 2025/02 - 現在株式会社estie QAエンジニアとしてjoin 現在ではフルスタックに開発に携わる estieでやっていること Ryuhei Yamamoto 株式会社estie / エンジニアいいプロダクトを作るために必要なこと全般・事業開発・要件定義・開発・テスト・運用趣味ゲーム作り © estie Inc. 最近始めたエックス↑ 2

Slide 3

Slide 3 text

自己紹介経歴 2022/03 – 2024/03 東京大学在学中、長期インターンとして株式会社estieの事業に参画。 2024/04 – 現在株式会社estie カスタマーサクセスとして新卒入社 estieでやっていること顧客要望を叶えること全般・サクセスプランの立案・推進・データ分析・レポート作成 Daisuke Kitamura 株式会社estie / カスタマーサクセス趣味運動全般（ゴルフ、テニス、スノボー、筋トレ等） © estie Inc. 3

Slide 4

Slide 4 text

アジェンダ 01 AI時代、Devの役割はどう変わる？ 02 AI時代、Opsの役割はどう変わる？ 03 Dev<>Opsで「何を作るか」を決める仕組み 04 仕組みを支える技術的な取り組み 05 職種の境界はどのように変わっていくのか © estie Inc. 4

Slide 5

Slide 5 text

0 会社紹介 © estie Inc. 5

Slide 6

Slide 6 text

株式会社estieの会社概要 © estie Inc. 6

Slide 7

Slide 7 text

株式会社estieの事業内容 © estie Inc. 7

Slide 8

Slide 8 text

株式会社estieは欲張りな会社です © estie Inc. 8

Slide 9

Slide 9 text

私たちの前提：少人数 × 複数プロダクト少人数のまま複数プロダクトを伸ばし、高収益を目指すことに挑戦している複数プロダクトを兼務沢山のミドルウェア高い利益率一般的な組織私たちの選び方職種ごとに分業する JDを越えて兼務する JDの内側で最適化する越境することが推奨される越境が、Dev<>Ops連携の前提になっている © estie Inc. 9

Slide 10

Slide 10 text

1 AI時代、Devの役割はどう変わる？ © estie Inc. 10

Slide 11

Slide 11 text

「作ること」の希少性は下がりつつある AIで実装速度が上がり、Devの価値は「コードを書く」ことだけでは決まりにくくなった BEFORE NOW 実装コストが高い AIで実装コストが下がる作れること自体が価値「何を作るか」の重要性が上がる間違ったものを速く作るリスクも増えた © estie Inc. 11

Slide 12

Slide 12 text

Devの役割は「事業を作る」側に広がる顧客課題を理解し、「何を作るか」を決め、売上まで考える 01 02 03 04 05 商談に出る Opsと課題を議論する POCを作る顧客に当てる利用・売上を見る「どう作るか」だけでなく、「何を作るか」に踏み込む © estie Inc. 12

Slide 13

Slide 13 text

Devの役割は「事業を作る」側に広がる実例顧客課題を理解し、「何を作るか」を決め、売上まで考えるある機能のリニューアルで、日常的に回しているサイクル 01 商談に出る読む 02 03 04 商談議事録やVoCを片っ端から読み込む聞く商談に5回以上同席し、顧客の課題感を直に整理 05 POCを作る顧客に当てる利用・売上プロトタイプを作り、顧客に直接ヒアリング（これも5社くらい）試す Opsと課題を議論する届ける Opsと連携し、利用確度の高い顧客へリリース磨く利用ログとVoCを聞きながらプロダクトを改善を見る「どう作るか」だけでなく、「何を作るか」に踏み込む「商談議事録を読む」「商談に同席する」は、社内では当たり前 © estie Inc. 13

Slide 14

Slide 14 text

Devの役割は「仕組みを作る」側にも広がる自分が速く作るだけでなく、チーム全体が速く試せる仕組みを作る検証をより高速に PoCをより簡単にデータ分析をより柔軟に自分が作るのではなく、「みんなが作れる状態」を作る具体的な話は第5章で詳しくお話しします © estie Inc. 14

Slide 15

Slide 15 text

2 AI時代、Opsの役割はどう変わる？ © estie Inc. 15

Slide 16

Slide 16 text

「開発」はDevの専売特許ではなくなった AIの登場で、開発のために必ずしもコードを書ける必要はなくなった BEFORE NOW 開発はDevだけの仕事 Opsも開発ができるコードを書けることが前提コードはAIが書いてくれる Opsも「開発をする」時代の到来 © estie Inc. 16

Slide 17

Slide 17 text

Opsの役割は「作って確かめる」側に広がる要望を伝えて待つのではなく、自ら作って顧客にぶつけ、磨き込む 01 02 03 04 05 顧客の声を聞く AIでモックを作る顧客に当てる改善を重ねる Devにパスする「あとはほぼ実装するだけ」の状態でDevへ渡す © estie Inc. 17

Slide 18

Slide 18 text

Opsの役割は「作って確かめる」側に広がる実例要望を伝えて待つのではなく、自ら作って顧客にぶつけ、磨き込むある顧客の「継続提案」で、いま実際に回しているサイクル 01 顧客の声を聞く聞く 02 03 04 05 「今の機能のままでは、使い続けるのは難しい」と率直な声作る「こうなれば使いたい」という要望をもとに、AIでモックを作る顧客に当てる改善を重ねる商談でモックを見せ、解約の検討から継続の検討へ当てるAIでモックを作る Devにパスする磨く継続となれば、その顧客とすり合わせながら改善を重ねる渡す磨き込んだものを、本体サービスへの実装としてDevにパス「あとはほぼ実装するだけ」の状態でDevへ渡す「要望を伝えて待つ」だけなら、解約で終わっていたかもしれない © estie Inc. 18

Slide 19

Slide 19 text

Opsの役割は「開発を知り、つなぐ」側にも広がるモック作成までいかずとも、開発の現場を知ることで「集めるべき声」が変わる定義すべき要件がわかる拾うべき顧客の声がわかる Devと同じ言葉で話せる「要望を渡す」から、「開発に効く声を届ける」へ © estie Inc. 19

Slide 20

Slide 20 text

私の事例：タッグ開発 Nightで、Devと一緒に機能を作った要望を伝える側だったOpsが、Devとタッグを組んでAIで自ら機能を実装したタッグ開発 Nightとはやったこと OpsがDevと組み、AIで機能実装するイベントまだ実装されていない改善要望を題材に選ぶ題材は自社プロダクトの改善ネタや新機能 Devと要件を詰め、Devinに指示して実装 Devはコードもプロンプトも書かないルール 1〜2時間で動くものを確認し、PRを提出気づき 01 コードが書けないことは、もはや開発の制約ではないこと 02 難しいのは実装ではなく、要件を決めること 03 開発の解像度が上がると、顧客に聞くことが変わる参考記事／ estie inside blog タッグ開発 Night!! “お願い” を Pull Request に © estie Inc. 20

Slide 21

Slide 21 text

DevとOpsの目線を、極限まで近づける社内のラリーを極小化し、顧客に最速で適切な価値を届ける理想現実解 1人で全部できれば最強チームで「最強の1人」になるだが、そんな人はごく一部 DevとOpsが1つの頭脳のように動く DevとOpsの「言語」が揃うことで実現する © estie Inc. 21

Slide 22

Slide 22 text

Dev<>Opsで 3 「何を作るか」を決める仕組み © estie Inc. 22

Slide 23

Slide 23 text

DevとOpsで、同じ目標を持つ Dev / Opsが同じ事業目標を持つことで、「何を作るか」の議論が成立する同じ事業目標がないと、お互いの役割に閉じて議論がかみ合わない Dev Ops プロダクトを作る顧客に売る技術判断をする顧客の利用を推進する同じ事業目標を持つと「何を作るか」の議論が成立する共通の事業目標：売上 / ARR / 顧客価値 © estie Inc. 23

Slide 24

Slide 24 text

DevとOpsで、一緒に顧客の理解を揃える要望だけを受け取るのではなく、Devも顧客の背景・温度感に直接触れる BEFORE やること Devも商談に同席 DevとOpsの日常的な会話 VoCをSlackに集約しつつ会話要望の背景まで残す（商談議事録）顧客 Ops Dev 一次情報を得づらい AFTER 顧客 Ops Dev 要望を知るのではなく、顧客を深く理解する © estie Inc. 24

Slide 25

Slide 25 text

DevとOpsで、課題の解像度を上げる要望をそのまま開発要求にせず、背景を掘って本当の課題に言い換える顧客の要望 CSVで比較したい一覧を出力したい Dev / Opsで掘る本当に解くべき課題何をしたい？複数の情報を比較する作業に毎回時間がかかっている今はどうしている？どこで困っている？この項目を追加してほしいどれくらい頻繁に？解決後どう変わる？社内共有のための加工が手作業になっている howではなく、whyを深ぼる © estie Inc. 25

Slide 26

Slide 26 text

実例：DevとOpsのコミュニケーションふらっと話した雑談が一晩で機能改善に。VoCも「書いて待つ」から「議論する」へ 01 ふらっと話しかけて、一晩で大幅改善夕方直後 OpsがDevの席にふらっと。査定機能の課題を雑談 Devが会話メモと改善案をSlackで共有深夜翌週「気が済むまで実装」。動く PreviewをSlackに投稿 Opsが顧客との打ち合わせで実物を当てる 02 VoCを「書いて待つ」から「議論する」へ BEFORE：スプレッドシート AFTER：Slackスレッド Opsが書いて待ち、Devが読んで整理。単方向投稿のスレッドで随時補足・議論。双方向 © estie Inc. 26

Slide 27

Slide 27 text

実例：Dev<>Ops定例個人間の連携に加え、全体で大きな顧客課題に向き合う場を週1回設ける Dev<>Ops定例とは場の空気全体で、より包括的な顧客課題に向き合う毎週金曜、プロダクトごとに開催一つの会議室にギュッと集まる肩書き関係なく雑談のように意見が出る DevとOpsがそれぞれの視点を持ち寄る Opsの視点顧客の温度感売れる可能性 Devの視点技術難易度小さく試す方法顧客価値 × 事業インパクト最後はグループに分かれて議論他顧客への広がり商談タイミング既存機能で代替できるか × 技術コスト → 実装コスト何を試すか正解を決めるのではなく、次に検証する仮説を決める © estie Inc. 27

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Preview環境を使って、動くものを見て認識を合わせる PRにラベルを付けるだけで専用の検証環境が発行される仕組み PRに「Preview」ラベル → 専用 URLが発行 Stagingの他サービス・DBに接続して動く数分で払い出し、PRクローズで自動削除使われ方コードレビューで実際の挙動を確認 PMが開発中の機能を触って確認 Opsが顧客にプロトタイプを見せる AIエージェントがUIを自動検証認識は、仕様書で合わせるのではなく、動くもので合わせる © estie Inc. 29

Slide 30

Slide 30 text

Preview環境の最近の進化サービス間連携も、PRごとの専用DBも、Previewで試せるようになった Preview同士をつなげる DB付きPreview Stagingの他サービスにつないで動く Preview同士をつなげて連携を検証「Preview with DB」ラベルで起動内部API連携もStagingを汚さず確認 PoC・プロトタイピングに活用 copy-on-writeでDBをクローンスキーマ変更の検証もできる参考記事 QR © estie Inc. estie inside blog estieでのナイス基盤な事例の紹介〜Preview環境実装〜 QR Zenn / estie Preview環境でPRごとに専用DBを使えるようにした話 30

Slide 31

Slide 31 text

高速/安全を担保する incubation というアプリ AIで作れるようになった一方、検証は速くなっていない変化ビジネス職がAIでアプリを作ることができる AIのおかげで、PDCAサイクルが高速にボトルネックセキュリティ面で顧客に出すのは怖い一定、エンジニアの知識がないと顧客提供できるクオリティにならない誰でも、安全/高品質にアプリのPoCをできるための基盤を作る © estie Inc. 31

Slide 32

Slide 32 text

速度と安全性を、構造で両立する誰がアプリを作っても安心安全なガードレールを、基盤側に持たせる Platform Engineeringチームを主体に、ミドルウェアを中心としてガードレールを整備認証/認可データ基盤インフラ/監視許可された人にしかデータが見れない構造権限とテナント分離を担保したDBラッパー統率の取れたインフラリソースを簡単に払い出す品質と安全は構造で守り、ドメイン知識だけで高品質なアプリを作る参考 © estie Inc. アーキテクチャカンファレンス2026で弊社エンジニアが登壇予定 32

Slide 33

Slide 33 text

同じデータを、誰でも簡単に分析できる基盤を作るデータを整えることも、誰でも引き出せるようにすることも、Dev × Ops で進めているデータを整える利用ログを分析しやすい形に整備不動産データもセマンティックを推進誰でも引き出せるようにする社内でsnowflake MCPを自作して利用 Claude connecterを作成して社内配布各々がskill化して、社内に共有使われるデータをデータマートとして整備 Ops・Corpも自分でデータ分析が可能にデータの整理も利用も、DevとOpsで一緒にやる © estie Inc. 33

Slide 34

Slide 34 text

Slide 35

Slide 35 text

DevとOpsはより根本的な問いに近づいている職種は違っても、両者ともに「何を作れば価値になるか」を考えるようになった Dev Ops どう作るかどう売るか何を作るか何を売るかどう売上につなげるか何を作るべきか顧客がお金を払ってでも解決したい課題は何か？これが「職種の境界が薄くなった」の正体 © estie Inc. 35

Slide 36

Slide 36 text

全員が同じ仕事をするわけではない責任範囲は重なるが、専門性は異なる Devの専門性共同で持つ責任 Opsの専門性技術判断顧客課題を見極める顧客理解設計・アーキテクチャ何を作るか決める商談・市場文脈品質・保守性作って顧客に当てる売れるか見極める開発基盤・仕組み化事業成果まで見る顧客へのデリバリ境界をなくすのではなく、境界部分を一緒に推進する「Opsにもコードを書かせる」「Devは全員営業」という話ではない © estie Inc. 36

Slide 37

Slide 37 text

「当事者」になる、とは「当事者」とは、コードを書く人ではなく顧客課題を解くプロセスに責任を持つ人課題を知る何を作るか作る売る・届ける確かめる「コードを書く人」はここだけ「当事者」＝顧客課題を解くプロセス全体に責任を持つ人 Devが売上の当事者になる © estie Inc. Opsが開発の当事者になる 37

Slide 38

Slide 38 text

Slide 39

Slide 39 text

本日の take away Dev<>Opsが「開発の当事者」になるために、私たちがやってきたこと 01 役割が広がった 02 越境を、文化と仕組みで支える 03 技術がダイナミックな越境を可能にする Devは「何を作るか」へ、Opsは「売るものを生み出す」へ目線を合わせて、コミュニケーションを増やし、一緒に仮説をシャープにするドメインだけに集中すれば売れるプロダクトを作れる環境を技術で叶える顧客課題を解くプロセスに共同で責任を持ち、当事者として高い価値を生み出す © estie Inc. 39

Slide 40

Slide 40 text

ご清聴ありがとうございました ←estieに興味を持っていただけたらDMでご連絡ください。カジュ面しましょう！ 40