1

セントラルソフト株式会社システム２部

システム開発課　課長林　栄一

2008/06/29

アジャイル開発手法スクラム適用報告

1

自己紹介

•システム２部、システム開発課　課長•勤続１２年ほど•前職：楽器メーカー、陶磁器の卸、鉄道関係の研究開発

•オブジェクト指向型開発　１５年ほど•教育のプランニング、ＰＭ、アーキテクト•興味のあること：要求開発、アジャイル、チームビルディング、Scala

2

アジェンダ

1.適用プロジェクト概要

2.スクラムの適用範囲

3.やったこと

4.効果

5.できてないこと

6.課題

7.対策

8.やってみたいこと3

プロジェクト概要

4

プロジェクト概要

•広告代理店の販売管理業務•規模は１５人月ほど•５月から詳細設計開始•５月の後半から実装開始•７月末に結合テスト完了予定

5

さて、スクラム

6

やったこと

7

やったこと

スクラム

7

やってないこと

8

やってないこと

スクラム？

8

どこからがスクラムで、どこまでがスクラムでないのか？

9

以後のプレゼンを見てみなさんに

判断していただきたい！

10

スクラムのプラクティス

11

スクラムのプラクティス

•スプリント 　一ヶ月のイテレーション 。いつでも納品。

• デイリースクラム 　毎日定時に15分間のミーティング、朝会

• プロダクトバックログ 　 業務視点で優先順位付けされたリスト

• スプリントバックログ 　スプリント（イテレーション）で実現する作業リスト

• スプリント計画ミーティング

　スプリントバックログを作成するミーティング

• スプリントレビュー

　スプリントの終了時に行う振り返り

12

スクラムのロール

13

ロール

• スクラムマスター 外部との折衝、チームを雑音から守る ミーティングをファシリテート スクラム推進のキーパーソン • プロダクトオーナー 業務の視点で、ＲＯＩからプロダクトバックログの優先順位を管理

• スクラムチーム 　開発を行う。スプリントにコミットする。

14

スクラム適用の状況

15

スクラムの適用

•前述の本社プロジェクトで部分適用•詳細設計がおわって実装にはいるタイミングから適用。

•単体テスト（画面機能単位）完了までを２つのスプリントにわけて実行

•１スプリント３週間•現在、第１スプリントが終わったところ

16

適用している役割

• スクラムマスター 私 • プロダクトオーナー 外部設計をおこなったＩ君次期フェーズの外部設計を兼任

• スクラムチーム 　本社開発メンバー

17

適用しているプラクティス

•スプリント計画ミーティング •工数再見積（見積ポーカー）•デイリースクラム•スプリントバックログ•バーンダウンチャート•スプリントバックログ•ニコカレ•スプリントレビュー

18

スプリント計画

•ＰＧ工数再見積（見積ポーカー）設計の画面をみながら全員で一斉にカードで見積を

だす。

ちがっている人の意見を聞いて、ナレッジを共有

化。

19

システム2部での適用状況

デイリースクラム

20

デイリースクラム

•スクラムマスターがファシリテート　→挨拶重要

•各自のタスクの状況と残工数を報告•開始するタスクカードにサインナップ•終わったタスクカードにはかかった工数と見積と違ったらその理由を明記(工数少なかった場合と多かった場合両方)

•各自の共有化すべき情報をシェア•終わり＝作業開始の挨拶→重要

21

デイリースクラム

•スクラムマスターがファシリテート　→挨拶重要

•各自のタスクの状況と残工数を報告•開始するタスクカードにサインナップ•終わったタスクカードにはかかった工数と見積と違ったらその理由を明記(工数少なかった場合と多かった場合両方)

•各自の共有化すべき情報をシェア•終わり＝作業開始の挨拶→重要

オリジナル！

21

デイリースクラム

•タスクカンバンの前で輪になって行う

22

タスクカード

実績工数を記入

見積との差異の理由やノウハウなどをメモ

23

システム2部での適用状況

スプリントバックログ

24

スプリントバックログ

通常のイナズマ線もそのままで、ハイブリッド

25

システム2部での適用状況

残工数の合計値バーンダウンチャート

に記入

26

•バーンダウンチャートスプリントバックログ

27

ニコニコカレンダー

•ついでにニコカレもやってみた

28

ニコニコカレンダー

•毎日変えるまえに、模造紙に気分を貼る•赤：ＧＯＯＤ！•黄色：ＮＯＲＭＡＬ•青：ＢＡＤ！•チームの気分を見える化

29

ニコニコカレンダー　例：

•ついでにニコカレもやってみた

30

ニコニコカレンダー　例：

•ついでにニコカレもやってみた

31

ニコニコカレンダー　例：

•ついでにニコカレもやってみた

32

スプリントレビュー

（振り返り）33

←要するにこれです。この本のいろいろをやってみた。

スプリントレビュー

34

スプリントレビュー

1.場を作る2.情報あつめ3.対策の検討4.終了

35

スプリントレビュー

1.場を作る1.あいさつ重要

2.大変だったメンバーをねぎらう

3.チェックイン

