🐶

自社でCREを始めた経緯と今後の方向性

smmr

2024/02/22に公開

はじめに

こんにちは
レバテックでCREを進めている住村です。
自社でCRE（顧客信頼性エンジニアリング）を始めたので、その背景や経緯と、今後やろうとしてることをつらつらとまとめます。

自分用の「あの時何考えてたっけ？」を振り返るための記載と、CRE推進を検討している似た状況の人に向けて参考になれば幸いです。

CRE（顧客信頼性エンジニアリング）って？

GoogleがSREの概念を顧客に適用し、サービスの信頼性を向上させるために提唱した概念です。

下記の流れで、GCP導入を促進するための取り組みとして誕生しました。

GoogleはオンプレからGCPに乗り換えてほしい
でも顧客は「いざという時のためにインフラは自社管理したい」ので中々乗り換えてくれない
GoogleがGCP上で動かすアプリのレビューや運用体制を整理
「これだけ自社のアプリ分かってくれるなら」と信頼関係を構築してGCP導入のハードルを下げる

正直、この取り組み自体はそのまま真似できるものではないですが、自分は「サービス利用に付随して発生する不安をエンジニアリングで解消する」ものと解釈しています。
これでも抽象度が高いですが、今後業界内でノウハウが溜まっていけば体系化が進むんじゃないかと期待しています。

レバテックでCREを進めることになった経緯

レバテックは若い会社で、事業の成長に伴いシステムも組織も急拡大が進んでいます。
その拡大に合わせて効率化すべく、システムも組織も細分化を進めて業務スコープを絞ることで専門性を高める動きが進みました。
細分化されて組織の専門性が高まることで、業務効率は改善され人も増やしやすくなりましたが、それは同時にシステムと組織の複雑性の増加に繋がりました。

それにより、下記の問題点が出てきます。

細分化によりチーム数が増え、チーム間のコミュニケーションパスの増加
専門化により業務が複雑化し、システム化の難易度の増加
急拡大に合わせたツギハギ改修により、システムに技術負債が積み重なる

恐らくここまでの流れ自体は急成長してきた事業会社では良くある話ではないかと思います。
レバテックでも、このまま行けば事業戦略にプロダクトの変化が追いつかず、事業成長のボトルネックになるリスクが高いため、システムの作り直しを進めようとしています。

が、システムの技術負債を抜きにしても前述の通り「そもそもシステム化対象の複雑性が上がりやすい」状態のため、作り直しのハードルも高いですし、その後に同じ問題が発生するリスクも高いです。

また、レバテックは人材紹介のエージェントというサービスの性質上、システム化対象にはエージェントの業務が大きく関わるのでエージェントの業務理解が重要です。
前述の通りコミュニケーションパスの増加と、専門化により業務が複雑化しているので業務理解のハードルも上がっています。
例えばエージェントからの開発要望が出たとして、その開発要望の効果見積もりの妥当性や、実際対応した後にどの程度効果があったかを測ることも困難です。

この状況に対して「システム化対象の複雑性を下げる」ため、レバテックでもCREを進めようとしています。

この辺りは社内発表用に作成した下記のスライドでも触れているので、詳細を知りたい方は見てみてください。

自社での取り組み

これまでにやったこと

CREの責務を定義

まず、自社のCREが何をするかを明確化するため、ミッション・ビジョン・ゴールを定義しました

ミッション

開発者が社内顧客（営業）の業務実態を把握し、利用する社内システムへ反映するための仕組みをエンジニアリングにより構築する。

ビジョン

レバテックのエージェント事業では、顧客に提供するサービス価値が社内顧客のオペレーショナルエクセレンスに依存している。
社内顧客の業務実態を開発者が把握し、オペレーショナルエクセレンスをシステムへ反映させることでサービス価値を向上させる。

ゴール

中〜長期

社内業務の指標が計測され、計画的に改善が進められる
- 社内の業務が可視化され、要望ベースの受動的な対応だけでなく能動的な問題解決に動ける
- 開発した機能が社内業務に与えた影響が分かり、効果測定や振り返りに利用できる
社内顧客の業務課題を開発で把握できる仕組み/体制が整備されている
- 社内の関係者間で適切に情報交換できる組織体制の整備

短期

社内顧客の業務実態の解像度を上げ、ナレッジ化を進める
- 社内顧客の課題を吸い上げる仕組み構築のため、既存業務の解像度を上げてナレッジ化する
- 蓄積したナレッジを元に、どういった仕組みを構築すれば良いかの検討を進める
社内でのコミュニケーションを円滑にするため、事業組織の可視化と言語化
- 各チームの担当領域と責務を明確化し、コミュニケーションコストを低下させる土台を作る
  - 業務で聞きたい/相談したい時にどのチームに連絡取れば良いかが簡単に分かる状態

