# 成熟度モデル

### Title

成熟度モデル

### Patlet

チームはインナーソースを採用し始めました。このプラクティスは、複数の部門に広がっています。しかし、インナーソースプロジェクトを構成する概念への理解は様々です。解決策は、チームがセルフチェックを経て、まだ気づいていないパターンやプラクティスを発見できるよう、成熟度モデルを提供することです。

### 問題

企業におけるインナーソースの導入が進み始めると、一人のエバンジェリストを通じて各プロジェクトを個別に指導することは不可能になります。また、インナーソースプロジェクトで働くことの意味について、少なくとも基本的な理解を深めている人が増えてきています。すべてのインナーソースプロジェクトを見てみると、コンセプトに対する理解の深さは異なります。チームは、彼らが次のレベルに移動し、彼らが扱っている問題やペインのポイントを解決するのに役立つだろう実績のあるパターンを認識していない可能性があります。

### 状況

いくつかのチームがインナーソースのプラクティスを採用し始めています。プラクティスの正確な理解度は、チームによって異なります。また、各チームが直面する問題も、各チームの状況や作業環境に応じて異なります。その結果、インナーソースプロジェクトにおける重要なベストプラクティスの定義は、各チームによって異なっています。

### 組織に働く力学

インナーソースのラーニングを共有するチームは、インナーソース採用の各レベルを認識していません。そのため誤解につながることがあります。

