Insight for Jira Service Management Data Center をご利用いただくにあたり知っておく必要がある、あらゆる情報です。
Insight for Jira Service Management Data Center スタート ガイド
このガイドは、Insight for Jira Service Management Data Center の設定を開始するすべてのユーザーを対象としています。Insight を使用すると、チームはアセット、構成アイテム、リソースを追跡して、アプリケーション、サービス、基礎となるインフラストラクチャ、およびその他の重要なセット間の重要な関係を可視化できます。Insight は Jira 上に構築されており、アセットと構成項目をサービス リクエスト、インシデント、問題、変更、重要なコンテキストを得るためのその他の課題に簡単かつ迅速に結びつけることができます。
Insight の詳細については、こちらをご覧ください。
ステップ 1 - インストール
Jira Service Management Data Center 4.15 以上を使用している場合は、ファイルのダウンロード時に Insight 機能が既に組み込まれています。
Jira Service Management Data Center 4.14 以前を使用している場合は、無料の Insight - Asset Management アプリをインストールする必要があります。
- Jira 管理者グローバルを持つユーザーとして Jira Service Management にログインします。
- 管理ドロップダウンをクリックして、[アプリの管理] を選択します。
- ページの左側にある [新しいアプリの検索] をクリックし、「Insight」を検索します。
- 結果に適切なアプリのバージョンが表示されます。
- 画面の指示に従って、アプリをインストールします。
- MyAtlassian へのログインを促すメッセージが表示され、Insight のダウンロードが開始されます。
ステップ 2 - Insight の構造を理解する
このセクションでは、Insight データベースの構造について概要を説明します。
オブジェクト
オブジェクトは、実際のアセット/構成項目です。これらはあなたの Jira 課題にリンクできるため、課題が発生するたびに、すぐに課題にコンテキストが追加されます。
また、オブジェクト参照を使用して相互にリンクして、オブジェクトが互いにどのように依存するかを示すこともできます。
オブジェクト スキーマ
オブジェクト スキーマは、実際の構成管理データベース (CMDB) です。このデータベースには、オブジェクト タイプ (以下を参照) とオブジェクトが含まれます。Insight で複数のオブジェクト スキーマを作成できます。これは、さまざまな理由で役立ちます。
- データをより小さなチャンクに分割すると、データを監査し、正確な状態に保ちやすくなります。
- 機密データがある場合 (例: 従業員情報) を使用した場合、アクセス許可が制限された 1 つのオブジェクト スキーマにすべてのデータをまとめやすくなります。
Insight にデータを配置する方法を決定するときは、データを論理オブジェクト スキーマにグループ化できるように、データの用途と更新対象者を考慮します。
Insight (およびその延長で Jira Service Management) は、どの情報がどのオブジェクト スキーマに含まれているかを考慮しません。それは、1 つの大きなデータ プールを確認するだけです。つまり、1 つのユース ケースで複数のオブジェクト スキーマを簡単に使用でき、複数のオブジェクト スキーマのオブジェクト間にリンクを作成できます。
オブジェクト タイプ
オブジェクト タイプはスキーマ内にあり、スキーマに含まれるオブジェクトを定義します。これは自分で定義することも、カスタマイズできる特定のオブジェクト タイプがあらかじめ入力されているオブジェクト スキーマ テンプレートを使用することもできます。オブジェクト タイプは、実際のオブジェクトのコンテナとして機能します。Insight は非常にオープンで柔軟であるため、オブジェクト タイプは希望に合わせて定義でき、一般的なオブジェクト タイプは次のとおりです。
- ビジネス サービス
- ホスト
- ラップトップ
- ソフトウェア
しかし、IT セットである必要はありません。たとえば、多くの人々は次のようなその他の有用な情報を追加します。
- ベンダー
- 場所
- 従業員
- ビジネス上の優先順位
階層ツリー内のオブジェクト タイプは、理にかなった方法で整理できます。このツリーは主にナビゲーションと読みやすさのためのもので、これを助けるために空のオブジェクト タイプを持つこともできますが、オブジェクト タイプを簡単に作成できるように属性の継承を提供するように設定できます。

