タスク分解が設計になる：アジャイルスプリント管理の実践
はじめに
アジャイル開発を導入したものの、こんな悩みを抱えていませんか？
- スプリント計画通りに進まない
- タスクの粒度がバラバラで進捗が見えづらい
- ディレクターがタスク管理に追われて本質的な仕事ができない
- エンジニアの自律性を高めたいが、どう実現すればいいかわからない
私たちNickel Lab.では、3年間の試行錯誤を経て、これらの問題を解決する仕組みを構築しました。その核心は「タスク細分化が設計そのものになる」という考え方です。
本記事では、実際に運用している具体的な手法と、そこから得られた知見を共有します。
ちなみにこの方法は、AIを使った開発ともシナジーがあります。
私たちのアプローチ：3つの原則
原則1：ストーリーポイントで共通言語を作る
13ポイント = 中堅エンジニアが1日で完了できる量
これを基準にすべてのタスクを見積もります。
重要なのは「自分の作業時間ではない」という点です。
❌ 間違った見積もり：
新人「私は2日かかるから26pt」
ベテラン「私は半日で終わるから6pt」
→ 同じタスクでポイントがバラバラ
✅ 正しい見積もり：
全員「中堅エンジニア基準で13pt」
→ 新人は2日かかっても「13pt消化」
→ ベテランは半日で終わっても「13pt消化」
この設計により：
- 新人：自分の現在地が明確になる（基準の2倍時間がかかる）
- ベテラン：生産性が可視化される（余った時間で追加タスク）
「中堅エンジニア」の定義：
- 知識が不足しておらず、要件を理解できる
- 設計を考えることができる
- 開発に手が止まらない
- 多少のエラーを自己解決できる
- テストを行える
原則2：タスクの3層構造
プロダクト: Todoアプリ
【ディレクターが作成】
エピック: Markdownエディター機能
├─ 機能タスク: UI/UXデザイン
├─ 機能タスク: APIコントローラー
├─ 機能タスク: APIサービス
└─ 機能タスク: 画面開発
【担当者が細分化】子タスクは13pt以内に分解
機能タスク: 画面開発（親、合計13pt）
├─ 子: Figmaデザイン作成（5pt）
├─ 子: Reactコンポーネント実装（8pt）
└─ 子: 状態管理実装（0pt：既存利用）
ディレクターの役割：
- エピック（プロダクトの大機能）を定義
- 機能タスク（エピックを構成する要素）を作成
- ここまで。実装方法は指示しない
担当者の役割：
- 機能タスクを受け取る
- 13pt以内の子タスクに分解
- 各子タスクを実装・テスト・完了
原則3：1タスク1担当者
1つの機能タスクは、1人の担当者が最初から最後まで担当します。
担当範囲：
- 要件の確認
- 設計（子タスクへの分解）
- 実装
- 機能テスト
引き継ぎによる情報ロスがなく、責任が明確になります。
核心：タスク細分化=設計である
ここが最も重要な洞察です。
見積もり可能 = 理解している証明
タスクを細分化して見積もれる = そのタスクのやり方を理解している
逆に言えば：
細分化できない = やり方をわかっていない
そして、自分がわかるまで細分化する過程は、実装方針を決める設計そのものなのです。
従来の開発：
設計書作成 → タスク分解 → 見積もり → 実装
私たちの開発：
タスク細分化 = 設計 = 見積もり
（この過程で実装方針が決まっている）
↓
実装（もう迷わない）
実例：新人とベテランの分解
機能タスク：「ログイン画面の実装」（13pt）
新人Aさんの分解：
細かく分解して理解：
1. 画面レイアウト設計（2pt）
2. HTMLマークアップ（2pt）
3. CSSスタイリング（3pt）
4. バリデーション処理（3pt）
5. API接続（2pt）
6. エラーハンドリング（1pt）
合計：13pt
実際の所要時間：約2日
ベテランBさんの分解：
大きめに分解：
1. 画面実装（バリデーション込み）（8pt）
2. API接続・エラー処理（5pt）
合計：13pt
実際の所要時間：約半日
同じ機能でも：
- 分解の粒度が違う → それぞれの理解度を反映
- 実際の所要時間が違う → スキルの差
- 消化ptは同じ（13pt） → 中堅エンジニア基準
極端な例：gitコミットすら分解できる
新人や未経験者の場合、こんな細かさまで分解することもあります：
機能タスク: 簡単なボタン実装（親、8pt）
├─ 子: ボタンのHTMLを書く（1pt）
├─ 子: CSSでスタイリング（2pt）
├─ 子: クリックイベント実装（3pt）
├─ 子: gitコミットする（1pt）
└─ 子: プルリクエストを作成（1pt）
合計：8pt
これは担当者自身が判断します。ディレクターは「これは1ptで」といった指示はしません。
この細かさが必要な人にとっては、これが理解できるレベルなんです。
責任の逆転：心理的安全性を構造化する
私たちの仕組みでは、責任の所在が明確です。
従来の考え方
担当者がタスクを細分化できない
→ スキル不足
→ 担当者の責任
私たちの考え方
担当者がタスクを細分化できない
→ アサインミス
→ ディレクターの責任
責任の考え方を変えています。
なぜこれが機能するか
1. 「できない」と言いやすくなる
黙っているとディレクターのミスが隠れたままになってしまいます。「できない」は情報提供であり、自己防衛ではありません。
2. 新人でも堂々と質問できる
新人「この機能タスク、どう分解すればいいかわかりません」
ディレクター「ごめん、私のアサインミスだね。一緒に考えよう」
3. ディレクターの成長
メンバーの能力把握精度が上がり、「この人はこのレベルまで分解が必要」を学習していきます。
技術的に不明な場合：リサーチタスク
技術的に未知の領域（新しいライブラリなど）の場合はどうするのでしょうか？
答えは、スプリント計画でディレクターが「リサーチタスク」として分離することです。
当初の計画:
機能タスク「新決済システム導入」
↓ 実装方法が不明と判明
修正後:
リサーチタスク「決済API調査」（13pt）
└─ 次スプリントで実装タスク化
重要な原則：スプリント開始後はタスクを変更しない
リサーチの結果、想定より大規模と判明した場合でも：
- 現スプリントでは追加タスクを作らない
- 次スプリントの計画で対応する
- 例外：クライアント要求など緊急性が高い場合のみ
ディレクターは技術詳細を知らなくてもいい
この仕組みのもう一つの効果は、ディレクターが技術詳細を知らなくてもよいという点です。
ただし、スプリント全体の見積もり感は必須です。
従来のディレクター像
❌ 必要だった能力：
- すべての技術スタックを理解
- 実装方法まで指示できる
- エンジニア出身必須
❌ 作成するタスク例：
「React HooksのuseEffectを使って
APIコールをdebounce処理する」
→ 技術詳細を知らないと書けない
私たちのディレクター
✅ 必要な能力：
- ビジネス要件を理解できる
- 機能を適切な粒度で分割できる
- 品質基準を示せる
- スプリント全体の見積もり感
→「この機能群は半月260ptで完遂できるか」
✅ 作成するタスク例：
「記事エディター機能」
→ ビジネス要件だけでOK
実装判断は担当者に委ねる：
- React使うか、Vue使うか
- どのライブラリを使うか
- パフォーマンス最適化手法
ディレクターは「品質基準」と「スプリント全体のバランス」だけを示します。これはまさにプロダクトマネージャー的な能力であり、ディレクターの本質的な価値です。
ディレクターの時間配分の変化
Before（3年前）：
- タスク細分化・割り振り: 30%
- 進捗管理・調整: 30%
- メンバー管理: 20%
- 本質的な仕事: 20%
After（現在）：
- エピック・機能定義: 20%
- 本質的な仕事: 60% ← ここに集中
- アーキテクチャ設計
- セキュリティ・パフォーマンス
- UX全体の一貫性
- クライアント対応
- 戦略・採用: 20%
タスク管理から解放され、プロジェクト品質を高める仕事に集中できるようになりました。
3年間の運用結果
副次的な効果：評価の透明化
ストーリーポイント消化数が自動的に記録されることで、評価の客観的な指標が得られます。
スプリント終了時（2週間、1人月契約：130pt）：
- Aさん: 130pt消化（計画通り）
- Bさン: 200pt消化（計画の1.5倍）← 高評価
- Cさん: 80pt消化（新人、3ヶ月前は50pt）← 成長が可視化
ベテランの動機づけ：
- 速く終わらせる = より多くのタスク消化 = 評価向上
- 「早く終わると仕事が増えるだけ」問題の解消
新人の成長実感：
- 月次でのpt消化数の推移が明確
- 「基準の2倍かかる」→「1.5倍」→「1.2倍」と成長が数値化
まとめ
3年間の実践を通じて学んだことをまとめます。
1. タスク細分化は設計である
- 見積もりと設計を統合することで、実装前に思考が整理されます
- エンジニアの設計力が自然に向上します
2. 責任の考え方を変えると心理的安全性が生まれる
- 「できない」を言いやすい構造
- 新人でも堂々と質問できる環境
3. ディレクターは本質的な仕事に集中できる
- タスク管理から解放される
- プロジェクト品質の向上に時間を使える
4. 完璧である必要はない
- 抽象的な基準で十分
- タスク間の相対比較ができれば、スプリント全体で十分な精度が得られます
この手法は、特別な才能やツールは必要ありません。必要なのは「タスク分解を設計として捉える」という視点の転換だけです。
Discussion