オープンな環境とルールの作り方
オープンな場の作り方
インナーソースの実践には、ソースコードリポジトリを企業内にオープンにする必要があります。さらに、そのリポジトリへのコントリビューションや開発に関する議論をオープンにし、誰もが開発に参加できるようにする必要もあります。つまり、これらのことを実践する場が必要です。
それぞれの組織やプロジェクトごとにソースコードリポジトリを格納するやり方は異なるかもしれません。しかし、どのような形にするにしても、インナーソースプロジェクトの成功に必要な要素は共通しています。オープン性と透明性があることです。こうした要素を持つプロジェクトを、企業全体でより効率的に進めるには、次の2つのいずれか、または両方の手段を用いることが良いでしょう。
- インナーソースポータルサイトを作る
- インナーソースに関係するすべてのリポジトリに一箇所でアクセスできるようにする
インナーソースのポータルサイトを作るのは、すべてのインナーソースプロジェクトの情報を集約し、発見性を高めるために用いる方法です。どのようなインナーソースのプロジェクトがあるか、簡単な説明を含めて掲載しておけば、たとえリポジトリが置かれるサービスが分散していたとしても、すべてのインナーソースプロジェクトから検索し、簡単に到達できるようになります。場合によっては、そのポータルサイトをインナーソースの流通の場として活用することも可能です。
このポータルサイトがあれば、インナーソースプロジェクトを見つけることはできます。しかし、それぞれのリポジトリが置かれる環境やツールが異なると、コラボレーションの妨げになる可能性もあります。例えば、プルリクエストを送る方法が環境ごとに異なるという理由で、開発が一時停止してしまう可能性も否定はできません。
インナーソースに関係するリポジトリを一つのサービスに集約すれば、その中ですべてのコラボレーションを行えるようになります。こうした場は、例えばGitHubやGitLabなどのサービスを用いて提供することも可能です。同じサービスの上に、インナーソースのすべてのプロジェクトが置かれることで、リポジトリ管理や、リポジトリ間のやりとりも効率化できます。さらに、ポータルサイトと組み合わせることで、インナーソースプロジェクトの発見性を高め、コラボレーションしやすい環境を構築することができます。
図2：インナーソースポータルサイトとリポジトリ
ルールを作ろう
インナーソースがオープンソースと異なることは、広く一般に公開された場で行うものではなく、企業または企業グループの中の活動として行われることです。企業の中であっても、複数の組織が関わることになると、それぞれの組織のルールや文化が異なることは良くあります。そのような組織の多様性は尊重するのは良しとしても、すべてのインナーソースのプロジェクトが異なるルールで運用されていると、組織ごとに異なる考え方が原因で、コントリビューションの内容や開発成果の扱いが不透明になってしまうことがあります。
例えば、あるチームが開発したソースコードが、製品利用するまでを想定していなかったとします。しかし、別のチームが利用した範囲では動作したため、知らないところで製品搭載されてしまうということが起こるかもしれません。これは、マナーの問題だけでなく、資産性など法務面の問題になる可能性もあります。
こうした事態を避けるためにも、インナーソースの実践にあたっては、最低限のルールを提示する必要があります。先程の成果の扱いに対する考え方に一定の基準を設ける方法の一つに、インナーソースライセンスを定める方法があります。インナーソースライセンスには、次のようなことを記述すると良いでしょう。
- どの組織が利用可能か（グループ企業まで含めるかなど）
- 何ができるか（改変、変更、利用、再配布など）
- 利用する際の制限はどのようなものか（知財権や免責事項など）
例えば、「企業内で実験的に利用する限りであれば、自由にコピーして、改変、利用、再配布できるが、製品搭載など企業の外に出ていく場合はトラステッドコミッターに相談する」という条件のライセンスにしたとします。そうすれば、先に述べたような問題を、緩和することができるようになります。
なお、こうしたルール作りは諸刃の剣となることを認識しておく必要があります。あらゆるコーナーケースを網羅するルールを定めると、参加するメンバーの活動を制限し、結果としてインナーソースの仕組みの良さを活かすことができなくなります。それぞれの企業の事情に合わせて、開発者が迷わずにインナーソースに参加できるルールを工夫してみてください。
先導者になろう
インナーソースを広めようとするのハードルの一つが、参加者を集めることです。企業でトップダウンでインナーソースの活動を始めることは、活動を活性化させるための要素の一つかもしれません。しかし、それに加えてボトムアップでもインナーソースの活動を推進することが必要です。なぜなら、ソフトウェアの開発に関する課題を抱えているのは開発者だからです。
企業内で組織の壁を感じた場合、誰かがその壁を打破する活動をしない限り、壁を壊すことはできません。これを組織的にサポートする方法に、オープンソース・プログラム・オフィス（OSPO）の活動の一つに位置づけるという方法があります。OSPOは、OSSに関して、セキュリティやライセンスコンプライアンスの観点から、組織的・戦略的に利活用を推進することが企業に求められていることから、さまざまな企業で設立の動きがあります。
オープンソースの開発の仕組みは、インナーソースの開発との親和性が高いため、インナーソースもOSPOの機能の一つとして位置づけることで、社内と社外、インナーソースからオープンソースへの繋がりも意識した戦略的な活動が可能になります。
もし、あなたがOSPOの一員であるなら、ぜひ率先して共通の課題を見つける活動を提案してみてください。そうでないとしても、普段の企業の中の仲間とのコミュニケーションから、同じ悩みを抱えていないか感じ取ってみてください。一つ事例を見つけたら、しめたものです。周りを巻き込んでインナーソース開発へと誘ってみましょう。
コミュニティに参加しよう
InnerSouce Commonsを通して、日本でもインナーソースのコミュニティが立ち上がっています。インナーソースを企業内に広めるには、さまざまな苦労があるかもしれません。しかし、苦労するポイントは、他の企業と共通している可能性が高いものです。こうした共通の課題を、一緒に解決してみませんか。
InnerSouce CommonsのSlackに、日本語で議論できるチャネルが開設されています。また、ドキュメントの日本語化も進められていますので、ぜひ参加してみてください。
さあ！ インナーソースを始めよう
4回の連載で、インナーソースとはどのようなものか、そこに関わる人が各々の立場でどのように関われば良いか、そして実際に始める時のポイントについて解説しました。本記事をインナーソース実践に少しでも役立てていただければ幸いです。
人が集まる環境を作り、参加する人たちが前向きに取り組み称賛しあう雰囲気を作る。インナーソースという言葉を意識しなくても、企業の仕組みとカルチャーがそのような形になれば、インナーソースは成功します。カルチャーを変えるのが先か、仕組みを用意するのが先かではなく、課題意識を持った人が、企業の中でオープンに活動すれば、少しずつカルチャーが変わり、場や仕組みもより成熟したものになるかもしれません。
インナーソースを成功に導くのは、この記事を読んでいただいている読者の皆さんです。さあ、一緒にインナーソースを始めましょう！
