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