社長しか知らないパスワードとアカウント、10人になる前に洗い出す方法

創業して2年、社員はまだ5人。ドメインの管理画面、会計ソフトの管理者アカウント、SaaSの請求担当ログイン、Wi-Fiルーターの設定画面。これらのパスワードを全部言える人は、社長であるあなた一人ではないでしょうか。あるいは、最初にITまわりを整えてくれた創業メンバーの1人だけが知っている、という会社も少なくありません。

これは決して珍しい状態ではなく、創業期の会社ではむしろ標準的な姿です。人数が少ないうちは「聞けばすぐ分かる」ので、誰も困りません。困らないからこそ、誰も手を付けないまま時間だけが過ぎていきます。しかし、この状態を放置したまま10人、20人と組織が育っていくと、ある日突然「パスワードが誰にも分からない」という事態に直面します。本人が体調を崩して数週間出社できなくなった、家庭の事情で急に退職することになった、あるいは単に忙しくて連絡が取れない――理由は何であれ、結果は同じです。ドメインの更新ができない、会計ソフトにログインできない、顧客管理システムの設定が変更できない、という形で業務が止まります。

このガイドでは、そうなる前に、社長やメンバー個人の頭の中にあるパスワードとアカウント情報を、会社の共有資産として台帳に落とし込む手順を説明します。10人を超えてから慌てて着手する会社が大半ですが、実際には5人、3人の段階から始めるほうがずっと簡単です。理由は単純で、洗い出すべきアカウントの絶対数が少ないからです。逆に言えば、今この文章を読んでいる時点が、これまでの人生で最も「棚卸しが楽なタイミング」だとも言えます。

なぜ「10人になる前」が分岐点なのか

会社の規模が小さいうちは、契約しているSaaSやドメイン、サーバーの数もまだ限られています。創業から1〜2年であれば、業務で使っているアカウントはおそらく10〜20個程度に収まっているはずです。これが10人を超えて部署が分かれ始めると、営業チームが独自に契約したツール、経理が使い始めたクラウド会計、現場が導入した勤怠管理アプリと、アカウントの数は加速度的に増えていきます。棚卸しの作業量は、放置した期間と組織の複雑さに比例して膨らむため、着手のタイミングが遅れるほど負担は重くなります。

さらに厄介なのは、創業期特有の事情として「誰が何の担当か」が明確に分かれていないことです。総務、経理、ITを1人が兼任している、あるいは社長自身がすべてを見ている状態では、業務の役割分担図を作っても「担当者=社長」としか書けません。この属人化の芽は、属人化という言葉で呼ばれる状態そのものであり、対処が遅れるほど本人以外に手を出しにくい聖域になっていきます。10人未満という段階は、まだ聖域化する前に「これは会社の資産であって、個人の記憶ではない」という認識を組織に根付かせる最後のチャンスと言えます。

もう一つ見落とされがちな理由があります。それは、創業期の会社ほど資金繰りが厳しく、専門の情シス担当を雇う余裕がないという事実です。人を雇えないなら、せめて仕組みで属人化を防ぐしかありません。10人を超えて売上が安定してから初めて情シス担当を採用する、あるいは兼任者を任命するという会社が大半ですが、その担当者が最初に直面するのが「前任者（多くの場合は社長自身）しか知らないパスワードの山」です。あらかじめ台帳化されていれば、その担当者は初日から本来の仕事に集中できます。逆に台帳が無ければ、最初の数週間はパスワードの謎解きに費やされることになります。

洗い出しの前に決めておくこと: 誰が管理者になるか

パスワードの棚卸しを始める前に、まず決めておくべきことがあります。それは「この台帳を誰が管理するか」という点です。創業期の会社では、この問いに対して「社長が全部見る」という答えを出しがちですが、これはあまりお勧めできません。社長自身が最大のボトルネックになってしまうと、本末転倒だからです。社長が出張中、あるいは体調を崩したときに限ってドメインの更新期限が来る、といった巡り合わせは決して珍しくありません。

現実的な選択肢は次の3つです。

