稟議システムのRFP・要件定義では、承認ルートの実態を洗い出し、法令・連携・移行の要件を定めます。評価基準と合わせて提案依頼書にまとめると、導入後の手戻りを防げます。
承認ルート、法令・統制、連携・移行、AIの観点から作り方を説明します。全体像は稟議システムの完全ガイドもご覧ください。
▼全体ガイドの記事
・稟議システムの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
既存の承認ルートの可視化と要件定義
要件定義では、まず既存の承認ルートを可視化します。
既存の承認ルートでは、起案から承認までの流れと例外処理を洗い出し、そのうえで、システムで再現する要件を決めます。
承認の実態が曖昧なままRFPを書くと、ベンダーは標準的な承認フローを前提に提案することになります。その結果、現場の業務と噛み合わないシステムになるおそれがあります。
稟議種別ごとの承認ルートの洗い出し
種別ごとの承認ルートは、金額の閾値、承認者の順序、分岐条件を表や図に書き出して一覧にします。この一覧があると、種別ごとの違いを関係者が同じ図で確認できます。
- 設備投資・採用：金額帯ごとの承認者
- 購買・契約・経費：金額帯と、確認を挟む条件
- 例外運用：規程にないルール
経理や法務の確認を挟む条件も、あわせて記録しておきます。この整理で、暗黙の決裁ルールを明文化できます。
RFPには、承認パターンの種類と、そのすべてをシステムで再現する必要があることを書きます。
この洗い出しでは、規程にない例外運用が頻繁に見つかります。たとえば、特定部署だけ部長を飛ばして役員へ上げる慣習や、特定の取引先への発注で社長確認を要する運用があります。
見つかった例外運用は、システムで再現するか、廃止して標準化するかを要件定義の中で決めます。
例外を放置すると、現場が自分たちのやり方と合わないと感じて使わなくなり、形骸化につながるおそれがあります。
現状（AsIs）と理想（ToBe）の切り分け
現状（AsIs）をそのままシステム化すると、紙時代の非効率な手順まで再現し、電子化の利点が薄れます。一方で、理想（ToBe）だけを押し付けると、理想論が先行して現場が付いてこられません。
- 現状の把握：AsIsの業務と例外の可視化
- 改善方針：残す業務と変える業務の線引き
- ToBeの明記：改善内容をRFPの要件に反映
たとえば、金額条件によるルートの自動分岐を必須とし、申請者が手動でルートを選ぶ運用を廃止する、といった定め方があります。
スマートフォンからの承認を必須とし、決裁者不在による滞留をなくす方針も記載できます。
riplaはフルスクラッチ受託と業務伴走の立場から、この設計を重視しています。
要件定義書が明確であれば、ベンダー選定後の実装もぶれにくくなります。
RFPに織り込む法令・内部統制の要件
稟議システムは契約や支払いを承認するため、法令対応と内部統制の要件をRFPに明記しておく必要があります。
法令に適合し、監査に耐える証跡を保存することは、企業にとって欠かせません。
電子帳簿保存法や電子署名法への対応は、後から追加すると大きな手戻りになります。そのため、要件定義の段階で織り込んでおく必要があります。
電子帳簿保存法・電子署名法への対応要件
稟議に紐づく契約や支払いの証憑を電子保存する場合は、電子帳簿保存法の保存要件を満たす必要があります。そのため、RFPには必要な機能を具体的に書きます。
- 改ざん防止：保存した証憑の改ざんを防ぐ措置
- 検索性：日付・金額・取引先で検索できること
- タイムスタンプ：証憑に付与できること
電子契約を扱う場合は、電子署名法第3条の要件も踏まえる必要があります。
立会人型（事業者署名型）か当事者型かで法的証拠力の扱いが異なる点も、あわせて整理します。
これらの確認には、条文レベルの理解が必要です。RFPには、検索要件やタイムスタンプ付与を機能要件として書きます。
標準対応か追加開発かについては、ベンダーに示してもらいます。
2025年の調査では、電子契約の導入率は78.3%でした。
法令対応を曖昧にせず要件に示すことが、コンプライアンスリスクを避ける第一歩です。
証跡・権限・バックデート防止の内部統制要件
内部統制要件は、不正やトラブルを未然に防ぎ、監査や有事の際に企業を守る基盤です。
RFPでは、この基盤を具体的な要件として書き出します。
導入後の課題調査では、約8割の企業が何らかの課題を抱えています。
- 承認証跡：誰がいつ承認したかを改ざんできない形で記録
- 権限分掌：起案者と承認者の役割の分離
- 遡及・経路制御：日時の機械記録と、ロック機能による未承認処理・ルート飛ばしの防止
統制設計の甘さも、課題の背景にあります。そこで、RFPで求める統制の範囲を定めれば、ベンダーはその条件に沿った設計を提案できます。
統制要件は、稟議システムを効率化ツールからガバナンス基盤へ引き上げる鍵になります。
連携・データ移行の要件定義
既存の業務環境に組み込むには、他システムとの連携要件を定義する必要があります。対象となるのは、会計・契約・人事との接続です。
過去データの移行要件も、あわせて定義します。対象は、紙や旧システムにある稟議データの引き継ぎです。
RFPで具体的に示さないと、ベンダーは見積もりにくくなり、想定外のコストが後から発生する原因になります。
会計・人事・契約システムとの連携要件
連携要件では、接続先、連携方向、対象データを具体的に定めます。たとえば、次のような業務データを連携します。
- 支払稟議：承認後に会計システムへ仕訳データを送る
- 人事情報：組織情報の取得と、承認ルートへの反映
- 契約稟議：承認後、電子契約システムへ案件情報を渡す
標準APIで対応するか個別に開発するかで、費用は大きく変わります。そのため、RFPにはリアルタイム連携か日次バッチか、マスタの同期方向まで書きます。
クラウド型でも、連携のカスタマイズに数十万〜数百万円かかる場合があります。標準連携と個別開発の範囲を分けておくことが、総コストを抑える鍵です。
導入後の課題調査では、システム間で業務が分断され非効率だという声が上位でした。連携設計が甘いと、運用の足かせになります。
発注側がデータフローまで定義しておくと、見積もりの精度と導入後の業務効率を高められます。
紙・旧システムからのデータ移行とメタデータ保持
比較記事は新規導入を前提とするものが多い一方、実務では過去の稟議や契約データの移行も大きな論点になります。
旧システムやExcelの稟議履歴、紙で保管した契約書を新システムへ引き継ぐ方法を、要件として定めます。
契約日・当事者・金額などのメタデータを保持しないと、過去の稟議や契約を検索できず、一つの場所で管理する利点が損なわれます。
導入後の課題調査では、導入前の紙データが未処理のまま残るという声が3割を超えています。大量の紙契約を、すべてスキャンするのが現実的でない場合もあります。
- 移行対象：対象範囲と優先順位をRFPで定める
- 優先するデータ：有効期限が残る契約や更新が近い稟議
- メタデータ：契約日・当事者・金額の保持
優先対象以外は、段階的に対応する方針もあります。riplaはフルスクラッチ受託の立場から、メタデータ保持と紙データの優先順位付けを含む移行設計を支援しています。
AI機能の要否の切り分け
近年は、AI-OCRやAIレビューをRFPに含めるかどうか悩む企業が増えています。標準機能か追加オプションかで費用が変わるうえ、誤認識のリスクもあります。
RFPの要件では、AI機能を「必須」と「あれば望ましい」に分けて書きます。
AI-OCR・AIレビューの費用対効果の見極め
AI機能を要件に含める前に、月間の利用量と削減できる工数を、数字で見積もっておきます。
この試算がないと、月額数万円の追加費用に見合わない投資になりがちです。
RFPでは、AI機能を必須要件と加点要件に分ける方法が現実的です。
- AI-OCR：月間処理件数と1件あたりの転記時間をもとにした工数の試算
- AIレビュー：契約書の法務確認件数と、初動の短縮幅の見積もり
- 要件区分：承認ルートと証跡は必須、AIは対応時に加点評価
AIの有無だけで選ばなければ、基本機能が自社に合わない事態を避けられます。また、誤認識のリスクを踏まえて、人による確認工程も残しておきます。
RFPに含める提案の評価基準
RFPには要件だけでなく、提案を公平に比べるための評価基準も含めます。各ベンダーを同じ物差しで見るため、評価の軸を設定します。
- 業務適合：承認ルートの再現性
- 対応範囲：法令対応、連携の柔軟性、データ移行の方針
- 導入後：サポート体制と総コスト
評価基準を事前に示しておくと、ベンダーは各観点に沿って強みを提案できます。その結果、提案を並べて見比べられます。
総コストは、初期費用だけでなく、月額費用、連携開発費、データ移行費、将来の機能追加費を含めた総保有コストで比べます。
安く見えても、従量課金や連携費で総額が膨らむ場合があります。riplaはフルスクラッチ受託の立場から、要件定義書・RFPの作成から提案評価まで伴走し、自社の承認業務に合う選定を支援しています。
要件定義に時間をかけることが、投資対効果の高い進め方です。
定着・運用・補助金活用の要件
導入後の定着支援と運用要件は、RFPから抜け落ちやすい項目です。課題調査では約8割が導入後に課題を抱えており、その多くは、現場で使われない運用面の問題です。
ベンダーの伴走力も、提案の内容から見極めます。
- 定着支援：初期設定、操作研修、マニュアル提供の範囲
- 運用支援：窓口の対応時間と運用開始後の改善対応
- 補助金：申請支援の可否と、申請にかかる手間
IT導入補助金を活用できれば、初期投資を抑えられる可能性があります。稟議システムや電子契約システムは、補助対象になることも多くあります。
インボイス枠やセキュリティ対策推進枠の対象経費と申請スケジュールを把握すれば、導入計画に補助金を織り込めます。
機能、法令、連携、移行に加えて、定着と補助金も見据えた要件定義が、投資対効果を高めます。
性能・セキュリティなどの非機能要件
RFPでは、機能要件だけでなく、性能・セキュリティ・可用性も明記します。人事や投資の稟議は機密性が高いため、セキュリティ要件は妥協できません。
- 性能：同時利用人数や件数増加時の検索速度
- セキュリティ：権限粒度、通信暗号化、二要素認証、ログ保全期間
- 可用性：停止時の復旧目標時間とバックアップ体制
非機能要件が曖昧だと、稼働後に動作が重くなったり、ピーク時に停止したりする問題が起こり得ます。そのため、非機能要件を定義しておくことが、安定した長期運用の土台になります。riplaは機能・非機能の両面を網羅する要件定義を支援しています。
関係部門を巻き込んだ要件の合意形成
要件定義は、情報システム部門だけでは完結しません。関係者の参加を前提に進める必要があります。特に、一部門だけで進めると、自分たちの業務が考慮されていないという不満が生じます。
- 参加者：各部門、管理職、経理、法務、内部監査
- 話し合い：代表者による要件定義ワークショップ（課題と理想像の共有、要件の詰め）
- 論点整理：承認ルールの違いや、暗黙の例外運用の洗い出し
各部門の要望や懸念を吸い上げて合意を形成することが、導入後の反発や形骸化を防ぐ鍵です。
要件定義は、技術文書の作成であると同時に、組織の合意をつくるプロセスです。
まとめ
稟議システムのRFP・要件定義は、承認ルートの現状（AsIs）を可視化し、ToBeの改善方針を示すことから始まります。
電子帳簿保存法・電子署名法への対応や、証跡・権限・バックデート防止の内部統制も、要件に織り込みます。
会計・人事・契約システムとの連携と、メタデータを保持するデータ移行の要件も具体的に定義します。
AI機能は必須要件と加点要件に分け、費用対効果を見極めます。評価基準とともにRFPへまとめることで、ベンダーの提案を公平に比較できます。
製品を選ぶ前に、自社の承認業務を言葉にしておくことが大切です。曖昧なまま選定すると、導入後に手戻りや形骸化を招きます。
現場の実態を洗い出し、法令・連携・移行・AIの要件を整理すれば、提案や実装がずれにくくなります。riplaは要件定義書とRFPの作成から提案評価まで一貫して支援します。
全体像の確認には、稟議システムの完全ガイドもご覧ください。
▼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を創業。