TL;DR
- 全社を開発プロセスに巻き込む
- MVPの究極は作らないこと
- PDCAにこだわりすぎない
- ROIを念頭に置きながら技術的負債と上手く付き合う
- 採用できない、リソースが足りないなら「ないものねだり」をしない
はじめに
ユアマイスター株式会社でエンジニアをやっています。
ちょうど開発に参加してから1年位経ったので、振り返りがてら自分の感じたスタートアップでの開発のコツを書いてみようと思います。
スタートアップ以外でも「社内の新規事業ブロジェクト」とか「友達となんか作ってみる」とかのときにも共通する部分もあるかと思います。
私のプロフィールは
- 2018年4月でエンジニア5年目に突入
- 底辺文系大卒
― 現在3社目(SIer->事業会社->スタートアップ) - やってきたこと
- WEBのバックエンド(Java/PHP/Ruby)
- AWSでインフラもどき
- ビックデータちょっと触ったり
こんな感じです。大体toCのWEBサービスを触ってきました。
全社を開発プロセスに巻き込む
まず、ここが無いとスタートアップでの開発は死にます。
入社当初はエンジニアが自分の他にCTOしかおらず、割とゴリッゴリの「営業さんが強めの会社」でした。
そもそもスタートアップは最初はそんな簡単に売れません。
なので、「数値から分析して施策を出そう」と言おうにも、そもそも数値がない状態からスタートします。
結果として
エンジニアは今までの経験から良さそうなものをとりあえず追加で作り続ける
VS
営業は今までの経験から良さそうなものをとりあえずエンジニアに作らせたがる
という仁義なき戦いが勃発することになります。
そもそもスタートアップって「他社がやってないことをやってみよう」というものなので
「今までの経験で似たようなことで上手くいっていた」という幻想に縋って大失敗することがたくさんあります。
そのため、まずは仮説をしっかり立てて、ひたすらその仮設を皆で叩くが重要です。
簡単に言うと、営業さんに頼んでVOC集めてもらうとかそういうことですね。
そして、作って欲しい機能や作りたい機能は色んな視点から施策をチェックをしてから実装に入りましょう。
エンジニアが作りたいだけの機能も、営業さんが作って欲しいだけの機能も、大体ユーザは求めてません。
MVPの究極は作らないこと
- Minimum Viable Product (参考: MVP（Minimum Viable Product）とは | リーン・スタートアップの基本とMVPの実践)
よく聞くようになりましたね。
最初から機能マシマシのものを作るのではなく、コアな機能だけを作って本当に必要なものだけをとにかく足していきましょう、というイメージです。
ただし、スタートアップの、特に管理側の機能とかスポットのキャンペーン機能とかは
「そもそもMVPを実装する必要があるのか」
をよく検討したほうが良いと思います。
そのダッシュボード、本当に必要ですか？スプレッドシートでできませんか？
そのアンケート機能、本当に必要ですか？GoogleFormで良いんじゃないですか？
そのクーポンでの値引き機能、本当に必要ですか？メール送ってもらってクオカードプレゼントのほうが実装コスト考えると安いのでは？
これだけSaaSが普及している時代です。
というよりスピード以外に強みがないスタートアップが、当たるかもわからないMVPに工数なんか使わないでいいと思います。
しかも手抜きのMVPは後々セキュリティホールや追加開発のボトルネックになりがちです。
PDCAにこだわりすぎない
前述しましたが、そもそもスタートアップは数値がない状態からスタートします。
そのため、PDCAを回そうにもサンプルが少なすぎてPlanもCheckも外れ値によるバイアスがかかることがかなり多いです。
でも、サンプルが少ないから外れ値を除外できないっていう辛さがあります。
なので、まずはMVPを作らない形を併用しながらひたすらDoを繰り返します。
その上で、ある程度サンプルが取れる状態(売上が上がってきた状態)になってから、PDCAを使って贅肉を落としていくほうが簡単です。
「何を施策としてやったら良いのかわからない」というときには大手・競合をひたすら参考にしましょう。
サービスの競合優位性・コアコンセプトを明確にして、ひたすら大手や競合を真似ることでマイナスを埋める。
地味でしんどい作業ですが、これが一番失敗を減らせる(スピードを落とさずに走れる)方法だと思います。
ROIを念頭に置きながら技術的負債と上手く付き合う
ROI(Return of Investment)を常に考えながら開発するのはスタートアップのエンジニアとしては当たり前のことだと思います。
が、これだけを考えていると実装が汚くなり、クソコードが量産され、結果として大きなツケを払う時が必ず来ます。
ただし、以下のようなことを押し通すことで開発スピードを落とすことは事業そのものの成長にとって大きなリスクになります。
- 「○○(特定の言語や技術)はクソ！今すぐ捨てて全て作り直すべき！」という当然の欲求
- 「耐障害性を考えると面倒でもなるべく冗長な構成を組むべき」という素晴らしい姿勢
- 「どんなときでも美しいコードを書く」という誇り
これらはエンジニアとしては当然持つべきものであり、大切にするものです。
しかしながら、それによって開発スピードが落ち、とある機能の実装が2週間遅れることで事業の継続が困難になることが有りえます。
そこはバランスが全てなのですが、それについてちょうどいい事例があります。
PHP5.6 + CakePHP3 + Apache2.2のECサービスからAMP並のTTFBを実現するまで
上の記事は先日公開したものですが、はてブで「本番環境でSingle-AZはありえないだろう」という至極当然の耳が痛いコメントが有りました。
まさに先に上げた「耐障害性を考えると面倒でもなるべく冗長な構成を組むべき」という素晴らしい姿勢 です。
ただし、それについては以下のような理由から無視する判断を下しています。
- AWSのAZ単位で障害が発生する確率がかなり低い
- RDSやRedisのデータは常に復元できる状態にある
- ElasticsearchについてもDBの内容から復元できる
- AMIからアプリケーションサーバを容易に復元できる
- 2018年4月よりGoogleがMFIの適用をアナウンスしていた
改善を積み重ねて手に入れたOrganic流入をスピードの改善が間に合わず失うというのは非常に痛い、という総合的な判断です。
ただし、これらは「クソコードを量産していい」という理由にはなりません。
適宜「改修が容易な設計を行うこと」「機能追加時にリファクタリングを行うこと」を徹底することである程度のレベルで劣化を留めておくことができます。
採用できない、リソースが足りないなら「ないものねだり」をしない
今エンジニアは空前の売り手市場、給与が安く環境が悪くなりがちなスタートアップではエンジニアの採用は厳しいものがあります。
「あと1人分リソースがあれば...」
「アプリを作れるエンジニアがいれば...」
そんな感情は常に頭に渦巻いていますが、そもそも
5人のエンジニアで作れないものをスタートアップが扱うことが危険だと思っています。
（もちろん、IoTやAI、バイオなどの「研究開発に近い業種」など例外はあると思います。）
自らへの戒めでもありますが、
エンジニアが足りないのは、MVPと想定しているものが巨大すぎるか、エンジニアの腕が悪すぎるだけです。
おそらくMVPが素晴らしければ、エンジニアも出資も集まってくるんじゃないかな、とも思っています。
とにかくスピードを上げて眼の前のプロダクトを研ぎ澄まし、事業を成長させる以外には採用はできないと思っています。
多分エンジニアが足りてる現場とか存在しません。
おわりに
スタートアップの開発は「スピード」と「チームの一体感」の2つが最も重要だと思います。
まだまだ未熟で至らない点が沢山ありますので、今後も最高のプロダクトを作れるチームを目指していこうと思います。