Upgrade to Pro — share decks privately, control downloads, hide ads and more …

エレガントパズル エンジニアのマネジメントという難問にあなたはどう立ち向かうのか / Elegant Puzzle

エレガントパズル エンジニアのマネジメントという難問にあなたはどう立ち向かうのか / Elegant Puzzle

iwashi

June 05, 2024
Tweet

More Decks by iwashi

Other Decks in Technology

Transcript

  1. 4 どんな本? • EM や VPoE 観点からの実践知が多く掲載される ◦ 研究による裏付けがメインという類の書籍ではない •

    チーム編成から組織文化、採用から業績評価まで 組織運営に必要なトピックが言及されている
  2. 5 実践 学術/ 研究 主観に基づく雑マッピング 注:もっとたくさん挙げたい書籍がありますが、自分の本棚 + kindle からぱっと目についたものを挙げてます 論文(のメタアナリシス)

    などから導出された知見に 基づく書籍。 様々な組織で使える 可能性がある。 ある特定の企業でうまくいった 経験に基づく書籍。 n=1 に近いため文脈が 近ければかなりハマるかも。
  3. 6 実践 学術/ 研究 ハード(組織設計・戦略など) ソフト(人・文化など) 主観に基づく雑マッピング 注:もっとたくさん挙げたい書籍がありますが、自分の本棚 + kindle

    からぱっと目についたものを挙げてます 組織設計・戦略・システムなど トップが判断すれば方針が さっと変わるトピック中心 人の関係性や組織文化など、 「やるぞー」といっても すぐに変わらないトピック中心
  4. 8 実践 学術/ 研究 ハード(組織設計・戦略など) ソフト(人・文化など) 主観に基づく雑マッピング 注:もっとたくさん挙げたい書籍がありますが、自分の本棚 + kindle

    からぱっと目についたものを挙げてます マネジメントに絶対的な正解は無いので 様々なアイデアを把握した上で 自分の文脈にカスタマイズして 適用していくのがオススメ
  5. 9 • 岩瀬 義昌 (@iwashi86) / Yoshimasa Iwase • 本業

    ◦ 通信会社で Generative AI Project の リーダー(EMとPdM) • サイドワーク ◦ ストックマーク社で Co-VPoE ◦ 早稲田大学で非常勤講師(プログラミング) ◦ Podcaster (fukabori.fm) ◦ 翻訳者
  6. 14 書籍の全体像 第1章 導入:重要なパズルを解くために 第2章 組織:機能する組織を作り、維持する 第3章 ツール:変化をマネジメントする手法 第4章 アプローチ:問題解決につなげる 第5章 文化:継続的に取り組んで育成する 第6章 キャリア:同僚と自分に対して責任を持つ 第7章 さらに先へ •

    システム思考(開発プロセスを事例に) • プロダクトマネジメント • 戦略とビジョンの使い分け • メトリクスの効果的な活用方法 • マイグレーション(技術的負債の唯一のスケーラブルな解決策) • 学習コミュニティ 3章は他にも色々
  7. 16 書籍の全体像 第1章 導入:重要なパズルを解くために 第2章 組織:機能する組織を作り、維持する 第3章 ツール:変化をマネジメントする手法 第4章 アプローチ:問題解決につなげる 第5章 文化:継続的に取り組んで育成する 第6章 キャリア:同僚と自分に対して責任を持つ 第7章 さらに先へ •

    機会(専門での成功とキャリア開発に臨めること)と メンバーシップ(ありのままで参加できること) • 機会を公平に作り出す方法 • メンバーシップを高める方法 • ポジティブな自由とネガティブな自由 • ヒーローへの対応
  8. 22 システム思考 • 詳細は 『世界はシステムで動く  ― いま起きていることの本質をつかむ考え方』(英治出版) • エレガントパズルでは一部が紹介されている ◦

    書籍では 『Lean とDevOps の科学[Accelerate]  テクノロジーの戦略的活用が組織変革を加速する』(インプレス) で挙がるメトリクスを参照しつつ説明
  9. 26 プルリクエスト (デプロイの) 準備完了 コミット デプロイ済み コミット インシデント 単位時間あたりの コードレビュー数

    単位時間あたりの デプロイ数 単位時間あたりの 欠陥数 単位時間あたりの 復旧数 開発での例
  10. 27 プルリクエスト (デプロイの) 準備完了 コミット デプロイ済み コミット インシデント リバート コミット

    単位時間あたりの コードレビュー数 単位時間あたりの デプロイ数 単位時間あたりの 欠陥数 単位時間あたりの 復旧数 単位時間あたりの デバッグ数 開発での例
  11. 28 プルリクエスト (デプロイの) 準備完了 コミット デプロイ済み コミット インシデント リバート コミット

    単位時間あたりの コードレビュー数 単位時間あたりの デプロイ数 単位時間あたりの 欠陥数 単位時間あたりの 復旧数 単位時間あたりの デバッグ数 数値を見ることによる活用① 準備完了コミットの ストック(数値)が ほぼゼロであれば
  12. 29 プルリクエスト (デプロイの) 準備完了 コミット デプロイ済み コミット インシデント リバート コミット

    単位時間あたりの コードレビュー数 単位時間あたりの デプロイ数 単位時間あたりの 欠陥数 単位時間あたりの 復旧数 単位時間あたりの デバッグ数 数値を見ることによる活用① 単位時間のデプロイ数を 増やしても効果が薄い 準備完了コミットの ストック(数値)が ほぼゼロであれば
  13. 30 プルリクエスト (デプロイの) 準備完了 コミット デプロイ済み コミット インシデント リバート コミット

    単位時間あたりの コードレビュー数 単位時間あたりの デプロイ数 単位時間あたりの 欠陥数 単位時間あたりの 復旧数 単位時間あたりの デバッグ数 数値を見ることによる活用② 「単位時間あたりの欠陥数」が小さくて インシデントがほぼなければ
  14. 31 プルリクエスト (デプロイの) 準備完了 コミット デプロイ済み コミット インシデント リバート コミット

    単位時間あたりの コードレビュー数 単位時間あたりの デプロイ数 単位時間あたりの 欠陥数 単位時間あたりの 復旧数 単位時間あたりの デバッグ数 数値を見ることによる活用② 「単位時間あたりの欠陥数」が小さくて インシデントがほぼなければ 「単位時間あたりの復旧数」を いくら増やしても効果は薄い
  15. 36 組織デザイン • なぜ組織が必要なのか? → 個人では限界があるため • 例:パンの大規模販売 ◦ 仕入れ:小麦などの原材料を仕入れる(もしくは育てる)

    ◦ 調理:生地を作って焼く ◦ 販売:お店でお客様に売る (1人でもできなくはないが、スケールしない)
  16. 39

  17. 45 例外の受け皿になるのがマネージャー 現場 マネージャー ディレクター 社長 … 注:組織によって階層数は異なる。初期スタートアップなら1-2階層。 try: 現場のmember.プロジェクトを実行する()

    except Exception as e: # 例外の原因を調査し、対応策を決定 if (自分の裁量で判断・実行可能) { EM.原因を特定する(e) EM.対応策を実行する() }
  18. 46 例外の受け皿になるのがマネージャー 現場 マネージャー ディレクター 社長 … 注:組織によって階層数は異なる。初期スタートアップなら1-2階層。 try: 現場のmember.プロジェクトを実行する()

    except Exception as e: # 例外の原因を調査し、対応策を決定 if (自分の裁量で判断・実行可能) { EM.原因を特定する(e) EM.対応策を実行する() } else { # 上位に投げる # 解決できるまで上位にエスカレされる }
  19. 50 組織における例外(Exception)による弊害 • 例外の数が極端に増えるとどうなるか? → マネージャーが例外処理に忙殺されて、   全体として非効率になる  加えて  →

    例外を頻繁に受け入れている組織は、    バイアスに強い影響を受けるようになり「一貫性」が損なわれる • 一方で「変化しない」組織は衰退していく → どのように変化と一貫性のバランスを取るか?
  20. 62 インクルージョン • 書籍ではインクルージョンの2側面について語られている ◦ 機会(Oppotunity)へアクセスできること ▪ (本資料では紹介しない、書籍参照) ◦ メンバーシップ(こっちを紹介)

    ▪ 会社のグループの一員として感じられること • なお先に、アンチパターン ◦ 上記(特に機会)が限られた人に提供されている状態 ◦ 退職の要因になる
  21. 65 メンバーシップを高めるために良かったこと • 業務時間中に開催される週次の定例イベント ◦ 任意で誰でも参加できる ◦ 論文読み会や読書会が該当 • ERGs

    (Employee Resource Groups) ◦ 共通の属性・背景を持つメンバが集まる機会 • チームでのオフサイト ◦ 4半期に1回立ち止まってふりかえる ◦ 1日集まるだけで驚くほど、個人がチームとして働けるように感じられるように ▪ 特にマネージャーの集まりで効果的
  22. 66 メンバーシップを高めるために良かったこと • 業務時間中に開催される週次の定例イベント ◦ 任意で誰でも参加できる ◦ 論文読み会や読書会が該当 • ERGs

    (Employee Resource Groups) ◦ 共通の属性・背景を持つメンバが集まる機会 • チームでのオフサイト ◦ 4半期に1回立ち止まってふりかえる ◦ 1日集まるだけで驚くほど、個人がチームとして働けるように感じられるように ▪ 特にマネージャーの集まりで効果的 • コーヒーチャット ◦ 異なるチームからランダムで呼ばれて話す会
  23. 67 メンバーシップを高めるために良かったこと • 業務時間中に開催される週次の定例イベント ◦ 任意で誰でも参加できる ◦ 論文読み会や読書会が該当 • ERGs

    (Employee Resource Groups) ◦ 共通の属性・背景を持つメンバが集まる機会 • チームでのオフサイト ◦ 4半期に1回立ち止まってふりかえる ◦ 1日集まるだけで驚くほど、個人がチームとして働けるように感じられるように ▪ 特にマネージャーの集まりで効果的 • コーヒーチャット ◦ 異なるチームからランダムで呼ばれて話す会 • チームでのランチ ◦ 週1回などでランチする会 (儀式的で嫌な人もいる)
  24. 70 メンバーシップにおける注意点 • 前述の活動はシンプルだが そのシンプルさゆえに、考慮すべき事項が埋もれることがある • またどの活動も全員に有効なわけではない ◦ ランチ会といっても複雑な食事制限があるメンバーがいたら? ◦

    運動がある活動だったとして、運動が苦手なメンバーがいたら? ◦ 終業後だとして、子供がいる親だったら? • さまざまな組み合わせで考えること および同僚とアイデアを(小さく)検証するのが大事
  25. 76 Community of Learning - 上手くいかなかったこと • いわゆるEMコミュニティでの勉強会 • 上手くいかなかったこと

    ◦ 重要な教訓などをびっしり書いた内容の濃いプレゼン (今もやってる!けど、ぜひ自分の場を作りましょう) ◦ 結果的に出席率も下がり、学習効果も低かった
  26. 78 Community of Learning - 上手くいったこと • 上手く行ったアプローチ ◦ 主催者は講師ではなく、互いの学びをファシリテートする

    ◦ 進め方 ▪ チェックインで20-30秒で名前・所属・考えていることを共有 ▪ プレゼンは短く5分程度、残りはブレイクアウトして ディスカッションする時間に • 盛り上がらないこともあるので、10分程度が良い ▪ ブレイクアウトして戻ったら、学びを相互共有する
  27. 83 コールドソーシング • 採用経路は主に3種類 ◦ インバウンド(自然流入) ◦ リファーラル ◦ ソーシング(アウトバウンド)

    • このうちソーシング、特に「コールドソーシング」は マネージャー自ら、見ず知らずの人に声をかけること ◦ これは心理的ハードルがかなり高い(著者も気まずかったと言っている)
  28. 84 コールドソーシング • 採用経路は主に3種類 ◦ インバウンド(自然流入) ◦ リファーラル ◦ ソーシング(アウトバウンド)

    • このうちソーシング、特に「コールドソーシング」は マネージャー自ら、見ず知らずの人に声をかけること ◦ これは心理的ハードルがかなり高い(著者も気まずかったと言っている) → であれば、どうすればできるのか?
  29. 87 具体的な方法 • Linkedin に参加 + 知り合いをフォローしてネットワークを築く ◦ ここが増えれば増えるほど、スパマーとして判定されにくくなる •

    やりすぎると、制限がかかることもある ◦ その場合は辛抱強く待つ or 有料プランを使う • 二次的な関係を持つ人を探してつながりをリクエストする ◦ 文面は非常にシンプルで良い ◦ 具体例は書籍参照だが、本当に簡素: ▪ あいさつ + なぜお声がけしたか + お話できませんか? 程度 補足:日本だと文脈がちょっと違う
  30. 92 今日お話したこと • 書籍の位置付け • 書籍の全体像 • 個別トピック ◦ システム思考

    ◦ 組織デザインと例外対応 ◦ インクルーシブな組織 ◦ 学習コミュニティ ◦ 採用