この記事は株式会社カオナビ Advent Calendar 2025の15日目の記事です。
カオナビでQAをやっています市野と申します。
みなさんが所属している組織には、ミッションや方針があると思います。
ただ、抽象的なミッションを見て「で、具体的に何をすればいいの？」と思ったことはありませんか？
この記事は、私が所属している部でのミッションについて段階モデルを利用し、どのような施策を行なってきたかを紹介します。
何をやってきたか
私が所属する部では、まず部のミッションからQAとしてのミッション・方針を決めました。
ここで決めたミッションや方針は抽象度が高いものになります。
例えば以下のような内容です。
- アウトカムに重きを置いた品質
- チーム全体の品質への責任感と能力の向上
まず、各メンバーが方針への理解を深めるために、ワークショップを行いました。
我々は普段の業務をどうするのか？という視点で、各方針に対してどんな行動ができているべきかを洗い出していきます。
通常であれば、洗い出した段階で行動を各メンバーが実践していく流れになるかと思います。
今回はその行動をより実践しやすい形にするために、段階モデルを利用しました。
段階モデルとは
それぞれの方針について、STEP1〜5を設け「できている状態」を段階的に定義しました。
CMMIなどの枠組みからアイデアを得て、段階で表現しました。
例でいうと、「2. チーム全体の品質への責任感と能力の向上」であれば以下となります。（ここでは最初の2ステップのみ紹介します）
- STEP1：チーム全員が「価値」や「品質」といった共通の概念で建設的にコミュニケーションを取ることができる
- STEP2：テストの透明性（どういうテストをしているか可視化し、関係者が納得できる状態）
そして、作成した段階モデルに基づいて、今自分たちがいるチームの現在地を把握します。
把握した上で、チームの状況に合わせ、次に目指すべきSTEPを自分たちで決めて進めていきました。
何がよかったか、何が課題だったか
よかったことはミッションに対して、自分のチームの状況が見える化できたことです。
具体的な行動例を各STEPに用意することで、今チームでは何ができていて、何ができていないのかがすぐに見える状態になりました。
カオナビの開発は、チームごとに開発の進め方が異なるので、全員が同じタイミングで同じ課題に対して進めていくのではなく、状況に合わせて取捨選択しながら進められるのは、私としては取り組みやすかったです。
一方で、自分たちで決めて進められるので、自分のチームでやりやすいものを選ぶ傾向が多く、優先度の観点が足りてなかったなと振り返って思いました。
なので、自分たちで決めて進めていく場合でも、「どういう順番で取り組むか」という道筋をある程度計画してから進めると、より効果的だったなと感じています。
実際にどんな施策をやったか
私のチームでは、「2. 全体の品質への責任感と能力の向上」という方針に対し、以下の取り組みを行いました。
- STEP1：チーム全員が「価値」や「品質」といった共通の概念で建設的にコミュニケーションを取ることができる
→ 品質ピラミッドのワークショップの実施 - STEP2：テストの透明性（どういうテストをしているか可視化し、関係者が納得できる状態）
→ テスト基本分析とテストレベルの明確化
品質ピラミッドのワークショップ
すでに別チームで実際に試していた実績があったので、以前やっていた内容を少しブラッシュアップし私のチームでも実践してみました。
品質ピラミッドのワークショップですが、『ソフトウェアテストをカイゼンする50のアイデア』[1]の「関係者と品質に関する全体像を定義しよう」(p.15)を参考に実施しています。
ワークショップのゴールとしては以下を定義しました。
- 自分たちのプロダクトの品質について、チームメンバーがそれぞれどう捉えているかを可視化し、共有すること
- どの品質を「大事にしたい」と思っているか、お互いの価値観を理解すること
進め方は、以下の図のようにピラミッドに対して、各メンバーに「良い点（黄色付箋）」「もっと良くしたい点（ピンク付箋）」を貼ってもらいました。
実施してみてよかったポイントは、チームメンバーが品質についてどう捉えているかを把握できたことです。
上記の図を見ると、USEFULの部分（役に立つか）についてもっと良くしたい付箋が多く、みんな同じような課題感をもっていました。まだまだ機能を拡充していく必要があるよね、といったことを認識合わせすることができました。
また、定期的に実施することでプロダクトの成長と課題感の目線合わせができそうといった意見もでました。
この場限りではなく、継続的に実施することで効果を出せそうだという手応えを感じました。
テスト基本分析とテストレベルの明確化
次に、テストの透明性を高めるために、テスト基本分析とテストレベルを明確化したテスト戦略文書の策定を行いました。
基本的なことができていなかったなと反省した部分でもあります。
まずテスト基本分析ですが、『ソフトウェアテスト徹底指南書』[2]を参考にしています。
以下引用です。
テスト基本分析は、テストの顕在的・潜在的な要求・制約を収集・分析・整理して、自分たちにどのようなテストが求められているかを具体化する活動です。
――『ソフトウェアテスト徹底指南書』p.119
私のチームでは以下を具体化しました。
- ステークホルダーの特定
- テストベース
- テストに対する要求や制約
- テスト対象の全体像の分析と理解
- 重大な課題やリスクとそれに対するアプローチ
- 必要なテスト環境
- テストの責務と目的
テストレベルの明確化については上記の「テストの責務と目的」で定義しました。
各テストレベルで、担当、テスト対象の粒度、発見したいバグ・問題、テストスコープを明確にしました。
テストの透明性を上げたいという目的で進めていましたが、そもそも自分たちが何のためにテストをしているのか？という根本的な部分を見直すことができました。
そして、透明性と言っている以上、QAで作って終わりではなく、チーム全体で共有し他メンバーの意見も取り入れ、みんなが納得感がある状態を目指して進めていきました。
その他の効果としては、
テスト設計においてテストスコープを決める際に指標を踏まえた上でステークホルダーと調整しやすくなったという声がありました。（システムテストとしてはxxのみで問題ないというすり合わせがしやすくなった）
また、テストレベルを明確にしたことで一部重複しているテストも見つかり、「どう最適化していこうか」という新たな課題も見えてきました。
まとめ
今回、QAのミッション・方針を段階モデルに落とし込み、具体的な施策を実践してきました。
この取り組みを通じて感じたのは、「できていない」を可視化することで、次に何をすべきかが明確になるということです。
抽象的なミッションのままだと「で、何をすればいいの？」となりがちですが、段階モデルで各STEPの「できている状態」を定義することで、自分のチームの現在地が見え、状況に合わせた施策を選べるようになりました。
もしミッションや方針があるけれど、具体的な行動に落とし込めていない方がいれば、ぜひ段階モデルを試してみてはいかがでしょうか。全員が同じことをやる必要はありません。自分のチームの状況を見て、今必要なことから始めてみると、取り組みへの一歩を踏み出しやすくなると思います。
参考文献
[1] Gojko Adzic, David Evans, Tom Roden 著、山口鉄平 訳『ソフトウェアテストをカイゼンする50のアイデア』翔泳社、2022年
https://www.shoeisha.co.jp/book/detail/9784798176062
[2] 井芹洋輝 著『ソフトウェアテスト徹底指南書 〜開発の高品質と高スピードを両立させる実践アプローチ』技術評論社、2025年
https://gihyo.jp/book/2025/978-4-297-14909-3