それぞれの立場で見る、インナーソースのメリット
インナーソースを用いることは、ゲストチームやホストチームだけでなく、組織にも大きなメリットがあります。ここでは、それぞれの立場で、どのようなメリットがあるかについて、その理由と共に説明しましょう。
ゲストチームのメリット
ゲストチームのメリットとしては、次の2つがあります。
- 必要な機能を必要な時に「共通性が高い状態」で手に入れることができる
- 長期メンテナンスの負担をしないで済む
コントリビューションする機能は、ゲストチームとしては緊急性の高いものです。しかし、これを独自実装した場合、ホストチーム側で行われる実装と重複する機能が実装されることになるだけでなく、ホストチームが本来提供すべき共通性も失われてしまいます。
インナーソースを用いた場合、ゲストチームの実装する機能がホストチームに受け入れられれば、レビューにより品質改善した状態で、共通性の高い公式な機能として入手することが可能となります。
また、コードはホストチームが管理するものとなります。機能追加時の実装に関する質問への回答を求められることもありますが、コードに対する最終的な責任はレビューを行ったうえで受け入れたホストチームにあるため、ゲストチームが長期的なコードのメンテナンスを行う必要はなくなります。
ホストチームのメリット
ホストチームのメリットとしては、次の3つがあります。
- ホストチームとして必要なものを受け取ることができる
- 全ての利用者との間で優先順位を調整することができる
- ホストチームの枠を越えて開発がスケールし、開発スピードと品質が向上する
最初のメリットは、受け入れ可否の判断をホストチームが行うことができるということです。ゲストチームからのコントリビューションを受ける機能は、ホストチームが必要と判断し、実装を予定していたものです。インナーソースを用いると、こうしたニーズが確定したコントリビューションを受け取ることができるだけでなく、受け入れの際にホストチームがレビューを行うことで、ホストチームの品質基準を満たしたものを受け取ることができます。
2つ目のメリットの、優先順位の調整については、インナーソースの「開発の状態の見える化」で可能になります。ホストチームとして優先度を落とさざるを得ない状況であっても、ゲストチームにとって緊急性が高いものだということが把握できれば、ゲストチームによるコントリビューションという手段を取ることができます。これにより、ホストチームは作業優先度を変更せずに、ゲストチームの優先度が高い問題を解決することが可能になります。
最後のメリットは、エンジニアリングリソースがスケーラブルになることです。例えば、ホストチームのエンジニアリングリソースが固定されている状況で、ゲストチームから要求があると、一時的に開発スケジュールの加速が求めらます。しかし、インナーソースでは、ゲストチームからのコントリビューションという形で、ホストチームのエンジニアリングリソースを一時的にスケールすることが可能となります。
なおこうした状況では、別の時点では逆の立場になる可能性もあることから、与えることから始まる「Give&Given」の関係が成り立つように意識することが求められます。そして、Give&Givenの関係が成り立った時、InnerSouceの効果は最大化され、エンジニアリングリソースの柔軟な投入による開発スピードの向上や、異なる視点からのレビューによる品質向上といった形で現れます。
組織のメリット
インナーソースを用いて、異なるチームが連携するという働き方は、企業の成長にも影響します。例えば、トラステッドコミッターとコントリビューターが連携し、レビューを通してコントリビューターが学ぶ機会を得ることは、人材教育の点からも大きなメリットとなります。こうしたやり取りにおいて、それぞれの立場でポジティブフィードバックが得られる雰囲気が作られると、自チーム以外からも認められることになり、仕事全体に対する満足度も高くなります。
また、異なるチームの作業を知ることで、スキルが向上するだけでなく、より大きな組織としての一体感を形成することにも繋がります。そして、最終的には組織のサイロがなくなり、企業全体からアイデアが生まれ、融合し、新しい価値を創造することにも繋がります。
インナーソースのメリット享受するために必要なこと
インナーソースを行う時に必要なことは、次の4点です。
- 誰でもコントリビューションできるオープンな状態であること
- 透明性が確保されていること
- コントリビューターに対するサポートを優先すること
- 共通の課題解決に向けて活動すること
「オープンな状態であること」というのは、コントリビューターの判断で参加できる状態になっていることを指します。
あるインナーソースプロジェクトへの参加を判断するためには、そのプロジェクトを発見し、ホストとなっているチームがコントリビューションを受け入れているものかを確認する必要があります。そのためには、例えばプロジェクトのトップディレクトリに置かれるREADME.mdファイルなどに、プロジェクトの説明、コントリビューションを受け入れている旨、連絡先などを明記する必要があります。
インナーソースプロジェクトの成功は、プロジェクトがどれだけオープンな状態であるかに依存するとも言われています。なぜなら、インナーソースプロジェクトに貢献するための障壁は、そのプロジェクトがオープンであるほど低くなるからです。
2番目の「透明性が確保されている」とは、プロジェクトに関連する情報が誰からも分かるようになっていることを指します。この情報には、例えば次のようなものが含まれます。
- プロジェクトやリポジトリの方向性
- 開発の進捗
- 未解決の問題
- 意思決定の過程と決定事項
こうした情報に加えて、プロジェクト内で持つ内部情報も可能な限り見えるようにすることをお勧めします。
3番目の「コントリビューターに対するサポートを優先すること」とは、コントリビューターに対するホストチームからのサポートを適切な形で行うことを指します。こうしたサポートは、主にホストチームのトラステッドコミッターにより行われることになりますが、これをどのように行うかがインナーソースを進めるうえでとても重要な要素となります。
具体的には、コントリビューターが必要とするタイミングで、コードを書く代わりに指導やコメントを提供し、コントリビューター自身の力でコードをコントリビューション可能になるよう手助けすることが求められます。このサポートが上手く機能するとコントリビューターはポジティブな体験と共に成長でき、将来のコントリビューションにも繋がります。また、ポジティブな体験が繰り返されることは、コントリビューター個人の成長にとどまらず、関係する周囲の人にも良い印象を与えるため、長期的にはホストチームとゲストチームの両者に良い影響をもたらします。
「共通の課題解決に向けて活動すること」で特に重要なのは、「共通の課題」の部分です。ゲストチームやホストチームのメンバーは、それぞれの必要性に基づいてインナーソースに参加します。ゲストチームはゲストチームが必要とするものをコントリビューションし、ホストチームもホストチームが必要とするコントリビューションを受け入れるのです。つまり、コントリビューションの内容について、両者の必要性に関する認識が一致していないと、議論が平行線をたどり意味のないものになってしまいます。
「共通の課題」があれば、ゲストチームとホストチームの両者に価値のあるものだということが明らかなため、協力して解決するために動くことが可能となります。そのためには、共通の課題の発見に至るまでのコミュニケーション、課題解決の際のコラボレーション、そしてこれらの活動を行いやすくするための場の提供が重要です。
まとめ
今回は、連載開始にあたり、インナーソースの概要とメリットを中心に紹介させていただきました。
今後は、インナーソースに関わるそれぞれの役割の詳細と、InnerSouceを企業内で実践する際のポイントついて説明させていただきます。次回は、インナーソースのコントリビューションの中心的な役割を担うコントリビューターについて説明させていただく予定です。お楽しみに。