システム開発組織における中間管理職の仕事と向き不向きを考える

morimorihogeです。首を寝違えて首が回らない。つらい。

アドベントカレンダーイベント実施中ということで、普段暖めていたけどなかなか踏ん切りが付かなかったネタを書こうと言うことで、今回は中間管理職の話になります。
中間管理職ってなんかめんどくさそうだけど、実際に何をやってるのか・どんな人が向いているのかよく分からないという人に読んでもらえれば幸いです。

※本記事の内容は弊社全体の合意事項ではなく、あくまで僕の経験を元にした考えです。弊社はチーム毎の意思決定の独立性がかなり高いため、他チームだと考えが違う所もあると思う点ご了承ください

対象組織について

設立17年ほどの独立系開発会社です。自社サービス事業、受託開発事業などがありますが、今回話す僕のチームの話は受託開発を主とするエンジニアチームの話です。
チームの人数規模は10名前後程度ですが、全員で1つのプロジェクトに取り組むというわけではなく、プロジェクトごとに何名かで構成されるプロジェクトチームを作ってそれぞれが対応するといった動きをしています。

僕の背景

システム開発会社でかれこれ15年以上くらい中間管理職をやっています。正直具体的にどのタイミングから明示的に中間管理職になったのかは覚えていませんが、会社が小さい時（10人以下）から開発のリードなどをしていたら、流れで管理職になっていたという感じが正しいかもしれません。

特に体系立った研修などで管理職の業務を学んだわけではありませんが、それなりに組織論的なビジネス書や他社の事例などは独学で学習し、取り入れられそうなものは取り入れてやってきました。
会社が小さい時から中規模（50人前後）の流れを見ていることもあり、それなりに様々な経験をしてきたのではないかと思います。

本記事ではそんな経験から感じる僕の持論を書いてみたいと思います。

中間管理職の仕事の分類

受託開発を行うシステム開発会社における中間管理職の仕事について、一言に中間管理職と言っても様々な役割を兼ねていることが多いと思います。
まずは中間管理職としてどのような仕事があるのか、ざっくりと分類してみましょう。

ピープルマネジメント

これはシステム開発会社といった業種に囚われない中間管理職の代表的な仕事です。部下の管理、育成、評価、人事異動、採用、退職など、部下に関すること全般を担当します。
組織の大きさによって中間管理職がどこまで自由度を持つかは様々かと思いますが、部下がいる以上は必ず関わる仕事です。

ピープルマネジメントの目的は、部下が仕事をスムーズに進められるようにサポートすることです。部下が仕事を進める上での障害を取り除いたり、部下が成長できるような環境を整えたりすることが求められます。
自分自身のアウトプットを最大化するのではなく、部下のアウトプットを最大化するためにあれこれするというのがポイントです。

例えば、僕が行っている具体的な業務としては以下のようなものがあります。

• 部下からの各種申請の承認（有給休暇や勤怠変更申請、備品・書籍購入・交通費等の申請）
• チーム内の情報共有の促進（チームMTGの開催・声かけといった仕組み作りを含む）
• 部下の育成・キャリア相談・待遇・条件交渉などの対応（夕会や1on1の実施などを通して）
• 年2回の評価面談の実施（給与評価決め、異動希望などのヒアリングなど）
• 自チームの採用活動（面接官としての参加、採用活動の企画・実施など）
• 部下のうち一部のシニアメンバをサブリーダーとして育成（リーダーとしての考え方やスキル向上を狙う）

また、部下に関する対応に付随して、会社側との調整も必要です。

• 部下からの社内制度上仕組みがない相談に対して、会社側と折り合いが付けられるかの調整（主に役員との相談）
• 部下の申請不備や問題が発生した際の会社側への報告・調整（勤怠が正しく付けられていない場合のお叱り対応など）
• 部下の評価結果に対する会社側へのフィードバック共有（自チーム評価内容が会社側の想定と大きくズレていないかなどの調整）
• 他チームとの間での人事異動の調整（他チームに人材を出す場合の調整や、他チームから人材を受け入れる場合の調整）
• 会社側の方針変更や連絡に伴う部下への説明・対応（会社側の方針変更に伴う部下への影響を説明し、部下の不安を取り除く）

