軽量開発プロセスにおけるTracを利用したメトリクスの収集とプロジェクト管理

Copyright © 2014 NTT DATA Corporation
株式会社NTTデータ技術開発本部
大杉直樹
軽量開発プロセスにおけるTracを用いた
メトリクスの収集とプロジェクト管理
第57回SEA関西プロセス分科会／第10回RxTstudy
2014年4月5日
於株式会社SRA 関西事業部会議室

2Copyright © 2014 NTT DATA Corporation
健康のために階段を使いましょう！
 何階までなら階段を使える？
 2つ上の階まで？
 5つ上の階まで？
 25上の階まで！？
 いつなら階段を使える？
 始業15分前なら？
 始業10分前なら？
 始業3分前！？
 そもそも、健康のために上の階
に上っているのではない。
 時間までにオフィスに到着する
ことが第一の目的。

管理のためにメトリクスを測りましょう！
 測定に使える時間は？
 1人時／週？
 1人日／週？
 5人日／週！？
 分析に使える時間は？
 1人時／週？
 1人日／週？
 5人日／週！？
 そもそも、メトリクスのために
開発をしているのではない。
 納期までにシステムを完成する
ことが第一の目的。

筆者らが参画したシステム開発では・・・
 管理業務（下記）は開発と兼務、大きな工数は確保できない。
 開発プロセス、進捗管理・品質管理手順のルール整備・監視。
 進捗管理・変更管理・構成管理ツール準備と使用ルール整備・監視。
 開発計画策定、上位層報告、そして、メトリクス収集・蓄積・利用。
SGLと要員1名が
管理業務を兼務
PM
有識者
管理&α業務SG
SGL 1名
要員 4名
β業務SG
SGL 1名
要員 4名
γ業務&方式SG
SGL 1名
要員 3名
オフショアSG
SGL 1名
要員 9名
マニュアルSG
SGL 1名
開発GL
PM
要員3名
開発GL
GLが開発と
管理業務を兼務
Aシステム開発プロジェクト Bシステム開発プロジェクト
※PM: Project Manager, GL: Group Leader, SG: Sub Group, SGL: Sub Group Leader

2つのシステム開発プロジェクトの事例
 できるだけ軽いシステム開発プロセスを設計し、小さいコストで
メトリクス計測・蓄積・利用できるよう努力した事例を報告する。
Aシステム開発プロジェクト Bシステム開発プロジェクト
開発対象生産管理系社内システム情報系社内システム
アーキテクチャ Web三層＆Windowsクラサバ Web三層
規模中規模小規模
要員数
ピーク時80名、
サービス開始後26名
ピーク時4名、
サービス開始後2名
言語・FWなど
Python, VB.NET, Trac,
PostgreSQL
Java, JavaScript, JSP, Struts2,
iBatis, MySQL
特徴
全社で標準的に使用されるシス
テム。稼働率とリカバリ要求など
ある程度の品質が要求される。
全社、Ｇ会社から使われるが研
究開発色が強い。要求品質は高
くないが、安く作る必要がある。

だからお前は誰なんだよ
 大杉直樹
 専門：ソフトウェア工学
（実証的ソフトウェア工学）
 経歴
 2004年9月
 奈良先端科学技術大学院大学
博士後期課程修了
 2004年10月～2007年3月
 同大学特任助手（ポスドク）
 2007年～現在
 株式会社ＮＴＴデータ技術開発本部勤務
 アクセス
 Twitter: @ohsugi
 LinkedIn: www.linkedin.com/in/ohsugi/

2008/8 2010/4 2012/42009/11 2013/32011/4
本稿での報告対象期間
 下記の、のべ29ヶ月間の運用事例について報告する。
 著者のうち3名が管理業務を実施し、状況をよく把握しているため。
 その後もおよそ同様の方法を運用しているが、本発表の対象外。
Aシステム開発
Aシステム維持保守・機能追加
Bシステム開発
Aシステムサービス開始
維持保守体制移行
Bシステムサービス開始
Bシステム維持保守

