InnerSource はウソだ――よくある誤解への応答
YouTube で「InnerSource」を検索すると、上位に「InnerSource はウソだ」と主張する動画が出てきます。
(link: https://youtube.com/shorts/53jEP3mPP3E)
この見方は、InnerSource を知ったばかりの方が最初に誤解しがちなポイントをそのまま示していると言えるでしょう。
今回はこの動画を題材に、どのような誤った結論へ誘導しているのかを整理します。これはかつての自分も通った誤解であり、この領域を深く学ぶ前なら誰でもはまりやすい落とし穴です。だからこそ、少し自省も交えながら紐解き、正しい道筋を見つける手がかりにしていきます。
誤解その1：「他の人が貢献できるように React を使え」 #
まず取り上げる主張はこうです。社内アプリには React を使うべきだ――「React を使えば、他の人が貢献できるから」。実のところ、InnerSource の議論でこうした理屈が語られることはほとんどありません。
should you use react HTMX or solid or something for your company’s internal application now a lot of people what you’re going to hear is use react so other people can contribute to this
この主張は、次の 3 点で問題があります。
- InnerSource の本質に対する根本的な誤解
- InnerSource を適用する領域の選び方を誤っている
- 個人の視点とチームの視点が混同されている
InnerSource の本当の意味 #
InnerSource とは、オープンソースの原則を社内で実践することです。すなわち、「貢献する／される」だけの話ではありません。
多くの人にとってオープンソースとの関わりは「利用者」です。消費者として使う人、バグを報告する人、そして実際にプルリクエストを送るのはごく一部。InnerSource は、そうした学びを社内に持ち込み、オープンでアクセスしやすく、意思決定が透明で、所有とメンタリングを通じて信頼関係が築かれる組織文化を育てます。目指しているのは、透明性と協働の文化です。
つまり「社内でオープンソースを実践する」とは、プルリクエストをもらうこと自体を目的にすることではないという意味です。プルリクエストはその文化が生んだ結果にすぎません。
InnerSource を当てはめにくい領域 #
次の問題は、議論の舞台が InnerSource／オープンソースの効き目が出にくい領域だという点です。
「プルリクエストを受けたい」「利用者が増えて品質を上げたい」と考えるなら、プロダクトの性質に左右されます。多くのチームが依存するコンポーネントやプラットフォーム的なツールのほうが、エンドユーザー向けのアプリケーションより価値が出やすいのは明らかです。ストリームアラインドなチームでも、必要に応じてオープンソース流の作法を採る価値はありますが、協働の成り立ち方は大きく異なります。
エンタープライズ支援の経験から言うと、最終利用者が「非エンジニア」であるプロジェクト単位の取り組みに InnerSource を適用するのは難度が上がります。開発スキルのない利用者と開発チームの間に直接の回路がないことが多く、要件は個別化し、調整のリードタイムが長くなりがちだからです。
InnerSource は、共有ライブラリ／プラットフォーム部品／開発ツール／インフラコードのように、利用者自身が「開発者」であり意義ある貢献が可能な領域で、相対的にうまく機能します。
もっとも、利用者向けアプリにおいても InnerSource の作法を取り入れることで、透明性や Issue を起点にした追跡が改善する、といった効用はあります（それだけでも十分に価値があります）。
個人とチームの視点の違い #
3 つ目は、「あなた」が個人を指すのか、チームを指すのかという点です。
InnerSource は、会社の中で「あなた個人のプロジェクト」に誰かが気まぐれに貢献してくれるのを待つ話では必ずしもありません。大手企業にある 20% ルールのような取り組みに他チームが参加することもありますが、それが主流ではないでしょう。
InnerSource が導入・維持されるのは、コスト削減、車輪の再発明の回避、相乗効果の創出、品質保証、階層的な意思決定に伴うコミュニケーションの負担軽減といった ROI が見込めるからです。多くの場合の対象は、共有の内部ライブラリ、競争優位に関わるコア部品、エンタープライズ内で高い依存を持つ領域です。そして、その便益の受け皿はチームの運営になります。結局はチームや組織としての ROI の話であり、そこを外すと「勤務時間中に個人プロジェクトへ貢献する」行為は止められてしまいます。短期でも長期でも、ROI を説明できることが必要です。
InnerSource の特長は、根本的にチームとチームの協働である点にあります。多くの実装は最終的にここへ行き着きます。個人が好き勝手に都合のよいプロジェクトに貢献するのではなく、ホストチームとゲストチームの関係で進むのが一般的です。多くの企業では役割と責任が定義され、その枠組みの中で協働が起こるからです。
したがって、プラットフォームチームとストリームアラインドチームの関係設計があるときに特に効果が高まります。ストリームアラインド同士の自発的な共創は、自然発生的には成功の確度が高くありません。
うまくいきにくい状況を前提にしたシナリオを根拠に、InnerSource そのものを批判するのは筋が通りません。
誤解その2：「現実の会社ではそんなことは起きない」 #
because we want people doing that the reality is that’s not what’s going to happen ever at any company ever inner source
現に起きています。 事例が存在します。それが答えです。
誤解その3：「InnerSource の 99.69% は失敗する」 #
99.69% a lie you’re going to build the entire project by yourself when it goes down people are going to look to you
「InnerSource」をどう定義するかによっては、ある部分では当たっているのかもしれません。先に述べたように、InnerSource は「プルリクエストを受けること」ではありません。
ただし、ここでは次の 3 点が重要です。
- InnerSource は戦略的なコンポーネントに特に適用する――すべてに必要なわけではない
- 価値は「能動的な貢献」に限られない
- オープンソースにも同じ“失敗率”の問題がある
InnerSource は企業の戦略である #
InnerSource と聞くと、「社内のすべてのコードを共有しよう」「誰もがあらゆるものに貢献しよう」といった極端な姿を想像しがちです。社内に何百もの共有リポジトリがあり、皆が相互に貢献し合う――そんな絵です。しかし、オープンソースが企業戦略であるのと同様に、InnerSource も優先順位のある企業戦略です。まずは「共有する価値の高いもの」から手を付けます。
つまり、実際に「チーム間でコードが流通し、活発な横断協働が起きる」コードベースの数はそう多くありません。単一桁のパーセンテージかもしれません。それでも、横断協働が活発でなくとも、オープンで透明にしておくことで得られる便益は多く、こうした広義の InnerSource による恩恵はかなりの範囲に及びます。
InnerSource は個人の貢献を含みますが、主眼はチームとチームの協働にあります。結果として、共有される対象は企業内のニッチな領域や、特定目的のためにフォークしたディストリビューションのようなものになりがちです。あるいは、GitHub が社内で Rails のコードを共有していたように、オープンソース的な開発文化そのものが広がる場合もあります。
「共通要件として能動的に横断協働が起き、継続的に保守される」という厳しい条件を付ければ、割合が小さくなるのは当然です。しかし、ゲストチームがドキュメントにプルリクエストを送る、設定の小さな修正を戻す、といった小さな協働は頻繁に起きます。さらに、透明化によって重複作業を防げる効果まで含めれば、その便益は相当大きくなります。
オープンソースにも同じ「問題」 #
この基準で言えば、オープンソースだって「ウソ」になってしまいます。なぜなら「公開されたオープンソースの大半は貢献を受けない」からです。しかし、それを理由に「オープンソースはウソだ」とは言いません。貢献を受ける以外にも価値があるからです。
繰り返します。「貢献してもらえること」だけが InnerSource の価値ではありません。 これはオープンソースでも同じです。
透明性がもたらす実利 #
社内コードを閉じずに開いておく――たとえば GitHub であれば、レベニュー部門のアーキテクトやソリューションエンジニアがソースを直接確認し、顧客要望に近い実装の情報を素早く見つけ、サポート対応を円滑にし、Issue から背景を的確に引き出せます。私が東京にいるとき、サンフランシスコのチームの動きを待つより、Ruby の実装を読み、Issue の履歴で経緯を確認するほうが速い場面が何度もありました。git blame で実際のステークホルダーを特定して経緯を尋ねることもできます。
もちろん、他の開発チーム間でも同様です。依存が生まれうる部品の情報が手に取りやすければ、コミュニケーションの負担は確実に下がります。
InnerSource は、オープンソースの協働実践を社内に持ち込み、その効果を享受する文化の実装です。プルリクエストのやり取りだけでなく、Issue を通じた機能要望やサポートの連携、意思決定の透明化など、恩恵は広範に及びます。活発な横断協働が起きている数パーセントのリポジトリを超えて、文化としての実装が組織全体にもたらす効果に目を向けるべきです。
誤解その4：「退職したら、半年後に連絡が来て結局あなたに頼る」 #
“when you leave the company they’re going to send you a message 6 months later asking you questions or seeing if you would like to contract with them to upgrade your application there is no such thing as innersourcing”
リソースが放置されることはあります。しかし、これは InnerSource そのものへの批判ではありません。正確には、InnerSource を適切に実装できていないことへの批判です。誰も保守しない体制を放置していることへの指摘であり、所有と保守の文化が欠落した結果です。
DevOps との類比 #
これは「InnerSource ができていないこと」の批判であって、「InnerSource そのもの」の批判ではありません。論理が取り違えられがちです。DevOps に言い換えれば、次のような話です。「レビューに数か月かかる、監査が増える、リリース判定のプロセスが積み上がる――結果としてリリースは四半期に一度か年 2 回。だから“高速リリースを可能にする”と謳う DevOps はダメだ」。問題は DevOps の方法論ではなく、DevOps を実装できなかったことにあります。
業務プロセスを変えるのは難しく、多くの企業が当初「DevOps は無理だ」と言っていました。それでも挑戦し、文化を変え、実現した先駆者がいました。InnerSource も同じです。
誤解その5：「最終的に 100% 自分が所有することになる」 #
you own it 100% (which implies: InnerSource where you don’t own 100% is impossible)
「InnerSource は所有を放棄するものだ」という理解は誤りです。むしろ InnerSource では、チームがコードを所有することが前提です。「保守責任を手放すために“オープンソースにしよう”」という発想がうまくいかないのと同じです。
個人所有か、チーム所有か――強い所有なのか #
ここでの「あなた」は個人でしょうか、複数でしょうか。CODEOWNERS に個人名が並ぶことはあっても、最終的な責任はチームが負います。文脈的には Martin Fowler のいう Strong Code Ownership を想起しますが、従業員は退職することもあり、組織としての保守性の観点では望ましくありません。
InnerSource は強い個人所有を前提にしません。 最低限、複数人で責任を分有できる体制が必要です。初期は個人の強い意志で強い所有に傾く局面があるにせよ、長期的な成功には権限移譲が欠かせません。
集合的所有か――InnerSource は「全員のもの」か #
Collective Ownership の文脈で「InnerSource＝みんなのもの」と理解されることもありますが、これも違います。InnerSource は集合的所有そのものではありません。 基本はホストチームが保守します。InnerSource の所有は**弱い所有（Weak Ownership）**に近い。したがって、「最終的に 100% あなたが持つことになる」という主張は筋が通りません。
Fowler が指摘するように、「みんなのもの」はしばしば「誰のものでもない」になり、責任の所在が曖昧になって破綻します。
弱い所有（Weak Code Ownership）のかたち #
弱い所有では、メンテナが存在し、ホストチームが主体的に保守しつつ、特定部分について他チームから信頼できるコミッター／メンテナを受け入れることがあります。貢献する人、保守する人は分かれ得ます。たとえば 98% は自チーム、2% は他チームが実質的に面倒を見る、といった形もあり得ます。
繰り返しますが、CODEOWNERS に個人が並んでいても、最終責任はチームです。チームとして所有する。ここを忘れないことが重要です。
誤解その6：「説明もなく 7,000 行の変更が突然投げ込まれる」 #
Every now and then there will be a sufficiently motivated coworker who’s really great and do like a 7,000 line update no explanation but don’t ever fall into this idea that choosing anything for an internal app that you are going to be working on
説明なしの 7,000 行プルリクエストが突然届く――これは InnerSource をやった結果ではなく、InnerSource の文化や協働作法を整備できていない結果です。InnerSource を導入するとそうなる、という心配は見当違いです。
真の問題はどこにあるか #
ここで問われるのは、協働の文化や手続きが機能していないことです。7,000 行もの実装が事前共有なしにいきなり送られてくるのは、合意形成や分割、設計レビュー、ドラフト段階での相談といった前工程の協働が欠けているからです。まずはそこを正す必要があります。これは InnerSource 以前の組織文化の問題です。
これを避けたいなら、答えは明快です。InnerSource の文化を育てましょう。
現実としての InnerSource：何であり、何ではないか #
InnerSource は、オープンソースの協働実践を社内に適用し、その恩恵を享受するための文化の実装です。最終目的はプルリクエストを受けることだけではありません。Issue を通じた機能要望、支援の連携、意思決定の透明化など、幅広い効果があります。
したがって、「プルリクエストを得るために InnerSource のベストプラクティスを実装するのはウソだ」という主張は、はっきり否定します。
貢献の現実を知る #
“Nobody ever is going to contribute”
オープンソースにおいて、実際に貢献する人は確かに少数です。1000 人の利用者がいれば、大半は使うだけ、20 人が Issue や要望を出し、5 人がプルリクエストを送り、メンテナになるのは 1 人かもしれません。
InnerSource のベストプラクティスを導入しても、1000 人全員が貢献者になるわけではありません。InnerSource は、そうした協働を起きやすくする土壌を整えつつ、エンタープライズに特有のサイロを崩し、従来型の組織構造が生む摩擦を減らし、情報のリードタイムを短縮し、組織資源の最適配置を図るためのアプローチです。
結び #
今回の主張には、現実の課題に触れている部分もありますが、InnerSource を学び始めたときに陥りやすい誤解が土台になっています。コミュニティではよく知られた落とし穴であり、深く踏み込んでいなければ、その結論に至ってしまうのも無理はありません。
大切なのは、InnerSource を硬直した枠に押し込めることではなく、**「オープンソースから何を学べるか」**という原点に立ち返ることです。視野を広く持ってオープンソースを捉え直せば、社内への適用もずっと豊かになります。
この対話に、ぜひ参加してください。ここでの議論を土台に深掘りしても、具体的な実装論に展開しても、あるいは正面から異論を唱えても構いません。重要なのは、オープンソースの学びを広い視野で捉え、それを社内という文脈にどう翻訳するかを考え続けることです。
より包括的な情報は InnerSource Commons Foundation にまとまっています。オープンソースの原則が企業にもたらす価値について、多様な視点からの議論が歓迎されています。
