⛑️

初めてマネージャーになるエンジニアのための手引き

2022/05/31に公開

idea

(noteから転載しました)

この記事は何？

数名程度の小規模なエンジニアチームにおいて、初めて「部下をマネジメントする」立場になった人向けに、マネージャーとはどういう役割なのか、気をつけるべきことは何か等を伝える記事です。
主にピープルマネジメント（人のマネジメント）の部分に焦点を置いています。
- ピープルマネジメント以外の領域が何があるのか知りたい場合は、以下参考記事などを見てください
想定読者は、部下を数名持っているくらいのエンジニアチームのマネージャー、特に若い部下（学生バイトやインターン生、エンジニア歴1,2年目の社会人）を持っているマネージャです。

参考記事：エンジニアリングマネージャ/プロダクトマネージャのための知識体系と読書ガイド

この記事を書いたきっかけ

去年から外部の技術顧問みたいなポジションで手伝ってる小さな企業で、今年から所属エンジニアメンバーの「チーム分け」をすることになり、「チームリーダー」が３名生まれた
３名とも、部下を持つのは初めてであり、エンジニアとしての歴も浅い。マネジメントについて教えられる人が社内にいない。筆者が３名のメンターをやっているが、「マネジメントとは何か？」についてちゃんと伝えるのが難しいので、一度自分が意識していることをちゃんと言語化しようと思った

1. マネージャーの役割とは

筆者なりに定義すると、「メンバーの一人一人の努力が、個人と組織両方のハッピーにつながるような状況を作り出すこと」、もう少し簡単に言えば「メンバーの努力が無駄にならないようにすること」である。

プレイヤーの役割は「目標に向かって努力すること」<-> マネージャの役割は「メンバーの努力が良い結果につながるようにすること」
- 車におけるエンジンとハンドル（もしくは整備士）の関係を思い浮かべるとわかりやすいかもしれない。メンバーの努力がエンジンとなるが、マネージャーは「エンジンが動けば目的地にたどり着けるようにする」ために、車の進む向きを整えたり、車体を点検したり、それぞれのエンジン同士の進む向きが衝突しているときに、噛み合うように直したりするのが仕事である。
プレイヤーとマネージャーの役割の違いを認識しておくことは非常に重要である。
- マネージャとしての役割を果たせていないことを、プレイヤーとしての忙しさでごまかしてはいけない。 ハンドル操作を間違えた状態で闇雲にエンジンを吹かしても、メンバーみんなが消耗するだけで、良い結果にはならない。「努力しない方がマシ」な状況を生み出してはいけない。
- 小さいチームだと、だいたいプレイングマネージャになるので、マネジメントだけに集中するのは難しいが、それでもプレイヤーとしての役割からマネージャとしての役割を区別し、きちんと評価すべきである。そうでないと、マネジメントが崩壊していても、誰もそれを問題として指摘できなくなる。
プレイヤーは努力の量で評価されるかもしれないが、マネージャーは努力の量で評価されるべきではない。
- エンジンの仕事量は排気量で計っても良いが、ハンドルの仕事量を回転量で評価するのは誤りである。
- マネージャーが常にタスクアサインなどの定常業務やトラブル対応でパツパツになっているとすれば、危険信号である。平時は少し時間が余っているくらいが望ましい。故障が起きていない時に整備士が車を無闇にいじくり回すべきではない（もちろんパフォーマンスアップのためのチューニングはやっても良いけれども）。極論、「メンバーの努力が皆にとって良い結果につながる」状況が担保されているなら、マネージャーは何もせず寝て暮らしていてよいというのが筆者の考えである。
上述のようなマネージャーの役割の考え方を飲み込むには、まず先に結果責任という考え方を理解する必要があるかもしれない。原因と責任を区別し、結果を達成できなかった原因があなたになくても、その責任はあなたにあることを理解せよ。

2. マネージャーが達成すべきこと

ここでは「メンバーの一人一人の努力が、個人と組織両方のハッピーにつながるような状況」とは何かを定義する。

2-1. 組織として求められる成果を出す

チーム全体として期待されている成果を出ていること。マネージャーの重要な役割だが、ピープルマネジメントという観点からは逸脱するので本記事では詳しく触れない。

2-2. メンバー全員が組織に十分に貢献している

一人一人の貢献量が求められる水準に達していること。ピープルマネジメントという観点では語られないことが多いが、個人的には一番重要な観点だと思っている。

自分以外のメンバーを含め、誰もが大事な役割を担っており、組織に必要不可欠な貢献をしているという感覚が、（特にベンチャー企業においては）居心地のよいチームづくりに必須のものである。ほとんどのケースにおいて、チームに不和が起こるのはこの感覚が守られなくなった時である。

