とあるチームのチームビルディング話

この記事はクラウドワークス Advent Calendar 2019 の 17 日目の記事です。昨日はアクセシビリティ向上隊長みーたさんによる「なんとなくで書かないで！HTML5 を書く時に気にしてみたいタグごとのお約束」でした。自分は懺悔室送りとなりましたが、皆様いかがでしたでしょうか。

はじめに

記事をご覧の皆様こんにちは。クラウドワークスでスクラムマスターをしている @zakky_dev です。普段は gatekeeper というチームで、周囲の認定スクラムマスターに怯えつつ、スクラムマスターロールを担当しています。*1

この記事では、立ち上げから関わっている gatekeeper において、組織の成功循環モデルを意識しつつ、チームビルディングをしてみた話をします。*2

背景

チームビルディングの話の前に、自分が関わっている gatekeeper の背景を説明します。

このチームは 2019/11 に発足したばかりのチームです。構成人数は 4 人、PO 1 人、SM 1 人、開発チーム 2 人と小規模なチームです。チーム発足当初は、メンバー間の面識はほぼありませんでした。*3

gatekeeper では、開発プロセスにスクラムを採用しています。*4 ただし、諸般の事情により、スクラムガイドから逸脱した部分もあります。特にレビューに関しては大きく外れており、ステークホルダーを呼ばず、チームメンバー全員がレビュアーとなり、成果物をレビューする体制を取っています。*5

チームのミッションはセキュリティ対応関係です。*6 チーム発足当初は、2020/03 末を目標に、とあるセキュリティ対応を実施する予定でした。はい、予定でした。そのセキュリティ対応はすでにリリース済みです。イェイ。

チームビルディングの仮説

先述の通り、gatekeeper はセキュリティ対応のためのチームです。セキュリティリスクを考慮した場合、2020/03 末の納期は守らなければならないものでした。よって、チームには下記 2 つの特徴が求められます。

生産性が高いチームであること。
リスクを早期に発見し、適切に対処可能なチームであること。

gatekeeper 発足当初、先述の背景と、上記 2 つの要求を整理した上で、1 つの仮説を立てました。

仮説「組織の成功循環モデルの通り、まずは関係の質を高めることで、成果が上がるのではないか？」

組織の成功循環モデル

「組織の成功循環モデル」とは、MIT のダニエル・キム教授によって提唱されたモデルです。組織が成功する上で、基本となる考え方とされています。

このモデルは下記 2 つにまとめられます。*7

結果を良くしたい場合、まずは関係性の構築から始めなければならない。
最初から結果を求めてしまうと、関係性の悪化を招き、最終的に結果が悪くなっていく。

上記 2 つを図化したものが下図です。

f:id:zakky_dev:20191217183756p:plain

関係の質を高める活動

チーム発足初期、まず関係の質を高める活動として、下記を実施しました。*8

ドラッカー風エクササイズ
Working Agreement

それぞれの意図について説明します。

ドラッカー風エクササイズ

ドラッカー風エクササイズは、「アジャイルサムライ」などで紹介されているチームビルディング手法です。表明を促す 4 つの質問に答え合うことで、メンバー間の相互理解を促進する狙いで実施しました。

先述の通り、gatekeeper のメンバーは、チーム発足以前はほぼ面識がありませんでした。そこで、お互いの価値観を知り合うために、ドラッカー風エクササイズを実施しました。また、後述する Working Agreement 作成のために、メンバーの価値観を共有しておく狙いもありました。

Working Agreement

Working Agreement は、チーム内での約束、ルールを指します。明示的なルールを作ることで、合意されていない期待をお互いに持つことを避ける狙いがあります。

gatekeeper の場合、「自分たちはどのようなチームになりたいのか」を出発点として、最初のルールを作りました。*9 明示的に理想的なチームを話し合っておき、そこを目指すことを合意しておくことで、ルールに対する納得感を高める狙いもありました。

結果

関係の質を高める活動として 2 つを紹介しました。この活動の結果として、メンバーに心理的安全性テストを受けてもらったため、その結果を掲載します。*10

各設問 1~7 点での評価です。なお、質問には肯定形、否定形が混在していますが、全てポジティブな結果が高得点になるようにテストを作りました。

