手続管理システム開発の発注/外注/依頼/委託方法について

手続管理システムの発注・外注では、申請フォームを作るだけでなく、承認、審査、差し戻し、期限通知、証跡保管までの業務全体を整理し、必要な範囲を決めてから委託することが重要です。費用の目安は、特定業務に絞った小規模な刷新で300万〜1,500万円、契約・法務手続などを統合する標準規模で1,500万〜4,000万円ですが、手続数や連携、データ移行の量で変わります。

本記事では、手続管理システムを開発会社へ発注・外注・委託する際の進め方を、発注形態の選択、RFPと要件整理、契約形態、費用相場、委託先の選定、見積比較まで順番に解説します。社内申請・契約や法務の手続と、自治体などの行政・対外手続を分けて考え、導入後に「作ったのに現場で使えない」「見積もり以外の費用が膨らむ」といった失敗を防ぐ判断材料を示します。

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

手続管理システムを発注する前に整理すべき全体像

手続管理システムの発注範囲を整理するイメージ

手続管理システムとは、申請や届出の受付から承認・審査、通知、完了、文書保管、更新期限の管理までを一つの流れとして扱うシステムです。発注前に対象範囲を定義しないと、ワークフロー製品の導入なのか、業務システムの新規開発なのかが曖昧になり、委託先から比較できない見積もりが出てきます。

社内申請・契約・法務手続を対象にする場合

社内向けでは、稟議、契約審査、法務相談、購買申請、人事申請、押印申請などが対象になります。申請フォームだけを電子化するのではなく、申請者、担当部署、承認者、審査者、最終決裁者を分け、金額や契約種別による条件分岐、代理承認、差し戻し、督促を定義します。契約書や本人確認書類を添付する場合は、申請データと文書を関連付け、誰がいつ閲覧・承認・変更したかを監査ログとして残す設計が必要です。

この領域では、既存の人事・会計・販売・電子契約サービスとの連携が費用を左右します。社員マスタを毎日同期するのか、申請完了時に会計へ連携するのか、APIが使えない場合にCSVを介するのかを発注前に決めておくと、連携部分の見積もりが安定します。

行政・対外手続を対象にする場合

自治体や事業者向けの手続では、住民・申請者が使う画面と、職員が審査する画面を分けて考えます。本人確認、添付書類の補正依頼、審査の差し戻し、結果通知、台帳連携までを含むため、社内ワークフローの延長だけでは要件を満たせない場合があります。デジタル庁は2026年6月更新の「行政手続のオンライン化」で、スマートフォンなどで手続が完結することを目指し、自治体のオンライン申請拡大を進めています。この動向を踏まえ、スマートフォン対応や本人確認方式をRFPに含めることが重要です(出典: デジタル庁「行政手続のオンライン化」、2026年)。

行政・対外手続では、受付番号、申請者への通知、審査担当者の権限、処理期限、問い合わせ履歴を後から追跡できなければなりません。マイナンバーカードや既存台帳との連携を予定する場合は、利用するAPI、認証、エラー時の再送、データの保管場所を発注条件に書き、実績のある委託先へ確認します。

手続管理システムの発注形態はどれを選ぶべきですか?

手続管理システムの発注形態を比較するイメージ

発注形態は、標準機能に業務を合わせられるか、独自の審査や連携が必要かで決めます。結論として、手続数が少なく早期に効果を確認したい場合はSaaS・パッケージやローコード、法務統制や複雑な外部連携が競争力に直結する場合はカスタム開発が候補になります。最初からスクラッチ開発に決めず、Fit & Gapを行って標準機能と独自開発の境界を見極めます。

SaaS・パッケージを導入する発注

SaaSやパッケージは、申請、承認、通知、検索などの共通機能を短期間で使い始めやすい方法です。料金を比較するときは、ライセンスだけでなく、初期設定、フォーム作成、権限設定、データ移行、教育、追加連携の費用を合算します。例えばkintoneは2026年8月確認時点でライトが月額1,000円、スタンダードが1,800円、ワイドが3,000円の1ユーザー単位で、初期費用無料です(税抜、最低10ユーザー)。一方、実際の申請アプリ設計や電子契約連携は別途必要になるため、ライセンス価格をそのまま導入費用と考えてはいけません(出典: サイボウズ株式会社「kintone 料金」、2026年8月確認)。

標準の承認経路に合わせられる企業、まず1〜3種類の手続で試したい企業に向いています。ただし、製品の標準機能を超える複雑な審査、案件単位の細かな権限、大量文書の特殊な検索を無理に追加すると、カスタマイズ費用と将来の保守負担が増えます。

