Close
製品ガイド & チュートリアル

Jira Service Management Data Center 向けアセットをご利用いただくにあたり、知っておく必要があるあらゆる情報です。

Jira が表示されたモニターへと歩いていく人々のイラスト

Jira Service Management Data Center 向けアセットを開始する

このガイドは、Jira Service Management Data Center 向けアセットの設定を開始するすべてのユーザーを対象としています。アセットを使用すれば、資産、構成アイテム、リソースを追跡してアプリ、サービス、基礎となるインフラストラクチャ、その他の重要な資産間の重要な関係を可視化できます。アセットは Jira に構築されており、チームは資産と構成アイテムをサービス リクエスト、インシデント、問題、変更、その他の課題に簡単に素早く結び付けられ、有用なコンテキストを取得できます。


ステップ 1 - インストール

Jira Service Management Data Center 4.15 以降を使用している場合は、ファイルのダウンロード時にアセット機能が既に組み込まれています。

Jira Service Management Data Center 4.14 以前を使用している場合は、無料のアセット アプリをインストールする必要があります。

  1. Jira 管理者グローバルを持つユーザーとして Jira Service Management にログインします。
  2. 管理ドロップダウンをクリックして、[アプリの管理] を選択します。
  3. ページの左側にある [新しいアプリの検索] をクリックし、「アセット」を検索します。
  4. 結果に適切なアプリのバージョンが表示されます。
  5. 画面の指示に従って、アプリをインストールします。
  6. MyAtlassian へのログインを促すメッセージが表示されて、アセットのダウンロードが開始されます。

ステップ 2 - Assets の構造を理解する

このセクションでは、Assets データベースの構造について概要を説明します。

オブジェクト

オブジェクトは、実際のアセット/構成項目です。これらはあなたの Jira 課題にリンクできるため、課題が発生するたびに、すぐに課題にコンテキストが追加されます。

また、オブジェクト参照を使用して相互にリンクして、オブジェクトが互いにどのように依存するかを示すこともできます。

オブジェクト スキーマ

オブジェクト スキーマは、実際の構成管理データベース (CMDB) です。このデータベースには、オブジェクト タイプ (以下を参照) とオブジェクトが含まれます。アセットでは複数のオブジェクト スキーマを作成できます。これは、さまざまな理由で役立ちます。

  • データをより小さなチャンクに分割すると、データを監査し、正確な状態に保ちやすくなります。
  • 機密データがある場合 (例: 従業員情報) を使用した場合、アクセス許可が制限された 1 つのオブジェクト スキーマにすべてのデータをまとめやすくなります。

Assets にデータを配置する方法を決定する際は、データを論理オブジェクト スキーマにグループ化できるように、データの用途と更新対象者を考慮します。

アセット (およびその延長で Jira Service Management) は、どの情報がどのオブジェクト スキーマに含まれているかを考慮しません。1 つの大きなデータ プールを確認するだけです。つまり、1 つのユース ケースで複数のオブジェクト スキーマを簡単に使用でき、異なるオブジェクト スキーマのオブジェクト間にリンクを作成できるということです。

オブジェクト タイプ

オブジェクト タイプはスキーマ内にあり、スキーマに含まれるオブジェクトを定義します。これは、自分で定義することも、オブジェクト スキーマ テンプレートを使用することもできます。このテンプレートには、カスタマイズできる特定のオブジェクト タイプが事前に入力されています。オブジェクト タイプは実際のオブジェクトのコンテナーとして機能します。アセットは非常にオープンで柔軟であるため、オブジェクト タイプは希望に合わせて定義でき、一般的なオブジェクト タイプは次のとおりです。

  • ビジネス サービス
  • ホスト
  • ラップトップ
  • ソフトウェア

しかし、IT セットである必要はありません。たとえば、多くの人々は次のようなその他の有用な情報を追加します。

  • ベンダー
  • 場所
  • 従業員
  • ビジネス上の優先順位

階層ツリー内のオブジェクト タイプは、理にかなった方法で整理できます。このツリーは主にナビゲーションと読みやすさのためのもので、これを助けるために空のオブジェクト タイプを持つこともできますが、オブジェクト タイプを簡単に作成できるように属性の継承を提供するように設定できます。

