QA組織を立ち上げ、QA文化を築いてきた1年間を振り返る

2022年4月。コアローンチとQA組織の誕生

＜0＞品質とスピードをトレードオンするために

海外旅行予約アプリ『NEWT（ニュート）』は、2022年4月5日にコアローンチしました。私が入社したのは4月1日、プロダクトをリリースするわずか数日前のことでした。当時を思い返すと、まさに”カオス（祭り）”で、どのチームもお客さまへ『NEWT（ニュート）』を届けるためにリリースに向けたラストスパートを駆け抜けている印象でした。ですが同時に、コアローンチはゴールではなくあくまでスタートであり、リリース後いかに安定し、継続的により良いプロダクトをお客さまに届けられるかについて考えるべきだろうと私は冷静でした。

入社当時の令和トラベルには、リリースプロセスやテストプロセス、branch管理や課題管理方法などが明確には存在せず無秩序で、個々人の裁量とコミュニケーションによってあらゆる問題を解決していました。それはそれですごいことですが、プロダクトをリリースした後は、ある程度のルールやプロセスを設けることで、安心したプロダクト開発やチームの生産性を損なわないプロダクト開発を目指せると考えました。

当時エンジニアチームが定めた重要指数は、下記の4つです。

デプロイ頻度

ソフトウェアの本番環境へのリリースの頻度

変更リードタイム

ソースコードのコミットからQAそして本番稼働までの所要時間

平均修復時間

L1インシデント（重大障害）が発生してから復旧するまでの時間

変更失敗率

本番環境へのリリース時のL1インシデント（重大障害）の発生率

これらの指標を維持、向上させるには、”品質もスピードも犠牲にはできない”という行動指針を設定し、これらをQA Unitで定期的にモニタリングすることでプロダクトの健康状態をはかろうとしました。

その上で私は、QA Unitの上期テーマは「プロダクト開発が継続的に進行するように、市場での重大インシデントを減らし、お客さま影響を最小化すること」をミッションに定め、取り組むべきことを整理していきました。

＜1＞プロダクト視点

QA文化のなかった令和トラベルでは、プロダクト品質向上のために3つのステップに分解し、QA活動を開始しました。

共通認識を揃える

どんなことをする時にもまず大事なことは、状況の整理だと思っています。なぜなら多くの場合、どこに向かっているのかゴールさえわかっていればプロフェッショナルなメンバーであれば、そこに向かって自走できると考えているからです。

そもそも令和トラベルにはQA文化としての共通認識が存在していなかったので、その部分を言語化し、方向性を指し示しました。いわゆる標準化に近いですが、ただそこまでかっちりとしたものではなく品質に向き合う上でのマインドセット、リリース基準、プライオリティ基準などを定義しました。初期に考えた思想は今もブラッシュアップしながら継続しており、オンボーディングという形でQAやQA文化について全メンバーに伝えています。

“品質”をみんなのものにするために行なっている入社者オンボーディング

令和トラベルに所属するエンジニアのブログです。「あたらしい旅行を、デザインする。」令和トラベルは、海外旅行事業を展開するデジタルトラベルエージェンシーです。

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

定量的な品質管理

次に、品質の管理です。いくら品質が大事だと言ってもプロダクト開発において品質だけが重要なわけではありません。なぜならスタートアップという環境にいる以上、スピードは最大の武器となります。その武器を活かし価値を最大化するために、「ここまでは大丈夫」「これ以上はダメ」となるボーダーラインが必要でした。

そこでリリース前後の品質を見える化し、品質を定量的にはかることを行いました。

リリース前の不具合分析から見えてきたことは、上流工程で改善できる不具合が多発していることがわかり、そこからSpecの整備方法の見返し（いわゆるきちんとした仕様書がなかった）やコミュニケーションの取り方などの改善を具体的な取り組みとして実施していきました。

特に重要視していたリリース後のインシデント数については注視しており、優先順位、発生要因の整理をつけた上で振り返りを実施し、一つ一つ丁寧に問題を解消していきました。

