はじめに
今回は、SIer出身エンジニアが自社サービスのカスタマーサポートと開発の企画・管理を任されてから整備したことをまとめておきます。
小さなサービスではありますが、「ITIL」の考え方を簡易版にして取り入れたことで、対応がスムーズになったので、同じ様な状況のサービスを始める際に参考になれば嬉しいです。
＊ サービス概要
ここでは、すでにリリース済みのeラーニング、LMS（Learning Management System）での問い合わせ〜対応完了までの事例を紹介します。
サービスがリリースされたのは2013年で、専任の開発者は2014年あたりから不在・・・。悪く言ってしまえば、数年間放置されていたという状況です。カスタマーサポートは社内のエンジニアが兼任でみていました。
＊ サービス規模
ユーザーはアカウント数で数千人規模。アクティブユーザーはもっと少ないですが、問い合わせは月に10〜20件程度です。問い合わせの内訳は既存ユーザーからの操作方法に関する質問と、新規ユーザーのサービス内容に関する質問が半々くらい。
＊ 開発体制
2017年度は、月に1度、BugFixや追加機能のリリースができる開発体制をミャンマーのオフショア拠点で構築しています。
開発人数は流動的ですが、日本人のブリッジSE1〜2名、オフショア側に現地リーダー1名、PG4名くらいです。
ITILの考え方を導入
今期、自社サービスを担当することになって初めて「ITIL」の考え方を知りました。（無知すぎる・・・）
知見のある弊社取締役にワークショップを開いてもらい、実際に自分たちのサービスに当てはめて考えてみることに。
＊ ITILとは
ITILは「アイティル」とか「アイティーアイエル」とかって読みます。この考え方が広まり始めたのは、私が生まれた平成元年頃だそうです。（関係ない）
以下、Wikipediaから引用。
Information Technology Infrastructure Library（ITIL）とは、ITサービスマネジメントにおけるベストプラクティス（成功事例）をまとめた書籍群。
要するに、サービスを管理する上でこうするとスムーズだよ、っていう体系的な事例や手法のことです。
＊ どう取り入れていくか
大規模なシステムであれば各部署に専任がいるべきですが、今回対応させるeラーニングサービスでは、問い合わせ対応から開発指示までを自分が横断的に対応しているので、全部当てはめていると逆に工数がかさんでしまいます。
なので、まずはカスタマーサポートの目線でKPIを定め、そこにかかる工数を最小化することを目的としました。
カスタマーサポートのKPI
私の部署は他にも様々な仕事を兼任しているので、カスタマーサポートの工数を膨大にかけるわけにはいきません。
いかに効率化するかを考えて整備していきました。
＊ 問い合わせ対応工数
10h/月 以内とする。
※開発チームとの仕様調整やリリース作業の工数はここに含みません。
＊ 一次対応経過時間
営業日18時までの問い合わせ＝30分以内
営業日18時以降の問い合わせ＝翌営業日10時まで
※問い合わせへのお礼と、調査完了時期の予定をご連絡します。
＊ 対応完了経過時間
営業日15時までの問い合わせ＝当日中
営業日15時以降の問い合わせ＝翌営業日午前中まで
※質問に回答するか、調査して開発チームに要望を連携後、暫定処置（データパッチなど）が完了するまでの時間です。
小規模サービスでの運用事例
今期は、サービス管理体制（主に私がここを担当）と開発管理体制をそれぞれ構築し、課題の運用ルールを策定し直しました。
＊ 問い合わせ発生からリリースまで
問い合わせを受けたら、ITILのインシデント管理手法に則って『問い合わせ管理表』を更新します。
一次回答後、質問への回答では解決せず、改善開発が必要になると判断すれば、『課題管理表』に詳細をあわせて転記します。この時点では問い合わせ課題は「暫定対応中」ステータスとなります。
ブリッジSEと連携して開発完了時期を相談した後、開発チームでスケジュールを決め、進捗管理はリリースフェーズに分けて行なっています。
その他、エンジニアが見つけたバグなども、いったんサービス管理の責任者（私）に連携された後、『課題管理表』に直接起票されます。
＊ リリースから問い合わせ課題クローズまで
開発が完了したらサービス管理でいったん受け入れをして、仕様の認識齟齬がないことを確認してからリリースに踏み切っています。
リリース手順書を用意し、当日のリリースはサービス管理の責任者（私）と開発管理のブリッジSEが立ち会います。
リリースが完了した際には、ご要望をいただいたユーザーへの報告も忘れずに。報告し終えたら問い合わせ課題がクローズされます。
まとめ
導入したばかりの頃は、誰が何すんの？あれ？管理表更新した？あ、私がやるの？ みたいなことが多々発生したので、ここでまとめておきます。
＊ サービス管理下でやるべきこと
- サービス企画ブレスト、アイディアノート更新 ※ときどきやる
- ユーザーからの問い合わせ対応（質問回答、データパッチ等の暫定対応）
- 問い合わせ管理表に起票
- 必要に応じて課題管理表に転記し開発管理に連携
- 週次MTGでの開発状況確認
- 結合テスト後の受け入れ、仕様確認
- リリース管理表更新、リリース手順書準備、経営層への報告
- リリース作業立会い、最終動作確認
- リリース後、ユーザーに報告
- 課題管理表、問い合わせ管理表、アイディアノートの該当課題をクローズ
＊ 開発管理下でやるべきこと
- サービス管理からの要望の開発可否（難易度など）を判断
- 現状の開発状況を確認し、リリース予定日を調整
- 開発メンバーへの指示、プロジェクトの進捗管理
- 週次MTGでの開発状況連携
- 開発後の品質管理（テスト、コードレビュー）
- 結合テスト完了後にサービス管理へ確認依頼
- リリース作業立会い、最終動作確認
- リリース後、開発中の進捗管理表をクローズ
さいごに
こうしてサービスの管理体制を整備すると、ユーザーの声を迅速に機能に反映させることができる環境が整ってきました。
それによって問い合わせ工数を削減することで、次の施策を検討し、サービス改善に目を向ける余裕も生まれています。
自社サービスを開発したはいいけどリリースしっ放しで終しまい、では残念です。せっかく自社サービスがあるなら、すぐにでも管理体制にITILを導入してみてはいかがでしょうか。