ユーザー要件を引出すテクニック： ユースケースかストーリーボードか：The Rational Edge（2/2 ページ）

» 2006年02月01日 12時00分 公開
[Jochen Krebs（IBMシニアITスペシャリスト），＠IT]
前のページへ 1|2 　　　　　　

◆ ユースケースとストーリーボード

　ソフトウェアエンジニアには、これらのユーザーのニーズ管理に役立つツールが用意されている。その好例の1つが、ソフトウェアエンジニアリングのありとあらゆる成果物を描写する目的で普及しているUnified Modeling Language（UML）だ。もちろん、ソフトウェアエンジニアにとっては自分たちが理解する言語で資料を受け取る方が良いが、それは非現実的だ。UML以外でも、言語の壁を橋渡しするアプローチとしては、ユーザーでも短い間隔で作業に指示を出したり、機能性に関するフィードバックを提供できる反復インクリメンタル開発が成功している。さらに、ユースケースやストーリーボードを反復インクリメンタル開発と組み合わせることが、ソフトウェアプロジェクトの活性化や、不足要件の早期解明にとって役立つ。ユースケースを用意する前に最も重要なのは、これらの資料の目的とユーザー層を明確にすることだ。

　ユースケースとストーリーボードについて探究し、要件分析におけるこれらの明確な役割を検討してみよう。

● ユースケース

　ソフトウェアエンジニアの間では、機能要件を取得するためのアプローチとしてユースケースの人気がかなり高まってきた。ユースケースがサポートするシナリオ主導のアプローチを用いれば、エンジニアはうまく絞り込まれた要件の重要な部分だけに注力できる。そして、品質保証チームのメンバーも、インプリメントされた構想を同じシナリオを使ってテストできる。また、そのうれしい副作用として、プロジェクトマネージャやエンドユーザーまでもが、プロジェクトの進展を監視し、プロジェクトチームにとって基本的なフィードバックを提供できる。この形態のユースケースは、特定の業務シナリオの本質を把握するためにある。ユースケースのフォーマットは、技術の詳細部分や議論に邪魔されるのではなく、1人以上の関係者とシステムとのやりとりを把握することに重点を置いている。ユースケースを調査することで、関係者が実現したいと考えているものや、着手から実現までの手順を学ぶ。図1のような簡略化された階層化アーキテクチャでは、通常はユースケースが中間層の要件を集めてシステムの機能を実現する（クラス／オブジェクトモデル）。

ALT 図1 階層化アーキテクチャにおけるユースケースのターゲットレイヤ

　ユースケースは、技術（ハードウェアやソフトウェア）に踏み込まずにシナリオを描写するため、業務ロジックが置かれる中間層を構築するエンジニアは、イベントフローが説明する機能に集中できる。ユースケーススタイルのもう1つの利点は、シナリオが自然言語で書かれていて、ユーザーがその意味するところを論評および議論できる点だ。これで、エンジニアはユーザーと同じ言葉を使って言語分析を行い、要件を1つずつソフトウェアに変換できるようになる。プロジェクトメンバーの意見が基本的なユースケースで一致すれば、これが企業とITの間の契約の役割を果たすことになる。

　だが、場合によって基本的なユースケースが異なるレベルで抽象化される欠点もある。シナリオを確認するユーザーは、自分の世界でシナリオを考える。これにより、ユーザーとこのエンジニアとの間に距離が生まれてしまう。このアプローチのもう1つのマイナス面は、機能のない要件が無視される場合があることだ。

● ストーリーボード

　ユースケースが映画のあらすじなら、ストーリーボードは台本だ。ユースケースとは対照的に、これらのストーリーボードは非常に現実的かつ具体的なコンセプトを利用するようになってきた。これには、ユーザーインターフェイスの例や、ハードウェアの利用法まで含まれている。このアプローチは、（関係者の名前を明らかにするなど）ストーリーをパーソナライズしたり、漫画的な要素をユースケースに加えることで、さらに踏み込むことができる。ストーリーボードには基準がないため、その内容は起草者の創造性に応じていくらでも拡大する。ストーリーボードは、電子フォーマットでまとめる場合もあれば、チームがマーカーや付箋紙などの各種メディアを使ってホワイトボードに書く場合もある。ワークショップの成果物は、これをスキャンしたり、写真を撮ることで、結果を保存および共有する。

　ストーリーボードはそれが描写するソフトウェアシステムとは独立して単独で存在するため、通常のプロトタイプと比較して多くの利点がある。クラッシュはしないし、大人数のグループでもかなり容易に共有できるし、システムがすでに開発済みだという誤った印象も与えない。さらに、フィードバックの受け入れも簡単だ。

　しかし、ストーリーボードの最も大きな問題の1つは、これがすぐに古くなってしまうことだ。当初定義したユーザーインターフェイスは時間の経過に伴って変わることが多く、これが保守の足かせとなる。

◆ 形態は機能に追従するだけなのか？

　建築家のLouis Henry Sullivan（1856‐1924）は、「形態は機能に追従する」という言葉を生み出した。これは、1920年代のBauhaus運動から生まれた概念だ。所定のデザインが持つ機能性だけに重点を置き、重要な機能からその外観と形態を導き出すという考え方だ。Adolf Loos（1870‐1933）は、自身の「装飾と犯罪」というさらに教訓的な概念によってこの概念を拡大した。これらのデザイン理論は建築物だけに限定されるものでなく、家具などの各種大衆文化財のデザインにも当てはまった。例えば、ジェット旅客機の形態は、隅から隅までそのほとんどが機能性から生まれたものだ。

