“コラボラティブである”ために（2/2）

実績データに基づくリアルタイム性と透明性（2）

あまりにタスクやストーリーが多すぎる。

個々のチーム内でのタスクは、チームのメンバー数を多くせず、作るコンポーネントの規模を適切にデザインすれば、管理しきれないほど増大することはないでしょう。しかし、システム全体に対するバックログとなると話は別です。複数の利害関係者から集められた多様なリクエストを、優先順位をつけ、所定のスプリントやリリースで消化できるかどうかは、そもそも優先順位をつけることができるくらいのボリュームか？に強く依存します。

管理者は、そんな細かい話は知りたくない。

はっきりいって、管理者は3－4時間程度で済むタスクが、いまどうなっているか？なんて関心ありません。それよりも、コストと期間の制約の中で役に立つシステムができるかどうかにその力点が置かれます。

ここのアジャイルでの、チームの状態の把握と、管理者が知りたいこととの間にギャップが生じるのです。このギャップを埋めるために、各チームに「管理者が知りたい情報を知らせるためのレポート作業」が、本来のコード開発とはまったく関係なく負担としてのしかかるのです。

これらに対処するためには、単に「センターのデータベースにタスク情報を1元管理する」という対策だけでは不足するのは明らかです。プロジェクトの透明性とリアルタイム性を担保するためには、次のような要素が必要となります。

【要件1】個々の作業者が日々行う作業が登録され、その進行状況が共有され、場合によってはFeed等で周知される。

アジャイルのタスク管理がそのままですね。これが実績データの基礎になります。分散したチームでの共同作業を促進するには、メールやフィードによる通知が、メンバー間の相互作用のトリガーになることも必要です。

実績データに基づくリアルタイム性と透明性（3）

【要件2】実績データから各種のレポーティングが自動生成される。

バーンダウンチャートはその典型的な例ですね。チームメンバーは同じ粒度のタスクを共有する仲間ですから、タスクの状態がいまどうなっているか？によって、チームの状態を共有することができます。

問題は管理者向けに、管理者の視点で必要な情報をどう提示するか？にあります。例えば、タスクやストーリーにかけてきた時間と、要員の工数から、プロジェクトコストの消化状況を把握したいとか、リスクの大小でプロジェクトを比較したいとかいう場合です。

IBMでは、この種の“単純ではないレポーティング”のために、世にいうBI（ビジネスインテリジェンスツール）の技術を導入しています。

【要件3】多すぎる作業内容からリスクに応じたシミュレーションで判断を支援する。

Jazzテクノロジーに基づくIBM Rational Team Concertでは、独自のロジックに基づき、たまりにたまったタスク群の中から、当該期間中に終わらない可能性のある作業を提示してくれます。バーンダウンチャートは、すでに作業に入った実績に基づきますが、それ以前の計画段階で実現可能性リスクを考慮することで、事前にリスクを排除するお手伝いをします。