estie 0→1bizdev、セブンルール

本記事は Calendar for estie Advent Calendar 20215日目の記事です。

このブログ記事を書いた背景

こんにちは、estie料理隊長橋爪です。（料理とこちらの記事は一切関係ございません。）

一般的にはあまり推奨されていないスタートアップ初期からのマルチプロダクト戦略ですが、estieでは新規事業を数件平行して進めています。弊社purposeの「産業の真価を、さらに拓く。」ために、不動産オーナーのみならず業界全体のIX (industrial transformation, 産業の変革) を達成するために、マルチプロダクト戦略を貫いており、不動産業界全体の情報流通構造をより滑らかにすることを目指しています。

自分がestieで働いていて感じる魅力の一つは、会社のフェーズ・規模が進んでも常に新規事業を始める、という起業初期のような取り組みを常時行っていることです。構想段階のプロジェクトもあれば、既にスケールしだしているプロダクトもあるので、自分の得意領域に沿ってプロジェクト間を移動したり、なんていうケースもあったりします。

特にコンサル・不動産会社・商社出身の方で「新規事業とかやってみたいけど、実際どんな感じで進めているか想像がつかない！」、だったりエンジニア・デザイナーの方で「ゼロから開発の設計をしたいと思っていたけど実際どんな感じでestieでやってるのか気になる」といった質問をいただくこともあるので、これを機にestieの0→1 bizdevを実際どう行っているのか言語化しようと思いました。

新規事業担当bizdev橋爪がお届けするestieで新規事業を始める上で徹底している（したい）セブンルールをご紹介いたします。

セブンルール

その事業は今estieにとって必要なのかを考える

estieは不動産情報がスムーズに流れる世界を目指しています。これを分解していくと、オーナー企業内での社内情報共有の仕組みも含みますし、この情報が仲介会社やその先の移転を検討しているテナント会社に情報が展開されるスピードも含まれます。

これらの情報フローを最初から最後まで追う中で、プロダクトで改善可能な個所を特定し、プロジェクトがスタートします。「○○→○○の情報流通を○○で改善する」のようにestieの達成したい未来にどのようにプロダクトが貢献するかを言語化した上で取り組むことが重要です。

そのプロジェクトが「estieの目指す未来に近づくか」に対して「no」の場合は取り組みません。

みんなで決める！三人しかいないので

0→1立ち上げのメンバーは基本的にbizdev, エンジニア, デザイナーの三人 (場合によってはエンジニアもう一人) で進める体制を取っています。

初期のビジネス仮説等はbizdev主導で議論を進めるものの、エンジニア・デザイナーと一緒に議論しながらプロダクトの詳細を詰めます。MVPを定義する上でも「この機能がなければ本当に使ってもらえないのか」というユーザー目線で議論を日々行っています。先週も「これってあったほうがいい気がするけどどうだろう？」と提案したところ、「その機能作るよりはそれなしで早く出したほうがいいですよね」と適切なツッコミをチームから受け、ちゃんとチーム全員を巻き込んで議論した方が意思決定の質が上がる！というのを日々実感してます（当たり前ではありますが）。

それを実現する上で重要なのが各メンバーの高いユーザー解像度で、チーム全員が既存の業務フローの理解とその中での新プロダクトの提供価値の把握、というのが全員に求められます。

社長や取締役は決めない

「方向性は誰かに決めてほしい！」という気持ちにたまになったりしますが、estieでは自分達以外だれも決めてくれません。プロダクトの方向性だったりMVPの定義等はチームで決めます。

「ジブンドリブン」という会社のバリューに定義されている通り、会社のリソースの活用だったり、議論の深堀はジブン主導でガンガン進めます。何が何でも自分から率先して聞きに行くのがestie流。オフィスでとなりに話したい人がいると「すみません、ちょっと今いいですか？」とさくっと5分ほど色々相談してます。

勝手に時間を設定して、社内でそのトピックに詳しい人に壁打ちに付き合ってもらったり、色んな人の頭を借りに行きます。estieでは社長や取締役含め多数のオフィス不動産業界出身者がいて、いつでも仮説の深堀に付き合ってくれて大変助かっています。

ヒアリングが命

今進めているプロジェクトを見返したら2カ月の検証期間で約30社のユーザーさんにヒアリングを行いました（内数社は複数回ヒアリングを実施していて、週約3~4回のペースでヒアリングを行っています）。直接訪問してヒアリングするケースも多く、UIを将来のユーザーに直接見てもらい、実際の業務で使う上での改善ポイント等を伺います。

bizdevは質問・資料等を事前に準備し、figmaを表示しながらヒアリングをリードしますが、ヒアリングはエンジニア含め全メンバー基本参加します。

その改善の提案はそのまま反映する訳ではなく、「ほしい」と言われた機能はその会社の業務にとって必要なのか、我々の提供する本質的な価値を損ねないか、自問自答しながらUIの磨きこみを行っています（次のUIセクションに続く）。

UI, UI, UI

UI→開発という順番を死守することを肝に銘じて日々動いてます。確実に「このUIなら価値を提供できる」ということを担保した状態で実装に進むことを意識しています。

例えばMVPの定義ですが、「これが担保できていないと使えない」ような業界特有な要望もあるので、仮説的なMVPをUIに落としてからも何回もユーザーヒアリングします。

UIを考える上で重要なことは多くあるのですが、二つ重要なことがあるとすれば「現在のユーザー行動」と「あるべき行動」を意識することかと思います。現在のユーザー行動に全く沿っていないプロダクトだと「使えない」や「やりたいことができない」プロダクトになってしまいますし、逆にあるべき行動を意識していないと、現在の業務をデジタル化しただけのプロダクトになってしまい、プロダクトで期待する価値を引き出すことができません。

ここの適切なバランスを考え、figmaに落とし、ユーザー行動を想定行動に誘導できる最適なUIを定義しようと頑張ってます（estieのslackには :figma_hoshii: スタンプまであります笑）。

スケールモデルを定義する

そのプロダクトは一社と共同開発するSaaSなのか、多くのユーザーが利用するプラットフォームなのかでスケールの方法が大きく変わります。どのタイミングでどんなユーザーを取り込むのか、どのタイミングで何社くらい使ってもらう想定なのか、ユーザーのどのセグメントをターゲットするのかを1.5年先まで考え、仮説的に書き出しています。

同じプロダクトでもセグメント・会社規模によってペインやニーズが大きく変わるので、どこのセグメントにどんな機能が必要とされているかヒアリングで聞き出し、長期ロードマップに取り組む機能と取り組むタイミングを書き込みます。

これらは決定事項ではなく、事業の仮説になります。どうしても想定外のことは起こるので、全てをプランニングすることはできませんが、事業成長のイメージをチーム・社内で共有できるようにしています。