ウォーターフォールとアジャイルを考える #ita_ws
TRANSCRIPT
アジャイルとウォーターフォールを考える
2016/6/21
鈴木雄介グロースエクスパートナーズ株式会社 執行役員
日本Javaユーザーグループ 会長
ITアーキテクトワークショップ#ita_ws
自己紹介
鈴木雄介• グロースエクスパートナーズ(株)
» 執行役員/アーキテクチャ事業本部長
» http://www.gxp.co.jp/
• 日本Javaユーザーグループ
» 会長
» http://www.java-users.jp/
• SNS
» http://arclamp.hatenablog.com/
» @yusuke_arclamp
1
はじめに
今日、話さないこと•顧客との信頼関係構築とか
•精神論
»広義のアジャイル的ななにか
•多重下請けとか契約とか分業とか
•ただ、例のあれには言及します
2
アジェンダ
•プロジェクトマネジメント
•ウォーターフォールのアプローチ
•アジャイルのアプローチ
•アーキテクチャのこと
•例のあれ
3
プロジェクトマネジメント
4
プロジェクトマネジメント
目標達成のための活動•プロジェクトとは、独自の製品、サービス、所産を創造するために実施される有期性の業務
»特定の成果を達成するために組織
»期間が限定されている : 有期性
»個別にユニークで同じものはない : 独自性
»相互に関連する作業の調整がなされる:相互関連性
•対としては「プロダクト」
»プロダクトが終了までの継続的な活動
5
プロジェクトマネジメント
基本はPDCA•計画する:QCDSを決める
•実行する:計画従って作業する
•計測する:計画と実績のズレを測る
•調整する:ズレに対応する(QCDSの変更)※QCDS:Quality(品質)、Cost(費用)、Delivery(期限)、Scope(機能)
6
プロジェクトマネジメント
失敗あるある•計画の失敗:そもそも計画が正しくない
•実行の失敗:計画された通りに作れない
•計測の失敗:正しく進捗を測れない
•調整の失敗:ズレがあっても調整できない
7
ウォーターフォールのアプローチ
8
ウォーターフォール
PMBOK•国際標準のプロジェクトマネジメントの知識体系(ガイド、手法、メソドロジー、ベストプラクティス)。建設、製造、ソフトウェア開発などに適用できる。1996年に初版
• 5個の基本的なプロセス群と10個の知識エリアとに分類する。
9
ウォーターフォール
10
立ち上げ 計画 実行 監視・コントロール 終結
統合 計画策定 計画実行 統合変更管理
スコープ(目的と範囲)
立ち上げ スコープ計画/定義 スコープ検証/変更管理
時間(期間) アクティビティ定義/順序設定/期間見積スケジュール作成
スケジュールコントロール
コスト(予算) 資源管理コストの見積/予算化
コストコントロール
品質 品質計画 品質保証 品質管理
人的資源 組織計画要員調達
チーム育成
コミュニケーション
コミュニケーション計画 情報配布 実行報告 完了手続き
リスク リスク・マネジメント計画リスク識別定性的/定量的リスク分析
リスクの監視・コントロール
調達 調達/引合計画 引合発注先選定契約管理
契約完了
ステークホルダー
特定 ステークホルダー計画 関与促進 関与のコントロール
計画 実行 調整
ウォーターフォール
PMBOK:5つのプロセス
11
スコープ定義
スケジュール作成
コスト積算
PJ計画策定
PJ計画実施
進捗報告 変更管理
計画プロセス
遂行プロセス監視・コントロールプロセス
終結プロセス
立ち上げプロセス
リスク管理計画
品質計画
コミュニケーション計画
調達計画
ウォーターフォール
PDCAをフェーズで管理する•計画:全体を定義し、計画立案
•実行:計画に沿って実行
•計測:計画従って実績を監視
•調整:計画と実績のズレをコントロールする
•フェーズで管理する
»プロジェクトのライフサイクルをフェーズに分ける
»フェーズごとに完了判定し、次に進む(進まない)
12
ウォーターフォール
ウォーターフォールあるある•計画の失敗:そもそも計画が正しくない
•実行の失敗:計画された通りに作れない
•計測の失敗:正しく進捗を測れない
•調整の失敗:ズレがあっても調整できない
•フェーズが完了していないのに次に進む
»そもそも完了基準も完了判定も曖昧で、結局、日付でしか見てない
13
アジャイルのアプローチ
14
アジャイル
ウォーターフォールへの反省(私見)•最初の計画がある程度は正しい必要がある
»計画通りが前提で、どうしてもバイアスがかかる
•最初にフェーズやプロセスへの分解が行われてしまうので、それを実行することが目的化する
• PMが知識職になってしまった
»本来は技術的な計画能力と政治的な調整能力が重要なはず
15
アジャイル
逆転の発想•計画:精度が出るぐらい小さな計画にする
•実行:計画通りに実行する
•計測:計画終了時に動くソフトウェアで判断
•調整:定期的に関係者全員で話し合う
»実行中にはスコープ調整は行わない
•失敗するにしても範囲が小さい
»うまくいかないことも成果の1つ
16
アジャイル
PMがいない、フェーズがない• PMがやるべきことを全員でやる
»PMの能力に依存しなくなる
»プロセスそのものがマネジメント行為になる
•「終わるまで」ではなく「時間制限の中で」
»時は金なり
»唯一明確な完了基準は「時間」
17
アジャイル
制約というか前提•チーム能力を重視する
»チームとして習熟させていく必要がある
»(スキルの出し入れが困難になる)
•「全体の終了」という概念がない
»全体が分からないから
»プロダクトが終わるまで続ければいい
▸プロダクトが終わるというのも明確な完了基準
18
ウォータフォールとの違い
計画駆動か変化駆動か•計画駆動=ウォーターフォール
»予測可能なプロジェクトの場合は、計画を重視する方が効率が良い
•変化駆動=アジャイル
»探索的なプロジェクトの場合は、変化を重視する方が効率が良い
19
アジャイル
PMBOKとアジャイル• 2013年の第5版ではアジャイルにも言及
»「ライフサイクルが違うだけで適用可能」
•ライフサイクルのタイプ
»予測型ライフサイクル(計画駆動型)
»反復型ライフサイクル/漸進型ライフサイクル
»適応型ライフサイクル(変化駆動型/アジャイル手法)
20
アジャイル
アジャイルでないもの•マネジメントがないもの
»マネジメント=計画>実行>計測>調整
•コミュニケーションが健全でないもの
»顧客も含めたチームとの信頼感は前提
»必要なドキュメントは作るべき
•これはウォーターフォールでも同じ
21
アーキテクチャのこと
22
アーキテクチャ
アーキテクチャは基盤•アーキテクチャ:システムの分け方と組合せ方
»分け方:構造、組み合わせ方:構成
»構造には工法(プロセス・手順)が必要
•「スコープからタスクへの分解」がある以上、そこには必ずアーキテクチャがある
»ウォーターフォールもアジャイルも、マネジメントの基盤はアーキテクチャが決定する
23
アーキテクチャ
アーキテクチャは選択肢を残す•現在的なアーキテクチャは「決めない」
»変化を許容できるようにする
•大切なのはモジュールを決めること
»変化の境界線で分け、適切に組み合わせる
▸標準化
▸交換可能、増減可能、拡張可能
»モジュールごとに交換を可能にする
24
MSA
サービスの分割•モジュール化の最先端がマイクロサービスアーキテクチャ
•システムを疎結合なサービスに分割する
»クラウド技術やDevOpsが前提
»サービスごとにライフサイクルを変えられる
▸技術もマネジメントスタイルも自由にしていい
»チームはサービスを管理する
25
この話は別の機会に
例のあれ
26
例のあれ
27
例のあれ
ウォーターフォールのメリットは?•「ウォーターフォールは何のメリットも無い」はダウト
»特定の文脈ではメリットがある
•では「いまどきのシステム開発においてウォーターフォールを採用するメリットはない」は?
»今日のワークのネタはこれで
28
まとめ
29
まとめ
基本はPDCA•計画する:QCDSを決める
•実行する:計画従って作業する
•計測する:計画と実績のズレを測る
•調整する:ズレに対応する(QCDSの変更)※QCDS:Quality(品質)、Cost(費用)、Delivery(期限)、Scope(機能)
30
まとめ
ウォータフォール•計画:全体を定義し、計画立案
•実行:計画に沿って実行
•計測:計画従って実績を監視
•調整:計画と実績のズレをコントロールする
•フェーズで管理する
31
まとめ
アジャイル•計画:精度が出るぐらい小さな計画にする
•実行:計画通りに実行する
•計測:計画終了時に動くソフトウェアで判断
•調整:定期的に関係者全員で話し合う
»実行中にはスコープ調整は行わない
• PMがいない、フェーズがない
32
まとめ
計画駆動か変化駆動か•計画駆動=ウォーターフォール
»予測可能なプロジェクトの場合は、計画を重視する方が効率が良い
•変化駆動=アジャイル
»探索的なプロジェクトの場合は、変化を重視する方が効率が良い
33
まとめ
アーキテクチャ重要•「スコープからタスクへの分解」がある以上、そこには必ずアーキテクチャがある
»ウォーターフォールもアジャイルも、マネジメントの基盤はアーキテクチャが決定する
•モジュール化の最先端はマイクロサービスアーキテクチャ
»サービスを疎結合化し、独立したマネジメントを許容できるようにする
34
まとめ
ウォーターフォールかアジャイルか•マネジメント手法は道具
•道具の適用を判断するのは人間
•個別の現場の文脈で正しい判断をしてください
35
後半1時間の全体ディスカッション
ワーク
36
テーマ
では「いまどきのシステム開発においてウォーターフォールを採用するメリットはない」か?
37
そもそもWFは必要なのか?
•スコープ確定すればWFという話ではない。「スコープはできるかぎり決める」というのは大前提。決まっててもアジャイルでやればいい
»WFはフェーズごとに中間成果物を作るのが無駄になる。コードという最終成果物を軸にするなら、アジャイルになる。 XPの「コードの共同所有」が重要
38
とはいえWFを採用するケースは?
•メンバーの力量が読めない場合
•約束されたリリースがある(法律改定など)
•スコープが確定的
•基幹システム連携がある(基幹側がWF)
•チームやプロジェクトが永続的ではない
•パッケージの横展開
•発注者が公共(計画レビューありき)
39
とはいえWFを採用するケースは?
•実現性検証が十分にできている
•研究開発ではない
•期間に対して量が多い(大量要員投入が必要)
•業務のパターンが読み切れている
40
なぜアジャイルにできない?
•保守開発(メンバーが決まっている)なら、やりやすい
•パッケージベンダーの指定でアジャイルをやったが、うまくいかなかった
•そもそもユーザー/開発者にやる気がない
»都度「スコープを決めて見積もり」という仕事の仕方では難しい
»開発会社としても、年初に請負の売上計画を作ることになるとWF型にしたくなる
▸かといって、派遣契約はモチベーションが下がるからいや
41
なぜアジャイルにできない?
•やはり、請負契約ではやりにくい
»発注側が稟議のために事前のスコープ確定を要求してくるなら難しい
•準委任でアジャイルして、スコープ確定したらWFというパターンもある=アジャフォール
»請負契約だが「先行発注の作業」でスコープ確定し、確定後に再見積もりして稟議を通してもらうこともできる
42
どうやってチームを組成する?
•コードが書けることは前提として、どういう性格や姿勢の人がいるとよいのか?
»素直で若い子を半分いれたい。変にこだわりすぎず、すぐに聞いてくれた方がチームが回る
»ただし、バックエンドなど安全に作りたいところは”おっさん”をいれて経験とコダワリを行かしてもらう
»コードを書けない人がいてもいい
▸テスター、デザイナー、スクラムマスター、教育目的
»そもそもチーム組成ができてから案件提案するのだから、いる人でやるしかないのでは
43
アジャイルとはいえ、PMっぽい人が必要になるケースがある
•全体計画を見る人が必要になる場合はいる
•進捗がぐずぐずになるチーム/人がいる場合
»毎回、見積もりに失敗するチーム/人がいた
»それぐらい「どう?」って声をかける人がいれば十分では
•なんらかの仕切ったりが必要になる場合にいる
•全体的な要求コントロールが必要な場合
»プロダクトオーナーがやるべきでは?
»WF慣れしたPOがやるとスコープが無限に広がる
44
アジャイルとはいえ、PMっぽい人が必要になるケースがある
•逆にPMでも手を動かすのが好きならアジャイル型がいかもしれない
•チーム同士が仲が悪くて調整役が必要になった場合
•スクラムマスターやプロダクトオーナーとの違いは?
»お世話係ならスクラムマスターでいいのでは
»現場に手を出し始めたらスクラムマスターがPMっぽくなっちゃう
45
チームの立ち上げ
•WF/PMに慣れてる人はチームとして動けないのでは?»本だけのオレオレアジャイルは無理。最初はコンサルやコーチをいれよう
•コーチは役に立ったの?»ある程度のアドバイスは必要
»週1回でも「これでいいのか?」という議論に参加してくれるだけでうれしい▸結局「自分たちのことは自分たちで考えないといけない」ことが学べたけど、それはそれで意味があった
▸メンター的な要素だね
46