入社初日の朝、新しいメンバーにノートPCを渡してログインしてもらう。メールアドレスとパスワードを入れたのに「このアカウントは利用できません」と出る、あるいはログインはできたのにGmailの画面が開かない。総務の担当者が情シス担当に内線をかけ、情シスが管理コンソールを開き直す。これを入社のたびに繰り返している会社は珍しくありません。
原因のほとんどは、アカウントを作る作業そのものではありません。アカウントを作った後にやることが5つあり、そのどれかが抜けているという形で起きます。新規作成の画面は親切に作られているので、作った時点で終わった気になってしまうのが落とし穴です。
ここでは、入社日の朝に慌てないための準備を、実際につまずく順番で並べます。ひとりずつ手作業で足している会社にも、年に十数人の入社がある会社にも共通する部分を中心にしました。
「作った」と「使える」の間にあるもの
管理コンソールでユーザーを追加すると、その瞬間にアカウントは存在します。ただし存在することと業務で使えることは別です。作成した後に、少なくとも次の4つが挟まっています。
この4つのうち、初日の朝に一番響くのがライセンスの割り当てです。ユーザーを追加しただけではGoogle Workspaceの各サービスが使えないため、ライセンスを別途割り当てる必要があります。自動割り当てを設定していない組織では、ここが手作業のまま残っていることがあります。ログインは通るのにGmailが開かない、という症状はたいていこれです。
残りの3つも、抜けたときの症状がそれぞれ違います。組織部門（OU）の配置を間違えると、その人だけ使えるはずのアプリが見えない、あるいは本来制限したいはずの設定が外れたままになります。グループと共有ドライブへの追加が抜けていると、ログインも業務アプリも問題ないのに、チームのファイルが1つも見えません。
初回ログインをどう設計するか
新しいメンバーが最初にログインする瞬間に何が起きるかは、管理者側で決められます。ここを決めずに運用すると、担当者が口頭でパスワードを伝える、チャットに貼る、といった方法に流れがちです。
仮パスワードを使う場合は、次回ログイン時にパスワードの変更を要求する設定を有効にします。CSVで一括追加するときは Change Password at Next Sign-In の列に TRUE を入れておくと、同じ挙動を全員に適用できます。これで、管理者が知っているパスワードがそのまま使われ続ける状態を避けられます。
初回ログインの直後に2段階認証プロセスの登録を求めるかどうかも、先に決めておく項目です。入社初日に本人のスマートフォンで登録まで済ませてしまうほうが、後から全員に督促するより確実に終わります。一方で、初日は業務端末の受け渡しだけで手一杯という事情もあります。どちらを選ぶにせよ、「いつまでに登録するか」を決めずに任意のままにしておくと、登録率は上がりません。セキュリティ設定の全体像はGoogle Workspaceのセキュリティチェックリストに整理しています。
復旧用のメールアドレスと電話番号も、初日に本人に登録してもらうと後が楽になります。これが空のままだと、本人がパスワードを忘れたときに管理者がリセットするしかなくなり、情シスの手間が増えます。
ひとりずつ作るか、CSVでまとめるか
入社が年に数人なら、管理コンソールの「ユーザーを追加」から個別に作るので十分です。画面の指示どおりに進めれば必要な項目は埋まります。
一方、4月の一括入社や、拠点ごとにまとまった採用がある場合は、CSVでの一括アップロードのほうが確実です。管理コンソールの「ディレクトリ」から「ユーザー」を開き、ユーザーの一括アップロードでテンプレートをダウンロードします。姓・名・メールアドレス・パスワード・組織部門のパスが必須項目になっているので、表計算ソフトで埋めてアップロードします。
| 個別作成 | CSV一括アップロード | |
|---|---|---|
| 向いている場面 | 月に1〜3人程度の中途入社 | 4月入社、拠点立ち上げ、10人以上 |
| 組織部門の指定 | 画面で選ぶ | Org Unit Path 列に記入 |
| 初回パスワード変更 | チェックボックス | Change Password at Next Sign-In に TRUE |
| つまずきやすい点 | 項目の埋め忘れ | 組織部門のパスの表記ゆれ |
CSVで多いつまずきは、組織部門のパスの書き方です。管理コンソール上の階層と1文字でも違うと、そのユーザーだけ意図しない場所に入ります。既存ユーザーをエクスポートして、実際に使われている表記をコピーするのが安全です。
入社より難しいのは退職のほう
アカウントを作る手順は整えたのに、使わなくなったアカウントの扱いが決まっていない組織は多いです。これは費用にも直接効きます。割り当てたままのライセンスは、その人が出社していなくても課金されます。
退職時に決めておきたいのは、アカウントを削除するのか、停止するのか、という点です。削除するとそのユーザーのデータも消えるため、引き継ぎが済む前に消してしまうと戻せません。停止（一時停止）にしておけば本人はログインできなくなりますが、データは残ります。ただし停止中もライセンスは消費されるので、引き継ぎ後にどうするかまで決めて初めて片が付きます。
もう1つ、退職者本人のGmailに取引先からのメールが届き続ける問題があります。転送設定や、そのアドレスをグループに切り替える対応を、退職日当日にできるよう手順に入れておきます。管理コンソールでの具体的な操作はGoogle Workspace管理コンソールの使い方にまとめています。
引き継げる形にしておく
ここまでの内容は、担当者の頭の中にあるうちは属人化しています。情シス担当が1人しかいない会社ほど、その人の休暇中に入社日が来たときに止まります。
手順書にするときは、画面の操作手順を長々と書くより、「誰が・いつまでに・何を確認するか」の一覧にしたほうが実際に使われます。入社日の3営業日前にアカウント作成とライセンス割り当て、前日に共有ドライブとグループへの追加、初日に本人と一緒に2段階認証と復旧情報の登録。この粒度で十分機能します。
Google Workspaceを導入したばかりで全体の設定から見直したい場合は、Google Workspace導入・初期設定ガイドも合わせてご覧ください。
次にやること
まず、直近で入社した人のアカウントを管理コンソールで開いて、組織部門とライセンスの割り当てを確認してみてください。意図した組織部門に入っていない人が1人でも見つかったら、作成手順のどこかが口頭伝達に頼っています。
そのうえで、退職者のアカウントが停止のまま何ヶ月も残っていないかを棚卸ししてください。ここは手順を直すだけで毎月のライセンス費用に跳ね返る部分です。
グリームハブでは、Google Workspaceの管理設計や情シス業務の整理について、IT・Google Workspace 無料相談で承っています。組織の人数や入退社の頻度によって適切な運用の形は変わるため、まずは現状をお聞かせください。お問い合わせからご相談いただけます。
