IIBA日本支部BABOK-WG発表会「アジャイル要求分析」(2014年6月17日) 講演メイン資料(伊藤衡さん作成)
•Download as PPT, PDF•
5 likes•1,384 views
2014年6月17日に開催したIIBA日本支部BABOK-WG発表会「アジャイル要求分析」の資料を、発表者の伊藤衡さんの代理でアップロードしたものです。アジャイル全般からその中の要求分析で使われるテクニックを2時間でカバーするワークショップで使用しました。
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to IIBA日本支部BABOK-WG発表会「アジャイル要求分析」(2014年6月17日) 講演メイン資料(伊藤衡さん作成)
Similar to IIBA日本支部BABOK-WG発表会「アジャイル要求分析」(2014年6月17日) 講演メイン資料(伊藤衡さん作成) (20)
More from 林 光一郎
Recently uploaded
Recently uploaded (10)
IIBA日本支部BABOK-WG発表会「アジャイル要求分析」(2014年6月17日) 講演メイン資料(伊藤衡さん作成)
- 1. アジャイル要求分析
- 2. グループ内自己紹介（ 5 分） ■ 名前・所属 ■ 業務内容 ■ アジャイル知識・経験 2
- 3. 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
- 4. Agile に する対 誤解 アジャイル・ プログラミン グ手法を使い たまえ。 お言葉ですが、アジャイ ル手法を使っても少人数 で多くの仕事ができるわ けではありません。 なら、それができる手法 を見つけてこい。 ウチもアジャイル・プログ ラミング手法を採用する！ 今後一切計画やドキュメ ント作成は禁止！コー ディングとデバッグのみ とする。 アジャイル 様々だね 君、勉強 になった ろう ボス。３人 の要員追加 をお願いし ます。 出典 : DILBERT: © Scott Adams/Dist. by United Feature Syndicate, Inc. 4
- 5. Agile に する対 誤解 ■ ドキュメントを作成しない？ ● 文書作成より対話に時間を割くことで新たな気づきを得る ■ 要求定義をしない？ ● 要求を確定せずに、バックログで継続的に管理する ■ 計画をたてない？ ● リリース計画は柔軟、スプリント計画は厳格 ■ 設計書を書かない？ ● スプリント 0 ■ PMBOK と対立する？ ● そうかも？ ■ 少ない資源で早く開発できる？ ● 製品全体を短期で開発できる小さい単位に分ける ■ 問題解決が素早くできる？ ● 問題を早期に発見できる！ 5
- 7. の い規範 違 計画駆動 変化駆動 計画通りの実行（問題解決）が目的 想定外から学習（課題発見）が目的 必要なことを知っていることが前提 必要なことを知らないことが前提 早期に結論を出す 結論を出さずに変化に対応する 文書をしっかり書けば意図は一意に伝わる いくら言葉を選んでも意図は一意に伝わらない 作業が価値（完了作業を測る） 製品が価値（残り作業を測る） 役割分担をする 役割を固定せずチームで協力する 指示命令による秩序形成 自己組織化による秩序形成 最少の時間とコストで機能を最大化 最小の機能でビジネス価値を最大化 客観的指標によりテスト結果を評価 主観的観点から製品そのものを評価 事前にリスクを識別して対応する リスクを取らないことが最大のリスク 製品に完成形がある 製品に完成形はない 7 思考 行動 行動 学習
- 8. トヨタ生産方式（ 1978 年） ■ 少品種大量生産（計画駆動）のフォード生産方式に対するアンチテーゼとして多品 種少量生産（変化駆動）への挑戦 8
- 9. LEAN とは？ • 必要なものだけをいかに少ない人間で作り出すか（ 36 ページ）徳川家康が子供のときに、石 合戦を見ていて、人数の少ないほうが勝つと言い当てた（ 46 ページ） • コンピュータの生み出す過剰の情報は生産現場にとって不要なものが相当に多い。早すぎる 情報は、必要以上に早く原材料を手配させてムダをもたらす。多すぎる情報は生産現場を混 乱に陥れる（ 84 ページ） • 設備の価値は使用した年数や型式の古さなどで決まるものではなく、どれだけ稼ぐ力を維持 しているかによって決まる（中略）十分な保全さえ実施しておれば、たとえその保全に費用 が発生しようとも、買い替えたほうが安くつくなどという話はありえぬ（ 115 ページ） • 工数さえ減らすことができれば、原価低減が達成できると思っている人が多い。ところが、 結果をみると、原価は少しも安くなっていない。むしろ上がってしまっていることが多いの である。（ 208 ページ） • いちいち脳までいかずに反射中枢で折り返して、瞬時に対応する反射神経を企業がもってい なければならない（中略）計画を変更するのにも、大脳の命令が出なければやれない、つま り、生産管理部が伝票を切る、計画変更書を出す、そんなことをやらなければ動き出せない ようでは、企業はヤケドや大けがから免れることはできないし、大きなチャンスを逃がして しまう（ 83 ページ） • 持続性をもたないスピードがいかに無意味のものであるかは、私どもが子供のときから聞い てよく知っている「兎と亀」の話で十分であろう（ 113 ページ）
- 10. グループ議論（ 10 分） ■ アジャイルアプローチに関する疑問は？ 10
- 11. Agile をやらない理由 ■ 専属メンバーでないとできない？ ■ 初心者メンバーではできない？ ■ チームのやる気やプロ意識が高くないとできない？ ■ 顧客の積極的参画がないとできない？ ■ コロケーションしないとできない？ ■ 大規模プロジェクトではできない？ ■ 短いプロジェクトでは不要？ ■ マネジメントがチームを監視できない？ ■ プロセスや文書の規定が厳しい組織ではできない？ ■ 小単位での漸進的な開発ができない？ 11 やらない は にある理由 無限 ！
- 12. スクラム概要 12
- 14. 3 つの役割 ■ スクラムマスター（ SM ） ● 開発プラクティスのルール遵守とチームの生産性を最大化する責任を負う（チームに 1 人） ● チームの自律的な創造と革新、 PO とチームのコラボレーションを支援する ■ プロダクトオーナー（ PO ） ● 製品のビジネス価値を最大化する責任を負う（１人） ● 製品ビジョンを描き、ステークホルダーに周知する ● PBL 項目の優先順位とリリースの受入れを決定する ■ 開発チーム ● スプリント内の開発責任を負う（ 9 人以内） ● 開発の進捗を見える化し、問題を解決する ● PBL 項目の実装期間を見積りリリースをコミットする 14
- 15. BABOK 6.1 BABOK 6.1 スプリント 計画 第１部 ■ PO ● プロダクトバックログからスプリントで実装する要求項目を選択する ● 各バックログ項目の受け入れ条件を決定する バックログ項目 1 ２バックログ項目 1 ２ バックログ項目 2 ２バックログ項目 2 ２ バックログ項目 3 ５バックログ項目 3 ５ バックログ項目 4 ５バックログ項目 4 ５ バックログ項目 5 １バックログ項目 5 １ 15 時間制限によって、プロジェクトチー ムが一定時間に完了できる作業量を基 にして要求に優先順位が付けられる。 ベロシティ 10pt なら？ ストーリー ポイント
- 16. スプリント 計画 第２部 ■ 開発チームがどのように実現するかを決める ■ プロダクトバックログ項目をタスクに分割して理想時間（※）で見積もる ■ タイムボックスに収まらない場合は PO に相談する ※ ）中断なく実施した場合にかかる作業正味時間 16
- 17. デイリースクラム ■ 毎日、同じ時間、同じ場所で開発チームが主体的に実施 ● コミュニケーションの改善 ● 他ミーティングの防止 ● 開発の障害の特定および排除 ● 迅速な意思決定 ■ ３つの事について話す ● 前回からやったこと ● 次回までにやること ● 問題点 17
- 18. スプリント レビュー・ ■ 開発チーム ● スプリントの成果と未完了タスクを示す ● PO からのフィードバックにより価値の共通認識を持つ ● 顧客への価値提供を実感する ■ PO ● 動く成果物に対するフィードバックをする ● 必要な人を招待する ● 成果の受入れ可否を決定する ● スプリントの結果をプロダクトバックログに反映する ● リリース日を予測する 18 BABOK 7.5 BABOK 7.5 ソリューションがビジネスニーズを 満たしていることの妥当性を確認し 、識別した欠陥に対する最も適切な 対応を決定する
- 19. ■ 各スプリント後にチーム全員が参加して実施 ■ 良かったこと、改善点を特定する ■ 実施可能な改善案を決める スプリント レトロスペクティブ・ Keep 続けること Drop 止めること Start 始めること 19
- 20. 月 火 水 木 金 1 週目 朝会（ 15 分） 朝会（ 15 分） スプリント計画 1 部 開発 開発 スプリント計画 2 部 2 週目 朝会（ 15 分） 朝会（ 15 分） 朝会（ 15 分） 朝会（ 15 分） 朝会（ 15 分） 開発 開発 開発 開発 開発 3 週目 朝会（ 15 分） 開発 ｽﾌﾟﾘﾝﾄﾚﾋﾞｭｰ （ 2 時間） ﾚﾄﾛｽﾍﾟｸﾃｨﾌﾞ （ 2 時間） スプリントの２週間 例 20
- 21. グループ議論（ 10 分） ■ スクラム実践に関する疑問は？ 21
- 23. インセプションデッキ ■ WHY ● 我々はなぜここにいるのか？ ● エレベーターピッチ（★は★をしたい★のために★を提供し★と違い★ができます） ● 製品パッケージ ● やらないことリスト ● （いざというときに頼りになる）近隣者を見つける ■ HOW ● 解決策は何か？ ● 心配事は何か？ ● 何カ月かかるか？ ● 何を諦めるか？ ● いくらかかるか？ 23 BABOK 5.4 BABOK 5.4 本タスク（ソリューションスコープの定義）の 目的は、推奨するソリューションを概念化して 記述することである。その記述は、イニシアチ ブがどの新しいビジネスの能力をデリバリする かについてステークホルダーが理解できるよう 、十分に詳細なものでなければならない。
- 24. ユーザーストーリーの品質特性（ INVEST ） ■ Independent （独立性） ● 他のストーリーとの依存関係が少ないか？ ■ Negotiable （交渉可能性） ● 実現方法の代替案が出せるか？ ■ Valuable （価値） ● ビジネス価値に関連するか？ ■ Estimatable （見積り可能） ● 実装工数をチームがＴシャツサイズで見積もれるか？ ■ Small （小さい） ● タイムボックスに入りきらなければ分解する ■ Testable （テスト可能） ● Done の定義 24 BABOK 6.5 BABOK 6.5 BA は、ドメイン SME や実装 SME とこのタ スク（要求検証）を完了する重要な責任を 負う。他のステークホルダーは、要求コ ミュニケーションで要求の問題点を指摘す る。つまりプロジェクトの全ステークホル ダーがこのタスクに参加する。
- 25. Vertical Slice ■ 骨組みと肉付けで分ける ■ 業務フロー（受注、梱包、配送、請求等）で分ける ■ CRUD （作成、参照、更新、削除）で分ける ■ ユーザータイプ（一般、管理者等）で分ける ■ プラットフォーム（ Android 、 iOS 、 Web ブラウザ等）で分ける ■ 受け入れテストを参考に分ける 25 BABOK 9.22 BABOK 9.22 垂直プロトタイプは、システム全体の 機能性に関して、深く、通常は狭い断 面をモデリングする。
- 26. リリース３ ■ 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 BABOK 7.2 BABOK 7.2 プロジェクトの各イテレーションにどの要求を入れ るかについて決定する。この決定を左右する要因に は、プロジェクトの全体予算、ソリューションが必 要になる期限、リソースの制約条件、教育スケ ジュール、タイムボックス内でビジネスが変更を受 け入れる能力など、数多くのものがある。
- 27. Focus On / Focus Off ■ 製品やサービスのトレードオフに着眼して「○○より ×× 」という表現で重視する 点と犠牲にする点を明確化する。 ● 「快適性」＜「燃費」 ● 「セキュリティ」＜「使いやすさ」 ● 「機能」＜「デザイン」 ● 「新規顧客」＜「従来顧客」 ● 「効率」＜「効果」 27 BABOK 4.2 BABOK 4.2 トレーサビリティには、後方トレーサビ リティ（起源をたどること）と前方ト レーサビリティ（割り当て先をたどるこ と）、および他の要求との関連がある。
- 28. Minimum Marketable Feature （ MMF ） ■ 開発製品の MMF （最小商品機能）と追加機能を分けることで、大枠の優先順位を決 める。 製品 MMF 追加機能 携帯 通話機能、電話番号簿、留守電 カメラ、音楽、地図、 GPS 車 移動能力、法定準拠、安全性 エアコン、燃費、見た目、走行性能、乗り心地 ATM 現金引出し、残高表示、強固、情報安全性 現金預金、小切手預金、引出し額記憶機能 28 BABOK 6.2 BABOK 6.2 このタスク（要求の体系化）のアウトプットは、体系化された要 求の構造とそれらの関係を文書化したものである。これは、要求 間の関連を示すトレース図とは異なり、特定の要求がどこに属す かを確認するために利用する。
- 29. プランニング ポーカー・ ■ 見積もりツールではなく、前提条件や制約条件を確認するためのファシリテーションツール ■ 使い方 ● 基準となる小さいストーリーを決めて SP １とする ● 他のストーリを相対的に見積もる ● 意見がばらついた場合は、最大値／最小値それぞれの見解を述べる ● あまり大きい数字になる場合はストーリーの分割を検討する ● すべてが見積もれたら、同じ規模同士でグルーピングして一貫性をチェックする。 29 BABOK 6.4 BABOK 6.4 前提条件と制約条件は要求ではないが「第４章 要求のマネジメントとコミュニケーション」のタ スクによって、要求と同様に扱うことができる
- 31. の事例：森 幼稚園 • 道具も遊具も指示も与えずに、毎日自然の森で活動する幼稚園。子供たちは、自分達で活動 内容を考えて、意見をまとめ、枯れ枝や落ち葉で遊び道具を作って、自由に遊ぶ。 • 森のなかには危険がつきものだが、子どもたちは体を使って自分の限界を学び、さらにその 限界を克服して自信を身につける。四季の移り変わりを体で感じながら、創造力、身体能力 、精神と体のバランス、社会性などの能力を最大限発揮できる。 • デンマークで発祥し、ドイツで広まり、日本でも全国に活動が広がっているが、日本の幼稚 園は教育基本法において、園舎の設置義務があるため、森の幼稚園は認可が難しいという問 題がある。 31
- 32. アジャイル コミュニケーション・ ■ 自己組織化を促進する具体的方法 ● カードの活用（不確定な情報は文書にしない） ● 浸透（ Osmotic ）コミュニケーション ● インフォメーション・ラジエーター ● Fist of 5 （賛成・支持・心配・反対・ありえない） ● Caves & Common 32
Editor's Notes
- 事前課題 現在携わっている開発案件の概要（目的、内容、期間、人数） 開発案件の背景（きっかけ、ステークホルダー、現在の作業フェーズ） 現状の課題（技術、組織、プロセス等に関する具体的なエピソード）
- 隠れてやる 標準プロセスの適用が免除されるトラブルプロジェクトでやる 専門家による革新的（実験的）プロジェクトでやる 協力してくれる経営陣を見つける 啓蒙ではなく大衆化する 適用前にすべての問題を解決しようとせずまず始めてみる 「本当に必要か？」→「最も簡単な手段は？」＝「必要十分」 リリース計画とスプリント計画にWF-PMを招く 検査→適用サイクルのリズムをつくる（簡単な改善の繰り返し） チーム外に原因があればすぐエスカレートする 態度をよく観察する プロジェクト・レトロスペクティブに全員を招く
- 隠れてやる 標準プロセスの適用が免除されるトラブルプロジェクトでやる 専門家による革新的（実験的）プロジェクトでやる 協力してくれる経営陣を見つける 啓蒙ではなく大衆化する 適用前にすべての問題を解決しようとせずまず始めてみる 「本当に必要か？」→「最も簡単な手段は？」＝「必要十分」 リリース計画とスプリント計画にWF-PMを招く 検査→適用サイクルのリズムをつくる（簡単な改善の繰り返し） チーム外に原因があればすぐエスカレートする 態度をよく観察する プロジェクト・レトロスペクティブに全員を招く
- １週間スプリントの例になります。全てのイベントを実施します。 またスクラムではタイムボックスを重視しています。タイムボックスは常に固定で、リズムを作り出します。 リズムに乗る事で集中して作業を行う事を促します
- 隠れてやる 標準プロセスの適用が免除されるトラブルプロジェクトでやる 専門家による革新的（実験的）プロジェクトでやる 協力してくれる経営陣を見つける 啓蒙ではなく大衆化する 適用前にすべての問題を解決しようとせずまず始めてみる 「本当に必要か？」→「最も簡単な手段は？」＝「必要十分」 リリース計画とスプリント計画にWF-PMを招く 検査→適用サイクルのリズムをつくる（簡単な改善の繰り返し） チーム外に原因があればすぐエスカレートする 態度をよく観察する プロジェクト・レトロスペクティブに全員を招く
- Inception（最初の） Deck（カードの一揃い）
- 関係性によるダイナミックな秩序形成 エチオピア、アジスアベバの交差点 （ジャズ即興、社会性昆虫、鳥の群れ） 前パスできない（横連携）、監督はスタンド 自動追尾ミサイル（Moving Target） すべてのものは常に変化する（諸行無常） 完成型はない、不調和の美（自然との対話）