Posted by この記事はGRIPHONE Advent Calendar 2019 7日目の記事です。
こんにちはサーバーサイドエンジニアの斎藤です。
今回はチームビルディングについてお話させて頂きます。
はじめに
これまで5年くらい様々なプロジェクトでリーダーと言われる仕事をさせてもらっており、 改めてチームビルディングで心がけていることをまとめてそれを共有することによって、同じようにチームビルディングを行う人達のお役に立てればと思って書かせて頂きます。
チームビルディングとは？
チームビルディングと言っても各所で様々に定義されていますが、私は
「プロジェクトが成功するために、メンバーの力を最大限に発揮できる体制を構築すること」と定義しています。
まず心に留めておくべきことは、完璧なチーム体制は存在しないということです。
プロジェクトの状況やメンバーが変わることで最適解は常に変わり続けます。
ですので、チームビルディングは一度では終わらず継続的活動であることと認識することが重要となります。
チームビルディングサイクル
それではチームビルディングサイクルについて、サーバーサイドリーダーとしてどう行動したのかを実例を元に説明していきます。
要点を伝えられるように大きく端折っているのでご了承ください。
サイクル１ リーダー１人でどうするの？
現状把握
最初はサーバーサイドはリーダー1人、短期間開発ということで、
あまり冒険はできない状態でスタートしました。
方針決め
まずはプロジェクトが成功するということはどういう状態かを考えます。
サーバーサイドエンジニアにとっては
「スケジュール」「品質」
を担保することがプロジェクトの成功につながると思ったので、
その2点を担保しようと考えました。
その中で下記を軸に考えました。
理想像
現在の状況的に難しいけど将来的に取り入れたいこと
常に考えておくことでチャンスが訪れたらすぐに導入できるように準備しておく
実現可能な方針
現実的に可能な範囲に落とし込んだもの
今回はリソース的に
「先行プロジェクトのコードを最大限活用」
が現実的な方針だと考えました。
実践
サーバーサイドは自分1人なのでチームビルディングとしては特筆的なことはやっていません。
サイクル２ 技術アドバイザー華麗に登場！
※技術アドバイザーとはプロジェクト横断で技術に関してアドバイスを行うエンジニアのことです
現状把握
たまたまうちのプロジェクトが技術アドバイザーの目に止まったらしく、会社の意向も踏まえてDaoなど基盤について吟味して実装することになりました。
方針のアップデート
今までは「先行プロジェクトのコードを最大限流用する」
としていましたが、技術アドバイザーの協力も得られるということで
「先行プロジェクトのコードを最大限流用する」とちょっと方針を緩め、
「基盤の品質にこだわる」の新方針を追加しました。
実践
上記を実現させるために、「基盤の仕組みについて議論する場」として
技術アドバイザーとクライアントのエンジニアリーダーと3人で週一定例MTGを設けました。
この際、軌道に乗るまでは毎回意識してアジェンダとなるものを作って、
参加者全員が意義のあるものと認識できるように注力しました。
サイクル３ メンバーが増えた！しかも２人！！
現状把握
サーバーメンバーが1人増え、さらに想定外にもう1人加わることになりました。
しかも2人共技術的にモチベーションの高い2人です。
当然のことながら状況が変わったのでチーム方針をアップデートする必要があります。
方針のアップデート
チームメンバーに恵まれたこともあり、「基盤の品質にこだわる」ことに注力できる環境が整ったので、「先行プロジェクトのコードを流用する」の方針を撤回しました。
また、理想としていた自動化への意識も高いので、 「自動化できるところは可能な限り自動化」 を進めるように方針転換しました。
実践
ビジョンのアップデートに伴い仕組みもアップデートしました。
週一の「基盤の仕組みについて議論する場」に「メンバー間で理想像について語る場」の意味合いも付加して、チーム内の共通認識をすり合わせることによりチームにビジョンを浸透させる場として活用しました。
チームビルディングサイクルを回す上での３つのポイント
チームビルディングサイクルを実施する上で下記の３つのポイントに注意しました。
ピンチはチャンス
何もトラブルの発生しないプロジェクトはまずありません。
トラブルが発生するということは、現状のチーム体制がプロジェクトの状況にマッチしていない可能性があります。
そういう時こそチームをアップデートするチャンスですので、ピンチを肯定的に受け入れるとうまく行きやすいです。
仕組み化すること
お題目を唱えるだけではチームに定着しません。
定期的に実行するものとして仕組み化しないと実現しないので必ず定常フローの中に組み込むようにしましょう。
しかし、あれこれと定常フローに組み込むと首がまわらなくなると思うので、機能していないフローは適度に切り捨てることも必要になるでしょう。
常に考え変化し続けること
チームは1回考えただけでベストなものになることはありません。
考えることをやめてしまったらそこでチームの成長は止まってしまいます。
常に状況の変化を見ながら適応し続けることが肝要です。
おわりに
できるだけわかりやすいように論点を絞って書いたつもりですが、わかりにくい所も多々あると思います。
そこは読者の想像力で補完してもらえばと思います。
この記事が読者のチームビルディングの参考になれば幸いです。
