はじめてのアジャイル

理想と現実の出会う現場へ1

A J㈱永和システムマネジメント

㈱チェンジビジョン平鍋健児

はじめてのアジャイル～アジャイルジャパンチュートリアル～

gile apan

TIS ㈱SonicGarden

倉貫義人

理想と現実の出会う現場へ

アジェンダなぜ今 Agile かAgile とは何か海外の状況日本の課題Agile のはじめ方日本の事例プラクティス紹介

2

3

プログラマがあと

３人欲しいんです。

アジャイルを使ってはどう

かね？

アジャイルは少数でも生産性が高い、という意味じゃないんです。

じゃあ、そういう意味のキーワード教えてくれ。その後で、もう一度来

てくれ。


なぜ今 Agile か


市場市場ビジネスビジネス ITIT

市場分析発注

納品リリース

半年から３年

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


従来型の問題＝要求の劣化システムの機能の利用度

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

い19%

たまに使う16%

いつも使う7%

よく使う13%

Standish group study report in 2000 chaos report


市場市場

ITIT ２週

間か

ら半

年

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

ビジネス

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


機能 A

機能 B

機能 C

開発サービス

開発サービス

サービス開発

時間軸 : 　２週間～半年単位のリリースを繰り返す

機能軸

　　

重要機能から積み上げる

反復・漸進開発＝ Agile

R1 R2 R3

反復 (Iterative)

漸進

(Incre

men

tal)


プロセスとしての Agile 短いサイクルで、分析、設計、実装、テス

トを並列に行う

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

分析

設計

実装

テスト時間時間

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

Beck 2000Royce 1970


製品バックロ

グ

製品バックロ

グ

スプリントバックログ

スプリントバックログ

1-4 週

24 時間

出荷可能ソフトウェ

ア

出荷可能ソフトウェ

ア

朝会朝会

Scrum の例


Agileの価値観

私たちは，

プロセスとツールよりも ……… 個人と対話に．包括的なドキュメントよりも ……… 動くソフトウェアに．契約交渉よりも ……… 顧客との協調に．計画に沿うことよりも ……… 変化に対応することに．

価値をおく．

