Close

インシデント管理改善への道はここから始まります

Jira Service Management でバグを追跡するための 4 つのベスト プラクティス

開発者と IT サポートが一致団結することで、バグが組織に悪影響を与えることがなくなります。

システムに潜むバグを迅速に特定して根絶する能力は、顧客満足度の向上に大きく貢献します。多くの場合、開発者と IT サポート間のコラボレーションが必要であり、サポート エージェントから開発者への引き継ぎは重要でありながら、たやすく手違いが発生します。特に、解決までの時間を短縮し、ユーザーを満足させようとしているときには、両者の連携が不可欠です。

適切なツールとプラクティスを用意しておけば、バグによって組織が緊急停止に陥り、多大な損失を被るのを防ぐことができます。そのため、私たちは、開発、IT、およびその他のチームがシームレスに連携できるよう、Jira を構築しました。また、Jira Service Management を使用すれば、インシデントおよび問題管理を行うための追加の専用機能にアクセスできます。

何よりもまず、バグ報告を奨励する文化を作ることが重要です。熱心でやる気のあるバグ報告者は、注意深く目を配り、時間を割いて実際に報告を提出する傾向があります。

バグ報告を奨励するためのアイデア

バグ報奨金制度の設立

ソフトウェアの問題を発見した人に報奨を与えることは、賢明な投資です。コードの開発者やテスト担当者に投資すれば、専任チームを雇う必要はありません。カリフォルニア大学バークレー校の調査によると、「バグ報奨金制度」が大きな成果を上げています。

Google の脆弱性報酬プログラムでは、$100 から $20,000 がスライド制で支払われます。どこで誰に聞いても、$20,000 相当のバグを見つけるためとなれば喜んでちょっとした調査をするでしょう。Google では、脆弱性や悪用のレベルを難易度や影響などの要因で判断しています。「Google の平均支払い額は $1,000 ですが、はるかに高い報酬を獲得できるかもしれないという可能性が動機となって、多くの人々がそのプログラムに参加しているようです」と研究者は書いています。実によく分かります。人間は捕った獲物と引き換えに報酬を得るのが大好きなのです。

一般の人々に脆弱性を見つけてもらうのも 1 つの方法ですが、同様に、社内のスタッフに報酬を与えることもできます。Skyscanner には「Skytrek」と呼ばれる報酬プログラムがあり、バグを報告したスタッフに報酬を与えます。「誰もが自社製品を使用することを常に奨励されています。従業員の場合は、[report feedback (フィードバックを報告する)] というボタンがウェブサイトに表示されます。このボタンを押すと Jira Service Management カスタマー ポータルに移動し、そこでバグを送信できます」と、ビジネス ツールのチーム リーダー Michael Hall 氏は言います。毎週、トリアージ チームが文書の質に基づいて「今週のバグ」を選びます。

バグ報告に関する話題が出たついでに、バグ追跡をできるだけ簡単にするための主な考慮事項をいくつかご紹介します。バグ追跡の両面、つまり、ユーザーが簡単に正しい情報を記録してレポートを提出できるようにすること、そしてバグの通知を受け取った担当者がバグを解決できるようにすることを考慮することが重要です。

これらのベスト プラクティスを使用して、厄介なバグを追跡し、潰しましょう。

1. バグ レポートの提出を行う一元的な場所を作成する

ヘルプ センターを設置して、ユーザーがバグ報告やその他のサービス リクエストを一元的に行えるようにします。ヘルプ センターは、店頭のディスプレイ ウィンドウのようなものです。訪問者を迎え、利用できるリソースを提示し、最適な次のステップに進むよう誘導します。ヘルプ センターは、潜在的な問題についてチームに警告するための最も重要な場所です。

特定のリクエスト タイプが設定されたヘルプ センターは、ユーザーが正確なレポートを作成できるよう誘導します。Jira Service Management では、チームのニーズに合わせてリクエスト タイプを設定できます。エージェントは、ユーザーが必要な情報に簡単にアクセスできるようにバグ報告のリクエスト タイプを設定して編成できます。またエージェントは徹底的かつ正確なレポート作成を可能にする動的なフォームを作成できるので、バグを迅速に修正するために必要なすべての情報を収集することができます。これらのカスタマイズにより、適切なフォームを見つけるためのやり取りや時間を最小限に抑えることで、バグ報告プロセスが合理化されます。

