システム開発の要件定義工程において、すべての要件を抽出することは非常に困難です。ここでは、この要件抽出を補助する手段のひとつとして、画面プロトタイプを用いて要件抽出を行う技法とその有効性を紹介します。
1. 要件定義工程における要件抽出のむずかしさ
困難な要件定義工程
要件定義工程は、システム開発において、発注側（お客様）の要件を調査し、IT化すべき要件を決定する重要な工程です。この要件が十分に引き出せるか否かでシステム開発の成功が決まってきます。しかし、現状ではこの工程において要件の抽出漏れが発生し、実装、試験工程においてお客様からの追加要件が発生してしまうことが多いのです。
この現状を解決すべく、要件を取り扱うツールや技法など様々なソリューションが存在します。ここでは、UIの観点を生かして要件抽出を行う技法を紹介していきます。
まず、要件定義工程における要件抽出の難しさを、架空の事例を例にとって説明します。
ある開発プロジェクトの要件定義工程では…
ある開発プロジェクトでは、画面の定義をMicrosoft のPowerPointで画面定義書として作成し、開発側とお客様が意識合わせを行っていました。この画面定義書では、画面については画面のイメージと画面項目を表形式で、画面の動きについては、画面遷移図でまとめていました。(図1)
図1
要件定義は無事終了し、開発は予定通りに進んでいるようみえました。しかし、試験工程において動く画面が出来てきたところでお客様から「想定していた動作と違う」と画面の動作に関するコメントが頻発してしまいました。中には、要件定義工程への手戻りが発生してしまうコメントも散見され、この開発プロジェクトでは対応に追われるようになってしまいました。
問題の原因は
この開発プロジェクトでは要件定義工程において、図1に示したように開発側とお客様の意識合わせは、紙面のみやり取りされていました。画面の動作に関する定義は、画面遷移図でなされていたものの、お客様は、画面の動作については明確に理解をできていなかったのです。このため、試験工程で動く画面に触ってみて初めて、開発中のシステムと自分のイメージの違いに気づき、コメントを出すようになりました。
一般的に開発プロジェクトにおいて、画面の定義が紙面などの動きをともなわないものでなされることは多いです。この時、上記の開発プロジェクトのように開発側とお客様側でシステムの動きに関するイメージが共有できていないことが頻発しています。これは、近年、画面の表現力が飛躍的に向上し、以前に比べて複雑なシステムの動き（インタラクション）を表現できるようになったものの、システム開発では動きに着目した開発がなされていないためだと思われます。このため、お客様にはシステムの動きが明確に伝わりません。このような問題を防ぐには、開発側とお客様で、システムの動きも含めた意識合わせを行うことが重要となってきます。
2. 画面プロトタイプを作成して利用のイメージを伝える
利用イメージを明確にする画面プロトタイプについて
お客様に利用イメージを伝える最も良い方法は、実際のシステムを使っていただくことです。しかし、要件定義工程においては、使ってもらえる実際のシステムは当然できていません。そこで、実際のシステムのように動作する画面プロトタイプを用いることがお客様に利用イメージを伝える一つの有効な手段となります。画面プロトタイプとは、実際のシステムに近い画面や画面の動きをお客様に伝え、開発側とお客様の意識のずれを見出し、解消を図るために用いられ、その実施方法にはペーパープロトタイピング、実装技術を用いたプロトタイピング、ツールを利用するプロトタイピングなど様々な方法があります。
ペーパープロトタイピングはその名前の通り、紙を使ってプロトタイプを作成する方法です。紙に画面を描き、画面上の動的に動く部分（たとえば、プルダウンメニューなど）は付箋などとして準備しておきます。お客様に利用イメージを伝えるときは、開発側が、動的に動く部分を状況に応じて手で張替えたり、画面に書き足したりして行きます。非常に安価で手軽な方法です。
実装技術を用いたプロトタイピングでは、画面を実際の実装技術(Htmlなど)で作成します。実際のシステムと違い、画面に表示される値などは典型的な値を静的にはめ込み、画面遷移についても条件分岐などのない単純なものとして作成することが多いです。より実際のシステムに近い画面を作り込むことができる半面、作成や修正にコストがかかりやすくなる方法です。
ツールを利用するプロトタイピングでは、ツールにてシステムを模した画面を作成します。画面の作り方は、ツールの仕様によって異なりますが、基本的には画面に対して、画面部品を貼り込んでいく形となります。さらに、ツールよっては画面の動きをよりリアルに表現できるものもあります。生産性や表現力が変わってくるため、より適した専用ツールを選定することが重要となってきます。
開発プロジェクトで画面プロトタイプを作成する際には、画面プロトタイプ作成方法を選択しなくてはなりませんが、その際の重要な観点となるのが、「利用イメージの伝達力」と「開発の生産性」でしょう。一点目の「利用イメージの伝達力」は、まさに画面プロトタイプを利用するその真価が問われることになります。より利用のイメージが伝わる画面プロトタイプの利用はお客様の要件抽出につながります。二点目の「開発の生産性」は開発プロジェクト全般に言えることであり、当然画面プロトタイプ作成においても考慮されるべきものとなります。この2つの観点を考慮した画面プロトタイプ作成方法の選定については、後ほど触れます。
画面プロトタイプを利用する時の注意点
画面プロトタイプ作成に当たって、まず問題となるのが、そもそも画面プロトタイプ作成が開発プロジェクトで受入れられにくいことです。時間やコストの面で余裕のない開発において、時間やコストをかけた以上に価値のある要件を抽出できるでしょうか。仮にもし画面プロトタイプが容易に作成できたとしてもそのような画面で要件が抽出できるのか、といった疑問があるためでしょう。この点については、後ほど適用例を挙げてその有効性を示します。ここでは、無事プロジェクトに画面プロトタイプが受け入れられた後に注意すべき点を挙げておきます。
画面プロトタイプを作る際の注意すべき点の一つに、作りこむ粒度の調整があります。あいまいに作ってしまうと、システムの利用イメージがお客様に伝わらず、本物らしく作りこみすぎると、コストがかかってしまうことがあります。また、システムの利用イメージが無事にお客様に伝わり、お客様から多くの要件を抽出できるようになる時も、実は注意が必要です。多くの場合、要件は画面の情報項目、レイアウト、機能、はたまたデザインなど多岐に渡って出されてしまい議論が発散してしまう可能性があるためです。
画面プロトタイプを最大限に活用する技法について
このため、画面プロトタイプの作成においても、作りこむ粒度の検討やお客様とのレビューの方法を整理した定型的な技法に則って実施するのが良いです。
図2
最初に、開発側の作成するプロトタイプの粒度の意識合わせを行い、作り込みすぎないように気をつけます。作成しているプロトタイプをなるべく早い段階でお客様に見せ、確認を取ることが重要です。
レビューの場においては、議論のスコープを定め、意見が発散しないようにします。たとえば、「基本フローの画面」「エラーの画面」「その他の画面」などといったステップ分けの考え方が有効です。それぞれのステップでアイディアを収集し、整理を行います。レビューにおいてステップ外のアイディアが出てきた場合は、そのアイディアを先のステップに先送りしつつ、議論をステップ内に戻るように促し、発散を避けるように調整します。
プロトタイプの作成を行い、お客様とのプロトタイプを用いたレビューも行ったうえ、可能であれば取り組みたいことの一つに、ユーザビリティ（使いやすさ）の確認があります。ユーザビリティの確認は、開発者がチェックリストを用いてチェックしたり、ユーザビリティの専門家が過去の経験をもとに確認したり、想定するユーザに実際に利用してもらって確認します。通常、要件定義工程におけるユーザビリティの診断では、診断対象がドキュメント中心となり、どうしても実戦にかける診断となってしまいます。しかし、要件定義工程において動くプロトタイプを作成しておくと、ユーザビリティの診断もより実践的になり、多くの改善点を抽出することができます。さらに、開発の初期工程であるために、実装技術による縛りなどがないために抽出した改善点への対応も容易となっています。
このように、プロセスに則ってプロトタイプを作成し、お客様とのレビューでプロトタイプを活用していくことで、お客様の要件をより多く抽出することができます。さらにユーザビリティの確認にプロトタイプを活用することで、システムの使いやすさも向上させることができ、その結果としてよりお客様に満足していただける質の高いシステム構築につながる要件定義を実施することができるようになります。
3. ツールを利用して画面プロトタイプを作成する
ツールによる画面プロトタイプ
ここで、上述した画面プロトタイプ作成方法を「利用イメージの伝達力」と「開発の生産性」の2つの観点で整理しておきます。
図3
画面プロトタイプ作成方法として、ペーパープロトタイピングは、容易に作成でき開発の生産性は良いものの、利用のイメージがお客様に伝わらない可能性があります。次に、実装技術を用いる方法は、利用イメージの伝達力がある半面、開発の生産性を落としてしまう可能性があります。最後にツールを利用したプロトタイプについては、ツールの仕様によってメリットが変わります。プロトタイプ作成に用いるツールには、Microsoft のPowerPointやVisio といった汎用なツールから、プロトタイプ作成に特化したツールがあります。このうち、特にプロトタイプ作成に特化したツールが「利用イメージの伝達力」「開発の生産性」という点で有効です。
主要なプロトタイプ作成ツールには、「Axure RP」「GUI Design Studio」「iRise」といったツールが挙げられます。いずれも、米国発のツールですが、「Axure RP」については、日本語化されています(NTT DATA AgileNetが日本語版を販売)。
4. 画面プロトタイプ有効性の検証
評価目的について
開発において、画面プロトタイプを用いることの有効性は実際のところはどうなのでしょうか。そこで、本稿の「2. 画面プロトタイプを作成して利用のイメージを伝える」で取り上げた要件抽出技法を実際のプロジェクトに適用し、評価を行いました。この結果、画面プロトタイプを用いたレビューを行うことで、紙面のみのレビューよりも要件抽出数が増加することを確認できました。この評価について、以下説明を行います。
評価方法
適用評価を行った開発プロジェクトは、30画面程度の社内で利用するウェブアプリケーションです。この開発プロジェクトに筆者も参画し、画面を検討し評価を行いました。画面の作成には、画面プロトタイプ作成専用ツールである、「Axure RP」を利用しました。 具体的な評価方法は以下のとおりです。
まず、開発中のある特定の画面に対して、まず紙のみで数回レビューを実施し、開発者側、お客様側からの要件を抽出します。次に、おおよそ要件の抽出が収束したところで、同じ画面について画面プロトタイプを用いて開発者側が動く画面をお客様に提示し、レビューを実施します。このとき、開発者側は頻繁に用いられる機能を中心とした利用シナリオを作成し、そのシナリオに沿ってレビューを行います。そのレビューにおいて紙のみでのレビューに加えて追加の要件がどのくらい抽出されるかを確認します。もし画面プロトタイプを用いたレビューが有効であるならば、紙のみでレビューを数回繰り返して要件が出切った思われる画面に対して、さらに画面プロトタイプを用いてレビューをすることで、新たに要件が抽出されるはずです。
評価結果
以下に、紙のみで2回のレビューを実施し、その後画面プロトタイプを用いたレビューを実施した際の、要件抽出の数の推移を示します。レビューの1回目（紙面利用）では非常に多くの要件が抽出されましたが、2回目（紙面利用）ではすでに要件の抽出が収束してきています。そのまま3回目を外挿するとほとんど要件の抽出は見込めません。しかし、実際にはレビューの3回目（画面プロトタイプ利用）で再び多くの要件が抽出されました。このことから、画面プロトタイプを用いることで要件抽出数が増加することを確認できました。
図4
なお、作成した画面プロトタイプの画面を用いて要件定義書を作成したため、画面プロトタイプ作成は、シナリオと動きの作り込みがオーバーヘッドとなりましたが、作成に専用ツールであるAxure RP を用いたため、修正作業などが非常に効率化でき、トータルとしての作業時間はこれまでの開発とほぼ変わらないものとなりました。
動くプロトタイプを用いることで抽出された要件とは
動くプロトタイプをお客様とのレビューで用いることで新たに抽出された要件は、主に画面の動きに関する部分（動的に変化するプルダウンメニューの中身）や画面遷移に関わる部分でした。画面の実際の動きや、遷移のイメージは静的な紙面ではなかなか伝えにくい内容であり、画面プロトタイプを用いることでこれらのことがより具体的に伝わったため、要件の抽出に至ったと思われます。このことからも定性的にも動く画面プロトタイプを使うことの有効性が確認できました。
5. まとめ
画面プロトタイプを用いた要件抽出方法の有効性について
要件定義工程において、画面プロトタイプを用い要件を抽出する方法は有効です。特に、画面プロトタイプを活用して、お客様から要件をしっかり抽出する技法を実践できるとより効率よく要件を抽出することができます。 また、画面プロトタイプを作成する際には、専用のツールを用いることも効果的です。お客様に利用イメージを明確に伝えることができつつ、開発の生産性も確保できるためです。 実際の開発現場において、ぜひとも画面プロトタイプを用いた要件抽出を実施していただき、開発プロジェクトに役立てていただけたらと思います。
作者紹介
株式会社NTTデータ 技術開発本部 ソフトウェア工学推進センタ 勤務。ユーザビリティに関する研究開発を実施しつつ、NTTデータが手掛けるシステムのユーザビリティ診断や設計支援などに従事しています。