LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

申請承認ワークフローシステムとは：電子化が解決する課題

申請承認ワークフローシステムとは、稟議書・経費申請・休暇申請・契約承認など、組織内の申請行為と承認フローを電子化・自動化するシステムです。紙の回覧や個別のメール承認を廃止し、誰がどの段階で承認・却下・差し戻しを行ったかを一元管理します。

紙・メール承認が引き起こす4つの問題

紙の回覧や個別のメール承認には、承認状況の不透明さ・承認漏れのリスク・監査証跡の散在・テレワーク時の業務停滞という問題があります。特に上長が出張中や在宅勤務の場合、紙の回覧は業務を完全に止めてしまいます。

申請承認ワークフローシステムを導入すると、申請者はシステム上で申請を登録し、承認者にはメールやSlack等で通知が届きます。承認・却下・差し戻しの操作はPC・スマートフォンから行え、全ステップの操作ログが自動的に記録されます。

対象業務の範囲と承認フローの種類

申請承認ワークフローシステムが対象とする業務は幅広く、稟議・購買申請・経費精算・休暇申請・契約承認・人事異動申請などが代表的です。承認フローの形式は大きく3種類に分かれます。

• 直列承認：A承認→B承認→C承認と順番に進む。スタンダードな稟議フロー。
• 並列承認：複数の承認者が同時並行で承認する。全員の承認を要件とする「AND条件」と、いずれか1名でよい「OR条件」がある。
• 条件分岐承認：申請金額・申請種別・組織階層によって承認経路が変わる。例「100万円以上は部長承認を追加」。

この条件分岐の複雑さが、外注費用と開発期間に直結します。フローの複雑さを設計段階から整理しておくことが、外注成功の前提条件です。

外注開発の費用相場：内訳とレンジの目安

申請承認ワークフローシステムの外注費用は、開発方式（ノーコード活用かスクラッチか）・承認フローの複雑さ・既存システムとの連携数によって大きく異なります。以下は市場参考値であり、一次資料に基づく公的調査ではありません。実際の発注時には複数社から見積もりを取得し比較することが大切です。

費用に影響する主な要因

見積もりを大きく左右する要因を整理します。まず承認経路の複雑さです。条件分岐の数が増えるほど、ルーティングエンジンの設計・テストパターンが増え、開発工数が積み上がります。

次に既存システムとの連携です。会計システム・人事システム・ERPとのAPI連携が必要な場合、連携1本あたり50万〜200万円程度の工数が上乗せされることがあります（市場参考値）。連携対象が多いほど費用は増加します。

電子帳簿保存法（電帳法）対応やタイムスタンプ付与も追加コスト要因です。経費精算書や稟議書を電子的に保存する場合、訂正削除履歴の保持・検索要件への対応が義務付けられます。要件定義段階でこれらを洗い出しておかないと、後から追加開発が発生します。

見積もり内訳の確認ポイント

外注先から見積書を受け取る際は、以下の内訳が明示されているか確認してください。

• 要件定義・設計費（基本設計・詳細設計）
• 開発費（フロントエンド・バックエンド・DB設計）
• 連携開発費（API・既存システム接続）
• テスト費（単体・結合・UAT支援）
• 移行費（データ移行・並行運転期間）
• 保守・運用費（月次コスト・SLA条件）

「一式」まとめの見積もりは費用内訳が不透明になります。フェーズ別・機能別の内訳を求め、後から発生しやすい追加費用（仕様変更・バグ修正範囲）の取り扱いも事前に確認しておきましょう。

ノーコード・ローコードvsスクラッチ：開発方式の選び方

申請承認ワークフローの開発では、ノーコード・ローコードツール（kintone（サイボウズ）・Microsoft Power Automate・Nintex等）の活用とスクラッチ開発の二択が迫られます。選択を誤ると、後から大規模な改修が必要になります。

kintoneなどノーコードツールの活用例と限界

kintone（サイボウズ株式会社）はノーコードでワークフロー・アプリを構築できるクラウドサービスです。稟議・経費申請・設備申請などのシンプルな承認フローなら、設定ベースで構築でき、開発期間を短縮できます。

ただし、承認経路の条件分岐が複雑な場合やレガシー基幹システムとのリアルタイム連携が必要な場合は、kintoneの標準機能では対応が難しくなります。プラグインや外部連携ツールを多用すると、保守が複雑になる点にも注意が必要です。

スクラッチ開発を選ぶべきケース

