インナーソースを理解してみる
はじめに
本プログは、筆者なりにインナーソース(InnerSource)を理解して、まとめたものになります。インナーソースを知ったばかりで、理解が異なる箇所もあるので、ご容赦ください。
インナーソースを知ろうと思ったきっかけ
インナーソース活動を始めて、車輪の再発明を防ぐことができないかと思って、調べ始めた。筆者はプラットフォームを提供する側だが、開発者にプラットフォームの普及や学習の提供などしてきた。新しい機能や機能改善したパイプラインのソースコードを周知することが一番効率悪く感じ、なんとか改善できないかと調べていた時に、インナーソースの存在を知った。
インナーソース
インナーソースとは
InnerSource Commonsによると、
InnerSourceは、企業内のソフトウェア開発にオープンソースの実践と原則を適用したものです [1]
と定義している。つまり、世の中にあふれているOSSの活動で得た実践方法や原則を一般的な企業の組織内に適用してセルフサービス化を図ろうとするベストプラクティスと解釈している。
[1] はじめに
インナーソースの成果
インナーソースによる成果は、開発者体験と生産性の向上と思われる。
インナーソースの利点として、以下が挙げられている。
- 組織横断的なコードの再利用が飛躍的に進みます。各チームのプログラマーは、他のチームによって開発されたモジュールのコードとアーキテクチャを理解し、コードをコントリビュートできます。
- このようなチーム間のコラボレーションが、比較的摩擦の少ないものになります。受け取ったチームがコントリビュートされたコードを書き直すことはほとんどなくなり、上層部における議論も必要なくなります。
- プログラマーはユニットテスト、コードカバレッジ、継続的インテグレーションを使い、開発の初期段階でバグを取り除くことを学ぶことができるため、開発はより速くなります。チームメンバー間で交わされるコメントのやり取りには時間がかかりますが、新しいプログラマーがシステムについて早く学ぶことができるようになるため、それ以上の効果があります。
- プログラマーは自分のコードをより良くドキュメント化することを学ぶようになり、それは公式なドキュメント(コード内のコメントやドキュメント)や、非公式なドキュメント(ディスカッションリスト) に対しても効果があります。ドキュメントはプロジェクトの履歴を提供して外部の人間が理解する助けとなるため、より多くの人がプロジェクトへコントリビュートできるようになります。 [2]
[2] チーム間コラボレーションへの強力なアプローチ - InnerSource Commons 日本語コンテンツ
インナーソースへの取り組み
インナーソースへの取り組むについて、InnerSource Coomonsより日本語のパターンブックが公開されているので、以下を参照してください。
patterns.innersourcecommons.org
最後に
パターンブックで気になった点を1つだけ感想を述べたい。「正式なコミュニティリーダ」[3]について、いくつかの条件を達成した優秀なリーダを選択する必要がある。そのうちの経営陣と開発者に強いネットワークを確立できることは、なかなか厳しい条件になるのではないかと思う。最初は小さく初めて、インナーソースの効果が出始めたときに、上層部に社内活動としてアピールして認知してもらうなど一工夫が必要だなと思った。
