アジャイルソフトウェア要求

第I部概観：全体像1

第1章　ソフトウェア要求手法の短い歴史

1.1ソフトウェア要求が置かれた状況：何十年間ものソフトウェアプロセスモデルの進歩
1.2予測に基く、滝のようなプロセス
　1.2.1このモデルの問題点
　1.2.2ウォーターフォールモデルにおける要求：鉄の三角形
　1.2.3それでも、ウォーターフォールモデルは依然として我々の間に存在する
1.3反復的に追加するプロセス
　1.3.1スパイラルモデル
　1.3.2ラピッドアプリケーション開発
　1.3.3ラショナル統一プロセス
　1.3.4反復開発における要求
1.4適応（アジャイル）プロセス
　1.4.1アジャイル宣言
　1.4.2エクストリーム・プログラミング（XP）
　1.4.3スクラム
　1.4.4アジャイルにおける要求は根本的に違う
1.5企業規模の適応プロセス
1.6リーンソフトウェア入門
　1.6.1リーンソフトウェアの殿堂
　1.6.2ソフトウェア要求のシステム的観点
　1.6.3カンバン：もう一つのソフトウェア手法の出現
1.7まとめ

第2章　アジャイル要求の全体像

2.1全体像の説明
　2.1.1全体像のハイライト
2.2全体像の要素：チームレベル
　2.2.1アジャイルチーム
　2.2.2アジャイルチームにおける役割
　2.2.3反復
　2.2.4ユーザーストーリーとチームバックログ
2.3全体像の要素：プログラムレベル
　2.3.1リリースと潜在的に出荷可能なインクリメント
　2.3.2ビジョン、フィーチャー、プログラムバックログ
　2.3.3リリース計画
　2.3.4ロードマップ
　2.3.5プロダクト管理
2.4全体像の要素：ポートフォリオレベル
　2.4.1投資テーマ
　2.4.2エピックとポートフォリオバックログ
　2.4.3アーキテクチャー滑走路
2.5まとめ

第3章　チームのためのアジャイル要求

3.1チームレベルへの導入
　3.1.1なぜチームについて論じるのか？
　3.1.2機能サイロを取り除く
3.2アジャイルチームの役割と責任
　3.2.1プロダクトオーナー
　3.2.2スクラムマスター/アジャイルマスター
　3.2.3開発者
　3.2.4テスト担当者
　3.2.5他のチーム/プログラムの役割
3.3ユーザーストーリーとチームバックログ
　3.3.1バックログ
　3.3.2ユーザーストーリー
　3.3.3ユーザーストーリーの基本
　3.3.4タスク
3.4受け入れテスト
3.5単体テスト
　3.5.1リアルタイムに本当の品質を
3.6まとめ

第4章　プログラムのためのアジャイル要求

4.1プログラムレベルの導入
4.2アジャイルチームを大きな規模で組織化する
　4.2.1フィーチャーチームとコンポーネントチーム
　4.2.2システムチーム
　4.2.3リリース管理チーム
　4.2.4プロダクト管理
4.3ビジョン
4.4フィーチャー
　4.4.1新たなフィーチャーがプログラムバックログを作る
　4.4.2フィーチャーをテストする
4.5非機能要求
　4.5.1バックログの制約としての非機能要求
　4.5.2非機能要求をテストする
4.6アジャイルリリース列車
　4.6.1リリースと潜在的に出荷可能なインクリメント
　4.6.2リリース計画
4.7ロードマップ
4.8まとめ

第5章　ポートフォリオのためのアジャイル要求

5.1ポートフォリオレベルの導入
5.2投資テーマ
5.3ポートフォリオ管理チーム
5.4エピックとポートフォリオバックログ
　5.4.1ポートフォリオバックログ
5.5エピック、フィーチャー、そしてストーリー
5.6アーキテクチャー滑走路とアーキテクチャーエピック
　5.6.1アーキテクチャーエピックを実装する
　5.6.2アーキテクチャー滑走路：ポートフォリオ、プログラム、チーム
5.7まとめ
5.8企業要求情報モデル全体のまとめ
事例：テンドリル・プラットホーム81

第II部チームのためのアジャイル要求

第6章　ユーザーストーリー

