※この記事はプレイド公式note『PLAID’s Engineer』に掲載した記事を転載しています。

プロダクトと顧客との間に立ち、プロダクト価値の最大化に取り組む役割の重要度が上がっています。

プレイドでは、これまで「Product Specialist」として活動してきた役割を「Customer Engineer」として再定義し、チームを立ち上げようとしています。

Customer Engineerという従来と異なるエンジニアのあり方や可能性について、プレイドでその役割を担っている池上に語ってもらいました。

池上 純平
1990年生まれ。東京大学経済学部卒業後、富士通株式会社を経て2016年11月より株式会社プレイドにジョイン。開発、テクニカルサポート、データ分析など幅広い役割を担う。YouTuber。Twitterアカウントは @jumpei_ikegami 。

※本記事は「Developers Summit 2021 Summer」での池上の登壇内容にも触れつつお届けしています。

DXの本質と、「開発しないエンジニア」のキャリアパス

※「Developers Summit 2021 Summer」では「Product Specialist」と定義していた役割を改めて見直し、「Customer Engineer」として再定義しています。

この記事を読んでほしい人
・エンジニアが担う役割の変化について知りたい方
・専門性を追求することだけがエンジニアのキャリアパスなのか、納得感がない方

プロダクトと顧客との間に立ち、プロダクト価値の最大化に取り組むCustomer Engineerとは？

──Customer Engineerとはどのような役割なのでしょうか？

池上：
Customer Engineerとは、「プロダクトと顧客との間に立ち、プロダクトの価値を最大化するエンジニア」のことです。もともと、Customer Engineerは、主にコンピュータのハードウェアの設置、保守点検や修理などを行う職種を指して呼ばれていました。

近年、様々なソフトウェアが登場し、SaaSのように複雑な業務に対応するためのプロダクトも増加しています。プロダクトがどれだけ良かったとしても、適切に使ってもらえなければ価値は半減します。

Customer Engineerの主な役割は、プロダクトそのもののコードを書くことではありません。エンジニアの目線で顧客にプロダクトのよりよい使い方を伝えたり、現場で発見された課題をプロダクトにフィードバックする役割を担います。

（※上記スライドを使用したイベント登壇時はProduct Specialistとしていましたが、今は役割を再定義し、Customer Engineerと呼んでいます。以降、登場するスライドのProduct Specialistという記載は、Customer Engineerとして読み替えていただけたらと思います）

──プロダクト開発のためのコードを書かないとなると、Customer Engineerはどのような業務になるのでしょうか。

池上：
例えば、プレイドのCustomer Engineerの業務は以下のようなものが挙げられます。

・プロダクト仕様をわかりやすいドキュメントにまとめる
・技術的な問い合わせに対して、調査、回答、バグや機能要望の取りまとめをする
・カスタマーが実現したい施策について設計や実装の支援をする
・プロダクト上及び周辺で動くアプリケーションの開発
・システム障害発生時には、対応状況の取りまとめやStatusページの更新をする
・プロダクトの価値や最適な使い方について、顧客に直接説明する
・上記の業務がうまく回るような仕組みを考え、改善する

このようにプロダクトを顧客に使ってもらうために必要なことをなんでもやる、ジェネラリストのような存在です。

──業務内容はかなり多岐にわたりますね。顧客に向き合う姿勢などはカスタマーサクセスなど、既存の職種とも近い印象です。

池上：
プロダクトと顧客との間に立ってプロダクトの価値を最大化するという目的に向かっているという点では、カスタマーサクセスやカスタマーサポートにも近いですね。

これらの職種との違いは、顧客やプロダクトとの距離感です。カスタマーサクセス等とチームを分けているのは、誰がどこにオーナーシップを持つのかをわかりやすくして動きやすい状態を実現したいという意図もあります。

組織の規模が大きくなると、カスタマーサクセスとエンジニアの人数も増え、役割分担が進んだ結果、相談のハードルが上がってしまうことは珍しくありません。

「誰に相談したらいいのかわからない」で悩む時間がもったいないので、事業の速度を上げるためにもこの役割は大切だと考えています。

日本の組織は業務のアジリティを高めなければならない

──Customer Engineerが必要だという考えには、どのような背景が？

池上：
これまではSNS、スマートフォン、ECプラットフォームなどのBtoCプロダクトが広がって社会が前進していく感覚がありました。その流れが一巡して、停滞期にあるように感じられます。

個人的には、BtoB SaaSには今の停滞を突破する可能性があると思っています。ただ、次々とBtoB SaaSのプロダクトが生まれてくるだけでは、生じる変化は限定的です。この点がこれまでのインターネットサービスがもたらした変化との違いです。

【対談】エンジニアが考えるBtoB SaaSの魅力とは（前編）

BtoB SaaSが大きな変化を創り出すには、デジタル以外の領域で強みを築き上げてきた企業と一緒になって取り組んでいく必要があると考えています。DXと呼ばれるような領域ですね。ここでのDXは「既存企業がデジタルネイティブな組織に変わること」という意味で使っています。

「DX」という言葉を使うと、エンジニアは拒否感があるかもしれません。ただ、スタートアップだけで起こせる変化はどうしても限定されます。社会をよりよく変えていこうとするなら、既存企業と共に取り組むことは欠かせないと考えています。

