ひとりスタートアップのサービス開発

久しぶりのブログ記事である。

新年ということもあり、初心に返る意味で今回はエンジニアひとりでサービス開発する際に意識しておくといいことがあるかもしれないポイントについて書いてみる。 

サービスデリバリを重視する

大抵のスタートアップは、クラウドサービスの形態（PaaS or SaaS)でサービスを世に出すことを前提とした場合、まず重視すべきは「動くものを、世に出す」ということである。

何を当たり前のことを、と言うべきところだが実際に動いて、それなりのUIを提供しそれなりのドキュメントを伴う形でローンチできるところまでは相当のエネルギーを要する。

まずは、最低限のクオリティ(MVP:Minimal Viable Product)を保ったプロダクトをスピーディに市場に出すことが何よりも最優先される。ここを意識することで、今やるべき事・やらない事の選択がシンプルになる。

Gitを使わない

チームで開発する場合はレポジトリが必須になるのは言うまでもないが、ひとりスタートアップには基本的にレポジトリ管理が必要ないと感じる。

私が採った方法は、ステージングサーバとプロダクションサーバを明確に分けプロダクション環境のコードは直接いじらずステージングサーバ上で改修を繰り返して、一定の動作確認が終わったらrsyncでコードごとプロダクションにコピーする方法だったが、シンプルかつプロダクションへの影響を最小限に抑える意味で有用なアプローチだと思う。

もちろん、Gitを使っても良いがシンプルな方法論としてrsync管理もありではないだろうか。

スケール前提の構成を組む

例えばSNSサービスを作るとして、最初からCDNやリッチなキャッシュサービス(redis or memcache)を使う必要はないとしても、マイクロサービス化できるところはないかを常に意識して構成を考えてほしい。

また、論理的に分割できる単位（ネットワーク/APP/DBなど）は可能な限りVM、コンテナなどで切り出しTCPベースのロードバランサでスケールできる構成にしておく事をオススメする。

サービスがスケールした場合にあなたを助けてくれると同時に顧客にとってもサクサク動くサービスはそれ自体が価値を生むだろう。

（あえて）マネージドサービスを使わない

ここは語弊がある点だが、マネージドサービス(RDS/CloudSQL）などは開発にリソース投下できる点でメリットが大きいが、当たるかわからない段階ではあえて使わない選択もありではないだろうか。

EC2/GCEインスタンスにミドルウェアを直接入れて、サービス成長の過程でマネージドサービスに移行すれば自らがconfファイルをいじりながらトラフィックの負荷に応じたチューニングや今後のアーキテクチャの方向性にも目を向ける事ができる。

また、今後AWS/GCP/Azureという選択がより難しくなる中でもプラットフォーマーに依存しないポータルブルなミドルウェア運用スキルというのは今後高まるのではないかと感じている。

まとめ

ここは私自身が場数を踏んでいるわけではないので（無い無い尽くしの状態での結果論）、今後も試行錯誤しながらやっていくんだろうと思う。

本年もよろしくお願いいたします。