品質担保で重要な「実装しないこと」を決める基準　PMFの拡大に必要な汎用性と資産化

品質保証の本質は新しい価値を継続的に届け続けるということ

近澤良氏（以下、近澤）：ありがとうございます。次は、今後の話です。今後どのようにプロダクトのスケールと品質を担保していくか、どういうQA組織を作りたいか。そこに入っていく人はどういうキャリアになっていくか。まず石川さんいかがでしょうか？　

石川 洋資氏（以下、石川）：すでに作成されているテストケースに関しては、なるべく自動化を取り入れていって、パートナー企業へレポーティングまでを含めて自動化を進めていきたいなと思っています。なので、QAの組織の1機能としては自動化に特化したSETみたいなメンバーを迎えて、そこにフォーカスできるチームを作ろうかなと思っています。

それとは別に、やはり品質保証は自動化だけがすべてではないとも思っています。例えばテストをどのように設計していくかとか、仕様を詰めていく段階で矛盾が生じたりするので、プロダクトを作る段階から一緒に入って、テストの戦略を設計するようなQAマネージャー的なメンバーも今後は迎えていきたいと思っています。

新規開発だとどうしてもアジャイル的に進めていくのが難しい側面があるので、そういう開発プロセスにおいても健全に進められるようにしたいなと考えています。

近澤：ありがとうございます。では次、榎本さんいかがでしょうか？

榎本悠介氏（以下、榎本）：まずは品質保証のプロセスを効率化していきたいと思っています。今はQA表みたいなものがあるのですが、項目が700以上あります。かなりの量を手動でやっているので、そこの半分以上をAutifyさんを使ったり、単体テストやAPIテストの量を増やしたりというかたちで自動化をしていきたいと思っています。

なぜかというと、このままだとリリースサイクルが遅れていくという危機感があります。QAに何日かかるからリリースも2週間に1回は無理だねとなっていくと、お客さんに価値を届けられなくなるので、そこは必ず維持したいなと思っています。なので効率化が必須かなと思っています。

どういう人に入ってもらいたいかいう話ですが、品質って一言で言ってもいろいろな意味が込められていて、僕はバグがないことが品質だとかそんな簡単な話ではないなと思っています。顧客に価値を届け続けることが品質なのかなと思っています。

極端な話、新しいバグやデグレを生みたくなかったら、なにも開発しなければいいわけじゃないですか。それって本質ではなくて。新しい価値を継続的に届け続けるというのが本質で、信頼を得ていくことが本質だと思います。なので、今の提供スピードを保ったまま品質を上げたいと思っています。

そもそもスピード、スケール、品質はトレードオフだとはあまり思っていなくて、品質を上げることこそが開発速度を生む面があると思っています。障害対応にけっこう時間が取られてしまったり、質の低い挙動によって時間取られたり、遅くなったりということも大いにあると思います。

スピードが速ければ、すぐに間違いを修正できたり、1回作ってみたけど「これはダメだわ」とすぐその場でリファクタしてみたり、すぐバグを取ったりができると思います。なので、僕はスピードと品質は必ず両立できると思っています。

なので、入ってもらいたい方はそこのバランスが取れる方ですね。ちょっと一歩引いた目線で、サービスの品質を考えられる方。顧客に価値を届けるってどういうことだっけみたいな議論ができて、「この機能はそもそもいらなくない？」「このほうがシンプルじゃない？」「なんでこうしないの？」みたいな話ができる方ですね。

そのためにはやっぱりドメインをキャッチアップできて、ユーザー目線になれる方がすごく大事かなと思っています。あとは当然QAとして、全体的に仕様把握をしたうえでクリティカルなポイントがなにかを見抜いていただける方がすごくいいなと思っています。

ほかにも、QA統括とSETはそれぞれいたほうが絶対いいなと思っています。SETの方だったら、やっぱり技術面の深い造詣は必要かなと思っています。これは単体テスト、これはE2Eでやるべきという切り分けや、開発プロセスにCI/CDなど品質のプロセスを組み込める方。

チームにおける品質の当たり前のレベルを技術的に上げていただける方がすごくいいなと思っています。すみません、バーっとしゃべっちゃったのですが、以上です。

近澤：ありがとうございます。LayerXさんも10XさんもQAマネージャーとSETの両方を募集中ですか？

石川：そうですね。

近澤：なるほど。では最後、松浦さんから。

