前提
後ろ向きな退職なので、書けそうなことだけです。
ログ的な雑記です。
謝辞
超絶面倒臭い私と一緒に仕事してくれたメンバーには感謝しかありません。
ベンチャー企業の最重要課題、会社をつぶさないを継続していることには、敬意しかありません。
会社変遷
うろ覚え、多少のズレはある
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が入る
参考: ＧＩＶＥ ＆ ＴＡＫＥ「与える人」こそ成功する時代
採用
高給で良い人なんてほとんど入ってこない
(良い)人はすぐに採用できない
半年先まで見据えて準備が大事
育成前提で考えた方が良い
成長性さえ感じられれば、半年もすれば大体メインになれる
コミュニケーション
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には感謝しております。