シングルサインオン（SSO）、承継後のアカウント管理を楽にする

結論から言えば、シングルサインオン（SSO）は「先代が現場感覚で回していたアカウント管理」を、承継後の自分が仕組みとして引き継ぐための最も現実的な一手です。パスワードを何十個も覚える必要がなくなる、という利用者側のメリットだけで語られがちですが、経営者にとっての本質的な価値はそこではありません。退職した社員のアカウントが消えずに残っている、パートさんが辞めたのにいつまでもクラウド勤怠にログインできる、先代しか知らないIDが5個も6個もある——そうした「見えない放置アカウント」を、たった一つの操作で一括に無効化できるようにする仕組みだという点にあります。

こんな状態に心当たりがある方に、この記事は特に読んでほしいと思っています。先代から会社を継いで半年から数年、事業自体は順調に回っているのに、パソコンやクラウドサービスのアカウントが「誰が何を使っているか分からない」まま放置されている。総務担当のベテラン社員に聞いても「昔からこうだから」としか答えが返ってこない。退職者が出るたびに、本当にアカウントを止められているのか不安になる。そんな漠然とした不安を抱えている二代目・三代目の経営者は、決して少数派ではありません。

株式や不動産の登記、税務、労務については、税理士や司法書士、社労士という「相談できる専門家」が最初から用意されています。ところが会社の中で動いているクラウドサービスやパソコンのアカウントについては、相談する相手がいないまま自分で何とかするしかない、という孤独感を抱えている経営者は多いはずです。この記事では、その孤独感を少しでも軽くするために、SSOという仕組みが承継後の会社にとって何を解決してくれるのか、そしてどう導入を検討すればいいのかを、できるだけ実務に近い言葉で解説していきます。

SSOとは何か、まず一言で言うと

シングルサインオン（SSO） とは、一度のログインで複数のクラウドサービスやシステムにまとめてアクセスできるようにする認証の仕組みです。社員は毎回別々のIDとパスワードを入力する必要がなくなり、一つの認証情報でメール、勤怠管理、会計ソフト、営業支援ツールなど複数のサービスに入れるようになります。ここまでは「便利になる」という話として紹介されることが多いのですが、経営者として本当に注目すべきは、この仕組みが同時に「管理する側」にもたらす変化です。

似たような略語として、IDaaS（Identity as a Serviceの略）という言葉もよく登場します。IDaaSはSSOの機能を含む、クラウド上でID・認証情報全般を管理するサービスの総称だと理解しておけば十分です。SSOという「認証をまとめる仕組み」を、クラウドサービスとして提供してくれるのがIDaaSだ、という関係性です。中小企業がSSOを導入する際は、多くの場合このIDaaS型のサービスを契約する形になります。自社サーバーに専用の認証システムを構築するようなオンプレミス型の対応は、情シス担当者がいない会社にとっては現実的ではないため、基本的にはクラウド型のIDaaSを前提に検討を進めるのが実務的です。

なぜ承継直後にSSOの話が出てくるのか

先代の時代は、会社の規模も社員の数も少なく、パソコンとID・パスワードの管理は「総務のベテラン社員の頭の中」で完結していたケースが少なくありません。誰がどのサービスを使っているか、誰が退職済みで誰がまだ在職しているか、その情報は暗黙知として引き継がれてきました。ところが代替わりのタイミングで、この暗黙知の継承がうまくいかないことが頻繁に起こります。先代は退任し、当時のIT担当だった社員も高齢化や退職で会社を離れていく。結果として、誰も全体像を把握していないアカウント管理が、承継後の会社に残されるのです。

さらに承継のタイミングでは、事業の拡大や業務の見直しに合わせて新しいクラウドサービスを導入する機会も増えます。先代の時代からある古いサービスに加えて、新しく契約したサービスのアカウントが積み重なっていくと、管理すべきIDの数はあっという間に二桁、三桁に膨らんでいきます。この「増える一方で減らない」という構造こそが、承継後の会社にアカウント管理の見直しを迫る本当の理由です。新しく何かを始めるたびに、古いものの後始末が追いつかなくなっていく。これは規模の小さい会社ほど陥りやすい罠だといえます。

退職者アカウントの放置は「よくあること」ではなく「危険なこと」

