開発者にもコーディングエージェントにも働きやすい環境を整える

プロダクトヒストリーカンファレンス2026の登壇資料です

Transcript

1. 開発者にも コーディングエージェントにも 働きやすい環境を整える PRODUCT HISTORY CONFERENCE 2026 Day1 6/26(金) Stage B 15:00–15:20 株式会社HRBrain　鈴木 悠大
2. 鈴木 悠大 株式会社HRBrain　専任執行役員 CTO 2013年 東京理科大学を卒業し、サイバーエージェントへ新卒入社 Ameba 事業で、スマホアプリ基盤やアメーバブログ、新規プロダク トをバックエンド中心に開発 2016年 HAROiD（日テレ×バスキュール）へ。dボタン連動など高ト ラフィックな放送局向け SaaS を、フロント〜インフラまで担当 2018年 HRBrain 入社・CTO 就任。創業初期からプロダクト開発を牽 引し、いまも自ら実装する Platform プロダクト開発 AI PRODUCT HISTORY CONFERENCE 2026 自己紹介 2
3. Power to the People — 企業はますます人なり 会社名 株式会社HRBrain 設立 2016年3月 代表 代表取締役 堀 浩輝 事業内容 タレントマネジメントクラウド「HRBrain」の開発・提供 拠点 東京・大阪 技術スタック Go / TypeScript / React / Google Cloud PRODUCT HISTORY CONFERENCE 2026 会社紹介 3
4. PRODUCT HISTORY CONFERENCE 2026 HRBrain ｜ Talent Experience Platform 4
5. 従業員の「期待」と「実感」のギャップを可視化し、注力すべき組織課題と優先順位を明確にする。 PRODUCT HISTORY CONFERENCE 2026 組織診断サーベイ ｜ EX Intelligence 5
6. 自社でも HRBrainを使う。EXサーベイも実施している。 自分たちで使うから、プロダクトの直すべき点に気づける。組織 の課題にも先に向き合える。 PRODUCT HISTORY CONFERENCE 2026 カスタマーゼロ：自社が最初の顧客 6
7. 半期に一度、開発者へ向けて DXに関するサーベイを実施してき た。 集まった回答をもとに、開発の妨げになっているものを探ってき た。 PRODUCT HISTORY CONFERENCE 2026 開発者体験も半期のサーベイで測ってきた 7
8. 01 Monorepo 全プロダクトを1つのリポジトリで管理。共通化や横断変 更が容易になり、影響範囲も一目で把握できる。 02 ブランチデプロイ PRごとに検証環境を立ち上げる。変更したサービスだけ をデプロイし、個別URLで確認。 03 Feature Flag main に入れたコードをフラグで隠す。デプロイと公開の タイミングを分けられる。 04 Tilt 依存サービスを気にせず動かせる。必要なものがまとめて 立ち上がる。 05 Cloud Workstations 手元PCに寄せず、クラウド上の標準環境で重い構成を動か す。 06 OpenTelemetry トレースやメトリクスを入れやすいよう、自社ライブラリ も整備。 PRODUCT HISTORY CONFERENCE 2026 開発者のために環境を整えてきた 8
9. それでも、わざわざ報告するほどでもない引っかかりを、開発者 が飲み込んで進んでしまう。 たとえば、古いドキュメントを見ていた。手順が一部だけ違って いた。そういう細かいズレは、半期のサーベイでは拾いきれな い。 本当は、週次やタスクごとに聞きたい。でも人にその頻度で聞く と、サーベイそのものが負担になる。 PRODUCT HISTORY CONFERENCE 2026 半期サーベイでは拾えない声がある 9
10. AIが実装者になった この1年で、開発の前提が変わった。 コードを書く相手が、人だけではなくなった。
11. 開発者のために整えた環境の多くが、AIにもそのまま役立っていた。 人のための投資が、AIの実装を支える土台になっていた。 PRODUCT HISTORY CONFERENCE 2026 人のために整えた環境がAIにも効いた Monorepo ― 全体を横断で見渡せる。AIもコンテキストをつかみ、影響範囲を追える - Cloud Workstations ― 標準環境がクラウドにある。手元のPCを閉じても、クラウド上で AIは動き続ける - ブランチデプロイ ― PRごとに検証環境。AIの変更もその場で動かして確かめられる - 11
12. 手は速く、理解も早い。でも入社初日の人と同じだ。 まだ自社の前提は知らない。設計判断の背景もチームの暗黙知 も、毎回こちらから渡す必要がある。 PRODUCT HISTORY CONFERENCE 2026 AIは「優秀な新人の1日目」に近い 12
13. 初日の人でも最初に見る場所が分かる。迷ったときは判断の手が かりへ戻れる。 AIにも同じ入口を用意する。やることは人のオンボーディングと 変わらない。 PRODUCT HISTORY CONFERENCE 2026 初日の新人でも迷わない環境をつくる 13
14. 人の新人と同じように、順番に整えていく。 コンテキストを渡す 規約ファイル / README / ADR。 規約や前提だけでなく、設計判 断の背景までたどれる。 道具に接続する MCP / 社内ツール。散らばった 情報を、安全な経路でその場で 取りに行く。 長いタスクを支える仕組み をつくる サブエージェント / ハーネス / 評 価役。長いタスクでも、計画・ 実装・検証の流れが崩れない。 PRODUCT HISTORY CONFERENCE 2026 AIオンボーディングは3つの層で整える 14
15. 良かれと思って増やしたルールが、いつの間にかAIの判断を鈍らせる。これが、いわゆる context rot （コンテキストの腐敗） 。 だから足すにも消すにも根拠がいる。 PRODUCT HISTORY CONFERENCE 2026 コンテキストは足しすぎると効かなくなる よくある光景 育ちすぎた規約ファイル 古い前提、重複、矛盾したルール。大事な判断基準が 埋もれていく。 あるある 全部消したら、なぜか直った 何が悪さをしていたかは分からない。また手探りで育 て直す。 15 →
16. リポジトリの構造も検証手順も分かる。失敗したときに次を見る 場所が分かる。 ここまで整えば、一連の実装をまるごと任せられる。 PRODUCT HISTORY CONFERENCE 2026 環境を整えるほどAIに任せられる 16
17. 社内では「overnight-coding」と呼んでいる。 夜のうちにAIが実装し、朝に人がレビューする。 計画 ― 方針と作業範囲を先に切る 実装 ― AIが夜のうちに進める 評価 ― 朝に人と別の評価役が成果を見る PRODUCT HISTORY CONFERENCE 2026 夜のあいだにも実装が進むようになった 17
18. 人なら「ここが分かりません」 「この手順がつらいです」と言って くれる場面がある。 AIは何も言わず、自律的に動き、探索し、推測で補い、実装まで 持っていく。 一見うまくいったように見えて、実は設計意図をつかめないまま 進み、あとで作り直しになることも多い。 PRODUCT HISTORY CONFERENCE 2026 AIは詰まりを言葉にしないまま進む 18
19. ログと成果物には、詰まりが残らない 詰まりはタスク単位のサーベイで その場で残してもらう 迷った瞬間にしか、正確には残せない 19
20. 従業員体験 EX 、開発者体験 DX と測ってきた。次は、エージェ ント体験 AX も測る。 人に毎回サーベイを頼めば、それ自体が負担になる。エージェン トはストレスなく回答してくれる。何度でも、どこで詰まったか を残せる。 PRODUCT HISTORY CONFERENCE 2026 エージェントなら、タスクごとに聞いても 負担にならない 20
21. わざわざ聞きにいかない。フックで開発フローに仕込み、節目ごとに自動で残す。 質問は節目ごとに変える。そして必ず、改善依頼をひとつ添えてもらう。 PRODUCT HISTORY CONFERENCE 2026 開発フェーズにAXサーベイを織り込む 計画 ― プラン確定時に、方針・前提は足りているか - 実装 ― push 時に、どこで詰まり、何に誤誘導されたか - サブエージェント ― 完了時に、そのタスクで何に詰まったか - 21
22. 9人・一部のメンバーが、半月ためしただけで 305回ぶんの節目から、 AIの詰まりが見えた 人には毎回聞けない。エージェントだから、何度でも貯まる 22
23. 実装が一区切りした push の節目に、エージェント自身がこの1行を残す。 { "ease": 3, "blockers": [ {"type": "docs_missing", "weight": 45, "comment": "権限まわりの設計判断がどこにも書かれていない"}, {"type": "stale_context", "weight": 30, "comment": "古い手順に沿って実装しbuildが通らなかった"} ], "note": "設計意図がコードから辿れず、推測で実装した", "improve_request": "権限まわりの設計方針を 規約ファイル / ADR に明記してほしい" } app / phase / branch は自動で付く。書かせず、フックの節目にエージェント自身が残す。 PRODUCT HISTORY CONFERENCE 2026 迷いがデータに残る 23
24. 9人・305回の節目を集計。全体 ease は 3.84、その詰まりの内訳がこれ。 ドキュメントがない 22% 設計判断が残っていない 11% 既存コードが複雑 21% サービス間の調整が必要 7% 環境セットアップが手間 6% ツールが未整備 6% その他 27% 「次に直す場所」を、感覚ではなくデータで見にいける。 　ease は自己申告。個人評価には使わない。 PRODUCT HISTORY CONFERENCE 2026 AIが一番詰まったのは「ドキュメント不足」 33% ドキュメント不足 24
25. 最も多かったのは、2つが重なったときだった。 ドキュメント不足 × 既存コードの複雑さ この2つが同時に出るのが、最多のペア（20回） 。 一番根深い詰まりは、巨大な既存コードから「なぜ」を見つけられないことだった。 PRODUCT HISTORY CONFERENCE 2026 詰まりの原因は1つじゃなかった 25
26. やってみて、分かった AIが詰まるのは手順より 「なぜ」＝設計意図だった 過去の判断をコードから辿れていないことが多かった 26
27. 使い始めのいまは docs 要望が中心。穴が埋まるほど、次の詰まり（テスト・環境）が見えてくるはず。 PRODUCT HISTORY CONFERENCE 2026 使った開発者から「穴が見える」と返ってきた AXサーベイが結構便利。ドキュメント化が足りない部分が見えてくる ― 社内の開発者 “ 27
28. 課題に応じて使い分ける。その場で済む詰まりはすぐ直し、横断で直すべき詰まりは集めて、プラット フォームで一度に直す。 AXサーベイ結果 plan / push / subagent ブロック要因・改善依 頼 → → その場で 開発者がすぐ見る 例 Notionの手順が古い → その場で直す docs を最新化する 集計して 集めて横断で見る 例 worktree 準備に毎回手間取る → 基盤側で一度に直す 全appに効かせる 集計に回す前に、別エージェントで機微情報を除く。個人評価には使わず、開発環境の改善だけに回す。自動化の範囲は調整中。 PRODUCT HISTORY CONFERENCE 2026 詰まりのデータで開発環境を直す 28
29. 返ってくるのは抽象的な感想だけではなく、そのまま着手できる具体的なタスク。しかも種 類はさまざま。 PRODUCT HISTORY CONFERENCE 2026 サーベイ結果を改善タスクに変える 設計意図を ADR / 規約ファイルに ― コードからは判断の背景が辿れない - ビルド系コマンドを sandbox 許可リストへ ― 毎回弾かれて反復が遅い - ローカルテスト手順を明記 ― DB起動・環境変数にチームの暗黙知が要る - 移行戦略を ARCHITECTURE.md に ― 旧基盤→新基盤が複数appにまたがる - 29
30. app ごとに直すのではなく、基盤側で一度直せば全員に効く。どれを横断で巻き取れるか は、AX が教えてくれる。 PRODUCT HISTORY CONFERENCE 2026 横断で効く詰まりはプラットフォームで一度に直す worktree の初期化を自動化 ― 依存セットアップの手作業をなくす（横断で最多の声） - ビルド系コマンドを許可リストへ ― go build / generate のたびに止まらない - codegen を CI と揃える ― 生成ツールのバージョン固定で生成物のズレを消す - 共通ヘルパを基盤に置く ― 各サービスが同じコードを書き写さない - シェル / CI の地雷を除く ― スナップショットの不具合や lint 設定を全体で直す - 30
31. AIのために直したドキュメントやADRは、入社したばかりの人に も効く。 最初に見る場所が分かる。 AIが迷った場所を直していくと、ドキュメントが自然と更新され 続ける。 PRODUCT HISTORY CONFERENCE 2026 AIが働きやすい環境は新人にも最高だった 31
32. PRODUCT HISTORY CONFERENCE 2026 まとめ 人には毎回は聞けない。エージェントなら、何度でも聞ける - だから、言葉にならない"詰まり"が見えるようになった - 一番の詰まりは、手順じゃなく 「なぜ」＝設計意図 だった - その詰まりが、声を上げなくてもプラットフォーム側に届くようになった - AIのために整えた環境は、そのまま開発者にも効いた - いまは「詰まりが見える」まで。直して ease が上がるかの効果検証はこれから - AIに任せるほど、この"見えない詰まり"は増えていく。だから、測り続け、改善し続けたい - 32
33. Power to the People, and Agents. AIをうまく活かして、良いプロダクトをつくりたい方へ。 エンジニア / プロダクトマネージャー / デザイナー募集中。ブースへお気軽に。 カジュアル面談はこちら