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

ソフトウェア開発書類の共同編集による合意形成支援
瀬川 貴雅

伊藤 恵

本研究では，ソフトウェア開発プロジェクトの外部設計工程において，発注者とシステム開発者の間の合意形成を支援することを目的とする．従来のソフトウェア開発プロジェクトでは，発注者とシステム開発者の間のコミュニケーション不足が原因で，開発後期段階での仕様変更が起こることが大きな問題となっている．我々はこの問題に対して，発注者とシステム開発者の間の開発するソフトウェアに対する合意の形成を効果的にすることで解決できると考えた．そこで 1 つのものを複数人で同時に編集できる共同作業ツールに着目した．従来，システム開発者が開発するソフトウェアの外部設計を行うが，設計作業に発注者を参加させることで効果的な合意形成ができると考えた．本研
究では発注者とシステム開発者が共同で画面設計書類の設計をすることで，発注者のソフトウェアに対する認識がどのように変化するか実験を通じて調査する．

In this study, it is purpose that we support consensus building between customer and system developer insoftware development projects. Conventional software developing projects have a problem that occurringsome specification changes in latter phases, because of lack of communication between customer and system developer. So we thought eﬀective consensus building about software would solve this problem. Then
we focus on cooperative editing tools. In general, system developer does external design of software. We
thought that they can make eﬀective consensus by customer participating in external design phase. In thisstudy, we will research how customer’s recognition about software would change through the cooperative
design between customer and system developer.

ミュニケーションが活発に行われることが望ましい．

1 はじめにそのような取り組みとして従来はシステムの仕様

1. 1 背景書などの設計書類を用いて，互いの認識を確認するこ

ソフトウェア開発の要件定義工程において，発注者とが一般的である．特にソフトウェア要求に関する仕がシステムに求める要件を決定する．システム開発者

様書には発注者とシステム開発者の間で合意したシはこの要件を満たすようなシステムを開発する．しかステムがなすべきこととシステムに期待してはいけし，最終的に発注者の要件を満たさないシステムが納ないことを記述する．記述内容は発注者とシステム品されることがある．これは発注者とシステム開発者開発者の度重なる会議によって合意が得られた内容の間のシステムの要件やイメージの食い違いが原因であり，その結果がこれらの設計書類となっている．のひとつであると考えられる．ユーザが真に求めるシ

この取り組みにはシステムの設計が開始される前にステムを開発するために，この齟齬を埋めることが必要求に対する査定を行う役割がある [4]．

要である．そのために発注者とシステム開発者のコまた，プロトタイピングを用いてシステム開発者の解釈の妥当性を確認することも一般的である．発注

The Consensus Support by the Collaborative Editingof Software Development Documents.
Takamasa Segawa, Kei Ito, 公立はこだて未来大学システ
ム情報科学部, Dept. of Systems Information Science,Future University Hakodate.

者がシステム開発者の解釈をイメージしやすいため，システム開発者の解釈の妥当性確認に加え，発注者の新しい要求を抽出することができる [4]．

1. 2 目的の共有や複数人での同時編集の機能がありコラボレー

本研究では，ソフトウェア開発プロジェクトの外部ションの点が特長である．

設計工程において，発注者と開発者の間の合意形成を支援することを目的とする．これを支援することで発

2. 3 ユーザ参画型の業務要求定義

注者とシステム開発者のシステムに対する認識の統片山他 [3] は世界最大級のシェアード型府省共通業一を狙う．結果として，発注者の要件に合ったシステ

務情報システム開発に積極的な要求工学技術の活用をムを開発することができると考える．また，要件定義行った結果を記した．特にシステムの納入において，終了後の設計工程，特に始めの外部設計工程においてシステムが正しく動作することを確認することに加合意形成の取り組みを促すことで開発後期段階に起え，ユーザの業務要求を満たしていることを確認す

こる仕様変更のリスクを軽減することができる．

る妥当性確認を目的としたユーザ参画型要求ベース受入テストを実施した．結果として，ユーザがテスト

2 関連研究ケースを洗い出すことで，具体的な利用場面を想定し2. 1 書類の合意形成ながら妥当性確認ができた．また，ユーザ参画による発注者とシステム開発者は要求とその実現方法がテストケースの作成と開発者によるシステム設計の適切であるかをモデルのレビューやプロトタイピン工程を同時に行うことで，新たに発見された要求を迅グ，受け入れテストを通じてソフトウェア要求が妥当速に設計に反映させることができた．

