先代がワンマンで決めてきたIT投資。承継後の「決め方」を仕組みに変える

先代が一代でここまで会社を大きくした。その事実は疑いようがない。だからこそ、システムやITへの投資判断も、長い間ずっと「先代の頭の中」だけで決まってきたのではないだろうか。稟議書は形だけ回っていても、実際には「社長が『いいよ』と言ったから決まった」。逆に「社長が首を縦に振らなかったから止まった」。そこに明確な判断基準があったわけではなく、先代の経験と勘、そして取引先や業界内の評判といった、属人的な物差しで意思決定がなされてきた会社は少なくない。

承継したばかりのあなたが今まさに向き合っているのは、システムそのものの古さだけではない。「IT投資をどう決めるか」という意思決定の仕組みそのものが、先代という一人の人間に依存したまま残っているという問題だ。

先に、要点をまとめる。

• IT投資の意思決定が属人化する最大の原因は、判断基準・情報源・決裁権が一人に集中し、その人の頭の中以外に記録が残らないことにある
• 承継後の再設計は「稟議フォーマットを作る」ことがゴールではなく、①何を判断材料にするか②誰の意見を聞くか③最終的に誰がどう決めるか、という3層を分けて仕組み化することが本質
• 先代がまだ社内にいる場合は、決定権の移譲と、経験の活用を分けて設計すると角が立ちにくい
• いきなり全社的な制度に変える必要はなく、次の1件のIT投資案件から新しい決め方を試すのが現実的な着地点

ただし、この仕組み化には一つだけ注意点がある。基準を作り込みすぎると、今度は「スピード感のあるワンマン経営」の良さまで失ってしまう可能性があるという点だ。これは記事の後半、「仕組み化のやりすぎに気をつける」のセクションで具体的に説明する。

なぜIT投資の決め方が「先代任せ」のままなのか

先代がワンマンで会社を回してきた期間が長いほど、IT投資に限らず、会社の意思決定プロセスそのものが「社長に聞けば分かる」という状態に最適化されている。これは悪意や怠慢の結果ではなく、合理的な帰結でもある。

創業期や成長期の中小企業では、意思決定のスピードこそが競争力の源泉になる。稟議書を何段階も回して1ヶ月かけて判断するより、社長がその場で「やろう」と決めて即実行するほうが、変化の速い市場では圧倒的に有利だった。IT投資の意思決定を担うのは経営層・現場部門・IT関連部門といった社内の人材だけでなく、既存の取引先ベンダーや外部の情報源も影響を及ぼすことが調査で指摘されており（日経クロステック「IT投資における『意思決定の担い手』と『3大阻害要因』」）、中小企業ではこの「担い手」が先代個人に集中しやすい構造がある。

問題は、その意思決定の「型」が、他の誰にも共有されないまま先代の頭の中だけに残っていることだ。具体的には次のような状態が起きやすい。

• 判断基準が言語化されていない：先代は「このベンダーは長年の付き合いだから」「この人の紹介だから」といった、記録に残らない基準で判断してきた
• 相談相手が固定化されている：長年の顧問税理士や、創業当初からの取引先社長など、特定の数人にしか相談していない
• 却下された案件の記録がない：「昔検討して駄目だったから」という理由で新しい提案が却下されるが、なぜ駄目だったのかの記録は残っていない
• 決裁のタイミングが不規則：定例の稟議会議のようなものはなく、思いついたときに、思いついた順で決まっていく

これらは、属人化という言葉で語られる問題の、意思決定版と言える。システムや業務フローの属人化はよく語られるが、「決め方」そのものが属人化しているケースは見落とされやすい。あなたが先代のシステムを引き継いだとき、システムの仕様書だけでなく、「なぜこのシステムをこの会社に発注したのか」という判断の経緯も一緒に失われているとしたら、それはまさにこの問題の表れだ。

御社の場合、稟議書や会議議事録は形式的に残っていても、そこに「なぜその判断に至ったか」の理由が書かれていないなら、この状態に該当している可能性が高い。

「先代の勘」が実は機能していた理由

誤解してはいけないのは、先代の属人的な判断が、単なる「思いつき」だったわけではないという点だ。20年、30年と会社を経営してきた先代の頭の中には、次のような情報が蓄積されている。

• 過去に同種の投資でうまくいった案件・失敗した案件の記憶
• 取引先やベンダーの「信頼できるかどうか」の評判の蓄積
• 業界特有の繁忙期・閑散期に合わせた投資タイミングの感覚
• 自社の資金繰りの季節変動を踏まえた「今なら投資できる」という肌感覚

