Agile Japan 2019 開発側ビジネス側の先へ/Agile Japan 2019 Beyond the business people and developer

※ AgileJapan2019再演
AgileJapan2019渋谷サテライトでお話させていただいた内容です。

1. ”開発側” ”ビジネス側” の先へ 〜アジャイルで超えた３つの壁〜 完 全 版
2. 陶⼭ 育男 Ikuo Suyama @martin_lover_se ⾒習い “Agile Developer” @CyberAgent AI tech Studio New!
3. Mob Mentality Show with Chris, Austin, 川⼝さん, 永⽥さん, 吉 ⽥さん omoiyari.fm#48 with 横道さん, 三浦さん, 川 ⼝さん XP祭り2019 Coming soon!! 「全部⾒せますモブプロジャー ニー︕ 」 ⾒てね︕
4. 今⽇お話すること とあるB2Bプロダクトでのアジャイル実践 • “開発側” “ビジネス側” が分断された状態から、ア ジャイルなチームになっていった過程 • 変化の過程で現れた「３つの壁」 • 壁に直⾯した時考えたこと、実践したこと
5. 「ビジネス側の⼈と開発者は、 プロジェクトを通して ⽇々⼀緒に働かなければなりません。」 ーアジャイル宣⾔の背後にある原則
6. 半年前のLODEOの開発 「社内受託開発」 • ”ビジネス側” からの要件通りにつくる • 進捗は 定例会議 で報告する • リリースした機能が使われないこともある
7. • なぜ必要なのか︖ • 価値はあるのか︖ • いつできるのか︖ • つくったものは正しいのか︖ 半年前のLODEOの開発 「社内受託開発」 何もわからない
8. ０．「変化」と向き合う ”ビジネス側” との間に現れた 「３つの壁」 第⼀の壁︓＜信頼の壁＞ コミュニケーションの分断 第⼆の壁︓＜透明性の壁＞ 情報の分断 第三の壁︓＜ミッションの壁＞ KPIの分断
9. 何を考え、どう⾏動して 「開発側」「ビジネス側」の壁を 乗り越えたのか
10. ０． 変化と向き合う
11. ⼆年前…
12. ぼく︓ 「スクラムやりましょう︕」
13. ぼく︓「スプリントプランニングやって デイリースクラムやってスプリントレ ビューやってレトロスペクティブをやり ます。スクラムマスターはプロセスに責 任持ってプロダクトオーナーがビジネス に責任持って開発チームはスプリントに コミットします。プロダクトバックログ は優先順位付けされていてスプリントプ ランニングでスプリントバックログにア イテムを積んでタスクボードで管理しま す。受け⼊れ条件がとても⼤事です。
14. メンバー︓「割り込みが多くて計画なんてできない︕」 ぼく︓「割り込みに対応できるだけのスラックをもたせ ましょう。“昨⽇の天気”というものがありまし て... なので⼤丈夫です（ｷﾘｯ」 メンバー︓「スプリント計画が⻑すぎて無駄︕」 ぼく︓「プランニングポーカーを使いましょう。 なれてくれば時間がかからなくなります。 ... なので⼤丈夫です（ｷﾘｯ」 ぼく︓「そうそうスプリントレビューでは どーのこーの...」 ぼく︓「POはどーのこーの...」 ぼく︓「もう⼤丈夫です︕ あとはよろしくおねがいします︕」
15. それから 約⼀年の⽉⽇が流れ... （育休をとってました）
16. 復帰後… ぼく︓「あれスクラムやってないんですか︖」 ボス︓「元のやり⽅でいこうってなった」 ぼく︓「」
17. なぜスクラムは 受け⼊れられなかったのか︖
18. ⼀度にもたらした 「変化」 が チームのキャパシティを超えていた
19. Tips. 「変化のキャパ」を⾒積もる
20. 「変化のキャパシティ」 単位期間あたりでやり⽅の変更を許容できる量 チームのキャパ ＜ 変化の⼤きさ を無理に実⾏しようとすると、望まない結果に..
21. 変化のキャパシティを⾒積もる • チームで起こっていることを観察する • 否定的な意⾒があったか︖ • 意⾒を⾔ってない⼈は誰か︖ • 顔⾊はどうか︖ • Fist to Five してみる • ⼀番低い数字を出す⼈は︖ • ⼀番変化に敏感な⼈はだれか︖ チームのキャパは平均では決まらない
22. チームに変化をもたらすには • キャパを増やすのは時間がかかる • 起こす変化を分割して⼩さくする • 例︓ • 今までのやり⽅と並⾏で始める • 例︓ガントチャート ＋ カンバン • スクラムイベントを１つずつ実装する 変化のバッチサイズ （⼀度に起こす変化の量）を下げる
23. “⼤きな変化より、⼩さな 変化のほうが抵抗が少ない。 しかしたくさんの⼩さな変 化が、最終的には⼤きな転 換を⽣み出すのだ“ ーFearless Change アジャイルに効く アイデアを組織に広めるための４８のパターン
24. 復帰から半年… 「モブプロ︕」 「カンバン︕」 「ノーエスティメート︕︕」 「変化のキャパ」の意識で ”開発側” のアジャイル導⼊が うまく回ってきた
25. “ビジネス側” の⼈と⼀緒に働きたい
26. 第⼀の壁︓ ＜信頼の壁＞
27. 信頼の壁︓ コミュニケーションの分断 • 暗黙の了解 • 「エンジニアに直接依頼しない」 • 固定概念 • 「ビジネスは開発プラクティスをやってくれない」 コミュニケーションがない＝信頼がない
28. ”ビジネス側” との コミュニケーションを増やしたい
29. 「⼩さな変化」を「継続的に」 起こすしくみが必要
30. Tips． 「アクションアイテムつき」 ふりかえり
31. “1. 場を設定する 2. データを収集する 3. アイディアを出す 4. 何をすべきかを決定する 5. レトロスペクティブを終了する ...この構成は 有⽤性が検証されたプロセスだ” ーアジャイルレトロスペクティブズ LODEOではとくに 1. と 4. を重視
32. アナログゲームで ” 場を設定” 発⾔の敷居を下げる 参加を促す
33. シビアな意⾒と カジュアルな意⾒が混在 楽しかったこと/できたことにも向き合う
34. 「次の週やること」を 必ず⼀つ決める 他はリストには積まない
35. 「ふりかえり」＝ コミュニケーションの⼟台 • プロダクトで起こっていることを定期的に話しあう • お互いに困っていること/興味があることを知る • ギャップを埋めるためにできることを少しずつ試す お互いのことを知り、少しずつ信頼が⽣まれる
36. ふりかえりにより コミュニケーションが増え、 どんどんチャレンジがしたくなる
37. ... 時々、「失敗」もする
38. 「失敗」に対する恐怖 「失敗したくない」 「会社が/上司が/チームが 失敗を許さない」 「競合がいて、失敗している暇なんてない」 ⾔葉のイメージが悪すぎる
39. Tips． 「失敗」をイメチェンする
40. “成功や失敗ではなく、 学んだことを祝おう。” なぜ失敗が必要なのか ーManaging for Happiness, 「Celebration Grid 」
41. 失敗がしたいわけじゃない 「うまくいくかどうかわからないとき、 最も学びの効率が⾼くなる」 ＝ 「やったことがないことは、 そこそこ失敗する可能性がある」 新しいことを始めると、 「失敗」は避けられない
42. 「失敗」の意味を揃える 「失敗」から連想されるもの • リリース時の事故、本番バグ • 情報漏えい • 契約で決まっている納期遅延 • etcetc... 取り返しがつかないやつ
43. 「失敗」の意味を揃える 僕が思う「失敗」 • CI環境でビルドがコケた • モブプロの交代時間を⻑くしたらすごい疲れた • タスクの粒度を1/2⽇以下で制限＝＞誰もやらなかった • etcetc... ごめんなさいテヘペロ
44. 「失敗」の閾値を下げる • ⾃分から率先して「実験」する • 「チョット試してみましょう︕」 • 「わからないんで実験してみましょう︕」 • 期待値をコントロールする • 「いいアイディアだと思うんですけど、やったこ とないのでうまくいかないかも...」 • 失敗した時素直に認め、すぐ謝る︕ • 「ごめんなさい、うまくいきませんでした」 • 「でも、これはうまくないことがわかりました」 笑顔で︕︕
45. 「失敗できる」 ＋ 「アクションアイテムつきふりかえり」 ＝ 機能するふりかえり 「信頼の壁」を超えた︕
46. 第⼆の壁︓ ＜透明性の壁＞
47. 透明性の壁︓ 情報の分断 • どんな案件が動いているのか • どんな営業活動をしているか • 開発は何を作っているのか • 頼んだ仕事はいつ終わるのか 何もわからない︕
48. 対策は知ってる。 カンバンをやればよさそう。 だけど...
49. キャパが⾜りなそう...
50. Tips． 「信頼貯⾦」 を使う
51. “信頼貯⾦とは あなたの周囲の⼈が 持っている あなたに対する信頼の蓄積” ーアジャイル開発者の習慣−acts_as_agile / 最終回 信頼貯⾦を増やす
52. キャパが⾜りない それでも変化が必要な時 境界を越境して⼈を巻き込みたい ⼤きな変化を伴う新しいプロセスを導⼊したい 「信頼貯⾦」と相談して、⼀歩踏み出してみる
53. 判断基準︓ 信頼残⾼はあるか︖ • 話を聞くに値する成果を残したか︖ • 正直か︖ • 約束を守っているか︖ • ⾃分もチームメンバを信頼しているか︖ • 弱さや⾜りない能⼒を開⽰できるか︖ • 失敗しても関係は壊れないか︖ ⾜りないキャパを残⾼で補う
54. みんながやってることが共通認識に︕ 踏み出した先で⾒つけたもの ビジネス/開発統⼀カンバン
55. 信頼貯⾦で ⼀歩踏み出して、 カンバンで 「透明性の壁」を超えた︕
56. …おや︖
58. 開発って、これだけしかないんだ…
59. これまでの⾃分の関⼼︓ 「開発チームのプロセスを いかに改善するか︖」
60. 突きつけられた現実︓ 「開発チームのことだけ⾒ていても インパクトは殆ど無い」
61. 第三の壁︓ ＜ミッションの壁＞
62. ミッションの壁︓ KPIの分断 • ビジネス側のKPI • 受注件数、売上、粗利 • 開発のKPI • スループット、リードタイム まるで関わりがない︕
63. 流れていく案件…
64. 関連のない開発…
65. 使われない機能…
66. 何も変わってない • なぜ必要なのか︖ • 価値はあるのか︖ • いつできるのか︖ • 作ったものは正しいのか︖ ー が、「⾒える化」された
67. ⼤丈夫、超えられる。 信頼があって、課題が明確
68. 持てるアジャイルを総動員して 壁を超えに⾏く︕
69. なぜ必要なのか︖ • 何が問題/課題なのか︖ • いまはどうしているのか︖ • どう解決すればよさそうか︖ • どれから/どんな順番ですすめるべきか︖ 「なんにもわかってなかった…」 ユーザーストーリーマッピング つくるものへの共通認識の醸成
70. 価値はあるのか︖ • そのPBIにどんな価値があるのか︖ • なぜその順番でつくるのか︖ • CD3(Cost of Delay Divided By Duration)による優先 順位付け • バックログポートフォリオ • 機能開発 N%, 負債対応 M%, … バックログリファインメント 価値の基準を合わせる
71. いつできるのか︖ 機能する朝会(昼会) • 全員参加できるよう「昼会」 • カンバンが情報ラジエーターに • 今何をしているのか︖ • 困っていることはないか︖ • 必要に応じて「分科会」 • 納期駆動、案件毎などのコミュニケーション 毎⽇活動を同期する
72. いつできるのか︖ プランニング • カンバンをタイムボックス化 • 少し先の作戦を⽴てやすく • ⾜りない/新しい情報はあるか︖ • 今週は何ができる/何をしてほしい︖ • どうやって今週のゴールを達成する︖ 今週できることを決める
73. つくったものは正しいのか︖ レビュー • 作り終えたらすぐフィードバックをもらう • ビジネス、デザイナー、クライアント… • 作ったものは欲しかったものか︖ • 課題を解決できそうか︖ • ビジネスで使えるものか︖ • もっとよくできるか︖ つくったものを確かめる
74. つくったものは正しいのか︖ ユーザーテスト • 実際に使ってもらうと、何が起こるか︖ • 数字だけではない、リアルなフィードバック • 作ったものの「リアルさ」を感じる • ⾃信と、プロダクトへの愛着 つくったものを確かめる
75. 出てくる課題をひとつひとつ、 着実に対応してきた
76. プロダクトの活動を通じて、 僕たちはチームになった。 「ミッションの壁」を超えた︕
77. 「ミッションの壁」の先は…︖
78. 社会から必要とされて ちゃんと「儲かる」...!!
79. … に向かって、 今⽇も挑戦中︕
80. まとめ 第⼀の壁︓＜信頼の壁＞ 「失敗できる」「ふりかえり」で超えた 第⼆の壁︓＜透明性の壁＞ 「信頼貯⾦」で「カンバン」をやって超えた 第三の壁︓＜ミッションの壁＞ アジャイルで超えていく︕ ０．「変化」と向き合う 「変化のキャパ」を⾒積もる
81. まだまだ旅は始まったばかり。 アジャイルの旅を続けましょう︕
82. ご清聴 ありがとうございました︕