30-100人規模で初めて外部に開発を発注するときの社内稟議の通し方

「稟議を上げてください」と言われて、まず戸惑うのはフォーマットではありません。この会社に稟議規程というものが本当に存在するのか、存在するとして誰が承認者で、どのルートを通れば決裁が下りるのか——そこからして分からない、という状態です。従業員30〜100人規模の会社では、稟議のプロセス自体が明文化されていないことが珍しくありません。総務出身の担当者なら経費精算の延長で何となく察しがつくかもしれませんが、営業や製造の現場から「情シス担当」に任命されたばかりの人にとって、これは未知の手続きです。

この記事は、システム開発の外注という高額かつ専門的な支出を、稟議の仕組みそのものを知らない状態から一件通すまでの手順を扱います。稟議で反対意見にどう対抗するかという説得の技術は、稟議で社内の反対を乗り越える説得材料の作り方ですでに詳しく解説されています。ここではその手前、つまり「そもそも何を、どの順番で、誰に、どんな粒度で提出すればよいのか」という、初めて稟議を書く人がまずつまずく実務の型を整理します。

この記事で分かること

30〜100人規模の会社で、情シス担当としてシステム開発の発注稟議を初めて書くことになった人が直面する、書式以前の疑問に答えます。

• 自社の決裁ルートをどう調べればよいか（規程が明文化されていない場合を含む）
• 稟議に添付すべき資料の最低限のセットと、その準備順序
• 金額規模によって決裁者が変わる仕組みと、事前に確認すべきポイント
• 稟議を出す前に「根回し」としてやっておくべきこと
• 差し戻しされたときの典型パターンと、修正の考え方

システム開発の予算そのものの組み立て方や、経営層を説得する材料の作り方は範囲外とし、決裁を通すための手続き上の道筋に絞って解説します。

なぜ30-100人規模で稟議のハードルが特に高いのか

10人未満の会社であれば、社長との距離が近く、システム化の相談も「ちょっといいですか」の一言で済むことが多いものです。一方、300人を超える会社であれば、情シス部門が独立し、稟議のフォーマットや決裁ルートも制度として確立していることがほとんどです。

30〜100人規模はちょうどその中間にあり、組織としての体制は整いつつあるものの、情シス業務を専任で担う人がいないまま、総務や経理の担当者が「ついでに」情シスを兼務しているケースが大半です。中小企業庁が公表している中小企業白書でも、DXを推進する人材の不足が中小企業共通の課題として指摘されており、特に情シスという専門領域を持つ人材が社内に育っていない会社ほど、稟議という手続き自体に不慣れなまま高額な意思決定を迫られる構図になりがちです。この「制度と人材のギャップ」が、30〜100人規模特有の難しさだと捉えると、これから紹介する手順の意味が理解しやすくなります。

稟議規程が「ない」会社は珍しくない

まず前提として押さえておきたいのは、従業員30〜100人規模の会社の少なくない割合で、稟議規程が正式な文書として整備されていないという事実です。就業規則や経理規程は労働基準法や税法の要請で作らざるを得ませんが、稟議のルールは法律上の義務がないため、後回しにされがちです。

規程が存在しない場合、実務上のルートは次のいずれかになっていることが多いです。

• 慣習ルート: 「金額が大きいものは全部社長に直接持っていく」という、明文化されていない暗黙のルール
• 属人ルート: 「この手の話はまず経理の〇〇さんを通す」という、特定の個人を経由する非公式な経路
• 部門長ルート: 各部門長の裁量に決裁が委ねられており、情シスがどの部門長の傘下かで扱いが変わる

自分の会社がどのパターンかを、規程を探すことに時間をかけるより先に、実際に過去の稟議を扱った人（経理担当、総務担当、直属の上司）に直接聞いてしまうのが早道です。「システム関連の支出で、過去に一番大きかった稟議はどう通しましたか」と聞けば、実際に機能しているルートが見えてきます。

決裁ルートを確認する3つの質問

初めて稟議を書く前に、次の3つを確認しておくと手戻りが大幅に減ります。

