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

Transcript

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


2. 小西 裕介 (こにふぁー / @konifar)
 - 株式会社 Kyash で8年くらいプロダクトを作っています -

   2017年から1年半くらいはずっと Android Kotlin を書いていました - 最初の DroidKaigi 参加は 2015年。懐かしいですね！
3. None

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. ありがとうございました