研究背景：

ミッションクリティカルなシステムで利用されているオープンソースソフトウェア(OSS) の不具合は，開発者によって迅速に修正されることが望まれる．しかし，多くの開発者を抱えるOSS プロジェクトでは，言語や文化，習慣などが異なる世界中の不特定多数のボランティア集団によって開発を進められているため，管理者が保守作業の適任者を特定することが容易ではなく，不具合が修正されるまでの時間が長くなってしまう問題がある．

ACTION：

本研究で作成したACTION(Awareness Communication Tool for Interactive Open Negotiation)は，(a)保守対象のソースコードの開発に関与した経験のある開発者，(b)開発者の活動地域と開発者の活動時間，を直観的に把握できるよう支援することができる．システムの有用性を検証するために比較実験をおこなった結果，ACTION を利用することで，開発者の活動時間に沿ったコミュニケーションが可能になることを確認した．また，従来システムと比較してACTION はOSS 開発者のコミュニケーションを効率化できることを確かめた．

アクションの全体図

• Folder/File View

ツリー構造化されたフォルダ・ファイルの一覧を示す．ファイルをクリックすることで，イベントが起こり，ファイルを検索キーとしたクエリがデータベースに送られる．

• Module History View

ファイルの変更を行った開発者，変更時刻をグラフに示す．横軸はタイムゾーン，縦軸は日付で，1プロットは開発者1名に該当する．

• Active Time View

開発者のメール送信数を用いて，活動頻度を表すヒストグラムを表す．横軸は時刻，縦軸はメールの送信数である．

• Commit History View

開発者の開発履歴をリスト化して示す。

研究の背景：

一般に，LinuxやApacheをはじめとするOpen Source Software（OSS）開発コミュニティには，情報共有や作業の効率化を図るために，参加者の役割（開発者，バグ報告者，ユーザなど）に応じたいくつかのサブコミュニティが存在しています．参加者が地理的に分散している環境下において高機能かつ高品質なOSSを持続的に開発するためには，それぞれのサブコミュニティで行われる活動の結果として得られる成果物（ソースコード，バグ報告，ユーザフィードバックなど）を有機的に機能させOSSに反映していくことが重要になります．そのため， OSSコミュニティ参加者の内，コアメンバはいくつかのサブコミュニティに参加しコミュニティ全体の秩序の形成や組織化に貢献し，サブコミュニティ間の協調作業を円滑化する役割を担っています．

我々が行った分析から，複数のサブコミュニティを媒介するコアメンバのコミュニケーション構造（図1）は，成功コミュニティと衰退コミュニティとでは大きく異なることが分かりました（図2）． また，異なるサブコミュニティの参加者をコアメンバが媒介する度合いを評価する指標として，従来の媒介中心性は適切ではないことも明らかにしました．

ソフトウェア開発者らのコーディネーション（作業分担の調整）の状況把握を目的として，ソーシャルネットワーク分析（人と人との関係を構造的観点から分析する手法）を用いた分析を行っています．ソーシャルネットワーク分析では，人を表すノードと，人と人を結ぶ関係を表すエッジを用いて構造をグラフ（ネットワーク図）化し，その構造の特徴を分析します（図1）．

図1　グラフ（ネットワーク図）のイメージ

コーディネータ

OSS開発はメールや掲示板などの非対面のコミュニケーション方式を用いて議論が行われます．加えて大規模なOSS開発では，開発者やユーザ，テスタなどの参加者の役割ごとにサブコミュニティ（メーリングリストなど）を設けることが一般的です．この運用方法は情報の混乱を避け，開発者（またはユーザ，テスタ）にとっての知識や情報，議論の選別が容易に行えるというメリットが得られる一方で，お互いの情報共有や協調作業が困難になります．これは，ユーザからの意見が開発にフィードバックされないことによるプロダクト（ソフトウェア）の成長の阻害や，新規ユーザの正統的周辺参加が成立たないことによるコミュニティの成長の阻害などの問題を引き起こします．そこで本研究では開発者とユーザの両方のサブコミュニティに参加している人物：コーディネータに着目し，成功とされるOSSと衰退期にあるOSSの比較・分析を行っています．

分析の結果，現在でも高品質なソフトウェアを提供しているApacheコミュニティでは，長期に渡って両コミュニティの調和活動を支えるコーディネータが存在することが確認されました．また衰退期にあるNetscapeの場合，両コミュニティとの頻繁にコミュニケーションを図るコーディネータが不在していることが明らかになりました．

研究の背景：

ソフトウェア開発を円滑に進めるためには，ソフトウェア開発者はソフトウェア開発に関する知識を常に獲得する必要があります．しかし，ソフトウェア開発に関する技術は非常に多く存在し，新たな技術も次々と生み出されています．また，それらの技術は日々進化しているため，獲得した技術に関する知識はすぐに過去のものとなってしまいます．そのため，個々の開発者が全ての技術について知識を獲得することは不可能と言えます．

