インキュベイトファンドの村田氏が登壇

畑浩史氏（以下、畑）：それでは最後のセッションを始めさせていただきたいと思います。

「そもそもエンジニア経営って何なの？」というところもあると思うのですが、VCの視点でエンジニア経営の強みや留置点を、ざっくばらんにお話しいただけたらと思います。

では、最初に自己紹介をお願いいたします。村田さんからお願いできますでしょうか。

村田祐介氏（以下、村田）：村田と申します。よろしくお願いします。インキュベイトファンドというベンチャーキャピタルをやっています。ファンドサイズがこれまでの8年間で累計300億ちょっと運用してまして、150社程度の投資先があります。

投資の方針は、すでに存在するスタートアップを見つけてきてデューデリして投資するということは一切やらずに、全部ゼロから、起業しそうな人を見つけてきて一緒に立ち上げるというスタイルで投資活動をしています。

私自身、このベンチャーキャピタリストをやり始めて15年ぐらいなんですけれども。その前は、SaaSのスタートアップをやっておりました。自分自身はずっとコードしか書かないということをずっとひたすらやり続けたので、大失敗をしました。その会社をわずか3年ぐらいで潰してしまうと。

その後もう1回旗揚げしようと思って「もうコードは書かない」というふうに決めてベンチャーキャピタリストになってみたら、15年やっている、というのが私のキャリアになります。

畑：村田さんは去年、『Forbes』の日本で最も影響力のあるベンチャー投資家ベスト10の1位になりましたよね。なにか身の回りで変わったことありますか？

村田：あの、友達が増えましたね（笑）。

畑：（笑）。Facebookで？

村田：そうですね。

East Venturesの衛藤バタラ氏が登壇

畑：ありがとうございます。では次、衛藤さんというとちょっと違和感が(笑)。バタラさん、自己紹介をお願いいたします。

衛藤バタラ氏（以下、衛藤）：衛藤バタラです。私はEast VenturesというシードステージのVCをやっていまして。今までだいたい300社ぐらいに投資をさせていただいて、半分ぐらいが日本と、インドネシアが40パーセントぐらいですかね。あとは10パーセントぐらいアメリカとか、そのほかの国とかに投資しています。

投資をする前に、2003年から「mixi」というSNSの立ち上げを一緒にやっていまして、2003年から辞めた時の2008年ぐらいまで、取締役CTOを5年間ほどやらせていただきました。

畑：はい、ありがとうございます。では、さっそく本日の内容ですが、まずはエンジニア経営の現状、「エンジニア経営って何なの？」「今どうなの？」のような話や、その強み・留意点について進められればと思います。

ゴールとしては、エンジニア経営でないスタートアップの方がエンジニア経営について考えるきっかけとなる、もしくはすでにエンジニア経営をされているスタートアップの方もエンジニア経営をより強化する気づきになれば、そのようなことを目的としております。

はじめに会場にどういう方がいらっしゃるか確認してみたいと思いますが、今スタートアップに勤めていらっしゃる方は挙手をお願いできますでしょうか？

（会場挙手）

けっこういますね。エンジニア経営の定義自体はこれからしますけど、みなさんご自身の定義でよいので、「うちはエンジニア経営だ」と思う方、さらに手を挙げていただけますか？

（会場挙手）

あ、ちょっと……けっこう減りましたね。というようなオーディエンスの方々かと思います。

エンジニア経営の現状

畑：では、まず最初の「エンジニア経営の現状」というところです。最初にこのトピックに行く前に、エンジニア経営ってどういうものですか？　これはカチっとした定義があるわけではないと思うのですけど、なにか「こういうものだ」というのがあればぜひ。

村田：「こういうもの」というと、なかなかこの定義は難しいんですが、先ほどの僕の投資のスタイルが、創業者を見つけてきて一緒に立ち上げるスタイルでやっています。そのなかで、一緒にやる方のほとんどがコードが書ける人。

そもそも自分でコードを書いてプロダクトを作る人もいれば、コードは書けるけど最終的に任せるってスタイルになる方も含めて、やっぱり自分でプロダクトを作れる人って強いなと。

自分でプロダクトを作れるトップ、もしくは創業メンバーでプロダクトがまずローンチできるというチームがエンジニア経営の入口なんじゃないかなとは思っていて。

村田：やっぱりビジネス系の人間だけで固めると、プロダクトを作るチームができないところが一番最初に陥る罠というか。どういう人を採用していいのかわからないし、この人が優秀なのかどうかも、ビジネス系の人だけだとぜんぜん見極められなかったりするので。

一番最初の1人目もそうですし、5人、10人とチームを作っていく上で、やっぱりトップがプロダクトを物理的にどうやって作るのかをちゃんとわかっているチームこそが、最初からスピード感を持って立ち上げられる会社なんだなと（思ってますね）。

畑：プロダクトを作れる人が創業メンバーもしくはトップにいるところが、エンジニア経営をしているスタートアップと。

村田：その入口という。

畑：入口ですね。わかりました。

エンジニア経営かどうかを見分けるポイント

畑：バタラさんお願いできますか？

衛藤：そうですね、僕もたぶん意見は近くて。なかなかこれは定義が難しくて、そもそもエンジニアってどこからどこまでがエンジニアなのかとか。

畑：エンジニア自体の定義ですね。

