AI時代こそ、スケールしないことをしよう -「作る人」から「なぜ作るか」を考える人へ / Do Things That Don't Scale in the AI Era

AI時代こそ、スケールしないことをしよう -「作る人」から「なぜ作るか」を考える人へ / Do Things That Don't Scale in the AI Era — From How to Why

by 株式会社カミナシ

Embed

Start on current slide

Slide 1

Slide 1 text

Developers Summit 2026 Summer AI時代こそ、スケールしないことをしよう「作る⼈」から「なぜ作るか」を考える⼈へ株式会社カミナシ

Slide 2

Slide 2 text

⾃⼰紹介経歴ヤフー株式会社 -> freee株式会社 -> 株式会社カミナシ既存プロダクトの開発を⾏った後株式会社カミナシ Software Engineer 清⽔那⾳也 2026年から新規プロダクトの⽴ち上げを⾏っている。

Slide 3

Slide 3 text

アジェンダ 1. AIで速く作れるようになって 2. ボトルネックを⾒つける 3. スケールしないことをしよう 4. 実例 5. まとめ

Slide 4

Slide 4 text

Q. AIで作れるようになってアウトカムは増えましたか?

Slide 5

Slide 5 text

アウトカム AIで”作る”ことは早くなったみなさんのチームでも実装や資料作成が速くなったはずアウトカムは増えましたか？

Slide 6

Slide 6 text

アウトカム機能を作った ≠ アウトカムリリースしただけでは、まだ何も⽣んでいない ● 顧客が把握し、理解し、業務の中で使う ● 顧客の課題が解消されて、初めてアウトカム ● プロダクトが売れる⼟台になって欲しい

Slide 7

Slide 7 text

アウトカム AIを使って機能を作りまくれば良いのでは？ ➡ 負債につながる作るコスト <<< 取り下げるコスト

Slide 8

Slide 8 text

負債について取り下げコストリリース前リリース後 1. 理解負債なぜこうなっているのか説明できない 3. 仕様負債誰の課題を解くのか曖昧な仕様 2. 技術負債コードの内部品質の劣化 4. 機能負債業務に組み込まれ取り下げられない

Slide 9

Slide 9 text

AIで何をするか ● 「もっと作る」はアンチパターン ● コーディングをさらに速くしても意味がない ① 何を作るか / 作らないかの確度を上げる ② 顧客に届くまでの速度を上げる

Slide 10

Slide 10 text

ボトルネックを⾒つける

Slide 11

Slide 11 text

ボトルネックとは ● 流れ全体の中で、最も処理能⼒が低い⼯程 ● ボトルネック⼯程以外をいくら速くしても、全体は速くならない。ボトルネックの速度＝全体の速度 https://promo.diamond.jp/books/the-goal/series/

Slide 12

Slide 12 text

ボトルネックは移動する ● 1つ解消すると、次のボトルネックが現れる ● コーディング”は”速くなった ○ ボトルネックはコードの外にある ● 移動した先を解消しない限り、全体のスループット上がらない実装レビュー顧客理解検証商談獲得

Slide 13

Slide 13 text

スケールしないことをしよう

Slide 14

Slide 14 text

スケールしないことをしよう Paul Grahamがスタートアップの創業者に向けて説いた⾔葉 ● 私の解釈 ○ 創業初期のスケールしない作業が貴重な学びを⽣み、後にスケールする⼟台になる AI時代のエンジニアに必要な考え https://paulgraham.com/ds.html

Slide 15

Slide 15 text

実例 https://kaminashi-developer.hatenablog.jp/entry/do-things-that-dont-scale-in-ai-era

Slide 16

Slide 16 text

私がやってきた事 ● ボトルネックを⾒つける ● スケールしないところに⼊る ○ ⾃ら⼊ることで課題が分かる ● スケールできるところは技術で解決する実装レビュー顧客理解顧客検証商談獲得

Slide 17

Slide 17 text

背景 B2B新規プロダクトの 0→1 開発 ● こういうのを作りたい。がある状態 ● 開発に関わる⼈達 ○ PM, BizDev, Designer, Researcher, Engineer, etc ● お客様は「現場」で働く⼈たち ○ ⾷品⼯場や機械製造業など

Slide 18

Slide 18 text

ボトルネックコードレビュー ● 最初のボトルネックはレビュー ● AIが書いたコードの品質担保 ● 設計や思想をレビュー「前」に担保する実装レビュー顧客理解顧客検証商談獲得 AIのための特別なアーキテクチャはいらない ― 0→1開発で実践した設計原則とガードレール

Slide 19

Slide 19 text

顧客理解実装レビュー顧客理解顧客検証商談獲得

Slide 20

Slide 20 text

