マネジメントのためのScrum入門

Agileにおける評価指標

2022/04/02

Agileで生産性が上がったか?」を評価することの矛盾

Agile Coachをしていると…多くの方から、上司から「Waterfallと比較してAgileにして…どれだけ生産性が上がったか示す指標が欲しい」と言われているという相談を受けます。

そんな相談を聞くたびに、昔…お客様に「新しい提案持ってきて!」と頼まれたので、斬新な提案を持ち込んだら「で…実績は?」と聞かれたことを思い出します。このお客様が言っていることがどう矛盾しているかはすぐに分かるかと思います。

しかしAgileを「ものづくりが早くなる…生産性が上がる開発手法」と捉えてたら…Waterfallよりどう早くなったかを比較計測したくなるかと思います。しかし前回も書いた通り…この考え方はAgileに関する典型的な勘違いです。

Waterfallは、「顧客価値を実現するであろう機能と工期を最初に確定し、予定通りに完成させる」というアプローチです。一方アジャイルは「最初に定義した顧客価値を実現するため、細かく計画を見直しながら、予定通りに価値を届ける」というアプローチです。

Waterfallでは、「最初に確定したを予定した期間で完成させる」…つまり「÷ 期間」で生産性を表現できると考えます。しかしこの考え方は「最初の顧客価値が最大になるを正確に量ることが可能である」ことが前提になります。ですので、過去何度もやったことがあって、今回も同じ方法で「顧客価値の最大化」ができるのであれば、きっとWaterfallで良いのだと思います。もちろんScrumの手法…チームワークや学びの最大化などを活用して、より高い生産性を実現することも可能ではあります。

しかし、Agileを導入しようとマネジメント層の方は思ったのでしょうか。

もし…今の仕事が「最初の顧客価値が最大になるを正確に量ることが可能である」ものの、更に生産性を上げるたい!と思っているのであれば、WaterfallにAgileなプラクティス…例えば、ポイント見積もり、機能横断で自己組織的なチーム作りを取り入れつつ…「要件が変わらないScrum」を行っても良いと思いますし、一定の効果は出ます。

ポイント見積もりはチーム間比較ができませんので…

  • まず機能横断なチームを作る

  • Waterfallプロジェクトをポイント見積もりで実施する

  • 同じメンバーでScrumを取り入れて、ベロシティの向上を比較する

ということは、理論的には可能です。しかし多くのWaterfallな組織は、機能横断なチーム構成ではないですし(機能横断なチームという考え方自体…Agile的ですし)現実的ではないと思います。効果を上げることより、計測することに主眼が置かれ…手段と目的が入れ替わってしまいます。

多くのマネジメント層は、本来…「期待された顧客価値を届けられないため、顧客満足度が上がらない」という課題を解決したかったのだと思います。それはつまり顧客が欲しいのは「ではなく価値」であることを再認識しなくてはなりません。

沢山の量を届けることより、沢山の価値を届けたい…つまり生産性の計算式は、÷ 期間」から「価値 ÷ 」もしくは「価値 ÷ 期間」に変わるべきなのです。

本当にAgileが有効なのか…数値評価したいのであれば、WaterfallでもAgileでも…この価値を色々な手法で数値化する必要があります。

くれぐれも経済学で言う…「AppleとOrangeを比較する」ことにならないようご注意ください。

個人評価と相性の悪いAgile

また、「Agileで個人のスキル…生産性が上がったのか数値評価したい。」と上司が言っている…いう相談も多く受けます。

そもそも、Agile…特にScrumでは個人評価は推奨しません。個人評価は部分最適を加速し…全体の生産性を下げてしまいます。

例えば、サッカーでいうなら…「うちのチームの評価指標はゴールだ!」としたらチームは強くなるでしょうか?全員がゴール前に押しかけて「ボールをよこせ!」と叫んでいたら勝てるのでしょうか?「失点が少ない」を指標したくても、失点の責任は誰と定義するのでしょうか?「1対1デュエル勝率」「ドリブル突破成功率」にしたらどうでしょう。勝利と関係なくても「勝てる勝負をできるだけする」選手の評価が高まります。結局「チームの勝点」が一番わかりやすい評価指標になります。

またチームの勝利のためには様々な人材が必要です。メッシがいくらサッカーの天才だったとしても、全員メッシのチームはきっと勝てません。点を取ることだけでなく、チャンスを作ること、リスクを減らすこと、守ること…は当然として、チームワークを高めるためにできることはプレイ以外にも沢山あります。ムードメーカーだったりキャプテンシーの高い選手もチームには必要です。

これって…チームスポーツだけの話ではありません。ソフトウェア開発も含めた「チームが協力してする仕事」すべてに言えることです。

優秀な設計者が…製造や試験が間に合っていないのに…設計を量産し続けても、チームが生み出す「」や「価値」は増えません。しかし苦手な「製造や試験」を手伝うより、得意な設計だけやっている方が、個人の生み出す÷ 期間」は高くなります。

マネジメント層が本当にAgileな組織を作って行きたいのであれば、個人評価指標を作ることのムダに気づき、チーム評価を重視することをおすすめします。

※顧客とのAgileな付き合い方について次回に…