【Developers Summit 2025】スタートアップ1人目QAエンジニアがゼロからはじめた品質活動の軌跡と話しきれなかったこぼれ話

はじめに

こんにちは。令和トラベルのQAエンジニア 兼 エンジニアリングマネージャーの miisan です！

2025年2月13日（木）にホテル雅叙園東京で開催された「Developers Summit（デブサミ）2025」にセッション登壇させていただきました！
現地でセッションにご参加いただきました皆様、運営の皆様、ありがとうございました！

この記事では、セッション内では話しきれなかったことや、セッション後のAsk the Speakerでいただいた質問や過去さまざまな場面で質問されてきたような疑問に対してせっかくなので残しておきたいと思います。

「Developers Summit（デブサミ）2025」の会場の様子や各セッションなどについては、こちらのイベントレポートで紹介しています。
https://engineering.reiwatravel.co.jp/blog/devsumi-2025

Developers Summit 2025について

開催概要

• 今回のテーマ：ひろがるエンジニアリング
• 日程：2025年2月13日（木）- 2月14日（金）
• 場所：ホテル雅叙園東京
• タイムテーブル：こちら

スタートアップ1人目QAエンジニアがQAチームを立ち上げ、“個”からチーム、そして“組織”に成長するまで

• セッションタイトル：スタートアップ1人目QAエンジニアがQAチームを立ち上げ、“個”からチーム、そして“組織”に成長するまで
• セッション詳細：こちら

当日の発表スライドはこちら

https://speakerdeck.com/mii3king/how-to-set-up-qa-team-at-reiwatravel

"個"からはじめる

当時の状況

私が入社した当時、エンジニア10名の中に初めての「QAエンジニア」として参画し、QAチームの立ち上げと品質文化の推進というミッションを担うことになりました。当時は、インターン生やPMがテストを行うような状況で、QA体制は整っていませんでした。
2022年4月、私が入社した当時の令和トラベルは、コアプロダクトのローンチを目前に控えていました。ですが、仕様書やリリースサイクル、QAプロセスといった基本的な品質管理の仕組みも存在しない状態でリリースに臨もうとしていました。

最初の試練

コアローンチ後、初めての新規機能となる銀行振込機能のリリースでは、重大なインシデントを経験しました。さらに開発に多くの時間を費やし、生産性も悪い状態でした。にもかかわらず、私はプロダクト開発の方向性として「品質とスピードのトレード・オン」を掲げました。

主な取り組みと結果

• 定量的な目標設定と認識の統一
• JIRAを導入した状況の可視化
• 可視化した情報をもとに、KPTにてボトルネックを改善
• インシデントフローやルールを策定し、発生時にはポストモーテムの実施及び恒久対策による仕組みによる解決を実施
• リリーストレインを確立し、リリースサイクルを定着化させる

これらの取り組みの結果、半年間で障害発生率は安定化し、2週間に1度の安定したリリースサイクルを確立することができました。

"チーム"になる

チームフェーズの変化

プロダクト開発チームは20名に拡大することになり、かつプロダクトも「海外ツアー」「海外ホテル」「基幹システム」「旅行ガイド」と広がっていきました。
そういった変化に対応するために、2人目のQAエンジニアを採用したり、チームとしてのパフォーマンス向上に重点を置くようになりました。

主な取り組み

標準化を進めることで、属人化していたものをチームで共有できるようにしました。テストパターンのマトリクス表や設計書を標準化したり、ドキュメント文化がうまく持続できるように運用プロセスを回していきました。
また、チームメンバーの育成にも力を入れ、将来を見据えた長期的な視点でチーム力の向上を目指しました。

"組織"になる

組織フェーズの変化

プロダクト開発チームは40名という規模に成長し、日々の開発サイクルもミッション別の少数チーム構成へと進化していきます。
QAメンバーも6名にまで拡大し「組織」と呼べる状態に変わっていきました。

主な取り組み

スケールアウトできる状態を目指し、開発に伴う基盤を大きく変えました。

• テスト環境
  • Staging環境1つから複数テスト環境を立ち上げ、並行したQA業務を可能な状態に
• リリースサイクル
  • 週1回から随時チームごとに品質保証ができたらリリース可能な体制へ

