【公開】第10回 RxTstudy／第57回 SEA関西プロセス分科会「チケット駆動開発とメトリクス」の感想 #RxTstudy

4月5日 第10回 RxTstudy／第57回 SEA関西プロセス分科会　チケット駆動開発とメトリクスに参加したので、ラフなメモ書き。

第10回 RxTstudy／第57回 SEA関西プロセス分科会のパネルディスカッション from akipii Oga

【0】大杉さん、神谷さんをお呼びして、チケット駆動開発とメトリクスに関係するお話。
僕はパネルディスカッションに出た。
パネラー4人のうち、3人(大杉さん、神谷さん、@sakaba37さん)は工学博士というかなりレベルの高い方ばかり(笑)。
聴衆にも、品質保証やメトリクスに詳しい方もおられて、パネルディスカッションが1時間以上白熱しました。
久しぶりにチケット駆動開発について熱い議論ができて有意義でした。

【1】僕のポジショニングトークスでは、Redmine導入・運用を支援するPMOの立場から、メトリクスの経験談と今後採取したメトリクスについてお話しました。

【1-1】Redmineでテスト工程の障害分析を見せると、上司も開発チームも驚いてくれる時が多い。
普通の開発チームは、プロダクトをリリースするのに精いっぱいで、障害がたくさん出ているのは分かるが、その詳細や傾向は知らない。
上司も、品質やコストを知りたがっているが、現場から離れているので、チーム状況が分からない。

だから、結合テスト工程が終わった直後に、チームの振り返りをするときに、反省会のイメージで、最もメトリクスが取りやすい障害分析の結果を見せると、Redmineを使うとこんなこともできるのか、と効果を感じてくれる。
その内容も、カテゴリ・対応者・原因工程・検出すべき工程・混入工程・機能別にサマリするだけでも、定量データで見せるのはかなり威力がある。

特に、新人SEや若手に見せると、その後の作業でやる気が出るみたい。
おそらく、今後は改善していこう、という意識が自然に働くのだろうと思う。
だから、僕はあえて、メトリクスを見せて成績評価に使うことはしない。
そんな使い方をしなくても、メトリクスを見せれば、行動は自然に変わってくる。

また、定量データは、上司への報告書や計画書の元ネタになる。
特に、マネージャレベルになると、テスト報告書やプロジェクト完了報告書を書くときに、リリース判定基準となる定量データとして使える。
今後のプロジェクト計画でも、過去のシステム開発の定量データを元に、今回は、こんな対策を講じて実施します、という使い方もできる。
経営者に近いレベルの人には、定量データを見せて論理的に話さないと、説得しにくい場面が多いからだ。

【1-2】信頼度成長曲線も実際に集計する時は多い。
すると、普通は、理論通りの曲線のように見える時が多い。
実際は品質が悪いのに、その感覚が現れていないように見えるのだ。

その理由は簡単だ。
普通は、結合テストやシステムテストの工程の後半になると、開発要員を縮小する計画になっているので、少ない人数でテストを続けるために、バグの発生が少なくなったり、そもそもテスト作業が減ったりする。
つまり、単にテストしなくなったから、バグが増えなくなって、S字のように見えるだけだ。
だから、次工程に進んでよい判定基準に使うことは難しい。

そんな事例を新人SEに話すと、彼らも実際の理論と現場の現実のギャップに気づいて、何かしら考えてくれる。
メトリクスは、若手にとって良い教育になると思っている。

【2】WF型開発とアジャイル開発を比べると、アジャイル開発はメトリクスを重視していると思っている。

【2-1】アジャイル開発の最大の利点は、直近のイテレーションで採取したメトリクスを、次のイテレーションですぐに使えることだ。
つまり、メトリクスのフィードバックをチームや次イテレーションに生かせる。

例えば、ある機能の障害が多発したならば、次回からはこんな対策を考えよう、と行動を促すこともできる。
あるいは、今回のイテレーションでは50枚のチケットを完了できたので、次回はこれぐらいの機能をリリースできるだろう、という見積りにも使える。

