ベンチャー企業に4年居て、やってみたこと・感想

# 前提
後ろ向きな退職なので、書けそうなことだけです。
ログ的な雑記です。

---

# 謝辞
超絶面倒臭い私と一緒に仕事してくれたメンバーには感謝しかありません。
ベンチャー企業の最重要課題、`会社をつぶさない`を継続していることには、敬意しかありません。

---

# 会社変遷
うろ覚え、多少のズレはある

## 1年目 
* 人数: 約10名
* モチベ: 高

## 2年目
* 資金調達1回目
* 人数: 約10名
* モチベ: 高->最低

## 3年目 
* 資金調達2回目
* 人数: 約40名
* モチベ: 最低->中->高->中

## 4年目
* 人数: 約40名
* モチベ: 中->最低

---

# やってみたこと
## 月1回の読んだ本LT(2分): `良かった`
### ルール
* 発表は2分
* 読んだことのある本でもスライドでも良い。
* 重複OK
* できるだけスライド用意

### メリット
本を読む機会が減っているので、こういった外的圧力により学習機会が増える
普段関わりの少ない人たちとも少しだけ交流できる
`INPUT -> OUTPUT`の癖づけ
LT(発表)の練習にもなる
要約する力が付く
本の読み方も学べる

### デメリット
継続が大変なので、言い出しっぺが熱量出して継続する必要がある(私は月1回開催が継続限界)



## 週１の1日meet繋ぎっぱなしday: `良かった`
### メリット
どうでも良い雑談が発生する
軽い質問がしやすい
質問内容を他のメンバーも聞いてることがリアルタイム共有になる

### デメリット
ずっと繋いでいるのが嫌なメンバーには辛い



## 朝会(長時間): `良かった`
### メリット
フルリモートだったので、コミュニケーションを増やす場になる
困っていること・相談事項・共有事項の3点を毎日やってたので、これがリアルタイム情報共有になる
タスクの相対見積もりもしっかりと説明・質問の時間を作ることで、これもリアルタイム情報共有になる


### デメリット
60-90分もまま発生
5-15分が王道なので、真逆のことをする
長いMTGが嫌いな(自分の作業がしたい)人には向かない


## タスクの相対見積もり: `良かった`
### メリット
誰もがタスクについてある程度把握しているので、PRレビューが早くなった
メイン担当が休みでも大体すぐにカバーできる
進め方について事前に確認できる


### デメリット
朝会が長くなる
スプリントプランニングが機能してないと、ただ`やるだけ`になる
ちゃんと運用しないと形骸化する


## 新規メンバーや面談者に対する自己紹介: `良かった`
なんで、`新規メンバーや面談者が自己紹介するだけなの？`という疑問から始めた。
みんなが対等であり、`古株おじさんこそ自己紹介しろよ`という思いもあった。
評判は上々。(のはず)

### メリット
面談者との面談でのフランクな会話がしやすくなる(はず)
良い印象を持ってもらいやすい(はず)
自分と合う・合わないを判断してもらいやすい(はず)

### デメリット
作るの大変
どれだけ自分を出せるかも大変
メンテが必要


## 面談内容のテンプレ化: `良かった`
とりあえず退職するので当面使わなそうだが、使う時に対策されてもいやなので、非公開。(そのうち公開するかも)
このオリジナル面談は、割と好評でした。(のはず)

### 概要

* 時間は90分(自分の自己紹介含む)
* プログラム書いてくれとかは無し
* 現在のスキル確認と成長性の確認
* 素直さ
* 面白さ
* ユニークさ
* 配慮
* チームのフィット具合
* MVVのフィット具合(やりませんでしたが)

### メリット
テンプレ化(項目化)することで、同じ指標で判断できる
`人`の部分について聞くので、お互いにフィット具合が判断できる
面談結果を報告するときにも、報告しやすい

### デメリット
大変（でも超大事）


## インフラクラウド化: `良かった`
AWSの導入支援チームには今でも感謝しています。

### メリット
サーバーのミドルウェアアップデートを気にしない
ログなどのハードディスク容量も気にしない
アプリケーションのメンテに専念できる
人数が少なくて良い

