れっぽんブログ

「渋谷ではたらく社長の告白」を読んで自分もできると思って代表と一緒に起業!→全く事業が当たらず、とはいえ投資家や顧客をはじめ多くの人を巻き込んだので、なんとか成果を出したいともがく日々を綴ります。

6/13<枯れた技術の良さ/フロントエンド・バックエンドを分ける利点・欠点>

枯れた技術の良さ

スタートアップ始めた時にどうせやるなら新しい技術を使おうと思って、初期のプロダクトは以下の技術構成になっていた(2019年時点)

---

フロント:React

API:GraphQL

バックエンド:Lambda(言語はnode.js) *フルサーバレス

---

結構モダンだったし、個人的にも新しい技術を学べると大満足だったんだが、今思うと悪い意思決定だった。

なぜならば出来て当然ということに対して、色々なものが確立されておらず調べるのに時間がかかってしまいスピード感が出ないことが多々あったのだ。

例えばGraphQLは画像のアップロード1つとっても当時は確固としたやり方がない上に、技術情報もほとんど掲載されておらず実装するのに3-4日ほど普通にかかった。

あとはAWS Amplifyを利用しており認証がCognitoだったのだが、これもはっきり言って癖が強くて使いにくかった。(あとなぜかfacebook 認証ができるはずだったのに全然できず微妙だった)

とはいえ上記の構成でやっていたので、ぶっちゃけコードを書くところが、GraphQLのデータ定義やデータ取得の定義とメール送る時ぐらいしかなく、バックエンドは楽だったので工数としてはプラマイはゼロでだったのだが、当たり前のことが出来ない怖さはこの時にすごく感じた。

 

すぐに次のプロダクト開発にシフトしたため全然反省が出来ていなかったんだが、

下記のポッドキャストを聞いて改めてあの調べる時間って無駄だったよねと反省した。

open.spotify.com

 

プロダクトの性質にもよるが、新しい技術がもたらすメリットを理解した上でそれが大きくプロダクト開発に影響しないなら、今後は枯れた技術を使う方向でやっていきたいと思っている。

 

フロントエンド・バックエンドを分ける利点・欠点

先ほどの反省と被るんだが、フロントエンド・バックエンドに最初から分けたのも本当にそうすべきだったのか迷う部分ではある。

SPAのようなリッチなフロントエンドの動きを初期から求めていたかというとそうではなく、自分がCSSやHTMLを書くのがめんどくさいから誰かにやってもらいたくて、フロントとバックエンドを切り分けたんだと思う。

しかもなぜかデータの取得が遅く、ページの切り替わりにも時間がかかったこともあり、ユーザーにボタン連打されて不正データが入ったのも懐かしい思い出w

この時SPAはボタンを押した感覚をユーザーに理解させづらいと思った。

 

話が脱線したが、フロントエンド・バックエンドを分ける利点ってなんだろうと改めて調べた時に以下の記事があった。

qiita.com

(引用)

メリットとしては以下の3つが挙げられます。
1:バックエンドが簡潔になり、再利用性が高まる
2:フロントエンドとバックエンドを別チーム/並行で開発できる
3:フロントエンド/バックエンドがそれぞれリリースでき、リリースが簡単になる

---

これをスタートアップの0-1開発である前提の場合どうなのかと考えてみると

1の「再利用性」に関しては、そもそもヒットするか分からないので再利用に関しては先の話であり、開発段階では優先度低い。

2の「別チーム/並行で開発できる」はメリットであるが、モノリシックな状態でも機能や画面別に担当を振り分ければ並行開発はできる。

3の「リリースが簡単になる」もプロダクト改善のスピードを上げるための1要素でしかないため、初期のスタートアップには不要(他にも改善速度をあげる施策はある)

 

と考えると大きめのチーム開発をせず、まずは1人2人で作り切るならモノリシックにフロント、バックエンドを分けない開発もありだとは思う。

そしてプロダクトがヒットし、チームが拡大していく段階で分けていけばいいのだと思う。