開発チームをスクラムなどを使って運営している時、改善がどんどん行われることは良いことである。しかし、その時によく起こりがちなのが、問題発見と改善にフォーカスしすぎた結果、チームの悪いところばかり見すぎてしまうことだ。過剰に悪いところばかり見てしまうと、徐々にチームが疲弊してしまうといったことが起こる。改善が捗ることは良いことだが、それでチームが疲弊してしまわないように注意しなければならない。
ちなみにスクラムガイドを参照してみると、スプリントレトロスペクティブの目的には「うまくいった項目や今後の改善が必要な項目を特定・整理する」と書かれている。つまり、デイリースクラムやふりかえり会などでは、問題発見と解決だけでなく、良かったことを言語化し再生産可能にすることも重視されているのである。
以上から、開発チーム運営では問題発見・改善だけでなく、良かったことの言語化・共有を大事にし、その2つをうまくバランスさせる必要があると考えている。
しかしながら、これまでの経験では、かなり意識的に良かったことを取り上げるようにしないと、結局問題発見・改善ばかりに目がいってしまうことが多かった。そのため、良かったことの共有を行いやすいように具体的に工夫したことを紹介してみる。
デイリースクラムに、良かったこと・自画自賛コーナーを設ける
良かったことを日常的に取り上げる場がないと、中々良かったことは共有されない。そこでデイリースクラムに「良かったこと・自画自賛」というコーナーを用意し、小さい良かったことや自慢を取り上げやすいように工夫したことがある。
ちなみに、次のようにいくつか失敗パターンもあった。
- 口頭でいうコーナーを作るだけだとなかなか出てこない
- 良かったことを自分の日記に書くみたいな形式だとなかなか出てこない
今まで試した中で良かったことが一番出てくるのは、デイリースクラムの会場をみんなで同時に書き込みできるツール（例: scrapbox、google docs）を使って用意し、ワイワイ書けるようにしておくことである。このようにすると、書きやすいだけでなく、誰かが書いた良かったことに対しさらにコメントが付くなどの連鎖反応が生まれることもあった。
他にも提案した自分が真っ先に書きまくるというのも普通に大事なので、そこは頑張りましょう。
KPTにGoodを追加してGKPTにする
KPTを使ってふりかえり会を行うのは定番である。しかし、Keepと言われると結構ハードルが高いようで、あまり良かったことが共有されないことが多かった。
そこでKPT会にGoodという項目を混ぜてGKPT（参考: http://c16e.com/1510132118/ ）にするという工夫をしたことがある。2チームほどでGoodを追加したGKPT会を経験したが、やはりKeepと比べてGoodは書きやすいようで、良かったことが出てくる割合が増えたように感じた。
また、Goodを増やして良かったことを書きやすくしたとしても、議論しやすいのはProblemなので、結局ふりかえり会の時間の大半はProblemについて話しているとなることも多い。そうならないように、GoodやKeepの時間を明示的に取るというのも有効だと思う。
あとは出てきたGoodやKeepを再生産可能な形に言語化するのはスクラムマスターやファシリテーターの腕の見せどころなので頑張りましょう。
まとめ
今回は、開発チーム運営では問題発見・改善だけでなく良かったこと共有を大事にすると良い理由と、そのために自分が具体的にした工夫を書いてみた。ただこのような工夫をしても、気を抜くと問題ばかりにフォーカスしてしまうことが多々あるので、より良い方法を模索していきたいと思う。
