🤗

エンジニア組織でありがちなリーダー・マネージャー問題と、フレキシブルで可逆なキャリア開発のアプローチ|Offers Tech Blog

2022/04/15に公開

プロダクト開発人材の副業転職プラットフォーム Offers を運営する株式会社 overflow VPoE の あほむ でございます。

今回は Offers エンジニアリングチーム[1]においてリーダーやマネージャーといった職務をどのように捉えているかについて紹介させてください。なにかのご縁があって弊社にご興味をもってくださった方のご参考になれば幸いです!

エンジニアリング組織のリーダー、マネージャーの扱い

所属する組織の中で「リーダーシップを発揮してほしい」とか「リーダー経験がないとこれ以上評価できない」とかのコミュニケーションをとった/とられたことがある方も少なくないのではないでしょうか。

こういったコミュニケーションの背景には 「組織としてリーダーシップを発揮できる人材を欲している」 という意図や 「評価上の分かりやすい材料を欲している」 などの事情があると考えられます。

そんなことを考えていたころの過去の自分のツイートをご紹介。

問題① リーダーにならないと評価されない問題[2]

https://twitter.com/ahomu/status/1488369000933650432

一般に減給や降格が難しい本邦において職位(いわゆる社内等級、グレード)として扱うことは当事者にとっても極めてキャリアの不可逆性が高いアプローチです。また新参者がそのポジションを得るためには前任者を押し出すか、組織拡大によってポジション自体が増えるのを待つしかありません。

よってリーダーやマネージャーという職務と責任は、不可逆で一本道な「職位」ではなく、人に対して付け替えてローテ可能な「役割」として扱うがよかろうという見解を暗に述べているツイートでした。

問題② マネージャーがただの便利屋になる問題

https://twitter.com/ahomu/status/1493457938534469634

私を含めて一部の物好きが便利屋として振る舞ってしまっているからこそ、体系的な職務教育が醸成されないまま人手不足を嘆いているんでないかと思う次第ですがさておき。

組織においてリーダーシップを発揮できる人材の確保は重要な課題ですが、前述の物好きが苦しそうに(嬉しそうに)やっているだけではそれをやりたがる人もまた物好きに限られてしまいます。好き嫌いによらずお役目として、挑戦可能なキャリアとして、どんな職務と責任を負っているのか明確にすることが大事ではというお気持ちツイートでした。

総じて、役割として職務の明文化が必要

overflow では次のように役割を分割して職務を明文化しました。職務に関する説明はブログ向けに概要のみで簡略化しています。

役割 期待される職務
エンジニア すべてのエンジニア(リーダー、マネージャー含む)に期待されるエンジニアリングを通じて価値を創出する本命の職務です
チームリード 開発チーム運営でリーダーシップを発揮し、エンジニアリングにおけるチームとプロダクトの結びつきを最大化します
テックリード テクノロジー領域でリーダーシップを発揮し、エンジニアリングにおける技術力とプロダクトの結びつきを最大化します
エンジニアリングマネージャー キャリア育成や採用、組織開発においてリーダーシップを発揮し、エンジニアリングにおける組織と技術力の結びつきを最大化します

評価制度の一環としてリーダーやマネージャーといった用語が使われていることは珍しくありません[3]が、どこでリーダーシップを発揮してほしいのか、なにをマネージメントしてほしいのか等の解像度が足りていないと感じることがあったのでチーム、テクノロジー、ピープル(組織)の 3 つに分けて役割として詳細化しました。

いちエンジニアとして専門性やハンズオンの価値創出に拘り続けることはもちろん、リーダーシップの発揮領域を分割&限定しているので意欲のあるひとがチャレンジしやすくなるようにと意識しています。あと、ポジション分けたほうがなんだかんだ椅子取りゲーム対策にもなります。

リーダーシップは職位ではなく役割(ロール)として扱う

overflow のエンジニアリングにおいてチームリード、テックリード、エンジニアリングマネージャ(以下 EM)は職位ではなく職務と権限に名付けをした「役割(ロール)」 として扱うことで着脱しやすくしています。もちろん、相応の能力が求められるという面で社内の職位との相関はありえますが評価や待遇には直結しません。

フレキシブルなチャレンジ機会をつくる

各々のキャリアやライフステージにおいてフレキシブルなチャレンジを可能にしたいと考えています。
昨今エンジニアリングマネージャーを務めた方が IC (Individual Contributor) としてのポジションを獲得するような事例からも分かるとおりマネージャー適性を持つ人でさえ、リーダーシップを発揮する時期と技術力によって価値を創出する時期の揺り戻し、または回帰があります。

私個人の経験を踏まえても技術的な好奇心による欲求や、技術の上に成り立った職務を遂行するための技術アップデートの必要性などを感じることは多々ありますし、マネージャーからプレイヤーに戻ったこともあります。技術職であるからこそフレキシブルなキャリア設計とそれに応えられる組織の制度設計が必要だと考えています。

変化や不確実性への適応力を高める

我々がスタートアップであること、VUCA と呼ばれる時代であること、その中で組織が変化や不確実性への適応力を身に付けることは重要です。職務や権限を人ではなく役割につける前提は個々人のキャリア開発だけでなく柔軟な組織編成にも役立ちます。
誰もがその時々の必要性に応じてリーダーシップをとったりオーナーシップを発揮したりできる組織は、変化や不確実性への高い適応力を持っていると言えるでしょう。

エンジニアの多様なキャリア開発に注力したい

以上、リーダーやらマネージャーやらに対する弊社エンジニアリングチームの考え方でございました。いうほどリーダー、マネージャーを本当に心の底から毛嫌いしてる人ってあんまりいなくて、面白くなかったときに降りられなさそうだったり、年次でリニアにいつか辿り着いてしまう終着駅の扱いだったりが問題なんでは思っているので、みなさんにふるってチャレンジしていただきたい所存です。

今後はデザイナーや PjM/PdM のような開発チーム内における専門軸が異なった隣接領域とのまたがりをどのようにするかも体系的な評価制度と合わせて考えていくので、今の環境で実現できないキャリアイメージがある方もお気軽にご相談ください!

脚注
  1. 今のところ Offers 以外にエンジニアリングチームはないので、実質的に全社エンジニアリングチームです。 ↩︎

  2. リーダーとしての実績以外で評価されるキャリアパスやミッションを提示できない制度設計か上長の指導力にも問題はありそうですが、そのあたり深掘りすると本題に辿り着けないので今回は割愛します。 ↩︎

  3. 評価とかリーダーとかマネージャーなどの諸問題をエッジの効いた組織運営ルールでカバーする事例もありますが、現状は各種のモダンな組織論のエッセンスを取り入れつつ組織上のまとめ役を明示的に必要とするハイブリッド型で設計しています。 ↩︎

GitHubで編集を提案
Offers Tech Blog

Discussion