インフラSEのぼちぼち備忘録

非登録セキスぺの情シスがMicrosoft関連技術(Azure、Windows、Exchange、SystemCenter、SQL、Powershell)を中心とした備忘録を残していきます。圧倒的にインフラよりです。たまにネットワークのことも書きます。※本アカウントの発信内容、その他は所属する組織の見解ではありません。

”サポートを使いこなす技術”を身につけるために

あけましておめでとうございます。今年もよろしくお願いいたします。

2019年末に 2つの記事を書きました。

1.(ITベンダー)サポート使いこなし宣言

tech-okzk.hatenablog.com

2.(ITベンダー)サポート使いこなし宣言の背後にある原則

tech-okzk.hatenablog.com


経緯

f:id:kurone810:20191231234324p:plain


クリスマスの日に宇田センセーのツイートに書いてみようかな?と思ったのが始まり。

TLにあつまる議論を確認

f:id:kurone810:20191231234627p:plain


どんな事を書いても、読む人は元々ひどい人じゃないので・・・というあきらめに近い意見。一理ある。

f:id:kurone810:20191231234946p:plain


当事者意識がない人、とか、本質じゃないことに固執する。

このあたりの感覚も共感するとともにサポートにおける”本質”とは何か? 認識のズレは議論すべき価値がありそうだなと思いました。

技術的なHow toについてはある程度既存のドキュメントが充実している

aws.amazon.com

技術的なサポートを円滑に進めるHow toについてはTLでよだれいぬさんが紹介しているAWSのサイトとか参考になるなと思いました。 若干AWS特有な表現や事情もありますが、 読み替え可能な一般的な注意点だとおもいます。

正直、これ読んどけば良いという感はある。

具体的なHow toではなく、ユーザー側の価値基準や心構えを書きたい

ぼんやりと、以下のようなことを考えながら書きました。

  • 物事迅速に進めるための心構えとしてアジャイルソフトウェア開発宣言は参考になるし、開発者以外にもぜひ一度読んでもらいたい。
  • 参考にはなるが、読み替えた方がはまりやすい表現も多いので少し手を入れよう



興味がある人は以下も読んでみてください。

私は大手インフラ系ユーザー情シスとして、またはパートナー企業として様々なITベンダーと取引してきました。

割と早めにテクニカルリード的なポジションになったことから技術的な相談窓口となり、 大小さまざまな課題に対してITベンダーのサポートの力もお借りしつつ解決してきました。

結果として、私の不勉強、時には製品のバグ等原因は様々でしたが、 チームとして取り組む際に嫌なコミュニケーションをする人が多かった。

1.エンドユーザーからのクレームをサポートに伝え、どうしてくれるんだとプレッシャーをかける人
2.復旧に時間がかかっているのをサポートの回答が遅いからだと責任転嫁の言い訳をする人
3.既存の運用手順に無いログの取得などは出来ないとサポートへのログ提供依頼に非協力な人
4.とりあえず直せ!と怒鳴る人

もちろん私たちユーザー企業もIT製品、ITサービスを導入して提供しているサービスの担当者であり、そこにはエンドユーザーがおり、一刻も早く状況を改善しないといけないわけで、むしろエンドユーザーからは怒号が飛んだりするわけで・・・。

怒り、焦り、憤り、など感情が出てくることはあります。

が、そこはぐっとこらえ。 エンドユーザーに一刻も早く、サービスを再開するために まず冷静に優先して解決すべき課題は何かを整理したうえでサポートエンジニアに共有した方が結果として迅速に課題が解決される。

また優先度に応じた適切なサポートプランや体制を整え、 必要に応じてステークホルダーの協力を仰ぐのが依頼側の最良だと考えています。

これまでのサポート活用の経験からサポートを使いこなす上では 報・連・相の”相談”ができる関係を築くことが迅速な課題解決、 サポートを使いこなす技術の根幹だと考えています。

本来複雑な課題をシンプルに整理して、サポートに解決を依頼すべきです。 その場合は、課題の報告、状況の連絡だけで1ターン回答が得られる場合も多いです。

しかし、どうしても複雑な課題の解決の場合は、サポートエンジニアと”相談”し課題を整理することから高度な製品知識が必要な場合もあります。

そもそも複雑な事象の場合は課題の"本質"について共通認識を形成することすら容易ではありません。

サポートエンジニアに対して威圧的なコミュニケーションを行うと”相談”ができなくなり、結果として課題解決が遅れます。または、”本質”の認識のズレが後々大きな不満となります。

"相談"というのは非常に高度なコミュニケーションだと考えています。

課題解決まではサポートエンジニアも含めてOne Teamであることが大切であり、 不信をもってサポートに依頼するのは避けた方がよいです。 むしろ、率先してサポートエンジニアの心理的安全を確保するくらいがちょうどよい。

原因が製品バグで不利益を被っているかもしれません。 「そういう謝罪とか、今はどうでもいいから状況の改善に集中しましょう。」

ただ、間違ってほしくないのは過剰にITベンダーの肩を持つわけではないですし、 原因究明や責任追及が無駄だと言っているわけではないです。

心理的安全を確保したのにサポートの品質が良くないだとか、 そもそもお粗末な製品バグが多発するとか、バグではないかもしれないけど製品の理解が難しすぎるとか。

我々ユーザー企業はエンドユーザーにより良いサービスを低価格で提供する 手段としてIT製品やサポートサービスを利用しているのです。目的を見失わないようしましょう。

もし自分たちに適したサービス、製品じゃないと感じたら、 目の前の課題が落ち着いたのちに保証や賠償、製品やサービスの乗り換えを実施すればいいのです。

それはそれ、これはこれ。

私は去年の11月から渋谷のメガベンチャーの情シスとして働いています。

今後も様々なベンダー様にお世話になるかと思いますが、 その際はよろしくお願いいたします。