スタートアップ企業をスケールアップするためのQA戦略

2024/04/25

| Sakurai Mizuki

NEWT2年目のQA戦略

弊社では、期初に1年間のミッションとKPIなど全体戦略が共有され、2023年は『10X』をテーマに掲げることになりました。

そのため各チームそれぞれ『10X』なKPIを掲げ、とにかくあらゆる文脈で大きくグロースさせる1年を目指しました。

QAチームとしては守りの文脈の役割を大きくは担いますが、一方で事業を『10X』させるために品質の観点からどんなことを考えアプローチすべきか同時に考えました。 4月から9月までを上期、10月から翌年3月までを下期として区切り、それぞれ上期と下期で整理し、それに伴う変化を取り上げます。

上期の品質目標：テーマ「生産性の最大化」

私はQAチームを創設したタイミングから「品質とスピードをトレード・オンさせるプロダクト開発を目指す」というメッセージを伝えてきました。弊社では “GoFast“ というスピードの価値を重視するバリューを大切にしていますが、品質を向上させることで、スピードをより加速させると考えてきました。

2023年のテーマは『10X』だったため、各チームの目標は前年をはるかに超える目標値となっていました。

NEWTで管理するツアー数は多くなり、販促への投資も増える。そして認知が広がれば、多様なカスタマーが増え、当然トラベルコンシェルジュチームへのお問い合わせ件数も増えるでしょうし、より多くのニーズに応えるためには、プロダクトのリリースを止めるわけにはいかないわけです。

それをふまえると、NEWTをリリースしてからの1年で、障害発生頻度はかなり安定してきたものの、まだまだブラッシュアップできる点もあると考え、プロダクトを安定的に提供し続けるために必要な目標を設定しました。

さらに、リリース前の品質管理についてもより高い基準でアウトプットすることが、結果的にリリースサイクルを止めないプロダクト開発を続けることにつながると考え、大きく2つの目標を設けました。

①障害発生率の設定


・ 変更失敗率 : L1障害 5%未満の実現
・ 平均修復時間 : 障害が発生した場合は24h以内に解消する

弊社では、問題に対して、規模や温度感に応じたレベル分けをしており、共通の品質基準を設けています。その中で最もレベルの高い問題をL1ラベルで分類しており、L1発生率を品質重要KPIとしました。

L1障害が起きると通常業務は止まるため、L1障害は絶対に起こしてはいけない問題としています。とはいえ、どれだけ洗練させた開発をしても、初めから狙って障害をゼロにすることはほぼ不可能です。

そのため、もう一つ重視しているのは、問題検知から解決までの時間です。基本的には問題検知から24時間以内に解決するくらいのスピード感を目指しています。

②リリースブロッカーの削減


・ 不具合発生率 : 昨年度の1/2の実現
・ リグレッションテストで検知するL1不具合削減

2つ目は、前年度の振り返りの中で見えた課題から設定したものです。各社で適応できるものではないと思いますが、リリース前の品質管理について計測可能な目標として定めました。

背景として、NEWT1年目が終わったタイミングで改善点として2つありました。

テストフェーズにおける不具合検知率の改善

リグレッションテストフェーズで見つかるリリースブロッカーの改善

どちらの課題も、カスタマーに届く前に不具合の流出を防ぐことができている点は、QAチームがうまくワークできているともいえます。しかし、全体で見た時、リリースサイクルを遅延させる要素にもなっていました。

そのため、QAエンジニアが行うテストフェーズよりも前段階でのクオリティの向上と、各機能単位のクオリティの向上を全体で取り組みたいと考えました。

上期に行った具体的な取り組み

1つ目のKPIは、2つ目のKPIを達成し、結果として達成できるものといった関係にあるため、注力ポイントとしては2つ目のKPIに対しての打ち手を検討していきました。

主な課題に対して、それぞれ特に効果のあった取り組みについて触れておきます。

①テストフェーズにおける不具合検知率の改善

Dog Foodingの導入

弊社では毎週リリースを継続してきましたが、テストフェーズよりも前に品質を高め、手戻りを減らすことでサイクルを維持してきました。Dog Foodingを毎週開催することで、OS動作差分の発見や体験変更などに対して、クイックに対応できるようになりました。
前年度、初期品質向上のためのQA目線での取り組みという記事の中で、Sanity testの効果について触れましたが、Sanity testの準備をせずとも、開発者テストのクオリティーが上がり、開発者テストにてカバーできる範囲が格段に向上したため、Sanity testのプロセスからDog Foodingの実施へと移行しました。
Dog Fooding、Dog Fooding前後のリリースサイクルについてはこちらを参照ください。

