日本ソフトウェア科学会第 30 回大会 (2013 年度) 講演論文集

要求工程におけるプロトタイプからの UI 仕様書の生成支援
曽我 知央

伊藤 恵

ソフトウェア開発の要件定義段階では顧客と開発者の間に認識の違いが生じやすい．顧客との認識の違いを埋める手法の一つであるプロトタイピングを用いて画面遷移を伝えることができるが，プロトタイプを作るのにもコストがかかる．また，プロトタイプで得た要求を仕様書にまとめる必要が出てくる．一方で，画面遷移を伝える他の手法として，UI 仕様書を用いることができる．UI 仕様書はプロトタイプほどではないが画面遷移を分かりやすく伝えることができ，後の開発で仕様書として有用である．しかし，UI 仕様書には統一された記法がなく，開発者によって異なる記法の UI 仕様書になってしまうため，こちらも，UI 仕様書の管理や転用が難しいという問題を抱えている．
この様な問題はあるが，プロトタイピングには顧客にシステムの動作が伝わりやすいという利点がある．また，UI仕様書には顧客にシステムの UI を伝えるだけでなく後の開発で仕様書として使えるという利点があり，互いを補完しあっているので開発現場ではどちらも作成したほうが良いと考えられる．本研究ではまず，ツールの提案に伴って必要となる，UI 仕様書の定義を行う．そして，プロトタイプ作成時にフォーマットをそろえた UI 仕様書を自動生成できるツールを提案することで，要件定義段階における作業効率の向上や顧客と開発者の認識の差異低減を目指す．

In the requirements deﬁnition phase, perception gaps occur between customers and developers. To curtail
the perception gaps, software prototyping which can tell customers to the screen transitions is often used,
but it is costly for making prototypes. In addition, it is needed to create speciﬁcations from the requests
got by prototype. On the other hand, it is possible to use UI Speciﬁcations for another way to tell screentransitions. UI Speciﬁcations are possible to tell easy-to-understand screen transitions, and are useful as
one of the developing documents in later development. However, UI Speciﬁcations have problems of difﬁcult to handle and divert. Because UI Speciﬁcations have no standardized notation, so developers makedisjointed format UI Speciﬁcations. Although there are such problems, Prototyping has an advantage to telleasy-to-understand system behavior for customers. And UI Speciﬁcations have advantages not only to telleasy-to-understand system behavior but also be able to use in later development. And these are complemented each other. Therefore, we consider both of them should be created in the development ﬁeld. In thisstudy, it is needed to deﬁnes UI Speciﬁcations. After that, to propose a tool that can automatically generate
UI Speciﬁcations have deﬁned notation when Prototyping. This study aims to improve working eﬃciency
and to reduce the perception gaps between customers and developers in the requirements deﬁnition phase.

うことである．認識が異なっているまま上流工程を終

1 はじめにえ下流工程に入ってしまうと，認識の相違からくる手

1. 1 背景戻りが発生する．その結果，工期の延長，コストの増現在，ソフトウェアの開発の上流工程において，顧大，納期遅れといったことが起きている．このような客と開発者の認識の相違という問題が発生している．

問題を解決するために様々な取り組みがされてきた．

これは，顧客が開発してもらいたいものと開発者が開その中にプロトタイピングと UI 仕様書がある．この発しようとしているものの認識が異なっているとい2 つを導入することで顧客と開発者の認識の違いを埋Generation Support of the UI Speciﬁcation from thePrototype in the Requirements Process.
Tomohisa Soga, Kei Ito, 公立はこだて未来大学システム
情報科学部, Dept. of Systems Information Science,Future University Hakodate.

めることが期待される．しかし，プロトタイピングとUI 仕様書それぞれに問題点もあり導入が進んでいるとは言いがたい．プロトタイピングと UI 仕様書の問題点については後述する．

1. 2 目的
本研究では，要件定義段階における顧客と開発者間で発生する認識の相違をプロトタイプと UI 仕様書を活用し追加コストを少なく抑えて解決することを目的とする．具体的にはプロトタイプから UI 仕様書を自動生成するツールを提案する．これにより，UI 仕様書作成で発生するコストを削減し顧客と開発者の認識の差異を埋める支援を行う．また，ツールの提案に伴って UI 仕様書の具体的な定義も行う．