色々書きましたが、部下が会社に対して大きな不満を持たないようにするために、部下と会社側の間に立って調整することが求められるという感じです。まさに中間管理職ですね。

テックリード（TL）的役割

エンジニア主体チームでありがちな、現場エンジニアがたたき上げで開発リーダーを経て中間管理職になった場合には、なし崩し的にテックリード（TL）的な役割も担うことが多いと思います。

いくつか本や事例を読んでいてもTLの役割は組織の定義によってもかなり幅が異なる印象ですが、一般的にはエンジニアリングの観点でチームをリードする役割で、開発責任者や開発リーダーといったポジションを担うような役割でしょう。
また、特定プロジェクトに限らず、チーム全体のエンジニアリングの品質向上や技術的な課題解決を行う役割もTL的な役割に含まれると思います。

TLの主な役割は以下の様なものが挙げられると思います。

• プロジェクトにおける技術的な課題解決の提案・実装
• チーム全体のエンジニアリングの品質向上の提案・実装
• チーム内のエンジニアのスキル向上の提案・実装
• チーム内のエンジニアのモチベーション向上の提案・実装

TLの特徴としては、良く一緒に話題に挙がるIC（Individual Contributor）とは違い、自分自身のアウトプットを最大化するのではなく、チーム全体のアウトプットを最大化するためにあれこれするというのがポイントです。
自分自身も高い技術力でチームを引っ張っていくことが求められますが、それ以上にチーム全体の技術力向上やモチベーション向上を考えるある種のリーダーシップが求められます。

僕のようなエンジニア出身の中間管理職の場合、元々少人数チームの開発リーダーとしてTL的な役割をしていたのが、人数が増えていくうちに中間管理職的業務が増えていった結果二足や三足のわらじを履くことになった、ということが多いのではないでしょうか。

プロジェクトマネジメントオフィス（PMO）的役割

僕のチームのような受託開発のチームでは、10名前後いるチーム全員が一つのプロジェクトに対して100%コミットしているということはありません。
常に複数のプロジェクトが走っており、チーム全員がそれぞれのプロジェクトに割り振られた割合で稼働しています。

プロジェクトごとに開発責任者やPMといった役割の人がいます（部下が担当することもあれば、顧客側が担当することもある）が、プロジェクトの状況は常に変わります。受託開発は究極的には人月商売なので、プロジェクトの状況に応じて部下の調整や場合によっては外注を含めた人員調整を行うことが求められます。
こうした複数プロジェクト間の人員調整を行う役割って何だろうな・・・と思うのですが、あえて言うならPMOが近いのかなと思っています。

• 参考: PMOとは？: 一般社団法人日本PMO協会｜NPMO

※僕自身、そこまできっちりプロジェクトマネジメントの体系的教育を受けているわけではないので、より適切な用語があれば教えていただけると幸いです

例えば、以下のような調整を行う役割があります。

• プロジェクトAが急に人手不足になった場合、プロジェクトBから人を借りる調整
• 新規プロジェクトの相談があった場合、チーム全体の稼働率を見ながら人員調整を行う
• 新規予定だったプロジェクトがキャンセルになった場合、他のプロジェクトに人を振り分ける調整
• こうした人員調整を他チームメンバーや協力会社を含めて調整する

ピープルマネジメントとは違い、こちらはプロジェクト主体の視点で人員調整を行うことが求められます。

PMOの役割は本来中間管理職とは別の立場であるべきかもしれませんが、受託開発のようなチームでは中間管理職がPMO的な役割を兼ねることが多いと思います。
ただ、ピープルマネジメントの視点とプロジェクトマネジメントの視点は相反することもあるので、この辺りのバランスを取る勘所は難しいところですね。

