ストック型チケットは記憶媒体、フロー型チケットは流通媒体

「ストック型チケットは記憶媒体、フロー型チケットは流通媒体」というアイデアについてメモ。

【参考】
Redmineによるチケット駆動開発はストック型プロセスとフロー型プロセスの二面性を持つ: プログラマの思索

【1】Redmineのチケットは、ストックとフローの二面性を持つ。
ストック型チケットは、障害管理票や課題管理票、WBSなどの記録媒体。

フロー型チケットは、流通媒体。
例えば、Agile開発やカンバン駆動開発のストーリーカードやタスクカード、申請承認ワークフローの申請書に相当する。

ストック型とフロー型のチケットシステムでは、どんな違いがあるのか？

【2】ストック型のメリットは、記憶媒体なので、チケットが蓄積されるほどナレッジ資産になる。
【2-1】下記の記事で、記憶媒体のチケットが集計されること、蓄積されていつでも検索できることのメリットが十分に明確にされている。

自分にとってのチケット駆動開発 @ アールケー開発

(引用開始)
最近だと主にアプリの開発ということが多いのですが、開発スタイルって色々ありますが、ここ数年、体になじんでいるものに、「チケット駆動開発」があります。

チケット駆動開発は、不具合だけではなく、タスクなども含めて、行う作業を全てチケットとして登録し、チケット単位でコミットを行います。SCMとチケット管理を連携させることで、コードの追跡もチケット単位で行います。

SCMには、Gitを使っているので、チケット単位でブランチを作るようにしました。そのおかげで、コミット自体はチケットの中で細かく行っても良くなりました。

数年、行って、やっと体になじんで、Gitの良さも感じられるようになってきました。最近思うのですが、このチケット管理という手法も語弊を恐れずに言えば、記録が残るということが最も重要な点だと思います。

開発中はチケット単位でタスクが管理されることで、現在の状況が整理されて、視覚化される。開発完了後は、どのように状況が推移していったかが検証できる。次のバージョンや関連する事象が起きたときには、当時はどうだったのか？何を行ったのかが記録に残っている。開発として重要な記録は、どのようなコード変更を行ったかだと思います。

そして、これらが蓄積されると資産になります。最近では、新しい機能の開発中に、影響することを調べるためや、特定のコードに対する理由を調べるのに、過去のチケットを参照することがあります。これも、チケットが蓄積されてきて、価値が出てきたからです。
(引用終了)

【2-2】しかし、記憶媒体のチケットの弱点はいくつかある。
入力項目が多くなりすぎたり、チケット内容を詳細に書く時間がかかりすぎるなど、チケット入力の運用が多少面倒になることだろう。
チケット入力のコストが大きくなるほど、チケット入力が億劫になり、チケットの保守ができなくなりやすい。

また、管理の度合いも強まるだろう。
本来は、チケットの精度が良ければ、いろんな観点のチケット集計機能を使うことで、多種多様なレポートやメトリクスを出力することができる。
それらレポートやメトリクスを使えば、プロジェクト運営のリスク管理に大きく役立てることができる。

でも、そのメリットも、メンバーがチケット入力を嫌がらずに作業してくれるのが前提だ。
この辺りの運用ルールはトレードオフになるかもしれない。

【3】フロー型チケットのメリットは、タスクがサクサク流れるので、作業のリズムが生まれることだろう。

【3-1】チケット駆動開発の最大のメリットは、開発のリズムが自然に出てくること。
朝に出社したら、チケット一覧で今日やるべき自分のチケットを決めた後、チケットに従って作業して、退社間際にチケットをCloseする運用になる。
この運用がメンバーごとにスムーズに流れるようになれば、チームの生産性は大きく上がる。

例えば、XPやScrumのように、イテレーション単位に小規模リリースする開発するスタイルでも良いし、カンバン駆動開発のように、WIPという仕掛り量の最大値に気を付けながらタスクを流すスタイルでも良い。

フロー型チケットシステムであるカンバン駆動開発の記事は下記がすごく参考になる。
やはり、ストック型チケット駆動を完璧にやろうとすると、開発プロセスが重量化しがちで、本来のチケット駆動の良さが失われがち。

カンバン駆動開発 - Trello, Slackで始めるKDD from Kazuya Takahashi

【3-2】しかし、流通媒体のチケットの弱点は、ナレッジ資産になりにくいことだろう。
タスクをサクサク流すことに注力するために、入力内容がおろそかになる時がある。
すると、完了したチケットには情報量が少ないので、蓄積されたナレッジになりにくい。

蓄積された完了チケットは、せいぜい、開始日や終了日、枚数の集計ぐらいしか使えないだろう。

【4】ストック型チケットとフロー型チケットでは、出力されるメトリクスが異なるように思える。

例えば、ストック型チケットは、ソフトウェア工学の品質管理やPMBOKのスケジュール管理・コスト管理で使われるメトリクスを集計しやすい。
例えば、信頼度成長曲線、障害のパレート分析などがある。
あるいは、EVM、要員表、稼働率、進捗遅れ日数などが出力できる。

フロー型チケットは、アジャイル開発で使われるメトリクスが多い気がする。
例えば、Velocity(イテレーション単位の開発規模、または開発速度)、サイクルタイム(ステータス更新にかかる作業時間)、スループット(チケット完了率)などがある。

ストック型チケットとフロー型チケットのメトリクスの違いを見ると、やはりストック型チケットの方がメトリクスの種類が多い。
管理者であれば、ストック型チケットの方が多種多様なメトリクスを、飛行機の操縦室にある計測器のように扱いたいだろう。

フロー型チケットのメトリクスは、チケットの流通量に関する指標が多い。
チケットが流れる速度が速いほど、作業はサクサク流れていることになる。

だが、チケットの流通量に関するメトリクスと稼働率や生産性の関連性があるのか、が興味あるところだ。
個人的な経験では、関連性は強いと思うが、それを実証することができるか？

いろいろ考えてみたい。