承認ルートを申請金額・申請者の所属部門・申請種別の組み合わせで動的に切り替える仕組みや、差し戻し時に「承認者全員へ戻す」か「直前の承認者のみへ戻す」かをフローごとに制御する要件は、ノーコードツールの標準機能では実現が困難です。

既存の会計システムや人事システムが独自APIしか持たない場合も、スクラッチ開発を選択するか、専用のミドルウェア層を設ける必要があります。内製化の可能性も含めてIT部門と議論した上で外注先を選定しましょう。

外注の進め方：要件定義から本番稼働まで5ステップ

ワークフローシステムの外注において、要件の曖昧さは手戻りと追加費用の主因です。以下の5ステップで進めることで、これらのリスクを抑えられます。

ステップ1：現状業務の棚卸しと承認フロー図の作成

まず、対象となる申請業務を洗い出し、現行の承認フローを図示します。「誰から誰へ」「どの条件で分岐するか」「代理承認・差し戻しのルール」を現場担当者・法務・経理とヒアリングして整理します。この段階で作成したフロー図が、外注先への依頼仕様の土台になります。

フロー図の精度が高いほど、外注先の見積もりも正確になります。曖昧な仕様のままRFP（提案依頼書）を送ると、後から「仕様変更」扱いで追加費用が発生します。

ステップ2：開発方式の選定とRFP作成

ステップ1の整理をもとに、ノーコード・ローコードかスクラッチかを決定します。RFPには、対象業務の一覧・承認フロー図・連携対象システム一覧・電帳法対応の有無・セキュリティ要件・納期・予算概算を明記します。

複数の外注先（最低3社）に同じRFPを送り、提案書と見積書を比較します。費用だけでなく、要件の読み取り精度・ワークフローシステムの開発実績・保守体制も評価軸に加えてください。

ステップ3：要件定義フェーズの実施

外注先が決まったら、まず要件定義フェーズを実施します。このフェーズでは、承認フロー・データモデル・画面設計・API連携仕様・非機能要件（性能・セキュリティ・可用性）を文書化します。要件定義書は、後続の開発フェーズの契約仕様書にもなります。

要件定義を準委任契約で進め、開発フェーズを請負契約に切り替えるケースでは、要件定義書の完成度が請負契約の成否を左右します。要件定義書の承認前に開発フェーズの契約を結ぶことは避けましょう。

ステップ4：開発・連携実装・テスト

開発フェーズでは、承認フローエンジン・画面・通知機能・API連携を実装します。開発完了後、単体テスト・結合テストに続き、実際の業務担当者が操作する受入テスト（UAT：User Acceptance Testing）を実施します。

UATでは「代理承認が正しく記録されるか」「差し戻し後に正しい段階から再開されるか」「承認ログがCSVで出力できるか」など、実運用を想定したシナリオを事前に作成して検証します。内部統制・監査対応の観点から、ログの出力形式もこの段階で確認してください。

ステップ5：移行・本番稼働・保守契約

本番稼働前に、ユーザー教育（操作マニュアル・説明会）と並行運転期間の設定が必要です。既存の紙・メール承認と新システムを一定期間並行稼働させ、問題がなければ完全移行します。

本番稼働後の保守契約は、SLA（サービスレベルアグリーメント：障害対応時間・可用性目標）と月額費用を明確にした上で締結します。ワークフローのロジック変更・承認者マスタの更新などの軽微な改修をどちらが担うかも、事前に取り決めておきましょう。

外注先の選び方と契約形態（請負・準委任）

外注先選定では、ワークフローシステムの開発実績・業界理解・保守体制の3軸で評価することが大切です。費用の安さだけで選ぶと、要件理解の甘さや保守サポートの手薄さで後から問題が生じます。

外注先評価の3つのポイント

第一に、ワークフローシステムの開発実績です。稟議・経費申請・契約承認など、対象業務に近い開発事例があるかどうかを確認します。実績があれば、業務固有の落とし穴（代理承認のエッジケース・組織変更時のマスタ更新など）を事前に把握しています。

第二に、既存システムとの連携経験です。会計システム（SAP・勘定奉行等）・人事システム・ERPとの連携実績がある外注先は、連携仕様の確認や不整合の検出が早い傾向があります。連携先システムのベンダー名を提示して、対応経験を確認してください。

第三に、本番稼働後の保守体制です。承認フローのロジック変更や人事異動に伴うマスタ更新など、稼働後も継続的な改修ニーズが発生します。月次保守契約の内容・担当者の継続性・問い合わせ対応時間を事前に確認しましょう。

