前回の記事
連載の構成
- この記事は、マネジメントについて一人で考える Advent Calendar 2022の連載記事です
- 1記事目から読んでいただいても良いですし、気になる記事から読んでいただいても問題ありません
- 全25回分の構成は、次の通りです
- 第1〜6回：ドラッカーの『マネジメント』を中心に解説します
- 第7〜13回：『図解人材マネジメント入門』を中心に解説します
- 第14〜22回：『エンジニアのためのマネジメントキャリアパス』を中心に解説します
- 第23〜25回：私の経験談を中心に、まとめに入ります
マネージャーの技術力
- 連載第10回で似たテーマを取り扱いましたが、今回はそれをさらに深堀りします
- マネージャーに技術力は必要か？です
マネージャーの悩み
- エンジニアリングマネージャー(以下EM)として働いていると、こんな悩みを持ちがちです
- マネージャーとしての知識やスキルが足りない
- マネジメントについて学ばないと、という焦燥感
- でもマネジメントばかり学んでいると、今度は技術に置いていかれる感覚
- 業務上コードを書く時間が減り、技術力の停滞やトレンドに置いていかれる感覚に陥る
- マネージャーとしての知識やスキルが足りない
カッツ・モデルで考える
- そこで、まずはカッツ・モデルを再度引用します
- 連載第10回でも紹介しましたが、（EMに限らない）マネジメントレイヤーによって必要になるスキルを示したものです
- 見てお分かりの通り、一般的にはレイヤーが上がるにつれて、テクニカルスキルの割合が減り、コンセプチュアルスキルの割合が増えます
- これは組織図を例に考えると分かりやすいでしょう
- ロワーマネジメント（チームリーダー）
- 例）4人所属する1つのチームを管轄する
- マネジメント人数は4名
- 例）4人所属する1つのチームを管轄する
- ミドルマネジメント（EM）
- 例）そのチームを3つ合わせたグループを管轄する
- マネジメント人数は4名*3=12名
- 例）そのチームを3つ合わせたグループを管轄する
- トップマネジメント（本部長）
- 例）そのグループを3つ合わせた事業本部を管轄する
- マネジメント人数は4名33=36名
- 例）そのグループを3つ合わせた事業本部を管轄する
- ロワーマネジメント（チームリーダー）
- この例でも分かる通り、レイヤーが上がると、マネジメント人数と組織数が増えます
- その中で、業務内容をテクニカルスキルに振っている時間は無くなっていくでしょう
- そして直接マネジメントするロワーマネジメントとは異なり、ミドルやトップマネジメントは、間接的にヒト・モノ・カネ・情報をマネジメントしていくスキルが必要です
- その分テクニカルスキルより、ヒューマンスキルやコンセプチュアルスキルが必要になるわけです
EMは技術を学ばなくて良いのか
- では、EMはテクニカルスキルを疎かにして良いのでしょうか？
- 結論、ITエンジニアという職種においては否、と考えています
- 仮にEMになって5年、全く技術のキャッチアップをしなかったとします
- その際、
- 採用面接で、候補者のスキルレベルを正しく評価できますか？
- 日々のマネジメントで、メンバーのスキルレベルを正しく評価できますか？
- スペシャリストやメンバーの技術の提案を、周囲に翻訳できますか？
- 正直、かなり難しくなるでしょう
- その際、
- 前述の通り評価の面はもちろんですが、最後に挙げた『翻訳』は重要です
専門家は専門用語を使いがちである。専門用語なしでは話せない。ところが、彼らは理解してもらってこそ初めて有効な存在となる。彼らは自らの顧客たる組織内の同僚が必要とするものを供給しなければならない。
このことを専門家に認識させることがマネジャーの仕事である。組織の目標を専門家の用語に翻訳してやり、逆に専門家のアウトプットをその顧客の言葉に翻訳してやることもマネジャーの仕事である。
引用：マネジメント[エッセンシャル版] - 基本と原則
- 重要なのは、翻訳ができるレベルを目指すということです
- スポーツで言うところのコーチや監督であるEMが、現役バリバリのスター選手であるスペシャリスト並みに"実務で使える"必要はありません
- 現実問題、担っている責務と割く時間が段違いなので、それは難しいでしょう
技術トレンドに取り残されないために
- エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイドでは、具体的な対策が書かれています
- コードを読む
- 自分が疎い領域を選び、その領域に詳しいエンジニアに解説を仰ぐ
- ポストモーテムに同席する
- ソフトウェア開発のプロセスに関する業界のトレンドを常に把握する
- 社外でも技術系の人脈作りを
- 「学び」は決してやめてはならない
- いくつかピックアップして解説します
- コードを読む
- これは比較的やりやすいです
- 全てではなくて良いので、プルリクエストのレビューを見たり、たまにコードレビューに入ってみると良いです
- 自分が疎い領域を選び、その領域に詳しいエンジニアに解説を仰ぐ
- これもすごく重要です
- インターネットや本の情報は、読者の知識レベルに合わせて柔軟に変化しません
- 身近なエンジニアに聞くことで、分からない部分を重点的に聞くこともできるでしょう
- そして重要なのは、それが気軽に聞ける関係性を作っておくということです
- レイヤーの上下や年齢・エンジニア歴の上下＝偉いという思いが強いと、若手から謙虚に学ぶ姿勢になりづらいです
- ポストモーテムに同席する
- ポストモーテムとは何かざっくり解説すると、
- 日本語訳すると検死
- インシデントが起きた後、原因や対応手順、影響を調べる会議や文章
- 犯人探しが目的ではなく、検死の名の通り、チームメンバーで分析し、学びに続けるのが主目的
- ここに同席することによって、インシデントの概要が分かることももちろんですが、EM自身の技術力向上にも繋がるでしょう
- ポストモーテムとは何かざっくり解説すると、
EMとスペシャリストを数年ごとに行き来する
- 今まではEMを続けながら技術力を上げる方法を紹介してきました
- 別の方法を上げるとするなら、シンプルにEMを離れるという選択肢です
- 私自身2年ほどEMを離れてスペシャリストを任されていた時期がありました
- EMを続けていれば得られなかった経験を得ることができました
- また、EMとしていかに視野が狭まっていたかを痛感しました
- 自チーム以外、組織全体や会社全体での課題に気付き、動かせるようになりました
- その分後継者が必要になりますが、3年5年と後継者が作れず属人化する組織も問題があるのではないでしょうか
- 入れ替わることで新たな風ももたらされますし、オススメです
終わりに
- 今回はエンジニアリングマネージャーの技術戦略について解説しました
- 次回はまたテーマが大きく変わり、エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイドで紹介されている"有害な社員"について解説します
次の記事