プロダクトのスケールと品質をどう両立すべきか　10X 、LayerX 、AutifyのCTOに訊く品質保証の本質

10X、LayerX、Autifyにおける現状の開発体制とプロセス

近澤良氏（以下、近澤）：ここからは、今回の題目にあるように、品質とスケールをどう両立させていくかというところを中心に、パネルディスカッションの質問を進めていきたいと思います。

今回、CEOとCTOの両方が参加しているのですが、パネルディスカッションのパネラーとしては、CTOを中心にお話を進めていく予定です。開発にすごく関係しているところはCTOで、もうちょっとレイヤーが上の組織みたいな話はCEOに意図的に話を振っていこうかなと思っています。

というところで、まずパネリストの紹介からでよろしいですかね。石川さんから簡単に、石川さん、榎本さん、松浦さん、簡単に自己紹介をいただいてもよろしいですか？

石川洋資氏（以下、石川）：10Xの石川です。よろしくお願いします。CTOをやっていて、創業メンバーでもあります。もともとソフトウェアエンジニアで、しばらくプロダクトマネージャーやUIデザインをやっていたのですが、最近は新たなメンバーが入ってきたので、また開発責任者をやっています。今日はよろしくお願いします。

近澤：よろしくお願いします。では次、榎本さんお願いします。

榎本悠介氏（以下、榎本）：榎本です。よくmosaと呼ばれています。ボンバーマンのアイコンでネットで活動しています。私だけ今CTOではなくて、モグリみたいになっているのですが、一応最初はCTOだったので許してください（笑）。

今は「LayerX インボイス」と、ワークフローを作っているSaaS事業のプロダクトの責任者をやっています。本日はメチャクチャQAに困っているという話をさせてもらおうと思います。よろしくお願いします。

近澤：よろしくお願いします。では最後、松浦さん。

松浦隼人氏（以下、松浦）：オーティファイの松浦と申します。2019年9月に「Autify」がオフィシャルローンチされる直前にジョインして、2020年1月からCTOをしています。どちらかというとインフラの畑を歩んできていて、オーティファイの中でも、裏でテストを実行する部分を作ってきています。

Autifyはテストに関わるプロダクトで、私たち自身もSaaSを提供してい品質に悩むところがあるので、今日のお話は私たちにとっても役に立つというか、楽しい会話になるんじゃないかと思って期待しています。よろしくお願いします。

一丸となってみんなでゴールを目指す10X

近澤：ありがとうございます。ではさっそく1問目にいきましょう。「急拡大のスタートアップが考えるプロダクトのスケールと品質を両立する方法」というところで、1問目、「現状の開発体制とプロセスは？」　まず現状どうされているか、各社にお話聞いていきたいなと思っています。開発と品質保証みたいなところ、リリースまでどういうプロセスでやって、どういう体制でやられているのかを聞いていきたいと思います。石川さんからお願いしてもいいですか？　

石川：10Xの開発体制とプロセスですが、体制はプロダクトチームが20名弱くらいいて、プロダクトマネージャーが2名とデザイナー1名と残りがソフトウェアエンジニアです。

開発のラインは大きく2つがあって、1つは新規に作っていくべきもの。ネットスーパーでは、まだまだ足りないパーツがたくさんあるので、その新機開発をしています。もう1つは出したプロダクトを継続的に改善していくこと。この2本立てになっています。

後者は、1週間ごとにスプリントを回していて、水曜日にリリース候補をビルドして、その動作確認して、翌週の月曜日にリリースするというかたちになっています。

新規開発は、わりと一つひとつが大きくて関係者もすごく多いので、実際にリリースする1ヶ月以上前にはテストを開始します。店舗も絡んだりするのでトレーニングに使ってもらって、それでリリースに至る感じです。

近澤：けっこういろいろなパートナーさんがいて、まったく同じものを提供されているというより、個別アプリになっているという感じですか？

石川：個別になっているところもありますが、基本的には同じ感じになっています。パートナーによって使う機能があったり、使わない機能があったりというかたちになっています。

近澤：なるほど。基本的なベースのシステムは一緒で、使う使わないみたいなカスタマイズがあって、そこの開発プロセスは1つでやっているという感じなんですかね？

石川：そうですね。

近澤：品質の保証の部分、テスト自体は今どなたがやられているんですか？

