DX

稟議システム比較5タイプの違いと選び方|ランキング・シェアの正しい読み方

稟議システムの比較記事を開くと、16製品や35製品の一覧表が並びます。表を眺めても候補が絞れないのは、比較軸が自社の稟議の形と噛み合っていないからです。この記事では、5タイプの製品分類と向く企業条件、ランキングやシェアが何を数えた順位なのか、稟議に固有の比較軸7項目、料金が想定より膨らむ構造、パッケージ比較では候補が残らない3条件までを整理します。

まとめ:稟議システムの比較で先に固める3条件と候補が絞れる順序

比較の順序は「自社要件の確定 → タイプの絞り込み → 個別製品の機能照合」です。逆順で製品から入ると、機能が多い製品ほど良く見えて判断が止まります。

先に固める3条件は、①残す申請書の点数(統合後の種類数)、②決裁権限規程の金額基準と経路が分岐する条件数、③合議・代理承認・差し戻しの発生頻度です。この3つが決まると、稟議特化型・グループウェア一体型・バックオフィス一体型・業務基盤(ローコード)型・Excelフォーム型のうちどのタイプが候補に残るかがほぼ決まります。

ランキングやシェアの数値は、そのまま選定根拠にはなりません。比較メディアの順位はレビュー件数の構成比や資料請求数を数えたもので、提供元自身が売上シェアではないと注記しています。

比較を続けても候補が残らない稟議の共通点は3つです。基幹システムの与信・在庫・原価と判断が連動している、業界固有の承認体系を持つ、社外組織の承認を経路に含む——このいずれかならパッケージのカスタマイズ費用が受託開発の見積りを超えることが起こります。境界は最終章で条件付きで示しました。定義・機能・仕組みは稟議システムとは?機能・仕組みと紙・メール稟議の課題から見る導入判断の基準で扱うため、この記事は選定判断に絞ります。

比較表を開く前に確定させる稟議要件:申請書点数・金額基準・合議の深さ

製品比較で迷う原因の大半は、自社要件が言語化されていないことにあります。要件が曖昧なまま比較表を見ると、どの製品も「できます」と読めてしまいます。

現行の申請書の棚卸しで残す点数を決める作業と、統合の判断基準

まず、紙・Excel・メール本文を含めて社内で回っている申請書を全て数えます。従業員300人規模でも60〜120種類に達する企業は珍しくなく、その中に様式は違うが承認経路と記載項目がほぼ同じ書類が混ざります。統合の判断基準は2つです。承認経路が同じで入力項目の差が3項目以内なら1つに統合し、差分は選択式の項目で吸収する。金額帯で承認者が変わる書類は経路の条件分岐で表現できるため、様式を増やしません。

決裁権限規程の金額基準と、承認経路が分岐する条件数の実務的な数え方

稟議の経路は、金額・組織階層・案件種別の3軸で分岐します。決裁権限規程に「50万円未満は部長決裁、50万円以上500万円未満は本部長決裁、500万円以上は役員会」とあれば金額軸の分岐は3段で、そこへ「システム関連はIT部門の合議を必須とする」という案件種別の条件が加わると経路パターンが掛け算で増えます。

数えるべきは経路パターンの総数ではなく「分岐条件の種類」です。条件が金額と部門の2種類なら、条件分岐の設定機能を持つ製品はほぼ対応できます。5種類以上あってAND/ORで組み合わさる場合は、設定画面の表現力に製品差が出ました。規程が金額基準を定めていない、実務と乖離しているなら、システム選定より先に規程の整備を済ませます。制度側の整理は稟議とは?意味・稟議書の書き方から決裁との違い・電子化の判断まで解説にまとめています。

合議・代理承認・差し戻しの実態を洗い出す3つの質問と確認手順

稟議が他の申請業務と違うのは、承認が直線的に進まない点です。運用実態を掴むため、稟議を回している担当者へ次の3つを確認します。

  • 1件の稟議で、承認ではなく「意見を求めるだけ」の関係者は何人入るか(=合議の人数と、承認との権限差)
  • 承認者が不在のとき実務ではどう処理しているか(代理押印・口頭了承の後追い・単に止まる、のいずれか)
  • 差し戻しは月に何件発生し、そのうち何件が「添付資料の版が古い」ことによるものか

差し戻しが月10件を超え半分が版違いなら、申請フォームに版番号と作成日を必須項目で持たせる設計が効きました。3つの答えが、次章以降の比較軸の重み付けをそのまま決めます。

