アジャイルジャパン・プレイベント企画

アジャイル初心者向けセミナー
2015/2/24

中佐藤 麻記子（なかさと まきこ）
（株）
（株）豆蔵
本トレーニングテキストの一部または全部を著作権法の定める範囲を超え、無断で複写、複製、転載、テープ化、ファイル化することを禁じます。
1

Copyright © 2015 MAMEZOU Co., LTD. All rights reserved

セミナープログラム
I.

13:00 ～ 14:50
 アジャイルを知ることからはじめよう～事例を聴く前にやっておきたいこと～
II. 15:00 ～ 15:40
 事例発表1：沼津クラウドセンターにおけるサービスのリリースサイクル短縮に向けた取り組み（富士通）
III. 15:40 ～ 16:20
 事例発表2：NECの製品開発マネージャが伝える
アジャイル開発導入の勘所（NEC）
IV. 16:30 ～ 17:30
 アジャイルにおける 『失敗』 の意味とは？
V. 17:45 ～ 19:00
 ミニ懇親会（1000円）
2

Copyright © 2015 MAMEZOU Co., LTD. All rights reserved本セッションの内容
 対象者
 「アジャイルに興味はあるけど、外部セミナーへの参加は不安」
 「Agile Japanに参加してみたいがアジャイルのことをよく知らない」というアジャイル・外部セミナー初心者の方々
 前提条件 Agile Japan 2015 に参加する予定の方
 到達目標 アジャイル開発の概要を把握し、用語に慣れる 事例を聞く時の心構えを理解する アジャイルにおける 「失敗」 の意味を理解する
3

Copyright © 2015 MAMEZOU Co., LTD. All rights reserved追加

言い忘れましたが・・・

宿題あります4

Copyright © 2015 MAMEZOU Co., LTD. All rights reservedアジャイルの基礎知識

そもそもアジャイルって何？

5

Copyright © 2015 MAMEZOU Co., LTD. All rights reservedアジャイルソフトウェア開発宣言（アジャイルマニフェスト）
私たちは、ソフトウェア開発の実践あるいは私たちは、ソフトウェア開発の実践あるいは実践を手助けをする活動を通じて実践あるいは実践を手助けをする活動を通じて、実践を手助けをする活動を通じて、よりよい開発方法を見つけだそうとしている
よりよい開発方法を見つけだそうとしている。このよい開発方法を見つけだそうとしている。この活動を通して、私たちは以下の価値に至った。
。この活動を通して、私たちは以下の価値に至った。

個人と個人と対話
包括的なドキュメントより包括的なドキュメントよりもなドキュメントよりも 動くソフトウェア
契約交渉より顧客との契約交渉よりも交渉よりも顧客との協調との協調計画に従うことより変化への計画に従うことよりもに従うことよりも変化への対応への対応

プロセスやツールよりプロセスやツールよりもやツールよりもを、を、を、を、価値とする。すなわち、左記のことがらに価値があることを認めながら価値とする。すなわち、左記のことがらに価値があることを認めながらもを認めながらも、私たちは右記のことがらにより価値をおく
私たちは右記のことがらにより価値をおく。
は右記のことがらにより価値をおく。
Kent Beck
Mike BeedleArie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler

James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick

Robert C. Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
Dave Thomas© 2001, 上記の著者たち
この宣言は、この注意書きも含めた形で全文を含めることを条件に自由にコピーしてよい。
6

Copyright © 2015 MAMEZOU Co., LTD. All rights reserved宿題その１

Webで「アジャイルソフトウェアの12の原則」 を読む

7

Copyright © 2015 MAMEZOU Co., LTD. All rights reservedさまざまなアジャイル開発手法
 エクストリーム・プログラミング（Extreme Programming: XP））
 スクラム（Scrum））
 クリスタル（Crystal））
 フィーチャ駆動開発（Feature Driven Development: FDD））
 適応型ソフトウェア開発（Adaptive Software Development: ASD））

 達人プログラマ
達人プログラマ（Pragmatic Programmer））
 Dynamic Systems Development Method: DSDM
 Executable UMLなど
8

Copyright © 2015 MAMEZOU Co., LTD. All rights reservedスクラム（Scrum）
 名称の起源は、
野中郁次郎氏野中郁次郎氏の論文
郁次郎氏の論文“The New New Product Development Game”（ハーバード・ビジネス・レビュー、1986
ハーバード・ビジネス・レビュー、1986年）
1986年）
 「プロセスフレームワーク」
 「検証／適応「検証／適応／透明性」／適応／透明性」 の3つの価値

