Jira のカスタム フィールドを効率的に管理する

概要

カスタム フィールドを設定する機能を活用することで Jira を強力なワークフロー管理ツールとして使い、組織の作業をモデル化する非常に具体的なオブジェクトを作成できます。ただし、設定が多すぎる場合、Jira のパフォーマンスと管理に影響を与える可能性があります。ここでは、カスタム フィールドが Jira のパフォーマンスに与える影響について説明し、カスタム フィールドを適切に使用して最適化するための推奨事項について説明します。

カスタム フィールドの数が多すぎるとインスタンスの速度が低下する可能性がある

カスタム課題の詳細 (課題の表示、検索、作成/編集、およびコメントの追加) をリクエストまたは処理する操作の応答時間は、Jira のカスタム フィールドの絶対数の影響を受けます。Jira 7.7 のスケール テストでは次のような点が明らかになっています: 

図 1: 操作当たりの平均応答時間 (ミリ秒単位): カスタム フィールド テスト

カスタム フィールドが 1400 と 2800 の Jira インスタンスにおいて異なるユーザー操作をテスト1すると、後者には、コメントの追加課題の作成、および課題の編集に対する応答時間に大きな違いがあります。ユーザーが Jira で費やす時間のほとんどがこれらの 3 つの操作であることを考慮すると、Jira インスタンスカスタム フィールドの数に注目する必要があることは明らかです。 

また、他の 8 つの Jira インスタンスで一連の同じユーザー操作をテストし、さまざまなデータ ポイントを検証しました。次のテーブルは、各テストのすべての操作に対する、すべての平均応答時間の集計を示しています。


図2: すべての操作の平均応答時間の集計 (ミリ秒): カスタム フィールド テスト

このグラフでは、テストを実施した 8 つのデータ ポイントにおいて、カスタム フィールドの数が平均応答時間に大きな影響を与えていることがわかります。 

使用していないカスタム フィールドの特定とクリーンアップ

インスタンス内のカスタム フィールドの増加を抑えるには、3 つの方法があります。

  1. 使用していないカスタム フィールドの削除。 
  2. ほとんど使用されていないカスタム フィールドのマージ
  3. 特定のプロジェクト コンテキストに対するカスタム フィールドの範囲の制限 

カスタム フィールドを削除または統合する前に、ビジネス オーナーと話し合い、変更を本番環境に適用する前に QA 環境でテストするようにします。これは時間のかかるプロセスですが、重要なデータを誤って失わないように注意する必要があるためです。

tip/resting Created with Sketch.

カスタム フィールドの範囲を制限する

安全に削除またはマージできないカスタム フィールドについては、特定のプロジェクトのコンテキスト範囲を制限できます。これには次のような効果があります。

  • インデックス サイズを小さくする (Jira Data Center の検索インデックス)
  • 計算の複雑度を下げる
  • レプリケーション中にクラスター内の他のノードで実行される作業を減らす

Jira's built-in custom fields optimizer

You can start the process of cleaning up your custom fields through Jira's built-in custom fields optimizer. This feature lets you scan your instance's custom fields and highlight the ones you can optimize. See Optimizing custom fields for more information.

SQL データベース クエリ

If you need to take a more detailed look at your Jira instance's custom fields, use the following SQL queries.


使用していないカスタム フィールド

このクエリは、プラグインで実装されるカスタム フィールドも返します。それらのカスタム フィールドは独自のデータストアを使用している可能性があります。実際に削除や変更を行う前に、ビジネス オーナーにこれらのカスタム フィールドを確認してもらうことをおすすめします。

select count(*), customfield.id, customfield.cfname, customfield.description
from customfield left join customfieldvalue on customfield.id = customfieldvalue.customfield
where customfieldvalue.stringvalue is null 
and customfieldvalue.numbervalue is null 
and customfieldvalue.textvalue is null
group by customfield.id, customfield.cfname, customfield.description;
ほとんど使用されていないカスタム フィールド

このクエリは、使用回数が 5 回未満のすべてのカスタム フィールドを返します。

