半年間チームに対して行ったアクション

2022年12月30日 21:44

2022/7月からiOSチームのEMを担当することになったので備忘録としてチームに対して行なったアクションをまとめておく。

前提

マネージャーのアウトプット = あなたのチームのアウトプット + あなたが影響を与えた他のチームのアウトプット

「弱めのEM定義」は、「エンジニアのマネジメントスキル」としてのピープルマネジメントスキルとテクノロジーマネジメントのスキルを持っているキャリアになります。

弱めのEM及びリードエンジニアとして開発の意思決定、中長期的なゴールに向けたステップとなる目標とロードマップを示す。
持続的にチームが成果を出せる状態を創るため、メンバーとの1on1やチームビルディングを行う。

0→1のフェーズは、ミドル~シニアのエンジニア個々人が自走し "勝手にキャッチアップし勝手に成長する" ような体制だった。
インターン生や中途入社が増える未来が見えていたので、新規メンバーが1日でも早く成果を出すためのオンボーディング資料を更新した。

メンターが受け入れ日までにやること
- Google、Slackアカウントの発行依頼、GitHubアカウントの権限設定など
- Slackグループにデフォルトのチャンネル設定しておくと楽
メンターの心構え
- 新規メンバーの相談窓口・寄り添う"存在"になるためコミュニケーション機会を意思的に設ける
初回タスクの検討
- お迎えタスクの用意
  - 締切に余裕があること
    - メンターが行なって1日程度で実装完了する程度の規模感
  - 個々人と相談しながら決めるが、直近は利用しているアーキテクチャの理解を狙い、適用外の画面の置き換えを行うことが多い
    - コードレビュー内容より、ハマりどころはコーディングガイドラインに追記をしている
MTGの設定
- チームメンバー内外とのランチの場を設定する(可能であれば初日)
- 事業説明とは別でコードベースの簡単な解説機会、チームが困っている課題や注力している内容を共有する

手引きは作って終わりではなく、メンバーに随時更新をお願いしている。

コードレビューの属人化と一貫性を狙いレビュイー・レビュアーに向けたガイドラインを整備した。

反応する
- "他の人の作業のブロッカーとなるため、コードレビューの優先度は相対的に個人作業よりも優先度が高い"
- 絵文字や返信コメントでリアクションを行う
気がつけるようにする
- 即時にPRレビューのアサイン、コメントのGitHub通知を受け取れるようSlack連携する
レビュー方針
- 確認すること
  - ex. モデリングの妥当性(意図のない抽象化がされていないか)
- 確認しないこと
  - ex. 機能の正常動作(依頼されている場合を除く)

※ これから対応予定
1. リードタイムの計測
2. 個々人が機能チームに分かれて開発を行なっている、職能チームとして横軸での技術共有、ドメイン知識の分散を狙い、PR説明会・ペアレビューの場を設ける

設計がコンポーネント化されていない、複数の実装方針が混ざっているなどの技術的負債により開発サイクルを高速に回せていない事を課題と感じている。今後の開発のスピード x 質を担保するための、中長期での開発改善に向けたゴールとアクションの策定をしている。

目の前のタスクに全力で立ち向かうのは大前提だが、私自身が短期的にやりやすい開発タスクに着目しがちな思考であった。この半期は中長期で立ち向かうべき課題の解像度上げの調査とプラクティスのキャッチアップに時間を使った。

一人で立ち向かうのではなく、チームの課題として共通認識を持つための目的(what)、対応方針(how) を決め、先頭を走り続けつつ、週一の勉強会の時間や日時の定例でメンバーの巻き込みを行う。

※ これから対応予定
機能開発と同時並行で開発改善を行う時間的制約が存在する、カンバンに落とし込みロードマップを示す。四半期毎に設定する開発チームの目標として宣言する。

振り返ると仕組み化の取り組みが多い。
今後は以下を目標とする。

委譲する
- サブリーダーの育成
- ノウハウは蓄積されてきたので、再現性持って取り組める業務は増えたはず。今後はコミュニケーションを交えながら自分がやらなくて良いことは依頼し信頼しきる
開発改善の戦略と戦術を決め、段階的に対応する
- チームの中長期課題に引き続き向き合う
- 対外的なアウトプット

この記事が気に入ったらサポートをしてみませんか？