@@ -1,74 +1,77 @@
 ## Title
 
-サービス vs. ライブラリー
+サービス対ライブラリー
 
 ## Patlet
 
-DevOps環境のチームは、サービスのダウンタイムに誰が対応するのかが曖昧なため、チームの境界を越えて共通のコードベースで作業することに消極的かもしれません。解決策としては、同じサービスを独立した環境で展開し、サービスダウン時のエスカレーションを別々に行うか、多くの共有コードを1つのライブラリにまとめて、その上でコラボレーションすることが可能な場合が多いことを認識することです。
+DevOps環境のチームは、サービスのダウンタイムに対応する責任が誰にあるのかが曖昧になるため、チームの境界を越えて共通のコードベースで作業することに消極的になる場合があります。解決策としては、同じサービスを独立した環境で展開し、サービスダウン時のエスカレーション・チェーンを別々に構築するか、多くの共有コードを1つのライブラリに集約し、その上で共同作業を行うことが挙げられます。
 
 ## 問題
 
-DevOps環境で作業しているチームは、開発者が機能のエンドツーエンドに責任を持ちます。顧客からデプロイメント、メンテナンス、サポートに至るまでです。これは、チームの境界を越えて作業する際に課題となります。エスカレーションチェーンは、どちらのチームでも発生するエラーに対して同じであるとは限りません。ソースコードとデプロイメントを結合すると、エラーが発生した場合に誰がオンコールサポートの責任を負うのかという疑問がチームに残ります。その結果、要件に大きな重複がある場合でも、チームは協力し合うことに消極的になる。
+チームがDevOps環境で作業しているとき、開発者は機能をエンドツーエンドで担当することになります。顧客からデプロイメント、メンテナンス、サポートに至るまでです。このことは、チームの境界を越えて作業する際に課題となります。エスカレーションチェーンは、どちらのチームでも発生するエラーに対して同じではないかもしれません。ソースコードとデプロイメントを結合すると、エラーが発生した場合に誰がオンコールサポートの責任を負うのかという疑問がチームに残ります。その結果、要件に大きな重複がある場合でも、チームは協力し合うことに消極的になってしまいます。
 
 ## 状況
 
-* チームはマイクロサービス環境で働いている。
-* 完全に機能する DevOps チームに編成されている。各チームは、メンテナンス、オンコール、カスタマーサポートを含むエンドツーエンドのコントリビューションに責任がある。
-* あるチームは、他のチームが構築した既存のサービスとよく似たサービスを下流の顧客に提供することを任務としている。
+* チームはマイクロサービス環境で働いています。
+* チームは完全に機能する DevOps チームによって編成されています。各チームは、メンテナンス、オンコール、カスタマーサポートを含むエンドツーエンドのコントリビューションに責任があります。
+* あるチームは、他のチームが構築した既存のサービスとよく似たサービスを下流の顧客に提供することを任務としています。
 
 ## ブロッカーとなりうるちから  (Forces)
 
-* 組織的なエスカレーション経路は、各チームで異なる可能性がある。
-* 各チームのメンバーは、自分たちの下流顧客に影響を与えないエ ラーについてはオンコールサポートに応じない可能性がある。
-* 同じ種類のエラーでも、チームや顧客との関係によって SLA の定義が異なるため、深刻度レベルが異なる場合がある。
-* チームによって、セキュリティや規制の制約が異なる場合がある。
+* 組織的なエスカレーション経路は、各チームで異なる可能性があります。
+* 各チームのメンバーは、自分たちの顧客に影響を与えないエラーのオンコールサポートに応じないことがあります。
+* 同じ種類のエラーでも、チームや顧客との関係によって SLA の定義が異なるため、深刻度レベルが異なる場合があります。
+* チームによって、セキュリティや規制の制約が異なる場合があります。
 
 ## ソリューション
 
-ソースコードとデプロイの責任を切り離す。両チームは、重複する部分や相乗効果がある部分を正確に特定するよう努力する。
+ソースコードとデプロイメントの責任を切り離します。両チームは、重複と相乗効果がある場所を正確に特定するために働きます。
 
