Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.
アジャイルと
ウォーターフォールを考える
2016/6/21
鈴木雄介
グロースエクスパートナーズ株式会社 執行役員
日本Javaユーザーグループ 会長
ITアーキテクトワークショップ
#ita_ws
自己紹介
鈴木雄介
• グロースエクスパートナーズ(株)
» 執行役員/アーキテクチャ事業本部長
» http://www.gxp.co.jp/
• 日本Javaユーザーグループ
» 会長
» http://www.java-users.jp/...
はじめに
今日、話さないこと
• 顧客との信頼関係構築とか
• 精神論
»広義のアジャイル的ななにか
• 多重下請けとか契約とか分業とか
• ただ、例のあれには言及します
2
アジェンダ
• プロジェクトマネジメント
• ウォーターフォールのアプローチ
• アジャイルのアプローチ
• アーキテクチャのこと
• 例のあれ
3
プロジェクトマネジメント
4
プロジェクトマネジメント
目標達成のための活動
• プロジェクトとは、独自の製品、サービス、所
産を創造するために実施される有期性の業務
»特定の成果を達成するために組織
»期間が限定されている : 有期性
»個別にユニークで同じものはない :...
プロジェクトマネジメント
基本はPDCA
• 計画する:QCDSを決める
• 実行する:計画従って作業する
• 計測する:計画と実績のズレを測る
• 調整する:ズレに対応する(QCDSの変更)
※QCDS:Quality(品質)、Cost(費用...
プロジェクトマネジメント
失敗あるある
• 計画の失敗:そもそも計画が正しくない
• 実行の失敗:計画された通りに作れない
• 計測の失敗:正しく進捗を測れない
• 調整の失敗:ズレがあっても調整できない
7
ウォーターフォールの
アプローチ
8
ウォーターフォール
PMBOK
• 国際標準のプロジェクトマネジメントの知識体
系(ガイド、手法、メソドロジー、ベストプラ
クティス)。建設、製造、ソフトウェア開発な
どに適用できる。1996年に初版
• 5個の基本的なプロセス群と10個の知識...
ウォーターフォール
10
立ち上げ 計画 実行 監視・コントロール 終結
統合 計画策定 計画実行 統合変更管理
スコープ
(目的と範囲)
立ち上げ スコープ計画/定義 スコープ検証/変更管理
時間(期間) アクティビティ定義/順序設
定/期間...
ウォーターフォール
PMBOK:5つのプロセス
11
スコープ
定義
スケ
ジュール
作成
コスト
積算
PJ計画
策定
PJ計画
実施
進捗報告 変更管理
計画プロセス
遂行プロセス監視・コントロールプロセス
終結
プロセス
立ち上げ
プロセ...
ウォーターフォール
PDCAをフェーズで管理する
• 計画:全体を定義し、計画立案
• 実行:計画に沿って実行
• 計測:計画従って実績を監視
• 調整:計画と実績のズレをコントロールする
• フェーズで管理する
»プロジェクトのライフサイクル...
ウォーターフォール
ウォーターフォールあるある
• 計画の失敗:そもそも計画が正しくない
• 実行の失敗:計画された通りに作れない
• 計測の失敗:正しく進捗を測れない
• 調整の失敗:ズレがあっても調整できない
• フェーズが完了していないの...
アジャイルの
アプローチ
14
アジャイル
ウォーターフォールへの反省(私見)
• 最初の計画がある程度は正しい必要がある
»計画通りが前提で、どうしてもバイアスがかかる
• 最初にフェーズやプロセスへの分解が行われて
しまうので、それを実行することが目的化する
• PMが知...
アジャイル
逆転の発想
• 計画:精度が出るぐらい小さな計画にする
• 実行:計画通りに実行する
• 計測:計画終了時に動くソフトウェアで判断
• 調整:定期的に関係者全員で話し合う
»実行中にはスコープ調整は行わない
• 失敗するにしても範囲...
アジャイル
PMがいない、フェーズがない
• PMがやるべきことを全員でやる
»PMの能力に依存しなくなる
»プロセスそのものがマネジメント行為になる
• 「終わるまで」ではなく「時間制限の中で」
»時は金なり
»唯一明確な完了基準は「時間」
...
アジャイル
制約というか前提
• チーム能力を重視する
»チームとして習熟させていく必要がある
»(スキルの出し入れが困難になる)
• 「全体の終了」という概念がない
»全体が分からないから
»プロダクトが終わるまで続ければいい
▸プロダクトが...
ウォータフォールとの違い
計画駆動か変化駆動か
• 計画駆動=ウォーターフォール
»予測可能なプロジェクトの場合は、計画を重視する
方が効率が良い
• 変化駆動=アジャイル
»探索的なプロジェクトの場合は、変化を重視する方
が効率が良い
19
アジャイル
PMBOKとアジャイル
• 2013年の第5版ではアジャイルにも言及
»「ライフサイクルが違うだけで適用可能」
• ライフサイクルのタイプ
»予測型ライフサイクル(計画駆動型)
»反復型ライフサイクル/漸進型ライフサイクル
»適応型...
アジャイル
アジャイルでないもの
• マネジメントがないもの
»マネジメント=計画>実行>計測>調整
• コミュニケーションが健全でないもの
»顧客も含めたチームとの信頼感は前提
»必要なドキュメントは作るべき
• これはウォーターフォールでも...
アーキテクチャのこと
22
アーキテクチャ
アーキテクチャは基盤
• アーキテクチャ:システムの分け方と組合せ方
»分け方:構造、組み合わせ方:構成
»構造には工法(プロセス・手順)が必要
• 「スコープからタスクへの分解」がある以上、
そこには必ずアーキテクチャがある
...
アーキテクチャ
アーキテクチャは選択肢を残す
• 現在的なアーキテクチャは「決めない」
»変化を許容できるようにする
• 大切なのはモジュールを決めること
»変化の境界線で分け、適切に組み合わせる
▸標準化
▸交換可能、増減可能、拡張可能
»モ...
MSA
サービスの分割
• モジュール化の最先端がマイクロサービスアー
キテクチャ
• システムを疎結合なサービスに分割する
»クラウド技術やDevOpsが前提
»サービスごとにライフサイクルを変えられる
▸技術もマネジメントスタイルも自由にし...
例のあれ
26
例のあれ
27
例のあれ
ウォーターフォールのメリットは?
• 「ウォーターフォールは何のメリットも無い」
はダウト
»特定の文脈ではメリットがある
• では「いまどきのシステム開発においてウォー
ターフォールを採用するメリットはない」は?
»今日のワークのネ...
まとめ
29
まとめ
基本はPDCA
• 計画する:QCDSを決める
• 実行する:計画従って作業する
• 計測する:計画と実績のズレを測る
• 調整する:ズレに対応する(QCDSの変更)
※QCDS:Quality(品質)、Cost(費用)、Deliver...
まとめ
ウォータフォール
• 計画:全体を定義し、計画立案
• 実行:計画に沿って実行
• 計測:計画従って実績を監視
• 調整:計画と実績のズレをコントロールする
• フェーズで管理する
31
まとめ
アジャイル
• 計画:精度が出るぐらい小さな計画にする
• 実行:計画通りに実行する
• 計測:計画終了時に動くソフトウェアで判断
• 調整:定期的に関係者全員で話し合う
»実行中にはスコープ調整は行わない
• PMがいない、フェーズが...
まとめ
計画駆動か変化駆動か
• 計画駆動=ウォーターフォール
»予測可能なプロジェクトの場合は、計画を重視する
方が効率が良い
• 変化駆動=アジャイル
»探索的なプロジェクトの場合は、変化を重視する方
が効率が良い
33
まとめ
アーキテクチャ重要
• 「スコープからタスクへの分解」がある以上、
そこには必ずアーキテクチャがある
»ウォーターフォールもアジャイルも、マネジメント
の基盤はアーキテクチャが決定する
• モジュール化の最先端はマイクロサービスアー
キ...
まとめ
ウォーターフォールかアジャイルか
• マネジメント手法は道具
• 道具の適用を判断するのは人間
• 個別の現場の文脈で正しい判断をしてください
35
後半1時間の全体ディスカッション
ワーク
36
テーマ
では「いまどきのシステム開発におい
てウォーターフォールを採用するメリ
ットはない」か?
37
そもそもWFは必要なのか?
• スコープ確定すればWFという話ではない。「
スコープはできるかぎり決める」というのは大
前提。決まっててもアジャイルでやればいい
»WFはフェーズごとに中間成果物を作るのが無駄にな
る。コードという最終成果物を軸...
とはいえWFを採用するケースは?
• メンバーの力量が読めない場合
• 約束されたリリースがある(法律改定など)
• スコープが確定的
• 基幹システム連携がある(基幹側がWF)
• チームやプロジェクトが永続的ではない
• パッケージの横展開...
とはいえWFを採用するケースは?
• 実現性検証が十分にできている
• 研究開発ではない
• 期間に対して量が多い(大量要員投入が必要)
• 業務のパターンが読み切れている
40
なぜアジャイルにできない?
• 保守開発(メンバーが決まっている)なら、や
りやすい
• パッケージベンダーの指定でアジャイルをやっ
たが、うまくいかなかった
• そもそもユーザー/開発者にやる気がない
»都度「スコープを決めて見積もり」という...
なぜアジャイルにできない?
• やはり、請負契約ではやりにくい
»発注側が稟議のために事前のスコープ確定を要求し
てくるなら難しい
• 準委任でアジャイルして、スコープ確定したら
WFというパターンもある=アジャフォール
»請負契約だが「先行発...
どうやってチームを組成する?
• コードが書けることは前提として、どういう性
格や姿勢の人がいるとよいのか?
»素直で若い子を半分いれたい。変にこだわりすぎず
、すぐに聞いてくれた方がチームが回る
»ただし、バックエンドなど安全に作りたいところ...
アジャイルとはいえ、PMっぽい人が必要になるケ
ースがある
• 全体計画を見る人が必要になる場合はいる
• 進捗がぐずぐずになるチーム/人がいる場合
»毎回、見積もりに失敗するチーム/人がいた
»それぐらい「どう?」って声をかける人がいれば十
...
アジャイルとはいえ、PMっぽい人が必要になるケ
ースがある
• 逆にPMでも手を動かすのが好きならアジャイ
ル型がいかもしれない
• チーム同士が仲が悪くて調整役が必要になった
場合
• スクラムマスターやプロダクトオーナーとの違
いは?
»お...
チームの立ち上げ
• WF/PMに慣れてる人はチームとして動けない
のでは?
»本だけのオレオレアジャイルは無理。最初はコンサ
ルやコーチをいれよう
• コーチは役に立ったの?
»ある程度のアドバイスは必要
»週1回でも「これでいいのか?」とい...
Prochain SlideShare
Chargement dans…5
×

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

11 946 vues

Publié le

2016/6/21に開催した勉強会「ウォーターフォールとアジャイルを考える」の資料とワークのディスカッションメモです。

Publié dans : Technologie
  • Soyez le premier à commenter

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

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

×