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
210
InvokeDynamic完全に理解した / Completely Understand InvokeDynamic
martin_lover
0
870
10分で完全に理解するInvokeDynamic / 10min To Understand InvokeDynamic
martin_lover
0
810
High Performance FastAPI EN
martin_lover
0
1.1k
High Performance FastAPI
martin_lover
17
8.5k
エッセンシャル モブプログラミング 〜実践者が考えるモブの価値,原則,プラクティス〜 / Essential Mob Programming
martin_lover
15
7.6k
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
リンクアンドモチベーション ソフトウェアエンジニア向け紹介資料 / Introduction to Link and Motivation for Software Engineers
lmi
4
300k
100 名超が参加した日経グループ横断の競技型 AWS 学習イベント「Nikkei Group AWS GameDay」の紹介/mediajaws202411
nikkei_engineer_recruiting
1
170
飲食店データの分析事例とそれを支えるデータ基盤
kimujun
0
160
テストコード品質を高めるためにMutation Testingライブラリ・Strykerを実戦導入してみた話
ysknsid25
7
2.7k
New Relicを活用したSREの最初のステップ / NRUG OKINAWA VOL.3
isaoshimizu
3
630
【Pycon mini 東海 2024】Google Colaboratoryで試すVLM
kazuhitotakahashi
2
540
Making your applications cross-environment - OSCG 2024 NA
salaboy
0
190
10XにおけるData Contractの導入について: Data Contract事例共有会
10xinc
6
660
安心してください、日本語使えますよ―Ubuntu日本語Remix提供休止に寄せて― 2024-11-17
nobutomurata
1
1k
FlutterアプリにおけるSLI/SLOを用いたユーザー体験の可視化と計測基盤構築
ostk0069
0
100
エンジニア人生の拡張性を高める 「探索型キャリア設計」の提案
tenshoku_draft
1
130
『Firebase Dynamic Links終了に備える』 FlutterアプリでのAdjust導入とDeeplink最適化
techiro
0
130
Featured
See All Featured
4 Signs Your Business is Dying
shpigford
180
21k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
48k
What's in a price? How to price your products and services
michaelherold
243
12k
The World Runs on Bad Software
bkeepers
PRO
65
11k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
Why You Should Never Use an ORM
jnunemaker
PRO
54
9.1k
Code Review Best Practice
trishagee
64
17k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
126
18k
How to Ace a Technical Interview
jacobian
276
23k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
31
2.7k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
26
1.4k
Building Applications with DynamoDB
mza
90
6.1k
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.「変化」と向き合う 「変化のキャパ」を⾒積もる
まだまだ旅は始まったばかり。 アジャイルの旅を続けましょう︕
ご清聴 ありがとうございました︕