ServiceNowとJira Service Managementの比較

この記事では、ITSM・ワークフローツールとしてのServiceNowとJira Service Management（旧Jira Service Desk）を比較します。この記事は、特定の製品を推奨するものではなく、皆さんの組織の状況や要望に応じて、より適切な製品を選ぶ手助けをすることを目的としています。また、この記事で使用する比較軸は、他の製品を含めた比較する際にも参考になると思います。

できる限り公平な視点を心がけていますが、筆者の知識がServiceNowに偏っているため、一定のバイアスがかかっている可能性があることをご理解ください。また、本記事は2024年7月時点の情報に基づいており、将来的に変化する可能性があることにも留意してください。

各製品の概要
製品の比較
その他の参考になるデータソース
1. 導入事例
2. 他者による比較資料
おわりに

各製品の概要

ServiceNowは、ServiceNow社が提供する製品で、『ServiceNowのシステムアーキテクチャの全体像』で詳述しているように、NowPlatformと呼ばれるアプリ開発基盤(aPaaS)の上に、IT Service ManagementやIT Operation Managementなどの業務アプリケーション(SaaS)が構築されています。ServiceNowは、これらの幅広い製品群全体を指します。

Jira Service Managementは、Atlassian社が提供するITサービス管理およびワークフローソリューションです。

Atlassianは、プロジェクト管理ツールのJira Softwareや社内WikiのConfluenceなどを独立したブランドとして提供しています。一方、ServiceNowは、社名と同じ名前で単一ブランドのクラウドサービスを提供しており、その中に様々な製品が含まれています。

競合するポイント

Jira Service Managementが競合するServiceNowの機能としては、ITサービス管理（IT Service Management）やNowPlatformにおけるワークフロー機能、データベース機能が挙げられます。

そのため、本記事では「ServiceNow」と言った場合、ITサービス管理、ワークフロー、データベース機能の部分のみを指すこととします。

2製品に共通する特徴

ServiceNowとJira Service Managementの共通する特徴は以下の通りです。これらの特長をすべて備えている製品は、単なる「チケット管理ツール」や「ワークフローシステム」ではほとんど見られません。そのため、多くの業務プロセスをシステムに組み込むためのソリューションを検討する場合、ServiceNowとJira Service Managementが最終候補になる可能性が高いです。

柔軟なワークフロー機能: 承認フローの柔軟性に加え、ワークフロー内でのタスクチケットの生成やデータベースへの読み書きが可能。また、様々な問い合わせや申請に利用するための申請画面の作成が可能

タスク管理・ダッシュボード機能: 問い合わせや依頼の状況を可視化し、必要なKPIをトラッキングするためのレポート・ダッシュボード機能が存在

データベース機能: 業務プロセスにおいて発生する様々な業務データを保持でき、細かな権限制御機能も備えたデータベース機能を持つ

外部システムとの連携機能: 他製品と連携して業務プロセスを自動化するための外部システムとの連携機能

製品の比較

筆者の独断で選んだ比較観点におけるそれぞれの製品の特長を説明します。

ライセンス体系・課金体系

ライセンス体系・課金体系はどちらの製品も類似しており、問い合わせや申請を行うユーザはライセンス不要（無償）で、対応を行うユーザに対して課金されるモデルになっています。

（なお、『ServiceNowのライセンス体系の基本』で紹介しているように、ServiceNowには様々なライセンス体系が存在しますが、本記事ではRequester/Fulfillerモデルと呼ばれる最も一般的な購入方法を前提として説明します）

ServiceNow

ServiceNowは次の3種類の役割によって必要なライセンスが決定されます。

役割	説明	必要ライセンス
Requester	問い合わせや申請を行うユーザ。一般従業員。	ライセンス不要（無償）
Business Stakeholder	申請に対して承認を行ったり、システムの各種データを閲覧するユーザ。管理職。	Business Stakeholderライセンス（有償）が必要
Fulfiller	問い合わせや申請の対応を行うユーザ。IT部門など、コーポレート部門のユーザ。	Fulfillerライセンス（有償）が必要

ServiceNowにおけるライセンス体系（Requester/Fulfillerモデルの場合）

Jira Service Management

Jira Service Managementも同様に3種類の役割によって必要なライセンスが決定されます。少し定義が異なります。

