チームは、頼まれた通りに働いていた。

言われたこと

ある開発組織が、生産性の問題に苦しんでいました。

仕事は想定より時間がかかっていました。機能はレビューまでたどり着いても承認されず、リリースは遅れていました。

プロダクト側から見た説明は単純でした。開発チームが、依頼された内容を一貫して提供できていない、というものです。

その説明が正しいなら、調べるべき明らかな対象はエンジニアリングの生産性でした。

観察したこと

チームは反復的に(イテレーティブに)仕事を進めていました。

実装の前に、ストーリーが話し合われ、期待される振る舞いが定義されます。その後、開発チームはスプリントの中でその振る舞いを実装します。

エンジニアたちは、それらの要件を無視していたわけではありませんでした。

むしろ、きちんと実装していました。

問題は、後になって現れました。

レビューの段階で、合意された受け入れ基準には含まれていなかった振る舞いが、仕事を承認してもらうために必要になることがありました。

例えば、あるストーリーが特定の操作について一つのワークフローを定義していたとします。

レビューの時点で、追加の条件が持ち込まれることがありました。「特定の状況下では、そのワークフローの一部を自動的にスキップすべきだ」というものです。

別の例では、合意された振る舞いが、操作が失敗した際にシステムがユーザーにどう通知するかを規定していたとします。

レビューの時点で、期待は「ユーザーに操作させることなく、システム自体が障害から回復すべきだ」というものに変わることがありました。

また別の例では、プレビュー機能が合意された基準を満たしていたにもかかわらず、レビューの段階で追加の操作機能が必要になることもありました。

個々の要求は、それぞれ理にかなっていたかもしれません。

問題はそこではありませんでした。

パターン

新しい期待は、仕様への変更として扱われていませんでした。

むしろ、開発チームが元の仕様を正しく実装できなかった証拠として扱われていました。

この違いが、すべてを変えていました。

プロダクトオーナーの視点からは、依頼した機能はまだ完成していませんでした。

開発チームの視点からは、合意された受け入れ基準はすでに実装済みであり、新しい要件は実装後になって現れていました。

組織は、その結果生じた遅れを、エンジニアリングの生産性の低さと表現していました。

しかし、実際に観察できた仕事の流れは、次のように異なるものでした。

1. 受け入れ基準が合意される。
2. 開発チームがそれを実装する。
3. レビュー中に新しい期待が現れる。
4. その新しい期待は、変更として分類されない。
5. その結果、元の実装は未完成として扱われる。
6. 追加の作業が、提供までの時間を延ばす。
7. その遅れは、エンジニアリングの生産性のせいにされる。

私たちの仮説

開発チームが抱えていたのは、主として生産性の問題ではありませんでした。

仕事が完了したかどうかを判断する仕組み自体が、不安定だったのです。

チームは、実装を始めた時点で存在していた受け入れ基準を満たしていても、レビューに通らないことがありました。仕事が評価される頃には、実際に適用される基準がすでに変わっていたからです。

これは、解決がとりわけ難しい生産性の問題を生み出します。

コーディング速度を上げても解決しません。

ツールを改善しても解決しません。

開発者にもっと正確な見積もりを求めても解決しません。

チームを劇的に速くしたとしても、動き続ける標的により早くたどり着くだけです。

この問題が見えにくかった理由

この仕組みが生まれるために、誰かが不誠実である必要はありませんでした。

プロダクトオーナーは、その追加の振る舞いが、もともと依頼した内容の当然の一部だと本心から信じていた可能性があります。

開発者たちも、合意された内容を正確に実装したのだと本心から信じていた可能性があります。

どちらの主張も、それぞれの理解を正確に表していたのかもしれません。

しかし、どちらの主張も、それ単独では仕事に実際何が起きていたかを説明していませんでした。

ですから私たちは、どちらの解釈が正しいかを決める必要はありませんでした。

私たちは、実装前に存在していた受け入れ基準と、レビュー時に適用された期待を比較しました。

その違いは、観察可能なものでした。

証拠が示したこと

報告されていた問題は、エンジニアリングの生産性の低さでした。

実際に観察された問題は、完了した仕事を受け入れる条件が、実装が終わったあとになって変わりうる、というものでした。

その結果、合意された仕様どおりの仕事であっても、未完成に分類されうる状態になっていました。

チームは、仕事を始めた時点では必ずしも存在していなかった要件によって評価されていました。

つまり、見かけ上の生産性の問題は、開発者だけを最適化しても解決できないということでした。

開発者たちは、受け入れ基準を満たせなかったのではありません。受け入れ基準の方が、仕事が終わったあとで動いていたのです。

Pulsarの視点

もし当初の診断をそのまま受け入れていたら、私たちは「どうすれば開発チームを速くできるか」という問いから始めていたでしょう。

しかし実際には、合意から実装、レビューに至るまで、仕事そのものを追跡しました。

組織が「問題」と呼んでいたものと、仕事そのものが私たちに示したものとの違いこそが、有用なシグナルでした。

語られていた問題はエンジニアリングの生産性でした。しかし、観察可能な問題は別の場所にありました。