最初のロンチ時点で長く使えるシステムを作りたい、と思う。
スタートアップだから
時間がないから
お金がないから
「とりあえず」のやっつけ対応で後のことは後の人に任せる。
人も金も無いベンチャーはそうしなきゃ勝てない。凄く分かる。
スタートが凄く大事だ。知名度を得るためにも、資金を調達するためにも。
けど、だからといって一年後に絶対止まるようなリスクを持ったシステムを作って、リスクを共有せずに後継の人に引き継いで、最初に作ったメンバーはごっそり抜けて、他の事業をやっていて「あとよろしく」って。
それが本当に健全なのか凄く疑問に思うようになった。
また、それを「健全だ」と言えないとベンチャーでやっていくのに向いてないのかも知れない、とも思った。
或いは職業エンジニアとしても向いていないのでは、とも思って最近凄く悩むようになった。
データで探る2012年度のIT戦略 - 基幹系の寿命は14.6年に、大規模プロジェクトの3割強で予算超過：ITpro
あるシステムの寿命がどのくらいかなんて誰にもわからない。
半年ぐらいで役目を終えるかも知れないし、１０年経ってもベースがそのまま使われるかも知れない。
でも、だからといって１年後にめちゃくちゃreadが遅くなるのが目に見ているテーブル設計や、データファイルがディスクを食い尽くしてクリティカルな機能が止まり、全システムが突然止まるようなことが目に見えているようなものを作って、そのリスクを一切共有しない。回避策も考えない。
それが本当に正しいのか。
いくら早くサービスを作ってリリースして高い収益を上げられたとしても、後継のエンジニアを不幸にするようなシステムを作ってはいけない。
ユーザーに不快感と迷惑を与えるようなサービスを作っちゃいけない。
いつか会社を不幸にするようなサービスを作っちゃいけない。
最初からユーザーがどこかで増えても簡単には落ちないシステムを最初から設計すべきだ。
いくらAWSを使ってインフラをスケールできるようにしても、根本の設計が間違っていたらいくらインスタンスに投資しても足りない。
ここは実装クラスを差し替えられるようにインターフェース作って抽象化しとくか、実装がばらつかないように早い段階でサンプルを作っておくか、ログは定期バックアップを取るかfluentでどっかに集めてAPサーバのディスクサイズが一定以上超えないようになっているか、使っているミドルウェアのデータファイル増加ペースはこんなもんで、Nagiosで監視する項目はコレで十分か、とかのノウハウ。
沢山貯めて、最初からユーザーが想定の倍以上増えても、スケールする時に全くビビリ必要がない設計のシステムを作って、安定したサービス運用ができるようにしたい。
エンジニアとして、この辺のことを全部把握できるようになりたい。
インフラは相変わらず苦手だが、一つのライブラリのようにミドルウェアをサービスベースで使えるようになった時代なので、それらを活用したシステム設計を身に付けていきたい。
いつか自分が仕事で新しいサービスをゼロから作ることになった時、出来る限りの人を不幸にさせないサービスを作りたいと思う。
