Tweet
Tweet

Slide 1

Slide 1 text

”開発側” ”ビジネス側” の先へ 〜アジャイルで超えた３つの壁〜 完 全 版

Slide 2

Slide 2 text

陶⼭ 育男 Ikuo Suyama @martin_lover_se ⾒習い “Agile Developer” @CyberAgent AI tech Studio New!

Slide 3

Slide 3 text

Mob Mentality Show with Chris, Austin, 川⼝さん, 永⽥さん, 吉 ⽥さん omoiyari.fm#48 with 横道さん, 三浦さん, 川 ⼝さん XP祭り2019 Coming soon!! 「全部⾒せますモブプロジャー ニー︕ 」 ⾒てね︕

Slide 4

Slide 4 text

今⽇お話すること とあるB2Bプロダクトでのアジャイル実践 • “開発側” “ビジネス側” が分断された状態から、ア ジャイルなチームになっていった過程 • 変化の過程で現れた「３つの壁」 • 壁に直⾯した時考えたこと、実践したこと

Slide 5

Slide 5 text

「ビジネス側の⼈と開発者は、 プロジェクトを通して ⽇々⼀緒に働かなければなりません。」 ーアジャイル宣⾔の背後にある原則

Slide 6

Slide 6 text

半年前のLODEOの開発 「社内受託開発」 • ”ビジネス側” からの要件通りにつくる • 進捗は 定例会議 で報告する • リリースした機能が使われないこともある

Slide 7

Slide 7 text

• なぜ必要なのか︖ • 価値はあるのか︖ • いつできるのか︖ • つくったものは正しいのか︖ 半年前のLODEOの開発 「社内受託開発」 何もわからない

Slide 8

Slide 8 text

０．「変化」と向き合う ”ビジネス側” との間に現れた 「３つの壁」 第⼀の壁︓＜信頼の壁＞ コミュニケーションの分断 第⼆の壁︓＜透明性の壁＞ 情報の分断 第三の壁︓＜ミッションの壁＞ KPIの分断

Slide 9

Slide 9 text

何を考え、どう⾏動して 「開発側」「ビジネス側」の壁を 乗り越えたのか

Slide 10

Slide 10 text

０． 変化と向き合う

Slide 11

Slide 11 text

⼆年前…

Slide 12

Slide 12 text

ぼく︓ 「スクラムやりましょう︕」

Slide 13

Slide 13 text

ぼく︓「スプリントプランニングやって デイリースクラムやってスプリントレ ビューやってレトロスペクティブをやり ます。スクラムマスターはプロセスに責 任持ってプロダクトオーナーがビジネス に責任持って開発チームはスプリントに コミットします。プロダクトバックログ は優先順位付けされていてスプリントプ ランニングでスプリントバックログにア イテムを積んでタスクボードで管理しま す。受け⼊れ条件がとても⼤事です。

Slide 14

Slide 14 text

メンバー︓「割り込みが多くて計画なんてできない︕」 ぼく︓「割り込みに対応できるだけのスラックをもたせ ましょう。“昨⽇の天気”というものがありまし て... なので⼤丈夫です（ｷﾘｯ」 メンバー︓「スプリント計画が⻑すぎて無駄︕」 ぼく︓「プランニングポーカーを使いましょう。 なれてくれば時間がかからなくなります。 ... なので⼤丈夫です（ｷﾘｯ」 ぼく︓「そうそうスプリントレビューでは どーのこーの...」 ぼく︓「POはどーのこーの...」 ぼく︓「もう⼤丈夫です︕ あとはよろしくおねがいします︕」

Slide 15

Slide 15 text

それから 約⼀年の⽉⽇が流れ... （育休をとってました）

Slide 16

Slide 16 text

復帰後… ぼく︓「あれスクラムやってないんですか︖」 ボス︓「元のやり⽅でいこうってなった」 ぼく︓「」

Slide 17

Slide 17 text

なぜスクラムは 受け⼊れられなかったのか︖

Slide 18

Slide 18 text

⼀度にもたらした 「変化」 が チームのキャパシティを超えていた

Slide 19

Slide 19 text

Tips. 「変化のキャパ」を⾒積もる

Slide 20

Slide 20 text

「変化のキャパシティ」 単位期間あたりでやり⽅の変更を許容できる量 チームのキャパ ＜ 変化の⼤きさ を無理に実⾏しようとすると、望まない結果に..

Slide 21

Slide 21 text

変化のキャパシティを⾒積もる • チームで起こっていることを観察する • 否定的な意⾒があったか︖ • 意⾒を⾔ってない⼈は誰か︖ • 顔⾊はどうか︖ • Fist to Five してみる • ⼀番低い数字を出す⼈は︖ • ⼀番変化に敏感な⼈はだれか︖ チームのキャパは平均では決まらない

