最近、新規事業に携わる機会があったけれど、最近つくづく思うことがある。
新規事業の初期段階で 「事業構造がこうだから、チームやシステムもこうあるべきだ」と最初から綺麗に最適化しすぎると、高確率で将来の負債になる ということだ。
変わらない新規事業なんてない
当然なのだけど、新規事業の立ち上げ期に提案される「事業の方向性」や「事業の目的」や「満たすべき要件」は、時間が経てば往々にして変わる。特にリサーチしたらこれは売れないからピボットするなんてこともザラだ。変わるのが当たり前だ。だけど、自分もチームメンバーもこれに関して盲目だった（いや、気づいていて言わなかった人もいたかもだけど）
最初の想定に合わせて最適化した設計（アーキテクチャ）を作ってしまうと、事業のゴールや目的がシフトした瞬間に、その設計は一気に破綻する。
結果として残るのは、意味をなさなくなった複雑な仕組みと、ただの「負債」だけ。その後は、変化に合わせて矢継ぎ早な実装や場当たり的な設計変更でなんとか凌ごうとするものの、チームはただただ疲弊していく……。で退職者増加。そんな光景に、これまで何度も出くわしてきた。
「早すぎる最適化は諸悪の根源」
コンピュータサイエンスの世界には、ドナルド・クヌース氏の有名な格言があるらしい。
「早すぎる最適化は諸悪の根源である（Premature optimization is the root of all evil）」
https://qiita.com/shuetsu@github/items/95370b6c208901db3a5e
これは一般的にプログラムのソースコード（実装レベル）の話として語られることが多い気がしてるが、もっと広い目線、つまり 「システム全体の設計（アーキテクチャ）」においても完全に同じことが言えると痛感している。
GraphQLの導入で起きた悲劇
うちのケースが、まさにそれだった。
当時、バックエンドのシステムがいくつかあって、これから新規事業が次々と立ち上がる予定だった。クライアント（アプリやフロントエンド）が乱立することを見越し、「クライアント側が1つのエンドポイントから効率よくバックエンドのリソースを取得できるようにしよう」と考えて、GraphQLを採用した。
設計としては非常にスマートで、一見すると未来を見据えた「最適な設計」だと思ってた。シニアのリーダーも、自分もそう思ってた。
だけど、蓋を開けてみると、最終的に想定していたほど新規事業は立ち上がらなかった。結果、GraphQLの高い学習コストによるチームへの浸透の難しさ、そして横展開されないGraphQLの運用のメンテナンスコストだけが重くのしかかり、気づけばチーム内に「GraphQLをまともに扱える人がほとんどいない」という、なんとも悲しい状況が生まれてしまった。
（GraphQLは何も悪くない。確かに学習コストは高い部類になると思うし、RESTに慣れてる人からしたらパラダイム・シフトと言っても良いレベルの再学習が必要だと思うが、それでもきれいな設計に慣れば、フロントエンド側が綺麗になる…と思う）
これはなかなかに辛い経験。結局、途中まで全部署導入を考えていたGraphQLは導入を取りやめ、RESTに戻すことになった。
さいごに
未来の不確実な成長を予測して、最初から「完璧で最適なシステム」を作ろうとすることは、新規事業においては麻薬のようなものだと思う。プログラムのコードだけでなく、システム設計、ひいては組織設計においても「早すぎる最適化」は牙を向く。（←AIが書いた締め括りだけど、ちょっとかっこいい）