自動化戦略の検討

1年目にNEWT Webでは、Cypressを使ったE2Eを導入していましたが、うまくメンテナンスがワークせず、運用を一度ストップしていました。ただ、リリースサイクルがはやまる中で、効率性と安定性の面からも初期品質を高めるためには自動化を再度動かす必要があると考えました。
1年目は限られたリソース（実際は私しかメンバーはいない）の中で力技で自動化を進めている状態でした。次は戦略をきちんと練り、もっと中長期的な目線で、今あるリソースだけでなく、ありたい姿から逆算して自動化について推し進めていくことにしました。
結果的に短期的なゴールでなく、きちんとワークするあり方から逆算して考えることができたため、下期時点ではツアーとホテルの主要シナリオを運用できるところまで持っていくことができました。詳細は下期の項にて説明します。

②リグレッションテストフェーズで見つかるリリースブロッカーの改善

QA観点の洗い出し、フォーマット作成

1年目は、私ともう1名のメンバーのみのようなQAチーム体制だったため、お互いの相互レビューによって足りていないものを補うことができていました。ただチームも開発スピードもスケールすることで、同じやり方ではワークしなくなることは見えていたため、QA観点なるものを棚卸ししていきました。
結果的に、QAの知見を形式知化していったことは正解で、QAチームだけでなく、他チームメンバーの最初のオンボーディング資料の一つとなり、組織の資産となっています。

リグレッションテストの再定義

機能は毎週のように追加される中で、いかにリグレッションテストを並行してアップデートしていくかという点も大きな論点でした。
リグレッションテストのフォーマットから見直し、更新フローも改善しました。また、リグレッションテストより上流段階で検知するために、機能ごとのテストフェーズにて確認しておくべき観点はそちらに移行するなど整備していきました。

1つ目のKPIである障害発生に対して何もしていなかったかというと、インシデントフローにアップデートを加えるべきと考えていました。

インシデント発生からクロージングまでの対応フローは初年度から作っていましたが、メンバーも増えたこともあり、うまくチーム間の連携がワークしないという課題が出始めていました。そこで、”インシデントプロセスVer2”というものを作成し、ワークフローを改善しました。

インシデントのように緊急かつ温度感の高いタスクについては、なるべく考える余白をなくし、機械的に誰でもできることを重視すべきと考え、明確な手順と役割分担させる形で作りなおしました。

4-5月頃には”インシデントプロセスVer2”を完成させ、その後1ヶ月間は周知→定着→運用→改善→周知…を続け、最終的に、障害が発生しても早期にチーム連携、解決まで行えるプロセスというものを構築することができました。

他にも、もともとセール関連のインシデントが問題となっていたこともあり、プロダクト起因の話やチームの垣根を越えたプロセス整備なども、上期の早い段階で完全に決着をつけることができたことは戦略上、正しい意思決定でした。

結果的に、今では複数のセールを同時にリリースしても安心できる状態を作り出すことができました。これも品質という観点から、プロダクトのスケールアップを支え、グロースを止めない攻めのアクションだったと思います。

セール関連のインシデントをチームの垣根を越えてみんなでゼロにした話

https://engineering.reiwatravel.co.jp/blog/newt-qa-improvement-activity

上期の振り返り

結果的に、L1障害発生率は5%未満を継続的に維持することができており、障害発生後の対応についても24時間以内に解決することを、無事に達成することができました。

一方で、リリースブロッカーの削減については、目標としては達成していましたが、下期を見据えるとまだまだ改善の余地があると感じていました。

上期の振り返りの中から2つの分析をしました。

案件ごとの初期品質の傾向

定常的に初期品質が悪いわけでなく、案件の規模や複雑性によってギャップが大きくなる
通常、App / Web / Backendのチーム単位での開発をしているが、チームの垣根を越える不確実性が大きなもので、手戻りを増長していそう

⇒ 初期品質を不具合発生率としてモニタリングしてきましたが、リリースブロッカーになるような大きな手戻りにこそフォーカスすべきと考えることにしました。また、初期品質については大きな案件に絞ってモニタリングしていたのですが、むしろ小さな開発案件でブロッカーを混入させる方が状態としては良くないため、この点をモニタリングできる状態を作ることを、下期の改善ポイントに組み込むことにしました。

リグレッションテスト以降の手戻り発生

実際にリグレッションテスト以降で発生した手戻り件数は、半期通して数件に削減できていた
一方で、リバートやリリース日の遅延につながったものが一定あった