9Copyright © 2015 MAMEZOU Co., LTD. All rights reserved宿題その２「スクラムガイド」 を読む

10

Copyright © 2015 MAMEZOU Co., LTD. All rights reservedエクストリーム・プログラミング（XP）
 皆さんが（もしかしたら）ご存じのテスト駆動開発（TDD）とか、リファクタリングとか、継続的インテグレーション（CI）とか、顧客同席とか、ペアプログラミングとか、最初に言った手法<<interface>>
価値価値

コミュニケーション
フィードバック＋ 尊敬シンプル
勇気
プラクティス

プラクティス

11

Copyright © 2015 MAMEZOU Co., LTD. All rights reserved基本的なアジャイルプロセスで、どうやるの？

12

Copyright © 2015 MAMEZOU Co., LTD. All rights reservedイテレーション イテレーション（スクラム用語：スプリント）
 開発期間を一定の期間に区切って、開発作業を反復的に行う
 通常１イテレーション ＝ １週間から３か月
１イテレーション内で、要件分析から実装・テストまで、すべての開発作業を行う

イテレーション

イテレーション

イテレーション

・・・

イテレーションの終わりには、ユーザーから見て分かる成果物（PSI※）をリリースする成果物（※ PSI：
： Potentially Shippable Increment
13Copyright © 2015 MAMEZOU Co., LTD. All rights reserved

会議体
 計画会議（スクラム用語：スプリントプランニング） レビュー会議（スクラム用語：スプリントレビュー） レトロスペクティブ（ふりかえり）
 日次スタンドアップミーティング（スクラム用語：デイリースクラム）

イテレーション
レトロスペクティブ

レビ ュー会議

計 画会議

14

日次スタンドアップ
日次スタンドアップ
日次スタンドアップ
ミーティング
ミーティング
ミーティング

Copyright © 2015 MAMEZOU Co., LTD. All rights reservedロール
通常、チームの人数は ７±２人

開発チーム

ファシリテーター

チームのお守役
スクラム用語：スクラムマスター
15

プロダクトオーナー仕様とその優先順位を決める人
XPではユーザーとか顧客と言っている
XPではユーザーとか顧客と言っている
Copyright © 2015 MAMEZOU Co., LTD. All rights reservedストーリー
ストーリーリスト（スクラム用語：プロダクトバックログ）
 ユーザーストーリーとも呼ぶ
 要件リスト プロダクトオーナーが優先順位を決める
 プロダクトオーナーは常にこのリストを「メンテナンス」 する：：

16

 イテレーションごとの計画会議でこの中のどれを対象にするかを決める

Copyright © 2015 MAMEZOU Co., LTD. All rights reserved

見積り ストーリーポイント
 基準となるストーリーを決め、そこからの相対値でストーリーの見積りをする プランニングポーカー
 ストーリーポイント見積りツールのひとつ
 スパイク
 見積のための調査や開発
 ベロシティ 前回のイテレーションの実績ストーリーポイント数
17

Copyright © 2015 MAMEZOU Co., LTD. All rights reserved

タスク
タスクリスト（スクラム用語：スプリントバックログ）
 対象ストーリーを、一作業者が1対象ストーリーを、一作業者が1日以内で作業できる大きさのタスクに分ける（くだく）
 これが開発チームがイテレーション内でやること ＝ ToDo リストになる18

Copyright © 2015 MAMEZOU Co., LTD. All rights reserved

タスクボード
TODO

DOINGDONE

Story1

Story2Story319

Copyright © 2015 MAMEZOU Co., LTD. All rights reservedバーンダウンチャート
 イテレーション内の進捗管理手法のひとつ
 縦軸に残タスク見積時間総合計、横軸にイテレーション内稼働日
 傾きで間に合うか間に合わないかを判断する

20

Copyright © 2015 MAMEZOU Co., LTD. All rights reserved継続的インテグレーション
 開発者がコードをコミットするたびに、バックグラウンドで自動的に開発者がコードをコミットするたびに、バックグラウンドで自動的にビルド・テスト・インスペクションを実行し、結果を開発チームにフィードビルド・テスト・インスペクションを実行し、結果を開発チームにフィードバックする仕組み
SCMサーバーサーバー① コードコミット② 変更点を取得③ 自動でビルド・テスト・インスペクション④ 通知

