はじめに
はじめまして。freee株式会社の上村と申します。人事労務freeeやプロジェクト管理freeeの品質保証業務を担当しています。
前回の記事では、新規プロダクトの開発でどのようにアーキテクチャーを選定して、どのように開発を進めていったのかを、エンジニアの増田と熊倉からご紹介しました。今回は、品質保証担当として、新規プロダクトを世の中に提供するために大事なのはなにか、そのためにどのように取り組んでいったのかをご紹介します。
スピードと品質を確保する最善策を探る
これまでのfreee本体でのサービス開発は、ウォーターフォール型が主流で、エンジニアが実装した機能を最後に確認するビッグバンテストを行うケースが多かったです。当然ながら、この方法では最後のテストフェーズで不具合が多く見つかるため、その対応に時間がかかり、リリースが遅延するこも多々ありました。
今回のプロダクト開発は、freeeとしてもまったく未知の領域への挑戦であり、新しい価値を創出していくためには、何度も仮説検証を繰り返しながら開発していくのが重要だと考えました。そのため、コミュニケーションを重視し、仮説検証に柔軟に対応できるスクラム開発を採用することになり、品質保証のやり方も全てゼロベースで考えることにしました。筆者自身が開発プロジェクトのスタート直後にfreeeにジョインしたこともあり、これまでのやり方を一からキャッチアップするよりも、新しい方法を構築する方がやりやすかったという背景もあります。
まず、スクラム開発を進めていくうえでどのように品質を担保していくかを考えました。スクラムを含むアジャイル開発では、フィードバックサイクルを早く回すことを重視した開発体制なので、うまくやらないと品質が置きざりになることもあります。スピードと品質というトレードオフになりがちな2つを確保するために以下のことをやっていくと決めました。
- チームの壁をなくし、ONE TEAMでスクラム開発を進める
- テストも早いサイクルで回す
- ユーザーの視点でサービス全体の品質を担保する
メンバーの固定化でチーム間の壁をなくす
要件定義書や仕様書をもとにテスト設計を行い、実行していくウォーターフォール型の開発と違い、スクラム開発では、1週間という短いスプリントの中で要件を決めて、開発を進めます。そのため、最低限のドキュメントしか作られず、必要なことはチームで決めて開発していくので、チーム内のコミュニケーションがこれまで以上に重要であると考えました。
そこでまず、QAメンバーを固定化し、プロジェクトにアサインしました。これまでの開発では、QAメンバーが必要になるのは最終フェーズに限られるため、手が空いたメンバーが他プロジェクトのヘルプをしたり、忙しいプロジェクトには大勢アサインしたりするなど、メンバーが固定されることはありませんでした。それに伴い、開発チームとQAチームといった組織間の壁もあり、十分なコミュニケーションができているとは言えない状況でした。しかし、今回はメンバーを固定してプロジェクトにアサインしたことで、朝会やスプリントレビューなどの全てのミーティングに参加するようになったため、仕様のキャッチアップや、リスクへの提言などがカジュアルにできるようになり、開発メンバーとのコミュニケーションが格段に良くなりました。
テストも早いサイクルで回す
前回ご紹介した通り、開発段階では実装の次のスプリントでテストを実施しています。よって1つの機能は、プランニングから約2スプリントでリリースすることができるようになっています。
スプリント内の実装とQAの流れ
このように、実装とテスト計画を同じスプリント内で行うことで、下記のメリットがあります。
- テスト計画中に仕様の曖昧さや不備に気づくことができ、テスト前に実装漏れやリスクを減らすことができる
- 直近で開発したコードは、何か月も前に実装したコードの修正よりも圧倒的に早く対応することができる
- テスト、不具合の発見・修正、修正確認のサイクルが短期間で行えるため、テストデータを作り直したり、テスト環境の再構築をしたりといった、時間のかかる作業を削減できる
昨今のソフトウェア開発において、アジャイル開発とEnd to Endテスト（以降、E2Eテストと呼びます）によるテストの自動化は切っても切れない関係になりつつあります。早いサイクルでリリースしていくためには、同様に早いサイクルでテストを行うことが非常に重要だからです。
プロジェクト管理freeeの開発では、開発の初期段階からE2Eテストを実装することに決めました。E2Eテストの構築は、それなりにコストがかかるため、以下必要最低限の項目に絞り、実施することを目指しました。
- ユーザーストーリーを実現するメイン機能が問題なく使えること
- マイクロサービスにおける各サービスとの疎通が担保できていること
サービスを提供するうえでメインの機能が正しく動かないということは致命的です。プロジェクト管理freeeでいうと「従業員を招待できる」「工数の入力ができる」「工数の実績が確認できる」といった機能は、ユーザーストーリーを実現するために、絶対に動作しなくてはならない機能となります。最低限、これらの機能が動作することはリリースするうえで必須となるのですが、そのために特に気にしたのが、「作り込み過ぎない」ということです。開発中のサービスは、常に変更が入るため、細かい部分まで作り込んでしまうと、メンテナンスの工数が増えてしまうからです。
自動化するうえで、もう一つ気をつけた点があります。今のWebサービスでは、マイクロサービスアーキテクチャーを採用し、いくつものサービスと連携しながら、1つのサービスを作っていくのが主流となっており、freeeも同様です。マイクロサービスにはいろいろメリットがありますが、気をつけないといけない部分もあります。例えば、自分達が作っている部分に問題がなくても、連携しているサービスと100％繋がる保証はないということです。連携先のサービスがダウンしたり、仕様が変わって繋がらなくなったり、というのはよく聞く話です。これらは外部要因とも言えますが、顧客から見た場合、連携サービスが動作していないことはプロダクトの問題となります。
よって常に連携サービスと繋がっており、プロジェクト管理freeeが問題なく動作していることを担保する必要があるのです。
幸い、他サービスで既にE2Eテストの実績があったので、それらの資産を使うことにしました。今回は以下の技術を使って構築しています。新規サービスということもあり、今後修正が頻繁に行われることを見越して、SitePrismを使ったPageObjectモデルを実現しています。
- Ruby
- RSpec
- Selenium Webdriver、Capybara、SitePrism
E2Eテストは、問題がないことを確認するためのテストであって、不具合を見つけるためのテストではありません（稀に不具合も見つかりますが）。あくまでもメインは手動によるテストであり、E2Eテストの役割を明確にして、少ない工数で最大限の効果をあげられるように設計することが大事です。プロジェクト管理freeeでは、上記に絞ったE2Eテストを構築しました。工数的にはQA工数全体の5〜6%程度です。
