Google Workspaceを新規に導入する時に押さえたいポイント
組織で初めてGoogle Workspaceを導入しようとなると何から始めたらよいのか？何をしなければならないのか？といったことで迷う点がたくさんあります。さらにMicrosoft365から移行するとなると新規導入よりも考慮しなければならないポイントが増えることになります。
今回は新規にGoogle Workspaceを導入する場合に押さえておきたいポイントをまとめてみました。Microsoft365からの移行についてはまた改めてまとめのページを作成したいと思います。とりわけ、今回の事例ではドメインをホストしてるケースがさくらインターネットの場合を想定しています（既に企業として独自ドメインを取得してることが前提です）。
目次
利用するサービスやツール
今回のエントリーはデータ類の移行と言うよりは、Google Workspaceの導入に伴う情シス側で要求される設定周りや社内メンバーに対する対応策などが中心です。大きく仕事のスタイルや使うツールが変更になるのでここをガッチリ組んでおかないと社内で大きな障害につながり、情シスに対する負荷が急上昇することにもなります。
注意点
はじめてGoogle Workspaceを導入するといっても、これまでの業務やシステムが存在しており、それらを停止して作業するというわけにはいきません。必ず並行稼働期間というものを設けて、尚且つエンドユーザに周知・トレーニングといった十分な時間を用意しなければ混乱をもたらし、場合によっては情報漏洩といったようなトラブルが生じるかもしれません。
主に配慮しなければならないシステムは以下の通りです。利用頻度の高い順に列挙してみました。
- メールサーバ（個々のメールボックスや転送設定）
- ファイルサーバ（ローカルに置いてあるNASなど）
- グループアドレスやカレンダーデータ
- VBAなどを使ったMicrosoft Officeファイルの有無
- 組織の共有連絡先データ
- 社内掲示板などのポータルサイト
とりわけ、メールとファイルサーバが大きな仕事になる点で、混乱が生じる可能性が高い要素になります。実際のメールデータ、NASのファイル、カレンダー等の移管作業については以下のエントリーを参考に計画的に実施しましょう。
Google Workspace契約時
ドメインについて
プライマリドメイン
スタートアップや初期導入時にはあまり考えずに決めてるであろう「プライマリドメイン」。会社で1個しかドメインないし、そのまま契約すればいいやというのはその通りなのですが、これが追々苦しめるケースがあります。会社が成長してホールディングス化したので、新たにドメインを取り、ホールディングスドメインをプライマリにして、これまでのドメインをセカンダリにしたいといったケース。
これめちゃくちゃ大変です。特にSAML認証やら色々と連携してる場合は、それらを全て洗い出してゼロからやり直しと検証が必要です。また、既存のプライマリでアカウントを作ってるので、これを異動するということは共有ドライブのグループアドレス付け替えや個々人のメールボックス、そもそものグループアドレスの作り直しなどなど。
殆どテナント間異動と変わらない大プロジェクトになるため、手軽にプライマリドメインを変更出来るとは思ってはいけません。
複数テナント
実際に運用してたことがありますが、検証用として別のドメインで別のテナントとして運用をするケースがあります。例えばメインのテナントは300名超えでEnterprise Standardを利用しており、検証用はBusiness Starterを利用していたケース。なぜそんなことをするかといったら、一番の理由はコスト。また同一テナント内でプランを同居できないのも理由の１つ。
また、社員にはEnterprise Standardを使わせて、業務委託の人はBusiness Starterで区別し、ホワイトリストを用いて共有ドライブにアクセスさせるといった運用もあるでしょう。
きちんと理解して割り切ってこの手法を取ってる場合には合理的と言えます。特に病院のような施設ではない場合、Frontlineプランは利用出来ませんので、フル機能のEnterprise Standardはコスト的にも機能的にもオーバースペックです。
問題は、あとあとこのテナントを統合したいとなった場合、前述のプライマリドメイン統合と同じくらい大変な作業になります。故にあとからフラフラと「実は統合したい」なんて考えを実行すればいいやという考えはかなり甘い考えなので、導入前からよくよく考えて実行したほうが良いです。情シスリソースが無い組織なのに、手軽に移動できると考えてはいけません。
申し込みについて
契約先を選ぶ
個人事業主や数名程度の組織であるならば、Googleのサイト上から直接契約でも良いでしょう。しかしパートナー企業経由で導入するという手段もあります。パートナー企業経由で導入するメリットとしては
- クレジットカード払いだけじゃなく請求書払いを選択することが可能（口座振込や引き落としで処理が出来る）。但し1年単位の支払いになります。
- 有償で導入の手助けをしてくれる
- 様々な導入後のサポートや情報を受けることが可能になる
- パートナー契約ではディスカウントを受けられる可能性がある
もちろんGoogle直契約でも領収書はインボイス対応しているのでバッチリです。10名以上の利用が予定されてる企業ならば断然パートナー企業経由で導入したほうが先々を考えればお得です。
国内の有名どころのGoogle Workspaceパートナー企業としては、電算システム・吉積情報・サテライトオフィスなどの会社があります。
契約プランを決める
ここが悩みどころの１つです。Google WorkspaceやMicrosoft365はプランによって利用できるユーザに上限が設けられています。その閾値が300名。また、利用するサービス内容によってもプランが枝分かれしてくことになります。ポピュラーなプラン選択ですと以下のようになります。本エントリーはこのポピュラーなプランの導入を前提に話を進めます。
- 300名以下ならばBusiness Starter、Business Standard、Business Standard Plusが選択可能
- 300名以上の場合は、Enterprise Standard、Enterprise Plusを選択することになる
直接契約の場合は、Business StarterとBusiness Standardについてはプロモコード(初年度10%割引)がありますので、こちらのフォームから送っていただければ発行することが可能です。支払時に適用することで割引となります。
また、特定のサービスを利用しないという形で使えるものとしてEssentialというプランがあります。但しこちらは、初めて導入する時にだけ選択可能で、跡から他のプランから変更は出来ません。またGmailの機能がありません。プラン比較や契約する上での制約・比較はこちらのページ。
さらに、デスクワークではないユーザ向けという特殊なプランがあり、それがFrontlineプラン。Google Workspaceは1つのテナント内で複数のプランを混在させることは出来ません。が、このFrontlineは別として混在が可能のようです。例えば病院のような組織で医療事務やバックオフィスについては通常のプランを選択し、現場の看護師さんや介護士さんなどの方々はFrontlineを適用することで、コストを大幅に低減させることが可能な上、Frontlineは人数制限がありません。
その分1ユーザ辺りのディスク容量が5GB程度と低く、またデスクワークユーザに適用できず、契約はパートナー企業経由のみとなっています。
※さらにGmailとChat無し、カレンダー無し、共有ドライブ制約有り、無償版と有償版の2つがあるCloud Identityという特殊なものもあります。
直接契約で申し込む場合
ドメインの所有権の証明
パートナー経由の場合には、パートナーの手助けを得ながら進めることが出来ますが、Google直接契約の場合は担当者が色々と整備を進めていかなければなりません。その最初の一歩が直接契約で申し込む手順です。並行稼働が必須要件であるため、ここでは注意点があります。
- こちらのページからまずはプランを選択し、今すぐはじめるをクリックする（この段階では14日間の体験版）
- 会社名や人数、担当者の名前とメアド、そして、会社所有のドメインで利用するよう進める
- ドメイン名入力画面では実際にGoogle Workspaceで利用するドメインを入力する
- 無事に完了し、管理コンソールへログインする
- 初回ログイン時のみ「Gmailを有効化」といったような画面が出ますがスルーします。メールはまだ移行しない為です。
- 左上のサイドバーのメニューからアカウント⇒ドメイン⇒ドメインの管理を開く
- 登録した企業ドメイン横の「ドメインの所有権を証明」をクリックする
- 確認レコードを追加という画面が出るので、出てきた文字列をコピーします。
- さくらのドメイン管理から対象ドメインのゾーン編集画面に入る
- 編集をクリックする
- 以下の設定でレコードを追加する
123エントリ名：@タイプ：TXTデータ：ダブルコーテーションでくくった、コピーしておいた値
コピーした値は、"google-site-verification=xxxxxx"といった値で入力することになります。 - 再度、6.の画面に戻ります。
- ドメイン所有権証明が完了していれば、続いて「Gmailを有効にする」をここでクリックします。ただし、「MX レコードの設定をスキップ」をクリックして進める必要があります。
このドメインの所有権の証明はセカンダリドメイン追加などでも同様に行う作業なので、複数ドメインを使い分ける場合には同じ作業が必要です。
図：ドメイン所有権はDNSで行う
支払い方法をセットする
体験版のままでは14日後に利用不可能になってしまいます。そこで、以下の手順で支払い手段を登録しておきましょう。
- 管理コンソールの左サイドバーから、お支払い⇒お支払いアカウントを表示する
- 目的のプランの横にあるお支払い方法を表示をクリック
- お支払い方法を追加をクリックする
- クレジットカード番号を登録して保存する
カード払いではなく請求書払いや銀行振込等にしたい場合は、パートナー経由で契約する必要があります。移行様々なサブスクの追加後の支払いはこのカードから支払いが行われます。
図：支払い方法はカードのみ
組織部門の作成
Google Workspaceの各種設定は１本ではなく、作成しておいた組織部門ごとに区別してオンオフが可能になっています。しかし、組織の人数が少ない場合は組織部門を作成せずに、ルートの組織（ドメイン直下）にすべてのメンバーを所属させてしまっても良いでしょう。
しかし、主に以下のような理由により組織部門はいずれ必要になってきます。人数が増える可能性や特定の利用目的が生まれるであろう場合には、予め作成しておいて、各組織部門にユーザを所属させるようにしましょう（ユーザは１つの組織部門にしか所属出来ません）。
- 部やチームごとにドライブの外部共有のオンオフを制御したい
- 特定組織部門にだけ特定のアプリの使用を許可したい
- 他の組織部門メンバーを連絡先一覧に表示・非表示をコントロールしたい
また、組織部門単位ではなくグループアドレス単位で、上記のオンオフも設定することが可能です。組織全体ではオフでも特定のグループアドレスメンバーにだけ許可をしたい場合には、設定グループを用意してコントロールも良いでしょう（設定グループのほうが組織部門設定よりも優先されます）
図：色々テストするために自分は分けてます
ユーザアカウントの作成
ライセンス枠の確保
パートナー経由の場合にはこの段階ですでに必要人数分のライセンス契約が終わっていると思いますが、直接契約の場合１名分（管理者のみ）の状態だと思います。その場合は、サブスクリプションのページから必要分を事前に購入しておく必要があります。でなければ、Cloud Identity Freeでしかユーザにライセンス割り当てが出来ません。
- 左サイドバーからお支払い⇒サブスクリプションを開く
- 対象のGoogle Workspaceプランをクリックする
- プランの詳細にある「さらに購入」をクリックして必要な分だけライセンス枠を購入しておく
- プランのアップグレードもここから行えます。
ライセンスはユーザ作成時にデフォルトでは自動割り当てされます。また、ユーザを削除するとその分だけライセンス枠が余るので別のユーザを作成してすぐに割り当てが可能です。
図：枠がないとアカウントを作れない
メールアドレス命名規則
これも新規導入時よりも追々問題になる課題です。これまでのメールボックスを移行するにせよ新しく設定して配布するにせよ、メールアドレス命名規則はよく考えて設定しなければなりません。理由は
- 同姓同名や同じ読み方をする人の存在
- ビジネスネームの存在（結婚してるけれど氏名は旧姓にしたいなど）
- グループアドレスでも同様のことが起きる
例えば、yamada.taro@hogehoge.comというのはよくあるケース。でも同じ山田太郎さんが入ってきたらどうすんの？であったり、ｔt_yamada@hogehoge.comでは全く解決にもなっていない。かといって、yamada.taro.01@hogehoge.comではなんだか間違えやすそうだ・・・といった具合にあとあと苦しむケースがあります。
この問題に答えは無いのですが、一番悪いのはあとあとこの問題が発生したからといってt_yamadaとyamada.taroと２つの命名規則に基づくアカウントが混在するケース。これは収集がつかなくなります。修正も大変です。これだけは辞めましょう。
ユーザの作成
ディレクトリのユーザから１人ずつ作成することが可能です。但しこの時点では、MXレコードを設定していないのでGmailでメールの送受信は出来ません。但し、標準ではユーザの一括作成の機能は用意されていません。
手動で作成する手順は以下のとおりです。
- ユーザの画面の上にある新しいユーザの追加をクリックする
- 姓、名、メアドを取り敢えず入力する
- 下の「ユーザのパスワード...」という部分をクリックする
- 組織部門を用意してる場合は組織部門を指定する
- Passwordにて、自動でランダムパスワードを生成するか？指定のパスワードを入力する
- 新しいユーザの追加をクリックする
- 作成完了画面から印刷や、プレビューして送信から対象者のメアド宛にログイン手順やパスワードを通知することが可能です。
- 完了をクリックして閉じる
図：ユーザの新規作成画面
※以下のエントリーにあるようなGoogle Apps Script + Admin SDKでユーザ一括作成のスクリプトを作成したり、サテライトオフィスのシングルサインオン for Google Workspaceなどを導入すると一括作成などが出来るようになります。今後のことも考えて用意しておくと作成作業を大幅に軽量化することが可能です。
※ユーザの細かなプロフィールもガッツリGoogle Apps Scriptから送り込むことが可能です。
グループの作成
グループの概要
メールのメーリングリストだけでなく、Google Workspaceではグループを様々なシーンで利用します。
- ドライブのアクセス権限一括付与
- 組織部門で特定ユーザにだけまとめて機能のオンオフ
- Google Chatのスペースにまとめて招待
- Google Sitesへのアクセスや編集権限をまとめて管理
などなど。グループを作成しておけばいちいち個別のメンバー単位で管理する必要がなくなり、Googleグループのメンバーの追加と削除でごっそり入れ替えが可能になります。可能な限り個別ユーザで権限付与などをせず、グループ単位で管理することが定石です（他部署に異動したのに権限外し忘れてセンシティブな情報が見られる状態のままになったりする為）。
グループのパターン
当初は既存のメールサーバ等にあるMLと同じものを、Google Workspaceでも作成しメンバーを所属させると良いでしょう。主に作成するであろうグループのパターンは以下のとおりです。
- 現在の企業の部署に基づく所属メンバーのグループ
- 全社員所属のグループ
- 正社員のみ、派遣・業務請負のメンバーのみのグループ
- 特定のプロジェクト用のグループ
- 役職者専用のグループ
- 組織部門用の設定グループ
グループアドレスの中にグループアドレスを入れることも可能なので便利ではあるのですが、組織改変があった場合に修正するのがとても大変で細かく作りすぎて入れ子にしすぎると、後で修正が大変になります。可能な限りシンプルなグループ作成が必要です。
※またプロジェクト単位でグループを作り続けると、全く使われてないグループなどが大量に残り、後で棚卸しをして削除する時に悲惨なことになるので、プロジェクトが完了したら随時停止するなり削除するなりしましょう。
グループを作成する
グループもユーザ同様、管理コンソールから１つずつ作成する必要があります。標準ではユーザの一括作成の機能は用意されていません。
- 管理コンソール右サイドバーから、ディレクトリ⇒グループを開く
- 上部にある「グループを作成」をクリックする
- グループ名称、アドレスを入力する。オーナー設定をする場合はオーナーを入れますが、通常はオーナー無しで特権管理者のみがメンバー入れ替え等できるようにするのが定石です。
- セキュリティは通常はチェックは入れません。アクセス制御などを目的とした場合にはチェックを入れます。
- 次へをクリック
- アクセスタイプは通常は「公開」でオッケーです。選んだ項目によって下のアクセス設定が変わります。
- ただし、グループに外部メンバーがいる場合は、これに加えて「投稿できるユーザ」については「外部」にチェックを入れると良いです。
- くれぐれも会話を閲覧できるユーザを外部にしないこと。情報漏洩に繋がります。
- 組織外のメンバーの許可は特権管理者が管理コンソールから加える場合は適用されないので、ここはオフでオッケー
- グループを作成をクリック
グループメンバーの個別の権限などは、作成したグループをクリック⇒設定に入り、一番下の管理設定と詳細設定からGoogle Group上で個別で行います。共同トレイ機能の有効化などはそちらで行うことになるので、注意が必要です。
図：グループの作成画面
図：アクセス権限制御
※以下のエントリーにあるようなGoogle Apps Script + Admin SDKでグループ一括作成のスクリプトを作成したり、サテライトオフィスのシングルサインオン for Google Workspaceなどを導入すると一括作成などが出来るようになります。今後のことも考えて用意しておくと作成作業を大幅に軽量化することが可能です。
※また、Enterprise Standard以上ですと動的グループというものが作れるので、ユーザの属性情報を元に自動でグループを構成し、組織改変があってもユーザ情報の一部を一括で書き換えるだけでグループ自体をメンテナンスフリーにすることが可能です。
共有ドライブの作成
ドライブの移行に関する概要
新規で移行する組織の場合、日常で使ってるファイルに関しては、ファイルサーバ（NAS）に格納されてるケースが殆どではないかと思います。中には個別でDropboxやBoxなどを使ってるケースもあるかもしれませんが、これらをGoogle Driveに統合することでGoogle Workspaceのライセンスの範囲内でコストを収めることが可能です。
現在はドライブの容量はユーザ数 x プランの1人当たりの容量を全員でシェアするストレージプールの方式なので、全容量とNASの全ファイル容量に於いて、Google Drive側の容量が足らないということがなければ移行が可能です（Enterpriseプランの場合、申請で増量することが出来ます）。Businessプランの場合は、Enterpriseにアップグレードを検討することで大幅にドライブ容量を増やすことが可能です。
また、NASからの移行の場合個人アカウントのマイドライブではなく、共有ドライブに保存することで、担当者が退職してもファイルのオーナー権は組織にあるので消えたりもしません。
共有ドライブの作成
通常組織で共有ドライブを作成する場合は、特権管理者のみ許可とし、ユーザ権限の割り当ても特権管理者のみ、ユーザに割り当てる権限もコンテンツ管理者までとするのが定石です。でなければ、好き放題に作成されてコントロールができなくなります。
主に用意する共有ドライブは以下の通りです。
- 部署専用の共有ドライブ
- 部門間で受け渡しするための共有ドライブ
- 外部共有用の共有ドライブ
- 顧客別・プロジェクト別の共有ドライブ
- 特定用途用に制限された共有ドライブ
ここで課題になるのが、顧客別・プロジェクト別のドライブ。あいうえお順でドライブを作成したり、1プロジェクト1ドライブにした場合、当初はそれでも良いのですが、時間経過とともにファイルがドライブの容量に収まらなくなったり、終了済みプロジェクトのドライブがたくさん表示されたままで日々のファイル操作の障害になったり、問題が出始めます。当初から運用ルールをしっかり用意して管理することが肝要です。
※また、共有ドライブの作成やコントロール、ユーザ割り当て等もGoogle Apps Scriptで制御が可能です。以下のエントリーを参考に実装してみてください。組織改編や異動、日々のドライブの作成などの業務が非常に軽量化する事が可能です。
外部共有について
Google Workspace導入前の組織の場合、外部の人とのファイルのやり取りはメールが中心であったと思います。しかしメールは添付出来るファイルが25MBまでと制限がある上に、昨今のPPAP問題であったり、誤送信の問題があったり、果にはシャドーITによる組織外サービスを使った受け渡し（例：ギガファイル便など）があります。
結果として情報漏洩などに繋がったケースも多数あり、企業としては頭を悩ます問題が非常に多いです。かといって、Google Driveで外部共有を完全に禁止となると、それが原因でシャドーITが広がるわけなので、外部共有手段として共有ドライブやビジター共有機能を適切に整備して、一定の要件の元に許可をすると良いでしょう。
但し、外部共有は期限を設けるとともに、一定期間が経過したら削除するなどの対策は別途必要です。いつまでも共有しておくと外部のメンバーが異動や退職で異動になっても、アクセス出来てる状況は避けなければなりません。以下のエントリーを参考に対策を講じましょう。
注意点
Google Driveの容量はメールボックスも併用しています。よって社内でやり取りをする場合は、添付ファイルにするのではなく、ドライブにあるファイルを指定するようにするべきです（でなければドライブの容量をその分だけ重複して消費することになる）。加えて、ドライブ容量が不足する原因となる「仮想環境の巨大なファイル」などは、Google Driveで管理するのではなく、それだけはローカルのNASで管理するなど併用も重要になります（アップもダウンロードも時間掛かりますし）。
また、共有ドライブは1つのドライブに最大40万ファイルまでという制限がついています。ファイルサイズではなく個数というのがポイントで、組織が大きくなるとリミットに達してしまう恐れがあります。ログ・ファイルや既に完了したプロジェクトなどの場合にはZIPで固めて保存しておくことで、容量制限に引っかかりにくくなります。
さらに、Google Driveには1アカウントが1日にアップロードできる容量は750GBまでの制限があります。
移行作業のタスク
ここまででGoogle Workspaceの下準備は完了しています。しかしいきなり全面移行でリリースというわけにはいかないのが世の常。実際にはこれまでのシステムも並行稼働しつつ、徐々に移行が必要になります。特に新規導入の場合は、ユーザの側でやっていただく作業もあるため、移行スケジュールとタスク一覧を整備しておくべきでしょう。
ユーザ側で行う必要のある作業
メール関係
メールボックスデータの移行
旧式のPOP3とSMTPで送受信を行っていたような組織の場合、メールサーバの容量も少ない上に、クライアントのメーラで受信したらサーバからは削除する設定であるケースが多いです。この場合、メールデータはユーザのクライアントにだけ残ってるため、管理者が一括でGoogle Workspaceに移行させるのは難しいです。
この場合、２つのパターンでユーザはデータを自分のGoogle Workspaceアカウントに移行させることが可能です。
- Outlookの場合：Google提供のGWMMOというツールを使って、PSTファイルを変換してGmailのメールボックスに送ることが可能です。
- Mozilla Thunderbirdの場合：MBOX形式でエクスポートし、ImportExportTools NGという拡張機能を使ってGmailアカウントへ移行可能です。MBOXで出力できるクライアントならばこの手法が使えます。
メーラーの設定
本来はPCにデータを残さない上でも管理手間のあるソフトウェアを排除する上でも、クライアント側でこれまで使ってきたメーラーアプリに関しては廃止すべきでしょう。Chromeのブラウザで十分作業は出来ますし、メーラーの場合だとGoogle Driveのファイルへのリンクの挿入などが出来ないので逆に利便性を欠きます。Google Chatのデータも見ることが出来ません。
しかし、どうしてもメーラーを使いたいと言う人（主に役員の方々とか）の要望を無碍に出来ないというケースに於いてはメーラーに対して個別に設定が必要です。この作業はローカルのメールボックスの移管が完了後に行います。しかし、現在のGmailは古いタイプのID/PWでのログインは出来なくなっていますので、OAuth2.0認証で設定する必要があるため、未対応メーラーは使えません（Mozilla Thunderbirdは対応しています）。
IMAPでの接続となるのでローカルにデータは残りません。
カレンダー
現在の組織でどのようなカレンダーツールを使っているか？によりますが、概ねどのサービスであっても、ical形式やCSV形式で予定のデータを出力できるのではないかと思います。これを手動でGoogle Calendarにインポートすることで移行が可能です。
- Outlookの場合：Google提供のGWMMOというツールを使って、カレンダーを変換してGoogle Calendarに送ることが可能です。
- icalやCSV形式の場合：手動で自身のGoogle Calendarに対してインポートをすることで移行が可能です。
図：カレンダーのエクスポート/インポート
連絡先
個人の連絡先データ（取引先など）のデータも移行が可能です。利用してるサービスによりますが、vCard形式やCSV形式で連絡先データを出力できるならば、手動でGoogle Contactsにインポートすることで移行が可能です。
- Outlookの場合：Google提供のGWMMOというツールを使って、連絡先を変換してGoogle Contactsに送ることが可能です。
- vCardやCSV形式の場合：手動で自身のGoogle Contactsに対してインポートすることで移行が可能です。
図：インポートダイアログ
個人のPC内のデータ
昔と違って現代の企業内における貸与PCに於いて、「ローカル保存禁止」は割と定着してきたルールです。データの漏洩や個人所有で企業が管理出来ない状態で抹消される可能性、退職時にデータの移管が非常に面倒、業務がブラックボックス化するなど良いことは殆どありません。またデスクトップに山のようにファイルを配置してるような人もいる状態です。
Google Workspace導入の目的の１つはこういった個人のPC内にデータを残さないというものでもあるので、個人のPC内にあるデータはマイドライブ、出来れば共有ドライブの所定の場所にアップロードしておき、ローカル環境からは抹消するよう通達を出すべきでしょう。
ですが、後述のPC版Google Driveアプリで大量のファイルをアップロードするとミスが起きたり同期しないといったものが出てきたりします。Chromeブラウザでのアップロードも同じで、何よりも非常に煩雑です。情シスの手助けが必要になりますが、以下のエントリーにあるrcloneツールが非常に強力ですので、退勤時にでも仕掛けてGoogle Driveにアップロードをし移行するようにしましょう。
管理者側で行う必要のある作業
メール関係
転送設定
現存のメールサーバを活かしつつ、Google Workspace側のGmailに新規受信のメールについて転送をすることが可能です。まだ、MXレコードを切り替えていないので本番のドメインではGmailは受信が出来ないわけですが、新規導入時点で管理コンソールのドメインの管理を見てみると「hogehoge.com.test-google-a.com」というテストドメインエイリアスが設定されています。
但しこれは、現存のメールサーバ側に受信メールの自動転送の機能がある場合でないと利用できません。
全ユーザに対して転送の設定をしておき、転送先はGoogleアカウントのドメイン部分をテストドメインエイリアスにしておく。すると新規に受信したメールはGmailのメールボックスにも入るようになります。一部のユーザにだけ先行してGoogle Workspaceを使わせたいといった場合にも利用が可能です。概ね転送で十分な日数が経過したならば、いよいよ次項のDNS切り替えで完全にGmailに移行しましょう。
Gmailに移行後はテストドメインエイリアスは無効化してしまって問題有りません。
図：テストドメインエイリアスを利用する
DNS切り替え
全てのユーザをGmailに移行させて、現行のメールサーバの運用を停止するというステージになったら、ドメインを管理してるDNSに於いて、以下の作業をする必要があります。以下の作業を行います。
- さくらのDNSの対象のドメインのゾーン編集画面を開く
- 既存のDNSには現在のメールサーバ向けのMXレコードがある筈なので削除する
- 新規にDNSに対して以下のようなMXレコードを追加します。
12345エントリ名：@タイプ：メール交換ホスト(MX)データ ：1 SMTP.GOOGLE.COM.DNSチェック：するにチェックTTL : チェックして3600を指定
※データの最後に必ずピリオドを入れるのを忘れずに - しばらく待ってみる
- 切り替えるとGmail側でメールの送受信が出来るようになるはずなので、確認テストを行う。
図：MXレコードを書き換える
SPF, DKIMやDMARCの設定
2024年2月、Googleは取り敢えずGmailに対して送信されるメールについては、送信元でSPF、DKIM、DMARCが適切に設定されていない場合受信を拒否するということを発表しました。実際にこの設定が出来ていないメールが拒絶されて届かない状況になっています。この設定はMicrosoftやYahooなども追従する方針が出ているため、Google Workspaceを導入したらもはや必須の作業となります。
前述のDNS切り替えと同時に以下のエントリーを参考に、GWSおよびDNSに対して設定を施すようにしましょう。
ファイルサーバのファイル
業務でローカルのNASだけがある場合、NASを廃止してGoogle Driveに寄せることは可能です。その場合、NASのアクセス権限はグループで制御することになります。アップロード先は共有ドライブとするわけなのですが、膨大なファイル数とファイルサイズであるため、安定的にアップロードして移行する手段が必要です。
個人のケースでも利用したrcloneでNAS内の各ディレクトリを対応する共有ドライブにアップロードするよう指示を作成し、アップロードを実行しましょう。但し、前述の注意点にもあるように1日1アカウント当たりアップロード出来る容量は750GBまで。また、共有ドライブは1ドライブ当たり40万ファイルまで。
NAS側の対象のディレクトリがどれくらいのファイル数があり、どれくらいの容量なのか？をよく考慮して共有ドライブに上手に収めてあげる必要があります。また、アップロード中、社内のネットワーク帯域が圧迫される恐れがあるので、可能であれば深夜にアップロード実行するように少しづつ移行しましょう。
共有連絡先
全社員で共有してる連絡先データというものを用意してるケースはあります。Active Directory、メールクライアントやグループウェアに入ってるわけですが、Google Workspaceにも共有連絡先というあまり知られていない機能があります。但しこの機能はユーザはGoogle Contactsで利用しメールでも宛先に出てくるようになるのですが、API経由でなければデータの入出力が出来ないという問題点があります。
Google Apps Scriptでこれを実現するものを用意しましたので、以下のエントリーを参考に移管をしてみると良いかもしれません。
Active Directory連携
現在の組織の環境にローカルのActive Directoryがあり、今後も利用することが決定してるならば、このActive DirectoryとGoogle Workspaceを連携させてユーザアカウントの自動作成、組織部門へ自動配置、共有連絡先の同期、グループの自動同期が可能になります。ADとGWSで個別に作業をする必要がなくなるので、ADを基軸として業務フローを構築可能です。
但し、ログオンパスワードに関しては対象のPCに対して別途Password Syncをインストールし設定しておく必要性があります。
殆どローカルADは活用しておらず、Google Workspaceに寄せるということであるならば、ADを廃止してGoogle 認証情報プロバイダ（GCPW）をローカルPCに対してインストールすることで、GoogleアカウントでPCにログインするといった事も実現可能です。
また、AzureのEntra ID（旧Azure AD）の環境がある場合については、Entra ID側にあるSSO機能 + Provisioning機能でGoogle Workspaceに対してローカルADと同様のことが実現可能です。SSOなのでパスワード同期は不要です。Google Workspace側にもGoogle Directory SyncというEntra IDと同期する仕組みが別に用意されています。
ポータルサイトの構築
現行の組織の環境でもおそらく旧来のイントラネットの顔であるポータルサイトがあったかと思います。これそのものの移行は手段が無いため出来ませんが、あらためて作成することが可能です。
簡単な作成手順は以下の通り
- 特権管理者のアカウントにてGoogle Sitesでサイトを作成しデプロイする
- Chrome Enterpriseにて、組織管理のChromeの初期ホームページを1.のサイトの公開URLを指定して全ユーザに配信。
- Google Apps Scriptにて業務用アプリを開発し、サイトに埋め込む（申請フォーム系など）
- 掲示板システムはGoogle Workspaceには存在しないので、どうしても欲しい場合はrakumoなどを追加導入する（自分の場合、GASで作成しました）
- ポータルのコンテンツを日々充実させ、利用者が離れないよう努力する
- Google Analyticsコードを追加して閲覧状況をモニターする
5.が一番大切ですが一番出来ていない人が多いかもしれません。ただ無闇に貼り付けておけば見に行くだろうという期待をしても実際には驚くほど見られていません。
汎用チャットスペースを作る
例えば人事からのお知らせや、総務からの企業全体のイベントの通知、現業部門からの商品情報の掲示発表など、主に通知を目的としたものは「メール」ではなく、「Google Chatのスペース」で行うようにしたほうがベターです。理由は明確で「メールだと他のメールに埋もれる」というよくある事例です。導入初期はそういった事例が薄くても、時間が経過する事に濃くなっていきます。
とりわけ旧来タイプの組織の場合、チャット文化がゼロなので何でもメールで片付ける傾向があります。
前述のグループアドレスに於いて、全員や特定社員のみのスペースを作成し、なるべく通知はGoogle Chatで行うように誘導しましょう。また、GASなどからも通知を送ることが可能ですが、最も簡単なWebhookを使って投稿する方法もありますので、簡単に対象のスペースに通知を行えるので、チャットを活用する習慣を定着させましょう。
Classroomで社内研修の場を用意する
Google Workspaceを導入して意外と企業ユースで活用されていないのが、「Google Classroom」。各個人でもクラスルームを使えますが、できれば特権管理者にてルームを用意しておき、講師として各ユーザを追加、研修資料（スライドやフォームの問題集、課題、動画）などをアップしてもらうようにしましょう（Classroomのファイル類は設置した対象者のマイドライブに保存される為。特権管理者ならば削除される心配がない）。
もともとはGoogle Workspace Educationの機能でしたが、現在は全プランで利用可能で各資料を単体で用意してというよりは体系やコース別に作り上げていく上では非常に優れたツールです。社内研修のe-Learningの場所として活用しましょう。情シス部門からも「セキュリティ講座」や「社内システム活用講座」、人事部門からは「コンプライアンス講座」「新法制度の解説講座」などなど色々と使い所は満載です。
※ファイルで管理の出来るGoogle Sitesで作成しても良いかもしれません（簡単に丸ごと複製も出来ますし）
GASのウェブアプリ専用アカウント
Google Workspaceを導入して現場の改善意識が高まり様々なGASを使ったツールが増えるのは良い傾向です。単純なGASであるならばそれを含めたスプレッドシートのファイル類は共有ドライブに配置しておけば問題ないでしょう。
しかし、GASで作成したウェブアプリとなるとちょっと事情が異なります。GASのウェブアプリはデプロイした人間のアカウントで動作する仕組みであるため、仮にも対象者が退職してしまい、アカウントを削除してしまうと動作停止してしまいます。ファイルのオーナー権は共有ドライブに移動させておけば消える心配はないのですが、突如としてウェブアプリが動かなくなるので、非常によく使われてるアプリの場合困ったことになります（結果、本人がもういないのにアカウントだけは延々生き続けてるケースがあったりします）。
故に、この自体を防ぐために内部で運用ルールを定めて、Webアプリケーションのデプロイに関しては特権管理者のアカウントで行うか？専用に用意したアカウントで実行するようにし、退職されたとしても動作を継続する体制を整えるのが肝要です。
Youtubeチャンネル
企業でGoogle Workspaceを導入した場合、個人のアカウントでチャンネルを作って運用してしまうと、あとあと問題になります。これは前述のGASのアプリ同様、対象者が退職した場合、アカウントを削除するとチャンネルも削除されます。
かといってそのためにアカウントをずっと延命するというのはコストの無駄遣いです。よって企業チャンネルを作る場合には、個人アカウントに紐ついたチャンネルではなくブランドアカウントを作成し、そこに複数名の管理者を参加させて共有する形で運用する必要があります。あとからブランドアカウントに変えることは出来ませんので（チャンネルのURLが変わりますので）、最初が肝心です。
現場まかせでチャンネル作って運用などということは絶対に行わないようにしましょう。
移行後のタスク
社内研修を行う
Google Workspaceは個人でも利用できるGoogleアカウントとそのサービスと基本的には使い方が同じです。それ故に学習コストはMicrosoft365などと比較すると低いと言えます（普段からGmailとかは使ってるでしょうし、Googleスプレッドシートの要領も理解してる人は多いでしょう）。
しかし社内となると、そもそもITリテラシーに疎い人も多いだけじゃなく、企業運用ならではの問題なども多々あります。にも関わらず、その点を蔑ろにして社内周知を掲示板だけにとどめ、十分な社内研修を行わずに見切り発車して後々面倒なことになるケースを見てきています。時間と手間は掛かりますが、必ず社内研修を十分に行い、 フォロー体制を構築しましょう。
以下は古い資料でリライトが必要なものですが、過去に自分が社内研修で作成した動画資料です。他アップしていませんが、スライド資料や研修中のテスト用の資料なども用意して、全国の施設を回って研修を行っていました。パートナー企業に於いても同様のサービスを提供してるケースがあるので、ここは投資ということで利用すると良いでしょう。
アプリでカバーをする
Google Workspaceを導入したからといって、いきなりローカルのMicrosoft Officeを全部廃止・・・ということは恐らくできないと思います。最終目標はそれでも良いのですが、移行期間や一部のメンバーに関してはどうしても避けられないというケースもあります（Excel VBAで組まれたツールがガッツリ業務のフローに入り込んでるケースなど）。また、Google DriveではなくBoxを採用していて使ってきたという企業の場合も、Google Driveに移行するというのはなかなか難しいのではないかと思います。
前者の場合は、PC版Google Driveアプリを導入し、PCのGドライブとしてGoogle DriveをマウントしてMicrosoft Officeの運用を継続できるようにしてあげると良いでしょう。
後者の場合、Boxをそのまま継続利用する場合は、box for google workspaceを導入し、Box上でファイルを開くとGoogleスプレッドシートやドキュメントで開かれるといったヘルパーアプリを用意するとスムーズです（GASが使えないという制限はありますが）。
徐々に徐々に、Google Workspaceの文化に移行していき、とりわけMicrosoft Officeの利用は卒業する方向性に持っていかないと、GoogleとMSの両方でコストを払い続けるのは非常に勿体ないです。
図：Box上で直接作成や編集が可能に
セキュリティ対策
導入してすぐに突き当たるかもしれないし、だいぶ立ってから遭遇するかもしれない問題が、Google Workspaceを利用するに当たってのセキュリティ的な問題点。
Chromeに好き勝手に拡張機能をインストールを許していて良いのか？であったり、個人端末でGoogle Workspaceにログイン出来るままにしておいて良いのか？といった大きな問題です。出来れば、導入時点でこれらも含めて以下のエントリーのようにChrome利用ポリシーに制限を加えたり、Google Workspaceにログインする端末を制限したりとやることは山積みです。
場合によっては、現場で使うようなツール向けのアドオンについては情シスで作成して組織内だけで公開するといった策も非常に有効です。こういった積み重ねがセキュアにし、シャドーITを駆逐することに繋がります。
SAML認証の設定
Google Workspace以外のWebサービスが存在し、現在も利用し今後も継続利用する方向性であるならば、そのWebサービスに対するSAML認証設定をすることによって、Google Workspaceアカウントによるシングルサインオン環境を構築することが可能です（例：ZoomやBacklog）。
SAML認証をセットすることによって、個別のサービスで個別に管理（パスワードなども）するのではなく、１つのGoogle Workspaceアカウントにてアカウント認証をして入れるようになるため、ユーザにとっては利便性が向上し、組織的には個別アカウントの管理が容易になるだけじゃなくパスワード漏れに関して注力すべきはGoogle Workspaceに絞ることが可能になります。
SAMLの設定は殆どのWebサービスで対応している場合は同一の手順となるため、１つ手順を身につければ概ね設定はできるようになります（一部特殊な設定をする事例はありますが、設定方法は必ずドキュメントで用意されてる筈です）。
カスタムSAMLアプリを設定すると、Chromeトップページのアカウント横のつぶつぶをクリックすると、対象のアプリが出てくるようになるので、ブックマークなどをしておく必要もありません。
図：SAML認証の設定中の画面
関連リンク
- 一部の社員だけGoogle Workspaceを導入する方法
- Google Workspaceへの段階的な移行が可能！？一部ユーザーのみを移行する方法。
- Google Workspace を導入した後の最初の設定手順を教えてください。
- デスクトップ保存を禁止すべき理由とデスクトップに保存のデメリット
- Google Workspace で Classroom を使いこなそう
- 共有アカウントはなぜ悪なのか
- Google Workspaceのプライマリドメイン変更が大変だった話
- Google Workspace のログイン ID をセカンダリドメインに付け替えた話
- Google Workspaceのプライマリドメイン変更を実施しました
- ドキドキ Google Workspace プライマリドメイン変更
- vol.33 Google Workspaceを用いたプロジェクトマネジメント (下)
- Google Workspace のテナント統合をした話
- Google Workspaceのお引越し手順を公開するぜ
- GWS（Google Workspace）異なるドメイン間でのデータ移行
