デブサミ2021 参加レポート「18-E-2 オープンソースのベストプラクティスを企業内で実践 ～インナーソースのすすめ」

Developers Summit 2021

この記事は、2021/02/18-19に開催されたDevelopers Summit 2021のレポートです。

チーム参加してきました

aslead Agile のチーム「オキザリス」にて参加してきました。
チーム5人中、4人で参加して、その場で実況しつつ、記事も作っています。

# 登壇者

服部 佑樹さん[日本マイクロソフト]
田中 裕一さん[ギットハブ・ジャパン]

Microsoftのサイロを壊せ

Microsoftでは、チームインナーソースの適用等を中心になって進めている1ESという組織が中心になり、Githubを使ってInnerSourceを実現。

InnerSource を実現するポイント

• 発見可能性
  共有しても見つけられないと意味がないため、見つけられるようになっていることが重要
• 実行可能性
  README.md を用意しておくなど、ソースコードを迅速かつ簡単にコンパイル及び実行できる、または別プロジェクトの一部として簡単に使用できるようになっていることが重要
• 貢献性
  社内の魅力的なプロジェクトを共有
• 継続性
  全てのチームがコードをメンテナンスし続けること

#Microsoft の InnerSourceプラクティス
最終的な目標は、「文化的な変化」。
人の働き方を決めたり、新しい統制プロセスとして追加してしまうと合わない。

InnerSourceフレームワーク

各企業でワークフレームを作って社内で共有することが重要

1.発見
PMが要件の検証を行い、InnerSourceのための機能の優先順位を決定

2.デザイン
PMは必要に応じて更なる顧客検証を実施

3.開発
開発者は、開発チームの延長線上で働く

4.デプロイ
PMが機能を有効にする前にコミュニティに新機能のリリースを送信する

5.メンテナンス
サポートを実施

#Microsoftが収集するCustomer Metrics
Contributerが複数いるリポジトリ等を集計

OKR例

• Object
  コードオーナが、自分たちのソフトウェアがどのように使われているかを理解し、コントリビューターを募集する方法を理解している
• Key Result
  • InnerSourceの貢献パイプラインのメトリクスを定義し、消費しやすい方法で提供する（使用状況、インタラクション、及び貢献の追跡）
  • InnerSourceの貢献パイプラインMVPが、関連する２つのチームで採用されていること
• Action Item
  • チームが使用できるInnerSourceモデルとダッシュボードMVPの開発
  • モデルとダッシュボードを公開
  • ファネルを改善するためのアクション指向のガイダンスとワークフローを開発し、提供します。

#ここまでのまとめ

• InnerSouceは文化変革の旅
• 発見可能性・実行可能性・貢献性・継続性が重要
• Fun！社内統制や標準化の一貫としないこと

Githubを使ってどのようにインナーソースを実践するか

疑問1 : どのプロジェクトをインナーソース化するか？

いきなりみんなお互いコントリビュートしあいましょう！といっても広まらない。
コントリビューターになるまでの流れとしては、まずユーザとして使っているプロジェクトがあって、その際にバグを発見したり、新機能が必要になった場合にコントリビュータになる場合が多い。
よって、既存のプロジェクトで社内で広く使われている・使われるものをインナーソース化すると良い。

• プラットフォーム、ライブラリ、フレームワーク、SDKなど
• ビルド、CI基盤などの開発ツール
• 全社的なFAQ
• 社内規約等のドキュメント

※実際にGithubの社内でもドキュメントをインナーソースとして管理している。

##疑問２ : プロジェクトをどう見つけてもらうか？
最低限、社内メンバーがリポジトリにアクセスできる必要がある。
GithubのInternalリポジトリを活用すると良い。Enterprise内全体からReadできる。

また、よくあるプラクティスとしては、InnerSourceプロジェクトの一覧を表示するポータルを作成すること。Private Github Pages ＋ Github Actionsで、Githubだけで社内限定のインナーソースポータルサイトを構築することも可能。

##疑問３ : どうやってコントリビュートしてもらうか？
初めてコントリビュートする人の不安を取り除くことが大事。

• どういうコントリビュートが受け入れられるのか？
• どういう流れでコントリビュートすれば良いのか？
• わからないことがあれば誰に聞けば良いのか？
• 何を満たせば良いのか？

ベストプラクティス

• README.md を用意する
  チーム外からのコントリビュートを歓迎していることを書く。また、どういう種類のコントリビュートを受け付けているのか、コントリビュートの具体的な手順を明記する。
• CONTRIBUTING.md を用意する
  詳細なことはこのページに記載する。初めてコントリビュートする人に対しては、README以外にこのページへのリンクが表示されるようになる。バグ報告の仕方、プルリクの作成方法などを記載しておく。
• イシュー・プルリクのテンプレートを作成しておく
• CODEOWNERS
  ファイルの種類やパスごとにレビューアーを指定しておく
• マージされる条件の明確化
• REPO LINTER
  レポジトリの中身をチェックしてくれるリンター。READMEがあるかなど設定ファイルで設定可能。

##疑問４ : 上手くいっているかをどう測る？

• grimoirelab
• hubble
  オーガニゼーションをまたいでコントリビューションしてくれているか可視化するツール

まとめ

• ツールは文化をかえる触媒
• インナーソースは文化
• 文化を変えるのはとても大変でも、ツール導入で人の行動が変わる
• 行動の変化が文化が変わるきっかけとなる

#感想
日頃、社内のソースが社内で共有されていればいいなと思いつつ、ハードルが高そうだと感じていましたが、ソースだけではなくドキュメントから始めることもできるということが勉強になりました。
また、さまざまなツールが世の中にあるということで、いろいろ活用してみたいなと感じました。