Index: [Article Count Order] [Thread]

Date:  Tue, 27 Mar 2001 19:00:58 +0900
From:  Yutaka Kamite <y-kamite@....jp>
Subject:  [XP-jp:01772] Re: Chapter3 [1]
To:  XP-ML <extremeprogramming-jp@....jp>
Message-Id:  <20010327185906.5ED4.Y-KAMITE@....jp>
X-Mail-Count: 01772


上手です。
communicate について前から気になっていたのでコメントさせて下さい。

On Wed, 21 Mar 2001 12:54:14 +0900 (JST)
Yuji Yamano <u90156@....jp> wrote:

> こんにちは。
> 
> まだコメントしていませんでした。
> 
> > Programmers, we all know, will program anything. The trick is to
> > tell them what's needed. In general, what's needed is called
> > "requirements," probably to make it sound more important. In XP, we
> > communicate what's needed using User Stories (page 23). User
> > stories, written on cards, are the core of the XP planning process
> > (see Chapters 8 and 9), and they belong to the people with the
> > requirements. We call these people the Customer-and we ask them to
> > be with the project all the time. Before you read about creating
> > user stories, here's why we want you to show up.
> 
> > 当たり前のことだが、プログラマは何だってプログラムするだろう。コツは、
> > プログラマに何が必要とされているかを伝えることだ。普通、「何が必要と
> > されているか」を“要求”という言葉で呼んでいる。多分いかにも重要らし
> > く聞こえるようにするためなのだろう。XPでは何が必要とされているかを
> > 「ユーザー・ストーリー」(4章)を使って伝えることにしている。ユーザー・

communicate を *伝える* と訳していますが、communicate には
to share or exchange opinions, feelings, information etc (Longman)
という、知識・情報を共有するという意味があります。
ちなみに ISO9001規格の解説(日本科学技術連盟)では、
communicationは「伝えること」だけではなく、「わかりあっている状況をつく
る」ことが目的で、うまい日本語訳がない、と述べています。
訳を検討いただいた方が良いと思います。コミュニケーションと、横文字にする
のも手かと思います。

(では)


