情シス予算の作り方と経営層への説明方法

毎年この時期になると気が重くなる、という担当者は多いのではないでしょうか。来期の予算編成のタイミングで「ITにいくら必要か出してほしい」と言われても、根拠のある金額をすぐに積み上げられる人は多くありません。セキュリティ対策やシステム更新は必要だと分かっていても、経営層に説明すると「今すぐ壊れるわけじゃないなら来年でいいのでは」と後回しにされ、翌年また同じ説明を繰り返す——このループに心当たりがある方に向けて、本記事を書きました。

IT予算が通らない最大の理由は、経営層の理解不足だけではありません。多くの場合、予算そのものが「なんとなくの積み上げ」になっていて、経営層が判断できる材料になっていないことが原因です。本記事では、ひとりで情シス・総務を兼任している担当者に向けて、IT予算をどう組み立て、どう説明すれば経営層に伝わるのかを、具体的な手順で解説します。稟議書という個別案件の「文書の書き方」については別記事で詳しく扱っているため、本記事は年間・複数年単位の予算計画そのものの立て方と、経営層への説明の技術に絞って解説します。

結論: IT予算は「金額」ではなく「意思決定の材料」として作る

先に結論を書きます。経営層に伝わるIT予算とは、金額の大小ではなく、判断に必要な材料（何のためにいくら必要で、やらなかった場合に何が起きるか）が揃っている予算です。多くの担当者は「来年はサーバーの更新で〇〇円、セキュリティ対策で〇〇円」という金額の一覧を作って終わりにしてしまいますが、これでは経営層は「高いか安いか」でしか判断できません。

経営層が本当に知りたいのは、次の3点です。

• やらなかった場合に、会社にどんなリスクが残るのか
• そのリスクは、いつまでに対処すれば間に合うのか
• 複数の選択肢（今すぐやる／段階的にやる／様子を見る）のうち、どれを選ぶとどうなるのか

この3点に答えられる形で予算を組み立て、説明することが、IT予算を通すための最短ルートです。以下、具体的な組み立て方と説明の技術を順に見ていきます。

なぜIT予算は経営層に理解されにくいのか

本題に入る前に、IT予算特有の「理解されにくさ」の構造を整理しておきます。原因を理解しておくと、対策も立てやすくなります。

効果が「壊れなかったこと」でしか測れない

セキュリティ対策やバックアップ体制の強化は、効果が発生したときにはじめて価値が分かります。裏を返せば、何も起きなければ「投資が無駄だった」ように見えてしまいます。これは他の設備投資（新しい機械を入れて生産性が上がった、など）と比べて、成果が見えにくい構造的な弱点です。経営層の立場からすれば「去年も対策費を払ったのに、今年も同じ額を要求される」ことに違和感を持つのは自然な反応であり、担当者の説明不足だけが原因とは限りません。

専門用語が多く、リスクの大きさが実感として伝わらない

「ランサムウェア対策として多要素認証（MFA）を導入する」と言われても、IT分野になじみのない経営層にとっては、それがどの程度深刻な話なのか実感を持てません。専門用語を並べるほど、かえって「よく分からないから任せる」か「よく分からないから後回し」のどちらかに振れやすくなります。

単年度の金額だけで判断されがちである

IT投資の多くは、一度導入したら終わりではなく、数年単位で更新・保守費用が発生し続けます。単年度の金額だけを見せると、翌年以降も同水準の費用が発生することが伝わらず、「今年だけ我慢すれば済む出費」だと誤解されたまま予算が通ってしまうことがあります。この誤解は、翌年以降の予算説明を余計に難しくする原因になります。

「今年は特別に頼む」という説明を毎年繰り返している場合、それはIT予算が単年度の思いつきの積み上げになっているサインです。複数年計画として説明し直す必要があります。

IT予算の作り方: 積み上げの前にやるべき棚卸し

予算の金額を積み上げる前に、まず「何にいくらかかっているか・かかる見込みか」を洗い出す棚卸し作業が必要です。この棚卸しを飛ばして金額だけを積み上げると、抜け漏れが起きやすくなります。

ステップ1: 現在稼働中のシステム・契約を一覧化する

社内で使っているシステム、契約しているSaaS、保守契約の内容を一覧化します。すでにシステム管理台帳を作成済みであれば、それを土台に使えます。まだ作成していない場合は、予算編成のタイミングが台帳作成の良い機会になります。一覧には最低限、次の項目を含めます。

