こんにちは。VoicyのQAエンジニアの、のんちゃん（@voicy_nonchan）です。
わたしが現在関わっているチームでは、2026年4月〜5月の2ヶ月間、開発体制を大きく変えるチャレンジを行いました。
これまでの「職能で分担する開発」をやめて、1人1案件という体制にという体制に。さらに開発の進め方も、プロジェクト計画書を起点としたスタイルに切り替えました。
この記事では、その2ヶ月の振り返りとして、新体制で導入した仕組み・直面した課題・見えてきた学びを整理します。
こんな人に読んでほしいです
- 職能を固定する開発体制から「全員が全部できるプロダクトエンジニア」体制への移行を検討している方
- AIを活用して、少人数チームで複数案件を並行で回す方法を探している方
- QAの新しい関わり方や、「プロセス監督」のような役割の動き方に興味がある方
- プロジェクト計画書ベースの開発・Claude Skillsを使った開発支援の事例を知りたい方
この記事は、音声でもお楽しみいただけます！
- 1. 何を変えたのか
- 2. 専門外に飛び込む：エンジニアたちのキャッチアップ
- 3. レビュー文化の再設計
- 4. プロジェクト計画書を中心に置く
- 5. 「プロセス監督」とは何だったのか
- 6. アウトカム：1案件あたりのリードタイムは同等、スループットは約3倍
- 7. 難しかったこと・これからの宿題
- 8. まとめ：AI時代に、チームとQAはどう変わるか
1. 何を変えたのか
これまでは「iOSエンジニア」「Androidエンジニア」「Backendエンジニア」「QAエンジニア」のように、職能で役割を固定していました。3人で1つのプロダクトを担当し、それぞれが得意領域を分担するスタイルです。
今回のチャレンジで切り替えたのは、以下の体制です。
- AIを活用して「全員が全部できる」プロダクトエンジニアを目指す
- 1人1案件 × 3案件を同時並行で進める
- プロジェクト計画書ベースで開発する
- QAは「プロセス監督」という新しい役割で関わる
開発体制のチャレンジにかける思いは、Voicy開発統括のやまげん (@yamagenii) のこちらの記事を読んでいただくと、その思いが伝わるかと思います。
2. 専門外に飛び込む：エンジニアたちのキャッチアップ
最大の変化は、「自分の専門領域以外も全部やる」になったことです。
- iOSをメインのエンジニアがBackendも実装する
- Webメインのエンジニアがアプリ開発を担当する
入り口は書籍や動画で領域知識を浅く広く拾い、実務ではAIをフル活用して実装をします。調査・実装方針の相談・コードレビューもAIと壁打ちしながら進め、AIが書いたコードに質問攻めをして理解を深める。これが新しいキャッチアップの形になりました。
3. レビュー文化の再設計
3案件並行になると、チーム全体のPR量が約3倍に増えます。レビュアーの負荷が一気に増えるため、出す側で以下の運用を入れました。
- PRの粒度を小さくする
- 複雑な実装は事前に方針を握っておく（手戻りを防ぐ）
- 「なぜそうしたか」をコメントで補足する
AIが書いたコードを出すからこそ、文脈を残しておかないとレビュアーが追えなくなる、というのが実感です。
4. プロジェクト計画書を中心に置く
開発着手前にAIや専門メンバーへのヒアリングを経て、開発者自身がプロジェクト計画書を策定する運用を行いました。
プロジェクト計画書とは、プロジェクトの概要・スコープ・スケジュール・技術設計・品質方針・リスク・運用までを1つにまとめたドキュメントです。「開発の話はここを見ればわかる」情報のハブとして位置づけています。
なぜ1人1案件に計画書が必要だったのか
1人1案件は「1人で済む」体制ではなく、「1人で全領域を見る」体制です。 関係者は思った以上に多く、計画書がないと毎回口頭で文脈を補う必要が出てきます。
- 担当者本人：複数領域の仕様・設計・リスクを頭の中だけでは管理しきれない
- 各領域のレビュアー：1案件あたり複数のリードがレビューに入る。毎回口頭で文脈を伝えるとコストが大きい
- QA（プロセス監督）：3案件並行の進捗・仕様変更を1人で追う必要がある
- PdM・他チーム：仕様変更や依存関係の調整時、状況を共有する必要がある
- AI（Skill）：差分検知・整合性チェックを任せるための「正の情報源」が必要
計画書をハブにすることで、関係者全員が同じドキュメントを見れば最新がわかる状態を作れました。 コードレビューやエスカレーションのたびに口頭で文脈を補う負担が減り、1人で複数案件を回しても情報を渡すコストでスピードが落ちにくくなります。
Skill化して運用を統一
計画書は最初にClaudeで叩きを作り、必要な内容を整理した上でClaude Skills化して雛形を生成できるようにしました。漏れがちな項目もチェックリストとして組み込んでいます。
AI生成のドキュメントは「読んでもらえる形」にする
運用してみると、AIに丸投げして生成した文章はそのままだと読まれにくいことがわかりました。チーム内でプロジェクト計画書のレビューをする際、形式は整っていても頭に入ってこないのです。
対策は、読んでほしい部分は自分で骨子を箇条書きで整理し、それをAIに構成させること。15分で読み切れる分量を目安にする、といった運用ルールも生まれました。
5. 「プロセス監督」とは何だったのか
この部分は、以前登壇した資料も併せてご覧ください。
新体制で、QAは「プロセス監督」という役割で関わることになりました。定義は、進行のチェック・品質の担保・障壁除去とエスカレーションの3つです。
やってみてわかったこと：QAの本質と同じだった
2〜3週間やってみて気づいたのは、これはいつもQAでやっていることだ、ということでした。
QAは、テストを書くだけの仕事ではなく、リリースまでの流れに問題がないかを確認し、本当にこの仕様で目的にヒットするかを問い、そもそも何のために作るのかを問い直す動きを含みます。役割名が「プロセス監督」になっても、QAの本質的な動きは変わりませんでした。
具体的な動きは以下の4つに整理できます。
- 仕様の空白を埋める（TBD・要確認・未定義に気づき、決定を促す）
- ボトルネックを見つける（進捗の詰まり・依存関係のリスクを早期検出）
- 情報を届ける（関係者に意思決定の根拠を共有）
- 認識を合わせる（暗黙の前提を言語化し、わからないことは突っ込んで質問する）
大変だったのは「情報の追跡」
立ち回りは変わらない一方、しんどかったのは情報量でした。これまで最大2案件までの経験しかありませんでしたが、合計4案件を進めることに。同時スタートで仕様変更も日々起きます。
そこで2つの仕組みを導入しました。
① 差分の追跡（プロセス監督Skill）：プロセス監督用のSkillを別途作り、「最新の計画書を取得して、前回見たときからの差分を色付きでまとめる」よう指示。UIや方針の変更、計画書内の矛盾点もAIが指摘してくれて、レビューの自動化として機能しました。
② アラート制度：「水曜の朝に◯◯まで終わっていなかったら、PdMにエスカレーション」という基準を決め、機械的にチェックする運用にしました。肌感に頼らず、仕組みで気づける化したものです。
計画書 ＋ 2つのSkill
- プロジェクト計画書 ← 開発の話のハブ
- 計画書作成Skill ← チームで運用を統一
- プロセス監督Skill ← 差分を取得・進捗をダブルチェック
QA自身がメインで動きつつ、Skillで自動的にダブルチェックされる体制を作りました。
6. アウトカム：1案件あたりのリードタイムは同等、スループットは約3倍
「企画開始から機能公開までのリードタイム」を、旧体制1件と新体制3件で比較しました。
結果
| 案件 | 体制 | リードタイム |
|---|---|---|
| 機能A | 旧体制（3人で1案件） | 32日 |
| 機能B | 新体制（1人1案件） | 41日 |
| 機能C | 新体制（1人1案件） | 22日 |
| 機能D | 新体制（1人1案件） | 33日 |
新体制3案件の平均は 32日。旧体制と同等の水準に収まりました。
スループットの観点
新体制では3案件を同時並行で進めました。
| 指標 | 旧体制 | 新体制 |
|---|---|---|
| 1案件あたりのリードタイム | 32日 | 32日 |
| 同時並行で進む案件数 | 1 | 3 |
| 32日あたりのリリース案件数 | 1案件 | 3案件 |
1案件あたりのリードタイムを保ったまま、チーム全体のスループットは約3倍になりました。各技術領域（iOS/Android/Backend）に精通したシニアエンジニアによるコードレビューが品質面を支え、大きな不具合は発生していません。
体感としての変化
数値面とは別に、チームの体感として以下のような変化がありました。
- チームで1案件をやっていた頃と、1人で1案件を完結させる速度がほぼ同じだった。結果として、個人ベースのアウトプットがそのまま3倍に。
- 1週間で出せるアウトプットできる量が増えた実感。1人だから時間がかかる、という予想は外れた。
- 大きな不具合は発生しなかった。テストケースを丁寧に作り、各領域のリードがコードレビューを担保してくれたことが効いた。
なぜ早くなったのか
わたしが横から見ていて印象的だったのは、「ためらわずに人に聞きに行く」文化が一気に強まったことです。
以前は「自分の専門領域だから、できるところまで自分で考えてから」という空気がありました。今回は専門外なので、最初から堂々と聞きに行ける。間に合わせるためには聞くしかない、という状況も後押ししました。
聞きに行くハードルが下がったことが、結果としてアウトプットを早めました。慣れていけば、伸び代はまだ大きいと感じています。
7. 難しかったこと・これからの宿題
スムーズに完璧にやり切った、わけではありません。今も悩み続けている論点があります。
①「チームとして動く」の再定義
3人で1案件をやっていた頃は、レトロスペクティブも全員が自分ごとでした。誰かが苦戦したところに、自分ごととして踏み込んでいく。
今は3人がそれぞれ違うプロジェクトを進めているため、他メンバーの苦戦に「大変そうですね」で終わってしまう可能性があります。チームでやる意味が薄れるとまでは言わないものの、「チームとして動く」の意味は再定義が必要だと感じています。
② コンテキストスイッチコスト
複数案件を頭の中で同時に持つことの負荷は、Skillで補える部分があるとはいえ、人間側に残ります。
エージェントが自律的に矛盾点や進捗の遅れを指摘してくれる体制にできれば、チームとしての視野を保ちながら個人の負荷を下げられるはずです。
"AIに指示通り実装をしてもらう"だけでなく、"AIが考慮不足に気づいて自律的に動く”方向にどう寄せるかが、次のテーマです。
③ スケールするか
今回うまくいった大きな要因の一つは、各領域のリードがコードレビューをしっかり見てくれたことでした。一番詳しい人がレビューしてくれるから、安心して未知の領域に飛び込めた、という構造です。
これを「全員が1人1案件」の体制にスケールさせようとすると、レビュー体制をどう仕組むかが大きな宿題になります。
しかし、体感としてもアウトプットの量としても、現体制のアウトカムを出せます。
世の中の流れとしても、すでにこの方向の体制を採用している会社は増えてきています。これからの開発の在り方は、1人1案件に近い形に寄っていくのではないかと感じています。
8. まとめ：AI時代に、チームとQAはどう変わるか
2ヶ月のチャレンジで見えてきたことを、まとめます。
- 役割を職能で固定しなくても、AIを前提にすればチーム開発は回る。
- 計画書を中心に置けば、レビュアー・QA・PdM・AIが同じ情報源を見られるようになり、1人1案件でも文脈共有のコストが下がる
- QAの本質的な動きは、体制が変わっても変わらない。
- AIを味方につけると、QA（プロセス監督）の関わり方の幅が広がる。
- 「チームとして動く」の再定義は、これからの宿題。
「プロセス監督」という新しい名前をつけられて、最初は構えました。実態を見ればいつもQAがやっていたことで、それをAIと一緒に、もっと広い範囲で、もっと素早く回すための新しい武器（Skill）が生まれた、という体験でした。
同じように「AI時代の開発体制」や「新しいチームの在り方」を模索している方の参考になれば嬉しいです。
私たちと一緒に、音声の未来を創りませんか？
いかがでしたか？Voicyの開発組織に少しでも興味を持ってくれたなら、ぜひ一度カジュアルにお話ししましょう！
最後まで読んでいただき、ありがとうございました。