何をするか現場にいく ● 実際の仕事を⾒る ● 現場で直接話を聞く ● 多いときは週1〜2回訪問した

Slide 21

Slide 21 text

顧客理解なぜ”現場”に⾏くか ● 伝聞で届く情報は整理された形になっている ● その裏にある背景から理解することが⼤事 ● 背景から理解すると ○ 適切な抽象化 ○ もっとシンプルに実現できる現場でしか取れない⼀次情報が重要

Slide 22

Slide 22 text

実例現場訪問で意識したこと ● ⽬的と仮説を持って⾏く ○ 「この帳票のこのデータ、なぜ書いてるんですか？」その結果 ● お客様によって異なると思っていた定義 ○ ドメインモデリングして体系化 ○ 設定の組み合わせでシンプルに表現できた

Slide 23

Slide 23 text

Researcher 1次情報の⺠主化 ● ヒアリング内容とインサイトをツールに集約 ● 「あのお客様何て⾔ってたっけ」を誰でも遡れる PM依存 -> 開発メンバーへの⺠主化「なんとなく」の顧客理解から脱却する ── 顧客の解像度を武器にするインサイトマネジメント

Slide 24

Slide 24 text

スケールさせるチームのAI活⽤を主導 ● 得た情報の共有や周辺業務をスケールさせる ● ⾮エンジニアへのAI導⼊を主導 ● 動かなかったGoogle連携MCPを⾃作 ○ 以前なら公式の修正待ち ○ AIで1⽇⾜らずで作れた

Slide 25

Slide 25 text

顧客検証実装レビュー顧客理解顧客検証商談獲得

Slide 26

Slide 26 text

課題作っても、検証できるのは⼀部 ● 検証のタイミングと範囲には上限がある ● 検証より速く作っても「検証されない機能」が溜まるだけ ● 全体のスループットは顧客検証で決まる顧客検証に開発を従属させる

Slide 27

Slide 27 text

何をしたか作るものを絞る + サイクルに合わせる ● 作るものを、検証で聞くべきことに絞る ○ 「正解がわからず、お客様に聞かないと判断できないもの」 ● 作るタイミングを、検証のサイクルに合わせる ○ 事前ヒアリング → 開発 → 使ってもらう → フィードバック持ち帰り

Slide 28

Slide 28 text

開発においてAIをどう活⽤すべきか機能を量産する道具ではなく「試⾏の回数と質を上げる道具」 ● 本実装の前に、Mockだけ作って顧客に当てる ● 設計を議論する前に、コードで⽬に⾒えるものにする ● 試⾏回数と確度を上げる

Slide 29

Slide 29 text

商談実装レビュー顧客理解顧客検証商談

Slide 30

Slide 30 text

商談展⽰会に乗り込む

Slide 31

Slide 31 text

商談⾏った背景 ● どんな課題の顧客が興味を持つか、どの機能で「使ってみたい」となるか結果 ● Salesの要望も背景から理解しやすくなった ● 商談を複数件獲得

Slide 32

Slide 32 text

上⼿くいかなかったこと感想 ● プロダクトへのフィードバック量は顧客訪問ほどではなかった ● 技術でスケールさせづらい ● ⼊ったからこそ分かったことはある実装レビュー顧客理解顧客検証商談獲得

Slide 33

Slide 33 text

できるようになったこと

Slide 34

Slide 34 text

Whyからの理解「なぜ作るか」を考えられる ● 機能を顧客の課題ベースで議論 ○ Whyから考えるように ■ なぜ必要か、他の解決策でできないか ■ 作る場合、本当にそれが正しいのか ● 仕様についてEng x Designだけでも進められる

Slide 35

Slide 35 text

ドメイン理解マルチプロダクト間での議論カミナシは複数サービスを持っている ● コア概念は将来重なる可能性が⾼い ● 他サービスとの将来の重なりを考える ● CTO, VPoE, 他サービスのPMと議論⾃分が主導して議論を進められた

Slide 36

Slide 36 text

まとめ

Slide 37

Slide 37 text

ボトルネックはコードの外へ移動した 1. 何を作る / 作らないかの確度 2. 顧客に届くまでの速度レビュー顧客理解顧客検証商談獲得

Slide 38

Slide 38 text

エンジニアの価値は、コードの外にも ● 「作る」も「調べる」も、AIで誰でもできるようになった ● アウトカムを増やす鍵は、コードの外にあった ● 現場の1次情報を持ったエンジニアが、「なぜ作るか」から考える

Slide 39

Slide 39 text

最後の質問 Q. あなたのチームのボトルネックは何ですか？そこにコミットしていますか？？？？？

Slide 40

Slide 40 text

AI時代こそスケールしないことをしよう