6.1導入
　6.1.1ユーザーストーリーの概要
　6.1.2ユーザーストーリーは開発者と顧客のコミュニケーションギャップを橋渡しする
　6.1.3ユーザーストーリーは要求ではない
6.2ユーザーストーリーの形式
　6.2.1カード、会話、そして確認
　6.2.2ユーザーストーリーの声
　6.2.3ユーザーストーリーの詳細
　6.2.4ユーザーストーリー受け入れ基準
6.3良いユーザーストーリーにおけるINVEST
　6.3.1独立している
　6.3.2交渉でき…そして交渉される
　6.3.3価値がある
　6.3.4見積もりができる
　6.3.5小さい
　6.3.6テストできる
6.4ユーザーストーリーを分割する
6.5スパイク
　6.5.1技術的なスパイクと機能的なスパイク
　6.5.2スパイクのガイドライン
6.6索引カードによるストーリーモデリング
6.7まとめ

第7章　利害関係者、ユーザーペルソナ、ユーザーエクスペリエンス

7.1利害関係者
　7.1.1システム利害関係者
　7.1.2プロジェクト利害関係者
　7.1.3利害関係者の声：プロダクトオーナー
　7.1.4利害関係者の関与のレベル
　7.1.5利害関係者の信頼を築く
　7.1.6利害関係者とのやり取り
7.2利害関係者を識別する
　7.2.1プロジェクト利害関係者を識別する
　7.2.2システム利害関係者を識別する
　7.2.3システム利害関係者を分類する
　7.2.4システム利害関係者のニーズを理解する
　7.2.5利害関係者/プロダクトオーナーチーム？
7.3ユーザーペルソナ
　7.3.1主と副ユーザーペルソナ
　7.3.2ユーザーストーリーモデリングによりペルソナを見つける
7.4アジャイルとユーザーエクスペリエンス開発
　7.4.1ユーザーエクスペリエンスの問題
　7.4.2ユーザーインターフェース開発のための忠実度が低い選択肢
　7.4.3UXストーリースパイク
　7.4.4集中したUX開発
　7.4.5分散され、統制されたUX開発モデル
7.5まとめ

第8章　アジャイルな見積もりとベロシティー

8.1導入
　8.1.1この狂気には筋が通っている
　8.1.2ゴールは同じである：より信頼できる見積もり
8.2なぜ見積もるか？見積もりのビジネス価値
8.3ストーリーポイントでスコープを見積もる
8.4ストーリーポイントを理解する：演習
　8.4.1演習パート1：相対見積もり
　8.4.2演習パート2：プランニングポーカーで実作業を見積もる
　8.4.3見積もりにどのぐらいの時間を費やすべきか？
　8.4.4見積もりに対する注意のたとえ話：ストーリーの中のストーリー
　8.4.5オンラインプランニングポーカーによる分散見積もり
8.5代わりのテクニック：机上での相対見積もり
8.6スコープの見積もりからチームベロシティーへ
　8.6.1演習パート3：ベロシティーを確立する
8.7相対見積もりモデルに対する警告
　8.7.1もう一つのたとえ話：ベロシティーを増やす、求めることに気をつけよう
8.8ベロシティーから期間と費用へ
　8.8.1期間を見積もる
　8.8.2費用を見積もる
8.9理想開発者日で見積もりする
8.10ハイブリッドモデル
　8.10.1ベロシティーを正規化する
8.11まとめ

第9章　反復、バックログ、スループット、そしてカンバン

9.1反復する：アジャイルさの鼓動
　9.1.1反復の長さ
　9.1.2反復のパターン：計画、実行、レビューと振り返り
　9.1.3チームバックログ
　9.1.4反復を計画する
　9.1.5反復の確約
　9.1.6反復を実行する
　9.1.7追跡し、調整する
　9.1.8レビューと振り返り
　9.1.9フィーチャーの下見
9.2バックログ、リーン、そしてスループット
　9.2.1バックログの成熟度、リーン、そしてリトルの法則
　9.2.2ブログの話：形式が整ったプロダクトバックログはチームのアジャイルさを低下させるか？
　9.2.3リトルの法則とアジャイルチームのバックログ
　9.2.4リトルの法則を適用してアジャイルさを増し、市場への投入時間を減らす
　9.2.5読者の反応
　9.2.6バックログの待ち行列長を制御することでスループットを管理する
9.3ソフトウェアカンバンシステム
　9.3.1カンバンシステムの特性
　9.3.2カンバンにおけるサービスの種別
9.4まとめ

第10章　受け入れテスティング