• プロジェクトAが人手不足になった場合、プロジェクトBから人を借りる調整を行う際に、プロジェクトBのPMが「うちのプロジェクトが遅れるからダメ」と言った場合、どうするか？
• αさんは特に落ち度無くプロジェクトを進めてくれているが、その他の要因でプロジェクトが遅れているので残業をお願いするか？はたまた協力会社を含めた他のメンバーに仕事を振り分けるか？

こうした調整を各プロジェクトのPMや社内・協力会社を通じて行うことが求められます。

その他の業務

上記の3つの役割以外にも、以下の様な業務が発生することがあります。

• 不慮のトラブルが発生した際の対応（プロジェクト稼働の穴埋めやお詫び入れなど）
• 会社の方針変更などに伴うチーム方針の変更対応・整合性取り
• その他特に担当されていない業務の引き受け（誰もやりたくない系作業や、ディレクションが必要だけど雑多な業務など）

ここまでのまとめ

ここまででざっくりと中間管理職の仕事をピープルマネジメント、TL的役割、PMO的役割の3つに分類してみました。
まとめてみると分かると思いますが、それぞれの役割は業務上の繋がりとしてはお互いに関連していますが、必要とされるスキルや視点は異なることが分かると思います。

中間管理職に向いている人について考える

中間管理職に向いている人とはどのような人なのでしょうか。以下に考えられる要素を挙げてみます。

部下個人の問題に対して親身になってくれる優しい人間性？

ピープルマネジメント的な役割を担う中間管理職には、部下の問題に対して親身になってくれる優しい人間性が求められるように思いますが、これは必須要件なのでしょうか？
確かに部下からしてみれば優しい上司の方が相談しやすくて良いと感じるかもしれませんが、あまり親身になりすぎるタイプの人は難しいかもしれません。端的に言うと会社と部下の板挟みになって病む可能性が高そうです。

そもそも中間管理職も会社に雇われているわけですから、一方的に部下の味方というわけではありません。会社の利益や出力を最大化するという目的がある以上、会社の利益と部下の利益が相反する場合、一般的には会社側の立場に立たなければならないことが多いでしょう。
そんなとき、部下個人の問題に対して親身になりすぎる性格だと自分の考える正解とは違う方向の判断を自ら下すことが難しくなるかもしれません。つらい。

また、部下の相談の中には会社と調整してどうにもならないような人生相談も含まれてくることがありますが、こうした相談に対して「上長としての対応」と「個人としての対応」を分けて考えられる、ある種のドライさが必要に感じます。
中間管理職は会社の業務・裁量範囲に関することであれば相談に乗ることができますが、部下の人生の責任を取ることはできないというある意味当たり前のことを頭に入れておくと良さそうです。

様々な事情を持つ部下の相談を受ける立場ですが、あくまで中間管理職という役割の業務を遂行するのが役割と考え、自分の責任範囲を超えた相談には自分以外の専門家に相談を勧めるなど、適切な対応を心がけることが求められると思います。

一方で、部下の立場にいる人向けの話も書いておくと、上司に個人的な問題を相談することが意味がないかというとそうでもありません。上司の方が会社の中で使える裁量や制度・その他過去の前例などについても詳しいため、あなたが部下のポジションだと思いつかない解決策を提示してくれる可能性もあります。
もちろん解決しないこともありますが、実は相談してたら過去に同じような問題を抱えた部下がいて、その時の解決策を教えてくれることもあるかもしれませんので、腹を割って話せると感じる上司がいる場合は相談してみるのも一つの手かもしれません。

結論としては、きちんと話を聞いてくれる懐の深さは必要だが、必要以上に親身になる必要は（中間管理職の業務としては）ないと思います。
もちろん部下も人間ですのであまりに機械的に対応するのも問題ですが、あくまで仕事上の関係だという線引きも重要ということで。

開発者として周りから尊敬される技術力？

