見出し画像

スタートアップ企業にQA組織は必要なのか？

miisan

こんにちは。前回noteを書いてから約3ヶ月がたとうとし、あっという間に2022年も半分を過ぎた事実に震えているmiisanです。

今回は改めて新しい環境での3ヶ月を振り返っていきたいと思います。
前回、幅広い方に拡散していただけたおかげで、「QAエンジニアってなんですか？」と、そんな声も届いたので、今回は「QAエンジニアってなんだろう」という点にも触れながら、この3ヶ月で取り組んできたこと・変化について紹介したいと思います。
※前回の記事は こちら。

QAエンジニアとは

よく「QAエンジニアです」と自己紹介すると、非エンジニアの方やIT企業出身でない方から「Q&Aですか？」と言われる確率が非常に高いです。笑
私が名乗っている「QA」はQuality Assuranceの略で、つまり品質保証という意味です。
と言っても、”品質保証”という言葉すら曖昧なので、わかりやすいようにレストランを例にして、QAエンジニアのお仕事について説明します。
※ここでの解釈は私なりのものになります。テストエンジニアなど細かい違いについても省略します。

QAエンジニアの役割

QAエンジニアは、システムやサービスがお客さまにとってより良いものになっているか検証する役割を担っています。
どういうことかというと、レストランでシェフが料理を作ってそのままお客さまに料理を届けないのと同じように、その料理を本当にお客さまに届けて問題ないか味見してチェックするようなことをQAエンジニアはします。もちろんシェフ自身が味見をしてもいいですが、第三者の視点を入れることによって客観的に料理の出来栄えを判断できます。
ですが、本当にいい料理を届けるために必要なことは、味見をして味の良し悪しを判断するだけでしょうか？

例えば、

  • 美味しい料理を作るためのレシピ研究

  • 食材はどこから取り寄せると作りたい味や料理に近づくのか

  • 配膳までのスピードを適切にコントロールし、美味しいうちに提供する方法を検討する

  • 衛生面やお店の環境は問題ないか

  • 料理の出来栄えは十分なものになっているのか基準や判断を整理する

など、より良い料理の提供につながる活動や改善点を見つけることで、お客さまの満足度を上げることにつながっていきます。
料理だけでなく、環境やプロセスなど全体を良くしていくことでクオリティーは向上します。

つまり、QAエンジニアは味見をするだけの人にとどまらないので、「完成されたプロダクトを最後に触ってみる人」というわけでもないのです。より良い価値の提供につながるような活動や、さらに良くできる点はないか？と全体を俯瞰し見守りながら、チームと一緒にプロダクト開発を行います。

では、実際にQAエンジニアのお仕事としてどんなことを取り組み、料理の味（= プロダクトの品質）を良くしていったのかについて、ここからはNEWTプロダクトに置き換えて説明していきます。

NEWTのQA、3ヶ月間を振り返る

入社して2ヶ月間でどんなことをしたかについては、イベントの登壇資料にまとめたのでここでは割愛します。

この2ヶ月間で感じた課題と取り組みによって、その後どのように変わっていったかについて紹介します。

インシデントとの向き合い方と障害発生の推移

まず入社後すぐにプロダクトのローンチが行われたこともあり、新しい機能の開発と温度感の高い障害が発生した場合、そのどちらも対応しなければいけない状態になることを想定しました。
インシデントが発生した際のフローについては取り決めがありましたが、細かい部分がほぼブラックボックスとなっていました。また、障害がどれくらいの頻度で発生し、その課題の温度感や優先度はどうなっているのか？などもしっかり管理する必要があると考え、インシデントの管理(JIRA)を始めました。

JIRAのダッシュボードの一部

インシデントが起きているのにそのままになっていたら、定期的にチェックインをし、再発防止を促すなどを行いながら、インシデントの振り返りやインシデント発生の傾向から分析し、チームの体制などを見直していきました。