稟議システムの5タイプ分類と、稟議特化型・一体型それぞれが向く企業条件

製品は機能の多寡ではなく、どの業務の中に承認機能が置かれているかで分かれます。この分類で見ると、候補は5つのうち1〜2タイプに収束します。

5タイプの分類軸と、稟議で刺さる条件・過剰になる条件の対応表

下表の製品名は比較メディアの分類・掲載時点に基づくもので、個別の仕様は各公式資料で確認してください。

タイプ 稟議で刺さる企業条件 過剰・不足になる条件 同タイプの例
稟議・ワークフロー特化型 申請書30種以上/分岐条件3種以上 申請書10種未満では使い切らない 代表3製品
グループウェア一体型 全社ポータルが未整備/稟議は月数十件 分岐が複雑だと経路設計で詰まる サイボウズ Office、グルージェントフロー
バックオフィス一体型 稟議の主対象が購買・経費・支払 人事系の申請では範囲外の設定が増える バクラク申請
業務基盤(ローコード)型 他の業務システムも同基盤で作る前提 稟議単体では構築工数が見合わない intra-mart ワークフロー、JUST.DB
Excelフォーム型 様式変更の社内合意が取れない 様式を統合する企業では足かせになる 特化型のフォーム設計機能として実装

特化型の代表3製品は、X-point Cloud、コラボフロー、楽々WorkflowIIです。使い方は中央2列を先に読むことです。「過剰・不足になる条件」に自社が当てはまるタイプを消すと、残りは1〜2タイプになります。統合後の申請書が30種類を超え分岐条件が3種類以上あるなら特化型が優位で、この規模では経路設計を総務・経理の担当者が自分で直せるかどうかが導入期間を左右しました。

グループウェア/バックオフィス一体型で足りる企業条件と運用上の限界

グループウェア一体型が向くのは、稟議が月数十件で社内ポータルもこれから整えたい企業です。ログイン先が1つに収まるため申請者側の定着が早く、限界は経路の表現力にあります。バックオフィス一体型は稟議の対象が購買・経費・支払に集中している企業で効き、承認後の内容が発注・支払処理へ引き継がれるため二重入力が消えます。ただし採用稟議や情報システムの利用申請まで同じ基盤に乗せると、業務範囲外の項目設定が増えました。ワークフローシステムとの範囲関係やクラウド型・オンプレミス型の違いはワークフローシステムとは?機能・クラウドとオンプレの違い・選び方と自社開発の判断基準で整理しています。

ランキング・おすすめ記事の順位根拠とITR公表の市場規模から読むシェア

「稟議システム シェア」「稟議システム ランキング」で表示される順位表は、それぞれ別のものを数えています。何を数えた数字か確認しないまま上位製品を候補にすると、選定理由が説明できません。

比較メディアのランキングが示す指標:レビュー件数構成比と資料請求数

比較サイトの「シェア動向」は、多くの場合サイト内に投稿されたレビュー件数の構成比です。ITトレンドのワークフローシステムのシェア動向は、1,279件のユーザーレビューの構成比としてサイボウズ Office 39%、ジョブカンワークフロー 8%、intra-mart ワークフロー 5%、楽々WorkflowII 5%、X-point Cloud 4% を示し、同時に「市場全体の売上シェアや導入社数そのものを示すものではありません」と自ら注記しています。

aspicのランキングは、資料ダウンロード数・PV数・口コミ数・導入実績スコアの加重平均です。順位が動く主因は露出量と来訪者の関心であって、導入企業数ではありません。順位表は候補の初期リストを作る道具として使い、選定根拠には用いません。

ITRが公表した国内ワークフロー市場110億円とSaaS比率の推移

市場全体の傾向は調査会社の公表値で確認できます。ITRが2023年7月18日に発表した国内ワークフロー市場の推移および予測では、2022年度の売上金額が110億円で前年度比13.4%増、2023年度は12.7%増の見込み、2027年度に200億円へ達すると予測されています(2022〜2027年度のCAGR 12.7%・数値は同発表時点)。

選定に効くのは総額より提供形態の内訳です。同発表では2022年度実績でパッケージ市場が前年度比マイナス3.9%、SaaS市場が32.6%増となり、2027年度にはSaaSが市場全体の約8割を占める見込みとされています。オンプレミス前提の製品を選ぶなら、この縮小傾向の中で機能改訂と保守が継続されるかをベンダーのロードマップで確認します。

