そんな皆さまの疑問にお答えします。
スタートアップのアーキテクチャがブッ壊れてるのってなんでェ？
先にざっくりまとめましょう。
巷でよく言及されるのはカネ、つまりは雇用するエンジニアの能力問題を元凶とする方が多いようです。
スタートアップの内情を知っていれば金と雇用の問題がどれだけ切実であるかについて異論を唱える人はいないとおもいます。しかし僕の考えによればこれはスタートアップのソフトウェア開発が抱える問題のうちのひとつ側面にすぎません。
つまりどんなに優秀な人間をかき集めようがスタートアップのソフトウェア設計は近い将来壊れる宿命にあるということです。
スタートアップの存在意義は未来の不確実性そのもの
普通のやつらの上を行け、ではありませんが。
スタートアップ企業はうまくいくかわからない事業をやることそのものに価値があります。
「誰からみてもうまくいくに決まってる」事業で金も人材も潤沢にある大企業と張り合うのは、少なくとも現代では難しいでしょう。
そして、ゆえにスタートアッププロダクトのコード設計は壊れます。これは構造的問題なのでカネで解決することは不可能です。
DDDを適用すべきじゃない、みたいなことを筆者が主張しているのもこれが原因です。
プロダクトを一分一秒でも早くリリースしたい
それともお前
何十年も修行して達人にでもなるのを待ってから戦場に出るつもりか？
気の長げェ話だな
みなさんは綺麗な、あるいは良い設計を定義できますか？
「私が上手に読めないのでこれは汚いです」「複雑な構造になっているので悪いです」
こんな風に考えている人はいませんか。
良い設計とは「プロダクトの本質的な複雑さが正しく反映されている」ことだと私は考えています。"正しく"、は必要なぶんだけ、と言い換えてもいいかもしれません。
さて、ではそのプロダクトの本質とやらはどうやって見出せばよいのでしょうか？ドメインマスター呼ぶ？屏風から出す？
貴方が作ろうとしているプロダクトは世界に前例がない、あるのは脳内のボンヤリした勝ち筋だけ。正解をどう定義する？グズグズしてたらライバルがイケてるやつ出しちゃうかも、もしかしたらGoogleが無料で似たようなものを出して焼畑しかけてくるかも、MicrosoftがカタログスペックだけのモックをリリースしてOfficeにバントルしてくるかも！！！
せや、さっさとベータ版をリリースしてユーザーの反応みればいいじゃん！
つまり
- 正しいかどうかもわからないものを
- とにかく最小手でリリースして素早く失敗して
- ユーザーのフィードバックから改善を繰り返す
というのがスタートアップの定番パターンです（もちろん例外も沢山ありますが）。
超天才なら最初から正解がわかるから未来の最適解アーキテクチャでしっかり作り込めるぜ……そう考えていた時期がオレにもありました。
もうね、↑の3ステップでこの記事で言いたいことおわっちゃった。
アーキテクチャを考えるのが得意なプログラマーを雇用*1できれば失敗の数を減らしたり、より多くの改善に耐えうる冗長性をもった設計を初手で行えるとはおもいますが、やはり無限の改善サイクルに耐えうる設計を人類が行うのは不可能で半年も経つころには技術的負債が山積みになります。
技術的負債が蓄積……？負債が蓄積するとはどういうことでしょうか？
ある程度軌道にのったプロダクトをスケールさせたい！！！
破産すれば負債は爆発四散します。
無になっていないということは、貴方のプロダクトはユーザーを無事に獲得して成長中です。
開発のフェーズも変わってきます。
最初期はとにかくリリースと仮説検証が重視されていましたが、サーバーの安定性、負荷対策、スケーラビリティ……UIもオシャレに使いやすく、離脱やCSコストを減らしたい……
えっ、無限の改修作業でぐっちゃぐちゃになったアーキテクチャのままマイクロサービス化！？
だいたいこの辺で会社が拡大して新規メンバーを雇用します。クソ設計（に見えるけど初期は最善手だったもの）を現代的にしようと苦心する新規メンバーとか、スケーリングフェーズの技術セットに微妙に疎い戦闘民族系古参メンバーとの軋轢、文化的断絶、その辺が理由で組織が崩壊しはじめるのがこの辺です。
当たり前ですが「さっさとリリースして失敗して失敗だったら簡単に捨てられる設計」は大抵の場合において「安定性が高くてスケールする設計」と大いにコンフリクトします。
「誰もが140字制限で書き込める、ゆる〜く繋がるSNS！」の初期設計に「極東の変な国が毎年年末になるたび全員一斉に滅びの呪文を唱える」耐障害性を加えようと画策する天才がいたらそいつはクビにしないといけません。
初期は簡単だとおもって軽視していた部分が、あとから実はとっっっっても重要で複雑なドメインであったことが発覚するのはまれによくあることです。
つまり、
「正しく開発したスタートアッププロダクトの初期設計は、正しく成長した未来からは壊れた設計にみえてしまう」
ということです。
誇っていい成果ってこと。
まとめ
スタートアップは……
- 仮説検証、そして陳腐化を防ぐために一分一秒でも早くリリースしなければならない
- 高速で失敗を繰り返す必要がある
- 改善を繰り返すたび、コードは壊れていく
スタートアップが成長すると……
- 仮説検証と高速失敗改善サイクルはある程度落ち着く
- 安定性やスケーラビリティが求められるようになる
- 結果、零戦みたいでかっこよかったはずの高速軌道重視設計が時代遅れのポンコツ扱いされてしまう
- 初期メンは悲しくて泣いちゃう
つらいね。
お金である程度の苦しみを緩和することはできる……かもしれません。
しかしこの問題を解決できる人材はただでさえ困難なスタートアップ採用において
- 事業立ち上げに精通した叩き上げのベテランソルジャー
- スケーリングフェーズにも詳しい
- 両方の要件を吸収した設計を書き上げられる
人間を探すということで、それだけで奥多摩でフェアリーを探すような大事業になることは間違い無いです。
仮にそんなUMAが実在していたとして、探して雇用する手間と金があれば既存メンバーの優遇や初期開発のブーストにリソースを割こうね、ってなるので絵に描いた餅みたいなもんでしょう。
補足
スタータッポ界隈で好まれるレトリックに「きれいだけど動かないコード、汚いけど動くコード」という非実在事象がありますが、私はあまり好きではありません。
最初に書いた通り、プロダクトコードのきれいさというのは問題の複雑さを正しく反映しているかどうかです。
動かないコードは問題を反映していないゴミです。ゴミを「きれい」だと定義することはできません。
汚いけど動くコードは成立可能ですが、意味のある規模のコードにおいて汚い（=無意味な複雑性を持ち込んでいる）コードはバグの温床であり、それを「動く」と形容していいのかは甚だ疑問です。
今回は意図的に「表面的な動作上の仕様を満たしてるだけのハチャメチャなコードしか書けない」プログラマーの存在を排除して執筆しています。
これはそういうババの存在を前提にすると議論が発散して意味をなさなくなってしまうからです。
型検査のエラーをまともに直せないとか、コピペでしかコードを書けないから仕様を読んで自分でロジックを組めないとか、そういった最低レベルの諸問題については予算と慎重な雇用計画で未然に防ぐことが可能です*2。
メン募
そんなわけで立ち上げからそろそろ2年目に差し掛かる弊社の事業は開発者を絶賛募集中です。
ぼちぼち、今回記事にしたような問題が表面化してくる時期になります。
「興味あるし話だけでもきいてみようかな」「スケーリング有識者だしちょっと面倒見てやろうかな！」そんな猛者たちは公式ページの問い合わせやら僕へのメッセージやら（ボーッと生きてるので反応がちょっと遅いかもしれません）で気軽にメッセージしてみてください。
以上。
