こんにちは、VP of Engineeringの青木啓剛です。
代表の平井による「【実践編】コンパウンドスタートアップの作り方」から始まった、プロダクト開発や事業づくりにおける各種領域について語るシリーズもついに10記事目です。本日はプロダクトのQA（品質保証）の観点から、コンパウンドスタートアップならではのQAのあり方、特にコンパウンドスタートアップにおける重要な役割を担うデータ領域にフォーカスして考えてみたいと思います。
テスト自動化とテストピラミッド
コンパウンドスタートアップという考え方は比較的最近の言葉ですが、その根幹にあるいくつかの要素を持ち合わせた企業というのはこの言葉が生まれる前から存在しています。例えばGoogle社は、複数のプロダクトを並行で開発・提供し、それらの多くはデータを連携させることによって価値を高めることに成功しています。彼らはすでにスタートアップではないという点においてコンパウンドスタートアップにはあたらないですが、彼らのプロダクト開発手法からは学べる点が多いのではないだろうかと考えました。
Google社のQAに関しては、いくつか公開されている情報があります。たとえば2018年に開催されたソフトウェアテストシンポジウム『JaSST’18 Tokyo』の基調講演では以下のようなことが言及されています。
- ほぼすべてのテストが自動化されていて、QA期間は存在しない
- エンジニアが自動テストを書くことを期待されている
昨今はテストの自動化推進に投資をするスタートアップも増えており、私たちestieも例外ではありません。しかしながら、”Almost all” と言い切れるだけの徹底した自動化に関してはそれを推し進めるだけの理由があったのだろうと考えられるのではないでしょうか。（参考：情報のソースが確かではないのですが、Googleも最初から「ほぼテストは自動化」というスタイルではなかったようで、2000年代後半に方向性を転換したらしいという話を耳にしたことがあります。）
テストの自動化を進めていくにあたっては、テストピラミッドの考え方を適用することが有用だと広く認められています。2009年に発刊された書籍「Succeeding with Agile (Mike Cohn著)」で提唱されたこの概念は、テストレベルを3つに分類し、テスト実施のコストと品質のバランスを取ろうというものです。
先人であるGoogle社に学びテスト自動化を中心に据えるという前提のもと、このテストピラミッドの考え方をベースに、どのようなテスト戦略で自動化を進めていくべきだろうかと思考を巡らせてみたいと思います。
マルチプロダクトにおけるテスト自動化
先ほどご紹介したテストピラミッドを単一プロダクト開発におけるテストの概念と仮定し、その上でマルチプロダクトでの開発をイメージすると、以下のようにピラミッドが横に増えていくイメージでしょうか。
プロダクトそれぞれが独立性が高く、QA活動もプロダクトごとに閉じた形での実施で構わなければ、この戦い方は十分に有用であると考えられます。実際の組織づくりとしてはプロダクトを開発するスクラムチームごとにQAエンジニアが所属していて、開発チームとともに品質活動を行っていくイメージでしょうか。担当領域や顧客課題に対する深い理解のもとでのQA実施は、プロダクトの品質向上に大きく寄与できることができるでしょう。ひとつの正解の形だと納得感があります。
コンパウンドスタートアップにおけるQA課題
いよいよ本題です。単なるマルチプロダクトではなく、コンパウンドスタートアップとしてのテスト戦略について考えたいと思います。前述のピラミッドが複数立ち並ぶ状態では、コンパウンドスタートアップならではの品質課題に対して、いくつかの難しさが残っている状態だと考えます。
まず1つ目ですが、プロダクト間のデータ連携に関する課題です。
これは実際にestieの開発チームが過去に直面し、現在も向き合い続けている課題なので私としても非常に実感があります。データを互いに連携しあうことで価値を増大させるコンパウンドスタートアップにとっては、特定プロダクトに閉じた品質がテストによって十分に担保できていたとしても、プロダクト間連携の品質には直接的にはあまり寄与しないというジレンマがあります。
そして2つ目、データそのものの品質をどう担保するかという課題です。
弊社和田が書いた記事「コンパウンドスタートアップを目指す estie のデータ基盤の現状 」でも言及されているとおり、各プロダクトで共通的に使用するデータは、データ基盤で管理される構成が考えられます。データ基盤側にてデータ構造に関する変更が行われた場合、プロダクト側でもその変更を追随するような修正が必要になったりします。時と場合により、プロダクトのアプリケーションコードに一切変更を加えていなかったとしても、そこで扱われるデータの更新によって不具合が生じる、などという可能性も否定できません。
これらの課題について、どのように立ち向かうのがよいでしょうか。
コンパウンドスタートアップにおける理想のQA仮説
先ほどのセクションで言及した2つの課題に対して、現時点で私は以下の方針によってQAを実施していくのが良いのではないだろうかという仮説に至りました。
プロダクト間データ連携に関しては、テストピラミッドにおける中間レイヤー「Integration Test」の階層においてプロダクト連携を意識したテストを充実させていく必要があると考えています。データ連携という観点においては、やりとりのインターフェースを定義し、内部の振る舞いに関わらず期待振る舞いをしてくれることが求められます。実施コストも考慮すると、Integration Testのレイヤーにて責務をもつことが適切と考えます。
弊社estieではバックエンドの開発言語が複数存在していますが、横断的な品質向上を見据えて、統一した記法でIntegration Testを実施できる基盤の構築を計画しています。
なおこれは余談ですが、冒頭言及したGoogle社は、テストピラミッドという言葉すらなかった2007年のブログ記事においてテスト自動化を成功させるための考え方として、End-to-end Testを放棄すべきではないが、公開インターフェースに対して極力低レベルのテストを増やすべきと言及をしています。この考えをテストピラミッドに投影すれば、Integration Testの充実が重要である、と言い換えることができるのではないでしょうか。
一方、データ品質のテストに関しては、UI Testにおけるリグレッションテストの考え方を応用できないか、ということを模索しています。例えば、Datafoldというツールは2つのデータソースにおけるデータの差分を可視化することで、データの品質確認を容易にすることを目指しています。
データ基盤とプロダクトをつなぐデータパイプラインに対して何らかの変更を行った場合、その変更適用前のロジックで処理されたデータと、変更適用後のロジックで処理されたデータを見比べて確認ができるようになると、思わぬ事故が生じる可能性を格段に減らせるのではないかという仮説です。
理想のQA実現のために
大前提として、この記事で言及した2つの仮説は現時点で机上の空論に過ぎず、実際に課題の束と向き合っていく中で答え合わせをやっていく、あるいは別の答えにたどり着く、そんな位置づけのものだと考えています。実践してみてどうだったかは後日ブログの記事で紹介をさせていただこうと思います。
また、今回はあえてテスト自動化にフォーカスしましたが、良いユーザ体験のプロダクトをつくっていく上では手動のテストの重要性も依然として大きいです。そのバランスについても今後試行錯誤を続けていく必要があることは申し添えておきます。
estieでは、QAとしても非常に挑戦しがいのあるコンパウンドスタートアップ戦略を推進しています。そして、この課題解決に一緒に取り組んでいただける仲間を探しています。少しでも興味のある方はぜひカジュアル面談しましょう。