TL的な役割を持つ中間管理職には開発者として周りから尊敬される技術力が求められると思いますが、これは必須要件なのでしょうか？

中間管理職ポジションになると、自分自身がアウトプットを出すことよりも部下のアウトプットを引き出すことが求められるようになりますので、自分の技術力をアウトプットする機会は減ると思います。
そのため、もしピープルマネジメントを含めたマネージャー職を目指すのであれば全ての技術領域でチームトップクラスの技術力を持っている必要はないと思います。仮に持っていたとしても業務でアウトプットできる時間的余裕がないです。人の1日は24時間しかないので。

ただ、エンジニアとしての経験やこれまでの学習の蓄積から成るある種の技術に対する勘のようなものは持っておく必要があるでしょう。
なぜなら、中間管理職は部下の評価も行うため、部下の技術力を評価するためには自分自身がその技術力を理解している必要があるからです。
とはいえ、現代のシステム開発では各技術ごとの専門性が高まってしまい、一人で全ての分野の技術力を評価するのは困難です。そのため、サブリーダーや他チームを含めた社内の詳しい人とも連携した上で、できる限り部下の技術力を正しく評価する努力をするのが現実的かなと思います。

僕自身しばらく直接実装する立場からは離れていることが多いですが、一部プロジェクトの手が足りない部分のフォローなどを通じて自分のスキルを維持しようとしている所です。

というわけで、あらゆる領域で高い技術力は不要だが、部下の評価やプロジェクトのフォローアップができる程度の技術力は必要くらいでしょうか。
なお、エンジニア上がりではない専門の中間管理職としてのポジションで入るのであれば、技術力よりもマネジメントスキルやビジネススキルがより重要になるので、そちらで尊敬してもらえるレベルの実力を持っていれば、技術面の評価については他の社内エンジニアとの連携でカバーできると思います。

沢山のプロジェクトを並行して進行できるプロジェクトマネジメント力？

PMO的な役割を担う中間管理職には、沢山のプロジェクトを並行して進行できるプロジェクトマネジメント力が求められるのでしょうか？

これは中間管理職に限らず、プロジェクトマネジメントのスキルはある程度持っていた方が良いと思います。自分が直接舵取りしないプロジェクトについても、順調に進行しているかの状況把握だけはきちんと行っておくことで、トラブルを予見しやすくなります。
システム開発業界あるあるな問題として「プロジェクト炎上からのチーム崩壊 -> 力尽きたメンバーが退職してガタガタになる」といったものが挙げられますが、こうした事態を防ぐためにもプロジェクトの健康管理スキルが必要になります。

ただし、中間管理職が直接特定プロジェクトのマネジメントを行うことはなるべくしない方が良いです。なぜなら、中間管理職は他で挙げたようなその他の業務も多く、どうしても特定のプロジェクトに専念しようとすると他の業務がおろそかになりがちだからです。
中間管理職として必要なのは部下が関わっているプロジェクトが順調に進行しているかどうかを偵察しておくことです。そのため、各プロジェクトのPMや開発責任者とのコミュニケーションを密に取ることが求められます。

このあたりはPMOが独立しているような組織であればPMOが担当するべき業務なので中間管理職に必須とは言えませんが、少なくともPMOを担う人がいない組織では中間管理職がこうしたスキルを持っていると良いでしょう。

部下の意見をよく聞いて民主主義的なチーム運営ができる人？

これまでチームや事業などを運営してきた経験がなく中間管理職を任されることになったという人もいるかもしれません。中間管理職は部下の意見をよく聞いて民主主義的なチーム運営ができる人が求められるのでしょうか？
これは既にある程度チームリーダーを経験してきた人であれば分かると思いますが、民主主義的なチーム運営はチームの規模や事業の性質によっては適さない場合もあります。