石川：QAの専任のメンバーは今はいない状態です。プロダクトマネージャーのメンバーがテストを取りまとめてくれていて、カスタマーサクセスのメンバーや、それこそソフトウェアエンジニアやデザイナーを巻き込みながら、みんなでテストをしているのが現状ですね。

近澤：みんなでテストをして、リリース前に確認するという感じですね。

石川：そうですね。みんな一丸となって、1つのゴールに向かってやるぞみたいな感じが現状ではあります。

明確なPMは不在、スピード重視のLayerX

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

榎本：今日一番お伝えしたいことがあります。「LayerXはブロックチェーンの会社でしょ？」とよく言われて、「LayerX インボイスとワークフローもブロックチェーン使っているんでしょ？」「ワークフローには電子署名ブロックチェーン乗せているんでしょ？」みたいな話をされるのですが、まったくブロックチェーンは使っていません。

開発プロセスやスタックとしては、とてもスタンダードな開発をしています。いわゆるWebエンジニアが集まって、Web系の技術を使ってやっています。開発の手法も、2週間1スプリントで、きちんとスプリント計画をして、振り返りをして、レビュー会をしてという極めてスタンダードなフローです。技術もGo、Vue、Nuxt、AWSなどを使っています。

SaaS事業部は、今はエンジニアが10人でやっています。フロントとサーバーの兼任が多いですね。けっこうフルスタックなメンバーが集まってやっています。こんな感じで、スタンダードにやっています。

じゃあ何が普通じゃないの？　という差分ですが、とにかくスピードを意識しています。爆速開発と社内で呼んでいるのですが、DDDと社内では呼んでいる、デモ駆動開発で実現しています。テスト駆動のほうではありません。

机上でなにか言うというよりは、プロダクトの実際の動きを見てワイワイ言っています。必ず週1でデモを行うから、それまでにきちんちゃんとアウトプットしないといけないみたいな感じです。いい緊張感や褒め称える文化が1つあります。

また、けっこう特殊なのが、明確なPMがいないというところです。一般的には、最初にPMが要件を定義して、画面イメージを固めて、そこからエンジニアに落ちていくみたいなフローになると思うのですが、LayerXはわりと民主的に作る順番や、このスプリントはこれやろうみたいところを決めて、あとはエンジニアが勝手に取っていきます。「この機能はこんな感じかなぁ」とエンジニアが考えながら作っていきます。

ほかにも、デザインのプロセスも今は挟んでいません。エンジニアが勝手にある程度それっぽいフロントエンドを作って、デザイナーの方に渡しています。デザイナーはCSSが書けるので、手直ししておしまいみたいな謎のプロセスが今走っています。

なので、すごく並列可動がしやすいです。直列というより、並列で可動できています。かつ、各エンジニアが背中を預けあっていて、言うなれば今はコードレビューもあまりしていない状態です（笑）。各エンジニアがそれぞれ信頼して、なにかあったら自分の責任だよねみたいな、いい緊張関係を持ってやれているので、スピード感のある開発ができています。

近澤：おもしろいですね。何を作るかもエンジニアが決めていくんですか？

榎本：もちろん壁打ちしながらとか、お客さんに当てながらとかではあるのですが、社内に経理に詳しいメンバーがいるので、PMがオーナーを持ってというよりは、けっこうエンジニアが主導で動いて、セールスがお客さんの声を聞きながらそれぞれが進めるみたいなプロセスですね。

近澤：個々人がセールスや顧客と話す責務があって、自ら何をするか考えていく感じになっている？

榎本：そうですね。直接話さないにしても録画を全部見返したり、議事録を見返したりして、お客さんの生の声をなるべくキャッチしながら作る感じです。

近澤：「これをやってください」ではなくて、「何をやればいいと思う？」みたいな、そういう感じの進め方ということですね。

榎本：ユーザーストーリーがあって、「じゃあ何作るの？」というところから個々人ががんばるみたい感じです（笑）。

近澤：へ～。じゃあ入社されてきたら、その日からコンテキストを渡して「何すればいいと思う？」みたいなそういう感じになるんですか？

榎本：オンボーディングのところは僕らも今模索中で、いきなり荒野に解き放つというより、タスクの曖昧さをちょっと下げて、徐々に上げていくほうがいいんじゃないかという議論をしています。

近澤：へ～。みなさん、自分の領域はここみたいなものがあるのですか？

榎本：ざっくりインボイス、ワークフローとOCR、インフラ、デザインみたいな感じで分けています。それ以外は特に分けていません。

