目次
記事の概要
リーダーのたけむらです。
今回はエンジニアリングマネージャーのお仕事について語ります。
最近、少しばかりマネジメントに寄ったお仕事をすることがあって、そもそもマネジメントって何なのだろうかと気になってきました。
マネージャーの仕事といえば、他の部署との折衝や計数管理をしている堅苦しい仕事。
ぼんやりとしたイメージしかなく、しっかりとマネジメントについて学んだことがないな。
それに、マネジメント業務ができているのか、どうかどうやって判断したらいいのだろうか。
そんなことを考えている矢先に面白そうな書籍に出会って、3カ月ぐらいかけてじっくり読んでみました。
(実はCTOからの紹介書籍です)
意識していなかった概念や考え、心構えが分かる良書だと思いました。
私が拾い取ったことと、書籍の章立てをメインに書いていきますので、お付き合くださると幸いです。
この書籍を読めば何がわかるか
- エンジニアリングマネージャーは何をするべきかを理解することができる
- リーダーとマネージャーの違いを言葉で表すことができるようになる(たぶん)
- マネージャーのアウトプットを客観的に評価することができるようになる(かもしれない)
- 素敵なエンジニアリングマネージャーへの一歩を踏み出すことができる(そうだといいな)
書籍紹介
こちらの書籍です!
O’Reillyさんの本家サイトはコチラになります。
それでは早速はじめていきたいと思います。
マネージャーの役割の変化
前時代的なマネジメントは、従業員をいかに無駄なく働かせて、短い期間に安いコストでたくさんのものを作れるようにするかが役割でした。
マネージャーは多くの知識を持つ司令塔であり、従業員はマネージャーが考えた計画をひたすら動くコマのようなものでした。
(もともとの私が抱いていたイメージ)
世の中の変化がどんどんはやくなり、試行錯誤や探索が必要な状況下で、顧客が満足するプロダクトやサービスを素早く継続的に提供することが求められるようになった昨今では、そのようなやり方は機能しません。
複雑な状況においてはマネージャーを含めて誰も答えを持っていないからです。
したがってチームに目的を与え、チームが自律的に機能し、成長を続けながらチーム自身で答えを見つけられるようにしなければなりません。
現代のマネージャーの役割とは、まさに機能するチームをつくることに他ならないということに気づくことができました。
(この書籍を読んだあとのイメージ)
マネジメントをはじめて悩むこと
プログラマーの時は、チケットをやった、何をつくったと指を指すことができました。
マネジメントはそういった具体的なタスクがなくて、なんだか満足感を得ることが難しい状況が多いです。
その理由はいくつかあります。
- 主に他の人と働いているので、明確に自分でやったという感じがない
- 少数の本質的なものより、多数の小さなタスクに取り組んでいる
- 1日中コンテキストスイッチをしていて疲れる
- アウトプットを生まないミーティングや議論に使う時間のほうが多い
- 仕事の割り込みが増えて、なんだかんだ仕事が終わらない
意義があると感じられる方法でマネジメント業務のすべてを構成できないと、仕事をしているというより、自分の周りで仕事が発生しているような気がしてきて、何かできているのだろうか?という気持ちになっていきます。
まさに私がその典型で、この書籍を読んだ後はマネジメント業務のコレだなと考えられるようになりました。
そのマネジメント活動の分類を紹介します。
マネジメント活動の分類
- 情報収集
- 意思決定
- ナッジング
- ロールモデル
書籍ではこの4つのいずれかに分類できるとされています。
これらを意識することで、仕事には意味があるということに考えられるようになり、時間の過ごし方についてより良い選択肢が取れるようになった気がします。
活動分類の例を見ていく
活動内容の具体例については、ここで語れないほどのボリュームがありました。
何度も読み返す必要があると考えていますが、ここでは分類の概要をお伝えします。
情報収集
情報を把握して記録し、タスクを行動に移すシステムに必要なものです。
マネージャーの情報は、マネージャーとして成功するためにとても重要なものであると自覚する必要があります。
知識ベースは、チームや会社で何が起こっているかを理解するために使うものであり、基本的に自分の意思決定の土台です。
情報収集の活動は、この知識ベースの糧です。
注目すべきは、情報収集は正式なプロセスではないということです。いつでもどこでも起こり得ます。
例えば、知り合いのエンジニアと話をしていて、便利な実装があると知ったときに、意識的に自身のメモにしておいたとします。
数週間後に自分のチームで同じような要件が発生したら、既にその実装の内容が分かっているので、労力を大きく削減できます。
知識ベースに情報を追加し続けることが必要で、情報収集したいと思うことで他の人と話したり、つながりをつくったり、良いマネージャーになるモチベーションにもなるとのことです。
なんだかエンジニアならみんな情報収集しているじゃないか。と思ったりもするのですが、自覚の問題で見え方が違ってきそうですね。
意思決定
マネージャーの仕事として疑いようのない答えの1つです。(エスカレーションすることも多いのですが)
意思決定をするとき、決定権は誰もが持っている特権ではないということを自覚する必要があります。
例えば優秀な採用応募者が2名いたとき、どちらを雇うのだとか、チーム分けをどうするかだとか、見積もり依頼を受けて、内容が不明瞭なのでいったん断るのか、受けるのかとか。
その決定は、その瞬間は小さく見えるけれど、時間をかけてさまざまなアウトカムのコストにつながる事があるので、注意を払わないといけません。
また、決めたことに責任を持たないといけません。
各決定はターニングポイントです。
しかしながら、何でもかんでも責任を自分で抱えることは誤りで、説明責任を持ちながら、実行責任を段階的に委譲していくことも必要です。
そして、実行責任は委譲できるけれど、説明責任は委譲できないという理解が必要です。
ナッジング
ナッジングは、議論に対して自身の観点を提供し、決定に影響を与えることです。
例えばあるサービスを利用するかどうかの議論に関わっているときに、どう感じるかを明確にするような場合です。
意思決定を下す人でなくても、決定に影響を与えることがナッジングです。
これも情報収集と同じように、いつでもどこでも発生しますし、大小に関わらずどのような決定にもナッジングは発生します。
日々のインタラクションをナッジングのレンズを通して見ると、組織における影響力を広げる十分な機会があるんだなということがわかりました。
ただし、マネジメントをする立場になることで、発言には権威や威力が伴うものだと自覚する必要があります。
自由に意見するときに、このことを念頭に置くようになりました。
役職が上がるほど、特にこの傾向は強くなるようで、なるほどと思いました。
ナッジングの説明の締めくくりは次のような言葉が述べられていました。
CEOが不用意に発言したことによって、望んでもいなかったのに現実のプロダクトになってしまったことはありませんか?
恐ろしいです。
ロールモデル
最後にロールモデルです。
ロールモデルとはつまり、やってみて見せて、行動で示せ!ということです。
物事を実行して、言うべきことを言うことです。
こんな風に実行してほしいと思う基準を他の人に示すことが、変化を作る最善の方法だと自覚する必要があります。
チーム内でフルリモートを推進したいと思っているのに、自分は毎日出社しているとしたら、それはロールモデルではないということですね。
一日を例に取ると・・・
- 朝のミーティングでチケットの優先順位を決めて、チームメンバーが困っていることなどを聞いたり、解決策を提案することは情報収集とナッジングです。
- 素晴らしい機能を短時間で作成したメンバーのPRを賛辞するとします。これは他のメンバーにも率直なフィードバックをしてほしいと思ってのことだったとすると、それはロールモデルです。
- 次のスプリントプランニングで行う課題の優先度を決める行為は意思決定です。
こんな具合です。
マネージャーとしてのアウトプットの測り方
マネージャーの活動を分類により整理整頓すると、何に時間を費やすかを考えて、生産性を意識できます。
活動を表現できるようになり、計測ができます。
では、マネージャーの計測可能なアウトプットとは具体的に何か。
書籍でははっきりと明記されています(他のマネジメントの書籍でも同じなようなことが書かれています)
マネージャーのアウトプット = 自分のチームのアウトプット + 自分が影響を与えた他のチームのアウトプット
シンプルかつ強力ですね。(手厳しいなぁ・・・)
また次のようにも断言されています。
- あなたはチームのアウトプットに対して最終的な責任を持ちます。もしチームがうまく機能できないなら、改善するのはあなたの仕事です。
- チームのアウトプットはあなた個人のアウトプットより重要です。つまり、自分のタスクを実行するよりも、権限の委譲やコーチング、メンタリングに多くの時間を費やすべきです。
- あなたは、他のチームの人たちも影響を与えて仕事をします。つまり、ナッジングと、ロールモデルになることが重要です。組織の他の人たちを改善するのに役立ちます。
マネジメントできてるのかなと悩んだら、この言葉を振り返ると、自己評価できそうな気がしますね。
章立ての紹介
いままでに紹介した部分はほんの序章で、それらを実現するためのツールや方法を具体的に紹介されています。
詳しくは書籍に譲りますが、以下のような章立てでマネージャーとしてチームにどのような影響を与えるかを学ぶことができました。
章立て
本書への推薦の言葉 訳者まえがき はじめに 第I部 オリエンテーション 1章 新たな冒険 1.1 最初の週を始める 1.2 スナップショットを作成する 1.2.1 チームに自己紹介しよう 1.2.2 チーム全員と週次1on1を予約しよう 1.2.3 上司と初顔合わせミーティングをしよう 1.2.4 自分のスナップショットを作成しよう 1.3 アクションリストを作成する 1.4 いったん落ち着こう 2章 まず自分を管理しよう 2.1 整理整頓をしよう! 2.1.1 ツール 1:カレンダー 2.1.2 ツール 2:ToDo リスト 2.1.3 ツール 3:メール受信箱 2.1.4 ツール 4:情報を記録する場所 2.1.5 あなたのツールキット:まとめ 2.1.6 ツールキットを使った1日の例 2.2 活動を分類して生産性を高めるには 2.2.1 情報収集 2.2.2 意思決定 2.2.3 ナッジング 2.2.4 ロールモデル 2.2.5 あなたの活動を分類した1日の例 2.3 マネージャーとしてのアウトプットを測るには 2.4 準備完了! 第II部 個人と働く 3章 人間と関わる 3.1 上手なコミュニケーションをするには 3.1.1 コミュニケーションの3つの媒体 3.1.2 あなたに合わせるのではない 3.1.3 一貫性を保とう 3.1.4 フィードバックをするには 3.1.5 避けるべきコミュニケーションの特徴 3.1.6 コミュニケーションと共にあらんことを 3.2 委譲 3.2.1 悪い委譲:両極端 3.2.2 説明責任は委譲できない 3.2.3 委譲の物差し 3.2.4 委譲でやるべきこと、やってはいけないこと 3.2.5 実装方法はあなたに委譲する 3.3 上司との連携 3.3.1 動き出そう。待つのではなく 3.3.2 パフォーマンスについて話そう 3.3.3 マネージャーの世界の蓋を開ける 3.3.4 サマリーの力 3.4 進め! 4章 1on1 4.1 毎週、毎週 4.2 1on1 の準備をするには 4.3 コントラクティング:最初の 1on1 4.3.1 コントラクティングとは何か? 4.3.2 コントラクティング:まとめ 4.4 話す内容と進め方 4.4.1 あなたではなく、相手のためのミーティング 4.4.2 沈黙は金なり 4.4.3 状況報告:退屈なところ 4.4.4 会話の話題のアイデア 4.5 メモを取りアクションをアサインするには 4.6 セラピストでないことに留意する 4.7 次はどうする? 5章 その人に合った仕事とは 5.1 何が人を動かすのか? 5.1.1 欲求の階層 5.1.2 仕事の役割 5.1.3 自己実現への道 5.2 発達の最近接領域 5.2.1 タスクレベルで発達の最近接領域を適用する 5.2.2 キャリアレベルで発達の最近接領域を適用する 5.3 大聖堂とバザール 5.3.1 大聖堂を建設する人 5.3.2 バザールをぶらつく人 5.3.3 会話する 5.4 面談の前のレビュー 6章 1年でいちばん輝かしい季節 6.1 迷信退治 6.1.1 迷信その1:面談はマネージャーがトップダウンでフィードバックをするためのものである 6.1.2 迷信その2:面談は会社が行うものである 6.1.3 迷信その3:パフォーマンスの上がらないスタッフにしか面談は重要ではない 6.1.4 迷信その4:面談は人に嫌われているのでさっさと終わらせよう 6.1.5 迷信その5:面談は当日のサプライズであるべきだ 6.1.6 迷信その6:面談は昇給を言い渡すために使われる 6.1.7 迷信その7:面談はパフォーマンスについて話す唯一の場である 6.2 評価面談の準備をするには 6.2.1 ピアフィードバックを受け取る 6.2.2 面談フォーム 6.3 当日やること 6.4 お金の話をするには 6.5 さて次は? 7章 採用中! 7.1 採用する人を選ぶ 7.1.1 才能が多ければよいものでもない 7.1.2 カルチャーフィットについて 7.2 素晴らしい職務記述書を書く 7.2.1 職務記述書テンプレート 7.2.2 スタイル、トーン、ジェンダーニュートラル 7.3 面接プロセスを設定する 7.3.1 応募書類をレビューする 7.3.2 電話でのスクリーニングを実施する 7.3.3 1 次面接 7.3.4 技術課題(オプション) 7.3.5 最終面接 7.3.6 条件を提示する 7.4 採用の次は…… 8章 ゲームオーバー 8.1 人が去るのは普通のこと 8.2 スタッフが去るとき 8.2.1 良い退職理由 8.2.2 悪い退職理由 8.3 うまく戦う 8.4 スタッフを辞めさせる 8.4.1 PIP を準備する 8.4.2 PIP を作成する 8.4.3 PIP の受け渡しと実施 8.4.4 解雇 8.5 もう別れは十分! 9章 友人を作り、人に影響を与えるには 9.1 チームを超える 9.2 ネットワークを構築する 9.2.1 自己紹介をする 9.2.2 定期的に連絡する 9.3 お返しをする 9.3.1 メンタリング 9.3.2 コーチング 9.4 ワンランク上を目指す 第III部 全体像 10 章 人間って難しい 10.1 詮索と審判 10.1.1 上も下も 10.2 ぐらつき 10.2.1 傾聴と観察 10.2.2 消化 10.2.3 伝達 10.2.4 同僚のサポート 10.3 ムチとニンジン 10.3.1 ムチ 10.3.2 ニンジン 10.4 馬鹿の山 10.4.1 ダニング=クルーガー効果 10.4.2 インポスター症候群 10.4.3 ギャップを埋める 10.4.4 ダニング=クルーガー効果と折り合いをつける 10.4.5 インポスター症候群と折り合いをつける 10.5 人間だけの問題ではなくて…… 11章 プロジェクトって難しい 11.1 サウロンの目 11.1.1 警告のサイン 11.1.2 視線を浴びているとき 11.1.3 視線がそれたとき 11.2 あなた自身の成功の犠牲者 11.2.1 人ではなく生産性 11.2.2 それであなたができることは? 11.3 スコープ、リソース、時間 11.3.1 スコープ 11.3.2 リソース 11.3.3 時間 11.3.4 レバーの透明性を保つ 11.4 いったん落ち着こう 12章 情報の証券取引所 12.1 スパイとゲートキーパー 12.2 必要十分な情報を共有するには 12.2.1 悪い情報を届ける 12.2.2 より高い透明性へ 12.2.3 常に必要十分 12.3 社内政治 12.3.1 政治はどう起こるか? 12.3.2 政治をうまく使う 12.3.3 政治をネガティブに使う 12.4 いったん力を抜こう 13章 コントロールを手放す 13.1 タスクを超越する 13.1.1 ストア派とあなた 13.1.2 コントロールの三分法 13.2 偽りの生産性の罠から脱出する 13.2.1LモードとRモード 13.2.2Rモードを活かす 13.2.3 自分のキャパシティを賢く使う 13.2.4 通知をチェックするのをやめる 13.3 仕事以外でやることも重要 13.3.1 睡眠の重要性 13.3.2 体を動かす 13.3.3 重要なのは今だけ 13.4 本章も……手放す 14章 良いハウスキーピング 14.1 コミュニケーションがソフトウェアの設計を決める 14.2 ギルドでサイロを壊す 14.3 トークの文化を奨励する 14.3.1 チームでのライトニングトーク 14.3.2 部門トーク 14.4 問題を学習の機会に変える 14.4.1 5Why 14.4.2 マネジメントバグ 14.5 よくある問題を解決するツール 14.5.1 このコードはなぜこうなっているのか? 14.5.2 チームは時間とともに改善しているか? 14.5.3 誰に責任があるのか? 14.6 次はキャリアの整理の話 15章 デュアルラダー 15.1 インディビジュアルコントリビューター(IC)トラック 15.2 マネジメントトラック 15.3 キャリアアップフレームワークを作る 15.3.1 キャリアアップ表 15.4 キャリアアップに関するトラブルシューティング 15.4.1 マネージャーは両方のトラックにいるのでは? 15.4.2 マネジメントをやってみても好きじゃなかったらどうしよう? 15.4.3 キャリアアップフレームワークは主観的なものではないのか? 15.4.4 スキルセットの幅が大きい場合はどうしたらよいか? 15.4.5 キャリアトラックがどのように報酬を決定するのか? 15.4.6 うちの会社ではうまくいかない! 15.5 大きな問題に取りかかる時間 16章 現代の職場環境 16.1 ダイバーシティとインクルージョン 16.1.1 パイプライン 16.1.2 文化的な問題 16.1.3 あなたができること 16.2 リモートワークへの移行 16.2.1 見た目ほど簡単ではない 16.2.2 リモートワークをサポートする準備をする 16.3 ワーク・ライフ・バランス 16.3.1 チームを守ろう 16.3.2 すべきことをする 16.4 文化について 16.5 ユニコーンの国へ 17章 スタートアップ 17.1 ソフトウェアが世界を飲み込む 17.2 マネージャーの機会 17.2.1 マネージャー第1号になる 17.2.2 波を捕まえて乗る 17.3 マネジメントがスタートアップの将来を左右する理由 17.4 あなたの未来はどうなっている? 18章 クリスタルボール 18.1 生命、宇宙、万物のあいだにあるもの 18.2 自分のビジョン 18.2.1 自分はどうしてここにたどり着いたか? 18.2.2 次の10年は? 18.3 あなたの計画 18.3.1 プランステートメントを書く 18.3.2 コンピテンシーを評価する 18.3.3 スキルバックログを作る 18.4 エクササイズをスタッフとやってみる 18.4.1 ステップ 1:10 年ふりかえり 18.4.2 ステップ 2:10 年コーチングセッション 18.4.3 ステップ 3:スタッフのビジョンのレビュー 18.4.4 ステップ 4:インプット、レーティング、宿題 18.4.5 ステップ 5:1 年コーチングセッション 18.5 これでおしまい 参考文献 索引
出典はコチラ
章立てごとの簡単な説明
各章をざっくりまとめますと・・・
3章「人間と関わる」では、うまくコミュニケーションを取る手法、委譲のフレームワーク、委譲でやるべきこと、やってはいけないこと、また上長との関係性の結び方、信頼関係の作り方を高いレベルで学びます。
4章「1on1」では、1on1がマネージャーとして影響を与えるための最高の機会の1つであることを自覚し、1on1の準備方法や良好な関係性を結ぶためのエクセサイズ方法、タスクのアサインの仕方などについて学びます。
5章「その人に合った仕事とは」では、人間のモチベーションを探るモデルの概念をまず学びます。そして発達の最接近領域というフレームワーク、また発達の最接近領域の境界を広げる方法、スタッフ個人の特徴との向き合い方について学びます。
6章「1年でいちばん輝かしい季節」、7章「採用中!」では、評価面談にまつわる誤解や迷信に触れ、間違いの理由を理解し、採用フェーズでの人の決め方、面接の進め方について学びます。
8章「ゲームオーバー」では、生々しいですが解雇の方法(さすがアメリカの書籍)を具体的に書かれており、またスタッフが去らないようにフォローアップの仕方や、祝福して送り出すべき場合の理由にも触れます。
9章「友人を作り、人に影響を与えるには」では、メンタリングとコーチングを通して他の人たちにお礼をする意味、チームを超えた世界を考慮する重要性にも触れ、マネージャーとしての次のキャリアに目を向けた意識を芽生えさせます。
10章「人間って難しい」では、これまで説明された概念を一変し、人間がいかに脆いか、その脆さがチームへぐらつきを起こすこと、他の部署からの詮索と審判への対応を学びます(生々しい!)。
またダニング=クルーガー効果やインポスター症候群などへの対処法を学びます。
チームメンバーの謙遜の度合いが高すぎる場合に自信を取り戻すお手伝いができたらいいなと思いました。
11章「プロジェクトって難しい」12章「情報の証券取引所」ではプロジェクトのスコープ、リソース、時間のレバー(優先度の付け方)の操作の仕方についてや、コンセンサスの取り方や社内政治について学びます。
11章、12章については他のプロジェクト管理手法の書籍の方が重みがあるかもしれませんが、人間関係の混濁について重きを置いているところが、この書籍の特徴かと思います。
13章「コントロールを手放す」では委譲の具体的な方法を20ページに渡り解説されています。
13章までは自身の意識改革に注力されており、13章以降は具体的な解説や紹介が入ります。
14章「良いハウスキーピング」、15章「デュアルラダー」(管理職と専門職を分別しているキャリアパスのこと)、16章「現代の職場環境」において、開発環境や開発手法の向上方法、人事評価制度の制定のしかた、現代の職場環境、特にフルリモートワークに適応するためのマネジメント方法の変化やフォローアップの仕方について具体的に事例を見ていくことになります。
フルリモートにおけるコミュニケーションツール採用の重要性や、フルリモートとはいっても定期的な顔合わせや飲み会が必要な理由を理解していきます。
当社もフルリモートを行っていますが、事例紹介にあるようなアクションを実行していて、さすがだなぁと思いました。
17章「スタートアップ」、最終章「クリスタルボール」において、草の根を分けてエンジニアリング担当VPになる方法と、今後のキャリアの立て方を学びます。
最終章は特にアメリカの文化に適合した内容となっているので、日本の職場環境とは少し異なると思います。
この書籍が最も伝えたいことは何なのか
全て大切なことだと感じましたし、違う日に思い返せば、また異なる感じ方をするのかもしれませんが、今印象に残っているのは次の3つの事です。
コミュニケーション
マネージャーの仕事は、コミュニケーションが非常に大事である。
複雑な現代社会において、チームが直面する課題や混濁に対し、自分自信を含むチームメンバーが心のコントロールを手に入れる。そうすれば安心して組織とともに成長できる。
そのコントロールを得るさまざまな思考や手法があり、それらを学ぶ必要があるということだと思います。
プログラマとマネージャーは別のトラックだということ
プログラマとマネージャーのトラックは全く異なるということ。
それを自覚しないと、マネジメントの責任を担いながら、エンジニアとして以前と同等のコード量を生み出すという非現実的な期待を自身に背負わせてしまいます。
マネジメントトラックとIC(インディビジュアルコントリビューター)トラックを明確に区別し、キャリアパスを設定しないと、優秀な人材が去ってしまうという。
人ではなく生産性にフォーカスすること
スピードに対する文句が人に対する攻撃にならないようにしなければならない。
組織が大きくなるに連れて仕事は必ず遅くなっていく。
これは数人の個人が部署や会社全体を遅くしているわけではなく、成長の自然な副作用である。
この副作用を対外的に説明できるように次のような思考ツールを意識する。
例えば・・・
- 普段の仕事が大変になる
SLAの向上、ストレージの拡張、監視やアラートの設定などなどが増えていく - レガシーコードを扱う機会がさらに増える
増え続けるコードベースによって、新しい機能を作る上で考慮するべきことが増える - コミュニケーションとプロセスのオーバーヘッドが増え続ける
コミュニケーションチャネルの指数関数的増加
さいごに
エンジニアリングマネージャーのしごとが簡潔にまとまった書籍でしたが、これまで視野になかった概念も多く、読み切るまでかなり時間がかかりました。
当社のマネージャーはこれらのことを考えながら仕事しているのだなと改めて認識することもできましたし、この書籍で紹介されるようなフレームワークを組織に持ち込み、実施しているという背景も理解することができました。
また、当社および当社開発Sec.では社員の成長を促せるよう取り組んでいっているので、このブログをみて興味をお持ちになったらぜひ当社の扉を叩いてみてください。
一緒に働けるのを楽しみにしています。(最後に宣伝活動😀)