📝

プレイングリーダー・マネジャーのタスク設定方法

に公開
task
idea

TL;DR

  • タスクは毎日整理し、設定する

    • 自分自身に加え、チームにもメリットがある

  • 開発職とリーダー職を兼任している場合、緊急度/優先度は以下で分類する

    • 緊急度高・優先度高
      • 障害等の緊急対応
    • 優先度高
      • メンバーへのFB
      • メンバーへの依頼
    • 必要に応じて分類
      • 開発タスク
      • （提案活動）

はじめに

こんにちは！おいぬと申します。
この記事はフロントエンジニア兼チームリーダーとして1年すこし奮闘中の一個人が考えた、
タスクの優先順位の付け方、タスクの設定方法を共有する記事です。
開発のタスクとメンバーのマネジメントを兼務している方の参考に少しでもなれたら幸いです！

タスクは毎日整理し、設定する

プレイングリーダー・マネジャーの場合、顧客・上司・部下の三方向からタスクの依頼をいただきます。
それぞれ依頼をいただくタイミングや異なるため、棚卸を毎日行いチームに共有します。

毎日見える化しておくことで、自分自身へのメリットに加えチームへのメリットがあると考えています。

チーム（メンバー）のメリット

リーダーの状態が分かることで、話かけやすいタイミングが分かる

締切が今日のタスクが溜まっていたりと、Slackのメンションに時差がでてしまうことはどうしてもあります。
このような状態が続くと次第にメンバーはリーダーに相談しにくくなり、プロジェクトの遅延リスク等が発覚するタイミングが遅くなりかねません。

リーダーが自分のタスクを開示しておくことで、チームメンバーがリーダーのタスク逼迫具合を把握することができます。
「確認依頼をしたけど、いつ返ってくるのかな。リマインドしていいかな」
「ちょっと相談したいけど、いつが都合いいだろうか」
などちょっとしたコミュニケーションのハードルが下がります。

コミュニケーションのハードルが低い状態は、チームの心理的安全性の向上・報連相のしやすさ向上に役立ちます。

次レイヤーの仕事内容のイメージが沸き、目指しやすくなる

評価面談の季節になると、２年後・３年後にどのような仕事をしていたいか、を考えると思います。
その時に真っ先に思い浮かぶロールモデルは直属の上司・あるいは先輩です。

業務範囲を広げてスキルアップをしていく目標を立てたときに、「自社で働き続けたときに得られるスキル」を持っている対象として一つ上のポジションについている人の動きを見ます。

リーダー業務内容ややっていること・考え方を日々明示しておくと、メンバーが具体的なアクションとして理解し真似しやすくなります。
真似しやすい ＝ 気づいた時に巻き取りやすく依頼しやすい状態なので、移譲が簡単です。
リーダー自身が次のステップに進みたいときに、メンバーのステップも一緒にあげやすくなります。

自分自身のメリット

1日のキャパに収まっているか確認できる

特に仕事にやりがいを感じていて、お客様や上司の想いに応えたい！なんでもしたい！人向けにおすすめです。
当たり前ですがひとりが1日に働ける時間は有限です。
気づいた時にはやることが溜まっていて毎日タスクを先送りしている...ことになる前のストッパーの役割として、タスク整理があります。

「何にどれくらい時間をかける予定か」を明文化しておくことで、8時間（あるいは6,10時間など日に応じて）に収まっているかを確認します。

依頼に備える

タスクの整理ができていると、自然と「今週はちょっとバタバタだな💦」「すこし余裕があるな。リファクタしたいな～」などの余力もわかります。
新たな依頼をいただいた時に、スケジュール感の判断をすぐできるようになります。
ちょっとした依頼に対しても機会を逃さずに受ける、かつ自分・チームの稼働を考慮したうえでの返答ができます。

開発職とリーダー職を兼任している場合、緊急度/優先度は以下で分類する

緊急度高・優先度高

障害対応は言わずもがなここに該当します。
暫定対応が終わるまでは緊急度・優先度高で対応します。

優先度高

メンバーの成果物に対するＦＢ・作業依頼は必ず毎日時間を取るようにします。
FBを行う際は以下の観点で確認をします。

  • When：作業状況はスケジュールにあっている
  • What：プロジェクトの目的に合う成果物になっている
  • Why ：メンバーからの質問への回答
  • How ：作業内容やコードの方向性が期待値通りである

作業をメンバーに依頼することもリーダーの責務の1つです。
チームの時間効率を最大化しチームの生産性をあげていくために、以下の観点で依頼を行います。

  • Why ：プロジェクト・タスクの目的
  • What：タスクの具体的な内容
  • When：いつまでに実施するのか（お客様との取り決め・メンバーのスキルに応じた期待値を伝える）
  • Who ：困ったときに聞く人
    • コーディングをするうえでデザインの質問点はAさん
    • 処理の書き方に困ったらBさん

必要に応じて分類

さて、チームに依頼することがまとまったらいよいよ自分の開発に集中できる時間です。
各案件の自分自身の担当範囲をこなしていく時間になります！

私の場合は提案活動にも参加していますので、提案活動・開発タスクが自分自身のやることになります。
※お客様の課題を直接聞けること、数か月先の案件を見通し売上に責任を持てるとても勉強になる時間です。

おわりに

いかがだったでしょうか？
自分自身も開発をしながらチームをまわす役割を担うようになって、とても時間のバランスがとても難しいと感じる日々を過ごしています。
おなじ悩みを持つ方のヒントに少しでもなれたら嬉しいです。

また次の記事でお会いしましょう👋

GitHubで編集を提案

Discussion