スクラムでベロシティ＝生産性を上げるHACK(イカチョロ版)

イカチョロとはなにか

最後に説明します。気になる人は最後までスクロールしてください。

まず最初にやること

スクラムにおいてたとえば13ポイントと見積もられたユーザーストーリーがあるスプリント中に終わらなかったとします。
だいたい8ポイントくらい終わっていて、残りは5ポイントとします。

このときこのスプリントのベロシティに途中まで終わった8ポイントは算入していないですか？
また次の見積時にこのユーザーストーリーの残ポイントは5ポイントに変更していますか？
つまり8ポイントをベロシティに参入せず、あらたにユーザーストーリーのポイントを5ポイントとして直していますか？
もしそうなら

• 8ポイントをスプリントのベロシティとしてカウントする
• ストーリーの残ポイントは無視して引き続きユーザーストーリーは13ポイントとし、次スプリントで終了時にベロシティに13ポイントカウントする

このいずれかをやってください。
なぜかというと、この方法に改めることで次以降のHackが格段にやりやすくなるからです。

実際のHACK方法の紹介

Definition of Done の緩和

言葉通り、完了定義を緩和させます。
スプリントの最終盤に、見積8ポイントのユーザーストーリーを初期に分解したタスクをすべてDONEさせたとします。

しかしデプロイして実際にユーザーストーリーにあらわされた便益をユーザーが享受するには実は追加でなにかしなければいけなかったとします。
追加作業は約2ポイントであり、それをおこなった場合今スプリント中にユーザーストーリーが完了しなかったとします。
厳密なDefinition of Doneを運用する場合、今スプリントのベロシティが8ポイント減る危機です。追加作業で残っている分2ポイントは次スプリントのベロシティに計上できるかもしれませんが、8ポイント減って2ポイントプラスでは6ポイントマイナス、生産性的に大損です。

そこで、完了定義を緩和します。
追加作業は新規で何らかのタスクとして見積2ポイントで起票され、次スプリントでDoneされます。
するとベロシティには8ポイントがプラスされ、さらに追加タスクも含めて2ポイントも増えます。

合計10ポイントベロシティが増えますね。
生産性がグッと上がりました。
もし問題があるとすれば、完了しているユーザーストーリーがあるのにスプリントレビューに出せないことになるわけですが、ここも運用でカバーする必要があります。生産性向上のために工夫する必要がありますね。

チームの分割

実はベロシティにカウントされるべき作業はチーム全員の作業が対象ではありません。
ベロシティにカウントされるべき作業を担当するメンバーと、カウントされないメンバーにチームを分けることができます。

普通は新卒や入社したばかりのメンバーなど未熟でパフォーマンスが安定しないメンバーをカウントしないメンバーに当てます。

しかしここで一工夫を入れます。
カウントしない側に、ある程度はパフォーマンスが期待できるメンバーを入れるのです。人事評価的には生産性向上に寄与していないことになるので、業務委託などのメンバーがいいかもしれません。

そしてその人にCynefin Frameworkにおける複雑系の作業を任せるのです。
つまり安定してベロシティが出せるか、いつまでに終わるかがはっきりしない作業だけを集中的に任せるわけですね。

するとアウトプットをベロシティにカウントされる他のメンバーは、集中的に安定してDoneさせることができるユーザーストーリーやタスクに集中することができます。Cynefin Frameworkにおける煩雑系の作業に集中できるわけですね。

安定してアウトプットできる作業にフォーカスして作業することで、生産性を上げやすくできます。

リスクを見積に折り込む

ユーザーストーリーの見積において、リスクの大きさはポイント見積に跳ね返ります。
そこで、常に皆を慎重にさせるのです。

• あの変更に関わる部分は仕様が複雑だから
• あの機能は現行コードが汚いから
• あのユーザーストーリーの変更には他チーム作業への待ちが出るかもしれないから

あれやこれやの言い訳を並べ立てていくだけでポイントが膨らんでいきます。
ポイントが膨らむと言うことは、完了させた時のベロシティが上がると言うことです。
みなさん、他に心配なことはありませんか？

実際にはDefinition of Readyの定義を厳格化し、リスクを正当に見積もるための先行調査タスクやブロック作業の前後を別ストーリーとしてぶったぎる方法もできます。
しかしそうすると、リスクでポイント増加ができなくなります。
つまりベロシティの増大がちょろくできなくなるわけで、その方法はベロシティや生産性に寄与しないわけですね。
なので基本は、ユーザーストーリーを大きく、リスクをたっぷり盛り付けて、が正解になります。

イカチョロとはなにか（解説編）

イカサマやチョロまかしのこと。つまり本質的な意味のない、見た目だけの誤魔化しのこと。
システム開発某社で使われていた用語であり、「こんなものはイカチョロだ」と言われた場合は「すぐに修正せよ」という意味合いを持ちました。

ノルマのきつい冷戦期の共産圏の国家ではよくあったらしいですね。
炭鉱で出荷ノルマを誤魔化すために、石炭を積んだ貨車に何台かガラクタしか積んでいない貨車を混ぜるような。
ちなみに「失敗の本質」のような古い本を読んでいると類義語として「イロケ」が出てきますね。

最初にやらせた見積やベロシティの計算方法の変更は何だったのか

ベロシティの厳密化とはスプリントの計画とコミットへの厳密化に他なりません。
つまり最初に厳密にリスクを洗い出し、作業内容をはっきりと明確化させ、スプリント計画へのコミットへの逃げ場をなくさせるのです。

上記のイカチョロHACKの内容は全て、スプリント計画へのコミットを骨抜きにし、逃げ場を作ってその逃げ場で誤魔化すための施策です。
ぱっとみは生産性が上がっているように見えますが、スクラムの恩恵である本質的なアウトカムやアウトプットの改善。あるいは本質的な価値へのフォーカスとリソースの集中配分とは背反する行動になります。

簡単に言うと、あの計算方法をやったが最後、チームのスクラムのレベルはある段階以上には絶対に上がらなくなります。
また既にあの方法を導入してしまったチームは意図せず不正が横行しているも同然なので、不正なやり方のアンラーンをどう行わせるかが最初の課題になります。

要するにどういうことや？

• 君のチームで上のようなハック(=イカサマ)をしようとしているなら絶対にやめろ
• もうやっているなら、どうやってやめさせるかを真剣に考えたほうがいい
• あるいは、このチームのスクラムはもうあるレベルまでは絶対に上がらないんだなと諦めて、転職か異動のために頑張ったほうがいい