2016/6/27開催のAUGJ TOKYO #18の講演資料です。 Atlassian社のPortfolio for JIRAを企業システム開発で活用する利点と方法についてお話しました。

1. 2016.06.27 AUGJ TOKYO #18
Continue to commit to overall plan on Portfolio for JIRA

2. 自己紹介
岡 大勝
（おか ひろまさ）
株式会社ゼンアーキテクツ
CEO/チーフアーキテクト
Profile
Financial / Manufacturing / Medical
IT Architecture Design / Requirements Analysis
Enterprise Agile Process
Micrsoft Azure / Atlassian / SPARX Systems

4. ソフトウェア開発は、事業と一体である
• 割合の大小はあるが、
ソフトウェアが事業の全てを占めることはない。
• ソフトウェア＝事業の中で、
最も「軽量（アジリティの高い）」な資源
• 軽量な特性を最大限活用したエンジニアリング手法が、
アジャイルやリーン
• 人・拠点・設備など「質量」があるものは調達リードタイムが必要
• 事業とソフトウェア開発は不可分
• 「ビジネス駆動開発」から「ソフトウェア駆動ビジネス」へ
• http://www.slideshare.net/tomohn/devsumib-19b6

5. アジャイルと企業活動の
よくあるギャップ
•特に「計画」に注目すると
• いつ完成するのか？（期間見積もり）
• いくらかかるのか？（規模見積もり）
• 何ができるのか？（スコープ）
• いま、どういう状況か？（進捗）
• 順調なのか？（リスク）
適切に答えられない
調達リードタイムが必要な他の事業部門との
連携・準備を考慮すると、常に全て明確であるべき。

6. 現場でよく見る２つの誤解

7. アジャイル＝
「計画できないこと（不確実性）への
対処法」だと思っている
• アジャイル＝「変化に素速く適応できる進め方」
• 計画できないなら、プロジェクトを開始してはならない。
• 正解が分からなくても、仮説を立て、全力で走る
• プロジェクトの中で試行錯誤しない。
• 常に全体計画を持ち続けるが、いざ「変更が発生した」時に
素速く適応できることがアジャイルの強み
アジャイルの誤解１
全体計画があるからこそ、全力で走ることができる

8. アジャイル＝
「全体計画を立てられない
（もしくは意味がない）」と思っている
• 計画の目的は「見通しを立てる」こと
• 実施すべきこと
• 事業計画との連携
• 他のプロジェクトとの連携
• リスクの識別
• 見積もり前提が同じなら、
従来型より精度の高い見積もりが可能
できあがった計画より、計画づくりにこそ価値がある
アジャイルの誤解２

9. アジャイルプロジェクト管理の
4つの利点
1. 全体計画と実施計画の分離
2. プロジェクト内のフィードバックループ
3. 「相対値の積算見積もり」という落としどころ
4. 見積もりコストの低さ
9

10. 10
アジャイルプロジェクト管理
①規模見積もり
ストーリー
要求識別
ストーリー
ストーリーの
見積もり
作成
ストーリーポイントの設定
プランニング
ポーカー
ストーリー積算による
概算レベルの規模見積もり
set
新たなストーリーが
識別されなくなるまで
ストーリーポイントの合計が
要求の規模
見積もり時の不毛な議論（100か101
か）を避けるため、ストーリーポイ
ントにはフィボナッチ数列の利用を
推奨
プロダクト
バックログ
+ストーリーポイント合計
ストーリー
+ ストーリーポイント
プロダクトバックログ構築時のボトムアップ見積もり

11. スプリントスプリント
ストーリー
11
アジャイルプロジェクト管理
②期間見積もり
ストーリー
次スプリントの
作成
ストーリーストーリー
スプリント
バックログの
割り当て
前スプリントの
実績よりベロシティ設定
プロダクト
バックログ
スプリント
バックログ
リリース計画による
期間見積もり
スプリント
+ 期間
+ ベロシティ
+ ストーリー
ポイント合計
ストーリー
優先順位の高い
ストーリーから取得
SPがベロシティを
超えないよう
ストーリーを割り当て
set
setget
実現するストーリーが
全てスプリントに
割り当てられるまで
1
1..*
1
1
スプリントの期間合計が
プロジェクト期間
チーム編成は基本固定
期間は「２週間」が標準
チーム/組織
+ ベロシティ
メンバー
+ スキル
期間見積もり
+ 総期間
タイムボックスとベロシティによる期間見積もり

12. タスク
ストーリー
12
アジャイルプロジェクト管理
③工数見積もり
ストーリーの
タスク分解
タスクアサイン
と作業時間見積
もり
スプリント
バックログ
スプリント計画による
工数見積もり + ストーリー
ポイント合計
ストーリー
get
タスクの定義
実施スプリントのタスク・工数の見積もり確定
実施スプリントのバックログ
タスク
+ 担当者
+予定作業時間
set
スプリントで実現する
ストーリー全て
全てのタスク
工数合計がスプリント期間を超える
もしくは大きな乖離がある
タスク見積もり
の精査
ストーリーの
割り当て変更
このスプリントでの1ポイントあたりの作業
工数見積もりは算出は可能。
しかし見積もりの数字遊びを避けるためSP
を意図的に精緻に見積もらないようにして
いる（フィボナッチ）ので、見積もりのポ
イントからの実時間算出は無意味
ストーリーポイント
の見積もりとの
ギャップ
エピック
1
0..* 任意の分類軸
creates
スプリントバックログでの工数見積もり

