cards.uml

@startuml
class 機会(1) << (C,lightgreen) >> {
特定された
--
  -機会のアイデをが特定した
  -予算を出してくれる1人以上のステークホルダーが興味を持った
  -他のステークホルダーを特定した
}
class 機会(2) << (C,lightgreen) >> {
ソリューションが必要になった
--
  -ソリューションを特定した
  -ステークホルダーのニーズを確定した
  -問題と根本原因を特定した
  -ソリューションのニーズを確認した
  -少なくとも1つのソリューションが提案された
}
class 機会(3) << (C,lightgreen) >> {
価値が確立された
--
  -機会の価値が定量化された
  -ソリューションのインパクトが理解された
  -システムの価値が理解された
  -成功基準が明確になった
  -アウトカムが明確になり定量化された
}
class 機会(4) << (C,lightgreen) >> {
実行可能になった
--
  -ソリューションの概要が決まった
  -制約を前提としたソリューションがある
  -リスクが受容および管理可能である
  -ソリューションが利益につながる
  -ソリューションの開発理由が理解された
  -深堀りが実行可能である
}
class 機会(5) << (C,lightgreen) >> {
対応済みである
--
  -機会に対応した
  -ソリューションを展開する価値がある
  -ステークホルダーが満足した
}
class 機会(6) << (C,lightgreen) >> {
メリットが発生した
--
  -ソリューションからメリットが生じる
  -ROIが受け入れ可能である
}
class ステークホルダー(1) << (C,lightgreen) >> {
認識できた
--
  -ステークホルダーを見つけた
  -ステークホルダーの代表者を決めた
  -ステークホルダーの責任を定義した
}
class ステークホルダー(2) << (C,lightgreen) >> {
代表者がいる
--
  -ステークホルダーの責任に合意してくれた
  -代表者に権限が与えられた
  -協調的なアプローチに合意してくれた
  -作業方法をサポート＆尊重してくれた
}
class ステークホルダー(3) << (C,lightgreen) >> {
関与している
--
  -代表者がチームを支援している
  -フィードバックや意思決定のタイミングがよい
  -変更をすぐに知らせてくれる
}
class ステークホルダー(4) << (C,lightgreen) >> {
合意できた
--
  -期待を最小限にしてくれた
  -代表者が関与に満足している
  -代表者からのインプットが重視されている
  -チームからのインプットが重視されている
  -優先順位が明確＆視点が安定している
}
class ステークホルダー(5) << (C,lightgreen) >> {
デプロイに満足している
--
  -ステークホルダーからフィードバックがある
  -システムがデプロイ可能である
}
class ステークホルダー(6) << (C,lightgreen) >> {
利用に満足している
--
  -システムの利用に関するフィードバックが利用可能である
  -システムが期待と合致している
}
class 要求(1) << (S,yellow) >> {
企画されている
--
  -スタークホルダーがシステムの開発に合意している
  -ユーザーが特定されている
  -資金を提供するステークホルダーが特定されている
  -機会が明確である
}
class 要求(2) << (S,yellow) >> {
明確化されている
--
  -開発のステークホルダーが特定されている
  -システムの目的が合意されている
  -システムの成功が明確である
  -ソリューションの共通理解が存在する
  -要求のフォーマットが合意されている
  -要求管理が整っている
  -優先順位付けの仕組みが明確である
  -制約が特定および検討されている
  -想定が明確である
}
class 要求(3) << (S,yellow) >> {
論理的である
--
  -要求が共有されている
  -要求の源が明確である
  -論理的根拠が明確である
  -衝突が解消されている
  -必要不可欠な特徴が明確である
  -重要な利用シナリオが説明されている
  -優先順位が明確である
  -影響が理解されている
  -提供するものをチームが理解・合意している
}
class 要求(4) << (S,yellow) >> {
受け入れ可能である
--
  -受け入れ可能なソリューションが記述されている
  -変更が管理されている
  -実現される価値が明確である
  -機会の対応が明確である
  -テスト可能である
}
class 要求(5) << (S,yellow) >> {
対応済みである
--
  -受け入れ可能になるまで十分に対応されている
  -要求とシステムが合致している
  -実現された価値が明確である
  -運用に値するシステムである
}
class 要求(6) << (S,yellow) >> {
満たされている
--
  -ステークホルダーが要求を受け入れている
  -邪魔になる要求がない
  -要求が完全に満たされている
}
class ソフトウェアシステム(1) << (S,yellow) >> {
アーキテクチャが選択済みである
--
  -アーキテクチャの選択基準に合意した
  -ハードウェアプラットフォームを特定した
  -テクノロジーを選択した
  -システムの境界がわかっている
  -システム構成を決定した
  -購入・構築・再利用を決定した
  -重要な技術的リスクに合意した
}
class ソフトウェアシステム(2) << (S,yellow) >> {
デモ可能である
--
  -重要なアーキテクチャの特性をデモした
  -システムを実行してパフォーマンスを測定した
  -重要なハードウェア構成をデモした
  -重要なインターフェイスをデモした
  -環境との統合をデモした
  -アーキテクチャが目的に合っていると受け入れられた
}
class ソフトウェアシステム(3) << (S,yellow) >> {
使用可能である
--
  -システムは運用可能である
  -システムの機能はテスト済みである
  -システムのパフォーマンスは受け入れ可能である
  -欠陥レベルは受け入れ可能である
  -システムが完全に文書化されている
  -リリース内容が周知されている
  -追加された価値が明確である
}
class ソフトウェアシステム(4) << (S,yellow) >> {
準備完了である
--
  -ユーザー文書が利用可能である
  -システムが目的に合致している
  -ステークホルダーが必要としている
  -運用サポートの準備できている
}
class ソフトウェアシステム(5) << (S,yellow) >> {
運用可能である
--
  -システムが稼働可能である
  -システムが稼働している
  -合意されたサービスレベルをサポートしている
}
class ソフトウェアシステム(6) << (S,yellow) >> {
廃止済みである
--
  -リプレースまたは破棄された
  -サポートが終了した
  -権限のあるユーザーがいない
  -更新を停止した
}
enum 作業(1) << (E,lightblue) >> {
開始された
--
  -求められる結果が明確である
  -制約が明確である
  -予算のステークホルダーがわかっている
  -起案者が特定された
  -受け入れするステークホルダーがわかっている
  -予算の源が明確である
  -優先順位が明確である
}
enum 作業(2) << (E,lightblue) >> {
準備できた
--
  -コミットされている
  -コストと労力が見積もられている
  -利用可能なリソースがわかっている
  -リスクの影響度が理解されている
  -受け入れ基準が設定されている
  -着手できるほど十分に分割されている
  -タスクが特定されて優先順位がつけられている
  -信頼できる計画がある
  -予算が用意されている
  -少なくとも1人のチームメンバーが確保できている
  -統合地点が定義されている
}
enum 作業(3) << (E,lightblue) >> {
着手した
--
  -開発が開始された
  -進捗を追跡している
  -完成の定義が設定されている
  -タスクが進行中である
}
enum 作業(4) << (E,lightblue) >> {
制御中である
--
  -タスクが完了した
  -計画外の作業が制御されている
  -リスクが制御されている
  -パフォーマンスを反映して再見積もりした
  -進捗が計測されている
  -再作業が制御されている
  -コミットメントが一貫して満たされている
}
enum 作業(5) << (E,lightblue) >> {
完了した
--
  -管理者の作業のみが残っている
  -結果が達成された
  -最終的なシステムが受け入れられた
}
enum 作業(6) << (E,lightblue) >> {
終了した
--
  -学びがあった
  -指標が利用可能である
  -すべてが達成された
  -予算を調整して終了した
  -チームが解放された
  - uncompleted tasks
}
enum チーム(1) << (E,lightblue) >> {
集められた
--
  -ミッションが定義された
  -制約が判明および定義されている
  -成長の仕組みが整っている
  -編成が定義された
  -責任の概要が決まった
  -必要となるコミットメントのレベルが明確である
  -必要となるコンピテンシーが特定された
  -規模が決まった
  -ガバナンスルールが定義された
  -リーダーシップモデルが選択された
}
enum チーム(2) << (E,lightblue) >> {
形成された
--
  -十分なメンバーをリクルートした
  -役割を理解した
  -仕事のやり方を理解した
  -メンバーを紹介した
  -個人の能力に合った責任を受け入れた
  -メンバーが作業を受け入れた
  -外部のコラボレーターが特定された
  -コミュニケーションの仕組みが定義されている
  -メンバーがチームにコミットしている
}
enum チーム(3) << (E,lightblue) >> {
コラボレーションしている
--
  -チームとして作業している
  -オープンで正直にコミュニケーションしている
  -ミッションにフォーカスしている
  -メンバーはお互いによく知っている
}
enum チーム(4) << (E,lightblue) >> {
機能している
--
  -一貫してコミットメントを満たしている
  -継続的に変化に適応している
  -問題に対処している
  -手戻りや後退が最小限である
  -継続的にムダを排除している
}
enum チーム(5) << (E,lightblue) >> {
散会した
--
  -責任が果たされた
  -メンバーが他のチームで利用可能である
  -ミッションが終了した
}
enum 作業方法(1) << (E,lightblue) >> {
原則を作った
--
  -チームが積極的に原則をサポートしている
  -ステークホルダーが原則に合意している
  -ツールの合意が必要である
  -アプローチが推奨されている
  -運用の背景が理解されている
  -プラクティスとツールの制約がわかっている
}
enum 作業方法(2) << (E,lightblue) >> {
基盤を作った
--
  -プラクティスとツールを選択した
  -作業開始に必要なプラクティスが合意された
  -必須のプラクティスとツールが特定できた
  -利用可能な作業方法と必要な作業方法のギャップが理解された
  -能力のギャップが理解された
  -作業方法の統合が可能である
}
enum 作業方法(3) << (E,lightblue) >> {
利用中である
--
  -プラクティスとツールを使用中である
  -定期的に検査している
  -状況に適応している
  -チームが賛同している
  -フィードバックの仕組みがある
  -プラクティスとツールがコラボレーションをサポートしている
}
enum 作業方法(4) << (E,lightblue) >> {
実施中である
--
  -チーム全体で使用している
  -チーム全体で利用可能である
  -チーム全体で検査と適応している
}
enum 作業方法(5) << (E,lightblue) >> {
順調である
--
  -進捗が予測可能である
  -自然にプラクティスを適用している
  -自然にツールに支援されている
  -継続的に調整している
}
enum 作業方法(6) << (E,lightblue) >> {
廃止済みである
--
  -すでに使用していない
  -教訓が共有されている
}
hide empty members
@enduml