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

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

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

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

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

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

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

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

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

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