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