ワークフローシステムのRFP/要件定義書/提案依頼書について

ワークフローシステムの導入で失敗を避ける最大の分岐点は、開発やツール選定そのものよりも、その前段にある要件定義とRFP（提案依頼書）の質にあります。「とりあえず稟議を電子化したい」という曖昧な要望のままベンダーに相談すると、自社の承認ルールが正しく再現できなかったり、会計連携が想定外の追加費用になったり、紙の過去データの扱いが宙に浮いたりと、後工程で手戻りが連発します。要件を言語化し、RFPに落とし込む作業こそ、導入の成否を左右する最重要工程です。

本記事は、ワークフローシステムのRFP・要件定義書・提案依頼書をどう作るかを、現状業務の可視化／法対応・連携要件／データ移行要件／RFPの書き方という4つの軸で体系的に解説する「要件定義特化」の記事です。既存の承認ルートを可視化して再現要件に落とす方法、電子帳簿保存法や電子署名法への対応要件、会計・CRM連携の要件、紙データの移行とメタデータ保持の要件、そしてAI機能の要否切り分けまで、実務に即して整理します。なお、ワークフローシステム導入の全体像をまだ把握していない方は、まずワークフローシステムの完全ガイドから読むことをおすすめします。

▼全体ガイドの記事
・ワークフローシステムの完全ガイド

現状の承認ルートを可視化する要件定義

ワークフローの要件定義は、システムの機能から考え始めるのではなく、まず「いまの承認業務がどう回っているか」を可視化することから始めます。多くの企業では、稟議や申請のルールが文書化されておらず、ベテラン担当者の頭の中や暗黙の慣行として存在しています。これを表に出さないまま要件を固めると、リリース後に「このパターンが再現できない」という事態に直結します。

要件定義の起点は、自社にどんな申請があり、それぞれがどんなルートで承認されているかの棚卸しです。稟議、経費精算、購買申請、休暇申請、捺印依頼、契約締結など、申請種別を洗い出し、それぞれについて「金額がいくらまでは誰の承認で、いくらを超えると誰まで上がるか」「どの部門の申請は誰を経由するか」を表形式で整理します。この現状（AsIs）の可視化が、システムで再現すべきルートの仕様の土台になります。導入後の課題調査で「システム間で業務が分割され非効率」が38%を占めたことを踏まえれば、分断を生まないよう全申請を俯瞰して設計することが重要です。

棚卸しの過程では、「実は使われていないルート」や「例外運用として個別判断されているケース」が必ず見つかります。これらを要件定義の段階であぶり出し、システム化を機に整理・標準化するか、例外として残すかを決めることが、後の作り込みを軽くします。すべての例外をそのままシステムに持ち込もうとすると、複雑すぎて運用できないものになりがちです。可視化は単なる現状記録ではなく、「あるべき承認の姿（ToBe）」へ整理し直す絶好の機会だと捉えてください。

棚卸しで洗い出したルートは、そのまま再現要件として明文化します。とくに重要なのが、条件分岐と例外処理の言語化です。「金額100万円以上は役員承認」のような明快なルールだけでなく、「申請者が部門長本人の場合は一段上の承認に切り替える」「特定取引先との契約は法務を必須経由とする」といった条件付きのルールを、漏れなく仕様に落とすことが求められます。ここが曖昧なまま開発に進むと、リリース後に承認が想定外の経路を通る、あるいは止まる、というトラブルになります。

あわせて、代理承認や差し戻しといった「正常系から外れる挙動」も要件に含めます。決裁者不在時に誰が代理するか、差し戻された申請はどの段階から再開するか、組織変更で承認者が変わったときにルートはどう追従するか。これらを要件定義で決めておかないと、運用が始まってから現場が混乱します。承認ルートの再現要件は、ワークフロー要件定義の中核であり、ここに最も時間をかける価値があります。riplaはフルスクラッチ受託の立場から、この承認ルールの可視化と仕様化を起点に要件整理を進めています。