ステップ2: 更新・入れ替えが必要な時期を洗い出す

一覧化したシステムのうち、老朽化やEOL（サポート終了）が近いものを洗い出します。特にサーバーやネットワーク機器など、ハードウェアに依存するものは、メーカーのサポート終了時期が明確に決まっているため、逆算して予算化のタイミングを決められます。ソフトウェアについても、開発会社が独自にサポート終了を告知する場合があるため、契約書や導入時の説明資料を確認しておきましょう。

ステップ3: 対策が手薄になっている領域を洗い出す

現状で対策が手薄になっているセキュリティ領域や、属人化して個人の頑張りに依存している業務を洗い出します。優先順位の付け方に迷う場合は、既存記事で解説している考え方が参考になります。この段階では金額を精緻に出す必要はなく、「対策が必要な領域はどこか」をリストアップすることが目的です。

ステップ4: 棚卸し結果を3つに分類する

洗い出した項目を、次の3つに分類します。

1. 維持コスト: 既存システムの保守費・ライセンス費など、やめない限り毎年発生する費用
2. 更新投資: 老朽化・EOL対応など、時期が来たら対応が避けられない費用
3. 新規投資: セキュリティ強化や業務効率化など、任意のタイミングで着手できる費用

この3分類は、後述する経営層への説明で「削れる余地がある項目」と「削れない項目」を区別する土台になります。棚卸しは一度作って終わりにするのではなく、年に1回、予算編成のタイミングで見直す習慣にしておくと、翌年以降の作業負担が大きく減ります。前年の一覧をコピーして、契約状況の変化や新たに老朽化が進んだ項目を追記していくだけで済むようになるためです。

棚卸しを一人で抱え込まないための工夫

ひとりで情シス・総務を兼任している場合、棚卸し作業そのものが後回しになりがちです。すべてを自分の記憶だけで洗い出そうとせず、次のような方法で情報を集めると、抜け漏れを減らせます。

• 経理部門に、IT関連の支払い一覧（会計ソフト上の勘定科目別の一覧など）を出してもらう
• 各部署に、日常的に使っているツール・サービスを簡単なアンケートで確認する（シャドーITの発見にもつながる）
• 契約書やベンダーからの請求書を保管しているフォルダを一通り確認する

特に経理部門との連携は有効です。IT担当者が把握していない小規模な契約（部署ごとに契約しているクラウドサービスなど）が、経理の支払い記録には残っていることがあります。棚卸しや日常運用そのものを自分だけで回しきれないと感じる場合は、情シス代行・アウトソーシングの費用相場と、頼みどころ・頼まないどころの見極めで扱っているように、運用の実務部分だけを外部に切り出すという選択肢も検討してみてください。予算編成のタイミングは、こうした部署間の情報を突き合わせる良い機会でもあります。

金額の積算根拠をどう作るか

棚卸しが終わったら、それぞれの項目に金額を積算します。ここで大事なのは、金額の出どころを説明できる状態にしておくことです。

既存契約は見積書・請求書から積算する

現在契約中のシステムであれば、既存の見積書・請求書・契約書に記載された金額をそのまま使えます。金額の根拠として最も説得力があるのは、実際に支払っている金額そのものです。ただし、更新のタイミングで料金体系が変わる可能性がある契約（ユーザー数課金のSaaSなど）は、現在の利用人数の増減見込みも合わせて確認しておきます。

新規導入は複数社から見積もりを取る

新規導入を検討している場合は、可能な限り複数社から見積もりを取ります。1社だけの見積もりで予算を組むと、経営層から「他と比較したのか」と聞かれたときに答えられず、差し戻しの原因になります。見積もりの取り方や、外部の開発会社に何を伝えればよいかについては、外注・発注に関する記事も参考にしてください。見積書に記載された項目をどう読み解き、経営層への説明に落とし込むかは、システム開発の見積書、どう読む？も参考になります。

相場が分からない場合は概算幅で示す

正式な見積もりを取る前の初期段階で、おおまかな予算感を経営層に伝えたい場合もあるでしょう。その場合、根拠のない金額を断定的に書くのは避け、「〇〇円〜〇〇円程度の幅がある」という形で、幅と前提条件（何を含み、何を含まないか）を明示します。裏付けのない数字を一人歩きさせると、後で見積もりを取った際に金額が食い違い、説明のやり直しが発生します。

補助金の活用余地を確認する

