Redmineを使った技術サポートサービスの運用効率改善事例 #RedmineJapan

結城です。

2022年2月25日に開催されたREDMINE JAPAN vol.2において、「Redmineを使った技術サポートサービスの運用効率改善事例」と題した発表を行いました。当日の発表内容を改めてご紹介します。

背景

当社では「自由と稼ぐの両立」を理念として掲げています。ここでの「自由」は「自由なソフトウェア」のことで、ビジネス的に分かりやすく言えば「OSSビジネス」ということになります。

OSSでのお金の稼ぎ方には色々ありますが、当社では以下の2つが中心となっています。

受託開発：ご依頼に基づいて何らかのソフトウェアを開発し、事前の相談あるいは事後のご了承に基づいて、その成果をGPLなどのライセンスで公開する。
技術サポート：「公式には法人向けの有償サポートを提供していないOSS開発プロジェクト」と「運用上のトラブルに責任を持って対応してくれるサポート先を求めているユーザー企業」の間に立って、問題の原因調査や回避策の調査、パッチの作成などを有償で行う。

16年前の設立当初は前者のみでしたが、その後お客さまからのご相談に応える形で、後者の技術サポートビジネスも手がけるようになりました。そのような経緯のため、自社で運用しているRedmineには、一般的な使い方である開発の進捗管理のためのプロジェクトと、技術サポートサービスの運用のためのプロジェクトが相乗りしています。

当時からあったのかどうかは定かでないのですが、世の中には「サポート・ヘルプデスクでの運用に特化したRedmine」も存在しています。ただ、当社で自社運用しているRedmineは、元々が開発の進捗管理用で、継続してその用途でも使っているため、Redmineそのものを全面的にサポート用にカスタマイズすると、開発業務に支障を生じる恐れがあります。

また、カスタマイズを激しく行えば行うほど、「カスタマイズに使用したプラグインが新しいバージョンのRedmineに対応していない」といった事態に遭遇する可能性が高まり、ベンダーロックインならぬバージョンロックインに陥ってしまうリスクもあります。

そのような事情から、当社ではRedmineをあまりカスタマイズせずに、初期設定に極めて近い状態で運用しています。技術サポートについても、なるべくRedmineの基本機能の範囲で、運用を工夫して業務を行うようにしています。

技術サポートの運用

当社の技術サポートサービスがどのような内容かは、過去の記事で詳しくご紹介していますが、これを具体的にどのようにRedmine上で運用しているかというと、以下の要領となっています。

顧客ごとに1つのプロジェクトを作成する。
問い合わせはメールで受け付けて、1件の問い合わせに対して1つのチケットを作成する。
問い合わせに対する調査の経過はチケットにノート注記の形で追記して記録していく。
問い合わせに対応が必要かどうかは、チケットのステータス欄で把握する。
- メールで回答したら、チケットのステータスを「解決」に切り替えて、回答の文面を転記しておく。
- 顧客から、回答の内容に対して追加の質問や情報の提供が寄せられた場合、それらは既存チケットにノート注記として記録し、チケットのステータスを「フィードバック」に切り替える。

また、Redmineではチケットに対して「作業時間」の記録を付けられるため、これを使って実際の作業時間も記録しています。

作業時間の記録にはいくつかの目的がありますが、最大の目的は、作業実績の報告のためです。受託開発でも技術サポートサービスでも、「契約期間中で工数にして50時間まで対応する」のような形での契約では、「現時点で契約工数の何割ほど消化しているのか？」を不定期あるいは定期的に顧客に報告することがあります。

課題とその解決

当初は顧客数も問い合わせの種類も限られていたため、特に問題は無かったのですが、技術サポート事業が軌道に乗って顧客数が増えてくると、少しずつ支障が生じてくるようになりました。今回の発表では、代表的な4つの課題について、どのように困ったのかと、どのように解決を図ったのかをご紹介しました。

チケットの運用ミスの問題

前述のようなメールとRedmineのチケットの対応付けは、当初は完全に手動で行っていました。そのため、契約の増加に伴い、以下のようなヒューマンエラーが発生するようになってきました。

チケットの作成ミス。似た名前の別の会社からの問い合わせと誤認し、誤って別のプロジェクトに起票してしまう。
チケットの更新ミス。似たタイトルの別の問い合わせのやり取りと誤認し、誤って別のチケットにノート注記を追加したり、ステータスを切り替えたりしてしまう。
メールのチケットへの反映忘れ。複数の問い合わせメールを近いタイミングで受領した際に、一部の問い合わせへの対応に追われた結果、他の問い合わせが起票されなかったり、チケットのステータスを「解決（対応済み）」から変え忘れたりしたままになってしまうことがある。

この問題への対処の方策の1つ目は、問い合わせのチケットへの反映を自動化するというものです。

