はじめに

この記事は Engineering Manager Advent Calendar 5日目の記事です。

私は前任の凄腕マネージャーの退場を機に、2023年7月から新任マネージャーになりました。
マネージャーを拝命して約半年経ち、これまで考えてきたこと、やってきたこと、そして今後こんなことをしたいなどを、現時点・現在地での視点で記載しておこうと思います。

やったことお品書き

端的にやったことだけを知りたいんだけど、という方は下記のお品書きからジャンプしてください。

準備編
- マネージャー業務をリストアップし、引き継ぐ
- マネージャーの仕事とは？的な本などを読む
仕組み作り編
雰囲気作り編
- メンバー間のペアワークの雰囲気作り
- あなたにここを任せたい、を伝える

マネージャーになった経緯

私の遍歴

複数のプロダクト、複数の開発チームへの異動経験がありました。

前述したとおり、マネージャーという職種になるのは今回が初めてです。
ただ、2018年後半〜2020年初頭までは、チームリーダーをしていました。
なので、チームをまとめる役目としては今回で2度目となります。²

マネージャーとリーダーの違いは？

文献によっても会社によっても、社内であっても部署によってすらも、少しずつ解釈が異なると思います。

私の解釈では、
いずれもチームが担当するサブシステム¹の成長と、チームメンバーの成長に責任がある役割だと思いますが、
開発業務そのものをリードする色が強いのがリーダー、チームメンバーが開発業務をしやすくするための土壌を整えることに重きを置くのがマネージャーかな、と思っています。
また、弊社的にはマネージャーはチームメンバーの人事評価をする立場でもあります。

その他にも、「リーダーマネージャー違い」などで検索するとさまざまな記事が出てくるので、自分がしっくりするものを見つけるとよいと思います。
例）リーダーとマネージャーの違いとは？それぞれの定義と役割をわかりやすく解説！

マネージャーになったチームとの関わり

第2子の育休明けから合流したチームで、1年半ほどチームメンバーとして合流していました。
いくつかのサブシステムを保守するチームで、いずれのサブシステムも10〜15年ほどの歴史がありました。
とはいえ、そのチームが担当する業務領域の新機能開発担当として合流したため、正直既存サブシステムの仕様については1番知らない状態でした。

前任マネージャー

超凄腕マネージャーでした。

その方は10年超にわたって私たちのチームが担当するサブシステムを守り育てていました。

当然それらのサブシステムへの深い造詣を持ち、
関連の市場動向にも目を向け、
シニアクラスのチームメンバーたちをとりまとめ、
レビューなどで鋭い視点や高い視座でフィードバックを投げ、
それでいて誰よりも機能も不具合修正をリリースし、
ユーザーの業務を紐解いた丁寧なデモもこなす。

そんな方でした。超人か。

もうほんとにめちゃくちゃ格好いいマネージャーでしたが…
私はその方のようには…到底なれない…

一方で、新参者だったからこそ見えてきたチームの課題もありました。

見えつつあったチームとしての課題

当時のチームは、シニアメンバーたちがほぼ1人1サブシステムを受け持っており、各々のサブシステムを守り育てていました。
さらにそのメンバーたちをマネージャーが統率していました。

その結果、以下のような課題がありそうだと感じていました。

他のメンバーが今何をしているのかが見えづらい
何か問題が起こったときに、マネージャーに相談はできるものの、最後は自分がなんとかしなくちゃいけない(代わりがいない)
明確な担当がついていないような小さなサブシステム、ユーザー数の少ないレアサブなどの保守はボランティア状態
上記のようなチームとしての課題を解決する余力もないし、対等だからこそ斬り込みづらい

その当時の均衡が保たれ続けていれば何とかなるかもしれませんが、1人でもメンバーが欠けたら即アウト、という危うさがありました。
また、新しくチームに加わったメンバーからすると、チームメンバーが今どんなことをやっているのかや、チーム全体としてどんな課題を抱えているのかが見えづらく、やりづらさを感じる部分もありました。

サブシステムへの深い造詣はないし、チームの新参者だけど、上記の課題を課題として認識しているし、解決する役割は担いたいと感じました。

