【チームビルディング】エンジニアチームで爆弾解除ゲームやってみた！

※このストーリーは、noteで発信した記事を転載しています。

はじめまして！
ourly株式会社でフロントエンドエンジニアとして働いている山岸と申します。

この記事ではエンジニアチームで行ったチームビルディングの紹介と、そこから学んだことやourlyの開発チームの文化について書いていきたいと思います。

ourlyバトンリレー2024の記事です。

前回は弊社が誇るテックリードの玉田が、ourlyで働く理由を書いてくれました。

次回は新卒バックエンドエンジニアの土橋が書いてくれます〜！

目次

1. 1. 爆弾解除ゲーム Keep Talking and Nobody Explodesとは
2. 2. 目的と選定理由
3. 3. ワークの流れ
4. 3-1. 事前共有
5. 3-2. 準備
6. 4. ワークの結果と気づき
7. 4-1. 作業目的の明確化
8. 4-2. 問題自体にギャップがあるときは定期的に振り返る
9. 4-3. 事実を確認する
10. 5. こんなチームにこのゲームをおすすめしたい
11. 少し安定してきたチーム
12. 6. 最後に

1. 爆弾解除ゲーム Keep Talking and Nobody Explodesとは

・「爆弾処理班」と「解除指示班」
このゲームは2つの役に分かれて爆弾解除を行う。
爆弾処理班は、ゲーム画面内の爆弾を見て操作できるが、その解除方法が書かれたマニュアルを読むことはできない。

解除指示班は、ゲーム内の爆弾を見ることはできないが、すべての爆弾解除の方法が書かれたマニュアルを読める。

お互いを繋ぐ「会話」こそが、爆弾解除の唯一の手段なのだ！

出典：完全爆弾解除マニュアル - 特徴

要は、爆弾を処理する側は爆弾側しか見れないし、解除を指示する側はマニュアルしか見れないということですね。

2. 目的と選定理由

このゲームのポイントは「情報の非対称性」にあります。

私達が業務を遂行する上で、情報は常に非対称です。

例えば、マネージャー/メンバー、BE/FE、開発/POさん、開発/セールス…などなど、持っている情報やスキルが異なるんですよね。

このゲームは業務さながら、情報が異なる中での「伝え方」「自分/相手のコミュニケーションの癖」が学べるので、フィードバックし合える機会にしたいなと思いました。

以上のことから、下記をワークのゴールに設定しました。

3. ワークの流れ

ワークの流れは下記の通りです。

とにかくゲーム数をこなして、コミュニケーション改善とともに爆弾解除成功に導いていきます。

3-1. 事前共有

1. カオスさもこのゲームの醍醐味です。
2. 爆弾が爆発する条件はタイムアウト or ミス3回。
3. ミスするごとにタイムが早くなります。
4. 都度フィードバックしてください。
5. ヒント：Keep Talking!（話し続けろ！）

3-2. 準備

• 解除指示班はマニュアルの導入部分をざっくり読む（1min）
  ・※解除指示班以外は絶対に見ないこと！！

ここまでできたらゲームスタートです！

4. ワークの結果と気づき

ゲームを通して業務に活かせるエッセンスがたくさんありました。

下記では3つに厳選してご紹介していきます。

4-1. 作業目的の明確化

解除指示班が出す指示が「どういう目的に繋がっているのか」がわからないと、爆弾処理班としては「この情報も伝えないといけないのでは...？」と不安になり、余計な情報を与えて時間をロスしてしまう場面がありました。

業務でも「どういう目的に繋がっているのか」という目的の明確化は、お互いの認識のズレを防いだり、やらなくても良いことでの時間ロスを防いだりすることができるね、と再確認することができました！

4-2. 問題自体にギャップがあるときは定期的に振り返る

爆弾爆破阻止するのに3つのモジュールを解除する必要があったのですが、爆弾処理班と解除指示班それぞれが、「どのモジュールを解除しようとしているのか」「解除するのに何がネックになっているのか」等、そもそもの問題認識を合わせる必要性を感じました。

業務でも、問題という核なる部分の認識がズレていると対策もズレたものになり、いつしか「これ何のためにやってるんだっけ？」状態を引き起こしてしまうことありますよね...。

話がすれ違っている/進まないと感じるときは、「そもそもの問題が合ってないのでは？」という姿勢が大切ということを学びました。

4-3. 事実を確認する

「指示側」はマニュアルという正解を持っているので、「処理側」としては「指示側」を100%信じることができそうに思いますよね…？

ですが、それぞれ持っている情報が違うので、「指示側」と「処理側」で時に解釈が異なることがあります。

「処理側」が少しでも「おや？？」と思ったことは、念のため確認することで、ミスが回避できた瞬間がありました。

言葉の定義一つ取っても「お互いが同じ解釈の元進められているか？」を確認する作業ですれ違いを回避できるという学びがありました。

5. こんなチームにこのゲームをおすすめしたい

少し安定してきたチーム

つまり、現ourly開発チームのように、ourly立ち上げから少し経過して安定感がでてきたようなチームにおすすめしたいです！

理由としては、チームビルディングとして実施する場合は、お互いを知っている状態の方がより旨味を感じやすいゲームだなと思ったからです。

例えば、お互いをよく知らないと癖かどうかがよく分からなかったり、業務にどう活かしたら良いのかわからなかったり...などなどが起こり得るように感じました。

また、ゲームを通して柔らかにコミュニケーションの癖が伝えられるというメリットがあるので、「部下にどう思われているのか知りたい🤔」と思うマネージャーの皆さんにも是非おすすめしたいですね！

6. 最後に

最後までお読みいただきありがとうございました！

もしourlyや私たちの開発チームに興味を持っていただけた方は、ぜひ気軽にお話ししましょう！