30人規模の会社が外注費用を稟議に通すための資料の作り方

システム開発の見積もりが数十万円〜数百万円という金額で出てきたとき、30人規模の会社の総務担当者は、この金額を決裁者(多くの場合は社長一人)に納得してもらうための説明を、自分の言葉で組み立てなければなりません。大企業であれば、経理部門や情シス部門が投資対効果の算定フォーマットを持っており、担当者はそれに数字を当てはめるだけで済むこともあります。しかし30人規模の会社には、そうした定型フォーマットが存在しないことがほとんどです。

さらに厄介なのは、決裁者がIT分野に詳しくないケースが多いという点です。「工数」「保守費用」「準委任契約」といった言葉が並ぶ見積書をそのまま見せても、決裁者には金額の妥当性が判断できません。結果として、「なんとなく高い気がする」という感覚だけで話が止まってしまうことがあります。

この記事では、IT分野に詳しくない経営者に向けて、金額感を納得してもらうための稟議資料をどう組み立てるかを、具体的な構成要素とともに解説します。想定する読者は、社員10〜30人規模の会社で、総務・経理担当として初めてシステム開発の外注費用を稟議にかける立場にある担当者です。決裁者が1〜2人しかいない組織では、稟議は形式的な承認手続きではなく、決裁者本人を実質的に説得する場そのものになります。社内合意の取り方全般の考え方は総務が初めてシステム開発を発注するときの社内合意の取り方で扱っていますが、本記事ではその中でも「資料」という具体的な成果物の作り方に絞って掘り下げます。

この記事で分かること

• 稟議資料に最低限含めるべき5つの構成要素
• 見積書の金額をそのまま貼るだけでは伝わらない理由
• 「現状維持コスト」を見せることで金額の高さを相対化する方法
• 決裁者から聞かれる典型的な質問と、事前に用意しておくべき回答
• IT導入補助金など、金額を軽減する選択肢の説明の仕方

稟議資料に最低限含めるべき5つの構成要素

稟議資料と聞くと、堅苦しい様式を想像するかもしれませんが、30人規模の会社では、社内規定で定められた稟議書フォーマットが存在しないことも多く、パワーポイントの数枚、あるいはA4一枚のメモでも十分に機能します。重要なのは形式ではなく、次の5つの構成要素が過不足なく含まれていることです。

この5要素のうち、多くの担当者が①と③だけに偏りがちです。「困っています、いくらかかります」という説明だけでは、決裁者は「本当にその金額を払う価値があるのか」を判断できません。②④⑤を含めることで初めて、投資判断としての体裁が整います。

見積書をそのまま貼るだけでは伝わらない理由

開発会社から受け取った見積書は、専門用語と項目名が並んだ、開発者向けの文書です。これを稟議資料にそのまま貼り付けるだけでは、IT分野に詳しくない決裁者には意味が伝わりません。

見積書に並ぶ「要件定義」「基本設計」「詳細設計」「実装」「結合テスト」といった工程名は、開発のプロセスを表す専門用語であり、決裁者にとっては「結局何にお金がかかっているのか」が見えにくい表現です。稟議資料では、これらの専門用語を決裁者の言葉に翻訳し直す作業が必要になります。

翻訳の一例を示します。

見積書の内訳をどう読み解けばよいか、工数や単価の考え方そのものについては、コラムシステム開発の見積書、この内訳の見方で損を防ぐ（工数・単価・バッファ）で詳しく扱っています。稟議資料を作る前に、担当者自身がこの内訳を理解しておくことで、決裁者からの質問にもその場で答えられるようになります。

「現状維持コスト」を見せて金額の高さを相対化する

決裁者が金額の高さに難色を示す最大の理由は、「システム化にかかる費用」と「何もしなかった場合のコスト」を比較する視点が、資料に含まれていないことです。人間は、新しい支出は目に見えやすい一方、既存の非効率が生む見えないコストには鈍感になりがちです。

この視点のズレを埋めるのが、「現状維持コスト」の可視化です。具体的には、次のような計算を資料に含めます。

