SETチームが取り組む魅力的品質へのチャレンジ

はじめに

SETチーム（Software Engineer in Testの略。テストを中心にエンジニアリングで品質に貢献するチーム）のリーダーをしている玉澤です。

２０１８年１２月にチームを立ち上げ半年が経った区切りとして、当時を振り返りながら品質や組織的な課題への取り組んできた内容をご紹介します。

QA体制の立ち上げや自動テストの導入などをこれから検討している方々の参考になれば幸いです。

背景

過去

JapanTaxiへ入社したのは2017年2月、私はiOSアプリエンジニアとして入社しました。

当時の社員は４０名程度。そのうち半数がエンジニアで、私は全国タクシー（現：JapanTaxi）のiOSアプリを担当し、日々新機能開発や不具合対応などを行なってきました。

全国タクシーアプリのリリース前テスト体制はリリース予定日の数日前に開発を止め、アプリエンジニアが手分けして行なっていました。

テストケースのメンテナンスはエンジニアが担当し、スプレッドシートで１行１テストのような感じで運用されていました。

２０１７年４月〜

開発に集中できる環境を作るためテストケースのメンテ作業を残し、実施をカスタマーサポートチームで請け負ってもらうことになりました。

カスタマーサポートチームは、ユーザーからのお問い合わせだけでなく、アプリと連携しているタクシー会社様のサポートも行なっているチームです。

ここでは、開発の手が止まらないメリットが得られました。

その代わりカスタマーサポートチームの負荷が上がったことは言うまでもありません。

２０１８年８月〜 行動開始へ

それから社員が増え組織構造も変わるなか、１年以上に渡ってこのテスト体制が続いてきました。

この間にカスタマーサポートチームはカスタマーエクスペリエンス部(以後CX部)と大きくなり、新たなサービスを開発したり大きなリニューアルがあったりと、組織も事業内容も大きく成長してきました。

この頃に個人的にソフトウェア品質への危機感を感じるようになったと同時に、メイン業務の合間ではなく会社として本格的に取り組んでいかなければならないと思う気持ちが強くなってきました。

危機感を感じるようになった理由の一部

• テスト体制はあるが、致命的なバグを検出できない
• デバッグに時間が掛かる / 方法が難しい手順が多い
• 組織横断的に課題が発生してきている
• 会社のビジョン実現
• 業界の競争激化

私自身、日々開発をする中でいくつものバグを生み出してきました。動作確認方法が分からず他のメンバーへ相談したりと、非効率なサイクルが暗黙的に慣習として定着していました。

そんな状態で組織が大きくなり開発リソースが増えていったとしても、品質や効率面で足を引っ張られ開発速度が期待より出ないといった課題にも直面することになります。

これらは改善サイクルを作り運用できれば解決できる事だと思います。

• バグの直接原因ではなく、なぜこのバグは発生したのかという根本原因の特定と改善アクション
• 動作確認方法、もう少し楽に出来ないかという生産性に繋がるアクション

改善サイクルは自然と出来るものではありませんし、最初は誰かが担当業務＋αで動き出す必要があるかなと思います。

そんな危機感から、今までCX部で１年以上アプリのテスト実施をしていただいていた方と「そろそろ、こういう組織作って改善していきたいね」という話で盛り上がり始め、CTOと話す場で今の気持ちを伝えチーム化する動きが始まりました。

（ここまでを振り返って、話の流れで認識の齟齬があるといけないため書いておくと、ここまでのJapanTaxiアプリの開発チームに所属していて感じていた課題であり、それ以外のプロダクトの話は含まれていません。ただし、チーム化を進め全社的にヒアリングをしていく中で組織全体として同じような課題を感じている人が多かったということが判明しました。）

ロードマップ

チームの立ち上げ準備期間に、半年後までのロードマップを作成し、そこへ向けてアクションプランを決めていきました。

アクションプランについては、現状の課題感に加えて各方面でヒアリングを実施し集めたものをチーム内で優先度付けしたものになります。

SETチームメンバーは２名しかいなかったため、初期は大きな成果に向け小さな成果を積み重ねていく戦略をとることにしました。

積み重ねる方法としては、私が所属していたJapanTaxiアプリ事業部をモデルプロジェクトとしてE2EテストやQA体制立ち上げを集中し、ここでの成果を横展開し他のプロダクトも改善していく流れです。

