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

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

本書は、章が進むごとに管理者のランクも上がっていく。第一章では「部下としていかに巧みに効率よく管理されるか」、「自分の上司に何を期待するべきか」といった管理術のABCを扱う。第二章では「メンター」、第三章では「テックリード」に焦点を当てている。第四章からは人の管理、チームの管理、複数チームの管理、複数の管理者の管理、経営幹部について解説している。本書によると新任の管理者の場合、第一章から第三章までをじっくり読むのが良い。私はまだ管理者という立場ではないため、本記事では第三章までについてまとめようと思う。

マネジメントの基本

良い上司とは

• 部下を一個の人間として気にかけてくれる上司
• 部下のキャリアアップを後押ししようと積極的に働きかけてくれる上司
• 大切なスキルを教え得難いフィードバックを与えてくれる上司
• 難局を乗り切ろうとしている部下をバックアップし教訓とすべきことに気づかせてくれる上司
• いつかは自分の今のポジションに就いてもらいたいと期待をかけてくれる上司

と様々な良い上司がいる。本書で一番重要としているのは、「焦点を当てるべき要点をあなたが把握する手助けをしてくれるばかりか、実際に焦点を当てられるよう計らってくれる上司」である。
部下とチームが本筋から離れないよう上司に果たしてもらいたい務めや役割が複数あるはずなので、それを明確にし上司に求める必要がある。

上司に求めるべきこと

1on1

上司に求めるべきことの第一は1対1で行うミーティングである。
1on1は直属の上司と仕事上、良好な関係を保っていく上で不可欠な要件である。
1on1の目的は大きく2つある。一つ目は、部下と上司との間に人間的なつながりを作ることである。上司が部下を一個の人間として気遣ってくれるような関係にあれば、上司に休暇を願い出るなどの頼みごとをするのもはるかに楽になる。二つ目は要検討事項について上司と1on1で話し合う定期的な場を設けることである。部下側でも事前に態勢を整えられるよう、スケジュールはある程度予測可能な形で組めると良い。こうすることで、議題を事前に部下側が決めておくことが可能になる。1on1が現況確認会議は相手にとっては繰り返しが多く退屈なものとなる可能性が高い。そのため、1on1は上司と膝を突き合わせて話し合いたいテーマや問題を引っ提げて臨むべきである。

フィードバック

上司に求めるべきことの第二はフィードバックの提供である。
人間誰しも失敗は避けて通れない。部下が失敗して、それに気づかずにいたとしても、できる上司であればすかさず教えてくれるはずである。そのフィードバックを悪いものと考えるのではなく歓迎する必要がある。部下の振る舞いについて苦言を呈してくれる人がいなければフィードバックが一切得られない、あるいは勤務評価の段階になって初めて知らされるといった事態になる。そのため、部下の悪い癖や習慣は早く知れば知るほど直しやすい。また、業務の価値を部下にしっかりと理解させ、日々の職務に関する目的意識を持たせてくれる上司は本当にできる上司である。毎日の平々凡々な務めでもそれが会社全体の成功にどう役立つかがわかれば、部下の誇りの源ともなり得る。

管理のされ方

できる上司は管理のされ方も心得ている。
職場で自分が経験することに対して当事者意識や主体性を持ち、上司との関係づくりにおいても上司任せにしないことこそが、職場で充実した日々を送り満足のいく形でキャリアを積んでいく上で重要な姿勢である。
　部下の成長につながる機会を教えてくれることなら上司にもできる。しかし、部下の心を見抜いたり、何が部下を幸せにするのかを教えたりすることはできない。自分自身が何を望んでいるのか、何を学びたいのか、何が自分を幸せにするのかを考え抜いて明らかにする責任はひとえに自分自身が負っている。そのため、自己分析し自分を知る必要がある。己を知った上で、次のステップは「望みをかなえるための努力を惜しまない」である。望みはすべてが叶えられるわけではない。また、希望を言い出しにくい場面もある。ただ希望を表明することは前に進む一番手っ取り早い方法である。公平な上司であれば、「希望をはっきり知らせてくれて良かった」と言ってくれる可能性もある。つまりは、自分なりの目標を定めたら、実現に向けて手を尽くす責任は自分自身にある。
　