現在、請求書処理に月20時間かかっている。担当者の時給換算コストを2,000円とすると、月4万円、年間で48万円のコストが、目に見えない形で発生し続けている。これに加えて、月平均2件の入力ミスがあり、修正対応にさらに時間がかかっている。

この計算はあくまで概算であり、精緻な原価計算である必要はありません。重要なのは、「システム化しない場合も、実はコストがかかり続けている」という事実を、決裁者に可視化することです。開発費用が仮に150万円だったとしても、「年間48万円のコストが3年続けば144万円になる。今回のシステム化で、この時間の大部分が削減できる見込みです」という説明があれば、投資の妥当性が格段に伝わりやすくなります。

決裁者から聞かれる典型的な質問と回答の準備

稟議の場で決裁者から実際によく聞かれる質問を、あらかじめ想定しておくと、その場で慌てずに答えられます。代表的な質問と、回答の準備の仕方を示します。

• 「なぜこの金額なのか、もっと安くならないのか」: 相見積もりを取った結果を示し、他社との比較で妥当性を説明できるようにしておく。相見積もりの取り方はコラム相見積もりの取り方と比較の観点を参照
• 「本当に効果が出るのか」: 現状維持コストとの比較、あるいはPoC・MVPのような小さな検証から始める提案をセットで用意しておく
• 「途中で追加費用が発生しないか」: 契約形態(請負契約か準委任契約か)と、追加費用が発生する条件を事前に開発会社に確認し、資料に明記しておく
• 「他の方法(既製品など)ではダメなのか」: 既製品・ノーコードとの比較検討をすでに行った結果を、簡潔に添えておく
• 「導入後、誰が管理するのか」: 導入後の運用体制(自分が窓口になるのか、保守契約でどこまでカバーされるのか)を明示しておく

これらの質問にあらかじめ答えを用意しておくことで、稟議の場が「担当者が答えられず、話が止まる」という展開になることを防げます。特に金額の妥当性に関する質問は、相見積もりの結果があるかないかで説得力が大きく変わります。

IT導入補助金など、金額を軽減する選択肢の説明の仕方

決裁者から「補助金は使えないのか」と聞かれることもよくあります。ここで注意が必要なのは、IT導入補助金(2026年度からは「デジタル化・AI導入補助金」という名称)は、そもそも既製のITツールの導入を前提に設計された制度であり、フルスクラッチ開発、つまり自社の要件に合わせてゼロから作るシステム開発は、対象になりにくい構造だという点です。

制度の対象になりにくい理由を簡潔に言うと、補助金の対象は事前に事務局へ登録された「完成済みのITツール」を、登録済みの「IT導入支援事業者」経由で導入する場合に限られるためです。要件定義から作り込む独自開発は、この「完成済みの製品」という前提に合いません。

決裁者にこの点を説明する際は、期待を過度に持たせないよう、次のように正直に伝えることをお勧めします。

「IT導入補助金は、既製のソフトやクラウドサービスの導入を対象にした制度で、今回のような独自開発にはそのままでは使いにくい仕組みになっています。ただし、開発の一部を既製パッケージとの連携に置き換えられる部分があれば、その部分だけ対象になる可能性はあります。詳しくは開発会社にも確認しつつ、過度な期待をせず別の予算確保の方法も並行して検討したいと思います」

補助金を使えることを前提に稟議を組み立ててしまうと、後で対象外と判明した際に計画全体が崩れます。制度の詳しい仕組みと、対象になりやすい・なりにくい開発の見分け方は、コラムIT導入補助金でシステム開発はできるかで詳しく解説していますので、稟議資料を作る前に一読しておくと、決裁者からの質問にも正確に答えられます。

資料に「やらない場合の選択肢」も併記する

意外に効果的なのが、稟議資料の中で「システム化しない、または見送るという選択肢」もあえて併記することです。一見、自分の提案を弱める行為のように思えるかもしれませんが、実際には逆の効果を持ちます。

