職種の越境と、溶け出す「エンジニア」
どうも、エンジニアのgamiです。
先日、僕が共同主催している「Customer系エンジニア座談会」というイベントでゲスト登壇者の方から面白い事例を聞くことができました。
その登壇者というのはアルプ株式会社 AccountManagementチームの岡部さんで、いわゆるカスタマーサクセス職の方です。「エンジニア」を冠する職種以外の方にご登壇いただいたのは、Customer系エンジニア座談会としては初でした。
岡部さんの登壇内容は、「カスタマーサクセス職のメンバーがSQLやJenkinsを駆使して日常的に本番データベースのデータを修正・抽出している」というにわかには信じられない話でした。イベント中の観客からも、「想像以上に技術よりの話だった」とか「もはやエンジニアでは？」といった驚きの声がDiscordに寄せられました。
今回は、カスタマーサクセス職がエンジニアリングを駆使して業務範囲を広げているというこの事例を題材に、職種の越境について考えます。
「エンジニア」と「非エンジニア」の境界とは？
「エンジニア」とは、字面から考えると「エンジニアリングをする人」のことです。一方でアルプさんの事例を見てもわかるように、「エンジニアリングをする人」は必ずしも「エンジニア」ではないことがわかります。
現状ではまだまだ技術の力で解決しなければいけないものが多いです。この場合、できるだけ早期に、高いクオリティでシステムを提供することが求められます。そうなると結果的にエンジニアの工数問題が起きがちです。
BtoBサービスのコア業務を行っていく中では、常にこの課題と向き合っていく必要があります。エンジニアの問い合わせ対応工数を減らすため、弊社ではCSもエンジニアリング思考で取り組んでいます。
考えてみれば、「エンジニア」という存在も曖昧です。もちろん全てのエンジニアが生まれたときからエンジニアであるはずはありません。医者などの職種とは違って、エンジニアと名乗るために必須の資格があるわけでもありません。僕自身もエンジニアを名乗っていますが、今の役割やスキルを表すのに都合がいいから名乗っているだけであって、必要ならエンジニアという肩書きを名乗らなくてもいいとさえ思っています。
最近では、非エンジニア職種として働いていた人がプログラミングスクールに通ってエンジニアに転職するというケースも増えています。僕は営業、役者、アイドル、消防士などの職種からエンジニアに転職して活躍している方を知っています。これがたとえば「仕事の合間に勉強して弁護士になりました」だったら、かなり驚くべき事態です。「エンジニア」と括られる仕事の中で価値を出すだけであれば、世の中の多くの人が思っているほどには難しくないと言えます。
もしそうであれば、エンジニアが得意とするような領域に非エンジニア職種の人が手を伸ばすのも、その人が思うよりハードルが低いかもしれません。アルプさんの事例は、カスタマーサクセス職の方々がエンジニアリングに手を伸ばして役割範囲を広げた好例といえます。たとえば僕が所属するプレイドという会社でも、非エンジニアのメンバーが、技術的なプロダクト仕様を深く理解して顧客の質問に応えたり、SQLで複雑なデータ抽出をしたり、SaaSを組み合わせて簡単な自動化を実現したりといった様子をよく目にします。
もちろん、エンジニアにしかできない高度な専門知識が求められる領域も存在します。主にはプロダクト開発にまつわる業務です。一方で、エンジニアが自然に扱っている手段や知識や思考法は、開発以外の分野でも大いに役に立ちます。前述の記事に「エンジニアの工数問題」と書かれていたように、全ての業務領域をエンジニアがカバーするにはエンジニアの手はとても足りません。
非デザイナー職種の人がデザインを学んで業務に活かすように、非エンジニア職種がエンジニアリングの領域に手を伸ばすような動きは今後ますます重要になってきます。
何がエンジニアリングのハードルを下げるか？
一方で、「エンジニアリングにまで手を伸ばして業務領域を広げる」ということを想像できない人も多くいると思います。そのハードルを下げる要素があるとしたら、どんなものでしょうか？
何より重要なのは、社内のエンジニアとの距離感です。エンジニアに気軽に教えを請い質問できる環境じゃなければ、最初のハードルを超えられません。
今までSQLには触れたことはなく、いざ触りだしてもつまずくことばかりでした。最初は目的のデータ抽出もままならなかったのですが、Slackのtimesで呟いていたところ、周囲のエンジニアから改めて考え方を説明していただいたり、突然質問しても丁寧に教えていただいたりと手厚いサポートをもらって少しずつ進んでいきました。
SQL勉強会の資料も改めて見直し、何度もRedashを触ることで、理解度が徐々に上がり、ごく簡単な参照なら自分でできるようになってきました。その後、データの参照だけでなくテンプレートのあるデータの修正クエリはCSが書いて、開発チームの方にレビューしてもらうことで経験を積みました。今はお作法がわかってきたのもあり、対応したことがないクエリについても開発チームに適宜振ってもらっています。CSが作成したクエリを開発チームがレビューしてくれることもあり安心して挑戦することができます。
もちろん単に技術的な知識を付けるだけであれば、本を読んだり社外のエンジニアに聞いたりすることもできます。しかし業務に直結する取り組みを進めるには、同じオフィスに座っていて一緒に画面やデータを見ながら相談できるエンジニアの存在に勝るものはありません。
エンジニアとの距離感という意味では、Tech系のスタートアップは有利です。アルプも2018年設立の若い会社で、まだまだビジネスサイドとエンジニアの距離が近いように見えます。僕が属するプレイドも社員数は200人を超えて大きくなってきましたが、エンジニアとその他の職種はフリーアドレスの座席に入り混じって座っており、お互い気軽に話しかけることができます。
逆に言えば、社内にエンジニアがほとんどいなかったり距離が遠かったりする場合は、こうした取り組みを実現するのは難しいかもしれません。長期的には、社内に優秀なエンジニアを増やしていくことが望ましいでしょう。
もしかしたら、社内にエンジニアがいなくても、自分のやりたい領域に近いSaaSを駆使することで業務の幅が広がるかもしれません。世の中に価値あるSaaSプロダクトが増えていることも、エンジニアリングのハードルを下げているといえます。僕自身もSaaS企業の中の人ですが、SaaSプロダクトを深く使いこなすためであれば顧客企業の立場でSaaS企業のカスタマーサクセスやエンジニアを頼ることもできます。
目的のために職種が溶け合う世界へ
最近流行りのDXっぽい文脈でよくある誤解として、事業や業務における課題はエンジニアを採用して高度な技術を導入しさえすれば解決すると思われがちです。しかし現実には、課題を解くのに適した技術をうまく選択し、さらにその技術を課題に合わせて運用し続ける必要があります。
たとえば社内データに対して自由にSQLを実行できる環境がカスタマーサクセスの部署に提供されたとしても、部署のメンバーがSQLが全くわからなければ何の価値も生み出しません。実際には、エンジニアとディスカッションしながらデータの扱い方を議論したり、業務課題に直面する現場のメンバー自ら運用設計をしたりして初めて価値が出ます。
また最近は、お客様の増加に伴いクエリ対応が多くなってきたので、開発チームと意見交換しながらJenkinsのバッチや、画面上に機能として提供してもらうための相談をしています。CSチーム内でも、クエリを汎用化して他のメンバーがアレンジしやすいようにするなど、将来の自分たちの仕事を減らすために日々の対応を効率化していきたいと考えています。
エンジニアが普段扱っている技術や考え方の一部は、あらゆる職種にとっての武器となります。しかし、単にエンジニアが社内にいるだけで自然とその技術が社内に浸透して勝手に価値を生むなどといううまい話はありません。
「技術を使って業務上の課題を解決する」という目的の前では、職種の境目などあまり意味がありません。実際、アルプやプレイドでは非エンジニア職種のメンバーでもSQLやJavaScriptを書いてカバー範囲を広げています。また僕のようなCustomer Engineerは、開発業務を飛び出してカスタマーサポートやカスタマーサクセスと一緒に動くことをメイン業務の1つとしています。
このように、特にTech企業の中ではエンジニアと非エンジニア職種の間で両側からの越境が進みつつあるといえます。
エンジニアリングの力は、今後あらゆる職種にとってさらに強力な武器となっていきます。そんな便利なものを「エンジニア」と呼ばれる職種の人々だけで専有するのはあまりにももったいない。エンジニアを定義する枠をどんどん曖昧にしていき、エンジニアリングの力を他の職種に溶け出させることで、あらゆる仕事がもっと楽しくなると僕は信じています。
ここから先は
仕事を楽しくするデジタルリテラシー読本
【初月無料】デジタル時代の歩き方について考えたことを発信します。ソフトウェアの時代とは何か。エンジニアの頭の中はどうなっているのか。NoC…
サポートをいただけると、喜びドリブンで発信量が増えます！初月無料のマガジン『仕事を楽しくするデジタルリテラシー読本』もおすすめです！