📚

フクロトジ開発チームが遂げた成長と伸びしろ

1 min read

Zenn初記事です🎉

みなさんフクロトジというサービスはご存知でしょうか。
18禁でアダルトジャンルのSNSです。

最近はこちらをリリースしました! https://note.com/fukurotoji_r18/n/nac9d35f87cc8

僕は大学の友人経由で太田社長と知り合い、サーバーサイドエンジニアとして初期からフクロトジの開発に携わらせていただいています。

今年6月末にローンチしたフクロトジは、3月ごろから開発スタートしました。創業したてのスタートアップのゼロイチなので金銭的なリソース、エンジニアのリソースも限られた中での開発は大変です。夜にゆくっり寝てられない日だってあります。

今回はそんな状況下でぶつかってきた壁と、僕らがどう対処して成長してきたのかをなぐり書きしてみます。

壁① 質を追求すると開発が遅れ、速さだけだと後々辛い

事象

  • この処理はどのクラスでやるべき?
  • 責務分担できてる?
  • もっと共通化できない?
  • テーブル本当に構成これでいいの?

長期的な視点で設計、実装することは当然ながらとても大切で、僕らエンジニアの力の見せ所でもあります。
しかし、特にスタートアップでは形あるものを早く作ることの優先度が高くなるケースが多く、じっくりと設計に時間をかけれないケースは多いですよね。(よく考えられた設計でスピーディーにできれば問題ないしそれが望ましいが、時間がかかってしまうのは僕の経験不足。)

どう対応したか
おそらく僕らエンジニアが常々向き合っていくこととなる課題でしょう。一定のレベルは求めつつも、状況によってはどういう点はしょうがなく妥協する、などのさじ加減を経験を積むとともに掴んでいくのだと思います。僕らの場合は本当に最低限ではありますが、以下の決め事をしました。

  • テストコードを書くこと
  • コードレビューをすること
  • リンターのチェックをすること

フクロトジのサーバーサイドはRailsを使っているのでテストはRspecで、リンターにはRubocopを使っています。(技術スタックやらも残りのadventで書いてみるか...)

また僕個人で意識していることとしては、自分の中では60点くらいの内容でも一度仕様を満たすところまで作り上げてしまい、ある程度時間の余裕を持って80点以上のコードに仕上げていくようにしています。このやり方だとある程度早い段階で形はできるので、クライアントサイドのエンジニアや企画側の人にとっても仕事が進めやすいはず。

壁② あやふやな仕様で開発が進んでしまい、仕様が詰まった時の出戻りが大きくリリースが伸びる

事象
大きめの機能開発をする際に、企画側との認識合わせが不足した状態でエンジニアの想定である程度作り込んでしまうことがありました。結果的にはリリース予定の直前に改めて仕様を確認すると、開発側と認識の相違があることが判明し、修正のためリリース延期になってしまいました。

どう対応したか
着手前にエンジニアと企画側で認識合わせをして仕様を詰め、その後も密にコミュニケーションを取る。先月から厳密にアジャイルを導入したので、それも追い風になって現在絶賛改善中です。

以上

という感じで、特に向き合うのが大変だったこと、そして改善すればもっと良い開発チームになる伸び代となる事柄をピックアップして書いてみました。(実際にはもっとたくさんの壁にぶつかったけど、文章書くのに疲れてきたので今晩はここまでで。。)

お読みいただきありがとうございました!

Discussion

ログインするとコメントできます