目次
■ソフトウェア設計とメンテナンス
2023.03.07 2024.03.05 約3分
| この記事は 2022年12月7日発売 『ちょうぜつソフトウェア設計入門――PHPで理解するオブジェクト指向の活用』を取り上げた connpass勉強会 を再編集し、記事化したものです。 |
スタートアップに入社や転職をして「どうしてこうなるまで放置した？」「なぜ対策しなかった？」「コードが酷すぎて読めない」と心のなかに秘めて吐き出せない気持ちを抱えている方も多いのではないかと思います。なんなら設計されたものとさえ思えないかもしれません。無数に散らばる require/include、N+1 なんて日常茶飯事。第一引数しか使われていない htmlspecialchars。このような技術的負債に対峙した場合、どうしたらよいか、CTO の立場からお答えします。
スタートアップは、ガチでお金がないです。ではどのようにお金を得るのか。手段は基本的にこの3択。それぞれ解説していきます。
|
デットファイナンスは銀行、信託銀行、公庫（日本政策金融公庫など）からの融資つまり借金です。利子をつけて返さないといけなかったり、原則代表自身が保証人となるため、 会社が潰れても責任を負う必要があります。その一方で、株式を譲渡する訳ではないため経営への影響はありません。また、損金計上できる等の会計上のメリットもあります。
余談：デットファイナンスを行わない経営を無借金経営といいます。
スタートアップ初期の企業価値は、紙切れに近いといっても過言ではありません。経営陣は投資家たちへ自分たちの会社にいかに輝かしい未来があるかを語って、現時点では紙切れに等しい株式と引き換えに投資を受けます。これがエクイティファイナンスです。この輝かしい未来像やそれを実現するための計画をエクイティストーリーと呼びます。エクイティストーリーに説得力があり、期待できる成長が大きいほど “バリュエーション” と呼ばれる企業価値が向上します。エクイティストーリーに説得力を持たせるためにもエンジニアリングが重要です。例えばSaaSサービスであればプロダクトの質を向上させることで競争力を高め売上を伸ばすことが可能ですし、システムの力で高効率な運用を可能にし、人件費などのコストを抑えることが出来れば利益が出やすくなります。
バリュエーション：企業の利益・資産などの企業価値評価のこと
投資ラウンド：投資家がスタートアップに対して投資を行うフェーズのこと
ランウェイ：投資を受けたお金 + 自己資金で会社が存続できる期間のこと。人を採用するとランウェイが短くなる (後ほど解説)
エクイティストーリー：投資家に対してどれだけ価値のある会社となるのか成長戦略を見せること
そのため、売上を上げても出ていくお金（キャッシュアウト）が上回れば、会社は永久に赤字です。そもそもスタートアップは売上がないことがほとんどですから、赤字経営な場合が多く、あまり現実的なまとまった資金を得る方法とはいえません。
今回は一般的なシリーズCまでをまとめています。
株式会社は定時株主総会で決算承認後、遅滞なく貸借対照表（B/S）の公告が必要です（会社法第440条）。基本的には B/S もしくは 官報 を確認しましょう。また上場企業であれば IR などを見るのがおすすめです。
スタートアップにはお金がないことがわかりました。そのため、エンジニア採用もキャッシュインや投資ラウンドなどの状況に応じて、戦略をわける必要があります。いきなり超絶激強エンジニアを採用するのは非常に困難です。次の図を見てみましょう。
もし年収1000万のエンジニアを雇った場合、資金は1年程しか持ちませんから、2年後の資金調達に間に合わず会社が倒産（資金ショート）してしまいます。実際には上記の図に、売上原価や販管費などが加わるため、1年と持たないでしょう。事業戦略・経営戦略によりますが、恐らく年収500万のエンジニアを選ぶ可能性が高いはずです。ランウェイを伸ばす方が、その期間中に様々な施策を行えるという点が大きいためですね。
ここまで聞くと「すぐに資金調達をすればいいのでは？」と思いますよね。しかしそう簡単にはいかないのです。資金調達のためには、事業上の KPIに基づき、エクイティストーリーを証明する必要があります。ゲームでステージ1をクリアしないとステージ2に進めないように調達した資金でエクイティストーリーを実現していかないと次の資金調達には進めないことが普通なのです。ここでちょっとズル賢くなって、早く次の資金調達を実現するためにストーリー上、低めに売上を設定して大達成を演出しても投資家からは予実管理の出来ない経営陣と受け止められてしまい、資金調達を進める上でプラスに働くことはありません。
業務委託や受託会社を使ってシード期などのアーリーフェーズを乗り切る場合は、経営陣にアプリケーションについての知識がないと、ソフトウェアの設計はハチャメチャになりがちです。シード期からしっかりとエンジニアを採用していくにしても、事業フェーズによってマッチするエンジニアは異なります。手が速い初期フェーズに適したエンジニアもいれば、設計やCI/CDなどの開発環境整備などにも知見のあるミドルフェーズ以降に特に力を発揮するエンジニアもいるでしょう。よって採用をする場合はその見極めも重要になります。
投資家から資金を得るためには 0→1の開発がマストです。 プロダクト開発が前に進まないと資金調達は難しいので、汚いコードでも動くものが重宝されますよね。
汚いコードでも動くもので走ってきました。サービスの成長は喜ばしいながらも技術的負債の蓄積などにより新しい価値をデリバリーしようにも影響範囲のリサーチに時間が掛かるなど、開発スピードが低下しがちになります。そこで技術的負債の返却に知見のある人や変更容易性が高い設計ができるエンジニアの価値が高まります。
エンジニア視点からいうと正直難しいと思っています。1年間で約6万社が設立され、そのうちの半分は潰れています。この状況で、マッチする1社を見つけるのは極めて困難でしょう。企業視点で見ると、お金がなく安定しない状況で、採用教育費をかけても、良いエンジニアとマッチングできる可能性は低いため、経営者同士のつながりや、VCからの紹介、リファラルなどを駆使し、開発できそうなエンジニアを探してきます。またプロダクト開発も推し進めなければ、資金調達にも支障が出ます。つまり採用に時間をかけられるのかが問題になってきます。
物理的にも金銭的にもエンジニアの採用が難しいという話をしました。エンジニアとしての経験がない人 （≒創業者）が、書くことになりソフトウェア設計はぶっ壊れ（ index.php が10万行になったり……）、直すたびに不具合が起きる “ 割れ窓理論 ” に該当するようになります。では 「はじめから丁寧なアプリケーションの品質でモノを作れば解決では？」と思うかもしれません。ところがこの図を見てもらうと、それもちょっと難しいという事実がわかってもらえると思います。
（図の下の部分）後半になるにつれ、メンテナンス性が高くなるので、やりたいことはいつでもできる状況になります。一方、プロダクトを世の中に出せていないリスクを抱えたまま走ることになるので、資金が底を尽きて資金ショートになる可能性もあります。もちろんうまくいけばお金も入ってきて良いアプリケーションを作っていけます。
（図の上の部分）経営陣や経営陣の友人が開発するなどエンジニアリング投資を控えめにした場合は、後々それらを回収するためのメンテナンス（リファクタリングやリプレイス）コストがかかります。そこをいい感じにしていくのが経営陣、 特に CTO のお仕事です。
多くの場合、競合との差別化のうえ顧客を獲得します。もし競合が不在でも、潤沢な資金を持った大企業が市場参入すれば、スタートアップはどうなるでしょうか……。そう考えると、早くプロダクトをリリースし、改善を繰り返し、PMF を急ぐ必要があると経営者や投資家は判断するはずです。仮にあなたが、なんでもできるスーパーエンジニアだとして、認知度や年収が低く（仮に無償ストックオプションをもらったとしても）存続の可能性が不明瞭な会社に行きたいと思えるでしょうか。多くのエンジニアは、高年収かつ、RSU（譲渡制限付株式ユニット）などで評価してくれる会社に行きたいと考えるはずです。
会社はこれらの課題を乗り越えたという点で、初期エンジニアを評価しやすい傾向があります。あとから入社したエンジニアが 「アプリケーションの品質を高めて 良いサービスを作っているのに初期メンバーが評価されがち」と思う理由はこういった背景です。 経営陣とエンジニア側の軋轢が生まれやすいところですね。評価制度の見直しは適宜必要でしょう。
これらを防ぐには予め潤沢な資金を用意しておく必要があります。 つまり資金調達が非常に成功している状況であるか、自己資金・自己資本が強い会社である必要があります。しかし資金に余裕があるからといって認知度の低い会社では、優秀なエンジニアが集まるとは限りません。もちろん会社の知名度向上施策は常々打つべきですが、多くのエンジニアに認知されるのは上場以後が多いように思えます。こうした面でも、プロダクト開発戦略も採用戦略もスタートアップに は苦難を強いることになるといえます。このように、プロダクト開発戦略は会社フェーズによって変えないといけないことがわかりました。開発戦略を変えるということは、すなわち採用の戦略も変わっていきます。つまり会社がグロースすることによってミスマッチが起こるようになるわけです。ミスマッチが起こらないようにするためには、適切なプロダクト開発戦略のコントロールと採用戦略のコントロールが必須です。
会社のフェーズによって、これらは変化します。
そのなかで、会社を存続させるためのソフトウェア開発の戦略をどのように考えソフトウェア設計までブレイクダウンするかが大切です。
複数のスタートアップを経て，GameWith や BASE といった上場企業でソフトウェアエンジニアとして従事。2020 年に株式会社トラーナに一人目のエンジニアとしてエンジニアリングマネジャー兼テックリードとして入社。2022 年 1 月に執行役員 CTO として就任。2023 年 5 月末に，執行役員 CTO を退任。同年 6 月より暫定無職。PHP 関連のカンファレンスやイベントなどで数多く登壇。拙著に「Swoole で学ぶ PHP 非同期処理」，「レガシーコードとどう付き合うか」，そのほか Software Design などに寄稿。
