見出し画像

JaSST'23Tokyoと，10年後の世界と．

うへの

こんばんは．JaSST Tokyo共同実行委員長のうへのです．

今日2023年3月9日は，JaSST'23 Tokyoの1日目．今回のJaSSTに込めた想いを綴ってみたいと思います．

JaSST’23 Tokyoのテーマは，「相互理解で広がる世界」と題しました．これまでのJaSSTで多く取り上げられてきた王道のテーマだけではなく，基調講演のカオスエンジニアリングのように，テクニカルかつ組織的に取り組んでいかなければならないテーマを取り上げています．

最近「相互理解」のようなテーマを冠するカンファレンスは多くなってきているように感じます．売れるサービスやプロダクトを作るためには，ユーザーからの早いフィードバックが必要だから，リリースまでのリードタイムを短くしなければならないのだ，という話はすでに何度も語られていることです．それを実現するためには，組織がサイロ化していてはダメで，権限がチームに委譲されており，どんな不確実な状態にも素早く対応できる必要がある．そのためにはこれまで職能別チームだったとしても，一つのチームとしてやっていかなくてはならず，お互いのやっていることを少しずつでも理解していかなければならない．「相互理解」という言葉からは，これまでのやり方から脱却しないといけない，という危機感も含まれているように感じます．

ただ，相互理解というと，どうしてもマインドセットとか態度，ヘタをするとワイワイ楽しければいい，といったただのポエムになりやすいような気がしています（もちろんこれは私の肌感覚で，根拠はありませんが）．どうしてもチームビルディングや組織論の話になり，「あー，またいつものやつね」と分かった気になり，「組織を変えるのは難しい」という結論に落ち着いてはいないでしょうか．組織の問題に取り組むのは難しいので明日から自分にできることをしようと，チーム内で努力されている方はもちろんたくさんいらっしゃるに違いありません．ですが，開発者に協力してもらってテストの進捗は滞りなかった，という事象に落ち着くとしたら，それは本当に「相互理解」が目指したい世界なのでしょうか？「QA」なので「開発者」任せにするのではなく，理解して，自分でも使えるようになろう．必要な技術を自分から発信し，周りの人に教えよう．そう思っていないといけないのです．

今アジャイルやDevOpsで語られているQA像というのは，「早くテストする」「品質を作り込む」，といったシフトレフトの色合いが強いように感じます（これも肌感にすぎませんが…）．確かに不具合をなるべく作り込まないとか，早期に潰すことはとても大切です．ですが，一歩間違えれば守りに入りすぎてしまい，本来ならば望ましくない「品質ゲート」のようなものになってしまうのではないか．そうなってしまうと，アジャイルやDevOpsの本来の価値である「早期にリリースして，ユーザーからのフィードバックを得る」ことからはほど遠くなってしまいます．ユーザー影響の少ない不具合ならばリリースしてかまわない，なぜならリリースサイクルが十分に短くすぐに修正できるから，という考え方とセットでない限り，QAの活動はゲートと化して行ってしまうのではないか，という気がしたのです．

ポエムでもなければ，シフトレフトに偏りすぎてもいけない．そんなメッセージを伝えたいと思っていました．その点，カオスエンジニアリングは，リリースや障害対応のリードタイムを極めて短くできる技術的基盤を前提としながら，意思決定者を含めた多くの関係者を巻き込まなければなりません．組織を巻き込んだ相互理解そのものであり，シフトライトの最たるものであり，極めてテクニカルであり，基調講演にふさわしいと感じたのです．

QAの見るべき範囲はアジャイル，DevOpsが出てきたあたりからどんどん広がっているように感じます．カオスエンジニアリングもまさにその中の一つなのでしょう．きっと10年後にはテスト自動化や探索的テストと同じように，カオスエンジニアリングも認知が高まっているに違いありません．

いつぞやのJaSST nanoで登壇させていただいたときに，「JaSST Tokyoから，その年のトレンドを作り出していきたい」と豪語した記憶がありますが，果たしてどうなることでしょうか．

謝辞

今回のテーマ設定には，JaSST’22Niigataのテーマだった「Observability」から多くの示唆を得ました．ありがとうございました．

また，本noteは情報交換会のテーマトーク「JaSSTの裏話」で じゅんぺー氏と話していたときに書くことが決定したものです．あの場にいてくださった皆様，ありがとうございました．

ではまた明日，お会いしましょう．

この記事が気に入ったらサポートをしてみませんか？