Insight CMDB ナビゲーション ペインには、たとえば、IT アセットからハードウェア、サーバーに至るオブジェクトの階層が表示されます。

オブジェクト タイプ属性

オブジェクト属性は、オブジェクト タイプを定義するものです。各オブジェクト タイプには、独自の属性セットがあります。たとえば、オブジェクト タイプ「ラップトップ」には、モデル、シリアル番号、ユーザー、保証の有効期限などの属性があります。

属性に実際の値を入力すると、オブジェクトが定義されます。これは手動または自動で行うことができます (手順 4 を参照)。

すべてのオブジェクト タイプには、次の 4 つの必須属性があります。

  • 名前
  • キー
  • 作成日
  • 最終更新日

最後の 3 つは自動的に設定されます。その他のすべての属性は、管理者が定義できます。また、一意のキー属性があるため、各オブジェクトの名前は一意である必要はありません。

データベース オブジェクトのさまざまな属性を示す Insight 属性ページには、DB タイプ、ステータス、ホスト先などが含まれます。

属性は、テキスト、日付、数字、URL (情報またはサービス契約の他のストアにリンクするのに最適)、Jira ユーザー (オブジェクトの所有権の設定に最適)、ステータス (在庫あり、割り当て済み、廃止済みなど)、およびその他のオブジェクト (詳細については次のセクションを参照してください) など、さまざまなデータ タイプで構成できます。

オブジェクト参照

特に呼び出すオブジェクト属性は、「オブジェクト」の属性タイプです。これにより、他のオブジェクトへの参照が作成され、オブジェクト間の依存関係のマップの作成が開始されます。

たとえば、所在地が独自のオブジェクト タイプである場合、各ロケーション オブジェクトをビジネスのオフィスの所在地の 1 つにすることができます。これにより、たとえば「ストックホルム」を選択することで、すべてのラップトップの所在地をすばやく設定できます。

コンピュータ オブジェクトの Insight オブジェクト作成画面。場所、モデル、製造、OS などのコンピュータの属性を入力します。

オブジェクト参照は、手動で設定する必要はありません。ネットワーク スキャナー、インポーター、自動化ルールなどから自動的に追加できます。これらの詳細については、手順 4 を参照してください。

オブジェクト間の参照には、主に次の 2 つの利点があります。

大きな利点 - オブジェクト間の依存関係をマッピングできます。たとえば、ビジネス サービスを、依存するさまざまなホスト、オペレーティング システム、およびファイルにマッピングできます。このマップは、下流での変更における影響への理解 (この OS を変更した場合、何に影響があるのか?)およびインシデントと問題の原因の把握に非常に便利な場合があります。また、各オブジェクトを Jira の問題にリンクできるため、インフラストラクチャやその他のビジネス資産の包括的な履歴を継続的に構築します。それは、課題や問題の解決に役立ちます。

小さな利点 - より管理しやすくなります。オフィスがモントリオールからトロントに移動する場合、モントリオールをトロントに変更する各ラップトップを経由するのではなく、オブジェクト「モントリオール」を更新するだけで済みます。

オブジェクト参照には、次の 2 つのタイプがあります。

  1. アウトバウンド参照は、現在のオブジェクトから他のオブジェクトへの参照です。
  2. インバウンド参照は、現在のオブジェクトを参照する他のオブジェクトです。

オブジェクト間の参照は、グラフィカル ビューワーを使用して表示できます。あなたが持っている参照タイプ (例: インストール先、所有者、ベンダー) を決定し、オブジェクト スキーマ設定でこれらを色分けすることができます。

オブジェクト「Jira Service Management」の Insight グラフィカル ビューアー ウィンドウ。それがあるホスト、OS、必要な異なる Jira バージョン、ライセンスなどの依存関係を表示します。

Assets の権限

