ニフティ株式会社でエンジニアリングマネージャーをしています芦川です。
今回は、インナーソースを日本に広めるべく、InnerSource Commons Japanの運営メンバーとしての立場からも意見を書いてみたいと思います。
ニフティではここ数年間、社内にインナーソースを導入するための活動を行ってきました。
導入のきっかけや詳しい活動内容については、以下をご参照ください。
導入後、学習を続けていく中で、社内でインナーソースが広まりやすい部分と、広まりにくい部分が見えてきたように感じます。実際の社内の結果や、今後に期待できる点も含めて書いてみたいと思いました。
ここからの話は、あくまで「こういうパターンだとインナーソースは広まりやすい」という話になります。本来、インナーソースでは社内で自由にコントリビュートできる環境を目指しています。パターンにあてはまらなくても当然個人のスキルアップやエンジニア体験の向上が期待できます。そのため、「これ以外のパターンはやらない方がいい」という制限を意図しているわけではありませんのでご注意を！
では、インナーソースが効果的に導入できるパターンについて、モデル図を作成しましたのでご紹介いたします。
効果的な導入1️⃣ みんなで便利ツールにコントリビュートしよう！
これはご想像の通りだと思いますが、出退勤や日報（弊社には日報文化があります）、コミュニケーションツールなど、業務に直接関わらないツールについて、エンジニアが自ら作成しやすく、また、作成したツールを社内に広めやすい環境があります。このようなツールに対してインナーソースは非常に効果的です。まさにOSSのように、コントリビュートが生まれやすい環境と言えるでしょう。
効果的な導入2️⃣ プラットフォームチームのリポジトリにコントリビュートしよう！
ここからは、チームトポロジーのチームタイプに基づいた例になります。
もう少し業務的な例として、プラットフォームチームのリポジトリへのコントリビュートが挙げられます。プラットフォームチームは、広範な部署からの依頼を受けることが多く、全社にわたる影響を持つこともあります。
ニフティでは、リポジトリ内での定義追加などをプルリクエストとして他チームから受けることで、依頼のワークフローが簡略化され、リードタイムが短縮されました。新機能のエンハンスや新しいAPI I/Fの提案などもっといきたいところはありますが、まだそこは道半ばではあります。
なぜプラットフォームチームだけがそうなのか、と考えた理由ですが、上の便利ツールと同じくメリットを享受できる人が、つまり利用者が単純に多くなるからです。
そもそもコントリビュートは、コントリビュートしたいモチベーション、つまり利用者自身へのメリットがあることが前提になります。
例えば、特定のストリームアラインドチームの持つリポジトリへ、プラットフォームチームのメンバーがコントリビュートするのか？そこでの業務的なメリットはなんだろうか？そのモチベーションは果たしてなんでしょうか？と考えていくと、4つのチームタイプの中ではプラットフォームへのコントリビュートが広まりやすいのでは？という話になります。
（コンプリケイテッドなシステムについて、スキルアップを目指してコントリビュートする例も、組織的な観点から見ると、おそらくその会社にとって重要な意味をもつシステムであるはずなので、そのシステムを知る人間が増えるということは会社にとってすごく大事なところです。もっと将来ではそういうところも目指していきたいです。）
効果的な導入3：ドメイン知識が似てビジネスの方向性が同じストリームアラインドチームのコラボレーション
ここからは、弊社でまだ実践例が少ないものの、期待が大きいパターンになります。
コントリビュートのモチベーションが広まりやすさに大きく関係すると考えていますが、その意味では、ドメイン知識が似てビジネスの方向性が同じストリームアラインドチーム同士では、お互いにメリットが生まれることが多いと思います。
例えば、あるチームが作成したAPIを、別のストリームアラインドチームが共通のものとして利用するケースです。弊社では、郵便番号から住所を引くAPIや共通のID登録を行うAPIなどがこれに該当します。こうしたコラボレーションでは、プルリクエストを柔軟に行うことでリードタイムが短縮され、他のチームにもメリットが生まれます。
逆に、ドメインが全く異なるストリームアラインドチーム同士のコラボレーションは、両者にメリットが少なく、認知負荷の増大にもつながるため、あまり広がりそうにないのかな、と思っています。
効果的な導入4：ドキュメントへのコントリビュートを全社的に推進しよう！
最後に、広がりが期待できるのがドキュメントへのコントリビュートです。
最近発表された「State of InnerSource Report 2024」でも言及されていますが、企業がインナーソースを導入する際に、ドキュメント管理は比較的ハードルが低いとされています。
documentation-as-codeが一般的な初期のInnerSourceプロジェクトタイプとして登場していること。この傾向は、組織がInnerSourceの取り組みを始める際に、実践的でハードルの低い入り口を見つけていることを示唆している。
State of InnerSource Report 2024, P2
ただし、ニフティの場合、すべての開発ドキュメントがgitで管理されているわけではなく、主にNotionに保存されています。また、全社の人事・総務なども含めたドキュメントを対象とする場合、GitHubアカウントがエンジニアにしか配布されていないことが課題となっています。
しかし！コードとして管理されているドキュメントに限らず、「コントリビュートして互いに助け合い、良いドキュメントを作る」ことを目的とするならば、Notionのサジェスト機能を活用できるのではないかと考えています。
サジェストモードでNotionページを編集すると、ページの持ち主に対して編集の提案ができ、承認されると反映されます。これは、ゆるいプルリクエストのようなもので、社内でのインナーソース活動と同義です。エンジニアに限らず誰でも使える機能であり、インナーソースの認知を広げる起爆剤としても活用できるのではないでしょうか。
私と同じくInnerSource Commons Japanの運営メンバーである @bory_kb さんもソースコードに限定したInnerSource を狭義の InnerSource、ソースコード以外の組織資産も含めた InnerSource を広義の InnerSourceと定義し、いろいろな協働モデルについての考察を書かれています。これはとても興味深い！
InnerSource の定義を見つめ直す ~ 広義のInnerSource と 狭義のInnerSource ~
以上、ニフティでもインナーソースはまだまだ促進中で、未来は明るく、これからもやれることがたくさんあると感じています。今後も導入事例や展望を発信していきます！
