freeeの開発情報ポータルサイト

freeeの品質トゥギャザー:リスク洗い出し編

ども。皆のQAアニキ、freeeをテストするおっさん*1ことコヤマンです。

この記事はfreee Developers Advent Calendarの16日目です。※22日公開予定だったのですが、諸事情により記事公開を早めさせていただきました。

12/8(土)に弊社にて開催したシステムテスト自動化カンファレンス2018において「freeeの品質トゥギャザー」と題して弊社の品質への取り組みの発表があったのですが、そこで伝えきれなかった素敵な取り組みの1つである「リスク洗い出し」についてエントリーさせていただきました。

テストの目的

さて。リスク洗い出しのご紹介の前に改めて「テストの目的」とはなんぞや、というのをご紹介したいと思います。

JSTQBというソフトウエアテストの資格*2があり、ソフトウエアテストの広義の目的が4つ定義されています。

  1. 欠陥を摘出する
  2. 対象ソフトウェアの品質レベルが十分であることを確認する
  3. 意思決定のための情報を示す
  4. 欠陥の作りこみを防ぐ

この目的は、開発におけるシーンによって何が主目的なのか、という点が変わってきます。

DevOpsでのテストとシフトレフト

f:id:koyatest:20181211164636p:plain
DevOpsサイクル
※上図はeBayのHead of TestであるDan Ashby氏の記事の画像を元に加工のため書き起こしています

freeeは所謂DevOpsをしていると言えるのですが、DevOpsでは「継続的テスト」をするのが一般的です。

上記で箇条書きしたテストの主目的をDevOpsサイクルに当てはめると、以下のようになります。

f:id:koyatest:20181211234056p:plain
継続的テストとテストの主目的
※目的3の「意思決定のための情報を示す」は主目的にはありませんが、常に実施します

テストは「知ること」なので、フィードバック(情報提供)は早い方が良いです。 フィードバックが早ければ早いほど問題の解決が安上がりになりますので*3、テストの原則*4としてテストは早ければ早いほど良い(=効果が高い)と言われています。

そのため、開発の初期であるPlan,Branch,Codeのあたりでは目的4の「欠陥の作りこみを防ぐ」が主目的になります。 このように開発の初期にテスト活動することを「シフトレフト」と呼んでさまざまな取り組みがなされています。

freeeはリスク洗い出しでシフトレフト

freeeが扱うお客様のデータはクリティカルなものが多いため、品質を疎かにできません。 しかしながら品質を上げる、保つ活動をDevOpsの中でスピード感を持ちながら実施することが要求されるためにシフトレフトな活動をしています。

その中で代表的な活動が「リスク洗い出し会」(そのまんま)です。

リスク洗い出しでトゥギャザー

リスク洗い出し会を一言で表現すると 「みんなの"ヤバい"を共有して方針を決める会」です。

開発の初期段階からプロジェクトやプロダクトの情報を皆で共有して理解し、エンジニア以外の目線でもヤバいところ、不安なところを洗い出して方針を決めます。

具体的には以下のステップで進めます。

  1. 人を集める
  2. ヤバい、不安だを共有する
  3. 方針と担当を決める
  4. プロジェクトを進めるにあたり都度確認する
  5. 新たに気づいたら追加して共有する
  6. 最後に振り返りする

QA(テストするおっさん)の役割

おっさんは以下の活動をします。

  • トゥギャザーする人を集める(セールス、サポート、マーケティング、PM、Engなどなど)
  • 開催までに仕様・データ構造・アーキテクチャや連携する対象などをできる限り理解する
  • ヤバいと思うところを予めリストアップしておく
  • テストしようと思うことを予めリストアップしておく
  • 洗い出し会を設定する
  • リスク洗い出し会をファシる(みんなのヤバいを引き出す)
  • プロジェクト中に都度リスク表を確認する

このトゥギャザーによりコードを書く前あるいは書いている最中にフィードバックすることが可能になり、以下のような効果が早い段階で得られます。

  • 優先順位やセリングポイントの共有
  • マイルストンと熱量の共有
  • みんなが困ることとその対策
  • 構造・仕様の共有
  • 頑張るところ、頑張らなくていいところ*5の明確化
  • ヤバいの未然防止・手戻りの予防
  • いつまでに何をしないといけないのか
  • 各人が何をした方がいいのか
  • 何からテストをした方がいいのか、どの程度徹底的にやればよいか

集まった人全員に対し早めにフィードバックをすることが可能になります。

さらなる取り組み

freeeでは先日発表したDevOpsサイクルのMerge時におけるE2E per PullrequestやPlan,Branch,Code時に効果のあるリスク洗い出し、タイミングによってさまざまなシーンに効果のあるUX主導のユーザーテストなどによるシフトレフトだけでなく、Monitorとしてバグ分析やOperate時に専門家によるTesting in Productionなどシフトライトなどにも取り組んでいます。 その他、私はあまりトゥギャザーできていませんがサービス品質などの知覚品質を上げるための活動も動き始めています。

このような活動をできるのも、先日素晴らしいエントリーを裏freee Developers Advent Calendarに上げてくれた同僚のスーパーマサキさんをはじめとする素敵なメンバーがいてこそ、だと思っています。 このようにfreeeのエンジニアは品質トゥギャザーしながら、お客様にマジ価値を届けるために日々活動しています!

さて明日のfreee Developers Advent Calendarは自作キーボードの変態 伝道師こと id:foostan の記事です。 自作キーボード部の私も今から楽しみです!

*1:アジャイルチームに入ってテストしたり時々自動テスト書いたり色々やってます

*2:実は筆者はトレーニングコースの講師もしております

*3:不具合修正はコードに埋め込まれてから早いほうが安い、というのはWatts S. Humphreyさんの書籍でおなじみ

*4:JSTBにも「初期テスト」という原則があります

*5:エンジニアがやるべきところ、やらなくていいところなど