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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

33
Keep(導入時)
見える化が進んだ
各タスクのステータスがひと目で分かる
Trelloの効果も大きい
タスクがレビューステータスの際は、次のタスクを自ら取って進めるなど、自己組織化が促進した
ラフ見積もりの精度...

34
Keep(現在)
受け入れテスト時の品質向上
2014年3Q：85%→2014年4Q：100%
レビューを複数回実施しているため
作業ペースは早くなってきている
体感ベース
引き続き自己組織化促進
Back...

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

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

37
Try(現在)
完了係数の活用
Trelloプラグイン(RFC for Trello)検討
完了係数自動集計
Due date × 完了係数から受け入れ予想表示
受け入れ予想がSprint期限を過ぎる場合は警告
...

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

Arata Fujimura