脱ロックインの第一歩: 自社で管理すべきアカウント一覧

「脱ロックインについて、いろいろ調べてきた。契約書の確認ポイントも分かった、データのエクスポート方法も分かった、保守費の相場感もつかめた。……で、結局今日、何から手をつければいいんだっけ」——このカテゴリの記事を何本か読み終えた方の多くが、最後にたどり着くのはこの疑問ではないでしょうか。

知識は増えたはずなのに、机の上には何も変わっていない。契約書は今日も同じ場所にしまわれたままで、乗り換えの検討は「そのうちやらなければ」というToDoリストの1行にとどまっている。これは決して珍しい状態ではありません。脱ベンダーロックインという課題は範囲が広く、契約・データ・保守費・組織体制など複数のテーマにまたがっているため、「全体像は分かったが、着手する順番が分からない」という段階で足が止まりやすいのです。

結論から言います。脱ロックインの第一歩として最も着手しやすく、かつ効果が大きいのは「自社が管理すべきアカウント一覧を整備すること」です。契約書の見直しや開発会社との交渉は、相手のあるやり取りで時間がかかりますが、アカウント一覧の整備は自社の中だけで完結し、今日から始められます。しかも、この一覧が整うと、これまで読んできた契約・データ・保守費というテーマすべてを実務的に下支えする土台になります。

この記事はこのカテゴリの19本目までを一通り読んだ方に向けた、20本目・締めくくりの記事です。個別の論点（契約書の条項、データのエクスポート手順、保守費の相場）はすでに他の記事で解説済みなので、ここでは繰り返しません。代わりに、それらの知識を「今日、具体的に何をするか」という1つの作業に落とし込むことに絞って解説します。

この記事で分かること

自社が管理すべきアカウントとは何を指すのか、なぜアカウント一覧の整備が脱ロックインの起点になるのか、そして実際に一覧を作る手順を、今日から着手できるレベルまで具体的に解説します。読み終える頃には、明日の朝、何を開いて何を確認すればよいかが分かる状態を目指します。

このカテゴリのほかの記事を読んでいない方でも、この記事単体で「アカウント一覧の作り方」は理解できます。ただし、一覧を作ったあとに直面する個別の論点（契約書の著作権条項、データのエクスポート手順など）については、記事末尾の関連記事に譲ります。

なぜ「アカウント一覧」が脱ロックインの第一歩なのか

ロックインの本質は「自社がアクセス権を持っていない」状態

このカテゴリのほかの記事で繰り返し出てきたベンダーロックインという言葉を、ここで改めて定義し直します。ベンダーロックインの本質を一言で言えば、「自社の業務に不可欠なシステム・データ・設定に、自社の人間が自分の意思でアクセスできない状態」です。

契約書に著作権譲渡の条項がない、データのエクスポート機能がない、保守費が不透明——これらはすべて重要な論点ですが、日々の実務でまず突き当たるのは、もっと手前にある問題です。それは「そもそも、そのシステムの管理画面に、自社の誰がどんなIDでログインできるのか、社内の誰も正確に把握していない」という状態です。

管理者アカウントのIDとパスワードが、退職した前任者のプライベートなメールアドレスに紐づいたままになっている。契約更新やプラン変更の通知が、辞めた担当者のメールボックスに届き続けている。こうした状態では、契約書の内容がどれだけ自社に有利でも、実際にその権利を行使する入口を自社が持っていないことになります。

「知っている」と「アクセスできる」は別の問題

ここで区別しておきたいのは、「このシステムを開発会社Aに発注した」という事実を知っていることと、「そのシステムの管理者アカウントに自分がログインできる」というアクセス権を持っていることは、まったく別の問題だという点です。

前者は台帳や記憶があれば足りますが、後者は実際のIDとパスワード（あるいは代替の認証手段）が手元になければ意味がありません。多くの中小企業では、システムを発注した当時の担当者が管理者アカウントを個人のメールアドレスで作成し、退職時にその引き継ぎが行われないまま数年が経過しているケースが見られます。

