【サービス比較】稟議システムのリプレース検討をした話【2026年版】

「今の稟議システム、高くないか？」——そんな一言から始まるシステム移行プロジェクトは、情シスとして何度か経験してきた。コストが明らかに割高なら動くのは当然だ。

ただ、稟議システムの移行は思ったより沼だ。ある会社で実際にプロジェクトを動かしてみて、ツール選定に入る前に決めておくべきことがいくつかあると痛感した。この記事ではその話を書く。

▼ なぜ乗り換えを検討することになったか

きっかけはシンプルなコスト問題だった。現行ツールの費用をあらためて試算したところ、移行候補のツールと比べて約2.5倍のコスト差があることが判明した。機能的に大きな差がないなら、移行を検討しない理由がない。

加えて、支払いと稟議の紐付けが現状では管理しにくい構造になっていた。「この稟議に対してどの支払いが紐づいているか」を追いかけるのに手間がかかっていたので、それを改善したいという目的もあった。

「これは決まりかな」という雰囲気が漂い始めたところで、話は複雑になっていった。

▼ 動いたら想定外の壁にぶつかった

移行候補のツールを本格検討し始めたタイミングで、外貨（USD）での購買申請に対応していないことが判明した。海外拠点との取引があり、USD建ての発注申請が発生するケースでは、そのツールを使うことができない。

「JP国内の取引だけ対象にすればいい」という考え方もあるが、そうなると海外拠点は別ツールを使うことになる。2システム運用になれば、ライセンスコストの二重負担・承認者のUX低下・IT管理コストの増加という問題が発生する。

「コスト削減のために移行する」はずが、要件を詰めていくと「グローバルツールと2ツールのどちらが最適か」という上流の議論に戻ることになった。

これは外貨対応という特殊な話ではなく、「ツール選定の前に決めるべき設計を後回しにした」ことで起きた話だ。

▼ 教訓：ツール選定前に決めるべき3つの設計

稟議システムの移行で詰まるパターンのほとんどは、ツール選定に入る前の設計が曖昧なまま進んでしまうことにある。具体的には以下の3つだ。

① スコープ設計（横軸）：誰まで使わせるか

稟議システムを「誰に使わせるか」は、2つの軸で考える必要がある。

このスコープが曖昧なままツール選定に入ると、後から「このレイヤーまでアカウントが必要だった」「海外拠点が使えない仕様だった」という問題が出てくる。

② 申請タイプ設計（縦軸）：何の申請を載せるか

「稟議システム」という言葉でひとくくりにされがちだが、実態は申請の種類によって要件がかなり異なる。

「稟議だけ移行するつもりが、気づいたら汎用ワークフローも含めて全部見直しになった」というのはよくある話だ。最初に何を載せて何を載せないかを決めておくことで、ツールの要件が絞れる。

③ ライセンス設計：申請者・承認者・閲覧者は別物

これが一番見落とされがちな論点だ。

「全社員にアカウントを付与する」という運用をしている会社は多いが、本当に全員がアカウントを必要としているか、立ち止まって考えてほしい。

ライセンス数の設計次第で、月額コストは大きく変わる。「全員アカウント」が本当に必要かどうかは、移行前に一度ゼロベースで見直す価値がある。

▼ 職務権限が先、システムは後——これは絶対に守る

稟議システムの移行を進めていると、必ずどこかで「このツールだとこの承認フローが組めない」という場面に出くわす。そのときに「ツールに合わせて承認フローを変えればいい」という発想になる人が出てくる。これは本末転倒だ。

稟議・承認フローは会社のガバナンスそのものだ。「誰が何を承認できるか」は、会社の意思決定構造を定義している。それをツールの都合で変えてしまうと、内部統制が崩れる。

正しい順番はこうだ。

稟議システムの移行は「今より安いツールに乗り換える」作業ではなく、会社のガバナンス設計を見直す機会だ。その認識を持って進めないと、移行後に「あの申請フローはどこに行った？」という話になる。

▼ まとめ：稟議システム移行前チェックリスト

稟議システムの移行を検討しているなら、ツール選定に入る前に以下を確認してほしい。

コスト削減を目的に動き始めたプロジェクトでも、この設計を後回しにすると必ず途中で詰まる。ツール選定は、設計が固まってから始めるものだ。

▼ 主要5サービス比較：どれを選ぶべきか

設計が固まったところで、ようやくツール選定に入れる。現時点で検討に上がりやすい5サービスの特徴を整理した。料金は公開情報をもとにした目安値であり、実際の契約条件は各社への問い合わせで確認してほしい。