私がユーザー体験の仮説をたて施策をうつときにすること

前提条件として

• ターゲットとなるユーザー層に知り合いがいることが前提です。
• え、いない？　作りましょう。いないと話になりません。
• え、つくりたくない？　興味を持つつもりもないユーザー相手に商売してもうまくいきませんよ。

システムしているの？

• 検証でやることはほぼ地道なアナログ作業です。
• このあたりの作業を最後までやりきってルーチン化できれば自動化できます。
• ようするに最初はほぼアナログです。この作業に限って言えば、ディープラーニングや機械学習は「機械に任せられるフェーズが早められる」「分析する変数が増やせる」くらいの効能しかありません。

これを１サイクル回すのにどれくらいかかる？

• 約２週間〜４週間
• 1~2イテレーションくらいです。
• 施策を検証せずに打つより時間はかかります。しかし有効度が高いためこの方法を採用しました。
• 「連射性」より「命中性」を重視した施策の打ち方です。
• 大事なのは「有効弾」や「有効ダメージ」をどれだけ出したかなので、連射性を下げてでも命中率の向上にこだわりました。

やること

1.オフラインインタビュー

最初にユーザーになりえそうな知り合いに直接サービスを見せて、どう思うか？を聞いてみましょう。

• ズケズケものを言うタイプの人がイイです。
• ものを知っている「素人じゃない」人でもいいです。
• ある程度仲が良いなら、競合であってもかまいません。というか競合同士ならお互いにインタビューができます。
• 逆に、取引先とかインターン生とか、そういう利害関係にある人は向きません。こちらに気に入られようと頑張りすぎます。

言われた内容をまとめます。主に、問題点として感じている部分が中心です。

• 逆に解決策として提案されたことは直接は役に立ちません。解決策として提示された内容があれば、実際には何を解決したかったかに注目します。
• 一般ユーザーは問題に対する適切な解決策を知りません。
• 片言隻句に注目するのではなく、発言内容の傾向に着目します。注目すべき点は１０種類以下になるくらいに絞りましょう。５種類以下でもいいと思います。
• 一度に多くは追えません。コストパフォーマンスを考えて重要な奴から叩きましょう。

2.選抜インタビュー

上の内容でまとめた内容をもとに「質問」としてまとめます。質問は複数作ります。

• 「このサービスはどんなサービスだと思いましたか？」
• 「〜〜するときに探しづらいとか思いましたか？」
• 「〜〜しようとしたときに、ちゃんと予約するところまでたどり着けましたか？つけなかったとしたら何が問題ですか？」
• 質問の回答を通じて「ユーザー体験の課題」を検索することが目的です。

質問は選択形式が２、３個、あとは自由記述式がよいです。回答はGoogleフォームでいいと思います。メールベースでも長々書いてくれる人はいます。

• このサービスの第一印象として、どんなサービスだと思った？は私なら絶対入れます。
• たとえば「このサービスを一言で言うと」の部分は運営側とユーザー側で印象は一致しているか？
• 「旅行を比較しながら旅行の予約できる」サービスだとして、「旅行を予約するサービス」だと直感できた？「選ぶ楽しさ」は感じられた？という質問は入れます。
• 作っている側が感じて欲しい部分は「本当に伝わっているか？」はシード段階で検証すべきです。そうでないと伸びません。伸びが止まります。

回答者の選び方

• 「お気に入りリストに大量に登録している」「アクティブに使っている」「滞在時間が長い」というようなヘビーなユーザーを選びます。
• 比較的リテラシーが高く、回答するモチベーションも高いからです。回答する可能性と有意な回答を返す可能性が高いです。

3.少量データチェック

• 選抜インタビューで得られた「ユーザー体験の課題」が本当に正しいか？という点を調べます。検証方法はDBに直接SQLを投げたりスクリプトを走らせたりして収集します。
• いきなりビッグデータ検証はしません。
• 地道かつ不定形な作業になります。
• コスト的に総当たりで調べられないので、調べるには絞りこむためのドメイン知識が必要になります。

