nav-portfolio-lean-budgets

従来の原価計算はアジャイル開発に釣り合わない
Rami Sirkia と Maarit Laanti

予算の概要

SAFeによるプロジェクトを超えた原価計算

従来型のソフトウェア企業において、リーン-アジャイルな開発手法で仕事をアジャイルに実施し、同時に予算編成と原価計算は現在の手法で行おうとすると、本来の性質の違いによる矛盾が発生する。その結果、リーン-アジャイルな開発への移行とそれに伴うビジネス上の利点(ケーススタディを参照)を、企業が手にできなくなる可能性がある。あるいは、アジャイルの取り組みがいくらか進むものの、結局は、支出を割り当てて結果を測定する受託者およびガバナンスモデルと対立することもある。

SAFeでは、従来型のプロジェクト資金拠出のオーバーヘッドや苦労なしにこの問題に直接対処できる、リーン-アジャイルな予算編成の戦略を用意している。SAFeではPPMが支出全体を制御していて、そのやり方は事業部門のポートフォリオ予算サイクルによって異なる。ただし、すばやく意思決定をして柔軟に価値を納品する権限はプログラムに与えられている。さらに、横断的なポートフォリオエピックのための予備の予算が確保されているため、複数のプログラムに影響する大きな取り組みの実装にも体系的に財源を割り当てることができる。こうすることで、市場のニーズにずっと素早く対応できる開発プロセスと、専門的で説明可能な投資支出管理の、両方の利点を企業は手にすることができる。

詳細

問題

ソリューションの説明に入る前に、まず現状を説明し、それがどうアジャイルを妨げているかを理解したい。

問題1 – コストセンターに対する予算割り当て

リーン-アジャイル開発に移行する前の、多くの企業における予算編成プロセスを、図1に示す。

 

Budgets article Figure 1. Traditional project-based cost budgeting and cost accounting model

図1. 従来型のプロジェクトベースのコスト予算編成および原価計算モデル

 図1を見ると、企業がいくつものコストセンターで構成されていることが分かる。新しい作業を始めようとすると、それぞれのコストセンターが、新作業用のプロジェクトの支出や人(主要なコスト要素)を分担しなければならない。その結果、以下に示すようないくつもの問題が発生する。

  1. プロジェクト予算全体を確保するために、実際には複数の予算(コストセンターごとに1つ)が必要なため、プロジェクトの予算編成プロセスが複雑で時間のかかるものになる。
  2. 2. 工数の見積もりを非常に正確に行わなければ、予算見積もりに不備が含まれる。そのため、チームは、未確定事項が山積みのまま早すぎる段階で詳細に(通常はWBSを使用して)作業を見積もることになる。タスクを特定できなければ、人をどれだけの期間割り当てる必要があるのかを見積もれないからである。
  3. 人の割り当ては一時的である。組織は、プロジェクトが完了したら人がコストセンターに戻ってきて、その後、別の割り当てをできると想定している。遅延などが原因で戻ってこなければ、予定していた別のプロジェクトが被害をこうむる。
  4. このモデルでは、コストセンターの管理者は、人を完全に割り当てるよう求められる(目標は100%)。ただし、100%稼働させると、フローや予測性が妨げられ[2]、結果として不安定になる。必然的に生じる問題に柔軟に対応するリソースがないためである。
  5. コストセンターが機能ごとに組織化されていると(たとえば開発部門とテスト部門など)、この問題は複雑になる。現在割り当てられている1つのプロジェクトを超えて長い期間協力することができず、知識の獲得や持続、チームの能力、従業員の雇用などが抑制されるからである。もちろん、物理的に(場合によっては仮想的にも)同じ場所にいるのは不可能である。

問題2 – プロジェクトベースの制約による適応性と経済効果の低下

プロジェクトの開始後にも問題は発生する。完全に未来を予測することはできないため、ビジネスの実際のニーズとプロジェクトの現実のパターンはすぐに変化する。しかし、プロジェクトは、予算や人がプロジェクトの期間を通して固定されているため、ビジネスの優先順位の変化に柔軟に対応することができない。その様子を図2に示す。

Budgets article Figure 2. Project funding inhibits agility

図2. プロジェクトの資金が決まっているためアジャイルに動けない

