アジャイル トランスペアレンシー ~アジャイル開発における透明性の確保について~

第3回 選択される開発内容

この記事を読むのに必要な時間:およそ 3 分

「Agile Conference tokyo 2009」開催のお知らせ

「Agile Conference tokyo 2009」12月8日(火)開催本カンファレンスは,400名規模のアジャイル開発事例を持ち,世界No.1のアジャイル開発の企業として名高いThoughtWorks社からスピーカーを招いて,最新の大規模アジャイル開発について講演していただきます。

詳細は→ http://gihyo.jp/event/2009/agile

はじめに

本連載では,⁠透明性」というキーワードで,アジャイル開発について説明してゆきます。前回は,開発者が顧客に対して透明性を提供することの重要性について解説しました。その一つの大きな手段として,継続的かつ頻繁なリリースを取り上げています。しかし,部分的に出来上がった画面を見せられて,顧客は何ができあがっていて,何が不足しているのかをどのように判断すれば良いのでしょうか?それを判断する為には,事前に今回のリリースで何を開発し,何を開発しないのかについて,顧客自らが選択し,意思決定しておく必要があります。第三回目の今回は,このような顧客による開発内容の選択の意味について,整理してみたいと思います。

ストーリーについて

一般的なウォーターフォール型のソフトウェア開発では,まず要求仕様を整理し,そこから機能を洗い出します。要求仕様は,顧客の言葉で表現された,利用する側からみたソフトウェアの振る舞いです。対して,機能はソフトウェアの内部構造や仕組みであり,開発者側からの視点でシステムを描き直したものとなります。

そして,タスクの洗い出しや担当の割り当て,進捗の管理といった作業には,後者の機能を単位とすることが通常です。 例えば,機能一覧を元に WBS とガントチャートを描いて開発の進捗を管理する,といったやり方です。

このようなやり方をとった場合,要求仕様から洗い出された機能一覧は,開発工数を十分に予測できる程度にまで詳細化されています。顧客にとっては,各項目の必要性を判断することが困難な一覧となります。

アジャイル開発を適切に進めるには,顧客に開発の状況の透明性を高めることが大切です。進捗の管理に,顧客が中身を把握できない機能一覧を利用することは好ましくありません。そこで,システム用語で記載された機能ではなく,顧客の用語で書かれたストーリーを単位として開発を進めることになります。

ストーリーとは,ソフトウェアの振る舞いを簡潔に表したものです。以下に例を示します。カード一枚に記載できる程度のボリュームです。

ストーリーの例

ストーリーの例

アジャイル開発で想定されるストーリーの使われ方は以下の通りです。ソフトウェアに必要な振る舞いをストーリーとして洗い出します。各ストーリーに依存関係は無いので,顧客はその中から次のイテレーションで実装するストーリーを選びます。通常,最も必要なストーリーから順に選択します。開発者は,選択されたストーリーを優先度を意識しながら実装していきます。

方法論により,ストーリーに該当する概念の名称や位置づけ,記載内容に違いはあります。しかし,顧客が自らストーリーを(間接的にせよ)選択するという点では変わりありません。この顧客にとってのストーリー選択の自由こそが,アジャイル開発の柔軟性の最大のメリットとなっています。

その為にも,ストーリーは依存関係が無く個別に選択可能であり,顧客が理解できる用語で記載されていなくてはなりません。

ストーリーの難しさ

顧客の理解できる言葉でかかれたストーリーを単位とすること,そして各イテレーションにおいては選択されたストーリーを実装対象とすることをご説明しました。

しかし,実際に試してみると,顧客に理解できる用語で,依存関係なくストーリーを杓子定規に記述することは,実はかなり難しいことが分かります。

例えば,コネクションプールの仕組みを DAO に組み込む作業が発生したとします。どのようなストーリーで表すでしょうか?

このように,各振る舞いに共通の内部処理は,外部の振る舞いとしては見えにくいものがあります。顧客にその作業の影響範囲や必要性を適切に示すことがちょっと難しくなります。他にも,セキュリティ関連の実装といった,非機能要件への対応等もストーリーとして記述しにくいものとなっています。

表現しにくいからといって特定のストーリーの中に含めてしまっては,ストーリー間に依存関係が生まれる可能性が高まります。 またストーリーが肥大化し,イテレーションに納まらなくなるかもしれません。

これらの解決方法は単純に一通りではありません。

大切なことは,顧客が判断可能なものにすることです。そしてイテレーションに十分に収まる程度に小さく分割されていることです。もし顧客が判断可能な内容であれば,ストーリーの一つとして挙げてしまって構いません。工数が小さいものであれば,一塊りにした別のストーリーをしてもよいですし,最も関連の強いストーリーに含めてしまっても良いでしょう。

個別にストーリー化しなくてはならないような機能でしたら,そこの実装はコストがかかるという意味で,顧客とっては重要なリスクです。きちんと時間をとって説明するのが開発者の責任です。

特に,イテレーション期間が短い場合,ストーリーが限りなく細分化されることがあります。そのような時にはより機能やタスクに近いストーリーが発生することになります。

例えば,"メール送信機能" というストーリー名称は OK でしょうか? NG でしょうか?

ここでの目的は,顧客が開発の状態を把握できるように透明性を高めることです。つまり,顧客がメール送信機能といったときに処理の内容を想像できればよく,誤解を与えたり,どの部分まで含むのか判断に迷うようではだめです。その為,開発者側からあげたストーリーについては,十分説明をすることが大切です。

著者プロフィール

設楽秀輔(したらしゅうすけ)

1994年,慶応義塾大学経済学部卒業。エンターテインメント系企業にて経営管理を経験後,システムインテグレータとして金融アプリケーションなどのソフトウェア開発に従事。2007年,株式会社テクノロジックアートに入社し,現在に至る。

テクノロジックアートアジャイル開発グループグループリーダー。認定スクラムマスター。会計士補。

コメント

コメントの記入