IT導入にあたって、公的な補助制度の活用を検討する場合は、IT導入補助金のように中小企業・小規模事業者向けの制度が用意されていることがあります。対象となるツールや申請要件、補助率・上限額は年度ごとの公募要領で変わるため、予算計画に組み込む際は、申請前に中小企業基盤整備機構（中小機構）が運営する公式サイトで最新の公募要領を必ず確認してください。補助金は申請すれば必ず受給できるものではなく、審査や交付決定の時期によって導入スケジュールに影響が出る場合もあるため、予算計画上は「補助金が採択された場合」と「不採択だった場合」の両方のシナリオを用意しておくと、経営層への説明で慌てずに済みます。

複数年計画にする理由と作り方

単年度の予算だけを提出すると、前述のとおり「今年だけの特別な出費」という誤解を生みやすくなります。IT予算は3〜5年程度の複数年計画として提示することを基本にしましょう。

複数年計画のフォーマット例

次のような表形式で、向こう数年分の見通しを1枚にまとめます。

この形式にすると、経営層は「毎年最低限これだけはかかる」「今年は更新のタイミングが重なって一時的に高い」といった構造を一目で理解できます。単発の金額を見せるより、変動の理由が伝わりやすくなります。

複数年計画のメリット

複数年計画には、経営層への説明のしやすさ以外にも利点があります。

• 更新時期が重なる年を事前に把握し、費用のピークを平準化する調整ができる
• 翌年以降も同種の説明を繰り返さずに済み、担当者の負担が減る
• 経営層が中期的な資金計画に組み込みやすくなる

一方で、複数年計画はあくまで見通しであり、確定額ではありません。市場価格の変動や、想定外のトラブル（レガシーシステムの突発的な故障など）で計画通りに進まないこともあります。計画は「現時点で分かっている前提に基づく見通し」であることを、提出時に明記しておくと、後から金額が変わった際の説明もしやすくなります。

経営層への説明方法: 何を、どの順番で伝えるか

金額の積算ができたら、次は説明の組み立てです。経営層への説明は、稟議書のような文書だけでなく、口頭での説明・会議での資料提示など、複数の場面で行うことになります。どれだけ精緻な積算根拠を用意しても、伝え方の順番を誤ると、経営層は金額の妥当性を判断する前に「よく分からない話」として聞き流してしまいます。ここでは説明の順番と構成を解説します。

説明の基本構成

経営層への説明は、次の順番で構成すると伝わりやすくなります。

1. 現状: 今、何が起きているか・何が老朽化しているか
2. リスク: 何もしなかった場合に何が起きる可能性があるか
3. 選択肢: 対応する場合の選択肢（今すぐ／段階的に／見送り）とそれぞれの結果
4. 推奨案と金額: どの選択肢を推奨するか、その理由と金額
5. やらなかった場合の代替コスト: 対応を先送りした場合に、将来どの程度の費用・リスクが積み上がるか

多くの担当者は3や4から説明を始めてしまいますが、経営層はまず「なぜ今その話をしているのか」という現状とリスクの部分を理解しないと、金額の妥当性を判断できません。順番を守ることが、理解を得るための最初のポイントです。

リスクは「金額換算できるもの」と「できないもの」に分けて説明する

セキュリティ対策の必要性を説明する際、リスクを金額に換算して伝えようとする担当者は多いですが、裏付けのない被害額の試算を出すのは避けるべきです。自社の状況に基づかない一般的な統計を、あたかも自社に当てはまる金額であるかのように示すと、後で根拠を問われたときに説明できなくなります。

金額換算できるリスク（システム停止による営業機会の損失日数など、自社の実績から推定できるもの）と、金額換算が難しいリスク（信用の毀損、取引先からの契約見直しなど）を分けて説明し、後者については「金額では示せないが、発生した場合の影響は大きい」という形で正直に伝えるほうが、かえって信頼されます。

専門用語は言い換えるか、たとえ話に置き換える

経営層への説明では、専門用語をできるだけ避け、業務への影響という言葉に置き換えます。たとえば次のような言い換えが有効です。

• 「EOLを迎える」→「メーカーがこの先、不具合を直してくれなくなる」
• 「単一障害点（SPOF）になっている」→「この1台が壊れたら、関係する業務がすべて止まる」
• 「バックアップの3-2-1ルール（バックアップ）」→「同じ場所に置いたコピーだけでは、火事や盗難で両方とも失う可能性がある」

