STEAM PLACE

エンジニアリングとマネジメント

トップ > 書籍 > マネジメントに興味がなくても騙されたと思って『エンジニアのためのマネジメントキャリアパス』を読んでくれ

マネジメントに興味がなくても騙されたと思って『エンジニアのためのマネジメントキャリアパス』を読んでくれ

書籍 マネジメント

エンジニアのためのマネジメントキャリアパスという書籍が出版されました。 
タイトルに書いたとおり、マネジメントに興味がなくても、読むこと大きな学びをもらえる本です。

及川さんが前書きを書いており

本書を読み終わった後、私はひどく落ち込んでいる自分に気づきました。
~中略~
内容が素晴らしい故に、いかに自分が未熟であったかを思い知らされた

と、記載があって衝撃を受けました。
及川さんが落ち込んだら、私なんて精神崩壊してしまうのではないか…！？

本書を読んで、精神崩壊こそしなかったですが、ひどく落ち込みました。自分のレベルの低さを痛感します。

本記事では本書の知識定着のためのアウトプットと、所感をまとめています。各章毎にピックアップして記載します。

書籍の内容

  • 1章 マネジメントの基本
  • 2章 メンタリング
  • 3章 テックリード
  • 4章 人の管理
  • 5章 チームの管理
  • 6章 複数チームの管理
  • 7章 複数の管理者の管理
  • 8章 経営幹部
  • 9章 文化の構築
  • 10章 まとめ

章立てを見てわかる通り、各キャリアのステップを辿るように構成されています。   メンバーから、マネージャー、CTOまで。  

自分のキャリアのふりかえりと、今の自分、そしてこれからの自分を具体的にイメージができます。

目次を見るだけでワクワクしてきませんか？

なぜマネジメントに興味なくても読んだ方がいいのか

あなたの上司は何をしていますか？

あなたの上司がしていることは、あなたからは見えずらいものがあるかも知れません。

この本からは上司がやるべき事が学べます。自分が上司になったらやるべきことが学べます。上司ができる上司なのかがわかるようになります。

本当にできない上司の元にいるなら、上司にこの本をプレゼントしましょう。または、上司を超える上司にあなたがなる時かも知れません。

読書をふりかえる

3行でまとめると

  • マネージャーのやること、必要なこと、どうすればなれるのかが理解できる
  • マネージャーのキャリアパスが、どうなっていくのかがイメージできる
  • マネジメントを目指していなくても、読むことでエンジニアリングマネージャーのことが理解できる

1章 マネジメントの基本

できる上司はどんな上司なのか、上司には下記2つを求めましょう。

  • 1on1ミーティング
  • フィードバックの提供

1on1でつながりと要検討事項を1対1で話し合い、フィードバックをもらえるようにします。そして、トレーニングとキャリアアップをしていきます。

しかし、上司にはできないことがあります。 「何があなたを幸せにするのか」は上司は教えることはできません。

自分自身が何を望んでいるのか、何を学びたいのか、何が自分を幸せにするのかを考え抜いて明らかにする責任はひとえにあなた自身が負っているのです。

己を知り、望みを叶えるための努力をしていく必要があります。
その望みを上司と共有することで、できる上司は必ずサポートをしてくれます。

2章 メンタリング

メンターになることは実はマネジメントの一歩目。
このブログを読んでいる人は、一度はメンターをやったことがあるかも知れません。そう、あなたはもう Hello Management ということですね。

さて、ではメンターとは何をやっていくべきなのか？
傾聴などのスキルから、具体的な事例まで取り上げられています。

メンターの重要な心得
  • 常に好奇心を絶やさずオープンな心で
    メンティーを通してあなた自身も気付かされることがたくさんあります。好奇心を全開にしてメンタリングの一つ一つに対して向き合っていきましょう。
  • 相手の言葉をよく聞き、相手の言葉で話す
    メンタリングは否応なくコミュニケーションスキルが磨かれます。特に傾聴のスキルは訓練がものを言います。
  • 人脈作り
    キャリアは長く、テクノロジーの世界は狭い。どんな相手にも丁寧に接しましょう。

3章 テックリード

テックリードとは？についてこう記載されています。

開発チームに対する責任を担い、最低でも自身の職務時間の3割はチームと共にコードを書く作業に充てているリーダーのこと

企業によって定義は様々ですが、確実に出てくるのが ”チーム” というワードだと思います。 本書でもテックリードのコツが紹介されていますが、フォーカスはチームになっています。

実際のプログラミングの作業からあっさり一歩引き、『技術面での貢献』と『チーム全体のニーズへの対応』のバランスを取る努力を惜しまない

テックリードになるとこれまで拠り所にしていたプログラミングというスキルの他に、マネジメントスキルという新しいスキルが必要になります。
その両者の「バランスの取り方」に習熟していく必要があるのです。

私自身もマネージャーとして従事した時に、エンジニアよりも忙しくなったというより、時間配分が変わったと感じました。

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

印象的ですね。優秀なテックリードの条件のうち、半分は人間にフォーカスしたことが含まれています。

スポンサーリンク

4章 人の管理

人の管理で求められる主な仕事を次の4点に絞って考えています。

  • 直属の部下との関係の構築
  • 定期的な1on1ミーティング
  • キャリアアップや作業の進捗状況、改善領域、功績の報奨などに関するフィードバック
  • 各メンバーの研鑽をようする領域の見極めと、その領域の能力の強化

部下と良好な関係を築くためには、相手を理解するための質問をして、信頼感と親近感を構築する必要があります。

