検収テストでは、見積書発行から在庫連動、承認フローまで、仕様書に書かれた機能をひとつずつ丁寧に確認した。動作は問題なし。押したボタンは期待通りに反応し、数字は正しく計算され、承認のメールもきちんと届いた。だからシステム担当者は胸を張ってハンコを押し、開発会社に検収完了の連絡を送った。ここまでは、誰の目にも「成功」に見えるプロジェクトだった。
ところがリリース初日の午前中から、内線電話が鳴り止まなくなった。「どこを押せば注文が確定するんですか」「この画面から前の画面に戻れないんですけど」「入力したはずのデータが消えています」。電話をかけてきたのは、10年以上パートとして受発注業務を回してきたベテラン社員だった。仕様通りに動くことは開発会社もシステム担当者も確認済みだ。しかし、実際に手を動かす現場の人がどこで迷うかは、誰も見ていなかった。
結局その担当者は、リリース後の1ヶ月間、日中の大半を問い合わせ対応に費やすことになった。マニュアルを急ぎ足で作り直し、操作手順を紙に印刷して各デスクに貼り、それでも減らない質問に一つひとつ答え続けた。検収テストは通ったのに、なぜこんなことになったのか。この問いに正面から向き合わないまま次のシステム更改を迎える会社は、驚くほど多い。
なぜ検収テストと現場の使いやすさは別問題なのか
検収テストとユーザビリティテストは、似ているようでまったく別の問いに答えるものだ。検収テストが確認するのは「仕様書通りに動くか」であり、いわば契約の履行確認である。見積機能に消費税率を反映する仕様なら、その通りに計算されるかを確認する。承認フローが三段階と決まっていれば、その通りに回るかを確認する。ここで見ているのは、あくまでシステムと仕様書の一致度だ。
一方でユーザビリティテストが確認するのは「現場の人が迷わずに使えるか」という、まったく違う軸である。仕様書には「消費税率を正しく計算すること」としか書かれていないが、その計算結果をどこに、どの大きさの文字で、どんな順番で表示するかは仕様書の外にある。開発会社のエンジニアにとって自明な操作導線が、日々の業務に追われる現場のパート社員にとっては全く自明ではないということが、日常的に起きている。
この二つを混同してしまうと、検収さえ通れば安心という誤った安心感が生まれる。実際には、仕様通りに動くことと、現場の人間が迷わず使えることの間には、決して自動的には埋まらない溝がある。その溝を埋める責任を、開発会社任せにしてしまっていいのか。これが本記事で考えたい核心の問いだ。
ユーザビリティテストとは何か、身構えずに理解する
ユーザビリティテストと聞くと、専門のラボで被験者にアイトラッキング装置をつけて、というような大掛かりなイメージを持つ人も多いかもしれない。しかし本質はもっとシンプルだ。実際にそのシステムを使う予定の現場社員に、実際の業務で起こりうるシナリオに沿って操作してもらい、どこで手が止まるか、どこで首をかしげるか、どこで別の画面を探してしまうかを、そばで観察するだけでいい。
例えば受発注システムであれば、「取引先Aから電話で注文が入った想定で、商品を3点登録し、納期を来週の水曜日に設定し、確定処理まで行ってください」といった具体的なシナリオを渡す。開発会社のデモ画面を見せられるのではなく、現場の人自身がマウスとキーボードを握って操作する。ここで大切なのは、操作している人に「ここはこう押すんですよ」と横から教えないことだ。教えてしまった瞬間、そのテストは何も観察できなくなる。
観察者がすべきことは、ただ黙って見ること、そして手が止まった瞬間や、画面を行ったり来たりした瞬間、ため息をついた瞬間をメモすることだけだ。この地味な作業の積み重ねが、開発会社の誰も気づかなかった落とし穴を浮かび上がらせる。専門用語も特別な機材も要らない。必要なのは、現場の人に実際に触ってもらう時間を、リリース前にきちんと確保するという意思だけだ。
実施しないことで起きる実害
ユーザビリティテストを省略した代償は、想像以上に長く尾を引く。まず目に見える形で表れるのが、問い合わせ対応工数の急増だ。冒頭の例のように、システム担当者やマネージャーが1ヶ月にわたって本来の業務時間を削られるケースは珍しくない。1件5分の質問でも、1日20件来れば1時間半が消える。それが週5日続けば、月20時間以上がサポート対応だけで溶けていく計算になる。
次に起きるのが、現場の定着の遅れだ。使いにくいシステムに対して人は本能的に距離を置こうとする。最初のつまずきで「難しい」という印象がついてしまうと、その後どれだけ機能が改善されても、心理的な抵抗感はなかなか消えない。結果として、一部の得意な社員だけがシステムを使いこなし、他の社員は最低限しか触らないという偏りが生まれる。これでは全社的な業務効率化という本来の投資目的が半分も果たされない。
そして最も避けたい実害が、シャドーITやExcel併用への逆戻りだ。新システムの入力画面が分かりにくいと感じた現場社員が、こっそり自分用のExcelシートを作って先にそちらへ記録し、後でまとめてシステムに転記するようになる。二重入力は転記ミスを生み、データの正確性を損ない、何より「なぜ新システムを入れたのか」という経営判断そのものの意味を薄れさせてしまう。せっかく投資した新システムの隣に、非公式の裏帳簿が並走している状態は、決して珍しい光景ではない。
中小企業でも無理なくできる簡易的な実施方法
ユーザビリティテストは、大企業だけの贅沢な工程ではない。専門のラボも、外部の調査会社も必要ない。現場社員2〜3名に、実際の業務シナリオに沿って30分ほど触ってもらうだけでも、驚くほど多くの気づきが得られる。
- 実際にシステムを日常的に使う予定の社員を、部署や年齢層が偏らないように2〜3名選ぶ。ベテランと若手、パートと正社員など、視点の違う人を組み合わせるとより多くの発見がある
- 本番に近い業務シナリオを3つ程度用意する。日常的な処理、月末月初など頻度は低いが重要な処理、イレギュラーな入力ミスの修正といった具合に、想定される場面をカバーする
- 操作は本人に任せ、観察者は口を出さず、つまずいた箇所と所要時間だけを記録する
- テスト後に「今どこで迷いましたか」と本人に振り返ってもらう。操作中は言葉にならなかった違和感が、後から言語化されることが多い
- 見つかった問題点を、致命的なもの、業務に支障が出るもの、軽微な改善希望に分類し、リリースまでに直すべきものと運用でカバーするものを仕分ける
この程度の規模であれば、システム担当者一人でも1〜2日あれば実施できる。開発会社に追加費用を払って大掛かりな調査を依頼する必要はない。大切なのは規模ではなく、リリース前に一度でも現場の生の反応を見る機会を作ることそのものだ。
発注時にどう組み込めばいいか
ユーザビリティテストを機能させるためには、リリース直前に思いついたように実施するのではなく、発注段階から工程として組み込んでおく必要がある。要件定義書や検収スケジュールの中に「検収テスト完了後、リリース判定までの間にユーザビリティテスト期間を設ける」と明記しておくことで、開発会社側も検収完了イコール即リリースという前提を持たなくなる。
具体的には、検収テストとリリースの間に1〜2週間の猶予を設け、その期間内に現場社員によるユーザビリティテストと、そこで見つかった修正点への対応を行うスケジュールを組む。この工程をあらかじめ契約や見積もりの段階で合意しておけば、後から「追加の修正費用がかかります」という揉め事にもなりにくい。ユーザビリティテストで見つかる問題の多くは、大規模な仕様変更ではなく、ボタンの位置や文言、画面遷移の順番といった軽微な調整であることが多く、開発会社にとっても対応コストは限定的なはずだ。
また、発注時点で「現場社員によるユーザビリティテストを実施し、その結果をリリース判定の材料とする」という一文を仕様書や契約書に盛り込んでおくと、開発会社側の設計意識そのものが変わることもある。最初から「使う人に見られる」という前提でUIを設計するのと、検収さえ通ればいいという前提で設計するのとでは、出来上がるものの質が変わってくる。
よくある失敗パターン
ユーザビリティテストを取り入れようとしても、いくつかの落とし穴にはまって効果が薄れてしまうケースがある。代表的な失敗パターンを挙げておきたい。
- テストの対象者をシステムに詳しい社員やIT担当者だけで固めてしまう。普段からITツールに慣れている人は、多少分かりにくい画面でも自力で突破してしまうため、本当に困る現場の声が拾えない
- 観察者が操作中に助け舟を出してしまう。「あ、それはここを押すんですよ」と教えた瞬間、その場面での気づきは永遠に失われる
- 見つかった問題点を記録するだけで、優先順位をつけずに開発会社に丸投げしてしまう。致命的な問題と些細な好みの問題が同列に扱われ、対応が遅れたり、逆に些末な修正に時間を取られたりする
- テストの実施タイミングが遅すぎる。リリース前日にテストを行っても、修正する時間的余裕がなく、結局「気づいたけれど直せなかった」という結果に終わる
- 一度実施して満足してしまう。実際には、修正後にもう一度同じシナリオで確認する再テストまで行って初めて、改善が機能したかどうかが分かる
これらの失敗の多くは、テストという行為そのものの問題ではなく、テストを「やった」という事実で満足してしまうことに起因する。目的はテストを実施することではなく、現場の人が迷わずシステムを使いこなし、日々の仕事に集中できる状態を作ることにある。
まとめ
検収テストに合格したシステムが、リリース初日から現場を混乱させる。この矛盾に見える現象は、実は当然の帰結だ。仕様通りに動くことと、現場の人が迷わず使えることは、そもそも別の問いだからだ。開発会社は仕様書との一致を保証してくれるが、現場の使い勝手までは、実際にその現場で働く人たちの目でしか確認できない。
ユーザビリティテストは、大掛かりな専門機材も莫大な予算も必要としない。現場社員2〜3名に、実際の業務シナリオで30分触ってもらうだけでいい。その小さな一歩が、リリース後の1ヶ月間を問い合わせ対応に追われる日々にするか、現場がスムーズに新システムを使いこなし本来の業務に集中できる日々にするかを分ける。
日々の業務を回している現場の人たちは、システムの向こう側で、確かに壁を越えようとしている。その人たちが迷わず前に進めるかどうかを、開発会社任せにせず、自分たちの目で確かめる。それこそが、システム投資を本当の意味で現場の力に変える、最後にして最も大切な一手だ。