2 関連研究2. 1 現状の分析と考察
顧客の要求をすべて引き出せているか，また開発者の見解に相違は無いかを確認せず開発を進めてしまうと，手戻りが発生する可能性が高い．手戻りが発生した場合，要求工程まで戻るのには相応のコストがかかり，納期を守れない等の問題が発生する．特に，ソフトウェア開発のおよそ 5 割を占めているウォー

図1

プロトタイピングの流れ

ターフォールモデル [1] は，手戻りの際のコストが他のモデルと比べて非常に大きい．業界ではスパイラル

3. レビュー エンドユーザーを含む顧客にプロトモデル等のほかの開発モデルを採用検討中のところタイプを実際に使ってもらい，追加点や修正点なもあるが，いまだにウォーターフォールモデルがソフどのフィードバックをもらう．

トウェア開発環境の中心である．そのため，手戻りを減らすことは急務であると考える．

4. プロトタイプの改良 フィードバックを使って要求仕様とプロトタイプの両方を改良する．変更が加えられたらレビューと改良を繰り返す．

2. 2 プロトタイピング

プロトタイプを開発していくことで，顧客の要求をシプロトタイピングはソフトウェアに限らず，様々なステム開発の上流工程で確実に認識でき，顧客の望む工業製品の開発に用いられる手法の一つで，設計の早ソフトウェアを開発していくことができる．また，プい段階で実際に動く製品の試作品の作成と検証を繰りロトタイピングの主な利点として，開発者側がシステ返すことで，仕様の検討や細かな設計を進めていくもム開発の早い段階で顧客側からのフィードバックを得のである [2]．ソフトウェア開発の場合，一般にソフられるという点と，顧客が試作品を検証できる点があ

トウェアプロトタイピングと称され，主に要件定義段る．これらの点はいずれも，顧客と開発者の認識の違階で顧客の要求から仕様を策定するのに用いられる．

いを埋めることに有効である．プロトタイプを作成す

一般的にプロトタイピングによる仕様策定は以下のるコストはかかるが，後々の工程で手戻りの発生が抑流れ [3] で行われる (図 1)．

えられ，開発の時間と費用を削減することができる．

1. 要求分析 基本要求を見定め，必要とされる情

また，プロトタイピングには様々な手法があるが，そ報の入出力を確定する．セキュリティなどの詳細

れらは大きく分けて，使い捨て型と進化型の二種類にはここでは無視する．

分けることができる．使い捨て型は，作成したプロト

2. プロトタイプ開発 ユーザインタフェースのみからなる最初のプロトタイプを開発する．

タイプを顧客に見せた後すぐに破棄してしまう．これは，顧客が要求仕様について即座にフィードバックできることを目的としているためである．また，使い捨UI の設計に関係する認識の差異を低減できる．UI やて型は素早さを重視しており，プロトタイプの中身よ

画面遷移を仕様書に記したドキュメントとして，画面りも顧客に理解してもらえる外見が重視されやすい．

遷移図や画面設計書，UI 設計図等があるが，本研究進化型はプロトタイプを最初に作る段階から中身をにおける具体的な UI 仕様書の定義については 3. 1 で重視し作成していく．これは進化型によって作成され述べる．また，本研究では UI 仕様書を用いたユーザるプロトタイプが作りこまれていくたびに完成品にビリティ評価や評価手法に関しては言及しない．

なっていくためである．よって進化型のプロトタイプ

2. 3. 1 UI 仕様書の問題点はレビュー後に破棄されない．ただし，進化型では，本研究に関係のある UI 仕様書の問題点について以開発者はシステム全体を一気に開発するのではなく，理解している部分から先に開発するため，全体像が見えるまで時間がかかる．

下に述べる．

1. 統一された記法がない

UI 仕様書は，他の仕様書のように統一された記法が定義されている

2. 2. 1 プロトタイピングの問題点

わけではない [5]．よって，作成者や見る人によっプロトタイピングの問題点のうち，本研究に特に関てフォーマットや捉え方が変わってきてしまう．