であるかを確認する [5]．その結果をもとに発注者とシステム開発者の間で合意が成される．合意形成のプ3 アプローチ

ロセスでは新たな要求の発生や仕様の変更が起こる発注者と開発者の間の合意形成を支援するためにため，合意の得られた仕様が他の書類に反映されてい共同編集に着目した．Google ドキュメントや Googleない状況が考えられる．

スプレッドシートでは複数人で 1 つの書類を同時にそのような状況に対して，従来のシステム開発では編集できる．また，コミュニケーションをとりながら書類はシステムの品質保証の検査に用いられ，書類と編集できる特徴がある．しかしこれらは文書作成と表矛盾がないか検査する．ソフトウェア開発の中間成果計算が目的のツールであり設計文書の作成や編集に物である設計書やマニュアル，テスト計画を検査し合は適していない．

否判定を行う．またレビューの結果がシステムに確実

この共同編集をソフトウェア開発の設計工程に適用に反映されているかを確認することも重要である [5]．

することが有効であると考えた．特に，システムのイ

このような取り組みで発注者から合意が得られたシンタフェースを定義する外部設計工程の画面設計にステム開発の実現に書類が用いられている．

適用する．システムの見た目や振る舞いがイメージがしやすいと思われる画面設計に発注者が参加する

2. 2 共同編集

ことで，システムを利用する場面が想像できる．その複数人のグループで協調作業を行うツールにグルー

結果，漏れていた要件の明確化や発注者とシステムプウェアがある．Ellis [1] はグループウェアを，共通開発者の要件の認識の統一という効果が考えられる．の仕事や目的をもって働く，利用者のグループを支援

そこで発注者とシステム開発者が共同でシステムのし，共有 (協同) 作業環境への，インタフェースを提設計書を作成することで発注者のシステムに対する供するコンピュータベースシステムと定義している．

認識の変化を調査する．この調査を実施するための実図の作成・編集・共有ができるグループウェアのひ
とつに Cacoo [2] がある．Cacoo は株式会社ヌーラボが提供しているワイヤーフレームやサイトマップなどの図が作成できる Web アプリケーションである．図験を次章にて述べる．

システムの概要，想定利用ユーザと人数，機能に関す

4 予備実験
4. 1 実験目的
画面設計書類の作成において，発注者が画面設計図を編集することの有効性や問題点を検証する．また被る要件を書かせた．
次に，システム開発者は発注者が作成した簡易提案依頼書をもとに画面設計図を作成した．このときCacoo のワイヤーフレーム作図機能を用いた．

験者へのアンケート項目や実験手順が適切か検証す作成した画面設計図を発注者に見せた後，発注者とる．そして発注者とシステム開発者が共同編集するこシステム開発者にシステムの認識に関するアンケーとによるシステムの認識の変化を調査するために役トを実施した．

立てる．

次に，画面設計図の作成に発注者を加え，システム開発者と共同で編集を行った．画面設計図作成工程

4. 2 被験者と同様 Cacoo のワイヤーフレーム作図機能を用いた．

発注者として公立はこだて未来大学教員 1 名，シまず，発注者が画面設計図を編集し，発注者自身で変ステム開発者として公立はこだて未来大学学部 4 年 1

更できない点はコメントを残した．その後，システム名の計 2 名を被験者とした．両者ともシステム開発開発者が編集された画面設計図を確認しコメントさの経験はあった．

れた内容についての提案を行った．これを発注者の合意が得られるまで繰り返した．

4. 3 実験環境
実験には被験者それぞれの PC を用いた．被験者 2名での画面設計図の共同編集を実現するため，Cacoo

最後に発注者とシステム開発者に，共同編集前に実施したアンケートに共同編集に関する設問を加えたアンケートを実施した．

を用いた．また，Cacoo にアクセスするための Web
ブラウザは特に指定しなかった．共同編集の環境を

4. 6 結果

共同編集時には画面収録を行い，編集の様子を録画

4. 6. 1 要件抽出工程した．

発注者に題材である発表会オンライン評価システ
ムに関する提案依頼書の作成をさせた．題材に設定

4. 4 題材したシステムは今後開発される予定があり実際のシ予備実験では発表会オンライン評価システムを題ステム開発の状況に近づけるため，題材に関する説材とした．これは PBL や研究の成果等の発表会で利明や提案依頼書の書き方の指示は特に行わなかった．

