Jira Service Management Data Center 向けアセットをご利用いただくにあたり、知っておく必要があるあらゆる情報です。
Jira Service Management Data Center 向けアセットを開始する
このガイドは、Jira Service Management Data Center 向けアセットの設定を開始するすべてのユーザーを対象としています。アセットを使用すれば、資産、構成アイテム、リソースを追跡してアプリ、サービス、基礎となるインフラストラクチャ、その他の重要な資産間の重要な関係を可視化できます。アセットは Jira に構築されており、チームは資産と構成アイテムをサービス リクエスト、インシデント、問題、変更、その他の課題に簡単に素早く結び付けられ、有用なコンテキストを取得できます。
アセットの詳細については、こちらをご確認ください。
ステップ 2 - Assets の構造を理解する
このセクションでは、Assets データベースの構造について概要を説明します。
オブジェクト
オブジェクトは、実際のアセット/構成項目です。これらはあなたの Jira 課題にリンクできるため、課題が発生するたびに、すぐに課題にコンテキストが追加されます。
また、オブジェクト参照を使用して相互にリンクして、オブジェクトが互いにどのように依存するかを示すこともできます。
オブジェクト スキーマ
オブジェクト スキーマは、実際の構成管理データベース (CMDB) です。このデータベースには、オブジェクト タイプ (以下を参照) とオブジェクトが含まれます。アセットでは複数のオブジェクト スキーマを作成できます。これは、さまざまな理由で役立ちます。
- データをより小さなチャンクに分割すると、データを監査し、正確な状態に保ちやすくなります。
- 機密データがある場合 (例: 従業員情報) を使用した場合、アクセス許可が制限された 1 つのオブジェクト スキーマにすべてのデータをまとめやすくなります。
Assets にデータを配置する方法を決定する際は、データを論理オブジェクト スキーマにグループ化できるように、データの用途と更新対象者を考慮します。
アセット (およびその延長で Jira Service Management) は、どの情報がどのオブジェクト スキーマに含まれているかを考慮しません。1 つの大きなデータ プールを確認するだけです。つまり、1 つのユース ケースで複数のオブジェクト スキーマを簡単に使用でき、異なるオブジェクト スキーマのオブジェクト間にリンクを作成できるということです。
オブジェクト タイプ
オブジェクト タイプはスキーマ内にあり、スキーマに含まれるオブジェクトを定義します。これは、自分で定義することも、オブジェクト スキーマ テンプレートを使用することもできます。このテンプレートには、カスタマイズできる特定のオブジェクト タイプが事前に入力されています。オブジェクト タイプは実際のオブジェクトのコンテナーとして機能します。アセットは非常にオープンで柔軟であるため、オブジェクト タイプは希望に合わせて定義でき、一般的なオブジェクト タイプは次のとおりです。
- ビジネス サービス
- ホスト
- ラップトップ
- ソフトウェア
しかし、IT セットである必要はありません。たとえば、多くの人々は次のようなその他の有用な情報を追加します。
- ベンダー
- 場所
- 従業員
- ビジネス上の優先順位
階層ツリー内のオブジェクト タイプは、理にかなった方法で整理できます。このツリーは主にナビゲーションと読みやすさのためのもので、これを助けるために空のオブジェクト タイプを持つこともできますが、オブジェクト タイプを簡単に作成できるように属性の継承を提供するように設定できます。
オブジェクト タイプ属性
オブジェクト属性は、オブジェクト タイプを定義するものです。各オブジェクト タイプには、独自の属性セットがあります。たとえば、オブジェクト タイプ「ラップトップ」には、モデル、シリアル番号、ユーザー、保証の有効期限などの属性があります。
属性に実際の値を入力すると、オブジェクトが定義されます。これは手動または自動で行うことができます (手順 4 を参照)。
すべてのオブジェクト タイプには、次の 4 つの必須属性があります。
- 名前
- キー
- 作成日
- 最終更新日
最後の 3 つは自動的に設定されます。その他のすべての属性は、管理者が定義できます。また、一意のキー属性があるため、各オブジェクトの名前は一意である必要はありません。
属性は、テキスト、日付、数字、URL (情報またはサービス契約の他のストアにリンクするのに最適)、Jira ユーザー (オブジェクトの所有権の設定に最適)、ステータス (在庫あり、割り当て済み、廃止済みなど)、およびその他のオブジェクト (詳細については次のセクションを参照してください) など、さまざまなデータ タイプで構成できます。
オブジェクト参照
特に呼び出すオブジェクト属性は、「オブジェクト」の属性タイプです。これにより、他のオブジェクトへの参照が作成され、オブジェクト間の依存関係のマップの作成が開始されます。
たとえば、所在地が独自のオブジェクト タイプである場合、各ロケーション オブジェクトをビジネスのオフィスの所在地の 1 つにすることができます。これにより、たとえば「ストックホルム」を選択することで、すべてのラップトップの所在地をすばやく設定できます。
オブジェクト参照は、手動で設定する必要はありません。ネットワーク スキャナー、インポーター、自動化ルールなどから自動的に追加できます。これらの詳細については、手順 4 を参照してください。
オブジェクト間の参照には、主に次の 2 つの利点があります。
大きな利点 - オブジェクト間の依存関係をマッピングできます。たとえば、ビジネス サービスを、依存するさまざまなホスト、オペレーティング システム、およびファイルにマッピングできます。このマップは、下流での変更における影響への理解 (この OS を変更した場合、何に影響があるのか?)およびインシデントと問題の原因の把握に非常に便利な場合があります。また、各オブジェクトを Jira の問題にリンクできるため、インフラストラクチャやその他のビジネス資産の包括的な履歴を継続的に構築します。それは、課題や問題の解決に役立ちます。
小さな利点 - より管理しやすくなります。オフィスがモントリオールからトロントに移動する場合、モントリオールをトロントに変更する各ラップトップを経由するのではなく、オブジェクト「モントリオール」を更新するだけで済みます。
オブジェクト参照には、次の 2 つのタイプがあります。
- アウトバウンド参照は、現在のオブジェクトから他のオブジェクトへの参照です。
- インバウンド参照は、現在のオブジェクトを参照する他のオブジェクトです。
オブジェクト間の参照は、グラフィカル ビューワーを使用して表示できます。あなたが持っている参照タイプ (例: インストール先、所有者、ベンダー) を決定し、オブジェクト スキーマ設定でこれらを色分けすることができます。
Assets の権限
アセットには 3 種類の権限があります。
- グローバル権限 - グローバル設定では、アセットの管理権限を持つユーザーを指定できます。「アセット管理者」ロールに割り当てられたユーザーは、アセット内のすべてのアクションを実行できます。
- オブジェクト スキーマのアクセス許可 -オブジェクト スキーマ設定では、特定のオブジェクト スキーマの管理者権限を持つユーザー、オブジェクト スキーマデータを更新できるユーザー、およびデータを表示できるユーザーを定義できます。
- オブジェクト タイプ権限 - Jira Service Management 顧客には、オブジェクト スキーマ内の特定の情報のみを表示できるようにしたいが、オブジェクト スキーマ全体内のすべてのデータを閲覧できるアクセス権を付与したくない場合があります。その場合では、オブジェクト タイプ権限を使用できます。
ステップ3 - 含めるデータを選択する
追跡すべき情報は企業ごとに異なるため、Assets のインスタンスはすべて独自のものになります。Assets には、自分と自分の業務に役立つあらゆる情報を保存できます。
含める必要がある資産または構成アイテムは、目的に応じて異なります。在庫管理のためのアセット インスタンスは、変更やインシデントの解決をより迅速に行うためのビジネス サービスおよびその依存関係をマッピングするために使用されるインスタンスと大きく異なります。
どのデータを含めるべきかを決定するためのアドバイスは次のとおりです。
問題を定義する
ほとんどのツールは問題の解決を目的に実装されており、Assets も例外ではありません。たとえば、インシデント解決速度が期待したほど速くない、またはサービスの依存関係が確認しにくいためサービスの変更によって予期しない結果が生じた、などです。
問題を見つけ、それを使用して、関与させる人からデータベースに含めるアセットと情報に至るまであらゆるものを定義できます。問題を確認し、問題を克服するためにスタッフが必要な追加情報を把握します。この情報によって、オブジェクト タイプが定義されます。
一度に多くの情報を追加しすぎると正確性をチェックするのが難しくなるため、一度に 1 つの問題に焦点を当てましょう。最初の問題が解決した後、他の問題を解決するためにアセットを拡張できます。
サービスから始める
構成管理を使用する場合は、解決しようとしている問題に関連するサービスから始めることをお勧めします。サービスは明確に定義されており、運営において依存するさまざまなアセットを追加したり、それらのアセットが依存するアセットを追加したりするのは比較的簡単です。最終的に、関連する各サービスとその依存関係の全体像を構築します。
必要な詳細度を決める必要があります。サービスを理解するために必要な詳細度を現実的に考えてください。特定のラックとケーブルのマッピングは詳細すぎる場合もあれば、必要な場合もあります。
また、すべてのサービスを一度に実行する必要はありません。ビジネス クリティカルなサービス、またはダウンタイムが最も多いサービスから始めることができます。
サービスを開始すると、まずアセット/構成項目の定義セットが与えられます。その後、新しい問題が発生したときに、必要に応じて他のアセットを追加できます。インフラストラクチャとアセット全体よりも、小さなデータのチャンクの正確性を簡単に確認できるため、CMDB を少しずつ構築するのが最善です。
オブジェクト スキーマ テンプレートの使用
アセットには、IT 資産と構成管理、人事、および顧客関係管理のためのオブジェクト スキーマ テンプレートが付属しています。
これらのテンプレートはニーズに合わせて変更できますが、アセットに保存することが多いオブジェクトのタイプの出発点として適しています。オブジェクト タイプのリストを下に移動して、使用しないものを削除します。
ヒントとコツ
絶対に必要なものについて考える
何を達成しようとしているのか、そのために必要な情報について慎重に考えてください。各オブジェクトとその属性は役に立ちます。
チームや関係者と一緒に座って、各属性を消費する人とものを確認する必要があります。誰も使用しないものは削除します。またいつでも後で追加できます!
サーバーの正確な所在地を知る必要が本当にありますか?また、オペレーティング システムのメーカーを知る必要がありますか?おそらくあなたはそれを知っているでしょうし、それ自体は全く問題ありません。しかし、そのデータに基づいて決定やクエリを行うつもりがない場合、それらのデータは不要です!
データを追加しすぎると、次のような問題があります。
- オブジェクトと属性が多いほど、それを正確に保つために必要な作業が増えます。
- 未使用のデータが多いと貴重なデータを把握しにくくなり、極端な場合にはパフォーマンスを低下させることさえあります。
- データは削除するよりも、後で追加する方が簡単です。そのため、何か欠けていることがわかった場合は、「念のため」データのロードから始めるのではなく、後で追加してください。データの削除が好きな人はいません。
将来の保守性を考える
アセットでのデータの保守方法を検討してください。オブジェクトの属性はどれくらい頻繁に変更され、アセットで最新の状態に保つのはどれくらい簡単ですか?
オブジェクトの特定の詳細が頻繁に変化するが、ほとんど使用されない場合は、アセットからそれを削除し、実際に必要になったときに調べる方が理にかなっています。ときどき使用されるがあまり変化がないものについては、アクセスしやすいように含めておくと良いでしょう。
ラップトップ ソフトウェアを例に取り上げます。必要に応じて、スキャン エージェント、ソフトウェア要求の課題、自動化ルールを使用して、ラップトップにインストールされているすべてのソフトウェアを含めるようにアセットを更新できます。オープン インストール ポリシーがある場合は、比較的早く変更されます。スキャン パターンが新しいソフトウェアを取得できない可能性があるため、精度が少し落ちる場合があります。代わりに、使用方法の理解に特に関心のある重要なソフトウェアを確認する方が良いかもしれません。
厳格なインストール ポリシーがあり、ラップトップのセットアップ時とサービス デスクの要求によってのみソフトウェアがインストールされる場合は、変更速度が遅く、追跡が容易であるため、すべてをアセットに保存することが理にかなっています。
物理的な項目にとらわれない
アセットでは必要なオブジェクトを定義できるため、従来の資産にも物理的な資産にも限定されません。たとえば、ビジネス サービスは物理的な資産ではありませんが、多くの場合、詳細に理解することが非常に重要です。サービスの物理的/非物理的な依存関係をすべてリンクできるため、ビジネス サービス オブジェクトを見ればサービスがどのように実行されるかを完全に理解できます。
好きなだけ抽象化できます。アセット ユーザーが作成する一般的な例には、ビジネス上重要なオブジェクト、環境タイプ、部門/チーム、所在地などがあります。
現実世界のその他の例として、ビジネス サービスの分類が挙げられます。すべてのビジネス サービスがオブジェクト タイプ「ビジネス サービス」としてアセットに追加されているとします。これらのビジネス サービスを「金融」、「物流」、「販売」、「インフラ」などに分類する必要があるとします。これは、ビジネス サービス オブジェクト タイプの属性によって行うか、これらのカテゴリを「サービス カテゴリ」と呼ばれる独自のオブジェクト タイプにすることができます。
この利点は、ビジネス サービスのカテゴリに固有の詳細 (属性) を追加できることです。すべての金融ビジネス サービスを担当する人がいるかもしれません。メンテナンスが困難になるので、その人をすべての財務「ビジネス サービス」オブジェクトに直接追加する必要はありません。「サービス カテゴリ」オブジェクト タイプの「財務」オブジェクトに一度追加すれば、それを一括で更新でき、データを繰り返す必要はなくなります。
また、個々の財務ビジネス サービスの運用ステータスを取得し、財務カテゴリの全体的なステータスにロールアップするルールを設定することもできます。これで、カテゴリ オブジェクトを表示して、各サービスのカテゴリにサービス問題があるかどうかをすばやく確認できます。
これらのタイプのオブジェクトを 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 を使用してさまざまなスキャン パターンを異なる頻度で実行することで、アセットを可能な限り最新の状態に保つために必要なリソースを削減できます。
ステップ 6 - Jira 課題に Assets カスタム フィールドを設定する
このセクションでは、アセット オブジェクトとリンクするように Jira 課題を設定する方法について説明します。影響を受けるビジネス サービスをインシデント課題にリンクする、ハードウェア リクエスト課題にコンピュータを追加する、影響を受ける可能性のあるホストのセットを変更リクエスト課題に追加する、といった方法があります。
アセットでは、新しい特定のカスタム フィールドを利用できます。これらのカスタム フィールドは、特定のオブジェクト セットを指すように設定する必要があります。
アセット フィールドはロックダウンして、顧客が利用可能なリストから選択するか、空白のままにすることができます。または、開いたままにしておいて、Jira 課題を記入するすべてのユーザーがフォームから直接アセットに新しいオブジェクトを追加できます。
主に最初のオプションを使用することをお勧めしますが、2 つ目のオプションが適したユース ケースもあります。例として、新しい従業員のオンボーディングが挙げられます。従業員をアセットに保存する場合は、採用マネージャーにアセット カスタム フィールドを開いている状態でオンボーディング Jira リクエストを入力させることができます。これにより、バックグラウンドで新しいアセットに従業員オブジェクトが自動的に作成されます。これにより、時間と管理者の作業が軽減されます。
ステップ 7 - 自動化をセットアップする
このセクションでは、アセットで反復的なタスクを自動化するための 2 つのオプションについて説明します。
アセットの自動化
アセットの自動化は、各オブジェクト スキーマに固有です。一般的な例:
- スキーマ内のアセット オブジェクトによる特定のトリガーや変更に基づいて通知を送信する - 例: ライセンスまたは保証の有効期限が切れたときにメールを送信する、またはサービスが停止した場合に Jira 課題を作成する。
- アセット データを整理し、標準化された状態に保ち、レポートとクエリを行いやすくする。
自動化ルールは、オブジェクト情報の更新、課題の作成、メールの送信、HTTP リクエストの作成、Groovy スクリプトの実行などを行うことができます。
自動化ルールの作成方法はこちらをご覧ください。
事後操作
アセットでは新しい事後操作も導入しています。自動化ルールと同様に、事後操作を使用するとアクションの実行を自動化できます。
違いは、Jira ワークフロー (課題の移行) によって課題ステータスが変更されたときにアクションが実行されることです。これらのアクションには、アセットの更新、通知の送信、スクリプトの実行などがあります。
たとえば、従業員のオンボーディングを要求する課題が作成されると、それぞれにアセット オブジェクトのリンクが必要なラップトップ、携帯電話、携帯電話サブスクリプションなど、新しいユーザーに必要なアセットを割り当てるためにタスクを作成できます。
ヒントとコツ
課題テキスト フィールドを使用してアセットでデータの入力や更新を行う場合、またはアセットにオブジェクトを手動で入力する場合は、データが少し煩雑になる場合があります。このような場合は、自動化を使用してください。
サーバー名はその好例です。通常、サーバー名は標準化されており、誤入力しやすいかもしれません。タイプ サーバーのオブジェクトが作成または更新されたときにトリガーする自動化ルールを作成して、名前が命名規則を満たしていることを確認し、エラーが発生した場合にフラグを立てることができます。
ステップ 9 - レポートを設定する
レポートは、あなたとあなたの会社、そしてあなたがアセットで解決しようとしている問題に特化したものです。アセットには、資産と構成データの理解に役立つ事前設定されたレポートが多数付属しています。アセット オブジェクト、関連する課題、プロジェクト、およびそれらに費やされた時間についてレポートできます。
たとえば、重要なビジネス サービスで発生した変更とインシデントの数や、サービス リクエストに費やされた時間と関連するアセットの種類に関するパターンがあるかどうかを把握できます。レポートを使用して、リンクされたインシデント数が最も多い重要なビジネス サービスを確認し、改善の優先順位を決める場所を把握できます。