Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
エレガントパズル 30分 ダイジェスト版/ Elegant Puzzle 30min Digest
Search
iwashi
July 16, 2024
Technology
5
320
エレガントパズル 30分 ダイジェスト版/ Elegant Puzzle 30min Digest
https://creationline.connpass.com/event/322816/
の登壇資料です。
iwashi
July 16, 2024
Tweet
Share
More Decks by iwashi
See All by iwashi
エンジニアリングが好きな私たちのためのエンジニアリングマネジャー入門 / Engineering management for the rest of us
iwashi86
21
4.3k
エレガントパズル エンジニアのマネジメントという難問にあなたはどう立ち向かうのか / Elegant Puzzle
iwashi86
15
3.3k
ベロシティを高く保つ仕事のすすめ方 / Maintaining a High Velocity as Productivity Hacks
iwashi86
55
19k
マネージャー&リーダー向け 社内トレーニング / Training of management and leadership for Stockmark
iwashi86
64
31k
30分でわかる「エンジニアのためのドキュメントライティング」- インフラエンジニアBooks / Docs for Developers within 30 minutes
iwashi86
9
2.3k
エンジニアのためのドキュメントライティング / Docs for Developers
iwashi86
33
20k
なぜ変化を起こすのが難しいのか? - 数年以上にわたって難しさに向き合い・考え取り組んできたこと / The reason why changing organization is so hard - What I thought and faced for more than several years
iwashi86
59
83k
2015年 第4四半期の WebRTC 標準化 アップデート / 2015 update of WebRTC Standards
iwashi86
0
190
外注が主な企業でどのように内製開発を立ち上げ・進化させているのか? / how we start in-house developement in enterprise?
iwashi86
2
31k
Other Decks in Technology
See All in Technology
Our Journey from in-House CD System to Open Source
ffjlabo
0
100
Staff Engineer / 20240827 Yuichiro Masui
shift_evolve
0
150
サイボウズ 開発本部採用ピッチ / Cybozu Engineer Recruit
cybozuinsideout
PRO
9
41k
Dojo 20240830 COBOL to Java on Z
ichikawayasuhisa
0
240
手軽に始める? おうちサーバーのすゝめ
nyagasan
0
180
OCI コスト管理
ocise
1
110
夏休みの(最後の)宿題 for JuliaTokyo #12
antimon2
0
130
Hyperledger Fabricの成長、成熟を振り返る / Looking back history of Hyperledger Fabric
gakumura
0
180
歴史と背景から改めて振り返るVPC
shotashiratori
2
220
[RSJ24] Object Segmentation from Open-Vocabulary Manipulation Instructions Based on Optimal Transport Polygon Matching with Foundation Models
keio_smilab
PRO
0
120
デジタル化・DX推進あるある
y150saya
0
220
リクルートのデータマネジメント組織に 求められてきたコト
recruitengineers
PRO
4
340
Featured
See All Featured
Typedesign – Prime Four
hannesfritz
38
2.3k
A better future with KSS
kneath
235
17k
Documentation Writing (for coders)
carmenintech
65
4.3k
Building Your Own Lightsaber
phodgson
101
5.9k
What’s in a name? Adding method to the madness
productmarketing
PRO
21
3k
Building Flexible Design Systems
yeseniaperezcruz
324
37k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
225
22k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
662
120k
How GitHub (no longer) Works
holman
309
140k
Designing with Data
zakiwarfel
98
5k
Thoughts on Productivity
jonyablonski
65
4.2k
Making Projects Easy
brettharned
113
5.8k
Transcript
エレガントパズル エンジニアのマネジメントという難問に あなたはどう立ち向かうのか - 30分ダイジェスト - 2023年6月 岩瀬 @iwashi86
1 チェックイン • おすすめのマネジメント系書籍を1冊、 Zoom Chat に書いてみましょう! ◦ マネジメントに関わるものなら何でもOKです! (Xでも構いません。
ハッシュタグは #clmeetup です)
2 発表終了時の到達点 • 「エレガントパズル」本の全体像を知ること • 書籍で言及される知見の一部を、詳しめに知ること • 書籍を購入したい気持ちになる
3 今日のアジェンダ • 書籍の位置付けを知る • 書籍の全体像を知る • 個別トピックをいくつか抑える
4 • ウィル・ラーソン氏 (@lethain) • Uber社のシニアエンジニアリングマネージャーや Stripe社のエンジニア組織のHeadを歴任 • 現在はCarta社のCTO •
書籍を3冊執筆 著者
5 どんな本? • EM や VPoE 観点からの実践知が多く掲載される ◦ 研究による裏付けがメインという類の書籍ではない •
チーム編成から組織文化、採用から業績評価まで 組織運営に必要なトピックが言及されている
6 実践 学術/ 研究 主観に基づく雑マッピング 注:もっとたくさん挙げたい書籍がありますが、自分の本棚 + kindle からぱっと目についたものを挙げてます
7 実践 学術/ 研究 主観に基づく雑マッピング 注:もっとたくさん挙げたい書籍がありますが、自分の本棚 + kindle からぱっと目についたものを挙げてます 論文(のメタアナリシス)
などから導出された知見に 基づく書籍。 様々な組織で使える 可能性がある。
8 実践 学術/ 研究 主観に基づく雑マッピング 注:もっとたくさん挙げたい書籍がありますが、自分の本棚 + kindle からぱっと目についたものを挙げてます 論文(のメタアナリシス)
などから導出された知見に 基づく書籍。 様々な組織で使える 可能性がある。 ある特定の企業でうまくいった 経験に基づく書籍。 n=1 に近いため文脈が 近ければかなりハマるかも。
9 実践 学術/ 研究 ハード(組織設計・戦略など) ソフト(人・文化など) 主観に基づく雑マッピング 注:もっとたくさん挙げたい書籍がありますが、自分の本棚 + kindle
からぱっと目についたものを挙げてます
10 実践 学術/ 研究 ハード(組織設計・戦略など) ソフト(人・文化など) 主観に基づく雑マッピング 注:もっとたくさん挙げたい書籍がありますが、自分の本棚 + kindle
からぱっと目についたものを挙げてます 組織設計・戦略・システムなど トップが判断すれば方針が さっと変わるトピック中心
11 実践 学術/ 研究 ハード(組織設計・戦略など) ソフト(人・文化など) 主観に基づく雑マッピング 注:もっとたくさん挙げたい書籍がありますが、自分の本棚 + kindle
からぱっと目についたものを挙げてます 組織設計・戦略・システムなど トップが判断すれば方針が さっと変わるトピック中心 人の関係性や組織文化など、 「やるぞー」といっても すぐに変わらないトピック中心
12 実践 学術/ 研究 ハード(組織設計・戦略など) ソフト(人・文化など) 主観に基づく雑マッピング 注:もっとたくさん挙げたい書籍がありますが、自分の本棚 + kindle
からぱっと目についたものを挙げてます
13 実践 学術/ 研究 ハード(組織設計・戦略など) ソフト(人・文化など) 主観に基づく雑マッピング 注:もっとたくさん挙げたい書籍がありますが、自分の本棚 + kindle
からぱっと目についたものを挙げてます
14 実践 学術/ 研究 ハード(組織設計・戦略など) ソフト(人・文化など) 主観に基づく雑マッピング 注:もっとたくさん挙げたい書籍がありますが、自分の本棚 + kindle
からぱっと目についたものを挙げてます ← 7/14 発売!
15 実践 学術/ 研究 ハード(組織設計・戦略など) ソフト(人・文化など) 主観に基づく雑マッピング 注:もっとたくさん挙げたい書籍がありますが、自分の本棚 + kindle
からぱっと目についたものを挙げてます マネジメントに絶対的な正解は無いので 様々なアイデアを把握した上で 自分の文脈にカスタマイズして 適用していくのがオススメ
16 • 岩瀬 義昌 (@iwashi86) / Yoshimasa Iwase • 本業
◦ 通信会社で Generative AI Project の リーダー(EMとPdM) • サイドワーク ◦ ストックマーク社で Co-VPoE ◦ 早稲田大学で非常勤講師(プログラミング) ◦ Podcaster (fukabori.fm) ◦ 翻訳者
17 全体像
18 書籍の全体像 第1章 導入:重要なパズルを解くために 第2章 組織:機能する組織を作り、維持する 第3章 ツール:変化をマネジメントする手法 第4章 アプローチ:問題解決につなげる 第5章 文化:継続的に取り組んで育成する 第6章 キャリア:同僚と自分に対して責任を持つ 第7章 さらに先へ
19 書籍の全体像 第1章 導入:重要なパズルを解くために (Webで公開中) 第2章 組織:機能する組織を作り、維持する 第3章 ツール:変化をマネジメントする手法 第4章 アプローチ:問題解決につなげる 第5章 文化:継続的に取り組んで育成する 第6章 キャリア:同僚と自分に対して責任を持つ 第7章 さらに先へ https://bookplus.nikkei.com/atcl/column/032900009/051300596/
20 書籍の全体像 第1章 導入:重要なパズルを解くために 第2章 組織:機能する組織を作り、維持する 第3章 ツール:変化をマネジメントする手法 第4章 アプローチ:問題解決につなげる 第5章 文化:継続的に取り組んで育成する 第6章 キャリア:同僚と自分に対して責任を持つ 第7章 さらに先へ •
チームサイズ(人数)の決め方 • チームごとのマネジャーの役割 • チームの成長段階・育て方 • エンジニアの採用と育成とのバランス • 組織的負債の扱い • サクセッションプランニング(後継者育成)
21 書籍の全体像 第1章 導入:重要なパズルを解くために 第2章 組織:機能する組織を作り、維持する 第3章 ツール:変化をマネジメントする手法 第4章 アプローチ:問題解決につなげる 第5章 文化:継続的に取り組んで育成する 第6章 キャリア:同僚と自分に対して責任を持つ 第7章 さらに先へ •
システム思考(開発プロセスを事例に) • プロダクトマネジメント • 戦略とビジョンの使い分け • メトリクスの効果的な活用方法 • マイグレーション(技術的負債の唯一のスケーラブルな解決策) • 学習コミュニティ 3章は他にも色々
22 書籍の全体像 第1章 導入:重要なパズルを解くために 第2章 組織:機能する組織を作り、維持する 第3章 ツール:変化をマネジメントする手法 第4章 アプローチ:問題解決につなげる 第5章 文化:継続的に取り組んで育成する 第6章 キャリア:同僚と自分に対して責任を持つ 第7章 さらに先へ •
組織の運営ポリシーと例外負債 • マネジメントの哲学 • アイデアと実行 • EMの成長が行き詰まるとき • マネジメントの哲学
23 書籍の全体像 第1章 導入:重要なパズルを解くために 第2章 組織:機能する組織を作り、維持する 第3章 ツール:変化をマネジメントする手法 第4章 アプローチ:問題解決につなげる 第5章 文化:継続的に取り組んで育成する 第6章 キャリア:同僚と自分に対して責任を持つ 第7章 さらに先へ •
機会(専門での成功とキャリア開発に臨めること)と メンバーシップ(ありのままで参加できること) • 機会を公平に作り出す方法 • メンバーシップを高める方法 • ポジティブな自由とネガティブな自由 • ヒーローへの対応
24 書籍の全体像 第1章 導入:重要なパズルを解くために 第2章 組織:機能する組織を作り、維持する 第3章 ツール:変化をマネジメントする手法 第4章 アプローチ:問題解決につなげる 第5章 文化:継続的に取り組んで育成する 第6章 キャリア:同僚と自分に対して責任を持つ 第7章 さらに先へ •
自身のキャリアの考え方 • 面接プロセスの運用方法 ◦ 採用ファネルの使い方を含む • 候補者プールを広げる方法(コールドソーシング) • 業績管理システム • 等級(グレード)の考え方
25 書籍の全体像 第1章 導入:重要なパズルを解くために 第2章 組織:機能する組織を作り、維持する 第3章 ツール:変化をマネジメントする手法 第4章 アプローチ:問題解決につなげる 第5章 文化:継続的に取り組んで育成する 第6章 キャリア:同僚と自分に対して責任を持つ 第7章 さらに先へ •
チーム(ライン) → グループ(チームの集まり) → 組織(グループの集まり) と成長したときのマネジメント方法 • 著者に役立った書籍と論文
26 個別トピックを 一部紹介 (特に参考にしているもの)
27 システム思考 https://unsplash.com/photos/sm0Bkoj5bnA
28 システム思考 • 詳細は 『世界はシステムで動く ― いま起きていることの本質をつかむ考え方』(英治出版)
29 システム思考 • 詳細は 『世界はシステムで動く ― いま起きていることの本質をつかむ考え方』(英治出版) • エレガントパズルでは一部が紹介されている ◦
書籍では 『Lean とDevOps の科学[Accelerate] テクノロジーの戦略的活用が組織変革を加速する』(インプレス) で挙がるメトリクスを参照しつつ説明
30 プルリクエスト 単位時間あたりの コードレビュー数 開発での例
31 プルリクエスト (デプロイの) 準備完了 コミット 単位時間あたりの コードレビュー数 単位時間あたりの デプロイ数 開発での例
32 プルリクエスト (デプロイの) 準備完了 コミット デプロイ済み コミット インシデント 単位時間あたりの コードレビュー数
単位時間あたりの デプロイ数 単位時間あたりの 欠陥数 開発での例
33 プルリクエスト (デプロイの) 準備完了 コミット デプロイ済み コミット インシデント 単位時間あたりの コードレビュー数
単位時間あたりの デプロイ数 単位時間あたりの 欠陥数 単位時間あたりの 復旧数 開発での例
34 プルリクエスト (デプロイの) 準備完了 コミット デプロイ済み コミット インシデント リバート コミット
単位時間あたりの コードレビュー数 単位時間あたりの デプロイ数 単位時間あたりの 欠陥数 単位時間あたりの 復旧数 単位時間あたりの デバッグ数 開発での例
35 プルリクエスト (デプロイの) 準備完了 コミット デプロイ済み コミット インシデント リバート コミット
単位時間あたりの コードレビュー数 単位時間あたりの デプロイ数 単位時間あたりの 欠陥数 単位時間あたりの 復旧数 単位時間あたりの デバッグ数 数値を見ることによる活用① 準備完了コミットの ストック(数値)が ほぼゼロであれば
36 プルリクエスト (デプロイの) 準備完了 コミット デプロイ済み コミット インシデント リバート コミット
単位時間あたりの コードレビュー数 単位時間あたりの デプロイ数 単位時間あたりの 欠陥数 単位時間あたりの 復旧数 単位時間あたりの デバッグ数 数値を見ることによる活用① 単位時間のデプロイ数を 増やしても効果が薄い 準備完了コミットの ストック(数値)が ほぼゼロであれば
37 プルリクエスト (デプロイの) 準備完了 コミット デプロイ済み コミット インシデント リバート コミット
単位時間あたりの コードレビュー数 単位時間あたりの デプロイ数 単位時間あたりの 欠陥数 単位時間あたりの 復旧数 単位時間あたりの デバッグ数 数値を見ることによる活用② 「単位時間あたりの欠陥数」が小さくて インシデントがほぼなければ
38 プルリクエスト (デプロイの) 準備完了 コミット デプロイ済み コミット インシデント リバート コミット
単位時間あたりの コードレビュー数 単位時間あたりの デプロイ数 単位時間あたりの 欠陥数 単位時間あたりの 復旧数 単位時間あたりの デバッグ数 数値を見ることによる活用② 「単位時間あたりの欠陥数」が小さくて インシデントがほぼなければ 「単位時間あたりの復旧数」を いくら増やしても効果は薄い
39 組織デザインと例外対応
40 組織デザイン • 本書で扱われるチームは主に「Devチーム」
41 組織デザイン • 本書で扱われるチームは主に「Devチーム」 • ひとつメタ的に捉えると全体像の中の位置づけを理解できて 応用が効くようになる → そこで、本書外ではあるが先に「組織デザイン」について説明する
42 組織デザイン • なぜ組織が必要なのか? → 個人では限界があるため
43 組織デザイン • なぜ組織が必要なのか? → 個人では限界があるため • 例:パンの大規模販売 ◦ 仕入れ:小麦などの原材料を仕入れる(もしくは育てる)
◦ 調理:生地を作って焼く ◦ 販売:お店でお客様に売る (1人でもできなくはないが、スケールしない)
44 どの組織であっても必ず「分業」「調整」がある • 分業:役割を分けることで 専門性を発揮させるなどのメリットを追求すること
45 どの組織であっても必ず「分業」「調整」がある • 分業:役割を分けることで 専門性を発揮させるなどのメリットを追求すること • 調整:分業の一部ずつを担っている人々の活動が、 時間的・空間的に調整されて、多数の人々の活動が あたかも一つの全体であるかのように 連動して動くこと(あるいは目指すこと)
46
47 組織デザインとは? “様々な経済性を求めて分業が行われる。 しかし分業を行うと、各人の活動を調整、 各人の努力が最終的なアウトプットにまとまるように統合しなければならない。 人々の活動を調整し、最終的なアウトプットへと統合していくために 多様な工夫が施される。 この分業と調整の工夫が集積されたものが組織デザインである。”
48 組織における例外(Exception) • 分業 と 調整 だけで話が進めばいいが、 現実はそんなにシンプルではない → イレギュラーな事象(=例外)が必ず発生する
49 組織における例外(Exception) • 分業 と 調整 だけで話が進めばいいが、 現実はそんなにシンプルではない → イレギュラーな事象(=例外)が必ず発生する • さきほどの例で言えば ◦
小麦粉が配送遅延で届かない ◦ オーブンが故障して、パンが焼けない ◦ お客様からクレームが上がっている
50 例外の受け皿になるのがマネージャー 現場 マネージャー ディレクター 社長 … 注:組織によって階層数は異なる。初期スタートアップなら1-2階層。
51 例外の受け皿になるのがマネージャー 現場 マネージャー ディレクター 社長 … 注:組織によって階層数は異なる。初期スタートアップなら1-2階層。 try: 現場のmember.プロジェクトを実行する()
52 例外の受け皿になるのがマネージャー 現場 マネージャー ディレクター 社長 … 注:組織によって階層数は異なる。初期スタートアップなら1-2階層。 try: 現場のmember.プロジェクトを実行する()
except Exception as e: # 例外の原因を調査し、対応策を決定 if (自分の裁量で判断・実行可能) { EM.原因を特定する(e) EM.対応策を実行する() }
53 例外の受け皿になるのがマネージャー 現場 マネージャー ディレクター 社長 … 注:組織によって階層数は異なる。初期スタートアップなら1-2階層。 try: 現場のmember.プロジェクトを実行する()
except Exception as e: # 例外の原因を調査し、対応策を決定 if (自分の裁量で判断・実行可能) { EM.原因を特定する(e) EM.対応策を実行する() } else { # 上位に投げる # 解決できるまで上位にエスカレされる }
54 組織における例外(Exception)による弊害 • 例外の数が極端に増えるとどうなるか?
55 組織における例外(Exception)による弊害 • 例外の数が極端に増えるとどうなるか? → マネージャーが例外処理に忙殺されて、 全体として非効率になる
56 組織における例外(Exception)による弊害 • 例外の数が極端に増えるとどうなるか? → マネージャーが例外処理に忙殺されて、 全体として非効率になる 加えて →
例外を頻繁に受け入れている組織は、 バイアスに強い影響を受けるようになり「一貫性」が損なわれる
57 組織における例外(Exception)による弊害 • 例外の数が極端に増えるとどうなるか? → マネージャーが例外処理に忙殺されて、 全体として非効率になる 加えて →
例外を頻繁に受け入れている組織は、 バイアスに強い影響を受けるようになり「一貫性」が損なわれる • 一方で「変化しない」組織は衰退していく → どのように変化と一貫性のバランスを取るか?
58 ポリシーに従う、例外に従わない(p.105) • ゴールを定め、そのゴールと行動を一致させるための制約を作る = これがポリシーとなる
59 ポリシーに従う、例外に従わない(p.105) • ゴールを定め、そのゴールと行動を一致させるための制約を作る = これがポリシーとなる • 書籍では、リモートワークオフィスのポリシーが例示される (具体・詳細は書籍を参照のこと)
60 ポリシーの成否はどう決まるか?
61 ポリシーの成否はどう決まるか? • 成否は、例外への要求対応によって定まる ◦ 例外を認めれば認めるほど、 前例が積み重なりポリシーの力が弱まっていく → これが「例外負債」となっていく
62 ポリシーの成否はどう決まるか? • 成否は、例外への要求対応によって定まる ◦ 例外を認めれば認めるほど、 前例が積み重なりポリシーの力が弱まっていく → これが「例外負債」となっていく •
では、どうすればいいのか? → 例外処理をやめて、ポリシーに従うしかない
63 変化の調和をどう取る?(p.108) ポリシーに従うといっても、例外への対応要求(エスカレーション)を ずっと無視し続けるわけにはいかない。そこで……
64 変化の調和をどう取る?(p.108) ポリシーに従うといっても、例外への対応要求(エスカレーション)を ずっと無視し続けるわけにはいかない。そこで…… エスカレーション 蓄積用 ポリシー ドキュメント 参照
65 変化の調和をどう取る?(p.108) ポリシーに従うといっても、例外への対応要求(エスカレーション)を ずっと無視し続けるわけにはいかない。そこで…… エスカレーション 蓄積用 ポリシー ドキュメント 参照 十分にエスカレーションが
溜まったら、この情報を活用して ポリシーを更新する 次回の更新時期も宣言しておくと良い
66 学習コミュニティ https://unsplash.com/photos/XkKCui44iM0
67 Community of Learning - 上手くいかなかったこと • いわゆるEMコミュニティでの勉強会
68 Community of Learning - 上手くいかなかったこと • いわゆるEMコミュニティでの勉強会 • 上手くいかなかったこと
◦ 重要な教訓などをびっしり書いた内容の濃いプレゼン (今もやってる!けど、ぜひ自分の場を作りましょう) ◦ 結果的に出席率も下がり、学習効果も低かった
69 Community of Learning - 上手くいったこと • 上手く行ったアプローチ ◦ 主催者は講師ではなく、互いの学びをファシリテートする
70 Community of Learning - 上手くいったこと • 上手く行ったアプローチ ◦ 主催者は講師ではなく、互いの学びをファシリテートする
◦ 進め方 ▪ チェックインで20-30秒で名前・所属・考えていることを共有 ▪ プレゼンは短く5分程度、残りはブレイクアウトして ディスカッションする時間に • 盛り上がらないこともあるので、10分程度が良い ▪ ブレイクアウトして戻ったら、学びを相互共有する
71 マネジメントの哲学 https://unsplash.com/photos/XkKCui44iM0
72 マネジメントの哲学 • 著者が当初考えていたこと ◦ 黄金律は非常に理にかなっている ◦ チーム全員がオーナシップを明確に持つ ◦ 報酬と地位は、高い品質の仕事の達成により得られる
◦ 自分が先頭に立つ。自分がやらないことは誰かに頼まない → ベースとしては機能したが、うまくいかないものもあった
73 強い関係性はどんな問題にも勝る • チーム内の問題は、関係節の欠如や悪化に帰着する
74 強い関係性はどんな問題にも勝る • チーム内の問題は、関係節の欠如や悪化に帰着する • さまざまな出来事は機会になる ◦ 技術的な意見の相違 = 学びの機会 ◦ 失敗 = チームが結束する機会
75 https://thesystemsthinker.com/what-is-your-organizations-core-theory-of-success/ より引用 参考:ダニエルキムの成功循環モデル
76 1. メンバー間の信頼の欠如 2. 信頼がないことによる、衝突への恐怖 3. 衝突への恐怖による、責任感の不足 (たとえば、表面上は同意して行動を起こさない) 4. 責任感の不足により、説明責任の回避
(たとえば、良くない行動や態度を見て見ぬふりに) 5. 互いの説明責任の回避による、結果への無関心 順 序 参考:チームの5つの機能不全要因
77 プロセスよりも人が大事 「正しい人材がいれば、どんなプロセスでも機能する。 間違った人材がいるなら、どんなプロセスも機能しない。」
78 採用 https://unsplash.com/photos/fY8Jr4iuPQM
79 採用ファネル全体像
80 採用ファネル全体像 書籍では各項目に対して説明があるが ここではすべてをピックアップできないので一部を紹介
81 コールドソーシング • 採用経路は主に3種類 ◦ インバウンド(自然流入) ◦ リファーラル ◦ ソーシング(アウトバウンド)
82 コールドソーシング • 採用経路は主に3種類 ◦ インバウンド(自然流入) ◦ リファーラル ◦ ソーシング(アウトバウンド)
• このうちソーシング、特に「コールドソーシング」は マネージャー自ら、見ず知らずの人に声をかけること ◦ これは心理的ハードルがかなり高い(著者も気まずかったと言っている)
83 コールドソーシング • 採用経路は主に3種類 ◦ インバウンド(自然流入) ◦ リファーラル ◦ ソーシング(アウトバウンド)
• このうちソーシング、特に「コールドソーシング」は マネージャー自ら、見ず知らずの人に声をかけること ◦ これは心理的ハードルがかなり高い(著者も気まずかったと言っている) → であれば、どうすればできるのか?
84 具体的な方法 • Linkedin に参加 + 知り合いをフォローしてネットワークを築く ◦ ここが増えれば増えるほど、スパマーとして判定されにくくなる
85 具体的な方法 • Linkedin に参加 + 知り合いをフォローしてネットワークを築く ◦ ここが増えれば増えるほど、スパマーとして判定されにくくなる •
やりすぎると、制限がかかることもある ◦ その場合は辛抱強く待つ or 有料プランを使う
86 具体的な方法 • Linkedin に参加 + 知り合いをフォローしてネットワークを築く ◦ ここが増えれば増えるほど、スパマーとして判定されにくくなる •
やりすぎると、制限がかかることもある ◦ その場合は辛抱強く待つ or 有料プランを使う • 二次的な関係を持つ人を探してつながりをリクエストする ◦ 文面は非常にシンプルで良い ◦ 具体例は書籍参照だが、本当に簡素: ▪ あいさつ + なぜお声がけしたか + お話できませんか? 程度 補足:日本だと文脈がちょっと違う
87 続:具体的な方法 • 上記のつながり構築作業に「毎週1時間」を費やすようにする ◦ (カジュアル面談などのフォローアップは別)
88 続:具体的な方法 • 上記のつながり構築作業に「毎週1時間」を費やすようにする ◦ (カジュアル面談などのフォローアップは別) • 前述のように不安感を覚える人もいるので 同僚と一緒に週次ミーティングをセットして、一緒にやるのも手
89 • 上記のつながり構築作業に「毎週1時間」を費やすようにする ◦ (カジュアル面談などのフォローアップは別) • 前述のように不安感を覚える人もいるので 同僚と一緒に週次ミーティングをセットして、一緒にやるのも手 “ここまで読んできて、これらの方法はうまくいかないだろうと 思っただろうか?
大丈夫、私もうまくいかないと思っていた。 (略) 単に時間の無駄と考えていた。(略) だが、その考えはゆっくり変わっていった。” (p.171) 続:具体的な方法
90 おわりに
91 今日お話したこと • 書籍の位置付け • 書籍の全体像 • 個別トピック ◦ システム思考
◦ 組織デザインと例外対応 ◦ インクルーシブな組織 ◦ 学習コミュニティ ◦ 採用
92 発表終了時の到達点 • 「エレガントパズル」本の全体像を知ること • 書籍で言及される知見の一部を、詳しめに知ること • 書籍を購入したい気持ちになる
93 チェックアウト • 本日の話を聞いてみて 「次にこれをやってみよう!」 ということをZoom Chatにポストしてみましょう! (Xでも構いません。 ハッシュタグは #clmeetup
です)