用され，傍聴者が発表のフィードバックをするための発注者が作成した提案依頼書を付録 A に添付した．

システムである．

4. 6. 2 画面設計図作成工程
提案依頼書をシステム開発者に渡し，Cacoo を用い4. 5 手順て画面設計図を作成させた．システム開発者は Cacoo

実験手順は大きく以下の 5 つの工程から成る．の利用経験があったため技術習得は省略した．システ

1. 要件抽出工程

ム開発者が作成した画面設計図の特徴的な画面を付

2. 画面設計図作成工程

録 B,C に添付した．

3. 共同編集前アンケート

4. 6. 3 共同編集前アンケート

4. 共同編集工程

画面設計図を発注者に確認させた後，発注者とシス

5. 共同編集後アンケート

テム開発者の間で交流させずに両者に画面設計図を各工程での具体的な手順を以下に記す．

見ながらアンケートに答えてもらった．その結果を表

まず，発注者は題材が持つべき機能に関する要求を1 に示す．

挙げ簡単に提案依頼書を作成した．今回被験者には，このシステムは何に使われますか，システム化に

図1

共同編集の回数と所要時間意が得られた．共同編集の前と後では画面設計図に大きな変化が生じた．その一部を付録に添付した．

4. 6. 5 共同編集後アンケート
共同編集を終えた直後に，再び両者に画面設計図を見ながらアンケートに答えてもらった．その結果を表2 に示す．このシステムは何に使われますか，システ!

ム化によってどのようなタスクが効率化されると思いますか，このシステムで最も重要な機能は何ですかの

3 つの質問からわかるシステムの認識について，共同編集前アンケートと同様，発注者とシステム開発者の間に違いがあった．また，同時利用が想定されるユーザの人数はどれくらいですか，運営者ユーザのシステ
ムの利用頻度はどれくらいですかという提案依頼書の理解度を問う質問は，発注者とシステム開発者の間で
表1

予備実験 共同編集前アンケートの結果同様の答えが得られ，共同編集前アンケートと違いはなかった．発注者の要求を満たすシステムだと思いま

よってどのようなタスクが効率化されると思います

すか，動作がわからなかった部分はありましたかといか，このシステムで最も重要な機能は何ですかの 3 つうシステムの動作を問う質問では，発注者のシステムの質問からわかるシステムの認識について発注者と動作の認識には不明点が減ったような回答であった．

システム開発者の間に違いがあった．また，同時利用設計に貢献することはできましたか，共同編集によっが想定されるユーザの人数はどれくらいですか，運営て相手との認識の誤差は見つかりましたか，それは者ユーザのシステムの利用頻度はどれくらいですか

どのようなものでしたかという共同編集の効果には，という提案依頼書の理解度を問う質問は，発注者とシ発注者とシステム開発者共に有効性があるような回ステム開発者の間で同様の答えが得られた．発注者の答をした．

要求を満たすシステムだと思いますか，動作がわからなかった部分はありましたかというシステムの動作を

4. 7 考察問う質問では，発注者のシステム動作の認識には不明

共同編集後アンケートの，共同編集によって相手と点があるような回答であった．の認識の誤差が見つかったか，またそれはどのような4. 6. 4 共同編集工程ものかという質問から両者の回答に違いが生じた．シ

共同編集は図 1 のように行われた．発注者とシスステム開発者は傍聴者や発表者の入れ替え機能を考テム開発者交互に 2 回ずつ計 4 回編集が繰り返され慮していなかったことという回答をした．一方，発注た．合計 116 分間編集が行われた後発注者からの合者はその点を質問の回答には挙げなかった．編集時の発注者には Cacoo の利用経験がほとんどなかったことから，編集が満足にできなかったように思えた．
図 1 より共同編集の時間に偏りがあったことからも明らかである．発注者の合計編集時間は 23 分，システ
ム開発者の合計編集時間は 93 分であった．また，収録した動画から，実際にシステムに対して変更したい要求はあったが，表現方法がわからずコメントを残して編集をシステム開発者に任せることが何度か見られた．Cacoo の技術が十分であればより双方向な共同編集ができたように考えられる．
発注者への共同編集後のアンケートには，設計に貢献できた，共同編集によって相手との認識の誤差が見つかったと回答があったため共同編集の取り組みは良かったと思う．しかし，発注者とシステム開発者の認識の誤差や変化を十分に引き出すことができなかった．特に認識が近づくかどうかを判断できるアンケート項目が必要に感じた．よりよいアンケート項目や実験手段の設定が必要であると思った．