プロダクトオーナーが優先順位を決めて開発を進めるオーティファイ

近澤：なかなかおもしろいですね。最後、弊社オーティファイの松浦から現状の開発体制、プロセスをお話しします。

松浦：オーティファイのプロダクトチームは私を入れて今13名います。そのうち1名がデザイナーで、2名がプロダクトオーナーです。

私たちもスクラムを採用していて、スプリントは2週間です。ただ、デプロイは毎週やっています。金曜日の夜にマージを締め切って、翌週のはじめにそのテストを回して、火曜日、あるいは水曜日にデプロイするというサイクルをぐるぐる繰り返しています。

スプリントは、そのデプロイの日が守れるかどうかをチェックする役割になっています。月曜日、あるいは火曜日に前の週に締め切られた機能をテストするのですが、こういうカッチリとしたQAのフローを開発の中に組み込むようになったのはわりと最近です。

以前は作ったものをどんどん出していくというかたちでした。今は、最後に自分たちのプロダクトである「Autify」や手動など、いろいろなものを組み合わせてテストをしています。それをよりしっかりやっていこうということで、毎週プロセスを回すというかたちになりました。

近澤：ありがとうございます。僕が松浦さんに聞くのもおかしいんだけど（笑）。​​うち（オーティファイ）は基本的にはどういうかたちで要件定義しているかみたいな話や、先ほど榎本さんからあった話でいうと、うちはもうちょっとトラディショナルな感じというか……そのあたりはどうでしょうか？

松浦：どちらかというと、プロダクトオーナーの人間がすべてを取りまとめています。カスタマーサクセスチームや営業からどんどんお客さまの声が上がってくるので、プロダクトオーナーがそのプライオリティ付けをしていって、それを上から順番に開発していくというかたちになっています。

先ほどLayerXさんがおっしゃった、個々のエンジニアの力もすごく大事だなと、今まさに感じていて、その2つをうまく組み合わせて、統一的な流れがありつつもエンジニアが自分で機能を作っていくかたちにしたいなと思っているところではあります。

パートナー企業としてテストを実行していることを示す責任がある

近澤：ありがとうございます。けっこう質問も品質、QAに関する質問が集まってきているので、品質の話に移っていきたいと思います。

具体的に品質保証は誰がオーナーとしてやっているのか。先ほど石川さんには少しお聞きしましたが、誰がテストしているのか、誰が品質を守っていくのかみたいなところを各社から詳しくお聞きしたいと思います。

さっきちょっと聞いてしまったところもありますが、石川さんこのあたりいかがですか？　品質保証のオーナーはいらっしゃるんですか？

石川：最終的な責任は僕にあるのですが、さっき言ったとおり開発ラインが2つあって、新規開発はプロダクトマネージャーのメンバーが主に担当していて、反復的な開発の定期リリースはカスタマーサクセスのメンバーがオーナーとしてやっています。一つひとつのテストに関しては、そのメンバーからお願いされたりとか、そういう中でテストを進めています。

新規開発のほうは、テストのボリュームがすごく大きかったりするので、事前にケースを洗い出すところからメンバーにお願いして、それで分散的に作業を進めています。

定期リリースのほうは、その1週間の間にどういう変更があったのかを各メンバーから週1回しっかり集める機会を持って、変更があったところを中心にやっています。

あと、少しだけなのですが、本当にクリティカルなところだけインテグレーションテストを導入していて、それをひと通り走らせて、通っていることを確認するのが今最低限やっているところです。

近澤：新機能開発のところはPMがテストケースならびにテストの実施を取りまとめていて、定常リリースのほうはCSの方々がテストケースを持っていて、影響範囲を確認していくかたちでリリースを行なっているんですね。

石川：新規開発のほうは、一緒にやってるパートナー企業がけっこう大きい会社で、彼ら自身にも事業を正しく機能させるという責任があるので、テストが十分に行われているということを示す必要があります。

本当に動いているということ以外にも、一緒にやるパートナーとして私たちはきちんとやるべき責任を果たしていますよ、と示す必要があります。そういう意味でも、テストケースを作って実行結果を双方でシェアするかたちになっています。

近澤：もしかしてエクセルでスクリーンショットみたいな話もあったりする？

石川：そこまではないです（笑）。

近澤：よかった（笑）。伝統的なエクセルスクショ芸がもしかしたらあるのかなと思って（笑）。そのへんをちょっと深掘りしたいなと思っています。特に10Xさんは、社会のインフラみたいな会社さんがパートナーとして多いから、求められる品質がすごく高いと思うんですよね。