質問	平均点
もしあなたがこのチームでミスをしたら、批難されることが多い	7
このチームのメンバー達は、困難な課題も提起することができる	6.5
このチームの人たちは、異質なモノを排除する時がある	6.5
このチームなら、安心してリスクを取ることができる	5.75
このチームのメンバーに対して、助けは求めにくい	6.5
このチームには私の成果をわざと無下にするような仕事する人は誰もいない	6.75
このチームのメンバーと仕事をする中で、私個人のスキルと才能は、尊重され役に立っている	6.5
全体	6.5

以上の結果から、ある程度の成果は出たと考えています。

思考の質、行動の質の現状

次に、チームの思考の質と行動の質の現状です。わかりやすく観測できる一例として、レビューとふりかえり時のチームメンバーの行動の一部を紹介します。

レビュー

チームメンバーはロール問わず、成果物に容赦なくツッコミを入れる。*11
見落としていた高リスクな問題に気付き、即共有する。
チームのスコープ外のことであっても、ユーザー不利益になりそうな箇所を指摘し、対応しようと判断する。
指摘の結果、仕事が増えても受け入れる。

ふりかえり

問題解決だけでなく、より良い方法を探求する実験が提案される。
Trello のレーンがほぼ毎週変わる。
実施できなかった Try も、できなかった理由を考え、実施できるようにやり方を変える。

結果

レビュー、ふりかえり時の行動という観点から、思考の質、行動の質の向上が見えたように思える行動を紹介しました。これらの行動から、問題に真正面から取り組めるチームになった、と言えると考えています。

チームの成果

最後に結果の質の話です。関係、思考、行動の質と同じように、結果の質についても、チームの成果についての事実を紹介します。

内容	事実
リリースまでの期間	想定 5 ヶ月 → 1.5 ヶ月
本番環境で発生したバグ件数	0 件
11 月の残業時間	合計 9.5 時間*12

以上の結果となりました。*13

トレードオフ

gatekeeper では、関係の質を高めることを最優先としました。それに伴い、意識的に後回しにすることを選んだこともあります。

具体的には、先述したレビューのやり方に代表される、スクラムガイド通りのスクラムを目指すことです。 gatekeeper がスクラムガイド通りのスクラムを実現するにあたり、対処が必要になる障害が数多くありました。*14 障害への対処と、関係の質の向上。どちらを優先するかを考えた結果、今回は関係の質の向上を選びました。

終わりに

当初の仮説である「関係の質を高めることで、成果が上がるのではないか？」について、実際に行った活動と、それに伴うチームの状況について紹介しました。これからチームビルディングしようと考えている方の参考になったら幸いです。

明日は @eighty8 さんの「チームにプロダクトオーナーが加わり変化したこと」です。お楽しみに。

参考資料

本記事は下記資料に支えられて書かれています。本記事の間違いを含め、全ての文責は @zakky_dev にあります。

脚注

*1:クラウドワークスには認定スクラムマスターを持っている人が多数在籍しています。

*2:なお、この記事にスクラムの話はほとんどありません。

*3:加えて、開発チームの一人は、中途入社直後にこのチームに所属しました。

*4:クラウドワークスは開発プロセスにスクラムを採用しているため、このチーム特有というわけではありません。

*5:働けスクラムマスター。

*6:チーム名の「gatekeeper」という名前は、セキュリティ対応を行う上で「ユーザーの情報を守るぞ」という意思表明として決めました。

*7:詳細な解説は「参考資料」にある記事をご参照ください。

*8:他にも試してみましたが、印象に残っているのはこの 2 つです。

*9:決める際には次の 3 つの質問をしました。「どのようなチームになりたい？」「そのチームはどのような姿勢で働いている？」「その姿勢は具体的にはどういった行動に表れる？」

*10:因果関係があるかは不明です。

*11:盛り上がりすぎた結果、1 時間の予定が 2 時間になったこともあります。

*12:ちなみに、クラウドワークス全体の 11 月の平均残業時間は 12.23 時間でした。

*13:ただし、このチームのメンバーが優秀であることと、当初想定よりも規模が小さかった、という事実があるため、必ずしも関係の質を高めた結果、というわけではありません。

*14:例えば、社外のステークホルダーと毎週会うことは難しい、という状況です。

クラウドワークスエンジニアブログ

日本最大級のクラウドソーシング「クラウドワークス」の開発の裏側をお届けするエンジニアブログ

目次