まず事実として押さえておきたいのは、退職者や異動者による情報漏えいが、企業の情報漏えい原因の中でも極めて大きな割合を占めているという指摘です。退職済みの社員のアカウントが削除されずに残っていると、そのIDとパスワードを使った不正アクセスは、ログ上では「正規ユーザーの操作」に見えてしまい、発覚が非常に難しくなります。中小企業では特に一人ひとりのアカウントに広い権限が与えられている傾向があり、被害が発生した場合の影響範囲も大きくなりやすいという点も見過ごせません。

IPA（情報処理推進機構）が公開している「中小企業の情報セキュリティ対策ガイドライン」でも、内部不正防止の観点から、退職や異動によって不要になったユーザーIDとアクセス権限は速やかに削除することが求められています。これは大企業だけの話ではなく、従業員10名から100名規模の会社であっても同じように当てはまる原則です。

このガイドラインが強調しているのは、内部不正は外部からのサイバー攻撃と同じくらい、あるいはそれ以上に警戒すべきリスクだという点です。退職者による情報漏えいというと、悪意を持った持ち出しを想像しがちですが、実際にはそこまで極端な話でなくとも、単に「アカウントが残っていた」という事実だけで、会社は説明責任を問われる立場に置かれます。取引先から個人情報の管理体制について問い合わせを受けたときに、「退職者のアカウントを何年も止め忘れていました」とは、どの経営者も答えたくないはずです。仕組みで対応しておくことは、いざというときの説明責任を果たすための備えでもあります。

退職済みの社員のID・パスワードが残っていると、それを使った操作は正規ユーザーの操作と見分けがつかず、発覚が遅れやすい。中小企業では一人当たりの権限が広い傾向があり、被害が拡大しやすい。

承継後の会社で起きやすい「アカウント放置」の具体例

実際に承継後の会社でよく見られるパターンを整理してみます。

• パートタイムで働いていたスタッフが退職したが、勤怠管理システムのアカウントがそのまま残っている
• 先代の時代に導入したクラウドサービスのIDが、誰の管理下にあるかも分からないまま動いている
• 退職した営業担当者が使っていた営業支援ツール（SFA）のアカウントに、今も顧客リストがアクセス可能な状態で残っている
• 総務担当者が把握しているのは「よく使うメール」だけで、それ以外のサービスのアカウント一覧が存在しない
• パスワードが共有の紙のメモやExcelファイルで管理されており、誰が何を知っているか分からない

こうした状態は、多くの場合「悪意があって放置した」わけではなく、単に「誰が退職者アカウントを消す責任者なのかが決まっていなかった」だけというケースがほとんどです。だからこそ、属人的な運用に依存しない仕組みが必要になります。この属人化した管理体制そのものが、承継時に最も引き継ぎづらい負債になりがちです。この状態を 属人化 と呼びますが、アカウント管理はその典型例だといえます。承継後のクラウド移行の進め方全体を見渡したい場合は、承継後のクラウド移行はどこから始めるかも参考になる。

さらに厄介なのは、こうした放置アカウントの多くが「業務上まったく必要ないのに、誰も止める判断をできない」という中途半端な状態のまま眠っていることです。総務担当者からすれば、自分の管理範囲外のサービスのアカウントを勝手に止めてよいものか判断がつかず、経営者からすれば、そもそもそのアカウントの存在自体を知らない。誰も悪くないのに、誰も止められない。この構造自体を変えるには、個人の判断力や注意力に期待するのではなく、仕組み側でアクセス権限をコントロールする発想への転換が必要です。

SSOが解決する3つのこと

SSOを導入することで、承継後の会社が抱えやすい課題のうち、少なくとも次の3点が改善されます。

第一に、退職者対応の一括化です。SSOの認証基盤で一つのアカウントを無効化するだけで、連携している複数のサービスへのアクセスがまとめて止まります。個別のサービスごとに「このIDを止めてください」と一つひとつ手作業で依頼する必要がなくなるため、対応漏れの可能性そのものが小さくなります。

第二に、アカウントの全体像の可視化です。SSOを導入する過程では、そもそも「社内でどのクラウドサービスが使われているか」を棚卸しする作業が発生します。この棚卸し自体が、承継後の経営者にとって非常に大きな価値を持ちます。今まで誰も把握していなかった契約中のサービス一覧が初めて明文化されるからです。

第三に、パスワード管理の負担軽減です。社員が個別にパスワードを覚える必要が減ることで、パスワードの使い回しや、メモへの書き置きといった危険な運用が減っていきます。パスワードの使い回しは、一つのサービスで情報が漏れた場合に他のサービスへも被害が広がる典型的な原因であり、SSOはこのリスクを構造的に下げます。

