InnerSourceは、企業の組織構造やその立場に関係なく、誰もがコードを再利用したりコラボレーションすることを推奨し、それに報いることができるものです。 このアプローチは、従来の組織に見られるアイデアや成果物を企業組織の階層やサイロの中に閉じ込めておくものとは異なるものです。 この考えについて実例をあげて見ていきましょう。
同じ会社にある二つのチームが、別々のソフトウェア部品を提供する時、片方のチームのソフトウェアが、もう一方のチームのソフトウェアに依存する状況を想像してください。 もう少し具体的にユーザエクスペリエンスを例にすると、表示用データを取得するAPIに依存するサービスがあります。 このような状況は、一つのチームが作成するソフトウェアが、数十人、数百人の利用される大企業では一般的なことです。
利用側のチームが多くの機能を必要とした時、提供側のチームは通常、どの機能から開発を進めるかを決めるために、ある種の要件や優先度付けを行うプロセスを持っています。 すぐに作業に取り掛かるため優先度が付けられていなかった重要な機能のリクエストのために、利用側のチームは通常、次に示す3つのオプションから一つを選択することになると思いますが、それぞれ欠点があります。
静観： 利用側のチームは何もせずにリスエストされた機能が無いために足を引っ張られるかもしれません。 このオプションは、利用側の作業を最小限にすることができます。 機能リクエストの効果に依存しているかもしれませんが、もしかすると待つだけで良いかもしれません。 しかし、これは苦痛を伴うかもしれません。要求された機能がいつまでたっても提供されない場合は、特に大きな苦痛を伴います。
回避策： 利用側のチームが待ちたくない時は、利用側が要求する機能が足りない部分を補うために、別の場所で追加作業をするかもしれません。 この追加作業は、利用側のプロジェクトの変更となるかもしれません。 あるいは、利用側のチームは彼らのニーズを満たし、開発チームの全部もしくは一部の仕様を置き換える新しいプロジェクトを作成するかもしれません（コード/プロジェクトの複製）。 こうした方法は、利用側のチームが要求する機能を自分たちの努力だけで手に入れることができます。とはいえ、これには幾つかの欠点があります。
More
AチームがBチームから提供されるソフトウェアを利用する場合を例に考えてみましょう。 AチームはBチームに機能追加のリクエストを送ります、でもBチームはそれを期限内に実装してAチームにリリースすることはできません。 InnerSourceでは、もしAチームがこの要求機能を得ることができない場合、代わりにプルリクエストを送信します。 それは、AチームはBチームのソフトウェアに直接機能を実装してプルリクエストを送付することを意味します。 チームBは連携して送付されたコードをレビューして受け入れます。
この例において、チームAは ゲスト チーム、チームBは ホスト チームと呼ばれます。 ゲスト や ホスト の用語は、自宅にお客を招くような感覚で使われています。 この状況では、殆どの人は良いホストとなること期待しています。 彼らはゲストの到着を見越して、物事が整理整頓されていることを保証します。 訪問者は、ドアのところで迎えられて中に招かれます。
More
InnerSourceによるコラボレーションには、多くの効果があります。 InnerSourceは、ゲストチームが長期メンテナンスの負担をせず、 彼らが必要な時に機能要求を手に入れる ためのスケーラブルな戦略を企業に提供します。 ゲストチームの時間を、他の人たちが利用できるコードに投入することが、会社全体としての勝利へとつながります。
この結果はInnerSourceの優れた効果であると同時に、定常的にInnerSourceのコントリビューションを受け取るホストにも多くの効果があります。 InnerSourceのプロセスの一部には、ホストチームのプロダクトオーナーが、コントリビューションされた機能が正しくかつ望まれたものであることに、最初から同意していることを思い出してください。 InnerSourceは、それを利用する人達のために 良いプロダクトを作るための支援 をホストチームが受け取ることを可能にします!
InnerSourceはホストチームにスケーラブルな戦略を提供し 、多くの利用者たちからの、さまざまな機能要求に応えてゆくことが可能となります。 ホストチームのフルタイムメンバーの対応力が固定されているとした場合、時として、その利用者たちのビジネスロードマップの組み合せが、ホストチームの製品で非常に（または理不尽に）大量の作業を必要とすることにつながる可能性があります。 InnerSourceなしでは、こうした状況は、リーダーにエスカレーションされた多くの機能要求に対処する、過労とストレスに満ちたチームを簡単に生みだすことにつながります。
しかし、もしホストチームがInnerSourceにより運営している場合、それらの機能を構築するために必要なエンジニアリソースは、それらの重要度に応じたゲストコントリビューターの形で現れます。 InnerSourceは、フォースマルチプライヤーになり 、需要が高い時間帯に、ホストチームが一時的に実際のサイズよりも大きく行動することを可能とします。 需要が終了すると、チーム人員や作業項目に関するマイクロマネージメントを一切せずとも、チームのスループットは通常のレベルに戻ります。 InnerSourceは、組織が必要とする時と場所にエンジニアリングの時間を有機的に投入することを可能とします。
More
会社、チーム、プロジェクト、そして個人はそれぞれ異ります。 ですので、InnerSourceのコンセプトが実際に機能する正しい方法は、ある状況と他の状況とで異なるものになるでしょう。 しかし、InnerSourceの成功例の根底には4つの原則があります。 これらの原則は、オープンソースプロジェクトの成功からインスピレーションを得ており、InnerSourceが前に説明したような効果を得るために必要なものです。
これらの原則は次の通りです：
オープン性
透明性
優先的なメンターシップ
自発的なコードコントリビューション
それでは、それぞれの原則について詳細を見ていきましょう。
オープンなプロジェクトを構成することで、摩擦のないコントリビューションが可能となります。 プロジェクトは、リポジトリのトップに置かれる README.md ファイルと CONTRIBUTING.md ファイルによって十分にドキュメント化され発見できるようになっていなければなりません。 組織の中の誰もが、目的としていたプロジェクトを見つけ、ホストチームのメンバからの過度な直接指導がなくても成長できるようになっていなければなりません。 ホストチームの連絡先情報は、そのプロジェクトにとって理にかなう程度の多くのチャネルに広められていなければなりません。 InnerSourceのコントリビューションを彼らのプロジェクトに受け入れるというホストチームの意図は、注目度を高めるために関連する組織のチャネルを通して共有されるべきです。 特に、小さめの環境では、あなたのチームが行っているInnerSourceの作業について定期的に"ブロードキャスト"したいかも知れません。 しかし、より大きい環境では、このようなブロードキャストは、多量のノイズとなる可能性があるため、簡単に使えるツールでプロジェクトを発見可能とする方が適切かも知れません。 忘れないでください。目標は、あなたの会社で機能する適切なチャネルを意識して使用することです。
More
このラーニングパスでは、InnerSourceの紹介をしました。 InnerSourceは、企業内のソフトウェア開発にオープンソースのベストプラクティスと原則を適用したものです。 これは、提供側のチームが必要な機能要件を提供することができない時に、利用者に追加オプションを提供するものです。 InnerSourceの成功には、 ホストチーム の プロダクトオーナー と Trusted Committer 、そして ゲストチーム の コントリビューター が関わります。 効果的に行うと、InnerSourceは両方の参加チームに多くの効果をもたらします。 効果的なInnerSource実施の主要な原則は、 自発的なコードコントリビューション と 優先的なメンターシップ です。
More
To conclude the Introduction segment of the Learning Path, here are some Frequently Asked Questions people have when embarking on their InnerSource journey.
More
InnerSource is the application of open source principles to company-internal software development. Done right, it unblocks progress and eases adoption of shared services and modules. This article contains guidance and questions to ask yourself when considering adoption of an InnerSource approach to running your project.
More