目的は２つ。

• 一つは検証方法を確立すること。何を見たら課題の検証ができるか？がわからないと検証の意味がありません。
• もう一つは「回答者が主観的に感じた課題は実在するか？」の検証です。ユーザーが主観的に感じているストレスの原因はユーザーが主張している内容とは異なっている可能性があります。間違った原因を調べても無意味です。

ユーザーの主張する原因に一致する結果が得られない場合

• ストレスを感じている原因は別にある可能性があります。
• アンケートの質問が悪かったのか、ユーザーの認知がゆがんでいるのか、実際には背後に別の問題が隠れているのかを調べる必要があります。

4.大量データチェック

• 上の少量データチェックで有意な仮説検証方法を見つけられた場合に遷移します。
• 「時間をたっぷりかけて調べてみました、よくわかりませんでした。」にならないように基本的にこのフェーズは有意と思われる仮説検証方法を見つけてから移ります。
• 「なんかの参考になりそうな数字」にならないようにしています。
• Google Big Queryでも Hadoopでも Treasure Dataでもお好きなものをどうぞ。

5.自動データ取得

• 大量データチェックでユーザーの挙動を象徴する指標をとります。
• 「施策の効果を測定するための、短期的に監視する数値」は特に監視対象です。

施策実施

• インタビューから時間をかけて検証した仮説をもとに、施策を打ちます。

1.施策の策定と実装方法の立案

• ProttやSketchにおこすまえにペーパープロトタイピングで設計します。
• これは意図やプランをメンバーにも考えさせることで、あとあとのマネージメントコストの低下を狙います。
• 実装者の深い理解は必須です。作っている人間が理解していない意図が、ユーザーに伝わるわけがないからです。
• しかし「理解しろ」の掛け声だけでは解決しないため、実装者にもこのフェーズに参画させることで理解と動機を植え付けます。

2.プロトタイプの検証

• 上で作ったプロトタイプを使って検証します。
• 検証は複数タイプでやります。本命は事前に決まっていても、対抗馬から思わぬユーザーの理解が引き出せる可能性もあります。
• また「対抗馬はなぜ敗れたか？」を理解させることは次回以降の時間の節約になります

実際の検証方法

• ユーザー体験は本当に解消するか？という点はUXデザイナーとそれ以外の素人(チーム外の同僚がいい)を使って検証します。
• チーム内の人間はほぼ隅から隅まで知り尽くしているため、施策を打てば敏感に反応しますが、素人の場合情報の洪水に流されて期待と異なる行動をとったり、挫折したりします。
• 重要なのはユーザーの大半は「怠惰で士気が低く観察力が低い」という点です。偏差値５０以下のユーザーが使えることがヒットサービスの条件です。
• なのでちょっとぼやっとした感じの人の方がテストには向いています。
• 集中力が低下する朝イチか、昼食直後がオススメです。

3.デザイナーによるデザイン

• この段階でようやくデザイナーがデザインします
• 一番最初にこのフェーズを経ないのは、「目に見えるものがないと人間は考えづらい」ので事前に検証をしたいからです。
• デザインの後に最初の検証をかけないのは、仮に「これってよくないのでは？」という疑問が出たときに「必死に考えたデザインを否定された」デザイナーは抵抗を感じますし、実装者は「なぜこれがよいのか」という説明をされていないため「上からふってきた」ものとして感じるからです。
• この２つの感情は「チーム内の軋轢」と「他人事感」を生み出していまう原因になります。

4. 実装

• 上で実装者を施策の実施意図まで含めて 説明しているためこのフェーズはスムーズに進みます。

5. リリース

• 触ってみて、これで大丈夫か？という確認をします。
• 直前まで触っていた人間は親のひいき目がでるので、この段階でも「チーム外の同僚による検証」を入れるのが望ましいです。

6. 検証

