アジャイル開発の明暗を分ける時間軸の捉え方の違いとは

前回は連載の初回ということで、エンタープライズ・アジャイルの代表的なフレームワークを紹介しました。その中で共通ポイントとして挙げた「しがらみを制御する」という視点を中心に、現場でいただくさまざまな質問を織り交ぜながら、具体的なイメージを共有できればと思います。
さて、プロジェクトの最初にくるのは「計画」なわけですが、その前にこの連載で道具として使うHP Agile Managerの下準備だけしておこうと思います。

下準備：HP Agile Manager ってこんなもの

HP Agile Manager（以下、AGM）は、アジャイルのチーム管理に特化した製品として、以下に挙げる機能を提供しています（図1）。

• バックログ管理
  テーマやストーリーなどを管理する、アジャイル開発ではおなじみの機能。
• リリースやスプリントの管理
  タスクボードやカンバンもあります。
• 不具合の管理
  不具合情報を管理します。HP Quality Centerなどを用いて、すでにテストや不具合を管理されている場合には同期することもできます。
• チームの管理
  メンバーやチーム、作業負荷などの管理ができます。
• トレーサビリティ管理
  SubversionやGit、Jenkinsなどと連携して、情報を一元管理できます。また、それらの情報とストーリーや不具合を関連づけて、トレーサビリティを管理できます。

HP Agile Managerの実行画面

AGMはSaaS版とオンプレミス版（＝お客様環境の中に構築するバージョン）が提供されていますが、今回はSaaSの評価版を使って手軽に始めましょう。
評価版の利用手順を長々とここに書いてしまうと「単なるページ稼ぎ」と編集部に怒られちゃいますから、HPのブログのほうにアップしておきますので、各自準備してください。

では、準備が済んだという前提で話を進めていきましょう。まずは全体計画を考える際の基本である、時間軸の考え方から始めます。

「プロジェクト」とアジャイル的な時間軸

「プロジェクトはどこで設定するのですか？」
AGMを使われたお客様から、最初にくる質問の一つがこれです。AGMの中には「プロジェクト」という表現がほとんど見られません。ここに、単にツールの機能の話ではない、「アジャイル屋さんの時間軸の捉え方の違い」を見ることができます。この違いを表現したものが、図2です。

これまでのソフトウェア開発では、「プロジェクト」という単位で仕事が区切られてきました。何らかのロジックで予算が決められ、開始と終了（サービスインや納品）が明確に決められた作業の単位です。もちろん「終了」とはいっても「引き続きの第2期開発」というように継続するシナリオはありますが、「予定された機能がどかーんとリリースされて『終了』」と明確に意識されていることが多いと思います。
それに対して昨今のアジャイル開発（特にリーン開発の色が強いと）では、短期間で小刻みにリリースし続けるというふうに時間軸を捉えます。サービス提供の土台となるシステム自体（AGMではこれを「アプリケーション」と呼んでいます）は、ある期間にわたって稼働し続けていて、その上で小規模な単位でサービスを短期間でリリースし続けるという捉え方をします。つまり従来の「プロジェクト」の意識と比べると、終了のイメージが明確ではありません。
アジャイル屋さんからすると違和感のないこの見方も、ユーザ部門に理解してもらうには一苦労な点となります。「予算の区切りがはっきりしない」「いつできあがるのかわからない」といったクレームを言われることも珍しくありません。
「しがらみを制御」するポイントの一つは、プロジェクトの進め方とその中での利害関係者のふるまい方について、事前に同意を取っておくことです。

もう少しだけ時間軸の話

前回の記事で、「スケールド・アジャイル・フレームワーク（Scaled Agile Framework：SAFe）」と「ディシプリンド・アジャイル・デリバリー（Disciplined Agile Delivery、以下DAD）フレームワーク」という2つのフレームワークを簡単に紹介しました。この連載ではDADをベースに話を進めることにした一番の理由は、「DADがプロジェクトという単位でものを見ており、従来のプロジェクト視点を持った人達が手を出しやすい」という点です。こう書くと、前述のようなリーン的アプローチを否定しているかのように取られてしまいますが、そうではありません。
DADは自らを「意志決定のフレームワーク」と位置付けていますが、組織の置かれた状況（ビジネス状況や技術への成熟度）に応じて、その判断材料やメリット／デメリットが異なるのは、前回ご紹介した通りです。DADでは、開発組織の成熟度が高まれば、リーン型へ移行していくのは自然なことだと捉えています。つまり「従来型のやり方」→「プロジェクトベースで運営されるアジャイル」→「アジャイル／リーン」という段階があるという見方をしています。

さて、DADの特徴的な時間軸の見方は、「フェーズ」という概念です。
DADの基本モデルでは3つのフェーズを提唱しています。

DADの基本モデル

方向付け（Inception）フェーズ

プロジェクトとしての実現可能性を踏まえたうえで、「何に対して投資するのか」について利害関係者との合意を取り付け、開発に必要な準備を完了させる時期です。
アジャイル開発では「変化には積極的に対応する」というポリシーがありますが、さりとてなんでもかんでも受け入れていては､いつまでたっても収束しません。このフェーズで合意された目的が、後続の構築フェーズでの変更依頼を受けるか否かを判断するベースになります。

構築（Construction）フェーズ

対象のプロダクトを開発するフェーズです。このフェーズの運営はスクラム＋XPをベースとした、よく知られた「アジャイル開発そのもの」となります。

移行（Transition）フェーズ