我々日本人はなんとなく民主主義が常に良い物と考えがちで、少数意見を尊重することが大事だと思いがちですが、実際のチーム運営においてはリーダーシップを持って方向性を示すことも重要です。
現代のシステム開発では時間は有限かつ貴重な資産ですし、そもそもシステム開発プロジェクトは先を完全に予測できない状態で走るアジャイル開発が主流となっています。
そんな中でチーム全体で同じ結論が出るまで議論していては、プロジェクトの進行が遅れてしまいます。

チーム運営方針であればピープルマネジメント的役割、技術的方針であればTL的役割、プロジェクト全体の方針であればPMO的役割が求められると思いますが、どのケースであってもリーダーシップを持って方向性を示すことができる人が中間管理職に向いています。
そもそも中間管理職は最終的に責任を取るのが仕事でもあり、部下の意見を聞いて責任を分散させるということはできませんので、その時その時で明確な意思決定を行うことが求められます。
なおここで言う「明確な意思決定」は「現時点では保留としておく」ということも含まれます。あくまで「保留」という意思決定を行ったというのが大事です。

部下から上長のポジションになって一番大きく変わるのはこのあたりかもしれません。部下の立場だったときは「上司に決めてもらえると楽だよな」と思ってたことがそのまま自分に降りかかってくるので、この辺りのチーム運営をどうやっていくのかについてはしっかり考えておく必要があります。

自分の作りたい・なりたいチームのイメージがある人？

中間管理職は自分の権限の中で意思決定を行っていく必要があるわけですが、その際に自分の作りたい・なりたいチームの具体的なイメージを持つ必要があるのでしょうか？

これについては何かしらこだわりなり目指すイメージを持っていた方が良いと思います。ピープルマネジメントにおいてもTL的な役割をするにしても、中間管理職は意思決定を迫られることが多い立場です。意思決定の際に自分の持っているイメージを元にすることで、チームの作りたい方向性と整合性を持つことができます。

こうしたチーム方針的なものはなんとなく気恥ずかしかったり、きちんとした言葉に整理するのが難しいかも知れませんが、そんなこと言ってないでやりましょう。
一発でしっくりくるものができないのは当たり前ですが、それでも何らかのイメージを部下と共有しておくことで、チーム全体の方向性を明確にすることができます。

参考までに、現在の僕のチームのチーム方針を貼っておきます。

ピープルマネジメントに関連してきますが、部下がある程度自由を持って仕事を進めるためにはチーム全体であるべき方向性・価値観が示されていることが重要です。
こうした大きな方向性が示されていないと、自分勝手に判断して大幅なやり直し・手戻りに繋がってしまったり、逆に部下が自分の裁量を持てずなんでも上司に確認するようになってしまいます。
評価を付ける時にもこのチーム方針を元に評価を行うことで、部下に対して（少なくともチーム方針に沿っているかという意味で）公平な評価を行うことができます。

部下から中間管理職になって初めて権限を持てるのがこのチームの方向性決めだと思いますので、中間管理職になることをぼんやりとでも考えているのであれば、自分の作りたい・なりたいチームのイメージを持っておくことをお勧めします。
逆に、自分の作りたい・なりたいチームのイメージが持てないのであれば、中間管理職になることはあまりお勧めできません。あなたのためでもありますが、部下が辛い思いをしてしまうので二重に不幸になってしまいます。

誰よりも死ぬ気で働ける人？

ここまで書いたように中間管理職はかなり多くの仕事がありそうに見えますが、これらをこなすためには誰よりも死ぬ気で働ける人（＝ハードワーカー）が向いているのでしょうか？

これについては僕としては作りたいチームのイメージに寄るかなあ、と思います。ベンチャーやスタートアップなどで超高いモチベーションと勢いでチームを引っ張っていくのであれば、部下に背中を見せるという意味でハードワーカーであることは重要かもしれません。業務時間外でも一緒に旅行したりハッカソンを企画したりして、密なコミュニケーションを取るなどもあるかもしれませんね。

