「ファーエンドテクノロジーのメール対応の仕組みの変遷」のRedmineの記事が参考になる

「ファーエンドテクノロジーのメール対応の仕組みの変遷」の記事が参考になるのでメモ。

【元ネタ】
ファーエンドテクノロジーのメール対応の仕組みの変遷 - ファーエンドテクノロジー株式会社

【1】ヘルプデスク管理は、顧客対応に直結するので上手く業務で回したいもの。
@g_maedaさんの記事では、代表メールアドレスとRedmineの連携→Redmineチケットでの受付へ変遷しているのが興味深い。

【2】以前は、顧客からの問合せメールをチケットに自動登録される運用をされていた。
Redmineにある「メールからのチケット自動登録」機能をうまく活用されていて、なるほど～と感心したし、色々考えていた。
僕も実際に運用してみて、結構使えると手応えはあった。

メールからRedmineのチケットを自動登録する時の注意点: プログラマの思索

RedmineはCRMソフトとして使えるか？: プログラマの思索

「メールからのチケット自動登録」機能は、ヘルプデスク管理だけでなく、インシデント管理のように、Zabbixのようなサーバー監視ツールが障害を検知したらメールを自動送信する時に、Redmineチケットも一緒に発行してしまう運用にも適用できる。

【2-1】しかし、下記の問題があるらしい。

(引用開始)
ただ、この仕組みも運用しているうちに問題点がわかってきました。

最も大きな問題点はメールのサブジェクトに依存した運用であることです。お客様がメールを送る際に、新たな用件のメールを以前やりとりしたメールの返信としてメールを作成されたために古いチケットに追記されたり、担当者が返信を行う際に誤ったチケット番号を記述して無関係のチケットに注記が追加されたりなどの問題が毎日のように発生していました。

メール返信時にチケット番号を入れ忘れないように注意したり、メールとRedmineの二つを見ながらサポートを行うというのも少し面倒でした。
(引用終了)

確かに、メールという機能の制約のために、チケットの内容の品質は正直良くない。
例えば、「いつもお世話になります」というタイトルのチケットが作られたりする。
RxTStudy勉強会で@g_maedaさんが話されていたように、90年代の頃はメールは短く的確に、と言われていたのに、今は手紙みたいに形式的な挨拶や駄文が多い。

また、顧客によっては、既に完了したメールのスレッドに、新しい問合せを混入させたりする。
すると、完了チケットに問合せメールの内容が埋もれてしまう。

つまり、メールというツールはもはや時代遅れなのだろう。
また、そんな古いツールでしかないメールにRedmineを従属させる運用は、本来のチケット駆動の運用ではないのだ。

【3】そこで、「Redmineチケットでの受付」では、Redmineのロールによる制御を上手く使うことで解決を試みている。

顧客がチケットに直接入力してやり取りする運用に変える。
顧客はプロジェクトのメンバーに所属させず、非メンバーに所属させる。
さらに、非メンバーのロール「チケットの参照」には、「作成者または担当者だけ」の設定を入れることで、他の顧客のチケットを参照できないようにしている。

つまり、Redmineの権限制御を入れたチケット管理で運用することで、チケットをやり取りする方が楽なわけだ。

この点はすごく参考になる。

【4】この記事を読んでさらに思うことは、Redmineのセキュリティ管理や権限管理はどんな場面でどのように設定すべきか、という問題だ。

ヘルプデスク管理では、「他の顧客の情報が漏洩されてはいけない」という大きな制約事項がある。
受託開発案件やオフショア開発でも、別プロジェクトのチケットは更新させないし閲覧させない制約事項が必要な場合もある。
そんな場合は、Redmineをどのように設定すればいいのか？

Redmineの権限管理の機能は、昔は正直貧弱だったが、バージョンアップされるにつれてすごく高機能になっている。
むしろ、複雑になりすぎているように思える時もある。
その辺りも一度整理してみたい。