Agile, Software Engineering, Process Kaizen. They mix like oil and water ?

Seeing is understanding. 1

アジャイルはエンジニアリングかプロセスか、あるいは新思想か？

〜⽔と油と醤油の混ざり⽅〜

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

平鍋健児

Seeing is understanding.

⾃⼰紹介•  ㈱永和システムマネジメント

–  福井市（本社）、上野東京（⽀社）、沖縄（事務所）–  「⾦融」、「医療」、「組込みシステム」開発–  GoogleApps を使った KAZEN Cloud–  「Ruby と Agile」を使ったシステム開発

•  株式会社チェンジビジョン–  福井市（開発部）、上野東京（本社）–  astah* (旧：JUDE) の開発

•  平鍋健児–  UML+マインドマップエディタ astah*の開発–  要求開発アライアンス、理事–  翻訳、XP関連書籍、『リーン開発の本質』

『IMPACT MAPPING』等多数。–  著書『アジャイル開発とスクラム』、『要求開発』

『ソフトウェア開発に役⽴つマインドマップ』

p.3

1F交流ギャラリーにて


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

• 顧客・技術・経営の３者をつなぐために、アジャイルと⽇本経営の接合点を探る

• 海兵隊の組織とアジャイル• 知識創造プロセスとアジャイル• 実践知リーダーとアジャイル• 富⼠通・楽天・リクルートの事例• Jeff Sutherlandインタビュー

平鍋健児＋野中郁次郎著


アジェンダ• アジャイル開発⼊⾨

– なぜアジャイルか?– アジャイルとは何か？– アジャイルの事例

• アジャイルの実際– アジャイルのチームづくり

• アジャイルはプロセスか?


なぜ、アジャイルか?


市場ビジネス IT

市場分析発注

納品リリース

半年から３年

ミッション・リスク分割型ビジネスとウォーターフォール型開発（従来型）


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

システムの機能の利用度

全く使われない45%ほとんど使われな

い19%

たまに使う16%

いつも使う7%

よく使う13%

•  Standish group study report in 2000 chaos report


市場

IT

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

ビジネス

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


IDEAS

CODEDATA

BUILDLEARN

MEASURE

素早くコード

単体テストユーザビリティテスト

継続的結合漸進開発

オープンソース利用クラウド

クラスタ免疫システムJITスケーラビリティ

リファクタリングデベロパーサンドボックス

素早く測定

ABテスト明確なプロダクトオーナ継続的開発ユーザビリティテストリアルタイムモニタ顧客代表

素早く学習

ABテスト顧客インタビュー顧客開発なぜなぜ5回、真因分析顧客アドバイザリボード仮説検証プロダクト・オーナーの責任顧客タイプ分析機能横断チーム半自立チームスモークテスト

漏斗分析コホート分析

ネットプロモータスコア検索エンジンマーケティング

リアルタイムアラート予測的モニタリング

Lean Startup


アジャイル開発とは何か?

スクラムとは何か?


プロセスとしてのアジャイル •  短いサイクルで分析、設計、実装、テストを並列に⾏う•  タイムボックス型、進化型開発

分析

設計

実装

テスト時間時間

要求(スコープ) 要求(スコープ) Waterfall Agile

Beck 2000 Royce 1970

最後に動くものができる動くものが徐々にできあがり、成長する


分割の仕⽅

• 顧客に分かる機能で切る。• 層で切らない。• ビジネスの価値が分かる。• やりがい、コミュニケーション

"These days we do not program software module by module; we program software feature by feature.“ 　　　　　　　　　　　—Mary Poppendieck by Akiyah


製品バックログ

スプリントバックログ

1-4 週

24 時間

出荷可能ソフトウェア

朝会

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


アジャイルの価値、原則、実践

価値 value

原則 principle

実践 practices

まずはこれを共有すること

考え方としての方針

具体的に現場ごとに作る


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

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

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

プロセスやツール　よりも　個人と対話を、包括的なドキュメント　よりも　動くソフトウェアを、

契約交渉　よりも　顧客との協調を、計画に従うこと　よりも　変化への対応を、

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

Kent BeckMike Beedle

Arie van BennekumAlistair CockburnWard Cunningham

Martin Fowler

James GrenningJim HighsmithAndrew HuntRon Jeffries

Jon KernBrian Marick

Robert C. MartinSteve Mellor

Ken SchwaberJeff SutherlandDave Thomas

© 2001, 上記の著者たちこの宣言は、この注意書きも含めた形で全文を含めることを条件に自由にコピーしてよい。

重要超重要!


アジャイルの原則

