「わたし、この店キライ」
という彼女の何気ない一言から始まった。
ちなみに、僕が頼んだのは「ホタルイカの沖漬け」だ。
目次
- 「サービスを改善」とか聞きたくないでござる
- 「問題」に飛びつかず「課題」を見よ
- 思考を「階層化」しとく
- 企画とブレストと雪崩とわたし
- まとめ
- 雑感: ドッグフードを食べる幸せ
WETな備忘録として。
「サービスを改善」とか聞きたくないでござる
なんとなく「サービスを改善したい」とかいう気持ちがあるのは分かるんだけれど、それって誰にでも言える言葉で、何も言ってないに等しい。
まずは「問題」を定義したほうがいい。しかもそれは「この辺をカッチョ良くしたい」とかの「改善」ではなく、「この辺がイケてない」「ここが不満だ」という「問題」であるほうが好都合だ。なぜなら「改善」だと、目指すべき理想状態の定義から入らないといけないので、企画出しのコストパフォーマンスがよくない。
お願いだから「サービス改善会議」とかセッティングしないで欲しいでござる。それをやるくらいなら「自サービスをdisる会」のほうがよっぽど生産的だ。
「なんでキライなのさ？」
「さっき注文した料理がぜんぜん来ない！」
「問題」に飛びつかず「課題」を発見する
「なんでこんなに時間かかるわけ？もうビール2杯目だよ？もっと早くできないわけ？」
「問題」には解決が必要なのだけれど、ここで注意しなければならないのが、「問題の原因を探してはいけない」ということだ。一見してイミフだけれど、ここに「アイデアが出ない理由」がある。
「なぜ時間がかかるか考えても面白いけど、もしかしたらもっと面白い解決があるかもしれない」
「早く料理を出す以外に？」
「そう」
多くの、そして質の良いソリューションを提案したかったら、問題の原因を深く掘り下げるのではなく、問題そのものをよく見直して「課題」を発見した方がよい。
ここでいう「課題」とは、「その問題（現象）が問題（不都合）である理由」「本来どうあって欲しいか」ということだ。
「たとえば、料理が早く来ないと、何が起きるの？」
「腹が減る」
「まあそうだよね」
「口寂しい」
「なるほど」
「暇」
「お...おう...」
「料理が来るまでの時間があるのが嫌？」
「問題」と「課題」は似ているようでちょっと違う。「問題（現象）」はそれが「問題（不都合なこと）」である文脈が無いと「問題（不都合なこと）」にはなり得ないが、「課題」は「欲求」や「不満」といった「ユーザの好みや感情」によって定義されるものであるべきだ。
たとえば「入力フォームの項目が押しづらい」というのは「問題（現象）」ではあるが、必ずしも「問題（不都合なこと）」であるとは限らない。むしろ別の文脈においては「入力フォームの項目が押しづらい」という現象は都合が良い場合さえある。したがって、おそらくこの「問題（現象）」の向こうにある「課題」は「フォームの入力が苦痛である」ということかもしれない。
思考を「階層化」しとく
問題の解決に飛びつく前に、課題を抽出しておくと、提案できる解決策にバリエーションが生まれるのではないだろうか。
「たしかに料理が遅いのは問題だけれど」
「料理を早くする以外にもいろいろ出来そう」
「口寂しいならキス割りみたいなの導入したらどうか」
「キモい」
適当にそれっぽくつくった
企画とブレストと雪崩とわたし
もちろん、発見した「課題」が間違っている場合もあるし、ある「問題」に対して発見される「課題」がひとつであるとも限らない。なので、適切なタイミングで方向転換や課題の見直しが必要な場合もある。
そういう場合は、必ずその場にいるひとで「今はどの階層の話をしているか」を確認すべきだと思う。「問題定義の提案」なのか「課題の抽出」なのか「解決の模索」なのか「実行可能性の検討」なのか。
「今、我々は何の話をしているのか」「どこまでコンセンサスを形成したか」を見失うと、アイデアが出ないばかりか、今後のチームの生産性やメンバーの自発性を損ねる可能性すらあると思う。
たとえばこういうのつらい↓
- 問題の定義をしていると怒りだす
- 課題の抽出をしているのにビジネス要件を持ち出す
- 実行可能性の検討中に不可能と判明したら問題の定義までさかのぼって否定する
「いるわ、そういうの」
「こういう前提で今話してますよね？っていうの一足飛びしちゃうとつらいとか」
「もう部長に任せておいた方がいいんじゃないの感あるわー」
これを防ぐ方法のひとつに、会議態や会議フェーズに名前をつけるというのがある。
- 問題から課題を抽出するフェーズを「インタビュー」と呼ぶ
- 前提となる課題を元に多くの解決を提案するフェーズを「ブレスト」と呼ぶ
- 解決の実行可能性を検討するフェーズを「リサーチ」と呼ぶ
などなど。まあ正解はない。いずれにしても、上下左右を見失ってはいけない。だから会議にはホワイトボードが必要なのだ！と思う。
まとめ
- 「改善」を目指すのではなく「問題」を定義する
- 「問題」を解決するのではなく「課題」を抽出する
- 「課題」に対して解決を提案してみるとよい
- 「上下」に掘っているのか「左右」に広げているのか明示する
「大変お待たせしました！ホタルイカの沖漬けです！」
「待ったよ〜」
「あとビール1つと日本酒ください」
という妄想をした。 #彼女いません
「アイデア出しは直感や才能ではなく、技術と論理である」みたいなのはこういうの読んで面白かったです。
雑感: ドッグフードを食べる幸せ
ドッグフーディングとは、自分たちの製品を使用することをまさに意味しています。これは、素晴らしい原則です。なぜなら、自分たちのソフトウェアを使用することにより、顧客と同じような痛みを共有することが出来るからです。もしあなたの製品がクズであれば、それをより良いものにする強い動機となるでしょう。もしあなたがそれを毎日使用していれば。ただ見栄えを良くするだけではなく、フィーチャーを良く動作するようにするかもしれません。
ドッグフーディングと頻繁な内部リリース | Atlassian Japan より
問題というか現象から、ユーザが本来感じている課題を抽出するには、自分がユーザになってその欲求とか不満とかを共有する、まさに「痛みを共有する」のが絶対に必要で。
逆に「全く自分が使ってないサービスや製品」をどんなに改善しようと思ったって、せいぜい（実際の）ユーザから来るクレームを黙らせるための「解決（？）」くらいしかできない。
そんなことを思うとやっぱり「仕事でも自分が使うサービスを作りたいなぁ」と思うわけだけど。
でも冷静になって考えてみれば、世の中の大半の人は直接自分の生活に関係のある仕事をしているのではなくて、生活の糧を得るために仕事をしているのであって、生きがいとかやりがいとか関係なく仕事するのもやっぱり間違ってなくて。
最近わりとよく考えるのが
これです
WETな備忘録として
