総務システムのRFP/要件定義書/提案依頼書について

総務システムの導入を成功させられるかどうかは、製品選びよりも、その前段にある要件定義とRFP（提案依頼書）の質で大きく決まります。総務の業務は、稟議・申請、契約・押印、文書・規程の管理など領域が広く、しかも会社ごとに承認ルートや運用ルールが微妙に違うため、要件を曖昧にしたまま開発やパッケージ導入に進むと、リリース後に「うちの承認フローが再現できない」「紙データが移行されていない」といった手戻りが続出します。だからこそ、何をどこまで作るかを言語化したRFPが、ベンダー選定と見積もりの精度を支えます。

本記事は、総務システムの要件定義書・RFP・提案依頼書の作り方を、発注企業の視点から体系的に整理する「要件定義特化」の解説です。既存の承認ルートをどう可視化して要件化するか、電子帳簿保存法・電子署名法といった法令要件をどう盛り込むか、会計・経費精算などとの連携要件をどう記述するか、そして膨大な紙文書をメタデータを保持したまま移行する要件をどう定義するかまで、一次データとあわせて具体的に解説します。なお、総務システムの全体像をまだ把握していない方は、まず総務システムの完全ガイドから読むことをおすすめします。

▼全体ガイドの記事
・総務システムの完全ガイド

既存の承認ルートを可視化して要件化する

総務システムの要件定義で、最初にして最大の山場が、既存の承認ルートの可視化です。総務が扱う申請・稟議は、金額や部署、申請種別によって承認者が変わる条件分岐を多数抱えています。これが暗黙知のまま担当者の頭の中にあると、システムに正しく落とし込めません。要件定義では、まず現状（AsIs）の承認フローを一つひとつ図に起こし、誰が何を承認しているのかを棚卸しすることから始めます。

承認ルートの可視化で大切なのは、現状（AsIs）をそのまま再現するのではなく、あるべき姿（ToBe）への再設計をセットで行うことです。長年の運用で積み上がった承認ルートには、形だけ残っている冗長な承認や、本来不要な合議が紛れ込んでいることが少なくありません。AsIsをそのままシステム化すると、複雑さを温存したまま電子化してしまい、かえって使いにくいシステムになります。要件定義の段階で「この承認は本当に必要か」を問い直し、ルートを簡素化してから要件に落とし込むのが理想です。

この再設計を怠ると、複雑な承認ルートを精緻に作り込んだ結果、誰も使えないシステムになる、という典型的な失敗につながります。要件定義書には、申請種別ごとに「申請者・承認者・条件分岐・差し戻し時の挙動」を表形式で明記し、ベンダーが見積もり時に工数を正確に見積もれる粒度まで具体化します。承認ルートの再現性は総務システムの成否を左右する最重要要件なので、ここに最も時間をかける価値があります。

承認ルートとあわせて要件化すべきが、申請フォームと権限の要件です。総務が現在使っているExcel・Wordの申請書の項目を棚卸しし、システム上のフォームでどこまで再現するかを定義します。既存フォーマットを流用できるか、入力チェックや必須項目を設定できるかは、現場の受け入れやすさに直結するため、RFPに明記してベンダーの対応可否を確認します。

権限要件では、誰がどの申請・文書を作成・閲覧・承認できるかを、役職や部署に応じてどこまで細かく制御したいかを記述します。役員規程や人事文書のように閲覧者を限定したい文書がある場合は、その出し分けのルールも要件に含めます。権限設計が甘いと、見られてはいけない情報が誰でも見られるという漏えいリスクや、逆に必要な人が見られず業務が止まるという問題が起きます。承認ルート・フォーム・権限の3点を具体的に記述することが、要件定義の土台になります。

法令要件を要件定義に盛り込む

