Jira のカスタム フィールドを効率的に管理する
概要
カスタム フィールドを設定する機能を活用することで Jira を強力なワークフロー管理ツールとして使い、組織の作業をモデル化する非常に具体的なオブジェクトを作成できます。ただし、設定が多すぎる場合、Jira のパフォーマンスと管理に影響を与える可能性があります。ここでは、カスタム フィールドが Jira のパフォーマンスに与える影響について説明し、カスタム フィールドを適切に使用して最適化するための推奨事項について説明します。
カスタム フィールドの数が多すぎるとインスタンスの速度が低下する可能性がある
カスタム課題の詳細 (課題の表示、検索、作成/編集、およびコメントの追加) をリクエストまたは処理する操作の応答時間は、Jira のカスタム フィールドの絶対数の影響を受けます。Jira 7.7 のスケール テストでは次のような点が明らかになっています:
図 1: 操作当たりの平均応答時間 (ミリ秒単位): カスタム フィールド テスト |
カスタム フィールドが 1400 と 2800 の Jira インスタンスにおいて異なるユーザー操作をテスト1すると、後者には、コメントの追加、課題の作成、および課題の編集に対する応答時間に大きな違いがあります。ユーザーが Jira で費やす時間のほとんどがこれらの 3 つの操作であることを考慮すると、Jira インスタンスでカスタム フィールドの数に注目する必要があることは明らかです。
また、他の 8 つの Jira インスタンスで一連の同じユーザー操作をテストし、さまざまなデータ ポイントを検証しました。次のテーブルは、各テストのすべての操作に対する、すべての平均応答時間の集計を示しています。
図2: すべての操作の平均応答時間の集計 (ミリ秒): カスタム フィールド テスト |
このグラフでは、テストを実施した 8 つのデータ ポイントにおいて、カスタム フィールドの数が平均応答時間に大きな影響を与えていることがわかります。
使用していないカスタム フィールドの特定とクリーンアップ
インスタンス内のカスタム フィールドの増加を抑えるには、3 つの方法があります。
- 使用していないカスタム フィールドの削除。
- ほとんど使用されていないカスタム フィールドのマージ。
- Limit the scope of the custom fields to specific projects context.
カスタム フィールドを削除または統合する前にビジネス オーナーと話し合い、変更を本番環境にロールアウトする前に QA 環境でテストするようにしてください。このプロセスには非常に時間がかかりますが、重要なデータを誤って失わないように特に注意する必要があります。
カスタム フィールドの範囲を制限する
For any custom fields that can't be removed or merged safely, you can limit their scope to the context of specific projects. This helps by:
- Reducing the index size (Jira Data Center search indexing)
- Lowering computation complexity
- Reducing the work done by other nodes in the cluster during replication
カスタム フィールドの用途
Jira Data Center 8.16 以降では、[カスタム フィールド] ページには、カスタム フィールドの使用状況 (実際に使用している課題の数と、最後に値がいつ作成されたかなど) を示す新しい列が表示されます。これらの列を基準に並べ替えたりフィルターを追加して値を更新したりして、適切な削除候補をすばやく見つけられます。詳細については「カスタム フィールドの使用状況を分析する」をご参照ください。
Jira に組み込みのカスタム フィールドの最適化ツール
Jira に組み込みのカスタム フィールドの最適化ツールを使用して、カスタム フィールドのクリーン アップ プロセスを開始できます。この機能では、インスタンスのカスタム フィールドをスキャンして、最適化可能なフィールドをハイライト表示します。詳細は、「カスタム フィールドの最適化」を参照してください。
SQL データベース クエリ
ご利用の Jira インスタンスのカスタム フィールドの詳細を確認したい場合、次の SQL クエリを使用できます。
Atlassian Marketplace plugins to identify/remove custom fields
Jira コマンド ライン インターフェイス (CLI): 組み込みの 'removeCustomField' 関数を含みます
Configuration Manager for JIRA: カスタム フィールドの競合の特定や解決に適しています。詳細は、「Duplicate Custom Fields (Botron Software のサイト)」を参照してください。
Admin Tools for JIRA: 使用中のカスタム フィールドを特定してカスタム フィールドをクローンすることができます。
- Cleaner for JIRA: カスタム フィールドやそれらの使用状況を一覧表示し、必要に応じて削除できます。
- Custom Fields Usage for JIRA: カスタム フィールドを名前、タイプ、および説明とともに表示できます。課題で設定されたことがないカスタム フィールドを確認してワンクリックで削除することもできます。
カスタム フィールドに関するガバナンスのセットアップ
未使用またはほとんど使用しないカスタム フィールドを特定してインスタンスから正常に削除 (またはマージ) したら、インスタンスで新しいカスタム フィールドを作成するためのルールとガイドラインを設定します。これは、インスタンスのパフォーマンスに影響を与えない、制御されたアプローチの確立に役立ちます。Jira カスタマイズのガバナンスの確立は、インスタンスの成長とユーザーのニーズに対応するための性能面のバランスを取る際に役立ちます。
その他の注意事項:
新しいカスタム フィールドのリクエストを評価する: ユーザーが新しいカスタム フィールドを作成する際にリクエストの必要性を検証するためのプロセスを確立します。ユーザーと会話してフィールドの要件を解釈し、既存のフィールドを再利用できないかどうか、また、フィールドが本当に必要かどうかを検討します。
新しいカスタム フィールドの目的を検証する: 各フィールドで取得された情報が正当な目的を果たすようにします。課題やレポートに使用されないデータは、必要ありません。四半期に一度、または組織に最適な頻度で、実際に使用されているカスタム フィールドの数を追跡します。
ガバナンス ポリシーの確立と共有: カスタム フィールド、ワークフロー、および他のカスタマイズなどの新しいオブジェクトを Jira に追加する方法を確立する、わかりやすく明確な一連のルールを作成します。
エグゼクティブの支持を得る: 組織内の関係するマネージャーやエグゼクティブとガバナンス ポリシーを共有し、Jira をスムーズに実行し続けるための意志統一を図ります。事実を整理して、ポリシーを立証し、不十分なガバナンスがインスタンスのパフォーマンス、ひいてはエンドユーザーに与える影響を示せるようにします。この記事のテスト結果を表示することもできます。
その他の推奨事項
カスタム フィールドを管理するための推奨事項と非推奨事項を以下にまとめました。
推奨事項
- 可能な場合は既存のフィールドを再使用する
- 汎用的なフィールド名を使用する
- カスタム フィールドにわかりやすい説明を追加する (有効な値の例を含む)
- カスタム フィールドに一貫性のある書式を適用する (大文字と小文字など)。可能であれば、Jira の既定と統一されるようにします
- カスタム フィールドの末尾にスペースなどの非表示の文字が追加されないように注意する。これがあると、スクリプトの使用が困難になります
- 柔軟性の面での考慮。たとえば、複数選択フィールドは、単一選択フィールドよりも柔軟です
- 異なる言語パックを使用しているユーザーのためにカスタム フィールド名を翻訳する
- カスタム フィールド コンテキストの使用方法とタイミングを把握する
- フィールドはどこですか? 機能を使用して、見つからないフィールドを追跡する
- ガバナンス ポリシーを使用し、ユーザーやエグゼクティブが見つけやすくする
- カスタム フィールドのコンテキストを適切に使用する。たとえば、カスタム フィールドが 1 つのプロジェクトでのみ使用されている場合、グローバル コンテキストの使用を避けます
- 可能な場合は、カスタム フィールドに既定値 を設定しない
- ドロップダウン リストを使用するカスタム フィールドを作成する際は、オプション数を最小限に抑える
非推奨事項
- 名前が重複したカスタム フィールドを作成しないでください。管理ミス、レポートの問題、カスタム スクリプトのエラーにつながる可能性があります
- 頻繁に更新が必要なオプション フィールドは作成しないでください。たとえば、ユーザー名が入った選択リストは、ユーザーの役割が変わるとすぐに古くなってしまいます
- Don’t add the option value None. This option already exists when the field is made optional and adding it to the list makes reporting harder.
参考
カスタム フィールドをより効果的に管理するためのアドバイスについては、Matt Doar による「Practical JIRA Administration: Using JIRA Effectively: Beyond the Documentation」をご参照ください。
この記事で使用したデータ ポイントは、さまざまなバージョンの Jira での一連の拡張テストの一部として収集されました。これらのテストのハードウェア、結果、および方法の詳細については、Scaling Jira 7.7 を参照してください。
Atlassian が提供するサービス
This article features advice typically provided by Atlassian Technical Account Managers to customers when custom field use starts affecting performance. Technical Account Managers can provide strategic guidance to help you choose the right methods to manage your custom fields or even mitigate other performance problems.
Atlassian のプレミア サポート チームは、お客様のアプリケーションのデプロイメントがユーザーのニーズを完全に満たしていることを確認するためにヘルス チェックを実行し、アプリケーションとログを慎重に分析します。ヘルス チェックでパフォーマンスのギャップが判明した場合、プレミア サポートがお客様のインスタンスで実施可能な変更を提案いたします。