第10回 RxTstudy／第57回 SEA関西プロセス分科会のご案内 チケット駆動開発とメトリクス http://kokucheese.com/event/index/156953/ 【公開】第10回 RxTstudy／第57回 SEA関西プロセス分科会「チケット駆動開発とメトリクス」の感想 #RxTstudy: プログラマの思索 http://forza.cocolog-nifty.com/blog/2014/04/10-rxtstudy57-s.html

1. Redmineによる
メトリクスの経験談
2014/4/5
あきぴー＠RxTStudy＆SEA関⻄
copyright2014 akipii@XPJUG関西 1

2. Agenda
• メトリクスの経験談
• 今後収集したいメトリクス
• 本日の観点
• Redmine導入を支援するPMOの⽴場でお話します
copyright2014 akipii@XPJUG関西 2

3. メトリクスの経験談(1)
• Redmineでテスト⼯程の障害分析を⾒せると、上
司も開発チームも驚いてくれる
• チームのふりかえりで⾒せると、新たな気づきを得る
• 新人SEほど、やる気が出てくるみたい
• 定量データは、上司への報告書や計画書の元ネタになる
• 定量データを⾒せないと説得しにくい
• 信頼度成⻑曲線の評価が⾯⽩い
• 新人SEに知識があるかどうか、質問する
• 普通は、理論通りの曲線のように⾒える
• 実際は品質が悪いのに、その感覚が現れていないように⾒える
copyright2014 akipii@XPJUG関西 3

4. メトリクスの経験談(2)
• アジャイル開発はメトリクスを重視している
• 直近のイテレーションで採取したメトリクスをすぐに使える
• メトリクスのフィードバックをチームや次イテレーションに生かせる
• 同一プロジェクトでメトリクスを採取するほど、精度が⾼くなる
• WF型開発のメトリクスは使いにくい
• 下流⼯程になるほど、忙しすぎて収集しにくい
• せっかく採取したメトリクスをチームにフィードバックできない
• Velocityとサイクルタイムを定期的に集計したい
• チームの生産能⼒を定量的に計測し、次の⾒積りに生かしたい
• リリースまでの平均待ち時間を計測し、顧客への回答に使いたい
copyright2014 akipii@XPJUG関西 4

5. 今後集計したいメトリクス(1)
• リトルの法則：サイクルタイム＝WIP/Velocity
• 待ち⾏列理論の基本的な法則
• サイクルタイム＝平均待ち時間
• チケットの平均滞留期間、チケットの生存期間
• Velocity＝チームの生産能⼒
• 1イテレーション(例：1ヶ月)の完了チケット数
• チームのWIP=1サイクル(1⼯程)の仕掛中のチケット総数
• 例：作業中のチケットは30枚で、5枚/週ペースで完了できる
• サイクルタイム＝30枚/5枚/週＝6週間
• ⇒顧客の新規要望がリリースされるまでに6週間かかることを意味している
copyright2014 akipii@XPJUG関西 5

6. 今後集計したいメトリクス(2)
• プロセスサイクル効率＝実績⼯数/サイクルタイム
• プロセスのムダを⾒える化できる
• 例：機能Aの実績⼯数は1日なのに、完了させるまでに10日もかかって
いる
• ⇒プロセスサイクル効率＝1日/10日＝10%
• 残りの9日間(90％)は、チケットが放置されたまま、何もしていない
• レビュー待ちや検証待ち？ PLや上級PGがボトルネック？
• 原因究明して、ムダを省くように対策を打つべき
• 「普通の企業のプロセスサイクル効率は10〜15％程度」
• 「リーン開発の現場」参照
copyright2014 akipii@XPJUG関西 6

7. 今後集計したいメトリクス(3)
• ⼯数集計の自動化
• 月末の開発要員の⼯数報告を自動化したい
• どの会社でも、部課⻑がExcelで集計し直している
• EVMも理論上は実現可能
• チームの開発速度から、完成時総コスト⾒積り(EAC)を予測できる
• 但し、⼯数と進捗率の履歴を日々記録する必要がある
• 要員表作成(リソースチャート)の自動化
• 案件の予定表に、予定⼯数と開発要員をマッピング
• PMのお仕事の殆どは、要員表の管理をExcelでやっている
copyright2014 akipii@XPJUG関西 7
Redmine Lychee製品製品製品製品に期待してます！に期待してます！に期待してます！に期待してます！(http://lychee-redmine.jp/)

8. copyright2014 akipii@XPJUG関西 8
ご清聴
ありがとう
ございました