エンジニアのためのマネジメントキャリアパスを読んだ

エンジニアのためのマネジメントキャリアパスを読んだ。

チームのマネジメントから始まり、複数チームのマネジメント、マネージャーのマネジメント、経営幹部と各段階における心構えを概観できた。

個人的にはチームのマネジメントはやったことがあり、複数チームのマネジメント辺りまではリアリティを伴って読むことができたが、管理者の管理など、それ以上はまだリアリティを持てなかったので、必要になった段階で再読しようと思った。

著者はマネジメントキャリアパスを進む前に、最低でも 1 種類のプログラミング言語を自在に使いこなせる程度の技術力は身につけておかないと、技術力不足とみなされキャリアパスが頭打ちになることがあると繰り返し言っており、個人的には DeNA 時代はマネジメントはやらないと宣言して技術研鑽だけしていたのは正解だったのかもと思うなどした（それが功を奏すのかはまだ何もわからないが）。

目次

• 1章 マネジメントの基本
• 2章 メンタリング
• 3章 テックリード
• 4章 人の管理
• 5章 チームの管理
• 6章 複数チームの管理
• 7章 複数の管理者の管理
• 8章 経営幹部
• 9章 文化の構築

3章 テックリード

著者によるテックリードの定義

テックリードはエンジニアの階層におけるランクのひとつではなく、シニアのレベルに達したエンジニアが担うことのできる職責群である。 管理職がテックリードの役割を引き受けることもできるが、その場合も含めてテックリードは(以下にあげる)RTRの厳しい基準を守ってチームのメンバーを管理するものとする。

• 各メンバーと定期的に(週 1 回)1 対 1 のミーティングを行う。
• 各メンバーにキャリアアップや作業の進捗状況、改善点、報奨などについて、権限内で定期的なフィードバックを与える。
• 各メンバーの研鑽を要する領域を、そのメンバーと共に見きわめ、その領域の能力強化を、プロジェクトでの職務遂行、外部での学習、メンタリングを介して支援する。

チーム外の者がテックリードの役を引き受ける場合でも、チームのメンバーに対する指導・育成役を果たすものとする。

立場であるため、細部まで厳しく管理して部下に裁量権を与えない微細管理に 陥ることなく、部下に効率良く仕事を割り振って自身の負担を適宜軽減するよ う心がける必要がある。

そしてチーム全体の生産性に照準を定め、しかるべき 成果を上げるよう全力を尽くさなければならない。また、チームのために自主 的な判断を下す権限を与えられ、管理やリーダーシップに関わる難局を打開す る方法と、製品、分析など社内の他部門と効率良く協働する方法とを習得することが求められる。

エンジニアとして昇格を果たす上でテックリード役を引き受けることは必須 ではないものの、エンジニアは通常、シニアエンジニア 1、シニアエンジニア 2、 エンジニアリングリード(主任エンジニア)の順に昇格し、シニアレベルの統 率力と責任はきわめて重要であるため、現実的に見てテックリード役を経験せずにシニアエンジニア 2 より上の職位に就くことは、たとえ部下をもたないエンジニアの立場ででも非常に難しい。

ThoughtWorksのパトリック・クアによる定義

テックリードとは（ソフトウェアの)開発チームに対する責任を担い、最低でも自身の職務時間の3割はチームと共にコードを書く作業に充てているリーダーのこと。

3.7 優秀なテックリードとは

• アーキテクチャを把握している
• チームプレイの大切さを心得ている
• 技術的な意思決定を主導する
• コミュニケーションの達人である — 書く力、話す力を伸ばす時期

技術力がない段階で指導的役割を担い始めてしまうと、将来もっと上の職位に就いてから「技術力不足」を理由に管理職への昇格が難しいと判断されてしまう恐れがあり、キャリアの点で大きなダメージを受けかねない。

4章 人の管理

1st one-on-one question

