SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine(コードジン) ProductZine

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

Developers Summit 2026 Summer セッションレポート

AIで実装は速くなったのに、なぜアウトカムは増えないのか? ボトルネックが移った先にあるエンジニアの仕事

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

森山 咲(編集部)[著] / 井原 淳一[写]

スケールしない仕事が、スケールの土台になる

 では、コードの外のボトルネックにどう向き合えばいいのか。清水氏が提示したのが、ポール・グレアムがスタートアップの創業者に向けて説いた「スケールしないことをしよう」という言葉だ。「創業初期のスケールしない作業が貴重な学びを生み、後々プロダクトとしてスケールする土台になるという話です。AI時代のプロダクト開発において、エンジニアこそスケールしないことで知識を得るべきではないでしょうか」と話す。

 同氏が実践したのは、ボトルネックになっている工程を見つけ、人しかできない仕事にもエンジニア自ら関わることだ。自分で関わることで何が課題なのかがわかり、技術で解決できる部分も見えてくる。

 最初のボトルネックはコードレビューだった。AIが大量にコードを書くため、その品質担保が課題になった。そこで設計方針や、やってはいけないことをSkillファイルやLint、静的解析に落とし込み、人を介入させずAIに自動で直させる仕組みを整えた。

 次に現れたボトルネックが顧客理解だ。ここでとった行動はシンプルで、「現場」に行くことだった。顧客は食品製造や機械製造業など、デスクワークではない現場で働く人々だ。PMや他のメンバーとともに顧客の実際の仕事を見に行き、多いときは週1〜2回訪問した。関西在住の清水氏だが、関東、名古屋、広島と全国各地に足を運んだという。

現場に足を運び、実際の仕事を見て直接話を聞く
現場に足を運び、実際の仕事を見て直接話を聞く

 なぜ現場に行くのか。PMを介した伝聞の情報は、すでに整理された形になっており、背景が見えないからである。「言葉にされない背景を知るために現場に行きました。なぜ、お客さまはその業務をしているのか、なぜ、それが課題なのか理解することが最大の目的です」と同氏は話す。背景から理解すれば、エンジニアの知識と掛け合わせて「本当に必要なのはこれではなく、別のものなのではないか」「もっとシンプルに実現できるのでは」など、実装する手前から考えられる。そのベースになるのが、現場でしか取れない一次情報だ。

 訪問時は御用聞きにならないよう、目的と仮説を持って臨んだ。訪問前に予め顧客の仕事で使っている紙帳票を見せてもらい、「このデータはこういう目的で見ているのでは」「この内容は別の書き方で実現すればプロダクトで共通化できるのでは」など仮説を持った上でヒアリングする。

 このようなことを続けていった結果、顧客ごとにばらばらだと思っていたKPIの定義が、実は共通の計算式で表せ、2つの設定の組み合わせで全顧客分をカバーできるとわかった。顧客ごとに個別に作り込むのではなく、1つのモデルでシンプルに扱えるということだ。

 「お客さまに話を聞いたうえで、エンジニアの知識でドメインとして見る。そのエンジニアリングがあったからこそ見つけられました」

 清水氏はこの知見を体系化してドキュメントにまとめ、チーム内でドメイン勉強会を開き、チームの資産とした。このようにして作られたドキュメントはAIに実装させる時の参考資料にできたり、新しく入ってきた人にオンボーディングとして読んでもらったり、数カ月たった今でも積極的に活用されている。

一次情報は全員のものに、周辺業務はAIで圧縮

 得られた一次情報は、誰か1人のものにしない。チームのリサーチャーがヒアリング内容とインサイトをツールに集約した。

 プロダクト開発でよくある課題としては、PMが現場についての情報を最も知っているので、「PMに聞いてみないとわからない」という状態になり、PMがボトルネックになることである。チーム全員がヒアリングで得た情報をツールに集約することで、開発メンバーへの「一次情報の民主化」を進めた。これによって現場に行かなかった人も一次情報を得られるようになった。

チームのAI活用を主導
チームのAI活用を主導

 一方で、ヒアリングそのものは物理的な時間がかかり、絶対にスケールしない。だからこそ、それ以外の業務はAIで圧縮しようと、清水氏はチームへのAI導入を主導した。Claudeをエンジニア以外でも利用するため、勉強会を主催した。

 個人が作ったAIの仕組みは、その人の手元にとどまりがちである。同じものを別のメンバーが一から作り直すことにもなる。そこで、個々の知識を組織に還元するため、メンバーが作成したSkillやMCP serverを共有基盤に集約し、誰でも使える状態にした。

 MCP serverは当初、Google公式のものを使っていた。しかしうまく動かない場面があったため、AIを使って自作した。Google公式のMCPが直るまでの間のツールではあったが、こうした隙間家具的なツールが1日足らずで作れたことは、AI時代ならではである。

次のページ
検証サイクルに開発を従属させる

この記事は参考になりましたか?

Developers Summit 2026 Summer セッションレポート連載記事一覧

もっと読む

この記事の著者

森山 咲(編集部)(モリヤマ サキ)

CodeZine編集部所属。

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

井原 淳一(イハラ ジュンイチ)

 雑誌やフリーペーパー(紙媒体)Webなどで、料理、人物(インタビューやポートレート)、商品撮影をしています。

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー