1. アジャイルプロジェクトマネジメント研究会
準備プロジェクト
(株)アットウェア 木村 事例発表
2013/03/21
©2013 atWare,Inc

2. Copyright© 2010 atWare,Inc. All rights reserved.
2

3. 自己紹介
株式会社 アットウェア
木村 卓央
KIMURA Takao
tw_takubon
http://facebook.com/kimura.takao

4. ひとつの案件について
©2013 atWare,Inc

5. 導入のきっかけ
サービスのリリースまでに時間が掛かる
©2013 atWare,Inc

6. 導入の進め方
アジャイル開発プロセス導入支援組織
•⽬目標設定
•定例例会議（毎週）
•個別ヒヤリング
アジャイル開発プロセス導入プロジェクト
アジャイル Sprint 0 Sprint
基礎研修
•アジャイル基礎研修 •インセプションデッキ作成 •スプリント計画ミーティング
•スクラム基礎研修 •ストーリー収集 •デイリースクラム
•ワークショップ •ストーリーマッピング作成 •開発作業
•開発プロセス •ストーリーの⾒見見積もり •スプリントレビュー
•TDD •環境構築 •ふりかえり
•プランニングポーカー •技術検証(スパイク)
•アーキテクチャ選定
•Doneの定義設定
準備期間（1w） Sprint0（2w） Sprint（2w）
※目標設定で設定した目標に対して、定例会議にて定期的に評価して頂きます。
©2013 atWare,Inc http://www.atware.co.jp/agilecoach/

7. プロジェクトスケジュール
準備 スプリント0 スプリント開始
スプリント0 スプリント1∼
• PO • KickOff • 開発開始
• インセプションデッキ • インセプションデッキ共有
• ストーリー収集 • ストーリーマッピング共有
• 画面デザイン検討 • PO & 開発チーム
• リリース計画 • 全体ストーリー見積もり
• 開発チーム
• Doneの定義を決定
• 開発環境構築
• スパイク(技術検証)
• PO(デザイナー含む)
• ストーリー収集
• 画面デザイン作成
©2013 atWare,Inc

8. 準備フェーズ
©2013 atWare,Inc

9. 開発プロセスはスクラムを導入
The Scrum Team
The Product Owner The Scrum Master The Development Team
©2013 atWare,Inc

10. 体制
プロダクトオーナー 開発チーム
デザイナー
お客様
スクラムマスター
©2013 atWare,Inc

11. アジャイルソフトウェア開発宣言
©2013 atWare,Inc http://agilemanifesto.org/iso/ja/

12. mの 概要
S cru
janBNZ
flick r - Dam
©2013 atWare,Inc

13. 我われはなぜここにいるのか エレベーターピッチ パッケージデザイン
• [潜在的なニーズを満たしたり、
• 大事な理由その1 潜在的な課題を解決したり] したい
(プロダクトの名前)
• 大事な理由その2 • [対象顧客] 向けの、
• [プロダクト名] というプロダクトは、
• 大事な理由その3 (素敵な写真)
• [プロダクトのカテゴリー] です。
• これは [重要な利点、対価に見合う説得力のある (最高のキャッチコピー)
理由] ができ、
<このプロジェクトの根幹に • [代替手段の最右翼] とは違って、
(ユーザーへのアピールその1)
(ユーザーへのアピールその2)
関わる理由を1つ、ここに書く> • [差別化の決定的な特徴] が備わっている。 (ユーザーへのアピールその3)
やらないことリスト プロジェクトコミュニティは...
やる やらない
(ほげほげ部門)
(他のチーム) コアチーム
(○○グループ)
あとで决める 関係者全員を！
インセプションデッキ
...思っているよりもずっと大きい！
技術的な解決策の概要 夜も眠れなくなるような問題は何だろう? 期間を見極める
• もし起きたらこわーいこと、その1 リリース!
• もし起きたらこわーいこと、その2 構築 受入テスト トレーニング
3ヶ月 1週間 1週間
• もし起きたらこわーいこと、その3
採用する技術: あくまで推測であって、確約するものではありません。
* <プログラミング言語>
* <ライブラリ>
←リスクがある箇所
* <ツール>
* <その他の要素技術>
←今回は対象外
トレードオフ・スライダー 俺たちの Aチーム
典型的なフォース
人数 役割 強みや期待すること
MAX MIN 機能をぜんぶ える(スコープ) 1 アナリスト 必要な分だけ必要なときに分析するスタイルで働ける。
テストも喜んで手伝える。
MAX MIN 予算内に収める(予算) 素早い繰り返し型の開発スタイルで働ける。
2 開発者 C#、MVC.NET、jQuery、SQL
MAX MIN 期日を死守する(時間) ユニットテスト、リファクタリング、TDD、
継続的インテグレーション
MAX MIN 高い品質、少ない欠陥(品質)
0.5 マネージャ 顧客と直接顔を合わせてのコミュニケーションを担当する。
上記以外で重要なこと 状況報告、スコープ調整、予算管理、レポートラインへの報告
MAX MIN 簡単に使える
MAX MIN 考えさせない！
MAX MIN 詳細な証跡(なんでもログを取る)
MAX MIN (などなど)
©2013 atWare,Inc