⇒ 大きな遅延ではないがリリース日が1日遅れるなどの影響があり、チームがスケールする中では、改善すべきと考えました。リグレッションテストで拾うべきものもありますが、事前のフェーズで検知できる問題もあると考えました。

さらに上期が終わったタイミングで、一つのあらたなテーマもわいてきました。それは “標準化” です。下期戦略に標準化の観点を組み込んでいくことで、さらに守りと攻めのQAを両立できると考えました。

下期の品質目標：テーマ「属人化からの脱却と標準化」

サービスがグロースしていく中でも、プロダクトの品質基準や価値が大きく損なわれることなくプロダクト開発ができていたことは、前提としてプロダクトチームの大きな成果だと今振り返っても感じています。

一方で、下期を考える中で、考慮すべき点としてプロダクトのグロースとは別に、組織のグロースについても考慮すべき時期に差し迫っていました。

下期戦略を考える中で、プロダクトチームだけで約1.5倍に拡大する採用計画で検討していました。

いわゆる創業メンバーで成り立っていたチームから、多様なメンバーで構成されるチーム体制で、これまでと同じ「品質とスピードをトレード・オンさせるプロダクト開発を目指す」という大テーマを実現しなければなりませんでした。

品質を守っていく中で、意識しなければいけないと思っていたことは、個人のファインプレーでなく、誰でも私たちが体現したいクオリティを発揮できる基盤作りでした。それはまさに、標準化の必要性です。

そしてQAチームとしてさらに考慮すべき点として、「QAエンジニアも開発メンバーと同じだけ増えるのか？」というと、QAエンジニアはそこまで増えない構図だと考えていました。

現在も弊社では内製化したQA体制を目指しており、開発メンバーとQAメンバーの対比が変わっても、今の品質基準を落とさないために先手を打っておく必要がありました。

そこで、より上流フェーズでの品質向上にシフトしていくことや、自動化をより強化していく方向性で進めたいと考えました。

そこから逆算し、下期の品質目標を定めていきました。

①障害発生率の設定


・ 変更失敗率 : L1障害 5%未満の実現
・ 平均修復時間 : 障害が発生した場合は8h以内に解消する(1営業日以内)

1つ目は、上期と同様のものを設定しています。

より高い変更失敗率を定めることももちろん可能なのですが、私たちが目指すことは障害をゼロにすることではないと思っており、重要なのは事業のグロースを止めず、継続的にカスタマーへの価値を提供し続けることです。そう考えると、より高い目標設定をおくことはスタートアップのグロース期においてはtoo muchですし、組織規模が拡大する中で、メンバーが変わり、複雑性が増す状態で、同様の品質目標を達成すること自体、実は難易度が高いことだと思っていました。

ただ1点、カスタマーが増えるという中で、問題に対して可及的速やかに解消していくスピード感は一層求められると思い、平均修復時間の目標数値についてはさらにショートに設定しました。

②初期品質の向上


・ L1以上の不具合発生率：最終的に5%以下の水準の達成
・ 事前に検討・議論することで回避できたであろう仕様考慮漏れ不具合の軽減

2つ目は、手戻りをとにかく減らし、カスタマーへの価値提供機会を増やしていくために、初期品質を向上させることに全力投資することを考えました。初期品質とは、エンジニア実装完了段階の品質を意味します。

L1以上の問題があると弊社では機能をリリースすることができないため、L1不具合をとにかく減らすことがリリースサイクルを高速化するためには必要となり、さらに仕様の検討が漏れていたことによる手戻りは、体験を大きく損ないますし、コストも大きくなります。

そこで、L1以上の不具合発生率のコントロールと、不具合タイプの中でも仕様考慮漏れにフォーカスしました。

③標準化


・機能ごとにドメイン、観点のリストアップ・観点表を作成できている状態を目指す

3つ目は、標準化の第一歩としてこのようなテーマを設けました。 QAチームのスケールを考えた時の標準化・属人化の解消と、プロダクトチーム全体としての品質活動のレベルアップの両軸を並行しながら進めていくことにしました。

下期に行った具体的な取り組み

1つ目のKPIは、上期同様に2つ目、3つ目のKPIを達成し、結果として得られるものなので、ここでは主に、初期品質向上に向けてと、標準化に向けての取り組みの中で、特に効果のあったものについてふれます。

①初期品質の向上

E2E

