申請管理システム開発の進め方/やり方/流れや方法/手法/工程/手順

申請管理システム開発は、6段階で進めます。まず要件整理と方式選定を行い、次に設計・開発とテストに進みます。最後に段階稼働と利用定着へ移ります。各段階で判断基準と次へ進む条件を決めておくと、手戻りや追加費用を抑えやすくなります。

▼全体ガイドの記事
・申請管理システム開発の完全ガイド

申請管理システム開発の全体像

申請管理システムは、入力から承認、差戻し、却下、決裁、保管、検索までを扱います。必要に応じて、会計や人事などのシステムへデータを渡す仕組みです。さらに、電子フォームとしてだけでなく、誰がいつどの条件で判断したかを残す業務プロセスと証跡の基盤として設計します。

申請管理システムで管理する範囲

申請管理の対象は、入力から保管・検索までです。そのうえで、自社で電子化したい申請を洗い出して決めます。その際は、次の業務例が参考になります。

  • 経費・購買:経費精算や購買申請
  • 稟議・人事:稟議、休暇、人事諸届
  • 契約・設備:契約審査、押印・電子署名、設備利用
  • 報告:事故報告などの申請も対象になります。

申請番号、状態、承認者、期限、添付証憑、操作ログを追える記録を残しておくと、承認待ちの案件を早く見つけられ、監査対応の手間も減らせます。

JICAが2025年に公表した仕様書では、決議書が2023年度に14.9万件ありました(出典:独立行政法人国際協力機構「経理業務統合システムへのワークフロー機能追加に係る業務仕様書」、2025年)。紙回付では承認状況が見えにくく、経理システムへの手入力も課題でした。特に申請件数が多い企業では、フォームの見た目だけでなく、後工程との連携や滞留の管理も欠かせません。

開発方式を選ぶ4つの軸

製品や開発会社を決める前に、方式を左右する条件を確かめます。

  • 利用規模:利用者数や申請量
  • 申請の複雑さ:合議、代理承認、異動履歴
  • システム連携:既存システムとの接続範囲
  • 情報の機密度:閲覧制御などの必要水準

利用者が少なく承認ルートが単純であれば、SaaSやノーコードの設定で始めやすいです。金額や部門による合議、基幹システムとの双方向連携、厳格な閲覧制御が必要な場合は、パッケージ拡張やSI会社による個別設計を検討します。

スクラッチ開発は、独自規程や権限を再現しやすい一方で、初期費用、保守、法改正への対応を自社で担う範囲が広くなります。申請業務を増やす予定がある場合は、まず代表的な1〜2業務で検証します。共通部品と例外要件を見極めてから拡張すると、安全です。

ポイント

まず管理する申請の範囲を決め、開発方式は利用規模や承認の複雑さ、基幹連携、機密度で選びます。利用者が少なく承認ルートが単純ならSaaSやノーコード、独自規程や基幹連携が中心なら個別開発が候補です。

申請管理システム開発の進め方(6フェーズ)

要件整理、PoC、受入テスト、KPIと改善会議を時系列に並べた申請管理システム開発の図解
業務例の検証から稼働後の改善までを順に追えます。

開発は6段階に分け、段階ごとに判断基準を決めておきます。次へ進む条件を関係者と合意しておくと、途中の手戻りや追加費用を抑えやすくなります。

フェーズ1:要件整理による現状業務の洗い出し

要件整理では、申請種別ごとに承認の流れと決裁後の処理を確かめます。

  • 申請・承認:申請者、承認者、金額条件、順序、合議、代理承認の記録
  • 例外・添付:差戻し条件、添付書類、保存期間の整理
  • 決裁後の処理:転記先など後工程の把握

現行の業務を示す資料として、申請書、Excel台帳、メール雛形、社内規程、組織図を集めます。そのうえで、担当者から例外処理を聞き取ります。規程と現場のルートが違う場合は、設定の前にそろえておきます。

要件は、MUST、SHOULD、WANTの3区分に分けます。具体的には、法令・監査・業務継続に必要なものをMUST、効果を高めるものをSHOULD、将来検討するものをWANTに置きます。

