イントロダクション

はじめに

このラーニングパスは、InnerSourceの紹介にあたるものです。 InnerSourceは、企業内のソフトウェア開発にオープンソースの実践と原則を適用したものです。 InnerSourceソフトウェアは、会社としてはプロプライエタリなものとなりますが、内部にはオープンで、誰もが利用したり貢献したりできるようになります。この方法は、広範かつ効果的なコラボレーション、内部の多くのステークホルダーからの変化する要求に、迅速かつ軽快に対応することを可能とします。このラーニングパスでは、InnerSourceを適用する良い候補となる状況を、どのように認識するかについて学びます。私たちは、これらの状況でどのようにInnerSourceが活用できるか概略を示します。それにより、あなたはInnerSourceについて議論する際の共通用語に詳しくなるでしょう。私たちはまた、InnerSourceの基礎となる主要な原則と、それが効果的に適用された時に得られる効果を列挙します。

InnerSourceによって解決される課題とは？

InnerSourceは、企業の組織構造やその立場に関係なく、誰もがコードを再利用したりコラボレーションすることを推奨し、それに報いることができるものです。このアプローチは、従来の組織に見られるアイデアや成果物を企業組織の階層やサイロの中に閉じ込めておくものとは異なるものです。この考えについて実例をあげて見ていきましょう。同じ会社にある二つのチームが、別々のソフトウェア部品を提供する時、片方のチームのソフトウェアが、もう一方のチームのソフトウェアに依存する状況を想像してください。もう少し具体的にユーザエクスペリエンスを例にすると、表示用データを取得するAPIに依存するサービスがあります。このような状況は、一つのチームが作成するソフトウェアが、数十人、数百人の利用される大企業では一般的なことです。利用側のチームが多くの機能を必要とした時、提供側のチームは通常、どの機能から開発を進めるかを決めるために、ある種の要件や優先度付けを行うプロセスを持っています。すぐに作業に取り掛かるため優先度が付けられていなかった重要な機能のリクエストのために、利用側のチームは通常、次に示す3つのオプションから一つを選択することになると思いますが、それぞれ欠点があります。静観：利用側のチームは何もせずにリスエストされた機能が無いために足を引っ張られるかもしれません。このオプションは、利用側の作業を最小限にすることができます。機能リクエストの効果に依存しているかもしれませんが、もしかすると待つだけで良いかもしれません。しかし、これは苦痛を伴うかもしれません。要求された機能がいつまでたっても提供されない場合は、特に大きな苦痛を伴います。回避策：利用側のチームが待ちたくない時は、利用側が要求する機能が足りない部分を補うために、別の場所で追加作業をするかもしれません。この追加作業は、利用側のプロジェクトの変更となるかもしれません。あるいは、利用側のチームは彼らのニーズを満たし、開発チームの全部もしくは一部の仕様を置き換える新しいプロジェクトを作成するかもしれません（コード/プロジェクトの複製）。こうした方法は、利用側のチームが要求する機能を自分たちの努力だけで手に入れることができます。とはいえ、これには幾つかの欠点があります。

どのようにInnerSourceは機能するのか？

AチームがBチームから提供されるソフトウェアを利用する場合を例に考えてみましょう。 AチームはBチームに機能追加のリクエストを送ります、でもBチームはそれを期限内に実装してAチームにリリースすることはできません。 InnerSourceでは、もしAチームがこの要求機能を得ることができない場合、代わりにプルリクエストを送信します。それは、AチームはBチームのソフトウェアに直接機能を実装してプルリクエストを送付することを意味します。チームBは連携して送付されたコードをレビューして受け入れます。この例において、チームAはゲストチーム、チームBはホストチームと呼ばれます。ゲストやホストの用語は、自宅にお客を招くような感覚で使われています。この状況では、殆どの人は良いホストとなること期待しています。彼らはゲストの到着を見越して、物事が整理整頓されていることを保証します。訪問者は、ドアのところで迎えられて中に招かれます。

InnerSourceの効果とは？

InnerSourceによるコラボレーションには、多くの効果があります。 InnerSourceは、ゲストチームが長期メンテナンスの負担をせず、彼らが必要な時に機能要求を手に入れるためのスケーラブルな戦略を企業に提供します。ゲストチームの時間を、他の人たちが利用できるコードに投入することが、会社全体としての勝利へとつながります。この結果はInnerSourceの優れた効果であると同時に、定常的にInnerSourceのコントリビューションを受け取るホストにも多くの効果があります。 InnerSourceのプロセスの一部には、ホストチームのプロダクトオーナーが、コントリビューションされた機能が正しくかつ望まれたものであることに、最初から同意していることを思い出してください。 InnerSourceは、それを利用する人達のために良いプロダクトを作るための支援をホストチームが受け取ることを可能にします! InnerSourceはホストチームにスケーラブルな戦略を提供し、多くの利用者たちからの、さまざまな機能要求に応えてゆくことが可能となります。ホストチームのフルタイムメンバーの対応力が固定されているとした場合、時として、その利用者たちのビジネスロードマップの組み合せが、ホストチームの製品で非常に（または理不尽に）大量の作業を必要とすることにつながる可能性があります。 InnerSourceなしでは、こうした状況は、リーダーにエスカレーションされた多くの機能要求に対処する、過労とストレスに満ちたチームを簡単に生みだすことにつながります。

InnerSourceの原則

会社、チーム、プロジェクト、そして個人はそれぞれ異ります。ですので、InnerSourceのコンセプトが実際に機能する正しい方法は、ある状況と他の状況とで異なるものになるでしょう。しかし、InnerSourceの成功例の根底には4つの原則があります。これらの原則は、オープンソースプロジェクトの成功からインスピレーションを得ており、InnerSourceが前に説明したような効果を得るために必要なものです。これらの原則は次の通りです：オープン性透明性優先的なメンターシップ自発的なコードコントリビューションそれでは、それぞれの原則について詳細を見ていきましょう。オープン性オープンなプロジェクトを構成することで、摩擦のないコントリビューションが可能となります。プロジェクトは、リポジトリのトップに置かれる README.md ファイルと CONTRIBUTING.

おわりに

このラーニングパスでは、InnerSourceの紹介をしました。 InnerSourceは、企業内のソフトウェア開発にオープンソースのベストプラクティスと原則を適用したものです。これは、提供側のチームが必要な機能要件を提供することができない時に、利用者に追加オプションを提供するものです。 InnerSourceの成功には、ホストチームのプロダクトオーナーと Trusted Committer 、そしてゲストチームのコントリビューターが関わります。効果的に行うと、InnerSourceは両方の参加チームに多くの効果をもたらします。効果的なInnerSource実施の主要な原則は、自発的なコードコントリビューションと優先的なメンターシップです。