アウトカム vs アウトプット

2020年2月11日

ショッピングサイトのソフトウェアを開発するチームを想像してみてください。チームのアウトプットを見る場合、前四半期に作成した新機能の数や、ページ読み込み時間の短縮といった機能横断的な指標を検討するかもしれません。しかし、アウトカム指標は、売上高の増加や製品のサポートコール数の減少を測定します。アウトプットではなくアウトカムに焦点を当てることで、ソフトウェアのユーザーと顧客の効率を向上させる機能の構築が優先されます。

他の専門的な活動と同様に、ソフトウェア開発に携わる私たちは、何が私たちをより効果的にするかを知りたいと考えています。これは、自身のパフォーマンスを向上させようとする個々の開発者、組織内のチームを改善しようとするマネージャー、あるいは私のような専門家が業界全体のレベルを引き上げようとする場合にも当てはまります。これを難しくしていることの1つは、ソフトウェアチームの生産性を測定する明確な方法がないことです。そして、この測定の問題は、有効性をアウトプットに基づいて評価するか、アウトカムに基づいて評価するかによって、さらに複雑になります。

私は常に、アウトカムこそが私たちが集中すべきものだと考えてきました。チームが多くの機能を提供する場合 - コード行数、ファンクションポイント、ストーリーなどで測定する場合 - その機能は、ユーザーの活動を改善するのに役立たない場合は意味がありません。多くの未使用の機能は無駄な労力であり、実際にはそれ以上に、コードベースを肥大化させ、将来新しい機能を追加することを困難にします。このようなソフトウェア開発チームは、新しい機能の有用性を重視する必要があり、より少ない機能を提供することで改善しますが、より大きな有用性があります。

アウトカムベースの観察を使用することの反対意見として、アウトプットよりもアウトカムの再現可能な測定値を考え出すのが難しいという意見を聞いたことがあります。私はこの点を理解するのが難しいと感じています。ソフトウェアの純粋なアウトプットを測定することは、非常に難しいことで有名です。コード行数は、簡単に操作できなくても、役に立たない指標です。ファンクションポイントまたはストーリーポイントには再現性が低く、同じものでも人によって異なるポイントスコアが付けられます。これと比較して、私たちは財務上の成果を測定することに非常に長けています。もちろん、多くのアウトカムの観察はより難しいものですが(顧客満足度を考えてみてください)、ソフトウェアの機能よりも難しいものはないと思います。

もちろん、何かを「アウトカム」と呼ぶだけでは、それが注目すべき正しいものになるわけではなく、観察する正しいアウトカムを選択するには確かにスキルが必要です。便利な概念の1つは、Seiden(サイデン)の考え方です。彼は、アウトカムは、組織にとって良いことを推進するユーザー、従業員、または顧客の行動の変化であるべきだと言います。彼は、観察しやすい行動変化である「アウトカム」と、組織へのより広範な影響である「インパクト」を区別しています。EDGEの開発において、Highsmith(ハイスミス)、Luu(ルー)、Robinson(ロビンソン)は、顧客価値に関するアウトカム(食器洗い機の信頼性)は、ビジネス価値に関するアウトカム(保証修理費用)よりも重視する必要があるとアドバイスしています。

アウトカムの観察に関する重要な懸念は、それをソフトウェア開発チームに割り当てるのが難しいことです。サプライチェーンにおける商品の品質を追跡するためにソフトウェアを使用する顧客チームを考えてみましょう。最終消費者による拒否の数を基準に評価する場合、そのうちどれだけがソフトウェアによるもので、どれだけが品質アナリストによって開発された品質管理手順によるもので、どれだけが原材料の品質を向上させるための別のイニシアチブによるものでしょうか?この配分の難しさは、Clojureを使用することでチームの効率が向上したかどうかを判断するために、異なるソフトウェアチームを比較したい場合、大きな障壁となります。同様に、開発者がうまく機能し、品質を追跡するための優れた価値のあるソフトウェアを提供しますが、品質管理手順が適切でない場合があります。その結果、拒否は減らず、イニシアチブは失敗と見なされますが、開発者は自分の役割を отлично こなしています。

しかし、配分の問題は、間違ったことを観察する理由として解釈されるべきではありません。一般的なフレーズは「測定するものになる」と言いますが、この場合は「測定しようとするものになる」と言った方が適切です。成功の評価をアウトプットに焦点を当てると、誰もがアウトプットを増やす方法について考えています。そのため、チームの作業がアウトカムにどのように影響するかを判断するのが難しい場合でも、人々がアウトカムとその改善方法について考えているという事実は、間違ったものを生成するチームの熟練度を比較しようとする努力よりも価値があります。

参考文献

Seiden(サイデン)は、アウトカムを考えるための優れたフレームワークを提供しています。これは、同様に仕事のインパクトを評価するという難しい仕事をしている非営利団体の経験に基づいています。

私の同僚は、デジタル世界で働くためにビジネスを変革するための運用モデルとしてEDGEを開発しました。アウトカムに焦点を当てることは、彼らの哲学の中核です。

アウトカムに焦点を当てることは、当然のことながらアウトカム指向チームを支持することにつながります。

謝辞

エクストリームプログラミングの初期の頃の仲間のパイオニアたちは、アウトプットの観点からソフトウェア開発を評価することの欠陥を非常に認識していました。初期のアジャイルカンファレンスのワークショップで、ロン・ジェフリーズと私が、チームの有効性の測定はアウトプットではなくアウトカムに焦点を当てるべきだと議論したことを覚えています。ただし、当時はまだこれらの言葉を使用していませんでした。その考え方は、私の投稿生産性を測定できないにも反映されています。

2000年代にThoughtworksの同僚がアウトカムとアウトプットの区別について話し始めたのを聞き始め、Daniel Terhorst-Northは、アウトカムを機能よりも優先することを5番目のアジャイルの価値にすることを提案しました。このアウトカムへの賛同は、リーンエンタープライズEDGEデジタルトランスフォーメーションゲームプランなど、Thoughtworksから生まれた書籍で繰り返し取り上げられています。

Alexander Steinhart、Alexandra Mogul、Andy Birds、Dale Peakall、Dean Eyre、Gabriel Sixel、Jeff Mangan、Job Rwebembera、Kief Morris、Linus Karsai、Mariela Barzallo、Peter Gillard-Moss、Steven Wilhelm、Vanessa Towers、Vikrant Kardam、Xiao Ranは、社内メーリングリストでこの投稿の草稿について議論しました。Peter Gillard-Mossは、Seidenの本と非営利団体からの他の仕事に私を導いてくれました。