ローコードで内製・共同開発する発注

ローコードは、フォームや一覧、簡単なワークフローを自社で変更しやすく、現場の改善サイクルを回しやすい方法です。外部会社にすべてを任せるのではなく、業務部門が手続マスタや承認経路を管理し、委託先が初期設計、連携、権限、移行を支援する分担もできます。発注時には、納品物にアプリ設定だけでなく、設計書、権限一覧、データ定義、変更手順、管理者教育を含めます。

一方で、製品のAPI制限、添付容量、検索性能、権限の粒度、監査ログの保存期間は事前検証が必要です。ローコードなら安いと決めつけず、プラグイン費、連携コネクタ、専門会社の支援費、将来の運用担当者の工数まで含めて比較します。

スクラッチ開発を委託する発注

スクラッチ開発は、独自の審査ルール、複数法人の権限、行政・基幹システムとの連携、特殊な文書管理など、標準製品に合わせることが難しい場合に選びます。申請ID、手続種別、担当部署、ステータス、期限、文書ID、承認履歴をデータとして分け、変更される業務ルールを設定値として管理できる構成にすると、法令改正や組織変更に対応しやすくなります。

ただし、要件を固める前の一括請負は、仕様変更や例外処理が増えたときに追加費用が発生しやすい方法です。初期の企画・要件整理は準委任で進め、機能が確定した部分から請負に切り替える段階発注も有効です。開発会社の提案に任せるのではなく、自社が業務上譲れない統制と、製品に合わせられる部分を分けて提示します。

手続管理システムの発注・外注はどの順番で進めますか?

手続管理システムの発注プロセスを進めるイメージ

発注は、現状把握、対象範囲の決定、RFP作成、提案・見積比較、契約、要件定義、設計・開発、テスト、移行・教育、運用評価の順で進めます。開発会社へ相談する前に、自社側で手続の一覧と困っている点を整理するだけでも、提案の比較可能性が大きく高まります。

現状の手続と課題を棚卸しする

まず、手続名、申請者、受付方法、承認者、処理期限、添付書類、保存年限、利用しているExcelやメール、連携先を手続ごとに記録します。担当者へのヒアリングでは「通常時の流れ」だけでなく、差し戻し、代理承認、緊急処理、担当者の異動、申請の取り下げなどの例外を聞き出します。月間件数、平均処理時間、期限超過件数、差し戻し率を現状値として残すと、導入後の効果測定に使えます。

対象手続が10種類以上ある場合でも、最初からすべてを同じ優先度にしません。処理量が多い、ミスや期限超過の影響が大きい、関係部署が多い、標準化しやすい手続を先行候補にします。代表的な1〜3種類をPoCの対象にすると、業務部門が実際に使えるかを確認しながら要件を調整できます。

Fit & GapとPoCで発注範囲を絞る

候補のSaaSやパッケージを選んだら、現状業務を製品の標準機能でどこまで処理できるかを確認します。申請フォーム、条件分岐、代理承認、通知、全文検索、CSV出力、SSO、監査ログ、電子署名連携を同じシナリオでデモしてもらい、標準、設定変更、追加開発、不可能の4段階で記録します。

PoCでは見た目だけでなく、実データに近い添付文書、権限の異なる利用者、差し戻し、期限超過、担当者変更を試します。性能や検索精度を確認し、処理時間、入力漏れ、差し戻し率、利用者の操作負担を測ります。PoCの結果をRFPの別紙に反映し、契約後に「想定外の追加要件」とならないようにします。

移行・教育・リリースまでを発注に含める

開発完了をゴールにせず、過去の申請書や契約書をどこまで移行するかを決めます。移行対象の期間、文書の形式、ファイル名、必須メタデータ、重複や欠損の扱い、移行後の検索確認を明文化します。移行データを委託先へ渡す場合は、受け渡し方法、アクセス権、保管期間、返却・削除の証跡も確認します。

リリース前には、業務部門による受入テスト、権限テスト、障害時の復旧テスト、通知の到達確認を実施します。操作マニュアルを納品してもらうだけでは定着しにくいため、申請者向け、承認者向け、管理者向けに教育を分け、問い合わせ対応と旧システムの停止時期まで計画します。

RFPと要件整理には何を書けばよいですか?

手続管理システムのRFPと要件を整理するイメージ

RFPは、開発会社に「何を作ってほしいか」だけでなく、「なぜ必要か」「どの条件で提案を比較するか」を伝える文書です。会社ごとに前提が違うまま提案を受けると、安い見積もりが機能不足、高い見積もりが過剰設計という状態になりやすいため、要求と評価基準をそろえます。