わりのあるものを，以下にまとめる．

1. プロトタイピングに時間をかけすぎる プロト
タイプは最低でも画面遷移等を顧客に提示できこれによりひとつの仕様書を共有することが難しくなる．

2. 要件定義段階での作成の困難性

UI 仕様書は，ればよいので，プロトタイプを複雑すぎるものに主に要件定義段階で作成され，ユーザビリティ評作りこむ必要はない．また，そもそもプロトタイ価等に用いられる．しかし，ユーザビリティ評価

ピングの利点として，後の工程の負担を減らすこまで可能な UI 仕様書を作成するのは相応のコスとにある．プロトタイプを作りこんでしまうと，トがかかってしまう．

当初の利点が欠点になってしまい得る．

3. UI 仕様書への理解の低さ

UI 仕様書は UI 設

2. 不十分な分析 限定的なプロトタイプに着目し計を行うにあたって非常に有用なものである．してしまうことで，開発者の要求分析が不十分なもかし，システム開発自体は UI に言及せずとも進のになってしまうことがある．つまり，機能の限めていくことができてしまうため，UI 設計を行定されたプロトタイプは顧客の要求を限定的にうためのドキュメントを作成するという意識が開しか得られない可能性がある．

発現場にて希薄になっていると思われる．

3. プロトタイピング後の工程 プロトタイプは顧客側から要求を引き出し，認識の差異を埋めるた3 生成支援めのものである．よって，後の工程ではそのプロ生成支援ツールの提案の前にまず，3. 1 節で UI 仕トタイプをもとに開発するのではなく，プロトタ様書の定義を行う．そして，その定義に則って 3. 2 節

イプによって引き出した顧客の要求から開発を進で生成支援ツールの提案を行う．

めていく必要がある．したがって，顧客から引き出した要求を更に仕様書にまとめる必要がある．

3. 1 UI 仕様書の定義
まず，生成支援の説明の前に本研究での UI 仕様書

2. 3 UI 仕様書の定義を述べる．本研究で扱う UI 仕様書は八木大彦

UI 仕様書とは，ユーザインターフェース仕様書の氏の提唱された UI 仕様書 [4] を参考にし，具体的にことである．主に，開発するシステムのユーザビリ定義していく．本研究の UI 仕様書を構成するのは，ティを評価際に用いられる [4]．これにより，システ

画面設計図，オブジェクト作動図，画面遷移図であム開発に関係する専門用語などを使用せずに顧客にる．すべての図には画面の種別のための ID を付与す

開発者側のシステムのイメージを伝えることができ，る．あるチケット予約サイトを参考に 3. 1. 1 節から3. 1. 3 節で説明する．
3. 1. 1 画面設計図
まず，画面設計図の説明をする．表示される画面全てと，画面内に重複して現れるサブ画面から構成され，画面の基礎構成を定義する (図 2)．表示される画面は具体的に，初期画面や終了画面，作業画面等がある．サブ画面はガイダンス画面，エラー画面，設定画面等である．これらの画面を画面設計図に作図する．
作図の構成としては，画面全体の構成，表示項目とレイアウト，画面のタイトル名称の表示，クローズボタンの表示位置とレイアウト，画面内の記号や言語，これら 5 つを元に作成する．図 2 を例に説明すると，
図 2 上の画面では画面 ID のほか一部だが表示される画面を作図してあり，画面の表示項目として 3 つのボタン，トップページという画面のタイトルが表示されている．図 2 下の予約内容画面では，画面全体のレイアウトが入力されており，画面のタイトルが画面名として記入されている．また，公演日やチケット枚数のチェック項目や入力フィールドなど表示項目とその図2

レイアウトが描かれている．

画面設計図の一部

