はじめに
こんにちは。カウシェでバックエンドチームのエンジニアリングマネージャーを担当しているs.ichijima (@shinichiji) です。
カウシェでは2025年を通してLLM活用に取り組んできました。関連記事として、上半期の振り返りを書いた「カウシェ開発チームのリアルなLLM活用上半期レポート」、CTOのikeが全社視点で書いた「AIで開発効率2倍に挑戦中」もあります。
本記事では、直近半年の成果を簡単に振り返った上で、今後のAIを使った開発におけるボトルネックと、その解決の方向性について考えます。
直近半年の成果
カウシェの開発組織では生産性の指標として、1人あたりPR数をウォッチしています。
ここ半年で見ると、6〜8月は足踏みしていたものの、9月以降順調にPR数のベースラインが上がりました。
具体的に何をやったかは弊社CTOであるikeのnoteや、カウシェのテックリードの1人でもあるuoのAI開発の生産性を上げる「小さく作る」アプローチを参照ください。
次のボトルネックはどこか
カウシェでは、次の半年で1人あたりPR数/日を現在の2.7から3.5に上げることを目標にしています。
では、0.8件増を達成するために何がボトルネックになるでしょうか。
PR数が増えれば増えるほど、レビューしなければならない数は増えます。稼働時間に限界がある以上、1日の総レビュー時間を短くできないと間違いなく頭打ちになると考えています。
つまり、今後を見据えてレビュー工数を減らすことが必要です。では、どうすれば減らせるのでしょうか。
自由記述から穴埋め・選択式へ
レビュー工数を減らすと一口に言っても、具体的に何をすればいいのでしょうか。
本番で動いているコードに変更を加えるので、何もチェックすることなくmergeすることはできません。したがって以下のアプローチが考えられます。
- 人間がレビューするPR1件あたりの時間を減らす
- 人間がレビューするPR数自体を減らす
どうすればこれを実現できるでしょうか。
私はこの問いを考えるとき、学生時代の試験を思い出しました。試験には自由記述式、穴埋め式、選択式がありますが、それぞれ解く側の負担も、採点する側の負担も違います。実装とレビューの関係も同じ構造ではないか、と考えました。
自由記述式の問題は、解く側の自由度が高く、どのように書いてもよいです。その分、アウトプットのブレは大きく、採点する側の負担も大きくなります。模範解答があっても、採点者によってブレが出ます。
穴埋め式の問題は、空欄を埋めるだけです。文脈が与えられているので、解く側はフォーカスすべき箇所が明確で、採点する側も「正しい語句が入っているか」や、より小さいスコープでの正誤を見ればよいです。自由記述式よりは採点も楽になります。
選択式の問題はさらにシンプルで、選択肢の中から選ぶだけです。採点も機械的にできます。
普段のプロダクト開発における実装においても、同様の考え方を適用できると考えています。
大きなタスクをそのまま実装すると、自由記述のPRになります。実装者は設計、DBスキーマ、テストなど多くのことを考えなければなりません。レビュワーも全体のコンテキストを把握した上で判断する必要があり、確認のためのやりとりが増えます。結果として、1件あたりのレビュー時間が長くなります。
タスクを小さく切って実装すると、穴埋めに近いPRになります。「既存のAPIと同じ構造で、エンドポイントを追加し、中身をこういった処理にする」なら、レビュワーはより小さいスコープで妥当性を確認すれば済みます。そのため1件あたりのレビュー時間が短くなります。
さらにパターンが明確なものは、選択式に近いPRになります。「ProtoにXXXの定義を追加する」「テーブルXXXにYYYというカラムを追加する」のように、やることが決まっていれば、レビューは機械的に判定でき、自動承認も可能になります。したがって人間がレビューするPR数自体を減らせます。
つまり、PRを穴埋め・選択式に近い形にしていくことで、レビュー工数を削減できる余地があるのではと考えています。
ただし、すべてのコードを穴埋めや選択式にできるわけではありません。DDLやビジネスロジックの新規追加など、しっかり見るべき領域は自由記述のまま残ります。一方で、適切なガードレールが存在するなら、typoの修正や既存パターンに沿った変更は穴埋め・選択式にできます。コードベースのどの領域を自由記述のままにして、どこを穴埋め・選択式にするか。この区別を設計することが、制約を設計するということです。
制約を設計する
では、どうすればPRを穴埋め・選択式に近づけられるのでしょうか。
それは組織やチームとして制約を設計することです。
試験で言えば、問題を作る側の仕事に近いです。良い穴埋め問題を作るには、何を空欄にして、何を文脈として与えるかを設計しなければなりません。良い選択式問題を作るには、妥当な選択肢を用意しなければなりません。
これは個人の努力ではなく、チームとしてのプロセス設計です。組織やチームがフォーマットを決めることで、自然と制約が生まれます。
具体的には、以下のようなプロセスが必要です。
1. タスクを適切な粒度に切るルールを決める
大きすぎると自由記述になります。小さすぎるとオーバーヘッドが増えます。チームとして「このくらいの粒度で切る」という基準を持つことが重要です。
2. パターンを認識する
「これは前にもやった形だ」と気づくことです。コードベースの中にある繰り返しを見つけます。
3. パターンを言語化・明文化する
暗黙知を形式知にします。CLAUDE.mdや.cursorrulesに落とし込み、「このパターンならこう書く」を共有可能にします。これがチームの資産になります。
4. パターンに当てはめる運用を回す
新しいタスクが来たとき、既存パターンに該当するか判断します。該当するなら「穴埋め」として渡します。
5. 採点基準を決める
「このパターンならこうなっていればOK」を定義します。自動承認の条件を明確にします。
これが実現すれば、レビューの一部は自動化できます。人間のレビューは、自由記述に近いPR、つまり新しいパターンや判断が必要なものに集中できるようになります。
これらは順番に積み上がっていくものです。まずは適切にタスクを分割すること、パターンを認識して明文化することが最重要だと考えています。
おわりに
今年は問題をハンドリングできる単位に小さく刻んで対応することで成果が出ました。次に取り組むべきは、実装を自由記述から穴埋め・選択式に変えていくことだと考えています。
これは言い換えれば、抽象を具体に変換する作業をチームで共有できる形にするということです。シニアエンジニアが経験で身につけているパターン認識や具体化の力を、チームの資産にしていく。それが制約を設計するということだと考えています。
チームとして作るべきものの単位を揃え、パターンを明文化し、制約を設計する。このプロセス設計がこれからの開発組織に求められるものだと感じています。
カウシェは採用強化中です！
現在、エンジニア・デザイナー・QAエンジニア・PdMなど、プロダクト開発に関わる方中心に様々なポジションで募集しております。
▼募集ポジションはこちら
▼採用ページはこちら
▼カジュアル面談希望はこちら
技術の力で大きなインパクトを生みたい方、プロダクト系の職種はほぼ全方位で採用中なので、ぜひカジュアルにお話ししましょう！
株式会社カウシェのProduct開発チームによる技術ブログです。 「日常に楽しさを」「新しい生活圏のカタチをつくる」をミッション・ビジョンに掲げ「誰かと一緒に」を楽しむソーシャルEC、カウシェを開発しています。 enjoy-working.kauche.com
Discussion