Author: mumumu Date: Sun Nov 2 09:15:17 2008 New Revision: 1551 Log: - translated "Documentation and Usability" section.
Modified: trunk/ja/ch05.xml Modified: trunk/ja/ch05.xml ============================================================================== --- trunk/ja/ch05.xml (original) +++ trunk/ja/ch05.xml Sun Nov 2 09:15:17 2008 @@ -2016,15 +2016,27 @@ <!-- ======================== subsection =========================== --> <sect2 id="subsidize-documentation-usability"> +<!-- <title>Documentation and Usability</title> +--> +<title>ドキュメントやユーザビリティの改善</title> +<!-- <para>Documentation and usability are both famous weak spots in open source projects, although I think, at least in the case of documentation, that the difference between free and proprietary software is frequently exaggerated. Nevertheless, it is empirically true that much open source software lacks first-class documentation and usability research.</para> +--> + +<para> + ドキュメントとユーザビリティは、両方ともオープンソースプロジェクトの弱点として有名ですが、 + 私は少なくともドキュメントについては、プロプラエタリなソフトウェアとの違いが誇張されていると思っています。 + とは言っても経験上は、素晴らしいドキュメントやユーザビリティ調査が多くのオープンソースプロジェクトに欠けているのは事実です。 +</para> +<!-- <para>If your organization wants to help fill these gaps for a project, probably the best thing it can do is hire people who are <emphasis>not</emphasis> regular developers on the project, but @@ -2034,17 +2046,46 @@ closest to the software are usually the wrong people to write documentation or investigate usability anyway, because they have trouble seeing the software from an outsider's point of view.</para> +--> + +<para> + あなたの組織がプロジェクトにあるこれらの穴を埋めたいのなら、 + プロジェクトの開発者では<emphasis>なく</emphasis>、 + 彼らと建設的に話ができる人を雇うとよいでしょう。 + プロジェクトの開発者を雇わない方がよい理由はふたつあります。 + ひとつは、プロジェクトから離れてしまうと開発する時間がとれなくなること。 + もうひとつは、対象となるソフトウェアにあまりにも距離が近い人は、 + 第3者の視点からそれを眺めるのが難しいために、 + ドキュメントを書いたりユーザビリティを調べるのに普通向いていないからです。 +</para> +<!-- <para>However, it will still be necessary for whoever works on these problems to communicate with the developers. Find people who are technical enough to talk to the coding team, but not so expert in the software that they can't empathize with regular users anymore.</para> +--> +<para> + しかしながら、開発者と話をしながらこれらの問題に取り組んでくれる人は必要です。 + 彼らと話せるだけの技術スキルがあるものの、対象となるソフトウェアに精通しておらず、 + 普通のユーザーに感情移入できる人を探しましょう。 +</para> + +<!-- <para>A medium-level user is probably the right person to write good documentation. In fact, after the first edition of this book was published, I received the following email from an open source developer named Dirk Reiners:</para> +--> +<para> + 中級者レベルのユーザが、ドキュメントを書くのに多分向いているでしょう。 + 実際、この本の第1版が世に出たあと、 + 私は Dirk Reiner というオープンソースソフトウェアの開発者から次のようなメールを受け取っています。 +</para> + +<!-- <screen> One comment on Money::Documentation and Usability: when we had some money to spend and decided that a beginner's tutorial was the most @@ -2060,6 +2101,27 @@ many people, which is something that was just a lucky occurrence and is probably hard to get in most cases. </screen> +--> + + + +<screen> + 「5.カネに関する問題」の「ドキュメントやユーザビリティの改善」についてひと言。 + もし人に支払えるだけのお金があって、 + もっとも必要となっているのが初心者向けのチュートリアルだという話になった場合、 + 私が実際に雇ったのは中級者レベルのユーザーだった。 + 彼はシステムに関する研修を最近受けたので、 + 何が問題になるのかを覚えているし、問題を乗り越えてきているので、 + どう人に説明すればいいかを分かっていた。 + このため、彼が書いたドキュメントは、彼自身が理解できなかった部分については、 + 開発者がちょっと修正すればよかったし、 + 開発者が「自明な」ものとして見逃していた部分も網羅できていた。 + + もっとも、彼の仕事は多くの人(生徒)にシステムを紹介することだったので、 + 彼は自分が教えた人達の経験、つまりほとんどの人が理解できなかったことや、 + たまたまうまくできたこと、をうまく組み合わせることができた。 + よって、彼が書いたドキュメントはさらに素晴らしいものになっていた。 +</screen> </sect2> _______________________________________________ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
