IT導入の稟議書の書き方（テンプレート付き）

「このツール、うちの部署で使いたいので導入したいです」——そう口頭で伝えただけで稟議が通った経験がある人は、おそらくいません。IT導入の稟議書は、決裁者がITに詳しくない中小企業ほど、書き方ひとつで通る・通らないが分かれます。金額の大小に関わらず、なぜ今それが必要なのか、他の選択肢では駄目なのか、リスクはどう抑えるのかを、決裁者が自分の言葉で説明できるレベルまで落とし込んで初めて、稟議は前に進みます。

本記事では、ひとりで情シス・総務を兼任している担当者に向けて、IT導入の稟議を通すための書き方を、テンプレートと具体例つきで解説します。稟議書という「文書そのものの書き方」に絞って解説するため、社内の説得材料の作り方や交渉の進め方について詳しく知りたい方は、外注・発注に関する別記事もあわせて参考にしてください。

結論: 稟議書は「決裁者の疑問に先回りして答える文書」である

先に結論を書きます。通る稟議書と通らない稟議書の違いは、文章のうまさではありません。決裁者が読みながら思い浮かべるであろう疑問——「なぜ今なのか」「いくらかかるのか」「他に手はないのか」「失敗したらどうなるのか」——に、本文を読み進める中で自然に答えが用意されているかどうかです。

逆に言えば、稟議が差し戻される理由の大半は、書き手が「自分にとって自明なこと」を書き漏らしていることに起因します。現場で日々そのツールの必要性を感じている担当者にとっては当たり前でも、決裁者にとっては初めて見る情報です。この前提のズレを埋める作業こそが、稟議書作成の本質です。

以下、稟議書に必要な7つの要素と、それぞれの書き方を順番に解説していきます。

稟議書とは何か: 「起案」から「決裁」までの社内手続き

まず稟議という制度そのものを簡単に確認しておきます。稟議は、担当者が起案書を作成し、関係する上長・部門の承認を順番に得たうえで、最終的な決裁者の承認を得る社内手続きです。担当者が最初に文書を作成する行為を「起案」、それが最終決裁者の承認を得ることを「決裁」と呼びます。

稟議制度がある会社では、一定金額以上の支出や契約は、たとえ担当者が必要性を強く感じていても、この手続きを経ないと実行できません。IT導入の場面で言えば、次のようなケースがすべて稟議の対象になり得ます。

• 新しい業務システム・SaaSツールの契約
• 既存システムの保守契約の更新・切り替え
• パソコンやサーバーなど、IT機器の購入
• セキュリティ対策ツールの導入
• 外部の開発会社への発注

会社によっては、決裁権限規程で「30万円未満は部門長決裁、30万円以上100万円未満は役員決裁、100万円以上は社長決裁」のように、金額帯ごとに必要な決裁者が定められています。稟議書を書き始める前に、まず自社の決裁権限規程（または過去の稟議の慣例）を確認し、今回の案件がどのルートを通るのかを把握しておくことが最初のステップです。ここを確認せずに書き始めると、想定していなかった決裁者へ追加で説明が必要になり、二度手間になります。

書き始める前に確認すべき3つの前提

本文を書き始める前に、次の3点を確認しておくと、途中で書き直しになる事態を防げます。地味な作業ですが、稟議書全体の完成度を左右する下準備です。

決裁ルートと承認者の顔ぶれ

前述の決裁権限規程に加えて、実際に稟議が回る順番（誰の後に誰が承認するか）を確認しておきます。稟議は多くの場合、直属の上長→関連部門の責任者→経営層、という順に回覧されます。関連部門（経理、法務、他の事業部など）を経由する案件では、その部門が気にするポイントが異なることがあります。たとえば経理担当者が最初に目を通す会社であれば、費用の内訳や支払いサイトの情報を厚めに書いておくと、その段階での質問を減らせます。

過去に似た案件が通っているかどうか

同じ会社で過去に類似のITツール導入が承認された実績があれば、それは強力な参考情報になります。過去の稟議がどんなフォーマットで、どの程度の粒度の情報を求められていたかを、可能であれば確認しておきましょう。過去に否決・保留になった類似案件がある場合は、その理由を把握しておくことも重要です。同じ理由で再び差し戻されることを防げます。

誰に非公式に相談しておくべきか

正式な起案の前に、決裁者や関係部署へ軽く相談しておくかどうかも、事前に決めておきたいポイントです。この点は後の章で詳しく触れます。

