IT業界で気づいたことをこっそり書くブログ

くすぶってるアプリエンジニアが、日々気づいたことを適当に綴っていきます(受託→ベンチャー→フリー→大企業→ベンチャー→起業)

なぜなぜ分析はサービス改善に使えなくない?

note.mu

 

前々からこれには違和感がありました。
ブコメにもありますが、全部仮説なんですよね。

 

Wikipediaには

”要因はひとつだけとは限らない。また、事象に対して、論理的なつながりがなければならない。" (なぜなぜ分析 - Wikipedia

とあるので、要因がいっぱい出てきて発散してしまいます。
発散した選択肢の中で「真の要因」を見つけられるメソッドになっているでしょうか?

 

なぜなぜ分析の適切な使いみち

調べた所、こちらのサイトがすごく納得できました。 

図解 なぜなぜ分析:5Whys ~現場の問題解決手法~

 

「悪い事例」が分かりやすいです。
つまり、原因と結果が仮説であってはならないわけです。

 

現場レベルで原因と結果が分かるものに対して使うものみたいです。
プログラミングで行われている普通の行為ですよね。バグから原因を特定して解決する行為こそなぜなぜ分析なのだと思います。

 

サービスに適用する問題

もちろん、顧客開発するときに似たようなフローは行われます。しかし非常に時間がかかります。
1個の原因と結果を調べるのがそもそも大変なんです
下手すると関係者でさえ誰も分かっていないことがあります
みんなして「うーん何となく」っていうんですよ。

 

リーンスタートアップなんかは、その誰も分かっていないポイントを仮説として、検証していく過程の方法論です。そこでは仮説を絞ることが推奨されています。5回なんて無茶です

(ブログにあるような小さい事象ならどうにかなるでしょうけど)

 

解決できていないからこそ真の問題

真の原因を特定して解決したらサービスになる、というのはちょっと烏滸がましいのだと思っています。
関係者は既にやれるだけやっているはずです。簡単に解決できるなら誰かがやってます

  • 解決できない
  • 解決する技術がない
  • 解決して旨味がない
  • 解決すると他が問題になる(トレードオフ
  • 解決してほしくない人が居る
  • 解決するコストが掛かりすぎる

などと言った理由で解決できていないからこそ真の問題なわけです。

 

サービスを考える時の思考法

個人的におすすめなのは論理木を作ることです。

全部仮説や推測で構いません。

 

f:id:otihateten3510:20180210143409p:plain

 

一応、仮説なのか仮説じゃないのかは分かるようにしておいたほうが良いかもしれません。「人によっては違う」みたいなのもあると思います。程度問題になるので完璧なものは作れないはずです。

 

これを1個の事実(不満など)から、要因の方、結果の方、思いつく限り広げていくとします。途中で別の事実も出てくるはずです。
すると、あれ何でこここうなってるの?こうした方がいいんじゃないの?という部分が発見できると思います。

 

そうしたら次に調べることができます。大抵は自分の勘違いですが、勘違いだとわかればまた角度の高い木が書けます。そうやってるうちに、本当に穴が見つかると思います。
しかし、それも大抵は解決方法ができないとかコストに見合わないです。

 

その中からさらに「行けそう」というものが見つかります。
それがようやくアイディアとなります。

 

アイディアまで辿り着けたら、既に論理木が書けているので、利害関係者やモチベーションが表せているはずです。

 

その次に待ち受けているのがアイディアを実現できるかで、その後に流行らせることができるか、が待ち受けています。
ですが、どこまで行っても最初に作り、アップデートしていく論理木があると迷うことが少なくなると思います。

お試しあれ。

 

 

あ、リーン顧客開発良いですよ

www.oreilly.co.jp