つまり先代の勘は、記録には残っていないが、実質的には長年のデータの蓄積に基づく経験則だった。承継社長がこれを「非科学的だから全部やめる」と切り捨ててしまうと、判断材料そのものが失われてしまう。仕組み化とは、この経験則を否定することではなく、頭の中にしかなかったものを、承継社長を含む複数の人間が参照できる形に「翻訳」する作業だと捉えるとよい。

先代の代からの付き合いのベンダー自身が、実質的に投資判断の相談相手になっていたケースも珍しくない。この場合、層2の「相談の層」にそのベンダーを組み込むこと自体は否定しないが、そのベンダーが提案する選択肢だけが判断材料のすべてにならないよう、あえて別のベンダーや専門家にも意見を聞き、比較対象を意識的に増やす視点を持っておきたい。

承継後によくある2つの極端な反応

先代のワンマン意思決定に気づいたとき、承継社長の反応は大きく2パターンに分かれる。どちらも、行き過ぎると新たな問題を生む。

パターン1: 一気に「合議制」に変えようとする

「先代のようなトップダウンはもう古い。これからはボトムアップで、みんなの意見を聞いて決める会社にする」と宣言し、いきなり複数人の承認を必須とする稟議フローや、月1回の経営会議での集団討議を導入するケースだ。

理念としては間違っていないが、実務上は次の副作用が起きやすい。

• 決裁までの期間が先代時代の3倍、5倍に伸び、現場から「昔のほうが早かった」という不満が出る
• 参加者が増えるほど「誰も強く反対しないが、誰も強く推進もしない」意見の丸め込みが起き、必要な投資が先送りされる
• 会議に呼ばれなかった古参社員が「自分は蚊帳の外に置かれた」と感じ、かえって心理的な反発を強める

パターン2: 何も変えず、先代のやり方をそのまま踏襲する

逆に、「先代のやり方を否定するのは角が立つ」と考え、これまでの意思決定プロセスをそのまま引き継いでしまうケースもある。この場合、承継社長自身が新たな「属人化の起点」になってしまう。先代の勘は20年、30年の経験の蓄積の上に成り立っていたものであり、承継したばかりの社長がそれをそのまま真似ても、同じ精度の判断はできない。結果として、勘に頼った投資判断が裏目に出て、失敗を重ねてから慌てて仕組み化に着手する、という遠回りをすることになる。

理想は、この2つの中間、つまり「決定権は明確に自分に置きつつ、判断材料と相談先を仕組み化する」という設計だ。次のセクションで、その具体的な組み立て方を示す。

実際に起きた失敗パターンから学ぶ

仕組み化の必要性をより具体的にイメージするため、承継後のIT投資判断でよくつまずくパターンを2つ挙げる。いずれも、どちらの会社が悪いというより、意思決定の「型」が引き継がれなかったことが根本原因になっている典型例だ。

失敗例1: 「先代の紹介だから」で契約したベンダーとの再契約

先代の代からの付き合いだったベンダーとの契約更新が近づいたとき、承継社長は「今までずっとお世話になってきたから」という理由だけで、内容を精査せずに更新してしまった。半年後、他社に相見積もりを取ったところ、同等のサービスを3割近く安く受けられることが分かった。判断材料が「これまでの関係性」だけに偏り、費用対効果という層1の観点が抜け落ちていたために起きたケースだ。契約更新のタイミングで一度、費用対効果と代替候補の有無を確認する手順が仕組みとして組み込まれていれば、防げた可能性が高い。

失敗例2: 誰にも相談せず即決した結果の手戻り

逆に、承継社長が先代の「即断即決」のスタイルをそのまま真似て、現場に相談せずに新しい業務システムの導入を即決したケースもある。導入後、実際にシステムを使う現場から「自分たちの業務フローとまったく合わない」という声が上がり、結局は追加のカスタマイズ費用が発生した。これは層2の「相談の層」を飛ばしてしまったことによる典型的な手戻りで、現場の実務担当者への確認を決裁前の必須ステップにしておけば避けられた失敗だ。

失敗例3: 撤退条件を決めずに投資を続けた結果の損失拡大

もう一つ多いのが、投資を始めた後に「もう少し様子を見よう」を繰り返し、損切りのタイミングを逃すケースだ。先代時代からのクラウドサービスの契約を、効果が出ていないと薄々感じながらも「解約すると角が立つから」という理由だけで更新し続け、結果的に数年分の無駄な費用を払い続けていたという相談は珍しくない。層1の判断材料に「撤退条件」をあらかじめ組み込んでおけば、感情的な判断に流されず、機械的に見直しのタイミングを迎えられる。