松浦隼人氏（以下、松浦）：開発チームの行うプロセスの1つとして、QAがあると思っています。QAのチームがあって、開発チームと別に最後のデプロイ前のゲートキーバー的にQAのプロセスをやってもらうというのはあまり想定にないです。

どちらかというと、開発プロセス全体の視点から品質を上げるにはどうしたらいいか、バグを減らしたり、スピード感のある開発を行うにはどうしたらいいかを考えられる方にぜひ入ってもらいたいと思っています。

QAの方でも、ユニットテストをこういうところに書くことによって品質が上がるよねと提案することもできるし、もちろんend-to-endテスト、あるいは手動テストをエンジニアが自分でできるようにすることで品質を上げることもできると思っています。QA組織内に閉じた考え方になってしまうと、あまりどちらも幸せにならないのかなと思っています。

先ほどLayerXさんがおっしゃっていたとおり、デプロイ頻度を下げて、スピード感を落として品質を上げるということではないと思っています。開発プロセスの中に深く入り込むというのが大事かなと思っています。

あとSETのところでいうと、私たちのプロダクトがテストの自動化のツールでもあるので、テストを自動化するということは、ある意味お客さまのワークフローを知ることでもあり、ドッグフーディングをすることでもあります。なので、直近でいわゆるテストの自動化を行うSETの方は募集はしていません。

どちらかというと、エンジニア自身でテストできる道筋を整えてくれるQAにジョインしてもらえるとすごくいいのかなと思っているところです。

近澤：ありがとうございます。各社共通しているのは、テストする人を募集しているのではなくて、品質を上げるために全体的にプロセスをどうしていくかとか、開発プロセスにどう手を加えていくかとか、それこそ榎本さんがさっきおっしゃっていたような仕様に手を入れるみたいな（笑）。ここはやらなくていいんじゃないかというところまで。全体的に品質を上げるためにどうすればいいかを考える人に来てほしいというところが各社共通していますね。

品質の水準はプロダクトのステージごとに変わっていく

というところで、Q&Aに移っていきたいと思います。矢本さんと福島さんにまだお話をいただいていないので、QAのセッションでどんどん振っていきたいと思います。

さっそくCEOの方々に質問です。「PMF（プロダクトマーケットフィット）と品質強化の順番や優先度はどのように考えてきましたか。エンジニア、プロダクトマネージャー出身者が考え方に影響しているのか、事業の性質が影響しているのかもおうかがいしたいです」という質問ですが、矢本さん、いかがですか？

矢本真丈氏（以下、矢本）：むずくない？（笑）。

近澤：バランスが一番悩むところですよね。

矢本：CEOという意味でいうと、事業がうまくいくかどうかという不確実性が会社の船にとって一番大きな不確実性だと思います。その不確実性をどうやって潰すかに僕らはたぶん血眼になっていると思うんですよね。

その意味合いで、例えば品質がないとパートナーである大企業に導入してもらえないというリスクがあるし、例えば3タップくらいしたらクラッシュするとか、エンドユーザーが満足しない品質を平気なものとして出していたら当然私たちの収益も上がらないし、市場にもぜんぜんエントリーできません。

PMFみたいな、マーケットにエントリーして受け入れられるための品質の定義はこの水準が必要だよねというのが、都度言語化していないにしろ絶対あるはずなんですよね。そういう意味では常に優先順位があるというわけではなくて、そのフェーズや置かれているコンディションにおいて僕らは線を引いていると思うんです。

それに合わせてどの程度の機能を盛り込むかとか、あるいは非機能的な品質と言われるものとか、パフォーマンスとかスケーラビリティとか、どのくらいのRPSに耐えられるんだっけとか、そういうのを統合的にマネージしていると思うんですよね。

その背景にはエンジニアかプロダクトマネージャーかというよりも、なにもないところにマーケットを作ろうという創業者的な性質のほうが影響度は大きいかなと僕は思いました。

近澤：メチャクチャすばらしい回答ですね。どっちかという話ではないですよね。PMFをするためにも必要な品質があって、品質のバーはステージごとにいろいろと変わっていくし、事業ドメインやプロダクトによってもぜんぜん線の引き方は違うよねという話ですよね。

矢本：そう。そういうことが言いたかった。

近澤：ありがとうございます。福島さんはどうですか？

福島良典氏（以下、福島）：けっこう似た答えになりますが、究極どっちを優先する？　というと、僕はPMFを優先しました。榎本（榎本悠介氏）と最初どういう感じでプロダクトを進めていこうかとなった時に、開発のスピードが手数を生んで顧客の価値を生むから、それを許容してくれる顧客だけに売ろうと決めたんですよね。

