エンジニアリングマネージャーのしごと ―チームが必要とするマネージャーになる方法
- オライリージャパン (2022年8月26日発売)
本棚登録 : 430人
感想 : 29件
- Amazon.co.jp ・本 (376ページ)
- / ISBN・EAN: 9784873119946
感想・レビュー・書評
-
エンジニアリングマネージャー
タスク
情報収集
決断
ナッジング
意図を伝えて相手の行動に影響を与える
ロールモデル
自身の行動とフィードバックで相手の行動に影響を与える
コミュニケーション
媒体を意識
対面、ビデオ通話
通話
チャット
メール
同期、非同期
会話、テキスト、非言語(ボディランゲージなど)
自己管理
スケジュール
メール
タスク
すべてのタスクはTODOリストで管理
アイデア
思いついたものを管理できるツールを用意
委譲
実行責任を渡すこと
説明責任
求められる品質でタスクを完了させる
実行責任
タスクを実行する
コントロールレベルを調整
自分がやり方を示す
相手が実行して自分がガイドする
相手が実行して自分がチェックする
チェック頻度は相手に合わせて調整
メンバーのパフォーマンスチェック
個人のスキルレベル
チームのスキル向上にどう関わるか
辛抱強いメンターか
チームに良い影響を与えるか
前向きでチームを鼓舞しているか
開発しているものの全体像、会社のニーズを理解してか
上司の視座で考える
今週の関心事は何か
懸念事項はなにか
他のメンバーの動きは
概要報告
前回からの進捗
問題点
対応方針
チームメンバーの状態
1on1
契約
サポートの必要性
何を求めるか
フィードバックの方法
悪い指摘は公開の場でも良いか、個別が良いか
一緒に働くうえでの問題は
自分のサポートが上手く行っていない場合のフィードバック方法は
ミーティング内容の機密性は
話す内容
前回からの気づき
他のメンバーへのフィードバックの収集
他のメンバーはどうだったか
プロジェクト、タスクの詳細
アーキテクチャの深堀り
プロセスの深堀り
メンバーへの情報共有
会社の方向性
自分のタスクの共有
チームのロードマップなど
コーチング
モチベーション管理
マズローの欲求階層
生理的欲求
適正な報酬
安全欲求
安定した仕事と安全な労働環境
愛と所属欲求
良い人間関係
良い刺激
徹底的に素直なフィードバック
承認欲求
自分がしたことの評価
公式
職位と昇格
非公式
フィードバック
自己実現欲求
成長のための挑戦
キャリアとして次に進めるところがあること
適切な仕事の委譲
新しいスキルを学べる環境の提供
自律性の尊重
学習者が支援ありでできるタスク
スキルツリー
目標に向かってのフロー
志向
一つのことをじっくりと深堀る
管理
色々なことに興味
変化
評価面談
ピアフィードバック
対象者と絡みのある人からのフィードバック
対象者は期間内に何をしたか
他の人と違うところは
それはなぜか
その他
匿名とするか
面談内容
評価者、対象者ともに
実績
成し遂げたことで満足していること
なぜか
評価者からみて感心したことは
役割、プロジェクト、キャリアへの振り返り
現在の役割についてどう思うか
伸ばしたい分野
成長のために何を学ぶべきか
評価者からみて伸ばすべきと思うところは
将来の役割について
成し遂げたいことは
どのような支援が必要か
内省を促す
ファシリテーションに徹する
悪い知らせへの反応の段階
無視
拒絶
他責
受容
展望
採用
品質、コスト、納期
優秀な人を安くすぐに採用することはできない
カルチャーフィット
モチベーション
学ぶことへの前向きさ
協調性
共感、親切さ
コミュニケーション
多様なバックグラウンドや視点
職務記述書
会社の紹介
ビジョン
役割と業務
なぜ重要なのか
どのような業務に取り組むことになるか
どのような職場環境か
候補者に求めること
経験、スキル、個性
メリット
福利厚生など
応募方法
面接プロセス設定、確認
選考
応募理由
仕事の役割や責任範囲
転居の必要性
想定する給与レンジ
退職
なぜ退職するのか
次の就職先
待遇
職務内容
報酬やキャリアアップ、職場環境等ならカウンターオファーの検討
辞めさせる
PIPを設定
明確な目標と期間
社内ネットワーク
対象を探す
同僚や上司がやり取りしている人
自己紹介
相手の課題などヒアリング
困っていること
欲しい情報
協業できそうなこと
返信がないのは今は困っていないということ
定期的にやり取りする
四半期に一回
お返し
メンタリング
指導的
メンターはマネジメントはしない
はじめに明確にしておく
コーチング
興味に従う
相手が自分で結論にたどり着くように働きかける
傾聴
審判抜きに観察
呼吸に集中
質問、提案、要約
対象とする問題を明確に
状況を明確に
選択肢を明確に
採るべき選択肢は
ダイニングクルーガー効果⇔インポスター症候群
プロジェクト
警告サイン
今までよりも進捗などに興味を持たれ始めた
注目されているとき
チームの足並みを揃える
頻繁なコミュニケーション
反応やフィードバック
頻繁なリリース
スコープ、リリース、時間
それぞれを状況に合わせて調整
マネジメント
ファシリテーション
共感
寛容性
素直性
情報
完全機密
誰にも知らせない
情報の存在も
密閉箱
関係者のみに内容を共有
関係者以外は概念やプロセスの存在は知らせても良い
開放箱
広く共有
社内政治
組織体制、グループ、キーマンの把握
チームとつながる
合意形成する
自分でいる
間違えている場合は意義を受け入れイニシアティブを渡す
0
詳細をみるコメント0件をすべて表示 -
冒頭にある「テック企業はスキルの危機にある。私たちが人をどう扱えば良いのか知らないから」という一文にはとても共感できる。ソフトウェアの開発という特殊スキルはあっても人を率いる術は何も知らない我々の脆さをよく表している。
マネジメントに関する書籍は世に山ほどあれど、テック企業の文脈に寄せてその詳細を取り扱う書籍はあまりないのではないか。初版も2022年8月なので、リモートワークが普及した以降の働き方を時代背景としている。詳細が陳腐化しないうちに手に取っておきたい1冊。
0
-
■日々取り組んでいるマネジメントの活動
・情報収集
・意思決定
・ナッジング
・ロールモデル
■1on1におけるコントラクティング
①いちばんサポートが必要な分野はどこか？
②どんな形でフィードバックやサポートを受けたいのか？
③一緒に働く上での問題は何か？
④私のサポートがうまくいっていないことはどうすればわかるか？
⑤ミーティングの内容の機密性はどれくらいか？
■学習者が継続的にスキルを向上させていくために重要な2つのこと
・発達の最近接領域内でタスクを与えられること
・タスクの完成を支援する豊富な知識を持つ適任者がいること
■最近の機能横断的チーム構成
・複数人のエンジニア
・デザイナー1人以上
・QA1人以上
・アジャイル実践者1人
・プロダクトマネージャー1人
・エンジニアリングマネージャー1人
■望ましい特徴
・モチベーション
・学ぶことへの前向きさ
・コラボレーションスキル
・良いコミュニケーション
・共感と親切さ
・多様なバックグラウンドや視点
・会社とあなたの価値観、倫理観との一致
■一次面接の質問例
導入
・会社について説明します。
・採用された場合、チームで何をするかを説明します。
候補者の現在の仕事
・直近の役割では何をどのようにやっていましたか?
・チーム、部門、会社の規模は?
・直近の役割で、典型的な1日の過ごし方は?
・ソフトウェアをどのように定義し、コーディングし、リリースしていましたか?
・現在も働いているなら、離職しようと考えた理由は?
技術的スキルと知識
・現在のコードベースやアーキテクチャーの構造はどうなっていますか? 良い点、悪い点は?
・ソフトウェアのテストをどう行っていますか? テストの責任を負っているのは誰ですか?
・好みのフレームワーク/言語/ライブラリはありますか? 好きな理由は?
・採用先のチームが使っているフレームワークライブラリの経験はありますか?
一般的で技術的な質問
・どのIDEを使っていますか?そのIDEの好きなところは?
・最近使ったソフトウェアでいちばんおもしろかったのは?それはなぜですか?
・最初に使ったコンピューターは何でしたか?
まとめ:
・質問があるか尋ねます。
・面接の次のステップについて知らせます。
■GROWモデル
・ゴール(Goal)：このセッションのゴールは何ですか?どんな問題を解決しようとしていますか?
・リアリティ(Reality)：今はどんな状況でしょうか?誰が、何を、どこで、どれくらい?
・オプション(Options)：この問題に取り組むために考えられる、ありとあらゆる方法は?
・ラップアップ(Wrap-up)：選択肢をはっきりさせ、コミットし、どんなサポートが必要かを議論します。
だんだんわかってきたと思います。マネージャーとしての仕事の一部は、うまくいっているチームの害となるような、過度に面倒で破壊的で感情的なものをチームに入れない盾になることなのです。情報を咀嚼し、飲み込みやすいように、じわじわと与える役目になる必要が頻繁にあるでしょう。ときには、完全に遮断してあげることも必要です。チームに影響を与えるようなぐらつきを抑えることが必要なのです。
■人の意見や自分の決断力に影響を与えるもの
・ダニング=クルーガー効果：能力の低い人ほど自分は優れていると錯覚する認知バイアス。
・インポスター症候群：高い実績を持つ人が自分の功績を内面化できず、偽物か詐欺師だと露呈することを恐れるという概念。
■成功していると…
・普段の仕事が大変になる。うまくやっていると仕事が増えます。顧客はSLAの向上を期待します。アプリケーションのセキュリティに関する作業が増えます。監視やアラートは改善が必要になります。それから、オンコール担当も設定しなければいけません。ストレージも拡張しなければいけなくなります。アーキテクチャーの見直しも必要かもしれません。ただ正常に動かすだけでも、それにかかる時間と労力が増えていきます。
・レガシーコードを扱う機会がさらに増える。昨日の新機能は、今日の技術的負債です。プロダクトの方向性の変化や会社のピボットが、やっつけ仕事や書き直しを引き起こします。それがとんでもないやっつけ方でないにしても、増え続けるコードベースによって新しい機能を作る上での最善の方法を理解し、それを実装するのに長い時間がかかるようになります。
・コミュニケーションとプロセスのオーバーヘッドが増え続ける。スタートアップでは、一方通行の意思決定をすばやく行うことができます。巨大な多国籍企業の意思決定は、氷河のような速度です。同意を得るのに、どれだけたくさんの人が必要でしょうか?そこに至るまで、どれだけたくさんのミーティングやメールが必要でしょうか?コミュニケーションチャネルは、スタッフの数よりも多くなっていて、潜在的には、人数(人数-1)/2のチャネルがあります。400人のスタッフがいる会社であれば、79,800 チャネルです!
■スコープ
・機能を「Must」、「Should」、「Could」、「Won't」に分解する。「Must」のラベルがついたものは、絶対に実現しなげればいけません。「Should」のラベルがついたものは重要ですが、最初のマイルストーンや締め切りのときにはなくてもよいかもしれません。たとえば、時間的にクリティカルでなければ、「Must」のものを全部リリースしてから、インクリメントをリリースしてもよいでしょう。「Could」のラベルがついたものは、あるとよいですが必須ではありません。「Won't」のカテゴリは、何かを検討して、意図的にやらない意思決定をしたことを示しています。このような方法で作業にラベルをつけることで、チームが困難な状態に陥ったときに、「Must」のものを終わらせることに専念し、それ以外を後回しにできるのが極めて明確になります。このあとの図でも示しているように、この優先順位付けのテクニックをMoSCoW法と呼びます。
・ストレッチゴールを推奨する。機能にラベルを付けて、優先順位付けのためにランキングをつけたら、プロダクトオーナーとチームは一緒にマイルストーンがどこになるか決定します。チームは全部の「Must」とたくさんの「Should」を最初のリリースで目指すべきでしょうか?どの「Should」は2回目のリリースにできるでしょうか?これを事前に決めておくことで、作業のためのバッファを確保して、将来のストレスやパニックを軽減できます。遅れや技術的な問題が発生した場合に、スコープのどの部分を外せるかを知っておくことで 物事がうまくいかないときのセーフネットが手に入ります。
■コントロールの三分法
・自分でコントロールできること→結果について心配する
・自分でコントロールできないこと→結果について心配しない
・自分である程度コントロールできること→内部ゴールを設定しベストを尽くす
■インディビジュアルコントロールトラック
ICトラックにおけるキャリアアップは通常、テック企業で見られる以下のようなものになります。会社によってキャリアアップの実装は微妙に異なるため、これは例にすぎません。トラックの各段階をレベルと呼びます。レベルはLで始まり数字で表されます。
L1：ジュニアエンジニア(アメリカ以外で一般的)
L2：エンジニア
L3：シニアエンジニア
L4およびL5：スタッフエンジニア
L6以上：プリンシパルエンジニア
ICは技術的な専門知識と影響力で、その価値を発揮します。コードを読み書きし、問題を解決相当な量の時間を割くことが通常です。エンジニアでも、デザイナーでも、QAでも、他にもいろいろなICがいます。最大の特徴は、ラインマネジメントを一切しないことです。その仕事は別物です。
■影響力
・ICが書いたソフトウェア。シンプルで洗練された拡張性の高いコードを書いて、問題を効率的に解決しているでしょうか?
・正味の貢献。他の人のために標準を作りながら、大部分を独力で進めているでしょうか?それとも、自分のタスクを終わらせるために周囲の助けをたくさん必要としますか?
・周囲との協調性。チームのニーズや、ときには反発も理解し、前進するための方法を見つけるようなチームプレイヤーでしょうか?
・メンターシップのスキル。経験の少ないエンジニアから日常的に助けを求められたり、それに応えることで自分自身のスキルを向上したりできるような、生まれついてのメンター気質でしょうか?
・周囲のエンジニアに対する影響。周囲に受け入れられるような提案をしていますか?自分のチーム外の人にも何をどうやって作るか助言していますか?
・アイデアの革新性。新しい機能を実現したり、ソフトウェアの速度を改善したり、ソフトウェアのコストを削減するために使える可能性のある技術について、新しい方法を提案していますか?
・ビジネスの最終的な損益に対する影響力。周囲のエンジニアの速度を上げたり(例：再利用可能なアーキテクチャーを作る)、プロダクトにかかるコストを削減したり(例：既存システムのアーキテクチャーを作り直す)して、効果的で新しいやり方での課題解決に関与していますか?
■キャリアアップ表
【業界経験】
1：関連する技術の講座を受けた経験がある(学部や自主学習など)。業界での経験は、まったくもしくはほとんどない
2：学校教育を含め3~7年の経験がある。ソフトウェア開発チームでの経験があり、チームワークやソフトウェアを作ってリリースすることへの理解がある
3：7年以上の経験がある。その領域における技術的専門家で、仕様どおりかつ期限内に仕事を終わらせる確かな実績を持っている
【技術的知識】
1：問題を分析し解決策を提案できる。比較的シンプルな解決策は1人で、複雑な解決策はシニアエンジニアに質問することで実装できる。プロジェクトに貢献する時間と、新しいスキルの習得と開拓に割く時間のバランスを取っている
2：オープンソースのソフトウエアやフレームワークなどを含め、選択した言語や技術スタックに堪能である。新技術を取り上げ、その使い方を周囲に教えることができる。ほとんどの問題に1人で対処できる。
3：さまざまな技術の専門家である。自分のチームだけでなく他のチームから技術的な判断について相談を受けられる。チームのコードをレビューする。最新かつ優れたオープンソースのソフトウェアや技術に関する知識が豊富で、チームに取り入れることができる。自分の知識は周囲に共有する
【メンターシップ】
1：自分よりシニアなスタッフから助言を受けることが多い
2：ジュニアエンジニアを指導してレベルを引き上げ優秀なチームメンバーにできる
3：技術スタックのさまざまな箇所について、周囲に助言ができる主力の人である。エンジニアを専門家に転身させることができる。優れた師である
【影響力】
1：同僚と強力な関係を作ることができる
2：仕事を完成させ周囲に技術的な助言ができることで定評がある
3：プロジェクトにいて手伝ってほしい人だとみんなに思われている。周囲の人からその人が考えた手法の正当性の確認のために、意見を求められることが多い
エンジニアリングマネージャー(L3)/エンジニアリングディレクター(L4)/エンジニアリング担当VP(L5)
【業界経験】
3：マネージャーになることについては本人が意識的に選択した。以前にマネジメント経験があるか、もしくは、マネジメントトラックに進みたがっているかのどちらかである。初めてマネージャーになる人には、会社がトレーニングやメンターシッブの機会を提供する。卓越した技術的スキルや人間関係のスキルを持ち、前に立ってリードする。プロダクトやエンジニアリングやデザインの部門とうまくコミュニケーションができ、プロジェクトを成功させる能力がある
4：人やチームのマネージャー、もしくはプロジェクトマネージャーとしての実績がある。エンジニアリング部門の下位部門、できれば複数チーム(戦略的領域、技術的職務、地理的領域)の責任者である
5：複数チームのマネジメントと戦略的もしくは技術的領域の責任者の経験実績がある。複数チームからなるエンジニアリング部門を運営している
【影響力】
3：周囲に権限を与えて仕事を任せ、前に立ってチームをリードしている。「この人のために働きたい」と思われる人である。チームを良い場所にしている。技術的能力と同じようにコミュニケーションスキルにも影響を与えている
4：部署の全スタッフに影響を及ぼす。チームが効率的で素晴らしいプロジェクトを届けていることを保証している。将来の技術やプロダクトの方向性について話し合っている。エンジニアリング担当VPと共に働き、部署の戦略に関わっている
5：内から外から部門全体に影響を及ぼす。チームが効率的で素晴らしいプロジェクトを届けていることを保証している。将来の技術やプロダクトの方向性について話し合っている。部門全体としてどういう理由で何をしているのかについての主たるステークホルダーである
【効率性】
3：効率的にチームに仕事を任せることができる。チームのアウトプットが、自分自身のアウトプットより良いものになることがわかっている。もっと効率的に物事を終わらせるために、タスクの優先順位を話し合う。 自分の役割を効率的にするために時間を整理できる
4：チームを活用して仕事を任せることができる。部署をもっとよくするために何をどのようにすべきかについて、議論し決定できる。いちばんインパクトの高い領域に時間を使うこと高い領域に時間を使うことを選択する
５：部署全体のアウトプットを監督できるように、エンジニアリングディレクターのコンピテンシーを踏まえる。スタッフと緊密に働き、進むべき最善の道について話し合い、優先順位をつけ、決定する
0
-
資料ＩＤ :82200250
請求記号 :007.35||S
配置場所：工枚ITエンジニア大賞
（※配置場所は、レビュー投稿時のものです。）
0
-
ある程度エンジニアリングマネージャー経験を積んだ者であれば、思わず「うっ」となるような瞬間が押し寄せ続けるだろう。ということは、これからエンジニアリングマネージャーの荒波に揉まれる人にとってはまたとないガイドブックとなる。
人と向き合うマネジメントの本質は、それこそピータードラッカーの時代からそう大きく変わっているものではない。人が頻繁に辞めること、アジャイル開発が傍らにあること、スタートアップが向き合うべきものとして語られることは「エンジニアリング」マネージャーならではの特色だろうか。
EM業に悩む人、これからEMを志す人には必携だろう。よろヒヒーン！
0
-
エンジニアリングマネージャーの仕事
コンピュータサイエンスの博士号を持ち、プログラマーからマネージャーに転身し活躍するJames Stanier氏の著書です。
プログラマーがキャリアの中で必ず岐路に立つ、プログラマーを継続するか、マネージャーの路線に行くか・・・
「エンジニアリングマネージャーのしごと」とは、どのようなもので、何をするのかを新米マネージャーになったことろから学べる内容となっています。
プログラマーをまとめるマネージャーに特化した内容になっており、ありそうでなった一冊です。
【本書で学べること・考えること】
- 3つの視点（自分、上司、チーム）で考える
- まず、自分の業務を整理する
- 人とのコミュニケーション
- 1on1のやり方
- 人に合った仕事とは
- フィードバック面談の仕方
- 採用活動
- 退職関連
- 社内での影響力
- 人間の特徴
- 情報の取り扱い
- 断捨離
- ハウスキーピングの仕組み
- キャリア形成（マネージャー、エンジニア）
- 現代の職場環境
- スタートアップ
- ふりかえり方法
読んでみての感想です。
マネージャー業務の全体を網羅しており、マネージャーの経験が浅い人、マネージャーに興味がある人が読むには有用な内容だと思います。
ただ、海外の方が書かれているので、日本ではそのままでは馴染まないという内容もあります。（退職や採用など）
IT業界に特化したマネージャーの本は、ありそうでなかったので、参考になります。
自分が受けてきた1on1などは、きちんとこの本に書かれている手順で行われていたことがわかり、自分が行う時は、同じようにやっていけばよいということもわかりました。
0
-
邦訳版が発刊されてすぐに会社で読書会を始め、毎週1章ずつ、おおよそ5ヶ月かけて読みました。この本を肴に自分の会社ではどうなんだ、という観点で会話する感じで。
まず、全18章の章立てそのものがEMとして考慮しなければいけない切り口を示してくれていてそれだけで参考になる。
そしてぶち当たるスパン・オブ・コントロールの壁。
完璧超人にはなれないけれど、たまに眺め直すとよさそうな書籍。また、マネージャー同士で会話する時のベンチマークになりそう。
0
-
抽象度が高く結局何が言いたいのかわからない本と違い、ちょうど良い抽象度でエンジニアマネージャーに初めてなる人を指南してくれる存在だと思います。
初めてリーダーとなった 30 歳くらいの時にこの本があれば良かったのにと思いました。
マネージャーとなった方の内省や後進育成用のツールとしても有用だと思うので、エンジニアリングのマネジメントに関わる人にはお奨めできると思います。
0
-
EMという定義や責任は組織に応じて異なるかと思うロールに対して、EMがやりそうなこと・持つべきマインドを包括的に扱っているガイドのような本。リファレンス的に使えそう。
本書の中で何度も取り上げられている重要な点は、マネージャー自身のアウトプットは、チームと影響を与えたチームのアウトプットであって、自作業の効率化やタスクをこなすことではないということ。
0
吉羽龍太郎の作品