また、同一プロジェクトでメトリクスを採取できるので、イテレーションを繰り返すたびに、メトリクスの精度は理論上高くなる。
同じメンバーでチームを組んで、小刻みにリリースしていく開発スタイルならば、メトリクスを採取する前提条件があまり変わらないからだ。

アジャイル開発はメトリクスが取りやすい: プログラマの思索

【2-2】しかし、WF型開発はメトリクスを使いにくいと思っている。
テスト工程やリリース前の工程でメトリクスを採取したいと思っても、普通は障害が多発するために、メンバーもリーダーも忙しすぎてメトリクスを収集しにくい。
また、プロジェクト完了時にメトリクスを採取して、チームにフィードバックしたとしても、チームは解散してしまうので、そのノウハウをチームとして学習することができない。

つまり、せっかく採取したメトリクスをチームの学習やチームの成長に生かせないのだ。

本来は、障害分析や設計レビュー、課題の傾向分析などから、そのプロジェクトの知見、そのシステムのノウハウをチームは学習して、どんどん改善すべきなのだ。
しかし、普通は、要件定義と設計工程は元請、開発・単体テスト工程は下請けのように、メトリクスを採取する対象のメンバーが違うために、そのメトリクスをチームの成長に使いづらい弱点がある。

日本のSIでWF型開発を標準プロセスとして持っている企業は多いし、品質保証のためのメトリクスの知見も持っているのにも関わらず、そのメトリクスのフィードバックが開発チームの学習に生かされていないのではないか、と思っている。

【3】今後、僕が意識的に採取したいメトリクスがある。
それは、Velocityとサイクルタイム。

【3-1】その理由は簡単。
Velocityを計測することで、チームの生産能力を定量的に計測し、次のイテレーションや次の改善要望の見積りに生かしたい。
例えば、顧客から追加要望が来た時に、これぐらいの開発規模までならば、1か月以内にリリースできるだろう、と見積りしたいのだ。

あるいは、サイクルタイムを計測することで、リリースまでの平均待ち時間を計測し、顧客への回答に使いたい。
例えば、現在の仕掛中の作業を踏まえると、顧客から新たに受け取った追加要望は、リリースまで6週間待つ必要がある、と回答できるようにしたいのだ。

【3-2】Velocityとサイクルタイムは、Redmineのチケット集計で簡単に計測できる。

(1)サイクルタイム＝平均待ち時間＝チケットの平均滞留期間 or チケットの生存期間＝全ての完了チケットの開始日～終了日までの平均期間

(2)Velocity＝チームの生産能力＝1イテレーション(例：1ヶ月)の平均完了チケット数

ここから、待ち行列理論のリトルの法則を使えば、Velocityとサイクルタイム、WIP(仕掛かり制限)には下記の関係がある。

リトルの法則：サイクルタイム＝WIP/Velocity

※チームのWIP＝1サイクル(一つの工程)の仕掛中のチケット総数

例えば、作業中チケット(WIP)は30枚で、5枚/週ペースで完了(Velocity)できるなら、サイクルタイム＝30枚/5枚/週＝6週間になる。
つまり、顧客の新規要望がリリースされるまでに6週間かかることを意味している。
普通の感覚としては長すぎるので、チケットの優先順位を変えたり、チケットの取捨選択によって、リリースサイクルを短くするように改善するだろう。

「リーン開発の現場」はアジャイルサムライの再来となるかpart3～サイクルタイムとリトルの法則の関係: プログラマの思索

チケット駆動開発におけるサイクルタイムの計測方法～リーン開発で最も重要なメトリクス: プログラマの思索

【3-3】また「リーン開発の現場」に出てくるプロセスサイクル効率も採取したい。

プロセスサイクル効率＝実績工数/サイクルタイム

目的は、プロセスのムダを見える化できることだ。

例えば、機能Aの実績工数は1日なのに、完了させるまでに10日もかかっているとする。
すると、プロセスサイクル効率＝1日/10日＝10%なので、残りの9日間(90％)は、チケットが放置されたまま、何もしていない事実を意味している。