総務が扱う契約・文書は法令の制約を直接受けるため、要件定義には法令要件を必ず盛り込みます。電子契約や文書保存に関わる電子帳簿保存法・電子署名法への対応は、後から作り直すのが難しく、要件漏れがそのままコンプライアンス上のリスクになります。法令要件は「対応していること」を漠然と書くのではなく、どの条文のどの要件を満たすのかを具体的に記述することが重要です。

電子帳簿保存法に対応するには、締結済みの契約・帳票を、改ざん防止措置を講じた状態で保存し、取引年月日・金額・取引先などで検索できる検索要件を満たす必要があります。要件定義書には、どの帳票を電子保存の対象とするか、保存期間、検索項目を明記します。電子署名法については、契約に求める証拠力の水準に応じて、立会人型（事業者署名型）と当事者型のどちらの署名方式を採用するかを要件として定めます。当事者型は本人性の証明が強い一方、相手方にも電子証明書の発行費（1万円前後）が発生するため、取引先への負担も踏まえて方式を選びます。

あわせて、タイムスタンプによって契約成立時刻を証明できること、電子署名法第3条が定める本人による電子署名としての要件を満たすことを、要件として明示します。注意したいのは、定期借地契約や任意後見契約のように、法律で書面が義務づけられ電子化できない契約が存在する点です。要件定義の段階で「どの契約は電子化対象外か」を切り分けておかないと、リリース後に「この契約は紙でなければならなかった」というトラブルになります。法令要件は専門性が高いため、必要に応じて法務部門や専門家のレビューを要件定義に組み込むことを推奨します。

法令対応と並んで重要なのが、セキュリティと内部統制に関わる非機能要件です。総務システムは契約書や人事文書など機密性の高い情報を扱うため、アクセスログの記録、操作証跡の保全、通信・保存データの暗号化、多要素認証といったセキュリティ要件を明記します。承認の証跡が改ざんできない形で残ること、バックデート（日付の遡及）ができないことは、内部統制と監査対応の観点で必須の要件です。

これらの非機能要件は、機能要件に比べて見落とされやすい一方、後から追加するとコストも工数も跳ね上がります。RFPの段階で、求めるセキュリティ水準、準拠したい基準、ログの保存期間などを具体的に提示し、ベンダーの対応可否と実現方法を提案に含めてもらいます。非機能要件まで丁寧に記述したRFPは、ベンダーの提案の質を引き上げ、見積もりの妥当性を判断しやすくします。

連携要件とデータ移行要件を定義する

総務システムを業務の中枢として機能させるには、連携要件とデータ移行要件の定義が欠かせません。導入後の課題で「システム間で業務が分割されて非効率」が38%、「導入前の紙データが処理されないまま残っている」が33.6%と高く挙がっているのは、この2つの要件定義が甘かったことの裏返しです。連携と移行は、要件定義の段階で具体化しておかないと、リリース後に深刻な負債として残ります。

連携要件では、総務システムを会計・経費精算・人事労務・CRM/SFAといった周辺システムとどうつなぐかを定義します。承認済みの申請データを会計システムへ自動連携できれば、転記作業が消え、申請処理を約4割削減した事例のような効果が狙えます。要件定義書には、連携対象のシステム名、連携するデータ項目、連携のタイミング（リアルタイムかバッチか）、連携方式（API・CSV連携など）を具体的に記述します。

注意したいのは、連携範囲を欲張りすぎるとコストが膨らむ点です。クラウド型は初期費用0円で始められても、カスタマイズ連携には数十万〜数百万円規模の費用が発生することがあります。要件定義では、どの連携を標準機能で済ませ、どこからを個別開発するかを切り分け、効果の大きい連携から優先順位をつけます。全部を一度に連携しようとせず、段階的に範囲を広げる前提で要件を組むと、初期投資を抑えつつ着実に効果を出せます。

