# なぜインナーソースなのか
私たちはオープンソースコミュニティのグループの1つとして、オープンソースの原則とプロセスを企業に取り込むことで、もっとうまく仕事ができるようになると強く感じています。 この取り組みは、会社には開発スピードの向上やチーム間のコラボレーション向上、さらにはドキュメントの充実などの面で効果があります。また、従業員にはメンタリングや説明責任、コミュニティからの支援を通して職場の雰囲気が良くなるという効果があります。
これは大きなゴールです。 私たちは、組織の中で情報やアイデアを共有するインナーソースという枠組みを広めるために、 [InnerSource Commons](http://paypal.github.io/InnerSourceCommons/) というコミュニティを立ち上げました。 私たちは、まずは小さな変化を起こすことに焦点をあてています。 なぜなら、完璧を求めることは行動の妨げにしかならないからです。
Commons は、企業がオープンソースの基本的な枠組み理解すれば、自信をもってオープンソースコミュニティで生産的な活動ができると確信しています。 インナーソースは、誰もが各々の限界を尊重しつつ参加できる仕組みです。 インナーソースは、会社の中のチームや部門にオープンとはいえ、プロプライエタリな情報を公開するものではありません。 むしろ、サイロを減らして組織間の相互理解を深め、イノベーションを加速するのに効果的なものです。
どのようにオープンソースのツールや方法論を取り込んで、企業内にインナーソースコミュニティを立ち上げるか、その方法を共有するために、本書を執筆しています。 末尾には、組織の中ですぐに使えるチェックリストを掲載しています。 そのチェックリストを使えば、読者の組織がどの程度インナーソースプロジェクトの実装に近づいているかを確認できます。 インナーソースの実装としては、推奨する一般的なステップを記載しており、そのステップを完了したグループが「インナーソースの準備ができている」状態となることを目指しています。
本書の目的は、典型的な企業活動の根本的な部分に変化を促す簡単な方法を見つけることにあります。
インナーソースの優れた点の1つは、本社からのトップダウンの指示で開始する必要はないということです。また、開始すべきではありません。 ある部門の1つのチームが、その効果を確認するのに良い場所で小さな変化を起こすことができるものです。 そして願わくば、他のチームが刺激されて同じようにすることを期待しています。
多くのインナーソースのプロセスは、エラーや問題を解決することから始まっています。 実際、私たちの最大の強みの1つは、自分や他人が犯した誤りから学んだ教訓を共有できることです。 私たちが教訓を共有することで、別の機会に他の人たちが助けてくれます。 これが透明性を奨励する理由の1つです。
例えば、製品のインテグレーション関わっている人たちは、一部の関係者だけでプライベートにメールをやり取りしたりミーティングをしたりする方が、すべてのステークホルダーを巻き込むよりも簡単だと感じています。 関係者全員に透明性のあるコラボレーションを要求し大きな効果を得る \[1-1] には、自らが率先して情報を(見つけられる場所に)置き、他の人が学べるようにすることが必要です。
インナーソースは、ツールとプロセスがあれば実施できますが、文化の変化を起こすものでもあります。 最も大きな変化は、ミスを許して議論し、そこから学ぶことにあります。
この本は、こうした前提のもと、実際に経験したことを元にして書かれています。 そして、その経験から学んだことや解決方法を共有し、誰でもコメントをしたり、その情報を参考に人々が成長できるように、 InnerSource Commons のサイトに全て公開しています。 また、紙の書籍も出版しています。 私たちは "プルリクエストの文化" で活動するようにしているので、もし本書を読んでいて間違いを見つけたり、議論を追加したりする必要があると感じたときには、いつでもオンラインでフィードバックしてください。
ビジネス環境においては、自由にフィードバックを共有することがブランド価値を低下させ金銭的な影響を生じる可能性があることから、難しいこともあるでしょう。 Commons は、チャタムハウスルールで活動しているので、明示的に公開を許可しない限り、誰もあなたの関与について触れません。 実際、この本でも関わった人を守るために、何人かの名前を変更しています。
本書に記された私達の経験を読むことで、小さな変化がより大きな文化の変革へと繋がることを追体験していただきたいと願っています。 そのために重要なソフトウェア変更管理の方法も本書で説明しています。
## 対象読者
この本は、全ての読者がそれぞれの立場について学ぶことができるように書かれています。 開発者は、コントリビュータや、コントリビューションされた内容を確認する *トラステッド・コミッター* (この役割については後ほど説明します)が、どのようなものが学べます。 プロダクトオーナーやプロダクトスペシャリストは、再利用やコラボレーション、インテグレーションを通して、大きな効果が得られます。 プランナーは、インナーソースの導入による変革をどのように管理するか理解することで、複雑なインテグレーションやコラボレーションを調停したり、属人的な知識や技術的な負債を減らせるようになります。 そして最後に上位の管理者は、従業員満足度を向上したり、新しい事業ユニットや買収した企業を統合するための、新しい方法を発見できます。
## オープンソースにあって、その他にないものは何か
端的に言うと、オープンソースには柔軟性があり、透過性に基づくグループ間の相乗効果があり、コラボレーションを推奨するカルチャーがあり、そして標準化され簡単に見つけられるドキュメントを用いることで学習曲線を大幅に改善しているという特徴があります。 オープンソースには、メンターに対する敬意を持ち、コントリビューションを負担と考えずにギフトと考えて自発的に参加する開発者がいます。 透明性や広範なコントリビューションで、より多くのユーザのニーズが満たされるようになっています。
## 今日のオープンソース
OSS(Open Source Software) は、「勝利した」と言われています。 Fortune500に掲載されている会社は、何らかのオープンソースプロジェクトを利用したり、そこで活動したりしています。 オープンソースコミュニティにおける主要なプレイヤーである Sonatype は、2014に大企業を対象に行った調査で「今や典型的なアプリケーションの90％以上がオープンソースコンポーネントとなっている」ということを明らかにしました \[1-2]。 OSS の主な強みのひとつに、欠陥密度が産業界の平均よりも一貫して低いということがあります \[1-3]。
## 産業界におけるオープンソースの将来：インナーソース
しかし、 *企業内* でオープンソースの力はどのように役に立つのでしょうか。 現実的には、ほとんどの企業が、規制や契約上ソースコード共有が禁止されているなどの理由で、オープンソースの力を活かすことができていません。 ここでインナーソースの出番となります。 インナーソースは、オープンソース・ソフトウェアの活動から学ぶことを、企業内のソフトウェア開発に活かす方法なのです。
インナーソースはオープンソースの利点を企業文化に取り入れることで、企業がオープンソースコミュニティでより良い活動者となるのに役立ちます。 その重要なゴールには、次のものがあります。
* 企業内のコラボレーション改善方法を学ぶ
* 企業内で洗練されたコードの作成を促進する
* ボトルネックを減らす
* チーム間連携を促進する
大きな変革を素早く起こすことは、ほとんどの企業にとって大変困難なことです。 急激な企業文化やプロセスを変更は、状況を改善させるのではなく、悪化させてしまうことがあります。 これがトップからの強要で、関係者からの賛同が得られない場合はなおさらです。 インナーソースの仕組みをうまく機能させるためには、効果測定しやすい小さな活動から始め、状況に応じて折り合いをつけながら柔軟に進めることが重要です。 こうすることで、大きな変革を起こす前にインナーソースはどのような効果があるか関係者が理解でき、混乱を最小にできます。 実際に、ある部門の１チームからインナーソースを始めるのが効果的です。
## インナーソースの歴史
企業全体にオープンソースの方法論適用を決めることは、特に新しいことではありません。 オープンソースが提唱されて以降、多くの人々が同様の方法を用いてプロジェクトに取り組んできました。 オープンソースプロジェクトに関わる人の多くは、その方法論を職場に適用したいと考えるため、こうした決定がされることは自然な流れです。 「社内オープンソース」、「エンタープライズオープンソース」、「ビジュアルソース」、「コーポレートオープンソース」など様々な名前を用いてオープンソースの方法論を企業に適用するための説明が行われてきましたが、今まで成功した人はほとんどいません。 現在用いているインナーソース(InnerSource)という用語は、15年以上前に Tim O’Reilly が提案したものです。 提案当初は「 Inner Source 」としていましたが、単語間のスペースを削除して用語検索しやすくしました。
インナーソースの方法論を広める活動は、それぞれの企業で個別にオープンソースの開発方法を社内適用する活動をしてきた人たちが、オープンソースコミュニティで知り合い会話を始めたことから始まりました。 そして、オープンソースの開発スタイル\[1-4] を取り入れたオープンなコンソーシアムを設立して、インナーソースの定義や標準を作成し、その維持に取り組んでいます。 こうすることで、オープンソースのリーダー達は、時に困難が想定される企業内でもインナーソース本来の考え方や文化を維持できます。 この活動の重要なポイントの1つは、*チャタムハウスルール (Chatham House Rule)* を厳格に適用していることです。
> 会議の一部や全体が[チャタムハウスルール](https://www.chathamhouse.org/about/chatham-house-rule)で行われる場合、参加者はその会議における発言者を含む参加者全員の身元や所属を明かさないというルールに従う限り、その会議で得た情報を自由に利用できます。
チャタムハウスルールのようなシンプルなルールを作ることは、インナーソースの活動にも活かされています。 誰もが守れる簡単なルールを作成することで、変革の効果を最大にできます。 しかし、商慣習がある中での透明性の確保は大きなハードルでした。 透明性を確保するというルールは、たとえ競合相手であってもオープンにコラボレーションする方が、より大きな効果を得られる場合があるということを認識するためのものでもあります。 グループとして協力し合う中で、互いに失敗を認めて情報や不満を共有することで、問題をより素早く解決できるようになります。
本来、チャタムハウスのルールはオープンソースに必要ないものですが、インナーソースの活動開始と発展には重要なものでした。 インナーソースの定義や標準の作成に関わる人のプライバシーを尊重しつつ透明性やオープン性を確保することは、この活動の特徴と言えます。 今でも、プライバシーと透明性の両立という二律背反な状況のバランスを取りながら活動しています。
## オープンソースの方法論の裏にあるもの
ジョークやユーモアには長い伝統があり、(例えば[カーゴ・カルト](https://en.wikipedia.org/wiki/Cargo_cult)で竹を使ってハリボテの飛行機を作るのは何故かという事と同様に)それをよく理解していない子供ですら見様見真似していることがあります。 しかし、ユーモアという言葉には相手を単に笑わせるだけでなく、相手への配慮をもって傷つけずに笑わせるという側面もあり、相手の理解はとても重要です。 残念ながら企業がオープンソースの方法論採用で失敗する原因の多くは、この方法論の本質の理解不足にあります。 なぜオープンソースが成功するか、その本質を理解せずに実践について語るだけではオープンソースの方法論を上手に採用できません。
ほとんどのビジネスドキュメントは、「*なぜ*」それが必要かという事より、「*どのように*」それを行うかを強調しています。 ビジネス環境は、往々にしてプロセスを決めるより早く変化します。 本書は、「*なぜ*」に着目して書かれており、新しいプラクティスの成功可能性を高める適切な環境作りに配慮しています。 本書の末尾にインナーソースを開始するためのチェックリストを掲載しています。これを見れば、なぜそのようなプロセスをとったのか、その背景や関係者との関わりついて学ぶことができます。 インナーソースを企業に取り入れることは一筋縄ではいかず、この本の事例を真似しても全ての人がうまく行くとは限りません。 *なぜ* 新しいルールやプロセスが必要で、それが有効かを学ぶことで、個々のニーズにあったプロセス、つまりは「自分の *やり方* 」を見つけてください。
もちろん、早く先に進みたければ、この本のチェックリストや[ウェブサイト](http://paypal.github.io/InnerSourceCommons/)はスキップできます。 しかし、「*なぜ*」を簡単に理解できる工夫が各所にあります。 各章の最初には要約があり、問題とその解決のための最小のステップ、さらにはその解決策が有効な理由を解説しています。
## 1章の参考文献と注釈
* \[1-1] 6章に詳細があります。
* \[1-2] Wayne Jackson, [“The 2014 Survey: Marked by an Industry Shock Wave”](https://blog.sonatype.com/2014/06/opening_letter_2014_survey/), The Nexus, June 20, 2014.
* \[1-3] Coverity 静的解析年次レポートより。最近では [“Coverity Scan Report”](https://www.synopsys.com/blogs/software-security/2017-coverity-scan-report-open-source-security/)
* 訳注：原著では Coverity Scan Report 2013 へのリンクがありましたが、邦訳を執筆している2023年5月現在は存在しないので、2017年版に差し替えています。
* \[1-4] 具体的には Apache Software Foundation のスタイルを指します。
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://jp-contents.innersourcecommons.org/understanding-the-innersource-checklist/contents/1-why-innersource.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.