衛藤：そうですよね。けっこう難しいなと思います。投資するときにエンジニア経営かどうかという見分けを自分なりにどうやってしていくかというと、そのプロダクトを自社で作るか外注するかというのが1つあります。

自社で開発している会社に優先的に投資するんですが、その中で役員レベルにエンジニアがいるとより良いです。

畑：じゃあ内製化して、役員にそういうエンジニアの人が1人でもいるというところですね。

衛藤：そうです。

畑：もし「外注してる」と言ったら、バタラさんは投資しないですか？

衛藤：というわけではないですけど。

畑：優先的に？

衛藤：傾向としてやはり自社開発するところに。

畑：結果的に？

衛藤：そうですよね。まぁちょっと評価は少し下がるかなという感じ。

畑：なるほど。

村田：最近の本で『UPSTARTS』って本があるじゃないですか。UberとAirbnbの創業秘話みたいな。あれ見ると、両社とも外注からスタートしてるんですよ（笑）。

畑：なるほどなるほど（笑）。

村田：だから、まぁ一概に……。

畑：一概には言えないということですね。

村田：はい。スタートから内製化している必要があるのかないのかというと、原型を作るところまではもしかしたら、というのはあるかもしれないですね。

畑：ありがとうございます。そのエンジニア経営について、今お二人から定義をいただきましたが、現状を知る上で1つ、過去のアンケートというのを参考にしたいと思います。

AWSが、IVSというスタートアップのイベントと一緒に「IVS CTO Night and Day」という、CTOを100名以上集めたイベントを開催しまして）。今日もそこに参加された方が何人かいらっしゃると思いますが、2016年春の開催時にアンケートを取ったものをご紹介したいと思います。

スタートアップCTO100名のアンケートで分かったこと

畑：スタートアップのCTO 100名が集まった時に、「いったいどのような属性のCTOですか？」というのを聞きました。結果がこれですね。

創業CTOがだいたい3割。それ以外があとからジョインしたCTO。それが今のお話で「創業からCTOがいるかどうか？」みたいなところも1つ、つながると思うのですね。

もう1つの質問が、「取締役ですか？」と聞いたんですね。そうすると35パーセントが「はい」で「NO」が65パーセントでした。

この辺りを受けて、そもそも創業CTOが今の日本のスタートアップにおいてこのデータより多い・少ないとか、取締役が多い・少ないというのは、今見た感じではどんな印象ですか？

村田：やっぱりなんか、ビジネス系の人が立ち上げることがいまだに多いというか。かつてのネットバブルの時もやっぱりビジネス系の方がやることが多くて。スタートアップというよりも、受託を中心にやりながら「自社プロダクト」を作るみたいな会社が当時たくさんありました。

今だったら自分のプロダクトしか作っていないスタートアップがほとんどだと思うのですが、それも外注とかしながらやってたところが多かったと思いますし、昔から日本って創業メンバーがビジネス系の方で多く構成されていることがとても多いんじゃないかなと思ってます。

やっぱり自分が作れるというか、こういう自己表現だとか、「こういうプロダクト、イケてるだろ？」というふうに言いたくて作るところからスタートするのが、本来の原点じゃないかなという気はしちゃうんですよね。

畑：なるほど。バタラさん、今、このデータをご覧になって思うところありますか？

衛藤：たぶんビジネスのコアのところってどこかというのもあると思うんですが、例えばすべてが技術で勝負しようと思ってたら、これは少ないなという感じはしますね。

なので、スタートアップとかももちろんいろいろ、営業系が強いとかマーケティングが強いとかというのももちろんITスタートアップであるので、それによるかなと思いますね。

CTOの半分以上が生株を持っていない

畑：なるほど。これは2016年春のデータなのですが、そこからほぼ2年が経っていますので、例えばこの2年で変わってきてるなとか、そういう実感ありますか？

衛藤：そうですね。最近だとY Comとかの影響があったりして、けっこう増えてるような気がします。

畑：なるほど。ありがとうございます。もう1つアンケートをご紹介すると、けっこう突っ込んだ質問をして、「そもそも自社株をどれぐらい持っていますか？」を聞いたことがあります。

その結果がこういうかたちで、下のSOはStock Optionですね。あり・なしというところで。なし・ありも含めると生株を持っていない方が半分以上というのが、2016年春に参加されたスタートアップCTO100人のアンケートなんですけど、これについていかがですか？

村田：半分が生株を持ってないってちょっとすごいですよね。ストックオプションすら持っていない方が21パーセント。これ、CTOですよね？

畑：はい。CTOです。

村田：ちょっと信じられないかな（笑）。やっぱりどうしてもこれはネット系のエンジニア人材だけにとどまらないんですけど、とくにエンジニアの方って、資本政策、エクイティに関するリテラシーが低すぎるなという感覚があって。

本来、給与水準だけじゃなくて、どれぐらいのエクイティインセンティブがどういう意味合いを持つのか。今のこの時点でどれぐらいの価値があって、将来どれぐらいの価値になる期待値を持つのかであったり、それが生株だった場合に自分自身がどういう影響力を行使できるのかというところをやっぱり細かく知る必要があって。

その上で、じゃあ我々のような投資家から資金調達をしたときに、その持っているエクイティの意味合いがどう変わっていくのかというのが肌身で感じられる人。