10.1なぜアジャイル要求の本でテスティングについて書くのか？
10.2アジャイルテスティングの概要
10.3受け入れテストとは何か？
　10.3.1ストーリー受け入れテスト
10.4良いストーリー受け入れテストの特徴
　10.4.1それらは良いユーザーストーリーをテストする
　10.4.2あまりあいまいでなく、すべてのシナリオをテストする
　10.4.3それらは存続する
10.5受け入れテスト駆動開発
10.6受け入れテストのひな形
10.7自動化された受け入れテスト
　10.7.1自動化された受け入れテスティングの例：FITアプローチ
10.8単体およびコンポーネントテスティング
　10.8.1単体テスティング
　10.8.2コンポーネントテスティング
10.9まとめ

第11章　プロダクトオーナーの役割

11.1これは新たな役割だろうか？
11.2プロダクトオーナーとプロダクト管理者の2つの役割の捉え方
　11.2.1名前ゲーム：プロダクトオーナーの役割/肩書で実験する
　11.2.2我々の結論：2つの役割を適用する
11.3企業におけるプロダクトオーナーの責任
　11.3.1バックログを管理する
　11.3.2ジャスト・イン・タイムのストーリーの詳細化
　11.3.3反復を推進する
　11.3.4技術的負債と価値のストリームの問題
　11.3.5リリースを一緒に計画する
11.4優れたプロダクトオーナーの5つの基本的な特質
11.5プロダクト管理者との連携
11.6プロダクトオーナーのボトルネック：パートタイムのプロダクトオーナー、プロダクトオーナーの代理、プロダクトオーナーチーム
　11.6.1プロダクトオーナーの代理
　11.6.2プロダクトオーナーチーム
11.7企業にプロダクトオーナーの役割の種をまく
　11.7.1トレードステーションテクノロジー社
　11.7.2CSGシステムズ社
　11.7.3ジョンディア・インテリジェントソリューショングループ
　11.7.4ディスカウントタイヤ社
11.8まとめ

第12章　要求発見ツールキット

12.1要求ワークショップ
　12.1.1ワークショップの準備を行う
　12.1.2議題を設定する
　12.1.3ワークショップを運営する
12.2ブレーンストーミング
　12.2.1アイデア出し
　12.2.2アイデアの絞り込み
　12.2.3アイデアの優先順位付け
12.3インタビューとアンケート
　12.3.1文脈に依存しない質問
　12.3.2ソリューションの文脈に依存した質問
　12.3.3真実の瞬間：インタビュー
　12.3.4ニーズに関するデータを集める
　12.3.5アンケートに対する補足
12.4ユーザーエクスペリエンスモックアップ
12.5プロダクト審議会を結成する
12.6競合分析
12.7顧客変更依頼システム
　12.7.1欠陥のログ
12.8ユースケースモデリング
12.9まとめ

第III部プログラムのためのアジャイル要求

第13章　ビジョン、フィーチャー、ロードマップ

13.1ビジョン
13.2ビジョンを表現する
　13.2.1ビジョン文書
　13.2.2先行したデータシートアプローチ
　13.2.3予備的なプレスリリースアプローチ
　13.2.4「概要説明付きのフィーチャーバックログ」アプローチ
　13.2.5非機能要求（システム品質）を伝える
13.3フィーチャー
　13.3.1ユーザーの声形式でフィーチャーを表現する
13.4フィーチャーを見積もる
　13.4.1労力の見積もり
　13.4.2コストを見積もる
　13.4.3開発期間を見積もる
13.5フィーチャーをテストする
13.6フィーチャーの優先順位付けをする
　13.6.1ROIの代用としての価値/労力：第一近似
　13.6.2価値/労力によるROIの代用の何が間違っているのか？
　13.6.3遅延のコストに基いてフィーチャーを優先順位付けする
　13.6.4遅延のコスト（CoD）の導入
　13.6.5遅延のコストを見積もる
　13.6.6フィーチャー優先順位付け評価マトリックス
　13.6.7すべての優先順位付けは局所的で一時的である
　13.6.8差を生む価値を達成する：顧客満足の狩野モデル
13.7ロードマップ
　13.7.1次、次の次、その先のリリースに対する自信と確約
13.8まとめ

第14章　プロダクト管理者の役割

