@@ -27,4 +27,5 @@
 このリポジトリのコンテンツは [CC-BY-SA-4.0](../../LICENSE.txt) の下でライセンスされています。このリポジトリにコントリビュートすることは、私たち(そして他のすべての人)に対して、このライセンスに従ってあなたのコントリビューション物を使用する権利を与えることになります。
 
 ## 翻訳の履歴
+
 - **2022-05-23** - 翻訳 [Yuki Hattori](https://github.com/yuhattor)
@@ -18,4 +18,5 @@
 このようにパターンを分類するアイデアは、Tim Yao さん、Bob Hanmer さん、Padma Sudarsanshi さんによる[Thoughts on an InnerSource Pattern Language](https://drive.google.com/file/d/13AY8glCOdpLOVuz7cVD6QOB8d2xbHCS1/view) (2018) の記述を大まかに元にしています。具体的な内容はそのスライドデックの15ページ目をご覧ください。
 
 ## 翻訳の履歴
+
 - **2022-05-23** - 翻訳 [Yuki Hattori](https://github.com/yuhattor)
@@ -1,6 +1,6 @@
 # イントロダクション
 
-![](../../book/innersource-patterns-book-cover.jpg)
+![book-cover](../../book/innersource-patterns-book-cover.jpg)
 
 {% hint style="info" %}
 あなたが読んでいるインナーソースパターンは初期のリリースフェイズです。リンクが壊れていたりスペルミスやエラーがある可能性があります。できる限りベストな本を作成するために是非修正にご協力ください。[本へのコントリビューション](./contribute.md)はこちらをご参照ください。
@@ -56,6 +56,7 @@
 [この本にコントリビュートするには](./contribute.md)
 
 ## クレジット
+
 この本は、世界中の無数の[オープンソースコントリビューター](https://github.com/InnerSourceCommons/InnerSourcePatterns/graphs/contributors)の方々による長年のワークの結果です。
 
 この本は、彼らの会社で直面した課題を率直に共有することや、どのようにそのチャレンジに InnerSource が役立ったかをオープンに共有ことに対する彼らの意欲によって素晴らしいものになっています。インナーソースの旅を始めようとしている方々にとって、とても貴重なリソースになるでしょう。
@@ -66,12 +67,12 @@
 
 **コントリビューターのみなさま、ありがとうございます！そして、良いインナーソースの日をお送りください😃**
 
-
 ## ライセンス
 
 ![Creative Commons License](https://i.creativecommons.org/l/by-sa/4.0/88x31.png)
 
 インナーソース・パターンは [InnerSourceCommons.org](http://innersourcecommons.org) によりライセンスされ、[Creative Commons Attribution-ShareAlike 4.0 International](http://creativecommons.org/licenses/by-sa/4.0/) ライセンスで提供されています。
 
 ## 翻訳の履歴
+
 - **2022-05-23** - 翻訳 [Yuki Hattori](https://github.com/yuhattor)
@@ -74,4 +74,5 @@
 - 複数の、功績至上主義的に任命された "[信頼されたコミッター(TC)](./trusted-committer.md)"が責任を持つことで、依存するチームの協力をコミュニティ化することで保証する。
 
 ## 翻訳の履歴
+
 - **2022-05-26** - 翻訳 [Yuki Hattori](https://github.com/yuhattor)
@@ -92,4 +92,5 @@ Provide standard base documentation through a README
 * [CONTRIBUTING-template.md](../templates/CONTRIBUTING-template.md)
 
 ## 翻訳の履歴
+
 - **2022-06-01** - 翻訳 [Yuki Hattori](https://github.com/yuhattor)
@@ -12,7 +12,7 @@
 
 ## 状況
 
-* すべてのプロジェクトがアクセスする共有リポジトリがあり、多くのプロジェクトが共通のコードを使おうとしています。 
+* すべてのプロジェクトがアクセスする共有リポジトリがあり、多くのプロジェクトが共通のコードを使おうとしています。
 * 誰かが(またはどこかのプロジェクトが)最初にコードを書き、リポジトリにコントリビュートしました。
 * 共通コードは、どのプロジェクトにおいても、成果物全体のうちのわずかな割合になります。
 * 各プロジェクトには、それぞれ独自の納期、成果物があり、別の顧客がいます。
@@ -23,10 +23,10 @@
 
 ## 組織に働く力学
 
-コードを利用可能にしたプロジェクトには、ひとつのニーズがあります。そのニーズは、一部の受けての組織が望んでいるものと似ていますが、まったく同じではありません。コードに関する要件は、実際の顧客のニーズから導き出される必要があります。 
+コードを利用可能にしたプロジェクトには、ひとつのニーズがあります。そのニーズは、一部の受けての組織が望んでいるものと似ていますが、まったく同じではありません。コードに関する要件は、実際の顧客のニーズから導き出される必要があります。
 
 異なる顧客のニーズが非常によく似ることはよくありますが、顧客によって表現が異なったり、重みが異なったりすることがあります。例えば、ある顧客はとある方法で結果を表示し、他の顧客は逆の順序で結果を表示することを望むような場合があります。両者の変換は簡単ですが、一方のケースで追加のコーディングが必要になり、その結果として、結果を計算するモジュールを両方の顧客で再利用することができなくなります。
-    
+
 多くの顧客は、サプライヤーに何が必要かを知るための手助けを望んでいます。この会社では、多くの「システムエンジニア」が製品の要求事項を書いています。これらの要件は、製品の開発を導くために顧客のニーズを抽出したものであると考えられています。コードの再利用は、会社の時間とお金を節約するための重要な目標になっています。
 
 多くの顧客は、サプライヤーが必要なものを知るのを手伝ってくれることを望んでいます。同社には、製品の要件を作成するための多くのシステムエンジニアがおり、それらの要件は製品開発の指針となる顧客ニーズの抽出物であるとされています。コードの再利用は、会社の時間とお金を節約するための重要な目標です。
@@ -38,7 +38,6 @@
 1. あるプロジェクトの要件を満たすコードが、他のプロジェクトのニーズも満たすように、プロジェクトの要件を調整する
 1. コードをリファクタリングして、多くの使用プロジェクトが要件に同意できるような小さな断片にする。
 
-
 さらに、サプライヤーに要件の解明を助けてほしい顧客を活用します。 コンポーネントを変更するのではなく、顧客との交渉中に要件の調整を行い、顧客の要件に影響を与えます。
 上記の例では、サプライヤーは両方の顧客が同じことを望んでいることを認識できるように支援し、同じ形式で結果を受け入れることに同意すれば、すべての人の労力(およびお金)を節約できます。
 
@@ -75,4 +74,5 @@ Robert Hanmer
 * Sebastian Spier
 
 ## 翻訳の履歴
+
 - **2022-06-02** - 翻訳 [Yuki Hattori](https://github.com/yuhattor)
@@ -61,5 +61,5 @@ Isabel Drost-Fromm
 * Drafted in December 2019.
 
 ## 翻訳の履歴
-- **2022-06-06** - 翻訳 [Yuki Hattori](https://github.com/yuhattor)
 
+- **2022-06-06** - 翻訳 [Yuki Hattori](https://github.com/yuhattor)
@@ -86,7 +86,7 @@
 - **2017-05-09** - rework
 - **2017-09-08** - second review, final rework and merged
 - **2021-02-27** - fixing issues with display of the pattern in the book
- 
+
 ## 翻訳の履歴
-- **2022-06-06** - 翻訳 [Yuki Hattori](https://github.com/yuhattor)
 
+- **2022-06-06** - 翻訳 [Yuki Hattori](https://github.com/yuhattor)
@@ -40,6 +40,7 @@
 
 他の人が簡単に参加でき、コントリビュートできるようにこのプロジェクトを維持することを仕事とするコアチームを形成します。このコアチームは、健全な利用やコントリビューションのエコシステムに必要な作業を行います。この重要な仕事は、コントリビューションとして優先されない傾向があります。この種の作業のカテゴリには、コミュニケーション、ローカル環境、DevOpsインフラストラクチャが含まれます。
 以下はその具体例です。
+
 * 本番環境のバグ
 * ドキュメンテーション
 * オンボーディングチュートリアルとサンプル
@@ -56,6 +57,7 @@
 その中心的な役割から、コアチームのメンバーはほぼ常に**信頼されたコミッター**の役割も果たすべきです (この概念については、[ラーニングパス][tc-learning-path]と [パターン][tc-pattern] を参照してください)。信頼されたコミッターの役割は、他のメンバーがプロジェクトに貢献したり利用したりするのを促進することに主眼が置かれていますが、コアチームのメンバーは定期的にプロジェクトにも貢献します。コアチームには、貢献を決定するような独自のビジネスアジェンダはありません。彼らは、他の人がプロジェクトを利用し貢献するために何が最も役に立つかを考えて、取り組むべきことを決定します。
 
 この目標を継続的にリマインドさせるためには、コアチームに定期的に以下の項目を報告してもらうのがよいでしょう。
+
 * そのプロジェクトを使用しているアクティブなチームの数
 * プロジェクトに対するチーム外からの貢献の数
 
@@ -90,4 +92,5 @@ Structured
 [tc-pattern]: ./trusted-committer.md
 
 ## 翻訳の履歴
+
 - **2022-06-01** - 翻訳 [Yuki Hattori](https://github.com/yuhattor)
@@ -98,4 +98,5 @@
 * Jeremiah Wright さんは、クロスチーム・プロジェクトを、開発者の時間という"通貨"を扱う社内ビジネスとして考えるように教えてくれました。
 
 ## 翻訳の履歴
+
 - **2022-06-03** - 翻訳 [Yuki Hattori](https://github.com/yuhattor)