基本原則ガイダンスの文書化 InnerSource Patterns Speaker: Yuki Hattori (@yuhattor) Pattern Authors: Isabel Drost-Fromm Georg Grütter

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

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

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

状況 インナーソースという言葉が社員の間で広がり始めています。 イニシアチブ自体はオープンソースの愛好家の間で始まった取り組みでした。 InnerSource Patterns: 基本原則ガイダンスの文書化 @yuhattor 5

組織に働く力学 チームは、インナーソースの重要な側面が何であるかを正確に伝えるのに苦労しています。 オープンソースの経験が不足している人々は、オープンソースのベストプラクティスを組織にもたらすこ との意味を理解することができません。 日常的にインナーソースのベストプラクティスに従おうとするチームは、自分たちがやっていることが 一般的なインナーソースの典型例に沿っているのかを判断するのに苦労しています。 InnerSource Patterns: 基本原則ガイダンスの文書化 @yuhattor 6

ソリューション 組織内でインナーソースの取り組みを推進する人は、オープンソースの深いバックグランドを持たず、イン ナーソースを直感的に理解できていないチームや個人を支援する必要があります。 以下の2 つの分野を文書化することで、チームや個人に対して明確な情報を提供する必要があります。 1. 目的: なぜ組織はインナーソースを採用するのか？ 2. 原則: どのインナーソースの原則は、これらの課題に対処するのに役立つのか？ 以下のセクションでは、この2 つの詳細について説明します。あなたの組織が目的と原則を文書化するため に、このセクションはよい出発点になるでしょう。 InnerSource Patterns: 基本原則ガイダンスの文書化 @yuhattor 7

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

インナーソースで対処できる課題 他の個人や組織がインナーソースのベストプラクティスに従うことによって対処しているいくつかの課題が あるので、見ていきましょう。 強力なオーナーシップを求める文化によって引き起こされる開発のサイロを減らすため 健全なコードの再利用を促進することにより、類似の問題の解決に費やす時間を短縮し、イノベーショ ンの速度を向上させるため より良いクロスチームのコラボレーションによって開発速度を向上させるため 依存関係があるプロジェクトやチームの連携を、ワークアラウンドを開発したり、ただ単純に待つので はなくエンジニアリングにおけるボトルネックを減らすことによって解決するため 品質を向上させるため 従業員の幸福度を高めるため 新入社員の成功の数を増やす アクショナブルなドキュメントをつくる InnerSource Patterns: 基本原則ガイダンスの文書化 @yuhattor 9

これらの課題を解決するのに役立つインナーソースの原則 チームがインナーソースがどのような問題に対処するのに役立つかをひとたび理解したら、次のステップ は、これらの課題に対処するのに役立つ原則を説明することです。 基本的なオープンソース開発の原則に基づき、以下のガイドラインが成功に役立つと証明されています。 1. コードは組織内で透明性を持ってホストされている 2. 機能リクエストよりもコントリビューション 3. 失敗することは学習をするチャンスであるということ 4. 口頭より文字で伝える 5. 書面によるアドバイスを永続的で検索可能なアーカイブに蓄積できるようにする 6. トラステッドコミッター に対するリワード InnerSource Patterns: 基本原則ガイダンスの文書化 @yuhattor 10

1. コードは組織内で透明性を持ってホストされている ソースコード、ドキュメント、プロジェクト開発に関連するデータは、組織内の誰もが利用でき、簡単に見 つけることができる必要があります。 InnerSource Patterns: 基本原則ガイダンスの文書化 @yuhattor 11

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

3. 失敗することは学習をするチャンスであるということ 組織全体で仕事が見えるため、どんなミスもメンバーに見えてしまいます。「ミスは何としても避けなけれ ばならない失敗」ではなく「学習のための機会である」という文化が確立されなければなりません。 InnerSource Patterns: 基本原則ガイダンスの文書化 @yuhattor 13

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

5. 書面によるアドバイスを永続的で検索可能なアーカイブに蓄積でき るようにする プロジェクトのすべてのコミュニケーション、特に決定事項やその決定に至るまでの議論はアーカイブされ る必要があります。また、コミュニケーションは安定したURL で参照できるようにする必要があり、過去の コミュニケーションも、簡単に検索できる形で保存される必要があります。 ただし、2 つの注意点があります。 1. これは構造化された文書に取って代わるものではありません。しかし一方で、構造化されたドキュメン トを収集するための出発点として機能もします。 2. すべてを文書化し、組織全体がアクセスできるようにするというルールには例外があります。人に関す る議論やセキュリティに関する議論は機密事項であり、人前で行うべきではありません。 InnerSource Patterns: 基本原則ガイダンスの文書化 @yuhattor 15

6. トラステッドコミッター に対するリワード すべての貢献( ソースコード、ドキュメント、バグレポート、議論への意見、ユーザーサポート、マーケティ ングなど) は歓迎され、リワードの対象になります。プロジェクトをサポートする人は、トラステッドコミッ ターとしてプロジェクトに招待され、全てのトラステッドコミッターのリストは公開されます。 InnerSource Patterns: 基本原則ガイダンスの文書化 @yuhattor 16