それ以外にいくつかの理由が重なり（割愛）、上記課題を解消すべく、マネージャーになることを決意しました。

やったこと

準備編

やりたいことはあったものの、マネージャーは初体験なので、まずは「マネージャー」が一体どんなことを担うべきなのかをインプットしました。

マネージャー業務をリストアップし、引き継ぐ

なにはともあれ、前任マネージャーが開発部門のマネージャーとして行なっていたさまざまな業務をなるべく漏れなく引き継いでいきました。

前任マネージャーや部門長にヒアリングをし、スポット、週次、月次、四半期ごと、それぞれでやっていることを書き出しました。また、引き継ぎが決まってからの2ヶ月ほどは関連ミーティングへも同席し、内容を把握しました。
他プロダクトや他部門からの問い合わせ窓口となっている箇所の引き継ぎも行っていきました。

マネージャーの仕事とは？的な本などを読む

社内的開発マネージャーのお仕事の引き継ぎもしつつ、「マネージャー」とはどういう役割を担うのか、どんなマインドセットを持つべきなのかを知ろうとしました。
また、チーム運営の参考のため、スクラム関連の本などを読みました。

マネジメント関連

組織運営関連

そのほか、Slackで共有されたりGoogle Discoveryでおすすめされたりするマネジメントやチーム運営に関するネット記事やスライドを読み漁りました。

仕組み作り編

チームの課題を集約・見える化する

問題：課題管理と進捗状況の散在

以前は、サブシステムやチームの課題が、課題管理ツール（自社開発）、チケット管理ツール（Redmine）、スプレッドシート、担当者の頭の中に散在している状態でした。

出荷が予定されている機能強化や不具合修正の案件の進捗状況：Redmineで管理
- ただし開発状況に応じてステータス更新しているかは開発者次第（最終的に実態と合えばOK状態）
出荷時期が未定だがいつかやりたい案件：スプレッドシートor課題管理ツール
- 基本はスプレッドシートに記載されているはず
  - コンサルなどからの要望は課題管理ツール経由で起票される。スプレッドシートへの転載は開発者が手動実施

また、各課題の進捗状況の管理も散在していました。

週次の進捗状況：スプレッドシートで管理
- 先週やったことと今週やることのセクションのみ分かれており、毎週行追加してコピペしていくスタイル。中身はフリーフォーマット
  - タスクの書き落とし、コピペミス
  - 長期案件の表現が難しい
日次の進捗状況：メンバーの手元or頭の中にあり、口頭共有

結果、

チーム内に今どんな案件や課題が存在するのか
各案件や課題の進捗状況はどうなっているのか

これらを把握するのに、いろんな課題管理先を確認したり、各メンバーに都度状況確認したりなど、結構な手間がかかりました。

解決策：課題管理と進捗管理をGitHub Projectsに集約

課題とそれらの対応時期、進捗状況を一元管理するツールとして、GitHub Projects（以下Projectsと記載）を採用しました³。

まずはチームでもともと行っていた、日次・週次の進捗確認ミーティングの場で利用するための、1週間のタスクを一覧できるビューをProjecsで作成しました。

同時並行で、課題管理をしていた各種ツールやスプレッドシートを確認し、チームの課題として管理すべきものを棚卸しし、サブシステム単位、チーム単位でProjectsに引っ越しさせました。

これにより、チームの課題や進捗状況はとにかくここを見ればわかる、という状態を作ることができました。

極力自動化する

GitHub Issue起票の自動化

チーム内の課題や進捗の一元管理は達成したものの、開発部門全体でツールが変わったわけではありません。タスクの流入口はさまざまです。

そこで、主にZapierを使ってIssueを自動起票し、
GitHub Actionsを使ってProjectsへ自動連携するようにしました。

課題管理ツール
- 新規課題起票時のメールをhook
別部門管轄のスプレッドシート
- 特定カラムの更新をhook
Slack
- Issue作成用のリアク字を作成し、あらゆるチャンネルでのリアクションをhook

などです。

PR/MRの依頼、コメント、Close、マージのSlack連絡の自動化

