本文書のライセンスについて
本記事は、InnerSourceCommons.orgが提供するInnerSource Learning Pathを元に再編集したもので、CC BY-SA 4.0（表示 - 継承 4.0 国際）ライセンスに従い提供されています。
コントリビューターになるメリット
インナーソースにおけるコントリビューターとは？
インナーソースにおけるコントリビューターとは、図にあるように他のチーム（ホストチーム）に対しコードを提供するゲストチーム内の人のことです。これは、同じプロジェクトを進めている別チームの人の場合もあれば、全く異なるプロジェクトのチームの人かもしれません。インナーソースでは、すべてのリポジトリが見える化されているので、あらゆる人がコントリビューターになることができます。
コントリビューターのメリット
コントリビューターとしてホストチームのコードにコントリビューションすること、ホストチームと共に働くことには、どのようなメリットがあるのでしょうか？こうしたメリットには、コントリビューター個人としてのメリット、コントリビューションを行うチームとしてのメリット、さらには会社のような組織としてのメリットがあります。以下では、それぞれの視点で、どのようなメリットがあるか見ていきましょう。
個人のメリット
個人の視点で、コントリビューションするメリットは、自分が解決したい課題を必要なタイミングで解決に導くことができることにあります。さらに、この課題解決をホストチームと共に行うことには、さまざまなメリットがあります。
まず、課題解決にあたり、独りで解決策を考えるだけでなく、ホストチームの協力も得ることができます。提案する解決策がホストチームという専門家により洗練され、品質の向上に繋がります。さらに、ホストチームからの助言をもらうだけでなく、一緒に作業することができれば、開発スピードも大幅に向上するでしょう。
ホストチームのメンバーと一緒に作業をすることのメリットは、時間が経つにつれ大きくなります。ホストチームの作業への理解が進むことで、コントリビューターのプロジェクト全体への理解が広まると共に、開発スキルも向上します。例えば、ホストチームが利用している開発ツールが異なる場合、そのツールについて実践的な方法で学ぶことができます。
さらに、ホストチームと一緒に作業して評価を得ることは、コントリビューターの評判が組織の枠を越えて広がることになります。もしかすると、そうした評価を得たことで、仕事に対する楽しみが増え、モチベーションアップにも繋がるかもしれません。
チームのメリット
チーム視点でコントリビューターが他チームにコントリビューションすることのメリットは2つあります。ひとつは、自チームの責任範囲ではないコードを、独自実装として抱え込まなくて済むという点があげられます。例えば、ホストチームにコントリビューションした機能に変更が加わったとします。このとき必要となる関連部分の互換性チェックは、ホストチームで行われるため、ゲストチームとしては独自に追従する必要がなくなります。
もうひとつは、ホストチームの開発方向性やスケジュールに対して、自チームの意見を取り込みやすくするかもしれないということです。何回かコントリビューションを繰り返し成功すると、ホストチームとの間に信頼関係が構築されます。そうすると、コントリビューションが受け入れられやすくなったり、コントリビューションの際に議論が必要な場合にも、コントリビューターの意見が通りやすくなったりする可能性があります。
組織のメリット
インナーソースのコントリビューターが組織をまたいでコントリビューションすることは、組織に対しても次のようなメリットがあります。
- 複数の実装が維持されなくなる
- ノウハウを持つ人が増える
- 組織間のポジティブな関係を構築できる
まず、複数の実装が維持されなくなる（似たような実装を持たない）ことは、会社組織全体としてのメンテナンスコストの削減に繋がります。さらに、それらの実装は、より多くの関係者から利用されることになるため、コードが精査され、会社としてリリースするソフトウェアの品質やセキュリティの向上にも繋がります。さらには、理解しやすく再利用しやすいモジュール化されたコードになる可能性もあります。
次に、組織をまたいだコラボレーションが活性化すると、結果として別の組織のプロジェクトや、コードに関するノウハウを持つ人が増えることに繋がります。その効果として、「誰かがいなくなると開発が止まり、ビジネスが立ち行かなくなる」という状況の回避に繋がるかもしれません。
そして、インナーソースが会社という組織全体で定着すると、成功事例が広まりやすくなり、組織間のポジティブな関係も構築でき、副次的な効果として従業員の定着にも繋がります。また、多様な考えを持つメンバーが、チーム間でコラボレーションすることで、より多くの意見交換が行われ、イノベーション推進に繋がる可能性もあります。
コントリビューターの自由
ここで前回の振り返りも兼ねて、インナーソースがどのような場合に力を発揮するのか見てみましょう。複数のチームが相互関係の中で開発を進めている場合、それぞれのチームの開発は、チームごとの優先順位に従って行われます。しかし、時として他のチームに提供しなければならない機能の提供スケジュールが、自チームの想定と合わないということが起こり得ます。
図2の例でチームBはデータ表示を行うサービスを作成しています。表示するためのデータはチームAが作成する機能を用いて取得する必要があります。チームBの開発は順調に進み、チームAが提供予定の機能が必要になりました。しかし、チームAのスケジュールが遅れており、必要な機能の実装が終わっていません。このようなとき、どのように対処したら良いでしょうか？
インナーソースを用いずに開発を進めていると、いつまでもチームAに待たされたり、チームAが作る予定の機能をチームBでも作成してしまい、本来チームBの責任範囲ではない機能を独自にメンテナンスしなければならない状況になったりする可能性があります。場合によっては、上司を通して圧力をかけるような、開発とは関係ない政治的な活動までしなければならなくなる可能性もあります。
インナーソースを用いて開発を進めると、チームAの開発遅延により必要な機能がチームBに提供されない場合も、チームBの活動は止まることがありません。インナーソースでは、すべてのリポジトリが公開されています。もし、チームAから必要なものが提供されないときは、コントリビューターとして活動することで、チームAのリポジトリにあるコードに直接変更を行う自由がコントリビューターにはあるのです。このとき、チームAは図1のホストチーム、チームBがゲストチームとなります。
コードに変更を加える際に大切なのは、コントリビューターの自由を間違えないことです。リポジトリが公開されていることで、ホストチームのリポジトリのコードをコピーして、ゲストチームの中で必要な変更を加え、手元に置いて利用することも自由です。しかし、その場合は、変更したコードを自分たちでメンテナンスしなければならないばかりか、ホストチームの新しいリリースのいずれに対しても、自分たちが行った変更を追従させる必要が生じるという問題も発生します。
自由に修正できるのあれば、コードのオーナーであるホストチームと一緒になってそれを行う。そのためには、ホストチームとコミュニケーションを取り、コラボレーションしながら開発を進める。コントリビューターの自由の裏にある、こうしたインナーソース特有の解決方法を意識すること、さらに行動に移すためのマインドセットの変化が大切です。
どのようなことをコントリビューションすれば良いか
コントリビューターとして、コントリビューションを始めるにあたり大切なポイントのひとつは共通の課題です。同じプロジェクトに関係する複数のチームの場合は、プロジェクトの完遂や成功といった明確な目的があり、機能の依存関係も明確です。これを、企業という組織全体で考えた場合には、いかがでしょうか？例えば、共通サービスがほしい、共通プラットフォームが必要、などの課題はないでしょうか？誰かが困っていることに対して、あなたはノウハウを持っていたりしないでしょうか？こうした課題解決の接点となり得るポイントすべてが、インナーソースのコントリビューションのポイントとなります。
もう少し具体的に見ると、他チームが提供するコードやサービスの改善点の報告、利用実績に関する報告、ドキュメントの改善、同じコードやサービスを利用する他のユーザーのサポート、バグの報告、バグの分類の支援、バグを確認するテストケースの提供、修正パッチの提供、開発の自動化や環境の改善など、すべてがコントリビューションのポイントになり得ます。つまり、どのようなことであれ、チームの垣根を越えて改善に向かうために、ノウハウやコードを共有することは正しいコントリビューションといえます。
