Agile pm8 cost_1a

THE SOFTWARE PROJECT MANAGER’S BRIDGE TO AGILITY 読書会 #９ : Cost Management （前半）

AgilePM研究会和良品文之丞 Bunnojo Warashina

2014/5/12 Agile PM Reading Circle, PMI 1

会場提供: PMI日本支部様

はじめにコストマネジメント（Chapter7）

• PMBOK 5th Edition: Project Cost Management

– Project Cost Management includes the processes involved in planning, estimation, budgeting, financing, funding, managing, and controlling costs so that the project can be completed within the approved budget.

• PMBOKガイド第5版：プロジェクト・コスト・マネジメント

– プロジェクト・コスト・マネジメントは、プロジェクトを承認済みの予算内で完了するための、計画、見積り、予算化、資金調達、財源確保、マネジメント、およびコントロールのプロセスからなる。


p.111

はじめにコストマネジメント（Chapter7） • Fast, cheap, good: you can have any two.

– Author unknown

• 速い、安い、良い：あなたはどれでも手に入れることできる、２つならば。 – 作者不詳

• For a project manager, overruns are as certain as death and taxes. – Author unknown

• プロジェクトマネジャーのために：「超過」は死や税のように避けられないものだ – 作者不詳

• Overrun: continue beyond or above (an expected or allowed time or cost)


p.111

はじめに

• 「美しさ」と同様に「価値」は見る者の目に飛び込んでくる。

– 価値：個人のニーズや欲求、利を得ること

– 将来の価値：希望

• 技術の世界では、市場の価値を急速に失うこともある。

– （著者が数年前に）小型のMP3 player を買ったが、その１か月後にiPodが出で妬ましかった


p.111

はじめに

• ソフトウェアの場合－仕事を楽にする

– 恐らく自動化ができ、しかも複雑にしないで、というようなフィーチャや機能を求める

• パッケージを開けたらすぐ使える

– 最小限のトレーニングやインストラクションで

– ユーザマニュアルを読むことに時間を取られたくない


p.112

はじめに

• 顧客に密接して働かなければ、顧客に最大の価値を提供することができない、ということを我々は学んでいる

– 価値の解釈、価格のポイント、マーケットのタイムライン（時流？）、そして製品の良さ（coolness）

• PMのように、見積り、予算化し、管理するプロジェク

トのコストによって、我々は、顧客がどのような最大の価値を受けるのか、ポイントを知ることを手助けすることができる


p.112

はじめに

• 最初のステップは、プロダクトの納品に必要なことや時間の制約を理解してプロジェクトのコストを決めることである

• PMが納品コスト、追加のライフサイクルのコスト、低

品質のコスト、間接コストなどに注意を払うのは、Traditionalと同じである


p.112

はじめに

• この章ではAgileプロジェクトにおけるコストマネジメントの概要を明確にする – トップダウン見積り＆チームの全員参加 – Agileプロジェクトにおけるコスト見積りとマネジメントの理

解を助ける

• プロジェクトごとに予算化のプロセスは異なる – 暫定的なコスト見積りに基づく財源確保のアイディアを提

供する

• さらにプロジェクト進捗への洞察を与えることでどのようにコストをコントロールするかも論ずる


p.112

はじめに

• 前述を通じて、PMがどのように価値を最大にするかを顧客に示すことができる

– プロジェクトが１億ドルの価値を毎年生むとして、半分のプロジェクトは何も生まない

– 顧客はフィーチャの増加をどのように使ったら良いかわからない

– ビジネスの価値を納品する（届ける）とは、どのような意味かを考える

– Agile PMはコストに対する意思決定はしない →ネゴシェートのためにファシリテートする


pp.112-113

グループワーク

• 変更要求は、どのような理由から生じると思いますか？

– 顧客の変更要求の理由

– プロジェクト側の変更要求の理由


pp.112-113

顧客の変更要求の理由プロジェクト側の変更要求の理由

コスト見積り

• 複雑な状況でコストを予想することは難しい

– 旅行中のガソリンやコーヒーの費用の2セントの差異を見積ることはできない

• estimate（Google検索）

– 数量を適切に算出すること

– 仕事のコストを示すこと

– 未来を正確に予想することとは書かれていない


p.113

コスト見積り