申請件数、承認完了時間、差戻し率、転記工数、承認滞留件数は、現状値として記録しておくと、稼働後の効果測定にも使えます。

フェーズ2:選定でのPoCと提案内容の比較

候補各社に同じ申請例を示して、製品の設定力と運用負担を比べます。

  • 提供体制:SaaS、パッケージ、認定パートナー、SI会社それぞれの役割
  • 承認機能:金額別ルート、異動時の承認者更新、代理承認の動作
  • 権限・監査:添付権限、差戻し後の再申請、監査ログの出力

可能であれば、経費、購買、契約審査、人事届出のなかから、件数が多く効果を測りやすい業務を1件選びます。必要なら2件まで増やし、PoCを行います。

PoCでは、利用者の入力しやすさに加えて、管理者がフォームやルートを変えられるかも確かめます。さらに、承認データを会計・人事システムへ渡せるか、監査ログを出せるかも試します。最後に、評価表で機能、設定しやすさ、運用負担、3年総額、データ返却条件を採点します。

フェーズ3:設計・開発での例外処理の決定

設計・開発では、フォームの仕様だけでなく、例外処理と非機能要件も決めておきます。

  • 基本設計:フォーム、承認ルート、状態、権限を決めます。通知、添付、検索、帳票、外部連携も定めます。
  • 例外処理:金額・申請区分による分岐、組織・役職の世代管理、退職者の無効化の設計
  • 承認例外:代理承認者が不在のときの引上げ承認の定め
  • セキュリティ:認証、シングルサインオン、多要素認証、暗号化を定めます。バックアップ、復旧目標、障害連絡、アクセスログは、RFPに記します。
  • 運用条件:保管場所、API制限、サービス水準、解約時のデータ返却、安全管理措置の明記

個人情報保護委員会のガイドラインを踏まえて、閲覧範囲や委託先の監督、教育、事故報告について、どこまでを誰が受け持つかを契約と運用手順に落とし込みます。

フェーズ4:テストでの業務シナリオの確認

受入テストは、申請から証憑とログの検索まで、一連の業務を通して確かめます。最初に、次の順で正常系を通します。

  1. 申請者の入力と、一次承認者による差戻し
  2. 申請者の修正と、複数の承認者による合議
  3. 最終決裁後の会計システムへの連携と、証憑・ログの検索

一方で、承認者の異動や代理承認、期限超過といった例外も試します。加えて、添付容量の超過と連携先の停止、二重送信と同時更新も確認します。

受入判定の前には、テストケースと期待結果、実施者、証跡のほか、未解決課題と対応期限も管理します。また、一般利用者が他部門の申請や個人情報を閲覧できないことも確かめます。

管理者が機密項目を必要以上に見られないことも、あわせて確認します。移行データがある場合は、件数や文字コード、添付、申請日、承認履歴を照合します。

フェーズ5:稼働での段階導入と切替条件

全社で一斉に切り替えるより、対象の部門や申請種別を絞った段階導入が適しています。まず、組織マスタ、認証、代表フォーム、承認ルートを整え、そのあとで連携を広げます。

会計や人事、購買、契約、電子署名との連携を段階的に広げると、問題の原因を絞り込めます。あわせて、紙や旧システムの停止時期と、紙を受け付ける例外条件を決めておきます。

問い合わせ窓口と障害時の代替手段も、事前に用意しておきます。そのうえで、過去データをすべて移すか、法定保存や参照頻度の高い期間に絞るかを判断します。

移行しないデータについては、旧台帳の保管場所、検索方法、保存期限、アクセス権を文書にまとめます。また、稼働前に、切替後の業務を安定させる条件を確認します。

  • 障害:重大な障害が起きていない状態
  • 機能:必須フォーム、承認、通知、連携、ログの動作
  • 教育:管理者と利用者への教育の完了

フェーズ6:定着でのKPIと改善会議の運用