最初の10社くらいはミスるかもしれない。ただ、例えばtoCのサービスを使っていて、アプリのバグが多くてもめっちゃ便利だから使うサービスがたまにあるじゃないですか。だからそれくらいのものを目指して、最初の10社はなにかやらかすだろう。やらかす前提で、それでもその障害を越えてメチャクチャニーズを見つけて、便利に使ってもらえるように、そこはもうスピードを優先しようという話をしましたね。ただ最低限の品質は絶対存在すると思います（笑）。

そういう意味においては両方重要で、今はどう考えているかというと、けっこうフェーズが変わってきていて、かなり会社数も増えてきていて、既存顧客の品質がすごく大事になってきています。

なので、こういうイベントをやらせてもらったり、Autifyさんの導入も決めたり、スピードと品質をどう両立させよう真剣に悩み始めている段階です。

近澤：ありがとうございます。確かにスピードに全振りするというのは初期のスタートアップにとってはすごく大事な意思決定ですよね。壊れてもとは言わないけど（笑）、許容できる顧客のみを対象にするみたいな。

そこまでしっかりと意思決定できるのも、なかなかないと思うのですが、そこまで振り切れると最初スピードにフォーカスできるから、PMFを乗り越えるところに全社員が全集中できそうですね。

福島：売上追うのはやめようとか、そういうことはけっこう決めていましたね。売上を追うと社数を増やさないとダメじゃないですか。10社でジェネラルな課題を解決できるように磨き込むんだ、そのためにスピードを集結させようと思いました。

近澤：さすがフォーカス加減がすばらしいですね。

福島：今は逆に品質がめっちゃ大事です。

近澤：確かにフェーズによって変わっていくのは、やっぱり共通してありますよね。必ず一般解があるわけではなくて、僕らもLayerXさんにけっこう近いのかなと思っています。僕らもテストの会社ですが、最初はスタートアップを中心に導入を広げていって、スピードでどんどん開発していきました。

社数がすごく多くなってきて、品質がどうあるべきかを見直す時期に来ているというところは、私たちにも共通しているところかなとお話を聞いていて思いました。

実装するか・しないかの決定は汎用性と資産化がポイント

次の質問にいきましょうか。SaaSとしての品質の担保として「実装しないこと」を決めることが重要だと考えています。ユーザーニーズの中で「実装すること」と「実装しないこと」を決める際の基準など、言語化されていればうかがいたいです。これもまず矢本さんにお聞きしたいですね。

矢本：おい～（笑）。

近澤：プロダクトマネジメントとして。

矢本：SaaSというカテゴリに私たちが属するのかがちょっと怪しい部分はあるのですが、例えばAutifyとかLayerX インボイスとか、SmartHRとかfreeeとかもそうなんですが、最終は抽象化や資産化できるかというのが1個キーなのかなという気はしています。

要はA社という場所にニーズがあって、その後ろに何万社が続いているのかどうかをけっこうセンシティブに見極めるのが、実装する、しないのまず大きい判断かなと思いますね。

例えばA社個社に解答するために、それを個別の実装として実装してしまうとまず1個負債ができます。その後の開発速度をトレードオフして犠牲にしているというのが1個と、あとは単純に市場性が低いという、2個問題があると思っています。

私たちがスケールしていくうえでは、そこの判断の軸で抽象度が高いかどうかはすごく気にするんじゃないかなと思いました。

近澤：特に10Xさんの場合だと、やっぱりパートナー企業が大きいのと、1つの案件が大きいところがあって、カスタマイズの要求に対してはけっこうそこと戦うんじゃないかなと想像していました。

さっき石川さんからお話聞いた時に、基本的には共通パッケージでやっているとおっしゃっていた部分が印象的だったのですが、共通化するために突っぱねることはけっこう多いということですか？

矢本：突っぱねるというよりは……各社大きくてぜんぜん違うけど、やろうとしているネットスーパーや小売りのDXみたいなアジェンダ自体は同じなので、どちらかというと私たちが最適解を作ってそこに寄せていったり、その最適化自体をよりカリカリにチューニングしていく方針に反映するというかたちでやっていますね。

近澤：熱いですね。

