エンジニアを色んなチームに埋め込む
どうも、エンジニアのgamiです。
最近、Customer系エンジニア座談会というオンラインコミュニティを立ち上げました。
先日の第00回イベントでは、初回にもかかわらず25名もの人に申し込みをもらいました。自分が呼びかけたイベントに人が集まってくれるというのは、嬉しいものです。
さて、こうした試みをしているのも、エンジニアが関わる課題解決のフィールドをもっと広げたいという思いがあるからです。
一般的に、エンジニアと聞くとソフトウェアやハードウェアの設計・開発・運用を担っているイメージがあります。しかし、エンジニアの専門領域であるところの「エンジニアリング」とは、実はもうちょっと広い概念です。
今回は、Customer系エンジニア座談会の立ち上げを記念して（？）、エンジニアが組織の中の様々なチームに散らばって働くことの価値について考えます。
Customer系エンジニアは増えている
Customer系エンジニア座談会では、主に次のような職種の人に登壇してもらっています。
・Customer Reliability Engineer（CRE）
・Customer Engineer
・Customer Success Engineer
・Customer Support Engineer
職種名は安定していませんが、どれもソフトウェア開発エンジニアと比べると顧客により近いチームで動きます。
今の日本でこれらCustomer系エンジニアを明示的に採用しているのは、エンジニア向けの機能を持ったSaaSやIaaSの会社が多いです。顧客企業の担当者がエンジニアであれば、顧客への商談やサポートもエンジニアがやらないとあまり話が通じません。
ただし、こうしたわかりやすい理由だけではなく、より顧客やユーザーに近いチームでエンジニアが働くことの価値に注目が集まっています。たとえば、BtoC事業をメインとする会社でのCREチーム立ち上げも増えてきています。
BtoC領域のCREチームは、主にカスタマーサポートの業務をエンジニアリングの力で改善したり、ユーザーの利用状況をモニタリングできる仕組みを構築したりに注力するケースが多いようです。
このように、ソフトウェアやハードウェアの設計・開発・運用という従来のイメージとは違う役割を担うようなエンジニアが増えつつあります。
エンジニアリングってなに？
会社が事業において直面する多くの問題は、不確実性と関係しています。
・変化の激しい市場で継続的に売上を上げ続けるには？
・大量の雑多なサポート問い合わせを適切にハンドリングして事業成長につなげるには？
・顧客や投資家と約束した期日までに目の前の未完成プロダクトを完成させるには？
どの手段を採用するのが適切か、未来の状況がどう変わるのか、それがわからないまま目的を達成しなければいけません。そのとき、エンジニアリングの力が役に立ちます。
エンジニアリングという行為は、何かを「実現」することです。実現のために、不確実性の高い状態から、不確実性の低い状態に効率よく移していく過程に行うすべてのことです。
もちろん、エンジニアだけがエンジニアリングをしているわけではありません。誰しもの業務の中に、少しずつエンジニアリングの知見は自然と溶け込んでいます。たとえばKPIを眺めて何らかの意思決定をしているとき、そこには経営工学（=エンジニアリング）の視点が知らずに入り込んでいます。
一方で、とりわけコンピュータとの共同作業が当たり前になった現代では、データやプログラムを使ったアプローチに強いエンジニアの方が解きやすい問題が増えています。
エンジニアは、よくわからない曖昧な現実を適切にモデル化し、定型的なデータで表現して、データベースの中のレコードとして扱えるようにします。そのレコードを計算機資源で処理して、見るべき指標を可視化したり適切なアクションを自動化したりします。こうした活動をさらっとできるのがエンジニアの強みです。
優秀なエンジニアに囲まれてエンジニアとして仕事をしていると気付きにくいですが、エンジニアと非エンジニアの間には問題解決のために取れるアプローチの幅に大きな差があります。非エンジニアのメンバーが「こんなことはできるはずがない」と暗に思っていることが、エンジニアのメンバーが週末にちょっと頑張るだけで簡単に実現できてしまったりします。
Embeddedなエンジニア
もちろん、どんなにエンジニアが問題解決の手段を豊富に持っていても、「じゃあエンジニアだけが組織にいればいい」とは全く思いません。カスタマーサポート、マーケティング、セールス、広報、人事、労務、経理、etc…。それぞれの専門性を発揮すべき仕事はたくさんあり、少なくともエンジニアの僕にはとても真似できません。
ただテクノロジーを採用すれば目の前の問題が解決するわけではないのと同様に、ただエンジニアリングの知見を振りかざせば解決するような問題はあまり多くありません。エンジニアが聞きかじった知識と自動化の力で駆逐できるような職種があるとすれば、そのような職種はすでに無くなっているはずです。人間がつくる社会や組織に相対して価値を生むような仕事には、まだまだ人間が必要です。
重要なのは、問題に直面した人がエンジニアと協力しながら問題解決に当たることです。逆から見れば、エンジニアにとってはその問題を自分ごととして取り組む必要があります。Customer系エンジニアも、まさにソフトウェア開発のチームを飛び出して別の問題に取り組んでいるエンジニアといえます。
別職種の似た話として、Embedded SREがあります。たとえばメルカリさんでは、SREが各サービスのプロダクト開発チームにEmbedされるような組織を良しとしているようです。
メルカリにおいて、Platformチームが担っているのは上記のうち「Center of PracticeとしてのSRE」であると考えています。そのポジションは、メルカリがマイクロサービスという技術的チャレンジを行っていく上で最新のテクノロジーを活用し、ベストプラクティスを打ち立てるために必要不可欠であったし、今後も大きな意味を持ち続けることは明らかです。その上で、それではカバーしきれないプロダクトチームの内側の領域をカバーできるEmbedded SREが存在することで、より解像度高く運用現場の内情を把握しそれをPlatformチームにフィードバックして改善していくサイクルが作れるのではないかと考えました。
Customer系エンジニアも、顧客に近いカスタマーサポートやカスタマーサクセスなどのチームにEmbedされたエンジニアといえます。
今後はCustomer系エンジニアに限らず、職種としてのエンジニアが様々なチームに散らばって仕事をするような事例が増えていくと思います。このあたりは、先日デブサミでも話しました。
そういった働き方をするエンジニアはまだまだ珍しく、職種としても曖昧でキャリアパスも謎です。とはいえ増やしていかないと楽しい職場も増えないのではないかと危機感も持っており、まずはCustomer系エンジニアから集まって情報発信してみようかなと思っている今日この頃です。
ここから先は
仕事を楽しくするデジタルリテラシー読本
【初月無料】デジタル時代の歩き方について考えたことを発信します。ソフトウェアの時代とは何か。エンジニアの頭の中はどうなっているのか。NoC…
サポートをいただけると、喜びドリブンで発信量が増えます！初月無料のマガジン『仕事を楽しくするデジタルリテラシー読本』もおすすめです！