一方で、僕のチームの様にそれぞれがプロフェッショナルとして高いアウトプットを出して行こうという感じの価値観だと、業務上のアウトプットが最大化されるように働けていれば必ずしもハードワーカーである必要はないかなとも思います。プライベートを大事にしたい人も尊重するよ、といった価値観のチームの場合、上司がハードワーカー過ぎると気を遣ってしまう部下もいるかもしれませんし。

そもそも、中間管理職はチーム内で発生する突然のトラブルに対応できることが求められるため、常時ハードワークしているような状態は不安定で危ない気はします。やれて数ヶ月～1年くらいでしょうか。
どちらかというと中間管理職は自分自身が死ぬ気でがんばり続けるよりは、自分自身の権限を適切に部下にも分散していくことでチーム全体の安定性を高める方が重要だと思います。

中間管理職適任者なんておらんやろ問題をどうするか？

中間管理職に向いている要素を考えてきましたが、そもそもこんな人材なかなか見つからないよなあ、と感じます。

• 自分以外の部下のピープルマネジメントというエンジニア -> マネージャーへのキャリアシフトを考えていて
• エンジニア出身でTLできるくらいの開発リーダーができる技術力・リーダーシップがあって
• 複数のプロジェクトを同時並行で確認しつつ、状況に応じて人員調整の交渉・フォローアップができる

無理ゲーですね。ここまでやれる人は優秀なフリーランスとかになった方が稼げそうな気もします。
特に、エンジニア -> マネージャーへのキャリアシフトはエンジニアにとってはかなり大きなキャリア選択となってしまうため、自分にマネージャー適性があるかどうかも分からないのに飛び込むのは厳しいのではないでしょうか。

というわけで、これらの職能を分解した形での構成を考えてみたいと思います。

PMO業務の分離

中間管理職の業務のうち、PMOの役割は比較的分離可能に見えます。そもそもPMO的アプローチは現場の開発エンジニアとはかなり違うより上流の管理的な視野が必要になり、各所との高い調整能力が問われます。TLをやっていた人も1プロジェクトは見られても、複数プロジェクトが絡んでくると脳のコンテキストスイッチが必要になり、ちょくちょく思考に割り込みが入るため向き不向きが分かれそうな業務です。

そこで、PMO的業務については別途PMOチームを用意してはどうか、という話が出てきます。
中間管理職はあくまで自分の部下の状況だけ把握しておけばよく、プロジェクト自体の状況についてはPMOチームが監視して、問題があれば適宜エスカレーションしてもらうような体制は構築できるかもしれません。

一方で、PMOチームは各チームのメンバーそれぞれまで深く知ることはありませんので、メンバーの再アサインまでPMOチームに任せてしまっていては、中間管理職が部下と調整していたキャリア設計と齟齬が発生したりするリスクがありそうです。
また、PMOチームは各プロジェクトのPMとはやり取りしていますが、それぞれの開発メンバーの状況を常に把握しているわけではないため、プロジェクトの進捗に一見問題は無くても実は内情は結構無理していた、という現場の頑張りでぎりぎりがんばってる様なプロジェクトを見落としてしまうかも知れません。難しい。

TL業務の分離

仕事の分類で挙げた中でTLはエンジニアリングスキルを要求する業務のため、この部分を中間管理職の必須スキルとしてしまうと様々な問題が発生します。

• TL経験者を中間管理職の前提条件とした場合、対象者が必ずしもピープルマネジメントやPMOに向いているとは限らないため、向いていない中間管理職に抜擢することで組織全体の不利益に繋がる可能性がある
  • 参考：ピーターの法則
• そもそもピープルマネジメントやPMOができる人材は貴重であり、パイが少ない

というわけで、ピープルマネジメントやPMOに長けた人をエンジニアに拘わらず呼んできて中間管理職になってもらい、TLは中間管理職とは別のメンバーに担当してもらう、というやり方が考えられます。