• 社長以外の特定の1人に管理者を任せる: 経理担当や総務担当など、比較的長く在籍する見込みのあるメンバーに任せる方法。ただし、その人自身が退職するリスクは残るため、次で述べる複数人アクセスの仕組みとセットにする必要があります
• 社長と管理者候補の2人体制にする: 台帳へのアクセス権を2人が持ち、どちらか一方が不在でも参照できるようにする方法。小規模な会社ではこれが最もバランスが良い選択です
• 外部の専門家（税理士・社労士・顧問のITパートナー）に一部を預ける: ドメインやサーバーなど専門性の高い契約情報は、日頃から付き合いのある外部専門家に一部管理してもらう方法。ただし丸投げにはせず、社内にも必ずコピーを残します

どの体制を選ぶ場合でも、「1人しかアクセスできない」状態を作らないことが最優先です。これは後述する台帳の保管場所の設計にも直結する考え方です。人数が少ない会社ほど「信頼できる人にだけ任せておけば安心」という発想に流れがちですが、その「信頼できる1人」が不在になった瞬間に会社が止まるのであれば、それは信頼の問題ではなく設計の問題です。

管理者を決める際のもう一つの視点として、「誰が最も長く在籍しそうか」だけでなく「誰が最もITリテラシーに抵抗がないか」も考慮に入れてください。パスワード管理ツールの操作や台帳の更新は、多少なりともデジタルツールへの慣れが必要な作業です。抵抗感の強いメンバーに無理に任せると、台帳自体が更新されずに形骸化するリスクが高まります。

ステップ1: 洗い出しの対象を4つのカテゴリで棚卸しする

パスワードの棚卸しは、思いつくままに書き出すと必ず漏れが出ます。次の4つのカテゴリに分けて、順番に埋めていくことをお勧めします。

洗い出す際は、「サービス名」「ログインURL」「管理者アカウントのメールアドレス」「パスワードの保管場所」「契約更新日」「支払い方法（誰のクレジットカードか）」の6項目を最低限セットで記録してください。特に「支払い方法」は見落とされがちですが、代表個人のクレジットカードで決済されているSaaSが後から法人カードに切り替えられずトラブルになるケースが多く、次の記事創業期の契約書・ドメイン・SaaSアカウント、代表個人名義になっていませんかで詳しく扱います。

4つのカテゴリの中でも、最も優先度が高いのはインフラ・契約基盤です。理由は単純で、これが止まると会社のウェブサイト自体が表示されなくなったり、メールが送受信できなくなったりと、影響範囲が全社に及ぶためです。業務SaaSは部署単位の影響に留まることが多い一方、ドメインとサーバーは会社の対外的な窓口そのものなので、最優先で洗い出しに着手してください。

物理的な鍵・端末のカテゴリは、デジタルなパスワード管理の話とは毛色が違うため見落とされがちですが、創業期の小さなオフィスでは「事務所の鍵を持っているのが社長だけ」「金庫の暗証番号を知っているのが経理担当1人だけ」といった状況が頻繁に起こります。デジタルとアナログを分けて考えず、「業務を止めうる情報」という同じ土俵で棚卸しの対象に含めることが重要です。

ステップ2: パスワードそのものを台帳に書かない

ここで重要な注意点があります。それは、パスワードの文字列そのものを平文で台帳（Excelファイルやスプレッドシート）に書き込むべきではない、という点です。台帳が漏えいした場合に、そのまますべてのアカウントへの侵入経路になってしまうためです。特に共有スプレッドシートは、リンクを知っている人なら誰でも閲覧できる設定になりがちで、退職者のアクセス権限を止め忘れるといった管理ミスも起きやすい形式です。

推奨される方法は、パスワード管理ツール（1Password、Bitwardenなど）を導入し、「どのサービスのパスワードがそのツールに登録されているか」という所在情報だけを台帳に記録することです。パスワード管理ツールには「共有ボールト（保管庫）」の機能があり、特定のメンバーだけがアクセスできる共有フォルダを作れます。これにより、台帳自体は「地図」の役割に徹し、実際の「鍵」であるパスワードは別の安全な場所に保管するという二層構造ができあがります。

パスワード管理ツールの月額費用は、小規模チーム向けプランであれば1人あたり数百円程度から利用できることが多く、創業期の会社にとっても導入のハードルは高くありません。むしろ、パスワードが分からなくなって業務が止まった際の損失（対応にかかる時間、機会損失、最悪の場合は事業継続そのものへの影響）と比較すれば、費用対効果は明らかにツール導入側に傾きます。

