本記事は「Delegation Is a Form of Respect. Here's What That Actually Means.」を翻訳した記事です。
What the SaaS?!のエピソード1ではアイデンティティの壁について定義しました。エピソード2ではアーキテクチャの基盤を築きました。エピソード3ではOINとExpress Configurationを使用して信頼構築までの時間を短縮する方法について話しました。
エピソード4ではすべてが機能した後に何が起こるかを問いかけます。エンタープライズ顧客が稼働を開始しました。次はどうなるでしょうか。
顧客は製品内で独自の環境を運営する必要があります。そして委譲管理を解決していなければエンタープライズ対応を実際に解決したことにはなりません。問題を先送りしただけです。
Auth0のシニアプロダクトマネージャーであり委譲管理製品をリードするBrittany Rothを招きました。彼女が気づかせてくれたのは委譲管理がUXの問題や運用の問題ではないということです。信頼の問題です。そして間違えると摩擦が生じるだけではありません。一生懸命築き上げた関係を損ないます。
誰も語らない運用の現実
会話はあるシナリオから始まりました。100社目のエンタープライズ顧客を獲得したばかりのB2B SaaS企業です。理論上は素晴らしい日です。実際には委譲管理を解決していなければ苦労の始まりです。
Brittanyは苦労がどのようなものかについて率直に語りました。
「ユーザーの追加、SSO接続の更新、ドメインや証明書のローテーションなど日常的な変更がすべてサポートチケットになります。そしてチケットを提出するIT管理者は初心者ではありません。自社のアイデンティティスタックやネットワークを運営する人々です。自身の環境を管理する能力は十分にあります。ただ許可されていないだけです。」
印象に残りました。優秀なIT管理者が1つのシステムに1人を追加するためにチケットを提出するのです。特別な種類のフラストレーションです。そして契約するエンタープライズ顧客が増えるごとに倍増します。
逆も同様に悪いです。チケットのキューを完全にスキップし顧客にスーパー管理者のログインを渡してうまくいくことを祈る企業もあります。両極端は失敗します。答えはBrittanyがスコープ付きセルフサービスと呼ぶものです。
スコープ付きセルフサービスとは何か
スコープ付きセルフサービスはシンプルに聞こえます。顧客に必要なものだけに管理者アクセスを与えそれ以上は与えません。実際には境界線を正しく引くことは分野でより難しい設計問題の1つです。
Brittanyは機能した場合にどのようになるかを説明しました。顧客はチケットを開くことなくメンバーの招待、ロールの割り当て、退職する従業員のオフボーディング、SSOの設定、ドメインの管理を行えます。しかし他の顧客のデータを見たりテナントレベルの設定に触れたり組織を超えて波及するようなことを誤って行ったりはできません。
「境界のないアクセスは制御ではなく混沌です。真の制御とは設定を変更したときに何が起こるか、誰に影響するか、いつ有効になるかを管理者が正確に把握していることを意味します。」
アクセスを支えるセキュリティはオプションではありません。Brittanyは常に立ち返る4つの原則を概説しました。
- プラットフォーム層の分離（境界はアプリケーションコードではなくAPIに存在します）。
- 何も信頼せずすべてを検証する（組織IDはURLではなく署名付きトークンに存在します）。
- 意図的に適用される最小特権。
- SaaSベンダーが顧客の管理者が設定できる上限を設定できるテナントレベルのガードレール。
4つがなければ顧客に安全にセルフサービスの権限を与えることはできません。錯覚を与えることしかできません。
ほとんどの管理者ツールはユーザーに完璧であることを求める
会話の最も興味深い部分は設計哲学、特に恐怖についてでした。
エンタープライズIT管理者は重要なインフラストラクチャを管理します。自身のシステムから誰かを締め出したことがあるか同僚がそうするのを見たことがあります。経験は臆病にするのではなく慎重にさせます。そしてツールは自信を持って行動するのを助けるか抜き足差し足で歩くことを強いるかのどちらかです。
Brittanyの枠組み。リスクの高いインターフェースにおける恐怖は不可逆性から来ます。
「管理者の脳は保存を押す前に1つの質問をしています。間違えた場合元に戻せるか。答えがイエスなら試してみようとします。答えがノーなら凍りつきます。」
したがって質問する前に答えるセーフティネットを構築します。
- 本番稼働前に実際のログイン試行に対してSSO設定をテストできるようにします。
- 適用する前に何が変更されるかを正確に示します。
- 1人の管理者のエラーが他の誰にも影響しないようにミスを単一の組織に限定します。
- 最悪のケースを想定して設計します。すべての予防策が失敗し誰かが会社全体を締め出してしまった場合サポートチームに電話することなく復旧できる経路が必要です。
「管理者が失敗からセルフサービスで抜け出せない場合元の問題を実際に解決したことにはなりません。場所を移動しただけです。」
管理者もあなたの顧客である
Brittanyが最後に述べた考え方の転換は何度も立ち返るものです。IT管理者を第一級のユーザーとして扱うことです。内部ツールとしてではありません。二次的なペルソナではありません。営業のチェックリストを満たすためにスプリントの終わりに急いで作成するダッシュボードではありません。
「エンドユーザーだけを喜ばせる製品は簡単に置き換えられます。エンドユーザーを喜ばせ管理者が信頼するために必要なもの、つまり明確さ、制御、予測可能性を提供する製品は10年間組み込まれたままになります。それがツールとパートナーの違いです。」
会話の前に十分に理解していなかったのは取引が成立する前に管理者体験がどれほど現れるかということです。プラットフォームがカスタムのロールベースアクセス制御（RBAC）、詳細な監査ログ、System for Cross-domain Identity Management（SCIM）、きめ細かな権限をサポートしている場合セキュリティレビューは数か月にわたる尋問から短い形式的なものに変わります。会話は「製品はXを行えますか」から「Xのためにどのように設定しますか」に変わります。変化こそが真の成熟のシグナルだとBrittanyは言いました。
そして取引成立後。製品をアイデンティティスタック、監査パイプライン、自動化に組み込んだIT管理者はどこにも行きません。他のものを探すことすらありません。顧客の成長が自社の成長になります。
一度にすべてを構築できない場合はどこから始めるか
エンジニアリングの帯域幅が限られているSaaSチーム（ほとんどがそうです）に対してBrittanyは明確な答えを持っています。アイデンティティプロバイダー管理を第一に。SSOだけでなくドメイン、SCIMプロビジョニング、属性マッピングも含みます。エンタープライズのアイデンティティプロバイダー（IdP）設定全体です。
アイデンティティプロバイダー管理は同時に最も大量のサポート要因でありエンタープライズ顧客が最も自身で制御したい機能でありエンタープライズ対応の最も明確な単一のシグナルです。なければ100人以上の企業のセキュリティチームやITチームはドアに入る前にブロックします。
良いニュースがあります。ゼロから構築する必要はありません。Auth0のMy Organization APIと埋め込み可能なUIコンポーネントにより事前構築されたブランド化可能なインターフェースをすぐに利用できます。数か月の統合ではなく数日で済みます。
エンタープライズ顧客との異なる関係を構築する
適切に行われた委譲は敬意の表れです。自身の環境を運営することを信頼していると伝えます。安全にするためのガードレールを構築しました。ミスをしたとき（誰もがミスをするのでミスは起こります）電話することなく回復できるように設計しました。
正しく理解しているSaaS企業はサポートコストを削減するだけではありません。顧客と異なる種類の関係を構築します。IT管理者が摩擦点ではなく擁護者となる関係です。成長が営業に依存するのではなく自己強化される関係です。製品が非常にうまく機能するため顧客が意識することなくただ機能する関係です。
エンタープライズ顧客が基本的な管理者の変更を行うためにまだチケットを提出している場合サポートの問題ではありません。製品の問題です。そして非常に解決可能な問題です。プラットフォームに真の委譲管理をもたらす方法について詳しくはチームに相談してください。
詳細をすべて聞くにはWhat the SaaS?!の完全なエピソードを聴いてください。
About the author
Sheena Allan
Product Manager