こんにちは！株式会社うるるでフロントエンドエンジニアをしております大河原と申します！
エンジニア5年目にして、初めてチームのタスク管理を行う機会をいただきました。
4月から12月までの8ヶ月間、5人規模のフロントエンドチームでタスク管理を実践して得た知見を振り返ります。
前置き
- あくまで5人規模のチームで私がタスク管理を行なってみた所感ですので、必ずしも他のチームや大規模開発に当てはまるものではないかもしれません。
- 私自身、マネジメントの専門家ではないため、ベストプラクティスとは異なる部分がある可能性がありますが、一事例としてご覧いただければ幸いです。
実際にやったことと所感（良かった点）
チームが円滑に回るように私が行なった行動と所感をふりかえります。
1. 直列と並列のバランスを意識した進行
- やったこと
- タスクを並列可と直列必須に分類し、後者の比重が増えすぎてアサイン不全に陥らないよう調整しました。具体的には、後続のブロッカーとなる直列タスクを最優先で消化させ、常に並列タスクが着手可能な状態（メンバーの手が空かない状態）を維持しました。
- 所感（良かった点）
- 意図的にボトルネックを先に解消していったことで、「待ち時間」によるプロジェクトの停滞を防ぎ、チーム全体の稼働率を高い水準で保つことができました。
2. 着手前の「依存関係解消」と準備の徹底
- やったこと
- メンバーへのアサイン段階で、未確定仕様の調整やバックエンドの進捗確認など、着手のブロッカーとなる要素を私が先回りして排除しました。
- 所感（良かった点）
- メンバーが実装に入った後に「仕様確認待ちで手が止まる」といった事態が激減しました。結果としてベロシティの予測精度が向上し、メンバーが開発作業そのものに集中できる環境を作れたと感じています。
3. MVPを意識した段階的スコープ管理
- やったこと
- 「リリースに絶対必要な機能（Must）」と「あると良い機能（Want）」を明確に分け、最低限必要な機能から優先的に終わらせるよう順序立てました。
- 所感（良かった点）
- 万が一工数が逼迫した場合でもリリース不可になるリスクを低減できました。また、コア機能が早く完成することでステークホルダーへの早期デモが可能になり、フィードバックを早い段階で得られたのも大きなメリットでした。
4. 期待値ズレを防ぐこまめな確認
- やったこと
- ステークホルダーやPdMに対し、成果物と期待値にズレがないか、こまめに確認の機会を設けるよう調整しました。また、メンバーにも早期の確認出しを促しました。
- 所感（良かった点）
- 開発における最大の工数損失は「手戻り」です。小さな確認を積み重ねたことで、認識齟齬による大幅な手戻りを防ぎ、トータルの工数を最小限に抑えることができました。
5. 機械的ではない「文脈」を考慮したアサイン
- やったこと
- 単に消化ポイント数だけで振り分けるのではなく、各メンバーの得意分野、その機能に関する背景知識、リポジトリの理解度などを考慮してタスクを割り振りました。
- 所感（良かった点）
- 実装に必要な背景文脈を把握しているメンバーが担当することで、仕様確認の手間や設計上の大きな見直しが発生するリスクを排除できました。これが作業効率の安定に大きく寄与したと考えています。
改善点
プロジェクトの安定化に貢献できた一方で、この経験を通して、来期に向けて取り組むべき課題も見えてきました。
プロセスのスケーラビリティ（仕組み化）の確保
- 課題: 現在の「ブロッカー特定」や「アサイン判断」は、体系化されたルールではなく、私の個人の暗黙知やその場の判断に依存している部分が大きいです。このままでは、チーム規模やプロジェクトが拡大した際に管理が追いつかず、機能不全（スケールしない）に陥るリスクがあります。
- 改善: 「誰がやっても同じ品質で管理できる」状態を目指し、属人的な管理からの脱却とタスク管理の仕組み化を進めることが急務だと感じています。
振り返ってみて
-
タスク管理とは単なる作業の割り振りではなく、並列と直列のバランスを見極め、メンバーが止まらずに動ける情報の流れを作ることだと実感しました。
-
振り返ってみると特別なことはしておらず、目的から逆算するというごく当たり前のことばかりです。しかし、この当たり前を徹底して積み重ねることが、プロジェクトを順調に進める上で最も大切なのかもしれません。
-
今後自分がメンバーとして動く際も、今回のような管理視点を持って動くことで、よりチームに貢献できるのではないかと感じています。
引き続き、この学びを活かし、より良いチーム作りを目指して努力していきます。
最後までお読みいただきありがとうございました！