CIサーバーサーバー

21

Copyright © 2015 MAMEZOU Co., LTD. All rights reserved

KPT 以下のような枠組みを使って、ふりかえりを以下のような枠組みを使って、ふりかえりをする使って、ふりかえりをする
Keep

Try

今回実施してよかったこと、今後も継続したいことを書く

Keep と Problem から、次回実施することを書く（できるだけ具体的に）

Problem

今回見つかった課題を書く

22

Copyright © 2015 MAMEZOU Co., LTD. All rights reserved

テスト駆動開発・リファクタリング
 テスト駆動開発（TDD
テスト駆動開発（TDD）
TDD）
 ソフトウェアの単体レベルでテスト⇒実装を細かく繰り返して、プログラムの設計・開発を行う手法

必要な機能から考えてテストを書く

テストに失敗するように実装コードを書く リファクタリング
 外部から見たときの振る舞いを保ちつつ理解や修正が簡単になるようにソフトウェアの内部構造を変化させること

23

テストに成功する最低限の実装コードを書く

実装をあるべき形にリファクタリングする

Copyright © 2015 MAMEZOU Co., LTD. All rights reservedペアプログラミング 略して 「ペアプロ」 とも呼ぶ
 手法
 2人の開発者がPC、モニタ、キーボード、マウスを共有し、一つのタスクに取り組む
 入力をするドライバーとそれを見守るナビゲーターは、常に相談しながらタスクを進める ドライバーとナビゲーターは頻繁に（数分ごとに）交代する
 タスクごとや日ごとにペアの相手は変える

24

Copyright © 2015 MAMEZOU Co., LTD. All rights reservedなぜなぜ？

25

Copyright © 2015 MAMEZOU Co., LTD. All rights reservedなぜ、のオンパレード なぜイテレーションは短いほうがいいの？
 なぜイテレーションの終わりにはをユーザーから見て分かる成果物を出すの？
 なぜそれぞれの会議やるの？
 なぜ日次 「スタンドアップ」 ミーティングなの？
 なぜ日次スタンドアップミーティングは１５分以内なの？
 なぜチームの人数は７±
なぜチームの人数は７±２人なの？
 なぜプロダクトオーナーは１人がいいの？
 なぜ厳密な見積りしないの？
 なぜタスクの大きさは１日以内がいいの？
 なぜペアプロするの？
 なぜアジャイルがいいの？
26

Copyright © 2015 MAMEZOU Co., LTD. All rights reserved

THINKTHINK27

Copyright © 2015 MAMEZOU Co., LTD. All rights reserved宿題その３

知らない用語をググる

28

Copyright © 2015 MAMEZOU Co., LTD. All rights reserved

事例の聴き方：きっかけえ？？

29

Copyright © 2015 MAMEZOU Co., LTD. All rights reserved

事例の聴き方：疑問

普通に聞いてちゃダメ？

30

Copyright © 2015 MAMEZOU Co., LTD. All rights reserved

事例の聴き方：事例聞きたい病「事例聞きたい」 病
対処療法として事例を聞かせると・・・「でもうちの会社では」 病
31

Copyright © 2015 MAMEZOU Co., LTD. All rights reserved

事例の聴き方：銀の弾丸

アジャイルはポンと一式導入すればどの会社でもうまくいく魔法の手法ではないし、そんなものは世の中に存在しない

32

Copyright © 2015 MAMEZOU Co., LTD. All rights reserved

事例の聴き方：なんのためでは、事例紹介はなんのため？

33

Copyright © 2015 MAMEZOU Co., LTD. All rights reserved

事例の聴き方：事例の意義
 「私の会社では、これがうまくいきませんでした」
 「うちのチームでは、朝会に1「うちのチームでは、朝会に1時間かけています」
 「この手法は、今回は効果的でした」
 「このツールは一度トライして、やめました」
 「インセプションデッキは、とても役立ちました」
 「TDDの導入は大変でした」
TDDの導入は大変でした」
 「こういう契約形態でやりました」：：

他の会社／組織／チームでの試行錯誤の経過となぜそうしたか／なぜそうしなかったかを共有してもらえる機会
34

Copyright © 2015 MAMEZOU Co., LTD. All rights reserved前半の終り

事例セッションをお楽しみください

35

Copyright © 2015 MAMEZOU Co., LTD. All rights reserved