請負契約と準委任契約の使い分け

請負契約は、成果物（完成したシステム）の納品と引き換えに報酬を支払う形態です。仕様が明確で変更が少ない開発フェーズに適しています。一方、仕様変更が生じた場合は「追加工事」扱いになりやすく、費用が膨らむリスクがあります。

準委任契約は、作業量（人月）に対して報酬を支払う形態です。要件定義・プロトタイピングなど仕様が固まりきっていないフェーズに向いています。ただし、成果物の納品義務がないため、進捗管理とマイルストーンの設定を自社で行う必要があります。

実務では、要件定義を準委任・開発〜テストを請負と組み合わせる「ハイブリッド型」が採用されるケースも見られます。契約形態の選択は、自社のプロジェクト管理能力と仕様の確定度合いを踏まえて決定してください。

内部統制・電子帳簿保存法・監査証跡：見落としやすい要件

申請承認ワークフローシステムは、単なる業務効率化ツールではありません。内部統制・コンプライアンス・法令対応の要件を見落とすと、稼働後に監査対応や法令改正で大きな改修コストが発生します。

内部統制とJ-SOX（金融商品取引法）への対応

上場企業またはその連結子会社では、金融商品取引法に基づく内部統制報告制度（J-SOX）の対応が求められます。ワークフローシステムの承認ログ（誰が・いつ・何を承認したか）は、ITシステムに係る内部統制の評価対象になります。

具体的には、承認者の変更履歴・差し戻し理由の記録・代理承認の設定記録など、監査証跡（オーディットトレイル）として一定期間保存できる設計が必要です。外注先に内部統制対応の要件を明示しておかないと、後から追加開発が発生します。

電子帳簿保存法への対応要件

経費精算書・稟議書など国税関係書類に該当する書類を電子的に作成・保存する場合、電子帳簿保存法（電帳法）の要件への対応が必要です。特に電子取引データの保存ルール（令和6年1月以降、原則として電子データでの保存が必要。要件を満たせない場合の猶予措置あり）は、経費申請システムを外注開発する際に確認が欠かせない事項です。

電帳法が要求する主な要件は、真実性の確保（タイムスタンプ付与または訂正削除履歴の保持）・可視性の確保（検索要件：日付・金額・取引先で検索できること）です。これらの機能要件を、RFPに明記しておく必要があります。

代理承認・差し戻し設計と監査対応

代理承認は、長期不在の承認者の代わりに別の担当者が承認する機能です。「誰が誰の代理になれるか」の設定ルール・代理承認の事実が承認ログに記録されるかどうかが、監査上の重要ポイントになります。

差し戻しは、承認者が申請内容に問題があると判断した際に申請者（または直前の承認者）へ差し戻す機能です。「差し戻し理由の記録必須化」「差し戻し後に何段階目から再開するか」を要件として明記しないと、監査証跡が不完全なシステムになります。

失敗回避の実務ポイント：承認フロー設計と連携仕様

ワークフローシステムの外注で多く発生する問題は、要件定義の不足から生じます。ここでは実務上の失敗パターンとその回避策を整理します。

失敗1：組織変更で承認フローが壊れる

承認フローを「個人名」で設定すると、人事異動・組織改編のたびに手作業でフローを修正する必要が生じます。承認者を「役職・グレード・組織コード」で設定できるマスタ管理型の設計にすることで、組織変更時の影響範囲を最小化できます。

要件定義段階で「組織マスタをどこから取得するか（人事システムとの連携か手動管理か）」「承認者マスタの更新は誰が行うか」を決定しておくことが大切です。

失敗2：会計・人事システムとの連携仕様の後付け

ワークフローシステムで承認された経費申請データを会計システムへ自動連携する要件は、開発初期に組み込まないと後から大規模な改修が必要になります。連携対象システムのAPIドキュメント（仕様書）を外注先に早期提供し、連携仕様を要件定義書に盛り込んでください。

既存システムが古くAPIを持たない場合（ファイル連携のみ対応など）は、中間ファイルの形式・連携タイミング・エラー時の再送方式も仕様として定義する必要があります。これを後回しにすると、連携開発で予期せぬ費用が発生します。

失敗3：テストシナリオの不足による本番トラブル

承認フローの条件分岐が多い場合、テストシナリオが不十分だと本番稼働後に「特定の条件でフローが止まる」「差し戻しの挙動が期待と異なる」といった問題が発生します。