本稿における軽量開発プロセスの定義
 アジャイルの知見やプラクティスを取入れたウォーターフォール。
 10営業日未満の開発単位（案件）で設計、実装、テストを繰り返す反復型開発。
 メトリクス分析や対面報告形式の集合型レビューではなく、全作業内容のピアレビュー
で品質保証する。
ITM/UTED/ID
案件1： A画面追加
案件2： B画面改善要望反映
開発要員I
案件3： B画面バグ修正
案件4： C画面バグ修正
開発要員II
案件5： C画面改善要望反映
案件6：移行ツール開発
開発要員III
ST
案件7：次々バージョンリリース機能追加開発
移
行
作
業
次バージョンサービス開始
ITM/UTED/ID
ITM/UTED/ID
ITM/UTED/ID
ITM/UT
ITM/UTED/ID
ITM/UTED/ID
※ED/ID：内部設計/外部設計、 M/UT：製造/単体テスト、 IT：結合テスト、 ST：総合テスト

開発環境と管理のためのサーバ群
 SVNを構成管理、Wikiを情報共有に使い、Tracを進捗管理・故
障管理・課題管理、メトリクス計測・蓄積・利用に使った。
開発
要員
Trac
開発環境
開発環境
SGL
管理
要員
PJの目標、
計画、議事録、
プロセス、
各種ルール、
技術Ｔｉｐｓなど
Wiki
ルール整備・保守
全体計画作成
Trac
チケット
チケット
で作業
アサイン
SVNリポジトリ
IRC
StepCounter
＋自作バッチ
作業報告、
レビュー依頼、
メトリクス記録
進捗・故障・課題管理
IRC
開発環境
Eclipse, VS2010,
Vim, MS Officeなど
IRC
開発作業
レビュー、
進捗・品質・課題管理
ルール整備・上位報告
監視
成果物作成・修正

プロジェクトの Wiki トップ
 各wikiページへのリンク、スケジュールやマイルストーンを示すダ
ッシュボード、チケットのリスト（人ごと&バージョンごと）

Tracの運用方法：計画作成時
 SGLが次のリリースに向けた自SGの計画を作成し、各案件に対
応する案件チケットを発行する。
 各案件について、ED/ID、M/UT、ITチケットを発行し、案件チ
ケットと共に各開発要員にアサインする。
SGL
案件A
案件B
案件C
ST 移行
次リリースに向けた計画
案件A
チケット
案件A
ED/ID
チケット
案件A
M/UT
チケット
案件A
IT
チケット開発要員Ｉ
案件C
チケット
案件C
ED/ID
チケット
案件C
M/UT
チケット
案件C
IT
チケット開発要員ＩＩＩ
案件B
チケット
案件B
ED/ID
チケット
案件B
M/UT
チケット
案件B
IT
チケット開発要員ＩＩ
作成
チケットを自SGの要員にアサイン

案件チケットの例
メトリクス
案件名
作業実施
情報
レビュー
情報
作業内容
の詳細

チケ切り地獄への対処（チケ切りコストの軽減）
 Aシステム開発プロジェクト（中規模、ピーク時80名）
 MS Project ファイルを読み込み、チケットを発行するツールを利用。
 中規模以上のプロジェクトで同様の運用をするためには必須？
 例）四半期で50案件に対応する→50 x 4 = 200 枚のチケットが必要
 Bシステム開発プロジェクト（小規模、ピーク時4名）
 全てのチケットを手動で切るが、バグ管理用のチケットと開発用のチケッ
トを兼ねたチケットにする。
 バグ発見したら「案件チケット」を切ってとりあえずペンディングにする。
 多くのバグは直すために開発する。案件チケットでバグ報告を兼ねることで、バグチ
ケットと開発用チケットの2重起票・2重管理を避ける。

Tracの運用方法： ED/ID実施時
 開発要員は設計書を作成・修正し、レビュー対象チェンジセットを
ED/IDチケットに記入してリーダに渡す。
 SGLはチェックリストに従ってレビューを実施し、結果を記入したチェッ