この三つの効果は、それぞれ独立しているわけではなく、互いに補強し合う関係にあります。棚卸しによって全体像が見えるからこそ退職者対応を一括化できるようになり、一括化の仕組みが定着するからこそパスワード管理の負担も自然と減っていく。個別に一つずつ対策を打つのではなく、SSO導入という一つの取り組みを通じて、三つの課題を同時に解決できる点こそが、限られた時間とリソースしかない承継直後の経営者にとって効率のよいアプローチになる理由です。

情シス担当者がいない会社でも導入できるのか

「うちには情報システム部門なんてない、総務が兼務でパソコンを見ているだけだ」という会社は非常に多いはずです。しかし現在のSSO・IDaaS（Identity as a Serviceの略で、クラウド上でID管理を提供するサービス全般を指します）市場では、専門の情シス担当者がいない中小企業でも導入できるサービスが増えてきています。

Microsoft 365 Business Premiumのような、日常的にすでに使っているオフィスソフトのプランに、SSOの基盤となる機能が標準搭載されているケースもあります。すでに契約しているサービスの中に、追加コストなしで使える機能が眠っていることも珍しくありません。まず自社が契約しているサービスのプラン内容を確認するところから始めるのが、遠回りに見えて実は最短ルートです。

また、近年のIDaaSベンダーは中小企業を主要な顧客層として想定した製品設計を進めており、管理画面の操作性も年々分かりやすくなってきています。数年前までは「導入するにはある程度の専門知識が必須」というイメージが強かった分野ですが、現在では初期設定の大部分をベンダー側のサポート担当者が代行してくれるプランも増えています。情シス担当者がいないことを理由に導入を諦める必要はなく、むしろ「情シス担当者がいないから、代わりに手厚いサポートのあるサービスを選ぶ」という発想で選定基準を立てるのが合理的です。

導入前に確認しておきたい社内の状態

SSOを導入する前に、承継後の経営者としてまず把握しておくべきことがあります。それは「今、会社の中でどんなクラウドサービスが使われているか」の一覧です。これがないままSSO導入の相談をベンダーにしても、話が前に進みません。

具体的には、次のような情報を最低限洗い出しておく必要があります。

この一覧表を作る作業自体が、実は承継後のIT管理を立て直す第一歩です。多くの会社では、この一覧表がこれまで一度も作られたことがありません。こうした情報を一元的に記録しておく仕組みを システム管理台帳 と呼び、SSO導入の前提としても欠かせない土台になります。

この一覧表を作る過程では、思わぬ発見が続くことも珍しくありません。もう誰も使っていないはずのサービスに毎月の課金が発生していた、退職して3年経つ社員のアカウントが有効なまま残っていた、契約更新の通知メールが先代の使っていなかったメールアドレスに届き続けていた——こうした事実は、実際に一つひとつのサービスにログインして確認してみるまでは、誰にも見えていません。手間のかかる作業ですが、この段階を丁寧に行うほど、その後のSSO導入がスムーズに進みます。退職者アカウントの棚卸しを仕組み化する具体的な手順は、退職者アカウントの棚卸しを仕組み化するにまとめている。

先代への配慮とアカウント管理の話をどう切り出すか

承継直後の経営者から相談されることが多いのが、「先代が現役の頃に決めた仕組みに口を出すのは気が引ける」という悩みです。特にアカウント管理のように、これまで先代や古参の総務担当者が長年守ってきた運用に手を入れることは、単なる業務改善ではなく人間関係の問題として重く感じられることがあります。

ここで大切なのは、「今までのやり方が悪かった」という話にしないことです。先代の時代は会社の規模も社員数も違い、当時のやり方が当時の状況には合っていた、という前提を明確に伝えることが第一歩になります。そのうえで、「会社が大きくなった今、退職者や異動者が増えてきたからこそ、仕組みで守れるようにしたい」という説明の仕方をすると、古参社員の抵抗感を減らしやすくなります。SSO導入は否定ではなく、先代の時代の運用を次の規模に合わせて引き継ぐ作業だ、という位置づけで伝えるのが現実的です。

古参社員との関係で気をつけたいこと

長年総務や庶務を担ってきた古参社員は、多くの場合「会社のアカウント事情を誰よりも知っている生きた台帳」です。SSO導入にあたっては、この古参社員の協力なしには正確な棚卸しができないケースがほとんどです。一方で、彼らにとってはこれまで自分が担ってきた仕事の一部が「仕組み」に置き換わることへの不安もあるでしょう。

