QA戦略を立ててみたので、その内容とやり方を公開してみます
こんにちは、アルプでQAエンジニアをやっているyokota(@katawara)です。
早いものでもう少しで転職して一年が経とうとしています（！）
結果的に、そこそこの期間を一人QAとしてソロ活動してきたことになるわけですが、今回はその中でつくってきたQA戦略についてお話してみようかと思います。
QA戦略って？
QA戦略、つまり「QAの戦略」なんですが、場所によっては、「QAの方針」「品質戦略」みたいな言葉で言い換えられるかもしれません。そして人によっては、自分より上の立場の誰かが考えるべきことで私には縁遠い、なんてこともあるかもしれません。
一人QAとか、QA部門の立ち上げなんかを担当することになると、そういうことも考える機会にも遭遇する確率は高まるんじゃないでしょうか。そして、まっさらな状態からいざ考えようと思うと、意外と手が止まってしまうんじゃないでしょうか。
（着任初日に聞かれた）前職から通算すると、こういったことを考えるのは2回目なのですが、個人的には、「QA戦略を立てるということは、QAという機能は会社（もしくは事業）に対して、どういう価値を提供していくのか？ という問いに答えを出す活動のことである」と位置づけてみています（もちろん諸説あると思います）。
遠くのゴールを見つけ、そこにつながる活動が何かを定めて、それを遂行する。そしてはるか遠くと思われたゴールを徐々に現実へと近づけていく。このサイクルが回るようにしていくことが戦略を立てることだと理解しています。
アルプにおけるQA戦略
我々は何をするのか、何をもって貢献するのか。
実際に活動を始めて一年あまりが経過した中でちょっとずつ手直しを入れたりしていますが、2024年2月現在はこんな感じにしています。
遠くのゴール
1. 事業の成功を品質の観点から後押ししたい
ゴールに至るための活動テーマ
1. テストに関する業務をオープンかつイージーにする
2. アジャイルテスティングの考え方を体現する
3. 「超いい品質」よりも「ちょうどいい品質」を目指す
それぞれの活動テーマに対する実際の活動例
1. E2Eテストの開発メンバーとの共同所有、その前提になる安定化や実装のしやすさの土台づくり、QAと開発との会話の場づくり、などなど
2. 実例マッピング、テストドキュメントのテンプレート整備、などなど
3. 非機能要件の検討、業務理解・顧客理解、インシデント分析、などなど
解説
ゴール、活動テーマ、活動例、としてまとめています。実際のところ、活動テーマが最初にできて、抽象度を上げたものがゴール、具体例に落としたものが活動例といったところで、それらは後から肉付けしていきました。
ここでのコアは活動テーマになるので、そこだけ意図したところを説明しようかと思います。
1. テストに関する業務をオープンかつイージーにする
品質は特定の誰かだけの持ち物ではないと思っています。
しかし一方で誰かしらに偏りが生まれやすい領域であることも事実だと思っていて、そうならないためにも、テストに関する知識や技術は使いやすい形で共有していく必要があると考えている、というものです。
2. アジャイルテスティングの考え方を体現する
アルプの開発業務はアジャイル開発で行われています。サイズを小さくサイクルを短く業務を回すことで、価値を届けていきたいというスタイルに対して、テスト工程が後ろにのみ積まれるみたいな姿には懐疑的な面があります。
現在の開発スタイルにフィットしたあり方というのは存在するはずであり、その解がアジャイルテスティングなのではと考えています。その考え方を体現することでサステナブルな開発体験を生み出し、最終的には事業の成長につなげよう、というものです。
3.「超いい品質」よりも「ちょうどいい品質」を目指す
たとえば、推奨ブラウザではないブラウザで表示崩れを見つけ、それを指摘事項としてあげることは今本当に必要なことだっけ、みたいなことを問いながら業務に当たりたいね、有限の時間の中で価値に対して重要なことを指摘し続けられる状態でありたいね、というものです。一言で言えば過剰品質にならないように気をつけよう、といったところでしょうか。
補足
ゴール > 活動テーマ > 活動というツリー構造は、ちょうど戦略 > 戦術 > 戦闘という構造とも類似しているのではと思われます。
奇しくも、最近読んで以来かなり気に入っているのですが、活動テーマはLEADING QUALITYで言うところの
1 = 責任ナラティブ
2 = テストナラティブ
3 = 価値ナラティブ
と言えなくもない気がしています。
これを考えた当時は品質ナラティブについてはまだ知りませんでしたが、こういった品質文化をつくっていくということが、アルプにとっての品質戦略である、とも言い換えられるのかもしれません。
そのほか気にしたこととしては、基本的に難しい言葉はあまり使わないようにしています。
実際は付箋をべたべた貼りながら考えていたので、結果的に言葉も短めです。同時に、自分の中でテンションが上がるワーディングというのも大事にしています。
普段の運用としては、折に触れてこれらを眺め、どれをピックアップして力を入れていこうか、みたいなことを考えると、あら不思議、四半期の目標や長期戦略、と言われるものが説明できてしまう、というからくりです。こういうのを一回作って、あとは定期的に見直していくようにできると、目の前のことだけに流されてしまわれにくくなっていきます。もちろん、目標の世界においては目の前のことを追いかけるのも大事なので、それらとうまく混ぜて使うイメージですね。
実際どうやってつくるのか
さて、結論だけまとめるとこんな感じではあるものの、いざ同じようにつくろうとしてみるとなかなか手が動かない、ということもあろうかと思います。
なので、そういう誰かの取っ掛かりにでもなれば嬉しいなということで、こういったものを自分がどうつくっているか、みたいなことをまとめてみたいと思います。
なお、このやり方は過去のいろんなインプットの結果こうなった、という内容であり、そこそこに我流の部分は多いと思われます。N = 1の知見ということでご了承ください。
0. 用意するもの
それなりに長めの時間
横から邪魔されにくい環境
付箋 or まっさらなFigJamのボードのようなツール
個人的にはFigJamが思考の整理に便利でした
1. 推しのスクラップ
まずはその分野において、自身がいいと思うもの、理想とするもの、憧れるもの、といったもの、いわゆるその分野の推しを集めてみます。
誰かのスライドだったり、ブログの画像だったり、何かからの引用だったり、過去に影響を受けた誰かの言葉だったりなど、とにかく思い出せるものを片っ端から出してみます。
出し切ったなーと思えるところまでやってみましょう。
2. 社内の声の書き出し
続いてその分野において、社内の声を書き出してみます。
同僚の、開発者の、セールスの、上司の、自分の。期待されていることや、課題に感じていること、不安、それらも思い出せる範囲で書き出してみます。
同時に、直近の会社の状況やプロダクト・事業としての戦略みたいな情報もまとめておくと、一度に俯瞰できて便利だと思います。
3. やってきたこと・やりたいことの洗い出し
いきなり部門立ち上げを任されたとかでなければ、ここまでにやってきた資産や、やれるといいなと思っていることを棚卸しします。
積み上げてきたものがあるから次がつながっていくわけで、そういったものは大事にして、最大限活用の道を探りましょう。
また、2で集めたことを受けて、やりたいことが新たに出てくるということもあると思います。それらも精査するのは後回しにしてまずは書き出していくといいと思います。
4. とりまとめ
ここまでをまとめていくと、一定の方向性が見えてくるのではと思います。
特に、1で集めたものを近い内容でまとめてみると、いくつかに集約されるのではないかと思われます。自分たちの指向性が見えてくるのではないでしょうか。
これが、先程上で書いた活動テーマにマッピングされていきます（下の図で言う、緑の付箋）。
そして、2と3の中で出てきたやってきたこと・やりたいこと（下の図で言う黄色とピンクの付箋）を活動テーマに対応する活動としてぶら下げていくと、活動例としてマッピングされていきます。
これでおおよその戦略の原型ができてきます。
あとは活動テーマがさらに上位の抽象的な概念にまとめられそうか考えてみて、時間が進むと解像度も変わってくるはずなので、テーマと活動を随時見直していく、といった感じです（実際、自分の場合でも3番目の「『超いい品質』よりも『ちょうどいい品質』を目指す」の活動テーマを出したのは、初版を作ってから半年後の見直しのタイミングだったりします）。
5. この後の運用
個人的には約束事として以下を決めています。
絶対のものにしない
間違っていると思ったら随時修正しても良い
解像度が上がってきたり前提が変わってきたら随時変えても良い
状況は変わるのでこれさえやっていればいいと思考停止しない
最初からすべてを見通して、スパッときれいなものがつくれるとは限りません。それに長期に渡って正しいものでもなければ、日々の業務を硬直させるものでもないはずであり、そこに縛られて身動きが取れなくなるのもまた違うと思います。
日常のやるべきことに流されてしまったとき、折に触れて見返して、初心にかえるためのツールとして使うのがいいんじゃないかなと思っています。
おわりに
今回はアルプとしてのQA戦略を紹介しつつ、自分がどんな感じでつくってみたかを紹介してみました。
同じような境遇になった人にとって、何らかの参考になれば幸いです。
改めてつくり方をまとめてみると、Will Can Mustのフレームワークと近しいような気がしますね。
それを組織版で展開したらこうなった、みたいな。
こういうのが一回できると、チームのアイデンティティを定義したり、現在地を対外的に説明するのにも便利だと思われます。
現場からは以上です！
この記事が気に入ったらサポートをしてみませんか？