• ちゃんと効果は出たか？
• 副作用はなにが出ているか？
• この２つは検証します。問題なければこのまま続行します。
• もしまずかったときにすぐに引っ込められるようにリリースサイズは小さくするのが望ましいです。

事業に勝つこと、勝ち続けること、負けること。

勝つこと

１つの事業で成功することはとても難しいと思います。
いわゆる「一発屋」で終わったとしても、その一発すら出せないまま死んでしまうベンチャー企業なんて山ほどあるわけです。私はその一発を出せる企業の創業者を尊敬します。

昔好きだった会社でVRの先駆けとなったARの先駆者セカイカメラを運営する「頓智ドット株式会社」というのがあったんですがいまはセカイカメラをcloseしてtabという後継サービスをリリースし、今は「株式会社オープン・ランウェイズ」に吸収されていました。

ソフトバンクの孫さんや楽天の三木谷さんなどはいろいろ思うところはありますが成功事業をあれだけ複数出している時点で凡百の経営者など及びもつかないところにいると思っています。仮に当人の実力でなかったとしてもそれは番頭さんを御しているということですし、当人の実力であるならば言葉に尽くすことはできません。
成功事業を「１つ」出せる経営者と、「２つ」出せる経営者、「複数」出せる経営者の間にはそれぞれ大きな壁があると思っています。
ミクシィもmixiで貯めたキャッシュを使い切る前にソーシャルゲームで一発当てたわけですし、これはこれですごいことだと思います。

ほかにもメルカリはアッテで１発当てれば「２つの事業を当てた会社」の殿堂に乗りますし、当てられなくてもメルカリの事業成功は桁違いなのでそれだけでもすごいことです。
えふしんさんのいるBASEは、BASE以外にもPAY.JPで当ててwいるので私的には「２つの事業を当てた会社」の殿堂に入っています。

いま割と注目しているのは、モバゲーの後、「役員会で事業の良し悪しを判断はできない。いったん市場に出してみてから判断すれば良い」と発言した南場さんです。「私には良し悪しはわからん」「むかし有望事業を望みなしと切って捨てたことがある」と言える大企業の創業者はそうはいない、というかほぼいないので役員会議の前に市場に判断させるという考え方は是非とも注目するところです。

事業に勝つこと

事業的に「勝つ」ことは意外と、人が思うよりは難しくないのかもしれません。自分の事業で勝てなくても、地方に行けば９０年代にロードサイドにチェーン店を出店する話にいち早く飛びついたことでいわゆる「名士」になった中小企業オーナーはそれなりの数がいます。彼らはそれなりの儲けを出していますが、正直に言えば経営哲学やビジョンの素晴らしさによって勝てたか？というと私は微妙に思ってます。

事業というものは、いち早くブルーオーシャンと見つけ、オーソリティとなって多数のユーザーを確保すればユーザーがコンテンツを呼び、コンテンツがユーザーを呼ぶ正のサイクルによって成功することができる場合があります。運営の腕の良し悪しなどどうでもよく、ただ人がいることが最大の機能性となります。つまり、業界最多クラスの多数のユーザーがついた時点で勝ちなのです。運営は凡庸でも関係ありません。
しかし、これでは違う事業を始めるときに「ブルーオーシャン」かつ「多数のユーザーがつく」事業を思いつかないと「２つの事業」で成功することはできません。おおむねこのケースではその２つを満たす事業を思いつかず、凡庸な運営は２匹目のドジョウを狙い失敗します。

私はこう考えています。「再現できない勝ち」はまぐれ勝ちです。その勝利を横展開することはできません。
その勝ちはどの前提条件があれば再現できるのか、という再現条件を見つけ出して「再現性のある勝ちパターン」を発見こその本当の「勝ち」なのです。

事業に勝ち続けること

これは極めて難しい問題です。
すなわち、「２つ以上の事業で勝つ」ための勝ちパターンを見つけなければ、つまり「再現性のある勝ちパターン」を見つけ出せなければ上の条件は達成できないからです。
注意しなければいけないのは、「再現性のある勝ちパターン」というのは「こうすれば絶対勝てる」という話ではありません。

