成熟度モデル InnerSource Patterns Speaker: Yuki Hattori (@yuhattor) Pattern Authors: Daniel Izquierdo Cortazar Isabel Drost-Fromm Jorge Nerea

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

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

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

組織に働く力学 インナーソースのラーニングを共有するチームは、インナーソース採用の各レベルを認識していません。そ のため誤解につながることがあります。 チームは、「ソフトウェアの共有プラットフォーム( フォージ) への移行がすべてだ」と考えています （GitLab 、GitHub 、Bitbucket がそのようなフォージのよく知られた例です）。 チームは、日々の業務で遭遇する問題を解決するためのベストプラクティスを知りません。 InnerSource Patterns: 成熟度モデル @yuhattor 5

ソリューション 提案された成熟度モデルに照らして、チームに自己評価をしてもらいましょう。 InnerSource Patterns: 成熟度モデル @yuhattor 6

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

1. 透明性: 開発プロセスとツール (DP) インナーソースプロジェクトは、コントリビューターがアクティブになって参加するときに成長します。 結 果として、コントリビューションを容易にすることは、純粋な技術的目標とバランスを取る必要がありま す。 DP-0 ：各チームが独自の開発プロセスやツールに従っています。 しかしそれらは、開発チームの外部で知識や成果物を共有するように設定されていませ ん。開発チームはサイロ化されています。 DP-1: 開発チームは、内部で共有リポジトリを使用します。しかし一部のチームは、企業標準ではないCI ツールを使用して、独自のCI プロセスを開発してい ます。コードレビューのプロセスは定義されていませんが、プロジェクトチーム内部で行っているところもあります。 DP-2: 組織は、集合知のための共有リポジトリを後援し、推進しています。チームによっては、企業の定めたCI ツールを使って、独自のCI プロセスを開発し ています。CI の環境があるり、またコードレビュープロセスが定義されており、いくつかのプロジェクトで使用されています。コードレビューが外部のチ ームメンバによって行われることもあります。 DP-3: ほとんどのチームが、企業が定めたCI ツールを使って独自のCI プロセスを開発しています。CI 環境はあり、コードレビュープロセスが定義され利用さ れています。コードレビューがチーム内外のメンバーによって行われています。 InnerSource Patterns: 成熟度モデル @yuhattor 8

1. 透明性: 意思決定(DC) 同僚にコアチーム以外の仕事へのコントリビューション意欲を持たせるためには、ホストプロジェクトの意 思決定プロセスを可視化し、さらに自分たちの声が聞き入れられ評価されていると感じてもらうことが重要 です。 DC-0: 意思決定者はしばしば、プロジェクトの決定に関連するデータや資料を意図的または偶発的に非公開にすることがあります。 DC-1: 意思決定プロセスの一部である資料は、意思決定が確定した後に閲覧できるようになります。 DC-2: メンバーは、重要な意思決定のほとんど( すべてではない) について知っており、その意思決定の形成に役立っていると感じています。 意思決定の実践 の一部となる資料が、プロジェクトの節目節目で利用できるようになっています。 DC-3: メンバーは、組織が承認する集合的な意思決定のための共有された標準プロセスの一部であると感じています。意思決定プロセスの一部である資料 は、プロセス中に継続的にアクセス可能になっています。 InnerSource Patterns: 成熟度モデル @yuhattor 9

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

1. 透明性: ストーリー ホストチームの中で働くと、ミスが自動的に目立ってしまうようになります。そのため、失敗を成長の機会 としてとらえる企業文化が必要です。 ST-0: 学習の目的でも、成功や失敗を他者が学ぶために共有しません。 ST-1: 成功体験は共有しやすい一方で、失敗体験は共有していません。 ST-2: 個人とチームは、レトロスペクティブやレビューの際に、成功や失敗のストーリーを共有することに抵抗はありません。 ST-3: 個人とチームは、成功や失敗のストーリーを共有することに抵抗がなく、正式なプロトコルに従って失敗から学ぶことができます。 InnerSource Patterns: 成熟度モデル @yuhattor 11