• 優れた功績や言動などに関して褒められる場合、人前でも構いませんか、それ とも 1 対 1 のほうがよいですか(人前で褒められることをひどく嫌う人もいま すから、この質問に対する答えはぜひとも聞いておきたいものです)。
• 重要なフィードバックの伝え方は、どういったものを希望しますか。じっくり 検討できる書面でのフィードバックがよいですか、あるいはあまり形式張らな い口頭でのフィードバックのほうが気が楽でしょうか。
• この部署(チーム)で仕事をしようと決めた理由は何ですか。希望、意欲、期待等を聞かせてください。
• 君が不機嫌な時、悩んだり苛立ったりしている時は、傍はたから見てどんな感じ か、教えておいてください。いつも君を不愉快な気分にさせる要因があり、そ れを私が事前に知っておくべきなら聞かせてほしいです
• 耐え難いと思う上司の振る舞いがあれば言っておいてください(私なら「 1–1をサボッたり、1–1の中止や日程変更をしょっちゅう命じたりする上司、 フィードバックをくれない上司、やりにくい会話を避けたがる上司」などと答 えると思います)。
• キャリアアップの明確な目標がありますか。それを私が知っておけば、その実 現に役に立てるかもしれません。
• この部署(チーム)に来てから、何か私に言っておきたいことができましたか。
• 返答として考えられるのは、たとえば「私の場合、自社株購入権はどうなって るんでしょうか」「配置転換に応じたらボーナスをくれるっておっしゃってまし たけど、まだいただいてないですよね」「なんで Git じゃなく SVN を使ってる んですか」「こんなにすぐお役に立てるなんて思ってもみませんでした」といっ たものです)

https://larahogan.me/blog/first-one-on-one-questions/

• 今後 1ヵ月/ 2ヵ月/ 3ヵ月の計画を立てさせる
• 新人研修用のドキュメントを更新させてチームに対する理解を促す
• 自分の流儀や要望をはっきり伝える
• 新人からもフィードバックを得る

4.3 1–1の進め方

• TO-DOリスト型 — Google ドライブのスプレッドシートを部下と共有して、話し合いたいトピックが思い浮かんだら随時記入できるように
• キャッチアップ型 — 1–1 で尋ねる
• フィードバック型 — 1–1 を非公式なフィードバックやコーチングの場として使う
• 経過報告型 — 避けるべき。プロジェクトの経過報告を受けるだけ。プロジェクトのステータスとは無関係な質問を投げかけよう。

1–1 の議事録は共有ドキュメントの形で作成し、管理する。勤務評価の材料にもなる。

4.5 効率よく仕事を任せるために──実践的アドバイス

• チームメンバーに尋ねる前にシステムからの情報収集を — JIRA, Github からパフォーマンスを計測
• マイクロマネジメントより、報告の仕方を教える
• 実際に勤務評価を書くより前に、継続的にフィードバック

マイクロマネジメントを避けるには、もしも週45時間しか働いてはならないのだとしたら、その45時間をどう使うか考える。若手開発者の書いたコードを逐一調べてあら探しをするのに使いはしまい。

4.7 勤務評価

• 直近の 2、3 ヵ月だけでなく過去 1 年全体に目を向ける
• 具体例をあげ、皆のフィードバックからの引用も使う
• 功績や長所の報奨にはたっぷり時間をかける — 指摘だけを欲しがる人もいるがしっかり褒める
• 要改善点を書く時は焦点を絞って
• 部下を驚かせてはならない — 継続的フィードバック

4.8 キャリアアップの取り組み

• 自分の会社では部下の昇進に関してどのような方針と手続きを取っているかをきちんと把握しておくこと

4.9 やりにくい仕事──成績不振者の解雇

• 継続的フィードバックが記録になる

4.10 自己診断用の質問リスト

• 直属の部下と定期的な 1–1 を計画した経験がありますか。
• キャリアアップについて最後に部下と話し合ったのはいつですか。「 3 ヵ月以上前」と答えた人にお尋ねします──次回の 1–1 でこの件を忘れずに持ち出すことができるでしょうか。
• 先週、部下にフィードバックを与えましたか。最後に「チームのひとりを皆の前で褒める」ということをしたのはいつでしょうか。
• 訓戒を要する言動をチームの誰かが最後にしでかしたのはいつでしょうか。その言動に関する批判的なフィードバックを与えたのは、どの程度の時間が経過 してからでしたか。与えた場所は、人目のない所でしたか、それとも人前でしたか。
• あなたがこれまでに受けた勤務評価のうち、「何の役にも立たない、単なる時間の無駄」と感じたものはありますか。その勤務評価は、どのような点を補えば、もっと有意義なものになったと思いますか。
• あなたがこれまでに自分の職務に関して与えられたフィードバックの中で一番有益だと思うのはどのようなものでしたか。それはどのような形で与えられましたか(口頭、書面など)。
• あなたは自分の会社の昇進の規則や手続きを把握していますか。「知らない」と答えた人にお尋ねします──誰かに詳しく説明してもらうことは可能ですか。