オープンソースソフトウェアコミュニティ：

あらかじめ開発に必要な知識やスキルを持っているメンバーを集めてから開発を進める従来の（企業などにおける）組織的なソフトウェア開発と異なり，オープンソースソフトウェア（OSS）コミュニティでは，一般的にはあらかじめ開発に必要なメンバーは集めません．OSS開発では，そのソフトウェアの開発に共感した人が順次そのコミュニティに参加していくことでコミュニティが形成され，開発を進めていきます．したがって，開発メンバーが開発に必要な知識やスキルを持っているとは限りません．

OSSコミュニティにおける知識共有：

OSSコミュニティでは，開発者だけでなく，OSSを使用するユーザやOSSの不具合を報告するバグレポーターもコミュニティの重要なメンバーとなります．ユーザやバグレポーターの”声”がOSSの信頼性の向上や機能拡張につながるだけでなく，開発者の新たな開発に対するモチベーションにもなります．そのため，コミュニティメンバー間の知識共有のためのコミュニケーションが重要となります．

コミュニケーションがうまくいかないと・・・

• 開発者は誰も使わないソフトウェアの開発を進めません．
• ユーザは（使い方の質問などをしても）誰も助けてくれないソフトウェアは使いません．
• バグレポーターは報告したバグが修正されないようなソフトウェアのバグは報告しません．

研究の目的：

本研究では，OSSコミュニティのコミュニケーションの質を知るためにソーシャルネットワーク分析を用いて，知識共有が成功している状態，および，失敗している状態とはどのような状況であるのかを明らかにしようとしています．

ソーシャルネットワーク分析：

本研究では，OSSコミュニティにおいて一般に使用されているメーリングリスト，バグトラッキングシステム，版管理システム，ディスカッションフォーラムなどにおけるメンバー間のコミュニケーションや作業分担などを基にソーシャルネットワークを構築し，ソーシャルネットワーク分析を行っています．

OSSコミュニティでは，コミュニティメンバーの入れ替わりや役割の変更が頻繁に起こります．そのため，本研究では，一定期間ごとのソーシャルネットワークの状態を取得し，ソーシャルネットワーク分析に時系列分析を取り入れて分析を行っています．また，より詳細なソーシャルネットワークの変化を得るため，分析期間を重複させて分析を行っています．

大規模コミュニティでは，特定プロジェクトにリソースが偏ったり,人物間をまとめるハブ的人物が不在したりなどで，知識共有が阻害されていることがあります.本研究では，知識共有支援の第一歩として，それらが発生しているメカニズムを把握するために，従来の可視化技術を大規模コミュニティに適用したり，新たな可視化技術を開発したりしています．    

例えば，SourceForge.netのコミュニケーション構造をWalrusというグラフ可視化ツールを用いて可視化し，コミュニティの活動の様子を分析しました．その結果，8割以上のプロジェクトは3人以下の開発者しか確保することができておらず．活発にOSS開発が行えないという傾向があることが明らかとなりました．           

Social Networkの形成と活用に基づく組織横断型知識協創支援:

「高度情報化社会の到来」や「経済のグローバル化」が謳われて久しい．知識労働者は複雑かつ急激に変化する社会や周囲の環 境に合わせて新たな知識を生み出し問題を解決していく必要性に常に迫られています．伝統的なナレッジ・マネジメントの枠組みは，組織のあらゆる情報や知識 を「知識リポジトリ」に集約させ再利用を可能にすることで，複雑な変化に対して迅速に対応する手段を提供することが大きな目的でした．しかしながら，社会 学や文化人類学の研究により，すべての知識を「知識リポジトリ」に保存することは不可能であり，知識とはそれが利用される環境に埋め込まれていたり，周囲 の環境に分散したものとして存在する事が多いということが明らかにされつつあります[1][2][3][4]．

Social Networkの活用:

知識集約型アプローチの限界を克服すべく，近年「ソーシャル・キャピタル（社会関係資本）」や「ソーシャル・ネットワー ク」の活用に注目が集まっています[5][6]．これらの枠組みでは，人と人との積極的な交流によって形成される「社会的なつながり」を通じて得られる情 報や知識に重点が置かれています．

知識集約型アプローチは，情報や知識をすべてのユーザが利用することができるという長所と，蓄積可能な情報・知識の限界と蓄積された情報・知識の陳腐化が避けられないという短所を持っています．一方，ソーシャル・ネットワーク型アプローチは，個々のユーザが有する（暗黙知を含めた）最新の知識を入手可能であるという長所があるものの，そうした知識を有するユーザとの直接的なやりとりがなければ入手不可能という短所があります[7]．

The DynC (Dynamic Community) framework [8]:

Yunwenらは，上で述べた2つのアプローチを融合した枠組みであるDynC(Dynamic Community)フレームワークを提案しています．この枠組みは，知識リポジトリから，情報と情報の関係(従事するタスクに関連する情報の検索)，人 と情報の関係(エキスパートの同定)，人と人の関係(社会的つながりの利用)を抽出し活用することによって，従来の知識協創支援における問題点に対処しよ うとするものです．DynCの枠組みによって形成されるダイナミックコミュニティは，タスクに応じてその都度形成されるという「恣意性」と，同じタスクで あってもタスクをおこなう人それぞれの状況に応じて変化するという「相対性」を特徴としています（DynCに関する詳細は文献[8]を参照して下さい）．

研究の目的：

本研究の目的は，DynC理論に基づく知識協創支援システムを構築することです．当研究グループでは，SourceForge等の大規模オンライン・コミュニティに所属するソフトウェア開発者を支援対象として，特に，

• 組織（プロジェクト）横断型の知識協創手法（理論・メカニズムの構築など）
• ソーシャル・ネットワークの形成および活用方法（推薦アルゴリズムの開発など）
• ソーシャル・ネットワークの管理方法（SNの評価・可視化手法の開発など）

に重点を置いて研究に取り組んでいます．また，SourceForgeに属するようなインターネット・ユーザだけではなく，実際の企業や組織のイントラネット・ユーザへ開発手法を適用することも検討中です．

DSNS: A Dynamic Social Network System：

現在構築中のシステム DSNS (Dynamic Social Network System) は，Social Network 形成のダイナミクス（スモールワールド現象におけるスケール・フリー・ネットワーク[9]）を考慮に入れたDynCフレームワークに基づく知識協創支援シ ステムです．SourceForgeに所属する開発者(Eclipseユーザ)が適切なタイミングで最適なダイナミックコミュニティを形成できるように，個々の開発者のソーシャル・ネットワークの質と量を計測し，ネットワークの形成と活用方法を動的にガイドします．

システムアーキテクチャ

システムモデル

SNメンバーリスト

SNを利用したコミュニケーション

参考文献：

• [1] M. Polanyi, Tacit Dimension, Doubleday & Co., 1966.
• [2] J.S. Brown, A. Collins and P. Duguid, Situated Cognition and the Culture of Learning, Educational Researcher, Vol.18, No.1, pp. 32-42, 1989.
• [3] J. Lave and E. Wenger, Situated Learning: Legitimate Periperal Participation, Cambridge University Press, 1991.
• [4] D.A. Norman, Things That Make Us Smart: Defending Human Attributes in the Age of the Machine, 1993.
• [5] M. Baker, Achieving Success Through Social Capital: Tapping Hidden Resources in Your Personal and Business Networks, 2000.
• [6] D. Cohen and L. Prusak, In Good Company: How Social Capital Makes Organizations Work, 2001.
• [7] A.A. Bush and A. Tiwana, Designing sticky knowledge networks, Communications of ACM, Volume 48, Issue 5, pp.66-71, 2005.
• [8] Y. Yunwen, Y. Yamamoto, and K. Kishida, Dynamic Community: A New Conceptual Framework for Supporting Knowledge Collaboration in Software Development, Proceedings of 11th Asia-Pacific Software Engineering Conference (APSEC’04), pp.472-481, 2004.
• [9] A. Barabasi, Linked: The New Science of Networks, 2002.

研究概要：

OSSの開発は品質を高めるために，リリースやバージョンアップを頻繁に行っています．リリースやバージョンアップを繰り 返すことで，不具合の修正を行い，商用のソフトウェアに劣らない品質を確保しています．このように頻繁にリリースを行うためには，リリースまでに修正すべ き不具合，またそれに要する時間やコストを見積もることが必要となります[1]．
多くの不具合はバグ管理システムに登録される際に優先度が指定され，修正に取り掛かる優先順位が大まかに決められています．しかし，不具合の修正に要する時間は優先度だけでなく，不具合の複雑さや修正に携わる開発者の技量など様々な要因が考えられます．
我々は不具合の修正に要する時間を左右する要因を追求し，修正に要する時間の予測精度向上に向けて研究を進めています．

研究背景：

ApacheやLinuxをはじめとするOSSは，社会基盤として広く普及しているため高い品質が求められています．しか しながら，OSSの開発は一般的に，開発者が地理的に分散した環境でメールなどの非同期非対面コミュニケーションメディアを用いた協調作業となるため，開 発中に生じた個々の不具合（バグ）の修正方針や修正状況を開発者間で共有することが困難です．さらに近年，OSSの大規模化や複雑化に伴う不具合の増加 が，不具合情報の共有と管理をますます困難なものにしています．そのため，多くのOSS開発では，不具合情報を一元管理するためにバグ管理システムを導入 し利用していますが，不具合が報告されてから修正が完了するまでの時間（滞留時間）が極めて長いものが数多く存在するという問題が指摘されています．

研究目的：

ソフトウェアに混入する不具合を効率的に修正するための作業支援システムの構築.

アプローチ：

未対応時間と修正時間が遅延する要因を分析する