アセットには 3 種類の権限があります。

  • グローバル権限 - グローバル設定では、アセットの管理権限を持つユーザーを指定できます。「アセット管理者」ロールに割り当てられたユーザーは、アセット内のすべてのアクションを実行できます。
  • オブジェクト スキーマのアクセス許可 -オブジェクト スキーマ設定では、特定のオブジェクト スキーマの管理者権限を持つユーザー、オブジェクト スキーマデータを更新できるユーザー、およびデータを表示できるユーザーを定義できます。
  • オブジェクト タイプ権限 - Jira Service Management 顧客には、オブジェクト スキーマ内の特定の情報のみを表示できるようにしたいが、オブジェクト スキーマ全体内のすべてのデータを閲覧できるアクセス権を付与したくない場合があります。その場合では、オブジェクト タイプ権限を使用できます。

ステップ3 - 含めるデータを選択する

追跡すべき情報は企業ごとに異なるため、Assets のインスタンスはすべて独自のものになります。Assets には、自分と自分の業務に役立つあらゆる情報を保存できます。

含める必要がある資産または構成アイテムは、目的に応じて異なります。在庫管理のためのアセット インスタンスは、変更やインシデントの解決をより迅速に行うためのビジネス サービスおよびその依存関係をマッピングするために使用されるインスタンスと大きく異なります。

どのデータを含めるべきかを決定するためのアドバイスは次のとおりです。

問題を定義する

ほとんどのツールは問題の解決を目的に実装されており、Assets も例外ではありません。たとえば、インシデント解決速度が期待したほど速くない、またはサービスの依存関係が確認しにくいためサービスの変更によって予期しない結果が生じた、などです。

問題を見つけ、それを使用して、関与させる人からデータベースに含めるアセットと情報に至るまであらゆるものを定義できます。問題を確認し、問題を克服するためにスタッフが必要な追加情報を把握します。この情報によって、オブジェクト タイプが定義されます。

一度に多くの情報を追加しすぎると正確性をチェックするのが難しくなるため、一度に 1 つの問題に焦点を当てましょう。最初の問題が解決した後、他の問題を解決するためにアセットを拡張できます。

サービスから始める

構成管理を使用する場合は、解決しようとしている問題に関連するサービスから始めることをお勧めします。サービスは明確に定義されており、運営において依存するさまざまなアセットを追加したり、それらのアセットが依存するアセットを追加したりするのは比較的簡単です。最終的に、関連する各サービスとその依存関係の全体像を構築します。

必要な詳細度を決める必要があります。サービスを理解するために必要な詳細度を現実的に考えてください。特定のラックとケーブルのマッピングは詳細すぎる場合もあれば、必要な場合もあります。

また、すべてのサービスを一度に実行する必要はありません。ビジネス クリティカルなサービス、またはダウンタイムが最も多いサービスから始めることができます。

サービスを開始すると、まずアセット/構成項目の定義セットが与えられます。その後、新しい問題が発生したときに、必要に応じて他のアセットを追加できます。インフラストラクチャとアセット全体よりも、小さなデータのチャンクの正確性を簡単に確認できるため、CMDB を少しずつ構築するのが最善です。

オブジェクト スキーマ テンプレートの使用

アセットには、IT 資産と構成管理、人事、および顧客関係管理のためのオブジェクト スキーマ テンプレートが付属しています。

これらのテンプレートはニーズに合わせて変更できますが、アセットに保存することが多いオブジェクトのタイプの出発点として適しています。オブジェクト タイプのリストを下に移動して、使用しないものを削除します。

オブジェクト スキーマは、空のスキーマ、IT アセット スキーマ、HR スキーマ、および CRM スキーマのオプションでフォームを作成します。

ヒントとコツ

絶対に必要なものについて考える

何を達成しようとしているのか、そのために必要な情報について慎重に考えてください。各オブジェクトとその属性は役に立ちます。

チームや関係者と一緒に座って、各属性を消費する人とものを確認する必要があります。誰も使用しないものは削除します。またいつでも後で追加できます!

サーバーの正確な所在地を知る必要が本当にありますか?また、オペレーティング システムのメーカーを知る必要がありますか?おそらくあなたはそれを知っているでしょうし、それ自体は全く問題ありません。しかし、そのデータに基づいて決定やクエリを行うつもりがない場合、それらのデータは不要です!

