ストーリーについて - Dan North

この記事はDan North氏の記事「What’s in a Story?」を氏の許可を得て翻訳した公式版("the official translation")です。(原文公開日:2007年2月11日)




ふるまい駆動開発("Behaviour-driven development")は「アウトサイド・イン」の方法論です。ビジネス上の結果("business outcomes")を識別することで外側から始まり、それらの結果をもたらす諸機能("the feature set")へと掘り下げていきます。各機能は「ストーリー("story")」としてとらえられ、このストーリーは受入基準("acceptance criteria")とあわせて機能のスコープを規定します。この記事ではストーリーとその受入基準を定義して識別するために用いられるBDDのアプローチを紹介します。

イントロダクション

ソフトウェアを提供するということ("software delivery")は、ビジネス上の結果を得るためにソフトウェアを書くということです。これは当然なようですが、政治的ないし環境的な要因によって、これを忘れてしまうことがしばしばあります。時としてソフトウェアを提供するのは、単に上層部の経営者を喜ばせるような楽観的なレポートを作り出すことや、雇用を守るために「忙しい仕事」をひねり出すことであるように見えることもあります。しかし、これについてはまた別の日に。


通常、ビジネス上の結果はきわめて粒度が粗く、直接ソフトウェアを書くのには使えません(ここでいうビジネス上の結果が「運用コストを5%削減する」であった場合、どこから手を付けるでしょうか)。だから仕事を仕上げるために、私たちはなんらか中間的な水準で要件を定義する必要があるのです。


ふるまい駆動開発(BDD)は次のような立場をとります。要件に関する観念を、実装とテストが行われたリリース可能なコードへと単純かつ効果的に移しかえることは可能です。しかし、それには何が行われているのかについて誰もが理解できるように、要件が詳細化されていなければなりません。そのために、ビジネス側の人もアナリストも開発者もテスタも皆が作業のスコープについて共通の理解を得られるように、要件を記述する方法が必要になります。それによって「完了した("done")」ということに関する共通の定義について合意することができるのであり、「頼んだものとは違う」「いい忘れていたことがあった」といった2大モチベーション低下要因("gumption traps")を避けることができるのです。


これこそがストーリーの果たす役割です。ストーリーが記述するべきなのは、要件とビジネス上の利益、そして「完了した」ことに関する合意の根拠となる基準です。これは他のアジャイル方法論においてなされているより厳格な定義です。他の方法論では「会話の約束」や「機能の記述」など、さまざまな形で説明されます。(BDDのストーリーは非機能要件に関しても、そのスコープが定められ、見積もられ、合意されている限り、簡単に記述することができます。)

ストーリーの構造

BDDはストーリーのための構造を提供します。これは必須ではありません。他のストーリー形式を用いてもBDDを実行していると言えますが、ここでストーリーの構造を示すのは、これがあらゆる形態あらゆる規模の多くのプロジェクトで機能することが証明されたものだからです。独自のストーリーを作る場合でも、少なくともここで示すテンプレートで記述された要素は全て含むべきです。このストーリーテンプレートは次のようなものです。

タイトル(ストーリーを1行で記述したもの)

叙述:
As a [役割]
I want [機能]
So that [利益]

受入基準:(シナリオとして表現される)

シナリオ1:タイトル
Given [前提となる文脈] And [さらに他の文脈]
When [イベント]
Then [結果] And [他の結果]

シナリオ2:・・・

ストーリーを語る

ストーリーは複数人で行われた会話から生み出されるべきものです。ビジネスアナリストはビジネスステークホルダ*1に要件ないし機能について語り、ストーリー叙述として形作る手助けをします。そしてテスタはストーリーのスコープを受入基準という形で定義する手助けをします。これは、どのシナリオが重要でどれがそうではないかを決定することによって行われます。技術面の代表者はストーリーに含まれる作業の総量を概算で見積もり、アプローチの選択肢をいくつか提案します。システムに関する優れたアイデアは、それを開発する人たちからも、最初にそれを頼んだ人からと同じように出てくるのです。


これはイテレーティブなプロセスになるでしょう。ステークホルダには、何が欲しいかというアイデアはありますが、それにはどのくらいの作業が必要であるか、あるいはその作業はどのように割り当てられるかといったことは通常知りません。技術やテストの専門家の助けを借りることで、各シナリオが持つ費用対効果のトレードオフを理解し、必要かどうかの判断を下すことができるのです。もちろん他の要件との兼ね合いもあります。ストーリーにおけるより境界的な部分をカバーした方が良いのではないか、あるいは他のストーリーに移った方が良いのではないか、ということがあるのです。


時に開発チームが概算の見積もりすら作れないほど情報がない場合もあります。このような場合、開発チームは要件についてより深く理解するため、「スパイク("spike")」と呼ばれる調査作業を行うという選択をするかもしれません。(計画立案については、いずれ別の記事でより詳細に扱います。)

優れたストーリーの特徴

BDDの導入」で用いた例を使って、ATMから現金を引き出す要件を見ていきましょう。

ストーリー:口座所持者が現金を引き出す。

