TAKASHI TOYOFUKU

4年間務めたスタートアップを退職しました

4年間務めたスタートアップを退職しました

June 22, 2020

4 年間務めた BEC を 2020 年 4 月いっぱいで退職していました(事後報告)。 1 つの SaaS サービスをひたすら開発して過ごした体験はとても貴重だったけど、31 歳になってキャリアを考える上でもっとたくさんのビジネスを経験したいという気持ちが強くなり退職の決断をした。 ここでは 4 年間の学びや反省(の一部)をまとめておく。

スタートアップはとにかく問題が山積みなので、優先度とスコープを決める

大きいチームではメンバーが多いため、課題解決のために必要な役割をできるだけ細分化してメンバーに割り振ることができるが、スタートアップでは少数のメンバーで役割を分担しなければならない。 スタートアップで働くメンバーがいかに優秀とはいえ、すべての分野の専門知識や能力をカバーしきれず、たくさんの問題に遭遇することになる。 しかしすべてを解決することはできないので、優先度をつけて、やるやらないのスコープを明確にしなければ、本質的にやらないといけないことができなくて死ぬ。 優先度の判断については記事が一つ書けそうなのでそのときに詳しく。

初期の技術力超大事

自分のことも含めての反省だが、初期実装者の技術力が非常に重要。 なぜなら初期の設計(アーキテクチャとかデータ設計とか)がその後のチームの開発スピードを制約してしまうので。アプリケーションの実装など、上層レイヤでは比較的再設計が可能だが、データ設計やアーキテクチャなど根幹の部分に近づくにつれて再設計が難しくなり、機能追加を優先し負債を放置せざるを得なくなり、開発スピードを落としてしまうことになる。 スタートアップのビジネスのスピードはとても早い。Product Market Fit するまではものすごい速さでビジネスが軌道修正されていく。エンジニアはそのスピードに付いていかなければならない。 よってスタートアップでは開発スピードが勝負なので、アプリケーションの実装に集中できる技術選定をしたほうがよい。新しい職場で Lambda と DynamoDB でサーバレスな設計を経験したけど、パブリッククラウドとそのマネージドサービスが便利になっていて、それを使いこなせるかどうかがスタートアップとしての競合優位になりそう。(最終的にはメンバーの技術スタックによるし、数年後また変わっている気がするので、技術のキャッチアップ超大事)。

役割の溝を埋める

先に述べたように、スタートアップでは問題が山積みです。 問題の解決方法は何通りもあるが、確度の高い解決策に至るには、その問題に対する専門知識が必要。 しかし、スタートアップでは数多くの役割を少ないメンバーで扱う必要があるので、メンバーの誰もが明るいとは言えない問題が発生した場合に、なんとなくそこに近い人に責任を押し付けたりしがちです。 僕はこれを「役割の溝」と呼んでいるんですけど、役割の溝は認識できたら 8 割解決できます。あとはその問題の解決に必要な知識を、メンバーの誰かが身につけて問題にアプローチして少しずつ解決に向かえばよいです。 身につけるのが大変なものであれば、外部の人にお願いするのも有効。 溝が溝のまま認識されていなければ、メンバーが「何故かうまくいかない」「これって A さんの役割じゃないの?」と問題を抱えたまま解決から遠ざかってしまう。 この辺は小さい組織でも、役職とか役割を言語化して各メンバーに割り当てるといいのかなと思っています。

採用がとても難しい

スタートアップではキャッシュフロー的に優秀なエンジニアに市場価格でオファーを出すことが難しい。そのためにストックオプションがあったりするのだと思っているけど、本当に初期の初期の場合はそれすら出すのが難しかったりしそう。 しかし、エンジニアを増やして新しい技術スタックを増やしていかなければ、開発スピードは上がらない。 なので結果として業務委託の方にコンサルしてもらって技術スタックを増やしたり、学生アルバイトを採用して微妙に育成コストをかけつつ、かんたんな業務を任せることで、コアメンバーでクリティカルな実装を行うなどしてました。 しかしもっといいやり方がありそうで、他のスタートアップはどうやって採用しているのか知りたい。。。採用に踏み切るフェーズの判定とか、どういう層にアプローチするとかどうなんだろう。。。

開発スタイルはメンバーに合わせてカスタマイズする

スクラム開発のようなメジャーな開発スタイルはスタートアップにはかなりフィットするが、そもそもスクラム開発で解決できる課題自体に対して、その時そこまで問題だと思っていなかったり(単純な視点の違いによる認識の違い)、プロダクト開発の経験がなかったりするメンバーがいることは多々ある。 そのような場合に新たな仕組みを導入しても、そもそも理解と強力を得るための努力が必要となってしまい、余計な労力が増えて、そもそも頓挫してしまうことが多い。 なので、テンプレとして仕組みの導入を検討することはとても大事だが、そのテンプレからみんなが課題だと思っている部分だけに絞って軽量にして導入し、あとから順次バージョンアップしていくのがワークしていたように思う。 あとは、初期は全員で始めずに、一部のメンバーだけで始めてみて徐々に展開していくなど。

まとめ

4 年間のスタートアップ生活はとても苦労したが、その分エンジニア的にも人間的にも成長できたと思っていて、お世話になった人々には感謝の気持ちしかない。 公私ともにお世話になったメンバーも居るし、いつかどこかで世話になるかもしれないので、その時に自分が力になれるようにレベル上げをしたいなと思っています。

BEC でみんなで揃えた iittala のマグカップは(割るまで)一生使うと思う。

マグカップ
マグカップ
© 2024 Takashi Toyofuku All rights reserved.