現場感覚として大切なのは、SSO導入の目的を「あなたの仕事を減らすためではなく、あなたが休んでも会社が困らないようにするため」と伝えることです。古参社員が突然入院したり、長期休暇を取ったりしたときに、パスワードが分かる人が一人もいなくなる、という事態は実際に起こり得ます。仕組み化はその古参社員自身を守ることでもある、という視点を共有できれば、協力を得やすくなります。

名義問題とSSOの関係

承継の場面では、クラウドサービスの契約者名義が先代個人になっているケースが少なくありません。法人契約のつもりで使っていたサービスが、実際には先代個人のメールアドレスで契約されていた、というのは非常によくある話です。これはSSOそのものの話ではありませんが、SSO導入の準備として全サービスの契約状況を洗い出す過程で、必ず発覚する問題です。

名義が先代個人になっている場合、先代が完全にリタイアした後に契約更新や重要な通知が先代個人にしか届かなくなり、会社側で気づけないまま契約が失効する、というリスクがあります。SSO導入の棚卸し作業は、こうした名義問題を早期に発見し、法人名義への切り替えを進める絶好の機会にもなります。

名義問題は、承継後しばらく経ってから発覚すると対応が難しくなる傾向があります。先代が完全に会社を離れてしまってから「このサービスの契約者は先代個人名義だったので、名義変更にはご本人の同意と手続きが必要です」とベンダー側から言われるケースもあり、先代がまだ会社に関わっている間、あるいは連絡が取りやすいうちに整理しておくことが望ましいのです。承継直後というタイミングは、この点でも名義問題を洗い出す最後のチャンスだといえます。パスワードやアカウント情報をいつ先代から預かるべきかについては、パスワードやアカウント情報は今預かるか、承継の瞬間まで待つかも参考になる。

中小企業がSSOを導入する際の一般的な費用感

SSO・IDaaSサービスの費用は提供事業者やプランによって幅がありますが、1ユーザーあたり月額数百円程度からのプランが中心とされています。社員数が10名から100名規模の会社であれば、月額のランニングコストは会社全体で数千円から数万円程度に収まることが多いという見方が一般的です。ただし、この金額感はサービスごとの機能差や、既存契約への追加機能として使えるかどうかで大きく変わるため、まずは自社が既に契約しているMicrosoft 365やGoogle Workspaceなどのプランに、SSOの基盤となる機能が含まれていないかを確認するのが先決です。

業種によってSSO導入の効果は変わるのか

「うちは製造業だから」「うちは飲食業だから」といった業種の違いによって、SSO導入の効果に大きな差が出るのではないかと考える経営者もいるかもしれません。実際には、業種そのものよりも「クラウドサービスをいくつ使っているか」「入れ替わりの多いパートタイム・アルバイト社員がいるか」という要素の方が、SSO導入の効果を左右します。

例えば飲食業や小売業のようにパートタイム社員の入退社が頻繁に発生する業種では、退職者アカウントの発生頻度自体が高く、SSOによる一括無効化の効果が特に大きく出やすい傾向があります。一方、製造業のように現場の作業員がクラウドサービスをほとんど使わず、事務所の数名だけがパソコンで各種システムを操作している会社では、対象となるアカウント数自体が少なく、導入の優先度はやや下がるかもしれません。自社の実情に合わせて、どの業種の一般論よりも「実際に何人が何個のサービスを使っているか」を基準に判断することが大切です。

SSOと多要素認証はセットで考える

SSOを導入する際には、多要素認証（多要素認証（MFA））とセットで検討することが強く推奨されます。SSOは一つの認証情報で複数サービスにアクセスできる仕組みであるため、裏を返せばその一つの認証情報が突破されてしまうと、被害範囲がすべてのサービスに一気に広がるリスクもあります。パスワードだけでなく、スマートフォンへの通知確認などを組み合わせる多要素認証を併用することで、この「一点突破のリスク」を大きく減らすことができます。SSOだけを導入して安心してしまうのではなく、認証の入り口そのものを強化する発想を持つことが重要です。

多要素認証と聞くと「複雑な設定が必要そう」と身構えてしまう経営者もいますが、実際にはスマートフォンに専用アプリを入れて、ログイン時に表示される通知を確認するだけという手軽な運用が主流になっています。社員側の操作としては、パスワード入力後にスマートフォンで「はい」をタップするだけ、という程度の手間で済むケースが多く、導入のハードルは想像するよりも低いはずです。むしろSSOによってログインする回数自体が減るため、多要素認証を追加しても、社員が感じる手間の総量は以前より減ることも少なくありません。

