[#TiDD] 計算量から考えるチケット駆動開発の効率化

あの議論、あのファイルはどこだっけ？
あっちで探し、こっちで探し、キーワードを変えてみたり、、。
チケットで情報を適切に管理したなら、もっとうまく探せます。
チケット駆動開発を効率化する方法を計算量から考えてみました。

計算量とは

計算量とは必要な計算時間や必要な記憶領域の量が、入力に対してどれくらい変化するかを示す指標でO（オーダ）で示します。代表的な例を以下に示します（いい加減な説明です。ご存じの方は優しく読み飛ばしてください）。

$O(N^2)$：
バブルソートのようにデータ数（N) のループを2重に実行しないといけない場合です。データ量が増えると爆発的に処理時間が増えます。

$O(N)$：
配列のデータを探すなどデータ数（N) の単純なループで実行できる場合です。データ量に比例して処理時間がかかります。

$O(logN)$：
木構造にデータが順にある場合、木の高さだけの処理回数で検索できます。データ数がNの2分木の場合は$log_2N$になります。オーダで示す場合は底を省略して$O(logN)$で示します。データ量が増えても$O(N)$よりは緩やかに処理時間が増えます。

$O(1)$：
ハッシュや指定されたインデックスのデータを配列から取り出す場合は、データ量に関係なく、常に一定時間で取り出すことができます。これを$O(1)$で示します。

データ量によってどのように変わるかを以下に示します。$O(N^2)$が爆発的に増えているほか、$O(N)$もデータ量が増えると検索が大変なこと、$O(logN)$や$O(1)$が効率的なこと、がわかるでしょう。

N	2	4	8	16	32
$N^2$	4	16	64	256	1024
$N$	2	4	8	16	32
$log_2N$	1	2	3	4	5
$1$	1	1	1	1	1

効率的なチケット構造

全文検索

全文検索でチケットを探す場合を考えましょう。
キーワードを変えながら何度か検索し、検索結果のリストからチケットを探します。検索そのものは色々な高速化の方法があるようで、大量のチケットから3秒で探せる環境もあるようです。検索そのものは$O(1)$と考えてもよいかもしれません。しかし検索結果から探す行為は$O(N)$ですし、キーワードを変えて繰り返す行為もキーワードをうまく考えないと$O(N)$になりそうです。データ量が異なる$O(N)$の処理が2重になる可能性があります。
このような全文検索を効率化するには後述の用語の統一が必要になります。

Wiki

プロジェクトのプロセスや成果物を基準にチケットのリンクをWikiにまとめます。慣れてくると$O(1)$で探せるかもしれません。
しかしチケットの数が増えてきて、Wikiページが肥大化してしまったり、同じ項目にチケット番号を並べてしまうと$O(N)$の検索になるかもしれません。
これを改善するにはWikiを階層的に構成すると、ページを検索する部分は$O(logN)$で探せるようになるでしょう。ページの肥大化や並んだチケット番号から探すことも減るかもしれません。
しかし、そのような構造化されたWikiの作成や最新化は負担が大きいでしょう。そこで親子チケットを考えます。

親子チケット

チケットの親子関係を利用して木構造を作れば、$O(logN)$で検索することができます。トップレベル以外は必ず親子関係にすることをルールにすれば、容易に木構造を構築できます。プロジェクト計画や監査対象一覧をWikiにしておいて、上位のチケットをリンクしておくと便利でしょう。
木構造の検索が$O(logN)$でできる条件は、すべてのチケットが一定のルールで適切なバランスで分割できている場合です。一つの親チケットにたくさんのチケットがランダムに並んでいれば、そこで$O(N)$の検索が必要になります。また、議論の結果を知りたいのに長い議論をすべて読まないとわからないようになっていたなら、$O(N)$の検索になってしまうでしょう。後述のような運用の工夫が必要です。
（チケットシステムによっては親子関係の段数に制限があるかもしれません。その場合は関連を使うなど工夫してください）

効率化に向けたルール

ここまで計算量をもとにチケットの構造に関しての効率化を考えました。ここでは書くべき内容のルールで効率化を考えます。

リポジトリとの紐づけ

チケットとリポジトリのファイル更新を紐づけることができます。複数の障害の原因になる不具合によるファイル更新時などには、複数のチケットと紐づけることで、チケットからの検索が容易になります。

用語や分類の統一

効率よく検索するには用語の統一や分類のルール化が必要です。全文検索でキーワードを変えたり、似て非なるチケットを探すと$O(N)$の処理になり、その回数倍の検索が必要になります。業務の用語、成果物やテストの種類、作業、といった名称を統一しておけば何度も検索をやり直したり、検索する際に迷うことも少なくなるでしょう。
仕様書の用語集や標準プロセスの定義があればそれを活用しましょう。SLCPやBOKなどの用語を標準として使うのも良いでしょう。

運用の工夫

ようやくチケットにたどり着いても、議論が延々と集いていて結論になかなかたどり着けなかったり、結論がよくわからず誤解することもあるでしょう。議論した後はチケットの詳細に結論を簡潔に書いておけば良いでしょう。結論がすぐにわかりますし、誤解も減るでしょう。
最近はチャット中心のツールを併用することも多いでしょう。テキストだけでなく、リアルタイムで通話できたり、会議室があったり、それぞれにファイルが置けるなど、便利ではありますが、ファイルや議論のステータスの管理が難しくなりがちです。主要なファイルの配置や議論の後は、ファイルや議論へのリンクやまとめを、チケットあるいはWikiで管理すると良いでしょう。

まとめ

チケット駆動開発はチケットを中心にプロジェクトを回す手法です。チケットを見れば求めている情報を効率的に検索し、日々チケットを確認して開発を進める。さらにはチケットに依存して、チケットを見なければ日々の作業が進まないような文化を熟成できれば、効率的で混乱の少ないプロジェクトを実現できるでしょう。
ここで述べた内容は一例にすぎません。例えばデフォルトの担当を決めておけば、担当が割り当てられていない作業をなくせるなど、いろいろ工夫できるでしょう。皆さんの組織文化や開発体制に合わせて開発の効率化を進めてください。