決裁者は、担当者から一方的に「これしかない」という形で提案されると、無意識のうちに他の選択肢がないかを疑いたくなるものです。逆に、「見送るという選択肢もありますが、その場合は現状の非効率が今後も続き、年間で約48万円相当のコストが積み重なります」という形で、見送った場合の影響まで示されると、担当者が中立的な立場で検討したうえでの提案だと伝わりやすくなります。

併記する際の書き方の例を示します。

選択肢A: 今回提案する内容で外注する(150万円、効果は月20時間の削減)

選択肢B: 見送り、現状のまま継続する(追加費用は発生しないが、非効率は継続する)

選択肢C: より安価な既製品での代替を検討する(月額数千円だが、自社独自の要件には対応しきれない可能性がある)

このように複数の選択肢を並べたうえで、なぜ選択肢Aを推奨するのかを説明する構成にすると、稟議資料全体の説得力が増します。

リスクと対応策を資料に含める重要性

稟議資料の中で見落とされがちなのが、⑤の「リスクと対応策」です。多くの担当者は、良い面(効果)だけを強調し、リスクについては触れないまま資料を作ってしまいます。しかし、決裁者の立場からすると、リスクに触れていない資料は「都合の良い話しかしていないのでは」という不信感につながることがあります。

含めるべきリスクの例と、対応策の示し方を挙げます。

このようにリスクとその対応策をセットで示すことで、「リスクを認識したうえで、それでも投資する価値があると判断した」という、担当者の検討の深さが伝わります。これは決裁者の安心感につながるだけでなく、万が一トラブルが起きた際に「想定していなかった」という後付けの批判を避ける効果もあります。

資料の分量と伝え方: 詳細版と要約版の2段構え

30人規模の会社の決裁者は、経営全体を見ながら意思決定をしているため、長大な資料を読み込む時間がないことも多くあります。稟議資料は、詳細版と要約版の2段構えで用意することをお勧めします。

• 要約版(A4一枚): 5要素をそれぞれ2〜3行で簡潔にまとめたもの。決裁者が最初に目を通す資料
• 詳細版(数枚〜): 見積書の内訳、相見積もりの比較表、リスクと対応策の詳細などを含めたもの。決裁者から質問が出た際に参照する資料

多くの決裁者は要約版だけで意思決定できますが、慎重な決裁者や、金額が大きい案件の場合は詳細版まで目を通したいという要望が出ることもあります。両方を用意しておくことで、どちらのタイプの決裁者にも対応できます。

相見積もりの結果を資料にどう組み込むか

金額の妥当性を説明するうえで、最も説得力を持つ材料の一つが相見積もりの比較結果です。1社だけの見積もりでは、その金額が高いのか安いのか、決裁者はもちろん担当者自身も判断がつきません。複数社から見積もりを取ることで、金額の相場観と、各社の提案内容の違いが見えてきます。

稟議資料に相見積もりを組み込む際は、単に金額を並べるだけでなく、次のような比較表の形にまとめると分かりやすくなります。

このような比較表があると、決裁者は「一番安い会社を選べばよい」という単純な判断ではなく、金額・期間・実績・保守体制を総合的に見て判断できるようになります。単純に金額の最安値だけで選ぶことのリスクについては、コラム相見積もりの取り方と比較の観点でも詳しく扱っています。

なお、相見積もりを取る際に、開発会社によって前提条件(対象範囲や保守の有無)が微妙に異なっていることがあります。比較表を作る前に、各社の見積もりが同じ前提条件で作られているかを確認しておかないと、単純比較ができない資料になってしまう点に注意してください。

段階的な投資（分割発注）という選択肢を資料に含める

決裁者が一括での大きな金額に難色を示す場合、稟議資料に「段階的に投資する」という選択肢を含めておくことも有効です。全体を一度に発注するのではなく、まず小さな範囲・小さな金額で試し、効果を確認してから本格的な投資に進む、という進め方です。

具体的には、稟議資料に次のような2段階の提案を含めます。

