SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

“アジャイル”の次へ:IBMの開発プロセス戦略の今(AD)

第5回 ソフトウェア開発にビジネス・インテリジェンスを

“アジャイル”の次へ:IBMの開発プロセス戦略の今(5)

  • X ポスト
  • このエントリーをはてなブックマークに追加

 これまで4回にわたって、開発プロセスを“実現可能なモノ”にするIBM Rationalのプロセス戦略を紹介してきました。最終回となる今回は、IBM Rational Team Concert(以降RTC)のダッシュボードで把握できる内容の説明や、意思決定時の考え方について解説します。

  • X ポスト
  • このエントリーをはてなブックマークに追加

RTCのダッシュボードでなにが分かる?

 前回は、『「定義」から「運営」へ:短期化する改善サイクルそのものと標準化の姿』として、以降RTCのプロセス実行エンジンとしての側面をご紹介しました。その中で、結果や効果を常に意識するということが重要であり、そのための価値トレーサビリティツリー(覚えてますか?)に言及しました。

 RTCは、タスク(RTC用語ではワークアイテム)駆動で開発作業を行うことで、さまざまな情報がリポジトリに管理されます。それらの情報をもとに、分散開発環境においてもチームの活動状況をダッシュボードでリアルタイムに把握することができます。このダッシュボードは、誰かが収集することなく(手間なく)、自動でレポートが表示されます。ブラウザさえあれば、アクセスしたその時のリアルタイムな状況を把握できます。

 では、その肝心な部分、ダッシュボードを見ることで何が分かるのでしょうか?

 これを理解するために、まずダッシュボードにはどのようなレポートが用意されているのか見たいと思います。第2回「ディシプリンド・アジャイル・デリバリーというお作法」で触れたお作法『DADには、実は「なにを測定すべきか?」』も定義されています(図1)。

図1 DAD「測定」の一覧
図1 DAD「測定」の一覧

 これらを一つ一つ見ていくとあることに気づきます。従来の進捗報告書にあるような「xx%の遅れ」とか「遅延タスク一覧」のような、いわば「計画との比較」がほとんどありません。

 計画との比較も重要ですが、DADでは事実(つまり実績)をもとにした傾向をみることをより重要視しています。日々成果物を作成していくソフトウェア開発プロジェクトでは、毎日なんらかのタスクが完了し、未完了タスク数は減少し、文書やソースコードが作成され、例えば障害が発生し、解決されます。多くのプロジェクト実績データが蓄積されていきます。

 DADで定義された測定は、これらをうまく活用しています。そして、RTCのダッシュボードには、図1『DAD「測定」の一覧』にある大部分の測定が定義されています。

 例えば、図2は反復バーンダウン・チャートです。

 これは、横軸に日付、縦軸に残り作業時間をとり、日々減少(増加)していくチームの残り作業時間を日々プロットしています。残り時間が0時間になれば、その期間のすべてのタスクが完了していることになります。

 この傾向(傾き)をみることで「このペースでいくと期限までにすべてのタスクが完了するのか?」という視点でみることができます。

図2 反復バーンダウン・チャート
図2 反復バーンダウン・チャート

 このチャートには、従来の「計画との差異」は一切ありません。「予定から遅れているタスクは?」「どのくらい予定より遅れているのか?」よりも、今のチームの実績に基づいた数値をもとに、このペースで「ちゃんと終わるのか?」という予測の視点でみることができます。

 反復バーンダウン・チャート以外のチャートについても、考え方は同じです。

実績ベースでみる。その本質は?

 この「実績をもとにして予測する」という考え方は、「ソフトウェア開発は複雑でかつプロジェクト見積もり時の前提や要求は変わる。仮に事前にかっちりと決まったとしても、チーム・メンバーやツールによる自動化の効率が変われば生産性は変わる 。結局のところ、ソフトウェア開発の不確実性は完全に排除できない」という背景があります。当然、計画は作成しますが、計画は固定されたものでなく、発展させるものとして捉えます。

 考えてみれば、複雑化するソフトウェアやどんどん出てくる新しい技術、加えてグローバル開発といったソフトウェア開発をとりまく環境を見てみるとそれも当然です。綿密に計画したものの、実際にやってみるとアレもコレも考えないといけない、などという経験はソフトウェア開発をやっていれば、誰もが経験があるはずです。

 DADでの「管理」とは、計画通りに進めることではなく、より良い結果を生み出すために管理者が積極的に関わり頻繁に方向性を修正することを指しています。3つのフェーズ(方向付け、構築、移行)に設けられたチェックポイントにより方向性を修正しますが、その際に、もっとも参考となるのは、(あまりあてにならない計画ではなく)今までのチームの実績です。今のプロジェクトの環境、制約、採用している技術、チーム・メンバーのスキルを踏まえた成果をベースにします。

 冒頭で「ダッシュボードを見ることでなにが分かるのか?」を問いましたが、一言でまとめると「今のプロジェクトにおける将来の予測性を高め、早期にリスクが分かる」ということです。そして、早期に方向性を修正できるようになるのです。

次のページ
管理者層は?

この記事は参考になりましたか?

  • X ポスト
  • このエントリーをはてなブックマークに追加
“アジャイル”の次へ:IBMの開発プロセス戦略の今連載記事一覧

もっと読む

この記事の著者

江木 典之(エギ ノリユキ)

  日本アイ・ビー・エム株式会社 Rational事業部 テクニカルセールス。プログラマ、SE、プロジェクトマネージャーを経験し、現在はポートフォリオ管理エリアのソリューションを中心にセールス活動、導入支援・コンサルティングに従事。ソフトウェア開発にたずさわる人と組織の明るい未来を目指し...

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

【AD】本記事の内容は記事掲載開始時点のものです 企画・制作 株式会社翔泳社

この記事は参考になりましたか?

この記事をシェア

  • X ポスト
  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/6675 2012/07/27 14:00

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング