リリース・プランニングでストーリを各イテレーションに割り振った後は,実際にイテレーション内でストーリをタスクに分解して実装していくことになる。この分解する作業を「イテレーション・プランニング」と呼ぶ。TRICHORDチームはイテレーションが週単位なので,月曜日は1日費やしてこのイテレーション・プランニングを実施している。

 イテレーション・プランニングでは,プログラマはストーリ・カードに書かれた内容を顧客から詳細に聞き出し,プログラマがそのストーリを実現するために必要な作業をタスクとして切り出していく。画面レイアウトなどについては,このタイミングで顧客がプログラマに提示して細かい仕様を詰めていくことになる。TRICHORDチームでは,筆者が顧客役となって画面レイアウトや仕様についての詳細を出している。プログラマ,つまり開発チームから疑問点や改善案などが出てきた場合は,その場で議論して指針を決めている。

 ストーリを「結果」とすると,タスクはその結果を実現するための「作業」である。実現したいこと(What)をどのように実現するか(How)を具体化することがタスクを切り出す作業の目的だ。ストーリを実現するために必要な作業はすべてタスクにするのが基本である。「○○さんにアイコンの作成を依頼する」というような,ものの5分で終わるような小さい作業もすべてタスクとして切り出していく。

 タスクはストーリと異なり,見積もりの単位は「時間(Hour)」である。言い換えれば,タスクは時間で見積もれる程度のサイズにまで細かく分割する必要がある。1つのタスクは長くても数時間で終わる程度にまで落とし込む。TRICHORDチームでは,ほとんどのタスクは2~3時間,またはそれ以下の時間で収まる粒度にまで分割している。

 見積もりは当然のことながら,リーダやマネージャではなく,実際に作業するプログラマが見積もる。この時点では,誰がどのタスクを実施するかまでは決まっていない。チームの中で「このくらいで行けそう」な時間を導きだし,タスクの見積もりとする。

 タスクは単にストーリを実現する作業項目を切り出すだけではない。タスクの切り出しは常に「作業の終了条件」を意識しながら行う。タスクのゴールを明確にすることが何よりも重要だ。タスクが「ストーリ(What)をどのように実現するか(How)」であることは先に述べた。しかし,単にHowを抽出していくだけでは終了条件があいまいになりがちである。

 実装系のタスクであれば,「単体テストがすべてパスしていること」という終了条件になるだろう。しかし「Aというライブラリを調査する」というような調査系のタスクを切り出したい場合は,「Aの何をどこまで調べるのか」「調べた結果をどうすれば完了なのか」をプログラマと合意しておく必要がある。そうしないと,プログラマはタスクの終了条件が分からずに迷子になってしまう。こうした場合に終了条件を明確にしておくことは,プログラマにとっても無駄な時間を費やしてしまうのを防ぐ効果があるのだ。タスクの終了条件が,プログラマがどこまで作業すればよいかを判断する際の基準となるためである。

 タスクの中には,正確に時間を見積もれないものもある。新しい技術を使ってプロトタイプを作る場合などがその例だ。そのような場合,TRICHORDチームは「タイム・ボックス」を決めてタスクを実施することにしている。「とりあえず2時間で,できるところまで実施してみる」といった具合に,作業時間を固定して実施するのである。

 タイム・ボックスを決めてタスクを見積もるメリットは,タスクの実施中にいわゆる「ハマった」際の時間を最小限に食い止めることができる点だ。あらかじめ決めた時間の範囲でタスクに取り組み,さらに時間が必要な場合は「どのようにすれば問題が解決できるか」「今までどんな作業をして何にハマっているのか」「さらに時間をかけて続行するべきかどうか」といった見直しや,状況判断をするタイミングが確実に取れるのだ。

 タスクもストーリと同様にすべてカードに書いてから実施する。これをタスク・カードと呼ぶ(図1[拡大表示])。TRICHORDチームでは,ストーリ・カードよりもやや小さいカードを使用して区別できるようにしている。最初はA7の情報カードを使用していたが,最近は大型の単語帳が安く買えるのでそちらを使用している。タスクはストーリと比べて書く内容が少ないので,小さめのカードがよいだろう。


図1 タスクカードの例
タスクはストーリと比べて記述する内容が少ないので,小さめのカードを使用する。

[画像のクリックで拡大表示]

 カードにはストーリの番号,タスクの概要,見積もり時間を記入する。裏は完了日と実績時間を記入するために白紙のままにしておく。プログラマが作業する際に手元に置いておくようにする点も重要だ。タスク・カードを使うことで,ほかの人がプログラマの机を見たときに「何の作業をしているか」が本人に聞かなくても分かるようになる。つまりタスク・カードは,担当している作業を「見える化」するという役割があるのだ。

 さらにタスク・カードは,タスクをアサイン(他人による割り当て)ベースではなく,サインアップ(自分の意思で取る)ベースで作業することを促進させる。カードという目に見えて手で触れる存在にすることで,プログラマは自発的にカードを取ってタスクにコミットメントできるようになる。カードにすることは,単にアナログで扱うだけではなく,タスクに対する姿勢そのものを変えてしまう効果があるのだ。実は,筆者が一番強調しておきたいのがこの点である。次回はこのタスクのサインアップについて取り上げる予定だ。

懸田 剛

チェンジビジョンでプロジェクトの見える化ツール「TRICHORD(トライコード)」の開発を担当。デジタルなハックと,アナログなハックの両方を好む。新しいやり方やツールを考えるのが好きである。個人サイトは http://log.giantech.jp/