アジャイル開発宣言 (http://agilemanifesto.org/iso/ja/) 背後にある原則 (http://agilemanifesto.org/iso/ja/principle.html)


アジャイルの原則

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

信頼会話

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


アジャイルの実践（例　 XP ）

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

ペアプログラミング共同所有権継続的インテグレー

ション週 40 時間オンサイト顧客コーディング標準


•大規模•組織改革•Lean/Agile•Agile/UX

XP

2000

Agile

2002

SCRUM

FDD, Crystal,DSDM, ASD

2010

Lean SoftwareDevelopment

アジャイルの現在位置

Evo

Patterns

TPS

Deming

Lean


Agile の海外での状況


Agile 現状調査

VersionOne 社が主催の調査” State of Agile Development”

2008 年で 3 年目。アジャイルの利用状況についてアンケート調査。

Web による全世界 (80カ国 ) のアジャイルユーザを対象にしたアンケートに、 3061人が参加。

さまざまなサイズの企業が含まれる。 250名以上の会社が 32%含まれる。


もはや、開発者レベルではなく、企業の意思決定レベルに上がってきている

Agile の支持層

最初の主導者は、組織内のどの役割か？


使っている Agile 方法論は ?

現在、 Agile というと Scrum がほとんど。

使用している Agile 方法論は ?


使っているプラクティスは (1)?

ふりかえり

イテレーション計画

ユニットテスト

朝会

リリース計画

継続統合

自動ビルド

バーンダウン

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


使っているプラクティスは (2)?ベロシティ（開発速度）

タスクボード

かんばん

テスト駆動開発オープンな作業場

コード共同所有

オンサイト顧客

ペアプロ

振舞駆動開発


Agile のさらなる採用への障壁

企業風土、カルチャー、変化への抵抗勢力が大きな障壁


Agile採用への不安点

初期の計画が不十分管理不在ドキュメントが不十分などなど。。。


生産性、品質、 TTM 短縮についても、有意な効果があったとする回答が多い。

生産性、品質、 TTM


アジャイル開発の特徴

リスクを初期に下げる。可視性を常に高く保つ。変化への対応性をキープする。

リスク、可視性、柔軟性

リスク可視性

変化への対応性



Agile のはじめ方


規矩作法

守りつくして　破るとも

離るるとても　本を忘るな

千利休　「利休百首」



プラクティスを忠実に守ってみる

“ ふりかえり”で自分たちにあわせる

ビジネスにあった開発手法とする


Agile の日本の事例


私の事例

31

受託開発（プライム）

受託開発（サブプライム）

社内システム（情シス）

クラウド（社内ベンチャー）

2002 年 7月〜

2004 年 8月〜

2005 年 11月〜

2008 年 11月〜

9 名（ PJ リーダー）

15〜 30名（ PM ）

2〜 10名（管理職）

7 名（カンパニー長）

金融業界の注文管理

通信業界のサービスオーダー

社内 SNS 社内 SNS,スモール SNS

△ × ○ ○


XP のプロジェクトに挑戦！期間： 2002 年 7 月〜 2003 年３月人数： 9 名（私は PJ リーダー）対象：金融業界の注文管理システム技術： Java, SOAP, EJB, WebLogic, C++課題：短納期 , 体制不十分 , 経験不足 , 要件未確定

ペアプログラミングテストファースト

リファクタリングコードの共同所有

コーディング標準ショートリリース

ふりかえり

開発技術　＜　チームビルディング


プロジェクトで XP を実践！期間： 2004 年 8 月〜 2005 年 6 月人数： 15〜 30名（私はプロマネ）対象：通信業界のサービスオーダーシステム技術： Java, Web, Spring, Hibernate特徴：自分たちなりのプロセスの作成（ EnterpriseXP ）

受託開発でのアジャイルに疑問

瑕疵担保責任

品質保証人月コストパートナー企業

セクショナリズム

要件定義顧客側の立場

ソフトウェア開発以外の課題に多数遭遇

ソフトウェア開発以外の課題に多数遭遇


ディフェンシブな開発

納品減価償却

人月

発注

日本の受託開発の課題

ビジネスに問題があるのではないか？

決められた予算で出来るのか？計画通りに作ること

が最大の利益


社内システム開発で XP を実践！期間： 2005 年 11月〜人数： 2〜 10名（私はプログラマ〜マネージャ）対象：社内 SNS技術： Ruby on Rails特徴：ビジネスオーナーが自分

予算管理＋内製だとうまくいく

ただし、•内製できるスキル•自分たちでリスクを持つ覚悟が必要


クラウドビジネスで XP を実践！期間： 2008 年 11月〜人数： 7 名（私はカンパニー長）対象：社内 SNS 、他 SaaS技術： Ruby on Rails特徴：ビジネスオーナーが自分

毎日

毎月

リリーステストSaaS アップデート

OSS リリース

リリーステストSaaS アップデート

OSS リリース

自動テストTODO更新ソース管理

自動テストTODO更新ソース管理

繰り返す繰り返す

プロデューサー

プログラマ

運用担当者

開発工程を全て担当開発工程を全て担当

ユーザ要件を決定

ユーザ要件を決定


ビジネスにあった開発を選ぶ

t t

買った時点が最高品質

Point of Sales Point of Use

構築

償却

利用すぐに利用開始

利用中が最高品質（常にアップグレード）

q q

買った時点が最高で、そこから陳腐化が始まるも

の

常に使っている時点で最高、最新のものを利用で

きる

製造業サービス業

受託開発クラウド

"Business Aligned"





最初から“離”を狙う必要は無い


Agile のはじめ方よく聞く言葉

– 「受託だから難しい・・・」

– 「契約が・・・営業が・・・」 Web 時代の弊害

–情報が多すぎる

–最初から完璧を求めすぎる

39

完璧でなくても始めるのが Agile では？


プラクティスの紹介


ふりかえり• “KPT” と呼ばれる方式• Keep / Problem / Try で共有

– K= よかったこと / P= 問題点 / T=次にやってみること

改善の意識を生む

Keep良かったこと

Practiceプラクティ

ス

Problem問題点 Try

次にやる

プラクティス化

問題の解決

個人の持つよかったノウハウや抱えている問題を

チームのものとすることができる


ペアプログラミング• 常時コードレビューを実施している状態• ソースコードを理解している人間をクラスタ

ドキュメントによるコミュニケーションを減らす

引継ぎ・不在時のための情報共有を減らす


ペアプログラミングの様子

の模造紙ｲﾃﾚｰｼｮﾝﾀｽｸ終了したから横線をﾀｽｸ引いて消していく

は「終了」とｽﾄｰﾘｰｶｰﾄﾞ「 TODO 」に分けて貼り出す

お菓子は必須♪


astah* 開発チームの「朝会」(stand-up)


朝会

スタンダップミーティング

必ず 15 分で終わらせる

日直が呼びかけて小話する

定番

時間割表

バーンダウンチャート

ふりかえり結果


時間割表

２時間ずつ集中して作業

ペアプロは疲れる＆休憩重要

長めの休憩時間＆チャイム

１日は２時間を３コマ

前日分と当日分

担当者名

独自



進捗会議が要らなくなる

中期的な進捗管理ができる

“ ぱっと見” 重要（プレッシャ重要）その日に起きた出来事なども書き込めばふりかえりがしやすい

青が見積・目標

赤が実績

定番



進捗の見える化– バーンダウン（下向き）– タスクかんばんと連動–中間成果物で

は計測しない。– メールでエクセルシート

を配布したり、サーバに置いたから見てね、はナシ。バーンダウンチャート

の例( 協力：永和システムマネジメント：チーム角谷）


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

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

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

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

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

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


タスク・不具合の共有

タスクをポストイットで見える化

しかし、 DRY に反している

改善を実施

TracRedmine

GoogleSpreadsheet






アジャイル実践の勘所

52

アジャイルは変化を習慣にすることカイゼン

Kent Beck

僕は偉大なプログラマじゃない。偉大な習慣を身につけたプログラ

マだ

P.F.Drucker

成果をあげるのは才能ではなく、習慣だ。

どうすれば習慣化できるのか？


習慣化のためのヒント

53

小さくすれば、身軽にできる。身軽になれば、習慣にできる。

見えなければ、制御できない。適応できない。カイゼンできない。

見える化

小口化

54

プログラマがあと

３人欲しいんです。

アジャイルを使ってはどう

かね？

アジャイルは少数でも生産性が高い、という意味じゃないんです。

じゃあ、そういう意味のキーワード教えてくれ。その後で、もう一度来

てくれ。

Technology

はじめてのアジャイル