IT導入の稟議書が承認されないとき、原因のほとんどは「機能」や「価格」の説明不足ではない。決裁者が本当に知りたいのは、「これをやらなかったら何が起きるのか」「元は何年で取れるのか」「もし失敗したらどうなるのか」の3点であり、稟議書がこの3点に答えていないから止まるのである。とくに二代目・三代目経営者が決裁者になる場面では、書き手自身が「先代なら通してくれたはずのロジック」と「非IT出身の決裁者が実際に知りたいロジック」のズレに気づかず、機能一覧を並べただけの稟議書を出してしまいがちだ。本記事では、そのズレを解消するための稟議書テンプレートと、承継期の会社特有の書き方の工夫を、実際の項目立てまで含めて解説する。

こんな人に向けて書いている。親の代からの中小企業を継いで数年、経理や現場のITツールを入れ替えたいが、稟議書をどう書けば会長や古参の専務に「うん、いいだろう」と言ってもらえるか分からない人。過去に一度、稟議書を出して「本当に必要なのか」「今のままでいいんじゃないか」と突き返された経験がある人。IT導入補助金の申請書は書けても、社内向けの稟議書は勝手が違うと感じている人。そうした読者を念頭に、機能説明ではなく「意思決定に必要な情報」を軸にした書き方を示していく。

なぜIT導入の稟議書は非IT出身の決裁者に刺さらないのか

多くの人がまず犯す間違いは、稟議書を「提案書」として書いてしまうことだ。提案書は良さを伝える文書であり、稟議書は判断を仰ぐ文書である。この違いを取り違えると、書き手は無意識に「このシステムは素晴らしい」という説得のロジックを積み重ねてしまい、決裁者が本来知りたい「リスクとコストの全体像」が抜け落ちる。

とくに事業承継後の会社では、この齟齬が増幅されやすい。日本政策金融公庫総合研究所が中小企業経営者へのインタビュー調査をもとに行った研究では、経営者のIT活用経験の有無によってIT導入を意識するきっかけが異なり、中小企業のIT経営を推進するには「経営者にITの価値を認識させること」「導入後のイメージを想起させること」が重要だと結論づけられている(日本政策金融公庫総合研究所, 2024)。つまり非IT出身の決裁者にとっては、機能の説明よりも「導入した後、自分の会社がどう変わって見えるか」を具体的に想像できることの方がはるかに重要だということだ。先代や現会長がまさにこのタイプの決裁者であることは多く、「クラウド」「API連携」「SaaS」といった単語を並べるだけの稟議書では、判断材料として機能しない。

もう一つの構造的な問題は、稟議という仕組み自体が、単一の説明相手ではなく複数の承認者を順に通していく前提で作られていることだ。経理担当が最初に見て、次に現場の部長が見て、最後に社長や会長が判子を押す。この経路のどこかに非IT出身者がいると、そこで稟議は止まる。機能を理解できないから止まるのではなく、「自分が承認したことの責任を負えるかどうか」を判断する材料が文書の中にないから止まるのだ。稟議書の設計思想を「説得」から「判断材料の提供」に変えるだけで、通過率は大きく変わる。

もう少し具体的に考えてみる。仮に、あなたが会社の請求書業務をクラウド請求書ソフトに切り替えたいとして、稟議書に「請求書発行業務をクラウド化し、月次の作業時間を削減する」と書いたとする。この文章自体は間違っていない。しかし、非IT出身の決裁者がこれを読んだときに頭に浮かぶのは、「今の担当者はどうなるのか」「クラウドというのは結局どこにデータが置かれるのか」「もし止まったら請求ができなくなるのではないか」という、書き手が想定していない別の疑問である。書き手は「効率化」という結論を先に持っているが、決裁者は「効率化の前に安全性と継続性を確認したい」という順番で考えている。この順番のズレに気づかず、効率化のメリットだけを重ねて説明してしまうことが、稟議が止まる最大の理由だと言ってよい。