改善活動

そしてプロダクト視点での品質向上に最も寄与したことは、やはり改善活動を継続的に回したことでした。チーム間での認識と品質管理ができる状態を作った後は、ひたすら課題を見つけ解消していくことを繰り返しました。

私が入社した当時はnotionを使った管理方法がメインだったため、長期的なスケールを見据えJIRAを導入しました。エンジニアのパフォーマンスやタスク管理がしやすくなったことはもちろんですが、JIRAで作成したダッシュボードを使っての実績ベースの振り返りを簡単にできるようになったことは良かったポイントの一つです。

こうしてどんな問題が発生したのかを見える化し、問題と対峙することで今後の資産にしていくとともに再発防止活動を行いました。

＜2＞プロセス視点

上段の通り、リリース当初はリリースサイクルというものが特になく、「できたものをとにかく速くリリースしよう！」という状態でした。速くお客さまにプロダクトを届けることは大切な一方で、いつまでに何をしなければいけないのかが曖昧な状態では、生産性を維持できず、リリース頻度を増やすことの弊害にもなりうると考え、リリーストレインなるものを定義しました。

当時の開発チームは、エンジニア8名に対してQA1名ほどの体制（かつ弊社は業務委託のエンジニアの方も多数在籍）で開発を行っていました。開発者個人のタイミングで機能をリリースしたいといわれてもQAできなかったり、そもそも開発が終わっても次に何をしたらいいのかわからない（QAには何を伝えたらいいのか、など）といった疑問を解消させるために、簡単なリリーストレインを用意しました。

開発が完了したら一度コードフリーズをもうけ、テストビルドを配信してもらい、テストを実施

修正が必要であれば対応してもらい、最終ビルドをOSごとに配布

最後にL1シナリオとして設けたリグレッションテストを実施し、審査アプリで問題がないことを確認できたら審査提出する

といったフローで、アプリのリリースをしました。

リリーストレインを導入し始めた当初は開発サイクルと仕様検討のサイクルがうまくマッチしなかったり、PPメンバー（※弊社では業務委託のメンバーをプロパートナーと呼ぶ）とのタスク連携などの部分で課題があったりと、リリース件数が好まし状態ではありませんでしたが、継続する中でコツを掴み徐々にリリースできる機能件数も増えていきました。

たしか4月時点ではリリースできたEpic数はほんのわずかで、まさに未整備のままに進むことの不安定さを物語っていた気がします。

他にも、ストア審査時の文言が意図しないまま公開されてしまったり、強制アップデートの実施一つで右往左往したり、本当に色々とあったと思い返しています。ですがそうした一つ一つの事象に、「では、どうしたらいいか？」と前向きに捉え、無駄や誤りを減らすことがどうしたらできるか議論し、結果としてリリーストレインは形式知としてワークしていきました。

リリーストレインを設けることで、定期的なリリース日やサイクルが決まり、PM、デザイナー、開発者などチーム全員がいつまでに何をしなければいけないのかが明確となり、業務を遂行するサポートになりました。

＜3＞チーム視点

QAチームといっても当初は私一人だけ。幸いなことに会社は、品質の重要性を理解しており、まだプロダクトをローンチし間もないタイミングから、さらにQAメンバーを増やすことを支援してくれました。

ただ闇雲に進んでもいきなりチームはスケールしないため、私は2つのことに取り組みQA Unitの基盤を作りました。

ロードマップの作成

社外発信をベースとした採用活動

ロードマップの作成については、事業戦略はもちろん、プロダクトのスケールや組織の変化を考慮し、まずは6ヶ月間のロードマップを作成しました。何月までにどのような状態を作っておけばチームとして成立するのか、またどんな準備をしなければいけないのかを整理していきました。

そして社外発信をベースとした採用活動については、大きくは2点。1点目は適切な人材の採用に向けたJDの再定義や採用媒体を拡大するなどを行いました。2点目はいざ転職を考えた時に候補にあげていただける企業になる必要があると考え、エンジニア組織の社外発信やイベント登壇などを積極的に行いました。

