analog

Issue Tracking System can make you stupid

ITS（バグ管理システム）を用いることの悪影響の面について。

ITベンチャーのスピードを速くする１０の提案～エンジニア視点～ // 起業家・Webデザイナー・SE→CIOを目指しつつの大学生のアレ

細かいバグに追われてしまう気がしました。売り上げに直結するタスクは何なのか、優先順位をつけるという意志が薄くなってしまいがちです。

まあ記事全体について賛成なわけではないけれども、「バグ管理システムへの業務集約が過ぎると、個々の担当者が経営視点を忘れて近視眼的に動き出す」この点については、たしかにそういう傾向があると認めざるを得ない。

バグ管理システムにより、現場の担当者が近視眼的な作業に忙殺され、「経営的に意味のある作業（本来高い優先度であるべき作業）」と「経営的な意味のない作業（本来低い優先度あるいはスポイルすべきバグなど）」の区別がなくなり、経営的な意味での開発効率が落ちる。

具体的な病状としては、数十・数百のタスク・バグがあるときに、「技術的に片付けやすいタスク」からこなしがちである。本来は経営的な必要性によりタスクの優先順位が決められるべきであり、どんなに単独で粒度の大きい難しいタスクであっても、まずはそれをやらなければならない。「カエルを食べてしまえ！」だ。

注意すべきは、対処したバグの数、タスク数などだけで、例えばバーンダウンチャートなどで可視化すると、あたかも「我々は素晴らしくよくやっている」と勘違いできることだ。

そこでこれだ。

チケット駆動開発

とてもユニークだし、サテライト・ワーク、在宅ワーク、フリーエージェント型業務委託契約（脱「雇用」契約）などの普及から考えても、時代を先取りしたワークスタイル（単に「開発スタイル」を超えて）になりえるかもしれない。

ただ、上述の問題について、どういう考え方で対処しているのか、どのような実践をしているのか知りたい。

例えば、「どのタスクを処理すべきかは、個々の担当者が独断するのではなく、かならず案件の財務的な責任を負ったマネジャと一緒に意志決定する」ことにすれば、経営的視点が失われることはなさそう。これは一つの対処法になりえる。それ以外の方法もあるかもしれない。

あるいは実務的にTrac等のITSアプリにおいて何段階の優先順位(priorities)設定をしているか。 簡単に使うなら3段階でも可能だろう。しかしきちんとスコアリングすれば10段階で運用するケースもある（見たことがある）。具体的に何段階の優先順位を、それぞれどういう意味あいで使っているか、という情報も「チケット駆動開発」をやろうとする人たちにとっては大いに参考になるはずだ。