Redmineに関するメモ

• Redmine（レッドマイン）に関する学習記録
• 就業先での使用感をイメージする。
• それに対する対応策・改善提案内容を予想してリストアップする。

参考サイト

Redmineでの使用感を予想し、改善提案を予想してリストアップする。

• 目的としては、自身の仕事を自ら作っていく姿勢を見せること。
• 積極的に関わることで、CUREDOの精神を掲げ、エンジニアとしてのチームへの関わり方をアピールする。
• ただし、現場の空気感を読んで、押し引きのバランスを見極めたい。
• 突っ走りすぎるのは良くないだろう。

Redmineをこんな使い方してるんじゃない？リスト

• 開発のタスクをチケットに登録して管理。
• ガントチャートで進捗状況をチーム内で共有し、全体像を把握。
• ヘルプデスクの対応履歴をチケットに登録してDBへ保存。
• 過去の対応履歴のチケットを検索することで、応対の効率化を図る。（※ただし、お顔合わせの際は、ヘルプデスクにおけるマニュアルというものは無いとおっしゃっていた。ので、ちょっと怖いが、応対履歴から過去の内容を見返すことはできるといっていたので、おそらくヘルプデスク対応ログをRedmineのチケットで管理しているのではないかと思う。）

Redmineのオープンソースを活かした開発（カスタマイズ）について、提案できそう？リスト

• 放置チケットの修正業務・改善提案

  • 「粒度を小さく」という使い方の指針に反し、数週間に及ぶタスクがチケット登録されている場合は、より粒度の小さいタスクに細分化したチケットに作り直すべきだという提案（これは嫌われそうだなwww）
  • ヘルプデスクにおける対応履歴をチケットで管理している場合、「題名（タイトル）から内容が想像しやすい名前をつけるべきだ」という使い方の指針に反し、タイトルからは分かりづらいチケット題名で登録されているものをピックアップして、分かりやすいタイトルに修正します。という業務を提案する。（これは良さそうだな。業務はヘルプデスク専任の自分が中心になって行いますと言って、責任を持ってやり通せばいいだけだからね。）
  • 終了条件が明確ではないタスク（チケット）がないかチェックする業務。
  • フィルタの条件設定を確認。（期日を過ぎているチケット、７日以上更新がないチケット、などを確認）
  • 一度作ったフィルターの条件をカスタムクエリにして保存する業務。（作成したカスタムクエリはサイドバーから一発で呼び出せるので業務効率化に便利である。）
  • チケットの更新でコメントを残す。解決までのログを残す。（自分でも分かりやすいし、企業としての資産として残るのでおすすめ。）
  • チケットの更新では、担当者を更新することも可能だが、ここで間違いが起きやすい（ここでは仕事を任された人という考え方があるが、Redmineでの担当者とは、現時点でボールを持っている人という認識である。）
  • 自分が担当のチケットでフィルタをかけた時、通知メールが担当者古い・新しい人に届く仕様になっているので、ここに間違いや失念が発生しやすいだろうと思われる。ので、ここを定期的に見返す業務が必要だと思います。
  • 全体的に見て、チケットの書き方、フォーマットに個々のズレが生じやすいと予想される。なので、そこについて、情報を共有して、煩雑なチケットが生まれないように工夫する必要がありあそう。
  • つまり、チケット書き方のフォーマットに明確なルールが無い場合は、それを考えて提案するという業務が出来そうな気がする。

