はじめに
株式会社WiseVineの奥田です。
私は2024年6月にQAエンジニアとしてWiseVineに入社しましたが、現在はQA・PdM・PjMの3つのロールを兼務しています。
この記事では以下のことについて書いています：
- QAとPdM/PjMを兼務することで得られた効果：情報伝達コスト削減、品質と生産性の両立
- AI時代のフルサイクル開発について：少数精鋭化と変化への適応
- 私が考える兼務を始めるためのポイント：親和性のある領域から始めることと主体的な課題解決
兼務に至った経緯
QAエンジニアとしてのスタート
WiseVineは自治体向けSaaSを開発するスタートアップで、スクラムチームでの開発を行っています。開発組織には以下のようなロールがあり、私は当初QAとしての業務に専念していました。
- PjM
- PdM
- FE
- BE
- QA ← 私のポジション
- デザイナー（横断的）
- SRE（横断的）
シフトレフトの取り組みから始まった変化
私がチームにジョインした時は、立ち上げ期で新しいメンバーが多い状況でした。以下のような問題が度々起きていました：
- 仕様の解釈が人によって異なる
- テスト設計時に仕様の不明点が発覚
- 実装後にバグや手戻りが頻発
入社後、シフトレフトとして仕様検討や設計のMTGに参加していましたが、こういった問題を改善するために、より早くテスト仕様書を作成し、仕様の曖昧な部分を明確化する活動を行いました。
工夫したのは、テスト仕様書を活用したコミュニケーションです。
テスト仕様書という具体的で仕様の全量を議論できるものがある状態で、チームでの議論や相談を行うようにしました。これにより、曖昧な部分を具体的に特定し、仕様について効率的に認識合わせができるようになりました。
自然とPdM業務へ
この活動が発展し、解決策の提案や関係者間の調整まで行うようになりました。スタートアップ特有のリソース不足もあり、「QAの仕事はここまで」と線を引かず、「誰もやれないなら自分が」という姿勢で課題解決に取り組みました。
こうした活動を続ける中で、以下のように徐々にPdM業務も行うようになりました：
- 2024年12月：サブPdM開始
- 2025年5月：正式PdM就任
- 2025年9月：複数プロダクトのPdM/PjM兼務
兼務で実感した2つのメリット
1. 兼務による工数とコミュニケーションコストの削減
私の場合の変化
PdM兼務前：
- PdMが仕様作成 → 2. QAが仕様把握 → 3. QAがテスト設計 → 4. QAがテスト実施
PdM兼務後：
- 私が仕様作成 → 4. 私がテスト実施
兼務することで多少の負荷増はありますが、従来の「仕様の把握」「テスト設計」の時間がなくなるため、工数が単純に増えるわけではありません。むしろチーム全体で見ると、2人分の作業を1人で効率的に行えるようになりました。
一般原理：情報伝達コストと認識齟齬リスクの削減
私の例で「仕様の読み込み」が不要になったように、職種間での成果物の読み解きには多くのコストがかかります。さらに、解釈の違いによる認識齟齬のリスクも生まれます：
- PdMが作った仕様をFE、BE、QAが読み解く
- BEが作ったAPIをFEが読み解く
- デザイナーが作ったデザインをFEが解釈する
一人で複数の工程を担当することで、これらのコストと認識齟齬のリスクを削減できます。
2. 全体最適による品質と生産性の両立
ロールによって重視する観点が異なる場合があります（両方を考慮できている人も当然いますが）：
- QA：品質を重視する傾向
- PdM/PjM：スピードを重視する傾向
兼務することで、品質とスピードの両方に責任を持つ立場になり、全体最適の視点で判断できるようになります。（というかそうせざるを得ません）。
まずは生産性向上から取り組む
全体最適を目指す中で、私はまず生産性の向上を重視して取り組んでいます。具体的には以下のような施策を実施しました：
- 仕様をシンプルにする：仕様の複雑さを排除することで、開発効率とテスト効率を同時に向上
- 作る量を減らす：価値が曖昧なnice to have機能を削り、本当に必要な機能に集中
- 優先順位を考える：技術的難易度やUX検証が必要な機能を先行し、不確実性を早期解消
なぜ生産性を重視するのか
生産性が向上することで時間の余裕が生まれ、結果として品質向上にも繋がると考えているからです。実際に、チームに余裕が生まれることで、ミスが減ったり、より充実したテストが実施できるようになりました。
PdMの裁量で実現できる改善
これらの改善は、仕様や優先順位を決めるPdMだからこそ実現できました。仕様を確認する側から作る側になったことで、品質とスピードを両立した判断を最初から反映できるようになりました。
AI時代のフルサイクル開発
エンジニアのフルサイクル化と少数精鋭化
従来のプロダクト開発では、各工程を専門の担当者が分業で行うのが一般的でした。
そんな中、AIによる2つの変化が起きています：
- 生成AIにより個人の生産性が向上
- 複数ロールを兼務できる人が増える（経験したことがないロールでも、AIを活用することで比較的すぐにジュニアやミドルレベルに到達可能）
これにより、一人のエンジニアが複数の工程を担当するフルサイクル開発が現実的になりました。
よくあるプロダクト開発
| 要件定義 | 設計 | 実装 | テスト | |
|---|---|---|---|---|
| PdM | ✅ | |||
| FE | ✅ | ✅ | ||
| BE | ✅ | ✅ | ||
| QA | ✅ |
フルサイクル開発
| 要件定義 | 設計 | 実装 | テスト | |
|---|---|---|---|---|
| フルサイクルエンジニア | ✅ | ✅ | ✅ | ✅ |
結果として：
- 一人ひとりがフルサイクルで価値を提供する時代へ
- エンジニア組織が少数精鋭になる
QAエンジニアから見たフルサイクル化
フルサイクル化の流れの中で、QAエンジニアが担当できる領域が大きく広がっています：
PdM業務への参入
私の場合は仕様明確化から始まり、最終的にPdM兼務に至りました。QAとしての品質視点を活かしながら、要件定義や優先順位決定にも関われるようになります。
コード開発への参入
生成AIツール（Claude Code、Cursorなど）により、「コード読めない、書けない」という障壁が大幅に下がりました。特にQAエンジニアにとって重要な理由：
- テスト戦略の変化：E2Eテスト自動化ではなく、下位レイヤーのテストを充実させる
- 生産性の観点：FEやBEの人に修正を依頼するより、自分で修正した方が効率的
- 品質の観点：実装を理解していることで、より効果的なテストが可能
私が考える兼務を始めるためのポイント
1. 現在の業務の延長線上から始める
いきなり遠い領域に挑戦するのではなく、今の業務と関連の深い部分から始めることが重要です。
QAからの具体的なステップ例：
- PdM兼務への道筋：テスト仕様書作成 → 仕様の曖昧点指摘 → 仕様改善提案 → 要件定義参加
- 開発兼務への道筋：テスト自動化 → Unitテスト作成 → 簡単なバグ修正 → 機能実装
他職種への応用：
- FE → デザイナー（UIの実装経験を活かして）
- BE → FE（APIの仕様理解を活かして）
- デザイナー → PdM（ユーザー体験の理解を活かして）
2. チームの課題を見つけて主体的に解決する
チームの課題に対してオーナーシップを持って解決することが重要です。課題解決が兼務に繋がる理由：
- 自然な業務拡張：課題解決の過程で、元の職種の枠を超えた業務に自然と関わることになる
- 組織からの承認：「この人なら任せられる」という信頼があることで、正式な兼務が認められやすい
- 実践的なスキル習得：座学ではなく、実際の課題を通じて必要なスキルが身につく
私の場合も、「仕様の曖昧さ」という課題を解決する過程で、自然とPdM業務に関わるようになりました。
「誰かがやるだろう」ではなく、自分から積極的に取り組む姿勢が大切です。
まとめ
QAとPdM/PjM兼務を通じて、工数削減と品質・生産性の両立を実現できました。AI時代でエンジニアのフルサイクル化が進む中、兼務は有効なアプローチの一つだと思います。
私が考える兼務を始める際のポイントは2つです：
- 現在の業務の延長線上から始める
- チームの課題を見つけて主体的に解決する
特にQAエンジニアの方は、仕様明確化からPdM業務に、Unitテストから開発業務に挑戦するのがいいと思います。