データを追加しすぎると、次のような問題があります。

  • オブジェクトと属性が多いほど、それを正確に保つために必要な作業が増えます。
  • 未使用のデータが多いと貴重なデータを把握しにくくなり、極端な場合にはパフォーマンスを低下させることさえあります。
  • データは削除するよりも、後で追加する方が簡単です。そのため、何か欠けていることがわかった場合は、「念のため」データのロードから始めるのではなく、後で追加してください。データの削除が好きな人はいません。

将来の保守性を考える

アセットでのデータの保守方法を検討してください。オブジェクトの属性はどれくらい頻繁に変更され、アセットで最新の状態に保つのはどれくらい簡単ですか?

オブジェクトの特定の詳細が頻繁に変化するが、ほとんど使用されない場合は、アセットからそれを削除し、実際に必要になったときに調べる方が理にかなっています。ときどき使用されるがあまり変化がないものについては、アクセスしやすいように含めておくと良いでしょう。

ラップトップ ソフトウェアを例に取り上げます。必要に応じて、スキャン エージェント、ソフトウェア要求の課題、自動化ルールを使用して、ラップトップにインストールされているすべてのソフトウェアを含めるようにアセットを更新できます。オープン インストール ポリシーがある場合は、比較的早く変更されます。スキャン パターンが新しいソフトウェアを取得できない可能性があるため、精度が少し落ちる場合があります。代わりに、使用方法の理解に特に関心のある重要なソフトウェアを確認する方が良いかもしれません。

厳格なインストール ポリシーがあり、ラップトップのセットアップ時とサービス デスクの要求によってのみソフトウェアがインストールされる場合は、変更速度が遅く、追跡が容易であるため、すべてをアセットに保存することが理にかなっています。

物理的な項目にとらわれない

アセットでは必要なオブジェクトを定義できるため、従来の資産にも物理的な資産にも限定されません。たとえば、ビジネス サービスは物理的な資産ではありませんが、多くの場合、詳細に理解することが非常に重要です。サービスの物理的/非物理的な依存関係をすべてリンクできるため、ビジネス サービス オブジェクトを見ればサービスがどのように実行されるかを完全に理解できます。

好きなだけ抽象化できます。アセット ユーザーが作成する一般的な例には、ビジネス上重要なオブジェクト、環境タイプ、部門/チーム、所在地などがあります。

現実世界のその他の例として、ビジネス サービスの分類が挙げられます。すべてのビジネス サービスがオブジェクト タイプ「ビジネス サービス」としてアセットに追加されているとします。これらのビジネス サービスを「金融」、「物流」、「販売」、「インフラ」などに分類する必要があるとします。これは、ビジネス サービス オブジェクト タイプの属性によって行うか、これらのカテゴリを「サービス カテゴリ」と呼ばれる独自のオブジェクト タイプにすることができます。

独自のオブジェクト タイプである「金融」と「ガバナンス」のタグ付きの「サービス カテゴリ」をハイライトした SAP ビジネス アプリケーション オブジェクトのビュー。

この利点は、ビジネス サービスのカテゴリに固有の詳細 (属性) を追加できることです。すべての金融ビジネス サービスを担当する人がいるかもしれません。メンテナンスが困難になるので、その人をすべての財務「ビジネス サービス」オブジェクトに直接追加する必要はありません。「サービス カテゴリ」オブジェクト タイプの「財務」オブジェクトに一度追加すれば、それを一括で更新でき、データを繰り返す必要はなくなります。

また、個々の財務ビジネス サービスの運用ステータスを取得し、財務カテゴリの全体的なステータスにロールアップするルールを設定することもできます。これで、カテゴリ オブジェクトを表示して、各サービスのカテゴリにサービス問題があるかどうかをすばやく確認できます。

これらのタイプのオブジェクトを Assets に追加する必要はありませんが、従来のアセット/設定項目に限定されないことを知っておくことが重要です。すべては、あなたの目的次第です。そのため、目標およびその目標の達成に必要な情報を理解することが重要です。

