１．担当ＰＭ

　筧　捷彦 　　（早稲田大学教授）

２．採択者氏名

３．プロジェクト管理組織

　リトルスタジオインク株式会社

　2,998,500円

５．テーマ名

　人の集まりを支援するツール QWikS（クウィックス）

６．関連Webサイト

　http://rook.aise.ics.saitama-u.ac.jp/

　http://rook.aise.ics.saitama-u.ac.jp/qwiks/

７．プロジェクト概要

　　人が集まるのはよいことだ。会議，飲み会，試合，お披露目会などなど。友達や知り合い，はたまた，見知らぬ他人が集まってわいわいやるのは楽しい。し かし，人が集まるとき，その企画人には大きな負担がかかる。「人が集まるのはよいことだ」という思想のもと，人の集まりを企画するリーダや幹事，役員の業 務をできる限り楽なものとするツールQWikS（クウィックス）を開発する。?会議やイベントを企画するグループのリーダ（以下，役員）が，集会を開くた め行う仕事は以下のものに分けられる。

　
　　１　日程の調整　
　　２　会議やイベントで集まるために決めるべきことの調査（アンケート）?　
　　３　会議やイベントの予定連絡?　
　　４　会議やイベントの結果報告?　
　

　日程の調整は，提示された個々の都合のよい日（悪い日）と照らし合わせて， グループのメンバの全員もしくは一部が参加できる日時を探す作業である。アンケートは，イベント会場やイベントの内容（飲み会であれば何を食べたいかな ど）などのイベントを行うために決めておかなければならない事柄を調査することである。会議やイベントの予定や結果の連絡・報告は，メンバーにイベント情 報を提供することである。申請者らの開発するツールでは，これらの仕事をWeb上ですべて行えるようにする。

　具体的にはスケジュール調整機能，Webアンケート機能，Wikiを用いた Webページ作成機能を用意する。本ツールの名前QWikSは，アンケート（Questionnaire），Wiki，スケジュール調整 （Scheduler）を合成した言葉である。グループのメンバーを会議やイベントの内容を企画し，運営するリーダたち（以下，役員）と役員が決めた方針 に従って会議やイベントに参加する他のメンバ（以下，構成員）に分け，試合や発表会などにくる外部からのお客さん（以下，部外者）とする。このとき，本 ツールは大きな利点は以下の３点である。
　

　１　役員の日程調整とアンケート，イベント情報公開に費やされる手間を軽減 する
　２　イベント情報を役員用，構成員用，部外者用に分けて公開できる
　３　複数のグループが共同で開催するイベントでも，日程の調整，アンケート，イベント情報の公開を行える。　

８．採択理由

　会議を開こう，飲み会 をやろう，というときに，そのグループの役員・幹事団・一般メンバーでそれぞれに行う作業には違いが生じる。それらの作業の違いを区分しつつも，全体をう まくコン トロールするシステムを開発し，そのサービスを提供することを目的とする。
　類似のソフトウェア（システムサービス）として Zoops/Zope が あるが，そこにはアンケート調査・スケジュール管理の機能はない。アンケート調査を管理運営するソフトについては，提案者の所属する研究室で開発ずみであ り，これを活用する。また，集会の会場に関するデータベースも用意してある。これらはいずれも既開発でその経過からOSSとすることは困難であるとのこ と。そこで，できあがったサービス自体を公開していく方向でプロジェクトを運営する。利用者の見込めるサービスであり，使い勝手のよいものに仕上げられる かどうかが勝負になるプロジェクトである。

９．成果概要

　次の特徴をもったシス テムQWikSが仕上がった。

　
　・　従来のWebアプリケーションでは，守備範囲外であった既に構築されているコミュニティーが実際に現実世界で集まるという行動を支援するツールであ る
　・　飲み会や試合，会議などの特定のイベントに限定されず，どのイベントでも必ず行わなければならない参加者のスケジュール調整，意見調整，イベント情 報の連絡を支援するツールである
　・　手軽に使えるシステムである
　　　　 Webブラウザがあれば使用できる
　　　　 メールアドレスがあれば使用できる
　　　　　 無料で使用できる

　
　しかしながら，会場データベース検索サーバを実装するには至らなかった。これは，会場情報をデータベースとして提供しているところとの連携をとることが 期間内にはできそうもなく，他の機能の実現に傾注するのが得策だと判断した結果である。
　また，設計段階では，それぞれのサーバが物理的に別マシーン（ネット上で分散は位置されていてもよい。）であってもいいように，サーバ間の情報交換に基 づくシステム構成とすることが構想されていた。そのサーバ間の情報交換にメール（SMTP）を使えるのではないかと考えていたのだが，それで実現するのは 非常に難しいことが判明した。その結果，出来上がったシステムは，基本的に１台のマシーンの上にそれぞれのサーバ機能を載せ，rubyを使って統合すると いう，密結合のシステム構成となった。

１０． ＰＭ評価とコメント

　　会場データベースと の連携を模索している間に多大な時間をとられてしまったこともあって，システム構成を手慣れた密結合に切り替えて開発することになってしまった。この結 果，今後会場データベースとの連携が可能になった場合には，その連携部分を密結合したシステムの中に割り込ませる必要が生じてしまった。
　こうした事情から，調査作業，設計作業に手間取り，前半でスケジュール的にかなりのロスをしたので，当初予定していた２回のテストを１回にするなど適宜 細かな計画変更して，開発作業の遅れの取り戻しに努めた。これらは，すべて適時ＰＭに報告があり，PMからも指示だして進めた。結果的には計画と開発成果 とが部分的に異なってしまったものの，実施計画書に記載した二つのユースケース（大学生が合コン，大学の先生が教員会議）に沿った形の開発を仕上げること ができた。
データベースサイトとの連携が一筋縄ではいかない，ということを予想しなかったのは，ある意味でうかつであった。冷静に考えれば，まさにコンテンツそのも のが売り物であるデータベースが「善意」で利用を許可してくれるはずはなく，技術問題以前に，どんなビジネスモデルが成り立ちうるのかを熟考しておくべき であった。こうしたことも，後からは簡単に言えても，立案時にはなかなか思い至らないものである。その点で，今回のプロジェクトは，開発者グループを含め て貴重な経験であったというべきであろう。
開発者グループが，今回の経験を貴重な糧とし，２.８に示す課題についても十分に対策を施して，次のステップに向かってくれることを期待したい。