監査ではないけれども、「きちんとできているの？」みたいなのはやっぱりすごく見せていく必要があるのかなと思っています。そのへんは肌感として厳しい感じはありますか？

石川：今までは許してくれていたというわけではないのですが（笑）、彼らもこれまでSIベンダーの方々にお願いしていたものと、まったく同じことを要求するのは違うと捉えてはくれています。僕ら自身にもまた違った強みがあって、それを殺さないように尊重してくれているなとは思います。

やっぱり、エクセルスクショエビデンスみたいなものは、達成しているものがあって、そもそもテストがきちんと行われているよね、というところをきちんと示すべきといえば確かにそうではあります。ただその手段がちょっと効率的でないし、そもそもそこの実行に対して信頼してもらえないんだっけみたいなところはあるかなと思っています。

そこのバランスをうまく取るために、自動テストをもっと充実させて、スクリーンショットを送らなくてもテストの動画が勝手に送られて、こういうテストケースはきちんと網羅できていますよと将来的には自動で示せるとよいかなと考えています。

近澤：そのあたり、内製と外注の比率はどうなっていますかという質問があったのですが、外部のテストの会社にお願いしているんですか？

石川：今まさに検討しているところです。自動テストの導入が進んでいったとしても、マニュアルでやっていくところがどうしても残るとは思うので、そういったところの設計を内部でも持ちたいと思っています。短期的に、というとなかなか難しいところはあるので、今まさに検討しているというか、お話をしている段階ですね。

泥臭くテストを行うことで仕様をきちんと理解できる

近澤：ありがとうございます。次、LayerXさんがどういう体制で誰がテストしているかをお聞きしてもよろしいですか？

榎本：結論、泥臭くやっています。まず専任ですが、100パーセントQAにコミットしますという責任者はいません。体制がヒーヒー状態です。一応QAのリーダーはいるのですが、カスタマーサクセスと兼任していて、カスタマーサクセスのリーダーも務めているのでかなりやばい状態なっています（笑）。

その人が今半分くらいのリソースで、あとバイトの方の1名でなんとかメインにやっています。すごい勢いで機能が追加されていくので、これってこういう動きをすべきだよねみたいな使用把握だけでも大変です。

僕らのプロダクトの場合、会計ソフト対応というちょっと複雑な山があります。複数の会計ソフトに連携するデータのアウトプット、ないしインプットがけっこう複雑で、かつ、1個1個あるべき仕様を把握するために確認するのが大変です。

わりと泥臭いかたちになっていて、今言った2人ではとても回しきれないんです。リリースを2週間に1回やっているのですが、その時はセールスやエンジニアがヘルプするかたちになっています。

でもいいところはあって、手動QAは仕様把握にとてもいいんですよね。あるべき姿をセールスも、カスタマーサクセスもきちんと理解できます。

エンジニアもそれぞれ背中を預け合っているので、全部を全員が把握しているわけではありません。「この会計ソフトはこういう動きなんだ」と把握できるのはすごくいいなと思っています。

泥臭くやるのにも一応理由があります。開発当初から「きちんとしすぎない」をテーマにエンジニアチームはやっていました。スクラムの最初にやること、やらないことをインセプションデッキみたいなのでやるのですが、そこで、スピードは絶対やるぞと。逆に、きちんとはしすぎない。

もちろんきちんとしないとまずいプロダクトではあるのですが、品質を目的化しないというところで、リソースがない中でエンジニアはきちんと攻められるように、守りは最低限というか、守るべきところは守るけれども、きちんと攻められる体制を作ろうとやっています。

非エンジニアのリソースでもなんとかできるように、Autifyさんをメチャクチャ活用しています。今日も僕、テストシナリオを作ったのですが、便利だなと思いました（笑）。

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

テストピラミッドは上からやるべきか下からやるべきか

榎本：上から下からみたいな話がテストではよくあると思います。E2Eみたいなかたちで、ピラミッドの上から攻めていく。ただ上からだと、テストの局所性があまり取れません。

「なんでこれバグったんだっけ？」がわかりづらかったりするので、下の単体テストから攻めていく方法があると思うのですが、下からやるとメチャクチャエンジニアリソースを食ってしまって、速度にけっこう影響すると思っています。なので、今は上からメインでテストをやっています。たださすがに全国銀行データの出力や、お金に関わるところは単体テストをきちんと書こうと最低限で切り分けてやっています。