先を見て徐々に成長する

将来的に実行したい拡張を覚えておいてください。それは、含めるべきデータだけでなく、データの構造も決まります。

それを念頭に置いておくのは良いことですが、アセットは段階的に構築することをお勧めします。数千のオブジェクトに対して 100% 正確なデータを使用して 1 つの巨大なリリースを行うのは非常に難しいことです。小さい規模から始め、新しい属性、オブジェクト、およびオブジェクト スキーマを追加する方がはるかに簡単です。

問題を見つけ、それを修正するために Assets を構築し、次の問題に移行し、進捗に合わせて Assets を拡張することをお勧めします。

精度に対する現実的な期待値を設定する

常に 100% の精度を維持するのが理想ですが、実際には難しいかもしれません。しかし、それで問題ありません。データが何もない場合よりもあった方が高いビジネス価値を得られさえすれば、その精度で十分なのです。多くの CMDB プロジェクトは、稼働前に「完璧」にしようとするあまり遅れたり、さらには失敗したりする場合があります。


ステップ 4 - データを Assets に取り込む

すべてを手動で入力すると、大規模な組織では大仕事になる可能性があります。そのため、データの入力をサポートするいくつかのツールがあります。

Assets Discovery Network Scanner

Assets Discovery は、Marketplace から無料でご利用いただけます。

Assets Discovery は、ネットワーク アセットを取得するエージェントレス スキャナーです (ただし、より詳細な情報を取得できるエージェントもあります)。Assets オブジェクト スキーマに取り込むアセットと属性を選択したり、独自のスキャン パターンを作成してよりニッチなアセットを検索したりできます。スケジュールに従って実行すると、変更が取得され、データが最新の状態に保たれます。自動化ルールを使用すると、検出された変更に基づいて Jira 課題や電子メール通知などをトリガーすることもできます。

インポート

アセット インポートを使用して、他のソースからデータを取り込めます。これらのインポート ルールは、スケジュールに従って同期できるため、必要に応じてデータを更新できます。インポート タイプごとに、アセットでのデータの保存場所とインポート先を定義する必要があります。

CSV インポート

すべてのアセットを含む Excel または Sheets などのスプレッドシートを使用している場合は、CSV インポートを使用して Assets にデータを取り込むことができます。これにより、アセットを課題にリンクし、影響を分析できる、統合された透明性の高いシステムを実現できます。

データベース インポート

データベース インポートを使用して、内部システムまたはサードパーティ システムからデータをインポートできます。サポートされているデータベースには、Oracle、MySQL、Microsoft SQL Server、PostgreSQL などがあります。

Jira ユーザー インポート

多くの場合、アセットのユーザーは Jira ユーザーを所有する資産にリンクします。そのためには、Jira ユーザーまたは特定のユーザー グループをアセットにインポートする必要があります。これは、Jira ユーザー インポートで行えます。

LDAP インポート

承認プロセスに使用されるアセットまたは従業員とマネージャーの関係を含む社内ディレクトリを扱っていますか?作業を簡単にするため、アセットには一般的な LDAP ディレクトリで動作してディレクトリから構造とアセットを取得できるモジュールが用意されています。

JSON インポート

インポートするデータを保持する JSON ファイルを使用して、オブジェクトを Assets にインポートできます。

統合

統合は、クラウド サービス、アセット マネージャー、その他の CMDB などの他のツールに接続するために使用できます。

これらすべてのツールを用意していますが、ツールを非推奨にする予定がない限り、すべてのデータをアセットに取り込むことはお勧めしません。Jira Service Management で使用する必要があるものだけ取り込んでください。後からいつでも追加は可能です。

すべての統合は、Marketplace から無料でインストールできます。

アセット統合の一覧は次のとおりです。

アセット - Confluence 統合もあります。この統合により、資産を文書化するための Confluence ページを作成できます。アセットにデータを取り込むのではなく、データを送信します。

ヒントとコツ

Assets Discovery、インポーター、および統合の実行頻度をバランスよく把握する必要があります。頻度が低すぎると、アセットが古くなります。頻度が高すぎると、処理しているオブジェクトの数によっては、多くのリソースを消費する可能性があります。1 時間ごとに統合を実行するユーザーもいれば、週に 1 回、またはオンデマンドで実行するユーザーもいます。

