「ユーザ視点」とは何か - ソフトウェアの品質を学びまくる

　「ユーザ視点」というキーワードが先日、ソフトウェアテスト/QA界隈でネタになっていました。
　ブロッコリーさんのこのスレッドです。

「QAなのでユーザー視点でテストできる」と言ったりするときの「ユーザー視点」の要素分解をしたい。（※私自身は、この言葉は言わないがよく聞く言葉）

「開発者はユーザー視点で見れないのか？」はNo（見れる）と思っていて、そこには結局「ユーザー視点」という単語で隠れている部分があると思う。
— broccoli (@nihonbuson) 2021年9月1日

　「ユーザ視点をテストできるのは誰か？」という議論はさておき*1、そもそも「ユーザ視点」って何だろうという点について、思うところを書いてみたいと思います。
　語る人の数だけありそうな「ユーザ視点」の意味を知る由もなく、またわたし自身も複数の意味で使っていそうという前提でございます。いやっ考え浅すぎない！？というご意見もあろうかと思いますが、ご笑覧を。

とりあえずオレオレ定義

　わたしが第一に考える「ユーザ視点」というのは、「外部仕様や要件をあらためて問い直す姿勢」を意味しているようです。
　もう少しだけかみ砕くと、（あまりMECE的ではないのですが）以下の2つになります。

要件・仕様に合致しているのは前提として、「開発したこれって、ユーザが満足して使えるんだっけ」と我に返ること
各「部分」は正しくできたとして、「システム外も含めて業務*2全体はちゃんと流れるんだっけ」とシステムを業務の一部として見直すこと

みたいな感じです。

　たとえば図書館の業務のシステム化において、

ユーザの情報の登録・修正・削除を行う。

蔵書の情報の登録・修正・削除を行う。

蔵書の貸出・返却を行う。

蔵書の貸出予約を行う。

といった機能の要件が出てきたとします。この要件は仕様として詳細化され、実装もうまくいき、テストでも個々の機能が仕様を満たしていることが言えたとしましょう。
　そのうえで、業務シナリオをイメージし、個々の機能に閉じない、システムの外も意識したテストを行ってみたとします。

　ここで初めて、「貸出予約のキャンセル機能がないな！？これで業務は回るっけ？」と気づくかもしれません*3。「性能要件」は満たしているけれど実際ユーザにとっては遅すぎたり、「画面遷移仕様」には完全に従っているけれどユーザにはまったく直観的でない遷移かもしれません。
　こういった問題を検出するのが、わたしの考える「ユーザ視点」です。

疑うことはけっこう難しい

　要件定義から仕様・設計を定め、実装し、それをテストする。
　この段階を踏む中で、エンジニアは多かれ少なかれ、「将来の変更は想定するにせよ、要件・仕様といった成果物は、現時点ではおおむね妥当なはずだ」と考えているのではないでしょうか。だからこそ、インシデントレポートに対する「仕様です」は強力かつ理不尽なチカラを持ちがちだし、「だとしたら仕様が適切ではないのでは」という説得は時に大きな労力を伴うことになります。

　開発成果物にもいろいろありますが、いわゆる「上流」で作られたものほど疑うのが難しくなってきます。要件ともなると、絶対無謬の存在のように捉えられかねませんし、覆すのも困難ですよね。
　ですが、要件もまた、神ならぬ人（発注者だったり、発注者の要求を整理した開発側メンバーだったり）が作ったもの。考え漏れ・記載漏れ、間違い、一貫性の欠如というのは紛れ込むものです。

　「ユーザ視点」というのはそういった潜在的な間違いを前提として、いつの間にか正しいと信じていたものを、「これ、大丈夫？」とあらためて問い直す行為なのかなとわたしは考えています。「ユーザ視点」という想像もつかないような職人芸があるわけではないと思いますが、かといって誰にでもできる簡単な作業とも思えません。

　テストエンジニアは、「作られたものにはおそらく間違いがあるだろう」という、ある意味悲観的な姿勢でレビューやテストに取り組みます。
　「すべてのものを疑い続ける」というのはなかなか大変なこと。インプットした様々な情報を、「正しいもの」としてテスト設計しながら、「正しくないかもしれないもの」として批判的にチェックするというのはジレンマです。このジレンマに日々さらされているテストエンジニアが、ユーザ視点というものに切り替えるスキルと経験を得やすいというのは考えられることだと思います。