1. 第一段階(PoC・小規模試作): 30万円〜50万円程度で、対象範囲を限定した試作を行う
2. 第二段階(本格導入): 第一段階の効果を確認したうえで、本格的な開発に進む(金額は第一段階の結果を踏まえて別途稟議)

この進め方のメリットは、決裁者にとって最初の意思決定のハードルが大きく下がることです。「150万円を一度に判断する」のではなく、「まず30万円で試してみる」という提案であれば、心理的な抵抗はかなり小さくなります。小さく発注して試すという考え方そのものについては、コラム小さく発注して試す: PoC発注のすすめでも詳しく解説しています。

ただし、この段階的な進め方には注意点もあります。第一段階と第二段階を別々の開発会社に発注すると、設計や実装の連続性が失われる可能性があるため、基本的には同じ開発会社に継続して依頼する前提で計画を立てることをお勧めします。稟議資料にも、「第一段階の結果を踏まえて、同じ開発会社に継続を依頼する想定である」ことを明記しておくと、決裁者の理解を得やすくなります。

稟議が通った後、資料をどう保管・活用するか

稟議が承認された後も、作成した資料をそのまま破棄せず、保管しておくことには実務上の価値があります。理由は2つあります。

1つ目は、契約内容と稟議で説明した内容に食い違いがないかを、後から確認できるようにするためです。開発が進む過程で、当初の想定と異なる展開になることは珍しくありません。稟議資料が残っていれば、「当初はこういう説明で承認を得た」という基準点を確認でき、変更が生じた際に決裁者へ再度説明すべきかどうかの判断材料になります。

2つ目は、次回以降のシステム化案件で、資料作成のたたき台として再利用できるためです。稟議資料の構成(5要素)は、テーマが変わっても基本的な型は使い回せます。一度型を作っておけば、2つ目・3つ目の案件では資料作成にかかる時間を大幅に短縮できます。

保管する際は、稟議資料そのものに加えて、次の情報も併せて残しておくことをお勧めします。

• 決裁者から実際に出た質問と、それに対する回答
• 最終的にどの開発会社を選んだ理由
• 承認された金額と、実際の契約金額に差異があった場合はその理由

こうした記録は、属人化を防ぐ観点からも重要です。担当者が異動・退職した場合でも、後任者がこの記録を見れば、なぜそのシステムが、その金額で、その開発会社に発注されたのかという経緯を追うことができます。

口頭説明のシミュレーションをしておく

資料が完成したら、実際に決裁者へ説明する前に、口頭でどう伝えるかを一度シミュレーションしておくことをお勧めします。資料は完璧でも、口頭での説明が要領を得ないと、決裁者に正確に伝わらないことがあります。

シミュレーションの際は、次の順番で話す練習をしてみてください。

1. 現状の課題を一言で(「〇〇の作業に月20時間かかっています」)
2. 提案する解決策を一言で(「この部分をシステム化したいと考えています」)
3. 金額を一言で(「初期費用は〇〇万円、月額の保守費用は〇〇円です」)
4. 効果を一言で(「導入後は、この作業がほぼ自動化され、月15時間程度の削減が見込めます」)
5. リスクと対応策を一言で(「スケジュールが延びるリスクはありますが、バッファを含めた計画にしています」)

この5つを、それぞれ一言で言えるように練習しておくと、決裁者から「結局いくらで、何が変わるのか」と聞かれた際に、資料をめくらずともすぐに答えられるようになります。資料は詳細な裏付けとして持ちつつ、口頭説明は簡潔に要点を伝える、という役割分担を意識してください。

決裁者が複数いる場合、資料の見せ方を変える

前提として、30人規模の会社でも決裁権を持つ人が社長一人だけとは限らず、専務や役員が加わって2〜3人で意思決定するケースもあります。この場合、全員が同じ関心を持っているとは限らない点に注意が必要です。例えば、社長は事業成長への貢献度を重視する一方、経理を統括する役員は費用対効果やキャッシュフローへの影響を重視する、というように、決裁者ごとに重視するポイントが異なることがあります。

