【ウェビナーレポート】成長SaaSのQAマネージャーが語る！ 事業フェーズに合わせたプロダクト組織のありかた
メンバーズが主催したウェビナー「成長SaaSのQAマネージャーが語る！ 事業フェーズに合わせたプロダクト組織のありかた」。成長SaaS企業であるMNTSQ株式会社とMicoworks株式会社のQAマネージャーをお招きし、パネルディスカッションを行いました。
メンバーズのQuality Approachカンパニーのカンパニー社長である小池がモデレーターとなり、成長著しいSaaS型ビジネスにおけるプロダクト開発体制の在り方についてお話を伺いました。
当日の様子をレポートでお届けします。
SaaS企業のQAマネージャーと語る、QAの開発体制や組織づくり
小池：本日はQAという観点で２社のSaaS企業のQAマネージャーにご登壇いただき、実際どのような開発体制やQA体制でプロダクトの品質を作りこんでいくのかというところをお話しいただければと思っております。まずはMNTSQ株式会社の石川さん、お願いします。
MNTSQ株式会社について
石川：MNTSQ株式会社、QAマネージャーの石川と申します。私は第三者検証を2社経験した後に、QAチームの立ち上げや自動化ツールのカスタマーサクセスに従事し、自動化の支援やQAの立ち上げに携わりました。今年の6月より現職のQAマネージャーに就任し、QAチームの立ち上げや開発プロセスの改善を行っています。
MNTSQ株式会社は「全ての合意をフェアにする」をミッションとしています。例えば企業間で契約を締結する際に、相手企業の立場が強く不都合な契約を結ばざるを得ない、ということがあると思います。そういったリスクをなるべくお互い合意の上でフェアにしていくことを目指している会社です。2018年に設立し、先日5周年を迎えました。
弊社では、契約書や契約締結にまつわる課題を解決するプロダクトを開発しています。
法務相談や契約書のドラフト作成、契約のライフサイクルを一気通貫でサポートすることを目指しています。契約は機械学習と相性が良く、過去の法令を参照してリスクについての示唆を出し、ナレッジマネジメントすることによって、次の契約に生かすサイクルを作れるサービスを提供しております。
次に、プロダクト開発体制です。
弊社は2週間で1サイクルというスプリントでアジャイル開発、スクラム開発をしています。
イシューレイズという文化があり、どの職種であってもプロダクトに意見を言うことができ、お客様の意見をしっかり吸い出して、それをプロダクトに反映しようという思想を持っています。お客様からの意見やご要望をしっかり聞き、機能に落とし込むところをPdMが中心となって開発を行っております。
最後に開発体制にQAがどうやって関わっているのか、紹介させてください。
弊社のCLMの大きなプロダクトの中に小さなプロダクトがいくつかございます。その中でAチームBチームといった小さなスクラム開発が回っておりまして、そちらにQAを1名ずつ置き、その下に随時アサインをしてサイクルを回しています。
11月より新しいチームでQAのサイクルの立ち上げを実施。また大きなプロジェクトを立てウォーターフォール開発も実施。随時QAをアサインしたり、エンジニアをアサインして実施をしていくという体制になっております。
続いてMicoworks株式会社の古谷さんにバトンタッチさせていただきます。
Micoworks株式会社について
古谷：Micoworks株式会社 QAチーム マネージャーの古谷と申します。2017年に大阪で創業し、今年で7期目を迎えました。元々は人材のマッチングサービスでスタートした会社なんですが、最近はLINEマーケティング領域のプロダクトを提供しており、どんどん勢いをつけています。
提供プロダクトとしては、先ほど説明した「MicoCloud」と、「ミコミー」というプロダクトの二つです。主力プロダクトの「MicoCloud」はLINEを活用して、企業と顧客のコミュニケーションを最適化するマーケティングプラットフォームです。2023年にLINE社の認定パートナー制度である「LINE Technology Partner」のコミュニケーション部門において最上位グレードである「Premier」認定をいただいております。
弊社の2023年の中期ビジョンとして「アジアNo.1のブランドエンパワーメントカンパニー」を目指しており、そのためにBtoCのコミュニケーションのあり方を変えていこうとしています。現在は、1000ブランド以上の導入実績がございまして、あなたが登録しているLINE公式アカウントの裏側にMicoCloudが、なんてことも最近は増えていると思います。
続いて、Micoworksの開発の組織図とQAチームの関係と規模をご説明いたします。開発組織の構造としてはプロダクト統括本部の下に、プロダクト開発チームやプロダクト企画チーム、QAチームが存在しています。
QAチームは現在10名ほどです。QAチームのメンバーはプロダクトごとに担当が分かれている、横断型の組織です。私がマネージャーを務めており、リードQAをいずれやれそうなQAエンジニア、あとSETエンジニアがいたり…。自動化などの推進も視野に入れて準備を進めております。
一つのプロダクトに対してQAの担当者は2人以上つける体制となっており、仮にどちらかが不在であっても支障がないよう体制構築を進めております。
これはあるプロダクトのケースです。ウォーターフォールっぽく開発しているのですが、QAは仕様検討にはじまり、リリースについても関与しています。他部門からの相談を随時受けながら、はじめから終わりまで全てQAが関与する状態になっております。
私たちQAチームではチームバリューを掲げています。「品質と速度の両立をしよう」というのはよく言われますね。品質と速度はトレードオフだと思われがちですが、「品質良くて速い」はあるんだぞ、というのをバリューにしています。続いては「当たり前品質110%」。「当たり前品質」って皆さん考えてらっしゃるかと思うんですけど、ユーザーがプロダクトを滞りなく使えるようにしたいと。ただ、当たり前に使える必要十分な品質を担保することが案外難しい。その当たり前を越えていきたい、という意図でバリューとして設定しています。
最後は、「プロダクトに関わる人をハッピーに！」。QAは横断的組織なので、開発や営業など様々な方と関わります。関わる人全員が幸せになれるようなプロダクト開発をしていきたいと思っています。
品質文化をどのように作っていくべきか
小池：皆さんからいただいた質問で多かったのが、組織においてQAチームを作ろうとしているけれど、品質文化をどうやって作っていけばいいのでしょうか？という質問です。石川さん、いかがでしょうか？
それぞれが話しながら、思わず熱くなる場面も。
石川：私は6月に入社したんですが、まずびっくりしたことが、社員の品質に対する思いがすごく強かったんですよ。それはありがたい反面、品質について思ってることがみんな違うという状態だったんですね。
ある人はすごく完璧なプロダクト、バグがないプロダクトに対しての品質に思いを持っている。あるいは別の方は、ユーザー目線の品質に関して特化した思いを強く持たれていたり。「じゃあQAチームができたら、どういう品質が守られるの？」というところがすごく中ぶらりんな状態だったことが、一番苦労しましたね。
その解決策としてQAチームのロードマップを作ってはどうか、というアドバイスをしました。QAチームはまずはこれをするんだという。
そもそもテストという文化が薄くて。それがなければ品質は守れないので、まずはその土台を作っていこうと考えました。土台を作った上で次何をするのか。機械学習の精度の向上をするのか、もっとUI/UXにこだわっていくのかというところは、内容を高めながら考えていこう、という風にロードマップをしっかり明示したんです。それによってQAチームはまずは土台を作るチームなんだね、という認識が明確になりました。開発プロセスにも入っていくし、スクラムマスターみたいな役割も担っていきますというところを明示したんです。それが一番最初のアプローチとしてうまくいったなと思っています。
小池：ロードマップはどれぐらいの期間を見据えて作成されたんですか。
石川：2024年のQ2までをいったんマイルストーンとしておいています。2024年はこんなところも手を出していきたい、例えば自動化や、検索精度の方にちょっと手を出していきたいよという願望まで書いて…という感じのロードマップを作っていますね。
小池：一旦来年中にここまでやるから、今年はここまで…みたいな感じでしょうか。
石川：そうです、そうです。
小池：大事ですよね。古谷さんのほうはいかがでしょうか。
古谷：私が入社したときは2名、QAエンジニアがいたのですが、まだチームという感じではなかったんですよね。私が入ったときからどんどんチーム化が進み、メンバーと相談や壁打ちをしながら進められるようになりました。ですが、やっぱり組織が一気に拡大している会社なので、いろんな会社からいろんなメンバーが入ってくるというところもありまして。 品質と一口に言っても、何が良くて何が良くないのかというのは一概に言えないところがあります。
そのため、皆さんが思ってる「品質がいい」という言葉が何を指すのかは、人それぞれ違う、ということを理解してもらうための社内イベントをまずは実施しました。それでも統一が図れるわけではなくて、それぞれ品質についての考え方があります。でも、まずはそれを理解するところからではないでしょうか。
小池：どういうイベントを企画されたんですか。
古谷：Micoworksでは月に一度、オフラインで社内のミートアップイベントがありますが、その中でディスカッションをする時間をとりました。話題をQAチームの中で考えて整理して、皆さんの考える「品質がいい」とは何ですか、「品質が悪い」とは何ですかと言う話をして、それを書き出してもらったりしました。
小池：ワークショップみたいな感じなんでしょうか。
古谷：そうですね。プロダクト関連組織全体でそのようなことを実施しました。
「品質」という言葉がいかに曖昧なものなのか、ということを感じて欲しかったんですよ。QAが入ったとしてもその品質が完璧になるというのは夢のような話で。QAエンジニアというのは、それを少しでも綺麗にする活動をしているんですよね。
しかも常に日進月歩の業界なので、新しい技術は取り入れながらも、メンバー一人ひとりが異なる定義の「品質」というものを求めながら、最低ラインを決めていくための活動に近頃は移りつつありますね。
小池：「当たり前品質110%」というQAバリューについて伺います。まずQAバリューがあること自体が素晴らしいですね。これはどのように作って発信されたのでしょうか。
古谷：バリューを作ったのは、実は今年の9月なんですよ。Micoworksでは開発組織のグローバル化を目指し、海外エンジニアの採用を加速させています。そうなると、元々品質についての定義がQAチームの中でも異なる中で、多様なバックグラウンドを持つ海外メンバーが入ってくるとその課題がより大きくなるのではないかと思ったんです。
QAの仕事の先にあるものって何だろう、みたいなことを考えてほしいなという狙いもありました。
どこまで内製する？外部パートナーとの上手な付き合い方
小池：QAロールの採用難もひとつの課題だと思います。
内製していくところと外部に頼るところの切り分けや、外部パートナーとの付き合い方については各社の方針がありそうですね。そのあたりもお話聞かせていただけますか。
石川：弊社ではQAに関してはまだ本格的にスタートして半年ほどというところでして、どうしても外部パートナーに頼らなければうまくいかないところがありました。
基本的にリグレッションテストだったり物量をこなしてもらうところに関しては外部パートナーさんにお願いしています。
その中で少しチームに入っていく必要があったり、より高速にテストをしていくところは外部パートナーさんに責任をとっていただくことはすごく難しいですね。時間制限や契約制限も大変な部分が多いです。なので、そこをなるべく内製化していきたいと、もともと思っていたんです。
たまたまご縁があってヘルプで入ってくださった方が、テストって面白いね、というふうに思ってくださり、まず11月に正式にQAチームにジョインという形になりました。
その方のやりたいことがマッチしてれば、すごくいい方にQAに入っていただけると思っています。
ただ、物量をこなしたり、ウォーターフォールの開発をしたときにちゃんとテスト計画ができて、それを項目作って外に投げるというのは結構効率がいいとも思っています。
スクラム開発で開発するものについては内製化していく。ある程度型が決まっているものに関しては、なるべく外に出していくというところでバランスをとっていきたいと思っています。
小池：スクラムを組むとなると、外部パートナーさんを入れるにしても、なかなかコミットしきれる外部パートナーさんもいないということなんでしょうか。
石川：そうですね。私も第三者検証時代にそうやってスクラム開発に入る案件をいくつかやらせていただいたのですが、やはり外部の立場だとできることに限界があるのは事実です。どうやってコミュニケーションとっていい塩梅を作るのかってすごく難しいですね。
だから最初からではなく、ある程度整えてから外部パートナーさんを入れましょうという感じになると思います。
小池：契約関係もあるので、ある程度マネジメントレイヤーとか、上をうまく使うみたいなところは大事ですね。古谷さんの方はいかがでしょう。
古谷：外部パートナーには力を借りたいパートで一定入っていただいてる状況です。どうしても、テストの物量が時期によって違ったり、新規開発が来ることもやっぱりあって。開発スピードを加速させたいときや、開発フェーズや時期による変化の波に対応するところでは外部パートナーさんと一緒に進めています。
ですが、品質の根幹というのは結局のところは内製しておかないと。担当者がいなくなってしまうとわからなくなってしまったりしますしね。社員がしっかり見ておけるようにしたい、とは思っています。
小池：プロダクトをグロースしていく過程での運用もそうですし、追加改修も含めて、開発しながらテストするみたいなことができるといいんじゃないのか、という発想で、Micoworks社内での取り組みはすでにされているのでしょうか。
古谷：はい、スクラム開発として1週間で担当するタスクを決めて進める運用をはじめています。開発が始まったときにテストを考えておかないと、テストがネックで終わらないという話になってしまうこともあるので。
小池：結構忙しく働かれてるからこそ、先ほどおっしゃっていたように、2人以上を1個のプロダクトにつけよう、というのもある感じなんでしょうか。
古谷：そうですね。あとは、やっぱり1人だと発想が浮かばないときがあるじゃないですか。ちょっと壁打ちするだけでも浮かんできたり、このパターンもあったみたいな話も出てくるので。QA内でも実は「昼会」という毎日話すための時間があって、必要があればそこで壁打ちをしていますね。
石川：私は1人目のQAエンジニアとして入社したので、最初とても孤独感があったんですが、弊社はPdMとやり取りをすることが多くて。そこでいろいろと話をしていますね。一緒にテストを作ろうとか、こういった観点が必要かな、と相談してあえてレビューに入っていただいたり、モブテストといって、エンジニアの方と一緒にテストを作ったり、QA同士で観点を一緒に考える取り組みを始めています。
小池：その取り組みは誰がやろうと言い出すんですか。
石川：実は、最近ジョインしてくださった方からの提案なんです。その方が1人でQAをしている中で、観点漏れなど反省することがいっぱいあったから、モブテストやってみたいですと言ってくれた感じですね。
小池：いいですね。QAをやる人間はコミュニケーション能力が大事、というのが僕の中でありまして。
古谷：大事ですね。なんだかんだ、ユーザーが使っているときに隣にいてそばで見て聞いているのが大事だと思います。使ってるときに首かしげて「う～ん…」みたいなそぶりを見せていたら、気持ちよく使えてはいないですよね。その言語化しにくい何となくの「違和感」って大事で。そういうのって直接尋ねても出てこないことも多いんです。それを一つのコミュニケーションとして拾いにいくという姿勢は大事ですね。
1人目のQAを採用するときのコツ
小池：はじめてQAのチームをつくるときに、どういう人をまず採用すればいいのか、みたいなところをもう少し伺えたらと思います。皆さんいかがですか。
古谷：よくあるのが、1人目だということで欲張りすぎて「あれもこれもお願いします！」みたいなのはちょっと避けた方がいいと思います。応募する側も「こんなには無理だわ…」ってハードルが上がりますよね。なので、ある程度求める要件を絞ったほうがいいかなと思いますね。
QA=テストじゃない、を啓蒙していくには？
小池：「QAって、いわゆるテストじゃないよ」ということはもっと啓蒙していきたいと思っています。テストだけやっていても、品質を確認はできるけど向上はできないじゃないですか。
誰がどう働きかければ、品質をテストではなくもっと別の領域だと思ってもらえるのか、
そのためにどのような取り組みが考えられるか、何かヒントになるようなことがあったら伺いたいです。
石川：QAというロールにとらわれないことが大事ですね。当たり前のことですが、PdMが知っていることを、「QAだから自分は知らない」で済ませるのではなくて知ろうとすることは大事だと思います。弊社ではPdMとQAでスクラムマスター研修に行きました。そこでスクラムマスターの資格をとったんですよ。結構いいアプローチだったんじゃないかなって思ってます。
古谷：結局経営に食い込むことが必要になってくると思います。会社としてどの程度の品質を作っていきたいのか、もしくは外に見せていきたいのかを把握するということですね。それは開発が始まる前にキャッチアップしておくことが大事だと思います。
ロードマップについても何度か聞きに行くぐらいのつもりでいないと追いつかないですね。テストをこなして100%の仕事だと、改善までやろうにもテストで終わっちゃうんですよ。項目書書いてテストやって、また次のが来て…となると、QAだけで改善しきるのは難しい。改善したいと思ったときにはその余力を残しておくような人材配置も大事ですね。
===========
石川さん、古谷さん、ありがとうございました！
成長中のSaaS企業で実際にどのようにQAの体制を構築されているのか伺うことができ、とても貴重な時間となりました。
Quality ApproachカンパニーではQAエンジニアを募集しています。
この記事を読んで興味を持った方がいましたら、ぜひ下記の募集要項から求人へご応募ください。
