The software project managers bridge to agility 読書会 #8 Project time management 後半

1. THE SOFTWARE PROJECT MANAGER’S
BRIDGE TO AGILITY 読書会
#8 : Time Management （後半）
株式会社エンラプト 関口匡稔, PMP, PMI-ACP, CSPO
会場提供: PMI日本支部様

2. Chapter6: Time Management
Iteration Planning: Developing the Schedule at the Tactical Level

3. 時間管理 ∼ PMBOKの定義（V5）
Initiation Planning Executing
Monitoring
&
Controlling
Closing
Time
Management
6.1 スケジュール管理計画
6.2 アクティビティ定義
6.3 アクティビティ順序設定
6.4 アクティビティ資源見積り
6.5 アクティビティ所要期間見積り
6.6 スケジュール作成
6.7 スケジュール・
コントロール
“Project Time Management includes the process
required to manage the timely completion to the
project.” PMBOK guide 5th Edition

4. Scheduling Methods ( Software Extension )
Structured scheduling
いわゆる従来型。マイルストーンを初期フェーズに
決める。
Schedule as independent variable (SAIV)
スケジュールを固定として、最も重要な機能から実
装するスケジュール方法。スケジュールに合わせて
スコープを調整する。
Interactive scheduling with a backlog ( Agile )
要求に優先順位を付け、イテレーションに割り振
り、実装前に詳細化する。rolling wave planning
On-demand scheduling ( TCO , Lean )
前もってスケジュールを組まない。バックログから
タスクを引き出し( pull ) 、消化していく。期間はケ
イデンス（リードタイム）により分かる。
Portfolio scheduling
プロジェクト間・プロジェクト内の順序づけを組織
レベルで決められた評価基準に基づき実施する。組
織にとって価値の高いものから作っていく。
• Software Extension では、ソフトウェア開発におけるスケジューリング手法と
して、下記の5つがあげられている。

5. イテレーション計画
• 1ヶ月のイテレーションなら8h、2週間なら4hくらい
• チーム、プロジェクトマネジャー、顧客（プロダクトオーナー）が参加。他のステー
クホルダーは、オブザーバーとしてか、フィーチャーに関する有益な情報を提供する
なら参加可。
• アウトプットは、イテレーションバックログ（チームのタスクの一覧）
• リリース計画との違いは、見積りの粒度
• リリース計画 - ストーリーポイント（またはハイレベルな見積り）
• イテレーション計画 - 時間

6. Strategy vs Tactic
Strategy Tactic
ゴールを実現するための計画
やアクション
結果を得るための計画や手続き
「戦略は構想だ、と私は言ったけど、あるいは価値判断だとい
うべきかもしれないね。戦略の段階で最善をつくしておけば、
戦術レベルでの勝利はえやすくなる」!
- ヤン・ウェンリー(銀河英雄伝説)

7. Agileでの計画
Release1 Release2 Release3 Release4
Vision Meeting
Product Roadmap
Release Plan
Iteration Plan
ビジネス
価値

8. アクティビティ定義
Traditional Agile
プロジェクトで計画されている全てのアクティ
ビティが記載されたアクティビティリストを準
備する。
イテレーションでチームは選択されたフィーチ
ャーを分解して、タスクリストを作成する。こ
れがイテレーションバックログ、もしくはイテ
レーション計画となる。
アクティビティの属性（担当者、先行・後続タ
スク、制約、前提、関節作業、等）を定義し、
スケジュールに含める。
担当者や見積といったアクティビティの属性は
イテレーション計画ミーティング中に定義し、
イテレーション計画に含める。
プロジェクト全体のマイルストーンを定義し、プ
ロジェクトスケジュールに含める。
個々のイテレーションのテーマはリリース計画
中に決める。イテレーションが終わった時の動
くコードの提供（増分）をマイルストーンと見な
すことが多い。
アクティビティ定義での変更要求は、変更管理
プロセスに通される。
イテレーション計画中に新たな要求が発見され
た場合は、顧客はそれをプロダクトバックログ
に追加する。イテレーションに含めるのは、顧
客がタイムボックスを守るために、低い優先度
のフィーチャーをプロダクトバックログに戻す
ことを承認した場合のみである。

9. アクティビティ定義の流れ
1. プロダクトオーナーが優先度高のフィーチャーリストを用意する
• 受け入れ基準（完了条件）とQAへの回答
• What & Why
2. チームがフィーチャーを実現するための全てのタスクの決定を行う。
• How
初めてのチームは「タスクのブ
レークダウン」作業に慣れてい
ないことが多く、作業の抜け漏
れが多い。うまくファシリテー
トする必要がある。
・タスク完了からその1つ前の
作業は？その前は？
・最初に何をする？次に何をす
る？