5章 チームの管理

エンジニアリングリードの定義

エンジニアリングリードになるとコードを書く作業に費やす時間は減るが、 チーム全体の作業の進行を遅らせたり妨げたりしなければ、小規模な技術的成 果物の作成(バグ処理やちょっとした機能の作成など)に携わるべきである。

エンジニアリングリードは、そうしたコードを書く作業以外に、チームの作業 の遅滞を招くボトルネックや成功を妨げる問題を突き止め、これを解消する責任を負う。この役を引き受けた者は組織全体の成功に多大な貢献をするものと期待される。

とくに、もっとも価値のあるプロジェクトを見きわめ、そうしたプロジェ クトに自身のチームを集中的に従事させる権限を有する。そのための取り組み の一環としてエンジニアリングリードはプロダクトリードと緊密に協力してプ ロジェクトの範囲を調整し、技術的成果物を確実に構築する。また、エンジニ アリングリードはチームに必要な人数を確認し、その確保のための計画立案と 人材募集を行う権限も有する。

エンジニアリングリードは独立した管理者であり、自分とは異なるスキル セットをもつメンバーから成るチームを管理する権限と能力を有する。チーム のメンバーに期待する能力や言動、成果は、全員に明確に伝え、個々のメンバー との間で(勤務評価の期間に限らず常日頃から)こまめにフィードバックを提 供し合うべきである。こうした優れた管理スキルに加えてエンジニアリング リードに求められるのは、(主力)製品グループに関する技術的ロードマップ を管理するリーダーの役割である。スケジュールと範囲とリスクを主要パート ナーに明確に伝え、主要なマイルストーンのデリバリ作業を明確なスケジュー ルに従って主導する。さらに、戦略に関わる技術的負債(場当たり的なアーキ テクチャや余裕のないソフトウェア開発のせいで生じたツケ)を感知し、その 解消を見据えた費用対効果分析(CBA: cost-benefit analysis)を行い、その 結果得られた解消優先のスケジュールを経営陣に提示するものとする。

5.1 ITスキルの維持

技術系管理者はコードも書き続けていないと、十分 キャリアアップができないうちに技術力が頭打ちの状態になってしまう恐れがあります。

5.2 機能不全に陥ったチームの 「デバッグ」 の基本

計画立案の段階で、 管理者としての職務時間の2割をシステムの「持続可能性」(技術的負債の解消)のための作業に確保することを推奨します。

対立を解決しようとする際の 「べし・べからず集」

• 他チームへの責任転嫁は禁物
• 誰しも人に好かれたいのはやまやまだが、管理者は「優しさ」よりも「親切」 を旨とすべし

新来の管理者になった場合

• システムとアーキテクチャ、テストとリリースの手順を詳しく教えてもらう
• 機能を作って、リリースまで経験しておく

5.8 自己診断用の質問リスト

チームの管理者になった人が新たに担う職責とは? あなたがそうした職責を 果たす時間を捻出するために、やめてしまった作業やチームの他のメンバーに 譲った作業には、どのようなものがありますか。

• あなたのチームがコードの作成やデプロイ、サポートに関連して日々直面して いる課題を、あなたはどの程度把握できていると思いますか。
• あなたのチームが「作業完了」を報告する頻度は?
• あなたが最後に、機能を作成したり、デバッグしたり、あるいはコードの作成に手こずっているメンバーとペアを組んであげたりしたのはいつのことですか。
• チームにひどく好ましくない影響を与えるメンバーがいますか。「いる」と答え た人にお尋ねします──そうしたメンバーの起こした問題を解決して作業を進展させるために、あなたが考えている計画は?
• あなたのチームの人間関係はうまく行っていますか。ミーティングは和やかな雰囲気で進められていますか。おしゃべりをしたりジョークを飛ばし合ったり することがありますか。お茶やランチを共にすることがありますか。最後に皆 で集まって仕事以外の話をしたのはいつのことですか。
• あなたのチームの意思決定の方法は? 意思決定を特定のメンバーに委ねる場 合のルールや手順はありますか。管理者であるあなた自身が責任をもって下す 意思決定にはどのようなものがありますか。
• プロジェクトが完了した時点でレビューを行い、目標を果たせたかどうかの確 認をあなたが最後にしたのはいつですか。
• 現在進行中のプロジェクトをチームが担当している理由を、あなたのチームは どの程度理解できていますか。
• あなたが最後にプロジェクトの範囲を削ったのはいつですか。どこを削るかを 決める際、何を判断材料にしましたか。