このやり方は組織の文化にも寄りますが、よっぽどエッジの効いた癖のあるエンジニア組織などで無ければうまくいきやすい様に感じます。
なぜなら、ピープルマネジメントやPMOに長けた専業中間管理職な人というのは、ある程度大きな組織だったり色々と癖のある部下や特殊な事例を経験していることが多く、人格的にもタフだったりすることが多いからです。
TL上がりの中間管理職のそれなりの割合が人間関係的な部分だったり、部下との付き合い方で精神的に悩むことが多いことを考えると、こういった「中間管理職技能の専門職」を雇うというのは合理的だと思います。

欠点としては、こういった中間管理職に長けた人というのはそれなりに高給でないと来てくれないため、ある程度組織の規模が大きくないとコスト負担が大きいというところでしょうか。
また、この中間管理職として呼んでくる人に多くの部下を割り当てるということは、その人がうまく自分の組織となじまなかった場合に大量の離職者を発生させてしまうリスクも孕むという意味で、なかなか思い切るのが難しい選択ではあります。

しかし、知り合いのツテなどで良い人が見つかるのであれば良い選択の一つだと思います。

ピープルマネジメント業務の分離

残念ながら、ピープルマネジメント業務は中間管理職と分離するのは難しいです。なぜなら、ピープルマネジメントこそが組織における中間管理職の本質であるため、ここを外に出すともう部下を管理する中間管理職では無くなってしまうからです。

ただ、ピープルマネジメント業務自体はある程度組織が安定してくると定常業務が多くなることと、特にエンジニア組織に限った業務内容ではないため、誰も率先してやりたがらないならそのうちAI中間管理職というのは冗談抜きで導入されていく可能性があるのかも知れません。

で、どうしよう？

理想としては、先に挙げた3種の対応ができるエンジニア出身者（望むらくは社内で数年在籍していて価値観・文化マッチングが済んでいる）が中間管理職に育つのがベストですが、会社組織というのは株主や市場等の都合によりどうしても今すぐ無理にでも拡張しないといけない時があります。

そういったときには本節に挙げたような役割分担を考えてみても良いのではないかと思います。特に、エンジニアの多い組織ではTLを突然外から招致すると、馬が合わない長年在籍してくれていた功労者が一斉退職したりする事例が稀に良くあるという話を聞きますので、TL役はできれば社内から出せるとリスクが低いと思います。

まとめ

そんなわけで、独断と偏見で中間管理職という仕事について考えてみました。
色々と書いてみましたが、中間管理職の向き・不向きは以下のような感じでしょうか。

• 自分ではなく部下を含めたチームのアウトプットの最大化が仕事
  • 自分の仕事のことだけ考えていたい、という人は不向き
  • 業務において部下のサポートをする必要はあるが、プライベートで仲良くなる必要は必ずしもない
  • ある程度ドライさを持って人と関われる人は向いているかも
• 部下だったころは使えなかった権限と責任が得られることで、自由度がUP
  • 自分で意思決定せず、誰かに決めてもらいたいという人は不向き
  • 誰かに相談できないわけではないので、人の意見を聞いたり相談しても良い
  • 最後の意思決定はエイヤと決める必要があるので、決断力は必要
• 意思決定に部下が付いてきてくるような何らかの要素が必要
  • 共感を得る、スキル的に尊敬される、人間的に好かれる、命令権を行使する、なんでも良いがチームが力を発揮できる必要がある
  • チーム方針の共有などを通じて価値観をすり合わせるなど

僕が中間管理職として一貫して目指しているのは「この上司の下だったら働いてやってもいいな」と自分自身が思えるラインなので、エンジニア上がりの人間がエンジニアチームを率いるという点では考えやすかったのかもしれません。

そんなわけで思いつくがままに書いてみましたが、振り返ってみるとまだ書き足りないことがあるなあという気持ちもあるので、またこの手のネタで書くかも知れません。
昨今は中間管理職はやりたい人が少なくて困っていると言われますが、中間管理職になることを考えている人がいるのであれば、この記事が少しでも参考になれば幸いです。ではでは