「うちのシステムを刷新したい」と役員会に持ち出した瞬間、会長や古参の専務から「今のままで回っているんだから、わざわざ金をかけなくていいだろう」と一蹴された経験はないだろうか。稟議書の書式やIT導入補助金の申請書はネットに雛形がいくらでも転がっているが、「先代の代から会社にいる決裁者を、実際にどう納得させるか」という交渉そのものの型は、驚くほど情報がない。
先に、要点をまとめます。
- 決裁者を止めているのは機能や金額の説明不足ではなく、多くの場合「自分が承認した責任を取れるか」という不安そのものである
- 説得材料は「このまま何もしなかった場合のコスト」を可視化することから組み立てる。新システムの魅力を語るより効果が大きい
- 一発の大型稟議ではなく、小さく試して実績を作ってから本丸を通す「二段階の合意形成」が古参役員には特に有効
- ただし数字の誇張・架空の実績はブランド毀損に直結するため、根拠のある範囲でしか書かない
ただし、この「二段階の合意形成」には1つ注意点があり、後半の失敗パターンの章で説明する。段階を急ぎすぎると、かえって古参役員の警戒心を強めてしまうケースがあるからだ。
この記事は、親または先代から会社を継いだばかり、あるいは継ぐ準備をしている二代目・三代目経営者に向けて書いている。会長職に退いた先代や、創業期から会社を支えてきた専務・古参の役員がまだ意思決定に関わっている会社で、システム刷新の話を一度は持ち出して止められた経験がある人、あるいはこれから初めて持ち出そうとしている人を想定読者としている。
なぜ古参役員はシステム刷新に反対するのか?
表向きの理由は「コスト」だが、実際の反対理由の多くは「自分の判断責任」への不安である。
システム刷新の提案が止まる場面を見ていくと、決裁者が口にする理由と、実際に引っかかっている理由がずれていることが多い。口では「まだ早い」「今のままでいい」と言うが、実際には「自分が承認した結果、現場が混乱したり、想定外の費用がかかったりしたら、自分の責任になる」という不安が根底にある。
日本政策金融公庫総合研究所が中小企業経営者へのインタビュー調査を分析した研究では、経営者のIT活用経験の有無によってIT導入を意識するきっかけが異なり、中小企業のIT経営を推進するには「経営者にITの価値を認識させること」「導入後のイメージを想起させること」が重要だと結論づけている(日本政策金融公庫総合研究所, 2024)。つまり、ITに馴染みの薄い決裁者にとっては、機能の説明よりも「導入後、会社がどう変わって見えるか」を具体的に想像できることの方が判断材料として重要だということだ。先代や古参の役員がまさにこのタイプの決裁者であることは多い。
もう一つ見落とされがちなのが、古参役員の「自分の在任中の実績を汚したくない」という心理だ。先代が長年かけて築いてきたシステムや取引先との関係を、承継直後の経営者が持ち込んだ提案で壊されることへの警戒感は、単なる保守性とは別のものとして理解しておく必要がある。自社の場合、反対の背景に「金額への不安」「変化そのものへの不安」「自分の責任への不安」のどれが強いかを見極めることが、説得材料の組み立て方を左右する。
反対する決裁者を一括りに「保守的な古参」と捉えてしまうと、説得材料の的も外れやすい。実務でよく出会う決裁者のタイプは、大きく3つに分けて考えると整理しやすい。
- 会長職に退いた先代: 経営権は譲ったものの、株式の大半をまだ保有しており、大きな支出には最終的な了承を求められる立場にいることが多い。反対の背景には「自分が作った会社の仕組みを、自分のいないところで変えられたくない」という感情的な要素が強く出やすい
- 創業期からの専務・古参役員: 経営権も株式も限定的だが、社内の実務を長年支えてきたという自負が強い。反対の背景には「自分たちのやり方が否定されている」という受け止め方をしやすく、感情面への配慮が特に重要になる
- 番頭格の古参社員(役員ではないが実質的な決裁権を持つ): 肩書き上は決裁者でなくても、現場の実務を握っているため「この人が嫌がると現場が動かない」という事実上の拒否権を持つ。稟議書とは別に、個別の合意形成が必要になる
このタイプ分けをしたうえで、誰の反対が最も強いか、誰の了承が実質的に必要かを見極める。会長の了承を最優先すべき会社もあれば、番頭格の古参社員を先に個別に説得しておかないと、いくら稟議書を整えても現場レベルで話が進まない会社もある。決裁のフローだけでなく、実質的な影響力の所在を見誤ると、説得材料をどれだけ精緻に作っても的外れになりやすい。
説得材料は何から組み立てればいいのか?
「導入するメリット」ではなく「導入しなかった場合に何が起きるか」から書き始めると、決裁者の腰は軽くなりやすい。
新しいシステムの機能や効率化の効果を訴える説得の仕方は、実は決裁者にとって最も響きにくい。人は「得られるかもしれない利益」よりも「既に持っているものを失うかもしれないリスク」に強く反応する傾向がある。この傾向を踏まえると、説得材料の最初に置くべきは「今のシステム・今のやり方を続けた場合、この先どんな損失が具体的に発生するか」の一覧だ。
例えば、次のような整理の仕方が有効である。
- 属人化のリスク: 今のシステムを扱える社員が1人しかいない場合、その人が退職・休職した瞬間に業務が止まる。「もし◯◯さんが来月倒れたら」という具体的なシナリオで語ると、決裁者は自分ごととして受け止めやすい
- サポート終了・保守切れのリスク: 使っているOSやソフトウェアのサポート終了時期が近い場合、放置すると障害発生時に修理する会社がなくなる。時期を明確な日付で示す
- 機会損失: 手作業や紙の処理に社員の時間を使い続けることで、その時間を他の業務に振り向けられないコスト。時間を金額換算すると伝わりやすい
これらを並べたうえで、初めて「だからこのタイミングで刷新する」という結論につなげる。決裁者の頭の中では「今のままでいるコスト」と「刷新するコスト」を比較する構造になっているはずなので、片方(今のままのコスト)が説明されていない状態では、決裁者にとって「刷新するコスト」だけが目に見える負担として映ってしまう。
実際にこの整理を紙に書き出す場合、次のような表形式にすると決裁者にとって読みやすくなる。
| リスクの種類 | 具体的な内容 | 放置した場合の影響 |
|---|---|---|
| 属人化 | このシステムを扱えるのが経理の◯◯さん1人だけ | 退職・休職時に業務が完全に止まる可能性 |
| サポート終了 | 使用中のOS・ソフトのサポート終了時期が迫っている | 障害時に対応できるベンダーがいなくなる |
| 機会損失 | 手作業の転記・照合に月◯時間かかっている | その時間を営業・現場の改善に使えない |
| データの散在 | 部門ごとに別々のExcel・紙台帳で管理している | 経営判断に必要な数字をすぐに把握できない |
この表を埋める作業自体が、実は説得材料作りの半分を占めている。決裁者向けの資料としてきれいに仕上げる前に、まず自社の実態をこの4項目に当てはめて書き出してみることが、次のステップである費用感の提示につながっていく。
もう一つ、この段階で意識しておきたいのが「誰の言葉で語るか」という点だ。承継したばかりの経営者自身がこれらのリスクを説明するよりも、実際に日々の業務でその不便を感じている現場の社員の声を添えた方が説得力が増すことが多い。「経理の◯◯さんも、月末はいつも残業続きで大変だと言っている」という具体的な声は、決裁者にとって「自分の知らないところで現場が困っている」という気づきになり、経営者側の一方的な主張よりも受け入れられやすい。
ここまでの整理ができたら、次は費用感を具体的な数字に落とし込む段階に入る。
説得材料に入れる費用感はどう示せばいいのか?
総額の提示だけでなく、「何にいくらかかり、それによって何が減るか」を対で示すと決裁者の納得感が増す。
費用の話を切り出す際、多くの提案が「◯◯◯万円かかります」という総額の提示だけで終わってしまう。これでは決裁者にとって「支出」という側面しか見えず、判断材料として不十分だ。総額だけでなく、内訳と、その支出によって何が変わるかをセットで示す必要がある。
中小企業のシステム刷新にかかる費用は、規模や範囲によって大きく異なるが、目安として次のようなレンジで語られることが多い。
| 規模感 | 費用の目安 | 主な内容 |
|---|---|---|
| 小規模な業務改善(Excel・紙台帳の一部システム化) | 数十万〜200万円程度 | 特定業務のみをノーコード・既製SaaSで置き換え |
| 基幹業務の刷新(受発注・在庫・顧客管理の統合) | 300万〜1,000万円程度 | パッケージ×カスタマイズ、または部分フルスクラッチ |
| 全面的な基幹システム刷新 | 1,000万円〜 | フルスクラッチ、複数部門をまたぐ大型プロジェクト |
(金額は案件の規模・要件の複雑さによって大きく変動する目安であり、正確な見積もりは個別の要件整理を経て算出する必要がある)
この金額感を提示するとき、決裁者が特に気にするのは「これは一度きりの支出か、それとも継続してかかるものか」という点だ。初期費用と、月額の保守費用・ランニングコストを分けて明示し、「初期費用は◯◯万円だが、今のシステムに払い続けている保守費用と比較すると、△年で逆転する」のように、既存の支出と比較する形で説明すると判断しやすくなる。今の会社がどこにいくら払っているかを決裁者自身が正確に把握していないケースも多いため、まず現状の支出を洗い出すところから始めるとよい。
費用感の提示でもう一つ効果的なのが、社内で過去に承認された別の支出と比較する方法だ。例えば「昨年更新した営業車両のリース費用が年間◯◯万円だった。今回の刷新の初期費用はそれと同程度で、しかも一度きりの支出になる」のように、決裁者が既に「妥当だ」と判断した実績のある支出と並べて示すと、新しい支出に対する心理的なハードルが下がる。古参役員にとって、これまで承認してきた設備投資や車両更新の金額感は既に馴染みのある基準であり、そこに紐付けて説明することは、未知の「システム投資」を既知の「投資判断」の枠組みに落とし込む効果がある。
補助金の活用を検討している場合は、費用感の提示に補助率を組み込むことも可能だが、採択されることを前提に稟議を組み立てるのは避けたい。デジタル化・AI導入補助金(旧IT導入補助金)のように毎年度制度内容が変わる補助金は、申請しても不採択になる可能性がある前提で、補助金なしでも判断できる金額感を先に示し、採択されれば負担が軽くなる、という順序で説明するのが手堅い。この補助金の使い道については別記事(デジタル化・AI導入補助金(旧IT導入補助金)は先代からのシステム刷新に使えるか)で詳しく整理している。
小さく試してから本丸を通すやり方とは?
いきなり全社規模の稟議を通そうとせず、影響範囲の小さい一部門・一業務から試験導入し、実績を作ってから本丸の稟議に進む二段階のやり方が、古参役員には特に有効である。
大きな決裁ほど、決裁者が背負う責任も大きくなる。逆に言えば、影響範囲を小さく区切った提案であれば、決裁者が「これくらいなら」と判断しやすくなる。具体的には次のような進め方になる。
- 一部門・一業務に絞った小規模な導入を提案する: 「全社の基幹システムを刷新する」ではなく「経理部の請求書発行だけをクラウド化する」のように、範囲を明確に区切る
- 期間と評価基準を最初に決めておく: 「3ヶ月試して、作業時間がどれだけ減ったかで判断する」のように、いつまでに何を評価するかを事前に合意しておく
- 試験導入の結果を数字で示す: 「請求書発行にかかっていた時間が月20時間から月5時間に減った」のように、具体的な削減効果を提示する
- 実績を根拠に、本丸の刷新を提案する: 小規模導入の成功実績を「うちの会社でも効果が出た」という根拠として使い、次の大きな提案につなげる
この進め方の利点は、決裁者にとってのリスクが小さいだけでなく、承継後の経営者自身にとっても「実際にやってみたらどうだったか」を確認しながら進められる点にある。いきなり大型投資に踏み切って失敗するリスクを避けられるのは、発注する側にとっても安心材料になる。
小さく始めるといっても、行き当たりばったりに1つのツールを試すだけでは実績として弱い。何を評価基準にするかを決裁者と事前にすり合わせておくことが、次の段階に進むための説得材料そのものになる。
この二段階のやり方が古参役員に有効な理由は、心理的な負担の分散だけではない。試験導入の期間中、決裁者自身が実際に変化を目にする機会が生まれることも大きい。請求書発行がクラウド化されて処理が早くなった、担当者の残業が減った、といった変化を数ヶ月にわたって間近で見ることで、決裁者の中で「これは危険なものではない」という実感が積み上がっていく。稟議書の紙の上だけで判断させるのではなく、実際の変化を体感してもらう期間を意図的に作ることが、二段階の進め方の本質的な狙いだ。
なお、試験導入の対象業務を選ぶ際は、影響範囲の小ささだけでなく「決裁者の目に触れやすい業務」を選ぶこともポイントになる。経理や総務のように役員が日常的に接する業務であれば、変化を実感してもらいやすい。逆に、現場の奥まった業務を選んでしまうと、試験導入が成功していても決裁者の目に留まらず、次の提案の後押しにならないことがある。
段階を分けることに慎重な意見もある。「小さく試している間に競合に先を越されるのではないか」という懸念だ。この懸念自体は正しいが、二段階の進め方は「時間を無限に引き延ばす」ことを意味しない。評価基準と期間をあらかじめ区切っておけば、試験導入は長くても3ヶ月程度で結論が出る設計にできる。むしろ、一発の大型提案が否決されて振り出しに戻ることの方が、結果的に時間のロスは大きくなりやすい。急いでいるからこそ、確実に進める二段階の方が総所要期間は短くなることも多い。
発注前に、どこまで社内合意を固めておくべきか?
開発会社に相談する前の段階で、少なくとも決裁ルートの誰が最終的にサインするのかと、予算の上限をどこまで自分の裁量で決められるのかの2点は、後継社長自身の中で明確にしておく必要がある。
説得材料が整い、小さな試験導入の実績もできたところで、いよいよ本格的な発注の話に進む。この段階で見落とされがちなのが、「開発会社との交渉」の前に「社内での最終確認」を済ませておくことの重要性だ。
具体的には、次の3点を発注前に自分の中で整理しておきたい。
- 最終的な決裁者は誰か: 会長なのか、取締役会全体の合意が必要なのか、あるいは自分の裁量で決められる金額の範囲なのか。会社によって決裁のルールは異なるため、定款や過去の稟議の慣例を確認しておく
- 予算の上限と、その根拠: 「このくらいまでなら出せる」という金額感を、可能であれば決裁者と事前にすり合わせておく。開発会社との見積もり交渉の場で初めて予算感を伝えると、社内での合意形成と対外的な交渉が同時進行になり、どちらも中途半端になりやすい
- 失敗した場合の落としどころ: 万が一プロジェクトが計画通りに進まなかった場合、どこまでを許容範囲とするか。事前に決裁者とこの点を話しておくと、トラブル発生時に「聞いていない」という反発を避けやすい
これらが曖昧なまま開発会社との商談を進めてしまうと、見積もりや提案内容を持ち帰って社内調整する段階で振り出しに戻り、対外的な信用も損ないかねない。開発会社に相談する前に、社内の合意形成をどこまで固めておくかを決めておくことが、結果的にプロジェクト全体をスムーズに進める近道になる。要件が固まっていない段階でどこまで先に決めておくべきかについては、別記事(刷新を開発会社に相談する前に、決めておきたい3つのこと)でも扱っているので、あわせて確認しておくとよい。
稟議書に書くべきこと・書かなくていいことの違いは?
稟議の書類自体には機能の詳細を並べすぎず、決裁者が「判断」に使う情報だけに絞り込むと通過率が上がる。
稟議書の文書そのものについては、別記事(IT導入の稟議書の書き方、非IT出身の決裁者に伝わるテンプレート)で項目立てまで詳しく解説しているが、この記事の文脈で強調しておきたいのは「稟議書に書くべき情報の取捨選択」の部分だ。
機能の一覧やシステムの技術的な仕組みを詳しく書き込みたくなる気持ちは理解できるが、非IT出身の決裁者にとってそれは判断材料にならないことが多い。稟議書に必ず入れるべきは、次の4点に絞られる。
- 今のまま何もしなかった場合に起きること(前段の「なぜ古参役員は反対するのか」で整理した内容)
- 費用の内訳と、既存の支出との比較
- 想定されるリスクと、その対処方針(失敗した場合にどうするか)
- 試験導入で得られた実績(ある場合)
逆に、開発会社の選定基準や技術的な実装方式の詳細は、稟議書ではなく口頭での補足や別添資料に回してよい。文書が長くなるほど決裁者が読み切れなくなり、かえって「よく分からないから保留」という結論に流れやすくなる。
書面での説得材料と、口頭での説明を使い分けることも意識しておきたい。稟議書は「後で見返しても筋が通っている」ことを目的とした文書であり、感情面への配慮や個別の事情説明は書面になじまない。一方、会長や専務個人への根回しは、書面よりも先に口頭で行う方が効果的なことが多い。稟議書を正式に提出する前に、決裁者本人に「今度こういう提案をしようと思っているのですが」と個別に一言伝えておくだけで、会議の場での反応が大きく変わることがある。不意打ちで大きな提案を出されると、決裁者は防御的な反応をしやすくなる。事前に趣旨を共有しておくことは、根回しというより、決裁者に考える時間を渡す配慮と捉えた方が実務的には近い。
反対されたときに、その場で切り返す必要はあるのか?
その場での即答・論破を目指さない方がよい。むしろ「一度持ち帰って検討する」という余白を作る方が、最終的な承認につながりやすい。
役員会や経営会議の場で反対意見が出ると、承継したばかりの経営者は「ここで言い返さないと自分の立場が弱くなる」と焦りがちだ。しかし、その場で議論を戦わせて論破しようとすると、古参役員は「自分の意見を否定された」という感情的な反発を強めてしまうことが多い。
有効なのは、反対意見が出た時点で「なるほど、そのご懸念はもっともです。次回までに、そのリスクへの対処方法も含めて整理してきます」と一度引き取ることだ。その場で決着をつけようとせず、次回までに懸念点への回答を用意して再提案する。この一手間が、決裁者に「自分の意見がちゃんと聞かれた」という納得感を与える。
古参役員が長年会社を支えてきたという事実そのものへの敬意を示すことも、実務的な効果を持つ。「先代の時代にこのやり方で会社が成長してきたことは理解している。そのうえで、今の環境変化に合わせて、この部分だけを見直したい」という伝え方は、変化の提案でありながら過去の否定にならない。感情的な対立を避けることは、単なる処世術ではなく、次の稟議を通すための実務上の準備でもある。
反対意見が具体的な懸念(「セキュリティは大丈夫か」「今の担当者はどうなるのか」等)であれば、次回までにその懸念に一つずつ回答を用意する。逆に、反対意見が「なんとなく心配だ」「今のままでいいのでは」といった漠然とした感覚的なものであれば、懸念点を具体化する質問を投げかけて、相手自身に何が不安なのかを言語化してもらうことが有効だ。「具体的にどのあたりがご心配でしょうか」と尋ねると、決裁者自身が「そういえば、システムが止まったときに誰が対応するのかが分からない」のように、漠然とした不安の正体に気づくことがある。この正体さえ分かれば、次の提案でピンポイントに対処できる。
古参社員が長年会社を支えてきたという事実そのものへの敬意を示す文脈で、事業承継後の離職リスクについても触れておきたい。帝国データバンクの調査によると、2025年度の人手不足倒産は441件で過去最多となり、そのうち従業員の退職をきっかけとする「従業員退職型」は118件で、こちらも過去最多を記録している(帝国データバンク, 2025年度「人手不足倒産」動向調査)。デジタル化への反発から古参社員が離職してしまうリスクと、刷新を先送りし続けるリスクの両方を天秤にかけながら進める必要があり、この離職リスクの見極め方については別記事(「デジタル化するなら辞める」と言われたら。刷新と離職リスクの向き合い方)で詳しく扱っている。
説得材料の作り方で失敗しやすいパターンとは?
根拠のない数字の誇張と、段階を急ぎすぎる二段階提案の2つが、代表的な失敗パターンである。
冒頭で触れた「二段階の合意形成」の注意点はここで回収する。試験導入から本丸提案への移行を急ぎすぎると、かえって古参役員の警戒心を強めてしまうことがある。試験導入の結果が出た直後に「では次は全社展開です」と大きく話を広げると、決裁者からすれば「最初から全社展開が目的で、小さく見せかけていたのでは」という不信感につながりかねない。試験導入の結果を丁寧に共有し、決裁者自身が「これなら広げてもいいのでは」と思える時間を置くことが、急がば回れの進め方になる。
もう一つの失敗パターンが、説得材料の数字を誇張してしまうことだ。「これを導入すれば売上が◯%上がる」のような、根拠のない断定は絶対に避けたい。実際に検証できていない効果を数字にして示すと、後になって実績が伴わなかったときに「あのときの説明は何だったのか」という不信を招き、次の提案が一段と通りにくくなる。分からない・断定できない効果は「◯◯という前提であれば、これくらいの削減が見込める」という条件付きの表現にとどめ、誇張しないことが長期的には最も効く説得材料になる。
もう一つ付け加えるなら、失敗パターンの多くは「説得材料そのものの出来」よりも「提案するタイミング」に起因することも多い。決算期直前で資金繰りに神経質になっている時期や、大きな取引先とのトラブルで社内が慌ただしい時期に新しい投資の話を持ち出すと、内容がどれだけ整っていても「今はそれどころではない」と一蹴されやすい。逆に、決算が締まって業績の見通しが立った直後や、既存システムで何らかのトラブルが実際に発生した直後は、決裁者の問題意識が高まっているタイミングであり、同じ説得材料でも通りやすさが変わる。提案の中身と同じくらい、いつ持ち出すかにも注意を払いたい。
比較として、銀行融資を受ける際に提出する事業計画書と、社内向けの稟議書の違いも押さえておくと説得材料の設計がぶれにくくなる。銀行は「返済できるか」という一点で審査するため、数値計画の精緻さが重視される。一方、社内の古参役員が見ているのは数値の精緻さそのものではなく、「この提案者(後継社長)は会社のことをちゃんと分かって言っているか」という信頼の有無だ。同じ費用対効果の数字を出すにしても、銀行向けには根拠資料を厚くする一方、社内向けには数字の裏にある現場感(誰がどう困っていて、何がどう変わるか)を厚くする、という力点の置き方の違いを意識するとよい。
この記事で持ち帰れることをまとめると、決裁者を止めている本当の理由の見極め方、そして「今のままのコスト」から組み立てる説得材料の作り方、小さく試してから本丸を通す二段階の進め方の3点になる。これらを押さえれば、次に役員会で提案する際、少なくとも「機能を説明しただけで終わる」という失敗は避けられるはずだ。
まずは今週、今のシステムや紙業務にどれだけの時間・費用がかかっているか、実際に数字で書き出してみてほしい。それだけでも、次に提案する際の説得材料の土台になる。誰か1人にヒアリングするだけでもいい。「先月、この作業にどれくらい時間を使いましたか」と聞くところから始めれば、机上の空論ではない、自社の実態に即した説得材料の第一歩になる。
承継直後の経営者にとって、こうした社内の合意形成は、開発会社との交渉と同じくらい、あるいはそれ以上に時間と気力を使う作業になりやすい。先代や古参役員との関係性は一朝一夕に築かれたものではないため、説得材料をどれだけ精緻に作っても、一度の提案ですべてが解決するとは限らない。それでも、決裁者が本当に不安に思っている部分を的確に言語化し、今のままでいることのコストを可視化し、小さな実績を積み重ねていけば、着実に前に進める話であることは間違いない。
先代からの付き合いのシステム会社に相談する前に、社内の合意形成をどう組み立てるかで迷う場合は、要件を整理する段階からエンジニアが直接ヒアリングに入る進め方もある。自社の状況に合わせた進め方を一緒に整理したい場合は、お気軽にご相談ください。