創業期でツール導入のコストをかけられない場合の次善策としては、パスワードを記載したファイルをパスワード付きZIPで暗号化し、そのZIPの開錠パスワードだけを口頭または別経路（社長と管理者2人だけが知る合言葉など）で共有する方法もあります。ただし、これはあくまで暫定措置と捉え、余裕ができ次第、専用ツールへの移行を検討してください。暫定措置を「とりあえず動いているから」という理由でそのまま何年も使い続けてしまうケースは非常に多く、これもまた一種の属人化・仕組みの老朽化と言えます。

ステップ3: 「知っているだけの人」を減らし、正式なアカウントに変える

洗い出しと並行して着手すべきなのが、個人アカウントで業務利用しているサービスを、法人としての正式なアカウントに切り替える作業です。創業期にありがちなのが、社長個人のGoogleアカウントでGoogle Workspaceを契約している、代表メンバーの個人アカウントでSaaSにサインアップしている、といった状態です。

この状態のまま人数が増えると、その個人が退職・独立した場合に、会社の重要なデータやアカウントごと持ち出されるリスクが生じます。契約自体を会社名義に変更できるサービスであれば、早い段階で名義変更の手続きを行ってください。名義変更ができないサービス（個人プランしか用意していない等)の場合は、法人向けプランへの移行を検討する契機と捉えましょう。

個人アカウントから法人アカウントへの移行は、単なる名義の書き換えでは済まないケースもあります。例えばクラウドストレージサービスでは、個人アカウントに保存されたファイルを法人アカウントへ一括で引き継ぐ機能が用意されていない場合があり、手作業でのファイル移行が必要になることもあります。移行作業自体に一定の工数がかかることを見越して、後回しにせず早めに着手することをお勧めします。

ステップ4: 台帳のフォーマットを固定する

洗い出した情報は、次のような列構成の表にまとめると管理しやすくなります。実際に使う際は、スプレッドシートの1行に1アカウントを記録してください。

1. サービス名・システム名
2. カテゴリ（インフラ／業務SaaS／コミュニケーション／物理）
3. ログインURL・アクセス方法
4. 管理者アカウント（メールアドレス）
5. パスワードの保管場所（パスワード管理ツールのフォルダ名等）
6. 支払い方法・契約者名義
7. 契約更新日・解約条件
8. 緊急連絡先（サービス提供元のサポート窓口）
9. 最終確認日

この9項目をすべて一度に埋めようとすると心が折れるので、まずは1〜4列だけでも埋めることを目標にしてください。台帳は完璧を目指すより、まず存在することの方が重要です。より簡易な1枚もののフォーマットで始めたい場合は、社員10人未満で今すぐ作るべき「IT台帳」はA4一枚でいいで紹介する最小構成から着手する方法もあります。

台帳のフォーマットを決める際は、将来的に列を追加しやすい構造にしておくことも意識してください。会社の成長に伴って、例えば「担当部署」や「利用者数」といった列が必要になる場面が出てきます。最初から完璧な設計を目指すのではなく、後から拡張できる余白を残しておくことが、長く使われる台帳の条件です。

洗い出しでよくあるつまずきと対処法

洗い出しを実際に進めると、いくつかの典型的なつまずきに直面します。

「そもそも何のサービスに登録しているか、社長本人も正確に覚えていない」

これはクレジットカードの明細を確認することで多くが解決します。法人カードや、業務用に使っている個人カードの過去半年〜1年分の明細を見返し、「サブスクリプション」らしき定期的な引き落としを洗い出してください。心当たりのない引き落としがあれば、それこそが忘れられていたSaaS契約である可能性が高いです。

「ドメインの登録者情報を確認しようとしたら、誰が契約したドメイン管理サービスか分からない」

ドメインの所有者情報は、WHOIS情報の検索サービスで公開範囲内のものは確認できます（代行公開サービスを使っている場合は登録者名は分かりません）。それでも判明しない場合は、過去のメール履歴を「ドメイン」「更新」「請求」といったキーワードで検索し、契約時のメールを探すのが確実です。

「元メンバーが個人アカウントで契約していたことが後から分かった」

