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

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

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

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

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

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

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

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

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

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

この整理により、単純な台帳業務と複雑な承認業務を同じ基準で統合しようとすると、無理が生じることが分かりました。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

オンプレミスとクラウドを比較する際、ライセンス料金だけを見ると正しい判断ができません。オンプレミスでは、サーバー、OS、ミドルウェア、バックアップ、監視、保守契約、更新作業、障害対応の工数が発生します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

製品を一つに統合すると管理対象を減らせますが、障害時の影響範囲が広がります。台帳と申請を同じ製品へ集約した場合、その製品が停止すると複数の業務が同時に利用できなくなる可能性があります。

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

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

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

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

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

現時点での考え方

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

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

まとめ

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

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

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