マネジメントTweetエンジニアのためのマネジメントキャリアパスという書籍が出版されました。タイトルに書いたとおり、マネジメントに興味がなくても、読むこと大きな学びをもらえる本です。及川さんが前書きを書いており本書を読み終わった後、私はひどく落ち込んでいる自分に気づきました。~中略~内容が素晴らしい故に、いかに自分が未熟であったかを思い知らされたと、記載があって衝撃を受けました。及川さんが落ち込んだら、私なんて精神崩壊してしまうのではないか...!?本書を読んで、精神崩壊こそしなかったですが、ひどく落ち込みました。自分のレベルの低さを痛感します。本記事では本書の知識定着のためのアウトプットと、所感をまとめています。各章毎にピックアップして記載します。まとめ章立てを見てわかる通り、各キャリアのステップを辿るように構成されています。メンバーから、マネージャー、CTOまで。自分のキャリアのふりかえりと、今の自分、そしてこれからの自分を具体的にイメージができます。目次を見るだけでワクワクしてきませんか?なぜマネジメントに興味なくても読んだ方がいいのかあなたの上司は何をしていますか?あなたの上司がしていることは、あなたからは見えずらいものがあるかも知れません。この本からは上司がやるべき事が学べます。自分が上司になったらやるべきことが学べます。上司ができる上司なのかがわかるようになります。本当にできない上司の元にいるなら、上司にこの本をプレゼントしましょう。上司を超える上司にあなたがなる時かも知れません。マネジメントの基本できる上司はどんな上司なのか、上司には下記2つを求めましょう。1on1ミーティングフィードバックの提供1on1でつながりと要検討事項を1対1で話し合い、フィードバックをもらえるようにします。トレーニングとキャリアアップをしていきます。継続的フィードバックの最大の効能は、フィードバック自体の促進ではなく、その取り組みでチームの面々に注意を払う観察眼、見守る習慣を養うこと。2018年9月24日しかし、上司にはできないことがあります。「何があなたを幸せにするのか」は上司は教えることはできません。自分自身が何を望んでいるのか、何を学びたいのか、何が自分を幸せにするのかを考え抜いて明らかにする責任はひとえにあなた自身が負っているのです。己を知り、望みを叶えるための努力をしていく必要があります。その望みを上司と共有することで、できる上司は必ずサポートをしてくれます。メンタリングメンターになることは実はマネジメントの一歩目。このブログを読んでいる人は、一度はメンターをやったことがあるかも知れません。メンターとは何をやっていくべきなのか?傾聴などのスキルから、具体的な事例まで取り上げられています。常に好奇心を絶やさずオープンな心でメンティーを通してあなた自身も気付かされることがたくさんあります。好奇心を全開にしてメンタリングの一つ一つに対して向き合っていきましょう。相手の言葉をよく聞き、相手の言葉で話すメンタリングは否応なくコミュニケーションスキルが磨かれます。傾聴のスキルは訓練がものを言います。人脈作りキャリアは長く、テクノロジーの世界は狭い。どんな相手にも丁寧に接しましょう。テックリードテックリードとは?についてこう記載されています。いうワードだと思います。本書でもテックリードのコツが紹介されていますが、フォーカスはチームになっています。実際のプログラミングの作業からあっさり一歩引き、『技術面での貢献』と『チーム全体のニーズへの対応』のバランスを取る努力を惜しまないテックリードになるとこれまで拠り所にしていたプログラミングというスキルの他に、マネジメントスキルという新しいスキルが必要になります。その両者の「バランスの取り方」に習熟していく必要があるのです。私自身もマネージャーとして従事した時に、エンジニアよりも忙しくなったというより、時間配分が変わったと感じました。優秀なテックリードとはアーキテクチャを把握しているチームプレイの大切さを心得ている技術的な意思決定を主導するコミュニケーションの達人である印象的ですね。優秀なテックリードの条件のうち、半分は人間にフォーカスしたことが含まれています。人の管理で求められる主な仕事を次の4点に絞って考えています。部下と良好な関係を築くためには、相手を理解するための質問をして、信頼感と親近感を構築する必要があります。言われており、「車のエンジンオイルなようなもの」という表現がわかりやすいですね。1on1の進め方、フィードバックの文化、評価の方法までの話が展開されていきます。チームの管理さて、今度は人からチームの管理になります。ここから上はランクが上がるたびに「これまでとはまるで違う任務と課題を担う経験」を繰り返していきます。自分自身、リーダー、マネージャー、部長などやってきましたが、確かに全く違う任務と課題、そして全く違うスキルが求められていることを感じました。(そもそも職位毎のジョブディスクリプションも企業毎に違いますが。)チームの管理者として人的管理以外に焦点を当てるべき側面は何かこれ、大事ですね。技術のスキルはずっと必要です。技術面の意思決定を主導する責任を負っているのです。この先、経営陣になろうが、技術の面での責任はずっと負っているのです。自分の技術を維持する方法を考え、学習を続ける必要があります。チームの状況が悪くなった時。そんな時は思い出してください。プロダクトでバグが発生したらどうしていますか?事実を洗い、仮設を立て、検証し、原因を特定し、課題を解消していると思います。チームも組織も同様です。バグが発生したら、デバッグをしましょう。組織の問題をデバッグという観点で分析すると、すごく好奇心が刺激された。事実を洗い出し、仮説を立て、仮説を検証し、原因を特定、解決へのアクションをする。仮説を立てた段階で、その仮説が正しいか早く検証したい!というドキドキが始まった。2018年10月3日チームの意思決定は誰がやるのか?管理者に与えられているのは自ら決定を下す権限ではなく、チームによる意思決定を主導する権限にすぎない。それでいて、そうした意思決定の結果の善し悪しが管理者の能力の判断材料にされてしまうそんな意思決定を主導するコツが書かれています。「あなたはもうコードをあまり(あるいはまったく)書いていない」という状況です~中略~「人を管理する道へ舵を切る前に、まずは十分時間をかけてプログラミングを完全にマスターしましょう」いきなりインパクトのあるワードが書かれています。日々スケジュールに追われる中で、OSS活動や講演活動など創造的な活動しないといけません。学びは続けなければいけません。時間を管理して「重要な仕事」にフォーカスしましょう。時間管理のマトリクスにあるとおり、重要なものを最優先するようにします。緊急に惑わされない、緊急に逃げない。注目しがちな「気の散る要因」そんな時間のない管理者は仕事を委任をしていく必要があります。訓練目的で委任そして、意思決定。職務内容は複数チームを管理する管理者と同じになってきます。かかりっきりになるということです。そんな複数の管理者の管理のコツです。2ランク以上離れた部下から情報を得る直属の管理者達に責任を課する新任の管理者、ベテランの管理者を管理する管理者を新たに雇い入れる組織の「機能不全状態」の根を突き止めるチームの技術戦略を調整する特に機能不全状態の根を突き止めるは、前述のデバッグのところでも書きましたが、組織とプログラミングは似ていますね。仮設を立てる、データをチェックする、チームを観察する、質問をする、チームの人間関係をチェックする、支援に乗り出すこの辺りから戦略がとても重要になります。組織としての戦略です。技術系幹部のことを指します。経営幹部の職務とは次の4つのカテゴリーに大別できるようです。ロールモデルこの4種類の職務を果たすのが、技術部門の頂点に立っている人なのです。企業によってこうした役割を組み合わせたりしています。構成員が、意識しなくても自然に仕事こなせる、そんな行動原理や行動様式が組織にあれば、それこそがその組織の「文化」である。フレデリック・ラルーポリシー、企業理念、キャリアラダー、採用などあらゆる文化の創造していきます。やり続けて、みんなが自然にやっていた。振り返れば文化ができていたんだとなるのかも知れません。文化を創る事が最後の章に入っていますが、文化創りはボトムアップでもできます。私は今の会社でそうしてきました。あなたの会社の文化を創るのは、どんなレイヤーにいようがあなた自身です。さいごに結構長い記事になってしまいました。本書の内容に比べたらスッカスカの記事です。本書を手にとって読んでほしいと思います。この本を通じて学ぶことは大きく、バイブルとして横においておきたいですね。さいごに、本書にあった好きな言葉3つで締めようと思います。「学び」を決してやめてはならない。「学び」ということ自体がスキルである。明けましておめでとうございます。はてなブログProエンジニアリングマネージャーの日記。エンジニアリングのことや、書籍やマネジメント、趣味のことを書いてます。(1)Archiveスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。