Microsoft PowerPoint - NonakaScrum ReqSimpo-print.ppt [互換モード]

(1)

アジイル開発とスクラム

アジャイル開発とスクラム

株式会社チェンジビジョン

株式会社永和システムマネジメント

平鍋健児

(2)



≪講演概要≫

⽇本でも採⽤が進んできたアジャイル開発ですが、そ

の根底には、80年代⽇本の製造業で⾏われていた暗黙

知利

た新製開発⼿法があ

す現在

知を利⽤した新製品開発⼿法があります。現在アジャ

イル開発において注⽬されている「スクラム」という

名前は野中郁次郎らが1986年に書いた「The New

名前は、野中郁次郎らが1986年に書いた「The New

New Product Development Game」に由来してお

り、そこには、製品への要求を顧客との共体験を通し

て学び取り、それを仕様書ではなく体で開発に運ぶ、

思いの伝達者としてのプロダクトオーナーの姿、すな

わち実践知リダシップのありかたが⽣き⽣きと

わち、実践知リーダーシップのありかたが⽣き⽣きと

書かれています。

この⼩セッションでは、アジャイル開発の概要を解説

した後、近刊書籍『アジャイル開発とスクラム』の中

から、現場マネジメント例、および、実践知リーダー

プを中⼼お話たと思ます

p.2

シップを中⼼にお話したいと思います。

(3)

自己紹介

 ㈱永和システムマネジメント福井市（本社）上野東京（⽀社） – 福井市（本社）、上野東京（⽀社） – Ruby と Agileを使ったシステム開発  株式会社チェンジビジョン  株式会社チェンジビジョン – 福井市（開発部）、上野東京（本社） – astah* (旧：JUDE) の開発  平鍋健児 – UML+マインドマップエディタ astah*の開発要求開発アライアンス理事 – 要求開発アライアンス、理事 – 翻訳、XP関連書籍、『リーン開発の本質』『IMPACT MAPPING』等多数。 – 著書『アジャイル開発とスクラム』、『要求開発』『ソフトウェア開発に役⽴つマインドマップ』

(4)

『アジャイル開発とスクラム』

• 顧客・技術・経営の３者をつなぐ

ために、アジャイルと⽇本経営の

接合点を探る

• 海兵隊の組織とアジャイル

知識創造プロセスとアジイル

• 知識創造プロセスとアジャイル

• 実践知リーダーとアジャイル

富⼠通楽天リクルトの事例

• 富⼠通・楽天・リクルートの事例

• Jeff Sutherlandインタビュー

Seeing is understanding. Seeing is understanding. 4 平鍋健児＋野中郁次郎著

(5)

Agenda

イ

•アジャイルとは

•アジャイルの現場

•Scrumと野中郁次郎

(6)

なぜ

なぜ、

アジャイルか?

Seeing is understanding. Seeing is understanding. 6

(7)

ミシンリスク分割型ビジネスと

ミッション・リスク分割型ビジネスと

ウォーターフォール型開発（従来型）

市場分析発注

ウォタフォル型開発（従来型）

市場市場 ビジネスビジネス _IT_IT 納品リリース半年から３年半年から３年

(8)

従来型の問題＝要求の劣化

システムの機能の利用度いつも使う 7% 7% よく使う 13% たま使う 13% 全く使われない 45% ほとんど使われなたまに使う 16% い 19% St di h t d t i 2000 h t Seeing is understanding. Seeing is understanding. 8

(9)

ミッション・リスク共有型ビジネスと

Agile型開発

市場 ビジネスとITが⼀体になった 「OneTeam」を作り、ミッション とリクを共有す 市場 _{とリスクを共有する。} やってみて、結果から戦略を 作りながら進む。 市場市場 ビジネス IT IT

(10)

Lean Startup

