ユーザーになりきることで非機能要件を本質的な価値に変える
みなさん、生きてますか？暑さにやられていませんか？私は70%を下回ることのない自宅のむちゃくちゃな湿度に耐えかねて、試しに除湿機をレンタルして投入してみたところ、1日20L程の水が量産されるようになり、たまった水を捨てるたびに果たしてこれは下水道料金のタダ乗りになっていないだろうか……と心配しています。なお、湿度は50%前後になり大変快適です。
今回は、作っている自分自身が利用者になって解像度を上げることが、製品の本質的な差別化につながるよねって話を書きます。気軽に書き始めた割にはちょっと長くなってしまいましたが、お付き合いいただけますと幸いです。
プロトタイプを対象ユーザーの立場で使う
このnoteでも何度か話に触れていましたが、私は今年に入ってしばらく新しい機能のプロトタイプを作っていました。
DeployGateでは6月にキャプチャ機能のベータ版を出しました。キャプチャ機能は、アプリのQA時など、テスト端末内で取得したスクリーンショットと実行環境の情報を1アクションで共有できる機能です。現時点ではベータ版となっており、Androidアプリでのみ利用できます。
私が作っていたプロトタイプの機能は、このキャプチャ機能で動画も活用できるよう、スクリーンレコーディングの取得と共有をより手軽にするためのものです。
既に一部のお客様にもご協力いただき、全体的にいい反応をいただいています。しかし、実際に機能を使う利用者として、何がどうなっているとより価値があるのかという感覚をどうにも得られずにいました。
そんな中、DeployGateのAndroidクライアントアプリの改修に伴うQAテストを自ら実施できる機会が生まれたので、自分自身がQA担当者として実際にこのプロトタイプを使ってみることにしました。
QA業務を実際に行って得られたこと
今回担当したアプリのQAは、テストケースを作るところから行いました。DeployGateでは、テストケースの管理は今のところ専用サービスではなくGoogleスプレッドシートを使用しています。QAの経験はあまりないのですが、これまでのテストケースや過去のヒアリングで得た知見を参考になんとかテストケースを整えました。
ひととおりのテストケースが整ったあと、実際にプロトタイプの機能を使いながらテストを実施してみました。結果として、プロトタイプについては、基本的に想定していた通りの使い方や効果を見ることができました。特に、自分自身でその必要性を感じる場面に直面したことで、具体的なユースケースを実感を持って伝えられるようになったのは大きな収穫でした。今後機能を紹介するときに自信を持って利便性を伝えることができます。
また、利用者として「ここがこうなってほしい」という点もいくつか出てきました。一つ一つは「少し工夫したら使える」「少し待つことを許容すれば使える」といったワークアラウンドで回避できる程度のものです。おそらく、テキストとして上がってきていたら優先順位が低めの改善要望として積んでいたと思います。
しかし、今回実際のQA担当者としてテスト作業の前後の作業までを体験し、テキスト化された要望には現れないコンテキストを把握したことで、これらの重要度の認識は大きく変わりました。
作業中の思考をとにかく減らしたい
今回のプロトタイプそのものは、テストの作業中に発生する報告の手間やミスを減らすことを目的としていました。実際のテスト体験を経たことで、この「手間」に対する解像度が上がりました。強く感じたのは、とにかく作業の集中力を奪わないよう「テスト以外の思考」を挟む場面を減らしたい、という需要です。
「テスト以外の思考」について、ありがちな例で説明してみます。例えばスプレッドシートのテストケースを上から順に消化していく際、実施者はテストの判定結果と確認日時を入力していきます。
特に何も自動化をしていない状態で作業を開始すると、開始早々「確認日時」の欄に時刻を入力することが億劫になり、「判定を選択したタイミングで勝手に入力してほしい」と感じます。 Googleスプレッドシートには現在時刻の入力自体のショートカットキー(Cmd+Shift+;)があるため、最初はそれで十分だと考えていましたが、「判定を選択して、適切にカーソルを移動させて、ショートカットキーを押す」というのがどうにも手間だな、と感じて、途中でさっさとGoogle Apps Scriptを書いて対応してしまいました。上の画像で途中20分ぐらい間が空いているところがそれです。
視覚と短期記憶を使ったタスク同士の相性の悪さ
さて、なぜ手間だと感じたのかをもう少し掘り下げてみます。
QAテストにおいてテスターは、「手順に書かれた通りの操作を行って、結果が期待値と完全に一致しているかを確認する」ということを求められています。このとき、テスターの意識は感覚器、特に視覚からの入力に集中しています。
先月例に挙げた、人間の脳は感覚器からの入力と自分の記憶をたどることを同時には行えないという話に似たもので、視覚あるいは聴覚に注目を必要とするタスクを処理している最中に同じ感覚器を使う割り込みが発生すると干渉が大きく行動パフォーマンスが悪化するという調査があります。視覚と短期記憶を使うタスクを行っている最中に、同じく視覚と短期記憶を必要とするタスクが割り込むと、効率ががっつり落ちてしまいます。
スプレッドシートは本質的に人間側に大きな裁量を持たせたモードレスなUIなので、状態の把握や適切な操作には常に思考と判断が伴います。前述の「判定を選択して、適切にカーソルを移動させて、ショートカットキーを押す」という作業は、テスト対象とは別の画面上の状態を見て、カーソルの位置が適切かを判断し、ショートカットキーが押せて値が入ったかを確認する、といった別の種類の視覚的判断が要求されます。熟練していない場合はさらに「ショートカットキーを思い出す」という記憶をたどるタスクも発生し、これらの割り込みとテスト自体のタスクとの干渉が避けられません。
もしここで、「判定結果を入力し、その時間を記録する」という操作が単一の手順で完了できるものになれば、短期記憶の干渉がなくなり、テストそのものから注目をずらすことなく安定したパフォーマンスで作業を継続できます。
確認日時の自動入力という単体で見れば小さな「機能」が、「行動パフォーマンスの低下を一律防ぐことができる」効果を持つのであれば、長期的な影響を鑑みても後回しにしていいものではありません。本当にささいな違いですが、作業の効率に非常に影響するという実感を持ったことで、起きている現象と重要度を理解することができました。
体験を経ると関連機能の背景も埋められる
さて、もしわれわれがこのスプレッドシート、もといテスト管理ツールをサービスとして提供していた場合、この「確認日時の自動入力機能」を実際に提供するには、もう一歩踏み込んだ考慮が必要です。
たとえば、入力した判定の値を修正した場合は、確認日時は更新されるべきでしょうか。あるいは、判定の値を削除した場合は、確認日時はどうなるべきでしょうか。これらを検討するためには、「どういうときにそれが必要なのか」というユースケースが必要です。
しかし今回、これも自分自身が体験していることで、容易に説明ができます。変更であれば「OKのつもりでNGを選んでしまったので直したい」「OKとしたけど、やっぱり要確認だと思い直した」という状況がほとんどでした。いずれにせよ、実際に確認を行った時間が変わったわけではありません。このため、時間は更新されるべきではないでしょう。削除は頻度が低く、「テストのスキップが発生して、本来3行下に入れる結果を間違って直下の行に入れてしまった」という場合でした。この場合は、値を削除したら時間も一緒に消えるのが期待される動作といえるでしょう。
実際に体験をすることで、具体的に機能に落とす場合に発生する追加の観点についても、具体的なユースケースにまでスムーズに落とすことができ、要件定義も円滑に行えるようになりました。
本質的に価値ある製品を外から見つけるのは難しい
今年に入って、実際のお客様や全然DeployGateを使ったことのない方まで、さまざまな目的でヒアリングを重ねています。いろんな発見があり、実際に役立っていることも多々ある中で、製品として本当にクリティカルなポイント、そこであるべき姿を見つけていくのは難しいなとも感じてきました。
そもそも人は自分の考えていることを正確に言語化する能力を均等に持っておらず、その結果の質は話す人にも聞く人にも依存します。また言語化した上でも、見えない制約や変数が多数存在しており、ワンショットですべてを洗い出して解決することは到底できません。作って、実際に当てて、改善してというインキュベーションの期間も必要です。
明確に定義できる機能面はもとより、型のない非機能要件を洗い出すのはさらに難しいです。しかし、製品を差別化できる本質的価値はだいたい非機能要件にあります。たとえ機能面で同じことができたとしても、セキュリティや性能はもとより、B2Cであればユーザビリティやデザイン、B2Bであれば信頼性やサポートといった非機能要件に価値を見いだしてお金を払っている例は枚挙にいとまがありません。
「ウェブブラウジング、Eメール、写真、ビデオ、音楽、ゲーム、電子書籍を利用できる端末」という機能要件からはいろんな製品を作ることができますが、結果としてこれだけ世に受け入れられたiPadという製品に辿り着いたのはAppleだけでした。2010年にSteve Jobsが「これらのタスクにおいて、ノートパソコンやスマートフォンよりもはるかに優れていなければならない」と強調した点はいずれも機能ではなく、ユーザビリティや体験、パフォーマンスといった非機能要件でした。(実際、発売当初のiPadの機能はほとんどiPod Touchと変わらなかったと思います。)
今回のようにできるだけユーザーに近い立場、可能であればユーザーと同じ体験をすることは、肌感を持って非機能要件を吸い上げる上でもとても重要だと改めて感じました。プロダクトによっては性質上なかなか難しいケースもありますが、直近で見かけたところだとnewmo社が全員が実際のタクシー会社での運行管理の研修を受けたり業務を体験しているという話があり、一般的に難しいB2Bでの実務体験を実践されているのを見られたのは大変よい刺激となりました。
みなさまのチームの開発現場を見せてください
ということで、今回は自分自身が作っているプロトタイプの対象であるQAテスターとして活動するという体験を経て、言語化しづらい価値を見いだして、解決すべき課題の解像度を上げることがとても重要で価値があると再認識した話でした。
この体験を経て、もっとクリティカルな改善をしていくには、もっとさまざまなアプリ開発の現場の状況を知る必要があると強く感じておりまして、近々「皆様の開発の現場を見せてください」という依頼をしていこうと思っています。もし、うちのチームを見に来てほしいという方がいらっしゃいましたら、ぜひお声がけいただければと思います。私が皆様のチームに伺います。コメント欄でも X でも Facebook でもよいです。具体的なスキームも決まっていませんが、私の方からもこれまでに得てきた何らかの知見を提供できるといいなと思います。
DeployGateとして目指していきたい未来を持ちつつ、現在目の前にある課題も本質的に解決できる手段を提供していきたいな。
今月はそんな感じで。
この記事が気に入ったらサポートをしてみませんか？