チーム開発を飛躍させるノウハウや組織づくり | dots. CONFERENCE SPRING 2016

チーム開発のノウハウを3人のプロフェッショナルが解説

渋谷にある『イベント＆コミュニティスペースdots.』にて、2016年2月24日～3月1日にデザイン・Web・ビジネスモデル・開発技術など多分野におけるエキスパート達が集まるセミナーイベントが開かれました。

その中で、企業における開発を担うチーム、そのチームをよりよく改善し開発を支える技術について、3人のプロフェッショナルが、ノウハウや想いをセミナーを通して教えてくれました。

自ら開発したプロダクトとチーム、2人3脚での成長を目指す

Increaments株式会社 は『Qiita:Team（キータ チーム）』という、開発チームのための情報共有サービスを提供しています。社内の技術情報を活性化し、企業やチーム力向上に繋げることができるのが特徴。

『Qiita:Team』を開発する中で、ユーザーが抱えるチーム作りの問題を吸い上げ、自らの会社でのチーム作りに実践。『Qiita:Team』サービスへフィードバックする取り組みの中で、Increaments のチーム体制を変えていったそうです。その試行錯誤のプロセスから学んだノウハウを、Increaments株式会社 の東峰さんが話してくれました。

東峰：Qiita:Teamを導入していただく際のよくある課題として、「ツールを導入したけどメンバーが全然書いてくれない」「使いたいって思っているんだけど全然上司が理解してくれない」ということがあります。Qiita:Teamの良さを伝えたくても、なかなか言語化して価値を共有するのが難しい。

結局、Qiita:Teamの導入をしてくださる人がやりたいことは「チームを変えていく事」なんですよね。もっといいコミュニケーションが取れるチームにしたいとか理想は様々と思いますが、良く変えていきたいという思いが強い。

でもそうするには自分だけじゃなくて、周りのメンバーや上司とか、組織の中のちょっとずつ立場や考え方の違う人たち同士が深いコミュニケーションをとっていかなければいけないんですね。だからどうしても状況は複雑になるし、そもそも正解がないことなので、すごく難しい。

僕らもその課題に対して、どのようにすれば良いチームが作れるのか、Qiita:Team を上手く使ってもらえるのかをすごく考えてきました。で、出た結論は当たり前のことで……。まずは、僕ら自身がいいチームを作ることだなと。

よいチームを作るための努力を、開発とは別の軸で試行錯誤する。その中で分かった知見を製品にフィードバックしていければと考えました。

東峰：僕たち自身も会社の人数が増えるにつれて様々な課題に直面していて、そのためのアクションも試行錯誤のひとつです。例えば社長と社員との月一回の1on1を通したチームビルディングとか、PM経験の豊富なメンバーを採用してその経験を取り込んでいったりとか。

最近では『チームが機能するとはどういうことか』という本の輪読会をやっています。全員が「チーム」というレイヤーで議論する機会ってなかなか持ちづらいので、本を中心にメンバー同士の意見を交換する機会として企画したものです。

この本は『学習する組織』というものの必要性やその方法論が書かれたもので、「意見の相違を乗り越えること」とか「解決策が生まれるまで議論できるような関係性」とか「安心して率直に意見を述べられるような環境」とか、そういったことができるチームを生むにはどういう考えが必要か、といった話が載っています。

そのあたりがまさに僕らやユーザーさんが抱えるチームの問題をうまく説明してくれていると感じていて、自分たちのサービスを理解する上でも大きな示唆を与えてくれました。

こんな風に、最初は3人から始まった会社ですが人数が増えていく毎にやっぱり色々な課題が出てきて、その度にコミュニケーションを取りながら状況を共有して解決策を考えて……。

難しいけれど諦めずに試行錯誤してきたことが、プロダクトの開発に際しても不可能にチャレンジしていくという文化を作っているんじゃないか、と考えています。

クラウドソーシングにおける不特定多数とのチーム作り

株式会社Startup Technology の菊本さんはクラウドソーシングを利用して不特定多数のエンジニアに仕事を外注するのが、コストの面から考えても使いやすさから考えてもメリットが大きいと話します。

ただし、そこにはクラウドソーシング独自のチームの作り方が求められるそうです。菊本さんがこれまで行なってきた、クラウドソーシングのノウハウを私たちに伝えてくれました。

菊本：よりよいクラウドソーシングのチームを作る方法についてですが、そもそも通常の外注とか受託っていうものと同じようには考えない方がいいです。本当に「チームを育てる」っていう感覚ですね、その感覚があれば、クラウドソーシングで良いチームができあがっていきます。

まず発注する時なんですけれど、受注する側に立って考えてみて下さい。内容が見えにくかったり、ボリュームが大きすぎる、どう考えても安い、納期だけ決まっているみたいな募集ってありますよね。

これは、完全に地雷案件です（笑）。絶対に受けたくないですよね。その点から逆に考えると、どうすれば人を集めることができるのかが見えてくると思うんです。

やることを明確に設定してあげる。納品の義務を負わせない。時給制にする……。だいたい、時給単価が1,500円～2,000円くらいにするとやってくれる人が増えてきます。

なるべく時間のコミットメントを減らしてあげてください。副業として月数万円くらいを稼ぎたいなぁ、っていう主婦や学生さんを取るようにします。受注側の負担を極力減らしてあげる事で応募の間口を広げてあげます。そうするといっぱい人が集まってきます。

続いて、採用についてご説明します。通常、応募後、スクリーニングしてから仕事を振るわけですが、クラウドソ－シングでは先に仕事を振ってしまって、その仕事を見ながら「この人はどうかな？」ってスクリーニングをする事ができます。本当にいい人だけを残していくといった仕組みです。

