1. 2013年10月29日 第3回SEMATカーネル勉強会
SEMATカーネル
アルファ状態カードゲーム
鷲崎 弘宜
SEMAT Japan Chapter Chair
Twitter: @Hiro_Washi washizaki@waseda.jp
http://www.washi.cs.waseda.ac.jp/
（ベース資料）
Ivar Jacobson International (IJI): Alpha State Card Games
http://www.ivarjacobson.com/alphastatecards/

2. ゲームの進め方
• 4-5名のチーム
• 各チームで1名がストーリーテラー役
– 自身の現在（あるいはある時点）の開発状況を説
明する。
– カードは扱わない。指示もしない。聞かれたら答
える。
• 他のメンバはプレイヤ役（大抵は開発者）
2

3. 進捗ポーカー（Progress poker）
• 開発における各アルファの状態の認識につ
いて、チーム内で効率的に同意する。
1. 各プレイヤは検討対象のアルファの状態カ
ードを選択する。
2. 選択カードを一斉に提示 or 指さす。
3. 全プレイヤが
– 同一カードを選択しなかった場合、最も進んでい
ない状態と最も進んでいる状態を選択した参加
者がそれぞれ理由を説明する。1に戻る。
– 同一カードを選択した場合は終了する。
3

4. 状態の追跡（Chase the state）
1. 各アルファのカードを横一列に。左端に最初の状態
2. チームにおいて当該状態に達しているかどうかを問
いかけ（不明な場合は「進捗ポーカー」の実施）
3. ある状態に達している場合は当該状態のカードを左
側に
4. 未到達・未検討の状態のカードを右側に
図5. チームは現在地の特定にアルファを使用する
要求
要求
要求
構想
スコープ定義
・新しいシステムのニーズが明確である
・ユーザが識別されている
・最初の出資者が識別されている
・システムの目的とスコープが同意され
ている
・成功の判断基準が明確である
・要求管理の仕組みが同意されている
・制約と前提が識別されている
1/6
2/6
ソフトウェアシステム
ソフトウェアシステム
アーキテクチャ決定
論証完了
・重要な技術リスクに対応可能な
アーキテクチャが採用されている
・アーキテクチャの選択基準が同意され
ている
・使用するプラットフォーム、技術、
言語が選択されている
・購入、構築、再利用の方針が決定して
いる
・重要なアーキテクチャの特性が論証
できている
・アーキテクチャが適切であることを
ステークホルダが同意している
・重要なインタフェースとシステム構成
が論証できている
1/6
2/6
要求
一貫性・体系化
・明確な全体像が関係者に共有されている
・重要な利用シナリオが共有されている
・要求の優先度が明確である
・認識の不一致が対応されている
・要求がもたらす影響力が理解されている
3/6
要求
受理可能
実装
・関係者が受理可能な解決策が示されて
いる
・同意された要求が変更される確度は低い
・価値が明確である
・システムの受理に必要十分な要求が
実装されている
・システムが稼働させる価値のある状態に
あることにステークホルダが同意してい
る
4/6
ソフトウェアシステム
使用可能
・システムは使用可能であり、要求された
品質特性を達成できている
・ユーザがシステムを操作可能である
・機能と性能がテストされており、
検収済みである
・欠陥レベルが許容されている
・リリース内容が周知されている
3/6
要求
5/6
ソフトウェアシステム
ソフトウェアシステム
準備完了
運用
・ユーザドキュメントが利用できる
・ステークホルダがシステムを受理して
いる
・ステークホルダがシステムの運用方法
を準備しようとしている
・運用環境でシステムが使用されている
・想定されたユーザに利用されている
・システムの全機能を運用した事例が
少なくとも一つある。
・システム保守のサービスレベルが同意
されている
4/6
5/6
満足
・システムは要求とニーズを満足している
・完成を妨げる未解決の要求が存在しない
6/6
ソフトウェアシステム
退役
・システムは保守されていない
・システム更新によるリリースはない
・システムは置き換えられるか開発が
中止されている
6/6
4

5. • 最上位の7つのアルファに対する状態識別に意味はあるか。
– アルファを捉えるスコープで最初に合意すべき。全体、部分。
– 組織、プロジェクト固有のアルファを持つことの大切さ。背景知識重要。
• チームA
– 要求: 構想で合意
• 当初ばらついていたが、最終的に低い方で収束
– 仕事の仕方: 合意せず
• 個人開発のため人によって捉え方が異なった
• 減速の決定有無をまずは意識合わせすると良さそう
• チームB
– 機会: 課題解決で合意
• チェックリストの確認により合意
– ステークホルダ: 時間切れ
• ステークホルダの種類によって異なる
• 質問の仕方が大事
• チームC
– ソフトウェアシステム: 合意せず
• 対象とするシステム範囲が異なっていた
• 範囲を合意したのちも、使用可能から運用までばらついた
• チームD（アジャイル開発）
– 要求: 合意せず
• アジャイル開発における要求の満足について捉え方に食い違い。未完なのか、 5
当該時点において満足と判断するのか。