Skip to content

Commit 1dbdd84

Browse files
committed
translate 「3-Advanced」to Japanease
1 parent 909def5 commit 1dbdd84

17 files changed

+82
-82
lines changed
Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -1,11 +1,11 @@
11
# How to Fight Schedule Pressure
22
[//]: # (Version:1.0.0)
3-
Time-to-market pressure is the pressure to deliver a good product quickly. It is good because it reflects a financial reality, and is healthy up to a point. Schedule pressure is the pressure to deliver something faster than it can be delivered and it is wasteful, unhealthy, and all too common.
3+
製品化までの時間の短縮は、すぐれた製品を迅速に提供するというプレッシャーです。それは財政的現実を反映しており、ある時点まで健全なので良いです。スケジュール圧力は、送達可能な速度よりも速く送達する圧力であり、無駄であり、不健全であり、あまりにも一般的である。
44

5-
Schedule pressure exists for several reasons. The people who task programmers do not fully appreciate what a strong work ethic we have and how much fun it is to be a programmer. Perhaps because they project their own behaviour onto us, they believe that asking for it sooner will make us work harder to get it there sooner. This is probably actually true, but the effect is very small, and the damage is very great. Additionally, they have no visibility into what it really takes to produce software. Not being able to see it, and not be able to create it themselves, the only thing they can do is see time-to-market pressure and fuss at programmers about it.
5+
スケジュール圧力はいくつかの理由で存在します。プログラマーを務める人たちは、私たちが持っている強い仕事倫理とプログラマーになることがどれほど楽しいかを十分に理解していません。おそらく、彼らは自分たちの行動を私たちに投影するので、早くそれを求めることは、私たちがより早くそこに到達するようにもっと働くようになると信じています。これはおそらく実際には当てはまりますが、効果は非常に小さく、損傷は非常に大きいです。さらに、彼らは実際にソフトウェアを作るために必要なものについては見えません。それを見ることができず、それ自体を作成することができないということは、彼らができる唯一のことは、市場投入までの時間の圧迫とそれに関するプログラマーの騒ぎである。
66

7-
The key to fighting schedule pressure is simply to turn it into time-to-market pressure. The way to do this to give visibility into the relationship between the available labour and the product. Producing an honest, detailed, and most of all, understandable estimate of all the labour involved is the best way to do this. It has the added advantage of allowing good management decisions to be made about possible functionality trade-offs.
7+
スケジュールの圧力と戦うための鍵は、それをタイム・トゥ・マーケットの圧力に変えることです。利用可能な労働と製品との関係を可視化するための方法。正直で、詳細な、そして最も重要なものを作り出すことは、これを行うための最善の方法です。これには、可能性のある機能のトレードオフについての適切な管理上の決定を可能にするという追加の利点があります。
88

9-
The key insight that the estimate must make plain is that labour is an almost incompressible fluid. You can't pack more into a span of time anymore than you can pack more water into a container over and above that container's volume. In a sense, a programmer should never say ‘no’, but rather to say ‘What will you give up to get that thing you want?’ The effect of producing clear estimates will be to increase the respect for programmers. This is how other professionals behave. Programmers' hard work will be visible. Setting an unrealistic schedule will also be painfully obvious to everyone. Programmers cannot be hoodwinked. It is disrespectful and demoralizing to ask them to do something unrealistic. Extreme Programming amplifies this and builds a process around it; I hope that every reader will be lucky enough to use it.
9+
見積もりが明白にしなければならない重要な洞察は、労働はほぼ非圧縮性の液体であるということです。コンテナの容積以上のコンテナにもっと多くの水を入れることができます。ある意味では、プログラマーは「絶対」と言ってはいけませんが、「帽子はあなたが望むことを諦めるでしょうか?」という明確な見積もりを出すのは、プログラマーにとっての敬意を高めることになります。これは他の専門家の行動です。プログラマーの労力が見えるでしょう。非現実的なスケジュールを設定することは、誰にとっても痛感することです。プログラマはうんざりすることはできません。彼らに非現実的なことをするのは無礼なことです。 Extreme Programmingはこれを増幅し、その周りにプロセスを構築します。私は、すべての読者がそれを使用するのに十分なほど幸運になることを願っています。
1010

1111
Next [How to Understand the User](02-How to Understand the User.md)
Lines changed: 8 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -1,17 +1,17 @@
11
# How to Understand the User
22
[//]: # (Version:1.0.0)
3-
It is your duty to understand the user, and to help your boss understand the user. Because the user is not as intimately involved in the creation of your product as you are, they behave a little differently:
3+
ユーザーを理解し、上司にユーザーを理解させるのはあなたの義務です。ユーザーは自分の製品の作成に密接に関わっていないため、少し違った動作をします。
44

5-
- The user generally makes short pronouncements.
6-
- The user has their own job; they will mainly think of small improvements in your product, not big improvements.
7-
- The user can't have a vision that represents the complete body of your product users.
5+
- ユーザーは、一般的に短い発言をします。
6+
- ユーザーは自分の仕事を持っています。彼らは主に、大きな改善ではなく、あなたの製品の小さな改善を考えるでしょう。
7+
- ユーザーは、製品ユーザーの全身を表すビジョンを持つことはできません。
88

9-
It is your duty to give them what they really want, not what they say they want. It is however, better to propose it to them and get them to agree that your proposal is what they really want before you begin, but they may not have the vision to do this. Your confidence in your own ideas about this should vary. You must guard against both arrogance and false modesty in terms of knowing what the customer really wants. Programmers are trained to design and create. Market researchers are trained to figure out what people want. These two kinds of people, or two modes of thought in the same person, working harmoniously together give the best chance of formulating the correct vision.
9+
彼らが本当に欲しいものを与えるのはあなたの義務であり、彼らが望むと言っているものではありません。しかし、それを彼らに提案し、あなたの提案があなたが始める前に本当に望むものであることに同意させるのが良いですが、そうするビジョンはないかもしれません。これに関するあなた自身のアイデアに対するあなたの信頼は変わるはずです。顧客が本当に望んでいることを知るという観点からは、傲慢さと誤った謙虚さの両方を守る必要があります。プログラマーは設計と作成を訓練しています。市場の研究者は、人々が望むものを理解するように訓練されています。この2つの種類の人、または同じ人の2つの考え方が調和して一緒に働いて、正しいビジョンを策定する最良の機会を与えます。
1010

11-
The more time you spend with users the better you will be able to understand what will really be successful. You should try to test your ideas against them as much as you can. You should eat and drink with them if you can.
11+
ユーザーと一緒に過ごす時間が長くなればなるほど、実際に何が成功するかを理解できるようになります。できるだけそれらに対してあなたのアイデアを試そうとするべきです。あなたができるなら食べて飲むべきです。
1212

13-
Guy Kawasaki [Rules] has emphasized the importance of *watching* what your users do in addition to listening to them.
13+
Guy Kawasaki [Rules]は、ユーザーが聞くことに加えて、ユーザーの行動を監視することの重要性を強調しています。
1414

15-
I believe contractors and consultants often have tremendous problems getting their clients to clarify in their own minds what they really want. If you intend to be a consultant, I suggest you choose your clients based on their clear-headedness as well as their pocketbooks.
15+
私は請負業者やコンサルタントが、しばしば彼らが本当に望むものを自らの心の中で明確にするように顧客に訴える大きな問題を抱えていると信じています。あなたがコンサルタントになろうと思っているなら、私はあなたのクライアントを、彼らの明確な頭の中だけでなく、彼らの手帳に基づいて選ぶことをお勧めします。
1616

1717
Next [How to Get a Promotion](03-How to Get a Promotion.md)
Lines changed: 5 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -1,13 +1,13 @@
11
# How to Get a Promotion
22
[//]: # (Version:1.0.0)
3-
To be promoted to a role, act out that role first.
3+
役割に昇進させるには、まずその役割を実行します。
44

5-
To get promoted to a title, find out what is expected of that title and do that.
5+
タイトルに昇格させるには、そのタイトルに何が期待されているかを見つけ出してください。
66

7-
To get a pay raise, negotiate armed with information.
7+
賃上げを得るには、情報で武装して交渉する。
88

9-
If you feel like you are past due for a promotion, talk to your boss about it. Ask them explicitly what you need to do to get promoted, and try to do it. This sounds trite, but often times your perception of what you need to do will differ considerably from your boss's. Also this will pin your boss down in some ways.
9+
あなたがプロモーションの期限が過ぎているように感じたら、あなたの上司に話してください。昇進させるために何をする必要があるのか??を明示的に尋ねて、それをやろうとします。これは馬鹿げていますが、しばしばあなたがする必要があることに対するあなたの認識は、あなたの上司とはかなり異なるでしょう。また、これはいくつかの点であなたの上司をピン止めします。
1010

11-
Most programmers probably have an exaggerated sense of their relative abilities in some ways---after all, we can't all be in the top 10%! However, I have seen some people who were seriously unappreciated. One cannot expect everyone's evaluation to perfectly match reality at all times, but I think people are generally moderately fair, with one caveat: you cannot be appreciated without visibility into your work. Sometimes, due to happenstance or personal habits, someone will not be noticed much. Working from home a lot or being geographically separated from your team and boss makes this especially difficult.
11+
ほとんどのプログラマは、おそらく何らかの形で相対的な能力の誇張された感覚を持っているでしょう。結局のところ、すべてがトップ10%に入るわけではありません!しかし、私は真剣に評価されていない人々を見てきました。みんなの評価が常に現実に完全にマッチするとは思っていませんが、私は人々が概して適度に公正であると考えています。あなたの仕事に目を向けることなく評価することはできません。ときには、偶然や個人的な習慣のために、誰かに気付かれないことがあります。自宅から多くの仕事をしたり、チームや上司から地理的に離れていると、これは特に困難になります。
1212

1313
Next [Serving Your Team - How to Develop Talent](../Serving-Your-Team/01-How to Develop Talent.md)
Lines changed: 10 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -1,23 +1,23 @@
11
# How to Develop Talent
22

3-
Nietschze exaggerated when he said [Stronger]:
3+
Nietschzeは彼が[Stronger]と言ったときに誇張した:
44

5-
> What does not destroy me, makes me stronger.
5+
>私を破壊しないものは、私をより強くします。
66
7-
Your greatest responsibility is to your team. You should know each of them well. You should stretch your team, but not overburden them. You should usually talk to them about the way they are being stretched. If they buy in to it, they will be well motivated. On each project, or every other project, try to stretch them in both a way that they suggest and a way that you think will be good for them. Stretch them not by giving them more work, but by giving them a new skill or better yet a new role to play on the team.
7+
あなたの最大の責任はあなたのチームです。あなたはそれぞれのことをよく知っているはずです。あなたはあなたのチームを引き伸ばすべきですが、彼らに負担をかけるべきではありません。あなたは通常、彼らが伸びている方法について話すべきです。彼らがそれを買収すれば、彼らはうまく動機づけられます。各プロジェクト、または他のすべてのプロジェクトで、提案する方法とそれに適した方法でストレッチを行います。より多くの仕事を与えることではなく、彼らに新しいスキルを与えたり、チームで新しい役割を果たしたりすることによって、彼らを伸ばす。
88

9-
You should allow people (including yourself) to fail occasionally and should plan for some failure in your schedule. If there is never any failure, there can be no sense of adventure. If there are not occasional failures, you are not trying hard enough. When someone fails, you should be as gentle as you can with them while not treating them as though they had succeeded.
9+
あなた自身(あなた自身を含む)が時々失敗するようにして、あなたのスケジュールで何らかの失敗を計画するべきです。決して失敗がなければ、冒険感はありません。時々失敗することがなければ、あなたは十分に頑張っているわけではありません。誰かが失敗すると、成功したかのように扱わずに、できるだけ穏やかにするべきです。
1010

11-
Try to get each team member to buy in and be well motivated. Ask each of them explicitly what they need to be well-motivated if they are not. You may have to leave them dissatisfied, but you should know what everybody desires.
11+
各チームのメンバーが購入し、動機付けされているようにしてください。そうでない場合は、彼らがうまく動機づけられている必要があることを明確にそれぞれ質問してください。あなたはそれを不満のままにしなければならないかもしれませんが、みんなが望むものを知っておくべきです。
1212

13-
You can't give up on someone who is intentionally not carrying their share of the load because of low morale or dissatisfaction and just let them be slack. You must try to get them well-motivated and productive. As long as you have the patience, keep this up. When your patience is exhausted, fire them. You cannot allow someone who is intentionally working below their level to remain on the team, since it is not fair to the team.
13+
低い士気や不満のために負荷を分担していない人をあきらめることはできません。あなたはそれらをうまく動機づけて生産的にするように努めなければなりません。あなたが忍耐力を持っている限り、これを維持してください。あなたの忍耐が疲れたら、それらを撃ってください。意図的にレベルを下回って作業している人は、チームにとって公平ではないため、チームに残り続けることはできません。
1414

15-
Make it clear to the strong members of your team that you think they are strong by saying so in public. Praise should be public and criticism private.
15+
あなたのチームの強固なメンバーに、彼らを強く信じていることを、公に話すことで明確にします。賛美は公然と批判プライベートにする必要があります。
1616

17-
The strong members of the team will naturally have more difficult tasks than the weak members of the team. This is perfectly natural and nobody will be bothered by it as long as everyone works hard.
17+
チームの強いメンバーは、当然、チームの弱いメンバーよりも難しい仕事をするでしょう。これは完全に自然なことであり、誰もが一生懸命働く限り、誰もそれによって邪魔されることはありません。
1818

19-
It is an odd fact that is not reflected in salaries that a good programmer is more productive than 10 bad programmers. This creates a strange situation. It will often be true that you could move faster if your weak programmers would just get out of the way. If you did this you would in fact make more progress in the short term. However, your tribe would lose some important benefits, namely the training of the weaker members, the spreading of tribal knowledge, and the ability to recover from the loss of the strong members. The strong must be gentle in this regard and consider the issue from all angles.
19+
良いプログラマが10人の悪いプログラマよりも生産性が高いのは、給料に反映されないという奇妙な事実です。これは奇妙な状況を作り出します。あなたの弱いプログラマがちょっと邪魔になる場合は、あなたがより速く動くことができることはしばしば真実です。あなたがこれをした場合、あなたは実際に短期間でもっと進歩を遂げるでしょう。しかし、あなたの部族は、弱いメンバーの訓練、部族の知識の普及、そして強力なメンバーの喪失から回復する能力という、いくつかの重要な利点を失います。この点で強くなければならず、問題はあらゆる角度から考えなければなりません。
2020

21-
You can often give the stronger team members challenging, but carefully delineated, tasks.
21+
あなたはしばしば、より強いチームメンバーに挑戦的ですが、注意深く描かれたタスクを与えることができます。
2222

2323
Next [How to Choose What to Work On](02-How to Choose What to Work On.md)
Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,5 @@
11
# How to Choose What to Work On
22

3-
You balance your personal needs against the needs of the team in choosing what aspect of a project to work on. You should do what you are best at, but try to find a way to stretch yourself not by taking on more work but by exercising a new skill. Leadership and communication skills are more important than technical skills. If you are very strong, take on the hardest or riskiest task, and do it as early as possible in the project to decrease risk.
3+
自分のニーズとチームのニーズとのバランスを取って、どのような側面のプロジェクトを作業するかを選択します。 あなたは自分が一番好きなことをしなければなりませんが、より多くの仕事をするのではなく、新しいスキルを行使して自分自身を伸ばす方法を見つけようとします。 リーダーシップとコミュニケーションスキルは技術スキルよりも重要です。 あなたが非常に強ければ、プロジェクトでは、リスクを減らすために、できるだけ早く、最も困難な、またはリスクの高いタスクを実行してください。
44

55
Next [How to Get the Most From Your Team-mates](03-How to Get the Most From Your Teammates.md)

0 commit comments

Comments
 (0)