2. コラボレーション: フィードバックのためのチャネル サイロをなくすには、同僚がオープンにフィードバックを共有することに対する抵抗をなくす必要がありま す。それをサポートする簡単な方法のひとつは、階層を越えて同じコミュニケーション原則を使用すること です。 CF-0: プロセスも確立されたチャネルもありません。組織の一部のメンバーは、プライベートチャネルまたはディスカッションを介して資料を共有していま す。 CF-1: 組織は、組織に属する誰もがそれらを使用できるように、会社/ 部門の決定に関する多様な視点を奨励するための内部ガイドラインとチャネルを確立 する過程にあります。 一方で組織の一部のメンバーは、非公式のプラットフォームを使用して非公式に意思決定資料を共有しています。リーダーは、組織 のメンバーが自分の仕事に関連するいくつかの問題について建設的に意見を共有するための、少なくともひとつの明確で直接的なチャネルを維持していま す。 CF-2: 組織は内部ガイドラインとチャネルを確立し、チームまたは決定に関する多様な視点を奨励および要請するための特定のリソース（トレーニングプ ログラム、コンテンツへのアクセスなど）を提供しています。 CF-3: 組織のメンバーは、公式に認可されたプラットフォームで意思決定資料を共有します。組織のメンバーは、フィードバックのための複数のチャネルと 方法を介して資料をオープンに共有します。リーダーはそれらのチャネルを自分で使用し、他の人にそれらを使用するように公に奨励し、受け取ったフィ ードバックやこのフィードバックに対処するために取った行動のチーム向けまたは公開向けの記録を維持します。 InnerSource Patterns: 成熟度モデル @yuhattor 12

2. コラボレーション: リーダーシップ インナーソースプロジェクトは、従業員が直属のラインマネージャーの直接の影響を受けないプロジェクト にコントリビュートすることを奨励しています。これには信頼の文化が必要です。 LS-0: 高度に階層化された組織内の命令系統とコントロールのカルチャーがあります。 LS-1: 一部のリーダーは、フィードバックを受け取り、メンバーが安全にフィードバックを提供できる環境を構築することに積極的です。 LS-2: 組織のほとんどのリーダーは、フィードバックを受け取り、メンバーが安全にフィードバックを提供できる環境を作ることに積極的です。しかしリー ダーは、すべてのメンバーが権限を与えられ、共有できるようになったかどうかを理解することに消極的です。組織は、リーダーが対話のなかに存在しな い声を積極的に求めて含めることを奨励しています。 LS-3: メンバーは、自分の仕事に関連する問題や情熱を持っている問題について建設的に意見を共有できるようになり、力を与えられたと感じています。 InnerSource Patterns: 成熟度モデル @yuhattor 13

2. コラボレーション: 組織的、そして機能的な構造 インナーソースが純粋なコーディングレベルを離れ、コミュニティやワーキンググループレベルに入ると、 直接的なコードコラボレーションが不可能な場合でも、サイロを減らす可能性があります。 OF-0: ワーキンググループでは、メンバーやスキルセットが固定される傾向にあります、 OF-1: 機能横断的なチームは存在するものの、チームの役割が不明確で、ガバナンス体制が曖昧であることが多いです。 OF-2: 機能横断的なチームが一般的であり、チームはその役割と目標を公表しています。 OF-3: 機能横断的なチームは一般的であり、その活動は組織内に広く知られ、その結果、組織は協業のためのベストプラクティスを推進しています。 InnerSource Patterns: 成熟度モデル @yuhattor 14

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

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

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