自分一人では出来ないことを達成するためにチームに所属するわけで、「チームメイトが自分だけではできないことをやってくれている」と思えることが、チームへの愛着や尊重の気持ちを持つための前提であると思う。

特にインターン生などの若いメンバーにとっては、周囲に貢献できた経験を早期にたくさん積ませることが、自信を持つ上で最重要な要素だと思っている。

2-3. メンバーのwillが尊重されている

一人一人が、自分のwillが尊重されていると感じられること。

マネージャーは、可能な限り、すべてのメンバーのwillを認識し、叶えられるように努力するべきである。

とはいえ、現実には全てのwillに応えることはできない。例えば、「インフラ系のスキルを伸ばしたい」というニーズを持っているメンバーがいるにもかかわらず、今のチームではちょうど良い案件はない、ということがままある。

仮に特定のwillを満たせていないならば、そのwillを満たせていないことを把握していることを伝え、そのwillを満たすためには今後本人と組織のそれぞれ何が必要なのかを伝えるなどして納得感を作ることが大事である。何も言わずにwillを無視し続けると、不信感につながり、マネジメントが崩壊する。

とはいえ、個人のwillは常に変化しているし、本人も自分のwillを理解していないことがしばしばある（というかむしろその方が多い）。特に学生などの若いメンバーは、自分のやりたいことが何なのかわかっていなかったり、揺らいでいたりすることが多い。

「自分のやりたいこと」がわかっていない相手、解像度が低い相手に対しては、相手が口で言ったことを鵜呑みにせず、さまざまな角度・頻度で確認をすると良い。「何があれば自分のやりたいことがわかりそうか？」について話し合い、必要な経験を積める機会や検証の場を用意する。まだ本当にやりたいかどうかわかっていないことに対し、早すぎるコミットメントを要求してはいけない。

部下のwillの解像度を上げていくには、コーチングの技術が有効である。マネージャ向けの入門書がいくつかあるので読んでみても良い。

2-4. メンバーが成長を実感できており、「ここにいれば成長できる」と感じられること

メンバーが「期待に応えていれば、自分は成長できる」と思えること。マネージャーはメンバーの将来に責任を持ち、メンバーが成長する上でその時々に必要な経験やリソースを用意するべきである。

適切なタイミングで、適切な期待と機会を与えることが人材育成においては最も重要である。人生には、タイミングごとに必要な経験がある。必要な経験を用意できるよう、適切なタイミングで適切なタスクを用意するのもマネージャーの仕事である。

「成長」というと、意識が高くて嫌な感じがするかもしれないが、「ここにいれば成長できると感じられること」は、むしろ人が"安心"して生きていくための前提条件である。特に若い世代は「何もせずにどんどんと時間がすぎていくこと」に対する不安を持っているケースが多い。小中高くらいまでは学校に行っているだけで「レールに乗っている」が、大学生くらいからはそうはいかなくなってくる。乗るかどうかは別として、レールを敷いておくのは社会人の先輩の義務であろう。（もちろん、敷かれたレールを踏み外し、保証されていない不安な世界に飛び出すのも、それはそれで若者の選択として尊重すべきである）

3. マネージャのタスク

上述の内容を達成するために、具体的にマネージャーが何をすればいいのか、その手段について記述する。

マネージャーは主に目標設定という手段を用いる。つまり、「メンバーが何に向かって努力すべきか」を定義することである。これがメインウェポンであり、それ以外の手段はサブウェポンであると考えて良い。

目標さえ与えれば、メンバーが目標達成のために必要なタスクを自分で定義できる場合は必要ないが、そうではない場合はタスクのアサインもマネージャーの重要な仕事である。DONEの定義を明確に記述するなどして、アウトプットイメージを適切に擦りわせることが重要である。

メンバーがタスクをこなす上で必要なサポートを用意するのもマネージャーの仕事である。サッカー部のマネージャーが走り続ける選手のために水入りのペットボトルを用意するのと同じである。プレイヤーが戦い続けられるように武器や補給を整えるのである。プログラミングのタスクの場合、具体的には、困ったことがある時に質問できる先を用意することやレビューの機会を用意するなどの非常に基礎的な環境を整えることが重要である。

目標が設定できると、その目標達成に必要なタスクを定義できる。メンバーがタスクに取り組み始めたら、タスクを行う上で必要なサポートを用意する。1. 目標、2.タスク、3.サポートの3つが問題なく整っている時、そのメンバーの状況は「問題なし」と判断する。

1on1などの状況確認の場においては、この3つの状態がヘルスチェックの指標になる。筆者の場合、部下とはだいたい1ー2週に1回くらいの1on1を行い、この3つが問題が起きていないか確認する。

4. タスクを任せるときの選定基準

