こんにちはこんばんは。
hacomono QAのpiro（@pirori_Qin）です。
気温と気圧の変化が激しくなってきました。
花粉との戦いが終わったと思ったら、次は自律神経との戦いです。
人生とは戦いの連続ですね。
新規事業 × QAの挑戦 —QAに求められる役割の変革
株式会社hacomonoは、3月上旬に初のtoCサービスである”FitFits”をリリースしました。
このプロジェクトが立ち上がってからリリースまでの1年半の間、
私がこのプロジェクトの品質保証を担当しました。
新規事業かつtoC、そしてモバイルアプリという、私にとっても初めてだらけのことでした。
その過程で自分がどのように考え、動き、品質を実現してきたのかについて語ろうと思います。
このブログのターゲット
- 新規事業の品質保証を担当されている方
- モバイルアプリの品質保証を担当されている方
（注記）
このブログの内容は、JaSST’26 Tokyoのhacomonoスポンサーセッション
『新規事業×QAの挑戦：不確実性を乗りこなす！フェーズごとに求められるQAの役割変革』
にて発表した内容に加筆を加えてブログ化したものになります。
発表で利用したスライドを一部流用しています。
スライドの全体はこちら（speakerdec）にまとまっていますので、ご参照ください。
FitFitsプロジェクトについて
FitFitsとは
今年の3月にグランドローンチを迎えた、hacomono初のtoCサービスです。
簡単に説明すると、”フィットネス施設の都度利用プラットフォームアプリ”であり、
「やりたいことを毎回選べるフィットネスマーケット」というコンセプトのサービスです。
1つのジムの月額会員として契約するのではなく、その日の気分に合わせて、アプリに掲載されている様々な種類の店舗を予約し、都度利用できます。
マシンやダンベルがあるようないわゆるトレーニングジムだけでなく、パーソナルトレーニングやマッサージ、サウナ、ゴルフなど、皆さんの健康に関わる多様な施設を掲載しています。
開発体制
アプリだけでなく、Web版やフィットネス施設が使うサイト、hacomonoの運営サイドが使うサイトなどの関連サービスが存在し、領域別・職能別に分かれた約20名のチームです。
QAは私を含めた2名で、全てのプロダクトの品質保証を担当していました。
開発プロセス
1つのボードで全チームのタスク管理を行い、1週間に1度のリリースサイクルで、開発が終わったものから出していくというイテレーティブ型の開発フローを採用していました。
QAはなるべく全工程で品質保証活動を行い、プロダクトリスク、プロジェクトリスクの両方を排除するように動きました。
また、開発サイクルとは別に、エスカレーション対応やβ版の社内フィードバックの分析、プロセス改善なども行いました。
フェーズ毎のQAの動き方
新規事業の初期からQAとして参画をしていて、何をしていたのか？
プロジェクトの立ち上げからグランドローンチまでをフェーズに分けて説明します。
立ち上げ
立ち上げ当初、このプロジェクトは開発2名と、PdM、デザイナー、QA1名というミニマムな体制
かつtoCサービスとビジネスモデルだけが決まっているという状態でスタートしました。
プロダクトの方針を立てるため、キックオフの翌日にオフラインで集まってユーザーストーリーマッピングを行い、このサービスで実現したい基本的な価値について定義しました。そこからまずは作ってみよう！ということで、それらを基に最初の半年間で、プロダクトの骨組みとなるα版を作成していきました。
進行していくにつれ、プロジェクト上の課題も見えてきました。
1つは、意思決定にかなりコストがかかったこと。
動かせるものも、仕様もUXもベースとなるペルソナやマーケティング施策も全て0から自分たちで組み上げ、その全てが仮説で、何が正解なのかを誰も知らない。仮説を進化させていく過程で、昨日決めたことが簡単に覆る。新規事業は暗い嵐の中を進んでいくようでした。
もう1つは、コミュニケーションの壁。
当時はバックエンドチームとモバイルチームがそれぞれタスク管理方法や会議体がバラバラで、
互いの進捗が見えずに結合フェーズでの認識齟齬が頻発しました。
hacomonoがフルリモートということも拍車をかけており、どこかで誰かが口頭で話して決定したことがドキュメント化されていない、共有されていないということも多くありました。
⭐️このフェーズでのQAの役割
こうした状況からこのフェーズでは、
QAはプロダクト自体よりもプロジェクトのカオスさにフォーカスし、そちらを改善できるように動きました。
日々更新され続ける情報をとにかくオープンにして、共通認識を作りに行く。
具体的には、ドキュメンテーションやメンバー個別との会話、
連携がうまくいってなさそうなところに情報を渡しに行く、などの動きをしていました。
β版（社内利用）リリースまで
α版から、hacomono社員の試験的な利用向けのβ版リリースまでに2つのイベントがありました。
1つは、SPORTECという健康産業に関する総合展示会で、FitFitsのサービスを世の中に初お披露目したことです。私にとってこのイベントは、1つの転換点でした。
α版の段階では、自分たちの作った仮説が正解か分からず、正直本当にこのサービスでいけるのか？という確信が私自身持てていなかったのです。
しかし、セールスの方々に混じって、案内スタッフとして私もビラを配ったり、サービスの説明をしたりしていると、店舗側からもユーザー側からも、両方から期待の声をいただくことが多く、希望が見えてモチベーションが爆上がりしました。
ビジネス仮説の論拠として、また、モノを作るモチベーションとして、
実際のユーザーやユーザーになると想定している方々からの生の声に勝るものはないと感じました。
もう1つのイベントは、新たなQAメンバーの参画です。
プロダクトが徐々に肉付けされていき、これまでのプロジェクトリスク解決と並行して製品の品質向上も本格化していき、拾わなければいけないボールが多かったため、人を増やすことにしました。
このタイミングで、hacomono QAメンバーであるakineさん（@poyogrep）が新たにチームに加わりました。
当時はhacomonoに入社して間もない頃で、新規事業のこのフェーズに参画することも初めてという状況でした。
最初はプロダクトの品質向上もとい、出来上がった機能のテストを中心にお願いしていましたが、
akineさん自身がプロジェクトの課題を積極的に拾う動きをしてくれたので、2人で自律的に品質に影響するリスクを拾っていきました。
具体的には、β版利用で体験した社員からのフィードバック収集や、エスカレーション・インシデント対応体制の整備などです。また、関わる範囲もより広くなり、ビジネスメンバーとプロダクトやマーケティング戦略について会話する時間も増えました。
⭐️このフェーズでのQAの役割
プロダクトの方向性やUXが徐々に固まっていき、スケジュールや品質の着地点も見通しが立ってくるフェーズでした。
ここからはプロダクト自体の品質も勿論のこと、品質に影響するリスクを取りこぼさないよう、リリースプロセスやブランチ戦略、インシデント発生時の対応フロー、負荷試験、スケジュールリスク、プロダクトの細かい仕様の意思決定などなど、舵取りしつつ他メンバーと連携して進めました。
私はこの頃の自分のことを「叩き台作るマン」と呼んでいます。
落ちているボールをとにかく拾って、チームの持ち物にしていく、そういった動きでリスクを1つ1つ潰していきました。
グランドローンチまで
β版のフィードバックを踏まえ、いよいよ大詰めです。
グランドローンチのタイミングで何をどこまでやるか？品質をどこまで追求するか？が命題になってきました。
プロダクトとして出来上がってくる部分も多く、実際にプロダクトを触って行うテストはこのタイミングに集中しました。テスト以外にもやるべきことが多くある中、何をやるか、そして何をやらないかをQA2人でじっくり話しながら進めました。
ここまでプロジェクト上で越境して築いてきた信頼関係によって、チームでの期待値も少し変わったように感じました。インシデント発生時の指揮役や、開発エスカレーション対応、ビジネスメンバーから直接仕様について聞かれることもありました。ここも1つの役割変化だと感じました。
⭐️このフェーズでのQAの役割
グランドローンチ直前、プロダクトの品質の追求にフォーカスを当てながらも、
どうしても疎かにしがちな、ローンチ後の話もしていきました。
グランドローンチからは落とす要件をいつやるのか、
ローンチ後のリリースフローはどうするのか、
運用フェーズの品質保証はどういう方針でやるのかなど。
チームがグランドローンチに真っ直ぐ突き進むのに並走しながらも、
ローンチよりもう少し先のことを見据えたり、依然としてあったチームの課題を拾ったり、
客観的な視点も持っていました。
これから
運用フェーズで見えてきた課題
グランドローンチ後の運用フェーズで見えてきた課題についても触れておきます。
- スプリントの運用
1週間を1スプリントとするイテレーティブ開発を行なっていますが、運用上の課題が多くあります。
直近では、プランニングで積んだチケットが1週間でちゃんとリリースされずに残っていたり、
テストがギリギリになりすぎて不具合の検出が遅れたり、振り返りで出たネクストアクションに中々着手できておらず改善が進まなかったりなど。
今はプロダクトのUXをどう改善していくかを最優先で進めてはいますが、
これらの課題についても小さな改善を重ねていっています。
- リグレッションテスト
週1回のサイクルでリリースを行なっていますが、現状はリグレッションテストをQAがほぼ手動で行なっています。今はサービス全体が小さめですが、それでも1人日程度はかかっており、この先機能が増えるにつれ、かかるコストもさらに増えていくと予想されます。
そこで、リグレッションテストをいつでも誰でも実行できるような仕組み化が必要だと考えています。
テストの属人性排除や価値提供のスピードアップなど、様々な改善施策に貢献する取り組みです。
特にスマホアプリのテスト自動化は我々としても初の試みですが、
AppiumやMaestroなどのツールを試しながら進めています。
- データ駆動での品質保証
toCサービスは、1人1人の顧客からフィードバックを収集するのがtoBよりも難しいように思います。
自分たちが立てた仮説が正しいのか、ユーザーにとってはどのような体験になっているのかを正しく分析し、プロダクトの改善に取り込むために、データを元にした品質保証をやっていかなければならないと考えています。
データアナリストやビジネスと協力し、UX上何がボトルネックになっているのか？
どこを改善すればより大きな価値提供ができるのかを分析し、品質を高めたいと思っています。
プロジェクトを通して
実際に新規事象のQAをやった体験談を、QAの役割変革というテーマを軸に書いてみました。
私のQAエンジニア人生においても、とても学びのあるプロジェクトだったと思います。
締めとして、それらをまとめておこうと思います。
- 品質というものは多面的で流動的である
我々の仕事は製品のバグを0にすることだ！と言えたら良いのですが、そんな単純なものでは到底ないということを再認識しました。
製品自体だけでなく、プロジェクト、プロセス、チーム構成、コミュニケーション、雰囲気などなど…たくさんの要素が品質に影響を与えているので、QAの見るべき範囲もそれだけ広いということです。
- QAの仕事の本質は「改善」
プロダクトもプロジェクトも「改善」を繰り返し推し進めるのがQAの役割だと思います。
何が原因でどこが悪くなっているか、深く観察し洞察する力、
それを解決するために道筋立てて計画する力、
それを実際に実行する行動力。
AIでは再現できない、技術や知識よりも根底にあるこういった力が今のQAには求められるのではないかと感じています。
- 信頼関係の大切さ
プロジェクト品質に向き合う時間が多かったですが、インプロセスQAとしては、
「この人がいるとなんか仕事しやすい」というのを目指したいなと今は思っています。
QAはテストをやってくれる人、みたいな固定観念はありがちですが、
それを打破して信頼関係を築いていくために、越境し行動していく必要があると思います。
おわりに
ここまで読んでくださりありがとうございました！
最も伝えたいことを最後に書いておきます。
みなさん、普段から運動してますか？
健康になりたいと思うことは誰にとっても当たり前なのに、
健康になるために運動することが当たり前にならないのは、
そこに圧倒的なハードルが存在するからです。
お金がかかる、通いたいジムが遠い、どこへ行けばいいのか分からない
運動する時間がない…など。
そういったハードルをなるべく低くして、運動人口を引き上げよう！日本に住むすべての人たちを健康にしよう！といった思いを形にしたのがこのFitFitsというサービスです。
魂込めて品質保証しました。是非とも利用してみてほしいです！
📖関連記事