### デメリット
インフラメンバーいないと構築するのが超絶大変(AWS/Lv1の私は2ヶ月かかりました)



## dev,stg,prdリポジトリを作らない運用: `良かった`
メインブランチは`main`のみ
すぐにマージ出来ないものは、`feature/xxx`で作る
mainにマージされたら、stg環境に自動デプロイ。prd環境にはビルド完了まで。(デプロイするときは手動承認)

### メリット
dev,stg,prdブランチに対するPRを何回も作る必要がない


### デメリット
一般的ではない
新規メンバーの理解が少し大変
このやり方が合わないプロダクトも当然ある


## PRテンプレート作成: `良かった`
### メリット
ついつい忘れがちな、マルチブラウザ確認などに意識がむく
必要な情報の記載漏れが減る
PRレビューコスト減

### デメリット
常にアップデートを意識する必要がある
簡単な修正でも、マルチブラウザ確認などに意識がむくことで、微妙にストレス(必要なストレスだけども)



## コミットを綺麗に作る: `良かった`
前の現場で教えてもらった
1つの目的で1コミットを意識する

### メリット
`revert` `cherry-pick` が簡単
PRレビューがしやすい
複数の目的を持ったPRが判断しやすい
バグがあった時の調査もやりやすい

### デメリット
教育コストが高い
慣れてない人への説明が大変
コミットが小さすぎると、レビューがちょっと面倒



## `git rebase` 文化: `良かった`
前の現場で教えてもらった
`git merge` ではなく、 `git rebase` でコンフリクトを解消する

### メリット
`コンフリクト解消ミス`対象が自分のコミット(これからマージされるコミット/PRレビュー対象のコミット)になる
PRレビューするときに、`merge`コミットの内容が正しいかを意識する必要がない
mainブランチにマージされたときに、コミット履歴が綺麗

### デメリット
王道ではない(はず)
メリットを全然理解してもらえない(私の言語化・説明力不足)


## 集まったメンバーに合わせた言語・フレームワーク選定: `微妙`
### メリット
メンバーに合わせているので生産性はある程度担保される
ベンチャーにおいて資金(時間)はかなり貴重なので、間違ってはいないと思う

### デメリット
そのままサービスが大きくなると、この選択がそのまま負債になる


## スプリント振り返り(開発メンバーのみ): `微妙`
いくつかの改善はできた
長時間朝会で解決してしまうことが増えて、形骸化した
最後は`振り返りを止める`という改善で終わった


## SEOに注力する方針: `悪かった`
### メリット
流入数は増える
認知は向上する
数字上、良いサービスに見える

### デメリット
ユーザーに提供する価値(コンテンツ)に時間を使えない
自分たちの強みが`認知`により真似されるので、強みで無くなる


## 中途半端なスクラム導入(カンバン管理): `悪かった`
いきなり1から10までキッチリ導入するのには抵抗があった
徐々に慣れていけば良いかと思っていた
メンバーの理解がなければ機能しない
TODOリスト的なタスク管理がダメな人もいる
スクラムマスターは超重要
POのスクラムへの理解も必須


---
# ここから感想

# プロダクト開発
## KPIとなる計測の仕組み
出来るだけ早い段階から想定して用意しておいた方が良い
GAデータとの連携など

## あとでやろう
やらない


## とりあえずやってみればいいじゃん
作って終わり
経過観察しない


## クロージング
しない
基本作りっぱなし
お掃除できない
もったいないとか言い出す



---
# 人事
## 人が足りない
ずっと足りない


