第17回ニコニコ・カレンダからチームの状態を読み取るコツ

2006.08.07

　前回に引き続き，ニコニコ・カレンダ（以下ニコカレ）を取り上げる。今回は，実際にTRICHORD開発チームのニコカレを見ながら，チームのムードの動きとその見方を考えていきたい。TRICHORDチームのニコカレはTRICHORDのプロジェクト状況公開サイトで閲覧できる。

　TRICHORDチームでは，1イテレーション＝1週間（4日間）であり，金曜日は午前中をふりかえり＊1に，午後を12％ルール＊2での個人開発の時間に当てている。1リリースは3イテレーションで構成され，リリースとリリースの間の1週間は，次のリリースの準備として，たまった課題やバグをつぶしたり，次のリリースのためのプランニングをしたりするインターバル週と位置付けている。

　まず5月29日～6月9日のカレンダ（図1）を見ていただきたい。5月29日から6月2日までの1週間はリリース週（6月1日リリース）だったため，5月31日まではチーム内でGood（黄色）が1つしかなかった。リリース当日はどうにかリリースを終えたこともあってGoodが増えた。翌6月5日～6月9日の週はリリース・インターバル週である。ちょうどこの週は，データ・マイグレーションのための緊急リリースなどもあったが，順調に進んだため比較的Goodが多かった。

図1 TRICHORD開発チームのニコニコ・カレンダ（5月29日～6月9日）
気分と色との対応は，Good＝黄，Normal＝赤，Bad＝青，である。6月1日がリリース日だったため，前日まではGood（黄色）が一つしかない。

　次に6月12日～6月23日のカレンダを見てみよう（図2）。6月12日からの週は，このリリースで最初のイテレーション・プランニングを実施して，リリースへ向けて走りはじめた段階だ。ちょうど6月12日夜にサッカー・ワールドカップ日本戦があり，オーストラリアに逆転負けしたときである。コメントにも日本の敗戦を挙げているメンバーが何人かいた。この週は後半に大きな問題が発覚して，その対応でチームが疲弊していたタイミングだった。翌6月19日～23日の週は，前週の問題対応のダメージをひきずっていたが，水曜（6月21日）にスコープ調整をすることになり，チームのムードの低下が一段落したことが分かる。

図2 TRICHORD開発チームのニコニコ・カレンダ（6月12日～6月23日）
6月12日からの週は，大きな問題が発覚し，そのチームがその対応に追われたためにBad（青色）が目立つ。

　最後に6月26日～7月7日のカレンダを見てみる（図3）。通常は木曜日がリリース日であるにもかかわらず，この週は火曜日（6月27日）がリリース日ということもあって，時間とリリースのプレッシャーで全員見事にBadになっている。しかし6月29日には全員Goodになった。これは6月29日にオブジェクト倶楽部＊3主催のイベントに参加したからだ。続いて翌7月3日～7日の週はリリース後のインターバル週のため，課題とリリース・プランニングに時間を割いた。この週は比較的自由に各人が自分の作業をしていたので，特に問題なく1週間が終った。

図3 TRICHORD開発チームのニコニコ・カレンダ（6月26日～7月7日）
6月29日が全員Good（黄色）になっているのは，この日にオブジェクト倶楽部主催のイベントがあったため。

　ここまでの経過を1つのカレンダにすると図4のようになる。遠目でみると，全体の中央部分にBad（青色）が多く分布していることが分かるだろう。Badが集中している時期は，開発が思うように進まなくなり，メンバーの疲労がたまっていた時期と一致する。一方，Good（黄色）は連続してはいないが，チームの大多数がGoodをつけるポイントが数回存在する。このようなときには何らかのイベント（宴会，イベント参加）があった。

図4 図1～3をまとめて休日部分を削除したもの
紫色の部分がリリース日。遠目で見ると，中央部分にBad（青色）が目立つ。
[画像のクリックで拡大表示]

　ここまでのニコカレから何が読み取れるだろうか？確実に言えるのは，リリースが近づくにつれて時間的なプレッシャーが増えると，気分も下降するということだ。さらにトラブルや新たな課題が発生して開発が予定より遅れてしまうと，個人差はあるにせよ，チーム全体の気分が大幅にダウンしてしまう。逆に毎週金曜日の12％ルールの時間やリリース・インターバル週が，チームの気分が底無しに停滞しないための防波堤になっていることも見えてくる。イベント参加や宴会といった出来事がチームの気分を盛り上げることもよく分かる。

　筆者は以前，ニコカレを「Badが増えたら即座に対処する」というイメージでとらえていた。しかし開発の現場では，そうそうBadが増えたくらいですぐにアクションを取ることは難しいし，個人によってBadの持つ意味合いも異なる。今では，対処療法ではなく，管理できない個人の気分を眺めながら，悪い方向に進み続けないように，適度な舵とりをすればよいのではないかと考えるようになってきた。

　つまり，良い状態を持続するというよりも，むしろ悪い状態を持続させないようなアクションを取る方が無理がないのではないかということだ。気がついたら全員が丸々一週間Badだった，という状況をいかに回避するか，回避するためのアクションを取れるかどうかが，ニコカレを使いこなすポイントではないかと考えている。

　最後にニコカレの注意点を示しておく。ニコカレを採用する際は，「Good」の入力を強制するような場を作ってしまってはいけない。あくまでも自然な状態で，個々の気分を入力できる場作りを心掛けるのが重要だ。何があってもGoodばかりのニコカレは，本当に最高の状態か，全く信用できないかのどちらかである。管理者に見せるというよりも，むしろチーム内のほかの開発者に向けて入力するようになって初めて，ニコカレはチームの状態を正確に視覚化できるようになる。