矢本：そこはけっこうセンスがいるというか。例えばA社、B社、D社いて、その先にいるお客さまの動体をよく知っている必要があります。あと、僕らの開発のアーキテクチャがどうだというところを統合的に見て判断しなければいけません。その点でいうと、僕もプロダクトについては石川にデリゲーションしている状態ですが、そのレイヤーの方針はけっこう密に話して決めていますね。

近澤：なるほど。さっきおっしゃっていたカスタマイズしていくと負債として残るという点は、品質の話でいうとすごく重要な議論なんじゃないかなと思っています。そこを逆に「これが正解だ」というスタンダードを作っていくのはめっちゃ熱いですね。

矢本：SaaSってやっぱりそういうものじゃないですか。なんか俺たちが考えた正解に……

近澤：こっちに合わせてくれみたいな（笑）。そういう感じですよね。ありがとうございます。LayerXさんはどうですか。

榎本：現場でけっこうやっているのは僕なので僕が答えます。まず、「クソ、ヤモッティ（矢本氏のこと）いいこと言いやがって」みたいな感じですが（笑）。

（一同笑）

どれだけ汎用的か、資産になるかはメチャクチャ意識していますね。その会社さんだけの業務フローでしかないよねみたいな。こういうワークフローあるよみたいなところはやっぱり実装しないと決定しています。

今は「Airtable」というスプレッドシートみたいなツールで、各要望が何社からあがったのかを全部まとめている最中です。それで要望数が多いものだとか、あとは顧客の温度感ですね。熱があるところを優先度を上げてセールスの責任者、CS、僕、エンジニアでワイワイ決めています。

意識しているのはとにかく顧客の声を聞く、かつ、外の世界に出る。IT村と僕らは呼んでいるのですが、LayerX インボイス、ワークフローを導入されているお客さんはIT系のお客さんがどうしても多いです。

SaaSに馴染みがあったり、僕らのリファラルネットワークをふんだんに使うとやっぱりそういう方々にアクセスがしやすいというのもあって、IT系の方々にすごくリーチしているのですが、そうではない地方の地場の産業の方に使ってもらうにはどういうのがいいのかみたいな。領域を広げるためにどういう機能がいるのかというところはすごく意識しています。

例えばよく「APIを実装してほしいです！」と言われるんですよ。LayerX インボイス、ワークフローのAPIを提供してくださいと言われるんですが、一歩引いて考えて、「これ、IT村だから言ってるんじゃない？」みたいな話はよくしています（笑）。地方の地場の方がAPI使うか？　みたいなところとか。

今の領域に囚われずに、PMFを広げるためにはどういう機能がいるのか、一歩引いて今リーチできていない顧客の方の声を真剣に聞いて考える、飛びつかないみたいなところは最近意識しています。

近澤：ありがとうございます。最終的にどこまでスケールするかを考えて、やること、やらないことを決めていくという感じですね。

福島：僕がプロダクトの仕様に関わることはもうほぼないのですが、客観的に参加することはあります。このチームがすごいなと思うところは、要望を要望のまま作らないというところ。

要は要望は個別で見るとカスタムが必要なのですが、一歩引いて抽象化すると1個の機能で10の顧客の課題が解決できたり、1,000の顧客の課題が解決できるみたいな。そこがSaaSの、いわゆるPMや開発チームに求められる能力かなと思うんです。そこをすごく意識してやれているなと思います。

あと、QAというプロセスをうまく仕様理解に使っているなと思いますね。経理の業務はエンジニアはやったことがないので想像がつかないと思いますが、QAをうまく利用しながら、そこでしっかり仕様を理解して顧客のニーズを理解して、汎用化した仕様に絞っていくことで品質が上がるという、いいサイクルが回っているなと思います。

僕は第三者視点でチームを見ているので（笑）。そういうポリシーがチームとしてあって、それがすごくいいなと思っています。

実装機能の選定条件はCS、PM、営業の三者間でコンセンサスが取れていること

近澤：すばらしい。ありがとうございます。次の質問は弊社の松浦さんにお聞きしようかな。

「実装する機能の選定フローについておうかがいしたいです。具体的にはユーザーインタビューをどのくらいのペースで誰が行い、どういうメンバーで、どういう選定方法で意思決定を行いタスク化していくのかをうかがいたいです」これは松浦さんに答えてもらおうと思います。

松浦：実装する機能の選定フローですが、先ほどちょっとお伝えしましたが、当社の場合はプロダクトマネージャーがプライオリティ付けをしてどんどん機能を実装していくかたちです。