アカウント一覧の整備とは、「知っている」を「アクセスできる」に変換する作業だと言い換えることができます。

契約書・データ・保守費の話が「絵に描いた餅」にならないために

このカテゴリの他の記事で解説してきた内容——『ソースコードの著作権は誰のもの？契約書の確認ポイント』や『自社システムのデータを吸い出せるか確認する方法』——は、いずれも「契約書を確認する」「管理画面からデータをエクスポートする」という行動を前提にしています。

しかし、その管理画面にログインするアカウントを自社が把握していなければ、これらの行動はそもそも実行できません。アカウント一覧の整備は、他の記事で得た知識を実行に移すための、最も基礎的な土台なのです。

「自社が管理すべきアカウント」とは何を指すか

4つのカテゴリに分けて考える

「アカウント」と一口に言っても、その性質はさまざまです。整理の見通しをよくするため、まず4つのカテゴリに分けて考えることをおすすめします。

この4分類はあくまで整理の一例で、自社の業態によって重要度は変わります。重要なのは、「システム開発」に関わるアカウントだけでなく、ドメインやSNSアカウントのような、一見システムと関係が薄そうなものまで視野に入れることです。ドメインの更新が滞って会社のWebサイトやメールが突然使えなくなる、という事故は、システムそのものの契約書の不備よりもむしろ起きやすいトラブルです。

「誰が管理者か」より「管理者権限のIDに誰がログインできるか」

もう一つ強調しておきたいのは、確認すべきは「担当者が誰か」ではなく「管理者権限を持つIDに、今この瞬間、誰がログインできるか」だという点です。

• 「システムの担当は経理の田中さんです」という情報だけでは不十分
• 田中さんが実際に管理者アカウントのパスワードを知っているか、多要素認証の復旧手段を持っているかまで確認して、初めて「アクセスできる」と言えます

この違いは些細に見えて、実務上は大きな差を生みます。担当者が変わるたびにパスワードは引き継がれても、多要素認証の復旧用電話番号だけが前任者の個人スマートフォンのままになっている、というケースは典型的な見落としです。

着手する前に：誰が音頭を取るべきか

具体的な手順に入る前に、もう一つ確認しておきたいことがあります。それは「この作業を、誰の権限で進めるか」という点です。

ひとり情シス・総務兼任という立場では、アカウント一覧の整備は業務命令というより「気になったからやってみる」という自主的な取り組みになりがちです。しかし、この作業は他部署の管理者アカウントの中身にまで踏み込む調査になるため、経営層や上長に一言、目的と範囲を伝えてから始めることをおすすめします。

• 「セキュリティ・事業継続の観点から、社内で使っているシステムの管理者アカウントを一度洗い出したい」という目的を簡潔に伝える
• 各部署の担当者に協力を仰ぐ際、「なぜこの情報が必要か」を説明できるようにしておく
• 洗い出しの過程で見つかった重大なリスク（退職者のアカウントが生きている等）は、見つかった時点ですぐに報告する

この一言があるかないかで、他部署からの協力の得やすさが大きく変わります。「勝手に調べている」という印象を持たれると、正確な情報が集まりにくくなるためです。

アカウント一覧を作る5つのステップ

ここからは、実際に一覧を作る手順を順番に見ていきます。完璧を目指さず、まず現状を「見える化」することを優先してください。

ステップ1：洗い出しの範囲を決める

最初に、どこまでを洗い出しの対象にするかを決めます。いきなり全社のあらゆるアカウントを網羅しようとすると、作業が止まってしまいます。まずは次の3種類に絞って着手するのが現実的です。

1. 止まると業務全体に影響が出るもの（基幹システム、ドメイン、メールサーバーなど）
2. 月額・年額で費用が発生しているもの（SaaS契約全般）
3. 顧客情報・個人情報を扱っているもの（CRM、会計システムなど）