4. ガバナンス: リワード チーム横断的なコラボレーションを促進するために、外発的モチベーションを利用することができます。 RW-0: 報酬が設定されていません。 RW-1: リーダーは例外的なコラボレーションに対して報酬を与えるよう奨励されていますが、方針やプロセスは確立されていません。 RW-2: 開発者チーム以外のコラボレーションに報酬を与えるための標準的なプロセスが確立されています。チームリーダーや役員会が報酬を決定していま す。 RW-3: 報奨は組織から提案されるだけでなく、コミュニティがより価値のある報奨を定義することができます。コミュニティが責任を持って報酬を決定し ています。 InnerSource Patterns: 成熟度モデル @yuhattor 18

4. ガバナンス: モニタリングポリシー インナーソースのプロジェクトは、自己を評価のための手段を必要とします。メトリクスは、この評価を容 易にするための一つです。またインナーソースの導入レベルが成熟している組織では、明確で合意された測 定基準に基づいて、この手法の導入が追跡されることが期待されています。 MP-0: 組織内のどのレベルにおいても、既存の監視ポリシーがありません。 MP-1: メトリクスは特定のチームにとって重要であり、独立した方法でそれらは使用が始まっています。 MP-2: 組織全体で特定の方針を検証するのに役立つ測定基準に関して、組織レベルでの戦略があります。このモニタリング方針は、いくつかのインナーソ ースプロジェクトのレベルでも存在します。 MP-3 ：組織が提供する特定のインフラストラクチャでのメトリックの使用に関する明確なガイドライン、推奨事項、およびトレーニングがあります。これ は組織内での一般的なインナーソース採用を理解するためのインナーソースプログラムと、インナーソースプロジェクトの2 つのレベルで機能します。 InnerSource Patterns: 成熟度モデル @yuhattor 19

4. ガバナンス: サポートとメンテナンス インナーソースチームは機能開発のみを担当するのではなく、サポートとメンテナンスもチームのコアタス クの一部です。 SM-0: コア開発者またはサポートチームによるサポートが存在します。ビジネスサイドはサポートを保証します。チーム外には製品についての知識があり ません。 SM-1: 専任のサポートチームによってサポートが提供されます。製品のサポートを形式化するための規則と規制があります。 SM-2: インナーソースコントリビューションのサポートは、30 日の保証期間やライブラリよりもサービスなどのインナーソースパターンによって形式化さ れています。 SM-3: 成熟したコミュニティによって提供される、製品のサポートを形式化するための規則と規制があります。 InnerSource Patterns: 成熟度モデル @yuhattor 20

4. ガバナンス: カルチャー 協調的な文化に対する複数のレベルがあります。 CL-0: サイロ - チームは独立して機能しますが、単独でも機能します。 CL-1: リアクティブ - チームは独立して動きますが、うまくいかない依存関係に対応する方法を知っています。 CL-2: コントリビューション - チームはコントリビュートすることで依存関係の改善を積極的に支援します。 CL-3: アクティビスト - チームは積極的に助けを求め、メンタリングをし、新しいコントリビューターを募集します。 InnerSource Patterns: 成熟度モデル @yuhattor 21

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

結果の状況 すべてのチームが、利用可能なベストプラクティスを認識しています。 チームは、インナーソースの採用のレベルを理解しています。 作業モデルとしてインナーソースを採用する前に、チームは短期的にも長期的にも、チームに期待され るプラクティスを認識しています。 InnerSource Patterns: 成熟度モデル @yuhattor 23

事例 Entelgy Zylk Bitergia InnerSource Patterns: 成熟度モデル @yuhattor 24

その他の呼び方 成熟度モデル: インナーソースのベストプラクティスについて学ぶ InnerSource Patterns: 成熟度モデル @yuhattor 25

InnerSource についてもっと知る InnerSource Commons: https://innersourcecommons.org Join our Slack community: https://innersourcecommons.org/slack InnerSource Patterns: https://patterns.innersourcecommons.org Twitter: @InnerSourceOrg 日本語 Slack チャンネル: #jp-general 日本語 Twitter: @InnerSourceJP InnerSource Patterns: 成熟度モデル @yuhattor 26