その機能の選定のフローをどうするかというと、カスタマーサクセスと営業がお客さまの声を一番拾ってくるメンバーなので、そことプロダクトマネージャーの三者間で協業して、タスクのプライオリティ付けと実装する機能の選定を行なっています。

今少し問題だと思っているのは、プロダクトマネージャーがユーザーインタビューにあまり直接的に関われていないということです。プロダクトマネージャーがユーザーインタビューを行うのが理想だと思っているので、私が業務を巻き取って、その方向に持っていくつもりです。

基本的に、社内的にはその三者間でコンセンサスが取れているのが一番大事だと思っているので、そういったフローでタスク化をしています。

開発プロセスに深く入り込んで議論できるQAエンジニアを募集中

近澤：ありがとうございます。最後に、「創業から現在の間でいつ頃QAエンジニアを雇うべきだったと思いますか」という質問を取りたいと思います。

今採用していますが、もっと早いほうがよかったかとか。スタートアップはどのタイミングでQAを雇うべきかという話を最後にピックアップしたいと思います。まずは石川さんいかがでしょうか？

石川：すごく難しい質問だと思います。10Xは、2020年5月くらいに「Stailer」という事業を始めました。そこから1年ちょっと経って、今まさにえらいニーズに出会って大変なことになっています。今QAのメンバーがいないという状況なので、この状況を考えると、明らかにQAのメンバーを迎えるタイミングが遅れているというのが、正直なところではありますね。

事後だから言えることではあるのですが、振り返ってみると、Stailerという事業を始める時点で、ある程度事業の方向性や確実性は上がってきていた段階だと思っています。なので、この事業を始める時にQAのエンジニアを迎え入れるべきだったなと今は思いますね。

会社自体はそのさらに前に、3年くらい「タベリー」というプロダクトをやっていました。その段階においては、まだ事業的にもどうなるかわからなかったので、その時にはまだ迎える必要はなかったのかもしれないなと考えています。

事業の方向とか、事業の価値がある程度見えてきた段階で本当は本腰を入れてチームに迎えるべきだったなと思っています。

近澤：ありがとうございます。

矢本：2個目の契約が見えた段階で、もう採用を始めるべきだったなという感じがします。再現性が取れるなみたいな。

近澤：再現性が見えたらという感じなんですかね。

矢本：そうですね。

近澤：なるほど。そのへん、スピードを最優先で考えられていたLayerXさんはどうですか？

榎本：メチャクチャいい話ですね。PMFが見えたら、つまり保つべき品質、保つべき機能は何だっけみたいな。この価値を届け続けないとダメだよねみたいなのが見えた瞬間に、それを専門で考える人が絶対いると思っています。僕らは4月くらいからかな、採用を出しているのですがなかなか採れていないんですよね（笑）。

近澤：難しいですよね（笑）。QAの採用。

榎本：雇うべきだったと思っているけど、できてねぇみたいなのが現状です（笑）。今日は一緒に働きたい人たちが集まっていると思いますので、何卒ご検討をお願いします。

近澤：ぜひ！　ありがとうございます。では松浦さんどうでしょう？

松浦：けっこう難しい質問だと思います。すごくあいまいな、私の感じ方ではあるのですが、私たちの場合、オフィシャルリリースしてから1年くらいの間は、テストを安定的にAutify上で回すためにいろいろ手を加えていた時期だったんですね。

そのあとは一旦落ち着いて、新しい機能を追加していってたくさんのお客さんを取るというフェーズに変わったタイミングがどこかにあった気がしています。今思うと、まさにそれがQAエンジニアを取る時だった。つまり新しい機能を出して、しかもその品質は保たないといけないというタイミングだったなと今は思います。

そう思いつつも、やっぱり必要に迫られてからのほうが、どういうQAエンジニアに来てほしいかという解像度も高いし、そういう意味ではやっぱり今来てほしい。採用しているということは、やっぱり今が雇うタイミングなんだとすごく思いますね。

そうでなかったら、さっき言った開発プロセスに深く入り込んでもらうQAエンジニアに来てもらいたいというのも、もしかすると違った考え方になっていたのかなと思うので。そういう意味で、今来ていただきたいという感じです。

近澤：半年前の自分たちに要件を伝えてあげたいですね。「こういう人たちがほしいです」みたいな（笑）。ありがとうございます。たくさんご質問をいただきましたが、時間がここまでなので、今日はちょっとこちらで締めさせていただきます。みなさま、ありがとうございました。