@@ -67,7 +67,6 @@ Instead edit toc_template.md
     * [InnerSource License](../translation/japanese/patterns/innersource-license.md) - 同じ組織に属する2つの法人は、ソフトウェアのソースコードを互いに共有したいが、法的責任や会社間の会計処理の観点からの影響を懸念している。
     * [InnerSource Portal](../translation/japanese/patterns/innersource-portal.md) - 潜在的なコントリビューターは、彼らが興味を持っているInnerSourceプロジェクトを簡単に見つけることができません。すべての利用可能なInnerSourceプロジェクトの情報をインデックス化するイントラネットのウェブサイトを作成することにより、あなたはコントリビューターが彼らに興味があるかもしれないプロジェクトについて学ぶことができ、InnerSourceプロジェクトの所有者は、外部の聴衆を引き付けることができます。
     * [Issue Tracker Use Cases](../translation/japanese/patterns/issue-tracker.md) - InnerSourceのホストチームは、計画や進捗だけでなく、変更の背景も透明化できていません。これは、プロジェクトの課題トラッカーのユースケースを増やし、ブレーンストーミング、実装の議論、機能設計にも使えるようにすることで解決されます。
-    * [Maturity Model](../translation/japanese/patterns/maturity-model.md) - Teams have started adopting InnerSource. The practice is spreading to multiple departments. However, the understanding of what constitutes an InnerSource project varies. The solution is to provide a maturity model to allow for teams to go through a self check and discover patterns and practices that they are not yet aware of.
     * [RFCを用いたチーム横断的な意思決定の透明化](../translation/japanese/patterns/transparent-cross-team-decision-making-using-rfcs.md) - 高い参加率を達成し、関係者全員にとって最良の意思決定を行いたいInnerSourceプロジェクトは、ソフトウェアのライフサイクル全体を通して参加型のシステムを構築する方法を見つける必要があります。内部のRFC（Requests for Comments）ドキュメントを公開することで、設計プロセスの早い段階から議論を行うことができ、関係者全員が高いコミットメントを持ってソリューションを構築できる可能性が高まります。
     * [クロスチーム プロジェクト評価](../translation/japanese/patterns/crossteam-project-valuation.md) - 会社の収益に直接的な影響を提供していないクロスチームのインナーソースプロジェクトの価値を評価して社内に売り込むことは困難です。 ここでは、あなたのプロジェクトの価値を明確に表現し、それを大きくするためのデータ駆動型の方法を紹介します
     * [コアチーム](../translation/japanese/patterns/core-team.md) - インナーソースのプロジェクトが広く必要とされていても、プロジェクトが難しいためにコントリビューションや活用に支障をきたす場合があります。プロジェクトの基本的な項目を専門に担当するコアチームを設立してください。コアチームの作業により、コントリビューターは自分のシナリオに価値をもたらす機能を追加し、使用することができます。
@@ -79,5 +78,6 @@ Instead edit toc_template.md
     * [共通要件](../translation/japanese/patterns/common-requirements.md) - 共有リポジトリにある共通のコードは、それを使いたいすべてのプロジェクトチームのニーズを満たしていません。これは、要件の調整とリファクタリングによって解決されます。
     * [基本原則ガイダンスの文書化](../translation/japanese/patterns/document-your-guiding-principles.md) - 「オープンソースのベストプラクティスを組織内に適用する」という通常のインナーソースの説明は、オープンソースのバックグラウンドがない人々にはうまく機能しません。 解決策として、インナーソースの最も重要な原則を文書化し広く公開しましょう。
     * [実験として始める](../translation/japanese/patterns/start-as-experiment.md) - インナーソースイニシアチブを期間限定の実験として開始し、インナーソースに慣れていないマネージャーがイニシアチブを承認およびサポートしやすくします。
+    * [成熟度モデル](../translation/japanese/patterns/maturity-model.md) - チームはインナーソースを採用し始めました。このプラクティスは、複数の部門に広がっています。しかし、インナーソースプロジェクトを構成する概念への理解は様々です。解決策は、チームがセルフチェックを経て、まだ気づいていないパターンやプラクティスを発見できるよう、成熟度モデルを提供することです。
     * [献身的なコミュニティリーダー - Dedicated Community Leader](../translation/japanese/patterns/dedicated-community-leader.md) - インナーソースの取り組みを成功させるために、コミュニケーションとテクニカルの両方のスキルを持つ人をコミュニティのリーダーとして選ぶ。
     * [賛美の参加者](../translation/japanese/patterns/praise-participants.md) - インナーソースのコントリビューションの後、その時間と努力に対してコントリビューターに感謝することは重要です。 このパターンは、コントリビューションを効果的に認めるだけでなく、コントリビューターや他の人たちのさらなる関与を引き出すためのガイダンスを提供します。