カスタマーサクセス部→未経験で開発部に異動してきた人間が思うこと

はじめに

こんにちは！
NE開発ブログリレーもいよいよ大詰めとなって参りました。
本日28日目は、さくらいがお送りします。

以前Qiitaでも書きましたが、私は弊社でも異例となるカスタマーサクセス部→未経験で開発部のジョブチェンを経まして、現在エンジニア2年目に入りたてのヒヨッコです。

https://qiita.com/saku_rye/items/48a274d00c4191b7c027

今回は、そんな私だから言える「CS時代に開発部に抱えていた不満」、そしてそれが「異動してどう変わったか」を、弊社先輩エンジニアの目を恐れず赤裸々にお話ししたいと思います。
CSと共に仕事をするエンジニアはもちろん、エンジニアの考えてることが分からん！というCSにとっても、この記事が一助となれば幸いです。

なぜエンジニアになったか

Q, さくらいさんは、なぜエンジニアになったんですか？
A, 開発部に不満があるのに、何もできない自分が悔しかったからです。

ジョブチェン後、社内外問わず何度もいただいた質問です。もちろんもっと言葉を考えた回答がベターですが、シンプルに言ってしまうとこうです。多方面から怒られそうですね。
ではここから、CSしか知らなかった私が開発部にどんな不満を抱えていたか、そしてそれが今はどう変わったかまでお話ししていきます。

実は推薦いただいて、社内エンジニアLT会でも発表しました。怒られませんでした。

CS時代に抱えていた開発部への不満→どう変わったか

1. 開発の優先度がよく分からない。誰がどう決めてるの？

なんと言ってもこれに尽きます。私が開発部に来た理由の8,9割はこれです。
今でこそ体制も変わりつつありますが、当時タスクの優先度は開発部内（とビジネスサイドの偉い人）で決定され、CSの下っ端には決定事項が言い渡されるだけでした。

ユーザー要望を開発に上げるだけで、それを溜めておく場所はあるが、実現はなかなかされない。
毎日ユーザーと対話している私たちが何度も訴えているのに、いまいち現場とエンジニアで温度感＝緊急度がチグハグなんじゃないか。そんな気がしてもどかしくて、でも何も変えられない自分が悔しかったです。実際、異動してきて「ああ、やっぱり伝わってなかったんだな」と思うことも往々。

クラウド化だの、PHPのバージョンアップだのに開発リソースの多くを割いているけど、それは実現したらどうユーザーに喜んでもらえるのか、なぜユーザーたっての要望より優先されるのか、憤りにも似たものを感じる時もありました。

異動後

思っていた何倍もの開発工数、開発の何倍も時間のかかる調査・検証、常に逼迫しているリソース、膨大な影響範囲、改修リスクetc…。エンジニアになって初めて、数々の「どうしようもない」を理解しました。
それでもその「どうしようもない」の間隙を縫って、色々な人がそれはもう色々な側面から、プロダクトの未来を考えて開発の優先度を決めていると知りました。また、エンジニア的視座の方が、より長期的かつ多面的にプロダクトを見やすい問題があることも理解しました（クラウド化、PHPバージョン問題とかまさにそうですよね）。

ただやはり、たまにでも良いので、開発部以外にも共有の機会があるべきだとは今でも思います。
「専門的な話は言ってもどうせわからないだろう」ではなく、なぜその開発優先度になったのか、なぜ今それが必要なのか。エンジニアもCSも、全員が常に自信をもってユーザーに説明できる状態が健全ではないでしょうか。少なくとも自分がエンジニアとしてCSに話す場では、なぜその優先度が良いと思ったかを必ず共有するようにしています。

---

2. 障害時のCS対応、方針が決まったら共有してほしい

障害対応中のエンジニア is この世で一番話しかけづらい存在、と言っても過言ではないんじゃないでしょうか。ものすごい緊迫感の中、もちろん邪魔はしたくない。でもユーザー対応が必要になる可能性があるなら、それはできれば早めに教えてほしい。でも超話しかけにくい…。全CSが今うんうんと頷いていることでしょう。