select customfield.id, count (*)
from customfield left join customfieldvalue on customfield.id = customfieldvalue.customfield
group by customfield.id having count (*) < 5
order by count (*) desc
日付 (YYYY-MM-DD) より後に更新されていないカスタム フィールド

このクエリは Agile、Service Desk、Capture、および Portfolio のフィールドを除外します。

select field.id, field.cfname from customfield field where field.cfname not in (
select item.field from changeitem item
JOIN changegroup cgroup ON item.groupid=cgroup.id
where item.fieldtype='custom' and cgroup.created > 'YYYY-MM-DD'
) and customfieldtypekey not like '%com.pyxis.greenhopper%'
and customfieldtypekey not like '%com.atlassian.servicedesk%'
and customfieldtypekey not like '%com.atlassian.bonfire%'
and customfieldtypekey not like '%com.atlassian.jpo%'
カスタム フィールドに関するユーザー アクティビティ

このフィールドは完全なカスタム フィールド ID (例: customfield_10301) を使用します。

select id, entitytype, entityid, username, to_timestamp(lastviewed/1000) as lastviewed, data from userhistoryitem 
where entityid='customfield_10001'
order by lastviewed desc;
すべての「リストを選択」カスタム フィールド
select * from customfield 
where customfieldtypekey = 'com.atlassian.jira.plugin.system.customfieldtypes:select';
"カスタム フィールド名" またはカスタム フィールド ID "10001" を含むフィルタ
select * from searchrequest where reqcontent like '%Field Name%' or reqcontent like '%10001%';
カスタム フィールドを参照するワークフロー

このフィールドは完全なカスタム フィールド ID (例: customfield_10301) を使用します。

select * from jiraworkflows wf where wf.descriptor like '%customfield_10301%';
スクリーン/ワークフロー/通知スキームを持たない、コンテキストを持つ計算対象外のフィールド (値なし)
SELECT
cf.id id,           
to_char(min(ji.created), 'YYYY/MM/DD'),
to_char(max(ji.updated), 'YYYY/MM/DD'),
count(distinct(ji.id))
FROM CUSTOMFIELDVALUE cfv
left join JIRAISSUE ji
on cfv.ISSUE = ji.id            
left join CUSTOMFIELD cf
on cf.id = cfv.customfield            
GROUP BY cf.id
ORDER BY cf.id
スクリーン/ワークフロー/通知スキームを持たず、コンテキストを持つ計算対象外のフィールドで、画面に関連づけられているもの
SELECT
cf.id id,           
to_char(min(ji.created), 'YYYY/MM/DD'),
to_char(max(ji.updated), 'YYYY/MM/DD'),
count(distinct(ji.id))
FROM CUSTOMFIELDVALUE cfv
left join JIRAISSUE ji
on cfv.ISSUE = ji.id            
left join CUSTOMFIELD cf
on cf.id = cfv.customfield            
GROUP BY cf.id
ORDER BY cf.id

カスタム フィールドを特定/削除できる Atlassian Marketplace プラグイン

カスタム フィールドに関するガバナンスのセットアップ

未使用またはほとんど使用しないカスタム フィールドを特定してインスタンスから正常に削除 (またはマージ) したら、インスタンスで新しいカスタム フィールドを作成するためのルールとガイドラインを設定します。これは、インスタンスのパフォーマンスに影響を与えない、制御されたアプローチの確立に役立ちます。Jira カスタマイズのガバナンスの確立は、インスタンスの成長とユーザーのニーズに対応するための性能面のバランスを取る際に役立ちます。

その他の注意事項:

新しいカスタム フィールドのリクエストを評価する: ユーザーが新しいカスタム フィールドを作成する際にリクエストの必要性を検証するためのプロセスを確立します。ユーザーと会話してフィールドの要件を解釈し、既存のフィールドを再利用できないかどうか、また、フィールドが本当に必要かどうかを検討します。 

新しいカスタム フィールドの目的を検証する: 各フィールドで取得された情報が正当な目的を果たすようにします。課題やレポートに使用されないデータは、必要ありません。四半期に一度、または組織に最適な頻度で、実際に使用されているカスタム フィールドの数を追跡します。