稟議書に必要な7つの要素

IT導入の稟議書に共通して必要となる要素は、次の7つに整理できます。会社ごとに用意されているフォーマット（既存のExcelやワークフローシステムの入力項目）は多少異なりますが、内容としてはこの7つを網羅していれば、たいていのフォーマットに当てはめられます。

1. 件名（何を・いくらで・いつから）
2. 現状の課題（なぜ今のままでは困るのか）
3. 導入する内容（何を導入するのか、代替案との比較）
4. 効果・メリット（導入によって何がどう変わるのか）
5. 費用（初期費用・月額/年額費用・総額）
6. リスクと対策（懸念点にどう備えるか）
7. スケジュール（いつまでに何を行うか）

それぞれを順に見ていきます。

1. 件名: 一文で「何を・いくらで・いつから」が分かるようにする

件名は、決裁者が最初に目にする情報であり、稟議書の中で最も軽視されがちな部分でもあります。「〇〇導入の件」のような曖昧な件名では、決裁者は本文を読むまで判断材料を得られません。

件名には、可能な限り「何を」「いくらで」「いつから」の3要素を含めることをおすすめします。

• 悪い例:「勤怠管理システム導入の件」
• 良い例:「勤怠管理システム〇〇導入の件（初期費用5万円・月額3万円、10月稼働開始希望）」

決裁者が日々何十件もの稟議・決裁を処理している場合、件名だけで概要を把握できる書類は優先的に目を通してもらいやすくなります。これは単なる印象の問題ではなく、決裁までのリードタイムにも影響する実務上のポイントです。

2. 現状の課題: 「困っている」だけでなく「何が・どれだけ」困っているかを書く

稟議書で最も重要なのがこのパートです。ここが曖昧だと、決裁者は「そこまで急いで導入する必要があるのか」という疑問を拭えないまま、承認を保留にしてしまいます。

書き方のポイントは、感覚的な表現を避け、具体的な事実に置き換えることです。

悪い例: 「現在の勤怠管理はExcelで行っており、非常に手間がかかっています」

この書き方では、決裁者は「手間がかかっている」がどの程度深刻なのか判断できません。次のように具体化します。

良い例: 「現在、勤怠管理は各従業員が個人のExcelファイルに入力し、経理担当が月末に手作業で給与計算ソフトへ転記しています。従業員数が15名から30名に増えたことで、この転記作業に経理担当者が毎月およそ2営業日を要しており、月末の他業務が圧迫されている状態です。また、手作業での転記であるため、過去に1件、勤務時間の転記ミスによる給与の再計算が発生しています」

このように「誰が」「何を」「どれだけの時間・頻度で」「どんな支障が出ているか」を書くと、決裁者は課題の深刻さを自分の言葉で判断できるようになります。数字を入れる場合は、必ず自分が実際に確認・計測できた数字を使ってください。感覚で「かなり時間がかかっている」と書くよりも、「先週1週間実測したところ、平均で1日あたり40分」のように、裏付けのある範囲で具体的に書くほうが説得力があります。裏付けの取れない数字を大きく見せるために書くことは避けましょう。

3. 導入する内容: 検討した選択肢と、それを選ばなかった理由も書く

「何を導入するか」だけでなく、「他にどんな選択肢を検討し、なぜそれを選ばなかったか」まで書くことが、稟議を通すうえでの分かれ目になります。決裁者は多くの場合、選ばれなかった案の存在を知りません。比較検討のプロセスを見せることで、「ちゃんと検討したうえでの結論だ」という信頼を得られます。

比較は表にまとめると伝わりやすくなります。

社内で開発・改修を依頼する形の案件であれば、外部の開発会社に発注するのか、既存のツールを組み合わせてノーコード・ローコードで対応するのか、あるいは内製化とアウトソースの観点で内製するのかといった選択肢を比較することもあります。金額が大きい案件では相見積もりを取り、複数社の提案を並べて比較すると、決裁者への説明材料としてより強くなります。

外部の開発会社への発注を伴う場合、契約形態（請負契約なのか準委任契約なのか）や、要件定義がどこまで固まっているかによっても、書くべき内容の粒度が変わってきます。この記事では稟議書そのものの書き方に絞って解説しますが、発注先の選定や交渉の進め方については、外注に関する別記事も参考にしてください。

4. 効果・メリット: 「楽になる」ではなく「何がどう変わるか」を書く