当社の場合、契約時に「この契約に基づいて問い合わせる際は、このメールアドレス宛にメールを送って下さい」ということを顧客に伝えるのですが、その際の問い合わせ専用メールアドレスを各顧客専用に発行しておき、自社開発の「Redmine plugin email importer」というRedmineプラグインによって、宛先メールアドレスに対応する顧客用のプロジェクトにチケットを自動起票するようにしました。このプラグインには、チケットとメールのスレッド情報を紐付けて保持する機能もあり、起票済みの問い合わせに関するメールのやり取りも、既存のチケットへのノート注記として自動的に追記するようになっています。

ただ、顧客によっては「その顧客専用の問い合わせ用メールアドレス」が発行されていない¹場合があったり、別のアドレス宛に問い合わせメールを送信されていたり²して、このRedmineプラグインだけでは対応しきれないケースがあります。そこでもう一つの対策として、ThunderbirdのメールからRedmineのチケットを作成・更新する操作を支援するアドオン「RedThunderMineBird Plus」を自社開発し³、組み合わせて使っています。 Thunderbird上のメールフォルダーにあらかじめ紐付けておいたRedmineのプロジェクトの情報や、スレッドに紐付けられたチケットの情報を参照して、自動的に各種の動作を切り替えるようになっているため、このアドオンによって、完全な手作業でのチケット更新運用と比べて、大幅に負担を減らす事ができています。

顧客側のメールクライアントの設定などによって、メールのスレッドが意図せず切れてしまうことなどはあり、これらの工夫でもまだ100％カバーはしきれていないのですが、人間が判断する箇所を減らしたことによって、ヒューマンエラーに起因するミスは激減しました。

回答内容が安定しない問題

技術サポートでは、「Firefoxのこの設定項目はどのように作用するのか？」といった、同じ内容のお問い合わせを、複数の顧客から時間を置いて頂く場合があります。公式な解説がない設定項目については、そのOSSのソースコードを参照して調査するのですが、過去の調査結果を参照できないと、毎回同じ事を時間をかけて調査し直す羽目になってしまいます。挙げ句、過去の問い合わせ時には詳細に調査して「そういうことができます」と回答したケースで、後からの問い合わせに対して不充分な調査しか実施できず「できません」と回答してしまう、といったことも起こり得ます。

また、サポート事業が10年以上の長期に渡って継続してくると、顧客側の担当者が異動で交代されるなどのことが度々発生します。そうした場合、顧客側で「クリアコードにずっとサポートを任せているので、詳しいことはクリアコードの方が把握している」と期待されて、ざっくりとした内容でお問い合わせを頂くこともあります。

このように、問い合わせに対して過去の回答を参照する必要がある場面は度々あるのですが、Redmineの既定の検索機能では、必要な情報が見つからなかったり、探している物と異なる情報が見つかりすぎてしまったりします。また、検索対象の件数が増加してくると、Redmine標準の検索機能では検索にかかる時間が増大しやすく、実用的でなくなってしまうという問題もあります。

これらの問題の解決策として当社でRedmineに組み込んで使用しているのが、自社開発の全文検索プラグインです。

この検索プラグインは、全文検索のバックエンドとして、当社が開発・サポートに関わっている全文検索エンジン「Groonga」を使用しており、Groongaの特長である「スコア順での結果の並べ替え」「ドリルダウン（ファセット検索）」「高速な検索⁴」といったメリットをRedmineの検索でも得られるようにするものです。また、さまざまな形式のファイルからテキストデータを抽出するための自社開発ライブラリ「ChupaText」によって、チケットに添付されたPDFやWord文書なども検索対象にすることができます。

これらの特長により、添付ファイルの形でのみ受領していた資料の内容も含めて、過去にRedmine上に記録された情報を効率良く検索できるようになったことで、技術サポートのサービス品質が向上し、顧客満足度も高まりました。

環境・契約の内容を間違える問題

メールからのチケット作成・更新間違いと似た問題で、チケットに基づいて調査や検証を開始した後で（下手をすれば、そういった作業を終えた後で）、当該顧客向けに適していない調査をしてしまっていたことに気が付き、工数を無駄にしてしまうという事態も度々起こっていました。

当社では、サポート契約開始の時点で明らかになっている「この顧客はFirefox ESR78をWindows 10 21H2で運用している」「この顧客はFirefox ESR91をWindows Server 2022で運用している」といった情報は、Redmineのプロジェクトの「概要」欄に記載するようにしています。しかし、チケットを閲覧して作業している状態からこの情報を参照するには、画面上部の「概要」リンクをクリックする（タブを切り替える）操作が必要です。環境を誤認しがちという問題は、この「1アクションが必要」ネックとなって、億劫で環境の確認をしそびれてしまい、環境を誤認したまま作業に入ってしまっていたために発生していました。

これを解決するために、redmine-plugin-descriptions-sidebarというプラグインを開発しました。これは、チケットの一覧や個別表示の画面のサイドバーに「概要」の内容を埋め込み表示するという、実装行数にして30行にも満たない、ごくごく単純なプラグインです。しかしその効果は大きく、「画面を切り替える」という一手間なしに「同じページの右側に視線を移動する」だけでよくなったために、「着手前に環境を確認する」ことのハードルが大きく下がり、確認忘れの発生頻度が大きく下がりました。

