「あの情報、どこにあるっけ」
そう思う回数が、増えていないか。
Notionを開く。Slackを確認する。メールを見る。Googleドライブも確認する。CRMにも入れたかもしれない。ツールの数だけ、「あそこかもしれない」という場所が増えていく。情報はあるはずだ。でも、必要なときに出てこない。
ツールを増やすたびに、便利になっているはずだった。でも気づくと、「全体が見えない」感覚が強くなっている。引き継ぎがうまくできない。あの人に聞かないとわからないことが増えた。会議のたびに「あれはどこの話でしたっけ」という確認が入る。
これは、情報管理の問題ではない。「分断」という構造の問題だ。
この記事は、SaaSが増えることで起きる分断を、もう少し深く見ていく試みだ。以前の記事でSaaSの疲弊に触れたが、ここでは「なぜ分断が起きるのか」「分断が何を奪っているのか」という構造の側から掘り下げる。
SaaSが増えると、仕事はどう変わるか
ツールが一つのとき、仕事の流れはシンプルだ。情報が一カ所にある。経緯が追える。「あのやり取り」を探せる。引き継ぎも、そのツールを共有すれば済む。
ツールが増えると、この単純さが崩れていく。
ツールごとに文脈が分断される。プロジェクト管理はAsanaで。コミュニケーションはSlackで。顧客情報はCRMで。資料はGoogleドライブで。それぞれのツールには、それぞれの「文脈」が積まれていく。でも、ツールをまたぐと文脈がつながらない。「Slackでの議論を踏まえてAsanaのタスクを見る」という行為は、人間の頭の中でしか起きない。
人によって使うツールが違う。ベテランのAさんはメールで管理している。若手のBさんはSlackを使う。別の部署はTeamsだ。同じ仕事をしているのに、どこを見れば全体がわかるのか、チームの誰も把握していない。「Aさんに聞かないとわからない」という状態が、あちこちに生まれる。
情報が散逸する。決定事項がSlackの会話の中に埋まっている。重要な判断の経緯が、メールのスレッドの奥にある。顧客とのやり取りが、担当者の個人メールに残っている。情報は存在するが、必要な人が必要なときに取り出せない。存在するのに使えない情報は、ないのと同じだ。
ツールを増やすほど、この状態は深刻になる。一つ追加するたびに、「また別の場所」が生まれる。情報の在り処の候補が増え、探すコストが上がり、全体像がさらに見えにくくなる。
分断とは何か
「情報が散らばっている」という言葉だと、整理すれば解決しそうに聞こえる。でも、分断の本質はもう少し深いところにある。
分断とは、「文脈が途切れること」だ。
文脈とは、情報の背景にあるものだ。「なぜこの決定がされたのか」「どういう経緯でこうなったのか」「この顧客は以前どんな状態だったのか」——情報そのものではなく、情報が生まれた背景と、情報がどう使われるべきかの文脈だ。
文脈があるとき、情報は意味を持つ。「売上が先月比15%減」という数字が、「新規開拓を止めた時期と重なっている」という文脈と一緒にあると、判断の材料になる。文脈がないと、数字はただの数字だ。
ツールが分断すると、情報は渡っても文脈が渡らない。データはCRMに転記できる。でも「このお客さんが最初に話してくれたときの温度感」「前回のやり取りでちょっと気になった言葉」——そういう文脈は、転記されない。担当者が変わると、データはあるのに、関係の質がゼロに戻る。
「また最初から説明しなければならない」という顧客の体験は、分断の最も見えやすい症状だ。情報は引き継がれているはずなのに、対応してくれる人が「前のやり取りを把握していない」と感じさせる。それは情報の不足ではなく、文脈の不足から来ている。
分断は、情報量の問題ではない。文脈がつながっているかどうかの問題だ。
分断が生む「見えないコスト」
分断による問題は、数字として見えにくい。だから軽視されやすい。でも、確実に消耗を生んでいる。
情報を探すコストがある。「あの決定の経緯はどこに書いてあるか」を探す時間。「あのお客さんのこれまでのやり取り」を復元する時間。1回あたりの時間は小さくても、毎日繰り返せば積み上がる。そしてこの時間は、「生産的な仕事をしていない時間」として計上されない。ただ消えていく。
判断のズレが起きる。同じ顧客や案件について、Aさんはこう認識していて、Bさんは別に認識している——という状態が生まれる。情報の共有はされているが、文脈が共有されていないから、判断の前提がズレる。ズレたまま進んで、後で「そういう意図じゃなかった」という摩擦が起きる。
引き継ぎのコストが高い。担当者が変わるとき、「この人でないとわからない」情報がある。マニュアルに書けない暗黙の文脈だ。引き継ぎに時間がかかる。それでも完全には引き継げない。「前の担当者のときはもっとスムーズだった」という顧客の感覚が生まれる。
「また最初から説明」という消耗がある。顧客の側も、提供者の側も、文脈が引き継がれていないとき、同じ説明を繰り返す必要がある。顧客は「また言わなければならない」という疲れを感じる。提供者は「また聞かなければならない」という非効率を感じる。関係の質が、少しずつ落ちていく。
これらのコストは、経費として見えない。時間として計測されない。でも、確実に事業のエネルギーを消耗させている。
分断を生むのは、ツールではなく「設計の不在」だ
SaaSが悪いのではない。分断が起きるのは、ツールの問題ではなく「設計の不在」の問題だ。
多くの場合、ツールは「課題が出たから入れた」という経緯で増えていく。顧客管理が必要になったからCRMを入れた。タスク管理が必要になったからプロジェクト管理ツールを入れた。コミュニケーションが分散したからチャットツールを入れた。それぞれの判断は合理的だ。でも「このツールと既存のツールの間を、情報はどう流れるか」という設計がないまま増えていく。
結果として、ツールは増えたが、ツール間の「つなぎ目」がない。情報はそれぞれのツールの中に蓄積されるが、ツールをまたぐ流れがない。人間がその都度、手動でつないでいる。その人間コストが、分断のコストだ。
設計がないとは、「誰が・どこに・何を・どのタイミングで入れるか」が決まっていないということだ。入れる場所が人によって違う。入れるタイミングが曖昧だ。何を入れるべきかの基準がない。だから、情報はツールに入っているようで、実際には使える状態になっていない。
設計とは、ツールの使い方を決めることではない。「情報の流れを決めること」だ。どこで情報が生まれて、どこへ渡って、どこで判断に使われるか。その流れを描くことが、設計だ。ツールはその流れを実現するための手段であって、ツールを選ぶことが設計ではない。
分断を防ぐ「つなぎ目の設計」
分断を防ぐためには、ツールを減らすことより、「つなぎ目を設計すること」が有効なことが多い。
つなぎ目とは、情報がツールからツールへ渡る瞬間だ。顧客との会話が終わったとき、その内容はどこへ行くか。プロジェクトの決定がされたとき、それはどこに記録されるか。問い合わせが来たとき、誰がどこで受けて、どこへ渡すか。この「渡す瞬間」を意識することが、つなぎ目の設計だ。
具体的には、「情報がどのツールからどのツールへ渡るか」を描くことから始まる。顧客との会話→CRMへ。CRMのステータス変化→担当者へ通知。担当者の対応記録→CRMへ。この流れを描くと、「人間がどこで介在するか」と「自動化できる部分はどこか」が見えてくる。
「どのタイミングで渡るか」も重要だ。情報をリアルタイムで共有するのか、日次でまとめるのか、特定のステータス変化があったときに渡すのか。タイミングが曖昧だと、渡し忘れや二重入力が起きる。タイミングを決めることで、流れが安定する。
「何を持って渡るか」も設計が必要だ。すべての情報を渡す必要はない。次のステップで必要な情報だけを、整理して渡す。「たくさん共有した」より「必要なものだけ渡った」の方が、文脈は引き継がれやすい。
完璧なつなぎ目を最初から作る必要はない。今、最も「ここで切れている」と感じるつなぎ目を一つ特定して、そこから手をつける。一つのつなぎ目が整うと、その前後の流れも見えやすくなる。
事業のベース地——情報が集まり、流れの起点となる場所——が整っているとき、各ツールはそこに接続する補助として機能する。ベース地なきSaaSの追加は、分断を加速させるだけだ。
あなたの事業で今、文脈が途切れているのはどこか。
「また最初から説明した」という体験が最近あったなら、そこがつなぎ目の問題を抱えている可能性がある。「あの情報はどこだっけ」という場面が繰り返されているなら、そこに設計の不在がある。
ツールを増やす前に、今あるつなぎ目を問い直す。それが分断を解消する、最初の一歩だと思っている。
