チケット駆動開発がWF型開発と相性が悪い理由

「SIの現場で使えるチケット駆動開発｜セミナー｜Growth xPartners Corporate Site」セミナーをUStreamで聞いて、思ったことをメモ書き。

【元ネタ】
2013/08/24（土）「SIの現場で使えるチケット駆動開発」セミナー #gxptech - Togetter

【１】Excelによるプロジェクト管理は、計画作成時はまだしも、その後の実績管理の運用では、利点よりもたくさんの弊害の方が出てくると思う。

Twitter / akipii: #gxptech　Excelの最大の弱点はコミュニケーションが閉じてしまうことかな。更新する人しか最新情報を知らない。メールにExcelを添付されても、その履歴を追跡するは面倒。Excel駆動とメール駆動の開発は表裏一体だと思う。

しかし、最近はRedmineを導入したものの、思ったような効果が出ていない事例をよく聞く。
話を聞くと、Redmineによるチケット駆動開発をそのままWF型開発を当てはめようとして、うまくいっていないという事例が多い。

Twitter / akipii: #gxptech @yusuke_arclamp はい、最近はRedmineを導入してもその効果を余り感じない事例をよく聞きます。開発業務の管理が混乱してる現場には即効果がありますが、管理業務が既にある所では、別の問題があり、ツールだけではない運用ルールが必要と思います。

Twitter / Sean_SF: 「BTSをプロジェクト管理に使えるのか？」という話題は盛り上がる。ウォーターフォール型が多い日本のプロジェクトにおいて、BTS、チケット駆動開発をどう取り入れていくのか。取り入れたいんだけどうまくいっていないと悩んでいるリーダーが多いんだろうなぁ #gxptech

【２】Redmineのガントチャートでタスク管理しようとする場合、MSProjectと異なる点は、チケットの粒度が異なる点と予実管理ができない点があげられる。

顧客やプロマネの観点と開発者の観点でチケットの粒度が異なる理由は、以下に既に書いた。

チケット駆動開発は進捗報告作りをどのように解決しようとするか？: プログラマの思索

予実管理がRedmineではやりにくい理由は、Redmineチケットに、予定の開始・終了日と実績の開始・終了日が区別されておらず、実績管理しかできないように機能実装されているからだ。
つまり、Redmineでは、本来チケット管理で予実管理を厳密に運営することは想定されていない設計思想で作られている。
だから、WF型開発でチケット駆動開発をやろうとすると、予定に合わせるようにタスクを調整するマネジメント手法が正直使いづらい。

Twitter / digitalsoul0124: "BTSについているガントチャートは何なんだ　ガントチャートはタスクの前後関係が見える。それに対して、チケットで管理するのは総量" #gxptech

Twitter / akipii: #gxptech　Redmineにガントチャートを欲しがるPMは予実管理がやりたいが、チケットは実績管理しかできない設計思想になっている。予定管理をチケットでやろうとするとカスタマイズが必要になる。その食い違いがチケット駆動でWF型開発をやろうとして失敗しがちなのだと思います。

WF型開発は、当初の計画で決められた予定をベースラインとして、実績として発生したタスクを合わせようとして、変化を抑えこむやり方。
計画で作成された予定作業がコロコロ変わると、ベースラインとして意味がなくなってしまう。
予実管理によって、予定よりも遅れたタスクに注目して是正対策を取る。

チケット駆動開発では、ロードマップのビューを主に使って、決められた期限までにどれだけのタスクを実現するか、という観点で、スコープ管理する発想。
タイムボックスという箱に、状況に合わせてチケットを詰め込むやり方。
だから、チケットという作業スコープに着目して、チケット管理していく。

Twitter / akipii:#gxptech ガントチャートを使って予実管理する手法では、予定した計画にいかに実績を合わせて、変化を抑えこむのを目的とする。チケット駆動はアジャイル開発と同じ設計思想で、スコープ管理の観点で計画偏差という変化を制御しようとする。やり方は全く違うと思います。

チケット駆動開発では、チケットに予定日を入れたとしても、ロードマップに当てはまるように随時調整するため、予定日は意味をなさない。
つまり、チケット駆動開発はアジャイル開発と同様に、計画と実績の偏差(ばらつき)に着目して、タイムボックスに入るようにタスクを調整する。

