LASSIC Media らしくメディア
システム導入の稟議書の書き方｜項目別の例文と決裁者が見る点
監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）
この記事の結論
- システム導入の稟議書は、企画書やRFP、見積書の要点をまとめて費用と契約の承認を求める書類です。
- 費用の行には金額だけでなく、仮試算から確定までのどの段階の見積もりかを書き添えます。
- 要件定義と開発で決裁を区切り、決裁者から出やすい5つの質問への答えを先に用意します。
※ 本記事は2026年10月時点の公式情報（省庁・公的機関、および製品やサービスを提供する事業者が公開している資料）に基づきます。
稟議書を出したら「この金額の根拠は？」と差し戻された。何を書けば通るのか、手本が見当たらない——。初めてシステム導入を任された情報システムの担当者には、こうした悩みがつきものです。システム導入の稟議書は、導入の目的・費用・期間・体制を1つの書類にまとめ、決裁者に承認を求める社内の書類です。
項目のひな形と例文があれば、書き始めは早くなります。ただし万能ではなく、例文を埋めただけでは、金額がどこまで確かなのか、どこで止めて判断できるのかまでは決裁者に伝わりません。本記事では、システム導入の稟議を初めて書く担当者に向けて、稟議書の項目と例文、見積もりの段階に合わせた費用の書き方、決裁者から出やすい質問と答え方、そして稟議の資料を外部に頼める範囲を整理します。
目次
システム導入の稟議書とは
システム導入では、稟議書の前後にいくつかの書類が並びます。それぞれ誰に向けた書類なのかを先に押さえておくと、何を稟議書の本文に書き、何を添付に回すかを決めやすくなります。
- 企画書（システム化の計画）：社内の関係者に向けて、なぜ導入するのか、どの業務を対象にするのかを固める書類
- RFP（提案依頼書）：外部の事業者に向けて、作りたい仕組みを伝え、提案と見積もりを求める書類。IPA（情報処理推進機構）のモデル契約は、システムの概要と狙いとする効果、機能の要件に加えて性能や運用などの要件（非機能要件）も記載事項に挙げています*1
- 見積書・提案書：事業者から届く、費用と進め方の案
- 稟議書：決裁者に向けて、上の書類の要点をまとめ、費用と契約の承認を求める書類
つまり稟議書は、企画書とRFP、見積書の「要約と結論」にあたります。中身を一から書き起こすのではなく、すでにある書類から決裁に要る点を抜き出す、と考えると書き始めやすくなります。逆に言えば、企画やRFPの段階で決めていないことは、稟議書にも書けません。
稟議書の項目と例文
システム導入の稟議書でよく使う項目を、書く中身・例文・決裁者が見る点に分けると次の表のようになります。項目の名前や並べ方は、会社の様式に合わせて変えてかまいません。例文の「〇〇」は、自社のシステム名や部署名、数値に置き換えて使います。
| 項目 | 書く中身 | 例文 | 決裁者が見る点 |
|---|---|---|---|
| 件名 | 何の承認を求めるかを一言で | 「〇〇システム導入の件（要件定義の発注）」 | 何を承認するのかが一目で分かるか |
| 目的と背景 | いま困っていることと、放置した場合の影響 | 「受注の入力を〇〇部の〇人が手作業で行っており、月末に〇日分の残業が出ている。」 | 会社や部門の方針とつながっているか |
| 導入の内容と範囲 | 入れる仕組み、対象の業務と部署、対象外の業務 | 「〇〇システムを導入し、受注の入力から請求書の発行までを対象とする。在庫の管理は対象外とする。」 | 範囲があいまいで、後から広がらないか |
| 費用 | 初期の費用、毎年かかる費用、見積もりの段階 | 「初期費用〇〇万円、年間の利用料と保守費〇〇万円。金額は要件定義の前の見積もりによる。」 | 運用の費用まで入っているか。金額がどこまで確かか |
| 期間と工程 | 工程の並びと、決裁を区切る時点 | 「〇月から〇か月で要件定義を行い、その結果をもとに開発の稟議を改めて申請する。」 | 途中で止めて判断する機会があるか |
| 体制と契約 | 社内の責任者、外部の役割、契約の形 | 「社内は〇〇部長を責任者とし、要件定義は外部の事業者に支援を依頼する（準委任契約）。」 | 社内で決めるべきことまで外部に預けていないか |
| 効果と確かめ方 | 測る指標、測る時期、測る担当 | 「入力の作業時間を月〇時間減らす。稼働から〇か月後に作業記録で確かめる。」 | 効果を測れるか。いつ判断するか |
| 比較した案 | ほかの案と、本案を選んだ理由 | 「〇〇製品の導入と自社開発を比べ、〇〇の点で本案を選んだ。」 | なぜこの案なのか |
| リスクと対策 | 遅れ、追加の費用、情報の扱いと、その手当て | 「要件が増えた場合は変更の手続きで見積もりを取り直し、予算を超えるときは改めて申請する。」 | 起きたときの判断の仕方が決まっているか |
表の中で書き漏らしやすいのは、「費用」の行の後半です。金額だけを書くと、決裁者はそれが確かな金額なのか、まだ動く金額なのかを判断できません。見積もりがどの段階のものかを1文添えておきます。範囲の行に対象外の業務を書いておくと、導入後の「これもできると思っていた」という食い違いも防げます。
見積もりの段階と費用の書き方
IPAが公開している「情報システム・モデル取引・契約書（第二版）」（以下、モデル契約）は、システム開発の見積もりを工程の進み具合に応じて4つの段階に分けています。*1 システム化の構想を立てる段階の「仮試算見積」から始まり、画面や帳票などを決める外部設計の段階で、ようやく「確定見積」が出せるという考え方です。
- 仮試算見積・試算見積：構想と計画の段階の見積もり。最終的な成果物を決めにくいため、参考値として扱うものとされています*1
- 概算見積：要件定義の後の見積もり。目的と範囲は決まっているものの、細かい部分はまだ固まっていない段階です
- 確定見積：外部設計の後の見積もり。これより後に要件の追加や仕様の変更が出たときは、変更の手続きを経て見積もりを取り直します*1
稟議書の費用の行には、この段階を書き添えます。要件定義の前に、開発費まで含めた総額で決裁を取ると、後で金額が動いたときに「稟議と違う」と差し戻されがちです。モデル契約は、工程ごとに個別の契約を結ぶ「多段階契約」と、要件が明確になった段階で見積もり直す「再見積り」の考え方を採っています。*1 稟議も同じように、まず要件定義までを決裁し、開発は確定に近い見積もりで改めて申請する、と区切ると説明しやすくなります。
ただし、区切るほど全体の金額は見えにくくなります。モデル契約も、再見積りのときは後の工程にしわ寄せが起きないよう、全体の予算の管理に注意が要るとしています。*1 稟議書には、今回の金額とあわせて全体の見込みの幅も書いておきます。
決裁者から出やすい質問と答え方
稟議書を回すと、決裁者からの質問はおおむね決まった形で返ってきます。費用の根拠、比べた案、効果、うまくいかなかったとき、やめた場合の5つです。先に答えを稟議書か添付資料に入れておけば、差し戻しの往復を減らせます。
| 質問 | 答え方 | 添える資料 |
|---|---|---|
| 費用の根拠は何か | 見積もりの段階と内訳（作業の量、単価、数量）を示す。複数の見積もりを取ったなら、その数と選んだ理由も添える | 見積書、内訳の表 |
| ほかの案と比べたか | 製品の導入、クラウドサービスの利用、自社開発、今のまま続ける、のうち比べた案と、比べた基準を示す | 比較表 |
| 効果はいつ、どう分かるか | 測る指標と時期と担当を決めて書く。測りにくい効果は確かめ方で示す | 効果の測り方の表 |
| うまくいかなかったらどうするか | 工程ごとに続けるかを判断する時期と、追加の費用が出たときの手続きを示す | 工程表 |
| やめた場合はどうなるか | 今のまま続けた場合の手間と費用、古い仕組みが止まる危険を示す | 現状の作業記録 |
このうち効果は、数値で示せるものと示しにくいものを分けて書きます。経済産業省の「DX推進指標」は、投資の判断について「DXに投じる資金をコストではなく経営にとって必要な投資として位置づけ、リターンの大きさや確度を求めすぎずに、挑戦を促す投資を行っているか」を問うています。*2 作業時間のように測れる効果は数値で、顧客対応の速さのように測りにくい効果は確かめ方で示します。
稟議の資料を外部に頼める範囲
稟議書そのものは社内の書類なので、書くのは自社の担当者です。一方で、添付する見積もりや比較の資料は外部の手を借りて作れます。モデル契約も、システム化の計画や要件定義の段階で、発注する企業が専門家と準委任契約（作業の遂行に対して費用を払う契約）を結び、支援を受ける形を示しています。*1
- 現状の整理：いまの業務の流れや、使っているシステムの調査。古いシステムの入れ替えでは特に手がかかる部分です
- RFPの作成支援：要件の洗い出しと、見積もりを比べられる形の依頼文づくり。進め方はRFP作成の支援と外注で扱っています
- 見積もりの内訳の説明：工数（作業の量を人数と期間で表したもの）や前提の条件を、決裁者に説明できる形に直す作業
- 比較表の軸づくり：複数の見積もりを同じ条件で並べるための項目の整理。システム開発の相見積もりの取り方も参考になります
- 段階の区切り方：要件定義・開発・運用をどこで分けて発注するかの計画
頼むときは、次の点を先に確かめておきます。答えはそのまま、稟議書の「体制と契約」の行に書けます。
- 範囲：現状の調査、RFP、要件定義のどこまでを頼むか
- 期間：稟議の締め切りに資料が間に合うか
- 体制：社内の誰が窓口になり、何を社内で決めるか
- 費用の決まり方：作業の期間に対して払うのか、成果物に対して払うのか
- 引き継ぎ：作った資料を、社内で直せる形で受け取れるか
モデル契約は、請負（完成に対して費用を払う契約）を選ぶと、発注する側に「丸投げ」の意識が強くなりやすいという議論も紹介しています。*1 資料づくりを外部に頼んでも、何を導入するかを決めて稟議を出すのは自社です。
まとめ：システム導入の稟議書で確かめておきたい3つの点
システム導入の稟議書を書くうえで、確かめておきたい点は3つに整理できます。第一に、項目ごとの例文を埋めるだけでなく、範囲の対象外の業務と、費用の見積もりの段階まで書くこと。第二に、要件定義と開発で決裁を区切り、確定に近い見積もりで次の稟議を出すこと。第三に、費用の根拠・比べた案・効果・うまくいかなかったとき・やめた場合の5つの質問への答えを、先に用意しておくことです。この3点を踏まえておけば、「金額の根拠が分からない」と何度も差し戻される事態を避けやすくなります。見積もりや比較の資料づくりに迷いがあれば、外部の手を借りるのも一つの選択肢です。
よくある質問
稟議書はどのくらいの分量にまとめればよいですか
決まった分量はなく、会社の様式に従います。本文は決裁に要る点に絞り、見積書や比較表、工程表は添付に回すと読みやすくなります。決裁者が最初に目を通す件名・目的・費用が、1枚目で分かる形にしておくのがおすすめです。
クラウドサービスの利用でも稟議は必要ですか
必要かどうかは、社内の決裁の規程で確かめます。稟議を出す場合は、月額の利用料だけでなく契約期間の合計の金額を示し、解約の条件や、預けるデータの扱いも書き添えると判断しやすくなります。
見積もりを1社からしか取れなかった場合はどう書けばよいですか
1社に絞った理由を書きます。たとえば、いまのシステムを保守している事業者にしか頼めない場合などです。そのうえで、見積もりの内訳と前提の条件を示し、金額が作業に見合っているかを決裁者が確かめられるようにします。
システム導入の稟議資料づくりのご相談
稟議に添える現状の整理やRFPの作成から、見積もりの内訳の説明、段階に分けた発注の計画まで、元請（プライムベンダー）としてご提案します。
2006年の創業以来、一次請けのシステムインテグレーターとして、企業のシステム開発と保守・運用を受託してきました。
出典
- *1 参考：独立行政法人情報処理推進機構（IPA）「情報システム・モデル取引・契約書（第二版）」（https://www.ipa.go.jp/digital/model/model20201222.html）。出典：第二版（2025年4月8日更新）の本文のうち、見積りの段階（仮試算見積・試算見積・概算見積・確定見積）、多段階契約と再見積り、全体の予算管理の注意、RFPの記載事項、工程ごとの契約類型（準委任・請負）と「丸投げ」の議論、専門家との準委任契約による支援の記述を参照（2026年10月確認）
- *2 参考：独立行政法人情報処理推進機構（IPA）「DX推進指標のご案内」（DX推進指標 設問一覧）（https://www.ipa.go.jp/digital/dx-suishin/about.html）。出典：設問一覧の定性指標「3-1. 組織づくり」の投資等の意思決定に関する設問を参照（2026年10月確認）