10. タスクボード
Require
ments
UI
Ready to
Code
Coding
Ready to
Test
Testing
Ready
for live
Status
Bugs

11. Milestone ( Software Extension 6.2.3.3 )
• 従来型のソフトウェア開発では、マイルストーンは要件・アーキテクチャレ
ビュー、顧客レビュー、製品のリリースなどを示すものだった。
• On-Demandな開発では、マイルストーンは「期日」に基づいてはいない。期
日を設定して確認会を行っても良いが、ゴールは設定できない。
• プロジェクトリスクを減らすためには、プロジェクト間の相互依存を考慮し
た、統合マイルストーンを設定するのが良い（ハードの調達とソフト開発など）
ソフトウェア開発に On-Demand
な開発というのは可能なのだろ
うか？
自社サービスで、期日はASAP
でとにかく継続してサービスを
提供するような場合？

12. アクティビティ順序設定
Traditional Agile
アクティビティの順番を定義し、ネットワーク
ダイアグラムで表現する。
イテレーション計画をファシリテートし、チー
ムがタスクの順番を決定できるようにする。チ
ームと顧客は共同で、技術や外部要員への依存
がプロダクトバックログの順番に影響するか議
論する。
アクティビティリスト、属性を更新し、変更履
歴を記録してプロセスに則る。
チームが発見・解決した依存性を反映して、イ
テレーションバックログを更新する。

13. 順序設定
• Waterfall: FS, FF, SF, SS
• ネットワーク図の作成に必要（ただ、MS Project等を使っていないと実質
意味がない気が・・・）
• タスクの順序はチームが作成する
• 明日最初に何をする？ それが終わったら次は誰と何をする？
• 外部依存性をプロジェクトマネジャーが支援

14. Sequence Activities ( Software Extension 6.3 )
• ソフトウェアのアクティビティ順序設定は、PMBOKとは若干異なる
• 新規開発の場合はアクティビティ完了までの予測ができない
• アーキテクチャ構築は予測が困難
• 非機能要件は要件横断的なため、これも順序を狂わせる
• 初期に予測できない作業（ dark matter ) が存在する
• プロトタイプ／実験／欠陥修正
アーキテクチャバックボーン（ス
ケルトン）を先行して作成する
ことで、独立して構築するパー
トが明確になる
セキュリティは、検証に時間と
コストがかかる（修正したら、
再検証しないといけない）
これらは他のタスクに優先する
ことが多いし、独立して追跡さ
れる。

15. アクティビティ所要時間見積り
Traditional Agile
アクティビティにかかる期間を見積る。
チームメンバーがイテレーション計画ミーティ
ングの中でタスクの見積りを行う。イテレーシ
ョン中でも、タスクが追加されたときや、タス
クが変更されたときにも見積りを実施する。

16. 所要時間の見積り
• イテレーションの期間は固定
• リリース毎のストーリーポイントはそんなにぶれないようにする
• イテレーションの合計時間がチームの能力を超えないようにする
見積りは経験とともに上達する
• 現在までの経過と速度から、到達時間がよ
り正確に予測できる
Nexco西日本
http://www.w-nexco.co.jp/safety_drive/faq_mark/

17. アクティビティ資源見積り
Traditional Agile
個々のワークパッケージに必要なリソースを特
定する。
チームはイテレーション開始前に編成され、イ
テレーションに専念できる。他のリソース（の
手配）はリリース計画にて計画される。
リソースの必要性や空きを示したカレンダーを作
成する。
チームにイテレーション中の非稼働日（休日、
トレーニング、休暇、等）を考慮させることを忘
れないようにする。

18. 資源見積り
• チームは専任で、プロジェクトの当初から従事する
• 個々のタスクへのリソースのアサインは考えない。
• チームメンバーは “多能工”
• より大きなリソースアサインメントを考える
• 例）4ヶ月後にデータアーキテクトが必要になる

19. Estimate Activity Resources ( Software Extension
6.4)
• ソフトウェア開発は開発者のスキルが命!!
• プロジェクトのゴールとプロジェクトチームの総スキルを比較
• Gapがあれば、それは別のチームか増員が必要ということ
• しかし・・・
• PMにそもそもメンバー選択の権限がない
• PMがロール／メンバーのJob Descriptionを出してといわれる
• ソフトウェア開発外のリソースも必要（構成管理／テスト環境／複数プラットフォーム）

