第２回 すくすく・スクラム資料、その１

1. すくすく・スクラム
第２回
2009/05/28
セントラルソフト株式会社
林 栄一

2. クリエイティブな仕事したい人？

3. 自己紹介
所属：セントラルソフト株式会社 課長
趣味はピアノ、ジェンベ、作曲、たまにライブ。
PMとかアーキテクトとか、教育制度のプランニング、
運営とか
前職では楽器メーカーで電子楽器の開発
オブジェクト大好き、モノ作り大好き
認定スクラムマスター
ドラムサークルファシリテーター協会メンバー
ＮＬＰ認定プラクティショナー

4. トロント アジャイル２００８
Thanks
チームの皆へ
送り出してくれた人達へ

5. トム・ポッペンディック
ヘンリック・クニーベルグ

6. EM ZERO VOL2

7. 今日やること
•ウォータフォールVSアジャイル
•グループワーク
•スクラムの概要
•スクラムの適用概要
•開発者兼経営者 ミルズさん講演
•Q＆A、グループワーク

8. グループ分け
•自己紹介
•一人１分づつ

9. ウォーターフォールvsアジャイル

10. 滝 vs いきいき

11. ウォーターフォール

12. ウォーターフォール
市場分析 発注
市場 ビジネス IT
リリース 納品
３ヶ月から３年
平鍋さんの資料から転載、一部修正

13. ウォーターフォール
フィードバックの欠落したウォーターフォール・モデルが広まったの
は防衛用ソフトウェア開発に関する仕様を定めた米国防総省の規格書
（1985年6月）がきっかけだとされる。
これをベースに英国のJSP-188、フランスのGAM-T-17、ドイツの
Vモデルなどが作成されている。
しかし、これらの標準に基づいて推進されたソフトウェア開発プロ
ジェクトが失敗を重ねたことから、米国防総省は1994年12月に反復
型開発を推奨する「MIL-STD-498」定めている。 （wikipedia）

14. 非ウォーターフォール
ウォーターフォール 非ウォーターフォール
開発単位：大 開発単位：小
上流工程ですべてを見通 上流工程ではもれがある
せる だろう
各工程は一発勝負
（実際は、手戻りによる 各行程をやりなおせる
やりなおし多発）

15. アジャイル
時間軸: １週間∼１ヶ月単位のリリースを繰り返す
機能軸 重要機能から積み上げる
反復(Iterative)
インクリメンタル(Incremental)
R1 R2 R3
開発 サービス
機能A
開発 サービス
機能B
開発 サービス
機能C
平鍋さんの資料から転載、一部修正

16. アジャイル
ビジネスとITが一体になった
市場 「OneTeam」を作り、ミッション
とリスクを共有する。
やってみて、結果から戦略を
作りながら進む。
チーム主動型
ビジネス
市場
ヶ月
ら1
間か
IT
１週
平鍋さんの資料から転載、一部修正

17. みなさんの現場の課題？
Keep
Problem
•ペアでシェア Try
のPだけやってみましょう
•テーマ：
•開発現場で困っていること、こうしたいと思っている
こと。
•一人２分ずつ話します
•聞いている人はちゃちゃを入れない
•グループ内で発表しながら模造紙の左半分に
記入

18. スクラム概要

19. スクラムとは

日本の製造業の製品開発手法をソフトウエア開
発に応用した方法論

最初のスクラムは１９９３年

繰り返し型開発手法

重要なものから作って使ってもらう

使ってもらって優先順位を区切りごとにメンテ

推進する役割をスクラムマスターという

20. スクラムの役割
• スクラムチーム
開発を行うチーム。
スプリントにコミットする。
• スクラムマスター
外部との折衝、チームを雑音から守る
ミーティングをファシリテートする。
指示型→促進型
スクラム推進のキーパーソン
• プロダクトオーナー
業務の視点で、ＲＯＩ（費用対効果）
からプロダクトバックログの優先順位を
管理する。 総責任者

