家族の肖像画を取り戻すために祖国に訴訟を起こす老婦人と若手弁護士の話。なかなか良かった。
老婦人がオーストリアの貴族の家柄の人で、いかにも貴族らしい威風堂々とした立ち居振る舞いが清々しかった。
弁護士はベン・アフレックに似てるなあと思いながら観てたけど全然違う役者だった。
SSH サーバへの接続を公開鍵認証ではなく証明書認証で行うこと。
↓作業手順はこのドキュメントがわかりやすい。
sudo ssh-keygen -f /etc/ssh/ca
sudo ssh-keygen -s /etc/ssh/ca \ -I "$(whoami)@$(hostname --fqdn) user key" \ -n "$(whoami)" \ -V -5m:+3650d \ ~/.ssh/id_rsa.pub
IP アドレス制限を設ける場合
sudo ssh-keygen -s /etc/ssh/ca \ -I "$(whoami)@$(hostname --fqdn) user key" \ -n "$(whoami)" \ -V -5m:+3650d \ -O source-address=$(hostname -I | tr ' ' ',') \ ~/.ssh/id_rsa.pub
echo "AuthorizedPrincipalsFile %h/.ssh/authorized_principals" | sudo tee -a /etc/ssh/sshd_config echo "TrustedUserCAKeys /etc/ssh/ca.pub" | sudo tee -a /etc/ssh/sshd_config echo $(whoami) > ~/.ssh/authorized_principals sudo systemctl restart ssh.service
ssh -i
で秘密鍵を指定する
azureuser@ssh-client:~$ ll ~/.ssh/ total 28 drwx------ 2 azureuser azureuser 4096 Mar 1 15:04 ./ drwxr-xr-x 5 azureuser azureuser 4096 Mar 1 15:04 ../ -rw------- 1 azureuser azureuser 553 Mar 1 14:52 authorized_keys -rw------- 1 azureuser azureuser 1679 Mar 1 14:55 id_rsa -rw-r--r-- 1 azureuser azureuser 1503 Mar 1 15:00 id_rsa-cert.pub -rw-r--r-- 1 azureuser azureuser 402 Mar 1 14:55 id_rsa.pub -rw-r--r-- 1 azureuser azureuser 222 Mar 1 15:04 known_hosts
↑こういうファイル配置なら -i オプションなしで良い。
$ ssh azureuser@192.168.x.x
ずっと「マージした後にメインブランチを production デプロイする」というワークフローだと勘違いしていた。
昔は「マージ後にデプロイ」だったが、いつの頃からか「マージ前にデプロイ」に変わったらしい。
もちろんチームによってワークフローは違って構わないし、上記ドキュメントでも "For some, it may be best to deploy to a specially provisioned testing environment." と説明されているが、 "For others, deploying directly to production may be the better choice" とも。
カスタマーサポートの仕事をするのは初めてなので、そもそもどういう仕事なのか?という基本的な知識をインプットしたいと思い、手頃そうなこの本を読んだ。
平易な内容でわかりやすかった。文章もとても読みやすかった。短いので短時間で読み切れたし、値段もとても安かった。
サポート業務の極意 いかにしてストレスなく、顧客満足度を上げることができるか (OnDeck Books(NextPublishing))
なお、お褒めの言葉をいただいたときに忘れてはいけないのが、周りの方々(同僚や開発部署、営業部署など)への感謝の気持ちとお礼の言葉、そして、お客様からの喜びの声をフィードバックすることです。
フィードバック重要。
サポート員にとって、最も大事なことは、「お客様に満足していただけること」です。
問題解決するだけでは不十分。顧客満足度の向上(を通じて売上に貢献すること)が使命。
合わせて、ご対応/ご協力いただいたことに対して、お客様に感謝とお礼の言葉を伝えます。
なるほど。
お客様からいただいた問い合わせに対して、単純に回答すれば良いわけではありません。問い合わせに回答する際に、お客様に満足していただくことがサポートにおいて非常に重要なのです。
大事なことなので二回ハイライトした。
過去の例では、多機能で高性能な海外の製品が、国内でのサポート技術力が弱いために、市場から消えてしまったことがあります。
:scream:
当然のことですが、「顧客満足度」の調査結果において、1位でないとまったく意味がありません。「顧客満足度で2位になりました。」と言っても、信頼されないでしょう。「1位を取った製品と、それ以外」というレッテルを貼られることこそが、関係者には非常にきついのです。
そうかな、2位でもそんなに悪印象は抱かないが。
最も大切なことは、お客様からのお問い合わせに対して、「迅速に」回答することです。(中略)詳しい説明や丁寧な応対を受けたとしても、問い合わせから数日後の回答では、まったくありがたみを感じません。
リードタイムの期待値は業種や製品によって違うとは思うけど、尤もだ。異常に細かい説明文を時間をかけて書くタイプなので、気をつけよう。
例えば、調査に時間がかかるような場合は、「XX日までに状況をお伝えいたします。」と連絡を入れておくことで、対応が遅いと感じることはないでしょう。
XX日ごとに、問い合わせ状況をお知らせします。」と伝えることでお客様は安心します。
これは自分が開発担当者としてカスタマーサポート担当者から調査依頼を受けたときに、 ETA の目安を伝えたり途中のチェックポイントで状況を共有したりする形でやっていた。
「トラブルを解決すること」が目的ではなく、「お客様が満足すること」が最終目標であることをくれぐれも忘れないでください。
これも業種や製品によって温度感に差はありそうだが、大事なことなので三回ハイライトした。
問い合わせの件だけど、現在はどうなっているの?」と聞かれた時点で信頼関係は崩れています。
手厳しい。
気をつけなくてはならないのが、お客様が不満に思っているからとやみくもに、お詫びをし続ける態度を取ることです。これは、経験の浅いサポート員が陥りやすい誤った対応で、かえって逆効果です。
そうなのか。言われてみれば確かに、「謝ってやり過ごそうとしてるだろ」と見透かされそうな。気をつけよう。
なぜなら、担当製品以外のお問い合わせに対して、責任を持った回答を提示することができないからです。
心を鬼にして、「担当製品以外のことについては、わかりかねます。」と回答しましょう。
これは会社のポリシーやスタンスによって結構違いがありそう。
今までかつて、成長しなかったサポート員を見たことがありません。
力強い言葉。
その製品やソフトを購入してもらえなくなること、利用してもらえなくなることが最大の恐怖なのです。つまり、サポート契約がなくなること、ひいては売上がなくなること、最終的にはサポート員の仕事がなくなることこそが、一番の恐怖なのです。
黙ってさる顧客がいちばん手痛い、ということ。
サポート員の方は、「クレーマーであっても、大切なお客様であること」をくれぐれも忘れないようにしましょう
はい。
サポート業務では、精神的に追い詰められる場面にたびたび遭遇します。そのようなときは、自分の中で抱え込まずに早いうちにアラートを上げるようにしましょう。
自分自身でのメンタルケア大事。
ガートナーによると、「2018年までに、200万人の労働者が雇用条件の1つとして健康モニタリング・デバイスの着用を求められるようになる」と予測されています。
例えば消防隊員とか、と続くので、デスクワーカーにもその波が来るのはもっと後だろうけど、未来な感じ。
「〜できません。」で終わるのではなく、「〜まではできます。」と肯定的に回答します。前向きな言葉で回答することにうより、打ち消された感じを払しょくすることができます。
表現のテクニック。
応対に正解はありません(100点を目指さない)
どんな仕事でもそういう側面はあるが、完璧主義に陥らないの大事。
他にもハイライトした箇所はあるけど、この辺で。