また、技術課題への対応をTech Leadのメンバーと相談しながら、技術負債と向き合い、スピードや品質を毀損する前に問題を最小化できるように取り組んだり、専門性を活かしたチームや文化を持続させるための組織運営にも取り組んでいきました。

学びとこぼれ話

わたしの学び

1. “現実”を受け止めることから始める

• 曖昧な状況や自分の”感覚”だけでは、組織を動かしたり、人を巻き込むことはできない
• 「なんか品質が悪いかも...」というぼやきは、体感でしかなく、人それぞれの感覚
• 目線や状況の共通認識を作ることで、人を巻き込みやすい状況を作り出せる

2. Fail Fast, Learn Fast

• 1人の時は全ての行動に対する良いも悪いも自分に跳ね返ってくる
• 1人だからこそ、たくさんの機会が与えられるメリットを最大活用し、たくさん新しい挑戦をして、たくさん失敗し、すぐにその結果を次の日に活かす

3. クイックウィンを目指す

• 将来的には変化に寛容な組織でありたいと思っていたが、変化を起こす自分も辛いし、周りはもっとストレス
• そのストレスに抗うためにはどうしても明確な成果が必要だった
• ポジティブな変化を作るために、早期に結果を作り出すことが非常に重要だった
• 成果とはつまり"信頼"

1. 再現性を意識する

• 人が増えたからといって、それだけでできることが2倍になったり、できることが爆増するってことにはつながらない
• むしろ、人が増えることによってできなくなることがあったりする
• 変化に左右されない仕組みを作り、きちんと継続的にプロダクト価値を提供できる再現性を意識する必要であり、フェーズに合わせて作り変えていく柔軟性も必要だった

2. 遠回りすることを受け入れる

• 自分がやってしまったらはやいことって、マネージャーをやっていると実は感覚的にわかるものがある。でも、将来的なことまで見据えた時、一歩引くことや、あえてトライしてもらって、私がそうであったように失敗から学んでもらうということも重要だった
• 個人の力に依存せず、チームでいかに乗り越えていけるか？にフォーカスをあてると、困難への乗り越え方には種類があると知った
• そうした経験を乗り越えることによってチーム力は引き上がっていた

3. QAエンジニアの“居場所”を作ること

• スタートアップでQAチームを内製で拡大することは意外と難しく、QA組織の存在はあたりまえでない
• そうした時、QAエンジニアが事業やプロダクトに価値提供できることを証明し続けるというのがすごく難しいことではあるが、意識しなければいけないこと
• QA文化に投資してもらえるように、きちんとQAエンジニアの活動が評価される状態を作ることを意識したチームの取り組みを考えていた

1. 1人ではできないことが叶っていく

• 1人でできないことでも、実現されていく
• さらにQAチームだけでも実現できないことができることがあって、それはQA文化によるものだと思う

2. 「私 (あなた)」がいなくても大丈夫

• “個人”に依存するとそれが組織の限界になるという怖さ
• 「QAメンバーがいるから大丈夫」という安心感を持ってもらえる振る舞いはすべきだけど、「QAがいるから大丈夫」と丸投げされる状態は目指したい方向性と違う
• 組織としては「自分がいなくても」「誰かがいなくても回る」状態を作り出すことを目指しながら、個人としては「それでも、私がやらなきゃいけない、いなければ始まらないんだ」みたいな責任感を持って目の前の課題に取り組む

番外編) こぼれ話

これまでさまざまな場面で質問されてきたような疑問に対してせっかくなので、残しておきます。
質問をくださった方の個別事情などは特定されないように、抽象度を上げ執筆しています。

QA組織を作る時に、意識すべきことはなんですか？

※質問者様はEMをされている方でしたので、少し組織的目線で回答させてだきました。

どんな会社のどんなフェーズで、どんな背景でQA組織を作ろうといたったのかがわからないので、一概には言えませんが、「QA組織」を新たに社内に作る場合、その価値や評価をどうしたら良いのか？という観点が意外と見落としがちになると思っています。