やっぱり経験を持った人は、当然、じゃあ例えば自分がSOを少しでも持っている会社が上場したりすれば、それが一気にキャッシュ化された瞬間に、「次、スタートアップにジョインするときは、ここを意識しよう」という。

シリアルな方ほどそこを強く意識して次のキャリアを選ばれる方も多いんですけれども、これをそもそもインプットして当たり前だと思って、スタートアップに飛び込んでほしいです。

エンジニア人材は資本政策の知識が足りない

村田：ビジネス系の人はやたら詳しすぎて、変に「何パーセントよこせ」みたいなことを言ってくる人が多いので、正直扱いづらいことが多いんですけど、逆にエンジニア人材は、CTOに限らずそこを要求してこなくて。

畑：もっとした方が？

村田：例えば、今の給料が1,000万ほしいとか1,500万ほしいってことばっかり追求される方が多いので、非常にもったいないなという。

畑：そうすると、それはそもそも経営陣にエンジニアがいないという話と、いたとしても、例えばそこまでいわゆるビジネス系の人みたいなアグレッシブさがないという両面なのですかね？

村田：アグレッシブさがどうこうというよりも、そもそも知らない。なので、ストックオプション渡すときも、新株予約権の契約書にサインするときに、「ここにサインすればいいんですよね？」みたいにろくに中身を読まずに書く人がすごく多いし。

僕がそれこそ出資先の対象社員を集めて、ストックオプションってこういう意味だと、資本政策のまず入口から説明するようなことをずっとやり続けてるんですが、やっぱり、昔からそこはあんまり変わらないですね。

畑：先ほどシリアルの方が出てきたらみたいな話もありましたが。また徐々にそういう成功するエンジニアが出てという循環のようなことも、そのロールモデルがなかなか少ないような理由にはあるのですかね？

村田：その持っているエクイティインセンティブが、上場なのかM&Aのイグジットイベントがあったときに、実際キャッシュに変わったのを目の前で見たことがある人がやっぱり少なすぎるのはあるんじゃないかなと思ってて。

それが目の前にいる人、もともと同僚だった人とかがそれを手にした瞬間に一気にそのイメージが湧くようになるというのはあるかもしれないですね。

畑：なるほど。ありがとうございます。バタラさんもなにかこの辺りコメントありますか？

衛藤：そうですね、さっきの質問だと多いか少ないかということだと思うんですけど、VCから言わせてもらうと、多いか少ないかというのは結局たぶんその人がなにをするかとかにもよると思うんですよね。例えば、技術で差をつけようという会社だったら「少ないかな」という感じがします。

畑：なるほど。そこは先ほどの、その会社がなにをコアにして、それをどういうふうに目指すか、というところですね。

衛藤：はい。そうですね。

畑：ありがとうございます。

エンジニア経営の強み

畑：ここまでで、今のエンジニア経営がどういうものかと現状をみなさんとシェアできたかなと思います。次に、エンジニア経営」にはどんな良いことがあるのかに移りたいと思います。

お二人にここで登壇いただいているのも、その辺りの思いというか、エンジニア経営の強みだったりメリットがあるからと思われてご登壇いただいたところもあると思います。

例えば、それは意思決定なのか、顧客に対してなのか、プロダクトに対してなのか、組織・チーム（に対してなのか）。採用も含めてですね。あと、営業・マーケティング、オペレーション。競合対策等々もいろいろあると思うのですが。

どの順番でもよいので、できればなにか投資先の事例だったり、あとはひょっとしたらバタラさんのmixiでの経験だったり、実例を交えて「こういうところが強みじゃないか」というところを、ぜひご紹介いただけたらと思います。

村田：エンジニア経営の強みというか、会社の立ち上げから支援してる立場の経験からすると、やっぱりトップマネジメントがコードを書けるかどうかで、圧倒的にそのプロダクトのローンチまでの時間軸が短いです。

畑：スピードが速いと？

村田：スピードが明らかに速いということがあって。一緒に創業からやろうといって、スタート用意ドンからプロダクトのローンチまでもそうですし、あとはチームづくりですよね。

先ほどもちらっと出ましたけど、エンジニアがエンジニアを採用できるというところのスピード感とかを含めて、チームがしっかり作れて、プロダクトのローンチまでの時間軸も短くて。

また、ローンチしてからユーザーからの声を聞く瞬間までがすごく短くて、次のプロダクトの反映までものすごい短い時間軸で作れて。そこでトラクションがすぐ生めるから次の資金調達も早いというのが実際多いかなと。

逆にエンジニアが創業チームにいなかったりすると、特定のエンジニアに負荷がかかりすぎて、ローンチ前にいなくなっちゃったりとか、蓋を開けてみたらからっぽでしたみたいなことが、やっぱりどうしても起こったりしてしまう。そういうところはまず入口としてあるかなと。

創業からわずか3か月弱でサービスをローンチ

畑：そのエンジニアが経営陣にいることと速さというのは、コミュニケーションだったりプロセスとか、どのあたりから生み出されるものなのですか？

村田：僕の場合、創業直前か直後に「これを作ろう」というのを決めて、プロダクトの設計を創業者と2人でもうひたすらリーンにやって、途中で2人目3人目のエンジニアを雇いながら一気に立ち上げていくというスタイルでやることが非常に多いです。

