この記事はLITALICO Engineers Advent Calendar 2023 カレンダー2の25日目の記事です。
初めまして！LITALICOのQA（品質保証）エンジニアをしている@az_hです。
私がLITALICOへ入社したのは約2年前になりますが、そこからLITALICOワークスという就労支援事業の社内向けシステム開発プロジェクトの中でQAチームの立ち上げから携わり、今年の夏にリリースを迎えて現在に至ります。
今回は、私が事業会社のQAとして新規開発のリリースまでに実施してきた取り組みについて、特に利用時の品質を高めるために行ったことの一部として以下の3つをご紹介していきたいと思います。
- SQuaREの活用
- ユーザーストーリーの活用
- QA仕様書の創作
はじめに
私たちLITALICOのQAグループのミッション
一般的なシステム開発において、"QA＝テスト"のようなイメージが強いかと思いますが、私たちの目指すQAとは、「品質管理を通じて、開発チームやユーザーの安心を育てる」です。実装後のテストだけではなく、上流工程から品質をチェックし高めるためのアプローチに取り組んでいます。
開発プロジェクトに関わる人々や、実際に使うユーザーにとって、新しい機能をリリースするときには様々な期待や不安があると思います。ちゃんと動くかな？業務に役に立つかな？操作難しくないかな？操作間違えちゃったらどうしよう？意図しない何かで会社に損害出たらどうしよう？？など。
これらの不安やリスクを事前に確認し、低減していくことで安心してユーザーへ使ってもらえるようにする取り組みを行う役割を担っています。
例えば、開発者が設計した仕様があったとしても、その仕様通りに動くことを確認するのは"テスト"の役割となりますが、"QA"とは品質保証を意味するので、要求と合致しているか？その仕様で本当に問題ないか？という観点の検知も必要である立ち位置です。
要求と合致しないというのは、ユーザーの業務に役立てられない事象が発生するということですが、システムでも実現できないことや、コストや納期、必要度合いによっても、実装から除外することもあるかと思います。その場合においても、人の手による運用や回避方法があり、業務を回すことができる状態を証明することも大切にしています。
1. SQuaREの活用
SQuaREは”Systems and software Quality Requirements and Evaluation”の略で、システム及びソフトウェア製品の品質要求及び評価に関する国際規格 ISO/IEC 25000シリーズ、国内規格 JIS X 25000シリーズの総称です。「スクウェア」と読みます。
QAとして特に注目したものは”利用時の品質”です。利用時の品質の定義としては 「利用者がある利用状況において、利用者のニーズに照らして、製品・システムを利用できる度合い。」 とあります。
ISO/IEC 25010は品質モデルとして、利用時の品質に”有効性””効率性””満足性””リスク回避性””利用状況網羅性”を定義しています。それぞれの概要は以下の通りです。
- 有効性：明示された目標を利用者が達成する上での正確さ及び完全さの度合い。
- 効率性：利用者が特定の目標を達成するための正確さ及び完全さに関連して、使用した資源の度合い。
- 満足性：製品またはシステムが明示された利用状況において使用されるとき、利用者ニーズが満たされる度合い。
- リスク回避性：製品またはシステムが、経済状況、人間の生活または環境に対する潜在的なリスクを緩和する度合い。
- 利用状況網羅性：明示された利用状況及び当初明確に識別されていた状況を超越した状況の両方の状況において、有効性、効率性、リスク回避性及び満足性を伴って製品またはシステムが使用できる度合い。
（参考資料：つながるソフトウェア品質ガイド）
この品質モデルをベースに、それぞれの機能に対してどんな観点で品質をチェックしていけばよいのかのヒントを得られるようになりました。
2. ユーザーストーリーの活用
ソフトウェア開発において参考にしたユーザーストーリーのフォーマットとして、
「[ある特定の役割や立場] である私は、[目的や望みごと] をしたい。それによって [こんな利益やよいことが得られる] だから。」
というのがあります。
ユーザーの思考を持つことで、これから作ろうとするシステムや機能について、それを実現する方法を見出していく手法になります。
ドメイン知識が不足していたり、ユーザーの思考を考慮しないまま開発を進めていくと、要件漏れや、設計漏れなどが発生し、手戻りが後のフェーズになってから発生したり、そのまま気が付けずにリリースしてしまい、ユーザーの業務が回らなくなるような自体に繋がりかねません。
そこで、ユーザーストーリーに沿ってユーザーの要求を分析し、要件定義、設計、実装、テストと進めて行き、最終的に始めに置いたユーザーストーリーが達成できる状態を確認するまでを一つのゴールとしました。
なんでこの機能必要なのか？という要求レベルの情報は、ユーザーから説明頂ける機会が必ずしもあるわけではないので、そこは自分がユーザーになったつもりで、想像を膨らませます。
例として、スケジュール管理機能を作る要件があったとします。
いきなり想像せよと言われても難しい所もあるかもしれませんが、ユーザーストーリーの考え方としては、どんな人がいつ使うのかな？どれくらいの量があるのかな？という疑問を持つところから始まり、それを知るための情報を集めます。
次に、そのユーザーに自分がなったつもりで、このシステムや機能が仮になかった場合はどうなるのか？を想像すると考えやすくなります。それは、 この業務を、紙と鉛筆でやる場合を考えてみる のです。
紙と鉛筆でやるとしたら、まず、管理したい対象者を紙に書き出し、年と月と日、曜日などのカレンダーを書くイメージだと思います。そして、誰がいつどこで支援を希望しているのか、個別で申請された内容を書いていきます。また、一日当たりの定員数も決まっているので、それも数えて定員超えたら消しゴムで消して、別の日に調整して、、という感じで、これを毎月何十人分と書いたり、新規や退所した人の増減も意識して、、となるとかなりの労力になるし、書き間違いも多発してしまうのが想像できます。
このあたりまで考えてみると、ユーザーストーリーが見えてきたでしょうか。作業効率を上げることや、情報処理の正確性を求める観点も多くなると思います。
以下に、組み立てたユーザーストーリーの一例を書いてみます。
- 私は【支援員】として、【支援対象者の利用スケジュールを管理しやすく】したい。【大人数を少ないスタッフで最適な支援や記録を行いたい】からだ。
- 私は【支援員】として、【定員を超過しないように管理しやすく】したい。【法令違反（減算）のリスクを回避しなければいけない】からだ。
対象者は自動で一覧化されたり、カレンダーが年月日と曜日も切り替えたら自動で出てくるようにしたり、予定の選択肢、定員の集計、超過時のアラートなど、ある程度固定のものは自動で出せるようにしておくことで、有効性、効率性、リスク回避性など、利用の時品質を高めていくことが可能になります。これらが要件定義の基となり、開発者にとっても実現するための設計を決める際に反映しやすくなると考えています。
3. QA仕様書の創作
これは私がLITALICOに入ってからQAグループとして創作たもので、名前は造語です。
概要としては利用時品質のテスト観点を分析していくために、ユーザーストーリーとシステム及び機能の紐づけを行っていくためのもので、命名についてはもっと他に適切なものがあるかもな、、と思いながら今に至ります。
作業のフェーズとしては、要件定義や設計フェーズでの”静的テスト”という位置付けで行います。
こちらを作成する主な目的は以下の通りです。
- 前述のユーザーストーリーを洗い出すための材料となる情報の集約する
- 上流工程での要件チェックを静的テストとして実施し、早期の不具合検出に役立てる
- 実装後の動的テストのテスト観点として用いる
構成としては アプリ説明 と、 UX要素 の2シートに分けています。
内容については次に記載していきます。
(1)アプリ説明
まず一つ目のシートは、作ろうとしているアプリケーションの役割を語ります。
今回のシステムは情報管理や請求処理をする機能がメインだったため、それに向けた内容でテンプレートを作成しました。主な内容は以下の通りです。
- 機能の目的・役割（紐づく業務）
- 関連する請求情報
- 管理の単位
- 使う人
- 使うタイミング・内容
- INPUTにするもの
- OUTPUTするもの
- 業務で起こりうる間違いや困りごと
- 後続の業務・使用アプリ
- 滞りなく業務を遂行できるポイント
これらの項目を埋めるときに、「そういえば誰がいつ使うんだっけ？」「どんなふうに使いたいんだろう？」を把握するきっかけにもなります。それによって、”ユーザー目線”を持ち、ユーザーストーリーの想像に繋げていくことが可能になります。そんなのどこにも書いていないし、誰もわからないよ、という状況もあるかもしれませんが、わからないまま開発してリリースするのは利用時品質を担保できていないことにもなりかねません。
参照できる資料や情報は異なるかもしれませんが、デザインや、業務フローや、現場の業務で使われている運用の資料などを見たり、時には業務に関する社外の情報なども調べて、できる範囲で集約させていきます。
ここで洗い出したものが、 利用時の品質を評価する際に用いる”テスト観点” として活用できるようになりますし、チームメンバーで分担してテストするときも、これを共有することでキャッチアップコストの低減も可能になります。
(2)UX要素
二つ目のシートは、UX要素を分解し、一つ一つのコンポーネントの役割を語ります。
要件や設計フェーズでデザインされているコンポーネントについて、開発者が作成している画面定義書等には、このボタン押下で何を表示する、という振る舞いは記載されていることも多いと思います。でも、そもそもどうして？というところまでは明記しないかと思います。
ここにはそれぞれの役割（ユーザー価値）を明記し、だからこのボタンはこう動く必要があるよね、これはどんなことを識別させるため必要な表示だよね、だからこういうテストが必要だよね、という分析にも役立てることができます。
例えば、”登録ボタン”と”完了メッセージ”の設計があったとします。
仕様としては「ボタンをして登録できること」になりますが、このラベルの必要性として”登録”なのか”削除”なのかを識別させるためにあることや、「完了しました」があれば「失敗しました」というようなメッセージで、ユーザーがその操作の結果を知り、次に進む判断をするための情報が得られる表示の設計がされている必要があります。これが日本人向けなのに英語だったり、伝わらない言葉になっていないかも、利用時の品質の観点になります。
仮に失敗していた場合に、ユーザーが認識できる表示になっていなかった場合は、ユーザーは登録できたのか、できていないのか不安になり、重複して同じ登録をしてしまうかもしれません。もしくは、登録に失敗していることに気が付かず、大事な情報をどこにも記録できていないというリスクも招きかねません。リスク回避性を高い状態にするには要チェックです。
決められた仕様であることを確認するだけのテスターではなく、QAとして、その仕様で本当に問題ないのか？ユーザーの誤解を生まないか？ユーザーが混乱して業務に支障が出ないか？を気にすることで、コンポーネントや挙動に対する品質を高めることが可能になります。
おわりに
ここまで読んでいただき、ありがとうございました。
現在も試行錯誤中なところも多く、上記の内容が完全な状態で活用できていないこともありましたし、リリースまでに見つけられなかった不具合もいろいろありました。。ドメイン知識やユーザーストーリーが不十分なところも痛感していますが、これからもインプット、そしてアウトプットに励み、品質保証と向き合い続けたいと思います。