この3つに該当するアカウントから着手し、余力があれば範囲を広げていく進め方をおすすめします。すでにシステム管理台帳（社内で使っているシステムの名称・契約内容・費用等をまとめた台帳）を作成済みの場合は、その台帳に載っているシステムがそのまま洗い出しの対象になります。台帳をまだ作っていない場合は、アカウント一覧の作成と並行して台帳の骨格も見えてくるはずです。

ステップ2：「誰が」「どこで」「どう」ログインしているかを確認する

対象が決まったら、1つずつ次の3点を確認していきます。

• 誰が：現在、実際にログインしている人物は誰か（担当者の記憶ではなく、実際のログイン履歴やアカウント設定画面で確認）
• どこで：管理者権限を持つアカウントのメールアドレスは、会社のドメインのものか、個人のフリーメールか
• どう：パスワードだけでログインできるのか、多要素認証がかかっているのか。かかっている場合、復旧手段（電話番号・予備メール）は誰のものか

「管理者アカウントのメールアドレスを見たら、10年前に退職した元社員の個人アドレスだった」——この種の発見は珍しくありません。むしろ、洗い出しを始めて最初に見つかる典型的なパターンだと考えておいたほうがよいでしょう。

ステップ3：一覧の形式を決めて記録する

確認した内容を記録する形式は、凝ったツールを使う必要はありません。まずはExcelやスプレッドシートで十分です。最低限、次の列があれば機能します。

• サービス名・システム名
• カテゴリ（前述の4分類のいずれか）
• 契約主体（自社の法人名義になっているか）
• 管理者アカウントのメールアドレス
• パスワードの保管場所（パスワード管理ツール名など。このシート自体にパスワードを直接書き込まないこと）
• 多要素認証の有無と復旧手段
• 費用（月額・年額）と契約更新月
• 緊急連絡先（開発会社・SaaSのサポート窓口）

このシートそのものが機密情報の塊になるため、アクセス権限を絞ったうえで保管してください。パスワードそのものは別途パスワード管理ツールに保管し、一覧シートには「どこに保管されているか」の参照情報のみを記載する構成が安全です。

ステップ4：個人アドレス紐づけのアカウントを会社ドメインへ切り替える

洗い出しの過程で、個人のメールアドレスに紐づいた管理者アカウントが見つかった場合、可能な範囲で会社のドメインのメールアドレスに切り替えることを検討してください。

この切り替えには、サービス提供元への申請や、場合によっては審査が必要になることもあります。すぐにできない場合でも、「個人アドレスに紐づいている」という事実を一覧に明記しておくだけで、次に担当者が変わるときの引き継ぎリスクを可視化できます。

ステップ5：定期的な棚卸しのサイクルを決める

一覧は一度作って終わりではありません。新しいSaaSが導入されるたびに、シャドーIT（管理部門の許可を得ずに現場が独自導入したツール）として一覧から漏れていくリスクが常にあります。

• 年に1回など、決まったタイミングで一覧を見直す
• 新しいツールを導入する際は、導入時点で一覧に追記するルールを決める
• 退職・異動が発生したタイミングで、該当者が持っていたアクセス権を必ず確認する

この3点をルール化しておくと、一覧が「作った瞬間から古くなっていく」事態を防げます。

優先順位に迷ったときの考え方

洗い出しの対象がいくつも見つかると、どこから手をつけるべきか迷うことがあります。その場合は、次の2つの軸で優先順位をつけると判断しやすくなります。

このように状態ごとに優先度を仕分けると、「すべてを一度に完璧にする」のではなく、「危険度の高いものから順に潰していく」という現実的な進め方ができます。特に「最優先」に該当するものが1件でも見つかった場合は、一覧の完成を待たず、その場で対応に着手してください。退職者のアカウントが管理者権限を持ったまま放置されている状態は、情報漏えいや不正アクセスのリスクに直結します。

アカウント一覧が整うと何が変わるか

開発会社の乗り換え検討が「机上の空論」から「実行可能な計画」になる

アカウント一覧が整っていると、『開発会社の乗り換え判断フロー』で解説したような乗り換え検討が、初めて実行可能な計画になります。管理者権限があれば、データのエクスポートや契約内容の確認を、開発会社に依頼することなく自社だけで進められる場面が増えるためです。

