スクラムチームでのゴリラの具体的な活用方法を考えたい。
その前にまずスクラムアンチパターンにおけるゴリラについて軽く説明する*1
ゴリラとは
チーム内にいる声の大きいメンバーのこと。
大抵の場合、技術的やプロジェクトの経験、ドメイン知識的に一番強い人間がこうなりがち。
ゴリラがチームに居るとチームはゴリラの意見や意向を伺うようになる。
自己組織化出来ないばかりかゴリラへの依存が高まりゴリラなしでは仕事が立ち行かなくなる。
一般的な対処法
- ペアプロなので知識をうまく使わせてもらう。
- チームの外に置いてアドバイザ的に使う。
一般的にゴリラの技術力・ドメイン知識についてはメンバーも認めていることが多い。
なのでその知識は活かしつつ他のメンバーにも少しずつそれを移していくアプローチ。
- どんな問題でも最後に発言するようゴリラに依頼する。
- ゴリラには発言するよりも質問するようにお願いする。
自立を妨げるゴリラを黙らせることで他のメンバーに強制的に自立を促す方針。
実際にゴリラと遭遇した
実際にチームにゴリラが出現したときの失敗談をここに残しておく。
なお今思うとゴリラは実は2頭いたのでそれぞれについて書く。
1頭目のゴリラ
組織図上の開発部門の部長で現在のプロダクト開発の大半を手動してきたわかりやすすぎるゴリラ。
スクラムチームにおけるゴリラと言っているが、実際には始める頃くらいに技術研究的な部署に異動になったのでチームの外に置くことには(勝手に)成功している。
しかしながらプロダクトの一部において未だにゴリラのレビュー承認を得ないとリリースできない状態になっている。
曰くチームだけに任せられる状態ではないとの判断とのこと。。。
ペアプロとかして徐々に知識を移していくのがよかったのかもしれないけど、
- 部署が変わったのでそもそも指揮系統が違う
- ゴリラ自身の性格の問題
そもそも指揮系統が違うのでこっちのプロダクトのために工数を割いてもらうことが出来ない(じゃあなんでレビューはやってんだって話ではあるんだけど)
性格についてはゴリラにありがちなやつ。聞いたことには答えてくれるけどキツイ文言で返ってきたりするアレ。
ゴリラがレビューフローに入っていることで計画が立てづらい。
ゴリラは計画に参加していないので設計レベルのレビュー打ち返しがしばしば発生するがゴリラの返しを恐れてゴリラの指摘通りの修正を行ったりしていた。
特に以前からのメンバーはゴリラと上司と部下という関係が長かった分、そういう行動を取ってしまいがちだったと思う。
きちんと説明すれば聞いてくれる方ではあり、メンバーにもまずは自分たちの意見として伝えるべきとしていたが上記の理由もあって全員がそれを出来たわけではない。
一方でチーム内のレビューでは見落としたがゴリラの技術力によって問題や不具合が事前に発見されることがあるのも事実。
タスクのフローがゴリラに依存せずかつゴリラの力を借りられる体制を作れればいいがどうすればいいんだろう?
ゴリラに聞かないとってわかるようなところならそもそも問題は発生しない。自分たちにはわからないけどゴリラが見たらわかるようなものをどうやって見てもらうか、が難しそうと感じている。
2頭目のゴリラ
1頭目のゴリラの次にプロダクト歴が一番長く、1頭目のゴリラが別部署になったことでプロダクトに関する質問や決定をしていく立場になり徐々にゴリラ化していった。
当初こそドメイン知識を少しずつ周りに移してく動きをしていたものの、徐々に普段の業務に追われて形だけになっていってしまった感じがある。
こちらのゴリラは「正しいやり方をすれば正しい結果になる」という考え方をする人で、結果として知識の伝達がうまくいっていないが理屈上は正しいことを言っているので周りは反論が出来ずという悪循環になってしまった。
理屈ではなく結果で判断しなかったこと、そして悪意があって行われているのではないからと行動を見逃してしまったことが大きなミスだったと思う。
(余談だがこの頃自分のタスクが重くとてもチームの状況に気を配れる状態ではなかった。やはり兼務はアンチパターンなのだと身を以て知った出来事でもある。)
そして何よりの問題は1頭目のゴリラに気を取られてチーム内に別のゴリラが出現しつつあることを察知出来ていなかったこと。いつからゴリラが1頭だけだと錯覚していた…?
ゴリラとの対戦を経て
ゴリラは実際強いのでその人を何かしら向きを変えるのはやはりパワーと諦めない強い意志が必要だなと感じた。
目の前の課題に追われがちでなし崩し的にゴリラの台頭を許してしまったのは大きなミス。
あと人は誰でもゴリラになりうるんだなという気持ちでいないといけないなと思った。
ゴリラへの警戒心がやばいなw