順位表の使い方は1つに絞れます。上位10製品から、前章のタイプ分類で自社に残ったタイプの製品だけを抜き出す。この時点で候補は3〜4製品になり、順位そのものはその中の序列には用いません。レビュー件数が多い製品は稟議が月数十件の企業の声を多く含むため、申請書80種類・分岐条件5種類の企業がそのまま選ぶと経路設定で表現できないパターンが出ます。

稟議固有の比較軸7項目:条件分岐・代理承認・差し戻し・添付の版管理

一般的な比較記事が挙げる軸は、費用対効果・UI・既存システム連携・セキュリティの4点です。申請業務全般に共通する軸で、稟議に固有の詰まりどころは含まれていません。稟議で確認する7項目はこちらです。

  • 承認経路の条件分岐(金額・組織・案件種別の組み合わせの深さ)
  • 合議と承認の権限差(意見のみ/承認必須/否認権ありを分けて設定できるか)
  • 代理承認と不在時のエスカレーション(期限超過での自動転送)
  • 差し戻しの戻り先制御(申請者か直前の承認者かを経路ごとに指定できるか)
  • 添付ファイルの版管理(差し替え履歴が承認記録と紐づくか)
  • 監査ログの粒度(経路設定を誰が変更したかまで残るか)
  • 基幹システムとの連携方式(API/CSV/DB直参照と、流せる方向)

承認経路の条件分岐と、金額・組織・案件種別での自動振り分けの深さ

条件分岐は、どの製品も「対応」と書きます。差が出るのは組み合わせの深さです。確認方法は、自社で最も複雑な稟議1本の経路をトライアル環境で組んでみることに尽きます。「500万円以上かつシステム関連なら、IT部門の合議を経てから役員会へ」をノーコードの設定画面で表現できるか、スクリプトやカスタマイズが必要になるかで導入工数が桁違いになりました。あわせて、役職ベースの相対指定(申請者の2階層上)と役割ベースの固定指定(購買責任者)を経路ごとに使い分けられるかも見ます。

代理承認・不在時のエスカレーションと、監査ログに残る記録の粒度

承認者の不在で稟議が止まる問題は、代理承認機能だけでは解けません。代理者を事前登録する方式は突発的な不在に対応できないためです。期限を超えた案件を自動で次の承認者へ回すエスカレーション設定と、代理承認の記録が「本人ではなく代理者が承認した」と区別して残る仕様の両方を確認します。

監査ログの粒度も選定を左右しました。承認履歴が残るのは当然として、経路設定そのものを誰がいつ変更したかの記録が残らない製品もあります。監査法人から経路の変更履歴を求められた場面で、この差が作業負荷に直結します。

添付ファイルの版管理と電子取引データ保存に関わる要件の切り分け

稟議書そのものは、必ずしも国税関係帳簿書類に該当するわけではありません。要件が関わるのは添付資料です。取引先から電子で受領した見積書・契約書・請求書を稟議に添付する運用なら、その電子データは電子帳簿保存法の電子取引データに当たり、2024年1月以降は電子での保存が原則となっています(宥恕措置は2023年12月末で終了し、相当の理由がある場合の猶予措置が置かれています/2026年7月時点)。

比較段階で切り分けるのは1点です。稟議システムを電子取引データの保存場所として使うなら検索要件(取引年月日・金額・取引先での検索)を満たす機能が必須で、保存を文書管理側に置いて参照だけ持たせるなら添付の版管理と参照リンクの整合が要件になります。決めずに進めると、導入後に保存場所が二重化しました。

基幹システム・購買データとの連携方式(API/CSV)と二重入力の回避

稟議の承認結果は、その後の処理に引き継がれます。購買稟議なら発注、採用稟議なら人事マスタ、設備稟議なら固定資産です。連携方式はREST APIによるリアルタイム連携、CSVの夜間バッチ、DB直参照の3通りが実務で使われます。

比較で見るのは方式の有無ではなく、流せる方向とデータ項目です。基幹のマスタ(取引先コード・勘定科目・予算残高)を稟議の入力画面へ引いてこられない製品では申請者がコードを手入力し、承認後の転記ミスが残り続けました。申請時点で予算超過を検知する仕組みまで求めるなら、連携はAPI方式が前提です。

料金体系の比較と、申請者全員がユーザー課金対象になる場合の費用試算

