あなたはプロジェクト マネージャーで、チームが次のスプリントに着手しようとしています。しかし、チームが取り組むタスクの準備は整っていますか?

これを判断するには、DoR (準備完了の定義) が必要であり、アジャイル プロジェクト管理には欠かせません。DoR によって、チームが効果的にタスクに取り組めるようになります。また、チームのバックログ リファインメントにも役立ちます。

本ページでは、スクラムやアジャイル アプローチにおける「準備完了の定義」を細かく分けて、タスクがその基準を満たしているかどうかを判断する方法をご説明します。

DoR（準備完了の定義）により、チームが作業を開始する前に作業を評価できます。DoR では、チームのタスク、ユーザー ストーリー、またはストーリー ポイントを定義します。スクラム アプローチを利用する場合、DoR とはすぐに行動を起こせるということです。プロジェクト開始前に、チームは次の内容を把握する必要があります。

• ターゲットにする顧客：顧客のモチベーション、問題点、ニーズは何か？

• プロジェクトの目標：プロジェクトの目的は何か？

• 必要なタスク：ビジネス、ユーザーの双方にとって価値があるタスクか？明確で実現可能であるか？

• 技術要件：必要なリソースは揃っているか？チームは技術的なアプローチや解決策を把握しているか？それをテストできるか？

• 時間の見積もり：業務完了までのタイムラインは？関係者とチームは終了日に関して合意しているか？

• 「完了」の定義（DoD）：DoD（完了）の状態とは？成功を評価するために、どのスクラム指標を利用する予定か？

チームがプロジェクトのスコープを把握して初めて、作業を製品バックログから行動に移せます。作業の準備が整っているかどうかは、全員一致で合意する必要があります。そうすれば、チームのワークロードに関するやり取りを削減できます。

DoR には考慮すべき重要な要素が 6 つあります。これらの要素は、アジャイル計画に役立ちます。これらの要素の通称は INVEST メソッドといい、以下を意味します。

独立している（Independent）

取り組んでいるバックログ項目が何であれ、他のタスクに依存してはいけません。自己完結型である必要があります。チームはこの方法で不要な作業を回避します。

交渉できる（Negotiable）

タスクは強硬であってはいけません。チームがもたらす可能性のある他のオプションを検討できるだけの柔軟性が必要です。

価値がある（Valuable）

作業には目的が必要です。さらに重要なのは、製品、顧客、ビジネスに付加価値を提供する必要があるということです。

予測できる（Estimable）

タスクは、実現可能、達成可能、測定可能である必要があります。チームは、どれほどの時間と労力が必要となるかを把握する必要があります。スプリントに複数のタスクが必要な場合、それぞれについても同様です。

小

作業を管理しやすくする必要があります。タスクが複雑な場合は、より小さなタスクに分割します。それにより、不当な締め切りを守るための、徒労や過度な作業を防ぎます。そうすれば、チームは燃え尽きることはありません。

テストできる（Testable）

ビジネスとユーザーのニーズに基づいて、成功基準と完了基準を指定します。この基準により、チームはタスクが完了したかどうかを評価できます。

明確な DoR により、あなたやチーム、関係者に自信を与え、期待値を設定します。

企業にとって DoR が不可欠な理由は次のとおりです。

• コミュニケーションを強化する：DoR は、タスクの作業準備が整っているかどうかについて、チームがより円滑にコミュニケーションするのに役立ち、混乱や遅延を最小限に抑えます。

• 効率を向上する：DoR により、チーム・メンバーが技術要件をしっかりと把握し、迅速に作業を進めることができるため、チームはタスクを効率的に実行できます。

• エラーを減らす：タスクをしっかりと把握することで、チームはスプリント時のエラーを軽減できます。

• コラボレーションを促進する：DoR は作業合意と見なすことができ、チーム全体の健全なコラボレーションを促進します。

• チームを強化する: DoR により、チームは自分の作業に対する所有権と制御機能を得ます。 「DoR は、チームのために、チームによって作成されることを忘れないでください」と、アトラシアンの Modern Work Coach を務める Mark Cruth は語ります。「すべては、チームが快適に仕事を始めるために必要なことです」

DoR を理解したら、次は DoR を作成してみましょう。会社にとって効果的な DoR を作成するプロセスをステップバイステップで見ていきましょう。

