こちらの記事にスラック(余裕)を設けることの大切さが描かれています。

あるとき、ひどい開発をしたことがあります。
寡少な人員と期間で、過大なタスクリストの消化を求められました。
結果的に徹夜や長時間労働でリリースまでには間に合いましたが、ユーザーの評判はひどいものでした。

要するに結果だけ見て酷い言い方をすれば大量のリソースを突っ込んで、ひどいガラクタを一生懸命作っていたわけです。

さてこの開発をして学んだことがあります。
ユーザー品質にかかわることはタスクリストには乗り切りません。動くものを見ないとわからないからです。そしてそれに最初気づくのは、動くプロダクトの最初のユーザーである開発者です。
ですので、通常の場合は開発者がタスクリストにない、ユーザー品質を上げる暗黙的なタスクを認識し、消化します。
ところが過密なスケジュールは余裕がなさすぎるため、「ユーザー品質を上げる暗黙的なタスク」よりも優先度の高い「タスクリストに記載されたタスク」を消化することに全力を傾注します。結果的にユーザー品質を上げる暗黙的でタスクリストに記載されていないタスクはほぼ未消化のままリリースされるため、ユーザー品質は低くなります。
これをビジネスサイドで認知できるのは、ユーザーの悪評や暗澹たるKPIの数字をもってのタイミングになります。

ユーザー品質を上げる方法は３つあります。
１つめは開発者にユーザー品質を改善する時間を与えること。
２つめは開発者にユーザー品質を改善するモチベーションを与えること。
３つめは開発者にユーザー品質を改善するために、リソースを効率的に使える情報を与えること。

せっかく苦労して作ってユーザーに使っていただけないのは非常に残念なことです。
なにしろどれだけ苦労しようと、開発リソースがほぼ無駄になるわけですから。
あの開発を契機に、ユーザーに使ってもらえる開発を重視するようになりました。

2016-07-13

ユーザーファーストis何

「ユーザーファースト」という言葉を最近よく聞きます。
しかしユーザーファーストとはなんでしょうか？

How Google Works エリック・シュミットという本の中でこの言葉が出てきます。

ユーザーファーストというからには「通常では1stになる"なにか"を差し置いて"ユーザー"を1stにしろ」と言っているように見えます。
では「通常では1stになる"なにか"」とはなんでしょう？

作中では「ヒッポ(かば)」という言葉で表現されています。
ヒッポとは「会社の偉い人」のことです。たとえばテレビのリモコンで、電話がかかってきたときなど頻繁に使う「ミュート」ボタンより、使わない「メーカーからのお得なお知らせ」「マイポータルへ」などのボタンが大きく目に付きやすい場所に配置されるケースがあります。
これは、ミュートボタンが押されても誰の営業成績にもなりませんが、「メーカーからのお得なお知らせ」「マイポータルへ」が押されれば偉い人の成果になるためです。
ユーザーの都合よりも会社の偉い人の都合が優先される、すなわちユーザーではなく会社の偉い人の方をむいてサービスを作るのをやめよう、ユーザーのために作ろう、と"How Google Works"は言っています。

こういうのはヒッポファースト

コンテンツを覆い隠すように表示されるキャンペーンのポップアップ表示(きっとキャンペーンの参加人数がKPIなのでしょう)
コンテンツを見ようとすると執拗に表示される「会員登録をしてください」「あなたの情報を入れてください」(コンテンツを見せるサービスなのに、コンテンツ表示を妨害してでもユーザーの情報を奪いにくる、"前払い"を強要する)
「スマホアプリをDLしてください！」(アプリはすでにインストール済なのにWebから見たせいでしょうか？)
「俺の考えた最高にCOOLなサービスをお前らにも使わせてやるよ」という既存のUXを無視した大幅なUX/UI刷新

それってユーザーファースト？

ユーザーファーストを掲げている会社は多いと思います。
ところで質問なのですが意味を理解していてユーザーファーストと言っていますか？
偉い人が、ユーザーの利益を損ねることを言った場合、あなたは反論できますか？
会社としてそれが支持される雰囲気はありますか？
偉い人に睨まれるのが怖いからみな黙っていませんか？

2016-07-05

Twitterの謎仕様の正体を推測する

タイトルは若干詐欺ですごめんなさい。
小ネタサイズですがWeb開発の経験から推測します。

お気に入りは全件保持されるわけではない

これは実際にやってみるとわかるのですが、あの膨大なレコードの中から全レコードを探索するためパフォーマンスが恐ろしく悪化します。
そのため過去の一定件数に絞ってしか見せない形にすることでパフォーマンス対策をしていると思われます。

画像をアップロードすると謎の文字列に変わってしまう

一つはオリジナルのファイル名に全角文字が含まれていた場合、それを扱うのがいやなのでしょう。全角文字はいろいろやっかいですから。
もう一つはキャッシュを使っているはずですが、同名ファイルだとサーバ側のキャッシュとブラウザ側のキャッシュでそれぞれ見分けがつかず厄介なことになります。たとえば、実際には新しいものに置き換わっているのに古いものがキャッシュのせいで表示されるとか。

2016-07-03

ユーザーに居場所を与えるサービス作り

最近流行っているSNS系のサービスは、いわゆる「バナージやリディ少尉」を満足させるサービスなんだと思いました。
ガンダムUCという小説原作のアニメがあるんですよ。それを例に使って説明します。

ガンダムUCの１巻から引用
そこで主人公バナージがヒロインに向かってこう訴えるわけです。

バナージ「初めて自分の居場所が見えたみたいなんだ。君が誰だってかまわない。必要だって言ってくれ。一緒にいた方がいいって。」

現代人は居場所が欲しい

現代人の欲求として「今の自分には居場所がない」「居場所が欲しい」という欲求を感じているのではないか、という仮説を私は持っています。

例えばtwitter

例えばtwitterでフォロワーが100人になれば、「自分の発言に興味がある人が100人はいる」ということになるわけです。
あるツイートをして100個RTやfavがつくと嬉しいわけです。
日常生活をする上で100人から褒められる、ポジティブな反応をもらえる経験はそうはありません。だからこそユーザーはtwitterにはまり込んでしまうのではないか、と考えています。

褒められたいユーザーがいつく場所

褒められたいと感じるユーザーは褒められやすい場所に居着きます。すなわち、人が大勢いる場所でかつ自分ができることをやって褒められやすい場所です。
単純な人の数と拡散力ならtwitterですし、映像における芸が得意ならyoutubeですし、服のコーディネートがうまいならiqonでしょう。

つまりそういうユーザーを獲得するには「人がいる感」「見せびらかせる感」「自分が何かやっても褒められそう感」がユーザーの獲得と定着に重要です。
事実としてそういう機能が備わっているかよりもユーザーがその期待を実感できるかのほうが１００倍重要だと考えます。そうでないと、ユーザーは居着きません。

サービスを作るときはユーザーが居着くメカニズム作りと、それをユーザーに感じさせるデザインの２つを最近は重視しています。

2016-07-02

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

前提条件として

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

システムしているの？

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

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

約２週間〜４週間
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. 検証

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

2016-06-28

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

勝つこと

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

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

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

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

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

事業に勝つこと

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

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

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

事業に勝ち続けること

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

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

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

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

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

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

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

負けること

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

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

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

2016-06-27

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

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

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

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

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

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

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

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