オブジェクト タイプ属性
オブジェクト属性は、オブジェクト タイプを定義するものです。各オブジェクト タイプには、独自の属性セットがあります。たとえば、オブジェクト タイプ「ラップトップ」には、モデル、シリアル番号、ユーザー、保証の有効期限などの属性があります。
属性に実際の値を入力すると、オブジェクトが定義されます。これは手動または自動で行うことができます (手順 4 を参照)。
すべてのオブジェクト タイプには、次の 4 つの必須属性があります。
- 名前
- キー
- 作成日
- 最終更新日
最後の 3 つは自動的に設定されます。その他のすべての属性は、管理者が定義できます。また、一意のキー属性があるため、各オブジェクトの名前は一意である必要はありません。

属性は、テキスト、日付、数字、URL (情報またはサービス契約の他のストアにリンクするのに最適)、Jira ユーザー (オブジェクトの所有権の設定に最適)、ステータス (在庫あり、割り当て済み、廃止済みなど)、およびその他のオブジェクト (詳細については次のセクションを参照してください) など、さまざまなデータ タイプで構成できます。
オブジェクト参照
特に呼び出すオブジェクト属性は、「オブジェクト」の属性タイプです。これにより、他のオブジェクトへの参照が作成され、オブジェクト間の依存関係のマップの作成が開始されます。
たとえば、所在地が独自のオブジェクト タイプである場合、各ロケーション オブジェクトをビジネスのオフィスの所在地の 1 つにすることができます。これにより、たとえば「ストックホルム」を選択することで、すべてのラップトップの所在地をすばやく設定できます。

オブジェクト参照は、手動で設定する必要はありません。ネットワーク スキャナー、インポーター、自動化ルールなどから自動的に追加できます。これらの詳細については、手順 4 を参照してください。
オブジェクト間の参照には、主に次の 2 つの利点があります。
大きな利点 - オブジェクト間の依存関係をマッピングできます。たとえば、ビジネス サービスを、依存するさまざまなホスト、オペレーティング システム、およびファイルにマッピングできます。このマップは、下流での変更における影響への理解 (この OS を変更した場合、何に影響があるのか?)およびインシデントと問題の原因の把握に非常に便利な場合があります。また、各オブジェクトを Jira の問題にリンクできるため、インフラストラクチャやその他のビジネス資産の包括的な履歴を継続的に構築します。それは、課題や問題の解決に役立ちます。
小さな利点 - より管理しやすくなります。オフィスがモントリオールからトロントに移動する場合、モントリオールをトロントに変更する各ラップトップを経由するのではなく、オブジェクト「モントリオール」を更新するだけで済みます。
オブジェクト参照には、次の 2 つのタイプがあります。
- アウトバウンド参照は、現在のオブジェクトから他のオブジェクトへの参照です。
- インバウンド参照は、現在のオブジェクトを参照する他のオブジェクトです。
オブジェクト間の参照は、グラフィカル ビューワーを使用して表示できます。あなたが持っている参照タイプ (例: インストール先、所有者、ベンダー) を決定し、オブジェクト スキーマ設定でこれらを色分けすることができます。