1. 誰が最終決裁者か: 社長ひとりなのか、取締役会での議決が必要なのか。30〜100人規模では社長の一存で決まる会社も多いですが、金融機関からの借入枠や株主構成によっては取締役会マターになっている場合もあります。
2. 金額でルートが分岐するか: 「〇〇万円未満は部長決裁、以上は社長決裁」といった金額の閾値があるかどうか。一般的な稟議規程の設計では、10万円未満・10万円〜50万円・50万円超といった区分で決裁権限を分けるケースがよく見られますが、これはあくまで一例であり、自社の実際の閾値を確認する必要があります。閾値を知らずに準備を進めると、想定していた決裁者と実際の決裁者が食い違い、資料の粒度をやり直すことになります。
3. どの経路で提出するか: 紙の稟議書に押印で回すのか、ワークフローシステムに入力するのか、あるいはメールと口頭確認の組み合わせなのか。ツールが導入されていない会社では、経路自体が「まず経理に相談し、経理から社長に話を通してもらう」という人を介したプロセスになっていることもあります。

これらは経理担当か総務担当に聞けば数分で分かることです。情シス担当が経理出身でない限り、遠慮せずに聞きに行くべき最初のステップです。

30-100人規模ならではの「組織の中間層の薄さ」

100人未満の会社、特に創業から日が浅い、あるいはオーナー経営が続いている会社では、大企業のような多段階の決裁ルートが存在しないことがむしろ一般的です。部長職はいても、実質的な決定権は社長に集中しているというケースは珍しくありません。この場合、稟議書という文書の完成度よりも、社長との日常的な会話の中でどれだけ事前に情報共有できているかが、決裁のスピードを左右します。

逆に、従業員数が100人に近づき、部門ごとに予算管理が独立してきた会社では、情シスが持つ予算枠自体が存在しない、あるいは総務や管理部の予算枠に間借りしている状態のことがあります。この場合は「そもそもこの支出はどの部門の予算から出すのか」という、決裁ルート以前の予算所属の問題から確認する必要があります。自分の会社がどちらの状態に近いかを見極めることが、稟議の準備の出発点になります。

稟議書サンプルの構成イメージ

書式が定まっていない会社では、A4一枚で次のような構成にまとめると、初めてでも大きく外しません。

件名: 〇〇業務システム化の件（開発会社への発注承認のお願い）

1. 現状の課題
   （Excelでの二重管理により月10時間の手作業が発生している、等）

2. 解決の方向性
   ・現行のExcel台帳をクラウド型の管理システムに置き換える
   ・入力担当者を1名から複数名に拡張可能にする

3. 概算費用
   ・初期費用: 〇〇万円〜〇〇万円（相見積もり前のためレンジで記載）
   ・想定される保守費用: 月額〇万円程度

4. スケジュール
   ・9月: 相見積もり取得
   ・10月: 発注先決定
   ・12月: 稼働開始（想定）

5. 発注先候補
   ・A社、B社（いずれも同規模企業の導入実績あり）

6. 懸念事項と対応
   ・移行期間中の並行運用が必要（1ヶ月程度を想定）

これはあくまで叩き台であり、金額や日程はすべて確定情報である必要はありません。「レンジで書く」「想定と明記する」ことに抵抗を感じる担当者もいますが、決裁者側もこの段階の稟議に完璧な確定情報を求めていないことがほとんどです。むしろ、不確定な部分を隠さずに明示している方が、後になって「話が違う」というトラブルを避けられます。

稟議に添付する資料の最低限セット

システム開発の発注稟議で、決裁者が最低限求める情報は次の5点に整理できます。これらが揃っていないと、差し戻しではなく「継続審議」という形で時間だけが過ぎていく事態になりがちです。

重要なのは、初回の稟議提出時点でこの5点すべてを完璧に仕上げる必要はないということです。多くの会社では、稟議は一発勝負ではなく「まず概要で相談し、方向性の了承を得てから正式な金額と契約内容で本申請する」という二段階の運用が実質的に機能しています。いきなり完成度の高い資料を作ろうとして時間をかけすぎるより、早い段階で決裁者の反応を一度確かめる方が、結果的に手戻りが少なくなります。

「概算費用」の欄で見積もりの内訳をどう読めばよいか分からない場合は、システム開発の見積書、この内訳の見方で損を防ぐで工数・単価・バッファといった項目の意味を先に押さえておくと、決裁者への説明もスムーズになります。

IT導入補助金を稟議に絡める場合の注意

