QAと開発の融合について、私が現場で感じたこと
目次
1. はじめに — QAと開発の二刀流になって見えた景色
この記事を書いている私は、QA歴13年・開発歴2年という経歴です。
どちらもSESとしての出向経験が多く、QAではリーダーや拠点責任者を務めました。
QA業務は一通り経験し、開発では社内プロジェクトでPMまで任されたこともあります（もちろん案件によって当たり外れはありました）。
そんな私ですが、「QAと開発の両方が分かっているからこそ、できること」 がある一方で、現場では知っていても権限がなくて動かせない場面も多く経験しました。
今回は、その両面を含めて私が感じた 「QAと開発の融合」 について、実体験をもとに赤裸々に書いていきます。
2. QAと開発、それぞれの立場の「本音」
私は品質分野の国際資格である JSTQB を上級まで取得しています。
各シラバス（FL／TA／TM）を読み込み、自分なりに重要だと感じたポイントは大きく2つです。
1つ目は 「しかるべき工程を守ること」、2つ目は 「開発物をどれだけ深く理解しているか」 です。
しかし現場では、知識や理解があっても必ずしも力を発揮できるとは限りません。
案件参画後、「問題も解決策も分かっているのに、手を打てない」ことが何度もありました。原因は多くの場合、権限や組織構造といった技術以外の壁です。知識よりも、この壁の方が強く感じられる場面は少なくありません。
一方、開発側に移ってからは、別種の壁にぶつかりました。
案件で通用するために覚えるべき運用ルール、コーディング規約、図や設計書の記述方法――覚えることは膨大で、技術習得にも多くの時間を要します。
私のSES経験の中での印象ですが、
- QA は「人間性」や「チーム適応力」が重視されやすい
- 開発 は「技術適応力」と「実績」が重視されやすい
というように、求められる力の軸が大きく異なると感じています。
3. QAと開発の融合で見える強み
QAと開発の両方を経験したことで、次のような強みが明確になりました。
- 品質やプロジェクトリスクに早く気づき、迅速に対応できる
QAとして多くの案件に関わった経験から、問題の兆しを察知する精度が高まりました。さらに開発経験があることで、自ら実装や設定を変更し、即座に対処できるようになりました。 - 資料構造を最適化し、将来の運用まで考慮できる
QA視点での「分かりやすさ」と、開発視点での「実用性・保守性」を両立できるため、長期的に使えるドキュメントが作れます。 - 適切なタイミングで状況を分析し、プロジェクトをコントロールしやすい
QA時代に培った計画的な分析力をベースに、開発経験で得た現場の制約や優先度感覚を組み合わせ、判断スピードを上げられます。 - 問題発見から処置までのスピードが早い
単に問題を見つけるだけでなく、その場で原因と対策を提示できるため、停滞を最小限にできます。 - 設計書の不備や不足情報を素早く特定できる
QAとしてのレビュー経験と、開発者としての実装知識の両方があるため、必要な情報を即座に洗い出せます。 - 納品物の品質が期待値を上回りやすく、信頼を築きやすい
QA的な品質基準を自然に組み込むため、追加指示がなくても一定以上の品質を確保できます。
これらは単なるスキルの寄せ集めではなく、QA的な視点と開発者としての実装経験が相互に作用した結果だと感じています。
4. QAと開発が融合できなかった壁
QAと開発の両方を経験しても、現場では強みを発揮できない場面が多くありました。
権限のなさ
品質面で改善提案をしても、「あなたは開発を知らないから」と一蹴されることがあり、酷い時は衝突の末に当時の役割を消されることもありました。
権力構造の固定化
資料に記載のないコードが存在していても、コードが「正」とされ、運用上のリスクも公式に肯定されてしまう現場があります。権力を持つ開発者がそう判断すれば、誰も逆らえず、後のトラブルは放置される――そんな現実を何度も見てきました。その結果、属人化が進み、人材不足というリスクが実際に具現化することもありました。
スピード感のズレ
QAの視点と開発現場の動きにはズレがあります。問題を発見できないこともあれば、発見しても「ではどうするか」が見出せず、手が止まってしまうことも少なくありません。
SES特有の「よそ者感」
プロジェクトの主導権はお客様にあり、多くの場合は指示に従うだけです。そのため、自分の意見や視点を積極的に活かす機会は限られます。
スキル不足による制約
開発初期は技術的なスキル不足も壁でした。開発者と同じ土俵で議論できず、初心者扱いされ、ドキュメントを渡されて「これを読んでおいて」とだけ言われる――そんな扱いが続いた時期もありました。
5. 融合を実現できた瞬間とその条件
融合が進む条件
- 裁量があること
プロジェクト初期から資料構造の設計や方針決定に関われる環境があると、融合は一気に進みます。 - 決定権を持つ人が品質知識を持っていること
体系的な資料品質の知識を持つリーダーがいると、方向性がぶれず適切なリードが可能です。 - 初期段階で全員が資料構造を理解していること
属人化を防ぎ、全員が同じ基準で作業できるため、連携がスムーズになります。
この条件が揃った社内プロジェクトでは、誰か一人だけが状況を知ることはなくなり、各メンバーの失敗にも柔軟に対応できました。結果として、連携力や信頼関係が飛躍的に向上しました。
実際にうまくいった事例
プロジェクト初期で資料構造の説明や資料作成方針を明確にしただけでは、属人化は解消できませんでした。
実際には、複数人で資料を作成し、レビューし合う体制を整えることが重要でした。
この体制により、プロジェクトや開発物の理解が進み、複数の目で確認することで自然と資料品質も向上。この文化が根付いた結果、納期トラブルが発生しても、お互いの状況を共有し、フロントエンド・バックエンドの垣根を越えて協力できました。
突破口となったこと
上記の条件と運用により、PMとしてのタスク管理が緩和され、メンバー間の連携もしやすくなりました。
各自がそれぞれの壁に挑戦できる環境が整い、時間の経過とともにチームの安定性は増しました。信頼が深まった結果、一人のミスはミスと呼べないほど小さくなり、プロジェクト全体の状況コントロールやタスクコントロールのハードルも下がっていきました。
安定し、柔軟に対応できるチームは、まさに融合の突破口だったと言えます。
6. まとめ（総括＋学び）
QAと開発を融合させればプロジェクトが良くなる――そんな単純な話ではありません。
実際の現場では、裁量の有無によって物事の正しさの見え方が変わります。プロジェクトの意思決定を統一し、QAの体系的な知識を持つ者に裁量がなければ、QAの力を開発と融合させることはできません。
一個人の裁量が小さければ、QAとしてできることも限られ、力を発揮する場面は少なくなります。逆に、裁量を持ってQAを実践できれば、チームは柔軟になり、安定性が向上します。
チームには歴史があり、内部情報を透明化し、改善を繰り返すことで、チーム力は着実に上昇していきます。QAは単に開発物の品質向上に貢献するだけでなく、チーム力そのものの向上にも寄与していたのです。
最初に触れた「しかるべき工程を守る」には体系的な知識が必要であり、「開発物をどれだけ深く理解しているか」には多くの技術的知識が必要です。
QAと開発が融合すれば大きな成果が得られますが、その間には裁量や権力といった“人の奥底”の壁があり、知識と技術を兼ねそろえているという壁もあり、そのひたすらに難しい条件を乗り越えた先に本当の融合があります。
7. 読者へのメッセージ
ここまで読んでくださった方なら、もうお気づきでしょう。
QAと開発の融合は、壁が二重にも三重にも重なるほど難しいものです。
それでも、どんなに厳しい現場にも「その場の条件と領域（裁量）に適したQAの役割」は存在します。
そして、その裁量の範囲で融合を実行するだけでも、確実に付加価値は生まれます。
融合できる裁量が広がるほど、力は増幅し、向上し、洗練されていきます。
全部を一度に変えようとすれば、必ず反発や圧力に押しつぶされます。
だからこそ大切なのは、自分が今置かれている状況で、自分だけが持てる裁量の中から融合を始めることです。
小さく始め、少しずつ影響力を広げる。
その過程で周囲の信頼が積み上がり、チームが形成され、結果は大きくなっていきます。
道は険しいですが、得られるものは計り知れません。
その先には、自分が最も力を発揮できる瞬間が必ず眠っています。
私はそれを信じ、これからも走り続けます。
