Jiraの完了の定義：「終わった」の意味を合意する

エンジニアが変更を終え、Jira課題を次に進めます。テスターは新しい画面が動く一方で、既存の操作が壊れていると気づきます。サポートは困惑した顧客から変更を知ります。全員が「終わった」と言っていましたが、その意味は違っていました。

完了の定義は、チームに共通の完了基準を与えます。作業開始前に期待する品質確認を見える化し、誰が適切な質問を思い出すかにレビューが左右されにくくします。

このガイドでは架空の顧客ポータルチームを例に、共通の品質確認と機能固有の受け入れ条件を区別し、Power PackのDefinition of Done & ACを使って両方をJira課題に置きます。

完了の定義とは？

スクラムガイドは完了の定義を、インクリメントが満たすべき品質基準として説明しています。完成した作業について共通理解を作るものです。組織に基準がある場合、それがスクラムチームの最低限の基準になります。公式スクラムガイドを参照してください。

この実践例では、関連する変更すべてにチームが問う少数の質問と考えてください。実装はレビューされたか。合意した検証を通ったか。変更をサポートするための情報はそろっているか、といったものです。

具体的な質問は製品とリスクに依存します。公開の顧客ポータル、社内レポート、安全性が極めて重要なシステムでは必要な基準が違います。他チームのリストを議論せずコピーすると、重要な穴が残り、無意味な作業が増えることがあります。

役立つ基準は観察できる結果を示します。「高品質」は目標です。「合意した回帰確認を通り、結果がJira課題からリンクされている」は、レビュー担当者が調べられる状態です。

共通の品質と機能の動作を分ける

架空のチームは通知設定を追加しています。顧客は週次サマリーメールをオンまたはオフにできます。重要なアカウントメッセージは、この設定の対象外です。

この機能には固有の受け入れ条件が必要です。例えば保存した選択が、ログアウトして戻った後も表示されることです。顧客が体験すべき動作を示すため、この機能の条件に属します。

完了の定義は、より広い完成基準を扱います。実装レビュー、影響を受ける既存動作の確認、サポート案内の更新は、多くの異なる変更に適用できます。

両方のリストが重要です。要求通りに動く機能でも、必要な品質作業が欠けているかもしれません。同様に、コードレビューと回帰確認を通っただけでは、依頼された機能が正しく動くと証明できません。

チームが実際に経験している不足から始める

製品を作る人、検証する人、支える人で短く話します。完成したと思ったのに予期せぬ追加対応が必要になった最近の例を使います。

このポータルチームは3つの繰り返し起きる問題を挙げます。レビューの指摘が未解決のことがある。既存のアカウント設定の回帰確認が少ない。機能が利用可能になってからサポート手順が届く、という問題です。

これらの問題から有用なチェックが見えてきます。また、基準を短くする理由にもなります。各項目は認識できる失敗を防ぐか、必要な品質状態を確立するべきだからです。

提案した項目をどう検証するか聞きます。誰も根拠を説明できないなら、採用前に表現を改善します。「文書化完了」はリリースノート、社内設計メモ、顧客向けヘルプのどれかもしれません。必要な情報と置き場所を合意します。

通常誰が確認するかも決めます。いつもの計画の中で話せます。チェックリストだけでは担当者の割り当てや予定の確保は行われません。

実用的な共通リストを作る

以下はポータルチームの初稿です。説明用の作業上の合意であり、普遍的な基準ではありません。

• 実装レビューが完了し、対応必須の指摘が解決している。
• 課題で合意した受け入れ条件を検証している。
• 影響するアカウント操作の、合意した回帰確認を通っている。
• 変更した画面の、合意したアクセシビリティ確認を通っている。
• サポート案内が変更後の顧客向け動作を反映している。
• 検証結果と関連レビューへのリンクがJira課題に記録されている。

使う前に、回帰確認とアクセシビリティ確認の内容を書き出します。そうしないと、2人が異なる作業をした後に同じ項目へチェックを入れる可能性があります。

このポータルの回帰確認には、ログイン、アカウント設定の表示、既存プロフィール項目の更新が含まれます。変更した操作部品のアクセシビリティ確認には、キーボード操作、見えるフォーカス、分かりやすいラベルが含まれます。これはチームが選んだ確認の例であり、完全なアクセシビリティ基準ではありません。

サポート項目にも実践的な解釈が必要です。顧客への影響がない変更なら、その種の仕事に適した基準を前もって作ります。リストを緑にするためだけにレビュー担当者が例外を即興で作る状況は避けます。