14. ストーリー収集
•ストーリーの書き方の説明
•ビジネス価値の重要性
•まずは一緒に書いてみる
©2013 atWare,Inc

15. ペルソナ
それっぽい名前
コンテキスト：
アプリを使い始めたきっかけ
この人の情報について 影響または価値
• どこに住んでいて • 価値がありそうな機能
• 趣味はどんなことやっていて • 製品の特徴などを書く
• 普段はどういう生活をしていて
s am ple
©2013 atWare,Inc

16. Kick Off
©2013 atWare,Inc flickr - Sum_of_Marc

17. 我われはなぜここにいるのか エレベーターピッチ パッケージデザイン
• [潜在的なニーズを満たしたり、
• 大事な理由その1 潜在的な課題を解決したり] したい
(プロダクトの名前)
• 大事な理由その2 • [対象顧客] 向けの、
• [プロダクト名] というプロダクトは、
• 大事な理由その3 (素敵な写真)
• [プロダクトのカテゴリー] です。
• これは [重要な利点、対価に見合う説得力のある (最高のキャッチコピー)
理由] ができ、
<このプロジェクトの根幹に • [代替手段の最右翼] とは違って、
(ユーザーへのアピールその1)
(ユーザーへのアピールその2)
関わる理由を1つ、ここに書く> • [差別化の決定的な特徴] が備わっている。 (ユーザーへのアピールその3)
やらないことリスト プロジェクトコミュニティは...
やる やらない
(ほげほげ部門)
(他のチーム) コアチーム
(○○グループ)
あとで决める 関係者全員を！
インセプションデッキの共有
...思っているよりもずっと大きい！
技術的な解決策の概要 夜も眠れなくなるような問題は何だろう? 期間を見極める
• もし起きたらこわーいこと、その1 リリース!
• もし起きたらこわーいこと、その2 構築 受入テスト トレーニング
3ヶ月 1週間 1週間
• もし起きたらこわーいこと、その3
採用する技術: あくまで推測であって、確約するものではありません。
* <プログラミング言語>
* <ライブラリ>
←リスクがある箇所
* <ツール>
* <その他の要素技術>
←今回は対象外
トレードオフ・スライダー 俺たちの Aチーム
典型的なフォース
人数 役割 強みや期待すること
MAX MIN 機能をぜんぶ える(スコープ) 1 アナリスト 必要な分だけ必要なときに分析するスタイルで働ける。
テストも喜んで手伝える。
MAX MIN 予算内に収める(予算) 素早い繰り返し型の開発スタイルで働ける。
2 開発者 C#、MVC.NET、jQuery、SQL
MAX MIN 期日を死守する(時間) ユニットテスト、リファクタリング、TDD、
継続的インテグレーション
MAX MIN 高い品質、少ない欠陥(品質)
0.5 マネージャ 顧客と直接顔を合わせてのコミュニケーションを担当する。
上記以外で重要なこと 状況報告、スコープ調整、予算管理、レポートラインへの報告
MAX MIN 簡単に使える
MAX MIN 考えさせない！
MAX MIN 詳細な証跡(なんでもログを取る)
MAX MIN (などなど)
©2013 atWare,Inc

18. Doneの定義
何をもって完了かを定義する
©2013 atWare,Inc

19. Doneの定義
•作業の完了について共通の理解
•ストーリーのDoneの定義、スプリ
ントのDoneの定義、リリースの
Doneの定義
•スクラムチームの成熟度によって変
わる
©2013 atWare,Inc

20. ストーリーの完了の定義
ソースコード・テストコードがコミッ
トされている事
コードレビューが完了していること
リファクタリングされていること
全てのユニットテストをパスしている
こと
全ての受け入れテストが用意され、そ
れにパスしていること
サーバーにデプロイされていること
討 済
©2013 atWare,Inc
検

21. スプリントの完了の定義
全てのストーリーの完了の定義が
満たされていること
全てのバグが解決しているか、対
応時期が決定されていること
未解決の問題に対して方針が決ま
っている事
ステークホルダーにも確認出来る
状態にある事
討 済
©2013 atWare,Inc
検

