二人が同じCRMで同じコンタクトを開きます。一方には最終通話日、deal の担当者、更新フラグが見えます。もう一方にはどれも見えません。いま見ているレイアウトに、その列が一度も追加されていないからです。二人は戦略を議論しているのではありません。レコードが何を示しているかを議論していて、しかも両方とも正しいのです。同一のデータの上で、別々の表示面を読んでいるからです。
これが、ほとんどの「数字が合わない」という会話の裏にある静かな故障モードです。レポーティングの問題であることはまれです。ほぼ常に、誰がどのレイアウトを設定したのか、そしてそのレイアウトがいまいくつ存在するのか、という問題なのです。
かつて、この食い違いの代償はコール中の数分の混乱で済みました。いまは積み上がります。GTMチームがフォローアップの下書き、アカウントのスコアリング、レコードの更新のためにAIエージェントをCRMに向けると、システム・オブ・レコードはすべてが読む土台になります。Jason Lemkin が2026年のエージェント型CRMに関する記事で述べているのは、CRMが複数のエージェントが履歴を引き出しシグナルを書き戻す中心ハブになりつつある、ということです。自社の担当者たちがレコードの示す内容で一致できないなら、同じレコードを読むエージェントは、その混乱を機械の速度で受け継ぎます。
つまり、かつては「あれば良い」程度だった規律が、いまは構造を支えるものになっています。雑然とした表示レイヤーは、人間だけが読むうちは耐えられました。ソフトウェアが読むようになると、もう耐えられません。
見分け方は簡単です。同じチームの二人に同じアカウントを開いてもらい、見えているものを説明させてください。答えが「ええと、私のビューでは」であれば、もう見つかっています。下のデータは同一です。その上のレイアウトは同一ではありません。
保存ビューを備えた現代のCRMは、HubSpot、Salesforce、Pipedrive のいずれであっても、ビューをフィルター、並べ替えた列、表示プロパティの保存された構成として扱います。それは利便性です。問題は、利便性が私有物になったときに始まります。各担当者、各マネージャー、各チームが独自の保存ビューを作り、誰も古いものを消さないのです。
怠慢ではありません。柔軟なツールの既定の挙動です。誰かが3月のキャンペーン用に列が必要で、個人ビューに足します。マネージャーが forecast コール用に deal をクローズ日順に並べたくて、それを保存します。新メンバーが既存ビューをコピーして手を加えます。どれも単独では間違っていません。半年後には保存ビューが二十個になり、その半分はチームを移った人が所有していて、同じフィールドを表示するものは二つとありません。
結果として、表示レイヤーはレコードのあらゆる共有された定義から離れていきます。誰かが同僚に情報を共有しても、同僚はそれを見つけられません。あるビューには追加されたのに、もう一方には追加されなかったからです。データはずっとそこにありました。ただ、その人が立っている場所からは見えなかっただけです。
考え方を正す捉え直しはこうです。保存ビューは表示の選択です。データではなく、真実でもありません。レイアウトがあたかも意味を帯びているかのように扱うことこそ、チームが下層を直す代わりにダッシュボードを突き合わせて終わる道筋なのです。
これは Thomas Redman が長年データ品質について説いてきたのと同じ教訓です。Harvard Business Review での論考では、品質はデータが作られる地点で管理するものであり、下流での後始末は高くつきスケールしない、と論じられています。ビューの乱立は下流の症状です。レイアウトが一つ増えるたびに、像が他の全員の像とずれうる場所が一つ増えます。それを上に良いダッシュボードを載せて直すことはできません。まず表面の数を減らすことで直すのです。
数字が合わないときの本能は、全員が信頼するはずの新しい「信頼できる唯一の情報源」ダッシュボードを作ることです。これは表面を一つ増やします。矛盾する表面を取り除くわけではないので、いまや同期し続けるべきものが一つ増えただけです。
逆の一手を打ってください。膨れ上がった pipeline や伸びすぎたプロパティ一覧に対するのとまったく同じように、保存ビューに残す・直す・消すの一巡をかけます。チーム全員が読む少数の共有ビューを残します。レコードの既定レイアウトを、人々が実際に必要とするフィールドを持つように直し、誰もそれを見るために個人ビューを作らずに済むようにします。残りを消します。目標は最強のビューではありません。仕事をまだこなせる最小限の共有ビューであり、個人ではなくチームが所有するものです。
複雑にしすぎないでください。数百シート規模のチームのほとんどに必要なのは、ひと握りの共有ビューであって、二十個の個人ビューではありません。
先日、DACH地域の Series B の B2B SaaS チームが単一のCRMへ統合するのを支援しました。その途中、ワーキングセッションで二人が、それぞれ「コンタクトのビュー」と呼ぶものを開き、フィールドが噛み合わずに話がすれ違いました。主要オブジェクトの保存ビューを数えたところ、コンタクトだけで十二個を超え、いくつかは役割を変えた人が所有していて、それぞれが少しずつ違う断面を見せていました。
解決策はそれ単独の移行プロジェクトではありませんでした。既定のコンタクトレイアウトに、サービスチームのカスタムビューが持っていたすべてを持たせ、冗長なものを消す合意を取り付け、チームが個人ビューではなく共有ビューから作業するという期待を定めました。突き合わせの問題は消えました。突き合わせるものが何も残らなかったからです。ようやく全員が、同じレコードを同じように見ていました。
- 主要オブジェクト上のすべての保存ビューを棚卸しする。 それぞれを所有者と最後に実際に使われた時期とともに一覧にします。乱立の全体を一か所で見られるまで、何を削るかは決められません。
- みなしご状態のビューを廃止する。 チームを移った人や退職した人が所有するものはすべて削除候補です。誰も守っておらず、最も簡単な成果です。
- チーム全員が読む共有ビューを定義する。 オブジェクトごと、役割ごとの小さな一式であり、個人ごとではありません。所有の単位はチームなので、新メンバーは初日から全員と同じビューを引き継ぎます。
- 必要なフィールドをレコードの既定レイアウトに移す。 個人ビューのほとんどは、既定に列が欠けていたために存在します。その列を既定に入れれば、個人ビューを作る理由は消えます。
- 冗長なものを消し、新規ビューに歯止めをかける。 新しい共有ビューはCRMを統括する人を通す、という規範を定めます。そうしないと、出発点まで一気に再び乱立します。
- 自動化とエージェントを同じ共有ビューに向ける。 workflow とAIエージェントが読むものは、人間が読むものと同じ像であるべきです。そうすればソフトウェアと人が、二つではなく一つのレコードから作業します。
自社のチームが一貫して見られないデータの上で動く forecast、自動化、エージェントは信頼できません。共有ビューへの標準化は地味ですが、CRMで最も安上がりな信頼性の獲得であり、チームを共有ビューへ移すのは通常、半日の作業であってプロジェクトではありません。片づけにもう一組の手が欲しいなら、それこそ私たちの Revenue Operations と HubSpot 実装の仕事が想定しているものです。go-live の前にこれを標準化するという隣接する課題については、CRM の go-live 前のリハーサルに関する関連記事をお読みください。
- Thomas Redman.「To Improve Data Quality, Start at the Source.」Harvard Business Review、2020年2月。hbr.org
- Jason Lemkin.「Which CRM Should You Use in 2026/2027? Follow the Agents.」SaaStr、2026年。saastr.com