@@ -61,7 +61,6 @@ Instead edit toc_template.md
   * [この本へのコントリビューション](../translation/japanese/contribute.md)
   * パターン
     * [30日の保証期間](../translation/japanese/patterns/30-day-warranty.md) - 自分のチーム以外からのコントリビューションを受け入れる場合、チームが書いていないコードの責任を持つことに抵抗があることは自然なことでしょう。 「30日の保証期間」プラクティスを利用すると、コードにコントリビュートしたチームはコードを受け取ったチームに対してバグフィックスを提供することを承諾することになります。 そうすることで、両チーム間の信頼度が高まり、コントリビューションが受け入れられる可能性が高くなります。
-    * [Communication Tooling](../translation/japanese/patterns/communication-tooling.md) - InnerSourceのプロジェクトは、元の開発チームの外で使用されていますが、ユーザーはヘルプを得たり、プロジェクトチームと連絡を取るのに苦労しています。このアイデアは、ディスカッションが可視化され、アーカイブされ、検索可能になることを可能にする標準的なコミュニケーションツールを設定し、文書化することです。
     * [Contracted Contributor](../translation/japanese/patterns/contracted-contributor.md) - InnerSourceにコントリビュートしたいアソシエイツは、彼らのライン管理によってそうすることから落胆しています。救済は、正式な契約や協定によって提供されています。
     * [Gig Marketplace](../translation/japanese/patterns/gig-marketplace.md) - マネージャーと従業員のどちらも、彼らはInnerSourceプロジェクトに関与して得ることから利益を得るかもしれない方法を理解しています。  それは従業員のために彼らはInnerSourceプロジェクトにする必要がありますどのような時間のコミットメントを彼らの経営にcomamunicateすることは困難である。
     * [InnerSource Portal](../translation/japanese/patterns/innersource-portal.md) - 潜在的なコントリビューターは、彼らが興味を持っているInnerSourceプロジェクトを簡単に見つけることができません。すべての利用可能なInnerSourceプロジェクトの情報をインデックス化するイントラネットのウェブサイトを作成することにより、あなたはコントリビューターが彼らに興味があるかもしれないプロジェクトについて学ぶことができ、InnerSourceプロジェクトの所有者は、外部の聴衆を引き付けることができます。
@@ -70,6 +69,7 @@ Instead edit toc_template.md
     * [インナーソースライセンス](../translation/japanese/patterns/innersource-license.md) - 同じ組織に属する2つの法人は、ソフトウェアのソースコードを互いに共有したいと考えていますが、法的責任や会社間の会計処理の観点からの影響を懸念しています。
     * [クロスチーム プロジェクト評価](../translation/japanese/patterns/crossteam-project-valuation.md) - 会社の収益に直接的な影響を提供していないクロスチームのインナーソースプロジェクトの価値を評価して社内に売り込むことは困難です。 ここでは、あなたのプロジェクトの価値を明確に表現し、それを大きくするためのデータ駆動型の方法を紹介します
     * [コアチーム](../translation/japanese/patterns/core-team.md) - インナーソースのプロジェクトが広く必要とされていても、プロジェクトが難しいためにコントリビューションや活用に支障をきたす場合があります。プロジェクトの基本的な項目を専門に担当するコアチームを設立してください。コアチームの作業により、コントリビューターは自分のシナリオに価値をもたらす機能を追加し、使用することができます。
+    * [コミュニケーションツール](../translation/japanese/patterns/communication-tooling.md) - インナーソースのプロジェクトは、開発チームの外で使用されていますが、ユーザーはヘルプを得たり、プロジェクトチームと連絡を取るのに苦労しています。 このアイデアは、ディスカッションが可視化され、アーカイブされ、検索可能になることを可能にする標準的なコミュニケーションツールを設定し、文書化することです。
     * [サービス vs. ライブラリー](../translation/japanese/patterns/service-vs-library.md) - DevOps環境のチームは、サービスのダウンタイムに誰が対応するのかが曖昧なため、チームの境界を越えて共通のコードベースで作業することに消極的かもしれません。解決策としては、同じサービスを独立した環境で展開し、サービスダウン時のエスカレーションを別々に行うか、多くの共有コードを1つのライブラリにまとめて、その上でコラボレーションすることが可能な場合が多いことを認識することです。
     * [スタンダード・ベース・ドキュメンテーション](../translation/japanese/patterns/base-documentation.md) - インナーソースプロジェクトへの新しいコントリビューターは、誰がプロジェクトを維持し、何に取り組み、どのようにコントリビューションすればよいかを理解するのに苦労しています。README.md/CONTRIBUTING.md のような標準ファイルでドキュメントを提供することで、新しいコントリビューターのためのセルフサービスなプロセスを可能にし、よくある質問に対する答えを自分自身で見つけることができるようにします。
     * [リポジトリアクティビティスコア](../translation/japanese/patterns/repository-activity-score.md) - 潜在的なコントリビューターは、彼らの助けを必要とするアクティブなInnerSourceプロジェクトを見つけたいと思っています。各プロジェクトのリポジトリ活動スコアを計算することで、プロジェクトのランク付けされたリストを作成することができます（例：InnerSource Portal ）、そのため、潜在的コントリビューターは、彼らがコントリビュートしたいプロジェクトをより簡単に決定できます。