なぜ早めの共有が必要か、それは障害に関係ない他ユーザーまで影響が及ぶ可能性があるからです。
CSでもセールスでも終日ユーザー対応をする部署は、業界イベントの有無やユーザーごとの特徴などを見ながら架電やアポの時間を最適に組んでいます。そこに急遽対応が差し込まれる可能性がある場合、他CSメンバーと早めの連携が必要不可欠です。それが遅れた場合、アポ変更など最悪無関係のユーザーにまでご迷惑をおかけすることになりかねません。

異動後

障害を起こしてしまった本人は、本当に頭まっしろ、正直目の前の対応のこと以外は考えられないですよね。わかります、私も変な汗をビッショリグッチョリかきました。あれはエンジニアにならないと体験できない恐怖NO.1です。
そんな時に「あの〜CSはどうしたら…」と聞かれたら、もちろん邪険にはせずとも、私のようなヒヨッコはパニックが加速すること間違いなしです。

だから渦中にいる人でなくていい、周囲の冷静な誰か一人でいいのです。状況と対応方針がまとまったら、ユーザー対応部署のことを思い出して、簡単に共有してあげてください。動く必要があるか/ないかだけでも早めに伝えられると、きっとエンジニアが思ってる10倍助かり、感謝感激されると思います。

---

3. 新機能の開発、UI/UXの刷新がされにくいのはなぜ？

これはCS外、セールスやマーケともよく話していました。新規契約獲得や解約阻止の大きな武器となる新機能、スムーズなオンボーディングを後押しするカッケェUI/UX。そういったプロダクトの目玉になる新開発よりも、既存機能のアップデートや改修の方が多い気がして、「なんかもっとこう、ババン！！とでっかいことやっちゃいたくないか？？！」とよく同期エンジニアを焚き付けていました。

異動後

エンジニアだってやりたいのは山々なんです！！やれるもんならやりたいと、皆んな思ってます！！と大声で書きましたが、本当にこれはどの会社、どのエンジニアもそうなんじゃないでしょうか。新しくて望まれててかっこいいモノを作りたい気持ちはみんな同じです。

ただこれもエンジニアになって初めて知った、コードとはハウルの動く城のようなもの。城の中枢部らへんに位置する古い浴槽を、新型の新しいジャグジーにしたいのなら、それは浴室の改装だけで済む話ではありません。城の歩みを止めずにお風呂だけをかっこよくするのは、発注した家主が思っているよりずっとずっと大変です。歴史あるレガシーコードなら尚更、どこかの小さいネジを一本引っこ抜いただけで、城全体が崩壊するかもしれません。エンジニアはいつだって「このネジを抜いても城は歩き続けられるか」を考えています。

その他にも、それは新規を獲るための新機能なのか、既存ユーザーの満足度向上のための新機能なのかなど、1で前述した通り、結局はプロダクトマネジメントの話とも複雑に絡み合っていきます。
それでも一つだけ確実に非エンジニアに伝えられるのは、お風呂には全く関係なさそうなネジの補強が、実はジャグジー導入の下地の下地になっている、みたいなことは結構あるぞということです。

おわりに

以上、「不満があるならば自分がエンジニアになってしまえ！」と、えいっとジョブチェンしてみた人間の気持ちと行動の変化でした。
ここまで読んでいただき、それはお前次第でCSでも改善できた不満やろ！と思われた方にも、心当たりがあってグサッと刺さった方にも、ここまで読み飛ばして来た方にも、最後に伝えたいカスタマーサクセス部→未経験で開発部に異動してきた人間が思うこと（タイトル回収）はただ一つ、「勝手に諦めるな」です。

「あれはエンジニアの話だから/CSの話だから、きっと話しても/聞いてもわからない」なんてことはないんです。それは俺が知る必要のないことだって、無意識に諦めてませんか。もちろん開発には開発の、CSにはCSの、各々だけが知っていればいい難しい専門的な話はあります。でもそうではなくて、本当にユーザーのために動いていることなら、開発もCSも同じ方向を向いて同じ言語で話せるはずです。私は両方経験して、どちらの苦しみもわかる人間になって、やっとそれができるようになれました。

他部署事だと思って勝手に諦めないで、言葉を尽くして、伝える努力をして、理解する努力をしてみたら、チームって組織ってプロダクトって、なんかもっと良い方にいっちゃうんじゃないの！？と思うのです。
長々と読んでいただき、ありがとうございました！