同じ現象は、稟議書の文体そのものにも表れる。IT業界の用語に慣れた書き手は「オンプレミスからクラウドへの移行」「API連携によるデータの一元化」といった表現を当たり前のように使うが、非IT出身の決裁者にとっては、そのひとつひとつの単語が「知らない言葉が出てきた」という警戒信号になる。警戒信号が3つ4つと積み重なると、決裁者は文書全体の理解を放棄し、「よく分からないから、とりあえず保留にしよう」という判断に落ち着く。これは決裁者の能力の問題ではなく、書き手が読み手の前提知識を見誤っているだけの話であり、稟議書の中で使う言葉を徹底的に平易にするだけで解決できる問題でもある。

決裁者が本当に見ている3つの論点

論点1: やらなかった場合に何を失うか

非IT出身の決裁者がIT導入稟議書で本当に見ている3つの論点を整理した図。

非IT出身の決裁者が最も重視するのは、実は「導入することの利点」ではなく「導入しないことの損失」である。これは行動経済学的にも説明できる現象だが、実務的な言い方をすれば「今のままでも会社は回っている」という事実がある限り、新しい支出を承認する強い理由が生まれないということだ。

したがって稟議書の冒頭では、現状のオペレーションで実際に発生している損失やリスクを、金額や時間に換算して明示する必要がある。「エクセルの請求書作成に毎月20時間かかっている」「手作業の在庫確認で年間3回、欠品による受注ロスが発生している」といった具体的な事実を積み重ねることで、決裁者は初めて「このままでいいわけではない」と認識する。ここで抽象的な「業務効率化のため」という表現を使うと、決裁者の頭の中では「今のままでも困っていない」という現状維持バイアスに勝てない。

この現状維持バイアスは、承継後の会社ほど強く働く傾向がある。先代が長年築いてきたやり方は、これまで会社を潰さずに存続させてきたという実績を持っている。したがって、そのやり方を変えるという提案は、実績のある方法を否定するかのように響いてしまう。ここで書き手が意識すべきなのは、「今のやり方が間違っている」という論調を避け、「今のやり方の限界値に到達しつつある」という論調に切り替えることだ。台帳を作って現状を可視化しておくと、この「限界値」を数字や事実で示しやすくなる。台帳の作り方は承継したらまず作る、システム管理台帳のテンプレートにまとめてある。たとえば「創業当初は取引先が20社だったが、今は80社に増えた。20社を前提にした手作業の管理方法が、80社という規模に対応できなくなってきている」という書き方であれば、過去のやり方そのものは否定せず、規模が変わったことによる限界だけを指摘できる。決裁者である先代や会長は、自分たちが作った仕組みを否定されたと感じない限り、変化そのものには意外と冷静に対応できることが多い。

またこの論点を書くときには、損失やリスクを「会社全体」の言葉で語るよりも、「特定の担当者」の言葉で語った方が響きやすいという実務上のコツもある。「業務効率が落ちている」という抽象的な表現ではなく、「経理の田中さんが毎月月末の3日間、請求書の突き合わせだけで残業している」というように、実在する担当者の負荷として描写すると、決裁者は自分が知っている社員の顔を思い浮かべながら読むことになり、他人事ではなく身近な問題として受け止めやすくなる。中小企業では社長や会長が社員一人ひとりの顔と名前を知っていることが多いため、この描写の効果はとくに大きい。

論点2: 投資はいつ回収できるのか

2つ目の論点は投資回収の期間である。中小企業庁が公募している「デジタル化・AI導入補助金2026」の制度趣旨でも、対象となるITツール導入の目的は明確に「労働生産性の向上」と定義されており、採択のためには導入後にどれだけ生産性が向上するかを数値計画として示すことが求められている(中小企業庁, 2026)。これは補助金申請の場面だけの話ではなく、社内稟議でもまったく同じ理屈が通用する。決裁者は「このシステムを入れると、何ヶ月で元が取れるのか」という一点に強い関心を持っている。稟議に載せる前に社内のIT資産を一度洗い出しておくと、比較対象や現状コストの根拠が示しやすくなる。洗い出しの手順は非IT出身の承継社長のためのIT資産管理の始め方にまとめてある。

