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

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

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

問題を定義する

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

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

一度に多くの情報を追加しすぎると正確性をチェックし難くなるため、一度に 1 つの問題に焦点を当てましょう。最初の問題が解決した後、他の問題を解決するために 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 を可能な限り最新の状態に保つために必要なリソースを削減できます。

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

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

データを 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 の手動更新は忘れやすいため、必要な頻度はできるだけ少なくするのが理想です。