4.テーマの宣言 見積精度、効率化、

主要課題の対策

遅れから萎縮しているメンバーがいた

らより重要

36

スプリントレビュー

2.情報集め1. 見積との差異が大きい機能を洗い出し2. マインドマップを書きながら各自の問題や課題をシェア3. スプリント１をバーンダウンチャート上で時系列でトレース4. 詳細設計のプログラム構造についての記述が書きにくいという点がわかってきた

5. 人月当たりの平均生産ステップ：４３００step/人月6. スプリント１だけで1人月強、超過• 細かい不定期なチーム要員追加、スタートアップコスト大（最大８名）

• みためにわからない予想外の複雑さ

37

情報集めバーンダウンチャートやニコカレ上で

タイムラインレビュー

タスクカードに記入した情報を転記

機能ごと見積と実績の差異分析表

発生した事件記入

要員増えた、仕様変更、etc

38

スプリントレビュー

3.対策の検討1.５５５(Triple Nickels)

2.対策に関してのブレスト

3.次ぎに行う対策を決定する

声が大きい人だけの意見が通るのを防ぐ

39

５５５(Triple Nickels)

最初の意見

カードをまわして他の人が意見を追記して

いく

40

スプリントレビュー議論の構造が見える状態を維持しながら

ブレスト

ブレストwithマインドマップ

41

スプリントレビュー

2.終了1.各自の感想と成果2.振り返りの振り返り

42

スプリントレビュー

きまったこと1. 実装のリスクがある機能のＰＳレビュー、方式確認を数人で行う

2. テストケースは実装前か実装しながら行う

3. 実装上の課題はＷｉｋｉで管理

4. 朝：ニコカレ＋情報共有＋会社からの連絡、　夜：進捗確認

5. ＰＪ途中で入ってくる７月からの新人の作業を明確に。

• ＳＰ２の後半で新人投入のリスク回避• テスト自動化ツール調査、サンプル作成

43

スプリント１終了後

お客様にＤＥＭＯ44

ユーザーＤＥＭＯ

•単体テスト完了レベル前提でのデモ•デモするシナリオを決めてそれ以外動かさない•ユーザー様には触らせない•開発が進んでいることを見せる

45

スクラムの効果

46

効果

1.メンバーが前向きになった•自分たちから新しいアイディア2.自己組織化進んだ3.チームができてきた4.早期に動作を見てもらえることでお客様に安心

47

できていないこと

48

できていないこと

•常時納品可能状態の維持•ＴＤＤ•Ａ-ＴＤＤ（受け入れテストドリブン）•受け入れ単位での進捗管理•自由度のある契約•ＲＯＩ視点での機能の優先度調整

49

課題

50

課題

1. スクラム以前にチームファシリテーションのスキルが必要

→笑顔、ねぎらい、傾聴、見える化、重要。　

2.依然として見積精度低い。　特に大きい機能ほど標準の便利機能が使えなくなって ドラスティックに工数が増えてしまうことがある。

3.自由度のある契約

4.細かい要員追加により特定メンバーへの負荷の集中

51

対策

52

対策

1.スクラムマスターのトレーニングとファシリテーションのトレーニングを同時に行う

2.見積精度の向上は、なるべく同一のアーキテクチャーでの開発を行う

3. それぞれのアーキテクチャーでの見積知見をナレッジ化する

• ただし、同一アーキ、同一チームでの開発が ２回以上行われることは現実問題として多くないという問題あり。

53

対策 (Cont.)

4.いつでも納品できる体制の確立と同時に、スプリント単位での見積と契約。

5.大きい機能であるほど、処理イベントごとのタスクを分解して開発を行う

6.複雑な機能について処理構造検討会を少人数で開く。• 処理方式設計は一人よりも複数で検討したほうが正確、早い。

54

やってみたいこと

55

やってみたいこと

アジャイルな契約モデル1. 最長スケジュール最大コスト

2. 開発が始まっていない機能は同規模の機能と入れ替え可能

3. 機能の優先順位は変更可

4. スケジュールと予算が許す限りお客様による機能追加可能

5. プロジェクトの残り残高が２割に収まればお客様による早期解約可能

6. スプリント単位での契約あるいは、検収

7. 成功報酬などのＷＩＮＷＩＮな契約

8. あるいはＬＯＳＴ-ＬＯＳＴ56

どこからがスクラムで、どこまでがスクラムでないのか？

最初の命題

57

さて、われわれはスクラム

をやったのだろうか？58

気づき

1.スクラムのなかでどんなプラクティスも追加可能

2.一部分でも使えるプラクティスがある。

3.その環境で使えるところから使うことでも効果を得られる。

4.徐々にスクラム度を増していけばいい。

5.ただし、契約の問題は大きい。

6.実は振り返りにＫＰＴは難しい。

問題の構造が見えないままカイゼンの検討は経験が必要

59

準・スクラムぐらいはいけたかな？

60

結論

61

結論

1.スクラムをやることが目的ではない

2.生産性を上げ、メンバーがやりがいを感じられることなら何でもやる柔軟性が大切

62

Q & A63

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

64