• 12インチ×12インチのウッドデッキを自宅の裏に追

加するコストを見積ることはたやすいが、ソフトウェアシステムの構築コストを見積ることは大変難しい

• ソフトウェアシステムは、ライフサイクルを通じて顧客の変更を繰り返し取り込むことで膨張する

– 入り組んだソフトウェアシステムを正確に予測することはできない

– 常に変更されることで高額になるので、多くの業者は全体を見通す（BDUF）ことのアイデアを諦めている


p.113

コスト見積り

• 我々にできるのは、承認された変更に対して、知っていることと、構築すること（費用）を見積ることだけである

• 我々はソフトウェアの創造や拡張が必要になった際に、定期的にコストを見積らなければならない

– 顧客にプロジェクト進捗の情報を提供し続ける

– 顧客はその中で重要な価値に対する意思決定を行う


p.113

コスト見積り


p.113

創造

拡張

コスト

進捗

期間顧客

意思決定

重要な価値

＋

＋

Agileプロジェクトのコストは、納品するチームによる算定が最良

• Traditionalプロジェクトでは、PMがプロジェクトコスト見積りの責任を持つ

• Agileプロジェクトでは、リリース計画策定のために初

期のフィーチャ見積りを提供することによって、チームが間接的に見積もる


p.114

イテレーション

×回数

リリース

計画コスト見

積り

フィーチャ

見積

変換


• Agileプロジェクトでは、プロジェクト全体に渡ってチームメンバがAgileデリバリチームとして貢献するため、Traditionalプロジェクトより簡単である

• PMは、リリース計画のイテレーション×回数の全

ロード（稼働）、及び直接費・間接費によりコストを見積る

– チームは必要に応じてコスト見積りを助けるための情報を提供する


p.114

グループワーク

• チームがコスト見積りに参加することのメリット・デメリットは何でしょう？


メリットデメリット

p.114


• チームメンバは、プロジェクトのライフサイクル全般に対する理解や経験が不足していることがあるので、経験豊富なPMがコストの主な内容：労務費、資材

費、機材費、サービス費、設備費などをチームに教育することができる

• PMの見積りに関する知識をチームメンバに広める

ことによって、チームはプロジェクトの開始や期間中に追加で必要となるコストを識別する手助けができるようになる


p.114


• Agile PMは、デイリーミーティング等でコストへの影

響を聞くことやコスト見積りの負担からチームを遮断することもできる

• チームメンバが（コスト見積りに）参画を望む場合には、必ずしも遮断するのではなく、「予算タスクフォース」のような有志によって、チームの作業環境の中で参画し、コスト構造への透明性を高めることもできる


p.114


• チームメンバの１～２名よりも、チーム全体がリリース計画策定時に見積り参加する方が、より良い結果をもたらすことが、多くの経験で示されている

• チームメンバが将来の見積りに従事することで、彼らのリリース計画策定に対する自由裁量を与え、計画に対する達成、参画、裁量の意識を引き出す。


p.114

Agileプロジェクトは、ボトムアップではなく、トップダウンで見積る

• TraditionalプロジェクトではWBSを作成し、より下位レベルの個々のタスクに対するリソースのワークロードを見積り、それを統合して全体を見積る – 「ボトムアップ見積り」としてプロジェクト管理ツールで知ら

れている

• Agileプロジェクトでは、トップダウンにより見積る

– ソフトウェア開発に対しては、タスクレベルやタスクの依存関係を正確に予測することが不可能なため

– プロジェクトの進行に伴って、顧客からの変更要求を受け入れながら、今回のリリース、今回のイテレーションに対してジャストインタイムで詳細化する


p.115

Agileプロジェクトは、ボトムアップではなく、トップダウンで見積る

• リリース計画の策定後に、リリース計画をチームが合意したときが、コスト見積を行う最初で最良のタイミングである

• 他にも、顧客と各フィーチャをリリースするのにどのくらいの期間がかかるか、顧客とチーム個人が相互に協議して決定する方法もある

– ここの訳に関して、「コスト見積もりは、リリースプランの異なる表現だということを述べているのではないか」、という意見あり。


p.115

Agileプロジェクトは、ボトムアップではなく、トップダウンで見積る • Agile Cost Estimation Worksheet (Based on Output of Release Planning)


