![見出し画像](https://assets.st-note.com/production/uploads/images/62188113/rectangle_large_type_2_346b53858350e90af75aab3ca3462c9d.jpg?width=800)
CSがWeb技術を学ぶべき理由
自己紹介
・東京生まれ、東京育ちのアラサー男。
・私大文系学部を卒業後、大手百貨店に入社し、子供服Divに配属。
・SaaSベンダーに転職し、カスタマーサクセスに3年以上従事。
・現在、別のSaaSベンダーにエンジニアとしてジョイン。
なぜ百貨店からSaaSベンダーに?
結論から言えば、本当に偶然なのです。
※ ここで言うCSはクラウドサービス提供ベンダーのカスタマーサクセス及びカスタマーサポートのことです。
デパートマン時代は販売・仕入れ担当を兼務しており、商品の販売を通じてお客様に寄り添い、幸せにすることができていたという自負がありました。
しかし、その犠牲はあまりにも大きく、日々の売り上げ予算との格闘や現場を円滑に回すため昼休憩がまともに取れない日々が1年以上続いたり、休日出社やサービス残業などを繰り返し、結果的に身体と精神が壊れるほど働きました。他にも要因はあるものの、そうした背景から私は百貨店を退職しました。
幸いにも転職活動を始めて1週間ほどで別業界の営業職で内定を頂けたものの、ご縁があって、とある企業をご紹介頂き、同社のビジョンやSaaSというビジネスモデルに共感したこと、面接官である前職の上長が偶然にも同業界出身だったということもあって、IT業界・SaaS業界に足を踏み入れました。
ブラウザも理解していなかったIT業界転職当初
恥ずかしながら、IT業界に転職した当初、以下のような場面が実際にありました。
先輩:「ゆうぞーくん、そのブラウザではうちのアプリケーションは非対応だよ」
自分:「先輩、今自分が使っているブラウザって何でしょうか?」
先輩:「え?……………」
残念ながらこのエピソードは至って真剣なのです(笑)
ユーザー向けのクローズドサイトのコンテンツを編集する際に以下のようなHTMLソースがあり、「ここの見出しの大きさをh1からh2に変えといて」と依頼されることがあっても、何を言われているのか全く理解できない…そんなレベルでした。
<!DOCTYPE html>
<html lang="ja">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width,initial-scale=1.0">
<title>サンプルHTML</title>
</head>
<body>
<h1>ホームページへようこそ</h1>
<p>誰でも歓迎するよ!!</p>
</body>
</html>
恥ずかしいレベルのリテラシーだった上に何を勉強したら良いのかさっぱり分からなかったので、社内の開発エンジニアに相談し、数冊の本を渡され、ひたすらインプットとアウトプットを繰り返しました。
職責として必要以上に技術面のインプットをすることに対し、チーム内から「何を目指しているの?」と白い目で見られることも多くありましたが、どこまでがCSとして一般的な知識であるかの区別がつかなかったので技術のプロフェッショナルであるWebエンジニアのアドバイスを信じてひたすら学びました。
具体的に何を学んだのか?
・Web技術の基礎(ドメイン、DNS、HTTP、DOM、APIなど)
・ネットワークの基礎(Webサーバ、冗長化、SSLなど)
・HTML / CSS / jQuery
・Ruby および Ruby on Rails
・LINUX(概要とCUIの基本的なコマンド)
・SQL
なお、Ruby及びRuby on Railsの学習はプログラミングスクールを活用しました。
プログラミングスクールは数多ありますが、同じ会社にいた現役のWebエンジニアが「本気でやるなら選択肢に含めるのもアリかもしれないよ」とアドバイスをもらい、RUNTEQで学習することにしました。
近年、プログラミングスクールは賛否両論あります。確かに決して手を出しやすい金額ではありませんでしたが、個人的には実際に学習方法や考え方など様々なヒントやアイデアを享受でき、本質を学ぶことが出来たという点で非常に良い投資だったと考えています。
学ぶべき理由
①トラブルシューティングの向上
一般的にユーザーは自分が置かれている状況を言語化するということは非常に難しいため、事実でなくても「不具合」や「バグ」などと非常に抽象的な内容で問い合わせてくることが日常茶飯事です。
そうした背景もあり、トラブルシューティングではユーザーからヒアリングした事象の概要や直面している状況などに対し、全て疑うことから始めるのが必要です。
残念ながら、どんなサービスであっても発生している事象の原因や回避策を100%断言・断定することは現代の科学技術では非常に困難なのが実情です。
そのため、CS担当はユーザーが置かれている状況に対して、考えられる可能性を1つ1つ潰していくことが必要です。手間ではあるものの、ユーザーが何をしようとして、何をした結果、どのような結果を想定したが、今どうなっているのか、などの状況をヒアリングした上でブラウザやネットワークの環境情報やログなどのあらゆる情報(材料)を事前に準備・ヒアリングすることで結果的に最短且つ最良の回答を導くことができるのです。
そして、技術的な知識があれば、先に得た情報と技術(原理)などと掛け合わせて考えられる可能性をより絞り込むことができるので、回答のスピードや精度の向上に寄与することができるのです。
②機能要望に伴うヒアリング精度の向上
SaaSのプロダクトであれば、機能要望は最も重要な財産の1つです。しかし、エンドユーザーからCSに届いた要望を開発部門へ伝える際に伺った情報を正確に把握し、正確に伝えるということが出来ているCSはどのくらいいるでしょうか?
残念ながら、私の経験上では完璧に出来ていたことはあまり多く無いというのが実情です。しかも、その多くは自分たちの知識レベルが足りていない故に発生していたという事実がありました。
Webを介したクラウドサービスは同じような技術を使うことが多々あります。そのため、ユーザーが寄せた要望に係る機能が物理的に実現可能なものか、可能であるなら競合他社では実装しているのかなど、少しググるだけでも意外と答えが見つかることも珍しくありません。
その際に前提知識を固めることで己の調べ方(ググり方)も改善することができ、結果的に顧客へのヒアリング精度も改善し、なぜ必要なのか代替案は無いかなどをより的確に提示しやすくすることができました。
③エスカレーションの削減と期待値コントロール
私が勤めていた会社ではCS担当でも手に負えない複雑なトラブルでは開発部門やインフラ部門にエスカレーションするフローとなっていました。
このエスカレーションの際、私はユーザーから聞いたヒアリング内容をエンジニアに対して非常に抽象的な概要だけ伝えてしまっており、エスカレーションした後にエンジニアから2度も3度も追加の確認事項が来るといったことが常態化していました。
これはCS側(当時の自分)が事前にユーザーに聞くべきことを聞くという仕事をサボってエンジニアに丸投げした結果を表しています。そして、それによってCSもエンジニアにとっても極めて無駄な稼働が掛かり、ユーザーへの回答スピードもどんどん遅くなっていました。
私はこうした失敗の積み重ねによって、「後から聞くくらいなら、問い合わせがあった時点で事前に聞ける内容をヒアリングすることで、無駄な追加確認の削減やユーザー自身による自己解決に繋げることができる」ことを学びました。
④事故的なチャーンの抑制
稀ですが、「改修しないなら解約する。」と迫ってくるユーザーも中にはいます。しかし、要件を聞いてみると競合他社どころかWebの原理上、物理的に不可能なものが意外と多いということに気づきました。
感情的になって解約する方も中にはいますが、解約して競合他社のサービスに乗り換えたのに、しばらくしてまた我々のサービスに戻ってきたユーザーも見受けられたので、そのユーザーに話を聞いてみると「やっぱり他社でも出来なかった」とのことで戻っていることが明るみになりました。
これはお互いにとってとても不幸な事故でしかありませんよね。ヒアリングをした際に技術的な知識を有することでなぜ不可能なのか具体的なファクトを提示でき、感情論に移る前にご納得してもらえる状況を作れたのではないかと感じました。
一通り学んだ後に同様の事案に直面したことも多々ありますが、なぜできないのか具体的なファクトやエビデンスを提示した上での仮説を提示していたので、こうした事故的なチャーンを防ぐことができていました。
Web技術を学んでみて分かったこと
Web技術はとても平等なもの
営業や販売などは個々人のバックグランドや対外的な要因に依存することも多く、意外とアンフェアであると感じていました。一方、Web技術自体は原則として誰であっても決まった処理が行われるのでとてもフェアなものです。
しかし、それは同時に冷たい意味を含んでいます。Web技術は原則として「知らない」という都合を一切考慮しません。つまり、それらの知識を「知っている」ことが前提となっています。「私はITやネットに関して疎くて…」という各々の背景や都合はWebの世界からすれば、そもそも求められていないのです。
全部を覚える必要はなく、大枠を把握することが重要
Webエンジニアやプログラマーと聞くと、爆速でプログラムを書いていく様をイメージするかもしれませんが、そうした場面は意外と多くはありません。
接するプログラムのメソッドやライブラリーは山ほどありますが、全てを覚える必要はなく(と言うよりも難しい)、定められた要件に沿った一連の処理の流れや仕組みを把握することが最も重要なのではないかと感じます。
「知らない」という都合は市場からは求められていない
営業、CS、バックオフィスなど、Webデザイナーやエンジニアでない職責の人にありがちですが、ビジネスの場面は論理的に物事を考え、行動できるにも拘らず、なぜか技術的な話になると苦しい言い訳ばかりを並べて、理に適っていない都合で自ら壁を作っている人を目にします(以前の自分もそうだった)。
これは各々にとって非常に勿体無いことです。クラウドサービスなどのプロダクトに従事するベンダーの人間は、その担当者がどのような役職であろうと職責の差異はユーザーにとって全く関係が無く、そもそも求められていません。
従って、「私は営業担当だから、文系出身だから、技術的な部分まで把握する必要はない」という主張や都合は求められていないため、理に適っていないということは明白です。
ユーザーから求められていない都合を押し通したとしてもユーザーからの期待値が高まる可能性は低いため、「やるべきこと」と「やっていること」に矛盾が起きているということも明らかではないでしょうか?
どうか、状況を冷静に分析して、学ぶことのメリットと学ばないことのデメリットを再考することを強く推奨します。
学習に使用した書籍
1:Web技術の基本
発行:SBクリエイティブ株式会社
→このレベルの知識は頭に入れておきたいと思う内容
2:3分間HTTP&メールプロトコル基礎講座
発行:株式会社技術評論社
→このレベルの知識は頭に入れておきたいと思う内容
3:DNSがよくわかる教科書
発行:SBクリエイティブ株式会社
→このレベルの知識は頭に入れておきたいと思う内容
4:ネットワークがよくわかる教科書
発行:SBクリエティブ株式会社
→このレベルの知識は頭に入れておきたいと思う内容
5:新しいLinuxの教科書
発行:SBクリエイティブ株式会社
→CUIを触る機会がある人なら学ぶべき価値あり
6:SQL第2版ゼロからはじめるデータベース操作
発行:株式会社翔泳社
→ログ抽出などの際にとても役立つ知識が満載
7:プロを目指す人のためのRuby入門
発行:株式会社技術評論社
8:オブジェクト指向でなぜつくるのか第2版
発行:株式会社日経BPマーケティング
結び
ユーザーに寄り添うための手段としてWeb技術は有効なので、己とWeb技術の間に理に適っていない勝手な都合で壁を作らない方が良いと思います。
Web技術を学ぶことで自身の視野は広がり、可能性も大きくなることは私自身も実感していますし、CSとして従事した日々の業務の中でも大いに役立ちました。
「知らない」という都合がユーザーや会社から求められているのかをもう一度よく考え、自分はCS担当としてどうあるべきかを再考してみては如何でしょうか?