メガベンチャーからスタートアップに転職して、生産性の爆上がりを実感した話

1,000人超のメガベンチャーから、20数名のスタートアップ（エンジニアチームも10名未満）に転職しましたが、生産性・スピード感は大きく向上したなと感じています。
その要因は何なのか、今後さらに生産性を向上していくために何が必要なのか考察してみました。

比較対象のプロジェクトでの生産性の差

いずれの会社でも、リアーキ（リニューアル）プロジェクトを実施しました。
私はいずれもほぼフロントエンドメインで担当しており、フロント部分の規模感は同程度です。
フロント部分でかかった工数としては以下になります。

• メガベンチャー
  • 10ヶ月 * 3名
  • 30人月
• Fivot
  • 7ヶ月 * 2名
  • 14人月

規模感や要員数などは精緻なものではありませんが、体感としても倍くらい違う感覚があります。

生産性に違いが生まれた要因

大きくは開発時間が増えたことと、コーディングスピードが上がったことです。

（集中して行える）開発時間が1.5倍以上増えた

以下のような要因から、前職と比べ開発時間を確保できるようになってます。

• 会議が少ない、短い
• 仕様や方針が決まるのが速い
• リモート頻度が高い（週3出社→週1出社）
• ペアプロやモブプロをやりすぎない
• テストを書き過ぎない、やりすぎない

会議が少ない、短い

前職と比べて会議量が減ってる要因としては、マネジメントやチーム運営をしっかりし過ぎないことと、チームメンバーが多すぎない（絞っている）ことと捉えてます。
前職ではスクラムを割としっかり行っていたのですが、プランニングで１日が潰れることはざらにあり、１つのストーリーポイントを決めるのに1時間かかるようなこともありました。
そこまで時間がかかる要因としては、チームメンバーの多さ（10数名）も大きいと考えてました。

Fivotでは入社当時、スプリントの概念もありませんでしたが、最低限やろうと提案しプランニングは導入されました。
ストーリーポイントは個々で入れるに留めるなど、1時間程度で終われるようにしています。
また、チームを細分化し、１チーム（１つの会議）の人数が肥大化しないようにすることで、短い時間でも質が高めようと意識しています。

正直、スクラムをしっかりやることの費用対効果は良くないと考えており、開発時間をしっかり確保して生産性向上にフォーカスする方が会社の成長に寄与していると思います。

仕様や方針が決まるのが速い

前職では仕様や方針が中々決まりませんでした。
フロント・バックエンド双方が絡むものや、他チームが絡むようなものは場合によっては難航することが多くありました。
メンバー数、組織の大きさに起因するものですが、意思決定者が曖昧になっていたのが問題だったと考えてます。
あらゆる意思決定をメンバー全員を巻き込んで行っていたため、まとまりが非常に悪くなっていました。
チーム間の方針はリーダー間で決定するなど、大きな組織であれば意思決定のプロセスを整備する必要があると感じています。

リモート頻度が高い（週３出社→週１出社）

昨今、出社回帰が流行っていますが、週３出社から週１出社になったことで生産性は明らかに上がりました。
自走できるスキルとマインドがあることが前提にはなりますが、リモートの方が（無理なく）稼働できる時間は増えますし、集中して作業が行えます。
一方、出社効果はあると思っており（特に参加く間もない時など）、週1出社が適切に思います。

コーディングスピードの向上

• AIの進化
• ライブラリ選定や実装方針の成功

AIの進化

生成AIの進化は、生産性向上に大きく寄与しています。
現在進行形で急速に進化しているので、最大限享受できるよう、CursorやDevinの導入をスピード感を持って行っています。

ライブラリ選定や実装方針

こちらの取り組みは概ね上手くいったと思います。
前職よりストレスなくコーディングができており、無駄が少なく生産性の高いコードにできているなと実感しています。

スピード重視のマインド

前職は一定成功を収めたメガベンチャーだったこともあり、チーム内でスピード感を持って開発するマインドが低かったように感じます。
結果として、会議の長さや意思決定の遅さが大きな問題とされず、個々の納得感や安全性を重視する形にになっていました。
このマインド差が違いを生んでいる一番の要因と思います。

高い生産性を維持する、向上させていくために必要なこと

以下のようなことをチェックする必要があると考えています。

• スピード重視のマインドを高める
  • valueに掲げ浸透させる
  • 評価対象とする
  • スピード重視に共感できるメンバーを採用する
• 極力少数精鋭にする
  • 人数が増えた場合はチームを分けるなどし、大所帯にならない工夫をする
  • 組織が大きくなった場合、意思決定のプロセスを整備する
• AIの進化に追従する
  • AIの進化にアンテナを貼り、可能性のある新規技術を試す
• コードを腐らせない
  • 定期的なリファクタリング
  • ライブラリアップデート、新機能の導入を定期的に行う

最後に

スピード感ある開発を求めて転職しましたが、想像以上に生産できエンジニアとしてやりがいを感じています。
今後、組織が大きくなることで、組織としての生産性向上も意識しつつ、一人当たりの生産性感が下がらないように心がけたいと考えています。