3. 1. 2 オブジェクト作動図
次にオブジェクト作動図の説明をする．画面内に存在するボタン等の入力操作を受け付けるものすべてのオブジェクトとそのアクションを記述する (図 3)．
具体的に，入力を受け付けるボタン類，文字入力エリア，チェックエリア，ハイパーリンクされた文字列などを記入し，それぞれの動作とその動作結果などを示す．それぞれの動作は，マウスカーソル合わせ時，クリック時 (ダブルクリック時)，などに分けて記述する．また，そのオブジェクトのアクションフローも作成する．アクションフローはオブジェクトにマウスを合わせた場合，オブジェクトをクリックした場合，オブジェクトを選択した場合，操作後のアクションを図3

オブジェクト作動図の一部記述する．図 3 では，図 2 の予約内容入力画面のオブジェクト作動図を記述している．予約内容入力画面

る画面すべてのオブジェクトに対し，作成する．

における入力操作を受け付けるオブジェクトは公演

3. 1. 3 画面遷移図

日のチェックボックスとチケット枚数の入力フォーラ

最後に画面遷移図について説明する．各選択肢ごム，確認と戻るボタンである．そしてそれぞれのアクとに表示されるすべての画面を矢印等で結ぶことでションとアクション結果を書いている．また，図 3 で表現する (図 4)．また，画面の名称，操作可能なすべ

は，オブジェクト作動図はひとつのみだが，表示されての選択肢，ポップアップ画面など各画面に表示され図4

画面遷移図の一部ている主な表示内容を合わせて記入する．画面遷移の分かりやすさのために画面の概要は記入する．図 4

図はその画面の遷移を主として表しているため，画は今回の UI 仕様書の構成例として挙げたチケット予面の構成やボタンの挙動といった点は作成コストを約サイトの画面遷移の一部である．画面の全容と画抑えるためにすべてを詳細に書かないが，ユーザへ面遷移に関係ある操作可能な選択肢とそこから伸び，テスト支援ツールだが，利用者のブラウジングを記録して再帰的にテストすることができる．Selenium のブラウジングを記録する機能に着目し，画面遷移の記録を目指す．
また，生成支援ツールによって自動生成される UI
仕様書は Excel ファイルとして保存される．単なる画像ファイルとしてではなく，Excel ファイルにすることで再編集が容易になる．

3. 3 適用例
本研究で提案するツールは要件定義段階での運用を想定している．また，プロトタイプとその後のプロ
図5

支援ツールの構成図

トタイピングを考慮すると，Web システムの開発で使い捨て型プロトタイピングを適用しているシステ画面遷移を表す矢印が記述されている．

ム開発が望ましい．図書館の Web システムのログイン画面のプロトタイプ (図 6) において，具体的に説

3. 2 UI 仕様書生成支援ツールの作成明する．プロトタイプには，ログイン画面とログイン

具体的にプロトタイプから UI 仕様書を自動生成す成功画面，ログイン失敗画面がある．ログイン画面にる支援ツールを作成する．プロトタイプから UI 仕様はユーザ名とパスワード入力フォーム，そしてボタン書を生成するために，Web アプリケーションテストがある．ログイン成功画面にはアクションを起こすもツールの Selenium を用いてプロトタイプの画面遷移のはなく，ログイン失敗画面にはログイン画面に戻るを記録する．その記録された画面遷移を 3. 1 の定義ボタンがある．に則って UI 仕様書に変換することにより，プロトタ開発者は，ブラウザ上で Selenium を起動し，画面イプから UI 仕様書を自動生成する．その結果，要件遷移を行うことでプロトタイプの画面遷移を記録する

定義段階において，プロトタイプと UI 仕様書の二つことができる．Selenium によって生成された記録をを顧客に見せることができ，UI 仕様書を後の工程で本研究で提案するツールに通すことによって，UI 仕使うことができる．

様書が自動生成される．生成された UI 仕様書にはロ

3. 2. 1 対象とするプロトタイプ

グイン画面の画面遷移図をメインとして，画面設計図プロトタイピングが適用できるソフトウェアは数多(図 8)，オブジェクト作動図 (図 9) がある．画面遷移

くあるが，本研究で対象とするプロトタイプはブラウ

図は開発者が Selenium によって遷移した画面が記録ザ上で画面遷移を確認することができるものとする．

される (図 7)．今回の画面遷移図には画面が 3 つ描か3. 2. 2 支援ツールの構成れている．また，各画面を結ぶ矢印は 3 本ある．オ