概算費用の欄で「補助金を使えば実質負担はもっと少なくなる」という説明をしたくなる場面がありますが、ここは慎重に扱うべきポイントです。中小企業基盤整備機構が運営する「デジタル化・AI導入補助金2026」の通常枠では、補助率は原則1/2以内（一定の賃上げ要件を満たす場合は2/3以内）、補助額は業務プロセス数に応じて5万円以上450万円以下という枠組みが公表されています。ただし対象となるのはあらかじめ事務局に登録された「ITツール」（ソフトウェア・クラウド利用料が必須経費）であり、要件定義から積み上げるフルスクラッチ開発がそのまま対象になるとは限りません。稟議の段階で補助金を前提にした費用感を出してしまうと、後になって対象外と判明した際に決裁の前提が崩れます。補助金の活用は、対象ツールの要件を開発会社に確認したうえで、正式な費用が固まってから改めて稟議に反映する方が安全です。制度の詳細や対象経費の考え方はIT導入補助金でシステム開発はできるかで個別に整理しています。

金額感が固まる前に相談する「事前打診」

30〜100人規模でひとり情シスが陥りやすい失敗は、相見積もりまで取ってから初めて上司や社長に話を持っていき、「そもそもその予算は出せない」と一蹴されることです。開発会社に問い合わせて見積もりを取るには、開発会社側にもそれなりの工数がかかります。会社の意思決定者が想定している予算感と、実際に開発会社から出てくる見積もりの水準がかけ離れている場合、相見積もりの労力そのものが無駄になりかねません。

これを避けるには、正式な稟議の前に「事前打診」を挟むことが有効です。決裁者に対して、口頭かメールで次のような短い相談を先にしておきます。

「〇〇の業務でこういう課題があり、システム化を検討したいのですが、ざっくり数十万円〜数百万円くらいの規模感で相談してもよいでしょうか」

この段階で決裁者から「その規模なら検討の余地がある」という反応が得られれば、その後の相見積もり取得や資料作成に安心して時間をかけられます。逆に「そんな予算は出せない」という反応であれば、その時点で方向性を見直せます。事前打診は稟議規程には出てこない手続きですが、30〜100人規模の会社では意思決定者との距離が近いぶん、この非公式な一往復が最も効率的な時間の使い方になることが多いです。

決裁者ごとに刺さるポイントは違う

同じ稟議書でも、決裁者が誰かによって重視するポイントは変わります。特に情シス担当として日が浅いうちは、この違いを意識せずに一枚の資料をそのまま提出してしまいがちです。

• 社長（オーナー経営者が多い）: 投資対効果と、会社全体の優先順位の中でこの投資がどこに位置するかを重視する傾向があります。技術的な詳細より「なぜ今なのか」「他の投資と比べてどうか」という説明が響きやすくなります。
• 経理・財務担当: キャッシュフローへの影響、支払いタイミング、既存の予算枠に収まっているかを確認します。分割払いが可能かどうかも聞かれやすいポイントです。
• 現場部門長: 自部門の業務がどう変わるか、移行期間中の負担がどの程度かを気にします。技術的な正しさより、現場が混乱しないかという実務的な懸念が中心です。

決裁ルートに複数の関係者が絡む場合、同じ資料を使い回すのではなく、説明の順番や強調するポイントを相手に合わせて微調整すると、稟議が滞りなく進みやすくなります。

差し戻しの典型パターンと対処

初めての稟議で差し戻しに遭うパターンには、いくつかの典型があります。

• 「他に方法はないのか」: 既存のExcelや無料ツールでの代替案を検討したかを聞かれるパターンです。既存の方法で対応できない理由（限界の具体例）を1〜2点、事前に用意しておくと即答できます。
• 「なぜその会社なのか」: 発注先の選定理由が説明できないパターンです。相見積もりを取っていない段階でこの質問が来ると答えに窮するため、可能であれば候補を2〜3社挙げておくだけでも印象が変わります。
• 「保守や運用はどうなるのか」: 開発して終わりではなく、その後の保守契約や運用体制まで聞かれるパターンです。初期費用だけでなく、稼働後の月額費用や対応範囲についても、概算で構わないので触れておくと差し戻しを避けやすくなります。

差し戻しは失敗ではなく、決裁者が真剣に検討している証拠でもあります。ただし、同じ質問に何度も答えられずに稟議が停滞すると、社内で「あの案件は進んでいない」という印象がついてしまい、次の稟議にも影響します。差し戻しを受けたら、その場で全項目を作り直すのではなく、指摘された論点にピンポイントで回答を追加する形で、スピード重視の修正を心がけるのが得策です。

「なぜその会社なのか」に備えるなら相見積もりを先に動かす