このような場合、資料の基本構成(5要素)は変えずに、説明の際に強調するポイントを決裁者ごとに調整することをお勧めします。例えば、経理担当役員向けには「現状維持コスト」の試算をより詳しく示し、事業側の役員向けには「効果」の部分、特に将来的な事業拡大への貢献を厚めに説明する、といった具合です。

ただし、決裁者ごとに全く異なる資料を作る必要はありません。基本の資料は1つに統一し、口頭説明の際にどの部分を重点的に補足するかを調整する、という運用が現実的です。資料そのものを何パターンも作ると、担当者の負担が増えるだけでなく、決裁者間で「言っていることが違う」という不信感を招くリスクもあります。

稟議のタイミングと予算編成のサイクルを合わせる

意外と見落とされがちなのが、稟議を提出するタイミングと、会社の予算編成のサイクルとの関係です。30人規模の会社であっても、多くは年度単位で大まかな予算枠を組んでおり、期の途中で想定外の大きな支出が発生すると、たとえ投資対効果が高くても「今期の予算にない」という理由で先送りにされることがあります。

稟議資料を作成する前に、次の点を確認しておくとスムーズです。

• 今期の予算にIT関連の投資枠がどの程度残っているか
• 次期の予算編成はいつ頃行われるか、間に合うのであれば正式に組み込めないか
• 今期中に着手する必要がある緊急性が本当にあるか

緊急性が高くない案件であれば、次期の予算編成のタイミングに合わせて稟議を提出する方が、決裁者にとっても判断しやすくなります。逆に、緊急性が高い場合(例えば現行の仕組みが限界を迎えている、担当者の退職が迫っているなど)は、その緊急性自体を資料の「①現状の課題」の中で明確に伝える必要があります。

まとめ: 「金額の説明」ではなく「投資判断の材料」を用意する

30人規模の会社で外注費用を稟議に通すための資料は、見積書の金額をそのまま伝えることではなく、決裁者が投資判断を下せるだけの材料を揃えることが目的です。次の5点を必ず押さえてください。

1. 現状の課題を数字で示す
2. 専門用語を決裁者の言葉に翻訳する
3. 現状維持コストと比較し、金額の高さを相対化する
4. 決裁者からの典型的な質問への回答をあらかじめ用意する
5. リスクと対応策をセットで示し、検討の深さを伝える

これらを一度に完璧にこなす必要はありません。最初の稟議では要約版のA4一枚だけで臨み、決裁者からの反応を見ながら詳細版を追加で用意する、という進め方でも十分に機能します。大切なのは、金額の大きさそのものに気圧されて資料作りを後回しにするのではなく、決裁者が納得できる材料を一つずつ積み上げていく姿勢です。

一度この型で資料を作っておけば、次にシステム化の話が持ち上がったときには、同じ5要素の枠組みに新しい数字を当てはめるだけで済みます。最初の1本を丁寧に作ることが、2本目以降の負担を大きく減らすことにつながります。

システム開発の受託会社が運営するメディアという立場から、あえて率直に付け加えておくと、稟議資料の目的は「発注を実現すること」ではなく、「決裁者が正しい判断を下せる材料をそろえること」です。整理を進める過程で「この規模なら既製品で十分では」「今は見送るのが妥当では」という結論に至ることも、決して失敗ではありません。むしろ、そうした冷静な判断ができる資料を作れることこそが、担当者としての信頼につながります。

資料作りに慣れないうちは、完璧な内訳や精緻な効果試算にこだわりすぎず、まずは「①現状の課題」と「③費用」だけでも粗く書き出してみることから始めてください。書き出してみて初めて、自分がどの情報を持っていて、どの情報が足りないかが見えてきます。そこから②④⑤を肉付けしていく方が、白紙の状態から5要素をすべて同時に埋めようとするより、実際には進めやすいはずです。

資料が整ったら、総務が初めてシステム開発を発注するときの社内合意の取り方で扱った着手前の相談から始まる合意形成の流れに沿って、決裁者への提案に進んでください。トップダウンで案件が始まった場合の資料の作り方は、経営者の鶴の一声で始まる開発案件を暴走させない進め方も参考になります。