IT投資の決め方を3層に分けて設計する

意思決定を仕組み化するというと、稟議フォーマットや承認ルートの図を思い浮かべがちだが、それだけでは形式が変わるだけで、判断の質は変わらない。分けて設計すべきは次の3層だ。

層1: 何を判断材料にするか（情報の層）

先代の頭の中にあった「判断基準」を、後から見返せる形に書き出す作業がまず必要になる。ゼロから新しい基準を作るのではなく、まず「先代がなぜOKを出し、なぜNGを出したか」の過去の事例を、覚えている範囲で棚卸しすることから始めるとよい。

具体的には、次のような観点をテンプレート化しておくと、案件ごとの検討が揃う。

このテンプレートに、金額の大小に応じた記入項目の濃淡をつけておくとよい。小さな投資（数万円〜数十万円程度のツール導入など）まで同じ厚さの資料を求めると、現場が疲弊し、結局「面倒だから社長に直接口頭で聞く」という旧来の動きに逆戻りしてしまう。

このテンプレートを実際に運用する際は、「撤退条件」の項目を空欄のまま提出させない、というルールだけは徹底したい。先代時代のIT投資が失敗しても方向転換しにくかった最大の理由は、「いつまでに効果が出なければ見直すか」という基準が最初から存在しなかったことにある。撤退条件を最初に決めておけば、投資後にずるずると「もう少し様子を見よう」を繰り返すことを防げる。

層2: 誰の意見を聞くか（相談の層）

先代の時代は、相談相手が特定の数人に固定化されていることが多い。承継後は、案件の性質によって相談すべき相手を意図的に広げる設計が有効だ。

• 現場の実務担当者：実際にそのシステムを使う人の意見。使い勝手やこれまでの不満は、経営層だけでは把握できない
• 経理・財務：投資額が会社のキャッシュフローに与える影響。特に承継直後は、先代の時代からの借入や設備投資の返済状況を踏まえた判断が必要になる
• 古参社員（顧問的な立場の人がいれば）：先代の判断基準を知る生き証人として、「これは先代なら賛成しただろう」「これは先代が過去に見送った理由がある」といった参照情報を持っている
• 専門家（必要な場合のみ）：契約内容や技術的な妥当性の確認が必要な高額案件では、顧問弁護士や外部のIT専門家の意見を仰ぐ

ここで重要なのは、「全員の合意を取る」ことが目的ではないという点だ。相談は判断材料を増やすためであり、最終決定は次の層で一本化する。

相談相手をリストアップする際は、案件の性質ごとに「誰に聞くか」をあらかじめ決めておくと、都度悩まずに済む。例えば次のような対応表を作っておくイメージだ。

この対応表自体も、最初から完璧を目指さず、案件を重ねるたびに「今回は誰に聞くべきだったか」を振り返って更新していけばよい。

層3: 誰がどう決めるか（決裁の層）

判断材料が揃い、必要な相談を終えたら、最終的に「誰が」「どのタイミングで」決めるかを明確にする。承継直後であれば、基本的には決裁権を自分（新社長）に一本化しておくのが望ましい。合議制にして責任の所在を曖昧にすると、投資が失敗したときに「誰の判断だったのか」が分からなくなり、次の改善につながらない。

決裁の記録は、稟議の形で残すのが一般的だが、重要なのは書式そのものより「なぜその判断をしたか」の一文を必ず添えることだ。稟議書の具体的な書き方については、IT導入の稟議書の書き方、非IT出身の決裁者に伝わるテンプレートで個別に扱っているので、フォーマットに落とし込む段階ではあわせて参照してほしい。予算そのものの組み立て方は承継社長のためのIT予算の作り方と、先代・古参役員への説明方法で扱っている。この記事はその一段上の、「そもそもどういう順番で、誰が関わって決めるか」というプロセス設計を扱っている。

先代がまだ社内にいる場合の進め方

会長や相談役として先代がまだ社内にいる状態で、意思決定プロセスを変えるのは特に神経を使う場面だ。ここでの基本方針は、「決定権の所在」と「経験の活用」を分けて考えることだ。

決定権については、承継が完了している以上、最終判断は新社長にあることを、遠回しにではなくはっきりと社内に示す必要がある。ただし、それは先代の意見を聞かないという意味ではない。むしろ層2の「相談の層」に先代を明確に位置づけ、「最終決定はあなた（新社長）だが、先代の意見は必ず聞く」という役割を制度として作ってしまうほうが、先代自身の面子も保たれ、周囲にも分かりやすい。

