コーディングエージェントで加速させるスキマエンジニアリング

Transcript

1. コーディングエージェント で加速させる スキマエンジニアリング
2. 自己紹介 野村朋生 / みそしる @miso_shiru_app 大阪大学 工学部 4年生 ぽちぽちのつどい 元副代表/創設メンバー NanobananaProで遊ぶの楽しい
3. はじめに
4. このセッションで話さないこと 便利で画期的な Tips の紹介
5. このセッションで話すこと コーディングエージェントを 「個人の道具」ではなく「チームの仕組み」 として、どう使ってきたか
6. 私の立場 PM歴 約1年 ジュニアエンジニアとして 試行錯誤しながら仕組みを導入
7. お断り これは 完成形の話ではありません 今も悩みながら 少しずつ前に進んでいる 途中の話です
8. スキマエンジニアリング
9. スキマエンジニアリングとは？ 聞いたことありますか......？
10. 造語です スキマエンジニアリング = 自由な時間に働くエンジニアによるエンジニアリング
11. よくあるプロジェクト構成 フルタイムメンバーが中心 副業・学生エンジニアは 部分的に関わる構成
12. 私たちのチームは違う 全員がスキマエンジニア 定例の開発MTG以外は 各自が好きな時間に開発
13. メンバー構成 学生エンジニア 大手企業副業エンジニア 経験も稼働時間も揃っていない
14. 実は珍しくない？ 学生団体内のチームなど 同じような前提のチームは 少なくないはず
15. 条件 はっきり言って 典型的な「良いチーム」の条件としては かなり不利
16. 日常的に直面する問題 ドメイン知識の共有不足 レビュー待ちによる停滞 認識のズレ コミュニケーションの遅延 今も解決できていない課題
17. それでも コーディングエージェントを前提に チームの設計を見直すことで 以前よりは確実に 前に進める感覚が生まれてきた
18. チームの理想
19. 参考にした指針 Google's Engineering Practices レビューを軸に スピードと品質の両立
20. Googleのルール ドキュメントには、次のように書かれています " コードレビューのリクエストに返信するまで の 最長の時間は一営業日です
21. 理想としては正しい ただし この理想は 「フルタイム前提」で設計されている
22. できるか？
23. 現実のギャップ 出来るわけない。 全員スキマ稼働で レビューを常に最優先で行うのは無理
24. AIレビュー
25. 結論 人間が速くなることを前提にするのをやめた
26. レビューが遅れる理由 1. 稼働時間が揃わない 2. レビュワー自身も実装タスクを持っている
27. 解決策 Claude Code Actions を使い AI を最初のレビュワーに固定
28. AIレビューのルール シンプルな4ステップ
29. ステップ1: PR作成 いつも通りPRを作る
30. ステップ2: AIレビュー Claude Codeにレビューさせる 即座にフィードバックが返ってくる
31. ステップ3: 修正 指摘ごとに 1コミットで修正 修正不要と判断したら → 理由をコメントで書く
32. ステップ4: 人間の最終チェック 人間は設計や責務分割など 本質的な部分に集中
33. この設計で変わったこと PR作成直後に 必ずフィードバックが返る 人間はより本質的なレビューに専念 レビュー待ちによる開発停滞の減少
34. AIを使う理由 AIが正しいからではない。 必ずすぐ返ってくるから
35. 結果 人間だけでは守れなかった 「1営業日ルール」を 仕組みとして満たせるように
36. 「書かなきゃ」を 仕組みで消す
37. 正直な話 コードを書くのは楽しい
38. でも... コミットメッセージやPR説明は 正直めんどくさい
39. ジレンマ " CL のディスクリプションは何が変更され、 なぜ変更されたのかを説明する公式記録で す。 この記録はバージョン管理の履歴に永続的に 残され、長期にわたって読まれます。
40. 結論 「ちゃんと書け」と言うのをやめる 書けてしまう仕組みを用意
41. 解決策 : カスタムコマンド Claude Code に2つのコマンドを用意 /commit - コミット案を自動生成 /pr - PR文を自動生成
42. この仕組みの効果 コミットの粒度がチーム全体で揃う PRの説明品質が安定する 「書かなきゃ」という**心理的ハードルが下がる*
43. 根本の考え方 人はサボるのではなく 続けられないだけ 続けられない作業は 仕組みで消すべき
44. 要件の曖昧さをAIで塞ぐ
45. 要件定義も同じ問題 スキマ稼働のPMとして 十分に詰めきれないまま タスクを振ってしまう
46. よくある失敗パターン 「なんとなく合意したつもり」 後から 認識ズレ として表面化
47. 曖昧さの影響 この曖昧さは レビューの質にも 直結
48. レビューの観点と要件 Google は 「設計」 「機能性」 「複雑性」 を重視 → 詳細な issue や要件が 　正しいソースとして機能すべき
49. /issue コマンド Feature / Fix / Chore の テンプレートをもとに AI と対話しながら要件を詰める
50. 3つの明確化 1. 何を作るのか 2. なぜ必要か 3. 実装案はどうなりそうか
51. MTGの使い方が変わる 従来： 仕様確認に時間を使う 今： 設計の議論に時間を使える 事前の言語化で実現
52. 正直なところ 要件の質は 今も改善途中 ただ、 「なんとなく」で 進めることは 確実に減った
53. デザインを 「後で」→「今」に
54. 前提 私たちのチームには 専任のデザイナーがいません
55. 以前のフロー MTGで要望を聞く ↓ 後日モックを作る ↓ 次のMTGで確認 1往復に1週間かかることも
56. 今のフロー Cursorのデザインモードで MTG中にその場でUI を触る リアルタイムで調整
57. 実際のシーン 「ここを少し右に」 「色を変えたい」 そう言われた 瞬間 に 画面で一緒に確認
58. 同期の密度 非同期が前提のチームだからこそ 同期の場の密度を 極限まで上げる ここに価値がある
59. まとめ
60. スキマチームの現実 「努力」だけでは 解決できない問題が多くある
61. 私たちが選んだ道 3つの選択
62. 選択1: 期待しすぎない 人に期待しすぎない 人間が速くなることは期待しない 構造的な問題として捉える
63. 選択2: 仕組み化 続けられない作業は仕組みにする 「ちゃんとやれ」ではなく 「やれてしまう」仕組みを作る
64. 選択3: AI前提の再設計 AI を前提にプロセスを組み直す 従来の方法を AIありきで再設計する
65. 変化 スキマエンジニアチームにとって AIはもはや便利ツールではなく 開発プロセスの一部 に
66. 今も続く試行錯誤 完璧ではない 今も改善途中 でも、確実に前に進んでいる
67. Qiita Advent Calendar 2024 同じ内容を記事にしました
68. ご清聴ありがとうござい ました