チームを育てるということ（エンジニアの巻）

フロントエンドエンジニア チームビルディング

ゼロベースからフロントエンドエンジニアのチームを作り始めて、もうすぐ2年が経とうとしている。

最初は1人しかメンバーがおらず、徐々に採用を進めて、今は4人のチームだ。

 

チームを育てるということは私にとって「明文化」の継続だ。

チームを形作るために、ドキュメンテーションを行う。その繰り返しこそが、チームビルディングと呼ばれるものかもしれない、とすら思う。

 

最近そんなことをよく考えていて、色々と整理したいので書いていく。

ちなみに「エンジニアの巻」としたのは私が今フロントエンドエンジニアのチームを担当しているからで、べつにそこまでエンジニアに限った話を書くつもりはない。

 

目次

 

何のためのチーム・誰のためのチーム

私が率いているチームは、何のために存在しているのだろうか。

そう考えるようになったのは、実はチームが発足してから半年以上は経った後のことだった。

それは分かっているつもりだった。しかし分かっていないことに気づいた。チームのメンバーが2人〜3人と増えていく過程で、これは私のチームではなくメンバー全員のチームだという、当たり前のことが明白になってきたからだ。

 

そして実は一つのチームに対しては、

  1. 企業（の上層部）が何らかの役割を期待している
  2. チームのマネージャーが何らかの役割を認識している
  3. チームのメンバーが何らかの役割を期待・認識している
  4. 他のチームが何らかの役割を期待している

これだけ複数の視点からの「何のためのチーム？」がある。

各々の認識が大きくズレると存在価値が危うくなったりして、最終的にはチームの解体も有り得る。実際に、人々の認識というのは簡単にズレる。

べつに企業にとって必要がないチームは、解体すればいい。しかし解体されず存続する以上は、明確な役割があった方が良い。誰だって、何のために存在しているのか分からないと思われているチームで働きたくはないからだ。

 

なので1.〜4. の皆の認識を統一するために動くことが、まずはチームのマネージャーの重要な仕事となる。これはチームを育てるというより、それ以前の前提となる話である。

 

コミュニケーションの先にあるドキュメンテーション

前述の1.〜4. の皆の認識を統一するために何をすればいいかというと、コミュニケーションとドキュメンテーションだ。これは1.〜4. の順番に行う。

  1. 改めて企業（の上層部）に期待する役割を聞く
  2. 自分が理解できる形まで落とし込み、企業（の上層部）に確認する
  3. チームのメンバーに役割を説明し、各々の期待と重なるか確認する
  4. 他のチームに役割を宣言し、各々の期待と重なるか確認する

こんな感じでコンセンサスを取っていく。

 

コンセンサスを取ったら、企業内の誰もが見れるところに「何のためのチーム？」を明文化して掲載しておく。

大事なのは、

  • 双方向のコミュニケーションを心がけ
  • 誰もが理解できる具体的な目標を設定し
  • 誰もが見れるところに明文化しておく

ことだ。

企業（の上層部）とチーム、チームのマネージャーとメンバー、これら各々の期待することが擦り合わないと、チームの土台が安定しない。

そして期待することが明文化されていないと、すぐに人々は忘れてしまう。何のためにやっているのか、などと言い出す。

なので、このようにしてチームの土台を固め、育てるための下準備を進めていく。

 

全てを明文化するイントラネット

ドキュメンテーションというが、それは一体どこに何を書いておくのか。

私の場合はGoogle サイトでチームのためのイントラネットを作り、そこにチームの目的から、メンバーから、ルールから、何から何まで書いて掲載している。

 

この、何から何までイントラネットに書いておき、絶えず運用し、定期的に社内に共有して啓蒙を進めることが、私にとってチームを育てるということだ。

 

勿論のこと、自分だけが考えたことを自分の好きなように書いてはいけない。

チームメンバーの意見を求め、皆で決めたことを、チームに求められる要求を意識しながら常に書き直していく。

簡単なフローとしては、

  1. まずは自分が下書きをしてドラフトを作る
  2. 定期的に開いているチームMTG でドラフトを揉む
  3. ドラフトを清書してFIX する
  4. FIX したものを社内に共有する

という、ごく一般的なフローに沿ってイントラを運用していく。

 

そのようにして例えば、下記のような構成のイントラネットを作っていく。

  • チームについて ⇒ 目的・メンバー・ルール・引き継ぎ情報など
  • 成長と評価 ⇒ グレードの説明・評価の方法など
  • 開発ルール ⇒ 品質を担保するためのルール・Git のルールなど
  • 開発ツール ⇒ 使って良いツール・ダメなツールなど
  • 案件の依頼 ⇒ 依頼フォーマット（チケットの書き方）など
  • 案件の情報 ⇒ 色んな案件のアーカイブなど
  • 会議と議事録 ⇒ 各MTG の目的や議事録など

こんな感じで各1〜7 の下に色んなページをぶら下げる。私が作っているイントラネットは現在、40ページ以上のボリュームになっている。

 

このイントラネットをチームのメンバーが毎日のように利用することを目指す。

