チーム開発について改めて考えたこと
DroidKaigi.collect { #26@Kanazawa } という勉強会に参加してきた。
テーマは「チーム開発」。
最近は個人開発や AI コーディングをすることも多いけど、結局プロダクトを長く育てるのって“チーム”なんだよな、と改めて実感する1日だった。
個人的に刺さった内容や、持ち帰った学びをメモ代わりにまとめておく。
「地ならし」の重要性を再認識した
コニファーさんの発表で一番印象に残ったのが地ならしという考え方。
開発がスムーズに進む状態を、最初に整えておくこと。
Output を効率よく出すための準備。
特に AI コーディング時代に入ってからは、この“準備を整えておくこと”の価値が以前よりずっと大きくなっている。
整理されていたポイントは大きく3つ。
- フィードバックループを短くする
- トライアンドエラーの回転数を上げる
- 個人の開発速度が上がる
- 例：Lint / Format、GitHooks、ClaudeCodeHooks、CICD（Lint→Test→Deploy）、RabbitCode などの自動レビュー
これは普段の自分の開発にも直結する内容で、
「“最初から整えておく”って大事なのに、忙しいと後回しにしがちだよな…」と反省。
- 考えることを減らす
メンバー（とAI）が“どこで迷うのか”を最初に潰す。
- Issue/PR テンプレ
- README の導線整理（導入、設計、方針）
- AGENTS.md / CLAUDE.md など AI 向けガイド
- タスク管理ツールとテンプレ
- ワーキングアグリーメント
- 定例とアジェンダの設計
「どこに情報があるか」「どこまでが OKか」「誰に相談すればいいか」
これらが“考えずにわかる状態”＝チームの生産性の底上げなんだなと納得した。
- 育てるフローを設計する
全部を最初に完璧にしようとしない。
大事なのは育てていける土台を作ること。
- 振り返りの場（週1くらいでOK）
- 意思決定者を決める
- ナレッジの棚卸しと共有
- AI やツールの変化にあわせて柔軟にアップデートする
「地ならしというより“土づくり”かも」という言葉が刺さった。
このニュアンス、すごく好き。
実装方針を守らせるには“言語化 × 機械化 × レビューの設計”
別の発表では「実装方針を守る仕組み」が話題に。
結論、必要なのはこの3つ。
- ルールの言語化
- コーディング規約アンチパターン
- 設計ドキュメント（責務の明確化）
- 機械的なチェック
- 静的解析
- lint / format
- 責務分離を強制するモジュール構造
- レビューの仕組み
- 人間レビューの負荷を減らす
- 感情が混ざらないようにする
- “指摘のポイント”の言語化でレビューの質を揃える
特に「人間のレビューはコストが高い」という話は共感。
AI のサポートでレビューを自動化していく方向性は今後ますます必須だと思う。
⸻
パネルトークで印象に残ったこと
自分に合う仕事はやってみないとわからない
Try & Error が結局一番強い。
夢中になれるものを複数抱えておくと、意外とリターンが返ってくるという話も面白かった。
やる気の差問題は“原因を聞く”のが大事
やる気が落ちている状態自体が危険信号。
そしてその理由は本人にしかわからない。
当たり前だけど、意外とできてないこと多いよな…と思った。
AI時代とチーム開発について思ったこと
AI が強い時代になったけど、
今日1日を通して感じたのは
結局、チーム開発における本質的なコミュニケーションは人間が担う部分が大きい。
AI がコードを書くのはどんどん当たり前になっていく一方で、
チームの設計、意思決定、方針の言語化、振り返りの習慣化などは
まだまだ“人間側の成熟”が必要な領域だと思った。
AI 時代だけど、だからこそ人間の“チームとしての動き”が問われるし、
これがあるから PM やリーダーの価値は消えないんだろうな、と。
言語化が難しいけど、そんな感覚。
余談
- Slido めちゃ便利そう。LT と相性いい。
- Google Meet の使い方の工夫、普通に参考になった。
- Unity の UaaL（Unity as a Library）知らなかったけど面白い。
まとめ
今日は、技術というより“チームとしてどう動くか”という話が多かった。
個人開発が多い自分にとっては、視点を広げてもらえる良い機会だった。
特に「地ならし」「育てるフロー」「考えなくていい仕組み」は
そのまま今の開発環境にも取り入れていきたい。
こういうイベント、やっぱり好きだわ。
また参加したい。
Discussion