メンタリング

メンターとは一般にチームの新人に1対1で仕事上の指導や助言、精神的なサポート等を行う専任のコーチのことである。

メンターの務め

メンター役を果たすように仰せつかった人はとても幸せである。誰もが経験できることではないし、人を管理する仕事がどういうものなのか、他社への責任を負うことがどんな感じなのかを、あまり責任を負わずに学べる好機である。多くの指南役に起こりえる最悪の事態としては、「新人や研修生が無能なために指導が徒労に終わり、プログラミングの作業にも支障が出てしまう事態」、「指南役の指導がまずくて有望な新人や研修生が不満や不快感を抱いたり、短期間で辞めたり他社を選んでしまう事態」の2種類があげられる。メンターとしての責任を軽視するような無能なメンターにより、逸材が機会を奪われることがある。
メンターを成功させるには、焦点を絞った計測可能で明確なゴールを設定することが必要である。メンティーがメンターの支援を仰ぐコツやこの関係を有意義に活用するコツを心得ていないと「義務的なおつきあい」のような感じになり、どちらにとっても単なる時間の無駄となってしまうことが多い。メンタリングは自分のチームと有望な若手の能力や功績を認め、未来のリーダーとして育成する好機と考え活用する。

メンターの選び方

まず、メンタリングプログラミングを新設する際には、実際にメンターとメンティーを組ませる前に、開始後の指導の枠組みや管理者によるメンターの指導環境が整備できているかどうか確認する必要がある。次に、「メンターにとっては担うべき責任がこの関係でさらにひとつ増えることになる」という点も考慮する。メンターという役割でも有能なエンジニアの場合、指導期間中は自身（エンジニアとして）の仕事の生産性がいくらかは落ちる可能性が高い。
また、メンタリングを設定する上でありがちな以下の2つの落とし穴には注意が必要である。

• メンタリングを低レベルな感情労働（自身の感情を抑制することが職務の一環であるタイプの労働）と誤認してしまう。
• 「〇〇タイプのメンティーには〇〇タイプのメンターを付けるべき」といった固定概念を押し付ける

メンター、メンティーの関係はチームの可能性をじかに探る好機である。そのため事前にきちんと計画を立ててメンターに時間を十分与え、丁寧なメンタリングにより望ましい成果を上げる必要がある。また、女性のメンティーには女性のメンターを付けるべきなどと決めてかかってはいけない。メンターとメンティーを組み合わせる際にはそれぞれのメンティーの立場や状況に最適なメンターを選び引き合わせる必要がある。例えば、ある業務スキルの向上を目的とするメンタリングでは、そのスキルに熟達した先輩をメンターに選ぶべきである。

メンターの重要な心得

メンター役を果たす際の大事な心構えを3つ紹介する。

• 常に好奇心を絶やさずオープンな心で
  エンジニアが心を閉ざし、学ぶことをやめてしまうとキャリアの維持やアップに必須のスキルが衰え始める。身の回りのテクノロジーは常に変化し続けているので、エンジニアはそれを絶えず敏感に察知できる必要がある。メンタリングはメンターにとっては新人のフレッシュな目を通して世界を見つめ、好奇心を刺激してもらう絶好の機会である。仕事を1から覚えようとしている新人を指導していると、隠されたパターンが突然見えてきて普段なら思いもつかないやり方が見えてくる。

• 相手の言葉をよく聴き、相手の言葉で話す
  メンタリングで成果を上げているうちに、リーダーにとって必須のスキルが漏れなく磨かれていく。メンタリングでは否応なくコミュニケーションスキルが磨かれていく。とくに傾聴のスキルに関しては訓練がモノを言う。メンターとメンティーが良好な関係で仕事を進めていくには、相手が理解できるやり方で傾聴し意見を伝達できなければならない。

