要件をどう取り扱うか--アジャイル開発で重視すべきは「ユーザーストーリー」

吉原庄三郎 (ウルシステムズ) 2016年02月15日 07時30分

  • このエントリーをはてなブックマークに追加

「要件」を明確に理解している顧客はいない

 今回はアジャイルにおける要件定義を取り上げる。要件定義は、業務システムに対してアジャイル開発を適用する際、最大の関門となるフェーズである。失敗原因の大半を占めるといっても過言ではない。逆に言えば、要件定義のコツを押さえれば成功の確率を高められる。

 本題の前に、最初に「要件」と「要求」という言葉があるが、どちらも「Requirements」である。要求を取りまとめたアウトプットが要件であるといった語感はある。しかし、些細な違いであり、どちらも同じ意味と考えた方がいい。また、ここでの要件とはシステム要件である。ビジネス要件や業務要件ではない。

 まずは、要件定義に対する考え方を整理しよう。アジャイル開発では、「顧客は要件を正確に理解していない」という前提を持っている。この課題認識を納得できる人もいれば、腑に落ちない人もいるだろう。「なぜ、自分が欲しいものすら正確に分からないのか」と。

 しかし、考えてみてほしい。言うまでもなくシステムは何らかの課題を解決するためのものだ。多くの場合、作り始める時点では未知のものである場合が多い。「こういうシステムがあれば、課題が解決できるはず」という仮説段階のものなのだ。

 仮説が正しかったかどうかは、検証してみないことには分からない。「実際に課題を解決できるのか」「もっとよい解決方法はないのか」ということは、実際に動くソフトウェアができあがらないことには分からないのだ。仮説が間違っていたと気付くこともあるだろう。「こうではなく、ああした方がよかった」と、当初の要件を覆すのは無理からぬことなのだ。こうした考え方を顕著に表したのが、次の文章である。

「まずは(組織内または組織外の)顧客が、システムが解決すべき課題のアイデアを思いつく。だが、顧客はソフトウェアが何をすべきかは正確にはわからない」(Kent Beck(著)、Cynthia Andres(著)、角征典(翻訳)、書籍『エクストリームプログラミング』より抜粋)

 ウォーターフォール開発では初めに要件を確定させる。後から間違いに気付いた場合は仕様変更として扱う。仕様変更は基本的にイレギュラー対応である。スケジュールを変更して要件定義書を書き直し、影響範囲を調査して設計や実装をやり直す。デグレードの確認も欠かせない。仕様変更ほど開発者に忌み嫌われるものもない。

 しばしば、仕様変更は発生する。「また、仕様変更だよ」。開発者の身としては愚痴の一つもこぼしたくなるのも分からなくはない。

 しかし、アジャイル開発ではこう考える。「仕様変更は顧客が悪いのではない。そもそも、最初から要件を明確に詰めることなど困難なのだ」と。そもそも、プロセスが悪いから上手くいかないのだというスタンスなのだ。

 アジャイル開発は、イテレーションの単位で計画を立てる。これは変更を受け入れるためだ。変更があれば、それを次のイテレーションのタスクとして盛り込めばよい。顧客が要件を完璧に予見できない以上、仕様変更が起こることは避けられない。仕様変更は起きるものとして考えて、それを受け入れられるプロセスを取っているのだ。

ユーザーストーリー

 アジャイル開発では要件という言葉を使わない。その代わりに「ユーザーストーリー」という概念がある。これは顧客の意図や要求の断片である。開発とフィードバックのサイクルを回す上での手がかりとなるもの、といった意味合いだ(エクストリームプログラミング=XPでは単にストーリーと呼ぶ。スクラムガイドには明記されていないが、やはりユーザーストーリーを作成する)。

 ユーザーストーリーはプロジェクトの初期に顧客、もしくはスクラムでいうプロダクトオーナーが作成する。最初から全部を出し切る必要はない。無理なく思い付く範囲で主要なものを書き出すのである。後からいつでも思いついたときに追加してかまわない。

 ユーザーストーリーの内容はざまざまだ。「従来と同じレスポンスタイムで5倍のトラフィックを処理する」といった性能に関するものもあれば、「会員は自分の購買履歴を参照できる。それによって過去の支払金額を確認できる」といった機能に関するものもある。

 重要なのは、ユーザーストーリーは絶対的なものではないという点だ。それを満たしたからといってシステムが完成するわけではない。これが要件と大きく異なる点だ。アジャイル開発では顧客が絶対的で普遍的な要件を口にすることを期待していない。

ZDNet Japan 記事を毎朝メールでまとめ読み(登録無料)

  • このエントリーをはてなブックマークに追加

この記事を読んだ方に

関連ホワイトペーパー

連載

CIO
IT部門の苦悩
Rethink Internet:インターネット再考
インシデントをもたらすヒューマンエラー
トランザクションの今昔物語
エリック松永のデジタルIQ道場
研究現場から見たAI
Fintechの正体
米ZDNet編集長Larryの独り言
大木豊成「仕事で使うアップルのトリセツ」
山本雅史「ハードから読み解くITトレンド放談」
田中克己「2020年のIT企業」
松岡功「一言もの申す」
松岡功「今週の明言」
内山悟志「IT部門はどこに向かうのか」
林 雅之「デジタル未来からの手紙」
谷川耕一「エンプラITならこれは知っとけ」
大河原克行「エンプラ徒然」
内製化とユーザー体験の関係
「プロジェクトマネジメント」の解き方
ITは「ひみつ道具」の夢を見る
セキュリティ
「企業セキュリティの歩き方」
「サイバーセキュリティ未来考」
「ネットワークセキュリティの要諦」
「セキュリティの論点」
スペシャル
ざっくりわかるSNSマーケティング入門
課題解決のためのUI/UX
誰もが開発者になる時代 ~業務システム開発の現場を行く~
「Windows 10」法人導入の手引き
ソフトウェア開発パラダイムの進化
エンタープライズトレンド
10の事情
座談会@ZDNet
Dr.津田のクラウドトップガン対談
Gartner Symposium
IBM World of Watson
de:code
Sapphire Now
VMworld
Microsoft WPC
Microsoft Connect()
HPE Discover
Oracle OpenWorld
Dell EMC World
AWS re:Invent
AWS Summit
PTC LiveWorx
より賢く活用するためのOSS最新動向
古賀政純「Dockerがもたらすビジネス変革」
中国ビジネス四方山話
ベトナムでビジネス
米株式動向
日本株展望
企業決算