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

AIで開発スピードがコモディティ化した今、プロダクトの競争力は「どれだけ速く作れるか」から「顧客がお金を払ってでも解決したい課題を、いかにシャープに見極めて作れるか」へ移りつつあります。一方で、現場では「営業・CSから上がる要望をどう開発に活かすか」「作ったものが本当に刺さるのか」が見えづらい、という悩みは少なくないはずです。

estieの私たちが所属する開発チームではPdMを置かず、少人数で複数プロダクトを開発しています。この体制では、Dev（開発）とOps（営業・CS）が同じ目的を共有し、議論を通じて「何を作るか」を決められるかが、プロダクトの価値に直結します。

本セッションでは、営業・CSが「開発の当事者」になるために私たちが設計した仕組みを、明日から取り入れられる粒度で紹介します。一方的な共有で終わらせず議論の時間を明示的に設ける「Dev<>Ops定例」、preview環境とAIで爆速に作ったプロトタイプをその場でOpsに当てる検証、Dev側メンバーの商談同席、CS含めたVoCの棚卸方法、等々。Dev視点では価値がないと思った機能が顧客に刺さったり、Ops視点で難しいと思った要望が実は簡単に作れたり。議論の場だからこそ生まれる発見と、「Devが売上に」「Opsが開発に」コミットする当事者意識がどう育つかを、具体的な運用とともにお話しします。

営業、CSメンバーからも、実際の変化も具体的にお話しします。営業は「言っても変わらない」と諦めていた要望が、商談同席→その場で議論→AIで爆速プロトタイプ→顧客のWOW、を経て「届ければ形になる」へと変わりました。CS側でも、プロセスを通した迅速な開発と早期デリバリによって、顧客との信頼醸成に繋がったり、VoCシートの文言だけでは埋もれていた声が「より温度感が高い課題」「複数顧客に共通する課題」だと判明して優先順位を組み替える、といった発見が生まれています。

こういった発見や変化の積み重ねで、dev、opsともに、要望を集めるだけではなく、顧客課題そのものを見るといった意識に変化しています。

Transcript

