20250929_QaaS_vol20

2025/09/29 QaaS 登壇資料：自立した開発組織の中でQAエンジニアは何する？
https://qaengineeratastartup.connpass.com/event/367605/

Transcript

1. © 2025 estie Inc. 自立した開発組織の中で QAエンジニアは何する？ 株式会社estie 村上 槙 (Shin Murakami)
2. © 2025 estie Inc. 自己紹介 1 x: @mura_shin0928 経歴： estie QAエンジニア ← Shippio QAエンジニア ← SHIFT QAキャリアスタート ← 愛知で自動車のソフトウェア開発 ← 福岡県生まれ 趣味： - マンガ、アニメ - 男性アイドル（妻の影響） - お酒、ゴルフ（初心者） 株式会社estie QAエンジニア（8月〜：QAマネージャー） 村上 槙（murashi）
3. © 2025 estie Inc. 会社紹介 2
4. © 2025 estie Inc. Confidential © 2022 estie Inc. Our purpose 産業の真価を、さらに拓く。
5. © 2025 estie Inc. 自社ビル等 estieの事業領域 数ある産業の中で、estieが最初に挑む領域は不動産 不動産の中でも商業用不動産領域に注力し、オフィス・物流・レジとアセットを拡充 資産 タイプ Office オフィス Retail 商業施設・アウトレット等 Industrial 物流施設・データセンター等 Hotel ホテル Residential 住宅 投資 目的資産 自己使用 目的資産 商業用不動産市場（資産規模: 約275兆円 / 業務規模: 約16兆円） 賃貸住宅市場 分譲住宅市場 分譲オフィスビジネス等も存在はするが、業としてではなく単純に古くからある自社ビルや工場の所有と言った形態が一般的 4
6. © 2025 estie Inc. Whole Product構想 5 商業用不動産市場全体を支えるWhole Productを構築し、産業の真価を拓く estie独自の不動産基盤データ 分析 認証 権限管理 API セキュリティ ワークフロー 検索 売買事例データ 賃貸事例データ マクロデータ 売買物件 探索 売買物件 管理 物件価値 評価 顧客管理 募集管理 募集情報 提供 売買マーケットプレイス 賃貸マーケットプレイス ポートフォリオマネジメント IR・資金調達 ERP Marketplace SaaS Data as a Service （DaaS） Middleware Data Platform 売買 賃貸 ファイナンス
7. © 2025 estie Inc. プロダクトラインナップ（一部抜粋） 6 賃 貸 市 場 DaaS ( デ ー タ ) 売 買 市 場 SaaS 日本最大級のオフィスビルデータベース 日本最大級の所有者/売物件探索サービス 不動産取引の案件管理サービス + J-REIT/行政関連オープンデータ 売 買 市 場 SaaS 日本最大級の物流施設データベース 日本最大級の住宅賃料データベース
8. © 2025 estie Inc. 不動産データ×AIで新たな価値を創造し、業界企業を後押して業界全体のデジタルシフトを推進 7 不動産業界のAI活用を支援する「不動産AI Lab」を開設 estieの強みを生かし、お悩み相談からAIソリューション提供まで幅広く対応 ①業務知識・経験を持つ ドメインエキスパート ①業界理解 培ってきた データモデリングの 技術・知識 ②データ構築技術 他社が持っていない 網羅的な マルチアセットデータ ③データを所有
9. © 2025 estie Inc. 組織体制について：事業部制により経営スピードを最速に プロダクト群で事業部制を引き、1事業部≒1companyの形をとる それぞれの事業部が1つのスタートアップであるかのように意思決定を行う
10. © 2025 estie Inc. ここから本題ですが、 あなたならどう動くかをぜひ想像しながら聴いてください！ 9
11. © 2025 estie Inc. ちなみに、本日の話は成功体験やTipsではなく 一人のエンジニアとしての葛藤と決意を赤裸々にお話しできればと思ってます 10
12. © 2025 estie Inc. murashiのスキル・経験 : estie入社前 ➢ スキル o 実装は多少 ▪ 雰囲気で書けるが、言語・フレームワークの特性などは詳しくない o アーキテクチャは分からない o SQLはシンプルなものであれば書ける o テスト ▪ テスト活動に関わるものは一通り ▪ 自動テスト:Playwright E2Eは書ける ▪ CIはE2E実行部分のみ ➢ 経験 o テストを軸としたQA活動 ▪ 基本的にはQAEの主活動はテストでありつつ、そこを軸にプロダクトやプロセスを改善 o プロセス設計やガイドライン整備などはしたことあるが、イネーブリング活動はない 11
13. © 2025 estie Inc. estieのプロダクト開発 12 • チームによって開発スタイルが異なる • ULはビジネスサイド目線で事業目標を設定しつつ Sales/CSとのHubになる • 事業目標はエンジニア含めチーム全員で追いかける • 複数Epic並行開発 • VoCはfeedbackもらった最短数時間で対応することもある • 基本的に一チーム1プロダクト o プロダクトのフェーズによってチーム構成、プロセスを柔軟 に変える • 開発はFeature Flagを使ったトランクベース開発 • Productionへのdeployは基本毎日実施 o Deploy=releaseとなる機能はdeploy前に各エンジ ニアで動作確認する
14. © 2025 estie Inc. estieのプロダクト開発 ➢ビジネス組織（estieではOpsと呼ぶ）とDev組織の垣根がなくエンジニアのビジネス感 度が高い ➢複数Epicを少人数で開発できるパワーとモチベーションがある ➢VoCに対する感度が高い ➢価値を早く届けることを大事にする文化 ➢Feature FlagでConflict意識せず安全に開発できる仕組みがある ➢自分で開発したものはリリース前に自分たちで確認する 13 要求定義〜実装、実装したものが正しい価値になってるかの確認までを 高速に実現するパワーと仕組みがある = 「自律した開発組織」
15. © 2025 estie Inc. 入社~1ヶ月：キャッチアップ期 SaaSプロダクトの開発チームに所属。チームとしては新しく、 プロダクトとしても売り上げを作るためにガンガン開発をしてい くフェーズ。複数の開発が並行で走り、リリースもほぼ毎日され る様子。リリース対象物の確認はSWE全員で実施する文化が あって良さそう。インシデントは多少発生してるものの、チーム のEMや各メンバーと話しても大きな課題感を持ってるわけでは なさそうな気配。 14
16. © 2025 estie Inc. 入社~1ヶ月：キャッチアップ期 ➢ 方針を一旦決めた o やること/やらないこと ▪ やること ✓大きめの開発の時は受入基準を作る ✓振り返りを隔週で開催 ▪ やらないこと ✓リリース前テストを巻き取る o QAエンジニアが確認しないとリリースできない、という状態にする ➢ 足元できるところからやる o E2Eテスト実装 15
17. © 2025 estie Inc. 1ヶ月~3ヶ月：模索期 E2Eテスト実装と受入基準の整理は進め出したものの、100%の 時間をそこに使うものでもないし何すると良いか模索。1ヶ月 経って感じるのは、チームの新しさやプロダクトのフェーズ的に も機能開発へのフォーカス度合いが強いので、チーム運営や運用 部分をパワーでやってそうなところやおざなりになってるところ がありそうな気配。その辺をいい感じにするともっと全員が気持 ちよく開発に集中できるかも？ 16
18. © 2025 estie Inc. 1ヶ月~3ヶ月：模索期 ➢ Datadog RUM (モニタリングサービス）の導入してモニタリング可能に o 手元で再現できない問い合わせの場合、都度打ち合わせなど発生して手間 ➢ JIRAのチケット作成方針決めと整理 o チケット単位がばらばらでチケットの作成や確認のたびにノイズがあった ➢ Dependabotのルール見直し o パッケージアップデートや脆弱性対応がややこしい感じになってた ➢ リリース確認bot作成 o 都度Githubのリリースタグから対象PRをslackにコピペするちょい手間運用 17
19. © 2025 estie Inc. 1ヶ月~3ヶ月: side story 機能不全によるインシデントが短期間に複数件立て続いた。いずれもE2Eテストでは検出 できない部分。たまたまError監視サービスの不具合も重なりリリース前の検出ができなか った。この対策のために、何かしらの要因で取りこぼしてしまうクリティカルなバグを検 出するために、5分でできる範囲で超重要なケースはリリース前に手動で確認する、としよ うとしたがチームの文化に合わず導入前に頓挫... 18 教訓：「強い意味を持たない」手動運用は好まれない。「怠惰」に安全 を作ることが大事。
20. © 2025 estie Inc. 3ヶ月~6ヶ月：チャレンジ期 インシデントの発生起因はフロントエンド部分に多そう だったので、調べた感じ怠惰で安全を作るためにはフロ ントエンドテストを実装して常にCIでチェックされるよ うになれば良さそう。ただ、フロントエンドテストって どういう粒度・観点でテストを書くのが良いんだ？E2E テストとの棲み分けは..？ 19
21. © 2025 estie Inc. 3ヶ月~6ヶ月：チャレンジ期 ➢ ひたすらフロントエンドテストのことを調べた o 技術スタック：Vitest + React Testing Library + MSW（いずれもお初） o ChatGPTとの壁打ち、書籍読む、公開資料読む ➢ フロントエンドテストの方針決めていざ実装 o E2Eテストとは勝手が似てるようで違いすぎて沼にはまった... ▪ ここでもChatGPTとひたすら対話しながらCursor使ってtry->error->try- >error... o 自分がハマったポイントはガイドラインとして整備してチームに展開 o 詳細はブログに書いてるので興味あればみてみてください！ ▪ Blog: フロントエンドテスト誰がやる？ 20
22. © 2025 estie Inc. 6ヶ月~9ヶ月：葛藤期 インシデントは収まってきた様でよかった。期も変わりそん なタイミングでQAマネージャーを襲名。estie QAがどうい う存在になると組織にとってより良いのか考え出した。ただ、 そもそもestie QA 3人いるけどそれぞれやってること違う中 でQA組織としての在り方や組織全体の中での位置付け・ Functionをどう定義すると良い？ 21
23. © 2025 estie Inc. 6ヶ月~9ヶ月：葛藤期 22 • 受入基準作り • エラーのトリアージ、修正 • KPIモニタリングダッシュボード作り • プロダクト横断的な課題に対する対応 • エンタープライズ向けPJ開発のサポートと一部巻き取り • エラーのトリアージ、修正 • 横断的なデータ品質改善活動 o テーブル毎、カラム毎のデータの特徴と重要度整理 o elementary testの実装 • 複数チームに対する横断的なサポート • エラーのトリアージ、修正 • パフォーマンスモニタリング • プロダクト固有のデータ品質改善活動 • 機能実装 • 問い合わせ対応、CSとの連携 向き合ってるプロダクトの特性やチームの状況、個人の志向性が異なる結果、 共通部分も多少あれどそれぞれやってることがかなり違っている murashi QAE QAE 開発チームに浅すぎず深すぎ ずの状態で入り、可能な範 囲で兼務 複数の開発チームに広く入り 包括的にサポート 開発チームにどっぷり深く入り、 プロダクト開発を牽引
24. © 2025 estie Inc. 6ヶ月~9ヶ月：葛藤期 ➢ QAEのJD (Job Description) を見直し o もともとのJDとはやってることが沿わなくなってきた o 実態とestie QAとしての職務を改めて議論&整理 ▪ 結果、「プロダクトの信頼性」と「組織の生産性」に貢 献する職務とした 23
25. © 2025 estie Inc. 6ヶ月~9ヶ月：葛藤期 ➢一方で、悩みも... o組織にestie QAはこんな組織です！と共有しようと思った 時につまりどういうFunctionをもった組織と定義するのが よいかわからなくなってきた... ▪ 定義 = 一定の線を引くことだけど、線を引いた結果それ ぞれの行動を制限することにもなりかねない ▪ いったん「どういう組織」を定義するのは保留中 24
26. © 2025 estie Inc. 悩んだ過程をもう少し深掘り 25 • Job型におけるQAEの仕事 o Job型 ▪ 人の前に仕事・職務があって、それぞれの仕事を全うする ことで組織の仕事が果たされる、という思想 o 前提 ▪ Job型であっても、主務を軸として周辺領域の越境をしな がら仕事を進めている ▪ Jobをパズルのピースとした時、ピース間に大きな隙間は ない ▪ estie QAにおいて明確に定義されたQAEの主務はない 出典：リクルートワークス研究所（https://www.works- i.com/column/works04/detail029.html） ※同サイトは『採用のストラテジー』（中村天江、慶應義塾大学出版 会、2020）を出所として記載
27. © 2025 estie Inc. 悩んだ過程をもう少し深掘り 26 • パターン1: 軸足を決めない o 各Jobが全うされるものの満たされないパズルの隙間を埋める ▪ メリット：広い課題をスコープとできる ▪ デメリット：何してる人か分からなくなりそう。課題の探索と実行に根気と時間がかかる • パターン2:軸足を決める o 自分自身が一つのパズルのピースになるように動く（例：SWE的な活動をする）。その上で、周 辺領域に「品質」を置く ▪ メリット：向き合う課題が絞られてフォーカスしやすくなる ▪ デメリット：足元の課題以外が見えづらくなりそう どっちが正解などではないし、どっちのパターンがいてもいい。 状況に応じて変わったりするものなだけに悩んだ結果今はいったん保留中。
28. © 2025 estie Inc. 最近考えていること ➢ Platform Engineering Kaigi2025に参加して感じたこと o Platform Engineer (PE) 的QAという在り方が一つのヒントになりそう o Platform Engineerが目指しているものは「プロダクトの信頼性」と「組織の生産 性」の向上 o それをPlatformの提供を通して実現している ▪ ただ提供するだけでなく「ドキュメントの整備」「導入支援」「セルフサーブ できる仕組みづくり」など、誰でもPlatformを使える形にすることで組織の土 壌から変えていく o estie QAとしても目指しているもの同じ o そのためにやりたい変化の起こし方も似てる部分が多そう 27
29. © 2025 estie Inc. 最近考えていること QAEが爆発的な事業成長に貢献する機会はほとんどないが、日々の+αを積 み上げることで複利を生み出し中長期的に大きな差分を産みたい 「estie with QAEの未来 >>>>> estie without QAEの未来」 を作る 28
30. © 2025 estie Inc. まとめ 問い：自律した開発組織の中でQAエンジニアは何する？ 解：絶賛模索中。ただ、やることに明確な線引きはせず「プロダクトの信頼 性」と「組織の生産性」のために何ができるかに向き合い続け何でもやる。 SWE的QA、PE的QAという在り方は一つのヒントになりそう。 29