業務要件は手続単位の一覧で示す

業務要件には、手続名、対象者、申請項目、必須・任意の別、添付書類、承認経路、条件分岐、差し戻し条件、通知先、処理期限、保存年限、検索条件、出力帳票を記載します。手続マスタを管理者が変更できるのか、変更時に承認が必要なのか、過去の申請へ影響させないのかも決めます。

特に重要なのは例外処理です。「部長が不在なら代理承認」「一定金額以上は法務審査」「添付不備なら申請者へ補正依頼」「期限を超えたら管理者へ引き上げ」といった条件を文章で書き、通常フローと区別します。例外を後から追加するとテストと見積もりが膨らむため、頻度の高い例外は初期要件に含めます。

非機能要件とセキュリティ要件を先に書く

機密文書を扱う手続管理システムでは、機能要件だけで委託先を比較できません。利用者数と同時接続数、稼働時間、障害時の復旧目標、バックアップ、通信・保存時の暗号化、MFAやSSO、IP制限、権限レビュー、監査ログの改ざん防止、ログの保存期間、脆弱性対応、データ所在をRFPに記載します。

個人情報を含む場合は、委託先の再委託管理、従業者のアクセス制御、インシデント発生時の報告期限、調査協力、契約終了時の返却・消去を確認します。個人情報保護委員会も、クラウド環境を利用するサービスでは安全管理措置や委託先管理を確認する考え方を示しています。RFPの質問票と契約書の安全管理条項を連動させ、提案書の「セキュリティ対応済み」という一文だけで判断しないことが大切です(出典: 個人情報保護委員会「クラウド環境を利用して開発・提供する場合の留意点」)。

納品物と提案条件をそろえる

RFPでは、画面やプログラムだけでなく、要件定義書、画面・データ・権限の設計書、テスト仕様書と結果、移行計画、操作マニュアル、運用手順、API仕様、ソースコードや設定情報の扱いを納品物として指定します。クラウドサービスの場合も、データをどの形式で返却できるか、契約終了後にいつ消去されるかを確認します。

提案書の提出形式もそろえます。初期費用、月額・年額、ライセンス、導入支援、データ移行、連携、教育、保守、追加開発単価を分け、標準機能と個別開発を区別して記載してもらいます。さらに、前提条件、除外項目、顧客側の作業、納期、体制、類似事例、想定リスクを同じ章立てで求めると、金額だけに引っ張られない比較ができます。

契約形態は請負と準委任をどう使い分けますか?

手続管理システムの契約形態を確認するイメージ

契約形態は、成果物を完成させる段階と、要件を探索しながら支援する段階で分けて考えます。請負は合意した仕事の完成を目的にしやすく、準委任は善管注意義務のもとで調査・設計・助言・開発作業を委託する形にしやすい契約です。名称だけでなく、成果、責任範囲、検収、報酬、変更手続を契約書と個別仕様書で確認します。

請負契約に向く範囲と注意点

要件、画面、連携、テスト条件、納期が確定している開発や、確定した機能単位の追加開発は請負契約に向いています。検収基準を明確にできるため、発注側は完成状態を判断しやすくなります。ただし、仕様書にない変更を無償対応と期待すると、品質低下や追加請求につながります。

請負で発注する場合は、受入テストの観点、重大障害の定義、修補期限、検収の期限、仕様変更の承認フローを定めます。文書移行や外部システム連携は、相手方のデータ品質やAPI仕様に左右されるため、完成責任の範囲と発注者側の協力事項を切り分けます。

準委任契約に向く範囲と注意点

業務ヒアリング、現状分析、要件定義、製品選定、PoC、アジャイル型の機能改善など、進めながら内容が具体化する作業は準委任契約に向いています。作業時間や体制に対して報酬を支払う形になりやすいため、月ごとの成果報告、稼働上限、会議体、意思決定者、課題管理表を設けます。

準委任だから品質責任が不要という意味ではありません。合意した作業内容、専門家としての説明責任、成果物のレビュー方法、知的財産権、秘密保持、再委託、情報セキュリティを明文化します。IPAの「情報システム・モデル取引・契約書」では、受託開発の段階や請負・準委任の組み合わせを整理しているため、契約交渉のたたき台として参照できます(出典: IPA「情報システム・モデル取引・契約書」、2025年版資料)。

要件定義と開発を段階発注する

手続管理システムでは、現場の例外やデータ移行量が要件定義の途中で判明しやすいため、企画・現状分析、要件定義、開発・導入、保守を分ける段階発注が有効です。最初の契約で全期間の仕様と金額を固定せず、各段階の成果物と次段階へ進む判断基準を決めます。

