チーム開発の “地ならし"

DroidKaigi.collect { #26@Kanazawa } 共催 GDGoC KIT
https://droidkaigi.connpass.com/event/371437/

Transcript

1. チーム開発の “地ならし”
 DroidKaigi.collect { #26@Kanazawa }
 2025/11/15 (土)
 @konifar

2. 小西 裕介 (こにふぁー / @konifar)
 - 株式会社 Kyash で8年くらいプロダクトを作っています - 2017年から1年半くらいはずっと Android Kotlin を書いていました - 最初の DroidKaigi 参加は 2015年。懐かしいですね！
4. “地ならし” とは
 - 語源 = 地均し - 土地を平らに整え、建物を建てられる状態にする作業 - 例: 草を刈る / 石・障害物を取り除く / 地面の高低を整える - チーム開発においては、開発がスムーズに進む状態を最初に整えること
5. なぜ “地ならし” ？
 - チームのアウトプットの最大化のため - 最終的にユーザーに届ける価値を最大化するために、いかに 無駄なく早くよいもの を作っ ていけるかを皆考えている - アウトカムの最大化は大事な一方で、エンジニアがコントロールして成果を出しやすいのは アウトプットの最大化 - まずはここを徹底的にやりきるのが大事 ──── プロとして──── - AIコーディングエージェントの普及により、 整備の重要性が増している - “土台が揃っているかどうか ” でアウトプットの質も安心感も大きく変わる
6. “地ならし” の3つの考え方
 1. フィードバックループを短くする 2. 考えることを減らす 3. 育てるフローを設計する
7. 1. フィードバックループを短くする

8. 1. フィードバックループを短くする
 - トライアンドエラーのスパンを短くして個々人の開発速度を上げる - ビルドせずに実装ミスに気づく - デプロイせずにローカルで確認する - ニンゲンのレビューを待たずに AIが自動レビューする - 途中からではなく最初から整備しておくのが大事 - 早く土台を作って育てていく
9. このあたりは必須でやっておく
 - Lint / Formatter の導入 - まずはルールは適当でもよいので自動で動く状態にすること - Git Hooks や Claude Code Hooks の整備 - CI/CD (Lint => Test => Deploy) の構築 - 検証環境 の作成も含む - 自動コードレビューの導入 - 2025年11月時点だと、Geminiなどは無料で導入できる https://speakerdeck.com/kgmyshin/xin-gui-kai-fa-woshi-merutokiniyarubekikoto 

10. 2. 考えることを減らす

11. 2. 考えることを減らす
 - メンバーや AI がいちいち考えないといけないことを減らす - 「どこを見たらいいのかな」 - 「どこにどう実装すればいいかな」 - 「どこで誰に相談すればいいかな」 - システムとチームの考えることを分けて一般化する
12. このあたりは必須でやっておく
 - システム - Issue / PRテンプレートの作成 - README の整備 - 特に導入と設計まわりを書いておくこと - AGENTS.md / CLAUDE.md の作成 - チーム - タスク管理ツールの選定とテンプレート作成 - MCP で見れるものがオススメ - ワーキングアグリーメントの作成 - 定例会議の整備とアジェンダ作成
13. 3. 育てるフローを設計する

14. 3. 育てるフローを設計する
 - すべてを最初に “地ならし” しようとしないこと - 大事なのは土台を作って育てていける状態にすること - 特にAIは秒進分歩。定期的に改善していく前提に立つ - そういう意味だと “地ならし” というより “土作り” に近いかもしれない - GitHub などコードで管理してチームメンバーがコントリビューションし、レ ビューできる状態にしてから育てていく - そのとっかかりとなるフローの設計が大事
15. このあたりは必須でやっておく
 - 振り返りの場を作る - 1週間に1回くらいは入れたほうがいいと思う - 一歩ずつでよいので、昨日より今日、今日より明日がよくなる実感 を作っていく - 意思決定者を決める - 皆で話し合うのは大事だが、合議では物事が進みにくい - 最後に決めるリーダーを明確にするほうがよい - ナレッジ共有の場を作る - これは今は振り返りとは別で設定したほうがよいと思う - モブプロやペアプロのような形式でもよいが、スラッシュコマンドやサブエージェントなど何か チームの共 有資産としたほうがよいものがあれば取り込んでいける場 を作る - ただし過度な共通化はむしろ悪影響になるので、共通化したものの振り返りも忘れずに
16. さいごに

17. “地ならし” というより “土作り”。耕していこう
 - 「途中からやろう」ではなく最初から整備しておくほうが絶対によい - その上で、最初から完璧にしなくてもいい - 仕組みとプロセスで、チームで改善できる土台を作ておくのが大事 - 色々書いてきたが、自分もスマートにできているわけではない - 振り返って失敗したなと思って、次はこうするぞをアップデートし続けてきている - 今回の内容も2025年11月時点でのスナップショットに過ぎない
18. ありがとうございました