システム開発の赤字案件は、着手してから生まれるように見えて、実は見積の段階で原因が作られていることが少なくありません。入れ忘れた作業、書いていない前提、承認を通らずに出た金額。この記事では、見積で赤字を防ぐためのチェックを「見落としやすい費用項目」「粗利率の承認ルール」「版管理と承認フロー」の3つに分けて整理し、見落としが利益をどれだけ削るかを試算します。
見積の段階で赤字が生まれる理由
開発プロジェクトの遅れは珍しいことではありません。日本情報システム・ユーザー協会（JUAS）の「ソフトウェアメトリックス調査2020」では、予定より20%以上工期が遅れたプロジェクトの割合は、全体684件の13.0%（納期優先267件では9.0%、納期優先以外417件では15.6%）でした[1]。同協会の2007年の調査を報じた記事では、工期遅延の原因として最も多かったのは「要件仕様の決定遅れ」と紹介されています[2]。
遅れや手戻りそのものを完全になくすことはできません。しかし、見積の段階で「起こりうる作業を誰が負担するか」を決めておけば、起きたときに追加の費用として請求するのか、自社で吸収するのかが明確になります。赤字の多くは、この取り決めが無いまま作業が増えることで生まれます。
なお、同じJUASの2020年調査では、ユーザー企業が支払った総費用と工数の関係を「総費用＝117.15×全体工数（万円）」という式で示しています（パッケージ開発を除く）[1]。ユーザー側から見た1人月あたりの費用の目安として、自社の見積単価を見直す際の参考になります。
見落としやすい費用項目チェックリスト
次の表は、開発の見積で入れ忘れやすい作業の例です。項目ごとに「見積に計上する」「対象外とする」「顧客の負担とする」「別途見積とする」のどれかを決め、空欄のまま見積を出さないことが大切です。
| 分類 | 見落としやすい作業 | 起きやすい場面 |
|---|---|---|
| データ | 移行データの調査・名寄せ・クレンジング | 旧システムのデータに不備や重複がある |
| 打合せ | 追加の打合せ・議事録作成・合意の遅れへの対応 | 関係部署が多く、決定に時間がかかる |
| 変更 | 仕様変更・レビューの手戻り | 要件が固まらないまま設計に入る |
| 外部連携 | 外部システムの調査・API仕様の変更への対応 | 連携先の資料が古い、仕様が途中で変わる |
| 非機能 | 性能試験・セキュリティ診断への対応 | 本番直前に顧客の監査部門から求められる |
| 移行・運用 | 移行リハーサル・本番立会い・運用トレーニング・マニュアル作成 | 「当然やってくれる」と顧客が考えている |
| 管理 | プロジェクト管理・外注先の管理 | 開発工数だけを積み上げて見積を作る |
| 経費 | クラウド利用料・ライセンス・交通費・出張費 | 開発・検証環境の費用を誰が持つか決めていない |
| 納品後 | 検収の遅れ・無償対応の期間・問い合わせ対応・終了時の引継ぎ | 検収後の不具合対応や質問が続く |
納品後の対応は特に見落とされがちです。情報処理推進機構（IPA）の解説によると、2020年4月に施行された改正民法では、契約不適合（いわゆる不具合）について、注文者は「契約不適合を知った時から1年以内」にその旨を通知すればよいとされました[3][4]。IPAのモデル契約では起算点を検収完了時とする考え方を残していますが[3]、いずれにしても、契約で定める期間と無償対応の範囲を見積の前提として決めておく必要があります。
前提条件と除外事項を書く
費用項目を決めたら、その判断を見積書の前提条件として書きます。金額だけが独り歩きすると、後で「その作業も含まれていると思っていた」という食い違いが起きます。少なくとも次の内容を見積書や提案書に記載します。
- 何をやるか（作業範囲）と、何を納品するか（成果物）
- やらないこと（除外事項）
- 顧客に用意してもらうもの（資料・環境・担当者の時間）
- 見積の前提条件と、まだ分かっていないこと（見積の幅）
- 金額が変わる要因と、変更を誰が決めるか
- 再見積をするタイミング（例：要件定義の完了時）
- 検収と請求の条件
要件が固まっていない段階では、全体を1つの金額で約束せず、「要件定義までを確定、以降は概算」として、要件定義の完了後に再見積する形にすると、リスクを抑えやすくなります。
粗利率の承認ルールを決める
営業担当者は受注を優先しがちで、競合がいる案件では値引きの圧力もかかります。そこで、粗利率に応じて承認者を変えるルールを決め、低い粗利の見積が担当者の判断だけで出ないようにします。次は一例です。
| 粗利率（例） | 承認者（例） | 添える情報（例） |
|---|---|---|
| 30%以上 | 課長 | 費用項目のチェック結果 |
| 25%以上30%未満 | 部長 | 上記に加え、値引きの理由 |
| 25%未満 | 役員 | 上記に加え、受注する理由（今後の取引・戦略上の意味）と赤字になった場合の対応 |
基準となる粗利率は、自社の販売管理費の水準や過去の案件の実績から決めます。大事なのは、基準を下回る見積を禁止することではなく、「誰がどんな理由で認めたか」を残すことです。受注後に見積と実績の差を理由つきで記録しておくと、次の見積の精度も上がります。
版管理と承認フロー
見積は、顧客とのやり取りの中で何度も改訂されます。ファイルを上書きしていくと、どの版を顧客に出したのか、どの版が承認を通ったのかが分からなくなります。次のルールで管理します。
- 版を上書きしない。改訂のたびにv1、v2…と新しい版として残し、変更点と理由を記録する。
- 状態を決める。「下書き→社内レビュー→承認→顧客提示」のように状態を決め、承認前の版は顧客に出さない。
- 承認は版ごとに行う。v1が承認済みでも、金額や条件を変えたv2は改めて承認を通す。
- 受注は承認済みの版から。顧客が合意した版と、承認済みの版が一致していることを確かめてから受注を登録する。
- 追加作業は変更要求として扱う。受注後の追加は口頭やメールだけで始めず、見積と承認を経てから着手する。
試算：見落とし5人月で粗利はどう変わるか
試算（数字はすべて仮の条件です。御社の単価・工数に置き換えてください）
条件：請負の開発案件。見積工数20人月、原価単価80万円/人月、見積金額2,200万円。
粗利 2,200万円 − 1,600万円 ＝ 600万円（粗利率 27.3%）
入れ忘れ：データ移行 2人月 ＋ プロジェクト管理 2人月 ＋ 納品後の無償対応 1人月 ＝ 5人月
実際の原価：25人月 × 80万円 ＝ 2,000万円
粗利 2,200万円 − 2,000万円 ＝ 200万円（粗利率 9.1%）
さらに工数が当初見積の20%（4人月）増えた場合：原価 2,320万円、粗利 −120万円（赤字）
見落とし5人月だけで粗利は600万円から200万円に下がり、そこに手戻りが重なると赤字になります。先のJUASの調査で、20%以上遅れたものが全体の13.0%あったことを考えると、珍しい事態ではありません。見積の段階で5人月分を計上するか、顧客負担・別途見積と明記しておけば、この差は防げます。
まとめ
- 赤字の多くは、起こりうる作業を誰が負担するかを決めないまま見積を出すことで生まれます。
- 見落としやすい費用項目は、項目ごとに「計上・対象外・顧客負担・別途見積」を決め、空欄で出しません。
- 判断の結果は、前提条件・除外事項として見積書に書きます。
- 粗利率に応じて承認者を変え、誰がどんな理由で認めたかを残します。
- 見積は版を上書きせずに残し、承認済みの版からだけ受注を登録します。
COMPASでできること
COMPASの見積の画面では、見積を版として上書きせずに残し、下書き→レビュー依頼→承認の流れで管理します。赤字リスクになりやすい作業（契約見積では23項目）を「見積に計上／対象外／顧客負担／別途見積」に振り分け、振り分けが済むまで承認できない作りです。粗利が基準を下回る版には、役員承認が必要であることが表示されます。何をやるか・除外事項・前提条件など10項目の記入状況も確認できます。受注は承認済みの見積からだけ登録でき、受注後は見積と実績の差を理由つきで記録できます。
出典
- 一般社団法人日本情報システム・ユーザー協会（JUAS）「ソフトウェアメトリックス調査2020 システム開発・保守調査」（2020年4月16日） https://juas.or.jp/cms/media/2020/04/20swm_pr.pdf
- ＠IT「最適な工期は『投入人月の立方根の2.4倍』、JUASが調査」（2007年7月5日） https://atmarkit.itmedia.co.jp/news/200707/05/juas.html
- 独立行政法人情報処理推進機構（IPA）「『情報システム・モデル取引・契約書』からの見直しのポイント」 https://www.ipa.go.jp/digital/model/review-point.html
- 独立行政法人情報処理推進機構（IPA）「改正民法に対応した『情報システム・モデル取引・契約書』」（2019年12月24日公開） https://www.ipa.go.jp/archive/digital/model/model20191224.html