コンテンツにスキップ

英文维基 | 中文维基 | 日文维基 | 草榴社区

Wikipedia:議論が終わったらまとめておく

Wikipedia:REFACTORから転送)

議論のまとめリファクタリング[注釈 1][注釈 2])は、ノートページなどでの議論が合意に達したら、元の意味を変えないように注意しながら、文章が読みやすくなるように、書き直すことです。議論をあとから参考にしやすくするために行います。議論中にまとめるのは避けましょう。

議論のまとめをうまく行えば、本題と関連のある重要な話題はきちんとすべて残しながらも、文章全体をずっと短くできる場合があります。議論のまとめの作業は、ウィキペディアでは重要です。議論のまとめがあれば、その記事の編集に新たに参加したいと思った人が、過去にノートで行われた長々しい議論(過去ログが何ページもできているノートもあります)のすべてに目を通さずにすむことになります。

議論のまとめの目標は、繰り返し出てくる内容を省いたり、関係ない情報を減らしたりすることで、より重要な情報の割合を高めることだと思ってください。今後その記事を編集しようとする人に役立たない不要な内容はみな削除してもいいでしょう。しかし、有用な情報を削除してはいけません。大事な情報ではあるがその場には不適切な内容なら、別の適切な場所に移動させるのがよいでしょう。

議論のまとめの作業に慣れるには、まず、井戸端調べもの案内などで自分が関わった問答をまとめてみるのがよいでしょう。既に答えの出た解決済の事柄について、要約してみることです。

議論をまとめる時期

[編集]

議論がまだ継続中なのに、まとめるのは避けましょう。これはその議論をさらに紛糾させてしまう可能性があり、また、議論に参加している人からすれば、議論の最中にまとめられてしまうことは不愉快なことかもしれません。

自分がその議論に参加し、何かを強く主張している場合は、自分がその議論をまとめるのはやめましょう。議論のまとめは、元の意味を変えないようにしなければならないのですが、あなたがまとめると、あなたの強い主張が反映されたまとめができてしまうかもしれません。

議論のまとめは、1回行えばそれで終わりというものではありません。継続して議論の更なるまとめを検討するのは良いことですし、まとめたいときに行って構いません。

議論をまとめる利点

[編集]

議論をまとめると、まとめる当人はもちろん議論の関係者みなの論点の重要性の程度などをすべてさらけ出すことになります。まとめる作業をどんなに慎重に行っても、関係者はショックを受けたり、教訓的だと感じたり、不満を持ったりするかもしれません。

自分が関与した議論を要約しようとするときには、自分の意見によるバイアスがかかってしまいがちですので、議論の過程で自分の心がどのような変化をしていったかを分析し、議論の過程を再度ずっと追ってみるのがよいでしょう。議論の最中には、熱くなるあまり、見落としてしまっていた重要な点を、議論をまとめようとしたときには気付くことが多いものです。井戸端などで議論のまとめをしてみると、うまくまとめるためにはどんなことを理解している必要があるか、がよくわかると思います。

署名の取り扱い

[編集]

議論をまとめるときに、誰かの発言を編集したら、署名は削除してください。そうでないと、あなたが改変した内容を、署名の人が書いたものと誤解されてしまいます。その内容が、誰が主張した内容であるかが必要なら、第三者の発言として書いてください。例えば、「ウィキペディアは素晴らしい。 Jimbo」という署名付の発言を改変するときは、「Jimboさんは、ウィキペディアは素晴らしいと書きました。」とします。

まとめるときに使う単語は、もとの発言に使われているものをそのまま使ったほうがよい場合が多いでしょう。こうしておくと、元の発言とまとめたものを比べるときに、どの部分をまとめに使って、どの部分を省いたのかがわかりやすくなります。

関係ない発言は、以下の例のように省くことができます。ただし、署名付の発言の改変、削除は議論の対象となる可能性があることは覚えておいてください。