結果として、組織はビジネスのニーズの変化に柔軟に対応できず、対応しようとすると予算や人の割り当てを見直すためのオーバーヘッドが生じる。オーバーヘッドが生じると、財政面で損害が出る。遅延コスト(やるべきことをやらなかったためのコスト)が増加する。

問題3 – 予定より時間がかかるとどうなるか

プロダクト開発でリスクを負わずに変革を起こすことはできない[2]。ソフトウェア開発は、そもそもの性質からして見積もりが非常に困難である。現在の(多くの場合は不安定な)レガシー環境を変更するのは確実でないうえに、ソフトウェアの研究開発には変動がつきものだからである。その結果、ほとんどの場合にはどうしても計画より長くかかってしまう。非常にうまく進んだ場合ですら、利害関係者が特定の機能をもっと充実させてほしいと望むことがあり、それにも余分な時間がかかる。ここでも、プロジェクト単位の原価計算では、進捗が遅れ、会社の文化に影響が及んで、最終的には透明性が損なわれる。これを図3に示す。

Budgets article Figure 3. When “overruns” happen, project accounting and re-budgeting increases Cost of Delay, negatively impacts culture

図3. 「超過」が生じると、プロジェクトの会計処理や予算の見直しにより遅延コストが増大し、文化に悪影響が及ぶ

プロジェクトのスケジュールが予定期間を超過したり予想外の遅延が発生すると、差異を分析し、予算と計画を見直すことが必要になる。リソースの奪い合いが生じ、人の再割り当てを行わなければならない。他のプロジェクトに影響が及ぶ可能性も高い。責任のなすり合いが始まり、プロジェクト管理者とプロジェクト管理者が、財務アナリストとチームが、争うことになる。士気と透明性に犠牲が出る。

SAFeによるプロジェクトを超えた原価計算

従来型の原価計算を行うと、よりリーンでアジャイルなプラクティスに移行したり、より早く納品し経済効果を向上するという最終目標を達成することが、明らかに著しく妨げられる。これに対処するため、SAFeでは4つの統合プラクティスを導入している。それぞれについてこの後のセクションで説明する。この責任のほとんどは、戦略と投資財源、プログラム管理、およびガバナンスの主担当である プログラムポートフォリオ管理の下にある。

1. プロジェクトではなくアジャイルリリース列車に財源を割り当てる

最初のステップとして、予算やリソースの割り当てを社内で少なくとも1段階高いところに移動して、権限委譲を促進し、予算管理のオーバーヘッドを削減する。これは、価値のストリーム内のそれぞれのアジャイルリリース列車にリソースを割り当てることで行う。その様子を図4に示す。

Figure 4. Operating budgets (allocated spend, personnel and other resources) are defined for each release train in a value stream

図4. 運営予算(割り当てられた支出や人やその他のリソース)は価値のストリーム内のリリース列車ごとに決められる

こうすれば、PPMはこれまで同様に支出全体を制御できるが、人は長期間同じプログラムに専念できるため、士気や能力や生産性が向上する。リリース列車はリソースプールの役割も果たすので、課題やチャンスが現れたときに、プログラムは現在のコンテキストに合わせて柔軟に対応でき、許可を得るための遅延は発生しない。

2. プログラムに内容の決定権を与える

この方法の付加的な利点として、権限委譲が進み、意思決定が非中央集権化されて、プログラムで行われるようになる。ただし、やはり企業としては、プログラムが正しい取り組みに従事していることを確認する必要がある。これは、プロダクト管理の下で行われ、プログラムバックログとして可視化される。これを図5に示す。

Budgets article Figure 5. Content decision-making governance under the authority of Product Management

図5. プロダクト管理の権限下での内容の意思決定ガバナンス

プログラムバックログは、従来は今後の「プロジェクト」と呼ばれていたものを保持する軽量リポジトリである。この方法では「プロジェクト」から「フィーチャー」へと焦点が移るが、後者の方が、標準的なSAFeのフィーチャーと利点の形式であるため、目的に適合するための高度なコンテキストを備えている。作業はWSJFの経済的優先順位に基づいてプログラムバックログからプルされるため、受託者は、健全で論理的な経済的根拠に基づいて重要な決定がなされることを確認できる。

