PleasanterとAgileWorksを統合するか併用するか｜オンプレからクラウドへ移行する際の判断軸

PleasanterとAgileWorksを別々のオンプレミス環境で運用していると、サーバー管理、製品保守、権限設定、障害対応がすべて二重になります。利用部門から見ても、申請はAgileWorks、承認後の管理はPleasanter、というように同じ業務で複数システムを触る場面があります。

サーバー更新と保守費用の見直しのタイミングで、Pleasanterへ統合する案、AgileWorksへ統合する案、別のクラウド製品へ移行する案、2製品をクラウド化して併用する案、オンプレミスを継続する案を比較しました。まだ検討中の項目もありますが、結論に至るまでの判断プロセス自体に実務的な価値があると思うので、そこを書いていきます。

2製品の見直しを始めた背景

PleasanterとAgileWorksを併用すれば、それぞれの得意分野を生かせます。その代わり、製品ごとにサーバー、ミドルウェア、ライセンス、バックアップ、監視、保守契約が要ります。開発方法も設定方法も違うので、担当者は両方の知識を維持しなければなりません。

組織変更や人事異動のたびに、複数製品の利用者情報と権限を確認する作業も発生します。データ連携が自動化されていなければ、承認後のデータを別の台帳へ手入力する運用も残ります。

見直したかったのは、単純に製品数を減らすことではありません。サーバー運用、利用者管理、開発、問い合わせ、障害対応を含めた全体の負荷です。ただ、統合すると一方の製品でできていたことを失う可能性があるので、統合ありきでは進めませんでした。

最初に製品ごとの役割を整理した

比較を始めるとき、製品名や料金表を見る前に、現在の業務で何をやっているかを整理しました。Pleasanterでは、業務台帳、マスタ管理、一覧検索、集計、Excel出力、簡易的な承認を行っています。

AgileWorksでは、稟議や各種申請、複数段階の承認、合議、差し戻し、組織情報に連動した回付を使っています。同じ「申請管理」という言葉でも、単純な上長承認と複雑な条件分岐では、必要な機能がまったく違います。

この整理で見えたのは、単純な台帳業務と複雑な承認業務を同じ基準で統合しようとすると無理が出る、ということでした。

2製品を併用することで発生している課題

併用環境では、開発方法、権限管理、操作説明、障害調査の対象が分散します。Pleasanterの変更に詳しい担当者が、AgileWorksの承認設定も同じように対応できるとは限りません。担当者が少なければ、特定の人に知識が集中します。

利用者からの問い合わせでも、「どちらのシステムで処理するのか」「承認後の情報はどこで確認するのか」を説明することになります。操作マニュアルや教育資料も製品ごとに作ります。

AgileWorksで承認された内容をPleasanterへ登録する場合は、API、CSV、バッチ、手入力のいずれかで連携します。連携障害が起きると、AgileWorks、Pleasanter、ネットワーク、連携プログラムのどこに原因があるのかを切り分けることになります。

実際にAgileWorks側で障害が起きたときの調査記録として、ジョブマネージャーがGC overhead limit exceededで停止した件とアップロードが完了しなかった件があります。どちらも製品固有の事情を知らないと切り分けに時間がかかりました。

既存業務と資産を棚卸しした

統合可否を判断するために、現在稼働している業務、利用者数、データ量、外部連携、帳票、独自開発を一覧化しました。画面数だけでは移行の難易度を判断できません。利用頻度が低くても、監査や過去履歴の確認に要る機能があります。

• 業務名、目的、主管部署、利用者数
• 月間件数、年間件数、繁忙期
• 承認段階、合議、差し戻し、代理承認
• サーバースクリプト、API、CSV、SQL連携
• 帳票、Excel出力、通知メール
• 添付ファイル、操作履歴、保存期間
• 継続必須、統合可能、廃止候補の区分

意識したのは、「現在存在する機能」と「今後も必要な機能」を分けることです。長期間使われていない画面や、別の業務と重複している台帳まで移行すると、費用と運用負荷が膨らみます。

比較対象を統合案だけに限定しなかった

検討では、Pleasanterへ統合する案、AgileWorksへ統合する案だけでなく、別クラウド製品への移行、2製品のクラウド併用、オンプレミスの継続も並べました。統合を前提にすると、業務要件に合わない案でも無理に評価を進めてしまうからです。

Pleasanterへ統合する場合は、複雑な承認経路、合議、組織変更時の回付をどう再現するかが課題になります。AgileWorksへ統合する場合は、柔軟な台帳、検索、集計、マスタ管理をどう実現するかを確認します。

別クラウド製品へ移行する場合は、インフラ保守を減らせる可能性がある一方で、両製品の既存資産を新しい方式で作り直すことになります。クラウドで2製品を併用する場合は、サーバー保守は減っても、製品管理とデータ連携は残ります。

判断軸を機能だけにしなかった

比較表には、機能の有無だけでなく、運用、移行、セキュリティ、費用、障害影響も入れました。製品に承認機能があっても、今使っている条件分岐や代理承認を再現できなければ、業務適合性は低いままです。

「対応可能」という評価も、標準機能なのか、設定で対応できるのか、追加開発が必要なのかで分けました。追加開発へ依存すると、将来のバージョンアップや保守費用に響きます。