まとめる前の議論(井戸端での例):
○○さんが、記事[[△△]]で、自説を譲るつもりが全くないみたいで、議論にならなくて困っています。経験豊富な方々、何とかしてください。初心者A
その問題は、井戸端で書くよりも、Wikipedia:論争の解決で依頼したほうがよいと思います。経験者A
Wikipedia:論争の解決は、仲裁を受け付けるページではありませんので、Wikipedia:コメント依頼に書くべき件だと思います。経験者B
すみません、経験者Bさんの書かれた通りです。まず Wikipedia:論争の解決を読んで、状況がどこに当たるのかを考え、その上で必要なら Wikipedia:コメント依頼にその件を書くとよいでしょう。経験者A
議論をまとめた後:
○○さんが、記事[[△△]]で、全く自説を譲るつもりがないみたいで、議論にならなくて困っています。経験豊富な方々、何とかしてください。初心者A
その問題は、まず Wikipedia:論争の解決を読んで、状況がどこに当たるのかを考え、その上で必要なら Wikipedia:コメント依頼にその件を書くとよいでしょう。経験者A

同様に、後から意味がなかったとわかったコメントなどは、なぜそのときそれを書いたのか?を説明するのではなく、単に削除してしまったほうがよいでしょう。

例:
○○の投票は、規定の7日間を過ぎましたが、その間にサーバダウンでアクセスできない日が4日ほどありましたので、その分期限を延長する必要はないのでしょうか?利用者A
その件は、利用者Cさんが、すでに対応されているようですので、該当ページをご確認ください。利用者B
わかりました。利用者Bさん、ありがとうございます。このページはちょっと前には見ていたのですが、そのときはまだその掲示がありませんでした。ここでうかがう直前にもう一度見ておくべきとは思ったのですが、サーバが重いようでなかなか表示されずにチェックできませんでした。利用者A

この例では、利用者Aさんの最初のコメントは、もはや意味がないことがわかったので、利用者Aさんは、最後の説明のコメントを書くのではなく、かわりにこの質問と回答自体を削除することもできました。こうすれば、このページをウォッチリストに入れている人も、関係のない会話を読まされなくとも済みます。 c2:DeleteDontJustify(言い訳をする代わりに削除する)を参照。

反論の扱い方

[編集]

議論のまとめ方は、仮に一般的なやり方で行ったとしても、必ずしも全員から支持されるとは限りません。必ずまとめる前のオリジナルの議論へのリンクを張りましょう。こうすれば、あなたのまとめ方がどのようなものかがチェックできますし、必要なときに、元の議論を手軽に参照し、元の発言がどのようなものだったのかも確認できます。議論をまとめると同時に、オリジナルも保存することで、必要な情報が失われているという不満は減るでしょう。また、あなたのまとめた議論を、オリジナルの議論であると誤解する人がいないよう、それがまとめであることをはっきりと書いておきましょう。

議論をまとめることそのものに不満を持つ人がいる場合には、そのページをまとめてしまわないで、別のページにまとめをつくりましょう。つまり、「ノート:○○/過去ログ7」~「ノート:○○/過去ログ10」に直接手を加える代わりに、「ノート:○○/過去ログ7~10のまとめ」という別のページをつくります。そして、「ノート:○○/過去ログ7」~「ノート:○○/過去ログ10」と「ノート:○○」(最新のノート)の冒頭に、「ノート:○○/過去ログ7~10のまとめ」へのリンクを張ります。こうしておけば、短いまとめを読みたい人も、オリジナルの発言が読みたい人も満足できるでしょう。

議論のまとめの方法

[編集]

要約

[編集]

ノートページの議論が長すぎるときは、それを要約してもよいでしょう。しかし、議論のまとめは、短く要約するだけではなく、文章を再構成しないといけない場合も多いようです。

関係ない話題を移動する

[編集]