6章 複数チームの管理

技術部長

技術部長は技術チームの重要な職務に関する責任を担い、通常、複数の製品 分野または複数の技術部署のエンジニアを統率する。テックリードにとっても、 部下をもたないエンジニアにとっても、この技術部長が直属の上司となる。

技術部長にとって日常レベルでコードの作成作業に携わることは職務上の義務 ではないが、全社レベルの技術力を維持、強化する責任を負っており、必要に応 じて研修や人材採用によりチームの技術力を強化するものとする。技術部長は優 れた技術的経歴と実績をもつ者が務めるべきであり、執務時間の一部を充てて最 新技術に関する調査を行い、IT 業界の最新動向を常時把握する。

また、技術部長はデバッグや問題を抱えたシステムのトリアージ(優先度付け)を支援し、監 督するシステムについては、必要に応じてコードレビューや問題の調査の支援が できるほど十分に理解していなければならない。アーキテクチャとデザインに関 わる作業には、主として、チームのエンジニアに事業や製品についての質問を投 げかける「事情に明るいベテラン技術者」として貢献し、チームで作成中のコー ドが製品や事業のニーズに合致することと、そうしたニーズが増大した場合に適 宜システムの規模を拡張できるよう万全を期するものとする。

技術部長が第一に重視するべきなのは、複雑な成果物が順調に提供されるよ う計らうことである。そのため、会社に持続的に価値をもたらし得る技術を生 み出すべく、開発およびインフラにおける標準やプロセスを絶えず評価、改善 する努力を重ねなければならない。また技術部長はプロセスの評価と反復によ り良好な結果を迅速に出せる組織を築き上げる責任も負っている。さらに、人 材の募集と採用、人員数の管理と計画、全社レベルのキャリアアップと研修も 主導するものとする。これに加えて、必要に応じて、ベンダー各社との関係を 管理し、予算編成にも参画する。

技術部長の影響力は、技術部門の複数の領域に及ぶ。技術部門で次世代のリー ダーや管理職となり得る人材を発掘、育成し、そうした人材が技術系の職務と管 理系の職務をバランス良くこなすコツを習得するのを支援する責任を負う。また、 モチベーションが高くひたむきで、大きな成果を効率よくあげられる組織を生み 出すことに重点を置き、担当組織で人材維持目標を達成することも求められる。 加えて、技術部長は短期的または長期的な、製品または事業に関わる業務と技術 的負債や戦略的な技術開発とのバランスを戦略的に取る責任も負っている。

技術部長は(技術部門と他部門の協働も、技術系の部署間の協働も含む)部 門間協力で部下の手本となる有力なリーダーである。この部門間協力の狙いは 「ビジネスニーズ、事業効率と収益、根本的な技術革新に関わる取り組みの戦 略的、技術的ロードマップを作成すること」である。また、技術部長には優れ たコミュニケーション能力が求められる。非技術系の協力者に対しては技術概 念を平易な形で説明でき、技術チームに対してはメンバーを鼓舞し主導する形 で事業の針路を説明できなければならない。さらに技術部長は RTR の技術に 関して良好な社会イメージを生み出し、同社とその事業領域を潜在顧客に売り込む努力も重ねるものとする。

このように技術部長は幅広く技術部門にも事業推進部門にも関わるため、組織内のすべてのチームの目標設定プロセスを主導する立場にある。事業戦略の 点でも、技術面や組織面の質の向上という点でも有用な目標をチームに立てさ せる責任を負っているのである

技術部長

「技術部長はコードを書く作業に必ずしも毎日携わらなくてよい」

部長職を引き受ける前にたっぷり時間をかけてコードを書く作業を十分経験し、最低でも 1 種類のプログラミング言語を自在に使いこなせるようになっているべき。