2019年4月16日 Webデザイン・Web制作に関する勉強会 #5 での登壇資料です。
エンジニアチームのリーダーとして私が実際にやっていること、気をつけていること、私にとっての「チームリーダの理想」のようなものについてまとめてみました。
（内容はあまり変えずに後日構成を修正してあげなおすかも）
開発チームのリーダーとしてどうあるべきか？20190415_Webデザイン・Web制作に関する勉強会 #5
View Slide
ショウノシオリ@shosho_egg ・株式会社 chatbox テックリード ・PHPカンファレンス関西2017&2018 実行委員長 ・Laravel/Nuxt.js をよく使う ・「技術が好き」というより チームで何かを作り上げるのが好き
ショウノシオリ@shosho_egg ・株式会社 chatbox テックリード ・PHPカンファレンス関西2017&2018 実行委員長 ・Laravel/Nuxt.js をよく使う ・「技術が好き」というより チームで何かを作り上げるのが好きでも、
チーム開発は簡単じゃないなぁと思う
今日話すこと▷ チームリーダーは何をしているのか？▷ リーダー職を兼任することの難しさ▷ チームリーダーの向き不向き※肩書き名は組織によっても変わると思うので、「チームリーダー」という名称で話します
1.チームリーダーは何をしているのか？「縁の下の力持ち」を目指す
主な業務▷ タスクの振り分け▷ PRのレビュー＆マージ▷ コード規約、READMEの整備、各種環境のセットアップ▷ 開発チーム以外の人との仕様確認
タスクの振り分け▷ 開発を分担して進めれるようにチケット化する○ はじめに作るチケットは粒度が大きくてもよい○ フェーズが進んできたら、粒度を小さくしていき、徹底的に未完了チケットを潰していく▷ 簡潔かつ明瞭に○ 誰が読んでも同じ内容が理解できるようにする○ 文章でダラダラ書くより、見出しを使って箇条書きで書く方が良い
PRのレビュー＆マージ▷ GitHub でのPR運用を取り入れることで、コードの品質を保つ○ commit や PR タイトルに 関連issue 番号を記載してもらい、遡れるようにする▷ 認識のズレや、改善点などをマージする前に伝えることができる○ マージしてしまってから修正箇所を探すのは大変○ 修正をするのは作業者が行う方がはるかに早い
コード規約、READMEの整備、各種環境のセットアップ▷ 指針となるものを作って、コードの破綻を未然に防ぐ○ README にコード規約や設計について記載しておくことで、複数人が並行で開発してもある程度整ったプログラムを保持できる○ ただ、全く崩れのないコード設計は不可能だし、初期のコード規約が好ましくない場合もあるため、随時見直しは必要▷ 必要な資料やテスト環境をまとめておくことで、開発をスムーズに○ どこに何が書いてあるのかがわからないのは思っている以上にストレス
開発チーム以外の人との仕様確認▷ PM やデザイナーの言いなりになるのではなく、ベストな実装を一緒に検討する○ 少しでも疑問に思ったら 5W1H について確認する○ 仕様を実装に落としこめるかどうかを考える必要がある▷ 立場の違う人との会話では、使う単語や表現などにも注意が必要○ お客さんに「モーダル」「バリデーション」といった単語は伝わらなかったりする
気をつけていること▷ 言い方には気をつけるが、発言は濁さない○ 偉そうな言い方、全てをわかったかのような言い方はしないようにする○ 伝えたいことは曖昧にせず伝えるようにする○ 相手の話を遮らない▷ 自分一人でタスクを抱え込まない○ タスクが膨大になりがちなので、優先順位をつけて困ったら周りの人に相談する○ 依頼コストを考慮して、他の人に頼める作業は頼む
2.リーダー職を兼任することの難しさ“切り替え” が勝敗を決める
少人数チーム故の弊害？▷ チームリーダー▷ 開発メンバー両者を一人の人が兼任するのは結構大変 ...
チームリーダー● エンジニアとしてのそれなりの知見● Yes/No で答えられること● 基本的には、どんな状態になっても案件をやり遂げること● いろんな種類の作業を並行して進められること● プロジェクト全体を俯瞰して見ること開発メンバー● 作業報告を適切に行えること● 「より良いコードを書く」という気持ちを持つこと● 分担されたチケットを優先順位をつけて、1つずつ完了させていくこと● 作業に没頭できることそれぞれに求められること
チームリーダー● エンジニアとしてのそれなりの知見● Yes/No で答えられること● 基本的には、どんな状態になっても案件をやり遂げること● いろんな種類の作業を並行して進められること● プロジェクト全体を俯瞰して見ること開発メンバー● 作業報告を適切に行えること● 「より良いコードを書く」という気持ちを持つこと● 分担されたチケットを優先順位をつけて、1つずつ完了させていくこと● 作業に没頭できることそれぞれに求められること相反する
兼任するならそれなりに気合をいれて▷ 相反することを1人の人が行う時は「いかに無駄なく時間と頭を使うか」がポイント○ 短時間毎でリーダー業務と開発業務を切り替えるのは作業効率が悪い○ 1日のはじめ、週単位といったタイミングで2人の自分をどう使うのかを大まかにでも計画しておく
3.チームリーダーの向き不向き「誰をリーダーにする？」
“チームリーダー大変じゃない？やるメリットあるの？
あります！！
チームリーダーをするメリット▷ プロダクトが完成していく様を間近で見れる○ 作って行く様子が見えるのは単純に楽しい▷ 自己満足で仕事を進めてしまうことが少なくなった○ チームリーダーがくすぶってしまうと、チーム全体が困る○ おこがましくも時々思っていた「これは私の成果だ」という考えを持たなくなった
誰でもチームリーダーはやってみた方がいい？▷ 私の答えは「No」○ 複数人で進めるのであればリーダーは必要だが、向いている人・やりたい人がやる方が効率的だと思う○ 開発業務が大好きな人もいる▷ 「よく喋るひと」「元気な人」「目立つ人」がリーダーには向くとは限らない○ 「感情的にならず、優先順位を間違えず、建設的に物事を伝えられる人」が良い
まとめチームリーダーとして、私なりの答え
チームリーダーのあるべき姿▷ チームリーダーを「やりたい、成し遂げたい」と自主的に感じていること○ やらされてる感はよくない▷ 常に冷静かつ、プロジェクトを俯瞰して見ること○ 感情的にならない○ 優先順位を間違えない○ 建設的に物事を伝える
「何かすごいことをやる」のではなく「普通のことをきちんとやる」
簡単なようで難しいことが真理なのかなぁ、と思います
Thanks!Any questions?You can find me at:@username[email protected]
sshono1210
niftycorp
tomokusaba
kasacchiful
mugi_uno
h0r15h0
uhooi
takamin55
chimame
zakky21
assu_ming
ddemaree
marktimemedia
sonatard
jakevdp
bcantrill
mongodb
jnunemaker
cherdarchuk
bluesmoon
rmw
mraible
danielanewman