🐈

自社のサービス品質を向上するためのひと工夫

2022/06/19に公開

マネジメント

1. はじめに

この記事は、自社のSaaSサービスを法人or 個人向けに提供している方向けの情報です。

【利用者像】:
- サービスプロダクトの品質改善が必要、と感じているマネージャー層・リーダー層の方々
- 運用・保守において、顧客からの問い合わせを頻繁に受けるサポート部門の方
- BizDevOpsでいうとOpsな方
【利用シーン】:
- 運用工程

2. 出来上がるもの

自社サービス品質を改善するための施策が見えるようになります。

以下は一例

改善テーマ	ステップ1 (標準化)	ステップ2 (管理強化)	ステップ3 (自立化)
問い合わせ件数の削減	✅一次問い合わせ窓口の設置 ✅ 業務フロー・管理シートの整備 ✅二次サポート要員の増強	✅FAQの情報提供 ✅問い合わせランキング	✅セルフ問い合わせ手段の提供
問題の早期検出 (診断/是正のスピードアップ)	✅メッセージの見直し ✅トレース情報の強化 ✅探索的テストによるデグレ検出	✅リバースエンジニアリングの実施 ✅正常性確認手法の確立 ✅テスト自動化の推進	✅障害の自動検知/予知 ✅開発プロセへの組み込み
業務オペレーションの維持/改善	✅業務マニュアルづくり ✅業務ローティションの推進	✅管理対象/管理基準の見える化 ✅定型業務/非定型業務のマニュアル整備 ✅オペレーション計測手法の確立	✅指標にあわせた人員配置・自働化 ✅分析と改善サイクルの定着化
新しい価値の訴求/バリューチェーン	―	✅ユーザー会づくり ✅事例発表会	✅新しいニーズ発掘 ✅新ビジネス創出

3. 考え方

3.1. 何が問題なのかを洗い出す

まず、何が問題なのかを関係者を交えて議論します。とある例では、2名ないしは3名以上の当事者を入れ、いま何が起こっているか、以前と比べ何がどうなっているか、「ヒト・モノ・業務・働き方」の4つの視点で、どこに何の問題があるのか発生しそうなのかを議論をしました。

ヒト：お客様、コールセンター部門、サポート部門、開発部門、連携部門
モノ：サービスプロダクト、連携サービス、利用端末
業務：提供機能の質、問い合わせの質/件数、緊急リリース件数、不具合件数
働き方：残業時間、ローテーション

特に、問い合わせに関し、サービスプロダクトのメッセージがわかりにくいこと、リリースの不具合が1年前と比べて圧倒的に増えていること、が判明しました。このままこの状態が続くとお客様が離れていく可能性もあり、最優先して取り組むべきことである、と意見にあがりました。

その他、出てきた問題点は次の通りです。

問題		いま起きている事	将来起こりうる事
ヒト	お客様	・意味不明なメッセージが出て、操作できない・APクラッシュで業務継続不能・ある操作を行うと稀にストールする	・お客様のビジネス遂行不可・サービス解約・他社サービスへの切り替え
	開発	・操作ログがなく切り分け不能・レスポンス問題・Sorryメッセージ多発	・取引誤り・サービス提供不能
モノ	自社	・APのデグレード	・信用低下
	連携先	・データ未送信	・業務連携の取引停止
業務	問い合わせ	・10倍に増加	・お客様ビジネスへの影響
	不具合件数	・5倍に増加	・お客様ビジネスへの影響
働き方	残業時間	・日々増加	・要員の離職・お客様ビジネスへの影響

議論の結果、サポート業務部門が課題を解決することで、お客様の困り事や開発部門の困り事を解決する、といった方向づけを行いました。

■取り組むべき課題:

(1) 問い合わせ件数の削減
(2) 問題の早期検出
(3) サポート業務の維持・改善

3.2. 課題と施策のマッピング

3、4つに課題を絞りこんだら、次に何をやることが解決になるのか具体的なイメージを考えながら、施策を立案していきます。いま出来ていることとできていないことの情報があるといいですが、現状なかなか普段できてないことを情報を引き出すことが難しいと思います。これがあるとお客様からの問い合わせが減りますね。と効果を意識しながら、あるべき姿をイメージし、机上で答え合わせをしていくのがよいと思います。このとき、網羅性チェック・漏れ防止のため、課題と施策を紐づけて確認をしていきましょう。

■取り組むべき施策:

(1) 問い合わせ件数の削減⇒「(1) 問い合わせ回答の自働化」
- 複数原因・対処がある場合の切り分け方法の提示
- サポートポータルの立ち上げ
- FAQ の事前整備と情報発信
- 月間問い合わせランキングの提供
- 自動問い合わせ/Chatサービスの提供
(2) 問題の早期検出⇒「(2) プロダクト品質向上に向けたフィードバック」
- 探索的テストによるデグレ検出
- わかりにくいメッセージの排除
- 操作ログ・関数IN/OUTの情報のトレースログの強化
- トラブルシュートに必要なシーケンス図の整備
- SLAを満足できない性能問題の切り分けと解決
- 再現性が低い問題のテスト条件絞り込み
- リリース前アプリケーションのテスト自動化
(3) サポート業務の維持・改善⇒「(3) サービスレベルの維持」
- 定型業務・非定型業務の業務フロー/マニュアル整備
- 管理項目の標準化
- 計測とモニタリング
- なぜなぜ分析の定着化
(4) サービスの差異化⇒「(4) 案件リピートへの貢献」
- お客様の声の早期フィードバック
- 次の商談・新しいお客様の紹介の場として
- 他のお客様を交えたバリューチェーンづくり

3.3. 意思決定者を交え、今後の行動を決める

課題と施策の紐づけがある程度終わったら、遂行体制や具体的にこういうものを整備していくアウトプットなども例に加え、これをやったらどうなる、やらなかったらどうなる、と判断材料を揃えて、意思決定いただきます。どこどこがやっているから、とか監視サービスいれたら楽ですよ、という発想にならないようにした方がよいかと思います。また、いきなり、全部やるべきことをやるという約束は難しい（すぐにやれるんだったら、いままで誰かがやってるはずです。。）ので、3段階くらいのステップを用意、何がどこまでできるようになるかのイメージを整理していくのがよいかと思います。ある程度すすんだら Go か No-Goか判断いただくタイミングも用意するようにしておきましょう。まずは、プロジェクト計画書的なものを揃え、最初のステップを承認いただきましょう。

4. まとめ

この記事は、私の過去の知見・経験に基づくものです。必ずしもこの考え方通りに進むもの、というものでもはありません。いわゆる銀の弾丸や打出の小槌はなく、あらゆる場面で使えるベストプラクティスを用意することは、現実的には難しいことでしょう。一方、推進の際には、時間的余裕が作れるか、定着化に向けた地ならしなど、企業風土や文化を変えていくことも必要でしょう。あくまで現場の問題解決の一例として見ていただければ、幸いです。

5. 参考

本記事作成にあたっては、以下の文書を参考にしました。
METI | SaaS 向け SLA ガイドライン

ITCA | ITC実践活動支援ツール | RFP/SLA見本

また、以下の曲を聴きながら、作成しました。

1.ships in the night(be-bop deluxe)
2.anarchy in the u.k(sex pistols)
3.who are you(the who)
4.owner of lonely heart(yes)
5.another one bites the dust(queen)
6.separate way(journey)
7.hold the line(toto)
8.easy lover(philip bailey, phil collins)
9.i wanna be your lover (prince)
10.hotel california(eagles)

ここまで読んでいただいた方、ありがとうございます。
では、また!!