20. 戦術レベルのスケジュールコントロール
Traditional Agile
承認された変更、ベースラインにそってスケジュ
ールを更新する。
イテレーション中は変更が禁止されているの
で、チームは妨害されることなくフィーチャー
を慣性できる。ただし、顧客は現在のイテレー
ションの価値がなくなるような変更の場合、イ
テレーションを中止する判断を下せる。
スケジュール差異(SV)とスケジュール効率指数
(SPI)を計算する。
チームに毎日必ずイテレーション中の残作業を
更新させる。チームはまたベロシティの計測を
行う。
変更要求を追跡し、文書化する。
顧客はプロダクトバックログと（または）リリ
ースバックログを更新する。
プロジェクトを軌道に乗せるための修正活動を
明確化、分析する。
顧客とチームの間の取るべき適応活動ディスカ
ッションのファシリテートを行う。（追加のイ
テレーション、チームの追加、フィーチャーの
削減、プロジェクトの終了、等）

21. 15分のデイリースタンドアップ
• 報告内容
• 昨日行ったこと
• 今日行うこと
• 障害となっていること
• チーム内での状態の同期を取るイベント
• （デイリースタンドアップ後）タスクの追加・削除や、順番の変更を行い、プ
ロアクティブに動く
単なる作業報告にならないよう
に、適切なファシリテーション
が必要。
「昨日はタスクAをやりまし
た。今日は続きをやります。特
に問題ありません」というよう
な朝会には意味がない

22. イテレーションの振り返り
• このイテレーションで実現したフィーチャーは何か
• 実現は想定より多かった？少なかった？
• フィーチャーのテストは全部できた？残があるなら、リリースプランへの影響は？
• チームのベロシティは？ ベロシティは増加しているか、減少しているか？ その要因は？
• リリース中の他のイテレーションへの影響は？
• 追加のイテレーションが必要か？統合、パフォーマンステストに追加のイテレーションが必
要か？それとも低優先度のフィーチャーを削りプロダクトバックログに戻すか？
• この結果からチームは計画に対してどんな印象を持っているか？

23. スケジュールコントロール
• リリース計画やイテレーション計画の変更は、「リアルタイム」に行われる
• イテレーション毎の増分は高い品質なのが前提。プロジェクト／製品の現状
が、「見て」分かる
• イテレーションレベルのコントロールはチームに任せる
• なんかコントロール不在な感覚が・・・→ もっと大きな仕事に励む
• 契約／調達／課題・リスク解決 アジャイルになるからプロジェ
クトマネージャーの仕事がなく
なるわけではない。
適切なファシリテーションが非
常に重要になるし、チーム外の
事により目を向ける必要がでて
くる。

24. イテレーションバーンダウンチャート
線が上がっているのはタスクの増加
フラットな線は更新なし
（障害か、更新のサボりか）

25. ベロシティ
グレーが予定
緑が実績

26. Cumulative Flow Diagram
ステータス毎のタスクの変化が追跡できる

27. AgilePM Change List for Time Management
Traditional PM Agile PM
プロジェクト計画を立てる前にプロジェクトの要求を洗い
出しておく。
顧客とチームの議論をファシリテートし、見えている範囲
でのフィーチャーを詳細に定義する。顧客が簡単に維持で
きるプロダクトバックログを作成することを支援する。
詳細なプロジェクトスケジュールを元に、リソースマネジ
ャーとともにいつ、どんなリソースが必要になるかを検討
する。
リソースの増減のない専任チームの一貫性を満喫する！リ
リースプランで想定した例外的な要求について、引き続き
リソースマネジャーとともに作業する。
要求を完了するために必要なタスクの見積りをお願いす
る。
プロダクト／リリースバックログでハイレベルな見積りを
行う。イテレーション計画で、タスクについてより細かい
粒度の見積りを行う。
全てのタスクの依存関係を明確にし、スケジュールを調整
する。関係性を明らかにし、最善の管理方法を示す。
タスクの依存性の管理はチームを信じて任せる。プロジェ
クトのより大きな依存性と外部との協調に注力する。
プロジェクトスケジュールを作成する。
リリース計画、イテレーション計画をファシリテートす
る。そこでチームはハイレベルなリリース戦略と、詳細な
イテレーション計画を作成する。
プロジェクトスケジュールを更新する。スコープ・クリー
プ（漏れ）を防ぐための変更管理を実施する。
チームがバーンダウンチャートの更新するのを支援する
（イテレーション／リリース進 ）。チームの進 に応じ
て、顧客にプロダクトバックログとロードマップの更新を
促す。

28. • 本書で記載されているアジャイルのやり方に変えたときに、チームが遭遇する
であろう疑問・問題・障害を3つ考えてください
• ホワイトボードに貼り付けて、利点や疑問とあわせて整理し、ディスカッショ
ンします。
グループワーク
5min

29. 次回 Part II
Chapter7: Cost Management
発表者（一部でも）募集！！