この記事は、ニフティグループ Advent Calendar 2023 16日目の記事です。
InnerSource Commons #11にて、ニフティでのインナーソースを導入期の事例紹介し、ディスカッションパートでは、全社展開に向けての悩んでいることについて話しました。
✔本記事の内容
こんにちは！会員・認証基盤システムの開発・運用をしている基幹システムグループの小松です。
InnerSource Commons #11 の発表したことやディスカッションした内容を一部紹介します。
ディスカッションパートではとても勉強になる情報を教えていただきました！
InnerSource Commons Japanのイベント
connpassにてInnerSource Commons Japanのイベントが開かれています。
まだ日本の事例は少ないので、有識者の方と直接お話ができる有意義なイベントとなっています。
アーカイブもYouTubeにて公開されています。
2024年度からは、コミュニティ内の繋がりを活発にするためオフラインの開催も増えるらしいです。
ニフティの事例紹介
InnerSource Commons #11ではまずニフティから、インナーソース導入に向け今までやったことの概要、インナーソース実験プロジェクトの結果と全エンジニアに向けたアンケートの結果を紹介しました。
ブログ記事（インナーソースを導入してみた その① お試し導入編）にアンケート結果など書かれているので気になる方はご覧ください。
登壇時に発表した資料は以下です。
発表パートはアーカイブに残っています。
事例紹介の内容で参加者の方と話したこと
ブログの内容も含め取り組みに感動したと言うフィードバックをいただけて嬉しかったです。
日本ではまだ事例が少ないので、ニフティとしても取り組み内容など情報発信をしていきたいと思います。
「インナーソースを始めたモチベーションは、やはりインナーソースのような開発の必要性を感じているのが大きいか？」という質問が来ました。
ニフティとしては必要性を感じています。
私と芦川が所属している基幹システムグループでは、共通基盤となるシステムが多くあるため、今後の開発業務で、共通基盤で必要となる修正がボトルネックになることを避けるためにもインナーソースは必要だと思っています。
「実験プロジェクトに参加した人数に比べて、アンケートの内容はポジティブな人が多かった。実際の社内の雰囲気はどうだったのか？」という質問が来ました。
2ヶ月の実験プロジェクト(社内ツール1リポジトリをインナーソース化)で約150人エンジニアがいるなかIssueをアサインした人が7名でした。
しかしアンケートは43名が回答してくれ、全社展開に賛成が76.7%、中立が23.3%、反対は0%でした。
メリットについても多くの方が記入してくれました。
実際、実験プロジェクトを始めますとエンジニア全体会で発表したときも、「〇〇リポジトリをインナーソース化したい！」といったフィードバックが何件か来ていたので、メリットは伝わっていてインナーソースに対してポジティブな人が多いと感じていました。
良い取り組みにポジティブな反応をしてくれるニフティのエンジニアの雰囲気もあると思います。
実験プロジェクトの参加者が少なかったのは、メインストリームの開発業務とのバランスがネックになっていたと思います。
これについては後述する悩みにも入っています。
社内展開に向けて悩んでいることの共有
現在インナーソースガイドラインやインナーソースポータルを公開し、いくつかインナーソースリポジトリが徐々に増えてきている段階です。
全社展開に向けての悩んでいることを共有し、ディスカッションさせていただきました。
他の会社はどのように進めたのか？
悩みの背景
- ニフティの規模に近いサンプルがあるのか
- 組織の人数感、文化、B2B orB2C、など
- 浸透速度なども知りたい
- 社内に普及するためのコツはありますか？
- ニフティではトップダウンでなくボトムアップで進めている
- 導入にはポジティブな雰囲気だが、スピード感が早いとは言えない状況
ディスカッションした内容
まずニフティの規模（エンジニア約150名）に近いサンプルは日本にはない。
ヨーロッパの方には近しいものがあるが、日本ではまだ知られない会社が多い。ソフトウェアベンダーの会社が多い。
社内に進めるスピード感について。
ここまでの流れは世界的にみても平均よりは早い方。
ただし更に社内展開していくところから色々な課題がでてくるので、ここからの方が重要でスピード感が求められる。
もともとインナーソースに近い活動をすでにしていた組織ではインナーソース普及が早いとのことでした。
ニフティはチームを超えて協力しあう雰囲気はすでにあったので、ここまでは順調に来れたのではないかと思います。
全社展開のコツ。
やはり人が多くなると時間もかかり、1年かかるところもあれば2,3年くらいかかるところもある。
社内で引っ張っていく人を1、2人を決めるのがよい。
元々OSSコントリビュートをやっていた人がなるケースがある。
成熟度モデルは誰がどの単位で自己評価していくか？
悩みの背景
例えば、透明性（プランや開発プロセス、ツール、意志決定など）は各プロダクト単位で自己評価していくとよさそうだが、ガバナンス（リワード、カルチャーなど）は全社的にインナーソースオフィスが評価すべきか？
ディスカッションした内容
あくまでベンチマークなので、組織的な課題と突合させて判断する。
成熟度モデルに関しては、誰のためのアセスメントなのかが重要。
単純に数値を上げることに注力しては意味がない。
自分たちの課題を見つけてレベルアップするために使うもの。
第三者含め、背景なども踏まえ議論しながら使うのがよい。
最初から全ての項目を測る必要はない。
事例として全てをチェックしたらどの項目も最低値になり、結局どこから手を付けるのかがわからなることがあった。
まず導入期は細かいプロダクト単位で測っていくのがよい。
徐々に案件や組織ベースで測っていくのがよいとのこと。
アンケートなどで課題や目指す姿を聞いてみるの効果的。
メインストリームの開発業務とのバランスをどう考えるか？
悩みの背景
- そもそもインナーソースは余力時間にやるものなのか
- 例えば、スクラムで開発をしている場合で、期待する成果物をより早くデプロイできる場合、プロダクトバックログアイテムに他リポジトリへのコントリビュートをすることも視野にいれていくのか
- スクラムをやっているチームはどのようにインナーソースを取り入れているか
ディスカッションした内容
まずボトムアップで組織にインストールする場合、良いカルチャーがあるとこの活動いいね、やりたいまではすぐ行くが、実際の業務で効率が上がったと認識するまでにはハードルが高い。
メインストリームの開発とのバランスを考えるよりもインナーソースを使って生産性を上げるという考え方への変換が必要になりそう。
余力時間を会社が認めて上げることも必要。
コントリビュートなどを試してみる時間の確保(Googleの20%ルールなど)や評価制度などのサポートがあるとよい。
実際のコントリビュートは余力時間以上のコストがかかるのでサポートが必要。
評価システムによって導入が難航している事例が多い。
とある事例では、コントリビューターを引き付けるようなものがあるとサイクルが回ったとのこと。
コントビュートされる側が一緒にやりましょうと呼びかけ、コントビュートする側もコントビュートされる側もプロダクトが良くなって、より多くの人が使われるようになり評価もされるとのこと。
スクラムとの兼ね合いについて。
スクラムはスプリントで期限が決まっているので、インナーソースと同期できないので単一のスクラムチームでは厳しい。
Large-Scale Scrum (LeSS) とインナーソースの相性はいいかもしれない。
スプリントゴールを達成するために、他チームのリポジトリに手を入れる必要がある場合が発生するため。
感想
まだニフティは導入始めたばかりでインナーソース文化の定着まではできていませんが、InnerSource Commons で事例紹介をさせていただく機会をいただけて嬉しかったです。
とても有意義なイベントでした。
まだ日本での事例が少ないので、情報発信をしつつ社内の普及活動を続けていきたいです。
悩みの部分に関してもいい情報をもらえたので良かったです。
成熟度モデルの評価はまずはできるところから検討してやっていこうと思います。
今回の話を聞かなかったら、とりあえず全部計測してみるというアンチパターンをやってしまいそうでした。
コントリビュートをサポートの仕組みなども検討していきます。
