複雑なドメインに挑むチームのタスク分解実践記

リファインメントとタスク分解の定義

本記事では「リファインメント」と「タスク分解」を区別して扱います。

リファインメント：プロダクトバックログアイテム (PBI) を、次のスプリントに取り込める粒度まで整える活動。要件の明確化や見積もりを通じて、スプリントプランニングで扱える状態（Ready）にする。
タスク分解：スプリントに選ばれたPBIを、実際の作業レベル（コード改修、UI設計、テスト観点など）に細かく落とし込み、スプリントバックログとして確定させる作業。

スクラムガイドに「タスク分解」という言葉は直接出てきませんが、本記事では上記の定義で、リファインメントに加えてタスク分解をチーム全員で行った実践について紹介します。

複雑な金融ドメインと不確実性の壁

こんにちは。CardチームのShunsukeです。私がこのチームに加わってから1年3ヶ月。法人カード「UPSIDER」のWebシステム開発を進める中で、常に 複雑なドメインと技術的負債との格闘 がありました。

プロダクトが扱うのは、eKYCによる本人確認、与信や決済、外貨建て取引、請求・入金、会計・仕訳や税務対応。さらにカード発行や状態管理、ユーザーロールや承認フロー、不正検知といったセキュリティ領域まで。扱う知識の幅は極めて広く、メンバーの経験や前提知識もばらばらです。

新機能開発に加え、改善要望やバグ対応がさまざまな領域で発生するため、１サイクル(２週間)で完結する異なるドメイン知識のタスクが一定数発生します。結果としてリリース計画とスプリント計画がほぼ重なる規模感のプロジェクトです。腰を据えて仕様理解に時間をかけることはできず、短期間でキャッチアップし実装に落とし込む必要がありました。

長期運用により技術的負債が積み重なり、過去の設計や暫定対応で、影響範囲や実装方針を見通すのが難しい状況でした。

結果として、１〜２サイクルで完結するバックログの対応に関して次の２つが特に大きな課題となっていました。

計画フェーズの不確実性

要件の認識が一度で揃わず、スプリント後半で計画が崩れる

実装・テストフェーズの不確実性

技術的負債で影響範囲が見えにくい
実装後に方針が変わる、再実装が発生する
遅延の見通しが属人化している

「短いサイクルで完結すること」と「幅広いドメインを理解すること」、そして「負債を抱えながら前進すること」。この三つの要素がしばしば衝突していました。

原則として1サイクルで完結するプロジェクトでも、見積もりのズレが生じてしまうと次のサイクルに持ち越すこともあります。さらに、期日を約束したバックログが控えているため、小さなズレが積み重なると吸収しきれなくなります。また、フレッシュで集中した状態で仕事に取り組める持続可能な開発環境を実現するためにも、この課題を解消しなければならないと考えていました。

書籍から得たヒントと挑戦のきっかけ

そんな中、EMに紹介されて手に取ったのが、常松祐一氏の「アジャイルプラクティスガイドブックチームで成果を出すための開発技術の実践知」 (翔泳社、2023)でした。

この書籍には机上の理論ではなく、現場に根ざした実践的なプラクティスが整理されており、多くの学びを得ることができました。

特に今回の課題に関連して印象的だったのは、タスクを分解すること自体の重要性、その分解作業をチームで行うことの意義、そして明確な完了基準をチームで共有しながら作ることの大切さの3点です。

また、Roman Pichler 氏も The Product Backlog Refinement Steps の中で、プロダクトオーナーが個人でリファインメントを行うことは機会損失だと述べています。

私たちの場合、1サイクル完結のバックログについてはリファインメントを軽く済ませ、タスク分解は開発者に任せることが多かったのですが、今回はリファインメントに加えてタスク分解までチーム全員でやる、というチャレンジをしてみることにしました。

チーム全員で進めるタスク分解の流れ

実際の進め方としては、まず他チームからの課題やチームとしてやりたいことをもとにPdMとTLでバックログを切り出します。

その後、バックログのおおまかな方針を2人で、場合によりQAも含めた３人で詰めて、一旦アサインを決めます。

そしてQA・PdM・TL、担当エンジニア達が同期的に集まり、具体的なタスク分解と合意形成を進める、という流れです。

