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 '12 Agileな開発からAgileな組織へ
Search
Ryutaro YOSHIBA
April 12, 2012
Technology
3
400
Agile Japan '12 Agileな開発からAgileな組織へ
2012年3月に実施されたAgile Japanメイン会場でのセッション資料です。質問等は@ryuzeeにお願いします。
http://www.ryuzee.com/
Ryutaro YOSHIBA
April 12, 2012
Tweet
Share
More Decks by Ryutaro YOSHIBA
See All by Ryutaro YOSHIBA
Vagrant (+Amazon EC2)
ryuzee
16
6.3k
CakePHP+Jenkinsによるアジャイル開発 #phpmatsuri
ryuzee
34
14k
自動テストvs手動テスト
ryuzee
1
2k
Agileってなんだっけ?
ryuzee
2
160
20110127_devloveテストの話.pdf
ryuzee
0
120
Doneの定義虎の巻
ryuzee
2
2.6k
スプリントバーンダウンチャート虎の巻 #scrumdo
ryuzee
1
450
アジャイルコーチで学んだ30+αのこと
ryuzee
2
210
ワンクリックデプロイ101
ryuzee
2
310
Other Decks in Technology
See All in Technology
社外コミュニティで学び社内に活かす共に学ぶプロジェクトの実践/backlogworld2024
nishiuma
0
250
私なりのAIのご紹介 [2024年版]
qt_luigi
1
120
DevOps視点でAWS re:invent2024の新サービス・アプデを振り返ってみた
oshanqq
0
180
バクラクのドキュメント解析技術と実データにおける課題 / layerx-ccc-winter-2024
shimacos
2
1k
オプトインカメラ:UWB測位を応用したオプトイン型のカメラ計測
matthewlujp
0
170
Amazon Kendra GenAI Index 登場でどう変わる? 評価から学ぶ最適なRAG構成
naoki_0531
0
100
C++26 エラー性動作
faithandbrave
2
690
権威ドキュメントで振り返る2024 #年忘れセキュリティ2024
hirotomotaguchi
2
730
継続的にアウトカムを生み出し ビジネスにつなげる、 戦略と運営に対するタイミーのQUEST(探求)
zigorou
0
520
How to be an AWS Community Builder | 君もAWS Community Builderになろう!〜2024 冬 CB募集直前対策編?!〜
coosuke
PRO
2
2.8k
TSKaigi 2024 の登壇から広がったコミュニティ活動について
tsukuha
0
160
社内イベント管理システムを1週間でAKSからACAに移行した話し
shingo_kawahara
0
180
Featured
See All Featured
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
59k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
38
1.9k
We Have a Design System, Now What?
morganepeng
51
7.3k
Six Lessons from altMBA
skipperchong
27
3.5k
A Tale of Four Properties
chriscoyier
157
23k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
191
16k
Site-Speed That Sticks
csswizardry
2
190
Agile that works and the tools we love
rasmusluckow
328
21k
Building Flexible Design Systems
yeseniaperezcruz
327
38k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
45
2.2k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
251
21k
Designing for Performance
lara
604
68k
Transcript
アジャイルな開発から アジャイルな組織へ 〜~継続的に価値を届けるために進むべき道〜~ h"p://bit.ly/wYu/U 2012/3/16 Agile Japan 2012 Ryutaro YOSHIBA
吉羽龍太郎 アジャイルコーチ http://www.ryuzee.com/
http://www.ryuzee.com/
@ryuzee
None
SSccrruumm BBoooott CCaammpp
h"p://bit.ly/zp22Aw 大阪開催決定! 66//1166((土))
今年も1100 月後半頃に Scrum Gathering Tokyo を開催予定
本⽇日の資料料は後⽇日公開します http://slideshare.net/ryuzee
よろしく お願いします
アジェンダ ü 自己紹介 (55分) ü 企業のおかれた状況 (1155分) ü AAggiilleeな開発 (2255分) ü AAggiilleeな組織 (2255分) ü まとめ・質疑応答
(1100分) ※あくまで予定です…
http://bit.ly/vj0b0v
11.. 企業のおかれた状況 http://bit.ly/ptKnqR
ビジネスをとりまく 環境の変化
IITT投資は業務効率化 から戦略実現へ
以前の競争 http://bit.ly/rioQDZ
現在の競争 競争の速度の変化
迅速な 意思決定 が必要 http://bit.ly/pccwAN
意思決定をもと に素早く 具現化する必要 http://bit.ly/r1ziWL
ビジネスモデルの賞味期限が短縮
変化への対応 “事前に綿密” にたてた計画を “長期間遵守” して大丈夫なのか?
変化への対応 “変化が起こる” ことを前提に “頻繁に軌道修正” することが必要 http://bit.ly/oX9ImQ
変化に対応できなければ マーケットから 見捨てられる
価値がなくなれば滅びる http://bit.ly/qJg8EX
None
顧客が説明した要件 顧客が本当に必要 だった物
価値を 高めない 各種現象や 結果を ムダと呼ぶ
ü 作り過ぎのムダ ü 手待ちのムダ ü 運搬のムダ ü 加工のムダ ü 在庫のムダ ü 動作のムダ ü 不良をつくるムダ
システムの機能の利利⽤用割合 4455 %% 1199 %% 1166 %% 1133 %% 77
%% Standishの2000年年の調査より いつも使う よく使う たまに使う ほとんど使わない まったく使わない
6644%% の機能は、使われない http://bit.ly/olku51
顧客が説明した要件 顧客が本当に必要 だった物
我々が解 決すべき 問題は何 なのか? http://bit.ly/qgox0e
h"p://bit.ly/x6Mznh
マーケットに製品 を早期に投入�して 投資を回収し利益 に結びつける必要 性がある
フィーチャー駆動・ スコープ駆動から価 値駆動へ。ビジネス 価値を評価せよ
22.. AAggiilleeな開発
AAggiilleeな開発 してますか? http://bit.ly/shZMnK
WWFFは長編映画 http://bit.ly/z0f0eo
AAggiilleeはTTVVドラマ http://bit.ly/wlJQzm
計画づくりの頻度度と 計画の粒粒度度が、AgileとWF では異異なる
ソフトウェアの不不確実性 ü 不不確実性コーン From 10 Deadly Sins of Software Estimation by
Steve McConnell, ©2002-‐‑‒2007
納期の確率率率分布 ü ソフトウェアの納期予測は確率率率分布である ⼀一般的にプロジェクトマネージャがリリース可能⽇日を設定する場合、 最もリリースできる確率率率が⾼高い⽇日を選ぶが、その⽇日にリリースできな い可能性の⽅方が⾼高い
予測困難 という前提にたち 小さい成功を 繰り返す
Agileはリスクマネジメント ü ビジネス環境が変化するリスク ü 事前の予測が外れるリスク ü 必要なものが必要な時に出来上がらないリスク ü 無駄なコストが発⽣生するリスク 時間の経過 リスク度度
基本コンセプトはAgileマニフェスト
1122個の原則
Our highest priority is to satisfy the customer through early
and continuous delivery of valuable software.
None
毎日何回も本番環境にデプロイで きているか?((可能か?)) 顧客に頻繁に価値を届けられてい るか?
通常のリリース ü ςετ͕͔ྃͯ͠Β ϦϦʔε·ͰҎʁ ü ςετ͕͔ྃͯ͠Β ϦϦʔε·ͰҎʁ ü ςετ͕͔ྃͯ͠Β ϦϦʔε·ͰिؒҎʁ ü ͦΕҎ্͔͔Δʁ h"p://bit.ly/wo4eyD
障害時のリリース ü ςετ͕͔ྃͯ͠ΒϦϦʔε·ͰҎʁ ü ςετ͕͔ྃͯ͠ΒϦϦʔε·ͰҎʁ ü ςετ͕͔ྃͯ͠ΒϦϦʔε·ͰिؒҎʁ ü ͦΕҎ্͔͔Δʁ h"p://bit.ly/zeFv2G
障害時に11日でリリース できるのであれば、 今のリリースプロセスに は組織的な無駄がある
継続的デリバリーとは何か? 継続的デリバリーとはリリースのスケジュール をIITT部門が握るのではなく、ビジネス部門が 握るということだ。継続的デリバリを実装する ということは、全体のライフサイクルを通じて 常にソフトウェアが本番環境にリリース可能で あるということを意味する。すなわちどのビル ドもボタン一発で、完全に自動化されたリリー スプロセスを通じて、秒とか分の時間で利用者 にリリース可能である、ということだ。
JJeezz HHuummbbllee
http://bit.ly/tFrqbz 継続的デリバリー ユーザーとプロジェクトチームの間に 固いフィードバックループを作る
継続的デリバリー 継続的なフィードバックプロセスは、 競争優位性やムダの削減につながる http://bit.ly/uLQaml
http://bit.ly/vPmiFJ 一日にしてならず
http://bit.ly/vj0b0v NNoo SSiillvveerr BBuulllleett†
http://bit.ly/sygcE9 自分たちのプロセス は自分たちで進化さ せるしかない!
ツールやプラク ティスを導入�す るとアジャイル な開発になる というのは 幻想 http://bit.ly/pQrRmy
アジャイルな開発の⼿手法 Scrum XP Lean FDD Crystal AUP他
プロダクトバックログ 製品の機能をストーリー形式で記載 プロダクトオーナーが優先順位を付け、プラ ンニングポーカーで相対⾒見見積もり。 項⽬目の追加はいつでも⾃自由だが実施有無や優 先順位はPOが決める。 チーム (7±2⼈人) プロダクトの開発を⾏行行う。 製品の成功に向けて最⼤大限
の努⼒力力をコミットする スクラムマスター スクラムプロセスがうまく いくようにする。 外部からチームを守る プロダクトオーナー 製品に対して責任をもち機能 に優先順位を付ける ステークホルダー 製品の利利⽤用者、出資者、管理理職 などの利利害関係者。鶏と称す スプリントバックログ そのスプリント期間中に⾏行行う タスクのリスト スプリント 最⼤大4週間までのタイムボックス 各スプリントの⻑⾧長さは同⼀一。この間は外部 からの変更更を受け⼊入れない スプリントレビュー スプリント中の成果である 動作するソフトウェアをデモ する ふりかえり スプリントの中での改善事項 を話合い次に繋げる 複 数 回 ス プ リ ン ト を 繰 り 返 す 出荷可能な 製品の増分 スプリント計画会議 プロダクトバックログを再度度分析・評価し、 そのスプリントで開発するプロダクトバック ログアイテムを選択する。また選択した項⽬目 をタスクにばらす Doneの定義 何をもって「完了了」とするかを 定義したリスト 毎⽇日の繰り返し デイリースクラム 毎⽇日チームが以下の3つの質問に答える ・昨⽇日やったこと ・今⽇日やること ・困っていること バーンダウンチャート スプリントタスクの「推定残り時間」を 更更新してグラフにプロットする タスク 時間で⾒見見 積もり
2〜~4週間に 区切切って 繰り返す http://www.flickr.com/photos/tonivc/2283676770/
Doneの定義 何ができたら 完了了なのかを 決める
ふりかえり ü 短い間隔でうまくいったこと、うまく⾏行行かな かったことを確認する ü 次はもっと良良くする(できることから)
プラクティスの話 • 朝会 • プロダクトバックログ • スプリント • 振り返り
• ペアプログラミング • 継続的インテグレーション • ストーリーカード • 全員同席 • コードの共同所有 • テストファースト • リファクタリング • リリース計画 このプラクティスはやってない ウチではこうやってる ベストプラクティスはこうだ…� 話が盛り上がる!
しかし 手法は 目的を実現するための 道具に過ぎない
目 的 重 要 http://www.flickr.com/photos/alwaysbecool/2796977195/
Agile 形容詞 11 敏捷な,, 機敏な,, すばしこい,, はしこい
22 活発な,, いきいきとした頭の切れる,, 頭の回転が早い 小学館『プログレッシブ英和中辞典 第44版』より http://www.flickr.com/photos/practicalowl/4098547561/
形容詞 物事の 性質や 状態を 表す http://www.flickr.com/photos/tomroyal/107653935/
h"p://bit.ly/yo7Fo7
h"p://bit.ly/xKgVwh カ イ ゼ ン し て る ?
h"p://bit.ly/zkrl3t Inspect and Adapt
None
我社も(Agile|Scrum|XP)やればうまくいく! (゚Д゚)ハァ?
Don't Do Agile, Be Agile
None
守破離 http://bit.ly/qRvi51
h"p://bit.ly/zLyLc0 チームの能力を 最大限に発揮する
IteraOve Development ConOnuous IntegraOon ConOnuous Deploy Con$nuous
Delivery Enterprise Value Crea$on Strategic Impact Adaptability / Agility
製品そのものを AAggiilleeな状態に 保つ
技術的負債を 少なく保つ
品質の作りこみ Scrumではフレームワークの定義のみで、テスト⾃自 動化については触れられていない.しかしアジャイル 開発においてはテスト⾃自動化は必須 ⼩小規模リリースのたびに⼿手 動でテストするとスプリン ト後半になるにつれてテス トコストが膨らむ ⾃自動化しないとソフトウェア規模に応じて、テスト⼯工数の占め る割合が増加していく(=価値への投資が減少)
None
None
Our highest priority is to satisfy the customer through early
and continuous delivery of valuable software.
None
AAggiilleeな開発 してますか? http://bit.ly/shZMnK
AGILEな組織 33.. AAggiilleeな組織 http://bit.ly/ndgMJ6
XP 技術⾯面を⾼高め る Scrum 価値あるものから継続 的に製品を届ける Lean 企業活動⾃自体の 全体最適化 チーム
マネージャ 経営者
組織における問題点 h"p://bit.ly/yFe3Za
組織規模の拡大 →問題の深刻化 h"p://bit.ly/xHSLfl
h"p://www.flickr.com/photos/_suika/3913063515/ 組織分割における 顧客価値との不一致
コンウェイの法則 “Organizations which design systems are constrained to produce designs
which are copies of the communication structures of these organizations.” http://bit.ly/oIUrUI
ü 規則の意図が理理解されず、ただ制約化される ü 仕事のための仕事??? h"p://www.youtube.com/watch?v=4u5N00ApR_k リリースは2週間に1回で、 かつ2週間前までに申請してく ださい。 もっと頻繁に すぐできないの? 規則で決まってるし、 忙しいんです。
ピラミッド組織 ピラミッド 組織は、同質 なものを受け 入�れ、異質な ものを受け入� れられない。 http://bit.ly/qpntdu
組織のマネー ジャや上級管 理職、経営者 の一部は変化 に踏み出せな い。 組織に対する背任 http://bit.ly/nMHv6P
http://bit.ly/paHrVi 抵抗勢力は かならず発 生する
人は、有能な間は昇 進を続ける。 昇進して仕事が変化 した結果、無能にな ると昇進がとまる。 そのため、階層社会 の上の方には、無能 な人であふれ返る。
コマンドコントロール 上司の命令に 従っていれば 良い、という 価値観
コマンドコントロールの問題 ü メンバーはやらされ感を持つ ü 上司の指示を遵守したかどうかが 評価の観点に ü 人が育たない。通常は上司の劣化 コピーに…� ü 現状に不満をもつ優秀な人から順 に退職…�
h"p://bit.ly/zjyVUl チーム解体による 連続性の放棄�
稼働率という名の幻想 h"p://bit.ly/AiGcma
None
チームを強く保つ h"p://bit.ly/ygbMSj
スクラムマスター ü スクラムプロセスをうまくまわす ü 外部の⼲干渉からチームを守りチームを集中させる ü 仕事を進める上での障害事項を解決する
実行責任? 説明責任? 結果責任? …� PPOOの責任は? SSMMの責任は? チームの責任は? 管理職の責任は? 経営者の責任は? 個人の責任は?
http://bit.ly/mRCCGH
チームの責任 チームが 「全力で選択したス トーリーをDDoonneeに しようとする」 ことをコミットメン トと呼ぶ これは チームの責任であり、 個人の責任ではない
http://bit.ly/pKXeZh
見積もりはコミッ トメントではない しかし多くの場合 見積もりがコミット メントとして扱われ る悪い習慣がある http://bit.ly/pOfAGO
常に 改�善する 責任 http://bit.ly/mRLszj
プラクティス の採用理由を チームや 顧客や ステークホル ダーに 説明する責任
チームのルールに従う責任 ü デイリースクラムに出席する責任 ü 完了の定義に従って作業を行う責任 ü チームメンバーを助ける責任 ü チームメンバーを育てる責任 http://bit.ly/qFy4Aq
⼈人材育成の責任 チームが人を育 てる OOJJTTによるマン ツーマンな人材 育成ではなく、 チーム全員が協 力しあってお互 いの能力を向�上 させる
http://bit.ly/qb0Jd4
ふりかえりによる改善
None
http://bit.ly/nK3hBr ××してはいけない?
◦◦しよう!!
競争優位は個人と集 団の両方の継続的学 習から生まれる。 学習する組織とは 「チームが目的を達 成するための能力と 気づきの状態を高め 続ける組織」
ü メンタルモデル ü 自己マスタリー ü システム思考 ü 共有ビジョン ü チーム学習 // ダイアログ
メンタルモデル マインドセットやパラダイムを含め た「世の中や事象に関する前提」 http://bit.ly/nRFmiT
⾃自⼰己マスタリー 自分がどうあり たいか、何を作 り出したいかに ついて理解しつ つ、現実との差 を認識し、それ に向�かって行動 する http://bit.ly/q2RSEq
システム思考 物事を一連の要 素のつながりと してとらえ、そ のつながりの相 互作用に注目す る。全体最適化 や複雑な問題解 決の手法として 用いる
http://bit.ly/nZTDdS
共有ビジョン 組織を構成する人のそ れぞれのビジョンを重 ねて、組織として共有 し浸透可能なビジョン を作るプロセス http://bit.ly/nvZhqo
命令 説得 テスト 相談 協創 http://bit.ly/p2KAjx
“リッツ・カールトンはお客様への心 のこもったおもてなしと快適さを提供す ることをもっとも大切な使命とこころ えています。 私たちは、お客様に心あたたまる、くつ ろいだそして洗練された雰囲気を常にお 楽しみいただくために最高のパーソナ ル・サービスと施設を提供することをお 約束します。” リッツカールトンのクレドより抜粋
“リッツ・カールトンではお客様へお約束した サービスを提供する上で、紳士・淑女こそが もっとも大切な資源です。 信頼、誠実、尊敬、高潔、決意を原則とし、 私たちは、個人と会社のためになるよう、持て る才能を育成し、最大限にのばします。 多様性を尊重し、充実した生活を深め、個人 のこころざしを実現し、リッツ・カールトン・ ミスティークを高める‥リッツ・カールトンは、 このような職場環境をはぐくみます。”
リッツカールトンの従業員への約束より
None
チーム学習・ダイアログ お互いのメンタルモデルに対す る理解を深めること。集団での 気づきの状態を高める
⾃自⼰己組織化 ü 上司は責任とチームで解消で きない問題の解決を担う ü 上司は後方支援、ファシリ テーター役になる ü チームを信じる http://bit.ly/r0Lc8F
自己組織化されたチームで仕事を できるようにするためには、 外部からのマイクロマネジメント を止める必要がある。 http://bit.ly/ovenYk
リーダーや管理理職の役割の変化 ü 従来の役割や振る舞い ü ピラミッド組織 ü コマンド・コントロール ü 権威的 ü 流動性がない ü 答えをいう ü 叱る ü 否定
ü マイクロマネジメント ü 求められる役割や振る舞い ü ネットワーク型組織 ü 自律・自発の支援 ü 民主的 ü 流動性のある ü 導く ü 褒める ü 肯定 ü チームの自主性に任せる
リーダーシップのモデル(SL理理論論) http://www.situational.com/ より図を引⽤用
権限の7レベル ü 指示する ü 売り込む ü 相談する ü 同意する ü アドバイスする ü 問い合わせる ü 移譲する
None
全てのアジャイルなプロセスはチームへの 権限移譲とチーム内での文化および規範の 確立を必要とする http://bit.ly/pdq0xn
⼈人事評価のやり⽅方 ü 個人単位の評価からチーム単位の評価 ü 単一の評価者からチームメンバーを含め た評価へ http://bit.ly/r00mRp
アンチパターン アジャイルな開発における透明性を そのまま人事評価に利用する。 (こなしたタスク数など) http://bit.ly/px6oa1
個人の評価はチーム全員から「チームへの貢献 度」「プロジェクトや顧客への貢献度」を中心に 収集する http://bit.ly/pUG9Gp 対応策
None
キャリアパス 名選手名監督 にあらず。 開発のプロが 経営のプロと は限らない。 逆もまた然り http://bit.ly/mUtDl7
採⽤用プロセス
よくある問題 ü 固定化された企業イメージによって応募 者の属性が偏る ü 面接官個人の判断に左右される ü そのため似たタイプの人材が多くなる ü 数回の面接では能力の見極めは困難
h"p://bit.ly/ywESRI
None
組織の多様性は強さ http://bit.ly/qEBgGV
None
None
“Scrum is a framework for surfacing organizational dysfunction.” Tobias Mayer
SSccrruummは組織の機能不全を明るみに 出すためのフレームワークである
スクラムマスターは 解雇されて一人前! h"p://bit.ly/xnoOUO
健闘を 祈ります h"p://bit.ly/zJczAB