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
870
10分で完全に理解するInvokeDynamic / 10min To Understand InvokeDynamic
martin_lover
0
800
High Performance FastAPI EN
martin_lover
0
1.1k
High Performance FastAPI
martin_lover
17
8.4k
エッセンシャル モブプログラミング 〜実践者が考えるモブの価値,原則,プラクティス〜 / 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
独自ツール開発でスタジオ撮影をDX!「VLS(Virtual LED Studio)」 / dx-studio-vls
cyberagentdevelopers
PRO
1
180
日経電子版におけるリアルタイムレコメンドシステム開発の事例紹介/nikkei-realtime-recommender-system
yng87
1
490
【技術書典17】OpenFOAM(自宅で極める流体解析)2次元円柱まわりの流れ
kamakiri1225
0
210
Aurora_BlueGreenDeploymentsやってみた
tsukasa_ishimaru
1
120
VPC間の接続方法を整理してみた #自治体クラウド勉強会
non97
1
820
使えそうで使われないCloudHSM
maikamibayashi
0
170
新卒1年目が向き合う生成AI事業の開発を加速させる技術選定 / ai-web-launcher
cyberagentdevelopers
PRO
7
1.5k
急成長中のWINTICKETにおける品質と開発スピードと向き合ったQA戦略と今後の展望 / winticket-autify
cyberagentdevelopers
PRO
1
160
サイバーエージェントにおける生成AIのリスキリング施策の取り組み / cyber-ai-reskilling
cyberagentdevelopers
PRO
2
200
Product Engineer Night #6プロダクトエンジニアを育む仕組み・施策
hacomono
PRO
1
460
AIを駆使したゲーム開発戦略: 新設AI組織の取り組み / sge-ai-strategy
cyberagentdevelopers
PRO
1
130
大規模データ基盤チームのオンプレTiDB運用への挑戦 / dpu-tidb
cyberagentdevelopers
PRO
1
110
Featured
See All Featured
Optimising Largest Contentful Paint
csswizardry
33
2.9k
Scaling GitHub
holman
458
140k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
37
1.8k
Measuring & Analyzing Core Web Vitals
bluesmoon
1
39
Statistics for Hackers
jakevdp
796
220k
VelocityConf: Rendering Performance Case Studies
addyosmani
325
24k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.2k
The Pragmatic Product Professional
lauravandoore
31
6.3k
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.1k
The World Runs on Bad Software
bkeepers
PRO
65
11k
Imperfection Machines: The Place of Print at Facebook
scottboms
264
13k
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.「変化」と向き合う 「変化のキャパ」を⾒積もる
まだまだ旅は始まったばかり。 アジャイルの旅を続けましょう︕
ご清聴 ありがとうございました︕