アーキテクトの教科書 価値を生むソフトウェアのアーキテクチャ構築

159

4

Column

ユーザーストーリー

アジャイル開発プロセスを採用するプロジェクトでは、作成するドキュメ

ントを軽量化する傾向があります。アジャイル開発プロセスにおいてユース

ケースの代わりによく利用される手法として、ユーザーストーリーがありま

す。

ユーザーストーリーは、ユーザーの観点でシステムに求める機能を、一枚

の小さなカードに記述可能な程度の簡潔な文章で記述していくものです。

ユーザーストーリーにはいくつかのフォーマットがありますが、筆者が好ん

で使用するのは以下のフォーマット

※4

です。

＜ビジネス上の価値を達成する＞ために

＜ユーザーの種類＞として

＜システムの機能＞が欲しい

以下はサンプルです。

このようにシンプルなフォーマットですので、ユーザーストーリー自体は

仕様とはなり得ません。ユーザーストーリーをもとに顧客や顧客の代わりと

なる人と対話を行い、システムの詳細な振る舞いを明確化します。この振る

舞いは受け入れテスト基準として明文化されます。

設計書の標準化

設計アクティビティで行う設計作業のアウトプットを文書化するかど

うか、何を文書化するかはプロジェクト次第です。詳細なクラス図やコ

ラボレーション図を事前に作成しても、ソースコードとして実装すると

そのとおりにはならないことが大半ですし、また設計書とソースコード

の同期が取れた状態を維持することも困難です。あくまで実装前の予備

不正な経費使用による社の損害を防止するために

監査者として

不正の疑いがある経費精算申請を検知する機能が欲しい

160

設計として使い捨てることを前提に作成することや、第 ...