47
アジャイルと ウォーターフォールを考える 2016/6/21 鈴木雄介 グロースエクスパートナーズ株式会社 執行役員 日本Javaユーザーグループ 会長 ITアーキテクトワークショップ #ita_ws

ウォーターフォールとアジャイルを考える #ita_ws

Embed Size (px)

Citation preview

Page 1: ウォーターフォールとアジャイルを考える #ita_ws

アジャイルとウォーターフォールを考える

2016/6/21

鈴木雄介グロースエクスパートナーズ株式会社 執行役員

日本Javaユーザーグループ 会長

ITアーキテクトワークショップ#ita_ws

Page 2: ウォーターフォールとアジャイルを考える #ita_ws

自己紹介

鈴木雄介• グロースエクスパートナーズ(株)

» 執行役員/アーキテクチャ事業本部長

» http://www.gxp.co.jp/

• 日本Javaユーザーグループ

» 会長

» http://www.java-users.jp/

• SNS

» http://arclamp.hatenablog.com/

» @yusuke_arclamp

1

Page 3: ウォーターフォールとアジャイルを考える #ita_ws

はじめに

今日、話さないこと•顧客との信頼関係構築とか

•精神論

»広義のアジャイル的ななにか

•多重下請けとか契約とか分業とか

•ただ、例のあれには言及します

2

Page 4: ウォーターフォールとアジャイルを考える #ita_ws

アジェンダ

•プロジェクトマネジメント

•ウォーターフォールのアプローチ

•アジャイルのアプローチ

•アーキテクチャのこと

•例のあれ

3

Page 5: ウォーターフォールとアジャイルを考える #ita_ws

プロジェクトマネジメント

4

Page 6: ウォーターフォールとアジャイルを考える #ita_ws

プロジェクトマネジメント

目標達成のための活動•プロジェクトとは、独自の製品、サービス、所産を創造するために実施される有期性の業務

»特定の成果を達成するために組織

»期間が限定されている : 有期性

»個別にユニークで同じものはない : 独自性

»相互に関連する作業の調整がなされる:相互関連性

•対としては「プロダクト」

»プロダクトが終了までの継続的な活動

5

Page 7: ウォーターフォールとアジャイルを考える #ita_ws

プロジェクトマネジメント

基本はPDCA•計画する:QCDSを決める

•実行する:計画従って作業する

•計測する:計画と実績のズレを測る

•調整する:ズレに対応する(QCDSの変更)※QCDS:Quality(品質)、Cost(費用)、Delivery(期限)、Scope(機能)

6

Page 8: ウォーターフォールとアジャイルを考える #ita_ws

プロジェクトマネジメント

失敗あるある•計画の失敗:そもそも計画が正しくない

•実行の失敗:計画された通りに作れない

•計測の失敗:正しく進捗を測れない

•調整の失敗:ズレがあっても調整できない

7

Page 9: ウォーターフォールとアジャイルを考える #ita_ws

ウォーターフォールのアプローチ

8

Page 10: ウォーターフォールとアジャイルを考える #ita_ws

ウォーターフォール

PMBOK•国際標準のプロジェクトマネジメントの知識体系(ガイド、手法、メソドロジー、ベストプラクティス)。建設、製造、ソフトウェア開発などに適用できる。1996年に初版

• 5個の基本的なプロセス群と10個の知識エリアとに分類する。

9

Page 11: ウォーターフォールとアジャイルを考える #ita_ws

ウォーターフォール

10

立ち上げ 計画 実行 監視・コントロール 終結

統合 計画策定 計画実行 統合変更管理

スコープ(目的と範囲)

立ち上げ スコープ計画/定義 スコープ検証/変更管理

時間(期間) アクティビティ定義/順序設定/期間見積スケジュール作成

スケジュールコントロール

コスト(予算) 資源管理コストの見積/予算化

コストコントロール

品質 品質計画 品質保証 品質管理

人的資源 組織計画要員調達

チーム育成

コミュニケーション

コミュニケーション計画 情報配布 実行報告 完了手続き

リスク リスク・マネジメント計画リスク識別定性的/定量的リスク分析

リスクの監視・コントロール

調達 調達/引合計画 引合発注先選定契約管理

契約完了

ステークホルダー

特定 ステークホルダー計画 関与促進 関与のコントロール