ノートページをまとめるときには、ウィキペディアはチャットではないことを思い出してください。記事を作り上げる過程ではノートで様々な会話をしながら進めることはありますが、この会話の様子はあとからこの記事に加筆する人には役に立つでしょうか? おそらく役には立たないでしょう。そこで、記事内容と直接関係のある内容だけにしぼり、議論の焦点となった事柄を洗い出して記述し、逆に、個人攻撃や、誰かの編集を非難するような内容、管理者権限の濫用の訴え、誰かをブロックするべきだ、などなど、記事内容と関係ない話題を除きましょう。

役に立ちそうなコメントがあったら、それを再構成するか、別の場所に移動します。そうでなければ削除しましょう。時間があって、読む気がある人には、完全なオリジナルの過去ログは保存されています。あなたのまとめはあくまでもそれ以外の大多数の利用者の利益を考えて行ってください。

「質問と回答」形式をやめる

[編集]

議論のまとめの簡単な方法の一つは、質問と回答形式になっているものを、回答を中心とした、まとめの文の形式に変更することです。

例:

まとめる前
== 教えてください ==
ウィキペディアで文字サイズを大きくするにはどうしたらいいでしょうか? 初心者A
利用者:初心者A/vector.css を表示して、font size:160% のように書き込んでください。経験者A
経験者Aさんありがとうございます。文字を大きくできました。初心者A
まとめた後
== フォントサイズの変更 ==
表示フォントのサイズを変更するには、[[利用者:< あなたのユーザー名>/vector.css]]に、font size:160% などと書き込みます。

この例では、まとめた後も有用な情報は残っています。この例を見ると、議論のまとめはあまり早くはやらないほうがよいことがわかると思います。経験者Aさんが、初心者Aさんのお礼をちゃんと読まないうちに、このやりとりを消去してしまうようですと、まとめの時期としては早すぎるということです。また、その内容を誰が書いたのかを、まとめにも記しておくことが大事な場合もあります。これは特に、内容に議論がありそうな場合などが当てはまります。

まとめかたの例:
フォントサイズを変える方法として、経験者Aさんから、[[利用者:<あなたのユーザー名>/vector.css]]を表示させて、font size:18pt を書き加える方法が紹介されました。一方、経験者Bさんによれば、このときのサイズの指定方法として、18ptなどの絶対サイズではなく、160%などの相対サイズを使うべきであるとのことです。

どの回答が正しいのか、明らかになっていない場合には、両方を提示して、それぞれの意見に提示した人の名前を書き添えておくと、それを読んだ利用者はどの方法を選ぶかの参考になるでしょう。井戸端などの非常に長いページでは、まだページ全体を過去ログにまわすには早すぎるし、そのセクションをどこか他のノートページに移動するのにも早すぎる、ということがありますが、そういうときにはこの方法が役立つでしょう。

議論を FAQ 形式にする

[編集]

何度も同じ質問、提案がなされるような場合には、FAQ(よくある質問と回答集)をつくるとよいでしょう。つくりかたとしては、既にある質問と回答を、文を推敲するなどしてわかりやすく仕上げるだけです。FAQをつくると、過去に何度も出ている質問、回答をまとめから削除できるだけでなく、これから同様の質問が何度も出ることも予防できます。実例として、 英語版のマザーテレサのFAQ や、アカウント関連のFAQ(Help‐ノート:ログインの過去ログ)をご覧ください。

議論の順番を変える、名前をつけなおす

[編集]

議論のまとめは、文を書き直すような面倒な作業をしなければいけないとは限りません。各話題を並べなおして、節を区切るだけで非常に読みやすくなる場合もあるでしょう。ほとんどのノートページでは、時系列順に発言が並んでいますが、まとめるときは、その順番を守る必要はありません。たとえば、賛成意見と反対意見のリストを完全に分けて、別々の節にしてしまうとわかりやすくなることもあります。

