ソフトウェア調達におけるアジャイル開発の要点と現状 Slideshare
•
0 likes•2,480 views
ISACA大阪支部１０月度月例会でお話しさせていただいた内容です。 開催要項はこちら。 http://www.isaca-osaka.org/info/isacay1210.htm
Recommended
More Related Content
What's hot
What's hot (18)
Viewers also liked
Viewers also liked (20)
Similar to ソフトウェア調達におけるアジャイル開発の要点と現状 Slideshare
Similar to ソフトウェア調達におけるアジャイル開発の要点と現状 Slideshare (20)
ソフトウェア調達におけるアジャイル開発の要点と現状 Slideshare
- 1. ソフトウェア調達における アジャイル開発の要点と現状 2012年10月17日 株式会社ジャムズ 玉牧陽一 @Jamzz
- 2. Ⅰ.ソフトウェア調達にかかわる状況変化 2
- 3. １．供給不足の時代 • 絶対的に供給が不足している • 需要側の選択肢が少ない • 供給＝調達しただけの価値がある • 供給側に主導権がある • 製造業のパラダイムは科学的管理法 – フレデリック・テーラー – フォード生産方式、PUSH型、コンベヤー方式 – 少品種、大量生産のモデル 3
- 4. ２．供給過剰・需要多様化の時代 • 供給は満ち足りている • 需要側の選択肢が豊富 • 調達ではなく、活用により価値を生む • 需要側に主導権がある • 製造業のパラダイムはトヨタ生産方式 – 大野耐一 – PULL型、サプライチェーン – 多品種、少量生産のモデル 4
- 5. ３．パラダイムの変化 • 所有から利用へ – ソフトウェア資産価値（時価）は急速に減少 – 相対的にストックよりもフローを重視 – クラウドの本質も所有から利用へのシフト • 市場主導でスピーディーに適応 – 市場の変化に対応するチャレンジが必要 – 大きなバッチサイズによる長いリードタイム、 在庫、仕掛がリスク 5
- 6. ４．米国防省における調達の変遷 • 1970年発表「Managing the Development of Large Software Systems」by Winston Royce • 米国防総省の規格書「DOD-STD-2167」 （1985年6月） • 米国防総省「MIL-STD-498」（ 1994年12 月） • CMU/SEI「Considerations for Using Agile in DoD Acquisition 」（CMU/SEI-2010-TN-002, 2010 年4月） 6
- 7. Ⅱ.アジャイル開発の概要 7
- 8. １．アジャイル開発とは • 1990年代中ごろ • CMMやウォーターフォールなど、重量ソ フトウェア開発手法への疑問 – エクストリームプログラミング – クリスタルクリア – スクラム • 製造業からの影響 – リーン（トヨタ生産方式） 8
- 9. １．アジャイル開発とは • アジャイルソフトウェア開発宣言（2001 年） 私たちは、ソフトウェア開発の実践 あるいは実践を手助けをする活動を通じて、 よりよい開発方法を見つけだそうとしている。 この活動を通して、私たちは以下の価値に至った。 – プロセスやツールよりも個人と対話を、 – 包括的なドキュメントよりも動くソフトウェアを、 – 契約交渉よりも顧客との協調を、 – 計画に従うことよりも変化への対応を、 価値とする。すなわち、左記のことがらに価値があることを 認めながらも、私たちは右記のことがらにより価値をおく。 9
- 10. １．アジャイル開発とは • アジャイル開発における実行可能なイン クリメンタルリリースのイメージ 10
- 11. １．アジャイル開発とは • ウォーターフォール開発における開発進 捗と成果物利用価値の関係 11
- 12. １．アジャイル開発とは • アジャイル開発における開発進捗と成果 物利用価値の関係 12
- 13. １．アジャイル開発とは • 設計進捗状況に応じた変更に要するエフ ォート変化の比較イメージ 13
- 14. ２．スクラム • スクラムのプロセス スクラムマスター 管理者 プロダクトオーナー スクラムチームメンバ 14
- 15. ２．スクラム • スクラムにおけるロール – 管理者 • プロジェクトに対する最終的な責任を持つ – プロダクトオーナー • 要求をプロダクトバックログとして管理する – スクラムマスター • スプリントを運営するスクラムチームのリーダー – スクラムチームメンバ • プロジェクトのために集められた開発担当者 15
- 16. ２．スクラム • スクラムのプラクティス – プロダクトバックログ • プロジェクトの成果となるビジネス上、技術上の 機能要求のリストである • 一人のプロダクトオーナーにより管理される • プロダクトオーナーが継続的に、優先順位を見直 し、ボリュームの見積もりを更新して維持される • スクラムチームに対する要求は全てこれにより管 理され、これ以外の要求は受け入れられない • スクラムチーム自身で発見した機能要求もプロダ クトバックログにより管理される 16
- 17. ２．スクラム – スクラムマスター • スクラムチームのリーダーとして特別の役割を担 う • 日次スクラムミーティングを主催し、常にチーム の状態、特にチームにおける障害を把握する • 主体的にチームの障害を取り除いたり、チームを 支援するために行動する • 必要に応じて管理者などのチーム外との交渉、調 整を行う 17
- 18. ２．スクラム – スクラムチーム • メンバはスプリント目標をコミットし、その達成 のために主体的にチームに貢献する • スプリント目標達成のために効果的だと判断する ものは何でも要求することができる絶対的な権限 が与えられる • 場合によっては顧客やユーザの代表なども含む５ から７人程度の人員で構成される • 各メンバがチーム内で固定的な役割を持つのでは なく状況に応じて自己組織化を行う 18
- 19. ２．スクラム – スプリント計画ミーティング • プロダクトオーナー、管理者、ユーザの代表など とともに次のスプリントで対象とするプロダクト バックログの選択する • 対象とするプロダクトバックログを包括する様に スプリントの目標の設定を行う • スクラムチームでスプリントの目標を達成するた めの見積もりを含むタスクのリストであるスプリ ントバックログを作成する 19
- 20. ２．スクラム – スプリント • スクラムチームはスプリントの目標コミットし、 その達成のために全力を尽くす責任を負う • スプリント中には誰もスクラムチームに干渉する ことは許されない • スプリントの目標を達成することが難しいと判断 した場合にスクラムチームは直ちにスプリントを 中止することができる • 状況の変化により現在のスプリントの目標の意味 が変化した場合にプロダクトオーナーはスプリン トを中止することができる 20
- 21. ２．スクラム – 日次スクラムミーティング • 毎日決まった場所で決まった時間に約１５分程度 の状況確認ミーティングを行う • スクラムマスターが主催と進行を行う • スクラムチームメンバ各自一人ずつ「前回のミー ティングから何を行ったか」「次回のミーティン グまでに何を行うつもりであるか」「作業場の障 害や懸念事項、改善提案など」について報告する • あくまでも情報の共有のための報告のみに集中し 可能な限り短時間で終了する 21
- 22. ２．スクラム – 日次スクラムミーティング（続き） • 議論や相談が必要な項目は別途フォローアップ ミーティングあるいは非公式な対話の場を設定す る • スクラムマスタはスクラムチームのサポートのた めの障害情報を収集する • スクラムチーム以外のメンバはプロジェクトの状 況を知るために参加することができるが、たとえ 上級管理職であっても発言は許されない 22
- 23. ２．スクラム – スプリントレビューミーティング • スプリントの成果を顧客、ユーザの代表、管理者、 プロダクトオーナーにレビューしてもらうミー ティング • スプリントの状況について簡単に報告し、スクラ ムチームがスプリントで行ったことを理解しても らう • スプリントの成果は動作するソフトウエアであり、 これをデモンストレーションする • レビューの結果として新たなプロダクトバックロ グなど、今後のスプリントのための情報を得る 23
- 24. ３．アジャイルに対する誤解と偏見 • 成果が保障されない – プロジェクトの目標の達成を追求する – 最善を尽くした結果を得る • 実績がない – 欧米ではメインストリームとなっている – 欧米でははやりすぎてポストアジャイルの議 論がメインとなっている – 日本では実績が少ないことは事実 24
- 25. ３．アジャイルに対する誤解と偏見 • 生産性を向上し納期を短縮化する – ムリ・ムダ・ムラを排除して最適化する – チームの能力を集合知として最大化して成果 に結び付ける – チームの主体的、継続的な学習と改善をプロ セスとして織り込む 25
- 26. ３．アジャイルに対する誤解と偏見 • 特殊な能力や経験が必要である – シンプルですぐに始められるプラクティス – 本質を理解していれば実践を通じて自然に身 に着く – やり方を変える場合の一般的な問題として、 従来の習慣が障害となる場合がある 26
- 27. ３．アジャイルに対する誤解と偏見 • 大規模では使えない – 大規模における本質的な困難さ以外に特性が あるわけではない – 大規模に対する手法と実績も確立されつつあ る • 分散開発では使えない – 分散開発における本質的な困難さにはアジャ イルのプラクティスが意味を持つ – オフショア開発などで実績がある 27
- 28. Ⅲ.アジャイル開発の実践 28
- 29. １．パラダイムとコンテキスト ウォーター スパイラル CCPM かんばん アジャイル フォール 問題領域 前提的 前提的 前提的 前提的 発見的 解決手段 前提的 前提的 発見的 発見的 発見的 問題・解決 PUSH型 PUSH型 PUSH型 PULL型 PULL型 の主体 トップダウン トップダウン トップダウン 現場主動 現場主動 ステップ、 工程、 バックログ、 バックログ、 マネージメ 工程、進捗 反復型 バッファー 見える化 タイムボックス ント マネージメント マネージメント マネージメント マネージメント マネージメント 29
- 30. ２．ウォーターフォール開発とアジャイル 開発の比較 ウォーターフォール アジャイル 管理対象 「作業」の分割統治 「成果」の分割統治 管理サイクル マイルストーン タイムボックス 工程表 バックログ 進捗管理 消化率 バーンダウン プロジェクトをコント 環境、条件を調整してメンバ PMの役割 ロール の活動を支援 事前に要求の範囲とレベ 都度状況に応じて要求の優先 顧客の役割 ルを明確にし、成果物を 順位を明確にし、その達成を 確認 確認 30
- 31. １．ウォーターフォール開発のポイント • 利点 – 実績、経験が豊富である – 工程管理の知見が活用できる – ドキュメントにより情報を形式知として時空 を超えて共有することを可能にする – 専門性による作業の効率化 31
- 32. １．ウォーターフォール開発のポイント • 難点 – 初期の要求がなかなか確定しない場合 – 後の工程になって要求が変更になる場合 – 事前に予見しきれない技術課題 – リスク管理とその運用の難しさ – コミュニケーションの質の悪化 – 官僚的な追加作業 32
- 33. １．ウォーターフォール開発のポイント • 典型的な失敗 – 要件定義が終わらない – 工程管理の無駄 • 「念のため」が積み重なる傾向がある – 使われないシステム • 当初の思惑と実際が異なる場合 • 長期開発では開発中に前提条件が変わる場合があ る 33
- 34. ２．アジャイル開発のポイント • 利点 – 現場状況のリアルタイムな把握 – 打ち手の迅速な反映 – ベストエフォートで合理的な成果 – 主体性重視とモチベーション – 情報共有、コミュニケーションの質的充実 34
- 35. ２．アジャイル開発のポイント • 難点 – 委託業務上の課題 • イテレーション単位での請負契約が煩雑になる • 準委任契約が望ましい • 社内標準との整合が難しい場合がある – 品質保証基準の確立 • 品質基準の定義が統計的手法による場合にはやり 方が変わることにより指標の継続性が維持できな い 35
- 36. ２．アジャイル開発のポイント – パラダイムシフトに対応する意識の変化 • 受身から主体へ • 作業から成果へ • 個人主義からチームワークへ 36
- 37. ２．アジャイル開発のポイント • 典型的な失敗 – やりっぱなし • バックログに「作業」を設定した場合に起こる • 「成果」の妥当性評価と「ふりかえり」が重要 – 要求が定まらず、終わらない • 根本原因は要求として期待する「成果」の設定と その優先順位づけにある • たとえ顧客の要望であったとしても達成感が得ら れないプロジェクトはつらい • 主体的に顧客価値を考えた提案も重要 37
- 38. ３．ウォーターフォール開発とアジャイル 開発の使い分け • ウォーターフォール開発を適用する場合 – 経験豊富で予見性が高い場合 – 再現性の高い作業の集約で計画できる場合 – 大量な単純作業で労働集約的な場合 38
- 39. ３．ウォーターフォール開発とアジャイル 開発の使い分け • アジャイル開発を適用する場合 – 小規模、少人数の場合 – 不確定要素が多く予見性が低い場合 – リスクが高く従来のやり方が通用しないこと が明らかな場合 – 継続的に保守、拡張するシステムの場合 – チームメンバの知識や経験を持ち寄って探索 的な試行錯誤が必要な場合 39
- 40. Ⅳ.まとめ 40
- 41. ３．まとめ • アジャイル開発は今の時代を反映したソ フトウェア製造方法である • 従来の工程中心のマネージメントは通用 しなくなるが、現物を効果的に評価する 手法が確立されつつある • 最近はプロジェクト単位を超えた、企業 レベルでの一連のプロジェクトや組織中 心のプロジェクトマネージメントに関す る議論が中心となっている 41
- 42. Ⅴ.質疑応答 42