22. 本番リリースの完了の定義
以下のドキュメントが作成されていること
デプロイ手順書
障害復旧手順書
全てのテストがパスしていること
負荷テストに合格していること
セキュリティテストに合格していること
マーケットアップの準備が整っている事
リポジトリーにリリース用のタグ・ブラン
チが切られていること
検 討
要
©2013 atWare,Inc

23. スプリント開始
©2013 atWare,Inc

24. スプリント
月 火 水 木 金
10:15
デイリースクラム 15分
10:30
13:00
スプリント
火〜火の１週間
レビュー スプリント
1時間
14:00
14:10 スプリント
レトロスペクティブ
スクラムイベント
15:10 1時間 を火曜日に集約
15:30
スプリント
プランニング1部
1時間
16:30
16:40 スプリント
プランニング2部
1時間
17:40
©2013 atWare,Inc

25. スプリント計画ミーティング
©2013 atWare,Inc flickr - d.mosher

26. デイリースクラム
©2013 atWare,Inc flickr - TomNatt

27. スプリント・レビュー
©2013 atWare,Inc flickr - Improve It

28. スプリント・レトロスペクティブ
©2013 atWare,Inc

29. 見える化（スクラムボード他）
① ③
②
④ ⑤
⑥
©2013 atWare,Inc

30. 見える化（タスクかんばん）
⑦
⑧
©2013 atWare,Inc

31. 採用プラクティス
• インセプションデッキ・・・写真③
• このプロジェクトのゴールは何か？等を明確にする
• CI（継続的インテグレーション）
• 自動ビルド＆テストを実行することで、デグレートを防止し、品質を確保
する
• ペアプロ
• ペルソナ
• 仮想のユーザーを定義し、サービスの利用者を想定する
• 見える化
• タスクかんばん・・・写真⑧
• タスクの進 状況を見える化する
• ストーリーボード・・・写真②
• ストーリーの進 状況および優先順位を見える化する
• バーンダウンチャート・・・写真⑤
• スプリントの進 状況を見える化する
• インピーディメントリスト・・・写真④
• 作業を進めて行く上での問題点を見える化する
©2013 atWare,Inc

32. 採用ツール
•Git
•Jenkins
•JIRA
•TestLink
©2013 atWare,Inc

33. ベロシティ
50"
45"
40"
35"
30"
25"
( )"
20"
15"
10"
5"
▲新規メンバー参画
▲新規メンバー参画
0"
Sprint1" Sprint2" Sprint3" Sprint4" Sprint5" Sprint6" Sprint7" Sprint8" Sprint9"Sprint10"Sprint11" print12" print13" print14"Sprint15" print16"Sprint17"
S S S S
©2013 atWare,Inc

34. POの暴走！
POの思いつきを抑える必要があります。
デザインをもっと この人はこんな使
こうしたいなぁ い方しますか？
ここをこうした こんな機能も 本当に必要 優先順位を
いなぁ 欲しいなぁ ですか？ 考えて下さい
係 ！
頼 関
の 信
O と
P
PO TEAM SM
©2013 atWare,Inc

35. 開発チームの暴走
•リファクタリングの時間で作りなお
して壊したままに。。。
•PBLの優先順位を意識しないで開発
ビジネス価値を
•完了していないストーリーがリリー
スに含まれている
第一に考える
•タスクを消化する事が目的になりが
ち
開発チーム SM
©2013 atWare,Inc

36. 難しいと感じた
•デザイナーとの共同作業
http://msdn.microsoft.com/en-us/magazine/dd882523.aspx
©2013 atWare,Inc

37. 見学者たちの声
こんなクリエイティブ 本で読んだだけでは、
な会議初めて見ました わからないですね
実際にやってるん 是非、
ですねw うちでもやってみたい！
©2013 atWare,Inc

38. Agile Project Management
©2013 atWare,Inc

39. マネジメントの観点
•プロダクトの責任はPO
•リリース計画等はPOが検討
•当然、サポートはします
•チーム
•バーンダウンチャート、スクラム
ボードで見える化
•基本的には自己組織化
©2013 atWare,Inc

40. 品質からの観点
•完了の定義により何を持って完了と
するかを定義する
•出来る限り自動化
•Jenkinsによる自動テスト
•コストが高いUI部分についてはリグ
レッションテストを実施
•毎回結合、毎回テスト
©2013 atWare,Inc

41. アットウェアのアジャイルへの取り組み
©2013 atWare,Inc

