この世界には、「スクラムフェス新潟」というイベントがある。
前置き
「今日QAチームではテストケースを50件消化しました。進捗は予定通りです」
「開発が終わりました。QAチームは、テストを開始してください」
「QAのテストが完了しました。報告書を作成したので、開発リーダーは確認してください」
よくある報告だ。ありふれている。こういうQAチームは、星の数ほどあるだろう。
でも、本当にそれでいいのだろうか？
QAはテスト専門部隊なのだろうか？
本当に？
QAとはなにか。
品質保証だ。
品質を保証するって、なんだ？
テストすることか？
違う。
僕は品質を保証するというのは、「作る段階から、すでに良い品質のものを作っている」という状態を作ることだと思っている。
全部をテストでどうにかしようとしたら、どうなるか。
すごく、大変になる。
あれもこれもテストしないといけない。
大変だ。
残業にもなる。
そうしたら、当然抜けも出る。
抜けが出たら？障害が起きる。
当然思うはずだ。「あんなにテストしていたのに、どうして？」
逆だ。
「テストだけでどうにかしようとしていたから」、障害が起きたのだ。
なので、障害が起きたのは、テストに依存しすぎたからだ。
テストは万能ではない。
私にとっては当然の帰結だが改めてここで言っておく。
QAにとって、良い作り方を知ること、理解することは必須の業務要件だ。
それが知らないのでは、永遠にQAと言いながら実際にはテストオペレーターのままだ。
品質を保証なんてできちゃいない。
いまはAIがあるから大丈夫？
逆だ。
AIがあるからこそ、QAが保証しないと、誰も品質を保証できなくなる。
なぜこうなってるのか、なぜ障害が起きているのか、誰もわからない。誰も直せない。障害は永遠に復旧せず、障害対応のMeetは24時間つけっぱなし。
そうなるよ。絶対に。断言する。
この生成AI時代にQAを軽視した組織は、必ずそのしっぺ返しを食う。
QAの仕事は、品質を保証するということなんですよ。
だから、絶対にここから逃げてはいけないんです。
つまり、テストすることや、レビューをすることは、手段であって、それ自体が目的ではないんです。
だから、仕事として「テストしました」とか、「レビューしました」っていうのは、
「今日、会社行きました」って言ってるようなもんで、何いってんだ？って話なわけですよ。
僕たちは、「なぜこのテストになってるのか」「なんでこれをテストしていて、これはしていないのか」「これでリリースできるのはなぜなのか」を、説明できないといけないんです。
というか、そういう、品質とかテスト状況みたいな、目に見えないものを見えるようにして説明できるようにすることが、QAのスキルのひとつなんですよ。
で、そういうのをやろうとすると、「じゃあこれって、そもそもどうやって、誰が作っていたんだっけ？」「リリースの判断って、誰がどうやってしてるんだっけ？」みたいな議論と地続きになっていきます。
つまり、どうやって作ってるんだっけ？どうやって開発してるんだっけ？というのが、知りたくなってくるのです。
はい。
徐々にスクラムの話に近づいてきましたね。
もう少し待ってください。
ここまで書かないと、
「スクラム？オレのチームはスクラムじゃないから関係ないよ。ていうかスクラムとQA関係なくね？」
みたいな寝言を言うやつに、思い切りパンチをぶちかましてやれないんで。
さて
作り方の話になってきましたが
んー、じゃあ良い作り方ってなんなんすかね。
そういえば、標準プロセスっていうのがあるらしいぞ。
それに沿ってやれば、高品質になるんじゃね？
はい、落とし穴ですね。
そんなことができれば苦労しません。
ソフトウェア開発は人間が、いろんな要件を受けて、その要件が途中で変わって、メンバーも入れ替わり、作る機能も毎回違う、とても複雑なプロセスです。
だから、たとえ全く同じ手順で開発をしたとしても、結果は同一に絶対にならないんです。
そんなあ。じゃあ、うまくいかなくてもしょうがないじゃん。あきらめるか。
…って、できたら苦労しないですよね。
我々はソフトウェア開発のプロなので、お客さんからしたら「この柱立てるの大変なんだよね」とか「マグロって切りにくくて」とか言われても「知らねーよ。仕事なんだからやれよ」としかならんのと同じで「いいから、なんとかしてよ」ってなるわけです。
困りましたね。
うーん。
…
スクラムだ！
はい。
スクラムはそういった、複雑性のあるプロセスのなかで、それでも予測・対応できるようにしていくために、チームの学習や相互作用に着目した枠組みです。つまり、そういった複雑性に対するアプローチのひとつが、スクラムということです。
やっとたどり着いた。
私がずっと言いたかったのは、
本質的にQAを突き詰めていったらそれはスクラムやアジャイル開発にたどり着かないとおかしいし、それを考えたことがないのは真剣にQAと向き合って考えたことが一度もないのと同義であるということです。
もちろんスクラムは唯一解ではないし、スクラムにしたからといって絶対品質が上がるかといったらそういうものでもありません。
それでも、QAを突き詰めて考えていった帰結としては、ほぼ必ず、間違いなく一度は通るのがアジャイル開発や、スクラムだと私は思っています。
スクラムフェス新潟というイベント
ここまで書いたらさすがにスクラムの重要性はご理解いただけたと思いますが、ここで改めてスクラムフェス新潟について紹介させていただきます。
QA、テストに関するコンテンツが比較的多い
スクラムイベントのなかでは比較的、ソフトウェアテストやQAに関するコンテンツが多いです。なので、スクラムにあまり詳しくないQAの方も入りやすいと思います。
セッションの質が異様に高い
これは半分くらい想像ですが、これはスクラムフェス新潟のブランド力、コミュニティ力などによるものだと思っています。数年間の開催のなかで、ファンが広がり、そのファンがまだ参加者を広げていく。そして、たくさんの良いプロポーザルが集まるようになり、さらにレベルが上がる。フィードバックを得て、さらに改善される。そういう、ポジティブな循環が機能しているのだと思っています。
新潟の飯と酒がうまい
もはや解説は不要ですね
個人的な感想
個人的にはQAとしても非常に有益なセッションばかりで、投資対効果はとんでもなかったです。やっぱりシンプルに、すべてのセッションが面白く興味深いものばかりだったというのが大きいです。地に足のついた、血の通った事例発表をたくさん聞くことができました。正直、すべてのQAエンジニアが新潟に集ってしまい、空港がパンクし、朱鷺メッセが貸し切りになるほど押し寄せても全然いいんじゃないかと思っています。
QAのみなさん、スクラムフェス新潟めっちゃおすすめです。絶対後悔しないですよ。
結論
QAは新潟に行け。