すなわち、チケットが放置された期間が長いほど、仕掛かり中の製品ないし作業が在庫として溜まっているので、無駄が発生していることになる。
普通のソフトウェア開発では、レビュー待ちや検証待ちや顧客回答待ちでチケットが放置されやすく、PLや上級PGや顧客がボトルネックになっている時が多い。
だから、そのようなボトルネックをなくすような対策を打たなければならない。

ただし、聴衆の方から指摘もあったけれど、実際のソフトウェア開発では、並列で作業する時が多い。
例えば、設計書が完成してレビュー待ちになれば、次の設計書の作成に取り掛かるように、並行作業している。
だから、待ち時間が長くても、さほど無意味ではない、と。

確かに、実際の現実はそんなケースが多いだろう。
しかし、トヨタの改善方式やリーン開発を考えると、作業の無駄を見える化することは、チームに気づきや行動の促進のために重要なことだと思っている。

【3-4】アジャイル開発のメトリクスでは、WF型開発のような品質保証のメトリクスよりも、見積りに関するメトリクスが多い特徴があるように思える。
この点では、アジャイル開発にかなり分があると思う。

上司や顧客にとっては、品質も重要だが、やはりコストや納期の方が知りたいからだ。
アジャイル開発の方が、数回のイテレーションを繰り返すたびに、チームが生み出すメトリクスは安定してくるはずなので、見積りの精度も上がるだろうと思う。
彼らは見積りにすごくこだわっているからだ。

アジャイル開発が見積りに関するメトリクスが多い理由はおそらく、顧客へ納品するという観点が強いために、いつリリースできるのか、を計測するメトリクスが研究されたからだろうと推測している。

Redmineによるチケット駆動開発は、そのようなメトリクス収集ツールの基盤として使えると思う。

【4】今後目指したいのは、工数集計の自動化だ。

月末の開発要員の工数報告を自動化したい。
どの会社でも、部課長がExcelで集計し直していて、とても労働集約的。
理論上は、Redmineチケットに実際の作業工数が入っているのだから、月次バッチ処理で出力できるはず。

また、EVMも理論上は実現可能だ。
EVMの利用目的は、現時点のチームの開発速度から、完成時総コスト見積り(EAC)を予測したいことだ。

それによって、当初の予算よりもコストオーバーになるのか、を知ることができる。
コストオーバーになる時期を予測できれば、その時期に合わせて、ヘルプ要員を投入するように要員計画を事前に立てることもできる。

また、要員表作成(リソースチャート)の自動化もやりたい。
案件の予定表に予定工数と開発要員をマッピングして、どの時期にどれくらいのスキルのメンバーが必要なのかを事前に計画したいのだ。
Javaができる開発者、Rubyの開発者、プロジェクト管理のできる人などのように、要求されるスキルのメンバーはすぐにかき集めることができないから。

しかも、PMのお仕事の殆どは要員表の管理であり、彼らはExcelやMSProjectでやっている。
とても労働集約的。

Redmineでは、WorkTimeプラグインで工数入力の機能やユーザインターフェイスは充実しているので、残る課題は工数集計の部分だ。

Redmine Lychee製品シリーズのEVMプラグインにはとても期待している。
できれば、Redmine Lychee製品シリーズは、MSProjectの機能をすべてRedmine上で実現してほしいと思う。

【公開】第6回品川Redmine勉強会発表資料「開発基盤としてのRedmine～Redmineをカスタマイズするポイント」　#47redmine: プログラマの思索

Lychee Enterprise

マネージャの仕事は、工数集計によるコスト管理、要員表の管理に尽きるからだ。
Redmineがプロジェクト管理用ERPになってしまえば解決できるだろうと思っている。

MS Projectを使いこなせない理由: プログラマの思索

RedmineのガントチャートはMS ProjectのWeb版になりうるか？: プログラマの思索

【5】パネルディスカッションで他の質疑応答で興味深かったのは、二つある。

【5-1】一つは、WBSをチケット管理する時の注意点について。