承認ルートの棚卸しを実りあるものにするには、関係者への現場ヒアリングが欠かせません。起案者、各段階の承認者、経理担当者といった立場の異なる人に、「実際にどう申請を処理しているか」「どこで手戻りや待ちが発生しているか」を具体的に聞き取ります。ここで初めて、文書化されていなかった暗黙のルールや、特定の人しか知らない例外運用が表面化します。ヒアリングを省いて机上で要件を固めると、現場の実態と乖離した仕様になり、稼働後に「これでは使えない」という事態を招きます。

ヒアリングで現状（AsIs）を可視化したら、それをそのままシステム化するのではなく、「あるべき業務の姿（ToBe）」へ整理し直すことが重要です。無駄な承認段階を減らせないか、例外運用を標準ルールに統合できないか、といった視点で業務そのものを見直します。システム導入は、業務改善の絶好の機会でもあるのです。riplaはフルスクラッチ受託と業務伴走の立場から、この現場ヒアリングを起点にAsIsを可視化し、ToBeを描いて要件に落とす進め方を重視しています。要件定義は、現場の声を集めて未来の業務を設計するプロセスだと捉えてください。

法対応・連携の要件を整理する

ワークフローが契約締結や経費処理に踏み込むと、避けて通れないのが法令対応と外部連携の要件です。電子帳簿保存法や電子署名法への対応、会計・CRMとのデータ連携をどこまで求めるかを要件定義で明確にしておかないと、後から「法的に不十分だった」「連携が別費用だった」という問題が噴出します。

ワークフローで電子契約や経費の証憑を扱う場合、電子帳簿保存法の保存要件（検索性・真実性の確保など）を満たす必要があります。具体的には、取引日付・金額・取引先で検索できること、タイムスタンプの付与や訂正・削除の履歴が残ることを要件に含めます。契約締結に電子署名を用いるなら、電子署名法第3条が定める「本人による電子署名」とみなされる要件を、立会人型（事業者署名型）と当事者型のどちらで満たすかも決めておく必要があります。これらは条文レベルで要件を確認すべき領域であり、曖昧なまま進めると後で法的有効性が問われかねません。

立会人型と当事者型では、取引先側の負担が大きく異なります。当事者型は相手方にも電子証明書の発行費（1万円前後）が発生するのに対し、立会人型はメール認証で取引先の負担が軽くなります。自社の取引先がどちらに対応できるかを見極め、要件として明記することが、後の「取引先が対応できず使えない」という失敗を防ぎます。法対応要件は、機能の有無だけでなく、自社と取引先の実態に合った方式を選ぶ視点で整理してください。

連携要件では、承認データをどの基幹システムに、どの粒度で、どのタイミングで流すかを定義します。会計システムへ仕訳として連携するのか、経費精算システムへ明細として渡すのか、CRM/SFAへ契約情報を戻すのか。これを「どのシステムと、何のデータを、API連携かCSV連携か」まで具体化しておくと、ベンダー間で見積条件がそろい、後から「連携は別費用」と言われる事態を避けられます。連携はワークフローの効果を左右する一方、追加開発の費用が膨らみやすい領域なので、要件定義で精緻に詰める価値があります。

近年とくに切り分けが必要なのが、AI機能の要否です。AI-OCRによる領収書読み取りやAI契約レビューは便利ですが、標準機能なのか月額数万円規模の追加オプションなのかで費用が大きく変わります。さらにAIには誤認識のリスクがあり、最終的な確認は人が行う前提で運用設計する必要があります。要件定義では「AIで何を自動化し、どこまで人が確認するか」「その追加コストに見合う法務・経理の工数削減があるか」を冷静に切り分けてください。AIを要件に盛り込むこと自体が目的化すると、コストばかりかさんで効果が出ない、という落とし穴にはまります。

