はじめに
こんにちは！@Katsu30 です。
Schooでは、新機能としてトレーニング機能をリリースしました。
このトレーニング機能をゼロから作る開発で、メインのエンジニアは2人でした。
少人数だからこそ、進め方・分業・AIの活用をどう設計するかが、成果と品質の両方に効いてきました。 この記事では、そうした前提のもとでスピードと品質をどう両立させたのか、具体的なやり方を共有します。
この記事で持ち帰れること：
- AI ツールに何をどこまで任せられるか
- エンジニア以外のメンバーをどう巻き込むか
- 少人数でも堅牢に動くための設計・プロセスの工夫
AIに「何を」任せたか
コーディングと設計
2人チームで最も効いたのは、AIコーディングツールの徹底活用です。Claude Code、Cursor、Gemini を場面に応じて使い分けました。
| ツール | 主な用途 |
|---|---|
| Claude Code | 設計 + 実装 |
| Cursor | コード修正 |
| Gemini | 設計の壁打ち |
任せたのはコード生成だけではありません。
- 機能開発: コンポーネントの実装、APIエンドポイントの雛形作成
- 基本設計・詳細設計: アーキテクチャの叩き台、データフローの整理
- ドキュメンテーション: 設計ドキュメント、実装計画の作成
- QA項目の作成: テスト観点の洗い出し、テストケースの生成
ポイントは「AIに丸投げ」ではなく 「AIに叩き台を作らせて、人間がレビュー・判断する」 というサイクルを回したことです。ゼロから書くのと叩き台をレビューするのでは、かかる時間とコードの品質がまったく違います。
たとえばClaude Codeでは、Planモードで実装計画を立て、その計画を実装前にレビューしてから実行させるようにしました。
初めからこのように実装をしていたのではなく、当初はエージェントモードですぐに実行するようにしていました。ですがコードの品質が上がらず、「生成されたコードが意図したものと違う！」 という状況に何度も遭遇しました。
そこで、Planモードの実装計画を、各エンジニアが確認し仕様との相違点がないかを確認してから実装することで、前述の意図しない実装の状況を大幅に改善することができ、結果的に実装のスピードが上がりました。
学び: エージェントモードで即実行 → Planモードで計画レビュー後に実行、に切り替えたことで品質・速度ともに改善
もうひとつ、このフローで良かったのは 「複数の実装を同時並行させやすい」 ことです。
個人的には、同じリポジトリを2つクローンし、片方を実装用、もう片方を計画策定用として使い分けました。こうすることで、実装が進んでいる間でも実装計画が進められ、実装計画をドキュメントに起こしていれば、ひとつの実装の間に複数の実装計画が出来上がり、次の実装にスムーズに入ることができました。
また、長期的な視点で見ると、設計ドキュメントと、それを作成・修正した際のプロンプトを保存しておくことによって、似たような機能の実装の時にAIが迷わないガイドラインを作ることができます。
Figma MCP / Figma MakeでUIの効率化
Figma MCP と Figma Make を、それぞれ異なる場面で活用しました。
Figma MCP は、設計ドキュメントの生成時と実装時 に使用しました。また、細かい修正でデザイン崩れが懸念される箇所では、MCPを通じてURLからデザインファイルを読み取ることで、手動での修正を抑えました。
一方 Figma Make は、チームで 「動くもの」をベースにコミュニケーションするため に活用しました。これにより認識のズレが減りました。
具体的には、企画が走り始めた際に、まずはチームメンバーとFigma Makeでプロトタイプを作成し、複数回にわたる社内テストまで実施しました。これを行うことで、自分たちでは気づけなかった視点での指摘や、考慮すべき点などが洗い出され、開発初期の段階からUXを意識して開発することができました。
また、デザインだけではわかりにくい 「動き」の部分を、Figma Makeで認識を合わせられた のも良かった点です。
具体的には、下記のような部分で役に立ちました。
- トレーニング機能のファーストビューのタブメニューがどのように動作するか
- トレーニング機能のレッスンに初めて入ってきたユーザーのためのモーダルをどのように表示するか
レビューサイクルの自動化
CodeRabbit (AIコードレビューツール) を導入し、PRのレビューを自動化しました。2人チームだとレビューがボトルネックになりがちですが、AIレビューで基本的な指摘を先に潰してから人間がレビュー（後述の日次レビュー会）することで、レビューの密度が上がりました。
自動化できるところは自動化し、人間がやるべきことに集中 しました。このバランスが大事でした。
| レイヤー | 担当 | 役割 |
|---|---|---|
| 1st | CodeRabbit | PRの自動レビュー、基本的な指摘 |
| 2nd | AIエージェント（Skills/Commands） | レビュー指摘への自動対応 |
| 3rd | エンジニア（日次レビュー会） | 設計レベルの議論・最終判断 |
具体的には、細かいレビューをAIエージェントに自動対応させることも行いました。Claude CodeやCursor上にSkillsやCommandsとして追加し、レビュー項目の対応方法を確認してから実行するフローを挟んでいます。
実際に使用したスキルはこちら
---
name: codeRabbit-pr-review-fix
description: Fetches a GitHub PR with gh, reads CodeRabbit AI review comments, then (Step1) shows a fix plan in thread, (Step2) applies fixes, (Step3) use codeRabbit-pr-review-reply for replies. Use when the user asks to handle CodeRabbit feedback, fix PR review comments, or "ghでPRを取得してCodeRabbitの指摘を修正して".
---
# CodeRabbit PR 指摘の確認と修正（3ステップ）
PR を取得し、CodeRabbit の指摘を確認する。**Step 1 で修正案のみ表示し、Step 2 で実際に修正する。返信は別スキル（codeRabbit-pr-review-reply）で行う。**
## 前提
- リポジトリは `gh` で操作可能（認証済み）
- ワークスペースルール（git push / rm 等の破壊的操作はユーザー確認必須）に従う
## 概要
```
Step 1: レビュー内容を取得 → 修正案を立ててスレッドに表示（修正はせずにスレッドで確認してください。勝手にStep2へは進まないでください）
Step 2: 実際に修正を実装 → Lint/テストで検証
```
---
## Step 1: レビュー内容の取得と修正案の表示（修正はしない）
**やること:** PR と CodeRabbit のコメントを取得し、指摘ごとの修正案を整理して**スレッド（チャット）に表示する。この段階ではファイルの編集は行わない。**
**PR 概要:**
```bash
gh pr view <PR番号> --repo <owner/repo>
gh pr view <PR番号> --repo <owner/repo> --comments
```
**CodeRabbit のインラインコメント一覧（REST）:**
```bash
gh api repos/<owner>/<repo>/pulls/<PR番号>/comments
```
- 返り値は JSON 配列。`user.login` が `coderabbitai` のものを対象にする
- 各要素: `id`, `path`, `line`, `body`, `html_url` 等
**修正案の出力内容（スレッドに表示）:**
- 各インラインコメントの `body` から「指摘内容」「代替案・修正案」を把握する
- 対応すべきか判断する（バグ・型不整合・ドキュメント不足・テスト不足は対応推奨）
- **修正対象ファイルと具体的な修正内容をリスト化してユーザーに表示する**
- 例: 「`path/to/file.go` L42: GraphQL 説明を追加。body に `Description: "..."` を追加」
- 例: 「`pkg/foo.ts` L10: 型を `number` から `0 | 1` に narrow する修正」
- 必要なら TODO で一覧化してから表示
**要約:** `--comments` の出力の `author: coderabbitai` ブロックに「Actionable comments posted: N」とインライン指摘の要約がある。
---
## Step 2: 実際に修正する
**やること:** Step 1 で示した修正案に従い、該当ファイルを編集し、Lint/テストで検証する。
**修正の実装:**
- 指摘ごとに該当ファイルを編集
- 例: GraphQL 説明追加、フォールバック値の変更、型の厳格化（`number` → `0 | 1`）、テストのアサーション追加、integration-tests の YAML 追加、モックのロジック修正 など
- 既存のリンタ・テストのルール（例: perfectionist/sort-modules）に合わせる
**検証（Lint とテスト）:**
- **Lint:** プロジェクトの lint スクリプトを実行（例: `pnpm run lint:arch`）
- **テスト:** ユニットテストを実行（例: `pnpm vitest run`）
- 失敗したら修正し、再実行して解消する
---
## チェックリスト
**Step 1**
- [ ] PR 番号・owner/repo を確認
- [ ] CodeRabbit のインラインコメントをすべて取得
- [ ] 指摘ごとに修正要否を判断し、修正案をリスト化してスレッドに表示（編集はまだ行わない）
**Step 2**
- [ ] 修正案に従って実装
- [ ] Lint とテストが通ることを確認
---
## 補足
- **integration-tests:** 既存のYAMLの形式をまねて、新規 Query 用の YAML を追加する（実際のパスをここで渡してますが省略）
こうすることで、エンジニアのレビュー時には 「ある程度の品質が担保されたコード」 から始められます。時間をあまり取れないレビューでも、最小限のリソースで最大限の効果を発揮できました。
エンジニア以外を巻き込む
2人しかいないので、エンジニアだけで全部やろうとすると破綻します。意識的にチーム内外のメンバーを巻き込みました。
QA はデザイナー・企画メンバーと一緒に
| 作業 | 担当 |
|---|---|
| QA項目の作成 | AI + エンジニア・企画メンバー |
| QA項目のブラッシュアップ | デザイナー・企画メンバー |
| QA実施 | チームメンバー全員 |
| UI微調整・文言修正 | チームメンバー（バイブコーディング） |
| UI/UXの最終品質担保 | デザイナー（バイブコーディング） |
QA項目の作成はAIに任せつつ、実際のQA実施はデザイナーや企画メンバーにも協力してもらいました。エンジニア以外の目で触ってもらうことで、エンジニアが見落としがちなUI/UXの問題が早期に見つかりました。
さらに、QA項目自体のブラッシュアップもお願いしました。ユーザー視点でのテスト観点は、エンジニアだけでは出てこないものがありました。
デザインの微調整やQA後の軽微な修正は、チームメンバーにバイブコーディングで対応 してもらいました。「ここの余白を4px広げたい」「この文言を変えたい」といった修正を、エンジニアが手を動かさなくても進められるようになったのは大きかったです。
特に助かったこととしては、デザイナーにバイブコーディングを依頼することによって、UI/UXの品質を最終的に担保できたことです。
エンジニア目線では気づけなかった部分を、デザイナーの目で見てもらい、デザイナーが修正する。このようなフローで実装することで、エンジニアとデザイナーの間の認識齟齬が生まれにくく、無駄なキャッチボールが減ったことも開発の速度を上げる要因の一つになりました。
詳しいQAについての観点は、別の記事で詳しく書いているので、ぜひご覧ください。
他チームへの技術支援依頼
自分たちだけでは判断が難しい技術的な問題は、素直に他チームに相談しました。少人数チームだからこそ、外部の知見を借りることを躊躇しないことが大切です。
実際の開発でも、アーキテクチャ観点やインフラ観点で迷った際には、他チームの知見のあるエンジニアと密に連携をとり、即座に解決することができました。
エンジニアがやるべきことに集中する
AIや他のメンバーに任せられることを任せた上で、エンジニアが集中したのは 全体の設計 と コードに責任を持つこと です。
「全体の設計」と「コードに責任を持つこと」
| 観点 | 全体の設計 | コードに責任を持つこと |
|---|---|---|
| 日次的なレビューとバイブコーディングのレビュー | 日次30分レビュー会で設計レベルの判断を行い、品質の方向性を決定 | バイブコーディングで生まれたコードもエンジニアがレビューし、最終品質を担保 |
| スキーマ駆動開発 | スキーマを先に定義し、フロント／バックエンドの並行開発体制を構築 | 日次レビュー会でスキーマをもとに認識を揃え、繋ぎこみをエラーなく完遂 |
| フェーズ分割と段階的QA | 3ヶ月の開発を設計1＋実装3フェーズに分割し、リリース可能な状態を保つ | 実装の全段階でQAを回し、方針がずれていないかを細かく確認 |
| アプリケーション基盤とドキュメントの活用 | アーキテクチャの設計思想に素直に乗り、ドキュメントを1箇所に集約する構成設計 | 設計ドキュメントを整備しAIとの協業品質を上げつつ、Git管理＋Obsidianで認識のずれを防止 |
日次的なレビューとバイブコーディングのレビュー
日次30分のレビュー会では、コードの細部ではなく設計レベルの判断に集中しました。細かい指摘はCodeRabbitやAIエージェントが先に潰してくれるので、エンジニア同士のレビューでは 「この設計方針で進めて良いか」「スキーマとの整合性は取れているか」 といった、人間にしかできない判断に時間を使えました。
バイブコーディングで他のメンバーが書いたコードについても、エンジニアが必ずレビューを行いました。デザイナーや企画メンバーがUIの微調整や文言修正をバイブコーディングで対応してくれることで開発速度は上がりましたが、そのコードの品質に最終的に責任を持つのはエンジニアの役割です。「任せる」と「放置する」は違います。任せた上で、コードとして問題がないかを確認するフローを維持しました。
ポイント: 「任せる」と「放置する」は違う。任せた上で、コードの品質はエンジニアが責任を持つ
スキーマ駆動開発
スキーマを先に定義し、フロントエンドとバックエンドを並行開発できる体制を作りました。
2人チームでこれが特に効くのは、1人がフロントエンド、もう1人がバックエンドを同時に進められるからです。スキーマが契約として機能するので、「APIの仕様どうなってる？」というコミュニケーションコストが大幅に減ります。
また前述の「日次で30分のレビュー会」も活用し、認識の齟齬が起こりそうな箇所に対してスキーマをもとに認識を揃えることを意識しました。この結果として、フロントエンドとバックエンドの繋ぎこみを目立ったエラーなくスムーズに行え、時間を効率的に使えました。
フェーズ分割と段階的QA
フェーズ分割と段階的QAは、品質や開発のフローを定めるために重要でした。
3ヶ月の開発を一気にやるのではなく、フェーズに分割しました。
- 段階的な機能作成 — 大きな機能を小さな単位に分けてリリース可能な状態を保つ
- 細かなスケジューリング調整 — 週単位で進捗を確認し、優先度を調整
- QAの段階的実施 — フェーズごとにQAを回すことで、手戻りを最小化
「全部できてからテスト」ではなく「少しずつ作って少しずつ確認」。当たり前のことですが、少人数チームではこの粒度が命綱になります。
今回の開発では、3~4個のフェーズを3ヶ月で回しました（設計1フェーズ、実装3フェーズ）。実装の全ての段階でQAを回し、方針がずれていないかを細かく確認しながら進められました。
アプリケーション基盤とドキュメントの活用
アーキテクチャの設計思想に素直に乗ることで、余計な複雑さを避けました。
また、ドキュメントコンテキストの活用も重視しました。AIツールにコードベースのコンテキストを渡す際、ドキュメントが整備されていると精度が上がります。設計ドキュメントを書くこと自体が、AIとの協業の質を上げるという好循環が生まれました。
ドキュメントは Git リポジトリで管理し、Obsidian で閲覧・編集できるようにしました。Workspace やClaude Codeのコンテキストとして共有することで、2人の間で認識がずれることを防ぎました。
具体的には、開発に関わるドキュメントは全てひとつのプロジェクトディレクトリ内に完結させることで、どこを見ればわかるかを開発初期の段階から作れていたことができていました。振り返ってみると、ドキュメントが散らばると少人数でも混乱するので、「ここを見ればわかる」という場所を1つ作ることが重要だったと思います。
ドキュメントの管理方法については下記記事でも言及しています！
成果と宣伝
この記事に書かれていることを実践し、Schooでは 「〜「知る」を「できる」に変える、ビジネス版スキルトレーニング〜」 をリリースしました。
１レッスン数分から気軽にできるので、スキマ時間やリフレッシュしたいタイミングなどでぜひ使用してみてください！
今後もアップデートしていくつもりなので「触って楽しかった！」などあれば、ぜひシェアしていただけると嬉しいです！
まとめ
少人数チームでスピーディかつ堅牢に開発を進めるために意識したことをまとめます。
- AIに任せられるところは任せる
- エンジニア以外を巻き込む
- エンジニアがやるべきことに集中する
少人数だからといって、すべてを自分たちで抱える必要はありません。AIに任せる、仲間に任せる、他チームに任せる。任せた分だけ、設計と意思決定に集中 できました。「任せる勇気」と「集中する覚悟」が、エンジニア2人で成果を出す鍵だったと感じています。
大きな機能開発を、エンジニア2人で完遂できたのは、ここまで書いてきた工夫の積み重ねがあったからこそです。
他のチームでも試せることがあるかもしれません。読んでくださった方に、なにか気づきや学びなどがあれば嬉しいです！
ここまで読んでいただきありがとうございました！
Schooでは一緒に働く仲間を募集しています！