毎朝午前５時に起きて、朝食をとり、新聞を読み、お抱えハイヤーで家を出る。会社の隅の神社にたっぷり３分の祈りを捧げ……みたいな日経新聞の私の履歴書に載っているような名物経営者の朝の習慣を、他の社長が真似すれば、名物経営者と同様の成功を彼は得られるでしょうか。私は得られないと思います。 　

では「再現性のある勝ちパターン」とはなんでしょう。

「再現性のある勝ちパターン」はいわゆる「勝利の方程式」のようなものです。
「２点以上リードのある状況」で「７回で先発をセットアッパーに継投」し、「８回からクローザーに継投」すれば100%勝てると思いますか？　 100%勝てますか？

ありえません。打たれて負ける日もあるでしょう。同点に追いつかれて延長戦の日もあるでしょう。

ただ、フットボールでいう「サイドからウイングがボールを上げて、パスでゴール前につなぎ、タッチダウン」のような比較的成功率の高い手法。あるいはチームの決め技の一つ、くらいの立ち位置で私は「再現性のある勝ちパターン」を捉えています。
実施して勝てなくても、それは弓馬の常というやつだと。

勝ちパターンは「決め技」のパターンの一つです。それだけでは勝てませんが、貯め続けることで勝ちを確信できるパターンを増やすことができます。それはチームの状況次第ですし、活用できるかは監督次第です。
ただ、勝ちパターンを知れば、監督は勝利への「王道」の引き出しを増やすことができます。
それは実際の勝利において極めて重要な点です

負けること

船の水夫のセオリーにおいてDamage Controlという概念があります。
船の船体に穴があいた場合、水がどんどん流れ込んできます。何もしなければ船は沈没です。でも、隔壁を閉めて浸水量を限定し、あとで穴を塞ぎ排水すれば船は沈みません。そのための浸水量を限定するテクニックです。

順調な時は良いのですが、そうではなくなったときのパターンも覚える必要があります。ダメージを限定し、どこかまずかったのか特定し、そこを直し、最悪の場合撤退や部分的なクローズ、縮退もありえます。精神論には頼れません。マーケットは変わったのです。「神国は不滅で神風が吹く、死守命令だ」ではなく、現実的な判断が必要です。
サッカーにおいても負けが確定してもディフェンスを厚くして得失点差をこれ以上悪化させないというのは戦術としてありえます。

よい負け方のパターンを覚えるというのもチームにおいて重要な点です。

ぼくのかんがえた最強の開発手法

皆様はどんなところにお勤めでしょうか？
上場企業にお勤めの方は、開発標準というものを見た事があると思います。中には使いづらい、開発を束縛する、と感じている方もいるのではないでしょうか。

あれは幾つかの理由があって生まれます。

• 監査において、会社で定めた標準に沿って作業されているか？という点がチェックされている
• 上の点から開発標準を１つに統一したい、可能な限りシンプルにしたい(その方がチェックや評価がしやすい)というモチベーションが生まれる
• シンプルな開発標準に合わせてすべての食材をさばける１つの最強の包丁が求められる
• その最強の包丁に合わせて食材や調理方法が束縛される

という負のループが発生しているせいです。

ではどうすれば使いやすい開発手法が作れる？

「最強の開発手法」は誰かが頭の中で考えるものではありません。
日々のフィードバックから「成功を再現させる方法」「失敗を再現させない方法」を再現性のある条件とともに見つけ出します。見つけ出した方法と条件を取り込んだものを使って最強の開発手法を作り出します。
「勝利」とは「再現できる」ことが条件です。できないならそれは「まぐれ勝ち」です。
勝利の方程式とか勝ちパターンとかに沿って作るのが、よい開発手法だと考えています。

つまり勝ちパターンに沿ってルールを決めていくわけです。すくなくとも、監査しやすさに沿ってルールを決めるよりはずっといい開発手法になるとおもいます。

戦略と機動によって勝利する。