データ移行・運用の要件を定義する

要件定義で見落とされがちなのが、過去データの移行と、稼働後の運用に関する要件です。新規導入を前提にした検討では、既存の紙契約や旧システムの申請履歴をどう扱うかが宙に浮きがちですが、ここを決めないと稼働後に「過去の決裁が追えない」という課題を抱えます。導入後の課題で「導入前の紙データが未処理」が33.6%を占めたことが、この見落としの多さを物語っています。

過去の紙契約や旧システムの履歴を新基盤へ移す際は、申請日・契約日・当事者・金額といったメタデータを保持したまま取り込む要件を定義します。単に書類をスキャンしてPDFにするだけでは、後から検索できず、電子帳簿保存法の検索要件も満たせません。どの項目をメタデータとして付与し、どう検索できるようにするかを要件として明記することが、移行を「使えるデータ」にする鍵です。膨大な紙をすべて一度に処理するのは非現実的なので、参照頻度や法定保存期間を基準に優先順位を付ける方針も、要件に盛り込んでおきます。

他システムからの乗り換えでは、解約と新規契約のタイミングも要件に絡みます。旧システムの解約前にデータをエクスポートし、新システムへ取り込み、検証が終わってから旧システムを解約する、という手順を要件・スケジュールに織り込まないと、データを取り出せないまま契約が切れる事故が起きます。データ移行は「泥臭いが効果が見えにくい」工程ゆえに軽視されがちですが、ここを要件で固めておくことが、稼働後の混乱を防ぎます。

稼働後に「現場で使われず形骸化する」ことを防ぐため、運用に関する要件も定義段階で押さえます。誰がフォームを作成・改修でき、誰が承認ルートを変更できるかという権限設計、組織変更時にマスタを更新する運用フロー、社内マニュアルの整備方針などです。これらを要件として位置づけておくと、稼働後に「設定を誰も触れない」「ルート変更のたびにベンダー依頼でコストがかかる」といった事態を避けられます。

あわせて、スモールスタートの方針も要件に反映します。全申請を一斉に電子化するのではなく、まず経費精算や購買申請から始め、運用を安定させてから範囲を広げる段階導入を前提にすれば、現場の負担を抑えつつ定着を図れます。要件定義の段階で「最初に載せる業務」「次に広げる業務」を順序立てておくと、プロジェクト全体の見通しが立ちます。運用・定着まで見据えた要件こそ、形骸化を防ぐチェンジマネジメントの第一歩です。

機能要件に偏りがちな要件定義で見落とされやすいのが、非機能要件です。アクセス権限の細かさ、通信やデータの暗号化、IPアドレス制限、二要素認証といったセキュリティ要件は、承認・契約という機密性の高い情報を扱うワークフローでは特に重要です。承認のたびに画面が重くなる、申請が集中する月末にシステムが遅延する、といった性能面の問題も、現場の不満や形骸化の原因になります。これらを「当然対応されているはず」と決めつけず、要件として明文化しておくことが、稼働後のトラブルを防ぎます。

可用性やバックアップの要件も忘れてはいけません。承認が止まると業務全体が滞るため、システムの稼働率の目標値や、障害時の復旧時間、データのバックアップ頻度を要件に含めます。クラウドサービスを選ぶ場合は、提供事業者のSLA（サービス品質保証）の内容を確認し、自社の求める水準と照らし合わせます。非機能要件は目に見えにくいぶん軽視されがちですが、ここを要件定義で押さえておくことが、長期的に安心して使い続けられる基盤を作ります。

RFP・提案依頼書への落とし込み方

整理した要件は、最終的にRFP（提案依頼書）として一つの文書にまとめ、複数ベンダーに同じ条件で提案を求めます。RFPの精度が、各社の提案・見積の比較可能性を決めます。粒度の粗いRFPでは、各社が前提を勝手に解釈し、見積条件がバラバラになって正しく比較できません。