次に運用の方法についてご説明します。まず、PM（プロジェクトマネージャー）がタスクをバッーと登録して、そこから好きな仕事を取ってください、という形をとります。

そして、時給で計ってpull requestを投げて下さい、と伝える。最後にこっちでレビューとマージをする。この流れの中で、エンジニアをスクリーニングしていきます。

コミュニケーションの方法ですが……まずは、全員をチャットに登録しましょう。同一チャット上に登録することで、そこに技術ヒエラルキーが生まれます。

その中で、この人に聞けば大丈夫とか、この人なら教えてくれるという、いわゆるコミュニティが生まれてきます。頼るほうも頼られるほうも、お互い気持ちよく仕事が進んでいくでしょう。

あとコーディング契約。ルールをどのようにしていくのか、しっかりと見える化していきましょう。プロジェクトの背景も、ドキュメンテーションしてあげるとキャッチアップしやすいです。なるべく人が入ってきやすいようにしてあげる。その上でスクリーニングをしていきます。

クラウドソーシング上でのタスクの作り方ですが、初期段階では、クラウドソーシングのエンジニアって、責任とか稼働時間、仕様理解度、スキルが見えづらい。この状態で問題なくエンジニアに依頼することができる、タスクの作り方を考えていかなければなりません。

まずは、なるべく簡単な技術に寄せてあげましょう。タスクを小さく分けて、1つが失敗してもリカバリーが利きやすくします。そして、業務が進んでいってメンバーが慣れ、こちらも誰がどのくらい仕事ができるのか分かってくるようになると、「これ、お願いします～！」というコミュニケーションで依頼することができます。

徐々に、コストがかからない形にシフトさせていきましょう！こんなふうに開発コミュニティをを作る感覚で、どんどん成長させていくといいチームができるんじゃないかと思います。ということで、みなさん、楽しいチーム開発を行なって下さい。

小さなトライを何度も続けることが強いチーム作りにつながる

もはや楽天株式会社の名を知らない人は珍しいのではないでしょうか。様々な人、国籍も違う人たちが集まる楽天で小さな努力を何度も何度も積み重ねて、揺るぎない強いチーム作りに努めてきた及部さんから、そのプロセスやコツを教えてもらいました。

及部：そもそもチームって何だ？ って考えたときに、ただ人が集まっただけの烏合の衆だとチームではないと考えています。ちゃんと共通の目的ができている事が前提で、初めてチームと呼ばれる、と。

その中で強いチームと呼ばれるものの共通点って何かな、って考えてみると、6人が集まったらその力がコラボレーションされて6人以上の力になっていることとか、変化に強いとか、ちゃんと文化が存在していて継続的であるとかいうようなものがあると思います。

じゃあ実際に強いチームを作っていくリファクタリングをどうやって進めていくかっていうところですが……。強いチームは、『意識して作っていかないと出来ない』です。たまたま集まったメンバーがたまたま強いチームだった、っていうことはまずないです。

じゃあ、集まったメンバーで作られたチームを強くするプロセスを考えると、『チームの今をまず知ること』これが最初ですね。今、自分達はどういう問題を抱えていてどれくらいのレベルにいるのか、なるべく具体的な数値で見せてあげて、最終的にどこに向かっていくのか、共通の目的を作ってあげます。

でも、いきなりそこに行けるわけではないので、じゃあ、直近、どこまで行こうかっていう次の目標を設定して、実施して振り返ってみて、って言うのを繰り返して強いチームに近づけていくっていうアプローチが基本的な進め方です。

ただし、例えば今現在、問題を抱えて混乱しているチームに新しい事を提案しても、更に混乱するだけなので、最初の「今を知る」の次に、今困っている問題を助けてあげて、これを続ければ自分達が楽になっていくんだなっていう感覚を覚えて、成功を癖にする、成功が嬉しくなる事を習慣化して繰り返していくことが1つのコツかなと思っています。

僕がチームに入ったら真っ先にメンバーと1 on 1でカフェでお茶します。「なんか困っている事ある？」って聞くと相手が萎縮しちゃうので「こうなったらいいなあ、って思ってることある？」という聞き方をすると意外とたくさん話してくれたりするので、これをずっと繰り返しています。

チームの抱えている問題って大体、みんな気づいているんですよね。気づいているけど解決できてない事が、こうして1 on 1で話していると見えてきて面白い。後は話していくと「ああ、この人キーパーソンだな」って人が見つかったりして、チームの状態が自分の中で掴めるっていう、いいこともあります。

それから大事にしているのが「振り返り」ですね。さっき話したプロセスの中で1つ取り組んだら、どこかで振り返りの機会を作って皆に「このまま継続しますか？」って聞いて続けるかどうかを決めてもらうんですね。こういう振り返りを定期的に行なう、これをやるだけで一人一人が話す機会ができるので少しずつオーナーシップが生まれます。

他にもチームでトライしたいことや、解決したい問題を付箋に書き出して張り出してもらって、みんなで投票してもらって、ロードマップを作って年間計画にしちゃいます。これでチーム全体の目標が見える化して、実現に向けて技術や資格を先回りして取るとか個人的な目標にも繋げていきます。

それからスキルマップです。誰がどの技術を持っているかを見える化する、定期的に更新する、今のチームに必要なスキルを入れたり、異動の時にどんな技術がなくなるのか、といった判断材料になります。

こういったトライと振り返りを小さくてもいいので繰り返し続けていく事、これを1年2年と続けていくと細かいトライを100回以上でも繰り返す事になるんですけど、これだけやれば嫌でも良くなっていくじゃないですか。こんなふうに小さなトライを積み重ねてで強いチームを育てる事を意識しています。

（おわり）