本文書のライセンスについて
本記事は、InnerSourceCommons.orgが提供するInnerSource Learning Pathを元に再編集したもので、CC BY-SA 4.0（表示 - 継承 4.0 国際）ライセンスに従い提供されています。
こんな経験ありませんか？
企業におけるソフトウェア開発は、複数のチームが関わり連携しながら開発を進めることがよくあります。そうした開発で、次のような経験をされたことはないでしょうか？
- 他のチームの機能追加を待っていたら遅れてしまった
- 他のチームの実装にバグがあることを発見して知らせたのに、修正される気配がない
- いくつかのチームで似たような機能を作ってしまい、全てメンテナンスしないといけない
ここでは次の図にある2つのチーム（チームAとチームB）が関わる開発プロジェクトを参考にしてみましょう。
2つのチームが関わるプロジェクト
チームBの開発は順調に進む中、チームAが提供する予定の機能が必要になりました。もしこの時までに機能がチームAで実装されていなかったら、どうしたら良いでしょうか？ この状況では、次の3つの手段のいずれかが選択できますが、いずれも利点と欠点があります。
1. 機能追加を待つ
チームBは予定を変更して別の作業を優先し、チームAの機能追加を待つことにします。この手段の利点は、チームBの追加作業を最小限にできるという点です。しかし、チームAに全てを任せる形となるため、いつまで経ってもチームAの開発が終わらない可能性があるという欠点があります。
2. 勝手に実装する
足りない機能をチームBで独自に実装します。この手段の利点は、チームAから機能が提供されなくても作業を継続できるという点です。しかし、機能の存在を知っているのはチームBだけなので、同じ機能を必要とする他の利用者には提供されないだけでなく、そのコードをメンテナンスし続けなければならないという欠点があります。また、チームAの実装が終わった時点で、プロジェクト内に同じ機能を複数抱えることになってしまうという欠点もあります。
3. 上司を通して圧力をかける
チームAの上長に影響力のある人にお願いして開発を加速してもらいます。この手段の利点は、上手く行けば必要な機能が手に入るかも知れないということです。しかし、こうしたやり方は、チーム間の関係や人間関係を険悪なものにするため、何度も使えるものではありませんし、チームBは本来の開発と関係がない政治的な動きにコストをかけなければならないという欠点があります。
インナーソースを使えば、これら全ての欠点を解決しながら、必要な機能を手に入れることができます。次の節では、インナーソースの概要を説明し、なぜ欠点を解決することができるのかについて見てきましょう。
インナーソースとは
インナーソースは、組織内のソフトウェア開発にオープンソース・ソフトウェアの開発方法を取り込むものです。これは、次の2つのことを組織内で実践することです。
- 開発の状態を誰からも見える状態にする
- コントリビューションを受け入れる
開発の状態には、コードだけでなく開発計画や意思決定の過程、取り組んでいる課題の一覧も含まれます。そしてコードなどに対するコントリビューションを受け入れ可能とすることで、共通の問題を協力して解決することが可能になります。
先程の例でいえば、チームAが開発の状態をチームBに公開していれば、チームBはチームAの開発が順調に進んでいるかどうかを把握することができます。そして、上手くいっていないようであればチームBが独自に実装する代わりに、チームAが開発しているコードに取り込まれるように実装してコードをコントリビューションします。こうすることで、チームBは必要な機能をチームA公認の状態で利用することが可能となるだけでなく、将来独自にメンテナンスする必要もなくなります。チームAとしても、実装予定だった機能が得られ、開発スケジュールに余裕が生まれるかもしれません。
コントリビューションを受け入れるチームAはホストチーム、コントリビューションするチームBはゲストチームと表現することもあります。こうした、ホストやゲストの言葉は、お客（ゲスト）を家に招く人（ホスト）からきたものです。
ゲストとホストの関係
コントリビューションを受け入れるホストチームとしては、何でもコントリビューションを受け入れれば良いというものではありません。もしかすると、既に実装済みの機能に大きな影響が生じたり、必要のない機能の取り込みを要求されたりするかもしれません。そうならないために、ゲストチームから見て、何が受け入れ可能なのか、どのように投稿したら受け入れやすいかを分かりやすく明示しておくことが必要です。こうしたそれぞれの行動は、まさにお客を自宅に招くために整理整頓するホストと、招いていただいた家のルールを守るゲストと同じですね。
インナーソースでは、ホストチームとゲストチームの間の「コントリビューション」を取り巻く役割として、次の図に示すような3つの役割を定義しています。
インナーソースにおける役割
- コントリビューター：ホストチームに対してコードを投稿するゲストチーム内の人
- トラステッドコミッター：受け入れるコードをレビューして、そのコードが受け入れ可能となるようにコントリビューターをサポートするホストチーム内の人
- プロダクトオーナー：ホストチームが受け入れ可能なコントリビューションを決定するホストチーム内の人
インナーソースにおけるコントリビューションの流れを、先程までの例と3つの役割を通して書くと次のようになります。
- ゲストチームの人がホストチームの機能を要求します。
- プロダクトオーナーは、要求された機能がコントリビューションを受け入れ可能なものか確認します。もし、受け入れ可能な場合には、アーキテクチャの制約やコーディング規約などを含めた提供方法などの詳細を提示します。
- ゲストチームの人は機能を実装し、コントリビューターとしてプルリクエストを送付します。
- トラステッドコミッターは、プルリクエストの内容をレビューします。もし、コードの変更が必要な場合、コントリビューターに修正を依頼します。またコントリビューターからの質問にも回答します。
- トラステッドコミッターは、プルリクエストのレビューが終了したらコードをマージします。
