アジャイル要求分析

グループ内自己紹介（ 5分）

■ 名前・所属■ 業務内容■ アジャイル知識・経験

2

3

自己紹介

伊藤　衡（ Ko Ito）MBA, PMP, CBAP, PMI-ACP, CSM

学歴● 1986 早稲田大学 理工学部 数学科 卒業● 2007 早稲田大学大学院 アジア太平洋研究科 国際経営学専攻 卒業● 2013 東京工業大学大学院 イノベーションマネジメント研究科 単位取得退学

職歴● 日本ディジタルイクイップメント（ 10年）

● グローバルナレッジネットワーク（ 4年）● 日本ヒューレットパッカード（ 1.5年）● インテル（ 5年）● ケプナートリゴージャパン（ 2.5年）● 富士ゼロックス総合教育研究所（ 5年）● 産業技術大学院大学 客員教授● 2014.7 ～ ボツワナ公務員大学（ JICAシニア海外ボランティア）

ko.ito2

Agileに する対 誤解

アジャイル・プログラミング手法を使いたまえ。

お言葉ですが、アジャイル手法を使っても少人数で多くの仕事ができるわけではありません。

なら、それができる手法を見つけてこい。

ウチもアジャイル・プログラミング手法を採用する！

今後一切計画やドキュメント作成は禁止！コーディングとデバッグのみとする。

アジャイル様々だね

君、勉強になったろう

ボス。３人の要員追加をお願いします。

出典 : DILBERT: © Scott Adams/Dist. by United Feature Syndicate, Inc.

4

Agileに する対 誤解

■ ドキュメントを作成しない？● 文書作成より対話に時間を割くことで新たな気づきを得る

■ 要求定義をしない？● 要求を確定せずに、バックログで継続的に管理する

■ 計画をたてない？● リリース計画は柔軟、スプリント計画は厳格

■ 設計書を書かない？● スプリント 0

■ PMBOKと対立する？● そうかも？

■ 少ない資源で早く開発できる？● 製品全体を短期で開発できる小さい単位に分ける

■ 問題解決が素早くできる？● 問題を早期に発見できる！

5

と計画駆動 変化駆動

要求定義

設計

試作

テスト

受入れ

イテレーション１

イテレーション２

イテレーション３

イテレーション４

計画駆動

変化駆動

6

BABOK2.1

BABOK2.1 変化駆動アプローチは、ソリューションのデリバリ全般にわたって高い

不確実性を受け入れることと引き換えに、短いイテレーション（反復）で迅速にビジネスバリューを提供することに焦点を置く。このアプローチは、ベストソリューションを見つけようとする探索的なアプローチを用いる場合、あるいは既存のソリューションにインクリメンタルな改善を加える場合に選択することが多い

変化駆動アプローチは、ソリューションのデリバリ全般にわたって高い不確実性を受け入れることと引き換えに、短いイテレーション（反復）で迅速にビジネスバリューを提供することに焦点を置く。このアプローチは、ベストソリューションを見つけようとする探索的なアプローチを用いる場合、あるいは既存のソリューションにインクリメンタルな改善を加える場合に選択することが多い

の い規範 違

計画駆動 変化駆動計画通りの実行（問題解決）が目的 想定外から学習（課題発見）が目的必要なことを知っていることが前提 必要なことを知らないことが前提早期に結論を出す 結論を出さずに変化に対応する文書をしっかり書けば意図は一意に伝わる いくら言葉を選んでも意図は一意に伝わらない作業が価値（完了作業を測る） 製品が価値（残り作業を測る）役割分担をする 役割を固定せずチームで協力する指示命令による秩序形成 自己組織化による秩序形成最少の時間とコストで機能を最大化 最小の機能でビジネス価値を最大化客観的指標によりテスト結果を評価 主観的観点から製品そのものを評価事前にリスクを識別して対応する リスクを取らないことが最大のリスク製品に完成形がある 製品に完成形はない

7

思考 行動 行動 学習

トヨタ生産方式（ 1978年）

■ 少品種大量生産（計画駆動）のフォード生産方式に対するアンチテーゼとして多品種少量生産（変化駆動）への挑戦

8

LEANとは？

• 必要なものだけをいかに少ない人間で作り出すか（ 36ページ）徳川家康が子供のときに、石合戦を見ていて、人数の少ないほうが勝つと言い当てた（ 46ページ）

