上流工程でQAするなら、ユースケース分析をしよう

「早期テストで時間とコストを節約」とテストの7原則にもある通り、テスト活動はソフトウェア開発のライフサイクルの早期に始めるのが良いと言われています。

私は現在WEB系事業会社で自社製品のQAを行っており、要件定義段階からQAに入ることが多いのですが、その際に必ず行うようにしている「ユースケース分析」が一定の成果を得られることが多いので、今回記事にまとめることにしました。
少しでも参考になれば幸いです。

ユースケース分析とは

ユースケースとは、利用者があるシステムを用いて特定の目的を達するまでの、双方の間のやり取りを明確に定義したもの。利用者は機器を操作する人間以外にも外部の他のシステムなどを想定する場合もある。

IT用語辞典

要は利用者などをはじめとするシステムの関係者（アクターと呼びます）がシステムとどう関わるかを示したのがユースケースで、どんな関係者がいてどんな関わりがシステムにあるのかを分析するのが今回言及したいユースケース分析になります。

なぜユースケース分析なのか？

開発者「システムの開発が終わりました！」
QA「テストもOKです！」
リーダー「よーしリリースだ！　お疲れ様でした！」
----リリース後----
サポート「お客さんから連絡が来て、ヘルプページと画面が違うって言われているんですが、サポート側ではそんなリリースがあるって聞いてないです……」
データアナリスト「新機能がリリースされたら利用実績を分析しようと思っていたんですが、分析に必要なデータが送られてきていないです……」

ある日の開発現場での会話（フィクションです）

この会話までのことは少ないですが、実際にこれに近いことは過去に経験したことがあります。

システムの関係者を考えた時に、一般ユーザー（ECサイトでいえば購入者）を忘れる人はそういないと思いますし、一般ユーザーが行う動作はよく作り込まれ、そしてテストがされていることが多いと思います。が、得てしてバグというものは想定の外から来ることが多いもので、その一つとしてあり得るのがこの「必要なアクターを忘れていた」という仕様漏れです。この「忘れられるアクター」は、開発作業に直接関わってこないサポート担当者だったり、分析担当者だったり、運用担当者だったりします。もちろん社内の人に限りません。

そして、その忘れられてしまったアクターたちの関わりは重要じゃなかったのかというとむしろ逆なことも多く、漏れてしまうと経営判断ができなかったり、ユーザーに直接悪影響を及ぼしてしまう場合もあります。

なぜかよくあるのがリリースぎりぎりになってその関係者を思い出すパターン。迫るリリース日にどう考えても間に合わない、となってしまわないためにも、開発の早い段階で関係者を洗い出しておく必要があります。

また、アクターの存在を忘れてはいなかったけれど問題が発生してしまうパターンは以下のようなものが考えられます。

開発関係者「ユーザーが商品を購入できるようになったぞ。ヨシ！」
----リリース後----
サポート「商品の納品書と領収書が出せなくて、お客様が困ってしまってます」

ある日の開発現場での会話（想像です）

例えば商品を購入するにあたって、ユーザーが求めているものは商品の入手だけとは限りません。ユーザーが業務として商品を購入している場合、その購入を証明する納品書や領収書が必要になります。（最近だとインボイス関連のあれこれも関わってくるかもしれません）その人の仕事はその書類を会社に提出して初めて完了するわけですから、その人はそのシステムで目的を達成できなかった、ということになってしまいます。

これも、言われてみれば何ということでもないのですが、商品の購入フローにばかり目が行ってしまうと忘れてしまいがちなことです。アクター同様、こちらも早期段階で洗い出しておくべきことであり、私がユースケース分析をおすすめしているのは関係者とその目的どちらも分析することができるためです。

「関係者は誰だ」「何が目的だ」と考えれば、思い出すのはそれほど難しくない

「忘れていた」と前の項で書いた通り、開発関係者たちはそのアクターたちのことも、アクターたちの目的のことも、知らないわけではありません。（全く知らなかった場合もないわけではないでしょうが……）大体は開発に追われ、忘れてしまっているのです。

ですが、「このシステムに関わる人は誰だろう」「どんな風に関わるんだろう」「このシステムで目的を達成できるのかな」とそのシステムに関心を持つ人に焦点を当てて分析を行えば、アクターたちとその目的を「思い出す」ことは、さほど難しくはないのではないかと思います。

ユースケース分析のやり方

まず始めに言っておくと、個人的には以下のような図をわざわざ起こす必要は必ずしもないと思っています。もちろん、状況によってユースケース図に起こした方が分かりやすいという状況はあるでしょう。

典型的なユースケース図

アクターとその目的について思い出せればExcelの表などフォーマットは何でも良いと思いますが、私はマインドマップを使用しています。

あるアクターの影響を受けるアクターがいないかを考えるのも良いと思います。
今回でいえばユーザーが問い合わせる→それを受ける担当者がいる、など。

ここまで来てしまえばあとは考えるだけです。誰か忘れている関係者はいないか？　このシステムに影響を受けるのは誰なのか？　その関係者に必要な対応はシステムに入っているか？
過去の似たような案件で関わった人なども参考になるでしょう。

もしシステムにとって重要なアクターが社内にいたら、そのアクターを開発に巻き込んでテストしてもらうのも良いと思います。また違った視点が得られるかもしれません。

終わりに

仕様の漏れを早期に見つけられると結構な効果が得られますし、ユースケース分析自体はさして時間がかかるようなものではありません。もし今回ご興味を持ってくださる方がいらっしゃったらぜひ取り組んでみてください。

ここまで読んでいただきありがとうございました。