2024.07.01
様々な現場でQA業務に携わっている方々の「声」をお届けする『隣のQAに聞く！』。
社会のデジタル化が推進され、QA・品質向上の重要性がますます増している現在、他のチームでは、どのようにQA業務が行われているか、気になっているエンジニアの方も多いと思います。
日本の商業用不動産DXをリードする株式会社estie（エスティ）は、「産業の真価を、さらに拓く。」 をパーパスに掲げ、商業用不動産業界が抱えるデータ流通の課題をデジタル化により解決し、業界の取引を円滑にするサービスを提供しています。
また、2024年3月にデロイトトーマツが発表したテクノロジー企業成長率ランキング「Technology Fast 50 2023 Japan」にも選出された、今注目の企業でもあります。
そこで今回は、成長率398.1%を記録した企業でQAとして働く粕谷恭平さんに、QAのミッションや社内の専属QA1名で工夫しているポイントをお話しいただきました。
今回インタビューを受けてくださった方
- 粕谷 恭平 氏
株式会社estie QA Engineer
前職では不動産業界で賃貸仲介、収益不動産売買を6年ほど経験。プライベートでプログラミングを学習しており、前職のドメイン知識を活かし、2021年6月にQAエンジニアとして不動産テックのestieにジョイン。趣味は筋トレであだ名はmacho。
- もくじ
1．未経験からQAエンジニアの1人目として入社
――現職についた経緯やこれまでの経歴を教えてください。
株式会社estieに入社する前は、不動産関係の会社に数社在籍していました。主に賃貸仲介と収益不動産の仕入れ、販売業務などを経験しています。
不動産の営業をする傍ら、趣味でプログラミングの学習をしたのがきっかけで、IT業界にキャリアチェンジしたいと考えるようになりました。
前職で培った知識が少しでも生きる会社があれば、と思っていたときに出会ったのが、不動産×ITの株式会社estieです。
――もともとQAエンジニアを目指していたのですか？
最初はソフトウェアエンジニアを志望していました。しかしCTOの岩成とカジュアル面談した際に「QAエンジニアという仕事は不動産のドメイン知識も生かせるよ」と提案してもらったのがきっかけで、QAエンジニアの存在を知りました。estieの在籍歴イコールQA歴になり、ちょうど今年で3年目になります。
――未経験からQAエンジニアに転職するのは苦労したのではないでしょうか。
私は未経験かつ社内では1人目となるQAエンジニアとして入社したので、「テストとは」「品質とは」みたいなものを知らない状態でした。しかし、CTOの岩成がQAエンジニアの重要性を社内に周知してくれたおかげで受け入れてもらいやすかったのを覚えています。
2. 日本の不動産市場をデータとITの力でアップデート
――御社の事業・サービスについて教えてください。
株式会社estieは商業用不動産と呼ばれるBtoBの不動産業界を対象としたソフトウェア、いわゆるバーティカルSaaSを提供する不動産テックの企業です。
「産業の真価を、さらに拓く。」というパーパスを掲げて、人間が生産活動を行う上で必要となる、商業用不動産のデータや業務インフラを構築することで、集積する企業の生産性を向上させるほか、強い都市地域作りと発展し続ける経済の基礎を支えることを目指しています。
また、弊社はコンパウンドスタートアップ(※1)を志向しており、商業用不動産領域の複数のサービス開発を並行して行っています。
※1：単一のプロダクトではなく、相互運用が可能な複数のプロダクトを同時に提供すること
画像：https://www.estie.jp/products/research/
その中で主力サービスである「estie マーケット調査」は、オフィスアセットの賃貸領域における業務効率化をするために必要なデータが揃ったDaaS（Data as a Service）というような位置づけです。
私自身も現在このプロダクトのスクラムチームのメンバーとしてQA業務を行っています。
3. 複数のプロダクトチームを横断的に支援
――御社のQA/品証業務の位置づけ・ミッションを教えてください。
QAのミッションは、ユーザーへ新しい価値を届けるために必要な品質を定義し、その品質の創造と維持をスピードと両立させるように必要なプロセス・仕組み作りをリードすることです。
とはいいつつ、今は道半ばなので、今後新たに参画してくださる方（絶賛募集中）と一緒にQAチームを立ち上げてミッションのアップデートも引き続きしていきたいなと考えています。
――現在、QAエンジニアは1名とのことですが、どのようなプロセスでQA業務に取り組まれていますか？
QAエンジニアはチームトポロジー(※2)でいうところのイネーブリングチーム(※3)の位置づけになっています。そのため、複数のチームを横断的に支援することを理想としていますが、実際はQAエンジニアが私1人しかおらずできることにも限りがあるのが正直なところです。
そのため、特に高い品質レベルが求められるプロダクトチームにフォーカスしてスクラム開発に参加し、QAファンネルでいうところのインプロセスQA(※4)的な立ち回りをしてきました。
その他のチームに対しては、必要なタイミングにスポットで、QAファンネルでいうコーチやコンサルタント的なロールで一歩引いて支援する形をとっています。
※2：ユーザに対して「素早く」「頻繁に」「安定的に」価値を届けたいに焦点を当てた組織を作るためのテンプレート・パターンのこと
※3：他のチームが新しい技術を取り入れるのを支援するチーム
※4：開発組織に常駐しながらQAの実業務と品質文化を担う
4. 限られたリソースで効率的にプロダクトの品質を担保する方法
――サービス品質を改善していくために、工夫しているポイントがありましたら教えてください。
前提として、QA1名でできることに限りがある中で、いかに効率的に各プロダクトの品質を必要なレベルで担保するかを大切にしてきました。その上で、工夫していることは主に2つあります。
1つ目は、各プロダクトで現在求められている品質基準を比較して、フォーカスすべきチームを判断し、フォーカスするプロダクトではインプロセスで密に関与していることです。比較的多様な品質基準に対応できるプロダクトに関しては、必要なタイミングで関与する形をとってきました。
2つ目は、インプロセスQAとして関わるチームでは、QAの関与が減っていっても開発が回るようなプロセスを作るように意識していることです。いくら品質基準の高いプロダクトであっても、現状QAの限られたリソースを同じチームに使い続けることは困難です。
他のプロダクトが成長してきた際に、手が回らなくなってしまうことを防ぐ目的でもQAの関与が減っても維持できるプロセス作りが重要だと考えています。
――具体的にはどのような方法で進めているのでしょうか？
たとえば、開発チケットの顧客影響の大きさと影響範囲の広さ、QA負荷の重さ等で総合的に判断して、そのチケットをレベル分けしています。QAレベル1、2、3のような感じでレベル分けをして、開発者がテストをするチケットとQAエンジニアがテストするチケットを明示的に分け、QAが実際に手を動かす量を減らすようにしました。
そのため、開発者には各々の観点でテストを実施してもらい、QAエンジニアはリリース前に開発者がテストした際のテストノート（テスト実行時の記録）を確認し、観点やテストケースが十分であるかを確認。問題がなければリリースする形をとっています。
その際に不足している内容があれば、QAエンジニアが追加で確認作業をして開発者にフィードバックすることで、間接的に開発者のQA意識の底上げも狙っています。
――そのほかにも、工夫していることはありますか？
あとは自動テストのオーナーシップの移譲もしてきました。
自動化されたE2Eレベルのテストは、もともとQAエンジニアが導入をしてメンテナンスをする形をとってきましたが、それを徐々に開発者にオーナーシップを移譲し、一緒に責任を持ってもらえる形に変えてきました。
そのため、今ではメインで関わっているプロダクトでは、私が手を出さなくてもテストの追加やメンテナンスもある程度回る運用状態にすることができました。
――限られたリソースの中で、社内の人を巻き込む形でQA業務の底上げをしているのですね。
もちろん、大きな開発ではQAエンジニアがテスト設計をしてテスト実施もしていますが、それと並行して開発メンバーや関連するビジネスサイドのメンバーを招待してリリース前にQA会を実施しています。
QA会とは、いわゆるバグバッシュやモブテストみたいなイメージをしてもらえばわかりやすいと思うのですが、複数人で集まって一斉に対象のテストをする方法で、不具合や気になるポイントの洗い出しをしてもらっています。
テスト実施時に開発メンバーだけでなく、より顧客に近い視点を持っているビジネスメンバーからフィードバックをもらうことで、リリース後の顧客からの改善依頼のフィードバックを減らし顧客にとって価値のある機能を初めから提供することができていると感じています。
5. プロダクトの成長と共に求められる品質レベルもアップ
――現在、御社の部門内で課題となっていること、改善したいことをお教えください。
たくさんあるのですが、まずはQAエンジニアのリソースが足りていないことです。各プロダクトがどんどん成長して、求められる品質レベルが上がってきているなと感じます。
初めのうちは顧客が少なく求められている品質基準も低かったのですがプロダクトが成長するにつれてそれまで許容されていた不具合がどんどん許容できなくなってきました。それに対してQAエンジニアのリソースが追いつかなくなっているのは課題だと思っています。
そのほかには、現在の弊社のメインプロダクトはDaaS（Data as a Service）がメインであるので、その価値の要となるデータの品質にQAとしてあまり関与できていない点も課題感がありますね。
――それを改善するためのポイントは、先ほど伺った自動化やエンジニアとの共有になるのでしょうか？
そうですね、QAエンジニアだけで品質を作るというよりかはみんなで協力して作るものだとは思っています。できることは協力して結果的にQAのリソースをうまく分散して使えるようになるのが理想です。
幸い、弊社には優秀なデータエンジニアが多数在籍しているのでサービスのデータ品質はある程度担保できているのが現状です。
しかし、QAエンジニアとしてもそこは関わっていくべきだと思っているので、QAエンジニアが増えてチームとしてやっていける頃には、QA側からも関与していきたいですね。
6. 重要なのは顧客にとって価値のある機能・データ
――どんなとき、QA/品証としてのやりがいを感じておられますか？
やりがいを感じるときは主に2つあります。
1つ目は、顧客からうれしいフィードバックがあったときに「やってよかった。開発していてよかった。」と感じますし、顧客に改めて「自分たちが価値を提供できたんだな」と実感が持てるのがやりがいに繋がっていると思います。
2つ目は、プロダクトが成長しているのを見るときですね。弊社ではコミュニケーションツールにSlackを使っていて、チャンネル内で「新規導入されました！」と共有されているのを見ると「サービスが顧客から期待されているんだな」「社会に対して価値を提供できているんだな」と実感できます。
――業務を遂行する上で大事にしていることを教えてください。
これはやりがいにも繋がるのですが、顧客にとっての価値を大切にすること、つまりユーザー体験やユーザーに対しての価値に重きを置いてQA業務をしています。
テストをする上で、サービスが仕様通りに動くかを検証するのは当たり前のことです。それは、いちテスターとして大切な業務ではありますが、何よりも「この機能・データ自体が顧客にとって価値のあるものになっているのか」を常に考えてきました。
7. QAとして開発速度と品質のどちらも妥協しない
――今後、業務を通じて達成したいこと、QA/品証を目指している方に向けてメッセージをお願いします。
現在、弊社ではQAエンジニアが私1人しかいません。今後は2人目となるQAエンジニアやテスト自動化の基盤作りを推進するSETのメンバーを採用し、QAチームを立ち上げ、コンパウンドスタートアップであるestieの品質作りを一緒に取り組んでいきたいですね。
もちろん、開発の速度と品質のどちらも妥協せず顧客にしっかり価値を提供できるような取り組みをしていきたいと考えています。
私1人でできることには限界があるので、QAチーム立ち上げに興味のある方はぜひよろしくお願いいたします。
――本日はお時間いただきありがとうございました。