上期に自動化戦略の検討と方向性を決めていたので、あとはカバレッジをあげていくことで、ここの有効性は高まる状態でした。
QAエンジニアとフロントエンドエンジニアが協業する形で自動化の推進を目指しました。シナリオ作成はQAエンジニアが中心となり進め、ツアー・ホテルとそれぞれあるシナリオのうち、ツアー側を開発メンバーが、ホテル側をQAメンバーが進めるなど、メンバー全員が一度はPlaywrightに触れている状態を作り、かつどんなシナリオが実装されているのかを理解している状態を作りました。
NEWT Webでは、CypressからPlaywrightにリプレイスしました。
E2Eテストについての詳細はこちらを参照ください。
なお、Backendについては、Backendエンジニアを中心にテスト管理しており、クライアントについてはまさに2024年やっていきたいフェーズです。どちらもこれからQAチームとしてコミットしていきたい部分です。

不具合、インシデントの徹底分析・振り返り

泥臭く、実直に改善活動のタネになることを日々集め、振り返り、仕組みで解決できるように繰り返しました。
案件の大小に関係なく、不具合レベル別の発生率、原因などを分析し、改善活動に繋げました。

②標準化

定期的に手の入る機能の設計書の標準化

機能拡張は継ぎ足しで増えているため、影響範囲や既存機能の理解がないと、大きなデグレを見逃すケースも多く、さらに類似事案に対して1からテスト設計するより効率的なので、優先度の高い機能から標準化していきました。
NEWTの特性上、ツアーの検索体験はカスタマー体験向上に直結するため、特に検索体験に多く手が入ると仮定し、機能の優先度を選定しました。
一度作ったフォーマットで、別のメンバーがテスト設計・実行し、漏れややりづらかった点を修正し、もう一度新しいフォーマットでやってみる、ということを繰り返しました。

「さがしやすい検索」機能を多数リリースした1年。この選定方法は間違っていなかった

テストパターンのマトリクス表作成

NEWTでは大きく分けると、ツアーとホテルが機能軸としてありますが、裏側は複雑なロジックでできています。
一見するとどれも同じデータに見えるのに、実際の構成は全く違う作りになっており、新しく参画するメンバーが全体像を把握することが難しい状況になっていたので、全体像を把握できる地図のようなものを作りました。

また1つ目のKPI文脈では、大きくは2つのことを行いました。

1点は、問題検知の速度をはやめるためのログ実装や監視の仕組み・運用体制の構築です。

もう1点は、プロダクト以外で起きている問題についても管理することです。

上期まではプロダクトのインシデントにフォーカスしていましたが、カスタマーから見えているものは「NEWTのサービス」なので、プロダクト以外で起きる問題、それがたとえ弊社によって引き起こしている問題でなくとも、良い体験を損なった事象についてきちんと把握する必要があると思ったからです。プロダクトチーム以外で起きた障害についても、インシデントレポートをフォーマット化し、振り返りの仕組みを作り、一元管理するようにしました。

下期の振り返り

KPIの振り返りをする前に、組織拡大の実績についてお話ししておくと、プロダクトメンバーは20名から30名まで拡大し、採用計画通り1.5倍の組織拡張をとげました。

その上で下期は、L1障害発生率は5%未満を継続的に維持することができました。さらに障害発生後の対応についても数時間以内に解決することができており、激しい変化にチームは適応することができたと言える結果となりました！

ちなみに、障害発生率は目標数値を達成しながら、これまでプロダクトの累積リリース案件数は順調に伸び続けています。

メンバーが増えていく中で、生産性を維持・向上させながら、品質とスピードを両立させてこれたのは、プロダクトチームの大きな成果と言えます。

また、結果的に事業としてもしっかり伸びており、プロダクトの価値がお客さまに届いている点は、チームでプロダクトゴールを目指してこられたからだと感じます🎉

一方で、問題の種類が変わりつつあり、それはプロダクトと組織がグロースしたからこその問題でした。

1つはアクセス数増加によるサーバー負荷問題。もう1つは、デグレや影響範囲漏れによる問題の増加です。

ますます組織は大きくなり、プロダクトももっと大きくなることを目指しているため、まさにこれらの課題を早期に解消しようと、これから向き合おうとしています。

ネクストステージ

静的なベストではなく、”改善し続けるベター”を目指す

これまでQAエンジニアとしてプロダクトに様々に携わってきましたが、品質には正解もなければゴールもないということを、この1年で強く感じました。

特に変化の激しいスタートアップという環境において、今日良かったことが明日も良いかというと、そうでないケースもあります。

昨日までの成功体験に縛られることなく、アンラーニングし続けること。よかった過去ではなく、未来と向き合い続けられるか？という視線の向け方は大切だと思います。