再び THINKTHINK36

Copyright © 2015 MAMEZOU Co., LTD. All rights reserved

後半の始まり「失敗」

37

Copyright © 2015 MAMEZOU Co., LTD. All rights reservedなぜ 「失敗」：きっかけ

小さく

38

アジャイルは失敗するための仕組み

Copyright © 2015 MAMEZOU Co., LTD. All rights reservedなぜ 「失敗」：強調

アジャイルは小さく失敗するための仕組み
39

Copyright © 2015 MAMEZOU Co., LTD. All rights reserved

適応型ウォーターフォール
スタート

ゴール

40

アジャイル
スタート

ゴール

Copyright © 2015 MAMEZOU Co., LTD. All rights reserved間違いをどうカバーするかウォーターフォールフィードバックサイクル

プロセス
文書

レビューポイント41アジャイル監
査

チェック
リスト

Copyright © 2015 MAMEZOU Co., LTD. All rights reservedディスカッション①：イテレーション内の進捗方法
 計画会議で、3計画会議で、3つのストーリーを対象として、プロダクトオーナーと合意したつのストーリーを対象として、プロダクトオーナーと合意した
 3つのストーリーそれぞれに担当者をアサインした
つのストーリーそれぞれに担当者をアサインした イテレーション期間の終盤、テストフェーズでテストケースの洗い出しが苦手なメンバーがいてストーリーの品質に影響を与えそうだったので、メンバー間の担当替えを行った その結果、無事に3その結果、無事に3つのストーリーを完成させた
 しかし、レビュー会議で顧客側の利害関係者からすべて期待のものとしかし、レビュー会議で顧客側の利害関係者からすべて期待のものとは違うのものとは違うと言われてしまった
参加者だけ
参加者だけのひみつだけのひみつ 何が問題で、どのように対処すべきだったでしょうか
何が問題で、どのように対処すべきだったでしょうか
レビ ュー×42

Copyright © 2015 MAMEZOU Co., LTD. All rights reservedディスカッション①：ふりかえり プロダクトオーナーが顧客の意図をくみ取っていない プロダクトオーナーと開発メンバーのコミュニケーションの問題
 イテレーションごとの完成度の程度（Doneの定義）を顧客側の利害の定義）を顧客側の利害
イテレーションごとの完成度の程度（関係者と合意できていない
 テストケースの洗い出しで担当替えを行ったのが適切だったのか イテレーションがミニウォーターフォール化している
 ストーリーをタスクにくだいていない（担当者が固定される）：：

43

Copyright © 2015 MAMEZOU Co., LTD. All rights reservedディスカッション①：もうひとつ問題？

44

Copyright © 2015 MAMEZOU Co., LTD. All rights reservedディスカッション②：バーンダウンチャート
 今日は3
今日は3週間のイテレーションの10週間のイテレーションの10日目です。チームのバーンダウン10日目です。チームのバーンダウン
チャートを見ると、以下のようになっていました。
チームの状態をどう判断しますか？（赤破線が基準線、青が実績）

45

Copyright © 2015 MAMEZOU Co., LTD. All rights reserved

「失敗」 に対する考え方
ウォーターフォール 失敗はしてはいけない
 そのため時間をかけて計画し、早めに開発内容と開発プロセスを確定

アジャイル

 失敗はありうること
 しかし失敗していることに早めに気付き、改善する 小さく、安全に失敗する⇒ スクラムの 「検証」 と 「適応」、XP「適応」、XP の 「フィードバック」
 失敗を隠さない、隠すと改善の機会を失う⇒ スクラムの 「透明性」、XP「透明性」、XP の 「コミュニケーション」 と 「勇気」
46

Copyright © 2015 MAMEZOU Co., LTD. All rights reserved宿題その４

Agile Japan 2015 に参加登録
47

Copyright © 2015 MAMEZOU Co., LTD. All rights reservedスポンサー※ 2015/2/23 現在48

Copyright © 2015 MAMEZOU Co., LTD. All rights reserved

まとめ

宿題その４：事例や他の意見を聴く

宿題その３：プラクティスを知る
宿題その２：スクラムを知る
宿題その１：アジャイルの根幹を知る
49

Copyright © 2015 MAMEZOU Co., LTD. All rights reserved

会場でお待ちしています

4月16日(木)@JA共済ビル（永田町）でお待ちしています50

Copyright © 2015 MAMEZOU Co., LTD. All rights reserved