まじでこれは良い本だった
自己啓発本ではないし、いい仕事の仕方を説明した本でもない。
純粋に「ジョブ理論」を説くことに専念した本。（ふつうに大学の講義とかでありそうなやつ）
「ジョブ理論」に基づかない平凡な施策が失敗していくさまを結構なページ数さいて書かれている。このあたりが、自身の過去の経験と照らし合わせることがしやすく、納得しつつ読みすすめることができた。
自分の場合は、ただ偶然にエンジニアリング組織論への招待 をKindleで読んだら、ついでにレコメンドされたので読み始めたのがきっかけ（苦笑）なんだけど、普通に本屋にでかでかと並べて欲しいなって思った。
読んでいて、脳裏で想像していたこと
業績とかの数字が上がるのは、「数字を上げる施策をしたから」ではなく「熱心に使う人がいるから」
競合他社がいい感じのUIで機能を作っていて、そこそこいい感じにユーザを獲得できている。
それに対して、多くの場合には、
- 競合他社のUIのどこがいいのかを分析する
- 自社でもやるには何を作ればいいか、最短で実現できる方法を考える
- ペルソナとかカスタマジャーニーマップとか作ってみて、どういう使い勝手が競合他社より理想的かを考えてみる
のような作業が発生する。
それで実装してみると、確かに使い勝手は多少良くなっているので、なんらかの数字は少し上がる。さて、次なにしよう・・・。
これが「ジョブ理論」からすると完全に反面教師的な流れだなと思った。
- 競合他社が使われている理由は本当にUIなの？
- 熱心に使われているのか、仕方なく使われているのか？
- そもそもその提供機能周辺に関しては"競合"なの？
あたりを都度詰めていかないと、（典型的には複雑度が増してメンテしきれなくなって）失敗するパターンだ。
数値的な評価は「仮説がおそらく間違ってはいない」ということだけ実証できる
ちょうど3年くらい前に、今の会社をやめようと思ったくらいイライラしていた時期があるんだけど、そのころのチームリーダー（？）の方針は「まずは測定をしてみてユーザがどこに困っているのかを正確にみてから、次の施策を具体的に考えよう」だった。
自分は、数字にこだわることが嫌いで、"数字を上げに行く"ことはさらに嫌いだったので、これは地獄でしかなかった。当時は「ユーザは数字で動いているわけじゃない」とか「自分らが実際に当事者として使ってみて不便なものが、多様なユーザに提供して便利なはずがない」とか、いろいろ反論はしてたんだけど、まぁ聞く耳もたずの人だったので完全に暖簾に腕押し。
で、「ジョブ理論」読んでちょっと思ったのが、そもそも「見るべき数字」というのは深い洞察にもとづくストーリーや仮説（「ジョブ理論」でいうところの "ジョブ"）があって、初めて測定指標になるんだということ。
"会員登録率" とか "○○画面での離脱率" とかそんな表面的な数値は、よほど洞察深く見える人じゃない限りは、眺めても混乱するか眺めて終わるだけなんだ、と。
幸いにして、直近半年くらいの業務ではこのあたりはかなり満足できる環境にあるので、何か改善をやっていかねばと思うには至らなかったけど、過去のイライラの説明が自分なりについたのは大きな収穫だった。
まとめ
みんな読もう。
次はAmazonのレコメンドにしたがいイノベーションのジレンマ読む。