差し戻しパターンの中でも、「なぜその会社なのか」という質問は最も答えに窮しやすいものです。ひとり情シスが兼任で動いている場合、稟議の準備と並行して複数社に問い合わせる余力がなく、結果として1社にしか話を聞いていない状態で稟議を出してしまうことがあります。可能であれば、稟議提出の前段階、あるいは事前打診の直後というタイミングで2〜3社への問い合わせだけでも動かしておくと、この質問への備えになります。相見積もりを1人でどう回すかという実務手順は、ひとり情シスが1人で相見積もりを取って開発会社を比較する実務手順で具体的なフローとして整理しています。

「稟議」という言葉自体を使わない会社もある

ここまで「稟議」という前提で話を進めてきましたが、30〜100人規模の会社の中には、そもそも「稟議書」という文書形式を使っていない会社も存在します。社長への口頭確認と、事後の経理処理だけで完結している会社では、正式な稟議書を作ろうとすること自体が空回りになる場合があります。

自分の会社にそうした文書文化がないと分かったら、無理に「稟議書」という体裁にこだわる必要はありません。その場合でも、この記事で挙げた5点（現状の課題・解決の方向性・概算費用・スケジュール・発注先候補）は、口頭で説明する際の骨子としてそのまま使えます。メモ書き程度でよいので、自分の手元には必ず要点を文書化しておくことをおすすめします。口頭のやり取りだけで進めてしまうと、後になって「言った・言わない」の食い違いが起きたときに確認する材料がなくなるためです。

情シス独自の予算枠がない場合の対処

30〜100人規模の会社では、情シス部門としての独立した予算枠が存在せず、総務費や管理費の中に埋没しているケースが多く見られます。この場合、稟議を出す前に「この支出はどの予算区分に計上されるのか」を経理担当に確認しておく必要があります。

予算枠が不明確なまま稟議を進めると、決裁自体は下りたものの、いざ支払いの段階で「この費目には予算が残っていない」という事態が起こり得ます。特に期の途中で発生した想定外の支出は、年度予算の中で調整が必要になることが多く、経理担当のスケジュール感（四半期ごとの締め、決算期前後の繁忙など）を無視して急かすと、協力を得にくくなります。稟議のタイミングを検討する際は、自社の決算期や予算編成のサイクルも合わせて確認しておくと、後工程がスムーズになります。

稟議を通した後にやるべきこと

稟議が承認されたら、そこで気を抜かず次の2点を必ず行っておきます。

1. 承認内容の記録化: 口頭やメールでの承認であっても、承認された金額・範囲・条件を書面（メールでも可）に残しておきます。後日「そんな金額は聞いていない」という食い違いを防ぐためです。
2. 関係者への共有: 経理には支払いスケジュールを、現場部門には今後のスケジュール感を、それぞれ簡潔に共有します。情シス担当がひとりで抱え込んだまま進めると、実際にシステムが動き始めたときに現場の協力が得られず、導入が滞る原因になります。

稟議は「通ったら終わり」ではなく、その後の発注実務・要件整理・相見積もり比較へとつながる最初の関門です。次に進む際は、相見積もりの取り方や要件のまとめ方についても別途整理しておくと、稟議で示した計画と実際の発注プロセスにずれが生じにくくなります。

よくある失敗パターン3つ

初めて稟議を書いた情シス担当が実際につまずきやすい失敗を、ここでまとめて確認しておきます。

失敗1: いきなり完成品の見積もりを持っていく

前述の通り、正式な相見積もりを取ってから稟議を出そうとすると、予算感がずれていた場合に労力が無駄になります。事前打診を挟まずに動いてしまい、決裁者から「そもそもこの規模の投資は今期考えていない」と言われて振り出しに戻る、というパターンは頻発します。

失敗2: 現場部門への説明を後回しにする

情シス担当と決裁者の間だけで稟議を完結させ、実際にシステムを使うことになる現場部門への説明を後回しにすると、稟議は通っても現場の協力が得られず、導入段階で頓挫することがあります。稟議を出す前、あるいは並行して、影響を受ける現場のキーパーソンには一声かけておくと、後々のスムーズな導入につながります。

失敗3: 決裁後の話を稟議書に書かない

稟議書を「発注の承認を得ること」だけを目的とした文書だと捉えると、保守費用や運用体制など、発注後に発生する継続的な費用への言及が抜け落ちがちです。初期費用しか書かれていない稟議書は、後になって「思ったよりランニングコストがかかる」という印象を決裁者に与え、次回以降の稟議の通りやすさにも影響します。