RFPには、導入の背景と目的、対象業務の範囲、機能要件（承認ルート・フォーム・証跡・連携）、非機能要件（セキュリティ・性能・可用性）、法対応要件、データ移行要件、運用・保守の範囲、想定スケジュール、予算感、評価基準を盛り込みます。とくに承認ルートの条件分岐は、棚卸しした表をそのまま添付すると、各社が同じ前提で工数を見積もれます。費用相場の目安として、小規模向けは月額300〜800円/ユーザー、多機能製品は月額1,000円程度/ユーザーといった水準を把握しておくと、提案金額の妥当性を判断しやすくなります。

評価基準を明示することも重要です。価格だけで選ぶと、安いが自社の承認ルールを再現できない製品をつかみかねません。「承認ルートの再現性」「会計連携の標準対応可否」「サポート体制」「運用フェーズの設定変更のしやすさ」といった軸に重み付けをして、総合評価する基準をRFPに記載しておきます。これにより、各社の提案を一貫した物差しで比較でき、稟議の説明資料としても使えます。

RFPを作る過程で、自ずと「既製のパッケージで足りるか、フルスクラッチで作るべきか」が見えてきます。承認ルートが標準的で、汎用パッケージの設定範囲で再現できるなら、月額課金のクラウドサービスが費用面で有利です。一方、自社固有の複雑な条件分岐や、独自の基幹システムとの深い連携が要件に含まれ、パッケージのカスタマイズでは無理が出る場合は、フルスクラッチが選択肢になります。要件の棚卸しは、この判断を裏付ける材料にもなります。

判断の決め手は、「自社の業務をシステムに合わせるか、システムを自社の業務に合わせるか」という観点です。標準化できる業務はパッケージに寄せ、譲れない固有要件はフルスクラッチで作る、というハイブリッドな割り切りも有効です。riplaはフルスクラッチ受託と業務伴走の立場から、要件の棚卸しを起点に、どこを標準化しどこを作り込むかの線引きを支援しています。RFPは単なる発注書ではなく、自社の業務を見つめ直し、最適な作り方を選び取るための思考の道具だと捉えてください。

判断を急がず、複数ベンダーから提案を受けてデモを確認することも大切です。RFPに自社の承認ルートの棚卸し表を添えておけば、各社が自社のルールをどこまで再現できるかを、デモの場で具体的に検証できます。カタログ上は「条件分岐に対応」と書かれていても、実際に自社の複雑なルートを設定してみると無理が出る、というケースは少なくありません。要件と提案を突き合わせ、実機で確かめるこの一手間が、導入後の「再現できない」という失敗を未然に防ぎます。

まとめ

ワークフローシステムのRFP・要件定義は、現状の承認ルートを可視化して再現要件に落とし、電子帳簿保存法・電子署名法への対応と会計・CRM連携の要件を整理し、紙データの移行とメタデータ保持・運用ルールまで定義し、それらをRFPへ落とし込む、という流れで進めます。とりわけ承認ルートの条件分岐の言語化、AI機能の要否切り分け、過去データの移行優先順位付けは、後工程の手戻りと「形骸化」を防ぐ要となります。導入後の課題で「一元管理できない」「業務が分断」「紙データ未処理」が上位を占めた事実は、要件定義でこれらを先回りして潰す重要性を示しています。

要件定義は、機能一覧を埋める作業ではなく、自社の承認業務を見つめ直し、あるべき姿へ整理し直すプロセスです。承認ルールの棚卸しから始め、法対応・連携・移行・運用までを文書化し、評価基準まで明示したRFPを作れば、ベンダー選定も稟議の説得も格段に進めやすくなります。riplaはフルスクラッチ受託と業務伴走を組み合わせ、要件の可視化からRFP作成、現場定着までを一貫して支援します。全体像の確認には、あらためて完全ガイドをご活用ください。

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

また、弊社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。