どうも @shutooike です。
2023年のチームと個人のふりかえりをしたので学びを雑に残しておきます。
来年の自分忘れんなよ^_^
今年の挑戦
- 新たな開発チームの立ち上げ
- BE（バックエンド）とFE（フロントエンド）の分離
- 去年までは一人のエンジニアがBEもFEも開発していたが、今年からは完全に分業にした
- スクラムをちゃんとやる
- なんちゃってスクラムからの脱却
→全部できた 🎉
チームの学び
最もインパクトが大きかった変化
- 「チーム全員でスプリントゴールを達成する」という意識改革
- それまでは
- 「スプリントゴール、FEはいけそうです」「スプリントゴール僕はいけます」という会話になっていた
- 「これってBEとFEどっちの責任範囲なの？」という会話や悩みが度々行われていた
- 自分を守る方に意識が行きがち
- 主語が「自分」や「FE/BE」から「チーム」になってから悩みのレベルが一段上がった
- それまでは
開発
- FEとBEの分離はスピードが上がった
- VS Code の Live Share の体験が良すぎる
- ペア/モブプロはもちろんだが、特にリモートデバッグの体験が良い
- Terminal の権限まで貰ったら秒で終わる
- 開発環境の構築には時間を投資するべき
- その後の生産性に直結する
- 良くないソフトウェア設計は不具合やデグレを起こす
- 当たり前ではあるが実際に体験したので改めて書いておく
チーム作り
- チームビルディングは半年ぐらいかかる
- ここではタックマンモデルの統一期ぐらいまでのことを指している
- これぐらい掛かるという認識のもと焦らずじっくりやった方が良さそう
- 優秀なチームを作りたいなら、まず優秀な人を集める
- 「優秀な人を集める」ことは優秀なチームを作るための施策ではなく前提条件
- 元も子もないがここは妥協しない方が良い
- 適切な人数がめっちゃ大事
- 適切なエンジニアの数
- タスクを捻出するために時間を作っていたら見直すサイン
- 適切なデイリースクラムの参加者
- 適切なエンジニアの数
スクラムの浸透
- スクラムガイドの読み合わせは最強
- だいぶ時間がかかるがやってよかった
- スクラムガイドの読み合わせの時期
- スクラムの流れや哲学をざっくり掴み、やっていくうちになんとなく理解できつつも、もやもやが大きくなってきたぐらいがベスト
ふりかえり・カイゼン
- 人を責めるのではなくプロセス/仕組みを見直す
- 個人でKPTを書いてきて、発表するだけでは意味がない
- Good/Badを書いてきて、みんなでディスカッションする方法に変えた
- TRYなきふりかえりに意味はない
- デイリースクラム前にSlackでTRYのリマインドするのは良い
- TRYを促進するためのSlackのスタンプを作るのも良い
- ふりかえりは先週のTRYが実施した結果どうだったか？から始める
- TRYにも優先度をつけて絞る
- 多すぎたら結局どれにも手がつけられない
- 課題を課題のまま置いておくことも大事
- 全てを対処することはできない
- 課題としては認識しつつ、一旦は置いておくというのは案外いい
- スプリントごとにふりかえりをしっかりしてたら1年分もふりかえりやすい
- もっとその時の気持ちや雑談も書いていいよねと言う話にはなった
コラボレーション・心理的安全性
- 上手くいっていないことの原因は大体コミュニケーション
- 相手がわかってそうでも、疑ってかかるぐらい、くどいぐらいがちょうどいい
- その一手間をかけるかどうかで、手戻りの発生率が圧倒的に違う
- Yes/Noではなく、オープンクエスチョンで聞く
- Slackのハドルはめっちゃ便利
- チームのコラボレーションは Google Meet 全く使わなくなった
- ハドル中も通知来るようにだけしてくれ
- ペアレビューめっちゃ便利
- コメントで非同期レビューするより、ハドルで画面共有しながら同期レビューやった方が早いことが結構ある
- わからないことを共有しづらいことを理解する
- 特にSESは技術と時間をお金に変えるビジネスモデル
- わからないことをわからないと言いづらいのは当たり前だからこそ、何度も発信する必要がある
- 15分経ってもわからなかったら助けを求めるというチームルールはワークした
- すぐハドルする文化もうまく作用した
- 今年の後半にはチームのために一人で立ち止まってる訳にはいかないので助けを求めるというマインドセットになった
- 小さい違和感を共有できるチームは強い
ストーリーポイント・ベロシティ
- ストーリーポイントはタスクベースではなくストーリーベースでやると上手くいく
- 名前の通りである
- とはいえストーリーにならないタスクレベルのものもあるので柔軟に
- BEタスク、FEタスクと分けて細かく見積もるとしんどくなる
- 大きい数字（21）をつけたくなったらストーリーを分ける
- 再現性はないが、うちのチームではいいルールになった
- ベロシティの運用を2〜3週間しないだけで、サイズの認識がズレだす
- 1年で2回あって笑った
- 原理主義に陥らない
- 結局チームのキャパシティをいい感じに把握するための手段でしかないので気楽にやる
その他
- 優先度をつけることを妥協しない
- 上からの差し込みや不具合にも優先度をつけることに妥協しない
- とはいえ細かいものに「優先度が〜」と考えてる暇があれば5分でPR作ろうという話は別にある
- フロー効率は大事だが、罠がある
- 1つのことを全員でやろうという意識が強すぎると、分担されすぎて逆にスピードが出ない
- タスクの分割が難しいなら、モブプロするという選択肢を検討する
- やり方や意識を変えることは結構難しい
- それまでのやり方や考え方はその人のアイデンティティでもあるので、変えることはとても難しい
- 人間は機械じゃないので「はい明日からこれでいきます」とできない
- 本人も周りも互いに難しいことを認識することが大事
- 工夫のしようはいくらでもある
- デイリースクラムの最後に特定のポーズ👊で締めるという実験を一時期やったが、雰囲気が爆上がりした（=イチローや五郎丸と同じ）
個人の学び
- マネジメントの役割はチームの成果の最大化とその成果に責任を持つこと
- 任せることはグラデーション
- 「これ任せたからあとお願いね、進捗と結果は教えて」じゃダメ
- 「自分でやってみせる、一緒にやる、相手にやってもらい自分がレビューする、いつでも相談できる環境で規模の小さいものから任せる、実行は任せて結果責任を持つ」など "任せる" にもいろんな段階がある
- 任せきれるところに至るまでは、むしろ自分がやっていた時よりも労力がかかることがほとんど
- チームの兼任は基本的に悪
- リソースは有限なので選択と集中が大事
- 2つのチームを1つにまとめたときに一気に処理コストが下がった
- Slack いろんなチャネルを見ない
- 色んなチャネルに参加しているが、Slackを読むことはお前の仕事ではない
- 業務中に見るチャネルは必要最低限に絞る（あとは適当な時間で趣味として見る）
- 得意なことに逃げない
- エンジニア出身なのでそこに逃げてしまいたい気持ちもあるが、本当にやらないといけないことに向き合う
- 完璧主義に陥らない
- 自分のしょうもないプライドを捨てる
- 当たり前品質を下げる
- v0.1をなるはやで公開してフィードバックループを回す
- 手段と目的を逆転させない
- めっちゃ起こるので定期的に検査する
さいごに
学びが多い一年でした。来年も頑張ろう。
