関西人スクラムマスターがとあるチームと過ごした日々(UAS3より)

こんにちは、ギルドワークスの中村 洋です。

以前、2つの期待マネジメント(前編)「内側の期待」をすり合わせる「ドラッカー風エクササイズ」(USA4より)というエントリを書きました。

今回はその1年前の「UltimateAgileStories3(UAS3)」で書いた内容を許可を得た上で、一部加筆、修正した上で公開します。

Ultimate Agile Stories とはアジャイル開発をテーマにした同人誌で、毎年1冊ずつ、これまで4冊出ています。
毎冊、30人前後の書き手が、アジャイルに関する本当に多くの様々な想い、実践話を綴っています。
詳しくは発起人である細谷さんのブログに書かれています。
またUASの利益は、東日本大震災の被災地支援として寄付されています。

UASは主に関東方面でのAgile系コミュニティなどで頒布されますので、お見かけした際にはぜひ手にとっていただければと思います。

◆関西人スクラムマスターがとあるチームと過ごした日々

今回は、私がかかわることになったあるチームと過ごした日々のお話です。

◆あるチーム
チームメンバーは5人。デザイナー1人、エンジニア2人、(他チームも兼任している)インフラエンジニア1人、そしてスクラムマスターの私という構成でした。

メンバーはまだ20代と比較的若く、あまりチーム開発をしたことがありませんでした。ミッションはいくつかのWebサービス、Webサイトの開発、改善を行うことで、私のミッションはそのチームビルディングをして、より成果を出せるチームになってもらうことでした。

このチームと数ヶ月一緒に過ごした中での出来事を「課題」「取り組んだこと」「結果」「工夫したこと」という形でお話します。

◆第1スプリント ~立ち上げ~
 
この時の課題:
1:誰が何をしているか分からない
2:計画がなく、優先順位や指示が不明確
3:指示待ち、受動的な感じになっている

チームに参加した初日の朝会は、ダラダラ集まり、ボソボソ話して、決まったリズムなく解散という感じでした。

そのため誰が何をしているか分からず、(ある期間に)何をしないといけないか?も見えていませんでした。また「このタスクは何のためにするのか?」をチームや依頼した人がお互い話し合っていないこともありました。
また(一見急ぎに見える)割り込みタスクもあり、1週間レベルでの計画も立てることができていませんでした。
その結果、対応が後手に周り、(自分でハンドルを握っていない)やらされ感のようなものがありました。

取り組んだこと:
1:朝会の改善
2:1週間単位での計画(タスクボードを利用)
3:ふりかえり

まず「誰が何をしているか?」をチームも私も必要でした。そこで、朝会ガイド(※リンク先はPDF)をベースに私が司会役で、チームのリズムを作るため朝会を実施しました。
朝会ガイドにあるシンプルな3つの問いに答えるというテンプレートに乗っかることで、うまくリズムを作りながら、話す内容に集中できます。

また計画と進捗を見える化するため、ホワイトボード、付箋、ペンなど一式を調達し、チームのタスクボードを作りました。
このタスクボードを見ながら毎日朝会をするリズムを作っていきました。

タスクボードには1週間の中で「自分達がやらないといけない(と思っている)総量」を見える化するために、自分が持っているタスク、やらないといけないタスクを全て表現していました。
この時点のタスクボードはシンプルなTodo/Doing/Doneの3レーンで、タスクには見積もり時間(残時間)や期日は書きませんでした。

そして1週間の終わりにはふりかえりガイド(※リンク先はPDF)をベースにふりかえりを行いました。その時に「この1週間にやらなければならないタスクがどのようにできたのか?どう感じたのか?」なども話し合うようにしました。

結果:
朝会が定着しチームにリズムが出て、タスクボードに見える化ができたことで「お互いどんなタスクをそれぞれが持っているのか?」が見えるようになってきました。 

タスクボードを導入したことで、タスクの粒度がまちまちだったり、完了の定義があやふやであるといった次の課題も見えてきました。
また別の課題として、Todoの時点でタスクに担当者の名前を書くようにしていたため、自分のタスクに関心が集まり、「チームとしてどうなのか?」という視点、アクションが弱いということもありました。

◆第2スプリント ~中盤~

この時の課題:
1:個人のタスクにフォーカスしている

Todoの時点で「このタスクは誰がする」とある程度決めていたこともあり、「他のメンバーのタスクに目が行かない」「チームとしての今の状態」が分かりづらくなっていました。

取り組んだこと:
1:バーンダウンチャートの導入
2:タスクボードの運用を工夫(Doingに持っていく時点で名前を書き込んでもらう)