• 顧客価値の優先• 変化に対応• 短期のリリース• 全員同席• モチベーションと信頼• 会話

• 動くソフトウェア• 持続可能なペース• 技術的卓越性• シンプル• ⾃⼰組織的チーム• ふりかえりと改善


アジャイルのプラクティス（例 XP）

• 計画ゲーム• ⼩規模リリース• メタファー• シンプルデザイン• テスティング• リファクタリング

• ペアプログラミング• 共同所有権• 継続的インテグレーション• 週40時間• オンサイト顧客• コーディング標準

p.19


⾼速に⽯橋を叩いて渡る

「開発環境」

協働でゴールに向かう

「チーム環境」

ビジネス価値、顧客満⾜、市場創造

継続的インテグレーションテスト駆動開発リファクタリングペアプログラミングアジャイルモデリング … その他

朝会タスクかんばんバーンダウンチャートふりかえり … その他

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

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

アジャイルのゴール

ソーシャルプラクティス技術プラクティス


アジャイル開発の実際〜プロジェクトファシリテーション〜

p.22 Project Facilitation by Kenji Hiranabe is licensed under a Creative Commons Attribution 3.0 Unported License.

プロジェクトの⾒える化からはじめましょう


見える化/透明性l  「新の正の情報」が、「一箇所に」、「大

きく」書かれていて、それを、「両チームのメンバー」、「審判」、「観客」が見ている。「次の行動」を誘発する。

全ステークホルダーが、行動を起こせるような、確かな、分かりやすい情報源POINT


プロジェクトの成功は、Moving Target

要求　　R(t)

システム　　S(t)

チーム(t) R(t) S(t) Δ

t

不明確かつ不安定な要求。

いくらよい計画を立てても、見えていなければ、プロジェクトは成功できない。 POINT

Δ 基盤技術　　T(t)

T(t)


実践


タスクかんばんl  作業の見える化

– ToDo(未実施)Doing(実施中)Done(完了)で管理。

– 各自の作業を指示しなくても、毎朝自発的に作業開始。

– フォーマットは徐々にカイゼン。タスクかんばんの例

※バーンダウンチャーなどと共に、とにかく、壁に貼る。「情報発信器」とも呼ばれる。

作業の見える化は、「タスクかんばん」で行なう。POINT

