"現場をより良くするためにやっていることを3つの観点で振り返る「kpt発表会」" で発表した資料です。

1. 1
2014年11月25日 ＧＭＯインターネット株式会社 次世代システム研究室 藤村 新
アジャイルな オフショア開発 KPT
～現場をより良くするためにやっていることを3つの観点で振り返る「KPT発表会」～

2. 2
現状の問題点
1度のやり取りで完成しない
オフショアチームの見積もり精度が低い その結果
遅延を繰り返す
モチベーションが下がる
スケジュールが信頼できなくなる
相手を信頼できなくなる

3. 3
現状の問題点
オフショアチームで品質を担保できない その結果
日本側の担当者(プロデューサー)の負荷増大
明らかなバグから細かいバグまで全て確認し、指摘す る必要がある

4. 4
現状の問題点
あとちょっとの修正も、修正を依頼するためのコストが 結構かかる その結果
95%完了から完成までしばらく時間がかかる

5. 改善施策

6. 頑張っても 効果が薄い事は 諦める

7. 一度のやり取りで期待通 りのアウトプットが出て こない

8. 一度のやり取りで期待通 りのアウトプットが出て こない 時間をかけてもっと詳細 な仕様書を準備する

9. 一度のやり取りで期待通 りのアウトプットが出て こない 時間をかけてもっと詳細 な仕様書を準備する

10. 一度のやり取りで期待通 りのアウトプットが出て こない
1度のやり取りでの完成を 諦めた初回ザックリ開発

11. 見積もりの精度が低く、 完了予定が見えない

12. 見積もりの精度が低く、 完了予定が見えない 時間をかけて見積もりの 精度を上げてもらう

13. 見積もりの精度が低く、 完了予定が見えない 時間をかけて見積もりの 精度を上げてもらう

14. 見積もりの精度が低く、 完了予定が見えない ザックリ開発工数だけ見 積もってもらい、実見積 もりは係数を使って算出

15. 95%完了から先が長い

16. 95%完了から先が長い 再度指示書を書いて、完 成してもらう

17. 95%完了から先が長い 再度指示書を書いて、完 成してもらう

18. 95%完了から先が長い 最後の5%は日本側で完成 させる

19. これら改善施策を 盛り込んだ 開発モデルを 考えてみた。

21. Rough Fill Closing

22. ベースは リーン開発の カンバン

25. Rough
Fill
Closing

26. 26
ザックリ開発するフェーズ
7割程度の完成度を目指す
Backlogの時点で、ストーリーはレディ(着 手可能、仕様記載済み)な前提
ストーリーをタスク分割時に、オフショア 側開発者に工数を見積もってもらう
Roughのレビューフェーズで、専任担当 は完成までに必要な仕様を詳細に伝える

27. Rough
Fill
Closing

28. 28
Roughフェーズでのアウトプットの完成 度を上げるフェーズ
9割以上の完成度を目指す

29. Rough Fill Closing

30. 30
完成させるフェーズ
日本側の発注者(エンジニア)が対応する

32. Roughフェーズの見積もり日数、実際にか かった日数、完成までに要した日数(サイク ルタイム)等のメトリクスを収集
サイクルタイム÷見積もり日数で完了係数を 算出し、計画づくりに使用する

33. 33
Keep(導入時)
見える化が進んだ
各タスクのステータスがひと目で分かる
Trelloの効果も大きい
タスクがレビューステータスの際は、次のタスクを自 ら取って進めるなど、自己組織化が促進した
ラフ見積もりの精度は想定通り高く、完了形数のバラ 付きもそれほど無かった
チームが慣れれば、計画づくりに使えると感じて いる

34. 34
Keep(現在)
受け入れテスト時の品質向上
2014年3Q：85%→2014年4Q：100%
レビューを複数回実施しているため
作業ペースは早くなってきている
体感ベース
引き続き自己組織化促進
Backlogに積んでおくと、タスク分解、ブランチ作 成、実装、ラボ内レビューまで自発的に実施
メンバー間のレビュー精度向上

35. 35
Problem (導入時)
ラボ専任担当の負荷増大
Rough仕様作成
Roughレビュー
Fill仕様作成
Fillレビュー
Closingタスク
ラボ専任担当がボトルネックになるケースがあった
レビュー待ち、Closingタスクの増大
スケールしない構造

36. 36
Problem(現在)
期限に対する意識が低い
Due date になってもサラッと遅延
遅れることが問題ではなく、共有されないことが 問題
完了係数をそもそも活用できていない
メトリクスの集計が手間

37. 37
Try(現在)
完了係数の活用
Trelloプラグイン(RFC for Trello)検討
完了係数自動集計
Due date × 完了係数から受け入れ予想表示
受け入れ予想がSprint期限を過ぎる場合は警告
RFCモデルを他のプロジェクトへ展開
パターン・ランゲージ化
敷居が高い…
導入マニュアル整備
ラボ専任担当のWIPを制限する仕組み

38. 38
おわり