さらに、プログラムエピックは、プログラム内部の状況から発生したり、ポートフォリオエピックによって引き起こされる。これらは重要なため、ポートフォリオの可視性をある程度高めなければならなかったり承認が必要になるかもしれないが、特別に予算を組んだりリソースを専用に割り当てる必要はない。ART予算の範囲内で対処されるからである。

3. 動的なART予算編成で会計ガバナンスを行う

プログラムはほとんどの面で自己組織化および自己管理するものであるが、プログラム自体を作成したり、自分で財源を確保することはできない。ポートフォリオビジョンの目的を達成するために存在するだけである。目的を達成できるよう、PPMはプログラム予算を設定し調整する最終権限を持つ。また、使用できる予算およびリソースは100%しかないため、徐々にビジネスケースが変化するのに合わせて財源の割り当ても変更しなければならない。その様子を図6に示す。

図6. ART予算は状況に応じて動的に調整される

通常、この予算は年に2回調整することができる。回数がそれより少なければ、支出の固定される期間が長すぎて、その年の間、アジャイルに動きにくくなる。それより多ければ、プログラムは足元が定まらず、目先の目標にすら専念できなくなる。

4. ポートフォリオバックログの予算編成

このパズルの最後のピースは、複数のプログラムに影響する横断的な取り組みであるポートフォリオエピックの、財源の管理方法である。図7に示すように、ポートフォリオバックログの内容はポートフォリオカンバンシステムから流れてくる。

Budgets article Figure 7. The Portfolio Kanban system feeds the Portfolio Backlog

図7. ポートフォリオバックログの内容はポートフォリオカンバンシステムから流れてくる

ポートフォリオカンバンシステムは、規模も影響も大きい取り組みを分析するための手段となる。ポートフォリオバックログには、承認済みのエピックが、関連するARTでリソースに空きができるまで保持される。つまり、最後に残ったこの予算項目は、これらの取り組みが列車に渡されるときのために留保されている。現実に我々は、適切なポートフォリオエピックを実装するための処理能力を企業で確保する2種類の方法を目にしてきた。

  1. 予算期間ごとの開始時に、その期間の運営予算すべてを列車に割り当てる方法。この場合、それぞれの列車が目的に応じた相対的な割り当て分を受け取ることになる。ただし、その予算の一部は、プログラムではなくポートフォリオのバックログ項目の実装に使われることが前提となっている。(つまり、「予算はこれですべてだ。だが、ポートフォリオの取り組み用にサービス費用を集金に来ても驚かないように」ということである。)
  2. 使用できる予算すべてを列車に割り当てるのではなく、ポートフォリオエピックの実装に使用できる予備の予算を確保しておく。

後者に対する反論としてすぐ思いつくものが、「新しい取り組み(エピック)用にお金を用意したからといって、そのエピックを実現するための作業を展開するのに必要な人やその他のリソースを列車が入手できるとは限らない」である。ただし、実際には、額に応じた仕事ができることをどの管理者も知っているし、財源をいくらか追加すればより多くの価値を納品できるだけの力を人は持っている。そのため、予備の予算を確保する方法は、実績のある実用的な予算メカニズムであると言える。

ガバナンス

PPMは、ガバナンスにおいても重要な役割を果たす。その役割には、プログラムの支出から意図した結果(顧客満足度やプログラムのROI)までの関係を理解するという責任が含まれる。 これは主に、PIマイルストーンの再調査や、プログラム実装時のプログラムメトリックスによって行われる。さらに、エピックがポートフォリオバックログから実装に移る時に、PPMがエピックの成功基準を見直すこともある。


さらに知りたい場合

[1] Rami Sirkia と Maarit Laantiに特に感謝する。彼らは、 「scaledagileframework.com/leanagile-financial-planning-with-safe/」にて、このトピックに関するホワイトペーパを発表した。

[2] Reinertsen, Don. Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009.

Last update: 25 July, 2014

This information on this page is © 2010-2014 Leffingwell, LLC. and is protected by US and International copyright laws. Neither images nor text can be copied from this site without the express written permission of the copyright holder. For permissions, please contact permissions@ScaledAgile.com.