ノートページの過去ログがたくさんあるときには、過去ログページの名前をつけなおすとわかりやすくなることもあります。たとえば、Wikipedia talk:requests for adminship/should bureaucrats use their judgement という名前にすると、Wikipedia talk:Requests for adminship/Archive 17よりはわかりやすく、参照しやすくなるでしょう。そして、その過去ログには、その主題に関して議論された内容をすべて集めます。オリジナルの過去ログへのリンクを張って、もとはどこにあった議論なのかを明確にすることもできます。もし、その話題が頻繁に出される話題なら、そのための新しいノートページをつくってしまうのもよいでしょう。たとえば、長ダッシュの使い方については、毎月のように議論が起こった問題なので、過去ログのあちこちに議論が散乱しています。en:Wikipedia talk:Manual of Style (dashes) というページを新たに作っておけば、利用者が長ダッシュに関する過去の議論について学びたいときに、スタイルマニュアルに関するほかの内容に埋もれた議論を発掘するのに時間を無駄にせずにすみます。

もし、過去ログを分割するときには、必ず、話題ごとに分割することにして、意見ごとに別の過去ログに分割するのはやめましょう。これを行うと、自分の考えと同じ意見だけを参考にするのに集中してしまいがちですし、そのまとめ記事の中立性がくずれます。

議論の再構成が特に有効な場合があります。en:MeatballWikiForest Fire(山火事)と呼んでいる現象が起きた場合です。これは、関連する議論がいくつものページに爆発的に広がってしまった場合のことを指します。削除依頼や、進行中の荒らし行為、井戸端、保護依頼などを中心にして起こりがちです。また、関連するいくつかのノートページで並行して議論が進むような場合もこれに当てはまります。このパターンは、議論に加わっていなかった「部外者」にとっては議論をフォローできないので、あとから利用するときを考えると議論の価値が大幅に下がってしまいます。解決法は単純で、関連する議論を1つのまとめページに集めてしまい、他の議論の場には、まとめページへのリンクを残しておく、という方法です。

概要を加える

[編集]

進行中の議論で、まだ議論全体をまとめる段階には至っていない場合でも、要約をつけると便利なことがあります。議論の最初に、ざっと様子がわかって、しかも議論が白熱している部分には触れないような概要を加えるとよいでしょう。何が議論の焦点になっているのかを書き加えてもよいでしょう。

その他

[編集]
  • ページ全体の議論をまとめる時間がないなら、節のタイトルをわかりやすく変えるだけでも効果的です。上の例で、「フォントサイズの変更」というタイトルは、「教えてください」よりはずっとわかりやすいはずです。
  • 関連するページのまとめを書く時間がなくとも、関連する議論が行われているページがどこなのかをリンクとして追加しておくだけでも他の利用者には大いに役立ちます。
  • かつて自分がかかわったノートの議論なら、他の利用者が読んでわかりやすいように論点を整理するのもよいでしょう。あなたや議論の相手がそのときは当然だと思っていたことを書き加えてください。書いておかないと数ヵ月後には忘れてしまうかもしれません。たとえば、あなたがある利用者のコメントを完全に無視することを決めたとしましょう。すると、将来そのページを見た人は、あなたのことをこの件でアクセス禁止になったのかな、と思うかもしれません。
  • 議論のまとめの目的は、ノートでの議論を、当初の会話状態のものよりも役に立つような形に改めることです。将来他の利用者が読みやすくなるような方法を考えてください。

注釈

[編集]
  1. ^ リファクタリング (Refactoring) は、プログラミング用語です。プログラミング用語のリファクタリングは、プログラムのソースコードを、意味を変えないように、すっきりと書き直すことを指します。しかし、この用語は、「議論をまとめる」というこの作業の意味を理解させやすくするよりも、誤解を招くかもしれないとされる場合もあります。プログラムでは、「意味を変えないように書き直す」ということは非常に明確ですが、ノートでの議論については、意味が変わっていないかどうかは単純に結論づけられない点が大きく異なっているからです。
  2. ^ Wikiの他プロジェクトでは、議論のまとめの作業を、その内容によって、リファクタリング (Refactoring) とリワーキング (Reworking) として区別している場合もありますが、ここでは、ノートページを読みやすくするために手を加える作業を、すべて「議論のまとめ」として扱います。

関連項目

[編集]

外部リンク

[編集]