Wikiを用いたプロジェクトでの議論ってどうしてる? 58
タレコミ by MolecularSpirit
MolecularSpirit 曰く、
複数のオープンソースソフトウェアのプロジェクトに関わっているのですが、そのうちのいくつかがwikiを開発に利用しています。wikiの素晴らしい所は、好きな所に好きな所からドキュメントを仕上げられる所です。ドキュメントの初期の発達には効果があり、相互に干渉しなくていい間はスムーズに推移します。ドキュメントの進行は、その裏での開発の指針となるのでどうやらプロジェクトが進んでいるなという実感があります。wikiのよくないところは、みんなが全てのコメントを読めていたメーリングリスト方式のプロジェクトと比べて、意図的に議論を無視させることが容易になってしまうことでしょう。
wiki上での議論が生じ始めると、参加者のやり方次第でとても偏った結果になってしまうように感じています。例えば、賛成意見と反対意見を分割してしまったり、反対意見だけを整理して新しい利用者グループを形成してしまったりします。結果的に、深刻な問題が進行してから、明るみになるというケースが多くなったり、気づいたらプログラミングがしたい人物ではなくwikiの独裁者のように振舞いたい人物が中心の体制になってしまったりするのです。
どのような態度で取り組めば、スムーズに運営できるのでしょうか?スラッシュドットのみなさんのお知恵を頂ければ幸せです。
wikiの問題ではなくプロジェクトのあり方の問題 (スコア:5, すばらしい洞察)
wikiでは、参加者がよってたかって一つのページを書き上げていくので、
wiki特有の現象が発生しているように見えるかもしれませんが、
mlでもbbsでも(オフラインですら)同様な状況はあったと思います。
wikiというツールを使っているが為に問題が発生しているのではなく、
過去から繰り返されてきた問題が、wikiという新たな舞台で、
演じられているのではないでしょうか。
Re: (スコア:0)
その面はあるだろう。
ただし、システムを適切に選べば「システムが制約を与えてくれる」ので
議論という本質に集中しやすくなるという側面はある。
システムに自由度が大きすぎると本質そっちのけで話題が展開していきやすいから要注意だ。
というより (スコア:4, 興味深い)
wikiは議論をするツールとしては向いていないと思います。
議論って結論と同じくらい会話の流れ・経緯が重要になりますが、wikiだと意識して経緯を書き残さない限り結果のみ書かれている状態になります。
wikiの編集履歴から掘り起こせば何とかならなくもないですが、編集履歴は議論の流れを確認するための機能ではないですよね。
つまり、メーリングリストやらIRCやらバグトラッカーのコメント欄での議論による決定事項・結果をまとめておくツールとして使うのが適切なんではないかと。
Re:というより (スコア:1, 興味深い)
まったくの同意で、Wikiはあくまで結論、まとめを掲載したり、
それ以外ではせいぜい議論のための資料を載せるポインタとしての役目くらいしか果たせません。
現実の会議に置き換えればホワイトボードを導入しましたが会議がうまく進みません。
どうすればよいのでしょうか?と言ってるのと同じくらい頓珍漢なことだと思うのですが。
ホワイトボードは会議の途中でメモ書きしたり、決定事項を参加者に向けて書き留めていくのには使えますが、
それ自体が議論を促したり、よい結論を導き出してくれるわけではないですよね。
Re: (スコア:0)
wikipediaの「ノート」も、wikiの形式を使わなくてもいいと思うんですけどね。
なにより読み辛いし、wikiの書法を知らないような人には敷居が高い。
コミュニケーションする部分は、ツリー式でも2ちゃんねる式でもいいですが、
もっと普通の掲示板の形式にした方がいいと思います。
Re:というより (スコア:3, すばらしい洞察)
激しく同意ですが
wikipediaに掲示板を導入すると
wikipediaで記事を書かずに
単なる巨大掲示板として使う輩が現れるので
導入しないのでしょうね。
サイトの目的に合った敷居の設定が必要なのです。
チケット(トラッカー)を使う (スコア:2)
SourceForge や github などであれば、チケットシステムがあります。
コード上であれ Wiki 上であれ、何らかの issue が発生した時点で
チケットに登録し、議論などはそっちで行うようにするのが良いと思い
ます。
一枚の Wiki を書いているといろんな問題が発生するのでそれらをきち
んと個別の問題として分けてトラッキングするためにも、チケットの
ような issue tracking system は最低限必要だと思います。
だれでも書ける=誰でもコミット権がある (スコア:2, 興味深い)
誰にでも書くことができるってことは、つまりVCSでいえば誰にでもコミット権があるってことですよね。
結局オープンソースでの開発の話に帰着しますね。結局Wikiというのはブラウザ上で編集ができるウェブページ専用VCSです。
と言い切ってしまうとちょっと言いすぎか。Wikinameによる自動的なリンクなどの特徴があるから。
しかしまぁそれはただの見せ方の問題だよな。
屍体メモ [windy.cx]
Re: (スコア:0)
もしかして:CVS
Re:だれでも書ける=誰でもコミット権がある (スコア:1, 参考になる)
Version Control Systemでしょ。
Re:だれでも書ける=誰でもコミット権がある (スコア:1, 参考になる)
# 名前が安定しないので論文を書くときに困るAC
Re:だれでも書ける=誰でもコミット権がある (スコア:1)
まぁ略称を使うときには正式名称を併記しろって事だな。
#一瞬「何故ここでConVenience Store?」って思った。
Re: (スコア:0)
ちょいと悪乗り。
「VCS の CVS は VSC の SCV に有効」
---
ちなみに意味は以下。(略語検索サイト [acronymfinder.com]を利用)
Version Control System
CVS
Virtualization Service Client (Windows)
Secure Configuration Verification
Re: (スコア:0)
ねえねぇ、CSV は?
= Comma Separated Values
--
ついでに SVC は、こちら [e-words.jp] だそうで、いやーただの "Service" の略かと思ってた。
Re: (スコア:0)
カンマ以外の文字で区切られているものをCSVと言う場合はこちらの略です。
そもそも (スコア:2, 興味深い)
もそもそ (スコア:2, 興味深い)
がんばりなされ。
ところで、他の参加者は気後れがして、書き込めないでいるのかもしれない。
一人しかアクティブメンバーのいないコミュニティサイトに書き込む、
というのは、それなりに緊張感や抵抗感がある行為だからね。
あなたの後輩ポジの人物がメンバーにいれば、
食事やお茶、お菓子、金品、暴力、色仕掛け、泣き落とし等々の
手練手管でむりくり何かを書かせてみよう。
サクラも実際やるとなったら、結構大変な作業なので、
カキコのネタ、話題のタネみたいなモノを、さりげなく提供してあげよう。
そういうメンツが居なければ、別垢作って、
ぶっちゃけ、自分でサクラをしてみるのも一手だ。
ネタ割れが怖かったら、性別詐称でネカマ・ネナベデビューしてみよう。
意外にバレないかも知れないし、新しい世界も開けるかもしれない。
自分キャラ同士で絡まないようにだけは、気を付けて。
先にも書いたけど、あなた一人がアクティブでいる、というのは、
他のメンバーが書き込み難い状況を作り上げているかもしれない。
しかし、みんなで渡ってしまえば、赤信号も怖くは無いんだ。
ほかのみんなが居る、という雰囲気を、上手くかもし出せたら、
現状を改善できるかもしれないよ。
Re:そもそも (スコア:1, 興味深い)
それでもメモ的な話をメールに流して、はいおしまいという人は多いです。
Re:そもそも (スコア:1)
とか言って、勇気を出して書き込んでみたら書式がどうだの
用語の定義がどうだのいちゃもんつけて全面的に書き直させたり
時には勝手に書き換えたり…
ほかの方が「どうやって書き込みさせるか」について書かれてますので
書き込みがあったら、上記のようなことが起きないように盛り上げてください。
Re:そもそも (スコア:1)
つーか、「これ載せておいて。」とメールが来ます。
Re: (スコア:0)
・個人的なメモでも良いからどんどん書けと事ある毎に言った
・近所の美味い店とか書くページを用意して、堅苦しさを無くした
とかやってたら、ちらほら書くようにはなりました。
Re: (スコア:0)
>・個人的なメモでも良いからどんどん書けと事ある毎に言った
これはあんまり効き目なかったなあ。
どうせ一部のアルファブロガーみたいな人しか書かないよ。
>・近所の美味い店とか書くページを用意して、堅苦しさを無くした
これやったら、その話題しか書かれなくなった。
結果的にプロジェクトWikiが美味い店コンテンツに乗っ取られた状態になった。
あと個人的には、うらみつらみを書くのが一番いいと思うんだが、
よほど奇特な人以外の大抵の人にとって一番書くのが怖いことでもあるんで、あんまり意味なし。
Re: (スコア:0)
いわゆるwikiサイトにもままあることですね。
編集権限オープンにしてるのに、管理人しか記述しないという。
Wiki導入する場合には、心理的なものと技術的なものと両方をフォローすべきだと思います。
・自分も勝手に書いていいのかどうか分からない
→自由に記述していいと明記する、書き直しもできるし誰かに添削の頼めるから気楽にと伝える
・Wikiの構文に不慣れ(構文を知らない)のでどうしたものか分からない
→Wiki構文駆使する必要はないと明記する、出来るようになりたい人にはリファレンスを提示する
ちっ (スコア:1)
なんでWikiで議論してるの? (スコア:0)
前段のドキュメント作成の話から、後段の議論の話へ飛躍しすぎ
いや、分かるけどね
Re: (スコア:0)
いや、使って使えないことは無いだろうけど、その程度だと思うよ。
Re:なんでWikiで議論してるの? (スコア:1)
見極め (スコア:0)
独裁者になりたがる人の傾向ってのはすぐ分かるんで、
なるべく早くに気付き、wiki以外のもっとリアルタイム性のある方法でつつくなり
いっそコミュニティから追い出すか、その人のいないプロジェクトを別途立ち上げるのがよいかと。
もしくは厄介者以上に独裁者ぶれば、その厄介者は暫くは身を潜めることでしょう:)
Re:見極め (スコア:2)
> いっそコミュニティから追い出すか、その人の
> いないプロジェクトを別途立ち上げるのがよいかと。
で、追い出した側のメインメンバは追い出された奴に
「独裁者」と呼ばれるようになると。
Re:見極め (スコア:1, すばらしい洞察)
>いっそコミュニティから追い出すか、その人のいないプロジェクトを別途立ち上げるのがよいかと。
オープンソースだとそれができるんですよね(遠い目
仕事だと(ry
Re:見極め (スコア:2, すばらしい洞察)
運用方法をおざなりにして始めると、行き詰まるパターンに陥りやすい。
苦労を最初にしておくか、後から苦労するかの違いなのだが、
後からの苦労は最初の苦労より何倍も大きくなりがちだ。
なので、仕事なら手抜きしないで土台を固めてから始めましょう。
必要なら根回しを事前にしておくのも準備のひとつだ。
Re: (スコア:0)
>運用方法
ただ、どういう運用方法がプロジェクトを幸せにする運用方法なのか?が、あまり知られていないよね。
#ベストプラクティスとか、グッドラッパー(?)とか。
むろんプロジェクト内の人が独自に正しい結論に行き着く可能性もあまり期待できないし。
で、DQNな運用方法を採用しちゃって、
かえってしっちゃかめっちゃかになるとか、
逆に活気が丸っきり潰されてしまって意味なしメディアに成り下がるとか、
といったパターンがよくある。
手探りでやってったほうがまだマシだったかも、ということはよくある。
「土台を固めて「から」はじめる」のが上策かどうかは不明です。
下策ではないのでしょうけども、
上になる保証もないので、
それはせいぜい中策です。
Re: (スコア:0)
それを活用すれば良いだけのこと。
オンライン会議と考えれば、昔から存在する「会議の手法」を転用するとか、
オンライン会議向きの活用本を利用すると土台を作るのは比較的楽になる。
基本ってあまり変わってるわけじゃないからね。システムに応じて微調整する必要はあるけど。
ちなみにビジネス教則本のジャンルで探せば、山と出てるからお好みのものをどうぞ。
#ただし、大事なのはシステム上で何をやろうとするか? の視点だ。
#それが最初に定まってないと運用も決まらん。
Re: (スコア:0)
大変苦労しています。
マネージャーの人の上司に話しても、マネージャーと
相談してねで終わりなのですが何かいい方法は
無いですかね。
wikiといえばPukiWiki (スコア:0)
独裁いけないんですか? (スコア:0)
正直な話し、「プロジェクト」というものを行うためには独裁者が必要でしょう。
たとえばライブラリアンとか。
Re:独裁いけないんですか? (スコア:2)
必要なのは『独裁者』じゃなくて『責任者』な。
独裁者は必ずしもプロジェクトに対して責任を持つ訳じゃないからなぁ。
Re: (スコア:0)
いや、責任者だけじゃダメだって。
責任者が独裁者と兼務になるのは良いよ。
でも、責任者だけではは責任を持つかもしれないが、プロジェクトを目指す方向に引っ張れない。
責任者………… (スコア:2)
本来の責任者は『プロジェクトを達成すること』に責任を持つのだから、
あらゆる手を尽してプロジェクトを目指す方向に引っ張る…………はずなんだけどなぁ。
現実には、問題が発生したときに責任だけを負わされる名ばかり責任者も多いけどね…………
あと、独裁者は『自分の望むことを達成する』という行動を取るから、必ずしもプロジェクトの
ためにはならんよ。たまたまプロジェクトの目指している方向と独裁者の目指している方向が
一致すればいいけど、大抵は毒にしかならないからなぁ。
Re:責任者………… (スコア:1)
>必ずしもプロジェクトのためにはならんよ。
そんなのはどのような「政治体制」においても同じ事。
ただ小規模な組織においては「プロジェクトの成功を希望する」独裁者に
『自分の望むことを達成する』という行動を取ってもらわないと成功は
おぼつかない。あくまで一つのベストプラクティスということだと思う。
話を戻して
>独裁いけないんですか?
プロジェクトを引っぱっていく「(慈悲深き)独裁者」は有益な場合が多い。
しかしここで問題とされているのは、プロジェクトを引っぱっていく能力も
気概もない人間が、Wikiの中でだけ独裁者の顔をしたがることではないだろうか。
そして、いずれにせよオープンソース開発において政治の問題は避けて通れず、
どういう政治体制をとろうとも政治というのは難しいものだという、月並みな
結論しか出ない気がする。
いけないよ (スコア:1)
独裁だとみんなごまかすようになるよ。
Re: (スコア:0)
けど、プロジェクトを推し進めるマネージャーは得てして独裁者の気があるよね。
独裁者でないマネージャーは他人の意見を聞きすぎてすぐ迷走するし。
Re: (スコア:0)
- プロジェクトの方向性を無視し(後から聞くと「興味なかった」らしい)
- 限られた時間とリソースを自分の興味のままに思う存分使い散らし
- でかい声でいやがる他人を無理に動かし
- 自分1人の考えをあたかも全体の決定のように外部の人間に話し
- 自分のやってることが絶対的に正しいと信じている
そういう奴は昔のプロジェクトにいたな。
Re: (スコア:0)
そいつは駄目なやつでしょう。
全部独裁者で無くてもなれる属性だし。
ウィキペディアの議論 (スコア:0)
みてみなよ、管理者の任期制なんて何年も前から議論が沸いてはなかったことにされ、
ちょっとがんばれば、がんばったやつが追放され、
任期が長けりゃ解任動議だしてもいいから、そんなものいらんって言うのに
誰もださないし
居座るやつは、くだらないやつ。
Re: (スコア:0)
いやだって頑張ってるやつをいぢめるのは楽しいよ。特に自分と反対の意見を持っているやつはね。
Re: (スコア:0)
なんか哀れだ・・・
Wikiを用いた… (スコア:0)
議論ってのは土俵が悪いって喧嘩するためにあるものじゃないだろ?
粛正 (スコア:0)
Re:粛正 (スコア:1)
uyabin