自治体のGoogle Workspace運用で最も負荷が高いのは、4月1日の一斉異動です。ここを乗り切る鍵は、組織部門（OU）を組織図どおりに作らないことと、権限をグループで付けることの2点に尽きます。ユーザーは1つの組織部門にしか所属できないため、兼務や組織改編を組織部門で表現しようとすると必ず破綻します。
自治体・公共機関のIT環境整備を、ネットワーク構成の設計からクラウドサービスの設定、運用定着までご支援しています。Google Workspace／Microsoft 365 のいずれにも対応します。
自治体・公共機関のIT支援 を見る →ITコンサルティング4月1日に何が起きるか
自治体の人事異動は、民間企業の異動とは規模も同時性も違います。数百人規模の団体でも、年度替わりに全職員の1〜3割が動くことは珍しくありません。しかも発令は4月1日に一斉で、その日から新しい所属で業務が始まります。
この日に間に合わせなければならない処理は、次のとおりです。
- 所属の変更（組織部門の移動）
- 共有ドライブやフォルダへのアクセス権の付け替え
- メーリングリストの入れ替え
- 新規採用者のアカウント発行
- 退職者・任期満了者のアカウント停止
- 組織改編に伴う部署そのものの新設・廃止
これらが同じ日に、まとめて発生します。設計が悪いと、この処理だけで情報部門が数週間を消費します。
民間との決定的な違い
| 論点 | 自治体で起きること |
|---|---|
| 同時性 | 4月1日に集中する。分散させられない |
| 組織改編 | 課の統廃合が同時に起きる。人が動くだけでなく箱も変わる |
| 兼務 | 本務と兼務、併任が日常的にある。1人が複数部署に属する |
| 任用形態の多様さ | 常勤、会計年度任用職員、非常勤、任期付、再任用、派遣・出向 |
| 出先機関 | 本庁・支所・出張所・公民館など拠点が分散し、権限も異なる |
| 議会・委員会 | 執行機関とは別系統の組織が同一ドメインに同居することがある |
民間向けのアカウント設計をそのまま持ち込むと、兼務と任用形態の多様さで必ず詰まります。設計段階でこの2つを織り込んでください。
組織部門を組織図に合わせない
Google Workspace の組織部門（OU）は、ユーザーを1つだけ所属させる階層構造です。サービスの有効・無効やポリシーは、この階層で継承されます。
ここで多くの団体がやってしまうのが、組織図をそのまま組織部門として作ることです。「総務部＞総務課＞人事係」のように細かく切ると、次の問題が起きます。
- 組織改編のたびに階層を作り直す：課の統廃合が毎年あると、毎年構造が壊れます
- 兼務を表現できない：1つにしか所属できないため、必ず例外が出ます
- 設定が同じ階層を無駄に分ける：同じポリシーの部署を分けても、管理対象が増えるだけです
設計の基準はシンプルです。設定を変えたい単位で切る。それ以外は分けません。
| 分ける | 分けない |
|---|---|
| 利用できるサービスが違う（例：外部共有の可否） | 単に部署が違うだけで、設定は同じ |
| 任用形態が違う（常勤／会計年度任用職員） | 組織図上の階層を再現したいだけ |
| 端末や利用環境が違う（例：Chromebook中心の部署） | ― |
| 議会事務局など別系統の組織 | ― |
組織図の表現は、次に述べるグループで行います。組織部門は「設定の入れ物」、グループは「人の集まり」と役割を分けてください。
権限はグループで付ける
グループは複数所属できます。この性質が、兼務と組織改編の両方を吸収します。
- 部署グループ：所属を表す。メーリングリストとしても機能する
- 役職グループ：課長級以上など、横断的な配信や権限付与に使う
- 業務グループ：特定の業務・プロジェクトの担当者。組織をまたぐ
共有ドライブやフォルダへのアクセス権は、個人ではなくグループに付与してください。そうすれば異動時はグループのメンバーを入れ替えるだけで済み、アクセス権を1件ずつ付け替える必要がなくなります。
この考え方は、ファイル共有基盤の設計と共通です。権限設計の詳細は共有ドライブの権限設計でも扱っています。
内示から発令当日までの流れ
発令当日に手作業で処理する運用では、規模が大きい団体では終わりません。内示の時点から準備を始めます。
| 時期 | やること |
|---|---|
| 内示後 | 新旧の所属とグループの対応表を作る。組織改編があれば新しいグループを先に作成しておく |
| 発令の数日前 | 一括更新用のデータを作成し、テスト環境または少数で検証する |
| 発令日 | 一括更新を実行。組織部門の移動とグループの入れ替えを反映する |
| 発令後1週間 | アクセスできない・できてしまうという申告を受け付け、例外を処理する |
一括更新は、管理コンソールのCSV一括更新や、Directory API を使った処理で行えます。重要なのは、当日に判断が発生しない状態まで事前に詰めておくことです。当日に「この人はどちらの部署か」を確認し始めると、必ず終わりません。
また、発令後1週間の申告受付は必ず設けてください。どれだけ準備しても例外は出ます。想定内として手順に組み込んでおくほうが、現場の混乱が小さくなります。
ライセンスの再割当
異動そのものではライセンス数は変わりませんが、次のタイミングで増減します。
- 新規採用（増）／退職・任期満了（減）
- 会計年度任用職員の年度更新（年度末に一斉に切れる）
- 再任用・再雇用（一度切れて再び発生する）
組織部門ごとに自動割り当てを設定しておけば、所属を変えるだけでライセンスが切り替わります。任用形態で組織部門を分けておくと、この自動化が効きます。前述の「設定を変えたい単位で切る」の具体例です。
あわせて、年度末に一斉に切れる分をどう扱うか（即時停止か、猶予期間を置くか）を先に決めておいてください。
退職・任期満了とデータ
最も影響が大きいのが、マイドライブに保存されたファイルです。マイドライブは個人に紐づくため、アカウントを削除すると中のデータも失われます。
対策は設計段階で決まります。
- 業務データは共有ドライブに置く：共有ドライブのファイルは組織に帰属するため、担当者が変わっても残ります。これが前提です
- アカウント停止と削除を分ける：即座に削除せず、一定期間は停止状態で残す運用にします
- 保存が必要なものは保持の仕組みで残す：文書管理の方針に沿って、保持ルールを設定します
保持と削除の考え方は、行政文書としての扱いと直結します。公文書管理・情報公開請求とGoogle Workspaceで詳しく整理しています。
自動化はどこまでやるか
人事システムと連携して自動化する構成は可能ですが、いきなり自動化に進むと失敗します。理由は、連携が「人事側のデータが正確であること」を前提にするためです。
実際には、人事データ上の所属コードと情報システム側の組織部門が一致していない、兼務が人事データに表現されていない、といったずれが必ず出ます。ずれたまま自動化すると、誤った権限が自動で付与されます。
推奨する順序は次のとおりです。
| 段階 | 内容 |
|---|---|
| 1 | 手順を文書化し、一括更新で回す。例外がどこで出るかを1年分記録する |
| 2 | 記録をもとに、人事データと組織部門の対応を整える |
| 3 | ずれが小さくなってから、同期の自動化を検討する |
1年分の記録があると、自動化の設計精度が大きく上がります。急がば回れが最も早い領域です。
よくある質問
組織部門（OU）は組織図どおりに作るべきですか？
おすすめしません。ユーザーは1つの組織部門にしか所属できず、設定は組織部門の階層で継承されます。組織図どおりに細かく作ると、組織改編のたびに階層を作り直すことになります。設定を変えたい単位で切り、部署の表現はグループで行うほうが改編に耐えます。
兼務している職員はどう扱えばよいですか？
組織部門は1つしか選べないため、主たる所属で決めます。兼務先へのアクセス権はグループで付与してください。組織部門で権限を管理する設計にしていると、兼務が発生するたびに例外対応が必要になります。
会計年度任用職員のアカウントはどう設計しますか？
任期が年度単位で区切られるため、一般職員とは分けて管理できるようにしておきます。年度末に一斉に任期満了となるので、有効期限や停止のタイミングを揃え、翌年度に再任用される場合の再有効化の手順まで決めておくと、毎年の作業が定型化できます。
異動処理はいつから始めればよいですか？
内示の時点で準備を始め、発令日に切り替えるのが基本です。内示から発令までの期間に、新旧の所属とグループの対応表を作り、一括更新用のデータを用意します。発令当日に手作業で処理する運用では、規模が大きい団体では終わりません。
退職者のデータはどうすればよいですか？
マイドライブに保存されたファイルは個人に紐づくため、アカウントを削除すると失われます。業務データは共有ドライブに置く運用にしておくことが前提です。そのうえで、保存が必要なメールやファイルは保持の仕組みで残し、アカウント自体をどう扱うかを文書管理の方針と合わせて決めてください。
人事システムと連携して自動化すべきですか？
規模によります。数百人以上で毎年の異動が大きい団体では、連携の投資に見合います。ただし連携は「人事側のデータが正しいこと」が前提になるため、まず一括更新の手順を固めて運用を安定させ、その後に自動化へ進むほうが失敗しません。
まとめ
自治体のGoogle Workspace運用は、4月1日の一斉異動をどう捌くかで負荷が決まります。設計の要は2つです。組織部門を組織図どおりに作らず「設定を変えたい単位」で切ること、そして権限を個人ではなくグループに付けることです。
ユーザーは1つの組織部門にしか所属できません。兼務や組織改編を組織部門で表現しようとすると必ず破綻します。組織部門は設定の入れ物、グループは人の集まりと役割を分けてください。
そして退職・任期満了に備え、業務データは共有ドライブに置く運用を前提にしてください。マイドライブのファイルは個人に紐づくため、アカウント削除で失われます。人事システムとの自動連携は、まず一括更新で1年回して例外を記録してから検討するほうが確実です。