Slide 22

Slide 22 text

チームに変化をもたらすには • キャパを増やすのは時間がかかる • 起こす変化を分割して⼩さくする • 例︓ • 今までのやり⽅と並⾏で始める • 例︓ガントチャート ＋ カンバン • スクラムイベントを１つずつ実装する 変化のバッチサイズ （⼀度に起こす変化の量）を下げる

Slide 23

Slide 23 text

“⼤きな変化より、⼩さな 変化のほうが抵抗が少ない。 しかしたくさんの⼩さな変 化が、最終的には⼤きな転 換を⽣み出すのだ“ ーFearless Change アジャイルに効く アイデアを組織に広めるための４８のパターン

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

”ビジネス側” との コミュニケーションを増やしたい

Slide 29

Slide 29 text

「⼩さな変化」を「継続的に」 起こすしくみが必要

Slide 30

Slide 30 text

Tips． 「アクションアイテムつき」 ふりかえり

Slide 31

Slide 31 text

“1. 場を設定する 2. データを収集する 3. アイディアを出す 4. 何をすべきかを決定する 5. レトロスペクティブを終了する ...この構成は 有⽤性が検証されたプロセスだ” ーアジャイルレトロスペクティブズ LODEOではとくに 1. と 4. を重視

Slide 32

Slide 32 text

アナログゲームで ” 場を設定” 発⾔の敷居を下げる 参加を促す

Slide 33

Slide 33 text

シビアな意⾒と カジュアルな意⾒が混在 楽しかったこと/できたことにも向き合う

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

「失敗」に対する恐怖 「失敗したくない」 「会社が/上司が/チームが 失敗を許さない」 「競合がいて、失敗している暇なんてない」 ⾔葉のイメージが悪すぎる

Slide 39

Slide 39 text

Tips． 「失敗」をイメチェンする

Slide 40

Slide 40 text

“成功や失敗ではなく、 学んだことを祝おう。” なぜ失敗が必要なのか ーManaging for Happiness, 「Celebration Grid 」

Slide 41

Slide 41 text

失敗がしたいわけじゃない 「うまくいくかどうかわからないとき、 最も学びの効率が⾼くなる」 ＝ 「やったことがないことは、 そこそこ失敗する可能性がある」 新しいことを始めると、 「失敗」は避けられない

Slide 42

Slide 42 text

「失敗」の意味を揃える 「失敗」から連想されるもの • リリース時の事故、本番バグ • 情報漏えい • 契約で決まっている納期遅延 • etcetc... 取り返しがつかないやつ

Slide 43

Slide 43 text

「失敗」の意味を揃える 僕が思う「失敗」 • CI環境でビルドがコケた • モブプロの交代時間を⻑くしたらすごい疲れた • タスクの粒度を1/2⽇以下で制限＝＞誰もやらなかった • etcetc... ごめんなさいテヘペロ

Slide 44

Slide 44 text

「失敗」の閾値を下げる • ⾃分から率先して「実験」する • 「チョット試してみましょう︕」 • 「わからないんで実験してみましょう︕」 • 期待値をコントロールする • 「いいアイディアだと思うんですけど、やったこ とないのでうまくいかないかも...」 • 失敗した時素直に認め、すぐ謝る︕ • 「ごめんなさい、うまくいきませんでした」 • 「でも、これはうまくないことがわかりました」 笑顔で︕︕

Slide 45

Slide 45 text

「失敗できる」 ＋ 「アクションアイテムつきふりかえり」 ＝ 機能するふりかえり 「信頼の壁」を超えた︕

Slide 46

Slide 46 text

第⼆の壁︓ ＜透明性の壁＞

Slide 47

Slide 47 text

透明性の壁︓ 情報の分断 • どんな案件が動いているのか • どんな営業活動をしているか • 開発は何を作っているのか • 頼んだ仕事はいつ終わるのか 何もわからない︕

Slide 48

Slide 48 text

対策は知ってる。 カンバンをやればよさそう。 だけど...

Slide 49

Slide 49 text

キャパが⾜りなそう...

Slide 50

Slide 50 text

Tips． 「信頼貯⾦」 を使う

Slide 51

Slide 51 text

“信頼貯⾦とは あなたの周囲の⼈が 持っている あなたに対する信頼の蓄積” ーアジャイル開発者の習慣−acts_as_agile / 最終回 信頼貯⾦を増やす

Slide 52

Slide 52 text

キャパが⾜りない それでも変化が必要な時 境界を越境して⼈を巻き込みたい ⼤きな変化を伴う新しいプロセスを導⼊したい 「信頼貯⾦」と相談して、⼀歩踏み出してみる

