“誰かが決めた仕様の資料化”から脱するための要件定義
2019.04.08
「あれ…?これ誰が欲しくて入ってる機能なんだっけ?」みたいなことを、どうしたら避けられるかな、というメモ。
案件をやる中で感じる「あれ…?これ誰が欲しくて入ってる仕様なんだっけ?」みたいなことを、どうしたら避けられるかな、というメモ。(ウェブサービスとかつくる前提で勝手に話します。)
埋まらないリーンキャンバスが意味すること
サービスを簡単にすばやく形にするため、リーンキャンバスを利用することがあります。
サービスを俯瞰するときに便利なこれは、ターゲットやニーズ、市場調査などができていなければ、埋めることはなかなか難しい代物です。
受注してつくるサービスなんかだと、クライアントに問いかけてはみるのですが得てして「これ!」という答えは返ってきにくい印象です。もはやこれは 埋められない ということを知ってもらうためのツールなのかもしれない、と最近感じます。
知らない、考えていないということを可視化するためのツール。
基本中の基本だけど、サービスを設計する上で大事なのは2つだと考えています。
- ターゲットは誰なのか
- 提供する価値は何なのか
ターゲットは誰なのか
まずターゲットを定めることです。当たり前のことではありますが、ユーザ理解のない機能は案外簡単に生まれてしまいます。
ユーザは使う側であってつくる側ではない、という意識は、言われれば思い出せますが、根気強く考え続けることができなければ実現しません。
それにはやはりターゲットを知るところから。
ニーズを叶えるサービスを作りたい
→ ターゲットを定めなければニーズが本当にあるのか分からない
→ ニーズがあるのかわからないと価値が定められない
→ 進まない……というループ
こういった負のループから抜け出すには、 「ユーザのことを知らない、知らなければ」という共通認識 が必要です。
ターゲットの定義は難しい課題ですが、結局のところ、解決したいこというのは生活の中に転がっているのかなとも思います。
面倒なことをやってくれる、めっちゃ早くやってくれる、言われる前にやってくれる、ずっと覚えてくれている……など。
こういった当たり前のことに困っている人、と考えると、身近にいそうな気がして考えられるかもしれません。
提供する価値は何なのか
ニーズを明らかにするためにユーザを具体化させるべし、というのが↑での主張ですが、機能開発をニーズから出発させると、 よくわからないモノが生まれがちです。これ何に使うの?みたいな。
は?言ってること違うじゃん。って感じですが、大事なのはターゲット像を明らかにし、一番大事な価値や体験を浮かび上がらせることです。ご意見番を作り上げることではありません。
なぜニーズから機能開発するとよくわからんのかというと、
コアとなるコンセプト、価値の欠如が起こりがち
→ 競合がある中で「少なくともこのニーズの人はこのサービスを使う」みたいな優れている点がない
→ どのようにその価値を知ってもらうか(シンプルな価値になっているか)という視点がない
「伝わる価値」になっているか、という視点が抜けると、上記のようなよく分からないけど客の要望は叶える 百徳ナイフ的サービス になりがちです。
百徳ナイフってなんやねん、って方は↓を。(なんか普通に話題にしたけどUIデザインしてる人しか百徳ナイフなんてもの見ないのでは、と思ってリンク探した。)
スマホUI考(番々外編) 誰得の100徳ナイフを買ったというお話 | fladdict
これら2つ(ターゲットは誰なのか、提供する価値は何なのか)を大事にしながら、以下のようにサービス設計を進めることにしています。
伝わる価値をつくる
使えるではなく、伝わる価値をつくる
サービスでは機能的な価値単体ではなく、 ユーザが理解・共感できるストーリーの中に 効果的な機能を置いていくのが大事だと考えています。
使い方が分かりつつ、価値がひと目・ひと言で分かる状態が良いのだ、と言うのが持論です。
これはリーンキャンバスで言う「 競合に勝てるポイント(独自の価値)」や「顧客が何に共感するか(サービスコンセプト)」に該当する部分でしょうか。チームで共通認識をつくることが大事だと感じています。
「簡単な」シナリオをつくる
共通認識をつくるためには、周辺情報が多い方がうまくいく気がします。
共感するシナリオを簡単に設定します。 簡単に行うこと が大事です。作り直しても良いくらいの手の入れ方が大事。
簡単なシナリオを具体化していくとカスタマージャーニーマップへを進化していきます。(多分)
↓のようなやり方だとイメージしやすいしみんなで進めやすそうです。
UXデザイン入門におすすめ!ユーザー体験を簡単に可視化・共有できる「いらすとやシナリオ法」|ばっこ|note
「簡単な」リーンキャンバスをつくる
いきなり全体ではなく、 基準点となるポイント を押さえることが大事だと思います。いろんな要素がサービス設計には入ってくるので、だいたいどこかには自信や根拠があって、どこかはそれが薄い、みたいなことが多いと思います。
- ターゲット
- 困っていること
- 解決策
- どうなるのか
- +α
上記のようなふわっとした情報を、具体化、詳細化するとリーンキャンバスへ進化します。(するのか?)
- ターゲット
- 顧客とは誰か(顧客セグメント)
- 初期の顧客は誰か(アーリーアダプタ)
- 困っていること
- なぜ顧客は喜ぶのか(解決する課題)
- 今、顧客はどうしているのか(既存の代替品)
- 解決策
- 顧客に何を提供するのか(機能、ストーリー)
- どうなるのか
- 顧客の反応をどうやって知るか(主要指数)
- 顧客が何に共感するか(サービスコンセプト)
- +α
- 競合に勝てるポイント(独自の価値)
- なぜ顧客はこのサービスを選ぶのか(圧倒的な優位性)
コストや収益についてはここに含められてません。
持続してサービスを良くしていくためにも、そこらへんは今後の課題ですね。
途中ですがここまで。
こういった、「どう案件をまとめあげるか」という視点はどんどん社内で共有していきたい所存です。