translate 「2-Intermediate」 to Japanease

jp/2-Intermediate/Judgment/01-How to Tradeoff Quality Against Development Time.md

@@ -1,13 +1,13 @@
 # How to Tradeoff Quality Against Development Time
 [//]: # (Version:1.0.0)
-Software development is always a compromise between what the project does and getting the project done. But you may be asked to tradeoff quality to speed the deployment of a project in a way that offends your engineering or business sensibilities. For example, you may be asked to do something that is a poor software engineering practice and that will lead to a lot of maintenance problems.
+ソフトウェア開発は、プロジェクトが行うこととプロジェクトを完了させることの間で常に妥協です。しかし、エンジニアリングやビジネスの感性を傷つけるような方法でプロジェクトの展開をスピードアップするために、品質をトレードオフするように求められることがあります。たとえば、ソフトウェアエンジニアリングの慣行が貧弱で、メンテナンスの問題が多く発生するような作業をするように求められる場合があります。
 
-If this happens your first responsibility is to inform your team and to clearly explain the cost of the decrease in quality. After all, your understanding of it should be much better than your boss's understanding. Make it clear what is being lost and what is being gained, and at what cost the lost ground will be regained in the next cycle. In this, the visibility provided by a good project plan should be helpful. If the quality tradeoff affects the quality assurance effort, point that out (both to your boss and quality assurance people). If the quality tradeoff will lead to more bugs being reported after the quality assurance period, point that out.
+これが起きた場合は、まずチームに知らせ、品質低下のコストを明確に説明することです。結局のところ、あなたの理解はあなたの上司の理解よりはるかに良いはずです。何が失われているのか、何が得られているのかを明確にし、次のサイクルで失われた地面をどのようなコストで取り戻すのでしょうか。この中で、良いプロジェクト計画が提供する可視性が役立つはずです。品質のトレードオフが品質保証の努力に影響を及ぼす場合は、それを指摘してください（上司と品質保証担当者の両方に）。品質のトレードオフが品質保証期間後に報告されるバグを増やす場合は、それを指摘してください。
 
-If she still insists, you should try to isolate the shoddiness into particular components that you can plan to rewrite or improve in the next cycle. Explain this to your team so that they can plan for it.
+彼女がまだ主張しているなら、次のサイクルで書き直しや改善を計画することができる特定のコンポーネントに不自由さを分離しようとするべきです。これをあなたのチームに説明し、計画を立てることができます。
 
-NinjaProgrammer at Slashdot sent in this gem:
+SlashdotのNinjaProgrammerがこの宝石を送った：
 
-> Remember that a good design will be resilient against poor code implementations. If good interfaces and abstractions exist throughout the code, then the eventual rewrites will be far more painless. If it is hard to write clear code that is hard to fix, consider what is wrong with the core design that is causing this.
+>優れた設計は、貧弱なコード実装に対して回復することを忘れないでください。コード全体で良好なインタフェースと抽象概念が存在する場合、最終的な書き換えははるかに無痛になります。修正が難しい明確なコードを書くのが難しい場合は、これを引き起こしているコアデザインに何が問題なのかを検討してください。
 
 Next [How to Manage Software Dependence](02-How to Manage Software System Dependence.md)

jp/2-Intermediate/Judgment/02-How to Manage Software System Dependence.md

@@ -1,13 +1,13 @@
 # How to Manage Software System Dependence
 [//]: # (Version:1.0.0)
-Modern software systems tend to depend on a large number of components that may not be directly under your control. This increases productivity through synergy and reuse. However, each component brings with it some problems:
+現代のソフトウェアシステムは、あなたのコントロール下に直接存在しないかもしれない多くのコンポーネントに依存する傾向があります。これにより、シナジーと再利用により生産性が向上します。しかし、各コンポーネントにはいくつかの問題があります。
 
-- How will you fix bugs in the component?
-- Does the component restrict you to particular hardware or software systems?
-- What will you do if the component fails completely?
+- コンポーネントのバグをどのように修正しますか？
+- コンポーネントが特定のハードウェアまたはソフトウェアシステムに制限していますか？
+- コンポーネントが完全に失敗したらどうしますか？
 
-It is always best to encapsulate the component in some way so that it is isolated and so that it can be swapped out. If the component proves to be completely unworkable, you may be able to get a different one, but you may have to write your own. Encapsulation is not portability, but it makes porting easier, which is almost as good.
+コンポーネントが何らかの方法でカプセル化され、コンポーネントが分離され、スワップアウトできるようにすることが常にベストです。コンポーネントが完全に機能しないと判明した場合は、別のコンポーネントを手に入れることができますが、独自のコンポーネントを作成する必要があります。カプセル化は移植性ではありませんが、移植が容易になりますが、これはほぼ同じです。
 
-Having the source code for a component decreases the risk by a factor of four. With source code, you can evaluate it easier, debug it easier, find workarounds easier, and make fixes easier. If you make fixes, you should give them to the owner of the component and get the fixes incorporated into an official release; otherwise you will uncomfortably have to maintain an unofficial version.
+コンポーネントのソースコードを持つことは、リスクを4倍に減少させます。ソースコードを使用すると、より簡単に評価し、簡単にデバッグし、回避策を見つけやすくなり、修正を簡単に行うことができます。修正プログラムを作成する場合は、コンポーネントの所有者に修正プログラムを渡し、修正プログラムを公式リリースに組み込む必要があります。それ以外の場合は、非公式のバージョンを維持する必要があります。
 
 Next [How to Decide if Software is Too Immature](03-How to Decide if Software is Too Immature.md)

jp/2-Intermediate/Judgment/03-How to Decide if Software is Too Immature.md

@@ -1,18 +1,18 @@
 # How to Decide if Software is Too Immature
 [//]: # (Version:1.0.0)
-Using software other people wrote is one of the most effective ways to quickly build a solid system. It should not be discouraged, but the risks associated with it must be examined. One of the biggest risks is the period of bugginess and near inoperability that is often associated with software before it matures, through usage, into a usable product. Before you consider integrating with a software system, whether created in house or by a third party, it is very important to consider if it is really mature enough to be used. Here are ten questions you should ask yourself about it:
+他の人が書いたソフトウェアを使用することは、堅牢なシステムを迅速に構築する最も効果的な方法の1つです。それは落胆すべきではありませんが、それに伴うリスクを検討しなければなりません。最も大きなリスクの1つは、ソフトウェアが使用可能な製品に成熟する前に、しばしばソフトウェアに関連している、バグと不完全な動作の期間です。ソフトウェアシステムとの統合を検討する前に、社内で作成されたものであろうと第三者によって作成されたものであろうと、実際に使用するには十分に成熟しているかどうかを検討することが非常に重要です。ここであなた自身に尋ねるべき10の質問があります：
 
-1. Is it vapour? (Promises are very immature).
-2. Is there an accessible body of lore about the software?
-3. Are you the first user?
-4. Is there a strong incentive for continuation?
-5. Has it had a maintenance effort?
-6. Will it survive defection of the current maintainers?
-7. Is there a seasoned alternative at least half as good?
-8. Is it known to your tribe or company?
-9. Is it desirable to your tribe or company?
-10. Can you hire people to work on it even if it is bad?
+1.蒸気ですか？ （約束は非常に未成熟です）。
+2.ソフトウェアに関する知識のあるアクセス可能な本体がありますか？
+3.あなたは最初のユーザーですか？
+4.継続に強いインセンティブはありますか？
+5.メンテナンスに努力していましたか？
+6.それは現在のメンテナの崩壊から生き残ることができますか？
+7.少なくとも半分の味付けの代替品がありますか？
+あなたの部族や会社にそれは知られていますか？
+あなたの部族や会社には望ましいのですか？
+10.あなたが悪い場合でもそれに取り組む人々を雇うことができますか？
 
-A little consideration of these criteria demonstrates the great value of well-established free software and open-source software in reducing risk to the entrepreneur.
+これらの基準を少し考慮すれば、起業家のリスクを削減するための十分に確立されたフリーソフトウェアとオープンソースソフトウェアの大きな価値が証明されます。
 
 Next [How to Make a Buy vs. Build Decision](04-How to Make a Buy vs Build Decision.md)

jp/2-Intermediate/Judgment/04-How to Make a Buy vs Build Decision.md

@@ -1,16 +1,16 @@
 # How to Make a Buy vs. Build Decision
 [//]: # (Version:1.0.0)
-An entrepreneurial company or project that is trying to accomplish something with software has to constantly make so-called *buy vs. build* decisions. This turn of phrase is unfortunate in two ways: it seems to ignore open-source and free software which is not necessarily *bought*. Even more importantly, it should perhaps be called an *obtain and integrate vs. build here and integrate* decision because the cost of integration must be considered. This requires a great combination of business, management, and engineering savvy.
+ソフトウェアを使って何かを達成しようとしている起業家の企業やプロジェクトは、常に「購入」対「決定」の決定をしなければなりません。このフレーズのターンは、2つの点で不幸である。オープンソースと、必ずしも*買っていないフリーソフトウェアを無視しているようだ。さらに重要なのは、統合コストを考慮する必要があるため、ここで取得して統合するか、ここで構築して決定するかを統合することです。これには、ビジネス、管理、エンジニアリングに精通した人材が必要です。
 
-- How well do your needs match those for which it was designed?
-- What portion of what you buy will you need?
-- What is the cost of evaluating the integration?
-- What is the cost of integration?
-- Will buying increase or decrease long term maintenance costs?
-- Will building it put you in a business position you don't want to be in?
+- あなたのニーズは、それが設計されたものとどれくらいよく合っていますか？
+- あなたが購入するもののうち、どの部分が必要ですか？
+- 統合を評価するコストはいくらですか？
+- 統合のコストはいくらですか？
+- 購入は長期的な維持費を増減させるだろうか？
+- それを構築することで、あなたが望んでいないビジネスポジションにあなたを置くことはできますか？
 
-You should think twice before building something that is big enough to serve as the basis for an entire other business. Such ideas are often proposed by bright and optimistic people that will have a lot to contribute to your team. If their idea is compelling, you may wish to change your business plan; but do not invest in a solution bigger than your own business without conscious thought.
+あなたは、他のビジネス全体の基礎となるほど大きなものを構築する前に、二度考えなければなりません。そのようなアイデアは、あなたのチームに貢献することがたくさんある明るく楽観的な人々によって提案されることがよくあります。彼らのアイデアが魅力的であれば、ビジネスプランを変更したいかもしれません。意識がなくても自分のビジネスよりも大きなソリューションに投資しないでください。
 
-After considering these questions, you should perhaps prepare two draft project plans, one for building and one for buying. This will force you to consider the integration costs. You should also consider the long term maintenance costs of both solutions. To estimate the integration costs, you will have to do a thorough evaluation of the software before you buy it. If you can't evaluate it, you will assume an unreasonable risk in buying it and you should decide against buying that particular product. If there are several buy decisions under consideration, some energy will have to be spent evaluating each.
+これらの質問を検討した後、おそらく建築用と購入用の2つのプロジェクト計画案を準備する必要があります。これにより、統合コストを考慮する必要があります。また、両方のソリューションの長期的なメンテナンスコストも考慮する必要があります。統合コストを見積もるには、ソフトウェアを購入する前に完全な評価を行う必要があります。あなたがそれを評価することができない場合、あなたはそれを購入する際に不合理なリスクを想定し、その特定の製品を購入することを決定する必要があります。考慮中の購入決定がいくつかある場合、それぞれを評価するためにいくつかのエネルギーを費やす必要があります。
 
 Next [How to Grow Professionally](05-How to Grow Professionally.md)

jp/2-Intermediate/Judgment/05-How to Grow Professionally.md

@@ -1,11 +1,11 @@
 # How to Grow Professionally
 [//]: # (Version:1.0.0)
-Assume responsibility in excess of your authority. Play the role that you desire. Express appreciation for people's contribution to the success of the larger organization, as well as things as that help you personally.
+あなたの権限を超えた責任を負います。 あなたが望む役割を果たしてください。 大規模な組織の成功への人々の貢献、そしてあなたが個人的に役立つものへの感謝を表明してください。
 
-If you want to become a team leader, instigate the formation of consensus. If you want to become a manager, take responsibility for the schedule. You can usually do this comfortably while working with a leader or a manager, since this frees them up to take greater responsibility. If that is too much to try, do it a little at a time.
+あなたがチームリーダーになりたいなら、コンセンサスの形成を促す。 マネージャーになりたい場合は、スケジュールを担当してください。 リーダーやマネージャーと一緒に仕事をしている間は、通常これを快適に行うことができます。これにより、リーダーやマネージャーがより大きな責任を負うことになります。 それが試しすぎるなら、一度に少ししてください。
 
-Evaluate yourself. If you want to become a better programmer, ask someone you admire how you can become like them. You can also ask your boss, who will know less but have a greater impact on your career.
+あなた自身を評価してください。 あなたがより良いプログラマになりたいなら、あなたがどのようにそれらのようになることができるか賞賛する人に尋ねなさい。 上司に聞くこともできます。上司には知っていますが、あなたのキャリアに大きな影響を与えます。
 
-Plan ways to learn new skills, both the trivial technical kind, like learning a new software system, and the hard social kind, like writing well, by integrating them into your work.
+新しいソフトウェアシステムを学ぶことのような、些細な技術的なものでも、あなたの仕事にそれらを統合することによって、うまく書くようなハードな社会的なものでも、新しいスキルを学ぶ方法を計画する。
 
 Next [How to Evaluate Interviewees](06-How to Evaluate Interviewees.md)

jp/2-Intermediate/Judgment/06-How to Evaluate Interviewees.md

@@ -1,15 +1,15 @@
 # How to Evaluate Interviewees
 [//]: # (Version:1.0.0)
-Evaluating potential employees is not given the energy it deserves. A bad hire, like a bad marriage, is terrible. A significant portion of everyone's energy should be devoted to recruitment, though this is rarely done.
+潜在的な従業員を評価することは、それにふさわしいエネルギーが与えられていない。悪い結婚のような悪い雇用はひどいです。みんなのエネルギーのかなりの部分は募集に費やされるべきですが、これはめったに行われません。
 
-There are different interviewing styles. Some are torturous, designed to put the candidate under a great deal of stress. This serves a very valuable purpose of possibly revealing character flaws and weaknesses under stress. Candidates are no more honest with interviewers than they are with themselves, and the human capacity for self-deception is astonishing.
+インタビュースタイルはさまざまです。候補者の中には非常にストレスを感じるように設計された拷問家もいます。これはストレス下でのキャラクターの欠陥や弱点を明らかにする非常に貴重な目的を果たします。候補者は自分自身と比べてインタビュアーには正直ではなく、自己欺瞞に対する人間の能力は驚くべきものです。
 
-You should, at a minimum, give the candidate the equivalent of an oral examination on the technical skills for two hours. With practice, you will be able to quickly cover what they know and quickly retract from what they don't know to mark out the boundary. Interviewees will respect this. I have several times heard interviewees say that the quality of the examination was one of their motivations for choosing a company. Good people want to be hired for their skills, not where they worked last or what school they went to or some other inessential characteristic.
+あなたは少なくとも、2時間の技術スキルの口頭試験に相当するものを候補者に与えるべきです。練習では、自分が知っていることをすばやくカバーし、境界線をマークするために知らないものからすばやく取り戻すことができます。面接者はこれを尊重するでしょう。私は、インタビューで、試験の質は企業を選ぶ動機の1つであると数回聞いたことがあります。善良な人たちは、彼らが最後に働いた場所や彼らが行った学校、または他の不可欠な特徴ではなく、彼らのスキルのために雇われたいと思っています。
 
-In doing this, you should also evaluate their ability to learn, which is far more important than what they know. You should also watch for the whiff of brimstone that is given off by difficult people. You may be able to recognize it by comparing notes after the interview, but in the heat of the interview it is hard to recognize. How well people communicate and work with people is more important than being up on the latest programming language.
+これを行うにあたっては、自分が知っているよりもはるかに重要な、学習する能力も評価する必要があります。また、困難な人たちによって払われた有害物質の欲求を監視する必要があります。あなたはインタビューの後でノートを比較することによってそれを認識することができるかもしれませんが、インタビューの熱でそれを認識することは困難です。最新のプログラミング言語を上回るよりも、人々がコミュニケーションをして人々とどのくらいうまくやっていくかが重要です。
 
-A reader has had good luck using a ‘take-home’ test for interviewees. This has the advantage that it can uncover the interviewee that can present themselves well but can't really code - and there are many such people. I personally have not tried this technique, but it sounds sensible.
+読者はインタビュー対象者のためにテイク・ホーム・テストを使って幸運を祈っています。これは、自分自身をうまく提示することができますが、実際にはコード化することができないインタビュイーを明らかにすることができるという利点があります。私は個人的にはこのテクニックを試していませんが、それは賢明なようです。
 
-Finally, interviewing is also a process of selling. You should be selling your company or project to the candidate. However, you are talking to a programmer, so don't try to colour the truth. Start off with the bad stuff, then finish strong with the good stuff.
+最後に、インタビューは販売のプロセスでもあります。候補者にあなたの会社やプロジェクトを売っているはずです。しかし、あなたはプログラマと話しているので、真実を色づけしようとしないでください。悪いものから始めて、次に良いもので強く仕上げてください。
 
 Next [How to Know When to Apply Fancy Computer Science](07-How to Know When to Apply Fancy Computer Science.md)