ID:84071さん

当時はリーダー職ではない立場から、5名チームのスケジュール・進捗管理を自発的に担当していました。この取り組みが評価され、2026年8月の組織変更（チーム統合）を機に、13名規模となった新チームの正式なチームリーダーに就任し、現在はチーム全体の進捗管理・工数調整・メンバー間連携の統括を担っています。

各メンバーが自分のタスクと優先度を常に把握でき、複数案件が期日通りに進行している状態を維持することが責務でした。具体的には、全案件の期日・依存関係・担当者が可視化され誰でも現状を把握できること、ボトルネックとなるタスクが早期に特定され担当者間で作業分散や優先度調整が行われること、PM不在時や突発的な割り込みが発生してもチームが自律的に判断・対応できることを目指していました。統合直後の現在は、①業務範囲が異なる2チームが互いの領域を担えるよう、まず保守・問い合わせ対応など負荷の軽い業務から段階的に広げること、②チームごとに異なる文化やタスクの進め方の違いでメンバー間に摩擦が起きないよう調整すること、③タスク管理の粒度・依存関係の可視化を13名規模向けに再設計すること、を新たな責務として計画段階で進めています。

### 背景・きっかけ チームはSaaSプロダクトの保守対応と受注案件の開発を並行して担っていましたが、マネージャーやチームがスケジュール管理に課題を感じており、メンバーの負荷が偏りやすい状況が続いていました。正式なリーダー職ではありませんでしたが、状況を改善できると判断し、自発的にスケジュール管理を引き受けることにしました。 ### 課題の特定 管理を始めるにあたって現状を整理したところ、根本的な問題が見えてきました。 **保守工数がスケジュールに含まれていなかった** チームの業務は大きく「受注案件の開発」と「保守対応（問い合わせ・インシデント対応）」の2種類でしたが、スケジュールには受注案件の工数しか計上されていませんでした。保守対応は「なんとなく」こなしていた状態で、工数として明示されていなかったのです。 保守対応が含まれていなかった理由は明確で、問い合わせ件数が時期によって大きく変動するためです。多い時期もあれば、ほぼゼロの時期もある。この変動の大きさが「工数として出しにくい」という認識につながり、結果として受注案件だけで工数が組まれる状態が続いていました。 この構造が招いていた問題は以下の通りです。 - 保守対応が発生するたびに受注案件の工数を圧迫し、スケジュールが後ろ倒しになる - メンバーが受注案件と保守対応を同時に抱え、負荷が見えにくくなる - スケジュールの遅延が直前まで見えず、対処が後手に回る ### アプローチと工夫 **保守工数を「最低限のバッファ」として明示化する** 変動が大きいからといって工数をゼロにするのは誤りだと判断しました。「平均的に最低これだけは発生する」というミニマムの工数を定義し、それをスケジュールに必ず組み込む方式に変えることを提案しました。 具体的には、過去の保守対応の傾向をもとに「週あたりの最低保守工数」を設定。この数字をマネージャー・リーダーに説明し、合意を取った上でスケジュールの前提として組み込みました。 **受注工数は保守バッファを引いた残りで計算する** 保守工数を確保した上で、残りのキャパシティに対して受注案件の工数を割り当てる順序に変更しました。それまでは受注案件ありきで工数を組んでいたため、保守対応が発生するたびに詰まっていましたが、順序を逆にすることでバッファが機能するようになりました。 **ClickUpで全体を可視化する** 各メンバーのタスクと工数・期日をClickUp上で管理し、週次でチーム全員が現状を確認できる場を設けました。誰がどの案件にどれだけ工数を使っているかを可視化することで、負荷の偏りをリアルタイムで把握できるようにしました。 ### 結果と学び 保守バッファの導入により、スケジュールが実態に即した形で組まれるようになり、受注案件の遅延が減少しました。また、メンバーの負荷状況が数字として見えるようになったことで、作業の分散提案もしやすくなりました。 この一連の取り組みが評価され、2026年8月の組織変更（チーム統合）を機に、正式なチームリーダーとして13名規模のチームを任されることになりました。 この経験を通じて、「見えていない工数を可視化することがスケジュール管理の本質」だと学びました。問題が起きてから対処するのではなく、構造的な課題を特定して仕組みで解決するアプローチは、その後のインシデント対応やプロジェクト管理、そして現在の13名チームのマネジメントにも活きています。 ### 5名→13名で変わったこと（タスク管理の再設計・検討中） 5名チーム時代に機能していた仕組みを、そのまま13名に適用しても機能しないと考えています。人数が増えたことで、量だけでなく質的に異なる問題が発生すると想定しており、以下の観点で再設計を検討しています。 | 観点 | 5名の頃 | 13名で起きる問題 | |---|---|---| | 粒度 | 全タスクをリーダー1人が把握できた | 1人で全タスクを追うのは非現実的。委譲が必要になる | | 依存関係 | ほぼ全員が頭の中で把握できた | 統合前の2チームをまたぐタスクの依存関係が見えにくい | | 週次共有会 | 5人なら全員が発言・状況共有できた | 13人だと発言時間が減り、形骸化しやすい | | 保守バッファ | 1チーム分の実績値で設定できた | 統合前の2チームは保守対応の対象システム・傾向が異なり、単純合算では機能しない可能性がある | 検討している打ち手： 1. サブチーム単位での管理に切り替える：13名全員をフラットに管理するのではなく、統合前の2チーム（または機能単位）をサブグループとして残し、各サブグループの状況を先に集約してからリーダーが全体を見る、という2階層構造にする 2. チームをまたぐ依存関係だけ別枠で可視化する：ClickUp上で「サブチーム内で完結するタスク」と「チームをまたぐタスク」を区別し、後者だけ重点的に追う。全部を同じ粒度で見ようとしない 3. 保守バッファを実績ベースで再設定する：統合前の2チームそれぞれの過去の保守対応傾向を合算し、暫定バッファを設定。運用しながら数値を調整する（5名時代と同じく「まずは仮の数字を置いて回しながら直す」アプローチを踏襲） 4. 共有の頻度・形を分ける：週次の全体同期に加えて、日々の状況は非同期（Slack/ClickUpのステータス更新）で拾う。全員参加の会議に情報集約を頼らない 5名チーム時代に学んだ「見えていない工数・違いを可視化することがスケジュール管理の本質」という考え方は変わりませんが、13名規模では可視化の"やり方"自体を見直す必要がある、というのが現時点での認識です。 ### 現在の役割（2026年8月〜） - 役職：チームリーダー（正式な役職として任命） - チーム規模：13名（元の5名チーム＋組織変更で統合された別チーム） - 任命の経緯：5名チーム時代の自発的なスケジュール管理・課題解決の実績が評価されたことに加え、組織変更によるチーム統合のタイミングが重なった - 現在取り組んでいること（計画段階）： - 業務範囲の相互乗り入れ：統合前の2チームは業務範囲が異なっていたため、まずは保守対応・問い合わせ対応など負荷の軽い業務から着手し、段階的にお互いの領域を担えるメンバーを増やしていく計画 - チーム文化の摩擦の予防：チームごとにタスクの進め方や文化に違いがあるため、統合によってメンバー間に摩擦が生じないよう、進め方のすり合わせを進めている - タスク管理の再設計：上記「5名→13名で変わったこと」の通り、サブチーム単位での管理・依存関係の可視化・保守バッファの再設定などを検討中 正式にチームリーダーとなってからまだ日が浅く、上記はいずれも計画・着手段階です。5名チーム時代に培った「見えていない工数・違いを可視化して仕組みで解決する」アプローチを、規模と多様性が増した現在のチームにも応用していく段階にあります。