• コンピュータの生み出す過剰の情報は生産現場にとって不要なものが相当に多い。早すぎる情報は、必要以上に早く原材料を手配させてムダをもたらす。多すぎる情報は生産現場を混乱に陥れる（ 84ページ）

• 設備の価値は使用した年数や型式の古さなどで決まるものではなく、どれだけ稼ぐ力を維持しているかによって決まる（中略）十分な保全さえ実施しておれば、たとえその保全に費用が発生しようとも、買い替えたほうが安くつくなどという話はありえぬ（ 115ページ）

• 工数さえ減らすことができれば、原価低減が達成できると思っている人が多い。ところが、結果をみると、原価は少しも安くなっていない。むしろ上がってしまっていることが多いのである。（ 208ページ）

• いちいち脳までいかずに反射中枢で折り返して、瞬時に対応する反射神経を企業がもっていなければならない（中略）計画を変更するのにも、大脳の命令が出なければやれない、つまり、生産管理部が伝票を切る、計画変更書を出す、そんなことをやらなければ動き出せないようでは、企業はヤケドや大けがから免れることはできないし、大きなチャンスを逃がしてしまう（ 83ページ）

• 持続性をもたないスピードがいかに無意味のものであるかは、私どもが子供のときから聞いてよく知っている「兎と亀」の話で十分であろう（ 113ページ）

グループ議論（ 10分）

■ アジャイルアプローチに関する疑問は？

10

Agileをやらない理由

■ 専属メンバーでないとできない？■ 初心者メンバーではできない？■ チームのやる気やプロ意識が高くないとできない？■ 顧客の積極的参画がないとできない？■ コロケーションしないとできない？■ 大規模プロジェクトではできない？■ 短いプロジェクトでは不要？■ マネジメントがチームを監視できない？■ プロセスや文書の規定が厳しい組織ではできない？■ 小単位での漸進的な開発ができない？

11

やらない は にある理由 無限 ！

スクラム概要

12

スプリント

スクラムによる プロセス開発

プロダクトバックログ

スプリントレビュー

スプリント計画

開発

ﾃﾞｲﾘｰｽｸﾗﾑスプリントバックログ

リリース計画

要求事項ユーザストーリー

インクリメントリリース

•　ビジョン作成•　タイムボックス決定•　イテレーション決定•　メンバー決定

開発チーム

開発チームPOPO

SMSM

レトロスペクティブ

３つの役割４つのセレモニー３つのアーティファクト

スプリント計画 ﾃﾞｲﾘｰｽｸﾗﾑ

スプリントレビュー

スプリント計画 ﾃﾞｲﾘｰｽｸﾗﾑ

レトロスペクティブ

スプリントレビュー

スプリント計画 ﾃﾞｲﾘｰｽｸﾗﾑ

プロダクトバックログ

スプリントバックログ

インクリメントリリース

プロダクトバックログ

スプリントバックログ

3つの役割

■ スクラムマスター（ SM）● 開発プラクティスのルール遵守とチームの生産性を最大化する責任を負う（チームに 1人）● チームの自律的な創造と革新、 POとチームのコラボレーションを支援する

■ プロダクトオーナー（ PO）● 製品のビジネス価値を最大化する責任を負う（１人）● 製品ビジョンを描き、ステークホルダーに周知する● PBL項目の優先順位とリリースの受入れを決定する

■ 開発チーム● スプリント内の開発責任を負う（ 9人以内）● 開発の進捗を見える化し、問題を解決する● PBL項目の実装期間を見積りリリースをコミットする

14

BABOK6.1

BABOK6.1

スプリント 　計画 第１部

■ PO● プロダクトバックログからスプリントで実装する要求項目を選択する● 各バックログ項目の受け入れ条件を決定する

バックログ項目 1 　　２バックログ項目 1 　　２

バックログ項目 2 　　２バックログ項目 2 　　２

バックログ項目 3 　　５バックログ項目 3 　　５

バックログ項目 4 　　５バックログ項目 4 　　５

バックログ項目 5 　　１バックログ項目 5 　　１

15

時間制限によって、プロジェクトチームが一定時間に完了できる作業量を基にして要求に優先順位が付けられる。

ベロシティ10ptなら？

ストーリーポイント

スプリント 　計画 第２部

■ 開発チームがどのように実現するかを決める■ プロダクトバックログ項目をタスクに分割して理想時間（※）で見積もる■ タイムボックスに収まらない場合は POに相談する

