リモートユーザ参加型 Web アプリケーション開発環境の改良

DEWS2007 B9-3
リモートユーザ参加型 Web アプリケーション開発環境の改良
横田 義和†
矢野 日高‡
山田 敬三†
田中 充†
佐々木 淳†
船生 豊†
†岩手県立大学ソフトウェア情報学部 ソフトウェア情報学科 〒020-0193 岩手県滝沢村滝沢字巣子 152-52
‡岩手県立大学 ソフトウェア情報学研究科 〒020-0193 岩手県滝沢村滝沢字巣子 152-52
E-mail: †‡{g031b160, g231e036}@edu.soft.iwate-pu.ac.jp, {k-yamada, m-tanaka, jsasaki, funyu}@iwate-pu.ac.jp
あらまし 昨今，アジャイル型システム開発方法論の一つである XP(eXtreme Programming)が注目されている．しかし，XP
は開発の現場にユーザが参加しなくてはならないためユーザの負担が大きいといわれている．著者らはユーザにとって負担の
少ない XP 開発環境を実現するため，遠隔地からユーザが開発に参加できる協調開発環境を構築し，試行実験を行った．その
結果，ユーザと開発者間のコミュニケーションや操作性という点で，いくつかの問題点が明らかになった．本論文では，より
ユーザにとって負担の少ない XP 開発環境を実現するため，問題点を解決する新たな機能を構築し，この環境を用いたシステ
ム開発実験，評価を行った．
キーワード 遠隔地，協調開発，リモートユーザ，XP，コミュニケーション
Improvement of Web Application Development Environment
with Remote-user Participation
Yoshikazu YOKOTA†
Hidaka YANO‡
and
Keizo YAMADA†
Michiru TANAKA†
Jun SASAKI†
Yutaka FUNYU‡
†Faculty of Software and Information Science, Iwate Prefectural University 152-52 Sugo, Takizawa, Takizawa-mura,
Iwate, 020-0193 Japan
‡Graduate School of Software and Information Science, Iwate Prefectural University 152-52 Sugo, Takizawa,
Takizawa-mura, Iwate, 020-0193 Japan
E-mail: †‡{g031b160, g231e036}@edu.soft.iwate-pu.ac.jp, {k-yamada, m-tanaka, jsasaki, funyu}@iwate-pu.ac.jp
Abstract In recent year，XP(eXtreme Programming) that is one of the agile system-development methodologies is paid to
attention. However, it is said that end users’ load is large in XP, because the users have to participate in the development site.
Therefore, we construct a cooperative development environment that the user is able to participate from the remote place in
the development place. In order to compare our proposed method with XP, we carry out an evaluation experiment. As a
result, some problems are clarified in the communications between the user and the developer and the usability. To achieve
the XP development environment with light load of the user, we construct new functions to solve the problem. This paper
describes the conventional problems and evaluation results of our new proposal.
Keyword remote, collaborative-development, view, users in remote site, communication
1. は じ め に
情報システム開発プロジェクトの多くがエンドユーザ
インターネットを基盤としたネットワーク社会の
の 要 求 に 応 え ら れ ず 失 敗 に 終 わ っ て い る [4][5]．プ ロ ジ
到来により，情報システムには，より多様なニーズに
ェクトが失敗する要因としては，要求仕様が不完全で
応 え ，か つ 早 期 に 開 発 さ れ る こ と が 求 め ら れ て い る [1]
あること，頻繁な要求使用の追加・変更等が挙げられ
[2][3]．
て い る が [6]，こ れ は 情 報 シ ス テ ム 開 発 の 上 流 工 程 で あ
高 品 質 な 情 報 シ ス テ ム を 迅 速 に 構 築 す る た め ，様 々
な開発方法論，開発技術が提案・実践されているが，
る要求定義，設計工程が不完全であるためと考えられ
る．
こ の 問 題 解 決 を 図 る 方 法 と し て ，新 た な 開 発 方 法 論
2.2. 現 行のプロトタイプシステムの概 要
と し て エ ク ス ト リ ー ム プ ロ グ ラ ミ ン グ（ XP）に よ る 情
我 々 は ， 前 述 の モ デ ル に 基 づ い て ， PHP， Smarty を
報 シ ス テ ム 開 発 が 注 目 さ れ て い る ．XP に よ る 情 報 シ ス
用 い た Web ア プ リ ケ ー シ ョ ン 開 発 を 対 象 と し た 遠 隔
テム開発では本質的な要求を持っているユーザ自身と
協 調 開 発 環 境 支 援 シ ス テ ム 「 RCDESS （ Remote
協調して開発を行うため，真にユーザの要求に沿った
Collaboration
情 報 シ ス テ ム 構 築 が 期 待 さ れ る ．し か し ，XP の プ ラ ク
System）」を 構 築 し た ．そ の シ ス テ ム の 構 成 を 図 2 に 示
ティスの一つであるオンサイト顧客では，ユーザは常
す．
Development
Environment
Support
に開発の現場に同席しなければならない．そのため，
ユーザに負担がかかり，実現が困難なプラクティスと
なっている．
そ こ で ， 我 々 は ユ ー ザ に 負 担 の 少 な い XP 開 発 の 実
開発者
現 を 目 的 に ，近 年 進 展 が 著 し い Web ア プ リ ケ ー シ ョ ン
(1)成 果 物 を 見 せ る
を対象とした遠隔地からユーザが開発に参加できる協
調開発環境のモデルを提案し，その提案モデルに基づ
ユーザ
(2)動 作 確 認
インター
(5)修 正
ネット
いてプロトタイプシステムを構築した．提案システム
(4)要 求 の 確 認
の 特 徴 は ， Web ア プ リ ケ ー シ ョ ン の 特 性 を 生 か し ， リ
(3)要 求 の
追加・修正
リースのタイミングだけではなくインターネット上で
常時システムの動作確認が可能になることで，これに
よりユーザが開発に割かれていた時間の軽減と，ユー
図1
現行の協調開発モデル
ザが開発の現場（フロア）に来るという負担が解消さ
れる．
し か し ，実 際 に Web ア プ リ ケ ー シ ョ ン の 開 発 ，実 験
動 作 確 認 サブシ ステム
評価を行った結果，プロトタイプシステムに対してい
くつかの問題点が明らかになった．
記述
そこで本論文では，現行の協調開発モデルにおいて，
よ り ユ ー ザ に と っ て 負 担 の 少 な い XP 開 発 環 境 を 実 現
す る た め に 新 た な 機 能 を 構 築 し ，再 び Web ア プ リ ケ ー
Sys tem
動作確認
参 照 ・追 加
ユー ザ
返答
ブラ ウザ
ションの開発，実験評価を行ったので，その結果につ
CSV
要 求 の確 認
いて述べる．
ファイ ル
管理
2. 現 行 の 協 調開 発 環 境の 概 要
2.1. 現 行の協 調 開発 モデル
参 照 ・変 更
Sys tem
開発者
状態確認
まず，我々がこれまで提案した遠隔地からユーザが
ブラ ウザ
開 発 に 参 加 で き る 協 調 開 発 モ デ ル の プ ロ セ ス （ 図 1）
追 加 要 求 管 理 サブシステム
について説明する．図 1 において，インターネットを
介 し て ，(1)開 発 者 は 実 装 済 み の 成 果 物 を ユ ー ザ に 見 せ ，
図 2 システム構成図
(2)ユ ー ザ は そ の 時 点 で の シ ス テ ム の 動 作 確 認 を 行 い ，
(3)要 求 の 追 加 ・ 修 正 が あ る 場 合 は 開 発 者 に 通 知 す る ，
RCDESS は ， 開 発 者 が 開 発 対 象 シ ス テ ム の 成 果 物 を
(4)開 発 者 は ユ ー ザ か ら の 要 求 を 確 認 し ，(5)シ ス テ ム の
ユーザに見せ，ユーザが動作確認を行う「動作確認サ
修 正 を 行 い ，(1)そ の 成 果 物 を ユ ー ザ に 見 せ る と い う 一
ブシステム」と，ユーザからの修正・追加の要求を管
連の作業を繰り返す．
理 す る「 追 加 要 求 管 理 サ ブ シ ス テ ム 」か ら な る ．ま た ，
本モデルでは，非同期的にユーザがシステムへの要
開 発 履 歴 を 残 す た め 追 加・修 正 の 要 求 を 格 納 す る CSV
求を通知したり，動作確認を行えるので，ユーザの都
ファイルを設ける．
合に合わせて，より負担の少ない協調開発が可能とな
2.2.1. 動 作 確 認 サブ シ ス テム
る．また，開発者はユーザの要求の追加・修正が即座
本サブシステムの画面構成は図 3 に示すように，フ
に把握できるため，ユーザの意図を迅速に反映したシ
レームによって 2 つに分割されている．動作確認フレ
ステム開発が可能となる．
ーム（画面右）では，開発中システムの動作確認を行
う．要求記述フレーム（画面左）は，開発中システム
の 1 画面毎にコメントが入力できるテキストボックス
本サブシステムの機能は以下の 3 つである．
が存在する．このテキストボックスにおいてユーザは
・ 状態別閲覧機能：新着・既読・修正中・修正済
追加・修正要求を，開発者は回答をそれぞれ記述する
の 4 つの状態別に要求の一覧を表示する．他の
ことができる．また，開発者側からユーザへの意見・
開発者が修正を行っている要求の確認ができる
質問等を記述することもできる．
ため，開発者間の協調関係が図れる．
本サブシステムの機能は以下の６つである．
・ 機能別閲覧機能：対象システムの機能別に要求
・ 動作確認機能：開発中システムの動作確認を行
の一覧を表示する．機能別の項目は対象システ
う．開発の進捗度をリアルタイムに把握するこ
ムに依存するが，各機能と階層関係の抽出は，
とができる．
要 求 が 格 納 さ れ て い る CSV フ ァ イ ル か ら 読 み 取
・ コメント機能：要求記述フレームのテキストエ
リアに，ユーザの要求記述，または開発者から
の意見・質問を記述する．
・ 返信機能：記述されたコメントに対して返信を
行う．各コメントをクリックすると，返信を記
る た め ，シ ス テ ム ご と に 設 定 を す る 必 要 は 無 い ．
・ 状態変更機能：各要求に対し既読・修正中・修
正済へ状態を変更できる．また，ここで修正済
に変更された要求は，動作確認サブシステムで
は過去ログに格納される．
述 す る た め の 別 Window が 表 示 さ れ る ．
・ チャット機能：会話形式にユーザと開発者がや
り取りをする場合に利用する．要求記述フレー
ム下の「チャット」ボタンをクリックすると，
チ ャ ッ ト を す る た め の 別 Window が 表 示 さ れ る ．
・ 過去ログ参照機能：過去のコメントとそれに対
応する返信コメントの参照を行う．要求記述フ
レーム下の「ログ」ボタンをクリックすると，
過 去 ロ グ を 参 照 す る た め の 別 Window が 表 示 さ
れる．
・ RSS 生 成 機 能 ： 新 た な コ メ ン ト 又 は 返 信 が 入 力
さ れ た 場 合 RSS を 生 成 す る ．そ の た め ，ユ ー ザ・
開 発 者 共 に RSS リ ー ダ ー に 登 録 す れ ば ，新 着 コ
メントの有無を常に把握することができる．
図４ 追加要求管理サブシステム画面例
3. 試 行 実 験 の概 要 と 確認 さ れた 問 題 点
3.1. 概 要
試行実験（以下，第 1 次開発実験）では，本学の古
川氏らが提案する「食育サポートシステム」の開発を
対 象 と し ，RCDESS を 導 入 し た 場 合（ 以 下 YP：Yokota
Process） と し な い 場 合 （ 以 下 XP） と で 開 発 効 率 を 比
較することにした．本実験では，すべての機能の開発
で は な く ，上 記 シ ス テ ム の「 認 証 機 能 」「 生 産 者 管 理 機
能 」「 ユ ー ザ 管 理 機 能 」の 3 つ の 機 能 の 開 発 に 評 価 対 象
を絞った．なお，システムの内部仕様上の特徴は，演
算 処 理 よ り も DB へ の デ ー タ の 挿 入 ， 抽 出 が 多 い 点 で
あった．両開発実験においては，できるだけ共通した
図 3 動作確認システム画面例
開 発 体 制 と 環 境 を 用 い る こ と と し た (表 2)．両 開 発 実 験
ともユーザは同一人物（古川氏）である．開発要員は
2.2.2. 追 加 要 求 管理 サ ブ シス テ ム
本サブシステムは動作確認サブシステムによって
記述された要求の管理を行う．図 4 はその画面例であ
る．
同等のスキルレベルを持つ別々の学生 3 人である．
表 2 開発体制と環境
開発要員
3人
OS
MacOS X
スクリプト言語
PHP 4
4.1. 動 作 確 認サブシステムの追 加 機能
本サブシステムに対し，新たに構築した機能につい
て，その概要と予想される効果について述べる．
DB
MySQL 4.0.27
フレームワーク
Smarty
(1) 打 合 せ 調 整 機 能
あらかじめチャットを行いたい日付，時間の指定を
行う．単位は 1 時間ごとに指定可能で，相手はその要
請に対し参加の有無を返答する．要求記述フレーム下
の「打合せ調整」ボタンをクリックすると時間指定，
返 答 の た め の 別 Window が 表 示 さ れ る ．
3.2. 確 認 された問 題 点とその考察
第 1 次開発実験の結果，アンケートから主に以下の
ような問題点が確認された．
(1) ユ ー ザ と 開 発 者 間 に お け る コ ミ ュ ニ ケ ー シ ョ ン
RCDESS で ユ ー ザ と 開 発 者 間 の コ ミ ュ ニ ケ ー シ ョ ン
(2) 状 態 表 示 機 能
各々の要求に対し，その左側に状態を表示する．
機能（１）から予想される効果：あらかじめチャッ
トをする日程を指定しておくことにより，チャット利
用が促進され，コミュニケーションが円滑に出来る．
が円滑に行えなかったという意見が多かった．その原
機能（２）から予想される効果：本サブシステムか
因として，リアルタイムに会話形式でコミュニケーシ
らも要求の状態を確認できるため，ユーザは開発者に
ョンを取れるチャット機能を一度も利用せず，コメン
要求が伝わったか，現在修正中なのかなどの開発状況
ト機能とその返信機能のみでやり取りをしていたから
を把握できる．
と考えられる．これはお互いにどのタイミングでチャ
4.2. 追 加 要 求 管理 サブシステムの追加 機 能
ットが利用できるか分からなかったためである．その
本サブシステムに対し，新たに構築した機能につい
ため，お互いにチャットを利用する時間を事前に打ち
て，その概要と予想される効果について述べる．
合わせできる機構が必要である．
(1) 状 態 通 知 機 能
(2) ユ ー ザ 自 身 に よ る 要 求 の 状 態 確 認 の 負 担
現 行 の RCDESS で は 要 求 の 状 態 を 確 認 で き る の は
追加要求管理サブシステムを利用できる開発者のみ
で あ り ，追 加 要 求 の 状 態 変 更 は ユ ー ザ に 知 ら さ れ な い ．
そ の た め ，ユ ー ザ は 自 身 の 出 し た 要 求 に 対 し ，そ れ が
本サブシステムによって追加要求の状態がされた
場 合 RSS を 生 成 ・ 配 信 す る ．
(2) 状 態 の 追 加
これまで新着，既読，修正中，修正済だった状態に
「お知らせ」を追加した
開 発 者 に 伝 わ っ て い る か ，ま た ，そ れ が 反 映 さ れ た か
機能（１）から予想される効果：これまで，ユーザ
の 確 認 を す る 必 要 が あ り ，そ の 時 間 が 負 担 と な っ て い
からの要求が修正された場合その通知は無く，ユーザ
た ．こ の こ と か ら ，ユ ー ザ に 対 す る 要 求 の 状 態 通 知 の
自身が確認作業を行う必要があり，その作業が負担と
機構が必要である．
なっていた．開発者によって状態が変更される度にそ
(3) ど の 状 態 の 定 義 に も 属 さ な い コ メ ン ト の 発 生
要 求 に 対 し ，新 規 ，既 読 ，修 正 中 ，修 正 済 と い っ た
の 旨 を RSS で 通 知 す る こ と に よ り ，ユ ー ザ 自 身 に よ る
確認作業の負担を軽減できる．
状 態 の 定 義 が さ れ て い る が ，例 外 の コ メ ン ト が 存 在 す
機能（２）から予想される効果：前述したようにど
る こ と が 判 明 し た ．例 え ば ，「 こ の 画 面 の ID＆ パ ス ワ
の 状 態 の 定 義 に も 属 さ な い コ メ ン ト に 対 し ，「 お 知 ら
ー ド は ∼ で す 」「 管 理 者 メ ニ ュ ー を 再 開 し ま し た 」 な
せ」という状態で統一することが可能になる．
ど ，そ の 画 面 に 対 す る 要 求 で は な く ，お 互 い の 意 思 疎
通 を 図 る た め の コ メ ン ト も 見 受 け ら れ た ．こ れ ら は シ
5. 実 験 評 価
ス テ ム 修 正 に 関 係 な く ，修 正 中 ，修 正 済 と い っ た 状 態
5.1. 概 要
に 属 せ ず ，新 た な コ メ ン ト の 状 態 を 定 義 す る 必 要 が あ
る．
開発実験（以下，第 2 次開発実験）では，本学の浜
田氏らが提案する「食事指導支援システム」の開発を
対 象 と し ，第 1 次 開 発 実 験 と 同 じ く YP と XP と で 開 発
4. 新 機 能 の 構築
効率を比較することにした．本実験では，すべての機
本 章 で は ，前 章 で 挙 げ た RCDESS に 対 す る 問 題 点 を
能 の 開 発 で は な く ，上 記 シ ス テ ム の「 認 証 機 能 」「 料 理
解決するために，動作確認サブシステム，追加要求管
管 理 機 能 」「 ユ ー ザ 管 理 機 能 」「 ク ラ イ ア ン ト 管 理 機 能
理サブシステムに新たな機能を追加して再構築した．
（ 一 部 除 く ）」の ４ つ の 機 能 の 開 発 に 評 価 対 象 を 絞 っ た ．
な お ，シ ス テ ム の 内 部 仕 様 上 の 特 徴 は ，
「食育サポート
シ ス テ ム 」 と 同 じ く 演 算 処 理 よ り も DB へ の デ ー タ の
挿 入 ，抽 出 が 多 い 点 で あ っ た ．両 開 発 実 験 に お い て は ，
量を求める．対象データはユーザからの要求かつ修正
開発要員を 4 人とし，その他は第 1 次開発実験と共通
が必要なコメントで，その件数を追加要求量とする．
した開発体制と環境を用いることとした．
(2) コ ミ ュ ニ ケ ー シ ョ ン 時 間
YP，XP 両 開 発 実 験 と も ユ ー ザ は 同 一 人 物（ 浜 田 氏 ）
ユーザと開発者のコミュニケーションは，全てコメ
である．開発要員は同等のスキルレベルを持つ別々の
ント機能，チャット機能で行われるのでテキストベー
学生４人である．
スとなる．そのため，コメント機能にてやり取りされ
両開発実験では，開発手法の比較材料として以下の
た時間と，チャット機能を利用した時間を足したもの
データを取得することとした．
をコミュニケーション時間とする．コメント機能にて
(1) 追 加 要 求 量
やり取りされた時間は，ユーザのコメント，開発者の
XP の 特 徴 で あ る ユ ー ザ の 要 求 を 反 映 し た 開 発 が YP
コメントを考えて，タイピングするのにかかった時間
でも行われたかを評価するため，両開発実験において
とする．チャットを利用した時間は動作確認サブシス
ユーザからの追加・修正の要求数（以下追加要求量）
テムから求める．
を測定する．
(3) 拘 束 時 間
(2) コ ミ ュ ニ ケ ー シ ョ ン 時 間
YP で は ， ユ ー ザ は 自 分 の 都 合 に 合 わ せ て 動 作 確 認 ，
XP は 現 場 で 会 話 を す る の み だ が ， YP は コ メ ン ト を
要求の記述が行えるので，非同期的に開発に参加して
入力する時間が発生するため，コミュニケーションに
いた場合拘束時間は発生しない．しかし，打合せ調整
要する時間（以下コミュニケーション時間）を比較す
機能により，開発者からチャットの要請があり，それ
る．
にユーザが承諾した場合，打合せ調整機能により指定
(3) 拘 束 時 間
された時間は同期的に開発に参加していたことになる．
オンサイト顧客では開発の現場に同席していても
そのため，打合せ調整機能によって指定された時間か
ユーザはコーディング待ちなど何もできない時間（以
ら，その間コミュニケーションが行われたチャット時
下，拘束時間と呼ぶ）が発生し，ユーザへの大きな負
間を差し引いた時間を拘束時間とする．
担となるため，その時間の違いを比較する
6. 評 価
以 下 ， XP と YP に お け る 測 定 内 容 の 詳 細 を 述 べ る ．
5.2. XP での開 発 実 験
第 2 次開発実験の計測結果を表２に示す．
表２
第 2 次開発実験の計測結果
(1) 追 加 要 求 量
XP の 場 合 ，ユ ー ザ と 顧 客 の 話 合 い に よ っ て 発 生 し た
YP
XP
追加要求についてドキュメントは残さないが，今回の
追加要求量（件）
13 件
8件
実験では追加要求量を計測するため，追加要求が発生
する毎にその内容を記述する追加要求レポートを作成
コミュニケーショ
ン時間
することとした．記述するタイミングとしては，ユー
拘束時間
3 時間 3 分
(9.7％ )
17 時 間 59 分
(57.1％ )
1 時間 2 分
(2.8％ )
35 時 間 38 分
（ 97.2％ ）
31 時 間 30 分
36 時 間 40 分
ザと開発者の話合いが終了した時点で，記述する内容
は 話 合 い に か か っ た 時 間 ，日 付 ，追 加 要 求 内 容 で あ る ．
開発時間
(2) コ ミ ュ ニ ケ ー シ ョ ン 時 間
開発中，ユーザからの追加要求，開発者からの仕様
についての質問，提案について話合いが行われるが，
その全ての話し合いにかかった時間を記録する．
(3) 拘 束 時 間
基本的にユーザと開発者の話合いの時間以外ユー
ザはコーディングが終わるまで何もしないで待つ．そ
の時間をユーザの拘束時間とする．拘束時間は，全体
の開発時間からコミュニケーション時間を差し引いて
求めた．
追 加 要 求 量 に つ い て は 若 干 YP の 方 が 多 い も の の ，
YP， XP 共 に 大 き な 差 は 無 か っ た と い え る ． コ ミ ュ ニ
ケ ー シ ョ ン 時 間 は YP の 方 が 多 く か か る こ と が 判 明 し
た ．YP の コ ミ ュ ニ ケ ー シ ョ ン 時 間 は ，追 加 要 求 管 理 シ
ステムから抽出されたチャット以外のコメントの文字
数 （ 1560 文 字 ） を 考 え な が ら タ イ ピ ン グ し た 時 間 （ 1
時 間 2 分 ）と ，チ ャ ッ ト 機 能 を 利 用 し た 時 間（ 2 時 間 1
分 ）を 合 計 し た 3 時 間 3 分 と し た ．YP に お け る ユ ー ザ
の拘束時間は，打合せ調整機能により指定され，ユー
5.3. YP での開 発 実 験
ザ が 同 期 的 に 開 発 に 参 加 し た 合 計 時 間（ 20 時 間 ）か ら
(1) 追 加 要 求 量
チャット機能を利用した時間（2 時間 1 分）を差し引
追加要求管理サブシステムのデータから追加要求
い た 17 時 間 59 分 と し ， 開 発 時 間 全 体 に お い て 57.1%
を 占 め る 割 合 と な っ た ．一 方 ，XP に お け る ユ ー ザ の 拘
が あ っ た こ と ，YP で は 最 初 か ら チ ャ ッ ト で コ ミ ュ ニ ケ
束時間は，開発時間全体からコミュニケーション時間
ーションを取ることに抵抗感が無かったことなどが今
を 差 し 引 い た 35 時 間 38 分 と な り ， 開 発 時 間 全 体 に お
回の結果に多少影響があったことを考慮すべきである．
い て 97.2%を 占 め る 割 合 と な っ た ．
次 に RCDESS の 利 便 性 ，開 発 さ れ た プ ロ ダ ク ト へ の
満足度について，ユーザと開発者それぞれに評価する
ためのアンケート調査を行った．
8. お わ り に
本稿では，現行の協調開発環境に対し，よりユーザ
に 負 担 の 少 な い XP 開 発 環 境 の 実 現 を 目 指 し ， 現 行 の
コミュニケーションはスムーズに行えたかという
協調開発環境の問題点を挙げ，それに対応する新たな
問 い に 対 し ，YP，XP と も に「 当 て は ま る 」「 や や 当 て
機 能 を 実 装 し た ．さ ら に ，本 シ ス テ ム を 用 い た 場 合 と ，
は ま る 」 と い う 回 答 を 得 ら れ （ 9 名 ／ 9 名 ）， ユ ー ザ の
用 い な い 場 合 で の Web ア プ リ ケ ー シ ョ ン 開 発 実 験 を
要求はシステムに反映されたかという問いには全員が
行い，本提案の有効性を確認した．
「 当 て は ま る 」「 や や 当 て は ま る 」と 回 答 し た（ ７ 名 ／
今 後 は ，YP を 利 用 し た XP の 開 発 プ ロ セ ス の 確 立 の
７ 名 ）． 開 発 さ れ た プ ロ ダ ク ト へ の 満 足 度 と し て は ，
必 要 性 が あ る ． YP， XP に は そ れ ぞ れ メ リ ッ ト ， デ メ
XP， YP 共 に 「 満 足 」 と い う 回 答 を 得 ら れ た （ ７ 名 ／
リ ッ ト が 存 在 し ，今 ま で の XP 開 発 に YP を 取 り 入 れ る
７ 名 ）．開 発 中 ，ユ ー ザ 自 身 に と っ て 無 駄 に 過 ご し た と
という両開発プロセスのハイブリット型が実際には有
思われるときがあったかという問いに対してユーザか
効 で あ る と 考 え ら れ る ．ま た ，YP は 実 装 段 階 前 の 要 求
らは「当てはまらない」という回答が得られた．
分 析 ，設 計 段 階 の 上 流 工 程 で の 利 用 を 考 慮 し て い な い ．
ま た ，ユ ー ザ か ら「 YP は 時 間 的 ，場 所 的 拘 束 が 少 な
そのため，上流工程での遠隔協調開発環境の提案も必
いのが魅力的．しかし，要求の伝え方とか伝わりやす
要になってくる．その他に，よりコミュニケーション
さ は XP の 方 が い い 」 と い っ た 意 見 が あ っ た ．
の負担を軽減するため，音声やビデオチャットを利用
したコミュニケーション手段も考慮すべきである．
7. 考 察
追 加 要 求 量 に つ い て は 若 干 YP の 方 が 多 い も の の ，
謝辞
YP， XP 共 に 大 き な 差 は 無 か っ た こ と か ら ， 遠 隔 か ら
最後に，開発実験にご協力いただいた，本学同研究
でもユーザの要求を反映したシステム開発が可能であ
室の古川恵理奈氏，浜田優子氏，小田雅貴氏，本田創
る こ と を 確 認 し た ．YP は コ ミ ュ ニ ケ ー シ ョ ン で は 多 少
大氏，高橋克也氏，北川愛優美氏，矢野日高氏，三田
負担になるという結果になったが，ユーザの拘束時間
村唯氏，山下徹氏に感謝致します．
を大幅に削減できたことの効果が大きく，総合的には
ユーザの負担が少ないシステム開発環境であるといえ
る．
今 回 ，YP の コ ミ ュ ニ ケ ー シ ョ ン の 問 題 を 改 善 す べ く
チャット機能利用を促進する打合せ調整機能を構築し
た．その効果は大きく，第 1 次開発実験の際には 1 度
も利用されなかったチャット機能が，今回の実験では
22 回 程 度 の 利 用 が 見 ら れ ，「 コ ミ ュ ニ ケ ー シ ョ ン が ス
ムーズにできた」というアンケート結果の大きな要因
と な っ た ． ま た ， 第 1 次 開 発 実 験 時 に YP で は 「 ど の
要求が修正完了したか確認する作業が無駄」という意
見があったが，今回の実験では無駄と感じる時間は無
かったという結果が得られ，各追加要求の状態表示機
能，状態通知機能を構築した効果があったと考えられ
る．
これらのことから，本研究の目的であるユーザに負
担 の 少 な い XP 開 発 の 実 現 可 能 性 を 確 認 で き た と い え
る．
しかし，今回の実験開発はユーザ，開発者共に全て
同 一 研 究 室 内 の メ ン バ ー で 構 成 さ れ て お り ，XP で は 実
際の現場にいるユーザは追加要求を出すことに遠慮感
文
献
[1] 総 務 省 ，“ 平 成 17 年 度 版 情 報 化 白 書 ” ，
http://www.johotsusintokei.soumu.go.jp/whitepaper/j
a/h17/index.html， 2004．
[2] 財 団 法 人 イ ン タ ー ネ ッ ト 協 会 監 修 ，“ イ ン タ ー ネ
ッ ト 白 書 2005”， イ ン プ レ ス ， 2005．
[3] 経 済 産 業 省 ，“ 平 成 16 年 情 報 処 理 実 態 調 査 結 果 報
告
”
，
http://www.meti.go.jp/policy/it_policy/statistics/jyoj
itu.htm， 2005．
[4] The Standish Group，“ 2004 CHAOS Demographics
and
Project
Resolution”
，
http://www.standishgroup.com/， 2004．
[5] 中 村 建 助 ， 矢 口 竜 太 郎 著 ，“ プ ロ ジ ェ ク ト 成 功 率
は 26.7％ 2003 年 情 報 化 実 態 調 査 ”，日 経 コ ン ピ ュ
ー タ 2003 年 11 月 17 日 号 ， 2003．
[6] The Standish Group ，“ The CHAOS Report ”，
http://www.standishgroup.com/， 2003．
[7] 横 田 義 和 ，矢 野 日 高 ，田 中 充 ，佐 々 木 淳 ，船 生 豊 ，
“ リ モ ー ト ユ ー ザ 参 加 型 Web ア プ リ ケ ー シ ョ ン
開発 環境 の構 築”，電 子情 報 通信 学会 ，
KBSE2006-11 ．