稼働後は、利用率に加えて、処理状況と例外の数値を月次で確認します。

  • 処理時間:申請から承認までの平均時間
  • 停滞・差戻し:差戻し率と承認待ち件数
  • 例外・工数:紙やメールでの例外、転記工数、監査対応時間

導入前より改善しない場合は、必須項目と承認者の集中、通知の見落としを調べます。規程とシステムのルートにずれがないかも確かめます。

管理者だけでは現場の不満や例外申請を把握しにくいため、月1回程度の改善会議を開きます。会議には、申請部門と承認者が出席します。加えて、経理・人事・法務の担当、情報システムとベンダーも参加します。

フォーム、ルート、権限の変更も、申請として管理します。なお、AIの入力チェックや承認ルートの提案は、機密情報の学習利用、誤判定、人の最終承認、判断ログの説明可能性を確かめてから、段階的に導入します。

ポイント

各フェーズの判断基準を先に決め、次へ進む条件を関係者と合意しておきます。要件整理で現状業務を洗い出しておくと、選定や設計以降の手戻りを減らせます。

申請管理システムの費用相場とコストの内訳

限定した開発、標準的な刷新、高度な要件の3区分と、それぞれの参考費用レンジを並べた図解
要件の広がりに応じて参考レンジも段階的に上がります。

費用は、ライセンス、初期設定・導入支援、移行、外部連携に分けて考えます。個別開発、教育、保守運用は、それぞれ別の項目として扱います。

公開価格は比較の起点として使えます。ただし、フォーム数や利用者数、API、保存容量、SSO、既存システム接続によって総額が変わるため、月額だけで決めないようにします。

SaaS・パッケージ導入の料金(月額と支援費)

2026年8月に公式料金を確認した例では、製品や契約プランによって料金が異なります。ライセンスと支援費は、分けて比較します。

  • rakumo:初期費用不要、1ユーザー月額500円。50ユーザーで月額25,000円、年額300,000円。
  • kintone:初期費用無料。ライトは1ユーザー月額1,000円、スタンダード1,800円、ワイド3,000円。
  • desknet’s NEO:初期費用0円。ライトは1ユーザー月額600円、スタンダード800円、プレミアム1,000円。
  • 比較レンジ:小〜中規模のSaaSは1ユーザー月額500〜3,000円程度です。

rakumoの料金は、公式の「ワークフローの料金」(2026年8月確認)が出典です。フォーム作成は1枚10,000円から、運用設計は150,000円からで、いずれも別料金です。

別途、Google Workspaceの有料版も必要です。申請書作成、組織設定、API、教育も、見積もりに含めます。

kintoneの料金は、サイボウズ株式会社の「kintone料金」(2026年8月確認)が出典です。スタンダードを100ユーザーで使う場合、ライセンスだけなら月額180,000円、年額2,160,000円が単純な目安になります。アプリ設計、プラグイン、API、導入支援は、別途確かめます。

desknet’s NEOの料金は、株式会社ネオジャパンの「desknet’s NEOクラウド版価格」(2026年8月確認)が出典です。AppSuiteを追加する場合は、1ユーザー月額500円です。連携、移行、教育を含めた3年総額で評価します。

個別開発の費用レンジ(要件数と連携数)

申請管理専用の公的な相場統計はありません。一般的な業務システム刷新の工数目安を応用した参考レンジは、規模と要件によって異なります。

  • 限定した開発:フォーム、承認ルート、通知、既存システム連携で数百万円〜1,500万円程度です。
  • 標準的な刷新:複数部門の申請、文書保管、会計・人事・契約システム連携で1,500万円〜4,000万円程度です。
  • 高度な要件:高度な認証、大量移行、全国拠点、独自の内部統制があると4,000万円を超える可能性もあります。

金額は、要件数と連携数から置いた参考値で、特定の案件の価格ではありません。見積もりでは、要件定義、設計、開発、テストを分けて見ます。移行、教育、保守も、別の項目として確認します。

リサーチノートでは、開発人件費を全体の40〜60%程度とします。内訳は、要件定義が約10%、設計が10〜20%、開発が40〜60%、テストが10〜20%です。保守運用費は、初期開発費の年5〜15%程度を見込んで比較します。