　ソフトウェア開発業界においては、「形態は機能に追従する」というデザイン概念は、ユースケースと同等の概念になる。システムにおけるユーザー操作の「構想」は、これをサポートする技術より変化の可能性が低い。基本的なユースケースから業務レイヤ全体を構築し、そこからゆくゆくはユーザーインターフェイスを作り出して、それがHCIの配置や外観を生み出す。問題なのは、「ストーリーボードは必要か？」という点だ。

　まあ、これはユーザー層と目標に依存する。ソフトウェアエンジニアリングに対する影響は、ストーリーボードよりユースケースの方が大きいことにほとんど疑問の余地はないだろう。入念に定義され、システムの機能性とビジネスルールを管理するだけでなく、複数のHCI（例えば、Webや携帯電話本体で携帯電話の通信記録をチェックするなど）を提供するオブジェクトモデルの原点であり、基礎であるのがユースケースだ。従って、堅牢な業務レイヤが極めて重要で、ソフトウェアエンジニアリングでは最も重要となり、これがユースケースに反映する。一方のHCIは、業務レイヤの必要な情報を提供および表示し、そこにはデータと機能性のカギがあり、これがストーリーボードに反映する。開発チームが提案したGUIをクライアントと一緒に「破棄する」のを手伝うことも、GUIへの準拠を保証することも、ストーリーボードの目的ではない。例えば、HCの視覚的基準に関する書籍は多数ある。ユーザーインターフェイスと参考書が1つあるだけで、ルック＆フィールに関する議論が簡単に始まる。そこから何か新しいものを吸収できないのなら、個々のユーザーインターフェイスを描写することに必ずしもメリットがあるわけではない。

　しかし、ストーリーボードはソフトウェアエンジニアリングで見落とされがちに思われるニッチ手法として生き残る可能性がある。適切な場所で活用すれば、そのニッチ分野で極めて有効になる。ストーリーボードは、HCIやGUIのようにデザインの考え方をユースケース単独よりも明確にユーザーに伝える。これらは、ユーザーが理解しやすい実際の内容を提供してくれる。電子ゲームなど、HCIが極めて重要な一部の業界でシステムを成功させるため、ストーリーボードに一段と注目が集まっている。

　ある意味、ストーリーボード関連資料の最大の受益者はユーザーではなく、われわれソフトウェアエンジニアだ。ユースケースの説明に「経理担当者が請求番号を入力する」という部分があるとする。このユースケースを検討した場合、エンドユーザーである経理担当者は、このユースケースが請求処理に絶対不可欠な要素をとらえていることを認識し、単純に了解するかもしれない。しかし、かなり詳細なストーリーボードでは、この文章に図2のような簡易ダイアログボックスが追加される場合もある。

ALT 図2 ユーザーインターフェイスの例

　このサンプルGUIは、請求処理を経理担当者にとってもっと明確にし、この部分に注目させている。さて、この視覚的なストーリーボードを見たエンドユーザーの経理担当者から、「実際の請求番号は年とユニークな番号の2つに分かれている。でも、この図には口座番号のフィールドが1つしかない」という話が出てくるかもしれない。さらに、「ところで、年をいちいち入力したくないので、初期値を今年にし、必要に応じて上書きするようにしてほしい」ということにもなる。

　いま説明したシナリオでは2つのことが起こった。HCIに対するフィードバックが得られただけでなく、業務ロジックや機能も把握できたのだ。この例の場合、経理担当者は請求書を年別に保存している。この画面のモックアッブによって、われわれは実際に新機能要件を入手したのだ。先に出た図1の階層化アーキテクチャの例を振り返ると、ストーリーボードがプレゼンテーションレイヤだけでなく、業務レイヤも作成していることが分かった。確かに形態は機能に追従するが、ここで分かったように、機能も形態に追従するのだ。ストーリーボードはHCIを確認する手段を提供するとともに、要件を引き出す有益なテクニックともなる。従って、ストーリーボードは、図3のようにプレゼンテーションレイヤ、そしてオブジェクトモデルを示す中間レイヤという、ソフトウェアアーキテクチャの2つの全く異なるレイヤをターゲットにすることができる。

ALT 図3 階層化アーキテクチャにおけるストーリーボードのターゲットレイヤ

　「形態は機能に追従する」という言葉は、反復インクリメンタル開発が該当するソフトウェアエンジニアリングに特に当てはまる。

　ストーリーボードを最新の状態にしておく保守の負担（先に指摘した欠点の1つ）を軽減するには、適切なユースケースによって結果が記録された時点でその多くを破棄すればよい。

　ストーリーボードの作成は面白く、ソフトウェアエンジニアリングプロセスで最も重要な関係者である顧客にも好まれている。要件を引き出すテクニックとしてストーリーボードを使うことは、過小評価される場合が多い。これらは潜在的な新機能要件をかなり早い段階で発見するための極めて重要な機会を提供してくれる。ストーリーボードは、よく選んで利用すれば、将来のシステムの一部を調査したり、既存の機能を実証することもできる。これは、プロジェクトの初期フェーズにおいて対象範囲、スケジュール、およびコスト面にメリットをもたらす。

　筆者は自分のキャリアを通じ、ユースケースにスクリーンショットを含めるかどうかについて多くの白熱した議論を繰り返してきた。本稿がソフトウェアエンジニアリングにおけるストーリーボードの役割を明らかにし、要件を特定する必要が出た場合に役立つ新しい視点を示せたことを願う。

本記事は「The Rational Edge」に掲載された「Form feeds function: The role of storyboards in requirements elicitation」をアットマーク・アイティが翻訳したものです。

「The Rational Edge」バックナンバー
前のページへ 1|2 　　　　　　

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