結果の状況 組織のメンバーは、インナーソースのベストプラクティスを適用することによって、どのような課題に 対処することができるのかを理解しています。 オープンソースの経験がないメンバーが、インナーソースプロジェクトの基本的な価値観や原則を理解 することができます。 オープンソースの経験がないメンバーが、自分たちが日々行っていることを、共通の価値観に照らして 確認することができる。 組織の開発手法がオープンソースプロジェクトと類似しているため、組織のメンバーがオープンソースプ ロジェクトに参加しやすくなります。 InnerSource Patterns: 基本原則ガイダンスの文書化 @yuhattor 17

事例: Europace AG 上記のソリューションに記載されているインナーソースの原則は、ほとんどが Europace の経験に基づいてい ます。 詳細はEuropace のインナーソース原則( ドイツ語) をご覧ください。 InnerSource Patterns: 基本原則ガイダンスの文書化 @yuhattor 18

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

事例: GitHub (2) 原則 全体として、このドキュメントで説明されている原則は、オーナーとなるチームの技術的負債とサポートの 負担を増加させないようにすることに焦点を当てています。 多くの場合、チームは責任範囲内のサポートとメンテナンスのコストのために遅れており、機能に貢献する ための余裕がないため、チームにヘルプが求められています。しかし別のチームによって新機能にかかるサ ポートの負担や技術的負担が追加されることになると、所有するチームが新機能に取り組む時間がさらに短 縮されることを意味するため、それらが正しく行われていることを確認する必要があります。 同時に、私た ちはエンジニアが境界を越えて自由に仕事ができる会社を目指しており、ビジネスの優先事項では、コアオ ーナーシップ以外の分野にコントリビュートすることが求められることがよくあります。 これらの原則をまとめると、「見つけたときと同じか、それ以上の状態で残す」ということになります。 InnerSource Patterns: 基本原則ガイダンスの文書化 @yuhattor 20

事例: GitHub (3) 原則の例 機能負債を抱えるようなMVP （Minimum Viable Product ）は避ける。顧客からのフィードバックを得るた めにMVP を出荷することは構いませんが、コントリビュートするチームはその機能セットを完成させる ことを約束しなければなりません。例えば、以下のようなことです。 MVP を越えて、ほとんどの顧客を満足させるソリューションにするためのコミットメント 新機能の管理を完全にサポートすること API のみを提供するのではなく UI と API の両方のインタフェースを提供する（またはその逆） 本番環境へのデプロイまで、またそれ以降も機能作業をサポートする インクリメンタルなロールアウトの連携 顧客からの( 機能やバグに関する) フィードバックに対応するための時間をプランニングする 正しい方法で機能を構築する( 技術的負債を作らない) プロダクトチームおよびエンジニアリングチームとの要件およびソリューションの合意 適切なアーキテクチャと設計 クラウドおよびローカルの本番環境でサポートされている バグの修正とドキュメントの更新 InnerSource Patterns: 基本原則ガイダンスの文書化 @yuhattor 21

事例: GitHub (4) エンゲージメント エンゲージメントモデルを使用するのは、チームが責任範囲外の領域に機能を提供するときに、チームが実 行できる具体的な手順を示すためです。 GitHub の一般的なエンゲージメントモデルは以下です。 プロダクトオーナーから、機能のセッティングとロールアウトプランの承認を得る エンジニアリングオーナー( 通常、エンジニアリングマネージャーとディレクター) から、非機能要件( テ レメトリ、テストカバレッジ、マルチ環境テストとサポート) への対応を含むエンジニアリング設計の承 認を得る 新規または変更された要件のレビューとともに、コードレビューを実施する。 InnerSource Patterns: 基本原則ガイダンスの文書化 @yuhattor 22

事例: Robert Bosch のインナーソース原則 Bosch のインナーソースイニシアチブBIOS は以下の原則を持ちます オープン性: BIOS コミュニティへの参入障壁を低くします。 透明性: 徹底的に透明性を高め、仕事上の成果物、コミュニケ ーション、意思決定を社内の全社員と共有します 自発性: BIOS コミュニティに参加し、コントリビュートするか どうかの判断は、各人に任されています。社員は上司に言われ たからではなく、自発的な動機で BIOS に参画すべきです 自己決定: BIOS コミュニティは、何に取り組むか、いつ取り組 むか、どのようなツールやプロセスを使って取り組むかを自由 に選択することができます 功績至上主義: BIOS プロジェクトメンバーには、その功績に基 づいて、つまりコントリビューションの質と量に基づいて権力 が付与されます InnerSource Patterns: 基本原則ガイダンスの文書化 @yuhattor 23

その他の呼び方 インナーソース原則の明示 Explicit InnerSource Principles InnerSource Patterns: 基本原則ガイダンスの文書化 @yuhattor 24

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 25