## 人事担当者
超重要
良い人事担当が居ないと`taker`が入る
参考: [ＧＩＶＥ ＆ ＴＡＫＥ「与える人」こそ成功する時代](https://www.amazon.co.jp/dp/B00IRV39FM)


## 採用
高給で良い人なんてほとんど入ってこない
(良い)人はすぐに採用できない
半年先まで見据えて準備が大事
育成前提で考えた方が良い
成長性さえ感じられれば、半年もすれば大体メインになれる






---
# コミュニケーション
## slackのコミュニケーション活性化ツール
続かない
飽きる


## 朝会でのローテLT
基本続かない
言い出しっぺはほぼやらない
やりたくない人多数


## チーム(会社)の用語集
作った方が良い
新しい人が入った時に、チーム(会社)のローカル用語の理解が地味に大変
同じものを指すときの`揺れ`もやめた方がよい
会話する度に、脳内での`翻訳`ストレスはバカにできない


## たまに出社(東京出張)すること
新鮮で良い
飲みに行こうともなりやすい
お土産選びは楽しい
行く度に事務所の場所が変わるのも面白かった


## 困ってることないですか？
結構効果的
エンジニアは怖いと思われがち
エンジニア以外のひとたちに声かけして、改善点を拾うのは効果的
大体何かある
エンジニアなら割と簡単に解決してあげられることが多い


## デザイナーさんとの連携
html/css知らないでレスポンシブデザインしようとする
何が`作りづらい`かがわからない
html/cssでやりづらいこと、コンポーネントとは？から話を聞いてくれるかが重要
フォント・カラーバリエーションの共通ルール化も大事
比率で拡大したいのか？固定値で表示したいのか？の確認も大事
とにかくコミュニケーションで生産性は大きく変わる
デザインについて確認すると `実は・・・` `ここだけ・・・` みたいなことはよくある
アニメーションとかも、早めにヒアリングして`出来る・出来ない・コストかかる`は伝えた方が良い


## 説明
自分の意見を`説明`できるメンバーを集めた方が良い
`説明`できない・疎かにする人が多い





---
# エンジニアチーム環境
## チームビルディング
フルリモートでも意外となんとかなる
コミュニケーションの機会をどれだけ作れるかが重要
朝会１時間も実は結構効果ある
タスクの見積もりも重要
週1の1日meet繋ぎっぱなしdayはよかった
どうでも良い雑談は大事
LGTM画像のおもしろさも大事
ペアプロも良い


## アプリケーションのローカル単独実行可能環境
システム要件次第ではあるが、ローカル実行する時に、あれもこれも起動みたいな状況を避けることはかなり意識した
dockerで全て解決じゃん。は間違ってないけどdokcer結構重い。。。


## pull request
テンプレート作るの大事
スクショ貼り付けは必要だと思うときだけ


## pull request レビュー
うちのメンバーしっかりやってるし、大体問題ないでしょって思えたから、チームビルディングちゃんとできた気がする


## CD環境
超重要
デプロイのしやすさは生産性に直結する


## インフラ
* ドメイン取得・管理は未来を見据えて決めた方が良い
    * 移行が地味に苦痛(怖い)
* メールも同じ
    * Gsuite移行とか結構苦痛(怖い)
* サーバーも未来を見据えて、多少高いけどAWS・GCP・Azureとかにした方が良い
    * 安いからレンタルサーバーとかだと、移行が地味に苦痛
    * 移行しないと管理が更に苦痛
* 技術サポートは契約しておいた方がよい
    * インフラ知識少なくても、結構しっかりサポートしてくれる


---
# 教育
## 1on1
あまり重要性を感じずやらなかった
個人目標設定などもやらなかった
お金が稼げれば良いと思う人もいる

## IDEカスタム
* カスタムできない人が多い
* IDE戦争はしないけど、Intellij派なのでいつも勧めた

## git操作
* 主にrebase
* revert
* cherry-pick

## コミット作成単位
* 1つの目的で1コミット

## ガード節
* 割と知らない人が多い

## Unitテスト
* 全然やらなかったけど、やった方が良い。
* コードのクオリティに雲泥の差が出る

## ネーミング
* 自分から相談をして、相談しやすい雰囲気を作る

## タスクを自分で拾いにいく姿勢
* 要件をちゃんと詰める手法・促し

## 自分が良いと思った記事の共有
* チャンネル作って投稿し続けた

## 失敗させる
* クリティカルにならないように注視

## 学習機会
月1回、有志で`読んできた本のLT(2分)`は、やってよかった
ペアプロも良い
タスク消化しながら時間を捻出した


---


いつもQiitaには感謝しております。