「エンジニアのためのマネジメント入門」を読んだ #

2023-03-14

マネジメントについても勉強しなくてはと思いがあり、読むことにした。
気になった点のメモを残しておく。

目次

経営学者ファヨールの管理的活動の定義 #

まずは管理的活動の定義が紹介されていた。

• 計画: 将来を予測して、企業の戦略を実現するための活動計画や目標を作成する
• 組織: 権限と責任の種類を割り付けて、組織体を設計する
• 命令: 計画を実行させるために指示をする。これは強制されるべきものではない
• 調整: 各チームのアウトプットやコミュニケーションを結合して調和させる
• 統制: すべての活動が計画どおりに遂行できるか監視して、状況に合わせて修正をする

合わせて「管理原則」を提唱しており、マネジメントに関わりの強いものは以下

• 分業: 組織は大きくなればなるほど、分業が必要とされる。それにより職能が専門化して、権限が分化される
• 権限と責任: 命令する権限を有し、それに伴う責任を負う
• 命令の一元性: 指揮命令系統を一元化し、構成員は一人の管理者から命令をうけとる
• 指揮の一元性: 目標達成のための責任者は一人、計画は一人である
• 階層組織: 指揮命令を確実にするため、責任者を階層にする

ドラッカー曰く、マネジメントとは組織に成果を上げさせるための機能としており、リーダーとマネージャーの違いは以下としていた。

• リーダー: 組織を指揮して導くもの
• マネージャー: 組織をマネジメントするもの
  • 組織の成果に責任を持つもの
    • つまりエンジニアリングマネージャーは「エンジニアリング組織の成果に責任を持つもの」
    • エンジニアリングとは「不確実なものを効率よく削減していく」
      • つまり単にエンジニアをマネジメントするのではなく上記をコントロールしていくこと

マネジメントドメイン #

マネジメントドメインには以下のような種類がある。

• プロダクト
• プロジェクト
• チーム
• テクノロジー
• ピープル
• ストラテジック
• ビジネスパフォーマンス
• ライン

特にエンジニアリングマネージは以下の 4 つで活動するケースが多いとのこと。

• ピープルマネジメント
  • 採用や育成、コミュニケーションなど -プロジェクトマネジメント
  • 品質、コスト、スケジュールなど
• プロダクトマネジメント
  • プロダクトのライフサイクルに渡るすべて
• テクノロジーマネジメント
  • 技術医師決定、選定、戦略など

コミュニケーション #

コミュニケーションについてはティーチングやメンタリングなどの目的や技法が紹介されており学びがあった。

• ティーチング
  • ゴールは「教えることを必要としなくなる」こと
  • ADDIEモデル
• コーチング
  • GROWモデル - 目標、現状認識、発見、アクションを決める 　- ジョハリの窓 - 秘密、盲点、開放、未知 　- チャンキング 　- フィードバック - SBI法 - シチュエーション、行動、影響
• メンタリング
• メンターが不要になることがゴール
• ラポール形成からはじめる
  • 承認
  • アクティブリスニング・傾聴技法
• マネージャーも社外を含め自分のメンターを見つける必要がある

1on1 #

有意義な1on1って難しいと思っており step などが記載されており参考になった。

• 成長支援
• コミュニケーションを円滑にする
• 相互理解
• 情報交換
• ラポール形成

1on1の step #

• テーマを決める
  • 「今日は何について話しますか？」という導入
  • テーマがクライントからでない場合は「直近のしごとを振り返る」などのテーマをマネージャから出すのは問題ない
• 話を聴く
  • まずは聴き、傾聴・承認し本質を探る
  • 議事録を取る
• 行動を促す
  • 「いつまでに何を行うか」
• 励ましとサポート
  • 他に議題がないか確認
  • サポートできることがないか確認

会議 #

業務時間の25%以上を会議に費やしているならそれは組織構造の欠陥を疑う
マネージャーは適切な会議を開催しないといけない
会議の壊し方という話もされており、遭遇したことあるものも多く、意識しようと思った

• 定例会議症候群
• 会議の壊し方
  • 闇鍋会議
  • 時間意識の欠如
  • 大名行列会議
  • 忘却の会議
  • 議論の空中戦
  • 発言の否定
  • 結論の先送り

ファシリテーション #

OARRを事前に定義しておく

• Outcome: 成果イメージ
• Agenda: 予定・議題・スケジュール
• Role: 参加者の役割
• Rule: 役割、心得

質の高い会議にするテクニック #

• テーマにフォーカスさせる
• 意見を明文化する
• パーキングエリアをつくる
  • ホワイトボードの端に「テーマから外れた意見を記載する場所」を用意し発散を防ぐ
• 誰がいつまでに何をするか

この会議はどのように決定するのかを事前に決める

チームエンジニアリング #

指示待ちチームができてしまう場合はマイクロマネジメントが行われていないか疑う
しかし、マイクロマネジメントはだれも気づかないうちにはじまっている

チームのフェーズとリーダーシップスタイル #

各フェーズにおいて効果的なリーダーシップスタイルは異なるという話。

• 混乱期には強圧型、先導型、民主主義型、コーチ型
• 統一期にはコーチ型、権威主義型
• 機能期には民主主義型