受入テスト（UAT）では、通常ルート以外の「エッジケース（境界値・例外ケース）」も網羅したシナリオを用意してください。テストシナリオの作成を外注先に丸投げすると、自社の業務固有のケースが抜け落ちるリスクがあります。業務担当者が参加してシナリオを作成することを推奨します。

内製化とのハイブリッド判断

ワークフローシステムの外注では、フロー設計・マスタ管理・運用ルールの整備を内製側が担い、技術的な実装を外注先に委ねるハイブリッド型が有効です。社内のIT部門がノーコードツールを操作できる場合は、初期構築を外注→改修・拡張を内製とすることで、ランニングコストを抑えられます。

一方、IT部門のリソースが限られている場合は、保守・運用まで含めた長期外注契約を検討することも選択肢です。外注先との役割分担を初期から明確にしておくことが、長期的なシステム維持のカギになります。

まとめ：外注判断の3つの軸

本稿では、申請承認ワークフローシステムの外注開発について、費用相場・開発方式の選択・進め方・内部統制対応・失敗回避のポイントを整理しました。要点を3つに集約します。

第一に、費用と開発方式は「承認フローの複雑さ」で決まります。シンプルな直列承認であればノーコード・ローコードツールで費用・期間を抑えられます。条件分岐が多く・既存システムとの深い連携が必要な場合はスクラッチ開発を選択してください。

第二に、要件定義の精度が外注成功の分岐点です。承認フロー図・連携システム一覧・電帳法対応要件・監査証跡要件を、RFP送付前に整理することが手戻り防止につながります。見積もりを複数社から取得し、費用だけでなく実績・保守体制も比較してください。

第三に、内部統制・電子帳簿保存法への対応は初期設計に組み込む必要があります。後付けで対応すると大規模な改修コストが発生します。法令要件を要件定義書に明記し、外注先が対応経験を持つかどうかを確認してから発注先を決定しましょう。

よくある質問

申請承認ワークフローシステムの外注開発にかかる費用の目安はどのくらいですか？

市場参考値として、ノーコード・ローコードツールを活用したカスタマイズ型は300万〜800万円程度、スクラッチ開発は800万〜3,000万円超が目安とされています（一次資料ではなく市場参考値）。費用は承認経路の複雑さ・既存システム連携数・電子帳簿保存法対応の有無によって大きく変動します。実際の発注前に複数社から見積もりを取得することをおすすめします。

ノーコードツール（kintoneなど）とスクラッチ開発のどちらを選べばよいですか？

承認フローが比較的シンプル（直列承認・3段階以内）で、短期稼働を優先する場合はノーコード・ローコードツールが適しています。承認経路の条件分岐が複雑・既存基幹システムとの深いAPI連携が必要・将来的な大幅カスタマイズが見込まれる場合はスクラッチ開発が選択肢になります。要件定義フェーズでITベンダーと一緒に判断することが大切です。

電子帳簿保存法への対応はワークフローシステムに含まれますか？

経費申請・稟議書など国税関係書類に該当する書類を電子的に作成・保存する場合、電子帳簿保存法（電帳法）の要件への対応が必要です。タイムスタンプ付与・訂正削除履歴の保持・日付や金額での検索機能といった要件を、要件定義段階から外注先と確認することが大切です。RFPにこれらの要件を明記しておくと、見積もりの精度が高まります。

請負契約と準委任契約のどちらが適していますか？

要件が明確で成果物（完成したシステム）の納品を求める場合は請負契約が適しています。要件定義フェーズや仕様変更が多いフェーズでは、作業量に対して報酬を支払う準委任契約のほうが費用調整がしやすいです。実務では要件定義を準委任、開発・テストを請負と使い分けるケースも見られます。どちらが適切かは自社のプロジェクト管理能力と仕様の確定度合いで判断してください。

代理承認や差し戻し機能はどのように要件定義すればよいですか？

代理承認は「誰が誰の代理になれるか（役職・組織単位での設定）」「代理承認の事実が承認ログに記録されるか（監査証跡）」を明確にする必要があります。差し戻しは「どの段階にどこまで戻すか（直前の承認者のみ／申請者まで全戻し）」をフロー図で整理してから外注先に伝えると、見積もりの精度が高まります。内部統制の観点から、差し戻し理由の記録必須化も検討してください。

著者：テレリモ総研編集部　鈴木 亮佑

---

ご不明な点はお問い合わせフォームからもご連絡いただけます。