  |
はてなキーワード: カスタマーとは
カスタマーサポート（テクニカルサポート）ってそんな簡単な仕事じゃねーのよ。切り分けのために広範囲の知識が必要だし、客先環境特有の仕様や状況まで推察できないといけないことすらある。
当たり前の話だけど、
そもそも開発チームに敬意持ってない人が、開発チームに敬意持てと言ってもそりゃ無理、というものだろう。
※開発チームが敬意を持っているかどうかはここでは語られていないけど、まーどっちでも。
大事なことは、
開発者って、こういう悪意がいつも自分に向けて飛んでくる立場だということ。
それが、あくまで究極的には「代理人」の立ち位置であるカスタマーサポートとの決定的な違い。
開発者自身が自分で作りたい量のソフトを作りたいように作れる業務環境は、あることはあるけど特殊。
そして、そういう系統の開発は、たいてい研究などのノンプロフィットか小規模開発。こういうチームが、費用が発生するカスタマーサポートと組むことは無い。
つまり、この開発チームは、会社上層部の方針や、企画チームなどのリクエストに従って開発をしている。
厳しいQCDでソフトを作ることを強く要求される。これが開発者の現実。
ノーバグで作ることはほぼ不可能で、規模が大きくなるほど、コード改修量当たりのバグ発生確率は上がる。
そして、バグに起因する不具合やらシステム障害が出ると、いろんなところから詰められる。
バグは回避困難なので、開発者はある種負けが約束された仕事、ともいえる。
結局、「お前ら何バグ出しているんだ」「お前ら何納期に遅れてるんだ」という怒られは覚悟する必要がある。
技術的負債のたまったシステムの改修なんて、ほぼ負け確定の勝負だ。
それでも「いやだ」という選択肢はまずない。
でさ、リリース後に発生するシステム障害や不具合、これを責められるのも、なかなかつらい。
「お前(達)が無能だから」とか「お前(達)のせいだ」という悪意に満ちた言葉が、ちょっとだけオブラートに包まれて飛んでくることもあった。
事実自分に起因する話だから、責務上仕方ないんだけど。人のせいにできないし、逃げ場はない。
カスタマーサポートは「あいつらのせいで」と責任を移譲できるけど、開発者には責任の移譲先はない。
開発者でもなすり合いはあるんだけどさ、バグを出したやつが誰なのかは割と明らかなので逃げ場はない。
しかも厄介なことに、責任といっても、単なる評価的な責任だけじゃない。
簡単だったらいいんだけど、超難問だったり、再現条件が見つからないようなバグもあったりする。
そして、解けるかどうかすらわからない難問を目の前に、顧客とかサポートから詰められることもある。
「早く答えてください！」とか「◎◎日になったのですが、まだ回答が来てません。なぜですか、答えてください」とか。
ただでさえ目の前の問題が難問だというのに、目の前の問題に苦戦していることについての説明責任までついて回るんだから、かなりメンタルが削られる。
なんでこの人たち給料が高いんだろう。
給料高いのが気に入らないなら、そりゃ開発者になるのが一番です。
皮肉でもなんでもなく。
開発者になるまでの努力をして、開発者になって1年やれば、多分実態がわかる。
それが「大したことない」と思えるなら、それは開発者が適職という事。
万事解決じゃないですか。
自分にできないことを他人にやってもらったら普通感謝するだろ。たとえば食卓で向かいに座ってるやつが醤油を使ったせいで醤油が手の届かない位置にあったとしても、「醤油とって」って言って相手が渡してくれたら「ありがとう」って言うべきだろ。人間としてあたりまえ。
開発チームの目的は製品を作ること、カスタマーサポートの目的は顧客満足度に貢献すること。
UberのCSやってたけどJIRAで報告したらかならずありがとうって返信してくれたわ
どうもエンジニアとCSの間にもう一つ準エンジニア的な部署があってカスタマーサポートのカスタマーサポートもしてくれてた
うちの会社のシステム、ほぼ毎日いろんなバグが見つかってカスタマーサポートから修正依頼がきてる。
依頼が来る度に、slack上ではカスタマーサポートに「申し訳ありません直ぐに調査します」って送ってるけど、なんで自分たちが「申し訳ありません」と言っているのかよくわからない。
営業が質の悪いスケジュールを立てて上司が勝手にオッケー出して、
開発チームがひいひい言いながら直して、
なにかがおかしい。なんだこれ。
スケジュールが足りなくて起きた問題をスケジュール足りない中解消してなぜ謝らないといけない構図になっているんだろうか。ただのマッチポンプじゃないか。
不出来な営業や上司が作ったのスケジュールに振り回されたらまともなもんなんて作れないよ。
ホントはバグ修正や上からきた新機能開発のごり押し対応だけじゃなく、改善とかリファクタみたいなことも色々やっていきたいと思っているよ。
でもできないんだよ。
新機能実装にたいしてまともなスケジュールが出てくるとは思えないんだもん。
新機能の依頼くるじゃん？
まともなもんなんか間に合わないじゃん？
怒られるじゃん？
どうせこうなる確率が１００％なんだけど、それでも新機能のリリース日程は上層部に勝手に決められてるじゃん？
もう新機能とか開発しないで、ひたすらちょっとしたメンテナンスとリファクタだけさせてほしい。
余計なこと言わないでほしいというのが実装チームの総意です。
なんでこの人たち給料が高いんだろう。
じゃあ開発がカスタマーサポートした時に、カスタマーサポートは代わりに開発する気概があるの？
プログラミングって一生懸命作ってもバグが出てくるわけで、その原因を探すのも結構大変だし、なんなら作る経緯ではかなり仕様変更とかがあったりして振り回されて仕事してる側面もある。
開発があって初めてその支援たるカスタマーサポートがあるのだから文句言う前に産みの苦しみ、いくら気をつけてもバグが出る苦しみを知った方がいい。
じゃあ開発がカスタマーサポートした時に、カスタマーサポートは代わりに開発する気概があるの？
プログラミングって一生懸命作ってもバグが出てくるわけで、その原因を探すのも結構大変だし、なんなら作る経緯ではかなり仕様変更とかがあったりして振り回されて仕事してる側面もある。
開発があって初めてその支援たるカスタマーサポートがあるのだから文句言う前に産みの苦しみ、いくら気をつけてもバグが出る苦しみを知った方がいい。
じゃあ開発がカスタマーサポートした時に、カスタマーサポートは代わりに開発する気概があるの？
プログラミングって一生懸命作ってもバグが出てくるわけで、その原因を探すのも結構大変だし、なんなら作る経緯ではかなり仕様変更とかがあったりして振り回されて仕事してる側面もある。
開発があって初めてその支援たるカスタマーサポートがあるのだから文句言う前に産みの苦しみ、いくら気をつけてもバグが出る苦しみを知った方がいい。
うちの会社のシステム、ほぼ毎日いろんなバグが見つかってお客さんからクレームがきてる。
バグが直った時に、slack上では開発チームに「修正ありがとうございます」って送ってるけど、なんで自分たちが「ありがとうございます」と言っているのかよくわからない。
お客さんがバグを見つけて怒って、
開発チームがバグを直して、
なにかがおかしい。なんだこれ。
自分で引き起こした問題を自分で解消してなぜ感謝される構図になっているんだろうか。ただのマッチポンプじゃないか。
カスタマーサポートはお客さんをサポートするための仕事なんだよ。
不出来な開発チームのための緩衝材じゃないんだよ。
本当はサポートだけじゃなく、サクセスみたいなことも色々やっていきたいと思ってるよ。
でもできないんだよ。
新機能が出てもまともに動くとは思えないんだもん。
新機能出るじゃん？
お客さんに使ってもらうじゃん？
動かないじゃん？
怒られるじゃん？
どうせこうなる確率が１００％なんだから、それだったらもう新機能が出てもお客さんに伝えないほうが得じゃん？
もう新機能とか開発しなくていいから、ひたすらちょっとしたメンテナンスだけしててほしい。
余計なことしないでほしいというのがサポートチームの総意です。
なんでこの人たち給料が高いんだろう。
サポートセンターに問い合わせれば、お客様に応じて適切な対処方法をアナウンスしてますよ。
何を言っているんだろう。カビで死ぬリスクと怪我で死ぬリスクは、比較するまでもないリスクの差でしょう?
それに、お客様によって環境が違いすぎるから、汚れについては個別のアナウンスをするには人力対応が必要なんですよ。
そして一番は使い方。特にエアコン稼働終了後にちゃんと自動清掃モード状態(クリーンモード)を維持しているか。
一番ダメなやつは、停止ボタンを押した時に連打をして、清掃モードを強制終了するやつ。これをやってるとあっという間に結露が起きてカビがはびこる。
説明書にしっかりと書いてある。しかし9割の人は読まないんだな、これが。
もっと具体的に言うと、例えば夏に冷房を使ったあと、30分くらい暖房を稼働させると良い。そういう細かな温度調整のメンテナンスをすれば、ものすごくエアコンは長持ちすして汚れはつきにくい。そもそもそれを自動で行うのがクリーンモードなわけだが、「ファンの音が気になる」とかで強制終了する人が多い。
適切じゃない使い方をして機器に負担をかけて、それで健康被害がどーこー言われても、そりゃ「説明書読めよ」としか言えんわな。
よって、ご自身のエアコンが「カビをまきちらしている」と思うなら、まずは説明書を読んで適切な使用方法を確認する。
「デプロイ頻度は開発組織にとって一番大事なこと。カスタマーサポートがそれを妨害してる」
事業を成長させるにはカスタマーサポートを強化する必要があるということが顕在化したと言う考えなんだろうなぁ。
DevOpsの一部を切り取った主張にも見えるけど、元々DevとOpsの対立を無くすものだったという大前提が抜け落ちてそう。
彼は実装がめちゃくちゃ速く、コードもきれい。テストもちゃんと書く。
とてもできるエンジニアなのだが、一つだけ困っていることがある。
実装完了した機能をすぐに本番環境にデプロイできないと、とても不機嫌になるのだ。
うちの会社が開発しているのはtoBのシステムで、実装内容によっては営業やカスタマーサポートからお客さんにアナウンスがされてからでないとデプロイができないものがある。
急にUIが変わったり新機能が追加されるとお客さんが混乱するしカスタマーサポートに問い合わせが殺到するので、デプロイ前に調整が発生するのは致し方ないことなのだが、こうした背景を説明しても彼は納得してくれない。
「とにかく早くデプロイをさせろ」の一点張りで、彼が勝手にPRをリリースブランチにマージして、機能が出てしまったこともある。
それによってカスタマーサポートへの問い合わせが増えても、彼は知らん顔。
謝るどころか「デプロイ頻度は開発組織にとって一番大事なこと。カスタマーサポートがそれを妨害してる」などとのたまうものだから、もはやカスタマーサポートから嫌われていて「あの人に重要な機能は開発させないでください」とまで言われてしまっている。
きっと彼はプログラムを書くこと、自分の中で開発のサイクルを回すことが好きなだけで、運用には興味がないんだろう。
営業やカスタマーサポートやお客さんなど、自分の開発するものに関わる人々にも興味がないんだろう。
うちの会社のシステム開発、運用とは考え方が根本的に違いすぎるので、どこかの会社に彼を引き取っていただきたい。
＜追記＞
カナリアリリースを提案したこともあるんですが、「サポートが悪いんだからそのためにフラグを追加するのはおかしい。本質的じゃない。」と拒否されることがしばしばです。
しぶしぶ自分や他のメンバーがカナリアリリース用の追加PRをつくったりしていますが、それに対しても小言が飛んでくるのでとてもやりづらい。
・権限について
一般的なブランチ管理はしていて、mainへの直接マージなどもできないようになっていますが、彼がリリースの担当の時に自PRをしれっとリリースブランチにマージされてしまい、そのままの流れで本番公開まで至ってしまった形です。
厳格に管理してないほうが悪い的なコメントもありますが、何にどれだけ管理コストをかけるべきなのかは組織や事業のステージによりけりでしょう。
gitだけでなく様々ことに管理コストをかけてまでその人を活かすべきなのかというと、現状うちの会社ではNoだと思います。
彼の担当領域を社内向けのadminだけに絞る的な話は出ています。
彼としては社内向けの仕事は嫌らしく、また、adminを一番使うカスタマーサポートに対して敬意がないので難しそうな気はしますが。
いろんな権限を剥奪して、何かしら限定的な範囲を担ってもらうことになると思うんですが、彼の望む自由はそこにないと思うので、そのうち転職されるのではないかと思います。
