この記事は株式会社ドットログによる
コンストラク体操日記 Advent Calendar 2025 の 21日目の記事です。

はじめに

この記事では、コーディングエージェントの便利な Tips を紹介しません。
代わりに、コーディングエージェントを 個人の生産性を上げる道具ではなく、チームを前に進めるための仕組み として、どのように使ってきたのかを振り返ります。

PMを担当してから約1年。
ジュニアエンジニアとして、試行錯誤しながら導入してきた仕組みと、その判断の背景をまとめたログです。

完成形の話ではありません。
今も悩みながら、少しずつ前に進んでいる途中の話です。

スキマエンジニアリングとは？

「スキマエンジニアリング」という言葉を聞いたことはあるでしょうか。
おそらくありません。私が勝手に作った言葉だからです。

ここでは、

スキマエンジニアリング = 自由な時間に働くエンジニア、またはその働き方

と定義します。

多くのプロジェクトでは、フルタイムで稼働するメンバーが中心にいて、副業や学生のエンジニアが部分的に関わる構成になることが多いと思います。

一方、私が参加しているプロジェクトでは、全員がスキマエンジニアです。
定例の開発MTG以外は、各自が好きな時間に開発を進めています。

メンバーは学生からメガベンチャー、大手企業の副業エンジニアまで様々。
経験も稼働時間も揃っていません。

学生団体や副業チームなど、同じような前提のチームは少なくないはずです。

はっきり言って、典型的な「良いチーム」を作る条件としてはかなり不利です。
実際、ドメイン知識の共有不足やレビュー待ちによる停滞は、今も日常的な課題です。

それでも、コーディングエージェントを前提に設計を見直すことで、以前よりは確実に前に進める感覚が生まれてきました。

Google流の理想、スキマの現実

非同期中心のチームでは、「何を良い開発とするか」を言語化しないと判断がブレます。

私たちは、その指針として
「Google's Engineering Practices documentation」を参考にしました。

特に意識していたのは、レビューを軸に スピードと品質をどう両立させるか という点です。

ドキュメントには、次のように書かれています。

コードレビューのリクエストに返信するまでの最長の時間は一営業日です
（つまり遅くとも翌朝一番に返信すべきです）。

理想としては正しい。
ただ、その理想は「フルタイム前提」で設計されています。

出来るわけない。

全員スキマ稼働で、レビューを常に他のタスクより最優先で行うことは難しい。

だから、割り切る必要がありました。

最初のレビュワーは AI に任せる

結論から言うと、人間が速くなることを前提にするのをやめました。

レビューが遅れる理由は明確です。

稼働時間が揃わない
レビュワー自身も実装タスクを持っている

そこで、Claude Code を使い、AIを最初のレビュワーに固定しました。

ルールはシンプルです。

PRを作る
Claude Codeにレビューさせる
指摘ごとに1コミットで修正（直さない場合は理由を書く）
人間が最終レビューする

この設計で変わったことは大きく3つあります。

PR作成直後に必ずフィードバックが返る
人間は設計や責務分割、要件など、本質的な部分に集中できる
レビュー待ちによる停滞が減った

AIが正しいから使っているのではありません。
必ず返ってくるから使っています。

結果的に、人間だけでは守れなかった「1営業日ルール」を、仕組みとして満たせるようになりました。

「書かなきゃ」を仕組みで消す

コードを書くのは楽しい。
でも、コミットメッセージやPR説明を書くのは正直めんどくさい。

重要だと分かっていても、続けるのは難しい作業です。

「Google's Engineering Practices documentation」には、次のように書かれています。

適切な CL のディスクリプションを書く
CL のディスクリプションは何が変更され、なぜ変更されたのかを説明する公式記録です。
この記録はバージョン管理の履歴に永続的に残され、長期にわたって読まれます。

そこで、「ちゃんと書け」と言うのをやめました。
代わりに、書けてしまう仕組みを用意しました。

Claude Code に以下のカスタムコマンドを用意しています。

/commit
/pr

変更内容を解析し、意味のまとまりごとにコミット案やPR文を生成します。

この仕組みで、

コミット粒度が揃う
PRの品質が安定する
書くことへの心理的ハードルが下がる

といった効果がありました。

人はサボるのではなく、続けられないだけです。
続けられない作業は、仕組みで消すべきだと感じています。

要件の曖昧さを AI との対話で塞ぐ

要件定義も同じ問題を抱えていました。

スキマ稼働のPMとして、十分に詰めきれないままタスクを振る。
「なんとなく合意したつもり」が、後から認識ズレとして表面化する。

この曖昧さは、レビューの質にも直結します。

「Google's Engineering Practices documentation」では、コードレビューにおける観点として、「設計」「機能性」「複雑性」 などを挙げていますが、それらについてレビュワーが確認する際、詳細かつ正しいソースとしてissueや要件は機能すべきです。

そこで、/issue コマンドを用意し、
Feature / Fix / Chore のテンプレートをもとに AIと対話しながら要件を詰める ようにしました。

何を作るのか
なぜ必要か
実装案はどうなりそうか

これを事前に言語化することで、
定例MTGでは「仕様確認」ではなく「設計の議論」に時間を使えるようになりました。

要件の質は、今も改善途中です。
ただ、「なんとなく」で進めることは確実に減りました。

デザインを「後で」から「今」に持ってくる

私たちのチームには、専任のデザイナーがいません。

以前は、
「MTGで要望を聞く → 後日モックを作る → 次のMTGで確認」
という流れで、1往復に1週間かかることもありました。

今は、Cursorのデザインモードを使い、MTG中にその場でUIを触ります。

「ここを少し右に」「色を変えたい」
そう言われた瞬間に、画面で一緒に確認する。
このような時間の使い方が最近はできるようになりました。

非同期が前提のチームだからこそ、
同期の場の密度を極限まで上げることに価値がありました。

コーディングエージェントは、チームを少し前に進める

スキマで働くチームでは、「努力」だけでは解決できない問題が多くあります。

だから私たちは、

人に期待しすぎない
続けられない作業は仕組みにする
AIを前提にプロセスを組み直す

という選択をしてきました。

「出来るわけない」と思っていたことが、
設計を変えることで「出来てしまう」状態に変わる。

コーディングエージェントは魔法ではありません。
でも、チームを少し前に進める力にはなる。

スキマで働くチームにとって、
コーディングエージェントはもはや便利ツールではなく、
開発プロセスの一部になっています。