従業員セルフサービスの、見えないもう半分

ここ数か月、私は従業員セルフサービスの開発に取り組んできました。その間に最も多くを教えてくれたのは、言語モデルでも連携機能でもありません。「仕事がどう依頼されるか」の中にある、ある小さな非対称性でした。

業務委託の担当者が、2週間だけ強い権限を必要とする。誰かが申請を承認し、誰かがアクセス権を付与し、そしてチケットはクローズされる。では2週間後、そのアクセス権を誰が剥奪するのか？　ほとんどの企業では、誰も剥奪しない。「権限を失いたい」というチケットを起票する人などいないからだ。付与には申請者がいた。剥奪にはいない。だから、誰かが思い出すまで、あるいは四半期ごとのアクセスレビューまで放置される――どのプロセスも取り上げなかったアクセス権を回収するためだけに存在する、コンプライアンス上の儀式まで。

一見、これは例外的なケースに見える。しかし私は、これこそが問題の全体像を凝縮したものだと考えている。

チケットは、そもそも問題を解決するために作られたものではない。人間を調整するために作られたものだ――申請を受け取り、キューに入れ、誰かに割り当て、クローズまで追跡する。その仕事のためには、実に優れた設計だ。あまりに優れていたために、いつの間にか「あらゆるものを測る単位」になってしまった。従業員セルフサービスツールがどう評価されるかを見てみよう。チケットあたりコスト、解決までの時間、初回接触での解決率。

そのすべて、しかも音声1分あたりのコストに至るまでベンチマークを公開している企業さえある。だが、これらの指標はどれも「チケットの属性」でしかない。

そのどれ一つとして、従業員の問題が実際に解決したかどうかは測っていない。

そしてチケットは、誰かが何かを依頼したときにしか存在しない。業務委託担当者のアクセス権を回収するような、誰も依頼しない仕事は、この仕組み全体から完全に見えないままだ。

企業が従業員セルフサービスを本格展開しようとするとき、たいていはパスワードリセットから着手する。それは理にかなっている。だが、リセット申請とは実際には何なのかに注目する価値がある。機械的な部分は、セルフサービスツールがとうの昔に処理している。

それでも人がヘルプデスクにたどり着くとき、その人は本当はパスワードについて尋ねているのではない。締め出されていて、欲しいのは「アクセス権を取り戻すこと」なのだ。最も古典的な申請でさえ、その正体はアクセス申請である。

それはただ、最も単純なアクセス申請にすぎない――システム1つ、操作1つ、承認なし。何が壊れているのかを見せてくれる申請は、もっと上の階層にある。「誰が何を使えるのか」だ。そしてリセットがそうであるように、ここでもアクセスそのものが本質なのではない。

アクセス申請は、チケットが破綻する様子を最も鮮明に観察できる場所にすぎない。なぜならそれは、チケットが答えるようには決して作られなかったあらゆる問いを、否応なく突きつけるからだ。

どのITチームも絶えず受け取る申請を例に取ろう。ある従業員が月曜から新しい役割に就くため、レポーティングダッシュボードへのアクセスが必要になる。これを「振り分ける」のではなく「解決する」には、何が必要だろうか。まず、その人物が誰なのかを知らなければならない。新しい役割によって何が許可されるのかを知らなければならない。

そのアクセスに承認が必要かどうか、必要なら誰の承認かを知らなければならない。そのうえで承認を取得し、アクセス権が実際に管理されているアイデンティティシステムに変更を加え、行ったことを記録する。このほとんどはAIの仕事ではない。アイデンティティ、権限（エンタイトルメント）、ポリシー、そして「別のシステムに変更を書き込む能力」である。どれも昔からある問題だ。

アクセス申請は、業界のお気に入りの指標をも破綻させる。

従業員セルフサービスAIで最も誇らしげに語られる数字が「ディフレクション（自己解決率）」だ。つまり、従業員に適切な記事を提示できたおかげで、そもそも起票されなかったチケットの数である。だが、アクセス権を付与してくれる記事など存在しない。アクセス申請はディフレクションできない。権限を伴って、記録システムの中で「実行」されなければならないのだ。

読み取って提案することしかできないツールは、モデルがどれほど優秀であろうと、このカテゴリーにはまったく手を触れられない。

オンボーディングとオフボーディングは、同じ問題を規模で拡大したものだ。オンボーディングとは、入社日に紐づいた数十件の権限付与であり、それはアイデンティティプロバイダー、人事システム、デバイス管理、そして無数のSaaSツールにまたがって散らばっている。

