Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Agile Japan 2019 開発側ビジネス側の先へ/Agile Japan 2019 B...
Search
Ikuo Suyama
September 04, 2019
Technology
1
990
Agile Japan 2019 開発側ビジネス側の先へ/Agile Japan 2019 Beyond the business people and developer
※ AgileJapan2019再演
AgileJapan2019渋谷サテライトでお話させていただいた内容です。
Ikuo Suyama
September 04, 2019
Tweet
Share
More Decks by Ikuo Suyama
See All by Ikuo Suyama
Dive into JVM JIT Compiler
martin_lover
2
200
InvokeDynamic完全に理解した / Completely Understand InvokeDynamic
martin_lover
0
850
10分で完全に理解するInvokeDynamic / 10min To Understand InvokeDynamic
martin_lover
0
800
High Performance FastAPI EN
martin_lover
0
1.1k
High Performance FastAPI
martin_lover
16
8.3k
エッセンシャル モブプログラミング 〜実践者が考えるモブの価値,原則,プラクティス〜 / Essential Mob Programming
martin_lover
15
7.5k
NoEstimates Scrum En
martin_lover
0
1.2k
見積りしないスクラム/No Estimates Scrum JP
martin_lover
23
32k
正しくつくる、みんなでつくる。/Do things right with team
martin_lover
1
2.5k
Other Decks in Technology
See All in Technology
分析者起点の企画を成功させた連携面の工夫
lycorptech_jp
PRO
1
230
AI時代のアジャイル開発(XP祭り2024版) / Agile Development in the AI Era in XPJUG
takaking22
13
3.5k
【swonet.conf_】NOCメンバーが語るSTMの実態!! ~ShowNetから若者への贈り物~
shownet
PRO
0
230
SQLによるオブザーバビリティの進化とClickHouseの実力
mikimatsumoto
0
150
普通の Web エンジニアのための様相論理入門 #yapcjapan / YAPC Hakodate 2024
ytaka23
3
600
Sansanにおける全社横断データ分析基盤の挑戦と未来 / Challenges and Future of Cross-Organizational Data Analytics Platform at Sansan
sansan_randd
2
310
Perlで始めるeBPF: 自作Loaderの作り方 / Getting started with eBPF in Perl_How to create your own Loader
takehaya
1
240
Pythonを活用したLLMによる構造的データ生成の手法と実践
brainpadpr
3
230
クレジットカードを製造する技術
yutadayo
74
38k
kube-vipとkube-proxy置き換えCiliumを積んだ究極のK3sクラスタを建てる
logica0419
4
190
【shownet.conf_】AI技術とUX監視の応用でShowNetの基盤を支えるモニタリングシステム
shownet
PRO
0
280
軽いノリで"自動化"に取り組んではいけないという話
tetsuyaooooo
1
270
Featured
See All Featured
Creatively Recalculating Your Daily Design Routine
revolveconf
217
12k
Rebuilding a faster, lazier Slack
samanthasiow
79
8.6k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
44
2k
Designing the Hi-DPI Web
ddemaree
279
34k
How to train your dragon (web standard)
notwaldorf
87
5.6k
Product Roadmaps are Hard
iamctodd
PRO
48
10k
Rails Girls Zürich Keynote
gr2m
93
13k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
246
1.3M
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
1
240
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
23
1.7k
Web Components: a chance to create the future
zenorocha
310
42k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
279
13k
Transcript
”開発側” ”ビジネス側” の先へ 〜アジャイルで超えた3つの壁〜 完 全 版
陶⼭ 育男 Ikuo Suyama @martin_lover_se ⾒習い “Agile Developer” @CyberAgent AI
tech Studio New!
Mob Mentality Show with Chris, Austin, 川⼝さん, 永⽥さん, 吉 ⽥さん
omoiyari.fm#48 with 横道さん, 三浦さん, 川 ⼝さん XP祭り2019 Coming soon!! 「全部⾒せますモブプロジャー ニー︕ 」 ⾒てね︕
今⽇お話すること とあるB2Bプロダクトでのアジャイル実践 • “開発側” “ビジネス側” が分断された状態から、ア ジャイルなチームになっていった過程 • 変化の過程で現れた「3つの壁」 •
壁に直⾯した時考えたこと、実践したこと
「ビジネス側の⼈と開発者は、 プロジェクトを通して ⽇々⼀緒に働かなければなりません。」 ーアジャイル宣⾔の背後にある原則
半年前のLODEOの開発 「社内受託開発」 • ”ビジネス側” からの要件通りにつくる • 進捗は 定例会議 で報告する •
リリースした機能が使われないこともある
• なぜ必要なのか︖ • 価値はあるのか︖ • いつできるのか︖ • つくったものは正しいのか︖ 半年前のLODEOの開発 「社内受託開発」
何もわからない
0.「変化」と向き合う ”ビジネス側” との間に現れた 「3つの壁」 第⼀の壁︓<信頼の壁> コミュニケーションの分断 第⼆の壁︓<透明性の壁> 情報の分断 第三の壁︓<ミッションの壁> KPIの分断
何を考え、どう⾏動して 「開発側」「ビジネス側」の壁を 乗り越えたのか
0. 変化と向き合う
⼆年前…
ぼく︓ 「スクラムやりましょう︕」
ぼく︓「スプリントプランニングやって デイリースクラムやってスプリントレ ビューやってレトロスペクティブをやり ます。スクラムマスターはプロセスに責 任持ってプロダクトオーナーがビジネス に責任持って開発チームはスプリントに コミットします。プロダクトバックログ は優先順位付けされていてスプリントプ ランニングでスプリントバックログにア イテムを積んでタスクボードで管理しま
す。受け⼊れ条件がとても⼤事です。
メンバー︓「割り込みが多くて計画なんてできない︕」 ぼく︓「割り込みに対応できるだけのスラックをもたせ ましょう。“昨⽇の天気”というものがありまし て... なので⼤丈夫です(キリッ」 メンバー︓「スプリント計画が⻑すぎて無駄︕」 ぼく︓「プランニングポーカーを使いましょう。 なれてくれば時間がかからなくなります。 ... なので⼤丈夫です(キリッ」
ぼく︓「そうそうスプリントレビューでは どーのこーの...」 ぼく︓「POはどーのこーの...」 ぼく︓「もう⼤丈夫です︕ あとはよろしくおねがいします︕」
それから 約⼀年の⽉⽇が流れ... (育休をとってました)
復帰後… ぼく︓「あれスクラムやってないんですか︖」 ボス︓「元のやり⽅でいこうってなった」 ぼく︓「」
なぜスクラムは 受け⼊れられなかったのか︖
⼀度にもたらした 「変化」 が チームのキャパシティを超えていた
Tips. 「変化のキャパ」を⾒積もる
「変化のキャパシティ」 単位期間あたりでやり⽅の変更を許容できる量 チームのキャパ < 変化の⼤きさ を無理に実⾏しようとすると、望まない結果に..
変化のキャパシティを⾒積もる • チームで起こっていることを観察する • 否定的な意⾒があったか︖ • 意⾒を⾔ってない⼈は誰か︖ • 顔⾊はどうか︖ •
Fist to Five してみる • ⼀番低い数字を出す⼈は︖ • ⼀番変化に敏感な⼈はだれか︖ チームのキャパは平均では決まらない
チームに変化をもたらすには • キャパを増やすのは時間がかかる • 起こす変化を分割して⼩さくする • 例︓ • 今までのやり⽅と並⾏で始める •
例︓ガントチャート + カンバン • スクラムイベントを1つずつ実装する 変化のバッチサイズ (⼀度に起こす変化の量)を下げる
“⼤きな変化より、⼩さな 変化のほうが抵抗が少ない。 しかしたくさんの⼩さな変 化が、最終的には⼤きな転 換を⽣み出すのだ“ ーFearless Change アジャイルに効く アイデアを組織に広めるための48のパターン
復帰から半年… 「モブプロ︕」 「カンバン︕」 「ノーエスティメート︕︕」 「変化のキャパ」の意識で ”開発側” のアジャイル導⼊が うまく回ってきた
“ビジネス側” の⼈と⼀緒に働きたい
第⼀の壁︓ <信頼の壁>
信頼の壁︓ コミュニケーションの分断 • 暗黙の了解 • 「エンジニアに直接依頼しない」 • 固定概念 • 「ビジネスは開発プラクティスをやってくれない」
コミュニケーションがない=信頼がない
”ビジネス側” との コミュニケーションを増やしたい
「⼩さな変化」を「継続的に」 起こすしくみが必要
Tips. 「アクションアイテムつき」 ふりかえり
“1. 場を設定する 2. データを収集する 3. アイディアを出す 4. 何をすべきかを決定する 5. レトロスペクティブを終了する
...この構成は 有⽤性が検証されたプロセスだ” ーアジャイルレトロスペクティブズ LODEOではとくに 1. と 4. を重視
アナログゲームで ” 場を設定” 発⾔の敷居を下げる 参加を促す
シビアな意⾒と カジュアルな意⾒が混在 楽しかったこと/できたことにも向き合う
「次の週やること」を 必ず⼀つ決める 他はリストには積まない
「ふりかえり」= コミュニケーションの⼟台 • プロダクトで起こっていることを定期的に話しあう • お互いに困っていること/興味があることを知る • ギャップを埋めるためにできることを少しずつ試す お互いのことを知り、少しずつ信頼が⽣まれる
ふりかえりにより コミュニケーションが増え、 どんどんチャレンジがしたくなる
... 時々、「失敗」もする
「失敗」に対する恐怖 「失敗したくない」 「会社が/上司が/チームが 失敗を許さない」 「競合がいて、失敗している暇なんてない」 ⾔葉のイメージが悪すぎる
Tips. 「失敗」をイメチェンする
“成功や失敗ではなく、 学んだことを祝おう。” なぜ失敗が必要なのか ーManaging for Happiness, 「Celebration Grid 」
失敗がしたいわけじゃない 「うまくいくかどうかわからないとき、 最も学びの効率が⾼くなる」 = 「やったことがないことは、 そこそこ失敗する可能性がある」 新しいことを始めると、 「失敗」は避けられない
「失敗」の意味を揃える 「失敗」から連想されるもの • リリース時の事故、本番バグ • 情報漏えい • 契約で決まっている納期遅延 • etcetc...
取り返しがつかないやつ
「失敗」の意味を揃える 僕が思う「失敗」 • CI環境でビルドがコケた • モブプロの交代時間を⻑くしたらすごい疲れた • タスクの粒度を1/2⽇以下で制限=>誰もやらなかった • etcetc...
ごめんなさいテヘペロ
「失敗」の閾値を下げる • ⾃分から率先して「実験」する • 「チョット試してみましょう︕」 • 「わからないんで実験してみましょう︕」 • 期待値をコントロールする •
「いいアイディアだと思うんですけど、やったこ とないのでうまくいかないかも...」 • 失敗した時素直に認め、すぐ謝る︕ • 「ごめんなさい、うまくいきませんでした」 • 「でも、これはうまくないことがわかりました」 笑顔で︕︕
「失敗できる」 + 「アクションアイテムつきふりかえり」 = 機能するふりかえり 「信頼の壁」を超えた︕
第⼆の壁︓ <透明性の壁>
透明性の壁︓ 情報の分断 • どんな案件が動いているのか • どんな営業活動をしているか • 開発は何を作っているのか • 頼んだ仕事はいつ終わるのか
何もわからない︕
対策は知ってる。 カンバンをやればよさそう。 だけど...
キャパが⾜りなそう...
Tips. 「信頼貯⾦」 を使う
“信頼貯⾦とは あなたの周囲の⼈が 持っている あなたに対する信頼の蓄積” ーアジャイル開発者の習慣−acts_as_agile / 最終回 信頼貯⾦を増やす
キャパが⾜りない それでも変化が必要な時 境界を越境して⼈を巻き込みたい ⼤きな変化を伴う新しいプロセスを導⼊したい 「信頼貯⾦」と相談して、⼀歩踏み出してみる
判断基準︓ 信頼残⾼はあるか︖ • 話を聞くに値する成果を残したか︖ • 正直か︖ • 約束を守っているか︖ • ⾃分もチームメンバを信頼しているか︖
• 弱さや⾜りない能⼒を開⽰できるか︖ • 失敗しても関係は壊れないか︖ ⾜りないキャパを残⾼で補う
みんながやってることが共通認識に︕ 踏み出した先で⾒つけたもの ビジネス/開発統⼀カンバン
信頼貯⾦で ⼀歩踏み出して、 カンバンで 「透明性の壁」を超えた︕
…おや︖
None
開発って、これだけしかないんだ…
これまでの⾃分の関⼼︓ 「開発チームのプロセスを いかに改善するか︖」
突きつけられた現実︓ 「開発チームのことだけ⾒ていても インパクトは殆ど無い」
第三の壁︓ <ミッションの壁>
ミッションの壁︓ KPIの分断 • ビジネス側のKPI • 受注件数、売上、粗利 • 開発のKPI • スループット、リードタイム
まるで関わりがない︕
流れていく案件…
関連のない開発…
使われない機能…
何も変わってない • なぜ必要なのか︖ • 価値はあるのか︖ • いつできるのか︖ • 作ったものは正しいのか︖ ー
が、「⾒える化」された
⼤丈夫、超えられる。 信頼があって、課題が明確
持てるアジャイルを総動員して 壁を超えに⾏く︕
なぜ必要なのか︖ • 何が問題/課題なのか︖ • いまはどうしているのか︖ • どう解決すればよさそうか︖ • どれから/どんな順番ですすめるべきか︖ 「なんにもわかってなかった…」
ユーザーストーリーマッピング つくるものへの共通認識の醸成
価値はあるのか︖ • そのPBIにどんな価値があるのか︖ • なぜその順番でつくるのか︖ • CD3(Cost of Delay Divided
By Duration)による優先 順位付け • バックログポートフォリオ • 機能開発 N%, 負債対応 M%, … バックログリファインメント 価値の基準を合わせる
いつできるのか︖ 機能する朝会(昼会) • 全員参加できるよう「昼会」 • カンバンが情報ラジエーターに • 今何をしているのか︖ • 困っていることはないか︖
• 必要に応じて「分科会」 • 納期駆動、案件毎などのコミュニケーション 毎⽇活動を同期する
いつできるのか︖ プランニング • カンバンをタイムボックス化 • 少し先の作戦を⽴てやすく • ⾜りない/新しい情報はあるか︖ • 今週は何ができる/何をしてほしい︖
• どうやって今週のゴールを達成する︖ 今週できることを決める
つくったものは正しいのか︖ レビュー • 作り終えたらすぐフィードバックをもらう • ビジネス、デザイナー、クライアント… • 作ったものは欲しかったものか︖ • 課題を解決できそうか︖
• ビジネスで使えるものか︖ • もっとよくできるか︖ つくったものを確かめる
つくったものは正しいのか︖ ユーザーテスト • 実際に使ってもらうと、何が起こるか︖ • 数字だけではない、リアルなフィードバック • 作ったものの「リアルさ」を感じる • ⾃信と、プロダクトへの愛着
つくったものを確かめる
出てくる課題をひとつひとつ、 着実に対応してきた
プロダクトの活動を通じて、 僕たちはチームになった。 「ミッションの壁」を超えた︕
「ミッションの壁」の先は…︖
社会から必要とされて ちゃんと「儲かる」...!!
… に向かって、 今⽇も挑戦中︕
まとめ 第⼀の壁︓<信頼の壁> 「失敗できる」「ふりかえり」で超えた 第⼆の壁︓<透明性の壁> 「信頼貯⾦」で「カンバン」をやって超えた 第三の壁︓<ミッションの壁> アジャイルで超えていく︕ 0.「変化」と向き合う 「変化のキャパ」を⾒積もる
まだまだ旅は始まったばかり。 アジャイルの旅を続けましょう︕
ご清聴 ありがとうございました︕