As a:口座所持者の立場で
I want:ATMから現金を引き出したい
So that:銀行が閉まっている時でも現金が得られるように

シナリオ1:口座に十分な残高がある
Given:口座残高が$100で
And:カードが有効であり
And:機械に十分な現金が入っていれば
When:口座所持者が$20要求した場合に
Then:ATMは$20を支払い
And:口座残高は$80になり
And:カードは返却されなければならない。

シナリオ2:口座に十分な残高がない
Given:口座残高が$10で
And:カードが有効であり
And:機械に十分な現金が入っていれば
When:口座所持者が$20要求した場合に
Then:ATMは一切現金を支払わず
And:ATMは残高が足りないと言い
And:口座残高は$20のまま
And:カードは返却されなければならない。

シナリオ3:カードが無効化されている
Given:カードが無効化されていて
When:口座所持者が$20を要求した場合に
Then:ATMはカードを保管し
And:ATMはカードを保管したと言わなければならない。

シナリオ4:ATMに十分な現金がない場合
・・・

このように、考えなければいけないシナリオは数多くあります。口座残高に関係するものがあれば、カードに関係するものもあり、ATM自体に関係するものもあります。これが役に立つものかどうかを検証するため、ストーリーの分析を行いましょう。

タイトルは行動を記述しなければならない

ストーリーのタイトルである「口座所持者は現金を引き出す」は口座所持者が実行したいと望む行動を記述しています。この機能を実装するまでは、口座所持者はATMから現金を引き出すことができません。一旦ストーリーが実現されれば、これができるようになります。このことは「完了した」というものがどのようなものであるかを決定する上での、明確なスタート地点となります。


もしタイトルが「口座管理」や「ATMのふるまい」であったら、いつ完了するのかを理解するためにもっとよく確かめなければならなかったでしょうし、境界ははるかに曖昧だったでしょう。例えば、「口座管理」はローンの申し込みを含むかもしれませんし、「ATMのふるまい」はキャッシュカードのPINナンバーの変更を含むかもしれません。ストーリーのタイトルは常にシステムのユーザによって行われる実際のふるまいを記述するべきなのです。

叙述は役割、機能、利益を含まなければならない

As a [役割] I want [機能] so that [利益]」というテンプレートには多くのメリットがあります。叙述中で役割を規定することによって、機能について誰と話せば良いのかが分かります。利益を規定することによって、ストーリーを書く人はある機能がなぜ必要なのかということについて考えるようになります。


もし特定の機能が、それに関連する利益を実際には実現しないことが分かったら面白いことになります。これは通常、ストーリーを見落としているということを意味しているのです。問題の機能にはあるストーリーがついていて、それが別の利益を実現します(だから役に立つことには変わりありません)。そして隠されたストーリーがもう1つあって、書かれた利益を実現するために別の機能が必要になるのです。


例として挙げたストーリーを見て分かるのは、実現されようとしている機能のことを重要だと思う("care")口座保持者がいるということです。このことにより、何をすべきかを考える上でどこから始めるべきかが分かるのです。

シナリオのタイトルは何が違うのかを表さなければならない

シナリオを並べた時にそれぞれ何が違うのかをタイトルだけで表現できなければいけません。今回の例では、シナリオの説明にそれぞれ何が違うのかということだけしか書いていないことが分かると思います。「口座保持者が現金を引き出そうとしたが、十分な預金がなく、取引を完了できないと言われる」と言う必要はありません。タイトルを他と比べることで、今見ているものが自分が問題としているシナリオなのかが明らかになります。

シナリオは前提、イベント、結果の観点から記述されなければならない

ここで説明するのは、BDDを採用したチームにおいて私が見てきた、唯一最大の行動の変化です。ただ単にビジネスユーザ、アナリスト、テスタ、開発者にこの「given/when/then」という語彙を採用してもらうだけで、曖昧な世界が消えていくのが分かってもらえるのです。


全てのシナリオが単純なわけではありません。イベントの連続として表現されるのが適切であるものもいくつかあります。例えば次のような具合です。「given [ある文脈] when [私が何かをする] then [これが起こる] when [他のことをやる] then [この新しいことがおこる]。」例としてはウィザード形式のウェブサイトが挙げられます。これは複数の画面に渡って複雑なデータモデルを組み立てるというものです。一連のイベントと結果を混ぜることはまったくもって適切なことです。ただし、これらの用語で考える習慣が身に付いている限りにおいてですが。


ここであらわれてくる興味深いものとして、会話の質が変わるというものがあります。すぐに気がつくのが、これまで当然と考えられる前提を書き落としていたり(「もちろん口座は借り越しになるだろう」)、結果を確認するのを忘れたり(「当然口座保持者はカードを返してもらえるだろう」)していたということです。これが良く分かったのが、あるプロジェクトで開発者のリーダと話をした時でした。アナリストと開発者の間で話が食い違っているのを感じるけれども、それをどうやって分からせれば良いか分からないというのです。given/when/then の語彙を紹介して数日のうちに、リーダは彼らの会話の質が劇的に改善するのを目の当たりにすることができたのでした。

前提は要求される文脈を全て定義しなければならず、それ以外のことをしてはならない

