2023年ー2024年にかけて、ITベンチャー企業でCustomer Reliablity Engineer (CRE)として働きました。同時に、Engineering Managerとして、CREチームのマネジメントを担当しました。
1年間の経験をもとに、CREとは何か、を言語化してみます。
(個人の見解なので、「これが絶対」と言うものではありません)
CREの定義
CREは、もともとGoogleが2016年に提唱した職種です。
では、CREとは何か、CREのミッションは何か。上のブログ記事では、以下のように説明があります。
「CRE チームは、お客様の基幹アプリケーションにおける主要な要素を、コードからデザイン、実装、運用手順に至るまで綿密に調査します。そこで見つけたものを取り出し、アプリケーション（および関連チーム）に対して厳しく PRR を実施します。」
うむ、ちょっとわかりづらいですね。
GoogleのCREは、Google Cloudを利用してサービス・アプリケーション開発を行う会社のためのロールです。プラットフォームを利用するエンプラユーザー向けの、プラットフォーマーが提供するCREです。
このため、一般的な事業会社の立場でCREを定義しようとすると、微妙に差異が生じます。
(プラットフォーマーとその利用者では、立ち位置も、業務内容も異なるため当然ですね)
そこで、CREについて言及する記事を他にも読み込み、自分の業務経験も踏まえた上で、以下のように定義してみました。
「CREとは、ステークホルダーの課題・悩み・不安事項を理解し、技術的なアプローチで解決方法を提示する職種」
ーーーーーーーーーーーー
ここでいうステークホルダーは、社外の顧客・クライアントに限らず、社内だったり、代理店だったり、ビジネス活動を行う上で関連がある対象者全般を指します。
社内外の関係者は、必ずしも技術に詳しい方ばかりではありません。
あるサービスを導入することでどんなリスクが生じるのか、どのような条件を整えれば導入がうまくいくかなど、正しい技術的な根拠のもと、わかりやすく説明する必要があります。
そんな社内外のステークホルダーに対して、自らが持つ技術のバックグランドをもとに、支援していくのがCREと言えそうです。
参考までに、さまざまな企業のCREチームについて書かれた記事・資料をご紹介します。
- CREチーム始めました - Mercari Engineering Blog
- よく分かるCRE入門
- CREという組織を作りました｜Repro CS Blog｜note
- CREがカスタマーサクセスに必要な理由｜Repro CS Blog｜note
- Kyashの現状の課題とCRE募集ページの解説 - Kyash Blog
- なれる！CRE
- freeeのCREチームとは
CREの業務領域
CREが担当する業務領域は、企業によって、微妙に異なります。テクニカルサポートチームのことを「CRE」と呼ぶケースもあれば、プリセールスを「CRE」と呼ぶケースもあります。
自分は「ステークホルダーの課題を技術的なアプローチで解決する職種」であれば、広義の意味でCREという言葉を使って良いのではないか、と考えました。
具体的に説明します。
CREと呼ばれる業務領域は、大きく分けて4パターンあります。
1. サービス導入前・実装前(プリセールス)
サービスの導入を決断するまでの不安・疑問・確認すべき事項を、技術的な観点から提案やアドバイスを行う業務が中心となります。いわゆるプリセールス、セールスエンジニアリング、ソリューションアーキテクトと呼ばれることが多い領域です。
サービス仕様の詳細な説明や制限事項、実際に利用する際のベストプラクティス、実装例の提示(プロトタイプ開発)などをステークホルダーに対して行います。
ここでのステークホルダーは、営業・マーケティング・開発部門などの社内関係者、および実際に導入を検討しているクライアント、導入支援を行う代理店やSierなどが対象となります。
2. サービス導入後(ポストセールス)
サービスの利用開始後、技術的な問題点・疑問点が顕現したときに、技術的な観点からサポートや問題解決を行う業務が中心となります。テクニカルサポート、テクニカルアカウント(TAM)と呼ばれることが多い領域です。
ステークホルダーの要請に応じて、問題の原因調査・切り分け・解決のための方法提示 (サンプルコードの作成や構成例の紹介など) をステークホルダーに対して行います。
ここでいうステークホルダーは、すでに導入済みのクライアント、クライアントを担当する営業・サポート担当者、導入後のサポートを行なっている代理店やSierなどが対象となります。
3. サービスの応用的な活用、情報交換 (DevRel、コミュニティマネジメント)
サービスのさらに効果的、応用的な利用方法を求めるステークホルダーに対して、支援をする業務が中心となります。いわゆるDevRel、コミュニティマネジメントと呼ばれることが多い領域です。
仕様に留まらない活用方法や情報交換が中心となるため、正規の営業・サポートとは異なるレイヤーでステークホルダーの支援を行います。コミュニティマーケティングと結びつき、コミュニティを通じたリーチ獲得・既存のクライアントのリテンションを支援するケースが多いため、営業・マーケティング部門の人間と連動して動くことが多い職種でもあります。
4. サービスに対する改善点のフィードバック
1-3の活動を通じて、サービスをよりよく改善する、もしくは問題点を修正するためのフィードバックを行う領域です。
フィードバックについては単体で存在する業務というよりも、1−３の業務を通じて顕現した改善点や問題点を整理し、開発チームに橋渡しします。1−3の業務に付随するサブタスクとして動く場合が多いです。
補足
ここでは、CREのアクティビティを4つのパターンに分類しましたが、プリセールスやテクニカルサポート＝CREの一部、という意図ではありません。
「プリセールスをCREと呼んでいる場合もあるし、呼んでいない場合もある。」
といった程度の、緩い関係性で捉えていただければ幸いです。
CREの業務内容の実際
CREの実際の業務内容について、自分の業務をもとに記述してみます。
自分が担当したCREは、主にアドテクのプリセールス領域とポストセールス領域でした。
具体的にいうとこんな感じです。
プリセールス領域のCRE
- サービス導入時の問題がないか、調査・PoCを行う
- 実際にコードを作成し、テスト環境で確認後、実環境に導入を行う
- クライアントの環境を把握し、導入に必要な技術要件を整理した上で、関係者に説明・理解してもらう
ポストセールス領域のCRE
- サービスを導入したユーザーに安心して使い続けてもらうためのテクニカルサポート
- クライアントの利用状況の調査、問題発生時の調査と切り分け、解決方法の提示
技術スタック（アドテク関連）
- JavaScript、TypeScript, Python, + α
- (アドテク技術のライブラリは、JSで書かれている場合が多い)
- Node環境
- (ライブラリ開発環境、およびChromiumやPuppeteerなどを利用した作業や各種調査など)
- 基本的なネットワーク知識
- (Request Header, Response Headerの解析、ブラウザの検証ツールを利用した動作確認、DNSや証明書の調査など)
- Google Analytics や Google Ad Manager など、Googleサービスの知識
- (アドテクの世界ではGoogleが圧倒的な力を持つため)
- オープンソースライブラリの実装・改修など
- (ライセンスの理解、プラグインのカスタマイズや組み込みなど。OSSは頻繁に仕様が更新されるため、リリースノートの輪読会を定期的に開催した。英語力必須)
- クラウド基盤の知識と実際の操作
- (CDNやストレージサービスをヘビー使うため、CDN周りの理解は必須項目)
- そのほか、ウェブ技術・ネットワーク技術の雑多なスキル
少し雰囲気が伝わったでしょうか。
プリセールス、ポストセールスを同時に行うチームだったため、CREについての解像度が、ぐっと上がった感覚がありました。
CREの業務開始時の整理
上記で整理したとおり、CREの定義は企業や事業領域によってまちまちです。事前にCREのミッションを整理しないと、混乱が起こるかもしれません。
これからCREチームを立ち上げる、もしくはCREチームと関係者の期待値を擦り合わせるためには、例えば以下のようにマトリクスを利用して、「うちの会社のCREチームはどこを担当するのか」を整理すると良いと思います。
CREが担当する業務領域を明文化・社内周知することで、業務の行き違いをなくし、ロスを軽減することができることでしょう。