Kamilas4am堀真輔さんの自己紹介
BOOTUP RADIO、エンジェル投資家の橋田一秀です。 BOOTUP RADIOは、スタートアップを立ち上げる上での疑問や企業に関するトピックを取り上げ、
SEED企業家や企業家予備群に役立つ情報をお届けする番組です。 本日のゲストは3回目の登場になります、Kamilas4am堀真です。
はい、今回もよろしくお願いします。こんにちは。 よろしくお願いします。
はい、ということで、ちょっと軽く、初めて聞く人もいると思うので、軽く何やってるか自己紹介お願いします。
はい、Kamilas4amのハリーこと堀です。よろしくお願いします。
我々は、Day1からグローバルでフィリピン中心にスタートしてるんですけれども、コンテンツのスタートアップです。
具体的には、フードデリバリーをオーダーするような形で、ビジネスオーナーがコンテンツ、ショート動画をオーダーするできるプラットフォームがありまして、
特徴としては、クリエイターの人たちはインフルエンサーでもないような、本当にフォロワーがゼロの人でもクリエイターになれるというところが、僕らの一つのプラットフォームの特徴で、そういったプラットフォームをフィリピン中心に展開をしております。
はい、ありがとうございます。ということで、立て続けに堀さんに出ていただいてるんですが、毎回堀さんと喋るとすごい盛り上がるんで、話しやすいなと思って、何回も出てもらっています。
ということで、前回予告した堀さんからの質問回なんですが、ちょっと今読み上げますね。
エンジニアに関することだったりするんですけど、エンジニアサラリーに関して、現在インハウスのエンジニアいないので、プロダクトは基本的に外注で作ってます。
PMF前なので、極力バーンを抑えつつ、小さな機能追加はせずに、しばらくは保守、運用、費用だけで数ヶ月様子を見ようと思ってます。その場合の一般的な相場はいくらくらいでしょうか。
続いて、また上記と繋がりますが、PMF前の開発について何か注意すべきアドバイス、例えばMVPに時間をかけすぎない、などあれば教えてください。
という内容なんですが、これはもう本人に聞いてしまおうと思ってるんですが、今ってチームにはCTOがいるっていう認識なんですけど、どういう状況なんでしたっけ。
はい、ちょっと特殊かもしれないですけど、一応コファウンダー3人でありまして、1人がCTOです。彼は一応ハーフコミットくらいの形で入ってもらっていて、ただいつもコミュニケーション取れるし、何かあったらいつでも対応できるみたいな感じなので、ほぼフルタイムっぽい感じなんですけど、一応ハーフタイム。
CTOの状況と求められる能力
彼の方で開発会社、もう5、6年くらいですね。彼がフィリピンの方ベースなんですけど、運営していて、なので開発をするってなった時は実際に彼のチームの方に依頼をするっていう形なので、インハウスとアウトソースの間ぐらいっていう感じのイメージ。
なるほど。そうですね、最近そういう選択肢もたまに聞くなーって思ってるんで、今できるベストがそれだったらそれでいいんじゃないかなっていうふうに思うんですけど。
ベストですね。
で、実際にどうすかね、今日の話は、エンジニアのサラリーの相場感。これ難しくて、結構いろんなやり方あるんで。
例えば、一般的なスタートアップの初期メンバーに欲しい人みたいな話で言うと、初期メンバーの人って、これだけできますだと結構、要は平たくインターネットサービスを一人で作れる人みたいなイメージなんですよね。
例えば技術で言うと、インフラから、インフラつっても今AWSとかGoogleクラウドプラットフォームとか使うんで、クラウドの扱いからサーバーサイド、それからフロントエンドまでまんべんなく触れる人みたいな人が理想像ですよね。最初の一人目のエンジニアとしては。
一人で一通りできる。別に何か特化してなくていいんだけど、一旦サービス立ち上げるとこまでいけるみたいな人が理想的ではありますと。そう考えると、なかなか難しくて、やっぱり、そうですね。もちろん全部できる人っていうと、
おだしょー かなりハイスペックになっちゃうんで。
りなたむ かなりハイスペックになっちゃうんで。
おだしょー 重要になってくるって感じですね。
りなたむ そうですね。ただ、もちろん別に、どこが一番重要かっていうと、やっぱりアプリケーションコードかけることっていうのが一番重要で、例えばインフラとかは誰かに手伝ってもらおうかとかでもいいし、結構、これは僕が始めたときとかそうだったんですけど、
10年ぐらい前とかって、今ほどAmazon、AWSとか今ほど普及してなかったし、でもやっぱりスタートアップ始めるなら、そういうAWSとかで簡単に管理できる方がいいよねみたいな話は結構あったんで、っていうところは結構例明記ではあったんですよね、日本においては。
だったんで、割と僕の試合とかはですね、スタートアップお手伝い屋さんみたいなのやってて、フリーランスで週1で5社駆け持ちして、ほとんど全部の会社はインフラからやるみたいな、AWSの設定からやるみたいなところ。
そこって結構かゆいところで、一番大事な能力ってアプリケーションをかけることなんで、インハウスのエンジニアで必要なのって。そうすると、そのインハウスのエンジニアの人がサーバーの面倒見れないとか、AWSあんま詳しくないみたいな話だと、そういうAWS立ち上げ屋さんみたいな人が活躍するみたいな。
それだから言いたいのは、それは今でもそうなんですけど、外部からでも補完できるんで、どのスキル取るって言ったらやっぱりアプリケーションコードを素早くかける能力だと思うんですよね。
これは多分、他のリスナーの方、それこそシード機だったりとか立ち上げる時に結構気になると思うんですけど、じゃあそこのスキルって、我々みたいにエンジニアじゃないファウンダーの場合、見抜けないじゃないですか。そこってどうやって、我々の場合は知人にチェックしてもらったりとか。
我々の場合は友人なので信頼がおけるっていうところで立ち上げたとは思うんですけども、その辺りで橋本さんがアドバイスするとしたらどういうふうに。
そうですね、究極それ今言ってくれたことなんじゃないかなと思っていて、信頼がおけるってことが大事ですと。結局どこまで行ってもスキルは自分の力ではわからないので、これは別に何かエンジニアっていうことだけ、相手がエンジニアだろうが、
ビズサイドだろうが、マーケターだろうが、カスタムサポーターだろうが、自分がやったことない仕事のスキルを見測るって難しいじゃないですか。
そうですね。
デザイナーでもそうですけど。なので、それは一定、仕事一緒にできるっていう信頼関係があることが一番大事ですと。
じゃあ他にスキル的に何見るかっていうと、やっぱコミュニケーションとか説明できる能力なんじゃないかなと思っていて。
結局、自分たちはこういうプロダクトを作りたいですっていう話をするじゃないですか。それを現実に落とし込む人が例えばエンジニアだとすると、
その過程でそのエンジニアの人が、これやろうと思うとこういう問題が起こるけどどうするとか、一緒にそれを考えてくれる。
わかりますね。
もっとこうやった方が、例えばだけどパフォーマンス良くなるよねとか、こういう作ろうと思うとこういう問題想定できるけど、そこどうするとかっていう議論を作り手側と一緒にちゃんとコミュニケーションして議論できることっていうのはすごい大事ですよね。
それはめちゃくちゃわかる。
コミュニケーションちゃんと取れるって意外と大事ですね。
僕らの場合は、これは本当にラッキーだったなと思うんですけど、彼はペリピンの中でも指折りのトップクラスだと僕らは思っていて、実際にコミュニケーションめちゃくちゃ取れるし、信頼も受ける。
なので、開発も自分たち、もともと2人が幹部だったんですけども、こういうの作りたいですっていったときに、いろんな想定されるリスクだったりとかを用意してくれていたり、その小さなピボットってよくあるじゃないですか。
それを想定してバックオフィスの方も仕組み作ってくれてたりとかしていて、なので簡単なピボットをクイックにできるみたいなところとかはめちゃくちゃ助かっていて、コミュニケーション能力めっちゃ大事だなって思いますね。
今の話より深掘りすると、コミュニケーション能力なんですけど、今の話聞いてるとそのエンジニアの方はすごくスタートアップ向きな方なのかなというふうに思っていて、きっと経験も豊富なんだろうと思うんですけど、
要はスタートアップ向きって何かっていうと、今みたいにピボットとかも全然いっぱいあると。すぐ仕様変えたいとかしたいじゃないですか、ユーザーにぶつけながら。なので、やっぱそれを意識して開発するっていうのは、またこれがスタートアップ、特に初期のサービスを作る初期においてすごく大事な能力で、
要は決められたものをカチッと作るというよりかは、ある程度柔軟性を持った上で開発する、余白を持たせて開発するっていう能力って、これまたちょっと特殊なスキルかもしれないですよね。
そうですね。完璧じゃなくてもいいので、程度使えるものをクイックに作ってくれるみたいなのがめちゃくちゃ大事。
そういう、この辺って変える想定あるよねみたいなのを共有できてる。たぶんそれっていちいち細かく指示しなくても、この辺って多分ユーザーの反応を見て変えたいよねとかっていうのを組み取ってくれるみたいなのはすごく大事なスキルかもしれないですよね。
この辺は経験っすねやっぱ。いきなりはできないと思う。
でもその話聞きながらいろいろ思い返しましたけど、そこをちゃんとこっちから伝えるのもめちゃくちゃ大事だなっていう。
もちろん。できるだけそれ頑張ると思うんですけどね。
本当に今ZackっていうCTOなんですけども、そのZackのイベントをする時にも、やっぱりエンジニアの方々の、これはその悪いとかいいとかじゃなくて、パーソナリティとしてちゃんとミスなくバグなくプロダクトを出すっていうのは一つすごく大事じゃないですか。
いやめちゃくちゃ大事なんですよ。やっぱりものを作るってそういうことだと思ってて、適当なものを作っていいとは思ってないですよ。僕も一応エンジニアになったんでありますけど。
適当なものを作っていいとは誰も思ってないんですよ。なんだけど、ことスタートアップにおいてはそういう完璧を求めて作って出すと手戻りが多いから、どっちかっていうと作りながら何が理想的なのかをやっぱり初期段階においてはすごく考えて変えたりするっていうのがすごい大事なんで。
それって普通のものづくりしてるエンジニアからするとちょっと考え方を変えないといけないので。
そうなんですよね。そこのコミュニケーション。
大変かも。
いやもう本当にバグとか全然あっていいからこういうのをクイックにテストしたいみたいなところを、こっちから結構かなり自分たちが思ってる以上に強めにリクエストを出しておくと、彼らも納得してくれる。
なんでかというと彼らとしてはバグがあるものを出してしまうことに対する罪悪感っていうか、こういう気持ちが絶対あるんだなっていうのは自分も一年やりながら、彼らの出すものをリスペクトしながら、勝つでもクイックに動くみたいなところのバランスを生き上げるってすごい大事だなっていうのは経験として学びましたね。
そうね、なんかその辺もこなれてくると、エンジニアの方もきっとこなれてくると、なんかここは落としていいけどここは落としたらダメみたいなところの優先順位とか、そのバーの下げ方とか多分わかってくるんですよね。
ここ落とすとサービス動かなくなるとか、ユーザーに致命的なこういうUXの、最悪のUXを提供してるから、ここは落とせないけど、こっちは落としても大丈夫だから一定、
手を抜くじゃないけど、力の入れどころを変えるみたいなのは、きっと器用なエンジニアだったら慣れてくるとできるのかなって思いますね。
エンジニアの給料相場と依頼方法
そうね、そういうこと、今スタートアップに向いてるエンジニアとか、スタートアップにおけるエンジニアとのコミュニケーションみたいな話をしましたけど、
最初あれなんですよね、質問の最初はサラリーについてなんですけど、これはね、いやマジでむずくて、今って結局じゃあ、なんかそういうエンジニアを求めようとすると、やっぱり好きそうですね。
年報で600万から800万とかっていう人は最低必要になってくるんですよ。これは一般的な日本の相場感で言うと、もちろんなんかいい人をあげればキリがないんですけど、
この辺ってどっちかっていうと、なんか、なんだろうな、どういう人を求めるかによるというか、例えば若くて、もっとスタートアップでチャレンジングなことをしたいエンジニアみたいな人だったら、
新卒3年目から5年目ぐらいの、一通りエンジニア経験ある、一通り回したことあるみたいなエンジニア人だったら、対応できそうな気もするし、一方で初手からやっぱりこう、なんだろう、経験豊富な人を求めていくと、もっともっと金額が上がっちゃうなって感じなんで、
なんか、相場感、いくらの人だったら大丈夫ですっていうのは別になくてですね、正直。
この辺りって、例えば、コファウンダーで最初に入っていただく方だったら、いわゆるエクイティを足して、エクイティセットで、そこの番を抑えるっていう意味でも給料ちょっと低めにみたいなこともあると思うんですけども、
吉田さんだと、その辺りってどういうふうに、創業される前とか、したてのところのスタートアップに対象にしたときにどうアドバイスされます?
今の日本でいうと、端的にまだ、ペナイチの場合は創業メンバーにエンジニアがいたので、それでいうと、エクイティもかなり渡して、やってもらってたっていうところがあるんですよね。
一緒に共同創業者なんで、一緒に創業して、給料も最初、資金調達するまでゼロ円でみたいな、調達した後月35万円みたいな、そんな感じだったんですよ。
つまり、創業メンバーにほとんど、創業メンバーとかそれに近い人であれば、とりあえず、生活できるだけのお金をとりあえず最初、給料として払う、現金として払う。
それ以外はエクイティでっていうのが、本当に創業に近い人だったら可能かもしれないですよね。
一方で、そこまでじゃない人、例えば2人目、3人目のエンジニアみたいな人だと、なかなかエクイティでっていうのはワークしづらいなっていうふうに思っていて。
だから、初期は一定、さらに給料を抑えつつも、それなりにはちゃんと払わないといけないんだろうなっていうふうに最近は思っていますね。
僕が始めたときに比べると、日本での資金調達環境良くなったんで、初手から1000万、2000万、3000万とかって調達できちゃったりするんで、そうすると別にエンジニアに500万の給料をまず払っても、いけるかっていう感じになりますよね、1年っていう意味で言うと。
1000万のうち500万払っちゃうとちょっと大変ですけど、3000万ぐらい調達できてたらエンジニア1人2人そんぐらい払っても、エンジニアリングが大事なサービスであればいいんじゃないと思いますけどね。
自分が質問させてもらったところの背景をちょっと深掘りながら質問させていただきたいんですけども、今、我々って本当にプレシード段階でプロダクトを出して、出した中で結論、いろんな偏りながらそんなに開発をアグレッシブに進めるっていうのはせずに、
今のプロダクトである程度、どちらかとセールスだったりとかに力を入れつつ、オペレーションを変えるところは人で変えながらやっていけばいいと。なので2ヶ月開発は止めようみたいな感じをしていて、そのような段階のときに、いわゆる保守費用的にメンテナンス先やってもらうみたいな場合ですね。
この辺りって、例えば日本でそれを依頼するだったりとかすると、だいたい相場感ってどれくらいになったりするんですか?
なんか、それって外注で業務委託みたいな前提ですよね。
そうですね。
それも結局、工数次第だと思うんですけど、バグが発覚してすぐ直さなきゃいけないみたいなやつは柔軟に対応してほしいっていう感じで言うと、エンジニアに月々一定の額を最低ライン払い続けないといけないんだろう。
例えばですけど、業務委託で外注したときに、一般的な日本の、これ別にCTOとか全く関係なく、普通にアプリケーションかけるエンジニアに発注したときに、だいたい月、これ間に直接いろいろあるんですよ。直接契約するか、SESの会社挟むかとかっていろいろあるんですけど。
レンジとして、例えばそうですね。
第一のときにやってたエンジニアの、求めてるエンジニアのレベルで言うと、月60万から100万ぐらいみたいな感じだったんですよ、フルタイムで。そうすると、例えばですけど、保守だけで週1相当ぐらいやってほしいみたいな。
そうすると、5で割って、月12万から20万払って、週1分ぐらいの稼働を確保しておいてほしいです。月曜日これって言うんじゃなくていいので、なんかあったときにすぐ動いてもらえるのと、あとは月々ちょっとずつ溜まってる開発タスクをこなしてほしいです、みたいな依頼の仕方を受けてくれるところを探すって感じなんじゃないですかね。
見事ですね。でもすごく見やすいですね。ありがとうございます。
日本だったら、今の相場感で言うとそんな感じなんじゃないですかね。
もちろんその辺は知り合いで直接契約できるから安くできるとか、あとはいろいろあると思うんですけど、そういうどれぐらい柔軟に動けるかみたいなその人の稼働工数によって変わったりもするんで。
僕だったらそういう依頼の仕方をしますかね。
プロダクト開発の捨てる前提と保守費用の相場感
ありがとうございます。
あと何でしたっけ。
PMFの開発について何か注意すべきアドバイス。
もちろん作りすぎないって大事だと思いますっていう話で、
基本的には作ったもの、すごくいい標語があって、捨てる前提で開発するっていうのはやっぱりいいですよね。
前にも話したかもしれないですけど、ココナラの初期とかもう本当に全部コード捨てるつもりで、要はコードの過読性とかそういうのは無視してとにかく早く作るみたいな。
使用を決めるために作ると。テストする作る。最終的に使用が固まったら全部コード書き直すみたいな前提で書いていたみたいな話を聞きました。
具体的に例えばじゃあ一旦作って捨てるタイミングって、これもピンキリだと思うんですけど、大体どれぐらいのタイミングで一回やり直そうみたいな感じや目安になりますか。
どうなんだろうね。それは検証したい仮説が何かによるっていう感じだと思うんですよね。
自分たちが検証したいところまで検証できていたら、じゃあこれ検証できたんで、一旦この部分の使用はこれで確定でってなったら、そこを綺麗にするかもしれないし。
ペライチの場合はそこまでやってないんですよね。全部捨てるまでやってなくて、結果的に捨てた部分はまあまああるみたいな感じとか、
3年ぐらい前にペライチの全体のリファクタリングしたときにいらないコードがいっぱい出てきたりとか、だからあんまりメンテできてなかったっていうところもあるんですよね。
ちなみにこれもエンジニアじゃないファウンダーだと聞きたい質問なんですけど、捨てる前提っていうところは分かりながら、
どうカテゴリーして、捨てるっていうのはカテゴリーごとに分かれてくるのなのか、捨てるってなったらもう基本的にはゼロか1かみたいになってくるのか、
その辺りって、例えば我々の場合ですとマーケットプレイス的な形で、ブリジネスサイドとクライアントサイドとそれからサプライサイドのクリエイター側があるみたいな感じだったりもしているんですけども、
その辺りの捨てるときのゼロ1なのかもっと細分化されるのかってどんなイメージになりますか?
これもケースバイケースですっていう前提なんですけど、要は今ある行動の中でもここは変えないよねっていう部分がもしあるんであれば、
例えばベースになるユーザー認証の部分とか、デマンドサイドとサプライサイドのこの部分はもう変えないっすみたいな話であれば、
別にそこは捨てなくていいんじゃないですかっていうふうに思っていて、要は変える分、現状を授業を進める上で、さっき言った仮説、分かってない部分を検証したい。
それがコードにおいてどの部分なのかっていうのを明確にした方がいいんじゃないですかね。
仮説で捨てないってことですね。
そうそう。ここは変える。今思っている仮説がうまくいくなら進めるし、違ったら変えるよね。
例えばこの画面のこの部分って変えるよねとか、データの持ち方変える可能性あるよねとか、そういう議論をした方がいいんじゃないですかね。
なるほど。
その上でエンジニアとここは捨てる、ここは捨てる可能性ある、ここは捨てないとかっていうのをある程度握っておくと、エンジニアのほうも安心して開発できるんじゃないですか。
なるほどですね。
ここは捨てる可能性低いなとか、ここはゴリっと捨てる可能性あるから、多少雑でもいいかみたいな、その辺の割り切りはできると思いますよね。
エンジニアとのコミュニケーションの違い
その辺のコミュニケーションをしっかりとエンジニアチームと話しておくっていうのが、我々みたいなエンジニア出身じゃないファウンダーがいるときってすごく大事になってくる。
なるべく気を使うってことなんじゃないですかね。
完璧は難しいんですよね。結局、よくよく考えてみたら全部違ったからやめるわみたいな決断って全然あると思うんで。
だからUFOも完璧は難しいんですけど、たぶんそういう気の使い方をしてあげると、エンジニアの人もそういうニュアンスなのねっていうのは伝わるし、丁寧なコミュニケーションなんじゃないですかね。
ありがとうございます。ちなみに、はじめさんの場合、USの方にも投資されてるじゃないですか。
その日本とUSにおいてのエンジニアとのコミュニケーションの取り方の違いだったりとか、もし出資先でそういう話とか聞いたらリスナーの方にも参考になるのかなと思って聞いてます。
正直あんまりそういう話を僕聞いてないので何とも言えないんですけど、そうですね。
エンジニアとのコミュニケーションの取り方の違い。コミュニケーションの取り方の違い。
これもピンチですよね。結局別に身が違ったとしても、個人パーソナリティも違いますし。
そうですね。何だろうな。
これエンジニア限らず日本人とアメリカ人とか欧米の人との違いみたいな話で、目的思考みたいな話があると思うんですけど、
欧米の人は目的を明確にしてからそこにフォーカスしてそれ以外のことをやらないみたいな。
なるほど。
日本人って結構過程を重んじるから、Howを重んじるで、どうやってやるのかみたいなところのコミュニケーションをすごくするみたいな。
なんですけど、僕しゃべってて思ったのはエンジニアだったらあんまり変わんない。
例えばエンジニアって結局最後形にする人なんで、別に日本人であろうが欧米の人であろうが、使ってるプログラミング言語は一緒だし、
考えてる考え方は基本一緒になるんで、
ゴールをちゃんと設定すれば別にどう作れっていう指示ってしないじゃないですか。
そうですね。
非エンジニアからは。
そう考えると本本は一緒なんじゃないかなというふうには、ちょっとすいません、しゃべっててそう思いました。
なるほどですね。ありがとね。
コミュニケーションの違いで言うとなんだろうなと、何作ってほしいのか。
僕の経験、海外のエンジニアと働いた経験みたいな話もちょっとあるんですけど、欧米の人はあんまりないっすね。
東南アジアとか。
インドとか韓国とかだったらあるんですけど。
でもそんなにないな。
インド人エンジニアの能力
例えば前前職で一緒に働いてたインド人のエンジニアの人は、日本に住んでる人なんですけど、だから普通に一緒に職場で働いてたんですけど、
むちゃくちゃコード書くの早いんですよ。
スピードが早い。
生産性めっちゃ高くて、スピードめっちゃ早いですよね。
もちろん日本語のところで言うと、少し曖昧な部分があるんで、そこをちゃんと要件のところとかしっかりフォローしてあげるとめっちゃ早いみたいな。
これは別にインド人だからっていうわけじゃなくて、彼の能力が高いからなんですけど、すげえなって思ったりはしましたね。
なので、やっぱり能力の高い人はいるよね。
でもこれも別にアメリカ人でも欧米の人でも能力高い人あると思うんで、そんなに変わらないんじゃないかな。
結論、そんな大きな違いはないのではって最近思ってます。
ちょっとすいません、ここは少し欧米の人のエンジニアと仕事をあんまりしたことがないんで、少し解像度が僕低いかもしれないです。
あと何でしたっけ、CTOの探し方みたいな話もちょっと。
そうですね、この前第2回の時にそういう質問もよく柱さんのところに来るみたいな話をちょっと聞いてたので。
いやもうみんな困ってるんですよ。
大前提から話すと、そもそも日本だとやっぱり共同創業する人が少ないっていうのがまだにあって。
そもそもってことですね。
そうそうそう、これCTOに限らずなんですけど、僕はなんかもう共同創業をしてるだけでかなり僕の中でポイント高いっていう。
だってスタートアップしんどいし、あと初手からほぼほぼフルコミットで馬力が2倍3倍みたいな状態でスタートしたら、それは成功確率高いっしょって普通に考えたら思うんですよね。
それはなんか考えたことなかったので、すごい面白いですね。
ハイリさんも最初2人で創業してるわけじゃないですか。
はい、そうですね。
だからシンプルに2倍動けるんですよ。
僕なんか3人ですよ、だからシンプルに3倍ですよね。
人間の能力なんて言っても、稼働できる部分の能力なんてそんなに変わらないんで、初手から3倍のパワーで動かせるってそれだけで強いんですよ。
いやでも言われてみればそういうことかね。
でそれが特に僕プライチー3人で創業したときすごい思ってたんですけど、やっぱり僕は社長でしたけど、3人で創業して3人でやるんだっていう気持ちでやってるから、うちなんかみんなフルパワーでやるんですよね。
そうするとシンプルに、しかも目線も一緒に経営してるっていう目線でやってるんで、初期はね実務めちゃくちゃやるんですけど、やっぱそういう目線でやってるんで、
やっぱりその資座でやってるんでまあ強いですよねっていうことですね。
そういうチームであったら本当に投資したいと思いますし、でもなかなかいないんですよ日本、マジで。
でその前提ですと。なのでやっぱみんな共同創業者とか、それこそやっぱCTOみたいな人探してますよねっていうところ。
そのちなみに背景としては、やっぱりエンジニアのバックグラウンドがある方たちが、じゃあ実際に取ってスタートアップしようっていうのがそもそも少ないみたいな感じになるんですかね日本のほうで。
どうなんすかね、なんかまあまあ前よりは増えてきたとは思うんですけど、まだまだって感じなんじゃないですかね。
しかもその最初期からリスク取ってやろうっていう人がまだまだ少ないのではっていう感じ。
ちょっとね、この辺はもうちょっと僕も解像度上げて調べたいって思ってる領域で、スタートアップに行く人が増えたのは事実ですが、
とはいえなんか僕のところに最初期に来るファウンダーの人たちを見てると、最初からエンジニアいるみたいなチームってそこまで多くない。
とかその共同創業者まで行かないけどエンジニアはいますみたいな、まあそれはまだマシな方って感じですけど。
なんか一緒に経営するCTOとか、CTOってつかなくても共同創業者エンジニアですみたいなチームがいたらすごくいいんだけどなーみたいな、思ったより出会えないなーみたいな感じがすごく受けてて。
このギャップ何なんだろうみたいなのはすごい感じてて、訂正的には初期からリスクを取ってやるエンジニアの人がいないのかなーとか、マッチングがうまくいってないのかなーとか、共同創業者同士のマッチングがそもそも出会えてないのかなーとか。
そういう共同創業する側のエンジニアの巻き込み力みたいなところかもしれない。
CTOの探し方とコファウンダーの役割
それもあるかもしれないし、ちょっとこの辺ね、いくつか仮説を持っていろんな人に当たっていきたい。
絶対ね、もっとね、多分マッチングすればいいスタートアップがどんどん出来上がってくると僕は思っているので、その辺もちょっとできることあればしたいなーって思ってます。
で、何でしたっけ?CTOの探し方。
その辺は僕も今1年半創業しててっていう上で、ちょっと話せることもあるんじゃないかなという。
だから最初その、今半分買い中みたいな感じですけど、一応共同創業者ってこと、あれ?コファウンダーですよね?
そうですね、1年経ってコファウンダーになりました。
これね、リスナーの方に解説なんですけど、後から入ってもコファウンダーなんで、これオッケーですっていう話です。
これね、これ意外と大事で、僕これちょっと話取るんですけど、この話をしたくて、コファウンダーっていう肩書きってOAだと結構大事ですよねっていう話をしたいんですよ。
先日されてましたよね、ポッドキャストで。
そう、しました。
ベゾスの映画を見たみたいな話の時に確かしたんですけど。
日本だとあんまり意識されてないんですけど、これは海外、特にアメリカだと、やっぱコファウンダーっていう経歴がついてるとやっぱすごいっていうか。
ついててもついてなくても、どうなんですかね、僕感覚わかんなくて。見栄えの問題なんですかね。
どうなんでしょうね。
名誉とかオーナー、でも普通に考えるとコファウンダーって入ってるんで、創業初期からやってる人、イコールリスク取って最初から頑張った人。
ってことですよね。
は、なんかやっぱ称えられるべきみたいな感覚があるのかなって思ってるんですけど。
僕はポッキーキャスト聞いて、ザックにコファウンダーって入れてたっけどうかってちょっと資料見直しました。
ぶっちゃけ彼は気にしてないんですけど、まったく。
おそらくエンジニアの方々、ほぼほぼ気にされる方って少ないといいなと、自分の肌感覚で思ってるんですけど、1年経った上でコファウンダーとして入ってますね。
あとからつけるケース、自分たちがコファウンダーだと思えばつけてもいいと思うんで、僕はすごくいいと思ってますと。
シンプルに見栄えもいいというか、僕が投資家の目線で資料にコファウンダーですって載ってたら、コファウンダーなんだみたいな、コミットメントそこそこ高くて、CTOなのねみたいな。
チーム出来上がってきてるじゃん、みたいな思うわけですよね。
結構いますよね、周りでも。自分たちももともとZackにアプローチしてたのは、それこそ創業したての時からで、その時はもう本当に特に開発もしてない、プロダクトもないところだったんで、アドバイザーみたいな感じで、
ずっと週1くらいとかでコミュニケーション取りながら、最終的に入ってもらったみたいな感じでしたけど、やっぱり国民のスタートアップとかでも、それこそYコンに入ってるようなスタートアップでも、Yコン通った時は2人でやっていて、その時のYCのアプリケーションをアドバイザーとして変えてくれた人がいて、そっから成長する中でコファウンダーになったみたいな話とか。
普通にいろいろ聞くんで、意外と海外とかは特にそんな感じなんだろうなっていうのは。
大事なんだよな、やっぱコファウンダー。コファウンダーって付くことがすごい大事みたいな。
リスナーの方、そこら辺の感覚わかる方いたらぜひ教えてほしいです。
ということで、話し取れちゃったんですけど、CTOの探し方。どんなふうに探しました、Zack。
自分たちの場合は、もうシンプルでいい。エンジニア候補になりそうな人を全部リストアップして。
どちらかというと、自分たちの場合はフィリピンスタートだったので、そもそも英語が使えるエンジニアじゃないといけないっていう前提条件があったので、日本人の方は特にリストアップはせずに、コファウンダーの耳が全部リストアップして、一旦全員声をかけるみたいなのをやりましたね。
それは元から全員知り合いってことですか?
基本的には知り合いとか知り合い周りみたいな感じですね。
知り合いの知り合いぐらいね。
そうですね。それぐらいの人に声をかけて可能性がありそうな人っていうのを一旦リストアップするみたいなのを。これはどっかのウェビナーで、誰だったかちょっと忘れちゃったんですけど、ヤプリの方だったかな。
基本的にはCOの一番の仕事は人を探すことだから。
イハラさんとか言ってそうですよね。
ヤプリのイハラさんとか言ってそう。
マジでそうだと思ってて、これもCTOに限らないですね。全職種層だと思います。
特にキーマンは社長とか経営メンバーの周りぐらいから集めてくるみたいなのって鉄則なんで、やっぱりそれをやり続ける必要があると。
初手においてもCTOもそういうふうに探した。フィリピンだったらフェイスブックとかたどっていく感じですかね。
そうですね。フェイスブックたどってだったりとか、人づてに聞いて。ミミィがフィリピンの東大みたいな一番トップの大学だったので、そこをアプローチすれば基本的には優秀な人って絶対当たれるだろうっていう仮説のもとを全員にやっていって。
ザックの場合は彼らは自分の会社をCEOとしてずっとやってるので、そのタイミングですぐにジョインとかはまずないでしょうし、何なら数年後とかに確率として10%、20%かもしれないけど、コファウンダーになってくれたらいいなって思いながら、ずっとちょっとずつリソースを回収しながら、ちょっとずつ増やしながら。
最終的に、もう今一応彼の会社があるっていうのはハーフコミットですけど、ほぼほぼフルコミットぐらいな感じの勢いでやってもらってるっていう。
なるほどね。
だからその辺がすごく恵まれてるというかラッキーだと思います。
結構すぐ見つかったんですか?
そんなにすぐはでも見つかってないですね。
アクション始めてからどれくらい?
ぶっちゃけ覚えてないところあるんですけど、最初にアプローチして、そっから数ヶ月後とかに一旦ちょっとアドバイザー的な感じで、週1ぐらいのミーティングとかにはちょっと参加してもらいながら、週1って言ってもでも2時間とかですけど。
結構ガッツリやるね。
どうですか?
最初にしては結構ガッツリやるなって思いました。
それでちょっとこういうの考えてるけどどうしようみたいな、いわゆる外注探しを手伝ってもらうみたいな位置づけで入った。
最初からあんまりプレッシャーをかけたくないっていうところもあったので、そこで開発会社選ぶ、エンジニア選ぶときのアドバイスをしてほしいみたいな感じからちょっと入ってもらいつつ、
最終的に話していくと結局、じゃあ外注するときにザックの会社にした方がいいじゃんっていうような結論にもなったり、
っていうところから一旦外注から入ってもらいつつ、中でプロダクト管理できる人がいいよねっていう話から、じゃあザックが中に入って一緒にやってくれたら一番いいよね。
だからプロダクトの開発はそんなめちゃくちゃ劇的に毎回やっていくわけじゃないから、フルタイムじゃなくていいよみたいな話でどんどん巻き込んでいくみたいなやり方。
エンジニアの給料とCTOの探し方
そうですね。サービスの特性もすごく今のやり方に相性が良かったのかもしれないですね。
要はフルタイムでゴリゴリゴリゴリ開発していかないといけないプロダクトではなかったっていうのがすごく大きいかもしれないですね。
そうですね。なので本当に今ってやっぱり開発のスピードコントロールできるってすごく大事じゃないですか。
確かに初期においてはすごく大事。
なのでそれを今クイックにやれているっていうところの状況なので、それこそインハウスで雇ってしまうとずっとそこのお給料が出ていく。
これって結構スタートアップにとっては致命的な場になってくるので、自分たちにコントロールできるっていうのはめちゃくちゃこの体制にして良かったなって思うところですね。
確かにそうですね。あとは、そうですね、やっぱりオペレーションの話もしましたし。
そんなとこですかね。
はい、ということで、ゴリさんすごく、今日も思ったんですけど話しやすいんで、レギュラー出演していただきたいなって思ってます。
何人かレギュラー出演、月1ぐらいのレギュラー出演してる人がいるんで、そんな感じで負荷にならない程度に出ていただけると、やっぱりテーマが毎回いいんですよね。
他にも出てもらってる投資先のオッシーとか出てもらってますけど、実際にスタートアップをやってる人、特にいろんなフェーズでやってる人が気になる話題とか、それからこれどうしてましたっけ、向き合ってるんで日々。
やっぱりそこから生まれてくる疑問とかテーマって、すごくやっぱりリスナーにとっても非常に生きたテーマなので、すごくいいかなというふうに思いますので、ぜひとも引き続き出ていただきたいと思っております。
はい、ということで、必ず僕このラジオの最後にお伝えしている内容がありまして、今ですね、スポーティファイのフォロワーを表示してます。フォロワー数が、Boot App Radioのフォロワー数が287人です。
おー、あと13名。
はい、300名いったらオフ会をやりますという告知をしておりまして、現在。あと13名です。もう行きそうなんで、実際にスケジュールを抑えてありましてですね。
ですよね。
オフ会のスケジュールが12月18日の夕方、都内某省にてオフ会をやる予定でございます。
これが配信日が。
配信日にはもうおそらく突破している。
配信日には突破しているかもしれないということで、これを聞いて、もしオフ会に興味。一応ね、公開収録みたいな話と、それから公開しない収録、公開しないトークとかも予定していまして。
せっかく来てもらったんで、ちょっと面白かったなというふうに思ってますので、ぜひお時間あう方は来てください。
Spotifyの配信のテキスト欄に応募のURLが、その申し込みのURL、イベント参加の申し込みURLを貼っておきますので、そちらからぜひご応募ください。
どんな人が聞いてるのかむちゃくちゃ気になるんで、ぜひ来てほしいなと思ってます。
もう残念にキリピンにいるのでちょっと参加できないですけど、なので第2回に参加できることをちょっと僕は。
ちょいちょいやりたいですね。
はい、ということで、今日も堀さんありがとうございました。
はい、ありがとうございます。
はい、失礼いたします。
