5日を超えるタスクを、どう分割していたか
プレイングマネージャーのための、管理しないタスク管理について考えてきた。その仕組みは、ほとんどがシンプルなルールや手法から成り立っている。例えば以下のようなこと。
- タスクは期日ではなくサイズと優先度で管理する
- マネージャー自身でサイズを見積もる
- ガントチャートではなく、カンバンで管理する
それぞれのルール・手法は、その考えや背景を納得できれば、導入は難しくはない。でも一つだけ、やり方を言語化できてない作業がある。それは「サイズが5日を超える場合は、タスクを適切に分割する」こと。以下の記事に書いた。
2026-08-27マネジメントが嫌い。だから、管理しないタスク管理を実現したい。タスク管理が嫌いなプレイングマネージャーが、2年におよぶタスク管理ツールの個人開発で悟った「任せる管理」についての思想。
yamataka.blog
タスクの分割について、これまでの自分の経験を振り返ってみたところ、僕は分割を目的に作業をしていなかったことに気づいた。今回は、この振り返りから、分割に至るまでの作業を整理していきたい。
なお、記事ではいつもの「サービスを運用しながら改善する継続型チーム」を対象にしている。ディレクターやセールスから依頼される要求を、マネージャーがタスク化する。
2026-09-16プロジェクトじゃないのに、プロジェクト管理ツールを使っていたサービスを運用しながら改善し続けるチームは珍しくない。それなのに仕事の見た目がプロジェクトだから、ツールとのミスマッチに気づかない。僕自身がそうだった。yamataka.blog
要求はざっくり「5日以下」「20日以下」「数ヶ月」の3サイズに分けて考えた。
5日以下：分割しない
まず、小規模な要求から。例えば、既存の画面に項目を追加したり、シンプルな機能を開発するような場合。このケースは、マネージャーはほとんど介入しない。サイズだけサクッと見積もって、あとはアサインしたメンバーと、要求の出所であるディレクターやセールスとで、直接やり取りして進めてもらう。
以前の記事で、大きなタスクを丸投げするのは放任、適切に分割することが委任、と書いた。こう書くと「細かく分割する」ほうが良いと感じるかもしれないが、そうではない。むしろ委任できる範囲で、なるべく大きなまとまりで渡したい。メンバーにとっても、裁量があるほうがやりやすいはずだ。なので、4〜5日程度のタスクは、明確な理由が無ければ、あえてタスクをそれ以上分割しない。たとえ、機能が2つあるなど「タスクを分割しやすくても」そこは1タスクとして定義する。
ただし、担当者がチームに入って間もないなど、スキルに不安がある場合は、1〜2日の粒度に切るのも手だ。要は「委任できる範囲で最大限にまとめる」を意図としている。
20日以下：マネージャーが理解して分ける
次に、作業に6〜20日ほどが見込まれる「中規模」な要求について。例えば、新規に複数の画面やバッチ処理を実装するようなケース。このサイズになると、ディレクターからの要求はまだ曖昧な状態である。
実際に僕が経験したシーンを例に挙げてみる。提供してるサービスには、とある事例データXを地図上にプロットして表示する機能があった。ディレクターから「事例データYも同じように見せたい」との要求が上がった。ただ、XとYには一つ大きな違いがあった。Xは1件ずつ正確な位置を持っているが、Yは「この辺り」までしか分からない。同じ「地図上のプロット」でも、Yは点が打てないことから、具体化には考慮すべきことが多くあった。
要求の具体化
まず、このような要求をそのまま「事例データYのプロット表示機能」として担当にアサインした場合、それは「放任」になる。メンバーに任せつつ、状況をコントロールするために、一つの要求を複数のタスクに分割していく。でもこの状態から、いきなりタスクを分割することはできない。なぜなら「マネージャーにとっても、やるべきことが不明確」だから。まずは、要求を具体化していくプロセスが必要になる。以前の記事で「分割するには、まずマネージャーが理解する」と書いたが、このプロセスが理解につながる。
そこで、まずはこの具体化作業だけをタスク化して、プレイングマネージャーである僕自身にアサインした。先に挙げた実例で要求を具体化すると、[A]事例データの検索、[B]プロット表示、[C]詳細表示、3つの機能について検討が必要になった。[A][C]は単純な機能だが、[B]については、地図上でどう見せるか検討が必要だった。検討した結果、[B]は地点ではなくエリアごとにサマリー表示する機能として実装することになった。具体化した内容は、カードにマークダウンとスクリーンショットで書いて、エンジニアに共有した。
このタスクでプレイングマネージャーが担うのは「要求の具体化」で、要件定義のようなドキュメント作成が目的ではない。ディレクターやセールスの言葉（要求）を、システムの言葉（要件と仕様）に置き換える。また、この段階でマネージャーが全ての仕様を定めるのではない。タスクを分割できる程度の具体性に留め、細かい点は実タスクでメンバーが担っていく。
分割する
要件と仕様がある程度定まったら、タスクを分割することができる。マネージャーには、既に大まかな機能も実装もイメージできてるはずだ。そのイメージがあれば、分割は簡単だ。これが冒頭に書いた「分割を目的に作業をしていなかった」になる。要求を具体化するプロセスを経ると、結果として分割された状態になる。
分割は、基本的には「機能単位」で分ける。分割の定石であるが、要件を「層」で区切らず、機能（縦）で区切る。その結果、ディレクターによる動作確認がしやすい粒度になる。
先に挙げた実例では、[A][B][C]それぞれをタスクとする。ただし[B]が複雑なため、要求を具体化してもなお、ディレクターはまだイメージしきれていない部分があった。早めにディレクターとイメージを合わせるために、実装の前段にモック作成のタスクを設けることにした。最終的に、以下のような5件のタスクに分割された。
- マネージャーによる要求の具体化
- UIレベルでのモック作成（ディレクター確認含む）
- [A]の機能実装
- [B]の機能実装
- [C]の機能実装
アサインする
分割したタスクをメンバーにアサインしていく。管理しないタスク管理のために、僕はアサインをなるべく1名に寄せるようにしていた。複数名で並列して進めると、コミュニケーションコストが発生するし、その歪みがマネージャーの管理作業として戻ってくる。上記の[モック][A][B][C]の実装は、全て同じメンバーにアサインし、モック実装時のディレクター調整もメンバーに担ってもらった。
数ヶ月規模：プロジェクトとして扱う
最後に、開発に数ヶ月かかるような大規模なケース。既に運用してるサービスであっても、根本に影響がある変更は、プロジェクト化して数ヶ月かけて進めることもある。規模が大きいので、完了の目標日を定めたり、複数名で実装を担うようになる。
ここでも僕の以前のチームでの実例を挙げる。内容は「ユーザーとの契約フローを変更する」といったものだった。実は、当初ディレクターから要求を聞いた時、セールスによるユーザー調整が大変そうだが、システムとしては大した影響は無さそうに思えた。しかし「要求の具体化」を進めると、システムのオペレーションや請求など、幅広い機能に影響があることが発覚し、具体化だけでも数日以上かかった。
そこで、メンバーにも具体化の作業を担ってもらった。「要求の具体化フェーズにおいても、タスクを分割した」 ことになる。この作業は「マネージャーがタスクを理解する」目的も含まれるので、メンバーのアウトプットを、マネージャーがレビューした。
その後にタスクを分割するが、いきなりカンバンにタスクをカードとして書き起こすと、抜け漏れのリスクがあった。そこでスプレッドシートに、要求ごとの機能と対応内容をWBSのように列挙してから、タスクをカンバンに登録した。要求は既に具体的になっていたので、それをインプットに使うことでタスクの列挙はスムーズにできた。この時点でタスクは43件になり、具体化作業を担った2名のエンジニアで開発を担当することになった。実装するごとにディレクターに動作を確認して調整していったので、途中で不要になって消したタスクもある。
まとめ
振り返ると、タスクの分割だと思っていた作業は、実は要求の具体化だった。具体化すれば、結果として分割できる。それに、要求の規模で分割の仕方が変わると思っていたが、誰が具体化するかの違いだった。
つまり具体化は、要求をシステムの機能につなぐ作業で、結果はそのまま実装のインプットになる。これはマネジメントではなく、エンジニアリングのスキル。マネジメントの判断として求められるのは、どこまで具体化するか。タスクを分割できる程度で止めて、その先はメンバーに委ねる。具体化が浅ければ、後からマネジメントの必要が生じるし、深すぎればメンバーに委ねられなくなる。
これまで分割を言語化できなかったのは、それをマネジメントの作業だと思っていたから。実際にやっていたのは、エンジニアの作業だった。