ユーザビリティとリソースのトレードオフは見誤るとまずい 【ぐんじの これはマジ。 #1】

新卒でキュレーションズ株式会社にて働いている軍司（グンジ）です。
仕事で「これはマジで覚えておこう」ってことをまとめておく僕なりの備忘録『ぐんじの これはマジ。』です。サムネイルは適当に画像生成したものなので特に意味はありません。

この記事では、サービス開発の初期段階のPoCにおいてユーザビリティは上げたいけど、こんなに色々詰め込んだらお金もかかるし、時間もかかるからどうしようってなった時の考え方について書いていきます。

ユーザビリティってなに？

まずは、ユーザビリティってなに？という話でして、Wikipediaにいい感じにまとめてあったので引用しますとこんな感じ。

ユーザビリティ（英語: usability）は、「使いやすさ」を示す言葉。
「ある製品を、特定の利用者が、特定の目的を達成しようとするにあたって、特定の状況で、いかに効果的に、効率的に、満足できるように使えるかの度合い」

wikipedia

つまり、あるモノがどれだけ使いやすいか、どれだけストレスなくそのサービスで目的を達成できるかってことですね。例えば郵便番号入れたのに市区町村を自動で入力してくれないECサイトとかイライラしますよね。あれは「ユーザビリティが悪い」と言えます。

ユーザビリティとリソースの関係はトレードオフ

僕が所属する会社では、新規事業創出のコンサルティング＆事業化伴走をしています。簡単にいうと、新規事業となりうるアイデア出しましょう→いいのがあったら事業化検討しましょう→事業化する・した初めのフェイズはモノを作ったりビジネスモデルを検討したり、とお手伝いしますよ。という感じです。
その中で、僕は事業化の初めのフェイズでのモノ（アプリ、ウェブ、ロゴなどなど）を作るところのディレクションをしています。どんなものを作るのか？どんな機能を持たせるのか？みたいな所を決めて、デザイナーさんやエンジニアさんと一緒にモノを作っていきます。

そこで最近意識してるのは、「ユーザビリティとリソースの関係はトレードオフ」であるということ。

どういうことかというと、リッチで便利な機能をたくさん入れたら使いやすいだろうな〜、でもそのぶん仕様の検討コストとか、デザインコストとか、開発コストかかってリリースが遅れちゃうしお金かかるな〜というジレンマがあるよねってことです。

「何がしたいのか」を意識していろいろ捨てよう。

そんな状態に陥った時にまず考えるべきことは「何をしたいのか」という認識をみんなで合わせて、必要な機能を絞ることです。

CookPadというサービスを例に考えてみましょう。
CookPadのサービス初期のPoCで確認したいことは「誰かが投稿したレシピを見たい人ってホントにいるのかな？」ってところだと思います。ここを検証の焦点に据えると、例えば「あなたはこの料理が好きかも」のようなレコメンド機能だったり、「人気急上昇中のレシピはこちら」などの機能は必ずしも必要ではありません。
ここで改めて必要となるのは、このあたりじゃないかなと決まるわけですね。

・プロフィールを作る
・レシピを投稿できる
・他人のレシピを閲覧できる
・簡単な検索ができる
・簡単なランキングが見れる（←ここすらいらないかも）
などなど

他の機能は上記の機能を最低限支える機能であればいいんだな〜となるわけです。これをデザインや開発、バックオフィスなどのコストと見合わせて切って切って切りまくっていくというわけですね。

それと、「みんなで認識を合わせる」というところも意外と大事でして、これをしないとデザイナーさんやエンジニアさんは「こんなこともできますよ！」「これ必要ないんですか？」など、ありがたいことなのですが、提案の嵐でまた判断する機会が増えて大変ですし、他の余計な仕事をやったり、やらせたりしてしまいます。

「この段階では…」という言葉を聞き流さない

いつもこの意識を持っていられるのが理想なのですが、そこまで僕は頭が回らないのでこの意識を呼び起こすトリガーを用意しています。
それが「この段階では…」「とりあえず今回は…」「ここで大事なのは…」という類の言葉です。
というのも「この段階では…」という言葉を誰かが発した瞬間に全員の中にそれぞれ <この段階> の定義が作られて、どうもみんな違うこと考えてるっぽいんですよね。

この類の言葉が出てきたら <この段階> の解像度を上げて、制約、目的、今のゴール、リソース、スケジュールなど色々認識を合わせよう。って思ってます。

以上。