専門用語を正確に使うことよりも、経営層が自分の言葉で人に説明できる状態まで噛み砕くことのほうが、予算を通すうえでは重要です。

「やらなかった場合」を具体的に描く

経営層の判断を後押しする最も効果的な材料は、「やらなかった場合に何が起きるか」を具体的に描くことです。抽象的に「セキュリティリスクがあります」と言うより、次のように業務への影響を具体的に描くほうが伝わります。

• 「このサーバーが故障すると、受注データにアクセスできなくなり、出荷業務が最短でも〇日は止まります」
• 「このソフトはサポートが切れているため、新しい脅威が見つかっても修正されないまま使い続けることになります」
• 「今のバックアップ体制だと、ランサムウェアに感染した場合、直近のデータを復元できない可能性があります」

具体的な業務影響を描くことで、経営層は「他人事のIT対策」ではなく「自社の業務が止まるかどうかの話」として受け止めやすくなります。

予算が通らないときの調整の仕方

すべての予算が一度で通るとは限りません。特に会社全体の業績が厳しい年や、他部署からも大きな投資要求が重なっている年は、IT予算だけが優先されるとは限らないのが実情です。減額や先送りを求められた場合の調整方法も、あらかじめ考えておくと交渉がスムーズになります。

削れる項目と削れない項目を事前に区分しておく

前述の3分類（維持コスト・更新投資・新規投資）のうち、削減の交渉が可能なのは主に新規投資です。維持コストは既存契約の解約・見直しを伴うため、簡単には削れません。更新投資もEOLなど時期の制約があるため、先送りにはリスクが伴います。予算全体を減額したいという要望が来た場合は、この3分類のどこを削るかを担当者側から具体的に提案できると、交渉が前向きに進みやすくなります。

段階的な導入案を用意しておく

「全部一度にやる」案しか用意していないと、予算超過を理由に全体が見送られるリスクがあります。優先度の高い部分から段階的に導入する案をあらかじめ用意しておくと、経営層が一部だけでも承認するという選択肢を選べるようになります。

たとえば次のような段階分けが考えられます。

• 第1段階: 最も緊急度の高いリスクへの対応（今年度中に必須）
• 第2段階: 業務効率化を伴う投資（来年度以降で調整可能）
• 第3段階: 中長期的な刷新（複数年計画の中で時期を調整）

先送りした場合のコストを記録しておく

予算が見送られた項目については、その決定と理由を記録に残しておきます。翌年、同じ項目を再提案する際に「昨年から先送りしている項目で、この間にリスクが〇〇に高まっている」と説明できると、単なる繰り返しの要求ではなく、状況の変化を踏まえた再提案として伝わります。

説明の場でよくある失敗パターン

予算説明の場で、担当者が陥りやすい失敗にはいくつかの共通パターンがあります。自分の説明がこれに当てはまっていないか、事前にチェックしてみてください。

失敗パターン1: 技術的な正確さを優先しすぎる

IT担当者ほど、説明を正確にしようとするあまり、専門用語や技術的な前提条件を丁寧に説明しようとしがちです。しかし経営層が知りたいのは技術的な正確さではなく、経営判断に必要な結論です。「厳密に言うと〇〇なのですが」という前置きを重ねるほど、聞き手は要点を見失います。技術的な正確さは、質問されたときに答えられる形で手元に用意しておき、説明そのものは結論から簡潔に伝えることを優先しましょう。

失敗パターン2: すべてのリスクを同じ重さで伝える

軽微なリスクと重大なリスクを同列に並べて説明すると、聞き手はどれが本当に重要なのか判断できなくなります。説明の場では、最も優先度の高いリスク（対応しないと業務が止まる、法令違反になるなど）と、それ以外のリスクを明確に区別し、時間配分にもメリハリをつけます。すべてを均等に説明しようとすると、かえって一番伝えたいことが埋もれてしまいます。

失敗パターン3: 「他社もやっている」だけを根拠にする

同業他社の事例やIT業界の一般的な動向を引き合いに出すこと自体は有効な補強材料になりますが、それだけを根拠にすると「うちはうち」という反応を招きやすくなります。他社事例はあくまで補強材料として位置づけ、主たる根拠は自社の状況（現状のリスク・業務への影響）に置くことが重要です。

失敗パターン4: 一度の説明で終わらせようとする