Insight 権限
Insight には 3 種類の権限があります
- グローバル権限 - グローバル設定では、Insight の管理権限を持つユーザーを指定できます。「Insight 管理者」ロールに割り当てられたユーザーは、Insight 内のすべてのアクションを実行できます。
- オブジェクト スキーマのアクセス許可 -オブジェクト スキーマ設定では、特定のオブジェクト スキーマの管理者権限を持つユーザー、オブジェクト スキーマデータを更新できるユーザー、およびデータを表示できるユーザーを定義できます。
- オブジェクト タイプ権限 - Jira Service Management 顧客には、オブジェクト スキーマ内の特定の情報のみを表示できるようにしたいが、オブジェクト スキーマ全体内のすべてのデータを閲覧できるアクセス権を付与したくない場合があります。その場合では、オブジェクト タイプ権限を使用できます。
ステップ3 - 含めるデータを選択する
企業ごとに異なる情報を追跡する必要があるため、Insight のインスタンスはすべて独自のものになります。Insight には、あなたとあなたのビジネスに役立つあらゆる情報を保存できます。
どのアセットまたは構成項目を含めるべきかは、何をしようとしているかによって異なります。在庫管理のための Insight インスタンスは、変更やインシデントをより迅速に解決するためのビジネス サービスとその依存関係をマッピングするために使用されるインスタンスと大きく異なります。
どのデータを含めるべきかを決定するためのアドバイスは次のとおりです。
問題を定義する
ほとんどのツールは問題の解決を目的に実装されており、Insight も例外ではありません。インシデント解決速度が希望するほど速くない、またはサービスの依存関係を容易に確認できないため特定のサービスへの変更によって予期しない結果が生じる場合があります。
問題を見つけ、それを使用して、関与させる人からデータベースに含めるアセットと情報に至るまであらゆるものを定義できます。問題を確認し、問題を克服するためにスタッフが必要な追加情報を把握します。この情報によって、オブジェクト タイプが定義されます。
一度に多くの情報を追加しすぎると、正確性をチェックするのが難しいため、一度に 1 つの問題に焦点を当ててみてください。最初の問題が解決されると、Insight は他の問題を解決するために拡張できます。
サービスから始める
構成管理を使用する場合は、解決しようとしている問題に関連するサービスから始めることをお勧めします。サービスは明確に定義されており、運営において依存するさまざまなアセットを追加したり、それらのアセットが依存するアセットを追加したりするのは比較的簡単です。最終的に、関連する各サービスとその依存関係の全体像を構築します。
必要な詳細度を決める必要があります。サービスを理解するために必要な詳細度を現実的に考えてください。特定のラックとケーブルのマッピングは詳細すぎる場合もあれば、必要な場合もあります。
また、すべてのサービスを一度に実行する必要はありません。ビジネス クリティカルなサービス、またはダウンタイムが最も多いサービスから始めることができます。
サービスを開始すると、まずアセット/構成項目の定義セットが与えられます。その後、新しい問題が発生したときに、必要に応じて他のアセットを追加できます。インフラストラクチャとアセット全体よりも、小さなデータのチャンクの正確性を簡単に確認できるため、CMDB を少しずつ構築するのが最善です。
オブジェクト スキーマ テンプレートの使用
Insight には、IT 資産と構成管理、人事、顧客関係管理のためのオブジェクト スキーマ テンプレートが付属しています。
これらのテンプレートはニーズに合わせて変更できますが、Insight に保存することが多いオブジェクトのタイプの出発点として適しています。オブジェクト タイプのリストを下に移動して、使用しないものを削除します。