イギリスのフラーという人がその昔「相手を打倒(Defeat)することによって勝つことよりもManeuver(戦略、機動)によって勝利するべき」みたいな事を言っていました。
直訳すると「愚者は打倒によって勝利を得ようとするが、賢者はManeuver(戦略、機動)によって勝利を得ようとする」なのですが、意味的には合っていると思います。

事例としてはGoogleが「フィンランド打倒プロジェクト」として全力で検索と広告を押さえに行った事例が最も当てはまると考えます。実際にGoogleは検索と広告を制覇し、仮想敵だったフィンランド、すなわちマイクロソフトをかなりの期間、圧倒しました。
あの時点において検索と広告はオセロでいう「四隅」のような「ここを取れば圧倒的に有利に戦いを進められる場所」でした。

ところがオセロでいう「四隅」は現実のビジネスでは明示されません。どちらかというと重要な場所が動的に形成される囲碁に近いものがあると思います。強い場所とはどこかを見定める観察眼は必要です。観察眼を下支えするのは、過去の経験や定石、棋譜から学んだ知識と経験です。
しかも重要な場所は複数あるため、より重要で、かつ争奪戦に勝利できる強い場所を複数の選択肢から選択できる能力と、その前の選択肢を作り出せる能力が、プロダクトをマネージメントする上で重要と私は考えています。

最近のUXデザインを取り入れたヒットプロダクトの特徴をつらつら考える

最近のUXデザインを取り入れたヒットプロダクトの特徴を見ていると * 最初に「このプロダクトはなにをして自分にどういうメリットがあるサービスなのか」が明示的であること * ユーザーはプロダクトにやることを押し付けられるのではなく、「合理的な判断」に基づき自発的にやることを決定すること * ユーザーの週にプロダクトに使う時間を５時間、１０時間、１５時間と増やすために、ユーザーのフェーズが明確に決められていること * 課金ユーザーの動きと非課金ユーザーの動きがセパレートされていること * 作る人間が、ユーザーに何をさせたいか、ユーザーはどう楽しむのかを明確に理解していること(作っている末端の人間すら理解できないのに、サービス利用者が理解できるわけがない)

とかそういう特徴があるのかなと思いました。
ただ依然として00年代ごろのUXデザインでも十分なシェアを獲得し、十分な伸びを続けており、100人以上の社員を抱える企業はいますので上の要素は必須でもないんじゃないの、と思います。

セオリーを知るということ

チェスのことわざで、「序盤は教科書のように打て」というものがあります。

教科書とは「定石」のことです。要するにセオリーがあって、そこから外さないように打て、ということです。
では序盤で定石を外すとどうなるのでしょう？
例えばオセロの場合。
最初の１０手で、定石から外れた場合ショボいスペックの３年前の家庭用ノートPCのAI相手でも負けます。
電王戦は高性能マシンが相手ですが、おんぼろPC相手でもオセロなら最初で定石を外せば負けます。
それくらい序盤で定石から外れることは致命的なことです。

定石とは、過去の積み重ねを頭の良い達人たちが要約した結果です。
スティーブジョブズのような教科書に載る側の超天才でもない限り、しかれたレールの上を走ったほうが効率的です。
苦労するのは中盤以降なので、セオリーにこだわらない打ち方をするのはそれ以降で良いでしょう。

富士山を登るにも、一合目から歩こうと車で半分まで登ってしまおうと、頂上にたどり着いて帰ってくることが目的なら、選ぶべきは楽できたほうだと思います。
苦労することに意味を見出すスポーツや娯楽ではなく、結果重視のビジネス目的なら特に、です。

変な奇策にこだわってしなくてもいい苦労をするのは賢くはないと思います。
セオリーを知り、知った上でそこから外れるのと、セオリーを学ばずに「柔軟な発想」と言い張るのは違うと思います。 たとえば体を鍛えずにボクシングのリングに登るようなものです。

ということで今日の結論は、セオリーを知ることは、「つまらないことで失敗することを避けるために必要だよ」という話でした。

