インナーソースをはじめてみよう！共通課題解決にむけた革新的な取組み

## **1\. インナーソース(InnerSource)とは？**

インナーソースとは、オープンソース開発の考え方を企業や組織内に適用する取り組みです。情報やコードを部門間で透明性を持って共有し、共創を促進することで、効率的な開発が可能となるだけでなく、開発者の成長にもつながる活動となります。インナーソースの魅力として、以下の点が挙げられます。

* **部門間の壁を取り払う**  
  技術やリソースが部門内に閉じている状況を解消し、組織全体の効率を高めます。  
* **アイデアの循環**  
  他部門からのフィードバックや多様な視点を取り入れることで、より高品質な成果物を作ることができます。  
* **持続可能な成長**  
  個人や部門に依存せず、透明性と共創の文化を根付かせることで、長期的に維持可能な仕組みを構築することができます。  
* **開発者体験の向上**  
  ポジティブなフィードバックが繰り返されると、関わる人の仕事への満足度を高めることができます。

つまり、インナーソースは単なる手法ではなく、組織全体をより強く、柔軟にする文化改革の一環とも言えるものです。このインナーソース、良い点に着目すると「やらない理由はない」ものに思えますが、うまくやらないと失敗する事もあります。インナーソースを始めて効果を得るには、どのようなケースに向いているか、またどのようなことをしないほうが良いか、本記事で体験談も交えて掘り下げてみましょう。

## **2\. インナーソースやってみた：私の体験談**

### **体験談1: 知らないうちにインナーソース**

以前、社内でLinux®を活用するプロジェクトを進めていたときのことです。Linuxはオープンソースソフトウェアですので、社外でさまざまな人がコラボレーションして開発しているものですが、社内でも同じソースコードを複数の部門で使う可能性があると考え、「せっかくなら誰でもアクセスできる形にしておこう」と社内で共通で活用可能な形でコードを共有し、それを用いて活用を進めるようにしました。活用にあたり、単に利用可能とするだけでなく、利用したコードに対する技術サポートも行っていました。

最初は技術サポートするだけでしたが、そうやってオープンに活用を進めていると、他部門でも自らそのコードを活用したいという声が聞こえるようになりました。さらに、使った人たちから「この部分でバグを見つけて、こうすれば修正できます」とフィードバックが返ってきて、コードが進化しました。

そのコードはオープンソースとして外部にも公開され、社外からのフィードバックも得られるようになりました。当時はインナーソースという言葉を知らなかったのですが、振り返ると、この取り組みはインナーソースの概念そのものでした。

### **体験談2: オープンドキュメントを実践してみた**

インナーソースを意識するようになってから、部門横断的な活動を進めるために「技術活動カタログ化」と「技術中計策定のオープン化」に挑戦しました。

技術活動カタログ化は、部門ごとに複数ある技術活動内容をMarkdown形式でドキュメント化し、共通リポジトリにまとめて紹介できる形にしてみました。技術中計策定オープン化は、作成した資料はPowerPointでしたが、検討過程がわかるように社内の誰からも見られる場所に置き、チャットで議論可能な形にしました。

結果として、他部門の人から「この情報が参考になった」「ここを改善するともっと良くなる」「このリンクが切れているから更新したほうが良い」「この技術はこうした方が良いのではないか」などの声が届きました。フィードバックを受けながらドキュメントを改良するというコラボレーションが生まれました。筆者の所属部門のミッションの一つに「全社共通のソフトウェア技術を提供することでソフトウェア開発力を強化する」ことがあるため、多くの方に興味を持っていただけたのかもしれません。

### **体験を通じて感じたこと**

インナーソースは「特別な技術」ではありません。大切なのは「自分たちが作ったものをオープンにして、他の人の役に立つようにする。フィードバックを歓迎する。」という意識です。インナーソースの「やり方」を意識したことで、業務プロセスに新しい可能性を見出し、効率化とコラボレーションの向上を実感することができます。

## **3\. インナーソースの課題：うまくいかなかったケース**

インナーソースの失敗から学ぶこともあります。以下に、うまくいかなかったケースを２つ紹介します。

### **ケース1: 不要なコードをオープン化**

使わなくなった古いソースコードを「もしかしたら誰か使うかもしれない」と思い、オープン化したことがあります。しかし、実際には利用者が現れず、価値を生まない取り組みになってしまいました。この経験から学んだのは、インナーソースで公開するものには「他の人にも有用だと（ある程度）確信できる」という前提が必要だということです。  
なお、確信の程度によっては失敗することもありますが、その時はその時という割り切りも重要かもしれませんね。私個人としては、うまくいかないとしてもオープンに活動することには意味があると感じています。

### **ケース2: 問い合わせ先が不明瞭**