料金の比較で見落とされるのは、単価ではなく課金対象の定義です。稟議は承認者だけの業務ではなく、全社員が申請者になります。

ユーザー課金・定額・従量の3方式と、稟議で対象人数が膨らむ構造と試算

クラウド型の課金方式は、登録ユーザー数に単価を掛ける方式、利用人数の上限つき定額、申請件数に応じた従量の3通りが中心です。稟議で費用が想定を超えるのは1つ目です。承認者が20人でも、申請者が全社員400人なら課金対象は420人になります。

確認するのは、申請だけを行う従業員向けに安価なライトプランや申請専用ライセンスがあるかどうかです。全員が同一単価の製品と申請者を別区分で数える製品では、同じ人数でも年額が数倍変わりました。単価の安さを比べる前に、想定人数を両方の料金表へ入れて損益分岐を出します。

初期費用に含まれない作業:申請書の移行設計と経路のテスト工数

見積書の初期費用に含まれるのは、環境構築と初期設定の支援までが一般的です。実務で工数が出るのは申請書の統合設計・経路パターンのテスト・既存稟議の移行判断の3つで、これは自社側の作業になります。目安は申請書1種類あたり0.5〜1人日、経路パターンが20通りならテストだけで別途数人日です。申請書60種類を初年度に全て移行する計画は担当者1人では回らないため、金額の大きい稟議から段階的に移すと工数が平準化されます。移行支援がオプション費用か標準の導入支援に含まれるかは、比較段階でベンダーに確認します。

トライアルで検証する5点と、比較表では見えない運用負荷の確認手順

候補が3製品に絞れたら、機能一覧の照合はここで終わりです。残る差は、自社の稟議を実際に流したときにしか出ません。

トライアルで自社の実申請書を1本通して製品差を見極める検証手順

確認するのはデモ用のサンプル申請ではなく、自社で最も複雑な稟議1本です。

  1. 最も分岐条件が多い稟議(多くは設備投資かシステム導入)を選び、現行の様式と経路を書き出す
  2. 申請フォームを設定画面だけで作り切れるか試す(項目の必須/条件表示・金額の自動計算まで)
  3. 承認経路を組み、金額を境界値(規程の50万円・500万円ちょうど)で入力して振り分け先を確認する
  4. 承認者を不在にして期限を超過させ、エスカレーションが動くかを見る
  5. 差し戻しと添付の差し替えを行い、履歴が承認記録と紐づいて残るかを確認する

この5点を3製品で回すと、機能一覧では同じに見えた製品の差が出ます。差が集中するのは3と5、つまり設定画面の表現力と履歴の残り方です。

選定で起きる失敗3パターン:紙の1対1移植・組織図完全連動・単独導入

1つ目は、紙の様式を1対1でそのまま画面に移すパターンです。申請書が200種類になり、改訂依頼が総務に集中し、担当者の異動後は誰も直せなくなります。棚卸しと統合を先に済ませれば回避できます。2つ目は、承認経路を組織図に完全連動させるパターンで、人事異動のたびに購買の承認が管掌外の部長へ飛ぶ事故が起きました。

3つ目は、稟議システムだけを単独で導入するパターンです。承認は速くなったのに、承認後の発注データを基幹へ手入力する運用が残り、経理側の作業量が変わりません。連携方式を比較軸に入れずに選ぶと、導入効果が承認時間の短縮だけに留まりました。

比較しても候補が残らない稟議の3条件と、受託開発に切り替える境界

ここまでの手順で候補が絞れない企業は一定数あります。製品の調べ方が足りないのではなく、パッケージの設計思想と自社の稟議が構造的に合っていないケースです。判断を先延ばしにせず、境界を条件で示します。

パッケージで足りる稟議の条件と、製品比較を続けるべき判断範囲

パッケージで足りる稟議には共通点があります。判断材料が申請書の中で完結している、経路の分岐条件が3種類以内、基幹連携は承認後の結果連携だけで足りる——この3つを満たすなら、比較検討を続けて製品を選ぶのが妥当です。ここで開発に踏み込むのは過剰で、年額数十万円から百万円台で足りる領域に初期費用数百万円以上を投じる判断は投資回収の説明が立ちません。

受託開発に切り替える3条件:基幹連動・業界固有の承認体系・外部組織承認

逆に、次の3条件のいずれかに当てはまる場合は、パッケージ比較を打ち切って開発の見積りを取ったほうが早く決着します。

