情報システム部門がTiDDを運用する時の注意点

ユーザ企業の情報システム部門がチケット駆動開発を運用する場合の注意点を考えてみた。
以下メモ書き。

情報システム部門は、その企業の業務を遂行するために必要なシステムに関する仕事を担当している。
現代では、業務システムは企業のインフラ。
電気や水道が止まったら家で生活できないように、業務システムが止まったら会社で仕事できない。
だから、CIOはCEOに次ぐ重要な役割を担っているはず。
しかし、日々の雑務に追われている割には、他部署からコストセンターと思われて大変だと思う。

情報システム部門は、企業規模や担当範囲によって、その役割は大きく異なる。
想像すると、次の3つのパターンに分けられると思う。

１・業務システムの運用保守以外に、内製(自社開発)も行っている
２・業務システムの運用保守だけ。
３・運用保守すらアウトソーシングし、企画・発注のみ行っている

１は、自社に開発部隊があるので、かなりの技術力を持っている。
２は、サーバーやPCなどハードウェアの運用保守が中心。PCの資産管理や他部門からの問い合わせ対応が多い。
３は、システムの企画や発注だけ自分たちで行い、開発も運用保守もアウトソーシングしている。

チケット駆動開発を上記の3パターンのユーザ企業が運用する場合、どのように使うと効果的だろうか？

１の場合、我々開発者がTiDDを使っているパターンと同じだ。
BTSをバグ管理だけでなく、SW開発のタスク管理にも使う。
利点は、開発チームのタスク管理がスムーズになること、そして進捗報告が楽になることだ。
導入も簡単だし、BTSのサーバーの保守も自分たちでできるだろう。
チケット駆動開発の運用方法も、バグ管理に慣れているだろうから、スムーズに慣れるだろう。

２の場合、BTSをITILで言うインシデント管理や問題管理の場面で使うと良いだろう。
ユーザ企業の他部門から、ネットが接続できない、とか、セキュリティパッチはどうするの？とか、詰まらない問合せが結構多いはず。
それらの問合せは、インシデントとしてBTSに登録し、インシデント管理プロセスに当てはめる。
更に、インシデントの根本原因に対して対策を講じた方が良い場合、問題管理プロセスで是正対策を講じる。
例えば、問合せを減らすには既存システムに機能追加した方がいい、という判断ならば、他部署や上司へエスカレーションしたり、SIerへ発注したりする。

つまり、BTSをチケット駆動開発へ拡張して運用する方法が基本になる。
Webサーバー設置は慣れているだろうが、BTSの経験も少ないと思われるので、チケット駆動開発の運用ルールにまず慣れてもらう必要があるだろう。

３の場合、BTSの使い道として、発注するシステムの要件管理に使う場合と、発注したシステムを受入テストで確認する場合の2種類があると思われる。

前者の場合、高機能なBTSでなければ要件管理として扱いづらいし、チケット駆動開発でチケットをストーリーカードとして扱う方法は難度が高い。
後者の場合、受入テストのテストケースはTestLinkで運用し、納品モジュールのバージョン単位にBTSでバグ管理していく運用になるだろう。
この場合も、テスト管理ツールとBTSを連携する必要があるし、チケット駆動開発の使い方としては難度が高い。

つまり、チケット駆動開発でも高度な運用方法が必要な上に、Webサーバーにも慣れていないだろうから、チケット駆動開発の導入はかなり難しいだろうと思う。

しかし、いずれの3種類の情報システム部門であっても、チケット駆動開発によって、日々のタスク管理が可能になるし、リアルタイムに進捗情報や傾向分析を得ることができる。
上手に使いこなせれば、業務を分析した結果を元に、業務の改善も可能になるだろう。
しかもオープンソースのツールを駆使するので、サーバーの知識さえあれば、基本的に無料で運用できる。

色々な状況でチケット駆動開発の運用が耐えれるか、考察してみたい。