RTCのダッシュボードでなにが分かる？
前回は、『「定義」から「運営」へ：短期化する改善サイクルそのものと標準化の姿』として、以降RTCのプロセス実行エンジンとしての側面をご紹介しました。その中で、結果や効果を常に意識するということが重要であり、そのための価値トレーサビリティツリー（覚えてますか？）に言及しました。
RTCは、タスク（RTC用語ではワークアイテム）駆動で開発作業を行うことで、さまざまな情報がリポジトリに管理されます。それらの情報をもとに、分散開発環境においてもチームの活動状況をダッシュボードでリアルタイムに把握することができます。このダッシュボードは、誰かが収集することなく（手間なく）、自動でレポートが表示されます。ブラウザさえあれば、アクセスしたその時のリアルタイムな状況を把握できます。
では、その肝心な部分、ダッシュボードを見ることで何が分かるのでしょうか？
これを理解するために、まずダッシュボードにはどのようなレポートが用意されているのか見たいと思います。第2回「ディシプリンド・アジャイル・デリバリーというお作法」で触れたお作法『DADには、実は「なにを測定すべきか？」』も定義されています（図1）。
これらを一つ一つ見ていくとあることに気づきます。従来の進捗報告書にあるような「xx％の遅れ」とか「遅延タスク一覧」のような、いわば「計画との比較」がほとんどありません。
計画との比較も重要ですが、DADでは事実（つまり実績）をもとにした傾向をみることをより重要視しています。日々成果物を作成していくソフトウェア開発プロジェクトでは、毎日なんらかのタスクが完了し、未完了タスク数は減少し、文書やソースコードが作成され、例えば障害が発生し、解決されます。多くのプロジェクト実績データが蓄積されていきます。
DADで定義された測定は、これらをうまく活用しています。そして、RTCのダッシュボードには、図1『DAD「測定」の一覧』にある大部分の測定が定義されています。
例えば、図2は反復バーンダウン・チャートです。
これは、横軸に日付、縦軸に残り作業時間をとり、日々減少（増加）していくチームの残り作業時間を日々プロットしています。残り時間が0時間になれば、その期間のすべてのタスクが完了していることになります。
この傾向（傾き）をみることで「このペースでいくと期限までにすべてのタスクが完了するのか？」という視点でみることができます。
このチャートには、従来の「計画との差異」は一切ありません。「予定から遅れているタスクは？」「どのくらい予定より遅れているのか？」よりも、今のチームの実績に基づいた数値をもとに、このペースで「ちゃんと終わるのか？」という予測の視点でみることができます。
反復バーンダウン・チャート以外のチャートについても、考え方は同じです。
実績ベースでみる。その本質は？
この「実績をもとにして予測する」という考え方は、「ソフトウェア開発は複雑でかつプロジェクト見積もり時の前提や要求は変わる。仮に事前にかっちりと決まったとしても、チーム・メンバーやツールによる自動化の効率が変われば生産性は変わる 。結局のところ、ソフトウェア開発の不確実性は完全に排除できない」という背景があります。当然、計画は作成しますが、計画は固定されたものでなく、発展させるものとして捉えます。
考えてみれば、複雑化するソフトウェアやどんどん出てくる新しい技術、加えてグローバル開発といったソフトウェア開発をとりまく環境を見てみるとそれも当然です。綿密に計画したものの、実際にやってみるとアレもコレも考えないといけない、などという経験はソフトウェア開発をやっていれば、誰もが経験があるはずです。
DADでの「管理」とは、計画通りに進めることではなく、より良い結果を生み出すために管理者が積極的に関わり頻繁に方向性を修正することを指しています。3つのフェーズ（方向付け、構築、移行）に設けられたチェックポイントにより方向性を修正しますが、その際に、もっとも参考となるのは、（あまりあてにならない計画ではなく）今までのチームの実績です。今のプロジェクトの環境、制約、採用している技術、チーム・メンバーのスキルを踏まえた成果をベースにします。
冒頭で「ダッシュボードを見ることでなにが分かるのか？」を問いましたが、一言でまとめると「今のプロジェクトにおける将来の予測性を高め、早期にリスクが分かる」ということです。そして、早期に方向性を修正できるようになるのです。
