Jira Assets (旧Insight) で築く「攻めのCMDB」：障害対応の迷走を終わらせる究極の実践術
「またか……このサーバーが落ちると、どのサービスが道連れになるんだ？」
障害発生時、Slackで右往左往し、構成図を探して数十分を浪費する。そんな惨めな光景を、今日で終わりにしましょう。
Jira Service Management (JSM) の奥深くに眠る最強の武器、それが Assets (旧Insight) です。単なるインベントリ管理ツールだと思っているなら、それは宝の山をゴミ捨て場として使っているのと同じこと。
本稿では、IT資産をJiraチケットと有機的に結合し、インパクト分析を爆速化する「真のCMDB構築術」を伝授します。
—
1. なぜ「静的な構成管理」は死ぬのか？
多くのチームがExcelやNotionで構成管理をして失敗するのは、「チケット（事象）」と「資産（実体）」が断絶しているからです。
Assetsを使う真の目的は、単にPCの台数を数えることではありません。「この障害が起きたとき、誰の、どの機能に影響が出るのか」を、Jiraの画面上で秒速で可視化することにあります。
実践的スキーマ設計の鉄則
Assetsのスキーマ構築において、最もやってはいけないのは「詳細すぎる分類」です。
- ラベル（Object Type）: サービス > クラスター > ノード > ソフトウェア
- リレーション（Reference）: `依存関係` を双方向に定義すること（重要！）
「Node A」に「Service B」が依存しているという参照関係を作れば、Jiraチケットに「Node A」を紐付けた瞬間、自動的に「Service Bへの影響」がクエリできる状態を作るのです。
—
2. 開発スピードを劇的に上げる「裏技」と設定
隠れたキーボードショートカット (Jira Assets)
資産管理画面でマウスをカチカチ動かすのは時間の無駄です。
- `Shift + A`: アセット検索モードへ即座にジャンプ。
- `Ctrl + Enter`: 編集中のオブジェクト詳細画面を即保存。
- `G + O`: オブジェクトグラフを表示。依存関係の視覚化に最適。
導入すべき「神プラグイン」
- ScriptRunner for Jira: Assetsのデータ更新を自動化するために必須。Webhookと組み合わせ、クラウド監視ツールから飛んできたJSONをAssetsに自動反映させます。
- Automation for Jira: 資産情報が更新されたら、関連する未解決チケットの担当者にSlack通知を飛ばす「動的なトリアージ」を実現します。
—
3. 実践コード：資産定義の自動化 (YAML構成例)
AssetsはGUIでポチポチ作るものではありません。APIを活用して「Infrastructure as Code」的に管理します。以下は、構成情報をインポートするためのYAML定義のベストプラクティスです。
assets-import-config.yaml
CMDBの整合性を保つためのスキーマ定義の一部（Automation API用）
objectTypes:
- name: Server
attributes:
- name: Hostname
type: String
- name: OS_Version
type: String
- name: Dependencies
type: ObjectReference # 他のオブジェクト（DatabaseやService）への参照
referenceType: Depends_On # 依存関係のラベルを明示
options:
allowMultiple: true
API連携時のマッピング例（JSON）
監視ツールから流し込む際、この構造でPOSTすることで自動紐付けを行う
mapping:
“host”: “${source.hostname}”
“attributes”:
“OS”: “${source.os}”
“Depends_On”: “${source.related_services}” # 依存関係を動的に更新
—
4. チームの生産性を底上げする「運用ルール」
ツールはルールがないとただの箱です。以下の3つをチームの「憲法」にしてください。
1. 「チケットなき変更は存在しない」: 構成変更を行う際は、必ずJiraチケットを作成し、Assetsのオブジェクトを紐付けること。
2. 「Dependency First」: 新しい資産を登録する際、必ず「何に依存しているか」を1つ以上入力すること。これが埋まっていない資産は「存在しない」ものとみなす。
3. 週次オートメーション・レビュー: 自動インポートが失敗した資産をSlackチャンネルに通知させ、金曜の夕方に「なぜ同期が切れたのか」を5分だけ確認する。
—
最後に：エンジニアが「泥臭い作業」から解放されるために
Assetsを活用すれば、障害時に「誰に連絡すればいいか」「どこから調査すればいいか」の答えが、チケットを開いた瞬間に目の前に提示されます。
「探す時間」を「直す時間」に変える。
これこそが、アジャイルのベロシティを最大化する唯一の道です。さあ、今すぐJiraのAssetsを開き、あなたのインフラを「生きた地図」に書き換えてください。
あなたのチームが、無駄な調査に追われる日々から脱却できることを確信しています。何か具体的なスキーマ設計で悩んだら、いつでも相談してください。現場の泥臭い課題こそ、設計の腕の見せ所ですから。