インナーソースで文化を変えるMicrosoftの挑戦
前半は服部氏が登壇し、Microsoft内におけるインナーソースの活動について言及した。「InnerSource Commonsの定義によると、インナーソースとは、オープンソースのコンセプトと学びを、企業が社内でソフトウェア開発に適用する試みだ。その目的は開発効率を上げ、より良い顧客満足度と成果につなげること。社内のシェアリングエコノミーの実現に向けて、文化的に変革していく旅である」。
Microsoftがこの終わりのない旅に踏み出した理由は、巨大化する組織によって生じていた弊害——官僚制組織化による柔軟性の低下、部門間の競争激化や社内政治の蔓延によるコラボレーションの低下、またコンウェイの法則により結果的にモノリシックになってしまったソースコード——を除去するためだった。
サティア・ナデラ CEOが大きな期待を寄せるMicrosoftの開発基盤チームである1ES（Microsoft One Engineering System）チームは、インナーソースの適用をはじめ、GitHubの推進や社内Stack Overflowの整備などを担い、最善のツールとプラクティスを社内のすべてのエンジニアに提供して支援するために存在している。これにより、サイロ化した組織を崩し、社内コラボレーションを促進し、エンジニアの満足度向上を図っているのだ。
次に服部氏は、インナーソースを実現するために重要な4つのポイントを挙げた。
発見可能性
単にソースコードを共有するだけではダメ。他のチームメンバーが、コードベース、ドキュメント、およびその他関連資料のすべてを検索してプロジェクトを探索できる状態にしておかなければならない。
実行可能性
コラボレーションを促進するには、使ってもらえなければ意味がない。他のチームメンバーが、ドキュメンテーションからプロジェクトの活用方法が分かり、迅速かつ簡単に実行できることが大切。
貢献性
インナーソースの活動に貢献することは、社内に対するセールス活動にもなる。強いエンジニアが魅力的なプロジェクトを見つけ、自らの貢献度をアピールしやすいよう、簡単に問題を報告したり、新しい機能を提案したりできる環境を整え、参加の障壁を低くしておくこと。
継続性
プロジェクトをホストするチームがコードをメンテナンスし続け、イシューに対する対応などを含め、社内ユーザーをサポートし続ける必要がある。
「インナーソースは統制プロセスや、社内システム・プラクティス標準化活動の一部になってはいけない。またソースコードのキュレーション活動でもない。インナーソースの最終的な目標は文化的な変化。そのため、オープンソースにコミットする人たちの行動原理と同様に、インナーソースも『コラボレーション』や『コントリビューション』ベースになるよう、我々も気をつけながら取り組みを進めている。」（服部氏）
ここからはMicrosoftがどのようにインナーソースに取り組んでいるのかを見ていこう。同社では、以下のフレームワークを用いている。
「インナーソースの活動は、ただのボランティアではない」と服部氏は強調する。エンジニアが「自らのプレゼンスを示す」などのモチベーションを持ち、担当するプロダクトを開発する中で、プラスαの要素として取り組んでいるのだ。だからと言って、片手間で取り組んでいるわけではない。社内でユーザーインタビューを重ねるなど、顧客向けのプロダクトと同様のモチベーションを持っているという。
そのため、インナーソースを有効化するための手段や環境を提供する「プログラムオフィス」があるほか、メトリクスを取って社内のコラボレーションの状況を可視化したり、OKRsを設定したりするなど、インナーソースをドライブさせるための仕掛けを複数用意しているのが特徴だ。
「最終的には楽しいことが何よりも重要。社内統制や標準化の観点で進めてしまうとインナーソースはドライブされないので、『投資』として行うべきだ」（服部氏）
GitHubを活用してインナーソースを始めよう
続いて後半は田中氏により、GitHubを活用したインナーソースの実践方法について紹介された。インナーソースを始めようと考えたときに浮かび上がる4つの疑問に応える形で話を進めていく。
1. どのプロジェクトをインナーソース化するか？
いきなり全リポジトリを対象に「お互いコントリビュートし合いましょう！」と言っても、そう簡単にはうまくはいかない。多くのエンジニアにとって、自分がやるべきことは担当しているプロジェクトのコードを書くことであるという認識があるからだ。
オープンソースの世界でも、自分が使ったこともないものにコントリビュートすることはないはず。自分がユーザーとして使っているうちに、バグを見つけたり、機能要望が生まれたりして、コードが見えているから自分で実装してみるという流れでコントリビューターになっていく。
この発想を転換すれば、どのプロジェクトをインナーソース化すれば良いかはおのずと見えてくる。「プラットフォーム、ライブラリ、SDKなど」「ビルド、CI基盤等の開発ツール」「全社的なFAQ」「社内規約等のドキュメント」といった“社内の既存プロジェクトで広く使われているもの”を取り上げるべきだ。
2. プロジェクトをどう見つけてもらうか？
次に、インナーソースに取り組んでいるプロジェクトを見つけてもらいやすくする必要がある。発見できる環境を作るのだ。
最低限やるべきこととして、社内の全開発者に対してリポジトリのアクセス権を付与する必要がある。その際、GitHub Enterpriseの「Internalリポジトリ」の機能を使えば、社内のメンバーなら誰でも見られるリポジトリを簡単に作ることができる。
さらに、インナーソース プロジェクトを一覧化したポータルサイトを社内向けに作るというのも、よくある手だ。GitHubのAPIでインナーソース対象のリポジトリの情報を取得して表示することで、それぞれの活動状況が一目でわかるようになる。「Project Portal for InnerSource」や「enterprise-showcase」といったOSSとして開発されているポータルサイト実装を利用することで、GitHub Pagesでポータルサイトをホストできるようになる。これらのツールでは表示するリポジトリの情報はJSONファイとして指定するようになっており、更新はActionsで定期的に更新すれば良い。
今年1月にリリースされた「Private GitHub Pages」と「Internalリポジトリ」を使えば、社内ポータルサイトをホストする環境がない企業でも、GitHubだけでインナーソース ポータルサイトを手軽に構築することが可能だ。（GitHubが構築した社内向けポータルサイトのサンプルコードはこちら）
3. どうやってコントリビュートしてもらうか？
各社の文化的な話はさておき、一般的にコントリビューターを増やすには、初めてコントリビュートする人の不安を取り除くことが大切だ。そのために「README.md」と「CONTRIBUTING.md」をきちんと用意しておく必要がある。
まず「README.md」には、「チーム外からのコントリビュートを歓迎していること」「どんな種類のコントリビュートを受け付けているのか」「コントリビュートの具体的な手順」を概要として記載する。そして「CONTRIBUTING.md」には、「バグの報告の仕方」「機能要望の報告の仕方」「プルリクエストの作り方」「プルリクエストのマージ条件」「レビュープロセス」など、より詳細な事項を記載しておく。
あわせて、登録するイシューやプルリクエストの種類ごとに必要な情報の項目をテンプレートにしておくことや、「CODEOWNERS」という機能を使ってファイルの種類やパスごとにレビュー担当者を自動設定しておくこと、マージされる条件を明確にしておくことも大切だ。その際、リポジトリの基準をそろえるために「REPO LINTER」のようなリポジトリのステータスをチェックしてくれるツールを活用するのも有効である。
4. うまくいっているかをどう測る？
インナーソースの取り組みがうまくいっているかどうかを測定するメトリクスはさまざまあるが、今回はGitHubからアクティビティの情報を取得してダッシュボード化する「Grimoire Lab」と、組織間をまたいだコントリビュートが行われているかを可視化する「hubble」の2つのオープンソースのツールが紹介された。
最後に、田中氏は「インナーソースは文化。文化を変えるのはとても大変だし、ツールの導入だけで文化は変えられない。しかし、ツールの導入をきっかけに新たな取り組みを始めることで、一部であれ人の行動変容は必ず起こる。それが文化を変えるきっかけとなれば、とても嬉しい」と語り、「みなさん楽しく社内でコントリビュートし合う文化を築いてほしい」とメッセージを残した。