つまり、プロジェクト管理におけるWF型開発のやり方とチケット駆動開発のやり方は全く発想が違う。
他にもWF型開発に囚われすぎたアンチパターンについては以前まとめた。

WF型開発にとらわれすぎたTiDDのアンチパターン #tidd: プログラマの思索

【公開】RedmineのFAQとアンチパターン集 #Rxtstudy: プログラマの思索

このようなアンチパターンが発生する原因は、BTSから生まれたチケット駆動開発が当初の利用範囲から外れた箇所に適用されたためだろうと思っている。

【２】では、WF型開発にチケット駆動開発を適用するには、どんな手法が必要か？

チケットで予実管理をやりたいならば、チケットに予定・実績の開始・終了日を設けるようなカスタマイズが必要だろう。
また、進捗管理が一目でわかるような、ロードマップとは違う別のビューが必要だろう。
多分、ガントチャートをもっとカスタマイズする必要があるだろう。

あるいは、CCPMのような発想を取り入れるといいかもしれない。
つまり、計画作成時に予定されたチケットを作るが、チケットに実績情報を入力する時に、残工数がひと目で分かるようにして、プロジェクト全体の残工数で進捗管理する手法を取ること。

Twitter / sakaba37: CCPM的ですね。RT @pato_taityo: … @yusuke_arclamp さん…計画に対する遅れがすぐわかるようにあえてギリギリのスケジュールを設定する。遅れが出たらその遅れの種類を見極める。そしてその種類に応じて残しておいたバッファで対応する。 #gxptech

個人的には、純粋なWF型開発をそのままチケット駆動開発に適用した場合、カスタマイズすれば運用できるだろうが、チケット駆動開発の利点が消えてしまうため、恩恵がなくなるのではないかと思っている。

WF型開発へのチケット駆動開発の適用方法については、@sakaba37さんが「アダプタブルウォーターフォール」という概念で説明されているので、そちらを御覧ください。

【３】では、Redmineによるチケット管理は万能なのか？

@yusuke_arclamp さんや@digitalsoul0124さんも話されていたが、担当者が決まらないチケットは、チケットとして起票してもあまり意味を成さない。
例えば、WBS作成時は、詳細なタスクが分からない項目もまずは空き箱として配置できるが、チケットに起票したとしても、そのチケットからどのように作業していけばよいか分からないから、放置されやすい。

Twitter / akipii: #gxptech　WBSでは曖昧な課題やタスクを空箱として配置できるが、チケットは曖昧なタスクを登録しても運用しにくい。@yusuke_arclamp さん談。

Twitter / akipii: #gxptech　チケットはソフトウェアの改修に関する情報が集まって更新されて流れるもの。(和智さん談)　チケットは「型はあって形はない」方が良いのでは。チケット駆動は期限までに担当者がチケットを完了させる仕組みではなく、活性化させるもの。(鈴木さん談)

また、「チケット管理は予実管理しにくい」という特徴から、チケット管理のモデルを考えると、チケットはマスタではなくトランザクションである。
つまり、チケットは、予定というマスタ情報を蓄積するのではなく、実績としてトランザクションを日々記録していく方が向いている。
だから、チケットを元帳のように扱うことには向いていない。
むしろ、GTDのように、次々に発生するタスクをどんどん消化していくやり方の方がチケット管理に向いている。

最近、Redmineによるチケット管理をヘルプデスク管理や顧客管理、資産管理に使う発想が試されている。
日々のトランザクションを管理する点はチケット管理は最強だが、顧客マスタやPC資産マスタというマスタ情報(元帳)はチケットではなく、別のマスタを用意する方が扱いやすい。

つまり、チケット管理がうまく当てはまる業務であるか否かという判断条件は、チケット管理のモデルの特徴に大きく依存していると考えている。
この辺りは今後まとめてみたい。

【追記】
@yusuke_arclampさんや@sakaba37さんも、チケット駆動による進捗管理についてBlogを書かれている。

ITS/BTSは進捗管理に使えるのか - SIの現場で使えるチケット駆動開発 - arclamp

[#TiDD] チケット駆動開発をプロジェクト管理の視点だけで考えてはいけない #gxptech: ソフトウェアさかば