Quantcast
Channel: モチベーションクラウド Advent Calendarの記事 - Qiita
Viewing all articles
Browse latest Browse all 25

スクラム未経験者がチームメンバーと共に暗黒の時代を抜けて、エンゲージメント・レーティングをAAまであげた1年を振り返る

$
0
0

はじめに

この記事は、「モチベーションクラウド Advent Calendar 2018」19日目の記事となります。

モチベーションクラウドにフリーのエンジニアとして参画しておりました@ultrasevenstarです。

現在は英語学習のため一時モチベーションクラウドを離れフィリピンのセブ島で暮らしてます。
ここ何ヶ月かは完全に英語漬けで、全くコードを書いてません。

概要

モチベーションクラウドの開発現場ではスプリント毎にチーム状態を把握するため、モチベーションクラウドで
サーベイを取り、チーム状態を可視化しております。
その指標の一つとしてエンゲージメントスコアとエンゲージメントレーティングがあります。

そのエンゲージメントレーティングが上から2番目のAAになったまでの経緯をつらつらと書いていこうと思います。

当時の背景

参画した当時はモチベーションクラウドは2チームに別れ、それぞれのチームがスクラムマスター、POをもち個別に開発をしておりました。
僕はその一方のチームで開発を担当しておりました。

参画当時は特に大きな問題はなく、平穏に過ごしてましたが
開発の難易度が上がりだしした頃から、徐々にチームの雰囲気が怪しくなってきました。
ベロシティーが上がらないどころか、目標が達成できず落としてしまうことがよくあり
KPTでも「疲れた」や「終わりが見えない」などの根が深そうなプロブレムが頻出し、
振返りも十分に出来ていない状態で、トライを発表しても劇ツッコミを喰らうことも多々。

そんな状態なので、他のチームやお客さんから心配やお叱りの言葉を受けることが多々あり、チーム状態は燦々たる有様でした。
エンゲージメントレーティングも確かCぐらいだったかと。
いわゆる暗黒時代でした。

まずはスクラムを理解するとこから

モチベーションクラウドに参画した当初はフリーランスになって間もないってこともあり、イキってたんやろうなと思います。
スクラムよくわからんしとりあえず俺のやることだけやっときゃええやろう。
とりあえず俺の担当分だけ終わらせとけば問題なし!
スクラムマスター?何それ?PLみたいなん?
みたいな感じでした。

でもそれじゃ二進も三進もいかん状況になってきました。
チーム状況は改善される予兆もなく、相変わらずベロシティーも悪いまま。新たな問題も噴出しつつある。
そんな時にある人から
「君達はスクラムの基本が全然出来ていない。スクラムテストでも受けるぐらいのことはしてみなさい」
と手痛いお言葉を頂きました。

結局この言葉が引き金にはなり、自分の不甲斐なさやその他諸々に怒りも覚えたこともあって、
改めて自分自身振り返ってみると、結局僕がスクラムを全く理解出来ていない
理解出来てないのに改善なんてできるわけがない。って結論に達しました。

なのでまずは最低限のことだけでも理解せねばと
スクラムの入門書と名高い「SCRUM BOOT CAMP」を読むことにしました。

役割の線引き

SCRUM BOOT CAMPを読み終わって、チームの現状と照らし合わせた時に一番乖離があったのがスクラムマスターの立ち位置でした。
SCRUM BOOT CAMPを読む前はスクラムマスターってPL/PM的な立ち位置でチームのマネージメントや意思決定権をもつ人なんやろうなと思ってました。
なので、とりあえず色んなことをスクラムマスターに押し付けてました。
極端ですが本来チームメンバーが対応する必要があるものも何から何までスクラムマスターに押し付け、メンバーは開発だけやってた感じがありました。

スクラムは本来チームメンバーが主体となって色々決めていかないといけないはずが、スクラムマスター頼りのところがかなり多かった。
それって正常なスクラムの形ではないですよね。歪にひん曲がっている。
そんな状態やと改善することも難しい。
まずは正常な形にもっていかないと個々の役割があやふやになり、改善の指標も立てにくくなる。

なので正常なスクラムの形に持っていくために、スクラムマスターにはなるべく本来の仕事だけしてもらうよう、本来の業務以外のタスクは剥がし、役割の分担を行いました。

結論をだす

スプリントの振返りが正常に機能していない原因としては、結論が正しく導き出されていないと感じました。

振返りとしてKPTをやっており、プロブレムからトライを出す段で皆で議論をします。
議論をするんですが、皆思うところはあり、様々な意見が出ます。
色々な意見が出ることは良いんですが、収束させずに話が広がるだけ広がり収集が付かず、時間を迎えてしまうことが多々ありました。

一つのプロブレムに対して深掘りするのは良いんですが、深掘りしてるつもりが別の問題に発展しそれがまた別の問題につながっていく。そして気づけば愚痴になってる。みたいなことも良くありました。

だからファシリテートが必要で、ファシリテーターが結論に持って行ってあげないといけない
じゃないと議論が広がるだけ広がって、時間だけ無駄に過ぎていき、結局何も決まらない
もしくは無理やり強引に結論を作り上げる。みたいなことになります

