InnerSource をどう定義するか
問い #
InnerSource の定義は？――そう聞かれることがよくあります。では InnerSource とは何か。ここでは、InnerSourceについて、そしてそれが私にとって何を意味するのか、考えを書いてみます。
はじめに断っておきます。これは私個人の見解であり、公式な立場ではありません。私はいま InnerSource Commons Foundation のプレジデントを務めていますが、InnerSource は私が心から敬意を抱く多くの先駆者の手で形づくられてきました。彼らの積み重ねが、今日の InnerSource を作ってきたのです。
InnerSource の土台は、企業の実務、学術研究、そしてもちろんオープンソースの進化が織り重なったものです。この豊かな文脈を前に、私個人が InnerSource を定義できるとするのは出過ぎた話でしょう。役職についているからといって、ひとりで定義を与える権限や知恵があるわけではありません。
そこで私は唯一の答えを掲げるのではなく、いくつかの見方を共有します。皆さん自身の文脈で「InnerSource が何を意味するのか」という定義や理解を見つける手がかりになれば幸いです。
InnerSource に至る二つの道 #
いま私たちは、ちょっとした転換点にいます。もう少し具体的に言うと、今日 InnerSource にたどり着く人は大きく二つのタイプに分かれます。
ひとつ目は、もともとオープンソースを実践していて、その協調の作法の強さを知り、自然に社内へ持ち込んだ人たちです。この人たちにとって InnerSource は、すでにやっていた「オープンソース流の協働を組織に根づかせること」に後から付いた名前に過ぎません。
ふたつ目は、「InnerSource」という名のついた方法論として見つけた人たちです。オープンソースの長い経歴はなくても、組織の方法論としての InnerSource が変革に大きな価値をもたらすと捉えています。オープンソース実践者だからではなく、InnerSource そのものが組織に効くから採用しているのです。
この二面性は、コミュニティにおもしろい広がりをもたらします。前者は、組織で InnerSource を実装する意味や、InnerSource／オープンソースの価値や文化を直感的に理解しています。ゆえに「InnerSource をどう定義するか」をオープンソースの枠組みの中で考えがちです。 一方、後者は必ずしもオープンソースに関わってきたわけではないので、「実際、何なのか」をより明確に知りたがる傾向があります。
DevOps から学ぶ：名づけの力 #
InnerSource が「定義しにくい」理由を考えるなら、DevOps の歩みが参考になります。私の理解では、Flickr のような企業の実践者が、開発と運用のサイロを壊す新しいやり方を試していました。彼らが経験を共有し、そこに「DevOps」という名前が与えられた瞬間、何かが起きた。各社が「うちも同じようなことをしている」と気づき、次々に物語を持ち寄り始めたのです。
要はこうです。実践は名前より先にあった。けれど、名づけがコミュニティを生んだ。コミュニティが生まれると、道具や共通概念、カンファレンスが整い、爆発的に広がった。DevOps は発明ではなく、発見され、名づけられた。名づけがすべての触媒になったのです。
InnerSource もよく似た道筋をたどりました。2000 年に Tim O’Reilly がブログで言及し、2015 年には当時 PayPal にいた Danese Cooper らが InnerSource Commons を体系化し、その後に財団として独立させました。彼らが実践そのものを発明したわけではありません。人々がすでにやっていたことに名前を与えたのです。
名づけにはやはり魔法がありました。孤立していた実践者が「自分はひとりじゃなかった」と気づく。「社内ライブラリでやっている、あれが InnerSource か！」――コミュニティは一気にパターン共有へと広がり、集合知をまとめた InnerSource Patterns のようなリソースが生まれました。
いまの DevOps をひと言で？――数ある見方のうちの一つ #
DevOps の定義は無数にあります。すべてを挙げることはできませんが、たとえば次のようにも捉えられます。
- もともと分かれていたチーム同士の協働文化
- 実践と自動化ツールのセット
- 伝統的なウォーターフォールに抗する哲学
- 方法論やフレームワークの束
- BizDevOps や DevSecOps などへの広がり
これはあくまで一解釈です。実践者が 10 人いれば、強調点も 10 通りあるでしょう。この多様さは弱みではなく、進化の強みです。
“internal open source” が示すものは一つではない #
“internal open source（社内のオープンソース）” という言い方は一見矛盾して聞こえます。この逆説が、InnerSource が組織ごとに違って見える理由を物語っています。コミュニティでの議論から見えてきた代表的な姿をいくつか紹介します。
オープンソース成熟への道としての InnerSource #
ある組織にとって InnerSource は、オープンソースへの参加やデジタル変革へと自然につながる道を開きます。将来のオープンソース貢献の準備にとどまらず、「ソフトウェアで戦える会社」へ育つための土壌づくりです。Microsoft や Google のように、内側の実践が外側と響き合う形へと成熟し、内外のコラボレーションがなめらかにつながっていく例は象徴的です。
では製造や小売、金融はどうでしょう。大量のオープンソースを使ってはいても、道のりは異なります。InnerSource は、ソフトウェア能力の内製化、イノベーション文化の醸成、そして最終的には自社のビジネスモデルに沿ったオープンソースとの関わり方を見つける――そんな長い変革の第一歩になり得ます。
組織の透明性としての InnerSource #
文化変革の入り口として InnerSource に惹かれる人も多い。単にプルリクエストを送る（それも大事ですが）という話ではありません。自然な透明性が育つ場をつくることです。たとえば：
- 他チームに機能要望を出せる
- 隣のチームが何を作っているか見える
- 組織全体の技術の地図が見えてくる
- 協働を妨げるサイロを壊せる
- 情報が呼吸するように流れる、風通しのよいカルチャーを育てる
この透明性は、硬直したヒエラルキーを、しなやかな協働ネットワークへと変えていきます。
そしてこれは、エンジニアやプロダクトチームなど組織で働く人たちの幸福や健康にもつながります。信頼が前提の環境で働ける――最初から信頼されていると感じられる――ことはとても重要です。開発者体験（DX）に直結し、離職の抑制や採用面にも良い影響をもたらします。
リソース最適化としての InnerSource #
従来の階層型プロジェクト管理では、各レイヤーで“余白”が積み上がりがちです。要件が下流へ流れるたびに不確実性のバッファが足され、実装現場に届くころにはスケジュールは膨らみ、エンジニアは逼迫します。
InnerSource はこれを反転させます。課題に最も近い人が、課題を最もよく知っています。彼らが優先度を決め、議論し、解決する――延々と会議や承認を重ねなくても。もちろん万能ではありません。現場は現場しか見えないこともある。けれど戦略的な見取り図と組み合わせれば、とても強力です。
最適化は人やチームにとどまりません。コード資産、知的財産、競争優位といった“組織の持ち物”をどう活かすかでもあります。ツールやライブラリ、知見をチーム間で共有・継承できれば、サイロでは生まれない相乗効果が生まれます。あなたのチームが作った社内の機械学習ライブラリを、別のチームが思いもよらない方向へ広げるかもしれない。競争力の源になったテスト基盤を内側で共有すれば、その価値は全社に掛け算で広がる。InnerSource は「コードや知識は抱え込むほどではなく、共有するほど価値が増す資源だ」と気づかせてくれます。
定義のジレンマ：答えはいつも文脈の中にある #
この“多義性”は InnerSource に特有のものではありません。たとえば OSPO（Open Source Program Office）が社内でオープンソースを推進する際、相手に合わせて語り方を変えます。活動ごとに巻き込む相手が違い、関心事も異なるからです。
InnerSource を勧めるときのメッセージも、たとえばこう変わります。
エンジニアへ：「優秀な仲間と協働し、一流のコードから学び、所属を越えたプロジェクトに貢献しよう」
ミドルマネジメントへ：「重複を減らし、再利用と協働で効率化し、デリバリーを加速しよう」
経営層へ：「コストを抑え、イノベーションの速度を上げ、優秀な人材を惹きつけ、定着させよう」
同じ InnerSource の取り組みが、同時にこうしたゴールを満たします。相手によって切り口を変えるのはごまかしではなく、InnerSource のような変革の方法論が多層で価値を生むという現実に合わせているだけです。
そして定義は、相手だけでなく“フェーズ”にも依存します。それでいいのです。
あなたの InnerSource の旅路：変わり続ける定義 #
では InnerSource とは何か。それは、あなたが定義するものです。
将来、InnerSource Commons Foundation が、誰にでもすぐ伝わる明快な定義を整える日が来るかもしれません。私自身、その日を楽しみにしていますが、これほど多様な実践を前に定義を形にするのは容易ではないとも感じています。
加えて、あなた自身の定義は変化していくはずです。出発点で役に立つ InnerSource と、3 年後に実践している InnerSource は同じではないかもしれません。組織の成熟、直面する課題、理解の深まりに応じて、定義は移ろいます。
ぜひ、あなたの定義をコミュニティに持ち寄ってください。視点を共有し、ともに考えましょう。トップダウンの宣言ではなく、協働の探究を通じて、やがて共有できる理解に近づいていく――それが私たちの望む姿です。
行動への招待 #
完璧な定義を探すより、まずは InnerSource を体験してみてください。
- 見つけた課題を issue で提起する
- ドキュメントの不備をプルリクで直す
- 他チームに機能をリクエストする
- 自分のコードを同僚と共有する
- 他チームが作っているものを見に行く
- 組織の垣根を越えて協働する
やってみることで、あなたの組織にとっての InnerSource が見えてきます。もしかすると、私たちが学べる新しいパターンをあなたが名づけることになるかもしれません。
議論に参加しよう #
2025 年、AI がコードの作り方や協働のしかたを大きく変える中で、InnerSource の原則はますます重要です。AI が一瞬で何千行も生成できる時代に品質をどう保つか。生成が自動化されても知識共有をどう守るか。人間の判断をどう中心に据え続けるか。
この論点については、AI 時代のコラボレーション方法論を扱う記事 を参照してください。
いま明確な答えはありませんが、開放性・透明性・意図的なメンタリング・自発的なコード貢献を重んじる InnerSource なら、こうした問いに向き合えると私は信じています。
InnerSource には多くの流儀があります。あなたの流儀を加えて構いません。まだ言語化されていない実践に名前を与えてもいい。だから InnerSource はおもしろい――コミュニティが育ち、進化し、イノベーションが広がっていく“旗印”だからです。
InnerSource Commons Foundation は、こうした議論を歓迎します。私たちのコミュニティは、日々経験を共有しながら、社内コラボレーションの未来を一緒に形にしています。
そこで、あなたに問います。あなたの InnerSource は何ですか？ 組織ではどう定義しますか？ どんなパターンを見つけ、どう共有しますか？
一緒に探っていきましょう。旅は始まったばかりです。innersourcecommons.org でお会いできるのを楽しみにしています。
