Redmine
Redmineが「インシデント管理」を得意なわけ
Redmineには「インシデント管理」に特化したバリエーションが存在しますが、そもそもなぜインシデント管理のためにRedmineが採用されたかと言えば、元々Redmineがソフトウェア開発の現場で期待されていたのは、障害を管理する機能が第一だったからです。
従来の障害管理は、主にExcelで管理されていました。ところが新たに導入したシステムの品質が良くないと、障害はどんどん増えていきます。その場合、Excelに残された記録と開発者らがやり取りしたメールは別のシステムに収められているわけですから、作業履歴は散らばっています。プロジェクトリーダーは最新状況を掴むのにもひと手間かかるわけです。さらにExcelファイルの肥大化によるクラッシュ問題、Excelデータを元に報告書を作る作業の煩雑さなども問題視されていました。
また、障害修正でも問題が起きていました。障害は特定の機能に集中する傾向があるので、1人の開発者に負荷が集中してボトルネックになりがちでしたし、Excelでは担当者の作業負荷の大小も把握しづらかったので、結果として障害検証が滞り、障害が放置されることがありました。つまり、プロジェクトリーダーがきちんと状況を把握できていなければ、作業工数が浪費されるという問題があったのです。
加えて、プロジェクトがテストの段階に差し掛かった場合、リリース管理が必要になりますが、Excelではこの管理も煩雑でした。過去のリリース記録から障害を探すのにも手間がかかり、情報の連携を欠いてしまうこともありました。
これらの問題は、RedmineをBTS（Bug Tracking System）として使うことで一気に解決できます。
まず、障害報告はすべてチケットに集約します。Excelの障害管理台帳は必要なくなり、障害修正と障害検証の記録はチケットのコメントに蓄積されていくわけです。修正・検証に伴う担当者間のやり取りもRedmineに記録することができます。つまりチケットによってワークフローも制御できるようになるのです。
さらに、チケット集計機能を使えば多種多様なレポートを簡単に作れますし、ロードマップ画面を使えばリリース計画を作成することもできます。
