文書管理システムの要件定義書とRFPは、現状業務の棚卸し、機能と非機能の要件、法令対応とデータ移行、RFPの作成の順に整理すると手戻りを防げます。たとえば、機能が多くても、文書実務や承認、法的要件が曖昧だと、リリース後に想定違いや機能不足が起きます。
全体像は文書管理システムの完全ガイドもご覧ください。
▼全体ガイドの記事
・文書管理システムの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
現状業務の棚卸しと可視化
要件定義は、新機能を並べる前に、自社の文書実務（AsIs）の現状を押さえることから始めます。具体的には、文書の種類と所在、量、利用者と使い方、承認経路を洗い出します。この洗い出しを省いて理想像から進めると、現場の実態とずれ、導入後に使われないシステムになりかねません。
文書種別・保管場所・件数の棚卸し
棚卸しでは、どの種類の文書が、どこに、どれだけあるかを確かめます。移行の優先順位を決める材料になるため、文書種別、保管場所と量、利用頻度と重要度の面から整理します。
- 文書種別：契約書・稟議書・請求書・帳票・図面・マニュアル・議事録
- 保管場所と量：紙のキャビネット、個人PC、共有フォルダ、複数のクラウド
- 利用頻度と重要度：移行計画と優先順位を決める評価軸
同じ契約書が複数の場所に重複していたり、所在を誰も把握していない文書が見つかったりします。また、情報を一元管理できない課題は、ContractSの2023年10月調査で39.5%でした。
文書を、日常的に参照するもの、法定保存文書、あまり見ないが廃棄できないものに分ければ、移行計画を立てやすくなります。洗い出した結果は、要件定義書の冒頭に記載します。
棚卸しと優先順位付けを省いて、すべてを一度に移そうとすると頓挫します。紙データが未処理のまま残る課題は、同調査で33.6%でした。
承認ルート・運用フローの可視化
文書の保管場所とあわせて、文書が生まれて流れていく業務フローも洗い出します。稟議書や契約書には承認ルートがあり、金額や種類によって承認者が変わります。そこで、どの条件でどの承認者に回るかを確かめます。
- 決裁規程：3万円未満は課長、3万円以上100万円以下は部長、100万円超は役員
- 実際の運用：規程とのずれ、代理承認、属人的な例外処理
規程と現状を照らし合わせておかないと、システム上の承認ワークフローを正しく設計できません。承認ルートは要件定義で見落とされやすく、特に注意したい箇所です。
例外運用には、合理的な理由がある場合もあります。そこで、例外を一律に切り捨てず、システムで吸収する範囲と運用ルールで補う範囲を分けます。
見つかった課題をシステム化の機会と捉えて、ルートを整理・標準化すると、導入効果を高められます。現状のフローを描いたら、次にあるべき姿（ToBe）を要件に落とし込みます。riplaはフルスクラッチ受託として、承認フローを含む業務全体の現状を把握し、設計し直すことを重視しています。
機能要件・非機能要件の定義
現状を把握したら、実現したい機能を機能要件と非機能要件に分けます。前者は「何ができるか」、後者は性能・信頼性・セキュリティの水準です。
検索や権限などの機能要件に目が向きがちです。一方で、大量の文書を扱う性能や止まらない可用性を軽視すると、運用段階で支障が出ます。
メタデータ設計と検索要件の定義
機能要件の中心は、メタデータ（属性情報）の設計と検索要件です。発注側と開発会社は、現場が何で検索するかを業務から逆算し、必要十分な属性を決めます。
- 属性情報：取引先・契約日・金額・文書種別・部署・保存期限
- 検索方法：本文・添付ファイル・スキャンPDFまで含むか、AI-OCRの要否、絞り込み検索の条件項目
- 法令対象書類：対象文書を特定し、法令に沿った検索要件を整理
属性が不足すると必要な検索ができません。一方で、増やしすぎると登録時の負担が重くなり、現場が入力を避けがちです。
電子帳簿保存法の対象書類は、「取引年月日・取引金額・取引先」での検索が法的に求められます。そのため、この条件に応える属性と検索機能を必須要件として定めます。
AI-OCRが標準機能か追加オプションかで、費用は変わります。発注側は要件に明記して、見積もりの内訳を確認できるようにしておきます。
権限設計と非機能要件（性能・可用性）
権限設計は、機能要件と非機能要件（セキュリティ）の両方にまたがり、安全な運用を左右します。発注側は、利用者ごとの割当範囲を定めます。
- 権限：部署・役職・プロジェクトごとの閲覧、編集、取得、削除
- 性能と可用性：大量文書の検索時間、停止時の復旧目標、稼働率
- 将来と保全：文書増加への拡張性、バックアップ、災害対策
閲覧や編集の範囲は、現状の機密区分に基づいて割り当てます。また、異動や退職の際の見直しも要件に含めると、長期的に安全な運用につながります。
設定が曖昧だと、機密文書の漏えいにつながります。さらに、必要な人がアクセスできず業務が止まる事態も起きます。
文書管理は業務の基盤になると、止められなくなります。そこで、稼働率の目標やデータの保全方針も、要件として明記します。
非機能要件は、クラウドかオンプレミスかの選択にも関わるため、的確な提案と見積もりの前提になります。
法令対応・データ移行の要件定義
機能と並んで、法令対応とデータ移行も要件定義の重要な項目です。国税関係書類や契約書は、電子帳簿保存法や電子署名法を満たさなければ、導入しても法的に不十分になります。
既存の紙文書や旧システムのデータ移行は、プロジェクトでつまずきやすい領域です。
電帳法・電子署名法への対応要件
電帳法では、真実性と可視性の確保が求められます。また、電子署名法では、本人による電子署名が要件になります。
- 真実性の確保：タイムスタンプの付与、または訂正削除の履歴が残る・削除できない仕組み
- 可視性の確保：取引年月日・取引金額・取引先での検索、ディスプレイ等での速やかな表示
- 電子署名：契約を電子署名で締結する場合、電子署名法第3条の本人署名要件
要件定義書には、対象文書ごとの検索、保存、改ざん防止の要件を具体的に書きます。
定期借地契約や任意後見契約のように、書面が法的に義務づけられた契約は電子化できません。そこで、電子化の可否を書面ごとに確かめ、電子化する文書と紙原本を残す文書を分けます。この切り分けを省くと、後になって電子化できない契約が見つかります。
必要に応じて顧問弁護士や税理士に確認し、その内容を要件定義書に反映します。
紙データ移行・メタデータ保持の要件
移行の要件は軽視されやすく、トラブルも起きやすい領域です。そのため、範囲と順序、保持する情報を明確にしておきます。
- 紙文書：スキャンする範囲と順序
- 既存データ：旧システムから移す方法と、新旧併存時の運用
- 属性情報：契約日・当事者・金額などのメタデータ保持
新規導入を前提にした比較記事は多い一方で、発注者は既存環境からの移行設計に直面します。そこで、棚卸しで決めた優先度を使い、参照頻度の高い直近◯年分から電子化するなど、移行の範囲を定めます。
乗り換える場合は、旧システムの解約時期と、新システムへの移行完了の時期も決めておきます。また、新旧が併存する間は、二重管理が起きない運用ルールが必要です。
riplaはフルスクラッチ受託の立場から、メタデータを保った移行や紙データのスキャン優先順位も含めて、要件定義を支援しています。ただし、移行要件は自社が主体となって設計します。
RFP（提案依頼書）の作成と発注体制
要件が固まったら、ベンダーに伝えるRFP（提案依頼書）にまとめます。RFPは、複数社から同じ前提で提案と見積もりを得るための文書です。
内容が曖昧だと、前提の異なる提案が届きます。そうなると比較できず、価格だけで選ぶ失敗につながります。
RFPに盛り込むべき項目の構成
RFPでは、前提を揃えて提案を比べられるように、次の項目を記載します。
- 背景・対象：見直す理由と課題、対象文書種別・対象部署・利用者数
- 要件：検索・版管理・権限・ワークフローなどの機能、性能・可用性・セキュリティ、法令対応、紙データ・既存システムからの移行
- 発注条件：スケジュール、予算感、評価基準
項目を決まった形で書けば、ベンダーの提案前提が揃い、発注側は内容を横並びで比べられます。
特に重要なのは、導入の背景と目的をRFPの冒頭で明確に伝えることです。現状の課題と目指す状態を共有しておくと、ベンダーは課題の解決策を提案しやすくなります。
AI機能や補助金活用など、自社だけでは判断しきれない論点について、提案を求めると明記します。RFPは、要求を伝える文書であるとともに、提案を引き出す対話の起点にもなります。
パッケージかフルスクラッチかの判断要件
RFPでは、パッケージ（クラウドの既製サービス）かフルスクラッチかの判断が欠かせません。判断の基準は、要件の標準性と固有性のバランスです。
- パッケージ寄り：一般的な要件が大半で、固有要件が少ない
- フルスクラッチ寄り：承認や連携に強い固有性があり、業務の競争力に直結する
パッケージは初期費用を抑えて早く始められます。一方、複雑な承認ルートや基幹システムとの深い連携、独自業務への適合が必要なら、フルスクラッチや大幅なカスタマイズが現実的です。
RFPでは方針を決め打ちせず、自社の要件をどう満たすかをベンダーに提案してもらいます。
riplaは、フルスクラッチ受託と業務伴走の立場から、要件定義でパッケージと作り込む範囲の切り分けを支援しています。発注者がRFPと要件定義を主体的に進めることが、ベンダー任せによる失敗を避けるうえで欠かせません。
提案評価基準とPoC・トライアルの設計
評価基準は、提案を受ける前に定めておきます。RFPの段階で評価軸ごとに重みを付け、可能なら点数化して比べます。
- 要件への適合：機能要件の充足度、非機能要件への対応、法令対応の確実性
- 導入後の支援：移行支援の実効性、サポート体制
- 総コスト：初期費用とランニング費用
事前に比較基準があれば、価格や見栄えだけで選ぶことを避けられます。社内でも、選定理由を客観的に説明できます。
固有要件が多い場合は、PoC（概念実証）やトライアルも評価に加えます。たとえば、実文書のサンプルで検索・登録・承認を試し、現場担当者が操作性や提案内容とのずれを確かめます。
導入後に約8割が課題を抱える実態は、ContractSの2023年10月調査に示されています。そのため、機能の比較に加えて使い勝手も確かめておきます。
評価基準とトライアルを要件定義やRFPの段階で設計しておくことが、選定の失敗を防ぐうえで欠かせません。
まとめ
文書管理システムの要件定義とRFPは、現状の棚卸し、機能・非機能要件、法令・移行要件、発注体制の順に組み立てます。特に最初の棚卸しを省くと、現場の実態と合わない要件になりかねません。
文書種別と保管場所、承認ルートを洗い出し、メタデータと検索を設計します。そのうえで、法令への対応、移行方法、パッケージとフルスクラッチの選択は、発注者が主導します。
導入後に約8割が課題を抱える実態は、ContractSの2023年10月調査に示されています。この実態を踏まえると、現状業務や移行・運用の要件を詰めることが、導入後に使われない失敗を避ける前提になります。
要件定義を丁寧に進めれば、多くの失敗を導入前に防げます。ベンダー任せにせず、業務と文書を洗い出し、あるべき姿をRFPに記載します。
評価基準を決め、固有要件が多い場合はPoCやトライアルで使い勝手を確かめておきます。こうした準備で選定の精度が上がり、後工程の手戻りを抑えて、全体のコストとリスクを下げられます。
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を創業。