ciklone blogをご覧の皆さま、こんにちは！

今回は、cikloneを使って、部門レベルにおいて課題、バグ情報の共有を実現したE社様の導入事例をご紹介いたします。

課題やバグ情報を共有したい

E社様では、新製品の開発や既存製品の顧客の声、設計障害、クレームをプロジェクトごとに管理し、情報共有はすべてメールで行っていました。しかし、次の問題点がありました。

• • 日々処理すべきメールの量が多く、現場では全てのバグ・クレームに対応できない
  • 本当に対応が必要な未処理のバグについての対処状況が把握できない
  • バグ・故障の対処を過去に遡って追跡できない
  • 優先度が低いが重要な作業など、対処されないまま放置されるバグ・クレームが過去にあった

そこで、cikloneを全部門に導入して、製品の設計・開発で発生する設計上のミス、ソフトウェアバグの障害に対して、漏れなく記録するためのバグ管理データベースを構築する必要がありました。

Ｅ社様では、情報共有方法としてメールが浸透していたため、「バグ・クレームがcikloneに登録・更新されるとメールによるアラート通知を行う」ワークフローを採用することにしました。

ciklone導入によるワークフロー検討

下図に示すワークフローに従って、バグ・クレームのcikloneへの登録・更新作業を行います。

チケットのワークフロー

1. 発行者からのメールに対応してチケットを登録（バグの発生・起票）
2. プロジェクト管理者がソフトウェアチームにアサイン（担当グループ振分）
3. 担当部署が異なっていたためインフラチームに再アサイン
4. インフラチームの担当者に振分（担当者振分）
5. 担当者が調査内容をアップロード
6. バグ修正をソースに反映（バージョン管理）し、 テスターによる動作確認完了後に、プロジェクト管理者がバグのクローズを宣言

新ワークフローの評価

上記①から⑦の流れにより、バグの発生から完了までをバグ管理データベースで管理できるので、利用者からは次のような評価をいただきました。

問題点の登録作業が容易になった

問題発見者と設計者、品質管理チームの情報共有ができるようになった

障害内容が即座に共有できるので、開発者の製品に対する問題認識が上がった

バグ報告書の作成や履歴管理が不要なので、作業効率が向上した

サーバ側で情報を一元管理するため、二重修正、修正漏れ、認識誤りなどがなくなった

導入の決め手

cikloneで現場主導による課題、バグを漏れなく管理できるようになったことが導入の決め手でした。クレームの対処が確実にできるようになっただけではなく、お客様からの情報を収集・分析してフィードバックするしかけもできたので、E社様の今後の製品開発が期待できますね。

なお、E社様ではcikloneを導入するために、各ユーザに利用してもらうための自社にあった運用ルールの作成、社員への研修が必要だったのですが、弊社の「導入研修サービス」によってスムーズに利用をはじめることが出来ました。

cikloneは無料版での利用が可能です。皆さまも是非、御検討下さい。

Tweet