逆に言えば、管理者アカウントへのアクセス権を自社が持たないまま乗り換えを検討すると、あらゆる確認作業を現行の開発会社に依頼せざるを得ず、相手の対応速度に検討全体が左右されてしまいます。

「うちでしか直せません」への対抗力が生まれる

『「うちでしか直せません」と言われたときの対処法』で扱ったような状況でも、自社が管理者アカウントを把握していれば、少なくとも設定画面を自分の目で確認し、開発会社の説明が妥当かどうかを検証する材料を持てます。何も確認できない状態で相手の言葉をそのまま受け入れるのと、自分で一次確認したうえで交渉するのとでは、立場が大きく変わります。

退職・異動時の引き継ぎが事故にならない

属人化対策の観点からも、アカウント一覧の存在は重要です。担当者が突然退職した場合でも、一覧さえあれば後任者はゼロから手探りする必要がなくなります。逆に一覧がない状態での担当者交代は、「パスワードを知っている人が誰もいない」という最悪の事態に直結しかねません。

既存のチェックリストとの使い分け

このサイトには、脱ロックインの状態確認に使える「ベンダーロックイン脱出チェックリスト」も別途用意しています。チェックリストは契約・データ・乗り換え準備という観点で「確認できているか／いないか」を印刷してその場でチェックする形式のツールで、アカウント一覧はそれよりも一段階手前、「誰が・どこで・どうアクセスしているか」という実務データを継続的に記録・更新していくための台帳という位置づけです。

チェックリストで「ソースコードの著作権が自社にあるか確認した」という項目にチェックを入れるためには、その確認作業自体を誰が担当し、どの管理者アカウントから何を確認したのかという実務の記録が必要になります。アカウント一覧は、その記録を支える基礎データとして機能します。両方を併用し、チェックリストで大きな進捗を管理しながら、アカウント一覧で日々の実務情報を更新していく、という使い分けをおすすめします。

小規模な会社ほど後回しにされやすい理由

ここまで読んで、「重要性は分かるが、日々の業務に追われてなかなか着手できない」と感じた方も多いはずです。実際、アカウント一覧の整備は、専任の情シス部門を持つ企業よりも、総務や経理と兼務でシステムを見ている担当者のいる会社のほうが、後回しにされやすい傾向があります。

理由は単純で、専任部門であれば「アカウント管理」自体が業務の一部として定義されているのに対し、兼務の担当者にとっては、日々の問い合わせ対応や目の前の業務に追われる中で、いつまでも「緊急ではないが重要」なタスクの位置にとどまり続けてしまうためです。しかし、この種のタスクこそ、何かトラブルが起きてから着手したのでは手遅れになりやすいという性質を持っています。担当者の退職が決まってから慌てて管理者アカウントを洗い出そうとしても、本人が退職してしまえば確認する相手がいなくなります。

だからこそ、「時間ができたら」ではなく、この記事を読んだ今日、最初の3件だけでも書き出してみることに意味があります。3件であれば、30分もあれば着手できるはずです。

よくあるつまずきとその対処

つまずき1：「全部を完璧に洗い出そう」として止まる

最も多い失敗パターンは、最初から完璧な一覧を目指して、着手する前に力尽きてしまうことです。前述の通り、まずは「止まると困るもの」「費用が発生しているもの」「個人情報を扱うもの」の3種類に絞り、8割の精度で構わないので一覧を作り切ることを優先してください。抜けている項目は、あとから気づいた時点で追記すれば十分です。

つまずき2：パスワードそのものを一覧に書き込んでしまう

一覧シート自体にパスワードを直接記載すると、そのシートが漏えいした際のリスクが跳ね上がります。パスワードは専用のパスワード管理ツールに保管し、一覧シートには「どのツールのどのフォルダに保管されているか」という参照情報だけを載せる形にしてください。

つまずき3：管理者権限が複数人に分散していることに気づかない

