VISITS Technologiesでマネージャー兼バックエンドエンジニアをしている@ham0215です。

VISITSでは去年もアドベントカレンダーに参加していました。
https://qiita.com/advent-calendar/2019/visits

去年のアドベントカレンダーでは『スタートアップに転職して思ったこと』というタイトルで記事を書きましたが、更に1年経ったのでアップデート版を書こうと思います。

今回の記事も前回と同様で完全に私の主観です。
弊社を代表しているわけでも、ましてやスタートアップ全体を代弁しているわけでもないので一個人の意見として読んでいただけると幸いです

スタートアップに転職して思ったこと +1 year

技術選定の自由度は諸刃の剣

前回は「モダンなシステム構成で開発できる」や「技術選定の自由度が高い」と書きましたが、その考えは1年たった今も変わりません。
私の関わっているプロダクトの事例を話すと、REST APIで作られていたバックエンドの大半をGraphQLに置き換えたりしました。
また、RailsやReactなどのライブラリもほぼ最新にバージョンアップを保っています。
インフラも去年はAWSのEC2で動いていたのですが、今ではEKSで動いています。

ただ技術選定の自由度は諸刃の剣でもあると思います。
こちらも弊社の例を挙げると、フロントエンドにVue.jsを使っているプロダクトとReactを使っているプロダクトがありました。
最初、技術選定したエンジニアが開発しているうちは良いのですが、社内のエンジニアが少ないのでプロダクトを兼務することがあります。
その場合に技術スタックに差があると兼務が難しかったり、できたとしても使う言語が週次で変わったりすると脳内の切り替えコストが高くなり進捗が悪くなることがあります。
また長い目で見ると採用も難しくなってきます。
1つの言語ができるエンジニアと、複数の言語を実践レベルで習得しているエンジニアの数には雲泥の差があります。

このように技術選定の自由度は良い面もあれば悪い面もあります。
複数プロダクトを持っている場合はプロダクト間の親和性を考えたり、エンジニア採用を視野に入れて一般的な技術か？ということも考慮して技術選定するようにした方がよいでしょう。

相談相手がいない

スタートアップでは一つのプロダクトに関わっているエンジニアが少ない事が多いです。
私が担当しているプロダクトもフロントエンド・バックエンドエンジニがそれぞれ1、２名で開発しています。
社内全体でもエンジニア全体で１０名弱です。
そのため、例えば私の場合はバックエンドで相談したいことがあっても相談先がなく、１人で解決しないといけないことがよくあります。
（会社全体で見ると他にもバックエンドエンジニアがいるので技術的な相談は可能ですがプロダクトが絡む内容の相談だと難しくなります）

１人で解決することも出来ており、１人で意思決定ができるところが醍醐味だと言えばその通りなのですが、同じプロダクトを開発するメンバーとワイワイ相談しながら開発したいなーとたまに思ったりします。
（そして寂しくなってTwitterなどへのつぶやきが多くなりますｗ）

トラフィックが少ない

前職では月間数億を超えるトラフィックをさばく必要があったのでパフォーマンスに気をつけた実装が必須でした。
また、デプロイ時などに数分止まるだけでも売上への影響が巨大で基本的にはダウンタイムも許容できませんでした。

現状のプロダクトは前職に比べるとかなり少ないトラフィックのためパフォーマンスに気をつけなくても問題なく動くことが多いです。
このような状況では工数をかけてまでパフォーマンスのよい実装をするより、現状＋αのトラフィックが問題なくさばける実装をすれば良いと考えています。
（もちろん、ほぼ同じ工数でパフォーマンスの良い実装ができるのであればパフォーマンスを考慮した実装にするべきだと思います）

またデプロイときにダウンタイムが発生してしまうことがわかったとき、最初はダウンタイムが発生しない方法を考えると思います。
ただしダウンタイムしない実装をするためにはそれなりに工数がかかると分かったとき、実際のトラフィックを考慮してダウンタイムを許容するという判断もできると思います。

トラフィックが少ない場合は少ないなりの判断ができるので、それを考慮して判断をすると無駄な作り込み工数を削減できて工数を削減することができます。