本研究で提案する支援ツールは，プロトタイプ開発

ブジェクト作動図は画面遷移時に選択したオブジェク者がブラウザ上で，作成したプロトタイプの画面遷移トとそのアクションが記述される．オブジェクト作動を行うことで UI 仕様書または UI 仕様書の一部を自図は，各画面ごとに作成するので 3 つあり，今回のオ動生成できるものである．具体的にはブラウザ上で開ブジェクトはすべてのオブジェクト作動図あわせて，発者がプロトタイプを動かした際，その画面遷移を記

図 7 に描かれていないオブジェクトも含めて，3 つの録することで，UI 仕様書を自動生成する (図 5)． プオブジェクトを記述する．画面設計図は画面遷移時にロトタイプの画面遷移を記録する方法だが，アプロー表示された画面が出力される．出力される画面数は 3

チのひとつとして Selenium がある．Selenium は元々つ．今回はサブ画面がないのでサブ画面は出力されな

図7

図6

プロトタイプの画面遷移図

ログイン画面のプロトタイプの一部
図8

プロトタイプの画面設計図の一部

い．開発者は出力された各ドキュメントを必要に応じて適時変更，更新していく．

プロトタイプでは開発者が口頭で説明していたこと

本研究のツールは UI 仕様書を作成するコストが抑も仕様書として顧客に伝えることができる．さらに，えられる．また，UI 仕様書はドキュメントなので，UI 仕様書は画面設計を含まない画面遷移図より UI

タイプとは違い，ドキュメントであることの利点もある．ドキュメントであるため，プロトタイプを実行する手間を省くことができ，全体像がつかみやすい．これは，開発現場での利点となり作業効率の向上につながる．

4. 2 認識の差異の点での考察
認識の差異の観点から考察する．まずプロトタイ
ピングだが，プロトタイピングを行う時点で顧客と
図9

プロトタイプのオブジェクト作動図の一部

開発者の間の認識の差異は低減されていると考える．
しかし，プロトタイピングだけでなく UI 仕様書も導が顧客に伝わりやすく，開発者間でのイメージの共有入することにより，更に認識の差異を低減できると考もしやすい．また，この仕様書の段階でのユーザビリえる．プロトタイプではできない全体像を UI 仕様書ティ評価にも活用できる．

は一目で表現できる．また，各ボタンの動作の詳細など，プロトタイプとは異なる方法でシステムの概要を

4 考察知ることができる．したがって，プロトタイピングとプロトタイプ作成時に UI 仕様書を自動生成する

UI 仕様書の両方を生成できるツールによって認識のことができると，プロトタイピングと UI 仕様書の 2差異はさらに低減できる．

つの観点からそれぞれの問題点を補うことができる．
ツールを導入することによる作業効率と認識の差異

4. 3 ツールを導入した場合としてない場合の比較の 2 つの点について考察する．

ツールを導入した場合と以下に示す場合について作業効率と認識の差異の観点から考察する．

4. 1 作業効率の点での考察

1.

プロトタイプも UI 仕様書も作らない場合，まずプロトタイピングを行う場合の作業効率の点

ツールを導入した場合に比べて作業効率は悪化しにおいて考察する．プロトタイプを作成し，レビューやすいと思われる．要件定義段階で，顧客の要求を得るところまではツールと同様だが，顧客の要求ををすべて把握できていればこの限りではないが，まとめ，後の工程で必要となる仕様書を作成する必要顧客の要求を引き出せていないことが多くある．

がある．特に使い捨て型の場合，作成したプロトタイ

この場合，後の工程で手戻りが発生することがあ

プは破棄してしまうので，仕様書作成は顧客の要求をり，結果的に開発全体の工数が増えてしまう．

反映する上で重要になる．その点で，プロトタイプを2.

プロトタイプのみ作る場合，プロトタイプを作成するだけで UI 仕様書を自動生成できるのはコス作るという点はツールを導入した場合と一緒でト削減につながる．進化型プロトタイピングでも最終ある．しかし，その後の工程でプロトタイピング的なシステムが提供されるまでの暫定システムといで得られた顧客の要求を仕様書に書き起こす必う面もあるため，仕様書作成について有用である．