計画 実行 調整

Page 12: ウォーターフォールとアジャイルを考える #ita_ws

ウォーターフォール

PMBOK:5つのプロセス

11

スコープ定義

スケジュール作成

コスト積算

PJ計画策定

PJ計画実施

進捗報告 変更管理

計画プロセス

遂行プロセス監視・コントロールプロセス

終結プロセス

立ち上げプロセス

リスク管理計画

品質計画

コミュニケーション計画

調達計画

Page 13: ウォーターフォールとアジャイルを考える #ita_ws

ウォーターフォール

PDCAをフェーズで管理する•計画:全体を定義し、計画立案

•実行:計画に沿って実行

•計測:計画従って実績を監視

•調整:計画と実績のズレをコントロールする

•フェーズで管理する

»プロジェクトのライフサイクルをフェーズに分ける

»フェーズごとに完了判定し、次に進む(進まない)

12

Page 14: ウォーターフォールとアジャイルを考える #ita_ws

ウォーターフォール

ウォーターフォールあるある•計画の失敗:そもそも計画が正しくない

•実行の失敗:計画された通りに作れない

•計測の失敗:正しく進捗を測れない

•調整の失敗:ズレがあっても調整できない

•フェーズが完了していないのに次に進む

»そもそも完了基準も完了判定も曖昧で、結局、日付でしか見てない

13

Page 15: ウォーターフォールとアジャイルを考える #ita_ws

アジャイルのアプローチ

14

Page 16: ウォーターフォールとアジャイルを考える #ita_ws

アジャイル

ウォーターフォールへの反省(私見)•最初の計画がある程度は正しい必要がある

»計画通りが前提で、どうしてもバイアスがかかる

•最初にフェーズやプロセスへの分解が行われてしまうので、それを実行することが目的化する

• PMが知識職になってしまった

»本来は技術的な計画能力と政治的な調整能力が重要なはず

15

Page 17: ウォーターフォールとアジャイルを考える #ita_ws

アジャイル

逆転の発想•計画:精度が出るぐらい小さな計画にする

•実行:計画通りに実行する

•計測:計画終了時に動くソフトウェアで判断

•調整:定期的に関係者全員で話し合う

»実行中にはスコープ調整は行わない

•失敗するにしても範囲が小さい

»うまくいかないことも成果の1つ

16

Page 18: ウォーターフォールとアジャイルを考える #ita_ws

アジャイル

PMがいない、フェーズがない• PMがやるべきことを全員でやる

»PMの能力に依存しなくなる

»プロセスそのものがマネジメント行為になる

•「終わるまで」ではなく「時間制限の中で」

»時は金なり

»唯一明確な完了基準は「時間」

17

Page 19: ウォーターフォールとアジャイルを考える #ita_ws

アジャイル

制約というか前提•チーム能力を重視する

»チームとして習熟させていく必要がある

»(スキルの出し入れが困難になる)

•「全体の終了」という概念がない

»全体が分からないから

»プロダクトが終わるまで続ければいい

▸プロダクトが終わるというのも明確な完了基準

18

Page 20: ウォーターフォールとアジャイルを考える #ita_ws

ウォータフォールとの違い

計画駆動か変化駆動か•計画駆動=ウォーターフォール

»予測可能なプロジェクトの場合は、計画を重視する方が効率が良い

•変化駆動=アジャイル

»探索的なプロジェクトの場合は、変化を重視する方が効率が良い

19

Page 21: ウォーターフォールとアジャイルを考える #ita_ws

アジャイル

PMBOKとアジャイル• 2013年の第5版ではアジャイルにも言及

»「ライフサイクルが違うだけで適用可能」

•ライフサイクルのタイプ

»予測型ライフサイクル(計画駆動型)

»反復型ライフサイクル/漸進型ライフサイクル

»適応型ライフサイクル(変化駆動型/アジャイル手法)

20

Page 22: ウォーターフォールとアジャイルを考える #ita_ws

アジャイル

アジャイルでないもの•マネジメントがないもの

»マネジメント=計画>実行>計測>調整

•コミュニケーションが健全でないもの

»顧客も含めたチームとの信頼感は前提

»必要なドキュメントは作るべき

•これはウォーターフォールでも同じ

21

Page 23: ウォーターフォールとアジャイルを考える #ita_ws

