Close

ウェビナー開催: AI、自動化、バーチャルエージェントで ITSM を加速 登録はこちら >

Assets オンボーディング ガイド

概要

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


Assets は、以前は Insight と呼ばれていました。現在はコンテンツ ライブラリの更新中です。そのため、一部の地域では Insight という用語が引き続き表示される場合があります。このトランジションによる技術的な能力や機能の変更はありません。

ステップ 1 - Assets にアクセスする

Jira Service Management Premium または Enterprise のライセンス版、トライアル版に関わらず、トップ メニューから Assets を選択してアクセスできます。

Jira Service Management Premium または Enterprise のトップ メニューから Assets にアクセスする

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

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

オブジェクトが中央、オブジェクト タイプがその上、オブジェクト スキーマが最も上のレベルにある図

オブジェクト

オブジェクトとは、ノート PC、サーバー、機器の一部、契約、または車両など、特異的で一意なあらゆるものです。オブジェクトは、実際のアセット/構成アイテム (CI) です。

オブジェクトは実際の Jira 課題にリンクできるため、課題が発生するたびに、すぐにその課題にコンテキストが追加されます。また、オブジェクト参照によって相互にリンクして、オブジェクトが互いにどのように依存するかを表示できます。

オブジェクト タイプ

類似するオブジェクトはオブジェクト タイプにグループ化されます。オブジェクト タイプは実際のオブジェクトのコンテナーとして機能します。オブジェクト タイプはスキーマ内にあり、スキーマに含まれるオブジェクトを定義します。これは、自分で定義することも、オブジェクト スキーマ テンプレートを使用することもできます。このテンプレートには、カスタマイズできる特定のオブジェクト タイプが事前に入力されています。一般的なオブジェクト タイプには次のものがあります。

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

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

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

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

オブジェクト タイプを階層ツリーで整理する

オブジェクト スキーマ

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

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

Assets にデータを配置する方法を決定する際は、データを論理オブジェクト スキーマにグループ化できるように、データの用途と更新対象者を考慮します。1 つのユース ケースで複数のオブジェクト スキーマを簡単に使用でき、異なるオブジェクト スキーマのオブジェクト間にリンクを作成できます。

テンプレートは、IT 資産管理、人材、施設などの主要なユースケースにも使用できます。これらのテンプレートには、ニーズに応じたさまざまな関連オブジェクト タイプが含まれており、効果的なデータベースを生成する際に有利なスタートを切ることができ、オブジェクトをインポートするための初期構造も提供されています。テンプレートの詳細についてはこちらをご覧ください。

Assets は Jira Service Management 内のサービス機能と自動で同期して、Assets データベース内に読み取り専用オブジェクト スキーマを作成します。このスキーマは、サービス レジストリ内にドキュメント化されたサービスごとに入力されたオブジェクトで構成されます。つまり、Jira Service Management のサービスをさまざまなアセットや CI にリンクしてサービス マップを構築し、変更、インシデント、問題をサポートできます。

オブジェクト属性

オブジェクトの説明、そのモデル番号、関連する別のオブジェクト、またはオブジェクトの所有者として割り当てられたユーザーなど、属性とはそのオブジェクトに関連付けられた情報の特定の部分を示します。

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

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

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

  1. 名前
  2. キー
  3. 作成日
  4. 最終更新日

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

Jira Service Management でオブジェクト タイプ属性を設定する

オブジェクト参照

参照は、Assets にある 2 つの異なるオブジェクト間の接続です。各オブジェクトは、直接的ではなく他のオブジェクトへの参照を含む属性を介して、他の多数のオブジェクトに接続できます。

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

Jira Service Management にあるオブジェクト参照のスクリーンショットの例

オブジェクト参照に手動の設定は不要です。ネットワーク スキャナー、インポーター、自動化ルールなどから自動で追加できます。

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

  1. オブジェクト間の依存関係をマッピングできます。たとえば、ITSM アプリケーションをビジネス サービスや依存するさまざまなホスト、オペレーティング システム、ファイルにマッピングできます。下流の変更がもたらす影響の理解 (この OS を変更すると何に影響があるのか?)、インシデントと問題の原因の把握に、このマップは非常に便利な場合があります。また、各オブジェクトを Jira 課題にリンクできるため、インフラストラクチャやその他のビジネス アセットの包括的な履歴を継続的に構築します。これは、課題や問題の解決により役立ちます。
  2. 簡単に管理できます。たとえば、オフィスがモントリオールからトロントに移動する場合は、モントリオールをトロントに変更する各ノート PC を経由するのではなく、オブジェクト「モントリオール」を更新するだけです。

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

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

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

オブジェクト グラフにあるオブジェクト間の参照を表示する

Assets の権限

