![[PukiWiki]](image/wadanyan.png "[PukiWiki]")
提案指標(コミュニティ媒介性)で他にどんな使い方ができるか・・・
ノード重み付きコミュニティ媒介性
ハブ的な人とつながっているとアンドマンの評価を高くする ⇒ ノード重み＝次数中心性
コミュニティ内の仲介者（？)とつながっているとアンドマンの評価を高くする ⇒ ノード重み＝媒介中心性
エッジの張り方を変えれば様々な様々な視点から分析できる はず
軸がブレるといかんのでメモ書きしておく
基本的な考え方
コーディネータの重要性(能力)はコーディネータと関わりのあるノードから見積もる
どれだけ頼られているのか？どれだけ重要な人と結びついているのか？
1ステップだけ見る理由
コーディネータ自身が及ぼすことのできる範囲だから
2ステップになるとコーディネータとつながるノードの重要性(能力)に影響する 虎の威をかる狐？
■重みは不要！？
いろいろ考えてみたけど，重みの取り扱いが一番めんどい
正規化の方法もそうだけど，考えもなしに取り扱うには向かないものだと思う
※実際，重み付きモデルがあるにも関わらずあんまり使われてないし
回数が何を意味して，どの程度多ければいいのか判断できない
単純に重みを考えれば結果は変わると考えられるけど，その現象を説得できる自信がない
重みを考慮するなら，どうしても重みを考慮しなければならない理由を先に見つけてから取り扱ったほうがいいような気がする
■媒介中心性は敵ではない！？
いろいろと考えた結果，媒介中心性は敵ではなくむしろマエトリクスの基本となるモデルであるという結論に至った
マエトリクスは媒介中心性の進化版として考えられ，コミュニティ間の仲介者評価に特化したモデルではないかと考えられる
媒介中心性との大きな違いは，仲介の形態(コミュニティ内の仲介とコミュニティ間の中間を切り離して考えている)に着目しているという点
付け加えるなら，OSSコミュニティみたいにMLを用いて交流しているコミュニティ間の仲介者評価に特化した指標だといえるかもしれない
結果として媒介性と同じような推移をたどるのは当たり前のことだといえる
個人的にはΣ(中心性)×Σ（中心性）モデルが自分の思い描くコミュニティ間の仲介者(媒介性)評価のための指標の理想系に近い
■重みの正規化方法
シグモイド関数でも何でもいいけど，ノード間の重みNを無限大に発散させた場合に1に収束する数式を用いればいいだけのこと
そうすれば値域は[0，1)として表現できる
※つながっている人物全てと非常に多くのやりとりを行ったときに限りなく1に近づく
シグモイド関数の場合，値の増加とともに緩やかに増加していくイメージがあるけど，
個人的にはもう少し急勾配な感じになる関数がいい
重みの最大値で正規化すると値に開きがあった場合（例：1と1000とか），値の小さなものはほぼ0になり無意味なものしてカウントされてしまう恐れがある
むしろ，ある一定回数以上に達したらそれ以上はほぼ変化なしといったほうが個人的にはしっくりくる
※心理学とかじゃないけど，ある一定回数以上交流したらお互いの親密度が急激に高まるような現象がありそうな気がする．もしあるのであれば，それに見合った関数を使えばいいと思う
■提案モデルのいうバランスについて ※バランスの解釈
●量的な意味でのバランスのよさ
2つのコミュニティに対しての交流人数や投稿回数に偏りがなく参加しているかどうか
●質的な意味でのバランスのよさ
2つのコミュニティに対して，それぞれのコミュニティにおいて重要だと考えられる人(中心性の高い人)とつながっているかどうかという点から，それぞれのコミュニティにおけるアンドマンの重要性に偏りがあるかどうか（みたいな）
※質的なバランスは少しオーバーな解釈かもしれないけど，一方のコミュニティでは重要な人とつながっていても，もう一方では重要でない人(中心性の低い人)としかつながっていない場合，2つのコミュニティにとってアンドマンの重要さ(重要視のされ方？)に違いがあるとも考えられるのではないかという気がした．
提案モデルでは，つながっている人の重要さ(中心性の値)に着目しているから，こんなことも言えるんじゃないかなと思った．
result.xlsmodel.zip■指標の限界
シミュレーションの結果，モデルＩの結果がもっともよいものとなった．(モデルＧ，Ｈ，Ｉは重み付きである分値が大きくなる)
モデルＧとＩはともに上（黄色）のコミュニティから８回のレスをもらっていて，回数的には同じだけど，モデルＧのほうが一見バランスよく幅広い人と交流をしているから良さ気に見えてしまう
※要するに単純に重みをかけ合わせるという点に少し疑問点が見つかった．
直感に合わないのは，ＩのほうがＧと比べ，取得している情報がコミュニティの一部の人の声だと感じてしまうからだ
幅広い人との交流を重視するのであれば，重みを考えず実質的な交流人数を表す次数だけ見ればいい
重みをどうしても考えたいのであれば，(恣意的な方法ではあるが)対処法は2通り考えられる
個人的には重み情報も重要な要素だと考えているので，単純に中心性を足し合わせていくのではなく，アンドマンの幅広い交流（2つのコミュニティの網羅率）を反映させる形にもっていったほうがいい気がする．
※ここではうまく説明できないけど，情報取得にしても，それがコミュニティ全体の声なのかごく一部の人の声なのかといった網羅率として考えたい．それに網羅率として考えれば，正規化できるし値域も0〜1にすることができる
コーディネータ能力をはかるメトリクス(重み付)を考える ※情報の伝達効率をはかる
アンドマン(©かめい)
(金光さんの本に紹介されているそれぞれの中心性では)単一ネットワーク内での個々のノードの状態を表すメトリクスが多いけど，複数のネットワークを対象としたメトリクス測定方法は提案されていない点
※(A⇒Bの場合)ネットワークA内で多くの人から情報を受け取った(Inputが多い)ノードがコーディネータを介して,ネットワークB内において発言力がある(Outputが多い)ノードにどれだけ情報を伝達させ,ネットワークB内に情報を浸透・普及させているかを表すイメージ
※Nが多くなったときいったい何を調べてるのかよく分からない．これだとコミュニティ間の依存関係(コミュニティの結びつきの強さ)を見ているような感じがする．
開発にも積極的に取り組んで,ユーザの意見にも常に耳を傾け支援するめちゃくちゃしんどい人？
この場合媒介先のネットワークにどれだけ次数をはっているかをカウントして調べるだけでいい(実際に自分も議論に加わっているわけだから,つながっている先の重みとかはあまり必要ない．むしろ重みを考えると変にややこしくなる)
個人的には,開発の第一線でバリバリがんばっている人というよりかは,Documentation作成とか事務的な役割を追っている人がコーディネータになっていくような印象がある．(実際にApacheでは,コーディネータの何人かがDocumentationProjectに参加している人だったし・・・)
ネットワーク間を媒介するただの窓口(こんな意見をもらいましたよと単に伝達するだけ)になっている人？
この場合であれば，重みを考える必要がある．例えばネットワークA⇒Bの流れを考えたとき，Aでもらった意見をネットワークB内のノードNiが議論として取り上げているかは，Niの出次数を見れば何となく分かる(ような気がする)
ネットワークA⇒Bの流れを考えたとき，コーディネータとつながっているネットワークB内のノードNiが問題提起(要求)を投げかけたと考えると，このNiを中心に議論が行われれば出次数だけでなく入次数も多くなるはず． Input，OutputでなくAll(一度でも意見交流しとことのある人の数＝知り合いの数)で考えたほうがよいのでは？
例えばApacheのDeveloperとUserのネットワークで考えた場合，コーディネータとして多くのユーザと関わりを持っている(多くのユーザを支援し，多くの声に耳を傾ける)ことが好ましく，Developerに対しては，影響力のある(問題解決を図る上で問題に対して直接の関係者でかつリーダーシップがありそうな人につながっている)ことが好ましいと考えられる．
※極端なことを言えば，Linuxの開発ならエッジの数よりも開発リーダーで決定権のあるLinus Torvaldsにつながっているかどうかが重要になってくるだろうし・・・
ただ，バランスの悪いノード(入次数多で出次数少のノードとか)もいるわけだから，これらをタイプ別に分類(入・出次数の多少で4つのタイプに分類)して役割みたいなものを考えてみてもいいかも
次数のバランスからタイプ別に分類して，擬似的な役割みたいなもの(パーティション)を与えたときにネットワークがどう見えるのか？とかネットワークにおいてどのくらいの割合を占めているのかと見てみたら何か言えるのだろうか？(自問自答 orz)
進捗報告6.ppt進捗報告5.ppt中間報告.ppt進捗報告4.ppt進捗報告3.ppt進捗報告2.ppt進捗報告1.ppt自分の中でのイメージであり単なる妄想です f(^ ^;)
着眼点：OSSコミュニティでは新規にユーザが参加し脱退していくというサイクルがめまぐるしい （新陳代謝が激しい)
正統的周辺参加が実際に行われていることがコミュニティを持続させる(OSSプロジェクトで言えば成功に導く)要因であるならば，成功と失敗(?)においてその差が現れてくるはず．
(イノベーションプロセスの論文中で中心性分析を行った結果)中心性の値の変動の要因としてこのような点も影響を与えていると考えられる．（むしろ，議論の内容・質が異なっているということのほうが影響している気がするけど・・・）
正統的周辺参加が行われている・促進されると考えれる状況
正統的周辺参加の状況(?)を評価するための仮説(正統的周辺参加が行われている・促進されると考えられる状況を以下に考えてみた)
・新規参加者がコミュニティ内で積極的参加(発言)している場合
・新規参加者に対してコミュニティの受け入れ体制(?)が整っている場合
⇒新規参加者がコミュニティ参加後,多くの人と関係を築いているのであればそれぞれの中心性は現状維持か悪くても若干低下するぐらい
これに対して，新規参加者が積極的に参加せず，受け入れ体制(?)が不十分な場合
⇒新規参加者の次数・近接性は低くなるためネットワーク全体の次数・近接性平均の低下率は大きい
⇒いろいろな人が話しかけないと近接性は低くなり，媒介性が高くなる
※この仮説を検証するためには，時系列で新規参加者数・脱退者数の割合や脱退者のもともとの中心性(そのネットワークにおいての影響力のある人物であったかどうか) を考慮しないといけないし，議論の内容によっても影響を受けるだろうから調べるのは結構めんどくさくなると思う．
※参加時期にもよるけど，新規参加者のコミュニティ平均継続期間は，最低，リリースのサイクル以上であることが好ましいような感じがした．(リリースのサイクル以下だと途中で仕事放棄しているような感じがする)
単に構造的に中心であるということと，重みを考慮した場合では違いが現れてもおかしくはない．(金光さんの本では，単に構造的なとらえ方をした場合と，重みを考慮した実社会の現象に近づけたとらえ方とでは違いがあることは既に証明されていると書いてあった)
※構造的に中心であるかどうかは，議論の場でよくしゃべってるけど実のない話をしている人でも中心性は高くなることを表しているが，重みを考慮した場合ではそうはならないことがある． 構造的中心性と重み付きの中心性で差異がないほど，議論を活性化させている人≒次数の高い人と考えらえれる．
それに対して，構造的中心性と重み付きの場合とで違いが顕著なほど，あまり議論が円滑に行われていない(議論が発散している)ような感じがした．(勝手な妄想 orz)
Apacheでは1つのML内で開発に関する議論を行うのに対して，NetscapeやEclipseの場合，複数のMLに分けて議論を行っている．
どちらが好ましいとかは分からないけど，議論の内容やコミュニティの規模によってはより議論を活性化させるコミュニティ形態というものがありそうな感じがした．
文系的な考え方だけど，複数のMLに分割した場合とそうでない場合では，参加者の主体性・積極性に影響を与えると思った．明示的に役割を与えることで責任の所在なり責任意識は与えられるけど，他のMLへの干渉(情報共有)は少なくなる感じがする． ※あまりいい例ではないけど，たとえば研究室内でごみ捨て係を決めると，ごみ捨て係でない人はごみが一杯であるかをあまり意識しなくなるようなイメージ
実際にNetscapeの場合では，同じ開発MLでありながら複数のMLに横断的に現れる人は少なく，ひどいときは0になっていた．もし，Eclipseで複数のMLに横断的に現れる人が継続的に現れているのであれば，それが成功(?)の要因とも考えら得れるのではないかと思った． ※個人的にはある程度関係のある仕事をする(意見交流があっておかししくない)コミュニティ同士は始めからひとまとめにしておいたほうがいいのではと思った．今回考えるネットワーク数がN(複数のMLに分割されて作業している場合)で，コミュニティ間の依存度を見て，統合・分割をするなどコミュニティ構造も状況によって変化してもいいのではと思った．
議論の内容とコミュニティ形態に関しては，例えば新規機能を考えるならより多くの声に耳を傾けたほうが言いし，モジュールやプラグインが多い場合，いくつかのサブネットワークに分けたほうがいい気がする．ソフトウェア開発におけるフェーズ分析じゃないけど，そんなの感じで結果が出たら面白いかなと・・・
GIMPとApacheのコーディネータを見ていて思ったことだけど，コミュニティの規模や成長過程によって，コーディネータとしての働きが変わってくるのではと思った． GIMP，Apacheはともにコーディネータのバランスはよかったけど，どちらかというとGIMPは開発者寄りでApacheはユーザ寄りのコーディネータだった．
コミュニティとしてある程度成長して成熟し，プロダクト(作ったソフトウェア)の利用者数が多くなればなるほど，よりユーザの意見に耳を傾ける必要があると思う． それに対して，開発規模が小さく利用者数がそれほど少ない時期では開発に注力していて開発寄りのコーディネータであってもおかしくはない．
亀井さんが言ってらしたように，開発MLとコミットログ(?)から評価する Bugzillaに報告されたBugの重要度によって開発者ネットワーク内での活発度の違いみたいなものがありそう(重要なバグほどみんなで一丸になって解決に取り組むとか・・・)
人と人とのつながりだけでなく，コミュニティの生み出すプロダクトの質が調べられたら面白いかなと思った．