IDEAS BUILD LEARN 素早くコード素早く学習 BUILD LEARN _{単体テスト} ユーザビリティテスト継続的結合漸進開発 AB テスト顧客インタビュー顧客開発なぜなぜ5回真因分析 CODE DATA 漸進開発オープンソース利用クラウドクラスタ免疫システムビなぜなぜ5回、真因分析顧客アドバイザリボード仮説検証プロダクト・オーナーの責任客プ析 JITスケーラビリティリファクタリングデベロパーサンドボックス顧客タイプ分析機能横断チーム半自立チームスモークテスト MEASURE 素早く測定 AB テストスモクテスト漏斗分析 AB テスト明確なプロダクトオーナ継続的開発ユーザビリティテストリアルタイムモタ漏斗分析コホート分析ネットプロモータスコア検索エンジンマーケティングリアルタイムアラト Seeing is understanding. Seeing is understanding. 10 リアルタイムモニタ顧客代表リアルタイムアラート予測的モニタリング

(11)

アジイル開発

アジャイル開発

とは何か?

スクラム

とは何か?

(12)

プロセスとしてのAgile

• 短いサイクルで、分析、設計、実装、テストを並列

に⾏う

• タイムボックス型、進化型開発

要求(スコプ) 要求(スコプ)

Waterfall

Agile

分析要求(スコープ) 要求(スコープ)

Waterfall

Agile

設計実装実装テスト時間 _時間_時間 Beck 2000 Royce 1970 最後に動くものができる動くものが徐々に Seeing is understanding. Seeing is understanding. 12 最後に動くものができる _{できあがり、成⻑する}

(13)

分割の仕⽅

• 顧客に分かる機能で切る。

• 層で切らない

• 層で切らない。

• ビジネスの価値が分かる。

• やりがい、コミュニケーション

"These days we do not program software

module by module;

y

;

we program software feature by feature.“

(14)

スクラムのフレームワーク

朝会朝会製品バグスプリントバグ 24 時間バックログバックログ 1-4 週 _出荷可能ソフトウアソフトウェア Seeing is understanding. Seeing is understanding. 14

(15)

アジャイルの

価値原則実践

価値、原則、実践

価値 l まずはこれを共有すること value まずはれを共有すると原則 i i l 考え方としての方針 principle 考え方としての方針実践具体的に現場ごとに作る具体的に現場ごとに作る

(16)

アジャイルソフトウェア開発宣言

私たちは、ソフトウェア開発の実践あるいは実践を手助けをする活動を通じて、よりよい開発方法を見つけだそうとしている。

重要

_{この活動を通して、私たちは以下の価値に至った。}

超重要

!

プロセスやツールよりも個人と対話を、

重要

超重要

プロセスやツルよりも個人と対話を、

包括的なドキュメントよりも動くソフトウェアを、

契約交渉よりも顧客との協調を

契約交渉よりも顧客との協調を、

計画に従うことよりも変化への対応を、

がが価値とする。すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。

Kent Beck James Grenning Robert C Martin Kent Beck

Mike Beedle Arie van Bennekum

Alistair Cockburn Ward Cunningham James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas Seeing is understanding. Seeing is understanding. 16 Ward Cunningham Martin Fowler Jon Kern Brian Marick Dave Thomas © 2001, 上記の著者たちこの宣言は、この注意書きも含めた形で全文を含めることを条件に自由にコピーしてよい。

(17)

アジャイルの原則

• 顧客価値の優先

• 変化に対応

• 動くソフトウェア

• 持続可能なペス

• 変化に対応

• 短期のリリース

全員同席

• 持続可能なペース

• 技術的卓越性

プ

• 全員同席

• モチベーションと信頼

• シンプル

• ⾃⼰組織的チーム

• 会話

• ふりかえりと改善

(18)

アジャイルの

プク

（例

）

プラクティス（例 XP）

• 計画ゲーム

• ⼩規模リリース

• ペアプログラミング

• 共同所有権

• ⼩規模リリス

• メタファー

• シンプルデザイン

共同所有権

• 継続的インテグレーション

• 週40時間

• シンプルデザイン

• テスティング