このような変化になります。

FigJam を使った全員参加型タスク分解

これまでのリファインメントは、NotionにPdMやPOが要件を書き込み、必要に応じて口頭で補足、エンジニアはそれをもとに詳細を詰め、不明点があれば随時質問する、というものでした。一見効率的に思えるやり方でしたが、複雑なドメインと技術的負債の影響で、どうしても後半に認識のズレやタスクのブレが顕在化していました。

そこで私たちは、新しい流れに基づいて FigJamを使い、全員で1時間だけ集中するタスク分解ステップ を始めました。

全員参加：QA、PdM、TL、担当エンジニア（バックエンド、フロント）が集まる
時間制限：1時間に区切って集中する
アウトプット：完了基準、タスク、スケジュールまでを付箋に落とし込み、一枚の絵にまとめる

進め方

1.ゴール確認：「何を作るのか」の認識を全員で合わせる

2.必要な機能と疑問点・要件の洗い出し：権限制御、API設計、非機能要件などを付箋で整理。これがこのままQA観点になる

3.実装方針のすり合わせ：コードを見ながらバックエンド・フロント双方で合意形成

APIのエンドポイントやスキーマの認識合わせなど、時間に余裕があれば実装者のスキルレベルに合わせてかなり詳細に実装方針を詰める

4.スケジュール感の認識合わせ：付箋ベースでどこまでをいつまでに終わらせるか合意形成

緑色の付箋で上から下にスケジュールを記載

最後に残ったのは、付箋だらけの 1 枚の FigJam ボード。整ってはいませんが、そこにはチーム全員で合意した証跡が残っています。

チームにもたらした変化と気づき

取り組みを始めてから、チームにいくつもの良い変化が生まれました。

レビュー工数が減り、PR は細かな指摘から始まるようになった
QAとエンジニアの一体感が高まり、付箋がそのままテスト観点になった
実際のコードやSQLを確認しながら判断するため、実装を進めてからの手戻りが少なくなった
進捗の確認がチーム全員で解像度高く把握できるようになった

実際の振り返りでも、各々反省点はありつつも、タスク分解の体験そのものを評価する声や、安心感を示す声が挙がりました。

一方で、試した結果全てうまく進んで課題が解決したという綺麗な話ではなく、実は一部のタスク（付箋）は１サイクルに収まらず、次のサイクルにズラすことになりました。

原因は、他チーム間の結合試験で他チームマターの問題が見つかったことと、差し込みの運用対応があったことです。

あらためて振り返ると、「思ってたように進まない」課題の原因は大きく3つに整理できると思います。

1. Planningの不足
a. タスク分解と完了基準十分でない

2. 遂行ケイパビリティの不足
a. 実装への慣れや問題解決力の差

3.外的な要因
a. 関係のない差し込みタスク

他チームの結合試験で見つかった問題による遅延に関しては、１と２が関わっていて、結合試験に向けて他チーム間でもっとはやくチェックポイントとなるタスクを切る、結合試験で問題があることを見越したスケジュール見積もりなどがあります

ただ、タスクが付箋で可視化されていたことで「どこまで終われば最小限成立か」が明確になっていたので、次にずらしても問題ないものを前倒しで調整できたのは大きな成果でした。

大規模開発や知識資産への広がり

大規模プロジェクトへの適用
今回の手法をそのまま大規模プロジェクトに展開するのは難しく、規模や性質に応じたアプローチの使い分けが必要です。今後はプロジェクト特性に合わせて、リファインメントとタスク分解のバランスを最適化していきます。
情報資産の整理
現在は FigJam・Notion・GitHub に情報が分散しており、特に FigJam は検索性の低さから中長期の情報資産として適していません。そのため、今後は GitHub を中心に情報を集約し、合意形成した内容のうち PRD や ADR に相当する部分を Markdown 形式で統合していきます。あわせて、AI を活用した自動化や知識検索の仕組み化も模索していきます。
チームの成長による自然な廃止
最終的には、メンバーが自律的にタスク分解を行い、誰かが不在でも同じ基準で進められる状態を目指します。ドメイン知識の習熟や技術的負債の解消が進めば、詳細な同期的合意に依存しなくても、チーム全体が大きなズレなく進められるようになるはずです。