去年上場したGameWithの創業期も、社長の今泉さんがエンジニアとしてもとても優秀で、会社を立ち上げてからローンチまで3ヶ月弱ぐらいでした。非常に速かったなと。

そこから3ヶ月ぐらいでトラフィックが一気に積み上がり、Monthly Active Userが100万人に到達してしまったというのもあって、そのまま資金調達しました。会社を創業してから丸半年ぐらいでシリーズAが出来てしまったんですけど、もうあっという間にそこまで到達できたのは非常に大きかった。

畑：自分の思いやフィードバックを受けて、すぐプロダクトに反映させていくというスピードですね。もしそれが経営者がそうでなかったとしたら、部下に指示を出してとか外注したりとかいうところで、どうしても後手後手に回って遅くなってたんじゃないか、というところですね。

村田：今泉さんとは、GameWith創業前に一緒にゲーム会社を立ち上げてCTOをやってたこともあって、1人でプロダクトを作れる人だと知っていました。今泉さんと僕とのコミュニケーションだけで「これをああしよう」という意思決定がすぐにできて。

余計な伝言ゲームみたいなかたちには当然ならずに、もうすぐに「明日反映します」みたいなスピード感でやれたのは大きかったと思います。トラフィックでいったら1,000万人ぐらいのアクティブユーザーまでは、ほとんど社長1人で作っちゃったというのはすごくすばらしいスピード感だなと思います。

一番早く差をつけられるのはエンジニアリング力

畑：ありがとうございます。バタラさん、なにか強みの事例をお願いします。

衛藤：強みはもちろんその会社次第なんですけど、ほかの会社とどうやって差をつけていくかが大事かなと思います。例えば、営業が強いからうちの会社が一番なんですよとか、マーケティングが強いからという会社もあり、いろいろだと思うんですが。

営業がめちゃめちゃ伸びるような会社を探してるVCだったら、たぶんエンジニアじゃなくてその営業が強いところを探せばいいんです。

ただし、うちが300社ぐらいやってきて、一番早く差をつけられるのがなにかというと、とくに今のステージだと、やっぱりエンジニアリング力なんですよね。なので、そこって一番の強みだと思います。

畑：それはやはり、村田さんがおっしゃってたスピードだったりとかその辺なんですか？　強みになるのは。

衛藤：そうですね。実際になにを作っていくかがわかるというのが。

畑：カタチにしていくというか、そこができるというところですね。

衛藤：はい。

畑：なるほどなるほど。他、今のお話し以外のなにか強みや実例とかありますかね？

村田：でも意思決定もそうですよね。なににコストを使うのかとか、創業チームにエンジニアに強い人間が入ってたりすると、そこに人がどんどん紐付いていくわけで、どうやったら優秀なチームづくりができるかというところに、わりと的外れのようなものじゃなくて、適切に投資判断ができますし。

それこそ「AWSを使うべきなのか、それともGCP使うべきなのか？」というところも、早い段階からそのコストの考え方だったりとか、まぁ諸々の意思決定が速いですよね。

ビジネス系の方が考える1人月いくらみたいな発想とか、外に発注しようって発想だけだとうまくいかないことが多いですが、このプロダクトを作る上でそもそもどれぐらいの時間軸がかかるんだっけというところが、さっさとその仮説が作れるので速いというところはあるんじゃないかなと思います。

畑：実際にエンジニアの方が創業メンバーにいるのがベストだと思うのですけど、必ずしもそうじゃない場合、ただそれでも非エンジニアの方がエンジニア経営を目指す最初の一歩だったりとか、そういう例もあるのかなと思うのですが、いかがでしょうか？

「コードが書けないお前が起業なんかできるか」

畑：今、非エンジニアの方がエンジニア経営を目指してエンジニアに歩み寄るとか、なにかそういうのありますか？

村田：そうですね。WealthNaviという出資先があって、これが会社を創業して2年半ぐらいなんですが、そこの柴山さんはもともと財務省（出身）。

畑：はい。

村田：財務省ご出身の方で、財務省・金融庁に行ったあとに、UKの財務省に行って、そのあとマッキンゼーでUSの東海岸の金融機関向けにリスクマネジメントの設計をしてました、みたいな人だったんですけど。

畑：エンジニアじゃないんですね。

村田：エンジニアじゃない人ですね。エンジニアじゃないけど、法律つくる人みたいな感じだった人が、急にスタートアップをやりたいと。今ではロボットアドバイザーというサービスが一般認知され始めていますが、当時アセットマネジメント業界が、もう少しコンピュータサイエンスで最適化されていくというか。

そういう考え方を持っているなかで、マッキンゼーの当時の上司に「会社を起業する」と相談した時に、「コードが書けないお前が起業なんかできるか」と言われたらしくて、CodeCampに通って。

一番最初のMVP（Minimum Viable Product）は、柴山さん1人で作った。3週間というすごい速いスピードで彼が作ったという。もともと天才なんでしょうね。頭のつくりがちょっと違うなという感覚はありますが、まぁ速く作って。それで1人目の社員の採用も、一緒にやってたんですが、CTO人材をを見つけてきて。

やっぱりMVPレベルでも自分で作った経験があるのは大きいと思います。金融機関、アセットマネジメント会社の仕組みを全部クラウド上で完結する前提でどうやったら作れるか。

それを金融庁のレギュレーションにどう適用かというところを踏まえて、ひたすら柴山さん自身が設計しながら、一番最初の第1号社員をCTO人材として選定できて、一気にスピードがそこから上がっていったという事例です。

ロボットアドバイザーNo.1のポジションを獲得

村田：ただ財務省の仕事だけををやってた方だと、なかなかこんなことにはなってないと思います。プロダクトローンチしてからまだ1年半ぐらいで、あっという間に運用資産の総額が600億円を超えるような規模感になって、現時点でロボットアドバイザーのNo.1ポジションとなっているわけですから。

まぁNo.1もなにも、最初からマーケットがなかったところに一気にそのポジションまで作りきれたのは、やっぱり最初にプロダクトが作れるチームづくりをするために、自分自身がプロダクトを作れる人材になろうとしたのは良いスタートだったのではないかと思います）。

畑：そうすると仮に今、創業者がエンジニアじゃなくても、エンジニア経営を目指すために自ら歩み寄って、たぶんその結果、実際自分で少しでもコードを書いてみれば、エンジニアの気持ちもわかるしとか。エンジニアが言ってることも、100はわからなくても0じゃないみたいな、たぶん違うとか、なにかそういうのがあるのですかね。

あとは採用のときも「この人すごいな」みたいなのも、まったく知らない人に比べたら多分わかるとか、そういうところに繋がっているということですかね。

村田：そうですね。じゃあみんなCodeCampに通えば、そのプロダクトを非エンジニアがものすごくイケてるマネジメントができるようになるかといったら、そう簡単では当然ないんですよね。

とくに今、最近のスタートアップの潮流というか、これから新しくスタートアップを立ち上げる方って、わりと専門性の高い領域で立ち上げる方が多くなってきてるんじゃないかって。「〇〇業界にインターネットを接続したらこうなる」みたいな。「xTech」とかって言う人もいますけど。

そういう人たちからすれば、誰もやったことのないプロダクトを創造しながらやっていく分、その作れた頭を持ちながら、その業界の構造と、もともと回ってる仕組みがどういう仕組みなのかというロジックがわかっていれば、わりと作るまでにそんなに時間を要さない気もしますよね。

畑：確かにそうですね。

経営者は技術をどこまで理解すべきか

畑：バタラさんお願いします。

衛藤：質問はたぶん「どのぐらい自分がわかればいいんだ？」ということですよね？

畑：そうですね。

衛藤：自分がわからない場合って、たぶんいろいろあると思うんですが、ブートキャンプ行ったり、あるいはわかる役員を雇ったりというのがあると思うんです。だけど、言いたいのはたぶんそれじゃなくて。

例えば社長って、エンジニアだけ特別にしてるように聞こえるんですが、そうじゃなくて。例えば経営がわからない。決算書を見てわからないと意味がないというか。だからある程度知識がないと、なかなか経営自体が難しいんですよね。

なので、この作りたいもののエンジニアリング力が100あるとしたら、別に自分が80までいかなくても、10パーセント、20パーセントが見てわかるぐらいとかにしたほうがバランスはいいですよね。

たぶん同じことも言えると思うんですけど、例えばまったく法律のことがわからないから契約書とか全部わからなくていいかというと、そうでもないと思うんですよね。税理士に関しても同じことが言えてて。そういう立ち位置かなと思います。

畑：それは先ほどのスタートアップがどういうプロダクトサービスを提供するか、それが技術によりどれぐらい振れてるかによっても多分違って。ただ、そこは0パーセントじゃないということですよね。

衛藤：そうです。

畑：では、これからディープラーニング、マシンラーニングをコアにしてやっていこうという方が技術の理解が10パーセントとかだと、たぶんきついとかっていうことですかね。

衛藤：そうですね。たぶんそのバランスが良くなると結果も良くなるんじゃないですかね。全体的に先を通して見れるので。

畑：なるほどなるほど。あと、よくスタートアップのCEOの非エンジニアの方とかから、やはり「自分はコードを書いたことがない」とか「自分はエンジニアじゃないから」というところで、けっこうブロックしちゃってたり、ちょっと言い方あれですけど、思考停止に陥っちゃってる場合もあるように思いますが、

多分知ることで、もちろん自分でコードを書いてプロダクトを作るわけじゃないにしても、最低限、なにかエンジニアが判断した時に「それはなんなの？」みたいなことを聞くところのハードルが下がるという効果はあるのかなと思いますよね。

衛藤：そうですね。

エンジニア経営の留意点

村田：我々の出資先の非エンジニアの社長には、どういう感じでプロダクトを作っていくのかを、ひと通り説明したりします。最初に仮説を作って、それを基本設計していって、どういうオペレーションでそのプロダクトを作っていくのかという。

なので、例えば、僕が関わってきたこのA社ではこうだった、B社ではこうだったとか、作ったことのある人、わりとプロダクトがローンチして間もない人を連れてきて、どういうふうに非エンジニア社長がこのプロダクトを作るまでにいたったのかを横でつなげてあげたりとかすると、とてもわかりやすかったりもするので。

どうやって意思決定をしていくのか。進行が1～10まであるうちの今どこに位置しているのか。これからどれぐらいのコストがかかりそうかとか。ローンチしたあと、どうやってその次の開発にどう繋げて意思決定をしていくのかなど。