リフクタリング

• 週40時間

• オンサイト顧客

コディング標準

• リファクタリング • コーディング標準

Seeing is understanding. Seeing is understanding. 18

(19)

ビジネス価値、

顧客満⾜市場創造

アジャイルのゴール

顧客満⾜、市場創造

アジャイルの レフトウィング アジャイルの ライトウィング

⾼速に⽯橋を

協働ゴルに

レフトウィング ライトウィング

ソーシャルプラクティス

技術プラクティス

⾼速に⽯橋を

叩いて渡る

「開発環境」

協働でゴールに

向かう

「開発環境」

「チーム環境」

継続的インテグレーション朝会タスクかんばん _{テスト駆動開発} リファクタリングペアプログラミングタスクかんばんバーンダウンチャートふりかえり _{ペアプログラミング} … その他 … その他

(20)

タスクかんばん



作業の見える化

作業

見る化

– ToDo(未実施) Doing(実施中) D (完了) Done(完了) で管理。 – 各自の作業を指示しなく各自の作業を指示しなくても、毎朝自発的に作業開始。徐 – フォーマットは徐々にカイゼン。タスクかんばんの例タスクかんばんの例 ※バーンダウンチャーなどと共にとにかく壁に貼る「情報発信器」とも呼ばれる (協力：チェンジビジョンastah* チーム） p.20 ※バンダウンチャなどと共に、とにかく、壁に貼る。「情報発信器」とも呼ばれる。作業の見える化は、「タスクかんばん」で行なう。 POINT

(21)

バーンダウンチャート

バンダウンチャト



進捗の見える化

進捗

見る化

– バーンダウン（下向き） – タスクかんばんと連動 – 中間成果物では計測しない。メクセシト – メールでエクセルシートを配布したり、サーバに置いたから見てね、はナシ。バーンダウンチャートの例 (協力：永和システムマネジメント：チーム角 谷）谷）

(22)

ポータブルかんばん

ポタブルかんばん

(協力：CCS 佐藤竜一さん） p.22 「かんばん-nano」スーツにもベストフィット！ POINT

(23)

日本からも海外へ発信

日本からも海外

発信

(24)

““Kanban, Successful Evolutionary

Kanban, Successful Evolutionary

Change for Your Technology Business

Change for Your Technology Business””

Change for Your Technology Business

(25)

(26)

Corey Ladas

p.26

http://leansoftwareengineering.com/2007/10/27/kanban-bootstrap/ Corey Ladas

(27)

(28)

朝会



作業の明確化

自発的なサインアプ – 自発的なサインアップ – 昨日やったこと、今日やること今日やること、問題点、の３点のみ。 – かんばんの前で、行なう。 – 朝の仕事はじめが重要！重要！ – スタンドアップで１５分． – 定時刻、定位置、短時間朝会例協力ジビジム）定時刻、定位置、短時間朝会の例(協力：チェンジビジョンastah* チーム） PF実践編：朝会ガイド http://www ObjectClub jp/community/pf/ p.28 毎朝、「かんばん」の前で全員で短い会議を行ない、リズムをとる。 POINT http://www.ObjectClub.jp/community/pf/

(29)

ふりかえり

ふりかえり(1)

(1)

ふりかえり

ふりかえり(1)

(1)



カイゼンの気づき

– Keep(良い点) Problem(悪い点) Try(次回挑戦) Try(次回挑戦) を出す。 – 全員で意見を出し、員見、暗黙知の共同化と形式知化を行なう。「名前付け」「課題解決リスト」とは違う – 「課題－解決リスト」、とは違う。 – とにかく、カジュアルな雰囲気で全員発言することで、チームのふりかえりシートの例全員発言することで、チムの安全性を確保する。 – 「問題vs私たち」の構図になるように。実践編：ふりかえりガイド http://www.ObjectClub.jp/community/pf/

(30)

ふりかえり

ふりかえり(2)

(2)

ふりかえり

ふりかえり(2)

(2)



Keep/Problem/Try（KPT）

p

y（

）

– Keepは定着する。 – ProblemはTryを _{やってみて} 生み出す。 – Tryは、Keepか

Problemに移動する Keep Try

やってみてうまく行った Problemに移動する。 – 定着したものには、「名前づけ」を。 Problem 定着新しい問題！新しいアイディア！解決法うまく行かないふりかえりがカイゼンを導く新しい問題！新しいアイディア！ p.30 イテレーション毎に「ふりかえり」を繰り返すことでプロセスが改善される。 POINT

(31)

astah*

astah* 開発チーム例

開発チーム例

astah

(32)

Scrumと野中郁次郎

Seeing is understanding. Seeing is understanding.

(33)

(34)

最初のスクラムの本

• “Agile Software Development with Scrum”

g

p

(by Ken Schwaber, Mike Beedle) の最初の⼀

⾏は次の引⽤で始まっている。

今⽇では新製品開発の動きが速く、競争率の⾼い世界では、速度と柔軟性がとても重要である企業は新製品開発に直線的なと柔軟性がとても重要である。企業は、新製品開発に直線的な開発⼿法は古く、この⽅法では簡単に仕事を成し遂げることができないことを徐々に認識し始めている。⽇本やアメリカの企できないことを徐々に認識し始めている。⽇本やアメリカの企業では、ラグビーにおいて、チーム内でボールがパスされながらフィールド上を⼀群となって移動するかのように、全体論的な⽅法を⽤いている。 -- “The New New Product Development Game”The New New Product Development Game

(35)

(36)

(37)

Agile and Lean

The New New Product

D l t G

Patterns

XP

Development Game

Manufacturing Industry in Japan

Toyota Production System

Scrum

XP

y Lean Software Development

Agile

Lean

_Kanban

Lean Startup

p

(38)

Innovation Sprint 2011

me

Jeff Sutherland Ikujiro Nonaka

(39)

Nonaka’s Text Agile/Scrum (Software)

“The New New Product Development Game” 1986

1993 O P tt (b Ji C li ) ( t PL P) “The Knowledge Creating Company”(HBR) 1991

p

“Scrum”

1993 Org. Patterns(by Jim Coplien) (at PLoP)

SECI-model

1994/1 First Sprint of Scrum by Jeff Sutherland 1994/2 Second Sprint of Scrum (with Cope’s Ideas)

2001 “Agile Software Development with Scrum” (by Ken Schwaber Mike Beedle)

アメリカ海兵隊(U.S. Marine) 1995

Fractal

Organization

Scrum Master Daily Scrum

(by Ken Schwaber, Mike Beedle) 2001 “The Agile Manifesto”

2012 “Software in 30 days” “Wise Leadership”(HBR) 2010 Phronetic Leadership “Managing Flow” 2008 2012 Software in 30 days 2013 2013

(40)

野中郁次郎

The New New Product Development Game(HBR)

Scrum

1

Scrum

_{リレーからラグビーへ}

2

The Knowledge Creating Company 2

SECIモデル

暗黙知と形式知のスパイラルな変換活動が知識創造過程である U.S. Marine 4 _{変換活動が、知識創造過程である}

3 Managing Flow, The Wise Leadership(HBR)

実践知

ネシ

実践知フロネシス

形式知と暗黙知を繋ぐ、実践知。

フラクタル組織

どの階層においても、自己相似形

(41)

SECI モデル

(42)

知識創造は暗黙知と形式知の相互変換運動である

暗黙知（Tacit Knowledge）形式知（Explicit Knowledge）

言語・文章で表現できる客観的・理性的な言語知言語・文章で表現するのが難しい主観的・身体的な経験知特定の文脈に依存しない一般的な概念や論理（理論・問題解決手法・特定の文脈ごとの経験の反覆によって体化される思考スキル（思いメンタルモデ

相互作用の

マニュアル・データベース）思考スキル（思い･メンタル･モデル）や行動スキル（熟練･ノウハウ）

相互作用の

スパイラルアップ

(43)

暗黙知



⾔語・⽂章で表

現するのが難し

い



主観的・⾝体的

な経験知



特定の⽂脈ごと

の経験の反覆に

よって体化され

る思考スキル

（思い･メンタ

ル･モデル）や⾏

動スキル（熟練･

(44)

•形式知



⾔語・⽂章で表

現できる



客観的・理性的

な⾔語知



特定の⽂脈に依

存しない⼀般的

な概念や論理

（理論・問題解

決⼿法・マニュ

アル・データ

ベース）

http://www.flickr.com/photos/stuartpilbrow/4264302708/

(45)

組織的知識創造の行為

-- SECI

SECIモデル

SECI

SECIモデル

モデル「どう知るか」

モデルどう知るか」

「どう知るか」 --

どう知るか」

暗黙知暗黙知形

共同化(S)

表出化(E)

Environment E O I 暗黙知形式知 I Individual I I I I I Group 暗

内面化( I )

連結化(C)

I 黙知形式知

内面化( I )

連結化(C)

O G G E 暗黙知 E G G G Org. I

(46)

組織的知識創造の行為

SECI

SECIモデル

モデル「どう知るか」

「どう知るか」

身体・五感を駆使、

-- SECI

SECIモデル

モデル「どう知るか」

「どう知るか」

--暗黙知暗黙知 _{対話・思索･比喩によ} 直接経験を通じた暗黙知の獲得、共有、創出（共感）形る概念・図像・仮説の創造(概念化） 4.自己の暗黙知の

共同化(S)

表出化(E)

Environment E O I 暗黙知形式知形式知組み合わせ 1.組織内外の活動による現実直感 2.感情移入・気づき・予知の獲得言語化 5.言語から概念・仮説･ 原型の創造 I Environment Individual I I I I I Group I E O 形式知の組み合わせによる情報活用と知識の体系化（分析）知の獲得 3.暗黙知の伝授、移転

内面化( I )

連結化(C)

I 暗黙知形式知形式知を行動を通じて具現化、新たな暗黙知として 6.概念間の関係生成と モデル化 7.形式知の伝達、普及・ 共有 O G G G G Org. E I 形式知形式知知 I 個人理解・学習（実践） 9.反省的実践を通じた形式知の体化共有 8.形式知の編集・操作 化、IT化 E G 形式知形式知 I = 個人 G = 集団 O = 組織 E = 環境 10.目標-成果の持続的追求、自己超越

(47)

Design

g

Thinking

との関係との関係

(48)

Design Thinking

“Design thinking is a human-centered approach to innovation that draws

from the designer's toolkit to integrate the needs of people the

48

from the designer s toolkit to integrate the needs of people, the

possibilities of technology, and the requirements for business success.”

(49)

IDEO Method Cards

(50)

iPhone アプリもあります

iPhone アプリもあります。

(51)

(52)

(53)

知識創造マシンとしてのスクラム

創造された２つの知識要求とユーザにソフトウェアの E T

S

S E

E

要求とユザに関する知識ソフトウェアの作り⽅に関する知識

S

II

C

E T

II

C

T E E 成⻑するソフトウア製品成⻑するスクラムチムソフトウェア製品スクラムチーム

(54)

対象に棲み込む

対象棲み込む

－

－Indwelling

Indwelling－

－

あらゆる状況の手がかりを統合して対象に住み込て対象に住み込み、ライダーの視点(内側)から切開していく暗黙的な暗黙知り方「マシンを見ていると、いろんなことがわかります。あのカーブを切るには、ああやれば、こうすればと･･･。そして次の製作過程自然提供：本田技研工業製作過程へ自然に入っているんです。」

(55)

その場で概念（コンセプト）を紡ぎ合う

言葉と動作

言語化によって初めて自己の考えが明確になる

床の上の

設計図

(56)

プロダクトオーナの仕事。

(57)

野中郁次郎

The New New Product Development Game(HBR)

Scrum

1

Scrum

_{リレーからラグビーへ}

2

The Knowledge Creating Company 2

SECIモデル

暗黙知と形式知のスパイラルな変換活動が知識創造過程である U.S. Marine 4 _{変換活動が、知識創造過程である}

Microsoft PowerPoint - NonakaScrum ReqSimpo-print.ppt [互換モード]

アジ イル開発とスクラム

アジャイル開発とスクラム

株式会社チェンジビジョン

株式会社チェンジビジョン

株式会社永和システムマネジメント

平鍋健児

平鍋健児

≪講演概要≫

⽇本でも採⽤が進んできたアジャイル開発ですが、そ

の根底には、80年代⽇本の製造業で⾏われていた暗黙

知 利

た新製 開発⼿法があ

す 現在

知を利⽤した新製品開発⼿法があります。現在アジャ

イル開発において注⽬されている「スクラム」という

名前は 野中郁次郎らが1986年に書いた「The New

名前は、野中郁次郎らが1986年に書いた「The New

New Product Development Game」に由来してお

り、そこには、製品への要求を顧客との共体験を通し

て学び取り、それを仕様書ではなく体で開発に運ぶ、

思いの伝達者としてのプロダクトオーナーの姿、すな

わち 実践知リ ダ シップのありかたが⽣き⽣きと

わち、実践知リーダーシップのありかたが⽣き⽣きと

書かれています。

この⼩セッションでは、アジャイル開発の概要を解説

この⼩セッションでは、アジャイル開発の概要を解説

した後、近刊書籍『アジャイル開発とスクラム』の中

から、現場マネジメント例、および、実践知リーダー

プを中⼼ お話 た と思 ます

シップを中⼼にお話したいと思います。

自己紹介

自己紹介

自己紹介

自己紹介

『アジャイル開発とスクラム』

• 顧客・技術・経営の３者をつなぐ

ために、アジャイルと⽇本経営の

接合点を探る

接合点を探る

• 海兵隊の組織とアジャイル

知識創造プロセスとアジ イル

• 知識創造プロセスとアジャイル

• 実践知リーダーとアジャイル

富⼠通 楽天 リクル トの事例

• 富⼠通・楽天・リクルートの事例

• Jeff Sutherlandインタビュー

Agenda

Agenda

イ

•アジャイルとは

•アジャイルの現場

•Scrumと野中郁次郎

なぜ

なぜ、

アジャイルか?

アジャイルか?

ミ シ ン リスク分割型ビジネスと

ミッション・リスク分割型ビジネスと

ウォーターフォール型開発（従来型）

ウォ タ フォ ル型開発（従来型）

従来型の問題＝要求の劣化

ミッション・リスク共有型ビジネスと

ミッション・リスク共有型ビジネスと

Agile型開発

Lean Startup

アジ イル開発

アジャイル開発

とは何か?

とは何か?

スクラム

スクラム

とは何か?

とは何か?

プロセスとしてのAgile

• 短いサイクルで、分析、設計、実装、テストを並列

に⾏う

に⾏う

• タイムボックス型、進化型開発

Waterfall

アジイル開発とスクラム

知利

た新製開発⼿法があ

す現在

名前は野中郁次郎らが1986年に書いた「The New

わち実践知リダシップのありかたが⽣き⽣きと

プを中⼼お話たと思ます

知識創造プロセスとアジイル

富⼠通楽天リクルトの事例

ミシンリスク分割型ビジネスと

ウォタフォル型開発（従来型）

アジイル開発

価値原則実践

プロセスやツールよりも個人と対話を、

プロセスやツルよりも個人と対話を、

包括的なドキュメントよりも動くソフトウェアを、

契約交渉よりも顧客との協調を

契約交渉よりも顧客との協調を、

計画に従うことよりも変化への対応を、

• 持続可能なペス

プク

• ⼩規模リリス

リフクタリング

コディング標準