Google G Suiteの導入手順とトラブルになりそうなポイントの解説

メールとスケジュールの連携やスマートフォンとの同期が可能なGoogleのG Suiteはとても便利ですが、導入までの道のりは決して楽な物ではありません。

理解できてしまうと簡単なことでも、最初はシステムの仕様を確認したり動作検証をするなど、とても多くの作業をこなさなければG Suiteの導入はできません。

特に難しいのがメールシステムの切り替えで、テスト環境では発生しないトラブルがシステムを変更した直後に発生したり、思いもよらない挙動を起こすことがあります。

そこで今回は、GoogleのG Suiteをできるだけスムーズに導入するための手順と、トラブルになりそうなポイントを整理してみました。

既存環境の見直し

GoogleのG Suiteを導入する上で最も重要になるのが既存インフラの確認や見直しで、ファイアウォールセッションの少ない通信機器を使用している場合は、交換が必要になることもあります。

クラウド系アプリケーションはファイアウォールのセッションを多く消費しますので、OutlookやMac MailなどをPOPとSMTPで使用していた時に問題なくても、G Suiteに切り替えた途端に問題になる可能性があります。

G Suiteの場合、Office365と比べるとファイアウォールのセッションを多く消費しませんが、念のためにG Suiteへ切り舞える前の通信状況を確認し、セッション数に余裕がなければ機器の買い替えをしてください。

また、Outlookなどの一部のメールソフトは、OAuthに対応していないので、メールソフトを卒業してWebブラウザ操作にするか、Thunderbirdなどの対応したアプリに切り替える必要がああります。

ただし、Thunderbirdはメールの利用はできてもアドオンや小難しい設定をしなければカレンダーの同期ができないので、大規模展開するには非現実的です。

Windows10のメールソフトはタッチ式を意識したのか普通に使いにくいことを考えると、Mac OS10.12に付属するMailが一番使いやすくてG Suiteと相性が良さそうです。

ただ、Mac OSを10.12にするとAdobe CS6が使用できなくなるので、OSのアップグレードやメールソフトの切り替えは慎重に検討しなければなりません。

G Suiteのご利用は計画的に

GoogleのG Suiteは単なるメールシステムではなく、スケジュール管理、ハングアウト、ドライブ、サイトなど、多くの機能を利用できる便利なツールです。

その機能の豊富さ故に検討しなければならないのが既存グループウェアの存在で、GoogleのG Suiteを単なるメールシステムだけで利用するのか、スケジュール管理なども含めたグループウェアとして利用するのか考えなければなりません。

G Suiteをグループウェアとして利用する場合ですが、可能なら最初にメールだけの移行を済ました後に、ドライブやスケジュール管理などの機能を段階的に利用した方が無難です。

何故ならG Suiteのメールは少し特殊で、個人アドレス以外はグループアドレスという、メールの送信ができるメーリングリストの様なものを作成しなければなりません。

レンタルサーバなどのメーリングリストは、基本的にメールメッセージを受け取るだけしかできませんが、GoogleのG Suiteはグループアドレスからも返信することができます。

メールソフトの設定を変えなければメーリングリストのアドレスからもメールメッセージの送信は可能ですが、CCにメーリングリストのアドレスを含めないと、グループに登録されているメンバーに送信したメールメッセージが共有されません。

その他にも2段階認証の導入や、OAuthに対応したメールクライアントの調査と検証、セキュリティに問題のあるアプリケーションの設定など、メールをGmailに変えるだけでもかなりの手順や仕組みの理解が必要となります。

メールだけでなくスケジュール管理なども、組織ありきの日本製グループウェアとはコンセプトが違うので、他の機能はメールの移行を確実にできた後に段階的に進めていくのがおすすめです。

DNSの仕様確認と設定

G Suiteを利用する際に必用な手続きがいくつかありますが、まずはドメインの所有確認が必要で、これを済まさなければG Suiteの契約をしても使用することができません。

ドメイン所有確認をする方法はいくつかありますが、一番簡単な方法はオリジナルドメインのWebサイトにhtmlファイルをアップロードする方法で、次にDNSにtxtレコードを記述する方法です。