ここでも定期的な1on1は ”必要” と言われており、「車のエンジンオイルなようなもの」という表現がわかりやすいですね。
そして、1on1の進め方、フィードバックの文化、評価の方法までの話が展開されていきます。

5章 チームの管理

さて、今度は人からチームの管理になります。

ここから上はランクが上がるたびに「これまでとはまるで違う任務と課題を担う経験」を繰り返していきます。

自分自身、リーダー、マネージャー、部長などやってきましたが、確かに全く違う任務と課題、そして全く違うスキルが求められていることを感じました。（そもそも職位毎のジョブディスクリプションも企業毎に違いますが。）

チームの管理者として人的管理以外に焦点を当てるべき側面は何か

これ、大事ですね。特に技術のスキルはずっと必要です。

技術面の意思決定を主導する責任を負っているのです。この先、経営陣になろうが、技術の面での責任はずっと負っているのです。
自分の技術を維持する方法を考え、学習を続ける必要があります。

チームの状況が悪くなった時。
そんな時は思い出してください。プロダクトでバグが発生したらどうしていますか？
事実を洗い、仮設を立て、検証し、原因を特定し、課題を解消していると思います。
チームも組織も同様です。バグが発生したら、デバッグをしましょう。

チームの意思決定は誰がやるのか？

管理者に与えられているのは自ら決定を下す権限ではなく、チームによる意思決定を主導する権限にすぎない。それでいて、そうした意思決定の結果の善し悪しが管理者の能力の判断材料にされてしまう

そんな意思決定を主導するコツが書かれています。

  • 「データ重視」の文化を根付かせる
  • 顧客に対する共感を深める
  • 将来を見据える
  • チームの意思決定やプロジェクトの結果を振り返る
  • プロセスと日程を振り返る

6章 複数チームの管理

「あなたはもうコードをあまり（あるいはまったく）書いていない」という状況です
~中略~
「人を管理する道へ舵を切る前に、まずは十分時間をかけてプログラミングを完全にマスターしましょう」

いきなりインパクトのあるワードが書かれています。
日々スケジュールに追われる中で、OSS活動や講演活動など創造的な活動しないといけません。学びは続けなければいけません。

時間を管理して「重要な仕事」にフォーカスしましょう。 時間管理のマトリクスにあるとおり、重要なものを最優先するようにします。緊急に惑わされない、緊急に逃げない。

緊急ではない 緊急
重要 必須。時間を作る 明らかにやるべき事
重要ではない 明らかに回避するべき事 ついつい注目しがちな「気の散る要因」

そんな時間のない管理者は仕事を委任をしていく必要があります。

頻繁 頻繁でない
単純 委任 自分でやる
複雑 （慎重に）委任 訓練目的で委任

そして、意思決定。

スポンサーリンク

7章 複数の管理者の管理

職務内容は複数チームを管理する管理者と同じになってきます。
が、かかりっきりになるということです。

さて、そんな複数の管理者の管理のコツです。

  • 2ランク以上離れた部下から情報を得る
  • 直属の管理者達に責任を課する
  • 新任の管理者、ベテランの管理者を管理する
  • 管理者を新たに雇い入れる
  • 組織の「機能不全状態」の根を突き止める
  • チームの技術戦略を調整する

特に機能不全状態の根を突き止めるは、前述のデバッグのところでも書きましたが、組織とプログラミングは似ていますね。

仮設を立てる、データをチェックする、チームを観察する、質問をする、チームの人間関係をチェックする、支援に乗り出す

この辺りから戦略がとても重要になります。組織としての戦略です。

8章 経営幹部

CTO、 VPoE などの技術系幹部のことを指します。
経営幹部の職務とは次の4つのカテゴリーに大別できるようです。

  • 情報の収集・共有
  • 注意喚起
  • 意思決定
  • ロールモデル

この4種類の職務を果たすのが、技術部門の頂点に立っている人なのです。

では、役割はどの様になるのでしょうか。

  • 研究開発
  • 技術戦略・ビジョナリー
  • 組織化
  • 執行
  • 技術部門の体外的な「顔」
  • 社内の技術インフラとその運用
  • 事業化

企業によってこうした役割を組み合わせたりしています。

VPoEとは？CTOとは？ということも本書には明文化されています

CTOとは、その会社が現在の成長段階で必要としている戦略的技術系幹部

9章 文化の構築

構成員が、意識しなくても自然に仕事こなせる、そんな行動原理や行動様式が組織にあれば、それこそがその組織の「文化」である。 フレデリック・ラルー

ポリシー、企業理念、キャリアラダー、採用などあらゆる文化の創造していきます。 やり続けて、みんなが自然にやっていた。振り返れば文化ができていたんだとなるのかも知れません。

文化を創る事が最後の章に入っていますが、文化創りはボトムアップでもできます。私は今の会社でそうしてきました。あなたの会社の文化を創るのは、どんなレイヤーにいようがあなた自身です。

さいごに

結構長い記事になってしまいました。
が、本書の内容に比べたらスッカスカの記事です。

是非、本書を手にとって読んでほしいと思います。この本を通じて学ぶことは大きく、バイブルとして横においておきたいですね。

さいごに、本書にあった好きな言葉3つで締めようと思います。

追記. エンジニアリングマネージャーがイマ熱い！

エンジニアリングマネージャーの Meetup が開催されたり、

dskst9.hatenablog.com

ひろきさんとゆのんさんのエンジニアリングマネージャーについて語る Podcast が始まったり、

anchor.fm

エンジニアリングマネージャーが盛り上がっています！