誰の許可を得てSSOを導入すればいいのか

社員数が数十名規模の会社であっても、SSOのようにシステム全体に関わる変更は、経営者一人の判断だけで進めるべきではない場合があります。特に古参の役員や、先代が退任後も相談役として残っているような会社では、大きな方向転換に見える取り組みについて、事前に一声かけておくことが後々の関係をスムーズに保つコツです。

社内で新しい取り組みを進める際の意思決定の仕組みを、稟議のような形で明文化している会社もありますが、そこまで厳格な制度がなくても構いません。要は、「なぜ導入するのか」「何が変わるのか」「誰にどんな影響があるのか」を簡単な資料や口頭説明でまとめ、関係者に共有するプロセスを踏むことが大切です。この説明の手間を惜しまないことが、結果的に社内の抵抗を減らし、導入後の定着をスムーズにします。

導入のステップを段階的に考える

いきなり全社の全サービスをSSOに統合するのは、承継直後で他にもやることが多い経営者にとって現実的ではありません。段階的に進める発想が現実的です。

1. まず利用中のクラウドサービスを一覧化する
2. 退職者・異動者のアカウントが残っていないか、現状の棚卸しを行う
3. 利用者数の多い基幹サービス（メール、勤怠、会計など）からSSO対応を検討する
4. 対応可能なサービスを絞り込み、無料または低コストのプランで試験導入する
5. 運用が安定したら、多要素認証を追加して認証全体を強化する
6. 対応範囲を広げながら、退職・異動発生時のアカウント無効化を標準の手続きとして定着させる

この順番で進めることで、一度に大きな投資や混乱を招くことなく、着実に管理体制を引き継ぎ直すことができます。

SSO導入後も残る「運用ルール」の重要性

SSOを導入したからといって、それだけで退職者アカウントの放置問題が自動的に解決するわけではありません。あくまでSSOは「一括で止める操作を可能にする仕組み」であり、「いつ・誰が・どのタイミングで止めるか」という運用ルールが別に必要です。退職が決まった時点で、誰がアカウント無効化の指示を出すのか、実際に無効化する担当者は誰なのか、この二点を明文化しておかなければ、SSOを導入しても「止め忘れ」は依然として起こり得ます。

退職手続きのチェックリストの中に「SSOアカウントの無効化」を必須項目として組み込み、退職日当日、あるいは退職が確定した時点で必ず実施する、というルールを社内規定として定めておくことが、仕組みを本当に機能させるための最後の一手です。

クラウドサービス移行時に起こりやすい混乱への備え

SSOを導入する過程では、これまで個別ログインだったサービスの認証方式が変わることになります。社員によっては「急にログインできなくなった」と混乱する場面も出てくるでしょう。特にITに慣れていないパートタイム社員や、長年同じ操作に慣れてきたベテラン社員ほど、変化への抵抗感が大きくなりがちです。

導入時には、一時的に旧来のログイン方法と並行運用する期間を設けたり、簡単な操作マニュアルを紙で配布したりするなど、現場の負担を減らす工夫が有効です。承継後の会社では、システムの変更そのものよりも、変更に伴う社内コミュニケーションの丁寧さが、導入の成否を左右することが多いという実感を持つ経営者も少なくありません。

導入を先延ばしにするとどうなるか

「今は他にやることが多いから、SSOの導入は落ち着いてから」と考える経営者は多いはずです。しかし、退職者や異動者は承継後の混乱期にこそ発生しやすいという現実があります。先代からの引き継ぎに伴う組織変更や、承継を機にした人員整理が行われる会社も少なくなく、まさにアカウント管理の重要性が高まるタイミングで、管理体制が最も脆弱なままになってしまうという矛盾が起きやすいのです。

先延ばしにした結果、退職者アカウントが数年単位で放置され、ある日突然の不正アクセスやデータ持ち出しの疑いが発覚してから慌てて対応する、というのが最も避けたいシナリオです。仕組みを整えるタイミングは、落ち着いてからではなく、むしろ承継直後の「棚卸しがしやすいうち」であることを強調しておきたいと思います。

承継直後だからこそ棚卸しがしやすい理由

