ハッカソンのための開発合宿の記事はよく見かけるのですが、チームビルディングのためのエンジニア合宿はあまり見かけないですよね。話を聞いてみるとトレタでは定期的にやっているみたいなので他でもクローズドでやっているのかもしれませんね。
シリコンバレーだとけっこうやっていて成果が出ているらしいからというのもあるんですが、私は個人的にメリットが多いと思っているので、チームビルディング合宿のことを書いていきます。
エクスペリエンスを知りたい方は開発者ブログ（チームビルディングのためのエンジニア合宿をしてきました！）に投稿してありますので、そちらを参照してください。この記事ではスペックを書いていきます。
なぜチームビルディング合宿をしたのか
私が今の会社にジョインしたのが3月で、それまではエンジニア2名体制でやっていましたが、レクミーのサービス検証フェーズが終わり、拡大フェーズに入っていくタイミングで私と同時期に2名のエンジニアがジョインして、チームの人数が5名になり倍以上になりました。過半数以上の人が別々のカルチャーを持っていたらそれはもう今までとは別のチームです。
「なにをするか」よりも「どうあるべきか」を決めなければまずいと思い、3月1日に入社して、3月14日には合宿に行きました。組織改善でCMMIをやるところは多いと思いますが、失敗例として多いのが「どうあるべきか」をないがしろにして「なにをするか」で進めてしまうことです。腹落ちしていないのにやるべきことを羅列して進めると最初はうまくいっても続かないことが多いですね。
チームビルディングでは基本的な考え方だと思いますが、Be→Do→Haveの順で決める必要があるということです。
チームビルディングの流れ
Be→Do→Haveの順で進めたわけですが、実際にどういった流れで進めたいったかと言うと。
Be
まず相互理解のためにお互いの「強み」を他己紹介形式でやったり、各人がどういったことをやりたいと思っているのかを共有しました。
次に、各人に理想のチームとはどんなものかを挙げてもらったのですが、箇条書きよりは実際にどんなチームなのかイメージしやすいように、絵や図にして描いてもらい、それを元に皆に共有する形式でやりました。
最後に理想のチームで出た意見をまとめて行動規範としました。
GoogleのHRTは本当によくできていて、自己・他者・関係についていくつか意見は出たのですが、自己＋他者＝関係と形で分類してまとめることができました。自己がどうあるべきかと、他者に対してどう接するべきか、その結果として関係が構築されるということですね。
Do
このあたりのナレッジはもう語り尽くされていると思うので簡単に説明すると、スクラム＋CMMIという感じですね。KPTでProblemとTryを洗い出して、CMMIに落とし込んでいくという感じです。
Have
KPTで出た「現状強み」と「課題を解決できたときにできる強み」を元に技術的ビジョンと組織的ビジョンに分類し、画像では戦略に落としこむことになっていますが、結果として１つのビジョンにまとまったので、それを目標とすることで認識の共有ができました。
エンジニアリングではよくある、品質・納期・コスト・スコープの４つの変数と似ていますね。フレームワークの再発明というか、フレームワークを作る過程を体験することでよりフレームワークに対する理解が深まる結果となりました。
正確には品質＝品質、納期＝スピード、コスト＝成長、スコープ＝集中ということで、「最高の品質のプロダクトを最速のスピードでユーザーに届ける」という技術的ビジョンと、「エンジニアとして成長し続け、やるべきことに集中できる環境を作る」という組織的ビジョンに分類されます。そのために必要なのがBeで決まった信頼関係の構築が必要だという結果になりました。
チームビルディング合宿をやってみて
合宿の成果としては「どうあるべきか」と「目指すべき姿」の認識の共有ができたことが一番大きかったですね。その後の目標設定や振り返りのベースとなる軸が作れたことでブレないチームになりました。
新規事業も始まりエンジニアが圧倒的に足りない状況なので積極的に採用していますが、メンバーが増えた際にはまた認識を共有するために定期的にチームビルディング合宿をやろうと思っています。