付加的な前提を見ると、どのようなものであれ気が散ります。これによって、初めてそのストーリーを見る人が、何を知る必要があるかを理解するのが困難になります。これは技術的な観点であっても、ビジネス上の観点であっても、変わりありません。同様に、書き落とされた前提は実はどれも想定なのです。与えられた前提から別の結果が得られるとしたら、なにか見落としているものがあるに違いありません。


前述した例では、最初のシナリオでは口座残高、カード、そしてATM自体について言及しています。これらは全てシナリオを完全に定義するのに必要です。3番目のシナリオでは口座残高についても、ATMに現金が入っているかどうかについても言及していません。これが意味しているのは口座残高がどうあれ、またATMの状態がどうあれ、カードを保管するということなのです。

イベントは機能を記述しなければならない

イベントそれ自体はひじょうにシンプルで、典型的にはプロダクションコードの1呼び出しとなるべきです。前述した通りシナリオによってはもう少し複雑になりますが、ほとんどの場合ストーリーのシナリオは1つのイベントをめぐって繰り広げられるものです。違いが出るのは、文脈(前提)とそれに対応した期待される結果です。

ストーリーは1つのイテレーションに合うような小さいものでなければならない

これをどのようにやらなければいけないかという点に関して厳格なルールはありません。実証できる大きさまでブレイクダウンできるなら良いのです。一般的には5〜6以上のシナリオがあったら、似たシナリオをグループにまとめることでストーリーをブレイクダウンすることができるでしょう。


ATMの例について、このストーリーにあとどの位のシナリオがあるのかは分かりませんが、おそらくもっとたくさんあると思われます。このストーリーには、本質的に3つの「可変な箇所」があります。つまり、口座残高、キャッシュカードの状態、ATMの状態の3つです。キャッシュカードに関してはさらに詳細に見ることができるでしょう。「期限切れで現金を引き出せないけれども、ATMがカードを返してきたらどうするか?」「ATMがトランザクションの途中で壊れたら?」「自分の口座に借り越し機能がついていたら?」


このストーリーはいくつかの細かいストーリーに分解した方が良いでしょう。

  • 口座保持者が現金を引き出す(想定:ATMが正常に動作していて、カードも有効である)
  • 口座保持者が不正なカードで現金を引き出す(想定:ATMは正常に動作している)
  • 口座保持者がこわれたATMから現金を引き出す(想定:カードは有効である)

これは技巧的に見えるかもしれませんが、これによってビジネスの用語で進捗を表現することができ、追跡するためのデータ点("data point")が増えることになります。重要なのは、ストーリーをシナリオに分解する際、常にビジネスの線引きに従うことなのです(そして想定を明示することです)。その際、技術的な線引きは好ましくありません(たとえば、このイテレーションではデータベースのことをやり、次のイテレーションではGUIのことをやる、といった具合に)。これが重要なのは、ビジネス側の人が自身の言葉で進捗を見ることができ、単に説明を聞くだけではないという点にあります。

それではこれはユースケースとどう違うのか

一口にユースケースと言っても、様々なものがあります。私はAlistair Cockburn氏がユースケースを説明するやり方に大賛成です(RUPという名を冠したウォーターフォールプロジェクトで出会った、やりすぎなバージョンとは正反対に)。私はユースケース駆動のプロジェクトの経験があまりないので、この比較は他の人に任せることにします。


精度("precision")の低い所(成果ないしゴール)から始め、進むのに合わせて例外系のシナリオを取り込んで精度を上げていくというCockburn氏のプロセスには賛成です。BDDにおいて、これはビジネス上の成果から始めて、受入基準を持つ特定のストーリーに踏み込むために、より高度な機能へと進んでいくことを意味します。


現実には、要件を識別して推敲する上で、プロセスがどのようなものであるかは重要ではありません。考えをまとめるのに役立つならば、要件のドキュメントを書くことは良いことです。しかし、あたかもそこに考えたことが全て込められているかのように、ドキュメントを人に渡してしまうのは良いことではありません。全ての考えなど込められていないからです。そのかわりに要件を示したドキュメントやユースケースの束を脇に置き、ビジネス上の成果から見たストーリーを定義し始めるべきです。自分のこれまで行った作業によって全ての答えが頭の中にあるか、少なくとも作業のアウトラインを作る上では十分に理解していることが分かって安心できるでしょう。

まとめ

ふるまい駆動開発ではストーリーを機能の基本単位として使用します。したがって、機能を提供する基本単位としても使うことになります。受入基準はストーリーにおける重要な部分です。実質的に受入基準によってふるまいのスコープを定義し、「完了」に関する定義を共有することができます。計画を立てる段になれば、見積もりの基礎としても使うことができます。


より重要なのは、ストーリーがプロジェクトステークホルダ、ビジネスアナリスト、テスタ、開発者といった人々の間で交わされた会話の結果だということです。BDDは開発プロセスの成果物に関するものであると同時に、プロジェクトに関わる様々な人々のインタラクションに関するものでもあるのです。

*1:実際には、これは機能を実際に重要だと思う人であるべきです。したがってストーリーによっては、操作、法律、セキュリティに関係する人になり得ます。