Google WorkspaceからMicrosoft 365への全社移行を任され、メールとファイルの移行計画はすでに固まっています。
ただ、現場で動いているGoogle Apps Scriptの自動化まで手が回っていないと感じていませんか。
移行ベンダーが提示する計画書はメールとカレンダーとファイルの移行が中心で、現場が個別に作った自動化の扱いは項目としてほぼ出てきません。
そのため切り替え直前になって「あの集計、動かなくなった」と気づく事例が後を絶ちません。
移行計画の中で自動化資産をどう扱うかに絞り、なぜ計画から漏れるのか、社内のGoogle Apps Script資産をどう見つけるかを整理しています。
あわせて、廃止・移行・併存の仕分け方と、作り直す体制をどう組むかも取り上げます。
移行計画から「自動化ツール」が漏れる理由
移行ベンダーが提示するプロジェクト計画は、メールボックスの移行、共有ドライブのファイル移行、カレンダーの同期といった、Google Workspace標準機能の対応表で構成されています。
実際にMicrosoftが提供する移行の仕組みも、Googleドライブのファイルとメタデータとアクセス許可を移すことに特化しており、現場が独自に組んだ自動化までは対象にしていません。
一方で、Google Apps Scriptで組まれた自動化は、作った本人しか仕様を把握していない状態のまま稼働しているケースが目立ちます。
承認が通りやすい小さな改善として個人や部門単位で作られることが多く、情シス側の資産管理台帳に載っていないケースがほとんどです。
台帳に存在しないものは、移行計画のスコープを決める段階で最初から検討対象に入りません。
結果として、切り替え直前や切り替え後に「毎朝自動送信されていた日報集計が止まった」「経費精算の承認通知が来なくなった」といった形で発覚し、現場からの問い合わせ対応に追われることになります。
自動化に限らず、担当者しか業務の全体像を把握していない属人化の解消には、棚卸しから着手する共通の順番があります。
社内のGoogle Apps Script資産を洗い出す方法
管理者側から見つける
Google Workspace管理コンソールのApps Scriptダッシュボードからは、組織内で作成・実行されているスクリプトの一覧をある程度確認できます。
ただし、個人アカウントで作成され共有ドライブに紐づいていないスクリプトは一覧に出てこないことがあり、これだけで全量を把握したとみなすのは危険です。
共有ドライブ全体をファイル種別でスキャンし、トリガー設定の有無から自動化らしきファイルを洗い出す作業を組み合わせる必要があります。
部門ヒアリングで「動いている業務」から見つける
管理者側からの調査だけでは、Googleフォームの回答をトリガーに動くスクリプトや、スプレッドシートの関数と組み合わさった半自動化までは拾いきれません。
各部門に「毎日・毎週決まった時間に自動で動いている作業はあるか」「担当者が休むと止まる作業はあるか」という切り口で聞き取ると、システム台帳に載らない運用が見つかりやすくなります。
ヒアリングは移行プロジェクトのキックオフと同じタイミングで始め、切り替え日までに棚卸しを終える前提でスケジュールに組み込みます。
洗い出した自動化の仕分け方（廃止・移行・併存）
洗い出しが終わったら、見つかった自動化を一件ずつ「廃止」「移行」「併存」の三択で仕分けていきます。
利用実績がほとんどない、あるいは元になった業務自体がすでに存在しない自動化は廃止の対象で、利用頻度が高く業務への影響が大きいものは、Power Automateなど新環境の標準機能で作り直す移行の対象になります。
判断が難しいのは、Google Workspace側の機能に強く依存していて、Microsoft 365環境での代替が技術的に難しいものです。
この場合は当面Google Workspaceのライセンスを一部だけ残して併存させる選択肢も現実的で、すべてを移行完了させることにこだわりすぎると、切り替えスケジュール全体が遅延するリスクがあります。
3つの仕分けと判断基準、その後の扱いを整理すると次の表のとおりです。
| 仕分け | 判断基準 | その後の扱い |
|---|---|---|
| 廃止 | 利用実績がほとんどない、または元の業務がすでに存在しない | 対応不要 |
| 移行 | 利用頻度が高く業務への影響が大きい | Power Automateなど新環境の標準機能で作り直す |
| 併存 | Google Workspace側の機能に強く依存し、Microsoft 365環境での代替が技術的に難しい | 当面Google Workspaceのライセンスを一部だけ残す |
具体的な移行手順や機能の対応関係は、別記事で整理しています。
作り直しの体制をどう組むか
社内で作り直す場合に必要なスキル
Power Automateでの作り直しは、プログラミング経験がなくても着手できる設計になっていますが、承認フローや複数条件の分岐を組む場合は、ある程度のロジック構築力が求められます。
Google Apps Scriptで自動化を組んでいた人材がそのままPower Automateの担当に移行できるかどうかは、環境の違いだけでなく本人の適性にも左右されるため、できること・できないことの違いを事前に把握したうえで検討したほうが、判断を誤りにくくなります。
人材がいない場合の3つの選択肢
社内にPower Automateを扱える人材がいない場合に取れる手は、次の3つです。
- 既存の情シス担当者を育成する（時間はかかるが、ノウハウが社内に残る）
- 経験者を新たに採用する（即戦力になるが、採用競争が激しく着任まで時間がかかる）
- 検証だけを外部に小さく依頼する（設計・実装は自社で担い、動作検証や品質チェックのみ切り出す）
日本情報システム・ユーザー協会の「企業IT動向調査2025」では、システム開発の内製化を進めるうえでの阻害要因として「開発人材の量の不足」を挙げた企業が50.8%にのぼっています。
育成にも採用にも時間がかかる実態がデータに表れており、内製化の担い手を社内だけで確保する難しさは業種を問わず共通の課題です。
だからこそ、3つ目の「検証だけを切り出す依頼」が現実的な中間解になります。
丸ごと外注するのではなく検証部分だけを外部に任せるため、コストを抑えながら社内にノウハウを残せます。
移行スケジュールに組み込むときの目安
自動化資産の棚卸しは、移行プロジェクトのキックオフと同時に着手するのが基本です。
棚卸しと仕分けに数週間、作り直しの体制検討と着手判断にさらに数週間を見込むと、切り替え予定日の2～3か月前には仕分け結果が出ている状態が理想です。
すべての自動化を切り替え当日までに移行完了させる必要はありません。
優先度の高いものから着手し、優先度が低いものは併存期間を設けて並行稼働させながら移行する計画のほうが、現場の混乱を抑えられます。
移行で作り直す量が読めないまま、計画を進めていませんか？
棚卸しで洗い出した業務フローのうち3本まで、5万円固定で検証を依頼できます。
丸ごと外注せず、検証だけを小さく始める形で切り出せます。
納品するのは、フローごとの移行可否判定と概算の実装工数、Microsoft 365環境での代替が難しいつまずきポイントをまとめたレポートです。
検証の結果、Google Workspace側の機能を一部残す判断が必要だと分かった場合も、その理由と代替案をレポートに明記してお渡しします。
よくある質問
Q. 自動化資産の洗い出しにはどのくらいの期間がかかりますか？
規模にもよりますが、管理コンソールでの調査と部門ヒアリングを合わせて2～4週間程度が目安です。
部門数が多い企業や、過去に情シス部門を介さずに自動化が導入された企業では、ヒアリングの回収に時間がかかりやすくなります。
Q. 自動化を作った担当者がすでに退職している場合はどうすればいいですか？
コードとログから仕様を読み解く作業が必要になります。
実行トリガーの設定や参照しているスプレッドシートの構造を確認すれば、業務上の意図はある程度復元できることが多いです。
判断に迷う場合は、そのスクリプトが今も使われているか利用実績のログで確認し、利用実績がなければ廃止を検討する材料にもなります。
Q. Power Automateへの移行と廃止、どちらを優先して判断すべきですか？
まず廃止できるものから確定させると、移行対象の母数を絞り込めます。
利用頻度と業務への影響度の二軸で洗い出した自動化を並べ、影響度が低く利用頻度も低いものから廃止候補として除外していく順番が効率的です。
Q. 外部に検証だけを依頼する場合の費用感はどのくらいですか？
依頼する自動化の件数や複雑さによって幅があり、一律の相場はありません。
設計と実装を自社で担い、動作検証のみを切り出す場合は、丸ごと外注するよりも費用を抑えやすい傾向があります。