要がある．それにより，認識の差異は低減できる

次に UI 仕様書について考察する．UI 仕様書は統一された記法がなく，またドキュメントのため，作成が作業効率は下がってしまう．

3.

UI 仕様書のみ作る場合，やはり作成にプロに多くのコストがかかる．しかし，ツールによる自動トタイピングほどはかからないかもしれないが，生成であれば作成のコストは最小限にとどめること時間的コストがかかる．また，作成者によって異ができる．また，UI 仕様書をシステム開発工程に導なる UI 仕様書が作成されてしまうことがあり，入すると，プロトタイプと同じ利点があるが，プロト結果的に顧客との認識の違いを埋めることができない可能性もある．

成した場合を比較する．開発者役はそれぞれの場合ごプロトタイプと UI 仕様書両方を手動で作るとに別々の被験者を用意するが顧客役は要求を提示

場合，認識の差異を埋めることについては非常にするだけなので共通の被験者にする．ここで作成し良く，互いに補完しあっていると思われる．しかてもらう UI 仕様書はこちらでフォーマットを指定す

し，プロトタイピングと UI 仕様書のそれぞれのる．その後，それぞれの場合の比較を要件定義書を作作成のコストがかかってしまうため，コスト面か成することにより比較する．顧客の要求が要件定義書らでは非常に悪いといえる．に記述されているかを見ることにより，認識の差異とこれらをまとめると表 1 になる．

その後の工程の作業効率が推測できる．要件定義書は4.

雛形を作っておくことと書き方を教示することによ
表1

導入手法ごとの作業効率と認識の差異低減の違い

導入手法

作業効率

認識の差異低減

両方作成しない××

プロトタイピングのみ△○

UI 仕様書のみ△○

両方手動で作成

××◎

提案ツールを使用○◎

り，被験者が要件定義書を作成しやすいようにする．

6 まとめと今後の課題
UI 仕様書の定義と要件定義段階における顧客と開発者の認識の差異を低減する，プロトタイプから UI仕様書を自動生成するツールを提案した．プロトタイ
ピングは開発者が自力で行う必要があるが，UI 仕様書についてはほぼ自動で生成されるため，プロトタイピングを導入しているプロジェクトではツールを使用しやすいと考える．ツールの作成にあたり，UI 仕様

5 実験書のどの部分まで自動生成でき，どの部分までサポー

本研究の目的である，要求工程での認識の差異を埋トできるかといった点は今後の課題である．

めるということが提案するツールにより解決されているかを確認する必要がある．ツールを用いた場合と参 考 文 献用いなかった場合での認識の差異の程度と作業時間の[1] 尾形慎哉，鱗原晴彦，青山寛太: UI（ユーザインタフェース）設計とシステム設計を結ぶモデリング技術の可能性について, ヒューマンインタフェースシンポジウ
ム, 2004.
[2] 神長裕明，郷健太郎，杉浦茂樹，高橋正和，藤田茂，
渡辺喜道: ソフトウェア工学の基礎, 共立出版, 2012.
[3] 佐川博樹: 要求定義の基本と仕組み システムの品質を決める最上流工程 開発の基礎, 秀和システム, 2010.
[4] 豊澤まどか，伊藤恵，八木大彦: 依頼者と開発者双方を支援する UI 仕様書に基づいた要求定義書の提案, 公立はこだて未来大学卒業論文, 2006.
[5] 山岡俊樹，鈴木一重，藤原義久: 構造化ユーザインタ
フェースの設計と評価, 共立出版株式会社, 2000.

違いを調査する予定である．具体的には，システム開発の要件定義段階を想定し，顧客役と開発者役を分け顧客役には要求を指示し開発者役は要求を引き出してもらう．開発者には簡単なプロトタイプまたは UI仕様書を作成してもらい，何も作成しない場合，プロ
トタイプのみ作成した場合，UI 仕様書のみ作成した
場合，プロトタイプと UI 仕様書を手動で作成した場
合，プロトタイプからツールを使用し UI 仕様書を作