.png)
アメリカのRipplingをはじめ、QA（Quality Assurance、品質保証）が果たす役割が認識されはじめています。SaaSプロダクトは継続的に使うことが前提となるだけに、根幹をゆるがすような許されないバグだけでなく、使い心地に関わる部分まで、QAが担う「品質」をいかに定義し、チームを運営していくのかが大切です。
まだ日本では取組内容に関してオープンになっている事例が少ないQAではありますが、自社プロダクト開発におけるQAについて意志を持って取り組んでいる企業も存在します。その一つが、「バクラク請求書」「バクラク申請」「バクラク経費精算」「バクラク電子帳簿保存」「バクラクビジネスカード」といったBtoB SaaSを提供するLayerXです。プロダクトとしては後発なものもありながら、その開発スタイルは業界でも一目置かれる同社。
LayerXの初代CTOを務め、現在はQAチームも含めた開発全体を率いる取締役の榎本悠介さんに、QAチームの立ち上げから運用の工夫まで、さまざま伺いました。
QAが担うべきは、「当たり前品質」と「魅力的品質」
──ベーシックな質問から伺うと「QAの重要性」を、どのように考えていますか？
榎本：前提として、僕らバクラク事業部は「圧倒的に使いやすいプロダクトを届け、わくわくする働き方を。」というビジョンを掲げています。LayerXにはtoC事業で開発を経験してきたメンバーが多いこともあり、「ユーザーにとって本当に使いやすいものを作って、生産性を高めていきたい。データや技術的な要素も含めて、良いプロダクトを届けたい」という意識がすごく強いんですね。
その中でQAチームが担う、「品質保証」はプロダクトの根幹を成すものです。toB向けプロダクトは経理、稟議、決済といった領域を担っていることが多く、使いにくかったり、正しい挙動でなかったりすると信頼されません。加えて、企業活動の生産性を本当に高められているのかについても強い課題意識を持っていなければいけない。
顧客からの安心感や信頼感のためにもQAは重要なんです。
──QAを組織に取り入れることによって、どういった変化や結果を期待しましたか？
榎本：事業において「一発アウト」の事案は存在すると思うんです。QAでいえばセキュリティ観点が例に挙がりますが、情報流出をはじめ、SaaS特有の問題としては他企業の会計情報が見えてしまうといったこと。それらを防ぐファンクションは必ず持つべきところでしょう。
また、組織における“品質への意識”を高めるのも、QAチームの役割としては重要です。特にベンチャーの立ち上げ時期は「攻めの意識」に向きがち。いかにスピードを高めて、いかに早く価値提供していくか。いわゆる「イケイケドンドン」な空気の中で、QAは「守りの視点」をもたらすファンクションとして機能します。
──「使いやすいものを作る」という意味では、UXの部分もQAが担うところなのですか？
榎本：本当に良い質問と言いますか、LayerX社内でも議論している最中のテーマですね。
というのも、「品質」にはいくつかの分類があると思っています。先ほど挙げたセキュリティといった「当たり前品質」に加えて、無くても使えるけれど、あればなお良いといった「魅力的品質」もある。僕らとして、QAは魅力的品質まで担うべきだと考えています。
UXデザインやPdM的な要素は、QAだけではなく組織のポジションをオーバーラップして作られていくものだと思うんですけれども、僕は最も仕様に詳しい人がQAであるべきだ、と捉えています。プロダクトの正しい動き、あるべき動きを最も理解したうえで、ユーザー行動への理解も取り入れることで出せる意見が必ずある。だからこそ、QAを魅力的品質も担えるような組織にしていきたいと思っています。
「PMF後にバグが出はじめた頃」が、QA導入の目安
──バクラク事業部として、最初からQAを織り込み済みで開発チームを立ち上げたのか、あるいは何かしらのきっかけがあったのでしょうか？
榎本：経緯を話すと、リリース前はもうぐっちゃぐちゃでした（笑）。少人数の組織で立ち上げる以前に、そもそも事業がどれだけうまくいくかもわからない状況で、QA担当者を明確に決めていたわけではありません。どちらかと言うとDE（Domain Expert）がQAも兼任するような格好でした。
開発初期に、スクラム開発で「何を最も大事にするか」「やること／やらないこと」を開発チームでリストアップしていきました。インセプションデッキの作成ですね。「やること」の中に「とにかくスピードが大事」と書きました。事業としてスピードがないと話にならない、そもそも僕らはSaaSとして周回遅れしている認識もあったので、大事にしようと。
バクラク請求書の前身にあたる「LayerXインボイス」を立ち上げたタイミングは競合が何社もいましたし、「バクラク申請」「バクラク経費精算」も後発です。経営層の中でも「本気で作るの？」といった議論があるレベルでしたから。まさに周回遅れだったわけです。
それだけに、「やらないこと」の一つに、「ちゃんとしすぎることをしない」と決めたんですね。例えば、過剰なドキュメンテーションをしない、完全なバグフィックスなど品質を追い求めすぎてスピードを損ねない、といったことです。QA以前に、まずはできる範囲で品質の担保をはじめたのが正直なところです。
2021年1月にバクラク請求書をリリースした後、3月頃に3件ほど軽微なもの含めてバグが出た辺りから、チーム内にも「品質へ真面目に向き合うべきでは？」といったムードが生まれてきました。そこで、QA専任者を立てたり、外部企業にQAを担ってもらったりすることの議論を、一気に本腰入れてやりはじめました。これがQAチームのはじまりです。
──QAをはじめるタイミングを振り返ると、適切だったと思いますか？あるいは、もう少し早めに着手すべきだったのか。
榎本：開発スピードの観点でも、今思い返してもタイミングは良かったと思います。「バクラクは開発が速い」と言われることが多いのですけれども、品質とうまくバランスが取れているからでしょう。QAは「品質を守るべきプロダクト、だから必要になってくる」と思うんです。極端な話、誰も使ってないプロダクトの品質を高めたり、稼げないプロダクトに投資をしたりしても、意味が無いですからね。
僕らとしてもPMFの手応えを感じはじめた頃で、なおかつ品質に対する振り返りが必要なタイミングでした。プロダクトも増やしていく想定もありましたから、このままだとスケールを妨げる可能性も出てきた。他のスタートアップにとっても「PMF後にバグが出はじめたタイミング」はQAチームを立ち上げる目安の一つになると思います。
「1人目QA」の立ち位置を考える
──現在のLayerXの開発体制を教えていただけますか。その中でQAはどういった位置づけなのでしょうか。
榎本：開発組織は、まずはプロダクトカットでチームが存在します。有名な「2枚のピザルール」ではないですが、エンジニアは多くて4人ですね。バクラク請求書、バクラク申請、バクラク電子帳簿保存、バクラクビジネスカードというプロダクトカットのチームがあって、そこにファンクションとしてML（マシンラーニング）、OCR、QA、デザイン、DevOps、イネーブリングといったチームが入ってきます。
QAは横串のチームとして、各プロダクトにディープに入り込み、スクラムのプロセスにも実際に参加して品質を高めているという状況です。
──なるほど。QAチームの中で、プロダクトごとに担当者を割り振っているのですか？
榎本：基本的にはプロダクトごとの担当制です。ただ、コンパウンドなスタートアップとして、プロダクト連携もどんどん増えていて、ノウハウの共有という意味でも、担当という概念にとらわれすぎないように保っていますね。
──開発プロセスに、どういった形でQAは関わるのでしょう。プロダクトチームとの連携についても教えてください。
榎本：スプリントの計画に入り込んで仕様を理解していく、振り返りに参加していく、といったようにチームの一員として動きますが、機能追加時に影響する範囲などはスプレッドシートで管理しながら細かく擦り合わせしていますね。あとは、バグが起きた時にQAチームがSlackに書いたものが自動的にNotionへ入るといった仕組みも使いつつ、自然と開発チームとQAチームがコラボレーションできるようにしています。
──CSチームなど、他のファンクションにも関わりますか？
榎本：CSチームは多いですね。お客さまの問い合わせから正しく仕様を理解している身としても、PMに負荷が集中しないためにも、QAチームが入って解決していく役割は果たしていますね。本当はBiz組織のイネーブルメントにも入っていける余地はもっとあるとは感じています。
──経験からわかる、QAチーム立ち上げ時のポイント、あるいは「よくある落とし穴」はありますか？
榎本：「1人目QA」の立ち位置でしょうね。「品質保証」を目的化しないことが大事で、あくまで事業を成り立たせて良いプロダクトを作るために必要である、という意識で取り組むべきです。
実際に僕が見た経験から言っても、品質にこだわりすぎて事業を見失うパターンが最も良くない。「ここのボタンを連打されると挙動が怪しい」といった点があったとして、「そもそも誰がそのボタンを連打しようと思うのか。しかも結果として起こる事象も大したことはない」みたいな話もあるものです。「そんなところのバグを気にして、誰が幸せになるの？」といった観点は忘れないでいたいし、バグの無さを目的化しないことが肝心です。
それから、プロダクトの初期は不確実性が高いものですが、楽しんで対応できる人であってほしいですね。事業がうまくいくかわからず、ピボットする可能性もあり、仕様も変更するかもしれない。そんな変化においても「事業を進めるためのものだ」と柔軟に対応できる。なおかつ、エンジニアリソースも絶対に枯渇しているでしょうから、その環境でも「コスパが良い品質担保のアプローチは何か」に頭を使える人が理想かな、と思っています。
──「1人目QA」のアサインに、経歴のバックグラウンドは必要ですか？
榎本：僕もいろんなパターンを考えたくて、まだ解を持っているとは言えませんが、実はウェブディレクター職などの「事業推進の仕方」がわかっている人のほうが向いているかもしれません。後のフェーズになって、QA専門家がマネージャーとして入れ替わっていくスタイルも良いでしょう。
僕らも外部QAの方を交えながら手探りで整備して、徐々にあるべき姿に近づいていったところがあります。初めから完璧を目指すよりも、プロダクトの性質に合った現実的な回し方を模索し続けられる方が、「1人目QA」としても適任なのかなと。
QAを任せるべきは「最も仕様に詳しい人」
──「バグの無さを目的化しない」に関連して、QAチームと開発チームの間で合意しておくべきことはありますか。あとは、QAチームが持つべき判断基準へのアドバイスがあれば、ぜひ教えてください。
榎本：やはり「ファクトを元に判断する」ということでしょうか。
まずは絶対に使われる機能を重視すること。ユーザーストーリーでも必ず通る道で、これが損なわれたらプロダクトとして成り立たないような項目です。逆に言うと、あくまで便利機能で、実はそれほど使われておらず、実際にバグが出ていても後回しで構わない、といった共通認識が持てると、QAチームと開発チームの連携としては良い状態と言えるはずです。
LayerXのQAチームは特徴として、お客さまサポートに類することも担っています。「最も仕様に詳しい人」として、カスタマーサクセスやカスタマーサポートからの問い合わせに対しても、ディープダイブして回答する、あるいは回答の補佐をするといった役割も務めています。仕様を最も理解しているからこそできるアクションは結構あります。
仕様書をちゃんと整えることで、セールスやカスタマーサクセスのイネーブルメントに繋がってくるところもあると思います。その点では、プロダクトチームのみならず、QAチームが果たせる役割は、組織の中でも大きいのだと思っています。
──榎本さんのポジションから、QAチームとの連携で意識されていることはありますか？
榎本：僕は、新規事業を立ち上げていく切込隊長のような役割なので、品質とフェーズのバランスを議論することがあります。「今は立ち上げの段階。まずはお客さまに動くものを届けて、フィードバックを得るフェーズだから、綿密な計画を立てるタイプのプロダクトではないよね」といったことを話します。
バクラクシリーズはプロダクトによってフェーズが異なりますし、市場も拡大していく中で、品質に対する重視性もどんどん上がっていっています。ただし、リリース間もないプロダクトなら優先すべきはPMFですし、求める品質レベルも業務領域によって違ってくる。それらをどういった濃淡を描いてQAチームと進めていくかを意識して話すことが多いですね。「ここはプロダクトの根幹に関わる部分は絶対に担保しなければならない」といったように。QAチームとして「何を優先するべきか」をはっきりさせていくイメージです。
自動化できる部分を突き詰めていく
──「スケールとスピード」について深掘りしていきたいのですが、プロダクトのラインナップや開発メンバーが拡充していく中で、プロダクトの質を高く保つ秘訣や、スピード感を維持する工夫があれば教えてください。
榎本：そもそも使われないものを作らないことが大事だと思います。機能を増やした時点で、どれほどきれいに作ったとしても、必ず品質に影響がある。究極的に言えば、障害やバグを起こさない一番の方法は何も作らないことです。「ちゃんと使われるものを、いかにシンプルに作るか」が品質の大前提ですね。
そのためにプロダクトチームとしては、ユーザーヒアリングをしてペインを明らかにする、エンジニアも含めてドメイン知識をみんなが持つといった文化を当たり前に持つこと、その中で正しい動き方を自然とみんなが考えられる土壌があることを大事にしています。仕様をシンプルに保ち、複雑なものに対する嗅覚を持ち、はじめから品質が高く保たれるようにする。そういった組織作りが、秘訣の一つ目かなと思っています。
本来的にはQAが上流から関われればいいのですが、僕らもまだそこには至っていません。現状は、プロダクトマネージャーが上段の仕様を決め、開発チームも自立的にそこにコミットしていって、その中にQAチームも入っていくという体制になっています。
──その他にも秘訣、ありますか？
榎本：僕らは「自動化」もテーマにしています。結構な速度でバクラクシリーズはプロダクト数と機能が増えているので、人力で品質を担保するのは限界があり、投資対効果も悪いですし、僕らの行動指針にも沿っていないなと。
LayerXの行動指針の一つに「Bet Technology」があります。「技術にBetすることは、より良い未来にBetすることだと私たちは考える。判断に迷ったときは、⻑期的には技術が勝つと信じ、技術に賭ける選択をしよう。」という考えで、やはり人力に頼りすぎるのは、この行動指針にも沿っていないと思います。
いかに自動化し、属人的にしないかを考えるうえで、QAは「正しい仕様を理解する」というハードルの高いことに取り組みますが、どうしても属人的になりがち。テスト仕様書みたいなところに文書化して落とし込むのも大変なので、それがそもそもシステム化されていて、正しく期待される挙動を文書化しなくても自動で回る状態を作れることが大切です。
リリースのたびに、そのシステムが当たり前に回って、すぐフィードバックが得られるようにする。開発プロセスの中にも自然と自動化が組み込まれるようなことが、品質を高く保てる秘訣になってくるでしょう。
──自動化を進めるうえで、気をつけた方がいいポイントは？おそらく部分的にスタートしていくと思うのですが、その際の注意点や考えるべきことはありますか。
榎本：自動化の優先順位でいえば、みんなが使う機能とか、サービスの根幹にかかわる機能でしょう。手動で毎回実施しているような項目から手をつける。
あとは、そもそも自動化への向き不向きもあります。実行するたびに期待する結果がシステムで定義しづらかったり、E2EテストにはAutifyを使っていますがカバーできない範囲もあったり。とっつきやすくシンプルで、QAの心理的に負担になっているところで、なおかつ自動化と相性がいい。そういった部分は確実に存在します。
例を出すと、バクラク申請とバクラク経費精算は、自動化のモデルケースとして最適です。稟議は複雑な承認フローをたどるものです。並列化できる承認ステップの洗い出し、申請者の上下関係など複雑なパターンがたくさんあるため、本来は人手でやると心理的にも手間がある。その何十パターンもある部分を自動化できると、費用対効果が高いんですね。
──なるほど。ちなみに自動化はQAチームの中で完結して進めていくものなのか、他のチームと連携して進めていくものなのか、どんな進め方ですか？
榎本：品質の自動化で言うと、Autifyなどツールを用いた自動化と、エンジニアが実装する単体テストによる自動化、両面からのアプローチがあります。理想は両輪で進めることですね。全体を最適化した品質の在り方は、僕らもまだ模索しているところではあります。
観点の一つは、スタートアップにおいて絶対に意識すべき、コスパでしょう。単体テストの自動化がピラミッドの根底にあって、僕らも最初は手動でしかやっていなかったところから、統合テスト、UIテスト、E2Eテストといったように登っていきました。ピラミッドとしては単体テストが最も多い割合を占めるべきではありますが、果たしてエンジニアリソースがなく、事業の先行きがわからないスタートアップで実現可能かというと、難しいはずです。
どこまで自動化にベットするかは、フェーズによって異なると思います。結果的に、今、僕らは単体テストに投資する判断をしているのですが、当初は単体テストより機能開発にエンジニアリソースを振っていました。エンジニアの手を借りずに自動化を進められる、学習コストが高すぎないという観点で技術選定をして、Autifyにたどり着いてもいます。
単体テストとE2Eテストには、メリット／デメリットがそれぞれあります。単体テストはフィードバックサイクルが小さく、間違いに気づきやすい。E2Eテストはカバレッジは広くできるけれども、不具合の発生箇所が特定しづらい、といったように。LayerXは、E2Eテストでカバレッジを広く実施して、そこからきちんと単体テストとしてピラミッドにしていくプロセスをとりました。
常にフェーズによって「コスパが良い品質保証とは何か」を、スタートアップは考えるべきだと思っています。事業上でクリティカルに響くところからはじめていく。バクラク請求書で言うと、会計上の仕訳や支払い、振り込みに関する部分で品質が低いことはあってはならないので単体テストを実施しますが、それ以外のクリティカルでない機能はE2Eテストでカバーし得ると考えました。それによってユーザーへの影響を最小化できると踏んでいます。
「バグ数3件以内」といった目標は定めるべきではない
──QAチームの目標はどのように設定していますか？
榎本：LayerXはOKRで目指すところを定義していますが、QAチームは「自動化」をテーマの一つにしており、「プロダクトのQA項目の何割が自動化されているのか」をトラッキングしています。今だとプロダクトによって違いますね。バクラク経費精算も9割が自動化されているので、他の会社の方に話すとよく驚かれます。
むしろ、バグ数をトラッキングするようなことは目標に設定していません。判断が歪む気もしていて。「バグ数3件以内」みたいにすると、「これはバグではないと定義しよう」といった話になったり、極端に開発チームが委縮してしまうのも本末転倒だと思うので。
──今後、QAチームが目指したい姿は？
榎本：「当たり前品質」はかなり実現できていて、ここ1年で自動化の整備も進んでいると感じています。ここからは「その先」ですね。まず、魅力的品質がテーマになってくるでしょう。上流工程の他に、プロダクトマネジメントやUXデザインといったプロセスに入り込むのか、僕らもまだ模索中です。品質という定義を広げて、「バクラクのプロダクトって本当にいいよね」と思われるために、QAチームとしてできることは意識していきたいです。
QAチームには「顧客への価値提供を最大化できるようにしよう」とは、よく言っています。それは幅広いプロセスも含めた価値提供だと捉えていて、顧客の問い合わせにすぐ良いレスポンスを返したか、営業活動において正しくプロダクトを案内できたか、良いトライアルを体験してもらえたか、お客さまがプロダクトを理解したうえで満足できたか……といった範囲も入ると思っています。
役割を限定しすぎず、最もプロダクトの仕様に詳しい人たちだからこそできる役割を、もっと広げていきたいですね。
QAはチャレンジングな領域、キャリアとしてもこれから
──LayerXのQAチームの体制など、取り組みの素晴らしさも含め、今日は学びあるお話をありがとうございます。榎本さん自身がQAチームに期待していることなど、補足的にあれば、ぜひ聞かせてください。
榎本：ありがとうございます。僕らは複数プロダクトで業務フローを一貫して良くするところを思想として掲げています。まさにコンパウンドなスタートアップとしてデータを基軸に、プロダクトが担う一連のプロセスをシームレスでラクな体験にしていくことを志向しています。各プロダクトが横断する一貫した体験を提供しながら、バクラクシリーズが領域をまたぐからこそ自動化しづらい部分の品質を高めていくことが、僕らにとってはチャレンジなんです。
QAチームがプロダクトに入っているだけだとサイロ化してしまう課題に対してもアプローチしていきたいですし、あるべき姿をさらに求めてもいける、というのは僕自身も楽しみです。
現状では、外部からの評価として、ここまで自動化やアジャイルのプロセスが進んでいる会社もそうそうないと言われています。QAを現在務めている方のキャリアとしても、選択肢の一つに挙がるようになりたいですね。
──アメリカでもRipplingに代表されるように、QAはまだまだ事例が少ないです。その意味でもチャレンジングですが、差別化要因にもなる印象はありますね。
榎本：そうですよね。細かい話にはなるんですけど、ボタンを押したときの挙動がプロダクトによって異なるといった一貫性の無さは、どうしてもユーザーにストレスを与えていくところだと思っています。そういった基本の徹底を組織として仕組み化していくところは、品質面でもUXデザインの面でも、組織やプロダクトが拡大する中で陥りがちですし、乗り越えていきたいと考えています。
LayerXにはCTO経験者がメンバーにも複数人いるのも背景にありますが、人が育つ組織にしていきたいんです。バクラクシリーズの開発を通して、より良い人材になっていきつつ、お客さまに価値提供していく取り組みは、ここ2年ほどでしっかり形にしていきたいです。
──LayerXはシニア人材しか適応できないのではなく、チャレンジングな環境であると。
榎本：育成面はまさに整備中です。インターンを経験して、新卒入社した社員が何名もいますからね。シニアなメンバーの中で揉まれて、各々の馬力で立ち上がってくれているとは感じますが、もっと体系化して研修制度やインターンプログラムも作っていけたらと考えています。スタートアップではありますが、新卒採用にしっかり取り組んでいきます。