ガバナンス ポリシーの確立と共有: カスタム フィールド、ワークフロー、および他のカスタマイズなどの新しいオブジェクトを Jira に追加する方法を確立する、わかりやすく明確な一連のルールを作成します。 

エグゼクティブの支持を得る: 組織内の関係するマネージャーやエグゼクティブとガバナンス ポリシーを共有し、Jira をスムーズに実行し続けるための意志統一を図ります。事実を整理して、ポリシーを立証し、不十分なガバナンスがインスタンスのパフォーマンス、ひいてはエンドユーザーに与える影響を示せるようにします。この記事のテスト結果を表示することもできます。

その他の推奨事項

カスタム フィールドを管理するための推奨事項と非推奨事項を以下にまとめました。

推奨事項

      • 可能な場合は既存のフィールドを再使用する
      • 汎用的なフィールド名を使用する
      • カスタム フィールドにわかりやすい説明を追加する (有効なの例を含む)
      • カスタム フィールドに一貫性のある書式を適用する (大文字と小文字など)。可能であれば、Jira の既定と統一されるようにします
      • カスタム フィールドの末尾にスペースなどの非表示の文字が追加されないように注意する。これがあると、スクリプトの使用が困難になります
      • 柔軟性の面での考慮。たとえば、複数選択フィールドは、単一選択フィールドよりも柔軟です
      • 異なる言語パックを使用しているユーザーのためにカスタム フィールド名を翻訳する
      • カスタム フィールド コンテキストの使用方法とタイミングを把握する
      • フィールドはどこですか? 機能を使用して、見つからないフィールドを追跡する
      • ガバナンス ポリシーを使用し、ユーザーやエグゼクティブが見つけやすくする
      • カスタム フィールドのコンテキストを適切に使用する。たとえば、カスタム フィールドが 1 つのプロジェクトでのみ使用されている場合、グローバル コンテキストの使用を避けます 
      • 可能な場合は、カスタム フィールドに既定値 を設定しない
      • ドロップダウン リストを使用するカスタム フィールドを作成する際は、オプション数を最小限に抑える 

非推奨事項

      • 名前が重複したカスタム フィールドを作成しないでください。管理ミス、レポートの問題、カスタム スクリプトのエラーにつながる可能性があります
      • 頻繁に更新が必要なオプション フィールドは作成しないでください。たとえば、ユーザー名が入った選択リストは、ユーザーの役割が変わるとすぐに古くなってしまいます 
      • オプション値 なし を追加しないでください。この値はフィールドがオプションとして作成されるタイミングで既に存在しているため、リストに追加するとレポートが困難になります


参考

カスタム フィールドをより効果的に管理するためのアドバイスについては、Matt Doar による「Practical JIRA Administration: Using JIRA Effectively: Beyond the Documentation」をご参照ください。

この記事で使用したデータ ポイントは、さまざまなバージョンの Jira での一連の拡張テストの一部として収集されました。これらのテストのハードウェア、結果、および方法の詳細については、Scaling Jira 7.7 を参照してください。

Atlassian が提供するサービス

この記事では、カスタム フィールドの使用がパフォーマンスに影響を与え始めている際に Atlassianテクニカル アカウント マネージャーがお客様に提供する一般的なアドバイスについて説明します。テクニカル アカウント マネージャーは、お客様のカスタム フィールドの管理や他のパフォーマンスの問題の軽減を支援する、戦略的ガイダンスを提供します。

Atlassian のプレミア サポート チームは、お客様のアプリケーションのデプロイメントがユーザーのニーズを完全に満たしていることを確認するためにヘルス チェックを実行し、アプリケーションとログを慎重に分析します。ヘルス チェックでパフォーマンスのギャップが判明した場合、プレミア サポートがお客様のインスタンスで実施可能な変更を提案いたします。

最終更新日: 2019 年 9 月 30 日

この内容はお役に立ちましたか?

はい
いいえ
この記事についてのフィードバックを送信する
Powered by Confluence and Scroll Viewport.