コミュニティを育てて会社を変える

Transcript

1. コミュニティを育てて 会社を変える DMM×はてな共催オンラインイベント 「それぞれのアジャイル開発の現場 〜 チームの中から外から 〜」 株式会社はてな id:shimobayashi
2. • id:shimobayashi • 株式会社はてな所属 • すくすく開発会の二代目オーナー 自己紹介
3. 会社の変え方 について話したい
4. =開発プロセスに関する 社内コミュニティ
5. Slackチャンネルから出発し、 会社の開発プロセス改善を 加速することができた
6. =会社を変えられた これをふりかえってみると
7. 課題の変化に注目し続けていたら Fearless Change的な変化になった
8. • イノベーター理論にしたがって変革を進める • アイデアを磨きながら広げていく • セグメントに応じて48のパターンを使い分ける Fearless Change
9. https://kawaguti.hateblo.jp/entry/20140228/1393522489 より引用 序盤 中盤 抵抗 パターン名(パターン番号)
10. Fearless Changeと照らし合わせて すくすく開発会が なぜ会社を変えられたのか 話したい
11. Step1: 場をつくる 2017/3 人口: 0→3 中盤 抵抗 序盤
12. 開発プロセスについて 相談する場が無かった😭
13. Slackでチャンネルをつくった ↑当時のオーナー↑
14. 結果
15. • 相談、自慢、(ふりかえりの司会といった)支援依頼など会話が散発 的に行われるようになった • =危機感を持っている人が複数人いた 結果
16. これはFearless Changeでいうと
17. 中核となるエバンジェリスト(1)がいた
18. Slackが電子フォーラム(10)となった (興味をもつかもしれない人々と定期的な接触ができるようになった)
19. 予備調査(4) (アイデアが組織に合うかの調査) も兼ねていた
20. 小さな成功(2) (小さな成功であってもお祝いすることで、困難な道のりを耐える) でもあった
21. 序盤に適した行動をしていた だからうまく立ち上がった
22. いきなり 根回し(45) しても(おそらく)うまくいかない
23. Step2: 加速させる 2019/2 人口: 3→7 中盤 抵抗 序盤
24. 開発プロセスへの 関心が高まっていた🔥 と、支援依頼の増加で気づいた
25. 定例をはじめた ↑当時のオーナー↑
26. 結果
27. • 会話の頻度や密度が増え、知見の横展開が加速した • 少数派たちの孤独感も軽減された ◦ 開発プロセスに関心があるスタッフはまだ少なかった 結果
28. これはFearless Changeでいうと
29. 勉強会(25)だった (あるトピックについて継続的に学ぶグループ)
30. 学びや関係強化につながり 後のアクションを起こしやすくなった
31. • Step1: Slackチャンネルをつくった • Step2: 定例をはじめた • Step3: • Step4: • Step5: ここまで
32. ここまでで コアメンバーを集めることができた (そしてこのあたりでオーナーを自分に交代)
33. Step3: 自立させる 2020/7 人口: 7→9 抵抗 序盤 中盤
34. ふりかえり支援依頼を さばききれなくなってきた😇 だんだん多くのチームから依頼されるようになった
35. 有志に ふりかえりをチームで行えるよう マニュアル化をお願いした
36. 結果
37. • ふりかえりをチームで実施できるようになった • =ふりかえり支援依頼が大幅に減少した 結果
38. これはFearless Changeでいうと
39. みんなを巻き込む(33)だった
40. 「やってもらう」から 「やるのを助けてもらう」になった =主体がチームに移った
41. Step4: 関心を集める 2020/7 人口: 9→9 抵抗 序盤 中盤
42. 開発プロセスの 改善速度を高めたい💪 もっと速くしたかった
43. 開発プロセスに関する講義を 繰り返し開催した 応募フォームから一定人数集まったら、 講師役を持ち回りで開催
44. 結果
45. • 開発プロセスに関心を持つ人が増えた👀 ◦ エンジニアに限らず累計38名のスタッフに受講してもらうことができま した ▪ 全スタッフの約20% ◦ インセプションデッキが以前よりも普及した 結果
46. • 当初、社内勉強会で募集しただけではあまり集まらなかった • 募集要項を改善してエンジニア以外にも展開したところ、応募者が かなり増えた👆👆 ◦ 講義は1時間だけと明記、フォームから応募するだけで勝手に ブッキングされる形にして、心理的抵抗を下げた • マネージャー陣にも営業して、部下に受講を推薦してもらった こうして人を集めました
47. これはFearless Changeでいうと
48. アーリーマジョリティ(30)パターン (多数派を納得させる)
49. 以前のステップで主体が移っていた ことに加えて ひとつの理想を示したことで 理想と現実のギャップが可視化された 結果、関心が集まった
50. • Step1: Slackチャンネルをつくった • Step2: 定例をはじめた • Step3: ふりかえりのマニュアルをつくった • Step4: 開発プロセスの講義を繰り返し行った • Step5: ここまで
51. 序〜中盤に適した 人を増やす動きができていた
52. そのおかげで 会社に影響を及ぼす準備ができた！
53. Step5: アプローチを変える 2021/8 人口: 9→14 抵抗 序盤 中盤
54. 参加者が一気に増えた🚀 これまでのやり方でスケールできなくなった一方、 ほとんどの開発チームから誰かしら参加してくれるようになった。 よって、外ではなく内へ向けて働きかけることで 会社の開発プロセスを改善できるようになった！ ターニングポイント🚗🚘
55. これまでの全体会とは別に、 サブグループ会をはじめた
56. • 5人ごとに3つのサブグループに分割 • コーチ役を中心に交流を通じて、開発プロセスの改善をペーシング • 月3開催 サブグループ会とは
57. • サブグループ会から ◦ 得られた知見の横展開 ◦ 解決できなかった疑問をエスカレーション • 月1開催 全体会はこうなった
58. 結果
59. 開発プロセス改善が 多くのチームで回っている
60. 会社の開発プロセス改善が加速した
61. =会社を変えられた
62. これはFearless Changeでいうと
63. メンター(37)と (アイデアになじみの無いチームへの導入を助ける)
64. 相談できる同志(39)だった (お互いに励まし合うことで、必要以上に落ち込まないようにする)
65. 多くのチームについて メンターに助けてもらいながら 同志と励まし合えるようになった
66. だから 会社の開発プロセス改善が 加速💨した！
67. まとめ
68. • 課題の変化に注目してきた • Step1: Slackチャンネルをつくった • Step2: 定例をはじめた • Step3: ふりかえりのマニュアルをつくった • Step4: 開発プロセスの講義を繰り返し行った • Step5: サブグループ会をはじめた • ふりかえってみると、Fearless Changeと整合的だった ◦ おそらく、課題を正しく取り扱ってきたということ ここまで
69. • イノベーター理論にしたがって変革を進める • アイデアを磨きながら広げていく • セグメントに応じて48のパターンを使い分ける Fearless Change
70. • 人が増えたから、すくすく開発会を通じて会社を改善できている • 人を増やす動きをセグメントに合わせてできていた ◦ 開発プロセス講義でマジョリティに働きかけたのが大きい • これができていなかったら、会社は変わっていなかった 特に重要だったのは
71. 会社を変えていきたいですよね？
72. Fearless Changeで ボトムアップに会社を変えられる👊
73. 付録
74. • Step1: Slackチャンネルをつくった=おそらく数分でエイヤッ • Step2: 定例をはじめた=おそらく数時間でエイヤッ • Step3: ふりかえりのマニュアルをつくった=半年かけてゆっくり • Step4: 開発プロセスの講義を繰り返し行った=半年かけてゆっくり • Step5: サブグループ会をはじめた=1ヶ月くらい検討してエイヤッ 各施策にかけた期間
75. • 外部のお墨付き(12) ◦ >新しいアイデアの信憑性を上げるために、外部の情報を組織内 に紹介しよう。 • 外部のお墨付きだからといって受け入れられる文化ではないので、 あまり効果は感じられなかった ◦ Howからスタートすると基本的に蹴られる ◦ WhyからスタートしてHowにつながらないと納得は得られない やってみたけど根付かなかったパターン
76. • 講義はいくつかやった施策のうちの1つ ◦ 前身となるマニュアルもいくつかあった ◦ マニュアルをつくっただけでは効果は不十分だった • マネージャーが孤軍奮闘するのではなく、メンバーがスキルを身に つけた方が効果的だろうと判断し、講義という形を選択した 開発プロセス講義について補足
77. • おそらく、新しいアイデアについて意思決定者を納得させられない ◦ 社内での実績も無ければ支持団体もいない • おそらく、メンバーの納得を得ることもできない ◦ 開発プロセスの主役はメンバーなのでこれはまずい 根回し(45)からすると何が良くないの？
78. • そっちもやってます • たとえば、マネージャー陣にアンケートやヒアリングをした上で、 課題とそれに対するアイディアをまとめて社長に提案する、といっ たことをしました • 他にも、役員と継続的に会話の場を持つなど模索し続けています トップダウンの動きはしなかった？