ある日突然届いた一本のメール
「弊社担当者の異動に伴い、今後の窓口を変更いたします」
先代から会社を継いで三年目のある月曜の朝、後継社長のもとにそんなメールが届いた。差出人は、創業当時から自社のホームページと基幹システムの保守を任せてきた開発会社だ。文面は丁寧だが、内容はそれだけだった。新しい担当者の名前と連絡先が添えられているだけで、これまで何を、どう管理してきたのかについては一切触れられていない。
社長は少し嫌な予感がした。先代の時代からこの開発会社と付き合いがあり、システムのことは「あの担当の人に任せておけば大丈夫」という空気が社内にずっとあった。誰がサーバーの管理画面のパスワードを持っているのか、ドメインの契約更新はいつで支払いはどこから出ているのか、社長自身も、経理の担当者も、正確には把握していない。今まで大きな問題が起きなかったのは、担当者が個人として状況を把握し続けてくれていたからにすぎなかった。
その担当者が変わるということは、これまで担当者の頭の中だけに蓄積されていた情報が、そのまま新しい担当者に漏れなく引き継がれるとは限らないということでもある。もし引き継ぎが不十分なまま新担当者が業務を始めれば、過去の経緯を知らないまま見積もりが出され、既存の仕様を無視した改修が提案され、最悪の場合は契約内容や管理権限の所在すら曖昧になってしまう。
後継社長という立場は、こうした「これまで大丈夫だったこと」が実は先代個人や特定の担当者の信頼関係の上に成り立っていたことに、代替わりのタイミングで初めて気づかされることが多い。開発会社の担当者変更は、その気づきが強制的に訪れる典型的な場面のひとつである。担当者が変わったという知らせを受け取ったときに、後継社長自身がどう動くべきかを整理しておく必要がある。
社長は椅子に座り直し、パソコンの画面をもう一度見つめた。返信の文面をどう書くべきか、そもそも何を確認すればよいのかすら、すぐには言葉にならなかった。総務担当の社員に声をかけても「いつもの担当さんとしかやり取りしていないので、詳しくはわかりません」という返事が返ってきただけだった。経理に聞いても同様で、支払いの記録は残っているが、その支払いが何のための費用で、どの契約に基づいているのかを正確に説明できる人は社内に一人もいなかった。
先代が現役だった時代は、こうした細かいことは先代自身が把握していたか、あるいは「知らなくても回っている」という状態がそのまま許容されていた。しかし今、経営の責任を負っているのは自分自身である。もし新しい担当者が対応を誤り、ホームページが表示されなくなったり、顧客情報が漏れたりすれば、その責任を取るのは開発会社ではなく、発注者である自分の会社になる。社長はそのことに、このメール一本で初めて実感を持って気づかされた。
こうした場面は、決して珍しいものではない。事業承継を経験した後継社長の多くが、似たような形で「システムのことは全部お任せ」という状態の危うさに直面している。担当者変更という出来事は、普段は見えない構造的な脆さを一瞬だけ可視化してくれる、いわば健康診断のような機会でもある。この記事では、なぜこうした事態が起こるのかという構造を整理し、実際に後継社長が取るべき対応をステップごとに解説していく。
さらに悪いことに、この社長のケースでは、旧担当者への直接の連絡先すらメールの署名以外には残っていなかった。名刺は何年も前に受け取ったものが引き出しの奥にあるだけで、携帯電話の番号が今も使われているかどうかもわからない。もし新担当者への引き継ぎに漏れがあり、旧担当者本人に確認したいことが出てきても、その手段自体が失われているかもしれない。社長は、こうした「もしも」の積み重ねに気づくたびに、背筋が寒くなるような感覚を覚えた。それでも、この気づきこそが、後継社長として次に取るべき行動を明確にする出発点になる。
なぜ担当者変更が経営リスクになるのか
開発会社の担当者交代は、単なる「連絡先の変更」ではない。ここには複数の構造的な問題が絡み合っている。順番に見ていく。
属人化した知識が引き継ぎの前提になっていない
多くの中小企業では、開発会社との取引は「会社対会社」ではなく、実質的には「社長（または先代）対担当者個人」という関係で成立してきた。担当者は長年の付き合いのなかで、その会社の業務フロー、社内政治、過去の失敗、なぜ今の仕様になっているのかという経緯を、ドキュメント化せずに頭の中に蓄積している。
たとえば「なぜこの機能だけ古い作りのまま残っているのか」「なぜこの画面には特殊な例外処理が入っているのか」といった経緯は、当時のやり取りに立ち会った担当者本人にしか正確にはわからないことが多い。仕様書に残されていればまだよいが、実際には「打ち合わせの場でその場で決まり、そのまま実装された」というケースが少なくなく、そうした細部の経緯はドキュメントには残らずに担当者の記憶だけに保存される。
この状態では、担当者が異動・退職すると同時に、会社の情報資産の一部が事実上失われる。開発会社側の社内で正式な引き継ぎ資料が作られていればまだ良いが、口頭の申し送りだけで済まされているケースは非常に多い。特に中小の開発会社やフリーランスに近い体制の会社では、引き継ぎのための時間や工数が契約に含まれていないことも珍しくない。引き継ぎ作業そのものが「無償の善意」に近い扱いになっており、退職が急な場合や、担当者本人が多忙な場合には、簡単な資料の受け渡しだけで済まされてしまうことも多い。
さらに厄介なのは、この属人化が「悪意によって生じたものではない」という点である。担当者は決して情報を隠したかったわけではなく、単純に日々の業務のなかで文書化する時間的な余裕がなかった、あるいは「聞かれたら答えればいい」という感覚で仕事を進めてきた結果、自然とそうなってしまったにすぎない。だからこそ、発注側がこの構造に気づかずに放置していると、誰の責任でもないまま情報が失われていく。
発注側にも同じ属人化が起きている
問題は開発会社側だけではない。発注側の中小企業でも、システムに関する窓口が特定の一人に集中していることが多い。先代社長、あるいは総務・経理の特定の担当者だけが、契約書のファイルの場所、管理画面のログイン情報、ドメインやサーバーの契約者情報を知っている。
これは中小企業においてはある意味で自然な現象でもある。システムに関する話題は専門性が高く感じられ、日々の業務で頻繁に触れるものでもないため、「詳しい人に任せておけば安心」という分業が自然と生まれる。先代の時代から長く一人の担当者が窓口を担ってきた場合、その担当者が異動や退職、あるいは病気やけがで急に不在になった場合の代替手段が用意されていないことも多い。
代替わりのタイミングでこの「発注側の属人化」と「開発会社側の担当者変更」が重なると、両方の当事者が情報の全体像を把握していない状態で取引が継続することになる。これは、システムの契約・運用管理において最も危険な状態のひとつである。どちらか一方でも情報を握っていれば復元できるが、両方が抜けていると、契約内容そのものが「誰にもわからない」状態になりかねない。
特に事業承継の場面では、先代社長が引退や高齢化によって完全に経営の第一線から退いてしまうケースが多く、後継社長が「先代に聞けばわかる」という前提そのものが崩れていることがある。先代が存命であっても、細かいシステムの契約内容までは覚えていない、あるいは当時のやり取りの記憶が曖昧になっているということも珍しくない。こうなると、開発会社側の担当者変更という外部要因が引き金となって、発注側の内部にもともと潜んでいた情報の空白が一気に露呈することになる。
契約書と実態がずれていることが引き継ぎ時に露見する
長年の付き合いのなかで、契約書に書かれている作業範囲と、実際に担当者が善意でやってくれていた作業とがずれていくことがある。例えば、契約上は「月次のセキュリティパッチ適用のみ」であっても、担当者が気を利かせて小さな不具合修正やちょっとした機能追加を無償で対応していたようなケースだ。
担当者が変わると、新しい担当者は契約書ベースで業務範囲を判断する。これまで無償で対応してもらっていた作業が、契約上の範囲外だとして有償化されたり、対応そのものを断られたりすることがある。これは開発会社側が不誠実というわけではなく、契約と実態のギャップが可視化されただけなのだが、発注側からすると「急にサービスが悪くなった」という印象を持ちやすい。
この現象は、旧担当者が個人として発注側の会社に肩入れしていたことの裏返しでもある。長い付き合いのなかで信頼関係が育つと、担当者は契約書に書かれた範囲を超えて対応することに、それほど心理的な抵抗を感じなくなる。しかし、その対応は会社としての正式なサービスではなく、担当者個人の裁量によるものである以上、その担当者がいなくなれば当然に失われる可能性がある。発注側がこの構造を理解していないと、契約書という「正式なルール」と、実際の運用という「非公式な慣習」の二重構造に気づかず、慣習の方を当然の権利のように感じてしまう。この認識のずれが、担当者変更のたびに小さな摩擦を生む火種になる。
仕様書・設計資料の有無が引き継ぎ品質を決める
新しい担当者が過去の経緯を正確に理解できるかどうかは、最終的には「ドキュメントが残っているか」にかかっている。要件定義書、仕様書、設計資料、過去の変更履歴が体系的に残されていれば、新担当者はそれを読み込むことで一定水準の理解に到達できる。
逆にドキュメントがほとんど存在せず、ソースコードとメールのやり取りだけが情報源という状態だと、新担当者は手探りで理解するしかない。この場合、引き継ぎ直後の数か月は対応品質が落ちる、見積もりが不正確になる、既存の仕様を壊すような改修が提案されるといったリスクが高まる。ドキュメントの有無は、発注側が確認しコントロールできる数少ない要素であり、担当者変更のたびに問われる論点になる。
特にホームページを開設してから何年も改修を重ねてきたシステムほど、初期の設計思想と現在の実装がずれていることが多く、この「なぜ今の形になっているのか」を説明できる資料がなければ、新担当者は既存のコードを一つひとつ読み解くところから始めなければならない。これは時間もコストもかかる作業であり、その分の工数が見積もりに跳ね返ってくることもある。発注側からすれば「同じ会社に頼んでいるのに、なぜ急に費用が増えたのか」という疑問につながりやすいが、その背景には、担当者交代によって暗黙知が失われ、明示的な調査が必要になったという事情が隠れている。
ドキュメントが整備されているかどうかは、実は発注時点、つまり先代がシステムを発注した当初の判断にまでさかのぼる問題でもある。安価な見積もりを優先して、ドキュメント作成を工程から外していた場合、そのしわ寄せは何年も後の担当者変更のタイミングで一気に表面化する。後継社長としては、現時点でドキュメントが存在しないという事実を受け止めた上で、今後の改修や新規開発の際には必ずドキュメントの整備を契約条件に含めるという学びに転換していくことが望ましい。
管理者権限・パスワードの所在が不明確なまま運用されてきた
サーバー、ドメイン、CMS、SNS連携、決済代行、解析ツールなど、事業を支えるシステムには大小さまざまな管理者権限が存在する。これらのログイン情報やAPIキーが、開発会社側の担当者個人のメモや、個人のパスワード管理ツールに保存されているだけで、発注側が独自に把握していないケースは非常に多い。
担当者が退職・異動すると、その情報の受け渡しが正式に行われるかどうかは、開発会社の社内体制と、発注側からの働きかけの両方に依存する。発注側が「うちのアカウントの管理者権限は誰が持っていて、今どこに保管されているか」を確認しないまま放置すると、いざドメインの更新やサーバー移行が必要になったときに、誰もログインできないという事態に陥ることがある。
管理者権限の問題がとりわけ深刻なのは、これが単なる不便さの問題では済まず、事業継続そのものを脅かすリスクになりうる点である。ドメインやサーバーの契約が誰の名義で、どのメールアドレスに紐づいているかが不明確な場合、契約更新の通知が届く先すら発注側で把握できていないことがある。通知メールが旧担当者の個人アドレスや、退職済みの人物のアドレスに届き続けているケースも実際にある。この場合、更新期限が過ぎてサービスが停止するまで、誰もその危険に気づけない。
また、複数のシステムが連携して動いている場合、管理者権限の所在はさらに複雑になる。ホームページのCMS、問い合わせフォームの送信先、決済システム、外部の予約システムなど、それぞれ異なるサービスに異なる管理者権限が存在し、それぞれが異なる担当者や異なる開発会社によって管理されていることもある。これらすべての所在を発注側が把握していなければ、担当者変更のたびに「このシステムは誰が管理していたのか」という確認作業から始めなければならなくなる。
相性・コミュニケーションスタイルの再構築コストがかかる
技術的な引き継ぎとは別に、人間関係の再構築という側面も無視できない。先代社長の時代からの担当者は、業界特有の言い回しや、社内の力関係、過去の失敗談まで理解した上でコミュニケーションを取ってくれていた。新しい担当者は、それをゼロから学び直す必要がある。
後継社長側も同様に、新しい担当者がどの程度の技術的な説明を好むのか、どこまで先回りして提案してくれるのか、逆にどこまで細かく指示を出す必要があるのかを見極める期間が必要になる。この相性の再構築には数か月かかることもあり、その間はコミュニケーションのロスによる小さな行き違いが増える傾向がある。
さらに、後継社長自身が先代と比べてITの知識にどの程度自信を持っているかによって、新担当者との関係の築き方も変わってくる。先代がITに詳しくなかった場合、担当者に強く依存する形で関係が成立していたことが多く、後継社長が経営を引き継いだ後もその依存関係をそのまま引き継いでしまいがちである。一方で、後継社長自身が一定の知識を持っている場合は、新担当者との間で対等な議論ができる可能性が高まるが、その分「細かいことにこだわる面倒な発注者」という印象を持たれないよう、伝え方に気をつける必要も出てくる。
いずれにしても、担当者変更の直後は、双方が手探りで関係を築いていく期間であり、この期間にどれだけ丁寧なコミュニケーションを積み重ねられるかが、その後何年にもわたる関係の質を左右する。最初の数回のやり取りで「この発注者は自社のシステムについて理解しようとしている」という印象を新担当者に持ってもらえれば、その後の対応の優先度や提案の質にも良い影響が出やすい。
ケーススタディで見る引き継ぎの実際
ケース1 ドメイン更新のタイミングで発覚した管理権限の空白
ある製造業の後継社長は、先代から会社を引き継いで二年目に、長年付き合いのある開発会社から担当者変更の連絡を受けた。それまでの担当者は先代社長の代からの付き合いで、会社のホームページとドメイン、レンタルサーバーの契約を一括して管理していた。
新担当者への引き継ぎ後、半年ほどたったころ、ドメインの更新期限が近づいているという通知メールが後継社長のもとに直接届いた。しかし社長はドメインの契約者情報がどこにあるのか、更新の支払いがどの口座から行われているのかを把握していなかった。新担当者に確認したところ、旧担当者からの引き継ぎ資料にはドメインの契約者名義や更新スケジュールの記載がなく、新担当者自身も正確な状況を把握できていないことが判明した。
結果として、ドメインの更新期限まで時間がなく、契約者名義の確認や本人確認の手続きに追われることになった。最終的には期限内に更新できたが、もし数日遅れていればドメインが失効し、ホームページとメールサーバーが同時に停止するリスクがあった。このケースから、担当者変更のタイミングで「契約者名義」「更新スケジュール」「支払い方法」を発注側自身が文書として保持しておく重要性が明確になった。
後日、後継社長はこの一件を振り返り、なぜこうした事態が起きたのかを新担当者と一緒に検証した。判明したのは、旧担当者が個人で契約していたレジストラのアカウントに、社長の会社のドメインが他の複数のクライアントのドメインと一緒にまとめて登録されていたという事実だった。旧担当者は退職にあたって、自分が管理していたドメインのリストを会社に提出していたが、そのリストのなかで社長の会社のドメインの記載に誤りがあり、正確な契約者情報が新担当者にも伝わっていなかった。
この経験を踏まえて、後継社長はドメインとサーバーの契約を、開発会社のアカウントから自社名義のアカウントへ移管する交渉を行った。移管には数週間を要したが、完了後は更新期限や支払いの通知が直接社長の会社に届くようになり、開発会社の担当者が誰であっても、契約の存続に関わる重要な情報が発注側の手を離れることはなくなった。検収に合格した後、開発会社との関係で気をつけたいことについては、検収に合格した後、開発会社との関係で気をつけたいことでも扱っている。この一件は、担当者変更というきっかけがなければ発覚しなかった潜在的なリスクだったといえる。
ケース2 無償対応が有償化され現場との関係がこじれた例
ある小売業の後継社長のもとでは、長年の担当者が「ちょっとした画像の入れ替えやテキスト修正」を無償のサービスとして対応してくれていた。これは契約書には明記されておらず、担当者の善意に近い対応だった。現場の店長たちは、この対応を前提にキャンペーン用のバナー差し替えなどを気軽に依頼していた。
担当者が異動し、新担当者が着任した後、同様の依頼をしたところ「それは保守契約の範囲外なので、都度見積もりになります」という回答があった。現場からは「今まで無料でやってもらえていたのに、なぜ急に有料になったのか」という不満が後継社長に寄せられた。後継社長は開発会社との契約書を確認したところ、実際に保守契約の範囲は「月次のバックアップとセキュリティ更新」のみであり、画像やテキストの修正は契約上そもそも対象外だったことがわかった。
この件は、後継社長が開発会社と改めて話し合い、軽微な修正作業を含む保守プランへの契約変更を行うことで解決した。しかし、この経緯を通じて、後継社長は「これまで無償で対応してもらっていた作業の範囲」を正確に把握していなかったこと、そして現場がその曖昧な運用に依存していたことの両方に気づかされた。担当者変更は、こうした契約と実態のギャップを露見させるきっかけになりやすい。
この事例で注目すべきなのは、後継社長が現場の店長たちからの不満を受けて初めて事態を把握したという点である。それまで社長自身は、日々の軽微な修正依頼がどのくらいの頻度で発生していて、それがどのような扱いになっていたのかを全く把握していなかった。現場は現場のレベルで開発会社の担当者と直接やり取りをしており、その関係性が社長の目の届かないところで独自に運用されていたのである。
後継社長は、この一件をきっかけに、現場から開発会社への直接の依頼ルートを一度整理し、依頼内容と対応結果を簡単な台帳に記録する仕組みを新たに設けた。これにより、今後同様の担当者変更が起きた場合でも、現場がどの程度の頻度でどのような依頼をしてきたのかを社長自身が把握できる状態になった。運用フェーズにおける社内と開発会社の役割分担の整理の仕方は、運用フェーズの体制。承継後の社内と開発会社の役割分担にまとめている。また、契約変更によって軽微な修正作業が正式な保守範囲に含まれたことで、現場の店長たちも依頼のたびに気を遣う必要がなくなり、結果的に以前よりも安定した運用体制を築くことができた。
ケース3 引き継ぎ資料が充実していたことで混乱を最小限にできた例
対照的な例として、ある建設業の後継社長のケースを紹介する。この会社が付き合っていた開発会社は、担当者変更にあたって、事前に「引き継ぎ資料」として要件定義書の最新版、過去一年間の対応履歴、管理者権限の一覧とその保管場所、契約内容の要約書を発注側に提出していた。さらに、新旧担当者と後継社長の三者でオンライン会議を実施し、資料の内容を確認しながら質疑応答の時間を設けていた。
後継社長は、この引き継ぎ会議の場で「今の保守契約に含まれている作業範囲」「今後のシステム更新の予定」「緊急時の連絡フロー」を改めて確認し、認識のずれがないことを確かめた。会議後、後継社長は自社側でも管理者権限の一覧を社内共有ドライブに保存し、経理担当者にも契約内容の要約を共有した。
この結果、担当者変更後の数か月間も業務に大きな支障は出ず、新担当者もスムーズに保守業務を開始できた。このケースが示すのは、引き継ぎの質は開発会社側の体制だけで決まるものではなく、発注側が「何を確認すべきか」を理解し、その場で積極的に質問し、確認した内容を自社側でも文書化しておくことで大きく改善するという点である。1年目に開発会社と初めて顔合わせする際に何を話すべきかは、1年目に開発会社と初めて顔合わせするとき、何を話すべきかにまとめている。
後継社長は後にこの経験を振り返り、開発会社側の引き継ぎ資料がしっかりしていたことに加えて、自分自身がその場で「わからないことをその場で聞く」という姿勢を持てたことが良い結果につながったと感じている。もし資料を受け取っただけで満足し、内容を深く確認しないまま会議を終えていたら、資料に記載されていない細かい運用上の癖や、過去に一度だけ発生した特殊な対応の経緯までは把握できなかっただろう。引き継ぎ会議という限られた時間のなかで、発注側がどれだけ主体的に質問できるかが、その後の運用の安定度を大きく左右するということを、このケースは物語っている。
さらに、この会社では新担当者が着任してから三か月後にも、改めて短い確認ミーティングを設定していた。最初の引き継ぎ会議で聞き漏らしたことや、実際に運用を始めてから気づいた疑問点を、時間を置いてから再度すり合わせる機会を作ったことで、認識のずれを早期に修正できたという。担当者変更への対応は一度の会議で完結させるのではなく、数か月にわたって段階的に確認を積み重ねていく発想が有効であることを示す好例である。
実務対応のステップとチェックリスト
担当者変更の連絡を受けたら、後継社長として次のステップを踏むことをおすすめする。それぞれの項目には、なぜそれを確認すべきかという理由も添えている。焦って全部を一度に確認しようとする必要はないが、少なくとも最初の一か月のうちに、以下の項目に一通り目を通しておくことが望ましい。
ステップ1 変更連絡を受けたらまず落ち着いて確認すべきこと
新担当者の役職と権限範囲を確認する 新しい担当者が、旧担当者と同等の意思決定権限を持っているのか、あるいは技術的な作業のみを担当し、契約や見積もりの判断は別の人物が行うのかを確認する。担当者によって権限範囲が異なると、今後の相談先を誤ってしまう可能性がある。特に、料金交渉や契約変更の話は、技術担当者ではなく営業担当や管理職でなければ判断できない場合が多く、最初にこの点を確認しておくことで、話を持っていく先を間違えずに済む。
旧担当者との引き継ぎがどの程度行われたかを確認する 「引き継ぎは完了しています」という一言だけで済まされず、具体的にどのような資料や情報が渡されたのかを確認する。口頭での申し送りのみなのか、文書化された資料があるのかは、今後の対応品質に直結する。可能であれば、引き継ぎ資料そのものを自社側にも共有してもらうよう依頼する。開発会社の社内向けの資料であっても、発注側に関わる部分だけを抜粋して見せてもらうことは、決して不自然な要求ではない。
旧担当者が退職済みか在籍中かを確認する 旧担当者がまだ開発会社に在籍していて、部署異動や担当替えによる変更であれば、必要に応じて旧担当者に直接確認できる余地が残っている。一方、旧担当者が退職済みの場合は、後から疑問点が出てきても本人に確認することができなくなるため、初期段階でより丁寧に情報を確認しておく必要性が高まる。
引き継ぎ内容の共有を依頼する 可能であれば、新旧担当者と自社側の三者でのミーティングを依頼する。書面のやり取りだけでは伝わらない過去の経緯やニュアンスを、その場で確認できる貴重な機会になる。この機会を逃すと、後から個別に確認するのに何度もやり取りが必要になる。オンラインでの短時間の打ち合わせでも十分に効果があるため、日程調整の負担を理由に見送らないようにしたい。
ステップ2 自社が保有している情報を整理する
契約書の現物を確認する 保守契約や開発契約の契約書を引き出し、契約期間、作業範囲、料金体系、解約条件を改めて読み直す。先代の時代に締結されたまま更新されていない契約書が、実態と大きくずれていることがよくある。契約書が見当たらない場合は、開発会社に控えを再発行してもらうよう依頼することも検討する。
管理者権限の所在を洗い出す サーバー、ドメイン、CMS、解析ツール、SNS連携アカウントなど、システムに関わる管理者権限がどこにあり、誰がログイン情報を保持しているかを一覧化する。開発会社に依存している項目があれば、自社側でも把握できるように情報の提供を求める。一覧化にあたっては、サービス名、契約者名義、ログインに使うメールアドレス、更新のタイミングを最低限の項目として記録しておくと、後から見返したときに実用的な資料になる。
支払いの流れを確認する 保守費用や利用料がどの口座から、どの周期で、どのような方法で支払われているかを経理担当者と一緒に確認する。担当者変更を機に、請求書の送付先や支払いフローが変わることもあるため、事前の確認が望ましい。特に、複数のサービスの費用がまとめて一つの請求書に含まれている場合、内訳を確認しておかないと、後から「何にいくら払っているのか」がわからなくなることがある。
過去のやり取りの履歴を確認する 旧担当者とのメールやチャットのやり取りが、退職や異動によって参照できなくなる可能性がある場合は、重要な部分だけでも早めに保存しておく。特に、仕様変更の経緯や、トラブル対応の記録は、後から見返す必要が出てくることが多いため、優先的に確保しておきたい。
ステップ3 新担当者との関係を構築する
過去の経緯を自社側からも共有する 新担当者に一方的に理解を求めるのではなく、自社側からも「なぜ今の仕様になっているのか」「過去にどのような要望を出してきたか」を積極的に共有する。双方が情報を持ち寄ることで、引き継ぎの精度が上がる。後継社長自身がすべてを把握していない場合は、先代や現場の担当者にも同席してもらい、複数の視点から経緯を伝えるとより正確な引き継ぎになる。
今後の連絡フローを確認する 緊急時の連絡先、対応可能な時間帯、通常の依頼と緊急対応の違いなど、実務上のルールを新担当者とすり合わせる。旧担当者との間で暗黙のルールとして成立していたものは、新担当者には伝わっていない前提で確認する。たとえば「土日でも急ぎの場合は電話してよい」というような取り決めがあった場合、それが新担当者にも継続されるのか、それとも正式な対応時間内に限定されるのかを明確にしておく。
軽微な対応の範囲を明確にする これまで無償や口頭のやり取りで対応してもらっていた軽微な修正作業がある場合、それが契約上どう扱われるのかを新担当者に確認する。曖昧なまま運用を続けると、後から現場との間でトラブルになりやすい。範囲が不明確なまま放置するのではなく、必要であれば契約内容を見直し、軽微な作業も含めた保守プランへの変更を検討する。
技術的な説明の粒度を確認する 新担当者がどの程度の技術的な説明を好むのか、逆にどこまで噛み砕いた説明を用意してくれるのかを、早い段階で見極めておく。専門用語を多用する担当者であれば、遠慮せずに「わかりやすく説明してほしい」と伝えることが、その後のコミュニケーションの質を高めることにつながる。
ステップ4 社内での情報共有体制を整える
窓口を一人に集中させない 後継社長自身が窓口になる場合でも、経理担当者や総務担当者など、少なくとも一人は同じ情報にアクセスできる状態にしておく。担当者が一人しかいない状態は、発注側自身が「属人化」のリスクを抱えていることになる。窓口の担当者が急に休んだり退職したりした場合の代替も、あらかじめ想定しておくとよい。
確認した内容を文書化して保存する 新担当者との会議ややり取りで確認した内容は、簡単なメモでもよいので文書化し、社内の共有できる場所に保存する。次に担当者が変わったときに、この記録が引き継ぎの基礎資料になる。特別なツールを使う必要はなく、社内で共有しているオンラインの文書やスプレッドシートに残しておくだけでも十分に機能する。
定期的な見直しの機会を設ける 担当者変更のたびに情報を整理するのではなく、半年や一年に一度、契約内容や管理者権限の状況を見直す機会を社内で設けておくと、担当者変更が起きたときの負担が大幅に軽くなる。日々の業務に追われるなかでこうした見直しを忘れがちだが、システムに関する定例確認を年に一度のルーティンとして組み込んでおくことが望ましい。
次回の担当者変更に備えた依頼をしておく 今回の引き継ぎで感じた不便な点があれば、開発会社に対して「次回担当者が変わる際は、事前に資料を用意してほしい」といった要望を伝えておく。これは開発会社との今後の関係を良好に保つための、建設的な提案として受け止められることが多い。要望を伝える際は、批判的な言い方ではなく、「今後もお付き合いを続けたいので、こういう形にしてもらえると助かる」という前向きな伝え方を心がけると、関係を損なわずに改善を促すことができる。
よくある失敗パターン
失敗パターン1 新担当者に遠慮して質問を控えてしまう
後継社長は、先代の時代からの付き合いがある開発会社に対して、どうしても遠慮が生じやすい。新しい担当者が着任した際も「今さら基本的なことを聞くのは失礼ではないか」という心理から、契約内容や管理権限について踏み込んだ質問を控えてしまうことがある。しかし、担当者変更というタイミングは、むしろ疑問点を整理して確認する好機である。遠慮によって確認を後回しにすると、数か月後にトラブルが起きたときに、より大きな手間とコストをかけて確認せざるを得なくなる。担当者が変わった直後こそ、質問しても不自然に思われにくい時期であることを理解しておきたい。
この遠慮は、後継社長がまだ経営者としての自信を確立できていない時期に特に強く出る傾向がある。先代であれば当然のように聞けたであろう質問も、代替わり直後の後継社長にとっては「経営者として頼りないと思われるのではないか」という不安がつきまとう。しかし、開発会社の担当者からすれば、発注者が自社のシステムについて正確に把握しようとする姿勢は、むしろ信頼できる相手だという印象につながる。質問を控えることが謙虚さの表れだと考えるのは誤解であり、必要な確認を行うことは経営者としての当然の責務であると捉え直すことが大切である。
失敗パターン2 引き継ぎ資料を受け取っただけで安心してしまう
開発会社から引き継ぎ資料や説明を受けると、それだけで「もう大丈夫だ」と安心してしまう後継社長は少なくない。しかし、資料を受け取ることと、その内容を自社側で理解し、実際に使える状態にしておくことは別の話である。資料をもらった時点では理解したつもりでも、数か月後に実際に必要になった際に、資料の場所すら思い出せないということがよく起きる。受け取った資料は必ず社内で共有できる場所に保存し、内容を要約して経理や総務の担当者にも伝えておく一手間が欠かせない。
この失敗パターンの根底には、「資料が存在すること」と「その資料が実際に使われること」を混同してしまう心理がある。多忙な経営者ほど、送られてきた資料をひとまずメールボックスやパソコンのフォルダに保存したまま、内容を精査せずに次の業務に移ってしまいがちである。しかし、資料が使われるためには、それがどこにあるかを他の関係者も把握していて、必要なときにすぐに取り出せる状態になっていなければならない。受け取った直後の数十分を使って内容に目を通し、要点を自分の言葉でメモに残しておくという小さな習慣が、後々の大きな手間を防ぐことにつながる。
失敗パターン3 契約内容の見直しを先送りにしてしまう
担当者変更の際に契約と実態のずれに気づいても、「今の担当者との関係がまだ落ち着いていないから」「忙しくて時間が取れないから」という理由で、契約内容の見直しを先送りにしてしまうことがある。しかし、契約と実態のずれは時間が経つほど双方の認識が固定化し、後から修正しようとすると「今まで無料だったのに」「今まで対応してもらえていたのに」という感情的な対立を生みやすくなる。ずれに気づいた段階、つまり担当者変更のタイミングこそが、双方にとって最も納得感のある形で契約内容を見直せる機会であることを理解しておく必要がある。
先送りが起きやすい背景には、契約内容の見直しという作業が「今すぐ困っているわけではない」ため優先順位が下がりやすいという事情がある。日々の業務のなかでは、目の前の売上や現場の対応に追われ、契約書の見直しのような地味な作業は後回しにされがちである。しかし、契約と実態のずれが放置されたまま次の担当者変更が起きると、さらに認識のずれが積み重なり、問題が複雑化していく。担当者変更という節目は、この見直しを行う上で最も自然なきっかけであり、先送りにせずその場で着手することが、結果的に最も労力の少ない対応方法になる。
よくある質問
Q1 新しい担当者が信頼できるかどうか、何を基準に判断すればよいですか
技術的な知識の深さだけでなく、過去の経緯を丁寧に確認しようとする姿勢や、わからないことを「わからない」と正直に伝えてくれるかどうかを見るとよい。最初の打ち合わせで、こちらの業務や過去の要望について具体的な質問をしてくる担当者は、引き継ぎに前向きに取り組んでいる可能性が高い。逆に、こちらからの質問に対して曖昧な返答が続く場合は、開発会社側の引き継ぎ体制そのものに問題がある可能性を考えたほうがよい。
Q2 引き継ぎが不十分だと感じた場合、どう対応すればよいですか
まずは開発会社の窓口責任者や上長に、引き継ぎ資料の追加提供や、旧担当者への確認の場を設けてもらえるよう依頼する。旧担当者がすでに退職している場合は、社内に残っている過去のメールやドキュメントを自社側で洗い出し、新担当者と共有することで補完できる部分もある。どうしても解決できない重要な情報の欠落がある場合は、契約自体の見直しや、他の開発会社への相談も選択肢として検討する価値がある。
Q3 管理者権限のパスワードは、どのように管理するのが望ましいですか
理想的には、開発会社の担当者個人ではなく、自社が契約主体として各サービスのアカウントを保有し、開発会社にはその中の必要な権限だけを付与する形が望ましい。すでに開発会社側の名義でアカウントが作られている場合は、担当者変更のタイミングを機に、自社名義への変更や、パスワード管理ツールを使った安全な共有方法への切り替えを相談してみるとよい。
Q4 担当者が変わるたびにこうした確認を毎回行う必要がありますか
一度きちんと確認し、社内に文書として残しておけば、次回以降の担当者変更時にはその文書を土台にして差分だけを確認すればよくなる。最初の引き継ぎで手間をかけて情報を整理しておくことが、その後の担当者変更を軽い作業に変えるための投資になる。逆に、毎回その場対応で済ませてしまうと、担当者が変わるたびに同じ手間と同じリスクを繰り返すことになる。
Q5 先代からの引き継ぎがそもそも不十分で、今の契約内容すら把握できていない場合はどうすればよいですか
このような場合は、担当者変更を良い機会として捉え、開発会社に対して現在の契約内容や過去の対応履歴を一から棚卸ししてもらうよう正式に依頼するとよい。多くの開発会社は、発注側から明確に依頼があれば、契約書の再確認や、これまでの作業履歴の整理に協力してくれる。先代からの引き継ぎが不十分だったことを恥じる必要はなく、後継社長として現状を正確に把握しようとする姿勢そのものが、今後の安定した関係構築につながる第一歩になる。
まとめ
開発会社の担当者変更は、多くの後継社長にとって「連絡先が変わっただけ」の些事に見えがちだが、実際には自社のシステム運用の土台がどれだけ属人化していたかを可視化する重要な機会である。先代の時代からの付き合いのなかで積み上げられてきた暗黙のルールや善意の対応は、担当者という個人がいなくなった瞬間に、契約書という文書だけが頼りになる。
大切なのは、担当者変更の連絡を受けたときに、遠慮せずに引き継ぎの実態を確認し、契約内容と実際の運用のずれを洗い出し、自社側でも情報を文書化して保存しておくことである。これは一度きりの作業ではなく、次に担当者が変わったときのための備えにもなる。開発会社との関係は、特定の担当者個人への信頼だけに依存させず、会社対会社の関係として、双方が確認できる形の情報を積み重ねていくことで、より安定したものになっていく。
先代の時代に築かれた「あの人に任せておけば大丈夫」という関係は、決して間違っていたわけではない。むしろ、長年にわたって円滑に事業を支えてきた実績そのものである。しかし、後継社長がその関係を次の世代に引き継いでいくためには、個人の信頼関係を会社としての仕組みに翻訳し直す作業が必要になる。担当者変更という出来事は、その翻訳作業を後回しにできない形で迫ってくる、いわば最初の試練のようなものだと捉えることもできる。
この試練を丁寧にこなせた後継社長は、次に同じような変更が起きたときに、以前ほどの負担を感じずに対応できるようになっている。契約書の場所を把握している、管理者権限の一覧が社内に残っている、新担当者への確認事項がテンプレートとして手元にある。そうした小さな備えの積み重ねが、代替わりのたびに繰り返されてきた「毎回ゼロから確認し直す」という非効率を解消し、事業の継続性そのものを支える基盤になっていく。後継社長にとって、この積み重ねは日々の業務に埋もれがちな作業だが、いざシステムに問題が起きたときの対応力を大きく左右する、経営基盤の一部だと捉えておきたい。