• 人脈づくり
  キャリアの最終的な成否を左右する重要な決め手は人脈である。それを拡大、強化する効果がメンタリングにはある。例えば、メンティーが将来メンターのもとで働く可能性だってある。
  メンター、メンティーは「人ひとりのキャリアは長く、テクノロジー業界は狭い。だからどんな相手にも丁重に接する」ということを肝に銘じておくべきである。

テックリード

テックリードとはプロジェクトに携わるエンジニアチームの技術上のリーダーのことである。
テックリードに必要なスキルとして、技術面だけでなくコミュニケーション能力も必要である。極端に緊張せずにプレゼンテーションをしっかりとこなせたり、他チームや他の役割の人たちとも臆さずに話し合い、経過や事情を丁寧に説明したりと実際的な適応力が必要である。つまりテックリードはリーダーシップが求められる役割である。
プログラムの作業に没頭したいと望む人はテックリードの適任者ではない。テックリードに求められるものとしては以下である。

• 部下に効率よく仕事を割り振って自身の負担を適宜軽減するように心がける
• チーム全体の生産性に照準を定めしかるべき成果を上げるよう全力を尽くす
• チームのために自主的な判断を下す権限を与えられ、管理やリーダーシップに関わる難局を打開する方法と、製品、分析など社内の他部門と効率よく協働する方法を習得する

テックリードは、技術的なプロジェクトのリーダー役を果たしより大きなスケールで自身の専門知識を駆使してチーム全体の向上を図る立場である。技術力も大切ではあるが、対人能力がより大切になる。

テックリードに必要な知識

テックリードには、実際のプログラミングの作業から一歩引き、「技術面での貢献」と「チーム全体のニーズへの対応」のバランスをとる力が必要になる。そのためにはまず、自分の時間を確保しそれを使いこなすコツをマスターしなければならない。

テックリードの役割

テックリードが最優先しなければならないのは「プロジェクトを推進するため、常に大局的な視点を失わないこと」である。
自分ひとりが担当するプログラミングの作業の計画・調整からプロジェクト全体の計画・調整と主導へと視点を変えるには以下の3つの役割を理解する必要がある。

• システムアーキテクトとビジネスアナリストとしての役割
  プロジェクトを完遂しデリバリを実現するには基幹システムのどこを改変すべきか、どの機能を構築すべきか見極める必要がある。そのために対象のシステム全体の構造の十分な把握と複雑なソフトウェアを設計するための方法に関する理解が欠かせない。また、ビジネス要件に対する理解とそうした要件をソフトウェアに織り込む能力も求められる。

• プロジェクトプランナーとしての役割
  プロジェクトプランナーとしての役割は、作業をデリバリ可能な単位に大まかに分割するというものである。この責任を担うことで、チーム全体が作業を迅速に行えるように業務を分割するための効率的な手法を習得できる。ここでの狙いは、作業をできるだけ同時並行で進めてもらうことである。そのためにはみんなが合意できるよう並行作業が可能な部分をうまく抽出することである。

• ソフトウェア開発者兼チームリーダーとしての役割
  ソフトウェア開発者兼チームリーダーとしては、自らプログラミングの作業をこなしつつ、メンバーに課題を伝えたり作業を任せたりする任務を果たす。テックリードになってからもコードを書く仕事は続けるべきだが、やりすぎは禁物である。問題が生じた場合は、自分独りで解決しようとするのではなく、まずはその問題をみんなに伝える必要がある。

テックリードはある作業を自分独りで完遂するべき場合とメンバーに任せるべき場合をきちんと心得た上でソフトウェアの開発者としての役割、システムアーキテクトとしての役割、ビジネスアナリストとしての役割、チームリーダーとしての役割のすべてを適宜こなさないといけない。優秀なテックリードは以下について理解できている。

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