1. マネージャーのしごと 2022/12/9 株式会社アトラクタ 吉羽龍太郎
2. 吉羽 龍太郎 (@ryuzee) ✤ 株式会社アトラクタ取締役CTO/アジャイルコーチ ✤ Scrum Alliance ✤ 認定スクラムトレーナー Regional (CST-R) ✤ 認定チームコーチ (CTC) ✤ 『SCRUM BOOT CAMP THE BOOK』 『スクラム実践者が知るべき97のこと』 『みんなでアジャイル』 『プロダクトマネジメント』 『レガシーコードからの脱却』ほか ✤ @ryuzee / https://www.ryuzee.com/
4. エンジニアリングマネージャーのしごと (8/26発売) 本書は、エンジニアリングチームのマネジメントの仕事全般を 紹介し、エンジニアリングマネージャーに必要な考え方やスキ ルを解説します。 はじめに、自分の役割と組織のさまざまな部分がどう関係する かを理解し、習慣を整えることで自分自身を管理することを学 びます。そして、日々のマネジメント業務で必要なツールとプロ セスを紹介し、スタッフとの関係性の構築、モチベーションの理 解、評価や採用などを解説します。さらに社内政治や難しい状 況での判断、その後のキャリアについて説明します。 マネジメントのさまざまな段階に沿って、日々の仕事に取り入 れられる実践的なアドバイスを紹介する本書は、エンジニアリ ングチームのマネージャーに必携の一冊です。 4
5. マネージャーと名の付く職種 ✤ プロジェクトマネージャー ✤ プロダクトマネージャー ✤ エンジニアリングマネージャー ✤ …… ✤ そして単なる「マネージャー」 5
6. プロジェクトマネージャー ✤ プロジェクトとは？ ✤ ✤ 「プロジェクトとは、独自のプロダクト、サービス、所産を創造するために 実施する有期的な業務」 ^1 プロジェクトマネージャーとは？ ✤ 「母体組織に任命された人で、プロジェクト・チームを率いてプロジェクト 目標を達成する責任を負う」 ^1 ✤ つまり、プロジェクトマネジメント全般の責任、予め決められた期間の中で、 事前に定めた目標を達成する責任を持つ ✤ プロジェクトが終われば任務が終わる [^1]: PMBOKガイド 第7版 p.4 6
7. プロダクトマネージャー ✤ 「プロダクトマネジャーの責任は明快だ。可能性を評価し、何を作って顧客 に届けるのかを判断することだ」 ^1 ✤ 「プロダクトマネージャーには2種類の仕事がある。プロダクトを育てること と、ステークホルダーをまとめプロダクトチームを率いることである。プロダ クトマネージャーは、（略）ステークホルダーの承認を得たうえでプロダクト に関係する意思決定に責任をもつ」 ^2 ✤ プロダクトが続く限り誰かがその任務につく [^1]: マーティ・ケーガン著『INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント』日本能率協会マネジメントセンター [^2]: 及川 卓也、曽根原 春樹、小城 久美子 著『プロダクトマネジメントのすべて 事業戦略・IT開発・UXデザイン・マーケティングからチーム・組織運営まで』翔泳社 7
8. エンジニアリングマネージャー ✤ エンジニアリング組織のマネージャー ✤ 業務内容の定義は統一されたものはないが、ピープルマネジメントとテクノロジーマネジメントを 担うとされることが多い ✤ 組織によってはテクノロジーマネジメントをテックリードに分離することも ✤ ピープルマネジメント ✤ チームの方向付け ✤ チームのパフォーマンスを上げる ✤ 個々人のパフォーマンスを上げる ✤ 採用や評価 ✤ 言い換えると、持続可能なチーム作り 8
9. 「マネージャー」 ✤ 1910年代にアンリ・ファヨールが提唱 ✤ 1950年代にピーター・ドラッカーも定義 ✤ マネージャーの責任 ^1 ✤ ✤ 投入した資源の総和よりも大きなものを生み出す生産体を創造する ✤ ただちに必要とされているものと遠い将来に必要とされるものを調和させていく マネージャーの共通の仕事 ^2 ✤ ①目標を設定する ②組織する ③動機づけとコミュニケーションを図る ④評価測定する ⑤ 人材を開発する [^1]: ピーター・ドラッカー著『【エッセンシャル版】マネジメント - 基本と原則』ダイヤモンド社 p.128-129 [^2]: 目標管理制度の登場のきっかけといわれる 9
10. 「マネージャー」 マネージャーのアウトプット = 自分の組織のアウトプット + 自分の影響力が及ぶ隣接諸組織のアウトプット^1 ✤ ✤ すべての活動はアウトプットを向上させるためにある ✤ チームのアウトプットはマネージャー個人のアウトプットより重要 ✤ 他のチームに悪い影響を与えると、アウトプットの総量は下がる ここでのアウトプットは「アウトカム」の意味に近い（単なる生産量ではない） [^1]: アンドリュー・グローブ著『High Output Management』日経BP社 p.85 10
11. ここまでのまとめ 役割 責任 プロジェクトマネージャー プロジェクトの目標を達成する プロダクトマネージャー プロダクト開発を率いる エンジニアリングマネージャー ピープルマネジメントとテクノロジーマネジメント 「マネージャー」 投入資源よりも大きなものを生み出す組織を作る 11
12. ある役割のJDに記載された責任の例 ✤ エンジニアへのタスクのアサイン ✤ 各種プロジェクトの進捗を把握する ✤ お客様との効果的なコミュニケーション ✤ 営業チームとの協働による新製品の創出 ✤ 各種プロジェクトの予算提案 ✤ プロジェクトの最新情報を伝えるためのレポート作成 ✤ 展示会・会議への参加 ✤ 新入社員の教育 これは何の役割でしょうか？ https://www.glassdoor.com/Job-Descriptions/Engineering-Manager.htm より引用・翻訳 12
13. 問題意識 ✤ 人によって、それぞれの役割が何に責任を持っているかに対する認識が違う ✤ そもそも組織ごとに、同じ役割の名前でも責任や業務内容が異なることも多い ✤ 一口に「マネージャー」と言っていて、実体として複数の役割を担っていることも多い ✤ ✤ （例）プロジェクトマネージャー 兼 エンジニアリングマネージャー つまり名前はどうあれ仕事の責任範囲が曖昧で広い ^1 ✤ 一人で全てを担おうとすると大変 [^1]: スクラムではプロジェクトマネージャーですら責任範囲が広すぎると考えて、プロダクトオーナー、開発者、スクラムマスターで責任を分担することにした 13
14. 自分の「マネージャー」事例 ✤ SIerの開発部門 ✤ 外資系クラウドベンダーのコンサルティング部門 14
15. SIerの開発部門 ✤ 新規事業をやる部署で、部署ができてから1年くらいで配属 ✤ 最初は自分より10才くらい上の人がマネージャーをしていた ✤ ビジネスがうまくいっていてどんどん人が増える ✤ そのうちグループに分割 ✤ 自然に10人くらいのチームのマネージャーになる ✤ そもそもマネージャーとしての教育も受けていない ✤ 新設の部署で確固たるやり方は確立していない ✤ エンジニアリングマネージャーとプロジェクトマネージャーの両方を同時に担当 ✤ チームの人は優秀な人が多かった 15
16. どうなったか ✤ 障害報告で謝りにいく回数は増えた ✤ 全システムの夜間コールに入り、夜中に携帯電話が鳴る回数が増えた ✤ 事務作業は増えた ✤ 労働時間は増えた ✤ コードを書く時間は減った ✤ ストレスは増えた ✤ 家族との時間は減った ✤ チームメンバーへの関心は減った ✤ 組織のミッションやビジョンの達成への関心は減った 16
18. どう対処したか ✤ お金にならない割に手間の多いプロジェクトから撤退した ✤ 全プロジェクトでチケット管理ツールを利用して仕事量を可視化した ✤ Wikiでノウハウを残し、再利用できるようにした ✤ 品質の基準を詳細に定義して、外部委託時にその遵守を条件にした ✤ アジャイル型に変え、顧客と頻繁に現物確認するようにした ✤ 1つのプロジェクトに複数人のプロパーを割り当てた。兼任を減らした ✤ よく障害が起きる箇所を予防的に改善した ✤ 夜間に動かすバッチ処理を最小限にした ✤ いわゆるサバイバルモード^1……こんなことを数年やっていた [^1]: Roy Osherove著、島田浩二訳『エラスティックリーダーシップ ―自己組織化チームの育て方』オライリー・ジャパン p.31 18
19. このときの学び ✤ エンジニアリングマネージャーとプロジェクトマネージャーを同時にやるのは無理 ✤ 兼任は片方で問題が起こると、もう片方にも波及する ✤ どうしてもプロジェクトのデリバリーを優先する力が働きやすい ✤ ステークホルダーや顧客ははっきりと不満を表明するし、自分を責める ✤ それを避けるために、チームを犠牲にしがち ✤ 補足: プロジェクトに関与しないという意味ではない ✤ 改善したければ、まず仕事を減らして余裕を作る必要がある ✤ 問題が起きにくい仕掛けやプロセスを作らないとモグラたたき 19
20. 外資系ベンダーのコンサル部門 ✤ 日本に新設されたコンサルティング部門の第1号コンサルタントとして採用 ✤ 入社後の直属の上司は海外で、日本の別ラインのマネージャーからもサポートを受ける ✤ ビジネスが好調でコンサルティング部門でどんどん人が増える ✤ 入社1年半くらいに、海外からマネジメントするのも大変ということで、日本にマネージャーを置 くことになる ✤ よくわからん人にマネジメントされたくなかったので自分が手を挙げる ✤ そして「マネージャー」になる 20
21. このときの状況 ✤ 部門の仕事のやり方はある程度決まっていた。日本の仕事のやり方はそれを真似した ✤ 組織が成長を続けていたのでやり方はどんどん改善されていった ✤ ピープルマネージャーを主に担当 ✤ 顧客案件は継続中のものを除いて担当しなかった ✤ チームの人は優秀な人が多かった 21
22. どうなったか ✤ 労働時間に変わりはなかった ✤ 仕事のほとんどの時間を、採用、1on1、評価、戦略策定、組織運営に使った ✤ 技術的な仕事は軽い案件や相談、レビューの対応など ✤ チームは機能してハイパフォーマンスだった（自走していた） ✤ （それでもストレスは溜まった） 22
23. このときの学び: マネージャー教育 ✤ マネージャーになる前後で多くの教育プログラムを受けた ✤ ✤ 組織によってマネージャーに求めることは違う ✤ ✤ 1on1 / 採用 / 評価 / コーチング / 文章術 / チームビルディングなど 組織が必要としていることができるようになっていないとマネージャーとして機能しない つまり、マネージャー教育はとても重要 23
24. このときの学び: 採用 ✤ 採用はマネージャーの重要な仕事 ✤ 良い人を採用すればおのずと成果は上がりやすくなる ✤ 「良いチームを作りたければ、良い人を採用する」という当たり前な話 ✤ 問題への対処に時間をかけるくらいなら採用に時間をかけた方が合理的 ✤ ジョブディスクリプションを書く、エージェントと話す、優秀な人に直接声をかける、レジュメを読 む、インタビューの質問を準備する、インタビューする、フィードバックを記入する、デブリーフィ ングする…… ✤ 良い人を見逃すことよりも、良くない人を間違って採用する方が怖い ✤ 技術力だけでなく、文化やチームにあっているかも重要 24
25. このときの学び: 目標設定 ✤ ✤ 目標設定は階層構造で、常に進捗を明らかにする ✤ 部門の年間目標を元に、チームの目標にブレークダウンする ✤ チームの目標を個人の目標にブレークダウンする ✤ 部門の目標もチームの目標も全員が知っていて、個人の目標の意義が分かる 部門の年間目標は変わることもある。ビジネスが変化するので当然 ✤ その場合は、チーム目標も個人目標もアップデートする ✤ 進捗は常に見える化し、1on1で継続的に話し合ってフィードバックする ✤ 4半期ごとに文章化して全員でレビューする ✤ 「共通の目標」はチームを機能させる上でいちばん重要な要素の1つ ✤ 明言はしていなかったが、OKR^1に近い [^1]: クリスティーナ・ウォドキー著、二木夢子訳『OKR(オーケーアール) シリコンバレー式で大胆な目標を達成する方法』日経BP 25
26. このときの学び: 評価 ✤ 評価の妥当性を追求する ✤ ✤ ✤ 評価が妥当であることは、パフォーマンスを出す上でとても重要 2つの軸を組み合わせて評価する ✤ 組織の目標から生成した個人目標を使った定量的評価 ✤ 一緒に働いている人たちからのフィードバックを元にした定性的評価（チームプレイヤーか どうか、正しいふるまいをしているか） 定量評価だけにすると組織は崩壊する ✤ 最近はノーレイティングの会社も増えている 26
27. 最大の学び: 「マネージャー」は選択肢の1つに過ぎない ✤ 自分に「マネージャー」としての競争力がないことが分かった（できなくはない） ✤ 好き嫌い、向き不向き、競争力の有無がある ✤ マネージャーとして必要なスキルセットがあり、これはエンジニアのスキルとは別 ✤ 全員がマネージャーになる必要はないし、マネージャーからICに戻ってもいい 27
28. 理想的なキャリアラダー レベル エンジニア系 プロダクト系 マネージャー系 5 チーフエンジニア チーフプロダクトマネージャー ディレクター 4 プリンシパルエンジニア シニアプロダクトマネージャー シニアマネージャー 3 シニアエンジニア プロダクトマネージャー マネージャー 2 エンジニア アソシエイトプロダクトマネージ ャー 1 アソシエイトエンジニア [^1]: プロジェクトマネージャーはエンジニア系専門職に入る可能性が高い [^2]: あくまでイメージであり、同一レベル同士の妥当性等は気にしないでほしい 28
29. 月曜日が楽しみになるキャリアを選ぼう 29
30. それでも… 「マネージャー」をうまくやりたいなら？ 30
31. 期待値を確認する ✤ 「マネージャー」が意味することは組織によって大きく違う ✤ どんな責任を持つのかを明らかにしよう ✤ 上司と期待値や責任範囲を確認するのが王道 ✤ そうしないと、上司からの自分の評価がギャンブルになってしまう…… 31
32. 自分のキャパシティをうまく使う ✤ マネージャーにはたくさんの仕事がある（？） ✤ ✤ マネージャーには多くの突発的な仕事が割り込んでくる ✤ ✤ マネージャーがいつも忙しい人（つかまらない人）なのはまずい 自分が考えたり作業したりするための時間も必要 ✤ ✤ 大規模障害、メンバーからの悩み相談、予算プロセス、評価面談…… チームから目を離していると問題が大きくなってしまう ✤ ✤ 情報収集、意思決定、ナッジング、ロールモデル みんなが帰ったあとや週末にやらない つまり、キャパシティに余裕をもたせなければいけない 32
33. 自分自身を整理整頓する ✤ ✤ ✤ マネージャーにはありとあらゆるところから、あらゆる情報が殺到してくる ✤ 必要なときに簡単に情報を探したり、見返したりできるようにしておかなければいけない ✤ 記憶に頼る情報はなるべく少なくする カレンダー、ToDoリスト、メールボックス、情報記録ツールの活用 ✤ このあたりのテクニックは巷にあふれているが、自分にあったシステムを作る ✤ 自分の場合は、Google Calendar、Microsoft ToDo、Gmail、Obsidian 自分自身を整理整頓できていないのに、より大きなチームを効果的に扱えるはずがない 33
34. 自分のエネルギーをマネジメントする ✤ 理想はいつも機嫌よく安定していること ✤ とはいえ人間なので、悲しくなったり、怒ったり、フラストレーションがたまることがある ✤ フラストレーションは言葉でなくても、表情、腕組み、姿勢などから伝わる ✤ このような負のエネルギーをそのまま持ち込まないようにする ✤ 2回測って1回切る ✤ 言うのは簡単だが、めちゃくちゃ難しい 34
35. 仕事を移譲する ✤ マネージャーとしてのアウトプットを最大化しようと思うなら、なんでもかんでも自分でやるの はよくないのは自明（というか無理） ✤ 移譲が重要になってくる ✤ ✤ プロジェクトマネージャーやプロダクトマネージャーの仕事は手放す（のが無難） 説明責任は移譲できない。移譲できるのは実行責任まで ✤ 説明責任を移譲すると単なる丸投げ 35
36. 移譲には段階がある（人ごと・タスクごと） 出典: 『エンジニアリングマネージャーのしごと』（オライリー・ジャパン、2022、p51） ✤ タスクごと、人ごとに移譲の度合いは異なる ✤ 教育、コーチング、メンタリング、確認が必要になる ✤ どのタスクをどの程度移譲するのかの選択はマネージャーの責任 ✤ 時間とともに、学習が進んでできることが増え、チームのアウトプットと有効性が上がる 36
37. マネージャーとしての不安 ✤ 締め切り直前とか大事故 発生したときな 、委譲した仕事を取り返して自分 やったほう 早いし、品質も間違いないと考える ✤ 移譲したタスクの進捗が心配になる ✤ 期待した品質でタスクが完成しないことにイライラする ✤ これらの不安やイライラが私生活に入り込む が で ど が 37
38. すべてをコントロールしようと思わない ✤ すべてのことをコントロールすることはできない ✤ コントロールの三分法 コントロール きるもの。自分たちの願望やゴール ✤ ✤ 結果について心配する まったくコントロール きないもの。天候な ✤ ✤ 結果について心配しない ある程度コントロール きるもの。テニスの試合に勝ちたいという願望なと ✤ ✤ 内部ゴールを設定してベストを尽く ど で で で 38
39. スタッフの欲求を考える ✤ スタッフ 欲求を満たせるように多くの機会を作るのは、マネー ャーとしての責任 ✤ 管理と安定によってモチベーションが高くなる人（大聖堂を建設する人） ✤ カオスや変化によってモチベーションが高くなる人（バザールをぶらつく人） ✤ 自分のチームのメンバーがどちらを好むのかによって、仕事の割り当て方、移譲の仕方、望まし い仕事の環境は変わってくる ジ が 39
40. 自己実現の欲求が実現するように支援する ✤ 適切な仕事を適切なスタッフに委譲し、スタッフが学び、貢献し、成長する継続的な機会を持て るようにすること ✤ 仕事、トレーニングやカンファレンスへの参加などを通して、新しいスキルを学ぶための環境を 提供すること ✤ 発達の最近接領域を踏まえて、成長につながる仕事と支援を与えること ✤ アウトカムが的確である限りは、スタッフが選ぶ方法で問題を解決する自由を与えること ✤ 自己実現が運任せ、本人任せにならないように支援する 40
41. “転職 きる らいに人を訓練し、転職したいと思わないくらいに厚遇せよ。 ” – リチャー ・ ランソン ぐ ブ ド で 41
42. マネージャーとしてのスキル開発に投資する ✤ コーチング、ファシリテーション、目標設定、1on1、評価などエンジニアリング以外のスキルを継 続的に鍛える必要がある ✤ メンバーと会話できるくらいの技術力は維持する。話が通じないと信頼されない ✤ 「忙しいので学習の時間がない」ではまずい ✤ マネージャーがスキル開発していないのに、メンバーがスキル開発することを期待できるの か？ 42
43. 「どうやって部下をやる気にさせ、与えられた環境で成功させる か？独裁者になっても仕方がない。ああしろこうしろと指図する んじゃない。同じ部屋で一緒に過ごして、自分は大事にされてい ると、部下に実感させろ。耳を傾け、注意を払え。それが最高の マネジャーのすることだ」 『1兆ドルコーチ シリコンバレーのレジェンド ビル・キャンベルの成功の教え』エリック・シュミット、ジョナサン・ローゼンバーグ、アラン・イーグル著、ダイヤモンド社p.66 43
44. 本日のまとめ ✤ 「マネージャー」とつく職種は色々あるが、責任範囲は大きくことなる ✤ 組織によって「マネージャー」に対する期待値も違うので確認が必要 ✤ 自分自身を整理整頓する ✤ 限られたキャパシティをうまく使う ✤ 仕事を移譲し、すべてを自分でやろうとしない。過度に心配しすぎない ✤ 1on1、目標設定、評価、採用などチームのパフォーマンス向上につながることに時間をかける ✤ 「マネージャー」としてうまくやりたいならスキルを身につけなければいけない ✤ 「マネージャー」は選択肢の1つにすぎない 44
