InnerSourceは、企業の組織構造やその立場に関係なく、誰もがコードを再利用したりコラボレーションすることを推奨し、それに報いることができるものです。 このアプローチは、従来の組織に見られるアイデアや成果物を企業組織の階層やサイロの中に閉じ込めておくものとは異なるものです。 この考えについて実例をあげて見ていきましょう。
同じ会社にある二つのチームが、別々のソフトウェア部品を提供する時、片方のチームのソフトウェアが、もう一方のチームのソフトウェアに依存する状況を想像してください。 もう少し具体的にユーザエクスペリエンスを例にすると、表示用データを取得するAPIに依存するサービスがあります。 このような状況は、一つのチームが作成するソフトウェアが、数十人、数百人の利用される大企業では一般的なことです。
利用側のチームが多くの機能を必要とした時、提供側のチームは通常、どの機能から開発を進めるかを決めるために、ある種の要件や優先度付けを行うプロセスを持っています。 すぐに作業に取り掛かるため優先度が付けられていなかった重要な機能のリクエストのために、利用側のチームは通常、次に示す3つのオプションから一つを選択することになると思いますが、それぞれ欠点があります。
-
静観： 利用側のチームは何もせずにリスエストされた機能が無いために足を引っ張られるかもしれません。 このオプションは、利用側の作業を最小限にすることができます。 機能リクエストの効果に依存しているかもしれませんが、もしかすると待つだけで良いかもしれません。 しかし、これは苦痛を伴うかもしれません。要求された機能がいつまでたっても提供されない場合は、特に大きな苦痛を伴います。
-
回避策： 利用側のチームが待ちたくない時は、利用側が要求する機能が足りない部分を補うために、別の場所で追加作業をするかもしれません。 この追加作業は、利用側のプロジェクトの変更となるかもしれません。 あるいは、利用側のチームは彼らのニーズを満たし、開発チームの全部もしくは一部の仕様を置き換える新しいプロジェクトを作成するかもしれません（コード/プロジェクトの複製）。 こうした方法は、利用側のチームが要求する機能を自分たちの努力だけで手に入れることができます。とはいえ、これには幾つかの欠点があります。
-
利用側のチームで行った成果は、同じ機能を必要としている他の利用者に提供されなくなる。
-
利用側のチームは、自分たちのチームの主要な役割の範疇にはない、新しいコードを長期的にメンテナンスするという負担を意図せずに背負い込んでしまいました。
-
会社全体として、同じ課題に対する重複したプロジェクトとコードを取得していしまいました。
-
-
エスカレーション： 利用側のチームは、「No」という答えを受け入れずに、代わりに提供側のマネージメント層に影響（や強制）を与えるように働きかけます。 このオプションは、利用側のチームにとっては、彼らが何も開発したりメンテナンスしたりせずに要求する機能を手に入れることができるため、魅力的に思えます。 しかし、それは利用側のチームにとって結局足を引っ張ることになります。なぜなら、エスカレーションという開発に関係のない作業に注力しなければならないからです。 加えて、このオプションは、何度も使えるものでもなくスケールしません。度重なるエスカレーションは、利用する側の信頼を損なうことに繋がるからです。 エスカレーションは、提供側のチームにも同様（もしくはそれ以上）に混乱をもたらします。なぜなら、エスカレーションされた機能の処理を、通常のワークフローや優先度付けの方法の範囲外で行わなければならないからです。
この議論は、InnerSourceのための準備となります。 InnerSourceは、利用側のチームが機能要求を通して必要なものが得られない、似たような状況に適用されます。 InnerSourceは、 静観 、 回避策 、エスカレーション に関連する欠点がない効果を得るための方法を提供します。
また、InnerSourceはエンジニア同士が新しいさまざまな技術やバラエティに富んだ人々と一緒に仕事をする機会を与えることで、エンジニアの開発文化を改善します。 開発者は、組織的なサイロを横断してアイデアや解決法を共有しながら、互いに指導したり学んだりできます。 エンジニアやチームは、コモディティな問題に対する内部の解決方法を再利用することで、組織にとってより高い価値となることに集中して取り組むことができるようになります。