GitHubのPRのSlack通知はこちらを利用しています。
GitLabのMRのSlack通知はやりたいことが標準のアプリで達成できなかったため、Issue起票の自動化と同様にZapierを利用し、こちらはSlackに即時自動通知するようにしました。⁴

その他

Issue Templateの作成

機能強化、不具合修正、全社向けのタスクの実行状況管理など、GitHubでよく使うテンプレートをIssue Templateとして登録し、/Templatesコマンドで呼び出せるようにしています。

ドキュメントレビューの一部自動化

Slackのワークフロービルダーを使って、テストケースやリリースノートなどの各種ドキュメントレビューも一部自動化しています。

自動化できないものは

日次、週次、月次、四半期ごとにあるミーティングのアジェンダに盛り込み、取りこぼしがないようにしています。

ルールを明文化する

これまでチーム内で暗黙のルールになっていた部分をチーム内で再確認したり、曖昧になっているルールを明確にしました。
また、チームの情報を集約するためのWikiページを作成して、明確にしたルールをその中に記載し、いつでも確認できるようにしました。

なんでもルール化して縛りつけよう、という意図ではもちろんありません。
決まりごとが明快であった方が効率が上がる部分を(再)定義したという感じです。

暗黙のルールはチームに慣れればなんてことないですが、新たにチームに参加した人にとっては右も左もわからない状態になり、入場直後の開発効率を著しく下げます。
また、既存メンバーも毎回一から説明するのも手間です。

また、この不具合修正の評価担当者誰にする…？などのちょっとした迷いや忖度の時間て意外と気を遣いますし、時間と労力と精神を削るのももったいないです。

サブシステムの担当を2人以上体制にする

ありがたいことにここ1年以内でチームメンバー増えたので、各サブシステムに新たなメンバーを割り当て、担当者を増やしました。
また、それぞれのサブシステムを担当してきてくれた既存メンバーたちにも、新たに別のサブシステムを触りはじめてもらいました。
これにより、1人のメンバーが不在になっても別のメンバーがフォローできる体制を作りつつ、1つのサブシステムだけに凝り固まらないような状態を作りました。

知識をみんなが見られる場所に配置する

自分用メモを手元にだけ残してそれを参照する状態をやめ、wiki、共有ドライブ、とにかくどこでもいいので、チームで「ここに行けば開発業務やサブシステムの情報にアクセスできる」という場所を作りました。

未来を見据えられるようにする

もう1つのチームの課題として、場当たり的な開発計画がありました。
すでに多くのユーザーがついている機能のため、ユーザーからの追加機能や不具合修正の要望などが頻繁に上がります。
いつどの機能強化をするべきかの判断をする際、中長期的なロードマップが不在のため、声の大きなユーザーの要望がどうしても目立ち、優先してしまいがちだと感じました。

そのため、サブシステム単位で、いつ、どのタイミングで、どんなことを、誰がやる予定なのかを明示したロードマップを作成しました。

すでに上がっているユーザー要望や、チームとしてやるべきだと判断している案件を加味して、向こう2年ほどのロードマップを作成しました。
新たに要望や要対応案件が挙がった場合、そのロードマップを見て対応時期を判断するようにしました。

なお、現在チームビルディングの最中のため、サブシステム単位に加えて、チームビルディングのロードマップも作成しています。

少しずつスクラム開発のエッセンスを取り入れる

ロードマップを作成したうえで、着実にロードマップを遂行していくために、スクラム開発のエッセンス⁵を取り入れ始めました。

スプリントを1ヶ月とし、月次で振り返りとプランニングを実施する⁶
直近(3ヶ月以内めど)やる予定のタスクについて、サブシステム単位で優先度をつけ、順番に並べる
ベロシティ計測のためタスクのサイズを考えるようにする

などです。

スクラムの文脈では、課題はたくさんある

たとえば以下のような課題があります。

サブシステム単位とはいえ、複数人で全く異なる毛色のことをやっていると優先度付けに迷った結果、結局優先度を要対応時期でつけてしまいがち
開発経験や年次の浅いメンバーもチームには合流する
- 新しく入ったメンバーにいきなり難易度に関わらない高優先度のものをやってもらうのは無理なので「上から順に着手する」は無理
スプリントレビューは機能強化や新規開発しか実施していない
そもそもスクラムマスターやプロダクトオーナーが不明瞭
- 強いて言えば両方私が兼任している状態