段階発注では、成果物の所有権、既存設定の再利用、途中解約時のデータ返却、次の開発会社へ引き継ぐ資料、追加見積もりの単価を先に確認します。発注先を一社に固定する場合でも、データ形式やAPI仕様を自社で把握し、ベンダーロックインを避けるための出口条件を契約に入れます。

手続管理システムの発注費用・外注費用の相場

手続管理システムの費用相場を確認するイメージ

手続管理システムの受託開発費用は、公的な一律相場があるわけではありません。ここでは、リサーチノートの一次Q&Aをもとに、手続数、利用者数、承認分岐、連携数、文書移行量を変数として整理した推定レンジを示します。実際の予算は、同じRFPで複数社から見積もりを取り、前提条件と除外項目を比較して決めます。

開発規模別の費用レンジ

1〜3種類の申請フォーム、単純な承認、検索、通知、CSV出力を中心とする小規模な刷新は、300万〜1,500万円が目安です。10〜50種類程度の手続、複数部署の条件分岐、添付文書、権限、監査ログ、基幹連携、過去データ移行を含む標準規模では、1,500万〜4,000万円が目安になります。行政向けの外部申請、本人確認、審査、複数台帳、強い可用性や災害対策まで含める場合は、4,000万円超を想定して予算枠を検討します。

この金額は手続管理システム単独の公的統計ではなく、業務システム刷新に関する一次Q&Aの整理を対象領域へ適用した推定です。特定の金額を断定するものではありません。RFPでは、手続数、利用者数、連携先、文書件数、保存期間、必要な可用性を明示し、レンジのどこに位置するかを説明してもらいます。

SaaS・パッケージの価格を初年度総額で見る

公式料金が公開されている製品は、ライセンス部分のベンチマークになります。例えば住友電工情報システムの楽々WorkflowII Cloudは、公式ページで初期費用5万円、基本料金月1万円、1ユーザー月500円と案内されています。50ユーザーなら月額は3万5,000円、初年度のライセンス部分は47万円となりますが、税抜であり、導入支援、連携、追加オプションは別途確認が必要です。オンプレミス版は基本ライセンス300万円からと案内されています(出典: 住友電工情報システム「楽々WorkflowII 価格・ライセンス体系」、2026年8月確認)。

kintoneは最低10ユーザーで、ライトならライセンスだけで月額1万円、スタンダードなら月額1万8,000円、ワイドなら月額3万円です。業務アプリの設計、権限・通知設定、帳票、電子署名、データ移行、教育を含めた初年度総額は、リサーチノートの試算では50万〜500万円程度ですが、これは利用範囲による推定値です。SaaSは安く見えても、複数サービスを組み合わせると月額と保守窓口が増えるため、5年程度の運用費も比較します。

保守・運用・法改正対応の費用を分ける

初期開発費だけでなく、クラウド利用料、ライセンス、監視、バックアップ、ヘルプデスク、障害対応、脆弱性対応、法令や組織変更に伴う改修、軽微なフォーム変更、データ保管を分けて見積もります。リサーチノートでは保守費を初期開発費の年5〜15%程度とする整理がありますが、月額か年額か、何が含まれるかで意味が変わるため、参考レンジとして扱います。

電子帳簿保存法の対象文書を扱う場合は、検索要件、改ざん防止、保存期間、関連するシステム関係書類、ダウンロード要求への対応を確認します。国税庁の電子取引・電子帳簿保存制度の資料をもとに、法務や経理の責任者と要件を確認し、法改正時の対応主体と追加費用を契約に記載します(出典: 国税庁「電子取引関係」および令和8年6月資料)。

委託先の選定と見積比較で確認するポイント

手続管理システムの委託先を比較するイメージ

委託先は、知名度や提示価格だけでなく、手続の理解力、要件定義の進め方、データ移行、セキュリティ、運用支援を同じ基準で比較します。カスタム開発会社と完成済みSaaSのベンダーは役割が異なるため、提案内容が自社の発注形態に合っているかを見極めます。

同種の手続・業界の実績を確認する

実績は「ワークフローを導入した件数」だけでなく、契約審査、行政申請、本人確認、複数法人の権限、文書移行など、自社に近い手続を確認します。可能であれば、導入前の課題、対象手続数、利用者数、連携、移行、稼働後の保守体制を匿名の範囲で聞きます。提案担当者と開発・運用担当者が異なる場合は、契約後の責任者を面談に同席させます。

