Steve Tendon氏が最近の彼のブログで、 “制約の理論とソフトウェアエンジニアリング”と題する投稿で、なぜソフトウェア開発組織においては、コスト会計よりもスループット会計の方を好ましいかを、述べている。彼はまた、ソフトウェアエンジニアリングに適用可能な スループット会計(Throughput Accounting)と呼ばれるコスト会計のための単純なモデルも提供している。
アーキテクチャ設計にような責任に加えて、ソフトウェアアーキテクトの役割は、ビジネスケースに注力する必要がある。アーキテクトは、アーキテクチャの決定にビジネス面を考慮する必要がある。さもないと、適当な経済価値の無いシステムを作ってしまうかもしれないからである。ソフトウェアエンジニアリングマネージメントを専門とするコンサルタントであるTendon氏のブログ投稿は、コストではなく、スループットをベースにしたビジネス価値の評価を提案している。
氏のブログ投稿は、コストではなく、スループットをベースにしたビジネス価値の評価を提案している。Theory of Constraints (TOC、制約の理論）をその「鎖は、その最も弱い結合以上のものを繋ぐものではない」という観点で、利用している。
TOCは、いかなるビジネスも インプットをアウトプットに変換するシステムとして考えている。インプットは、幾つもの作業工程を経て、アウトプットに変換される。アウトプットは、ビジネス顧客にとって価値のある、そして対価が支払われる製品／サービスである。
TOCの主要な考えは、いつもシステムのアウトプット能力を制限する作業工程がある、ということである。このエンティティは、能力制約リソース（CCR）と呼ばれている。氏によると、CCRは、しばしば、プロセスにおける作業と在庫の鎖となって明らかになる。ソフトウェアエンジニアリングにおける、在庫の単位は、 Rational Unified Processのユースケース、XPのストリーポイント、あるいは Scrumのバックログ項目である。CCRを最適化するために、この方法が提案しているモデルは、Wikipedia.org によると5つの集束ステップと呼ばれ以下のものからなる。
- 1. システムの制約を識別する（このために組織は、単位時間にもっとゴールを得ることができない）。
- 2. いかにシステムの制約を活かすかを決定する（いかに制約から最大限のものを得るか）
- 3. 他のあらゆる物を上記の決定よりも重要視しない（上の決定を支援するよう、全システムや全組織は一丸となって、上の決定を支援する）
- 4. システムの制約をもっと大きく取り上げる（制約を破るのに必要な他の大きな変更を行う）
- 5. 警告！！！！もし、前のステップで、制約が破られたら、ステップ1に戻る。しかし、慣性 がシステムの制約の原因となることを許してはならない。
TOCモデルを導入した後に、氏は、3つの公式によって定義されたスループット会計（TA)の概念を説明している。
- スループット: T = 収入－ 完全に可変な支出
- 純利益: NP = スループット － 運営経費
- 投資収益率: ROI = 純利益／投資額
ソフトウェアエンジニアリングに適用すると、
-
スループット:
TEは、機能するコードを製品に供給することで得られた現金の割合。販売価格マイナス 直接コストたとえば、パッケージング、配達、インストール、トレーニング、サポート、ネットワーキーング。 -
投資:
Iは、ソフトウェア製造システム プラス 顧客に価値のある機能を考えだすことに費やされるお金。その中には、ソフトウェア開発ツールや要求収集が含まれる。 -
運営経費:
OEは、アイデアから動くコードを開発するのに使われた全コストである。それは主に、ソフトウェアエンジニアの直接労務費だが、売るためのコストや一般的コスト、そして管理コストも含む。
この単純なモデルのお蔭で、ソフトウェアアーキテクトのような会計の専門家でなくても、TAを使うことができるようになる。多くの組織がよく、ビジネスパフォーマンスの改善のために、コスト削減を強調するが、スループット会計（TA)は、代替の考えを提唱する。Tendon氏は、次のように言っている。
コスト削減には、限界があるが、スループットの増加には、本質的に限界がない。コスト削減に余りに注力すると、会社の提供能力が危うくなり、その代わりにスループットが下がり、遥かに壊滅的な結果を招くことになる。
投稿の中で、Tendon氏は、 スループット会計 メソッドを適用できる3つの例を上げている。
- TAで運用経費を減らす一つのやり方は、実装前に要件を捨てることである。捨てられた各ストーリーが運営経費を減らし、純利益を増加させる。
- オープンソースを採用すると、投資を減らす助けになるが、運営コストが増加する。しかし、運用コストの増加は、同じシステムを開発するより安いだろう。
- リッチなマーケットを選んだ時、ソフトウェア組織は、そのマーケット用のユニークなフィーチャを提供することで、単位コストが増加するだろう。
Tendon氏が説明したように、TAは、ソフトウェアエンジニアが使える会計モデルであるばかりでなく、運営コストを減らすようなコスト削減にずっと注力してきた、これまでのコスト会計に対する抜本的な代替手段でもある。この投稿の終りで、氏は、日程、予算、リソース、スコープの点で、離職、雇用、プロジェクトのような他の共通のプロセスに対するTAの効果を説明している。
TAは、全てのビジネス・プロセスに関する管理側の決定を下すのに使うことができる。その中には、 離職、雇用、アウトソーシング、方法論の選択などのプロセスが入る。トリックは、単に情報に基づいた、財政的に健全な決定を下すために、あらゆる決定を
T,OE,Iに関連させることである。
何人かの読者がブログポストにコメントしている。例えが、 Robert McGinley氏は、制約の理論のアプローチを支持している。
私は"The Goal"読んだので、TOCを非常に信じてます。私はいつもTOCをSEに適用するのは、理にかなっている思うし、この記事には多くの素晴らしい説明があります。
氏はこの記事を気に入っているが、ストーリーポイントの扱いについては、賛成していない。
私は、ストーリーポイントを収入の見積り値に関連付けるやり方には、反対せざるを得ません。IMEストーリーポイントは、努力のレベルをベースにしており、見積り値は、努力のレベルとは直交しています。私は一般的に、顧客定義の価値の提供を追跡するために、Earned Business Valueを使うほうが好きです（とりわけhttp://danube.com/system/files/CollabNet_WP_Earned_Business_Value_041910.pdf と http://danube.com/system/files/CollabNet_WP_AgileEVM_and_Earned_Business_Value_Metrics_032510.pdfを参照してください）。これは、従来型と適応型の両方の開発に適用することができる。私がスコープと価値を同じ尺度を使って、追跡する人を知っていますが、それは疑わしいものでした。あなたの経験は、違うかもしれませんが。
Tendon氏のこの点への回答は：
そうです。ストーリーポイントを収入に関連付けるというのは、最善のアプローチでない、と仰るあなたの意見は、もちろん正しいです。しかし、私が扱ったケースでは、これが充分な概算値となり、容易に開発者の見積りを管理層の決定に必要な数値に橋渡しすることができました。言い換えると、それは、充分良いソリューションを提供できる実践的なアプローチだった、ということです。それは、平均で上手くいきます。平均して、ストーリーポイントは、収入の平均値に関連付けることができます。そして、もしあなたがToDoリストの優先順位付けに厳格なのであれば、その平均値は、リスト上に残る仕事の極めて良い代表になります。
氏は、この記事を楽しんだが、制約が必ずしも悪いとは限らない、と考えている。
制約は、必ずしも悪いとは限りません。CDSでは、制約は、主として生産量（これはまた、ソフトウェアでは、定義／測定が難しい）ばかりでなく、アウトプットの他の重要な特性、例えば品質、アウトプットがどれほど革新的であるかを決定します。更に、制約は、意図的にシステム設計（例えば、WIP上限、タイムボックス）の統合部分です。制約を変更することは、アウトプットを左右する（コントロールすではなく）重要なツールです。
ブログの作者は以下のように応えている。
そうです。制約は常に、あなた自身のゴールに照らして見なければなりません。ある制約は、実際あなたを正しい方向に導くでしょう（良い制約）、他の制約は障害になるでしょう（悪い制約）。両方をいかに見分け方を知ることが良いスキルです。またいかに人為的すなわち意図的な制約（KanbanにおけるWIPの上限のような）を設けるかを知ることは、あなた自身のゴールにとって有益になり得ます。