1つ目は、稟議の判断が基幹システムのデータと連動している場合です。与信枠の残高で承認可否が変わる、在庫と原価を参照して発注量の妥当性を判断する、予算残高を超える申請は経路が変わる——こうした要件は申請時点で基幹の値を読み、その値で分岐させます。パッケージの外部参照機能で組めない範囲に入ると、カスタマイズ費用が積み上がりました。

2つ目は、業界固有の承認体系を持つ場合です。建設業の実行予算の変更承認、医療機関の症例に紐づく承認、金融の与信稟議のように、承認単位が汎用の「申請書」ではなく業界固有の管理単位であるなら、汎用パッケージの項目定義では表現しきれません。

3つ目は、社外組織の承認を経路に含む場合です。親会社の決裁、施主・元請の承認、共同事業体の合議を同じ経路上で扱うなら、社外ユーザーの権限管理と開示範囲の制御が必要になります。社外分までユーザー課金される製品では、費用と権限設計の両方で無理が出ました。

いずれかに当てはまるなら、稟議を独立したシステムとして買うのではなく、基幹や業務システムの一部として設計する判断になります。要件の切り出しから設計・開発までを外部に相談するなら、ワークフローシステム開発のように承認フロー設計と基幹連携を含めて対応できる開発会社を候補にすると、要件定義の段階から連携方式を詰められます。

受託開発を選ばない方がよい場面と、その場合に採るべき代替手段

開発を選ばない場面もはっきりしています。決裁権限規程が未整備、あるいは規程と実務が乖離した状態での開発は要件が固まらないまま作ることになり、稼働後に経路の作り直しが発生しました。まず規程を整え、暫定的に安価なクラウド製品で電子化して運用実態を可視化してから開発の判断に戻るほうが早く済みます。

稟議件数が月10件程度に留まる場合も同じで、承認1件あたりの短縮時間を積み上げても開発投資の回収に届きません。逆に稟議以外の業務システムも同時に見直す計画があるなら、その全体の中でワークフロー部分を設計したほうが投資効率が上がります。

よくある質問

稟議システムの比較・選定で受ける質問のうち、判断に直結するものを5つ取り上げます。

稟議システムのおすすめはどの製品ですか?

製品単体で「おすすめ」は決まりません。統合後の申請書が30種類以上で分岐条件3種類以上なら稟議・ワークフロー特化型、10種類未満で経路が一本道ならグループウェア一体型、対象が購買・経費に集中しているならバックオフィス一体型が候補です。自社をどれかに当てはめ、そのタイプの製品3つに絞って比較するのが最短です。

稟議システムの市場シェアはどこで確認できますか?

比較サイトの「シェア」表示は、多くがサイト内のレビュー件数構成比や資料請求数であり、売上シェアや導入社数ではありません(ITトレンドは自ら注記しています)。市場規模はITRが2023年7月18日に発表した国内ワークフロー市場の推移が一次データとして使えます。製品別の売上シェア実数は、有償の調査レポートを購入しない限り一般公開されていません。

稟議システムとワークフローシステムは何が違いますか?

ワークフローシステムが申請・承認業務全般(勤怠・経費・稟議・各種届出)を対象とする総称で、稟議システムはそのうち起案から決裁までに用途を絞った呼び方です。同じ製品が両方の名称で紹介される例が多く、比較では名称ではなく機能で見ます。範囲の違いは稟議システムとは?機能・仕組みと紙・メール稟議の課題から見る導入判断の基準で扱っています。

稟議システムの費用は何で変わりますか?

変動要因は課金対象の定義と初期の移行工数の2つです。登録ユーザー数に単価を掛ける方式では申請者となる全社員が課金対象に入るため、申請専用の安価な区分があるかどうかで年額が数倍変わります。料金表に自社の想定人数を入れて比較してください。移行支援が初期費用に含まれるかも確認項目です。

無料プランや無料トライアルだけで稟議システムを運用できますか?

無料プランでの本番運用は、ユーザー数や申請書数の上限、監査ログの保存期間で制約を受けます。内部統制の対象となる稟議では、経路設定の変更履歴が残らない構成は避けたほうがよいでしょう。無料トライアルは検証に使い、最も複雑な稟議1本を通して経路の表現力と履歴の残り方を確認する用途が向いています。

関連記事

資料請求

RELATED POSTS 関連記事