開発期間と補助金の確認

導入期間の目安は、方式や対象範囲によって変わります。補助金は申請枠や購入時期の条件があるため、期間とは分けて確認します。

  • SaaS・小規模連携:数週間〜数ヶ月
  • 複数部署への展開・データ移行:3〜6ヶ月
  • 複数領域の統合:スクラッチの場合、半年〜1年以上
  • 補助金:対象経費、登録ツール、申請枠、購入時期

JICAの2025年公表資料には、経理システムのワークフロー機能を2025年10月1日から2027年3月31日までに構築する計画があります。要件定義から調達、移行、並行運用までを含む大規模案件の例です(出典:独立行政法人国際協力機構、2025年公表資料)。

2026年のデジタル化・AI導入補助金は、通常枠で5万円〜150万円未満です。ただし、4プロセス以上の場合は、150万円〜450万円以下で、補助率は原則2分の1です(出典:独立行政法人中小企業基盤整備機構「デジタル化・AI導入補助金2026通常枠公募要領」、2026年)。

交付決定前の購入は禁止されます。補助金を前提に要件を決めず、公式の公募要領とIT導入支援事業者に対象の可否を確かめます。

ポイント

費用は導入費、継続費、将来費に分け、3年総額で比べます。公開価格は月額だけで判断せず、契約後に増える費用まで見て決めます。

申請管理システムの見積もりを取る際のポイント

導入費、継続費、将来費の3項目を確認カードに分けた見積もりの図解
契約時の費用に加え、継続と将来の変動も見通せます。

見積もりの差は単価だけでなく、前提条件と作業範囲から生まれます。そこで、RFPに必要条件を記載し、各社が同じ前提で提案できるようにします。

RFPに書く申請・組織・データの条件

申請条件とデータ条件は、RFPで具体的に示します。

  • 申請量と体制:申請種別、年間件数、利用者・承認者数、組織の更新頻度
  • 承認・通知:直列・並列・合議、条件分岐、代理承認、通知方法
  • 保管・連携:添付容量、検索、保存年数、廃棄、連携先、移行対象

現在の申請書をサンプルとして添付すると、各社のフォーム再現の精度を比べられます。非機能面では、SSO、多要素認証、IP制限、暗号化、バックアップ頻度、復旧目標を確認します。さらに、監査ログの保存期間と出力、稼働率、サポート時間、障害連絡もRFPに記載します。

再委託先、データセンターの所在地、解約時のデータ返却形式も確かめます。あわせて、個人情報保護委員会のガイドラインと自社規程を照合し、機密項目の閲覧範囲を要件に含めます。

3年総額での比較

費目と契約後の変動を分けて確認します。

  • 導入費:初期設定、フォーム、ルート設計の費用です。API・SSO、移行、テスト、教育の費用も含めます。
  • 継続費:ライセンス、保守、追加ストレージ、バージョンアップの費用
  • 将来費:利用者の増加、組織変更、法改正、障害、引き継ぎ費の考慮

SaaSは、最低ユーザー数や契約期間、オプション、連携費によって増額する場合があります。個別開発では、本体価格に加えて、開発会社を変えるときの引き継ぎ費も見込みます。

比較表には、初年度、2年目、3年目の費用と、利用者が増えたときの額を並べます。さらに、見積もりに含まれない作業や仕様変更の単価、追加テスト、保守の受付時間、データ返却費についても質問します。

JICAの参考見積様式は、導入費、構築中のライセンス料、保守、環境費、ストレージ費を分けています(出典:独立行政法人国際協力機構、2025年公表資料)。

契約形態と変更管理による予算超過の防止

契約形態と変更の手順を決めておくと、予算や納期に影響するリスクに備えられます。

  • 契約形態:要件整理やPoCは準委任、仕様確定後の開発は請負とする方法
  • 変更管理:受付、影響分析、承認、見積、実装、受入の手順
  • 想定リスク:承認ルートの複雑化、マスタ更新の遅れ、API変更、移行データ欠損、旧運用への回帰

