Author: matakagi
Date: Sun Sep 30 00:43:50 2007
New Revision: 1225
Log:
- translated introduction of "Handling Growth".
Modified:
trunk/ja/ch06.xml
Modified: trunk/ja/ch06.xml
==============================================================================
--- trunk/ja/ch06.xml (original)
+++ trunk/ja/ch06.xml Sun Sep 30 00:43:50 2007
@@ -2616,8 +2616,12 @@
<!-- ======================== SECTION ============================== -->
<sect1 id="growth">
+<!--
<title>Handling Growth</title>
+-->
+<title>巨大化への対応</title>
+<!--
<para>The price of success is heavy in the open source world. As your
software gets more popular, the number of people who show up looking
for information increases dramatically, while the number of people
@@ -2631,7 +2635,28 @@
provide a place where people can get their questions answered, while
others watch and (presumably) absorb knowledge from observing these
exchanges.</para>
+-->
+<para>
+ オープンソース界では、成功の代償は重いものです。
+ あなたの書いたソフトウェアが有名になればなるほど、
+ その情報を知りたがる人の数も劇的に増加します。
+ 一方、みんながほしがっている情報を提供できる人の数は、
+ それほど急激に増えることはありません。
+ さらに、たとえ情報をほしがる人と情報を提供する人の増加率が
+ うまい具合にバランスがとれていたとしても、
+ オープンソースプロジェクトのメンバー間でのコミュニケーションは
+ 人数が増えれば増えるほど面倒になります。
+ たとえばメーリングリストを考えてみましょう。
+ たいていのプロジェクトには、一般的なユーザ向けのメーリングリストがあります。
+ いわゆる "users" とか "discuss" とか "help"
+ などといった名前のメーリングリストです。
+ 名前が何であるかにかかわらず、これらのメーリングリストの目的は同じです。
+ 疑問がある人が質問をすれば何らかの答えが得られるということ、
+ そして、それらのやり取りをただ眺めていることで
+ それなりの知識を得られるということです。
+</para>
+<!--
<para>These mailing lists work very well up to a few thousand users
and/or a couple of hundred posts a day. But somewhere after that, the
system starts to break down, because every subscriber sees every post;
@@ -2649,7 +2674,29 @@
ominous: the usual open source model of massively parallelized support
simply does not scale to the levels needed for world
domination.</para>
+-->
+<para>
+ この手のメーリングリストのメンバーは数千人になることも珍しくありません。
+ また、一日あたりの投稿数が数百になることもよくあります。
+ しかし、このくらいの規模になってくると、システムは徐々に破綻しはじめます。
+ 個々のメンバーが一日にさばききれない量のメッセージを受け取るようになると、
+ メーリングリストのメッセージがその人にとって重荷になってしまうでしょう。
+ 考えてもみましょう。たとえば、Microsoft が Windows XP
+ 用にこの手のメーリングリストを開設したとします。
+ Windows XP を使っている人は、世界中に何億人といます。
+ そのうちのほんの 0.1% の人が 24 時間のうちにひとつの質問を投稿したとすると、
+ この仮想メーリングリストの一日の投稿数は10万通にもなってしまいます!
+ もちろん、実際にはそんなメーリングリストは存在しません。
+ もしあったとしても、だれもそんなメーリングリストのメンバーでい続けることはできないでしょう。
+ これはメーリングリストに限った問題ではありません。
+ IRC チャネルやオンラインの掲示板、
+ その他個人からの質問を受け付けるあらゆるシステムには同じ論理があてはまります。
+ この論理が示唆するところはあまり思わしくありません。
+ オープンソースモデルでしっかりとしたサポートを続けようとすると、
+ 世界征服できるほどにまでプロジェクトの規模を拡大するのは不可能だということです。
+</para>
+<!--
<para>There will be no explosion when forums reach the breaking point.
There is just a quiet negative feedback effect: people unsubscribe
from the lists, or leave the IRC channel, or at any rate stop
@@ -2668,20 +2715,65 @@
the experience to do so start to look elsewhere for answers first.
Adjusting communications mechanisms to cope with project growth
therefore involves two related strategies:</para>
+-->
+<para>
+ メーリングリストや掲示板の規模が臨界点に達しても、
+ 大爆発が発生するといったことはありません。
+ 負の反応は、静かに出てくることになります。
+ たとえばメーリングリストから脱退する人や
+ IRC チャネルから去る人が出てきたり、
+ ノイズが目障りだという理由で質問を控える人が出てきたりといった具合です。
+ 人がみなこのように合理的な選択をすれば、
+ 掲示板の規模はある程度管理可能な範囲で落ち着くのでは?
+ と考える方もおられるかもしれません。
+ しかし、このような場合にまずメーリングリストから去っていくのは、
+ たいていの場合は経験を積んだメンバーです。
+ 一方、参加して日が浅い人たちはそのままそこに残ったままでいるでしょう。
+ つまり、プロジェクトの規模が大きくなりすぎても
+ まだ同じコミュニケーションモデルを使用していると、
+ その場における質問や回答のレベルが徐々に低下していくということになります。
+ まるで、(実際にはそうではないかもしれないのに)
+ 新参者のほうが古参メンバーより劣っているというように見えてしまうかもしれません。
+ このような状況になると、古株のメンバーは
+ そこに参加するメリットをあまり感じられなくなり、
+ どこか他の場所を探すようになるでしょう。
+ プロジェクトの規模が拡大したときにコミュニケーションの仕組みをどうするか。
+ これには、次のふたつの戦略がかかわってきます。
+</para>
<orderedlist>
+<!--
<listitem><para>Recognizing when particular parts of a forum are
<emphasis>not</emphasis> suffering unbounded growth, even
if the forum as a whole is, and separating those parts
off into new, more specialized forums (i.e., don't let
the good be dragged down by the bad).</para>
</listitem>
+-->
+ <listitem>
+ <para>
+ 全体としては巨大化の悪影響が出てきつつあるようだが、
+ 特定の分野の話題についてはまだその影響を受けて<emphasis>いない</emphasis>
+ というところを見つけたら、その分野の話題だけに特化した会議室を新たに作成する
+ (つまり、被害が及ばないうちに他の場所に避難させる)。
+ </para>
+ </listitem>
+<!--
<listitem><para>Making sure there are many automated sources
of information available, and that they are kept
organized, up-to-date, and easy to find.</para>
</listitem>
+-->
+ <listitem>
+ <para>
+ 情報を自動的に取得できる場所を多く確保し、
+ それをきちんと系統立てて管理する。
+ また、常に最新の情報を反映させ、人が見つけやすいようにする。
+ </para>
+ </listitem>
</orderedlist>
+<!--
<para>Strategy (1) is usually not too hard. Most projects start out
with one main forum: a general discussion mailing list, on which
feature ideas, design questions, and coding problems can all be hashed
@@ -2696,7 +2788,26 @@
between the types themselves. They could be divided into separate
lists without causing any harmful balkanization, because the threads
rarely cross topic boundaries.</para>
+-->
+<para>
+ 作戦 (1) は、通常はそんなに難しくはありません。
+ たいていのプロジェクトは、最初はメーリングリストがひとつだけで始まります。
+ そこでは、一般的な議論のほかに、機能追加の要望や設計に関する疑問、
+ コーディングに関する問題などさまざまな内容をごちゃ混ぜにして扱います。
+ そしてプロジェクトにかかわるすべての人たちがそのメーリングリストに参加しています。
+ しばらくすると、扱う内容によって
+ いくつかのメーリングリストに分割したほうがよいということがわかってきます。
+ たとえば、あるスレッドでは開発に関連する話題が盛り上がっており、
+ 別のスレッドでは、いわゆる「○○をするにはどうすればいいの？」
+ 的な質問が行われ、また別のスレッドではバグレポートや機能追加要求が行われていたりといった具合です。
+ 中にはこれらのスレッドの複数に参加する人もいるかもしれませんが、
+ ここで重要なのは、これら異なるタイプのスレッドには
+ 共通点がほとんどないということです。
+ ということで、これらの話題をそれぞれ個別のメーリングリストに分割しても、
+ 特に弊害は出ないでしょう。
+</para>
+<!--
<para>Actually doing this division is a two-step process. You create
the new list (or IRC channel, or whatever it is to be), and then you
spend whatever time is necessary gently nagging and reminding people
@@ -2709,7 +2820,23 @@
responses can simply reference that web page and, as a bonus, the
recipient may learn something about looking for guidelines before
posting.</para>
+-->
+<para>
+ この分割は、二段階の手順を踏んで行います。
+ まず新しいメーリングリスト (あるいは IRC チャネルなど) を作成し、
+ 次にそのメーリングリストを適切に使用するよう、
+ 他の人たちを誘導することになります。
+ 後半の作業は数週間程度の時間をかけて行うことになりますが、
+ それくらいあれば人はみなその考えを理解してくれるでしょう。
+ あなたがすべきことは、間違った場所に投稿してきた人に対して
+ 他人にも見える場所でそれを指摘してあげることです。
+ そうすれば、他の人たちはいちいち指摘されなくても新しい場所を利用することになるでしょう。
+ すべてのメーリングリストの一覧をまとめたウェブページを作成するのも有用です。
+ 他の人に新しい場所を指定する代わりに、そのページを参照させるだけでよくなります。
+ うまくいけば、他のメンバーも投稿の前にそのページを参照してくれるようになるかもしれません。
+</para>
+<!--
<para>Strategy (2) is an ongoing process, lasting the lifetime of the
project and involving many participants. Of course it is partly a
matter of having up-to-date documentation (see
@@ -2717,6 +2844,16 @@
<xref linkend="getting-started"/></phrase>) and making sure to
point people there. But it is also much more than that; the sections
that follow discuss this strategy in detail.</para>
+-->
+<para>
+ 作戦 (2) は、そのプロジェクトが存続する限りずっと続けることになる作業です。
+ もちろんこれは、ドキュメントを常に最新の状態に保って
+ (<phrase output="printed"><xref linkend="getting-started"/></phrase>
+ の <xref linkend="documentation"/> をごらんください)
+ みんなをそこに誘導するという作業の一環でもあります。
+ しかし、それ以外にも考慮すべき点があります。
+ このセクションでは、こちらの作戦について詳しく見ていきます。
+</para>
<!-- ======================== SECTION ============================== -->
<sect2 id="using-archives">
_______________________________________________
Producingoss-translators mailing list
[email protected]
http://www.red-bean.com/mailman/listinfo/producingoss-translators