42. アジャイル開発実績
• 2007-2008
• ECサイトリプレイス
• 開発チーム 最大40名
• 主にXP
• 2010
• 基幹システムリプレイス
• サブプロジェクト担当 最大12名
• 主にScrum
• 2012
• Androidアプリ(端末-Web)
• 開発チーム 4名
• Scrum
• Androidアプリ(端末-Server)
• 大規模プロジェクトの1部をScrumチーム(開発チーム4名)として(2013.03)
• 社内の各部署横断的にPOチームを設立
• Scrum
• 2013
• Androidアプリ(端末)
• 開発チーム 4名
• Scrum
©2013 atWare,Inc

43. 契約形態
•80%一括請負契約
•期間を短く設定
•成果物が変更される事は事前に合
意済み
•20%準委任契約
•期間を短く設定
•残業が当り前の現場だとタイムボ
ックスでの作業に異論が出た
©2013 atWare,Inc

44. アットウェアの取り組み
•アジャイル導入支援
•開発プロセス改善コンサルティング
•アジャイルでの受託開発
©2013 atWare,Inc

45. アジャイル導入支援
顧客満足を最優先し、価値のあるソフトウェアを早
く継続的に提供出来るチームを作る
•役割について説明
•開発プラクティスサポート
プロダクトオーナー
開発チーム
•役割について説明
•ストーリー収集サポート
•役割について説明
•振る舞いについてサポート
スクラムマスター
アジャイルコーチ
©2013 atWare,Inc

46. 初期導入（例）
アジャイル開発プロセス導入支援組織
•⽬目標設定
•定例例会議（毎週）
•個別ヒヤリング
アジャイル開発プロセス導入プロジェクト
アジャイル Sprint 0 Sprint
基礎研修
•アジャイル基礎研修 •インセプションデッキ作成 •スプリント計画ミーティング
•スクラム基礎研修 •ストーリー収集 •デイリースクラム
•ワークショップ •ストーリーマッピング作成 •開発作業
•開発プロセス •ストーリーの⾒見見積もり •スプリントレビュー
•TDD •環境構築 •ふりかえり
•プランニングポーカー •技術検証(スパイク)
•アーキテクチャ選定
•Doneの定義設定
準備期間（1w） Sprint0（2w） Sprint（2w）
※目標設定で設定した目標に対して、定例会議にて定期的に評価して頂きます。
©2013 atWare,Inc

47. 開発プロセス改善コンサルティング
開発プロセスのムダを無くせるとしたらどうですか
お客様のこうなりたいと⾔言ったビジョンをお聞きします
現状の開発プロセスについて、現場の⽅方々にイ
ンタビューさせて頂き、現状の開発プロセスの
把握を⾏行行います
現状の開発プロセスとお客様のビジョンとのギャップを洗い出します。
お客様のビジョンとのギャップについてお客様にご呈⽰示させて頂き、今後の
改善案についてご提案させて頂きます。
現在の開発プロセスに疑問を持っているお客様に対して、現状の開発プロセス
の問題を洗い出し、改善案をご提案いたします。
©2013 atWare,Inc

48. 作業例
現状調査した結果を、貴社ビジョンに基づき改善策を検討します。
現場のメンバーにもディスカッションに参加して頂く事により、より精度の高い
改善策をご呈示する事が出来ます。
•ビジョン確認
•定例例会議（毎週）
現状調査 改善策検討
•現場ヒヤリング •改善策についてディスカッション
最終報告
•現場確認 •改善策調査
•現状調査結果についてディスカッション •改善策についてディスカッション •最終報告書を
ご呈⽰示
現状調査(2w) 改善策検討（2w）
※目標設定で設定した目標に対して、定例会議にて定期的に評価して頂きます。
©2013 atWare,Inc

49. アジャイルでの受託開発
アジャイル経験値の高い弊社開発チームとお客様と
連携して開発を行います
•ヒアリング
•ストーリー収集
•アジャイル基礎講習
•ストーリーマッピング作成
•スプリント期間の設定
•インセプションデッキ作成
プロダクトオーナー
•スプリント計画ミーティ
(お客様)
ング
•ストーリーの⾒見見積もり •デイリースクラム
•技術検証(スパイク) •バックロググルーミング
•アーキテクチャ選定 •スプリントレビュー
スクラムマスター
•Doneの定義設定 •スプリントレトロスペク
ティブ
開発チーム
準備期間（1週間） Sprint0（2週間） Sprint1（2週間）
アジャイルコーチ
より良良いサービスを提供したいと考えているお客様に対して、アジャイル経験値の⾼高い弊社にてアジャイル開発を実施いた
します。もちろん、お客様にも積極的に関与して頂きますが、アジャイルコーチのサポートや、
弊社のプロダクトオーナーと共にプロダクトオーナーチームを編成する事も可能です。
※アットウェアでは、アジャイル開発プロセスとしてスクラムを採⽤用しています。
©2013 atWare,Inc

50. 百聞は一見に如かず
©2013 atWare,Inc