1. Product Engineering Conference 2026 営業・CSを「開発の当事者」にする 少人数チームで複数プロダクトを動かすDev<>Ops連携の方法 山本龍平 北村大助 © estie Inc. 1
2. 自己紹介 経歴 2022/04 - 2025/01 株式会社SHIFT 新卒でQAエンジニアとして品質保証に従事 プロジェクトリーダーとして活動 2025/02 - 現在 株式会社estie QAエンジニアとしてjoin 現在ではフルスタックに開発に携わる estieでやっていること Ryuhei Yamamoto 株式会社estie / エンジニア いいプロダクトを作るために必要なこと全般 ・事業開発 ・要件定義 ・開発 ・テスト ・運用 趣味 ゲーム作り © estie Inc. 最近始めたエックス↑ 2
3. 自己紹介 経歴 2022/03 – 2024/03 東京大学在学中、長期インターンとして株式会社estieの事 業に参画。 2024/04 – 現在 株式会社estie カスタマーサクセスとして新卒入社 estieでやっていること 顧客要望を叶えること全般 ・サクセスプランの立案・推進 ・データ分析・レポート作成 Daisuke Kitamura 株式会社estie / カスタマーサクセス 趣味 運動全般（ゴルフ、テニス、スノボー、筋トレ等） © estie Inc. 3
4. アジェンダ 01 AI時代、Devの役割はどう変わる？ 02 AI時代、Opsの役割はどう変わる？ 03 Dev<>Opsで「何を作るか」を決める仕組み 04 仕組みを支える技術的な取り組み 05 職種の境界はどのように変わっていくのか © estie Inc. 4
5. 0 会社紹介 © estie Inc. 5
6. 株式会社estieの会社概要 © estie Inc. 6
7. 株式会社estieの事業内容 © estie Inc. 7
8. 株式会社estieは欲張りな会社です © estie Inc. 8
9. 私たちの前提：少人数 × 複数プロダクト 少人数のまま複数プロダクトを伸ばし、高収益を目指すことに挑戦している 複数プロダクトを兼務 沢山のミドルウェア 高い利益率 一般的な組織 私たちの選び方 職種ごとに分業する JDを越えて兼務する JDの内側で最適化する 越境することが推奨される 越境が、Dev<>Ops連携の前提になっている © estie Inc. 9
10. 1 AI時代、Devの役割はどう変わる？ © estie Inc. 10
11. 「作ること」の希少性は下がりつつある AIで実装速度が上がり、Devの価値は「コードを書く」ことだけでは決まりにくくなった BEFORE NOW 実装コストが高い AIで実装コストが下がる 作れること自体が価値 「何を作るか」の重要性が上がる 間違ったものを速く作るリスクも増えた © estie Inc. 11
12. Devの役割は「事業を作る」側に広がる 顧客課題を理解し、「何を作るか」を決め、売上まで考える 01 02 03 04 05 商談に出る Opsと課題を 議論する POCを作る 顧客に当てる 利用・売上 を見る 「どう作るか」だけでなく、「何を作るか」に踏み込む © estie Inc. 12
13. Devの役割は「事業を作る」側に広がる 実例 顧客課題を理解し、「何を作るか」を決め、売上まで考える ある機能のリニューアルで、日常的に回しているサイクル 01 商談に出る 読む 02 03 04 商談議事録やVoCを片っ端から読み込む 聞く 商談に5回以上同席し、顧客の課題感を直に整理 05 POCを作る 顧客に当てる 利用・売上 プロトタイプを作り、顧客に直接ヒアリング（これも5社くらい） 試す Opsと課題を 議論する 届ける Opsと連携し、利用確度の高い顧客へリリース 磨く 利用ログとVoCを聞きながらプロダクトを改善 を見る 「どう作るか」だけでなく、「何を作るか」に踏み込む 「商談議事録を読む」「商談に同席する」は、社内では当たり前 © estie Inc. 13
14. Devの役割は「仕組みを作る」側にも広がる 自分が速く作るだけでなく、チーム全体が速く試せる仕組みを作る 検証をより高速に PoCをより簡単に データ分析をより柔軟に 自分が作るのではなく、「みんなが作れる状態」を作る 具体的な話は第5章で詳しくお話しします © estie Inc. 14
15. 2 AI時代、Opsの役割はどう変わる？ © estie Inc. 15
16. 「開発」はDevの専売特許ではなくなった AIの登場で、開発のために必ずしもコードを書ける必要はなくなった BEFORE NOW 開発はDevだけの仕事 Opsも開発ができる コードを書けることが前提 コードはAIが書いてくれる Opsも「開発をする」時代の到来 © estie Inc. 16
17. Opsの役割は「作って確かめる」側に広がる 要望を伝えて待つのではなく、自ら作って顧客にぶつけ、磨き込む 01 02 03 04 05 顧客の声を 聞く AIでモックを 作る 顧客に当てる 改善を重ねる Devに パスする 「あとはほぼ実装するだけ」の状態でDevへ渡す © estie Inc. 17
18. Opsの役割は「作って確かめる」側に広がる 実例 要望を伝えて待つのではなく、自ら作って顧客にぶつけ、磨き込む ある顧客の「継続提案」で、いま実際に回しているサイクル 01 顧客の声を 聞く 聞く 02 03 04 05 「今の機能のままでは、使い続けるのは難しい」と率直な声 作る 「こうなれば使いたい」という要望をもとに、AIでモックを作る 顧客に当てる 改善を重ねる 商談でモックを見せ、解約の検討から継続の検討へ 当てるAIでモックを 作る Devに パスする 磨く 継続となれば、その顧客とすり合わせながら改善を重ねる 渡す 磨き込んだものを、本体サービスへの実装としてDevにパス 「あとはほぼ実装するだけ」の状態でDevへ渡す 「要望を伝えて待つ」だけなら、解約で終わっていたかもしれない © estie Inc. 18
19. Opsの役割は「開発を知り、つなぐ」側にも広がる モック作成までいかずとも、開発の現場を知ることで「集めるべき声」が変わる 定義すべき要件が わかる 拾うべき顧客の声が わかる Devと同じ言葉で 話せる 「要望を渡す」から、「開発に効く声を届ける」へ © estie Inc. 19
20. 私の事例：タッグ開発 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
21. DevとOpsの目線を、極限まで近づける 社内のラリーを極小化し、顧客に最速で適切な価値を届ける 理想 現実解 1人で全部できれば最強 チームで「最強の1人」になる だが、そんな人はごく一部 DevとOpsが1つの頭脳のように動 く DevとOpsの「言語」が揃うことで実現する © estie Inc. 21
22. Dev<>Opsで 3 「何を作るか」を決める仕組み © estie Inc. 22
23. DevとOpsで、同じ目標を持つ Dev / Opsが同じ事業目標を持つことで、「何を作るか」の議論が成立する 同じ事業目標がないと、お互いの役割に閉じて議論がかみ合わない Dev Ops プロダクトを作る 顧客に売る 技術判断をする 顧客の利用を推進する 同じ事業目標を持つと 「何を作るか」の議論が成立する 共通の事業目標：売上 / ARR / 顧客価値 © estie Inc. 23
24. DevとOpsで、一緒に顧客の理解を揃える 要望だけを受け取るのではなく、Devも顧客の背景・温度感に直接触れる BEFORE やること Devも商談に同席 DevとOpsの日常的な会話 VoCをSlackに集約しつつ会話 要望の背景まで残す（商談議事録） 顧客 Ops Dev 一次情報を得づらい AFTER 顧客 Ops Dev 要望を知るのではなく、顧客を深く理解する © estie Inc. 24
25. DevとOpsで、課題の解像度を上げる 要望をそのまま開発要求にせず、背景を掘って本当の課題に言い換える 顧客の要望 CSVで比較したい 一覧を出力したい Dev / Opsで掘る 本当に解くべき課題 何をしたい？ 複数の情報を比較す る作業に毎回時間が かかっている 今はどうしている？ どこで困っている？ この項目を追加して ほしい どれくらい頻繁に？ 解決後どう変わる？ 社内共有のための加 工が手作業になって いる howではなく、whyを深ぼる © estie Inc. 25
26. 実例：DevとOpsのコミュニケーション ふらっと話した雑談が一晩で機能改善に。VoCも「書いて待つ」から「議論する」へ 01 ふらっと話しかけて、一晩で大幅改善 夕方 直後 OpsがDevの席にふらっと。査定機 能の課題を雑談 Devが会話メモと改善案をSlackで 共有 深夜 翌週 「気が済むまで実装」。動く PreviewをSlackに投稿 Opsが顧客との打ち合わせで実物を 当てる 02 VoCを「書いて待つ」から「議論する」へ BEFORE：スプレッドシート AFTER：Slackスレッド Opsが書いて待ち、Devが読んで 整理。単方向 投稿のスレッドで随時補足・議論。 双方向 © estie Inc. 26
27. 実例：Dev<>Ops定例 個人間の連携に加え、全体で大きな顧客課題に向き合う場を週1回設ける Dev<>Ops定例とは 場の空気 全体で、より包括的な顧客課題に向き合 う 毎週金曜、プロダクトごとに開催 一つの会議室にギュッと集まる 肩書き関係なく雑談のように意見が出る DevとOpsがそれぞれの視点を持ち寄る Opsの視点 顧客の温度感 売れる可能性 Devの視点 技術難易度 小さく試す方法 顧客価値 × 事業インパクト 最後はグループに分かれて議論 他顧客への広がり 商談タイミング 既存機能で代替できるか × 技術コスト → 実装コスト 何を試すか 正解を決めるのではなく、次に検証する仮説を決める © estie Inc. 27
28. 4 仕組みを支える、技術的な取り組み © estie Inc. 28
29. Preview環境を使って、動くものを見て認識を合わせる PRにラベルを付けるだけで専用の検証環境が発行される 仕組み PRに「Preview」ラベル → 専用 URLが発行 Stagingの他サービス・DBに接続し て動く 数分で払い出し、PRクローズで自動 削除 使われ方 コードレビューで実際の挙動を確認 PMが開発中の機能を触って確認 Opsが顧客にプロトタイプを見せる AIエージェントがUIを自動検証 認識は、仕様書で合わせるのではなく、動くもので合わせる © estie Inc. 29
30. 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
31. 高速/安全を担保する incubation というアプリ AIで作れるようになった一方、検証は速くなっていない 変化 ビジネス職がAIでアプリを作ることが できる AIのおかげで、PDCAサイクルが高速に ボトルネック セキュリティ面で顧客に出すのは怖い 一定、エンジニアの知識がないと 顧客提供できるクオリティにならない 誰でも、安全/高品質にアプリのPoCをできるための基盤を作る © estie Inc. 31
32. 速度と安全性を、構造で両立する 誰がアプリを作っても安心安全なガードレールを、基盤側に持たせる Platform Engineeringチームを主体に、ミドルウェアを中心としてガードレールを整備 認証/認可 データ基盤 インフラ/監視 許可された人にしか データが見れない構造 権限とテナント分離を 担保したDBラッパー 統率の取れたインフラリ ソースを簡単に払い出す 品質と安全は構造で守り、ドメイン知識だけで高品質なアプリを作る 参考 © estie Inc. アーキテクチャカンファレンス2026で弊社エンジニアが登壇予定 32
33. 同じデータを、誰でも簡単に分析できる基盤を作る データを整えることも、誰でも引き出せるようにすることも、Dev × Ops で進めている データを整える 利用ログを分析しやすい形に整備 不動産データもセマンティックを推進 誰でも引き出せるようにする 社内でsnowflake MCPを自作して利用 Claude connecterを作成して社内配布 各々がskill化して、社内に共有 使われるデータをデータマートとし て整備 Ops・Corpも自分でデータ分析が可能に データの整理も利用も、DevとOpsで一緒にやる © estie Inc. 33
34. 5 職種の境界はどのように変わっていくのか？ © estie Inc. 34
35. DevとOpsはより根本的な問いに近づいている 職種は違っても、両者ともに「何を作れば価値になるか」を考えるようになった Dev Ops どう作るか どう売るか 何を作るか 何を売るか どう売上につなげるか 何を作るべきか 顧客がお金を払ってでも解決したい課題は何か？ これが「職種の境界が薄くなった」の正体 © estie Inc. 35
36. 全員が同じ仕事をするわけではない 責任範囲は重なるが、専門性は異なる Devの専門性 共同で持つ責任 Opsの専門性 技術判断 顧客課題を見極める 顧客理解 設計・アーキテクチャ 何を作るか決める 商談・市場文脈 品質・保守性 作って顧客に当てる 売れるか見極める 開発基盤・仕組み化 事業成果まで見る 顧客へのデリバリ 境界をなくすのではなく、境界部分を一緒に推進する 「Opsにもコードを書かせる」「Devは全員営業」という話ではない © estie Inc. 36
37. 「当事者」になる、とは 「当事者」とは、コードを書く人ではなく顧客課題を解くプロセスに責任を持つ人 課題を知る 何を作るか 作る 売る・届ける 確かめる 「コードを書く人」はここだけ 「当事者」＝顧客課題を解くプロセス全体に責任を持つ人 Devが売上の当事者になる © estie Inc. Opsが開発の当事者になる 37
38. まとめ © estie Inc. 38
39. 本日の take away Dev<>Opsが「開発の当事者」になるために、私たちがやってきたこと 01 役割が広がった 02 越境を、文化と仕組みで支える 03 技術がダイナミックな越境を可能にする Devは「何を作るか」へ、Opsは「売るものを生み出す」へ 目線を合わせて、コミュニケーションを増やし、一緒に仮説をシャープにする ドメインだけに集中すれば売れるプロダクトを作れる環境を技術で叶える 顧客課題を解くプロセスに共同で責任を持ち、当事者として高い価値を生み出す © estie Inc. 39
40. ご清聴ありがとうございました ←estieに興味を持っていただけたらDMでご連絡ください。 カジュ面しましょう！ 40