-共有されたソースコードのみが、InnerSourceプロジェクトの一部として、共有された責任で保持されます。共有ソースは、すべてのテストコード（可能であれば統合テストを含む）と、コントリビューションの検証を容易にするために可能な限りCIパイプラインを含むという点で、首尾一貫している必要があります。
+共有されたソースコードのみが、責任を共有したインナーソースプロジェクトの一部として保持されます。共有ソースは、すべてのテストコード(可能であれば統合テストを含む)と、コントリビューションの検証を容易にするために可能な限りCIパイプラインを含むという点で、首尾一貫している必要があります。
 
-設定とデプロイのパイプラインを、実際のビジネスロジックから切り離す。 2番目のチーム用に、サービスの2番目のデプロイメントを確立する。
+設定とデプロイのパイプラインを、実際のビジネスロジックから切り離します。
+共有したチーム用に、サービスの2つめのデプロイメントを確立します。
 
-共通基盤を、両チームで使用するライブラリとして扱い、コードの所有権を共有する。
+共通基盤を、両チームで使用するライブラリとして扱い、コードの所有権を共有します。
 
-デプロイメント設定は、InnerSourceポートフォリオに別のプロジェクトとして含めることができ、チームが議論/コラボレーションしたり、新しいチームがそれをコピーしたりできるようにすることができます。
+デプロイメント設定をインナーソースポートフォリオの別プロジェクトとして含めることで、チームが議論/共同作業を行ったり、新しいチームがそれをコピーしたりすることができるようになります。
 
 ## 結果の状況
 
-チームは、ビジネスロジックを実装する作業を共有することで恩恵を受け、コラボレーションすることを望んでいます。
+チームは積極的に協力し、ビジネスロジックを実装する作業を共有することで利益を得ることができます。
 
-元々ある環境で動作するように特別に作られたサービスが、特定のビジネス要件に基づいて、より一般的なソリューションに変換されます。
+ある環境で動作するように特別に構築されたサービスが、特定のビジネス要件に基づき、より一般的なソリューションに変換されます。
 
-両チームは、それぞれのエスカレーションポリシーと展開設定を知ることができ、自分たちの設定に対する改善点を見出すことができる可能性がある。
+両チームは、それぞれのエスカレーションポリシーと展開設定を知ることができ、自分たちの設定に対する改善点を見出すことができる可能性があります。
 
 共有されたソースコードに変更が必要な可能性が高まり、実装を改良、改善、最適化する機会がより頻繁に発生するようになる。
 
 リリースのパッケージング、遠隔測定、ヘルス/レディネス エンドポイントなど、運用の標準化を段階的に進めることができるようになります。
 
 ## See also
 
-Related to this pattern is the [30 Day Warranty](30-day-warranty.md) pattern that takes a different approach to solving the forces described above.
+このパターンに関連するものとして、上記を解決するために異なるアプローチをとる[30日の保証期間](30-day-warranty.md) パターンがあります。
 
 ## 事例
 
 * ユーロスペース AG
-* Flutter Entertainment: Flutter InnerSourceアプリケーション](https://innersource.flutter.com/start/setup-ci/)は、チーム横断的にコントリビュートする共有コード「サービス」リポジトリと、共有リリース成果物をビルドして公開するCIパイプラインを備えています。各チームは独自のデプロイメントを定義する "デプロイメント設定 "リポジトリを持っています。これは、ビジネスのさまざまな領域におけるさまざまな規制要件、サービスおよびインシデント管理の実践、インフラストラクチャのスキルセットによって駆動されます。
+* Flutter Entertainment: 
+* 
+[Flutter インナーソースの応用](https://innersource.flutter.com/start/setup-ci/)には、チーム横断的にコントリビュートする共有コードの"サービスリポジトリ"と、共有リリース成果物をビルドして公開するためのCIパイプラインがあります。各チームは、独自のデプロイメントを定義する"デプロイメント設定"リポジトリを持っています。これは、さまざまな規制要件、サービスおよびインシデント管理の実践、ビジネスの各領域におけるインフラストラクチャのスキルセットによって異なる運用がされています。
 
 ## ステータス
 
 * Structured
 
-## 著者(s)
+## 著者
 
 * Isabel Drost-Fromm
 * Rob Tuley
 
 ## 謝辞
 
-Thank you Tobias Gesellchen for review internal to Europace AG.
+Tobias Gesellchenさん、Europace AGの内部レビューをありがとうございました。
 
 ## その他の呼び方
 
-Service vs. library: It's inner source, not inner deployment
+サービス対ライブラリ: インナーデプロイメントではなくインナー**ソース**