誰もがその失敗を目にしたことがある。新入社員が最初の1週間、同僚のログインを借りて過ごすようなケースだ。オフボーディングはその鏡像であり、そしておそらく、より深刻に懸念すべきものだ。というのも、その失敗モードは「遅さ」ではなく「不完全さ」だからだ。チケットのチェックリストとして処理された退職手続きは、チェックリストの網羅性以上には正確になりえず、漏れたアカウントは自ら名乗り出てはくれない。

企業はオンボーディングの失敗にはすぐ気づく。新入社員が不満を言うからだ。だがオフボーディングの失敗には、ずっと後になって、あるいはまったく気づかないことも多い。

この領域で開発を始めたとき、私の視点を作り直してくれたのは、「言語モデルは最も重要でない構成要素に近い」と気づいたことだった。モデルが効いてくるのは入口の部分――雑然とした人間の依頼を構造化された依頼へ翻訳する場面だ。それこそ、旧来のセルフサービスポータルが決して解決できなかった部分である。誰も正しいフォームを見つけられなかったのだ。

だが、モデルの背後にあるものはすべて「配管（プランビング）」であり、その配管こそが結果を決める。これまで従業員セルフサービスに導入されてきたAIツールの多くは、配管のないモデルだ――読み取り専用のAPIアクセス、セッションごとにゼロから再構築されるコンテキスト、記述対象のシステムが毎週変わるのに手作業で保守されるナレッジ記事。モデルに、記憶を持たない読み取り専用の世界を与えれば、できることは質問に答えることだけになる。だから、それしかしないのだ。

欠けているピース――記録システムへの書き戻し――が欠けているのには理由がある。読み取りは安全だ。書き込みは物事を壊しうる。誤った回答は数分を無駄にするだけだ。だが誤った操作は、業務委託担当者にドメイン管理者権限を与えたり、別人のアカウントを削除したりする。企業がこの2つを区別して扱うのは正しい。私が関わったすべての導入で、実際のクリティカルパスはテクノロジーではなくセキュリティレビューだった。そして私は、それこそが本来あるべき姿だと考えるようになった。

私が最も驚いたのは、あるカテゴリーが自動化されるかどうかを決めるものは何か、という点だった。それは技術的な難易度ではない。「ポリシーの明確さ」である。標準的なソフトウェアのアクセス権はきれいに自動化できる。実行が簡単だからではなく、組織がそれについて曖昧さのないルールを持っているからだ。

自動化に抵抗するカテゴリーは、2つのうちいずれかの形で失敗する。1つは、そもそも誰もルールを書き留めていなかった場合。業務委託担当者の強い権限を誰が承認するのか？　「場合による」。何によって？　ベテランIT担当者2人の頭の中にあるものによって、だ。もう1つは、ルールは書かれていたが、散在していた場合である。

私たちが支援したある大企業では、新入社員が機微なデータストアへのアクセスを申請すると、数百時間も待たされることがあった。誰かが怠けていたからではない。権限（エンタイトルメント）は1つのシステムに、アイデンティティは別のシステムに存在していたからだ。

そのため、人間がその人物が誰かを確認し、何の権限を持つべきかを調べ、直属の上司でない場合は承認者が誰かを突き止め、その承認者を追いかける必要があった。ルールは存在していた。ただそれが3つのシステムと2人の頭の中に散らばっていて、チケットごとに誰かが手作業で再構築していたのだ。

いずれにせよ、人々はその隙間を「判断」で、1件ずつチケット単位で埋めていく。それこそが、まさにスケールしないやり方だ。このループから人間を外すことは、結局のところ、組織に自らのポリシーを「完全に、かつ一箇所に」明文化させる作業にほぼ等しい。テクノロジーは、むしろ簡単な部類なのだ。

私はこれをDevRevで手がけているので、その分は割り引いて読んでほしい。既存プレイヤーがなぜ「解決」を軸に作り直してこなかったのかを問うのは正当だ。一つには、書き戻し、永続的な状態、そしてデータレベルの権限を、20年前のチケッティングアーキテクチャに後付けするのが本当に難しいからだ。

そしてもう一つには、彼らの収益が人間のエージェントとチケットの数に比例して伸びるからだ。それは誰かが不誠実だという意味ではない。ただ、チケットを消し去るインセンティブが、チケットを保有する企業の外側にある、というだけのことだ。

この移行にどれだけ時間がかかるかは分からない。企業はこの領域では――多くはもっともな理由で――ゆっくりとしか動かない。そして「行動するシステム」への信頼は、退屈なものから始めて、1カテゴリーずつ勝ち取っていくことになる。だが、アーキテクチャが本当に変わったかどうかを見極める私のテストはシンプルだ。

誰かが会社を去るとき、その人のアクセス権は、誰かが依頼せずとも、その日のうちにすべてのシステムから消えるだろうか？　今日、その答えはほぼ常に「ノー」だ。それが「イエス」になる日、チケットは仕事の単位であることをやめているだろう。