二手間かかっていた物が一手間に減れば改善で、一手間がゼロ手間に減ると革命、ということを以前どなたかがおっしゃっていましたが、その意味で、これは非常に分かりやすい「ゼロ手間化」だったと言えそうです。

なお、これとは別方向の解決策として、近年では、顧客ごとにあらかじめ用意しておいた設定に基づいて、Terraformを用いて使い捨ての検証環境をクラウド上に1コマンドで用意する仕組みを整備するようにもしています。

作業実績報告の負担の問題

作業実績報告書の作成は、元々は、当社で営業関係の業務を一手に引き受けている担当の者が手作業で作成していました。これもやはり、顧客数・契約数の増加に伴う作業量の増大が問題となっていました。

この問題については段階的な解決を図ってきており、第一段階では、Rubyスクリプトを使ってExcel形式の報告書を生成するようにしていました。このときのワークフローは以下の要領でした。

各顧客の契約情報を、手作業で、マシンリーダブルな形式のYAMLファイルに記述する。
Redmine上の各プロジェクトについて、「契約期間」に対応する「バージョン」を作成し、問い合わせから起票したチケットは必ず適切なバージョンに紐付ける⁵。
Rubyスクリプトは、リポジトリからGitでcloneして、シェルから手動操作で実行する。実行されたスクリプトは、YAMLファイルで与えられた契約情報に基づいて、RedmineのREST APIを呼んで、作業時間の情報を集計し、Excel形式のファイルを出力する。
報告書を顧客に連絡する必要が生じた際には、担当エンジニアがRubyスクリプトを実行し、生成された報告書のファイルをアップロードする。

ところが、最近になって新たに入られた非エンジニア職の方に、作業実績報告書の作成まわりの業務を一通り担当して頂く運用に切り替えようとして、前述のワークフローは非エンジニア職の方がやるには無理がある⁶という事実に直面しました。

そこで改めて、そのRubyスクリプトのロジックを流用し、Redmineの作業時間一覧からExcel形式のファイルを生成・ダウンロードできるようにするプラグイン「redmine-plugin-work-report-exporter」を作成しました。これにより、スクリプト実行のための環境を整備しなくてもよくなったほか、元のスクリプトにあった「月初のタイミング以外で実行すると期待通りの結果を得られない」といった制限も解消され、作業実績の報告に必要な手間を大幅に減らすことができました。

まとめ

以上、自社運用のRedmineを使って技術サポート業務を行う過程で遭遇した諸問題を、Redmineのカスタマイズと運用の工夫で乗り切ってきた事例についてご紹介しました。

今は高機能なカスタマイズ済みRedmineのSaaSや、Redmineベースでないカスタマーサポート用のクラウドサービスなどもありますが、当社のビジネス規模だとメリットがあまりないかったり、技術力を維持しておきたかったり⁷といった理由から、当社では現在もRedmineの自社運用を継続しています。

Redmineは進捗管理のために使われることが多いですが、標準的な機能の範囲内でも、運用の工夫で技術サポート業務にも使えます。また、「あともう少し、ここの挙動が違えば……」と感じる部分の挙動を、小規模なプラグインで変更することもできます。自社のワークフローにフィットする既存のシステムがなくお困りの方や、Redmineベースでのシステムの売り込みにあたって機能不足を補いたい方など、Redmineプラグインの開発パートナーをお探しの方がもしいらっしゃいましたら、お問い合わせフォームよりご連絡下さい。

「顧客ごとのアドレスを発行する」という運用になる前から契約している顧客の場合など。 ↩
担当者個人宛のメール、あるいはこのWebサイトの問い合わせフォームからの送信など。 ↩
元々は「Redmine拡張」という名前で他の方により開発されていたアドオンなのですが、その方による開発が途絶えてしまった様子であったため、現在は当社で独自にforkして開発を継続しています。 ↩
DBにPostgreSQLを使用した場合のパフォーマンス計測事例。また、当社での運用ではありませんが、200万件のチケットがあるMySQLのDBで約380ミリ秒で検索結果を得られたという事例もあります。 ↩
プログラムで作業実績報告書を生成する際に、それまで記録されていた情報からだけではうまく報告書を作成できなかったことから、この段階で、チケットの運用に一部変更を加えました。 ↩
スクリプトを実行するにはbundlerで依存ライブラリをインストールする必要があり、bundlerを使うにはRubyをインストールする必要があり、スクリプトをダウンロードするにはGitもインストールする必要があり、GitもRubyも使える状態にするにはBashが動作する環境を……と、乗り越えなくてはならないハードルが多数あります。 ↩
Redmineを自社で運用したりカスタマイズしたりといったことを行える程度の技術力が必要になるレイヤーでの受託開発を主戦場としているため。 ↩

ククログ

背景