もう一つの重要な要件が、既存の紙文書・契約データの移行です。膨大な紙の契約書や規程をどこまでスキャンして取り込むか、どんなメタデータ（契約日・取引先・契約金額・更新期限など）を保持するかを要件定義で決めます。メタデータを保持せずにただスキャンしただけでは、後から検索できず、「導入前の紙データが処理されないまま残る」という33.6%の企業が陥った状態になります。優先順位をつけて、検索頻度の高い重要契約から計画的に移行する方針を要件に盛り込みます。

他社システムからの乗り換えの場合は、既存システムからメタデータを保持したままデータをエクスポートできるか、移行のタイミング（旧システムの解約と新システムの契約をどう重ねるか）も要件として整理します。比較記事の多くは新規導入を前提にしているため、乗り換えに伴う移行の泥臭いノウハウは見落とされがちですが、ここを要件定義で詰めておくことが移行失敗を防ぐ鍵です。riplaはフルスクラッチ受託の立場から、承認ルートの可視化から法令・連携・移行要件まで、抜け漏れのないRFP・要件定義の作成を支援しています。

連携・移行とあわせて要件定義で判断したいのが、AI-OCRやAI契約レビューといったAI機能の要否です。これらは紙文書のテキスト化や契約条項のチェックを自動化できる魅力的な機能ですが、標準機能か月額数万円の追加オプションかで費用が大きく変わり、誤認識のリスクも伴います。要件定義では「自社の業務量からみてAI機能の投資が見合うか」を冷静に評価し、必要な機能だけを要件に含めることが、無駄なコストを避けるポイントです。

AI機能を要件に含める場合は、AIが出力した結果を人がどう最終確認するかという運用も併せて定義します。AIの読み取りや指摘を鵜呑みにすると、誤ったデータや見落としが業務に紛れ込むため、あくまで人の判断を補助する位置づけと明記します。法務工数をどれだけ定量的に削減できるかという効果見積もりも、要件定義の段階で試算しておくと、導入後に「思ったほど効果がなかった」というギャップを避けられます。AI機能は要否を明確に切り分けて要件化することが大切です。

RFPの構成とベンダー選定の進め方

ここまで整理した要件を一つの文書にまとめたものが、RFP（提案依頼書）です。RFPは、ベンダーに自社の要件を正確に伝え、各社から比較可能な提案を引き出すための設計図です。RFPの質が低いと、ベンダーごとに前提がバラバラの提案が返ってきて比較できず、見積もりも当てになりません。逆に質の高いRFPは、提案の質を引き上げ、適正な見積もりとベンダー選定を可能にします。

RFPには、プロジェクトの目的と背景、対象業務の範囲、機能要件（ワークフロー・契約管理・文書管理・連携）、非機能要件（セキュリティ・性能・可用性）、法令要件、データ移行要件、想定スケジュール、予算感、ベンダーへの提案依頼事項を盛り込みます。それぞれの要件は、ベンダーが工数を見積もれる粒度まで具体化することが重要です。「ワークフローが使えること」では曖昧すぎて、各社が異なる前提で見積もってしまいます。

あわせて、AI-OCRやAI契約レビューといった先進機能を要件に含めるかどうかも、RFPで明確にしておきます。これらは標準機能か月額数万円の追加オプションかで費用が変わり、誤認識リスクもあるため、本当に必要かを見極めて記述します。導入後の社内定着（チェンジマネジメント）の支援を提案に含めてほしい場合は、その旨もRFPに明記すると、運用フェーズまで見据えた提案が得られます。

RFPを通じて提案を集める過程で見えてくるのが、パッケージ製品で足りるのか、フルスクラッチでの構築が必要なのかという判断です。承認ルートが比較的シンプルで、標準的な申請・契約・文書管理で要件の大半を満たせるなら、初期費用無料から始められるパッケージが合理的です。一方、自社固有の承認ルートや業務フローが多く、標準機能では再現しきれない場合は、フルスクラッチでの構築が現場定着の近道になることがあります。