Assets には 2 種類の権限があります。

  • オブジェクト スキーマ権限 - オブジェクト スキーマ設定では、特定のオブジェクト スキーマの管理者権限を持つユーザー、オブジェクト スキーマ データを更新できるユーザー、データを表示できるユーザーを定義できます。
  • オブジェクト タイプ権限 - Jira Service Management の顧客にはオブジェクト スキーマにある特定の情報のみを表示できるようにしたいが、オブジェクト スキーマ全体内のすべてのデータを閲覧できるアクセス権は付与したくない場合があります。その場合は、オブジェクト タイプ権限を使用できます。

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

追跡すべき情報は企業ごとに異なるため、Assets のインスタンスはすべて独自のものになります。Assets には、自分と自分の業務に役立つあらゆる情報を保存できます。含める必要があるアセットまたは構成アイテムは、目的に応じて異なります。このセクションでは、含めるべきデータを決定するためのアドバイスを提供します。

問題を定義する

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

問題を見つけてアドバイスを参考にし、関与させる人からデータベースに含めるアセットと情報に至るまでのすべてを定義します。問題を確認して、解決するために必要となる追加情報を把握します。この情報によってオブジェクト タイプが定義されます。

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

サービスを開始する

構成管理に Assets を使用する予定がある場合は、サービスを開始してトップダウンのアプローチを採用することをお勧めします。次に、それらのサービスが依存する対象 (例: アプリケーションとホスト) をマッピングします。その後、それらの依存関係が依存する対象などをマッピングします。これによって、インシデントや変更リクエストが発生したときに使用できるサービス マップを素早く構築できます。必要に応じて他の領域の文書化に拡大できます。

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

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

好きなだけ抽象化できます。一般的な例としては、ビジネスで重要なオブジェクト、環境タイプ、部門/チーム、所在地などがあります。

例: ビジネス サービスの分類

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

オブジェクト タイプの分類の例としての「ビジネス サービス」

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

また、個々の財務ビジネス サービスの運用ステータスを取得して、財務カテゴリの全体的なステータスに導入するルールを設定できます。この方法ではカテゴリ オブジェクトを表示することで、各サービスのカテゴリにサービス問題があるかどうかを素早く確認できます。

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

先を見て徐々に成長する

今後追加するといい拡張機能を覚えておきましょう。これによって含めるデータだけでなく、データの構造も決まります。

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

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

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

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


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

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

Assets Discovery

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

インポート

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

CSV インポート

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

JSON インポート

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

ヒントとコツ

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

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


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

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

データの使用またはデータの所有者に基づいて複数のオブジェクト スキーマを持つことをお勧めします。

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

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

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

Assets には多数のインポーターが付属しています (前のセクションを参照)。これらのインポーターを使用すると、意思決定に必要な情報が Jira 課題とAssets 自体で利用できるようになりますが、2 つのコピーを保守するわけではありません。

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

インポーターを利用できない場合は、オブジェクトを作成して詳細がある他のデータベースにリンクする URL 属性を付与できます。このオプションは、エージェントが情報を表示できるようにして、その情報に基づいて検索またはレポートを作成しない場合に適しています。

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

属性が多くの場所で使用されて同じ繰り返し値を持つことが多い場合は、その属性を独自のオブジェクト タイプにする方が合理的です。たとえば、オブジェクト タイプの「ノート PC」、「電話」、「プリンター」、「モニター」などにベンダーという属性を使用できます。また、オブジェクトごとに、その特定のノート PC や電話のベンダー名を入力 (またはインポート) する必要があります。

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

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

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


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

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

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


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

Assets では、オブジェクト関連の自動化トリガーとアクションの新しいセットが導入され、さまざまなタスクの自動化に利用できるようになりました。

次のような例があります。

  • サービス リクエストのワークフロー中にノート PC の所有者またはステータスを更新する
  • インシデントの課題が発生した際に、インフラストラクチャの一部のステータスを「インシデントが進行中」に更新する
  • 添付されたオブジェクトに基づいて Jira 課題を特定のスタッフに自動ルーティングする
  • ライセンス、契約、または保証の有効期限が切れる時期を重要な関係者に通知する

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

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

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

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

たとえば、ユーザーのラップトップが壊れたので新しいラップトップを提供するとエージェントが決定した場合は、以下の情報をアセットでキャプチャする必要があります。

  • 新しいノート PC では、所有者をリクエスターに更新してステータスを「サービス中」に更新する必要があります。
  • 古いノート PC では、所有者を削除してステータスを「異常あり」に更新する必要があります。

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

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


ステップ 9 - 改善を示す指標を追跡する

アセットをセット・アップしたら、すぐに使えるレポートを使って価値を証明できます。これにより、アセットおよび構成データを厳密に分析し、より適切な意思決定を行い、容易に報告できます。アセットで追跡する内容に応じて、これらのレポートを使用して在庫管理、ライフサイクル管理、従業員の生産性の測定などを行えます。レポートには、オブジェクトの種類、属性別のオブジェクト、または経時的なオブジェクトが表示されます。たとえば、現在使用中の従業員のラップトップの台数、メンテナンスが必要な台数、所有者、費用に関するデータを見ることができます。


その他のトピック

Assets Query Language - AQL

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


ヒントとコツ

フォーム デザイン