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