はじめに
この記事は、アソビュー Advent Calendar 2025の9日目（表面）です。
井上です。今年の中頃からアソビューの一人目SETとして活動を始めました。
プロダクト品質の課題をエンジニアリングの観点から仕組みで解決するために、私の解釈のSETとはなにか、やったこと、これから目指したいことなどを共有します。
背景
遊びの現場におけるお客様のお困りごとを解決するアソビューの事業ですが、アソビューの事業が拡大してより多くのゲストやパートナーさんに使っていただく機会が増え、開発スピード、アプリケーションの規模の増加してます。
そういった中で、どうしてもスピード重視で品質を後回しにする場面が増え、それに起因した技術的負債が増えたり本番バグの増加などの課題もそれに比例して増えてしまっている現状でした。
今後も事業成長、事業拡大していく中でそういった状況を打破するための”品質”に対する取り組みが急務であったがそのためのポジションでもあるSETの採用はなかなか進んでいませんでした。
そんな中で、私がこれまでフロントエンドを中心に品質を意識し、レビューやリファクタなどをやってきており「コード品質とスピードの両立」という観点に元々興味と課題感が有ったこと。また、質とスピードといえばのt-wadaさんのフォロワー（ファン？）でも有ったことからこのポジションに社内公募の制度を活用してこの課題解決へのチャレンジを始めました。
SETとはなにか
さてSET（Software Engineer of Testing）の定義とは何でしょう。
SETというポジションにチャレンジするに当たって各社の事例や定義を調べてみましたが、結論各社定義は様々で体制も様々であるということがわかりました。
ミッションが自動化環境の構築がメインだったり、はたまた品質保証だったり、体制についても開発チームの一員 or 横断チームなどなど様々でしたのであくまで今のアソビューの目的ベースであるべき姿を探れば良いと思い、整理しました。
アソビューのSETとしては「テスト」のみにフォーカスせずプロダクト品質全体に向き合い下記を目指そうと考えています
- プロダクト開発チームが開発品質とスピードを両立できている状態
- プロダクト開発メンバー全員が品質を意識している
- テスト、品質保証がシフトレフトできている
- プロダクト品質管理のプロセスや手段も改善され続けている
SETになってやったこと、施策の内容を紹介
各チームのテスト状況全般ヒヤリング
各プロダクト開発チームのメンバーにそれぞれ下記をヒヤリングして課題を把握しました。
- コードベーステスト（UT/IT）を日常的に書いているか
- pre-commitや、CIでのテスト実行出来ているか
- E2Eテストの現状（手動、自動）
- 何に一番困っているか
チームごとに細かい状況はまちまちですが、総じてテストコードを書くかは人依存、自動テスト実行状況はチームによるという形で品質に関する取り組みは優先度が高くなさそう、一方手動でのE2Eテストは工数や確実性などに課題が有りそうという状況でした。
これらのヒヤリング結果を元にして実施した施策を下記で紹介します。
E2E自動テスト環境整備
課題
E2Eテストについての課題感を各チームにヒヤリングした結果最も問題になっていたのが各プロダクトでリリース前に行う、プロダクトの重要なシナリオについて手動で動作確認を行う手動のリグレッションテストの工数でした。
というのも、このリリース前テストのケース数がプロダクトの機能追加に伴って増えており、全部終わらせるのに数時間レベルでかかっていました。
そのため、効率優先で時間がないので、開発者が修正に直接関係無い機能のテストは適宜判断して間引いてしまったり、本来のリグレッションテストとしての位置づけとしては意味がない状態になりかねない状態でした。
また、手動テストなのでシナリオの管理がコードベースではなくconfluenceのページの表であり、更新性に乏しく実際機能追加に合わせた追加が不十分にもなっていました。
やったこと
Playwright環境と既存のリリース前テストケースをもとにシナリオを用意しました！
具体的にはPlaywrightをローカルで動かすように環境を用意（モノリポにパッケージ追加）して、シナリオの作り方、書き方のルールを整備、実際に現在のリリース前テストを全て自動テストのシナリオ化しています。
現段階ではローカルからstaging環境のアプリケーションで操作を実行して検証できるところまでにとどめています。（CIでは動かさない）
また、合わせてこのシナリオはQAエンジニア中心にメンテできると良いと思っていましたので、QAエンジニア向けに勉強会を開催してテストシナリオを書けるようになってもらいました。
結果と今後
数時間かかっていたリリース前テスト作業がローカルでのPlaywright実行で数分で終わるようになりました。
QAエンジニアの方で機能追加が有ったタイミングでE2Eシナリオも追加、編集いただく運用で回せています。
現段階ではローカルのリリース前テストの効率化のみですが、いずれはCIで動くようにして、例えば実装してpushしたタイミングでPR上でE2Eテストの結果が見られるようにしてより堅牢性を高めていきたいと思います。
コードベーステスト（UT/IT）促進
課題
これまでコード実装時にUT/ITなどのコードベーステストを書くことは特別ルール化されておらず、個人の裁量に任されていたこともあり、結果スピード重視でテストコードは後回しになっていました。
結果として
- テストカバレッジが低い
- テスタブルではない設計で実装される（適切なレイヤーで分離されていないなど）
- 特に変更が多い重要なクラスほどテスタブルではない設計のまま修正され続けてしまいノンテストのまま膨れ上がってしまう（割れ窓状態）
などの状況を見かけるようになっていました。
その代償としてエンハンスの影響範囲の考慮漏れなどで不具合につながるケースも発生してしまっています。
やったこと
啓蒙、レビュー
テスタブルな設計にすること、まずは追加や修正したロジックに対してのテストを必ず書くことなどをプロダクト開発チームに働きかけました。
また、テストを書く上での課題感を把握するためにも私の方でチームのPRに対してテスト、品質観点のコードレビューを実施しています。
UTの書き方や効率化、テスタブルな設計に関しての指摘をしています。
また、PRごとにどのくらいテストコードが書かれてるかを簡単に可視化できるようにスクリプトを組んで確認できるようにしてPRごとのテスト実装率のモニタリングをしました。
さらに、個々のPRを紐解き、テストコードが書かれていないPRに対して、何故テストコードが無いのか原因についてPRをサンプリングして開発メンバーと対話して深堀りするなどしました（時間がない？テスタブルではないから書けない？など）
結果、テストを書き始める事自体に課題が無いことがわかり、基本的にはテストは必ず実装することをメッセージングし、実装率の向上やその上でテストを書く上での課題などが見えてくるようになりました。
カバレッジレポート
まだ細かい数値目標を立てたりはしていませんが、社内用のSonarQubeサーバーを準備して現状のカバレッジや推移を見られるようにしたり、
先週との差分を自作ツールで簡単にカバレッジレポートとしてまとめてチームに共有するようにしています。
テストを頑張って書いてもどういう成果に繋がっているのか分からないと達成感ややりがいがないと思いますが、これによって前週比で少しずつでも上がっていることがわかるようになりました。（実際上がり続けている）
コードベーステスト実装の効率化
実装ルールをコンフルエンスにドキュメントとしてまとめたり、cursorルールなど生成AIで実装時に参照するルールを整備、またArchUnitを用いてレビューで指摘するようなところのチェックを自動化するなどにも取り組んでいます。
余談ですが、cursorなど生成AIを活用してテストコードを書いているとうまく行かず結果的にテストをパスすることが目的になって実際のコードのロジックを全くテストしないようなものが出来上がってくることが往々にして見受けられます（！）。効率化しつつもしっかり何をテストすべきか、実際にテスト出来ているかを確認することは重要です。
結果と今後
これらの活動は泥臭くはありますが、少しずつ「実装したらテスト書くのは当たり前」という空気感が生まれて来たと思います。
前述のPRごとのテスト実装率についても40%以下だった状況から80%は書かれるように向上しました。
今後も社内への発信を続けてコード品質意識を高めて、「テスタブルなコードを意識したら良い設計になった」「テストを書いたら自分もチームも得をした」ような文化や雰囲気を作っていきたいです。
不具合の分析、可視化
課題感
元々本番障害などを表で管理するような運用は有ったものの、それぞれの障害の元になった不具合にどういった原因が多いのかなどの統計情報は取れておらず、また本番リリース以前の不具合の管理についてはチームによってバラバラであまり管理されていませんでした。
テストや品質保証をシフトレフトしていくにはもっと前の段階で不具合を検出して対処すべきですが、前のフェーズ（実装やシステムテスト）の不具合の分析が出来ておらず傾向が掴めていなかったのでそこから漏れ出て本番障害につながる不具合がただ増えてしまうが原因が特定できないという状況でした。
やったこと
本番障害に限らず、実装以降に発生した不具合チケットの起票とラベル付けをルール化しました。
スプリントごとに開発リーダー、QAエンジニアと集まりそれぞれに不具合に関して原因や本来どこで防ぐべきだったかなどの情報を付けていく運用をすることによって、データを収集、統計情報を可視化しています。
これにより感覚では分かっていた、本来は実装やコードベーステストで防ぐべき不具合がシステムテストや本番で検出されてしまうものが多い＝シフトレフトできていない
という現状が可視化されました。
一般的にも複数の研究（Google Testing Blog, Microsoft Research, Capers Jones, IPA/SEC）によれば、本番で発見される欠陥の 70〜85% は「本来は単体テスト（UT）や結合テスト（IT）で検出可能な種類の欠陥」であるということがありますが、弊社でもまさに同様の結果でした。
結果と今後
現状は可視化出来たところまでですが、これらを元に原因の傾向などを見ながら目標、指標を設け、対策を打って上流フェーズで防げる不具合を防いでシフトレフトを目指していければと思います。
今後の展望
基盤の整備と継続的な負債抑制の仕組み
今は文化の定着のためにも私の方でレビューをしたりレポートしたり泥臭く動いていますが、今後スケールするためには機械的に解決できるところはAIなどを活用して行くことが重要です。
ルール化を進め、AIを活用して自動化できるところを自動化して効率化していきたいと思います。
- テストコードの実装ルールやTipsの整備
- カバレッジのレポーティングをPR単位にして修正分のカバレッジなどの基準などを設ける
- 例えばCode Qualityなど静的解析ツールを用いてコード品質観点の機械的なチェックを自動化
- 成果物にカバレッジなどのガードレールを敷く
既存の技術負債を解消していく方法の道筋
上記は新しく作るときの仕組みですが、アソビューのプロダクトは歴史が長く過去の技術負債が積み上げられている箇所も有ったりしてエンハンス開発してるついででは解消できないものも多いです。
そういった技術負債をいかに解体していってテスタブルにしていくかという下記のような観点も必要です。
そのためのリファクタリングの方法論を確立して行きたいと思っています。
- テストが無い状態の対象に対していかに既存ロジックが壊れないことを保証するか
- 様々なクラスなどに密結合になってUTなどが書けないものをどのように解体するか
- 例えば外部要件からのテスト（APIテスト、コントラクトテスト、スナップショット）などを作成して固めていき、要件通りに動くことを保証した状態でロジックを分割、外出しして本来のUTを書いていくなど
テストコードもプロダクションコードの必須な成果物とする文化の確立
私自身もコードを書くこと、アプリケーションを作ることが好きですが、プログラミング対象物が複雑になっていくにつれて書いたコードに対してテストをすると落ちる、修正したことでアプリケーションが壊れる、などの状況になってしまうと楽しくありません。（頑張って書いたコードが後々負債の温床になったら悲しいですよね、、）
テストも確実に実装とセットにすることで堅牢なコードが出来て自分のためにもチームのためにも良い効果を生み出すと思います。
テストもプロダクトコードの一部としてセットで育てていく文化を作っていきたいです。
こちらのpodcastでt-wadaさんが述べていた内容がすごく印象的でした！
テストとリファクタリングをワンセットで開発することで、現実が複雑であっても、複雑さに合わせてきれいに作り直しながら形を変えていくことができるようになった結果、プログラマーとしての誇りややる気、喜びといったものを取り戻すことができ、「俺ってすげえな」という状態をずっとキープできるようになった
https://refactoradio.com/episode/100
まとめ
”SET”はグローバル含めた各社のトレンドをみてもテストだけにフォーカスして自動テストのコードを書く人ではなく、「開発者が自然に品質を作れる世界」をつくる、テストが書きやすくなるプラットフォームをつくる人、という定義であると思っており、そのためのインフラや仕組みを開発していくエンジニアとされていると思います。
私もアソビューの一人目SETとしてこれからも開発やQAエンジニアと連携しながら「生きるに遊びを」のミッションを支えるそういった世界の基盤を作っていければと思います。
アソビュー株式会社では新しいメンバーを随時募集していますので、ご興味ある方はお気軽にカジュアル面談ご応募ください。
