システム開発の社内稟議、何を書けば通るか ── 決裁者が見ている4点

現場は困っている。相見積もりも取った。それなのに稟議で止まる。実際の相談でいちばんよく聞くのが、この状態です。

止まる理由は、たいてい書いてある内容ではなく、書いていない内容のほうにあります。稟議書に「業務が非効率なので改善したい」と書いてあって、決裁者が知りたい4点が1つも書かれていない。この記事は、その4点を埋めるためのものです。

なお、これは社内の決裁者に渡す情報の話です。開発会社に渡す情報のほうは開発会社に相談する前に、決めておくと話が早い3つのことに別で書きました。中身が違うので、混ぜると両方が中途半端になります。

「必要です」は、稟議では理由になりません

現場から上がる稟議書には、困りごとが丁寧に書いてあります。転記に時間がかかる、ミスが起きる、月末が遅い。全部本当のことです。

ただ、決裁者の側から見ると判断の材料になりません。困っている業務は社内に20も30もあって、そのどれもが「必要」だからです。問われているのは必要かどうかではなく、今期の予算をここに割り当てるかどうか。典型的な落ち方を3つ挙げます。

落ち方	稟議書に書いてあったこと	決裁者が見つけられなかったこと
金額が判断できない	開発費300万円（1社見積もり）	その300万円が何で決まっているか
効果が読めない	業務が効率化される	いま何時間かかっていて、何時間になるか
怖くて押せない	2026年度中に導入	失敗したときに、いくらで止まるか

1点目 ── 投資額に、根拠があるか

ここで見られているのは金額の高い安いではなく、その金額がどこから出てきたかです。「一式300万円」とだけ書かれた見積書では中身を確認できません。確認できないものには押せないので、差し戻しになります。分解するだけで通ることもあります。

項目	金額（税別）	何で決まっているか
初期費用	50万円	画面8枚（10画面以内のため最小プラン）
月額（12ヶ月）	20万円 × 12	運用保守＋改善 月20時間分
1年目 合計	290万円	追加見積もりなし

金額が何で決まるかを説明できる形になっているかが、ここでの分かれ目です。人月で積まれた見積もりだと「4人 × 3ヶ月」の人数と月数が動いた瞬間に総額が動くので、決裁者としては上限を約束できません。そのあたりの構造はMVP開発の費用は、何で決まるのかに書きました。稟議の通りやすさだけで言えば、総額が動かない形のほうが有利です。

2点目 ── やらなかった場合、いくら失うか

ここが、いちばん抜け落ちます。

稟議書は「これをやりたい」から書き始めるので、やらない場合の話は自然には出てきません。ただ決裁者は、常に「今はやらない」という選択肢と比べています。書き方は単純で、いま人がやっている作業を時間に直すだけです。架空の想定例で出します。

いまの作業	頻度	1回あたり	年間
受注データの転記	週5日	40分	約163時間
月末の突合と修正	月1回	6時間	72時間
「最新はどれ」の確認連絡	週3回	10分	26時間
合計	──	──	約261時間

261時間を社内の時間単価3,000円で置くと、年間78万円です。3年で234万円。ここまで書いて初めて、290万円という数字と同じ土俵に乗ります。

ひとつ注意があります。削減時間をそのまま人件費削減と書くと、「では何人減らすのか」という別の話になります。人を減らす計画がないなら、「本来の業務に戻せる時間」として書いたほうが素直です。

3点目 ── 失敗したとき、損失はどこで止まるか

決裁者が押せない最大の理由は、金額の大きさではなく上限が見えないことです。途中で止めても支払いは発生し、しかも何も残らないことがある。そういう案件を見ている決裁者ほど慎重になります。だから、最悪の場合いくらで止まるかを書きます。

止めるタイミング	そこまでの支払い	手元に残るもの
ラフ・見積もりを見て断る	0円	画面構成のラフ
8週間で作って、使わないと判断	50万円＋月額2ヶ月分	動くシステムと画面設計
12ヶ月の改善契約を満了	290万円	運用中のシステム

初回のお打ち合わせ60分と、3営業日以内に出すラフと見積もりまでは無料です。稟議に添付する資料を作る段階では、まだ支払いが発生していない。これは書いておくと効きます。

途中で止めたときの扱いは契約の形で変わります。請負か準委任か、検収の条件はどこか。システム開発の契約書で、発注側が読むべき5つの場所に読む場所を書いたので、稟議を出す前に一度当てておくと、決裁者に聞かれたときに答えられます。

4点目 ── 誰が責任を持つのか

金額の話ではなく、導入したあと社内で誰が面倒を見るのかという話です。稟議が通ったシステムが1年後に使われなくなる原因は、たいていここにあります。導入担当が異動した、運用の担当が決まっていなかった。決裁者はそれを見ているので、担当者名のない稟議書には慎重になります。

書くべきは3つです。導入を進める担当者。使い始めたあとの運用担当。範囲や仕様を最終的に決める人。3つが同じ人でも構いません。空欄でなければいい。

外注するなら、開発会社側の体制も併せて書きます。相談した相手が設計から運用まで担当するのか、途中で別の会社に渡るのか。ニカゲツは分業せず、下請けも使いません。窓口が変わらないことは、一行書く価値があります。

内製との比較を求められたら、社内システムは内製か外注かに4つの選択肢を1年総額で並べてあります。表をそのまま添付に使えます。

稟議書に貼れる比較表

4点を1枚にまとめると、こうなります。項目名だけ残して、自社の数字に置き換えてください。

観点	今のまま続ける	今回の提案
初期の支出	0円	50万円（税別）
年間の支出	0円	240万円（月20万円 × 12）
年間の作業時間	約261時間	約80時間（見込み）
時間を金額に直すと	約78万円/年	約24万円/年
最悪の場合の損失上限	──	90万円（2ヶ月で中止した場合）
効果の判断時期	──	リリース3ヶ月後の稼働レポート
社内の責任者	（現状の担当）	導入・運用・意思決定の3名

数字は架空の想定例です。時間と金額は自社のものに置き換えてください。大事なのは、左の列が空欄になっていないことです。「今のまま続ける」のコストが0円に見えているうちは、どんな提案も高く見えます。効果の判断時期を入れているのは、決裁者が押したあとに報告を求められる立場だからです。月次の稼働レポートは、そのまま添えられます。

落ちたときに、何を直すか

一度で通らないほうが普通です。落ちた理由がどれに当たるかで、直す場所が変わります。

金額が理由なら、範囲を削ります。画面を減らせば初期費用は下がり、1業務フローに絞ると効果も測りやすくなります。全部を一度に作らないのは、稟議の都合としても理にかなっています。

効果が読めないと言われたなら、2点目の表が弱い。時間の数え方が粗いか、単価の根拠がないかです。ここは経理に相談すると早く埋まります。

時期の問題で落ちたなら、書き直す必要はありません。次の期に同じ内容で出すほうが通ることがあります。理由が分からないまま戻ってきたときは、決裁者に直接聞いてください。

見積書と画面構成のラフは、初回のお打ち合わせから3営業日以内に無料でお出ししています。稟議に添付する資料がない段階でも、お問い合わせからご相談いただいて構いません。他社の見積もりと並べていただくのが前提です。