大きな金額の投資であるほど、一度の説明で即決を求めるのは現実的ではありません。初回の説明では情報を提示して検討の土台を作り、質問や懸念点を持ち帰って次回までに回答を用意する、という複数回のやり取りを前提にしたほうが、結果的に承認までの時間が短くなることがあります。即決を焦って情報を詰め込みすぎると、かえって判断材料が多すぎて結論が先送りされる場合もあります。

経営層のタイプ別に説明の重点を変える

経営層といっても、意思決定のスタイルは人によって異なります。相手のタイプに合わせて、説明の重点を調整すると伝わりやすくなります。

• 数字重視型: 投資対効果、削減できるコスト、複数年の総額を明確に示すことを優先します。感覚的な説明より、表やグラフでの提示が効果的です。
• リスク重視型: やらなかった場合に何が起きるか、他社の被害事例（一般論として）、法令や取引先からの要求といった外部要因を厚めに説明します。
• 現場重視型: 実際に業務がどう変わるか、現場の担当者がどう楽になるか、日々の業務フローへの影響を具体的に描写します。

同じ会社でも決裁ルートに複数の承認者が関わる場合は、全員に同じ説明を一律にするのではなく、それぞれの関心に応じて強調点を変えた資料を用意すると、全員の納得を得やすくなります。ただし、事実として提示する数字やリスクの内容自体は、相手によって変えてはいけません。強調する部分を変えるのと、伝える事実を都合よく変えるのはまったく別の話です。

会社の規模によって予算計画の粒度を変える

すべての会社が同じ精度の予算計画を作れるわけではありません。会社の規模や、情シス担当者にかけられる工数に応じて、計画の粒度を調整することも実務上は必要です。

小規模な会社で、予算編成にかけられる時間が限られている場合は、最初から精緻な複数年計画を目指す必要はありません。まずは「今年度、最低限これだけは必要」という単年度の積み上げから始め、翌年以降、少しずつ複数年の見通しを付け加えていくという段階的なアプローチでも構いません。完璧な計画を初年度から作ろうとして手が止まってしまうより、粗くても毎年更新し続けられる計画のほうが、長期的には経営層との信頼関係の構築に役立ちます。

一方で、従業員数が増え、システムの数や契約金額が大きくなってきた会社では、棚卸しの精度を上げ、複数年計画の前提条件（利用人数の増減見込み、契約更新のタイミングなど）をより具体的に記録しておく必要が出てきます。会社の成長に合わせて、予算計画の作り方自体も見直していく意識を持っておくとよいでしょう。

稟議書との違い: 予算計画と個別案件の書き分け

ここまで解説してきた予算計画と、個別のIT導入案件で作成する稟議書は、役割が異なります。予算計画は年間・複数年単位で「何にどれだけ使うか」の全体像を経営層と合意する文書であり、稟議書は個別の案件について「この案件を実行してよいか」の承認を得る文書です。

年間の予算計画があらかじめ経営層に共有・承認されていれば、個別の稟議を起案する際に「これは年初に合意した予算計画の一部です」と説明でき、稟議が通りやすくなります。逆に、予算計画がないまま個別の稟議を積み重ねていくと、そのたびに「なぜ今この金額が必要なのか」をゼロから説明することになり、担当者の負担が増えます。個別案件の稟議書の具体的な書き方については、テンプレート付きの別記事で詳しく解説していますので、あわせて参考にしてください。

まとめ: IT予算は「毎年出す」ものから「積み上げる」ものへ

IT予算の作成と説明は、単年度で完結する作業ではありません。棚卸しに基づいた積算根拠を作り、複数年の見通しを示し、経営層が判断できる材料（現状・リスク・選択肢）を揃えて説明する、という一連の流れを毎年繰り返すことで、少しずつ経営層の理解と信頼を積み上げていくことができます。

最初の年は思うように予算が通らないこともあるかもしれません。それでも、棚卸しの記録や複数年計画を毎年更新し続けることで、翌年以降の説明はより具体的で説得力のあるものになっていきます。IT予算の作成は、一度で完成させるものではなく、年々改善していくプロセスだと捉えて取り組んでみてください。

次のステップとして、個別のIT導入案件が決まったら、稟議書の作成に進むことになります。年間の予算計画で合意した内容を、個別案件の稟議にどうつなげるかについては、次の記事で具体的なテンプレートとあわせて解説しています。予算計画と個別稟議は別々の文書ですが、両方を連動させて運用することで、初めて経営層との合意形成が積み重なっていく点を、最後にあらためて強調しておきます。