予算全体をどう組み立てるかという上流の話は承継社長のためのIT予算の作り方と、先代・古参役員への説明方法で扱っているので、稟議の前段階として合わせて読んでおくとよい。回収期間の算出は難しく考える必要はない。導入コスト(初期費用+月額費用×12ヶ月分)を、削減できる人件費や損失回避額で割るだけでよい。仮に月10万円のコストで、月30時間の作業時間が削減され、その時間の人件費換算が1時間3,000円だとすれば、月9万円の効果となり、ほぼ数ヶ月で投資額に近づいていく計算が示せる。この数字が多少粗い試算であっても、「回収の見立てがある」という事実そのものが、決裁者の不安を大きく下げる。

ここで注意したいのは、投資回収の計算を「時間削減」だけに寄せすぎないことである。非IT出身の決裁者は、時間の削減を人件費に換算されることに対して、案外冷淡な反応を示すことがある。「時間が減っても、その分の人件費が実際に減るわけではない」という反論は、経営の現場感覚としては正しい指摘だからだ。パートタイムの時給制の担当者であれば時間削減はそのままコスト削減に直結するが、正社員の場合、単純作業が減った時間は別の業務に振り替わるだけで、給与そのものは変わらない。この点を書き手が理解していないと、「時間が減る」という説明に対して「でも人件費は変わらないだろう」と切り返され、稟議が止まる。

この反論への対策は、時間削減の効果を「その時間で何ができるようになるか」まで一歩具体化して書くことだ。「月30時間の作業時間が減れば、その時間を新規顧客への提案書作成に使えるようになり、成約率が現状のままでも年間で〇件の新規受注機会が生まれる」という書き方であれば、単純な時間削減の話ではなく、売上や成長の話に変換できる。あるいは「その時間分、パートタイムの追加雇用を見送れる」という表現であれば、将来の人件費増加を回避できるという文脈で語ることができる。決裁者にとって重要なのは「時間が減る」という事実そのものではなく、「その先に会社にとって良いことが起きる」という筋道が見えることである。

もう一つ、投資回収を考える際に見落とされがちな観点として、ミスやクレーム対応にかかっているコストがある。手作業のオペレーションでは、入力ミスや伝達漏れによる再作業、取引先へのお詫びや信用の損失といった、直接の人件費以外のコストが発生している。これらは金額換算しづらいが、稟議書の中では「昨年度、入力ミスによる再発行が〇件発生し、そのたびに担当者が半日ほど対応に追われている」というように、頻度と作業時間で示すことができる。投資回収の見立てを「時間削減」「売上機会」「ミス防止」の3方向から積み上げると、決裁者にとっての説得力は単純な時間削減の試算よりも格段に高くなる。

論点3: 失敗したときにどこまで戻れるか

3つ目の論点は失敗時のリスクの大きさである。非IT出身の決裁者が新しいシステム導入に慎重になる最大の理由は、「入れてみたら使えなかった」という事態を想像できないことではなく、逆に「入れてみたら使えなかったときに、どれだけ後戻りできないか」を想像してしまうことにある。長年紙とエクセルで運用してきた会社であれば、その不安はなおさら強い。

この不安に対しては、契約形態そのものに答えを持たせるのが最も効果的だ。買い切り型のオンプレミス導入ではなく、月額契約のクラウドサービス(SaaS)を選定できるのであれば、「合わなければ翌月で解約できる」という事実を稟議書に明記する。あるいは無料トライアル期間や、一部門だけで試すスモールスタートの提案を稟議書に組み込むことで、決裁者は「一度の判断で全社の運命を決める」という重圧から解放される。この「引き返せる設計になっている」という一文があるだけで、承認のハードルは大きく下がる。

