アジャイルコーチが見た開発現場～初めてのアジャイルでつまづく12のポイント～【プロジェクト立ち上げ時①】

私がアジャイルプロジェクトに参画するタイミングは、これからプロジェクトをたちあげようとしている時になります。計画づくりや要員育成を手伝ってほしいという要望を受けての参画となりますが、このタイミングで既に要件定義の作成に着手されている場合があります。

そこで作成されている資料を見せていただくと、「まだ出来上がっていませんが」という前提を付けた上で、ウォーターフォールで作られる機能一覧や非機能要件一覧、画面遷移図といったものが出てきます。

これらの資料は要件を固めるために有効な資料ではあるのですが、アジャイルではそのまま使うことが難しい資料です。そしてウォーターフォールのアプローチでアジャイルの要件定義で行うと「終わらない」「書けない」「わからない」という悩みの種が噴出することになります。

いったいなぜなのか？その答えをみつけるために、改めてウォーターフォールとアジャイルの要件定義の違いを考えてみましょう。

図１：ウォーターフォールとアジャイルの要件定義比較

両者を見比べてみると、そもそも目指している完成形が異なることがわかります。
ウォーターフォールにおける要件定義とは、あいまいさを排除し、必要な機能を漏れなく明確に定義した将来形を描くことにあります。
一方のアジャイルは、変化の激しい環境では将来の完成形を明確に描くことは困難であることを念頭に、本当に必要なものやコアとなる機能を定義し、それ以外については可能な範囲での定義にとどめることとしています。このようにすることで、その後の変化に対応できる状態を作り出しているのです。

さて、それでは本題に戻りますが、ウォーターフォールのスタイルでは要件定義が終わらないのは何故か？
アジャイルを採用する一番の理由は、今後の変化に対応できることではないでしょうか？変化に対応するということは、最初に決めたことが変わる可能性があるということになります。将来形が変わるとしたら、計画段階でそれを確定させることには無理があります。仮に将来形を定義したとしてもその正しさはわからず、変化しないとは言い切れない状態になります。
そのため業務要件に即してシステム要件を明確にしようと思っても、可能性の議論に終始してしまい、議論が終わることはないのです。

とはいえ、機能要件の洗い出しやシステム要件の検討に意味がないというわけではありません。アジャイルにおいてもアーキテクチャや設計は当然重要ですし、それらをなくして開発は不可能です。重要なポイントは、全ての項目を洗い出して確定させることではなく、業務要件の中から本当に必要なことを明確にすることであり、その範囲をしっかりとシステム要件に落とし込むことなのです。

今見える範囲は確定させる、今見えない範囲は確定させない。この割り切りがアジャイルの要件定義で求められます。答えのない議論に時間を割くより、可能性に夢を膨らませる議論をしたいものです。

続いて、予算と見積、責任範囲についてもお話しておきます。
この話は、アジャイルが社内で浸透していない段階では非常に重要なテーマとなります。

「アジャイルプロジェクトだといくらかかるのかわからない」
「見積の妥当性がわからない」
「ベンダーが責任もって作ってくれるのかわからない」

こんな疑問をよく伺います。

一般的にアジャイル開発では、請負型で開発ベンダーが一手に責任を負うというスタイルはとりません。それは要件が定まっていないものに対して事前に見積を確定させることができないからであり、請負う範囲と責任を明確に定義できないためです。

これは、開発ベンダーを使わず社内リソースのみで開発を行う場合も同じです。要件が定まらなければ、確定した見積は作れないはずであり、従って実装される機能や時期についても確定できないはずです。

しかし実際には、社内で予算申請をする際に、アジャイルプロジェクトであっても、明確に期間や成果物を確定させた計画が提出されているなんてことはないでしょうか？

このあたりは少々理屈が入り組みますので、先に結論から申し上げます。
アジャイルプロジェクトにおいてベースラインとなる計画は作成しますが、確定したものとして扱うべきではありません。そのため、プロジェクト開始後、定期的に進捗を確認し予算執行の妥当性を確認していくべきと考えています。

たとえ話をしましょう。
あなたは２つの登山隊を派遣することにしました。目的はそれぞれ異なります。一つは山頂に到達する登山隊。もう一つは山中に生息する鹿を発見する登山隊。彼らのスポンサーであるあなたは、無事に目的を達成したか結果が気になります。さて、それぞれ何を確認すれば良いでしょうか？

図２：目的の異なる登山隊

すでにお気づきでしょうが、アジャイルのアプローチは「鹿を探す登山隊」になります。行動予定はもちろん作成しますが、予定通りに行動したからといって目的を達成できるとは限りません。そこで、進捗を確認するためには、予定通りかどうかではなく、目的に近づいているかという確認が必要です。

閑話休題、予算の話に戻ります。
先に述べましたが、アジャイルプロジェクトの計画には、不確実性が含まれます。そのため、最初に作成した計画は仮説の域を出ない部分があり、もしかしたら間違っていたり、軌道修正が必要な可能性があります。そのため、予算確保の段階では、目的の妥当性と計画の実現性は評価すべきですが、実行のコミットまでを求めることはあまり意味がありません。実行の段階でゲートチェックとしてレビューの場を置き、そこまでの結果とこれからの予定を確認していくことが必要となります。

本章の冒頭で申し上げた外部の開発ベンダーに依頼する場合も同様のアプローチが必要と思います。契約を一括でするのでなく、一定の期間で区切って、その後の続行を評価することで各自の責任範囲を明確にし、リスクを低減することが可能となります。

予算や見積は計画時のベースラインとして設定します。当然それを守る努力はすべきですが、目的達成のために見直しが必要であれば、今後の投資予算や期間について都度、評価をし納得できる修正を加えていきます。（いたずらに増やすということではありません。減らすことも考えるべきです）

なお、社内でアジャイルの取り組みが正しく認知されていない場合、このような計画や予算の承認を得ることが難しい場合があります。それは承認する側が上記のような観点を持っていないからかもしれません。「我々は鹿を探しにいくのです」と理解を求めてはいかがでしょうか？

次回は続けて、プロジェクト立ち上げ時に起こりやすい別の問題点について解説します。