フクロウの図表ラボ

アジャイル開発の要件定義どうやって進める？（1）

, ,
Fukurou

アジャイル開発においてはご存知の通り、要件定義では各工程を区切る開発手法（例：ウォーターフォール）とは異なるアプローチが必要です。本記事では、アジャイル開発における効果的な要件定義のプロセスを3つの主要なステップに分けて解説します。

要件のざっくりすりあわせ

プロジェクト初期の段階では、おそらく誰もが具体的なイメージを持っていない状態です。どんなユーザーに使ってもらうのか、どんな価値を提供するためのプロダクトなのか。まずはプロジェクトの大まかな方向性を決定し、ステークホルダー間で共通認識を持つことが重要です。この段階では、以下のツールを用いて要件を整理します。

ペルソナ

ペルソナとは、プロダクトやサービスの想定ユーザーを具体化した架空の人物像です。ペルソナを作成することで、開発チームは誰のために作るのかを明確にできます。

ペルソナについての詳細はこちらの記事が参考になります。

どこまで細かく属性を定義するか、ペルソナシートを用いるかどうか、などやり方はいくつかありますが、ここでペルソナを示す目的はマーケティングではなく「プロダクトの要件についてステークホルダーと合意すること」なので、細かすぎる必要はありません。

例えば、5W1Hが一文に収まる程度に表現することが目安です。
（what, who, when, where, why, and how）

  • 20代前半の大学生で、限られた予算内でトレンドを追った服を身に着けたい
  • 20代~30代の新婚夫婦で、節約しながらも高品質なインテリアを揃えたい
  • 30代後半の働く母親で、時間に追われながらも品質にこだわって料理食材をオンライン購入したい
  • 40代前半の独身男性で、平日オフィス勤務の空き時間に効率的に健康を維持したい
  • 50代の退職後のシニアで、半径10km以内のような近所のコミュニティでできる新しい趣味を見つけたい

ユースケース

ユースケースは、（一般的な定義では）システムと利用者の相互作用＝インタラクションを記述したものです。ちょっと分かりづらいですが、つまり、ユースケースが記述されることの効果は「ユーザーがシステムに期待する機能がわかる」ということです。

ユースケースについて詳しくは、以下記事もご参照下さい。

ペルソナを示したことにより、誰にどんな場面・目的で使われるプロダクトか？が分かったので、具体的な機能をざっくりと書き出します。

ただ、この文脈でのユースケースは例外処理などをこと細かく書き出すというよりは、アクターと正常フローを書き出して、ステークホルダーと認識を合わせる、ぐらいのライトな使い方で十分です。

ここでユースケースを利用する意図としては、いきなりユーザーストーリーから記述するのは難易度が高いため、ワンステップ挟むと進めやすくなるという狙いです。

（オプション）ワイヤーフレーム

ワイヤーフレームは、UIの簡易的な設計図です。管理画面の機能やボタン、コンテンツの配置図と捉えて下さい。その配置から機能の全体像を把握（想像）できます。

ただし、このタイミングで利用するワイヤーフレームに高い「正確性」は必要ありません。ボタンの位置、大きさ、は重要でなく、この画面ではこの機能が使える。ということが重要なのです。

具体的な例は、こちらの記事（英文）で記載されているようなものです。

プロダクトデザインの出発点として記述される”正確性の低い”ワイヤーフレームの例

描画ツールすら必要なく、手書きレベルで問題ないので、このようにページが遷移し機能が利用できるというイメージを紙芝居的に示しています。このように、ワイヤーフレームも初期のステークホルダーとの認識合わせで利用することができます。

（オプション）ストーリーボード

ストーリーボードは、ユーザーの行動や体験を一連の流れとして視覚化したものです。具体的なアウトプット形式は「理想とするユーザーの体験」を絵コンテのようなストーリー仕立てで示したものです。

詳細はこちらの記事で丁寧にまとめて下さっています。

記事内にも記載がある通りストーリーボード自体は「UXデザイン」の文脈で登場することがほとんどです。

ですが、アジャイル開発では機能の要否、実現方法などをメンバーが継続的に議論しながら良いプロダクトを生み出すという性質上、ストーリーボードで示されるUXはまさに、アジャイル開発では関わる人すべてが、エンジニアまで意識すべきことです。

ストーリーボードもまた、アジャイル開発初期のステークホルダーとの認識合わせで利用することができます。

いきなりユーザーストーリーは難しい

アジャイル開発だからといって、いきなりユーザーストーリーを記述することは実は難しい作業なのです。料理に例えるなら、肉じゃがを作るときのじゃがいもを切るというユーザーストーリー（！）を記述するとします。

「肉じゃがを作るプロセス」の全体がわかっていない状態で、「じゃがいもを切ること」だけにフォーカスした記述は、Aのようなものになりそうです。

A：「料理人はじゃがいもを一口大に切りたい。というのも、食べやすくするためだ」

一方で、この先にどんなプロセスがあるか分かっている場合は、Bのような記述もできます。

B：「料理人はじゃがいもを一口大に切りたい。というのも、他の食材と同じタイミングで火が通るように調整するためだ」

どちらが肉じゃがを美味しく作れそうですか？Bの記述のほうが”よく分かっている”気がしますよね。このように、良い要件を設定するためには、全体像を理解しながら考えるというテクニックは非常におすすめです。

また、全体像を把握することはもう1点メリットがあり、それは網羅性の確認です。ユーザーストーリーを記述し終わった段階では、その数は20~50になるので（もっと多い場合ももちろんありますが）、ぜひワンステップ挟んでおきましょう。

まとめ

アジャイル開発における最初の第一歩、ざっくりとした要件のすり合わせについて、その方法をご紹介しました。

アジャイル開発＝ユーザーストーリー！という認識が広まりつつあるかと思いますが、ユーザーストーリーでやや細かい要件（場合によっては機能そのもの）が記述されるその前に、全体像を把握できるツールで認識合わせができるとコミュニケーションをよりスムーズにすることができます。

続きはこちら👇️

この記事が誰かの助けになると思われましたら、ぜひシェアいただけると嬉しいです。

PVアクセスランキング にほんブログ村