RTCのダッシュボードでなにが分かる？
前回は、『「定義」から「運営」へ：短期化する改善サイクルそのものと標準化の姿』として、以降RTCのプロセス実行エンジンとしての側面をご紹介しました。その中で、結果や効果を常に意識するということが重要であり、そのための価値トレーサビリティツリー（覚えてますか？）に言及しました。
RTCは、タスク（RTC用語ではワークアイテム）駆動で開発作業を行うことで、さまざまな情報がリポジトリに管理されます。それらの情報をもとに、分散開発環境においてもチームの活動状況をダッシュボードでリアルタイムに把握することができます。このダッシュボードは、誰かが収集することなく（手間なく）、自動でレポートが表示されます。ブラウザさえあれば、アクセスしたその時のリアルタイムな状況を把握できます。
では、その肝心な部分、ダッシュボードを見ることで何が分かるのでしょうか？
これを理解するために、まずダッシュボードにはどのようなレポートが用意されているのか見たいと思います。第2回「ディシプリンド・アジャイル・デリバリーというお作法」で触れたお作法『DADには、実は「なにを測定すべきか？」』も定義されています（図1）。
これらを一つ一つ見ていくとあることに気づきます。従来の進捗報告書にあるような「xx％の遅れ」とか「遅延タスク一覧」のような、いわば「計画との比較」がほとんどありません。
計画との比較も重要ですが、DADでは事実（つまり実績）をもとにした傾向をみることをより重要視しています。日々成果物を作成していくソフトウェア開発プロジェクトでは、毎日なんらかのタスクが完了し、未完了タスク数は減少し、文書やソースコードが作成され、例えば障害が発生し、解決されます。多くのプロジェクト実績データが蓄積されていきます。
DADで定義された測定は、これらをうまく活用しています。そして、RTCのダッシュボードには、図1『DAD「測定」の一覧』にある大部分の測定が定義されています。
例えば、図2は反復バーンダウン・チャートです。
これは、横軸に日付、縦軸に残り作業時間をとり、日々減少（増加）していくチームの残り作業時間を日々プロットしています。残り時間が0時間になれば、その期間のすべてのタスクが完了していることになります。
この傾向（傾き）をみることで「このペースでいくと期限までにすべてのタスクが完了するのか？」という視点でみることができます。
このチャートには、従来の「計画との差異」は一切ありません。「予定から遅れているタスクは？」「どのくらい予定より遅れているのか？」よりも、今のチームの実績に基づいた数値をもとに、このペースで「ちゃんと終わるのか？」という予測の視点でみることができます。
反復バーンダウン・チャート以外のチャートについても、考え方は同じです。
実績ベースでみる。その本質は？
この「実績をもとにして予測する」という考え方は、「ソフトウェア開発は複雑でかつプロジェクト見積もり時の前提や要求は変わる。仮に事前にかっちりと決まったとしても、チーム・メンバーやツールによる自動化の効率が変われば生産性は変わる 。結局のところ、ソフトウェア開発の不確実性は完全に排除できない」という背景があります。当然、計画は作成しますが、計画は固定されたものでなく、発展させるものとして捉えます。
考えてみれば、複雑化するソフトウェアやどんどん出てくる新しい技術、加えてグローバル開発といったソフトウェア開発をとりまく環境を見てみるとそれも当然です。綿密に計画したものの、実際にやってみるとアレもコレも考えないといけない、などという経験はソフトウェア開発をやっていれば、誰もが経験があるはずです。
DADでの「管理」とは、計画通りに進めることではなく、より良い結果を生み出すために管理者が積極的に関わり頻繁に方向性を修正することを指しています。3つのフェーズ（方向付け、構築、移行）に設けられたチェックポイントにより方向性を修正しますが、その際に、もっとも参考となるのは、（あまりあてにならない計画ではなく）今までのチームの実績です。今のプロジェクトの環境、制約、採用している技術、チーム・メンバーのスキルを踏まえた成果をベースにします。
冒頭で「ダッシュボードを見ることでなにが分かるのか？」を問いましたが、一言でまとめると「今のプロジェクトにおける将来の予測性を高め、早期にリスクが分かる」ということです。そして、早期に方向性を修正できるようになるのです。
管理者層は？
私はIT部門の管理者層（IT部門長などの組織管理者、プロジェクト・マネジメント・オフィスなど）の方と話しをする機会が多くあります。複数のプロジェクトをまとめてみる立場の管理者層の方は、以下のような悩みを持たれているケースが多いです。
- たくさんあるプロジェクトの中で、結局どのプロジェクトに問題があるのか分からない
- 問題に気づいたときには手遅れになっているケースがある
例えば、管理者層がつぶさに各チームのダッシュボードをみる、もしくは各チームで毎朝行われるスタンドアップミーティングなどに参加してヒアリングすれば解決されるかもしれません。しかし、プロジェクトはたくさんあり、そもそも管理者層は多忙です。
さらにお話を伺うと、以下のような方法（図3）で報告を受けているケースが一般的です。
マネジメントへの報告のために、まずプロジェクト・メンバーからの報告をPMがとりまとめ、さらにPMOなどがそれをとりまとめ全体報告を作成します。
とりまとめと報告が何層にも及んでいます。プロジェクト・メンバーの報告から全体報告までに1週間～2週間はかかっています。
手作業でのとりまとめによる間違いも起こるし、報告内容の「いわゆる調整」も入るかもしれません。これでは、2週間前の情報で判断することになり、そもそも正しくない情報によって判断せざるをえません。
管理者層は、組織としての目標を達成する、リスクを察知して早期に対応する、場合によってはプロジェクトを早期に中止して費用の浪費を抑えるといった対応をとりますが、そのためには、正しい情報に基づいて、「一目」ですぐに「結局どのプロジェクトに問題があるの？」に気づけることがなにより重要です。
管理者層を支える開発インテリジェンス
各プロジェクトの細かく大量な実績データ（タスク、障害、課題、ソースコード、テストケースなど）をもとに、意思決定できる情報に変える。切り口を変えて分析する。この考え方は、膨大な業務データをもとに経営面での意思決定を支援するビジネス・インテリジェンスの考え方と同様です。ビジネス・インテリジェンスのコンセプトをソフトウェア開発に適用するという意味で、Rationalではこの考え方と仕組みを「開発インテリジェンス」と呼んでいます（図4）。
この仕組みでは、人手を介することなくプロジェクトで使用しているRTCなどのツールから直接データを取得し、データウェアハウスに取り込みます。そのデータをビジネス・インテリジェンス・ツールのレポート・エンジンにより意思決定のできるレポートとして表示し、必要に応じて問題のあるプロジェクトを掘り下げて分析します（図5）。
この仕組みにより、開発者は普段の開発作業を行い、RTCのダッシュボードによってプロジェクトの予測性が高められる一方で、管理者層はクリアな定量的データをもとにした開発インテリジェンスにより、一目で問題に気づき、原因の分析ができるのです。
そして継続的改善へ
そろそろこの連載も終わりに近づいてきました。
第1回で、RUP（IBMプラクティス・ライブラリ）は『「開発プロセス」から「開発組織のためのプロセス」』へ進化しているという話がありました（未読の方はこの際にぜひ！）。
プロセスは、決めること自体に意味はなく、適用されて効果がでて初めて価値があります。クイックにプロセスを定義し、適用し、展開して、これを繰り返すことで継続的な改善につながります。
効果をどのようにみるか。開発インテリジェンスの仕組みにはあらゆるデータが蓄積されているため、これもまたクイックに効果をみることができます。
IBMプラクティス・ライブラリでは、プラクティスと測定をマッピングして体系化し、適用するプラクティスと効果測定がセットで定義されていますが、Rational Insightには、この測定レポートがあらかじめ含まれています。
開発インテリジェンスの仕組みを使用することで、効果を測るために新たな運用や作業、測定の仕組みを変えることなく効果をみることができるのです。
少々手前味噌ですが、IBM Rationalは組織改善のためのノウハウとその仕組みをもっています。
多くのお客様のプロセス改善をお手伝いしてきた経験に加え、自らそのプラクティスを実践しツールを使用し組織を変革することで、IBMプラクティス・ライブラリ自体もツールもRationalの組織自身も進化しています。今、変革を求められる方々にとって、これらのソリューションが少しでもお役に立てればこれほど嬉しいことはありません。
お付き合いいただきありがとうございました。
