Clipした日: 2024-11-18T23:13:16+09:00 Clipした記事: [10Xなプロダクトを創る](https://yamotty.tokyo/post/20190514_10x_product) ---- [Top](https://yamotty.tokyo/)/[Post](https://yamotty.tokyo/post) 2020/11/12 19:252023/4/18 12:56  投稿日 2019/05/14 このテキストは「非連続で、未来に必要な(10Xな)プロダクトを創るために私が考えてきたこと」を言葉として叩き出そうとチャレンジしたものです。同時に以下を達成することを目指しました。 - 10X社でプロダクトに関わる人にとっての拠り所となる - 迷ったときに何度も読み返せる - 外部へ公開し、10X社のプロダクト再現性が伝わる 10Xという会社はは人々の生活を一変させるような巨大なイシューのみにフォーカスし、プロダクトという形で貢献したいと思っています。 「様々なアングルから解像度を高めて、プロダクトを創る」というのがチームのスタイルであり、再現性の出し方です。そこへ込められた「度を超えた熱量」が伝わると嬉しいです。 ## **目次** ※ 約2万字あり、また各章について深く掘り下げる項目は別記事を添付している。モバイルで通読するのはすこし骨が折れるかもしれないので、都度該当する箇所を参考にしながら辞書の用に利用してもらえればと思う。 [目次](https://yamotty.tokyo/post/#block-c74ddc88d59547eda4f253a7c5f5ee51)[心を構える](https://yamotty.tokyo/post/#block-8083743c52d342c68c9883ca74b6fe2a)[「気づき」からスタートする](https://yamotty.tokyo/post/#block-c4cd40f782c54ebba78aa1bdc092ecad)[未来に生き、欠けているものをつくる](https://yamotty.tokyo/post/#block-00123f65c11a4f7c8193d52c929eadf9)[神は「順序」に宿る](https://yamotty.tokyo/post/#block-9daf7625bda841d49202e59cec585f68)[変化しうる前提はなにかを想定する](https://yamotty.tokyo/post/#block-8171fd9e05784fd8ac7c773874df71b4)[10倍良いものは「違うもの」である](https://yamotty.tokyo/post/#block-7b0e32b5cc6b4fac9aea8112d7739be7)[時間は有限](https://yamotty.tokyo/post/#block-bd1bc631dd8f4e5b9c7c00febc9c4e50)[避けるべきこと](https://yamotty.tokyo/post/#block-7b923a450b404eec8b874dccb8869473)[人を知る](https://yamotty.tokyo/post/#block-b9d3def7c38f4b0bb0322ced9ebce4d0)[実在する誰かのために創る](https://yamotty.tokyo/post/#block-10c039bb4ce348478680fa0aea16b89c)[観察する](https://yamotty.tokyo/post/#block-a4beb168a046468eb66d5e89d0cfac2e)[イシューから始める](https://yamotty.tokyo/post/#block-f3a05a64dbff46b785014cb901825b10)[ユースケースを置き換える](https://yamotty.tokyo/post/#block-597760313e434853aac741745b334778)[創る](https://yamotty.tokyo/post/#block-c4cfdec201a644049c6d04fb3a6b0307)[実験的であること](https://yamotty.tokyo/post/#block-dcdedbab65464358b28f98c16365239a)[最も偉大な解決方法は「予防」](https://yamotty.tokyo/post/#block-1a45e9b207714391a8340986b5e86851)[壺の中には大きな石から](https://yamotty.tokyo/post/#block-c47b721d19954419b8c7750aec8124b0)[確実に使えるものを創る](https://yamotty.tokyo/post/#block-b93bc0f760df4875ac0044b6523f7ec1)[習慣的に使えるように洗練する](https://yamotty.tokyo/post/#block-3a4d734ceba04a23962942fd481d3073)[クラッシュさせない](https://yamotty.tokyo/post/#block-fb1f9acb857c42a19fbc2dd37d419815)[わかりやすさ、は機能に勝る](https://yamotty.tokyo/post/#block-a9b0ededa7a34225869677f86a16098e)[オンボードする](https://yamotty.tokyo/post/#block-c86efa9affa2475aa614cb7eaa54e08c)[ユーザーの邪魔をしない](https://yamotty.tokyo/post/#block-e97c82564ca5498ea3ed49b41391dd79)[厳選したリリースをする](https://yamotty.tokyo/post/#block-3db18d7023c94aa0812e27cd83b48f0a)[シンプルさを保つ](https://yamotty.tokyo/post/#block-53c7cffdebf8481d824336a7eedaec4c)[分析する](https://yamotty.tokyo/post/#block-5241460108a24e6fb4576e68c5841d73)[分析とは共通言語を創ること](https://yamotty.tokyo/post/#block-b0cd8a4185014ba694aea75f734dda4b)[ことばを扱う](https://yamotty.tokyo/post/#block-8b1785fc4b584cbf9a0460c2d9ddd4c3)[森から木へ](https://yamotty.tokyo/post/#block-0438a81473c645fd84278b06a296e878)[データは1箇所に集める](https://yamotty.tokyo/post/#block-695a3f93d1904170a730fdeb7d35875c)[フェーズに合わせたインジケーターを持つ](https://yamotty.tokyo/post/#block-de22f3ee923d4894b86611f0c4853803)[チャートを正しく読む](https://yamotty.tokyo/post/#block-988faee2fa2444fd8f29cd8b211577ba)[分布を見る](https://yamotty.tokyo/post/#block-890e6907bada443391af984de658a3db)[伝わるダッシュボードをつくる](https://yamotty.tokyo/post/#block-0b750653c9a74ae4a545544a67a2d92a)[届ける](https://yamotty.tokyo/post/#block-482d88bdb5114326bc54936e35b15185)[市場を理解する](https://yamotty.tokyo/post/#block-ecfaf587c0f641ef984ddb529ad494cd)[すべては認知というステージから始まる](https://yamotty.tokyo/post/#block-0d72427582ab47ca9604b8de5c900535)[スケールタイミングを見定める](https://yamotty.tokyo/post/#block-b5e4a7d15ee34e4ca08fb535ee1bfe18)[口コミを生むものがブランド](https://yamotty.tokyo/post/#block-f1982f04bc4645c6aeab8f9e160f416f)[徹底して測る](https://yamotty.tokyo/post/#block-59ca92fbcaf14febb3632fc5c7f58e50)[1つのチャネルを発明する](https://yamotty.tokyo/post/#block-cc7c4f47741c4859a900856a902e78e4)[競合に対するアジェンダ](https://yamotty.tokyo/post/#block-b30b15ba50964b4885599703015718cf)[ダブルジョパディの法則に修練する](https://yamotty.tokyo/post/#block-12b1859592f44c1aad4292d7c2b18a1b)[弱弱アライアンスほど無駄なものはない](https://yamotty.tokyo/post/#block-fb19293d83af450683366618cf3fc595)[チームを創る](https://yamotty.tokyo/post/#block-0c2a0e09245b4724bada380ad8dc0f4b)[チームを構築する意義](https://yamotty.tokyo/post/#block-fc410cfae50d468eaed9a608290d05e8)[違いは「人」で生まれる](https://yamotty.tokyo/post/#block-7ee07c3e5c2d405fa5b7fe1d2c4f3f3f)[背中を合わせる](https://yamotty.tokyo/post/#block-ae5dff9d61ef4993bc6d3996e935b0f1)[チームはプロダクトである](https://yamotty.tokyo/post/#block-5a079031867c4247bc2d3bf3f7e21f96)[チームの価値観は初期に決まる](https://yamotty.tokyo/post/#block-0603dcc19e0f463fa5d6ac0d8fd30b6e)[チームは人数でなくスループットが最重要](https://yamotty.tokyo/post/#block-5cb003c885c64b8e8c6fea299754714e)[個人とチームのインセンティブを揃える](https://yamotty.tokyo/post/#block-68568a66d82f4a0da11c8e50bee70e81)[真のオープンさを目指す](https://yamotty.tokyo/post/#block-bc828fe3d9a34e798afcad670006b5ba)[継続する](https://yamotty.tokyo/post/#block-e9bf68c4a3f04784b96cc57474d84c02)[キャッシュフローをつなげる](https://yamotty.tokyo/post/#block-ee5e7f9c4994477c9b64a429a0ce9141)[ビジネスモデルほどシンプルに](https://yamotty.tokyo/post/#block-40905525e4644ddb92f217ecc0610e1f)[本ドキュメント作成に寄せて](https://yamotty.tokyo/post/#block-153fad553996413f94c01f0929d5b406)[We are Hiring!!!](https://yamotty.tokyo/post/#block-c367917e5a8e4018b7124c779591caa2) ## 心を構える --- ## 「気づき」からスタートする - 科学と技術が発展し全てのスピードが早い現代において、普通に生きていると「不足しているものはない」と感じられる。故に、針の穴を通すような「自分だけが知っている気づき」の中にだけ、その後大きくなりうるものを孕むと考えている。 - 一握りの人間は現状に何かしらの気づきを得ようとしているが、多くの人はそうではない。気づきを得るためには、気づくための訓練が必要だ。現状に「なぜ」を問いかけ、欠けているものを見つける訓練である。 - 僕がこれまでに得た最大の気付きは、どんなに優秀な経営者、起業家、プロダクトマネージャー、クリエイターであっても、「気づきを得る訓練」をしている人は極めて稀だという事実だ。気づきを得るためには、そこにある事象、因果、携わる人の気持ち、外部の構造など全てを深く理解しようと務めなければいけない。1点ではなく、多面をだ。 - 全てを理解するために最も手っ取り早いのは、全ての現場に自分を晒すことにほかならない。気づきがないものにパッチを当てたようなプロダクトを創り始めてはいけない。 **詳細記事** [ スタートアップのアイデア(翻訳) この記事は2012年11月にポール・グレアムが自身のBlogへ投稿した『How to Get Startup Ideas』というエッセイの翻訳記事だ。 ポール・グレアムはシリコンバレー最大の起業家養成スクールである『Y Combinator』の創設者であり、YCの卒業者にはDropbox Airbnb Heroku  https://yamotty.tokyo/post/20171127\_how-to-get-startup-ideas  ](https://yamotty.tokyo/post/20171127_how-to-get-startup-ideas) ## 未来に生き、欠けているものをつくる - 「今は実現していないが、あるべき未来」を具体的に描くことがスタートする。 - 小さなプロダクトからエントリーすることは極めて正しいが、それは戦略上の手段にすぎない。「大きな未来を描き、そこへのステップを具体的にする」ことのほうがずっと重要。 - よくfacebook はハーバード大の学生コレクションからスタートした、といった「小さなプロダクト話」は巷に溢れているが、それらの創業者も初期から大きな未来像でスタートしている。加えて、道中で未来像をさらに拡大させている。 - プロダクトを創るには、厳密にはプロダクト作りをしてはいけない。そのプロダクトが発展し普及した前提で、人間がより豊かになるには、幸せになるにはどうすべきか、という未来像を創らなくてはいけない。 - 未来像は、創り手にとってのWhyになる。例えば「なぜこの施策を行うのか」について最も根源的な答えとなる。 - 逆に未来像がない中で手当たり次第に創作・改善・施策を行うと、再現性がなくただの博打となる。行動した結果が確実に積み上がり、前進し続けるためにも、クリアな未来像が必要。 **詳細記事** [ 未来に生き、欠けているものを創る その過程で考えてきたことを、たまたまあるスタートアップの面々と話す機会があった。テーマは 「どんな未来に、どのくらいの時間軸で仕込むのか」 ということだ。 「未来に生き、欠けているものを創る」 Paul Buchheit (Gmailの発案・開発者) 現状の改善ではなく、未来の当たり前になっているだろう状況と、現状の差分をプロダクトで埋めていくという考え方。 ...  https://yamotty.tokyo/da7e5c77dc3f412fbd03c1ab88edfc0a  ](https://yamotty.tokyo/da7e5c77dc3f412fbd03c1ab88edfc0a) ## 神は「順序」に宿る - 大きな未来像は、一部の人を惹きつけるのには役に立つが、実際はそれのみでは価値がない。 - それよりもずっと大事なのは、どうやってその未来像を実現するかだ。 - 未来像は誰も到達したことのない不確実なものだから、そこから逆算し、「何を、どういう順序で、いつ行うべきか」について自分なりの思考や意志を持つ他にない。 - 特に「順序」は大きなイシューだ。プロダクト創りは、どんな段階にも制約があり、それを無視して先へ進むことはできない。誤ったステップで100の努力をしても、価値は一切生まれない。 - 自分が置かれている状況、そこに潜んでいる制約を正しく理解する必要がある。これはスキルであり、不断の努力を必要とする。 - 正しいステップを踏んでいることを実感できる機会や環境を用意する。この進捗の実感は、不確実な道を進む上で、精神面の支えとなってくれる。 ## 変化しうる前提はなにかを想定する - どれだけ革新的なプロダクトがあったとしても、一般的な人間はご飯を食べ、運動し、他者と繋がり、睡眠するといった「あり方」は変化しない。またプロダクトや事業の外部環境も簡単には変わらない。 - 他方で、様々な世の中のプロダクトや技術によって「行動」は変化する。加工食と流通の普及により、弁当を持参するのではなく、コンビニでお弁当を買うという形に変化したように。 - 将来、産業構造を変えうるほど大きく変化しうる前提はなにか、それはいつ起きるのか、そのとき人の行動はどう変わるのか。そのときに自分のプロダクトはどうあるべきか。未来の解像度を高め、ポジションを決める。 - 前提の変化の兆しは、また別の「未来を創っている実行者」の行動を見ることで気づくことができる。 ## 10倍良いものは「違うもの」である - 「真に深い課題を、10倍良い方法で解決するプロダクト」をはじめから目指す。このときその課題を抱えるユーザーが多いかどうかはそこまで大きな問題ではない。 - 既存のプロダクトに対して、劇的に良いもの、10倍良いものを創る。既存プロダクトの延長で考えてはいけない。10倍良いものでなければ、ユーザーは価値を見出すことが難しい。 - 既存のプロダクトからスイッチするための学習コストや精神コストは、想像するよりはるかに大きい。少し良い、くらいでは絶対にスイッチは起きない。 - 「10倍良いもの」は既存のプロダクトと比べられることがない。「違うもの」としてみなされ、ときに驚きをもって受け入れられる。 - 驚きがあるプロダクトは、口コミを生み、手にとってもらうハードルを下げる。実はプロダクトを届けるコストも格段に下がる。 ## 時間は有限 - プロダクトには常に2つの外部的なプレッシャーがある。 - 1つは「キャッシュの限界を迎える前にリクープをしなくてはいけない」ということ。もう1つは「競争に勝たなくてはいけない」ということ。 - 10Xなプロダクトはそのポジションも異質なため、新しく小さな市場からスタートする。戦い方によっては競争を先延ばしすることができる。 - 他方でキャッシュの限界は明確に存在する。多くの失敗が必要といえ、失敗には優先度がある。 - 時間を最も適切に使うためにも、小さな失敗を重ねてはいけない。価値を大きく伸ばせるような大きなチャレンジのみをする。 ## 避けるべきこと - ユーザーに、自身が欲しいものを聞いてはいけない。彼らは自分が欲しいものを知らない。 - 「まずは創って反応を見る」という姿勢も避ける。 - 洞察のないプロダクトはただの博打になり、たとえヒットしたとしても再現性が蓄積されない。 ## **人を知る** --- ## 実在する誰かのために創る - バイネームで名指しできるほど、具体的な人物のために創る。 - プロダクトを創り始めるにあたり、まず検討すべき最高の対象は自分自身である。次いで、自分の家族・友人・同僚など、**最も頻繁に接する人である**。 - 身近な誰かが心から称賛してくれるプロダクトは、近い環境に置かれた別の誰かにとっても確実に役に立つ。 - 逆に、空想上の誰かのためのプロダクトは誰の役にも立たないものであることが多い。 - 顔を知らない100人が「良いね」と思うものではなく、身近な1人が「なくてはならない」と思ってくれるものを目指す。 ## 観察する  - 目の前に置かれたときに、「私が欲しかったのはこれだ」と言われるものを創る。そのために必要なのは傾聴ではなく「観察」。 - 観察とは、着目した事象が起きている「系」を調査し、起きていることの背景や因果を考察し、自分なりの言語に落とし込むことをいう。 - 観察の起点は目で見るだけではない。ユーザーの実態を知るためにインタビューする、データを分析して統計を調査したり、実際に事象を体験したり、プロダクトのユーザビリティやレスポンスをテストしたりすることなど、あらゆるインプットが起点になる。 - **ユーザーは自分の欲しいものを正しく理解したり、言語化することはできない。** だからこそ観察からスタートすることが重要だ。 - 例えば移動手段として馬が主流だった時代には、人々は早く走れる馬が欲しいと言った。しかし本当に欲しいものは「早く手軽な移動手段」だった。 - あらゆる創作物は、自分が観察できる系の中でしか生まれない。一つの事象ではなく、系の仕組みを観察することで重要な気づきを得ることができる。 - 自分だけが持ち得ている気づきは競争優位性や差別化要因、参入障壁という経営上の最も重要な資産を。すべての源泉は観察から生まれる気づきだ。 **詳細記事** [ Day One 2017年12月20日に生まれて初めてプレスリリースを出し、いくつかのメディアから取材記事も公開していただいた。 このブログは上記で伝えきれなかった自分の思想を、ポツポツと、とりとめもなくまとめたものになる。また性懲りもなく長いため、お時間のある際に読んでいただければ嬉しい。 僕は「人が欲しがるプロダクトを創ること」に人生をかけたい と思っている。 ...  https://yamotty.tokyo/post/20171230  ](https://yamotty.tokyo/post/20171230) ## イシューから始める - 未来と現状のギャップを埋めるために必要なアクションをイシューと呼ぶ。イシューを言語化できないプロダクトは、絶対に前に進むことはないだろう。観察によって得た気づきは大事なものだが、その気づきをそのままアクションにしてはいけない。 - 例えば「自分にとって使いづらい箇所があるから直す」「ユーザーがXXXと話していたので改善したい」などを思いのままに実行するのは、非常に危険だと考える。 - 得られた気づきがどの程度大事なのか、どの程度のインパクトが有るのか、それは今すべきなのか、他に優先すべきイシューはないのかなど、多くの論点があり、これらを客観的に判断してから実行する必要がある。気付きは常に比較可能なサイズのイシューに言語化する必要がある。 - イシューを言語化し、比較し、優先度をつけると、それはロードマップと呼べるものになる。これをIssue Analysisと読んでいる。ふと浮かんだ気づきも、一度Issue Analysisに組み込むことでより精度の高い解決方法に変換できる。 - 多くの直感は間違っている。直感を正しく活かすためにも、Issue Analysis を経由して物事を考える。 ## ユースケースを置き換える - プロダクトは人間が本来もつ機能を拡張するもの、にすぎない。 - つまりユーザーにとってのプロダクトは「今している行動」を置き換える手段となる。 - 「遠く離れた友達と文通する」というユースケースを電話が置き換え、メール、SNS、チャット、アバター等の分岐進化をしてきた。 - ユースケースというのは根源的な欲求に準じている。欲求の満たし方が技術やプロダクトで変化してきたとしても、欲求そのものは普遍だ。 - このプロダクトがどんなユースケースを置き換えていくのか。その先にユーザーの行動はどう変わるのか、をデザインする。 - そのためにも、人間の欲求がどのように構成されているのか、コンテキストを含めて理解する。 ## 創る --- ## 実験的であること - **すべての創作、企画、施策はイシューを検証するために行う**。イシューは存在するのか、深いのか、多くの人が持つのか。この3つの総和が大きなイシューから検証する。決して創ることからはじめてはいけない。 - プロダクトとは狙ったイシューの存在や深さ、広さを確認した上で、それらを解決する手段に過ぎない。 - ただ、プロダクトのレイヤーでも多くの不確実性を孕む。正しい解決策が見つけられるか、多くの人に届けられるか、10Xできるか。これらの論点も極めて不確実性（リスク）が高いものである。 - 成功の確実性を高めるためにも、リスクを正しく言語化し、優先度をつけ、計画を立てて検証していく。科学的実験と同じアプローチをとる。 - 実験をすばやく行うためには、成否をすばやく測定できる環境が何よりも効果を持つ。データ可視化のみならず、一定量のNew Acquisitionはその助けとなる。 **詳細記事** [ リスクの切り分けとテスト文化 プロダクトが「狙った人の課題ををちゃんと解決できているのか」を確認するためにテスト（実験）する、ということを大事にしている。そしてテスト自体が自分だけではなく10Xという会社のカルチャーにもなりつつあると感じている。 リスクの設計 リスクを言語化し、要素を細分化、優先度を判定する リスクの検証 要素に対し可逆的な解決方法を試し、結果をフィードバックする ...  https://yamotty.tokyo/580ac3f485d34589961395c98cda0c90  ](https://yamotty.tokyo/580ac3f485d34589961395c98cda0c90) ## 最も偉大な解決方法は「予防」 - どんな課題に対しても、必ず解決方法は存在する。しかし解法の選択に巧拙がある。 - 一流の解決方法は「**2度とその課題が発生しない状況をつくる**」ことである。すなわち、予防だ。 - 2流は「ある問題を大げさに何度も解決」し、3流は「問題を解決する裏側で別の問題を引き起こす」。 - 抗生剤ではなくワクチンのようなプロダクトを創るべきだ。 - 予防は、目に見えにくい。ユーザー自身も気づかないものが多い。 - 何かの課題を発見したときの第一手は理想的な予防状態を描くことを目指す。その理想状態を目指すことからスタートする。 ## 壺の中には大きな石から - プロダクトにとって最も重要なユースケースを満たす機能を先に実装する。 - **大きな石を先に入れない限り、それが入る余地はその後二度とない。** - 先に小さな機能で満たされたプロダクトは、ユーザーにとって「どういうシーンで使うべきものか」という想起を獲得できない。 - ユーザーから諦められたプロダクトはバリューポジションの変更に大きなコストを要するか、経営判断でクローズすることとなる。 ## 確実に使えるものを創る - 動くプロダクトと、確実に動くプロダクトには天地の差がある。ユーザーにとって、いつでも確かな結果が得られるプロダクトの提供を目指す。 - 確実に動く、というのは文字にすると簡単だが非常に難しい。例えば「パーソナライズされた商品を提案する」という謳い文句に対して、ユーザーが疑問に感じるような提案が含まれていたらどう思われるだろうか。多くは離脱するだろう。 - コアアクションは「確実に動く品質」に磨き上げなければいけない。 - そしてリリース後も、ユーザーの期待の変化に合わせて「確実に動く状態」を維持するための開発を継続する。 ## 習慣的に使えるように洗練する - 優れたプロダクトは、限られたコアアクションを、**いつでも・何度でも・確実に反復可能** にデザインされている。この原則を厳守する。 - 例えばハサミというプロダクトは、「物体を切断する」というコアアクションのために使われる。ハサミが生まれてから現在に至るまでその形状をほとんど変えておらず、原則に従った素晴らしいプロダクトだ。 - 多くても片手で収まる程度のコアアクションを、軽快で、確かに動くものにする。 ## クラッシュさせない - 一度でも期待通りに動かないプロダクトはユーザーに見捨てられる。 - 24/365、不具合がなくクラッシュの起きないプロダクトを目指す。 - しかし不具合0はほとんど不可能である。ソフトウェアプロダクトは、運用しながら改善や機能追加、大幅な変更を同時に行っていく性質があり、その過程でトレードオフは必ず生じる。 - 大事なのは「クラッシュや不具合に迅速に気づける環境」を用意することと、初動の速さである。 - ユーザーからのお問い合わせや、ドッグフーディングをして感じた違和感があるのなら、見過ごしてはいけない。 ## わかりやすさ、は機能に勝る - 一見して、何をどう使ったらよいのかわからないプロダクトは、どれだけ高度なアルゴリズムや、画期的な機能を搭載していても、ユーザーにその価値を100%届けることは無理だ。 - アプリであればほとんどのプロダクトは翌日には60~70%以上のユーザーを失う。またアプリの下タブで複数のタブを利用するユーザーは20%程度だ。そういったファクトを鑑みるに、ユーザーとの初接点の数十秒間で、「このプロダクトはわたしの役に立つものだ」と理解してもらい、期待値をすり合わせる必要がある。 - プロダクトの表示・動作が明快で、解決したい課題とマッチしていることを伝わらなければ、ユーザーは2度と帰ってこない。 - わかりやすさ、に最も重要な要素はユーザーインターフェース（UI）だ。シンプルで、直感的に理解できるUIを提供する。 - またUIはすべての体験において**一貫したシステムのもとで構築されている**必要がある。整合性の取れたUI以外は「デザインされている」とは言えない。 - 逆に「デザインされたUI」は継続的な開発をもスムーズにする。創り手にとって一貫性があり、明確で、シンプルなデザインシステムをもつことは、プロダクトの発展速度とユーザーの体験向上の両方へ対して、複利的に効果をもたらす。 ## オンボードする - どれだけわかりやすいプロダクトが構築できたとしても、我々が創るものは10倍良いもの = 異質なものである。 - 「異質なものの扱い方にユーザーは戸惑う」という前提を出発点とする。そのため、オンボーディングは多くの実験を必要とする。 - 「このプロダクトがあなたのためのもので、どのように使うと便利なのか」の期待値調整をユーザーコンタクトの初手とする。 - 素晴らしいオンボードというのは創り手がダラダラと説明するものではない。 - ユーザー自身が使いながら自然とプロダクトの価値や、扱い方を理解できるオンボーディングプロセスが最上である。 ## ユーザーの邪魔をしない - 不必要なPush通知やメールマガジンでユーザーのマインドシェアを獲得するような、事業者本意の施策は情報過多のユーザーに対し迷惑を以外の何物でもない。 - あくまで「**ユーザーのユースケースに対して、最上のプロダクトかつ第一想起**」だから使われる、という状態をめざす。 - 逆に通知を利用するケースは「見逃すべきではない重要な情報の伝達」などの通知自体が本質的な価値を持つというときに使うものである。 ## 厳選したリリースをする - 「長期的に真にユーザーのためになる」と考えられる機能以外はリリースしてはいけない。中途半端なリリースは、長期的なメンテナンスコストによりプロダクトの改善サイクルを阻む。 - 一度使われた機能は、たとえ数が少なくとも誰かにとっては価値のあるものになりうる。これを後から排除するには多くのエネルギーが必要となる。 - またリリースをしなければ技術的負債は生まれない。コードを削除するだけで済む。 - どれだけコストを掛けて開発したとしても、リリースをしていなければ仕様や設計のミスは取り戻せる。捨てることをためらってはいけない。 ## シンプルさを保つ - プロダクトをシンプルに保つ。何に対してか。ユーザーの目的、そして我々の目的に対してである。可能な限り、この2つの面積が重ねられた状態が「シンプル」である。 - シンプルであることは、ユーザーのわかりやすさのみならず、開発の生産性を保つことにつながる。 - 他方で実験的にプロダクトを創ると、必ず複雑化するジレンマがある。ジレンマのコントロールを失わないために、可能な限りのシンプルさを追求する。 - 効果の低い機能やほとんど使われていない機能は、サンクコストにとらわれずに大胆に削除する。ユーザーからのネガティブ・フィードバックを恐れない。代わりに開発生産性を得られる前進である、と捉える。 - 複雑化した場合、提供価値を抽象化したシンプルなルールへ割り戻す。なかでもUIとアルゴリズムは複雑化しやすい。常に抽象化の機会をうかがう。 ## 分析する --- ## 分析とは共通言語を創ること - 分析とは、意図した通りにユーザーが行動し、満足しているのかを可視化するために行う。これらは意思決定のために使う。 - つまり、分析とは **共通言語を創る仕事** である。 - 言語である以上、「表現できたかどうか・伝わるかどうか」の2点が極めて重要となる。 ## ことばを扱う - 意図が不明瞭なものは、何を計測し、何と比較したら良いかわからない。すなわち分析できない。 - 分析とは「プロダクトがどう使われたらユーザーが満足するか」を日本語や英語などの会話言葉で記述することから始まる。 - イシューや、分析すべき事項を明瞭な言葉で表すことができたなら、その結果は極めて明瞭な数値として計測できる。ただしどういった条件で数値を算出するのかを必ず明確に定義する。 - 良いアナリストとは算術演算に優れた人ではなく、明確な言葉を使え、それを表現する技術に長けた人だと考える。 ## 森から木へ  issue analysis - 何事も大きな問から答えを出し、徐々に細かな問へ向き合う、というのが鉄則だ。 - 「機能に3枚のページがあり、各離脱率を分析し、2枚めに問題があった」といった分析結果を得て、2枚めのページを頑張って改善したが、そもそもその機能を利用するユーザーが全体の5%しかいない、といった自体は少なくない。分析においても優先度やステップは極めて重要である。 - こういった自体を避けるために、予め答えをだすべきイシューの上下関係と、優先付を完了させた上で分析を行う必要がある。 - あらゆる分析や施策もIssue Analysisありきで進める。 ## データは1箇所に集める - ユーザーの行動ログやプロダクトの基盤データなど、可能な限り全てのデータを1箇所に徹底的に集める。 - データ分析はデータの整形、仮説の言語化、集計、チャートへの可視化、インサイトの言語化というフローををとる。 - データが散らばっているだけで、定義の確認、居場所の確認、データ間の連携など集計以前のコストが指数関数的に跳ね上がる。逆にデータを1箇所に集めるだけで、集計のハードルは格段に下がる。 ## フェーズに合わせたインジケーターを持つ  - 分析は問に応じて行うものだ。つまり、分析にも粒度がある。そしてフェーズに応じてベストな粒度は異なる。 - 例えばリリース直後のプロダクトにおいて、単純なリテンションレートなどは適切なインジケーターとはなりにくい。リテンションを構成する要素はチャネル・プロダクト・ネットワークやコンテンツ、データなどのアセットと大きく3つに分解できるが、初期はアセットがほぼ皆無であり、悪かったときの要因の特定が難しい。一方ファネルはUIによって規定され、初めの100人が突破できないファネルは、あとの1万人も突破できない。ユーザーがプロダクトを手にしてから、コアアクションを行うまでのすべての動作を切り刻み、離脱を生んでいる要因を潰すことは資産となる。ただし、ファネルの改善は1.1xとなるものの、ファネルの短縮や組み換えは10xとなりうる。適切なインジケーターをもつと、フェーズに応じた実験が可能になる。 - 逆に成熟しセグメント別に機能を深化させていくフェーズなどでオンボードのファネルをインジケーターとしてもアクショなブルな分析結果は得られない。より対象を絞り、機能の満足度に特化した分析が必要なケースも有る。フェーズに敏感であることが、分析のROIを左右する。 ## チャートを正しく読む - 同じチャートが目の前にあったとしても、そこから意味を読み取るスキルによって洞察の精度は大きく変わる。まず正しく読むスキルを身につける。 - 正しく読むには一つのKPIを見ていても解像度は絶対に上がらない。コンテキストを深く理解する。 - コンテキストをざっくりと理解するために、以下の3点だけは必ず抑える。 1. どの程度のユーザーに影響のあるデータなのか 2. データのボリュームは信頼に足るに十分か 3. 縦（時間軸）と横（類似事例）の比較で、推移はどうなるか ## 分布を見る - 多くの重要な指標は「率」で表されるが、平均は重要な事実を隠してしまう。 - 大事なのは分布 - ヒストグラムである。全体がどのようなユーザー群の分布によって構成されているかを理解しなくてはいけない。例えば「1000人で平均CVR 2%」でも、ピークが分散しているケースもあれば、テールに広がるケースも有る。波形によってたった一つの数字の意味が全く変わる。 - 分布を理解すると、よりプロダクトの使われ方の解像度があがり、ユーザーを正しくセグメント化できる。 - ある機能や施策がすべてのユーザーに影響を及ぼすことは稀だ。しかし分布を確認すると深く刺さるユーザー群とそうでない群が存在することにも気づける。 - プロダクトの深化というのは、複数のセグメントに応じた深化ともいえる。正しくセグメントを捉えるためにも、分布の確認を怠らない。 ## 伝わるダッシュボードをつくる - 数値はそのままでは人間が認知しやすいものとはならない。逆に美しいチャートは事実をシンプルに伝えるのに役立つ。 - 複数のチャートを通じて、洞察の過程を誰もが理解できるようにするのが分析者の役割でもある。そしてそれを手助けするのがダッシュボードだ。 - 理想は誰が見ても同じ結論が導けるダッシュボードである。良質なダッシュボードはドキュメントやオープンな文化と相まってチームの生産性を10xする。 - 他方でダッシュボードをつくるためのBIツールは膨大にあり、扱いやすさという観点も重要だ。その点でRedashは機能が制限されるものの、迷わず使えるという点で良いツールだろう。 ## 届ける --- ## 市場を理解する - 市場（マーケット）とは「特定の経済活動をおこなっているユーザー数 × 頻度」の総和である。 - 自分たちが想定している市場はどのような人で構成されているのか、どのくらいの人がいるのか、なぜ今の市場が形成されたのか、そのコンテキストを知らないことには、プロダクトを届けることは難しい。 - 市場を理解するときは、1人の人に焦点を当ててはいけない。どういった群（セグメント）で構成されているのかを調査し、群ごとに共通するコンテキストを理解できるように務める。 - また自分の経験や感想を持ち込んではいけない。市場とは自分と異なる多くの人で構成されているという前提に立つ。 - これはプロダクトを使うユーザーを理解するときにも全く同じことが言える。プロダクトのことを一番良く理解しているのは創り手だが、使っているユーザーのことはほとんど何も知らない。ユーザーは一人ひとり自分とは違うという前提を忘れてはいけない。 ## すべては認知というステージから始まる - すべてのプロダクトは、「誰もその名前すら知らない」という点から始まる。つまり認知がない - 将来のあらゆるユーザーはプロダクトを認知するところから始まる - そのサービスが何者かを理解し、自分へのフィットを判断し、関心を示し、実際に使ってみて、期待値とのギャップを、もしプロダクトが良いものであれば継続する、という流れをとる - こうしたユーザーのステージに応じて、適切な情報を適切な方法で伝える、という原則を怠ってはいけない - 認知がないユーザーにクーポンをいくらプレゼントしたって、そのサービスが自分の生活に同影響を及ぼすかイメージできなければ、ゴミやノイズにしかならない - デジタルプロダクトマーケティングの多くは「運用型広告によりどれだけ効率的CPAでユーザーを獲得できたか」という観点で語られる事が多いが、これはステージングの概念が欠如している事が多く、注意が必要 ## スケールタイミングを見定める - 早すぎるスケーリングはプロダクトにとって命取りとなる。 - バケツの穴を塞いでから蛇口をひねる。蛇口をいつひねるかは、完全にコントローラブルなはずだ。 - ユーザーが継続して利用する状態 = ユースケースに対して満足の行く状態までは、拡大をしてはいけない。 - それまでは実験を進めるに当たり必要な、最低限のユーザー獲得に留める。 - 他方でスケールするときは速度が重要となる。 ## 口コミを生むものがブランド - 情報とは、伝えるだけでは意味がなく、その情報を得た人が行動を変えるようなものでなくてはいけない。 - 誰にとっても最も信頼できる情報は、信頼できる人からの良質な口コミ（UGC）である。 - 情報が過大な現代において、信頼をのせた口コミを生み出すものがブランドといえる。 - 良質な口コミの数をブランドKPIとし、ブランドをつくる。 - ブランドが口コミを生み、プロダクトをより多くの人へ届ける装置となる。 ## 徹底して測る - 広告やPRは大きくわけて2つの目的で運用される。一つはアテンションを獲得すること、もう一つは売上やそのベースとなるユーザーを獲得すること。 - 特に急速なスケールを狙うにはどちらに対しても、短期的に大きな予算を消化することが世界的に必然となりつつある。 - 広告成果は大きく分けて3つの要素で分解できる。ターゲットはあっているのか、クリエイティブはどういうものが良いのか、良い枠が確保できているのかどうか。 - この3つを正しく分析できていれば、高いROIを得ることができる。逆に、この3つの要素を検証できていない広告成果は再現が難しい。 - オンライン広告はすべてがデータとして取得できる。故に、この3つの要素は徹底して計測できるように環境を整える。 - 2019年時点で、広告成果データを取得するためのAPIはそこまで使い勝手の良い状態ではない。しかし多少の社内開発や力技を駆使したとしても、データを収集・整形し、測定できる環境を整える。それからでなくてはスケールを始めてはいけない。 ## 1つのチャネルを発明する - ユーザーの獲得チャネルは無数に存在するように見えるが、80%の獲得は20%のチャネルに依存する。 - リソースには限りがある。そのため、チャネルの探索後は、いくつかの効果的なチャネル開発に集中すべきだ。 - 同一チャネル内でのユーザー密度が高まると、UGCの発生やバイラルの発生が起こりやすくなる。 - ポートフォリオの形成はチャネル内での十分なリーチが取れたあとでも全く遅くない。 ## 競合に対するアジェンダ - 本質的に競合というのは明確に定義できない。デジタルテクノロジーを利用したプロダクトは複雑系であり、第一想起の競合、可処分時間の競合、可処分所得の競合、採用競合など、切り口によって競合といえる相手は変わる。 - 初期ほど1名でも多くのユーザーにより10Xな価値を届けることや、そのためのチームを創ることに集中するべきである。 - 他方で競争は必ず生じる。「どの競争で、いつNo.1のシェアをとるのか」というアジェンダは重要だが、考えるべきタイミングを間違えない。 - あくまで自社のプロダクトが競合と同じ様に届き始めないことには土俵にすら立てていない。 ## ダブルジョパディの法則に修練する - あらゆるプロダクトが最後はコモディティ化し、大きな差異は「シェア」のみに収束する。そしてシェアこそが継続率や利用頻度に大きな影響を及ぼすようになる。これは長年の観察で確立された法則である。 - だからこそシェアを獲得することから逃げてはならない。 - 小さな誰にも気づかれていない市場から初めて、縦に独占するというはプロダクトの継続率を高める上でも最も有効な戦略である。 ## 弱弱アライアンスほど無駄なものはない - プロダクトを運営していると様々なアライアンスの話は絶えない。そのどれもが「双方にとって少し良さそう」程度のものであり、こういったアライアンス絶対に避けるべきだ。パートナーと手をとるときは「**双方** が大きな目的を同時に達成するか、目的までの距離を大きく縮める事ができる」ケースに限る。 - どんなアライアンスにも必ず3つの仕事がつきまとう。双方にとって大きなリターンを描くこと、相手のコンテキストを深く理解し相手の立場からストーリーを進めること、意思決定のガバナンスを理解し動かすこと。いずれもビジネスタスクのなかで最上級の難度と考える。 - だからこそ小さくファジーなアライアンスに手を出してはいけない。ゲームを前へ進めることに集中すべきだ。 ## チームを創る --- ## チームを構築する意義 - 個の時代にチームを創る意義は極めてシンプルで、「難しいことを実現する」ためである。 - クラウドやSaaSの普及により、個人でも簡易なプロダクトを創ることができる。他方で簡易なプロダクトや、インターフェースを凝らしたのみのプロダクトでは、長期的にユーザーの価値を満たし続けることは難しい。ユーザーの期待値は現状をベースに高まり続けるものだからだ。10Xを目指すのであれば、複合的で、誰もが諦めるような困難な問題に挑戦する必要がある。 - どれだけ有能な個人でも、1人でできることは限定的だ。難しい問題を解くには時間という制約があるから。だからこそチームで難しい問題に取り組むことに意義がある。 ## 違いは「人」で生まれる - チームを誰と構成するか、で最も大きな差が生まれる。 - 世の中にITエンジニアは100万人近く存在すると言われているが、例えば「モバイル × データフロー × アルゴリズム × UI」のように、複数の要素を深く理解し、高い完成度で設計/構築できるエンジニアは1%にも満たないだろう。こういった人材は「学習する力」が並外れている。 - 職種を問わず、「問題を自ら定義し、必要に応じて新しく学び、自ら解決する」という行動規範を持つタレントをGoogle 社はラーニングアニマルと呼ぶ。 - 「磨いてきた強みを持ち寄り、かつ学習の仕方を知っているラーニングアニマルの集団」と「学習の仕方をこれから学習する集団」とでは10xどころではない差が生まれる。 ## 背中を合わせる - あくまで共通のゴールを目指しつつ、複数の問題をそれぞれが集中的に解決するチームを「背中を合わせる」と形容しており、理想としている。 - 複雑な問題を解決するには、問題を解決可能なサイズに分解することが必須だが、分解されたあとも解決が困難であることが多い。 - ときに端的で、短いコミュニケーションを繰り返し、横にいるメンバーの知見を吸い上げながら自分の問題に集中する。これを各人が行うことで極めて大きなスループットが実現できる。 - 個々の影響力、創造力を最大限発揮できるチームを目指すことで、チームのスループットが最大化すると考えている。 ## チームはプロダクトである - **チーム自体がプロダクトである**。チームを磨くことで、その創作物であるプロダクトも磨かれる。 - チームを知ってもらい、同じような意志を持つ潜在的な仲間へアテンションすることから、入社した社員が最高のパフォーマンスをし続け、リテンションしてもらうこと。チームというプロダクトの外から流入し、定着するまで設計し、実行する。 - コーポレートチームは「チーム」をプロダクトとする。その長はチームのプロダクトマネージャーと言える。 ## チームの価値観は初期に決まる - チームの価値観は「はじめの数人が持つ価値観の最大公約数」によって構成される。**初期のメンバーが大事にしているもの以外は残らない**。基本的に行動指針は、「理想を掲げて変えていくもの」として運用するには無理がある。 - **理想的な行動を試み、継続した態度** を言語化するもの。現チームが体現していない行動指針は空虚と思われるだろう。 - 故に創業者から始まる初期数名のメンバーが正しい行動を継続していること自体が、最も重要な行動指針となる。はじめの数人が大事、の理由はここにあると考える。 ## チームは人数でなくスループットが最重要 - チームの価値は人数ではなくそのスループットで測られるべきである。 - チームの人数が増えると、必ずしもスループットが増えるわけではない。「人数が増えたときにスループットが増える」ことが真の採用活動であり、人事活動である - 素晴らしい個人が、素晴らしいチームを構成し、チームとして振る舞うときにスループットが初めて増える。 - 時間あたりのスループットはスピードであり、チームとしての効率がスピードを決める。つまりスピードは「何人を船に載せたか」よりも「誰を船に載せたか」へより強く依存する。 ## 個人とチームのインセンティブを揃える - チームには複数のステークホルダーが存在する。理想状態は、「全ステークホルダーの行動インセンティブが揃っている状態」である。これは意図的に創り出す必要があり、それ以外のケースでは必ずズレが発生する。 - 事業価値を高めることで、それぞれが求めるインセンティブを獲得できる状態を創ることはチームを預かる人間にとって大きな仕事の一つ。 - インセンティブの源泉は「チームが生み出すリターン」である。可能な限り「チームが生み出すリターン」に応じたインセンティブを設計することが最もシンプルである。 - チームが頑張るほどスループットが増え、スループットによってリターンが産まれ、チームに還元される。この流れをマネジメントする。 **詳細記事** [ スループット最大主義の評価設計 2018年、10X社は少しずつ人を増やしながらチームを構築してきた。現在はフルタイムで5名という陣容で、数名の内定者がいる。1年前と比較すると3倍ではあるが、それでもスタートアップという雑な括りで見るとゆっくりとした人数推移かな、と思う。 ...  https://yamotty.tokyo/dc8f7f7cd70c472f835a26a1593e2725  ](https://yamotty.tokyo/dc8f7f7cd70c472f835a26a1593e2725) ## 真のオープンさを目指す - オープンさは「今その場にいないメンバーがいつでも情報を参照できること」「情報が置かれている場所、持っている人が明確であること」「すぐに雑談できる状態」の3つによって担保できる。 - ラーニングアニマルの集団であれば、持っている情報と行動指針が揃えばほとんど同じ精度の意思決定が可能という前提にたつ。誰でも同じ程度の情報をもてる「オープンな環境」はチームのスループットをブーストできると考える。 **詳細記事** [ 真のオープンさとは何か 「真のオープンさ」とは何かについて考えた。先日、あるスタートアップのCOOの方とランチしていて（A、とする）、以下のようなやりとりをした。 A: 「組織が40人に達して、一通りVCから指摘されていた問題が起きてきたところです」 Yamotty、以下、Y: 「おお、よく聞きますね。僕も1回目の起業ではその規模でたくさん失敗しました...ちなみにどんな問題ですか？？」 A: ...  https://yamotty.tokyo/15854b3ce82d44a193a877ddce1ed29b  ](https://yamotty.tokyo/15854b3ce82d44a193a877ddce1ed29b) ## 継続する - イシューが複雑で困難なほど、その解決や、その先の未来の実現にはどうやっても時間がかかり、その短縮には限界がある。長く戦い続けることを前提としたチームを創る必要がある。 - チームが高いスループットを出し続け、大きくし続けるために、キャッシュ・意志を継続できる環境を先手先手で用意する。 - 常に多くの選択肢をもてるようなキャッシュフロー構造、そして人の問題が生まれにくい構造を維持するチーム構造を両立させ、ユーザーのイシューに集中する。 - 目的の不明瞭な施策は長期的な体制構築を自ら妨げる要因になりうる。 ## キャッシュフローをつなげる - キャッシュフローがなければ、どんなチームも継続することはできない。プロダクトに適したキャッシュフロー戦略が肝要となる。 - プロダクトから得られる営業キャッシュフローは垂直で短期なものより、長期的で積み上がるものの時間がかかるものに集中する。 - その間を戦うキャッシュフローとして財務キャッシュフローをうまく組み込み、ポートフォリオをフェーズに応じて組み替えていく。 ## ビジネスモデルほどシンプルに - ビジネスモデルそのものに発明は存在しない。 - 安く買って高く売る、以上である。商材・時間軸・タイミング・プレイヤーによって複雑化しているのみ。 - 多くの変数やプレイヤーを絡める複雑なビジネスモデルはカスタマーにとって理解されづらく、またステークホルダーの理解も得られにくいために立ち上がりにくい。 - 複雑なビジネスモデルを築くより、シンプルな商売を強くすることにリソースを割く。シンプルだが多くの人がアクセスできるビジネスが長期的に最も強い。 ## 本ドキュメント作成に寄せて --- 2019年5月14日、プレスリリース及びいくつかのメディアに取材いただき、10X社としてのアップデートをアナウンスしました。 [ タベリーが「オンライン注文機能」の提供を開始し食材ショッピングアプリへ、あわせて2.5億円の第三者割当増資を実施しました。 パーソナルな献立を推薦するiOS/Androidアプリ「タベリー」を提供する株式会社10X（本社：東京都中央区 代表取締役：矢本真丈）は、同アプリ内で新たに「オンライン注文機能」のサービス提供を開始します。 ...  https://10x.co.jp/news/posts/?id=2019-05-14 ](https://10x.co.jp/news/posts/?id=2019-05-14) これまでほとんど社会でサポートされてこなかった「モバイルから食品を簡単に購入できる」という体験をタベリーの上で実現したこと、そしてファイナンスの2つがプレスリリースのトピックだ。 ファイナンス自体は2018年11月に完了しており、前後して足掛け8ヶ月ほどかけてこのリリースのためにプロダクトと事業を前に進めてきた。今は進捗を公にできてよかったな、という思いだ。タベリーの大きなアップデートにより、「料理を考える、買うものを考える、買う」という行動を全てモバイル上で完結するためのチャレンジがスタートする([2020年9月にクローズ済](https://10x.co.jp/news/posts/?id=2020-06-26))。  タベリー | オンライン注文機能 自分自身も二人の子供を抱え、「献立と買い物のペインは表裏一体」「子連れの買い物ははちゃめちゃに難易度が高い」という気付きからタベリーがスタートした。今回のアップデートによりやっと本丸の入り口に立った心地だ。あくまで入り口でしかなく、今後はこの価値をさらに大きくできるよう、またプロダクトや事業に対し、チームと真摯に向き合っていく。 あわせて、このブログでなにか思いの丈やポエムでも書こうかと思ったのだが、本リリースに当たり最も重要だったのは僕自身の思いの丈などではなく、**10Xなプロダクトを創るという揺るぎないチームの意志と、突き詰めて向き合う日々の行動** そのものだった。とにかく一緒に歩みを進めてくれるチームを尊敬している。 ## We are Hiring!!! --- 資金調達のアナウンスにもある通り、ここからまたチームの可能性を拡げるような素晴らしいメンバーを募り、より強いチームを創っていきたいと考えている。 そのため10X社へ関心がある方へむけて、社のカルチャーや事業の方向性、目指している組織像、そして現在募集しているポジションを含めた資料を公開した。 もし少しでも興味を持っていただいた方は、ぜひ会社の応募フォームへご連絡ください。社会へ10Xを創りたい、そのために自らの影響力を発揮したいという方と出会えることを楽しみにしています。 [ 10X 採用情報 メンバーが長期的に安心して仕事ができることを目指す福利厚生制度 「10X Benefits」 を導入しています。体調不良時、産前・産後・保育園入園、病児対応、介護など、働く上でのイシューをサポートする制度を整えています。 10Xは決して、ネットスーパーシステムを創る開発ベンダーでも、流通小売に特化したコンサルティングファームでもありません。10xを創る集団です。 ...  https://jobs.10x.co.jp/  ](https://jobs.10x.co.jp/)