4章を読み終えたのでまとめ。*1
さて4章は、3章で出てきたフィーチャーの詳細化の方法を説明しています。
3章で疑問に思ったフィーチャーの定義
3章でフィーチャーと特定された中には「これはフィーチャーなのか？」と思う物がありました。 kazokmr.hatenablog.com
この疑問について章の最初に触れており、フィーチャーに限らずこれらの概念として用いられる用語は、扱う方法論によって少しずつ定義が異なることがよくあり、混乱の基になっていると書かれていました。
そこでBDD（あるいは、この本）の中では、用語を次のように定義しています。
- この本では、主にケイパビリティ、フィーチャー、ユーザーストーリー、例(Example)の4つを用いて説明する。
- ケイパビリティは、ユーザーやステークホルダーが「何かを行うための能力」を表し、ソフトウェアの実装に依存しない。
- フィーチャー, エピック, ユーザーストーリーは、ケイパビリティをサポートするためのもの。 扱う規模が違うが概念はほぼ同じで「エピック => フィーチャー > ユーザーストーリー *2」となる。
フィーチャー
前章で利用したインパクトマッピングにおいて、最後の成果物(Deliverable)をフィーチャーとします。 ちなみに、前段の影響(Impact)を、ケイパビリティとして扱います。
インパクトマッピングから、フィーチャーを定義すると次のようになります。
Feature: "成果物(Deliverable) " In order to "影響 (Impact)" As a "関係者(Actors)" I want to "成果物をビジネス用語で表す。"
起点となるGoalがここには現れませんが、「そのフィーチャー(Deliverable)は、ケイパビリティ(Impact)を関係者(Actors)に与えるために提供する。」と表現できるので、個人的にフィーチャーが考え易くなると感じました。
また、3章および元々のインパクトマッピングでは「影響をHow、成果物をWhat」と説明しているが、フィーチャーを定義するときは「影響をWhat、成果物をHow」と表している。 これについては、目標を機転に成果物を特定していく時と、特定した成果物を表現する時の違いと考えればそれほど違和感を持たなかった。*3
フィーチャーとユーザーストーリーの違い
BDDでは通常、ユーザーストーリーは、フィーチャーを小さく分割して定義していくそうです。*4
ユーザーストーリーがフィーチャーと大きく異なる異なるのは「それ単独でリリースする価値があるかどうか？」と言う点であると説明されていました。*5
ユーザーストーリーの主な概念は(目的？)は次のようになります。
フィーチャーについてより深く考えていく過程で、思いついた具体的な状況や例を一つ一つをユーザーストーリーとすると作りやすいと感じました。
Real Options と Deliberate Discovery
訳すと「現実的な選択」と「意図的な発見」となるかなと思います。
ステークホルダーの目標を達成するためのケイパビリティに役立つと考えるソリューション、つまりフィーチャーを検討する中で不確実なことが出てきます。それらは大抵、自分たちの無知や誤解から生じます。このような不確実性に向き合って要件に対する共通理解を得るために、この2つの原則について説明しています。
Real Options (現実的な選択)
不確実性が原因で、最適だと考えるフィーチャーが思いつかない、あるいは確信が持てない場合に用いる代替案や保険的なフィーチャーを考えておく事を指します。
この目的は「決断を可能な限り先延ばしにする事」にあり、最適なフィーチャーを考える時間を確保することにあります。 そのためにReal Optionにはいくつかのルールがあります
- Real Optionにも価値を持つ必要がある。
- Real Optionに期限を設ける。
- 何事もすぐに決断をしない。
- でも、最適なフィーチャーである確信が持ったら、期限を待たずに実装する。
Deliberate Discovery (意図的な発見)
最適なフィーチャーを特定するために、無知なことを学んだり、誤解を無くして共通認識を持つ事を積極的に進める考え方で、不確実なことはプロジェクトのリスクになるので、早く解消する事を目的とします。
本に書いてあった説明だと、例えばバックログリファインメントで、どのフィーチャーから取り上げていくかを考えたときに、「最適な方法が明確なもの」よりも「不確実性というリスクを持つもの」から優先して取り掛かることで、プロジェクト全体の明確さを底上げした方がいいとありました。実際にはバランスが重要ではありますが。
この2つの原則を併用して、不確実性を取り除いた最適なフィーチャーを積極的に特定していくと良さそうです。
感想
これまでは最初から、断片的なユーザーストーリーを作ろうとして、ストーリーが上手く定義できなかったり整理できないことが多かったので、「ケイパビリティ -> フィーチャー > ユーザーストーリー」と順番に思考していくと作りやすそうだと感じだので、チャレンジしていきたい。
(おまけ) describe と illustrate
どちらも 「説明する」 と言う意味だが、この章では主にDescribeを使っていて、次の章からはIllustrateフェーズと呼ぶように後者が話の中心になる事を明示していたので、この意味の本質的な違いを調べてみました。
describe
- 「詳細化する」と言う意味もある。
- 大きなフィーチャーを小さく分割していき、ユーザーストーリーに分割していく流れは、まさに詳細化だと感じました。
illustrate
- 「解説する」「例となる」と言う意味合いが強い。
- 明確にするようなハッキリとさせる様子があると感じました。
- 次章で紹介する例(example)などは正に、この意味合いになると思います。
*1:ちなみにこれを書いている時点で、次の5章までしか公開されていない。
*2:実際には、フィーチャーとユーザーストーリーには大きな性質の違いがあるのですが、それは後述します。
*3:後者において成果物を実装するコードと捉えればHowと言えるし、そのフィーチャーの目的と捉えれば影響すなわちケイパビリティをWhatと表現することはそれほどおかしくは無いと思う。
*4:他の方法には、大きなテーマからユーザーストーリーを考え出す方法があり、どちらから言えば自分はこの考え方だった。
*5:ちなみにビジネス価値はシステムが対象としている業界によって変わるので、ある場合はユーザーストーリーと定義された物が、違う状況ではフィーチャーとして価値が出せることもあります。
