エンタープライズ・アジャイルのキモとなるスケーリング

2015年1月28日(水)
藤井 智弘

前回の軽いおさらいと、構築フェーズのスプリントの終了

一口に「コラボレーション」とは言っても、利害関係者が持つ関心のポイントは、それぞれ異なります。より経営層に近い立場なら「業務が廻るか」「ビジネス的な狙いは?」という視点となり、より開発現場に近ければ「動くかどうか」という観点で開発中の評価を下します。これをより適切に行えるようになるために、要求に階層構造を持ち込んでいることは、前回にご紹介した通りです。

この類いの「分類」を提示すると、「いまリストに追加されたモノは、フィーチャーかストーリーか」といった、分類自体に時間をかけるチームに出くわすことが珍しくありません。もちろん提示された「モノ」が、ビジネス的にどういう意味を持つか(あるいは持たないか)を議論することは大事ですが、化石の分類みたいに「どこに属するか」を延々議論することには意味がありません。皆さんの仕事はシステム開発であり、考古学ではないのです。

要求の分類というのは、定義だけの話ではありません。図1はAgile Managerのダッシュボード機能のスクリーンショットですが、「機能」に対するカバレッジやテーマごとのバーンダウン等で、ともすると大量の情報に埋もれてしまいがちな「自分に関係する要求事項の今のステータス」を、より迅速に把握することができます。

HP Agile Mangerのダッシュボード

図1:HP Agile Mangerのダッシュボード(クリックで拡大)

日々このダッシュボードを横目に開発を進めながら、各イテレーションの終わりには、利害関係者に対してのデモとふりかえりを行います。この点はアジャイル共通のお作法なので、すでに実践されていらっしゃるチームも多いでしょう。

理想的なアジャイルチーム、すなわち利害関係者が少人数か、権限の強いプロダクトオーナーが開発チームと日々密にコラボレーションし、状況をほぼリアルタイムで把握できている場合には、何の問題もありません。しかし、チームの規模が拡大して開発チームとの接点が薄い利害関係者が増えてくると、彼らにとってのイテレーション終了時のデモやふりかえりは、「単発で行われるイベント」のように見えてしまいます。つまり、以前のイテレーションから今に至る連続性が見えづらくなってしまうということです。イテレーションを積み重ねて、アプリケーションが健全に成長しているという結果を、時系列で見ていくことが重要なのです。

そのための手段として、Agile Managerではリリースサマリ(図2)とアプリケーションサマリ(図3)を提供しています。どちらの情報も、Agile Managerと連携するソースコード管理システム(Git等)とCIツール(Jenkinsと、連動する単体テストツールやコードカバレッジツール)から得られた情報をもとにアウトプットの質を可視化する手段です。

HP Agile Managerのリリースサマリ

図2:HP Agile Managerのリリースサマリ(クリックで拡大)

図2にリリースサマリは、各イテレーション(図中の例ではスプリント)でのアウトプット(ストーリーポイントと不具合)と、その質の根拠であるコードカバレッジおよびテスト成功数の比率を時系列に表示します。テスト成功率が高く不具合の件数が少なくても、コードのカバレッジが低ければ、テストそのものが健全には行われていないかもしれません。

アジャイル開発では頻繁にコードに手を入れることになるので、「ある時点での品質の善し悪し」も大事ですが、プロジェクト期間にわたってある一定水準の検証が行われ続ける(そしてそれをパスする)ことが、より重要です。

HP Agile Managerのアプリケーションサマリ

図3:HP Agile Managerのアプリケーションサマリ(クリックで拡大)

図3のアプリケーションサマリは、ある期間(プロジェクトやイテレーション)でのビルドの健全性を示すレポートです。指定された期間でのビルド結果や不具合の情報を総合して、次の4つに分類して表示します(とかいいつつ、サンプルデータを準備する余裕がなかったので、図の例はしょぼいですが…… すみません)。

  1. 安定したビルド
    ビルドの成功率が平均以上であり、未解決の不具合もほとんどありません。
  2. 品質が低いビルド
    ビルドの成功率は平均以上ですが、未解決の不具合が平均を超えています。
  3. 問題があるビルド
    ビルドの失敗率が高く、未解決の不具合も平均を超えています。
  4. 失敗率の高いビルド
    未解決の不具合はほとんどありませんが、ビルドの失敗率が高くなっています。

問題が大きくなってから慌てて対策するのではなく、時系列のデータからトラブルの可能性をいち早くつかまえて問題が小さいうちに対策するというアプローチは、短期開発では決定的に重要です。そしてそのためには、ソースコードの変更履歴やビルドの結果という作業結果の生データから、客観的に把握することがキモになります。

日本ヒューレット・パッカード株式会社

日本アイ・ビー・エム株式会社を経て、現職は日本ヒューレット・パッカード株式会社でHPソフトウェア事業統括 テクニカル・コンサルタントを務める。
いまだ誤解の多い”ちょっと新し目の技術”を、きちんと咀嚼しお伝えして何ぼのこの世界、「アジャイルは品質が…」という若干の誤解に基づく不安にも、きちんと丁寧に答えをだしていこうと思う毎日。

連載バックナンバー

Think ITメルマガ会員登録受付中

Think ITでは、技術情報が詰まったメールマガジン「Think IT Weekly」の配信サービスを提供しています。メルマガ会員登録を済ませれば、メルマガだけでなく、さまざまな限定特典を入手できるようになります。

Think ITメルマガ会員のサービス内容を見る

他にもこの記事が読まれています