クリストを添付して返す。
 要員は修正を実施したチェンジセットを記入して渡す。全ての指摘を
SGLが確認したらED/ID完了。チケットを閉じる。
SGL
開発要員
SVNリポジトリ
設計書作成・修正
ED/ID
チケット
設計書
レビュー結果添付、
メトリクス記入
設計書
設計書レビュー、
修正確認
ED/IDチェックリスト
管理要員
監視・
是正処置
作業状況、
レビュー対象チェンジセット、

ED/IDチケットの例
メトリクス
作業内容
チケット名
作業実施
情報
レビュー
情報

非同期の観点ベースレビュー
 作業 ⇒ レビュー ⇒ RV結果確認 ⇒ 修正作業 ⇒ 修正確認を
チケットとSVNを介して行うことで非同期化する。
 レビュー待ち中に他作業（前倒しM/UT、他案件）を進められる。
 チェックリスト改善により、系統的に再発防止できる。

Tracの運用方法： M/UT実施時
 開発要員はコードとUTコードを作成・修正し、レビュー対象チェンジ
セットをM/UTチケットに記入してリーダに渡す。
SGLが確認したらM/UT完了。チケットを閉じる。
SGL
開発要員
SVNリポジトリ
コード、UTコード作成・修正
M/UT
チケット
コード、UTコード
コード、UTコード
コード、UTコードレビュー、
修正確認
M/UTチェックリスト
管理要員
監視・
是正処置
作業状況、

M/UTチケットの例
メトリクス
作業内容
の詳細
チケット名
作業実施
情報
レビュー
情報

チケットと作業ラインを対応させたリブ管理
 M/UTは開発ライン、ITはメインライン、STは安定ラインの資材で実施。
 案件毎にコミットしメインラインへマージ、リリース毎に安定ラインへマージ。
 衝突は複数人が同一資材を同時編集しないようスケジューリングして回避。
Ver.1.1開発ライン（1.1-devel）
Ver.1.1
案件1
M/UT
Ver.1.1 リリース対象案件
安定ライン（stable）
Ver.1.1
案件2
M/UT
Ver.1.1
案件3
M/UT
Ver.1.1 案件
マージ
試験環境へ
デプロイ、ST実施
Ver.1.2
案件1
M/UT
Ver.1.2 案件
Ver.1.2
案件2
M/UT
Ver.1.2
案件3
M/UT
・・・
メインライン（trunk）
マージ
&IT
マージ
&IT
マージ
&IT
Ver.1.1開発ライン削除
（※ST完了後）
廃棄
Ver.1.2開発ライン（1.2-devel）
マージ
&IT
分岐
マージ
&IT
マージ
&IT
分岐
本番環境
へデプロイ
Ver.1.1 リリースタグ作成
※設計書は別ディレクトリで管理

Tracの運用方法： IT実施時
 開発要員はコードとUTコードをメインラインへマージし、ITコードを作
成・修正。チェンジセットをITチケットに記入してリーダに渡す。
SGLが確認したらIT完了。チケットを閉じる。
SGL
開発要員
SVNリポジトリ
Trunkマージ、
ITコード作成・修正
IT
チケット
ITコード
ITコード
マージ結果、ITコードレビュー、
修正確認
ITチェックリスト
作業状況、
管理要員
監視・
是正処置

ITチケットの例
メトリクス
作業内容
の詳細
チケット名
作業実施
情報
レビュー
情報

チケット種類（工程）に応じたチェックリスト
 各自席でチェックリストに従ってレビューを実施。全観点OKになれば通過。
工程作業内容レビュー対象レビュー観点
設計
（ED/ID）
 仕様検討
 設計書作成修正
 設計書のチェンジセット  要件の充足
 影響範囲の考慮
製造
（M）
 ソースコード作成・修正  ソースコードのチェンジ
セット
 設計との整合性
 アーキテクチャや規約
 性能や信頼性の考慮
単体テスト
（UT）
 リクエストレスポンスでの
ブラックボックステスト
 C1網羅のためのホワイト