すでに退職済みのメンバーが個人名義で契約していたことが判明した場合は、退職者名義のドメイン・サーバー契約を取り戻す手順で紹介されている名義変更の手続きに沿って対応してください。このガイドはあくまで「まだ在籍しているうちに」台帳化することに主眼を置いていますが、すでに退職者名義になってしまっている場合の復旧手順は上記のコラムで扱っています。

「棚卸しを始めたら、想像以上にアカウント数が多くて心が折れそうになった」

これは非常によくある反応です。10人未満の会社でも、実際に洗い出してみると30〜50個近いアカウントが見つかることも珍しくありません。無料トライアルのまま放置されたサービス、1回だけ使って以降誰も触っていないツールなど、「本当は使っていない」アカウントも多く含まれています。すべてを丁寧に管理する必要はなく、まずは現在も業務で使っているものに絞り込み、使っていないものは思い切って解約・削除してしまうという判断も有効です。棚卸しは「増やす」作業であると同時に「減らす」作業でもあります。

パスワード自体の質を見直す機会にもする

台帳化の作業は、同時にパスワードの質そのものを見直す良い機会でもあります。創業期の会社では、複数のサービスで同じパスワードを使い回している、あるいは会社名や電話番号から推測しやすいパスワードを設定している、といったケースが少なくありません。洗い出しの過程で、脆弱なパスワードや使い回しが見つかった場合は、この機会にパスワードそのものも更新することをお勧めします。

あわせて検討したいのが、多要素認証（MFA）の導入です。パスワードだけに頼る認証は、パスワードが漏えいした瞬間に突破されてしまいますが、多要素認証を設定しておけば、パスワードが漏れても不正ログインのリスクを大幅に下げられます。特にドメイン管理画面やクラウドサービスの管理者アカウントなど、影響範囲の大きいアカウントから優先して設定することをお勧めします。

台帳を作って終わらせないための運用ルール

台帳は作った瞬間がピークで、その後は更新されずに古いままになる、というのが最もよくある失敗パターンです。これを防ぐために、次の3つの運用ルールを最初から決めておくことをお勧めします。

• 新しいSaaSを契約したら、契約と同時に台帳に追記する: 「後でまとめて登録しよう」は実現しません。契約した本人が、契約完了のタイミングでその場で1行追加するというルールを、社内の共通認識にしてください
• 半年に1回、棚卸しの見直し日を決める: カレンダーに定期的なリマインダーを設定し、契約更新日や利用実態が変わっていないかを確認します。特に無料トライアルから有料化したサービスや、逆に使われなくなった解約すべきサービスの洗い出しに有効です
• 人数が増えて役割分担が生まれたら、担当を分散する: 10人を超えて部署が分かれてきたら、台帳全体を1人で抱えるのではなく、カテゴリごとに担当者を分ける体制に移行してください

運用ルールを決める際は、「誰が守らなかったときに誰が困るか」を明確にしておくことも大切です。新しいSaaSを契約したメンバーが台帳への追記をサボっても、その場では誰も困りません。しかし半年後、そのサービスの契約更新日が来たときに困るのは別の誰かです。この時間差があるからこそ、ルールとして明文化し、繰り返し周知する必要があります。

台帳の運用が軌道に乗ってきたら、次はパスワード管理そのものだけでなく、業務のやり方や判断基準が特定の人にしか分からない「なんとなく詳しい人」への依存状態からの脱却にも取り組む段階です。「なんとなく詳しい人」に依存した社内IT、辞めたら詰む前にやることもあわせて参照してください。

台帳化がもたらすもう一つの効果: 資金繰りの見える化

パスワードとアカウントの棚卸しを進めると、副次的な効果として「会社が今、月にいくらSaaSに支払っているか」が可視化されるという利点があります。創業期の会社では、複数の担当者がそれぞれ別のクレジットカードでSaaSを契約していることが多く、経理担当が全体の支出を正確に把握できていないケースが少なくありません。台帳に「支払い方法」と「月額・年額費用」の列を加えておくと、棚卸しがそのまま固定費の見直しにもつながります。

実際に棚卸しを行った会社の中には、使われていないSaaSの解約だけで月数万円のコスト削減につながった例もあります。パスワード管理という一見地味な作業が、経営面でも意味のある投資になり得るという点は、社内で台帳化の必要性を説明する際の説得材料としても使えるでしょう。

