1. はじめに：半年で世界がひっくり返るとは思っていませんでした
4月に新卒エンジニアとして入社し、プログラミング研修に追われていた私は、自分がRevOpsを推進するチームに配属されるとは考えてもいませんでした。
正直なところ、この時の私は、
- RevOpsって営業やマーケの話だしエンジニアと何が関係あるんだろう
- コーディングを学んできたけど活かせるんだろうか…
そんな戸惑いのほうが大きかったです。
そして配属後、チームの課題図書で 『RevOpsの教科書』 を渡されました。
「営業やマーケの話をなぜエンジニアが読むんだろう？」
そんな疑問を抱きながら読み始めたのですが、結果として、この本が私の考え方を変えました。
この記事は、RevOpsとエンジニアのつながりに気づいていく過程をまとめたものです。
2. RevOpsの“理想”を見たときの疑問
RevOpsでは、よくこんな理想が語られます。
- マーケ → 営業 → 顧客対応まで一気通貫で進むプロセス
- 共通KPIで組織が同じ指標を見る状態
- どの部門でも同じ顧客像を共有できること
つまり、プロセスとデータと顧客の流れが一本の線としてつながっている状態です。
理想は理解できる。
しかし、その理想を“動く仕組み”として成立させるには、
「これ、データ構造が整っていないと成立しないのでは？」
と気づきました。
3. 多くの組織で起きる“サイロ化”は、実はデータ構造の問題
RevOpsの最大の課題はサイロ化です。
私は最初「サイロ化＝部門間のコミュニケーション不足」だと思っていました。
しかし、整理するとサイロ化とはもっと構造的な問題だと気づきました。
世の中でよく起きるサイロ化の正体
- 部門ごとにステータス定義が異なる
- 帳票・パイプラインが部署ごとに作られる
- リードと商談が別経路で管理される
- KPIや指標が部門単位で独自定義されている
これらが積み重なると、
- データがつながらない
- プロセスが途中で途切れる
- KPIの計算が歪む
つまり、
サイロ化とは「コミュニケーションの問題」ではなく「データの断絶」。
ではこの断絶はなぜ起こるのか。
4. RevOpsを動かすボトルネックは“プロセスをデータ構造に落とす技術”なのでは？
RevOpsの理想は「マーケ・営業・CSが一気通貫でつながり、データに基づく意思決定ができる状態」です。
この理想を実現するには、顧客接点のプロセスが一貫しており、その流れがデータとしても途切れずに表現されている必要があります。
しかし、多くの組織ではこの理想が実現しない構造的な課題が存在します。
それらは単なる運用ミスではなく、“業務プロセスの設計”と“データ構造の設計”が一致していないことから生まれる現象です。
言い換えると、RevOpsを動かすボトルネックは、
「プロセスをどのような単位・関係でデータ構造に落とし込むか」を設計しきれていないこと
にあるのではないでしょうか。
以下では、よく起きる4つの課題を
「なぜそうなるのか」「何が本質的な要因なのか」に分解して整理していきます。
⸻
■1. 部署ごとにステータスやプロセス定義が異なる
これは「不統一だから悪い」という話ではありません。
ほとんどの組織がプロセス定義を部門最適で作り続けた結果、自然発生的にズレていきます。
◇なぜズレるのか
• 各部署のKPIが異なる
• 商談・リードの定義が部門単位で最適化される
• 部門ごとに管理者が異なる
◇結果として起きること
• 顧客の“全体の流れ”を把握できない
• KPIの計算方法が部署ごとに違うため、全社的な意思決定がブレる
本質：部門ごとの最適化が、顧客の一連の流れと噛み合っていない構造
⸻
■2. パイプライン・帳票が部門ごとに分散し運用コストが高くなる
これは「無駄に分散している」のではなく、帳票を共通化する基準が存在しないことが原因です。
◇なぜ共通化されないのか
• 部署ごとに見たい指標・粒度が違う
• 過去の帳票がそのまま残り続ける
◇起きる現象
• 同じデータでも部門ごとに別帳票が作られる
• 各担当者が毎Q帳票を作り直す
• 指標定義が揃わず数字の比較ができない
本質：帳票は“データモデルの派生物”であるにも関わらず、逆に帳票がプロセスを決めてしまっている構造
⸻
■3. システム追加・改修の積み重ねによるデータフローの複雑化
どの会社でも起こる「歴史的負債」で、システム間連携の宿命でもあります。
◇なぜ複雑化するのか
• 過去の仕様を“壊せない”ため増築方式になる
• ロジックがブラックボックス化する
• 担当者異動で意図が失われる
◇起きる現象
• 補修ロジックが増え、データの整合性を保てなくなる
• 既存影響範囲が読みにくいため新しい仕組みを追加する際に既存のものを修正できない
• データの流れが“全体設計ではなく部分最適の継ぎ接ぎ”になる
本質：データモデルの原則（シンプル・正規化・一貫性）が時間と共に崩壊していくこと
⸻
■4. 活動が統一的に計測されずPDCAが回らない
これは単なる“データ欠損”ではなく、
「入力するべきポイントが統一されていない」ために起きる導線問題 です。
◇なぜ計測できないのか
• 行動ログを“どの単位で記録するか”が定義されていない
• 入力する画面やタイミングがバラバラ
• 計測項目がプロセス完了条件に紐づいていない
◇起きる現象
• 施策の効果が評価できない
• ボトルネックの場所がわからない
• 定量評価できないため改善が「感覚」になる
本質：プロセスが計測可能な"構造"に変換できていないこと
⸻
■分析のまとめ
上記4つの問題は別々のように見えるが、すべては以下1点に収束する。
プロセス構造（どのように仕事が流れるか）と
データ構造（どのようにデータが保持されるか）が一致していない
◇一致していないと：
• 部署間の定義が揃わない
• 帳票が増え続ける
• システムが複雑化する
• 活動ログが計測できない
結果として、RevOpsの理想である
「一気通貫でつながり、データに基づく意思決定ができる状態」が成立しなくなる。
つまり、RevOpsのボトルネックは
“人”でも“文化”でもなく、“構造” にある。
5. 新卒エンジニアとして、この領域に飛び込んで感じていること
1. 飛び込んでみてわかったこと
RevOpsに関わる前は「営業やマーケの領域で、エンジニアとは少し距離がある」と感じていました。
しかし、実際にプロセスとデータの流れを分解していくと、各部門で起きていた問題は
コミュニケーション不足ではなく“構造設計のズレ”から生まれる現象だと分かりました。
ステータスの不一致、帳票の乱立、データフローの複雑化、計測できないプロセス...
4章で整理したこれらの課題はすべて、「プロセス構造」と「データ構造」が一致していないことが原因です。
そして、この“構造の扱い方”そのものが、エンジニアが日々向き合っているテーマと重なります。
RevOpsは運用の工夫の話でだけではなく、
ビジネス全体をどんな構造で表現するかという根本設計の領域だと実感しました。
2. エンジニアとしてどう関わりたいか
構造をつくる、整える、変化に耐えられる形にする
これは、コードやデータベースを扱うエンジニアが得意とする役割です。
- プロセスをどの単位で切り、どの関係でデータに落とし込むか
- 変更が起きても破綻しないデータモデルはどうあるべきか
- どこを自動化し、どこを人の判断に委ねるのか
こうした問いは、RevOpsを推進する上で避けて通れません。だからこそ、エンジニアの視点はこの領域で大きな力になります。
私はエンジニアとしてまだ学びの途中ですが、業務やデータの前提を整理し、構造を設計・再設計できるエンジニア として成長していきたいです。