WBSからそのままチケットに落として、タスク管理することは可能だ。
しかし、神谷さんが言っていたように、WBSを再現したチケット管理は、開発者は楽しくない。
作業の開始日・終了日が決まっていて、納期も決まっているために、がんじがらめに作業する感覚になってしまうから。
むしろ、自分たちで気づいたときにチケットに作業を登録して、チケット管理していく方が楽しい。

また、WBSによるチケット管理ですべてのタスクを実現できるわけではない。
実際は、WBSで予定されていたタスク以外にも、想定していなかった仕様変更や改善要望が発生する。
当初の計画時には、どれくらいの課題が発生するか、どれくらいの障害が多発するか、を正確に予測するのは不可能。
つまり、WBSからこぼれ落ちる作業が結構多いのだ。
僕の感覚では、当初計画したチケットよりも2倍以上増えるのが普通だと思っている。

この解決方法としては、補完型チケット方式、あるいは、アダプタブルWFという手法がある。
つまり、計画外の作業管理に特化してRedmineでチケット管理していく方法だ。

ハイブリッドアジャイル開発・変形WF型開発のプロセスパターン from akipii Oga

この方法の利点は、WBSは従来のやり方のまま管理すればよく、顧客や上司向けに標準プロセスを変えたように見えないことがある。

【5-2】もう一つは、Redmine＋Subversionは相性が悪いのではないか、という指摘が聴衆の方からあった。

その方曰く。
ソフトウェア開発は、WF型開発のようなきれいな開発はほとんどない。
普通は、手戻り作業も発生するし、反復型開発に近い。
そして、並行開発が普通だ。

組み込み製品ならば、一つの製品シリーズに、ある一つの機能が追加されたとする。
すると、製品シリーズの全ての製品群に影響があり、その機能をマージしなければならない。
しかも、影響する機能も他にあるので、単純に移植するだけでなく、それぞれの製品に会った修正パッチをマージする必要がある。

しかし、Redmine＋Subversionでは、複数の製品へのマージ作業がやりにくい、と。

この指摘は正しいし、今後のRedmineの課題であると思っている。
その課題は、ソフトウェアプロダクトラインまたは派生開発をRedmineにどのようにマッピングして運用すべきか、ということ。

本来はGitを使うべきだが、RedmineとGitの相性はあまりよくないと言われている。
また、トピックブランチをチケットに対応付ける手法が一つの解決方法だと思うが、1個のトピックブランチから複数の製品群のブランチへマージする場合、GitHubのようなPullRequest機能がRedmineでは実現されていない。
「No Ticket, No Fork」という運用ルールも試されているが、それがすべての問題を解決するわけではない。

一つの修正が、複数の製品ブランチに影響を与える場合、それらの影響調査は現状は手作業しかないし、それらをチケット管理したとしても、あくまでもプロセスは管理できても、そのパッチ取り込みの妥当性はチケット管理では保証できない。
チケット管理はあくまでもプロセス管理に特化しているからだ。

また、トピックブランチがマージされた後に削除される場合、コミットログも消えてしまうために、トレーサビリティが保障されなくなる。
回避方法としては、マージする時に新たにチケットを関連付ける、マージする時のコミットログにチケット番号を書くなどがある。

第9回RxTstudy勉強会の感想～Redmineとチケット駆動開発の今後の課題　#RxTStudy: プログラマの思索

GitHubのプルリクエスト駆動におけるチケット駆動開発の問題点: プログラマの思索

この辺りの課題は今後も考えていきたいと思う。

【追記】他の人の感想を見つけたのでメモ。

「「チケット駆動開発とメトリクス」の感想」の感想 - Some Days You Get the Bear

(引用開始)
開発途中に生かされないこともそうだし、以降のプロジェクトにも生かされない。
まるで知見がその場その場で蒸発して抜けだしていっているようだ。
(中略)
どうもＷＦは何から何まで流してしまいやすいものだ。
(引用終了)

【追記2】他の講演者のスライドはコチラ。

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

チケット駆動開発とメトリクス from Makoto SAKAI