アーキテクチャのこと

22

Page 24: ウォーターフォールとアジャイルを考える #ita_ws

アーキテクチャ

アーキテクチャは基盤•アーキテクチャ:システムの分け方と組合せ方

»分け方:構造、組み合わせ方:構成

»構造には工法(プロセス・手順)が必要

•「スコープからタスクへの分解」がある以上、そこには必ずアーキテクチャがある

»ウォーターフォールもアジャイルも、マネジメントの基盤はアーキテクチャが決定する

23

Page 25: ウォーターフォールとアジャイルを考える #ita_ws

アーキテクチャ

アーキテクチャは選択肢を残す•現在的なアーキテクチャは「決めない」

»変化を許容できるようにする

•大切なのはモジュールを決めること

»変化の境界線で分け、適切に組み合わせる

▸標準化

▸交換可能、増減可能、拡張可能

»モジュールごとに交換を可能にする

24

Page 26: ウォーターフォールとアジャイルを考える #ita_ws

MSA

サービスの分割•モジュール化の最先端がマイクロサービスアーキテクチャ

•システムを疎結合なサービスに分割する

»クラウド技術やDevOpsが前提

»サービスごとにライフサイクルを変えられる

▸技術もマネジメントスタイルも自由にしていい

»チームはサービスを管理する

25

この話は別の機会に

Page 27: ウォーターフォールとアジャイルを考える #ita_ws

例のあれ

26

Page 28: ウォーターフォールとアジャイルを考える #ita_ws

例のあれ

27

Page 29: ウォーターフォールとアジャイルを考える #ita_ws

例のあれ

ウォーターフォールのメリットは?•「ウォーターフォールは何のメリットも無い」はダウト

»特定の文脈ではメリットがある

•では「いまどきのシステム開発においてウォーターフォールを採用するメリットはない」は?

»今日のワークのネタはこれで

28

Page 30: ウォーターフォールとアジャイルを考える #ita_ws

まとめ

29

Page 31: ウォーターフォールとアジャイルを考える #ita_ws

まとめ

基本はPDCA•計画する:QCDSを決める

•実行する:計画従って作業する

•計測する:計画と実績のズレを測る

•調整する:ズレに対応する(QCDSの変更)※QCDS:Quality(品質)、Cost(費用)、Delivery(期限)、Scope(機能)

30

Page 32: ウォーターフォールとアジャイルを考える #ita_ws

まとめ

ウォータフォール•計画:全体を定義し、計画立案

•実行:計画に沿って実行

•計測:計画従って実績を監視

•調整:計画と実績のズレをコントロールする

•フェーズで管理する

31

Page 33: ウォーターフォールとアジャイルを考える #ita_ws

まとめ

アジャイル•計画:精度が出るぐらい小さな計画にする

•実行:計画通りに実行する

•計測:計画終了時に動くソフトウェアで判断

•調整:定期的に関係者全員で話し合う

»実行中にはスコープ調整は行わない

• PMがいない、フェーズがない

32

Page 34: ウォーターフォールとアジャイルを考える #ita_ws

まとめ

計画駆動か変化駆動か•計画駆動=ウォーターフォール

»予測可能なプロジェクトの場合は、計画を重視する方が効率が良い

•変化駆動=アジャイル

»探索的なプロジェクトの場合は、変化を重視する方が効率が良い

33

Page 35: ウォーターフォールとアジャイルを考える #ita_ws

まとめ

アーキテクチャ重要•「スコープからタスクへの分解」がある以上、そこには必ずアーキテクチャがある

»ウォーターフォールもアジャイルも、マネジメントの基盤はアーキテクチャが決定する

•モジュール化の最先端はマイクロサービスアーキテクチャ

»サービスを疎結合化し、独立したマネジメントを許容できるようにする

34

Page 36: ウォーターフォールとアジャイルを考える #ita_ws

まとめ

ウォーターフォールかアジャイルか•マネジメント手法は道具

•道具の適用を判断するのは人間

•個別の現場の文脈で正しい判断をしてください

35

Page 37: ウォーターフォールとアジャイルを考える #ita_ws

後半1時間の全体ディスカッション

ワーク

36

Page 38: ウォーターフォールとアジャイルを考える #ita_ws

テーマ

では「いまどきのシステム開発においてウォーターフォールを採用するメリットはない」か?