> > ストーリーはカードに書かれるのだが、XPのプランニング・プロセス(8章/9
> > 章参照)のコアであり、要求する側の人のものである。私たちはその人たち
> > を顧客と呼び、その人たちにプロジェクトにつきっきりになってくれるよう
> > お願いする。ユーザーストーリーの書き方を読む前に、どうして顧客にオン
> > サイトにいて欲しいのかをお教えしよう。
> 
> 「プログラマに何が必要とされているかを伝えることだ」だと、直後の文章を
> 読むまで、「プログラマーに必要とされるもの」なのか、「必要なものをプロ
> グラマーに伝える」なのか判断できません。「何が必要とされているかを
> プログラマに伝えることだ」のように順番を入れかえるほうが、意図がクリア
> になります。
> 
> 「ユーザー・ストーリーはカードに書かれるのだが、XPのプランニング・プロ
> セス(8章/9章参照)のコアであり、要求する側の人のものである」は、ちょっ
> とわかりにくいです。「カードに書かれたユーザー・ストーリーは、XP の
> プランニング・プロセス(8章/9章参照)の中核となるものであり、顧客によっ
> て書かれます」ではどうでしょうか?
> 
> > A simple story may need backup details that can be provided on
> > paper. But for the programmers to implement the story quickly and
> > well, they need to build up a sense of how it fits in. That sense is
> > provided by the customer, in many discussions, over the course of
> > the project. Here's an example:
> 
> > ごく簡単なストーリーでは、書面にした補足詳細が必要になるかも知れない。
> > しかし、プログラマがストーリーを迅速かつ、うまく実装するにためには、そ
> > のストーリーがシステムにどうはめこまれるのかという感覚を築き上げる必要
> > がある。
> > ★ 19
> > その感覚は、プロジェクトの進行中に何度も話し合いを行うなかで、顧客から
> > 提供されることになる。ひとつ例を挙げておこう。
> 
> 「ごく簡単なストーリー」だと、なぜ「書面にした補足詳細が必要になる」の
> かわかりにくいと思います。ちょっと捕捉して「簡単すぎるストーリー」では
> どうでしょうか?
> 
> # 要求が簡単(大雑把)すぎて、モデルなりコードなりにおとせないという
> # 意味ですよね?
> 
> あと、「感覚」が「提供」されるという表現には違和感があります。
> 代案はないのですけど…
> 
> > Now yes, that same exchange could have been held via e-mail, or
> > written down in a detailed spec. But that would have taken more
> > time, and quite likely wouldn't have completely quelled the
> > programmer's concern the way the conversation did. You might also be
> > concerned that this important information about the requirements
> > will get lost somewhere, but remember that you will have specified
> > acceptance tests, and they will surely cover the two tiers of plant
> > guards.
> 
> > さてここで、これとまったく同じやり取りが電子メールや書類にした詳しい
> > 仕様書でもできていただろう、と思う顧客もいるだろう。そのとおり。しか
> > し、その方が時間がかかっただろうし、この会話がやってのけたように完璧
> > にはプログラマの懸念を鎮めることはできなかっただろう。それから、書類
> > にしないと、要求に関しての重要な情報が忘れ去られてしまうのではないか、
> > という心配もしているかも知れない。しかし、顧客は受け入れテストを書く
> > ことになるのを忘れないで欲しい。受け入れテストは間違いなく、工場警備
> > 員の1種、2種についてカバーするだろう。
> 
> 心配もしているかも知れない -> 心配もしているかもしれない
> 
> あと、「心配もしているかも」だと、「も」が続くのでいまいちです。also 
> は「それから」で表現できていると思うので、「心配をしているかも」で
> 十分ではないでしょうか。
> 
> それから「顧客は受け入れテストを書く」には、「実際には顧客がコードを書
> くわけではない」旨の訳注が必要ではないでしょうか。言いたいことをうまく
> つめこむと、こういう表現になるのは良くわかるのですが、原文は you will
> have specified acceptance tests ですし、顧客が受け入れテストのコードを
> 書けない場合がほとんどでしょう。
> 
> > How important is it to have the customer right there? Here's an
> > example. Ron has been coaching a project whose customers have a
> > private office right in the development area. A couple of times
> > every day, while the programmers are working, one of them will ask a
> > question and no one will know the answer. The programmer generally
> > gets right up and goes to ask Pam, the customer. In a couple of
> > minutes, he's back, shares the answer (because now everyone is
> > curious), and gets back to work.
> 
> > 顧客がすぐそばにいることはどれくらい重要だろうか。ひとつ実例を挙げて
> > おこう。ロンはあるプロジェクトをコーチしていた。そのプロジェクトの顧
> > 客はまさに開発部の中に専用部屋を持っていた。プログラマは作業している
> > 間に、毎日何回かは、誰かが疑問点を見つけ、プログラマ仲間に聞いてみて
> > もだれも答えられない、という状況が起きていた。疑問を持ったプログラマ
> > は普通、すぐに立ち上がり、顧客であるパムに質問をしに行く。2,3分でそ
> > のプログラマは戻ってきて、パムから得た回答をほかのプログラマたちにも
> > 教えてやる。( というのは、その頃にはみんながその答えに興味を持ってし
> > まっているからだ。)そして仕事を再開する。
> 
> development area は programing area と同じ意味ですよね?
> 
> 「プログラマは作業している間に、毎日何回かは、誰かが疑問点を見つけ、プ
> ログラマ仲間に聞いてみてもだれも答えられない、という状況が起きていた。」
> だと、この状況が強調されすぎるような気がします。単に「だれも答えられな
> かった」のほうが良いと思います。
> 
> > One day on Ron's last visit, the customers had to go to another work
> > site for machine access. They told the programmers where they were
> > (two floors down and a few offices over), and left their phone
> > number and beeper number. Sure enough, in the afternoon, someone had
> > one of those questions. But the programmer knew Pam wasn't there. He
> > didn't call her-instead, he guessed about the code and wrote a note
> > to ask her later.
> 
> > 最後にロンがそのプロジェクトに顔を出した日、顧客はマシンアクセスの都
> > 合で別の仕事場に移らなくてはならなくなった。顧客はプログラマに自分た
> > ちの新しい居場所(2フロア下の2つか3つオフィスを奥に行ったところだ)を
> > 告げ、電話とポケベルの番号を置いていった。当然の事ながら、午後になる
> > とさっきのような疑問を持つものが出て来た。しかし、そのプログラマには
> > パムがすぐそばにはいない事がわかっていた。プログラマはパムに電話をし
> > なかった。その代わり、疑問点については憶測し、パムに後で訊こう、とメ
> > モを作っただけだった。
> 
> someone had one of those questions の those を「さっき」と訳すと、時間
> 的な距離を感じます。前の段落をさしているだけなので、「いつものように」
> と訳してはどうでしょうか。
> 
> he guessed about the code は、仕様を憶測しただけなのでしょうか。それと
> も仕様を憶測しコードまで書いたのでしょうか?  後の段落で、How many
> guesses do you want in your code? といってるので後者かなと思ったのです
> が自信がありません。
> 
> > Sometimes you can't afford to have the customer removed from doing
> > real customer-related work. That's fine-Pam and her partner Robin
> > have real jobs, too. They're set up with computer access in the
> > programming area, and one or the other of them is usually there.
> > They mostly do their regular work and answer a few questions. Their
> > answers make the relocation worthwhile.
> 
> > 場合によっては、顧客に本来の仕事を離れさせられない時だってあるだろう。
> > それはそれでいい。パムと、彼女のパートナーであるロビンにも本来の仕事
> > がある。彼女たちは開発チームのフロアの中にコンピュータアクセス環境を
> > 用意されていて、大体どちらか一方がその場所にいる。彼女たちは普段は自
> > 分の本来の作業に従事していて、時たま質問に答えるのだ。彼女たちの回答
> > は「引越してきた価値はあった」と思わせるに足るものなのだ。
> 
> >   Their answers make the relocation worthwhile.
> >    -----------  ====  ------------   --------
> >         S        V         O             C
> > 
> >   ですよね?
> >   彼らの回答があるからこそ、引越しは有意義なものなのだ、ということでは
> >   ないかと思います。
> 
> 高嶋さんの解釈であっていると思いますが、日本語訳のほうは意味がクリアで
> はありません。そのまま、「彼女たちの回答が得られるから、引越しは有意義
> なものなのだ」ではどうでしょうか。
> 
> > First, try hard to get someone to represent the customer
> > locally. This could be a non-programming project manager, a trainer,
> > a tracker, or just someone in the company who is expert in the
> > area. Let them handle the bulk of the interruptions, then get with
> > the real customer off-line to double-check. If the customer and this
> > pseudo-customer can get on the same wavelength, this works quite
> > well.
> 
> > まず最初に、プログラマのもとで顧客の代わりになれそうな人を精一杯探し回
> > ること。この代理は、プログラミングをしないプロジェクトマネジャがするこ
> > とになるかもしれないし、トレーナやトラッカ、あるいは単にその方面に特化
> > している誰かがすることになるかもしれない。行き詰まってしまったら大部分
> > はその代理に処理を任せ、それから本当の顧客に直接あって、再度チェックを
> > させること。本当の顧客と仮顧客が波長をぴったりあわせられれば、この方法
> > はかなり大きな効果を発揮する。
> 
> pseudo-customer は「仮顧客」より「擬似顧客」のほうがしっくりきます。
> 
> > Having your customer with you is really valuable. It's possible to
> > survive without it-many projects do-but you'll go faster and more
> > smoothly by being together. It's the difference between being in the
> > car when it's time to turn or just writing a note that says, "Don't
> > forget to turn at 34th Street." When 34th is blocked and you're in
> > the car, you can tell the driver how to recover. The note can't
> > help.
> 
> > 顧客をすぐそばにいさせることは実に価値のあることだ。そうしなくてもや
> > りぬくことは可能だし、実際多くのプロジェクトがそうしている。しかし、
> > 顧客がそばにいることで進みは速くなり、またスムーズにもなる。それはちょ
> > うど、車に一緒に乗っていてあげて、どの角を曲がったらいいか教えてあげ
> > るのと、「34丁目の角を曲がること」と書いたメモを残してあげるのとの違
> > いに匹敵する。もし、34丁目が閉鎖されていて通れなくても、車の中にいる
> > のだったらどうやったらリカバーできるか教えてあげられる。しかし、メモ
> > はそんなことは教えてやれない。
> 
> ここの recover はカタカナでなく適当な日本語に訳すべきだと思います。
> 「もし、34丁目が閉鎖されていて通れなくても、車の中にいるのだったら
> どうすればいいか教えてあげられる」ぐらいでどうでしょうか。
> 
> -- やまの


--------------------- Original Message Ends --------------------