【完全ガイド】desknet’s NEO・サイボウズ Office・Garoon オンプレ から クラウド型グループウェアへの移行戦略

本記事は、Garoon／サイボウズオフィス／desknet’s NEO／Notes 系自社グループウェアを10〜20年使ってきた中堅大企業（500〜10,000名）で、「次の社内コラボ基盤をどうするか」を経営に答える情シス部長／総務部長を読者として書きました。Teams／Slack／Zoom／M365／Google Workspace の浸透で社内情報共有が分散し、グループウェアにワークフローと掲示板だけが残っている現状を、機能分解設計で再整理します。

1. 「グループウェア継続なのに見直し議論が出る」5つの理由

Garoon／サイボウズ Office／desknet’s NEO は継続提供されており、機能・サポートに大きな問題があるわけではありません。それでも次の3年で動く議論が出る理由は次の5つ。

① コミュニケーション中心がチャット（Teams／Slack）に移った。掲示板の利用率が低下。
② ワークフローはBPM／kintone／Power Automate に分化。
③ ファイルは SharePoint／Drive／Box に分化。
④ モバイル中心のUX。在宅・モバイル前提の業務。
⑤ 海外拠点との統一。Garoon／desknet’s は日本中心、海外は M365／Google が標準。

2. 「機能を分解して各SaaSに割り当てる」発想が本質

移行の本質は「グループウェアの機能を分解して、各機能を最適なSaaSに割り当てる」です。1製品で全部置き換えるのではなく、機能別に最適配置します。

3. 移行候補の組み合わせパターン

4. ワークフロー（申請・回覧）をどう移すか（最大の難所）

移行の最大の難所はワークフローです。グループウェア時代に作り込まれた数百〜数千のフローを、新システムでどう実装するか。選択肢は次のとおり。

5. ワークフローの棚卸しと統廃合（必須）

移行前に必ず、稼働中ワークフローの棚卸しを行い、使われていないフローを廃止します。グループウェアには「作ったが半年使われていないフロー」が必ず多数あります。

棚卸しで集める情報：
・フロー名／作成者／作成日
・直近12カ月の起案件数
・承認者数・承認段数
・関連部門・対象人数
・廃止判定（起案件数ゼロ／同義フロー存在／業務廃止済）

経験上、500本のワークフローのうち200〜300本は廃止可能です。残ったフローも統廃合により、最終的に100〜200本に集約できることが多いです。「全部移行」を目指すと費用も運用負荷も爆発します。

6. メール／カレンダー移行の現実

メール／カレンダーは選択肢が成熟しており、技術的には大きな論点になりませんが、「移行ツール」と「カレンダーの繰り返し予定」の2点は必ず詰まります。

・M365 への移行ツール：純正コネクタ／Quest On Demand／BitTitan MigrationWiz／CloudM
・Google への移行ツール：Google Workspace Migration for Microsoft Exchange／BitTitan
・カレンダー繰り返し予定の例外日付はパイロット部門で必ず検証
・会議室予約のリソースカレンダーは Outlook／Google Calendar のリソース予約機能で再現

7. 掲示板・社内ポータルの再設計

掲示板・社内ポータルは、次の選択肢で再現します。

・SharePoint コミュニケーションサイト：M365統合・Power Platform 拡張
・Confluence：開発文化との親和性・WIKI 中心
・Notion：UX・モバイル親和・スタートアップ系で人気
・Google Sites：Google Workspace 統合・シンプル

情報設計（誰が／何を／いつ書くか）を再定義し、トップページを「読まれる構造」に作り直します。グループウェア時代の「全部署が書き込んだ無秩序な掲示板」を、移行を機に整理する好機です。

8. ID基盤・SSO・権限の刷新が裏の本丸

グループウェア時代は「グループウェアIDが社内ID」になっていたケースが多く、移行を機に Microsoft Entra ID または Google Identity を中心に再設計します。

具体的にやること：
・Entra ID または Google Identity を Master とした SSO 確立
・全SaaS（M365／kintone／Salesforce／勤怠／経費）を SAML/OIDC で連携
・条件付きアクセス（端末準拠・場所・リスクレベル）と MFA の必須化
・退職者プロビジョニング自動化（人事システム → SCIM → 各SaaS）

ID基盤を後回しにすると、グループウェア時代の権限の混乱がそのままSaaS群に持ち込まれます。ID基盤刷新を移行プロジェクトの第1フェーズに置くことを強く推奨します。

9. プロジェクト期間の典型値（500〜2,000名規模）

10. 3年TCOの実数試算（1,000名規模）

11. 失敗事例から逆算する「やってはいけない3つ」

① 「全機能を1製品で置き換える」を狙って破綻。Garoon の機能を全部 SharePoint で再現しようとして、施設予約・ワークフロー・掲示板で UI 不満が連発し、移行が止まる。
② ワークフロー棚卸しを省略して全フロー再現を試みる。500本のフローを全部移行する計画で予算化し、3年経っても完了せず、結果的にグループウェアと新基盤の二重運用が続く。
③ メール・チャットだけ移行してグループウェアが残り続ける。M365への移行は完了したが、ワークフロー・掲示板・施設予約のためにGaroon を継続契約し、二重コストが固定化。

12. 来期予算化までに、いま動かす3アクション

① ワークフロー棚卸しを総務／情シス主導で開始する。直近12カ月の起案件数を集計するだけで、廃止候補が見えます。
② 機能分解設計の方針を経営と握る。「グループウェア1製品で全部置き換える」を諦めることが、議論を進める第一歩。
③ ID基盤刷新の独立プロジェクト化を提案する。脱グループウェア本体の前段階として Entra／Google Identity 整備を半年〜1年先行させると、後続が一気に楽になります。

グループウェア移行の今後3年は、「機能を分解して各SaaSに割り当てる設計」がゴールです。1製品置き換え発想を捨て、ワークフロー統廃合とID基盤刷新を最優先することが、議論の質を決めます。