EM就任後にチームを俯瞰するためのプラクティス
これは SmartHR Advent Calendar 2023 シリーズ1の19日目の記事です。
はじめに
こんにちは！私は今年の10月からSmartHRの労務プロダクト領域でエンジニアリングマネージャーとして活動しています。今までの経歴でも同じ職種を担ったことはありましたが、今回は管掌範囲も増え、自分なりの成果を出すために未だ四苦八苦しているのが現状です。就任当初の地に足がつかない状態では、チームがどうあるべきなのかを自問自答しても漠然としてしまい、マネージャーとして素早く成果を出すには「現状を把握する力」が求められるということをこれまで以上に実感しました。
この記事では、現状を把握するためにいくつか取り組んできたことをご紹介しています。就任初期のエンジニアリングマネージャーがチームを俯瞰するためにどんなことをしたのかの一例としてご覧ください。
そもそも俯瞰するとは？
マネージャーには少なくとも下に挙げた責務があります。
- 事業の成果を残す
- 人的資産を活用する
- 人を育てる
- チームを機能させる
これらを達成するには、「各項目で必要なタスクを見極め遂行する」必要があり、「必要なタスク」を見極めるには「現状を把握する」ことが必須です。（あるべき姿とのギャップを見出す必要がありますが、理想やビジョンについては本記事では取り上げません）
つまり、マネージャーの文脈でよく使われる「俯瞰する」は、「現状（チームや市場）を把握し、課題を見極める」という意味合いで使われていることが多いように見受けられます。市場やチームの構成が変わりやすい環境で日頃から課題を見極めるには、現状を把握する力がとかく必要なのです。
以降「現状を把握する」ために、私自身が取り組んだことをご紹介します。
①自分の期待値調整資料を作り共有する
自分のことをよく知らないメンバーも多かったため、はじめに期待値調整の資料を作り、「マネージャーの役割」と「今後の活動」を共有、内容が的外れではないかを確認しました。大きなズレはありませんでしたが、ここで事前にフィードバックをもらうのは自分の考えとズレがあるか確認できる活動でした。
内容は現職の秘匿情報に触れるため詳細に掲載できませんが、以下の構成でドキュメントにし、slackなどで共有しています。
# 期待値調整資料
- どんな人？
- 管掌範囲
- 弊社のマネージャーの役割
- 私の活動内容
- 全チーム共通（間接的にコミットする）
- 組織環境づくり
- 成長支援
- 動機づけ
- 安全配慮・ハラスメント防止
- 立ち上げ期のチーム（直接的にコミットする）
- プロダクトマネジメント
- テクノロジーマネジメント
- プロジェクトマネジメント
- ピープルマネジメント
②チェックリストの活用
チームを一通り把握するためのチェックリストを使いました。
このチェックリストは、書籍「急成長を導くマネージャーの型」にあったものをほぼそのまま使いました。チームを把握するといっても最初どこから何を見ていくのか漠然としがちです。こういったチェックリストを使うことでスタートダッシュしやすい状況を作ります。
| 把握項目と順番 | 内容 |
|---|---|
| チームの役割・目標 | 会社におけるチームの役割、チームの目標 |
| チームの貢献モデル | チームはだれの何に貢献しているのか？ |
| チームの業務概要 | チームではどのような業務がおこなわれているのか？ |
| チームの業務関連知識 | チームの業務に必要なドメイン知識 |
| チームの体制 | チームはどのような構成・開発プロセス・体制になっているのか？ |
| プロダクトオーナー、リーダーの考え方とスタイル | 方針やニーズ、仕事の仕方など |
| 会議体・各種リンク | どのような会議があるかと、各種議事録やボードなど |
| 業務詳細 | それぞれどのような業務をおこなっているのか？ |
| 戦力 | メンバー1人1人のスキルセット |
| 実務現場 | 実際の現場でどのように開発が行われているか |
（参考: 急成長を導くマネージャーの型）
チームのドキュメントを読んだり、適宜ヒアリングや1on1を利用しつつ項目を埋めていきます。まずは薄くても良いので、とにかく全体を見るようにしました。
③実際のチーム開発を観察し、フィードバックする
スクラムチームはすべて1週間のスプリント開発を行っており、私は各チーム2週間づつ観察することにしました。
現場を観察するのは「組織・環境づくり」の一環で、正確かつ即時的なフィードバックをするには現場を見る必要があり、受け手の目線でも一緒の時間を共有した人間のフィードバックほうが納得感を得やすい、というのも考慮しています。
実際に観察した内容は手元のメモにしたためておき、観察期間の最終日に各スクラムイベントごとのGood/Problemをチームに共有しました。
以下は共有したメモの一例です。（この記事用にサンプルで書いています）
# ◯◯チームのスクラムイベントを見学したメモ
## デイリースタンドアップ
### 最高
- 雑談コーナーがあるのコミュニケーションが活性化して良き
- タスクの移譲が日常的で「○○さんお願いします」的な会話が多い
- 言い出しっぺの法則になりづらいコミュニケーションができている
### 気になった
- タイムボックスベースでタスクへのアサインを調整するのは非常に良いが、その作業自体に時間がかかっているため効率化できないでしょうか
## リファインメント
### 最高
- 事前にPBIの内容が詳細に記入されているため、リファインメントの時間効率や良い
- pointing porkerでポイントもほぼズレがない
- 観点がなかなか収束しない状況がなく、事前準備力を感じました
### 気になった
- 議論の起点（観点を引き出す）や話を進めるメンバーに偏りが若干見えました
...
④スキップレベル1on1の実施
SmartHRの開発組織は四半期に1度、マネージャーと開発チームのメンバーが1on1をする時間があります。
※チームリーダーをスキップして行われるため”スキップレベル1on1”と呼ばれています。
各メンバーにプロダクト、チーム、自身のキャリアについてのヒアリングを実施し、伏せたほうが良い内容を除き、チームリーダーにも話した内容は共有するようにします。（メンバーには共有することを事前に通達します）
チームリーダーが客観的にプロダクト開発 / チームの状態 / メンバーの状態を把握できる機会として活用しつつ、自身もチーム状況をより具体的に把握するための活動としてとても役に立ちました。
設問はざっくりと下のような構成で聞いています。
①プロダクト開発状況について（観点 : 目標 / 目標への進捗 / 障害 など）
- うまくいっていますか？
- なぜそう思うのでしょうか？
- よりよくするアイデアはありますか？
- 今後開発を進めていく上で気になっている技術的な障害
- 今後開発を進めていく上で気になっている技術以外の障害
②チーム状況について（観点 : モチベーション / 情報の透明性 / コミュニケーション など）
- よいと思いますか？
- なぜそう思うのでしょうか？
- よりよくするアイデアはありますか？
- 今後課題になりそうなことはありますか？
③ご自身のキャリアについて（観点 : キャリア形成 / チームリーダーとの関係値 など）
- うまくいっていると感じますか？
- なぜそう思うのでしょうか？
- やっていきたいことはありますか？
- その他、気になる・困っていることはありますか？
⑤自分用の俯瞰シートを作成
各チームごとのslackや会議の議事録、その他ドキュメントとシートなどを読んでキャッチアップし、情報を集約した場所を作ることで、全体を把握できるようにしました。
どうしてもログを追うのは一定必要になりますが、マネージャーの本来すべきことはキャッチアップそのものではなく、その情報を扱ってチームや組織にどう還元するかです。OKRをはじめ、チームのリアルタイムな関心事を観測し、議論すべきことに対して時間が使えているのかを検査するようにしました。
また、情報を集約した場所にまとめておくことで、slackをはじめとしたログを追うときにも、カラーバス効果が働き、情報の取捨選択が多少はしやすくなります。
私は情報を集約するのにはスプレッドシート使い、「チーム用シート」と「チームリーダー用メモ」を分けて作りました。
チーム用シート
そのチームにおける「目標やOKR」、「各スクラムイベント」、「その他チームの関心事」を記述できるようにします。日付ごとにそれぞれの項目の更新をチェックします。
特におすすめしたいのが、「中長期的な関心事」を明示しておくことです。この項目を追加しておくことで、ある特定の中長期的な課題に対するアプローチをタイムラインとして把握できるようになるため、動きがないときにチームに対してもリマインドすることが可能になります。
チームリーダー用メモ
私が直接評価をする対象はチームリーダーであるため、チームリーダーの行動・振る舞いについてGood/Badをログに貯めていきました。日常的に使うメモとしてできるだけ簡単にするためにフォーマットもシンプルにし、このログを使って即時的なフィードバックを実施できるようにしています。（以下の内容は実際のメモではなく、本記事用に書いたサンプルです）
これらの俯瞰シートを使い、得た情報を整理し、継続して見るべきポイントを絞るように私はしました。もしとにかく情報を咀嚼し続けているのであれば、量の多さを捌く何かしらの仕組みを取り入れることを強く推奨します…！
終わりに
本記事では10月からエンジニアリングマネージャーとして活動している私が行ったことを振り返りつつまとめてみました。冒頭にもありましたが、マネージャーが「何したらいいんだ…」という問題に対し、本記事が少しでも手助けになっていたら幸いです。
Discussion