21. スクラムのプロセス
•デイリースクラム
•毎日定時に15分間のミーティング、朝会
•スプリント
•2週間∼４週間の繰り返し。開発単位。
•スプリント計画で決めた機能を開発
•スプリントバックログ
•スプリント（イテレーション）で
•実現する作業リスト
•プロダクトバックログ
•業務視点で優先順位付けされた機能リスト
•スプリント計画ミーティング
•スプリントバックログを作成するミーティング
•スプリントレビュー
•スプリントの終了時に行うデモと振り返り

22. スクラムの基礎となる価値
自己組織化
予測型 実測駆動
問題の原因はプロセスや技術ではなく人間に依存する

23. スクラムのポイント
実測駆動管理と制御プロセスからなる

振り返りと調整のループ

２∼４週間ごとの納品

原理は単純

一種の管理しない管理

個人ではなくチームとしての生産性を高める

チームに責任と権限


24. （ちなみに）従来の管理方法
 リーダーは部下の管理と監視が役割
− 指示を出して結果を確認
− 部下の選択を承認する権限を維持する
− 部下が使えるリソースと情報を制限する
 顧客ではなく、作業者の管理によって、作業
が決まる。
 タスクごとの担当、期間

25. プロダクトバックログ
（機能リスト）

26. スプリントバックログ
（タスクリスト）

27. タスクカンバン

28. バーンダウンチャート

29. スクラム適用

30. ２つのプロジェクト
 プロトタイプシステムの開発をとおして、シス
テム開発と同時にシステム開発手法を作る。
− 業務システムを開発する＝>開発プロジェクト
− 開発方式を開発する＝>メタプロジェクト

31. 開発プロジェクトゴール
 担当が使いやすく、使いたくなる
 担当から仕様アイディアを誘発する
 利用が増える
 内部調整がスムーズに行える

32. メタプロジェクトゴール
 引継ぎ可能な必要十分なドキュメント方式
 重要なものから早期にリリースするアジャイル
方式からビジネス効率化可能性を高める
 お客様の環境に適合したアジャイル開発手法を
適切に適用するプロジェクト運営方式を作りあ
げる。
− 各種規約、運営方針、運営ノウハウ
− ワークショップ資料
− 基礎理論資料

33. プロジェクト体制

34. プロジェクトの進め方

35. プロジェクト全体像
達成したい目標を挙げてください

目標の詳細を明らかにしてください


36. スケジュール（３ヶ月間）
スクラムマス
ター：林
スクラムマス
ターをBさんにス
イッチ
スクラムマスター
を林がコーチ

37. プロジェクト体制（敬称略）
 ユーザー部門
− 責任者：１名
− 現場ご担当
 開発
− プロダクトオーナー：A
− スクラムマスター 林 → B
− チームメンバー：
 お客様会社:２名
 セントラルソフト：３名
− スクラムコーチ：林（認定スクラムマスター）

38. 開発で行ったプラクティス
• TDD（テスト駆動開発、自動テスト）
• CI（継続的統合、毎日二回の最新ビルドと自動テスト）
• ペアプログラミング
• 朝会（デイリースクラム）
• スプリントプランニング
• プランニングポーカー
• タスク分割
• タスクカンバン
• TRACによる、タスク管理、ドキュメント管理
• バーンダウンチャート
• 振り返り

39. 次ぎはミルズさんのご講演です！

40. みなさんの現場の課題？Problem
Keep
Try
のTをやってみましょう
•グループで先ほどの課題の解決策を考えてみ
ましょう。
•アジャイルをつかってもいいしつかわなくてもか
まいません。
•使える考え方はなかったか考えてみましょう。
•グループ内で検討しながら模造紙の右半分に
記入してください。
リーダーの人はスクラムマスター
になったつもりでグループをファシリテー
トしてみてください。

41. グループごとに発表

42. おつかれさまでした！