ソフトウェア調達における

アジャイル開発の要点と現状

2012年10月17日

株式会社ジャムズ

玉牧陽一

@Jamzz

Ⅰ.ソフトウェア調達にかかわる状況変化

2

１．供給不足の時代

• 絶対的に供給が不足している

• 需要側の選択肢が少ない

• 供給＝調達しただけの価値がある

• 供給側に主導権がある

• 製造業のパラダイムは科学的管理法

–フレデリック・テーラー

–フォード生産方式、PUSH型、コンベヤー方式

–少品種、大量生産のモデル

3

２．供給過剰・需要多様化の時代

• 供給は満ち足りている

• 需要側の選択肢が豊富

• 調達ではなく、活用により価値を生む

• 需要側に主導権がある

• 製造業のパラダイムはトヨタ生産方式

–大野耐一

– PULL型、サプライチェーン

–多品種、少量生産のモデル

4

３．パラダイムの変化

• 所有から利用へ

–ソフトウェア資産価値（時価）は急速に減少

–相対的にストックよりもフローを重視

–クラウドの本質も所有から利用へのシフト

• 市場主導でスピーディーに適応

–市場の変化に対応するチャレンジが必要

–大きなバッチサイズによる長いリードタイム、在庫、仕掛がリスク

5

４．米国防省における調達の変遷

• 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

１．アジャイル開発とは

• 1990年代中ごろ

• CMMやウォーターフォールなど、重量ソフトウェア開発手法への疑問

–エクストリームプログラミング

–クリスタルクリア

–スクラム

• 製造業からの影響

–リーン（トヨタ生産方式）

8

１．アジャイル開発とは

• アジャイルソフトウェア開発宣言（2001年）

私たちは、ソフトウェア開発の実践

あるいは実践を手助けをする活動を通じて、

よりよい開発方法を見つけだそうとしている。

この活動を通して、私たちは以下の価値に至った。

– プロセスやツールよりも個人と対話を、

– 包括的なドキュメントよりも動くソフトウェアを、

– 契約交渉よりも顧客との協調を、

– 計画に従うことよりも変化への対応を、 価値とする。すなわち、左記のことがらに価値があることを

認めながらも、私たちは右記のことがらにより価値をおく。

9

１．アジャイル開発とは

10

• アジャイル開発における実行可能なインクリメンタルリリースのイメージ

１．アジャイル開発とは

11

• ウォーターフォール開発における開発進捗と成果物利用価値の関係

１．アジャイル開発とは

12

• アジャイル開発における開発進捗と成果物利用価値の関係

１．アジャイル開発とは

13

• 設計進捗状況に応じた変更に要するエフォート変化の比較イメージ

２．スクラム

• スクラムのプロセス

プロダクトオーナー

管理者

スクラムマスター

スクラムチームメンバ

14

２．スクラム

• スクラムにおけるロール

–管理者

• プロジェクトに対する最終的な責任を持つ

–プロダクトオーナー

• 要求をプロダクトバックログとして管理する

–スクラムマスター

• スプリントを運営するスクラムチームのリーダー

–スクラムチームメンバ

• プロジェクトのために集められた開発担当者

15

２．スクラム

• スクラムのプラクティス

–プロダクトバックログ

• プロジェクトの成果となるビジネス上、技術上の機能要求のリストである

• 一人のプロダクトオーナーにより管理される

• プロダクトオーナーが継続的に、優先順位を見直し、ボリュームの見積もりを更新して維持される

• スクラムチームに対する要求は全てこれにより管理され、これ以外の要求は受け入れられない

• スクラムチーム自身で発見した機能要求もプロダクトバックログにより管理される

16

２．スクラム

–スクラムマスター

• スクラムチームのリーダーとして特別の役割を担う

• 日次スクラムミーティングを主催し、常にチームの状態、特にチームにおける障害を把握する

• 主体的にチームの障害を取り除いたり、チームを支援するために行動する

• 必要に応じて管理者などのチーム外との交渉、調整を行う

17

２．スクラム

–スクラムチーム