承認機能の再現性については、実際にPleasanter側で組んでみた記録があります。多段階承認を設計して分かったことで、どこまで作れてどこを運用に寄せたかを書きました。

オンプレとクラウドの費用範囲をそろえた

オンプレミスとクラウドを比べるとき、ライセンス料金だけを見ると判断を誤ります。オンプレミスでは、サーバー、OS、ミドルウェア、バックアップ、監視、保守契約、更新作業、障害対応の工数が乗ってきます。

クラウドでは、初期導入費、月額または年額料金、利用者追加、ストレージ、データ移行、追加開発、外部連携、サポートオプション。利用者数やデータ量が増えたときの料金も確認します。

初年度の費用だけでなく、3年から5年程度の総費用で比較しました。移行期間には新旧システムの並行稼働が発生し、一時的に二重費用になります。旧環境の保守終了時期や履歴保管も費用へ含めます。

クラウド化して減る作業と残る作業を分けた

クラウド化すれば、ハードウェア障害、OS更新、バックアップ設備、サーバー監視あたりの作業は減らせます。一方で、利用者管理、権限設計、問い合わせ、業務変更、データ品質管理は残ります。

それから、サービスの仕様変更やメンテナンス情報を確認して、利用部門へ周知する作業が新しく増えます。クラウド事業者が基盤を管理していても、誤った権限設定や不要なアカウントの放置は自社側の問題です。

だから「クラウドにすれば運用がなくなる」とは考えず、減らせるインフラ作業と、継続する業務運用を分けて工数を見積もりました。

データ移行と既存連携を重点的に確認した

移行では、画面や項目だけでなく、過去データ、添付ファイル、承認履歴、通知、外部連携をどこまで引き継ぐかを決めます。すべての履歴を新環境へ移すと費用が増えますし、旧環境に残すなら参照方法と保管期間を決めておきます。

メールやマニュアルに現行URLが書かれている場合は、移行後にリンク変更が発生します。外部システムが直接画面やAPIを呼んでいる場合は、連携先の改修も要ります。

• 既存フォームと承認経路を再現できるか
• 添付ファイルと操作履歴を移行するか
• 過去データをどこで参照するか
• API、CSV、バッチを再開発するか
• 並行稼働中の二重入力をどう防ぐか
• 旧システムを停止する条件

セキュリティと権限管理を比較した

セキュリティでは、認証方式、多要素認証、シングルサインオン、IPアドレス制限、操作ログ、バックアップ、データ保管場所を確認しました。機能が存在するかどうかだけでなく、契約するプランで使えるかまで見ます。

権限は、サイト、画面、項目、レコード単位でどこまで制御できるかを比較します。部署、役職、プロジェクトなど複数条件で閲覧範囲を分けているなら、実際の業務例を使って検証します。

クラウドサービスでは、事業者と利用企業の責任範囲も確認します。基盤のセキュリティをサービス側が担当していても、利用者への過剰な権限付与やアカウント管理は自社の責任として残ります。

統合によって増えるリスクも評価した

製品を一つに統合すれば管理対象は減りますが、障害時の影響範囲は広がります。台帳と申請を同じ製品へ集約すると、その製品が停止したときに複数の業務が同時に使えなくなります。

特定製品への依存も強まるので、料金改定や仕様変更の影響を受けやすくなります。追加開発を増やしすぎると標準機能との差が大きくなり、将来のバージョンアップや再移行が難しくなります。

移行期間中は、現行環境の保守と新環境の構築が並行するので、一時的に担当者の負荷が増えます。統合後の削減効果だけでなく、移行中の作業量や利用者教育も評価に入れました。

比較表には点数だけでなく判断理由を残した

この表では、確認できていない内容を無理に点数化せず、「要見積もり」「要検証」のまま残しました。各評価には判断理由、前提条件、確認先も書いています。

必須要件を満たさない案は、料金が安くても採用できません。法令、監査、承認統制などを必須条件として先に判定し、そのあとで費用や使いやすさを比較する。この順番のほうが判断は早くなります。

現時点での考え方

今のところは、すべての業務を一度に一製品へ統合するより、業務ごとに適した製品を判断するほうが現実的だと考えています。単純な台帳や申請は統合候補にして、複雑な承認や既存連携が多い業務は慎重に検証します。

最初から最終構成を決めず、代表的な業務を選んで試作し、操作性、移行難易度、運用負荷を確認する方法もあります。検討中の項目を無理に結論へ変えず、何が未確認なのかを残しておく。ここが後で効いてきます。

まとめ

PleasanterとAgileWorksの統合では、製品機能だけでなく、既存業務、データ、外部連携、運用体制、障害影響まで含めて比較します。統合を目的にせず、現状維持、併用、クラウド化、別製品への移行を並列で評価する。ここが最初の分かれ目でした。

オンプレミスとクラウドの費用は、ライセンス料金だけでなく、サーバー保守、バックアップ、移行、追加開発、運用工数を同じ範囲で比べます。クラウド化しても利用者管理や権限設計は残ります。

結論が検討中でも、業務棚卸し、判断軸、未確認事項を整理しておく価値はあります。すべてを一度に移行せず、業務ごとに段階的に検証していく方法も含めて判断していくつもりです。