開発会社が要件定義をどのように行うかも重要です。現場ヒアリングの回数、業務フロー図やプロトタイプの作成、例外の洗い出し、Fit & Gap、受入テスト支援が見積もりに含まれるかを確認します。要件定義を発注側がすべて準備する前提なら、その作業を自社で担える体制があるかを検討します。

見積もりの前提・工数・除外項目をそろえる

見積書は総額より先に、前提条件と内訳を確認します。要件定義、画面・API設計、開発、テスト、移行、教育、PM、インフラ、ライセンス、保守を分け、各項目の数量や工数が読める状態にします。手続数や画面数、連携先が何件として計算されているかを確認し、A社だけデータ移行を含み、B社は除外しているような比較条件の違いをなくします。

特に、追加開発単価、仕様変更の扱い、休日・夜間対応、再委託費、クラウド費の改定、ストレージ超過、データ返却、契約終了時の移行支援を見落としやすいです。安い見積もりを採用するのではなく、同じ要件で不足しているものがないかを確認し、必要なら見積もりを二段階に分けます。

安全性とベンダーロックインの対策を確認する

委託先には、権限設計、MFA・SSO、暗号化、ログ監視、バックアップ、脆弱性対応、再委託先、インシデント対応を質問します。機密文書を扱う場合は、検証環境へ本番データをコピーしないこと、退職・異動時の権限を速やかに剥奪すること、管理者権限を記録することも要件に含めます。AIで書類の項目抽出や不備チェックを行う場合は、入力データの学習利用、ログの保存、誤判定時の人によるレビュー、最終承認者を明確にします。

ロックインを防ぐには、申請データと文書を標準的な形式で出力できるか、API仕様やデータ辞書が提供されるか、契約終了時に移行支援を受けられるかを確認します。自社がフォームや承認経路を変更できる範囲、委託先へ依頼する場合の単価、保守SLA、法改正時の対応範囲を事前に決めると、運用開始後の主導権を保ちやすくなります。

手続管理システムの発注でよくある質問

手続管理システムのよくある質問を確認するイメージ

最後に、発注前に特に相談が多い質問をまとめます。費用や契約の答えは、対象手続、利用者、連携、移行、セキュリティの条件によって変わるため、以下の回答をRFPの確認項目として利用します。

手続管理システムの開発費用はいくらですか?

特定業務に絞った小規模な刷新は300万〜1,500万円、複数の契約・法務手続と連携や移行を含む標準規模は1,500万〜4,000万円が推定目安です。行政向けの本人確認、審査、複数台帳、強い可用性まで含める場合は4,000万円超も想定します。これは固定相場ではないため、手続数、利用者数、分岐数、連携数、文書量を示して複数社から見積もりを取ります。

SaaSとスクラッチ開発はどちらがよいですか?

早期導入や標準化を優先し、製品の承認・通知・検索に業務を合わせられるならSaaS・パッケージが向いています。独自の審査、複雑な権限、特殊な文書管理、既存基幹との深い連携が重要ならスクラッチ開発が候補です。判断に迷う場合は、1〜3手続のPoCで標準機能の限界と、独自開発が必要な部分を確認します。

RFPは自社だけで作成できますか?

手続一覧、現状フロー、困りごと、利用者、連携先、セキュリティ条件を自社で整理し、詳細な要件定義やRFPのレビューを外部へ支援依頼する進め方が現実的です。最初から技術仕様を固定するより、業務要件、評価基準、提案の前提条件を明確にし、候補会社へ同じ条件で提案してもらうことが重要です。

まとめ

手続管理システムの発注をまとめるイメージ

手続管理システムの発注・外注は、製品や開発会社を先に決めるのではなく、社内申請・契約や法務手続なのか、行政・対外手続なのかを分け、現状の手続、例外、文書、連携、期限を棚卸しすることから始めます。SaaS・パッケージ、ローコード、スクラッチにはそれぞれ向き不向きがあるため、Fit & GapとPoCで標準機能と独自開発の境界を確認します。

費用は、小規模な刷新で300万〜1,500万円、標準規模で1,500万〜4,000万円を推定レンジとして検討し、行政向けの大規模連携では4,000万円超も想定します。これは要件によって変動する目安です。RFPでは手続数、利用者数、承認分岐、データ移行、API、非機能要件をそろえ、初期費用だけでなくライセンス、保守、法改正、教育、契約終了時の移行まで比較します。

契約は、要件を探索する段階を準委任、仕様と検収条件が確定した開発を請負とする段階発注が選択肢になります。委託先の実績、要件定義力、セキュリティ、データ返却、保守SLAを同じ質問票で確認し、現場が継続的に手続を改善できる体制まで含めて選定することが、発注後の成功につながります。

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

会社紹介

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

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

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

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

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

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