Webサイトのヘッダーに情報を追記する方法もありますが、Webサイトに手を加えずに所有確認のできるhtmlファイルのアップロードがおすすめです。

もし何らかの理由でDNSレコードを追加しなければならない時は、既存のTXTレコードが邪魔をしたり、DNSの反映に時間がかかる場合があります。

DNSのレコードでドメイン所有確認をする場合は、事前に不要なTXTレコードの削除やTTLを10分程度に短く設定するのをおすすめします。

更に重要なのがSPFレコードとDKIMの設定で、GoogleのGsuiteでは簡単にこれらの設定を行うことができますが、DNSのレコード登録で工夫をしなければならない場合があります。

SPFやDKIMの設定は情報がネッと上に沢山ありますのでここでは説明しませんが、TXTレコードの長さが問題になる場合があるので注意が必要です。

特にDKIMを設定する時は、TXTレコードに設定する文字列の長さが256文字を越えるので、ダブルクォーテーションで区切る必要があります。

G Suiteの管理画面で生成されるDKIMのレコード設定情報をそのままコピーしても、文字列が長すぎて正常に設定できない場合があるので注意してください。

DNS関連で問題になりそうなのが、逆引きできないDNSを利用している場合にメールの一部が送受信できない可能性があるという点です。

一部、IPv6に対応したレンタルサーバーから送られたメールがGmailに届かないという事例もあるようですが、現時点ではトラブルになるような報告は受けていません。

DNS関連で慌てる可能性があるとしたらTTLを短く設定するのを忘れて、システム切り替えの当日にメールが正しく届いているか検証できないということくらいでしょうか。

Gmailに限らずメールのシステムを切り替える時は、1週間くらい前からTTLを10分程度の短い時間にしておいた方が良いでしょう。

DNS関連で注意したいのが、G Suiteのヘルプに掲載されている内容に一部古い情報があり、設定すべきMXレコードに誤りがあります。

優先するMXレコードの情報はどのヘルプも同じなのでトラブルにはなりませんが、常に最新の情報を確認してMXレコードを設定するようにしてください。

MXレコードを設定する際は、既存レコードの優先順位を下げることを忘れないようにしてください。

全メールを転送する時の注意点

メールシステムを切り替える際は、どの様な方法で移行するのかを決めるのが重要ですが、実際に考えていた方法でシステムを切り換えた時に大きなトラブルが発生しました。

今までと同じようにOutlookのPOPでメールを送受信する方法を選択するのであればGmailから旧メールサーバへ電子メールを転送する必要はありませんが、スマホとの連動を考えるとWebメールへの移行が自然となります。

その際に、一定期間Gmailに届いたメールを旧メールサーバへ転送するのが普通の方法らしいですが、この普通という言葉に騙されると痛い目にあいます。

最近は迷惑メール判定されないようにDNSレコードにSPFやDKIMを設定する企業が増えていますが、実はSPF設定されたメールサーバーから送られてきた電子メールをGmailから旧システムに自動転送するように設定すると、SPFがsoftfailになりなりすましメールとして判定されてしまいます。

旧メールサーバはアカウント毎になりすましメールを受信するか否かの設定をできるのですが、一部なりすましメールを拒否する設定にしているユーザーがいたので、全てのアカウントにログインして設定をチェックしました。

デフォルトがなりすましメールを受信する設定でしたので大きな混乱は発生しませんでしたが、この事実に気が付くまで24時間程かかりました。

全メールの自動転送は、G Suite導入を支援する書籍や業者が推奨するおすすめの方法でしたが、検証せずに鵜呑みにして慌てたことがあります。

その他に起こりえるトラブルと言えば、全メールの転送設定をする際にホストの登録をするのですが、MXレコードに登録する情報を設定せずに、メールソフトに設定するメールサーバを設定して、一切メールが転送されないという現象がありました。

既に解決した問題なので今では笑い話でしかありませんが、当日は夜中に切り換え作業をして徹夜になりましたので、この記事をご覧になられている方が不要なトラブルで慌てないように記録として残しておきます。