13. タスク
ストーリー
13
アジャイルプロジェクト管理
④開発作業と見積もりの改善
タスクの実施
スプリントデモ
スプリント
バックログ
スプリント実施とフィードバックによる
継続的見積もり改善
+ ストーリー
ポイント合計
ストーリー
実施スプリントのバックログ
タスク
+ 担当者
+予定作業時間
+ステータス
全てのタスク
スプリントタスク完了
リリース計画へ
のフィードバッ
ク
対象ストーリーは変えない
ステータス更新
タスクボード
未着手
→着手中
→完了
タスクの追加、
変更、削除
仕様化、レビュー、実装、テ
スト、不具合改修、データ作
成、環境構築、リリース、等
ストーリーストーリーストーリー
プロダクト
バックログ
• ストーリーの追加・削除・修正
• 各ストーリーポイント見直し
• 優先順位変更
任意の
タイミング
追加変更
要求
次のスプリント計画へ
ストーリー単位で完了/未完了を判断
未完了のストーリーは実績ストーリーポイントに含めない
実績ストーリー
ポイント
＝ ベロシティ
レポート
活動結果
フィードバックによる製品とチームの精度向上

14. パラメータに変更がある度に「再計算」して
提示することが理想
• プロジェクト
• スプリント期間
• リリース
• 非稼働日
• プロダクトバックログ
• エピック
• ストーリー
• ストーリーポイント
• スプリントバックログ
• タスク
• 作業予定時間
• チーム
• ベロシティ
• メンバー
• 稼働可能時間
• スキル
アジャイルプロジェクト計画の
パラメータ
現実問題、全体計画を維持し続けることは
手作業では難しい

15. ツールで全体計画を「導出」する

16. ツールのスコープは様々
BTS/ITS
アジャイルプロダクト生産活動
アジャイルの企業活動への適合E
C
Enterprise Agile
Core Agile

17. ツールのスコープは様々
BTS/ITS
アジャイルプロダクト生産活動
アジャイルの企業活動への適合E
C
Enterprise Agile
Core Agile
「全体計画」が可能

18. プロダクトバックログ

19. 期間とベロシティにより、
プロジェクトの長期計画を自動生成

20. 全体計画の使いどころ
プロジェクト企画・予算計画
定例進捗会議
スプリントデモ
事業企画会議（他部門メンバー）
プロダクトオーナーによるリリース戦略
他プロジェクトとの連携
スキル開発・人員調達
チームメンバーに見通しを提供

21. Portfolio for JIRAで全体計画を扱うポイント
• ビジネスのマイルストーンを「リリース」に設定する
• 初期のプロダクトバックログ構築がいちばん大事
• 実現性とリスクを考慮したストーリーと見積もり
• 業務分類を「テーマ」に設定すると、直感的に理解しやすい
• ベロシティにバッファは積まないこと
• ストーリーポイントも水増ししない
• バッファを積むならSRSSストーリーを差し込む
• 単位はリリースが望ましい
• スキルの設定はストーリーの粒度に影響する
• テクノロジーの切り口でストーリーが分割される方向に行きやすい
• 依存関係は適切かつ最小の利用に留める
• 粒度の大きなストーリーと同様、計画の柔軟性が失われる
※ SRSS （Square Root Sum of Squares） = 2乗和平方根法

22. ContinuousReleasePlanning
「継続的リリース計画」
Agile Processes in Software Engineering and Extreme Programming
「Continuous Release Planning in a Large-Scale Scrum Development Organization at Ericsson」
アジャイルのプロジェクト計画は
「手作り」するものではない。
によって、
長期計画も変化に適合し続ける。

23. イテレーション5
イテレーション6
イテレーション7
・新たなストーリー
・優先順位の入替
・利用技術の見直し
・別チームの支援
継続的リリース計画
常時「見通し」を可視化
影響を反映
影響を反映
・・・

24. チーム活動の透明化によって
事業活動との連携が生まれている
• プロダクトオーナーがリリース計画を調整できるようになった。
• 他の事業部の施策を考慮することができるようになった。
• 外部プロジェクトとの依存関係調整の自由度が向上。
• 他の施策の状況に応じて、リリース優先順位の入れ替えを行う
ようになりつつある。
ブラックボックスの
プロジェクト
「システムの調達」から「事業としての生産活動」へ
要求 システム
ブラックボックスの
プロジェクト
事業活動と連携した生産活動
現場の声

25. 25
zenarchitects.co.jp
facebook.com/zenarchitects