まずQA組織を作ろうとするのならば、QAエンジニアに期待することはなにか言語化してみるのはどうでしょうか。
「問題が最近増えている気がするからQAエンジニアに任せたい！」「品質について考えることはプロダクト開発において大事そう。でもわからないから専門家に託したい！」などなど、期待することはそれぞれのはずです。

• 今起きている問題を解決してほしいのか？
• 一緒に問題を見つけながら並走してほしいのか？
• 自分たちの開発に対してよりよい品質改善案を提案してほしいのか？
• これからの投資？

「QAエンジニア」といってもその解釈や個々人でもやれることはさまざまです。

求める要件によって、QA組織への期待役割も当然変わりますし、採用要件も変わります。
まずは、なぜQA組織が必要なのか、考えてみてはいかがでしょうか。

2人目QAエンジニアに求めてたことはなんですか？

私の場合、と捉えていただけると幸いです。

大前提、背中を任せられる人であることは重要なポイントでした。
さらにそれを分解していくと、

• 思考性、マインドセットがある程度自分と近いこと

  • 考え方が根本的に違うと、辿り着きたいゴールも変わってしまうので、考え方や向き合いたいと思う”コト”がなにかは重視していました

• スキルセットとしては私の得意領域の円と被る領域が多そうな人であること

  • 得意なことから自分から引き剥がしていく、ということをしました
  • なぜなら得意領域であれば、何かあっても絶対に助けられると思っていたからです
  • 常に半歩先の挑戦機会を本人には渡すことで、将来的にはできる幅を拡張してもらいたかったのですが、それでできなかった時のプロジェクト側へのインパクトを考えると、自分をバッファとして余白を持たせることによってメンバーの挑戦と組織の成長を両立できるようにしておきたかったという背景があります

• ゼロイチだけではなく、プロダクトの成長に喜びを感じられる人であること

  • ゼロイチはいずれ終わります
  • ゼロイチだけにこだわるのではなく、プロダクトや事業そのものの成長に向き合えること、そのフェーズごとに重要と思えるミッションを自分ごと化できる視点を持てる人であるかどうかという点も大切にしていました

より大きな範囲に関わっていきたいですが、テスト工程しか携われないです。どうしたらより広範囲に関わっていけますか？

個人的に色々な環境での染み出し方で共通している部分をシェアしてみます。

大きくは2つあり、小さく信頼関係を作ること。そして、これまでの歴史を否定しないこと、尊重することです。
大前提として、責任範囲を広げるためには、任せてもらえる人にならないといけません。

この人が言うならいいかな〜と思ってもらうためには、信頼関係を勝ち取っていくしかありません。
そしてそれは、大きな取り組みではなく、むしろ足元にある小さな困りごとや誰のものでもない名もなきタスクを拾い上げるだったり、そういう日々のなんてことない積み重ねにあったりします。

まずは今あるプロセスやあり方の中で、完璧にこなしていく。
やってみた結果、ここをこう変えたらこんなことになると思うんだけどどう思う？など相談してみると、案外「そこは昔の名残で残っていただけで」なんて背景を教えてくれたりします。

いまあることって必ず背景となる積み上げてきた歴史があるのです。
それをいきなり変える！ってなっても、そりゃあ元々いた人たちには嫌な顔をされます。

まずは自分が任された範囲で、周りの期待値を超える。
与えられた役割をきっちりやりきれない人には次のチャンスは来ないと私は思っているので、まずは与えられたミッションに真摯に向き合うことから始めるのはどうですか？と思います。

それでも環境的な制約によってチャレンジできない場合もあり、やはりそれは自分と会社とのすり合わせがマッチしていないことになるので、環境を変えるということも一つの選択肢になるのだと思います。

チームを巻き込んだ大きな意思決定や変化を作るのが怖いです。勇気をください。

私も怖いです。
というか、以前よりその感覚は年々増していっています。ずっと、もっと怖い。
動かす規模、組織が大きくなればなるほど責任は重い。

でもこの勘所は実体験からしか培うことができないものかもしれません。意思決定をした人にしかわからないことが間違いなくあるということを知りました。
机上の空論なんて言葉がありますが、想像したものが現実でその通りに進むなんてことは残念なことに少なく、実行の伴わない意思決定をどれだけ繰り返しても、自信を引き出すものにならないような気がします。

