インナーソースパターンブックへようこそ。

この本では、インナーソースのベストプラクティスを理解しやすい特定のフォーマットで体系化し、評価し、あなたの環境で適用しやすくまとめています。このフォーマットを私たちは "パターン" と読んでいます。

インナーソース は、長年にわたってこれらのパターンを収集し、この本で最も成熟したパターンを公開しています。また、コミュニティのメンバーが、少なくとも一つの事例をもって、それぞれのパターンをレビューしています。

このイントロダクションでは、インナーソースとは何か、パターンとは何か、そしてあなたの組織におけるこれらのパターンの使い方 について説明します。

もしあなたが既に会社でインナーソースを使っていて、その経験を本書に提供したいのであれば、ぜひ本書へのコントリビューションをよろしくお願いします！

インナーソースとは何か

私たちはインナーソースを次のように定義しています。

組織という限られた環境において、ソフトウェア開発におけるオープンソースの原則とプラクティスを活用すること

インナーソースは、オープンソースソフトウェアの開発から得た教訓を、企業の社内でのソフトウェア開発のあり方に応用します。 開発者は世界トップクラスのオープンソースソフトウェアに慣れるにつれて、これらの手法をファイアウォールの内側に戻し、企業がリリースを躊躇するようなソフトウェアに適用したいと強く思うようになりました。

インナーソースは、主にクローズドソースのソフトウェアを構築している企業にとって、サイロの解消、社内コラボレーションの促進および拡大、新しいエンジニアのオンボーディングの促進、そしてオープンソースの世界にソフトウェアを還元するチャンスを探るのに役立つ役立つ素晴らしいツールです。

インナーソースパターンとは何か

パターンとは、ある状況の中で、問題に対する再現可能で実績のある解決策を記述する方法です。 パターンは、ソリューションを適用する際に、問題の制約を理解し、バランスをとる必要のある力を理解し、ソリューションを適用した結果生じる状況を理解することをたすけるシンプルなフォーマットに従っています。

パターンは、インナーソース・コモンズ の参加者が情報を簡潔に共有し、インナーソースのプラクティスを磨く方法を提供しており、タイトル、問題提起、状況、フォース、ソリューションを主要なセクションとして分けて構成してあります。

• パターンとは何か Youtube ビデオ - インナーソースパターンを説明する2-5分のyoutubeビデオのセットをご覧ください

• パターンディスカッション ウェビナー - 2017年3月16日にウェビナーを開催し、ドーナツパターンをライブディスカッションしました（ディスカッションは24:30から）。これは、私たちが行うレビュープロセスの実例です。

• 合わせてこちらもご覧下さい 2017年6月1日 インナーソースパターンに関する O'Reilly ウェビナー.

• パターンテンプレート - インナーソースパターンの概略を見て、新しいパターンの中身を知ることができます

• インナーソースパターンの紹介 (2016 Fall Summit presentation) - Tim Yao and Padma Sudarsan (PDF) 「パターンとの付き合い方 - 手法と理由を詳しく理解する」合わせてこちらもご覧ください - インナーソースパターン入門 (2017 Fall Summit) Tim Yao and Bob Hanmer (PDF)

どのようにインナーソースパターンを使うか

パターンは無差別に適用するのではなく、よく考えて使わなければなりません。

ほとんどの場合、与えられたソリューションを自分達の状況に合わせる必要がありますが、パターンで与えられている情報、コンテキスト（動かせない制約）とフォース（変更可能な制約、相互にバランスをとる制約）の定義は、ソリューションを適用するのに役立つはずです。 またパターンに追加すべき項目として、あなたの特定の企業/組織に適用さる追加の制約があるかを決定する必要があることにも注意してください。 これらの追加の制約のためには、追加のソリューションステップを適用する必要があるかもしれません。

パターンのフォーマットは実績のあるソリューションを記述するのに便利ですが、パターンがまだ確立されていない新しいソリューションに関する ブレインストーミング にも使用できます。これは、パターンの構造が、構造化された方法で問題について考えるためのフレームワークになっているからです。

また、インナーソース・コモンズのコミュニティに助けを求める方法として、ドーナツ・パターン（問題、状況、フォース、結果の状態のフィールドを記載し、ソリューションの欄は空白にする）を作ることもできます。(実証済みのソリューションを見つけるために、または試してみるためにブレインストーミングを実施します)

コントリビュートするには

こちらをご参照ください。 この本にコントリビュートするには

クレジット

この本は、世界中の無数のオープンソースコントリビューターの方々による長年のワークの結果です。

この本は、彼らの会社で直面した課題を率直に共有することや、どのようにそのチャレンジに InnerSource が役立ったかをオープンに共有ことに対する彼らの意欲によって素晴らしいものになっています。インナーソースの旅を始めようとしている方々にとって、とても貴重なリソースになるでしょう。

またインナーソース・パターンのワーキンググループに関しても言及させてください。彼らは、インナーソース・パターンのクオリティを育て、他の人がコントリビュートするのを支援してきました。

最後に、彼らはこの本に利用可能なパターンを選択してまとめています。この本のタイトル画像は、CC BY 2.0で利用可能な Tony Hisgett - Alhambra 6 による画像を基に Sebastian Spier氏によって作成されています。

コントリビューターのみなさま、ありがとうございます！そして、良いインナーソースの日をお送りください😃

ライセンス

インナーソース・パターンは InnerSourceCommons.org によりライセンスされ、Creative Commons Attribution-ShareAlike 4.0 International ライセンスで提供されています。

翻訳の履歴

• 2022-05-23 - 翻訳 Yuki Hattori

• 2022-06-15 - レビュー @johtani

Title

30日の保証期間

Patlet

自分のチーム以外からのコントリビューションを受け入れる場合、チームが書いていないコードの責任を持つことに抵抗があることは自然なことでしょう。 「30日の保証期間」プラクティスを利用すると、コードにコントリビュートしたチームはコードを受け取ったチームに対してバグフィックスを提供することを承諾することになります。 そうすることで、両チーム間の信頼度が高まり、コントリビューションが受け入れられる可能性が高くなります。

問題

あるチームが、組織全体で使用されるコンポーネントを開発しています。 このチームはコントリビューション(機能への要求を含む) を受け入れることに抵抗したり、完全に拒否したりします。 この振る舞いは進行を妨げたり、エスカレーションによる頻繁な混乱につながります。

状況

• コントリビューションを受け入れる側のチームによって生み出されたコンポーネントを、コントリビュートした側のチームが使えるかどうか、それは他のチームが受け入れてくれるかに依存してしまいます。

• 受け入れる側のチームが、コントリビュートされたコンポーネントや機能に対するリソース・知識・許可を持っていないか、もしくは(それに加えて) それらのコンポーネントや機能を自分自身で書く意欲がない場合があります。

組織に働く力学

• 過去に不正行為があったため、コントリビューションに対する不信感があります。例として、チームは中途半端にしたコントリビューションを提供し、その後に本番で使えるように修正するよう要求してきました。

• チーム外からコードを提供された場合、他のチームはチームの期待に沿うようなコードの書き方を知らないのではないかという疑念を持つことは自然なことです。

• 各チームは、自分のリーダーが目標を達成するための活動を第一に考えます。この忠誠心の方向性が、この問題の解決を複雑にすることがあります。

• 自分で書いていないコードに責任を持つことに抵抗があることは自然なことです。

• コントリビュートされたものは、コードベースに受け入れる前に大きく書き換える必要があります。

• コントリビュートした後、バグフィックスなどのサポートが受けられなくなる恐れがあります。

• コントリビュートされたコードが高いメンテナンスコストにつながることを恐れているが、それをどのように管理すればよいのかわかりません。

• 受け入れ側のチームは、他の人にコードを提供する方法を教えることで、自分たちのシステムの技術的負債が露呈し、それによって損害が発生することを恐れています。

• 受け手のチームは、いくら指導しても納得のいくコードが得られるとは思っていないかもしれません。