結果として、フルタイムのQAメンバーと、PPのメンバーの採用につながりました。

QA Career Talk vol.3 ~メガベンチャーからスタートアップQAへ~

https://engineering.reiwatravel.co.jp/blog/qa_event_3

QA Career Talk vol.3 ~メガベンチャーからスタートアップQAへ~

※ QA Career Talkという形で主催イベントもついに3回目を迎えました！引き続き開催予定です。

＜4＞振り返り

実はこの半期で最も意識していたことは「QA Unitが会社にあることの意義や価値をメンバーに知ってもらうこと」だった気がしています。

多くのメンバーはQAエンジニアと働いた経験がなく、QAエンジニアって結局何だったの？と思われたら、私が入社した意味はないと思っていました。リリース間もないNEWTに、爆速で貢献したかったというのが本音で”QA エンジニア”という肩書きを脱いで色々と挑戦しましたが、「やりましょう！」と受け入れてくれる環境があったからこそ、私のバリューは発揮出来たと感じます。

さて、上期テーマにおいていた「プロダクト開発が継続的に進行するように、市場での重大インシデントを減らし、お客さま影響を最小化すること」についてですが、数値で振り返ってみると達成できたと思っています。

5月頭にグッと数が増えていますが、リリース当初から存在していた問題が多く、そのタイミングで既存不具合を潰しにかかり、そこからはほぼ新規での問題が発生しないようなサイクルになりました。

当然、新たなイレギュラーな問題が発生しないため、私たちは生産性高い状態を保ちながら機能開発することに専念でき、結果的にリリースできたEpic数も増えていきました。つまり、リリース件数は増えても、インシデントが起きない仕組みを作り上げることを上期の段階で作り上げることができたのです。まさに品質とスピードのトレードオンが証明された瞬間でした。

2022年10月。機能拡張と新規プロダクトの立ち上げ

＜0＞更なる品質とスピードのトレードオンに向けて

上期テーマは端的にいうと市場での重大インシデントをなるべく減らすことでしたが、下期はこれに加え、新しい目標を掲げることにしました。

次に目指すべきことは、インシデントをなるべく発生させないだけでなく、いかにリードタイムを短くし、良いものをお客さまに届けられるかという点にフォーカスしました。

そのため下期は上期同様の4つの指標（デプロイ頻度・変更リードタイム・平均修復時間・変更失敗率）に加え、開発完了からリリースまでの間に起きた不具合発生率をモニタリングすることも追加し、初期品質を高めることを品質指標としました。というのも、上期でインシデントの発生をある程度是正できたものの、リリース前にQAから指摘される不具合が多いという課題が残りました。QAフェーズになるとチーム全体の負荷がグッとあがってしまうところに改善の余地があると考え、初期品質を向上させることをひとつのテーマにすることにしたのです。

そこで、QA Unitの下期テーマはリリース後のインシデント件数だけでなく「リリースまでのリードタイムの縮小と高品質を目指すこと」をミッションに定めました。

＜1＞プロダクト視点

下期を語る上で忘れてはいけないことは、下期からNEWTに新しく海外ホテルプロダクトをリリースする計画があったことです。ローンチ当初からあった海外ツアー向けの機能追加や改善だけでなく、新たにNEWTの柱となる海外ホテルプロダクトを立ち上げることを前提にプロダクト開発を進めていく必要がありました。ただ海外ホテルプロダクトを開発していく過程については、あまりに長くなってしまうためここでは省略させていただきます。（これだけでコンテンツになるので、また機会があれば。。）

海外ホテルプロダクトをリリースするためにも、海外ツアーを安定的に最少人数でリリースする必要があり、ここで初期品質が重要観点となってきました。

正直下期からモニタリングし始めた初期品質については、下期開始時はあまり良い傾向にありませんでした。そこから改善ポイントを探り、原因を突き詰めていくと、エンジニア自身で確認すべき観点に漏れがあることがわかりました。開発完了の連絡を受けた後にQAの進行が止まらないようにするための、セルフQA制度を取り入れました。QAメンバーへQA依頼前に必ず自身もしくはチームでテストし、そのテストが完了しなければQAチームに回すことができないというものです。