役割	説明	ライセンス
Customer	問い合わせや申請を行うユーザ。一般従業員。	ライセンス不要（無償）
Agent	Customerからの問い合わせや依頼に対応するユーザ。必要に応じてCollaboratorと協力して対応を行う。IT部門など、コーポレート部門のユーザ。	Jira Service Management（有償）のライセンスが必要
Collaborator	Agentからの依頼を受けて問い合わせや依頼の対応に協力する。開発部門などのユーザ。	Jira Softwareなどのライセンス（有償）が必要

Jira Service Managementにおけるライセンス体系

ライセンス体系の違い

主な違いは以下の通りです。

ワークフローで承認を行うユーザは、ServiceNowではBusiness Stakeholder（課金対象）になるが、Jira Service ManagementではCustomer（非課金対象）になる
Jira Service ManagementにおけるCollaboratorは、Jira Softwareなどのライセンスが必要で、既にJira Softwareライセンスを持っているユーザに関しては追加の費用は不要
ServiceNowのRequesterは他のユーザの申請を閲覧するのに制限がある（Watch listという機能を用いてby nameで追加した他のユーザのみ閲覧可能）
Jira Service ManagementのCollaboratorはCustomerの問い合わせに直接回答ができない（Customerからの問い合わせや依頼に直接対応できるのはAgentだけ）

重要なのは、実現したいことが無償のRequesterまたはCustomerで可能なのか、有償のライセンスが必要なのかをしっかり見極めることです。例えば、ワークフローの承認者は、Jira Service Managementでは無償ですが、ServiceNowでは有償です。また、Jira Softwareのライセンスを持っているユーザでも、問い合わせや依頼に直接コメントしたい場合は、Jira Service Managementの追加ライセンスが必要です。

外部システムとの連携に関するライセンス体系

外部システムとの連携に関するライセンス体系について、各製品の概要を補足します。他の製品と連携してワークフローを自動化する場合は、注意が必要です。

ServiceNow

Inbound連携: 外部システムからServiceNowのAPIを呼び出す場合（Inboundの連携）には課金はありません
Outbound連携: 外部システムのAPIを呼び出す場合は、Integration Hubと呼ばれる外部システムとの連携用ライセンスを別途購入する必要がありますこのライセンスは、トランザクション数に応じて課金されます
プログラムによる連携: 外部システムのAPIをIntegration Hubではなく、Rest Messageというプログラミングを必要とする機能を用いて実現する場合、課金されません

Jira Service Management

自動化機能: 外部システムとの連携に関しては、連携に対して課金というよりは、口述する自動化機能の実行数により課金されます。自動化機能の実行回数は購入ライセンス数に応じて付与され、別途購入は不要です
連携アプリ: 外部システムとの連携用のアプリ（プラグインのようなもの）を用いる場合、アプリごとに別の課金体系が適用されます（ほとんどの場合アプリは本体のライセンスよりも安価です）。

コスト

コストについては、一般的にJira Service Managementの方が優位（安価）です。ただし、ライセンス体系の違いや、要件による違い、そして各社が提示するディスカウントレートによる影響も考慮する必要がありますので、一概には言えない点にご注意ください。

無料トライアル

ServiceNowでは個人開発者インスタンス（PDI）という、登録さえすれば誰でも、無料で開発・検証用環境を受け取ることができます。
下記の記事で詳しく解説していますので、あわせてご覧ください。

一方Jira Service Managementでは、こちらから無料トライアルが可能とのことです。実際に、筆者はGmailアカウントで申し込むことができ、すぐにJira Service Managementが使えるようになりました。

ITSM機能の充足性

ITSM機能については、両製品とも非常に強力であり、類似点が多く見受けられます。互いにベンチマークしつつ不足機能を補完していると思われるため、ほとんど差異はないと考えてよいでしょう。

GartnerによるIT Service Managementの比較を見ても、本記事執筆時点では同じレーティングになっています。

なお、筆者にて各機能の詳細まで触れているわけではないので、細かい要件がある場合は、もちろん各製品でそれが満たせるかを確認してください。

フォーム画面の柔軟性

フォーム画面の柔軟性については、どちらの製品も多くの入力形式に対応しており、操作性の高いフォームを実現することができます。しかし、以下の点で違いがあります。

レイアウトの柔軟性ならJira Service Management

Jira Service Managementでは、Form（フォーム）機能によって、Confluenceのページのように非常に柔軟なレイアウトを実現できます。一方で、ServiceNowのフォーム画面はレイアウトの自由度はあまり高くありません。

機能の柔軟性ならServiceNow