(協⼒：チェンジビジョンastah* チーム）


助け合う


バーンダウンチャートl  進捗の見える化

– バーンダウン（下向き）

– タスクかんばんと連動

– 中間成果物では計測しない。

– メールでエクセルシートを配布したり、サーバに置いたから見てね、はナシ。

バーンダウンチャートの例

全体進捗は、「バーンダウンチャート」で見える化、繰り返しのリズムづくりPOINT

(協⼒：永和システムマネジメント：チーム⾓⾕）


スルーしない


SOMCでの朝会のヒトコマ

３⼈のリーダが集まっての朝会。移動式ホワイトボードであるNUboardを使ってます。（写真提供：ソニーモバイルコミュニケーションズの冨⽥さん）


日本からも海外へ発信

“Kanban, Successful Evolutionary Change for Your Technology Business”

http://www.agilemanagement.net

p.33 Project Facilitation by Kenji Hiranabe is licensed under a Creative Commons Attribution 3.0 Unported License. http://blog.crisp.se/henrikkniberg/


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

Corey Ladas


現場で⼯夫する

p.36

「かんばん-nano」スーツにもベストフィット！POINT

ポータブルかんばん

(協力：CCS 佐藤竜一さん）

p.37

日本からも海外へ発信

p.38

朝会l  作業の明確化

– 自発的なサインアップ

– 昨日やったこと、今日やること、問題点、の３点のみ。

– かんばんの前で、行なう。

– 朝の仕事はじめが重要！

– スタンドアップで１５分．

– 定時刻、定位置、短時間朝会の例(協力：チェンジビジョンastah* チーム）

毎朝、「かんばん」の前で全員で短い会議を行ない、リズムをとる。POINT

PF実践編：朝会ガイドhttp://www.ObjectClub.jp/community/pf/

p.39

ふりかえり(1)l  カイゼンの気づき

–  Keep(良い点)Problem(悪い点)Try(次回挑戦)を出す。

– 全員で意見を出し、暗黙知の共同化と形式知化を行なう。「名前付け」

–  「課題－解決リスト」、とは違う。

– とにかく、カジュアルな雰囲気で全員発言することで、チームの安全性を確保する。

–  「問題vs私たち」の構図になるように。

ふりかえりシートの例

カイゼンの「気づき」を「ふりかえり」で得る。POINT

実践編：ふりかえりガイド http://www.ObjectClub.jp/community/pf/

p.40

ふりかえり(2)l  Keep/Problem/Try（KPT）

–  Keepは定着する。

–  ProblemはTryを生み出す。

–  Tryは、KeepかProblemに移動する。

– 定着したものには、「名前づけ」を。

ふりかえりがカイゼンを導く

Keep

Problem

Try

新しい問題！新しいアイディア！

解決法

やってみて

うまく行った

うまく行かない

定着

イテレーション毎に「ふりかえり」を繰り返すことでプロセスが改善される。POINT


esm-conferenceブログより


やわたメディカルさんの事例

“現場では、このようにKPTを張り出し、気づいた時に付箋をはり、毎⽇お昼に話し合って、すぐアクション、というサイクルで回していたとのこと。24時間/365⽇とまらない現場は、このように⼿軽に導⼊しやすく、当事者同⼠で話し合って解決策を⾒つける仕組み（問題vs私たち）がフィットしたとのこと。”


PFの5つの原則l  見える化(Management by Sight)

– 目に見えるようにして、行動につなげる。

l  リズム(Rhythm)

– 人間活動として定期的なリズムを設計する。

l  名前づけ(Name and Conquer)

– 気づいた概念に名前をつけておく。

l  問題 vs. 私たち (Problem vs. us)

– 「問題」と「人間」を分離する。

l  カイゼン（Kaizen)

– 継続的に、今の自分たちにできる、小さいことから。


見える化l  「新の正の情報」が、「一箇所に」、「大き

く」書かれていて、それを、「両チームのメンバー」、

「審判」、「観客」が見ている。「次の行動」を誘発

する。

全ステークホルダーが、行動を起こせるような、確かな、分かりやすい情報源POINT


リズムl  リズムを「デザイン」する

– 四半期、月、週、日

– 会議や成果物のタイミング

– 日次のテスト

– 日次の朝会（毎朝１０：００）

– 週次の会議（毎週金曜は。。。）

l  朝会、ふりかえりのタイミング

l  リズムが行動の「搬送波」

リズム（チームの鼓動）をデザインして、チームを前進させようPOINT

リズムがチームのハートビート


名前付けl  「気づき」をキャッチ

l  ナレッジを，– 定着

– 他のチームに伝播

l  例：–  「今日のお仕事」（by 坂田さん）

–  「ぬかどこ」(by 倉貫さん)

–  「にこにこカレンダー」

名前をつけないと，「気づき」が逃げて行っちゃう！POINT

名前は⼤切（写真協⼒：平塚市博物館）


問題対私たち (Problem vs. Us)

l  ともすると，議論はYou vs. MeYou vs. Us になりがち．

l  「問題」と「人」とを分離

l  Problem vs. Usにもちこむ。– ホワイトボードを使う

– 座り方を替える

– ペアプログラミング

不毛なゼロサムゲームから，生産的な議論へ向かうカギ．POINT

You vs. Meの構図

You vs. Usの構図

問題 vs. Usの構図

問題 vs. Usの構図


カイゼンl  大きな改革でははじまらな

い

l  小さなカイゼンから

l  今の自分たちでできること

l  来週からできること

l  よくなっていくことを体感しよう

l  ふりかえり、が強力な武器

l  For the better tomorrow

l  明日はきっと今日よりも、いい日に決まっている

継続的に、今の自分たちでできることからカイゼンを。うまくいったら自分たちをホメよう。POINT


要求

タスク

タスク

タスク

タスク

計画イテレーション開発ふりかえり

朝会、かんばんバーンダウン

あんどんペアボード

ふりかえり

色つきUML

全体構成

半日半日一日の繰り返し

１週間

マインドマップ SKMS

l  見える化l  リズム

l  名前づけl  問題対私たち

l  カイゼン

にこにこカレンダー


佐賀県庁の事例(1)l  ニコニコカレンダー

(協力：佐賀県庁東　泰史さん)


危険ゾーン

佐賀県庁の事例(2)l  タスクかんばん



副知事

佐賀県庁の事例(3)l  朝会


ぜひこの資料を⾒てください。（有名資料） http://www.slideshare.net/hiranabe/agilejapan2010-saga-prefecture-higashi

Seeing is understanding.

デジタルとアナログ

p.57

astah* 開発チーム例

アジャイルはソフトウェア⼯学か？

73

Change Vision, Inc.

ソフトウェア工学についての後悔

l  Tom Demarco –  ソフトウェア工学、そのときは去った。

l  Ed Yourdon –  ソフトウェア工学に大切なことは？

l  Barry Boehm -  あの指数曲線は間違いだった。

l  Ivar Jacobson –  ソフトウェア業界は、ファッション業界のようだ。

l  Tom Gilb –  ソフトウェア工学は定義を間違った。

75

Tom DeMarco

Change Vision, Inc.

IEEE SOFTWARE 2009

Software development is and always will be somewhat experimental. The actual software construction isn’t necessarily experimental, but its conception is. And this is where our focus ought to be. It’s where our focus always ought to have been.

– Tom DeMarco

78 Ed Yourdon

ソフトウェア工学でも大切な

１０の考え方 Ed Yourdon

Blog: www.yourdonreport.com, Twitter, Flickr, Facebook, LinkedIn:

“yourdon” Version 11.1, spring 2009

Slideshare.net version Japanese translation by

Kenji Hiranabe 日本語訳：平鍋健児

全⽂はこちらhttp://blogs.itmedia.co.jp/hiranabe/2009/03/ed-yourdon-ca9f.html

Published under the GNU Free Documentation License (GFDL)

Top Ten Eleven Items 1. 計測できないものは制御できない 2. ピープルウェア(Peopleware) 3. インクリメンタル(Incrementalism) 4. 反復(Iteration) 5. 欠陥が下流に漏れること、修正コストが増加する 6. トレードオフは、非線形 7. 再利用は重要 8. リスクマネジメントが鍵 9. 一貫性は才能+デスマーチに勝る 10. 車輪を再発明しない 11.  透明性を重視。何も隠さないこと

80


1.計測できないものは制御できない q  多くの良書がある。例えば、トム・デマルコ 1982 の古典、

「品質と生産性を重視したソフトウェア開発プロジェクト技法」, そして、Paul Strassmann の The Squandered Computer

q  Cultural/management issues more important than technical issues (1987 の古典HP’s Robert Grady & Deborah Caswell, Software Metrics: Establishing a Company-Wide Program

q  コア・メトリクス: 規模, 見積, 欠陥, 離職

q  ソフト・メトリクス: 士気（モラール）、ユーザ満足度など。 q  システム・ダイナミクス — 例えば、ブルックスの法則 (Tarek Abdel-Hamid の

Software Project Dynamics, と Ray Madachy の新しい本, Software Process Dynamics)

q  新展開: Joel のエビデンス駆動スケジューリング(evidence-based scheduling)

q  ハイゼンベルグの不確定原理の潜在的なポジティブな側面を利用。

81


2. ピープルウェアq  人は（いつの時代でも）プロジェクトにおける大の生産性要因である。 q  もよい人材を採用して、Google の人材管理をまねよ。 q  質問：一番頭のよい大学卒業生が、あなたの会社を選択しますか（選択権が彼ら

にあると仮定して）？ ü  注意！　彼らのほとんどは MS Outlook を見たことがない。 (もし見たら恐れるだろう)

ü  彼らは、すべての人がFacebook にブログを書き、とiPhone/Android上で IM していると思っている。

ü  彼らは、 COBOLでのプログラミングできる人がまだ生きている、ということに仰天する。 q  彼らによいオフィス空間をあたえて、仕事環境でのインタラプトを小限にせよ。 q  「チーム殺し(teamicide)」をするな。 q  『ピープルウェア』: ICSE 2007 パネルセッション、「peopleware20周年記念」のレ

ポートを見よ(Sep 2007 IEEE Software). 私のブログでも無料でみれる。（訳者注：ぼくのブログに解説あり）

q  “Meet the Life Hackers,” を見よ(Oct 16, 2005 New York Times). 西海岸にある２つのハイテク会社での1,000時間にわたる観察に基づいている。”

•  “社員は、プロジェクトの中で11分ごとにインタラプトされ、別のことに振り回される。11分のタスクは、email の返信、のようなより短い3分のタスクに分断され、タスクから引き離されるたびに、戻るのに平均で25分の時間がかかる。”

82

http://www.flickr.com/photos/74987020@N00/131796142/

Barry Beohm

Plan-drivensweet spot

Time and Effort Invested in Plans

Dam

age

from

ov

er/u

nder

plan

ning

The “correct” mix of planning vs. reacting

depends on the individual project’s risk exposure.

from “Get Ready for Agile Methods – With Care” (Barry Boehm, IEEE Computer, January 2001)

Agilesweet spot

86

Ivar Jacobson

Change Vision, Inc.

ソフトウェア工学は未成熟なプラクティス(immature practices)によって、重大な阻害(gravely hampered)を今日受けている。例えば、具体的には以下のように：

l 言葉の流行が、工学の一分野というよりファッション業界のようだ。l しっかりした広く受け入れられた、理論的基礎の欠如。l 非常に多くの方法論(methods)とその派生。またそれらの違いがほとんど理解されずに作為的に強調されている。l 信頼できる実験的評価(experimental evaluation)と妥当性確認(validation)の欠如。l 産業界の実践(industry practice)と学界の研究(academic research)の乖離。

Call for Action(1/2)

私たちは、ソフトウェア工学を堅固な理論および検証された原則とベストプラクティスを基礎として、再建するプロセスを支援する。そのプロセスは、以下の特徴を備えている。

l 広く合意された要素からなる、特定用途に拡張可能なカーネルを含み、l 技術の問題と人の問題の両方を扱い、l 産業界、学界、研究者そして、ユーザに支援され、l 要求とテクノロジの変化に応じて追随できるような拡張性を備えている。

Call for Action(2/2)

Tom

Gilb

ソフトウェアシンポジウム第一回

Definition of Software Engineering from Wikipedia (= SWEBOK)

“Software engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, and the study of these approaches; that is, the application of engineering to software”

Definition of Software Engineering Tom Gilb

“Software engineering is the engineering discipline of enabling and motivating software systems to deliver a balanced set of values, directly or indirectly, to a balanced set of stakeholders, throughout their lifecycle…

アジャイルはプロセスか？

96


アジャイルの価値、原則、プラクティス

価値 value

原則 principle

プラクティスpractices

まずはこれを共有すること

考え方としての方針

具体的に現場ごとに作る


製品バックログ

スプリントバックログ

1-4 週

24 時間

出荷可能ソフトウェア

朝会

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

p.99

価値-原則-プラクティス＋

プロセスフレームワーク＋

プロセス改善p.100

Change Vision, Inc.

Alistair Cockburn

Ecosystem Methodology

Process

Techniques

Tools Skills

Roles

Standards

Quality Teams

Products People

Milestones Activities

Personality

Jenny

Jim Peter

Annika

But people are stuffed full of personality

Project manager Documenter Designer Tester

Values

Values

103

⽅法論の終焉(The End Of Methodology)“われわれは、ようやく成熟した。現在われわれが作っ

ているのは、「ふりかえり改善フレームワーク(Reflective Improvement Framework)」とも呼ぶべきものであり、方法論(methodology)ではない。Crystal, Scrum, Kanbanがその例で、これらは少数のルールからなる。少数とは、プロジェクトを運営するのには不十分なくらい、でも、単なる観察と調整(inspect&adapt)を繰り返すよりも、現場の人々が状況を改善するには十分なものだ。旧式の「方法論」、つまり ”Big-M のMethodology” は現在ではもう過ぎ去り日のものになった。それはよいことだといえるだろう。”

-- Alistair Cockburn⽇本語訳: http://blogs.itmedia.co.jp/hiranabe/2011/05/end-of-methodology-ja.html

QA to AQ Quality Assurance から Agile Quality へ

出典: http://www.washi.cs.waseda.ac.jp/?p=3147品質⾯でアジャイルになる) 品質の特定品質の可視化

壁を壊せ！

QAを組み込め!

アーキテクチャリスクキーとなる品質シナリオ受け⼊れ基準値

まとめ（私の⾒解）

108

⽔と油から醤油へl  アジャイルはプロセスではない。しかし、現場には必

ずプロセスはある。l  すべてうまくいくプロセスはなく、環境、働く⼈々、

お客様、製品などの特性によってそれぞれである。l  誰かが決めるプロセスではなく、現場改善こそが、具

体プロセスを作っていく。その仕組みをプロセス⾃⾝に⼊れるべき。

l  そして、その活動⾃体も、現場で⾏うべき。l  この場のみなさんにとっては、、、、

p.109

なんて当たり前のことを言っているのだ！

プロセス改善

ソフトウェア開発の中での、Agile の位置づけ

ソフトウェア⼯学

ソーシャル⼯学

プロジェクト管理

ビジネス

Agileが埋める領域


⾼速に⽯橋を叩いて渡る

「開発環境」

協働でゴールに向かう

「チーム環境」

ビジネス価値、顧客満⾜、市場創造

継続的インテグレーションテスト駆動開発リファクタリングペアプログラミングアジャイルモデリング … その他

朝会タスクかんばんバーンダウンチャートふりかえり … その他

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

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

アジャイルのゴール

ソーシャルプラクティス技術プラクティス


One more thing …




ご清聴ありがとうございました。