このロードマップの先にある大きなテーマとしては以下の２つになります。

• 当たり前品質の確立、魅力的品質の追求
• 全社横断

アクション

テスト体制見直し

1. テストケース管理ツールの導入

テストケースの運用を始めるにあたり、TestRailを導入しました。

テストケースを１から定義しなおしたのですが、どういう粒度や観点で定義していったかについてはここでは割愛します。

テストケースの実行結果を蓄積し傾向を把握できるようになり、テストケースの管理も以前に比べて圧倒的に楽になりました。

テストケースから仕様書へ辿れるようにリンクを追加しておくなど、サービス仕様の把握するハブとしての役割も担えるようにしています。

ツール自体はSETチーム外に解放し、場合によってはレクチャーを行い、誰でも活用できる状態にしています。

2. テストケース設計プロセスの導入

仕様追加や変更に追従できていないことが長年の課題だったため、テストケース設計プロセスを展開しSETチームで依頼を受ける形で運用していくことにしました。（QA体制ができるまではSETの２人で運用を続けた）

このころから徐々に、作成したテストケースを元にエンジニアチーム内で開発の中で機能テストを実施するという流れが生まれ始めました。

そこで優先度の高い不具合を未然に防げたりと、このアクションによる成果も出始めました。

運用し続ける必要があるため時間が取られる施策ではありましたが、「常に最新の状態が反映されることが保証されている」ことによる安心感は今までにない大きいものでした。

3. リリース前リグレッションテストプロセスの変更

実施に関してはCX部のサポートを受けている状態でしたが、SETが依頼窓口として仲介し影響範囲からテストケースを抽出しCX部へ依頼するといったことを行いました。

なぜ仲介したかというと、テストケースを全面的に見直したことでテストケース量や粒度が大きく変化したため、今までどおりのやりかたで全テストを行うと時間が足りない・非効率な状況が発生してしまうからです。それから、書き直したテストケースを実施を通してレビューしてもらい質を上げていきたかったという理由もあります。

QA体制構築

1. 人員

QA体制を立ち上げるためには、人員が必要です。人員確保までの間は、前述のように自ら運用してきましたが、運用している限り自動テストや環境改善アクションに注力できなかったため少々焦りがありました。

チーム立ち上げ後３ヶ月で１名採用することができましたが、QAを運用していくためには人が足りないことと、全社的にQAの需要は高くこのペースでの採用を待っていられなかったため、即効性を得るためにベンターを活用することにしました。

2. 機能テスト設計・実施プロセスの導入

今まで、リリース前リグレッションテストをCX部で実施していましたが、QA体制ではそれをQAチームが巻き取り、さらに機能テスト設計・実施も行っていきます。

機能に着目したブラックボックステストが主で、テストケースのメンテナンスも併せて行なっています。

QAチームがどれだけ機能テストを受け入れられるか未知数だったため、アプリのUIが絡むものは全てがQA対象として運用しています。

リリース前に一気にテストを行うのではなく、一定の品質を機能開発時の段階で保証することで、リリース前のテスト負荷を下げることができました。

3. シナリオテスト/探索的テストの導入

過去に作成していたテストケースは、主に機能テストメインで、リリース前に手動で毎回やるにしては粒度が細かすぎて時間がかかる上、ほぼバグが見つからず、もう少しケース数に対してのバグ検出率を改善したいという課題がありました。

そこでリリース前リグレッションテストでは、シナリオベースと影響範囲を含めた機能テストの２軸で行うことにしました。それで余った時間は探索的テストを行うことで、予め用意したテストケースでは打ち取れない部分のテストも行えるようになりました。

これによって、手順化しにくい状態に対するテストも行えるようになりました。

4. シフトレフト

シフトレフトとは開発サイクルの中でQAエンジニアがより早い段階からQAを行なっていくことで早期発見し、手戻りを最小限にする考え方です。これによってコストとリスクを抑えるとが期待できます。

SETチームで作るQAチームは、施策や案件の最後の工程であるリリース前リグレッションテストからカバーし、シフトレフトを目指すことにしています。

６月末時点では、まだシフトレフトできていませんが、そのために必要なリリース前リグレッションテストフェーズの安定化は着実に進んでいます。

自動テストの導入

1. E2Eテストの自動化