ただバグがちょいちょい増えてきたので、今開発リソースの2割は品質に割こうと意思決定をしています。ただ……ありがちですが、そういう意思決定をしても運用に乗るかは別みたいなところがあって（笑）。なかなか難しいですね。

工夫としては、月に1日か2日改善する日、品質やインフラにきちんと気を遣う改善デーを用意したり、隔週でエンジニアが気になるところをざっくばらんに話す会を用意したりしてなんとか運用に回そうとはしています。なかなか泥臭い状態が続いています。

近澤：いやぁ、要は、技術負債やテストの品質の部分をどう定常的に乗せていくかがけっこう悩ましいところだと思っています。うち（オーティファイ）も現在進行形でいろいろ試していて、どうやっていこうかを考えています。同じ悩みを抱えているなと思いました。

榎本：他社さんの取り組み、気になります。

近澤：先ほど軽くお話いただいた上から攻めるか、下から攻めるかというやつ、僕も梶原さんのブログを読みました。

ユニットテストからまず層を厚くして、インテグレーションテストをやって、三角形になるという話です。ユニットテスト、インテグレーション、そしてE2Eテストが一番量が少なくて三角形、つまりテストピラミッドになる。ただ、アンチパターンとしてよく知られているは、逆三角形になるという話です。

E2Eテストが大きすぎて、ユニットテストが少ないものがアンチパターンとしてよく言われるのですが、実は初期においてはそのほうがむしろスピードが上がるし、いいんじゃないかという話があります。

LayerXさんが、逆三角形を上から攻略していくという話をされていたのがすごく印象的でした。上からと下からのバランスをうまく取って、現実解で攻めるみたいな感じですよね。

榎本：ですね。ただ、ずっと逆三角形というよりは徐々に下三角形というか、三角形に移していくべきだとは思います。やっぱりタイミングとリソースは必ず一致しなきゃいけないなと思っています。

近澤：こっちの三角形にするって、すごく理想的ですが、現実的にはやっぱりそうはいかないというのがありますね。これを段階的にどうしていくか、本当はそこをすごく考えなければいけないと思っています。

榎本：初期段階は、お金を生むかどうかもわからないし、お客さんに価値をきちんと提供できるかもわからない状態なので、品質ばかり上げても仕方ないと思っています。なのでいかにコスパよくできるかはすごく大事かなと思っています。

Autify自体のテストはAutifyと手動で対応

近澤：まさしく。ありがとうございます。では最後、松浦さんお願いします。

松浦：当社（オーティファイ）には「Autify for Web」と「Autify for Mobile」という2つのプロダクトがありますが、Mobileはまだベータテスト中で（※取材当時　2021年10月に正式リリース）、けっこうカジュアルにどんどん機能を出すことに集中しています。

どちらかというと、品質が大きな話題になっているのはfor Webのほうです。for Webの品質保証は、プロダクトマネージャーがプロセスを立ち上げています。現在は私のもとで、QAの経験があるテスト自動化エンジニアが実務上QAプロセスを回しています。

ただやはりタスクがかなり多くて、テストケースの洗い出しや、リリースするものの確認などに忙殺されているので、QAのプロセスを率いてくれる方を募集しています。

Autifyを使ってテストももちろんやっていて、そこのテストケースをどんどん増やしつつも、一方で手動で行わないといけないテストもあります。Autify自体のテストがAutifyではできないという難しいところもあります。そういうところは、別のツールを使って自動化してテストを行っています。

先ほどLayerXさんもおっしゃっていましたが、私たちもAutifyを使ったAutifyのテストや、ユニットテストのテストケースを増やしていくのに全体の3割くらいを使いたいというのが最近の流れになっています。意識的にそういったタスクを作っては、スプリントに必ず投入するみたいなことを始めています。

開発でなにか不具合が出たり、インフラ的なインシデントもそうなのですが、なにかインシデントが出た時は、ポストモーテムを書いてみんなでふりかえるようにはしています。

例えばQAプロセスで漏れてしまってバグが世に出た時は、そのポストモーテムの中でどういうテストを書いていたら防げたかなとか、開発プロセスの中でそれを先に見つけるにはどうしたらいいかなという話を一緒にしています。なので、QAというよりは開発チームの1つのワークフローという感じでQAを回しています。

（次回へつづく）