負荷が軽い時間には、できるだけ頻繁に同期することをお勧めします。データの変更頻度、およびそのデータの重要性を確認して、実行するためにスケジュールする必要がある頻度を決定します。データの変化の速さに遅れないようにしましょう。

Assets Discovery を使用してさまざまなスキャン パターンを異なる頻度で実行することで、アセットを可能な限り最新の状態に保つために必要なリソースを削減できます。


ステップ 5 - データの構造化方法を決定する

データを論理オブジェクト スキーマに分割する

すべてのデータを、1 つの巨大なオブジェクト スキーマに入れる必要はありません。データの使用またはデータの所有者に基づいて複数のオブジェクト スキーマを持つことをお勧めします。

アセットと Jira は、どのオブジェクト スキーマにどのデータが含まれているかを考慮しません。管理者は、そのデータに含まれるスキーマに関係なく、必要なデータでアセット カスタム フィールドを指すだけです。また、カスタム フィールドは、1 つの Jira 課題からデータを複数のオブジェクト スキーマにプルおよびプッシュできます。あるオブジェクト スキーマのオブジェクト間のリンクは、別のオブジェクト スキーマ内のオブジェクトを使用して作成でき、クエリは異なるスキーマ間で実行できます。オブジェクト スキーマは基本的には、アセットそのもののためではなく、私たちの生活を楽にするためのツールです。

データを異なるオブジェクト スキーマに分けることによって、ユーザー フレンドリーになり、保守がより簡単になります。Assets の情報を必要とする財務部門や人事部門などのチームは、不要な情報に翻弄される必要はありません。また、チームに 1 つの大きいオブジェクト スキーマの特定の部分のみをチェックするように依頼するよりも、1 つのオブジェクト スキーマで定期的にデータ品質のチェックを行うように依頼する方が簡単です。

データをフェデレーションする

完全に利用可能なデータベースまたは情報ソースがどこかに存在して、それを更新し続けるためのプロセスがすでにある場合、 Assets にデータを移動する必要はありません。代わりに、統合によって関連するデータのコピーを作成して、それらの統合をスケジュールに従って実行して、Assets 情報を更新する方がよいでしょう。

アセットには、多数のインポーターと統合が付属しています (上記参照)。これらのインポーターと統合により、意思決定に必要な情報を Jira 課題/アセット自体で利用できますが、2 つの別々のコピーを保守するわけではありません。

これの非常に一般的な例として、LDAP インポーターを使用してアセットを Active Directory と同期しているユーザーが挙げられます。これで、すべての Windows ユーザーが簡単にアクセスできるようになり、同期を定期的に実行して最新の状態に保てます。

場合によっては、このインポートされたデータに対して個別のオブジェクト スキーマを作成することもあれば、より大きなオブジェクト スキーマに統合する場合もあります。データが複数の用途に使用される場合 (例: IT サポートと人事)、それを IT オブジェクト スキーマに直接結びつけ、HR にそのスキーマへのアクセス権を付与するのではなく、別のオブジェクト スキーマとして持つ方が理にかなっています。

統合では、利用可能なすべてのデータをアセットに取り込むことはお勧めしません。統合を設定するときに、オブジェクト スキーマに何を取り込み、何を取り込まないかを決定できます。また、この変更を元のデータ ソースにプッシュしない限り、アセット内でこのデータを更新しないでください。更新すると、データの競合が発生します。

事前構築済みの統合が利用できない場合は、他にもいくつかのオプションがあります。1 つ目は、データを CSV/JSON ファイルとして定期的にエクスポートし、アセット CSV/JSON インポーターでスケジュールに従ってデータを取り込むことです。または、オブジェクトを作成し、そのオブジェクトに詳細情報がある他のデータベースにリンクする URL 属性を付与することもできます。このオプションは、エージェントが情報を表示できるようにして、その情報に基づいて検索またはレポートを作成しない場合に適しています。