やっていることはシンプルなことですが、Figmaに記載があるのに実装されていない機能やデザイン、そもそもQAに入れないという致命的な問題はこの取り組みによってかなり改善されました。

詳細についてはQAメンバーのブログにて紹介しています。こちらをご覧ください。

初期品質向上のためのQA目線での取り組み

https://engineering.reiwatravel.co.jp/blog/newt-adventcalendar-20230419

＜2＞プロセス視点

上期に構築したリリーストレインをさらにブラッシュアップすべく、ツアーチームのリリースサイクルを固定化しました。上期は平均6.75日間隔でリリースサイクルが回っていたのですが、下期は5日間隔で完全固定化を目指しました。

1週間に一度アプリをアップデートするサイクルでまわっており、仕様検討、開発期間、QA期間どれもスピード感をもって対応しています。

そのため、QAの体制としてはツアーチームとホテルチーム、それぞれにリードQAとして1人ずつ張り付く形でこのサイクルの実現をしました。

ここではホテルプロジェクトについて紹介しておきます。実はこちらかなり苦戦したプロジェクトでした。

下期がスタートしたときからプロジェクトはスタートしていたのですが、外部連携箇所なども多く不確実性の高いプロジェクトとなっており、年内リリースはほぼ不可能という状況が11月中旬に発覚しました。

ですがここで諦めないのがこのチームのすごいところで、とにかくどうしたら年内にリリースできるか整理しました。

どんなタスクが残っているか

それを実施するにはどれだけの工数がかかるか

まだ見えてない不確実要素はなにか

ブロッカーはなにか

などを順に整理し、分かったものから担当者をつけ、対応していきました。この時にはすでに全プラットフォームでの対応ができないことがわかったので、最小単位戦略のもとiOSのみ先行でリリースすることを決断しました。

正直この頃のホテルプロジェクトでは、必死すぎてプロセスというプロセスがなく、ただがむしゃらに画面単位で、実装 → テスト → 修正 → テスト→ 修正…の連続を、高速にまわしていました。この反省を活かし（正確には活かしきれてはない）、2023年の1月からすべてのプラットフォーム対応とお得な世界観を作り出すための機能追加（クーポンやポイント機能）をロードマップにまとめ、誰がいつ何をするのかプロジェクトマネジメントしながら進めていきました。結果的には2023年4月5日の周年記念の目玉として海外ホテルをお披露目することができました。

しかも今ならクーポン配布中でさらにお得に海外に行くことができます。(歯を食いしばりながらクーポン、ポイント機能を作りましたので、是非目一杯使ってください！)

＜3＞チーム視点

QA Unitのチーム体制もプロダクトの実態に合わせ、少しずつ拡大させました。海外ツアーと海外ホテルの2プロダクト体制になり、かつホテルプロダクトを年内リリースするためにはQAリソースがボトルネックになることがわかっていました。フルタイムメンバー（FT）をすぐに増やすことはできませんでしたが、下期の途中から新しくメンバーを増やしました。

私がツアーとホテルを兼務する形でQAリソースのハンドリングとマネジメントを行なった

現在はこんな感じで、少しずつですがQAチームを拡大中です。

実はプロダクトのメンバーからQAがボトルネックになる可能性があるから人手を増やさない？(= テスト会社を検討しないか？)という話をされたことがあったのですが、私の個人的なこだわりとして今はQAチームの内製にこだわりたいと考えています。

QA文化を築いてきたとはいえたったの1年。QA Unitは、『プロダクトをどうしたいか常に考え、領域を定めずお客さまの価値になることはなんでもする』そんな組織でありたいため、こういったマインドセットを外部のテスト会社の方に求めるのはあまりにも難しいと思っているからです。

文化というのは人が波紋させるもので、人の想いに宿るものだと思っています。

