[Jira Service Management] Insightに含めるべきデータについて

[#1]

※本記事は、Charlotte Nicolaouによる英語記事「What Data Shoud I Include in Insight?」を翻訳したものです。内容に相違が見受けられる場合、英文ページの内容を正とします。

こんにちは。今回も、Insightで作業する際の便利なヒントをご紹介します。これは、Insightに取り込むべきデータ、それらの構造化方法、およびそれらを最新に保つ方法についてご説明する、3つの記事から構成されるシリーズになります。これらはInsightの利用を開始するお客様からいただくもっともよくある質問でもあります。

これらはいずれもとても良い質問ですが、答えるのが難しい質問でもあります。答えは、ユーザーでのデータの使用方法、ユーザーのゴール、以前のアセットおよび構成管理の方法、チームの知識/熱意、企業の文化によって変わってくるためです。

Insightの最適な利用方法は企業によって変わってくるため、お手本になるようなガイドをご用意したり、全員が使える完璧なテンプレートを作成したりすることは、残念ながらできません。

代わりに、含めるべき (あるいは含めるべきでない) データ、作業やメンテナンスを楽にするためのデータの構造化方法、および実際のメンテナンス方法についてのガイダンスを提供します。

この記事の内容が完全に網羅的なものであるというような意図はありませんので、ほかのアイディアがありましたらコメントでお寄せください。

Insightを初めて利用する場合、Insightの構造についてのこちらの記事をまずお読みください。

Insightに含めるべきデータとは

答え: あなたまたはあなたのビジネスで、把握および理解しておくと有益な、任意の情報です。具体的な回答ではありませんが、Insightの美点は、なんでも追加できる柔軟性です。

含める個々のオブジェクトは、行おうとしていることに応じて異なります、インベントリ管理用のInsightインスタンスは、変更やインシデント解決を素早く行うためにビジネスサービスとそれぞれの依存関係をマップするために使われるInsightインスタンスとは大きく異なるでしょう。

重要なのは、含めるべきでないデータの判断 

Insightで行いたいことを判断するときには、達成したいことと、それに必要なオブジェクト情報を注意深く考えます。それぞれののオブジェクトと属性は、有益なものである必要があります。

チームやステークホルダーと打ち合わせの場を設け、それぞれの属性が誰か (あるいは何か) によって利用されることを確認します。誰も使用していない属性がある場合、それは削除します。これらはあとからいつでも追加できます。

たとえば、サーバーの正確な所在地や、オペレーティングシステムのメーカーは本当に把握しておく必要があるのでしょうか? 必要がある場合は何の問題もありません。しかし、それらのデータに基づいた判断や問い合わせを行うことがない場合、それはゴミ箱行きです。

私にできる最高のアドバイスは、なるべく注意深く考え、含めるべきデータと同じぐらいの比重で、含めるべきでないデータに焦点を当てることです。これには次のような理由があります。

• オブジェクトや属性の数が多ければ多いほど、それらの正確性を保つための作業が多く必要になります。

• 使われていないデータがたくさんあると、価値のあるデータがわかりづらくなるだけでなく、極端な例ではパフォーマンスの低下につながることもあります。

• データを削除するよりも、あとから追加するほうが簡単です。このため、”念のため” 大量のデータがある状態で開始するよりも、何かが不足しているとわかったときにそれをあとから追加するようにします。データの削除は愉快な作業ではなく、個人的にはInsightのデモインスタンスからデータを削除するときでさえ不安になります。

Insightのメリットを実現しているユーザーに共通することとして、オブジェクトや属性を軽量化することへの関心があります。

将来のメンテナンス性を考慮

データがInsight内に登録されたあとのメンテナンス方法を考慮するのも、非常に重要です。オブジェクトの属性はどの程度の頻度で変更され、Insight内で最新化するための難易度はどの程度のものでしょうか。

データを最新に保つ方法については今後の投稿でご説明しますが、これはオブジェクトスキーマを構築するときに常に気にかけておく必要があります。

オブジェクトの特定の詳細情報が頻繁に変更されるが、それはめったに使用されない場合、その情報はInsightには登録せず、情報が実際に必要とされる少数の事例ではInsight外を参照するほうが効率的です。非常に頻繁に利用される情報があるが、それがほとんど変更されない場合、アクセス性のためにInsightに含める価値があるかもしれません。

例として、ノートPCのソフトウェアを考えてみます。管理者は必要に応じ、スキャンエージェント、ソフトウェアリクエスト課題、自動化ルールなどを元に、ノートPCにインストールされているすべてのソフトウェアを含めることもできます。オープンなインストールポリシーをお持ちの場合、ユーザーの環境が比較的素早く変更され、スキャンパターンで新しいソフトウェアポリシーを取得できず、正確性が落ちるかもしれません。代わりに、特に用途を確認したい一連の特定のソフトウェアを確認するほうが良いかもしれません。

厳密なインストールポリシーをお持ちで、ノートPCのセットアップ時とサービスデスクのリクエスト経由でのみソフトウェアがインストールされる場合、変更率は低く追跡しやすくなると考えられるため、Insightで追跡するメリットを得られるかもしれません。

物理アイテムに留まることなく検討する

Insightでは要件に応じてオブジェクトを定義できますが、従来のアセットや物理アセットに囚われる必要はありません。たとえば、ビジネスサービスは物理アセットではありませんが、多くの場合、詳細に把握しておく必要があります。あるサービスの物理的および非物理的なすべての依存関係をそのサービスにリンクすることで、ビジネスサービスオブジェクトを見るだけでその実行方法のすべてを理解できます。

抽象化することもできます。よくある例として、ユーザーがビジネスにおける重要性、環境タイプ、部門/チーム、所在地などのオブジェクトを作成します。Insightでのデータモデリングについて説明しているDerek Fieldsの記事では、抽象化されたオブジェクトタイプや施設管理システムについての例を確認できます。

実世界のもう1つの例として、ビジネスサービスの分類があります。社内のすべてのビジネスサービスが、Insightのオブジェクトタイプ “ビジネスサービス” の配下に追加されたとします。このようなビジネスサービスを “財務”、”物流”、”セールス”、”インフラストラクチャ” などに分類したいとします。これは、ビジネスサービスオブジェクトタイプの属性で行うことも、カテゴリ用に “ビジネスサービスカテゴリ“ という独自のオブジェクトタイプを作成して行うこともできます。

この方法のメリットは、カテゴリに固有の詳細情報 (属性) を追加できることにあります。財務系のビジネスサービス全体の責任者がいるときに、その人をそれぞれの財務 “ビジネスサービス” オブジェクトに追加すると、メンテナンスが困難になります。代わりに、その人を財務 “ビジネスサービスカテゴリ” オブジェクトに一度のみ追加することで、更新も1か所でのみ行い、作業の繰り返しを避けることができます。

個々の財務ビジネスサービスの運用ステータスを元に財務カテゴリの全体的なステータスを判断するようなルールを持つことができます。これにより、カテゴリオブジェクトを見るだけで、各サービスカテゴリでサービスの問題が発生しているかどうかを素早く確認できます。

このようなオブジェクトタイプをInsightに追加することは必須ではありませんが、従来のアセット/構成アイテムに縛られる必要はないことを知っておくことが重要です。すべてはユーザーが実現したい内容に基づきます。ゴールと、その達成に必要な情報を理解するのが鍵となるのは、このためです。

将来を見据えてオーガニックに成長する

最後のアドバイスは、将来的に行いたい拡張を気に留めておくことです。これは、含めるべきデータの選定基準だけでなく、データの構造化方法 (こちらについては次の記事でご説明します) にも影響します。 

これを考慮しておくことをおすすめしますが、Insightは段階的に構築していくことをおすすめします。100%の信頼性のデータや何千件ものオブジェクトデータで1度限りの大規模なリリースを行おうとすることは困難です。小さく開始し、状況に合わせて新しい属性、オブジェクト、およびオブジェクトスキーマを追加していくほうがシンプルです。

私たちからの推奨事項は、問題を見つけ、それを修正するための方法をInsight内に構築し、次の問題に取り組み…を繰り返すことで、Insightを成長させていくことです。

次の投稿では、含めるべきデータを決定したあとにそれらをInsight内で構造化する方法についてご説明します。含めるべきデータの判断方法について実際の例がありましたらコメントをお寄せください。