Slide 53

Slide 53 text

判断基準︓ 信頼残⾼はあるか︖ • 話を聞くに値する成果を残したか︖ • 正直か︖ • 約束を守っているか︖ • ⾃分もチームメンバを信頼しているか︖ • 弱さや⾜りない能⼒を開⽰できるか︖ • 失敗しても関係は壊れないか︖ ⾜りないキャパを残⾼で補う

Slide 54

Slide 54 text

みんながやってることが共通認識に︕ 踏み出した先で⾒つけたもの ビジネス/開発統⼀カンバン

Slide 55

Slide 55 text

信頼貯⾦で ⼀歩踏み出して、 カンバンで 「透明性の壁」を超えた︕

Slide 56

Slide 56 text

…おや︖

Slide 57

Slide 57 text

No content

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

ミッションの壁︓ KPIの分断 • ビジネス側のKPI • 受注件数、売上、粗利 • 開発のKPI • スループット、リードタイム まるで関わりがない︕

Slide 63

Slide 63 text

流れていく案件…

Slide 64

Slide 64 text

関連のない開発…

Slide 65

Slide 65 text

使われない機能…

Slide 66

Slide 66 text

何も変わってない • なぜ必要なのか︖ • 価値はあるのか︖ • いつできるのか︖ • 作ったものは正しいのか︖ ー が、「⾒える化」された

Slide 67

Slide 67 text

⼤丈夫、超えられる。 信頼があって、課題が明確

Slide 68

Slide 68 text

持てるアジャイルを総動員して 壁を超えに⾏く︕

Slide 69

Slide 69 text

なぜ必要なのか︖ • 何が問題/課題なのか︖ • いまはどうしているのか︖ • どう解決すればよさそうか︖ • どれから/どんな順番ですすめるべきか︖ 「なんにもわかってなかった…」 ユーザーストーリーマッピング つくるものへの共通認識の醸成

Slide 70

Slide 70 text

価値はあるのか︖ • そのPBIにどんな価値があるのか︖ • なぜその順番でつくるのか︖ • CD3(Cost of Delay Divided By Duration)による優先 順位付け • バックログポートフォリオ • 機能開発 N%, 負債対応 M%, … バックログリファインメント 価値の基準を合わせる

Slide 71

Slide 71 text

いつできるのか︖ 機能する朝会(昼会) • 全員参加できるよう「昼会」 • カンバンが情報ラジエーターに • 今何をしているのか︖ • 困っていることはないか︖ • 必要に応じて「分科会」 • 納期駆動、案件毎などのコミュニケーション 毎⽇活動を同期する

Slide 72

Slide 72 text

いつできるのか︖ プランニング • カンバンをタイムボックス化 • 少し先の作戦を⽴てやすく • ⾜りない/新しい情報はあるか︖ • 今週は何ができる/何をしてほしい︖ • どうやって今週のゴールを達成する︖ 今週できることを決める

Slide 73

Slide 73 text

つくったものは正しいのか︖ レビュー • 作り終えたらすぐフィードバックをもらう • ビジネス、デザイナー、クライアント… • 作ったものは欲しかったものか︖ • 課題を解決できそうか︖ • ビジネスで使えるものか︖ • もっとよくできるか︖ つくったものを確かめる

Slide 74

Slide 74 text

つくったものは正しいのか︖ ユーザーテスト • 実際に使ってもらうと、何が起こるか︖ • 数字だけではない、リアルなフィードバック • 作ったものの「リアルさ」を感じる • ⾃信と、プロダクトへの愛着 つくったものを確かめる

Slide 75

Slide 75 text

出てくる課題をひとつひとつ、 着実に対応してきた

Slide 76

Slide 76 text

プロダクトの活動を通じて、 僕たちはチームになった。 「ミッションの壁」を超えた︕

Slide 77

Slide 77 text

「ミッションの壁」の先は…︖

Slide 78

Slide 78 text

社会から必要とされて ちゃんと「儲かる」...!!

Slide 79

Slide 79 text

… に向かって、 今⽇も挑戦中︕

Slide 80

Slide 80 text

まとめ 第⼀の壁︓＜信頼の壁＞ 「失敗できる」「ふりかえり」で超えた 第⼆の壁︓＜透明性の壁＞ 「信頼貯⾦」で「カンバン」をやって超えた 第三の壁︓＜ミッションの壁＞ アジャイルで超えていく︕ ０．「変化」と向き合う 「変化のキャパ」を⾒積もる

Slide 81

Slide 81 text

まだまだ旅は始まったばかり。 アジャイルの旅を続けましょう︕

Slide 82

Slide 82 text

ご清聴 ありがとうございました︕