ククログ

株式会社クリアコード > ククログ > メールのやりとりとRedmineチケットを紐付けてタスクの状況を半自動で管理する

メールのやりとりとRedmineチケットを紐付けてタスクの状況を半自動で管理する

結城です。

以前、当社でのRedmineを使った技術サポートサービスの運用効率改善事例において、当社のサポートサービスでのお客さまとのやり取りは原則としてメールベースで行っていることと、トラッキングのためのRedmineチケットを使用していること、その両者を関連付けるThundebrirdアドオン「RedThunderMineBird Plus」を使用して問い合わせの取りこぼしやミスを減らすようにしていること、などをご紹介しました。

この中で、受信メールからのチケット起票・更新を自動化する物としてRedmine plugin email importer(以下、「Email importer」と表記します)をご紹介しましたが、運用の仕方の見直しによって、チケット運用の負担がさらに下がりました。 本記事では、Email importerの概要と使い方を改めて紹介します。

Email importerの概要

Email importerは、Redmineのチケット起票・更新機能を拡張し、より簡単に使えるようにするプラグインです。

実は、Redmineには元々、メールからチケットを起票・更新するための仕組みが備わっています。 ただ、設定の仕方が煩雑だったり、起票先のプロジェクトを動的には変更できなかったりと、使い勝手はあまり良くないのが実情です。 Email importerは、この仕組みを拡張して、以下のことを実現します。

  • YAML形式の設定ファイルに設定をまとめておけるようにする。
  • メール本文の余計な部分を削除する。
  • メールのスレッド情報に基づいて、既存チケットへのコメント追加を自動的に行う。
  • GitHubの通知メールに基づいて、GitHub上のIssueの変更内容をRedmineのチケットに同期する。

導入

導入手順はリポジトリの説明を参照して下さい。 基本的には一般的なプラグインの導入手順と変わりありませんが、お使いのRedmineへのファイルの設置に加えて、以下の事も追加で行う必要があります。

  • メール取り込みのための定時処理タスクの登録(インストール手順に記載あり)
  • チケットのカスタムフィールドMessage-Ids(長いテキスト型)の追加
  • 各プロジェクトでのMessage-Idsフィールドの有効化

プロジェクトでMessage-Idsが有効になっていないと、メールからのチケット起票・更新が期待通りに行われません。 くれぐれもご注意ください。

メールサーバーからのメールの取り込み

Email importerは、Redmineサーバーからメールサーバーにアクセスして、メールボックス内のメールを取り込み、その内容に応じてチケットの起票・更新処理を行います。

設定は、Redmineのconfig/email_importer.ymlに設置するYAMLファイルで行います。 メールサーバーからのメールの取り込みに必要な情報は、このファイルのimap配下に記述します。

default: &default
  imap:
    address: "mail.example.com"
    start_tls: true
    user_name: "redmine-import"
    password: |-
      Secret
    inbox: "INBOX"
    trash: "Trash"
  ...

Email importerはメールクライアントの一種としてIMAPでメールサーバーと通信し、メールボックスの内容をダウンロードします。 よって、Email importerを使う際は、Redmineからのメール取り込み専用のユーザー(メールボックス)を用意しておく必要があります1。 Email importerは、ここで「受信」したメールを元にして、Redmineのチケットを起票することになります。

受信したメールからのチケット起票・更新

Redmineにチケットを起票するには、チケット起票対象のプロジェクトを指定する必要があります。

そのための設定もconfig/email_importer.ymlで行います。 具体的には、issue配下にメールアドレスを列挙し、それぞれに1つのRedmineプロジェクト名(識別子)を記述します。

default: &default
  imap:
    ...
  issue:
    "project1@example.com":
      project: "project1"
    "project2@example.com":
      project: "project2"

Email importerは、受信したメールの宛先の中にここで列挙されたメールアドレスが含まれるかどうかを見て、含まれていれば、対応するプロジェクトに新規チケットを起票します2。 チケットのタイトルはメールのSubject、説明文にはメールの本文が使われます。 メールに添付ファイルがあった場合は、それらもRedmineにアップロードされ、チケットに添付されます。

この時、Email importerはメールのMessage-Idヘッダーの内容をチケットのMessage-Idsフィールドに自動登録します。 以後は、Referencesヘッダーの内容に基づいて「すでにメールからチケットを起票済みのメールに対する返信」を自動検出し、返信に対しては新規にチケットを起票する代わりに、既存のチケットへの追加コメントとしてメール本文を転記するようになります3

なお、ビジネスメールのやり取りでよく見られる運用として、返信のメールの末尾に返信元のメール本文を全引用するケースがありますが、Email importerがメールの本文をチケットに転記する際は、それらは自動的に削除するようになっています。 この削除処理はヒューリスティックな実装のため、削除されるべきでない本文の引用が削除されてしまったり、逆に、削除されるべき全引用が削除されずに残ってしまったりする可能性があります。 そのような事例に遭遇した際は、メール本文のサンプルを添えて「このメールで引用の削除に失敗した」という趣旨でissueを立てて頂ければ幸いです。

メールのやり取りをトリガーとしたステータスの自動変更

サポートの運用とチケットのステータス

さて、ここからが本記事の本題です。

ここまでの説明した基本的な動作によって、問い合わせメールを発端としたやりとりの経緯をRedmineチケットに自動的に転記することはできます。 しかし、Redmineで「問い合わせに回答するサポートサービス」を運用する場面では、チケットには、経緯の記録以外にもう一つ大事な役割があります。 それは、その問い合わせに回答済みか、未回答かのステータス管理です。

当社のRedmineによるサポート運用では、チケットのステータスを以下のように使っています。

  • 起票時点では「新規」
  • 作業に着手したら「進行中」
  • 回答のメールを送ったら「解決」
  • 先方から追加の問い合わせが届いたら「フィードバック」
  • 完全にクローズしたら「終了」