37

Page 39: ウォーターフォールとアジャイルを考える #ita_ws

そもそもWFは必要なのか?

•スコープ確定すればWFという話ではない。「スコープはできるかぎり決める」というのは大前提。決まっててもアジャイルでやればいい

»WFはフェーズごとに中間成果物を作るのが無駄になる。コードという最終成果物を軸にするなら、アジャイルになる。 XPの「コードの共同所有」が重要

38

Page 40: ウォーターフォールとアジャイルを考える #ita_ws

とはいえWFを採用するケースは?

•メンバーの力量が読めない場合

•約束されたリリースがある(法律改定など)

•スコープが確定的

•基幹システム連携がある(基幹側がWF)

•チームやプロジェクトが永続的ではない

•パッケージの横展開

•発注者が公共(計画レビューありき)

39

Page 41: ウォーターフォールとアジャイルを考える #ita_ws

とはいえWFを採用するケースは?

•実現性検証が十分にできている

•研究開発ではない

•期間に対して量が多い(大量要員投入が必要)

•業務のパターンが読み切れている

40

Page 42: ウォーターフォールとアジャイルを考える #ita_ws

なぜアジャイルにできない?

•保守開発(メンバーが決まっている)なら、やりやすい

•パッケージベンダーの指定でアジャイルをやったが、うまくいかなかった

•そもそもユーザー/開発者にやる気がない

»都度「スコープを決めて見積もり」という仕事の仕方では難しい

»開発会社としても、年初に請負の売上計画を作ることになるとWF型にしたくなる

▸かといって、派遣契約はモチベーションが下がるからいや

41

Page 43: ウォーターフォールとアジャイルを考える #ita_ws

なぜアジャイルにできない?

•やはり、請負契約ではやりにくい

»発注側が稟議のために事前のスコープ確定を要求してくるなら難しい

•準委任でアジャイルして、スコープ確定したらWFというパターンもある=アジャフォール

»請負契約だが「先行発注の作業」でスコープ確定し、確定後に再見積もりして稟議を通してもらうこともできる

42

Page 44: ウォーターフォールとアジャイルを考える #ita_ws

どうやってチームを組成する?

•コードが書けることは前提として、どういう性格や姿勢の人がいるとよいのか?

»素直で若い子を半分いれたい。変にこだわりすぎず、すぐに聞いてくれた方がチームが回る

»ただし、バックエンドなど安全に作りたいところは”おっさん”をいれて経験とコダワリを行かしてもらう

»コードを書けない人がいてもいい

▸テスター、デザイナー、スクラムマスター、教育目的

»そもそもチーム組成ができてから案件提案するのだから、いる人でやるしかないのでは

43

Page 45: ウォーターフォールとアジャイルを考える #ita_ws

アジャイルとはいえ、PMっぽい人が必要になるケースがある

•全体計画を見る人が必要になる場合はいる

•進捗がぐずぐずになるチーム/人がいる場合

»毎回、見積もりに失敗するチーム/人がいた

»それぐらい「どう?」って声をかける人がいれば十分では

•なんらかの仕切ったりが必要になる場合にいる

•全体的な要求コントロールが必要な場合

»プロダクトオーナーがやるべきでは?

»WF慣れしたPOがやるとスコープが無限に広がる

44

Page 46: ウォーターフォールとアジャイルを考える #ita_ws

アジャイルとはいえ、PMっぽい人が必要になるケースがある

•逆にPMでも手を動かすのが好きならアジャイル型がいかもしれない

•チーム同士が仲が悪くて調整役が必要になった場合

•スクラムマスターやプロダクトオーナーとの違いは?

»お世話係ならスクラムマスターでいいのでは

»現場に手を出し始めたらスクラムマスターがPMっぽくなっちゃう

45

Page 47: ウォーターフォールとアジャイルを考える #ita_ws

チームの立ち上げ

•WF/PMに慣れてる人はチームとして動けないのでは?»本だけのオレオレアジャイルは無理。最初はコンサルやコーチをいれよう

•コーチは役に立ったの?»ある程度のアドバイスは必要

»週1回でも「これでいいのか?」という議論に参加してくれるだけでうれしい▸結局「自分たちのことは自分たちで考えないといけない」ことが学べたけど、それはそれで意味があった

▸メンター的な要素だね

46