4. 8 予備実験のまとめ予備実験では，発注者が画面設計図を編集に参加することの有効性や問題点，アンケートを含めた実験手段の有効性や問題点を検証した．被験者 2 名を募り，発注者とシステム開発者に分けて実験を行った．
結果から，発注者とシステム開発者の新しい要求に対する認識の違い，利用ツールの技術習得の必要性，実験手順の問題点が分かった．

5 本実験計画
5. 1 実験目的
画面設計書類の作成において，発注者とシステム開表2

予備実験 共同編集後アンケートの結果発者が共同で編集をすることによって両者のシステムの認識が近づくか調べる．また画面設計図の共同編集

画面を収録した動画から，そのようなやり取りがあっによって発注者にどのような効果があるか調査する．

たにも関わらず，発注者は認識の誤差とは考えていなかった．このことから，発注者は実装されて当たり前

5. 2 被験者であると思っており，新しい要求と認識していなかっPBL 等発表評価システムを利用したことがある人たと思われる．またはシステム開発者がどのような認を発注者として 1 名，システム開発経験のある人を識であったか，発注者には伝わっていないことが考えシステム開発者として 1 名を募り，2 名 1 組で実験をられる．

行う．なお，システム開発者は Cacoo を使ったことがあるとより好ましい．この条件で複数組を対象に実が望ましい．本研究では特に外部設計工程における験を実施する．

有効な合意形成の支援を目的として，よりよいコミュニケーションの支援を図る．この目的達成のために発

5. 3 題材

注者とシステム開発者の画面設計図の共同編集が有予備実験で用いた題材と同じ，発表会オンライン評効であると考る．これを検証するために実験を行う．

価システムを題材とした．PBL や研究の成果等の発共同編集による有効性や問題点，実験手段の有効性や表会で利用され，傍聴者が発表のフィードバックをす問題点を予備実験を通して検証した．結果として，発るためのシステムを想定した．

注者とシステム開発者の新しい要求に対する認識の違い，利用ツールの技術習得の必要性，実験手順の問

5. 4 実験環境

題点が分かった．これをもとに本実験の計画を立て，実験には被験者それぞれの PC を用いる．被験者今後本実験を行う．

2 名での共同編集を実現するため，Cacoo を用いた．
共同編集時には画面収録を行い，編集の様子を録画

参 考 文 献する．

[1] Ellis, C. A., Gibbs, S. J., and Rein, G.: Groupware: some issues and experiences, Communications of the ACM, Vol. 34, No. 1(1991), pp. 39–58.
[2] 株式会社ヌーラボ: Cacoo. http://cacoo.com.
[3] 片山昭, 菊島靖弘, 野村典文, 吉田宏明, 岡村美和: 人
事・給与システム：大規模シェアード型府省共通業務情報システムの開発ーユーザ参画型の業務要求定義からー, 情報処理学会デジタルプラクティス, Vol. 4, No. 2(2013),
pp. 141–151.
[4] 松本吉弘: ソフトウェアエンジニアリング基礎知識体
系, オーム社, 2014.
[5] 村上和夫: ソフトウェア品質知識体系ガイド, オーム社, 2014.

5. 5 手順
実験手順は大きく以下の 6 つの工程に分かれる．

1. 技術習得工程
2. 要件抽出工程
3. 画面設計図作成工程
4. 共同編集前アンケート
5. 共同編集工程
6. 共同編集後アンケート
ここでは予備実験での手順と異なる部分について触れる．
まず，技術習得工程で Cacoo を用いた円滑な共同編集を実現するため，発注者とシステム開発者を対象に技術習得を実施する．簡単な画面設計図を作成する
課題を出し，Cacoo での作図方法を習得させる．
共同編集工程には予備実験時とは異なる以下の方法を追加する．

• 被験者 2 名が交互に編集する• 被験者 2 名が同じ場所で同時に編集する• 被験者 2 名が遠隔地で同時に編集する
また，共同編集前と共同編集後のアンケートには予備実験時とは異なる内容のものを用いる予定である．

6 まとめ
よりよいソフトウェア開発のために発注者とシステム開発者のコミュニケーションが活発に行われること

A 付録: 発注者に作成させた提案依頼書

B 付録: 共同編集前の画面設計図 (一部)C 付録: 共同編集後の画面設計図 (一部)