こんにちは。プロダクトエンジニアリング部の渡邉です。
今回は先日私が所属するプロダクトエンジニアリング部にてオンラインで実施でき、チーム形成とエンジニアが楽しむことができるチームビルディングを開催しましたので、そちらの内容について紹介させていただきたいと思います。
チームビルディングとは
チームビルディングとは、組織を単なる「グループ（人の集まり）」で終わらせずに、成果を上げる『チーム』に組成するための一連の手法です。
新しいチームを組成する際には、チームのビジョンや戦略を共有し、所属メンバー一人一人がそれらを自分のものにしなければなりません。
LIFULLでは、期初に各グループに対してチームビルディング予算が割り当てられ、メンバーが自分達で考えたさまざまなチームビルディングが行われています。 そして今回は私たちプロダクトエンジニアリング部2ユニット(※以下ユニット)で行われたチームビルディングについて紹介します。
参加者の構成
LIFULL HOME'S事業本部では現在職種別組織の体制を取っており、私たちのユニットは全員がエンジニアで構成されています。
またユニットの中で3つのグループに分かれており、普段は異なるサービスを開発しています。 今回はその3つのグループが集まり、フロントエンド・バックエンド・マネジメント層など、あらゆる領域を専門とするエンジニアたちでチームビルディングを行いました。
目的
チームビルディングで達成したいゴール
今回チームビルディングを行うにあたって達成したい目的がありました。
それは隣のグループとのコミュニケーションの活性化です。
もともとエンジニアではありながら別サービスに対してコミットをしてきたグループが一つの集団となったこともあり、 お互いのことを知る機会が少ないことが課題でした。
チームビルディングのフレームワークであるタックマンモデルにおいて、チーム形成のプロセスには5段階あると言われています。 現在のユニットはその最初の段階の「形成期」にあてはまるので、お互いに意見をぶつけ合うことができる「混乱期」にステージを進めることをゴールとしました。
ビジョンを交えて実施したい
目的に記載した内容を元にチームビルディングを行うということだけであればみんなで一体感を感じることができるようなアクティビティであったり、 比較的心理的ハードルの低い内容を元に議論を行うといった方法でチームビルディングを行うことも可能ですが、 今回は『エンジニアらしさ』というものにフォーカスを当ててコンテンツを準備しました。
なぜエンジニアらしさにこだわったのか
一つは普段のチームビルディングが企画やデザイナーなどの職種を横断したものであることが多かったのに対し、今回の参加者はエンジニアのみでした。
もう一つはチームのビジョンによるものです。
私たちのチームは”プロダクトエンジニアリング部”という部署であり、プロダクト開発を行うエンジニア組織です。
その部署の達成したいビジョンは"強い個人・最高のチームになることで、価値創造を加速させ続ける"というものになります。
一人一人が強い個人を達成することで最高のチームが形成され価値創造は加速するということを意味しているのですが、 強い個人を達成する一つの指標に"技術力の向上"というものも含まれています。
ですので、今回のチームビルディングでは、ただチームの風通りをよくしたいというだけでなく強い個人の達成というものも意識して強化したいということも含めて『エンジニアらしさ』にこだわって実施することにしました。
どんな内容にしたのか
今回私たちが上述した目的を達成するために選んだ手法は自作のエンジニア謎解きを開催するというものでした。
どんな風に実施したのか
形式はGitHubにエンジニアらしい分野ごとのクイズを用意し、解答をスプレッドシート上で解答する方式を取りました。
クイズはチームビルディング運営メンバーで分担して考え、LIFULLらしさを活かした問題など、さまざまな問題を用意しました。
エンジニアなら答えられて当然！？な問題や
暗号を解読する問題
今回の問題のために準備されたデータベースから答えを導く、エンジニアの腕がなるような問題もあります。
中には、アルゴリズムを考えるような問題も！( PKU JudgeOnline『Expedition』 改題 )
という具合に、知らないと解けないような問題から頭を使って解く問題、専門性を活かした問題と非常に多岐に渡る領域から問題を作成しました。
問題を作成するにあたって工夫した点
エンジニアそれぞれで得意な領域が違うので、まったく手が付かないことがないように各領域で難易度を考えながら用意しました。
参加者に公開せずに各問題で難易度に応じて配点を設けて、「これは難しいから配点が高いのではないか」「まずは簡単そうなやつから解いて着実に稼ごう」などゲーム性を持たせて少しでも参加者のみんなが楽しめるように運営メンバーで考えました。
当日の様子
実際に解き始めると各チーム取り組み方が違いました。全問題を一つずつみんなで解答していてくチームもあれば、得意分野ごとに各自別れて解答していくチームもありました。
実際に問題に取り組んでいる時の様子です。基本的にzoomで画面共有しながら解いていました。
みんなで解いているチームは会話量も多かったですが、各自で分かれて解いていたチームは会話量も少なくなりがちでした。
このようなクイズでも、ちゃんと最初に作戦を練るチームがやはり強かったです。見積もることはどんな場面でも大事ですね。
振り返り
チームビルディング終了後に参加者へのアンケートを実施したところ、以下のようなコメントが集まりました。
「問題の難易度がバラけていたのでとっつきやすさ/やりがいの両面がありつつ、戦略も考えられる内容だったので良かったです」
「エンジニア歴の浅い私でも解けるようなスプレッドシートやGitの問題など、幅広い問題が考えられていて楽しかったです！」
これらをもとに運営メンバーで振り返ったところ、良かったところと改善できるところが見えてきました。
良かったところ
オンラインならではのコンテンツ
オンラインでの実施にあたって、全身を使うアクティビティや共通の道具を使ったゲームなどは難しく、 今までのチームビルディングとは違ったやり方を試みる必要がありました。
オンラインでのチームビルディングを成功させるには、ビデオコミュニケーションのために全員の手元にあるPCを十分に活用する必要がありますが、ITエンジニアにPCを持たせたらまさに水を得た魚・鬼に金棒・虎に翼です。
GitHubなどの普段から用いているサービスや、それぞれが得意とする技術を使用することで、スムーズな実施ができました。
置いてけぼりがいない、全員が楽しめる設計
エンジニアとしての基礎知識から、フロントエンジニアが活躍できる問題、論理的思考力で勝負できる問題、ひらめきが重要になる問題、データベース等の知識が問われる問題など専門性の高い問題まで幅広く問題を用意しました。
その結果、問題の取り組みやすさとやりがいが両立され、最後まで全員が楽しめました。
今まで業務で関わらなかったチームメンバーのかっこいい一面を見ることができ、お互いの強みの理解へとつながっているようです。
改善できるところ
運営メンバーと参加者とのコミュニケーション不足
運営メンバーは作問をした立場ですので、必然的に謎解きへの参加はできなくなります。
そのため、今回のチームビルディングを通して運営メンバーと参加者のコミュニケーションはあまり十分ではなかったように感じられました。
事前に
- 何回か、チームの出した答えが正しいかを聞ける
- 何回か、他チームの解答状況を確認できる
といったような、『クイズ$ミリオネア』の"ライフライン"さながらのルールをうまく作っておくことで、運営メンバーと参加者のコミュニケーションも活性化したかもしれません。
企画者が参加者と同じ立場でゲームに参加できないというケースはよくありますが、どうやってコミュニケーションロスをカバーするかを事前に考えておく必要があると感じました。
チームによるコミュニケーションの差
普段の業務にも通じる部分ですが、チームでたくさんの問題を解くという性質上、チーム内で各々の強みを把握することで有利に進めることができます。
競技として戦略の組み立てがうまいチームが勝つことは望ましいのですが、お互い初対面の場合もあるチームビルディングで戦略的なコミュニケーションをとることが容易でないことは明らかです。
そこで、
お互いがどんなスキルを持っているか
どのような方針で問題に取り組むか
どのように報告しあうか
といった観点を事前に提示したうえで、作戦会議をする時間を設けることで、より円滑なコミュニケーションができたかもしれません。
チームビルディングに限らず言えることですが、明確な話題や流れの設定があると、即席のチームでも短い時間に密度の高いコミュニケーションをできると考えられます。
まとめ
エンジニアとしての矜持のもとに個々の持つ強みを発揮し、協力して壁を打ち破るという今回のエンジニア謎解き。
「コードで語れ 頭を使って 謎を解け」と言えるような今回のチームビルディングでは、チームで協力して謎に挑戦することで、お互いの理解と技術的な気付きを得ることができました。
風通しの良さとエンジニアとしての能力を高めてもらうためのいいコンテンツとなったと思います。
完全オンラインでのチームビルディングの一例として、参考になれば幸いです。