そして新しい機能をリリースする中でも、傾向と対策を考慮しながらプロダクト開発を進めた結果、インシデントの発生数と発生率は大きく軽減されつつあります。

インシデントの発生件数

インシデントの件数が減ると、プロダクトチームは新しい機能の開発に集中することができます。他にも、お問い合わせの件数も減るため、お客さまサポートチームは本来の業務に集中することにもつながります。もし障害の数をコントロールできていなかったら、お客さまの旅行手配業務が止まっていた可能性があったと感じています。
プロダクトの状態が可視化されたことによって、自分達のプロダクトの精度を自分ごと化しやすく、重要な指標として意識付けられます。かつ、インシデントが少ない！という単純な事実はプロダクトチームの大きな成果でもあるので、それがきちんと評価される状態を作り出したいと思っています。（当然、その逆の悪い状態になりそうな時は早めにキャッチして対策を打つこともQAエンジニアの役割です。）

新しい機能を定期的にリリースし続ける

重大障害の発生防止以外に、もう一つプロダクトチームのOKR(目標)として新しい機能(Epic)の定量的な数の目標があります。
当然、数をこなそうとすると、リリースの回数を増やす必要があります。

例えば、単純にEpicの数にだけにフォーカスをあてリリースし続けることはできますが、その引き換えに本番でインシデントが起きるリスクも高まります。結局インシデントが起きれば、着手していたタスクを止めてそちらを優先することになるため、新しい機能の開発に最終的に時間を割けなくなります。短期的に見ると品質を落としてリリース回数を増やした方が機能数を量産して見えますが、長いスパンで見た時の結果はおそらく逆転していると思います。機能をリリースすることと、そこに一定の品質を担保することは両輪で一つのことを体現します。

4月当初は、1つの機能を1週間に1度リリースするくらいのスタートでしたが、現在は1週間に1度のクライアントリリースを実現し、リリースしたいEpicの数やリリース頻度はOKRに掲げたものをほぼ達成しています。
2週間を1つのスプリントとしてサイクルを作っていますが、直近リリースした1つ前のスプリントと直近のスプリントでは対応できたEpicの数は約2倍近く増えており、改善サイクルが回り始めているといえます。
とはいえ、まだまだ改善の余地はあり、QAフェーズにおける不具合検知がやや多い点や、タスクの負荷が集中する期間が固定されていることがあるためそのあたりは改善が必要と考えています。
QAフェーズに見つかる不具合の数が減れば、検証にかかるリードタイムが減るので、より多くの機能をリリースすることやさらにリリースの頻度を上げることもできるはずです。

QAフェーズにおける不具合についても振り返ることができるようにしていて、KPT(振り返り)の場で客観的かつ定量的に振り返ることができるように管理しています。

優先度や不具合要因分類、コンポーネントを管理しているダッシュボードの一部

QAエンジニアは開発者の並走者となり、一緒にプロダクトの実現したいところに向かう役割も担っていると思います。
一見、遠回りに見えることが実際は効果的かつ近道だったりするので、それを客観的に伝えつつ、こういったデータをうまく活用しながらより良い方向に導くということも重要だと考えています。

スタートアップ企業にQA組織は必要なのか？

結局のところ、品質を上げることのメリットってなんなの？といったら、実は"スピードにつながること"だと思っています。
この3ヶ月間の変遷を、品質という定性的要素の強いものから、定量的なものに落とし込んでみて分かったことは、

  • インシデントの発生頻度の大幅な軽減

  • 新機能のリリースの増加

でした。

品質は重要指標になるのか？

個人的には当たり前ですが（笑）、「重要！」と考えています。
特にスタートアップ企業において、スピード感・勢いなどは当たり前のように重要要素になります。例えばプロダクトや機能をリリースしたという事実は社内でも多くの人が注目していますが、そのリリースした機能の精度や積み残したタスクについて最後まで注視している人は前者に比べて少ないです。この差分が増えていけばいくほど、気づいた時には大きな負債となります。
カードタワーの始まりがぐらついたままスタートすると、当然途中でうまくいかなくなったり、突然出来上がっていたものが全て壊れたりするのと同じです。

