こんにちは。現場の最前線でコードと向き合い、泥臭い自動化を愛するエンジニアです。
「顧客からの問い合わせ対応」と「開発タスク」。この二つが分断されている組織は、往々にして疲弊します。メールをコピーしてチケット管理ツールに貼り付け、進捗をメールで返信する……そんな「コピペ地獄」から卒業しませんか？
GitLabには、Service Deskという隠れた強力な機能があります。これを使えば、顧客のメールがそのまま「イシュー（Issue）」に変換され、エンジニアは普段通りGitLab上で議論し、修正をコミットするだけで、顧客に返信を届けることができます。
今回は、この「開発フローとサポートの融合」を実現するための極限の実践ガイドをお届けします。
—
1. なぜ「Service Desk」なのか？その本質的な価値
多くのチームがJiraやZendeskを別に導入しますが、小〜中規模のチームであればGitLabに一本化すべきです。理由は明確です。
- コンテキストのスイッチがゼロになる: エンジニアが普段使っているGitLabから離れる必要がありません。
- トレーサビリティの確保: どの顧客の要望が、どのコミットで修正されたのか、イシューのリンクで一目瞭然になります。
- 自動化のフック: GitLabの強力なCI/CDパイプラインを「顧客対応」にまで拡張できます。
—
2. セットアップ：最短で「メールをイシュー化」する
Service Deskは、設定さえ終われば魔法のように動きます。
手順1：Service Deskの有効化
GitLabのプロジェクト設定画面へ向かいます。
1. `Settings` > `General` > `Service Desk` を展開します。
2. `Activate Service Desk` にチェックを入れます。
3. `Email address` のプレフィックスを決めます。
これで、`contact-project-123-issue@gitlab.example.com` のような専用アドレスが自動発行されます。ここにメールが届くと、即座にイシューが作成されます。
手順2：自動返信テンプレートのカスタマイズ（重要）
デフォルトの返信は機械的すぎます。ここを丁寧に書くだけで、顧客の満足度は劇的に変わります。
プロジェクトルートに `.gitlab/service_desk_mail_templates/thank_you.md` を作成してください。
ありがとうございます！
[Issue IID]番として担当者が確認しております。
- 状況確認: [Issue URL]
- 予想される回答期限: 3営業日以内
※ このまま返信いただくと、エンジニアに直接メッセージが届きます。
—
3. 「Hello World」：動作確認の極意
単にメールを送るだけでは不十分です。以下のステップで「現場レベルの動作確認」を行いましょう。
1. セルフテスト: 自分の個人のメールアドレスから、発行されたService Desk用アドレスへメールを送ります。
2. イシューの確認: GitLabの「Issues」ボードに、件名がメールタイトルのイシューが作成されていることを確認します。
3. エンジニア視点の回答: イシューにコメントを書きます。「`/close`」などのクイックアクションを使ってみてください。
4. 顧客体験の確認: 自分のメールボックスを確認し、GitLabからの返信が「スレッドとして」繋がっているか確認します。
ここで重要なTips:
GitLabのコメント欄に書いた内容は、「内部メモ」と「顧客への返信」を使い分けられます。
- エンジニア同士の会話はそのまま書き込む。
- 顧客に見せたい内容は、コメントの先頭に「`/reply`」を付ける。これにより、顧客にメールが自動送信されます。
—
4. 現場で「震えるほど楽になる」運用のコツ
ここからは、プロの知見です。導入した後に「運用が回らない」とならないための防御策です。
- ラベルの自動割り当て:
`Service Desk` から作成されたイシューには、自動的に `service-desk` ラベルを付与するルールをCI/CDや自動スクリプトで組みましょう。これにより、通常の開発タスクと混ざるのを防げます。
- Boardの分離:
「サポート専用ボード」を作り、`service-desk` ラベルがついたものだけを表示させてください。これで、サポートチーム（あるいは担当エンジニア）は、自分が対応すべき案件のみに集中できます。
- 公開用ポータルとしての活用:
GitLabの「Issue Tracker」を公開設定にすれば、顧客はイシューページから状況を確認できます。もし機密情報を含むなら、`Confidential Issue`（機密イシュー）機能を活用し、特定のユーザーのみが見られるように制御しましょう。
—
最後に：エンジニアが「顧客の声」に近い場所へ
多くの開発者が、顧客の顔が見えない環境でコードを書き、疲弊していきます。しかし、Service Deskを通じて直接「ありがとう」というメールがイシューに届く瞬間、エンジニアのモチベーションは別次元へ昇華されます。
この仕組みは単なるツール導入ではありません。「開発者と顧客の距離を最短にする」ためのアーキテクチャなのです。
さあ、まずは今日の午後、プロジェクトの設定を開くところから始めてみてください。あなたのチームのコミュニケーションが、劇的に洗練されることを約束します。
何か詰まったら、いつでも聞いてください。我々はエンジニアです。壁は越えるためにあります。