などなどなどです。

それって「なんちゃってスクラム」ってやつでは？

はい、その自覚はあります。

ただ、私たちのチームでは、すでにサブシステムが存在し、利用ユーザーも存在する、運用フェーズの機能の保守を主業務ととしています。
機能開発や不具合修正に加え、不定期かつ規模感のまばらなユーザーやコンサルからの問い合わせ対応(=差し込みタスク)も業務の1つです。
これらをいきなりすべてをスクラムのやり方に変えようとしても破綻するし、メンバーも混乱するだろうと感じました。

また、メンバーにスクラム開発の経験者もおらず、私自身もスクラム開発を経験したことがない(あったかもしれないが、それをスクラム開発だと意識したことがない)ため、スクラムを取り入れていくイメージがありませんでした。

そのため、導入ハードルの低いものから少しずつ取り入れ、「いいね！変わったね！」の認識共有をしつつ、「実はこれはスクラムでいうところのXXXにあたってだね…？」というように、少しずつ「スクラムいいじゃん！」を浸透させています。

また少なくとも現時点では、スクラムは新規開発時により高い効果を発揮すると思っているので、運用フェーズのサブに対してすべてを導入する必要もないのでは？とも思っています。

ミーティングのファシリテーターをメンバー内で持ち回る

デイリーミーティングやウィークリーミーティングのファシリテーターを、マネージャーではなくメンバーに週次で持ち回りで担当してもらっています。

デイリーやウィークリーは進捗確認などの一面はもちろんあるものの
マネージャーがファシリを回してしまうとマネージャーからの進捗確認の場、という意識が強くなり、発言ハードルが上がってしまう可能性があるのと、
ファシリは場数を踏むことで慣れて上達すると感じているので、その機会を私1人で使ってしまうのはもったいないなという気持ちからです。

週に2回、チームとしてメンバーの作業集中ブロックを確保する

先に記載した通り、私たちのチームでは問い合わせ対応、不具合修正、機能強化を担当しています。
とはいえ、問い合わせ対応を何件も抱えながら機能開発もするのは限界があります。
そこでサブシステム単位で、主に午後の13:00-16:00を、一人のメンバーの作業集中ブロックに設定しています。
その時間帯はカレンダーに予定登録しておき、サイレントでの予定重複を避けてほしい旨を記載しています。
また、緊急の問い合わせ対応は可能な限り集中ブロックが割り当てられているメンバー以外で回すようにしています。⁷

雰囲気作り編

メンバー間のペアワークの雰囲気作り

これまでは何か困ったことがあった場合、前任マネージャーと各メンバーでの1on1内で、各々がマネージャーとだけ相談して解決していました。
しかしそのマネージャーは退場し、私は既存機能を深く知るわけではないので、同じ体制を敷くのは無理です。
また、新たなメンバーも増え、私自身も育児時短勤務中なので、相談事を私に一極集中させてしまうと私が確実にボトルネックになります。
そういった意味でも、これまでのように「まずはマネージャーに相談」という状態にすべきではないと思いました。

そのため、
機能についてはその機能を担当しているメンバーが1番よく知っているので、メンバー間で相談する。
チームを超えての案件や相談事など、サブ担当メンバーの中だけでは判断に迷うような時はマネージャーに相談。

のように、ある程度の役割分担をしました。

とはいえ、ただ役割分担をするだけでは、忙しそうな先輩に相談するの遠慮しちゃうな…という心が働いてしまうのは目に見えているので、大きく以下の3点を用いて、相談しやすい雰囲気を作っています。

デイリーミーティングで困りごとをキャッチ

毎朝開催するデイリーミーティングの中で困りごとを確認しています。即解決できるものはそこで解決、できないものもデイリーミーティング後に時間を作ってもらうなど、追加相談への足掛かりとしています。

"モブワークタイム"でちょっとした相談やモブワークへのハードルを下げる