一見矛盾するようですが、承継直後は実はアカウントの棚卸しをするのに向いているタイミングでもあります。新しい経営者として社内を見渡す立場になったばかりだからこそ、「これは何のためのサービスですか」「このアカウントは誰が使っていますか」と、率直に質問しやすい空気があります。数年経営者を続けていると、既存の仕組みに慣れてしまい、疑問を持たなくなってしまうものです。承継直後の「素人目線」を、むしろ強みとして活用する発想を持つとよいでしょう。

相談先が見つからないときの考え方

株式や登記の手続きには司法書士、税務には税理士、労務には社労士という明確な相談先が存在します。しかしシステムやアカウント管理については、多くの経営者が「誰に相談すればいいのか分からない」という状態に置かれています。これは決して経営者自身の勉強不足のせいではなく、そもそも中小企業のIT運用を専門的に相談できる窓口が、他の士業と比べて整備されていないという構造的な問題です。

まずは既に契約しているクラウドサービスのベンダーに、SSO対応の可否や導入サポートの有無を問い合わせるところから始めるのが現実的です。多くのIDaaSベンダーは導入支援のプランを用意しており、専門知識がなくても相談しながら進められる体制を整えています。一人で悩み続けるよりも、まずは問い合わせてみることが、孤独感を解消する最初の一歩になります。

まとめではなく、次にやるべき一つのこと

ここまで、SSOが承継後の会社にとってどのような意味を持つのかを見てきました。最後に伝えたいのは、今日すぐにSSOを導入する必要はないということです。まず今週やるべきことは、社内で契約しているクラウドサービスを一つずつ書き出してみることです。それだけで、これまで見えていなかった会社の輪郭が、少しずつはっきりと見えてくるはずです。先代から引き継いだ会社を、次の世代にも安心して引き継げる形に整えていく作業は、地味に見えて、確実に会社を強くしていく一歩になります。

よくある質問

Q1. SSOを導入すると、先代が個人的に使っていたアカウントも整理されますか。

SSOの導入作業そのものは、先代が使っていた個人アカウントを自動的に整理してくれるわけではありません。ただし、導入前に必ず行う「利用中サービスの棚卸し」の過程で、契約名義が先代個人になっているアカウントが発覚することは非常に多くあります。棚卸しの段階で見つかった名義問題は、SSO導入と並行して、法人名義への切り替えや退任に合わせた権限の見直しを進めるとよいでしょう。焦って先代のアカウントをすぐに削除するのではなく、まずは何が先代名義になっているかを一覧化することを優先してください。

Q2. 古参の総務担当者がパスワード管理を一人で担っていて、その人がいなくなったら困りそうです。SSO導入で解決しますか。

これはSSO導入によって大きく改善できる典型的な課題です。SSOでは認証情報を一元管理する基盤に情報が集約されるため、担当者一人の頭の中や個人のメモに依存する状態から脱却できます。ただし、導入直後は移行期間として、古参社員に協力してもらいながら既存のアカウント情報を正確に洗い出す必要があります。この協力を得るためには、「あなたの仕事を奪う仕組みではなく、あなたが安心して休めるようにする仕組みだ」という説明を丁寧に行うことが効果的です。

Q3. 退職者のアカウントが残っていることに、承継後に気づきました。今すぐ何をすればいいですか。

まず優先すべきは、現在残っている退職者アカウントを速やかに無効化することです。SSOの導入を待つ必要はなく、各サービスに個別にログインして退職者のアカウントを停止・削除する作業を今すぐ進めてください。その上で、同じことが繰り返されないように、退職手続きのチェックリストに「アカウント無効化」を必須項目として加え、SSOの導入によって将来的にこの作業を一括化できるように検討を進める、という順序が現実的です。緊急対応と仕組み化は並行して進めるべき別の課題だと考えてください。

Q4. 社員数が20名程度の小さな会社でも、SSOは本当に必要ですか。

社員数の少なさは、SSO導入の必要性を下げる理由にはなりません。むしろ社員数が少ない会社ほど、一人ひとりのアカウントに広い権限が与えられている傾向があり、退職者アカウントが放置された場合の被害範囲は相対的に大きくなりやすいという指摘があります。また、専門の情シス担当者がいない会社ほど、属人的な管理から仕組みによる管理への切り替えの効果が大きく出ます。まずは既に契約しているオフィスソフトのプランにSSOの基盤機能が含まれていないかを確認し、追加コストを抑えた形での導入を検討するのがよいでしょう。