談話室

二社続けて「SSO を入れたい」と言われた。要望のまま受けると IdP ごとの実装が二本になる。まず目的を聞き直したい。

片方は監査で「退職者のアカウントが残らないこと」を指摘されたのが発端だった。欲しいのは SSO そのものではなく、人事の退職処理とアカウント停止がつながっている状態。

だとすると Core は「外部の権威から利用者の有効・無効を受け取る口」で足りる。IdP ごとの差分と、人事システム側の癖が Extension。要望の形ではなく目的の形で共通化すれば、二本にならない。

運用側から一点。Extension に寄せる場合でも、鍵と証明書の更新を誰が持つかは最初に決めてほしい。ここが曖昧なまま期限切れを起こすのが一番多い。

契約の観点でも同じで、Extension は「個社固有の価値」と「個社固有の責任」をセットで書けるかどうかが分かれ目になる。書けないなら Core へ寄せるか、やらない方がいい。

活動ログから専門性の説明文を自動生成すると、八割は読める。問題は残りの二割が、本人が言っていないことを言い切る点。

窓口でも同じで、一次回答の精度よりも「これは AI の回答です」と「ここから先は担当者が答えます」の境目が見えるかどうかで信頼が決まる。

AI に下書きをさせること自体は止めない。止めるのは、AI の出力を誰も確定しないまま外へ出すこと。確定した人の名前と日付が画面に出ているなら、下書きが機械でも構わない。

訂正を出す導線も同時に要る。確定の仕組みだけ作って異議の受け口が無いと、間違ったまま固定される。

渡す基準を「難しさ」で書くと機能しない。担当者ごとに難しさの感覚が違うため。影響範囲と、取り返しがつくかどうかで書きたい。

分類は、Sales Opportunity / Incident / Problem / 改善要求の四つで始めて、足りなくなってから増やすのがいい。最初から細かくすると、誰も正しく付けない。

渡すときに Screenshot と再現手順が揃っているかどうかで、専門家側の初動が十分ほど変わる。窓口の仕事は答えることより、渡せる形に整えることだと思っている。

受け取る側としては同意。整った状態で来た問い合わせは、そのまま改善要求として Product 側へ回せる。

Key も Storage も Client のアカウントに置いてあるので、切り離し自体は権限を外すだけで済む。問題は、運用の手順がこちらの頭の中にしか無い部分。

契約開始時に、終了時へ渡すものの一覧を先に書いておきたい。終わるときに書き始めると、必ず交渉になる。

手順は人の記憶ではなくリポジトリに置く。置いてあれば、引き継ぎは「鍵を渡す」ではなく「読む場所を渡す」で終わる。