例えば、一定額以上の投資案件については「決裁前に先代へ一度説明する」という手順を仕組みとして組み込んでおくと、先代は「相談された」という実感を持てる一方、決裁権が自分にはないことも自然に理解できる。これは、先代を軽視しているように見えず、かつ属人的な「先代の許可がないと動けない」状態にも陥らない、現実的な落としどころだ。

古参の役員や社員に対しても同様で、「あなたの意見を聞く場は用意されているが、最終判断は社長が行う」という構造を明確にしておくことが、後々のトラブルを減らす。曖昧なまま進めると、「話を聞いてもらえなかった」という不満と、「結局誰が決めているのか分からない」という混乱の両方を招きやすい。

先代への説明で意識したい伝え方

先代への事前説明の場では、「これまでのやり方を変えます」という宣言よりも、「これまで先代の頭の中にあった判断のコツを、みんなが使える形にしたい」という伝え方のほうが受け入れられやすい。承継後の経営では、先代が社内で孤立させられたと感じたり、古参社員の理解が得られないまま摩擦が生じたりするケースが指摘されており（りそなBiz Action「二代目社長が陥りやすい経営の落とし穴」）、これはIT投資の決め方を変える場面でも起こりうる摩擦と同じ構図だ。IT投資の決め方についても、「先代のやり方を否定する」のではなく「先代が大事にしてきた基準を、形にして残す」という文脈で説明すると、抵抗感が和らぐことが多い。

一方で、伝え方を工夫しても、決定権の所在という核心部分は曖昧にしてはならない。「相談はするが、決めるのは自分」という一線を、態度と言葉の両方で一貫させることが、中長期的には先代からの信頼にもつながる。

仕組み化のやりすぎに気をつける

冒頭で触れた注意点に戻る。ここまで3層構造での仕組み化を説明してきたが、これを厳密にやりすぎると、今度は先代の経営スタイルが持っていた「決めるのが速い」という長所を失うことになる。

特に、小規模な投資判断（月次のツール利用料、数万円程度の備品的なソフトウェア導入など）まで、層1〜3をフルセットで回そうとすると、現場は「稟議を出すのが面倒だから、システム化を諦めよう」という後ろ向きな判断に流れてしまう。これでは本末転倒だ。

現実的な運用としては、金額や影響範囲に応じて「決裁のレベル」を分けておくとよい。

• 少額・影響小（例: 月額数千円〜数万円のツール、部門内で完結する範囲）：現場責任者の判断で導入可、事後報告のみ
• 中額・部門をまたぐ影響（例: 業務システムの一部改修、複数部署が使うツールの導入）：層1のテンプレートを簡易版で記入し、社長が最終判断
• 高額・全社的な影響（例: 基幹システムの刷新、大型のベンダー契約）：層1〜3をフルセットで実施し、必要に応じて専門家の意見も仰ぐ

この線引きの金額は、会社の規模や資金繰りの状況によって変わるため、まずは仮の金額を決めて運用し、数ヶ月試してから調整する、というくらいの気軽さで始めてよい。最初から完璧な制度を作ろうとせず、次に扱う1件の投資案件から新しい決め方を試すのが、現実的な着地点になる。目安として、月商や年間のIT関連支出の規模から逆算し、「これくらいなら現場判断で構わない」という金額を仮決めしてみると、線引きが具体的にイメージしやすくなる。

先代時代と仕組み化後で何が変わるか

イメージを掴みやすくするため、先代時代の意思決定と、仕組み化後の意思決定を並べて整理する。

この比較表からも分かる通り、仕組み化の目的は「遅くする」ことではなく「再現性を持たせる」ことにある。先代の即決の速さのうち、小口案件については現場判断の形で維持しながら、中〜高額の案件には再現可能なプロセスを組み込む、というのが現実的なバランスだ。この線引き自体が、承継後の会社の「新しい意思決定文化」の土台になっていく。

実際に手を動かす: 次のIT投資案件で試す

理屈が分かっても、実際にどこから手をつければよいか迷う場合は、次に検討しているIT投資案件（あるいは検討し始めたばかりの案件）を1つ選び、それを題材に層1〜3を書き出してみることをおすすめする。

まず、その案件について「目的」「費用対効果の目安」「緊急度」「既存システムとの関係」「撤退条件」を、A4用紙1枚程度の分量で書き出してみてほしい。次に、その案件について意見を聞くべき相手を2〜3人リストアップする。最後に、最終的に誰が・いつまでに決めるかを自分の中で決めておく。

