← エピソード一覧に戻る Episode 186 Chapter 1
Chapter 2
Chapter 3
Chapter 4
Chapter 5
0:00 / 0:00
スクリプト
Chapter 1 オープニング ― 使う人より、管理する人で導入が決まる
タカシ
今日は SaaS デザインの管理者UXです。実は導入現場では、一般ユーザー向けの画面が良くても、管理画面が弱いだけで全社展開が止まることがあります。買う人、配る人、守る人の体験が悪いと、SaaS は広がらないんです。
ミカ
たしかに、現場の担当者は使いたいのに、IT 管理者が『設定が重い』『権限が怖い』『退職者処理が面倒』って言うと、一気にブレーキがかかりますよね。管理者UXって、売上にもかなり効きそうです。
タカシ
その通りです。Okta の 2025 年レポートでは、企業が使うアプリ数の世界平均が初めて 100 を超え、前年比 9% 増とされています。アプリが増えるほど、管理者は導入、統制、監査のハブになるので、管理画面の質が事業の伸びを左右します。
ミカ
100 個を超えるアプリを管理するって、もう設定画面を一枚置けば済む世界じゃないですね。今日は、どんな管理体験なら『安全だけど遅い』でもなく、『速いけど危ない』でもないのかを知りたいです。
Chapter 2 原則 ― 管理者UXは四つの仕事で設計する
タカシ
管理者UXで大事なのは、管理者の仕事を『設定』に縮めないことです。実際には、人を追加する、権限を配る、例外申請をさばく、監査ログを追う、担当者不在時に引き継ぐ、という複数の仕事があります。画面もその単位で分けるべきなんです。
ミカ
なるほど。一般ユーザーは『仕事を進める』のが目的だけど、管理者は『みんなが安全に仕事できる状態を保つ』のが目的なんですね。同じ情報設計にすると、必要な操作へ辿り着きづらくなりそうです。
タカシ
はい。特に重要なのが、権限の分解、一括運用、申請と承認、監査と引き継ぎの四つです。権限だけ細かくしても、一括変更や代理対応が弱ければ現場は回りません。統制とスピードの両立こそが、管理者UXの設計テーマです。
ミカ
『安全性のために遅くなる』じゃなくて、『安全だから速く回る』状態を作るわけですね。たしかに管理者が迷わないと、導入も運用もサポートも全部軽くなりそうです。
Chapter 3 実務 ― Google WorkspaceとAtlassianに学ぶ管理導線
タカシ
Google Workspace は一括運用の好例です。CSV での bulk update は 1 ファイル 35MB、最大 150,000 レコードまで扱え、Tasks list で進捗確認、完了後はメールレポートも届きます。管理者UXは、一人ずつ編集しない前提で作るべきだと分かります。
ミカ
150,000 レコードはすごいですね。そこまで扱えるなら、管理画面は『設定の見た目』より『大量処理しても事故らないこと』が大事だと分かります。進捗や結果レポートがあるのも、管理者にはかなりありがたいです。
タカシ
しかも Google Workspace は、権限委譲を organizational unit 単位で絞れる一方、別の管理者の security settings は super admin しか見られないとしています。大量処理は速く、特権操作は狭く、という線引きがはっきりしているんです。
ミカ
全部を見せないのも UX なんですね。権限が強い人向けに情報を寄せすぎると、委譲したい人に渡せなくなるし、逆に広く見せすぎると統制が崩れる。そのバランスが管理者UXの難しさかもしれません。
タカシ
Atlassian も面白いです。organization admin、site admin、user access admin、app admin と責務を分け、さらに access requests は organization 内の全 site から集約一覧で処理できます。利用者が権限不足になった瞬間に request できるのが重要です。
ミカ
つまり管理者UXって、管理画面だけの話じゃなくて、ユーザーが困った瞬間の受け皿まで含むんですね。『申請はメールで』だと記録も残らないし、判断材料も散らばるから、たしかに運用が重くなりそうです。
Chapter 4 設計 ― 外部招待、例外処理、引き継ぎを止めない
タカシ
Figma は外部協力者の扱いが上手いです。guest を free View seat で受け入れつつ、外部招待は『自由』『admin approval 必須』『完全禁止』の三段階から選べます。しかも guest は最初に Ask to be added を出せるので、現場の協業を止めずに統制だけ強められます。
ミカ
それいいですね。外注先や代理店さんと仕事するときって、全部禁止だと遅いし、全部自由だと怖い。段階設定と承認フローが最初からあると、管理者が『例外処理係』になりすぎずに済みますね。
タカシ
Notion と Okta は引き継ぎ設計が参考になります。Notion は guest 招待依頼に page、role、email、申請者を添えて owner が判断できますし、削除したメンバーが 30 日以内に戻れば private pages や group membership が復元されます。Okta ではレビューや承認を期間指定で delegate できます。
ミカ
担当者が休んだり異動したりするのって、むしろ普通ですもんね。そのときに『誰も承認できない』『前の設定が消えた』となると、導入後の信用が一気に落ちそうです。管理者UXは、平常時より例外時で差が出ますね。
Chapter 5 まとめ ― 管理者が迷わないと、全社展開は速くなる
ミカ
今日の失敗パターンをまとめると、一般ユーザー向けUIの延長で作る、権限だけ細かくして運用を設計しない、申請をプロダクト外に逃がす、一括処理や監査ログが弱い、そして引き継ぎ不能な運用にする、このあたりですね。
タカシ
ええ。まずは自社SaaSで、管理者が最初の 30 日に行う仕事を書き出してみてください。初期設定、ユーザー追加、権限変更、外部招待、監査確認、代理対応の六つです。その流れが一画面で見えず、申請や一括処理も弱いなら、そこが改善優先順位です。
ミカ
管理者UXって地味に見えていましたけど、実際は導入の速さ、情報漏えいの防止、サポート工数、監査対応まで全部つながるんですね。『使いやすいプロダクト』の定義に、管理者向け体験も入れないと片手落ちだと分かりました。
タカシ
その通りです。SaaS は利用者の画面だけでは売れ続けません。導入担当者、IT 管理者、運用責任者が『これなら任せられる』と思えることが、継続契約の土台になります。皆さんの管理画面も、ぜひ今日『迷わず回せるか』で見直してみてください。