この記事は 食べログアドベントカレンダー2022 の14日目の記事です🎅🎄
はじめまして、磯部と申します。
わたしはテストエンジニアとしてのキャリアは約15年ほどになり、様々な開発プロジェクトに関わってきました。 JSTQB Advanced Level Test Manager / Test Analyst や、 Certified ScrumMaster も保持しており、アジャイルテストチョットデキルと自認しています。
2022年4月から、食べログオーダー開発チーム（以下では単に「開発チーム」と呼びます）に1人目のQAとして参画し、開発チーム内のQAチームの立ち上げをしました。 QAという役割を追加することにより、開発チームがサービスをより速くより安定してリリースしていけることを目指しています。
半年間で、テスト活動のシフトレフトをはじめとした、様々な活動を行いました。 その活動をご紹介して、みなさまの日々の開発活動やQA活動に参考にしていただければと思います。
背景
食べログオーダーは、レストランにいらっしゃったお客さまが自分のスマートフォンで注文をする、いわゆる「モバイルオーダー」を実現するためのシステムです。 実際には、店舗向けやお客さま向けなど、いくつかのWebアプリやネイティブアプリを連携させてご利用いただきます。
わたしが参画したのは、クローズドベータ版をご利用いただいているお客さまもありつつ、パブリックリリースを目前に控えたタイミングでした。 この段階では、開発チームにはQA担当者はおらず、開発者がお互いにレビューやテストをすることで開発を回していました。 いま現在バグだらけで困っているわけではないけれど、このままではいつか破綻するのではという不安があるという状況だったようです。
注文というレストランの業務に大きく影響するシステムです。 プリンタやスタッフ向け端末などハードウェアもシステムに含んでいます。 従来のWebベースの開発よりも高い品質が要求されることを、開発チームでは想定していました。
もともとあったアジャイルマインド
開発チームの特筆すべき点として、チームビルディングがとても上手くいっていたということです。 スクラムやエクストリーム・プログラミングのようなアジャイル開発手法を直接的に採用していたわけではないのですが。 アジャイルソフトウェア開発宣言に見られる精神が、自然に実現されていました。
「顧客との協調」
お客さまもまだ少なく、企画メンバーがご訪問して要望を聞き取りし、即座に開発チームに伝えてくれていました。 開発メンバーがお客さま先に訪問することもあり、開発者が顧客目線を忘れないでいられる環境です。
開発メンバーがプライベートで利用したレストランにモバイルオーダーが入っていた、といった報告が共有されたりもしました。 ここはウチのがいいね、ここはマネしたい、といった意見がかわされ、開発のモチベーションにもなっていました。
「変化への対応」
事業分野が既存サービスとは少しずれていたため、既存サービスと独立して開発をはじめています。 システム上も、既存システムと完全に独立ではないものの、結合点は非常に小さいです。 そして組織としては、企画メンバーやデザイナーも参加して、機能横断的なチームを形成していました。 このため、小回りの効くベンチャー企業のような対応ができています。 実際に、開発予定になかった緊急の差し込み対応を協力してやり切り、それが営業的な成果につながったこともあります。
「個人と対話」
良いコミュニケーションをとるために、さまざまな工夫がされていました。
毎日の朝会や週1回の振り返り会のモデレーターは、持ち回りで担当します。 司会役として回しているうちに、自然にメンバーの顔と名前が一致しました。
朝会では「今日のKAWAII」というコンテンツが愛されていました。
メンバーのうち1人が、可愛いと思う写真（動画も多かった）を毎朝紹介するというものです。
可愛いの解釈はひとそれぞれで、モコモコの子犬の写真のような王道から、高層マンションの外観写真という 謎な 個性的なものもありました。
QAチームの活動
ここからは、開発チームの良いところを殺さずに、QAチームがどのような活動をしたかご紹介します。
テスト活動をシフトレフトしてスピードアップ
QAとして参画してまず手をつけたのは、テストです。 といっても「システムテストが終わってないならリリース不可」のようなゲートキーパー式のやり方は、メリットがないと考えました。 チームの技術力と協力的な関係から可能になっている速い開発スピードを落とさずに、効果的なテストをどうするか。
当初は「こういうテストはしてますか、必要ないですか」と聞くことからはじめました。 「やらないと出させない」ではなく「市場でバグが出たら困りますよね」という姿勢です。 もともと、しっかりと顧客を向いて開発するチームなので、すんなりと協力体制ができました。
次第に、要件定義の初期段階からQAが関わるようになり、シフトレフト、つまり、テスト活動を上流から開始できるようになりました。 よく言われるシフトレフトの効果として、仕様の曖昧さや矛盾を早期に指摘し、手戻りを防げたこともありました。
他に効果として大きかったのはテスト準備です。 複数の案件を並行して開発しており、複数のアプリケーションが連携したシステムなので、案件によってテストに必要な環境や機材が異なります。 計画段階でQAが入って整理することで、テスト準備が効率的になりました。
テスト実施については、当初はQAの人数も少なかったので、引き続き開発者に行なっていただくことが多かったです。 しかし、開発の設計や実装と並行して、テスト設計やテスト準備を行なっておくことで、テスト実施の日数を短くできました。 チーム全体を見たときのスピードアップと品質向上につながりました。
プロセスを明示して手戻り防止
前記のようなテスト活動を行なっているなかで、ルール化した方がよいこと、ルール化しているのに知らない開発メンバーがいることが目立つようになりました。 チームが成長していくタイミングだったこともあり、毎月のように新しい開発メンバーが参画してきます。 特に、どのタイミングでどういったタスクがあるといったプロセスについては、都度伝えるには限界があります。 「ドキュメントより動くソフトウェア」とはいえ、前者の価値も認めるのがアジャイルです。
そこで、参画して3〜4ヶ月くらい経った頃に、開発プロセスの整理整頓を行いました。 具体的には、案件の開発プロセスをConfluenceページに書き出して、プロセスごとのチェックリストを作成しました。 これらは後に、Asanaタスクのテンプレートや、GitHubのPRテンプレートにも反映してもらいました。
ユニットテスト、結合テスト、ステージングテストといったテストプロセスも定義し、スコープを明示しました。 オーダーチームでは、開発案件単位で全アプリケーションを結合しテストすることを、結合テストと呼んでいます。 案件はサイズも性質もさまざまなので、どういった条件ではどういったテストをする必要があるかも明文化しました。
これらの文書は作って終わりではなく、振り返りやバグの分析を受けて、追加したり修正したりといったフィードバックを続けています。 その結果、手戻りを防止でき、新規参入の開発メンバーの立ち上がりもスムーズになりました。
ところで、これらの活動の中で印象的だったことを紹介します。 リリースプロセスについて、最初にわたしが書いた図では、トロッコの箱がプレゼントを積み込むため線路の端から落とすような絵でした。 開発メンバーから「捨てちゃうみたいなので、ロケットが飛んでく方がいい」という意見があり、わたしもなるほどと納得して今の絵に修正しました。 こういった言語化していない価値観が共有できているのは、本当に良いチームですね。
不具合管理を改善し良い循環へ
前記の活動と並行して、不具合管理を改善していきました。 これについては、試行錯誤がありました。
当初は、テストケースのExcelファイルに「不具合一覧」のようなシートを作成して、検出したバグを書いていました。 不具合修正する場合はAsanaタスクを起票するのですが、それまでの管理フローがないために混乱が多かったです。 テストケースは案件に関わるメンバーしか見ない点も問題でした。
案件ごとに不具合管理用のAsanaプロジェクトを作成したこともありました。 テスト実施している間の管理は、Excelよりも容易になりました。 しかし、案件外への情報共有ができない点は同じでした。
最終的には開発用のAsanaプロジェクトにタスクを追加するフローにしました。 起票やそのあとの運用を効率化するために、不具合を登録する用の「バグ」テンプレートも作成しました。 開発チーム全員が朝会で確認するプロジェクトでもあるので、案件外のメンバーにも情報共有できるようになりました。
不具合というのはチームにとっての経験でもあるので、これを活かすことも大切です。 まだ散発的にではありますが、企画やデザイナーなども含めたオーダーチーム全体で、不具合を振り返る会を開催しました。
不具合の振り返りは、バグを出したひとを責める場になってしまいがちなので、そうならないように工夫しています。 標語に掲げた「失敗なんてない、成功するか学ぶかだ！」は、エジソンの名言の言い換えです。 開発チームにもQAチームにも、バグが出たことに対してネガティブにならず、チャンスと捉えて活かすように折に触れて伝えています。 実際に振り返りの結果、仕様の見直しポイントが判明したり、企画やデザイナーのメンバーの仕様理解が進みました。 バグをポジティブに捉えることで、素早く報告し素早く修正して予防にも繋げる、良い循環を目指しています。
他に、修正済みの不具合を知見として溜めておくためのプロジェクトも作成しています。 将来的には、不具合の定量的な分析にも繋げていきたいところです。
まとめ
もともと、オーダーチームは、アジャイル・マインドをもって、楽しくスピード感のある開発をしているチームでした。 そのメリットを殺さずに、スピードアップや良い循環に貢献できるQAチームを立ち上げることが出来ました。 当初1人きりだったオーダーQAチームですが、現在は3名に拡大しています。 わたしは10月から別チームのQA立ち上げのためオーダーQAチームを卒業しましたが、今後もチーム仲良くチャレンジングにオーダーチームを支えてくれると確信しています。
明日は @yoneyamashumpei の「RatingBarで不具合を起こして学んだこと」です。お楽しみに!
