僕はスタートアップや新規事業立ち上げをサポートするプログラムでメンターを担当することがあります。
（「サポート」とか「メンター」という言葉を使う是非は脇に置いておいて…）
今回はメンターを担当する際に考えていることをまとめました。
- メンターを依頼されたもののどういうスタンスで望めばいいかわからない時
- 今抱えているプロジェクトについて、岡島に相談するかどうかの判断材料が欲しい時
などなど、ご参考ください。
メンターとしてチームのお手伝いをする際、口出しするところ/しないところを明確にしている。
- 口出ししない項目
- そのプロジェクトが成功するかどうか
- 口出しする項目
- 「ユーザーに受け入れられるか」の確認方法の設計
- 売上を作る実験
- 技術的な実現性の確認方法の設計
- プロジェクトを進めるための原動力の深掘り
- プロジェクトを進めるための役割分担
口出ししない項目
そのプロジェクトが成功するかどうか
そもそもプロジェクト初期の段階で成功失敗を正しく予測することはほぼ不可能だ。
当初は「技術的に不可能」「技術的には可能でも多分売れない」と判断したチームが、その後多くのユーザーを集め成功した、という経験はスタートアップに助言を求められた人にとっては必ずあるはずだ。
（少なくとも僕はたくさんある）
プロジェクトの成功失敗は「時の運」含め様々な要素により決まる。このような議論はプロジェクトの初期では参考にならないし、参考にならないのであればメンターとして口出しする意味はない。
むしろこの後紹介する「うまくいくかどうかをどのように検証するか」のほうが重要だ。
なお、事業そのものに対する批判の無意味さはこちらの記事を読むとわかりやすい。
口出しする項目
「ユーザーに受け入れられるか」の確認方法の設計
プロダクトの成功失敗が予測できないとはいえ、成功率を上げるために工夫すべきことは多い。開発初期の段階で、プロダクトがユーザーに受け入れられるかを検証する作業がその一つだ。
最近ではPoC（Proof of concept=コンセプト検証）と呼ばれる手法を、様々な企業が実践している。
（事例：MKIと沖縄銀行、AIを活用したテキストデータ解析のPoCを開始）
プロダクトがユーザーに受け入れられるかの検証手法には3つの方向性がある。
- コンテクストの検証（ユーザーがプロダクトをどのように知り、購入し、使うかを検証する）
- ファンクションの検証（必要な機能が動作するかの検証）
- デザインの検証（プロダクトの利用場面に機能が当てはまるかの検証）
それぞれについては深掘りすると話が長くなるので省略するが、多くのチームが勘違いする「完成品間近のキラキラしたプロトタイプを作ってからユーザーテストを行う」という考え方は、手戻りのコストがかかる可能性が高い。
紙工作でもダーティモックでも良いので、低コスト/短時間で作れるプロトタイプをユーザーに触れさせ、その反応を見ることでアイディアの何が受け入れられ、何が受け入れられないかを確認し次のプロトタイプに反映するスタイルが、リソースと時間が限られたスタートアップにとっては有効だ。
どのようなプロトタイプを作るべきかは、そのプロダクトのターゲットユーザーや提供価値により変わる。僕がメンターとして参加する場合はチームが考えるプロダクトの理想像をヒアリングしつつ、どのような実験を最初に行うかを一緒に考えるようにしている。
売上を作る実験
プロダクトの開発が大規模な場合、リリースに時間がかかるしそのプロダクトが売上を生むまでに長い時間がかかる。そうした場合、売上を生むまで自分やメンバーのモチベーションを維持することは難しいし、そのプロダクトが本当にビジネスになるのかも確認しづらい。
そこで、想定するビジネスモデルの縮小版をプロトタイプとしてリリースし、実際に買ってもらえるかどうかを検証する方法を紹介することがある。
例えばチームが、
「AIを駆使して分析レポートを自動生成し有償で提供するサービス」
を開発しているとする。
小売店向けに日々の売上データをもとにした従業員の個別の売上パフォーマンスについてのレポートの生成を行うサービスや、野球チーム向けに練習状況から選手の分析レポートの生成を行うサービス、というイメージだ。
こうしたサービスは、うまくいけば元となるデータをクライアントから受け取るだけで、レポートを短時間かつ低コストで生成できるので、良いビジネスになりそうだ。
しかし一般的にAI分野のプロダクト開発はお金や時間のリソースが膨れがちだ。そして技術的にチャレンジングなプロダクトほどシステム完成の後に販売テストを行いたくなる。
しかし例えば、下記について確認しないまま開発を続けると後から大きな手戻りが発生する可能性がある。
- そもそもクライアントはどのようなフォーマットのレポートを必要としているのか？
- クライアントはレポートにどの程度の精度を求められるのか？
これらを確認するために、まずは人力でレポートを作成する。そしてそれに値札をつけ、売れるかを検証する。こうすることで「少なくともこのフォーマットでこの値段であれば想定顧客に売れるらしい」という自信を得ることができる。これが開発中のプロダクトへの自信につながり、かつユーザーの反応を踏まえてさらに要件を明確にし、開発を続けることができる。
メンターとして関わる場合、こうした「小さい売上を作る実験」の設計を手伝うこともある。
技術的な実現性の確認方法の設計
ハードウェア系のプロジェクトを手伝う際に比較的よくあるパターンだ。量産の視点で必要な要件を洗い出し、どのようなプロトタイプを作ることでそれらの要件を検証するか、こうした一連の計画を一緒に検討することは多い。
プロジェクトを進めるための原動力の深掘り
チームがプロジェクトを進める上で、モチベーションは重要だ。当初のアイディアをもとにしたプロダクトのピボットや閉鎖はあったとしても、最初に設定した「解決すべき課題」に対する挑戦心を維持する事は重要だ。
そこでしばしば、チームリーダーと「なぜそれをやるのか、なぜその人がやらなくてはいけないのか」を深掘りすることがある。
人によっては金銭的な成功を目指すし、人によっては承認欲求を満たすことを目指す。社会の発展を願うケースもある。いずれも正しい原動力だ。
なぜ金銭がほしいのか、なぜ承認欲求を満たしたいのか、なぜ社会発展を願うのか、それらを深掘りすることで、その人の根本的なモチベーションが見えてくる。起業家自身が根本のモチベーションを認識していれば、たとえピボットしてもプロジェクトが迷走する可能性は低くなる。
起業家が自分に嘘をつかずにプロジェクトを進めるためにも、メンターとして適切な提案をするためにも原動力の深掘りは大事だ。
プロジェクトを進めるための役割分担
スタートアップのコアメンバーに求められる役割には以下の4つがある。
- 事業の10年後を描く人（CEO：経営×10年後）
- 今の事業を現場でハンドリングする人（COO：経営×今）
- 10年後、チームが持つべき技術をイメージする人（CTO：技術×10年後）
- 今のメインプロダクトの開発をハンドリングする人（開発責任者：技術×今）
つまり「技術と経営」「今と10年後」の2つの軸で4つのカテゴリに分ける。そしてそれぞれに人的リソースを配置する。
これらの役割は無理に4人に分ける必要はない。メンバーがリーダーひとりだけなら一人四役でも良い。重要なのはシチュエーションに合わせて、これらの役割に合わせて考え方を切り替えることだ。
エンジニア出身のリーダーの場合、目の前のプロダクトの開発に専念しすぎて事業の未来を思い描けず適切なマイルストーンを置けない場合があるし、技術の未来を考えすぎて、今目の前にいる顧客候補の満足度を確かめるための実験計画を設計できない場合もある。
もちろん、一人でこれらをやり続けるのは限界があるので人を増やし、役割を振る必要がある。しかしその場合もただ肩書を与えるだけでなく、上記の4つの役割を自覚してもらうことが必要だ。
起ち上げ当初のチームはメンバーが1,2人という場合が多い。そうしたチームをお手伝いする際は、直面する課題に応じてこれらの頭を切り替えて対応してもらうためにも、「頭の切り替え役」として議論に参加することが多い。
今回は僕が考えるメンターの役割、行っていることをまとめました。立ち上げ初期のチームにとってはいずれも重要なポイントだと思っています。