はじめに
こんにちは、ともしゅうです。CloudNativeで情シスの運用支援をしています。
昨年12月から案件に入り始めて、気づけば半年が経ちました。複数の企業の情シス業務に並走する中で、「あれ、この課題さっきも別の会社で見たな」と思うことが増えてきたので、一度まとめてみようと思います。
本記事で伝えたいのは、課題を“自動化”だけで片付けず、まず整理して、無理なく回る形に落とし込むということです。以降では、具体例として「自動化」と「マルチテナント運用」を取り上げます。特別な知見というよりは、あくまでも私が現場で繰り返し出会った課題と、それに対して実際にやってみたことの記録です。うまくいったことも、ハマったことも含めて書いていきます。
運用支援チームって何？
私が所属している運用支援チームは、情シスが日常的に扱うSaaSやID基盤・セキュリティまわりの運用を、お客さんの環境に入って支援しているチームです。
業務の内容は様々で、アカウント発行・権限変更といった日常タスクから、トラブル対応・運用ルールの整理・自動化の設計まで一通りやります。お客様によって入り方も違って、「日々の運用が回らないので手を貸してほしい」もあれば、「自動化したいけど何から始めるか分からない」もあるし、「とりあえず話を聞きにきてほしい」みたいなトーンで入ることもあります。
運用支援チームのメンバーは情シス経験者だったり、現在もmakeやGASを使った社内の自動化に貢献しており、自社業務と運用支援としての業務両方を日々こなしています。そのため、実現性だけでなく、その後の運用に無理がないかまで見て提案できるのが大きな強みです。
半年やってみて思うのは、お客様ごとに使っているツールはバラバラなのに、相談されるテーマは意外と被るということです。以降では、その中でも特に多かった自動化とマルチテナント運用を順番に書いていきます。
自動化=楽、では終わらない
自動化のお話は、運用支援に入っていちばんよく聞く相談です。一方で、ご依頼を受けてそのまま作るとあまりうまく回らないことが多いのも自動化です。
ここで扱うのは「自動化そのもの」ではなく、自動化が“運用として”回る状態に持っていくための考え方です。そしてここは、コンサルティングだけでは届きにくい領域でもあります。業務をどう整理するかのレイヤーで止まると、現場で動いているExcelマクロや既存スクリプト、SaaSの細かい設定までは見えてこない。手を動かしながら業務理解の高い人が現場に並走しないと、自動化の前提となる現状が掴めません。運用支援が呼ばれる場面の一つは、ここに価値が出るときです。
私が支援に入ったケースでは、おおむね次の流れで進めています。
① 作業の棚卸し
↓
② 自動化すべきか判断（やらない判断も含む）
↓
③ ツール選定
↓
④ 運用コストの見積もりそれぞれ簡単に書いていきます。
① 作業の棚卸し：そもそも今、何ステップやっているか
「手作業をなんとかしたい」という相談で、最初の壁になるのが「そもそも今どんな作業が何ステップあるのか」が見えていないこと。
ある支援先では、定期的に発生するアカウント発行業務をたどってみたら、十数ステップの手作業が数珠つなぎになっていました。スプレッドシートからの転記、CSV出力、複数の管理画面への手動登録。「これ、全部本当に必要なんだっけ？」と最初に思ったのを覚えています。「どこから自動化すべきか」を判断するには、まず全体像の棚卸しが必要でした。
そして棚卸しの時点で、こんな問いを必ず一回挟みます：
- そもそもこのステップは必要か？
- なくせないステップはどれか？
- 統合できるステップはどれか？
20ステップの手作業を20ステップの自動化にしても、保守が大変になるだけです。自動化の前に減らすができないかを先に検討します。
② 自動化すべきか：作業と判断を分ける
棚卸しが終わったら、次は自動化していい部分と、しない方がいい部分を切り分けます。
例えば、
- 機械的に繰り返せる作業は自動化の対象にしやすい
- セキュリティやライセンス管理に関わる判断は人を挟む
加えて、こんな観点も毎回チェックします
- 月にどれくらい発生する作業か（年に数回なら自動化のコスパが悪い）
- ミスが起きたときの影響度（取り戻せるか／取り戻せないか）
- 仕様変更の頻度（変わりやすい業務を自動化するとメンテで疲弊する）
なんでも自動化すればいい、というわけではなく、自動化しないという判断も立派な選択肢です。
③ ツール選定：コードを書くか、iPaaSに乗せるか
ここで初めてツールの話になります。
自動化の選択肢は、大きく2系統で考えるとシンプルです。
- コードで書く系：GAS（Google Workspace向け）、Microsoft Graph + PowerShell（Microsoft 365向け）、独自スクリプト・サーバー
- iPaaS系：Make、Zapier、Workato、Power Automate など
それぞれの向き不向きはざっくりこんな感じです。
| コード系（GAS / Graph 等）が向いている | iPaaSが向いている |
|---|---|
| 処理がGoogle / Microsoft のエコシステム内で完結する | 複数SaaSをまたぐワークフロー |
| ロジックがそこそこ複雑で柔軟性が必要 | ノーコード／ローコードで運用を引き継ぎたい |
| ライセンス追加や運用基盤を増やしたくない | エラー監視・リトライをプラットフォームに任せたい |
| 個人や小チーム規模で運用する | 複数チームの自動化を一元管理したい |
正直なところ、お客様環境ではGASやMicrosoft Graphで何とかなるケースが本当に多いです。Google Workspace中心ならGASで「スプレッドシート → Drive → Gmail → カレンダー」が閉じる処理を、Microsoft 365中心ならGraph + PowerShellでEntra ID・Teams・SharePointまわりを、ライセンス追加や運用基盤を増やすことなく扱えます。コードで書ける分、複雑な条件分岐や独自API連携にも柔軟に対応できるのが強みです。
一方で、人事システムの変更を起点に、複数のSaaSへ権限同期しつつチャットに通知、ストレージに専用フォルダを作成して、結果を別シートにログ、のような複数SaaSをまたぐ自動化になると、コードで全部書こうとすると保守コストが跳ね上がります。ここはiPaaS側の強みが効く領域です。
逆に注意したいのは、iPaaSを「とりあえず」で入れてしまうこと。ライセンス費用に加えて、シナリオの保守・障害対応・命名規則・退職者の整理など、それ自体が新しい運用業務になります。コードで済むものをiPaaSに乗せるとオーバースペックになり、運用コストが見合わなくなることもあります。
④ 運用コストの見積もり：書いて終わりではない
自動化した後の維持コストは見落としがちです。
- SaaS側の仕様変更・API変更に追従する必要がある
- 障害が起きたときに気づける仕組み（通知・監視）が要る
- 「これを作った人が辞めたら誰が見るのか」のドキュメントが要る
自動化したら楽になる、は半分正解で、半分は新しい運用の始まりです。だからこそ、運用支援側でも作って終わりにせず、設計書と運用手順書をセットで残すようにしています。
マルチテナント運用には、独特の不便がついて回る
自動化と並んでよく持ち込まれるのが、グループ会社・子会社でGWSやIdPのテナントが分かれているケースの運用相談です。
自動化が「手を動かすところ」だとすると、こちらは「そもそもの前提や境界線がつらい」タイプの悩みです。
「いますぐ全部直さなくてもいい、でもずっとなんとなく困っている」というトーンで持ち込まれることが多く、発火点はたいていグループ再編・子会社統合・新サービス導入のタイミング。腰を据えて整理する時間がなかなか取れない領域です。
マルチテナント運用には、テナントが1つに統合されていれば本来発生しない不便がいくつか付いてきます。製品で吸収できる部分もあれば、運用ルールで受け止めるしかない部分もある。ここでは現場で繰り返し出会った悩みごとを3つ並べてみます。
① カレンダーのクロステナント共有
子会社間でGWSテナントが分割されていると、Googleカレンダーの共有が外部扱いになります。
- 相手の空き時間が見えない
- 会議室予約に苦労する
- 招待されてもリソースの空き状況を確認できない
標準機能でいちばん取りやすいのは、会議室リソースに、外部テナント側のメーリングリストを閲覧権限で追加するあたりです。ただ、これでもユーザー単位の空き状況までは見えません。AppSheetのようなノーコード基盤で予約フローを組む、クロステナント向けのスケジューラ製品を入れる、といった選択肢はありますが、いずれもある程度作り込まないと完全には埋まらない領域です。最終的にどこに着地させるかは、運用負荷・費用・セキュリティとのバランスで判断していくことになります。
同じグループ会社のはずなのに、テナントが違うだけでここまで不便になるのか、という感覚は複数案件で共通していました。
② ファイル・ドキュメント共有の境界線
ファイル共有もテナントが分かれていると一気にややこしくなります。
子会社の人とGoogle Driveでファイルを共有しようとすると外部共有扱いになり、社内向けの共有ルールから外れる。共有ドライブも基本的に1テナント内のものなので、子会社間で同じ場所にファイルを置いて運用したい場合に詰まります。
ここは、個別のリンク共有で対応する、グループ会社共通の共有用テナントを立てる、契約・人事文書だけ別ストレージに集約するなど、組織のセキュリティポリシーと組み合わせて運用ルールで吸収するパターンが多いです。どこに、誰が、何を置いていいかをファイル置き場のグラウンドルールとして明文化しておくのが、地味ですが効きます。
③ ユーザー検索・連絡先の分断
「あの人にメールしたいけど、アドレス帳に出てこない」「Google Meetに招待しようとしたら名前が候補に出てこない」。地味だけど毎日効いてくる不便も、マルチテナントあるあるです。
GWSならディレクトリ共有（共有連絡先）で子会社の連絡先を相互に取り込む構成は組めるので、見える化はある程度進みます。ただ、これで全部が埋まるわけでもありません。共有できるのはGWSテナントに所属している人の連絡先なので、Microsoft 365側の人や業務委託の人はサジェストに出てこないですし、GASやiPaaSから別テナントのユーザーを扱おうとすると、結局テナント側の認証・APIスコープの壁にぶつかります（カレンダーと同じ構造です）。
3つ並べてみて共通して言えるのは、マルチテナント運用は、製品単体で完全解決を目指すよりも、製品の機能と運用のグラウンドルールを組み合わせて現実的なところに着地させるアプローチになりやすいということです。発火点はだいたいグループ再編や新サービス導入のタイミングですが、その時に慌ててゼロから設計するのは大変なので、平時に少しずつ整えておくのが理想と言えば理想です。
運用支援が活きるのは、こんな現場
運用支援がいちばん活きるのは、手を動かす人と、一緒に課題を整理してくれる人の両方が欲しい現場だと感じています。言い換えると、代行でもコンサルだけでも埋まらない「間」を一緒に埋めるときです。具体的にはこんな状況：
- 日々のアカウント発行や問い合わせ対応に追われて、改善や整理に手が回っていない
- 「自動化したい」「ID基盤を整理したい」と思いつつ、何から手をつけていいか決められない
- ナレッジが属人化していて、「あの人しか分からない」が増えてきている
通常のアウトソーシングは、発注者側で課題を特定し、要件を整理して依頼するのが前提です。ただ、情シスの現場では目の前のタスクに追われ、その整理にまで手が回らないことも多い。そこに入って、手を動かしながら課題の輪郭を一緒に詰めていく。
代行ではなく、伴走。これが運用支援の価値なのかなと思います。
おわりに
半年の支援を振り返って強く感じるのは、これらの課題が独立していないということです。手作業の背景にはアカウント発行ルールやID基盤の曖昧さがあり、マルチテナントの不便の背景には共有ルールやディレクトリ設計の難しさがある。個別に直してもすぐ元に戻りやすいのは、こうした課題がつながっているからだと思っています。
だからこそ、現場では「何を自動化するか」だけでなく、「どこまでを機能で吸収し、どこからを運用ルールで受け止めるか」まで含めて、一緒に決めていくのが大事でした。
同じようなことに頭を悩ませている方がいたら、何かの参考になれば嬉しいです。相談したいことがあればお気軽にお声がけください！
