![[PukiWiki]](image/wadanyan.png "[PukiWiki]")
*進捗 [#pff9ee93] **研究内容? [#g08ee39d] コーディネータ能力をはかるメトリクス(重み付)を考える ※情報の伝達効率をはかるイメージ **既存のメトリクス(調査中) [#o609757a] -地位中心モデル(カッツ-ハベル・モデル) --つながっている先のノードの影響力を考慮した中心性 --頼りがいになるノードにつながっている人ほど中心性が高い --頼られ具合を考えるために重み+個々のノードの中心性を利用して計算 **既存のメトリクス(未調査) [#t040f8d9] -方向性ありの媒介性 -重みを考慮した中心性 ⇒ 固有ベクトルにもとづく中心性(ボナチッチ中心性) **提案メトリクスのいいところ(今のところ・・・) [#i4a1b0fa] 金光さんの本に紹介されているそれぞれの中心性は，単一ネットワーク内での個々のノードの状態を表すメトリクスが多いけど，複数のネットワークを対象としたメトリクス測定方法は提案されていない点 **自分なりのイメージ [#zc0680df] -前提条件：複数のネットワークに共通して出現するノードを潜在的コーディネータと考える．(コーディネータになりうる可能性のあるノード) --1．異なる複数のネットワーク(例えば，ネットワークAとネットワークB)において，それぞれのネットワーク毎に個々のノードの中心性を求める． --2．情報伝達の流れ(Information Flow)を考える (ネットワークA,Bがあった場合 A⇒B または B⇒A) --3．(A⇒Bの場合) 潜在的コーディネータにつながっているネットワークA内のノードの統合中心性(入次数の多いノードほど大きい)にやりとりの回数(重み)を掛け合わせて，その和を求める --4．潜在的コーディネータにつながっているネットワークB内のノードの放射中心性(出次数の多いノードほど大きい)にやりとりの回数(重み)を掛け合わせて，その和を求める --5．3，4で求めた値を掛け合わせてコーディネータ能力(情報の伝達効率の良さ的なイメージ)をはかる ※イメージとしては，互いのネットワーク内にどれだけ情報を浸透・還元させているかを表すイメージ -ネットワーク数を2からNへ拡張した場合 --1つのネットワークを1つのノードに圧縮して考える． --ネットワーク間を横断するノード(コーディネータ)がいればエッジをはる． ※当然有向グラフになる --エッジの重みはネットワーク間の情報伝達量(何人かいるコーディネータの情報伝達量の総和)みたいなイメージ ※Nが多くなったときいったい何を調べてるのかよく分からない．これだとコミュニティ間の依存関係を見ているような感じがする． **疑問・問題点 [#zc0680df] -そもそもコーディネータって？ >自分で何でも解決する人？ >>この場合媒介先のネットワークにどれだけ次数をはっているかをカウントして調べるだけでいい(重みを考えると変にややこしくなる) >ネットワーク間を媒介する窓口になっている人？(この考え方だと少し不自然な感じもする・・・) >>この場合であれば，重みを考える必要がある．例えばネットワークA⇒Bの流れを考えたとき，Aでもらった意見をネットワークB内のノードNiが議論として取り上げているかは，Niの出次数を見れば何となく分かる？ -流れを考えたとき入・出次数で分けて考えることに意味はあるの？ >ネットワークA⇒Bの流れを考えたとき，コーディネータとつながっているネットワークB内のノードNiが問題提起(要求)を投げかけたと考えると，このNiを中心に議論が行われれば出次数だけでなく入次数も多くなるはず． Input，OutputでなくAllで考えたほうがよいのでは？ -ネットワークの特徴によって適切なつながり方も変わってくるのでは？ >例えばApacheのDeveloperとUserのネットワークで考えた場合，コーディネータとして多くのユーザと関わりを持っている(多くのユーザを支援し，多くの声に耳を傾ける)ことが好ましく，Developerに対しては，影響力のある(問題解決を図る上で問題に関係のある人でかつリーダーシップがありそうな人につながっている)ことが好ましいと考えられる． >※極端なことを言えば，Linuxの開発ならエッジの数よりも開発リーダーで決定権のあるLinus Torvaldsにつながっているかどうかが重要になってくるだろうし・・・ -ぶっちゃけ入・出次数のバランスを見ればいいんじゃないのか？ >ただ，バランスの悪いノード(入次数多，出次数少)もいるわけだから，これらをタイプ別に分類して役割みたいなものを考えてみてもいいかも >次数のバランスからタイプ別に分類して，擬似的な役割みたいなもの(パーティション)を与えたときにネットワークがどう見えるのか？とかネットワークにおいてどのくらいの割合を占めているのかと見てみたら何か言えるのだろうか？(自問自答 orz) **その他(研究ネタ？) [#zc0680df] 自分の中でのイメージであり単なる妄想です f(^ ^;) ***正統的周辺参加の評価？ [#v1cc4d69] 着眼点：OSSコミュニティでは新規にユーザが参加し脱退していくというサイクルがめまぐるしい （新陳代謝が激しい) >正統的周辺参加が実際に行われていることがコミュニティを持続させる(OSSプロジェクトで言えば成功に導く)要因であるならば，成功と失敗(?)においてその差が現れてくるはず． >(イノベーションプロセスの論文中で中心性分析を行った結果)中心性の値の変動の要因としてこのような点も影響を与えていると考えられる．（むしろ，議論の内容・質が異なっているということのほうが影響している気がするけど・・・） 正統的周辺参加が促進されると考えれる状況 正統的周辺参加の状況(?)を評価するための仮説(正統的周辺参加が行われている・促進されると考えられる状況を以下に考えてみた) ・新規参加者がコミュニティに積極的参加している場合 ・新規参加者に対してコミュニティの受け入れ（サポート）体制(?)が整っている場合 >⇒多くの人と関係を築いているのであればそれぞれの中心性は現状維持か悪くても若干低下するぐらい これに対して，新規参加者が積極的に参加せず，受け入れ体制(?)が不十分な場合 >⇒新規参加者の次数は低くなるためネットワーク全体の次数平均の低下率は大きい >⇒いろいろな人が話しかけないと近接性は低くなり，媒介性が高くなる ※この仮説を検証するためには，時系列で参加者数・脱退者数の割合や脱退者のもともとの中心性(そのネットワークにおいての影響力のある人物であったかどうか) も考慮しないといけないし，議論の内容によっても影響を受けるだろうから調べるのは結構めんどくさくなると思う． ※関係ないけど，新規参加者のコミュニティ平均継続期間は参加時期にもよるけど，最低，リリースのサイクル以上であることが好ましいような感じがした．(リリースのサイクル以下だと途中で仕事放棄しているような感じがした) ***構造的中心性と重み付き中心性の値の差分から何か調べる [#eddcb611] 単に構造的に中心であるということと，重みを考慮した場合では違いが現れてもおかしくはない． 構造的に中心であるかどうかは，議論の場でよくしゃべってるけど実のない話をしている人でも中心性は高くなるが，重みを考慮した場合ではそうはならないことがある． 構造的中心性と重み付きの中心性に違いがないほど，議論を活性化させている人≒次数の高い人と考えらえれる． それに対して，構造的中心性と重み付きの場合とで違いが顕著なほど，あまり議論が円滑に行われていないような感じがした．(勝手な妄想 orz) ***コミュニティの規模や議論の内容によって適切(?)なネットワーク構造があるのでは？ [#gb77431e] Apacheでは1つのML内で開発に関する議論を行うのに対して，NetscapeやEclipseの場合，複数のMLに分けて議論を行っている． どちらが好ましいとかは分からないけど，議論の内容やコミュニティの規模によってはより議論を活性化させるコミュニティ形態というものがありそうな感じがした． 文系的な考え方だけど，複数のMLに分割した場合とそうでない場合では，参加者の主体性・積極性に影響を与えると思った．明示的に役割を与えることで責任の所在なり責任意識は与えられるけど，他のMLへの干渉は少なくなる感じがする． ※研究室内でごみ捨て係を決めると，ごみ捨て係でない人はごみが一杯であるかをあまり意識しなくなるようなイメージ 実際にNetscapeの場合では，同じ開発MLでありながら複数のMLに横断的に現れる人は少なく，ひどいときは0になっていた．もし，Eclipseで複数のMLに横断的に現れる人が継続的に現れているのであれば，それが成功(?)の要因とも考えら得れるのではないかと思った． 議論の内容とコミュニティ形態に関しては，例えば新規機能を考えるならより多くの声に耳を傾けたほうが言いし，モジュールやプラグインが多い場合，いくつかのサブネットワークに分けたほうがいい気がする．ソフトウェア開発におけるフェーズ分析じゃないけど，そんなの感じで結果が出たら面白いかなと・・・ ***コミュニティの規模や成長過程とコーディネータの関係 [#dce8f044] GIMPとApacheのコーディネータを見ていて思ったことだけど，コミュニティの規模や成長過程によって，コーディネータとしての働きが変わってくるのではと思った． GIMP，Apacheはともにコーディネータのバランスはよかったけど，どちらかというとGIMPは開発者寄りでApacheはユーザ寄りのコーディネータだった． コミュニティとしてある程度成長して成熟し，プロダクト(作ったソフトウェア)の利用者数が多くなればなるほど，よりユーザの意見に耳を傾ける必要があると思う． それに対して，開発規模が小さく利用者数がそれほど少ない時期では開発に注力していて開発寄りのコーディネータであってもおかしくはない． ***ネットワークの階層的分析手法 [#dce8f044] そもそも大規模コミュニティにおいて，ある個人から1000ステップ先の人に影響を与えているものなのか疑問に思えることがある．~ 大規模になっても実際に影響を及ぼしているのは限られた範囲の人たちではないのか?~たとえば，ノード間をつなぐエッジが互いに影響を及ぼしあう確率をαとしたとき，1000ステップ先になると単純に考えてもα^1000の確率で影響を及ぼすことになる~ 一見複雑に見えることも実際はある限られた程度の範囲でしか影響を受けていないのかもしれない．もしくはノードによって影響を受けている範囲が異なっているとか…~
