今回は、BacklogにITILのインシデント管理と問題管理を導入する方法を考えてみます。

これから述べさせていただくこと

イントロダクション

Backlogはプロジェクト管理ツールではありますが、サービスの保守や運用を行う際には、バグトラッキングシステム(以下、BTS)としても活用することができます。

提供しているサービスに何かしらのトラブルが発生した場合、課題*1を作成し、そこに発生した現象と解決方法を記載します。

さて、前項では解決方法と簡潔に書きましたが、そのトラブルは本当に解決したのでしょうか。

トラブルは根本解決よりも暫定対処による解消が先に望まれます。その為、暫定対処の後に以下を考慮する必要があります。

では、再発する場合、課題をどの単位で作成すれば有効活用できるのでしょうか。次項で考えてみます。

課題には未対応から完了までの状態があります。では、このトラブルに対する完了条件は何でしょうか。

根本解決でしょうか。それは一理あります。しかし、根本解決までに時間がかかってしまう場合、状態が処理中のまま、課題が残り続けることになります。

その間の再発と暫定対処は、同じ課題に記載しつづけるのでしょうか。再発した現象は必ず過去の現象と完全一致するとは限らない為、暫定対処もまた異なる可能性があります。これらをすべてひとつの課題に記載すると、個々の差がわかりづらくなってしまいます。

では、少し面倒ではありますが、課題を分けることにしましょう。

分ける単位は、次の3つです。

Backlogでは、課題キーを貼り付けると自動でリンクにしてくれるので、相互に課題キーを貼ることで参照性が高まります。

課題の内容が長くなったら、フェーズ毎に別課題を作成して相互に課題キーを貼ってます。後からの参照性は高いのですが、運用としては広められないので、 API で補助、ですかね。 #JBUG
— 加納誠人 (@ma310kano) 2019年4月23日

また、種別と課題テンプレートを活用することで、APIを使わずともある程度の複写が可能となります。

さて、ITILでは上記で分けた3つの課題のうち、1つ目と2つ目が「インシデント管理」、3つ目が「問題管理」となります。

インシデント管理で達成すべき条件は「ユーザーに対しての迅速な状況復帰」となります。ただし、課題の作成については発生時に作成した方がよい*4かと思います。

課題の状態と変更するタイミングを合わせた例を次に記載します。

一方、問題管理の達成すべき条件は「インシデントの原因究明と根本解決」となります。

こちらも課題の状態と変更するタイミングを合わせた例を次に記載します。

*1:BTSではチケットといいます。

*2:同じ手順で同じ現象が発生すること

*3:再発ごとに作成し、過去の課題を検索します。

*4:対処してからだと作成する意識が弱まってしまいます。