失敗時の戻し方を考える上で、もう一つ重要な観点がある。それは「データが人質に取られないか」という点だ。非IT出身の決裁者が最も嫌う事態は、あるシステムに慣れてしまった後で、そのシステムの提供会社が値上げをしたり、サービスを終了したりした際に、自社のデータを取り出せなくなることである。これは決裁者の思い込みではなく、実際に中小企業のIT活用においてよく指摘される懸念でもある。稟議書には、契約前に確認したエクスポート機能の有無や、データ形式(CSVやExcel形式での書き出しが可能かどうか)を一文入れておくと、この懸念を先回りして解消できる。「仮にこのサービスをやめることになっても、蓄積したデータはCSV形式で全て取り出せることを契約前に確認済み」と書かれているだけで、決裁者は「最悪の事態でも会社の資産は守られる」という安心感を持つことができる。

また、スモールスタートを提案する際には、「どの部署から始めるか」「いつ全社展開の判断をするか」という2点を具体的に書いておくことが望ましい。「まず経理部門のみで3ヶ月試験運用し、月次の作業時間削減が実際に確認できた場合に、営業部門への展開を検討する」というように、判断のタイミングと基準を先に決めておくことで、稟議書自体が「なんとなく始めて、なんとなく続ける」という曖昧な状態に陥ることを防げる。決裁者からしても、次の判断ポイントがあらかじめ明示されている提案は、白紙委任を求められている提案よりもはるかに承認しやすい。

非IT出身の決裁者に伝わる稟議書テンプレート

以上の3論点を踏まえたテンプレートの項目立てを以下に示す。各項目は長くなくてよい。むしろ箇条書きと数字を多用し、1画面で全体像がつかめる密度にすることが重要だ。

非IT出身の決裁者に伝わる稟議書のテンプレート構成を俯瞰する概要図。

1. 件名 「〇〇業務のクラウド化について(伺い)」のように、対象業務を明確にする。「システム導入の件」のような曖昧な件名は、決裁者に「また新しい話か」という警戒感を与えるため避ける。

2. 現状の課題(数字で) 現在の業務にかかっている時間、発生しているミスやロスの件数、それによる金額換算の損失を3行以内で書く。ここで感覚的な表現(「非効率だと感じる」等)を使わず、必ず数字を先に置く。

3. 導入したいツールと概要 ツール名、提供会社、機能の要点を3点までに絞る。機能を列挙しすぎると、決裁者は逆にリスクの多さを感じて及び腰になる。「これだけできれば十分」という絞り込みの姿勢を示すことが、むしろ信頼につながる。

4. コストの全体像 初期費用、月額費用、年間費用の3段で明記する。ここで「初年度だけ補助金でいくら軽減される」という書き方をすると、2年目以降の実質負担が見えにくくなり、後で「思っていたより高い」という不満につながる。初年度と2年目以降の費用を分けて書くのが鉄則である。

5. 投資回収の見立て 削減できる時間・人件費・損失回避額を根拠に、何ヶ月・何年で投資額に見合うかを示す。前提条件(時給換算のレート、削減時間の算出方法)も併記し、「この数字はどこから来たのか」を決裁者が自分で追えるようにする。

6. 失敗した場合の戻し方 契約期間、解約条件、データの持ち出し(エクスポート)可否を明記する。「合わなかったら〇ヶ月で元の運用に戻せます」という一文を必ず入れる。

7. 導入スケジュールと責任者 誰がいつまでに何をするかを示す。IT担当者がいない会社であれば、「自分(申請者)が責任者として最後まで運用に乗せる」という一文を入れることで、決裁者は「誰も面倒を見ない放置システム」への懸念を払拭できる。

8. 承認欄 役職順に承認印・確認日を並べる。承継後の会社であれば、会長や先代の確認欄をあえて明示的に設けておくことで、後から「聞いていない」と言われる事態を防げる。

テンプレートの記入イメージ(製造業の例)

抽象的な項目説明だけでは実際の書き方が分かりにくいため、従業員35名の金属加工業を想定した記入イメージを示す。実際の稟議書はもっと簡潔でよいが、各項目にどの程度の粒度で数字を入れるかの参考にしてほしい。

