ユーザーストーリーを用いたプロジェクト推進手法

レザボア・コンサルティングの中西です。

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

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

その中核を成すのが、「ユーザーストーリー」を用いたプロジェクト推進です。

ユーザーストーリー とは

ユーザーストーリーとは、お客様の業務目線で要件を明確化するためのドキュメントです。

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

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

一方、この要件の中には、システムの振る舞い・仕様については記載しません。

ユーザーストーリーの上では、あくまでユーザが行いたい事を記載します。

その実現方法はユーザーストーリー上には記載しません。実現方法を考えるのはシステムベンダーの責務であり、そここそがシステムベンダーの腕の見せ所なのです。

つまり、5W1Hの ＜WHO＞と＜WHAT＞、必要に応じて<WHY>（なぜその業務を実現する必要があるのか）を記載し、＜HOW＞は書かないというのがユーザーストーリーの基本的な書き方となります。

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

良いユーザーストーリーは、その特徴の頭文字を取って「INVEST」であると言われます。

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

一つ一つのストーリーが、上記の６つの特徴を有している必要があります。

ユーザーストーリーを記載していく上では、「適切な粒度なのか？」「この一つのストーリーだけをピックアップしても、見積もりが行えるか？テストできる単位か？」などを意識することで、お客様の要件を整理することができます。

ユーザーストーリー を用いたプロジェクト推進

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

なぜなら、ユーザーストーリーには＜HOW＞は記載されず、その実現方法は開発者に依存するからです。

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

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

弊社のReservoir Way は、「共感」「問題定義」「創造」「プロトタイプ」「テスト」の５つのステップを繰り返す、「デザイン思考」に基づいて定義されています。ユーザーストーリーとプロトタイプを併用し、開発まで一貫して進め、繰り返しスプリントを回していくのが大きな特徴です。

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

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

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

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

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

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

一つのスプリントの中でこれらを実施することで、お客様は実際の画面や機能のイメージを早い段階で確認することができます。

また、ユーザーストーリーがベースとして開発されているため、業務を回すイメージも早期に持つことができます。

よく、「システムを導入したけど定着化が難しい」「実際の業務に即してないため使いにくい」と言った失敗例が挙げられますが、ユーザーストーリーが起点となることで、これらのリスクを低減することができる事も大きなメリットとも言えるでしょう。

ユーザーストーリー を用いたテストの実施

ユーザーストーリーをプロジェクトで用いるメリットは、テスト工程でも現れてきます。

システムベンダー側としては、総合テスト（システムテスト, ST）の段階でのシナリオテストのインプットとして利用することができます。

一方、お客様側としても、UAT（受け入れテスト）の段階で、テストケースを作成する際に同じくインプットとしてユーザーストーリーを利用できるのです。

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

ユーザーストーリーを中心にプロジェクトを推進することで、要件の整理だけでなく、後の工程でもそのメリットを享受できるのです。

おわりに

ユーザーストーリーはどのようなものか知っていても、実際にプロジェクトで利用するのは難しいと思われる方も多いと思います。

一方で、作成さえしてしまえば、山のような設計書や仕様書よりも大きな価値を提供してくれるでしょう。

是非、ユーザーストーリーを介してお客様とシステムベンダー間で大いにコミュニケーションが為され、良い関係性のプロジェクトが増えることを願っています。