• どちらのチームも、リスクを測定したり、コントリビューションの中でリスクが軽減されていることを証明することに自信を持てないかもしれません。例えば、システム自体がややもろいなどの理由が挙げられます。(テストが完全でなかったり全ての問題を拾いきれてないかもしれません。）

解決策

コントリビュートしたコードが本番稼動した時点から 30日の保証期間 を設けることで、受け入れた側とコントリビュートした側の双方の不安に対処します。この保証期間中、コントリビュートしたチームは受け入れたチームにバグフィックスを提供することに同意します。

なお、保証期間は45日、60日、100日のいずれでもかまいません。この期間は、プロジェクトの制約、プロジェクトのソフトウェアライフサイクル、顧客との約束事項、その他の要因に基づいて変化される可能性があります。

さらに、受け入れ側のチームとコントリビュートする側のチームの期待値を明記した、明確なコントリビューションのガイドラインを提供することも役に立ちます。

結果の状況

• 受け入れ側のチームがコントリビューションを受け入れ、初期適応/修正の作業負担を分担することができます

• 透明性と公平性が高まります

• エスカレーションが重荷になりすぎないようになります

事例

• これは PayPal で試みられ、成功したことが証明されています。

• GitHub は社内でこのパターンを使っており、6週間という修正された保証タイムラインを使っています。

• Microsoft はこのパターンを原則として推奨しています。チームは自分たちのニーズと自信にマッチするよう具体的な時間目標を設定します。

著者

• Cedric Williams

謝辞 (Acknowledgment)

• Dirk-Willem van Gulik

• Padma Sudarsan

• Klaas-Jan Stol

• Georg Grütter

ステータス

• Structured

• Drafted at the 2017 Spring InnerSource Summit; reviewed 18 July 2017.

同種の例

• 複数の、功績至上主義的に任命されたトラステッドコミッターが責任を持つことで、依存するチームの協力をコミュニティ化することで保証する。

翻訳の履歴

• 2022-05-26 - 翻訳 Yuki Hattori

• 2023-06-18 - 最終更新

Title

インナーソースポータル

Patlet

潜在的なコントリビューターは、彼らが興味を持っているインナーソースプロジェクトを簡単に見つけることができません。すべての利用可能なインナーソースプロジェクトの情報をインデックス化するイントラネットのウェブサイトを作成することにより、あなたはコントリビューターが彼らに興味があるかもしれないプロジェクトについて知ることができ、インナーソースプロジェクトのオーナーは、外部のオーディエンスを引き付けることができます。

問題

インナーソースプロジェクトチームは、外部からのコントリビューションを集めることが難しいと感じています。

あなたの組織のインナーソースプロジェクトは増えているものの、潜在的なコントリビューターにとって、それらのプロジェクトを見つけるための簡単な方法がありません。

ケーススタディ

あなたは、組織内のインナーソースプラクティスを確立しようとしています。 あなたは、いくつかのプロジェクトがインナーソースモデルを使用して運用されていることを知っていますが、それらの存在は、他の社員の口コミ、電子メールまたは立ち話を介してのみ伝達されています。 結果としてインナーソースプロジェクトのオーナーは、コントリビューターを引き付けることに困難を感じています。

現在、組織全体の従業員がアクセスできる単一の共有リソースはなく、進行中のすべてのインナーソースプロジェクトを簡単に見つけることはできません。このことは、すべてのインナーソースプロジェクトの成長の可能性を大幅に制限しています。

すべてのインナーソースプロジェクトが、できるだけ多くのオーディエンスにビジビリティを発揮し、組織全体のコントリビューターを引き付けるためには何ができるでしょうか？

状況

• あなたの組織は、インナーソースワークスタイルを採用することに興味を持っています。

• インナーソースプロジェクトのオーナーは、彼らのプロジェクトにオーディエンスを引き付けるための方法を探しています。しかし、潜在的なコントリビューターに宣伝するために利用できる通信チャネルはなく、活動が制限されてしまっています。

• あなたの組織でインナーソースプロジェクト自体は増加しています。

• この問題をさらに深刻にしているのは、使用されている共有ソース管理アプリケーションの検索機能が非常に限られているためです。インナーソースプロジェクトを探すのに慣れた開発者でさえ、その場所を特定するのに苦労しているという事実です。

前提条件

• マネージャーは、従業員がインナーソースプロジェクトに参加することを暗黙の了解としています。

• ホストするリポジトリのコンテンツは共有ソース管理システムによって提供されていますが、プログラムによるアクセス制限がついています。

• 組織内にインナーソースコラボレーションの促進を担当する部門があります。

組織に働く力学

• 別々のエンジニアリングチームが、共通の課題に対してパートナーとして取り組むことのポテンシャルが十分に発揮されていません。

• インナーソースプロジェクトが存在することを、個人が知ることは困難になっています。

• インナーソースプロジェクトのオーナーが外部のコントリビューターを引き付けることは困難です。

ソリューション

インナーソースプロジェクトのオーナーがプロジェクトの利用可能性を簡単に宣伝できるインナーソースポータルイントラウェブサイトを作成します。

ポータルの主要な内容は次のとおりです。

• インナーソースポータルにアクセスした人は、すべての利用可能なプロジェクトを見るだけでなく、プロジェクト名、使用中の技術、コントリビューター名、スポンサー事業部などの様々な条件に基づいて、特定のプロジェクトを検索することができるようになっています。

• インナーソースポータルを通じて表示される情報は、常にインナーソースプロジェクトのオーナーの完全な制御下にある必要があります。プロジェクトリポジトリ自体に格納されている特定のデータファイルまたはメタデータから直接この情報をソーシングすることによって実現されるのが好ましいです。

• プロジェクトのオーナーは、プロジェクト名、トラステッドコミッターの名前、簡単な説明とコードリポジトリまたは任意のサポートドキュメントへのリンクを含むそれらのデータファイル内のプロジェクトに関するすべての関連情報を含める必要があります。

• (*オプション)ほとんどの組織は、ポータルをイントラネットでのみ利用できるようにすることを選択しますが、いくつかの組織は、ポータルを公共のインターネット上で利用できるようにすることを選択しました。後者は、例えばブランディングや採用の目的で、ポータルにインナーソースのアプローチに関する追加情報を表示したい組織にとって興味深いものになるでしょう。

ポータルを立ち上げる際には、ポータル内に表示されるプロジェクトの数を増やすために、インナーソースのデータファイルやコードリポジトリへのメタデータの追加を促進するコミュニケーションキャンペーンを検討する必要があります。

インナーソースポータルの参考実装はGitHub上で公開されており、コントリビューションを受け付けています。これは、インタラクティブで使いやすい方法で、組織のすべてのインナーソースプロジェクトを一覧表示します。プロジェクトはGitHubの専用トピックを使って自己登録し、追加のメタデータを提供することができます。

結果の状況

• インナーソースポータルは、インナーソースプロジェクトのオーナーが組織全体のオーディエンスにプロジェクトを広告することが可能になりました。ビジビリティがあがったため、彼らはこれまで以上に大きなコントリビューターのコミュニティを惹きつけています。

• インナーソースプロジェクトに参加したい人のために、インナーソースポータルは、社員が特定の条件に基づいてすべての利用可能なインナーソースプロジェクトを横断検索することによって、興味を持っている種類を正確に発見することを可能にしました。

• インナーソースプロジェクトへの参加を検討している場合、インナーソースポータルでは、特定の基準に基づいて利用可能なすべてのインナーソースプロジェクトを一度で検索することにより、関心のある機会の対象を正確に見つけることができます。

• これらの両方のニーズを満たすことで、組織のすべての領域において個別に実現できないことを一緒に達成するために活用できる魅力的な手段として、インナーソースを確立するのに役立ちました。

事例

• 大手金融サービス組織は、異なるビジネスユニット間で存在するインナーソースプロジェクトを宣伝し、発見する仕組みを提供するためにインナーソースポータルを使用しています。

• SAPはインナーソースポータルでインナーソースプロジェクトを推進しています。 プロジェクトはGitHubトピックを使用して自己登録することができます。リポジトリアクティビティスコア は、ポータル内のインナーソースプロジェクトのデフォルトの順序を定義しています。 また、SAP における事例はこちらもご参照くださいMichael Graf & Harish B (SAP) at ISC.S11 - The Unexpected Path of Applying InnerSource Patterns。 コードベースはリファレンス実装 として公開されており、コントリビューションのためにオープンになっています。

• Elbit Systemsはこのパターンを使い、さらにゲーミフィケーションを上乗せしています。

  • 文化変革の手段としてのゲーミフィケーションとインナーソースのエンゲージメントブースター | Shelly Nizri | OSCON 2018 - Portland, Oregon

  • Of Islands, Monsters & InnerSource (slides), (video) | InnerSource Spring Summit 2019 (Galway, Ireland)

  コードはオープンソース化されており、gitlab.com/gilda2にて公開されています。

• アメリカン航空は、インターナルインナーソースマーケットプレイスを介してInnerSourceプロジェクトを推進しています。SAPと同様に、プロジェクトはGitHubのトピックとして innersource を追加することで自己登録されます。プロジェクトは、言語、トピック、オープンイシューの数などで検索やフィルタリングが可能です。

• Banco Santander社は、インナーソースをサポートして増やすために、Santander ONE Europe InnerSource Communityという公開ポータルを作成しました。このポータルには、プロジェクトのカタログに加え、ドキュメント、仕事の進め方、ニュース、イベントなどの関連コンテンツが含まれています。

リファレンス

• インナーソースポータルパターンはインナーソースギグマーケットプレイス のパターンと一緒に使うと非常によく機能することが証明されています。

ステータス

• Structured

著者

• Stephen McCall

謝辞

• Shelly Nizri

• Melinda Malmgren

• Michael Graf

• Jesús Alonso Gutierrez

翻訳の履歴

• 2022-06-06 - 翻訳 Yuki Hattori

• 2022-06-13 - レビュー @kanazawazawa

• 2023-06-18 - 最終更新

Title

インナーソースライセンス

Patlet

同じ組織に属する2つの法人は、ソフトウェアのソースコードを互いに共有したいと考えていますが、法的責任や会社間の会計処理の観点からの影響を懸念しています。

インナーソースライセンスは、組織内でソースコードを共有するための再利用可能な法的枠組みを提供します。これにより、新しいコラボレーションの選択肢が広がり、関係する法人 の権利と義務が明確になります。

問題

組織内の2つ以上の法人が互いにコードを共有したい場合、条件についての合意が必要であり、多くの場合で法的契約が必要になります。プロジェクトごとにこのような契約を作成するには手間がかかり、それは共有における障壁になってしまいます。たとえば、ある法人のチームは複雑そうだからという理由で、組織内の別の法人とソースコードを共有しないことに決めるかもしれません。

共有における障壁は、組織の複数で同様のソリューションを再構築する際のサイロ化と車輪の再発明につながる可能性があります。

ソースコードを共有する時点では、共有の価値を確実に予測することはできません。共有の活動に(使用条件の交渉などの)多大な労力が必要な場合、法人は投資に対する収益率を懸念しているため、一連の活動を行う可能性は低くなります。

状況

• コードを共有したい大量の子会社を持つ大組織。組織が大きくなればなるほど、このパターンの価値は高くなります。

• 定義によると、法人は独自の法的権利と義務を持っています。

• 複数の法人はソフトウェアを開発しており、他の法人のサービスを使用しています。彼らには、お互いのソースコードに貢献する動機があります。

• 組織とその組織構造は十分に複雑です。

組織に働く力学

• 特に、技術、法律、ビジネスの観点を考慮する必要がある場合、正式な契約書を書くのに必要な労力のレベルがあります。

• 大きな組織(特に多くの法人から成る組織)には、多くの内部規制があります。新たに締結される契約は、セキュリティ、プライバシー、調達プロセスなど、これらの規制に準拠しなければなりません。規制が多いため、特に標準的な手順がない場合、2つの法人間でソフトウェアを共有することについてこれらの規制に準拠しているかどうかを評価することが困難になる場合があります。

• 組織内のいずれかの法人が、独占的なコードと組織内のライセンス料の会計処理に依存する ビジネスモデル を有している場合があります。

• インナーソースのコラボレーションとソースコードの共有に企業文化が慣れていない場合があります。これは、共有ソースコードを使用する場合の権利と義務についての不確実性をもたらします。

• ソフトウェアの使用を自由にすることが、競争と所有権の拡大につながります。

• ソースコードの共有に関する事項を含む法的なルールが存在します。しかしこれらのルールは標準化されていないため、プロジェクトごとに交渉と理解のための追加的な労力が発生します。また既存の契約では、真のインナーソースのアプローチをサポートするために十分オープンな意味でのソースコードの共有ができない場合があります。

• あるいは、法的な契約は結ばれていないものの、ソースコードが非公式に共有されている場合もあります。その場合、所有権や権利・義務の明確化が必要なケースにおいて不確実性が生じるかもしれません。

ソリューション

対象組織(およびその法人)のニーズに合わせてカスタマイズした インナーソース ライセンス を作成します。このライセンスは、最も重要な企業間関係に適用できるような汎用的なものである必要があります。

インナーソース ライセンスは、関係する法的実体の境界を越えて、本当にオープンソースのような共同作業を可能にするように書くことが重要です。したがって、フリーソフトウェアの4つの自由(*)は、ライセンスに統合されるべきです。

このライセンスは正式な法的文書として書かれており、コード共有契約を管理するために法人間の契約の一部として使用することができるようにします。

(*「4つの自由」の補足: 使用する自由, 変更する自由, 共有する自由, 変更したソフトウェアを再配布する自由)

結果の状況

インナーソースライセンスにより、組織内の法人間でコードを共有するためのツールを手に入れることができます。

このライセンスは、ソースコードの共有に関する組織内の会話を簡素化し、法人が最初に使う動機づけにもなっています。

注: 事例で説明されている実験は初期段階にあります。したがって、しっかりとした結果の状況はまだ形成されていません。数ヶ月後には、この問題に対するインナーソースライセンスの効果がより明確になり、このセクションは更新されるでしょう。

事例

DB 社の中で最初の法人(企業) は、このインナーソース ライセンスを使用しています。

すでに現れているポジティブな効果のひとつは、特に関係者の中にまだインナーソースのコンセプトをよく知らない人がいる場合、会話がシンプルになることです。ライセンスはよく知られた概念なので、インナーソースライセンスがあることは、議論のきっかけになります。

この実験では、真のインナーソースのコントリビューションとコラボレーションモデルにつながるために解決しなければならない、さらなるコラボレーションの課題があることも明らかになりました。

その課題とは、以下のようなものです。

• インナーソースのライセンスプロジェクトを発見できるようにする

• オープンソースのように、プロジェクトでコラボレーションするためのコミュニティを構築すること。

これまでのところ、このインナーソースライセンスの下で共有されるソフトウェアは、ほとんどがツール、インフラ、およびスタックの下位にあるツールであることは言及に値します。

ステータス

• Structured

• 事例に記載されている実験は、2020年2月から実施されています。最初の経験では、最初のポジティブな効果を示していますが、パターンを完全に評価するためには、より多くの経験が必要になります。

著者

• Cornelius Schumacher (DB Systel GmbH)

• Schlomo Schapiro (DB Systel GmbH)

• Sebastian Spier

リファレンス

単語の解説

• 組織 - 複数の企業の母体(同義語: グループ、ホールディング、エンタープライズ) (例: Microsoft Corporation)

• 法的エンティティ - 独自の法的権利と義務を有するエンティティ (同義語: グループ子会社、子会社、関連会社) (例: Microsoft Japan, GitHub, LinkedIn)

翻訳の履歴

• 2023-06-18 - 最終更新

Title

ギグマーケットプレイス

Patlet

イントラネットのウェブサイトを作成し、特定のインナーソースプロジェクトのニーズを、時間とスキルの要件を明示した「ギグ」としてリストアップすることで、マーケットプレイスを確立する。 これにより、管理者がインナーソースのコントリビューションを行うための承認を与え可能性が増え、従業員の時間のコミットメントと専門的な利点をよりよく理解することができます。

問題

マネージャーも従業員も、インナーソースプロジェクトに参加することでどのように利益が得られるかを理解していません。

従業員がインナーソースプロジェクトに対してどのような時間を費やす必要があるかを経営陣に伝えることは困難です。

マネージャーには、インナーソースプロジェクトへの従業員の関与を追跡したり報酬を与えたりするための統一された方法がありません。

ケーススタディ

あなたは、会社でインナーソースプログラムを成功させ、上級管理職、中間管理職、開発者から賛同を得ています。 しかし、約1年後、最初にそれらを作成したチーム以外の任意のインナーソースプロジェクトに行われた実際のコントリビューションはほとんどありませんでした。 関係者にヒアリングしたところ、インナーソースプロジェクトに参加する場合、開発者がどの程度の時間を割く必要があるのか、また、個人的にどのようなメリットがあるのかが分かりにくいことが主な原因であるようです。また、貢献者のためのどのような機会が存在し、彼らは何をするように求められてもおおよその時間を示すための統一された方法がありません。管理職は協力的で、従業員が参加することを望んでいますが、これまでのところ、インナーソースプロジェクト内の従業員の活動のための会計処理や報酬の方法が欠けています。 すべての関係者（インナーソースプロジェクトの所有者、潜在的な貢献者と開発マネージャー）のためにこの状況を改善するには何ができるのでしょうか？

状況

社員は、現在のポジションを離れることなく、会社の他の領域で行われている活動に触れることができればと願っています。しかし、インナーソースのプロジェクトには、社員の参加を阻む2つの要因があります。まず、現在進行中のインナーソースプロジェクトにどのような貢献の機会があるのかを容易に発見し、上司に伝えることができないこと。 つぎに、マネージャーがこれらのインナーソースプロジェクトタスクに対する従業員の時間的コミットメントを計画および説明できないことです。その結果、インナーソースプロジェクトのオーナーは、彼らの目標を達成するために十分な規模のコミュニティを構築することができません。

組織に働く力学

• 社員にはインナーソースのチャンスを見つける簡単な方法が用意されていません。

• 社員は、貢献が専門的にどのように役立つかを理解していません

• マネージャーは、インナーソースプロジェクトに関連するタスクにかかる時間/労力の要件を理解していません

前提条件

• 従業員は、マネージャーからインナーソースプロジェクトに参加する時間を提供されています。

• マネージャーは、インナーソースのコントリビューションを定量化、追跡、記録して、説明と報酬を得る方法を必要としています。

ソリューション

個人が自分のスキルや興味のある分野を示すことができ、インナーソースプロジェクトのオーナーがコラボレーションのための機会を宣伝することができます "ギグ" ベースのイントラネットサイトを作成します。

従業員は、アプリケーション内に自分のスキルと関心のある分野をリストできるプロファイルを作成できる必要があります。システムは、これらの基準の1つ以上に一致するギグが投稿されたときに、(電子メールまたはその他の手段を介して)個人に積極的に通知することにより、この情報を活用することができる必要があります。

インナーソースのプロジェクト・オーナーが投稿する各ギグには、スキルや時間の要件が含まれており、稼働可能な従業員と簡単にマッチングでき、直属の上司に明確に伝えられるようになっていなければなりません。説明は、可能な限り魅力的なようにするために、タスクを引き受ける人にどのように役立つかについての理論的根拠を含める必要があります。

従業員のギグへの関与を評価し、追跡するために、ポイントベースのシステムを作成することができます。 例えば、完成したギグを投稿するとギグのオーナーに10ポイント、ギグを完成させた開発者には100ポイントを付与するなどの仕組みを適用します。ギグを完了することで得られるポイントは、ゲーミフィケーションの仕組みとして、また、組織内に存在する専門分野を把握するためのパフォーマンス管理の基準として利用することができます。

ギグを受けたい人は、まずギグの所有者が、その従業員がギグを完了するために必要なスキルと割り当てられた時間を有しているかどうかを判断する必要があります。

ギグを通じたコントリビューションの透明性は、コントリビューターの評判を高め(あるいは下げ)、コントリビューションの質が高くなる可能性を高めるのに役立ちます。 また、ギグを完成させることで、その分野の専門性を証明することができます。

マーケットプレイスに投稿されるギグの内容は、グループイベントの運営、レポートの作成、メンターへの依頼など、ハードスキル、ソフトスキルの両方を含むことができます。

ギグマーケットプレイスの構築は、全社的なインフラと機能を提供する責任を持つ組織内のチームによって行われることが理想的です。

結果の状況

インナーソースギグマーケットプレイスは、インナーソースのプロジェクトの数だけでなく、それに関わる社員の数も大幅に増加させます。 ギグマーケットプレイスの自主的な性質は、社員が実行する作業のレベルを選択し、会社全体でパートナーとなることができるようにすることで、社員の仕事の満足度を高めています。 社員は、自分が何にサインアップしているか、そしてその経験から何を期待できるかを正確に理解することができます。 マネージャーは、インナーソースプロジェクトに関する従業員の時間的コミットメントをより適切に推定および追跡し、個々の取り組みを認識し、特定のスキルセットを検証する方法としてギグの成果を使用することができます。 またマネージャーは、社員がギグマーケットプレイスで利用可能な仕事にピボットできるようにすることで、従業員が経験しているかもしれない既存のダウンタイムを活用することができます。 ギグマーケットプレイスでのやり取りによって生成されたデータは、すべての部署で雇用とトレーニングの決定を促進するのにも役立っています。

インナーソースポータルのパターンと組み合わせて使用すると、ギグマーケットプレイスは、ギグが関連するプロジェクトのコードリポジトリとドキュメントへのリンクに加えて、より細かいレベルのコンテキストと詳細を提供することができます。

事例

• 大手金融サービスの組織は、インナーソースプログラムを育成するためにインナーソースギグマーケットプレイスのウェブサイトの作成をしました。

• SAP はギグマーケットプレイスパターンを実装しました - 新しいインナーソースプログラムは、ポジションと同様の提供を掲載することができ、内部のジョブプラットフォームに追加されています。

ステータス

• Structured

# 著者

• Stephen McCall

• Shreyans Dugar

翻訳の履歴

• イントロダクション

• 目次

• パターンの一覧

• この本へのコントリビューション

パターン

• 30日の保証期間 - 自分のチーム以外からのコントリビューションを受け入れる場合、チームが書いていないコードの責任を持つことに抵抗があることは自然なことでしょう。 「30日の保証期間」プラクティスを利用すると、コードにコントリビュートしたチームはコードを受け取ったチームに対してバグフィックスを提供することを承諾することになります。 そうすることで、両チーム間の信頼度が高まり、コントリビューションが受け入れられる可能性が高くなります。

• RFCを用いたチーム横断的な意思決定の透明化 - 高い参加率を達成し、関係者全員にとって最良の意思決定を行いたいインナーソースプロジェクトは、ソフトウェアのライフサイクル全体を通して参加型のシステムを構築する方法を見つける必要があります。内部のRFC(Requests for Comments)ドキュメントを公開することで、設計プロセスの早い段階から議論を行うことができ、関係者全員が高いコミットメントを持ってソリューションを構築できる可能性が高まります。

• イシュートラッカーの使い方を多様化する - インナーソースのホストチームは、計画や進捗だけでなく、変更の背景も透明化することができていません。これは、プロジェクトのイシュートラッカーのユースケースを増やし、ブレーンストーミング、実装の議論、機能設計にも使えるようにすることで解決することができます。

• インナーソースポータル - 潜在的なコントリビューターは、彼らが興味を持っているインナーソースプロジェクトを簡単に見つけることができません。すべての利用可能なインナーソースプロジェクトの情報をインデックス化するイントラネットのウェブサイトを作成することにより、あなたはコントリビューターが彼らに興味があるかもしれないプロジェクトについて知ることができ、インナーソースプロジェクトのオーナーは、外部のオーディエンスを引き付けることができます。

• インナーソースライセンス - 同じ組織に属する2つの法人は、ソフトウェアのソースコードを互いに共有したいと考えていますが、法的責任や会社間の会計処理の観点からの影響を懸念しています。

• ギグマーケットプレイス - イントラネットのウェブサイトを作成し、特定のインナーソースプロジェクトのニーズを、時間とスキルの要件を明示した「ギグ」としてリストアップすることで、マーケットプレイスを確立する。 これにより、管理者がインナーソースのコントリビューションを行うための承認を与え可能性が増え、従業員の時間のコミットメントと専門的な利点をよりよく理解することができます。

• クロスチームプロジェクト評価 - 会社の収益に直接的な影響を提供していないクロスチームのインナーソースプロジェクトの価値を評価して社内に売り込むことは困難です。 ここでは、あなたのプロジェクトの価値を明確に表現し、それを大きくするためのデータ駆動型の方法を紹介します

• コアチーム - インナーソースのプロジェクトが広く必要とされていても、プロジェクトが難しいためにコントリビューションや活用に支障をきたす場合があります。プロジェクトの基本的な項目を専門に担当するコアチームを設立してください。コアチームの作業により、コントリビューターは自分のシナリオに価値をもたらす機能を追加し、使用することができます。

• コミュニケーションツーリング - インナーソースのプロジェクトは、開発チームの外で使用されていますが、ユーザーはヘルプを得たり、プロジェクトチームと連絡を取ったりするのに苦労しています。 このアイデアは、ディスカッションが可視化され、アーカイブされ、検索可能になることを可能にする標準的なコミュニケーションツールを設定し、文書化することです。

• コントラクトコントリビューター - インナーソースにコントリビュートしたい社員がいますが、彼らの直属の上司はその活動に抵抗を示しています。正式な契約と合意をすることによって救済することができるかもしれません。

• コントリビューションの功労を称える - インナーソースのコントリビューションの後、その時間と努力に対してコントリビューターに感謝することは重要です。 このパターンは、コントリビューションを効果的に認めるだけでなく、コントリビューターや他の人たちのさらなる関与を引き出すためのガイダンスを提供します。

• サービス対ライブラリ - DevOps環境のチームは、サービスのダウンタイムに対応する責任が誰にあるのかが曖昧になるため、チームの境界を越えて共通のコードベースで作業することに消極的になる場合があります。解決策としては、同じサービスを独立した環境で展開し、サービスダウン時のエスカレーション・チェーンを別々に構築するか、多くの共有コードを1つのライブラリに集約し、その上で共同作業を行うことが挙げられます。

• スタンダード・ベース・ドキュメンテーション - インナーソースプロジェクトへの新しいコントリビューターは、誰がプロジェクトを維持し、何に取り組み、どのようにコントリビューションすればよいかを理解するのに苦労しています。README.md/CONTRIBUTING.md のような標準ファイルでドキュメントを提供することで、新しいコントリビューターのためのセルフサービスなプロセスを可能にし、よくある質問に対する答えを自分自身で見つけることができるようにします。

• トラステッドコミッター - 多くのInnerSourceプロジェクトは、コントリビューターからフィードバック、機能、バグフィックスを一貫して受け取る状況にあります。このような状況で、プロジェクトのメンテナーは、単一のコントリビューションを越えてコントリビューターの仕事を認識し、報酬を与える方法を模索します。

• リポジトリアクティビティスコア - 潜在的なコントリビューターは、彼らの助けを必要とするアクティブなインナーソースプロジェクトを見つけたいと思っています。各プロジェクトのリポジトリのアクティビティスコアを計算することで、プロジェクトのランク付けされたリストを作成することができます (参考: インナーソースポータル )、そのため、潜在的コントリビューターは、彼らがコントリビュートしたいプロジェクトをより簡単に決定できます。

• レビュー委員会 - インナーソースの作業モデルは、開発者と管理者のための、より伝統的なアプローチからの抜本的な変革です。インナーソースイニシアチブとそれに参加するビジネスユニットのすべてのシニアマネージャーの間のインタフェースとしてレビュー委員会を確立することにより、マイクロマネジメントを助長することなく、監視と制御の一定レベルを与えるように、イニシアチブに慣れ親しみ、それをサポートできるようになる可能性が高くなります。

• 共通要件 - 共有リポジトリにある共通のコードは、それを使いたいすべてのプロジェクトチームのニーズを満たしていません。これは、要件の調整とリファクタリングによって解決されます。

• 基本原則ガイダンスの文書化 - 「オープンソースのベストプラクティスを組織内に適用する」という通常のインナーソースの説明は、オープンソースのバックグラウンドがない人々にはうまく機能しません。 解決策として、インナーソースの最も重要な原則を文書化し広く公開しましょう。

• 実験として始める - インナーソースイニシアチブを期間限定の実験として開始し、インナーソースに慣れていないマネージャーがイニシアチブを承認およびサポートしやすくします。

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

• 持続可能な成長のためのエクステンション - インナーソースプロジェクトは多くのコントリビューションを受けており、メンテナンスが難しくなっています。メンテナは、プロジェクトのコア部分から離れた拡張機構を提供することで、最小のコストとメンテナンスオーバーヘッドでプロジェクトの能力をスケールアップすることを可能にします。

• 正式なコミュニティリーダー - インナーソースの取り組みを成功させるために、コミュニケーションとテクニカルの両方のスキルを持つ人をコミュニティのリーダーとして選ぶ。

付録

• パターンテンプレート

• その他

  • README テンプレート

  • CONTRIBUTING テンプレート

リソース

• GitHub

• InnerSource Commons

この本をもっと良くしたいですか？ 素敵ですね、やりましょう！

インナーソース・パターンブックはですので、どんな形でのコントリビューションでも、そしてどんな些細なことでもかまいません！ 文法やスペルの修正やデザインの改善から、あなたの職場で行われたインナーソースの経験に基づいた全く新しいパターンの提案まで、私たちはどんなコントリビューションでも喜んで歓迎します！ あなたがオープンソースプロジェクトにコントリビュートしたことがない場合でも大丈夫ご心配なく。インナーソース・パターンのコミュニティはフレンドリーな人々のグループですので、コントリビュートするのに安全な場所です。

始める前に

インナーソース・パターンとこの本のソースは、GitHub のリポジトリで保管されています。そのため、この本の編集や提案を行うには、GitHub のユーザーアカウントが必要です。もしまだそれを持っていないなら、 で無料のアカウントを作成してください。

コントリビュートするさまざまな方法

ここでは、あなたがコントリビュートできるいくつかの方法を紹介します。

1. この本で気づいたスペルやフォーマットなどの不具合を修正する

2. 既存のパターンの内容を改善する（例えば、 既知の例 としてパターンを使用している方法についての短い説明を追加する）

3. 新しいパターンを投稿し、あなたの組織でインナーソースに関する課題をどのように克服したかを説明する

上記の(1)と(2)については、本書の各ページの上部にある Edit on GitHub のリンクを押すだけです。この操作では、私たちの GitHub リポジトリ内のそれぞれのファイルに直接移動し、各ページであなたの変更を提案することができます。

(3) については、 リポジトリをクローンし、あなたの提案するパターンを新しいファイルに追加する必要があります。このような大きなコントリビュートする場合は、私たちの と を確認してください。

コントリビューションにかかるライセンス

このリポジトリのコンテンツは の下でライセンスされています。このリポジトリにコントリビュートすることは、私たち(そして他のすべての人)に対して、このライセンスに従ってあなたのコントリビューション物を使用する権利を与えることになります。

翻訳の履歴

とても素晴らしいことに、インナーソース・コモンズのコミュニティから、どんどんパターンが寄稿されています！

さて、ではどのように特定の自分の状況に役立つパターンを読者は簡単に見つけられるでしょうか？ そこで私たちはこのマインドマップを提供します。このマインドマップは、インナーソースプログラムのさまざまなフェーズと、それぞれのフェーズで現れる可能性のある課題に基づいてパターンを分類しています。

このマインドマップを改善する

リファレンス

翻訳の履歴

Title

イシュートラッカーの使い方を多様化する

Patlet

インナーソースのホストチームは、計画や進捗だけでなく、変更の背景も透明化することができていません。これは、プロジェクトのイシュートラッカーのユースケースを増やし、ブレーンストーミング、実装の議論、機能設計にも使えるようにすることで解決することができます。

問題

あるチームが、組織内の多くのチームが依存するコンポーネントを開発しています。このチームは、未解決のバグや機能要求を追跡するために、標準的なイシュートラッキングシステムを使用しています。しかし、各エントリのコンテキストは非常に限られています。その結果、潜在的なコントリビューターは、各課題がどのような変更について話しているのかを知る術がありません。

状況

インナーソースのプロジェクトツールはすべてセットアップされています。しかし、プロジェクトのイシュートラッキングシステムは、主に進捗の共有のために使用されます。インナーソースプロジェクトでは、リモートでの非同期通信を容易にするために、イシュートラッカーが使用できるユースケースは他にもたくさんあります。

組織に働く力学

• コントリビューターは、自分たちが必要としている機能がすでにロードマップにあるかどうかを理解したいと思っています。しかし、イシューには多くの文脈が欠落しており、既存のイシューがコントリビューターのニーズに合致しているかどうかを判断することは不可能です。

• その結果、多くの重複したイシューがオープンされ、ホストチームがそれに対処しなければならなくなります。

• オープンなイシューの文脈は非常に限られているため、コントリビューターはすでにオープンになっている簡単なイシューを実装して、ホストチームを助けることができません。その結果、多くの作業がホストチームの手に委ねられることになります。

• 口頭でのコミュニケーションに重点を置いているため、数ヶ月後や数年後に、なぜとある機能が実装に選ばれたのかを見極めることができません。その結果、リファクタリング、特にコンポーネントの簡略化は、プロジェクト考古学そのものとなり、議論されたことを覚えている人たちの脳を巻き戻して考えるしかなくなります。

ソリューション

純粋なソフトウェア開発だけでなく、新機能の企画段階でも「言葉より文字」の哲学を受け入れましょう。

• バグ、計画された機能、機能のアイデアについては、それぞれ別のイシューを作成します。それぞれのイシューには、外部の潜在的なコントリビューターが文脈を理解できるように、可能な限り多くの情報を含めるようにします。理想的には、特に簡単な変更については、外部のコントリビューターが問題の機能を実装することでホストチームをサポートできるよう、十分な情報を含めることです。

• 質問するためのチャネルとして、イシュートラッキングシステムを利用することができます。これは、ユーザーの質問に対応するための他のコミュニケーション源が不足している場合に、特に有用です。

• 異なる目的で使用されるイシューを区別するために、タグやカテゴリーを使用します。

• 非同期でブレーンストーミングを始めるには、アイデアを集めるためにイシューを開きます。議論が落ち着いてきたら、このイシューで指摘されたことを別の文書にまとめます。それをプルリクエストとして投稿し、まだ説明が必要な個々のポイントについて掘り下げます。出来上がった文書は、他の適切なチャンネルで結果を公表したり、将来の参考資料として使用したりすることができます。

• ほとんどのイシュートラッキングシステムで、イシューのテンプレートを作成することができます。バグレポートに必要な情報を集めるだけでなく、他の用途でどのような情報が必要なのかのヒントも含めて活用しましょう。

結果の状況

• プロジェクトのイシュートラッキングシステムをコミュニケーションに活用することで、外部のコントリビューターがプロジェクトの動向を把握し、何をコントリビュートすべきかをより的確に判断することができるようになります。

• 文書によるコミュニケーションに重点を置くことで、ホストチームのメンバーがリモートで参加できるようになった。

• 常に文書でコミュニケーションすることで、プロジェクトの決定事項に関する受動的な文書が副産物として蓄積され、特別な注意を必要としなくてすみます。

• 公開コミュニケーションチャネルを一貫して使用することで、より多くの人間が議論に参加することになります。つまり、質問に答えたり、未解決の問題を指摘したり、計画中の機能の欠点を指摘したりできる、より多くの知識を持った人間を巻き込むことができるようになります。

• ディスカッションを公開の場に移すことで、将来のコントリビューターとなる可能性のあるメンバーがが、プロジェクトに参加する必要が生じるずっと前に、プロジェクトに潜り込み、フォローし、慣れ親しみ、プロジェクトのやり方を学ぶ機会を作ることができます。

事例

• Europace AG - ブログをご覧ください Issue Use Cases

著者

Isabel Drost-Fromm

ステータス

Structured

翻訳の履歴

• 2022-06-06 - 翻訳 Yuki Hattori

• 2022-06-13 - レビュー @kanazawazawa

Title

コミュニケーションツーリング

Patlet

インナーソースのプロジェクトは、開発チームの外で使用されていますが、ユーザーはヘルプを得たり、プロジェクトチームと連絡を取ったりするのに苦労しています。 このアイデアは、ディスカッションが可視化され、アーカイブされ、検索可能になることを可能にする標準的なコミュニケーションツールを設定し、文書化することです。

状況

チームは別のチームのコンポーネントに依存しており、そのコンポーネントにコントリビュートしたいと思いっています。コミュニケーションは文書で行われる場合でも、1対1で行われています。

問題

チームは、そのコンポーネントのダウンストリームユーザーからのコントリビューションを受け入れることができます。しかし、調整とコミュニケーションはアドホックな方法で行われ、支離滅裂な情報が共有されたり、回答が遅れたり、コントリビューターが明確な回答を受け取る前に複数のホストチームのメンバーに問い合わせをしたりすることがあります。

組織に働く力学

• ホストチームはコントリビューションを受けることに興味があり、コントリビューターを指導することに積極的です。

• チームは口頭でのコミュニケーション文化が強く、プロジェクト特有の非同期コミュニケーションチャンネルを設定する経験は浅いです。

• コミュニケーションチャネルは、連絡を取るべき特定のグループと連携しているかもしれませんが、コミュニケーションの目的によって連携しているわけではありません。

ソリューション

ホストチームは、社内で公開され、アーカイブされ、検索可能で、リンク可能なコミュニケーション・チャネルを提供することの利点を明確にする必要があります。

インナーソースプロジェクトのコミュニケーションチャネルを合理化する際の目標は、特定の人々の周りではなく、トピックの周りのコミュニケーションを調整することであるべきです。

• プロジェクトは、ホストチームのメンバーだけでなく、ダウンストリームユーザーやコントリビューターもフォローできるように、構造化されたコミュニケーション、意思決定、進捗追跡が透過的に行われる独自のイシュートラッカーを持っている必要があります。

• プロジェクトは、あまり厳密でない構造を持つ1つ以上のディスカッションチャンネルを持つべきです。一般的に、これはメーリングリスト、オンラインフォーラム、あるいはアーカイブされたチャットチャンネルになります。通常、プロジェクトのためのチャンネルは1つで十分ですが、トラフィックが増えすぎた場合は、プロジェクトの使用に関する議論とプロジェクトの開発に関する議論を分けることが有用です。

• さらに、プロジェクトはトラステッドコミッター の間で機密のやりとりができるプライベートチャンネルを一つ持つべきです - たとえば、ホストチームにさらにトラステッドコミッターを追加するなどです。このチャンネルは、デフォルトではオープンで、非常に稀な状況下でのみ非公開になるように、細心の注意を払って使用されるべきです。

文章での共有のチャンネル以外でもコミュニケーションは可能ですが、できるだけ多くの情報を非同期チャンネルにつなぐべきです。

すべてのコミュニケーション・チャンネルはプロジェクトの README.md で文書化されるべきです。ホストチームのメンバーは、個人的に受けた質問を公式のコミュニケーションチャンネルに戻すよう努力する必要があります。

結果の状況

公式の非同期コミュニケーションチャネルを設定し、一貫して使用することで、同様の質問が再び出てきたときに再び参照できる受動的なドキュメントのベースレベルを作成することができます。

コミュニケーションがオープンに行われることで、他の人も簡単にプロジェクトの進捗を追うことができ、積極的に貢献することができます。また、他の参加者が潜んで読んでいることで、参加するための障壁が低くなり、コントリビューションを受ける可能性が高くなります。

質問に対する回答が公開されることで、より多くの人が自分の視点を追加し、全体像を把握することができます。これは、ホストチームのメンバーだけでなく、プロジェクトのユーザーも含みます。

非同期チャネルでコミュニケーションをとることで、タイムゾーンや会議のスケジュール、チームのルーチンなど、異なるスケジュールの参加者がプロジェクトに有意義に貢献することができます。

このようなチャンネルで質問に答えることは、他のチームメンバーがそれを聞いて追加情報を提供できるだけでなく、同じ質問をした他のユーザーが前回の回答を見る(または後で見つける)ことで、説明を繰り返す必要性を低くすることを意味します。

事例

• Europace AG

• Paypal Inc.

著者

Isabel Drost-Fromm

ステータス

• Structured

• Drafted in December 2019.

翻訳の履歴

• 2022-06-06 - 翻訳 Yuki Hattori

• 2022-06-13 - レビュー @kanazawazawa

Title

コントリビューションの功労を称える

Patlet

インナーソースのコントリビューションの後、その時間と努力に対してコントリビューターに感謝することは重要です。 このパターンは、コントリビューションを効果的に認めるだけでなく、コントリビューターや他の人たちのさらなる関与を引き出すためのガイダンスを提供します。

問題

プロジェクトにコントリビュートしてくれたインナーソースのコントリビューターに対して、どのように感謝の気持ちを表せばいいのでしょうか? 感謝の気持ちを伝えることを忘れてしまったり、十分な効果や誠意を示すための言葉や場所がわからなくなってしまったりすることがあります。 賞賛と感謝は、楽しさやコントリビューターとそのマネージャーのモチベーションを維持し、継続するための簡単で使いやすい方法です。 このパターンがあれば、簡単に実行でき、メッセージが明確かつ誠実に伝えることができるようになります。

状況

• あなたはインナーソースプロジェクトの トラステッドコミッター あるいはメンテナーです。

• あなたは、コントリビューターのコミュニティを大切にし、それを維持・発展させたいと考えています。

組織に働く力学

• あなたは忙しいので、賞賛や感謝のようなソフトタッチを忘れがちです。

• あなたは、人付き合いが苦手だったり、口下手だったりするかもしれません。

• 仕事への満足度やキャリア開発には、仲間からの評価が非常に重要です。

ソリューション

他人から認められることは、誰にとっても気持ちの良いことです。 プロフェッショナルな場では、認知度の向上は、影響力や成長への道筋にもなります。 誰かがあなたのインナーソースプロジェクトにコントリビュートしたときはいつでも、誠実で適格な「ありがとう」の言葉でその人を認めてあげてください。

自明でないコントリビューション(すべてのコードコントリビューションと多大な時間的コントリビューション)に対しては、以下の方法でお礼を言いましょう。

(1) あなたがプロジェクト活動を組織しているチャットの場所 (例: Slack) で、その人の名前を呼びます。 その人が何をしたかを皆に知らせ、公に感謝します。

例 (意訳):

みなさん、@andrew.clegg が rcs-viewer を hebo-client の最新版 (https://github.com/rcs/rcs-viewer/pull/81) にアップデートしてくれました！ Andyさん、ライブラリを最新に保つ活動をお手伝いしていただきましてありがとうございます！！

(2) 彼らとそのマネージャー(cc'd)に、個人的にお礼のメールを送ります。 コードのコントリビューションでは、しばしばマージ通知メールを転送するだけでよい場合があります。

例 (意訳):

Andy さん、先日はアップデートを手伝っていただきまして本当にありがとうございました！ Andy さんの活動の中で修正していただいた rcs-viewer は、おかげさまでより良いものになり、組織の皆さんがその恩恵を享受しています。 お忙しい中とは存じますが、このような配慮があるからこそ、RCSプロジェクトは会社全体のために機能しています。 改めまして、誠にありがとうございます！

結果の状況

このようなフィードバックは、コントリビューターに素晴らしい気持ちを残し、また貢献しようと戻ってくることにもつながります。 仲間の前でも、直属の上司の前でも、幅と深さの両方の側面の感謝の言葉を組み合わせることで、認めてもらうことができます。 またその上司は、他の直属の部下に同じことをするよう促す適切な状況を模索します。 さらに、インナーソースプロジェクトの意識は、以前はチームの使用とそれとの関わりを知らなかったかもしれないマネージャーにも広がります。

一つ注意点があります。 あなたの言葉は、彼らがしてくれたことに対して、あなたが心の中で感じている心からの感謝からきていることを確認してください。 褒め言葉も、その人のレベルに合わせて冗長になりすぎないようにしましょう。 やり過ぎると、不誠実で機械的な印象を与え、せっかく声をかけた意味がなくなってしまいます。

類似パターン

• Just Say Thanks (Fearless Changeより)

事例

• Nike (multiple projects)

ステータス

• Structured

著者

• Russ Rutledge

謝辞

• Todd Lisonbee for encouraging to "keep it real".

• Isabel Drost-Fromm for this extra explanation of a "qualified" thank you.

翻訳の履歴

• 2022-06-06 - 翻訳 Yuki Hattori

• 2022-06-15 - レビュー @hirotakatoya

• 2023-06-18 - 最終更新

Title

サービス対ライブラリ

Patlet

DevOps環境のチームは、サービスのダウンタイムに対応する責任が誰にあるのかが曖昧になるため、チームの境界を越えて共通のコードベースで作業することに消極的になる場合があります。解決策としては、同じサービスを独立した環境で展開し、サービスダウン時のエスカレーション・チェーンを別々に構築するか、多くの共有コードを1つのライブラリに集約し、その上で共同作業を行うことが挙げられます。

問題

チームがDevOps環境で作業しているとき、開発者は機能をエンドツーエンドで担当することになります。顧客からデプロイメント、メンテナンス、サポートに至るまでです。このことは、チームの境界を越えて作業する際に課題となります。エスカレーションチェーンは、どちらのチームでも発生するエラーに対して同じではないかもしれません。ソースコードとデプロイメントを結合すると、エラーが発生した場合に誰がオンコールサポートの責任を負うのかという疑問がチームに残ります。その結果、要件に大きな重複がある場合でも、チームは協力し合うことに消極的になってしまいます。

状況

• チームはマイクロサービス環境で働いています。

• チームは完全に機能する DevOps チームによって編成されています。各チームは、メンテナンス、オンコール、カスタマーサポートを含むエンドツーエンドのコントリビューションに責任があります。

• あるチームは、他のチームが構築した既存のサービスとよく似たサービスを下流の顧客に提供することを任務としています。

組織に働く力学

• 組織的なエスカレーション経路は、各チームで異なる可能性があります。

• 各チームのメンバーは、自分たちの顧客に影響を与えないエラーのオンコールサポートに応じないことがあります。

• 同じ種類のエラーでも、チームや顧客との関係によって SLA の定義が異なるため、深刻度レベルが異なる場合があります。

• チームによって、セキュリティや規制の制約が異なる場合があります。

ソリューション

ソースコードとデプロイメントの責任を切り離します。両チームは、重複と相乗効果がある場所を正確に特定するために働きます。

共有されたソースコードのみが、責任を共有したインナーソースプロジェクトの一部として保持されます。共有ソースは、すべてのテストコード(可能であれば統合テストを含む)と、コントリビューションの検証を容易にするために可能な限りCIパイプラインを含むという点で、首尾一貫している必要があります。

設定とデプロイのパイプラインを、実際のビジネスロジックから切り離します。 共有したチーム用に、サービスの2つめのデプロイメントを確立します。

共通基盤を、両チームで使用するライブラリとして扱い、コードの所有権を共有します。

デプロイメント設定をインナーソースポートフォリオの別プロジェクトとして含めることで、チームが議論/共同作業を行ったり、新しいチームがそれをコピーしたりすることができるようになります。

結果の状況

チームは積極的に協力し、ビジネスロジックを実装する作業を共有することで利益を得ることができます。

ある環境で動作するように特別に構築されたサービスが、特定のビジネス要件に基づき、より一般的なソリューションに変換されます。

両チームは、それぞれのエスカレーションポリシーと展開設定を知ることができ、自分たちの設定に対する改善点を見出すことができる可能性があります。

共有されたソースコードに変更が必要な可能性が高まり、実装を改良、改善、最適化する機会がより頻繁に発生するようになる。

リリースのパッケージング、遠隔測定、ヘルス/レディネス エンドポイントなど、運用の標準化を段階的に進めることができるようになります。

その他の情報

このパターンに関連するものとして、上記を解決するために異なるアプローチをとる30日の保証期間 パターンがあります。

事例

• ユーロスペース AG

• Flutter Entertainment: Flutter インナーソースの応用には、チーム横断的にコントリビュートする共有コードの"サービスリポジトリ"と、共有リリース成果物をビルドして公開するためのCIパイプラインがあります。各チームは、独自のデプロイメントを定義する"デプロイメント設定"リポジトリを持っています。これは、さまざまな規制要件、サービスおよびインシデント管理の実践、ビジネスの各領域におけるインフラストラクチャのスキルセットによって異なる運用がされています。

ステータス

• Structured

著者

• Isabel Drost-Fromm

• Rob Tuley

謝辞

Tobias Gesellchenさん、Europace AGの内部レビューをありがとうございました。

その他の呼び方

サービス対ライブラリ: インナーデプロイメントではなくインナーソース

翻訳の履歴

• 2022-06-06 - 翻訳 Yuki Hattori

• 2022-06-13 - レビュー @kanazawazawa

• 2023-06-18 - 最終更新

Title

コントラクトコントリビューター

Patlet

インナーソースにコントリビュートしたい社員がいますが、彼らの直属の上司はその活動に抵抗を示しています。正式な契約と合意をすることによって救済することができるかもしれません。

問題

中間管理職によるサポートがなければ、コントリビューターの総数や、インナーソースイニシアチブによって生み出されたコントリビューションの量と価値は、トップレベルの経営陣の期待を下回る可能性が高いでしょう。これは、正式なコミュニティリーダー - Dedicated Community Leaderへの十分な資金提供や権限付与がない場合、さらに増幅される可能性が高くなります。 これでは、トップレベルの経営陣がインナーソースの活動やアイデアを放棄してしまう危険性があります。

状況

ある大企業が、インナーソースイニシアチブを開始しました。このイニシアチブの主な目標は、分散ソフトウェア開発の効率を高め、トピックやビジネスユニットに関係なく、すべての社員がインナーソースプロジェクトに自発的にコントリビュートできるようにすることで、イノベーションを促進することです。

トップレベルの経営陣は、インナーソースイニシアティブを支持し、ボード上にあります。彼らにとって、インナーソースイニシアチブは、イノベーションと効率性を促進するための多くのイニシアチブの1つに過ぎませんが。彼らは、インナーソースに資金とエリアリーダーに対するキャパシティを提供し、予算がどのように使用されるかについて主に自治を与えています。また、取り組みの幅と期間を限定し、期待通りの成果が得られることが証明されるまで、定期的な見直しも行っています (レビュー委員会を参照)。 経営トップ層は、様々な社内会議でインナーソースを支持することを表明しています。

しかし経営トップは、中間管理職に対して、従業員が部門横断的なインナーソースの活動に参加することを許可したり、動機付けるような権限を与えたり、インセンティブを与えるまでには至っていません。さらに、すべてのアソシエイトのキャパシティは、通常、勤務時間の100％をインナーソース以外のプロジェクトに割り当てられています。組織横断的なコラボレーションはまだ一般的ではなく、直属マネージャーは通常、自分の組織外に目標を持っていません。 一方で、インナーソースのプロジェクトに貢献するのは、自由時間ではなく、勤務時間内に行われることが期待されています。

組織に働く力学

• マネージャーは、ビジネスユニットの結果に対して責任を負います。 スタッフをインナーソースアクティビティに参加させると、ビジネスユニットの外部でコントリビューションすることに時間を費やす可能性があり、ユニットのキャパシティが効果的に減少します。 これにより、マネージャーが目標を達成または超えることが難しくなる可能性があります。

• 直属のマネージャーと人事は、一般的に部下のパフォーマンスをビジネスユニットの目標に対して判断します。これは、インナーソースコミュニティの目標と一致していない可能性があります。

• 直属のマネージャーがトップ層の後方支援を受けていると思っていない場合、他のビジネスユニットに貢献するインナーソースアクティビティにスタッフを参加させる可能性は低くなります。

• 直属のマネージャーがコントロールしにくく、さらに作業の透明性が低い場合、彼ら・彼女らの部下がインナーソースのプロジェクトにコントリビュートできる可能性は低くなります。

• インナーソースでの正式な作業が管理および整理されていないほど、正式なプロセスに慣れている直属のマネージャーが、従業員のインナーソースの活動へのコントリビューションを承認する可能性は低くなります。

• 社員はインナーソースプロジェクトへのコントリビューションに多くの時間を費やしますが、それらの活動は彼・彼女の日常業務に利益をもたらすことはありません。そのため、彼のビジネスユニットのチームメイトの作業負荷が増加してしまいます。

• 個々のコントリビューターは、おそらく社内の専門的なネットワークを強化し、彼ら・彼女らのコントリビューションの技術分野における知識と経験を得るための機会としてインナーソースに参加することを検討しています。

ソリューション

コントリビューター、その直属のマネージャー、および中央で資金提供され運営されているインナーソースガバナンスオフィス(ISGO) の間で正式な契約を締結します。 ISGO に、契約期間内にコントリビューターと契約したビジネスユニットに払い戻しを依頼します。

• 契約では、インナーソースで社員の作業時間の最大割合を指定します。

• 契約では、コントリビューターのビジネスユニットでの作業がインナーソースでの作業よりも優先されることを明確に述べています。

• 契約では、契約で指定された最大割合の作業量をインナーソースプロジェクトでで必要はないことを述べています。

• 契約では、コントリビューター、コントリビューターの直属の上司、ガバナンスオフィス、コントリビューターがコントリビュートするコミュニティの正式なコミュニティリーダーによって署名されています。

• ガバナンスオフィスは、コントリビューターと直属のマネジャーの間で時間に関するコンフリクトが生じた場合、その仲介を行うことを提案します。

• 正式なコミュニティリーダーは、20%以上の活動をインナーソースに充てている契約コントリビューターのパフォーマンスレビューに参加するか、意見を提供します。

結果の状況

正式な契約と中央資金による払い戻しは、インナーソースイニシアチブのための組織のサポートを説得力を持って伝えることになり、またそれに署名するために中間管理職の権限を与えることになります。

• 開発キャパシティを払い戻すための企業資金のビジネスユニットへの割り当ては、インナーソースが組織によって価値があると見なすことになります。また、エグゼクティブの後方支援があり、彼らもそれをサポートすることが期待されていることを直属のマネージャーにに伝えることにもなります。

• 正式な契約は、インナーソースで仕事が専門的に管理されていることを意味し、信頼につながります。

• 正式な契約により、透明性が向上し、社員のビジネスユニットおよびインナーソースプロジェクトで利用可能なキャパシティの概要がわかりやすくなるため、「過剰なリソースの提供/計画キャパシティ」に関するリスクが軽減されます。

正式な契約は、コントリビューターやコミュニティにとっても有益です。

• 安定したコントリビューターのグループがあれば、そのうちの何人かが最終的にトラステッドコミッター のロールに到達する可能性が高くなります。

• 正式な契約は、インナーソースの活動への参加に関連するコンフリクトを解決するための基礎を提供します。(注: 調停は、対応する文化を持つ一部の企業のみに成功する可能性が高いことにご注意ください)

事例

• BIOS at Robert Bosch GmbH

ステータス

• Structured

著者

• Georg Grütter (Robert Bosch GmbH)

謝辞

• Diogo Fregonese (Robert Bosch GmbH)

• Robert Hansel (Robert Bosch GmbH)

• Jim Jagielski

• Tim Yao

• Cedric Williams

• Klaas-Jan Stol

• Padma Sudarsan

• Nick Stahl

• Ofer Hermoni

• Robert C. Hanmer

Changelog

• 2016-10-25 - first review

• 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

• 2023-06-18 - 最終更新

Title

RFCを用いたチーム横断的な意思決定の透明化

Patlet

高い参加率を達成し、関係者全員にとって最良の意思決定を行いたいインナーソースプロジェクトは、ソフトウェアのライフサイクル全体を通して参加型のシステムを構築する方法を見つける必要があります。内部のRFC(Requests for Comments)ドキュメントを公開することで、設計プロセスの早い段階から議論を行うことができ、関係者全員が高いコミットメントを持ってソリューションを構築できる可能性が高まります。

問題

インナーソースプロジェクトが健全であるためには、相当な数のコントリビューターが必要です。しかし、コントリビューターが増えると、例えば互いに互換性のない機能をプロジェクトに追加したり、アーキテクチャを不健全に肥大化させたりする可能性があります。 このような意見の相違や誤解をプロセスの後半で発見した場合、特にソフトウェアがすでに構築された後では、修正に非常にコストがかかってしまいます。このような意見の相違は、関係者全員のフラストレーションにつながり、プロジェクトにおけるコラボレーション文化の健全性を損なう可能性さえあります。 このような不一致が表面化する時によくあるケースとして、変更リクエストの作成者とプロジェクトのメンテナーが、提案された変更を行うべきであるということに本質的に同意していないために、非常に長い間オープンになっている変更リクエスト(プルリクエスト) が存在するなどがあります。

インナーソースプロジェクトでは、社内の複数のチームによってプロジェクトが維持されている場合、このような状況がより頻繁に発生します(共有オーナーシップ)。

ケーススタディ

プロジェクト、または複数のプロジェクトで構成されるアプリケーションは、多くの異なるチームによって維持され、各チームはプロジェクトまたはアプリケーションの異なる領域を所有し管理します。これらのチームは、お互いの領域にインナーソースの貢献をしますが、より大きな分野横断的な変更は、チームの技術リーダーが協力することによってのみ推進されるか、もしくはそもそもまったく発生しません。その結果、ほとんどのエンジニアは大規模で分野横断的な変更を行うことができなくなり、イノベーションとコラボレーションの機会が減少します。

ここで RFC のプロセスとテンプレートを導入することで、チームや個人は、透明性のある意思決定プロセスを通じて、大規模で横断的な変更を提案する権限を与えられ、チーム間で非同期的に協議が行われます。その結果、イノベーションが促進され、コラボレーションが緊密になり、知識がより広まることになります。このためには、あらゆるレベルのあらゆる分野から賛同を得ること、そして人々がオープンにアイデアを提案し、議論できるような心理的安全性の高い環境を整えることが必要です。

どのようなプロセスでもそうですが、これは継続的に改善されなければなりません。RFC のテンプレートやプロセスを変更して、包括的、協調的、かつ効果的なものにする必要があるかもしれません。

状況

• インナーソースプロジェクトは多くのチームによって共有されています。

• アーキテクトグループは十分な時間がなく、またすべてのケースで適切な判断を下すのに十分なドメイン固有の知識もないため、包括的な設計上の決定を常に中央の組織(アーキテクトグループなど)から行うことはできません。

• あるプロジェクトの方向性については、さまざまなタイプのユーザーが意見を述べます。そのようなユーザーには開発者、プロダクトオーナー、プロダクトマネージャーなどがいます。

• 参加者全員と頻繁に同期ミーティングを開くことが不可能なため、少なくとも部分的には非同期で意思決定を行う必要があります。

• 決定事項を文書化したい、つまり口頭だけでなく文書で確認したいと感じています。

組織に働く力学

• ほとんどの場合、関係者はかなり迅速に決定を下したいと思っています (例: 事前の設計時間はかなり限られています)

• 関係者の多くにとって、(すでに実装されていない)物事を書き留めることは新しいスキルであることが多いです。

スケッチ

ソリューション

チーム横断的な意思決定プロセスの透明性を高めるために、RFC的なプロセスを採用します。(Requests for Commentsもご参照ください)

このソリューションの重要な要素は以下の通りです。

• RFC を発行する場合(および発行しない場合)の説明

• RFCドキュメントのテンプレート

  • RFC の作成者に、自分の提案を多角的に検討するよう促す必要があります。

  • ハイレベルでアクセスしやすい概要と、詳細で深い説明の両方を促す必要があります。

• RFC を取り巻くよく知られた軽量なプロセス

  • RFC を公開し、すべての関係者と共有する方法 (例: Slack、メーリングリスト)

  • RFC に対するフィードバックをどのように収集するか

  • どのようにフィードバックを取り込むか

  • 結論や決定に向けて RFC をどのように進めるか (例: 関連する指名されたメンテナーが承認すること)

  • 適切なツールの選択 (例: 非エンジニアはソースコントロールツールにアクセスできないかもしれません)

• RFC のテンプレートとプロセスを繰り返し使用することを約束すること

Examples/Templates

• Rust は RFC テンプレートとプロセスの優れたオープンソース例であり、他の多くの RFC プロセスの基礎となっています。

• 一般化された BBC iPlayer & Sounds RFC テンプレート (元々はRustテンプレートに基づいています)

結果の状況

RFC のようなプロセスを導入することで、チーム横断的な意思決定プロセスがより透明化され、すべての人の声を聞くことができるようになり、価値があることが証明されました。

観察できるポジティブな効果

• 多くのチームに影響を与える意思決定プロセスを民主化します(チームリーダーの負担を軽減)。

• 複数のチームや地域にまたがって機能するオープンな非同期コミュニケーション手法になります。

• 個人とチームが大規模な変化を起こせるようにします。

• 決定事項を記録し、その内容を参照することができます。

• 経験豊富なエンジニアが、ミーティングに出席する必要がなく、非同期かつリモートでソリューションに貢献できるため、その影響力を拡大することができます。

• 例えば、"システムテストとは何か" などのテスト用語を定義しておくことで、用語の整合性を図ることができます。

• プロセスの整合性を図ります。 例えば時間外サポートのプロセスを明示するなどが挙げられます。

• RFC を書くことで、著者が自分自身に挑戦することになり、思考がより明確になります。

一方で RFC のアプローチにはリスクも存在しますので、以下に注意も喚起したいと思います。

• この方法はいつもうまくいくとは限りません。例えば、RFCを通じてすでになされた決定に対して異議を唱える人がいるかもしれません。しかし、意思決定のプロセスを文書化しておくことは、このようなシナリオでも有益です。ある決定がいつ、なぜなされたかを人々に示すことができるからです。

• 設計案 (アーキテクチャ、プロトコルなど) を前もって書き上げることは、ウォーターフォールのような設計の要素があり、多くの開発チームが好む反復的なアジャイルの開発アプローチには適さない場合があります。アジャイルマニュフェストに存在する「括的なドキュメントよりも、動くソフトウェアを」という項目は覚えておいてください。RFC プロセスは可能な限り軽量であるべきです。

• RFC は大きくなりすぎて扱いにくくなる可能性があります。これはしばしば、長いコメントスレッドやそれをめぐる議論に表れます。そのような状況では、ワーキンググループや直接のミーティングなど、同期的なコミュニケーションで RFC を補完することを決定することもあります。しかし、ミーティング中にすべての情報を共有するのではなく、ミーティングの前に RFC を読むことができるので、時間はいずれにせよ節約されていることになります。

理論的解釈

RFCは、長年にわたってオープンソースの世界でその効果が証明されてきました。これは、RFCが標準の開発に役立ってきたインターネット全体にも当てはまるほか(例: RFCの30年を参照)、コミュニティにおける透明な意思決定を促進するためにこの方法を適応させてきたその他のオープンソースプロジェクト(RUST, ZeroMQ)にも当てはまります。

インナーソースの文脈では、Uber や Europace など、様々な企業が RFC のようなアプローチの経験を有しており、共有しています。

また、純粋なソフトウェア設計の決定以外にかかる意思決定においても、透明性のある意思決定モデルは、例えばオープンな組織に向けて取り組む際に効果的です。例として、Red Hatの Open Decision Framework (2016年6月7日に公開)をご覧ください。

事例

• BBC iPlayer & Sounds - ISC Fall Summit 2020 のプレゼンテーションをご参照ください - Using Internal RFCs to Enhance Collaboration

• Europace - Open Organizationの項目で述べられています - Setting cross-team standards and best practices in the open.

• Uber - Gergely Orosz さんの記事をご覧ください Scaling Engineering Teams via RFCs: Writing Things Down.

• Google Design Docs - Malte Ublさんの記事をご覧ください Design Docs at Google

ステータス

Structured

著者

• Tom Sadler

• Sebastian Spier

その他の呼び方

• デザインとキュメント

• アーキテクチャの決定記録(ADR: Architecture Decision Record) - 意見を求め、合意を形成するための RFCです。決定と実装の詳細を記録するための ADR など、非常に異なる使い方をすることがあるため、必ずしも直接的な類例ではありません。

翻訳の履歴

• 2022-06-07 - 翻訳 Yuki Hattori

• 2022-06-13 - レビュー @kanazawazawa

• 2023-06-18 - 最終更新

Title

コアチーム

Patlet

インナーソースのプロジェクトが広く必要とされていても、プロジェクトが難しいためにコントリビューションや活用に支障をきたす場合があります。プロジェクトの基本的な項目を専門に担当するコアチームを設立してください。コアチームの作業により、コントリビューターは自分のシナリオに価値をもたらす機能を追加し、使用することができます。

問題

• プロジェクトにコントリビュートすることが困難な場合、以下のようなことが原因として考えられます。

  • ローカルでプロジェクトを実行できない。

  • ドキュメントが貧弱

  • コードが複雑

  • テストが不適切である

• プロジェクトを使用するのが困難な場合、以下のようなことが原因として考えられます。

  • ドキュメントに不備がある

  • バグが頻繁に発生する

  • セットアップが直感的でない

ケーススタディ

誰もが依存する中心的なプロジェクトがあります。「なんて素晴らしいインナーソースのための候補でしょうか！」 しかし残念ながらこれまでプロジェクトは有機的に成長し、様々なコントリビューションと追加が無計画に行われてきました。今では、誰も理解できず、誰もが触れることを恐れている、厄介で厚いコードの沼になっています。 明らかにオーバーホール（リファクタリング、テスト、ドキュメンテーションなど）を行うべきなのに、誰もがその作業を必要とし、望んでいるにもかかわらず、誰もそのための時間を取らないのです。

状況

• 多くのチームがそのプロジェクトを必要としています。

• プロジェクトに大きな技術的負債があります。

• プロジェクトの採用やイテレーションは遅いです。

• プロジェクトとコントリビューションのエコシステム全体に対して責任を持つオーナーやメンテナが存在しません。

組織に働く力学

• コントリビュートするチームは皆忙しいので、自分たちにすぐに利益が出る仕事を優先します。

• プロジェクトが成長するにつれ、使用や変更が難しくなるのは当然の傾向です。

ソリューション

他の人が簡単に参加でき、コントリビュートできるようにこのプロジェクトを維持することを仕事とするコアチームを形成します。このコアチームは、健全な利用やコントリビューションのエコシステムに必要な作業を行います。この重要な仕事は、コントリビューションとして優先されない傾向があります。この種の作業のカテゴリには、コミュニケーション、ローカル環境、DevOpsインフラストラクチャが含まれます。 以下はその具体例です。

• 本番環境のバグ

• ドキュメンテーション

• オンボーディングチュートリアルとサンプル

• 自動化されたテスト

• CI/CD

• ローカル環境

• モジュール化

• バージョニング

• モニタリング

• 新しいクラス/機能のカテゴリを開拓する

これらの各項目は、健全な製品エコシステムにとって非常に重要であるにもかかわらず、貢献として優先されることはまずないでしょう。 コアチームは少人数の、フルタイムまたはパートタイムで構成することができます。その選択は、必要な作業量、リソースの利用可能性、組織の文化に依存します。最も重要な考慮点は、組織が他のチームと同じように権限を与え、責任を負わせることができるようにチームを編成することです。 その中心的な役割から、コアチームのメンバーはほぼ常にトラステッドコミッターの役割も果たすべきです (この概念については、ラーニングパスと パターン を参照してください)。トラステッドコミッター の役割は、他のメンバーがプロジェクトに貢献したり利用したりするのを促進することに主眼が置かれていますが、コアチームのメンバーは定期的にプロジェクトにも貢献します。コアチームには、貢献を決定するような独自のビジネスアジェンダはありません。彼らは、他の人がプロジェクトを利用し貢献するために何が最も役に立つかを考えて、取り組むべきことを決定します。

この目標を継続的にリマインドさせるためには、コアチームに定期的に以下の項目を報告してもらうのがよいでしょう。

• そのプロジェクトを使用しているアクティブなチームの数

• プロジェクトに対するチーム外からの貢献の数

これらのメトリックに継続的に焦点を当てることで、コアチームは自然と、プロジェクトの周りに繁栄するインナーソースエコシステムを作成するための適切な作業に優先順位を付けるようになります。

結果の状況

• プロジェクトを利用しコントリビュートすることが容易になります

• 多くのチームがこのプロジェクトを利用し、貢献するようになります

• コアチームの成功は、他のプロジェクトとの相互作用とプロジェクトへの対応という観点から定義されています。

理論的解釈

コアチームを分離し、このようにタスクを与えることで、プロジェクトを成功させるために必要なギャップを埋めることができます。 コアチームはそのギャップを埋め、コントリビューションのエコシステムが健全であるよう、潤滑油の役割をします。

事例

Nike は、再利用可能なCI/CDパイプラインを中心としたインナーソースの取り組みを管理するためにこのパターンを導入しました。

ステータス

Structured

著者

Russell R. Rutledge

翻訳の履歴

• 2022-06-01 - 翻訳 Yuki Hattori

• 2022-06-21 - レビュー @hirotakatoya

• 2023-06-18 - 最終更新

Title

スタンダード・ベース・ドキュメンテーション

Patlet

インナーソースプロジェクトへの新しいコントリビューターは、誰がプロジェクトを維持し、何に取り組み、どのようにコントリビューションすればよいかを理解するのに苦労しています。README.md/CONTRIBUTING.md のような標準ファイルでドキュメントを提供することで、新しいコントリビューターのためのセルフサービスなプロセスを可能にし、よくある質問に対する答えを自分自身で見つけることができるようにします。

問題

あるチームは、新しく始めたプロジェクトや既存のプロジェクトをより広い組織で共有し、それに対するコントリビューションを受けたいと考えています。潜在的なコントリビューターは、しばしば迷ってしまいます。チームの好ましいコミュニケーションチャネルを特定できない。新しい機能が追加されることに意味があるのかどうか、すぐに判断することはできません。また現在、どの同僚が活発にプロジェクトをメンテナンスしているのかを正確に理解するのに苦労しています。

状況

プロジェクトは、インナーソースプロジェクトとして他の人と共有されることになります。他の人がプロジェクトが何であるか、また、どのようにコントリビュートするかを理解できるようにするために、プロジェクトはいくつかの基本的なレベルのドキュメントを提供する必要があります。これまでのところ、プロジェクトは、すべてのドキュメントまたはユーザーがセルフサービス方式でそれを試してみるだけでなく、コントリビューターが迅速にスピードアップするために必要な項目がいくつか不足しています。

組織に働く力学

• プロジェクトがインナーソースのプロジェクトになったのは、つい最近のことです。以前は、ユーザーは社内のみ、または個人的な対面セッションでオンボーディングされていました。同様に、プロジェクトで働く人々は、コントリビューターやリモートコントリビューターの数の増加に伴いスケールしない個人的なオンボーディングセッションを通過しました。その結果、セルフサービスの文書が不足しています。

• プロジェクトは、インナーソースプロジェクトとして新しく作成されました。しかし、ホストチームには、十分なインナーソースの経験がありません。その結果、彼らはどのような情報についてのガイダンスをドキュメントに含める必要があるのか、他の人がどこでそれを見つけることができるようにすべきか、どのような人に対してそのドキュメントを提供すべきなのかがわかりません。

• プロジェクトは、つい最近インナーソースプロジェクトになりました。ホストチームは、インナーソースに関して限られた経験を持っています。その結果として既存のドキュメントは、技術的な側面の多くに対応していますが、コミュニケーション、調整、透明性の高い計画を促進するために必要な情報をカバーしていません。

• プロジェクトは、ごく最近インナーソースのプロジェクトになりました。その結果、チーム内に存在する多くの暗黙の知識が書き留められることはなく、コントリビューターにとっても明らかではありません。

• ドキュメントの欠如は、潜在的なコントリビューターがセットアップをして作業を開始するのに長い時間がかかることにつながります。ドキュメントを作成する(そしてそれを最新に保つ)には、時間的な投資が必要です。たとえホストチームがドキュメントの欠如に関してコントリビューターに頼ったとしても、それらのコントリビューションはレビューする時間を必要とします。

• プロジェクト・メンバーは、使い始めの質問に答えるために多くの時間を費やしています。しかし、サポートに関する質問の包括的なデータベースを維持することは、多くの時間と労力を必要とします。

• ソースコードのフォーマットやソフトウェアのパターンについて、組織内の異なるチームが異なる基準を持っています。その結果、コントリビューションはしばしば、大部分または全体が書き直されてしまうこともあります。そのすべてを標準化し、その標準を強制するには、多くの時間と労力が必要になるケースがあります。

• このように、説明と書き直しを繰り返す作業は、インナーソースアプローチの有用性を低下させます。

• 余分な仕事と書き直しのための遅延による頻繁なエスカレーションは、ビッグチーズ問題(*)に発展します。 (*ビッグチーズ問題について-和: ビッグチーズとは「お偉いさん」のことを指します。現場がわからない上の人同士でコミュニケーションをとることによる問題をさします。例として、政治的にコードベースへの統合が実施されることで、例えそのコードが要件を満たしていなくても統合しなければいけない状況が起こり、コントリビューションを受け入れる側が多くの作業をかかえることになります)

ソリューション

新しいコントリビューターのために、より明確なドキュメント作成の作業に取り組む。このドキュメントを作成する際の目標は、よくある質問に標準的なドキュメント形式で回答することで、可能な限りセルフサービスのプロセスを開始できるようにすることです。

README.md

まだ存在しない場合は、あなたのプロジェクトの README.md を作成してください。それには以下の内容が含まれていなければなりません。

• プロジェクトのミッション できるだけ簡潔な形式にしてください。これは、プロジェクトの目的が何であるかに答え、提案された機能がプロジェクトの範囲内にあるかどうかを、コントリビューターが最初に推測できるようにする必要があります。

• プロジェクトで実働をするユーザーに向けた "Getting Started" セクション。プロジェクトの成果物をどのようにセットアップし、統合するかを説明し、初めてのユーザーのためのファーストステップに関する説明も必要です。

• プロジェクトユーザーのための詳細なドキュメント - またはそれへのリンク

• プロジェクトを修正するために必要なドキュメント - またはそれへのリンク

• プロジェクトにコントリビュートする方法に関するドキュメント - またはそれへのリンク

• プロジェクトがどのようなアクセス可能なパブリックもしくはアーカイブのコミュニケーションチャネルを用いているかを説明する "Getting involved" セクション。このリンクには、プロジェクトのイシュー・トラッカーへのリンクだけでなく、さらなるディスカッションメディアへのリンクも含めるべきです。

• プロジェクトを支える トラステッドコミッターが誰であるかを説明する "Who we are" のセクション。これらの人々と個人的に連絡を取る代わりに、上記の公開コミュニケーションチャンネルを使用して連絡を取るべきであるという説明も必要です。

• プロジェクトが貢献者を信頼されるコミッターにするための基準（もしそのような道があるならば）の説明です。

• コントリビューターがそのプロジェクトにおけるトラステッドコミッターになるための基準及び、そのパスが存在するならばそのパス

CONTRIBUTING.md

コントリビューションを行うための手順の説明が複雑すぎる場合は、CONTRIBUTING.md というドキュメントを別に作成します。この文書では、コントリビューターが過去によく聞かれた質問に答えるようにします。前もって包括的なドキュメントを提供する必要はありません。むしろ、コントリビューターが必要としていることが証明された情報を共有しましょう。おそらく、以下のトピックのうちの1つ以上に触れることになるでしょう。

• プロジェクトのソースコードをバージョン管理からチェックアウトする方法

• プロジェクトに変更を加える方法 (コーディングガイドラインに関する情報を含む可能性があります)

• プロジェクトをビルドする方法

• 上記の修正が新しいバグを引き起こしていないことを確認するためのテストの実行方法

• プロジェクトにあなたの修正をサブミットする方法

• 修正が行われた場合、変更が取り込まれるまでに必要な所要時間に関する情報

様々なオープンソースプロジェクトにおいて、 README.md の書き方や、 CONTRIBUTING.md ファイルにどのような情報を含めるべきかについての良い例がたくさんあります。How to write a readme that rocks, Open Source Guide from GitHub や書籍 Producing Open Sourceなどのページには、どのような情報を提供すべきなのかについての貴重な情報が掲載されています。Producing Open Source には、良い README を書くための章はありませんが、Getting Started chapter には、ホストチームのメンバー、ユーザー、コントリビューターが必要とするもののかなり広範なリストがあります。インナーソースのプロジェクトは、おそらく最初からこれらの側面のすべてをカバーする必要はありませんが、リスト自体は README.md がカバーできるものを想起するために有効です。 このパターンには、すぐに始められるように、2つの非常に基本的なテンプレートが付属しています。README-template.md と CONTRIBUTING-template.md をご参照ください

結果の状況

• コントリビューターがスピードを上げるまでの時間が大幅に短縮されます

• トラステッドコミッター が初歩の質問に答える時間が大幅に短縮され、他の作業に時間を割くことができるようになります

• 誤った理解や、同じ方向を向いていないことによるエスカレーションが大幅に削減されます

事例

• Europace AG - こちらのブログをご覧ください InnerSource: Adding base documentation

• Paypal Inc.

著者

• Isabel Drost-Fromm

その他の呼び方

Provide standard base documentation through a README

ステータス

• Structured

• Drafted in December 2019.

リファレンス

• README-template.md and

• CONTRIBUTING-template.md

翻訳の履歴

• 2022-06-01 - 翻訳 Yuki Hattori

• 2022-06-13 - レビュー @kanazawazawa

• 2023-06-18 - 最終更新

Title

レビュー委員会

Patlet

インナーソースの作業モデルは、開発者と管理者のための、より伝統的なアプローチからの抜本的な変革です。インナーソースイニシアチブとそれに参加するビジネスユニットのすべてのシニアマネージャーの間のインタフェースとしてレビュー委員会を確立することにより、マイクロマネジメントを助長することなく、監視と制御の一定レベルを与えるように、イニシアチブに慣れ親しみ、それをサポートできるようになる可能性が高くなります。

問題

管理職は、インナーソースの作業モデルを、彼らが慣れ親しんできた作業モデルからの根本的な逸脱として認識することになるでしょう。その結果、彼らはこの変化のリスクを最小限にしようとするために、インナーソースイニシアチブを拒否またはマイクロマネジメントする可能性があります。 どちらの場合も、インナーソースの利点を実現することができません。その結果、インナーソースは信用を失うことになります。

状況

A社は、最初のインナーソースの取り組みを導入したいと考えています。A社のほとんどのマネージャーは、オープンソースの作業モデルに慣れておらず、代わりに階層的な、トップダウンのコントロールスタイルの管理に慣れています。

組織に働く力学

• マネージャーがインナーソースイニシアチブでのワークをコントロールしている認識を持てば持つほど、マネージャーは事前の経験がなくてもイニシアチブをサポートする可能性が高くなります。

• マネージャーは、オープンソースのワークモデルの経験が少ないほど、マネージャーがイニシアチブのリスクを制御したいと思う可能性が高くなります。

• インナーソースの取り組みがより重労働でマイクロマネジメントされているほど、 オープンソースの作業モデルを必要な範囲で採用できる可能性は低くなります。その結果、InnerSourceのメリットは実現されません。

ソリューション

• インナーソースイニシアチブに参加するすべてのビジネスユニットのシニアマネージャーで構成されるレビュー委員会を設立します。

• レビュー委員会メンバーには、どのインナーソースプロジェクトが一般的な支援を受け、特に資金援助を受けるかをグループとして決定する権限が与えられています。

• 申請者は、会議の前にレビュー委員によって選出され、レビュー委員会の会議でインナーソースプロジェクト案を提示することができます。

• 現在、レビュー委員会が資金を提供しているインナーソースプロジェクトのリーダーは、毎回のレビュー委員会でプロジェクトの状況について報告することが義務付けられています。

• レビュー委員は、レビュー委員会において、新規申請者と現在のプロジェクト・リーダーの両方に対して建設的なフィードバックを行う義務があります。

• すべてのインナーソースプロジェクトは、プロジェクトの早期終了を避けるために、レビュー委員会のあるセッションで受け取ったフィードバックに対して、次のセッションまで反応する機会を与えられることになっています。

• インナーソースプロジェクトのリーダーは、レビュー委員会で自発的に停止させるための動議を提示することもできます。レビュー委員会は、次に、ソフトウェアを使用するビジネスユニットが、インナーソースコミュニティによる開発の代替ソリューションが見つかるまで、コードベースの開発またはメンテナンスを継続するための手段を講じる時間を与える必要があるかどうかを決定しなければなりません (ビジネス関連またはミッションクリティカルである場合)。

• レビュー委員会は、定期的に開催されるべきです。年に2回のペースで開催するのが効果的であることが証明されています。

結果の状況

マネージャーは、インナーソースイニシアチブのために必要な量の情報を取得し、制御するために、使い慣れたツールをインナーソースに適用します。この親しみやすさにより、マネージャーはインナーソースイニシアチブを承認し、インナーソースプロジェクトに必要な自由度を付与する可能性が高くなります。 開発者は十分に自己組織化することができます。 レビュー委員会はあまり頻繁に招集されないため、マイクロマネジメントは行われません。

事例

• BIOS at Robert Bosch GmbH

ステータス

• Structured

• Finalized and Reviewed as of 8/31/17.

著者

• Georg Grütter, Robert Bosch GmbH

• Diogo Fregonese, Robert Bosch GmbH

その他の呼び方

Cheese Interface

翻訳の履歴

• 2023-06-18 - 最終更新

Title

クロスチームプロジェクト評価

Patlet

会社の収益に直接的な影響を提供していないクロスチームのインナーソースプロジェクトの価値を評価して社内に売り込むことは困難です。 ここでは、あなたのプロジェクトの価値を明確に表現し、それを大きくするためのデータ駆動型の方法を紹介します

状況

• あなたは、社内のプラットフォームとして機能するクロスチームを担当しています。

• クロスチームプロジェクトは、企業の収益に直接的な価値をもたらすものではありません。

問題

チーム横断的なプロジェクトは、会社に非常に大きな影響を与える可能性がありますが、データに基づいた形で表現することは困難です。 その結果、真の価値を生み出さないプロジェクトを追求してしまったり、本来なら大きな価値を生むはずのプロジェクトに資金を投入しなかったりすることがよくあることはご存知の通りでしょう。

組織に働く力学

• プロジェクトが資金を得るためには、会社のリーダーシップに価値(客観的または主観的)を示す必要があります。

• チーム横断的なプロジェクトの価値は、複数の最終事業部門に分散しています。

• このように分散しているため、クロスチーム・プロジェクトの価値を直接測定することは困難になっています。

ソリューション

チーム間のプロジェクトを評価する方法のパターンとモデルを設定します。このようなモデルは、会社にとって価値の高いコラボレーションに焦点を合わせて拡大するために必要なツールを提供します。 チームをまたがるすべてのプロジェクトにおける価値の核となるのは、離れるよりも一緒に多くのことを成し遂げることができるという考えかたです。 チーム間の取り組みに価値を与えることは、一緒に行われていることの量を定量化するための演習にもなります。 生産性に関する実際の差は、ドメインやプロジェクトによって異なります。ここではモデルを作成して計算できる一般的なプロセスがありますので以下で紹介します。

解説

まずあなたのドメインにおける特定分野の専門家からなる小さなチームを編成します。その専門家チームで、プロジェクトの成果物を利用するそれぞれの人について、以下の4つのことを見積もってください

• プロジェクトの成果物をユーザーが使うのにどのくらい時間がかかりますか？

• そうでなければ、あなたのプロジェクトのアウトプットの価値をユーザー自分たちのものにするために、どれくらいの時間がかかりますか？

• プロジェクトの成果物の何パーセントが、実際に彼らにとって有用ですか？

• 自社で開発したソリューションのメンテナンスに、継続的(理想は使用ごと)にどれだけの時間を費やすことになりますか？

これらの見積もりを行う場合、アクティビティにかかる時間を正確に知ることは不可能です。また、それはあなたの目標ではありません。 正確さではなく、これらの見積もりに最悪の場合の限界を設定するように努める必要があります。専門家のグループがお互いに「どれくらいの時間がかかるかは正確にはわかりませんが、少なくともこれだけだということには同意できます」と言うことができるという考えです。 具体的には、プロジェクトのアウトプットを消費するための最大の妥当な時間と、消費者が独自のソリューションを自分のものとして使用、および維持するための最小の妥当な時間を見積もる必要があります。

自前でソリューションを開発する(ホームロール)場合のコストについては、一つ注意点があります。ソリューションの自作にかかるコストは、必ずしも共有ソリューションの作成コストと同じとは限りません(実際、非常にまれです)。 同じ機能であれば、チーム横断的な共有ソリューションの構築に必要なモジュール性と品質により、一度だけ使用する迅速でハードコードされた実装よりも明らかに高い投資となることがよくあるのです。

数式

ワーストケースを設定すると、単純な計算式でチーム横断的なプロジェクトの成果物を評価することができます。

解説

一見このプロセスには厳密さがあるように見えますが、チーム横断的なプロジェクトの成果を正確に測定する方法を提供するものではありません。 ただし、実際には、この作業に資金を提供する方法を適切に決定するためのフレームワークが提供されます。 上記の説明に従って適切で妥当なデータを取得したら、少なくとも次の3つのレベルのうち、小さい方までプロジェクトを実行するための専用の開発時間に資金を提供する必要があります。

1. 上記の式によって節約された実際の時間。 公式が実際に節約された時間数よりも少ない数を生み出すと私たちは皆確信しています。そのため、その時点までのプロジェクトへの資金提供はあなたにとって確実な勝利であると確信することができます。

2. チーム間のプロジェクトへのインナーソースのコントリビューションをサポートするためにかかる時間。コントリビューターは、一度限りのワークを提供することが多いでしょう。そのワークを共有の場所に持っていくための時間に投資することには価値があります。

3. あなたが心地よく進められるものなら何でもかまいません。評価式を持つことの意図的な副次効果として、ユーザーに価値を提供する重要ポイントの測定を自然に強制することができます。

それらの測定値を理解し、そのまま使うことで、プロジェクトの価値を直感的に理解することができます。 この評価手法が正確さに欠けることを心配される方もいらっしゃるかもしれません。このプロセスでは正確な測定値が得られなくてもかまいません。ただ、以下2つの目的を達成するのに十分な精度があることが重要です。

1. チーム横断的な取り組みを組織し、資金を提供している人々に、起こっていることの価値を表す手段を提供します。

2. チーム横断的な取り組みのうち、どの分野がより高い価値を持ち、優先的に追求されるべきかを関係者が知ることができるようにします。

実際には、これらの評価が現実と一桁以内の誤差である限り、これらの目的を満たすのに十分な精度であると言えます。 ドキュメント冒頭の「問題」で述べたような場当たり的な評価（およびその結果生じる影響）に比べ、現場での結果は頭一つ抜きん出たものになるでしょう。

結果の状況

• チーム横断型プロジェクトの価値と資金調達について、リーダーシップと議論するためのデータ駆動型の手段になります。

• クロスチーム・プロジェクトに関する主要な指標を素のデータの形で計測することができます。

• クロスチーム・プロジェクトがどのように価値を提供するかを定義することで、実際に企業にとってより大きな価値を生み出すことにつながる傾向があります。

• 一般的に成功したプロジェクトの周辺でバズが生まれます。

事例

• Nike

ステータス

• Structured

• Proven in multiple domains.

著者

• Russ Rutledge

Acknowledgement

• Jeremiah Wright さんは、クロスチーム・プロジェクトを、開発者の時間という"通貨"を扱う社内ビジネスとして考えるように教えてくれました。

翻訳の履歴

• 2023-06-18 - 最終更新

Title

実験として始める

Patlet

インナーソースイニシアチブを期間限定の実験として開始し、インナーソースに慣れていないマネージャーがイニシアチブを承認およびサポートしやすくします。

問題

インナーソースイニシアチブは検討されているものの、経営陣がその結果について確信が持てず、その結果として投資にコミットする意思がないため、なかなか開始されません。

状況

会社は、ソフトウェアプロジェクトにおけるコラボレーションの効率を高めるために、InnerSourceを検討しています。しかし、ほとんどの管理者は、オープンソースの作業モデルに精通しておらず、代わりに階層的な、トップダウンの制御スタイルの管理に慣れています。InnerSourceのアイデアは、社内のソフトウェア開発者に非常に人気があり、少なくとも多くの開発者がオープンソースソフトウェアを使用しているか、積極的に開発しているためです。

同社は、ソフトウェアプロジェクトでのコラボレーションの効率を高めるためにインナーソースを検討しています。 ただし、ほとんどのマネージャーはオープンソースの作業モデルに精通しておらず、代わりに階層的なトップダウンの制御スタイル管理に慣れています。インナーソースのアイデアは、社内のソフトウェア開発者に非常に人気があります。その理由は特に、多くの開発者がオープンソースソフトウェアを使用または積極的に開発しているためです。

組織に働く力学

• マネージャーは長期的な投資を行う前に、インナーソースを用いたコラボレーションにおいて効果が期待できるかを検証する必要があります。これには通常、改善したかを測定することが含まれます。

• インナーソースイニシアチブが開発者の間で大きな支持を得る可能性が高く、多くのプロジェクトがそれに依存する可能性が高い場合、それをシャットダウンする決定は非常に不人気であり、実施するのは困難でしょう。導入した結果、コントロールを失う可能性が認識される場合、一部のマネージャーはインナーソースを始めることさえ思いとどまる可能性があります。

• インナーソーススタイルの作業モデルの実装は、以前に実践されていた作業モデルからの根本的な逸脱であることがよくあります。したがって、既存の必須プロセスはもはや適用できず、適切な管理プロセスが失われてしまう可能性があります。その結果、規制や、時には法的規制のない場所で活動しなければならなくなるかもしれません。例えば、複数の国に複数の法人を持つ大企業では、税金や輸出管理関連の規制があります。

ソリューション

インナーソースイニシアチブを期間限定の実験として宣言します。インナーソース実験に参加するプロジェクトの基準を定義し、伝達します。健全なコミュニティを構築する可能性を最大化する基準を選択してください。実験の文脈の中でそこから生み出された洞察が、他のインナーソースプロジェクトの可能性を含む文脈に直感的に適用できるならば、一連の基準は良いものであると言えるでしょう。 このような基準の例は次のとおりです。

• 開発者の十分な地理的分布

• 開発者の十分な部門別構成

• コミュニティ内の風通しの良さ

• コミュニティ内での能力に応じたキャリアパス

• コミュニティ内での民主的な意思決定

結果の状況

マネージャーが、インナーソースをキックスタートできる理由になりうるのは以下です。

• インナーソースプログラムを以前の典型的なプロジェクトのように精査することが実験的なセットアップにより緩和されます。

• 実験の失敗の可能性が理解され、受け入れられているので、サポートするマネージャーの個人的なリスクが最小限に抑えられます。

• 失敗した場合でも、実験的なセットアップにより、会社は失敗から学ぶことができます。

• 成功した場合、実験中に収集されたデータによって、マネージャーはインナーソースに対してより長期的なコミットメントを行うことができます。

インナーソースの実験参加者は、インナーソースが約束された利益をもたらすことを経営陣に証明する必要があることを認識しています。 したがって、最も実証可能な価値を提供し、成功の可能性を高める活動に集中するのに役立ちます。 また最後に、実験として開始すると、成功の可能性を減らすかもしれないツールやプロセスポリシーなどの規制や力を回避することがはるかに簡単になります。

Related Patterns

事例

• Robert Bosch GmbH (グローバルな分散型ソフトウェア開発組織を有する)

ステータス

• Structured

著者

• Georg Grütter (Robert Bosch GmbH)

謝辞

• Jason Zink (Robert Bosch GmbH)

• Diogo Fregonese (Robert Bosch GmbH)

• Robert Hansel (Robert Bosch GmbH)

• Hans Malte Kern (Robert Bosch GmbH)

• Russ Rutledge (Nike)

• Tim Yao (Nokia)

• Clint Cain (Optum)

翻訳の履歴

• 2023-06-18 - 最終更新

Title

トラステッドコミッター

Patlet

多くのInnerSourceプロジェクトは、コントリビューターからフィードバック、機能、バグフィックスを一貫して受け取る状況にあります。このような状況で、プロジェクトのメンテナーは、単一のコントリビューションを越えてコントリビューターの仕事を認識し、報酬を与える方法を模索します。

問題

• プロジェクトメンテナーは、プロジェクトをサポートする力をスケールする方法を探しています

• プロジェクトメンテナーは、プロジェクトが提供する価値を高める方法を見つけたいと思っています

• プロジェクトメンテナーは、頻繁に貢献している人に目に見える形で報い、彼らの価値貢献を拡大させる力を与えたいと考えています

• 組織内のチーム間の貢献を認識するための仕組みや言語がない

状況

• あなたはチーム横断的なライブラリ、サービス、または共有リソースのメンテナーです

• あなたは定期的にコントリビューションを受けます

• あなたは定期的に機能のリクエストを受けます

• あなたは定期的にバグフィックスのリクエストを受けます

• InnerSource プロジェクトを通じて専門知識を身につけようとする意欲的なコントリビューターがいます

組織に働く力学

• プロジェクトのライフサイクルの中で、変化するビジネスの優先順位に対応するため、メンテナーのフォーカスがずれることがあります

• コントリビューターは、自分たちのコントリビューションが目に見える形で認められ、その価値が示されることを求めています

• 小規模なチームにとって、それなりに複雑なプロジェクトを維持することは大きな負担になります

• プロジェクトの機能を大規模に開発することは、小規模なチームにとって負担になります

ソリューション

プロジェクトの トラステッドコミッターの役割を定義する

トラステッドコミッターが何を担当するかは、各プロジェクトとそのメンテナー次第です。トラステッドコミッターの役割の範囲について、プロジェクト内で文書化することを忘れないようにしましょう。明確な文書化によって、新しいコミュニティのメンバーに対する期待値を設定し、将来の候補者のために役割を確立します。 トラステッドコミッターの候補者を特定するためのガイドラインは以下のとおりです。

• コミュニティチャネル (Slack、JIRA issue triaging など) に積極的に参加している人はトラステッドコミッターになり、コミュニティサポートにおける役割を正式に決定することができます

• コード、ドキュメント、その他のリポジトリの変更を頻繁に提供する人をプルリクエストに参加させることから始めましょう。この人が積極的にプルリクエストに参加している場合、プロジェクトにおけるさらなるコラボレーションの機会についてアプローチすることを検討してください

信頼できるコミッターを正式に認定する

最初のステップは、トラステッドコミッターになることについて候補者にアプローチすることです。メンテナーは候補者にトラステッドコミッターの役割について理解してもらう必要があります。候補者がトラステッドコミッターの役割を引き受けることを期待してはいけません。各候補者は、自分がその責任を果たすために必要な余剰リソースを持っているかどうかを判断する必要があります。

候補者がその役割を引き受けた場合、"ユーザー" からトラステッドコミッターへの移行を公の場でアナウンスするかはプロジェクトのメンテナー次第です。また、プロジェクトの README にある [トラステッドコミッター] セクションに名前を追加することもお勧めします。

例としては以下のようなものがあります。

トラステッドコミッターとの関係を維持する

トラステッドコミッターの退任

トラステッドコミッターが以下のような場合、トラステッドコミッターを退任させなければならないことがあります。

• 参加する意思がなくなった

• 責任を果たせなくなった

• 会社の従業員ではなくなった

結果の状況

コントリビューターに対して

プロジェクトのトラステッドコミッターとなることは、コミュニティプロジェクトにコントリビュートするイニシアチブを示すことになります。このような貢献は、上司との年次レビューでの評価に組み込むなどの利用が可能です

メンテナーに対して

プロジェクトが成熟するにつれて、 メンテナーはプロジェクトの重要な側面についてあまりよく知らなくなることがあります。トラステッドコミッターはこのようなギャップを埋め、プロジェクトのあらゆる側面をより良くすることができます。 トラステッドコミッターを健全に組織に配置することは、メンテナンス担当者が進むにあたり、職務遂行のための責任がある管理計画の所在を保証することになります。

事例

この事例は、試行錯誤のすえ以下の企業で成功しています。

• Nike

• PayPal

ステータス

• Structured

• Nike の社内で公開、2018年6月にプルリクエストで起草

著者

謝辞

翻訳の履歴

• 2023-06-18 - 最終更新

Title

成熟度モデル

Patlet

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

問題

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

状況

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

組織に働く力学

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

チームは、「ソフトウェアのへの移行がすべてだ」と考えています（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-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 - 最終更新

Title

リポジトリアクティビティスコア

Patlet

潜在的なコントリビューターは、彼らの助けを必要とするアクティブなインナーソースプロジェクトを見つけたいと思っています。各プロジェクトのリポジトリのアクティビティスコアを計算することで、プロジェクトのランク付けされたリストを作成することができます (参考: )、そのため、潜在的コントリビューターは、彼らがコントリビュートしたいプロジェクトをより簡単に決定できます。

問題

インナーソースのプロジェクトはどのような順番で表示されるべきでしょうか？ GitHubのスター数, フォーク数, コミット数, コードの行数, 最終更新日時 などの典型的なKPI は、プロジェクトの活動状況を簡潔に示すには十分ではありません。

活発なプロジェクトはもちろん、新しいコントリビューターを必要としているかなり新しく熱心なプロジェクトも、成熟したプロジェクトで活動が少ないものやメンテナンス中のものよりも上位にランクされるべきでしょう。

プロジェクトのアクティビティレベルについて、信頼性が高く汎用性のあるスコアを定義するために、いくつかのKPIから派生した新しい評価指標が必要になります。この指標は、プロジェクトのアクティビティレベルに応じて、プロジェクトを分類するために使用されます。

ケーススタディ

インナーソースが長期間実践されている場合、または特定の数のプロジェクト(意味のあるしきい値を与えるために50としましょう)を超えて拡がっている場合、現在最も人気がありアクティブなインナーソースプロジェクトを見つけるのは困難です。 長い間存在するプロジェクトはよく知られていますが、もはやあまり活発ではないかもしれません。 一方、かなり新しいプロジェクトには、まだ評判や活発なコミュニティがありません。

インナーソースプロジェクトのリストは、静的なリソースと考えるべきではありませんが、ちょうどその日の最も興味深いトピックを最初にリストするニュースページのように、新しいアクティブなプロジェクトを発見し探索するためのエキサイティングな場所です。したがって、プロジェクトの順序が定期的に更新され、プロジェクトの人気と活動に応じて変更された場合、それは有益であると言えます。

これらの考慮事項を加味し、リポジトリアクティビティスコアを計算する最初のプロトタイプが開発されました。 このプロトタイプは驚くほどよく機能し、プロジェクトの活動状況に応じて常に変化する順序を決定することができます。

状況

インナーソースプロジェクトの発見は、 と パターンで促進されるか、他のコミュニケーションチャネルやプラットフォームでプロジェクトを促進することで可能になります。アクティビティスコアは、プロジェクトがコミュニティに提示されるデフォルトの順序を定義しています。

組織に働く力学

GitHub API で取得できる自動化された KPI は、全ての事柄のうち一部しか示せていません。コードの品質や優れたドキュメントの有無、活発で助け合うコミュニティなど、そのプロジェクトが楽しくコントリビュートできる場所であるかどうかも重要な事項です。

このような「ソフトなKPI」は、手動または半自動で計算と結果のスコアに追加する必要があります。もし、コードカバレッジレポートのような、リポジトリにより多くのコンテキストを提供するツールがあれば、簡単に取り入れることができます。

スケッチ

ソリューション

リポジトリアクティビティスコアは、インナーソースプロジェクトの(GitHub)活性度を表す数値です。GitHubスター、ウォッチ、フォークなどのリポジトリ統計から自動的に導き出され、他のツールからのKPIや手動評価で付加情報が足されることもあります。

さらに、最終更新日やレポの作成日などの活動パラメータを考慮し、多くのトラクションを持つ若いプロジェクトに活力を与えます。 コントリビューションガイドライン、積極的な参加統計、課題(公開バックログ)を持つプロジェクトも、より高いランキングを受け取ります。

以下のコードでは、変数 repo に GitHub search API から取得したエンティティを、Participation オブジェクトに GitHub stats/participation API から取得したエンティティを格納することを仮定しています。

結果の状況

コントリビューターは、時間の一部をインナーソースプロジェクトに自由にコミットできます。 彼らはまっさきに彼ら自身のチームの仕事において使っているプロジェクトへのコントリビューションを選ぶかもしれません。しかし、人によってはそれぞれの興味や個人的な開発目標に基づいて、まったく異なる何かにコントリビュートすることを選択するかもしれません。

プロジェクトはリポジトリアクティビティスコアで並べ替えて表示できるため、ポータルで意味のある順序を指定して潜在的な新しいコントリビューターに見てもらうことができます。スコアは、プロジェクト進行中に計算することも、すべてのプロジェクトを定期的に評価して結果のリストを保存するバックグラウンドジョブで計算することもできます。

理論的解釈

リポジトリアクティビティスコアは、GitHub API に基づくシンプルな計算です。完全に自動化することができ、新しい要件にも簡単に対応することができます。

事例

ステータス

• Structured

# 著者

謝辞

InnerSource Commons Community の迅速なアドバイス、そしてこのパターンを養うための多くの有益な意見に感謝します!

• Johannes Tigges

• Sebastian Spier

• Maximilian Capraro

• Tim Yao

翻訳の履歴

• 2023-06-18 - 最終更新

Title

正式なコミュニティリーダー

Patlet

インナーソースの取り組みを成功させるために、コミュニケーションとテクニカルの両方のスキルを持つ人をコミュニティのリーダーとして選ぶ。

問題

新しいインナーソースのイニシアチブがその影響を拡大するために適切なコミュニティリーダーを持っていることを確認するにはどうすればよいか 間違った人を選択し、またはそれらのために十分なキャパシティを提供しないことは、無駄な努力と、最終的に新しいインナーソースイニシアチブの失敗を引き起こすリスクになる

ケーススタディ

次のようなストーリーを考えてみましょう。ある企業が、組織の境界を越えたコラボレーションを促進するために、インナーソースイニシアチブを始めたいと考えています。彼らは、範囲を限定した実験的な段階から始めることを決定しました。経営陣は、最初のインナーソースコミュニティに適したパイロットトピックを選択し、組織全体の多くのビジネスユニットからのコントリビューションを期待しています。会社はまだ完全に計画をできていなかったので、新入社員をコミュニティの責任者に指名し、業務時間の50％を割り当てました。6か月後、コミュニティにはわずかなコントリビューションしかなく、そのほとんどはひとつのビジネスユニットからのものでした。そこで、コミュニティリーダーを社歴の長い人物に代え、今度は30%の時間しか割かないようにしました。さらに6ヶ月後の結果は、コントリビュートがわずかに増加したのみでした。同社は、部門を超えたコラボレーションを増やす目標を達成するのに、インナーソースが役立つと確信できなくなり、インナーソースを放棄しました。

状況

• この会社は大企業で古い会社で、またオープンソースやその他のコミュニティベースのワークモデルの経験がありません。企業文化は古典的なトップダウン経営スタイルとして最もよく特徴づけられています - それは一般的にコミュニティ文化とは相反するものです。

• トップレベルの支持者とスポンサーがいる一方で、会社の中間管理職はまだインナーソースの価値を納得できていません。

• 経営陣は、パートタイムのコミュニティ・リーダーに対し、限られた予算以上のリソースを提供することに納得していませんでした。

• 最初に選ばれたコミュニティのリーダーは、オープンソースの作業モデルについてほとんど、あるいは全く経験がありません。

• 最初に選ばれた開発者コミュニティのリーダーは、社内に広いネットワークを持っていません。

組織に働く力学

もし、企業がインナーソースの予算とキャパシティの面で初期のインナーソースコミュニティに大幅に投資していない場合、インナーソースへのコミットメントの信頼性は疑わしいと認識されるかもしれません。期待通りに実行されていないプロジェクトやイニシアチブに対する伝統的な管理文化を持つ企業の一般的な動きは、そのリーダーを交換することでしょう。コミュニティを巻き込むことなく、そして功績至上主義の原則に従わずに活動を行うことは、現在の企業文化とコミュニティ文化との間の摩擦を強調することにつながり、インナーソースへの企業のコミットメントをさらに弱体化させます。 インナーソースプロジェクトにおける価値の貢献は、従来のプロジェクト管理方法に慣れ親しんでいる多くのマネージャーにとっては明らかではありません。これらのマネージャーは、通常は非インナーソースプロジェクトから高い需要があるトップクラスの人物の1人を、作業時間のかなりの割合でインナーソースプロジェクトに割り当てる可能性が低くなります。 コミュニケーションは、コミュニティリーダーの日常業務のかなりの割合を占めています。同時に、担当者は初期開発の先頭に立つ必要があるでしょう。限られたキャパシティに直面して、経験の浅いリーダーは開発に集中し、コミュニケーションを怠る傾向があります。コミュニティリーダーが連絡を取りにくい場合や、時間不足のためにフィードバックや質問への回答が遅い場合、潜在的なコントリビューターが最初のコントリビューションをしてコミュニティにコミットするための障壁ははるかに高くなります。さらに技術的に経験の浅いリーダーは、企業で目立つトップパフォーマーと比べると、経験豊富なコントリビューターを引き付けて維持するのに苦労する可能性があります。 もしコミュニティが十分に速く成長し、十分なスピードを手に入れることができなければ、インナーソースの可能性を説得力を持って示すことができない可能性があります。 もし会社が伝統的な管理手法に慣れた経験豊富なプロジェクトマネージャーやラインマネージャーをコミュニティリーダーに選んだ場合、その人は功績至上主義で模範を示すのではなく、リソース配分、構造、報告ルートといった伝統的な管理テーマに焦点を当てる可能性が高いです。これは、開発者の目から見たインナーソースイニシアチブの信頼性を損ねることになります。

ソリューション

以下のようなコミュニティリーダーを選択します。

• オープンソースの作業モデル、または類似のコミュニティベースの作業モデルの経験がある

• 自然なリーダーとして活動するために必要なソフトスキルを持っている

• 模範を示して指導し、コミュニティの功績至上主義において自分の立場を正当化することができる

• 優れたネットワーカーであること

• コミュニティーのメンバーにインスピレーションを与えることができる

• 経営陣と開発者の両方に効果的にコミュニケーションをとることができる

• コミュニティ活動の経営的な面を扱うことができる

コミュニティリーダーには、コミュニケーションや開発など、自分の時間の100％をコミュニティ活動に捧げることができるよう、権限を与えましょう。コミュニティ運営に変化をもたらす際には、コミュニティの意見に耳を傾ける必要があることを経営陣に伝え、理想的には、コミュニティが自らコミュニティリーダーを指名できるようにすることが望ましいです。

結果の状況

上記の能力を持つコミュニティのリーダーは、会社のインナーソースへのコミットメントを人前に出て体現することになります。彼のネットワーク内の他の同僚は彼のリードに従い、インナーソースに貢献する可能性が高くなります。

時間が経つにつれて、リーダーは、開発者の安定したコアチームを構築することができ、したがって、インナーソースプロジェクトの成功の可能性を高めることができます。 インナーソースの可能性について社内の十分な数のオーディエンスを納得させることによって、リーダーは企業文化をよりコミュニティ中心のものにする変革に大きく貢献することになります。

優秀で熱心なコミュニティリーダーを持つことは、インナーソースを成功させるための前提条件です。しかし、それは銀の弾丸ではありません。インナーソースには、予算、法律、財政、あるいはその他の組織的な課題など、コミュニティリーダーが取り組める以上の課題がたくさんあります。

事例

Robert Bosch GmbH における BIOS。Bosch社のインナーソースは、大半の場合、イノベーションを高めることを目的としており、かなりの割合で内部向けのプロダクトを扱っていました。このパターンは、資金不足のため、現在Bosch社では使われなくなりました。

その他の呼び方

Dedicated Community Manager

ステータス

• Structured

著者

• Georg Grütter (Robert Bosch GmbH)

• Diogo Fregonese (Robert Bosch GmbH)

謝辞

• Tim Yao

• Padma Sudarsan

• Nigel Green

• Nick Yeates

• Erin Bank

• Daniel Izquierdo

Changelog

• 2016-11-06 - 1st review

• 2017-04-06 - 2nd review

翻訳の履歴

• 2022-06-01 - 翻訳 Yuki Hattori

• 2022-06-21 - レビュー @hirotakatoya

• 2023-06-18 - 最終更新

Title

Short Title Here

Patlet

Concise 1-2 sentence description of the problem and solution. Readers may quickly review dozens of these patlets to discover and browse the larger library of patterns. From http://wiki.c2.com/?PatLet

Problem

What is the problem - crisp definition of the problem. Short description, usually not more than a couple sentences, that describes what the issues and challenges are. Be careful not to morph into information found in other sections below.

Story (optional)

Sometimes there is a story that helps people understand the pattern better.

Context

Where does the problem exist? What are the pre-conditions? Unchangeable before the solution goes into place. The content here is often tied to the applicability of the pattern for other readers: "Do I have this same particular situation?"

Forces

What makes the problem difficult? What are the trade-offs? These are constraints that can be changed at a cost. The solution might change one or more of these forces in order to solve the problem, while also in-turn changing the context.

Sketch (optional)

visual illustration

Solutions

Verified resolutions and possible resolutions to the problem.

Resulting Context

What is the situation after the problem has been solved? The original context is changed indirectly by way of the solution. Often this section can include discussion of the next possible Patterns/problems introduced. This section can be short in content - the solution may not introduce new problems or change much context.

Rationale (optional)

Explains why this is the right solution; using totally different words WHY this solution balances these forces and this context to solve this problem. Can expand on what-if's or theories.

Known Instances (optional)

Where has this been seen before? Helps to reinforce that this is a REAL pattern and that you match the context.

May mention:

• A particular business

• Anonymized instances ex: "3 companies have proven that this is a good solution" or "A large financial services org...".

Status (optional until merging)

General pattern status is stored in GitHub's Label tagging - see any pull request. Note that this GitHub label tagging becomes less visible once the pattern is finalized and merged, so having some information in this field is helpful.

You might store other related info here, such as review history: "Three of us reviewed this on 2/5/17 and it needs John's expertise before it can go further."

Author(s) (optional)

Often, this is yourself. If you need to, find someone in the InnerSource Commons to be the nominal author (As Told To). Could also be no-one if you do not want to take on authorship (common with a donut looking for a solution).

Acknowledgments (optional)

Include those who assisted in helping with this pattern - both for attribution and for possible future follow up. Though optional, most patterns should list who helped in their creation.

Alias (optional)

If this pattern is also known under a different name than what is listed unter Title, please list those alternative titles here. e.g. if the pattern is named after the problem it solves, a helpful alias might be one that describes the solution that is applied.

ミッション

あなたのプロジェクトのミッションについての簡潔な(3〜5行の)説明が含まれている必要があります。このセクションのゴールは、あなたが何に取り組む予定かを述べ、外部のコントリビューターがこのプロジェクトに歓迎されそうな機能の種類をおおよそ理解できるようにすることです。 Producing Open Source Software の Mission Statement Chapter も参照してください。

はじめに

このセクションには、初めてプロジェクトを使う人に向けた、使い始めるための簡単な説明を記載します。さらに詳細なドキュメントにはここからリンクをさせましょう。

詳細

このセクションでは、以下のいずれか、またはすべてを列挙することができます。

• ソフトウェアが対応する機能、ユースケースのリスト

• トレードオフを解決するために使用される設計原理に関する情報

• ユーザーレベルのドキュメントへのリンク

• よくある質問(FAQ)に対する回答。できれば、特定の質問とその回答にリンクして、簡単に参照できるようにした形式が望ましいです。

ヘルプ

このセクションには、ユーザーとしてプロジェクトのヘルプを得る方法についての簡単なドキュメントを記述します。 イシュートラッカーをユーザーに対して指し示すようにシンプルなディレクションでもかまいません。また、アーカイブされ検索可能なチャットチャネルとメーリングリスト、オンラインのユーザーフォーラムを紹介することもできます。

参加するには

このセクションには、プロジェクトと連絡を取る方法に関する情報を含める必要があります。通常これにはアーカイブされた検索可能およびアクセス可能なコミュニケーションチャネルへのリンクが含まれます。

私たちについて

このページは、プロジェクトのトラステッドコミッターに謝意を表すのに良い場所です。 また、このプロジェクトにおいてトラステッドコミッターであることが何を意味するのかについての情報を含めるのにも良い場所です。 理想的には、組織内のすべてのプロジェクトが同じ定義を使用のが良いでしょう。その場合、すべての README が同じ定義へのリンクを貼ることになります。 このリンクを残す理由は、インナーソースのプロジェクトで働いたり貢献した経験がない、もしくは少ない同僚が、日々の仕事に必要な技術プロジェクトから会社全体の情報へのダイレクトリンクを持てるようにするためです。

コントリビューションについて

このセクションでは、初めての人がコントリビュートを始めるために知っておく必要があるすべての事柄についてドキュメント化(もしくはリンクを貼る)する必要があります。 以下のトピックのすべてがカバーされることは希ですが、あなたのプロジェクトが標準的なセットアップと何が違うのか、以前のコントリビューターが理解しにくいと感じたことに重点を置いて書いてください。

• ソースコードを見つける方法

• プロジェクトで助けを必要としている問題のリストを見つける方法。これらの問題は、技術的・非技術的な両方の問題になりえます。通常、これらの問題は、コントリビューターがアクセスできるイシュートラッキングシステムも掲載されます。

• プロジェクトのアーキテクチャ、一般的なコーディング規約、テスト規約など、さらなるドキュメントへのリンク

• 技術的なコンとリビューションについて、変更を加え、プロジェクトをビルドし、変更をテストする方法

• 変更した内容をプロジェクトにサブミットする。

理想的には、プロジェクトにとって望ましい変更プロセスがどのようなものであるかについての情報も含めてください。コントリビューターはまずイシューを作成して提案を提出すべきなのか、それともすぐにでも変更を提出することができるのか。投稿をレビューする際に重要なことは何ですか?

さらに、プロジェクトで守りたい設計の価値観についても概要を説明しておく必要があります。これらを明示することで、トレードオフをより早く、より簡単に解決できることがよくあります。さらに、暗黙の前提に対する変更を透明化するのにも役立ちます。

時間が経つにつれて、このセクションがかなり大きくなっていることに気がつくと思います。その場合は、例えば CONTRIBUTING.md と TESTING.md のように、情報を別のファイルに移動することを考えてみてください。

コントリビューションの種類

プロジェクトがどのような種類のコントリビューションを求めているのか、ここに情報を提供してください。例えば、バグレポート、ユーザーの質問に対する回答、ドキュメントの改善、バグの修正、新機能の実装などです。

バグレポート

バグレポートの提出方法に関する情報をここに追加してください。これには、問題を再現し修正するためにプロジェクトがどのような情報を必要とするかについてのヒントが含まれるべきです。また、よく見られるバグのような設定ミスの情報も含めることができます。

また、初動までの時間やその後のプロセスなどに関して、コントリビューターが期待すべき情報についても記載してください。

機能リクエスト

機能リクエストを提出する方法についての情報をここに追加してください。また、初動までの時間やその後のプロセスなど、コントリビューターが期待すべき情報についても記載してください。

ドキュメントに対するコントリビューション

プロジェクトが遵守しているドキュメントのベストプラクティスや、ドキュメントの構築方法、チェック方法、プロジェクトに変更を戻す方法などの情報を含めてください。

ソースコードに対するコントリビューション

このセクションでは、以下の情報を提供します。

• プロジェクトのソースコードにアクセスする方法

• プロジェクトの一般的なレイアウト

• 開発環境に対する要求事項

• コードの書式に関するガイドライン

• テストの実行方法

トラステッドコミッターになるには

このセクションでは、トラステッドコミッターになるためのプロセスがコントリビューターに開かれている場合、そのプロセスを明示する必要があります。

トラステッドコミッターをノミネーションする方法

このセクションは、既存の トラステッドコミッターへのリマインダーと、新しい トラステッドコミッターへの説明として、他のメンバーをホストチームに追加する方法について説明するものです。繰り返しになりますが、この情報は組織内のすべてのプロジェクトで同じものであることが理想的で、ここから中央の情報にリンクさせることができます。

Title

持続可能な成長のためのエクステンション

Patlet

インナーソースプロジェクトは多くのコントリビューションを受けており、メンテナンスが難しくなっています。メンテナは、プロジェクトのコア部分から離れた拡張機構を提供することで、最小のコストとメンテナンスオーバーヘッドでプロジェクトの能力をスケールアップすることを可能にします。

問題

成熟したインナーソースリポジトリへのコントリビューションが急速に増えると、コードレビューやメンテナンスの負担が増大します。これにより、大量のコードレビューのバックログが生じたり、新しい機能のコントリビューションが早期に拒否されたりする結果となります。

ホストチームは、新しい機能のリリースをより早く行い、イノベーションと実験を奨励しつつ、リポジトリを適切にメンテナンスするためにはどのようにすればよいのでしょうか？

ストーリー

特定のドメインスペース内での最高のイノベーションを一つの共通スタックに集め、共通のインフラストラクチャの再利用を可能にし、標準的なユーザーエクスペリエンスを提供することを目指す戦略的なプロジェクトが存在します。インナーソースを通じて、組織内の各チームは、そのドメインスペース内で働きながら、共通のコードベースにイノベーションをコントリビューションする機会を得ます。

しかし、複数の開発者からの並行したコントリビューションが多くなると、コードベースのメンテナンスが難しくなります。 それは、プロジェクトのメンテナはコードの品質基準に対するオーナーシップを引き受けることになり、さまざまな形式のコミュニケーションを通じてコミュニティを支えるという大きな負担がかかるからです。

プロジェクトのメンテナは以下のようなリスクに直面しています:

• コントリビューターからのプルリクエストのバックログが絶えず存在する

• 職業の不満: メンテナの時間の大部分がコミュニティサポートの支援に使われてしまい、新しいことに挑戦する時間がない

• 成果感の欠如: 提供されたすべての機能が適切なユーザー需要を満たすわけではなく、それによって結果的に採用されるとは限らない

• リリースに時間がかかる: コードベースに多くの機能があると、テストに時間がかかる

• メンテナンス活動の増加: 新しい機能が追加されると、バグが増える

可能性のあるユーザーがその機能を自分のユースケースに適用する機会を得る前に、新しい機能のコントリビューションが成熟するまでに多くの時間が費やされています。もし新しい機能がユースケースを満たさなければ、求められていたコード品質基準を達成するために費やした全ての時間が無駄になります。

状況

• 戦略的なインナーソースコードベースが、多数の従業員からの新機能のコントリビューションで急速にスケールアップしています。

• レビュアーとコントリビューションの比率により、プルリクエストのバックログが増加しています。これにより、新機能のリリースがコミュニティに対して遅くなっています。

• コードベースの品質が劣化し、ユーザーエクスペリエンスが悪化しています。

• コードベースのメンテナが負荷を感じ、コントリビューションの増加とコミュニティサポートの増加に対応できなくなっています。

• 提供された機能の一部はユーザーに採用されず、完全に不活動になる可能性があります。しかし、それらが使用されていないにもかかわらず、これらの機能は依然としてメンテナンスのオーバーヘッドを増やしています。

• 組織は、新しい機能のコントリビューションを品質基準を保持するために厳しく対応している一方で、コミュニティがアイデアを探求する前に大量の投資を行っています。

• 次の2つのシナリオのどちらかでパターンが適用されます:

  • メンテナがプロジェクトの範囲を絞り込むために、自身で新しい機能のアイデアを拒否することにより、コミュニティのイノベーションを阻害し、さらなる拡大を制限しています。

  • バックログを減らすために、新しい機能が十分なドキュメンテーション、ハードニング、テストなしにリリースされ、ユーザー体験が悪化します。これにより、コードベースのサイズが大きくなり、依存関係が大きくなり、メンテナンスが難しくなります。

組織に働く力学

• メンテナとプロダクトオーナーは、拡張、イノベーション、実験を促進しつつ、コントリビューションに対して過度に制限を設けずに、良好なコードと品質基準を保持したいと考えています。

• 特性を製品基準に適合させ、徹底的にテストするために多くの時間が費やされますが、製品オーナーは新しいイノベーションを機能が成熟する前に製品が探求できるように、新しいイノベーションのリリースを早めたいかもしれません。

• メンテナは、プライマリリポジトリにより多くの依存関係を追加せずに、コミュニティが製品の機能と他のユースケースを組み合わせたイノベーションを共有することを奨励したいと考えています。

ソリューション

高規模なインナーソースコードベースへの拡張/プラグイン(英語)を許可することで、リポジトリのメンテナに対するメンテナンスの負担を軽減し、新機能のリリースを探求する製品のリリースを早めることができます。これにより、機能のメンテナンスを拡張所有者に移し、プライマリリポジトリがより広範に採用され、より戦略的にサポートされる機能を支援することが可能になります。

拡張機能は、最終的にプロジェクトのコアに移動する可能性のある新たな機能のフィルターとして機能します。また、拡張機能はインキュベーションとコミュニティのハードニング環境としても機能し、そのハードニングが高価なレビュープロセスではなく、自然に行われるようにします。

拡張モデルを成功させるためには、いくつかのアーキテクチャ上の考慮事項が必要です:

1. 作成が簡単: コミュニティの参加を得るためには、拡張機能を簡単に作成できる必要があります。

   • 拡張機能がスタートポイントとして使用するべきリポジトリテンプレートを作成します。これにより、拡張機能は新しいリポジトリに新機能を追加することができ、コアプロジェクトとは別になります。テンプレートはプライマリリポジトリと同じモジュール構造を提供し、拡張機能のパッケージ化とリリースのフレームワークを含むべきです。

     • プライマリリポジトリが変更されると、テンプレートが適切に保守されていることを確認します。プライマリリポジトリのメンテナがテンプレートを更新し、メインプロジェクトとの互換性を保証します。良いバージョニング規則を守ること、例えば、semverの使用がこれを容易にします。

     • さらに、新しいバージョンがリリースされると、プライマリリポジトリのメンテナが古いバージョンのテンプレートに基づく拡張機能の更新方法についてのガイドラインを提供することを推奨します。

   • テンプレートから開発された拡張機能の例を追加します。これにより、プロジェクトの開発者は、どのようにして良いパターンの拡張機能を書くべきかを理解することができます。

   • レビューをバイパスして拡張機能を作成する寄稿者の要件を緩和し、リリースや実験を早めることを許可します。

2. 疎結合: 機能を含むモジュラーなコンポーネントを持つことで、拡張機能への変更がメインコードベースや他の拡張機能の品質に影響を与えない疎結合を可能にすることができます。

3. 依存性管理: 各拡張は、それが構築されるプライマリリポジトリのバージョン範囲をピン留めするように注意する必要があります（他の依存関係と同じように）。また、それがプライマリリポジトリの依存関係をシャドーする他の依存関係の使用についても注意深くなければなりません。選択した依存関係のバージョンがプライマリリポジトリの選択したバージョンと互換性があるようにします。プライマリリポジトリとの任意の競合は、拡張のテストフレームワークで検出できます。

4. テスト戦略: 拡張機能を個別に、または組み合わせてテストする方法は？

   • 拡張機能を個別にテストする: 拡張機能のテンプレートは、拡張機能の開発者が追加した機能をテストするためのテストフレームワークを提供します。これには、ユニットテスト、ランタイムパフォーマンステスト、品質テストのフレームワークが含まれることがあります。

   • 拡張機能をプライマリリポジトリと組み合わせてテストする: 拡張機能の開発者は、プライマリリポジトリの特定のバージョンに対して自分の拡張機能をテストするための良好なパターンの方法を持つべきで、これにはプライマリリポジトリのメンテナの関与は必要ありません。

   • 拡張機能を他の拡張機能と組み合わせてテストする: このシナリオのためにテストフレームワークを提供することは、特に、ユーザによってまだ調査中であり、すべての拡張機能を組み合わせて使用する可能性が低い多数の拡張機能がある場合、過剰になる可能性があります。もしユーザが拡張機能を組み合わせて使っているときにコンフリクトに遭遇した場合 (十分な疎結合であればありえないはずです)、ユーザはそれぞれの拡張機能の所有者に問題を提起することができます。拡張機能がライフサイクルの後半に達し、プライマリリポジトリにマージされるようになると、ライブラリの残りの部分と組み合わせてテストされるようになり、依存関係の衝突はその時点で解決されなければならなくなります。

5. 発見性と利便性:

   • ユーザーが作成し、製品の使用に共有したいと思っている拡張機能を表示する公開ページで、拡張機能を容易に発見できるようにします。

   • ユーザーが元のプロジェクトと一緒に拡張機能を利用できるように、プライマリプロジェクトに拡張機能の登録を許可します。これにより、同じユーザーエクスペリエンスが維持されます。

6. 拡張機能のライフサイクルと保守性: 拡張機能の作成からプライマリコードベースへの移植までのライフサイクルを確立し、明確な所有権ガイドラインを作成します。

   • 拡張機能の作成者は、拡張機能のメンテナンスを続け、サポートを提供し、欠陥を修正します。保守されていない拡張機能は、公開ページからリストから削除されます。

   • 内部製品による拡張機能の採用と機能への需要など、プライマリリポジトリへの移植が可能になる基準を作成します。

   • 拡張機能のプライマリリポジトリへの移植プロセスは、ライブラリメンテナによって設定されたより厳格なコードレビューガイドラインに従います。

これらの原則に従うことで、以下が確保されます:

• 開発者は、大量のボイラーテンプレート(定型)コードを書くことなく、プロジェクトのエコシステムに新しい機能を追加することができます。

• 拡張機能は、プライマリプロジェクトの全てのユーザーによって反復可能な方法で発見できます。コードがまだメインリポジトリに存在していないとしても、それが価値がないわけではありません。

• メンテナの負担は、拡張機能がプライマリプロジェクトで重要なギャップを埋めていることを示すまで軽減されます。

• コアプロジェクトの共通コード（例えば、ベースクラスやユーティリティ関数）は、プロジェクトの領域を拡張する新しい開発の出発点となります。これにより、革新的な作業を後から移植する必要がなくなり、プロジェクトにとって新しい機能を開発する全体的な負担を軽減します。

• 開発者は、コードベースのためのコミュニティのメンテナンスとコミュニティ構築にコントリビューションし、関与し続ける可能性が高くなります。これは全体のプロジェクトエコシステムの健康にも良い影響を与えます。

結果の状況

• プロジェクトは、新しい機能の追加により拡大することができ、プライマリプロジェクトリポジトリにメンテナンスのオーバーヘッドを追加することなく、拡大することができます。

• コミュニティが探求する新機能のリリースが早まり、革新と実験を奨励します。

• 機能がその有用性を証明するまで、高額なコードレビューと機能強化プロセスが削減されます。これにより、組織に対するコスト節約の利益が得られます。

• 一つの問題が導入される可能性があります - 拡張機能がフルライフサイクルを完了できない場合、何が起こりますか？

  • 拡張機能が一定期間採用されず、それをサポートするコミュニティを形成できなかった場合、そのメンテナンスを続けるかどうかは拡張機能のオーナー次第です。もし拡張機能がメンテナンスされなくなった場合、それは非公開になります。

  • 拡張機能の開発者がそれ以上のプロジェクトを維持できなくなり、コミュニティ内の他の開発者がそれを引き続きサポートしたい場合、彼らはその拡張機能の維持を進めていくことができます。

事例

• IBM社は、インナーソース AIライブラリを拡大するためにこの解決策を採用しています。拡張機能を使用することで、開発者はAIライブラリに更に多くのアルゴリズムを追加し、彼らの革新を企業内のコミュニティと共有することができます。コアライブラリには、採用されて検証された戦略的なアルゴリズムのみが含まれており、これにより我々はコントリビューションをスケールするにつれてそれらをより簡単に維持することができます。

エイリアス

大規模にコントリビューションを管理するための拡張

ステータス

• Structured

著者

• Sukriti Sharma, IBM

• Alexander Brooks, IBM

• Gabe Goodhart, IBM

Title

共通要件

Patlet

共有リポジトリにある共通のコードは、それを使いたいすべてのプロジェクトチームのニーズを満たしていません。これは、要件の調整とリファクタリングによって解決されます。

問題

共有リポジトリにある共通コードは、それを使いたいすべてのプロジェクトのニーズを満たしていません。

状況

• すべてのプロジェクトがアクセスする共有リポジトリがあり、多くのプロジェクトが共通のコードを使おうとしています。

• 誰かが(またはどこかのプロジェクトが)最初にコードを書き、リポジトリにコントリビュートしました。

• 共通コードは、どのプロジェクトにおいても、成果物全体のうちのわずかな割合になります。

• 各プロジェクトには、それぞれ独自の納期、成果物があり、別の顧客がいます。

• このパターンは、これらの状況のいずれにも当てはまります。

  • 強いコードへのオーナーシップ: つまり、共有リポジトリへのすべての変更は、リポジトリの所有者によって承認されなければなりません。

  • 弱いコードオーナーシップ: つまり、誰も本当にコードを所有していません。

  • 慈善のスポンサーがいない: つまり、インナーソースの方法で共通コードを整理するためのリソースを提供する組織や幹部がいません。

組織に働く力学

コードを利用可能にしたプロジェクトには、ひとつのニーズがあります。そのニーズは、一部の受けての組織が望んでいるものと似ていますが、まったく同じではありません。コードに関する要件は、実際の顧客のニーズから導き出される必要があります。

異なる顧客のニーズが非常によく似ることはよくありますが、顧客によって表現が異なったり、重みが異なったりすることがあります。例えば、ある顧客はとある方法で結果を表示し、他の顧客は逆の順序で結果を表示することを望むような場合があります。両者の変換は簡単ですが、一方のケースで追加のコーディングが必要になり、その結果として、結果を計算するモジュールを両方の顧客で再利用することができなくなります。

多くの顧客は、サプライヤーに何が必要かを知るための手助けを望んでいます。この会社では、多くの「システムエンジニア」が製品の要求事項を書いています。これらの要件は、製品の開発を導くために顧客のニーズを抽出したものであると考えられています。コードの再利用は、会社の時間とお金を節約するための重要な目標になっています。

多くの顧客は、サプライヤーが必要なものを知るのを手伝ってくれることを望んでいます。同社には、製品の要件を作成するための多くのシステムエンジニアがおり、それらの要件は製品開発の指針となる顧客ニーズの抽出物であるとされています。コードの再利用は、会社の時間とお金を節約するための重要な目標です。

ソリューション

この問題を解決するには、2つの側面があり、並行して行う必要があります。

1. あるプロジェクトの要件を満たすコードが、他のプロジェクトのニーズも満たすように、プロジェクトの要件を調整する

2. コードをリファクタリングして、多くの使用プロジェクトが要件に同意できるような小さな断片にする。

さらに、サプライヤーに要件の解明を助けてほしい顧客を活用します。 コンポーネントを変更するのではなく、顧客との交渉中に要件の調整を行い、顧客の要件に影響を与えます。 上記の例では、サプライヤーは両方の顧客が同じことを望んでいることを認識できるように支援し、同じ形式で結果を受け入れることに同意すれば、すべての人の労力(およびお金)を節約できます。

結果の状況

これには、要件の変更について顧客と交渉する必要がある場合があります。そして、変更には要件を調整するために営業チームと製品マネージャーの関与が必要になる場合もあります。また、顧客は変更の同意の代わりに、割引などのインセンティブが必要になる場合があります。

これに関連する課題(新しいパターンの可能性)として、インナーソースを採用しているとある企業で報告されている「循環型ストーリーライティングの試行」があります。 これは、端的に言うと以下のようなことです。

• 開発者は、ある方法で問題を解決するためにストーリーを書きます。

• プログラムマネージャーはそのストーリーを自分たちのニーズをよりよく表現するために書き直します。しかし、開発者のもとに戻ってきたときには、開発者はそれが自分たちが最初にやりたかったことだと認識しておらず、そのため実装に躊躇してしまいます。

• このパターンの解決策は、開発者やプログラムマネージャーの陣営だけでなく、プロジェクト全体でストーリーの修正が理解されるように、プランニングの際により多くの人を巻き込むことが挙げられます。

事例

• 大手通信事業者

ステータス

• Structured

著者

Robert Hanmer

謝辞

• Manrique Lopez

• Daniel Izquierdo

• Tim Yao

• Sebastian Spier

翻訳の履歴

• 2022-06-02 - 翻訳 Yuki Hattori

• 2023-06-18 - 最終更新

Title

基本原則ガイダンスの文書化

Patlet

「オープンソースのベストプラクティスを組織内に適用する」という通常のインナーソースの説明は、オープンソースのバックグラウンドがない人々にはうまく機能しません。 解決策として、インナーソースの最も重要な原則を文書化し広く公開しましょう。

問題

この組織は、インナーソースをより大規模に展開しようとしています。この取り組み自体はオープンソース愛好家のなかで始まりました。現段階の目標は、オープンソースの経験がない人たちからの賛同を得ることです。その人たちに伝えるためのツールとして「オープンソースのベストプラクティスを適用する」という典型的なスローガンは最適ではありません。この伝え方では、そもそもインナーソースがなんであるか、また問題の解決のためにどのようなツールを使うべきなのかは伝わりません。結果として、組織におけるインナーソースの適用が遅くなることにつながります。 チームはインナーソースのゴールが何であるか、そしてどうやったら最適の実装方法を見出せるのかを場当たり的なアイデアをもとに解決しようと試みます。しかしそれはコントリビューターがチームの境界を越え始めたときに混乱を引き起こす結果にも繋がってしまいます。

ケーススタディ

ある組織での初期の実験では、オープンソースコラボレーションのベストプラクティスが有益であることが示されました。次のステップは、オープンソースの深いバックグラウンドがないチームや個人にそのイニシアチブを移すことです。 そして今の目標は、インナーソースイニシアチブの目標と、これらの目標達成に向けた明確な道筋を明確に伝えることです。

状況

• インナーソースという言葉が社員の間で広がり始めています。

• イニシアチブ自体はオープンソースの愛好家の間で始まった取り組みでした。

組織に働く力学

• チームは、インナーソースの重要な側面が何であるかを正確に伝えるのに苦労しています。

• オープンソースの経験が不足している人々は、オープンソースのベストプラクティスを組織にもたらすことの意味を理解することができません。

• 日常的にインナーソースのベストプラクティスに従おうとするチームは、自分たちがやっていることが一般的なインナーソースの典型例に沿っているのかを判断するのに苦労しています。

ソリューション

組織内でインナーソースの取り組みを推進する人は、オープンソースの深いバックグランドを持たず、インナーソースを直感的に理解できていないチームや個人を支援する必要があります。

以下の2つの分野を文書化することで、チームや個人に対して明確な情報を提供する必要があります。

1. 目的 - なぜ組織はインナーソースを採用するのか？

2. 原則 - どのインナーソースの原則は、これらの課題に対処するのに役立つのか？

以下のセクションでは、この2つの詳細について説明します。あなたの組織が目的と原則を文書化するために、このセクションはよい出発点になるでしょう。

なぜ組織はインナーソースを採用したいのか？

かつてよりインナーソースは、組織で発生する一般的な問題を解決するのに役立つことが証明されています。しかし幾多ある組織的な課題のうち、あなたの組織がインナーソースを用いて解決したい課題はなんでしょうか。その問題を特定するためには一般化するのではなく、組織の課題に一致するソリューションを正確に特定するようにしてください。できれば、目に見える変化を求めているチャレンジを特定するのが好ましいです。

他の個人や組織がインナーソースのベストプラクティスに従うことによって対処しているいくつかの課題があるので、見ていきましょう。

• 強力なオーナーシップを求める文化によって引き起こされる開発のサイロを減らすため

• 健全なコードの再利用を促進することにより、類似の問題の解決に費やす時間を短縮し、イノベーションの速度を向上させるため

• より良いクロスチームのコラボレーションによって開発速度を向上させるため

• 依存関係があるプロジェクトやチームの連携を、ワークアラウンドを開発したり、ただ単純に待つのではなくエンジニアリングにおけるボトルネックを減らすことによって解決するため

• 品質を向上させるため

• 従業員の幸福度を高めるため

• 新入社員の成功の数を増やす

• アクショナブルなドキュメントをつくる

どのインナーソースの原則がこれらの課題を解決するのに役立つのか？

チームがインナーソースがどのような問題に対処するのに役立つかをひとたび理解したら、次のステップは、これらの課題に対処するのに役立つ原則を説明することです。 基本的なオープンソース開発の原則に基づき、以下のガイドラインが成功に役立つと証明されています。

(1) コードは、組織内で透明性を持ってホストされなければなりません。 ソースコード、ドキュメント、プロジェクト開発に関連するデータは、組織内の誰もが利用でき、簡単に見つけることができる必要があります。

(2)機能リクエストよりもコントリビューション

プロジェクトのすべての関係者は、潜在的なコントリビューターとして扱われ、サポートされます。コントリビューションはリクエストではなく、提案にとどめましょう。 コントリビューション前にきちんと連携をしておくことにより、無駄な労力を省くことができます。 プロジェクトは摩擦を避けるためにコントリビューションのガイドラインを提供します。

(3) 失敗することは学習をするチャンスであるということ

組織全体で仕事が見えるため、どんなミスもメンバーに見えてしまいます。「ミスは何としても避けなければならない失敗」ではなく「学習のための機会である」という文化が確立されなければなりません。

(4) 口頭より文字で伝える

複数のチームにまたがるプロジェクトでは、潜在的に会議のスケジュールが異なるため、非同期でのコラボレーションを可能にする必要があります。インナーソースのプロジェクトのゴールは、新しいコントリビューターを集めることです。そのため潜在的な将来のコントリビューターがプロジェクトに参加するハードルを下げることが必要であり、セルフサービスでプロジェクトの進捗状況を追跡することができるようにしておく必要があります。プロジェクトに関連するコミュニケーションが同期的なコミュニケーションを介して行われる場合、議論された内容は、ドキュメンテーションのチャネルで透明化しておく必要があります - 最終的な意思決定はそのコミュニケーションチャネルでのみ決定されるべきです。 このことは副次的な効果として、プロジェクトに新しく参加する人にとって非常に価値のある受動的なベースドキュメンテーションにつながります。

(5) 書面によるアドバイスを永続的で検索可能なアーカイブに蓄積できるようにする

プロジェクトのすべてのコミュニケーション、特に決定事項やその決定に至るまでの議論はアーカイブされる必要があります。また、コミュニケーションは安定したURLで参照できるようにする必要があり、過去のコミュニケーションも、簡単に検索できる形で保存される必要があります。

ただし、2つの注意点があります。

1. これは構造化された文書に取って代わるものではありません。しかし一方で、構造化されたドキュメントを収集するための出発点として機能もします。

2. すべてを文書化し、組織全体がアクセスできるようにするというルールには例外があります。人に関する議論やセキュリティに関する議論は機密事項であり、人前で行うべきではありません。

(6) トラステッドコミッター に対するリワード

すべての貢献(ソースコード、ドキュメント、バグレポート、議論への意見、ユーザーサポート、マーケティングなど) は歓迎され、リワードの対象になります。プロジェクトをサポートする人は、トラステッドコミッターとしてプロジェクトに招待され、全てのトラステッドコミッターのリストは公開されます。

結果の状況

• 組織のメンバーは、インナーソースのベストプラクティスを適用することによって、どのような課題に対処することができるのかを理解しています。

• オープンソースの経験がないメンバーが、インナーソースプロジェクトの基本的な価値観や原則を理解することができます。

• オープンソースの経験がないメンバーが、自分たちが日々行っていることを、共通の価値観に照らして確認することができる。

• 組織の開発手法がオープンソースプロジェクトと類似しているため、組織のメンバーがオープンソースプロジェクトに参加しやすくなります。

事例

Europace AG

上記のソリューションに記載されているインナーソースの原則は、ほとんどが Europace の経験に基づいています。 詳細はEuropace のインナーソース原則(ドイツ語)をご覧ください。

GitHub

目的

GitHub ではしばしば、チームが自分の担当外の領域に機能を提供するモデルで作業をします。よくある例としては、セールスエンジニアリングが営業におけるブロッカー要素を排除するために機能を提供したり、緊急なニーズに対する特別なプロジェクトがあり、インパクトの強い機能をプロダクト全体に提供したり、チームが複数のエリアにまたがって機能を提供したりすることです。

原則

全体として、このドキュメントで説明されている原則は、オーナーとなるチームの技術的負債とサポートの負担を増加させないようにすることに焦点を当てています。

多くの場合、チームは責任範囲内のサポートとメンテナンスのコストのために遅れており、機能に貢献するための余裕がないため、チームにヘルプが求められています。しかし別のチームによって新機能にかかるサポートの負担や技術的負担が追加されることになると、所有するチームが新機能に取り組む時間がさらに短縮されることを意味するため、それらが正しく行われていることを確認する必要があります。 同時に、私たちはエンジニアが境界を越えて自由に仕事ができる会社を目指しており、ビジネスの優先事項では、コアオーナーシップ以外の分野にコントリビュートすることが求められることがよくあります。

これらの原則をまとめると、「見つけたときと同じか、それ以上の状態で残す」ということになります。

それを踏まえて、私たちが賛同する原則を以下に紹介します。

• 機能負債を抱えるようなMVP（Minimum Viable Product）は避ける。顧客からのフィードバックを得るためにMVPを出荷することは構いませんが、コントリビュートするチームはその機能セットを完成させることを約束しなければなりません。例えば、以下のようなことです。

  • MVP を越えて、ほとんどの顧客を満足させるソリューションにするためのコミットメント

  • 新機能の管理を完全にサポートすること (例: コマンドラインの操作のみを提供するのではなく、設定のための UI を提供する）

  • APIのみを提供するのではなく UI と API の両方のインタフェースを提供する（またはその逆）

  • クラウドとやサーバー環境での動作保証 (補足: GitHub Enterprise Server と GitHub Enterprise Cloud の両方で動く)

• 本番環境へのデプロイまで、またそれ以降も機能作業をサポートする

  • インクリメンタルなロールアウトの連携

  • サポートチケットをハンドルする

  • 顧客からの(機能やバグに関する)フィードバックに対応するための時間をプランニングする

• 正しい方法で機能を構築する(技術的負債を作らない)

  • プロダクトチームおよびエンジニアリングチームとの要件およびソリューションの合意

  • 適切なアーキテクチャと設計

  • 後のデータマイグレーションを避けるために、データが適切に保存されていることを確認する

  • 適切なテレメトリの計測が行われていること

  • 適切なテストカバレッジが確保されている

  • クラウドおよびローカルの本番環境でサポートされている（セットアップ、設定、バックアップ/リストア、マイグレーションなどを含む）

  • バグの修正

  • ドキュメントの更新

エンゲージメント

エンゲージメントモデルを使用するのは、チームが責任範囲外の領域に機能を提供するときに、チームが実行できる具体的な手順を示すためです。 GitHubの一般的なエンゲージメントモデルは以下です。

• プロダクトオーナーから、機能のセッティングとロールアウトプランの承認を得る

• エンジニアリングオーナー(通常、エンジニアリングマネージャーとディレクター)から、非機能要件(テレメトリ、テストカバレッジ、マルチ環境テストとサポート) への対応を含むエンジニアリング設計の承認を得る

• 新規または変更された要件のレビューとともに、コードレビューを実施する。

Robert Bosch GmbH

目的

Bosch のインナーソース・イニシアチブ (BIOS: Bosch Internal Open Source) は、コラボレーション、学習、イノベーションを促進することに主眼を置いています。

原則

ボッシュは以下の原則を適用しました。

• オープン性: BIOS コミュニティへの参入障壁を可能な限り低くします。

• 透明性: 徹底的に透明性を高め、仕事上の成果物、コミュニケーション、意思決定を社内の全社員と共有します。

• 自発性: BIOSコミュニティに参加し、コントリビュートするかどうかの判断は、各人に任されています。社員は上司に言われたからではなく、自発的な動機で BIOS に参画すべきです。

• 自己決定: BIOS コミュニティは、何に取り組むか、いつ取り組むか、どのようなツールやプロセスを使って取り組むかを自由に選択することができます

• 功績至上主義: BIOSプロジェクトメンバーには、その功績に基づいて、つまりコントリビューションの質と量に基づいて権力が付与されます

オープン性、透明性、自発性の原則は、本質的な動機によって動く仲間の多様なコミュニティを成長させるのに役立ちました。功績至上主義は、多大な貢献をするための効果的な動機であることが証明されています。 自己決定により、コミュニティは限られた時間を最も効果的かつ効率的な方法でコントリビューションに使用することができました。

ステータス

Structured

著者

• Isabel Drost-Fromm

• Georg Grütter

謝辞

• Zack Koppert - GitHub のアプローチを提供していただき感謝いたします。

その他の呼び方

インナーソース減速の明示 - Explicit InnerSource Principles

翻訳の履歴

• 2022-06-02 - 翻訳 Yuki Hattori

• 2022-06-13 - レビュー @kanazawazawa

• 2023-06-18 - 最終更新