ヒントとコツ
絶対に必要なものについて考える
何を達成しようとしているのか、そのために必要な情報について慎重に考えてください。各オブジェクトとその属性は役に立ちます。
チームや関係者と一緒に座って、各属性を消費する人とものを確認する必要があります。誰も使用しないものは削除します。またいつでも後で追加できます!
サーバーの正確な所在地を知る必要が本当にありますか?また、オペレーティング システムのメーカーを知る必要がありますか?おそらくあなたはそれを知っているでしょうし、それ自体は全く問題ありません。しかし、そのデータに基づいて決定やクエリを行うつもりがない場合、それらのデータは不要です!
データを追加しすぎると、次のような問題があります。
- オブジェクトと属性が多いほど、それを正確に保つために必要な作業が増えます。
- 未使用のデータが多いと貴重なデータを把握しにくくなり、極端な場合にはパフォーマンスを低下させることさえあります。
- データは削除するよりも、後で追加する方が簡単です。そのため、何か欠けていることがわかった場合は、「念のため」データのロードから始めるのではなく、後で追加してください。データの削除が好きな人はいません。
将来の保守性を考える
Insight でのデータの保守方法を検討してください。オブジェクトの属性はどれくらい頻繁に変更され、Insight で最新の状態に保つのはどれくらい簡単ですか?
オブジェクトの特定の詳細が頻繁に変化するが、ほとんど使用されない場合は、Insight からそれを削除し、実際に必要な機会があればそれを調べる方が理にかなっています。ときどき使用されるがあまり変化がないものについては、アクセスしやすいように含めておくのが良いでしょう。
ラップトップ ソフトウェアを例に取ります。必要に応じて、スキャン エージェント、ソフトウェア要求の課題、自動化ルールを使用して、ラップトップにインストールされているすべてのソフトウェアを含めるように Insight を更新できます。オープン インストール ポリシーがある場合、これは比較的早く変更され、スキャン パターンが新しいソフトウェアを取得できない可能性があるため、精度が少し落ちることがあります。代わりに、使用方法の理解に特に関心のある重要なソフトウェアを確認することが良い場合が多いでしょう。
厳格なインストール ポリシーがあり、ラップトップのセットアップ時とサービス デスクの要求によってのみソフトウェアがインストールされる場合は、変更速度が遅く、追跡が容易であるため、すべてを Insight に保存することが理にかなっています。
物理的な項目にとらわれない
Insight では必要なオブジェクトを定義できるため、従来のアセットや物理的なアセットに限定されません。たとえば、ビジネス サービスは物理的な資産ではありませんが、多くの場合、詳細な理解が非常に重要です。サービスの物理的および非物理的な依存関係をすべてそのサービスにリンクできるため、ビジネス サービス オブジェクトを見るだけで、サービスの実行方法を完全に理解できます。
好きなだけ抽象化できます。Insight ユーザーが作成する一般的な例には、ビジネス上重要なオブジェクト、環境タイプ、部門/チーム、所在地などがあります。
現実世界のその他の例として、ビジネス サービスの分類が挙げられます。すべてのビジネス サービスがオブジェクト タイプ「ビジネス サービス」として Insight に追加されているとします。これらのビジネス サービスを「金融」、「物流」、「販売」、「インフラ」などに分類できます。これは、ビジネス サービス オブジェクト タイプの属性を使用して行うか、これらのカテゴリを「サービス カテゴリ」と呼ばれる独自のオブジェクト タイプにすることができます。

