多機能は誰のため？

「誰がどんな使い方をしても文句がでない完璧なシステム」を作った。リリース後に待っていたのは、その言葉とは正反対の反応だった。

完璧を目指した要件定義

あるプロジェクトで、開発担当者はとにかく丁寧でした。すべてのユーザーの要望を一つひとつ拾い上げ、機能要件と仕様の詳細を徹底的に洗い出しました。

「より多くの項目が登録できるように」「より複雑な条件で検索できるように」「より多彩な表示ができるように」

どんな使い方にも対応できるよう、機能は増え、設定項目は増え、画面の情報量も増えていきました。

「これで、誰がどんな使い方をしても文句がでない完璧なシステムが出来上がったぞ！」

担当者は満足そうでした。そして、その場にいる全員が「これはいいものができた」と信じていました。

リリース後、フィードバックが届き始めました。

「画面がごちゃごちゃしていて見づらい」「どうやって使うかわからない」「やりたいことをするまでが長い」

利用率もなかなか上がりませんでした。導入説明会を開いても「難しい」という声が続きました。

担当者は困惑しました。すべての要望を取り入れ、機能はすべて揃っています。なぜ使われないのでしょうか。

ここで起きていたのは、「機能がある」と「使える」の混同です。

多くのユーザーは、全機能を使いこなしたいわけではありません。日々の業務でよく使う操作を、素早く、迷わず終えたいだけです。画面に100個のボタンがあっても、実際に使うのはそのうち5個かもしれません。

ユーザーが本当に求めていたのは「全部できる」ではなく、「すぐできる」でした。

機能を増やすほど画面は複雑になり、使い方の学習コストが上がり、迷いが生まれます。「使わない機能が多いシステム」は、使いやすいシステムにはなりにくいものです。

誰かの要望を叶えることと、使いやすいシステムを作ることは、必ずしも同じではありません。