効果の欄も、課題の欄と同様に具体性が鍵になります。「業務効率化が期待できます」だけでは、決裁者はその効果を金額や時間の削減として評価できません。

可能な範囲で、次の3つの軸に分けて整理すると書きやすくなります。

• 定量的な効果: 削減できる作業時間、削減できる人件費相当額、エラー発生率の低下など、数字で示せるもの
• 定性的な効果: 従業員の負担軽減、ミスによる手戻りの防止、属人化の解消など、数字にしづらいが重要なもの
• 副次的な効果: 本来の目的以外に得られる波及効果（例: データが一元管理されることで、将来の分析や他システムとの連携がしやすくなる）

先ほどの勤怠管理システムの例で言えば、次のように書けます。

導入により、経理担当が毎月行っている手作業での転記作業（月あたり約2営業日）がなくなり、その時間を月次決算や他の経理業務に充てられるようになります。また、手入力によるミスが構造的になくなるため、給与の再計算といった手戻りのリスクも低減します。

数字にしづらい効果を無理に数値化しようとすると、根拠のない数字になりがちです。定量化できない効果は、無理に数字を作らず、定性的な表現で正直に書くほうが、結果的に信頼される稟議書になります。

5. 費用: 初期費用・ランニングコスト・見落としがちな費用まで含める

費用は最も具体的な数字を求められる項目です。ここで見落としがちなのが、ツール本体の費用以外にかかる周辺コストです。次のような費用も、発生する場合は必ず盛り込んでください。

• 初期費用・導入設定費用
• 月額または年額のライセンス費用（ユーザー数による従量制の場合は、今後の増員見込みも考慮）
• 既存システムからのデータ移行費用
• 従業員向けの操作説明・マニュアル作成にかかる時間コスト
• 契約期間中の解約に伴う違約金の有無
• サポート費用・保守契約の有無とその範囲

特に月額課金型のSaaSツールは、初期費用だけを稟議書に大きく書き、月額費用を小さく扱ってしまうケースが見られます。決裁者が本当に知りたいのは、契約期間全体でいくらかかるかという総額です。1年間・3年間といった単位での総額も併記しておくと、後になって「思っていたより費用がかかっている」という認識のズレを防げます。

IT導入補助金など、公的な補助制度の活用を検討している場合は、その旨と、補助金適用後の実質負担額も明記すると、決裁者の判断材料が増えます。ただし、補助金は申請すれば必ず受給できるものではなく、審査や交付決定のタイミングによって導入スケジュールに影響が出る場合があります。IT導入補助金の活用を前提にスケジュールを組む場合は、不採択だった場合にどうするかも一言添えておくと丁寧です。

6. リスクと対策: 懸念点を先に書き、対策とセットで示す

決裁者が稟議を保留にする理由の多くは、「リスクが書かれていない」ことそのものです。リスクを書かないほうが通りやすいと考えるのは誤解で、実際には逆です。リスクを書かない稟議書は、決裁者に「担当者はリスクを検討していないのではないか」という不安を与え、かえって質問や差し戻しを招きます。

想定されるリスクを先回りして書き、それぞれに対策をセットで示すことで、「検討済みである」という安心感を与えられます。IT導入で一般的に挙がるリスクには、次のようなものがあります。

• 利用が定着しないリスク: 従業員が新しいツールに慣れず、結局Excelに戻ってしまう懸念。対策として、導入後の操作研修の実施計画や、移行期間中の並行運用の有無を書く
• データ移行時のトラブル: 既存データの移行時に不整合や欠損が起きる懸念。対策として、移行前のバックアップ取得や、テスト移行を行う計画を書く
• ベンダー都合による制約: 特定のベンダーに依存し、将来的に他のツールへ乗り換えにくくなる懸念（ベンダーロックイン）。対策として、データのエクスポート機能の有無や、契約の解約条件を確認済みであることを書く
• セキュリティ・情報漏えいのリスク: 特にクラウドサービスの場合、自社の重要データを外部に預けることへの懸念。対策として、提供事業者のセキュリティ認証取得状況や、多要素認証（MFA）など自社側で行う対策を書く

すべてのリスクをゼロにすることはできません。稟議書の目的は「リスクがない」と主張することではなく、「認識しているリスクと、その許容可能な範囲・対策」を示すことです。

