%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png?width=130&height=39&name=%E6%9C%80%E7%B5%82Start%20Link%20(500%20x%20150%20px)%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png "StartLink"){kind=logo}
この記事の結論
部門間のサイロ化は、業務の非効率・顧客体験の断絶・データの分断を引き起こす組織の構造的な課題です。解消の起点は、部門の「つなぎ目」に引き渡し基準・責任者・期限を決め、それを人ではなく仕組みで回すこと。
部門間のサイロ化は、業務の非効率・顧客体験の断絶・データの分断を引き起こす組織の構造的な課題です。解消の起点は、部門の「つなぎ目」に引き渡し基準・責任者・期限を決め、それを人ではなく仕組みで回すこと。
「マーケが渡したリードが、営業で手つかずのまま残っている」「受注時の約束事項が導入チームに伝わっていない」「カスタマーサクセスが契約内容を別のスプレッドシートで探している」——部門間の連携不全は、企業の規模を問わず起こりやすい課題です。
部門横断の業務フロー設計とは、マーケティング・営業・カスタマーサクセスなど複数部門にまたがる業務を1本の流れとして描き、部門間の引き渡し条件・責任・期限・共有するデータを定義することです。各部門の業務を個別に効率化するのではなく、顧客から見て途切れない流れをつくることを目的とします。
ただし、つなぎ目の最適な形は、商材・組織体制・使っているツールによって企業ごとに異なります。StartLinkでは、他社の型をそのまま写すのではなく、自社の条件で選び、小さく始めて広げる進め方をおすすめしています。
本記事では、サイロ化が起きる仕組みを整理したうえで、部門横断フローの設計手法、CRM上での仕組み化、段階的な導入の進め方までを、判断の手順として解説します。
DXのプロセス設計について体系的に学びたい方は、プロセスマッピングガイドで全体像を把握できます。
この記事でわかること
本記事では、部門間のプロセス断絶がなぜ起きるのかを構造的に分析し、部門横断フローを設計して日々の運用に乗せるまでの手順を紹介します。
こんな方におすすめ: 営業・マーケ・CSなど部門間の連携に課題を抱えている経営者・事業責任者の方、全社横断のプロセス改善プロジェクトを推進する立場の方
- サイロ化が起きる3つのメカニズム — 構造的・プロセス的・情報的な要因と、自社でどの要因が効いているかの見分け方がわかります。
- スイムレーン・RACI・内部SLAの組み合わせ方 — 部門横断プロセスの流れ・責任・期限を決める3つの手法の使い分けがわかります。
- マーケ→営業→CSの一気通貫フロー — 各ステージの引き渡し基準と、受注時に共有すべき情報、失注・解約から戻るループの設計がわかります。
- 引き渡し基準をCRMで仕組み化する考え方 — ライフサイクルステージ・取引パイプライン・ワークフローに基準を載せる方法がわかります。
- 共通KPIと段階的な導入手順 — 部門をまたぐ成果の測り方と、1本のプロセスから広げていく進め方がわかります。
この記事を読み終えるころには、自社のサイロ化の主な要因と、最初に手を付けるつなぎ目が決められます。まずは売上に直結するプロセスを1本選び、部門をまたぐ引き渡しポイントを書き出すところから始めてください。
サイロ化が発生する3つのメカニズム
サイロ化は、担当者の意識や部門同士の相性だけで起きるものではありません。組織構造・プロセス・情報の3つの層それぞれに原因があり、どの層の問題かによって打ち手が変わります。まずは自社のつまずきがどの層にあるのかを切り分けるところから始めるのがおすすめです。
構造的要因：部門最適化のインセンティブ
サイロ化の大きな原因は、組織構造そのものにあります。部門ごとにKPIが設定され、部門ごとに予算が配分され、部門ごとに評価が行われると、この構造が各部門を「自部門の最適化」に向かわせることがあります。
例えば、マーケティング部門は「リード獲得数」、営業部門は「受注金額」、カスタマーサクセス部門は「解約率」をKPIに置くケースがあります。各部門がそれぞれのKPIを追求すること自体は合理的ですが、部門間の「つなぎ目」にあたるプロセスは誰のKPIにも含まれないため、放置されがちです。
その結果、マーケがリード数の目標を達成し、営業も受注金額の目標を達成している一方で、引き渡したリードのうち何件が商談になったのかを誰も追っていない、という状態が起こります。どちらの部門も自分の数字は達成しているため、つなぎ目の損失が表に出にくいのがこの要因の厄介な点です。
プロセス的要因：引き渡し基準の曖昧さ
部門間でデータや案件を引き渡す際、その基準が明確でなければ、以下のような問題が発生します。
- マーケが「リード」として営業に渡した案件が、営業にとっては「まだ商談にならない」レベルだった
- 営業が受注した案件の情報が不十分で、導入チームが再度ヒアリングを行う必要があった
- カスタマーサクセスが顧客の過去のやり取り（営業時の約束事項等）を把握できていない
これらはすべて、部門間の「引き渡し基準（ハンドオフ基準）」が定義されていないことに起因します。受け取る側の部門が「何がそろっていれば受け取るのか」を言語化していないため、渡す側は自分の感覚で渡し、受け取る側は差し戻すか、黙って作業をやり直すことになります。こうしたプロセスの断絶を可視化するためには、業務フロー可視化の目的と効果で解説している手法が有効です。
情報的要因：データの分断
部門ごとに異なるツールやシステムを使用していると、データが分断されます。マーケのデータはMAツールに、営業のデータはSFAに、CSのデータは独自のスプレッドシートに——こうした状態では、顧客の全体像を誰も把握できません。
スプレッドシートでの管理は始めやすい反面、部門ごとに別のファイルが作られ、同じ顧客の情報が複数の場所に存在するようになります。一方のシートで担当者を更新しても、もう一方には反映されず、どちらが正しいのかを毎回人に聞いて回ることになります。引き渡しのたびに情報をコピーし直す手作業が発生し、その転記の過程で漏れや食い違いが生まれます。
自社のサイロ化がどの要因から来ているかを見分ける
3つの要因は同時に起きていることが多いものの、最初に手を付ける対象は絞った方が進めやすくなります。本記事では、現場で起きている症状から主な要因と着手対象を次のように整理します。
| 現場で起きていること | 主な要因 | 最初に手を付ける対象 |
|---|---|---|
| 引き渡した案件が止まっていても、誰も気づかない | 構造的要因 | 部門をまたぐ共通KPI |
| 受け取る側が「まだ早い」「情報が足りない」と差し戻す | プロセス的要因 | 引き渡し基準と内部SLA |
| 同じ顧客の情報を複数のツールやシートで探している | 情報的要因 | データ基盤の統一 |
複数の症状が当てはまる場合は、プロセス的要因から着手することをおすすめします。引き渡し基準が決まっていないままKPIやツールを整えても、何をもって「引き渡し完了」とするかが定まらず、KPIの測り方もデータ項目の設計も決められないためです。
全部の要因を一度に解消しようとせず、自社の症状に合う1つの要因から小さく始め、効果を見ながら次の要因へ広げていきます。
部門横断プロセスを設計する3つの手法
部門横断プロセスは、「流れ」「責任」「期限」の3点が決まると運用に乗ります。本記事では、流れをスイムレーンダイアグラム、責任をRACIマトリクス、期限を内部SLAで定義する組み合わせとして整理します。3つは別々の資料ではなく、同じプロセスに重ねて使うものと考えてください。
手法1：スイムレーンダイアグラムで流れと引き渡しを可視化する
部門横断プロセスの可視化には、スイムレーンダイアグラムが適しています。各部門をレーン（区画）として配置し、プロセスの流れと部門間の引き渡しポイントを明示します。
スイムレーンダイアグラムで可視化すべき要素は以下のとおりです。
- 各部門の担当業務（レーン内のタスク）
- 部門間の引き渡しポイント（レーンをまたぐ矢印）
- 引き渡しの条件・基準
- 各ステップの所要時間（SLA）
- 情報の流れ（データ・ドキュメント）
描き終えたら、レーンをまたぐ矢印を1本ずつ見て、「引き渡しの条件」「期限」「渡す情報」の3つが書き込めるかを点検します。3つとも書ける矢印は運用が回っている箇所で、1つでも空欄になる矢印が、次に基準を決めるべき箇所です。空欄の矢印が多い場合は、売上への影響が大きい順に1〜2本を選んで先に埋めていくと、議論が散らばりません。図の描き方の詳細は、業務プロセスマップの書き方で解説しています。
手法2：RACIマトリクスで責任の空白をなくす
RACIマトリクスは、各タスクに対して以下の4つの役割を明確にするツールです。
| 役割 | 意味 | 説明 |
|---|---|---|
| R（Responsible） | 実行責任者 | タスクを実際に実行する人 |
| A（Accountable） | 説明責任者 | タスクの最終的な責任を持つ人（各タスクに1人） |
| C（Consulted） | 相談先 | 実行前に意見を求める人 |
| I（Informed） | 報告先 | 完了後に報告する人 |
部門横断プロセスにおいて、「誰が実行し、誰が最終責任を持ち、誰に相談し、誰に報告するか」が曖昧だと、責任の空白地帯が生まれます。RACIマトリクスで各タスクの責任を明確にすることで、この空白を解消できます。
スイムレーン図の引き渡しポイントを行に並べ、部門や役職を列にしてRACIを書き込むと、つなぎ目ごとの責任が一覧になります。点検するのは「A」の列です。Aが空欄の行は責任の空白、Aが2人以上いる行は責任の重複で、どちらも引き渡しが止まる原因になります。空欄なら、そのつなぎ目の成果に最も影響を受ける部門の責任者をAに置き、重複していれば1人に絞り、もう一方をCかIに移します。
手法3：内部SLAで引き渡しスピードを測れるようにする
部門間のプロセスに内部SLA（応答時間・処理期限の合意）を設定します。
| プロセス | 引き渡し元 | 引き渡し先 | SLA |
|---|---|---|---|
| リード引き渡し | マーケティング | インサイドセールス | MQL判定後24時間以内に初回コンタクト |
| 商談引き渡し | インサイドセールス | フィールドセールス | SQL判定後48時間以内に商談設定 |
| 受注引き渡し | フィールドセールス | カスタマーサクセス | 受注後3営業日以内にキックオフ |
| エスカレーション | カスタマーサクセス | 営業マネージャー | 解約リスク検知後24時間以内に共有 |
SLAを設定することで、部門間の引き渡しスピードが計測・管理可能になります。上の表の時間は設定例で、自社の商材の検討期間や体制によって適切な値は変わります。
本記事では、SLAの値を次の順番で決めることをおすすめします。
- 現状の所要時間を把握する ── 引き渡しポイントごとに「引き渡した日時」と「受け取った側が最初に動いた日時」を一定期間記録します（例：リード引き渡しなら、1か月分のMQLの引き渡し日時と初回コンタクト日時を並べ、多くの案件が収まっている時間を出発点にします）
- 守れる水準でSLAを置く ── 次に、その実績をもとに置きます
- 超過した案件を月次で見る ── 運用を始めたら、「SLAを超えた案件」だけを抜き出し、超えた理由が人員不足なのか基準の曖昧さなのかを分けて見ていきます
理由が基準の曖昧さに偏っていれば手法1・2に戻り、人員不足に偏っていれば担当の割り振りを見直します。KPIとしての測り方は、業務プロセスKPIの設計方法もあわせてご覧ください。
3つの手法を全部のプロセスに一度に適用する必要はありません。自社で最もつまずいている1本のつなぎ目から順に、流れ・責任・期限を重ねていく進め方をおすすめします。
マーケ→営業→CSの一気通貫フロー設計
3つの手法を、見込み顧客が顧客になり、継続利用に至るまでの流れに当てはめます。ポイントは、各ステージを部門の持ち場として定義するのではなく、前後の部門へ「何を渡すか」で定義することです。最後のステージから最初のステージへ戻るループまで含めて、1本のフローとして設計します。
ステージ1：リードの獲得と資格付け（マーケティング）
マーケティング部門がWebサイト・広告・コンテンツ・セミナーなどを通じてリードを獲得し、スコアリングやナーチャリングを経て「営業に引き渡す価値のあるリード（MQL）」を選定するステージです。
マーケから営業への引き渡し基準（MQL→SQL）の例は次のとおりです。
- 行動スコア（Webサイト訪問・資料ダウンロード・セミナー参加等）が閾値を超えている
- BANT条件（Budget・Authority・Need・Timeline）のうち少なくとも2項目が確認済み
- 企業属性（従業員規模・業種・地域）がターゲットセグメントに合致
これらはあくまで例で、どの条件を採用するかは自社の商材と営業の進め方に合わせて選びます。この基準は、マーケだけで決めず、受け取る営業側と合意して決めてください。営業が差し戻したリードの理由を記録しておき、差し戻しが特定の条件に集中していれば、その条件を引き渡し基準に加えます。逆に、基準を満たさないまま渡されたリードからも商談が生まれている場合は、基準が厳しすぎる可能性があるため、閾値を下げる方向で見直します。
ステージ2：商談の推進と受注（営業）
インサイドセールスが初回コンタクトを行い、ニーズを深掘りした上でフィールドセールスに引き渡し、提案・交渉・クロージングを行うステージです。
営業からCSへの引き渡し情報（受注時に共有すべきデータ）は次のとおりです。
- 顧客の課題と導入目的（なぜこの製品・サービスを選んだか）
- 提案内容と合意事項（契約範囲・カスタマイズ内容・特別条件）
- 意思決定者と実務担当者の連絡先
- 導入スケジュールと成功基準
これらを受注後に思い出して書くのではなく、商談の進行に合わせて記録される形にしておくと、引き渡し時の抜け漏れが減ります。例えば「提案内容と合意事項」は見積もりを提示する段階で、「導入スケジュール」は受注内示の段階で記録する、というように、どのステージで何を記録するかを決めておく考え方です。
ステージ3：オンボーディングと継続支援（カスタマーサクセス）
カスタマーサクセスが顧客のオンボーディングを支援し、導入後の活用促進・アップセル・契約更新を管理するステージです。
CSから営業・マーケへのフィードバックループは次のとおりです。
- 顧客の活用状況と満足度のデータ（営業にフィードバック→提案品質の向上）
- 解約理由・不満の分析結果（マーケにフィードバック→ターゲティングの改善）
- アップセル・クロスセルの機会（営業にフィードバック→追加受注）
フィードバックは、気づいた人が気づいたときにチャットで送る形だと、受け取る側に残りません。どの情報を、どの頻度で、誰に渡すかをステージ1・2と同じように引き渡しポイントとして定義し、RACIとSLAを付けておくことをおすすめします。例えば、解約理由の分析結果は月次の会議の前に集約してマーケに渡す、アップセルの機会は検知した週のうちに営業担当へ共有する、といった形で頻度と宛先を決めます。
失注・解約から最初のステージへ戻すループ
一気通貫のフローは、受注やオンボーディングで終わりではありません。失注した商談や解約した顧客を、ナーチャリングの対象として最初のステージへ戻す流れまで設計しておくと、フローが一方通行ではなく循環になります。
そのために重要になるのが失注理由の記録です。失注理由を「価格」「競合他社」「製品機能」「時期」「社内決裁」などのカテゴリーで選ぶ形にしておくと、部門をまたいで集計できるようになります。「製品機能」が多ければ製品開発やマーケのメッセージに、「時期」が多ければ一定期間後の再アプローチを前提としたナーチャリングに、というように、理由ごとに戻し先を決めておけます。自由記述だけだと集計できず、結局は営業の頭の中に知見が残るだけになりがちです。
一気通貫のフローも、最初から3ステージすべてを作り込む必要はありません。最もつまずいている引き渡しポイントから決めて運用し、うまく回ったら前後のステージへ広げる順番で進めてください。
引き渡し基準をHubSpot上の仕組みに落とし込む
引き渡し基準を文書で決めても、担当者の記憶や心がけに頼る運用では、異動や繁忙期に崩れていきます。StartLinkでは、基準をCRMのデータ項目と自動処理に置き換え、担当者が替わっても新人が入っても同じ判断で回る状態をつくることをおすすめしています。
ここではHubSpotを例に、コンタクト→取引→顧客→請求という流れのどこに、どの機能を置くかを整理します。リレーショナルなデータ構造を持つCRMであれば、他の製品でも同様の考え方で設計しやすくなります。
ライフサイクルステージでマーケと営業の境目を定義する
ライフサイクルステージは、コンタクトや会社が「いまどの検討段階にあるか」を表す項目で、コンタクトから顧客になるまでの区間を受け持ちます。HubSpotの標準のステージは、購読者、リード、マーケティング・クオリファイド・リード（MQL）、セールス・クオリファイド・リード（SQL）、商談、顧客、エバンジェリスト、その他で構成されています。
標準ではステージは前方向に進む設計で、前の段階へ戻すには一度値をクリアしてから設定し直す手順が案内されています（出典：Use lifecycle stages）。
部門横断の観点では、ステージ1で決めたMQL→SQLの引き渡し基準を、このステージの定義としてそのまま使うのがポイントです。「MQLとは何を満たした状態か」「SQLに上げるのは誰か」をステージごとに決めておくと、マーケと営業が同じ言葉で同じ状態を指せるようになります。前方向にしか進まない仕様は、失注・解約からナーチャリングへ戻すループを設計する際に影響するため、戻す処理は「クリア→再設定」の2段階で組んでおきます。
また、コンタクト単位と会社単位のどちらで管理するかも判断の分かれ目です。リードの件数に比べて会社の数が少なく、1社に複数のリードがいる状態が多いなら、会社単位でもステージを管理し、会社のステージはその会社のコンタクトのうち最も進んだ段階に合わせる設計をおすすめします。
取引パイプラインで営業からCSへの引き渡しを可視化する
取引パイプラインは、商談から受注、さらに請求準備までの区間を受け持ちます。部門横断のフローで見ると、受注のステージが営業からCSへの引き渡しポイントにあたります。本記事では、パイプラインを次の4つの要素で設計する考え方を推奨します。
| 要素 | 内容 | 部門横断での役割 |
|---|---|---|
| 取引ステージ | 受注率が変化するポイントでステージを分ける | 部門をまたいで案件の進み具合を同じ言葉で共有できる |
| 受注確度 | ステージごとに受注の見込みを置く | 加重した見込み額で、CSやバックオフィスが受注後の準備量を見積もれる |
| ステージ定義 | 各ステージの意味を明文化して共有する | 担当者ごとの判断のばらつきを減らす |
| 必須入力項目 | ステージを進める際に入力する項目を決める | 受注時の引き渡し情報が自然にそろう |
ステージ2で挙げた「受注時に共有すべきデータ」は、4つ目の必須入力項目として受注ステージに置くのが基本です。新しく入った営業担当にとっても、何を確認して何を記録すべきかが画面上で示されるため、教育の手間を減らす効果があります。
次の画面は、取引をテーブルビューで一覧表示した例です。部門をまたいで同じ一覧を参照できるようにしておくと、週次のパイプラインレビューのたびに別資料を作る必要がなくなります。
ワークフローで判定と通知を自動化する
ワークフローは、条件を満たしたレコードに対して通知・タスク作成・項目更新などを自動で実行する機能で、ライフサイクルステージと取引パイプラインをつなぐ役割を持ちます。ワークフローは各HubのProfessional以上のプランで提供されています（出典：Create workflows）。
例えば、SQLに上がったコンタクトの担当営業へ通知を送る、取引が受注ステージに進んだらCS担当にキックオフのタスクを作る、といった形で、内部SLAの起点を自動で記録し、引き渡しを人の連絡に頼らない形にできます。通知は、受け取った担当者がその日のうちに次の行動を決められる条件に絞ってください。運用を始めて1〜2週間ほど様子を見て、開かれないまま残った通知があれば、その条件から外していくと通知が埋もれにくくなります。
次の画面は、問い合わせ内容をAIで判定し、その結果によって分岐してレコードを更新するワークフローの例です。
フォームからの問い合わせを、営業向けの案件と、それ以外の問い合わせに振り分けるような判定をワークフローに組み込むと、マーケと営業の間の振り分け作業を人が毎回行わずに済みます。
AIに任せる判定と人が決める基準を分ける
HubSpotのAI機能であるBreezeなどを使うと、引き渡しの前後にある判断作業の一部を自動化できます。ただし、AIに任せられるのは決まった基準に沿った分類や下書きまでで、基準そのものを決めるのは人の役割と考えています。
| AIに任せやすい作業 | 人が決めること |
|---|---|
| 問い合わせの分類（営業案件かどうか） | 引き渡し基準・ステージの定義 |
| 引き渡し前のレコードの要約 | 部門間のRACIとSLA |
| 企業情報の下調べ | 大型案件へのアプローチ方針 |
| メールの下書き | 最終的な送信判断 |
AIの判定結果は、最初からそのまま次の工程に流すのではなく、一定期間は人が結果を見直す運用をおすすめします。見直しで誤判定が目立つ分類があれば、判定の指示や分類の定義を修正し、誤りが減った分類から人の見直しを外していく流れが現実的です。
HubSpotの中での役割は、ライフサイクルステージが基準を定義し、取引パイプラインが引き渡し情報をそろえ、ワークフローが通知と記録を起動し、Breezeが判定や下書きを補助する、と整理すると設計しやすくなります。最初からすべてを使うのではなく、自社のつまずきに合う機能を1つ選んで始め、固まった基準から順に載せていく進め方をおすすめします。
サイロ化を防ぐ組織設計のポイント
フローと仕組みを整えても、評価の仕組みや会議体が部門ごとのままだと、運用は少しずつ元に戻っていきます。ここでは、部門横断のフローを組織として支えるための3つの要素を整理します。いずれも、前の節で決めた引き渡し基準を測り、見直す場として設計します。
共通KPIの設定
部門横断プロセスの成果を測定する「共通KPI」を設定します。各部門の個別KPIに加え、全体の成果を反映するKPIを共有することで、部門間の協力を促進します。
| 共通KPI | 対象部門 | 測定内容 |
|---|---|---|
| リード→受注の転換率 | マーケ・営業 | ファネル全体の効率 |
| 受注→オンボーディング完了日数 | 営業・CS | 引き渡しのスムーズさ |
| 顧客生涯価値（LTV） | 全部門 | 顧客との長期的な関係の成果 |
| NPS（顧客推奨度） | 全部門 | 顧客体験の総合評価 |
この表は、対象部門が2つにまたがるKPIと、全部門にまたがるKPIに分かれています。最初から4つすべてを追うと測定の準備だけで止まりやすいため、前の節の見分け方で最も問題が大きかったつなぎ目に対応するKPIを1つ選ぶところから始めるのがおすすめです。マーケと営業の間が課題なら転換率、営業とCSの間が課題ならオンボーディング完了日数、というように選びます。LTVやNPSは、データが一か所に集まり、継続的に測れる状態になってから加えます。
定期的なクロスファンクショナル会議
部門横断のプロセスを運用するために、定期的なクロスファンクショナル会議を設計します。
- 週次：パイプラインレビュー（マーケ・営業・CS合同）
- 月次：KPIレビューとプロセス改善の議論
- 四半期：プロセス全体のレビューと改善計画の策定
会議ごとに扱う対象を分けておくと、議論が個別案件の報告に流れにくくなります。週次はSLAを超えた案件と差し戻された案件だけを扱い、月次は共通KPIと失注理由の集計をもとに引き渡し基準を見直し、四半期はスイムレーン図そのものを描き直すかどうかを判断する、という分け方です。資料はCRMのレポートやダッシュボードをそのまま投影する形にすると、会議のために数字を集め直す作業がなくなります。
データ基盤の統一
部門横断の業務フローを実現するためには、データ基盤の統一が欠かせません。CRMを中心に、マーケティングオートメーション・SFA・カスタマーサクセスツールのデータを一元管理する基盤を構築します。
統一の目的は、ツールの数を減らすことではなく、引き渡しポイントで受け取る側が別の場所を探しに行かなくて済むことです。そのため、統一する範囲は引き渡し基準に使う項目から決めていきます。
部門ごとのスプレッドシートにある項目をすべて移すと、使われない項目が増えて入力の負担が大きくなり、結局は元のシートに戻ってしまうことがあります。引き渡し基準・共通KPI・失注理由に使う項目を優先して移し、それ以外の項目は使われているかどうかを見てから判断することをおすすめします。
KPI・会議体・データ基盤のいずれも、自社の体制で無理なく回せる範囲から始め、運用が定着してから広げていくのが現実的です。
段階的な導入アプローチ
部門横断の業務フロー設計は、一度に全社展開するのではなく、段階を分けて進めることを推奨します。最初から全部門・全プロセスを対象にすると、合意形成の相手が増えすぎて設計が止まりやすいためです。本記事では、各フェーズの内容と次に進む目安を次のように整理します。
| フェーズ | 期間の目安 | やること | 次へ進む目安 |
|---|---|---|---|
| フェーズ1 | 1〜2ヶ月 | 売上に直結するプロセスを1本選び、スイムレーン図で可視化 | 関係部門が図の内容に合意している |
| フェーズ2 | 2〜4ヶ月 | 引き渡し基準とSLAを設定し、運用を開始 | 引き渡し日時が記録され、SLA超過を数えられる |
| フェーズ3 | 4〜6ヶ月 | CRMやMAツールで自動判定・通知の仕組みを構築 | 引き渡しが人の連絡なしで起動している |
| フェーズ4 | 6ヶ月以降 | 他のプロセスへ横展開 | ― |
期間はあくまで目安です。関係部門の人数や現在の運用状況によって前後するため、「次へ進む目安」の列を満たしているかどうかで、次のフェーズへ進むかを判断してください。
フェーズ1（1〜2ヶ月）：売上に直結するプロセスの可視化
売上に直結するプロセス（例：リード→受注→オンボーディング）を1本選び、スイムレーン図で可視化します。どれを選ぶか迷う場合は、前の節の見分け方で差し戻しやSLA超過が多いと見込まれるつなぎ目を含むプロセスを優先します。図は担当者へのヒアリングをもとに描き、実際の業務と食い違う箇所があれば、理想の流れではなく現状の流れに合わせて描き直します。現状と理想の差の扱い方は、As-Is/To-Be分析の考え方が参考になります。
フェーズ2（2〜4ヶ月）：引き渡し基準とSLAの設定
可視化したプロセスの引き渡しポイントに、具体的な基準とSLAを設定し、運用を開始します。この段階では、基準の内容をスプレッドシートや共有ドキュメントで管理していても構いません。まずは運用してみて、差し戻しの理由とSLA超過の理由を記録し、基準が現場の実態に合っているかを見ていきます。
フェーズ3（4〜6ヶ月）：データ基盤との連動
CRMやMAツールの設定を調整し、フロー図の引き渡し基準をシステム上で自動判定・通知できる仕組みを構築します。フェーズ2で運用して固まった基準だけを仕組みに載せるのがポイントです。運用で頻繁に変わっている基準を先に自動化すると、設定の修正が追いつかなくなります。
フェーズ4（6ヶ月以降）：対象プロセスの拡大
フェーズ1〜3で確立した方法論を、他のプロセス（例：採用・調達・プロジェクト管理等）に横展開します。最初のプロセスで作ったRACIやSLAの書式、会議体の運び方をそのまま使えるため、2本目以降は立ち上がりが早くなります。
1本のプロセスで小さく始め、固まった型を次のプロセスへ広げる。この繰り返しが、全社の部門横断フローを無理なく育てる進め方です。
部門横断フロー設計でつまずきやすい点と限界
部門横断のフロー設計は、進め方を誤ると現場の負担だけが増えて定着しないことがあります。ここでは、設計段階で起こりやすいつまずきと、仕組みだけでは解決しない領域を率直に整理します。自社の状況に当てはまるものがあれば、先に手当てしておくことをおすすめします。
| つまずき | 手当ての方向 |
|---|---|
| 基準や入力項目を作り込みすぎる | 受け取る側が「これがないと次の作業に入れない」項目だけを必須にする |
| ツールを入れれば連携が進むと考えてしまう | フローと基準を決め、運用で固め、仕組みに載せる |
| 仕組みだけでは解消しない領域 | 仕組みで解決できる範囲から小さく始め、評価や予算は経営層と議論する |
基準や入力項目を作り込みすぎる
引き渡し基準を厳密にしようとするほど、確認する条件や入力する項目が増えていきます。項目が多いと入力が後回しになり、結果として基準が使われなくなります。各引き渡しポイントでは、受け取る側が「これがないと次の作業に入れない」項目だけを必須にし、それ以外は任意にしておくと集中しやすくなります。項目を追加・変更できる人を管理者に限っておくと、部門ごとに項目が増えていくのを防げます。
ツールを入れれば連携が進むと考えてしまう
データ基盤を統一しても、引き渡し基準や責任者が決まっていなければ、同じ画面を見ながら部門同士が別の解釈をするだけになります。順番としては、フローと基準を決め、運用で固め、仕組みに載せる流れをおすすめします。ツールの選定や設定から入ってしまった場合は、いったんスイムレーン図に戻り、つなぎ目ごとの基準を埋め直すところから再開してください。
仕組みだけでは解消しない領域
評価制度や予算配分が部門単位のままだと、共通KPIを置いても優先度は自部門のKPIに傾きます。これはフロー設計やCRMの設定だけでは解消できない、組織の意思決定の問題です。共通KPIを導入する際は、部門長の評価の中に共通KPIをどう反映するかを経営層と合わせて決めておくと、現場の優先順位が揃いやすくなります。
どこまでを仕組みで解決し、どこからを組織の意思決定に委ねるかは、自社の体制によって変わります。まずは仕組みで解決できる範囲から小さく始め、その結果を材料に、経営層と評価や予算の議論へ広げてください。
よくある質問
Q1. サイロ化が発生する根本原因は何ですか？
主に3つの要因があります。①部門ごとにKPI・予算・評価が設定される構造的要因、②部門間の引き渡し基準が曖昧なプロセス的要因、③部門ごとに異なるツールを使用することによるデータの分断です。特に部門間の「つなぎ目」のプロセスは誰のKPIにも含まれないため放置されがちで、複数の要因が当てはまる場合は引き渡し基準の整備から着手するのが進めやすい順番です。
Q2. 部門横断プロセスの設計にはどのような手法を使いますか？
3つの手法を組み合わせます。スイムレーンダイアグラムで各部門の業務と引き渡しポイントを可視化し、RACIマトリクスで各タスクの実行責任者・最終責任者・相談先・報告先を明確にし、内部SLAで部門間の引き渡しスピードの基準を設定します。スイムレーン図の引き渡しポイントを行にしてRACIとSLAを書き込むと、つなぎ目ごとの責任と期限が一覧になります。
Q3. 段階的な導入はどのように進めればよいですか？
4フェーズで進めます。フェーズ1（1〜2ヶ月）で売上に直結するプロセスを1本選びスイムレーン図で可視化、フェーズ2（2〜4ヶ月）で引き渡し基準とSLAを設定して運用開始、フェーズ3（4〜6ヶ月）でCRM・MAツールと連動した自動判定・通知の仕組みを構築、フェーズ4（6ヶ月以降）で他プロセスへ横展開します。運用で固まった基準だけを自動化に載せると、設定の修正に追われにくくなります。
Q4. 部門ごとに別のツールを使い続けたまま、部門横断のフローは作れますか？
フロー図・RACI・SLAの設計自体は、ツールが分かれていても進められます。ただし、引き渡しのたびに情報を転記する手作業が残るため、漏れや食い違いが起きやすい状態は続きます。まずは引き渡し基準に使う項目だけでも一か所に集め、受け取る側が別のツールを探しに行かなくて済む範囲から統一していくことをおすすめします。
Q5. 内部SLAを設定しても守られない場合はどうすればよいですか？
SLAを超えた案件だけを抜き出し、理由を「基準が曖昧で判断に迷った」「人手が足りなかった」などに分けて記録してください。基準の曖昧さが多ければ引き渡し基準を見直し、人手不足が多ければ担当の割り振りやSLAの水準そのものを見直します。超過の理由を記録しないまま期限だけを締め直すと、形だけのSLAになりやすくなります。
まとめ
部門横断の業務フロー設計は、サイロ化を解消し、組織全体の生産性と顧客体験を向上させるための土台です。最適な形は企業ごとに異なるため、自社の条件で選び、小さく始めて広げる進め方をおすすめします。
- サイロ化が起きる3つのメカニズムは「部門最適化のインセンティブ構造」「引き渡し基準の曖昧さ」「データの分断」で、症状から主な要因を見分けて着手対象を絞ります
- スイムレーン・RACI・内部SLAの組み合わせで、部門横断プロセスの流れ・責任・期限を設計します
- マーケ→営業→CSの一気通貫フローでは、各ステージの引き渡し基準と共有すべき情報を定義し、失注・解約から最初のステージへ戻るループまで含めます
- 引き渡し基準はCRM（ライフサイクルステージ・取引パイプライン・ワークフロー）に載せ、担当者が替わっても回る仕組みにします
- 共通KPI（転換率・LTV・NPS等）を設定し、全社一斉ではなく売上に直結する1本のプロセスから段階的に設計・導入します
まずは、売上に直結するプロセスを1本選び、部門をまたぐ引き渡しポイントを書き出すところから始めてみてください。次の3ステップで進めると、議論が具体的になります。
- 選んだプロセスをスイムレーン図に描き、レーンをまたぐ矢印に「条件・期限・渡す情報」を書き込む
- 空欄が残った矢印について、受け取る側の部門と引き渡し基準・RACI・SLAを決める
- 一定期間運用して差し戻しとSLA超過の理由を記録し、固まった基準からCRMの項目とワークフローに載せる
部門間の壁は一朝一夕には解消できませんが、プロセスの可視化と引き渡し基準の明確化から始めることで、着実に改善を進めることができます。組織全体のワークフロー設計について体系的に学びたい方はワークフロー設計の基本を、業務改革の全体像を把握したい方はBPR（業務プロセス改革）の進め方もあわせてご覧ください。部門横断の改善を現場に定着させる変革推進の方法はチェンジマネジメントの実践で詳しく解説しています。
DX推進の全体像についてはDX完全ガイドで基礎から実践まで体系的に解説しています。
CRMを活用した業務効率化やAIとの連携に関するご相談は、StartLinkまでお気軽にお問い合わせください。
あわせて読みたい
記事の内容を、そのまま実務に落とし込みたい方向け
HubSpotゴールドパートナーのStartLinkが、HubSpot導入・AI活用・CRM整備・業務効率化までをまとめて支援しています。記事で気になったテーマを、そのまま相談ベースで整理できます。
次に読む
株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化（ERP/CRM/SFA/MAの導入）」などのご相談を受け付けております。 サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。
著者情報