特にスタートアップのまだ人数の少ない会社においては、一人一人の発言や行動で組織を良い意味でも悪い意味でも大きく変えてしまう可能性があります。ですので、慎重に採用活動は行っています。逆にいうとエンジニアチームは同じ方向を向いており、非常に優秀なメンバーと共に日々プロダクト開発できていると感じています。

人をただ増やすことで問題を解消するのではなく、少ない人数でパフォーマンスを最大化させる方法は何か？という視点でチームについて考えた下期だった気がします。

とはいえ、開発者が増えればテスト対象も増えるので、メンバーについては積極採用中です。笑

ぜひ興味を思ってくださった方は、まずはお話ししましょう！

mii________san

https://twitter.com/mii________san

＜4＞振り返り

QA Unit下期テーマにおいていたリリース後のインシデント数だけでなく「リリースまでのリードタイムの縮小と高品質を目指すこと」についてですが、数値で振り返ってみると、こちらも上期に続き達成できたと思います。

不具合発生率 ( = 初期品質)

海外ツアー、新規で立ち上げた海外ホテル共に目標としていた初期品質の水準を達成

変更失敗率

リリースしたEpic件数は増える中で、インシデントの発生頻度は目標に掲げていた水準をこえることがなかった（インシデントをゼロにするのではなく、最小限に抑える）
インシデントが発生した際は平均修復時間も計測し、こちらも目標対処時間をこえることはなく被害を最小限に抑えた

上期に比べリリース件数も圧倒的に増えた中で、大きな障害を多発させない状態をキープしながら、プロダクト開発を実現できました。下期は大改修や大きな機能の追加など、プロダクト全体に影響のあるような開発を行なったにもかかわらず、オペレーション含め大きな問題がなく終えられたことは非常に良い結果でした。

最後に

2023年4月。まだまだ旅行には行きづらいこの瞬間に、知名度の低いNEWTというプロダクトを通して”旅行”というかけがえのない体験をしてくださるお客さまがいらっしゃることに感謝しています。

私たちQAエンジニアは、特にカスタマーファーストでなければいけないと思いますし、このマインドセットはNEWTに関わる全員でこれからも変わらない芯として持ち続けていきたいと思っています。そしてその芯がぶれそうな時だけは、攻めではなく守りのQAとしてきちんと方向性を立て直し、羅針盤になれるチームでありたいと考えています。

私たちQA Unitは、プロダクトチームはもちろん、各部門と協業しながらNEWTというプロダクトの品質と向き合ってきました。QAエンジニア、QA Unitが誕生したことで、開発プロセス全体で品質意識が向上したことも実感しますし、QAエンジニアがチームの一員として開発に参加することで、チーム全体の品質に対する意識が高まり、よりお客さまへの価値を考えられる組織にパワーアップしました。

今後もQA Unitでは品質保証に関する活動を継続し、品質向上に貢献していくことを目指します。QA活動は決して100点を取ることのできない悪魔の証明との戦いです。でもだからこそ面白く、奥深い世界です。これからも私たちなりの価値を追求し、みなさまに素敵な旅を届けていきますので、これからもNEWTの成長を見守っていてくださいね。

明日のNEWT 1st ANNIVERSARY CALENDAR はトラベルコンシェルジュチームのゆっきーさんです。4月にフルタイムメンバーとして令和トラベルにジョインしたゆっきーさんの熱い入社エントリをお楽しみに！

令和トラベルでは、現在全力で仲間探しをしていますので、少しでもご興味ある方はぜひ採用ページからご連絡ください。まずは気軽にお話を聞いていただける、ミートアップも開催しています。メンバー全員で温かく迎える準備はできています！

Recruit | 株式会社令和トラベル

私たちは「あたらしい旅行を、デザインする。」というミッションのもと、挑戦を始めました。令和時代を代表するデジタルトラベルエージェンシーとなり、あたらしい旅行体験を提供します。そして、5年以内の上場を目指し、全速力で社会価値を創出していきます。創業メンバーの一員として、大きな変革にチャレンジする仲間を募集しています！