なお、稟議が無事に承認された後も、リスクへの対応はそこで終わりではありません。導入後しばらく経ってから、想定していなかった不具合や利用状況のずれが判明することもあります。稟議書に書いた対策を実際に実行したかどうかを、導入後1〜3ヶ月程度の節目で振り返る習慣をつけておくと、次回以降の稟議書の説得力にもつながります。「前回のツール導入では、事前に想定したリスクに対してこのように対応し、結果としてこうなった」という実績は、次の稟議を書く際の何よりの裏付け材料になるためです。

7. スケジュール: 契約から稼働開始までの流れを時系列で示す

最後に、契約から実際の稼働開始までのスケジュールを時系列で示します。決裁者は「いつ決裁すれば、いつから使えるようになるのか」を知りたいため、次のような簡単な工程表があると理解が早まります。

決裁後、契約手続きに約1週間、初期設定とデータ移行に約2週間、従業員への説明会を経て、決裁から約1ヶ月後の運用開始を予定しています。

決裁者が稟議を確認するタイミングは、必ずしも担当者の想定通りではありません。稟議が通るまでの社内の標準的な所要日数（会社によって異なりますが、経験的には数日から2週間程度かかることが多いとされています）も見込んだうえで、逆算して起案のタイミングを決めることをおすすめします。年度末や決算期など、決裁者が多忙になりやすい時期は、通常より時間がかかる可能性も想定しておくと安心です。

金額・案件規模によって書き分ける

7つの要素はどんな案件でも共通して意識すべき骨格ですが、実際に書く分量やトーンは、案件の金額・影響範囲によって変えるべきです。すべての案件で同じ厚みの稟議書を書こうとすると、小さな案件では過剰な作業になり、大きな案件では逆に説明不足になりがちです。目安として、次の3段階で考えると書きやすくなります。

• 少額・部門内で完結する案件（目安: 数万円程度、月額数千円〜数万円のSaaSツールなど）: 7要素をコンパクトに、1ページ以内でまとめる意識で十分です。現状の課題と効果、費用が明確であれば、代替案の比較は簡単な一言程度でも許容されることが多くなります
• 中規模・複数部門に影響する案件（目安: 数十万円程度、部門をまたいで使うツールや、既存システムとの連携を伴う導入など）: 7要素をそれぞれ数行ずつ、比較表や簡単なスケジュール表を添えて書きます。関連部門への影響がある場合は、その部門への確認・調整状況も一言加えておくと安心されます
• 高額・全社影響のある案件（目安: 百万円以上、基幹システムの入れ替えや、外部の開発会社へのシステム開発発注など）: 稟議書本体に加えて、見積書・提案書・比較検討シートなどの添付資料を充実させます。PoC（概念実証）（概念実証）を先に実施している場合はその結果を、RFP（提案依頼書）を用いて複数社から提案を募った場合はその選定経緯を、それぞれ独立した項目として記載することをおすすめします。金額が大きくなるほど、決裁者は「なぜこの金額に見合う価値があるのか」を厳しく見るため、費用対効果の説明はより丁寧にする必要があります

自社にすでに決まったフォーマットがある場合は、そのフォーマットの範囲内で、案件規模に応じて記述の密度を調整するという考え方で問題ありません。

稟議書テンプレート

ここまでの7要素を1枚のテンプレートにまとめました。自社のフォーマットがない場合や、既存フォーマットの参考として活用してください。

【件名】
〇〇（ツール名・システム名）導入の件
（初期費用〇〇円・月額〇〇円、〇年〇月稼働開始希望）

【現状の課題】
・現在の業務フロー: （誰が、何を、どのように行っているか）
・課題: （具体的にどんな支障が出ているか。頻度や時間があれば数値で）
・課題を放置した場合の影響: （このまま何もしなければどうなるか）

【導入する内容】
・導入予定: 〇〇（製品名・サービス名）
・提供元: 〇〇社
・検討した他の選択肢:
　- 選択肢A: （概要と見送った理由）
　- 選択肢B: （概要と見送った理由）
　- 現状維持: （見送った理由）

【効果・メリット】
・定量的な効果: （削減時間、削減コストなど）
・定性的な効果: （負担軽減、ミス防止など）
・副次的な効果: （あれば）

【費用】
・初期費用: 〇〇円
・月額/年額費用: 〇〇円（〇名分、今後の増員見込み: 〇名）
・その他費用: （データ移行費、研修費など）
・契約期間中の総額（目安）: 〇〇円（〇年間）
・補助金活用の有無: （活用する場合はその旨と実質負担額）