判断の軸は、標準機能でカバーできる要件の割合、カスタマイズに要する費用と工数、そして将来の業務変化への拡張性です。パッケージを無理にカスタマイズして要件に合わせると、かえって高コストになり、バージョンアップにも追従しにくくなります。要件定義を丁寧に行えば、この判断に必要な材料が揃います。riplaはフルスクラッチ受託の立場から、要件定義の伴走と、パッケージ・フルスクラッチを含めた中立的な方式選定の支援を行っています。

導入後の定着と運用要件まで定義する

要件定義というと機能や法令の要件に目が向きがちですが、見落としてはいけないのが、導入後の定着と運用に関する要件です。約8割の企業が導入後に課題を感じているという調査結果が示すように、システムは入れただけでは定着しません。要件定義の段階で、誰がどう運用し、どう定着させるかまで描いておくことが、形骸化を防ぐ要件になります。

要件定義では、すべての総務業務を一度に電子化するのではなく、どの業務から着手するかという段階導入のスコープを定めることが重要です。いきなり全業務を対象にすると、要件が膨れ上がり、開発も長期化し、現場も一度に多くの変化を強いられて混乱します。効果が大きく件数の多い経費精算や捺印申請から始め、現場が慣れてから稟議・契約管理へと広げる、という優先順位を要件として明記します。

段階導入を要件に組み込むと、初期投資を抑えながら早期に効果を出せるという利点もあります。第1フェーズで小さな成功を作り、その効果を次のフェーズの投資判断に活かす、というロードマップを要件定義書に盛り込んでおけば、ベンダーも段階的な開発を前提に提案・見積もりを組めます。スコープを欲張らず、優先順位を明確にすることが、現場が使えるシステムを着実に育てる要件設計の基本です。

システムを使い続けるための運用要件も、要件定義に含めておくべきです。誰が承認ルートのメンテナンスを行うか、権限の付与・剥奪を誰が管理するか、規程の更新を誰がいつ行うか、といった運用体制と責任分担を定義します。これを決めずに導入すると、異動した人のアカウントが残り続ける権限放置や、古い規程が放置される情報の鮮度低下といったリスクが、運用フェーズで顕在化します。

あわせて、社内教育とマニュアルの整備も要件として位置づけます。現場が迷わず使えるよう、操作マニュアルや申請の手引きを用意し、問い合わせ窓口を設けることまでをベンダーの提案範囲に含めるかどうかを、RFPで明確にします。導入後の定着（チェンジマネジメント）支援を提案に求めれば、システムを納品して終わりではなく、現場に根づくまで伴走してくれるベンダーを選べます。riplaはフルスクラッチ受託と業務伴走の立場から、機能要件だけでなく、段階導入のスコープ設計や運用・定着の要件まで含めた要件定義を支援しています。

まとめ

総務システムの要件定義・RFPは、既存の承認ルートの可視化とToBe再設計、電子帳簿保存法・電子署名法などの法令要件、会計・経費精算とのAPI連携要件、メタデータを保持した紙データ移行要件という4つの柱で構成されます。承認ルートはAsIsをそのまま再現せず簡素化してから要件化し、法令要件は条文レベルで具体化し、連携と移行は欲張りすぎず段階的に範囲を切り分けることが、手戻りを防ぐ鍵です。導入後課題の上位に挙がる「業務分断38%」「紙データ未処理33.6%」は、いずれも要件定義の甘さが原因であり、ここを丁寧に詰める価値は極めて大きいと言えます。

要件定義で大切なのは、ベンダーが工数を見積もれる粒度まで要件を具体化し、比較可能な提案を引き出せるRFPに仕上げることです。そのうえで、標準機能でカバーできる割合を見極め、パッケージかフルスクラッチかを判断してください。riplaはフルスクラッチ受託と業務伴走の立場から、承認ルートの棚卸しから法令・連携・移行要件、方式選定までを一貫して支援します。全体像の確認には、あらためて完全ガイドをご活用ください。

株式会社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を創業。