「社内に置いてあるグループウェアのサーバーが古くなってきて、保守も来年で切れると言われた。この機会にクラウドへ移したいが、何をどう移せばいいのか見当がつかない」——最近、こうした相談が増えています。加えて「営業先やスマホから予定表が見られない」「若い社員から画面が古くて使いにくいと言われる」といった不満も、乗り換えを後押しする典型的な症状です。長年使ってきたサイボウズ Office のパッケージ版や desknet’s NEO、あるいは社内サーバーに載せた独自のメール・グループウェアは、確かにそろそろ潮時を迎えつつあります。
実際、パッケージ版「サイボウズ Office」は 2027 年 9 月 30 日でサポートが終了する予定で、ライセンスの有効期限によってはそれより前に使えなくなる企業が大半です。保守が切れれば脆弱性の修正も止まるため、「まだ動くから」と先延ばしにできる話ではありません。移行先として Google Workspace は有力な選択肢ですが、ここで一つ、最初に知っておくべき前提があります。メールや予定表のような「対応関係が作りやすいもの」と、掲示板や稟議のように「そのままの形では移らないもの」が、はっきり分かれるということです。この切り分けを曖昧にしたまま進めると、移行の途中で必ず行き詰まります。
きれいに移るもの、そのままでは移らないもの
まず、旧グループウェアの機能を「移しやすさ」で二つに仕分けします。ここを最初に押さえておくと、移行計画の全体像がぐっと見通しやすくなります。
移しやすいのは、メール・予定表・アドレス帳・ファイルです。これらは Google Workspace 側に Gmail・Google カレンダー・連絡先・Google ドライブという明確な受け皿があり、データの対応関係を作れます。日常業務の中心がこの四つである以上、ここが移せる意味は大きい。Microsoft 365 からの乗り換えであれば管理コンソール標準の移行ツールも整ってきており、その勘所はMicrosoft 365 から Google Workspace への移行を扱った記事にまとめています。
一方、そのままの形では移らないのが、掲示板・独自ワークフロー（稟議・各種申請）・カスタム業務アプリ・独自データベースです。国産グループウェアはこの領域を作り込んで「一つの箱にすべてが入っている」状態にしているため、社内の業務がその独自機能に深く依存していることが少なくありません。Google Workspace にはこれらに 1:1 で対応する機能がなく、移行ではなく再設計が必要になります。ここを「移行ツールで何とかなるはず」と見込んでしまうのが、最も多い誤算です。
移行データの急所は、メールとカレンダーの細部にある
移しやすいはずのメール・予定表にも、実際に手を動かすと事故が起きる急所があります。
過去メールの移行は、旧サーバーが IMAP に対応していれば Google の新しいデータ移行サービスで取り込めます。管理者が IMAP サーバーと Workspace を接続し、ユーザーごとのメールアドレスとパスワードを CSV で指定して一括インポートする方式で、一度に最大 100 ユーザーまで処理できます。ただし IMAP を無効にしている旧環境や、独自形式でしかエクスポートできないグループウェアの場合は、この標準ルートが使えず、別途エクスポート・変換の手当てが要ります。
取り込みの際に問題になりやすいのが、文字化け・添付ファイルの欠落・フォルダ構造の崩れです。国産グループウェア特有の深いフォルダ階層や「要返信」などの独自フラグは、Google 側にそのまま再現されず、移行後にラベルで組み直す前提で考えたほうが安全です。予定表も、繰り返し予定（毎週の定例など）や施設予約が正しく移らないことがあり、テスト移行で必ず現物を確認します。そして忘れられがちなのが権限の作り直しです。旧環境の「この部署だけ見られる」といったアクセス制御は移行データに含まれないため、Google ドライブの共有設定として一から設計し直します。こうしたデータ移行そのものの難所は、グループウェアに限らず共通する論点で、業務システムのデータ移行を扱った記事の観点がそのまま効いてきます。
「移らない機能」をどう置き換えるか
本題は、1:1 で移らない掲示板・ワークフロー・業務アプリの置き換えです。ここには大きく三つの選択肢があり、機能の複雑さで使い分けます。
一つ目が、Google Workspace の標準機能で代替する道です。掲示板やチーム連絡は Google チャットの「スペース」に、稟議・申請は Google ドキュメント/スプレッドシートの承認機能や、Google フォームを受付窓口・スプレッドシートを台帳とする組み合わせに置き換えられます。標準の承認機能は Business Standard 以上のプランで追加費用なく使えます。費用をかけずに済むのが利点ですが、複雑な条件分岐や部署階層をまたぐ多段承認には向きません。
二つ目が、AppSheet などのノーコードで作り直す道です。独自データベースや簡易な業務アプリは、スプレッドシートを土台にノーコードで再構築でき、スマホ対応も同時に実現できます。標準機能では窮屈だが本格開発までは要らない、という中間の要件に合います。具体的な作り方はAppSheet で業務アプリを作る記事を参照してください。
三つ目が、受託でカスタム開発する道です。複雑な条件分岐を伴う稟議、基幹システムとの連携、独自の帳票出力など、標準機能でもノーコードでも表現しきれないものは、要件に合わせて作り込みます。
| 置き換え先 | 向いている機能 | 主な制約 |
|---|---|---|
| 標準機能（スペース/承認/フォーム） | 掲示板、単純な申請・稟議 | 複雑な条件分岐・多段承認は苦手 |
| AppSheet（ノーコード） | 独自DB、簡易業務アプリ | 高度な外部連携・複雑処理は限界 |
| 受託カスタム開発 | 多段稟議、基幹連携、独自帳票 | 要件により費用・期間が変わる |
現実には、この三つを組み合わせるのが定石です。「掲示板はスペースへ、経費申請はフォームと承認へ、複雑な稟議だけは作り込む」というように、機能ごとに最適な置き換え先を割り当てます。なお受託開発の費用は要件によって大きく変わるため、金額は個別のお見積りになります。
進め方は、棚卸しと対応表づくりから
置き換え先が見えたら、進め方は次の流れが確実です。
出発点は現状の棚卸しです。旧グループウェアのどの機能を、誰が、どう使っているかを一覧にします。ここで「実はほとんど使われていない掲示板」や「特定の人しか触らない申請」が見つかることも多く、移行のついでに業務そのものを整理できます。次に、棚卸しをもとに機能ごとの対応表を作ります。メールは Gmail へ、稟議は承認機能へ、独自アプリは AppSheet へ、といった「移行先の設計図」です。この対応表がないまま手を動かすと、移行の途中で「これはどこへ移すのか」が毎回止まって進みません。
その後は、いきなり全面切替はせず、旧環境と Google Workspace を並行運用しながら、部署ごと・機能ごとに段階移行します。最後に見落とされがちなのがユーザー教育で、画面が変わる以上、操作研修と質問窓口を用意しないと現場が旧環境に戻ってしまいます。Google Workspace 側の初期設定そのものに不安があれば、Google Workspace 導入ガイドを先に押さえておくと足元が固まります。
落とし穴も明確です。一斉切替の事故（並行運用を省いて全社を一度に移し、問題が全社に波及する）、旧データの保全漏れ（移らない掲示板の過去ログをアーカイブせず捨ててしまう）、教育不足（使い方が浸透せず定着しない）——この三つが失敗の典型です。まず着手すべきは、旧グループウェアの機能棚卸しと、「メールは必須／掲示板は閲覧用アーカイブで十分」といった優先順位づけの二つ。ここが決まれば、移行の設計は自ずと動き出します。
グリームハブは、Google Workspace の導入・活用支援と、標準機能で足りない業務のノーコード化・受託開発の両面に取り組んできました。「国産グループウェアの保守終了が近いが何から手をつければいいか分からない」「掲示板や稟議をどう置き換えればいいか判断できない」——そうしたお悩みがあれば、Google Workspace・IT活用のご相談窓口からお気軽にどうぞ。現状の機能棚卸しから移行先の対応表づくり、置き換えの設計と定着までをご一緒に進めます。
Sources
- 新しいデータ移行サービスについて － Google Workspace 管理者 ヘルプ
- IMAP アカウントからメールを移行する － Google Workspace 管理者 ヘルプ
- 一般提供開始: Google Workspace、Gmail、その他の IMAP 対応メールサーバーからユーザーのメールを移行 － Google Workspace Updates
- 承認機能を管理する － Google Workspace 管理者 ヘルプ
- パッケージ版「サイボウズ Office」販売・サポート終了のお知らせ － サイボウズ
- Google Workspaceで承認フローを作成する方法 標準機能でできること・できないこと － Gluegent