1回やったことがある人が語るととてもわかりやすいですし、僕らのような投資家であれば実体験を語れる人をたくさん紹介もできるでしょうし、その知り合いの人がたぶん周りにたくさんいるでしょうから。それこそAmazonの方にいろいろなエピソードを聞きに行くということもあるでしょうし、いっぱい聞くといいですよね。

畑：なるほど。ありがとうございます。ここまで、エンジニア経営の強みの話でした。非エンジニアだったりエンジニア経営じゃない方向けに「やっぱり経営陣、エンジニアがいたほうがいいですよ」とか「非エンジニアの方はもっとエンジニアに歩み寄ったほうがいいですよ」的なメッセージだったと思いますが、次はエンジニア経営の留意点についてお話しいただけたらと思います。

エンジニア中心、本当にエンジニアばかりの会社が恐らく陥ってるようなことや、気をつけなければいけないこともあると思いますので、その辺りで、今までのご経験とかお聞きの話とかも含めてなにかあればご紹介いただければと思います。

プロダクトのローンチ後はビジネス系の発想が必要

村田：プロダクトのローンチまではわりとエンジニア主導かなとは思うんですけど、プロダクトをローンチしたあとは変わってくるかなと思います。

これは僕らが投資家とつきあうためにやってるのもそうですし、toBの顧客と向き合ってプロダクトをさらに進化させていく過程のなかで、KPIの設定みたいなところ。

やっぱりプロダクトが動いて、ユーザーが出てきて、それでじゃあGA上で、MAUがこうで、それでPVがこれだけあって。じゃあメディア系の会社であれば、IMPに対してRPMがこれぐらい出てて、いくらぐらいの売上になりましたとかという話だけじゃ当然なくてですね。

これはビジネス系の人が考える発想じゃないですか。それこそ流行り言葉になっていますけど、ユニットエコノミクスってどうやったら成り立つのかって、たぶんそのプロダクトを作ってるだけじゃわからないところだと思うんですよね。

どこの数字をどうやって上げていけばアクイジションコストがLTV（Life Time Value）よりも安くなる構造が作れるのかという発想って、対投資家向けにもそうですし、よりプロダクトのスケーラビリティを上げていくために絶対に必要な議論だと思うので。

プロダクトを作って、そのグロースハックをする仮説設計をするときに、わりとそのフラグが立ったらどういう顧客が獲得できるようになるのかとか、その質と量がどうやって変化させられるのか、そのために資金調達がどうやったらできるのか。

資金調達をしたあとに、さらに大きな組織をつくるための資金調達を達成させるために、どういうフラグが立たせられるようにするか。単純にプロダクトのMAUが100万いったのでどうこうみたいな話ではなくて。

そういう設計をするのは、たぶんエンジニア視点以外の視点が必要になってくるのかなと思っています。

エンジニア気質のデメリット

畑：そのエンジニア視点が強すぎたり、ほぼ経営陣がエンジニアだった場合に、投資家から見たときに、歯がゆさだったり、なんか「もうちょっとこういうこと考えてくれたらな」みたいなそういうケースってありましたか？　強すぎるみたいな。

村田：そうですね。まだスケールしてないプロダクトなのでまだまだこれからなんですけど、出資先で「SideCI」というプロダクトを作っているチームでの話なのですが。今日もこの会場に来てるかもしれないですけど、CIツールを作っている会社、コードレビューの自動化みたいなことをやっているスタートアップがあって。

今ようやくそのユーザー数がグローバルで3,500社作れて、よりスケールしていっているんですが、社長の角さんがもう完全にエンジニア気質の人で。最初はもうこの2人でプロダクトを一緒に仮説から作ってたんですけど、資金調達の際に角さんが「エンジニアでない投資家はこのプロダクトのことを理解できないんですよね」と言って半ば諦め気味なシーンがかつてありました。

村田：いくら説明してもエンジニア向けのCIって言われてもまったくピンとこないどころか、そもそもエンジニア用語を使って説明してしまうがゆえに「エンジニアならわかるんですけど……」みたいなことを卑屈なように語ってしまうことがあるので、「絶対それはやめろ」みたいな。

村田：ちゃんと数字で語って、なんのマイルストーンを達成してきたのかを語る必要がある。マーケットの仮説も語る必要がある。エンジニア気質すぎて技術寄りすぎると、やっぱりプロダクトアウトすぎる発想になる方が多くて。もう少しマーケットインな発想を取り入れていく必要がある。

相対的に自分たちのプロダクトがどういう位置で、どういうふうにグロースさせるかというシナリオを、プロダクトを作るという発想だけじゃなくて、KPIを語りながら、どういう経営をするんだと語ってほしいです。

非エンジニアにもわかる説明の大切さ

畑：技術に特化だけではなくて、投資家に話すのであれば、投資家の目線に合わせた説明の仕方があるし、プロダクトを出すときもマーケットを見てというところとのバランスが必要ということですね。

村田：なので、もうひたすらデック作る、さんざんもう何十回やりとりをしたか覚えてないぐらいの（笑）。ひたすらエンジニアの言葉、エンジニアの発想だけで語っていたデックがあったので、あの……。

畑：それではわからないと。

村田：「ぜんぜんわからん」みたいな話だったので、全部が非エンジニアにわかるような数字の戦略みたいなところに落としていく作業をしていって、去年シリーズAで2億ぐらい調達できたんですけど、大変でしたよね。やっぱり説明し切れないという。