※）中断なく実施した場合にかかる作業正味時間

16

デイリースクラム

■ 毎日、同じ時間、同じ場所で開発チームが主体的に実施● コミュニケーションの改善● 他ミーティングの防止● 開発の障害の特定および排除● 迅速な意思決定

■ ３つの事について話す● 前回からやったこと● 次回までにやること● 問題点

17

スプリント レビュー・

■ 開発チーム● スプリントの成果と未完了タスクを示す● POからのフィードバックにより価値の共通認識を持つ● 顧客への価値提供を実感する

■ PO● 動く成果物に対するフィードバックをする● 必要な人を招待する● 成果の受入れ可否を決定する● スプリントの結果をプロダクトバックログに反映する● リリース日を予測する

18

BABOK7.5

BABOK7.5

ソリューションがビジネスニーズを満たしていることの妥当性を確認し、識別した欠陥に対する最も適切な対応を決定する

■ 各スプリント後にチーム全員が参加して実施■ 良かったこと、改善点を特定する■ 実施可能な改善案を決める

スプリント レトロスペクティブ・

Keep

続けること

Drop

止めること

Start

始めること

19

月 火 水 木 金

1週目

朝会（ 15分） 朝会（ 15分）スプリント計画

1部開発 開発

スプリント計画2部

2週目

朝会（ 15分） 朝会（ 15分） 朝会（ 15分） 朝会（ 15分） 朝会（ 15分）

開発 開発 開発 開発 開発

3週目

朝会（ 15分）

開発

ｽﾌﾟﾘﾝﾄﾚﾋﾞｭｰ（ 2時間）ﾚﾄﾛｽﾍﾟｸﾃｨﾌﾞ（ 2時間）

スプリントの２週間 例

20

グループ議論（ 10分）

■ スクラム実践に関する疑問は？

21

Agile の要求分析プラクティス

22

インセプションデッキ

■ WHY● 我々はなぜここにいるのか？● エレベーターピッチ（★は★をしたい★のために★を提供し★と違い★ができます）● 製品パッケージ● やらないことリスト● （いざというときに頼りになる）近隣者を見つける

■ HOW● 解決策は何か？● 心配事は何か？● 何カ月かかるか？● 何を諦めるか？● いくらかかるか？

23

BABOK5.4

BABOK5.4

本タスク（ソリューションスコープの定義）の目的は、推奨するソリューションを概念化して記述することである。その記述は、イニシアチブがどの新しいビジネスの能力をデリバリするかについてステークホルダーが理解できるよう、十分に詳細なものでなければならない。

ユーザーストーリーの品質特性（ INVEST）

■ Independent（独立性）● 他のストーリーとの依存関係が少ないか？

■ Negotiable（交渉可能性）● 実現方法の代替案が出せるか？

■ Valuable（価値）● ビジネス価値に関連するか？

■ Estimatable（見積り可能）● 実装工数をチームがＴシャツサイズで見積もれるか？

■ Small（小さい）● タイムボックスに入りきらなければ分解する

■ Testable（テスト可能）● Doneの定義

24

BABOK6.5

BABOK6.5

BAは、ドメイン SMEや実装 SMEとこのタスク（要求検証）を完了する重要な責任を負う。他のステークホルダーは、要求コミュニケーションで要求の問題点を指摘する。つまりプロジェクトの全ステークホルダーがこのタスクに参加する。

Vertical Slice

■ 骨組みと肉付けで分ける■ 業務フロー（受注、梱包、配送、請求等）で分ける■ CRUD（作成、参照、更新、削除）で分ける■ ユーザータイプ（一般、管理者等）で分ける■ プラットフォーム（ Android、 iOS、Webブラウザ等）で分ける■ 受け入れテストを参考に分ける

25

BABOK9.22

BABOK9.22 垂直プロトタイプは、システム全体の

機能性に関して、深く、通常は狭い断面をモデリングする。

リリース３

■ POは、チームを交えてユーザーストーリーに以下の観点を考慮して優先順位をつける● ビジネス価値や制約● 実装の視点（ストーリーポイントとベロシティ）● PBL項目間の依存関係

■ 優先順位に基づき、ユーザーストーリーを適切なリリースに配置してリリース日を決める

■ リリース計画は定期的に更新する

リリース計画

リリース２

リリース１

スプリント１

