AI活用を前提とした
チーム開発での生産性

Kurogoma4D

株式会社Sun Asterisk - Senior Engineer / DevRel
X: @Kurogoma4D

前提

どんなプロジェクトの話か

前提

  • Sun* はクライアントワークを中心にやる
  • 今回はその一例、自分が入っているプロジェクトのはなし
    • クライアント名・プロダクト名は伏せます
  • 開始当初からAI駆動全開でやってます
    • 2025/7〜10 要求まとめ・ビジネス的決定を含む要件定義期間
    • 2025/10〜 開発期間
  • アジャイルスタイル、毎週スプリントプランニングをやっている

スプリントプランニングの内容

  • リーンコーヒー（のような）形式での前スプリントの振り返り
  • 次スプリントへのタスク追加
lean-coffee

生産性向上のために
やってみたこと

① アセットをなるべく GitHub に寄せる

課題

  • 情報源が分散すると（人でも AI でも）良くない
  • 共有に Notion を使うが、MCP 経由より gh CLI のほうが速くて正確なのでは

良かったこと

  • Issue にタスクを集約、それを前提とした Claude Code ワークフローを軽量に組めている
  • 調査から Issue を作る Skill、Issue を参照して実装・セルフレビュー・PR 作成まで行う Skill など

① アセットをなるべく GitHub に寄せる

flow

  • 厳密にはPRを上げる前にClaude Codeにセルフレビューを行わせる
  • このチームではPRマージ前に人の動作確認・レビューが入る

② 人間の業務の自動化を試験導入

課題

  • PR のレビュアーを誰にすればいいかわからない
  • AI レビューの観点をレビュー時に更新しなければならない

やってみたこと

  • 各メンバーの専門性をスコア化し、PR に対し自動でレビュアーをアサイン
  • PR スレッドで @learn frontend とコメントするとセルフレビューの観点に追加
良かったこと
レビュー前後で手が止まるリスクが減り、レビュアーはレビューに集中すればよくなった

③ 前スプリントの実績を可視化

課題

  • 振り返りの場で、前スプリントに生産性よく動けていたかがわからない

やってみたこと

  • プランニング前に Claude Code に GitHub の情報を集計させる
  • closed issue / created PR / merged PR の数とサマリを出す
良かったこと
ベロシティ計測の代わりとして導入、個人的にはなんとなく状況が見えるようになった（スプリント内で作成したissueと閉じたissueの割合など）

③ 前スプリントの実績を可視化

以下のような流れのAgent Skill（抜粋）を用意

## ワークフロー

### Phase 1: 期間計算

### Phase 2: GitHub 集計

# 例

```bash
# Closed Issues
gh search issues --repo "$GITHUB_REPOSITORY" --state closed --closed "${START_DATE}..${END_DATE}" --limit 200 --json number,title,url,labels,closedAt > /tmp/retro-issues.json
...
```

### Phase 3: ラベル / prefix 集計

### Phase 4: 自然文サマリ生成

④ 他にも色々

  • 必要なものの Skill 化、Skill の継続改善
  • /onboarding Skill の作成

施策が生まれるタイミング

これらの施策が生まれるのは 振り返りの時間

（ある日の振り返りの内容抜粋）

- 最近のドキュメントをmarkdownからHTMLにする風潮に追随するべきかご意見伺いたい
- モバイルのE2Eテスト環境を整えつつある（が、Expoのコアライブラリ起因でスタック中）
- そういやPOMLっていうプロンプト作成用のXML記法あったので、それ使って必要であれば修正するのも手段のひとつなのでは
- 偶然ではあるがNode.js更新の調査過程で、既存の実装のメモリ暴食やスレッドプール枯渇などの問題に気づけたのはよかった。
- もろもろ画面を触っていて 郵便番号 → 住所変換 を入れてあげたくなった
- あとでfigmaを調整（コードが先行）した時用のIssueテンプレートを用意しているので使ってください
- ローカル環境ではフロント側からバックエンドのAPIを呼び出せないため、動作確認はSTG環境のみで実施します
- 前スプリントのサマリそれとなく作ってみたが、あれがないとか、もっとこうしてほしいとかあればご意見いただきたい
- 機能を改修してマージしたけど使ってみたら期待通りに動かなかった、ということがあった。そういうことをなくしていけたらいい。
- Claudeにコード書かせたら必ずセルフレビューさせるSubAgent欲しいかもしれない
- stgでの確認環境について（実装ずれていて壊れているところがどこか）
- 別プロジェクトでFigmaデータ自体をClaude Codeに編集させる実験をしたが、Figma側の環境を整えておかないと難しかった
- あまり関係のない人がレビュワーとして自動アサインされることがあるため、自動アサインの有無を選択できるような形にするのはいかがでしょうか。

施策が評価されるタイミング

これらの施策が評価されるのも 振り返りの時間

→ 導入してから、適宜メンバーにヒアリングするのも大事なプロセス
→ これまでのプロジェクト運営と変わらない問題意識がそこにある

e.g. 自動レビュアーアサイン

  1. 効率化のために導入してみた
  2. 誤アサインが多いとの所感が集まり、改善に乗り出した

自動レビュアーアサイン成功率を出してみた

  • bot がアサインしたレビュアーが最終的に外され別人に付け替えられた=失敗
  • 付け替えられず維持=成功（下書き切替で一時的に外れ再追加されたケースは成功扱いに補正）
期間 PR総数 自動アサインあり（母数） 成功 失敗 成功率
5/18〜5/31 198 43 21 22 48.8%
6/1〜6/23 195 139 102 37 73.4%

→ 振り返りからの改善が機能している（のかもしれない）

今後

今後

  • 「もしかしたらこうしたほうがいいかも」を積極的に導入してみる
    • AI を活用するとは、実装を高速化するだけではなくワークフローをより効率的にすることでもある
    • ただ効果測定はあんまりできてないです、ごめんなさい……
  • プランニングでの実績の可視化も、今は定性的にしか見られていない
    • これを定量化する

github.com/Kurogoma4D

おまけ: project-kickstarter

project-kickstarter というテンプレートリポジトリを作っています

  • 先のプロジェクトで自分が管理するリポジトリのエッセンスを取り入れた、プロジェクトのスターターとして使える Skill 集
  • 個人で何かを立ち上げるときに便利

github.com/Kurogoma4D/project-kickstarter

おまけ②: 採用

Sun Asterisk をよろしくお願いします！

右の QR から募集要項をご覧いただけます。

採用ページ