同じ属性をどこでも再利用することは避ける

属性が多くの場所で使用され、同じ繰り返し値を持つことが多い場合は、それを独自のオブジェクト タイプにする方が理にかなっています。ベンダーが良い例です。たとえば、オブジェクト タイプ「ラップトップ」と「電話」に「ベンダー」という属性を使用して、各オブジェクトにベンダー名を入力 (またはインポート) できます。

これは問題ありませんが、多くの理由により、「ベンダー」というオブジェクト タイプを使用して、各ベンダーをオブジェクトとして設定する方が効率的です。

  1. ベンダー名以外の情報も必要になる場合があります。サポート連絡先番号や契約へのリンクなど、ベンダーに関連するその他の情報が必要な場合があります。すべてのラップトップとすべての電話にこれを繰り返す必要はありません。一度入力して、ベンダー オブジェクトにリンクするだけで十分です。これは、Jira Service Management 内でベンダー管理の要素を実行する場合にも役立ちます。
  2. ベンダーはこのように標準化されるため、レポートの実行が容易になります。ベンダーごとのサポート リクエストの数について報告する場合は、誰かが Micrsoft または Aple をどこかに書いたため、何も見逃していないと確信できます。
  3. ベンダーを何らかの方法でリブランドまたは変更する必要がある場合は、1 か所で更新するだけで済みます。

ベンダーは一例に過ぎず、ビジネス上の重要性、デプロイ環境、部門、場所などが含まれます。


ステップ 6 - Jira 課題に Assets カスタム フィールドを設定する

このセクションでは、アセット オブジェクトとリンクするように Jira 課題を設定する方法について説明します。影響を受けるビジネス サービスをインシデント課題にリンクする、ハードウェア リクエスト課題にコンピュータを追加する、影響を受ける可能性のあるホストのセットを変更リクエスト課題に追加する、といった方法があります。

アセットでは、新しい特定のカスタム フィールドを利用できます。これらのカスタム フィールドは、特定のオブジェクト セットを指すように設定する必要があります。

アセット フィールドはロックダウンして、顧客が利用可能なリストから選択するか、空白のままにすることができます。または、開いたままにしておいて、Jira 課題を記入するすべてのユーザーがフォームから直接アセットに新しいオブジェクトを追加できます。

主に最初のオプションを使用することをお勧めしますが、2 つ目のオプションが適したユース ケースもあります。例として、新しい従業員のオンボーディングが挙げられます。従業員をアセットに保存する場合は、採用マネージャーにアセット カスタム フィールドを開いている状態でオンボーディング Jira リクエストを入力させることができます。これにより、バックグラウンドで新しいアセットに従業員オブジェクトが自動的に作成されます。これにより、時間と管理者の作業が軽減されます。


ステップ 7 - 自動化をセットアップする

このセクションでは、アセットで反復的なタスクを自動化するための 2 つのオプションについて説明します。

アセットの自動化

アセットの自動化は、各オブジェクト スキーマに固有です。一般的な例:

  • スキーマ内のアセット オブジェクトによる特定のトリガーや変更に基づいて通知を送信する - 例: ライセンスまたは保証の有効期限が切れたときにメールを送信する、またはサービスが停止した場合に Jira 課題を作成する。
  • アセット データを整理し、標準化された状態に保ち、レポートとクエリを行いやすくする。
ライセンスの有効期限が切れる場合に Jira 課題を作成する Insight 自動化ルール。

自動化ルールは、オブジェクト情報の更新、課題の作成、メールの送信、HTTP リクエストの作成、Groovy スクリプトの実行などを行うことができます。

自動化ルールの作成方法はこちらをご覧ください。

事後操作

アセットでは新しい事後操作も導入しています。自動化ルールと同様に、事後操作を使用するとアクションの実行を自動化できます。

違いは、Jira ワークフロー (課題の移行) によって課題ステータスが変更されたときにアクションが実行されることです。これらのアクションには、アセットの更新、通知の送信、スクリプトの実行などがあります。

