法人の座席設計の考え方｜誰に何アカウント（非エンジニア向け1枚）

企業のDXが進む一方で、多くの経営者や情シス担当者を悩ませているのが「SaaSのアカウント管理（座席設計）」です。「なんとなく全員分を発行しているが、実は使われていない」「退職者のアカウントが残り続けている」といった課題は、放置すれば多額のコストロスと重大なセキュリティリスクに直結します。

本記事では、非エンジニアのIT担当者や総務・人事の方が、迷わず「誰に、どのツールのアカウントを、どの権限で」付与すべきかを判断できる、座席設計の完全なガイドラインを提示します。

法人の座席設計（ライセンス管理）がなぜ重要か

座席設計とは、社内で利用する各種ITツールのライセンス（座席）を、従業員の役割に応じて最適に割り当てる設計のことです。これが適切になされていない組織では、以下の3つの問題が発生します。

• コストの肥大化：月額数千円のツールも、100名規模で不要な上位プランを契約し続ければ、年間で数百万円単位の損失になります。
• セキュリティの脆弱化：適切な権限管理ができていないと、本来閲覧すべきでない機密情報に誰でもアクセスできる状態になります。
• ガバナンスの崩壊：誰がどのツールを使っているか把握できない「シャドーIT」の温床となります。

特に、SaaSは「1ユーザーあたり月額○円」という従量課金が主流であるため、座席設計の精度がそのまま営業利益に影響するといっても過言ではありません。後述するSaaSコスト削減のフロントオフィス編でも触れている通り、まずはコミュニケーションツールの最適化から着手するのが鉄則です。

【職種別】推奨アカウント・権限マトリクスの作り方

「誰に何のアカウントを渡すべきか」を判断するには、職種ごとに標準的な「IT装備品」を定義するのが近道です。

非エンジニア（営業・企画）に必要な標準セット

営業や企画職の場合、外部とのやり取りが発生するため、基本的には「フルライセンス」が必要になる場面が多いです。ただし、すべてのツールで最高級プランである必要はありません。

• メール・カレンダー：フルライセンス（Google Workspace / Microsoft 365）
• チャット：フルライセンス（Slack / LINE WORKS 等）
• 名刺管理：閲覧・登録権限（Sansan 等）

バックオフィス（経理・人事）の特殊な権限設計

バックオフィス部門は、全社的なツールに加えて、専門性の高いツールを使用します。ここで重要なのは「管理者権限」の集中を防ぐことです。例えば、会計ソフトであれば「承認者」と「起票者」を明確に分離する設計が求められます。詳細はfreee会計導入マニュアルにあるような、役割ごとの権限分離（職能分離）の考え方を参照してください。

外部パートナー（業務委託）へのアカウント発行基準

外部のパートナーに社内アカウントを発行する際は、「ゲスト権限」を活用できるかどうかがコストとセキュリティの分かれ目です。
多くのSaaSでは、正社員向けの「フルメンバー」とは別に、特定の場所だけにアクセスできる「ゲスト」や「マルチチャンネルゲスト」という枠組みを用意しています。

主要SaaS別：座席設計のポイントとコスト削減の秘訣

ツールごとに、ライセンス体系の「落とし穴」があります。代表的なツールの設計ポイントをまとめました。

比較表：主要ツールの座席設計パターン

Slack：マルチチャンネルゲストの活用

Slackのプロプラン以上では、有料ライセンス1つにつき、最大5名までの「マルチチャンネルゲスト」を無料で招待できる仕様（公式ヘルプ参照）があります。特定のプロジェクトに関わる外部パートナーには、フルライセンスを割り当てず、このゲスト枠を活用することで、ライセンス費用を劇的に抑えられます。

Notion：メンバーとゲストの境界線

Notionにおいて「メンバー」はワークスペース全体の設定や他メンバーの追加が可能ですが、非常にコストが高いです。情報の参照や特定のプロジェクトページへの書き込みだけであれば、メールアドレスで招待する「ゲスト」権限で事足ります。

アカウント管理の棚卸しと運用ステップ

理想の座席設計が決まったら、次は現状を整理し、運用を定型化します。このプロセスを怠ると、せっかくの設計図もすぐに形骸化します。

ステップ1：現状のID一覧と利用状況の可視化

まずはスプレッドシート等で「誰がどのツールにログインしているか」を一覧化します。
多くのSaaSには「最終ログイン日時」をエクスポートする機能があります。30日以上ログインしていないユーザーは、ライセンスを回収する候補となります。

ステップ2：不要アカウントの削除とダウングレード

棚卸しの結果、不要と判断したアカウントを削除します。ここで注意が必要なのが、退職者のアカウントです。削除漏れを防ぐためには、SaaSコストと退職者アカウント管理の解説にある通り、ID管理ツール（IdP）や管理デバイスとの紐付けによる自動化を検討すべきです。

ステップ3：入退社プロセスの自動化・半自動化

「入社初日にどのライセンスを付与するか」を職種ごとにパッケージ化しておきます。
例：営業職パッケージ ＝ Google Workspace (Standard) + Slack + Salesforce + Sansan

座席設計でよくある失敗とセキュリティ対策

実務において、コスト削減を急ぐあまりに陥りやすい「罠」があります。

• 共有アカウントの利用：1つの「eigyo-common@company.com」といったアドレスを複数人で使い回す行為。これは多くのSaaSの利用規約で禁止されているだけでなく、誰が情報を持ち出したかのログが追えないため、重大なセキュリティリスクとなります。
• 権限の過剰付与：誰でも「管理者（Admin）」にしてしまうケース。管理者は設定の変更や全データの削除が可能です。原則として管理者は各ツール2〜3名に限定し、日常業務は一般権限で行うべきです。
• 無料版の無秩序な利用：会社が把握していない個人アカウントでの業務利用は、退職時にデータを持ち出される原因となります。会社が管理する「座席」を正しく提供することが、結果的にセキュリティを守ることにつながります。

まとめ：持続可能なライセンス運用を目指して

座席設計は一度作って終わりではありません。事業の拡大やツールの仕様変更に合わせて、定期的な見直しが必要です。特に非エンジニアの担当者が運用を行う場合、複雑すぎるルールは長続きしません。

まずは「主要な3ツール（メール、チャット、ドキュメント）」の座席状況を可視化することから始めてください。それだけでも、年間で数十万円、規模によっては数百万円のコスト適正化が可能です。ITインフラを整えることは、単なる節約ではなく、攻めのDXを実現するための「足腰」を作る作業なのです。