毎日夕方の1時間、必ずチーム全体で集まる時間を設けました。
oViceに集まり、ちょっとした質問や相談をできる時間にします⁸。モブワークを冠していますが、特に相談事がなければ黙々とそれぞれの作業をします。コロナ禍前の出社している状況を模した形です。

Slackにチーム用のtimesチャンネルを作り、発言ハードルを下げる

もともとチーム外の人からチームへの連絡窓口となるチャンネルがありましたが、そこはチーム外の人も入ってくるので、どんどん発言ハードルが上がってしまいます。
そのため、窓口チャンネルとは別に、ほぼチームメンバー（と目的を理解してもらえるチーム外の人）のみが参加しているチームtimes⁹チャンネルを作成し、そこでチーム内の質問、相談、共有、雑談などなど、雑多な会話をしています。

あなたにここを任せたい、を伝える

「今こういうことをお願いしているのは、ゆくゆくはこういうことをお願いしたいからなんだよね」というのを、各メンバーに意識して伝えるようにしています。
また、チーム内で管理しているロードマップには、誰がその案件を担当する予定か、も表現しています。口頭だけではなく、可視化することで、これが終わったらこういう案件が待っているのか、というのが予測できるようにします。

もちろん闇雲にお願いするのではなく、チームメンバーとの週次の1on1の中で、本人の希望に加え、この人はこういうこと興味ありそうだなと感じことや、「XXさんこういうこと興味あるって言ってましたよ」みたいな話をキャッチしたうえで、そこに至るまでにやった方がよさそうなことと現在挙がっている案件とをなるべくマッチングさせています。

今後：マネージャーっておもしろそう！と思ってもらえるようなマネージャーを目指したい

マネージャー業務っておもしろいのか？

面白そうには見えていなかったメンバー時代

私はメンバー時代、本当にマネージャーになりたくなかったです。

歴代の直属のマネージャーや近隣のマネージャーを見ていると、チームメンバーのレビューや相談を受けたり、上司などに進捗状況の説明したりする時間が多く、自分の機能を作る時間を捻出するのも困難そうに見えました。
マネージャーご自身でも案件を持っているのに、集中して仕様考えたりコーディングしたりする時間が取れないのつらすぎるだろ…マネージャー絶対なりたくない…という印象ばかりでした。¹⁰

このメンバーからのマネージャーに対する印象って、後進を育てていくうえでは軽視できないと思います。

マネージャーおもしろそうかも！と思った契機

そんなことをずっと思い続けて10余年、私の尊敬するマネージャーのお一人に、次のようなことを言われたことがありました。

たしかに職務上はマネージャーなんだけど、俺はマネジメントをやっているというよりは、ずっとアプリ開発者っていう感覚があるよ。
マネジメントをやってやるぞというよりも、自分に作りたいものがどんどん増えて、大きくなってくると、1人じゃ作り切れない。だから、メンバーと協力しながら1つのものを作っていっている感覚。

口頭だったので細かいニュアンスが一部異なる可能性もあるものの、当時マネジメントやりたくなくて仕方がなかった私にとっては、天啓が降りてきたかと思うくらい衝撃的な一言でした。

育てていきたい機能があるけれど、1人では機能を作れる時間も限られています。
今ある機能をもっとよくしていきたいという同じ志を持ったメンバーがいて、自分より手を動かす時間もあって、自分より手を動かすのが得意な人がいるなら、
チームとして機能を作る人と、機能を存分に作るためのサポートをする人で分かれるのは戦略としてアリで。

そのサポートをする役割を担当するのがマネージャーなんだなと、大変大変腑に落ちた瞬間でした。

マネージャー業務は（少なくとも半年経過した時点では）おもしろい

そして実際にマネージャーになってみて、直接コーディングをすることは減ったものの、メンバーが実装する機能にはさまざまな場面で深く関わるので、機能開発ができなくなったという感覚はそこまでないなと感じています。
むしろ、見るべきサブシステムの範囲も広がり、それらの未来もちゃんと見据えることができるようになり、チームメンバーが機能強化や不具合修正をしてくれることで、サブシステムを一緒に着実に育てている感覚もあります。