この利点は、ビジネス サービスのカテゴリに固有の詳細 (属性) を追加できることです。すべての金融ビジネス サービスを担当する人がいるかもしれません。メンテナンスが困難になるので、その人をすべての財務「ビジネス サービス」オブジェクトに直接追加する必要はありません。「サービス カテゴリ」オブジェクト タイプの「財務」オブジェクトに一度追加すれば、それを一括で更新でき、データを繰り返す必要はなくなります。
また、個々の財務ビジネス サービスの運用ステータスを取得し、財務カテゴリの全体的なステータスにロールアップするルールを設定することもできます。これで、カテゴリ オブジェクトを表示して、各サービスのカテゴリにサービス問題があるかどうかをすばやく確認できます。
これらのタイプのオブジェクトを Insight に追加する必要はありませんが、従来のアセット/設定項目によって制限されないことを知っておくことが重要です。すべては、あなたの目的次第です。そのため、目標およびその目標の達成に必要な情報の理解が重要なのです。
先を見て徐々に成長する
将来的に実行したい拡張を覚えておいてください。それは、含めるべきデータだけでなく、データの構造も決まります。
それを念頭に置いておくのは良いことですが、Insight は段階的に構築することをお勧めします。1000 個のオブジェクトに対して 100% 正確なデータを使用して 1 つの巨大なリリースを行うのは非常に難しいです。小さい規模から始め、新しい属性、オブジェクト、およびオブジェクト スキーマを追加する方がはるかに簡単です。
問題を見つけ、それを修正するために Insight を構築し、次の問題に移行し、進捗に合わせて Insight を拡張することをお勧めします。
精度に対する現実的な期待値を設定する
常に 100% の精度を維持するのが理想ですが、実際には難しいかもしれません。しかし、それで問題ありません。データが何もない場合よりもあった方が高いビジネス価値を得られさえすれば、その精度で十分なのです。多くの CMDB プロジェクトは、稼働前に「完璧」にしようとするあまり遅れたり、さらには失敗したりする場合があります。
ステップ 4 - データを Insight に入れる
すべてを手動で入力すると、大規模な組織では大仕事になる可能性があります。そのため、データの入力をサポートするいくつかのツールがあります。
Insight Discovery Network Scanner
Insight Discovery は、マーケットプレースから無料でご利用いただけます。
Insight Discovery は、ネットワーク資産を取得するエージェントレス スキャナーです (ただし、より詳細な情報を取得できるエージェントもあります)。Insight オブジェクト スキーマに取り込むアセットと属性を選択したり、独自のスキャン パターンを作成して、よりニッチなアセットを検索できます。スケジュールに従って実行すると、変更が取得され、データが最新の状態に保たれます。自動化ルールを使用すると、検出された変更に基づいて Jira 課題や電子メール通知などをトリガーすることもできます。
インポーター
Insight インポートを使用して、他のソースからデータを取り込むことができます。これらのインポート ルールは、スケジュールに従って同期できるため、必要に応じてデータを更新できます。インポート タイプごとに、Insight でのデータの保存場所とインポート先を定義する必要があります。
CSV インポート
すべてのアセットを含む Excel、スプレッドシートなどのスプレッドシートを使用している場合は、CSV インポートを使用して Insight にデータを取り込むことができます。これにより、資産を課題にリンクし、影響を分析できる、統合された透明性の高いシステムを実現できます。
データベース インポート
データベース インポートを使用して、内部システムまたはサードパーティ システムからデータをインポートできます。サポートされているデータベースには、Oracle、MySQL、Microsoft SQL Server、PostgreSQL などがあります。
Jira ユーザー インポート
多くの場合、Insight のユーザーは Jira ユーザーを所有するアセットにリンクします。そのためには、Jira ユーザーまたは特定のユーザー グループを Insight にインポートする必要があります。これは、Jira ユーザー インポートで行うことができます。
LDAP インポート
承認プロセスに使用されるアセットまたは従業員とマネージャーの関係を含む社内ディレクトリを扱っていますか?作業を簡単にするために、Insight には、一般的な LDAP ディレクトリで動作するモジュールがあり、ディレクトリから構造とアセットを取得します。
JSON インポート
インポートするデータを保持する JSON ファイルを使用して、オブジェクトを Insight にインポートできます。
統合
統合は、クラウド サービス、アセット マネージャー、その他の CMDB などの他のツールに接続するために使用できます。
これらのツールはすべて用意されていますが、ツールを減価償却する予定がある場合を除き、すべてのデータを Insight に取り込むことはお勧めしません。Jira Service Management で使用する必要があるものだけ取り込んでください。後からいつでも追加は可能です。
すべての統合は、Marketplace から無料でインストールできます。
Insight 統合の完全な一覧については、こちらを参照してください。
Insight Macro for Confluence Integration もあります。この統合により、アセットを文書化するための Confluence ページを作成できます。Insight にデータを取り込むのではなく、データを送信します。
ヒントとコツ
Insight Discovery、インポーター、および統合の実行頻度をバランスよく把握する必要があります。頻度が低すぎると、Insight が古くなります。頻度が高すぎると、処理しているオブジェクトの数によっては、多くのリソースを消費する可能性があります。1 時間ごとに統合を実行するユーザーもいれば、週に 1 回、またはオンデマンドで実行するユーザーもいます。
負荷が軽い時間には、できるだけ頻繁に同期することをお勧めします。データの変更頻度、およびそのデータの重要性を確認して、実行するためにスケジュールする必要がある頻度を決定します。データの変化の速さに遅れないようにしましょう。
Insight Discovery を使用すると、さまざまなスキャン パターンを異なる頻度で実行し、Insight を可能な限り最新の状態に保つために必要なリソースを削減できます。
ステップ 5 - データの構造化方法を決定する
データを論理オブジェクト スキーマに分割する
すべてのデータを、1 つの巨大なオブジェクト スキーマに入れる必要はありません。データの使用またはデータの所有者に基づいて複数のオブジェクト スキーマを持つことをお勧めします。
Insight とJira は、どのオブジェクト スキーマにどのデータが含まれているかを気にしません。管理者は、そのデータに含まれるスキーマに関係なく、必要なデータで Insight カスタム フィールドを指すだけです。また、カスタム フィールドは、1 つの Jira 課題からデータを複数のオブジェクト スキーマにプルおよびプッシュできます。あるオブジェクト スキーマのオブジェクト間のリンクは、別のオブジェクト スキーマ内のオブジェクトを使用して作成でき、クエリは異なるスキーマ間で実行できます。オブジェクト スキーマは基本的には、Insight そのもののためではなく、私たちの生活を楽にするためのツールです。
データを異なるオブジェクト スキーマに分けることによって、ユーザー フレンドリーになり、保守がより簡単になります。Insight からの情報を必要とする財務部門、人事部門などのチームは、必要ない情報に翻弄される必要はありません。また、チームに 1 つの大きいオブジェクト スキーマの特定の部分のみをチェックするように依頼するよりも、1 つのオブジェクト スキーマで定期的にデータ品質のチェックを行うように依頼する方が簡単です。
データをフェデレーションする
完全に利用可能なデータベースまたは情報ソースがどこかに存在し、それを更新し続けるためのプロセスがすでにある場合、データを Insight に移動する必要はありません。代わりに、統合を使用して関連するデータのコピーを作成し、それらの統合をスケジュールに従って実行して、Insight 情報を更新する方がよいでしょう。
Insight には、多数のインポーターと統合が付属しています (上記参照)。これらのインポーターと統合により、意思決定に必要な情報を Jira 課題/Insight 自体で利用できますが、2 つのコピーを別々に保守することはできません。
この非常に一般的な例は、LDAP インポーターを使用してInsightを Active Directory と同期しているユーザーです。これで、すべての Windows ユーザーが簡単にアクセスできるようになり、同期を定期的に実行して最新の状態に保つことができます。
場合によっては、このインポートされたデータに対して個別のオブジェクト スキーマを作成することもあれば、より大きなオブジェクト スキーマに統合する場合もあります。データが複数の用途に使用される場合 (例: IT サポートと人事)、それを IT オブジェクト スキーマに直接結びつけ、HR にそのスキーマへのアクセス権を付与するのではなく、別のオブジェクト スキーマとして持つ方が理にかなっています。
統合では、利用可能なすべてのデータを Insight に取り込むことはお勧めしません。統合を設定するときに、オブジェクト スキーマに何を取り込み、何を取り込まないかを決定できます。また、この変更を元のデータ ソースにプッシュしない限り、Insight 内でこのデータを更新しないでください。更新すると、データの競合が発生します。
事前に構築された統合が利用できない場合は、他にもいくつかのオプションがあります。1 つ目は、データを CSV/JSON ファイルとして定期的にエクスポートし、Insight CSV/JSON インポーターでスケジュールに従ってデータを取り込むことです。または、オブジェクトを作成し、そのオブジェクトに詳細情報がある他のデータベースにリンクする URL 属性を付与することもできます。このオプションは、エージェントが情報を表示できるようにし、その情報に基づいて検索またはレポートを作成したくない場合に適しています。
同じ属性をどこでも再利用することは避ける
属性が多くの場所で使用され、同じ繰り返し値を持つことが多い場合は、それを独自のオブジェクト タイプにする方が理にかなっています。ベンダーが良い例です。たとえば、オブジェクト タイプ「ラップトップ」と「電話」に「ベンダー」という属性を使用して、各オブジェクトにベンダー名を入力 (またはインポート) できます。
これは問題ありませんが、多くの理由により、「ベンダー」というオブジェクト タイプを使用して、各ベンダーをオブジェクトとして設定する方が効率的です。
- ベンダー名以外の情報も必要になる場合があります。サポート連絡先番号や契約へのリンクなど、ベンダーに関連するその他の情報が必要な場合があります。すべてのラップトップとすべての電話にこれを繰り返す必要はありません。一度入力して、ベンダー オブジェクトにリンクするだけで十分です。これは、Jira Service Management 内でベンダー管理の要素を実行する場合にも役立ちます。
- ベンダーはこのように標準化されるため、レポートの実行が容易になります。ベンダーごとのサポート リクエストの数について報告する場合は、誰かが Micrsoft または Aple をどこかに書いたため、何も見逃していないと確信できます。
- ベンダーを何らかの方法でリブランドまたは変更する必要がある場合は、1 か所で更新するだけで済みます。
ベンダーは一例に過ぎず、ビジネス上の重要性、デプロイ環境、部門、場所などが含まれます。
ステップ 6 - Jira 課題に Insight カスタム フィールドを設定する
このセクションでは、Insight オブジェクトとリンクするように Jira 課題を設定する方法について説明します。影響を受けるビジネス サービスをインシデント課題にリンクする、ハードウェア リクエスト課題にコンピュータを追加する、影響を受ける可能性のあるホストのセットを変更リクエスト課題に追加する、といった方法があります。
Insight を使用すると、新しい特定の Insight カスタム項目にアクセスできます。これらのカスタム フィールドは、特定のオブジェクト セットを指すように設定する必要があります。
Insight フィールドはロックダウンして、顧客が利用可能なリストから選択するか、空白のままにすることができます。または、開いたままにしておいて、Jira 課題を記入するすべてのユーザーがフォームから直接 Insight に新しいオブジェクトを追加できます。
主に最初のオプションを使用することをお勧めしますが、2 つ目のオプションが適したユース ケースもあります。例として、新しい従業員のオンボーディングが挙げられます。従業員を Insight に保存する場合は、採用マネージャーに Insight カスタム項目を開いている状態でオンボーディング Jira リクエストを入力させることができます。これにより、バックグラウンドで新しい Insight に従業員オブジェクトが自動的に作成されます。これにより、時間と管理者の作業が軽減されます。
ステップ 7 - 自動化をセットアップする
このセクションでは、Insight で反復的なタスクを自動化するための 2 つのオプションについて説明します。
Insight の自動化
Insight の自動化は、各オブジェクト スキーマに固有です。一般的な例:
- スキーマ内の Insight オブジェクトによる特定のトリガーや変更に基づいて通知を送信する - 例:ライセンスまたは保証の有効期限が切れたときにメールを送信する、またはサービスが停止した場合に Jira 課題を作成する。
- Insight データを整理し、標準化された状態に保ち、レポートとクエリを行いやすくします。

