Author: mumumu Date: Sun Jun 22 19:09:59 2008 New Revision: 1472 Log: - translated "Be Open About Your Motivations" section.
Modified: trunk/ja/ch05.xml Modified: trunk/ja/ch05.xml ============================================================================== --- trunk/ja/ch05.xml (original) +++ trunk/ja/ch05.xml Sun Jun 22 19:09:59 2008 @@ -776,8 +776,12 @@ <!-- ======================== subsection ============================== --> <sect1 id="open-motives"> +<!-- <title>Be Open About Your Motivations</title> +--> +<title>動機を隠し立てしない</title> +<!-- <para>Be as open about your organization's goals as you can without compromising business secrets. If you want the project to acquire a certain feature because, say, your customers have been clamoring for @@ -787,7 +791,21 @@ development community knows about <emphasis>why</emphasis> you want what you want, the more comfortable they'll be with whatever you're proposing.</para> +--> +<para> + あなたの組織がプロジェクトで目指していることを、できる限り隠さないようにしましょう。 + ただし、ビジネス上の秘密は漏らしてはいけませんが。 + たとえば、自分の顧客から強く要求されているという理由で、 + ある機能をプロジェクトに取り込んでもらいたいのであれば、 + メーリングリスト上で率直にそう言うようにしましょう。 + 顧客から自分のことを秘密にしてほしいと頼まれることもありますが、 + その場合は匿名で事例を紹介させてもらえるかどうかを少なくとも聞くようにします。 + 開発コミュニティがあなたがやりたいことの <emphasis>動機</emphasis> を知れば知るほど、 + あなたが何を提案しても違和感がより少なくなります。 +</para> + +<!-- <para>This runs counter to the instinct—so easy to acquire, so hard to shake off—that knowledge is power, and that the more others know about your goals, the more control they have over you. @@ -800,7 +818,23 @@ will start to suspect a hidden agenda. But if you give just a few real-world scenarios showing why the proposed feature is important, that can have a dramatic effect on the debate.</para> +--> +<para> + これは、知識は力であり、他人が自分の目標を知れば知るほど多く干渉される、 + という直感に反するものです。 + — 直感を受け入れるのは簡単ですが、取り除くのは難しいものです。 + しかし、ここではその直感は間違っています。 + 新機能 (バグ修正でもなんでも) を公の場で主張することで、 + あなたは <emphasis>既に</emphasis> カードをテーブルに置いているのです。 + その時点で唯一問題になるのは、目標を共有できるようにコミュニティを誘導できるかどうかです。 + 仮に望むことだけを主張して、その理由となる具体例を述べなければ、 + その主張は弱くなってしまいますし、隠れた意図があるのではないかと疑われてしまいます。 + しかし、現実世界のシナリオを 2,3 述べ、提案している新機能がなぜ重要なのかを示すだけで、 + 議論する上で劇的な効果があるのです。 +</para> + +<!-- <para>To see why this is so, consider the alternative. Too frequently, debates about new features or new directions are long and tiresome. The arguments people advance often reduce to "I personally @@ -812,7 +846,20 @@ experience. Without some countervailing force, the end result is as likely as not to be determined by whoever was the most articulate, or the most persistent, or the most senior.</para> +--> +<para> + 別の視点から考えてみましょう。新機能やプロジェクトの新しい方向性に関する議論は長く、 + 退屈なものです。人々の主張は「個人的には X が欲しいんだよね」とか、 + もっとよくあるのは「ソフトウェア設計を長い間やってきたんだけど、 + X は ユーザにとってもの凄く重要だ / 誰も満足しない余計な飾りだよね」 + といったものになります。現実世界での使い方が示されていないと、 + 議論の短縮や決着に繋がらないばかりか、実際のユーザ体験からは程遠い議論になってしまいます。 + そういった議論を止める力が働かない限り、行き着くところは結局何も決まらない、 + ということになりがちです。 +</para> + +<!-- <para>As an organization with plentiful customer data available, you have the opportunity to provide just such a countervailing force. You can be a conduit for information that might otherwise have no means of @@ -827,7 +874,23 @@ oxygen. As long as you present it right, they will welcome it enthusiastically, and it will propel things in the direction you want to go.</para> +--> +<para> + 大量の顧客データを持つ組織として、あなたにはそういった議論を止めるチャンスがあります。 + 他の人が開発コミュニティに伝えることができない情報へのパイプ役になれるのです。 + あなたが望むことをを支えている情報は恥ずかしいものでも何でもないのです。 + ほとんどの開発者は自分が書いたソフトウェアがどのように使われているのかについて、 + 広い見聞を持っているわけではありません。開発者はめいめいが、 + 自分独自のやり方でソフトウェアを使っているのです。そして他の使い方については、 + 直感や当て推量、そして本能に頼って作っていることを知っているのです。 + 非常に多くのユーザの信頼できるデータを提供することで、 + あなたは開発コミュニティに酸素に似た何かを与えることになります。 + そうした情報を適切に示す限り、彼らは熱狂的にそれを受け入れるでしょうし、 + 物事はあなたの望む方向に進むでしょう。 +</para> + +<!-- <para>The key, of course, is presenting it right. It will never do to insist that simply because you deal with a large number of users, and because they need (or think they need) a given feature, therefore @@ -835,7 +898,7 @@ initial posts on the problem, rather than on one particular solution. Describe in great detail the experiences your customers are encountering, offer as much analysis as you have available, and as -many reasonable solutions as you can think of. When people start +many reasonable solutions as you can think of. When people start speculating about the effectiveness of various solutions, you can continue to draw on your data to support or refute what they say. You may have one particular solution in mind all along, but don't single @@ -847,7 +910,30 @@ get behind it of their own free will, which is much better than you browbeating them into implementing it. (There is also the possibility that they will think of a better solution.)</para> +--> + +<para> + 鍵となるのは、もちろん情報を適切に示すことです。あなたが大量のユーザを抱えていたり、 + ユーザがある機能を必要としている (またはそう思っている) からといって、 + 自分の解決策を実装すべきだと主張してもうまくいかないでしょう。 + むしろ、ある特定の解決策についてではなく、 + 問題となっていることがらをはじめに投稿するとよいでしょう。 + あなたの顧客が経験していることを詳細に記し、できるだけ多く分析しておきます。 + その上で、考えられうるだけの現実的な解決策を提示するのです。 + 解決策がどれくらい有効かを人々が考え始めたら、あなたは彼らの発言を擁護したり、 + 異議を唱えたりするのに自分のデータを示すことができます。 + あなたははじめからずっと特定の解決策が頭にあるかもしれませんが、 + はじめからその解決策を選んで特別な配慮をしてはいけません。 + これは相手を騙しているのではありません。単に普通の「公正な仲裁者」として振る舞うことです。 + 結局、あなたの本当の目標は特定の問題を解決することです。 + 特定の解決策は、そのための手段でしかないのです。 + 仮にあなたが好む解決策が優れていれば、他の開発者達もそれを結局は認めてくれ、 + 彼らの自由意志で応援してくれるようになるでしょう。 + 彼らを威嚇して自分の解決策を実装させるより、この方があなたにとってよいでしょう。 + (彼らが自分より優れた解決策を考えているかもしれません。) +</para> +<!-- <para>This is not to say that you can't ever come out in favor of a specific solution. But you must have the patience to see the analysis you've already done internally repeated on the public development @@ -860,7 +946,23 @@ closed doors. It makes it seem as though efforts have been going on, and perhaps decisions made, that the public is not privy to, and that is a recipe for resentment.</para> +--> + +<para> + これは、特定の解決策を好んでいることを言ってはいけないということではありません。 + しかし、あなたが既に内部で終えている分析が、 + 開発用の公開メーリングリストで繰り返されるまで我慢しなければなりません。 + 「すべての解決策をみてきたけれども、それは A, B, C という理由でうまくいかない。 + 突き詰めて考えていくと、結局唯一の解決策は ...」などと発言してはいけません。 + 問題なのは、こうした発言が尊大に聞こえるということよりも、 + むしろあなたがその問題を分析するためにある未知数の (多分大きいと人々は思うでしょう) + リソースを <emphasis>既に</emphasis> 裏で投入しているという印象を与えてしまうことです。 + これは既に物事が進行していて、多分決定もなされていて、 + 公にはそれについて何も知らされていないように見えてしまいます。 + これは人々の怒りを買う原因になります。 +</para> +<!-- <para>Naturally, <emphasis>you</emphasis> know how much effort you've devoted to the problem internally, and that knowledge is, in a way, a disadvantage. It puts your developers in a slightly different mental @@ -875,7 +977,22 @@ feel comfortable talking to you even when they disagree. If they can't figure out what makes you tick, they'll assume the worst, at least some of the time.</para> +--> + +<para> + 当然、<emphasis>あなた</emphasis> はその問題について裏でどのくらい努力してきたかを知っています。 + その知識はある意味不利なものです。あなたが雇っている開発者は、 + メーリングリスト上にいる他の開発者とは違った精神状態に置かれてしまい、 + その問題について考えたことがない開発者の視点から物事を見る能力が欠けてしまいます。 + より早い段階で他の人にあなたと同じ言葉で考えさせれば、こうした溝は小さくなります。 + この論理は、個々の技術的な状況だけでなく、自分の目標をできるだけ隠さないという広義の要請にも適用できます。 + 知らないことは知っていることよりも不安定なものです。 + あなたがやりたいことの動機を人々が知れば、 + 彼らはたとえそれに反対であってもあなたと気軽に話してくれるでしょう。 + あなたの動機が分からなければ、彼らは物事を悪い方向に考えてしまうこともあります。 +</para> +<!-- <para>You won't be able to publicize everything, of course, and people won't expect you to. All organizations have secrets; perhaps for-profits have more of them, but nonprofits have them too. If you @@ -884,6 +1001,18 @@ accept the fact that you may not have as much influence as you want in the discussion. This is one of the compromises you make in order to have a development community not on your payroll.</para> +--> + +<para> + もちろんすべてを公にはできないでしょうし、人々もそんなことを期待していません。 + すべての組織には秘密があります。おそらく営利組織には多くの秘密があるでしょうし、 + 非営利な組織でもあるでしょう。ある方向性を擁護する義務があるけれども、 + その理由を全く公にできない場合は、 + そういった制約の中で出来るもっとも優れた主張をするようにしましょう。 + そして、議論の中で自分が望むほど影響力を行使できない可能性がある、 + という事実を受け入れましょう。 + これは、開発コミュニティ全体に給料を払わないために行う妥協のひとつです。 +</para> </sect1> _______________________________________________ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