公開した成果物について、「誰にどこで質問すればいいのか分からない」という事態が発生したことがあります。問い合わせ先を探すまでに時間がかかるだけでなく、そうした手間に嫌気がして利用者が離れてしまい、取り組みが広がるチャンスを逃してしまいました。問い合わせ先や責任者を明確にしておくことで、利用者との信頼関係を築き、フィードバックを受け取る流れを作ることが重要です。

## **4\. インナーソースを成功に導く秘訣とは？**

### インナーソースを成功に導く秘訣、それは「共通の課題」と「わかる、つかえる、つながれる」に集約されるのではないかと感じています。

### **共通の課題を見つける**

インナーソースを成功に導くには、部門横断的な課題を見つけることが重要です。つまり、仲間集めですね。

* **共通〇〇という言葉に注目**  
  「共通プラットフォーム」「共通ツール」「共通仕様」など、部門間で横断的に使われるものを見逃さないことがポイントです。もし既に着手している「共通〇〇」があれば、是非インナーソースで実践してみてください。  
* **困りごとをシェアする視点**  
  「これ、他の人も困っているかもしれない」と思ったら、それはインナーソースを始める絶好のチャンスです。  
* **共有ドキュメントの作成**  
  部門間で共有されるドキュメントは、共通課題が凝縮されている場合が多く、インナーソースの対象として適してるかもしれません。社内規定のような影響範囲の大きなドキュメントで作成中のものを誤用される、業務に支障が出そうな場合でも、その旨を明示することで誤用を抑えつつ早期のフィードバックを得ることができるかもしれません。

### **インナーソースの成果物を広める**

インナーソースの成功には、「インナーソースで何（成果）を目指すか」を広めることが大切だと感じています。

* **やるコトの価値を明確にする（わかる）**  
  やるコトとその成果が解決できる課題やメリットを明確に伝えましょう。これから始める活動では成果の想定活用シーンを明示することが大切ですし、既に成果があるものは成功事例を具体的に紹介することで、利用者を増やすことができます。  
* **使いやすさを重視する（つかえる）**  
  わかりやすいドキュメントや導入ガイドを用意して、利用のハードルを下げましょう。  
* **連絡先を明示する（つながれる）**  
  問い合わせ先や窓口を明示することは、とても大切です。うまくいかなかったケース2に書きましたが、連絡できないストレスにより利用者が離れてしまいます。それを避けるためにも、他の利用者とも簡単につながれるコミュニティを作ることも有効です。

上に挙げた3点はどれも「紹介する」に集約されるかもしれません。（顔が見えるように自分のことを含めて）活動を広く伝えて理解してもらい利用につなげることでフィードバックを得るという循環を発生させることができます。

### **透明性のある活動とそれを支える文化作り**

インナーソースしてみたい人が周りにいそうな時、インナーソース自体を広めるには、その活動を支える文化と仕組み作りが大切です。

* **活動プロセスの可視化**  
  インナーソースの取り組みがどのように進められ、成果物が作られたのかを公開することで、他部門の参考になります。  
* **部門間の協力を奨励する制度**  
  インナーソースの取り組みの始め方が明確化されて、成果物が活用されることや貢献することが評価される仕組みを整えることで、モチベーションが向上します。

## **5\. まとめ**

インナーソースは、部門横断的な課題を解決し、組織全体の効率とコラボレーションを高める革新的な手法です。成功のカギは共通の課題を見つけたらインナーソースのやり方を実践し、その成果を広めて利用してもらうことにあります。一人ひとりが課題を共有しながらオープンに活動することを実践した結果として、「インナーソースという言葉に集約されるやり方が広がった」ということになれば、組織や個人として大きく成長できるでしょう。

私自身、インナーソース実践や手法を広める活動は道半ばです。しかし、少しづつでも継続して取り組むことで、会社だけでなく日本の中にもいつか大きな変化を起こすことができると確信しています。

皆さんも、自分の業務を振り返ってみてください。もしかすると、すでにインナーソース的な取り組みを始めているかもしれません。そして、それをさらに価値あるものにするために、次の一歩を踏み出してみてはいかがでしょうか？

## **6\. インナーソースを始め方**

インナーソースをやってみようと思った時に、頼れるコミュニティーや参考文献についてまとめてみました。

### コミュニティ
* [InnerSource Commons Slack](https://app.slack.com/client/T04PXKRM0/C03M546NR16)：日本語チャネルもあります
* [Connpass内のInnerSource Commonsコミュニティ](https://innersourcecommons.connpass.com/)：インナーソース関連のイベントを開催しています

### 参考記事
* [実践インナーソース入門](https://codezine.jp/article/detail/14809)：インナーソースの入門記事です
* [インナーソース入門](https://innersourcecommons.org/ja/learn/books/getting-started-with-innersource/)：インナーソース入門書です
* [インナーソース パターンブック](https://innersourcecommons.org/ja/learn/books/innersource-patterns/)： インナーソースのベストプラクティスが揃っています

## 商標について

* Linuxは、Linus Torvalds 氏の米国およびその他の国における登録商標です