ボックステスト
 テスト項目表、証跡
 UTコードのチェンジセット
 UTコード走行結果
 修正個所に対するC1網羅
 テスト観点の充足
 無駄なテストコードがないか
 影響範囲の回帰テスト
結合テスト
（IT）
 画面遷移確認
 画面間データ連動確認
 テスト項目表・証跡
 ITコードのチェンジセット
 ITコード走行結果
 設計書の修正個所網羅
 テスト観点の充足
 無駄なテストコードがないか
案件完了
判定
 全作業結果確認
（主要部分のみ）
 全対象物
（主要部分のみ）
 ITまでの全観点
（主要部分のみに絞って確認）
総合テスト
（ST）
 業務、移行、運用、環境、
外部接続
 マニュアルの連動
 非機能要件の確認
 システム全体  業務、移行、運用、環境、外部
接続が正しく連動するか
 マニュアルと動作の整合性
 非機能要件の充足

Tracの運用方法：案件完了後
 開発要員は実施状況などを書き込み、案件チケットをSGLに渡す。
 SGLは有識者、および開発GLに案件完了判定を依頼する。
 案件完了が承認されれば、案件チケットをクローズする。
SGL
開発要員
SVNリポジトリ
実施状況など、
実施状況など、
コード、テストコード
コードレビュー、
修正確認
開発GL 有識者
案件
チケット
ED/ID
チケット
M/UT
チケット
IT
チケット
案件完了判定
チェックリスト
管理要員
監視・
是正処置

開発GL／有識者による最終レビュー
 基本的には開発要員によるセルフレビュー、SGLによるレビュー
で品質を担保する。
 難しい案件／ヤバそうな場所／ST開始後のバグなどについて
は、開発GLや有識者が要点を絞って全成果物をレビュー。
SGL開発要員開発GL有識者
成果物
•設計書
•ソースコード
•テストコード
成果物成果物
セルフRV RV
要点を絞って
全成果物をRV
RV状況を
踏まえ案件
完了を判定
成果物
品質UP品質UP品質UP
品質十分と判断したらほぼスルー
（有識者／開発GLが判断）

収集した基本メトリクス（1）
メトリクス名チケット記入担当者記入内容
作業工数
（人時）
全チケット開発要員作業、レビュー指摘事項への対応工数。
レビュー工数
（人時）
全チケット SGL 作業のレビュー、レビュー指摘修正確認の工数。
レビュー頁数
（頁）
ED/ID SGL
レビューした設計書頁数。レビュー対象がMS Excel
形式の場合、レビューしたシート数。
指摘件数
（件）
ED/ID SGL
レビュー指摘件数。レビュー結果はMS Excel形式
のレビュー結果票で1行に指摘1件を記入するため、
レビュー結果票の行数（＝指摘数）。
開発規模
（Step）
M/UT 開発要員
M/UT開始前～完了までの追加・変更行数の合計。
削除行数は数えない。
リビジョン間差分のLOCを計測して記入。
テスト項目数（件）
または
テスト規模（Step）
M/UT,
IT,
ST
開発要員
テストの量。Aシステム開発ではテスト項目数、
Bシステム開発ではテストコード（UTはJUnit、ITとST
はSelenium）の追加変更行数、削除行は数えない。

収集した基本メトリクス（2）
メトリクス名チケット記入担当者記入内容
バグ数
（件）
IT,
ST
開発要員
ITやSTで検出されたバグの数。
UTバグは取り切ってからM/UT完了する想定のた
め計測しない。
コーディングとUTコード記述を並行実施するため、
計測にかかるコストも大きすぎる。
すり抜けバグ数
（件）
IT,
ST
開発要員
ITやSTで検出されたものの、完了済の前工程の観
点で検出すべきだったバグの数。
開発要員が判断に迷った場合は、レビュア（SGL）
と管理業務担当者が判断する。
開発期間
（日）
案件開発要員
案件開始～完了までの日数。開始日と終了日か
ら算出。
案件完了判定
指摘件数
（件）
案件 SGL
IT完了後に実施する案件完了判定での指摘件数
を記入。

