こんにちは、坂野です。
今日は東博のやまと絵展を活用して、社員向けに「やまと絵から読み解く日本の住宅史」ツアーを開催しました。

さて、1年半ぶりに筆を取ったのは、ひょんなことからBtoB事業開発アドカレなるイベントに参加させて頂いたからです。では冒頭文。

今回の記事では、エンジニアである僕が、複数の新規サービス立ち上げにあたり、行ってきたことの整理・言語化を試みます。それによって、エンジニア職の人間がbizDev（事業開発）に関わることの意義や、その際の心構えとして後輩の役に立つものを浮かび上がらせることを狙いとします。

自己紹介

株式会社いえらぶGROUPという、不動産業者向けのバーティカルSaaSを提供する会社で、エンジニアマネージャーをやっています。マネージャーとはいえ、思いきり自分の手でプログラミングします。自身の志向もあり、これまでやたらと新サービスを作ってきました。その過程で、企画、開発、戦略策定、顧客提案、オンボーディングとひととおりの業務を複数プロダクトで経験しています。

bizDevを名乗るにはまだエンジニアに寄っていて、力不足の部分もありますが、とはいえ自分の生み出したいくつかのサービスでグロースが見えてきたのと、今年結婚して人生のフェーズが変わったこともあり、この辺りで自分の仕事を言語化してみようと思った次第です。

エンジニアとしてbizDevを行うにあたって

①ニーズの汲み取り：エンジニアは特に意識する必要あり

企画の一部ではあるのですが、普段開発をしていると、視野が狭まり、漏れがちなので分けました。ビジネスチャンスに気づくことはすべてのスタートです。

エンジニアは現場に出ることが少ないので、ここは意識的にやらなければノーチャンスです。社内外、業界内外を問わず、様々な情報に触れることを常に意識しています。一方でエンジニアの強みとしては、営業サイドよりも既存サービスの利用データにアクセスしやすい点が挙げられます。データ分析から示唆を得ることは考えてもいいと思います。

②企画・承認：社内の雰囲気を醸成する

思い立ったら企画して、役員の承認を通して、プロジェクトとして始動させます。企画時に必要な市場調査や営業戦略策定については、詳しい方が多くいらっしゃると思うので、省きます。このタイミングで重要だと考えているのは、社内の雰囲気の醸成です。エンジニアにとっては関門になりえますが、そのサービスがいかに可能性に溢れていて、協力することにメリットがあるか、これを各部門が感じられるよう、対話や発信を通じて、空気を作る必要があります。これに成功していると後が楽です。

③開発：クライアントの現場に関する肌感は必須

開発はエンジニアの特権ですが、経験すればするほど、クライアントの現場についての肌感が必須だと気付かされます。多くのサービスで、営業（またはbizDev）がフィードバックを行いながらエンジニアが開発をしていると思いますが、これでカバーできるのは表側（機能や見た目）の話だけです。ある機能を開発する前に、エンジニアは多かれ少なかれ設計を行います。この設計が曲者で、クライアントの現場に対する理解が乏しいと、悪意がなくてもとんでもないものになることがあります。

たとえばクライアントごとに呼び方は違うが実は同じ概念、というようなモノがあったとき。エンジニアがそれを知らずに別のデータ項目として設計すると、リリース当時は問題ありませんが、後から必ず、片方を変更したらもう片方も変更する、という処理が必要になってきます。すでに両項目を使っているクライアントがいるので、下手に統一もできません。開発スピードは必ず落ち、障害の要因にもなりえます。リリース前に気付ければいいのですが、エンジニア以外が設計段階の瑕疵に気付くのは至難の業だと思います。

だから、エンジニアがクライアントの現場を理解しているのが一番いいのです。僕は、エンジニアがbizDevを行う一番の意義はこの点にあると思っています。エンジニア界隈ではDDD（ドメイン駆動設計）と呼ばれる開発手法で、従来から推奨されていることではあるのですが、それを実現するには、エンジニアがbizDevとして市場調査、ヒアリング、そしてこの後の提案・オンボーディングを行うことで、クライアントの現場への造詣（僕は「肌感」という言葉が一番しっくりきます）を深めていくことが重要だと考えます。

④顧客提案：エンジニアによる提案にはメリットがある

開発したプロトタイプのサービスを、クライアントに提案していく段階です。エンジニアが提案を行うメリットは複数あります。
まず、質問に対する回答が非常に明確に行えます。何しろ仕様を把握しているので。次に、追加要望の対応可否・工数について、その場で見立てが立てられます。最後に、先ほど書いたように、エンジニアが直にクライアントと接することで、クライアントがどういった点を気にするのか、何に違和感があり、何に喜ぶのかを把握することができます。経験上、どんなに営業に詳細な共有を受けたとしても、直接会話をした方が、学びは深いです。結果として、サービスが素早く的を得たものになっていきます。

⑤オンボーディング：まずは1つ成功事例を作る

提案とセットですが、サービス初期で最も大事なのはまず1つ、オンボーディングまで含めた成功事例を作ることだと思います。それによってサービスが全体最適化され、エンジニアとしてのクライアントの現場への理解も一定の成功をもたらせる段階に到達するからです。もちろんそのとき感じた全体最適は、最終的には全体最適ではなかった、ということは多々ありますが、まず1つ成功事例を作ることで、再現性のある成功パターンを1つ生み出します。それができれば、横展開が可能になります。

⑥体制構築：売ってくれる人を作る、その人が評価されるようにする

成功事例を単に横展開するだけなら、成功体験を積んだ自分でやった方が確実です。しかし横展開してグロースさせるとなると、同様の成功を収められる人を増やす必要があります。具体的なタスクとして、資料作成をしたり、成功パターンを言語化したり、といったことは必要ですが、要するに重要なのは、自分のほかに売ってくれる人を作ることです。

理想的には専任で新サービスを提案・オンボしてくれる人を作れるといいです。組織上難しい場合は、ノウハウ・知識をなるべくおろして、提案のハードルを下げるとともに、新サービスで成果を出すことで評価されるよう、社内調整することが大事だと思います。（ここで企画段階の社内の空気の醸成がいきてきます）

まとめ

• エンジニアがbizDevを行う（関わる）意義は、クライアントの現場についての肌感を得ることで、後のグロースの妨げにならないサービス設計と、素早いPMFを実現できることにある。

• エンジニアがbizDevを行う（関わる）際の心構えとしては、企画段階の社内の空気の醸成と、体制構築段階で売ってくれる人を作ることに意識を払うことが肝要である。