検索における2種の条件と3つの機能についての考察
これはなにか
サービスにおける検索行動と検索機能についての考察である。
検索行動とはなにか
サービスにおける検索行動とは、ユーザーが思い描いた条件に合致する商品を見つけるために行う行為である。
たとえば、「男性向けのコンバースの26cmの白色のスニーカーが欲しい」といったケースを想像する。その場合、これらの「条件」をキーワードに含めて検索するか、検索条件に含めて商品を探し、購入するという行動を行うだろう。
この一連の行為の中で、「購入対象となる商品を見つける」という行為が検索行動である。
この検索行動においては、ユーザー自身が自分が求める商品の条件を、明文化された条件という形で明確に頭に思い描けていないというケースもある。（e.g. ◯◯っぽい感じのスカート、◯◯っぽい雰囲気のカフェなど）
そういったケースにはまた別の対処方法があるが、本稿では比較的明文化された条件に対しての検索行動を取り上げるため、割愛する。
商品に求める条件の種別
これらの検索行動に重要な役割を果たす「条件」であるが、この条件には2つの種類がある。 「Must条件」と「Want条件」である。
Must条件とWant条件
Must条件
Must条件とは、この条件が合わないと最終的な行動がそもそもできないという、絶対的な条件である。
例えば、靴を買う際の「サイズ」、賃貸を借りる際の「エリア」などである。この場合の「最終的な行動」は靴であれば「購入」、賃貸であれば「申込み」であり、これらが合致しないとそもそも最終行動ができない、「最終行動の可否を分ける条件」である。
Want条件
一方、Want条件とは、希望の条件に合っていた方が望ましいが、完全に合致していなくても最終的な行動が出来るという、相対的な条件である。
例えば、靴を買う際の「価格」、賃貸を借りる際の「駅からの距離」が該当する。これらは希望の条件に合致しなくとも折り合いがつく、「比較によって意思決定をする条件」である
Must条件とWant条件はグラデーション
ここまで検索条件を2つに大別してきたが、Must条件とWant条件は明確な線引があるものではない。
より厳密に言うと、Want条件はユーザーの意向次第でMust条件になりうる。また、その強さもグラデーションとなっており、これ以上強くなるとMust条件である、といったような明確な段階差はない。
例えば、靴の購入であれば、「一定価格以下でないと予算をオーバーするため買わない」であったり、賃貸を借りる場合であれば、「駅徒歩5分以内でないと絶対に住まない」といった、ユーザーのマイルールとしてWant条件をMust条件化しているケースが存在する。
条件の種別による検索機能UIへの影響
Must条件が「最終行動の可否を分ける絶対的な条件」だと考えると、Must条件は検索階層の上部に所属しているほうがよい。（表示位置ではなく画面階層の話。また、Want条件が同じ階層に同居することは問題ない）
例えば、賃貸を探すときに、次のような手順で絞り込む検索フローだった場合、条件にマッチするものが出ず、1からやり直すことになる。
- 部屋の金額、駅徒歩(Want条件)を先に決めて絞り込み
- その次にエリア(Must条件)入力して表示
逆の順番であれば、手戻りは1ステップで済むだろう。
加えて、金額や駅徒歩は、「他の物件との対比の中で最も良い」という状況で選択ができるため、徐々に条件を緩和して、候補物件を増やして妥協点を探るといった使い方もできるだろう。
また、一度Must条件のみで、検索を実行させ、その後検索結果の絞り込みとしてWant条件でフィルタリングをかけるという検索フローを組むこともできる。
検索機能の種別
検索条件には2つの種別があったが、検索機能は3つの種別に大きく分けられる。
- ディレクトリ型
- 条件並列絞り込み型
- キーワード型
である。
※画像検索、バーコード検索、ID検索といったピンポイント型の検索もあるが、検索の型としてはそんなに広がらないので本稿では扱わない
1. ディレクトリ型
ディレクトリ型は、カテゴリーをドリルダウンして掘っていき、該当するジャンルの商品一覧を出す方法である。
ディレクトリ型の特徴
ディレクトリ型では最終的に求める商品一つにたどり着くのは難しく、検索行動フローの終盤で、ユーザーのマニュアル操作での詳細確認・比較検討にかなりの比重で頼ることになる。
また、商品数が少なく、カテゴリー内の商品が適切なボリュームに保たれている場合は、ゼロマッチを起こさずに商品を見せることが出来るという利点がある。
一方で、サービスが成長し、商品が増えれば増えるほど、カテゴリーを広く深く拡張するか、カテゴリーごとの商品数を増やす必要があるため、探しにくくなるという欠点がある。
ディレクトリ型の活用方法
ディレクトリ型だけで検索行動を完結させることは難しいため、前述のとおりサービスの初期での利用および、Must条件に適応し、その後の絞り込みについては次の「条件並列絞り込み型」に任せるといった使い方をするとよい。
2. 条件並列絞り込み型
条件並列絞り込み型は、全商品群から単一もしくは複数の条件を並列で並べて絞り込んでいき、理想とする商品にたどり着く方法である。
条件並列絞り込み型の特徴
条件並列絞り込み型は、複数のピンポイントな条件で絞り込むことができるため、絞り込み強度が高く、精度高くユーザーの理想の商品にたどり着くことができるという利点があり、Want条件の適応に向いている。
しかし、その体験が実現できるのは、強度の高い絞り込みに耐えられるほど、商品群が豊富にあるときに限られる。
よって、商品群が多く存在しない段階で、良かれと思い、細かく多くの絞り込み条件を提供すると、ユーザーは理想を求めたキツい絞り込みをかけた結果、ゼロマッチ(※)になってしまい、かえって体験が悪化するという欠点もある。
さらに条件並列絞り込み型が苦手な状況として、商品のジャンルがバラバラなものを対象とする場合が上げられる。
例えば、釣具とコスメを探す場合の検索条件は大幅に異なるため、すべての商品を対象にして一括で絞り込みをかけようとするとどうしても無理が出てしまう。
仮にコスメだとしても、液状、パウダー状、固形など形状が異なるし、効能も異なるため、ジャンルごとに個別のUIが必要になってくる。
※ゼロマッチ= 合致する商品がなく、検索結果に商品がなにも出ないこと
条件並列絞り込み型の活用方法
まず、絞り込みの強さについての対策として、サービス内の商品の拡充度合いに応じて、下記のような対応をしてゼロマッチ時の体験をコントロールする必要がある。
- 粒度の粗い絞り込みにとどめる
- ひとつの条件内で複数の選択肢をOR条件で持たせられるオプションを用意する
(e.g. 選択できる都道府県を複数選択出来るようにする)
- ゼロマッチしても何かを必ず返すようにする
(e.g. 勝手に検索条件を緩和した結果を返す、おすすめの商品一覧を返す)
次に、ジャンルごとの条件が異なるという状況に対しては、ディレクトリ型の検索を前工程にはさみ、ジャンル別に検索条件が分かれるようなUIを提供することで解決ができる。
3. キーワード型
キーワード型は、おなじみGoogleを筆頭に一番良く使われているであろう検索型である。
（キーワード型は今回の考察の対象外だったので、初稿時点では割愛します。キーワード型はキーワード型で結構いろいろある気がするので、後日気が向いたら加筆します。）
まとめ
Must型、Want型という2つの検索条件に加えて、ディレクトリ型、条件並列絞り込み型、キーワード型といった検索機能があり、検索条件に合わせて機能を振り分けて、組み合わせることで、サービスのフェーズに合わせた最適な検索体験が提供できるため、サービスの状況を加味して適切に設計していくとよいだろう。
U25 夜のお茶会 Vol.1での学び
これはなにか
- U25 夜のお茶会なるイベントを開催してみたので、まとめてみる
- そこで話した（ことでまとまった）考えを記録する
U25 夜のお茶会ってなに？
- U25(25歳以下)の方と、少人数（~6人くらい）でお話する会です
- 平日の夜に渋谷とかそのへんのコーヒーショップで開催します。
- 私自身はお酒好きですけど、この会ではお酒は飲みません。ノンアルシラフで話します
- スタートアップとかテクノロジーとかじゃなくてもOKです、芸術とかでも何かに打ち込まれてる方ならどなたでもOKです
- 主体的に会話に参加してほしいので、聞きたいこととか話したいことがあるひと限定です。
何目的でやってるの？
1. 若いほうが優れている
若い人たちのほうが優れていると思うので、お話させていただきたいし、つながらせてもらいたいと思ってます。
自分も31歳になって、中堅化し、中年化して感じるのは、古い人が優れているのは経験量のみで、それに伴うパターン認識と思考機会の多さが付属するくらいだということ。
感性も柔軟性も対応力も基本的に若い人のほうが優れている。
つまり、古い人は量的に勝ってるだけで、質的には劣化していっている。
2. 話すとまとまる
対話・会話させてもらうと、考えがまとまるので、自分の意見やスタンス考え方がソリッドになる
3. 自社メンバーに還元したい
自社のメンバーに若い人が多いので、得た知見やまとまった学びを自社のメンバーに還元できるといいなーと思ってます。
※もちろん、この取り組みの延長線上で採用につながることがあれば、それはもちろん嬉しいこと
会話を通じて整理できた学び
今回は下記のbosyuで募って、ご応募頂いた5人の方にお会いさせてもらいました！
そこでの内容をまとめます。
1. 打席数、回転数
戦略の精度を高めるためになにをするか、という話です。 戦略という大それた話じゃなくても、作戦でも計画でも、施策でもなんでもいいんですけど、それらの確率・精度を上げようとすることはあまり重要じゃなくて。それよりも、実行回数を多くしていくことのほうが大事。
イチローでさえ打率3割だし、ユニクロ柳井さんでさえ一勝九敗なので、どんなにワールドクラスに精度を上げたって、10%とか30%とかの世界なので、その変数に労力と時間割いてもあんま意味なさそう。
Googleが何回ピッチで断られたか知ってますか？サイバーエージェントが何回新規事業を潰してきているか知ってますか？メルカリがこれまで何個の失敗したA/Bテストを葬ってきたか知ってますか？
ちなみに僕は知らないです。 そして仮にそれらの数字を知っていたとして、「あー、打率低いし、ダメな会社だよねー」ってなりますか？不思議とならないと思います。
幸か不幸か、自分が思うより周りは自分のことを見てくれてないので、結局最後にホームランを打てたか打ててないかしか見られない。
となると、限られた時間軸の中で、回転数を上げて、打席に立つ数を増やしたほうが、結果として成功確率は高まるかなーと思います。
2. 言い訳を残さないよう振り切る
回転数を上げていくためには、それぞれの戦略やら作戦やら施策やらの仮説検証時間をどんどん短くしてかなきゃいけない。
なので、一個の検証に2年も3年も掛けてられない。そんなことしてたら、生涯打席数が減っちゃって、結局ホームラン打てなくなっちゃう。
となると、一個の仮説検証を一回で終わらせないといけない。この半期やってみたんだけど、○○が原因でポテンシャル出しきれてないから、もう半期やろう！おかわり！とかやってちゃいけない
「仮説の正しさ x 実行やりきり = 成果」 この掛け算の2つの項がどっちも良い感じにやれて初めて成果になるのだけど、一番お寒いのは「今回結果がついてこなかったのは、○○がxxで実行がやりきれていないだけ。次の半期ではそこを改善してちゃんとやりきって仮説をジャッジしよう」ってやつ。
これはただひたすらに言い訳してるだけで、回転数を無駄に下げるムーブ。最初からやりきればいいじゃん。
だから、この「仮説の正しさ」と「実行やりきり」という2つの変数のうち、「実行やりきり」という自助努力でなんとかなる変数による失敗をなくさないといけないと思います。
具体的には、これでダメならこの仮説ダメだって諦めつく、というくらいまで施策を作り込む。手を抜かない。「N数が足りなかったから、検証おかわり！」とか言わないように、ちゃんと集客導線を調整しまくって集めてくる。とかそういう言い訳しないために振り切ってやるのが大事。
※とはいえ、やり込むからと言って無限に時間をかけると、それはそれで回転数が下がるからダメ。言い訳にならなく遅くなりすぎないラインの見極めが大事。どっちやねん。
3. 振り切るためにひとつのフォーカスする
だもんで、振り切る必要があるからこそ、ひとつの要素、検証項目、KPIにフォーカスする必要があると思います。
これには3つの意味合いがあります。
ひとつは、人的リソースの観点。
基本いつだってやりきろう、振り切ろうとすると、リソースは足りないものです。なので、兵力を分散させない。みんなで一個の棒を倒しに行く。
ふたつめは、アセットをめぐる社内調整を減らす意味合い。
たとえば、検証したい新機能が2つあって、別のチームが一緒にリリースしたとします。そうすると、どっちも「ほげほげ率」を見たくて、どっちも言い訳を残さないために、その新機能への導線というアセットを取り合います。例えばTOPバナー枠、例えばPUSH通知…見覚えありませんかね…そんな光景。
このめんどくさい調整をへらすためにも一つに絞るが吉です。
みっつめは、結果が濁る。
特にファネルの前の数字と後の数字の両方に関わるものとか。例えば、アポ取得率と受注率。例えば、サイト訪問率とコンバージョンレート。
一緒に施策を突っ込むと、どっちかがどっちかの影響を受けたとか言い始めて、「この数字が悪いのは仮説の筋が悪いからじゃない、もう一回検証おかわり！」とか言い出すことになります。
振り切るためにも一個にフォーカス！
4. 螺旋階段を登れているか
こうやって回転数を上げて、打席数を多く重ねていくと、次に登場するのが、「あれ、これこの前やらなかったっけか？問題」。いろいろ検証していくと出てくるんです。
例えば、「太客にフォーカスするのが正しい論 vs 薄く広くのお客さまにアプローチするのが正しい論」、どっちが正しいかわからないから、考えながら高速に回転させていっていると、揺り戻し的に、行ったり来たりします。
これ自体は健全だと思っていて、こういうときって、螺旋階段を登っていくような形で前に進んでいっていると思っています。
ただ、このとき気をつけなきゃいけないことがあって、螺旋階段をちゃんと登れているか、上の階に上がれているかをチェックしないといけません。螺旋階段を登っているつもりでも、よく見たら同じところをグルグルと回っていたとかは避けたいです。
そのチェックに使うのが、「この前のと同じベクトルのことをやろうとしてるけど、前回とどこが違うんだっけ？どこがどう違うから、失敗した前回と違って、成功する可能性があるんだっけ？」という問です。最近ほんとよく使ってます。
ここを整理して記録しておくと、同じ失敗をしなくてすみます。結果としてさらに回転数があがり、タイムリミットまでの打席数が増えます。
他にもいろいろ…
他にもこんな話をしたのですが、上記の流れとは少し違うトピック、かつもう結構長くなってきたので、割愛します。
- 右腕を探す
- 方向性とリソース確保
- 正しさ < 結果のデリバリー
気になる方はぜひ、次回の「U25 夜のお茶会」にご参加頂いて、お話しましょう！
最後に宣伝
最後に宣伝を3つ
1. Twitterやってます！
Twitterやってます。無駄ツイも多いですが、フォローしていただけると喜びます！
2. 採用やってます！
「救急車のたらい回しをなくす」というビジョンを掲げて、医療業界向けのVertical SaaSプロダクトを展開する会社、ドクターズプライムをやっています。
絶賛、積極採用中です！カルチャーデッキ作ったのでみてください！
興味を持っていただいた方はコチラからTwiterのDMからご連絡ください！
3. U25 夜のお茶会 Vol.2をやります！
U25 夜のお茶会 Vol.2をやりたいと思っています！ 3月第1週(3/2~3/6)か3月第4週(3/23~27)とかで考えてます！
25歳過ぎちゃってるけど、社会人3年目以内とかの方でもOKです！ ご興味ある方はぜひこちらのフォームからお願いします！
崖から飛び降りながら、組織をつくってはいけない
これはなにか
振り返ると2019年は、組織やその地固をした1年だったと言える。
ハード部分としては、データを適切に扱うためのELTパイプライン、データマートの整備、分析環境の構築など、中長期で事業推進を行うに足る、地固を行った。
一方で、ソフト部分としては、組織に時間を投資した1年だった。
その中で、組織の急拡大とその弊害について考える機会が多かった。 今回のポストでは、その点について記述する。
なぜ組織は急拡大を目指してしまうのか
理由はいくつかある。パッと思いつくだけでも
- 短期で売却によるExitを目指しているので、中長期での組織への影響よりも短期での成長・バリエーションに、創業者の興味関心が強い
- 急拡大するマーケットでシェアを一気に広げないと負けてしまうドメインで戦っている場合
- ex.伸びが顕著でプレイヤーがどんどん出てきている市場、勝者がまだ決まっていない新興市場かつWinner Takes All型でデファクトスタンダードを取らないと負けてしまう市場 etc..
- 「ファンドの償還期間」というビジネスモデルの末端に組み込まれた結果、一定の期間でのExitに対してプレッシャーがかかる
といったものが上げられる。
これらの条件のどれかに合致する場合は、程度の差はあれども組織の急拡大を目指していく方向になるのではないかと思う。
組織の急拡大による弊害
LinkedInの創業者、リード・ホフマンは「起業とは崖から飛び降りながら、飛行機をつくるようなものだ」と言っている。
事業の判断や起業するかしないか、といった点では確かにそのとおりだが、こと組織づくりや採用に関しては、崖から飛び降りながら行ってはいけないと感じている。
飛行機を作るのは、組織やその構成員であるヒトだ。組織やヒトが盤石であれば、崖から飛び降りながらでも飛行機は作れる。 しかし、組織やヒトがしっかりしていない状況で、飛び降りながら組織も飛行機も作る、というのは相当難易度の高い曲芸である。
実際、組織の急拡大による弊害というものがある。
質的な急拡大による弊害
質的な急拡大とは、CxOのようなエラい人が急にパラシュート人事で降りてくるパターンだ。
しかもその人は現場メンバーは会ったこともなければ、知らされてもおらず、当日急に登場し、CxO然とし始める。
適正・能力・組織文化へのFIT感があればよいが、ないと最悪だ。 現場と執行レイヤーの長であるCxOとの間の信頼は作れず、連携は取れず、そのCxOは孤立し、結果機能しなくなる。
さらにそのCxOが政治屋だと地獄である。 メンバーとは連携が取れていないが、自分を採用した経営陣に対しては良いレポートしか上げず、結果正しい情報が経営に行き届かなくなり判断ができなくなる。
量的な急拡大による弊害
量的な拡大とは、実行の手が必要で、目標採用数の達成が絶対とされた採用活動を行い、ヘッドカウントを増やすパターンだ。 この場合、採用のハードルが下がることが考えられる。
採用基準の低下と言っても、いくつか種類があるし、ときには意図的に下げるということが有効な場合もある。 その中でも特にカルチャーFIT面での妥協が一番組織を壊す。 これまで築いてきた組織文化の基盤が崩れるからだ。
組織文化への投資を優先する
質的な急拡大・量的な急拡大どっちにおいても、組織カルチャーへのFITが大切だと考えた。
その観点からドクターズプライムでは、採用面に関して短期利益の追求よりも、中長期的に続く組織の強さを作ることを優先した。
粘り強くそこに投資することが出来たのは3つの理由がある。
- ペインが強く、顧客の財務基盤が盤石な業界であった
- 先にユーザーを集めてあとからマネタイズする投資専攻型モデルではなく、受益者負担型モデルで、投資をした翌月から収益を上げることができるビジネスモデルであった
- 「作らないものづくり」によって、外部株主を招かずに、初期の仮説検証を行うことができた
これらは突き詰めると、
- きちんと顧客の課題を解決して、毎日収益を上げること
- ステークホルダー全員が短期的な事業成長よりも、盤石な組織を作りに投資する方針に賛成していること。
この2点に尽きる。
やってきたこととやらなかったこと
中長期的に続く組織の強さを作るために、2019年にやってきたこととやらなかったことがある。
やってきたこと
- 人事評価・等級制度の策定
- カルチャーコードの作成
- バリューの作成・再定義
- インターンからの正社員登用
- インターン&副業中心の組織体制の継続
やらなかったこと
- バリューが固まる前の中途採用
- CxOの採用
- マネージャーの採用
- 外部資本の組み込み・エクイティでの資金調達
1人目の社員を採用したときから人事評価・等級の制度を整えた。 面倒だから、事業優先だから、まだ必要ないから、色んな理由で数十名まで作らない会社も多いと思う。
一方、人事評価は会社からのメッセージなので、組織としてなにが正しいか、会社として何を評価するのかを明確にして指針を立てることを我々は重要視した。
また、バリューが決まりきるまで、一定期間一緒に働いていない人の採用を行わないことにした。 その時点で、華々しいトラックレコードを持つスーパープレーヤーの採用をすぐには行わないことが決まった。
そして、インターン&副業中心の組織体制の継続および、インターンからの正社員登用を推進していく方針を決めた。
短期的な成長 < 中長期的な組織の強さ
こうして、短期的な成長を求めるがゆえに組織の破壊を導く恐れのある採用を行わないことを決めていった。
自分たちはたまたま運良く、ペインが強くて顧客の財務基盤が盤石なドメインで、受益者負担型のビジネスモデルで事業を展開し、「作らないものづくり」によって、中長期的な組織の強さに投資する意思決定をすることが出来たと思っている。
組織への時間的投資を行った2019年を通じて、組織拡大をしても壊れないための準備が出来てきた。
2020年からは本格的に組織拡大をして、人員的にも事業にドライブをかけていきたいと考えている。
採用やってます！
興味を持っていただいた方はコチラからご連絡ください！
とりあえず話を聞いてみたいという方は TwitterのDMを開放しているので、お気軽にどうぞ！
作らないものづくりで進める、非エンジニアPdMの仮説検証
これはなにか
2019年も、あと残すところ2日という所まで来ました。 個人的には、2019年1月末を最終出社としてメルカリを退職し、中高の同級生である田（でん）と創業した株式会社ドクターズプライムへのフルコミットを開始した、転換点となる年でした。
このポストでは振り返りとして、ドクターズプライムを始める上で、初期から大切にしていた仮説検証の進め方、「作らないものづくり」について書きたいと思います。
3年前の再会
本題に入る前にすこし昔話を。 実はこのDr.'s Primeという事業は、今から3年半ほど前にさかのぼった、2016年5月に田と再開したことをキッカケに始まっています。
私がメルカリに入社したのが2016年の7月なので、実はメルカリに入る前から行っていた事業になります。
チームのバックグラウンドとしては
- 田
- 聖路加国際病院（救命救急医）
- メドレー（Sales）
- 私
- CyberAgent America,Inc.（Producer）
- サイバーエージェント（Director/Project Manager）
- メルカリ（Product Manager）
という構成で、創業チームに技術的バックグラウンドがありませんでした。
医療業界へのパス、セールスの経験は田が持っていて、プロダクトマネジメント、仮説検証の経験は私が持っている。しかし技術バックグラウンドがなく、ものが作れないというのがチームの課題でした。
作らずにどうやって検証するか
このチームでどうやって、サービスを展開し、仮説検証を行っていくか。
そのひとつの形が「作らないものづくり」でした。
「作らないものづくり」とは、必要最低限の開発、ないしは開発を行わない状態で仮説を検証し、検証できたあとに作り込む進め方を指します。
具体的には既存のwebサービスなどを組み合わせて、検証を進めます。
Dr.'s Primeでは、Google Spreadsheet, Google Form, Gmail, Google Apps Script, LINEグループ, LINE@等を利用しました。 HTML, CSSは書きましたが、これも今ではSTUDIOあたりを使えば不要そうです。
プロダクト開発・製品ありきで考えるのではなく、検証したい仮説とその証明ありきで考えることに重きを置いていました。
初期のDr.'s Primeの構成
具体例があったほうがわかりやすいので、実際に初期のDr.'s Primeの構成を見てみましょう。
Dr.'s Primeは医師と病院をつなぐ、非常勤救急医の採用マッチングプラットフォームです。 簡略化した、サービスの利用フローは下記です。
シンプルなTwo Sided Platformのフローです。
これを実現するにあたって、初期のMVPとして、メインループにあたるフローのみを次のような構成で作りました。
- 求人の投稿:
- 病院担当者がGoogle Formsで求人情報を登録
- 求人の掲載:
- スタッフが手作業で応募フォームに転記（運用でカバー！）
- 閲覧・応募:
- iframeで応募用Google Formsを埋め込んだwebページから医師が応募
- 応募の通知:
- 応募が入るとGoogle Apps Scriptが応募テーブルを読み、Gmailを病院に送信
- 採用の判断:
- 病院は採用を判断し、求人案件別の専用メアドに採用する/しないのメールを送信
- 採用の通知:
- Google Apps Scriptで採用判断のメールをパースして読み解き、医師に結果を通知
このように、入力のインターフェースをすべてGoogle Formsに寄せて、そこから自動転記されるGoogle Sheetsをもとにデータベースを作っています。 そのGoogle Sheetsデータベースに対して、Google Apps Scriptで読み書きして、Gmailを出力のインターフェースとして利用者に通知を行います。
また、この図を見ればわかる通り、Google Sheets, Google Forms, Gmail, など非技術者でも直感的に扱えるものを中心に構成されています。 Heroku, HTML, CSS, Google Apps Script, Basic認証などは少し学習する必要はありますが、ググったりProgateを一周やる程度の学習コストで済みます。
サービスを展開する上での機能と利用ツールをマッピングすると下記のようになります。
- 静的ページのホスティング: Heroku
- 静的ページの作成: HTML, CSS
- 入力インターフェース: Google Forms
- データベース: Google Sheets
- サーバー・バックエンドシステム: Google Apps Script
- 認証: Basic認証
- 通知: Gmail
シンプルなマッチングプラットフォームであれば、これらでMVPは成立します。
当然、色んな面で突っ込みどころは満載なんですが、ベータである状況をご理解頂いた、特定の方を対象としたMVPであれば検証は十分進められます。
この「作らないものづくり」で検証を進めて、一定のトラクションを確認することが出来たため、安心して本格的な製品開発に入ることが出来ました。
そのビジネスってスケールするの？に答える
なぜ「作らないものづくり」を選んだか、ということを考えると、理由がいくつかあります。
- 初期のチームにエンジニアリングの能力がなく、ありものでなんとかするしかなかった
- 保守的なので、きちんと市場ニーズがあって、サービスとして成立することを見極めてから進めたかった
このあたりが主な理由です。 しかし、それだけではありません。
新しいサービスを立ち上げる際には、スケールに耐えうるシステムを考える前に、そもそもそのビジネスってスケールするの？という問いに答えなければいけません。
どんなに立派でモダンなアーキテクチャでスケールするシステムを作ったとしても、ビジネスがスケールしなければ、それらは無用の長物になってしまうからです。
その問いに答えるために、自分たちにとって一番最適な進め方がこの進め方でした。
作らないものづくりの利点
作らないものづくりで仮説検証を進めてきて、よかったなと思った点は下記でした。
- 創業チームに開発力がなくてもすぐに仮説検証が始められる
- 仮説検証のサイクルが早くなる
- 提供価値が受け入れられることが証明できてから作るので無駄がない
- ファイナンス的な負債を負わずに仮説検証ができる
4点目はチーム内に開発力があれば問題にならないので、状況によりけりなのですが、私達にとってはとても大きなことでした。
これによって、エンジェルラウンドやシードラウンドで一定比率の株式を放出することなく仮説検証ができ、サービスを本格展開することが出来ました。
作らないものづくりが合わないケース・欠点
一方で、作らないものづくりが合わないケースや、マイナスになる点も勿論あります。
（人間には、自分の決定や仮説をサポートする証拠ばかりを集めてしまう、確証バイアスというバイアスがあります。私の論も多分に確証バイアスを含んでいるでしょう）
- サービスの種類やサービスのコアな提供価値によっては、ちゃんと作らないと検証ができない場合がある
- 創業チームに開発力がある場合は、作ってしまったほうが逆に早く検証ができる場合もある
- 技術的な負債が残る可能性がある
勿論すべては状況によりけりなので、「これこそが唯一至高の仮説検証・MVP作成方法である」とは言いませんが、少なくとも当時の私達にとっては最善の手法だったと思います。
まとめ
ここまでをまとめると、下記の3点になります。
- 「作らないものづくり」とは既存のツールやwebサービスを組み合わせて、仮説を検証する進め方である
- スケールに耐えるシステムの前に、そもそもそのビジネスってスケールするの？という問いに答えなくてはならない
- 作らないものづくりによって、仮説検証のサイクルを早められる場合がある
一方で、チームの保有する能力によっては普通に作ったほうが早く検証できるので、自チームの状況を見極めて、最速の方法で仮説検証を行うのが良いと思います。
採用やってます！
興味を持っていただいた方はコチラからご連絡ください！
とりあえず話を聞いてみたいという方は TwitterのDMを開放しているので、お気軽にどうぞ！
フォーカスを明確にするPMF仮説のマッピング
これはなにか
PMF仮説の検証を進める上で、各仮説の状態を見える化する方法を記したものである。
先日、この記事を読んで、自分の事業はどうだろうと考え、実際に当てはめて作ってみたところ、次の一手を決める指針になったので筆を執った。
なお、この記事は新規サービスの運営者や、それを検討している方に見てもらうことを想定して書いている。
そもそもPMFとはなにか
PMF（プロダクト・マーケット・フィット）は様々な記事で語り尽くされているので、この記事ではその説明に多くを割かない。
他のよりわかりやすい記事を引用して説明に替える。
PMFの定義として頻繁に挙げられるのが、「顧客を満足させる最適なプロダクトを最適な市場に提供している状態」です。
顧客は、あなたがプロダクトを作るのと同じぐらいのスピードでプロダクトを購入する - あるいは、あなたが多くのサーバーを追加するより早くユーザーが増加する。ユーザーからの収益があなたの会社の当座預金口座に積み重なっていく。あなたはできるだけ早くセールスとカスタマーサポートのスタッフを雇おうとしている。
PMF(プロダクトマーケットフィット)とは？事例から学ぶ、PMF達成の測り方とその方法
人々が欲しがるものを作ること (ポールグレアム) 市場を満足させるプロダクトで、正しい市場にいること (マークアンドリーセン) スタートアップのプロダクトに共感する、広範囲の顧客を見つけた状態 (エリックリース)
PMF仮説とはなにか
PMF仮説とは「『これらの仮説が正しければ、PMFが実現する』と事業者が考える仮説群」のことだと私は理解している。
ざっと調べた限りでは明確な定義は見つけられなかったので、上記の理解は私の解釈である。
上記の理解に基づき、PMF仮説はどういった型で表現されるかというと、下記のような形式で表せると考えている
「◯◯であれば(すれば)、△△はxxするはずだ」
より形式化すると以下のようになる。
[条件]を満たす場合、[ステークホルダー]は[期待する行動]をするはずだ」
こういった仮説が、ステークホルダーおよび、それらに期待する行動の数だけ存在すると考える。
これらの仮説群のことをPMF仮説だと、私は解釈した。
なぜこれが大切なのか
なぜ仮説をマッピングするかというと、仮説群を列挙しただけでは、どの順番でどこから着手すべきなのかが明確でないからだ。
実際に、この手順でマッピングを行ったところ、複数あるPMF仮説の状況の可視化とプライオリティが明確になった。
以降、実際にマッピングの方法を記述する。
PMF仮説をマッピングする
チャートの2軸
縦軸に重要度、横軸に進捗度を取り、PMF課題をマッピングする。
- 縦軸: 上にいくほど重要度が高く、下にいくほど重要度が低い
- 横軸: 右にいくほど検証の進捗が良く、左にいくほど進捗が悪い
ポスト・イットにPMF仮説を記載
各ポスト・イットには、先程の「◯◯であれば(すれば)、△△はxxするはずだ」の形式で、PMF仮説を記載する。
ポスト・イットには下記の3つの要素を含める
- PMF仮説: 「◯◯であれば(すれば)、△△はxxするはずだ」の形式でポスト・イット1枚につきPMF仮説を1つ記載
- KPI: PMF仮説の検証を表現するKPIと目標値を定義する
- ステークホルダー: ステークホルダー別にポストイットのカラーを分ける
どうマッピングするのか
以下の手順でマッピングを行う。
2軸を用意したチャートを作る
PMF仮説をポスト・イットに書き出す
重要度・進捗度に応じてマッピングする
複数名でこの作業をする場合、2までを各自で行ったあとで共有し、PMF仮説を絞り込むのが良いだろう。 またその場合、以下のステップを挟むことで、ポジションや声の大きさに引っ張られずに、重要度と進捗度の認識を揃えることができる。
2-1. 絞り込んだPMF仮説ごとに、重要度・進捗度について10段階評価で、同時に数字を言い合う
2-2. なぜその数値にしたのかを議論
2-3. 合意が取れた重要度・進捗度をポスト・イットにメモ
重要度と進捗度の精度について
マッピングを進めていくと、重要度と進捗度の精度の良し悪しに頭を悩ませるかもしれない。
しかし、ここでの目的は「どの順番でどこから着手すべきなのか」つまり優先度の決定であるため、厳密な精度は不要である。
また、ANDREESSEN HOROWITZの12 Things about Product-Market Fitの#8でも書かれている通り、PMFはそんなに明白なものでなければ、一度実現すれば終わりではなく、市況に応じて追い求め続けなければならないものである。
よって厳密な精度で測ること自体はそこまで重要ではない。
もちろん、雑でいいと言っているわけではなく、こだわりすぎて足を止めても仕方がないという話である。
どう使うのか(各象限の意味合い)
マッピングした結果、下図のようなチャートが出来上がるはずである。
第二象限(左上)の、重要度が高く、進捗の悪いPMF仮説を真っ先に取り組んで行けば良い。
実際にいま取り組んでいるテーマが第三象限以外の場合は、そのテーマは重要じゃない可能性がある。
第三象限以外のPMF仮説は言うなれば下記のような仮説群と言い換えられる。
- 重要度が高く、進捗も良い、第一象限(右上): もう十分な仮説
- 重要度が低く、進捗の悪い、第三象限(左下): あとでよい仮説
- 重要度が低く、進捗が良い、第四象限(右下): やらなくていい仮説
これらの象限の意味合いを踏まえて、この章の冒頭のPMFマッピングの例を見てみると、PMF仮説1, 2がもっとも注力すべきものとわかる。
再掲: 章の冒頭のPMFマッピングの例
また、青色のポスト・イットのステークホルダーと黄色のポスト・イットのステークホルダーの、PMF仮説の重要度と進捗度を比べてみると、黄色のステークホルダーのほうが全体的に重要度が低いが、検証の進捗が良い状態であることがわかる。
この場合であれば、黄色のステークホルダーに割くリソースを、青色のステークホルダーにドラスティックに寄せても良いかもしれない。
このように、マッピングを使うことで、注力すべきポイントがわかり、体重の乗せ方を考える参考にすることができる。
まとめ
- PMFを目指す中で、サービスはいくつかのPMF仮説を検証していく
- PMF仮説は複数ある場合が多いと思うが、ただ羅列するだけは少ないリソースをどこに集中すべきかを見失いやすい
- PMF仮説を、シンプルな重要度と進捗度の2軸でマッピングすることによって、それらの状況の可視化とプライオリティ付けに役立つ
- 重要度が高いが進捗の悪い、最重要PMF仮説に注力すると良い
株式会社メルカリを退職しました
これはなにか
いわゆる、退職エントリと言うやつである。
先日、約2年と6ヶ月の間勤めた株式会社メルカリの最終出社を終えた。
多大なる感謝と濃密すぎる2年半で、めっちゃ長文になったけど、ご勘弁を。
目次
- なぜメルカリに入ったのか
- メルカリでなにをしたのか
- メルカリで得たもの
- 内側から見たメルカリ
- では、なぜ辞めるのか？
- なぜそれをやるのか？
- ぐちゃぐちゃした思いの中で、ひとつ明確に言えること
- 最後に
なぜメルカリに入ったのか
メルカリに入る前は、サイバーエージェントで一貫してゲーム畑のPMをやっていた。
SFでのアメリカ支社の立ち上げ→大型ソシャゲタイトルの運用→自社IPタイトルの新規リリースetc.と、いろいろと経験を積ませてもらった。
きっかけはBizDevのミートアップだった。「ちっちゃいベンチャーがヤマト運輸と提携、ってどんなマジック使ってんのよ？」くらいの、ほぼ冷やかしと言っても過言ではない気持ちで参加したミートアップだった。
そこから「業務理解のための面談」を重ねて、気がついたらオファーを頂いていた。
元ウノウ・ジンガ→某チケットフリマの創業メンバーの友人が、最後のひと押しとして「今のメルカリには今しか入れないよ」的な、何かを言っているようで何も言っていないような、しかし僕にぶっ刺さった深イイ言葉をくれて、決断した。
とはいえ、自分のジャッジなので、そこは自分で考えて決めており、当時のノートを見返すと、こんなことを考えつつ、US市場に再挑戦するための意思決定していた。
当時、新卒採用時に自分をアメリカ配属にしてくれた担当役員の方が退任されており、海外市場へ向けたサービスに挑戦する機会は減っていた。
帰国してからは、「まずは地力を上げて、いつか来る大リーグでのバッターボックスに備えよう」という気持ちで一生懸命素振りをしていた。
しかし、当たり前のことだが、素振りをしていても、大リーグでホームランを打つことはできない。
その理由はシンプルで、打席に立っていないからである。
メルカリでなにをしていたのか
メルカリでもまた、US担当→JP担当→話題のメルペイ関連業務と、大変にいろいろな機会を頂き、最終的にメルカリUSで9ヶ月、メルカリJPで1年と9ヶ月の期間を過ごすことになった。
それぞれのステージで、これまでのモノの考え方が、いい意味で覆される経験をし、躓くたびに、「なにくそ」という気持ちとともに知的好奇心、探究心が満たされる2年半だった。
初アサインは念願のメルカリUS
転職時の思いもあり、もちろんメルカリUSのアプリを担当するプロダクトマネジャーとしてメルカリに入社した。
当時はほとんどのリソースをUSアプリに振り切っており、僕も東京オフィスから、USアプリを開発するチームへの配属となった。
余談だが、入社の翌日にメンター兼上長がKR0案件(全社プライオリティトップの超重要案件)にアサインされ、「明日から1ヶ月アメリカ出張になったから、あとよろ！」って感じで放置プレイ セルフOJTの機会をいただき、これがGO BOLDか（そうじゃない）と思ったことを覚えている。
メルカリUSでは、検索周りの改善、オンボーディングの改善、アプリの下タブ化（ハンバーガーメニュー→タブバー）、ホーム改修、ファセットを利用した絞り込み検索など、様々なチャレンジをさせてもらった。
この頃は今以上に技術の「ギ」の字もわかっておらず、多くのひとに迷惑をかけながら仕事をさせてもらい、根気よく教えていただいた結果、今の自分がある。
メルカリJPへの異動
そこからJPへの異動が決まり、メルカリチャンネルの0→1の立ち上げ、スマートフォンに特化したカタログ出品や、検品業者を挟んだ新取引スキーム「あんしんスマホサポート」、決算説明会で取り上げられたカテゴリーグロース戦略の一端を担うなど、ここでもあげるとキリがないほど機会を頂いた。
特にメルカリチャンネルは上海出張から帰国するやいなや、企画→デザイン&仕様策定→開発→ QA→リリースまで含めて全行程2.5ヶ月でリリースしており、タレント起用の大型プロモーションも仕込んであり、スピードもクオリティも求められるプロジェクトだった。
また、スマートフォンのプロジェクトでは、自分の未熟さから、企画から0スタートをしなおすという失敗もあり、学びが多かった。
もともと、個人最適を突き詰めたい宗派に属しているのに、なぜか全体非最適が許せない性格で、障害対応やら、組織の狭間におちるルーズボールを拾って過ごしていたら、社内に関わる人も増えてきて、気づくと最後の9ヶ月はマネジャーとして過ごしつつ、メルカリ本体の数字を伸ばすチームと、メルペイをメルカリに組み込むチームのマネジャーを兼務していた。
ここでも見える世界がぐっと広がり、自分でも施策を持ちつつも、チームのスループットを上げる思考に時間を割くようになった。
メルカリでのマネジメントの経験を通じて、当然様々な学びを得ることができたが、書けないことも多いのと、さらにものすごく長くなるので割愛。
メルカリで得たもの
USチーム、JPチーム両方での経験を通じて、この記事であげたような、プロダクト・サービス・カスタマーに向き合う姿勢を学んだ。
このブログでの発信含め、これらはほぼ全てメルカリで得たものと言っても過言ではない。
日々発生する、BIチームとのやりとりからは、どうKPIを扱い、どう課題を設定し、解決策にアプローチするか、といった問題解決の基礎的な部分を学んだ。
このBIチームと問題解決を通じて、その考え方をINPUTし、また別の課題でOUTPUTしてフィードバックを得るというループはPdMにとっての最大の福利厚生であったと思う。
特に、この記事のお二人にはめっちゃ学ばせてもらった。メルカリでこの2人と働くと、企画者としての第三の目が開眼するので超絶オススメ。
一緒にモノを作る大切な仲間である、エンジニア、デザイナー、QAのみなさんからは、ものづくりの楽しさ、お客様に触っていただけるモノを世に出すことの、苦しみ・喜び・楽しさを教えてもらった。
また、プロダクトチームの良さがフォーカスされて伝わりがちだが、むしろそれ以外のPR, CS, リーガル, 人事, BizDev, マーケ, ファイナンス その他のコーポレート部門の仕事こそ神がかっていて、「プロダクト以外の面でのサービスの伸ばし方」のベストプラクティスを学べたのは今後の大きな資産である。
内側から見たメルカリ
人材のブラックホールと呼ばれているだけあって、各職種でトップクラスのプロプレイヤーがたくさんいる。 そういった人たちと働くのは本当に楽しく、吸収するものが非常に多い。
本来USをやりたかったのでJPに異動になったとき「転職時の本来の目的とズレるし、モチベーション続かないのでは…」と一瞬危惧したのだが、そんなものは全くの杞憂で、非常に楽しく学び続け、気づいたらUSへの拘りは小さくなっていた。
それくらい、毎日が楽しいのである。
組織の特徴として、よく挙げられる点だが、やはり下記は外せないし中から見ててもそのとおり。
- 風通しがよく、積極性と論拠がしっかりあれば、のびのびとなんでもやれる空気がある
- プロダクトを愛し、お客様のほうを向いている人が多い
- 年齢層も比較的高めで、落ち着いて仕事に集中できる
- 働き方もフレキシブルで、子持ち家庭にとってかなり働きやすい
控えめに言って最高な環境だった。
では、なぜ辞めるのか？
なぜそんな最高の環境にいながら、辞めるのか。
ズバッと一言で理由を言い切るのは難しいのだが、次の挑戦として、医療ドメインでVertical SaaSを提供する会社、株式会社ドクターズプライムを友人と共に創業した。
救急車のたらい回しをなくすサービスで、救命救急の領域で病院と医師をつなぐ橋渡しを行う、SaaSプロダクトを提供する。
医療領域のバーティカルSaaSで、プロダクトの類型としては、マッチングプラットフォームに分類される。
広義での医療系スタートアップはたくさん出てきているが、「医療」と一口に言っても、ドメインをよく見ると、DNA解析、創薬、ヘルスケア、予防医学、遠隔診療、電子カルテ、診断領域と切り口は様々である。
救急救命の現場もまた、解決すべき課題が多く、構造的な問題により、失われている命があることは否定できない。
なぜそれをやるのか？
ソーシャルゲーム → CtoCマーケットプレイスと来て、なぜ救命救急のSaaSを創業するのか？
うまく言葉がまとまらないのだが、いくつかの理由がある。
2人の祖母の死と病
先週末、母方の祖母の三回忌があった。
2年前の2017年の2月、アメリカ出張中に、母から電話で話したいという旨のLINEが来た。
当時SF市内にあったオフィスで、ユーザーインタビューを終えた後に電話をかけると、母方の祖母が亡くなったと聞かされた。
急遽、帰国して最後の別れを告げた。
そのときに、人はいつか死ぬ、という当たり前のことを理解した。
また、時を同じくして、大学を卒業するまで一緒に暮らしていた父方の祖母が胃癌の宣告を受けた。
僕にとっては追い打ちをかけるような、急な知らせで、最終的に彼女は胃の殆どを切除し、情報の非対称性と無力さを強く感じた。
この経験に、人の死、命の有限さ、それを前にした無力さを突きつけられた。
パートナーの存在
一緒に会社を創業したパートナーがいる。
代表取締役を務める彼は、当時通っていた中高一貫校の同級生である。
青春時代を共に過ごし、のちに聖路加国際病院という、救命救急で有名な病院の救命救急リーダーを務めた後、医療系ベンチャーでトップセールスとしてビジネスの現場に立っていた。
彼と久しぶりに再開し、会話を重ねる中で、気兼ねせずに率直に話ができる間柄でありながら、自分のプロダクトを作りサービスを運営していく知識・経験と、彼の医療ドメインの知識とセールスの経験が、お互いに補完し合える関係性であることに気がついた。
僕は自然にしていると、他人を意識し、気を遣い、萎縮して、忖度してしまうような人間なので、ナチュラルに遠慮・気兼ねせずに思ったことが言える関係性には非常に助けられている。
メルカリでの体験と着想
最後に、メルカリでの経験も、この意思決定に影響を与えており、背中を押されている。
「モノを欲しいと思う【需要】に対して、モノを渡して対価を得る【供給】を、【直接マッチ】させる」というメルカリの仕組みを抽象化して考えると、救命救急の分野にも応用ができることに気がついた。
メルカリというサービスの企画・運営経験が、自分のプロダクト・サービスの輪郭をはっきりさせてくれたと言える。
また、運良くメルカリ上場の瞬間に立ち会えており、全員が一体感をもって生み出す、その熱量を目の当たりにして、このような組織と瞬間を自分たちの手でも作りたい、と感覚的に思ってしまったことも、この決定に少なからず影響を与えている。
ぐちゃぐちゃした思いの中で、ひとつ明確に言えること
入社の前からその先まで、とりとめもなく、長文を書いてしまい、ほぼ自分史みたくなってしまったが、メルカリは掛け値なしに素晴らしい環境で、先日リリースされたメルペイをはじめとして、仕込んでいる種もあり、これからも輝く場であり続けると思う。
「それでもなぜ辞めるのか？」という問には、きれいに回答できないのだが、ここまで述べてきたような色んな思いが綯い交ぜになって、こうなっている。
そんな中でも、明確にひとつ言えるのが、僕自身も30歳になり、3人目の子供が生まれようとしている中で、「はっきりとした形で世の中に対してポジティブな変化を起こすこと」を、自分自身に対して求める気持ちが強くなっているということだ。
世の中の構造を変え、人々の生活をより良くすることで、子どもたちの世代に対して、自分自身に対して、「自分たちの手で、世の中をより良い方向に変えた」と誇れる仕事をしていきたいと思っている。
最後に
一緒に働く仲間を募集しています！
職種としては、フロントエンドエンジニア、バックエンドエンジニア、デザイナーを募集しています。
サービスの状況としては、ベータ版としてローンチしているモバイルwebを中心に、プロダクトの磨き込みをしており、一通りの機能が整った段階でiOS/Android等のネイティブアプリを展開していく予定です。
すでに数十の病院さまと、数百の医師の方々にご参加頂いていて、現場のニーズも強く、手触り感のあるかたちで順調な滑り出しをしています。
技術スタック的にはこんな感じです！
Frontend
- TypeScript
- React
- Almin
- Sass
- Webpack
- Jest
- Prettier
- Yarn
- Netlify
Backend
Programing Language
- Go
Public Cloud
- Google Cloud Platform
- Google App Engine
- Cloud Firestore (Datastore mode)
- etc.
- Firebase
- Authentication
- etc.
Logging, Analytics
- Stackdriver Logging
- BigQuery
Other
- Serverless
少しでもピンと来た方は、まずは副業からでも良いですし、とりあえずお茶・寿司・肉でもOKですし、インターンも募集しています。
そのほかの職種についても随時募集しているので、下記twitterのDMか、採用情報ページまでお気軽にご連絡ください！
与えてもらった機会と、関わっていただいた皆さんすべてに本当に感謝しています。
めちゃくちゃお世話になりました！
こういう会社を作りたいと思える、最高の会社でした！！
ありがとうございました！！
ものづくりのプロトコルの作り方と大切にしている29の価値観
これはなにか
プロダクトを作るにあたって私が大切にしている29個の価値観を列挙したものだ。
経験上、チーム内でものづくりの前提となる価値観が揃っていると無駄な議論が減り、物事が進みやすい。 私は「ものづくりのプロトコルを合わせる」という表現を使うが、これが合っていると、ものづくりが非常にスムースになる。
この記事ではどうやって、この「ものづくりのプロトコル」の作り方と、事例として私が大切にしている価値観を、自分用のメモがてら書き出した。
ものづくりのプロトコルの作り方
価値観の抽出の仕方
自分が大切に思う価値観を抽出する前提条件として、下記の目線で書き出している。
- 自分の中で当たり前となっているものもすべて書き出す
- プロダクトの定義は、プロダクト≒サービスとなるような広義の意味とする
- プロダクトそのものでなくても、プロダクトに関係する領域であれば、広く書き出す
- チームや組織のあり方は扱わない
ブラックボックスになっている価値観を可視化し、判断基準をあわせることが目的なので、言うまでもないように思えることのほうが、むしろ大切である。
また、組織論を含めると「プロダクトの意思決定の基準となる価値観」からズレてしまうため、扱わない。
どう決めるかよりも、決定の基準を揃え、スムースなプロダクトづくりを行うための「value」を揃えることが重要である。
※行動規範・判断基軸になるという意味では、組織におけるvalueの位置付けに相似する
すり合わせ&プロトコル化
チームメンバー各自の大切にしている価値観を書き出し、すり合わせを行う。
人数規模によっては、中心人物の価値観をベースに、メンバーの声を聞きながら加筆修正を加えていく形でもよいだろう。
ゼロから立ち上げ、これからチームメンバーを集めるフェーズの場合は、先にチームで大切にしたい価値観を定義しておくことで、ミスマッチが防ぎやすくなるだろう。
プロダクト作りで大切にしている29の価値観
最後に事例として、私が大切にしている29の価値観をあげる。一度ですべて書きあげられるものでもないと思うので、今後メンテナンスしていきたい。
粒度やスタイルなど、作成の事例として参考になれば幸いである。
ユーザーファースト
- 01. ユーザーにメリットのないアクションを取らせない
- 02. マーケティング活動もユーザーメリット有りきで考える
- 03. 運営・開発の都合をユーザーに押し付けない
- 04. ユーザーに考えさせない
- 05. ユーザーが受け身でも完結できるようにする
- 06. とにかくシンプルに、わかりやすく直感的に
- 07. 論理的な正しさ ＜ ユーザーの感情面での正しさ
- 08. ユーザーの期待値をコントロールし、ユーザーの期待を裏切らない
- 09. 規約やルールで縛らず、自然とそうしたくなる仕組みを
- 10. ユーザーに会いにいく
分析や狙いどころの考え方
- 11. 穴の空いたバケツに水を入れない
- 12. すべては検証
- 13. 分析は意思決定を行うためにある
- 14. 主観と客観を分離して考える
- 15. ファクトの上で議論する
- 16. 相関で短絡せずに因果をさぐる
- 17. データで証明された命題の成立理由を言語化する
- 18. Vanity Metrics < Actionable Metrics
- 19. Squeeze Toyの概念: ひとつずつフォーカスする
施策の考え方
- 20. オペレーションありきの成立は成立ではない、仕組み化する
- 21. オペレーションは尊いが、オペレーションに逃げるのは悪
- 22. 小さく検証してから仕組み化する
- 23. すべての方針や仕様に狙いを持つ
- 24. ソリューションを考えるのはユーザーの仕事ではない
- 25. 成功するか学習するか
- 26. まず最速で価値提供して、プロダクトの価値を感じてもらう
- 27. 最小単位でリリースして、とにかく届けてフィードバックを得る
- 28. 体験としての早いは正義
- 29. 仕様のひとつひとつに優先度をつけ、いつでも切れるようにする
まとめ
ステークホルダーの多いプロダクトづくりでは、前提の価値観が揃わないことによる無駄なコミュニケーションや議論が、プロダクトの速度を落としていく。
この枠組を利用して、意思決定の前提となる価値観を可視化し、すばやくユーザーに価値を提供していきたい。