自動化ルールは、オブジェクト情報の更新、課題の作成、メールの送信、HTTP リクエストの作成、Groovy スクリプトの実行などを行うことができます。
自動化ルールの作成方法はこちらをご覧ください。
事後操作
Insight では新しい事後操作も導入しています。オートメーション ルールと同様に、事後操作を使用するとアクションの実行を自動化できます。
違いは、Jira ワークフロー (課題の移行) によって課題ステータスが変更されたときにアクションが実行されることです。これらのアクションには、アセットの更新、通知の送信、スクリプトの実行などがあります。
たとえば、従業員のオンボーディングを要求する課題が作成されると、それぞれに Insight オブジェクトのリンクが必要なラップトップ、携帯電話、携帯電話サブスクリプションなど、新しいユーザーに必要なアセットを割り当てるためにタスクを作成できます。
ヒントとコツ
課題テキスト フィールドを使用して Insight でデータの入力や更新を行う場合、または Insight にオブジェクトを手動で入力する場合は、データが少し煩雑になる場合があります。このような場合は、自動化を使用してください。
サーバー名はその好例です。通常、サーバー名は標準化されており、誤入力しやすいかもしれません。タイプ サーバーのオブジェクトが作成または更新されたときにトリガーする自動化ルールを作成して、名前が命名規則を満たしていることを確認し、エラーが発生した場合にフラグを立てることができます。
ステップ 8 - データを正確に保つ方法を決定する
データを最新の状態に保つことは重要です。そうしないと、チームは誤った前提の下で作業し、インシデントの解決が遅れたり、サービス リクエスト後に間違った結果になる可能性があります。
Insight でデータを最新の状態に保つ方法は数多くありますが、その多くは自動化を活用して大量の作業を行います。
- データの定期的な監査を実行します。
Insight 自動化ルールは、スケジュールに従ってデータ監査を実行するようにユーザーに通知するように設定できます。これにより、重要なアセットを最新の状態に保つために、迅速なサニティー チェックを行うリマインダーが提供されます。 - Insight Discovery、および関連するインポーターと統合を定期的に同期します。
古いデータの大きなソースは、Insight を外部データ ソースと頻繁に同期していません。外部ソース内のデータの変更頻度、およびバランスを正しく保つために Jira Service Management で使用される頻度を考えてください。何かが頻繁に変更され、定期的に課題にリンクされる場合は、24 時間ごとに同期する必要があります。他の統合では、数週間または数か月も待つことがあります。 - 自動化ルールを使用します。
アセット/構成データを変更する Jira 課題で決定が行われる場合は、Insight でそれをキャプチャすることが重要です。たとえば、エージェントが持っているラップトップが壊れているため新しいラップトップをユーザーに提供することを決定した場合、Insight でキャプチャする必要がある情報があります。
- 新しいラップトップは、所有者をリクエスタに更新し、ステータスを「サービス中」に更新する必要があります。
- 古いラップトップは、所有者を削除し、ステータスを「異常あり」に更新する必要があります。
エージェントがこれをリクエスタに伝達すると、移行画面と Insight 投稿機能を使用してこのタイプの情報を取得し、自動化を使用して Insight で新しいステータスと所有者を設定できます。
これはあくまで一例であり、Insight を Jira ワークフローに組み込む際には、課題からどの情報を Insight に戻す必要があるかを考慮してください。Insight の手動更新は忘れやすいため、必要な頻度はできるだけ少なくするのが理想です。
ステップ 9 - レポートを設定する
レポートは、あなたとあなたの会社、そしてあなたが Insight で解決しようとしている問題に特化したものです。Insight には、アセットと構成データの理解に役立つ事前設定されたレポートが多数付属しています。Insight オブジェクト、関連する課題、プロジェクト、およびそれらに費やされた時間についてレポートできます。

たとえば、重要なビジネス サービスで発生した変更とインシデントの数や、サービス リクエストに費やされた時間と関連するアセットの種類に関するパターンがあるかどうかを把握できます。レポートを使用して、リンクされたインシデント数が最も多い重要なビジネス サービスを確認し、改善の優先順位を決める場所を把握できます。
その他のトピック
Insight クエリ言語 - IQL
Insight クエリ言語 (IQL) は、Insgith のクエリに使用される言語です。IQL は、検索ビュー、自動化ルール、アセット間の高度な参照を作成したり、インポートを指示したりするのに便利です。
ラベルと QR コード
ラベルと QR コードを使用すると、有形資産の管理を本当に合理化できます。このため、Insight では、任意のオブジェクトのラベルと QR コードを印刷できます。