実は、こういった文章にまとまったルールというものは、最初は殆ど守られることがない。なので、根気強く啓蒙する精神力が求められる。

 

私のチームでは定期的にイントラネットを読み合わせるためのMTG を設けており、30分だけ皆で集まって特定のページを読み合わせ、ルールの確認・ルールを変える必要があるかどうかの議論を行っている。

 

べつに最初から上手くいくことを期待してはいない。まずはやってみながら、必要な調整を加えていき、数年かけて強いチームになっていければ、それで良い。

 

ステータスを把握するためのドキュメンテーション

チームのマネージャーは、何らかの形でメンバーの稼働を管理している人が多いと思う。メンバーが今、何に時間を使っていて、次に何に時間を使うのか、その成果はどのようであったか、そういったポイントを見ている。

 

それらを毎日のように口頭でヒアリングしていくのは面倒なので、色んなツールがある。Backlog や、Asana、Toggle なんかも使おうと思えば稼働管理に使えるだろう。

私は少し独特な手法なので、それに合うようにGoogle Sheets をカスタマイズして稼働管理に使っている。

  • 今日は何に時間を使ったか
  • 明日は何に時間を使うのか
  • その成果はどのようであったか

これらを可能な限り手間がかからない形でGoogle Sheets に書いて残し続け、メンバーのステータスがいつでも確認できる状態を作り上げている。

 

それ以外にも、

  • 今の仕事が楽しいか
  • 今の仕事から何を学んでいるか

というメンバーのステータスを常に把握しておくため、ファン・ダン・ラーン（FDL）を応用し、週に一度のペースで簡易的な振り返りを行っている。勿論、その結果もGoogle Sheets に書いて残し続けている。

 

特に私が重要視しているのは、チームのメンバーが今、楽しく仕事ができているかという、モチベーションのステータスだ。それを常に把握しておきたいので、FDL を取り入れた。

べつに常にモチベーションが高い状態で仕事をしてくれなんて思わない。辛い時期もあれば、楽しい時期もあるだろう。ただ、辛い時期ばかりが続いていると単に退職という結果にしかならないため、そのメンバーが何を楽しいと感じ、今はどうなのかというステータスは常に把握しておきたい。

 

このように、ステータスのドキュメンテーションを重ねることでチームを育てるための情報を、常に得ることができるようにしている。

 

チームを取り巻く環境を良くするためのドキュメンテーション

私は毎日、楽しく働きたいと思っている。チームのメンバーも、楽しく働きたいと言う。

若いメンバーが殆どである私のチームにとって、楽しいとはチャレンジのことを指す。技術的に面白そうな実装をしてみたいとか、ハードルが高そうな依頼をこなして達成感を感じたいという話だ。

 

しかし残念ながら、待っているだけでそのような依頼ばかりが来るわけではない。

なので、チームの外に働きかける動きが必要だ。

 

今年から私のチームは、いわゆる社内報として、社内メルマガを発行し始めた。

それは所属する企業の社員だけに向けて発行するメルマガだ。

そこには例えば、

  • チームのリソース状況
  • チームの目標の達成状況
  • どのようなことが楽しかったか
  • どのようなことを学んでいるか

などを書いて、月に一度のペースで配信している。

 

まだ4〜5回ぐらいしか配信していないが、この社内メルマガの効果は抜群だ。

既に「君のチームはそんなことができるのか、じゃあこんな案件はどうかな？」といった類の依頼が入ってくるようになった。

 

それ以外にも単純に、社内メルマガはチームのメンバーとチームの外のメンバーのコミュニケーションのネタにもなっており、例えば「最近こんなものを買いました」みたいなメルマガ内のコメントが、そのメンバーを知るきっかけになっていく。

 

実はこの取り組みにはロールモデルがあり、それは株式会社モノサスという企業が毎月のように送ってきてくれる、紙の社外報である。

その社外報はコーディングファクトリーというマークアップの委託サービスの現場を伝えるコンテンツが主となっており、実際にマークアップやQA を担当している人の考えていることが伝わる、とても参考になる取り組みだ。（たぶん見積りとか依頼したら送ってきてくれると思う。）

 

ドキュメンテーションを継続しているからこそ、すぐに社内・社外に共有することができるのだ。積み重ねたドキュメントは大切な資産なので、それを活用していくことを、社内メルマガ以外にも、もっと考えていきたい。

 

チームを育てるということ

簡単にまとめる。

コミュニケーションを取って皆で決めたことをドキュメンテーションする。そして、それを社内に共有していく。

この繰り返しで、チームというものが形になっていく感覚がある。

 

中核となるのはドキュメンテーション。決めたことは、書く。誰でも、いつでも、どこでも見返せるようにしておく。

なので、どこに書くか、どのように書くか、ということを常に気にしている。

 

このような私の試行錯誤を知ってか知らずか、チームのメンバー達はすくすくと成長し、最近では何だかエンジニアっぽいことを言うようになってきた。

来年〜でやっと3年、そろそろ大きな成果に繋がっていくことを期待したい。