勘定系の発注では、標準に合わせる方針の決定、Fit&Gapによるギャップ判定、要件の明文化を順に進めます。要件が曖昧なままだと、リリース後に処理や帳票の不足が見つかり、大きな手戻りになります。
発注側では、RFP・要件定義書・提案依頼書に何を書くかを体系的に押さえることが出発点です。これらの書き方が、提案の比較を左右します。全体像は勘定系システムの完全ガイドもご覧ください。
▼全体ガイドの記事
・勘定系システムの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
Fit to Standardを前提とした要件定義の進め方
Fit to Standardは、独自の業務にシステムを合わせず、標準機能に業務プロセスを合わせる考え方です。仕訳・残高・決算を扱う会計の中核である勘定系でも、近年の要件定義はこの考え方が主流です。
制度や慣行が標準化された会計領域では、標準に寄せると開発コストと将来の保守負担を抑えられます。まず、発注側の社内でこの方針を合意しておきます。
標準に寄せる範囲と独自要件の切り分け
切り分けでは、業務ごとに判断の軸を当てて、維持が必須か、標準に寄せられるかを見極めます。
- 独自仕様を検討する業務：競争力に直結する業務
- 標準に寄せる業務：慣習にすぎない業務
得意先指定の請求書や会社固有の承認ルールは、標準機能では吸収しきれない場合があります。独自仕様を増やすと費用が膨らみます。一方で、すべてを標準に押し込むと、現場が回らなくなります。
独自仕様にする要件は、理由も記録したうえで、標準との線引きを最初に丁寧に行います。この判断によって、開発コストが際限なく膨らむのを防げます。
現状業務（AsIs）とあるべき姿（ToBe）の描き方
要件を決める前に、現状業務（AsIs）を関係者への聞き取りで押さえておきます。仕訳入力から決算の締めまでを、業務フローにまとめます。
- AsIs：担当者、作業内容、作業の順番を一覧にする
- ToBe：新システム稼働後の業務の姿
現状を洗い出さずに要件を決めると、現場の実態から離れた理想論になり、稼働後に使われないシステムにつながります。
ToBeの設計では、現場担当者や経理、経営層を巻き込んで合意します。情報システム部門だけで決めると、現場の反発を招いたり、経営層の関与が足りず意思決定が遅れたりします。
新しい勘定系で変える業務や、なくす手作業を具体的に書き出すと、必要なシステム要件が自然と見えてきます。
riplaは、要件定義をシステム部門だけの作業で終わらせず、現場業務から逆算してToBeを描く支援を重視しています。
Fit&Gap表の作り方と活用
Fit&Gap表は、Fit to Standardを実務に落とし込むためのツールです。候補システムと業務要件を並べ、要件定義とベンダー選定で同じ言葉を使えるようにします。
- Fit：標準機能で業務要件を満たせる
- Gap：標準機能では満たせない要件がある
Gapが見つかったら、業務を標準に合わせるか、追加開発で対応するかを検討します。
ギャップの判定基準と対応方針の決め方
Fit&Gap表では、Gapごとに対応方針の候補を比べ、優先順位を付けて取捨選択します。
- 判定区分：標準対応、設定対応、追加開発、業務変更
- 比較項目：想定費用と業務への影響度
まず、運用変更で標準機能に合わせられないかを確かめます。その見極めが、追加開発費を抑えることにつながります。
カスタマイズ費は、最小でも100万〜300万円かかります。標準的な範囲では500万〜1,000万円、大規模になると1,000万〜3,000万円以上に達します。
対応方針は、要件を実現する価値と追加開発費を比べて決めます。たとえば、年に数回だけ発生する業務への高額な改修は、費用対効果が合わないことがあります。
要件定義の論点は、標準適合と、会社ルールや得意先要求のどちらを優先するかです。この判断が、プロジェクト費用を左右します。
現場摩擦を見越したBPRの調整プロセス
業務を標準に寄せると、現場は従来のやり方の変更を求められます。そのため、Fit&Gap表で摩擦を事前に洗い出し、調整に備えます。
- 業務改革（BPR）：業務プロセスの見直し
- 現場調整：変更への合意づくり
慣れた手順への抵抗を軽く見ると、稼働後も旧来の方法に固執し、Excelに戻る失敗につながります。
そのうえで、なぜ標準に合わせるのか、何が楽になるのかを現場に伝え、BPRの計画とあわせて要件定義の段階から組み立てます。
riplaは、摩擦を見越して業務改革と現場調整に伴走し、標準適合と現場定着の両立を重視しています。Fit&Gap表は、現場との合意形成にも使います。
法令要件とデータ移行要件の盛り込み方
RFPで見落とされやすいのは、法令とデータ移行の要件です。機能に偏ると、法令違反や移行の難航による長期化を招くため、要件定義書に章を立てて明記します。
インボイス・電帳法の法令要件の明記
インボイス制度（適格請求書等保存方式）と電子帳簿保存法への対応は、必須要件として明記します。
- インボイス：発行・保存、登録番号と税率区分の管理
- 電子帳簿保存法：電子取引データの保存・検索要件
要件は条文のレベルまで具体化しておきます。特に記載が曖昧だと、ベンダーが対応済みと回答しても、実際の運用では条件を満たさないことがあります。
将来の法改正にどう対応するかも確認しておきます。クラウド型やサブスクリプション型は、定額の保守の範囲内で無償対応されることが多くあります。
一方で、オンプレミス型は改修のたびに高額な費用が発生します。制度改正への対応方法と費用負担をRFPの提案項目に入れると、長期のコストを比べられます。また、法令対応は継続して発生する要件として、RFPに記載します。
データ移行・クレンジングと連携の要件
移行と連携の要件では、対象と条件を具体的に書きます。移行要件には、対象範囲、引き継ぐ過去データの年数、勘定科目や取引先コードの統廃合方法を含めます。
- データ移行：範囲、年数、統廃合、品質の整備
- 外部連携：接続先、方式、実行タイミング
移行データの品質をどうクレンジングするかも明記します。たとえば、20年分のデータが複数のシステムに分散していた事例では、統合に4ヶ月、移行費に数百万円がかかりました。
既存データは要件定義の段階で洗い出し、工数と費用を現実的に見積もります。移行の難しさを甘く見ると、プロジェクトが破綻するおそれがあります。
連携先は、ネットバンキングや既存の会計ソフトのように具体名で挙げます。APIかCSVか、リアルタイムかバッチかといった方式も要件に含めます。
連携要件が曖昧なままだと、稼働後に予想外の開発費が発生し、見積もりが大きく変わります。
riplaは、移行・クレンジング・連携を機能要件と同じ重みで要件化します。RFPの精度が、提案の比較とプロジェクトの安定性を左右します。
提案を比較できるRFPの構成と非機能要件
RFPは、各社の提案を引き出し、横並びで比べられる構成にしておきます。その構成が、ベンダー選定の精度を左右します。
RFPに盛り込むべき必須項目の構成
必要な章をそろえたうえで、要件ごとの対応方法と見積もりの内訳を、提案の中で示してもらいます。
- プロジェクト情報：背景、目的、現状課題、スケジュール
- 要件と依頼事項：機能、移行、連携、法令、予算、提案内容
- 費用の内訳：初期、月額、改修、保守、移行
各機能要件には、標準・設定・追加開発のどれで対応するかを示す欄を設けます。そのうえで、各社にFit&Gap表を埋めてもらい、追加開発の範囲と費用を比べられるようにします。
価格透明性の調査では、主要な会計・基幹サービス19社のうち15社が価格非公開でした。公開している4社の初期費用は、中央値で10万円程度です。
相場が読みづらい領域だからこそ、費用は「一式」ではなく項目別に示してもらいます。RFPの項目設計で比較しやすさが決まるため、各社の前提もそろえておきます。
セキュリティ・サポートなど非機能要件の明記
会計データを扱う勘定系では、機能以外の運用条件もRFPの段階で確かめておきます。
- セキュリティ：暗号化、アクセス権限、バックアップ、復旧目標
- サポート：問い合わせ時間、保守範囲、法改正対応と費用
非機能要件が曖昧だと、機能を満たしていても「サポートが手薄」「障害からの復旧が遅い」と、運用後に問題になります。あわせて、保護の条件も具体化します。
法改正への対応は、クラウド型なら定額の保守の範囲で無償のことが多い一方、オンプレミス型では都度高額な改修費が発生します。
riplaは、セキュリティや保守も含めて、稼働後を見据えて比べられるRFPの作成を支援します。導入時だけでなく、運用全体を考えて作ることを大切にしています。
まとめ
勘定系の要件定義とRFPは、Fit to Standardを前提に標準と独自を分け、現状業務（AsIs）からToBeを描く流れで進めます。続いて、Fit&Gapで対応方針を定め、法令・移行・連携の要件を具体化します。
カスタマイズ費は最小100万円から、大規模では3,000万円以上になります。移行に4ヶ月と数百万円を要した事例もあるため、Gapと移行費の見積もりを甘く見ないことが重要です。
RFPでは機能を網羅するだけでなく、現場の摩擦を見越したBPRや、経営層と現場を巻き込んだ合意形成まで考えます。要件が曖昧だと提案の比較が難しくなり、稼働後の手戻りを招きます。
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を創業。