【リスクと対策】
・想定リスク1: （内容） → 対策: （内容）
・想定リスク2: （内容） → 対策: （内容）

【スケジュール】
・決裁: 〇年〇月〇日希望
・契約手続き: 〇年〇月〇日〜
・導入設定・データ移行: 〇年〇月〇日〜
・従業員説明: 〇年〇月〇日
・稼働開始: 〇年〇月〇日

このテンプレートはあくまで骨格です。会社の稟議フォーマットにすでに決まった項目がある場合は、無理に7項目すべてを別立てにする必要はなく、既存の項目の中に必要な情報を書き込む形で構いません。重要なのは項目の名前ではなく、7つの要素の中身が漏れなく盛り込まれていることです。

稟議が差し戻される典型パターンと、その回避方法

ここまでの内容を踏まえて、実際によくある差し戻しパターンを整理します。自分の稟議書を見直す際のチェックリストとして使ってください。

• 「なぜ今なのか」に答えていない: 課題が漠然としており、今このタイミングで導入する緊急性・必要性が伝わらない差し戻しパターンです。既存の運用を続けた場合に今後どう悪化していくかを一言添えると解消できます
• 金額だけが書かれ、根拠がない: 「月額3万円」とだけ書かれていて、何人分のライセンスで、それが妥当な価格なのかが分からないケースです。比較表や見積書を添付し、金額の内訳を明記しましょう
• 代替案の検討過程が見えない: 決裁者から「他にも安いツールがあるのでは」と質問され、答えられずに差し戻されるパターンです。前述の比較表を用意しておくことで防げます
• リスクに触れていない: リスクを書かないほうが心証が良いと考えて省略した結果、逆に「検討不足」と判断されるケースです
• 効果が抽象的すぎる: 「業務が効率化されます」だけで終わっており、何にどれだけ効くのかが分からないケースです
• 添付資料が不足している: 見積書、製品パンフレット、比較検討シートなど、本文を裏付ける資料が添付されていないと、決裁者は本文の内容を検証できません。可能な限り一次資料を添付しましょう

決裁者との事前すり合わせも並行して行う

稟議書は書類そのものの完成度も重要ですが、いきなり正式な稟議として提出する前に、決裁者や関係する上長へ口頭やメールで概要を軽く共有し、方向性に大きなずれがないかを確認しておくことも実務上は有効です。特に金額が大きい案件や、複数部門にまたがる影響がある案件では、正式な起案の前に非公式な相談を挟むことで、差し戻しの手戻りを減らせます。

これは稟議書の「書き方」そのものとは別の話ですが、社内合意形成の進め方や説得材料の作り方に関しては、発注準備を扱う別のガイド記事でも取り上げていますので、あわせて確認しておくと、稟議書作成の前段階の準備がより整理しやすくなります。事前相談の段階で決裁者から出た懸念点は、正式な稟議書の「リスクと対策」の項目にそのまま反映できることが多く、二度手間にはならず、むしろ本番の稟議書の完成度を上げる材料になります。

よくある失敗: 「熱意」で押し切ろうとする稟議書

最後に、書き方以前の心構えとして触れておきたい点があります。稟議書の中に「ぜひ導入させてください」「業務改善のため必要不可欠です」といった訴求的な表現を重ねて、熱意で押し切ろうとするケースが見られますが、これは基本的に逆効果です。決裁者が知りたいのは担当者の熱意ではなく、判断に必要な事実と数字です。

熱意そのものが不要というわけではありません。むしろ、事実と数字を丁寧に積み上げたうえで、最後に一言「現場の負担軽減のためにも、ぜひ前向きにご検討いただけますと幸いです」と添える程度であれば、文書全体の印象を和らげる効果があります。ただし、それは事実の裏付けがあってこそ機能するものであり、事実の代わりに熱意を書くことはできません。まずは7つの要素を事実ベースで埋めることを優先し、熱意はあくまで最後に添える調味料程度に留めておくことをおすすめします。

次に読みたい記事

稟議書を無事に通した後は、実際に導入するツール・システムの選定や発注準備が次のステップになります。IT資産管理の始め方や、社内のセキュリティ対策の基本など、ひとり情シスとして押さえておきたい実務についても、関連記事で解説していますのであわせてご覧ください。稟議は一度通したら終わりではなく、次にまた同じような案件が出てきたときに、より短い時間で通せるようにしていくことが、ひとり情シス担当者にとっての長期的な負担軽減につながります。