Espresso・XCUITest / Appium で検討しましたが、シナリオベースのテストについては両方OS一気に書きやすいこととソースを使い回しやすいこと、今後QAエンジニアにもテストコード書くビジョンがあることなどからAppiumを選択しました。

Appiumは社内の Mac miniで構築し、Jenkinsで定期実行するようにしています。

現状、JapanTaxiではサービスの特性上、配車周りや決済周りなど動作確認がしずらい課題があります。E2Eテスト導入と同時にテストしやすくする環境的問題も同時に解決していく必要があります。

環境問題が改善されていくと、シナリオベースで作成されたリリース前リグレッションテストの自動化がスムーズに行え、結果として品質の安定化への寄与と、QAチームからマニュアルテスト業務を減らしシフトレフトを加速させることができます。

2. CI / CD の構築、TestRailとの連携

自動テストを書くだけでなく、問題が発生したときに、エンジニアが気がつけるようにビルドパイプラインの構築が必要不可欠です。

今回は、Bitriseを使ってiOS / Androidリポジトリのmasterを毎晩ビルドし、Amazon S3にアップロードするようにしました。

IPA/APKファイルをダウンロードし、Appiumを実行、自動化テストシナリオはTestRailAPIで連携をし結果を記録し、Slackへ通知するといったところまでを構築中です。

SET での取り組みを CI / CD Test Night #4 で LT した時の資料

3. QA用デバッグツール開発

マニュアルテストやE2Eテストで使える動作確認を楽にするツールを開発します。

開発時のデバッグが楽になり、マニュアルテストの時間も削減できます。そして何より空いた時間でより価値のあることに時間を使うことができるようになります。

その他

1. APIモックサーバー

タクシーの注文条件や配車状態・決済状態によってアプリのUIは様々です。

その状態を再現すること自体が大変で時間が掛かるという課題があったため、２０パターン程度をあらかじめデータを用意し、表示動作確認に掛かる時間を大幅に短縮することが出来ました。

アプリエンジニアがマニュアルでも難しかった動作確認を楽にできる仕組みが用意できました。

2. RIBsTreeViewer

おまけ的なものなのですが、iOSではRIBsというアーキテクチャを採用しています。

RIBsは画面ツリーとは別に状態をツリー構造で管理するのですが、動的に変化していくためイメージしにくい課題や、状態ツリーの不具合の発見がしづらい課題がありました。それを可視化するためのツールを開発して iOSチームへ提供しています。またtry! Swiftのブースで説明用ツールとして活用した実績もあります。

• iOSアプリ起動中の RIBs Tree を簡単に見られるツールを作る
• try! Swift Tokyo 2019にゴールドスポンサーとしてブース出展してきました

振り返り

私のような現場の声に耳を傾け、素早く実現に向け組織的に手厚いサポートをしてくれるところがJapanTaxiの良い所です。

またチーム立ち上げ後も、部署を超えて能動的に協力してくれる同僚が多かったことも助かりました。

品質や効率は組織全体で意識していかないとなかなか改善しないものですが、チーム立ち上げ後の半年経った今の感覚からして、意識に対する懸念はあまりなく、私たちチームが周りを巻き込んで改善していければ良さそうな雰囲気です。

ロードマップで半年後に目指した状態を全て実現することはできませんでしたが、QA立ち上げに関しては実際に数回テストを行うところまで出来ました。

ロードマップ通り行かなかった理由について、タスクの掛け持ち数が多すぎて進捗が悪化した時に継続判断をしたこと、アクションプランを計画しつつも探索的に動いていたことにあったため、今年後半はその辺りを注意していきます。

チームビルディングに関しては、２週間ごと振り返りやカンバン運用を経て軌道修正しながらも、業務サイクルが定着してきたことは大きな成果でした。

今後、会社をより広い視野で理解し、品質というテーマについては深掘りし、何を実現できれば皆ハッピーになれるのか問いながら突き進んでいく所存です。

まとめ

アプリエンジニア２名がSETチームとして独立して半年の成果になります。

年内は全社プロダクト横断で当たり前品質を確立する地固め期間。

魅力的品質へのチャレンジはまだまだ続きます。

今後も継続してSETチームから取り組みについて発信していきます。

Mobility Technologies では共に日本のモビリティを進化させていくエンジニアを募集しています。話を聞いてみたいという方は、是非 募集ページ からご相談ください！