Jira課題に基準を追加する

対象のJira課題を開き、Power PackのDefinition of Done & ACカードを探します。Acceptance CriteriaとDefinition of Doneが別々のタブにあります。共通のチェックを加える前にDefinition of Doneを選択します。

少数ならタイトルを入力し、Addを押すかEnterキーを使います。各タイトルは一つの確認可能な条件に絞ります。無関係な3つの確認を長い一文にまとめると、部分的な完了を表しにくくなります。

Bulk Importを選び、Markdownリストを貼り付けることもできます。例えば上の6項目を、各行の先頭にハイフンとスペースを付けて貼ります。通常のMarkdownチェックボックスも使えます。

インポートは選択中のタブに項目を追加します。確定前にタブを確認し、取り込み後にリストを点検します。同じ内容を再度取り込むと既存の項目を追加することがあるので、再読み込みとして使わず、意図して実行します。

未検証の仕事には未チェックの項目を使います。チェック済みのMarkdownは完了として取り込まれます。以前の課題からコピーしたチェックは、今回の変更の確認の代わりになりません。

合意した基準は、各課題に手動で入れる必要があります。普段のチーム文書に原本を置き、新しい課題へ必要な確認を貼り付けます。これは運用上の習慣であり、中央の基準と各課題が自動連動する仕組みではありません。

実際のレビューをたどる

通知設定の機能がレビュー可能になったとします。Mayaは顧客向けの結果を確認し、Priyaは合意した回帰確認を行います。Leoは残りの実装レビュー指摘を解決して記録をリンクします。

最初の確認で、設定は保存できるものの、Saveを選ぶとキーボードフォーカスが消えることが分かります。チームはアクセシビリティ項目を未完了にし、通常のJira上の議論で問題を記録し、修正後に該当の確認を繰り返します。

サポート案内も未完成です。機能固有の受け入れ条件が完了していても、その不足は見えたままです。別々のリストによって、まだ仕事が残る理由を説明できます。

実際に確認に合格してからDoneボタンを選びます。新しい情報で未完了に戻すべきなら再度選びます。テスト結果、レビューへのリンク、重要な決定は通常のJiraや文書化の運用で残します。

完了項目はチームの判断を記録します。確認の実行、証拠の収集、検証者の特定は行いません。誰がいつ確認したかが重要なら、普段のレビュー記録に明示します。

準備状況の表示を正しく読む

各タブには完了数と総数が表示されます。両方のリストに1件以上の項目があり、両方の全項目が完了した場合だけReady for Releaseになります。それ以外はIn Verificationです。

この規則により未完了項目を見つけやすくなります。また、Definition of Doneを完了してもAcceptance Criteriaが空なら全完了にならない理由も分かります。

この文言はチェックリストの状態の要約です。確認が十分だったこと、根拠が説得力を持つこと、安全にリリースできることを証明しません。役立つ項目も、不適切な項目も、同じように完了にできます。

チェックリストはJiraの状態遷移やプルリクエストのマージも止めません。そうした判断には引き続き通常の開発・リリース手順を使います。

仕事の変化に合わせて基準を役立つものに保つ

繰り返す不具合から不足が分かったとき、製品が大きく変わったとき、既存の確認が有用な情報を生まなくなったときに基準を見直します。

例えば設定の変更が直後には動くのに、遅延した同期の後で失われることがあるかもしれません。そこから非同期処理に依存する機能向けの、より広い確認ルールを作れます。まず適用する変更と成功の根拠を決めます。

原本を更新し、進行中の仕事への反映を話し合います。既存の課題リストには自動で引き継がれません。影響する課題を確認し、必要な新しい項目を手動で追加します。

一度の失敗ごとにリストを増やさないようにします。個別の受け入れ条件、明確な実装タスク、レビュー方法の変更が適している場合もあります。共通基準はチームが理解し、実際に適用できるものに保ちます。

現在の課題で試す

レビューが近い課題を選びます。短い共通の品質基準を合意してDefinition of Doneに置き、その課題固有の顧客向け結果をAcceptance Criteriaに追加します。

一緒に確認を進め、普段記録する場所の根拠をリンクします。検証後にのみ完了にし、残る仕事は通常の作業手順で確認します。

得られるのは、より明確な会話です。通知設定の変更が終わったと言うとき、どの結果が動き、どの品質確認に合格し、何に基づいて判断したかを説明できます。

• スクラムガイド — 完了の定義