要件定義では、承認業務の現状を洗い出し、法対応・連携・移行・運用を整理してRFP（提案依頼書）にまとめます。導入の成否は、ツール選びより前段の要件定義とRFPの質に左右されます。
全体像はワークフローシステムの完全ガイドでも確認できます。
▼全体ガイドの記事
・ワークフローシステムの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
現状の承認ルートを可視化する要件定義
要件定義は、機能を並べる前に、現在の承認業務の流れを可視化することから始めます。
稟議や申請のルールは、文書にまとまっておらず、担当者の経験や暗黙の慣行として残っている場合があります。こうしたルールを表に出さないまま要件を固めると、稼働後に一部の承認パターンを再現できない恐れがあります。
申請種別ごとの承認ルートの棚卸し要件
まず、申請種別を洗い出します。次に、種別ごとの承認ルートを表に整理します。
- 申請種別：稟議、経費精算、購買、休暇、捺印、契約締結など
- 金額条件：金額の範囲ごとに、必要な承認者を記録
- 部門条件：部門ごとに、経由する承認者を記録
AsIs（現状）の可視化は、システムで再現するルートの仕様を決める土台になります。
導入後の課題調査では、「システム間で業務が分割され非効率」が38%を占めました。そのため、分断を生まないよう、全申請を俯瞰して設計する必要があります。
棚卸しでは、使われていないルートや、個別判断による例外運用も見つかります。
見つかった例外は、標準化するか例外として残すかを先に決めておくと、後の作り込みを軽くできます。
すべての例外をシステムに持ち込むと、複雑になって運用しにくくなる場合があります。そこで、可視化を記録だけで終えず、あるべき承認の姿（ToBe）へ整理する機会にします。
条件分岐・例外処理の再現要件の明文化
なかでも、条件分岐と例外処理の言語化は重要です。
棚卸しした承認ルートは、これらを含めて再現要件にします。
- 金額条件：100万円以上の申請は役員承認とする
- 申請者条件：部門長本人の申請は、一段上の承認へ回す
- 取引先条件：特定取引先との契約は、法務を必ず経由する
- 代理承認：決裁者が不在のときの代理者
- 差し戻し：戻された申請の再開段階
組織変更で承認者が変わった場合は、ルートをどう追従させるかも決めておきます。
条件が曖昧なまま開発を進めると、運用開始後に現場が混乱します。申請が想定外の経路を通ったり、途中で止まったりする恐れもあります。
再現要件はワークフロー要件定義の中核であり、ここに時間をかける価値があります。
riplaは、フルスクラッチ受託の立場から、承認ルールの可視化と仕様化を起点に要件を整理しています。
現場ヒアリングでToBeを描く進め方
承認ルートの棚卸しでは、立場の異なる関係者に、現場の実態を聞き取ります。
- 起案者：実際の申請処理と、手戻りや待ちの発生箇所
- 承認者：各段階での判断方法と例外運用
- 経理担当者：申請後の処理と、関連業務とのつながり
現場ヒアリングでは、文書にない暗黙のルールや、特定の人だけが知る例外が表面化します。
ヒアリングを省いて要件を固めると、実態と仕様が離れ、稼働後に使えない事態を招きます。
AsIsを可視化した後は、ToBe（あるべき業務）へ整理してから、システム化の検討に進みます。
ToBeの整理では、無駄な承認段階を減らせるか、例外運用を標準ルールに統合できるかを見直します。
システム導入は、業務改善の機会でもあります。
riplaは、フルスクラッチ受託と業務伴走の立場から、現場ヒアリングを起点にAsIsを可視化します。
riplaは、ToBeを描いて要件に落とし込み、現場の声から未来の業務を設計します。
法対応・連携の要件整理
契約締結や経費処理を扱う場合は、法令対応と外部連携の要件を決めておきます。
法対応では、電子帳簿保存法や電子署名法への対応、会計・CRMとの連携範囲を明確にします。
連携範囲を曖昧なまま進めると、法的に不十分になったり、連携が別費用になったりする問題が起きます。
電子帳簿保存法・電子署名法への対応要件
電子契約や経費の証憑を扱う場合は、電子帳簿保存法の保存要件を満たす必要があります。
- 検索性：取引日付・金額・取引先で検索できること
- 真実性：タイムスタンプや訂正・削除履歴を要件に含める
- 署名方式：立会人型か当事者型かの選択
電子署名を使う場合は、電子署名法第3条の要件を、どの方式で満たすかを決めます。
ここは条文レベルで確認すべき領域で、曖昧なままでは、後から法的有効性が問われかねません。
立会人型と当事者型では、取引先側の負担が大きく異なります。当事者型では相手方にも電子証明書の発行費が1万円前後かかりますが、立会人型はメール認証のため、取引先の負担が軽くなります。
そのため、取引先がどちらの方式に対応できるかを見極め、要件に明記します。方式は、機能の有無だけでなく、自社と取引先の実態に合わせて選びます。
会計・CRM連携とAI機能の要否の切り分け
連携要件では、承認データの送信先、データの粒度、連携のタイミングを定義します。
- 会計システム：仕訳として連携するかの決定
- 経費精算システム：明細として渡すかの決定
- 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に明記すれば、各社の提案を同じ尺度で比べられます。また、評価結果は、稟議の説明資料としても使えます。
パッケージかフルスクラッチかの見極め
要件を整理すると、パッケージかフルスクラッチかを判断する材料がそろいます。
- パッケージ：標準的なルートを設定範囲で再現できる場合
- フルスクラッチ：複雑な条件分岐や深い基幹連携が必要な場合
- ハイブリッド：標準化できる業務はパッケージに寄せ、固有要件は作り込む
汎用パッケージの設定範囲で承認ルートを再現できるなら、月額課金のクラウドサービスが費用面で有利です。
パッケージのカスタマイズでは無理が出る場合、フルスクラッチが選択肢になります。選定では、自社の業務をシステムに合わせるか、システムを業務に合わせるかを見極めます。
riplaは、フルスクラッチ受託と業務伴走の立場から、標準化する範囲と作り込む範囲の線引きを支援しています。
RFPは発注書であるだけでなく、自社の業務を見直して作り方を選ぶための資料です。
複数ベンダーから提案を受け、デモを確認することも大切です。承認ルートの棚卸し表を添えると、デモで自社ルールの再現性を具体的に検証できます。
カタログに条件分岐対応と書かれていても、複雑なルートを設定すると無理が出る場合があります。要件と提案を突き合わせ、実機で確かめることで、導入後の再現トラブルを防げます。
まとめ
ワークフローシステムの要件定義は、承認ルートを可視化し、法対応や連携、移行と運用を定めたうえで、RFPにまとめます。条件分岐の明文化、AI機能の要否、過去データの移行順位は、後工程の手戻りや形骸化を防ぐうえで欠かせません。
導入後の課題では「一元管理できない」「業務が分断」「紙データ未処理」が上位を占めました。この事実は、要件定義で問題を先回りして潰すことの重要性を示しています。
要件定義は機能一覧を埋めるだけでなく、承認業務を見直してあるべき姿に整える作業です。承認ルールから法対応・連携・移行・運用までを文書化し、評価基準を明示したRFPを作ります。こうした準備があれば、ベンダー選定や稟議の説明を進めやすくなります。
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を創業。