ユーザーストーリーを使ってプロジェクトを進める方法

今回は、ユーザーストーリーを使ったプロジェクトの進め方をご紹介します。

レザボア・コンサルティングでは、Reservoir Way（レザボアウェイ）というハイブリッドアジャイル型の開発手法で、プロジェクトを進めることを基本にしています。

その中心にあるのが、「ユーザーストーリー」を使った進め方です。

ユーザーストーリーとは

ユーザーストーリーは、お客様の業務の目線で要件をはっきりさせるためのドキュメントです。

アジャイル型のプロジェクトではよく使われる手法ですが、お客様にとっては聞き慣れないドキュメントかもしれません。

具体的には、「＜誰が＞（そのシステムを利用することで）＜何を＞＜行うことができる＞」という形で、業務ユーザーの要望を書き出していきます。

ここには、システムの振る舞いや仕様は書きません。

ユーザーストーリーに書くのは、あくまでユーザーがやりたいことです。

それをどう実現するかも書きません。実現方法を考えるのはシステムベンダーの責任であり、腕の見せどころでもあります。

5W1Hでいえば、＜WHO＞と＜WHAT＞、必要に応じて＜WHY＞（なぜその業務を実現する必要があるのか）を書き、＜HOW＞は書かない。これがユーザーストーリーの基本的な書き方です。

良いユーザーストーリーの書き方

良いユーザーストーリーが備える特徴は、それぞれの頭文字を取って「INVEST」と呼ばれます。

• Independent（独立している）
• Negotiable（交渉の余地がある）
• Valuable（価値のある）
• Estimatable（見積もれる）
• Small（小さい）
• Testable（テストできる）

一つひとつのストーリーが、この6つの特徴を備えている必要があります。

書くときには「粒度は適切か」「このストーリーだけを取り出しても見積もれるか、テストできる単位か」といった点を意識すると、お客様の要件を整理しやすくなります。

ユーザーストーリーを使ったプロジェクトの進め方

ただ、ユーザーストーリーだけではシステムの仕様は分かりません。

＜HOW＞が書かれておらず、実現方法は開発者に委ねられているからです。

では、要件定義フェーズで、お客様とシステムの仕様をどのように合意していくのでしょうか。

レザボア・コンサルティングのハイブリッドアジャイルでは、本物に近いプロトタイプを用いながら機能単位に要件定義、基本設計、詳細設計・開発を一体としてスプリントを繰り返し実施します。 Reservoir Way

レザボア・コンサルティングのReservoir Wayは、「共感」「問題定義」「創造」「プロトタイプ」「テスト」の5つのステップを繰り返す「デザイン思考」をもとに定義しています。ユーザーストーリーとプロトタイプを併用して開発まで一貫して進め、スプリントを繰り返し回していくのが大きな特徴です。

良いシステムを作るには、メンバーがお客様を理解し、お客様の業務に共感している必要があります。

お客様がその業務をどのように、なぜ行っているのか。身体的・感情的なニーズは何か。お客様にとって意味のある機能は何か。

デザイン思考の最初のステップである「共感」は、お客様を理解するために必要なステップです。そのためのツールとして、私たちはユーザーストーリーを使っています。

そして、その「共感」をもとに本物に近いプロトタイプを作り、「創造」「プロトタイプ」のステップで、お客様に画面や機能を直接確認していただきます。

Reservoir Wayでは、次の流れでスプリントを進めます。

• お客様の業務要件をユーザーストーリーとして定義する
• ユーザーストーリーをもとにプロトタイプを開発する
• お客様が実際の画面や機能を確認しながら、ストーリーが実現されているかを確かめる
• 機能やストーリーの過不足を反映する

これらを一つのスプリントの中で行うので、お客様は実際の画面や機能のイメージを早い段階でつかめます。

また、ユーザーストーリーをベースに開発しているため、業務をどう回すかのイメージも早くから持てます。

「システムを導入したけれど定着しない」「実際の業務に合っていないので使いにくい」といった失敗はよく聞きますが、ユーザーストーリーを起点にすることで、こうしたリスクを減らせるのも大きなメリットです。

ユーザーストーリーを使ったテスト

ユーザーストーリーを使うメリットは、テスト工程でも表れます。

システムベンダー側は、総合テスト（システムテスト、ST）で行うシナリオテストのインプットとして使えます。

お客様側も、UAT（受け入れテスト）でテストケースを作るときに、同じくユーザーストーリーをインプットにできます。

ユーザーストーリーを基準に開発しているので、そこに定義された業務要件がすべてシステムで実現されていれば、そのシステムで業務を回せるということになるからです。

ユーザーストーリーを中心にプロジェクトを進めると、要件の整理だけでなく、その後の工程でも役に立ちます。

おわりに

ユーザーストーリーがどういうものかは知っていても、実際のプロジェクトで使うのは難しいと感じる方も多いと思います。

それでも、一度作ってしまえば、山のような設計書や仕様書よりも大きな価値をもたらしてくれるでしょう。

ユーザーストーリーをきっかけに、お客様とシステムベンダーのコミュニケーションが深まり、良い関係で進むプロジェクトが増えることを願っています。