チーム

I moved to a different team

今年の8月から、約1年所属していたチームから別のチームへの配属になりました。（内部的には希望を出していた）

元々のチームでは Node.js でいくつかのプラットフォームの API の新規開発や追加機能開発、運用保守をやってましたが、今は Vue.js (Nuxt.js) を使って画面の設計・実装を行っています。

ちなみに、「フロントエンドの開発がしたい」と会社に言ったところ、フロントエンドの仕事を取ってきてくれたのは嬉しく、自分がそこにジョインできたのは有り難いが、まさかチームリーダーとは予想していなかったですw

My role

ジョインしてわかったことは、こういう言い方するとマイナスに聞こえるかもしれませんが、想定と現実は異なりましたw PM (この記事では Project Manager の略) が私に期待することは、フロントエンドチームのリーダーということで、自分は１エンジニアとしてジョインのつもりでしたが、まぁそこは受け入れました。

実際にプロジェクト始まってやってることはこんな感じです。

ドキュメントの作成
- WBS
- JIRA のタスクボード管理
- 画面設計書の作成、更新
ブリッジ
- デザイナー、バックエンドエンジニアと仕様の確認
- 客先での定例会での技術的な補佐
環境、インフラ周り
- デプロイフローの環境整備
- API スタブの用意（by using swagger-node）
その他
- テストコード（by using Node.js）

（…あれ、俺コード殆ど書いてなくね？唯一書いているの Node.js でテストコードか、yaml ファイルじゃね？）

と気づいたのが今月頭のことでして、割と気付くの遅かったんですが、フロントエンド、バックエンド、デザイン、クライアントと話ができる のと、テストコードをガリガリ書いたことがある 人間がチーム内で私だけだったので、まぁこのまま走り切るしかなさそうなのが現状です。

ただ、人と話すことは好きですし、自分の役割はとても大きいかつやりがいもある、チームメンバーがなるべくエンジニアリングに集中できるように動くのがリーダーの役割ですので、適材適所だと感じてます。そして何より、実際にこれでチームメンバーが楽しく開発ができているので、十分満足しています😆

For the ripening of the team

今の案件の開発フローは、古来からの定番「ウォーターフォール開発」です。が、私のチーム内だけでもアジャイルの良い点を取り入れて、チームの活性化・パフォーマンスの最大化をはかりたかったので、チーム作りのアクションとして、以下の３つを取り入れました。

Stand-up meeting（朝会）
Retrospective meeting（振り返り会）
Break the wall of communication（コミュニケーションの壁を壊す）

重視していることは、「いらないコミュニケーションはなるべくなくす」「ノウハウの共有」「チームの熟成」「必要なら誰でも気軽に適宜コミュニケーションを取る環境を作る」の４つです。これらがそろえば、100%とはいかないまでもパフォーマンスはかなり出ると思っています。

Stand-up meeting（朝会）

私のチームでは、毎朝 10:30 に朝会を行っています。ここで「各自が今日やること」「何に詰まっているか」「それの解決策がパッと出ればその場で解決」「勤怠などの連絡」の共有を行っています。

この会はなるべく全員が参加してほしいので、誰かが遅刻する場合はその人に合わせて時間をズラしています。ファシリテートは基本的にリーダー（つまり私）が行いますが、私が休みの場合は、誰か他の人（だいたいチームのエース）が自発的にやってくれています。ホンマにありがたい👏

ちなみに、会社の始業時間は 10:00（コアタイムは11:00）ですが、全員が集まりやすい時間が 10:30 なので、この時間になりました。私朝弱いんですよ…ﾈﾑｲ(´･ωゞ)

Retrospective meeting（振り返り会）

また、週一回フロントエンドチームのみの振り返り会（と言う名の KPT ）をやっています。日時は毎週火曜日の15:00。

全チーム含めた案件全体の定例会もありますが、主に全体共有と各チームの進捗や共有事項を話しています。（もちろんリスク事項や、あればアラートなども含む）フロントチームの振り返り会は月曜日でも良かったのですが、週明けは皆そんなにテンションが上がらないのと、定例会の日程と合わせて同じ曜日にしました。

定例的なミーティングはまとめてしまいたい派です。（メンバーと相談の上、全員納得の上決定です）

Break the wall of communication（コミュニケーションの壁を壊す）

こちらが一番苦心しました。。。

メンバー間の中は良いと思いますが、いざ一緒に仕事するとなると途端にコミュニケーション取りづらさが出てくるメンバーもいました。理由としては、

2人を除いて、ほぼ全員が初めて一緒に仕事をする
年齢もちょっとバラけている（私は上から２番目の年長者）
互いの性格も分からない

が挙がるかなと思います。特に年齢が上の人ほど話かけづらい空気が出ていたようで、思ったより最初は壁を感じていたようです。私事ですと例えば、以前ツイキャスでも話しましたが、メンバーの女の子に

桑原さんの事が少しずつ分かってきて、人間味を感じてきました！今までは、感情があまりない仕事マシーンのような人なんだと思っていたので！

と言われ、ちょっと驚きました。会社で顔は見たことあるけど、喋ったのもこの案件で一緒になったのが初めてでしたしね（笑）

こちらは時間が解決もしてくれたと思いますが、フロントチーム全員でランチに行くとか、こちらから意図的にメンバーへの会話を増やしたりとか、時間があるうちに slack 上で雑談をちょいちょい挟んだり、色々行動してみました。（雑談は大好きです😁←）

Problems

あくまでチームビルディングの課題としては以下です。

モチベーションの維持が難しい
- クライアントの仕様変更による手戻りなど
私の役割が広すぎる
- 各チームとのコミュニケーション
- PM陣との進捗管理や客先訪問との仕様詰め
- 諸々のドキュメント管理
案件全体の情報共有ドキュメントがない
- 会議の議事録を追うしかないのは辛い
メンバーの技術力の底上げ
私が案件の単一障害点になりかねない

やっぱり変化し続ける 人 が一番難しいですね。その日の気分や体調によって進捗も全然変わりますし。

後は、案件全体の情報共有の仕組みが弱すぎますね💦誰が正解を持っているのか、最新情報はどこにあるのかを誰も知らないのは問題過ぎます… また、PMだけが持っているドキュメントなどもあり、その辺も今後はしっかりつついていきたいと思います。（それは私の仕事）

Closing

ざっくりと話しましたが、細かいルール（commitルールや、コーディング規約など）とかも案件スタート時にしっかり時間取って、全員で決めています。

また、チーム内の情報共有は割とこまめに行なっているので、最悪誰かが倒れても、他のメンバーで巻き取れる体制はできたかなと思います。（全員いなくなっても、私がやれば良い。そんな状況はないでしょうがw）

嬉しい誤算は、メンバーに自立性が生まれたことですね。各自のタスク中に、各自が他のチームとどんどんコミュニケーションを取り、何か変わることがあれば slack から共有してくれる流れが定着しました🎉本当に良いチームになってきたという実感があって、嬉しい限りです。実は次の案件の話も降ってきてはいますが、ほぼ今のこのチームのままやれそうなので、次も安心しています。

この内容が誰かの参考になれば幸いです。ではでは(=ﾟωﾟ)ﾉ