開発フローのカスタマイズ

私のプロダクトではスクラム開発を採用しています。
ただしスクラム開発といってもスクラムマスターもいないし、レビューや振り返りなども最近までやっておらず、スクラムっぽいところはスプリント単位で進めているくらいでした。
スクラム開発に詳しい人に話したら怒られそうですが、私はこれでよいと思っています。
どういうことかというと、開発フローとは開発を円滑に進めるためのフレームワークだと思っています。
当初、プロダクトメンバーはエンジニア3名、PM1名、デザイナー1名でした。
人数も少ないし、それぞれが単独で滞りなく作業を進められていたので、スクラムイベントを端折っても問題なく開発をすすめることが出来ていました。
この状況なのでスクラムの形式通り様々なイベントをしても時間の無駄でしかありません。

現在はコロナの影響でフルリモートになったり、メンバーも入れ替わりして状況が変わってきているので振り返りをやるようにしたりなど、状況に合わせてカスタマイズしています。

開発フローは様々なところでノウハウが共有されており、それを学習するときちんとノウハウ通りに実行したくなります。
しかし、開発フローにチームを当てはめるのではなく、チームにあわせて開発フローを適切な形で当てはめていくほうがスムーズに開発を進められるようになります。

採用が難しい

前職は知名度のある企業だったため応募が多く、書類選考は毎日のようにやっていたし面接も週に数回やっていました。
一方、スタートアップは知名度が低いので社内ホームページや採用サイトの求人から応募があることは滅多にありません。
大体のスタートアップが同じだと思いますが、一番最初に力を入れるのはリファラル採用だと思います。
ただしリファラルには限りがあります。
そこで次に重要になるのは採用サイトなどを使ったスカウトだと思います。
スカウトをする場合、対象者の検索やその後のやり取り、面談などに工数がかかるのでそれを考慮して予定を立てるようにしています。

コアユーザーに親切に（やりすぎるとグロースがむずい）

Saasプロダクトを開発しているとグロースさせてより多くのユーザーに使ってもらうことが目標になると思います。
グロースさせるためには如何に人の力を使わずに自動で動くプロダクトにできるかが重要です。
人の作業が入っていたらそこがグロースのネックになるからです。

ただ、最初から完全に自動化されたプロダクトを作ることは困難なので、最初のうちはところどころ人力で動かす必要がある未成熟なプロダクトになることが多いです。
使っているユーザーからすると自動化されてそうなことでも、中では人が頑張って動かしていることが多々あるのです。
すでにグロースしているプロダクトに関わっている人がこのように人を介するプロダクトを見ると、こりゃダメだと拒否反応を起こしてしまいそうですが、私は必要悪だと思っています。
これを許容せず、最初から自動化された完璧なプロダクトを出すにはそれ相応の工数がかかります。
まだ当たるかわからないプロダクトを完璧な状態にしてからリリースするよりも途中に人力の箇所があったとしても早い段階でユーザーに当てて、プロダクトの可能性を探ったほうが良いからです。

ただし、必要『悪』と書いた通り、グロースさせるためには必ず解消しなければいけない課題なので最終的には人を介さずに動くシステムにする必要があります。

テレワークが早かった

コロナでテレワークになる企業が多かったと思います。
弊社も例外ではなく、今は職種によって違いますがエンジニアは現時点でもフルリモートで働いています。
ただ、コロナ前からリモート制度があったわけではなく毎日本社に出社していました。
制度や環境が全く整っていない状態のも関わらず、まだ緊急事態宣言の話も出ていない2月からフルリモートが始まりました。
このような柔軟性がスタートアップの強みだと思います。

最後に

最後まで読んでいただきありがとうございます！
スタートアップは良くも悪くも流動的であり内情も様々ですが、社会に何らかのインパクトを与えようとしてがんばっている点はどこも同じだと思います。
スタートアップが気になるけどよくわからないという方の参考に少しでもなれば幸いです。

明日は@ken_hikitaのパスワードマネージャーを比較してみた話しです。お楽しみに！！