また、チームビルディングを進めていき、少しずつチームやメンバーの雰囲気が変わっていくさまを見られるのはシンプルにとてもうれしいです。

今は1つのプロダクトの中のいくつかのサブシステムを受け持つチームのマネージャーなので、これがプロダクト全体を見るべきマネージャー、開発部門全体を見るべきマネージャーになったらもちろんまた異なる見え方をするとは思います。
また、チームによって、開発状況もマネージャーに迫られる役割も異なるとは思います。

それはそうとして、半年たった現時点・現在地では、マネージャー、とてもおもしろいです。

と同時に、前述のとおりマネージャーはあくまでも役割の1つでしかないと思っているので、マネジメントに興味がある方がいらっしゃればいつでも交代したいと本気で思っています。
マネージャーが代わるとチームにも新しい風が吹いてとてもよいと思うので、定期的にマネージャーを入れ替えていくのもありだなと思っています。

おわりに：チームマネジメントは水物

今回ご紹介した内容は、現時点で私たちのチームに取り入れたらもっとよくなるかも？にひたすら取り組んでみた結果です。
これ以外にも取り入れてみて「イマイチだね…？」となったり、陳腐化してしまいそうな片鱗を見せたものをチームで話し合って改善したりなど、常に変更を加えています。

今回の内容が、自分たちのチームに合ったやり方を模索するための一助となれば幸いです。

弊社が提供する統合型人事システムCOMPANYは、その中に数百におよぶ機能が存在します。その1つ1つのことを「サブシステム」と呼んでいます ↩ ↩²
2023年11月7日に開催されたWomen Developers Summitに登壇したのですが、その際私はマネージャーになるのは2度目、という自己紹介の仕方をしました。これらの解釈が個人的にありつつも、チームを引っ張っていく役割という意味でマネージャーとまとめた方が伝わりやすいだろう、という判断でした。というちょっとした言い訳です。 ↩
採用理由は、開発部門全体でGitHubが導入されており、Projectsの導入ハードルが低かったのと、身近にProjectsを使ってタスク管理をしているチームがあり、参考にしやすかったためです。ツールは採用しやすいものでいいと思いますが、スプレッドシートなどのフリーフォーマットではなくタスク管理や進捗管理を得意とした専用ツールを利用すべきだと思います ↩
現在ソースコード管理やドキュメント管理でGitLabとGitHubが混在しているため、どちらも活用しています。 ↩
スクラムとは？アジャイルとは？については言及しません。マネージャーの仕事とは？的な本などを読む#組織運営関連で挙げたドキュメントや書籍を参照してください ↩
弊社の開発部門全体は、なんとなく1ヶ月スプリントでスクラムを回せるようなスケジューリングになっています。また、1週間だと問い合わせ対応も加味すると短すぎ、2週間だとリリースサイクル的にも半端ということで、1ヶ月をスプリントとするのがよさそうだね、とチームで結論が出ました ↩
最初は1週間単位とか1日単位とかの方がいい？と提案してみましたが、3時間でも差し込みがない状態で集中できるだけで効果がありそうとの声がメンバーからあったため、現在1つのサブシステム担当者間、3時間での効果測定中です。効果がありそうだったら他サブにも横展開しようと考えています ↩
oViceのいいところは、複数の相談が走るときは、どちらかが"ちょっと隣の島"にずれて相談し、終わったらまた戻ってくる、がしやすいところです。
Google MeetやSlackのHuddleもいいのですが、上記のようなちょっとした小回りが効くのがよくてoViceを使っています。 ↩
参考）なぜ WHI では times 文化がうまくまわっているのか？。ただし、個人timesとは違い、チーム内では会話の場としているので、業務利用もしています。 ↩
当時の私は、マネージャーかプレイヤーかとかはあまり関係なく自分で考えた機能を自分で出すことこそ美徳、とすら思っていた節があり、マネジメント業務は正直、ミーティングや細々とした調整や雑務など、開発業務の邪魔になるものの印象しかありませんでした(暴論) ↩

凄腕マネージャーからチームを引き継ぎ半年間でやってきたこと