14.1プロダクト管理者、ビジネス分析者？
14.2プロダクト会社でのプロダクト管理者の責任
14.3この役割のIT/IS部門におけるビジネス上の責務
14.4責務のまとめ
14.5アジャイル以前の企業でのプロダクト管理への幻滅のフェーズ
　14.5.1フェーズ1：抑制されていない熱狂
　14.5.2フェーズ2：偽りの安心感
　14.5.3フェーズ3：突然の認識
　14.5.4フェーズ4：期待を再設定する
　14.5.5フェーズ5：持続的な不信の季節
　14.5.6持続的な不信の季節から抜け出す
14.6アジャイルな企業でプロダクト管理を進化させる
　14.6.1顧客のニーズを理解する
　14.6.2要求を文書化する
　14.6.3スケジュールを立案する
　14.6.4要求を優先順位付けする
　14.6.5要求の妥当性を確認する
　14.6.6変更を管理する
　14.6.7現状を評価する
14.7アジャイルなプロダクト管理者の責務
　14.7.1ビジョンとリリースバックログに責任を持つ
　14.7.2リリースの内容を管理する
　14.7.3ロードマップを維持する
　14.7.4効果的なプロダクト管理者/プロダクトオーナーチームを築く
14.8まとめ

第15章　アジャイルリリース列車

15.1アジャイルリリース列車入門
　15.1.1アジャイルリリース列車の論理的な根拠
　15.1.2アジャイルリリース列車の原則
15.2戦略的な方向性を揃える
15.3プロダクト開発フローを制度化する
15.4アジャイルリリース列車を設計する
15.5リリースを計画する
　15.5.1リリース目標
15.6リリースを追跡し、管理する
15.7リリースの振り返り
15.8リリースの予見性を測定する
　15.8.1リリース目標プロセス制御帯
15.9リリースする
　15.9.1ARTと同じリズムでリリースする
　15.9.2ARTのリズムよりも少ない頻度でリリースする
　15.9.3ARTのリズムよりも多い頻度でリリースする
15.10まとめ

第16章　リリース計画

16.1リリース計画を準備する
　16.1.1リリース計画領域
　16.1.2計画策定への参加者
　16.1.3リリース計画ファシリテーター
　16.1.4リリース計画チェックリスト
16.2リリース計画物語、初日
　16.2.1オープニング
　16.2.2ビジネス背景
　16.2.3ソリューションのビジョン
　16.2.4アーキテクチャービジョン
　16.2.5チームに分かれての計画策定
　16.2.6計画の下書きのレビュー
　16.2.7管理者のレビューと問題解決打ち合わせ
16.3リリース計画物語、2日目
　16.3.1オープニング
　16.3.2計画の調整：共同戦線
　16.3.3計画策定の続き：チームに分かれての計画セッションII
　16.3.4リリース目標を確立する
　16.3.5最終的なリリース計画レビュー
　16.3.6リスクと障害に対応する
　16.3.7確約
　16.3.8計画策定振り返り
　16.3.9チームへの最後の指示
16.4背伸び目標
16.5まとめ

第17章　非機能要求

17.1非機能要求をモデリングする
　17.1.1非機能要求をユーザーストーリーとして表現する
17.2非機能要求を検討する
　17.2.1使いやすさ
　17.2.2信頼性
　17.2.3性能
　17.2.4サポートのしやすさ（保守性）
　17.2.5設計制約
17.3非機能要求を保管する
17.4非機能要求をテストする
　17.4.1使いやすさ
　17.4.2信頼性
　17.4.3セキュリティー
　17.4.4性能
　17.4.5サポートのしやすさと設計制約
17.5非機能要求のひな形
17.6まとめ

第18章　要求分析ツールキット

18.1アクティビティー図
18.2帳票の見本
18.3疑似コード
18.4決定表と決定木
18.5有限状態マシン
18.6メッセージシーケンス図
　18.6.1メッセージシーケンス図の限界
18.7実体関連図
18.8ユースケースモデリング
18.9まとめ

第19章　ユースケース

19.1ユーザーストーリーとバックログ項目の問題
19.2ユースケースを使い続ける5つのもっともな理由
19.3ユースケースの基本
　19.3.1ユースケースのアクター
　19.3.2ユースケースの構造
　19.3.3ユースケースモデルを構築するためのステップ・バイ・ステップガイド
19.4ユースケースの例
19.5ユースケースを適用する
　19.5.1アジャイルでユースケースを適用するためのコツ
19.6アジャイル要求情報モデルにおけるユースケース
19.7まとめ

第IV部ポートフォリオのためのアジャイル要求

第20章　アジャイルアーキテクチャー