• Redmineを業務に合わせたカスタマイズを提案できないか？

  • チケットのカスタムフィールドに適切な入力項目を追加検討する。
    • タイトル・問合せ内容・バグの内容・原因・対処
  • ステータスの内容をカスタマイズできる＝＞改善案を提案する。
    • 新規・未着手・承認待ち・公開待ち・公開済み・終了・却下
    • ToDo・Doing・Done（簡略化ステータスの例）
  • チケットの種類を分類するトラッカーは単なる分類ではないので、ここを精査・改善する。
    • チケットで使用するカスタムフィールドやステータスを制御するための重要な分類項目である。むやみやたらにトラッカーの選択肢を増やすのは禁物。
    • そのため、現状のトラッカー分類を精査し、不明点があれば質問。
  • トラッカーの部分で修正や代替案が見つかれば提案する。
    • 例えば、カスタムフィールドの入力項目が全て同じなのに、トラッカーには「バグ」と「タスク」の二つがある。という状況は、トラッカーの意味合いを履き違えている可能性がある。
  • トラッカーでできる「読み取り専用」「入力必須」の設定がされていない場合に提案する。
    - これが設定されていない場合は、読み取り専用というトラッカー設定を追加することを提案できそうだ。
  • ステータスのカスタマイズを検討・提案する。
    • SV（スーパーバイザー）の方だけが、チケットを完了ステータスにすることができるようにする。
    • つまり、ヘルプデスクのroleメンバーは、admin管理者の許可を得ないと、チケットを完了させることができないようにする。というステータスのカスタマイズが可能である。
    • これを行うことで、誤った対応を放置することなく、事故を未然に防いだり、軌道修正できるようになるはず。
    • （※まぁ、すでに行われているかもしれないけれど、これは一つ、提案出来そうな気がする。）

Redmineって何？に対するざっくりまとめ

• 汎用性の高いプロジェクト管理ツールである。
• 汎用性が高く自由自在なカスタマイズが可能。
• その反面、設定をうまくやらないと扱いづらく感じるという意見も。
• 汎用性を活かし、Redemineを使いこなすためには、各種設定の概念の理解が必要である。

提案できるかも？リストのまとめ

• チケットを社内全体に公開する。（読み取り専用トラッカーを設定）
  • バグや不具合に対する対応方法について社員全員が閲覧できるようにする。
  • ヘルプデスクへの問合せ前に、よくある質問といった例を見れば、ある程度、誰でも解決しやすいようになるはずだ。
  • つまりFAQという意味でのチケットの全体公開をするということだ。
  • 社内イントラへ周知、メールを社員全員に送信して周知。

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Redmine4.2で作るヘルプデスク向け問い合わせ受付・管理システム

• 参考サイトはこちら。
• Redmine4.2で作るヘルプデスク向け問い合わせ受付・管理システム
• この動画ではRedmineを使ったヘルプデスク管理システムを構築する事について解説する動画である。
• Excelで管理したいところだが、ここをRedmineで構築する。
• お客様とのコミュニケーションも、Redmine上で行えるといった優れものアイテムである。

Redmine主な用途例

• バグ・インシデントの登録・追跡
• タスク管理
• プロジェクト管理
• 問い合わせ・FAQ管理
• 管理表を作りたくなるような業務の多くに使える高い汎用性が魅力である。

これらについて詳しく解説していく。

Redmineは問い合わせ管理と相性が良い。

• 元々、Redmineはバグトラッキングツールとして開発されたシステムである。
• バグの管理は、ヘルプデスクなどの問い合わせ管理にそのまま適用しやすいという共通点がある。

RedmineによるWebサポート窓口

• Redmineの開発・販売企業であるファーエンドテクノロジー株式会社は、「Webサポート業務」をRedmineで構築している。
• 貴社のSaaS系サービス（クラウドサービス）「My Redmine」で受け付けるWebサポート窓口サービスでは、顧客との問い合わせのやりとりをチケットで行っている❗️
• 顧客はRedmineにログインして、チケットを作成する。
• サポート担当者は、チケットのコメントで、対応を行う。
• 2014年4月に運用が開始されている。

顧客目線の問い合わせ画面

• 基本的には、チケットの新規作成画面である。
• 画面のデザインをシンプルにしたり、
• 画面丈夫に、このツールの使い方ガイダンスを記載したり、
• 顧客にとって扱いやすい画面に、少しカスタマイズを加えている。
• 問い合わせを投げると、顧客の管理画面に、発行したチケットが出現。
• 対応中、などのステータス管理や、対応日時などを確認できる。

サポート担当者側のチケット管理画面

• 一方、サポート担当側は、すべてのお客様の発行したチケットが一覧で確認できる。
• 見た感じ、普通のメールの一覧画面みたいな感じ。
• だけど、ここに、対応中やアサインされている担当者の名前、などのステータスを一覧で直感的に視覚できるのが魅力。
• 対応が完了すれば、ステータスは、完了となるので、わかりやすい。たぶん、対応中のみを一覧に表示したり、といったフィルターも付いているんじゃないかなぁ？それなら、1日の最後に、対応完了したチケットを眺めたりして、達成感が味わえて、良いよね。
• いちいち、Excelを開いたり、共有ファイルのExcelで、誰がいま開いてて、編集できないよ、みたいなコンフリクトも起こらないよね❗️これ、めちゃ良いじゃん❗️

