チケットは京大式カード～1チケット1コンテンツ

RedmineのようなITSのチケットについて考えたことをラフなメモ書き。
以下はアイデアを殴り書き。
あとでまとめ直す。

【元ネタ】
メインページ - PoIC

時代に逆行するカードによる情報整理が熱い : ミームの死骸を越えてゆけ

【1】チケット駆動開発における「チケット」とは一体何だろう？
本来は、BTSの障害管理票。
ITSにおいては、Issueつまり課題票に相当する。

そして、Tracでは「チケット」と呼ばれている。
Tracのチケットの種類には、障害や課題だけでなくタスクも初期登録されていた。
@machuさんは、Tracのチケット管理をソフトウェア開発のタスク管理に適用するアイデアをチケット駆動開発と呼ばれた。
そこから、チケットはタスクを意味する時が多くなった。

チケット駆動開発の強みは、トレーサビリティとワークフロー管理だ。
チケットとソース管理のリビジョンが相互リンクされることで、成果物から仕様の追跡が可能になる。
また、チケットのステータス管理の背後にあるワークフロー管理から、チケットの申請・承認を運用フローに合わせてカスタマイズできる。

最近は、チケット管理をヘルプデスク管理・PC資産管理・工数管理などにも適用する事例がある。
つまり、本来のチケット駆動開発を他業務へ拡張したやり方がいくつかあるのではないか？
例えば、チケットは障害、課題、タスクだけでなく、問合せや資産、工数記録などにも使える。

そもそもチケットとは何だろうか？

【2】下記の記事を読んで、チケットは京大式カードではないかと気づいた。

メインページ - PoIC

京大式カードは、「知的生産の技術」で提唱されたアイデアカード。
野外で動物や現象を観測する学者が、屋外でも手軽に記録できるような5*6インチのカード。

上記の記事にあるPoIC (Pile of Index Cards：情報カードの積み重ね)とは、京大式カードを発展させたアイデアのようだ。

(引用開始)
PoIC のエッセンスは極めてシンプルに表現することができます。
・頭の中のアイディア・身の回りの情報を、カードを使って収集する
・それを箱の中にすべて時系列で保存していく
・それをあとで利用し、新しい知恵・知識・成果の再生産を行う
PoIC の目的は、この3行を成し遂げるためのものにほかなりません。
(引用終了)

京大式カードで重要な原則はいくつかある。
一つは、1カード1ファクトの原則。
つまり、1カードには1個の事実やアイデアを書く。
カードは惜しみなく使って、どんどん記録する。

もう一つは、収集したカードを並べて、カード間の関連から未知の法則を再発見すること。
KJ法もその一環だろう。

京大式カードで記録した事実から、新たな法則を再発見し、そこから普遍的な理論を編み出していくやり方。
京大のサル学や文化人類学は、こういう技術を用いて研究されていたわけだ。

【3】チケットが京大式カードではないかという発想は、@sakaba37さんが「チケットは備忘録」と言われていることとほぼ同等だ。

チケットは、ソフトウェア開発に必要な情報をとにかく記録していく。
チケットに残れば、チケット集計のビューによって、ガントチャート、バグ収束曲線、タスクボード、バーンダウンチャート、EVMなどのように色んな観点でメトリクスを集計できる。
そして、チケットを関連付けたり、親子チケットにすることで、チケットの情報を参照しやすくできる。
最終的には、チケットから得られたノウハウは集約して、ナレッジとして資産化する。

そのナレッジは、パターン形式で書くことができるだろう。
どんな状況でどんな問題に対して、どんな手法が効果的で解決できたのか。

チケットを単に記録して収集するだけでは意味が無い。
定期的に棚卸しして、チケットを最新化したり、チケットから得られたノウハウをチームで共有する。
そのやり方は、まさにチケットを収納したボックスから、チケット間の関係を見出し、一つのパターンにまとめて、チームで流通できるようにすること。

それらの原則をまとめると、チケットでも下記にまとめられるのではないか。
一つは、1チケット1コンテンツ。
つまり、チケット1枚には、1個の情報を記録する。
惜しみなくチケットに記録していく。

もう一つは、チケット間の関連から新たなパターンを再発見し、実践知として抽出する。
それらパターンは相互に関連し合い、パターン言語をなす。
SECIモデルと関連付けることもできるだろう。