要件が固まる前に全工程を固定価格の請負とすると、仕様変更による追加費用や納期の延長が生じがちです。そこで、例外ルートを制限し、マスタ更新の責任者を置いておきます。

あわせて、連携先の試験環境を確保し、移行リハーサルを複数回行います。稼働後は、問い合わせの窓口を一つにまとめます。

ポイント

見積もりの比較は、前提条件と作業範囲をそろえるところから始めます。RFPに申請量や承認ルート、保管・連携の条件を書き、比較表には3年分の費用を並べます。

申請管理システム開発でよくある質問(FAQ)

導入時には、業務をどこまで変えるか、既存データをどう扱うか、稼働後に誰が管理するかが疑問になりがちです。よくある質問に順に答えます。

申請管理システムはSaaSと個別開発のどちらがよいですか?

申請種別が限られ、標準的な承認ルートで始められる場合は、SaaSやノーコードが適しています。独自規程や複雑な合議、複数の基幹システム連携、厳しい権限管理が中核になる場合は、パッケージ拡張や個別開発を検討します。判断に迷う場合は、代表業務のPoCで設定変更と連携を確かめます。

過去の紙やExcelの申請データはすべて移行すべきですか?

全件を移すかどうかは、法定保存、監査、問い合わせ、参照頻度、移行コストを比べて決めます。移行しないデータについても、保管場所、保存期限、検索方法、アクセス権、旧ファイルの改ざん防止を文書にまとめます。

移行する場合は、件数のほか、添付証憑、承認履歴、申請日、部門、申請番号の対応関係を確認します。

個人情報や契約書をクラウドで管理しても安全ですか?

クラウドかオンプレミスかよりも、認証や多要素認証、権限の中身で安全性を見ます。暗号化やバックアップ、ログ、脆弱性対応も同様に確かめます。

データの保管場所、委託先や再委託先、事故報告、解約時の削除や返却も確かめ、自社の安全管理規程に合うかを判断します。また、個人情報保護委員会のガイドラインやIPAの中小企業向け情報セキュリティ対策ガイドライン第4.0版を、候補サービスへの質問に使えます。

小さく始める場合はどの申請から着手すべきですか?

件数が多く、処理時間や転記工数を測りやすい経費、購買、契約審査、人事届出から選ぶと、効果を確かめやすくなります。

機密度の高い申請を最初から扱う場合は、権限と監査ログの検証を優先します。また、関係者がそろい、稼働後のKPIを決められる業務から選びます。

ポイント

方式は申請種別の広がりと独自規程の有無で、移行は法定保存や参照頻度で決めます。安全性はクラウドかどうかより認証や権限の中身で見て、着手する業務は効果を測りやすいものから選びます。

まとめ

フォーム作成の前に、申請種別と承認条件、例外処理、証憑、権限、保存期間を一覧にして洗い出します。連携先もあわせて確かめます。6フェーズごとに判断基準を決めておくと、業務部門と情報システム部門が同じ基準で進捗を確認できます。

着手前に確認する3つの項目

着手前に確認する項目は、対象業務と現状のKPI、必須のセキュリティ・保存要件、連携先と各担当の受け持ち範囲の3つです。曖昧なまま製品や開発会社を決めると、フォームや承認ルートの追加によって費用と納期が膨らみます。

稼働後のKPIに基づく改善

稼働後は、業務指標と現場の声を定期的に確かめ、改善を続けます。

  • 確認指標:承認時間、差戻し率、滞留件数、転記工数、監査対応時間
  • 改善:現場の声と数値をもとにした、フォームやルートの見直し
  • 継続体制:組織・制度変更に対応できる運用体制の整備

代表的な1〜2業務でPoCを行い、導入前後の数値を比べると、方式を選びやすくなります。費用は、ライセンスや支援、移行、連携を含めた3年総額で見ます。あわせて、開発、教育、保守も含めます。

▼全体ガイドの記事
・申請管理システム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

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

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

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

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。