Changed some translations (#517)

Author: yuhattor

introduction/ja/02-problems-solved-ja.asciidoc

@@ -22,15 +22,15 @@ InnerSourceは、企業の組織構造やその立場に関係なく、誰もが
  .. 利用側のチームで行った成果は、同じ機能を必要としている他の利用者に提供されなくなる。
  .. 利用側のチームは、自分たちのチームの主要な役割の範疇にはない、新しいコードを長期的にメンテナンスするという負担を意図せずに背負い込んでしまいました。
  .. 会社全体として、同じ課題に対する重複したプロジェクトとコードを取得していしまいました。
-. *エスカレート：* 利用側のチームは、「No」という答えを受け入れずに、代わりに提供側のマネージメント層に影響（や強制）を与えるように働きかけます。
+. *エスカレーション：* 利用側のチームは、「No」という答えを受け入れずに、代わりに提供側のマネージメント層に影響（や強制）を与えるように働きかけます。
 このオプションは、利用側のチームにとっては、彼らが何も開発したりメンテナンスしたりせずに要求する機能を手に入れることができるため、魅力的に思えます。
 しかし、それは利用側のチームにとって結局足を引っ張ることになります。なぜなら、エスカレーションという開発に関係のない作業に注力しなければならないからです。
 加えて、このオプションは、何度も使えるものでもなくスケールしません。度重なるエスカレーションは、利用する側の信頼を損なうことに繋がるからです。
 エスカレーションは、提供側のチームにも同様（もしくはそれ以上）に混乱をもたらします。なぜなら、エスカレーションされた機能の処理を、通常のワークフローや優先度付けの方法の範囲外で行わなければならないからです。
 
 この議論は、InnerSourceのための準備となります。
 InnerSourceは、利用側のチームが機能要求を通して必要なものが得られない、似たような状況に適用されます。
-InnerSourceは、 _静観_ 、 _回避策_ 、_エスカレート_ の効果を関連する欠点なしに得るための方法を提供します。
+InnerSourceは、 _静観_ 、 _回避策_ 、_エスカレーション_ に関連する欠点がない効果を得るための方法を提供します。
 
 また、InnerSourceはエンジニア同士が新しいさまざまな技術やバラエティに富んだ人々と一緒に仕事をする機会を与えることで、エンジニアの開発文化を改善します。
 開発者は、組織的なサイロを横断してアイデアや解決法を共有しながら、互いに指導したり学んだりできます。