pp.115-116

Sprint n Sprint n+1 Sprint n+2Bobby 10,000.00 Bobby 10,000.00 Bobby 10,000.00Jeanne 8,000.00 Jeanne 8,000.00 Jeanne 8,000.00Ted 11,000.00 Ted 11,000.00 Ted 11,000.00Liam 7,500.00 Liam 7,500.00 Liam 7,500.00Nellie 10,000.00 Nellie 10,000.00 Nellie 10,000.00Misha 9,000.00 Misha 9,000.00 （Matarnity leave）

Eric 4,000.00 UI Cntractor 16,000.00

Total 55,500.00 Total 59,500.00 Total 62,500.00TotalHumanCost

177,500.00

Server 25,000.00 Server-Alpha 25,000.00Environment 30,000.00 Training 10,000.00Testing tools 40,000.00 Testing License 2,500.00 Testing License 2,500.00PM tool 5,000.00 PM tool 2,000.00 PM tool 2,000.00

Total 100,000.00 Total 14,500.00 Total 29,500.00TotalOtherCost

144,000.00

TotalEst.Cost

321,500.00

Release A

Training Season Equipment & Software Cost

リリース計画策定中にチームは代替案を示すことができる


p.117

• Agileプロジェクトは、スコープに柔軟性があれば、常に期間と予算内に収めることができる – 最も重要なフィーチャを重視する

• 顧客満足、業務変革の優先度、お金の支出

期間予算

プロダクトバックログ

平均ベロシティスコープ

顧客との交渉

代替案代替案代替案代替案

顧客の意思決定

提供されるビジネスの価値≧プロジェクトコスト

フィーチャを実装しないことを含む

コスト見積りはプロジェクト期間を通じてより洗練される


p.117

• リリース計画における初期のコスト見積りは、個々のイテレーションで何が完了し何がバックログに残っているかという情報を元に更新される

• イテレーションを繰り返すことで、より正確さが増す

初期のコスト見積り

イテレーションイテレーションイテレーション

アップデート

プロダクトバックログ

チームのベロシティ

コスト見積りはプロジェクト期間を通じてより洗練される


p.117

イテレーション

見積りの正確さの

レベル

高

イテレーションn

完成したもの

バックログ

イテレーションn+1

完成したもの

バックログ

イテレーションn+2

完成したもの

バックログ

プロジェクトのコストパフォーマンスが容易に理解できる

まとめ

• トップダウンの見積り技法とリリース計画策定へのチームアプローチにより、Agileプロジェクトのコストは許容範囲内に見積ることができる


Traditional Agile

活動コストの見積りは、詳細と累積によるボトムアップ見積り技法を用いて、マネジメントのレビューと財源確保のために行われる

コスト見積は、AgilePM及び／又は有志による予算タスクによって、トップダウン技法とリリース計画策定ミーティングの結果によって算定される

変更要求は、正式な変更管理プロセスを用いたレビューに向けて処理される

リリースバックログは新規及び変更の要求を反映して更新される

これらの更新によって、チームはリリースプランへの影響を決定することができる（それがコスト見積りへの影響でもある）

p.118

コラム：現実的な見積り

• 私はレガシーをリライトする11チーム、100名のリリース計画策定セッションを8月に開催した

• それぞれのチームはシステムの特定のモジュールの責任を割り当てられた

• ブレークアウトセッションと多くのプロダクトオーナーの参画を得た2日間の計画策定後、チームは8ヵ月で50フィーチャのバックログを策定した

• シニアマネジメントは12月（半分の4ヵ月！）の納品を望んだ • チームは2週間ごとのイテレーションを実施し、11月までにできる

範囲で最低限のリリースを行った

• 年が明け、チームは優先度の低い作業に取り掛かり、リリース計画策定から9ヵ月経った5月までで、全てのリリースを段階的に行った

• 全体の見積りに基づいたチームの当初立案に対して、1ヵ月しか差異がなかった


p.118

なぜかコストではなく期間のお話

THE SOFTWARE PROJECT MANAGER’S BRIDGE TO AGILITY 読書会 #９ : Cost Management （前半）

Thank you


Agile pm8 cost_1a

Documents

Transcript of Agile pm8 cost_1a