チームごと賢くなるAI活用.pdf

Transcript

1. チームごと賢くなる AI 活⽤ その⼯夫、ローカルに眠らせない。
2. ⾃⼰紹介 kenf • Backend Engineer(4年くらい) • Belong ⼊社 2年弱 • 趣味 ボードゲーム、デジタルゲーム全般 • AI は主に Claude , Gemini を使ってます
3. 前提 チームとプロダクト • エンジニア 3 ⼈のチームで、販売管理システム（Go / クリーンアーキテクチャ）を開発 • JIRA でチケット管理、GitHub で PR レビューする通常の開発フロー AI ツールと使⽤歴 Gemini 使⽤歴 2 年以上 調査‧ドキュメント読解‧壁打ちなどの補助 Devin 使⽤歴 1 年 3 ヶ⽉ 仕様が明確なチケットを投げて PR を受け取る⾃律型 Claude Code 使⽤歴 1 年 実装の主⼒。設計‧調査を伴うタスクを対話しながら進める
4. 同じツールなのに、成果は⼈それぞれ かつて プロンプトの⼯夫、設定、使い⽅のコツ。 • 秘伝の Makefile 個⼈個⼈で知⾒が溜まっていく。 • 有識者だけが知っている⼿順書メモ ツールの使い⽅が上⼿い⼈、それほどでもない⼈ の⽣産性に差がつく。 いま この構造、⾒覚えがありませんか。 構造は同じ ── 属⼈化。 • ローカルにだけある AI 設定 • 脳内のプロンプト集
5. リポジトリ管理で「個⼈設定」から「チーム資産」へ リポジトリで管理する利点 project/ └── .claude/ # リポジトリにコミット ├── commands/ # フェーズ別の定型フロー ├── rules/ # ⽂脈で⾃動注⼊される規約 ├── skills/ # 実⾏可能な⼿順書 └── settings.json CLAUDE.md 1 レビューを通る AI への指⽰や⼿順が PR でレビューされ、品質 が担保される 2 # プロジェクトの説明書 履歴が残る 「なぜこのルールになったか」を Git で追える 3 全員の AI が同じ知識で⽴ち上がる clone した瞬間、誰の Claude でも同じ規約‧ ⼿順を知っている
6. CLAUDE.md ── プロジェクトの「読ませる README」 AI も⼈も最初に読む、プロジェクトの説明書 • 技術スタックとアーキテクチャの全体像 • タスク別の必読ガイドラインへの導線 • コーディング規約‧テスト規約 • 「よくある落とし⽳」8 選 ## よくある落とし⽳ 1. SQLBoiler モデルを編集しない 2. 変更後はコード⽣成を実⾏ 3. テスト DB: 5433、開発 DB: 5432 4. time.Now() でなく ctime.Now(ctx) 5. マイグレーションで権限を付与 ... 気づき：新⼈へのオンボーディング資料と AI 向け説明書は、同⼀物になる。
7. スキル ── ⼿順書のコマンド化 add-migration-query release-diff-check create-pr マイグレーション＋ロールバック ＋init.sql 更新。⼿順書どおりの ⼀式を⽣成 Git のコミット履歴と JIRA リ リースの完了チケットを双⽅向突 合してレポート タイトル‧本⽂‧Reviewers の 規約に準拠した PR を作成 ほか、エラーコード追加‧gomock の書き⽅‧ドメインモデル図の同期など、全 10 スキルをリポジトリで管理 「ドキュメントに書いてある⼿順」から「頼めば実⾏される⼿順」へ。 ⼿順が存在する場所そのものが変わる。個別のドキュメントではなく、リポジトリから把握できる。
8. ルール ── ⽂脈に応じた⾃動注⼊ --paths: - "module/**/domain/**/*.go" --# Domain Constructors Rules ## 1. New と Reconstruct の役割分担 ## 3. 時刻の受け取り ## 4. 跨集約の調整はドメインサービスで⾏う パスにマッチしたときだけ発⽕ domain 層を触るとき → ドメイン設計規約が注⼊される。 テストを書くとき → go-testing.md が注⼊される。 全部を常に読ませない 必要な規約を、必要な場⾯でだけ。 コンテキストを浪費せず、規約の精度も上がる。
9. 使い分け ── 任せる AI と、隣に座る AI Devin（任せる） ⼈ + Claude（隣に座る） 仕様が明確で完結している定型作業 設計判断‧調査を伴う複雑なタスク 例 typo 修正、依存更新、既存パターンの横展開 新規ドメイン設計、跨集約の変更 ⼈の関与 チケットを投げて、PR をレビューするだけ 対話しながら⽅針を随時修正 向いているタスク 軸は「仕様が⾃明かどうか」。 往復が発⽣しそうなタスクは、最初から⼈が横に付いた⽅が速い。
10. 「作った後」の⼿間が違う Devin チケット投⼊ → 実装 → PR → レビューコメント → ⾃動で対応して push → マージ 実⾏者の作業はチケット作成とレビューだけ。往復から解放される。 ⼈ + Claude 依頼 → 実装 → PR → レビューコメント → ⼈が拾って再依頼 → 対応 →（繰り返し） セッションの外で起きたこと（PR コメント）には反応しない。都度、⼈が指⽰を出す。 実装の難しさだけでなく、レビュー往復まで含めた「総⼿間」で選ぶ。
11. 週次定例での「AI コーナー」 仕組みを作っても、使いこなしは⾃然には広がらない。 週次定例に AI コーナーを常設し、今週試したこと‧うまくいった使い⽅‧新機能の情報を持ち寄って共有して いる。 個⼈の発⾒ → 定例コーナーで共有 → .claude/ に固定 → 全員の AI が賢くなる 専⽤の会を⽴てない チーム資産への⼊⼝ 既存の定例のついでという軽さだから続く。 準備コストが低く、⼩さなネタでも出せる。 コーナーで共有された使い⽅が、スキルや CLAUDE.md への追記として .claude/ に還流する。
12. 運⽤して分かったこと 1 効いたこと：ラフに追加する運⽤にすることで、スキルが拡充した 2 できていないこと：メンテナンスができておらず古いスキルが残る claude の進化で陳腐化するものもある。(phase を分けた実装、/code-review スキル) 3 レビューの扱い：AI も⼈間の PR も扱いを変えず精査する AI も⼈の PR も同じ⽬線でレビューする
13. まとめ 1 知識は .claude/ に固定する スキルやルールを書くほど、チームの知識はレビュー可能‧継承可能になる。 2 タスクを⾔語化できると Devin 任せで実装者負担が減る 「AI に任せられるか」は、タスクの⾔語化レベルを測るリトマス試験紙でもある。 3 定例の AI コーナーは持ち寄る場、.claude/ は固定する場 個⼈の発⾒ → 共有 → 資産化のループが「チームごと」賢くなる仕組み。 明⽂化された知識は、AI がいなくなっても残るチームの資産。
14. ご清聴ありがとうございました！