チームが新しい習慣を身に着けようとして、なかなかうまくいかないときがある。習慣とは、ユニットテストを書く、コンパイラの警告をなくす、ビルドを壊さない、などのことだ。どうしたら、チームにこうした習慣を植え付けることができるだろうか？Clint Shankは(リンク)メンバーを移行させるために、あるゲームをデザインした。
そしてErik RamfeltはHudson用の「継続的結合ゲームプラグイン」(リンク)を書いた。開発者が良いことをするためには、ときに後押しが必要であるという前提にたったゲームである。
以前、ビルドを壊してしまう人がいるという問題がありました。そういう人を助けるために、いくつかの方法を試しました。交代でビルド監視役をつとめたり、ビルドを壊したら貯金箱に1ドル入れる、などです。いずれもネガティブな、懲罰的なものでした。それでは、ビルドを壊さなかった開発者に褒賞を与えるようなやり方はどうでしょう？作業を小さな単位に分割して早く頻繁にチェックインするという(リンク)ベストプラクティスをきちんと守っている開発者に報いるようなやり方はどうでしょうか？
Clintは、Darin Cumminsの「開発ゲーム」の記事(Agile Development Conference 2004)を読んだ。そしてビルドで問題を起こさなかった開発者を報いて、問題を起こしたら罰するようなゲームを思いついた。
Ericの実装によると、開発者のカルマは以下のように計算される。
ゲームのルール
- ビルドを壊したら-10ポイント
- すでに壊れているビルドを壊したら0ポイント
- ビルドで問題が何もなかったら+1ポイント(不安定なビルドにはポイントがつかない)
- 新しいテストが失敗するごとに-1ポイント
- 新しいテストが成功するごとに+1ポイント
他のプラグインに依存しているルール
Clintは以下のような注意を付け加えている。インチキをする人(たとえば、1時間ごとに無意味にチェックインするなど)が出ないように気をつけること。ときどきポイントを0に戻して、誰でもいつか勝てるチャンスが巡ってくるようにすること。
Scrum Developmentで(リンク)このことが話題になり、いくつかの懸念点が指摘された。Graeme Matthewが指摘したのは、得られる褒賞が大きすぎると、スコアを上げることに熱中してしまい、顧客へ価値を提供することがおろそかになってしまうかもしれないという点だ。Ilja Preussは以下のように述べた。
もうひとつ、気をつけるべき点があります。外的なモチベーションは、内的なモチベーションと激しく対立してしまうのです。つまり、チームの内的モチベーションが十分なときに外的モチベーションを導入すると、状況を悪化させてしまうかもしれないのです。
最後にPete Deemerが以下のように述べた。
個人にインセンティブを与えるような複雑なフレームワークは、「自分」思考を増長し、「われわれ」(チーム)思考を阻害してしまうと、私は思います。(「われわれ」思考は、Scrumで「隠れた推進剤」のひとつに数えられています。)そのようなやり方はミクロレベルでの最適化を招きます。ミクロレベルの最適化は、全体的な最適化の障害となります。それにまた、顧客にサービスを提供するうえでは不必要な、儀式や考え方がいろいろと生まれてしまうでしょう。