先日、2026/1/21(水) に開催された CRE Camp #4 で「なぜCREを8年間続けているのか」というタイトルで登壇しました。
登壇は10分だったのですが、スライドに載せていないことも、手元ではいろいろと考えていたので、改めて最近考えたこと全編をブログにまとめたいと思います。
私がこのテーマで話したいと思った理由は単純で、「CREのキャリアって長く続けられる仕事なの？」という不安が、コミュニティの空気として少なからず漂っていると感じていたからです。また、チームメンバーとの会話でも、採用面接でも、同じ匂いの問いに何度か出会ったことがあります。自分自身も、8年という時間が経って初めて「続けられた理由」を言語化できる状態になりました。だからこそ、今の時点の整理を共有して、次に続く人の足場になればと思っています。
自己紹介と、はてなMackerelにおけるCREの出発点
私は株式会社はてなで、オブザーバビリティツール Mackerel のCREチームでディレクターをしています。2018年3月にジョインして、同じプロダクトに向き合い続けてきました。1つのプロダクトで約8年が過ぎようとしている、というのは自分でも感慨深いですし、コミュニティの中でもなかなかレアな存在になってきたのではないかということも感じます。
はてなでCREという職種ができたのは2017年です。当時はてなに所属しておられた 
id:a-know さんが立ち上げたものです。
当時は他社事例も今ほど多くはなく、ようやくコミュニティイベントが生まれ始めた頃でした。入社直後に参加したイベント「JustTechTalk#11 エンジニアの新しいキャリア Customer Reliability Engineer (CRE)」の id:a-know さんの登壇で引用されていたもので印象に残っている言葉があります。
（a-knowさんの登壇資料より）
この2行が、当時の自分にはやけに刺さりました。サポートや運用という文脈はどうしても「減点を取り返す」話になりがちです。障害を減らす、問い合わせを減らす、炎上を避けるなど。もちろんそれは重要ですが、「プロフィットセンター」という言葉は、信頼を扱う仕事が“価値を生み出す側”にもなり得るのだ、と視界を開いてくれました。
ここから8年経った今、Mackerelの中でCREはどういう存在になっているのか。この記事の終盤で、私なりの“答え合わせ”を書きます。
みんなが感じるCREキャリアの不安を、まず言葉にする
私がよく聞く不安は、大きく2つに集約できます。
1つ目は、専門性が捉えにくい不安です。
「CREって、結局何ができる人なの？」「市場価値は上がるの？」という問い。SREのように体系や役割の輪郭が比較的共有されている領域に比べると、CREは会社ごとの差分が大きい。スキルが積み上がっている実感が得にくい、と感じる人も多いと思います。
2つ目は、「狭間」の仕事が多い不安です。
開発・サポート・CS・営業…境界に立つからこそ、いろんなボールが飛んでくる。割り込みも多い。気づくと、誰かの“やり残し”の後始末をしている感覚になることがある。これを何年も続けて、やりがいを保てるのか、という問いです。
この2つは根っこで繋がっています。狭間に立つほど仕事は増えるのに、狭間の仕事は定義しづらい。定義しづらいから評価もしづらい。評価しづらいから、専門性としての実感が弱くなる。だから不安になる。私は、これを「気のせい」ではなく、構造上起こりやすい問題だと思っています。
事業成長とCRE：なぜ“途中から”必要になるのか
ここで、LayerX tanisukeさんの記事「CREを5年続けても、まだ『CREとは何か』悩んでいた話」に強く共感した話をしておきます。この記事で特に印象深かったのは、CREを責務やタスクではなく、スタンスや佇まいとして語っている点です。そして、事業成長の中で“構造的に”信頼が毀損され得るからこそ、それを継続的に担保する装置として専任CRE組織が必要になる、という説明でした。
私はこの整理がとても大事だと思っています。なぜなら、CREは事業の初期から常に必要というより、事業が育ち、プロダクトが成熟し、顧客が拡大・多様化していく中で「必要性が顕在化する」性質を持つからです。
登壇でもお話しした、Mackerelの例を参考に見てみます。初期は、少人数で顧客の声も近い。開発チームが直接サポートし、営業も事業責任者やPMが兼任し、意思決定も速い。多少の歪みがあっても、気合と近さで吸収できる。ところが成長すると、分業が進み、境界が生まれます。
- 開発とサポートが分かれる
- 開発と営業が分かれる
- プロダクトと顧客の距離が少しずつ離れる
- 顧客の多様性が増えて、全員の前提が揃わなくなる
- 技術的・運用的・契約的な複雑性が増える
この状態で起こるのが、いわゆる「狭間の問題」です。典型例を挙げると、こういったものです。
- 営業が伝えた「できる」が、実際は前提条件つき・制約つきで、顧客が落胆する
- 開発としては仕様だが、顧客は「不具合だ」と感じる
- 営業は大口顧客の要望を叶えたいが、開発は全体最適のために時期と優先度を検討したい
- リリースされるがドキュメントが間に合わずサポート負荷が高まる
- 機能はあるのに知られておらず、顧客が価値に到達できない
ここで重要なのは、「誰かがサボっているから起きる問題」ではないことです。全員が自分の職務を全うしているのに、構造として信頼が削れていく。結果として、顧客は静かに諦め、非アクティブ化し、あるいは離脱します。私がCREを続けている理由の中心には、「この静かな毀損を、設計の問題として扱いたい」という気持ちがあります。
「信頼」を再定義する：Reliabilityだけでは足りない
CREという言葉にはReliabilityが入っています。ソフトウェア開発の文脈でReliability（信頼性）と言えば、一般的には「要求された機能を、一定の条件下で、一定期間にわたり継続的に提供できる能力」といった定義に寄ります。可用性、障害頻度、性能、耐障害性…このあたりが主戦場です。
でも、CREコミュニティで語られている「信頼」には、それだけでは収まらない何かが混ざっていると感じます。顧客はサービスを使うとき、可用性や性能だけで「信頼していいか」を判断しているわけではありません。
- できること / できないことを、正直に伝えてくれるか
- 困ったとき、素早く誠実に助けてくれるか
- 仕様変更があっても、説明があり、予測できるか
- データや権限の扱いに責任があり、透明性があるか
- そのサービスを作っているチームを、頼ってよいと思えるか
こうしたもの全部が、顧客の意思決定の中では「信頼」の一部になっています。ここを扱うのがCREだとすると、Reliability（システムの信頼性）だけを物差しにするのは足りない。そこで私は、組織におけるTrust（信頼）を整理した研究を借りて考えるのが便利だと思いました。
Trustモデル（3軸）＋Reliability（1軸）で、4つの信頼を扱う
Mayer, Davis, Schoorman（1995）は、組織関係における信頼を整理して、信頼の成立に関わる要素を3つにまとめています。
- Ability（能力）：特定の領域で影響力を持てるだけの技能・知識・経験・判断力など。
- Benevolence（善意）：自己利益のためだけでなく、信頼する側（trustor）にとって「良いことをしよう」とする志向があると信じられる程度。
- Integrity（誠実さ）：信頼する側が受け入れられると感じる原理・価値観に従い、言行が整合していると知覚される程度。
これを顧客と企業 / プロダクトの文脈に翻訳し、さらにソフトウェア文脈のReliabilityを足すと、私は次の4軸で捉えるのがしっくりきます。
Ability（能力）：サービスの領域について、提供者が十分な知識・スキル・経験を持ち、顧客にその体験を高い価値で継続的に届けられる。
Benevolence（善意）：提供者が自分たちの利益だけでなく、対価に見合う（あるいは超えるほどの）顧客の成功・利益が得られるように振る舞う。
Integrity（誠実さ）：仕様・契約・サポート範囲などの約束ごとを守る。データの取り扱い、権限設計、脆弱性対応などセキュリティに責任を持つ。加えて透明性を保ち、問題が起きたときに誠実に対応する。
Reliability（一貫性・予測可能性）：可用性や性能が安定している。機能や挙動に一貫性がある。変更の影響を予測できる。
この4軸のいいところは、狭間の問題が「どの信頼を削っているのか」に分解できる点です。たとえば、営業が誤解を招く説明をしてしまう問題は、顧客から見ればIntegrityやBenevolenceの毀損として表れます。ドキュメント不足で価値到達が遅れる問題は、Abilityに響きます。仕様変更の説明不足は、ReliabilityやIntegrityの毀損です。
そして何より、この4軸は「CREが何を大事にするか」を語る言葉になります。CREは責務の羅列ではなく、どの信頼を選び取り、解決しようとしているのか、ということをスタンスとして持っているとも説明できます。これは、登壇で触れた、CREは自分たちにとって優先度の高い「信頼」の問題を選択し、さらにそれを素早く解決し、中長期に仕組み化してスケールする高度な仕事であるという話題につながります。
MackerelのCREは何に特化しているのか：AbilityとBenevolence
MackerelのCREは、もちろん4軸すべてに跨って仕事をしています。ただ、私の実感として、特に強くフォーカスしているのは Ability（能力） と Benevolence（善意） です。
Abilityについては、オブザーバビリティという領域の専門性が、そのまま顧客の成功に直結します。サーバー・インフラ、アプリケーション、各種テレメトリー、SREing、DevOps…技術的にも周辺領域的にも複雑で、顧客の状況も千差万別です。ここで「頼れる」と思ってもらえることは、プロダクトの価値そのものになります。
Benevolenceについては、「顧客が価値に到達する」ことを第一に置く姿勢です。単に問い合わせを処理するのではなく、顧客がうまくいくための道筋を一緒に設計する。ときにはプロダクトの今の限界を正直に伝え、代替案で成功に近づける。短期で救いつつ、中長期は同じ困りごとが繰り返されないように構造化し、一般化し、プロダクトやドキュメントや仕組みに落とす。
ここに、冒頭の言葉が効いてきます。
プロフィットセンターになるというのは、CREの行動が対価を得られるということです。顧客が支払う価値のある体験を作る。マイナスをゼロに戻すだけでなく、エンジニアリングを使ってプラスの価値を生む。私はこの感覚が、8年続けられた理由のかなり大きな部分を占めています。
そして、ここを本気でやろうとすると、プロダクト開発だけでは完結しない部分もあります。サポート体制、ドキュメント、コミュニティ、営業、CS、時には契約やセキュリティまで含めて「信頼が維持・強化される設計」が必要になります。結果としてCREは横断的になりやすい。だから「狭間」になる。でも、狭間で起きる信頼の毀損は放置できない。ここに仕事が生まれ続けます。
それは専門性になりうるか：職能の条件と“+α”の正体
CREが職能として成立する条件を考えると、たとえば次のような観点が出てきます。
- 需要が安定して存在する
- 価値提供の範囲が定義できる
- 体系性がある（再現性・学習可能性）
- 評価可能である（スキルの測り方がある）
- 他職能との境界と連携が設計できる
現状、需要は明らかにあります。一方で、価値提供の範囲や体系、評価、境界は、企業ごとに設計されているのが現状です。だから「専門性が捉えにくい」という不安が生まれるのも自然です。私は、CREを職能と呼ぶには、まだいくつかの高いハードルがあると感じています。
ただ私は、ここに希望もあると思っています。CREが提供している価値は、既存の職能（サポート、CS、CSOps、開発、PM、営業など）に「+α」を載せているケースが多い。そしてこの+αの部分こそが、CRE特有の専門性として磨かれる余地があるとも考えています。
私の言葉で言えば、この+αはこうです。 組織の複雑性から生まれる“信頼の問題”を分析し、優先順位をつけ、解決策を設計し、仕組みに落としてスケールさせる力。
一方でこれは、エンジニアだけの専売特許ではないとも思っています。信頼を扱うチームに、ソフトウェアエンジニアだけが所属している必要は本来ないのではないかとも感じています。実際、MackerelのCREチームにも、過去にエンジニアではないカスタマーサクセスマネージャーのメンバーが所属していた時期があります（うまくいったことも、難しかったこともありました。これは別の機会にでも）。
だから、職種がCREであることに違和感がある、という話にも一定共感します。チーム名がCREであることにも、実は少し違和感があります。とはいえ現実としては、いまの会社の分業や評価の仕組みの中で「誰かが持たないと落ちる信頼」を持つために、CREという入れ物が有効に機能している。私の理解はそういうものです。
この+αを“個人の頑張り”で終わらせず、継続的に発揮するには、どんな組織の器がふさわしいのか。ここを一度、組織設計の言葉で考えてみます。
理想的な組織体系の仮説：+αを実行する最適な“器”は何か
ここまでで私は、CREの+αを「組織の複雑性から生まれる“信頼の問題”を分析し、優先順位をつけ、解決策を設計し、仕組みに落としてスケールさせる力」と置きました。 では、この+αを継続的に発揮するには、どんな組織形態がふさわしいのでしょうか。
私は、ここまでの考察から素朴に導き出すのであれば、の分類でいうところの イネイブリングチーム が本来的には最も相性が良いのではないか、という仮説を持っています。
なぜなら、+αの本質が「自分たちが成果物を全部抱えること」ではなく、ストリーム（プロダクト）側が信頼を維持・強化できる状態を作ることにあるからです。 具体的には、次のような動きが中心になります。
- 信頼毀損が起きている箇所を、顧客接点のデータから発見し、原因を構造として特定する
- 仕様・運用・ドキュメント・伝達・体制などを含めて、解決策を「設計」する
- その設計を、ストリーム側が再現できる形（ガイド、チェックリスト、ツール、テンプレ、意思決定の型）に落とし、移譲する
- 一時的に伴走して、チームに“インストール”する（以降は自走できる状態にする）
これは、まさに「できるようにする」「移せるようにする」仕事で、イネイブリング的です。 加えて、信頼の問題はプロダクトのあちこちに散らばり、発生源が固定されないことが多い。だからこそ、ストリームに固定で内製するより、横断の視点で“波形”を見て、チームへ入っていく形が効く、という直感があります。
一方で、現実のCREはこの理想形だけでは成立しにくいことも多いです。実際、多くの組織でCREは 常設チーム になり、加えて サポートチームやCS、CSOpsなどと兼務 になりがちです。 これは、構造上起こりやすい理由がいくつかあると考えています。
なぜ“常設×兼務チーム”になりやすいのか
1. 信頼の毀損は“今この瞬間の顧客体験”として現れる
信頼は遅効性ですが、毀損は即時に顧客体験として表れます。問い合わせ、炎上、解約予兆として出てくる。 だから短期的にはどうしても「目の前の顧客を救う」対応が優先され、CREは“現場”に留まりやすくなります。イネイブリング的な支援は本来、短期的な対応から距離を取って価値を出すものですが、信頼の問題は放っておくと損失が大きく、引き戻されます。
2. +αの材料（データ）は顧客接点に集まる
信頼の問題を設計対象にするには、具体的な顧客のつまずき、誤解、期待値のズレに関するデータが必要です。 その一次情報が最も濃く集まるのは、サポートやCSの接点です。結果として、+αをやる人が“そこにいる”のが合理的になり、兼務が自然に起きます。
3. 短期KPIの前では「信頼の設計」が後回しになりやすい
事業成長のフェーズでは、売上や開発スピード、目に見える新機能が優先されがちです。 信頼の設計は重要でも、短期のKPIに直結しないものは後回しになりやすい。そこでそれらを各チームの努力目標にするのではなく「継続的に担保する装置」として、常設チームが生まれる、という説明が成立します。LayerXさんの例を参考にした仮説です。
4. 信頼の問題は「流量が読めない」
信頼の問題が未設計のままだと、いつどれだけ発生するのかを事前に見積もれません。するとアドホックなチームのほうが都合が良いようにも聞こえますが、予測は難しくても発生自体は途切れません。この「流量が読めない」という性質は、常設チームになる理由というより、むしろ兼務になりやすい理由になります。専任にすると、波が来ない期間は稼働が余り、波が来たときは一気に溢れる。だから現実的には、サポート/CS/開発支援などの安定業務と兼務し、波を吸収する形のほうが機能する場合があります。
ここまでを踏まえると、私は次のように整理しています。
- 理想の仮説：CREの+αを最大化するなら、イネイブリング的に動ける形が強いのではないか
- 現実：ただし信頼の問題は顧客接点から噴き出すため、受け皿としての常設性・現場性が必要になりやすい
- 結論：多くのCREが「常設×兼務」のハイブリッドになっているのは、一定の合理性がある
そして、これは次の話（狭間を設計する仕事に変える）につながります。 重要なのは、常設×兼務それ自体を善し悪しで断じることではなく、狭間を「割り込み」から「設計」に変えられるかです。次は、その変換の具体を整理します。
狭間を“割り込み”のまま抱えると、チームは消耗戦になっていきます。 狭間を“設計対象”に変換できると、この現場性はむしろ武器になっていきます。
「狭間」を割り込みで終わらせない：設計する仕事に変える
次に、もうひとつの不安、「狭間の仕事が多く、やりがいを保てるのか」について。
私がここで大事だと思うのは、狭間を“割り込み”として扱うのではなく、狭間を“設計対象”として扱うことです。割り込みは無限に来ます。でも、構造として捉え直せば、減らすことも、再発させないことも、スケールさせることもできます。
具体的には、次のような問いに変換します。
- これはどの信頼（4軸）の毀損として起きているか
- それは自社にとって優先度の高い軸か
- 毀損の原因はどこにあるか（説明不足か、期待値のズレか、プロダクトの仕様か、ナレッジの未整備か）
- 一回の対応で終わらせるのではなく、どこに“仕組み”を作ればいいか
- 誰がオーナーを持つべきか（CREが永遠に抱えない設計になっているか）
こうして狭間を設計に変えると、仕事は「振り回される」から「組み立てる」に変わります。さらに、プロダクトの成長に応じて狭間の性質自体が変化するので、同じ問題を延々と解いている感覚にもなりにくい。8年続けてなお、探求できるテーマが残り続けているのは、私にとっては大きいです。
一方で、正直に言うと、MackerelのCREチームでも「信頼の設計」を、明確に職務として持てているというわけではありません。現実には、もともとの専門性（サポート、CS、開発など）への期待値が先に立つ場面も多いです。でも、今回こうして整理してみると、+αとして“すでにやっている”ことが確かにある。それを言語化できたのは自分にとっても面白い発見でした。では実際に、どこまでをチームの職務として具体的に組み込んでいくかについては、チームメンバーとも議論が必要です。
8年続けられた理由：フェーズが変わるたび、問いが変わる
最後に、「なぜ8年続けられたのか」を、いちばん素直な言葉にするとこうなります。
フェーズが変わるたびに、問いが変わるから、飽きない。
初期のがむしゃらな時期は、近さと気合で吸収できる課題が多い。成長すると、分業と境界が生まれ、信頼の毀損が構造として現れる。成熟すると、品質・期待値・運用・契約・セキュリティ・変更管理など、信頼を維持するための設計が効いてくる。さらに変革期に入ると、新しい価値を作る過程で未成熟さと向き合いながら、同時にすでに積み重ねた信頼を落とさない工夫が必要になる。
この一連の変化の中で、CREは同じ場所に立っているようで、実は見ている問題が少しずつ変わっていきます。だから飽きない。むしろ、積み上げた経験が効くほど、解ける問いの難易度が上がっていく感覚があります。
最後に、私は、CREは10年は余裕で続けられる仕事だと思っています。さらには、10年求められる仕事だとも思っています。
信頼は事業の土台です。昨今は不確実性が増し、AIの登場によって、顧客が提供したデータがどう扱われるのかも見えにくくなっています。そうした状況では、プロダクトが顧客から信頼されることが、事業継続にとってますます重要な要素だと考えます。 そして、その重要性を引き受けたいと思える志向（モチベーションやパーソナリティ）そのものが希少であり、価値があるとも感じています。
こういったCREについての探求を一緒に面白がってくれる人がいたらうれしいです。コミュニティとのつながりのなかでそういった仲間に会えることを、これからも楽しみにしています。
id:missasan
id:wtatsuru
id:ne-sachirou
id:RyuGoo
id:do-su-0805