プロブレムって結構出ますが、グルーピングすると3〜5になり
その3〜5のうちほんまにトライをうち解決が必要なものって1か2に絞れるはずです。
大体一週間もしくは二週間で速攻で解決しないといけない問題が山ほどあるとしたら
そのチームって崩壊してますよね。KPTなんかやってる場合やあらへん。

ですので、挙がったプロブレムを整理し、絞り、それを深掘りし結論に持っていくのが
ファシリテータの役目と考えています。

議論が逸れそうになると本来の道筋に戻してあげるのもファシリテータの役目です。
それさえ気を付けていればそれほど時間もかからず結論も出る議論になるはず

当事者意識

チームでは毎朝モーニングスクラムと言う名の進捗共有会をやっています。
やっているんですが、メンバーの数名かは遅れてきたり途中でトイレに行ったり雑談を始めたりすることが時々ありました。
そうなると余計に時間がかかったり、情報格差が生まれたりします。

最初は腹たったりしてたんですが、改めて客観的にモーニングスクラムを見てると無駄な時間が多いことに気づきました。
ファシリテータが一つの問題に対して深掘りしたいがあまり、一対一の会話になり他のメンバーが置いてけぼりをくらう。
進捗共有にしても、メンバーがファシリテータに対しての報告をする姿勢になっているので他のメンバーは聞いていない。

こんな状態なので、個々の問題は個々の問題のまま。
スクラムが提唱する個の課題はチームの課題という状態には程遠い。

なので、モーニングスクラムの時間を短く15分をめどに終わるようにしし、なるべく皆が集中しやすい環境を作りました。
深掘りについては後ほど時間を取って必要なメンバーだけで話をするようにし、課題の共有を図りました。

そうすることにより、ノイズが排除され課題の共有に集中することが出来、メンバーが課題を認識できるようになり
個の課題がチームの課題、チームの課題が個の課題とすることが出来ました。

他責は避ける

KPTをやってると他責を起因としたプロブレムが出ることがあります。
他責って「言うは易く行うは難し」の典型だと思っています。
同一チーム内では凄く共感を持ちやすいし、凄く言うてる感がある。
なので他責のプロブレムが上がると皆食いついて、それの深掘りをするんですよね。

でも他責のプロブレムって一朝一夕で解決するような問題ではないことが多いです。
だって関わる人数が必然と多くなるし、他人を変える必要があったりする。

どこの現場でも良く出る問題が
- ○○部署が全然情報をくれません。情報共有が出来ていません!
- なんだと?!それは由々しき問題だ!解決しないと
- 私、情報共有するスプレッドシートのフォーマットを作りました
- おっ!そいつは素晴らしい!早速〇〇部署に渡して書いてもらうようにしよう
1週間後
- 〇〇部署が全く書いてくれません
- なんだとっ?!だからあいつらはダメなんだ!

言葉は違えど上記のようなことは良くありました。
そもそも言うてやるぐらいなら言われる前からやってるはず。
この手の問題って言う方言われる方どちらもストレスが貯まり、時間も消費無駄に消費する。

そんな無駄な労力使うぐらいなら自分から聞きに行って、自分で共有してる方が建設的で速効で終わります。

他責が起因となるプロブレムを解決するなとは言いませんが、手間も暇もかかるものだと認識し、他人を変えるのではなく自分で何か出来る手立てはないかを考える方が得策です。

特にKPTでのトライのような速効性に重きを置くものとしては他責の解決は向いてないと考えます。

ホワイトボードで見える化

僕もそうなんですが、進捗の遅れがあったりするとどうしても目を背けたくなるのが人情ではないでしょうか。
でも臭いものには蓋をしてても、進捗の遅れは取り戻せたりしません。

なのでホワイトボードに付箋でタスクの管理を始めました。
ホワイトボードなのでそんな難しいことはせず、残課題をホワイトボードに貼り、終われば剥がす。
ただそれだけ。

ただそれだけなんですが、ホワイトボードに付箋なので否が応でも目につきます。
強制的な見える化です。目は背けれません。

これがもしスプレッドシートや他のウェブサービスなら一度そのURLを叩く行為が必要になり
必要が無ければ目にする必要もない。

でもそれじゃ結局スクラムマスターや一部のメンバーしか状況が把握出来ない。
それじゃ当事者意識も生まれにくい。

なので、否が応でも目に入るようにホワイトボードでタスクを管理し皆の目に入るようにし、タスクの共有化を図りました。

情報は足で稼ぐ

メンバーの状況を把握するため、一日最低一回チームメンバーと話をすると勝手に自分の中で決めました。
なので時間が出来ると皆の席まで行きほぼ雑談ですが話をしてました。

日々のモーニングスクラムやslackでも良いんですが、情報は一方通行で生の声は得づらい。

やはり個別に無駄話でも良いので話をしていると色々と情報が得られるし、仲も深まります。
また他のチームメンバーとも話も出来るので他のチームの状況も知れてそれを自チームにも落とし込めます。

お陰で皆には良く「暇なんですか」と言われましたが。

まとめ

そんな感じで細かい改善を繰り返してると、
自チームのモチベーションクラウドのエンゲージメント・レーティングがAAになっており、その状態をキープすることが出来ました。

改めて振り返ってみるとSCRUM BOOT CAMPに載っているような改めて書くようなことでもない基本的なことだらけでした。
でもその基本的なことが一番有用なのだなと感じた一年でした。


Viewing all articles
Browse latest Browse all 25

Trending Articles