バーンダウンチャートを導入し、立ち上げの頃はしていなかった、残時間を見積り、タスクに書くようにしました。
バーンダウンチャートは「チームがこのペースで行けば、どの辺りが着地点になるか?」を示す側面もあるので、(個人がどうであれ)「チームとしての状態」が見えるようになりました。

見積もりについては(全てではありませんでしたが)チームで行うようにして「Aさんだけがこのタスクを知っている」ということが少なくなりました。

どうしてもこの人でないといけないタスク以外はTodoからDoingに持っていく際に担当する人が自分でサインアップする形にしました。

結果:
「自分だけ」という視点から「チーム」として「何を」「いつまでに」終わらせないといけないのか?という視点に変わってきました。
「誰がそのタスクをするか?」を決めるタイミングを遅らせることで、チームとしてリソースをうまく使えるようになってきました。

◆第3スプリント ~終盤~

この時の課題:
1:バーンダウンが落ちない 
2:ふりかえりがフワッとしている

何度かスプリントをこなすうちに、バーンダウンチャートがなかなかバーンダウンしないパターンが出てきました。
ふりかえりで「そもそもどういうタスクが多かったのか?」などと話し合っている中で見えてきたその原因は「割り込み作業の多さ」でした。

チームの業務フロー上、計画したタスク以外に他チームからの(一見緊急に見える)作業依頼が多く来る特性がありました。
#本来は、1週間という短いスプリントなので、その割り込み自体を無くすことを目指したかったのですが、すぐには難しい状況でした。

また、ふりかえりは継続していたものの、特にProblemやTryの内容が、フワッとしており深掘りできておらず、アクションにつながっていないものもありました。

取り組んだこと:
1:割り込みタスクを見越してスコープを決めた
2:割り込みタスクの扱いを工夫した
3:ふりかえりの内容をさらにツッコンで話し合った

日常タスクに割り当てることができる時間を6割程度とみなして見積もりをし、スコープを決めるようにしました。経験上、業務時間のうち、開発に専念できる環境で7割くらい(これは素晴らしいことです)、普通なら5割以下しか実際の開発に集中できる時間は取れないと感じています。

また、割り込みタスクをタスクボードに追加する際に、その優先順位をタスクボード上で表現しました。「急ぎであればDoingレーンに近い側に、そうでなけれれば遠い側」という感じです。

そして、その割り込みタスクも(他のタスクと比較して)優先順位を決めるようにして、その際に依頼者にそれをやる理由や期待する効果を説明してもらうようにしました。このようにすると依頼者から「よくよく考えると、そんなに急ぎでない気がして来たから次のスプリントで良い」という声も出てくるようになりました。
実際に割り込みタスクをする場合でも、この会話があるために、仕様が明確になり、効率良くできたこともありました。

フワッとしたふりかえりには、次のような視点を意識してやってみました。

・Keep:たまたまできたわけでなく、これからも続けていけるだろうか?(継続性)
・Problem:その事象自体ではなく、実際にそれで困ったことを明確にできるだろうか?(対応する課題の特定)
・Try:(Pに対するTryは)それでProblemの本当の原因を解決だろうか?(課題の真因へのアプローチ)

結果:
割り込みが入っても、計画していたタスクも含めて無理なく対応できるようになりました。

この頃には、チームのコミュニケーションもずいぶん変化していて、朝会やタスクボードを中心とした半円がチームでできていて、私に向かってではなく、タスクボードやチーム全体に向かって話すようになっていました。それと共に、メンバー同士による会話の割合が増え、タスクの受け渡しや(ふりかえりを待たなくても)日々の改善をするようになっていました。

さらに大きな変化として、指示待ちの姿勢や「○○はどうしたらいいでしょう?」という質問も減っていき、自分達でこういう風にするという意思表示をして進めていっていました。
#私が「で、どうしたいですか?」と口にすることも減っていきました。

◆最後に

この時は私もスクラムマスターとしてチームと過ごしながら、試行錯誤し、観察し、考え、色々工夫しました。その中で、多くのことを学び、また別のチームと過ごす今、それを活かすことができています。

読んでいただいている皆さんのチーム、現場で同じことが起こっているのか分かりませんし、原因も対応も違うと思いますが、(一度には変わらなくても)このように一歩一歩工夫して、改善していくことで、より成熟したチームに変わっていくことができます。

今回のお話が、少しでも読んでいただいている方のヒントになれば幸いです。

******************************

いかがでしたでしょうか?

ギルドワークスでは、このように開発チームの現場改善(アジャイルコーチと呼ばれることもあります)も行っています。
開発チームをこれから作っていきたい、より強化していきたい方など興味を持たれた方は、ぜひお気軽に「ギルドワークスに依頼する」などをご覧になってお問い合わせいただければと思います。

※アイキャッチの写真:https://www.flickr.com/photos/dawnmanser/3532598208/

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中