誰の権限も剥がせない事業を買う怖さ
事業の売買で、いちばん多く飛んでくる質問は「いくらですか」です。そして、いちばん答えるのに時間がかかる質問は「これ、結局いま誰が触れるんですか」です。数字は資料に書いてありますが、権限は、どこにも書かれていないからです。
買い手のエンジニアが、クロージングの前に必ず一度は考えることがあります。引き渡しが終わったあと、この事業の本番環境に、旧オーナーはまだ入れるのか。開発を手伝っていた業務委託の人は。2年前に辞めていったメンバーは。ごく当たり前の疑問なのですが、この質問に即答できる中小規模の事業は、実際のところ驚くほど少ないのが現状です。
しかも厄介なのは、答えられない理由が「売り手が隠しているから」ではないという点です。本当に、誰も知らない。この記事では、権限の設計が属人化したまま育った事業を引き継ぐときに何が起きるのか、そしてそれがなぜ単なるセキュリティの宿題ではなく、事業の値段そのものに直結する問題なのかを、順番に解きほぐしていきます。
「全員が管理者」は、その時いちばん正しい設計だった
最初に、はっきりさせておきたいことがあります。少人数で走ってきた事業の権限管理がザルであることを、後から来た人間が笑うのは筋が違います。あれは怠慢ではなく、その時点における最適解だったからです。
3人でサービスを回している局面を想像してみてください。深夜に決済が詰まった、明日の朝までに直さないと問い合わせが溢れる。そのときに「本番DBの参照権限を申請したので承認をお願いします」と誰かの起床を待つ設計は、正しさとしては満点でも、事業としては失格です。全員が全部触れる状態が、最も速く、最も事故が少ない。だから全員が管理者になった。権限を細かく設計する工数は、その時点では純粋にプロダクトから奪われた時間でしかありませんでした。
実際、立ち上げ期に権限設計を丁寧にやった事業がスケールしたという話より、権限をザルにしたまま機能を出し続けた事業が伸びたという話のほうを、私たちは圧倒的に多く見ています。あれは合理的な判断でした。
ただ、この設計はひとつの前提の上に建っています。ここにいる全員が信頼できて、全員がこれからもここにいて、事業と自分たちが一体であるという前提です。売却は、この3つを同時に、しかも一瞬で無効にします。設計が間違っていたのではありません。設計が乗っていた地面のほうが、売ると決めた日に消えるのです。
権限の一覧は、どこにも存在しない
権限を剥がすには、まず誰が何を持っているかを知る必要があります。ところが、その一覧が存在しない。ここが最初の壁です。
理由は単純で、権限がサービスごとにバラバラに存在しているからです。クラウドのIAM、リポジトリのコラボレーター、決済管理画面のメンバー、DBのユーザー、サーバーに配られたSSHの公開鍵、VPNのアカウント、ドメインレジストラ、広告アカウント、それに数え切れないSaaSの招待。ID基盤で束ねていない事業では、「この人が何を持っているか」を中央から引ける場所が、そもそも用意されていません。一覧が散らばっているのではなく、一覧という概念が最初から無い状態です。
そこに、個人のGmailで作られたアカウントが混ざります。共有のadminアカウントを全員で使い回している箇所も出てきます。数年前に外注へ一時的に渡したきり、返してもらった記憶がないものもあります（「返してもらう」という発想自体が、当時は無かったわけです）。
この論点はアカウント名義の問題と混同されやすいのですが、別の層の話です。名義は「その契約の当事者は誰か」であり、権限は「そのアカウントで実際に何ができるか」です。名義がきれいに法人へ移ったあとでも、その配下にぶら下がっている権限が汚れていれば、事業の支配権は移りません。
もうひとつ、構造的な性質があります。権限は増える一方で、減ることがないという性質です。権限は付与された瞬間だけ意識されます。「明日までにここを見てほしいので招待しますね」。その瞬間は全員が状況を理解している。しかし、その作業が終わったことを誰かがカレンダーに書いて、権限を戻す日を管理している事業は、まずありません。付与にはきっかけがあり、剥奪にはきっかけが無い。だから権限だけが、地層のように静かに積もっていきます。
そして重要なのは、この棚卸しがDD期間中に「調べれば分かる」類のものではないということです。情報が散らばっているなら、時間をかければ集まります。しかしここで起きているのは、そもそも記録されたことが一度もないという事態です。集める先が無い。
剥がすと何が壊れるのか、誰も知らない
仮に、時間をかけて一覧を作れたとします。次に来る壁のほうが、はるかに高い。剥がせないのです。
技術的には、ボタンひとつです。招待を取り消す、IAMユーザーを消す、鍵を無効にする。10秒で終わります。それでも押せない。理由は、その個人アカウントが、システムの実行主体になっているからです。
人が使う入口だと思っていたアカウントが、実は機械の心臓だったというケースは、本当に頻繁に起きます。深夜の集計バッチが、旧オーナー個人のAPIキーで叩いている。CIのシークレット変数に、その人が発行した個人トークンが入っている。外部SaaSとの連携が、連携を作った人のOAuth認可の上に成立していて、そのアカウントが消えると連携ごと沈黙する。決済管理画面の二段階認証が、旧オーナーの携帯に紐づいている。クラウドのリソースを、個人のIAMユーザーが作成者として保持している。
そして最悪なのは、これらが剥がした瞬間には何も壊れないことです。今日は動きます。明日も動く。壊れるのは、翌月の締め日であり、四半期の請求であり、証明書の有効期限が来る90日後です。cronジョブの引き継ぎが抜けた事業で売上が静かに消えるのと、まったく同じ時間差の構造です。
だから買い手は、正しく怖がります。「このアカウント、消していいですか」と尋ねて「たぶん大丈夫だと思います」と返ってきた瞬間、その権限は永久に剥がせなくなる。買ったばかりの事業を自分の手で止めたら、それはもう買い手の過失として処理されるからです。「たぶん」で本番を落とす権限は、買い手にはありません。
こうして、買い手は何ひとつ剥がせないまま運用を開始することになります。
剥がせないまま引き渡された事業に起きること
この状態を正確に言語化すると、こうなります。事業の所有権は移った。しかし、事業の支配権は移っていない。
まず、旧オーナーが本番に入れる状態が続きます。ここで想像しがちな「悪意ある元オーナーが復讐する」みたいな話は、実務ではまず起きません。起きるのはもっと地味で、もっと厄介な事態です。心配だから様子を見に行ってしまう。頼まれてもいないのに直してしまう。あるいは、本人にその気がなくても、アラートと決済通知と顧客からの問い合わせが、いつまでも旧オーナーの受信箱に届き続ける。
次に、契約が終わっている人たちの権限が生き残ります。元業務委託の端末には、いま別のクライアントの案件が入っています。その同じ端末の中に、あなたが買った事業の本番の鍵が残っている。誰も悪くない。ただ、誰も回収していないだけです。
個人情報を扱う事業なら、事態はもう一段深刻になります。買い手は個人情報の管理主体になったにもかかわらず、その個人情報にアクセスできる人間の一覧を持っていない。何か起きたときに提出する報告書の「アクセス権者」の欄を、埋められないということです。
実務でいちばん頻繁に見るのは、もっと穏やかな形をした失敗です。買い手が「まだ分からないことが多いので、しばらく権限は残しておいてください」と自分から頼むパターン。合理的な判断に見えますし、実際その場では助かります。ところがこれが、引き継ぎの完了を無期限に先送りします。聞けば教えてもらえる状態が続く限り、買い手は本気で調べません。半年後、旧オーナーの善意が尽きたタイミングで、事業は「誰も理解していない」状態のまま買い手の手元に取り残されます。権限を残すという判断は、引き継ぎを先延ばしにするという判断と、実質的に同じものです。
そして、何かが実際に壊れたとき。誰がやったのかを特定できません。旧オーナーを疑うこともできないし、疑わないこともできない。判断材料が存在しないからです。関係が壊れるのは、事故が起きたときではなく、事故の原因を誰も証明できないと分かったときです。
これはセキュリティの話であり、同時に価値の話
権限の論点は、たいていセキュリティのチェック項目として持ち出されます。ただ、本質はそこではないと考えています。
事業を買うという行為は、その事業を自分の意思で動かせる状態を買うことです。権限を剥がせないというのは、自分の意思では動かせない部分が残っているということに他なりません。
合鍵が何本出回っているか分からない家を想像してください。住めます。今日も明日も普通に住める。でも、それをあなたの家と呼べるでしょうか。鍵を全部こちらで握れる家と、同じ値段を払っていいでしょうか。
M&Aの世界で「独立した事業として切り出せるか」という論点は、契約書と資産一覧の話だと思われがちです。実際には、権限の話でもあります。権限が旧オーナーの人格に癒着している事業は、人格ごとしか売れない。だから、その人が去った瞬間に価値が目減りする。買い手が支払っているのは事業の対価であって、旧オーナーという人間のレンタル料ではないはずです。
査定への効き方は、そのまま裏返しになります。権限を剥がせる事業は、事業と人が分離しています。買った通りのものが手に入る。権限を剥がせない事業は、分離していません。契約が終わったあとも旧オーナーへの依存が続き、その依存には終わりの日付が設定されていない。
ここが、少人数チームの「全員が管理者」が意味を変える瞬間です。運用効率のために選ばれた設計が、売却の局面では「分離不能」という減点として計上される。繰り返しますが、判断が間違っていたわけではありません。前提が変わったので、同じ設計の意味が変わっただけです。
買い手は権限をどう検分するか
技術的DDの一項目として権限を見るとき、質問の仕方を間違えると何も出てきません。順序をつけて整理します。
一覧は「出してもらう」のではなく「一緒に作る」
「権限の一覧を出してください」と依頼すると、返ってくるのは主要な3サービス分です。隠しているのではなく、忘れているだけです。棚卸し表は、DDの成果物として双方で作る前提に置くほうが早い。作る過程そのものが、その事業の権限に対する解像度を測る検査になります。
質問ではなく、実演で確かめる
「この人の権限、剥がせますか」への答えは、ほぼ確実に「剥がせます」です。そうではなく、「試しにひとつ、いま剥がしてみてもらえますか」と頼むべきです。剥がして、何も壊れないことを確認するところまで。全部やる必要はありません。1件やってみれば、その事業に「剥がす手順」が存在するのかどうかが、はっきり分かります。
アカウントごとに「これが死ぬと何が止まるか」を聞く
ここで即答できないアカウントは、剥がせないアカウントです。答えられない事実そのものが、そのアカウントがシステムの実行主体になっている可能性を示しています。
共有アカウントの数を数える
個人に紐づかない管理者アカウントが何個あるか。これは属人化の度合いを測る、もっとも直接的な指標です。共有アカウントが1つあるだけで、その範囲では「誰が何をしたか」の記録が原理的に成立しなくなります。
過去に本番へ触れた人を、全員挙げてもらう
現在のメンバーではなく、過去です。辞めた人、契約が切れた外注、試用期間中に招待したきりの相手。人数と、その人たちの権限が現在どうなっているか。ここで名前が5人出てきて、そのうち3人の権限状態が不明なら、それが引き渡し後にあなたが背負う数字です。
そして最後に、剥がす作業を誰の費用と時間で行うのかを、価格の話に含める。DDで発見した権限の混乱は、必ず引き渡し後の作業として残ります。それを買い手の持ち出しにするのなら、その分は価格に反映されるべきです。しかもこれは工数だけの問題ではありません。剥がし終わるまでの数ヶ月間、旧体制が本番に入れる状態が続くという、時間で計上すべきリスクでもあります。
売り手が、売ると決める前にやっておくこと
順序が決定的に重要です。売却を決めてから始めると、交渉のテーブルで作業することになります。買い手はその様子を見て、価格ではなく信頼のほうを調整し始めます。
いちばん時間がかかり、いちばん効くのは、人格とシステムを引き剥がす作業です。バッチ、CI、外部連携の実行主体を、個人アカウントからサービスアカウントへ移す。地味で、誰にも褒められず、機能が1つも増えない作業ですが、これをやった事業とやっていない事業では、引き渡しの難易度が別物になります。人が抜けても動く状態を作るというのは、要するにそういうことです。
そのうえで、棚卸しの表を作ります。列は5つで足ります。サービス名、アカウント、誰が持っているか、剥がしたら何が止まるか、そして剥がす手順。名義の棚卸しをすでにやっているなら、その表に列を足すだけで済みます。
過去の招待を洗うのも忘れないでください。「もう持っていないはずです」と思っている権限は、だいたい生きています。そして共有アカウントは、可能な範囲で個人アカウントへ割り直す。誰が何をしたかが残る状態そのものが、事業の資産になります。
最後に、引継ぎマニュアルに権限の章を設けること。ここが空白のまま引き渡すと、買い手は権限に触れるたびに旧オーナーへ確認の連絡を入れることになり、その連絡はいつまでも終わりません。権限を渡していないというのは、質問される義務を手放していないということです。
権限を剥がせる形にすることは、疑いの表明ではない
権限を分けるという行為は、しばしば「信頼していない」というメッセージとして受け取られます。特に、仲間と少人数でここまで来た事業では、そう感じるのが自然だと思います。
けれど、権限を設計する理由は不信ではありません。事業が、人より長く続くからです。作った人が病気になっても、燃え尽きても、まったく別のことをやりたくなっても、事業のほうは翌朝も動く。そのときに、誰が何を触れるのかが定義されていないと、事業は動き続けているのに誰も手を出せないという、いちばん救いのない状態になります。
買い手が権限を怖がるのも、旧オーナーを疑っているからではありません。剥がせないという事実そのものが怖いのです。全員が善人であっても、把握されていない鍵は、いつか誰かの手に渡ります。悪意は必要ありません。管理されていないという状態だけで、事故は十分に成立します。
そして売り手にとって、これは値段の話でもあります。権限を剥がせる状態にしておくと、交渉の場で「この事業は、私がいなくても成立します」ということを、言葉ではなく構造で示せる。買い手が本当に知りたいのはそこです。どんな資料よりも雄弁で、どんな説得よりも強い。
「全員が管理者」で駆け抜けた日々は、間違いではありませんでした。あの速度がなければ、そもそも売れる事業になっていない。ただ、その設計は「自分たちがずっとここにいる」という前提の上に建っています。売るという決断は、その前提から降りると決めることです。だとしたら、降りたあとも事業が誰かの手で回るように、鍵の在り処を先に整理しておく。それは、自分が作ったものを最後まで面倒みる、という話だと思うのです。
