インナーソースを日本でやるとはどういうことなのか
こんにちは、InnerSource Commons Japan の久保です。 みなさんインナーソース （InnerSource）は聞いたことありますか？ 概念自体は割と古くからあるのですが、日本のコミュニティができたのは2022年の7月ごろです。 それまでは日本語のコンテンツも少なく、日本の環境における知見などもあまりありませんでした。
私はこのポストを書く時点で一年ほど社内でインナーソースを実践しようとしたり挫折したりしていますが、 そんな中で得た知見だったり課題だったりをまとめるポストにしようと思います。
改めてインナーソース（InnerSource）とは
概要だったり定義だったりはすでに素晴らしい資料があるのでリンクをぺたぺたと貼っておこうと思いますが、 簡潔にまとめると以下の通りです。
「オープンソースの世界で成功した原則を社内にも取り入れソフトウェア開発に適用する。 また、そのための文化変革や組織間のサイロを壊す。」
より概要から詳しく知りたい方は👇の資料だったり、InnerSource Commons Japan の Youtube を参照してみてください。
伝統のある日本の大企業こそインナーソースをやろう
インナーソースとは組織間のサイロ・隔たりがある企業こそがやるべき取り組みです。 従業員規模が一桁二桁のスタートアップやベンチャーであれば、そもそもサイロなんて存在しないかもしれませんし、 ソースコードはすでに全社に公開されており、誰でもプルリクエストを投げられるかもしれません。
またいわゆるメガベンチャーと呼ばれるような企業は社員数こそ多いものの組織文化として既に醸成されている部分があり、インナーソースが寄与できることはなかったり限定的であると推察されます。
しかし、（伝統ある）日本の大企業はそうはいきません。 機能的分業の結果、業務の部分最適化が進み、組織間で対立が起きていて顧客に価値を届ける活動の妨げになっていたり、 セキュリティ・コンプライアンスなどの観点から大きな情報格差があって現場が適切な判断を下せなかったりなど現代のグローバルマーケットで通用する理想の組織とは程遠いのではないでしょうか。（諸説）
ですが、これらの課題はインナーソースの実践で改善する方向に力が働く可能性が大いにあります。 グローバルマーケットに対しての日本企業の競争力に課題ある現代、インナーソースは日本の大企業こそ実践するべきだと強く考えています。
ソースコードである必要はない
インナーソースという名称や、そのルーツに迫るとソフトウェア開発への適用にフォーカスしがちですが、 私は必ずしもソフトウェア開発に限る必要はないと考えています。 社内で管理されている規定やルール、テンプレートなど様々適用が可能なはずです。
例 : 服装に関するガイドライン
例 : 会議の際に使用する議事録等のテンプレート
着目すべき点はどこかで勝手に決まっていたりするものに対してフィードバックをすることで、協働を促すことができる点です。 もちろんフィードバックの受け口であったり、議論する場（ログの残るチャットベースが望ましい）を用意する必要性はあります。 ただ、オープンソース・インナーソースは GitHub などフィードバック・議論をする場（Issues）がもともと整備されていたというだけであり、 そういった場さえ用意できればインナーソースはなんにでも適用できる大きな可能性を秘めているはずです。
GitHub などでできることの代替手段を提供するだけなので、難しく考える必要性はないと思います。（実践は一筋縄ではいかないと思いますが）
議論する場として Teams や Slack などでチャネルを用意してあげればいいでしょうし、 インナーソースの対象となりうるもの（上記で言うところのガイドラインやテンプレート）が PDF として公開されているのであれば、そのベースとなっているであろう Excel なり Word なりのファイルを共有・編集権限の付与などしてあげれば良いでしょう。（原本が壊れないようにする工夫も必要です）
もちろん実践は一筋縄でいかないことが明白なのですが、難しく考えすぎて最初の一歩が踏み出せないのはもったいないです。
インナーソースという名称により生まれる課題
新しい取り組みへの抵抗
全世界に公開するオープンソースの「オープン」に対して、会社の内部にフォーカスを向けた「インナー」という名称は非常に的を射ていると思います。
社内でインナーソースを実践する上でインナーソースとは何かを関係者に説明をする機会が必ず訪れるはずですが、 そうなると「インナーソースはオープンソースを源流に持つ」という文脈を語ることは避けられないわけです。 そのまま工夫なく話をすると「既存の開発手法・文化を脅かす新しい何か」と捉えられるでしょう。 新しい取り組みを始めようとすると避けられない問題ですが、インナーソースも例外ではありません。
常套手段かもしれませんが、新しい取り組みはスモールスタート、小さく静かに始めましょう。 ある程度、実績が出来てから大きく広げる活動を始めるのでも遅くはないはずです。
私はアジャイル開発の実践をスモールスタートで始めたのち、社内に展開し一定の理解を得られた経験があるので、インナーソースでも同様の進め方が適切だと踏んでいます。
インナー"ソース" ( Inner "Source" )
もう一つ大きな問題があります。 それはインナーソースで破壊するべき組織間のサイロは必ずしもITや開発に詳しい組織とは限らない、という点です。 多くの（特に伝統のある）日本企業における組織構造は主に機能別分業をベースに構成されているかと思います。（営業部門・システム部門・マーケティング部門など）
すなわち、インナーソースとは営業部門とシステム部門間など異なる業務をこなす組織間にあるサイロを破壊することが真なる目標だと私は理解しています。 再三言及していますが、インナーソースはソフトウェア開発をルーツに持ちます。 伝統のある日本企業は業務の部分最適化がかなり進んでいるはずなので、営業部門はITに詳しくない可能性が大いにあると思います。（少なくとも私の環境は…）
となると、インナーソースについての説明を受けても「開発部門がやることであり、私たちは関係ない」と捉えられかねません。 この認識はオープンソースに対してインナーソースという名称がつけられた背景を伝えると、より強調されるかと思います。
このことからただでさえ変化に抵抗のある組織に対して、インナーソースという名称を利用することで携わる部門をより限定的にしかねないです。 そのためインナーソースではなく「情報の透明性を持たせる取り組み」や「部門間連携」など言葉を工夫して浸透させていく必要性があるかもしません。
さいごに
今回はインナーソースの概念・価値観をどのようにして日本企業に売り込んでいくのかについてまとめました。 そのため現代の日本企業におけるソフトウェア開発環境には踏み込みませんでした。 また別のポストでソフトウェア開発環境にフォーカスしてみます。
インナーソースについては InnerSource Commons Japan というコミュニティがあります。 Connpass や InnerSource Commons のページのリンクを貼っておくので、ぜひご覧ください。