畑：はい。バタラさん、留意点、陥りがちなことを教えてください。

衛藤：プロダクト開発とかでよく見られるのは、プロダクトは使われるかかどうかよりも、自分がその技術を使いたいがためにそのプロダクトを作ったりすることです。

畑：エンジニアの方が陥りがちなことですね。

衛藤：はい、そうですね。そういうのはけっこうありますね。

畑：技術選択のときに、自分が使ってみたいとか、ちょっと新しいとか、好みみたいなとか、そういうことですよね。

衛藤：はい。

畑：仮に非エンジニアの方が経営陣にいたときに、どういうかたち……もちろんもともとの話は、経営陣の中にエンジニア経営者もしくはCTOを入れるべきかと思いますが、そうでなかった場合、経営に対して必要な余地を、非エンジニアの方とかはどうしていけばいいのか。

衛藤：そうですね。問題としては、エンジニアリング力が高すぎるというよりもプロダクト力が低いからだと思うんですよ。

畑：なるほど。逆に。

衛藤：なので、別にエンジニアが必ずそれができないかというと、たぶんそうでもないと思うんですよね。ただし、傾向としてはあるとは思うんです。バランスで見ると、やっぱりエンジニアリング力が高くなると、ほかはちょっと下がっていく傾向があるんだと思うんですけど。

となると、非エンジニアの人が中にいると、結局その人はエンジニアリング力がそんなに高くないので、普通にバランス的には、ほかに高いところがあると思うんですよね。そうするとたぶん違う意見を出してくれるようにはなるかなと思いますね。

なんか全員エンジニアだとみんな同じ視点から見てて、「いや、これおもしろいからやろうよ」という傾向になりがちだなと思っています。

mixi立ち上げのときの体制づくり

村田：それってmixiの時に笠原さんとどういうふうに？

畑：（笑）。

衛藤：笠原はどちらかと言うとビジネス目線から見てますね。 畑：笠原さんは、コードを見られてたのですか？　

衛藤：とくにないですね。

畑：全く無かったのですね

衛藤：はい。

村田：それで、その技術中心のバタラさん。そもそもmixiという仕組み自体を作ろうと言い出して作っていたのはバタラさんで、それこそどうやって社長を巻き込むかとか、チームづくりのリソースの配分とかも社長とCTOでまた違ったりするじゃないですか。どうやってそれを？

衛藤：確かに作る前に笠原にそれを持っていって説明して、「こういうの海外ではやっているので、やりたいんですよね」と説明したら「やりましょう」という感じだったんですね。

村田：ローンチまではたぶんそうだと思うんですけど。もうプロダクトができたところから社名変更にいたるまでのところって、一気にグロースしまくってる最中の時に、がんがん人を採りにいったりとかもしていったはずだし。

その当時はAWSもまだちゃんと日本では稼働していない時期だと思うんですけど、技術選定を含めて、リードしていくなかでどうやって、それこそ権限をどこまで自分に移譲してもらうとか、予算の配分だったりとか、どこまでCTOである自分がやってたんですか？

衛藤：そうですね。まず技術をどうすればいいかというところからいうと、当時mixiって一時期、日本国内のトラフィックは3位ぐらいだったんですよ。Yahoo!、Google、mixi。しかも純国産だと1位になっちゃうので、まずは相談相手がまったくいないです。

開発者に熱意を持ってもらう大切さ

衛藤：トラフィックが増えていった時に、周りに相談したりとか、例えばはてなと勉強会してたりしました。さらにトラフックが増加すると、ネットで公開されている資料を見てたりして、それで判断してたんですね。

村田：それじゃあチームづくりとかは自分ががんがん採用しにいくとか、どんどん投資を、お金を使いにいくみたいな発想というよりも、先陣を切って技術資料を読み漁ってプロダクトを作っていくという突撃をバタラさんがしていって、そこに笠原さんがどんどん放り込んでくるような構造だったということですか？

衛藤：そうなんですよね。僕も相当エンジニアだった……なんていうんですかね、経営思考とかあんまりなかったので、逆に「そんな人を雇ってこれやっていけんのかな？」という感じがしたんですよ。

村田：でも、それってすごくいいバランスだったから、ちゃんと成長していけたし、変なクラッシュもせずに、国内最大級のトラフィックを作っていくところまでいったんだとすれば、それはどういうバランスがよかったんですかね？

衛藤：1つ言えるのは、技術というよりもやっぱり熱意だなというのが、これけっこうみんなにも言ってるんですけど。例えばmixiのところとかも、国内で3位ぐらいのトラフィックがあったんですけど、当時、私も含めてたぶんエンジニア全員、「そんなトラフィック見たことがないよ」という感じだったんですよ。

なんでそれを乗り越えられるかというと、考えてみると、みんな相当そのサービスが好きで「これはどうにか乗り越えたいんです」という気持ちが強かったからだと思うんですね。それはやっぱり開発者とかにどうやってそういう気持ちにさせるのかがけっこう大事だと思います。

畑：なるほど。その辺のビジョンなどやりたいことみたいなところですかね。

衛藤：それとモチベーションです。例えば先ほどのストックオプションとか、役員にするかしないかとか、そういうところですね。

経営者はコードが書けなくてもコンプレックスを持つ必要はない

