OffboardIT by Stitchflow

退職者アカウント停止の要となるのが、ID基盤が届かないアプリに手を伸ばす力だ。多くのシステムには管理APIがなく、開通機能をエンタープライズ向けプランの後ろに置いている場合もある。SCIMはそこに触れない。Stitchflowは代わりにブラウザエージェントで管理画面を操作する。ローカルで専用のChromiumを動かし、認証情報はOSのキーチェーンに置き、常駐プロファイルを使う。つまり人間が使うのと同じ管理画面を自動処理する。全アプリを網羅できるか、楽な半分だけで終わるかの分かれ目がここにある。

Stitchflowはサービスであり、自分で設定するソフトではない。チームが環境を調査し、ルールと例外を一つずつ記録し、フローを組み、アプリの変化に合わせて動かし続ける。管理画面が刷新されたりAPIが変わったりすれば、提供元が連携を更新する。購入側から見れば、自作スクリプトを書いた担当者が辞めた途端に朽ちていく、あの減衰を避けられる。

実行するたびに記録が残る。サービスは各操作を時刻付きで記録し、オフボーディングのサマリーをSlackやJiraに投稿して、誰を処理し、どのアプリを網羅したかを示す。これが効くのはコンプライアンス審査だ。問われるのは権限を外したかどうかではなく、証明できるかどうかである。記録されたサマリーは、多くのチームが頼りがちなスクリーンショットと表計算の習慣を置き換える。

チームがすでに使っているツールからオフボーディングを始められる。JiraのチケットやSlackのメッセージが処理のきっかけになり、結果も同じ場所に返ってくる。ヘルプデスクの担当は、各管理画面の管理者権限がなくても作業を終えられる。だから一次サポートの担当者でも、上に回さずオフボーディングを閉じられる。

オフボーディングは支出の問題でもある。退職後に残った席は、毎月請求され続ける。Stitchflowは同じ処理の中でライセンスを回収するので、アカウントを閉じるフローがそのまま請求も止める。提供元はこれを支出分析の取り組みと並べて打ち出しており、財務チームにとっては、回収した席がサービス費用を説明する最も簡単な材料になることが多い。

Stitchflowは60以上のアプリと、読むだけでなく書ける深いAPI連携でつながる。各アプリにおけるロール、グループ、最終ログイン、ライセンス状態の意味を理解しているので、停止処理はフラグを一つ立てるのではなく、正しい処理を行う。既定は読み取りで、書き込みはフローが必要とする場面だけ有効になる。