plusと出会い、かねてより興味のあった教育業界にものづくりの立場から貢献できることに大きな魅力を感じ、業界業種未経験ながら、QAとしての入社を決意。plusのプロダクトを通して、生徒に学ぶことの楽しさを伝えたい。Assurance:品質保証)について、最大の特徴はなんでしょうか?渡辺:1チームに1人のQAがいる体制が、一番大きな特徴だと思っています。チーム全体でプロダクトの品質を高めていこう、という考え方が浸透してきてるのもいい流れですね。Testing」(以下アジャイルテスティング)の考え方ですね。アジャイル開発におけるプロダクト品質に対するマインドセットとして、近年注目されています。plusではそうではありません。「開発後にバグを見つける」ではなく、「バグを作りこまない」ことを意識して、チーム全体でプロダクト開発をしています。これによって、より早く、より良いものをユーザーに届けよう、というのが、アジャイルテスティングの基本的な考え方ですね。plusでは、アジャイルテスティングの考え方がどのように浸透しているのでしょう?渡辺:QAだけでなく、プロダクトチーム全体でアジャイルテスティングに取り組んでいます。赤根:チーム内で実施されている、週次のレトロスペクティブ(振り返り会:以下レトロ)で、品質の課題点があれば、チーム全体でそれに対する打ち手を考えることが習慣になっていますね。Condenced」という書籍の読書会を実施するくらい、品質への意識が高まってきていますね。チーム内の品質に対する考え方がすり合っているので、日々の品質改善の活動はとてもスムーズに行われていると思います。具体的に、チームでどのような品質改善活動をされているのですか?宮田:毎週のレトロで、チームが感じている様々な課題に対して、その都度、具体的なアクションをチーム全員で検討します。会社のカルチャーとして「新しいことをまずは小さくはじめてみよう」という"アジャイル"の考え方があるので、品質に関する改善活動もどんどんやっていこうぜ!という雰囲気です。赤根:例えば、「開発中の不具合が多く、開発効率が上がらない」という課題については、毎週その週に出た不具合をチームで分析する時間を設けました。「機能開発の後半で、パフォーマンスの問題が発見され、大きな手戻りとなってしまった」となれば、次からはリスクの大きいところからテストできるように計画を立てよう、と決めたこともありました。チーム内での認識が合えば、すぐにアクションを実行します。渡辺:地道なところからコツコツと、チーム全体で品質改善活動に取り組んでいます。いった品質に関する活動を主導することも、QAの大きな役割のひとつです。活動の中で、「これは特にうまくいった!」みたいな事例はありますか?渡辺:「ふるまいを書いて仕様の認識をそろえよう」という取り組みはうまくいきましたね。赤根:「ふるまいを書く」というのは、実際のユーザーを主語にして、プロダクトがどのように「ふるまうのか」を記述しよう、というプラクティスです。誰が読んでも誤解なく読み取れるような記述方法を使うことで、認識齟齬が発生しづらくなります。渡辺:1月頃にはひとつの機能開発中に30件も不具合が出るようなこともあったのですが、ふるまいを書くようになってからは、ひとつの開発でだいたい2〜3件程度まで不具合が減りました。発生した不具合のうち、クリティカルなものはほとんどなく、簡単な修正で済むようなものばかりになりましたね。このふるまいを書く取り組みを始めたきっかけを教えてください宮田:不具合が多く発生していた当時、レトロでその原因をふりかえったところ、「チームメンバー間の、仕様に対する認識齟齬で不具合が発生しているよね」という話になりました。その打ち手となるアクションをチームで考えていた時に、アジャイル開発の経験が長い赤根さんが、「ふるまいを書くこと」を提案してくれました。赤根:この「ふるまいを書く」という取り組みは、プログラム開発手法のひとつである「BDD(ふるまい駆動開発)」の一部です。仕様に関するユーザーストーリーを、より具体的に表現できるので、簡単に始められるアクションとして有効なのでは、と考えて案を出しました。渡辺:これはよさそう!ということで、早速その週からチーム全体で取り組むことにしたんですよね。わかりやすいふるまいの具体例などはありますか?渡辺:例えば、「教科選択画面で中学英語を選択したら、学習が開始できる」という仕様をふるまいとして記述すると、以下のようになります。中学英語の学習ホーム画面に遷移したことがわかる(それに対する結果)宮田:簡単な仕様でも、ふるまいを書いてみると、ユーザーの実際の様子を、より具体的にイメージできます。plusの場合、主語をペルソナとして記述できるので、ふるまいを書くことでよりユーザーを意識した仕様が検討できると思っています。実際に取り組み始めてからはいかがでしたか?渡辺:仕様を決める段階で、ふるまいを書いて、チームみんなで確認することで、あきらかにメンバー間の仕様に関する認識齟齬が減りましたね。ふるまいを具体的に記述する過程で、「あれ?そういえばこんなときはどうなるんだ?」と、新たな観点が見つかることもあります。機能を作る前の、このタイミングで観点に気づくことができれば、まさにアジャイルテスティングで言う「バグを作りこまない」ことにつながりますよね。宮田:始めはふるまいを書くことに慣れておらず、チーム全員で1時間以上使って苦労しながら書いていました。大変でしたが、機能を作り終わってから手戻りのコストが発生するよりはずっといいと考えて、取り組みを続けました。赤根:明らかに開発効率が上がったという手ごたえを感じたのは、取り組み始めてから3カ月程たった頃のこと。この一連の取り組みを、成功事例として他のチームにも展開することができました。現在は同様の取り組みを開始しているチームもあるようです。チーム全体でプロダクトの品質を高めよう、という雰囲気が伝わってきました。plusのカルチャーとしてありました。アジャイルテスティングに対する意識が高まってきたのはここ半年くらいですね。2020年のはじめ頃から、各開発チームにQAを1人アサインする、という流れはありましたが、当時はまだ「チーム内にいるテスト担当者」みたいな立ち位置だった気がします。渡辺:2020年の後半あたりから、QA全員がアジャイルテスティングの考え方や手法を学び、QAの本来の役割である「品質活動の推進者」に少しずつ近づいてきていることを感じています。QAの成長に伴って、プロダクトチーム全体の品質に対する意識が上がっていった面もあるかもしれません。plus全体のカルチャーとしてあったので、アジャイルテスティングの考え方はとても浸透しやすかったのだと思います。宮田:あとは、毎週チームのレトロで開発をふりかえり、課題があればすぐにアクションを検討して、実際にやってみる。いうカルチャーも、アジャイルテスティングを加速させていますよね。アジャイルテスティングが浸透してきて、チームはどのように変わってきましたか?宮田:以前と比べて一番変わったのは、やっぱり「バグを作りこまない」という意識ではないでしょうか。機能を「作り終わってからテストしてバグを見つける」ではなく、「バグが出ないように作ろう」とチーム全体で心がけるようになりました。赤根:バグが出ないように作れば、開発が終わった時点で、ある程度の品質が担保された状態になります。...のような工程が減るので、より早く、より良いプロダクトをユーザーに届けられるようになるよね、という共通認識を、チーム内で持てていますね。渡辺:ひとつの機能開発でも、全部完成してからテストするのではなく、メインの部分が完成したら一度テストし、フィードバックして、さらに細部を作りこみます。QAとしても、従来のテスト実施にかかる時間が減ってきたので、単なる「テストでのバグ探し」ではなく、「品質を上げる活動」に時間をより割けるようになってきました。品質活動を主導するQAがチームにいる環境は、他メンバーにとってはいかがですか?宮田:アジャイルテスティングが浸透してからは特に、QAのことを「テストする人」とは思わなくなりました。QAの人はプロダクトの仕様に誰よりも詳しい上に、「ユーザーにより良いものを届けたい」というマインドを持っています。そんなQAの「この仕様だと、こういうユーザーが困るのでは?」みたいなFBは、デザインをする上でとても助かっていますね。赤根:エンジニアにとっても、チームにQAがいるのはとても頼もしいですね。これまでの環境では、エンジニア自身でテストコードを書き品質を担保するという意識が強く、QAと連携するとしても、作り終わったものについてテストを依頼する、という流れが普通でした。plusでは、プロダクト仕様に詳しいQAがチーム内にいて、仕様検討の早い段階から、一緒にリスクをつぶしながら開発を進められるので、安心して開発に集中できています。渡辺:そういっていただけると、QA冥利に尽きますね(笑)。plusでは、QAはあたりまえのようにチームの一員で、「開発者」です。自分はプロダクト作りに関わっている、という実感があり、とてもやりがいを感じています。アジャイルテスティングの姿勢によって、開発がうまくいっているようですが、今後の伸びしろはどういうことろにありますか?市川:「チーム全体で品質を高めよう!」という姿勢は浸透してきていますが、アジャイルテスティングの取り組みは、まだまだ道半ばです。これまで真摯にアジャイルテスティングに取り組んできて、やっと成果が出てきたのかな、という段階だと考えています。渡辺:より早く、より良いものを生徒に届けようと思うと、一番の課題はテストの自動化ですかね。先ほど話にあがったBDD(ふるまい駆動開発)も、本来は記述されたふるまいをコード上のテストに落とし込むところまでが一連のプラクティスになります。テスト自動化が進んではいるものの、品質の担保はまだまだ手動テストに頼る部分が多いですからね。テストの自動化が進むと、QAの役割も変わっていきそうですが、これからのQAに求められるものって何でしょうか?市川:今以上に、担える役割が増えていくと思っています。テスト自動化についてもエンジニアと協力して推進したいですね。plusのQAとしては、新しいことを学習し続ける姿勢や、ユーザーに品質の高いプロダクトを届けようという想いを大切にし続けたいです。渡辺:私もそう思います。テストの自動化が進めば、テスト実施の作業時間が減り、よりプロダクトの品質を高める活動に注力できるようになりますよね。「マイナス面を減らす」品質改善だけでなく、「プラスの価値を提供する」活動に貢献できると思っています。そのためには、専門的な知識もですし、「ユーザーにとっての価値」をもっと深く理解する必要があると考えています。今以上にQAとしての挑戦の機会が増えそうで楽しみです。