総務システムの要件定義では、承認ルートの再設計、法令要件の具体化、連携・移行範囲の整理に取り組むことで、手戻りを防ぎます。
また、発注企業の立場から、要件定義書とRFP（提案依頼書）に何を書けばよいかを、承認ルート、法令、連携・移行、導入後の定着の順に見ていきます。
▼全体ガイドの記事
・総務システムの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
既存の承認ルートの可視化と要件化
要件定義の最初の山場は、既存の承認ルートを可視化することです。申請や稟議は、金額や部署、申請種別によって承認者が変わるため、現状の流れを正確につかむことが出発点になります。
条件分岐が担当者の頭の中にだけあると、システムに正しく反映できません。そこで、現状（AsIs）の承認フローを図に起こし、承認者と内容を一覧にします。
AsIs可視化とToBe再設計のセット
長年の運用には、形だけ残った承認や不要な合議が含まれることがあります。そのため、現状（AsIs）をそのまま写すだけでなく、あるべき姿（ToBe）への再設計も一緒に行います。
- 不要な承認：本当に必要かを問い直し、ルートを簡素化する
- 要件の明記：申請種別ごとの申請者・承認者・条件分岐・差し戻し時の挙動を示す
複雑さを残したまま電子化すると、使いにくいシステムになるおそれがあります。特に、再設計を怠ると、精緻に作り込んでも誰も使えない失敗につながります。
要件定義書は、ベンダーが工数を見積もれる粒度で書きます。承認ルートをどこまで再現できるかは成否を左右するため、この部分に最も時間をかけます。
既存フォーマットの流用と権限要件の記述
申請フォームは、今使っているExcelやWordの申請書を一覧にし、システム上で再現する範囲を決めます。そのうえで、入力チェックや必須項目を設けるかどうかも確かめます。
- フォーム要件：既存書式の流用範囲、入力チェック・必須項目の要否
- 作成・承認権限：役職や部署ごとに、申請や文書を扱える範囲を定める
- 閲覧権限：役員規程や人事文書など、閲覧者を限定するルール
フォームの使いやすさは現場の受け入れやすさに関わります。そのため、RFPに記載して、ベンダーの対応可否を確かめます。
権限の設計が不十分だと、情報が漏えいしたり、必要な人が閲覧できず業務が止まったりします。承認ルート、フォーム、権限を具体化することが、要件定義の土台になります。
法令要件の要件定義への盛り込み
総務が扱う契約や文書には法令の制約があるため、要件定義に法令要件を盛り込む必要があります。電子帳簿保存法や電子署名法の要件が抜けると、コンプライアンス上のリスクになります。
法令要件は後から作り直すのが難しいため、どの条文の要件を満たすのかを具体的に書いておきます。「対応する」という表現では、何をどこまで満たすのかが読み取れません。
電子帳簿保存法・電子署名法の要件
電子帳簿保存法に対応するには、締結済みの契約や帳票の改ざんを防ぐことと、取引年月日・金額・取引先などで検索できることが必要です。そのうえで、対象の帳票、保存期間、検索項目を明記します。
- 立会人型（事業者署名型）：電子署名の方式として採用するかどうかを定める
- 当事者型：本人性の証明が強い一方で、相手方に電子証明書の発行費（1万円前後）が生じる
署名方式は、契約に求める証拠力と取引先の負担を踏まえて選びます。加えて、タイムスタンプで契約の成立時刻を証明できることも明示します。
電子署名法第3条が定める、本人による電子署名の要件も示します。ただし、定期借地契約や任意後見契約のように、法律上書面が必要で電子化できない契約もあります。
電子化の対象外を分けておかないと、リリース後に紙での締結が必要だと分かるおそれがあります。そこで、法務部門や専門家のレビューも要件定義に組み込みます。
セキュリティ・内部統制の非機能要件
契約書や人事文書を扱うため、セキュリティと内部統制の要件も定める必要があります。具体的には、アクセスログや操作証跡、通信と保存データの暗号化を明記するほか、多要素認証も要件に含めます。
- 証跡保全：承認記録を改ざんできない形で残す
- 日付管理：バックデート（日付の遡及）ができない要件にする
- ログ管理：保存期間など、求める記録の条件を示す
証跡保全と日付管理は、内部統制や監査対応の観点から欠かせません。また、非機能要件は後から追加すると、コストと工数が増えます。
RFPには、セキュリティの水準や準拠基準、ログの保存期間を示し、対応可否と実現方法を提案に含めてもらいます。そうすると、提案の質が上がり、見積もりの妥当性も判断しやすくなります。
連携要件とデータ移行要件の定義
新しいシステムを業務の中枢として機能させるには、連携とデータ移行の要件定義が欠かせません。導入後の課題では、システム間の業務分断が38%に上り、紙データが未処理のまま残る課題も33.6%です。連携や移行を具体化しないまま進めると、リリース後に深刻な負債として残ります。
会計・経費精算・CRM連携要件の記述
総務システムを会計や経費精算とどう接続するかを定めます。人事労務やCRM/SFAとの連携も含めて、接続先を明らかにします。たとえば、承認済みの申請を会計システムへ自動連携できれば、転記の作業をなくせます。
こうした連携では、申請処理を約4割削減した事例のような効果も狙えます。要件定義書には、連携の対象とデータ項目を具体的に記し、タイミングや方式も示します。
- 対象・項目：連携するシステム名とデータを決める
- タイミング：リアルタイムかバッチかを定める
- 方式：API・CSV連携などから選ぶ
連携範囲を広げすぎると費用が膨らむ点に、注意が必要です。特に、クラウド型は初期費用0円でも、個別連携には数十万〜数百万円かかる場合があります。
標準機能で足りる部分と個別開発が必要な部分を切り分け、効果の大きい連携から優先します。一度に全部はつながず、段階的に範囲を広げれば、初期投資を抑えられます。
紙データ移行とメタデータ保持の要件
紙文書と既存システムのデータは、移行の前に次の点を決めて移行要件に含めます。
- 紙文書の対象：契約書や規程のスキャンと取り込みの範囲
- メタデータ：契約日・取引先・契約金額・更新期限など、保持する項目
- 移行の優先順位：検索頻度の高い重要契約から、計画的に移す
- 既存データの出力：乗り換え時にメタデータを保ったまま出力できるか確かめる
- 切り替え時期：旧システムの解約と新システムの契約を、どう重ねるか整理する
紙文書は、メタデータを付けて取り込まなければ後から検索できず、紙データが未処理のまま残る状態につながります。
比較記事は新規導入を前提にしていることが多く、乗り換え時の移行ノウハウは見落とされがちです。そのため、要件を詰めておくことが移行失敗を防ぐ鍵です。
riplaは、フルスクラッチ受託の立場から、承認ルートの可視化、法令対応、連携・移行要件を含むRFP作成を支援しています。
AI-OCRとAIレビューの要否の切り分け
連携や移行と合わせて、AI-OCRやAI契約レビューが必要かを判断します。これらは、紙文書のテキスト化や契約条項の確認を自動化できます。
- 費用：標準機能か、月額数万円の追加オプションかで変わる
- 誤認識：読み取りや指摘に誤りが生じるリスクがある
- 投資判断：自社の業務量に見合う機能だけを要件に含める
AIを導入する場合は、人が結果を最終確認する運用も定義します。誤ったデータや見落としを防ぐため、AIは人の判断を補助する位置づけにします。
法務の工数をどれだけ減らせるかも試算します。要否を明確に分けておけば、無駄なコストや導入後の効果との食い違いを避けやすくなります。
RFPの構成とベンダー選定の進め方
整理した要件を一つの文書にまとめたものが、RFP（提案依頼書）です。自社の要件をベンダーに伝え、比較できる提案を得るための設計図になります。
前提が各社で異なると、提案を比べられず、見積もりも当てになりません。そこで、質の高いRFPを用意すると、提案の質が高まり、適正な見積もりと選定につながります。
RFPに記載すべき項目と粒度
RFPには、プロジェクトの目的・背景と対象業務、移行要件を書きます。そのうえで、要件は次のとおり分けて示します。
- 機能要件：ワークフロー・契約管理・文書管理・連携の範囲
- 非機能・法令要件：セキュリティ、性能、可用性、法令対応
- 計画・依頼事項：想定スケジュール、予算感、ベンダーに求める事柄
各要件は、ベンダーが工数を見積もれる粒度で書きます。「ワークフローが使えること」のような表現では曖昧なため、各社が異なる前提で見積もってしまいます。
AI-OCRやAI契約レビューを含めるかも明確にします。標準機能で足りるか、追加オプションが必要かで費用が変わり、誤認識のリスクもあります。
社内定着（チェンジマネジメント）の支援を求めるなら、提案範囲に含めるようRFPに明記します。そうすると、運用フェーズを見据えた提案が得られます。
パッケージとフルスクラッチの判断基準
提案を集める過程で、パッケージ製品で足りるか、フルスクラッチで構築する必要があるかを見極めます。承認ルートがシンプルで、標準機能が要件の大半を満たすなら、パッケージのほうが合理的です。
パッケージは、初期費用無料から始められます。ただし、固有の承認ルートや業務フローが多く、標準機能で再現できない場合は、フルスクラッチが定着への近道となることがあります。
- 要件充足率：標準機能で満たせる要件の割合
- 費用と工数：カスタマイズに必要な負担を比べる
- 拡張性：将来の業務変化への対応力
パッケージを無理にカスタマイズすると、コストが高くなり、バージョンアップにも追従しにくくなります。丁寧な要件定義をしておけば、判断に必要な材料がそろいます。
riplaは、フルスクラッチ受託の立場から、要件定義に伴走し、パッケージを含めた中立的な方式選定を支援しています。
導入後の定着と運用要件の定義
要件には、機能や法令に加えて、導入後の定着と運用も含めます。実際、調査では約8割の企業が導入後に課題を感じています。
定着させるには、誰がどう運用し、どう現場に根づかせるかを、要件定義の段階で描いておく必要があります。
段階導入のスコープと優先順位
最初に着手する業務と段階導入の範囲を決めておきます。対象を広げすぎると要件や開発期間が膨らみ、現場も混乱するため、全業務を一度に電子化するのは避けます。
- 効果が大きく件数の多い経費精算や捺印申請から始める
- 現場が慣れてから稟議・契約管理へ広げる
- 第1フェーズの効果を次の投資判断に活かすロードマップを作る
段階導入には、初期投資を抑えながら早期に効果を出せるという利点があります。ロードマップを示せば、ベンダーも段階開発を前提に提案や見積もりを組めます。
スコープを絞って優先順位をはっきりさせることが、現場で使えるシステムを育てる基本です。
運用ルールと教育・マニュアルの要件
運用要件では、承認ルートの保守、権限の付与と剥奪、規程の更新を誰が担うかを決め、体制と責任を明らかにします。担当を決めないままだと、異動した人のアカウントが残る権限の放置や、古い規程による情報の鮮度低下が起きるおそれがあります。
- 操作案内：操作マニュアルや申請の手引きを用意する
- 問い合わせ対応：窓口を設けるかどうかの判断
- ベンダー支援：教育や定着支援の提案範囲
教育やマニュアルの整備も要件に位置づけ、RFPでベンダーの対応範囲をはっきりさせます。定着支援を求めれば、納品後も現場に根づくまで伴走する提案が得られます。
riplaは、フルスクラッチ受託と業務伴走の立場から、機能要件に加えて、段階導入のスコープ設計や運用・定着まで含む要件定義を支援しています。
まとめ
要件定義・RFPは、4つの柱で構成されます。承認ルートの可視化とToBe再設計、法令要件のほか、会計・経費精算とのAPI連携と紙データ移行があります。
承認ルートは簡素化したうえで要件にし、法令要件は条文のレベルまで具体化します。連携と移行の範囲を段階的に分けることが、手戻りを防ぐことにつながります。
導入後の課題では、システム間の業務分断が38%、紙データの未処理が33.6%に上ります。いずれも要件定義の甘さが原因とされ、丁寧に詰める価値があります。
要件をベンダーが見積もれる粒度まで具体化し、比べられる提案を引き出すRFPに仕上げます。そのうえで、標準機能の充足度を見て方式を判断します。
riplaは、フルスクラッチ受託と業務伴走の立場から、承認ルートの洗い出し、法令・連携・移行要件、方式選定まで一貫して支援しています。全体像は、完全ガイドもご覧ください。
▼全体ガイドの記事
・総務システムの完全ガイド
▼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を創業。