[Jira Service Management] Insight内でのオブジェクトの構造化方法

[#1]

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

こんにちは。Insightに含めるべき情報の判断方法についてのアドバイスをご提供した前回の記事に続き、オブジェクトをオブジェクトを構造化する方法についてご説明します。この記事では、データをモデリングするにあたってのアドバイスを3つご案内します。前回に引き続き、正しい方法や誤った方法は存在しませんが、スムーズな運用を実現するための考慮事項はあります。

ほかにアドバイスをお持ちの方はぜひコメントに投稿してください。

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

すべてのデータを1つの巨大なオブジェクトスキーマにまとめる必要はありません。データの用途や持ち主に応じて複数のオブジェクトスキーマを持つことをおすすめします。

InsightおよびJiraでは、どのオブジェクトスキーマにどのデータが格納されているかは考慮されません。管理者は必要なデータにカスタムフィールドをポイントしますが、そのデータが所属するスキーマはどこでもかまいません。また、カスタムフィールドでは、1つの課題から複数のオブジェクトスキーマにデータをプッシュしたり、1つの課題で複数のオブジェクトスキーマからデータを取得したりすることができます。1つのオブジェクトスキーマにあるオブジェクト間のリンクは、別のオブジェクトスキーマのものから作成できます。また、複数のスキーマを横断してクエリを実行できます。オブジェクトスキーマの主な目的は、Insightというよりも私たち人間による理解を容易にすることにあります。

データを複数のオブジェクトスキーマにブレイクダウンすることは、ユーザーフレンドリーの面と、容易な管理の2つのメリットを実現します。Insightからの情報を必要としている、財務や人事部門などのチームが、自身のチームに関連しない情報に溺れることはなくなります。また、あるチームにデータ品質の定期的な確認を依頼する際にも、1つの巨大なオブジェクトスキーマの特定の側面よりも1つのオブジェクトスキーマの確認を依頼するほうがかんたんです。

最後に、各オブジェクトスキーマには独自の権限があるため、機密データをお持ちのときにそれを特定のユーザーに非表示にすることができます。

2. データのフェデレーションを行う

利用可能なデータベースや情報源をすでにお持ちで、その最新状態を保つためのプロセスが用意されている場合は、そのデータをInsightに移動する必要はありません。代わりに、連携機能を使ってその関連データのコピーを作成し、連携機能を定期的に実行するようにしてInsight側の情報を最新に保つようにすることをおすすめします。

Insightには多数のインポーターや連携機能が付属します (現時点ではクラウド製品では一部のみが提供されますが、現在連携機能の需要を確認しています)。これには、CSV、JSON、LDAP、ServiceNow、Device42、AWS、Azure、Google Cloudなどが含まれます。このようなインポーターや連携機能を使い、意思決定を行う必要がある情報をJira課題やInsightに提供しつつ、管理の重複を防ぐことができます。

よくある例として、LDAPインポーターを使ってInsightをActive Directoryと同期させる方法があります。すべてのユーザーを簡単に取り込み、同期を定期的に実行することで最新状態を保てます。

このようなインポートしたデータ用に個別のオブジェクトスキーマを作る人も、インポートしたデータをより大きなオブジェクトスキーマの一部にする人もいます。データが複数の場所で使われる場合は別のオブジェクトスキーマとして持つほうが理にかなっています。

前の記事でご説明したように、連携機能を使ってあらゆるデータを取り込むのはおすすめしません。連携機能をセットアップするときに、オブジェクトスキーマに取り込む情報と取り込まない情報を選択できます。また、このようなデータをInsight内で直接更新するのも推奨されません。これを行う場合は同じ変更を元のソースにも適用しないと、データの競合が発生します。

既存の連携機能が提供されていない場合は、別のオプションを利用できます。まず、データを定期的にCSV/JSONファイルとしてエクスポートし、InsightのCSV/JSONインポーターでそれらを定期的に取り込むようにします。あるいは、空に近いオブジェクトを作り、そこに、より多くの情報を含む別のデータベースにリンクする、URL属性を追加できます。これは、エージェント側で情報を参照したいが、それに基づく検索やレポートは不要な場合に便利です。

3. 同じ属性の再利用は避ける

1つの属性が複数の場所で使われていて、それらで同じ値が繰り返し使われている場合、それを独自のオブジェクトタイプにしてしまうことをおすすめします。たとえば、ベンダーが考えられます。ノートPC、電話、プリンター、モニタなどの各オブジェクトタイプにベンダーという名前の属性が存在し、それぞれのノートPCや電話についてベンダー名を入力 (またはインポート) しなければならないとします。

この方法が悪いわけではありませんが、”ベンダー” という名前のオブジェクトタイプを作り、各ベンダーはオブジェクトとして設定するほうが効率的です。これには次のような理由があります。

1. ベンダー名よりも多くの情報が欲しい場合があります。サポート用の電話番号や契約へのリンクなどの、ベンダーに関連する他の情報が必要かもしれません。このような情報をノートPCや電話の1台ずつについて入力するのは大変で、情報は一度のみ入力し、ベンダーオブジェクトにリンクするほうが便利です。また、ベンダー管理をJira内で行いたい場合にも便利です。

2. ベンダー情報が必ず標準化されるようになるため、レポートを簡単に実行できます。たとえば、ベンダーごとのインシデント数などのレポートを作成するときに、誰かがMicrsoftやApleなどと入力しているために情報が欠落するようなことがなくなります。

3. ベンダーがリブランディングや何らかの変更を行ったときに、1か所を変更するだけで済みます。

ベンダーは1つの例に過ぎませんが、ビジネスにおける重要性のレベル、デプロイ環境、部門、所在地など、ほかにもさまざまな例が考えられます。

データの構造化についてのヒントをご説明させていただきました。ほかにもヒントをお持ちの方や、ご質問をお持ちの方がいましたら、ぜひコメントを投稿してください。