ステータスが「解決」か「終了」になっていれば、こちらで取るべきアクションがない状態で、そうでなければ何らかの対応が必要ということになります。

このステータス切り替えを手動で行う運用においては、ステータスの変更漏れが生じる場合がありました。 「回答済みなのに『解決』や『終了』にし忘れていた、という種類の変更忘れであればあまり害はないのですが、「追加の問い合わせがあったのに『解決』から『フィードバック』に切り替え忘れていた」という種類の変更漏れは大問題です。 このようなステータス変更漏れは、「3営業日以内の回答をお約束していたのに、そのようなステータス変更漏れのせいで、回答期限が過ぎた後に回答漏れがあったことに気がついた」といった事故が起こる原因となります。

Sieveによるチケットのステータス変更指示

この文脈におけるチケットのステータス変更の要件を整理すると、以下のように言えます。

  • メールの送信者が自社のドメイン(clear-code.com)のメールアドレスであれば、チケットのステータスを「解決」に変更する。
  • そうでなければ4、チケットのステータスを「フィードバック」に変更する。

この要件への対応は、Email importerの設定では行えませんが、メールサーバー上でメールフィルターとして動作する仕組みであるSieveを使って実現できます。

Sieveは、そのようなソフトウェアがあるわけではなく、サーバーサイドで動作するメールフィルターを定義するための言語仕様の名前です。 メールサーバー本体でSieveに対応していたり、Sieveに対応するプラグインが存在していたり、という形で使用できます。

当社ではこのSieveを使い、以下のような設定を行っています。

require "editheader";
require "envelope";

if anyof (header :is "delivered-to" "project1@example.com",
          header :is "delivered-to" "project2@example.com") {
  if envelope :domain :is "from" "clear-code.com" {
    addheader "X-Redmine-Status" "解決";
  } else {
    addheader "X-Redmine-Status" "フィードバック";
  }
}

if anyof (...)には、config/email_importer.ymlissueで設定したチケット起票・更新対象の宛先メールアドレスに対応する設定を列挙します。 ここでメールを絞り込んだ上で、if envelope :domain :is "from" "clear-code.com"で送信者が自社ドメインのメールアドレスかどうかを調べ、真であればRedmineのステータスを表すX-Redmine-Statusヘッダーに「解決」を、そうでなければ「フィードバック」を設定する、という要領です。

Email importer5は、X-Redmine-* のような名前のSMTPヘッダーが設定されていると、そのメールに基づいて更新したチケットの該当フィールドの値をSMTPヘッダーの値で更新する、という動作を行います。 これを応用し、サポートの要件に合うステータス変更を実現しているわけです。

なお、この方法だとメールサーバー側からはRedmineの情報を参照できないため、「お礼などのメールがスレッドの返信として顧客から届くと、特にこちらから何か応答する必要が無い場面でも、ステータスが『フィードバック』になってしまう」「こちらから一旦中間報告のメールを送ったが、まだやらなければいけないタスクが残っている、というチケットが『解決』になってしまう」といった事は起こってしまいます。 前者はそれほど大きな害はないため、対応の必要がないと判明した時点で手動でステータスを「解決」に戻すようにしています。 後者は、こちらも都度手動でステータスを「進行中」や「フィードバック」に設定し直すか、もしくは、こちらからの連絡は基本的にこちらで行うべき作業をすべて終えたタイミングでのみ行う運用とする、といった形で対応しています。

まとめ

以上、技術サポート業務におけるRedmineの運用を例として、メールとRedmineのチケットを連携するためのプラグイン「Redmine plugin email importer」の概要および基本的な使い方と、Sieveと組み合わせたチケットのステータス自動変更の設定例をご紹介しました。

Redmineはプラグインでの機能拡張によって、便利な機能を後から付け加える事ができます。 機能をゼロから実装する必要は必ずしも無く、Email importerがそうしているように、Redmineの標準機能を下敷きにして必要最低限の実装だけで機能を実現する、というやり方もあります。

自社のワークフローにフィットする既存のシステムがなくお困りの方や、Redmineベースでのシステムの売り込みにあたって機能不足を補いたい方など、Redmineプラグインの開発パートナーをお探しの方がもしいらっしゃいましたら、お問い合わせフォームよりご連絡下さい。

  1. 既存のユーザーのメールボックスにアクセスさせる使い方もできますが、セキュリティの観点からはお薦めできません。

  2. このような仕組みなので、複数の顧客で共通の「総合受付」的なメールアドレスで問い合わせを受け付けている場合には、メールアドレスとRedmineプロジェクトとを対応付けられないため、新規のメールからの自動起票は行えない、という制限事項があります。また、Redmine上で操作して追加した新たなプロジェクトをチケット起票・更新対象に加えるためには、config/email_importer.ymlの変更が必要となります。

  3. 手動で起票したチケットのMessage-Idsフィールドに、任意のメールのMessage-IdヘッダーやReferencesヘッダーの内容を転記した場合も、そのメールを含むスレッドへの返信が自動的にそのチケットに転記されるようになります。「総合受付」的なメールアドレスで問い合わせを受け付けている場合でも、この方法を使うことによって、労力の削減が可能です。

  4. サポートサービスの顧客企業の数が多い上に、各社で決まった担当者の方以外からも問い合わせや応答がある場合があるため、「このドメインからのメールは顧客からの物として扱う」という判断や設定を行うのは現実的に困難です。そのため、「自社のドメイン以外はすべて顧客からの物として扱う」というざっくりした判定とする形としました。

  5. 正確には、その実装が元にしているRedmine本体のMailHandlerの機能です。