開発会社から見積もりをもらった。金額は3社で2倍以上ばらついている。これを社内の稟議に載せなければいけないのに、何をどこまで書けば通るのかが分からない。差し戻されればそれだけで2週間遅れます。システム開発の稟議書は書く機会が少ないぶん、社内に前例が無いことも多く、最初の1枚で手が止まりがちです。
先に答えを書くと、システム開発の稟議書が通るかどうかは金額の大きさでは決まりません。決裁者が知りたいのは「なぜ今なのか」「その金額は妥当なのか」「やらなかったらどうなるのか」の3点で、ここに答えていない稟議書は、金額が小さくても差し戻されます。この記事では、書くべき項目と例文、初期費用と運用費の分け方、見積もりに幅があるときの扱い、効果を数字に置き換える方法までを、発注する側の実務として整理します。
この記事のポイント
- 稟議書は金額の大小ではなく、効果と前提の示し方で通るかが決まる
- 初期費用だけ書いて年間の運用費を隠すと、翌年以降に必ず問題になる
- 見積もりに幅があるときは、いちばん高い金額を上限として書くほうが後で楽になる
- 全額を一度に通さず、要件定義だけ先に小さく通す進め方も選べる
目次
システム開発の稟議書に書く項目
稟議書の書式は会社ごとに違いますが、決裁者が見る観点は驚くほど共通しています。ここでは、システム開発の稟議に必ず入れておきたい項目と、金額の書き方を整理します。
先に押さえておきたいのは、稟議書は説得の文書ではなく、判断材料を渡す文書だという点です。熱意を書き足すより、判断に必要な数字と前提を抜けなく並べるほうが速く通ります。
稟議書と決裁・申請の違い
言葉が混ざりやすいので先に整理します。稟議は、権限を持つ人が一堂に会して決める代わりに、書面を回して順番に承認をもらう仕組みです。決裁は、その最終的な承認そのものを指します。つまり稟議書は「決裁をもらうために回す書類」です。
ここが分かっていると、書き方の方針が決まります。稟議書は複数の人が順番に読みます。情報システム部長、経理、役員と、読む人の関心はそれぞれ違います。技術に詳しくない人が途中に入る前提で書くのが基本です。専門用語を並べた稟議書は、意味が分からないという理由だけで止まります。
もう一つ、金額によって決裁者が変わる会社がほとんどです。書き始める前に、自社の決裁権限規程で今回の金額がどこまで上がるのかを確認してください。役員決裁まで上がるなら、その人が知りたい粒度で書く必要があります。
必ず入れる7つの項目
システム開発の稟議書に入れる項目は、おおむね次の7つです。会社の書式にこれらの欄が無くても、備考や添付で補っておくと差し戻しが減ります。
| 項目 | 書く内容 | 抜けたときに起きること |
|---|---|---|
| 件名 | 何を導入するのかが一行で分かる表現 | 回覧の途中で後回しにされる |
| 背景と課題 | いま何に困っていて、放置するとどうなるか | なぜ今なのかが伝わらない |
| 目的と効果 | 何がどれだけ良くなるかを数字で | 費用だけが目立ち止まる |
| 費用 | 初期費用と年間の運用費を分けて | 翌年度の予算で揉める |
| 発注先と選定理由 | 何社比較してなぜその会社か | 相見積もりを取ったか問われる |
| スケジュール | 着手から稼働までの時期 | いつ効果が出るか判断できない |
| リスクと対応 | 遅延や追加費用の可能性と備え | 問題が起きたとき責任問題になる |
件名は意外と効きます。「システム導入の件」ではなく「受注処理の二重入力を解消する基幹システム改修の件」のように、読む前に用件が分かる書き方にしてください。回覧の順番が後ろの人ほど、件名だけで優先度を決めています。
背景と課題の例文は、次のような形になります。
| 現在、受注情報を基幹システムと販売管理システムへ二重に入力しており、営業事務3名で月あたり約120時間を要しています。入力ミスによる出荷誤りも月2件程度発生しており、対応工数と信用の両面で損失が出ています。担当者の退職が決まっており、現行の運用を維持することが困難な状況です。 |
初期費用と運用費を分けて書く
システム開発の稟議で最も揉めるのが、ここです。初期の開発費だけを書いて稟議を通し、翌年になって年間保守費の請求が出てきて「聞いていない」となるケースを、私は何度も見ています。
開発費用は、作って終わりではありません。保守費、サーバーやクラウドの利用料、ライセンス料、そして数年後の改修費が続きます。目安として、年間の運用費は初期開発費の1割から2割を見ておくと大きく外れません。金額が分からない段階でも「年額◯◯万円程度を想定」と幅で書いておくほうが、空欄にするより安全です。
費用欄は、次のように分けて書くと決裁者が判断しやすくなります。
| ■初期費用（今年度） ・要件定義：80万円 ・設計・開発・テスト：520万円 ・データ移行：60万円 小計 660万円（税別） ■運用費（次年度以降・年額） ・保守サポート：79万円 ・クラウド利用料：24万円 小計 103万円（税別） ※上記のほか、仕様追加が発生した場合の予備費として初期費用の10%（66万円）を見込んでいます。 |
予備費を最初から書くことに抵抗があるかもしれません。ですが、開発は途中で必ず仕様の追加や調整が出ます。何も書かずに後から追加稟議を出すより、最初に上限を示しておくほうが決裁者の心証は良くなります。
見積もりの幅をどう扱うか
相見積もりを取ると、同じ要望なのに金額が2倍から3倍違うことが普通に起きます。ここで多くの人が迷うのが、稟議書にどの金額を書くかです。
結論としては、本命の会社の金額ではなく、候補のうち高いほうの金額を上限として書いておくことをおすすめします。安い金額で通してしまうと、交渉の結果その会社に決まらなかったときに再稟議が必要になります。上限として通しておけば、その範囲内であれば発注先を変えても決裁を取り直さずに済みます。
金額差が大きいときは、その理由も一行添えてください。差が出るのはたいてい、対象範囲の解釈が違う、データ移行が含まれていない、テストの工数の見方が違う、保守が別見積もりになっている、のいずれかです。理由が書いてあると「なぜ高いほうを選ぶのか」を説明せずに済みます。
そもそも各社の見積もりが同じ前提で並んでいるかは、稟議に載せる前に点検しておくべきです。前提が揃っていない見積もりを比べても意味がありません。見積書の読み方や人月単価の考え方は、システム開発の見積もりの妥当性を判断する記事で詳しく整理しています。あわせてシステム開発見積もりチェックシート（危険サインを見抜く60項目）を使うと、抜けている前提を機械的に洗い出せます。
金額そのものが相場から外れていないかを確かめたい場合は、システム開発の費用相場を規模別に整理した記事も参考にしてください。
システム開発の稟議書を通す書き方
項目がそろっても、書き方次第で通り方は変わります。ここからは、実際に決裁までたどり着かせるための書き方を見ていきます。
基本の考え方は一つです。決裁者は、あなたを信用するかどうかではなく、その投資を説明できるかどうかで判断しています。決裁者が自分の上司に説明できる形になっているかを基準にしてください。
効果を数字に置き換える
費用だけが書かれた稟議書は、まず通りません。効果を数字にする作業が、実質的に稟議書づくりの本体です。
やり方は単純で、いまかかっている時間と件数を洗い出し、それがどれだけ減るかを見積もります。月120時間の作業が40時間になるなら、削減は月80時間。時給換算3,000円なら月24万円、年288万円です。初期費用660万円なら、単純計算で約2.3年で回収できることになります。
効果の書き方の例です。
| 本改修により、二重入力の作業を月120時間から40時間へ削減できる見込みです（削減80時間／月）。人件費換算で年間約288万円の削減にあたり、初期費用660万円は約2.3年で回収する試算です。あわせて入力ミスによる出荷誤り（月2件）の解消を見込んでおり、対応工数と再発送費用の削減も期待できます。 |
ここで大切なのは、削減した時間を何に振り向けるかまで書くことです。「3名が80時間空きます」で止めると、では人を減らせるのかという話になり、現場が反発します。「空いた時間を新規顧客の対応に充てる」「残業を減らして人件費を抑える」など、方針まで書いておくと社内が動きやすくなります。効果の測り方をもう少し詰めたい場合は、投資対効果の測り方を整理した記事の考え方がそのまま使えます。
数字にしにくい効果の示し方
すべての効果が時間で測れるわけではありません。属人化の解消、意思決定の速さ、監査対応、顧客からの信用といった効果は、金額に直せません。ここで無理やり数字をひねり出すと、根拠を突かれて逆効果になります。
数字にしにくい効果は、金額ではなく「起きたら困ること」の形で書くのが実務的です。担当者が1人しかいない業務なら、その人が抜けたときに何日業務が止まるのかを書きます。監査対応なら、指摘を受けた場合にどんな対応が必要になるのかを書きます。損失の大きさで語ると、決裁者は判断できます。
私の感覚では、金額に直せる効果と直せない効果を混ぜて一つの数字にしてしまう稟議書がいちばん危ないです。金額で語れる部分だけを回収年数の計算に使い、それ以外は別枠で並べる。この分け方をしておくと、後で数字の根拠を問われても崩れません。
分割して通すという選択
金額が大きくて通る見込みが薄いとき、全額を一度に通そうとしないでください。システム開発は、工程を分けて別々に稟議を出せます。
よく使う分け方は、要件定義だけを先に通す形です。要件定義に80万円かけて、そこで作るものと金額を確定させ、本開発の稟議はその結果を持って改めて出します。決裁者から見ると、いきなり660万円の判断を求められるより、80万円で情報を買ってから判断するほうがはるかに承認しやすくなります。
この進め方には、発注側にとっての実益もあります。要件定義を終えた時点で見積もりの精度が上がるため、本開発の稟議に書く金額の確からしさが変わります。最初の稟議で「今回は要件定義までの承認をお願いし、本開発は改めて上程します」と明記しておけば、二度手間という印象も与えません。
追加費用が出たときの再稟議
開発中に仕様が増えるのは、失敗ではなく通常のことです。問題になるのは、増えたときの扱いを最初に決めていない場合です。
最初の稟議に予備費を書いておくと、その範囲内なら再稟議なしで対応できます。範囲を超える場合は追加稟議になりますが、そのときも「当初想定していなかった◯◯が必要になった」という経緯を書けるかどうかで通りやすさが変わります。開発会社との打ち合わせ記録を残しておいてください。
あわせて、追加が発生したときに誰が判断するのかも社内で決めておきましょう。金額いくらまでは担当者判断、それを超えたら部長承認、といった線引きが無いと、開発が止まります。
差し戻される稟議の共通点
最後に、差し戻されやすい稟議書の特徴を挙げます。現場で見てきたものを中心にまとめます。
- 課題の記述が抽象的で、放置した場合に何が起きるかが書かれていない
- 費用は書いてあるが、効果が「業務効率化」など言葉のままで数字が無い
- 初期費用だけで、翌年以降の運用費に触れていない
- 相見積もりを取ったかどうかが分からず、選定理由が書かれていない
- 専門用語がそのまま使われ、技術に詳しくない決裁者が読めない
- 「ご検討をお願いします」で終わり、いつまでに何を決めてほしいかが無い
最後の項目は見落とされがちです。稟議書には、いつまでに承認が必要かと、その期限の理由を書いてください。「開発会社の見積もり有効期限が◯月◯日のため」「◯月着手で年度内稼働に間に合うため」と書いてあると、回覧が止まりにくくなります。
提出前に、社内で技術に詳しくない人に一度読んでもらうことをおすすめします。読んで意味が分かるか、金額の根拠が伝わるかを確認してから回すと、差し戻しは大きく減ります。
- Q. 相見積もりは何社取れば十分ですか？
- A. 3社が一般的な目安です。2社だと比較の材料として弱く、5社を超えると評価する側の負担が大きくなります。ただし社内規程で必須の社数が決まっている場合はそちらが優先です。稟議書には、何社に声をかけ、何社から回答があったかまで書いておくと親切です。
- Q. 稟議書に見積書は添付すべきですか？
- A. 添付してください。ただし本文の費用欄は見積書を見なくても分かるように書きます。決裁者が添付を開かないと金額が分からない稟議書は、それだけで止まりやすくなります。
- Q. 効果の数字が出せない場合はどうすればよいですか？
- A. 無理に金額へ換算せず、放置した場合に起きることを具体的に書いてください。担当者が抜けたら何日止まるか、法令対応が間に合わないとどうなるか、といった損失の形で示すほうが、根拠の薄い試算より説得力があります。