件名は「受注管理業務のクラウド化について(伺い)」とする。現状の課題は「受注情報を紙の受注書とエクセルの二重管理で運用しており、月末の集計作業に担当者2名でのべ40時間を要している。過去1年間で入力の転記ミスが5件発生し、そのうち2件は納期の誤認識による取引先への迷惑につながった」と書く。導入したいツールは「受注管理システム〇〇(提供会社名)。紙の受注書をスマートフォンで撮影するとデータ化される機能、在庫と連動した納期の自動計算機能、取引先ごとの受注履歴の一覧表示機能の3点に絞って導入する」とする。

コストの全体像は「初期費用15万円、月額費用は利用人数5名までのプランで3万円、年間では初年度51万円、2年目以降は36万円」と数字を段で示す。投資回収の見立ては「月40時間の集計作業が月10時間に短縮される想定。削減される30時間を担当者の時給換算(2,500円)で計算すると月7.5万円の効果。加えて、転記ミスによる取引先対応の時間(月平均5時間、時給換算で1.25万円相当)も削減対象と見込む。合計で月8.75万円の効果があり、初期費用を含めても7ヶ月弱で投資額に見合う計算になる」とする。失敗した場合の戻し方は「契約は月単位、初期費用を除き最低利用期間の縛りはない。受注データはCSV形式でいつでも書き出し可能なことを契約前に確認済み。3ヶ月試験運用し、効果が見えなければ紙とエクセルの運用に戻すことも可能」と明記する。

テンプレートの記入イメージ(卸売業の例)

もう一つ、従業員18名の食品卸売業を想定した記入イメージも示しておく。業種によって課題の質は変わるが、書き方の骨格は変わらないことが分かるはずだ。

件名は「請求書発行業務のクラウド化について(伺い)」。現状の課題は「取引先120社への請求書を毎月手作業でエクセル作成しており、経理担当1名が月末3日間、他の業務を止めて対応している。過去には請求書の送付漏れが年2回発生し、支払いサイトのずれによる取引先からの問い合わせにつながった」とする。導入したいツールと概要は「クラウド請求書サービス△△。取引先情報の登録による自動請求書作成機能、郵送代行機能、送付状況の一覧管理機能の3点」。コストの全体像は「初期費用0円、月額費用は取引先数に応じた従量課金で月2万円前後、年間では約24万円」。投資回収の見立ては「月24時間かかっていた作成作業が月4時間に短縮される想定。削減される20時間を時給換算(2,200円)すると月4.4万円の効果。加えて郵送代行により切手代・封筒代等の実費が月8千円程度削減される。合計で月5.2万円の効果があり、月額費用を上回る」とする。失敗した場合の戻し方は「月契約のため、合わなければ翌月末で解約可能。請求データはExcel形式で全件エクスポートできることを事前に確認済み」とまとめる。

これら2つの例に共通しているのは、数字の精度そのものよりも、「どの前提でその数字が出てきたか」を隠さずに書いている点である。稟議書を読む決裁者は、数字が完璧に正確であることよりも、数字の根拠を自分で検証できることを重視する。多少粗い試算であっても、前提条件が明記されていれば、決裁者は「この数字はそれなりに信頼できそうだ」と判断できる。

承継期の会社特有の書き方の工夫

事業承継後の会社で稟議書を通す際には、一般的なテンプレートに加えて配慮すべき点がいくつかある。

まず、先代がまだ会長や顧問として社内に残っている場合、その存在を無視した稟議は通りにくい。ある事業承継の実務解説では、先代が会長や顧問として残っている会社では、二代目社長が新しい方針を示しても、社員がまず先代の反応を確認しようとし、「会長にも確認したか」という一言で新しいシステムの導入提案が停滞するケースが指摘されている(プロデュース, 2024)。これは書き手の説明が悪いからではなく、組織の意思決定の慣性がそうなっているからだ。対策としては、稟議書を回す前に、先代・会長には別途、口頭または短いメモで「相談」の体裁で先に見せておくことが有効である。稟議書という正式なルートに乗せる前に、非公式な合意形成を済ませておくことで、稟議書自体はスムーズに通過する。