稟議の粒度と要件定義の粒度を混同しない

初めて稟議を書く担当者がもうひとつ陥りやすいのが、稟議書の「解決の方向性」の欄に、開発会社に渡すレベルの詳細な要件を書き込もうとしてしまうことです。稟議はあくまで「この投資をする価値があるか」を判断してもらうための文書であり、画面のレイアウトやデータ項目の詳細まで書き込む必要はありません。

詳細な要件は、稟議が通った後、開発会社とのやり取りの中で固めていくものです。むしろ稟議の段階で細部まで決めてしまうと、開発会社からの提案の余地がなくなり、相見積もりの比較もしづらくなります。稟議では「何を解決したいか」という目的レベルの記述にとどめ、「どう実現するか」という手段の詳細は、要件をまとめる別の作業に譲るという役割分担を意識すると、稟議書の作成そのものが軽くなります。前任者からの引き継ぎがない状態で、この目的と手段の切り分けをどう資料に落とし込めばよいかについては、前任者のいない状態で開発会社に要件を伝えるための資料の作り方で扱っています。

想定される質問と回答の準備

決裁の場でよく出る質問と、その場で答えられるようにしておきたい回答の方向性を整理しておきます。

• 「今じゃなきゃダメなのか」: 先延ばしにした場合の具体的なコスト（手作業の継続時間、ミスのリスク、担当者の負担など）を数値や具体例で示せるようにしておきます。
• 「他社はどうしているのか」: 同業他社の導入事例を厳密に調べる必要はありませんが、業界団体の資料や開発会社からのヒアリングで得た一般論程度は用意しておくと説得材料になります。
• 「失敗したらどうするのか」: 段階的に発注範囲を区切る、小さく試してから本格導入するといった、リスクを抑える進め方を検討していることを伝えられると、決裁者の不安を和らげられます。小さく試す発注の考え方は、小さく発注して試す: PoC発注のすすめで扱っています。

全体のスケジュール感の目安

兼任で情シス業務を担っている場合、稟議にかけられる時間は限られています。目安として、次のようなスケジュール感を持っておくと、逆算しての準備がしやすくなります。

この表はあくまで目安であり、会社の規模や決裁者の忙しさによって大きく変動します。重要なのは、兼任業務の合間を縫って進める以上、最初から「最短でも1〜2ヶ月はかかる」という前提でスケジュールを組んでおくことです。急いで資料の完成度を犠牲にするより、多少時間がかかっても事前打診と資料準備を丁寧に行う方が、結果的に手戻りが少なく済みます。

まとめ

30〜100人規模で初めてシステム開発の外注稟議を書く場合、最初のハードルは書式ではなく「決裁ルートを知らないこと」にあります。規程が明文化されていない会社では、経理や総務に直接聞くのが最も早い確認方法です。相見積もりを取る前に事前打診で予算感をすり合わせておくこと、決裁者ごとに刺さるポイントを意識すること、差し戻しにはピンポイントで対応することの3点を押さえれば、初めての稟議でも大きくつまずかずに進められます。

情シス担当としての最初の稟議は、その後の発注・要件整理・契約という一連のプロセス全体の入り口にすぎません。ここで無理に完璧な文書を作ろうとするより、決裁者との対話を重ねながら段階的に精度を上げていく姿勢の方が、兼任で時間の限られたひとり情シスには現実的です。稟議という手続きに慣れていないこと自体は恥じる必要のないことであり、分からない部分は素直に経理や総務、あるいは開発会社に相談しながら進めていくことが、結果として一番の近道になります。

稟議という一枚の書類の裏側には、会社の意思決定の仕組みそのものが表れます。今回の稟議を通す経験は、次にまた別のシステム投資を検討するときの土台にもなります。一度型を作ってしまえば、二度目以降の稟議は格段に書きやすくなるはずです。

参考にした一次情報

• 中小企業庁「2025年版 中小企業白書」第1部第1章第5節（デジタル化・DX、DX推進人材の不足に関する記述）: https://www.chusho.meti.go.jp/pamflet/hakusyo/2025/chusho/b1_1_5.html
• 中小企業基盤整備機構「デジタル化・AI導入補助金2026 通常枠」（補助率・補助上限額・対象経費）: https://it-shien.smrj.go.jp/applicant/subsidy/normal/