ServiceNowのフォーム画面では、以下のような細かい設定や制御が可能です。

動的に行数を増やせる表形式の入力項目（いわゆる「明細」を受け付けるためのUI）
過去の申請を参照して選択する入力項目
ユーザの属性や既に入力された別の項目に基づいて他の項目の表示・非表示を制御
ある項目の値の入力応じて別の項目の値を自動入力

一方で、Jira Service Managementのフォーム画面は、動的な制御はあまり得意ではありません。

ワークフロー機能

どちらの製品もGUIでパーツを配置していく簡単なUIでワークフローを作成できます。以下で説明するように、機能の概念が異なりますが、単純な承認フローとしてのワークフローであればJira Service Managementで十分です。一方、承認だけでなく、特定のワークフロー中で発生するタスク管理や外部システムとの連携などを含む一連の業務プロセスをシステムとして組み込む場合は、ServiceNowの機能に優位性があります。

Jira Service Managementのワークフロー機能

Jira Service Managementには、ワークフローを実現するための機能として、Workflow（ワークフロー）とAutomation（自動化）の2つの機能が存在します。

Workflow（ワークフロー）　…　問い合わせや依頼のステータス遷移（例：マネージャ承認 → 部長承認）を制御するための機能。どのボタンが押されるとどのステータスに遷移するかや、承認を取得するステータスで誰に承認依頼を行うかを設定します。
Automation（自動化）　…　特定の条件を満たした際に自動処理を実行するための機能。承認が完了した際に問い合わせや依頼に自動でコメントをする、特定の項目の値を更新する、データベースを自動更新する、外部システムと連携するといったことが可能です。

例えば「アカウント申請」というワークフローを作成し、申請者のマネージャの承認が得られたらAPIを用いて特定のシステムにアカウントを自動で作成する場合、次のように実現します。

(Workflow) アカウント申請のステータス遷移をワークフロー機能で作る
(Automation) 承認完了ステータスになったことをトリガとして、外部システムへのアカウント作成及びデータベースの更新ロジックを自動化機能で作る

そのため、「ワークフロー」を「承認フロー」とほぼ同じ意味で考えている場合は、Jira Service Managementで必要十分な機能があると言えるでしょう。

しかし、複雑な一連の業務プロセスをワークフローとして組み込む場合、Jira Service Managementはあまり得意ではありません。例えば、同様の「アカウント申請」で、マネージャ承認後にIT部門のユーザにアカウント手動作成のタスクを割り当て、タスク完了後に申請者に通知する場合、次のように実現します。

(Workflow) アカウント申請のステータス遷移をワークフロー機能で作成。
(Automation) 承認完了ステータスをトリガとして、IT部門向けにアカウント作成のJiraタスクを起票するAutomationを作成。
(Automation) Jiraタスクがクローズされたことをトリガとして、申請者にアカウント作成完了通知を行うAutomationを作成。

2.,3.の部分がポイントで、Automation機能では「条件を待つ」といった高度な制御ができないため、複雑なワークフローを組み込む場合、多くのAutomationを組み合わせなくてはなりません。

ServiceNowのワークフロー機能

ServiceNowは、Flow Designerという機能を使ってワークフローを作成します（以前はWorkflow Editorという機能もありましたが、現在はほとんど使用されていません）。

Flow Designerは、Jira Service ManagementのWorkflow（ワークフロー）とAutomation（自動化）を一つにまとめたような機能です。さらに、「条件を待つ」ことや、他の多くのシステムとの連携がパーツを配置するだけで簡単に組み込むことができます。

Flow Designerはより高い柔軟性を提供するため、複雑な一連の業務プロセスをシステムで組み込みたい場合には、とても魅力的です。

外部システムとの連携機能

どちらも多くの外部システムとInboud・Outboundいずれでも連携することができます。標準で用意されているコネクターの数ではServiceNowが、Atlassian社の他製品との親和性ではJira Service Managementが優れています。

ServiceNowの外部システム連携機能

ServiceNowは、グローバル標準のSaaSを中心とした数多くのサービスと、GUI上にパーツを配置するだけでシステム連携を構築できる非常に優れた外部システム連携機能を有しています。

製品ドキュメント | ServiceNow

さらに、ServiceNowは外部システムからのアクセスを可能にする豊富なInbound APIを提供しており、外部システム起点のシステム連携にも強みを持っています。追加のWebhook URLを作成し、任意の動作をするエンドポイントを構築することも可能です。

