yukihattori.com

InnerSource をどう定義するか

hello@yukihattori.com (Yuki Hattori) — Mon, 25 Aug 2025 00:00:00 +0000

問い

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 でお会いできるのを楽しみにしています。

InnerSource はウソだ――よくある誤解への応答

hello@yukihattori.com (Yuki Hattori) — Mon, 18 Aug 2025 00:00:00 +0000

YouTube で「InnerSource」を検索すると、上位に「InnerSource はウソだ」と主張する動画が出てきます。

(link: https://youtube.com/shorts/53jEP3mPP3E)

この見方は、InnerSource を知ったばかりの方が最初に誤解しがちなポイントをそのまま示していると言えるでしょう。

今回はこの動画を題材に、どのような誤った結論へ誘導しているのかを整理します。これはかつての自分も通った誤解であり、この領域を深く学ぶ前なら誰でもはまりやすい落とし穴です。だからこそ、少し自省も交えながら紐解き、正しい道筋を見つける手がかりにしていきます。

Contents

誤解その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 にまとまっています。オープンソースの原則が企業にもたらす価値について、多様な視点からの議論が歓迎されています。

プラットフォームエンジニアリングと InnerSource ― スケールする開発者コミュニティを築く

hello@yukihattori.com (Yuki Hattori) — Mon, 11 Aug 2025 00:00:00 +0000

Backstage の瞬間：本当の仕事はここから始まる

あなたの組織はやり遂げました。Backstage の導入に成功し、プラットフォームエンジニアリング変革についてカンファレンスで講演もし、開発者ポータルが組織全体のエンジニアリング資産を可視化できると示しました。チェックボックスはすべて埋まりました。

しかし不都合な真実を言えば、Backstage を入れたからといって「プラットフォームエンジニアリングが終わった」わけではありません。ようやくスタートラインに立ったというだけです。

プラットフォームエンジニアリングは Backstage と同義ではありません。特定のツールやソリューションとも同義ではありません。頭では皆わかっているのに、組織は繰り返し同じ罠に落ちます――技術にだけ目を奪われ、文化を忘れるのです。

Contents

共有プラットフォームに繰り返される失敗パターン

プラットフォームエンジニアリングが実際に求めるものに話を進める前に、まずは部屋の中の象を認めましょう。共有プラットフォームや共通ライブラリの多くは歴史的に失敗してきました。 これは秘密でも何でもなく、プラットフォームエンジニアリングが解こうとしている「よくあるパターン」です。

なぜ失敗するのか。答えはたいてい、次のどちらかの予測可能なパターンに沿っています。

パターン1：サービスデスクの罠 プラットフォームチームがサービスデスクと化し、組織中の全チームからの機能要望・共通要件・依存関係対応に溺れます。相反する要件が雪崩れ込み、あらゆるユースケースに合わせてカスタム開発工房になるか、プラットフォームが保守不能な枝分かれにフォークしていくかの二択を迫られます。長期の保守サイクルがさらに問題を増幅させます――機能を作るだけでなく、時間とともに複雑化していくカスタム実装の動物園を維持する羽目になるのです。

パターン2：象牙の塔 要望の洪水に耐えられなくなると、プラットフォームチームは「ノー」と言い始めます。ユーザー要件を退け、端ケースを受け付けず、「プラットフォームはあるがままに使え」と迫る。結果は？各チームが自前で解決策を作り、共有プラットフォームは無関係な存在に。ゲームオーバーです。

これらの失敗は構造の問題ではありません。文化の問題です。 いくら豪華なポータルや洗練されたツーリングがあっても、根本の問い――プラットフォーム提供者と利用者の間に、協働的で持続可能な関係をどう築くか――を解かなければ、何も解決しません。

欠けているのは「文化の実装」

いまの GitHub の使い方を思い浮かべてください。おそらく、組織のデフォルトの「ポータル」として機能しているはずです。リポジトリを探索し、Issue でコラボし、ドキュメントにアクセスするための一か所として。リポジトリが 100 個だった頃は Backstage は不要でした。GitHub で足りました。けれど数千リポジトリへとスケールすると、探索と編成のためのもう一層が必要になるのです。

プラットフォームエンジニアリングも同じです。基盤となるインフラやツールは土台にすぎません。本当に作っているのは「開発者コミュニティ」であり、コミュニティにはツールだけでなく意図的な文化実践が要るのです。

ここでプラットフォームエンジニアリングは、Infrastructure as Code（IaC）の原則と強力に交差します。テンプレート生成、標準化されたデプロイ、自動プロビジョニング――どれも「インフラをソフトウェアとして扱う」考えに合致します。しかし従来の IaC と違い、人間の側面も扱わなければなりません。開発者はどうやって利用可能なものを見つけるのか。変更はどう要求するのか。改善はどう貢献するのか。

クラウドベンダから学ぶ：開発者コミュニティの作法

発想を少し変えてみましょう。プラットフォームチームは、社内のクラウドベンダを営んでいるのだ、と。AWS/Azure/GCP のように何百何千というサービスの複雑さを引き受け、開発者が使いやすい絞り込まれたエンタープライズ基盤へと蒸留しているのです。

では、クラウドベンダは開発者とどう対話しているでしょう？ GitHub です。ドキュメント用のリポジトリです。GitHub Discussions です。オープンソース部品と透明な Issue トラッキングです。スレッド化された会話が保存・検索可能で、コミュニティの投票がプロダクト判断に影響を与える仕組みです。

私は Microsoft でクラウドアーキテクトをしていた時に、これを目の当たりにしました。究極的にはカスタマーの声がすべてを動かします。 プロダクトチームは、ユーザーの痛点を理解し、どれだけ多くに影響するのかを確かめ、ビジネスインパクトを測りたがっています。時に手作業のヒアリングや顧客ノミネーションも必要ですが、近年は大規模ユーザーが機能に投票し、プロダクトチームが公開の場で直接対話するオープンフォーラム型に近づいています。

偶然ではありません。これはスケールする開発者向けプロダクトにおける実証済みのモデルです。

InnerSource：文化の橋渡し

InnerSource は、プラットフォームエンジニアリング成功に必要な欠けていた文化的フレームワークを提供します。社内コードをすべてオープンにすることでも、「魔法のように貢献が届く」ことを期待する話でもありません。よりオープンで透明・協働的な環境へ、段階的に変わっていくための取り組みです。

InnerSource は、プラットフォームエンジニアリングに必須の協働文化を育てます。プルリクエストと透明な議論を例外ではなく当たり前にします。何より、エンジニアが利用者であり貢献者でもある環境を作ります。

ここがプラットフォームチームに重要な理由は明快です。あなたの顧客は社内の開発者――コードという言語を話し、GitHub のワークフローを理解し、プラットフォーム開発に意味のある貢献ができる人々です。こうした社内開発者コミュニティとのコミュニケーションの作法は、エンドユーザー向けプロダクトのために設計されたアジャイル流儀とは根本的に異なります。

プラットフォーム利用者はソースコード管理の中で語り、技術的で、コードもドキュメントも改善も自ら差し戻せる。その力を引き出すための実証済みパターンが、InnerSource のパターン集です。

Team Topologies とコラボレーションパターン

プラットフォームエンジニアリングの議論で皆が引き合いに出すベestseller、Team Topologies は、チーム間のさまざまなコラボレーションパターンを示しています。ここで肝心なのは、すべてのチーム種別が InnerSource から等しく恩恵を受けるわけではないという洞察です。

プラットフォームチーム × InnerSource：相性は抜群 プラットフォームチームは、多くの組織で依存関係のハブです。ひとつのライブラリを 100 人が使う状況では、協働開発の恩恵はその 100 人全員に跳ね返ります。再発明を防ぎ、レビュー負荷を減らし、規模の経済が働きます。高依存・高再利用の型は、InnerSource の価値を最大化します。

ストリームアラインドチーム：自然な適合度は低め ストリームアラインドチームは、そもそもドメイン知が分離され、チーム間依存が最小になるように設計されています。チーム間のコラボは限定的になりがちで、依存がある場合も協働開発というより消費者―提供者の関係になりやすい。

この違いは重要です。プラットフォームチームは、高い再利用・多様な貢献者・共有の保守メリットという、成功するオープンソースに似たダイナミクスを持つため、InnerSource と自然に噛み合います。

AI 時代：情報アーキテクチャで加速するプラットフォームエンジニアリング

AI 時代に入るにつれ、プラットフォームエンジニアリングの重要性はさらに増し、InnerSource の価値も高まります。理由はこうです。

AI 支援のプラットフォーム開発 ユーザー Issue への即応を人間だけで行うのではなく、初動のトリアージや解決の試行を AI に任せられるようになります。ただしそのためには、AI が理解できる情報アーキテクチャ――GitHub リポジトリへの集約、明快なドキュメント、十分な Issue 履歴、標準化されたテンプレート――が必要です。

理想的なユーザージャーニーはこうです：ポータルで機能を知る → つまずく → GitHub Issue を起票 → プラットームチームが AI に初期解析をアサイン → 人がレビューして実装。ドキュメント・会話履歴・関連チケットが AI 可読な形式にまとまっているからこそ回ります。

情報集約の課題 制約があることは承知しています。全員が GitHub Enterprise のライセンスを持っているわけではない。ソースは社内 Git や AWS CodeCommit にあり、ドキュメントは Google Docs、会話は Slack や Discord など多系統に散らばる――。

しかし重要な洞察はこれです。それらの制約に合わせるための迂回策は、すべてプラットフォームチームの運用負荷を増やすということ。複数チャネルは会話を分断し、散在する情報はトレーサビリティを落とし、統一されないフローは重複と混乱を生みます。

AI はプラットフォームチームのやるべきこと自体を変えませんが、情報アーキテクチャの出来不出来が成果を大きく左右します。うまく構造化された情報さえあれば、AI はよくある課題の解決コストを劇的に下げてくれます。

実装の勘所：プラットフォームチームのための InnerSource「4 原則」

1. オープンネス：発見でき、貢献できる状態にする

プラットフォームの各コンポーネントは、利用可能であるだけでなく、貢献可能でなければなりません。Backstage にリポジトリを登録するだけでは不十分です。誰がメンテするのか、どう貢献するのか、バグ報告はどこに、機能要望はどう出すのか――各リポジトリに明記しましょう。

透明性がなければ、チームは協働できず消費者に留まります。そうして再び、サービスデスク化が始まります。

2. トランスペアレンシー：意思決定を見える化する

提供物の一覧だけでなく、なぜその設計判断に至ったのかを記録しましょう。たとえば GitHub Actions のテンプレートやデプロイパイプラインを出すとき、その設計がどんな背景で、どの用途に適し、どこを改善すべきか／どこは分岐すべきかをユーザーが判断できるようにします。

閉じた場での意思決定は、無秩序なフォークや重複解の乱立を招きます。

3. 優先順位づけられたメンタリング：スケールするオンボーディング

プラットフォームチームは開発者コミュニティに奉仕する立場です。「顧客」にはオンボーディング、貢献ガイドライン、関与のルートが必要です。外部コントリビューター管理ではなく、社内チームが継続的に関与し、改善できる道筋を作ります。

4. 自発的コード貢献：コミュニティ駆動の進化

目的は、プラットフォームチームがすべての要望を自前でさばくことではありません。ユーザーが改善を持ち帰らず、プラットフォームへ還流できる条件を作ることです。そのためには、消費専用ではなく貢献前提でコンポーネントを設計する文化が必要です。

この 4 原則が、成功する InnerSource 実装の土台になります。

ツールの彼方へ：持続可能な開発者コミュニティをつくる

GitHub を使うだけでは InnerSource にはなりません。コードを共有するだけでもコミュニティは生まれません。双方向の貢献と協働の文化こそが要です。

コミュニティ不在のプラットフォームエンジニアリングは、結局のところ開発者に解を提供する別の手段に過ぎません。最も成功するプラットフォームチームは、次のようなエコシステムを作ります。

ユーザーがテンプレートやツールを平台へ還元する
機能要望が協働開発の機会へと変わる
透明なプロセスによって知識共有が自然発生する
プラットフォームの進化がプラットフォームチームの思い込みではなく実ユーザーニーズに駆動される

Netflix や Spotify は、プラットフォーム周りに繁栄する開発者コミュニティを築く方法を示してきました。

次の一歩：小さく始め、コミュニティを育てる

一夜にして組織全体を変える必要はありません。ひとつのプラットフォームコンポーネントから始めましょう。本当に貢献可能な状態にし、使い方だけでなく改善の仕方も書き、ユーザーフィードバックと貢献の明確なルートを用意します。

まずはコアファン――あなたのアプローチに心から賛同し、声を上げてくれる開発者――を育て、その人たちが平台の進化に意味のある貢献ができるようにします。どんな小さなフィードバックでも「貢献」です。なにもプルリクエストを送るだけが「貢献」ではありません。

スケールするプラットフォームエンジニアリングは、より良いツールを作る競争ではありません。そのツールの周りに、より良いコミュニティを作ることです。エンタープライズの制約の中でもコミュニティを育てるための実証済みパターンが、InnerSource Patterns です。

最も成功するプラットフォームチームは、単なるインフラ提供者ではありません。共通の課題と解を持つ開発者同士の協働を促進する、コミュニティビルダーなのです。

あなたのプラットフォームエンジニアリングの旅は、Backstage をデプロイしたところで終わりません。協働の文化を築き始めたとき、ようやく本当に動き出します。

オープンソースのやり方でいこう ― AI 時代における InnerSource の役割と可能性

hello@yukihattori.com (Yuki Hattori) — Mon, 04 Aug 2025 00:00:00 +0000

いまの組織を悩ませる問い

無数の開発者がプロンプトエンジニアリングやコンテキストエンジニアリングの是非を論じ、インフルエンサーが最新の AI コーディング術を披露し、スタートアップが AI ファーストの開発へと舵を切る――そんな議論の洪水の中で、ひときわ大きな空白が残っています。個人の生産性や小規模チームの戦術は語り尽くされる一方で、歴史ある大規模組織が AI トランスフォーメーションをどう進めるべきかについての指針は、圧倒的に足りていないのです。

これは大企業だけの問題ではありません。強力な 10 人の AI チームを抱える小さなスタートアップであっても、やがて巨大なコードベースを扱い、一夜にして大規模システムへとスケールする局面に直面します。根本の問いはこうです。組織は、破綻せずに AI と高速かつシームレスに協働できるよう、ソースコードとコラボレーションの作法をどう整えるのか。

ここで扱うのは「より良いプロンプトの書き方」や「コパイロット体験の最適化」の話ではありません。問うているのは、AI 時代にあなたの会社が“生き延びる”だけか、“伸びる”のかを決める組織の DNA です。

Contents

TL;DR：組織が直面する 5 つの重要課題

AI 駆動の開発には、Open Source Way が解決できる 5 つの組織的課題があります。

標準化のジレンマ：組織は自社流を AI に理解してほしいが、AI が得意なのは独自仕様ではなくオープンな標準です。AI は公開され標準化された実践から広範に学んできた、という事実の受け入れが鍵になります。
品質保証のボトルネック：AI は重複したコードを大量生成し、人間はそれをすべてレビューできません。車輪の再発明を繰り返させるのではなく、品質保証済みコードを社内で共有し、終わりなきレビュー地獄を避ける必要があります。
情報サイロ問題：AI がより自律的になるにつれ、組織はより広い知識へのアクセスを求めますが、情報のサイロ化が多層のアクセス問題を生みます。透明で非サイロな組織ほど、AI は必要情報に官僚的なボトルネックなく到達できます。
ドキュメント形式のカオス：AI は PowerPoint や Excel、独自フォーマットが苦手です。オープンソース流のコラボレーションは自然に Markdown と issue 中心へ寄っていきます――AI が容易に解釈できる形式です。
文脈欠落の危機：人は AI に「なぜ」その判断に至ったかという文脈を抜いたスナップショット情報を渡しがちです。オープンソース文化は意思決定プロセスを自然に記録し、AI が適切に提案するための文脈理解を育みます。

AI を、文脈のない天才エンジニアが突然あなたの組織に加わった存在だと考えてください。 システムやプロセス、歴史に関する前提知識を持たずにやって来た、オープンソースのコントリビューターのようなものです。AI には“組織としてのメンタリング”が必要であり、個人の努力ではなく、私たちが何を・どのように・なぜ行っているのかを理解させるための、体系的で全社的な支援が求められます。

この Open Source Way を社内で実装することを、私たちは InnerSource と呼びます。オープンソースの実践は、透明なコラボレーション、共有された標準、コミュニティ駆動の改善を促します。オープンソースの方法論は、AI が理解しやすい作法へチームを自然に誘導しつつ、あなたの組織固有の知を守ります。オープンソースのアプローチは、「AI が知っている標準的手法」へ徐々に歩調を合わせる戦略を育み、その移行に必要な組織資産と個々の能力を整えます。これは変化を強制する話ではなく、変化が自然で得だと感じられる条件を整える話です。

1. 「うちのやり方」 vs 「標準のやり方」

こう想像してください。あなたの組織は、コードレビュー、ドキュメント標準、テスト手法を何年もかけて磨いてきました。単なる作法ではなく、組織のアイデンティティの一部です。そこへ AI が現れ、丹念に作ってきた慣習を理解しません。生成されるコードは自社の Python スタイルガイドではなく PEP8 風に寄り、テストは独自フレームワークではなく Jest のパターンで書いてきます。

もちろん、AI にあなた固有のやり方を教えることは可能です。ただし、多くの場合、AI が既に持っているゼロショットの知識を活かす方が明らかに容易です。人々が Bootstrap や Tailwind といった確立されたパターンに寄っていくのは、単にその方が効率的だからです。

不都合な真実

AI はあなたの秘伝を知りません。内部のコーディング規約、カスタムフレームワーク、固有のアーキテクチャ判断で学習されてはいないのです。AI が話すのは、広く文書化・共有されてきたオープンソースの共通語です。

ここに即座に摩擦が生まれます。組織は「特別なやり方」に多大な投資をしてきました――それには正当な理由があることが多い。つらいデバッグの歴史から規約が生まれたのかもしれない。コンプライアンス要件に応えるために書式が育ったのかもしれない。どれも恣意的な選択ではなく、組織知が結晶化したプロセスです。

目先の解決策：標準を受け入れる

少なくとも現時点の実用解は標準化です。Python は PEP8 を採用し、コミットメッセージは conventional commits に沿い、テストは確立したパターンに従う。AI が解釈できる形式でドキュメントを構造化する。

それは降伏ではなく、現実的な判断です。AI があなたの標準に沿ったコードを吐くようになれば、摩擦は消えます。コンテキストウィンドウが劇的に拡大すれば、いずれあなたのソースや独自情報を丸ごと文脈に載せられるようにもなるでしょう。レビューは滑らかになり、統合はシームレスになり、開発者は AI 生成コードと戦う時間を減らして、能力を引き出すことに時間を使えます。

長期の現実：AI はやがて「あなた流」を学ぶ

ただし、多くの議論が見落としているニュアンスがあります。これはおそらく一時的な問題だということ。AI システムは文脈や独自情報の理解を急速に高めています。ファインチューニング、改良されたインコンテキスト学習、より長いコンテキストにより、AI はやがて組織の癖を取り込めるようになるでしょう。

では問います。自然解消していくかもしれない問題のために、組織を揺るがす大変動を起こす価値はあるのか。

架け橋としての InnerSource

ここで InnerSource が真価を発揮します。InnerSource は、あなたに組織アイデンティティを一夜にして捨てろとは求めません。安全かつ効率的に移行するための枠組みを提供します――いわば、赤ずきんが安全で効率的な道を見つけられるように導くのです。

InnerSource は「自分のために書く」のではなく、「チームのため、組織全体のため、隣のチームや 1〜2 ホップ先のチームのため」に書くことを意味します。新人のジュニアから経験豊富なベテランまで、誰が読んでもすっと入れるコードを書く。これはコードにとどまらず、コード内ドキュメントやアーキテクチャ判断にも及びます。

InnerSource は、透明なコラボレーション、共有された標準、コミュニティ駆動の改善といったオープンソースの実践を、組織内に根づかせることを後押しします。AI が理解しやすい作法へ自然に寄せながら、組織固有の知を守るのです。

この方法論は、「AI が知っている標準的手法」へ段階的に歩調を合わせる戦略を育むと同時に、その移行に必要な組織資産と個々の能力の整備を進めます。これは強制ではなく、変化が自然で有益だと感じられる条件を整えることです。

2. 品質保証のボトルネック：AI の速度が人間のレビューを上回るとき

これは秘密でもなんでもありません――誰もがこの不都合な真実に苦しんでいます。AI の能力は指数関数的に拡大する一方で、人間の認知能力は相対的に頭打ちです。AI はコード理解を助け、レビューを効率化できますが、人間の処理能力にはどうしても越えられない限界があります。

AI は数秒で 1,000 行のコードを出せます。熟練の開発者でも 1 時間に数百行をレビューするのがやっと。計算が合いません。しかも AI の能力が上がるほど、この差は広がります。

レビューはスケールしにくい

テストを書くことは状況を大きく改善しますし、多くの組織が「テストはこれまで以上に重要」と一致しています――AI 支援開発における必須のガードレールだからです。たとえ AI が実装と一緒にテストを書いたとしても、そのテストを誰かがレビューする必要があります。AI が推論を説明しても、その妥当性を誰かが検証する必要があります。突き当たる壁は、やはり人間の帯域です。

従来の品質保証は「コードは高価である」という前提に立っていました。だからこそ丁寧にレビューする価値があった。しかしコードが安価に大量生成される世界では、このモデルは完全に破綻します。

解決策：品質保証済みコードの“共有”

鍵は、AI に同じ問題を何度も解かせないことです。各所の AI が似たコードを量産する代わりに、レビュー済み・テスト済み・承認済みのコードコンポーネントのリポジトリを用意し、チームが再利用できるようにするのです。

オープンソースや InnerSource の環境に共有部品が多いと、興味深いことが起きます。多くの人が同じ道具やコンポーネントを使い、結果として品質が“集合的な使用”によって保証されていく。多くの目がコードを見て、問題が洗い出され、徐々に磨かれていくのです。

これは前提の転換を要します。コードは個人の所有物ではなく、共同で管理する資源になります。ただし「みんなのもの」はしばしば「誰のものでもない」になりがちなので、強すぎないコードオーナーシップ（弱い所有）と、適切に保守する文化が必要です。

朗報もあります。いまやソースコード保守の多くは AI が担えます。問われるのは、組織がこうした共有リポジトリをどう所有し、どう育てるかです。

チームは自分たちの目先のニーズを越えて、その解決策が組織横断でどう役立つかを考える必要があります。

InnerSource は“体系的な共有”を可能にする

InnerSource は、この変革の文化的土台を提供します。開発者に、目先の課題だけでなく他者が理解・変更・改良できる解決策を書くという、オープンソースのメンテナ視点を促します。

対象はライブラリに限りません。どのコードに品質投資をすべきかの選定フレーム、共有リポジトリの維持プロセス、貢献と再利用を促す文化的プラクティス――これらを整える話です。

この方法論は、自動化と人の監督のバランスにも向き合い、AI 生成コードを品質基準を保ったまま取り込む持続可能な実践を育てます。

3. 情報サイロ問題：AI の“知識飢餓”

組織は、すべてを知る AI――全部署の知識にアクセスし、卓越した部門横断の働きができる“人工の社員”――を夢見ます。しかしこの夢は、情報のサイロという現実に突き当たります。

多層アクセスという難題

あなたの組織をベン図だと考えてみましょう。X 部門はある情報、Y 部門は別の情報、Z 部門はさらに別の情報にアクセスできます。全員が見える交差領域は驚くほど小さいのが常です。

「組織全体の AI」を作ろうとすると、すぐにこの制約にぶつかります。現在の RAG の実装は部門単位での最適化には向きますが、検索精度や部門横断の文脈理解は苦手です。各部門に専用アシスタントは作れても、組織全体を本当に理解する AI は育ちません。

「AI に参照させたいプロジェクトは、そのベン図の一つの円の中に収まるから大丈夫」と思うかもしれません。けれど、これはソースコード権限だけの話ではありません。Notion と Office 365、GitHub と GitLab、ライセンスの有無、役割や職位や部署による権限差――異なるシステムが協働しようとすると、問題は多層・多段に増殖します。短期的には AI は個人ツールに留まりやすく、組織情報へのアクセス不足や権限取得のリードタイムが、効果の重大なボトルネックになります。

効くのは「重なり」を増やすこと

解決は、AI により多くの情報を与えることではありません。部門間で共有される情報の“交差領域”を広げることです。交差が大きいほど、組織 AI は強力になります。

これは文化変革を要します。多くの情報が個人の Google Drive やローカルに溜まりがちです。適切なルールと文化の転換がなければ、人は情報を“自分の手元”に置くほうへ自然と流れます。個人の保有から組織の知能への還元へ、発想を切り替える必要があります。

セキュリティとアクセスの配慮

これは、アクセス制御をすべて外したり、セキュリティの穴を開けたりすることを意味しません。機微なデータの境界を保ちつつ、安全に共有できる範囲を思慮深く広げることです。

課題は技術的であると同時に文化的でもあります。AI が扱えるのは形式化された情報のみであり、 tacit knowledge や個々人が抱え込む情報には手が届きません。だからこそ、オープンで透明なコラボレーションが極めて重要になります。

とはいえ、思考の途中や自信のない資料、未完成の文書を多くの人に見せるのは、心理的なハードルがあります。それを自然で安全に感じられるようにする訓練が必要です。信頼の構築には時間がかかります。セキュリティとプライバシーを守りながら段階的にアクセスを広げる枠組みが要ります。

InnerSource は壁を壊す

InnerSource は、組織内にオープンで協働的な環境をつくることを目的としています。知識共有、貢献の受け入れ、コミュニティ運営の実証済みプラクティスが揃っています。

この方法論は、より広い情報アクセスのための信頼とセキュリティモデルを整え、オープンな情報共有を促す文化変革プログラムを設計します。情報アクセスの変更は一夜で実現しない、という現実にも向き合い、持続的な文化定着を前提に進めていきます。

4. ドキュメント形式のカオス：Markdown 革命

あなたの組織には、PowerPoint、Excel、複雑な Word、JIRA、Confluence、Notion…といった媒体に、何十年分もの知見が蓄積されています。これらを AI に食べさせたい――しかし問題はここです。形式の多様性が、精度の悪夢を引き起こします。

AI にとってのアクセシビリティの壁

AI にとって PowerPoint はXML と画像の束に過ぎません。精魂込めたスライドの意味論は掴めない。Excel は文脈のないデータスープになりがち。複雑な文書は、処理の過程で構造と意味を失います。画像処理の精度にもまだ大きな改善余地があり、プラットフォームの壁（API、検索、権限）も追い打ちをかけます。あなたの知は、異なる API・検索性・アクセス制御を持つ複数のシステムに散在しているのです。

思い切った解：Markdown と GitHub への集約

答えは一見ばかばかしいほど単純に聞こえます。書けるものはすべて Markdown で書き、GitHub（あるいは同等のバージョン管理プラットフォーム）に集約する。

リッチな書式はどうする？複雑な可視化は？既存のワークフローは？――反射的に抵抗が湧くでしょう。しかし、AI がアクセスすべき場所は少なくなり、AI が理解できる意味構造が得られ、履歴管理とコラボ機能が組み込みで、リンク可能で検索しやすく、長期にわたって保守しやすいという利点があります。

マイグレーションの難しさと段階的アプローチ

リッチドキュメントから Markdown へ移すのは、大規模な移行作業であり文化的シフトでもあります。これは、PowerPoint での計画・Excel での追跡といった伝統的なプロジェクト管理から、issue と設計ドキュメント中心のワークフローへ移行する難しさに重なります。

ただし、これは全か無かの話ではありません。「全部 PowerPoint/Excel」か「全部 Markdown」かの二者択一ではなく、AI が読める形式の割合を段階的に増やすのです。管理システムの性質も重要で、複雑な階層権限を必要としない、相対的に“平ら”な情報管理のほうが理想的です。

エンタープライズ統治のための多層権限をサポートするプラットフォームはもちろん重要ですが、高い透明性で管理できる情報の割合を増やすことは、結果的にみんなの利益になります。これは、用途に応じて適切なツールを使い分け、バランスを取る話です。

チームは新しいツールとフローを学び、複雑な文書は再構造化が必要で、権限設計も作り直す必要があるかもしれません。それでも、移行に成功した組織は AI 連携以外にも思いがけない副次的メリット（コラボの改善、バージョン管理の向上、ドキュメントの可用性向上、ツールの複雑性低減）を報告しています。

InnerSource が枠組みを提供する

InnerSource には、この種の組織変革に向けた実証済みの戦略があります。文書の忠実性を保ちながら AI 可読性を高める移行戦略、統一的な情報アーキテクチャの原則、オープンソース流のドキュメント作法を提供します。

リッチドキュメントと AI 可用性のトレードオフを認めつつ、混乱を最小化しながら段階的に進める道筋を示します。

5. 文脈欠落の危機：「なぜ」を理解する

AI は「何を」は分かっても「なぜ」が分かりません。完成物のスナップショットは見えても、どうして・なぜそう決めたのかの文脈が欠けているためです。この限界は、AI 支援開発に大きな問題をもたらします。

スナップショットの問題

多くの人が AI にスナップショット情報を与え、完全な理解を期待します。しかしそれでは、意思決定の背後にある肝心の「なぜ」が欠けます。問題解決には膨大な情報と無数の選択肢があり、採用されなかった案にも採用されなかった理由がある――にもかかわらず、その理路は包括的に記録されないことが多いのです。

現在の AI は完成したコードは見えますが、開発のプロセスは見えません。関数が存在することは知っても、なぜその書き方になったのかは分からない。「非効率」に見えるコードが、意図をもってそうなっているのかどうかを区別できないのです。

その結果、AI の“改善”提案が、入念に組み上げた解決を壊したり、目に見えにくいが重要な役割を持つ“冗長”コードを削除してしまったりする危険が生じます。

インフォーマル知のギャップ

貴重な文脈の多くは、GitHub の issue 議論、Slack の会話、Microsoft Teams のスレッド、廊下でのやり取り、会議での設計判断といった非公式コミュニケーションに宿ります。この組織知は AI にとってアクセスしづらく、時間とともに失われがちですが、現状のコードの理由を理解するうえで不可欠です。

新しいメンバーが、避けるべき実装を理解できないのも同じ理由です。何が決まったかだけでなく、なぜ他案が退けられたかまで記録する歴史的文脈は、人にも AI にも価値があります。

AI が追える“意思決定の道筋”を作る

解決には、意思決定とその理由を捕捉し、AI がアクセスできるようにする仕組みが必要です。あらゆる会話を録音しろという話ではありません。重要な決定と理路を正式に残すということです。

オープンソースでは、意思決定が別文脈・別プラットフォームで行われると、新しい参加者は実装がどう実現されたのか、現在の判断がどう下されたのかを追うのが非常に難しくなります。こうした障壁は、コントリビューションの参加を妨げます。AI も全く同じ壁にぶつかります。

これは、（コミュニケーション基盤との連携といった）技術的課題であると同時に、（意思決定を記録する文化を根づかせるという）文化的課題でもあります。

InnerSource の文化は“なぜ”を自然に残す

オープンソースのプロジェクトは、透明性が成功の前提であるため、意思決定の記録を得意とします。コントリビューターは、コードが何をするかだけでなく、なぜ存在し、どんな問題を解くのかを理解する必要があるからです。

InnerSource はこの文化を社内に持ち込みます。理由を記録し、オープンに議論し、組織知を監査可能な形で残すことを促します。

この方法論は、意思決定ドキュメントのフレームワーク、インフォーマルなコミュニケーションを公式記録へ橋渡しするプロセス、コード変更をビジネス判断と紐づける実践を提供します。

組織の制約という現実

これら多くの課題は、短期から中期で技術が解決するかもしれません。AI 能力の向上、より良い統合ツール、強化された文脈理解が、いくつかの問題を自動的に解いていくでしょう。

しかし組織は、完璧な解を待ってはいられません。AI の力を活かしつつ、現実の制約――予算、リスク回避、規制、大規模組織の慣性――を捌かなければならないのです。

実行可能性の問題

こうした議論になると、しばしば過激な提案が飛び出します。私が Microsoft にいた頃、内製開発力の前進に苦しむお客様がいました。そこに Microsoft のエグゼクティブが来て、一言、「大企業なんだから、最先端エンジニアを多く抱える会社を買えば？」。

たぶん正しい。しかし――。

「革新的な会社を買え」「システムを作り直せ」「抵抗勢力を入れ替えろ」「AI の達人を雇え」。どれも言うは易く行うは難し。多くの組織は、そう簡単には実行できません。

そんな意見はソーシャルメディアでは“正論”として受け止められるでしょうし、実際、ビジョナリーな CEO が迅速に断行できれば理想的でしょう。だから論としては間違っていません。

けれど、現実の企業で戦う経営陣やミドルマネージャーは、すでにそれを知っています。知っているのです。それでもなお、実行できない理由が山ほどある。大規模買収を株主に正当化できない。PMI を成功させる人材が不足している。基幹刷新には高額のコンサル費が要る。既存契約、コンプライアンス、運用依存が縛る――。

過激な助言に従えない会社が誤っているわけではありません。 しばしば“助言者”が無視しがちな、現実の制約の中で最善を尽くしているのです。

段階的変革の必然

だからこそ方法論が重要です。情熱あるリーダー、熱心なコントリビューター、持続する文化進化に支えられた、段階的移行の枠組みが必要です。

自分を変えるのは比較的簡単。しかし環境や他者、部門全体を変えるのは本当に難しい。それでも、制約の中で前に進む必要があります。

“ジョン問題”

この文章を読んでいるあなたは、おそらく成長志向で、新しい AI トピックを能動的に追っているでしょう。高給取りのエンジニアであれば、成長志向を活かしてパフォーマンスを高め続けるはずです。懐疑派は組織に不要だ――そう感じるかもしれません。

でも、隣のチームのジョンのことを考えてみてください。彼は無能ではありません。そこそこ有能で、別の領域では卓越しているかもしれない。ただ、あなたの領域で自発的に成長に協力するインセンティブが弱いのです。

これは必ずしも個人のパフォーマンスの問題ではなく、組織設計の問題です。ジョンが AI 変革に参加したくなる条件をどう作るか。協力が“善意”ではなく“合理”になるよう、インセンティブをどう整合させるか。

広がる「エンジニア」の定義

InnerSource はもともと、ソースコード・情報・コラボレーションを扱い、新規コントリビューターの参加を促すためのエンジニアリング方法論として設計されました。けれど、「エンジニア」の定義は明らかに広がっています。

Ruby on Rails が登場したとき、“フレームワークのユーザー”がエンジニアコミュニティの一員になりました。Rails がソフトウェア開発への参入点を提供したからです。いまは「Vibe Coding」やAI アシスト開発が、新たな参入点になっています。

より多くの人が「エンジニアリング」に関わるにつれて、従来の境界は溶けていきます。かつて「非エンジニア」と見なされていた人々が、コード作成、システム設計、技術判断に参加するようになっています。

「非エンジニアが学習なしに突然エンジニア同等の力を得られるのか？」という懐疑は理解できます。それでも参入障壁は着実に下がり、参加の敷居は低くなり続けているという事実は否定できません。

ソフトウェア創造の民主化

この広がりは、過去の技術変化を想起させます。Rails が強力な抽象化で Web 開発を民主化したように、AI はコード生成の技術的障壁を下げ、ソフトウェア創造を民主化しています。

新たな課題も生まれます。参加者が増えても品質をどう保つか。変更の敷居が下がっても安全性をどう担保するか。より多様な人材が加わる中で、組織知をどう保存するか。

組織的フレームワークとしての InnerSource

InnerSource は、スキルや動機が多様なコントリビューターのコミュニティを運営するための答えを提供します。オンボーディング、品質基準の維持、組織知の保存といった実証済みのプラクティスが揃っています。

「エンジニア」の定義が AI アシスト開発者を含むほど広がるにつれ、この方法論の重要性は一層高まります。新しい現実を運営するための文化的・方法論的な枠組みをもたらすからです。

結論：AI 戦略としての Open Source Way

未来は、自社固有の知とプロセスをAI の能力と上手にブレンドできる組織のものです。人と AI の二者択一ではなく、両者を相互に増幅する関係をどう築くかが問われます。

Open Source Way は、AI とうまく協働するための鍵です。透明性を抱き、貢献を促し、意思決定を記録し、知を共有し、コミュニティを育てる組織が、AI 時代において繁栄します。

オープンソース原則の組織内具現が InnerSource です。情報共有、品質保証、アクセシビリティ、文脈保存といった、AI を開発プロセスに統合する際に組織が直面する根本課題に対し、この枠組みは解を与えます。

次の一歩

これは InnerSource を一晩で導入する話でも、劇的な組織変革を強いる話でもありません。AI に優しく、同時にあなたの知と文化を守る実践を、段階的に取り入れていくことです。

小さく始めましょう。チームやプロジェクトを一つ選ぶ。コードをもっとオープンに共有する。意思決定をより丁寧に記録する。意味のある範囲で標準化する。透明性によって信頼を築く。

開放とセキュリティ、標準化と独自性、AI の能力と人間の判断。 このバランスを体得した組織が、次のソフトウェア開発時代を形作ります。

AI がソフトウェアの作り方を変えるかどうか、という問いではありません。あなたの組織が、その変化に“形作られる側”になるのか、“形作る側”になるのか。

選択は、いつだってあなたの手にあります。Open Source Way は、そこへ至る実証済みの道を示しています。