ログラスでCREを立ち上げた背景とこれから
株式会社ログラス エンジニアの山﨑（@zaki___yama）です。 ログラスではフロントエンドエンジニアとしてプロダクト開発を担当する傍ら、CRE（Customer Reliability Engineer）というロールも兼務しており、業務時間のうち一定割合をこの CRE としての活動に充てています。 本日はこの CRE というロールを立ち上げた経緯と、立ち上げにあたり具体的にどんなことをやってきたのか、そして今後取り組みたいことを紹介します。 ログラスにおいてカスタマーサクセスは非常に重要な要素です。 ログラスが扱う「経営管理」という領域は非常に複雑なドメイン知識が求められます。弊社のカスタマーサクセス（CS）チームには、元々お客様と同じ経営企画業務を経験していた者も多く、単なるプロダクトの使い方にとどまらずお客様の業務に踏み込んだ支援を可能にしています。経営企画という、企業活動の根幹に関わる部分で CS チームがお客様と伴走できるというのは、ログラスの強みの 1 つとなっています。 一方、お客様に対するフロントとしては CS チームがいますが、その CS チームとプロダクトチームをつなぐ部分に関しては、まだまだ体系化できておりませんでした。具体的には、CS チームが日々お客様からいただいた声をプロダクトチームにどのように届けるか、CS チームが真にお客様と向き合えるためにプロダクトチームとしてはどういったサポートが必要なのか、といったことです。またそのつなぎ込みとして、プロダクトチームと CS チームをつなぐ専門のロールが必要なのでは、と模索しておりました。 そんな折、国内外で CRE（Customer Reliability Engineer）という職種について言及されている事例記事を見かけるようになりました。 ログラスにおいても、このような顧客に軸足を置いたエンジニアというロールが必要なのではと考え、ロールの立ち上げに至りました。 （以下、「お客様」を「顧客」という表現で統一します） CRE というロールを新たに立ち上げるにあたり、まず行ったのが責務の言語化です。 そのためにはまず CRE というロールに対する理解を深める必要があり、国内外の事例を参考にしました。 まずはじめに読んだのは、CRE を最初に提唱した Google による記事です。 この記事から、従来の SRE という職で培われたプラクティスを顧客に適用したものが CRE であること、CRE とは「お客様の不安をゼロにする」ことが究極的なミッションであること、などを学びました。 しかしながら、職務が具体的にイメージできない箇所もありました。たとえば、以下のような記述です。 CRE チームは、お客様の基幹アプリケーションにおける主要な要素を、コードからデザイン、実装、運用手順に至るまで綿密に調査します。そこで見つけたものを取り出し、アプリケーション（および関連チーム）に対して厳しく PRR を実施します。 （PRR とは "Production Readiness Review" の略で、Google 社内における検査プロセスを指すそうです） これをログラスにそのまま適用できるイメージがわかない理由として、Google にとっての顧客 = Google のプラットフォームを利用してアプリケーション開発を行う開発者 であり、Google と顧客の間で技術的な話ができる、Google は顧客のコードを見れるという前提になっており、上記のような表現になるのだと解釈しました。 ログラスが提供するのは経営企画の方向けの SaaS であり、Google のようなプラットフォームとは特性が異なるため、ここについては自社にあった形で責務を定義する必要があると感じました。 その後、他社の事例記事なども参考にしつつ、以下のようなキーワードが重要であると考えました。 顧客の不安をゼロにするためにエンジニアリングで貢献する、というのが大まかなミッション プロセス全体に責任は持つが、具体的な仕事として何をどこまで担当するかは各社それぞれ リアクティブ（受動的）とプロアクティブ（能動的） 問い合わせ対応、要望対応などは前者 顧客が直接声を上げなくても、顧客の不安を減らすためのアクションをこちらから能動的に起こせる、のが後者 データドリブン：プロアクティブなアクションのためのデータ収集と分析 これらを踏まえ、ログラスにおける CRE の責務を以下のように定めました。 （社内の notion ページをそのまま添付しています） ログラス社内の「CREの責務」ドキュメントの一部 同時に、現時点で CRE ...