明日からできるチームの開発生産性の向上

明日からできるチームの生産性向上という小ネタです。

だいたいどこのチームでも通じる鉄板ネタを使ってます。 スクラムしてなくてもアジャイルでなくてもできるネタです。

これで成果出して信用稼いで、それで次のやりたいことをやらせてもらう布石作りにするのが目的だったりします。

１. Pull Requestラリーの削減

レビューを受ける側がPull Requestを出した際に、レビュワーがコメントを付けた後に１作業を入れます。
２人でペアプログラミングのような形で修正させます。
なぜ修正して欲しいのか、どうしてこの形ではよくないのか、どのようなかたちにすべきなのか。
その３点を説明しながら一気に直させることでレビューラリーを１発で終わらせます。

PRのOpenしてからCloseするまでの時間が一気に減ります。
また、同様の指摘が再発する率が減るので、今後の時間の節約になります。
PRのCloseまでのリードタイムが減るため、同時に開かれているPRも減ります。すなわちWIP数の削減につながります。

詳しい方法を聞きたい場合は私から聞き出してください。ビール一杯で話すはずです。

２. PRにテスト内容を追加

PR か Issueを最初に作った初期段階でRSpecでテストすべき内容を書きます。
初期段階、というのはコミットが行われていないか、最初の一回を行った段階です。
なお私の好みとしては1stコミットはspecファイルを空で作った "Implement fake spec of ...."にするのが好きです。
「今回のPRでテストすべき正常系。およびテストで保証したい異常系(存在する場合のみ)」を書くと、だいたいDoneの条件に近似します。
本質的にはどこまで書いたらDoneか、を書かせたいのですがそれを未経験者に理解させるのが難しいためこちらを書きます。
「これもっと細かくPRを分割できるよね？」「そもそもやりたいことがおかしくない？」というツッコミを実装を始める前の段階で発生させることを目的としてにSpecについてPRに書かせます。
ただし、JSでの処理をテストにおいて記述することは難しいです。

これはかなり効果があります。PRというかタスクの質を向上させ、手戻りや「成果に繋がらないタスク」を減らせるからです。
実践方法や詳しい方法を聞きたい場合は私から聞き出してください。ビール二杯で話すはずです。

３. デザイナーからのコンテクスト説明

ProttやSketchにデザインをがっちり書く前に「ユーザーはこの機能を使ってなにをしたいか」「ユーザーにさせるUXをどう考えているか」「ユーザーはこの機能があるとどう嬉しいか」という説明を行います。
この説明の後にはデザイナーによるそう考えた仮説と根拠の提示、非デザイナーからの質疑応答があります。
時間はかかりますが、言語化された説明により開発サイドのモチベーションの向上やコンテクストの共有、「これいけるんじゃね感」や「腹落ち感」の醸成が期待できます。

つまり、ProttやSketchに実際にがっちり書く前に問題点の洗い出しとコンテクストの共有が行われるため、デザインの実装時間の短縮とデザインの効能発揮の打率向上が望めます。

個人的見解ですが、優秀なデザイナーの気合を入れたデザインは死亡フラグです。
実装者はProttoやSKetchからデザイナーの意図を推測し「リバースエンジニアリング」を行うため、再現度の面で粗が出ます。
また、ユーザーは優秀なデザイナーほど察しが良いわけでもなくストレスにも弱くまた流行のデザインと今までのデザインとの差異に拒否感を示しやすいので、おしゃれなデザインから意図を読み取れず離脱する傾向があります。

そこで一度デザイナーの脳内の現実歪曲フィールドから取り出し、「他人の眼」を経て揉み直すことでユーザーが受け入れやすく、また実装しやすいデザインを作れると考えています。
ペーパープロトタイピングなどでの非デザイナーの参画、特にディレクターやセールスの視点の取り込みもとても有効でした。

実践方法や詳しい方法を聞きたい場合は私から聞き出してください。ビール三杯で話すはずです。