私が大事にしていたことは、意思決定の機会を誰かに譲らないということです。
自分の意見を持って、自信を持って意見するということは練習する中で慣れていきました。
たくさんの人が参加しているディスカッションの中で、私は飛び込んで意見することがいまだに苦手だし、あまりできないのですが、自分の意思決定を揺るがす瞬間だけはボールを譲らないようにしています。

ですので、最後の意思決定を上長に託すのはとてももったいないことです。
「XXXってどう思いますか？」ではなく、「XXXをしたいです。なぜならば〜」と話すだけで、コミュニケーションのあり方は少し変わったりします。
何か明らかな問題があればきっと周りの人はフィードバックをくれるでしょうし、上長の仕事の一つに、あなたの行動の結果責任を負うことも含まれます。報連相をしっかりできていれば、「任せた！」と言われた時点で、自由にやってなんぼです！

とにかくどれだけ小さなことであっても良いので、まずは意思決定する癖をつけるといいと思います。
小さくトライして、素早く意思決定し、間違えたら軌道修正する。
不可逆なもの以外は、それでいいのではないでしょうか。
大抵のことは不確実であり、どんな意思決定をしてもどこかからは批判は届きます。
決めたら、あとはやり切るしかないです。

また、現実は常に変化するものなので、「間違ってた！すまん！」という姿勢も忘れず、一度行った意思決定もアップデート、軌道修正が必要です。

そして周りの人たちも意思決定をした人に寛容でありましょう。常に先陣を切って物事を進めている人は大きな重圧と戦っているからです。
少なくとも私は挑戦する人に寛容でありたいです。必ず、皆さんの環境にも1人は寄り添おうと向き合ってくれる人がいるはずです。安心して意思決定してみてください。お互い頑張りましょう。

おわりに

この記事を読んで、なんかうまくいってそう〜と思いましたか？笑
確かにさまざまな困難を私たちは乗り越えてきました。

ですが、開発組織は倍々に拡大しており、嬉しいことに事業も急成長しており、毎日成長痛で節々が痛いです。

ただ、マイナスをゼロに変えていくとか、そもそも品質活動ってのはね・・・みたいな前段を省くことができる環境にはなりつつあると思っているので、そういった意味では私はここから第二章を始められると思っています。

まだ『NEWT（ニュート）』はまったく完成していないプロダクトですし、今後事業の核となる新たな事業軸をまさに作ろうとしています。
これまでもそうであったように、これからも変わらずカオスであり、常に苦しい意思決定を迫られると思います。
それでもプロダクト品質に向き合ってきた私たちは、次のフェーズにいけるはずです。

旅とはオフラインの体験そのものにこそ価値がある。
だからこそ、私はサービス品質そのものに向き合っていきたいと思っています。

まだ前例をあまり見かけないので、どうやって進んでいったらいいのかしら？と思っているのですが、スタートアップ1人目QAエンジニアとして、組織もプロダクトもスケールさせることができ、1つのモデルケース（今日参加者の方にいってもらったのでそう言わせてください！笑）を作れた今、次の新しい事例を作りたいと思います。

ぜひこれからのNEWTにご期待ください！！！

https://newt.net/sale

令和トラベルでは一緒に働く仲間を募集しています

会社やプロダクトについて興味を持ってくれた方は、ぜひご連絡お待ちしています！お気軽にお問い合わせください！
フランクに話だけでも聞きたいという方は、カジュアル面談も実施できますので、お気軽にお声がけください。
一緒にあたらしい品質保証のあり方を考えていきましょう🤝 お待ちしてます！！！

https://www.reiwatravel.co.jp/engineers

また令和トラベルでは、技術的な知識や知見・成果を共有するLT会を毎月実施しています。発表テーマや令和トラベルに興味をお持ちいただいた方は、誰でも気軽に参加いただけます。
次回は、「プロダクトデザイナーが語るPMスキルを融合させた実務アプローチ」をテーマに、開催予定です。
QAエンジニアだけでなくさまざまな職能を持ったメンバーが越境をあたり前にプロダクトに向き合っています。オフィスとオンラインのハイブリット開催となりますので、ぜひご参加してみてください！

https://reiwatravel.connpass.com/event/342958/