とはいえ、いくつか弱点も存在します。まず、ノーコードでシステム連携を行うためにはIntegration Hubというライセンスを、ユーザごとのライセンスとは別で購入する必要があり、結構高いです。また、日本製品との標準コネクタはあまり提供されていないため、日系ツールとの連携を行う場合、3rdパーティ製のプラグインや日系SaaSに強いIntegration PaaS（iPaaS）を組み合わせる必要があります。

Jira Service Managementの外部連携機能

Jira Service Managementでは、標準でノーコードで簡単に連携できるシステムはあまりなく、多くの場合、3rdパーティーベンダが作成したアプリをインストールする必要があります。これにより、連携機能がプラグイン内に閉じ、既存の自動化機能との組み合わせが難しい場合や、アップデートや障害対応が3rdパーティベンダに依存するというデメリットがあります。

とはいえ、Jira Service Managementも次のような外部システムと連携するための必要十分な機能は有しています。

標準でREST APIをコールするためのステップがAutomation（自動化）に組み込まれているため、リクエストの作成やレスポンスのハンドリングを自分で行えば、Web APIを公開しているほぼすべてのシステムと連携が可能
（上記デメリットはあるものの）3rdパーティベンダのシステム連携アプリが豊富で、要件に合うアプリがあれば、大抵は低コストで利用可能
Webhookトリガで自動化を作成することで、Inboundのシステム連携にも対応可能

Atlassian製品との親和性

Jira Service Managementは、Atlassian社の他製品であるJira SoftwareやConfluenceとの親和性が非常に高いです。既にAtlassian製品を利用している企業にとっては、この点は大きなメリットとなります。

Jira Softwareとの親和性: Jiraタスクで仕事をする文化が根付いている場合、ワークフローで発生するタスクをJiraタスクとして生成できるのは大きな魅力だと思います
Confluenceとの親和性: 問い合わせや依頼を起票する画面において、自動で関連するConfluenceページを検索して「この記事を見たら解決できるのでは？」という提案をしてくれます。また、Confluenceページ内にJira Service Managementの問い合わせや申請フォームを埋め込むことができ、ナレッジの検索から問い合わせや申請の起票をシームレスに行えます。

データベース機能

両製品ともに業務データを管理するためのデータベース機能を備えていますが、ServiceNowに若干の優位性があります。

ServiceNowのデータベース機能

ServiceNowは内部のデータベースに直接に近い形で操作を行うことができます。具体的には、標準のテーブルへのフィールド追加、新たなテーブルの追加、ビューの作成、トリガーの作成など（に相当する操作）が可能です。また、ACLという機能を用いて非常にきめ細かい権限制御ができます。

Jira Service Managementのデータベース機能

Jira Service Managementでは、Asset（資産）という名前でデータベースにあたる機能を提供しています。元々はAsset、つまりPCやサーバなどのITサービス管理における「資産」を管理する機能であるためか、ServiceNowの生に近いデータベース機能と比べると、下記の点で不足があります。

キャパシティ　…　Atlassianの公式ページ「アセットに保存できるデータ量」に記載があるように、2024年7月時点では環境全体で100万件までのデータの制限があります。大規模な組織で多くの業務データを格納する場合には少し不足がありますが、件数は今後拡張される可能性があります。
権限制御　…　テーブル（スキーマ）単位やレコード単位の権限制御は可能ですが、フィールド単位での条件に応じた権限制御はできません。例えば、「従業員データベース」を作成した場合、住所や報酬などの機密情報が、ITヘルプデスクの対応を行うユーザにも見えてしまう可能性があります。この点はスキーマの工夫や、何らかのアプリを探して対応する必要がありそうです。

開発管理機能・変更容易性

意外と見落としがちな観点が開発管理機能です。特にワークフロー機能を積極的に活用する場合、新しい申請を追加したり、修正したりすることが頻繁に発生すると予想されるため、設定の追加や改修を安全に素早くできるか、という観点を見ておきましょう。この点については、ServiceNowに優位性があります。

資源移送機能

SAPやSalesforceなどと同様に、ServiceNowには開発環境で作成した開発物（資源）を本番環境に移送（移行）する機能が存在します。この機能により、開発と本番環境の同期を容易に行うことができます。一方、Jira Service Managementにはこの機能がなく、検証環境でテストを行った後、手動で同じ設定を本番環境に反映する必要があります。