Tracの運用方法：メトリクス利用時
 管理要員はTracのカスタムクエリによって蓄積したメトリクスを抽出
し、MS Excelファイルで集計する。
 各案件の実施状況やメトリクスに基づき、計画書や報告書を作成し、
PMに計画付議、または工程完了やリリースを伺う会議を実施する。
 外部からの依頼などに応じて、適当なタイミングで集計・報告もする。
PM
管理要員
SVNリポジトリ
計画・報告書作成
チケット
計画書、報告書
作業状況確認、
メトリクス検索
成果物レビュー、
計画会議、報告会議
チケットチケットチケットチケットチケットチケットチケット
成果物、計画書、報告書
計画付議、
工程完了・
リリース伺い
開発GL

カスタムクエリによるチケット検索結果の例

報告書におけるメトリクス集計結果の例

利用した導出メトリクス
メトリクス名評価対象導出方法主な用途
生産性
（KStep/人月）
案件
開発規模
÷案件に要した全工数
計画時の見積り、スコープ調整や再
計画で見積り根拠として利用。
１日当たり
稼働時間
案件
案件に要した全工数
÷開発期間
要員毎の負荷調査、稼働時間が低い
要員や案件の検出と問題改善。
レビュー密度
（分/頁）
ED/ID
ED/IDレビュー工数
÷レビュー頁数
レビュー不十分な可能性がある案件
の検出。仕様が複雑など、レビューに
時間がかかる要注意案件の抽出。
エラー密度
（件/百頁）
ED/ID
ED/ID指摘件数
÷レビュー頁数
レビュー不十分でエラーが少なすぎる
または、多すぎる案件の検出。
テスト密度
（件/KStep）
または
テストコード比率
（%）
UT、
IT、
ST
テスト項目数÷開発規模
または
テスト規模÷開発規模
テスト不十分な可能性がある案件の
検出。仕様が複雑など、テスト量が非
常に多い要注意案件の検出。
バグ密度（件
/KStep）
IT、
ST
バグ数
÷開発規模
テスト不足でバグ抽出が過小、または
バグが多すぎる問題案件の検出。
すり抜けバグ密度
（件/KStep）
IT、
ST
すり抜けバグ数
÷開発規模
前工程のテスト不備とレビューチェック
漏れ検出。再発防止に繋げる。

メトリクスの用途：各バージョンの開発計画策定
 案件数ベースの見積り
 人数（人） x 期間（月）で四半期で利用可能な工数を算出、研修や休暇などを
減算して利用可能な工数を確定。
 案件を「時間がかかるもの（大案件）」、「すぐ直せるもの（小案件）」の2種類に
分類し、各案件の平均必要工数から四半期で対応できる案件数を見積り。
 線を引いてみて、各案件の複雑度や開発要員やPMとの意識合わせに応じて
微調整。
 KStepベースの見積り
 生産性（KStep/人月）で見積り。完了済案件の生産性と、開発予定案件の
見積り規模を積算して各案件の見積り工数を算出。

メトリクスの用途：スコープ調整における再見積り
 生産性起因のスコープ調整の場合
 当該時点での完了済案件から、実際の生産性を再計算。
 再計算した生産性で線を引き直す。
 稼働時間起因のスコープ調整の場合
 当該時点での完了済案件から、1日あたりの稼働時間を算出。
 他業務と兼務の要員など、実質上の稼働が1日3時間程度のケースもあった。
 当初想定の稼働時間と、実状に応じて線を引き直す、もしくは稼働時間を低
下させている原因のブロックや影響緩和に動く。
 人起因のスコープ調整の場合
 当該四半期でアサインされている案件の消化が早い／既に全部終わってし
まった開発要員に、遅れている要員分の案件をアサイン。
 アサインする案件は取捨選択するが、最初の計画ではスキルレベルでの補正はしない。
 できる人のモチベーションを下げない仕組みが必要。
 できる人を日ごろから称える／未熟な要員の育成＋補助をミッションとしてアサインなど

