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

Developers Summit 2026 Summer
https://event.shoeisha.jp/devsumi/20260716

AI時代こそ、スケールしないことをしよう -「作る人」から「なぜ作るか」を考える人へ

Shimmy
ソフトウェアエンジニア

Transcript

1. Developers Summit 2026 Summer AI時代こそ、スケールしないことをしよう 「作る⼈」から 「なぜ作るか」を考える⼈へ 株式会社カミナシ
2. ⾃⼰紹介 経歴 ヤフー株式会社 -> freee株式会社 -> 株式会社カミナシ 既存プロダクトの開発を⾏った後 株式会社カミナシ Software Engineer 清⽔ 那⾳也 2026年から新規プロダクトの⽴ち上 げを⾏っている。
3. アジェンダ 1. AIで速く作れるようになって 2. ボトルネックを⾒つける 3. スケールしないことをしよう 4. 実例 5. まとめ
4. Q. AIで作れるようになって アウトカムは増えましたか?
5. アウトカム AIで”作る”ことは早くなった みなさんのチームでも 実装や資料作成が速くなったはず アウトカムは増えましたか？
6. アウトカム 機能を作った ≠ アウトカム リリースしただけでは、まだ何も⽣んでいない • 顧客が把握し、理解し、業務の中で使う • 顧客の課題が解消されて、初めてアウトカム • プロダクトが売れる⼟台になって欲しい
7. アウトカム AIを使って機能を 作りまくれば良いのでは？ ➡ 負債につながる 作るコスト <<< 取り下げるコスト
8. 負債について 取り下げコスト リリース前 リリース後 1. 理解負債 なぜこうなっているのか 説明できない 3. 仕様負債 誰の課題を解くのか 曖昧な仕様 2. 技術負債 コードの内部品質の劣化 4. 機能負債 業務に組み込まれ 取り下げられない
9. AIで何をするか • 「もっと作る」はアンチパターン • コーディングをさらに速くしても意味がない ① 何を作るか / 作らないかの確度を上げる ② 顧客に届くまでの速度を上げる
10. ボトルネックを⾒つける
11. ボトルネックとは • 流れ全体の中で、最も処理能⼒が低い ⼯程 • ボトルネック⼯程以外をいくら速くし ても、全体は速くならない。 ボトルネックの速度 ＝ 全体の速度 https://promo.diamond.jp/books/the-goal/series/
12. ボトルネックは移動する • 1つ解消すると、次のボトルネックが現れる • コーディング”は”速くなった ◦ ボトルネックはコードの外にある • 移動した先を解消しない限り、全体のス ループット上がらない 実装 レビュー 顧客理解 検証 商談獲得
13. スケールしないことをしよう
14. スケールしないことをしよう Paul Grahamがスタートアップの創業者に向けて説 いた⾔葉 • 私の解釈 ◦ 創業初期のスケールしない作業が貴重な学びを ⽣み、後にスケールする⼟台になる AI時代のエンジニアに必要な考え https://paulgraham.com/ds.html
15. 実例 https://kaminashi-developer.hatenablog.jp/entry/do-things-that-dont-scale-in-ai-era
16. 私がやってきた事 • ボトルネックを⾒つける • スケールしないところに⼊る ◦ ⾃ら⼊ることで課題が分かる • スケールできるところは技術で解決する 実装 レビュー 顧客理解 顧客検証 商談獲得
17. 背景 B2B新規プロダクトの 0→1 開発 • こういうのを作りたい。がある状態 • 開発に関わる⼈達 ◦ PM, BizDev, Designer, Researcher, Engineer, etc • お客様は「現場」で働く⼈たち ◦ ⾷品⼯場や機械製造業など
18. ボトルネック コードレビュー • 最初のボトルネックはレビュー • AIが書いたコードの品質担保 • 設計や思想をレビュー「前」に担保する 実装 レビュー 顧客理解 顧客検証 商談獲得 AIのための特別なアーキテクチャはいらない ― 0→1開発で実践した設計原則とガードレール
19. 顧客理解 実装 レビュー 顧客理解 顧客検証 商談獲得
20. 何をするか 現場にいく • 実際の仕事を⾒る • 現場で直接話を聞く • 多いときは週1〜2回訪問した
21. 顧客理解 なぜ”現場”に⾏くか • 伝聞で届く情報は整理された形になっている • その裏にある背景から理解することが⼤事 • 背景から理解すると ◦ 適切な抽象化 ◦ もっとシンプルに実現できる 現場でしか取れない⼀次情報が重要
22. 実例 現場訪問で意識したこと • ⽬的と仮説を持って⾏く ◦ 「この帳票のこのデータ、なぜ書いてるんです か？」 その結果 • お客様によって異なると思っていた定義 ◦ ドメインモデリングして体系化 ◦ 設定の組み合わせでシンプルに表現できた
23. Researcher 1次情報の⺠主化 • ヒアリング内容とインサイトをツールに集約 • 「あのお客様何て⾔ってたっけ」を誰でも遡れる PM依存 -> 開発メンバーへの⺠主化 「なんとなく」の顧客理解から脱却する ── 顧客の解像度を武器にするインサイトマネジメント
24. スケールさせる チームのAI活⽤を主導 • 得た情報の共有や周辺業務をスケールさせる • ⾮エンジニアへのAI導⼊を主導 • 動かなかったGoogle連携MCPを⾃作 ◦ 以前なら公式の修正待ち ◦ AIで1⽇⾜らずで作れた
25. 顧客検証 実装 レビュー 顧客理解 顧客検証 商談獲得
26. 課題 作っても、検証できるのは⼀部 • 検証のタイミングと範囲には上限がある • 検証より速く作っても「検証されない機能」が溜 まるだけ • 全体のスループットは顧客検証で決まる → 顧客検証に開発を従属させる
27. 何をしたか 作るものを絞る + サイクルに合わせる • 作るものを、検証で聞くべきことに絞る ◦ 「正解がわからず、お客様に聞かないと判断で きないもの」 • 作るタイミングを、検証のサイクルに合わせる ◦ 事前ヒアリング → 開発 → 使ってもらう → フィードバック持ち帰り
28. 開発においてAIをどう活⽤すべきか 機能を量産する道具ではなく 「試⾏の回数と質を上げる道具」 • 本実装の前に、Mockだけ作って顧客に当てる • 設計を議論する前に、コードで⽬に⾒えるものに する • 試⾏回数と確度を上げる
29. 商談 実装 レビュー 顧客理解 顧客検証 商談
30. 商談 展⽰会に乗り込む
31. 商談 ⾏った背景 • どんな課題の顧客が興味を持つか、どの機能で 「使ってみたい」となるか 結果 • Salesの要望も背景から理解しやすくなった • 商談を複数件獲得
32. 上⼿くいかなかったこと 感想 • プロダクトへのフィードバック量は顧客訪問ほど ではなかった • 技術でスケールさせづらい • ⼊ったからこそ分かったことはある 実装 レビュー 顧客理解 顧客検証 商談獲得
33. できるようになったこと
34. Whyからの理解 「なぜ作るか」を考えられる • 機能を顧客の課題ベースで議論 ◦ Whyから考えるように ▪ なぜ必要か、他の解決策でできないか ▪ 作る場合、本当にそれが正しいのか • 仕様についてEng x Designだけで進めたりする
35. ドメイン理解 マルチプロダクト間での議論 カミナシは複数サービスを持っている • コア概念は将来重なる可能性が⾼い • 他サービスとの将来の重なりを考える • CTO, VPoE, 他サービスのPMと議論 主導して議論を進められた
36. まとめ
37. ボトルネックはコードの外へ移動した 1. 何を作る / 作らないかの確度 2. 顧客に届くまでの速度 レビュー 顧客理解 顧客検証 商談獲得
38. エンジニアの価値は、コードの外にも • 「作る」も「調べる」も、AIで誰でもできるよう になった • アウトカムを増やす鍵は、コードの外にあった • 現場の1次情報を持ったエンジニアが、「なぜ作 るか」から考える
39. 最後の質問 Q. あなたのチームのボトルネックは？ そこにコミットしていますか？ ？ ？ ？ AI時代こそ スケールしないことをしよう ？
40. ありがとうございました