0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

「エンジニアリングマネージャーの仕事」を読んで その5

Posted at

はじめに

James Stanier著「エンジニアリングマネージャーの仕事」を読んで私が印象に残ったことをメモがわりに、少しずつアウトプットします。
今回で(強引に)ラスト!
予想以上に残ボリュームが大きいため、あと2回に分けます。。。

3章 人間と関わる

3.1 上手なコミュニケーションをするには

  • コミュニケーションの媒体
    • 会話
    • テキスト
    • 非言語(ジェスチャー・ボディランゲージ・表情・姿勢・声のトーンなど)
  • 目的に応じた適切な媒体を選ぼう
    • 必要な行動を引き起こせるか?
  • フラストレーションを次のコミュニケーションに持ち越さない
  • 情報を発信する前に2回考える
    • コミュニケーションしたいときにするのではなく、必要なときにする ★
  • 会話は双方向で
  • 適切性は効率性に勝る。相手を尊重して判断
  • マネージャーの言葉は、個人の言葉ではなく組織図の上のポジションからの言葉として受け止められることを忘れずに
  • 「言いにくいことをはっきりと言う」横軸と「心から相手を気にかける」縦軸の4象限
    • 大:大 徹底的な本音 👈ここを目指す
    • 大:小 イヤミな攻撃
    • 小:大 過剰な配慮
    • 小:小 摩擦の回避
  • 避けるべきコミュニケーショの特徴
    • オーバーコミュニケーション
    • はぐらかし
    • ウケ狙い
    • 一貫性のなさ
    • 感情にとらわれる

3.2 委譲

  • 悪い委譲
    • まったく委譲できてない
    • 丸投げ
  • 説明責任は委譲できない ★
  • 良い委譲は、タスクの実行責任を誰かに渡す一方で、説明責任を負い続けること
  • 委譲でやるべきこと
    • スタッフにとってチャレンジになるくらい委譲すること ★
    • 重要性に応じて適切なコントロールを保持
  • 委譲でやってはいけないこと
    • 丸投げ
    • 他の人のやり方が自分と同じであることを期待すること ★
    • 渡したタスクを取り返すこと ★

3.3 上司との連携

  • 能動的に動こう
  • パフォーマンスについて語ろう
    • 上司からみたパフォーマンスはなにか?
  • 報告のためにサマリーを書く習慣

4章 1on1

  • 毎週やろう
  • 同じ時間、同じ場所が理想、プライベートエリアで
  • アジェンダと記録を共有しよう
  • コントラクティング:お互いが相手に期待することを出し合う
  • 答えを出すのは時間が必要なもの。安易に提案しない。★
  • 相手のためのミーティング、70%の時間は部下に話してもらう★
  • 相手の頭の上に思考の吹き出しを浮かべておく
  • 状況報告は必要最低限
  • マネージャーはセラピストではない。センシティブな領域は適切な第三者へ

5章 その人に合った仕事とは

  • それぞれが楽しめる方法で、それぞれに合った逆境にさらされるように
  • 仕事に合った人を獲得するのではなく、人に合った仕事を獲得する
  • マズローの五段階欲求
  • 「アウトカムが明確である限りは」スタッフが選ぶ方法で問題に解決する自由を与える
  • 「発達の最近接領域」学習者が支援ありでできるタスク
  • 子供は自主的に学習する時がいちばん効果が高い
  • 発達の最近接領域のタスクをスタッフに与える
  • OSSの大聖堂モデル/バザールモデル
  • 管理と安定によってモチベーションが高まる人もいれば、カオスや変化によってモチベーションが高まる人もいる ★
  • 大聖堂を建設する人、バザールをぶらつく人 ★

6章 1年でいちばん輝かしい季節

  • 評価面談は双方向のプロセスであるべき、マネージャーはファシリテーター
  • 面談でいちばん大きな恩恵を受けるのはハイパフォーマー
  • 面談内容はサプライズであるべきでない。適切な情報は開示され、咀嚼され、理解されていること
  • ピアフィードバックを3〜5名から収集する ★
  • 悪い知らせを受け取った人は無視する→否定する→他人のせいにする→責任を引き受ける→解決策を見つけるという5つのステップを踏む
  • よって事前展開し、面談時には「解決策を見つける」に注力できるようにする
  • パフォーマンスのフィードバックと、お金(昇給)のフィードバックは分けるべき

7章 採用中!

  • チーム全体のアウトプットを向上させるための選定
  • 採用はプロジェクトマネジメントの鉄の三角形と似ている(品質・納期・コストの3つを同時には満たせない)
  • カルチャーフィットは概念として不可能、そこで働く人が生み出し変えていくもの
  • 自分と似た人を探そうとしてはいけない
  • 求める役割については具体性をもたせる。エンジニアの仕事は抽象化するとほとんどの会社で同じになっちゃうので
  • 要求スキルの長いリストを使わない。研究によると男性は60%満たせば応募したのに対し、女性は全て満たさないと応募しないという行動が報告されている
  • 面接では全員が良い経験をすべき。面接したすべての人が、ここは働く場所として素晴らしいという印象をもって面接をあとにするのが理想
  • ホワイトボードを使ったシステム設計の技術課題

8章 ゲームオーバー

  • 人は必ず去るもの
  • 良い退職・悪い退職
  • ローパフォーマーへの最終手段、業務改善計画(PIP)

9章 友人を作り、人に影響を与えるには

  • メンタリングやコーチングで「お返し」
  • メンターシップマトリックス
    • 名前・役職・チーム・連絡先・求めるスキル・提供できるスキル
    • スキルマップより有効かも
  • コーチングとは同僚とインタラクションするフレームワーク

10章 人間って難しい

  • 思いやりと理解→気遣いと心配→恨み→反抗
  • 傾聴と観察→消化→伝達
  • 自律性・熟達・目的の重なるところがニンジン(動機づけ)となる
  • ダニング=クルーガー効果とインポスター症候群

11章 プロジェクトって難しい

  • プロジェクトの正念場では
    • チームの足並みをそろえる
    • 過剰なまでのコミュニケーション
    • 反応やフィードバックを求める
    • 頻繁にリリースする
    • 現実的でいる
    • 正面からリードする
  • 正念場を脱したら
    • お祝いする
    • 技術的負債をきれいに片付ける
    • 自分用のプロジェクトの時間を取る
    • ふりかえる
    • 計画を立てて、気持ちを切り替える
  • 自身の成功の犠牲者
    • 成功しているからこそ・・・複雑性が増し遅くなる
    • 人ではなく生産性にフォーカスをあてる
    • 会社が大きくなるにつれて一人当たりの生産性が下がる事実は、スタートアップの繁栄が証明している
    • 開発チームがスピードについて直接文句を言われないように
      • 隠れた複雑性を明らかにする
      • 常に進捗を示す
      • ソフトウェアを実用主義で開発する
    • プロジェクトの適切な妥協点をみつけるための3つのレバー「スコープ」「リソース」「時間」
0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?