コンテンツにスキップ

作業項目 (Work Item)

作業項目(Work Item)とは、ワークフローを移動する個々の価値の単位であり、ワークフローの定義(DoW)の最初の必須要素として定義されるものである。単に「項目(item)」とも呼ばれ、粒度はさまざまで、価値を生み出す可能性がある限りどのような用語で表現されてもよい。作業項目はワークフロー内で「開始(started)」と「終了(finished)」のタイミングを持ち、開始点と終了点の間にある作業項目は進行中の作業(WIP)とみなされる。スクラムチームがカンバンを併用する場合、作業項目は通常プロダクトバックログアイテム(ユーザーストーリーやバックログアイテム)に対応する。KGO(Kanban Guide Ontology)では kgo:WorkItem として表現され、必ず kgo:ToDo / kgo:InProcess / kgo:Done のいずれかちょうど 1 つの状態に属する。

  • DoW の最初の必須要素: Kanban Guide 2025 は、ワークフローの定義を作成するために「ワークフローを移動する個々の価値単位の定義」を最初に挙げ、この価値単位を「作業項目(work item)」または「項目(item)」と呼ぶ[1]。Open Guide to Kanban の用語集は、作業項目を「価値を生み出す可能性をもつもの」と定義し、粒度がさまざまであることと、ステークホルダーにとっての価値を生み出す可能性がない作業項目は無駄となりうることを付け加えている[2]。
  • 開始と終了、そして状態: DoW は、作業項目の「開始(started)」と「終了(finished)」のタイミングと、その間のフローを示すひとつ以上の状態を定義しなければならない[1]。作業項目によっては、ワークフローにひとつ以上の開始点や終了点がある場合もある[1]。開始点と終了点の間にある作業項目が進行中の作業(WIP)であり[1]、フロー指標の WIP は「開始しているが、まだ終了していない作業項目の数」として数える[1]。Open Guide to Kanban の用語集は「作業(Work)」を、「開始している」「開始していない」「終了している」「終了していない」のいずれかの場合を含むひとつ以上の作業項目と定義している[2]。
  • 主体的な管理: ワークフロー内の項目は主体的に管理されなければならず、その形式には WIP の制御、サービスレベル期待値(SLE)を参考にして作業項目が不必要に古くならないようにすること(作業項目の年齢の監視)、ブロックされている作業の解除が含まれる[1]。カンバンシステムメンバーは、進行中の項目を継続的または定期的にレビューするのが一般的である[1]。
  • プルによる着手: カンバンシステムメンバーは、対応できる余力があるという明確な合図があるときにのみ作業項目に着手すべきであり、これを「プルする」または「選択する」と呼ぶ[1]。
  • スクラムとの対応: Kanban Guide for Scrum Teams では、作業項目は「スクラムチームが作業を開始したが、まだ終了していない」単位として WIP の対象になり、通常はプロダクトバックログアイテムに相当する[3]。 大規模なアジャイル ERP 変革プログラム 1 件のケーススタディでは、ウェーブ計画の間に、ワークパッケージが、チームが 1 スプリント内で実装可能な完全で動作する機能的サブセットであるワークアイテムへ分解された[4]。

作業項目は、開発フロー内を移動する作業の個別単位であると同時に、不確実性や前提条件を紐付けて検証や学習ループを適用する対象である[5]。

  • 所属タグ: Kanban Workflow Work Item
  • カテゴリー: Kanban & Flow
  • 上位クラス(直接の親から順に): 未定義
  • 兄弟クラス: 未定義
  • 他の概念との関係: 未定義
  • 関連する検証ルール: K3、K4
  • 関連CQ: 未対応
  • 原文: 未定義
  • オントロジー階層: オントロジー階層で見る

KGO は作業項目の状態を、「開始」と「終了」に基づく互いに素な 3 つのクラスで表す。

状態クラス意味WIP 集計
kgo:ToDoまだ「開始」していない作業項目対象外
kgo:InProcess「開始」しているが、まだ「終了」していない作業項目対象
kgo:Doneすでに「終了」している作業項目対象外

