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

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

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

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

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

C385e96e5ddd25faba59e3e14fc3e019?s=128

ショウノシオリ

April 16, 2019
Tweet

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