2024.10.21
お互い疑心暗鬼になりがちな、経営企画と事業部の壁 組織に「分断」が生まれる要因と打開策
メルペイ開発組織の統一期における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.11.13
週3日働いて年収2,000万稼ぐ元印刷屋のおじさん 好きなことだけして楽に稼ぐ3つのパターン
2024.11.21
40代〜50代の管理職が「部下を承認する」のに苦戦するわけ 職場での「傷つき」をこじらせた世代に必要なこと
2024.11.20
成果が目立つ「攻めのタイプ」ばかり採用しがちな職場 「優秀な人材」を求める人がスルーしているもの
2024.11.20
「元エースの管理職」が若手営業を育てる時に陥りがちな罠 順調なチーム・苦戦するチームの違いから見る、育成のポイント
2024.11.11
自分の「本質的な才能」が見つかる一番簡単な質問 他者から「すごい」と思われても意外と気づかないのが才能
2023.03.21
民間宇宙開発で高まる「飛行機とロケットの衝突」の危機...どうやって回避する?
2024.11.18
20名の会社でGoogleの採用を真似するのはもったいない 人手不足の時代における「脱能力主義」のヒント
2024.11.19
がんばっているのに伸び悩む営業・成果を出す営業の違い 『無敗営業』著者が教える、つい陥りがちな「思い込み」の罠
2024.11.13
“退職者が出た時の会社の対応”を従業員は見ている 離職防止策の前に見つめ直したい、部下との向き合い方
2024.11.15
好きなことで起業、赤字を膨らませても引くに引けない理由 倒産リスクが一気に高まる、起業でありがちな失敗
2024.11.13
週3日働いて年収2,000万稼ぐ元印刷屋のおじさん 好きなことだけして楽に稼ぐ3つのパターン
2024.11.21
40代〜50代の管理職が「部下を承認する」のに苦戦するわけ 職場での「傷つき」をこじらせた世代に必要なこと
2024.11.20
成果が目立つ「攻めのタイプ」ばかり採用しがちな職場 「優秀な人材」を求める人がスルーしているもの
2024.11.20
「元エースの管理職」が若手営業を育てる時に陥りがちな罠 順調なチーム・苦戦するチームの違いから見る、育成のポイント
2024.11.11
自分の「本質的な才能」が見つかる一番簡単な質問 他者から「すごい」と思われても意外と気づかないのが才能
2023.03.21
民間宇宙開発で高まる「飛行機とロケットの衝突」の危機...どうやって回避する?
2024.11.18
20名の会社でGoogleの採用を真似するのはもったいない 人手不足の時代における「脱能力主義」のヒント
2024.11.19
がんばっているのに伸び悩む営業・成果を出す営業の違い 『無敗営業』著者が教える、つい陥りがちな「思い込み」の罠
2024.11.13
“退職者が出た時の会社の対応”を従業員は見ている 離職防止策の前に見つめ直したい、部下との向き合い方
2024.11.15
好きなことで起業、赤字を膨らませても引くに引けない理由 倒産リスクが一気に高まる、起業でありがちな失敗