Issue Manager は、問題が報告されてから完了するまでのライフサイクル全体を、アクション駆動型ワークフロー メカニズムを使用して管理します。アクション駆動型ワークフローとは、問題が終端つまり終了状態に達するまで、ある状態から別の状態へとユーザーのアクションによって駆動されることを意味します。
ある状態の問題に対してアクションが実行されることで問題がライフサイクルを移動するしくみを、例を示しながら説明します。デフォルトのワークフローでは、技術サポート担当者によって報告されて入力されたばかりのソフトウェア バグは、レビュー未完了状態と見なされます。この状態は、"問題" が本当にバグであることをだれも確認していないことを意味します。QA エンジニアが状況を評価し、問題がバグであることを確認すると、問題は修正のために開発者に送ることができる状態になります。この例では、初期状態をレビュー未完了、実行されるアクションをバグとして確認、次の状態を開発準備完了とします。次の簡略化されたワークフロー図は、これらの状態とアクションを示します。
一方、同じ問題が既に Issue Manager に入力されている場合は、このレビュー未完了の問題に対して実行されるアクションは重複として指定であり、次の状態はおそらく対応完了です。したがって、このレビュー未完了の問題に対して実行されるアクションが異なると、問題が送られる次の状態が異なり、この例では対応完了になります。次の図はこれらの例を示したものです。
ワークフローには、最終状態つまりワークフローの最後の状態が少なくとも 1 つは必要です。前の図では、対応完了が最終状態です。
問題の状態に影響を与えないアクション
場合によっては、問題に対してアクションが実行された後でも、アクションが現在の状態を維持することがあります。たとえば、既存の問題の説明にコメントを追加できるコメントの追加の場合は、これに該当します。次の図では、開発者は開発準備完了状態の問題にコメントを追加しますが、問題を対応完了状態に遷移させるような動作は生じません。したがって、問題は開発準備完了状態に留まります。
Issue Manager では、各ワークフローの各状態に対して 2 つの定義済みアクションがあります。
• 再割り当てを実行すると、問題を別の受信箱に送ることができます。
• 編集を実行すると、問題の詳細ページのフィールドを変更できます。
これらのアクションを実行してもワークフロー内で問題は移動しないので、問題の現在の状態は変化しません。たとえば、Fred は休暇を取るので、レビュー未完了のバグを Diane の受信箱に再割り当てします。Diane がバグの状態を変化させるアクションを実行するまで、バグはレビュー未完了のままになります。
ワークフローでは、ある状態に対して実行できる有効なアクションのセットが定義されています。これらのアクションは、[ワークフロー] ページで確認できます。実行できるアクションは、ドロップダウン リスト ボックスで選択されている [問題の種類] と [状態] により異なります。
問題の詳細ページでは、アクションはボタンの形式で使用できます。使用できるボタン（つまりアクション）は、問題の種類と現在の状態により異なります。
この章では、問題の詳細ページに表示される各状態のボタン ラベルを定義する方法を学びます。
状態の情報は、Issue Manager のすべての場所で表示されます。たとえば、各グループと各ユーザー アカウントには、問題の種類（バグ、機能拡張、ドキュメント）ごとに 1 つ、計 3 つの初期状態が割り当てられています。
問題のライフサイクルに影響を与える初期状態
問題の初期状態は、問題を報告したユーザーがその種類の問題に関してどの程度の知識を持っているかによって異なります。たとえば、技術サポート グループのメンバがドキュメントの問題を報告した場合は、正確に評価されていて修正できる状態になっているものと考えられるので、問題には対応中ドキュメントの初期状態が割り当てられます。一方、同じメンバがソフトウェアのバグを提出した場合は、正確ではない可能性があるため、ワークフローでの初期状態はレビュー未完了になります。同じ種類の問題でも、グループが異なれば初期状態も異なる可能性があります。問題の初期状態の詳細については、「問題の初期状態」を参照してください。
ユーザーが問題を保存するとき、Issue Manager は、ユーザーに割り当てられている初期状態を基にして、問題に初期状態を自動的に割り当てます。テクニカル ライターがドキュメントの問題を記録すると、問題の詳細ページの [状態] フィールドの値は [対応中ドキュメント] になります。[状態] フィールドは自動フィールドなので、ユーザーではなく Issue Manager が、ワークフローおよび他の情報に基づいて設定します。
ワークフローの最終以外の各状態には、厳密に 1 人の所有者がいます。所有者とは組織内のロールの 1 つで、特定の状態にある問題の対処を担当します。レビュー未完了のバグについて考えると、レビュー未完了のソフトウェアの問題を確認または拒否するのは、通常は、QA ロールを実行する人物です。したがって、レビュー未完了のバグの状態の所有者は QA ロールです。
ワークフローの最終状態には、所有者はいません。これは、この状態の問題には、アクションを実行する担当者は必要ないからです。
Issue Manager では、最終以外の状態の所有者を、次の 4 つの候補から選択します。
• QA
• 開発
• ドキュメント
• 機能拡張
状態の所有者は、特定の QA エンジニアや特定の受信箱ではないことに注意してください。また、特定の製品、コンポーネント、リリース、またはプラットフォームとも関係ありません。状態の所有者は、ある状態に関する機能的な責任を一般的に指定するものです。
状態に所有者が必要な理由状態の所有者とルーティング ルールの組み合わせによって、問題を受け取る特定の受信箱が決まるので、所有者は、状態の重要なプロパティです（ルーティング ルールについては「ルーティング ルールのセットアップ」を参照）。ここでは、Issue Manager がルーティング ルール、状態、および状態の所有者を使用して、特定の受信箱に問題を移動する様子を例として示します。
特定の製品やコンポーネントなどに関係なく、すべてのソフトウェア バグのレビュー未完了状態の所有者を QA ロールにするとします。このロールのユーザーは、報告された問題が実際にバグであることを確認します。そのため、レビュー未完了状態の [状態のプロパティ] ダイアログで、[QA がこの状態を所有] ラジオ ボタンを選択します。この [状態のプロパティ] ダイアログにアクセスするには、[設定｜ワークフロー] を選択し、[状態の編集] ボタンをクリックします。
次に、特定の製品に対するルーティング ルールについて考えます。ルーティング ルールをセットアップする場合は（[設定｜ルーティング ルール]）、製品、コンポーネント、リリース、およびプラットフォームの組み合わせごとに 4 つの特定の受信箱を指定します。4 つの状態所有者ラジオ ボタンはそれぞれ、[ルーティング ルール] ページの 4 つの受信箱、つまり [QA用受信箱]、[開発用受信箱]、[機能拡張用受信箱]、および [ドキュメント用受信箱] に対応します。
例：任意のプラットフォームのProduct C の任意のリリースのEmail コンポーネントにバグが関係している場合は、そのバグを受信箱 Mike - QA、Sonja - Dev、Dan - Dev (Product C)、または Judy - Doc のいずれかに送ることを、ルーティング ルールに記述します。
問題の現在の状態とその状態の所有者という 2 つの要素に基づいて、4 つの受信箱から 1 つが選択されます。バグの現在の状態がレビュー未完了で、QA ロールがレビュー未完了の問題を所有するものと指定されている場合は、問題は自動的に Mike の受信箱 Mike - QA に送られます。
Mike がこの問題に対処すると、実際には、彼は、ライフサイクルに従ってこの問題を別の状態（別の所有者を持つ）に移動します。Issue Manager は、再び、この問題の現在の状態、その状態の所有者、および特定の製品、コンポーネント、リリース、プラットフォームに該当するルーティング ルールに基づいて、適切な受信箱を決定します。
この章では、ワークフローの各状態に対する状態所有者を定義する方法について学びます。
Issue Manager は理由コードをサポートします。これは、特定のアクションが実行されたときに問題の状態が変化した理由を説明する、省略可能でカスタマイズ可能なキーワードです。
理由コードは情報を提供するものです。前の例で示されているように、異なるアクションによって問題が同じ状態に移動する場合があります。たとえば、問題が完了するには、再現不能、重複、非バグなどさまざまな理由があります。理由コードによって追加情報が提供されないと、ユーザーは問題のライフサイクルを完全に把握できません。
理由コードは、ワークフローの状態数をできる限り少なくするのにも役立ちます。たとえば、複数の最終状態（非バグ、再現不能、重複）を定義する代わりに、対応完了という名前の最終状態を 1 つ用意して、問題が完了した理由を示すさまざまな理由コードと組み合わせれば十分です（たとえば、対応完了/非バグ）。
理由コードは、問題の詳細ページおよびアクション ダイアログに表示されます。たとえば、テクニカル ライターの Judy が、ドキュメントの問題を自分の受信箱で受け取ったとします。説明を読んだ彼女は、問題が既に報告されていたことを思い出します。そして、その問題に重複の印を付けます。[重複として指定] ダイアログを開くと、Issue Manager が問題を対応中ドキュメントから対応完了/重複に移動していることがわかります。対応完了が新しい状態で、重複は理由コードです。
次回この問題の詳細ページを開いたときには、Issue Manager が状態と理由コードを設定します。
特定のアクションが実行されると、Issue Manager は理由コードをそのアクションに割り当てて、問題を新しい状態に渡します。それ以降のアクションでは、その理由コードをクリアするか、または単にその理由コードを維持します。一般に、いったん設定された理由コードは、ワークフローの最終状態に達するまで問題と共に移動します。
開発者がバグを解決した後に、解決アクションを実行してバグが解決されたことを主張する場合について考えます。このアクションにより、バグは開発準備完了からQA 準備完了に移動し、理由コードには解決が設定されます。開発者の主張を検証する QA エンジニアは、検証アクションを実行してバグ修正を承認します。このアクションにより解決理由コードは維持され、バグと共に対応完了状態に移動します。次の図は、このワークフローを示したものです。
ただし、たとえば問題が最終状態に向かって先に進むのではなくワークフローの前の状態に戻るような場合は、理由コードをクリアできます。たとえば、QA エンジニアが開発者の主張に異議を唱えて却下アクションを実行すると、問題は開発準備完了却下アクションに対しては理由コードをクリアできます。次の部分的なワークフローは、この部分を示しています。
理由コードが、割り当てられるか、クリアされるか、維持されるかは、[状態 "<状態名>" のアクションの新規作成] ダイアログの設定で決まります。このダイアログについては、「理由コード」で説明します。[状態 "<状態名>" のアクションの新規作成] ダイアログを表示するには、[設定｜ワークフロー] を選択し、[アクションの追加] ボタンをクリックします。
理由コードが必要な状態
一般に、開発者が対処するすべての状態には理由コードを割り当てる必要があります。最終状態の場合は、それ以前の状態で理由コードが割り当てられているはずなので、理由コードを割り当てません。
この章の後半で、ワークフローの状態と、特定の状態に対して実行できるアクションを定義するときに、理由コードをセットアップする方法を学びます。