✔記事の対象者
- インナーソースに興味がある
- インナーソースを導入してみたいと思っている
- インナーソースを実際に導入するまでにやったことを知りたい
✔記事の内容
こんにちは！会員・認証基盤システムの開発・運用をしている基幹システムグループの小松です。
社内にインナーソースの導入を進めています。
インナーソース導入活動の様子、実際にやったことなどをブログで共有していきます。
今回はその①、インナーソースを導入活動発足から、1つのリポジトリでインナーソースお試し導入をしてアンケートを取るまでの範囲を紹介します。
その②では、その後の全社展開のために活動した内容紹介予定です。
1. インナーソースとは
世界最大コミュニティ InnerSource Commonsによる、インナーソースの定義は以下です。
「組織という限られた環境において、ソフトウェア開発におけるオープンソースの原則とプラクティスを活用すること」
簡単にイメージを言うと、「企業内部限定のオープンソース活動」です。
これにより組織内の異なるチームや部門が効果的にコラボレーションし、知識やコードを共有することが可能になります。
インナーソースによるメリットは以下です。
- コード再利用による開発効率の向上
- コラボレーションの強化
- 透明性の向上
2. インナーソース導入のきっかけと目的
2.1. インナーソース導入前の状態
エンジニアが約160名。
基幹システムグループ、会員システムグループ、インフラシステムグループにわかれ、それぞれ各チーム、サブチームにわかれます。
一部協力会社に開発・保守を任せるシステムもありますが、基本的に内製による開発・保守を行っています。
担当システムの人が開発・保守を行い、他システムにも機能修正が必要な場合は、他チームのシステム担当に依頼し、修正をしてもらう形になります。
他チームからの修正依頼に追われるチームもありました。
多くのチームはGitHubを使っているのですが、気軽にグループ間でソース共有するような文化もあまりありませんでした。
2.2. きっかけ
最初のきっかけは、私の上司である芦川が管理職レイヤーで事業計画を考えている際に、他チームの開発をできるようになればもっと柔軟に開発ができるのではないかと思っていました。
せっかくなら、社内独自ルールを作るよりも一般的なOSSコントリビュート方法にならう形がいいと思い、調べているとインナーソースを知ったそうです。
私は、後述するテストプロジェクトにちょうどいい社内用ツールのリポジトリを管理していたので、そこから一緒に広めようということになりました。
2.3. 目的
ニフティでの導入の目的は、将来的にサイロ化を破壊し、開発リソースの有効活用することです。
ですが、現在のインナーソース導入期間での目的は、Developer Experienceの向上です。
Developer Experienceとは、簡単に言うと「エンジニアが気持ちよく開発・保守できる環境」を指します。
InnerSource Commons Japanの運営メンバーである服部 佑樹さんが、インナーソースを導入する目的は2種類あると言っていました。
「Developer Experience and InnerSource – エンジニアの共創は結局大企業では無理なのだろうか」の36ページから書かれています。
「Developer Exprerienceのため」と「競争戦略のため」の2種類。
競争戦略のためは主に製造業などで目的とされるそうです。
ニフティでは、まずDeveloper Exprerienceの向上を目指します。
Developer Exprerienceのために導入する場合の得られる効果を資料から引用させてもらいます。
透明でコラボティブな開発文化育成
技術や知識共有によるスキルレベル向上
従業員満足度向上と離職率の低下
車輪の再発明の防止で生産コスト削減
https://speakerdeck.com/yuhattor/developer-experience-and-innersource-ensinianogong-chuang-hajie-ju-da-qi-ye-tehawu-li-nanotarouka?slide=37
3. インナーソースお試し導入でやったこと
3.1. 情報収集
InnserSouce Commonsという世界で最も大きいコミュニティがインナーソースに関する情報や、ベストプラクティスなどを紹介しています。
InnerSource Commons Japanもあり、ドキュメントの翻訳や、connpassでのオンラインイベント開催などをしてくれています。
まずはインナーソースパターンブックというベストプラクティスをまとめたドキュメントがあるので、そちらを読みました。
導入のフェーズごとにわかれているので、まずBeginの箇所から読みました。
またInnserSouce Commonsのラーニングパスもあるので、一通り読みました。
ここは初学者にとっては少し難しいかもしれません。
ここで説明されているプロダクトオーナーは、他チームのリポジトリとコラボレーションを考えたり、テスト要件、コーディング要件までドキュメント化するなどの役割があり、エンジニアでないと難しいと思います。
ニフティではプロダクトオーナーがビジネス職の場合もあります。その場合はトラステッドコミッターに技術的な範囲の権限を委任するという形をとっています。
他にはInnerSource Commons Japanがconnpassでイベントを開催しているので、参加できるものは参加しました。
過去のイベント内容もYouTubeチャンネルにアップロードされています。
3.2. 社内のエンジニア全体会でインナーソースについて発表
月に1回エンジニア全体会を行っており、LTコーナーがあるので発表しました。
インナーソースの説明と、導入するとこんなメリットがあるというまず簡単な共有をしました。
インナーソースという言葉を初めて聞く人がほとんどだったと思いますが、以下のようなポジティブな反応が多かったです。
- 「別チームのリポジトリにプルリクだしてみたい」
- 「〇〇ツールはみんなで触れるのを理想としていた」
- 「OSSコントリビュートの練習にもなりそう」
3.3. 社内用ツールでインナーソースのテストプロジェクト
これは、エンジニアが誰でも知っていて、そこまでコントリビュートにハードルがない社内用ツールでやってみようということになりました。
ちなみ社内用ツールとは、私が作った「もじこえ」というツール。
オンライン会議で気軽なリアクションができるようにと、作った読み上げ機能つきのチャットツールです。
全社的に知られており、中身はシンプルで機能追加などもしやすいので、このリポジトリでテストプロジェクトをやることにしました。
3.3.1 テストプロジェクトをやるために準備したこと
- Slackチャンネル作成
- 社内ツール(もじこえ)専用チャンネル
- こちらで機能追加の相談などを受けます。
- インナーソース専用チャンネル
- こちらはインナーソースについての連絡や相談の場として使います。
- 社内ツール(もじこえ)専用チャンネル
- test, lint環境を整える
- 様々なチームの人がコントリビュートすることになるため、コードの品質向上、一貫性を保つためにもテスト、lintを用意しておく必要があります。
- README.mdの作成
- コントリビュートについては、CONTRIBUTING.mdを参照するように誘導しました。
- InnerSource Commonsがテンプレートを公開しています。
- CONTRIBUTING.md作成
- コントリビュートするための詳細な手順を載せます。
- コントリビュートしたいと思った人は、まずCONTRIBUTING.mdをみることになります。
- InnerSource Commonsがテンプレートを公開しています。
用意ができたら、エンジニア全員が見れる場所で連絡します。
事前に、コントリビュートしてくれそうな人、チームがあれば、直接メンションを飛ばします。
継続的に宣伝したり、参加してくれる人には手厚いサポートをしながら地道に進めていきます。
Good First Issueも何個か用意しておき、初めての人でもコントリビュートしやすい環境を用意しました。（実際にコントリビュートしてもらえました）
3.4. テストプロジェクトの評価とアンケート実施
テストプロジェクトは約2ヶ月で一区切りとして評価しました。
3.4.1. テストプロジェクトの評価
Issueにアサインしてくれた人が7名、実際にマージされたPRが3件でした。
新卒入社5年目までの若手が参加してくれました。
インナーソースを体験してみたいと、CONTRIBUTING.mdの修正をしてくれる人がいたり、機能追加のリクエストをくれる人もいました。
皆、メイン業務の合間にやることになるので、機能追加系のIssueにアサインしたものの、テストプロジェクトの間ではマージまでできませんでした。
機能追加にしても、なるべくサイズを小さくするのがよさそうです。
Good First Issueも1件マージしてもらうことができました。
やはり、インナーソースを体験してみたいという需要はありそうです。
3.4.2. アンケート
実際に参加した人だけでなく、エンジニア全体を対象としてアンケートを取りました。
なるべく、回答率を上げるため、質問数は絞って簡単に答えてもらえるようにしました。
エンジニアの約3割の方が回答してくれました。
部署ごとの割合もある程度バランス良く回答もらえました。
以下はアンケート内容と結果です。
1.インナーソースに対する理解度はどの程度ですか？
- ちょうど半分くらい、理解がある人と、ない人でわかれていました。
2.インナーソースの取り組みに関するハードルがありますか？ （複数選択可）
どんな些細なハードルでも記入していただくと助かります。
- 「時間やリソースの制約」が一番多かったです。他チームのリポジトリへのコントリビュートはメイン業務と調整して行うことになるので、予想通りハードルが高そうです。
- まずハードルを改善できそうなところでいうと、「理解がない」「コミュニケーションの課題」になりそうなので、まずここにアプローチしていくことになりそうです。
3.インナーソースに参加する上でどのようなサポートが必要だと感じますか？ （複数選択可）
- 「社内でのインナーソースに関する情報共有やプロモーション」「ガイドライン」が必要であることを改めて感じました。
- 3番めに多い「インナーソースの専門知識やトレーニング」、4番目に多い「メンターやサポート役」から、インナーソースを普及・サポートする活動も継続的に行っていく必要があると感じました。
4.今後、インナーソースを他のプロジェクトや部署に展開することについてどのように考えますか？
- 反対の方はいませんでした。
- 中立の方で多かった理由は、そもそもインナーソースの理解がないから判断できないというものでした。
5.上記(4番の質問)の回答理由をざっくばらんに記入してください。一言でも結構です。
回答をまとめてみると以下のようになりました。
賛成
- エンジニア間の横展開が活発になりそう
- さまざまな視点からコードをいいものにしていくことができそう
- リソースを効率的に使える
- 技術力向上
- ライン業務以外で技術に触れることができる
- 属人化解消
- 情報がオープンになる
- 他チームのシステムを修正したいとき、担当者のスケジュールを気にしなくてよくなり、優先順位で後回しにされることも無くせるのでよい
中立
- 判断できるまで理解がない
- 取り入れる工数があるか不安
賛成では多くのメリットを上げてもらえ、インナーソースを知っている人には、メリットが伝わっているのだと感じました。
6.もじこえインナーソースに参加、参加しようとしてくださった方のみ必須
- こちらの質問は、実際にもじこえインナーソース実験に参加、参加しようとした方を対象
- 「チーム間のコラボーション向上」が最も多く、実際にグループの垣根を超えて参加してくれる方がいました。私も普段関わらない人とコミュニケーションが取れてコラボレーション向上は大きく感じました。
- 「ナレッジ共有の促進について」も高く、他チームのおすすめCIツール設定や他者の面白いアイデアなどがリポジトリに反映されるので、私自身も大きな可能性を感じました。
- 「コードの品質向上」については、README.mdやCONTRIBUTING.mdなどのドキュメント系が整備されたのがよかったですが、今回お試し対象になったツールは画面UIを修正することがメインになるシンプルなツールだったため、テストコードが増えませんでした。
- 「プロジェクトの進捗速度向上」については、メイン業務で使われず、独立したツールのため、開発速度を求められておらず、メイン業務の隙間に開発する人が多かったので、低くなったと思います。
7.インナーソースの取り組みに関して、感想、改善すべき点や提案があればご記入ください。どんな些細なことでもOKです。
質問の回答を一部抜粋します。
感想
- コーディングが得意でなくても気軽に取り組めるものだと嬉しい
- 楽しい 皆自分のチームの仕事があると思うので、1つのIssueが小さければ小さいほど参加しやすそうだなと思いました
- 仕組みが整えば開発だけでなく社内ナレッジに関するドキュメント整備にも役に立ちそうな気がしました。
提案
- おそらく、「インナーソースって何？」、「どんなメリットがあるんだろう？」と思っている方が私を含めている気がします。なので、インナーソースの基礎的な知識を共有する場があったら嬉しいです！
- Fork解放するかどうかの検証をしてほしい
- ドキュメントとレポジトリの共通化を強く意識したほうがよいと思います。 そのへんが共通であれば、全社感はとても出るので。
- 参加するメリットや会社的な評価がわからない
- 長く続けるとソースの管理者がいなくなったときの想定も必要かも。
実際にインナーソースお試しに参加してくれた方は、楽しいと感想をもらえたり、ドキュメントの共通化に関する感想をもらえたりと、インナーソースが普及していくとDeveloper Exprerience向上につながるのではないかと思いました。
評価の話やトラステッドコミッターの引き継ぎの話など、深いところまで言及してくる方もいました。
実際にインナーソースを普及するためにも必要な話になってくるので、徐々に考えていきたいと思います。
3.4.3. アンケート結果からの考察
インナーソースの全社展開に関しては、賛成が多く、反対は0%でした。
コラボレーション向上、透明性向上、技術力向上などのメリットは伝わっているのだと思いました。
ただ時間やリソースの制約が課題になりそうです。
まずは、理解不足の人をなくしていくのと、コミュニケーションの課題などから解決していきたいです。
コミュニケーションの課題については、もっと具体的な課題を質問すればよかったと思いました。
今後考えることは多いと思いますが、需要はありそうなので、全社展開に向けて活動していくことにしました。
4. 後の話はその②の記事に書きます
インナーソースのお試し後も社内で普及活動を続け、2023年11月時点では、社内向けインナーソースガイドライン、インナーソースポータルなどを公開し、インナーソースリポジトリが少しづつ増えてきている状態です。
詳しい内容は別記事で紹介する予定なので、気になる方はぜひご覧ください！
【追記】その②を公開しました！