開発されたプロダクトは、本番環境でいきなり稼働させても使えない場合があります。本番稼働後、プロダクトがきちんと稼働するためには、ユーザに対する利用者教育や既存のデータを新システムに移行するといった事前準備が必要な場合があります。それを行うのが、このフェーズです。

DADでは、これらのフェーズそれぞれに対して典型的なゴールを設定しています。最終ゴールにむけて中間ゴールを設定し、それをクリアしていくことで方向性がぶれないように確認しつつ進められるようにします。また同時に、それらのゴールを達成するやり方は、当該チームの状況に応じていろいろなバリエーションがありうるので、チームが適切なものを選択するという前提を設けます。DADには、その選択を助けるためのさまざまなガイドが記述されているのです。

全体計画の前にやっておきたい「オリエンテーション」

プロジェクトに固有の事情を加味して、各フェーズでのゴールを決めていく。それがDADにおける全体計画の第一歩なのですが、なかなかどうして、そう簡単には進みません。日々お客様に接していると、次のような状況を目にすることが珍しくありません。

• 社内の開発案件は、ほとんどが既存システムの保守
  「業務サイドの要件」とはいっても既存システムへの改修要望なので、きわめて具体的かつ詳細になり、システムの要件と業務の要件との間を区別して考えられていない。
• 「安くて速い」というイメージのみで根拠なくアジャイルに期待している
  当然、最初に要件をどさっと出せば、最後にできてくると考えている。頻繁にコミュニケーションするなんて業務の邪魔だと思っている。
• アジャイルは変更に強いんだから最初はいい加減に決めて、後からいつでも変えればいいだろう、という程度の認識
• 変化に強いなんていったら際限がなくなるから、ユーザ部門と話をしたがらない。

このように「目の前のプロジェクトをどうやって進めていくか？」を相談する場で、それ以前の認識の相違で話が先に進まないという例はよく見られます。

そこで最近では、プロジェクトの正式スタートに先だって、「プロジェクト・オリエンテーション」（←個人的にこう呼んでます）の時間を設けることをお奨めしています。プロジェクト・オリエンテーションの目的は、ひとことで言うと「自分達がアジャイル開発を採用するのはなぜか？」について共通の理解を作り上げることです。これは、ベンダーやコンサルによる「アジャイル開発とは？」という一般論説明と、「このプロジェクトの計画では…」という目の前のプロジェクト運営との間を埋めてつなぐ作業と言えます。
前述したようなプロジェクトの時間軸一つとってもこれまでとは異なる見方が存在します。「ユーザさんと同じ場所で開発作業を…」とはよく言われますが、かといってユーザの代表者が頻繁に時間を取られると、その代表者は上司から「仕事しろよ」と言われかねません。
そもそも「ビジネスの立場で要件を考える」なんて習慣がなければ、何を基準にストーリーの優先順位を付ければ良いのでしょうか？
アジャイル開発は、開発者だけでなく、ユーザ側にもそれなりの負担が発生します（もっとも、これまでもやらねばならなかったことが、当たり前にかつ今まで以上に要求されるというだけのことですが）。ユーザ側の担当者はその周囲に理解を求めなければならないでしょう。ですから、その変化が自分達にとってなぜ必要なのかを、着手前にきちんと議論しておくことが重要なのです。　
参考までに、某社で実施したオリエンテーション・セッションのアジェンダと論点を、以下に挙げておきます。

• アジャイル開発の一般論の説明
• 適用プロジェクトにおける、アジャイルへの期待値の確認
  いわゆるネット系のサービスであれば、単なる機能性だけでなく使い勝手なども重要な差別化要素になるので、頻繁にリリースしフィードバックを取り込む手段としてのアジャイル開発は理解されやすいでしょう。しかし社内システムであれば、それほど使い勝手に神経質になることもなければ、そもそも頻繁にリリースする必要がないかもしれません。その一方、既存の他のシステムとの連携が不可避になるので、短期間のスプリントで頻繁に統合されテストされるという進め方には、技術的なリスクを排除するうえで大きな効果が期待できます。
  このように、「ビジネスの変化に対応したあじりてぃー」という大雑把な話ではなく、目の前のプロジェクトの特性を考慮して、アジャイルの何に期待するのかを合意する時間です。極論すれば、この時に明確な位置付けができないのであれば、「アジャイルを採用しない」という選択肢も当然ありえます。
• これまでのプロジェクトへの関わり方とアジャイルでの関わり方の違いを確認
  アジャイルでは、頻繁に状況に合わせた意志決定を積み重ねていきます。「持ち帰って来週返事します」のような時間感覚では、到底太刀打ちできません。その時々に適切な判断を下せて、かつ周囲を説得できるだけの担当者を引き込むことが重要です。往々にしてそういう人は「忙しい」ので、アジャイルの一般論でのコミュニケーションのあり方は理解しつつ、場合によっては担当者の交代も視野にいれた「このプロジェクトではどうするか？」を議論します。

言葉を変えると、このオリエンテーションの目的は「アジャイルを使うのなら、キチンと理解して覚悟を決めよう」ということです。ユーザ側はこれまでと同じ、開発者はアジャイル開発という、いわゆる「日本的なアジャイル」などという「ごまかし」は、ユーザ側、開発側ともに成長の機会を阻害するだけです。

次回からはツールも使って…

ということで、次回からはツールも使って、フェーズの計画と要求の管理について話を進めていこうと思います。ツールの準備もお忘れなく。