次に、古参の社員が経理や現場の承認ルートに入っている場合は、「今までのやり方を否定された」と受け取られないような書き方を意識する。「今のやり方が悪いから変える」ではなく、「今のやり方を支えてきた仕組みに、負荷がかかりすぎている部分を補強する」という表現に変えるだけで、受け取られ方が変わる。たとえば「請求書を手作業で作ってきたことが会社を支えてきたが、取引件数が増えた今、その作業量が担当者一人に集中しすぎている」という書き方であれば、過去の努力を否定せずに、変化の必要性だけを伝えられる。

さらに、IT導入補助金を活用する場合は、稟議書と補助金の申請書を完全に別物として扱わない方がよい。中小企業庁の「デジタル化・AI導入補助金2026」では、IT導入支援事業者とのパートナーシップのもとで事業計画を策定し、交付申請から事業完了報告までの流れが定められている(中小企業庁, 2026)。この申請書に書く「労働生産性向上の数値計画」は、そのまま社内稟議の「投資回収の見立て」に転用できる内容であることが多い。つまり補助金申請のために作った数字の根拠を、社内稟議のために二重に作り直す必要はなく、同じ数字を使い回せる。この二重利用の視点を持っておくと、書類作成の負担そのものを減らせる。

加えて、補助金を稟議書の中で扱う際には、書き方に一つ注意点がある。「補助金が出るから実質半額」という説明を前面に押し出しすぎると、決裁者は「補助金頼みの投資」という印象を持ってしまい、逆に慎重になることがある。補助金は採択されるかどうかが事前に確定しているわけではなく、審査を経て決まるものである。稟議書には「補助金の採択を前提とせず、自己負担額での投資回収が成立することを基本とし、採択された場合はさらに回収期間が短縮される」という書き方をしておくと、補助金が不採択になった場合でも決裁の前提が崩れない。この一文があるかないかで、決裁者からの信頼度は大きく変わる。

最後に、承継期特有の事情として、稟議書を出すタイミングそのものにも配慮が必要である。刷新を年度計画のどのタイミングで組み込むかという論点は、刷新を年度計画に組み込むタイミング、期初と期中どちらで決めるかでも扱っている。事業承継の直後、社長交代からまだ半年や1年しか経っていない時期に大きなIT投資の稟議を出すと、「代替わりしてすぐに会社を変えようとしている」という印象を社内に与えやすい。一方で、承継から数年が経ち、経営者としての実績や社内の信頼が積み重なった後であれば、同じ提案でも受け止められ方は変わる。もちろん業務上の必要性が高い場合はタイミングを待てないこともあるが、緊急性が低い投資であれば、社内での信頼構築が進んだ時期を選ぶという視点も、稟議の通過率に影響することを覚えておきたい。

そもそも、この稟議書のフォーマット以前に「どの案件を、誰に相談し、誰が最終判断するか」という決め方自体が先代の頭の中にしか無いままだと、稟議書を整えても毎回ゼロから判断基準を作り直すことになる。先代がワンマンで決めてきたIT投資。承継後の「決め方」を仕組みに変えるでは、判断材料・相談先・決裁権を3層に分けて仕組み化する考え方を扱っているので、稟議書の運用を安定させたい場合はあわせて読んでおくとよい。

決裁者のタイプ別に効く伝え方の違い

非IT出身の決裁者と一括りにしても、実際には反応のタイプがいくつかに分かれる。稟議書の本文自体は共通のテンプレートで作ってよいが、口頭での補足説明や、事前の根回しの仕方は、決裁者のタイプによって変えた方が通過率が上がる。

決裁者のタイプ(コスト重視型とリスク重視型)によって効く伝え方の違いを対比した図。

一つ目のタイプは「数字重視型」の決裁者である。長年、財務や資金繰りを自分で見てきた経営者に多く、稟議書の中でもコストと投資回収の項目を真っ先に見る。このタイプには、数字の精度と前提条件の透明性が何よりも重要になる。数字に少しでも矛盾や説明不足があると、そこで信頼を失い、他の部分がどれだけ丁寧に書かれていても稟議は止まる。数字重視型の決裁者に対しては、提出前に自分で一度、数字の整合性を電卓で再計算してから出すくらいの慎重さが求められる。

