アジャイル開発とユーザーストーリー

こんにちは、ライトパスの建守です。今回は、アジャイルシステム開発プロジェクトで要件を明確にするために使われる「ユーザーストーリー」についてのお話しです。

従来の要件定義

従来型のシステム開発（ウォーターフォール型の開発）では、開発プロジェクトが立ち上がると最初のフェーズとして「要件定義」という作業が行われます。ここでの成果物である「要件定義書」にプロジェクトで実現すべきこと＝要件をすべて書き出し、以後のフェーズではその内容をもとに作業が進められていきます。

要件定義書に書く内容は、プロジェクトを実施する組織やプロジェクトによってまちまちですが、大項目は以下のような構成になることが多いのではないでしょうか。

システム概要
業務概要
機能要件
非機能要件
移行要件
運用要件
システムアーキテクチャ
スケジュール

アジャイルの要件定義

アジャイルシステム開発においても、必要があればこういった内容の書かれたドキュメントを作ります。

ただし、従来のシステム開発のように、プロジェクトの初期にすべての要件をリストアップして要件定義書を作るということはしません。必要になったときに、必要になったものだけ作るのが基本です。製造業でいうところのJust-In-Time方式ですね。この方式を取ることで、手戻りの無駄を避けて生産性を上げ、最大のビジネス価値を生み出すことを目指します。

ユーザーストーリー

さて、決められたフォーマットの要件定義書を一気に作り上げるわけではないアジャイルシステム開発で、要件を明らかにして関係者間で共有するために使われるのが今回のお題である「ユーザーストーリー」です（単に「ストーリー」と呼ぶこともあります）。

ユーザーストーリーには、「3C」という特徴があります。これは「Card」「Conversation」「Confirmation」という3つの単語の頭文字です。一つ一つ見ていきましょう。

Card

ユーザーストーリーは多くの場合、インデックスカードに書き留められます。WordやExcelを使った美しいフォーマットではなく、A5サイズくらいのインデックスカードに、ユーザーがそのシステムを使ってやりたいことを手書きします。サイズが小さいので、書く内容は短くまとめる必要があります。必ず書かなければいけないのは以下の3点です。

誰が
何のために
何をしたいのか

よくあるストーリーの書き方としては、「Aとしてわたしは、Bという結果を得るためにCをしたい」（例：ECサイトのユーザーとしてわたしは、ほしい商品を手に入れるために、サイトで購入可能な商品から目的の商品を検索したい）のような感じになります。

このカードは、基本的には顧客（プロジェクトにおけるビジネスサイドの担当者）が書きます。そして、書いた内容を開発者やほかの関係者に読んで聞かせます。「ストーリー」ですから、読み聞かせるのが本来の目的なのです。

Conversation

小さなインデックスカードに書かれたストーリーだけでは、どうしたって細部が伝わりません。ではどうするのか？徹底的に会話をしましょう、というのがアジャイルの考え方です。

そもそも、従来型のシステム開発で作られるような手の込んだ要件定義書があったとしても、書き手と読み手の間には必ず意識のずれ（誤解）が発生します。時間とコストをかけて誤解のもとを作っても、誰も得をしません。だったら、書くのは最小限にして、文章よりも短時間で多くの情報が伝えられる会話を活用しましょう、ということです。

「アジャイルソフトウェアの12の原則」にも、「情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。」と書かれています（よろしければ以前の投稿もご覧ください）。

Confirmation

Cardに書かれた内容をConvesationで深く理解したとしても、まだ意識のすれ違いが発生している可能性があります。そこでConfirmationつまり「確認」の出番です。Cardにかかれた内容（システムを使ってやりたいこと）がシステムでできるようになったと判断する基準を、関係者間で確認するのです。ゴールラインがどこにあるのか、何をもって完成とするのか、ここの合意が取れていれば、お互いの認識があっていると確信できます。

従来の要件定義では、要件定義書のレビュー完了をもって工程が終了します。レビューでは、要件定義書の内容に抜け漏れ間違いがないかを確認しますが、それだけです。読み手と書き手の認識がずれていないかをチェックする方法がありません。ですから、プロジェクト最終盤の受け入れテストフェーズになるまで誤解に気が付かず、最後の最後でどんでん返しという悲劇が発生してしまうのです。

さいごに

『ユーザーストーリーマッピング』（Jeff Patton、オライリージャパン）によれば、ユーザーストーリーは「バケーションの写真」のようなものだそうです。

楽しいバケーションの思い出を誰かに話して聞かせるときに見せる写真、その写真があれば当時の記憶がよみがえって、イキイキとした情景を伝えることができるでしょう。聞き手の側も、ただ話を聞くだけではなく、写真があればよりよく情景を思い描けますよね。

ユーザーストーリーは、アジャイルシステム開発プロジェクトにおいて、関係者がシステムに対する要件を理解し思い出すためのきっかけとなります。より詳しい内容は会話で確認し、誤解がないかを確認するステップが必要ですが、これもすべてカードに書かれたストーリーがあってはじめてできることです。

ことほどさように重要なユーザーストーリーについては、どんな粒度で書くのかとか、どうやって管理していくのかとか、追加情報をそのうち書きたいなと思っています。
それではまた！