メトリクスの用途：完了案件の週次定量分析
 当該週に完了した全案件を、過去案件とメトリクスが大きく乖離して
いないか（中央値±８０％以上、もしくは以下でないか）をチェック。
 かい離がある場合は管理SGが追加で証跡やコードをレビュー。プロダ
クトやプロセスに問題がある場合はGLにエスカレーション。
 原因分析や対策を検討し、必要に応じて開発G進捗、全体進捗にエ
スカレーション。
月火水木金土日月
週次定量分析 → → → →
報告
↓
開発G進捗 ◎ ― ―
報告
↓
全体進捗 ◎

メトリクスの用途：上位マネジメントへの報告
 ED/ID-IT完了時とST完了時にPMや必要に応じて上位マネジメント
への品質報告を実施。
 品質報告では、下記に合わせて、各案件のメトリクス、全案件の眼ト
リクス結果値、定量分析で検出した問題とその対策を報告。
 開発の実施状況（体制、ユーザとの仕様調整、作業、RVの実施状況）
 次工程、次以降のリリースへの持ち越し案件・バグ
 残存する品質上の課題とリスク
 工程完了・次工程開始、サービス開始についての開発GLの所見
案件A
案件B
案件C
ST 移行ED/ID-IT実施期間
ED/ID-IT
品質報告
ST品質報告&
サービス
開始判定
サービス
開始

メトリクスの有効性：規模、工数、開発期間
 非常に有効
 計測と解釈が容易で、収集や要員の学習コストも小さい。
 他のメトリクスと組み合わせて分析できる。
 見積もりの際に必須の情報
 案件当たり必要工数（工数／案件）
 1日・1人あたり稼働時間（時間／日・人）
 1日当たり開発量（KStep／日）
 開発の規模感・全体傾向を掴むためにも必須
 実コード行数、テストコード行数、前バージョンからの変動
 実コード vs テストコードの比率
 1人あたりが四半期で書くコード行数、テストコード行数

メトリクスの有効性：テスト量やテスト密度
 大きい体制ではある程度有効
 GLが全案件ピアレビューできないため、危険案件のフィルタリングに使える。
 GLが全案件ピアレビューする小さい体制では、詳細把握しているため意義薄。
 テスト量（追加コード行数ゼロ）というのは、目立つので指標になる。
 つまり回帰テストのみだが、案件の内容からそれが妥当かどうか、中身を見なくてもな
んとなく判断できることもある。
 C0/C1網羅率、コードクローン分析、コーディング規約違反数など、ピアレ
ビューでは検出できない課題を検出できるメトリクスが有効か？
 メトリクス計測そのものは本筋ではなく、EclEmma、CheckStyle、Xlint など
コード分析ツールを利用した継続的な品質向上は有効。

メトリクスの有効性：バグ密度
 バグ密度：課題あり
 IT、STバグ数を計測したが、多くの案件ではIT、STバグは検出されなかった。
 バグが検出された否かのみに着目すればよく、密度を算出した意義は薄い。
 機能やモジュール単位でバグ数や密度を算出 ⇒ 当該部分の品質
や担当者・チームのスキル判断材料に利用できる？
 中小規模の開発なら、そんなものなしでもある程度は把握しているはず。
 超大規模開発や管理側の技術スキルが低い場合など、管理側に情
報が少ない状態では役立つ局面があるかもしれない。
 開発期間やリリース期間が長い時代にディスカッションベースで品質
保証をしていた時代の遺物になりつつある？

気が付けば色々ノウハウが…
試行錯誤しながらやっていて、気が付けば色々ノウハウが
溜まっていた気がします。
今回、当時のチケットを見直していて、チケットベースの振
り返りがノウハウを形にする材料にもなると思いました。

軽量開発プロセスにおけるTracを利用したメトリクスの収集とプロジェクト管理

More Related Content

Viewers also liked

Similar to 軽量開発プロセスにおけるTracを利用したメトリクスの収集とプロジェクト管理

Recently uploaded

軽量開発プロセスにおけるTracを利用したメトリクスの収集とプロジェクト管理