• メンバはスプリント目標をコミットし、その達成のために主体的にチームに貢献する

• スプリント目標達成のために効果的だと判断するものは何でも要求することができる絶対的な権限が与えられる

• 場合によっては顧客やユーザの代表なども含む５から７人程度の人員で構成される

• 各メンバがチーム内で固定的な役割を持つのではなく状況に応じて自己組織化を行う

18

２．スクラム

–スプリント計画ミーティング

• プロダクトオーナー、管理者、ユーザの代表などとともに次のスプリントで対象とするプロダクトバックログの選択する

• 対象とするプロダクトバックログを包括する様にスプリントの目標の設定を行う

• スクラムチームでスプリントの目標を達成するための見積もりを含むタスクのリストであるスプリントバックログを作成する

19

２．スクラム

–スプリント

• スクラムチームはスプリントの目標コミットし、その達成のために全力を尽くす責任を負う

• スプリント中には誰もスクラムチームに干渉することは許されない

• スプリントの目標を達成することが難しいと判断した場合にスクラムチームは直ちにスプリントを中止することができる

• 状況の変化により現在のスプリントの目標の意味が変化した場合にプロダクトオーナーはスプリントを中止することができる

20

２．スクラム

–日次スクラムミーティング

• 毎日決まった場所で決まった時間に約１５分程度の状況確認ミーティングを行う

• スクラムマスターが主催と進行を行う

• スクラムチームメンバ各自一人ずつ「前回のミーティングから何を行ったか」「次回のミーティングまでに何を行うつもりであるか」「作業場の障害や懸念事項、改善提案など」について報告する

• あくまでも情報の共有のための報告のみに集中し可能な限り短時間で終了する

21

２．スクラム

–日次スクラムミーティング（続き）

• 議論や相談が必要な項目は別途フォローアップミーティングあるいは非公式な対話の場を設定する

• スクラムマスタはスクラムチームのサポートのための障害情報を収集する

• スクラムチーム以外のメンバはプロジェクトの状況を知るために参加することができるが、たとえ上級管理職であっても発言は許されない

22

２．スクラム

–スプリントレビューミーティング

• スプリントの成果を顧客、ユーザの代表、管理者、プロダクトオーナーにレビューしてもらうミーティング

• スプリントの状況について簡単に報告し、スクラ

ムチームがスプリントで行ったことを理解してもらう

• スプリントの成果は動作するソフトウエアであり、これをデモンストレーションする

• レビューの結果として新たなプロダクトバックログなど、今後のスプリントのための情報を得る

23

３．アジャイルに対する誤解と偏見

• 成果が保障されない

–プロジェクトの目標の達成を追求する

–最善を尽くした結果を得る

• 実績がない

–欧米ではメインストリームとなっている

–欧米でははやりすぎてポストアジャイルの議論がメインとなっている

–日本では実績が少ないことは事実

24

３．アジャイルに対する誤解と偏見

• 生産性を向上し納期を短縮化する

–ムリ・ムダ・ムラを排除して最適化する

–チームの能力を集合知として最大化して成果に結び付ける

–チームの主体的、継続的な学習と改善をプロセスとして織り込む

25

３．アジャイルに対する誤解と偏見

• 特殊な能力や経験が必要である

–シンプルですぐに始められるプラクティス

–本質を理解していれば実践を通じて自然に身に着く

–やり方を変える場合の一般的な問題として、従来の習慣が障害となる場合がある

26

３．アジャイルに対する誤解と偏見

• 大規模では使えない

–大規模における本質的な困難さ以外に特性があるわけではない

–大規模に対する手法と実績も確立されつつある

• 分散開発では使えない

–分散開発における本質的な困難さにはアジャイルのプラクティスが意味を持つ

–オフショア開発などで実績がある

27

Ⅲ.アジャイル開発の実践

28

１．パラダイムとコンテキスト

ウォーターフォール

スパイラル CCPM かんばん アジャイル

問題領域 前提的 前提的 前提的 前提的 発見的

解決手段 前提的 前提的 発見的 発見的 発見的