たしかにこの1年で、NEWTは大きな成長を遂げましたが、私たちはまだまだ挑戦者であり、成し遂げたいミッションのほんの一部に指をかけたくらいのところにいます。

時間をかけ考え抜いた最高の一石を投じるのでなく、改善し続けることを前提としたベターな状態を作り続けることを、私たちは目指すべきと考えています。

これからNEWTはさらなる成長を遂げるプロダクトになると思っているので、そんな環境で、非連続な成長や経験を積みたい！という方は、まずはお話からでもさせてください。

▶️ メッセージはこちらから：https://twitter.com/mii________san

ここまでの1年の振り返りを読んで、「NEWTは順調そうだ」と思った方に、”ごめんなさい、そんなことはありません！”と大きな声でお伝えしたいです！（自信を持っていうなという感じですがw

実際、QAエンジニアの役割だけでいっても、開発組織がスケールする中で品質基準を守り続けることは難易度が高いミッションですし、旅行ドメインの根幹を担う基幹システムの1人目QAエンジニアの席はまだ空いています。

さらに、これだけ成長している環境だからこそ、次々と新規立ち上げもあると思いますし、グローバルな展開だってもちろん見据えており、羅列していくだけでもやらなければいけないことが山盛りなのです。

過去に給与や金融といったドメインを経験してきた私の視点からも、旅行ドメインは複雑で、難易度が高いシステムといえます。そういった難易度の高い品質活動の経験や、toCとtoBの両観点を常に持ち合わせながら行う品質活動も、得難い経験と言えそうです。

とにかく言いたいのは、まだまだチャレンジングな挑戦ができるということです！

アウトプットの総量でなく、”アウトカムの向上”で評価する

これまで私たちは、ゼロイチを積み上げてきており、旅行のプロダクトとしての当たり前を積み上げてきました。

ほぼ何もない状態だからこそ、何かアウトプットすれば、それがプラスに作用するのは当然といえば当然で、だからこそ生産性を高めることで、結果的にプロダクトの価値も向上していました。ですがこれまで同様に、生産性を追い求めるだけでは、プロダクトの価値の成長角度は確実に落ちるはずです。効率化していくことで確かに無駄は減り、大きな問題も起きづらくなるかもしれませんが、同じやり方を同じ思考でやり続けるとするならば、革新的な発想や行動も生まれづらいでしょう。とにかく数を打ち、トライアンドエラーを繰り返すなかで見えてきた正解が、そのまま価値につながるというフェーズから、より緻密な分析からカスタマーのニーズをとらえ、より重要度が高く、非連続な成長曲線を描けるようなサービス提供が求められるフェーズに変わりつつあります。

そのためにはAIなどの技術的な大胆な取り組みが必要ですし、生産性だけを追い求めるようなタスク消化型の形から戦略遂行型組織へと変わり、各々が自分たちのミッションを考え、行動することが求められます。これからは、アウトプットの数ではなく、カスタマーに届いた価値で、私たちは良し悪しを評価すべきです。機能をリリースしたことはあくまでスタートでしかなく、それが「いかに使われたのか？」「どれだけ良質な旅行体験につながったのか？」を定量的に分析し、チーム全員で向き合うことで、その機能の本当の価値は決まると思います。

スケールアップから”スケールアウト”へ

これまでの2年間はとにかくワンチームで、それぞれが成長し、垂直立ち上げすることで、事業もチームもスケールしてきました。

けれどこれからのフェーズは、自律的かつ自走できる組織を次々つくり、同時並行的にスケールアウトさせていかなければなりません。多くの優秀なメンバーが揃っているプロダクトチームですので、より可動力の高いチーム体制を構築し、各チームがそれぞれの目標に責任を持ち自立していくことが、これからのグロースに不可欠だと考えています。

これまで以上にリリーサイクルは早まるでしょうし、チーム単位でのクオリティーの担保は絶対条件にもなるため、より難易度は上がります。

ですがそれぞれの責務を果たすことで、スケールアウトへの変化にも順応できるのではないかと思ってます。

それと同時に、QAチームとしてもこの変化に対応するためには、多くのことを整えていく必要があります。

私たちQAチームは、みんなが全速力で走ってもこけたり、事故に繋がらないような先回り的な行動が求められます。

新しい道を作り、ルールも作らなければいけませんし、もしもルール通りの速度で走れないなら、それを支援する活動をしなければなりません。

プロダクト開発がスケールアウトするために、QAチームもさらにこの1年でたくさんの壁をこえていかなければなりません。