勘定系システムの刷新を発注するとき、プロジェクトの成否を最初に決めるのが要件定義とRFP（提案依頼書）の質です。勘定系は、仕訳・残高・決算といった会計の根幹を扱う中核であり、要件の詰めが甘いまま開発に進むと、リリース後に「この処理ができない」「この帳票が出ない」といった致命的な手戻りが発生します。さらに、要件が曖昧なRFPでベンダーに提案を求めると、各社の見積もり前提がバラバラになり、提案を正しく比較できません。だからこそ、何をどう書くかを体系的に押さえることが、発注側の出発点になります。
本記事は、勘定系システムのRFP・要件定義書・提案依頼書を、発注側の視点から作り込む「要件定義特化」の解説です。標準機能に業務を合わせるFit to Standardを前提とした要件整理、標準とのズレを可視化するFit&Gap表の作り方、インボイス制度・電子帳簿保存法の法令要件、データ移行とクレンジングの要件、ネットバンキングや会計ソフトとの連携要件まで、一次データとあわせて具体的に解説します。読み終えるころには、ベンダーに渡せるRFPの骨格が描けるはずです。なお、勘定系システムの全体像をまだ把握していない方は、まず勘定系システムの完全ガイドから読むことをおすすめします。
▼全体ガイドの記事
・勘定系システムの完全ガイド
Fit to Standardを前提とした要件定義の進め方
勘定系システムの要件定義では、近年「Fit to Standard」という考え方が主流になっています。これは、自社の独自業務にシステムを合わせるのではなく、システムの標準機能に業務プロセスを合わせていくアプローチです。会計のように制度や慣行が標準化されている領域では、標準に寄せることで開発コストと将来の保守負担を大きく抑えられます。要件定義の前提として、まずこの方針を社内で合意することが重要です。
標準に寄せる範囲と独自要件を切り分ける
Fit to Standardを掲げても、現実には標準では吸収できない要件が残ります。たとえば、得意先から指定された独自の請求書フォーマットや、長年守ってきた会社固有の承認ルールなどです。要件定義では、こうした「維持が必須の業務」と「標準に寄せられる業務」を明確に切り分ける作業が中心になります。すべてを独自仕様にするとコストが膨らみ、すべてを標準に押し込むと現場が回らなくなるため、このバランスの判断が要件定義の腕の見せどころです。
切り分けの判断軸は、その業務が「競争力の源泉か」「単なる慣習か」という問いです。競争力に直結する業務は独自仕様を許容し、慣習にすぎない業務は標準に寄せて業務プロセスを変える、という整理が基本になります。要件定義書には、なぜその要件を独自仕様にするのかという理由まで書き残しておくと、後の意思決定がぶれません。標準と独自の線引きを最初に丁寧に行うことが、開発コストの暴走を防ぐ最大の防波堤になります。
現状業務（AsIs）とあるべき姿（ToBe）の可視化
要件定義の前段として欠かせないのが、現状業務（AsIs）の可視化です。仕訳の入力から決算の締めまで、いま誰がどの順番で何をしているのかを、関係者へのヒアリングを通じて業務フローとして描き出します。この棚卸しをせずに新システムの要件を書こうとすると、現場の実態と乖離した「理想論だけの要件」になり、稼働後に使われないシステムが生まれます。
AsIsを描いたら、次にあるべき姿（ToBe）を設計します。新しい勘定系で業務をどう変えたいのか、どの手作業をなくすのかを具体的に描くことで、システムに求める要件が自然と浮かび上がります。ここで重要なのは、現場の担当者・経理・経営層を巻き込んで合意形成することです。情報システム部門だけで要件を決めると、現場の反発を招き、経営層のコミット不足で意思決定が遅延します。riplaは、要件定義をシステム部門の作業に閉じず、現場の業務から逆算してToBeを描く伴走を重視しています。
Fit&Gap表の作り方と活用
Fit to Standardを実務に落とし込むツールが、Fit&Gap表です。これは、自社の業務要件を一覧化し、各要件が候補システムの標準機能で満たせる（Fit）か、満たせずギャップ（Gap）があるかを整理する表です。Gapが見つかった要件については、業務を標準に合わせるのか、追加開発で対応するのかを判断していきます。この表が、要件定義とベンダー選定の共通言語になります。
ギャップの判定基準と対応方針の決め方
Fit&Gap表を作る際は、各要件に「標準で対応可」「設定で対応可」「追加開発が必要」「業務側を変更」といった判定区分を設けます。重要なのは、Gapが出た要件をすぐ追加開発と決めつけないことです。一見独自に見える要件も、運用を少し変えれば標準で吸収できることが多く、その判断を丁寧に行うことで追加開発費を抑えられます。カスタマイズ費は、最小でも100万〜300万円、標準的な範囲で500万〜1,000万円、大規模になると1,000万〜3,000万円以上に達するため、Gapの一つひとつがコストに直結します。
対応方針を決めるときは、その要件を実現する価値と、追加開発のコストを天秤にかけます。年に数回しか発生しない業務のために高額なカスタマイズを行うのは、費用対効果が見合いません。Fit&Gap表に、各Gapの想定対応コストと業務影響度を併記しておくと、優先順位をつけて取捨選択できます。標準適合の理想と、維持すべき会社ルールや得意先要求とのギャップをどう埋めるかは、要件定義の最大の論点であり、ここでの判断力がプロジェクトの費用を左右します。
現場摩擦を見越したBPRの調整プロセス
業務を標準に寄せるという判断は、現場に「今までのやり方を変えてください」と求めることを意味します。ここで必ず現場摩擦が生じます。長年慣れた手順を変えることへの抵抗は根強く、これを軽視すると、システムが完成しても現場が旧来の方法に固執し、Excelに逆戻りする失敗につながります。Fit&Gap表は、この摩擦を事前に洗い出すための地図でもあります。
摩擦を乗り越えるには、業務プロセスを見直す業務改革（BPR）と、現場への丁寧な説明・調整がセットで必要です。なぜこの業務を標準に合わせるのか、それによって何が楽になるのかを現場に納得してもらう調整プロセスを、要件定義の段階から計画に組み込みます。riplaは、Fit&Gapで生じる現場摩擦を見越し、業務改革と現場調整を伴走することで、標準適合と現場定着を両立させることを重視しています。Fit&Gap表は作って終わりではなく、現場との合意形成のために使ってこそ価値があります。
法令要件とデータ移行要件の盛り込み方
RFPで見落とされがちなのが、法令要件とデータ移行要件です。機能要件に注力するあまりこの二つを軽視すると、稼働後に法令違反のリスクを抱えたり、移行作業が難航してプロジェクトが長期化したりします。要件定義書には、これらを明確に章立てして盛り込むことが重要です。
インボイス・電帳法の法令要件を明記する
勘定系の要件定義では、インボイス制度（適格請求書等保存方式）と電子帳簿保存法への対応を、必須要件として明記します。適格請求書の発行・保存、登録番号や税率区分の管理、電子取引データの保存・検索要件への準拠などを、具体的な条文レベルで書き出すことが望まれます。法令要件を曖昧にRFPへ書くと、ベンダーが「対応済み」と回答しても、実際の運用で要件を満たさないことがあります。
あわせて要件化したいのが、将来の法改正への追従方針です。クラウド型・サブスクリプション型は法改正対応が定額保守の範囲で無償提供されることが多い一方、オンプレミス型は都度の改修開発で高額な費用が発生します。RFPには「今後の制度改正にどう対応し、その費用負担はどうなるか」を提案項目として求めておくと、長期のコストを比較できます。法令対応は一度きりではなく、継続的に発生する要件だと捉えて書いてください。
データ移行・クレンジングと連携の要件
データ移行は、RFPで最も具体的に書くべき要件の一つです。移行対象のデータ範囲、過去何年分を引き継ぐか、勘定科目や取引先コードの統廃合をどう行うか、そして移行データの品質をどうクレンジングするかを明記します。20年分のデータが複数システムに分散し、統合に4ヶ月・移行費数百万円を要した事例が示すように、移行の難易度を甘く見るとプロジェクトが破綻します。既存データの状態を要件定義の段階で棚卸しし、移行の工数とコストを現実的に見積もってください。
連携要件も同様に重要です。自社が接続したいネットバンキングや既存会計ソフトの具体名を挙げ、API連携かCSV連携か、リアルタイムかバッチかといった方式まで要件化します。連携要件が曖昧だと、稼働後に想定外の連携開発費が発生し、見積もりが大きく狂います。riplaは、勘定系のRFP作成において、機能要件と同じ重みでデータ移行・クレンジング・連携を要件化し、後の手戻りと費用膨張を防ぐことを重視しています。RFPの精度が、そのまま提案の比較精度とプロジェクトの安定性を決めます。
提案を比較できるRFPの構成と非機能要件
要件を整理したら、それをベンダーが提案しやすく、かつ各社の提案を横並びで比較できるRFPの形にまとめる必要があります。RFPの構成が雑だと、各社の見積もり前提がバラバラになり、価格も内容も比較できません。提案を引き出し、比べられる構成にすることが、ベンダー選定の精度を決めます。
RFPに盛り込むべき必須項目の構成
勘定系のRFPには、プロジェクトの背景と目的、現状業務の課題、求める機能要件、データ移行要件、連携要件、法令対応要件、想定スケジュール、予算の考え方、そしてベンダーへの提案依頼事項を、章立てして盛り込みます。特に重要なのが、各機能要件に対して「標準対応か、設定対応か、追加開発か」を提案で明示してもらう欄を設けることです。これにより、Fit&Gap表の判定を各社の提案で埋めてもらい、追加開発の範囲と費用を横並びで比較できます。
価格透明性の調査では、主要な会計・基幹サービス19社のうち15社が価格を非公開にしており、公開している4社でも初期費用の中央値は10万円程度というデータがあります。つまり、相場が読みにくい領域だからこそ、RFPで見積もりの前提を揃えることが欠かせません。費用を「一式いくら」ではなく、初期費用・月額・カスタマイズ費・保守費・移行費といった内訳で提示してもらう構成にすると、各社の見積もりを正しく比較できます。RFPの項目設計が、そのまま比較可能性を決めます。
セキュリティ・サポートなど非機能要件の明記
機能要件と並んで見落とせないのが、非機能要件です。勘定系は会社の機密性の高い会計データを扱うため、セキュリティ要件は妥協できません。データの暗号化、アクセス権限の管理、バックアップ体制、障害時の復旧目標などを、RFPに具体的に明記します。あわせて、稼働後のサポート体制も重要な要件です。問い合わせの対応時間、保守の範囲、法改正対応の方針とその費用負担を、提案で明らかにしてもらいます。
非機能要件を曖昧にすると、機能は満たしていても、運用が始まってから「サポートが手薄」「障害復旧が遅い」といった問題に直面します。特に法改正対応は、クラウド型なら定額保守の範囲で無償提供されることが多い一方、オンプレミス型は都度高額な改修費が発生するため、その違いをRFPで明確に問うことが、長期コストの比較につながります。riplaは、機能要件だけでなくセキュリティ・サポート・保守といった非機能要件まで要件化し、稼働後の安心まで含めて提案を比較できるRFP作成を重視しています。RFPは導入時だけでなく、運用全体を見据えて作ることが大切です。
まとめ
勘定系システムの要件定義とRFPを振り返ると、Fit to Standardを前提に標準と独自を切り分け、現状業務（AsIs）からあるべき姿（ToBe）を描き、Fit&Gap表でギャップと対応方針を整理し、法令要件・データ移行・連携を具体的に書き込む、という流れに集約されます。カスタマイズ費が最小100万円から大規模3,000万円以上まで幅があること、移行が4ヶ月・数百万円規模に膨らんだ事例があることを踏まえ、Gapとデータ移行の見積もりを甘く見ないことが重要です。
RFPを作るときに大切なのは、機能の網羅だけでなく、現場摩擦を見越したBPRと、経営層・現場を巻き込んだ合意形成までを射程に入れることです。要件が曖昧なまま発注すると、提案を正しく比較できず、稼働後の手戻りも避けられません。riplaはフルスクラッチ受託と業務伴走を組み合わせ、現場の業務から逆算した要件整理と、Fit&Gapの調整、データクレンジングまでを一貫して支援します。全体像の確認には、あらためて完全ガイドをご活用ください。
株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。
また、弊社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。