良いチーム #

良いチームとはなんぞや。という話から。

• 心理的安全性
• 相互信頼
• 構造と明確さ
• 仕事の意味
• インパクト

優れたマネージャーの要件を特定する の優れたマネージャーの 10 の行動要件が引用されていた。

• 良いコーチである
• チームに任せ、細かく管理しない
• チームの仕事面の成果だけでなく、健康を含めた充足に配慮し、インクルーシプな環境を作る
• 生産性が高く結果を重視する
• 効果的なコミュニケーションをする - 人の話をよく聞き、情報を共有する
• キャリア開発についてサポートし、パフォーマンスについて話し合う
• 明確なビジョンや戦略を持ち、チームと共有する
• チームにアドバイスできる専門知識がある
• 部門の枠を越えてコラボレーションを行う
• 決断力がある

目標については「目標はないほうがよい」という見解（ピープルウェア第 3 版の p31）もあり、組織によっては目標は不要かもしれないという話が紹介されていた。この点はとても気になったのでピープルウェアを読んでみたが以下のような話が記載されていた。

ニューサウスウェールズ大学の優れた研究者であるマイケル・ローレンスとロス・ジェフリーの二人は、80 年代と 90 年代にプロジェクトについての年次調査研究を行っていた。...省略...目標値設定のやり方によって生産性がどのように影響を受けるかを調査した。開発者（ここでは、プログラマー）は、自分で立てた目標値を達成するために懸命に努力する、という伝説的な仮説が正しいか検証しようとした。103 のプロジェクトに対し重みつきの指標で生産性を計測した。

誤った目標値の設定、つまり、絶望的に厳しい見積もりは、プログラマーのやる気を吸い取ってしまうなケイパー・ジョーンズは、次のように述べている。「プロジェクトのスケジュールが、完全に不合理かつ非現実的であり、どれだけ残業しても完成しそうにない場合、プロジェクトチームのメンバーの不満がつのり、やがて怒り出し、……そして士気は地に墜ちる」。不合理かつ非現実的なスケジュールを立てるのが、上司か開発者自身かは大した問題ではない。成功する見込みが全くない状況に置かれると、効率の良い仕事をしなくなる。

1985 年のジェフリーとローレンスの研究の中で、最も驚くべきものは、最後に載せた研究である。これは 24 のプロジェクトについて、全く目標値を設定しない場合の生産性を調査したものであった。このプロジェクトは、他のどのプロジェクトよりもはるかに優れた結果を示した。

上司が、日程的なプレッシャーを少しもかけなかったプロジェクト（「仕事が終わったらおれを起こしてくれ」というたぐい）は、最高の生産性を示した... ピープルウェア第 3 版より

組織のマネジメント #

組織についてはヒエラルキーについての説明がなされていた

• 組織の例外処理のための仕組みがヒエラルキー
• コミュニケーションの最適化と経路の固定化を減らすためのツールになる
• しかし、巨大になると意思決定の遅れなどを招く
• のでヒエラルキーは作りつつも例外処理の scope を広げ可能な限りフラットにする

ケイパビリティとメトリクス #

DORAチームの研究結果を引用し 24 個のケイパビリティとソフトウェアデリバリのパフォーマンス指標Four Keysについて紹介されていた。このあたりは以下も読むと良さそう。

• DevOps の能力
• エリート DevOps チームであることを Four Keys プロジェクトで確認する

エンジニアリングチームのデザイン #

以下の形態が紹介されていた。要は縦割り横割り、みたいな話っぽい。

• コンポーネントチーム
• フィーチャーチーム

逆コンウェイ作戦 #

ここでも以下のように逆コンウェイ作戦の話が記載されていた。

戦略にとって最適なシステムアーキテクチャが実現できるとともに、システムアーキテクチャに最適なチームが組成できる

ただ、最近読んだ本当は怖い、逆コンウェイ戦略に近い感想を自分も持っており、どうなんだろうという感じ。

技術とセルフマネジメント #

技術戦略において重要なのは「コア技術」、コア技術とは他社が模倣できない難しく複雑なもので、プロダクトの中核を担う競争優位性のある技術。

テクノロジーロードマップ #

マーケット、プロダクトとの連携を時間軸上に表示。
このロードマップはトップダウンだと現場を無視した非現実的なものになり、ボトムアップだと大胆な施策がでないかもしれない。
両面から詰める必要がある。

ロードマップそのものよりマーケット・プロダクトなどの組織と共同し、トップ、ボトムを行き来して作成するプロセスに意味がある。

###　セルフマネジメント

時間管理のマトリクス #

課題の委任 #

委任スタイル (p198 より)が表にまとまっていた。
上手な委任ができないとマネージャーは詰むと感じている。

ソフトウェアを実務者に含んで考える委任スタイル (p198 より)

まとめ #

幅広く書かれており、とっかかりによいと感じた。
各部の詳細は引用の書籍や資料に目を通したり、以前読んだ「エンジニアマネージャーのしごと」や「チームトポロジー」「リーダーの作法」なども読み返してみると良さそうと感じた。

以上。