やらないこと

具体の課題解決はやらない。
直接顧客体験を改善するのではなく、各開発チームが顧客体験の改善に必要な仕組みを作るのが主軸。
計測や分析できる仕組みは入れても、その結果上がった課題などに対するオーナーシップは開発チームが持つ。

事業全体のリーダー層への共有、共通認識の醸成

前述の責務上、開発に完結する取り組みではなくエージェントやマーケターも巻き込んだ活動になります。
そのため、事業全体で共通認識を取るためにこれまでのシステムや営業組織の歴史的経緯とそれにより発生している問題を整理した資料を作成し、リーダー層以上を対象にした研修を実施しました。

現在やっていること

業務実態の情報収集のため、内製しているSFAシステムの業務改善に取り組んでいます。
具体的には、現在内製しているSFAのシステム化対象となる業務領域の広さに対して開発チームの人員が不足しています。
それにより、開発チームに業務知識の知見が溜まりにくく開発効率が上がりにくい問題があります。

現状は下図のように、一見するとタスクの実施効果順に対応できているので効率が良いように見えます。
しかし、実際には対応する業務範囲が広いのでタスク間の業務の関連性が薄く、都度キャッチアップが必要なので対応工数にオーバーヘッドがかかります。

AsIs
現在の開発チームの担当範囲と、作業順のイメージ

この問題を改善するため、下図のように期間ごとに開発対象の業務領域を絞ることでタスク間の業務の関連性を上げ、業務解像度が高い状態で開発することで開発効率を改善できないか試そうとしています。

ToBe
試そうとしている体制のイメージ

具体的な進め方やリスクなどの詳細をこの記事で説明するとボリュームが大きいので、それらは別途記事を書こうと思います。

これからやろうとしていること

次の取り組みとして、下記の2点を進めようとしています

社内の担当領域と責務の明確化
- 現状だとチーム数が多く担当領域が不透明なため、コミュニケーションのコストが高い
  - 都度、情報を知ってる人を経由して繋いでもらう必要がある
- コミュニケーションコストを軽減するため、担当領域と責務を定義した資料を作成する
- 継続したメンテナンスができるかが懸念
  - こういった資料は陳腐化しやすいため。
社内の業務プロセスの可視化と、作業工数が計測できる体制の構築

自社でのCRE活動での悩み

社内メンバーの行動データをどう取るか

現状はシステム化が追いついておらず、システム外でアナログ運用されている業務が多く存在します。
そういった業務のデータが取りづらく改善効果を測るのが難しいため、システム化が追いついてない領域の改善効果をどう測るかがネックになっています。
この問題には全く解を得られていないので、今後も引き続き課題として向き合っていかなければなりません。

何でも屋になりやすい

既存組織の構造的にどのチームの管轄にもならない浮き球的な問題が出た際、CREの活動は抽象度が高く、浮き球を拾いやすいポジションです。
その影響で「とりあえず今動きやすいポジション」として何でも屋になりかねません。
SREを進めようと思ったらインフラ屋になっているのと似たイメージですね。

これが常態化してしまうと、浮いた問題の対応に追われてCRE活動が進められない状態になりかねません。
実際、現在でも浮いた問題に取り組むことが多いので、CREとしての活動を進めるために浮き球への対処を組織的にどうするかの対策が必要になっています。

個人的な感想

個人的に、CREは主にアウトカムを上げるための取り組みだと解釈しています。
そして、今後はCREに限らず、アウトカムを上げるための取り組みへの注目度が加速すると思います。
何故かというと、近年の開発現場では市場の変化速度に対応するためにアジャイルが広まり「開発サイクルを高速化してアウトプット速度を上げるノウハウ」が業界全体で一般化してきています。
その結果、サービス品質向上のための次のアプローチとして「アウトカムを上げるノウハウ」の重要性が高まってきているのではないかと思います。
そして「アウトカムを上げるノウハウ」はまだ一般化されていない領域なので、今後はCREや他のアウトカム向上に繋がる手法のトライ＆エラーが各社で進み、記事なども多く出てくるんじゃないかと思います。

なので、今後もCREやその他のアウトカムを向上する取り組みに対しては注目していきたいですね。

レバテック開発部

レバテック開発部の公式テックブログです！