はじめに
株式会社LITALICOでエンジニアをやっている@kazuisです。
この記事は『LITALICO Engineers Advent Calendar 2024』の16日目の記事になります。
障害者福祉・介護領域でエンジニアリングを使って教育領域、働き方領域をよくするために、奮闘しております。
LITALICOの事業所運営を行っており300以上の事業所を運営している大きい会社です。
ITエンジニアも200人以上在籍しており、障害がある当事者様向けのメディア：LITALICO仕事ナビや保護者様向けのメディア：LITALICO発達ナビを運営しております。この記事は全国の障害者福祉・介護事業所を運営している事業所様向けの業務支援プロダクトを開発しているQA組織での品質保証活動のお話です。
本記事の概要
LITALICOの品質保証はリスクベースドテスト戦略を実行するために、ユーザーストーリーを使ってリクス分析を行い、利用時の品質を保証できるように品質とコストと開発スピードのバランスを判断して活動してます。
利用時の品質とは
LITALICOの品質保証の大切にしている考え方の1つにニーズ・ユーザ価値が満たされてなくなった状態を利用時の品質が悪いと定義しプロダクトの価値が下がるを防ぎたい考えがあります。製品品質は、ざっくり言うと仕様通り動いている状態として定義しております。動作している事を保証するテストではなく、「利用時の品質」に問題ない状態を保証するテストを実施しQCDのバランスを実現する完成条件をつくる仕事をしています。
一般的には、利用者がある利用状況において、利用者のニーズに照らして、製品・システムを利用できる度合いとして定義されており、ISO/IEC 25000シリーズ（SQuaRE）で定義されています。
品質保証と「利用時の品質」
利用時の品質に着目して品質活動を行うと市場に出てからの失敗が減り、ブランドやプロダクトの信頼低下、不具合における経済的な損失、サポート業務のパンクなどを防ぐことができSaaSプロダクトの市場価値を高めることに貢献できると考えています。
LITALICOのSaaSプロダクトは業務システムです。業務が止まりお客様の事業に影響がある状態を作ってはいけません。しかしながら、製品品質にある「仕様通り正しく動いていること」の品質特性「機能適合性」は100%不具合をなくす事はできません。開発スピードとコストと品質のバランスを判断する基準として「利用時の品質」を大切にしております。リスクの高い部分に優先的にリソースを割り当てるテスト戦略を方針としています。(リスク=実運用環境での事業価値を下げる事)
リスクベースドテスト
リスクベースドテストは、テストの優先順位を決めるための実践的な手法です。リスク評価が正確であれば効果的にコストと時間を最適化できます。特に重要な部分を重点的にテストすることで、製品の信頼性と品質を高めることが可能です。業務システムは、法令やルールが多くテストケースの組み合わせで何千、何万とテストケースが増えます。全部はできない、やらないと判断するときのリスク評価・基準を明確にする事がポイントです。
参考資料
IPA: つながる世界の利用時の品質～IoT 時代の安全と使いやすさを実現する設計～
ユーザーストーリーテストとは
ユーザーストーリーテストと聞いて具体性が浮かぶ人は少ないかもしれません。JSTQBなどでも具体例は言及されていませんが、受け入れ基準がテスト設計や分析の基盤となることが述べられています。受け入れ基準や、受け入れテスト駆動開発（ATDD）などが言及はされています。テスト駆動(TDD)などにも使われる場合もあり、ユーザーストーリーをベースとしてテストケースを作っていくテスト手法と理解すれば良さそうです。
LITALICOではATDDの開発プロセスではありませんが、ユーザーストーリーをリスク分析やテスト計画、テストケース作成に使っております。
自然言語にする意味
ドメイン知識の解像度・理解を判別しやすい
文章理解モデルのテキストベースモデルと状況モデルという認知プロセスがあります。ドメイン知識を活かし、リスクや影響範囲と関連付けて構築する手法として自然言語は効率的であると判断して採用しています。一言でいえば、何がわからないのか判断しやすいという事です。
テキストベースモデルは、文章や記述の表面的な情報を構造化し、記憶に保持するモデルです。ここでは、仕様書やユーザーストーリーの言葉や単語そのものに焦点が当たります。文章を読んでわかるものと理解してください。
状況モデルは、テキストベースモデルを超えて、文章が表現する状況やシナリオを読み手が構築するための認知的枠組みです。これは読み手の知識と単語や言葉が紐づき、新たな価値と連想ができている状態です。「ユーザーがログイン後にダッシュボードを閲覧できる。なぜなら、最初にダッシュボードの状態を見て業務の優先度を決めたいからだ。」というストーリがあった場合を例にします。
「ユーザがログインできる」という事柄を認知できるのがテキストベースモデルになります。そこに関連する「状態を見て業務の優先度を決める」とした場合、どのような状態なら優先度が上がるかは読み手の経験と紐づけされないと解像度があがりません。
テキストベースモデルで文章が理解できてない状態だと、そもそも単語など知らない用語が多くて認知負荷が髙い状況です。システムの受け入れ基準や仕様が理解できない状況になっています。プロダクトの機能やドメイン知識をつけないと開発できないレベルです。基本的な知識をつけるように勉強する必要がありそうです。
状況モデルの表象までいくとシステムの影響範囲や、ユーザがシステムを使ったときの困難さを理解できるレベルになります。文章を読み、影響範囲がや結果が推論できないというのはドメイン知識と関連付けができてない状況なので具体的な業務イメージをドメインエキスパートと話してイメージできる状態にしないといけません。
共通認知を作りやすい
自然言語での仕様表現は、ドメインエキスパートにも理解しやすく容易にレビューし、矛盾や曖昧さを指摘するのに役立ちます。そういう意味でユーザーストーリー形式は、受け入れテストにも活用しやすいです。
ユーザーストーリーの活用ポイント
- 言語化のレベルでドメイン知識の解像度が判断できる
- エンドユーザーの視点で記述されたシナリオを基にしているため、システムの価値を直接的に検証できる
- 受け入れ基準に基づいているため、開発チームとPdMでQAの共通のゴールを明確にできる
- 自動化しやすい（Gherkin構文を使うと「Given-When-Then」で仕様とテストを統合可能）
- 探索的テストの観点をテスト実行する担当者間やチーム内で平準化しやすい
ユーザーストーリーテストをストーリーマッピングする
前提条件
LITALICOはUXデザイナの方々がいらっしゃるので、ストーリーマップなどを使ってワイヤーフレームを作りながらプロダクトデザインされています。コアになるストーリーはUXデザイナが考えてPdMや開発、QAと意見交換しながら作成してくれています。品質保証は、このストーリーをベースにしつつサブストーリーや品質ストーリーを補完してユーザーストーリーを分析やテスト計画に活用しています。
リスクベースドテスト戦略のストーリーマップ
※ストーリーの書き方が雑すぎる。(≧∇≦)b
サブユーザーストーリー・品質ストーリーの発見
前述した通りですが、LITALICOにはUXデザイナーがUXを定義しながら開発を進めるプロセスになっています。ワイヤーフレームがある前提でサブストーリーを作っていく流れになります。このやり方なら既存のシステムや自分たちで開発していないプロダクトの品質を検証するのにも応用できると思います。
1つの画面（CRUD単位、もしくはモーダルなどのサブ機能も含める）をベースにストーリーを見つける会議を行うのがいいと思います。1つの画面には、たくさんのコンポーネントや暗黙的なルールが隠れています。
この画面は、「発達ナビ 施設運営ソフト」というプロダクトのログインが画面です。
コアのストーリーはアカウント情報をいれたらログインできることなんのですが、サブストーリーを見つけるときのコツは画面を分解するという事になります。ロゴやサービス名、チャンクレイヤーも含めて何かしらの利用時の品質に関連する期待値が必ずあるものです。 コンポーネント毎にルールがあるのでそれを具体例を話しながら、解像度をあげていきます。 この場合だとアカウント名の命名規則、パスワードルール、ロゴのレギュレーション、セッションの時間などルールは暗黙化されやすいですので具体的にペルソナを決めてケースやシナリオを話ながら複数人で進めていく事をお勧めします。
ユーザーストーリーの文書化
解像度があがってきたらユーザーストーリーにしてみます。文書化することによって、曖昧だった理解ところに気づくこともあると思います。当たり前だなっと思うこともストーリーに書いてみるのがいいと思います。
ユーザーストーリーをわかりやすく書くやり方は、全部は割愛します。（世の中にたくさんありますし、自分も修行中です）INVESTは良いユーザーストーリー（PBI）を作るための基準です。その中でも「価値がある (Valuable)」は、良いユーザーストーリーを書くときに注意が必要だと思っています。
業務システムは、そもそも業務が難しいので「価値」を理解するのがとてもハイコストです。ストーリーの発見で具体例を上げながら解像度をあげていく必要があります。解像度が低い状態でストーリーを書くと価値を書くべきところに気持ちを書いてしまう場合もありました。
ストーリーのフォーマットは以下のように書くとよいとされています。
[誰（役割や立場）] は [機能] したい。
[（それにより）〇〇という利益や良いことがある] からだ。
例えば、勤怠を打刻するシステムがあったとします。
良くない例だと利益などの価値が書かれず、正しく認識したい気持ちを書いてしまっております。
社員Aさんは、現在時刻を正しく認識する必要がある。時刻を正しく認識したいからだ。
利益や価値を書くとなると以下のようにルールや基準を守る必要性などの価値や期待値を含むストーリーにして業務の解像度や達成基準を作っていく根拠にしていく必要があります。
社員Aさんは、現在時刻を正しく認識する必要がある。なぜなら、労働基準法で1秒単位で出勤時間を記録する必要があるからだ。
ログインしたい。ログインしたいからだみたいなストーリーは利用時の品質を表してはいません。プロダクトチームに新しいメンバーが入ってきても価値が共有できる文書を書く必要があります。
非機能要件
アジャイルテストだと品質ストーリーと表現する事もあります。セキュリティは性能に関するストーリーも定義しておくと良いです。この場合は、セキュリティ基準やキャパシティプランニングなどデータが必要な場合もあります。
リスクの選別
どのストーリーが利用時の品質が満たされなかったとき、最もリスクが高いかを洗い出します。影響度（ビジネスやユーザーに与える損害）× 発生確率で優先順位を決定します。このときに代替手段や、リスク回避策も考える必要があります。PdMと話しながら決めます。
テスト計画
高リスク領域にリソースを集中させるテスト計画をつくります。網羅性を作り込む必要性がある場合はデシジョンテーブルなどを作ってパターンを絞り込んだり、事業影響を調べるためにデータ調査を行いながら計画を作ります。計画時のテストケース数などで見積りを行い、高リスク領域にリソースを集中させるための判断材料にします。探索的テストの場合はケース数を判断するのは難しいです。例えば、5分で1ケースなど決めて時間を計画してケース数にすると判断基準が揃えられるので判断材料になります。
ケースの作成
ユーザーストーリーは構造化された文章なので、文章を分解をしながらケースを作ります。
-
ユーザーストーリーに基づくテストケースの作成
- ユーザーストーリーに記載された受け入れ基準を元にテストケースを設計
- 例:
「ユーザーがログイン後にダッシュボードを閲覧できる。なぜなら、最初にダッシュボードの状態を見て業務の優先度を決めたいからだ。」
といった要件に対し、以下のようなテストケースを作成。- 正しいアカウント情報でログインできる
- 誤ったアカウント情報でエラーメッセージが表示される
-
受け入れ基準の達成確認
- ユーザーストーリーの最終価値を含めたテストシナリオを実施し、合否を判定する
- この場合だと「ダッシュボードの状態を見て業務の優先度を決められる」
- ケース作らない場合でも探索的テストを併用して想定外の挙動を確認する
- ユーザーストーリーの最終価値を含めたテストシナリオを実施し、合否を判定する
-
BDD（行動駆動開発）の利用
- Gherkin記法（Given-When-Then）などを用いて、ユーザーストーリーを具体的なテストシナリオに変換する
- 例:
シナリオ: 正常なログイン
Given: ユーザーがログインページを開いている
When: 正しいIDとパスワードを入力して「ログイン」ボタンを押す
Then: ユーザーはダッシュボードにリダイレクトされる
And : ダッシュボードをみて次の業務の優先度が判断できる
非機能要件の評価
ユーザーストーリーに関連する性能、セキュリティ、ユーザビリティといった非機能要件についても評価する。この場合は、キャパシティプランニングなどデータをもとにした負荷を発生させたりするようにします。
業務要件の場合、業務ごとにどの程度の時間で業務が終了するのか設計されているはずです。もしなければ、利用時の品質を満たす業務にかかる時間を定義し、テストケースに定義する必要があります。
テスト実行と再評価
リリース判定を行います。検証した結果、残ったリスクと、計画時にトレードオフしたリスクをレポーティングして事業リスクを判断できるようにします。テスト結果を基にリスクが軽減されているか確認し、リリース判断の材料にします。 バグの数ではなく、システムを使った業務を遂行するのにどのようなリスクがあるのかを文章化して説明するのが判断しやすいです。 バグの数では事業リスクを表現するのは難しいですし、多くの場合、PdMや事業責任者は、バグの数で事業リスクを判断できるほどの解像度をもつのは難しい状況にあります。（忙しいとかビジネス方面のスキルが強いとか）。サポート業務が肥大化しないか等、事業全体のリスクも話し合いができるとプロダクト全体の品質を判断してもらいながら、事業をグロースすることができます。
終わりに
品質保証と聞いてテストと連想する人は多いと思います。
前述した通りではありますが、B2B向けのSaaS事業を成長させていくにはプロダクトの機能をテストするだけでは足りない事が多いと考えてます。
品質保証活動を通じて「安心」できるプロダクトを作っていきたいと思っています。
QAは製品品質ももちろん大切ですが、利用時の品質を保証するお仕事だと思っています。
* ブランドやプロダクトの信頼低下
* 不具合における経済的な損失
* サポート業務のパンク
リスクを安心に変えていきたい
* 業務が時間通りに終わり効率化もされて安心
* 法律や計算を不安なくお任せできる
* サポート業務の調査や応答が早く回答されて顧客は安心
AIを使ったり、新しい検証方法や業務知識をつけて品質つくる技術を高めていけると楽しいですよね。