1つのサービスに対して、実は複数の人が個別に管理者アカウントを持っていた、というケースもあります。洗い出しの際は「担当者は誰か」だけでなく、「そのサービスの管理画面に、他に誰がログインできる状態になっているか」まで確認するようにしてください。想定していない人物（退職者を含む）が管理者権限を持ったままになっている事例は珍しくありません。

つまずき4：協力を依頼した部署から反応が返ってこない

他部署の担当者に「使っているツールの管理者アカウントを教えてほしい」と依頼しても、優先度が低いと判断されて後回しにされることがあります。この場合、依頼の仕方を「情報を教えてください」という受け身の聞き方から、「一緒に画面を見ながら5分だけ確認させてください」という具体的な行動に変えると、反応が得やすくなります。相手にとって「何をどれだけの時間、協力すればよいか」が明確なほど、着手のハードルは下がります。

つまずき5：一覧を作った後、更新されずに放置される

一覧を一度作っただけで満足してしまい、半年後には状況が変わっているのに一覧だけが古いまま、というのもよくある失敗です。前述のステップ5で触れた「棚卸しのサイクル」を、カレンダーやタスク管理ツールに実際の予定として登録しておくことをおすすめします。「いつか見直す」ではなく「毎年◯月に見直す」という具体的な日付にしておくと、実行される確率が大きく上がります。

アカウント一覧整備と他の脱ロックイン施策との関係

最後に、このカテゴリで解説してきた他の施策と、アカウント一覧整備がどう関係するかを整理しておきます。順番に着手する際の目安にしてください。

1. アカウント一覧の整備（この記事）：自社がどのシステムに、どうアクセスできるかを可視化する
2. 契約書・権利関係の確認：著作権・ライセンス・データの権利がどうなっているかを確認する。詳しくは『システムの権利関係の整理』を参照
3. データのエクスポート可否の確認：管理者アカウントでログインし、実際にデータを取り出せるか試す。詳しくは『自社システムのデータを吸い出せるか確認する方法』を参照
4. 保守費・契約内容の見直し：管理者アカウントの契約画面から、現在の費用と契約条件を確認する。詳しくは『月額保守費の相場と見直し方』を参照
5. 乗り換え・内製化の検討：ここまでの情報が揃って初めて、乗り換えや内製化の是非を具体的に検討できる段階に入ります

この順序が示す通り、2〜5のどのステップも、起点にあるのは「自社がアクセス権を持っているかどうか」です。アカウント一覧の整備を後回しにしたまま契約書の確認だけを進めても、いざ実行しようとした段階で「そもそもログインできない」という壁に突き当たります。このカテゴリを最初から読んできた方は、ぜひこの記事を最後の実践編として位置づけ、明日からの行動に落とし込んでください。

まとめ：今日、開くべきものは何か

このカテゴリで解説してきた契約書の確認、データのエクスポート、保守費の見直し、開発会社の乗り換え判断——これらはすべて重要な論点ですが、いずれも「自社が対象のシステムにアクセスできる」ことが前提になっています。

今日、この記事を読み終えたら、まず開いてほしいのはExcelやスプレッドシートの新規シートです。そこに「止まると困るシステム」を3つだけ書き出し、それぞれの管理者アカウントが誰のものか、会社のドメインに紐づいているかを確認するところから始めてください。19本の記事で得た知識は、この1枚のシートを起点に、初めて実務として動き出します。

脱ベンダーロックインは、一度の作業で完結するものではなく、継続的な体制づくりです。アカウント一覧はその体制づくりの出発点であり、同時に、いつ戻ってきても現在地を確認できる地図の役割も果たします。今後、開発会社の乗り換えを検討するとき、SaaSの契約更新のタイミングが来たとき、担当者が交代するとき——その都度、この一覧を更新しながら向き合っていくことになります。

次に読むべき記事に迷ったら、まずは『ベンダーロックインとは？中小企業が陥る典型パターン』でこのカテゴリ全体の地図を再確認するか、あるいは『社内システムの現状調査（棚卸し）のやり方』で、アカウント一覧をより体系的な台帳に発展させる方法を確認してみてください。