二つ目のタイプは「現場重視型」の決裁者である。自身が現場出身で、社員の顔と日々の業務の大変さを具体的に知っている経営者に多い。このタイプには、数字よりも「誰が今、どう困っているか」という現場の描写が効く。前述した「経理の田中さんが月末3日間残業している」といった具体的な描写は、このタイプの決裁者に特に強く響く。現場重視型の決裁者に数字だけを並べた稟議書を出すと、「机上の理屈だけで現場を分かっていない」という印象を持たれることがあるため、稟議書の冒頭にも現場の具体的な様子を必ず書き込む必要がある。

三つ目のタイプは「関係重視型」の決裁者である。取引先や社内の人間関係、先代との関係性を重視する経営者に多く、このタイプには「このシステムを入れることで、どの取引先や社員との関係がどう変わるか」という視点が重要になる。「取引先からの問い合わせ対応が早くなり、信頼関係の強化につながる」「担当者の負荷が減り、社員の定着率向上に寄与する」といった、関係性への影響を明記することで、このタイプの決裁者の懸念を払拭できる。

自分の会社の決裁者がどのタイプに近いかを見極め、稟議書の中でどの論点を厚く書くかを調整するだけで、同じ投資内容でも通過率は大きく変わってくる。多くの場合、非IT出身の経営者は「現場重視型」と「関係重視型」の要素を併せ持っていることが多いため、数字だけに寄せた稟議書よりも、現場の描写と関係性への影響を織り込んだ稟議書の方が、結果的に承認されやすい傾向がある。

よくある失敗パターンとその回避策

稟議書が差し戻される典型的な失敗パターンをいくつか挙げておく。

失敗1: 機能一覧の丸写し ベンダーの提案書やカタログの機能一覧をそのままコピーして稟議書に貼り付けるケースが最も多い失敗である。機能の網羅性は決裁者の関心事ではない。稟議書に書くべき機能は「自社の課題を解決する機能」に絞り、それ以外は「詳細は別紙資料を参照」として本文から外す。

失敗2: コストの内訳が不透明 「月額〇万円」という一行だけで済ませ、初期費用やオプション費用、将来的な増員時の追加費用に触れない稟議書は、後から「思っていたより高い」という指摘を受けやすい。想定される追加費用のパターンをあらかじめ書いておくことで、後出しの疑念を防げる。

失敗3: 比較検討の跡がない 1社のツールだけを提示し、「なぜこれを選んだのか」の比較軸が書かれていない稟議書は、決裁者に「本当に検討したのか」という疑問を持たせる。最低でも2〜3社を比較し、選定理由を短く書くことで、検討プロセスの信頼性が上がる。

失敗4: 撤退条件が書かれていない 前述の通り、失敗時に元に戻せる設計であることを明示しないと、決裁者は「一度始めたら戻れない」という前提で判断してしまう。契約期間と解約条件は必ず明記する。

失敗5: 責任者が不明確 稟議書に「導入後の運用担当者」が書かれていないと、決裁者は「誰も見ない放置システムになるのでは」という懸念を持つ。申請者自身が運用の最終責任を負う姿勢を明記することが、承認への最短距離になる。

失敗6: 決裁者の懸念を先に潰していない これまでに何度も差し戻された経験がある人ほど、実は過去の差し戻し理由を稟議書に反映していないことが多い。前回「セキュリティが心配だ」と言われたのであれば、今回の稟議書には必ずセキュリティに関する一文を入れる。差し戻しの履歴は、次の稟議書を通すための最も具体的なヒントである。それを無視して同じ構成の稟議書を出し直すと、決裁者は「前回の指摘が反映されていない」という印象を持ち、内容の是非以前に心理的な壁ができてしまう。

失敗7: 稟議書の分量が多すぎる 熱意のある書き手ほど、稟議書を丁寧に書こうとして分量が増えすぎる傾向がある。しかし非IT出身の決裁者は、長い文書を読み切る前に判断を先送りにしてしまうことが多い。稟議書の本文はA4用紙1枚、多くても2枚に収め、詳細な見積書やパンフレットは別紙として添付する形にとどめるのが実務上の目安である。分量を絞る過程で、書き手自身も「本当に伝えるべき情報は何か」を整理でき、結果的に説得力の高い文書に仕上がる。

