シード期に基幹技術のリプレイスはするなという話
MySQLを使用すると会社が潰れると言う記事を見た。エンジニア界隈では定期的にこのような記事が拡散され、普段は面白おかしく見ている。ただし今回はシード期の話であり、この記事が好意的に拡散されるのはスタートアップエコシステムにとって好ましくないと思い、記事を書くことにした。
エンジニアに意識して欲しい事業ステージ
界隈では技術の良し悪しが日常的に話題になっているが、人的リソースを考慮した記事はあれど、会社の事業ステージを踏まえた記事は少ない。一般的にエクイティ調達(株式による調達)をして、IPOを目指すスタートアップの事業ステージは以下のように分かれる。それぞれがどのような時期なのかはザックリでも是非エンジニアに覚えておいて欲しい。
- シード(プロトタイプ)
- アーリー(PMF前後)
- ミドル(スケール)
- レイター(上場前)
スタートアップにおけるシードステージというのは大抵が初回の資金調達を行い、12〜18ヶ月程のランウェイ(会社の口座残高と運転資金を踏まえた事業の継続可能な期間)の中で、Product Market Fitという金脈を掘り当てる期間だ。PMFに至った、もしくはその兆しが見えたスタートアップだけが次の投資ラウンドへ進むことができる。
これを言い換えると、多くのスタートアップがその金脈を掘り当てられず、早くもこのタイミングで消えていく訳だ。ちなみに古い海外のデータではここで8割が消えるそうだ。簡単にいえば会社として生きるか死ぬかの分岐点なのである。
シードステージでのプライオリティ
では、そんな状況の中で金脈を掘り当てるため開発チームに求められることはなんなのか。これは声を大にして言うが、間違いなく開発スピードだ。
考えてもらえばわかると思う。どんなに「良い設計」も、どんなに「綺麗なコード」も、金脈を掘り当てられなければ1, 2年後にはただのデジタル粗大ゴミとなってしまうからだ。
シード期のスタートアップにおいて、Railsなどモジュラーモノリスなフレームワークが好まれる理由はここにある。まず自分たちが死ぬ前にPMFに至ることが大切で、理想的な綺麗なコードは二の次なのだ。
初期設計が全て。十字架を背負って進め
ではセキュリティを考慮する必要はないのか、スケーラビリティは要らないのか、全てをハードコードして良いのかと言うと勿論そうではない。これらは初期設計段階で十分に吟味しておく必要がある。
ただし、いかんせん会社が安定しているフェーズとは違い「キャッシュを産めないコード」に時間を割く余裕はない。やり直しが効かないのだ。リファクタリング単体に工数を割くなんてもってのほか、初期設計を間違ってもそのまま突き進むしかないのだ。
強い言葉を使うなら、「おれ、わたしの、なうでトレンディなさいきょうのせっけいや、OSSコミットを実現したいのなら余裕のある大企業へ行ってくれ」と零細スタートアップのfounderとしては思う。
じゃあ失敗したらどうするの?
シード期のスタートアップが初期設計に失敗したらどうするのかというと、その問題が発生してはじめて改修を考えるというのが定石だ。例えばweb上では「スケーラブルな設計」という記事がありふれているが、あるかもわからないトラフィックに耐える改修に工数を割くのはシード期では愚の骨頂なのだ。それを実現する引き合いが発生してはじめて、スケーラブルな設計は必要となる。
(個人的にはtoBのwebサービスではフロントエンドを分離する必要すらないと考えている。引用元風に言うと、「フロントエンド界隈はShopifyとGitHubを超えてから言え」とすら思う。それほどスピードが第一ということだ。
※catnoseさんのしずかなインターネットのような、デザインや世界観がUSPとなるtoCサービスは別なので注意)
経営陣はエンジニアの手綱を握れ
さて、ここまで読んでくれた人にとっては、シード期というフェーズにおける基幹技術のリプレイスがどう言う意味を持つか理解してくれたかと思う。
個人的に率直に思うのは「技術がわからない経営陣をいいことに、やりたい放題やったな」という感想だ。エンジニアの暴走は時折聞くことがあるが、シードフェーズでDB変更やバックエンドの言語変更までの事例は聞いたことがない。それほどまでにひどい。
不幸中の幸いだったのはtoBサービスであり、Biz、Salesが強かったのだろうとうかがえることだ。そこが弱ければリプレイスしている間に会社が潰えただろう。
この事例を見て、改めて非エンジニアの経営者にとって、最初のエンジニア採用がいかに難しいかがわかる。そこを間違えると必ず死活問題となる。少なくとも外部委託してでもダブルチェックは入れた方が良い。
最後に
この記事を書いたのは、自分が非エンジニアとして起業したからだ。今でこそ技術選定の意思決定もできるようになったが、当時は言われるがままの技術を採用していた。こういった事例に巻き込まれなかったのはただ単に運が良かったと思う。
コードレビューがあってないようなフェーズというのはスタートアップに存在する。そのことをエンジニア、スタートアップ経営者には知っておいて欲しい。こんな事例をのちに聞くことのないことを切に願う。
Discussion