たとえば、従業員のオンボーディングを要求する課題が作成されると、それぞれにアセット オブジェクトのリンクが必要なラップトップ、携帯電話、携帯電話サブスクリプションなど、新しいユーザーに必要なアセットを割り当てるためにタスクを作成できます。

ヒントとコツ

課題テキスト フィールドを使用してアセットでデータの入力や更新を行う場合、またはアセットにオブジェクトを手動で入力する場合は、データが少し煩雑になる場合があります。このような場合は、自動化を使用してください。

サーバー名はその好例です。通常、サーバー名は標準化されており、誤入力しやすいかもしれません。タイプ サーバーのオブジェクトが作成または更新されたときにトリガーする自動化ルールを作成して、名前が命名規則を満たしていることを確認し、エラーが発生した場合にフラグを立てることができます。


ステップ 8 - データを正確に保つ方法を決定する

データを最新の状態に保つことは重要です。そうしないと、チームは誤った前提の下で作業し、インシデントの解決が遅れたり、サービス リクエスト後に間違った結果になる可能性があります。

アセットでデータを最新の状態に保つ方法は数多くありますが、その多くは自動化を活用して大量の作業を行います。

  1. データの定期的な監査を実行します。
    Assets 自動化ルールは、スケジュールに従ってデータ監査を実行するようにユーザーに通知するように設定できます。これにより、重要なアセットを最新の状態に保つために、迅速なサニティー チェックを行うリマインダーが提供されます。
  2. Assets Discovery、および関連するインポーターと統合を定期的に同期します。
    データが古くなる大きな原因は、アセットを外部データ ソースと頻繁に同期していないことです。外部ソースにあるデータの変更頻度、Jira Service Management で使用される頻度を考慮して、バランスよく同期しましょう。頻繁に変更されて定期的に課題にリンクされる場合は、24 時間ごとに同期する必要があります。一方、数週間または数か月も待つことができる統合もあります。
  3. 自動化ルールを使用します。
    資産/構成データを変更する決定が Jira 課題で行われた際は、アセットでそれをキャプチャすることが重要です。たとえば、ユーザーのラップトップが壊れたので新しいラップトップを提供するとエージェントが決定した場合は、以下の情報をアセットでキャプチャする必要があります。
  • 新しいラップトップは、所有者をリクエスタに更新し、ステータスを「サービス中」に更新する必要があります。
  • 古いラップトップは、所有者を削除し、ステータスを「異常あり」に更新する必要があります。

エージェントによってこれがリクエスターに伝達されたとき、トランジション画面と Assets 事後操作でこのタイプの情報をキャプチャして、自動化によって新しいステータスと所有者を Assets に設定できます。

これはあくまで一例であり、Assets を Jira ワークフローに組み込む際には、課題からどの情報を Assets に戻す必要があるかを考慮してください。Assets の手動更新は忘れやすいため、必要な頻度はできるだけ少なくするのが理想です。


ステップ 9 - レポートを設定する

レポートは、あなたとあなたの会社、そしてあなたがアセットで解決しようとしている問題に特化したものです。アセットには、資産と構成データの理解に役立つ事前設定されたレポートが多数付属しています。アセット オブジェクト、関連する課題、プロジェクト、およびそれらに費やされた時間についてレポートできます。

Insight レポートの設定ウィンドウには、ビジネス上の重要性が最も高いオブジェクトに関連する変更またはインシデントの数が表示されます。

たとえば、重要なビジネス サービスで発生した変更とインシデントの数や、サービス リクエストに費やされた時間と関連するアセットの種類に関するパターンがあるかどうかを把握できます。レポートを使用して、リンクされたインシデント数が最も多い重要なビジネス サービスを確認し、改善の優先順位を決める場所を把握できます。


その他のトピック

Assets Query Language - AQL

Assets Query Language (AQL) は、アセットのクエリに使用される言語です。AQL は、検索ビュー、自動化ルール、アセット間の高度な参照を作成したり、インポートを指示したりするのに便利です。

ラベルと QR コード

ラベルと QR コードを使用すると、有形資産の管理を本当に合理化できます。これを実現できるように、アセットでは任意のオブジェクトのラベルや QR コードを印刷する機能が備わっています。