開発チームのリーダーとしてどうあるべきか？

2019年4月16日 Webデザイン・Web制作に関する勉強会 #5 での登壇資料です。

エンジニアチームのリーダーとして私が実際にやっていること、気をつけていること、私にとっての「チームリーダの理想」のようなものについてまとめてみました。

（内容はあまり変えずに後日構成を修正してあげなおすかも）

Transcript

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