半年でやりきった、最初の一歩
miisanがまず取り組んだのは、「良い品質とは何か？」をチームで定義し、共通認識として整えることだった。品質は曖昧な概念であり、価値観の差が判断を曇らせやすい。そこを揃えることで、ようやく改善の起点に立つことができた。
次に着手したのが状況の可視化だ。当時の社内はコミュニケーションが活発なだけに、新機能の開発においても、「『話せばなんとかなる』スタイルだった」とmiisanは話す。いかにもスタートアップらしい空気感ではあるが、口頭ベースのやり取りでは情報が属人的になってしまう。そこでJIRAを導入し、タスクを整理しながらスクラム体制を整備。運用ルールを設け、継続的な改善が回る仕組みを築いていった。
このような可視化を進めるなかで、振り返りの場でもKPTなどを通じて、具体的な課題やボトルネックが見えるようになってきた。そこからは、「次のスプリントで何をするか？」という建設的な議論も生まれていった。
一方で、どれだけ体制を整えてもインシデントをゼロにするのは極めて難しい。そもそも必要なのは継続的なデリバリー。インシデントゼロを目指すのではなく、miisanは、「万が一、インシデントが発生したらどうするか？」について、フローやマインドセットをマニュアル化して全社に展開。組織全体で品質リスクに備える文化をつくっていった。
さらには、開発サイクルにもメスを入れていく。当時は「とりあえず出す」が前提で、誰が何を担当しているのかが不明瞭なままリリースが進んでいた。これを変えるために設計したのが、2週間ごとのリリースを前提とした「リリーストレイン」だ。これによりスケジュールと責任が明確化され、安定的な開発サイクルが根づいていった。
一連の取り組みにより、チームはわずか半年で大きく変貌を遂げた。銀行口座番号を誤って公開するという致命的なインシデントを経験したチームが、2週間に一度の安定したリリースを実現するまでに成長したのだ。重大インシデントも結果的にゼロに抑えることができた。
このフェーズでmiisanが得た学びは3つある。
1つは、現実を正しく見つめること。品質は人によって捉え方が異なるからこそ、チーム内で共通の「事実」をベースにする必要がある。感覚に頼らない議論が、組織的な改善の出発点になる。
2つ目は、一人であることの強み。すべての課題を自分で解くしかない状況は、挑戦の連続だった。失敗も含めて経験を積み重ねることで、miisan自身のスキルも飛躍的に伸びていった。
そして3つ目は、クイックウィンを意識することだった。「変化に巻き込まれている側は、どうしてもストレスを感じてしまう。それをネガティブな感情に変えないために、『変化した結果、何が良くなったのか』を可視化し、納得感を提供することを強く意識した」（miisan）。重大インシデントゼロやリリースの安定化といった成果は、その象徴だと言えるだろう。
miisanは、どんな改善施策でも「半年以内に成果が見える状態」を目指していたと話す。このスピード感が信頼を生み、チームとの関係を築く原動力となった。
急成長にも対応できるチームへ
土台が固まったところで、次にmiisanが取り組んだのは、「チームになっていく」ための体制づくりだった。
この頃、開発チームは10人から一気に20人へと倍増し、QAチームとしても2人体制に拡大。一方で、プロダクトの軸も増え、Webとアプリの両方への対応が求められるようになっただけでなく、新たに海外ホテル事業や旅行ガイド機能の開発もスタート。領域の急拡大に合わせて、開発体制もワンチームから複数チーム体制へと移行していった。
「ビジネスが拡大するにつれ、自分のロールもQAだけでなくPMやエンジニアリングマネージャー、PR（広報）活動などへと広がっていった。これは無理だ、採用を進めなければということで、人数が増えても回るチームを作ることに注力していった」（miisan）
採用にあたって重視したのは、「信頼して任せられるかどうか」と「この環境を楽しめるかどうか」だ。まだまだ混沌としたフェーズであり、スキル以上にスタンスやマインドセットが重要だというのが、当時のmiisanの考え方だった。一方で、その先のスケールフェーズも見据え、「ゼロイチの立ち上げだけでなく、ビジネスが軌道に乗った“後”にも価値を発揮できるかか、サービスを一緒に育てていけるかどうかを慎重に見ていた」という。
採用活動と同時に、開発組織のスケールアップに対応するための基盤づくりにも着手していった。実施したのは、ナレッジとプロセスの標準化。QAチームが持つ知見をドキュメント化し、PMやデザイナーなど他の職種でも参照できるように整備した。また、チーム内で得意・不得意や担当領域に差があったことに鑑み、対応範囲を明確に整理し、標準化を進めることで、チームとしてのパフォーマンスを安定させていった。
このフェーズでmiisanが得た学びは、3つある。
1つ目は、「再現性を意識する」ことだ。事業の成長とともに変化は必ず起きる。そのたびにやり方を一から作り直すのではなく、変化を前提とした仕組みを整えることで、チームとして安定したパフォーマンスを維持できる。
2つ目は、「遠回りを覚える」こと。マネージャーとして、自分がやればすぐ終わるのにと焦る気持ちになる場面は誰しもある。「そこをあえて任せることで、メンバーが挑戦と失敗を繰り返し、自分で乗り越える力を身につけてもらいたかった」。その積み重ねが、チームとしての底力につながっていった。
3つ目は、「QAエンジニアの居場所をつくる」ことだ。スタートアップでQAチームを内製化し、さらに拡大していく体制は、まだ一般的とは言いがたい。だからこそ、miisanは事業KPIへの貢献を明確にし、QAの存在価値を可視化することを意識した。さらに、QAエンジニア個々の成果がきちんと評価されるよう、機会を用意し、成果として形に残すことにも取り組んでいった。