提出した後のフォローアップも稟議書の一部と考える

稟議書は提出して終わりではない。とくに複数の承認者を経由する社内承認のプロセスでは、提出後にどう動くかが承認のスピードと成否を左右する。

まず、稟議書を提出した直後に、経路上の各承認者に一言、口頭やチャットで「先ほど〇〇の件で稟議を回しましたので、ご確認いただけますと幸いです」と伝えることを習慣にしたい。稟議書は書類として回っていくが、人間は書類だけでは動きが遅くなりがちで、声をかけられることで初めて「早めに見よう」という意識が働く。とくに経理担当や現場の部長が最初の承認者になる場合、この一言があるかないかで、稟議が机の上で数日間眠ってしまうかどうかが変わる。

次に、決裁者から質問や懸念が出た場合には、その場で防御的に反論するのではなく、まず「なるほど、その視点は稟議書に書き切れていませんでした」と受け止める姿勢が有効である。非IT出身の決裁者からの質問は、多くの場合、書き手にとっては当たり前すぎて書かなかった前提を尋ねるものであることが多い。「クラウドというのは結局どこの会社のサーバーにデータが置かれるのか」「担当者が変わったらどうなるのか」といった質問は、IT側の人間には初歩的に見えても、決裁者にとっては本質的な不安である。この不安に丁寧に答え、可能であれば次回の稟議書や補足資料にその回答を反映することで、単に1件の稟議を通すだけでなく、次の稟議も通りやすくなる土台を作ることができる。稟議書の文書そのものではなく、決裁者との交渉プロセスや、反対されたときの切り返し方まで含めて整理したい場合は、刷新の稟議を通す。先代や古参役員が納得する説得材料の作り方も参照してほしい。

さらに、稟議が承認された後には、当初稟議書に書いた投資回収の見立てが実際にどうだったかを、決められたタイミングで検証し、簡単な報告を決裁者に返すことを忘れないようにしたい。「3ヶ月前に稟議を出した際、月30時間の削減を見込んでいましたが、実際には月25時間の削減が確認できました」という報告を自主的に行う人は、次にまた別のIT投資の稟議を出す際に、圧倒的に信頼されやすくなる。稟議書は一度きりの文書ではなく、書き手自身の「言ったことをやり切る」という実績を積み重ねていくための手段でもある。承継期の経営者にとって、この積み重ねは稟議の通過率だけでなく、社内における経営者としての信頼構築そのものにも直結する。

まとめ

IT導入の稟議書で最も重要なのは、機能の魅力を語ることではなく、決裁者が判断に必要とする3つの情報――やらなかった場合の損失、投資回収の見立て、失敗時の戻し方――を、数字と具体的な事実で示すことである。とくに非IT出身の決裁者、あるいは事業承継後の会社で先代や古参社員が意思決定の経路に関わっている場合は、テンプレートの項目立てに加えて、先代への事前の非公式な合意形成、過去のやり方を否定しない表現の選択、補助金申請書との数字の使い回しといった配慮が、稟議の通過率を大きく左右する。

稟議書は説得の文書ではなく、判断材料を渡す文書である。この視点の転換だけで、これまで何度も差し戻されてきた稟議書も、一度で通る文書に変わっていくはずだ。そして、稟議書がうまく通るようになることは、それ自体が目的ではない。承継後の経営者にとって、IT投資の稟議を丁寧に組み立て、その通りに実行し、結果を検証して報告するというサイクルを一つずつ積み重ねることは、社内における「この人の判断は信頼できる」という評価を作っていく過程そのものでもある。最初の1本の稟議書がうまく通ったとしても、それで終わりではなく、その後の実行と報告までを含めて、次のIT投資、そしてその先の経営判断全体への信頼につながっていく。稟議書というありふれた社内文書の中に、実はそれだけの意味が詰まっていることを踏まえて、次の一枚を書いてみてほしい。