導入 ―― 引き継いだシステムは「動いている」だけでは終わらない
先代から社長の椅子を引き継いで半年が経った、ある建材商社の後継社長の話から始めたい。彼が引き継いだのは会社の経営権だけではなかった。受発注管理システム、社内で使っている在庫管理ソフト、そして先代が10年以上前に発注した開発会社との「なんとなくの付き合い」も、すべてセットで引き継いだのである。
引き継ぎ当初、彼は経営の勉強と社内の人間関係の把握に忙殺され、システムのことは「今まで通り動いているなら触らなくていい」と考えていた。ところが3ヶ月目に、在庫管理システムがエラーを出して受注処理が止まった。慌てて先代に電話をかけると「開発会社に連絡すればいい」と言われたが、その開発会社の担当者は退職しており、後任の担当者は引き継ぎ資料をほとんど持っていなかった。結局、原因調査だけで1週間、復旧までにさらに2週間かかり、その間は手書きの受注管理台帳で業務を回すことになった。
この後継社長が痛感したのは、「システムが動いていること」と「システムを運用する体制があること」は全く別物だという事実だった。先代の時代は、開発会社の担当者と先代自身が長年の付き合いの中で、暗黙のうちに役割分担ができていた。誰が何を判断し、誰が何を実行するのかという線引きは、明文化されていなくても、二人の頭の中には存在していた。しかし後継社長が代替わりした瞬間、その暗黙の了解は失われる。社内の誰も開発会社との窓口役を明確に担っておらず、開発会社側も「誰の指示を受けて動けばいいのか」が分からない状態に陥っていたのである。
事業承継において、経営理念や取引先との関係、社内の人事といった「見える資産」の引き継ぎには誰もが注意を払う。しかし業務システムの運用体制という「見えない資産」は、承継計画のどこにも書かれていないことが多い。運用フェーズにおける社内と開発会社の役割分担が曖昧なまま放置されると、些細な不具合が事業停止レベルの危機に発展しうる。本稿では、なぜこの役割分担が承継のタイミングで崩れやすいのか、その構造的な要因を解き明かし、後継社長が今すぐ着手できる実務的な対応策を、具体的なケースとチェックリストを交えて解説する。
この建材商社の後継社長は、その後の振り返りの中で、もう一つ重要なことに気づいたという。それは、先代が現役だった頃、開発会社との関係はいわば「経営者同士の付き合い」として機能していたという事実である。先代は開発会社の社長や担当者と定期的に会食をし、業界の動向や自社の課題を雑談の中で共有していた。その雑談の中から、開発会社側が「そろそろこの機能が必要になりそうですね」と先回りして提案してくることもあった。つまり先代の時代の開発会社は、単なる外注先ではなく、経営の相談相手としての役割も担っていたのである。後継社長がこの関係性を引き継げなかったのは、単に紹介を受けなかったからではなく、その関係性自体が「先代という個人」と「開発会社という個人」の間で育まれた、極めて人間的な資本だったからだ。組織のルールや契約書には決して落とし込まれない、この人間的な資本こそが、承継の最大の盲点になりやすい。
後継社長業を引き継ぐということは、突然、経営のあらゆる領域において「初心者」としての立場に立たされることを意味する。財務や人事、営業といった領域には、多くの経営者仲間や専門家からの助言が得やすい。ところが、業務システムの運用体制という領域は、相談できる相手がほとんどいない。同業の経営者仲間に聞いても「うちは開発会社に任せているから分からない」という答えが返ってくることが多く、専門家に相談しようとしても、税理士や弁護士のように定型的な相談窓口が存在しない。結果として、後継社長は自分の会社のシステム運用体制について、誰にも相談できないまま、独力で手探りの対応をすることになる。本稿がその手探りの一助になれば幸いである。
なぜ運用フェーズの役割分担が承継時に崩れるのか ―― 構造的な要因
運用フェーズの体制が承継を境に崩れる背景には、単純な「引き継ぎ不足」では説明できない、いくつかの構造的な要因が重なっている。ここでは4つの観点から整理する。
要因1:先代と開発会社の関係が「人」に紐づいていた
多くの中小企業では、システムの発注や運用の意思決定は、経営者個人と開発会社の担当者との信頼関係の上に成り立っている。先代社長は開発会社の担当者と何年も、場合によっては何十年も付き合いを続けてきた。その関係の中では、契約書に書かれていないルールが自然に育つ。「軽微な修正なら電話一本で対応してもらえる」「請求は月末にまとめて」「トラブルがあれば先代の携帯に直接連絡が来る」といった運用は、契約という制度ではなく、個人と個人の信頼という土台の上に築かれている。
この状態は、当事者である先代と担当者にとっては何の問題もない。むしろ意思決定が速く、柔軟性が高いという利点すらある。運用フェーズの契約が準委任契約契約の形を取っているケースも多く、この場合は成果物の完成そのものより日々の対応の質が重視されるため、なおさら個人間の信頼が運用の実態を左右しやすい。しかし、この関係性は組織の資産ではなく、個人の資産である。先代が退任し、担当者が異動や退職をすれば、関係性そのものが消滅する。後継社長は、ゼロから新しい関係を構築しなければならないにもかかわらず、先代からは「開発会社とは上手くやっているから大丈夫」という抽象的な安心情報だけが引き継がれ、具体的な役割分担のルールは何も引き継がれない、という事態が頻発する。
この構造は、経営学の世界で古くから指摘されてきた「関係的契約」の問題と重なる部分が大きい。関係的契約とは、契約書という明文化された約束事ではなく、当事者間の継続的な関係性そのものが、暗黙の規範や期待値を形成し、それが実質的な契約として機能する状態を指す。中小企業と開発会社の関係の多くは、実はこの関係的契約によって支えられている。取引開始当初は明確な契約書があったとしても、数年、数十年という時間の中で、当初の契約内容よりもはるかに細かい運用ルールが、口頭のやり取りと実績の積み重ねによって形成されていく。この暗黙のルールは、両者にとって効率的である一方、担い手である個人が交代した瞬間に、引き継ぎの手段を持たないという致命的な脆弱性を抱えている。先代個人の頭の中にあった暗黙知は、書面化されていない限り、退任と同時に会社から失われてしまうのである。
要因2:社内に「システムの窓口」という役職が存在しない
中小企業、特に非IT業種の企業では、情報システム部門という専門組織を持たないことが多い。先代の時代、システムに関する判断は先代自身が一人で担っていたケースが典型的である。先代は経営者でありながら、事実上の情報システム責任者でもあった。この体制は、先代が現役である限りは機能する。しかし後継社長に代替わりした瞬間、経営全体の意思決定に加えてシステムの判断まで一人で担うのは現実的に不可能になる。
ここで問題になるのが、社内に「システムに関する一次窓口」という役割そのものが制度として存在していないことである。先代は個人の能力と経験でその役割を埋めていたが、それは組織構造として設計されたものではなかった。後継社長が同じように一人で全てを判断しようとすれば、経営の他の業務が圧迫されるし、逆に誰かに委任しようとしても、委任すべき役割の輪郭が定義されていないため、誰に何を任せればいいのか分からない。結果として、「なんとなく総務の人が窓口をやっている」「たまたまパソコンに詳しい社員が対応している」という、属人的で不安定な体制が生まれる。
さらに厄介なのは、この「なんとなくの窓口」が、本人の自覚なしに窓口としての機能を担ってしまっているケースが多いという点である。例えば、パソコンの操作に慣れているという理由だけで、経理担当者が日常的にシステムのちょっとした質問に答えるようになり、いつの間にか開発会社からの連絡も彼女のところに集まるようになっていた、という状況は珍しくない。本人は経理の仕事の延長線上でシステムの相談に応じているだけだと思っており、自分が会社にとって重要な役割を担っているという自覚がない。この自覚のなさは、本人が突然退職や異動をした際に、会社側が窓口機能の喪失に気づかないまま時間が過ぎてしまうという二次的なリスクを生む。役割が制度として定義されていない限り、その役割の重要性を経営側が正しく認識することもできないのである。
要因3:開発会社側も「誰の指示を受けるべきか」を把握していない
役割分担の崩壊は社内側だけの問題ではない。開発会社の側にも同じ構造的な問題がある。開発会社の担当者にとって、先代社長は長年のクライアントであり、意思決定者として明確に認識されていた。しかし承継が起きた後、開発会社は「新しい社長が本当の決定権者なのか」「実務の窓口は誰なのか」「これまでの取引条件はそのまま継続してよいのか」といった情報を、後継社長側から明示的に伝えられない限り把握できない。
これは開発会社の怠慢ではなく、情報の非対称性の問題である。承継のタイミングで社内の体制が変わったことを、開発会社は自動的には知り得ない。後継社長側が「体制が変わったので、今後はこのように役割分担したい」という意思を明確に示さない限り、開発会社は従来通り、先代個人や、先代が指定していた古参社員を窓口として扱い続ける。この状態が続くと、後継社長が知らないところで開発の優先順位が決まったり、逆に後継社長が出した指示が開発会社に届かなかったりする、という情報の断絶が生じる。
開発会社側の立場に立って考えると、この問題はより理解しやすくなる。開発会社にとって、クライアント企業の内部事情は基本的に外部からは見えない。特に中小企業の場合、組織図が整備されていなかったり、役職と実際の権限が一致していなかったりすることも多く、開発会社は「その会社の窓口は誰か」という情報を、過去のやり取りの実績から経験的に判断するしかない。過去に何度もやり取りをした相手が、今後も窓口であり続けるだろうという推測は、開発会社側からすれば合理的な判断である。この推測を修正するのは、クライアント企業側から明確な情報発信があった場合に限られる。後継社長が「今後は自分が最終決定者であり、日常の連絡はこの担当者を通してほしい」という情報を伝えない限り、開発会社は永遠に古い体制を前提に動き続けることになる。
要因4:「運用フェーズ」という概念そのものが軽視されやすい
システム開発には、要件定義・設計・開発・テストという「構築フェーズ」と、リリース後に日々発生する不具合対応・軽微な改修・問い合わせ対応という「運用フェーズ」がある。多くの経営者、特にIT業界出身でない後継社長は、システムは一度作れば完成するものだと誤解しがちである。しかし実際には、システムは稼働を始めた瞬間から、法改正への対応、業務フローの変化への追随、OSやブラウザのアップデートへの追従など、継続的な調整を必要とする「生き物」である。
この運用フェーズを軽視する経営観が先代から後継社長にそのまま引き継がれると、「運用の体制を整える」という発想自体が生まれない。先代の時代、運用フェーズの調整はほぼ全て開発会社が「サービスの一環」として無償か低コストで巻き取ってくれていたかもしれない。しかしそれは開発会社の善意や、長年の関係性への配慮によるものであり、契約上保証された役務ではないことが多い。後継社長がその実態を理解せず、「今まで通りにやってくれるはず」という前提で運用フェーズに入ると、開発会社側の対応姿勢が変わった際に、突然サポートが手薄になったと感じる、という齟齬が生まれる。
運用フェーズが軽視される背景には、経営者側の時間軸の問題もある。構築フェーズは、要件定義から納品までのスケジュールが明確に区切られており、経営者としても「いつまでに何をするか」という進行管理の対象として意識しやすい。一方、運用フェーズには明確な終わりがない。システムが稼働している限り、日々小さな調整が発生し続けるが、その一つひとつは目立たず、経営会議の議題として取り上げられることも少ない。この「終わりのない、目立たない業務」という性質が、運用フェーズを経営の優先順位から外れやすくしている。後継社長が就任直後の忙しさの中で、運用フェーズの体制整備を後回しにしてしまうのは、ある意味で自然な判断ですらある。しかし、目立たないからこそ、体制の不備は静かに蓄積し、ある日突然、大きな問題として表面化するという性質を持つことを理解しておく必要がある。
これら4つの要因は独立して存在するのではなく、相互に絡み合っている。人に紐づいた関係性(要因1)は、社内に制度としての窓口がないこと(要因2)によって代替手段を持たず、開発会社側の情報不足(要因3)によって修復されにくくなり、そもそも運用フェーズという概念自体が軽視されていること(要因4)によって、問題が表面化するまで誰も気づかない。この4層構造を理解することが、後継社長にとっての最初の一歩になる。
ケーススタディ1:窓口不在で軽微な不具合が業務停止に発展した製造業の例
従業員45名の金属加工業を営むA社は、先代から2代目社長への承継が完了してから8ヶ月後に、生産管理システムの不具合に直面した。不具合自体は、ある特定の条件で在庫数量の表示がずれるという、決して深刻な内容ではなかった。しかし発覚から復旧までに実質3週間を要し、その間、複数の受注案件で在庫の見込み違いによる納期遅延が発生した。
問題の根本は、不具合発生後の「最初の連絡」が誰にも届かなかったことにある。生産管理システムを日常的に操作していたのは製造現場のベテラン社員だったが、彼は開発会社への連絡窓口ではなかった。先代の時代は、先代自身が定期的に現場を巡回し、システムの使い勝手について現場から直接話を聞き、必要であれば先代が開発会社に電話をしていた。この巡回と口頭確認という非公式なルートが、事実上の不具合検知の仕組みとして機能していたのである。
後継社長は経営会議や営業活動に時間を取られ、先代のような現場巡回を行っていなかった。現場のベテラン社員は不具合に気づいていたが、「誰に報告すればいいのか分からない」「大した問題ではないだろう」と判断し、しばらく手作業で数量を補正しながら業務を続けていた。この自己判断による誤魔化しが2週間続き、在庫のズレが累積して、最終的に複数の受注案件で実際の在庫と表示上の在庫が大きく食い違う事態に至った。ようやく総務担当者経由で後継社長の耳に入った時には、問題はすでに深刻化していた。
後継社長が開発会社に連絡したところ、開発会社側は「もっと早く連絡してくれれば軽微な設定変更で対応できた内容だった」と回答した。つまり不具合自体の技術的な重大性は低く、対応も難しくなかった。問題は技術ではなく、報告のルートが存在しなかったという体制の不備にあった。この一件を受けて、A社の後継社長は生産管理システムの「一次報告窓口」を製造課長に正式に任命し、不具合や違和感を感じた際は必ず24時間以内に課長に報告し、課長が開発会社に連絡するというルールを社内規程として明文化した。あわせて、開発会社側にも「今後の窓口は製造課長である」ことを正式な書面で通知し、開発会社側の顧客管理情報も更新してもらった。
この事例が示すのは、不具合そのものの技術的難易度と、それが事業に与える影響の大きさは必ずしも一致しないという点である。むしろ「誰が最初に気づき、誰に伝え、誰が判断するか」という報告の経路が明確でないことが、軽微な問題を深刻な問題へと拡大させる最大の要因になる。承継後の体制整備において、システムの技術的な引き継ぎよりも先に、「誰が窓口か」という一点を明確にすることの重要性を、この事例は端的に物語っている。
さらに興味深いのは、この事例における後継社長の振り返りである。彼は事後の反省会で「自分が先代のように現場を巡回する時間を確保できなかったこと自体は仕方がなかった。しかし、巡回に代わる別の情報収集の手段を用意していなかったことが本当の失敗だった」と語っている。先代の巡回という手法そのものを模倣する必要はない。重要なのは、現場で発生している小さな違和感を、経営側が定期的に吸い上げる仕組みを何らかの形で持っておくことである。A社ではこの反省を踏まえ、月次の朝礼の中に「システムで気になることがあれば製造課長まで」という一言を必ず入れるようにし、報告のハードルを下げる工夫を継続している。体制を作ることと、その体制が実際に使われる状態を維持することは別の努力を要するという点も、この事例からの重要な学びである。
ケーススタディ2:古参社員がボトルネック化した卸売業の例
従業員28名の食品卸売業B社では、先代の時代からシステム運用の実務を一手に担っていた古参社員がいた。彼は入社25年のベテランで、受発注システムの導入時から関わり、開発会社との打ち合わせにも常に同席していた。先代は彼を絶大に信頼し、システムに関する判断のほとんどを彼に一任していた。後継社長が就任した際も、先代から「システムのことは彼に聞けば全部分かる」と紹介され、後継社長はその言葉を信じてシステムに関する判断を彼に委ねた。
しかし1年ほど経ったころ、後継社長は業務の停滞を感じるようになった。新しい取引先との連携のために発注システムに機能追加をしたいと考えても、古参社員は「今のままで問題ない」「変更するとまた覚えることが増えて現場が混乱する」と難色を示し、なかなか話が前に進まなかった。後継社長が開発会社に直接問い合わせても、開発会社側は「その件は既に窓口である彼と話を進めている」と返され、後継社長の意向が反映されているのかどうかも分からない状態が続いた。
調べてみると、古参社員は開発会社との関係において、事実上の「拒否権」を持つ立場になっていた。彼が「不要」と判断した提案は開発会社に伝わらず、彼が「必要」と判断した改修だけが実行される。この状態は、彼個人の善意や能力の問題ではない。先代の時代に「システムの実務は彼に一任する」という体制を作った結果、彼一人に判断権限と情報が集中し、後継社長の経営判断がシステムの現場に届かなくなっていたのである。いわば、運用フェーズの意思決定が完全に属人化し、経営のガバナンスが及ばないブラックボックスが社内に形成されていた。
後継社長はこの状況を問題視し、古参社員本人と率直に話し合いの場を持った。彼を排除するのではなく、彼の経験と知識を正式な役割として位置づけ直すことを提案した。具体的には、彼を「システム運用リーダー」として明文化し、日常の軽微な対応は引き続き彼が担当する一方、機能追加や仕様変更といった経営判断に関わる事項は、必ず後継社長の承認を経てから開発会社に発注するという承認フローを新設した。同時に、開発会社に対しても「今後、経営判断を伴う依頼は社長の承認印(または承認メール)がある場合のみ着手してほしい」と明確に依頼し、開発会社側の受注プロセスにもチェックポイントを設けてもらった。
この事例の教訓は、属人化した運用体制を否定するのではなく、その人の経験を資産として活かしながら、経営の意思決定と現場の実務を分離する仕組みを作ることが有効だという点である。古参社員を排除して新しい体制をゼロから作ろうとすれば、貴重な業務知識が失われるだけでなく、社内の反発を招く。重要なのは、誰が「実行」を担い、誰が「承認」を担うのかという権限のレイヤーを明確に分けることである。後継社長はこの整理によって、古参社員のモチベーションを損なうことなく、経営としてのコントロールを取り戻すことができた。
この事例には、もう一つ見逃せない側面がある。古参社員自身も、実は内心では負担を感じていたという点である。話し合いの中で彼は「本当は自分一人で全部の判断をするのは荷が重いと思っていた。でも先代から任されている以上、自分が全部やらなければいけないと思い込んでいた」と語った。属人化した体制は、任されている側にとっても決して心地よいものではないことが多い。判断の責任を一人で背負い続けることは、本人にとっても心理的な負荷になる。後継社長が承認フローを新設したことで、古参社員は「自分の判断が正しいかどうかを、社長が確認してくれる」という安心感を得られるようになり、結果として本人の働きやすさも向上したという。役割分担の明確化は、経営のガバナンスを取り戻すためだけの取り組みではなく、属人化に苦しんでいた社員自身を助ける効果も持つことを、この事例は示している。
ケーススタディ3:開発会社との契約範囲が不明確で追加費用が発生し続けたサービス業の例
従業員15名のクリーニング業C社では、先代が10年前に予約管理システムを開発会社に発注し、以後大きな契約更新はせずに運用を続けていた。後継社長が承継後にあらためて契約書を確認したところ、契約書自体が非常に簡素な内容で、開発の範囲だけが記載されており、運用フェーズにおける対応範囲やその費用については、ほとんど何も定められていないことが分かった。
先代の時代は、軽微な修正依頼があるたびに開発会社の担当者に電話をし、その都度、口頭で見積もりを聞いて対応してもらうという運用をしていた。この方式は関係が長く安定していれば大きな問題を生まないが、後継社長に代替わりした後、依頼のたびに見積もり額が変動し、以前より高い金額を提示されることが増えた。後継社長が疑問を持って開発会社に問い合わせると、「以前は先代社長との関係で割安に対応していた部分があった」という説明を受けた。
この状況は、開発会社が不誠実だったという単純な話ではない。むしろ、これまでの「割安な対応」自体が、契約上の根拠のない、先代個人への配慮による特別対応だったのであり、後継社長との関係がまだ構築されていない段階では、開発会社側も標準的な料率に戻すのが自然な判断だったとも言える。問題は、後継社長がその実態を知らずに「今までと同じ条件で対応してもらえる」と誤解していたことにある。
後継社長はこの一件を機に、開発会社との間で運用フェーズの対応範囲と費用の目安を、あらためて書面で確認し直すことにした。具体的には、月々の軽微な問い合わせ対応は基本料金の範囲内で行う、機能追加や大幅な改修は個別見積もりとする、緊急対応が必要な障害時の対応時間と費用の目安を事前に共有する、といった内容を、簡易な確認書として取り交わした。全面的な契約書の刷新ではなく、既存の関係性を前提にした「運用ルールの再確認」という形を取ったことで、開発会社側も協力的に対応してくれたという。
この事例が示すのは、承継のタイミングで運用フェーズの契約内容や費用感を一度言語化し直すことの重要性である。先代の時代の「口約束」や「関係性による特別対応」は、後継社長にそのまま引き継がれるわけではない。むしろ承継を機に、対応範囲と費用感を明文化し、双方が納得できる形に更新することが、長期的な関係の安定につながる。
C社の後継社長がもう一つ気づいたことがある。契約範囲が不明確だったのは予約管理システムだけではなく、その周辺で連携している顧客管理の仕組みや、店舗のPOSレジとのデータ連携についても、どこまでが開発会社の対応範囲で、どこからが別のベンダーの対応範囲なのかが曖昧なままだったという事実である。中小企業の業務システムは、単一の開発会社が全てを担っているとは限らず、複数のベンダーやツールが組み合わさって運用されていることが多い。承継後の体制整備では、目に見えている主要なシステムだけでなく、それに付随する周辺のツールやサービスについても、どのベンダーがどこまでの範囲を担当しているのかを、あわせて確認しておくことが望ましい。C社ではこの機会に、関連するすべてのシステムとベンダーの対応関係を一枚の表にまとめ、今後何か問題が起きた際に、まずどこに連絡すればよいかが一目で分かるようにした。この表は結果的に、後継社長だけでなく、店舗スタッフにとっても心理的な安心材料になったという。
実務対応:承継後にやるべき体制整備のステップとチェックリスト
ここまでの構造的な要因とケーススタディを踏まえ、後継社長が実際に着手すべき体制整備のステップを、段階を分けて具体的に解説する。
ステップ1:現状の運用体制を「見える化」する
最初にやるべきことは、現状どのような体制でシステムが運用されているのかを、紙やドキュメントの上に書き出すことである。先代の頭の中にしかなかった暗黙のルールを、後継社長自身が言葉にして可視化する作業だと考えてほしい。
- 現在、社内で誰がシステムの操作や問い合わせ対応の実務を担っているかを、部署・氏名単位で書き出す。属人化している場合は、その人の名前を正直に書く。
- 開発会社側の窓口担当者の氏名と連絡先を確認し、先代との個人的な関係に依存していないかを見極める。担当者が退職・異動した場合の連絡先の代替手段も確認する。
- 過去1年程度の間に発生した不具合対応・改修依頼の履歴を、可能な範囲でリストアップする。誰が発見し、誰が報告し、誰が対応を判断したのかという流れを追う。
- 契約書や見積書が現在も手元にあるかを確認する。見つからない場合は、開発会社に控えの再送を依頼する。
この見える化の作業は、後継社長一人で完結させる必要はない。古参社員や現場のスタッフに聞き取りを行い、実際の運用の実態を掘り出すことが重要である。先代に直接尋ねられる場合は、先代自身に「これまでどうやってシステムのことを判断していたか」を聞くことも有効な手段になる。
この作業を進める際のコツは、最初から完璧な資料を作ろうとしないことである。多くの後継社長は、体制図や業務フロー図といった形式的な文書を最初から整えようとして、作業が滞ってしまう。実際には、簡単な表やメモ書きの形で構わない。「誰が」「何を」「どこまでの範囲で」「開発会社の誰と」やり取りしているのかという4つの要素を、思いつく限り箇条書きにしていくだけでも、現状把握としては十分な出発点になる。むしろ重要なのは、この見える化の過程で、これまで気づかなかった属人化や情報の断絶を発見することそのものにある。書き出してみると、「あの業務は誰が担当しているのか、実は誰も把握していなかった」という空白地帯が見つかることも少なくない。その空白地帯を発見できただけでも、この作業は十分な価値を持つ。
ステップ2:社内の「一次窓口」を正式に任命する
見える化の結果、属人的に実務を担っていた人物が明らかになったら、その人物を正式な役割として任命する。ポイントは、これまで「なんとなく」担っていた役割に、明確な名前と権限、そして責任の範囲を与えることである。
- 「システム運用担当」あるいは「情報システム窓口」といった役職名を定め、社内の誰が見ても分かる形で通知する。専任である必要はなく、既存の業務と兼務でよい。
- 窓口担当者が対応できる範囲(軽微な操作方法の質問、日常的な不具合の一次受付)と、社長の承認が必要な範囲(機能追加、大幅な改修、契約や費用に関わる事項)を切り分ける。
- 窓口担当者が急な休職や退職をした場合の代替要員を、最低でも1名は決めておく。属人化のリスクを一人に集中させないための保険である。
- 任命したことを社内全体に周知し、「システムのことはまず窓口担当者に相談する」というルールを浸透させる。
窓口担当者を選ぶ際に注意したいのは、役職の高さや専門性の有無だけで人選を決めないことである。むしろ重要なのは、社内の様々な部署とのコミュニケーションが取りやすい立場にいることと、報告を受けた際に適切なタイミングで後継社長に伝える誠実さを持っていることである。日頃から現場との接点が多い総務担当者や、複数の部署をまたいで業務をしている中間管理職が適任になりやすい。また、任命した窓口担当者には、判断に迷った際に「分からないことは分からないと言ってよい」という心理的な安全性を与えることも欠かせない。窓口担当者が、分からないことを自己判断で誤魔化してしまうと、ケーススタディ1のような事態を再び招くことになる。
ステップ3:開発会社に体制変更を正式に伝える
社内の体制を整えたら、次は開発会社側にその変更を明確に伝える。承継のタイミングで最も見落とされがちなのが、この開発会社への通知である。
- 後継社長が正式な決定権者であることを、開発会社の担当者だけでなく、可能であれば開発会社の管理職や窓口の上位者にも伝える。
- 社内の一次窓口担当者の氏名と連絡先を開発会社に共有し、今後の日常的な連絡はこの窓口を経由することを依頼する。
- 過去の「特別対応」や「口約束」がある場合は、それが今後も継続されるものなのか、それとも標準的な対応に戻るのかを、率直に確認する。曖昧なまま放置すると、後々の費用トラブルの火種になる。
- 開発会社の担当者自身が異動・退職する可能性についても尋ね、その場合の引き継ぎ体制がどうなっているかを確認しておく。担当者交代が実際に起きた際に何を確認すべきかは、開発会社の担当者交代、後継社長が引き継ぎで確認すべきことで詳しく取り上げている。
この通知を行う際、後継社長が緊張しすぎる必要はない。多くの開発会社は、クライアント企業の代替わりを何度も経験しており、体制変更の連絡自体は珍しいことではない。むしろ、後継社長側から積極的に体制変更を伝えてくれることは、開発会社にとってもありがたい情報である。伝えるべき内容を事前に整理し、簡潔な連絡(電話でもメールでも構わない)で済ませても構わない。重要なのは、伝える内容の詳しさよりも、伝えるという行為自体を怠らないことである。逆に、この通知を後回しにしていると、開発会社側は「体制はまだ変わっていない」と判断し続けるため、時間が経てば経つほど、後から訂正する際の説明が煩雑になってしまう。承継が完了したら、できるだけ早い時期に、簡潔でもよいので一報を入れることを心がけたい。
ステップ4:運用フェーズの対応範囲と費用感を書面で確認する
契約書が古い、あるいは簡素すぎる場合は、全面的な再契約ではなく、運用フェーズに関する確認事項を簡易な文書として取り交わすことが実務的である。
- 日常的な問い合わせ対応や軽微な修正が、既存の契約料金の範囲内で対応してもらえるものなのか、都度費用が発生するものなのかを明確にする。
- 障害発生時に、どの程度の時間で初動対応してもらえるのかという目安を確認する。数値的な保証を求めるのではなく、あくまで目安として双方の認識を揃えることが目的である。
- 機能追加や大幅な改修を依頼する際の見積もりの出し方や、発注から着手までの標準的な流れを確認する。小さな改修を都度発注する際のコツは追加開発の頼み方。小さな改修を安く早く進めるコツも参考になる。
- 開発会社が使用しているツールやシステムのアカウント、管理権限が誰の名義になっているかを確認し、必要であれば会社名義に統一する。
このステップで特に見落とされやすいのが、システムの管理権限やドメイン、サーバーの契約が、会社名義ではなく先代個人の名義やメールアドレスで登録されているケースである。中小企業では、システム導入時の担当者が先代自身であったことから、クラウドサービスのアカウントやドメインの登録者情報が、先代の個人名や個人のメールアドレスになっていることが少なくない。この状態を放置すると、先代が完全に経営から退いた後、パスワードの再設定やアカウントの復旧が必要になった際に、本人確認ができず身動きが取れなくなるという事態が起こり得る。承継のタイミングで、システムに関わるあらゆるアカウントの登録者情報を確認し、会社としての管理体制に統一しておくことは、地味だが極めて重要な作業である。
ステップ5:定期的な確認の場を設ける
体制を整えた後も、それを維持するための仕組みが必要である。一度整備しただけで安心してしまうと、時間の経過とともに再び属人化や情報の断絶が起きる。
- 半年に一度程度、社内の一次窓口担当者と後継社長とで、システムの運用状況について簡単な振り返りの時間を設ける。
- 開発会社との定期的な連絡の機会(電話でもメールでも構わない)を最低でも四半期に一度は設定し、関係が途切れないようにする。
- 窓口担当者が変わった場合には、その都度、開発会社に速やかに連絡し、連絡先の更新を怠らない。
- 新しい業務フローやツールの導入予定がある場合は、早い段階で開発会社に相談し、既存システムとの整合性を確認する。
これらのステップは、一度にすべてを完璧に整える必要はない。重要なのは、後継社長自身が「運用フェーズの体制は誰かが自然に整えてくれるものではなく、経営として設計するものだ」という認識を持ち、優先度の高いところから着手していくことである。特にステップ1とステップ2は、費用も専門知識もほとんど必要とせず、社内の対話だけで進められるため、承継後できるだけ早い時期に着手することを勧めたい。
よくある失敗パターン
体制整備を進める際、後継社長が陥りやすい失敗パターンが3つある。それぞれの背景と回避のヒントを解説する。
失敗パターン1:先代の関係性を「そのまま維持しよう」とする
後継社長が最も陥りやすい失敗は、先代が築いた開発会社との関係性を、そのまま維持しようとすることである。先代への敬意や、関係を壊すことへの不安から、「先代のときと同じやり方を続けよう」と考えるのは自然な心理である。しかし前述の通り、先代と開発会社の関係は、先代個人の信頼関係の上に成り立っていたものであり、後継社長が同じ関係性をそのまま引き継げるわけではない。後継社長は先代とは別の人格であり、開発会社から見れば「新しい取引相手」である。関係性を新しく構築し直すという前提に立たなければ、双方の期待値がずれたまま時間が過ぎていき、ある日突然、対応の質が変わったと感じるような齟齬が発生する。関係を尊重することと、体制をそのまま維持することは別の話だと理解する必要がある。
この失敗パターンが厄介なのは、後継社長本人が「変えない方が誠実だ」と信じ込んでしまう点にある。先代のやり方を尊重する姿勢は美徳ではあるが、経営者としての役割は、先代の模倣ではなく、その時々の状況に応じた最適な判断を下すことにある。開発会社との関係を再構築することは、先代を否定することではない。むしろ、先代が築いた関係の土台の上に、後継社長自身の関係を新たに積み重ねていく作業だと捉えるべきである。実際、多くの開発会社は、後継社長が自分の言葉で関係を築こうとする姿勢を歓迎する。長年のクライアントの代替わりに際して、開発会社側も「新しい社長とどう付き合っていくべきか」を探っていることが多く、後継社長からの積極的な関わりは、双方にとって前向きな一歩になる。
失敗パターン2:古参社員に「全部お任せ」してしまう
先代から「あの人に聞けば大丈夫」と紹介された古参社員に、システムに関する判断を丸ごと委ねてしまうことも典型的な失敗である。ケーススタディ2で見たように、この状態は古参社員の能力や人格の問題ではなく、経営の意思決定がシステムの現場に届かなくなるという構造的な問題を生む。後継社長は経営者として、システムに関する最終的な承認権限を自分の手元に残しておく必要がある。古参社員の知識と経験は最大限に尊重すべきだが、それは「実行」の役割であり、「経営判断」の役割まで委ねてしまうと、ガバナンスの空白地帯が生まれる。任せることと、丸投げすることは違うという認識を持つことが重要である。
この失敗が起きやすい背景には、後継社長自身のシステムへの苦手意識も関係している。財務や営業には自信があっても、システムやITの話になると急に判断を放棄してしまう後継社長は少なくない。「自分には分からない分野だから、詳しい人に任せておけば安心だ」という気持ちは理解できるが、経営判断とは技術的な詳細を理解することではなく、会社にとって何が必要かを見極め、優先順位をつけることである。技術的な内容そのものは開発会社や社内の担当者に確認すればよく、後継社長が担うべきは「この投資は今の会社にとって必要か」「このリスクは受け入れられるか」という経営レベルの判断である。この線引きを意識するだけで、苦手意識を理由に判断を放棄してしまう事態は避けられる。運用フェーズを越えて、将来的なシステム刷新まで見据える段階になったら、社内主導と外注主導のどちらで進めるかという判断も必要になる。この点は刷新を社内主導で進めるか外注に任せきりにするかの決め方で扱っている。
失敗パターン3:問題が起きるまで体制整備に着手しない
3つ目の失敗パターンは、実際に不具合や契約トラブルが発生するまで、運用体制の整備に着手しないことである。承継直後は経営全体の引き継ぎに忙殺され、システムの体制整備は「今すぐ問題になっていないから後回しでいい」と判断されやすい。しかしケーススタディ1で見たように、体制の不備は問題が発生した瞬間に一気に表面化し、その時点で対応しようとしても、原因調査や関係者への確認に時間がかかり、業務への影響が広がってしまう。体制整備は、平時にこそ着手すべき性質のものであり、問題が起きてから慌てて整えるのでは、後手に回ってしまう。承継後できるだけ早い時期、理想的には承継から最初の半年以内に、最低限の見える化と窓口の任命だけでも済ませておくことが望ましい。
この失敗パターンの背景には、「保険と同じで、問題が起きなければ整備した効果を実感できない」という体制整備特有のジレンマがある。財務上の投資であれば、売上や利益として効果が数字に表れるが、体制整備の効果は「問題が起きなかったこと」としてしか表れない。起きなかった問題を実感することは誰にとっても難しく、そのために体制整備への投資は後回しにされやすい。しかし、事業承継を経験した多くの経営者が振り返って語るのは、体制整備を怠ったことによる問題は、忙しい時期や重要な商談のタイミングと重なって発生することが多いという経験則である。トラブルは経営者の都合を選ばない。だからこそ、まだ何も起きていない平時のうちに、多少の時間を割いてでも体制整備に着手しておくことが、結果的に後継社長自身の時間と心理的な余裕を守ることにつながる。
よくある質問(FAQ)
Q1. 社内にITに詳しい人材がいない場合、どうすればよいですか。
A. 一次窓口の役割は、必ずしもITに詳しい人物である必要はない。求められるのは、システムに違和感を感じたときにそれを言語化して開発会社に伝える力と、社内からの相談を取りまとめる調整力である。技術的な判断そのものは開発会社に委ねればよく、窓口担当者の役割は「橋渡し」であると捉えると、人選のハードルは下がる。総務や経理など、社内の業務全体を把握している立場の社員が担うケースも多い。
Q2. 先代がまだ会長として在籍している場合、先代の関与をどう扱うべきですか。
A. 先代がまだ関与できる立場にいるなら、承継直後の一定期間は、後継社長と先代が同席する形で開発会社との顔合わせを行い、体制変更を先代自身の口から伝えてもらうのが最も円滑である。先代の口添えがあることで、開発会社側も体制変更を自然に受け入れやすくなる。ただし、その関与はあくまで移行期間の橋渡しであり、恒久的に先代が窓口として残り続けることは避けるべきである。時期を決めて、徐々に後継社長主体の体制に移していく計画性が必要になる。
Q3. 開発会社が体制変更に消極的で、これまでの担当者を通してほしいと言われた場合はどうすればよいですか。
A. 開発会社にも、これまでの担当者が長年の経緯を把握しているという合理的な理由がある場合が多い。無理に窓口を切り替えるのではなく、まずは新しい窓口担当者と既存の担当者が並走する期間を設け、段階的に引き継ぐ形を提案するとよい。それでも変更に応じない、あるいは対応が不透明なまま先代個人への依存を続けようとする場合は、開発会社側の体制自体に問題がある可能性もあるため、他の開発会社への相談や見積もり取得も選択肢として検討する価値がある。
Q4. 体制整備にどの程度の費用や時間がかかりますか。
A. 本稿で紹介したステップ1から3(見える化、窓口の任命、開発会社への通知)は、追加費用がほとんど発生しない社内的な取り組みであり、後継社長と関係者の対話だけで、数週間から1ヶ月程度で着手できる。ステップ4の書面確認については、既存の開発会社との関係次第だが、簡易な確認書の取り交わしであれば大きな費用は発生しないことが多い。重要なのは費用の大小ではなく、着手するタイミングの早さである。
まとめ
事業承継において、経営理念や取引関係、人事の引き継ぎには注意が払われやすい一方、日常的に使っている業務システムの運用体制は見落とされがちである。しかしその体制は、先代個人の信頼関係や、社内の暗黙の了解、開発会社側の非公式な配慮によって、綱渡りのように成立していたものであることが多い。承継によってその土台が崩れると、些細な不具合が業務停止につながり、属人化した実務担当者が経営のコントロールを阻む壁になり、契約範囲の曖昧さが予期しない費用トラブルを生む。
本稿で紹介した3つのケーススタディは、いずれも技術的な難易度が高い問題ではなく、体制の不備が根本原因だった。逆に言えば、後継社長が早期に、社内の一次窓口を任命し、開発会社に体制変更を正式に伝え、運用フェーズの対応範囲を書面で確認するという地道な作業に着手するだけで、多くのリスクは未然に防げる。これらの取り組みは特別な予算や専門知識を必要とせず、後継社長自身の意識と、社内外との率直な対話によって実現できるものばかりである。
承継後の経営は、日々の意思決定に追われ、システムの体制整備は優先順位が下がりやすい。しかし運用フェーズの体制は、事業が止まらずに回り続けるための土台である。先代から引き継いだのはシステムそのものだけではなく、そのシステムを支えてきた見えない体制であるという認識を持ち、できるところから一つずつ、自らの手で体制を再構築していく姿勢が、後継社長には求められている。