問題・解決の主体

PUSH型 トップダウン

PUSH型 トップダウン

PUSH型 トップダウン

PULL型 現場主動

PULL型 現場主動

マネージメント

工程、進捗 マネージメント

ステップ、 反復型

マネージメント

工程、 バッファー

マネージメント

バックログ、 見える化

マネージメント

バックログ、

タイムボックスマネージメント

29

２．ウォーターフォール開発とアジャイル開発の比較

ウォーターフォール アジャイル

管理対象 「作業」の分割統治 「成果」の分割統治

管理サイクル マイルストーン タイムボックス

進捗管理 工程表 消化率

バックログ バーンダウン

PMの役割 プロジェクトをコントロール

環境、条件を調整してメンバの活動を支援

顧客の役割

事前に要求の範囲とレベルを明確にし、成果物を確認

都度状況に応じて要求の優先順位を明確にし、その達成を確認

30

１．ウォーターフォール開発のポイント

• 利点

–実績、経験が豊富である

–工程管理の知見が活用できる

–ドキュメントにより情報を形式知として時空を超えて共有することを可能にする

–専門性による作業の効率化

31

１．ウォーターフォール開発のポイント

• 難点

–初期の要求がなかなか確定しない場合

–後の工程になって要求が変更になる場合

–事前に予見しきれない技術課題

–リスク管理とその運用の難しさ

–コミュニケーションの質の悪化

–官僚的な追加作業

32

１．ウォーターフォール開発のポイント

• 典型的な失敗

–要件定義が終わらない

–工程管理の無駄

• 「念のため」が積み重なる傾向がある

–使われないシステム

• 当初の思惑と実際が異なる場合

• 長期開発では開発中に前提条件が変わる場合がある

33

２．アジャイル開発のポイント

• 利点

–現場状況のリアルタイムな把握

–打ち手の迅速な反映

–ベストエフォートで合理的な成果

–主体性重視とモチベーション

–情報共有、コミュニケーションの質的充実

34

２．アジャイル開発のポイント

• 難点

–委託業務上の課題

• イテレーション単位での請負契約が煩雑になる

• 準委任契約が望ましい

• 社内標準との整合が難しい場合がある

–品質保証基準の確立

• 品質基準の定義が統計的手法による場合にはやり方が変わることにより指標の継続性が維持できない

35

２．アジャイル開発のポイント

–パラダイムシフトに対応する意識の変化

• 受身から主体へ

• 作業から成果へ

• 個人主義からチームワークへ

36

２．アジャイル開発のポイント

• 典型的な失敗

–やりっぱなし

• バックログに「作業」を設定した場合に起こる

• 「成果」の妥当性評価と「ふりかえり」が重要

–要求が定まらず、終わらない

• 根本原因は要求として期待する「成果」の設定とその優先順位づけにある

• たとえ顧客の要望であったとしても達成感が得られないプロジェクトはつらい

• 主体的に顧客価値を考えた提案も重要

37

３．ウォーターフォール開発とアジャイル開発の使い分け

• ウォーターフォール開発を適用する場合

–経験豊富で予見性が高い場合

–再現性の高い作業の集約で計画できる場合

–大量な単純作業で労働集約的な場合

38

３．ウォーターフォール開発とアジャイル開発の使い分け

• アジャイル開発を適用する場合

–小規模、少人数の場合

–不確定要素が多く予見性が低い場合

–リスクが高く従来のやり方が通用しないことが明らかな場合

–継続的に保守、拡張するシステムの場合

–チームメンバの知識や経験を持ち寄って探索的な試行錯誤が必要な場合

39

Ⅳ.まとめ

40

３．まとめ

• アジャイル開発は今の時代を反映したソフトウェア製造方法である

• 従来の工程中心のマネージメントは通用しなくなるが、現物を効果的に評価する手法が確立されつつある

• 最近はプロジェクト単位を超えた、企業レベルでの一連のプロジェクトや組織中心のプロジェクトマネージメントに関する議論が中心となっている

41

Ⅴ.質疑応答

42