チームは、「ソフトウェアの[共有プラットフォーム(フォージ)](https://en.wikipedia.org/wiki/Forge_%28software%29)への移行がすべてだ」と考えています（GitLab、GitHub、Bitbucketがそのようなフォージのよく知られた例です）。

チームは、日々の業務で遭遇する問題を解決するためのベストプラクティスを知りません。

### ソリューション

提案された成熟度モデルに照らして、チームに自己評価をしてもらいましょう。

#### 透明性

**プランとプロダクト (PP)**

インナーソースプロジェクトは、ステークホルダーが決定をよりよく理解し、他の人が従うことができる方法で決定に影響を与えることができるようにすることで、組織全体で透明性のある計画を立てることができ、そのことから恩恵を受けます。

* PP-0: 個人やチームが、複数のステークホルダーに対して定期的にプランやプロダクトを開示していません。組織内に正式なアクションが存在しません。
* PP-1: 個人やチームは、プランやプロダクトが開始される前に、複数のステークホルダーにたいして可視化します。またロードマップは共有されています。
* PP-2: 明確なガイドラインと貢献ルールを持つ共有ロードマップが既に存在し、ステークホルダーがフィードバックを提供できます。しかし、これは組織全体で標準化されておらず、すべてのプロジェクトがこの情報を提供しているわけではありません。
* PP-3: ロードマップはデフォルトで共有され、各インナーソースプロジェクトのレベルで、組織全体でこれを行うための標準的なプロセスとスタンダードな方法があります。これには、ロードマップにコントリビュートして影響を与えるための明確なルールが含まれています。

**開発プロセスとツール (DP)**

インナーソースプロジェクトは、コントリビューターがアクティブになって参加するときに成長します。 結果として、コントリビューションを容易にすることは、純粋な技術的目標とバランスを取る必要があります。

* DP-0：各チームが独自の開発プロセスやツールに従っています。 しかしそれらは、開発チームの外部で知識や成果物を共有するように設定されていません。開発チームはサイロ化されています。
* DP-1: 開発チームは、内部で共有リポジトリを使用します。しかし一部のチームは、企業標準ではないCIツールを使用して、独自のCIプロセスを開発しています。コードレビューのプロセスは定義されていませんが、プロジェクトチーム内部で行っているところもあります。
* DP-2: 組織は、集合知のための共有リポジトリを後援し、推進しています。チームによっては、企業の定めたCIツールを使って、独自のCIプロセスを開発しています。CIの環境があるり、またコードレビュープロセスが定義されており、いくつかのプロジェクトで使用されています。コードレビューが外部のチームメンバによって行われることもあります。
* DP-3: ほとんどのチームが、企業が定めたCIツールを使って独自のCIプロセスを開発しています。CI環境はあり、コードレビュープロセスが定義され利用されています。コードレビューがチーム内外のメンバーによって行われています。

**意思決定(DC)**

同僚にコアチーム以外の仕事へのコントリビューション意欲を持たせるためには、ホストプロジェクトの意思決定プロセスを可視化し、さらに自分たちの声が聞き入れられ評価されていると感じてもらうことが重要です。

* DC-0: 意思決定者はしばしば、プロジェクトの決定に関連するデータや資料を意図的または偶発的に非公開にすることがあります。
* DC-1: 意思決定プロセスの一部である資料は、意思決定が確定した後に閲覧できるようになります。
* DC-2: メンバーは、重要な意思決定のほとんど(すべてではない)について知っており、その意思決定の形成に役立っていると感じています。 意思決定の実践の一部となる資料が、プロジェクトの節目節目で利用できるようになっています。
* DC-3: メンバーは、組織が承認する集合的な意思決定のための共有された標準プロセスの一部であると感じています。意思決定プロセスの一部である資料は、プロセス中に継続的にアクセス可能になっています。

**役立つリソース** コントリビューターを引きつけるために、役立つサポート資料に簡単にアクセスできる必要があります。

* RS-0: 個人およびチームは、ナレッジに関する共有リポジトリにコントリビュートしたり、それを利用したりすることはありません。
* RS-1: 個人およびチームは、作業が終了した後、内部でレビューするためにプロジェクト資料をリリースします。個人とチームはリソースを共有しますが、それは切断された、断片化された、または個別化/サイロ化されたシステムまたはリポジトリにあります。 個人とチームはリソースを共有しますが、情報が機密であるかどうかを判断するために使用される基準について、一般的に表現され共有されているものはありません。「他人と考えを共有する」こともしていません。
* RS-2: 個人およびチームは、明確に定義および共有された形式および/またはプロトコルに従って、プロジェクトチームの一部のメンバーがプロジェクト関連の資料にアクセスできるようにします。個人およびチームは、機密データおよびリソースを差し控え、限定された詳細、コンテキスト、および範囲を提供します。
* RS-3: 個人およびチームは、明確に定義および共有された形式および/またはプロトコルに従って、プロジェクト関連の資料を組織に広くアクセスできるようにします。機密データやリソースを差し控えなければならない個人やチームは、共有しないものについて明確に知っており、他の人はそれらの資料が利用できない理由を理解しています。

**ストーリー** ホストチームの中で働くと、ミスが自動的に目立ってしまうようになります。そのため、失敗を成長の機会としてとらえる企業文化が必要です。

* ST-0: 学習の目的でも、成功や失敗を他者が学ぶために共有しません。
* ST-1: 成功体験は共有しやすい一方で、失敗体験は共有していません。
* ST-2: 個人とチームは、レトロスペクティブやレビューの際に、成功や失敗のストーリーを共有することに抵抗はありません。
* ST-3: 個人とチームは、成功や失敗のストーリーを共有することに抵抗がなく、正式なプロトコルに従って失敗から学ぶことができます。

#### コラボレーション

**フィードバックのためのチャネル**

サイロをなくすには、同僚がオープンにフィードバックを共有することに対する抵抗をなくす必要があります。それをサポートする簡単な方法のひとつは、階層を越えて同じコミュニケーション原則を使用することです。

理想的には、組織の誰もが知っている適切なコミュニケーション・チャネルを持つことになります。チャネルは、異なるターゲット(お知らせ、ユーザーサポート、開発チャネル、インフラ・ディスカッションなど)に焦点を当てます。 インナーソースプロジェクトが成熟するにつれて確立するベストプラクティスには以下のようなものがあります。

* ネチケットガイドラインの採用
* 新しいインナーソースプロジェクトごとに実証済みの（アーカイブされ、一般にアクセス可能で、検索可能な）標準チャネルの開設
* CF-0: プロセスも確立されたチャネルもありません。組織の一部のメンバーは、プライベートチャネルまたはディスカッションを介して資料を共有しています。
* CF-1: 組織は、組織に属する誰もがそれらを使用できるように、会社/部門の決定に関する多様な視点を奨励するための内部ガイドラインとチャネルを確立する過程にあります。 一方で組織の一部のメンバーは、非公式のプラットフォームを使用して非公式に意思決定資料を共有しています。リーダーは、組織のメンバーが自分の仕事に関連するいくつかの問題について建設的に意見を共有するための、少なくともひとつの明確で直接的なチャネルを維持しています。
* CF-2: 組織は内部ガイドラインとチャネルを確立し、チームまたは決定に関する多様な視点を奨励および要請するための特定のリソース（トレーニングプログラム、コンテンツへのアクセスなど）を提供しています。
* CF-3: 組織のメンバーは、公式に認可されたプラットフォームで意思決定資料を共有します。組織のメンバーは、フィードバックのための複数のチャネルと方法を介して資料をオープンに共有します。リーダーはそれらのチャネルを自分で使用し、他の人にそれらを使用するように公に奨励し、受け取ったフィードバックやこのフィードバックに対処するために取った行動のチーム向けまたは公開向けの記録を維持します。

**リーダーシップ**

インナーソースプロジェクトは、従業員が直属のラインマネージャーの直接の影響を受けないプロジェクトにコントリビュートすることを奨励しています。これには信頼の文化が必要です。

* LS-0: 高度に階層化された組織内の命令系統とコントロールのカルチャーがあります。
* LS-1: 一部のリーダーは、フィードバックを受け取り、メンバーが安全にフィードバックを提供できる環境を構築することに積極的です。
* LS-2: 組織のほとんどのリーダーは、フィードバックを受け取り、メンバーが安全にフィードバックを提供できる環境を作ることに積極的です。しかしリーダーは、すべてのメンバーが権限を与えられ、共有できるようになったかどうかを理解することに消極的です。組織は、リーダーが対話のなかに存在しない声を積極的に求めて含めることを奨励しています。
* LS-3: メンバーは、自分の仕事に関連する問題や情熱を持っている問題について建設的に意見を共有できるようになり、力を与えられたと感じています。

**組織的、そして機能的な構造**

インナーソースが純粋なコーディングレベルを離れ、コミュニティやワーキンググループレベルに入ると、直接的なコードコラボレーションが不可能な場合でも、サイロを減らす可能性があります。

* OF-0: ワーキンググループでは、メンバーやスキルセットが固定される傾向にあります、
* OF-1: 機能横断的なチームは存在するものの、チームの役割が不明確で、ガバナンス体制が曖昧であることが多いです。
* OF-2: 機能横断的なチームが一般的であり、チームはその役割と目標を公表しています。
* OF-3: 機能横断的なチームは一般的であり、その活動は組織内に広く知られ、その結果、組織は協業のためのベストプラクティスを推進しています。

**コントリビューション**

コントリビューションパターンを設計する際の目標が、サイロを減らすことである場合、コラボレーションを念頭に置く必要があります。

* CB-0: 完全にサイロ化されており、チーム外でのコラボレーションはありません。コラボレーションはクロスファンクショナルチームによるものがいくつかあります。
* CB-1: 組織のメンバーとチームは協力していますが、「難しすぎる」とよく言われます。 チームは、コラボレーションの結果をめったに再評価しません。
* CB-2: 組織のメンバーとチームは、積極的に協力する機会を求めています。チームは、共同作業の結果について定期的に話し合い、再評価し、議論し、これらの結果をデフォルトで利用できるようにします。
* CB-3: 組織のメンバーは、関係者全員に利益をもたらす方法で、内部と外部の両方で協力します。 チームは共同作業の結果について定期的に話し合い、再評価し、議論し、組織外で学んだことを共有し、これらの結果をデフォルトで外部で利用できるようにします。

#### コミュニティ

**共有ポリシー**

共有値に関するベースラインがあると、チームの境界を越えて作業しやすくなります。限られたベースラインルールとガイドラインのセットがどこにでも適用され、簡単に参照できる場合は、境界を越えることが容易になります。

* SP-0: 共有する文化もドキュメント化されたポリシーもありません。
* SP-1: 組織の一部のメンバーは、価値観や原則を定義するために団結するものの、その際に明確に支持されることはありません。
* SP-2: 組織のメンバーは、ミッションステートメントや行動規範などの共有ビジョンと合意をまとめてドキュメント化し、簡単にアクセスできるようにし、頻繁に参照します。 オンボーディング資料とオリエンテーションの慣例は、新しいメンバーが組織がコントリビューションからどのように利益を得るかを理解するのに役立ちます。
* SP-3: 共有された価値観と原則は、組織のメンバー間で意思決定、コンフリクトの解決、および評価プロセスに情報を提供します。メンバーは、これらの価値観と原則を口頭とドキュメントの両方の形式で一貫して参照します。

**組織の一員であると実感できる**

インナーソースを組織に導入する理由のひとつとして、エンゲージメントの向上が考えられます。このポイントでは、インナーソースを採用している間にエンゲージメントがどのように変化しているかを追跡します。

* PA-0: エンゲージメントが低く、コラボレーションがなく、人々は他の人と共有することに抵抗を感じます。
* PA-1: 組織のメンバーは、報復を恐れることなく自分の考えや意見を共有することに抵抗を感じませんが、それはあくまでも慣れ親しんだ領域でのみです。ただしメンバーは、最高のアイデアが勝ち、コントリビューションとコミットメントの実績を持つ人々にリーダーシップの責任が生じることを理解しています。
* PA-2: 組織のメンバーは、報復を恐れることなく、自分の考えや意見を快適に共有できます。リーダーは、組織の共有価値への献身を示します。
* PA-3: 組織はメンバーにコントリビューションの恩恵を受けていることを積極的に伝えています。このように、メンバーは共有された意識と権限を与えられた実行を示し、コミュニティへの責任感を感じます。リーダーは、他の人の成長を支援することで成長することを理解し、組織のジュニアメンバーを指導します。

#### ガバナンス

**リワード**

チーム横断的なコラボレーションを促進するために、外発的モチベーションを利用することができます。

* RW-0: 報酬が設定されていません。
* RW-1: リーダーは例外的なコラボレーションに対して報酬を与えるよう奨励されていますが、方針やプロセスは確立されていません。
* RW-2: 開発者チーム以外のコラボレーションに報酬を与えるための標準的なプロセスが確立されています。チームリーダーや役員会が報酬を決定しています。
* RW-3: 報奨は組織から提案されるだけでなく、コミュニティがより価値のある報奨を定義することができます。コミュニティが責任を持って報酬を決定しています。

**モニタリングポリシー**

インナーソースのプロジェクトは、自己を評価のための手段を必要とします。メトリクスは、この評価を容易にするための一つです。またインナーソースの導入レベルが成熟している組織では、明確で合意された測定基準に基づいて、この手法の導入が追跡されることが期待されています。

* MP-0: 組織内のどのレベルにおいても、既存の監視ポリシーがありません。
* MP-1: メトリクスは特定のチームにとって重要であり、独立した方法でそれらは使用が始まっています。
* MP-2: 組織全体で特定の方針を検証するのに役立つ測定基準に関して、組織レベルでの戦略があります。このモニタリング方針は、いくつかのインナーソースプロジェクトのレベルでも存在します。
* MP-3：組織が提供する特定のインフラストラクチャでのメトリックの使用に関する明確なガイドライン、推奨事項、およびトレーニングがあります。これは組織内での一般的なインナーソース採用を理解するためのインナーソースプログラムと、インナーソースプロジェクトの2つのレベルで機能します。

**サポートとメンテナンス**

インナーソースチームは機能開発のみを担当するのではなく、サポートとメンテナンスもチームのコアタスクの一部です。

* SM-0: コア開発またはサポートチームによるサポートが存在します。ビジネスサイドはサポートを保証します。チーム外には製品についての知識がありません。
* SM-1: 専任のサポートチームによってサポートが提供されます。製品のサポートを形式化するための規則と規制があります。
* SM-2: インナーソースコントリビューションのサポートは、[30日の保証期間](/ja/30-day-warranty.md)や[ライブラリよりもサービス](/ja/service-vs-library.md)などのインナーソースパターンによって形式化されています。
* SM-3: 成熟したコミュニティによって提供される、製品のサポートを形式化するための規則と規制があります。

**カルチャー**

協調的な文化に対する複数のレベルがあります。

* CL-0: サイロ - チームは独立して機能しますが、単独でも機能します。
* CL-1: リアクティブ - チームは独立して動きますが、うまくいかない依存関係に対応する方法を知っています。
* CL-2: コントリビューション - チームはコントリビュートすることで依存関係の改善を積極的に支援します。
* CL-3: アクティビスト - チームは積極的に助けを求め、メンタリングをし、新しいコントリビューターを募集します。

**インナーソースにおける役割**

インナーソースにはいくつかの明示的な役割があります。初期の段階では、これらの役割を採用しなくても一部のパターンを使用できる場合がありますが、明示的な役割のタイトルを使用してプロジェクト内でコミュニケーションする方が簡単になります。

* RO-0: インナーソースの採用を支援する特定の役割はありません。開発者、アナリスト、テスターなど一般的な開発の役割のみが存在します。
* RO-1: 時折、一部の個人やチームが他のプロジェクトにコントリビュートします。これらは技術的なコントリビューションであり、ユーザー/コントリビューターの役割が見られます。 チームによっては、少なくとも一人のメンバーが、他の開発チームのメンバーに開発プロセスを説明する技術的なリファレンスであることが確認されています。このメンバーはトラステッドコミッターの役割をカバーするための候補者となりえます。
* RO-2: 「インナーソースオフィス」が存在します。インナーソースオフィサーの役割は、ガバナンスとサポートを担当します。プロセスなどを含みます。教育ニーズを特定し、組織に提供されることを確認します。ISプロジェクトへの組織の参加をリードし、メンタリングします。インナーソースのビジョンとロードマップを定義するための最初の公式ステップです。組織は、開発チームのメンバーだけでなく、外部の貢献者に対しても連絡先/参照先となる信頼できるコミッターの役割を定義しています。コミュニティへの貢献方法を説明する標準的なプロセスがあり、貢献者の役割が存在します。データサイエンティストの役割は、インナーソースイニシアチブによって残されたアクティビティの痕跡を管理し、インナーソースの進化を測定するために必要です。信頼できるコミッターの役割は、より技術的なプロフィールに進化し、コミュニティマネージャーはコミュニティを「活性化」する役割を担当し、主な責任は新しい開発者/ユーザー（貢献者/コミュニティメンバー）を引き付け、維持することです。
* RO-3: 「エバンジェリスト」は組織内を移動し、現在の作業、インナーソースの機能とその方法を他の人に知らせ、他の人がイニシアチブを理解して参加できるように支援します。この段階では「非技術的なコントリビューター」の存在も出現します。

### 結果の状況

すべてのチームが、利用可能なベストプラクティスを認識しています。

チームは、インナーソースの採用のレベルを理解しています。

作業モデルとしてインナーソースを採用する前に、チームは短期的にも長期的にも、チームに期待されるプラクティスを認識しています。

### 事例

* Entelgy
* Zylk
* Bitergia

### 著者

* Daniel Izquierdo Cortazar
* Isabel Drost-Fromm
* Jorge
* Nerea

### 謝辞

* Alexander Andrade (スペルの修正に特に感謝します)

### その他の呼び方

成熟度モデル: インナーソースのベストプラクティスについて学ぶ

### ステータス

* Structured
* Drafted in September 2019

### 翻訳の履歴

* **2023-06-18** - 翻訳 [Yuki Hattori](https://github.com/yuhattor)
* **2023-06-18** - 最終更新


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://patterns.innersourcecommons.org/ja/maturity-model.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.