納品書システムは、現状業務の可視化（AsIs）、Fit&Gapの整理、法令・連携・移行の要件を固めてから発注します。
要件定義とRFPは、開発の成否を左右する最も重要な工程です。要件定義書とRFPの作り方を、発注側の担当者の目線で順に解説します。
▼全体ガイドの記事
・納品書システムの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
現状業務の可視化とあるべき姿の設計
要件定義は、納品書に関わる現状業務（AsIs）を可視化するところから始めます。納品書の発行では、誰が、いつ、どのデータを使い、どの順番で進めているかを明らかにします。また、リサーチノートも、現場の実態を起点にしない設計が失敗の本質だと指摘しています。
納品書まわりの業務フローの洗い出し
まずは、受注情報の受け取りから、明細作成、金額・税の計算、承認までを工程ごとに書き出します。続けて、発行・送付、控えの保管、請求・売上計上への連携までを、同じ手順で整理します。
- 取引先ごとの違い：様式や特殊な例外処理、担当者だけが知るルールを洗い出す
- 発行の実態：繁忙期の件数と月末への集中度合いをつかむ
- 部署ごとの課題：二重入力や手作業、残業などの痛点を整理する
受注担当や経理など各部署の担当者にヒアリングし、現場ごとの困りごとを集めます。把握した痛点は、システム化で優先して解決する課題になります。現状を正確に可視化することが、要件定義の土台になります。
あるべき姿（ToBe）と目標指標の設定
現状を可視化したら、次に、あるべき姿（ToBe）を描きます。課題が解消された後の業務を関係者と合意しながら、具体的な形にしていきます。
- 作成：受注データから納品書をワンクリックで生成
- 承認と送付：決裁済みの納品書を、PDFにしてメールで自動送付
- 後続業務：請求・売上計上までの自動連携
ToBeとあわせて、効果を測る目標指標も決めます。リサーチでは、月次決算が3週間から1週間へ短縮された事例や、経理工数を月20時間削減し、年72万円相当を削減したという試算が示されています。
一次データを参考にしながら、発行作業時間を◯割削減、月次決算を◯日早期化といった定量目標を置きます。また、定量目標があると、要件の優先順位が明確になり、導入後の効果も検証できます。一方で、目標がないと、機能の盛り込み合戦になりがちです。
Fit to StandardとFit&Gap表の作り方
近年重視されるFit to Standard（標準適合）は、自社業務を作り込まず、可能な限り標準機能に合わせる考え方です。過度なカスタマイズは、費用と保守負担を増やし、法改正への対応も難しくします。そのため、固有ルールや得意先の要求と標準との差をどう扱うかが、要件定義の要点になります。
Fit&Gap表による標準適合と差分の整理
Fit&Gap表は、要件を標準機能で実現できるもの（Fit）と、差分対応が必要なもの（Gap）に分けて示す表です。
- 標準機能で対応：Fitとして整理
- 標準では不足：Gapとして対応方針を検討
- Gapの対応：カスタマイズ、運用吸収、要件見直しから選ぶ
テンプレートの自由度や得意先別の様式、税計算などを項目にして、標準で満たせるかを評価します。承認フローの段数も、項目に加えます。
表を使って差分を早い段階で一覧にし、経営層も交えて、本当にカスタマイズが必要かを判断します。特に、すべてのGapを埋めると、費用が膨らみ、保守も重くなります。
リサーチノートでも、標準適合という理想と、維持が必要な社内ルールや得意先要求との間のギャップが、現場の摩擦を生むと指摘されています。
カスタマイズ費の目安は、最小で100万〜300万、標準で500万〜1,000万、大規模で1,000万〜3,000万以上です。このため、Gapの扱い方が総コストを左右します。
RFP（提案依頼書）に盛り込むべき項目
整理した要件は、RFP（提案依頼書）にまとめてベンダーへ提示します。また、必須・推奨・任意の優先順位を明示します。
- 目的と範囲：プロジェクトの目標と対象業務
- 業務・データ：必須要件、希望要件、データ量、得意先数
- 実施条件：連携要件、予算、希望日程、評価基準
優先順位を示すと、提案を公平に評価でき、過剰な機能提案にも流されにくくなります。さらに、Fit&Gap表を添付して、Gapへの対応方針を各社に尋ねると、提案を比較しやすくなります。
リサーチでは、BOXILの主要19サービス調査で15社が価格非公開でした。価格を公開している製品が少ないため、具体的なRFPが見積もりの前提になります。特に、曖昧なRFPには曖昧な見積もりが返り、追加費用の原因になります。
法令対応・連携要件の定義
法令対応と他システムとの連携を曖昧にすると、後工程で追加開発や費用増が起きがちです。そこで、対応すべき法令と連携先を特定し、手戻りを防ぎます。
インボイス・電帳法の対応要件の明記
要件書には、インボイス制度と電子帳簿保存法への対応を盛り込みます。そのうえで、自社の取引パターンに沿って必要な処理を定めます。
- インボイス：登録番号、税率区分、税率別消費税額を記載
- 税計算：軽減税率の按分と端数処理のルール
- 電子保存：検索要件、訂正削除履歴、真実性の確保
電子帳簿保存法への対応では、取引年月日・取引金額・取引先で検索できることも、要件に含めます。
将来の法改正への追従範囲も、確認しておきます。リサーチでは、クラウド・サブスク型は定額保守の中で無償対応する一方、オンプレ型は都度の追加開発が必要な傾向にあります。法令対応は運用中も続くため、制度改正時の対応がどこまで保守に含まれるかを確認すると、導入後の継続コストを把握できます。
会計・販売管理・ネットバンキング連携の要件
既存システムとの接続では、対象データと連携方法を具体的に決めます。特に、既存の会計ソフトやネットバンキングとの連携は、比較検討時の重要な判断材料になります。
- 接続先：会計、販売管理、受注システム、ネットバンキング
- 連携内容：対象データと、やり取りの頻度
- 連携方式：APIかCSVバッチか
債権管理のイレギュラーも、自動化の精度まで詰めておくと連携要件が具体的になります。たとえば、振込名義の相違、複数請求の合算、手数料差引では、納品・請求データと入金データをどこまで自動で照合するかが、経理工数に直結します。連携の細部を要件に書くと、提案が具体化し、リリース後の想定外の不具合を避けやすくなります。
債権消込のイレギュラー処理の要件化
請求から入金消込までを自動化する場合は、例外をどこまで自動で照合するかを具体化します。曖昧なままだと、稼働後も手作業が残るおそれがあります。
- 名義相違：振込名義と取引先名が異なる入金
- 合算入金：複数請求分をまとめて支払われたもの
- 手数料差引：振込手数料を差し引いた入金
実際に発生する例外を洗い出し、頻度の高いものから自動化の優先順位をつけます。
すべてを自動化すると開発費が膨らむため、頻度と工数削減効果の釣り合いで線を引きます。こうした例外の自動化精度は、比較時の論点になります。要件を具体的に詰めることが、連携の費用対効果を高める鍵になります。
データ移行・クレンジング要件の定義
データ移行とクレンジングは軽視されがちですが、プロジェクトの遅延を招きやすい要件です。取引先・商品マスタや過去の納品履歴を、新しいシステムへ引き継ぎます。
移行範囲とクレンジング方針の決定
すべての過去データを移すか、直近数年分の有効なマスタと取引に絞るかを決めます。また、古いデータを別管理にする方法もあります。
リサーチでは、従業員200名規模の商社で、20年分のデータが3システムに分散していた事例が示されています。その統合には4ヶ月、移行費には数百万円を要しました。
移行範囲を絞ることは、コストと日程を抑える現実的な選択肢です。そのうえで、クレンジング方針を要件として定めます。
取引先、商品、履歴では移行前に整えるべき点が異なるため、データごとに直し方を決めておきます。
- 名寄せ：取引先の表記ゆれや重複登録を一つにまとめる
- 商品情報：廃番商品コードが残っていないかの確認
- 履歴：欠損の補正や受入データの扱いの決定
分散データの統合には数ヶ月かかる場合があります。さらに、勘定科目の統廃合で重複が生じることや、受入データの安易な削除も落とし穴です。そのため、クレンジングを独立した要件として定めると、データ品質を継続して管理しやすくなります。
受入テストと定着支援の要件
要件定義書には、受入テストの方針を含めます。実データを使って発行・連携・法令対応を検証するシナリオを想定します。現場教育やサポートの要件も盛り込みます。
テストの合格基準を決めておくと、稼働の判定が明確になります。一方で、要件が曖昧なままだと、不具合を抱えたまま本番に進むリスクが高まります。
- 操作研修：現場が新しい手順を使えるようにする
- マニュアル：日々の運用手順の整備
- 稼働直後の支援：現場に伴走して定着を支える
リサーチノートでは、失敗原因の大半が、人員の脆弱さ、マニュアル未整備、教育不足にあると指摘されています。加えて、Excelへの固執も失敗につながる要因として挙げられています。
riplaは、フルスクラッチ受託と業務伴走の立場から、要件定義からデータクレンジング、受入テストを経て現場定着まで、一貫した支援を重視しています。そのため、要件定義は機能を並べるだけでなく、導入後の定着まで見据えて設計します。
非機能要件とコスト・スケジュールの定義
性能・セキュリティ・運用保守などの非機能要件も重要です。また、予算と日程の前提を固めることが、現実的なプロジェクトを支えます。曖昧な要件のままだと、月末の処理遅延や監査でのセキュリティ指摘として、稼働後に表面化します。
性能・セキュリティ・可用性の要件
性能は、発行件数や同時利用者数を踏まえて定めます。月末の発行が重なる時期でも、快適に動く処理能力が必要です。
たとえば、月に数千件を一括発行する企業では、その負荷でも遅延しないことを明記します。自社のピーク時の件数を根拠に性能の前提を示し、「速い」とだけ書かないようにします。
- アクセス制御：利用者ごとの権限を定義
- データ保護：通信や保存情報の暗号化を定める
- 運用記録：操作ログを保存する
オンプレ型は、データを自社の管理下に置けるため、セキュリティ統制の面で優位とされます。一方で、クラウド型では、提供元のセキュリティ水準を確認することが論点になります。また、障害時に許容できる停止時間を定め、月次の締めに支障が出ない可用性を要件にします。
予算とTCOの前提の要件化
要件定義では、予算の前提を明確にしておきます。初期費用だけでなく、月額・保守・将来の改修まで含めて、3〜5年の総所有コスト（TCO）で捉えます。
- 費用構造：オンプレ型の保守費はライセンス費の年15〜22%程度で、クラウド型は費用の8割がサブスクです。
- カスタマイズ費：最小100万〜300万、標準500万〜1,000万、大規模1,000万〜3,000万以上です。対応するGapの範囲が総額を左右します。
- 予算と日程：上限内でGapの優先順位を決め、移行・受入テストの工数も見込みます。
予算と日程に無理のない計画を要件に含めると、品質を犠牲にした突貫稼働を避けやすくなります。
まとめ
成否を分けるのは、要件を一貫して具体化することです。本文では、業務の可視化とあるべき姿の設計、Fit to StandardとFit&Gapの整理を取り上げました。さらに、法令・連携要件、データ移行・クレンジング、定着支援まで、一連の工程として扱いました。
カスタマイズ費は、最小100万〜300万から大規模の1,000万〜3,000万以上まで幅があり、Gapの扱いが総額を左右します。そのため、具体的なRFPが実態に即した見積もりにつながります。
要件を固めてから、製品とベンダーを選びます。20年分のデータ分散で移行に4ヶ月かかった事例のように、事前の洗い出しが遅延や追加費用を防ぎます。
riplaは、フルスクラッチ受託と国内開発の立場から、業務とデータを起点に、要件定義からFit&Gapの整理、データクレンジングを経て現場定着まで、一貫して支援します。
全体像は納品書システムの完全ガイドもご覧ください。
▼全体ガイドの記事
・納品書システムの完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。