目標設定、およびタスクのアサインの時に気をつけるべき点について記述する。

4-1. そのタスクは取り組む価値があるか？

目の前のメンバーを尊重しようと思うならば、まず第一に取り組む価値のある目標を任せるべきである。
- その人の組織への貢献量は、マネージャーが任せる目標やタスクに制約される。組織にとって達成する価値のない目標やタスクを任せた瞬間、そのメンバーは、この組織において大きな貢献を果たすことがその時点で不可能になることを心得よ。問題設定が優れていなければ、どれだけ努力しても良い成果にはつながらない。
組織にとっての重要度は高くないが、教育のためにあるタスクをアサインしようとしている場合は、以下の点を注意せよ。
- 機会だけを与えても、適切な期待を与えられないのであれば、教育効果は劣る。「なんとしてもあなたのこのタスクをやってほしい理由」が説明できないのであれば、そのタスクアサインは教育としても機能しない可能性が高い。
- 本当にその経験が部下にとって今まさに必要なのか、一度立ち止まって考えるべきである。マネージャーが「教え方がわからない」ので、タスクアサインという安易な手段に逃げていないか？
- 今の組織に存在する、より重要度の高いタスクの中で、本人にとって必要な経験を与えられないか考えるべきである。タスクを適切に分解したり、他の人からタスクを持ってくることで解消できる場合が多い。

4-2. そのタスクに学びはあるか？

タスクの難易度
- 育成中の若いエンジニアに対しては、基本的には 「今すぐ何も見ずにやれと言われたら無理だが、調べる時間や周囲のサポートが少しあれば、ほぼ自分一人でこなせるギリギリの難易度」のタスク を渡し続けられるのが理想である。
- プログラミングタスクは、大抵の場合「他人のサポートあり」で一回できれば、その次は自分一人でもできる。そうやってできることを増やしていく。
- 逆に、ほぼ他人に頼り切りになるタスクや、何も迷わずにできるタスクはできる限り避ける。それは単に学びがないだけではなく、本人の自尊心や学習へのモチベーションを低下させる。
スモールステップを意識し、タスクの難易度やタスクの切り出し方、サポートの量を調整することで、難易度の調整を行う。特に難しそうなタスクを渡す場合は、こまめな1on1を入れるなどして状況確認の頻度を増やす。
タスクの「お手本」度
- 基本的には、「一般的なもの」「ドキュメントがそろっているもの」から「特殊なもの」「ドキュメントがそろっていないもの」の順序で渡すべきである。
- プログラミングにおいては、大抵の場合「お手本的なタスク」を一回経験させるだけで、その後できることが格段に増える。「お手本的なタスク」は正しいメンタルモデルの作成を促し、理解やコミュニケーションの助けとなる。

5. 定常監視

目標、タスク、サポートの3つを十全に揃えることができたら、そのあとは定常監視のフェーズに移る。いわゆるヘルスチェックである。定期的にメンバーの状況を把握し、赤信号が光っていないかチェックする。

メンバーの状況を常に正しく認識できていることが、正しいマネジメントのための前提条件である。例えば、メンバーが難易度が高すぎるタスクにずっと詰まったまま、適切なサポートが与えられていないことに1週間気づかなければ、メンバーの1週間分の努力が虚空に消えていく。

根本的なことではあるが、困ったこと、将来的に問題になる可能性があることがあれば、できるだけ気軽に、かつ早めに声をあげるように伝える。遠慮しがちな相手に対しては、一回言うだけでは足りず、手を変え品を変え何度も何度も言っておくべきである。「15分詰まったら質問してね」というように具体的な数字を上げて指示したり、日報を毎日上げるように指示するのも良い。

この時、「状況把握」と「解決」は別物であるという認識をチーム内に行き渡らせることが重要である。ある問題が起きている時、その解決にリソースを投下するかどうかを意思決定するのはマネージャーの仕事である。インターン生などの経験の浅いメンバーに「これは解決すべき問題なのか」を判断させてはいけない。解決すべきかすべきでないか判断に迷っているうちに報告が遅れる or 報告してこなくなるからである。「対処が必要なのか必要じゃないのか判断する前に、まず上司に報告せよ」と伝える。

問題の見当たらない時も報告させ、状況確認を行わなければならない。 健康であっても毎年健康診断を受けるのと同じことである。

経験の浅いメンバーから相談が上がってこないからといって、問題が起きていないと考えるのは早計である。単に相談の仕方がわかっていないだけのこともしばしばあるからだ。筆者はよく「1.今日やったこと」「2.明日やる予定のこと」「3.困っていること・不安なこと・相談したいこと」という3項目を毎日報告させておいて、想定より進捗が悪ければ黄色信号だと捉え、ちょっと状況を聞いてみる、という方法を取っている。