Redmineをヘルプデスクで使うメリット

• 対応すべきタスクが分かりやすい
• メールだと、埋もれてしまって分かりづらい
• 前述した通り、ステータスを持ったチケットで管理するため、未対応・対応済みのタスクが一目瞭然なのだ！
• やり取りの流れを追いやすい！
• メールだと引用返信機能があるが、正直、見づらいよね。
• しかも、相手が引用返信を使わないで送信してきたり、CCに他の人を指定せずに送って来たりすると、たちまち分からなくなる💦
• 別担当者への引き継ぎもスムーズに行える！
• 過去の対応履歴の参照が容易である！
• 様々な情報を関連付けられる！

実際の運用と設定

• まずは設計方針から考える

設計方針

• ユーザーはアカウント作成することで、問い合わせができるようになる。（システム管理者によるメンバー登録といった介在ポイントを無くし、すぐに問い合わせができるようにする）
• 問い合わせ画面は極力シンプルにすること
• ユーザーからは、他のユーザーのアカウントやチケットが見えないようにすること！（過去対応の参照や情報共有する時に、他ユーザー名などが別顧客に閲覧されるといったリスクは無いのか？）

登場人物

• クライアント⇔フロントスタッフ⇔バックオフィス
• お客様 ヘルプデスク 契約関係の事務員
• こんな感じ。

プロジェクトへのアクセス

• farend-supportという大きなプロジェクトが存在する。（これ1つだけ）
• そこに、お客様が参加する。（厳密には違う）
• 正しくは、プロジェクトのロール role（非メンバー）としてアクセスして、チケットを作る、という感じ。
• ヘルプデスクやバックオフィスはそのプロジェクト内の顧客のチケットに対応する。
• こんな感じ。
• 顧客は、プロジェクトに非メンバーという立場でアクセスをするため、顧客同士が互いのチケットやユーザー情報を閲覧することはできないので、機密情報の漏洩といった心配は無い。
• 全ての顧客情報が見えるのは、プロジェクトにadmin？的なステータスで参加している、ヘルプデスク・バックオフィスのメンバーである。

チケット更新時のメール通知

• これは、為される！
• 顧客、担当者、ヘルプデスク全体に、メール通知が来るように設定できる。
• 作成したチケットに対し、ヘルプデスクから担当者が名乗りをあげて、着手という状態になると、顧客へ通知が行くようにできる。
• 顧客からは、「あ、ちゃんと対応してくれてるんだな」と安心してもらえて便利。
• LINEの既読みたいな感じかな。

チケットのクローズ

• ヘルプデスクからの回答後、顧客から2営業日、返信がなければ、クローズ。
• ヘルプデスクは、クローズ可能なチケットがあるか、1日1回確認する。
• 顧客からクローズしてくれるパターンもある。

チケットのライフサイクル

その他の工夫

• ガイダンス表示（プラグインview customize）で、管理画面の操作方法を導く。
• チケットテンプレート（顧客への回答にテンプレートを用意）
• ステータスアイコンに絵文字を付けてる
• チケットから顧客管理システムへのリンク機能（チケットに顧客番号というカスタムフィールドを設定しており、クリックすると、顧客管理台帳画面に飛ぶ）
• なお、顧客情報の画面へのリンクは、カスタムリンクが生成できる。（カスタムフィールド >> チケット >> 顧客番号 、の画面で設定可能）
• 顧客番号がカスタムリンクに反映される。

課題

• サポートから顧客宛てのチケットが作成できない💦→なぜなら顧客はプロジェクトの非メンバーであるため。
• 同じ会社の顧客同士でチケットを共有することができない💦→緩和策として、顧客のメールアドレスに顧客メンバー全員のアドレスを登録してチケットを作成するという事。
• ↑↑これにより、メールからチケットの内容について通知を受け取る事は可能となる。（ただし、複数の人が1つのチケットにアクセスできるわけではないので注意）

✅動画視聴完了！

投稿に使うタグのメモ

• <img src="" width=50%>

参考サイト

Redmine4.2で作るヘルプデスク向け問い合わせ受付・管理システム