彫刻のようにプロダクトを開発する
こんにちは、株式会社CHILLNN代表の永田です。
CHILLNNは宿泊事業者向けにオンライン予約管理のSaaSを提供させていただいている会社です。現在750以上の宿泊施設様にご利用いただいております。
最近（ここ1週間くらい）弊社で実施しているプロダクト開発時のロードマップとマインドセットについて、とにかくワークしており、ぜひご紹介させてください！
経験が増えるほど、身動きが取れなくなる罠
アンラーニングという概念が一般に普及して久しいですが、日々、アンラーニングの重要性を感じています。
人は誰しも生活する中で何かを経験し、特定のパターンを学習していきます。そうして獲得したパターンを組み合わせることで、ある種の予知能力を手に入れることができます。
この予知能力を使うことで「食べて運動せずに寝ると太る」であったり「こんな時間に揚げ物を食べたら太る」など、実際に行動する前にリスク回避的な行動を取れるようになります。
これをビジネスに昇華したのが初期のマッキンゼーを祖とするコンサルティング業であり、さらに抽象度を高めて直接の経験を不要にしたのがロジカルシンキングです。
パターン認識は生きる上でとても便利なのですが、一方で、新しく何かを始めようとした時に足枷になってしまうという側面をもっています。
特定のパターンは、本来特定の状況下でのみ成立するはずなのですが、人間の経験には、1日あたり24時間というハードキャップが存在しており、圧倒的に経験の母数が限られているため、意識しなくては内面化したパターンの過度な一般化を招いてしまうのです。
市場は常に加速しており、状況は刻々と変化しています。
獲得した外的環境に対するパターンはすぐに陳腐化しますし、パターンが成立するコンテキストは大概ずれています。
新しく何かを始める際は、はっきり言ってこれまで学習したパターンのほとんどが邪魔になります。例外は、自分の行動特性の理解くらいです。（夏休みの宿題は最後の日にまとめてやるタイプ、みたいな）
VUCAの時代には、リスク回避的な行動をする以上に、むしろ多少の失敗を許容する事でリスクを最小化していく行動特性こそが重要なのです。
「それはリーンスタートアップじゃないか！」という声が聞こえてくる気がしますが、僕はそれ以前の問題でがんじがらめになっていたので、このマインドセットを共有することできっと、誰かの役に立つと信じています。
本記事では、読書が趣味で、日常的に大量のHowをインプットし続けてしまう自分が、何かをしようとした時に心の中で鳴り響くアラートを乗り越えてチャレンジをする際のマインドセットについて紹介します。
対象のコンテキスト
前置きが長くなりましたが、本記事の対象読者は以下です。
一度目のPMFを達成しており事業成長をしている企業で、さらなる非線形成長のためにアップセル・クロスセルのためのプロダクト開発を行っている
新たな収益軸を作るために、既存事業の収益を投資して、新規事業開発を行なっている
既存事業の資産がある程度あり、それを活かしたプロダクト開発が可能な状況を想定しています。
大前提
大前提として、リスク回避的ではなく、リスクを最小化する行動特性を実現するためには、「失敗をデザインする」必要があります。
ぶっ飛んだ度胸やメンタルを持っていない自分にとって、頭の中に鳴り響くパターン認識アラートを乗り越えるためには、失敗していたとしてもあとで修正できるという心理的安全性を確保する必要がありました。
「事業開発のうまさとは、失敗のうまさ」です。
ここから紹介する4つの方法論は、うまく失敗するための方法です。もし参考になれば幸いです。
① 不確実性が高い順にタスクを並べる
何度目かの事業開発において必ず陥る課題は、サービスリリースまでに必要なタスクへの解像度が局所的に妙に高いことにより、最初から重箱の隅が気になってしまうという問題です。
タスクの優先順位づけこそがプロダクトマネジメントの本質です。もはや事業開発とはタスクの優先順位づけであると言っても良いと思います。
しかし一度事業を立ち上げ、ある程度グロースさせた経験があると、当時踏み抜いた失敗に意識が向きすぎてしまいます。（ex: プライシング、GTM戦略、技術選定など）
一度ぶち当たった課題は、その課題を乗り越えるのに要した苦い経験があるので、重要度が上がりがちです。加えて、乗り越えた方法についてのナレッジがあるので業務の解像度が高く、すぐに手を動かすことができ、なんとなくやっている感を出すことができます。
しかし、断言します。
「解像度の高い業務はやらなくていい」です。
一度失敗して乗り越えたことは、あと回しにしても絶対忘れないし、必要になってからやりましょう。
事業開発におけるタスクは、
絶対に、不確実性が高い順（=市場での検証が難しい順）に並べましょう。
② 重要なタスクは何度も繰り返すことで不確実性を排除していく
タスクを不確実性が高い順に並べるのには明確な理由があります。
事業開発の初期に必要なタスクは、サービス全体のディレクションです。以下に例をあげます。
サービスコンセプト
ターゲットユーザー
プロダクト全体を通したUX設計
これらのタスクは一度決定したら終わりというわけにはいきません。
事業開発は、一歩進むごとに解像度が徐々に上がっていくものです。
最初に決めたコンセプトやターゲットなんて、100%間違っています。
不確実性が高いものを、あらくとも一番最初に決めておくことによって、一歩進むごとにより上位の意思決定を何度も修正することができます。
意思決定の精度は、フィードバックの回数によって磨かれていきます。
弊社では、事業立ち上げのタスクリストを、カンバンボードのようなものでは管理しておらず、上下関係を持たせ、ヒエラルキーを可視化したツリー構造のリストとして、ホワイトボードに貼って管理しています。
このようにしている理由は、一つのタスクをこなしたら、必ずそれよりも上位のタスクにフィードバックを行うためです。
このように業務を進めることで、最もふわっとしている不確実性の高い意思決定を何度も何度も検証することができます。
③ プロダクトビジョンはリリースしてから決める
プロダクトビジョンの策定に時間をかけすぎるべきではないと考えています。プロダクトを作る前にビジョンを作る方法もあるとは思いますが、弊社の場合はそもそも、先にプロダクトビジョンを作ることをやめました。
ビジョンには正解などなく、検証が不可能で議論の余地がないからです。
タスクを進める中でフィードバックが起きない上に、議論の根拠となってしまい、チームの中でここに違和感があると、あらゆるタスクが遅々として進みません。
プロダクトは究極、お客様のためのものです。
経営者が「えいや」で決めてもいいと思いますが、プロダクトビジョンが現実を歪曲して、市場からのフィードバックを正しく解釈できない可能性もあります。経営者のスタンス次第だと思いますが、我々はスピードを優先するために、リリース後に必要になってから決めることにしました。
④ 隣接領域の「そうではないもの」を特定していく
やっとここでタイトルの伏線回収です。
事業開発の初期には、とにかくサービスのセンターピンを一発で特定しようとしてしまいがちです。もちろん、リリースまでにはセンターピンの特定は必要です。しかし、意識しないと、全てを解決するピンポイントのアイデアを考えつづけてしまうという状況に陥ってしまいます。
これは、全く下書きせずに突然ボールペンで線画を描くようなもので、間違えてしまった時、毎回最初からやり直しになります。時間をかけても正解に到達する確率がずっと変わらず、効率の良いやり方とは言えません。
事業開発とは「これは違う」「これは含まれない」と、否定を繰り返すことで、徐々に輪郭を浮かび上がらせていくようなプロセスで進めるべきです。
このアプローチであれば、時間をかけることで考える範囲を狭めていくことができ、確実にセンターピンに近づいていくことができます。
事業開発とは「なにではないのか」を特定していく作業です。
ボヤボヤとした輪郭を、木彫りの彫刻のように徐々に浮かび上がらせていきましょう。
最後に
結局事業開発で達成すべきことは「とにかくリリースすること」です。
世に出るまではなにも始まっていません。
上記の方法論は、あらかじめ失敗を許容するシステムを構築することで、チームの合意形成コストを下げることができます。素早くチームの合意形成ができれば、素早くリリースをすることができます。リリースをすることができれば、より精度高く仮説を検証していくことができます。
みなさま、早いチームを作りましょう。
稚拙な文章を最後までお読みいただきありがとうございました。事業開発とは己との対話なのだと、運動部のように日々を過ごしております。
CHILLNNではこんな感じで、日々、アウトプットをnoteに残していくことにしました！もし少しでもお役に立てたならシェアしていただけると本当に嬉しいです！
We're hiring!!!
めちゃくちゃ人が足りません！！！
ぜひカジュアル面談に応募してください〜〜〜！！！
この記事が気に入ったらサポートをしてみませんか？