創業期ならではの落とし穴: 共同創業者間の認識のズレ

複数人で創業した会社の場合、もう一つ特有の落とし穴があります。それは、共同創業者の間で「誰がどのアカウントを管理しているか」の認識がずれているケースです。例えば、代表者は「ドメインの管理は共同創業者のBさんに任せてある」と思っている一方、Bさん自身は「代表者が管理しているはず」と思い込んでいる、というすれ違いです。

このようなすれ違いは、実際に契約更新のトラブルが起きるまで表面化しないことがほとんどです。創業期は関係者全員が忙しく、「言わなくても分かっているだろう」という暗黙の了解に頼りがちですが、パスワードとアカウントの管理においてはこの暗黙の了解が最も危険です。台帳化の作業は、単に情報を書き出すだけでなく、共同創業者間で「誰が何を管理しているか」を明文化し、認識を揃える機会としても機能します。

台帳を作る過程で、「これは誰が管理しているんだっけ」という会話が自然と発生するはずです。この会話こそが、暗黙の了解を明文化されたルールに変える瞬間であり、台帳という成果物そのものよりも価値があるとも言えます。

退職・離脱時の引き継ぎフローとセットで考える

パスワード台帳は、作って終わりではなく、メンバーの退職・離脱が発生した際にどう機能するかとセットで設計する必要があります。創業期の会社では、メンバーの入れ替わりが比較的頻繁に起こることも珍しくありません。台帳が整備されていれば、退職者が管理していたアカウントの一覧をすぐに洗い出せ、退職日までにパスワードの再設定や管理者権限の移譲を計画的に進められます。

逆に台帳が無ければ、退職者が最後の出社日になって初めて「あのアカウントのパスワードを聞いておかなければ」と慌てることになります。退職を伝えられてから最終出社日までの期間は、感情的にもデリケートな時期であり、この時期に「パスワードを教えてください」と詰め寄るようなコミュニケーションは、双方にとって望ましいものではありません。台帳が事前に整備されていれば、退職の申し出があった時点で「担当していたアカウント一覧」がすぐに分かり、落ち着いて引き継ぎ作業を進められます。

退職時のアカウント整理については、パスワードの引き継ぎだけでなく、そのメンバーがアクセスできていたすべてのシステムからのアクセス権限の削除も同時に必要になります。この削除作業も、日頃から台帳が整備されていて初めてスムーズに行えるものです。台帳の「管理者アカウント」列を常に最新に保っておくことが、退職時の速やかな対応の土台になります。

経営者自身がボトルネックにならないための心構え

最後に、経営者自身の心構えについても触れておきます。創業期の社長は、良くも悪くも「自分が一番よく分かっている」という自負を持ちやすい立場です。パスワードやアカウント情報も、自分が把握していれば安心だと考えがちですが、この考え方こそが会社を脆弱にする最大の要因になり得ます。

経営者が体調を崩したり、事故に遭ったり、あるいは単純に忙しくて連絡が取れない状況は、いつ訪れてもおかしくありません。会社を守るということは、経営者自身がいなくても最低限の業務が回る仕組みを作ることでもあります。パスワードの台帳化は、その最も基本的な第一歩です。「自分が把握していれば大丈夫」という感覚を手放し、「自分がいなくても大丈夫」な状態を意図的に設計する。この発想の転換こそが、10人未満というこのタイミングで最も必要とされているものです。

まとめ: 完璧な台帳より、今日書き出せる分だけの台帳を

パスワードとアカウントの棚卸しは、100点を目指すと着手すら難しくなる作業です。まずは今、思いつく限りのサービス名を書き出すことから始めてください。「支払い方法」や「更新日」といった項目は後から埋めても構いません。重要なのは、社長やメンバー個人の記憶だけに頼っている状態から、会社としての記録に変えていく一歩を、10人になる前の今、踏み出すことです。

会社の規模がまだ小さいうちは、この作業にかかる時間は数時間から長くても1〜2日で済みます。この小さな投資が、将来「パスワードが誰にも分からず業務が止まる」という重大なリスクを未然に防ぎます。まずは自社の危険度を客観的に知りたい場合はひとり情シス危険度診断を、チェック形式で進めたい場合はチェックリスト集もあわせてご活用ください。