Google Workspace移行で最初に決めるべきは、
役職ごとの使い分け設計

1. 「全社員に同じツールを配る」が、ほぼ確実に詰まる

地場産業のクラウド移行プロジェクトで、最初の打ち手として議論されるのが「どのツールを入れるか」です。Microsoft 365からGoogle Workspaceへの移行、Slack導入、LINE WORKS導入。ベンダー比較・コスト比較に時間を使い、プランを決め、契約に進む。よくある流れです。

ただ、半年後に現場を覗くと、想定通りに使われていないことが多くあります。経営層はSlackもLINE WORKSもログインしなくなっている。一般社員はメール（外部宛）以外Gmailを使っていない。店舗の現場はLINE WORKS上で連絡をしているが、誰がいつ何を言ったかが記録されていない。「全社員に同じツールを配る」設計は、3ヶ月で形骸化するのが典型パターンです。

2. その問題が起きる構造

原因は、ツールではなく「役職ごとに見るべき情報の粒度が違う」ことを設計に落とし込んでいないことです。

経営層が見るべきは、部門横断のPJ進捗・経営判断・リスク。部長層が見るべきは、担当事業のKPI・現場からの一次情報・経営層への報告。一般社員が見るべきは、日々のタスクと業務依頼。店舗・現場が見るべきは、緊急連絡と本部からの指示。これらをひとつのツールに混ぜると、誰も全部を追えなくなる。結果として、経営層は通知を切り、現場は元の電話・口頭・紙運用に戻ります。

もうひとつの落とし穴は、「会話の場所」と「記録の場所」が分かれていないことです。SlackやLINE WORKSは、流れるチャットです。重要な決定事項や進捗をそこに置いたままだと、3ヶ月後に検索しても出てこない。だから、会話はチャット、記録はGoogle Workspace（ドライブ・ドキュメント・スプレッドシート）と、明確に分ける必要があります。

3. 経営者が判断すべき論点

クラウド移行を成功させるために、契約前に決めるべきは次の3つです。

• 役職ごとに、どのツールで・どの情報を扱うかの設計図
• 会話の場所（チャット）と記録の場所（GWS）の切り分けルール
• 役職をまたいだ情報の橋渡し責任を、誰が担うか

この3つを決めずに進めると、移行直後の数週間は新ツールで盛り上がりますが、3ヶ月以内に「結局メールと電話に戻った」状態になります。ツール選定は、設計図が固まったあとの工程です。

4. 現場で実行するための具体策

Step 01役職ごとの「見るべき情報」を1ページに整理する

経営層・部長・一般社員・店舗/現場の4階層で、それぞれが「日々見るべき情報」「週次で見るべき情報」「月次で見るべき情報」を書き出します。粒度は具体的に。経営層なら「事業別の粗利・受注速報・部門横断PJの遅延」、部長なら「担当事業のKPI・現場日報・経営層への報告議題」、というレベル。

Step 02役職別にツールを割り当てる

経営層・部長層は Slack（経営判断・PJ進捗・部門横断連携）、一般社員・店舗/現場は LINE WORKS（日常連絡・業務依頼・緊急共有）、全社共通の記録基盤は Google Workspace（メール・カレンダー・ドキュメント・ドライブ・PJ管理シート）。この3層構造が、地場産業の中堅企業では機能しやすい組み合わせです。

Step 03会話と記録の切り分けルールを明文化する

チャットに残っているだけの情報は、3ヶ月後には存在しないのと同じです。「決定事項・タスク・期限・担当・進捗は、必ずGWS上のPJ管理シートに反映する」を社内ルールにします。チャットでの会話のうち、記録すべきものを誰がどのタイミングで転記するかを決めます。

Step 04部長層に「橋渡し責任」を置く

この設計は、部長層の運用次第で機能するかが決まります。部長は、Slack上の経営判断を LINE WORKS で現場に落とし、現場からの一次情報を Slack で経営層に上げます。同時に、PJ管理シートを更新する責任を持ちます。「橋渡し責任」を部長のミッションとして明文化することで、移行が運用に乗ります。

Step 05移行スケジュールに「トライアル・説明・規定整備」を入れる

ベンダーの納期だけ見て契約すると、社内側の準備が抜けます。スケジュールに必ず入れるべきは、（1）部長層以上の2週間トライアル、（2）全社員向けキックオフ説明会、（3）利用規定（セキュリティ・社外共有・退職時の処理）の整備、（4）管理部の統合システム移行との連動。本格運用開始は、これら4つが揃ってから設定します。

5. 失敗しやすい落とし穴

• 「アカウントは全員に配る」から始める。一般社員・現場で年間数十万円のライセンスが死蔵されます。役職別の設計を先にやれば、必要なアカウント数も明確になります。
• SlackもLINE WORKSも「とりあえず全員入れる」。両方使う人は、結局どちらも開かなくなります。役職別に主ツールを1つに絞ることが大事です。
• 「ツール導入＝DX完了」と勘違いする。移行は始まりです。3ヶ月後・6ヶ月後の運用定着レビューを最初から設計しないと、半年後にExcelに戻っています。
• 外部取引先の都合を後回しにする。Microsoft Teamsで会議をしてくる取引先は必ず残ります。例外運用ルール（Teams会議だけ個別対応など）を最初に決めておきます。

6. eapとしてどう支援するか

eapがクラウド移行に入るときは、ベンダー選定の前に「役職ごとの情報設計」のワークショップから始めます。経営者・部長・現場リーダーを集め、それぞれが何を見たいか・どう動きたいかを2週間で言語化します。そのうえで、役職別のツール割り当てと、会話／記録の切り分けルール、橋渡し責任の設計を進めます。

ベンダー選定はその後です。Google Workspace / Microsoft 365 / Slack / LINE WORKS / Notion など、選択肢ごとの強みは設計図に合わせて評価します。実装段階では、必要に応じてRuffnoteと連携し、PJ管理シートの自動化やGAS連携、社内独自の業務システム連結まで巻き取ります。

ツールは、設計図に乗せるもの。設計図がないままツールから入ると、3ヶ月で形骸化します。