メルペイはカオスな状態から組織がかたち作られる統一期にいる
矢尻 真実氏：今回のセミナーのタイトルにもなっている「全員品質」についてお話しします。初めまして、矢尻 真実と言います。このような大きな規模のセミナーで発言するのは初めてなので、とても緊張しています。ではよろしくお願いします。
まず自己紹介です。メルペイには、2019年の8月に入社して、今2年弱になります。それまでは職を転々としていて、新卒で就いた仕事は、ちょっと珍しい仕事で、神主さんです。ほかにも、大学の職員をしいました。25歳のときに、自分の好きなことをやりたいなと思ってIT業界に踏み込みました。それ以来15年間SEやプリセールス。ここ5年ぐらいは、QAの職種でエンジニアリングを経験してきました。
趣味は走ることで、走ったあとに温泉やサウナに入るのが好きです。たくさん走るので、たまに怪我するので、それを治せるように今は解剖学を勉強しています。
得意なことは、抽象的に考えたことをブレイクダウンすることなんですが、しゃべるのはあまり得意ではありません。考えながらしゃべる癖があるので、「言っていることがわかりにくい」と言われることがあります。なので、お聞き苦しいところもあるかと思いますが、よろしくお願いします。
まずメルペイのプロダクト組織が、どういう状況にあるのかなんですが、グランドローンチから先日で2周年を迎えることができました。私はローンチから少し経ったときに入社したんですが、およそ2年弱、先ほどmiisan（櫻井みづき氏）さんがお話ししたCredit Designなど含めた複数チームのテストに携わりました。
タックマンモデルをご存知の方もいるかと思いますが、混乱した状態から、メンバー全員が同じ方向を向いて組織がかたち作られていく統一期に差し掛かっているのかなと感じています。組織が立ち上がって間もないカオスな状態から、同じ方向にかたちを作っていく、その過渡期にメルペイのプロダクト組織はあると感じています。
プロジェクト体制の多様化に対応したポリシーとガイドラインを制定
メルペイではさまざまな機能がリリースされていて、そのためのプロジェクトが同時並行で非常にたくさん走っています。プロジェクトごとにすごいスピード感で進んでいて、体制もプロジェクトごとに多様です。
なので、特に品質保証のプロセスは明確な共通言語がなくて、QAと開発同士がなんとなく察し合ってコミュニケーションをしているなと思うことが度々ありました。結果的に、プロダクトが問題なくリリースされればよいのかもしれませんが、その確度や精度を上げていくためにお互いが活動の目的をもっとクリアにして品質保証活動をしていく。
そうすることで、最高のプロダクトだともっと自信を持ってリリースできるのではと思い、『品質保証活動のポリシー』と『ガイドライン』という文書を作成しました。コンセプトはプロジェクト体制の多様化に対応すること、役割よりも活動の目的を明確にすることです。ルールに当てはめて、この通りに動かなきゃいけないというよりは、自由に活動する上でのマインドセットとして普及できたらなという思いで、この2つの文書を作りました。
まずはPMが合理的な進め方をメンバーに明示すること
具体的な文書は社内のConfluenceにアップしてあるんですが、その中から、かいつまんでスライドにしたものをこれからお話ししたいなと思います。
先ほども言ったとおり、メルペイのプロジェクト体制はいろいろあって、すごく多様です。メルペイのQAセミナーでいろいろな方が、DevOpsの文脈であらゆるプロセスでテストすることを言っていると思うんですが、ときどきしっくりこないことがありました。
それはなんでなのかと、自分が携わったプロジェクトに立ち返って考えたときに、基本的にはメルペイではスクラム型が選ばれることが多いんですが、JIRAやアジャイルボードでカンバンを使っていても、実はプロジェクトは隠れウォーターフォール型で進んでいたことがあったことを思い出しました。
この場合は特に、開発者の息を合わせるのがギクシャクすることがあったので、それぞれのプロジェクトの実態をファクトに則して分類して、メンバー全員がイメージできる状態でテストする必要があるなと感じました。
そのためにプロジェクト開始時にスクラム型、ウォーターフォール型どちらで進めるのかを明示するようにしました。キックオフするのはプロダクトチームのPMが多いので、PMにどちらで進めるのが合理的か判断してもらって、プロジェクト開始時に開発メンバー全員に明示できる状態が望ましいと考えています。
基本的にはほとんどスクラムですが、外部のパートナーとシステム連携が必要な場合、それらとのシステムテストのスケジュールなどにコミットする必要があるので、ウォーターフォールを選択することがあります。
何のためのテストなのか目的別にテストタイプを作成
プロジェクトの開始時にスクラムかウォーターフォールかの手法を選択するんですが、それによって開発プロセスに対応する活動も若干変わります。ウォーターフォール型の場合は、Wモデルにあるようにテスト対象ごとに活動を紐づけていけばよいんですが、アジャイルテストというテーマで考えたときはイメージがしにくいことがよくあります。
前職で『実践アジャイルテスト』という本を買って読んでいて、もしかしたら知っている方もいるかもしれませんが、この左側のアジャイルテストの4象限の図を参考に、ビジネスレイヤーのテストなのか、技術レイヤーのテストなのか、チームを支援することが目的なのか、それとも製品を批評する目的で行うテストなのか……目的ごとに行うべきテストタイプを置いて、その中で品質にインパクトの大きい活動を選択して取り組むという定義をしました。
メンバー全員がマインドセットを意識して活動の精度を高める
ほかにも、テストについて「テスト、テスト」と開発者と会話をしているんですが、2020年の3月ぐらいにQA界隈で、「Checking vs. Testing」みたいな議論をされていたのをTwitterやブログで目にしました。そういうイメージのすみ分けはすごく大事だなと思って、みなさんの議論を見ていました。
開発者との間で何気なく〇〇テストと呼んでいるものはChecking、要求や仕様どおりに動作することを確認する活動と、探索的テストのような動作するプロダクトに向き合って学習や探索をする活動に分類をして、この2つを行うことで初めてテストをしたと言えるとしました。メルペイでは開発者も単体テストやE2Eのテストコードを書くので、このマインドセットをメンバー全員が意識することで、活動の精度を高められたらいいなと考えて、ポリシーにも盛り込んでいます。
4つのコンセプトを用いたリリース判定基準も今後作成予定
これから作る予定のものにはなるんですが、リリース判定基準についても明確にしていきたいと考えています。具体的なリリース判定基準はまだ標準化されてはいないんですが、ここに書かれている「十分なテスト」。このフレーズでピンと来た方もいるかと思いますが、PRISMAメソッドに出てくるフレーズです。これを参考にして、4つのリリース判定基準のコンセプトをメルペイの組織に合わせて作成しました。
まず1つ目が、重大インシデントを引き起こす欠陥がないこと。2つ目が現在の状態で十分に価値を出せること。3つ目がプロダクトの価値が残存リスクを上回ること。4つ目がリリースする利益がリリースを遅延させる損害を上回ること。これらを「十分なテスト」の定義にして、これからよりブレイクダウンして、リリース判定基準を作りたいと考えています。
「十分なテスト」のコンセプトには価値やリスクというワードがたくさん出てきました。これは「狩野モデル」のおなじみの図ですが、これとにらめっこしながら、「当たり前品質」と「魅力的品質」がKPIになるように数値化できないかという思いから着想しました。
具体的なKPIについては、これから定義していきますが、例えばリリースに対するインシデントの比率をダウンサイドとしたり、ABテストをやったり、社内では「おさわり会」と呼んでいるUAT（受け入れテスト）。ほかにも、リリース後の評判のネガティブとポジティブを指標として、追っていけたらなと考えて、これらのドキュメントを作成しました。
取り組みの成果についてですが、すべてはこれからという感じです。実はまだ社内にも未公開です。社内で未公開のものを先にみなさんにお披露目するのはどうかと思ったんですが、そこはメルペイの価値基準の「Go Bold」でお許しいただけたらと思います。
今月末に記念すべき第1回の勉強会を開催して、そこでプロジェクトメンバー全員にお披露目して、新しく入社するメンバーにも、オンボーディングのコンテンツとして浸透を図っていくと予定をしています。社歴としては2年弱で、まだ若いほうなんですが、このようなポリシーとガイドラインをこういう思いで作ったということを発表しました。
ご清聴ありがとうございました。