──社会を前進させうるBtoB SaaSのポテンシャルを信じている一方、それを発揮するには既存企業の変革が必要になる。では、DXはどうすれば進んでいくのでしょうか。

池上：
DXとは、既存企業がデジタルネイティブな組織に変わることなので、単にテクノロジーを導入するだけでは不十分なんですよね。企業が仕事の仕方をデジタル前提に変えることで様々な業務のアジリティを上げ、その結果として破壊的なプロダクトを生み出す側に変容します。

業務のアジリティをどう上げるかについて、僕はDevOpsという開発業務のアジリティを高めたムーブメントにヒントがあると考えています。DevOpsのきっかけとなったのは、IaaS（クラウドインフラ）の登場です。

IaaSは、インフラを気にせずに新しい機能を追加したいDevと、システムを安定稼働させたいOpsの対立を解消しました。IaaSの登場以降、Devだけでインフラ構築が完結可能になり、開発業務のアジリティが向上しています。

──DevOpsのムーブメントを生み出したIaaSと同様の役割をSaaSが担うということでしょうか。

池上：
そうです。DevOpsは、エンジニアが主導する開発業務のオペレーション改善です。IaaSのおかげでエンジニアだけでインフラ構築まで完結できるケースが増え、開発業務のアジリティが向上しました。

SaaSの登場により、非エンジニアでもシステム構築が可能になっています。例えば、労務部門だけでSmartHRを導入したり、CS部門だけでチャットボットを導入したり。業務部門が直接システムを扱えるようになり、業務のアジリティが上がっていくと考えられます。

こうした環境下では、エンジニアの役割も変化していきます。個別にオンプレ業務システムをカスタマイズしていたSIerの仕事は減り、社内で情報システムを担っていた部門はSaaSによる業務オペレーションの改善を支援するような役割を担うのではないでしょうか。

システムを複雑な現実世界に合わせてカスタマイズするためにエンジニアが必要

──つまり、SaaSを導入すれば業務のアジリティは上がっていく？

池上：
それができたらいいのですが、現状はいくつか課題があります。

たしかに、SaaSとAPIの組み合わせにより、様々なシステムの構築が可能になりました。SalesforceやKARTEなどのプロダクトの上で何かを作ることも一般的になりつつあり、エンジニアと非エンジニアの境界は曖昧になってきています。

ただ、「ノーコードで誰でも簡単に使える」といっても、誰でも価値あるシステムがつくれるかというとそうではないと考えています。私もKARTEの提供を通じて実感したのですが、SaaSとユーザーの間には以下の2つのギャップがあると考えています。

1. エンジニアリングスキル
2. 業務知識

他にも、非機能要件や技術的負債などの観点もあり、なかなか非エンジニアだけで対応するのは難しいのが現状です。このあたりについての詳細は以前「ノーコードという幻想」というタイトルで個人のnoteにもまとめています。

まとめると、複雑な現実世界に合わせてシステムをカスタマイズするのは難しく、SaaSを導入して業務のアジリティを高める上でエンジニアの支援は必要。ただ、より現場に近いレイヤーで開発するエンジニアの数は不足しているという課題があります。

──エンジニアは、プログラミング言語の開発などの低レイヤーの開発に惹かれる傾向があるようにも思います。

池上：
それも、現時点での高レイヤーで開発に携わるエンジニアの数が足りない要因かもしれません。ただ、状況は少しずつ変化していくと思います。「AWSエンジニア」のような特定のクラウドサービスに詳しいエンジニアも、登場した当初はなかなか評価されていませんでした。

AWS自体が市民権を得て、AWSに強いエンジニアも転職市場で価値が高まっていきました。同様に、この先Salesforceのような汎用的で、標準的なSaaSが市民権を得ていくなかで、その上で開発を担うエンジニアの価値は高まっていくと思います。

より広範な人を巻き込む、ソフトウェア開発の次の段階へ

──業務のアジリティが高まっていくために、現場に近いレイヤーで活動するエンジニア、Customer Engineerの必要性がわかりました。どんな人であれば、Customer Engineerの仕事に合うのでしょうか。

池上：
技術力のあるエンジニアであれば、Customer Engineerとして活躍できるかというと、そうではありません。現場には正解があるわけではないため、何を良しとするかは業務上、事業上の判断が随時必要になります。

そのため、Customer Engineerは非エンジニアのチームメンバーとも連携しながら業務を進めていきます。人を巻き込むためには説明が必要不可欠。技術的に自分で実装ができるだけでなく、人々がやりたいこと（≒現実）を理解してシステムに翻訳する役割ですね。

──Customer Engineerは人とデジタルを翻訳してつなぐ役割なんですね。

池上：
エンジニアだけでシステムを開発する時代は終わりました。正解はないため、開発に巻き込む対象を広げてアジリティを高めていかないと、良いモノを作れなくなってきています。

Customer Engineerとは、顧客や非エンジニアのメンバーをもエンジニアリングの対象として捉え、システムに組み込む役割とも言えるかもしれません。

プレイドでも、まさにCustomer Engineerのチームを立ち上げて、職種の可能性を探索していこうとしています。先程もお話したとおり、担い手が少ない状態なので共に挑戦する人はいつでもお待ちしています！

記事を読んで興味をお持ちいただいた方、まずは話を聞いてみたいという方はぜひカジュアル面談でお話ししましょう！

Meetyでカジュアル面談を申し込む

PLAID 採用情報資料