さまざまなサイズにおける巻き込み方と伝え方 / OSO2026

Transcript

1. さまざまなサイズにおける 巻き込み方と伝え方 - 地域コミュニティ, スクラムチーム, 100人の技術組織 etc... 粕谷大輔 (だいくしー) 2026-09-12 オープンセミナー2026@岡山 1
3. 今日のテーマ • 仕事にせよ、コミュニティ活動にせよ、人を巻 き込んで物事を動かす必要がある • どうやって組織に自分の意図を伝えるか？ 3
4. 過去に関わった「サイズ」の遍歴 開発チーム (スクラムチーム) SaaSプロダクトの ディレクター 技術組織の マネージャー 4~6人 10~20人 100人~ 小さな勉強会・ 地域コミュニティ 大きめの勉強会 カンファレンススタッフ 京都アジャイル勉強会 EM Louge 鹿駆動勉強会 Scala関西 Scala Matsuri 仕事 コミュニティ 4
5. 今日話すサイズ感と特徴 〜10人 〜50人 100人〜 5
6. 最初は「言えば伝わる」 〜10人 〜50人 100人〜 • 全員の顔が見える • 伝わったかどうかが直接わかる • 「説明すれば伝わる」で物事が進む 6
7. サイズが大きくなると伝わらなくなる 〜10人 〜50人 100人〜 • 全員と話せない • 伝わらない人がでてくる（通知やメールに気づかない、 ミーティングの日に体調を崩して休んでいる） • 伝え方の工夫が必要 7
8. さらに大きくなると内容が途中で変わ る 〜10人 〜50人 100人〜 • 伝言ゲームになるので、自分が直接伝えた人と、経路の 末端で情報を得た人とで理解が異なる • 解釈がブレにくい伝え方の工夫が必要 8
9. 経路は n(n-1)/2 で爆発する 5人 → 10本 10人 → 45本 15人 → 105本 50人なら 1,225本、100人なら 4,950本 9
10. お互いを理解し合う認知の上限 150 50 15 5 • 人間が安定的な社会関係を維持できるとされる 人数の認知的な上限 • ここでいう関係とは、ある個人が、各人のこと を知っていて、さらに、各人がお互いにどのよ うな関係にあるのかをも知っている、というも の R. Dunbar のダンバー数 10
11. サイズごとのまとめ 〜10人 自分で直接伝えられる 〜50人 100人〜 直接伝える上限を 超え始める 経路で内容が変質する (さらに150を超えると認知 の上限も超える) 11
12. 問題の対処の仕方 12
13. 問題の対処の仕方 1. 繰り返す 2.他人を巻き込む 3.全員に伝え切ろうとしない 4.経路を設計する 13
14. サイズごとの対処 〜10人 自分で直接伝えられる 〜50人 - 繰り返す - 他人を巻き込む 100人〜 - 全員に伝え切ろうとしない - 経路を設計する 14
15. 1.繰り返す 15
16. √（ルート）の法則 • √100 = 10 100人に分かってもらうには 同じ話を10回 • • • 帝人の元社長安居祥策が、物事を他人に理解 してもらうときの目安として使っていた法則 物事を理解してもらうために必要な繰り返し 回数が対象人数の平方根になる 1万人なら100回（√10000 = 100） トップのビジョンを浸透させるためには地道 な継続が不可欠である 日本経済新聞「社長に必要な法則」2010年5月12日 16
17. 人々は自分の話より多くの「その他のコミュニケーション」をしてい る • 3ヶ月間に一人の従業員に届くコミュニケーションの総量=2,300,000のワード • 3ヶ月間に、変革ビジョンのコミュニケーションに費やされる量=13,400ワード（30分の スピーチ, 1時間のミーティング, 社内報の記事 etc...) • 13,400 / 2,300,000 = 0.58% • つまり変革ビジョンのコミュニケーションは、コミュニケーション総量の0.58%しか費や されていない John P. Kotter『Leading Change（企業変革力）』日経BP 2002 17
18. 1.繰り返す • 大勢の人に伝達するためには粘り強く同じ話をし 続ける必要がある • 情報伝達するためには、メンバーの日常のコミュ ニケーション総量の割合を増やす必要がある 18
19. 2. 他人を巻き込む 19
20. Complex contagion(複雑な伝播) • 情報や病気は1対1の接触で感染する（単純な伝播） • ある種のイノベーションは人が集団的に採用してはじめて魅 力的なものになる。人が新しいやりかたを採用するには複数 の情報源からの裏付けを必要とする (複雑な伝播) Centola & Macy 2007, American Journal of Sociology 20
21. 巻き込んだ人をノードにする 次の集団へ 巻き込む側 巻き込まれた人 21
22. 3. 全員に伝え切ろうとしな い 22
23. 集団の25%が動けば全体が動く 25% 変わらない 集団全体が動く コミットした少数派の割合 確立した慣習に対して、15〜35%の割合で「コミットした少数派」を投入する実験を行ったところ、 約25%を境に、集団全体が少数派の慣習を採用した。 Centola, Becker, Brackbill & Baronchelli (2018) Science 360, 1116–1119 23
24. キャズム理論 キャズム 13.5% 34% 34% 16% イノベーター 2.5% アーリーアダプター 13.5% アーリーマジョリティ 34% レイトマジョリティ 34% ラガード 16% 最初の 16% 24
25. 4. 経路を設計する 25
26. 伝えたい情報が伝わる構造をつくる • 人の階層構造 ◦ 技術グループ長 -> チーフエンジニア(7人) -> シニアエンジニア (30 人) -> メンバー全体(100人~) • 1on1 • 評価制度やラダー ◦ 制度にメッセージを組み込む ◦ 季節ごとのイベントで必ず目に触れる • サーベイ ◦ 伝わったかを計測する ◦ 情報の変質を観測する 26
27. ここまでのまとめ 〜10人 自分で直接伝えられる 〜50人 - 繰り返す - 他人を巻き込む → 自発的な伝播を促す 100人〜 - 全員に伝え切ろうとしない - 経路を設計する → 制度的な経路を作る 27
28. コミュニティの場合 28
29. 仕事とコミュニティの違い • ボランティアベースなので人によって使える時 間やリソースの差が大きい ◦ 深くコミットできる人や浅くしか関われない人など事情 がさまざま • コミュニティに参加する動機も多様 29
30. とはいえやることはそんなに変わらな い • コアメンバー同士よく話し合う • 当日スタッフのようなスポットで手伝ってくれる 人もいるので、連絡経路はきちんと決めておく 30
31. はてなの技術組織での 浸透の実例 31
32. はてなの技術組織 | マトリクス組織 エンジニアは開発グループと技術グループの両⽅に所属します。開発グループが縦軸、技術グループは横軸 の組織で、技術グループはエンジニアの成⻑と技術の展開を担当します。 エンジニアの⼈数は100名強です。 はてなブログ マンガ toitta Mackerel 技術グループ Eng Eng Eng Eng デザイングループ Des Des Des Des 32
33. 技術グループの ある半期の目標 33
34. AIを使いこなして バリューストリームを 激流にする 34
35. 目標の狙い • 当時はまだ「AIをとにかく使ってほしい」とい う時期だった。その上で期待を上げる成果を出 してほしいというメッセージ • はてなはプロダクトごとに事業/チームが独立 しており、それぞれ固有の事情の差異が大きす ぎるため、抽象的な目標にならざるを得ない 35
36. AIを使いこなしてバリューストリームを激流にす る • ポイントは「激流」という単語のインパクト • ある指標が5%改善したとして「5%は激流といえる か？」と議論を促せる。場合によってはそこからさ らに踏み込む議論になりやすい • AIを使わずにバリューストリームが改善したとし て、時勢的にAIを使ったほうがより「激流」なので は、と「AIを使う」という意図に目を向けやすい 36
37. AIを使いこなしてバリューストリームを激流にす る 現場で繰り返される言葉にする 1 1度では届かない 100人の組織に、1度のメッセージで意図を伝えるのは不可能 2 現場で繰り返される必要がある 自分がいない場でも話題に上がる状態をつくる 3 短くインパクトのある言葉 チームのあちこちで、議論の的にしやすい 実際、定常的にそれぞれのチームで話題になっていた → コミュニケーションの総量を多くできた 37
38. 具体的にやったこと 「激流」という言葉をつくる 自分の口から直接伝える • エンジニア全員の集会で周知 • グループウェアで周知 • 「今週の激流」というコーナーをつく り、1週間の各チームの取り組みを毎週 アナウンス 他人の口に載せる • シニアエンジニアとの1on1で繰り返し 話題に • シニアエンジニアたちに、チームで事 あるごとに話題にするよう促した 意図的に「話題を独り歩きさせる」ことをやる 38
39. 話題の独り歩き • チャットの雑談で皆がおもしろがって「激流」という言 葉をよく使うようになった ◦ 入社直後の人がさっそく同僚と遅くまでお酒を飲んだという話題にて 39
40. 話題の独り歩き • グループウェアに「激流」をテーマとしたさまざまなテキ ストが投稿された • 「激流を考える会」という定例会を設けるチームがあった • Slack emojiが作られた 40
41. 技術グループの体制 • 技術グループ長 (daiksy) • チーフエンジニア (7人) • シニアエンジニア (30人) この人たちと一緒にやることで 組織全体が動く25%を超えることができる 41
42. 流量を増やす 組織全体のコミュニケーション流量を調整する メンバーの日常のコミュニケーション総量 何もしないと 意図的に流し込むと ← 意図した情報は総量のごく一部（Kotterの試算では0.58%） ← この流量をどこまで大きくできるか？ 人が多くなるほど、意図的に組織へ流し込む情報量を増やさないと、 組織内を流れるコミュニケーション総量は増えない 42
43. 注意点: 真実性の錯覚 • 認知バイアス • 同じ情報に何度も触れると、それが偽りであって も真実であると錯覚してしまう • 反復と同時に反証の経路を設計する ◦ ふりかえりなどで反対意見を述べたり、議論したりできる場を 用意しておく 43
44. 巻き込む力 巻き込まれる力 44