kgo:ToDo から kgo:InProcess への遷移が「開始」、kgo:InProcess から kgo:Done への遷移が「終了」に対応する。1 件の作業項目は必ずこのうちちょうど 1 つの状態に属し(K2 の相互排他性と K3 の完全性)、ブロック中の有無(kgo:isBlocked)や外部トラッカーでのクローズの有無(kgo:isClosed)は状態とは独立したフラグとして扱う。カンバンボード上の列の位置(kgo:inColumn)も状態とは別の軸である。

KGO (Kanban Guide Ontology) に基づく、この概念に関係する制約です。各制約の括弧内は、その制約が対象とするクラスです。

  • K2 (ToDo, InProcess, Done): 1 件の作業項目(kgo:WorkItem)が kgo:ToDo / kgo:InProcess / kgo:Done のうち複数の状態に同時に分類されている場合、状態の相互排他性(disjoint)違反として不適合になります。作業は「開始している」か「開始していない」か、「終了している」か「終了していない」かのいずれかであり(Open Guide to Kanban 用語集「作業」)、同時に両方であることはできません。
  • K3 (WorkItem): 作業項目(kgo:WorkItem)が kgo:ToDo / kgo:InProcess / kgo:Done のいずれの状態にも属していない(浮遊作業項目)場合、状態の完全性(totality)違反として不適合になります。ワークフローの定義は「作業項目が開始から終了までの間のフローを示すひとつ以上の状態」を定義しなければならず、状態を持たない作業項目はどのワークフローにも属していないことになります。
  • K4 [警告] (WorkItem): 作業項目がプッシュ型の割り込みでワークフローに投入されている(kgo:enteredVia が kgo:PullTransition ではなく kgo:PushTransition を指す)場合、プル運用からの逸脱として警告されます。カンバンシステムメンバーは「対応できる余力があるという明確な合図があるときにのみ、作業項目に着手すべき」(Kanban Guide 2025)です。kgo:enteredVia が未指定の作業項目は判定対象になりません。詳細はプルによる投入を参照してください。
  • K5 (InProcess): 外部トラッカー(GitHub Issues / Jira 等)上で既にクローズされた作業項目(kgo:isClosed が true)が、ボード上で進行中(kgo:InProcess)に残存している場合、ゾンビ WIP 違反として不適合になります。Kanban Guide 2025 は「進行中の項目を定期的にレビューする」ことを求めており、終了済みの項目を WIP に残すと WIP の集計と WIP 制限の判定を歪めます(ADR-0010)。
  1. Kanban Guide 2025 — 「ワークフローを移動する個々の価値単位の定義 これらの価値単位は、『作業項目(work item)』または、『 項目(item)』と呼ばれる。」「作業項目が開始から終了までの間のフローを示すひとつ以上の状態の定義 開始点(started point)と終了点(finished point)の間にある作業項目は、『進行中の作 業(WIP: Work in Progress)』とみなされる。」「ワークフロー内の項目は主体的に管理されなければならない。」(ライセンス: CC BY-SA 4.0) ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8

  2. Open Guide to Kanban — 「作業項目または項目(Item)とは、価値を生み出す可能性 をもつものである。作業項目の粒度はさまざまであり、価値の可能性がある限り、さ まざまな用語で表現されることがある。」「ひとつ以上の作業項目のことを指し、『開始している』『開始していな い』『終了している』『終了していない』のいずれかの場合を含む。」(ライセンス: CC BY-SA 4.0) ↩ ↩2

  3. Kanban Guide for Scrum Teams 2021 — 「進行中の作業(WIP: Work in Progress)とは、スクラムチームが作業を開始したが、ま だ終了していない作業項目のことを指す。」(ライセンス: CC BY-SA 4.0) ↩

  4. Investigating Effort Estimation in a Large-Scale Agile ERP Transformation Program — 「各ウェーブ計画の間、次のウェーブのワークパッケージはさらに、チームが1スプリント内で実装可能な完全で動作する機能的サブセットであるワークアイテム(Work Items)へと分解される(E2、E4、E11)。」(訳)(ライセンス: CC BY 4.0) ↩

  5. Collaboration and Uncertainty Management in Agile Software Development: A Systematic Integrative Review and Literature-Based Positioning of CDM — 「提案されたループは、作業項目(ワークアイテム)レベルでの将来の観察に向けて具体化することができる。」(訳)(ライセンス: CC BY 4.0) ↩