カードタワー

問題は、小さく早く、適切なタイミングで返していく。この絶妙なバランス感覚は難しいところですが、マイナスサプライズをなくすための情報の見える化と”品質”という曖昧で不確かなものを、いかに定量的に語ることができるかということは非常に大切なことだと思っています。

クオリティーがスピードをつくる

 重複しますが、スタートアップ企業やベンチャー企業ほど、スピード！スピード！！！の色が強いと思われがちですが、個人的には日々新しいプロダクトが生み出され、より洗練されたサービスが提供されるこの時代において、はやさだけを追うことは逆にリスクやデメリットが大きい気がします。

短期決戦の短距離走を挑んでいるわけでなく、このマーケットを変えようとしているような大きな取り組みであればあるほど、遠くを見据えて物事を捉える必要があります。一度離れたお客さまは、別のサービスのファンとなり戻ってくることは少ないからです。

ですが、リソースも資金も大きな企業に比べ劣るスタートアップ企業が優位に立てる部分があるとするならば、それはスピード。Go Fastに意思決定を行い、想いを形にしていく。そしてその想いの粒度をいかに緻密に設計し、より良い状態のアウトプットを届け続けることができるか、が重要だと考えています。

結果的にスピードは重要であり、ですがスピードを作る要素の一つに実は「クオリティー」が大きく寄与しているということを私たちは忘れてはいけません。スピードと品質はトレード・オンできるということです。
例えば、コード品質が実際にどれほどの影響があるかについて定量的に論文にまとめられていたりもします。

高品質なコードは低品質なコードより開発速度が2倍になる

※ https://arxiv-export1.library.cornell.edu/pdf/2203.04374

私はプロダクトのコアローンチ後、どのような感じになるのかを一度経験しているため、すぐに訪れるであろうカオスな状況下を想定できてはいたものの、その中で何ができるかわかりませんでした。ですが、駆け抜けた3ヶ月を振り返ってみると、入社してすぐに作成したロードマップを現時点までは順調に進んでいました。ですがもしかしたら一番は、社内に「品質管理って大事なのかも…??」と気づきを与えることに成功したことが最大の成果かもしれません。

この先は、私もまだ経験したことがないフェーズや山を登ることになると思うので、客観的かつ冷静に考え、引き続きより良いプロダクト・サービスになるようにチームメンバーと一緒に挑戦していきたいと思います！

終わりに

令和トラベルはまだまだ実績も小さく、これから進化していくスタートアップ企業です。会社や事業を大きくし、マーケットの変革とカスタマーへの価値を発揮したいという方は、ぜひ一緒にこの山に挑戦しましょう！
もっともっとやりたいことはありますが、できていないことがたくさんあるので、いつでも仲間を探しています！

イベント情報

令和トラベルでは、定期的に勉強会やイベントを開催予定です！ぜひ興味を持ってくださった方はご参加ください。
※ イベントの主催も私主体で進めていますので、コラボしたい企業様、個人の方がいらっしゃいましたらご連絡ください！毎月イベント開催予定です！

  • 7/13(水) 19:30~ Mobility Technologies x 令和トラベルのコラボイベント

  • 7/20(水) 19:00~ eureka x 令和トラベル x カウシェの3社合同イベント

Meety & Twitter

私個人に興味を持ってくださった方や、令和トラベルに興味を持ってくださった方もいつでもフランクにお話ししましょう！キャリア相談などでも大丈夫です。

また、スタートアップのQAアドバイスや立ち上げなどについて、もしご相談があればTwitterまでご連絡ください。

では今回も最後に、、、

青い海、白い砂浜、夏が近づいてます。久しぶりの海外旅行は、ぜひNEWTで！

最後までご覧いただき、本当にありがとうございます！Have a nice trip!!


この記事が気に入ったらサポートをしてみませんか？