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

by ショウノシオリ

Slide 1

Slide 1 text

開発チームのリーダーとしてどうあるべきか？ 20190415_Webデザイン・Web制作に関する勉強会 #5

Slide 2

Slide 2 text

ショウノシオリ @shosho_egg 　・株式会社 chatbox　テックリード　・PHPカンファレンス関西2017&2018 実行委員長　・Laravel/Nuxt.js をよく使う　・「技術が好き」というより　　チームで何かを作り上げるのが好き

Slide 3

Slide 3 text

ショウノシオリ @shosho_egg 　・株式会社 chatbox　テックリード　・PHPカンファレンス関西2017&2018 実行委員長　・Laravel/Nuxt.js をよく使う　・「技術が好き」というより　　チームで何かを作り上げるのが好きでも、

Slide 4

Slide 4 text

チーム開発は簡単じゃないなぁと思う

Slide 5

Slide 5 text

今日話すこと ▷ チームリーダーは何をしているのか？ ▷ リーダー職を兼任することの難しさ ▷ チームリーダーの向き不向き ※肩書き名は組織によっても変わると思うので、「チームリーダー」という名称で話します

Slide 6

Slide 6 text

1. チームリーダーは何をしているのか？「縁の下の力持ち」を目指す

Slide 7

Slide 7 text

主な業務 ▷ タスクの振り分け ▷ PRのレビュー＆マージ ▷ コード規約、READMEの整備、各種環境のセットアップ ▷ 開発チーム以外の人との仕様確認

Slide 8

Slide 8 text

タスクの振り分け ▷ 開発を分担して進めれるようにチケット化する ○ はじめに作るチケットは粒度が大きくてもよい ○ フェーズが進んできたら、粒度を小さくしていき、徹底的に未完了チケットを潰していく ▷ 簡潔かつ明瞭に ○ 誰が読んでも同じ内容が理解できるようにする ○ 文章でダラダラ書くより、見出しを使って箇条書きで書く方が良い

Slide 9

Slide 9 text

PRのレビュー＆マージ ▷ GitHub でのPR運用を取り入れることで、コードの品質を保つ ○ commit や PR タイトルに関連issue 番号を記載してもらい、遡れるようにする ▷ 認識のズレや、改善点などをマージする前に伝えることができる ○ マージしてしまってから修正箇所を探すのは大変 ○ 修正をするのは作業者が行う方がはるかに早い

Slide 10

Slide 10 text

コード規約、READMEの整備、各種環境のセットアップ ▷ 指針となるものを作って、コードの破綻を未然に防ぐ ○ README にコード規約や設計について記載しておくことで、複数人が並行で開発してもある程度整ったプログラムを保持できる ○ ただ、全く崩れのないコード設計は不可能だし、初期のコード規約が好ましくない場合もあるため、随時見直しは必要 ▷ 必要な資料やテスト環境をまとめておくことで、開発をスムーズに ○ どこに何が書いてあるのかがわからないのは思っている以上にストレス

Slide 11

Slide 11 text

開発チーム以外の人との仕様確認 ▷ PM やデザイナーの言いなりになるのではなく、ベストな実装を一緒に検討する ○ 少しでも疑問に思ったら 5W1H について確認する ○ 仕様を実装に落としこめるかどうかを考える必要がある ▷ 立場の違う人との会話では、使う単語や表現などにも注意が必要 ○ お客さんに「モーダル」「バリデーション」といった単語は伝わらなかったりする

Slide 12

Slide 12 text

気をつけていること ▷ 言い方には気をつけるが、発言は濁さない ○ 偉そうな言い方、全てをわかったかのような言い方はしないようにする ○ 伝えたいことは曖昧にせず伝えるようにする ○ 相手の話を遮らない ▷ 自分一人でタスクを抱え込まない ○ タスクが膨大になりがちなので、優先順位をつけて困ったら周りの人に相談する ○ 依頼コストを考慮して、他の人に頼める作業は頼む

Slide 13

Slide 13 text

2. リーダー職を兼任することの難しさ “切り替え” が勝敗を決める

Slide 14

Slide 14 text

少人数チーム故の弊害？ ▷ チームリーダー ▷ 開発メンバー両者を一人の人が兼任するのは結構大変 ...

Slide 15

Slide 15 text

チームリーダー ● エンジニアとしてのそれなりの知見 ● Yes/No で答えられること ● 基本的には、どんな状態になっても案件をやり遂げること ● いろんな種類の作業を並行して進められること ● プロジェクト全体を俯瞰して見ること開発メンバー ● 作業報告を適切に行えること ● 「より良いコードを書く」という気持ちを持つこと ● 分担されたチケットを優先順位をつけて、1つずつ完了させていくこと ● 作業に没頭できることそれぞれに求められること

Slide 16

Slide 16 text

Slide 17

Slide 17 text

兼任するならそれなりに気合をいれて ▷ 相反することを1人の人が行う時は「いかに無駄なく時間と頭を使うか」がポイント ○ 短時間毎でリーダー業務と開発業務を切り替えるのは作業効率が悪い ○ 1日のはじめ、週単位といったタイミングで2人の自分をどう使うのかを大まかにでも計画しておく

Slide 18

Slide 18 text

3. チームリーダーの向き不向き「誰をリーダーにする？」

Slide 19

Slide 19 text

“ チームリーダー大変じゃない？やるメリットあるの？

Slide 20

Slide 20 text

あります！！

Slide 21

Slide 21 text

チームリーダーをするメリット ▷ プロダクトが完成していく様を間近で見れる ○ 作って行く様子が見えるのは単純に楽しい ▷ 自己満足で仕事を進めてしまうことが少なくなった ○ チームリーダーがくすぶってしまうと、チーム全体が困る ○ おこがましくも時々思っていた「これは私の成果だ」という考えを持たなくなった

Slide 22

Slide 22 text

誰でもチームリーダーはやってみた方がいい？ ▷ 私の答えは「No」 ○ 複数人で進めるのであればリーダーは必要だが、向いている人・やりたい人がやる方が効率的だと思う ○ 開発業務が大好きな人もいる ▷ 「よく喋るひと」「元気な人」「目立つ人」がリーダーには向くとは限らない ○ 「感情的にならず、優先順位を間違えず、建設的に物事を伝えられる人」が良い

Slide 23

Slide 23 text

まとめチームリーダーとして、私なりの答え

Slide 24

Slide 24 text

チームリーダーのあるべき姿 ▷ チームリーダーを「やりたい、成し遂げたい」と自主的に感じていること ○ やらされてる感はよくない ▷ 常に冷静かつ、プロジェクトを俯瞰して見ること ○ 感情的にならない ○ 優先順位を間違えない ○ 建設的に物事を伝える

Slide 25

Slide 25 text

「何かすごいことをやる」のではなく「普通のことをきちんとやる」