1. チームの責任を定義する。各チーム メンバーが自分の責任を把握していることを確認します。

2. 重要な関係者を参加させる。スコープ クリープを軽減するには、DoR 基準に関する、関係者の意見と賛同が必要です。

3. DoR の構造と形式を指定する。チェックリストの目的は？作業の準備完了を定義するものは？準備が完了していることをチームはどのように判断するか？これらは、DoR の作成時に確認すべき重要事項です。

4. バックログを整える。整理されたバックログに勝るものはありません。チームは、項目が製品ロードマップに適合し、今も関連性があるかどうかを調べる必要があります。

5. ユーザー ストーリーを特定して定義する。ユーザー ストーリーの基準と、それが実現可能かどうかを判断します。

6. INVEST メソッドを満たしていることを確認する。タスクが、独立している、交渉できる、価値がある、予測できる、小さい、テストできるかどうかを DoR チェックリストで判断します。

7. DoR を定期的にレビューします。優先度は変化するため、DoR はこれらの変化を反映している必要があります。そうでない場合、チームはそれほど効率的に作業できていない可能性があります。「チームがスプリント内にすべての作業を完了していないことが多い場合や、スプリント内に作業を理解しようと必死になっている場合は、準備完了の定義を見直してアップデートする必要がある可能性が高くなります」と Cruth は説明します。

すべての手順を把握したら、Jira 内で「準備完了の定義」チェックリストを作成して、チームがタスクを完了する方法と期待値について共通認識を持てるようにします。

DoR を始める準備は整っていますか？Jira はソフトウェア・チームのアジャイルの状態を維持しやすくし、作業が顧客とビジネス全体にとって有意義なものとなることを保証します。

DoR を定義し、その要件を Jira に組み込みます。カスタム・フィールドを作成するか、拡張機能をダウンロードして、Jira 課題ごとに Jira の課題チェックリストを作成します。さまざまなタイプの作業が存在する場合は、Jira 課題タイプをカスタマイズして、異なる DoR を作成します。

また、Jira では、スプリント・バックログ・リファインメントのプロセスを簡素化することもできます。Jira を使用すると、ソフトウェア・チームは次のことを行えます。

• 準備が整っていて実行できるタスクとユーザー ストーリーを決定する。

• 大規模なタスクを、より小さく管理しやすいスプリントに分割する。

• スプリントを効率的に実行し、作業を継続する。

• 摩擦を最小限に抑えてベロシティを向上させる。

DoR の例にはどのようなものがありますか？

DoR によって、チームはバックログ項目がスプリントの準備を完了しているかどうかを把握できます。バグ修正での「準備完了の定義」の例をご紹介します。

バグ修正がバックログに残っている可能性はありますが、今ならバグ修正を上に移動できます。その理由は、チームが次のような状態だったためです。

• 実行可能だと判断した。バグ修正は実現可能で、他のタスクから独立しているとチームは考えています。

• 共通認識を確立した。チーム全員がバグ修正の内容を把握しています。メンバーは、実現するために何が必要かを把握しています。

• 価値を把握している。チームは、バグ修正が顧客とビジネスに与える影響を理解しています。

• 基準や、完了までのタイムラインを設定した。チームは、主要な基準に基づいて修正が完了するまでの時間を推定できます。

• バグ修正はテスト可能かつ検証可能だと確信している。チームは、修正をテストし、それが機能するかどうかを確認し、関係者に実証できます。

DoR はアジャイル プロジェクト管理にどのように適合しますか？

DoR によって、チームはアジャイルになれます。DoR はアジャイル プロジェクト管理には最適です。チームで次のことが可能になるためです。

• 合理的なタイムライン内で取り組めるタスクを把握できる。

• 依存関係や要件をすべて把握しているため、効果的に作業できる。

• チームが予定どおりに作業スコープを完了できるように、必要な情報をすべて揃えている。

DoR と DoD の違いは何ですか？

DoR と DoD は、どちらもスプリントの開始/終了時の両方での重要な基準ですが、主な違いがいくつかあります。

• DoR：チームが取り組むタスクまたはユーザー ストーリーの準備が整っているかどうかを判断する基準です。

• DoD：タスクまたはユーザー ストーリーが完了する時期を判断する基準です。