BizDev入門しての振り返り
手掛けてたものを半分程度世に放つことができ、次のフェーズを考える余裕ができたので半年を振り返るエントリ。
PdM(プロダクトマネジメント) 兼 BizDev をやりはじめて半年、手掛けてたものを半分程度世に放つことができ、次のフェーズを考える余裕ができたので半年を振り返るエントリ。 起こったことと学びを書いていく。
目次
- 事業計画を立てようとして、発散しまくる
- 自分で頑張りすぎない方がよいと気づく
- 結局は得意なこと (PdM) をやればいいと開き直る
- 得意な考え方を軸に状況を俯瞰する
- 最終的には事業の成功
- 方向性やスケジュールの共有で各メンバーが自律的に意思決定できるようにする
事業計画を立てようとして、発散しまくる
エンジニア、PdM ポジションでしか仕事をしたことない状態でいきなり事業計画を立てようとした結果、先々のことまで考えすぎて時間を溶かしてしまった。 一般的に事業計画を立てる際にリサーチが重要だが、何をどの程度リサーチすべきかわかっていなかった。
基本的な考えとして、事業を成功させるには、課題を解く順番を工夫していかに速く効率よく問題を解いていく必要がある。 そのためには、今のフェーズで何をすべきか理解して集中すること。初期の立ち上げフェーズでは、まずプロダクトを立ち上げないと話にならない。 先のことを見据えることは重要だが、その先のことはその手前の仮説が立証あるいはそれに近い状態でなければならない。 Web サービスの場合は、ユーザーが何を求めているか、どのくらいのトラフィックを集められるかも重要だが、最終的にはリリースして数字が出ないとわからない。 立ち上げフェーズでは、とにかくアイデアが山のように出てくるので、その山の中から重要なものを拾い上げて取捨選択して早く実行フェーズに移行しなければならない。
自分で頑張りすぎない方がよいと気づく
前職で難しいシチュエーションを突破した成功体験の代償として、「自分が能力をつけて突破する」という考え方が身体に深く刻まれてしまったことに起因したと思っている。 結果として情報やタスクが溜まって自分がボトルネックになってしまった。 強すぎる学習意欲は全体を滅ぼす。 ある時一人で解決できる課題の量に限界があると気づき、少し考え込んでわからない場合は思い切って前々職の同期やチームメンバーに聞くことにした。 その方が全体として解決のスピードが速いし、思ったより何倍もみんな親身になって助けてくれる。 今振り返ると「自分は一人前なんだ」というちっぽけなプライドがあったように思う。 大事なのはプライドより事業の成功。
結局は得意なこと (PdM) をやればよいと開き直る
自分がボトルネックににならないように頑張りすぎない、詳しい人に頼ると決めた時に発生した疑問が「では自分が何をやるべきか？」だった。 結論から言うと得意なこと、僕の場合は PdM をやればよい。 卵が先か鶏が先か、組織と事業というのは相互に影響を及ぼす。 まずはじめに事業があり、その事業を遂行するに必要な人材を獲得するか、逆に組織がありそのメンバーでできる事業を考案し実行するか。 今回携わった事業では、まず自分に開発と PdM の能力があり、周りにたまたまゲーム開発を行っている同期がいてなんとか形にできた。 なので、構成するメンバーはその時獲得しうる人材で構成されるし、獲得された人材のスキルポートフォリオに依存したアーキテクチャになる。
話がそれたが、要するに自分が得意なこと＋他人に補完してもらえることで事業を成り立たせなければならない。 CEO や CTO に色んなタイプがいるというのもおそらくそういう話なのかなと思った。
得意な考え方を軸に状況を俯瞰する
BizDev に限らず、意思決定をする場合はバランスが重要。なのでできる限りメモリに情報が乗っている状態で意思決定をしないと抜け漏れがあったり、事後の調整に返って手間取ることになる。 考え方のフレームは人それぞれなので、自分がメモリ効率のよい考えのフレームワークを軸に状況を俯瞰できるとよい。 僕の場合はマインドマップ。 マインドマップを常にメンテナンスして、マインドマップ上で課題を切り分ける。 トレードオフとしてマインドマップが膨らみすぎて重要なポイントを落としてしまうことがあるので、もう少しマインドマップをダイエットさせる工夫は必要。
最終的には事業の成功
これはロジカルに考えうる。 まず達成したい未来を思いつくとする。 その未来はどうすれば訪れるか？それはある工夫によって体験が変化し、その状態が継続され人々の考え方が変化し行動変容していく必要がある。 これは殆どの場合一時的な状態では達成し得ない。つまり一時的に売上を上げたとして継続性がなく、一過性のもので終わってしまう。 よって継続的に利益を上げて事業を成立させる必要がある。
BizDev(に限らずあらゆること)はトレードオフの連続である。 トレードオフの主語は色んなものになりうるが、最終的には一番大きな「事業にとってのトレードオフ」を考慮できていないと精度の低い意思決定になってしまう。
余談だが、「いいプロダクトを作る」ことがなぜ重要かも「事業の成功」を軸にすると理解しやすい。
- 事業を成立させるためにはユーザーが使い続けてくれる必要がある。
- ユーザーが使い続けてくれるということはユーザーが目的を達成できるプロダクトを作る必要がある。
- いいプロダクトを作ることが重要
方向性やスケジュールの共有でメンバーが自律的に意思決定できるようにする
事業を成功させるためには、メンバー全員の知恵や能力を最大限に引き出せないといけない。 最大限に引き出すには、なるべくオーバーヘッドをなくせるようにする必要がある。 ではオーバーヘッドとはなにか。それは「迷い」である。 迷いには色んなものがある。
- この問題を報告すべきかどうか
- この問題をどうやって解決すべきか
- この実装はどういう方針で行うべきか
- この作業はいつまでに行うべきか
上げ始めるとキリがない。 これらの迷いをできる限り排除できるようになるべく全員に判断基準や哲学やカルチャーをシェアすべき。 シェアの方法はメンバーが少ないうちは口頭でのコミュニケーションでもよいが、チームはいつ急拡大するかわからないのでできれば早い段階で文書化できているとよい。 文書化する際に自分もそれについて深く考える事ができる。
さいごに
よく聞く言葉として「ヒト・モノ・カネ・情報」という言葉がある。これは思考を整理するのに非常に理解しやすいフレームである。
- ヒト => 採用・育成・配置
- モノ => 資源・原材料
- カネ => 資金調達・売上・コスト
- 情報 => 知識・スキル・コネクション
スタートアップ界隈ではいろんな用語があり一見して理解が複雑に思えるが、最終的にはこの 4 つだと考えると理解しやすくなる。 事業を成功させるということは、「適宜カネを燃やしながら、情報を利用してヒト・モノを獲得しながら価値を生んでいく」ということだと理解するとよさそう。