こんな状態になっていませんか？
| チャット | 勤怠 | 販売管理 | 会計 | 銀行 | 案件管理 | ||
|---|---|---|---|---|---|---|---|
| Google連携 | ID＋PW | ID＋PW | ID＋PW | 電子証明書 | Google連携 | ||
| 山本さん6/30 退職 | 止めた | 止めた | まだ 入れる1 | まだ 入れる1 | — | — | 止めた |
| 佐藤さん7/1 入社・営業 | 作った | 作った | ？2 | ？2 | — | — | 作った |
| この表は、どこにも無い。誰がどこに入れるかは総務の頭の中だけ3 | |||||||
ログインの仕組みがバラバラ（GoogleID＋PW電子証明書）なので、Google を止めても ID＋PW のシステムは個別に止めないと残る。入社のときも同じで、システムごとに別々の担当へ依頼が要る。
退職した人の ID が、まだ生きている① 止め忘れ ② 入社日にまだ入れない ③ 一覧が無く属人化
このデモの場面設定
- 今日は 7/1（火）。あなたは架空の「サンプル株式会社」（社員 8 名）の総務担当・岡本さんです。会社では 7 つのシステムを使っていて、ログイン方法はバラバラです。
- 昨日 6/30 で山本さんが退職しました。Google のアカウントは止めましたが、Google と連動していないシステムには ID が残っています。台帳がそれを検知しています。
- 今日 7/1 に佐藤さんが営業として入社します。「営業」の役割に必要なシステムの一覧から、入社チェックリストが自動で作られます。
※ このデモの操作はすべてこのページ内（お使いのブラウザ内）で動いています。各システムへの実際の操作（ID の停止・作成）は行いません。データも履歴もサーバーへは送信されません。
ログインの手間について、できること・できないこと
- できない他社のシステム同士のログインを、こちらの開発でひとつにする。相手のシステムのログイン画面は変えられません。画面操作で ID とパスワードを自動入力する類の仕組みは規約違反になりやすく壊れやすいので、TMR ではお勧めしません。
- 相手次第Google Workspace や Microsoft のアカウントで各システムに入れるようにする（SSO）。相手のシステムが SSO（SAML / OIDC）に対応していれば「設定」で束ねられます。ただし上位プラン限定のことが多く、小さな業務ソフトは非対応が普通です。導入・更新のときに「SSO 対応プランか」を選定基準に入れる、という助言はできます。非対応なら、パスワード管理ツール（1Password / Bitwarden 等）で入力の手間だけ減らすのが現実解です。
- できるTMR が作るシステムは、最初から Google / Microsoft のアカウントでログインできる形で作る。少なくとも「ログイン先を増やさない」ことは約束できます。またこの台帳のように「誰がどこに入れるか」を1か所で管理し、入退社の作業と退職者の ID 残りを仕組みで拾うことは、相手のシステムに関係なく作れます。
会社で使っているシステム（ログイン方法と SSO 対応）
台帳が検知していること
アカウント台帳（人 × システム）
上の「退職処理を始める」「入社処理を始める」を押すと、ここにシステムごとのチェックリストが出ます。
台帳の変更履歴
| 日時 | 対象 | システム | 内容 | 実施者 |
|---|
このデモの作り方の考え：ログインそのものより、「誰がどこに入れるか、誰も把握していない」ことの方が実務では重い問題です。退職者の ID が残るのは悪意ではなく、「7 つのシステムのうち 2 つを忘れた」だけで起きます。台帳は各システムを操作しません。「このシステムは誰が止めるか」を決めておき、やったかどうかを記録するだけです。それでも「忘れた」は無くなります。
役割ごとのテンプレート（営業なら販売管理＋チャット＋Google、経理なら会計＋ネットバンキング……）を持っておくと、入社時に「何が必要か」を毎回考えずに済みます。SSO 配下のシステムは Google の停止で自動的に入れなくなるので、チェックリストにも「自動」と出ます。ここが SSO 対応プランを選ぶ実利です。
仕組みとしては小さな Web アプリで、共有レンタルサーバーの構成で動きます。各システムが API を持っていれば「ID の有効・無効を台帳から実際に確認する」ところまで広げられます（相手次第なので要件定義で確認します）。同じ「間」の作業として、CSV のレイアウト変換は システムの間 ①、請求と入金の突合は システムの間 ② をご覧ください。