これだけで、これまで「なんとなく検討している」状態だった案件が、他の人にも説明できる形に整理される。この1件がうまく回れば、それをテンプレートとして、次の案件からも同じ流れを使い回せばよい。

書き出す際のチェックリストとして、次の5項目を使ってほしい。

1. この投資は「守り」（リスク回避・法対応など）か「攻め」（売上・効率化）か、目的を一言で言えるか
2. 投資額に対して、何をもって「うまくいった」と判断するかの基準を決めたか
3. 現場の実務担当者に、実際に使う立場としての意見を聞いたか
4. 既存のシステムやベンダー契約と競合・重複しないか確認したか
5. 期待した効果が出なかった場合、いつの時点で見直すかを決めたか

この5項目にすべて答えられる状態になっていれば、その案件は「先代の勘」に頼らずに、他の人にも説明できる形で意思決定できている証拠になる。逆に、答えられない項目があれば、決裁の前にそこを埋める作業が、そのまま今回の仕組み化の実践になる。埋められなかった項目こそが、これまで先代任せになっていた部分そのものだと捉えるとよい。

よくある質問

Q. 先代がまだ会長として社内にいる場合、IT予算の説明はどのタイミングで行うべきですか。 A. 正式な決裁権が自分に移っているなら、決裁前に一度目を通してもらい意見を聞く場を設けるとよい。先代の経験を活かしつつ、決定権が自分にあることも自然に示せる。

Q. 判断基準のテンプレートは、どこまで細かく作り込むべきですか。 A. 最初から完璧なテンプレートを目指す必要はない。まずは「目的・費用対効果の目安・緊急度・既存システムとの関係・撤退条件」の5項目程度から始め、実際に案件を通す中で過不足を調整していけば十分だ。

Q. 相談する相手を増やすと、決裁が遅くなりませんか。 A. 相談と決裁を分けて設計すれば遅くならない。相談は判断材料を集める工程であり、最終的な決裁権は一人に一本化しておくことで、合議制のような遅延は避けられる。

Q. 古参の役員に反対されたら、どう対応すればよいですか。 A. まず反対の理由が「過去の失敗経験に基づくもの」か「変化そのものへの不安」かを見極めたい。前者であれば層1の判断材料に組み込み、後者であれば決定権の所在を示しつつ、段階的に進める姿勢を丁寧に伝えることが有効だ。

小さな投資判断の練習台としては、無料で始められる自動化ツールも向いている。Power Automateで先代の定型業務を無料で自動化する入門がその一例だ。

まとめ: 承継後にあなたが持ち帰れること

この記事を通じて、次の2点を自分の会社に当てはめて判断できるようになったはずだ。

• 自社のIT投資の決め方が、先代個人の勘と人脈に依存した「属人的な意思決定」になっていないかどうかの見極め方
• それを仕組みに変える際に、①判断材料②相談先③決裁権の3層に分けて設計し、金額に応じて濃淡をつけるという具体的な進め方

いきなり全社的な制度改革をする必要はない。まずは今抱えている1件の投資案件で、この記事のテンプレートを使って書き出してみてほしい。そこで「意外と自分の中でも判断基準が曖昧だった」と気づくことができれば、それがこの記事から持ち帰るべき最大の収穫だ。

もし、この整理を自分だけで進めるのが難しく、社内システム全体の現状把握や、外部の目線での判断材料の整理から相談したい場合は、承継後のIT刷新を専門に扱う外部の相談先を検討するのも一つの手だ。まずは今検討している案件を1枚の紙に書き出すところから、始めてみてほしい。

なお、意思決定の仕組み化を進める過程で、そもそも会社にどんなシステムやベンダー契約が存在するのかが正確に把握できていないと気づくことも多い。その場合は、「触ると壊れる」と先代に言われ続けたシステムを調査する順番や、承継したらまず作る、システム管理台帳のテンプレートを先に読み、現状把握を先に済ませておくと、この記事のテンプレートに書き込む内容の精度が上がる。逆に、判断材料と相談先が整理できた後、具体的な予算組みと稟議書の作成に進む段階では、承継社長のためのIT予算の作り方と、先代・古参役員への説明方法とIT導入の稟議書の書き方、非IT出身の決裁者に伝わるテンプレートを合わせて参照してほしい。この3本と合わせて読むことで、「現状把握 → 決め方の設計 → 予算化 → 稟議」という一連の流れが一通りカバーできる。