スプリント 2

スプリント 3

User Story-C

User Story-Ｂ

User Story-A

User Story-E

User Story-F

User Story-D

User Story-I

User Story-G

User Story-H

26

BABOK7.2

BABOK7.2

プロジェクトの各イテレーションにどの要求を入れるかについて決定する。この決定を左右する要因には、プロジェクトの全体予算、ソリューションが必要になる期限、リソースの制約条件、教育スケジュール、タイムボックス内でビジネスが変更を受け入れる能力など、数多くのものがある。

Focus On / Focus Off

■ 製品やサービスのトレードオフに着眼して「○○より××」という表現で重視する点と犠牲にする点を明確化する。● 「快適性」＜「燃費」● 「セキュリティ」＜「使いやすさ」● 「機能」＜「デザイン」● 「新規顧客」＜「従来顧客」● 「効率」＜「効果」

27

BABOK4.2

BABOK4.2

トレーサビリティには、後方トレーサビリティ（起源をたどること）と前方トレーサビリティ（割り当て先をたどること）、および他の要求との関連がある。

Minimum Marketable Feature（ MMF）

■ 開発製品のMMF（最小商品機能）と追加機能を分けることで、大枠の優先順位を決める。

製品 MMF 追加機能

携帯 通話機能、電話番号簿、留守電 カメラ、音楽、地図、 GPS車 移動能力、法定準拠、安全性 エアコン、燃費、見た目、走行性能、乗り心地

ATM 現金引出し、残高表示、強固、情報安全性 現金預金、小切手預金、引出し額記憶機能

28

BABOK6.2

BABOK6.2

このタスク（要求の体系化）のアウトプットは、体系化された要求の構造とそれらの関係を文書化したものである。これは、要求間の関連を示すトレース図とは異なり、特定の要求がどこに属すかを確認するために利用する。

プランニング ポーカー・

■ 見積もりツールではなく、前提条件や制約条件を確認するためのファシリテーションツール■ 使い方● 基準となる小さいストーリーを決めて SP１とする● 他のストーリを相対的に見積もる● 意見がばらついた場合は、最大値／最小値それぞれの見解を述べる● あまり大きい数字になる場合はストーリーの分割を検討する● すべてが見積もれたら、同じ規模同士でグルーピングして一貫性をチェックする。

29

BABOK6.4

BABOK6.4

前提条件と制約条件は要求ではないが「第４章　要求のマネジメントとコミュニケーション」のタスクによって、要求と同様に扱うことができる

自己組織化

30

「計画どおりにやるのがよいことだ」とか「計画変更は恥かしいことだ」という言い方で、あらゆることに適応しようとする。先が完全に読み切れない以上、状況が変われば、やり方も変えていくのは当然であるし、また変化に対応できるよう現場の体質を作り上げていくこと、自分自身の頭脳を柔軟に保つことこそ大切なことである。　大野耐一『トヨタ生産方式』 92ページ

「計画どおりにやるのがよいことだ」とか「計画変更は恥かしいことだ」という言い方で、あらゆることに適応しようとする。先が完全に読み切れない以上、状況が変われば、やり方も変えていくのは当然であるし、また変化に対応できるよう現場の体質を作り上げていくこと、自分自身の頭脳を柔軟に保つことこそ大切なことである。　大野耐一『トヨタ生産方式』 92ページ

の事例：森 幼稚園

• 道具も遊具も指示も与えずに、毎日自然の森で活動する幼稚園。子供たちは、自分達で活動内容を考えて、意見をまとめ、枯れ枝や落ち葉で遊び道具を作って、自由に遊ぶ。

• 森のなかには危険がつきものだが、子どもたちは体を使って自分の限界を学び、さらにその限界を克服して自信を身につける。四季の移り変わりを体で感じながら、創造力、身体能力、精神と体のバランス、社会性などの能力を最大限発揮できる。

• デンマークで発祥し、ドイツで広まり、日本でも全国に活動が広がっているが、日本の幼稚園は教育基本法において、園舎の設置義務があるため、森の幼稚園は認可が難しいという問題がある。

31

アジャイル コミュニケーション・

■ 自己組織化を促進する具体的方法● カードの活用（不確定な情報は文書にしない）● 浸透（ Osmotic）コミュニケーション● インフォメーション・ラジエーター● Fist of 5（賛成・支持・心配・反対・ありえない）● Caves & Common

32