チームリーダー必見！ エンジニアチームでやっていること
ごあいさつ
こんにちは！
Web開発部門 エンジニアチーム（以降 エンジニアＴ）の馬場です。
「実年齢より若く見える！」と言われたいものの、左肩が四十肩で回らず年齢に抗えなくなってきている40代男性です。
今回、なにについて書くか悩みましたが、どういう環境で働いているのかについて話したいと思います。（環境というか取り組みというかやっていることというか。。。）
目次を見ていただければ、どういうことを書いているのかなんとなくわかっていただけると思いますが、できるだけ働きやすい環境にしたいという気持ちでやっています。
ちなみに取り入れていることはどこかでやっていたことを真似ていることがほとんどです。
だめだったらやめればいいだけですし、もし良さそうなものがあれば取り入れてみてください。
読んでほしい方
なにかしらチームを運用している方
社内の他部署の方
前情報
チーム構成
馬場
チームリーダー
主にバックエンド担当Uくん
主にフロントエンド担当Yさん
主にフロントエンド担当
外部リソースあり
関連チーム
HONDANAスマーケティングチーム（以降 スマケＴ）
https://note.com/tokoai/n/nacb6ed3e1b86ディレクターチーム（以降 ディレクターＴ）
Backlog に課題を登録してもらう → エンジニアが対応する
勤務場所
在宅ワークが基本
案件リリース時などに出社
馬場は歯医者に行く日に出社
（会社からの方が近い）
朝MTG
毎朝9:30から3人でビデオチャットで今日の予定を確認しています。
スマケＴ、ディレクターＴ、エンジニアＴのメンバーが参加しているSlackのワークスペースに、出勤時今日の予定を各々貼り付けているため、そこを見れば予定はなんとなくわかるのですが、MTGをすることでその予定がどういう内容なのかわからない際に確認できたり、案件を進めるにあたり、不明点を確認したり、他の連絡事項を共有したりと、いろいろと共有の時間として使うことができています。
メリット
お互いの対応内容を把握できる
→ コードレビューしやすくなるリソース状況の確認ができる
顔を見ることで、なんとなくその日のコンディションを確認できる
（体調悪そうとか）集まる時間を毎日確保しているため、ちょっとした別の用事にも使える
デメリット
毎朝 人数分の時間を拘束してしまう
人数が増えると時間も増える
→ 長引いてしまう際はなにかしら工夫が必要
おすすめ度
★★☆
月次面談
毎朝 チームでMTGしているものの、言いづらいこともあると思いますので 月1回 1対1 で話す機会を設けています。
基本、下記について聞いています。
困っていることはありませんか？
こうした方がいいと思っていることはありませんか？
こんな仕事がしたい等はありませんか？
その他なにかあれば
メリット
朝MTGで聞けないことを聞くことができる
言い出しづらいことも時間を設けることで少しは言いやすくなるかもしれない
デメリット
毎月やっていると話す内容がなくなってくる
聞く方も「きっと話は無い」という気持ちになって聞きづらい雰囲気になってしまっている可能性アリ
→ 意図とは逆の効果になってしまうかも聞き手（馬場）に言えない内容、不満が拾えない
おすすめ度
★★☆
案件着手前MTG
出版社さまのサイトとしてHONDANAを使っていただくための導入案件が主な案件となるため、案件の着手前にエンジニアＴ全員で案件の仕様を確認し、ある程度の実装方法を事前に確認するようにしています。
1人で悩む時間を少しでもなくし、導入スピードを上げることが目的です。
メリット
知識の共有
開発担当者による技術力の偏りを少なくする
デメリット
着手前のため、内容がイマイチあたまに入らない
開催タイミングが難しくあまり実施できていない
（案件着手前MTG実施前に着手してしまい、そのまま実施しない等）
おすすめ度
★☆☆
振り返り
導入案件がリリースになる毎にKPTによる振り返りを行っています
当初はエンジニアＴだけでやっていましたが、ディレクターＴの担当者にも参加してもらい、今はスマケＴの担当者にも参加してもらっています。
振り返りの内容はスマケＴ、ディレクターＴ、エンジニアＴ全員で月イチでやっているMTGで共有し、うまくいったことは今後の案件に活かし、うまくいかなかったことは繰り返さないようにしています。
メリット
良かったこと、うまくいかなかったことの認識合わせ、共有ができる
うまくいかなかったことについては改善案を実施
デメリット
数名の時間を拘束する
改善案の実施についてどうなったのか話す機会を設けておらず、改善されているか否かの判断ができていないものがある
おすすめ度
★★★
コードレビュー
Backlogの課題単位でコードレビューを行っています。
YさんのレビューはUくんが。
Uくんのレビューは馬場が行っています。
（2024年1月からUくんのレビューはYさんにやってもらう予定。）
馬場のレビューは外部開発チームにお願いしていましたが、現時点では行っていません。
（社内にバックエンドエンジニアが増えたらレビューしてほしい）
メリット
知識の共有
チームとしての技術力の底上げ
コードの品質確保
デメリット
レビュアー（レビューする人）の負担
スムーズにレビューしてもらえないとレビュー待ちで開発が止まる
おすすめ度
★★★
レビュー会
コードレビューにてレビュアーとレビューイ（レビューされる人）の情報共有はできるものの、他のメンバーには共有されません。（今3名なので1名にだけ共有されていない）
月イチでYさん、Uくんに聞きたい案件を指定してもらい、その案件の担当者（レビューイ）に案件のカスタマイズ内容を軽く紹介してもらって、どのような実装になっているのかの確認を行っています。
月イチではなく、案件リリース後に実施すればいいのでは？と思い始めているのでそのようにする予定です。
メリット
知識の共有
チームとしての技術力の底上げ
デメリット
レビューイの負担
おすすめ度
★★☆
雑談会
エンジニアＴは在宅ワークが基本で他社さんにうかがって打ち合わせすることもなく移動中に話す等の時間がないため雑談する機会がほとんどありません。
こう書くと
「いや、出社すればいいのでは？」
と言われそうですが、出社してもきっと雑談はしないと思います。
（どうやって話かけるのかわからない。。コミュ力不足。。）
ただ、よく知らない人のためにがんばろうとは思わない（一緒に仕事したいとは思わない）はずですし、お互いのことを知っておいた方が仕事がしやすくチームとしての生産性も上がるとは思っています。
ということで月イチ30分、ビデオチャットでの雑談の時間を設けています。
当初はテーマがあったほうがいいと思い、持ち回りでテーマを決めていましたがテーマ決めが少し負担になっていそうだったのでテーマなしで行い、最近は別のチーム、スマケＴのメンバーにも参加してもらいました。
今月はディレクターＴの誰かにお声がけ予定です。
雑談をする時間を設けるってどうなの？と思ったりもするのですが
とうこう・あいで導入しているメンター制度に「当たらずも遠からず」だと思っているのでギリギリセーフでは？と勝手に思っています。
メリット
チームの結束力アップ
デメリット
時間の拘束
他の方法をうながされるかも？
おすすめ度
★☆☆
やりたいけど できていないこと
本当は勉強会のようなものを実施したいとは思っています。
みんなでマナバナイトのエンジニアＴ版のようなものですね。
前職でも勉強会のようなものはやっていましたが、発表者の負担が大きく、なかなか運用が難しかったためやったほうがいいとは思いつつ、実施できていません。
最後に
チームの人数やメンバーが変わったタイミング等で実施する内容が変わることはあるかもしれませんが、良さそうなものは真似をして、合わなくなったものは取りやめて働きやすい環境となるように努めていきたいと思います。
コードレビュー等エンジニアじゃないと導入できないものもあるかもしれませんが、似たようなことはできるのではないかと思っていますので（作った資料の共有とか、商談方法の共有とか？）ぜひともご検討ください。
この記事が気に入ったらサポートをしてみませんか？