この記事はフューチャーAdvent Calender 2021 2日目の記事です。
はじめに
2020年のアドベントカレンダーではテックリードになって気をつけていること - Qiitという内容を投稿しました。今年はレイヤーが0.5段くらい上がって、複数チームをマネジメントするような役割に広がりました。
エンジニアのためのマネジメントキャリアパス――テックリードからCTOまでマネジメントスキル向上ガイドを探すと自分の職位的にはdirector of engineering(技術部長)が近そうですが、部長と呼ばれる規模感には届かず、直に見ているのは2~3チーム・10名程度です。
これくらいの、技術志向だけれどマネジメント寄りのキャリアパスに踏み込む人も少なくないのではないでしょうか。まだまだ手探りなところが多いですが、それでもこの1年をなんとか回してきたので工夫点をまとめます。こういったルートを歩む人にとって少しでも参考になれば嬉しいです。
この記事を書くことを決めたキッカケですが、このロール（？）から業務中に行うコーディングの時間が減るのと、メンバーへの1 on 1・リーダー向け数値管理・採用・面接などでスケジュールが会議通知で割と埋まっているのをメンバーが見て「忙しそう！」と少し引かれたことがあります。また、全社的な貢献へのコミット（採用とか講演とか社外リレーションづくりとか）も求められ、責任が重そう！って思うかもしれませんね。実際のところどうなのか・どういう学びがあるのか残したいと思いました。概ね楽しいですし、僕自身はポジティブで学びみがある魅力的な仕事だと思っています。
テックリードとは
エンジニアのためのマネジメントキャリアパス――テックリードからCTOまでマネジメントスキル向上ガイド によると、以下のように説明されています。大体はエンジニアチームの取りまとめ役を指していると思います。
- テックリードはエンジニアの階層におけるランクのひとつではなく、シニアのレベルに達したエンジニアが担うことのできる職責群である技術的なプロジェクトの管理者
- 部下に効率良く仕事を割り振って自身の負担を適宜軽減するよ う心がける
- チーム全体の生産性に照準を定め、しかるべき成果を上げるよう全力を尽くさなければならない
- 管理やリーダーシップに関わる難局を打開する方法と、製品、分析など社内の他部門と効率良く協働する方法とを習得することが求められる
Talking with Tech Leads という書籍によると、最低でも自身の職務時間の3割 開発（プログラミング）に当てるといった表現がされています。巷のテックリード職を調べると、だいたいこれに準じて2~4割の時間を開発に当てると言っている方が多かったです。
director of engineering(技術部長)とは
エンジニアのためのマネジメントキャリアパス――テックリードからCTOまでマネジメントスキル向上ガイドからいくつかの説明を抜粋します。
- 技術部長は複数の技術部署のエンジニアを統率し、テックリードにとっても部下をもたないエンジニアにとっても、この技術部長が直属の上司となる
- 技術部長にとって日常レベルでコードの作成作業に携わることは職務上の義務ではない
- 技術部長が第一に重視するべきなのは、複雑な成果物が順調に提供されるよう計らうことである。開発およびインフラにおける標準やプロセスを絶えず評価、改善する
- 技術部長の影響力は、技術部門の複数の領域に及ぶ。技術部門で次世代のリーダーや管理職となり得る人材を発掘、育成、支援する
- 技術部長は（技術部門と他部門の協働も、技術系の部署間の協働も含む）部門間協力で部下の手本となる有力なリーダーである
職務が多岐に渡ることが分かります。そして見るからに大変そうです。ただこういった方向に向かって、今私がキャリアパスを進めているのは間違いないかなと思います。
なんとなく今の自分の状況には「技術部長補佐」といった名前が合いそうだなと思いました。一気にまだまだこれからだ感がでますね。
気をつけていること
技術部長補佐ロールで気をつけていることを挙げていきます。正直扱うのが人・チームであり、組織の文化によっても状況は大きく変わるかと思いますので、こういうリーダーもいるんだという一例として認識いただければです。
①1 on 1への投資時間の増加に備える
技術部長補佐ですがテックリードと異なり圧倒的にメンバーにかける時間が増えます。この手のエンジニアマネジメントで必須となる、 1 on 1ですが、テックリード時代の2,3倍に届くことが少なくないのではと思います。1 on 1に投資する時間は業務時間から天引きだと思っていますが、当初想定よりなんか多く時間をとっていると感じます。なぜかというとメンバー数が増えると1 on 1の頻度を増やしたくなるからです。バグかな。
いいえ違います。なぜかというと、テックリードとしてメンバーと同じ職務をしているときは、タスクに対する同期的な会議（Google Meetなど）で話すことが多かったのですが、直接業務を共同で行う機会が減り、コードレビュー・報告・チャットから困ってそうなことを拾ってアドバイスをする程度の関わりだと、今の実態の状況が見えず、従来月1程度で大丈夫だと思っていた人でも、隔週など頻度を上げて話したくなるからです。
つまり、メンバーが増えたら 1 on 1の開催頻度も下げて臨もうという目論見は明らかに破綻しますし、メンバーが増えれば線形に間接コストが増えるだけだよね、という目論見も破綻します。よく8名規模からマネジメントの質が変わるよって言われますが、こういうことかーって感じました。
自分が受け持つ開発タスクの量はシビアに絞らないと迷惑をかけます。当然メンバーに対して優先度に応じて効率よく成果を出してもらうかが最重要で、自分の能力でリカバリーするという考えは捨てましょう。自分の開発リソースは最後の埋蔵金です。
ちなみに1 on 1自体についてはかなり回数を重ねたので以下のような記事を会社ブログに寄稿しました。基本はコーチングの場だと思っています。育成力は高めていきましょう。
②大丈夫だと思ったら信じて委ねる
複数チームを見ていると皿回しをしている感覚に陥ります。放置するとお皿の回転が止まり墜落（炎上するとは限りませんが、何かしらのハレーションは起こるでしょう）します。ハードランディングすると大変なのでいかに回避するかが求められます。逆にメンバーが優秀故にある程度任せた方がうまく機能するパターンがあります。これをどう見極めるかが最大の鍵です。
一方で任せた≒放置することではないです。常に任せたチームの技術・ビジネス的な成果の動向には目を向けます。必要に応じて特に品質面は確認します。ここの確認を怠り無防備になると死にます（強い言葉ですが、大事なことなのであえてこの言葉を使います）。何をやっているか抑えられなくなるとマネジメント不能になるので、現時点の最も大きな課題・懸念点・作業上のボトルネックや技術的課題はチームメンバーと同期をとるようにします。また、チームが短期的な目線に陥っていないかなどに注意を払います。
注意ですが自分だけが中長期的な視点を保っているという幻想は捨てます。あくまで相対的に見ると将来目線で考えやすい（考えやすい立場であるだけです）という違いですので、中長期的なバランスと、短期的な作業とのバランスは現実を見据えてプラグマティックの立場をとります。自分だけが夢を抱いて実現しないと不満を持つのではなく、それを少しでも実現に向けて布石をうち先にすすめることこそ自分の仕事だと認識します。
③順調そうに見えても定期的に手を入れる
難しいですが、順調に回っている皿であっても定期的に手を入れる必要があります。考えるべきはメンバーのローテーション（あるいは別チームへの転籍）でしょう。なぜならマネジメントの関与度が低くて順調に推移しているということは、メンバーにとっては業務的（多くは技術的に）マンネリしていることが多いからです。この場合、ランタイムのアプリケーションの技術スタックを変更することは中々厳しく、正直ありえない選択肢ですが、運用ツールなどは新しいアーキテクチャを導入したり、一見オーバーエンジニアリングな構成を選定したりと新しい風を吹き込む方向に持っていきます。もちろん、対処には限界があるので対応の効果が見えなければ早めにメンバーを新規アサインしローテーションに向けた手はずを整えます。
④不安定な悪いお皿に対しての対処
回転が悪いとお皿が落下しそうになります。それを防ぐためには現状のチームの課題をよく観察して（なるべく、ともに入って）ボトルネック箇所を探します。「人が足りない」とチームからは良く言われますが、大体そこでメンバーを追加アサインしても人月の神話になることが多いので、メンバー追加アサインだけでは無く現状の課題も同時に対処します。
チームとして血行が良くない状況で、原因かも？と最初に推測するのは以下でしょうか。
- チームが忙しすぎる状態でヒヤリ・ハットが増えてきている黄色信号の場合
- ちょっとした修正なのに、全テストケースを実施しているなど、運用がオーバースペックになっている
- QCDのバランスが取れて無く、デリバリ最優先になっている。品質優先が崩れている
- タスクマネジメントが行われていない。チケットドリブンな開発になっていない
- 作業が五月雨になっていて、全体感を見据えた対応ができていない
- 中々生産性が上がらないと感じる場合
- ある程度は諦める。諦めて現実的なスケジュールに引き直す
- 優先順位付けで、Wantなタスクは切り捨てる
- 間接業務（多くは報告、調整）を巻き取る。大体の人はこの手の作業と開発のコンテキストスイッチで大幅に劣化します
- というか僕です
- アーキテクチャ・技術的負債を感じる場面
- すぐに修正できる技術的負債（例えば、リトライ処理の追加やログ項目周りを直すとか）はすぐ対応します
- それ以外はおそらくかなり返済に向けて厳しい工数投下ですが、信頼できるメンバーを当てて対応してもらいます
- 技術的に実直で、品質優先できるメンバーに頼ることになると思います
- 技術的負債の返済スプリントを取るというアイデアもありますが、個人的にはあまり好きではないです
- 機能開発/機能改修に才能を光る人もいる
- ある程度、ビジネス側に見える動きは継続しておきたい
- 技術的負債はそんなにすぐ終わらない。返済スプリントを取ったとして解消しない場合が悲惨
こうして条件を整えながら開発メンバーをアサインできると、新規参画したメンバーのストレスも減ると思います。地道に改善するしか無い！ってことですね。銀の銃弾は存在しないと。
⑤自分の考える時間を捻出する
テックリードでもそうかもしれませんが、中長期的な作戦を考える立場は、あるていど連続した自由に考える時間が必要です。
なんなら平日の午後は作業を全て止めてでも、今あるチームがどういう状態で、どういった武器を磨き、どこに向かうべきかに時間を投下しても良いと思います。複数チームを見るようになってからは細切れの時間でそれを行うのが難しいですが、貴重な空き時間に細かいデータ分析作業を行うのではなく、未来志向の時間をとることも忘れないようにすると良いかなと思います。
すこし立場が上がって気がついたのは、中期的な戦略が無いリーダーに対してメンバーがかなり不安になることです。何かしらの着地点を見据えたアクションを取れず場当たり的な対応を取るばかりだとメンバーもモチベーションが低下します。今損をしていたとしてもどこで得をとるつもりなのか、現在のチーム課題に対してどう考えているか、そういった内容をメンバーに聞かれて（正解は無いにしろ）自分なりの所見は述べられるようにする必要があるかなと思います。こればかりはメンバーのだれかに仕事をオフロードすることはできないかなと思います。
責任重大！ってプレッシャーに感じる必要はなく、考えた内容をメンバーに相談するのが全然ありかなと思います。そういったリーダーの荒削りかも知れない構想であっても自分の経験では快く聞いてくれるメンバーが多かったです。ディスカッションを通してアイデアをブラッシュアップすれば、自信の考えにも自信が持てます。
⑥意思決定の量は濁流で振り返れない。一撃必殺へ
次から次へ課題が舞い込むことが少なからずあります。その際に意思決定をしないと後で振り返って見る余裕がない場面も多く、マネジメント的な負債になります。そうすると相談した側の士気にも関わるので（自分だったら嫌だなと思います）、頭を振り絞ってその場で意思決定をします。もちろん全てをその場で判断するわけではなく、判断を先延ばしにすることもあり、そのための前提や条件などを考え伝えます。
こういった意思決定を潤滑に行い、ある意味ブレないためにも⑤にあるようにある程度自分なりの考えを整理しておくことをおすすめします。私の尊敬する先輩は、リーダーはその日に下した意思決定の質と数で評価されるべきだって言っていました。当時はなんだそれって思ってましたが、今では少なからず賛同しています。
⑤タスクの振り方
チームメンバーにどういったタスクを振るかで生産性は変わってきそうです。正直私も全然ですが、自分でやるか委任するかは以下のマトリクスが有名です。
| 頻繁 | 頻繁でない | |
|---|---|---|
| 単純 | 委任 | 自分でやる |
| 複雑 | 慎重に委任 | 訓練目的で委任 |
すこし直感に反しますが、この表に従うとちょっとした雑用（評価ラインのチェックとか）は自分でやる方が早いということです。そういったタスクの趣旨を説明するコストがあるからです。また、ちょっとしたデータ調査ツールなどもワンショットであれば自分で作る方が良い場面があります。
注意なのは期限がある仕事をリーダーである自分が持つと非常に危険です。本当にタスクを行う時間を捻出できない可能性があり、泣く泣く夜中に対応。集中力が下がり良くない意思決定をしてしまうと、そちらの方が影響度が大きいじゃないか、という話にもなりえます。常に頭が最高に働く状態にしておくのは半ば義務的です。
⑥インシデントへの対応
何かしらのインシデントが発生したら、できる限り一緒に対応します。特にこの手はインシデントの原因特定・暫定対応・恒久対応といった流れと同様以上に、関係者へのアナウンスやレポートが重要になってきます。チームメンバーはこのあたりのプロフェッショナルで無い場合が多いので、できる限り巻き取っていきましょう。また、ピンチはチャンスであり、インシデントに対応速度でチームの評価が上がるかも知れません。積極的に株は上げていきましょう。
また、インシデントが発生したことはチームが成長するためのキッカケになることが多いです。属人性の排除、仕組み化、技術的負債の返済、などなどのアクションプランに繋げていきます。
⑦タスクの抜け漏れチェック
目の前の開発タスクをこなしていると、ちょっとしたTODOを見過ごすことがよくあると思います（私です）。そうした場合の最後のセーフティネットはリーダーしか存在し得ないため、あのタスクの行方がどうなったか確認を怠らないようにします。バックログチケットは思い立ったら確認したり、Slackなどのチャットにタスクが流れていないかチェックします。
注意として、偏見かもしれませんが大体業務時間外のちょっと落ち着いた時間にふと「あのタスク～って大丈夫だっけ？」といった形で思い出すことが多いと思います。この時、業務時間外なのにチームメンバーへメンションを飛ばすのは当然NGです。
もしSlackをお使いであれば、予約投稿ができますので心強い味方です。ぜひ明日の10:00（9:00）以降に確認依頼を投げさせていただきましょう。
メッセージがあとで送信されるようにスケジュールする | Slack
⑧チーム外への貢献を求められる
いわゆるメンバーロールに比べると、チーム外（ややすると全社貢献）を求められるのもこのあたりのロールからかなと思います。
- 採用への協力/推進
- 外部発信への協力/推進
- 社内教育、ナレッジ蓄積、他チームへの情報共有のための資料作成
- セールスへの協力（既存、新規顧客とのディスカッション、提案用の資料準備）
- 社内交流イベントの運営
個人的に思うのはこういった作業に対して、自分の専門と関係ない（エンジニアとかそのマネジメントとじゃない）と壁を作るのは勿体無いことです。やってみるとマネジメントの幅が広がると思います。また、自分たちの仕事を知らない人たちに対し、魅力的に語る能力を身につけることは、強み・弱みをしることにも繋がり、さらに良いチーム運営の材料にもなりえます。より客観的な論理的な説明能力は、自チームメンバーへの説明力をさらに上げるでしょう。部署部門を超えての協力関係ができ上がるので、何か課題を見つけたときの突破口になることすらあります。何か悩んだときに相談できる相手（それも自分とは別の得意領域をもつ人たちです）を持つことと、それにより新しいアイデアがでてくることを経験すると間違いなく思考の幅が広がります。
自ら壁を作らず、幅広い貢献を求められた際は喜んで協力し、様々な経験を通してリーダーである自分自身を成長するキッカケにすれば良いかなと思います。
また、この手の作業に対応できるようにリーダー自信は忙しくなりすぎないことが重要です。忙しいリーダーに対しては、メンバーも相談しにくいですからね。うまくセルフマネジメント・チームとしての作業量やスケジュールの調整していきましょう（それができたら、、、という話ですが簡単に書きました。基本路線の話です）。
⑨声が枯れないようにちょっと良いマイクに頼る
急にレイヤーが物理層です。複数チームを見るようになって、会議が多いと集中力が切れがちです。また発言をしない会議は出ない勢いでカットしていますが、集中する日もどうしても発生し、肉体的にノドが痛くなります。辛いのでちょっと良いマイクを買いました。指向性マイクはおすすめです。私はグロメット式のPCアームに、マイクアームを取り付けて話しています。便利です。
まとめ
テックリード記事に比べ、Tips内容それぞれが抽象度が高い内容になってしまいました。概ね今チームがどういう状態にあるか、プロダクトの技術課題がどういう状態であるかよく観測して、対処を重ねていくことが重要かなと思います。まだまだビギナーなマネージャーですので、引き続き精進していく所存です。ありがとうございました