畑：なるほど。実は時間があっという間に経ってしまいました。最後、二言お願いしたいのですが。まず最初に非エンジニアの方に向けて今日の振り返り的なところをお願いし、最後にエンジニアの方に向けてというかたちでお願いできたらと思います。まず非エンジニアの方に向けて、（お二人の）どちらからでも。

村田：そうですね。非エンジニアの方は、コード書けるようになられるのが早いんじゃないかなと思うのはあるんですけど。

畑：少しでも？

村田：そうですね。うまく役割分担を……。チームづくりだと、非エンジニアの方も経営陣の方もいれば、そうじゃない方もいらっしゃると思うんですけど、さっきちょっと裏で話したところでいくと、エンジニア経営者やCTOって、めちゃくちゃコードがかける人っていうんじゃなくて、コードが一番わかる経営者みたいなところがあるんだと思うので。

だからコードを書けないからといって、そこに変なコンプレックスを持つ必要は当然なくて。どうやったらそのエンジニアたちのチームが作れるのかもそうですし、よりモチベーションが高いチームを作るためにはどうしたらいいかというところを、別の視点で考えられるんだと思うんですよね。

どうやったらリソースを補給できるのかもそうですし。要はおもしろい案件を持ってくるみたいな、おもしろいPoC（Proof of Concept）を持ってきて「これってここまでいっちゃうんじゃないか」みたいな仮説レベルで話をあげて、あと作るところはもうひたすら任せるみたいなところってできるはずだし。

非エンジニアはプロダクトに口出ししないほうがいい

村田：あとは、非エンジニアの方はプロダクトにあんまり口出ししないでほしいなというのはあります。僕らみたいな投資家とかでも、なんかちょっと趣味が入って、「いや、ここは角丸のほうがいいんじゃないか？」とか「ボタンはこういう挙動がいいんじゃないか？」とか、「こうしたほうがCVR上がるんじゃないか？」ってみんな好き勝手言う人がいたりするなかで、間違った意思決定をしてしまうことがままあります。

なんの背景も知らずに間違ったことを言ってしまいがち。一方でプロダクトをどうやってグロースさせていくかという仮説は、当然エンジニアもちゃんと語らなきゃいけない。

やっぱり、なんのためにこの仕組があるのかを相互理解するためのお互いのプロトコル設計みたいなことはしておいたほうがいいんだろうなとは思います。

お互いにお互いを知ろうと思ったり、お互いをどうやったらエンパワーメントできるのかを考えていくのがいいんじゃないかなと。

畑：ありがとうございます。ではバタラさん、非エンジニアに向けてお願いします。

衛藤：先ほども話してたんですけど、別にエンジニアって、そんなにすごい特別な技術というか特別なものとかではなくて、決算書が見れるよという程度だと思うんですよ。

なので、土台がネットのITで、しかも技術で差をつけようとしたら、当たり前のことだと思うんですけど、100までじゃなくても、やっぱりそこはある程度バランスよくしたほうがいいとは思いますね。そのバランスをよくするというのは、ある程度技術のこともわかってたほうがいいと思います。

エンジニアこそ、起業をするべき

畑：ありがとうございます。では最後、本当の最後、エンジニアの方に向けてお願いします。

村田：創業ステージから応援してる人間からすれば、みんなやっぱりコードを書ける人がスタートアップを起こすと速い。立ち上がりがとにかく速いというのがあって。

僕が自分で起業した18、19年前とかは、そんな1人のエンジニアがプロダクトをローンチするまで1人みたいなことなんて絶対にありえなかったし、自分の手元の資金だけで立ち上げることなんて絶対ありえなかった。

それが今では、それこそAWSさんみたいな仕組みを使うことで、さっさとプロダクトをローンチできてユーザーの声が聞けるところまで行けるわけなので、サイドプロジェクトでもなんでもかまわないので、まずはプロダクトを作ってみるということを。

この場の経営者の方はそうかもしれないですけど、経営者じゃない方は自分でスタートアップを起こす入口からトライしてみることはぜひやっていただきたいですし、その際はぜひお声がけいただきたいなという。そういう方にはいつでも相談に乗りたいなと思っているので。

畑：「エンジニア、起業せよ！」ということですかね。

村田：はい。

畑：はい。バタラさん、最後の一言をお願いします。

衛藤：同じく、エンジニアの方はもっと起業してほしいですね。

畑：ありがとうございます。今日のお二人のお話にあったとおり、エンジニア経営というもの、エンジニアが経営に参画するというのがますます重要になってきてますし、

先ほど2016年のデータは、たぶんまたこの2年経つと徐々に変わってくるかと思いますし、アメリカを見ても、エンジニアがいないようなスタートアップってなかなかないとか、いろんな状況があると思います。

ぜひ今日のお話をベースに、非エンジニアの方はエンジニア経営に寄り添うとか歩み寄って、うまくバランスを取る、エンジニアの方も、先ほどのファイナンスリテラシーの話など、色々なバランスを取って頂けたらと思います。 あと一番大きなメッセージは、「エンジニアの方こそ起業していただきたい！」というところかとと思いますので、そういう形で最後の言葉とさせていただけたらと思います。

それではお時間となりましたので、これで本日のセッションを終わりたいと思います。最後にご登壇いただいたお2人に盛大な拍手をお願いできればと思います。ありがとうございました。

（会場拍手）

Occurred on , Published at