バグ報告

2. 複数の報告チャネルを利用できるようにする

バグ追跡の最初の一歩を踏み出すのは、最初に問題を報告するユーザーです。サービスを実際に利用している顧客は、新たなバグの最初の報告者となる可能性を秘めています。つまり、バグ報告システムがポジティブな体験であり、簡単で使いやすいものであることがいっそう重要になります。複数の報告手段を提供することで、顧客は潜在的なバグを簡単かつ柔軟に警告でき、チームはインシデントを回避する機会を獲得できます。Jira Service Management は、ヘルプ センターに加えて、メール、チャット、埋め込み可能なウィジェットなど、複数のレポート チャネルから報告を受けることができます。

ウィジェット
ウィジェット

3. できる限り自動化する

タスクの自動化は、チームの時間を節約して生産性を高め、可能な限り最高のサービスを提供できるようにすることを目的としています。どのタスクをどれだけ深く自動化するかを決め、事前に自動化しておくと、ボトルネックの解消に役立ちます。

例えば、チームは類似のバグを参照するチケットをグループ化し、その後、報告されたバグを既存の開発作業にリンクできます。ここから、バグの問題をエスカレーションできます。その後、問題への対応が始まって現在解決中であることが、リンクされた各報告者に自動的に通知されます。このように、対応者側で追加の作業を行う必要なく、報告のステータスが常にユーザーに通知されます。

チームは Jira Service Management の自動化テンプレートを使用するか、必要に応じてルールを調整できます。自動的に Jira 課題を分散チームに割り当てたり、承認者を割り当てたり、関連するサポート課題 (同じバグを報告する複数のユーザーなど) をリンクしたりすることができます。自動化された通知とアラートをワークフローとテンプレートに設定することで、対応者はコミュニケーションの誤りを回避し、適切なチームと連携して迅速にバグを解決します。何百もの自動化ルール テンプレートが用意されており、チームの特定のニーズに合わせて調整および編集できます。

Jira Service Management の自動化テンプレート ライブラリを参照してください。

ウィジェット

4. 開発者と IT サポートが一致団結する

構築した者が運用する」というフレーズを聞いたことがあるかもしれません。この言葉は、開発者がソフトウェアの日常的な運用に関与し続け、ソフトウェアと顧客の間に立つサポート担当者と開発者の間の壁を打破する責任を負っていることに言及しています。これにより、開発者とユーザーの直接的なつながりが強化され、より強力なフィードバック ループが形成され、ひいては顧客体験を向上させることができます。

バグを効果的に追跡して修正するためには、いかなる対応計画においても準備が最重要要素であると認識することが不可欠です。これは、開発チームと IT サポート チームが団結して、バグ レポートを共同で監視して対応することを意味します。これらのチームが 1 つになることで、全員がソフトウェアの円滑な動作に責任を負うことになります。

しかし、明らかな利点 (IT サポート チームへのプレッシャーの軽減、本番環境に対応した設計、迅速な応答時間、徹底的にテストされたコードなど) があるにもかかわらず、一部のチームはまだ十分に団結できていません。強力なバグ修正プラクティスには、団結したチームが文化とツールを通じて連携し合えることが必要です。

バグが出現したとき (そして、バグは必ず出現します)、サービス チームは Jira Service Management 課題を Jira Software 開発バックログにシームレスにリンクできます。開発者が介入し、コメントを見てフィードバックを提供できます。全員が同じコンテキストにアクセスできるので、バグ報告者、エージェント、開発者の間でシームレスなエクスペリエンスを維持できます。

強力なバグ追跡のプラクティスとツールがあれば、ダウンタイムを回避し、顧客満足度を高め、インシデントを減らすのに役立ちます。バグ報告を奨励し、可能な限りプロセスを自動化し、開発チームと IT チーム間のより強力なコラボレーションを可能にすることで、バグを撲滅しましょう。一致団結して対応すれば、バグに勝ち目はありません!

Jira Service Management のバグ追跡機能のメリットをご確認ください。

次の記事
事後分析