技術を土台にして自分なりのQAエンジニアを目指す本連載では、「テスト設計」に続き、今回は「テストマネジメント」を取り上げます。
「テストマネジメント」と聞くと、進捗管理やリソース調整といった、いわゆる「管理業務」を思い浮かべる方が多いかもしれません。
しかし、私自身はQAエンジニアとしての専門性を高める上で、テストマネジメントは根幹をなす重要な技術の一つだと捉えています。
この記事では、私の経験から得たテストマネジメントに関する考えを言語化し、皆さんにとってのヒントとなれば幸いです。
記事一覧：技術を土台にして自分なりのQAエンジニアを組み立てる -あるQAの場合
「テストマネジメント」は単なる管理業務ではない
「テストマネジメント」という言葉もまた、組織や人によって様々な解釈が存在します。
例えば、JSTQBでは、
テスト活動の計画、スケジューリング、見積り、モニタリング、レポーティング、コントロール、完了のプロセス。
ISTQB Glossary Version2,2025年9月1日参照
とあります。
この記事では、もう少し身近な言葉を使って、以下のように定義します。
テストを通じて、プロジェクトのQCD（品質・コスト・納期）を調整し、その達成に責任を持つ活動
テストマネジメントは単に与えられたリソース（人、時間、お金）を管理するだけではありません。
テストにおける品質への貢献は、「プロダクトリスクを低減する」と言い換えることができます。
この目的を達成するためには、必要なテスト技術を適切なタイミングで活用し、意思決定を促すことが重要です。
時にはそういった意思決定の当事者になることも含まれる、専門性の高い活動だと考えています。
テストマネジメントを自分ごととして捉える
当初私は、テストマネジメントは経験豊富なマネージャーの仕事であり、キャリアの浅い自分には関係ないと考えていました。
しかし、テスト業務の中でテストマネジメントの側面に触れ、自らも学習していくうちに、この認識が先入観だったと気づきました。
『テストをマネジメントする』という考えは、テストのあらゆる活動に不可欠です。メンバー一人ひとりが主体性を持って取り組むべき課題だと、私は考えるようになりました。
「テストは本来不要な活動である」と捉える
この先入観を壊すきっかけとなったのは、ある逆説的な考え方でした。
『テストとは、本来やるべきでない活動である』という捉え方です。
もちろん、品質を保証するためにテストが必要不可欠なのは言うまでもありません。
あくまで思考実験です。
しかし、もし完璧な人々が完璧なプロダクトを作れるのであれば、テストは本来必要ないはずです。
これは「開発者完全性仮説」という概念にも通じます。
この概念は、にしさんが以下の動画で紹介しています。
しかし、現実には多くの現場がそうではありません。
ソフトウェア開発には何らかのリスクや不確実性があるため、その必要性に応じてテストを実施しているのです。
『本来不要な活動』であるテストに、私たちはなぜ貴重なリソース（時間やコスト）を投じるのか。
その問いに答えること自体が、テストにおけるマネジメント、すなわち『投資対効果を最大化するための意思決定』に他ならないのです。
テストマネジメントは「組織の合意形成」と「意思決定」の技術
例えば、『プロダクトを顧客に届け、安定的に運用して利益を得る』という目的があるとします。それを阻害するリスクがあるからこそ、テストを実施するわけです。
そう考えると、『テストとして何が必要で、どこまでやるべきか』という合理的な判断をするための根拠を、きちんと言語化する必要があると考えるようになりました。
この考えに至ったとき、テストマネジメントは現場で完結するものではなく、組織全体での『合意形成』や『意思決定』の側面もあることに気がつきました。
現場の特性に加え、時々刻々と変化する状況に応じてテスト戦略やリソースを判断し、その判断に責任を持つこと。これこそが、テストマネジメントの本質だと私は考えます。
この視点を持つと、テストマネジメントは特定の役職者だけのものではなくなります。
むしろ、現場の状況を深く理解した専門家としての判断が求められる分野であり、特に開発チームの中にQAが入り込む「インプロセスQA」においては、必須のスキルとなるのではないでしょうか。
※「インプロセスQA」に関しては以下のスライドも参照ください。
品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話（3D版）
Yasuharu Nishi／slideshare
ドキュメントではなく、育てるテスト計画
JSTQBにおいて、テストマネジメントの代表的なアクティビティとして「テスト計画」と「テストのモニタリングとコントロール」が挙げられます。
『テスト計画』は、しばしばテンプレートに沿った重厚長大なドキュメント作りだと捉えられがちです。もちろん、そのような現場があることは否定しませんが、私は異なる考えを持っています。
むしろ、最初の段階では現場のコンテキストに合わせた最小限のテスト計画を作成し、合意形成を重ねながら育てていくことも有効だと考えています。
だからこそ、テスト計画に記述する典型的な項目や、テストモニタリングでの管理項目について深く理解し、その必要性を自分なりに説明できることが大切です。そうすることで、チームメンバーやステークホルダーとも納得感を持って進められます。
モニタリングにより、テストもコントロールする
『モニタリングとコントロール』は、リソースの調達やリリース日の延期といった決断のためだと考える人は少なくありません。
プロジェクトリスクの高いバグを早い段階で発見し、すぐにテストスケジュールを調整することは、まさにテストマネジメントの技術が発揮される場面です。
しかし、モニタリングとコントロールの役割はそれだけではありません。
テストを通じて品質に関する情報をモニタリングし、テスト戦略あるいはプロジェクト全体へフィードバックすることも重要です。
プロダクトリスクの高いバグを発見した際には、バグ分析を通して『欠陥の偏在』の原則に基づき、重点的なテスト設計をやり直すといったアプローチも可能です。
プロジェクト面、プロダクト面両方から「モニタリングとコントロール」を行うことが大切です。
専門性の組み合わせ
「テストマネジメント」という専門性もまた、他の技術と組み合わせることで、さらなる価値を生み出します。
テスト実行との組み合わせ
テストマネジメントの視点を持つことで、テスト実行中に「この情報はいま誰に、どのように伝えれば、組織にとって有益だろうか？」と考えるようになります。
単に進捗を報告するだけでなく、発見した事象が今後のプロジェクトリスクや、全体的なプロダクトリスクの見立てにどう影響するかを示唆するなど、報告の質が格段に向上したと実感しました。
これは、自分自身のテスト実行がプロジェクト全体のどの位置にあるかを知る手がかりにもなります。
テスト設計との組み合わせ
限られたリソースで最大限の効果を発揮するというマネジメントの観点は、テスト設計に大きな影響を与えます。
例えば、テスト技法を選択する際も、その手法が生み出すテストケースの特性から、必要なリソースや低減できるプロダクトリスクを判断できるようになりました。
また、プロダクトリスクを把握することは、テストマネジメントにおけるモニタリングやコントロールにも有益なフィードバックとなります。
テストマネジメントの観点を持つことで、『どこまでテストすれば十分か』というカバレッジの判断基準が明確になり、費用対効果も考慮できるようになりました。
これにより、より実践的で『使える』テストケースを導き出せるようになりました。
おわりに：今日からできるテストマネジメント
この記事を通して、テストマネジメントが特別な技術ではなく、あなたのQAキャリアを支える土台となる専門技術であることをお伝えしました。
例えば、テストケースを一つ設計・実行する際にも、「このテストは誰に、どんな意味があるのか？」と、その背後にあるマネジメントの観点を意識してみてください。
その問いから、あなたのテストマネジメントがはじまり、QAエンジニアとしてのキャリアを、そしてチームやプロダクトの未来を大きく変えていくはずです。
