こんにちは。エムスリーキャリアでQAを担当している@tak_koheiです。
このエントリーは、エムスリーキャリア Advent Calendar 2019の19日目です。
今回は、私がエムスリーキャリアに入社する以前の「大昔に携わってきたQAのお仕事」を振り返り、エムスリーキャリアに入社してからQAエンジニアとして「これからやろうとしていること」を書いてみようと思います。
エムスリーキャリアに入社する以前の話*1
孤独なQA
QAのキャリアをスタートしたのはウォーターフォール開発の大きなプロジェクトでした。開発関係者が分散した環境に100人くらいいて、1～2年がかりでシステムを改修していく例のアレです。そこでは開発を進める組織とテストをする組織が2つに分断されていてコミュニケーションが乏しい関係性でした。テスト対象のシステムにどんな機能改修があるのかは直前まで殆ど知らされません。事前に情報がもらえてもエクセルファイルに羅列された一行コメントのみ、といった感じでした。
その機能が、どんな目的の施策に紐づくものなのか、どんな人が使うのか、どんな機能なのか、どんな実装なのか、全くわからないまま。どんな人が開発しているのか開発者の顔も見えません。機能を想像しながらテスト計画やテスト設計の検討を進めても、初期見積りすら怪しい状態。適切な成果物が作成できるわけもなく、実装が終わったテスト対象の機能をひたすら解読しながらテストドキュメントの修正とテスト実行を進めていました。
テスト中のバグも大量に検出されました。表示される文言が違うといった軽微な不具合から、機能仕様そのものが大きく変わってしまうような不具合が検出されることもあり、大量のバグチケットがプログラマーとテスターの間で行き交います。1件のバグ修正に2週間を要するといったことはざらにありました。よってスケジュールは常に遅延していて、市場にリリースした後もユーザー環境で不具合が出てしまい、テスターの責任が問われるといったこともありました。
今から思えばそんな環境でもQAとしてもっと改善できた部分はありました。コミュニケーションを改善し、無駄をできるだけ排除していけばもしかしたら良い方向に進んでいたかもしれません。ですが当時はその世界しか知らず、そんな状況が問題であること自体も認識できずに、ただひたすら困難な状況に立ち向かう日々だったように思います。*2
Scrumとの出会い
そんな中でScrumを採用したアジャイル開発のプロジェクトにアサインされることになりました。プログラマー/テスター/プロダクトオーナー/スクラムマスターといった様々なスキルセットを持つメンバーで構成される開発チームは、それまでの分断された関係性ではなく、ソフトウェア開発に必要とされる人たちがコンパクトに集約されたようなチームでした。そこではプログラマーとテスターが常に共生し、お互いを補完し合う関係にありました。多様性に富んだ開発チームメンバーやアジャイルコーチとの出会いは、それまで孤独だった私のQA人生を一変させたのです。
見積
例えば、見積はスプリント計画で全員が相談しながら決めていました。どんな実装をするかの情報からテストスコープが明確になりましたし（プログラマー→テスター）、どんなテストをするかの情報から実装するロジックが明確になりました（テスター→プログラマー）。一方の限られた視点では見えていなかった観点に気付かされることがお互いよくありました。見積の精度が上がるだけでなく、開発を始める時点で「なにをやるのか」「なにをやらないのか」が明確になっていました。機能の設計/実装をし始める前にテスターがテスト観点をプログラマーにフィードバックするので、実装直後の品質も高く保つことができ、テストしても殆どバグが出ないといったことも多々ありました。*3
設計/実装とテスト
スプリント中はタスクを共有してお互いが助け合っていました。例えば、大きな機能を追加する際、できるだけビックバンテストにならないようテスト可能な範囲まで実装したら、そこまでで一旦ビルドしてテストするなど、実装の粒度や順番を調整していました。設計/実装を進める中で計画時には気付かなかった要検討事項が見つかり予定通りに実装が進まなそうな場合、後回しにしていたテストデータ作成を前倒しするなどテスト作業の順番を柔軟に入れ替えたり、QAが検討に加わって問題解決をサポートしたりすることがありました。テスト中に検出したバグの原因調査も、バグを発見したテスターがコードの中身まで確認して原因を特定し、修正内容をプログラマーと相談してバグフィックスする、といったことも行われていました。
スピードと品質の両立がこの方法であれば可能なんだ、という確信めいた気付きがありました。また、何より自分たちの肌感覚として得られるプロダクト品質が、チーム全体に共有されている実感が持てていたことも重要だったように思います。
やり残したこと
過去に例のない短期間で開発したそのプロダクトは、市場にリリースされた後の数年の間に発生した市場障害は0件でした*7。その後、どんなことにも終わりはあるもので*8、QAエンジニアは孤独な世界に戻っていくことになったのです。
やり残した、と心に残っていることがあります。それは製販分離の組織だったために開発したプロダクトを売るビジネス側のステークホルダーや、実際に使ってくれるユーザーとの距離が果てしなく遠かったことです。距離が遠いためプロダクトやサービスの改善が開発チーム内に閉じてしまいがちで、よりアジリティのある開発にしたくてもできないジレンマがありました。QAエンジニアとして開発チームの改善に留まらず、もっと広い範囲でサービスやビジネスそのものの改善に寄与できるのではないか、という想いが残されました。
エムスリーキャリアに入社してからの話
あの体験をもう一度
あの時に体験した、プログラマーとテスターのコラボレーションによる圧倒的な品質とスピード感を、もう一度実現したいと思い続けていました。そしてやり残したプロダクトを作ることだけに留まらないQAエンジニアとしての可能性を見てみたい。その考えは日に日に大きくなり転職に至ります。2019年5月からエムスリーキャリアの正社員として採用いただき、今はQAチームの一員として通常のテスト業務に加えてQCD改善の活動に携わっています。
開発のより早い段階からQAエンジニアが検討に加わり、要件検討から設計の段階でテスト観点や仕様の懸念点をインプットすることで、仕様の不備やバグの混入を防止する施策。また、プログラマーが実装時にハマりやすい落とし穴に効率良く気付けるようなテスト観点リストの整備。QAチームの活動が品質保証を担う組織としてのQA（Quality Assurance）から、品質支援を担う組織としてのQA（Quality Assistance）へ発展させていくための取り組みを進めています。詳しい話はまた別の機会に書こうと思います。
更にその先へ
願わくは、QAエンジニアとして更に一歩踏み込んでビジネスサイドも含めたチーム全体の改善活動をしていくことが今後の夢です。Feature Team（依頼された機能を作るチーム）からProduct Team（プロダクトを成長させられるチーム）へ。そしてService Team（プロダクトを通じて提供するサービスを発展させられるチーム）、Business Team（ビジネスの一翼を担うQAエンジニアへ）という想いで日々を過ごしています。ONE TEAM。
楽しむ
最終的にこの一節が私の拠り所になっています。私たちQAエンジニアの理想。全てのQAエンジニアから孤独が取り払われ、本当の意味でQA活動を楽しめる世界になるよう頑張っていきたいと思います。
みんなが協力しているチームで働くこと、プロジェクトの最初から最後まで働くこと、業務のステークホルダーが開発チームと一緒になっているチームで働くこと、チーム全員で品質そしてテストに責任を持っている場所で働くこと、これらのことは、まさにテスターのユートピアだと私達は考えます。みな仕事の中に喜びを見出していて、孤独ではありません。アジャイル開発はアジャイルテスターの仕事への情熱に報います。
「実践アジャイルテスト ジャネット・グレゴリー リサ・クリスピン著 P.31 2.3.10 楽しむ」より 一部抜粋
参考文献
私の心を支えてくれた皆さまに感謝。
*1:主に請負契約や派遣契約で”協力会社”の一員としてQA業務に従事していました
*2:という小説を読んだことがあります。
*3:従来のテスト方法ではあまりにバグが出ないので、最終的にはセッションベースの探索的テストを部分的に導入していました
*4:物理カンバンを使って、すべてのタスクを付箋に書き出して運用していました
*5:既存の自動テストツールもありましたが動作が遅いのとCI環境に統合できなかった
*6:気になっていることや不安に思っていることをプログラマからヒアリングして、その情報を元にテスターが時間制限付きの探索的テストを実施していました
*7:但し、開発チームをその状態まで成長させるのに2年はかかっていたと思います
*8:派遣契約終了