20.1全体像のポートフォリオレベルの導入
20.2エンタープライズ級のシステムにおけるシステムアーキテクチャー
　20.2.1アジャイルですべてのアーキテクチャーが現れるか
　20.2.2意図的なアーキテクチャーの必要性
　20.2.3アーキテクチャーエピックを推進するビジネス要因
　20.2.4アジャイルな企業におけるシステムアーキテクトの役割
20.3アジャイルアーキテクチャーの8つの原則
　20.3.1原則1：システムのコーディングをするチームがシステムの設計もしなければならない345 　20.3.2原則2：正しく動作し得る中で最もシンプルなアーキテクチャーを構築する
　20.3.3原則3：疑わしいときはコードを書くかモデルを作成して確認する
　20.3.4原則4：構築したらテストする
　20.3.5原則5：システムが大きいほど滑走路を長くとる
　20.3.6原則6：システムアーキテクチャーは役割間の協調である
　20.3.7原則7：イノベーションに独占はない
　20.3.8原則8：アーキテクチャーフローを実装する
20.4アーキテクチャーエピックを実装する
　20.4.1状況A：大規模だが段階的、システムは常時稼働
　20.4.2状況B：大規模だが完全に段階的ではなく、システムを時々止める必要がある
　20.4.3状況C：非常に大きくかつ段階的でなく、システムは必要なときに稼働、害を及ぼさない355 20.5アーキテクチャーエピックを分割する
20.6まとめ

第21章　フローによるアーキテクチャーの再設計

21.1アーキテクチャーエピックのカンバン方式
　21.1.1カンバン方式の目的
21.2アーキテクチャーエピックのカンバン方式の概要
　21.2.1待ち行列の解説
　21.2.2アーキテクチャーエピックの状態の解説
21.3　1.じょうご：問題/ソリューションのニーズの特定
　21.3.1新しいアーキテクチャーエピックの情報源
　21.3.2作業：エピックの評価
　21.3.3仕掛かり作業制限
　21.3.4意思決定権限者
21.4　2.バックログ
　21.4.1作業：リズムベースのレビュー、議論、待ち行列内での評価
　21.4.2優先順位および評価方式
　21.4.3重み付けされた評価値と判断基準
　21.4.4バックログから分析へのプル
　21.4.5仕掛かり作業制限
21.5　3.分析
　21.5.1作業
　21.5.2開発チームとの連携
　21.5.3ビジネスとの連携：ソリューション管理、プロダクト管理、ビジネス分析者
　21.5.4仕掛かり作業制限
　21.5.5アーキテクチャーエピック用のビジネス企画テンプレート
　21.5.6意思決定権限者
21.6　4.実装
　21.6.1実装方針A：開発への移行
　21.6.2実装方針B：新チームの作成
　21.6.3実装方針C：開発のアウトソーシング
　21.6.4実装方針D：ソリューションの購入
　21.6.5仕掛かり作業制限
21.7まとめ

第22章　アジャイルポートフォリオ管理への移行

22.1ポートフォリオ管理
22.2アジャイルチームがPMOと出会うとき：暗闇ですれ違う2隻の船
22.3従来型の発想では企業はアジャイルになれない
　22.3.1「彼らの」問題ではなく「自分たちの」問題である
22.4ポートフォリオ管理における従来型の発想
22.5アジャイルポートフォリオ管理へ移行するための8つの提案
　22.5.1投資財源の見直し
　22.5.2変化の管理の見直し
　22.5.3ガバナンスと監視の見直し
22.6まとめ：アジャイルポートフォリオ計画へ

第23章　投資テーマ、エピック、ポートフォリオ計画

23.1投資テーマ
　23.1.1投資テーマの伝達
　23.1.2バックログの優先順位ではなく投資構成を使用する理由
23.2エピック
　23.2.1サブエピック
　23.2.2エピックの表現
　23.2.3エピック、フィーチャー、ストーリーの描写
　23.2.4エピックの種類
23.3ビジネスエピックの特定と評価：ポートフォリオ計画のカンバン方式
　23.3.1概要
　23.3.2状態図
　23.3.3じょうご：問題/ソリューションのニーズの特定
　23.3.4バックログ
　23.3.5分析
　23.3.6実装
23.4まとめ

第24章　終わりに

24.1これ以上の情報

付録

A文脈に依存しないインタビュー
Bビジョン文書テンプレート
Cリリース計画準備チェックリスト
Dアジャイル要求の企業バックログメタモデル
参考文献

お問い合わせ

内容についてのお問い合わせは、正誤表、追加情報をご確認後に、お送りいただくようお願いいたします。

正誤表、追加情報に掲載されていない書籍内容へのお問い合わせや
その他書籍に関するお問い合わせは、書籍のお問い合わせフォームからお送りください。

利用許諾に関するお問い合わせ

本書の書影（表紙画像）をご利用になりたい場合は書影許諾申請フォームから申請をお願いいたします。
書影（表紙画像）以外のご利用については、こちらからお問い合わせください。