「チームが変わった」経験を広げるため、クラウドワークスへ

私は1年ほど前にクラウドワークスに入社しました。当時はまだエンジニアが10名程度の組織でしたが、今では30名程にまで増えています。現在は主に、チーム作りやマネジメントを担当しています。

前職は、NEC系の開発会社で働いていました。100名ほどのチームにいたのですが、そこで最後の4年ほどは、アジャイルやスクラムに取り組んでいました。

まずは4、5人の小さなチームにスクラムを導入し、それを徐々に拡大して開発チーム全体に広げていきました。すると、徐々に組織の雰囲気が変わっていき、チームだけでなく個人も成長していく様を目の当たりにしたんです。

大企業になると、業務に閉塞感を感じている人も多いと思うんですよね。そういう人たちが、明らかに変わっていくのが分かったんです。

今まであまり喋らなかった人が発言をするようになったり、成長意欲が出てきたり、外に発信を始めたり…。その時の体験を、また別の場所でも再現できないかと思い、クラウドワークスに転職しました。

組織が拡大すると、「コミュニケーションの設計」が重要に

僕が入社した当時、エンジニアはインフラ寄りの人とそれ以外、という風に役割が曖昧で、チームと呼べる状態ではありませんでした。

それでも人が少ないうちはコミュニケーションも取れるし、上司と1対1で話す機会も多いので、何も考えずに動いても問題が起こらないんですよね。

それが人が増えていくに従って、どんどん見えなくなってくる。どういう仕事があるのか、隣の人が何をやっているのか分からなくって、コミュニケーションが希薄になっていく。そうすると中途入社で入ってきた人も、自分がチームの中で何をしたらいいのか分からなくなってしまいます。

チームがある程度の規模になると、横のつながりをどう作っていくか、コミュニケーションを設計してあげる必要があるんです。そこで思い切って、ひとつだったチームを5人1組ほどの小さなチームに分割しました。

その小さなチーム内でコミュニケーションを取り、できるだけトップダウンでない目標をもたせ、チームで考えていくように進めました。そしてその仕組みは、アジャイルやスクラムの考え方をベースに作りました。

「スクラムをやろう」はアンチパターン！？

そんな当時のクラウドワークスに入った瞬間に、「スクラムが活かせる！」と感じました。

スクラムを取り入れると朝会、プランニング、そしてふりかえりと、決められたことを実施するだけで、会話が生まれてくるんですよね。そこでコミュニケーション量が増えて、結果としてチームが同じ目標に向かうようになり、メンバーも自分がどう動けばいいのかが分かっていきます。

ただ、よくやってしまうアンチパターンが「スクラムをやろう」と言ってしまうことなんですよね。「スクラムを取り入れること」がゴールになってしまうと、チームやコミュニケーションの改善という、本来の目的を見失ってしまいます。

大企業やSIerでスクラムに取り組んで失敗するのは、結局はスクラムを本質的には理解せず、形だけを取り入れてしまうからだと思います。チームで共通のゴールに向かうためにはどうしたら良いのか、というところから、進め方をしっかりと考える必要があるんですよ。

そこで今回は、スクラムという言葉もわざと使わないようにして「チーム化していこう」という言い方をしていました。まずは、やりやすいように「朝会、プランニング、ふりかえりの3つだけはやってください」とお願いした上で、私がチームを見ながら、その意図を伝えていくようにしました。

意見を出しやすい仕組みを作り、成功体験を積み上げていく

朝会やふりかえり、プランニングなどは、基本的に全員でミーティングを行います。その時にあまり喋らない人がいる場合は、ふせんを使うといいですよ。

例えば、ふりかえりをする時に、5分時間を取って各自でふせんに書き込んでいく。それを1人ひとりが出していくことで、誰でも話すようになるんですよ。

タスクの見える化も重要ですが、知的労働である以上、考えていることの見える化が大事なんです。それぞれが考えている事を、どこまで出していけるかが重要ですね。

弊社では、「課題があるなら率直に言う」ということをルールにしています。難しいことですが、それができるとお互いに刺激になったりと相乗効果が生まれてきます。

それを実現するためには、成功体験が重要です。例えば、自分が出した改善案にチームの人が頷いてくれて、その案を実施し、そして実際に改善されると、それが自分の存在意義になっていきますし、チームのテンションも上がっていく。そのサイクルの繰り返しが大切だと思います。

チームの目的を一致させるため、コミュニケーションは必須

また大切なのは、チームを作るときに、なぜ自分たちはここにいるのか、目的は何なのかを最初に話し合うことだと思います。そこで目的を一致させておくと、チームはどんどん良い方向に変わっていきます。要するに、コミュニケーションは不可欠なんです。

フラットな組織でも、隣の人が何やっているか分からないと話しかけにくいですよね。そうするとアクションが遅れてしまったり、もっと出来るはずなのに辞めてしまったり、といったことが起きます。

それを防ぐためにも、朝会で全員一度は話す機会を与えて、意識的にコミュニケーションを増やしていくことが凄く大切だと思います。すると結果的に、中途で入社した人も、あまり不安も無くチームに入ってもらえるようになります。

まだ「チーム化」を導入して1年ほどでチームの配置換えは少ないですが、今後はメンバーを入れ替えていこうとも考えています。

ただ、一方でスクラムの考え方、継続的なノウハウや暗黙知は、同じチームで続けたほうが貯まっていきます。これが3ヶ月ごとにチームが変わるとなると失われてしまうので、半年から1年くらいでチームを変えていけると良いかなと思っていますね。

エンジニア自身がユーザーの笑顔にコミットできる組織を

エンジニアは技術力を上げるだけではなく、サービスやマネジメントに関わっていくことも必要だと思っています。考える人と作る人、役割としては分かれるのですが、経験として完全に分かれてしまうとお互いにかみ合わなくなってしまいます。

ですから、「考える人」にはエンジニアリングに興味を持って欲しいですし、逆にエンジニアもサービスに興味を持つことも必要だと思います。

そうして色々な経験を重ね合わせる量が多くなっていくと、組織としても成長できますし、エンジニア自身がユーザーの笑顔にコミットできるような状態になってくると考えていますね。（了）