picjumbo.com_HNCK8997_800

こんにちは、nawotoです。
今回はプロダクト開発におけるチームビルディングについてお話したいと思います。

アジャイルだけじゃない?

僕はふだんプロダクト開発におけるチームを支える仕事をしていますが、チームビルディングでは自分のバックボーンであるアジャイル開発の考え方やテクニックを使うことが多いです。
しかし、アジャイル開発が誕生した10年以上前と今では状況は変わってきています。各種ツールは大きく進歩して、メンバーひとりひとりができることが増えたため、少数精鋭のチームを組むことが主流になったり、サーバーサイドエンジニア、フロントエンジニア、UXデザイナーといった専門性の強い新しい職種が生まれたりしています。
また、チームビルディングのやり方には様々なものがあり、新しいやり方もどんどん生まれてきています。そのため、僕自身もあまりこれまでの手法にはこだわらずに考えるようにしています。
そこで、いま、チームビルディングを考える上で必要なことは何なのかを、少し抽象的ですが僕の経験から4つのTipsにまとめてみました。

いま、チームビルディングに必要な4つのTips

1:最初からメンテナンスする

個人的な考えとしては、3人以上で仕事をする時は何かしらメンバーに働きかけ、チームとしてまとめていく活動が必要だと思っています。もちろん、人数が増えれば増えるほど全員とコミュニケーションをとることも困難になっていきます。
また、3~6人くらいのチームの場合でも、毎日全員と会話できるので、すぐにチームとしての大きな課題が出にくくはあるのですが、気がつくと負債のような顕著にはなっていない小さな課題が溜っていき、徐々に顕在化していきます。
気がつくと課題は大きな問題となって、結果として大きな失敗や無駄も増えていきます。

そうしたことの原因のひとつに、チームメンバーのひとりひとりが「アラートをいつどこに挙げたらいいのか?」「この開発に実は不安があって。。。」などの迷いや疑問を口にする機会が少ない場合があります。
これを回避するために、「小さな疑問や悩みをひたすら出す場を作る」といったアプローチがあります。個人的には、このようにチームとしてまとまりを生むきっかけをワークショップという共同作業を通じてチームを作り上げていくのが好きです。
もちろん、ワークショップを単発で開催するだけでは上手くいかないので、チーム立ち上げの初期はワークショップを密に行ない、その後は定期的に開催するようにしています。ワークショップと言っても大層なことをやるわけではなく、チームのいいところベスト3を探したり、チームで挑戦したいみたいことを整理・見直したり、といった些細なことでも良くて、続けることに主眼を置いています。
たとえば、あまりチームの課題にフォーカスすると続けていくのが辛くなってしまうので、なるべく「今週はがんばったよね。次はもっとうまくやろうぜ!」みたいに、前向きな方向にフォーカスするようしています。

"チームビルディング"という言葉が進行形で書かれているように、やはり継続的にメンテナンスしていくことが上手くいく秘訣のような気がしています。

2:チームの意見を見つける

チームメンバーが話しやすい状況を作り、チームとしての意見をみんなで出すというのを意識的にやっています。特にチームができたての頃は、チーム全員が集まる場で意見を出し合おうとしてもほぼ出てこないので、あの手この手を尽くします。
例えば、順番に意見を聞いたり、発言するのが苦手なメンバーが多いチームの場合は付箋などに書いてもらったり、ということもあります。言葉を選びながら書く人もいるので、そんな時は、30枚分など、とにかく大量に書いてもらうと、最後の方に本音がひとつくらい出てきたり。
あとは、チーム内でペアを組んで意見を3つくらい挙げてもらうなど、ひとつの「ひと/もの」に焦点が当たらないようにすることもあります。そうすると、個人の意見になりにくいので、意見が偏りにくくなります。こういう感じで、チームとしての意見を見つけるようにしています。

3:ひとりひとりにあわせる

もうひとつ意識しているのは、チームのことを考えつつも、実際はひとりひとりのメンバーを見ながら、それぞれアプローチを変えるようにしています。なにかアクションを考える時に、一度立ち止まって考えた方がチーム全体のことに気づく人もいるし、各メンバーのことをよく分からないうちは、ツッコんで意見を言えない人もいますし。それぞれの個性に応じて考えるようにしています。

例えば、幼稚園の先生はチーム作りがとてもうまいですよね。クラスというチームがあるとして、お絵描きの時間であれば、まずはみんなが絵を描き終えるというゴール設定をする。絵を描きたくない子やさっさと描き終えて外に遊びに行きたい子、ゆっくり考えながら描く子など、いろいろな園児がいる中で、まずは絵に関心を引き寄せて、ひとりひとりの状況に合わせて指導する。
そのように、ひとりひとりの特性に合わせて考えていかないとチームでゴールを達成するは難しいのかなと思います。

4:イメージする

最後に「このメンバーだったら、こういうチームになったらおもしろそう!」など、チームの将来の姿をイメージすることも大切です。チームビルディングをリードする役割は、チームスポーツの監督みたいなものだと思うのです。ひとりひとりではなかなかゴールを達成できないものを、人に合わせた練習メニューを考えたり、モチベーションを上げたりすることでチームとして目標を達成していく。
しかし、勝敗などスポーツのようにわかりやすいゴール設定がするのが難しいので、ここ数年はその辺りに興味を持ってやっています。良いチームをイメージする時は、過去にコンサルタントや受託開発をしながら様々なチームを見てきたので、その経験から良かったものを組み合わせて、チーム毎にカスタマイズするようにしています。
ただ、イメージをわかりやすい目標に落としこんだり、人に伝えたりすることについては、まだまだクリアできていないという感じはします。

チームビルディングの今後

チームビルディングは、これからもっとやり方が変わっていくと思っています。その際、昔の手法にとらわれず、疑ってみることもおもしろいのではないでしょうか。まだまだ僕も手探りですが、アイデアとしては、開発合宿や、海外で紹介されているMob Programmingのような、職種も関係なくみんなで無理矢理ひとつの作業をすることは、重要だと感じます。職種の壁って、年々難しくなっている気がしているので。
それから、チームが歩んできた過去から学んでいくことも大事なのですが、完全に未来指向の活動だけでチームビルディングをしてみたいとも思っています。ふりかえりではなく、常に未来をイメージするみたいな。「今はこれができていないから次のアクションを」と考えるのではなく、「一週間後にはチームはこうなっていたい」「数ヶ月後はどうなっていそうか」など、チームとプロダクトの未来像を先に設定して、そこからアクションを考えていくという進め方です。
僕の周りは、マジメでいつも難しい顔して「課題が、課題が」と言っている人が多いので(笑)、いつか、そこで実践した活動やワークショップも紹介できたらと思います。