0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

【システム運用】顧客から特別対応を求められた時の対応方針

Posted at

初めに

この記事は法人向けのSaas運用を想定して書いています。
オーダーメイドのシステムやtoC向けのアプリケーションは考慮していません。
ご了承ください。

この記事の目的

顧客から特別対応を求められた時の対応方についてノウハウを整理することで、システム運用におけるトラブルを回避すること。また、これにより顧客に高品質なサービスを提供すること。

特別対応とは

ここでは「不特定多数の顧客に提供しているサービスにおいて、特定の顧客に対して基本機能・オプションに含まれないサービスを提供すること」と定義します。

具体的には顧客が誤って削除したデータをバックアップファイルから復元する、特定のノードのみリリース日時を変更する等が挙げられます。

基本方針

原則として特別対応はお断りするのが良いです。
理由として以下のことがあります。

  • 想定していないオペレーションにより予期しないトラブルが起こる可能性がある。
    • データを復元する際に誤って関係のないデータを切り戻してしまう、デプロイ手順を書き換えて不具合が発生するなどのトラブルがよく起こります。
  • CSチームとの調整や事前検証等に時間がとられて本来やるべき業務に取り組むことができない。
    • 新機能開発・問い合わせ対応等にかけられる稼働が減り、総合的なサービスとしての品質が低下します。
  • 特別対応の前例を作るとそれ以降も他の顧客(あるいは、特別対応の前例を知った営業)から同様の対応を求められる。
    • 一度前例を作ると断ることが難しくなります。

ただし、注意点として単に「特別対応はやりません」と無下に断ると角が立ちます。
CSチームや営業チームとの関係が悪化して今後の業務に悪影響が出ることは避けたいです。

上記のような理由をきっちりと説明すれば大抵は大きな問題なく断ることができるでしょう。

この時、「開発が大変なのでやりたくない」だけではなく 「お客様に不利益が及ぶ危険があるのでやらない方が良い」 という方向で説明できれば納得いただける可能性が上がります。

例: 「事前に十分検証の上対応しますが予期せずデータが更新・削除される可能性があります。この場合、復旧に0.5人日程度かかりその間はシステムをご利用いただけません。」

どうしても対応を求められた場合

やりたくない理由やリスクを説明しても対応を求められることはままあります。
この時本番作業前にがやるべきことは以下の3点です。

  1. 上位者に報告して承認を得る
  2. 関係各所と調整して合意形成する
  3. 事前に検証する

1. 上位者に報告して承認を得る

特別対応のようにリスクのある作業を実施する時は必ず上位者に報告して承認を得ます。
その目的は 大きく2つあります。

1つは報告によって責任を上位者に委譲することです。事前に報告すれば仮に問題が発生した場合でも何とかしてもらえる可能性が上がります。逆に報告せずに事を進めて問題が発生した場合かなり怒られます。

2つ目の目的は対応方針をレビューしてもらい、問題点やリスクを解消することです。
そのためには単に「特別対応することになりました。どうすればよいですか?」と報告するのではなく、「特別対応します。 私はこのような方針で作業を進めようと考えています」とある程度たたき台を作っておくと良いでしょう。

報告する範囲は顧客影響の大きさによって変わります。DBのレコードを1つ更新する程度であればチームリーダーに報告すれば十分だと思います。リリース時期を変更する・システム要件を超えた利用を許可するといった内容であればPdMや管理職にも報告すべきでしょう。

また、必ずチャットやメモ書き程度でも良いので報告と承認の証跡を残します。

2. 関係各所と調整して合意形成する

開発チーム内で承認が下りたら次は関係各所と調整します。この作業は平のメンバーがやるよりもある程度肩書のあるメンバー(PdMやチームリーダー)がやる方がスムーズに進むことが多いです。 可能であれば報告の時点で依頼しておくのが良いでしょう。

ここでいう関係各所としては開発・顧客との窓口になる部署(主に営業やCS)・本番作業を担当する部署(開発部内の運用エンジニアやインフラチームのメンバー)を想定しています。

どの部署からもある程度上位者に参加してもらう必要があります。

ここでは対応方針と対応完了までの納期を調整します。 営業やCSからはなるべく早くしてほしいと言われることが多いですが、適当に理由をつけて断る方が無難です。

ここでも合意形成に至るまでの証跡を文面で残します。

3. 事前に検証する

対応方針が決まったら検証を実施します。
検証の目的は2つあります。

1つは当然作業内容に問題がないかを事前に確認することです。2つ目は問題が発生した際に原因がどこにあったのかを検証するための証拠を残すことです。(万一障害報告書の提出にまで発展した場合にも材料にすることができます。)

検証にあたってはなるべく本番と近い状態を再現します。(データ量・アクセス状況・MWのバージョン等)
本番に近い環境を急ごしらえするのは大変なので、普段から本番相当の環境を最低1つ用意しておくのが良い運用と言えそうです。

また、ここでも証跡を残します。ターミナルのログを使うのが手っ取り早いです。

本番作業

祈ります。

全体を通して

説明・報告・記録によって責任を回避することがシステム運用の肝と言えるかもしれません。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?