Developer Experience and InnerSource - エンジニアの共創は結局大企業では無理なのだろうか

[セッション概要]
日本の企業文化の中でインナーソースを成功させるためには、アプローチは工夫をする必要があります。本セッションでは、日本のインナーソースコミュニティの成果と1年間の振り返りを基に、以下のポイントを深掘りします。

1. インナーソースの基本概念の再確認: インナーソースの核心とその重要性を説明し、新参者も容易に理解できるように解説
2. 1年間の振り返り: インナーソースの取り組みや結果、成功例、学びなど、1年間での動きを総括。
3. 日本/海外のインナーソースの現状: 国内外のインナーソースの動向と比較しながら、日本の進捗状況を評価
4. 企業戦略としてのインナーソース: インナーソースの目的と、それを日本企業の戦略としてどう位置付けるかの詳細な議論
5. インナーソースアンチパターンと解決策: 一般的に誤解されているインナーソースのポイントと、それに対する正しいアプローチや解決方法を提示。
6. 日本企業のためのインナーソースロードマップ: これからインナーソースを取り入れる企業のための、実践的なステップバイステップのガイドラインを提供。

Transcript

1. #InnerSource aka.ms/iscslack #jp-general 1 エンジニアの共創は 結局大企業では無理なのだろうか 服部 佑樹 @yuhattor Board Member, The InnerSource Commons Foundation Customer Success Architect, GitHub いや、むりでない
2. #InnerSource aka.ms/iscslack #jp-general Agenda インナーソースの基本概念の再確認: インナーソースの核心とその重要性を説明し、新参者も容易に理解できるように解説 振り返りとインナーソースの現状 (日本/海外): インナーソースの取り組みや結果、成功例、学びなど、1年間での動きを総括。 また、国内外のインナーソースの動向と比較しながら、解説 企業戦略としてのインナーソース: インナーソースの目的と、それを日本企業の戦略としてどう位置付けるかの詳細な議論 インナーソースロードマップ: これからインナーソースを取り入れる企業のための、実践的なステップバイステップのガイドラインを提供。 2
3. #InnerSource aka.ms/iscslack #jp-general The InnerSource Commons Foundation InnerSource Commons は、InnerSourceの実践者の世界最大のコミュニティです。 組織という枠の中でソフトウェア開発にオープンソースのベストプラクティスを活用する InnerSourceに関するナレッジの創出と共有に特化しています。 2015年に設立された InnerSource Commons は、現在 750 以上の企業、学術機 関、政府機関から2000人以上の個人をサポートしつないでいます。 3
4. #InnerSource aka.ms/iscslack #jp-general 4
5. #InnerSource aka.ms/iscslack #jp-general インナーソースの基本概念 5
6. #InnerSource aka.ms/iscslack #jp-general InnerSource とは オープンソースの原則を 社内のソフトウェア開発に適用すること InnerSource is the application of open source principles to company-internal software development 6
7. #InnerSource aka.ms/iscslack #jp-general InnerSourceは、 企業文化や組織内部の制限を尊重しつつ、 オープンソースに似た内部のシェアリングエコノミーに向けて 文化的に変革し、組織のサイロを壊していく旅です 7
8. #InnerSource aka.ms/iscslack #jp-general なぜ今 InnerSource なのか 8
9. #InnerSource aka.ms/iscslack #jp-general なぜ今 InnerSource なのか 9 Technology の進化と マーケットの急拡大 2000 2023
10. #InnerSource aka.ms/iscslack #jp-general なぜ今 InnerSource なのか 10 Technology の進化と マーケットの急拡大 39,100人 221,100人
11. #InnerSource aka.ms/iscslack #jp-general なぜ今 InnerSource なのか 11 39,100人 221,100人 大量のプロダクトと大量のチーム サイロが簡単にできてしまう状況
12. #InnerSource aka.ms/iscslack #jp-general 経済の状況: 景気後退 グローバル • コスト削減 - 被っているプロダクト・機能の統合 • 成熟したプロダクトおよび組織の最適化 • 肥大化・サイロ化した組織の単純化 日本 • 引き続きエンジニア不足 / 少子高齢化 • 業界の多重請負構造は硬直したまま • (ようやく) 企業は少しずつ内製化 💪 風通しの良い文化と、コスト削減、新しい価値の創造の必要性 12
13. #InnerSource aka.ms/iscslack #jp-general InnerSourceは、 企業文化や組織内部の制限を尊重しつつ、 オープンソースに似た内部のシェアリングエコノミーに向けて 文化的に変革し、組織のサイロを壊していく旅です 13
14. #InnerSource aka.ms/iscslack #jp-general InnerSource の4つの原則 Openness - オープンなプロジェクト リポジトリのトップに置かれる README.md ファイルと CONTRIBUTING.md ファイルによって十分にドキュメント化され発見できるようになって いなければなりません。 Transparency - 透明性 プロジェクト/リポジトリとその方向性未解決の機能要件機能要件の進捗ホストチームの意思決事項を透明にします。 Prioritized Mentorship - 優先的なメンターシップ Trusted Committer によるホストチームからゲストチームへの優先的なメンターシップにより、ゲストチームの コントリビューター は、ホストチームの プロジェクト/リポジトリについて十分理解し、変更できるようにレベルアップされます。 Voluntary Code Contribution - 自発的なコードコントリビューション ゲストチームとホストのチームの両方からInnerSourceに参加することが、彼らの自由意志に基づいて行われること 14
15. #InnerSource aka.ms/iscslack #jp-general InnerSource はエンジニアの共創を実現する鍵 15 XP ソースコードの共同所有 DevOps 組織のサイロを削減する Team Topologies チーム間の相互作用 Platform Engineering 車輪の再発明をしない InnerSource
16. #InnerSource aka.ms/iscslack #jp-general InnerSourceは企業規模でチームとコードをつなぐ 16 DevOps DevOps DevOps Waterfall DevOps Kanban
17. #InnerSource aka.ms/iscslack #jp-general InnerSource Program Office - ISPO InnerSource Program Office (ISPO) は、InnerSourceを組織内で実現するための手段と環境を提供します。 プログラムオフィスは開発を促進しますが、開発部門やゲートキーパーではありません 主な役割 • InnerSource 方針の共有 • メンタリング / トレーニングの実施 • InnerSourceのアドバイザリー • インセンティブモデルの開発 • 支援活動の組織化 • 適切なツーリングの確保 (ex: BI Dashboard, InnerSource Portal, GrimoireLab – CHAOSS toolset) 17
18. #InnerSource aka.ms/iscslack #jp-general InnerSource の推奨計測メトリクス リポジトリごとの状況の１ヶ月ごとの推移 • Contributor が複数いるリポジトリ数 • CONTRIBUTING.md の存在するリポジトリ数 • README.md が存在するリポジトリ数 • Fork の数 プルリクエスト数の推移 • 期中のプルリクエストの数* • チームを越えたプルリクエストの数 18 * GitHub Enterprise Server においては GitHub Connect - Server Statistics が有効です。 * 上記は Microsoft の事例です PR Cross Team PR % Q1 FY19 852k 37k 5.6% Q2 FY19 810k 35k 4.2% Q3 FY19 912K 39k 4.8% Q4 FY19 1.0M 46k 4.1% Q1 FY20 1.2M 43k 3.6%
19. #InnerSource aka.ms/iscslack #jp-general プラクティス集 - InnerSource Patterns (一部) 19 ソフトウェアライフサイクル全体で参加型システムを作成し、デザインドキュメントを公開して早期のディスカッションを促進する。 30日の保証期間 社内兼業コントリビューター インナーソースライセンス インナーソースベースドキュメント インナーソースポータル インナーソースデザインドキュメント 基本原則ガイダンスの文書化 トラステッドコミッター コントリビューターが30日間のサポート付きでバグ修正や機能提案をすることで、両チームの信頼を向上させる。 ボランティアではなく、組織内で正式な契約と合意をすることによって、InnerSourceへの貢献を促す。 組織内でソースコードを共有するための法的枠組みを提供し、新たなコラボレーションオプションを提供する。 InnerSourceプロジェクト情報をインデックス化し、コントリビューターが興味を持つプロジェクトを発見しやすくする。 継続的なコントリビューターの仕事を認識し、報酬を与える方法を定義する 標準的なプロジェクトドキュメントを提供し、新規コントリビューターに自己サービスプロセスを提供する。 InnerSourceの主要原則を文書化し、広く公開する。 パターン名 パターンの概要
20. #InnerSource aka.ms/iscslack #jp-general 1 年間の振り返り / 世界の状況 20
21. #InnerSource aka.ms/iscslack #jp-general InnerSource Commons Japan InnerSource のワーキンググループ InnerSource リソースの翻訳 InnerSource の勉強会開催 / 動画作成 21
22. #InnerSource aka.ms/iscslack #jp-general InnerSource Case Study 22
23. #InnerSource aka.ms/iscslack #jp-general InnerSource Case Study 23
24. #InnerSource aka.ms/iscslack #jp-general 世界では何が起こっているのか • 生成 AI • 認知不可の増大 (管理対象が多すぎる) • コストカット • 人材不足 • Security の問題 (急速な進化についていけない) DevOps など既存の概念も変革が求められている 24
25. #InnerSource aka.ms/iscslack #jp-general 25 https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/tech-forward/why-your-it-organization-should-prioritize-developer-experience
26. #InnerSource aka.ms/iscslack #jp-general Developer Experience (DevEx/DX) 人材の引きつけと定着 ➢ 世界中の優れたエンジニアは、素晴らしいブランドだけでなく、技術文化と高い従業員満足度がある優れたテクノロジー企業で働きたいと 考えています。こうした企業では、開発者は彼らが得意とすること、すなわち先進的なツールを使用して優れたソフトウェアを構築することが できます。 生産性とコスト削減 ➢ ボイラープレート活動に費やす時間を減らすことで、アイデアから顧客の問題を解決するコードまでの時間を数ヶ月から数分に短縮することが できます。このような生産性の向上はDXへの投資が必要ですが、その投資は高いROIを持っています。 一貫性と品質 ➢ 開発者のための全体のツールスタックを標準化し、製品化することで、DXは向上し、デジタル製品の品質も向上します。さらに、容易に見 つけて使用できるツールは、開発者が本当に重要な作業に集中することを可能にします。 セキュリティとコンプライアンス ➢ セキュリティとコンプライアンスが最初からコンポーネントに組み込まれている場合、例えば、エンタープライズ全体のCI/CDパイプラインの一部と してセキュリティテストが行われる場合、コンプライアンスは箱から出した状態で既に満たされています。 速度 ➢ チーム間のハンドオーバーや調整を減らし、早期の品質チェックによる再作業を排除し、生産へのパスを完全に自動化することで、開発者は はるかに速く進むことができます。これにより、数週間または数ヶ月に一度のデプロイメントではなく、1日に数回のデプロイメントが可能となり ます。 26 McKinsey 記事のサマリー
27. #InnerSource aka.ms/iscslack #jp-general 優れたDevExを確保するための10のステップ ユーザーに焦点を当てる : 開発者エクスペリエンスプラットフォームの最も重要な顧客は開発者です。 プラットフォームを製品として扱う: DXプラットフォームを所有し、それを適応させる責任を持つ小さな中央チームを設立します。 貢献モデルの分散化: 中央チームが開発を完全に所有するのはスケールしません。分散型の継続的な開発が可能な貢献モデルを確立する必要があります。 成功を使用率で定義する: 成功の重要な指標は、プラットフォームへのトラフィックを生成し、開発者がそれを日常的に使用する能力です。 影響を測定する: KPIを最初の日から測定します。例えば、Salesforceは顧客の問題を解決するコードに至るまでのプロセスの期間を、Spotifyは新しい開発者の生産性を測定します。 既存の機能を最大限に活用する: 既に製品化され、採用されているツールを使用し、既存のチームがプラグインを介してプラットフォームに統合するのを支援します。 最初の日から機能を構築する: この努力は、優れたプラットフォームエンジニアを集めることではなく、プラットフォームエンジニアリングの能力の重要な質量を築くことについてです。 プラットフォームを布教する: エンジニアリング文化と習慣を促進し、DevOpsチーム内での採用を促進します。 変化を管理する: DXは、技術だけでなく、プラットフォームの採用と使用をサポートするために必要なすべての前提条件にも関わっています。 大きく考え、小さく行動する: プラットフォームが初日から価値を提供し、スケールするようにするため、MVPの範囲は最初の顧客またはユースケースに限定すべきです。 27 McKinsey 記事のサマリー
28. #InnerSource aka.ms/iscslack #jp-general DevEx 28 https://www.youtube.com/watch?v=mRqoVlhtVzA
29. #InnerSource aka.ms/iscslack #jp-general Japan も勉強会やっているので見てください 29
30. #InnerSource aka.ms/iscslack #jp-general 企業戦略としてのインナーソース 30
31. #InnerSource aka.ms/iscslack #jp-general インナーソース導入のポイント インナーソースに関する誤解 31
32. #InnerSource aka.ms/iscslack #jp-general GitHub を使ってるからInnerSourceはできてるでしょ？ 32 InnerSourceの実現には GitHub が必要だという意見は、私達が毎日戦っている概念です。 GitHub は組織におけるコードの透明性を上げますが、それだけで組織の縦割り問題が解決するわけで はありません。 ほとんどの人々は、GitHub の活用よりもはるかに大変なことに気づいていません。 それは、社内におけるオープンソースの源を見つけ、コミュニティとし て育ててゆくことなのです。 コミュニティがソフトウェアを作るのであって他の何者でもないのですが、 大企業にはそれに気づくための全体的なコミュニティに対する センスがないのです。 From “Understanding the Innersource Checklist” by Silona Bonewald, the founding member of the InnerSource Commons.
33. #InnerSource aka.ms/iscslack #jp-general 競争の源泉をコードに埋め込み、 シナジーを生み出し、エコシステムを強化 InnerSource では、組織は部外者にコードが公開されることを恐れることなく、 競争の源泉である企業秘密をコードに埋め込むことができ ます。 同時に、組織全体にわたる人々によって提供される多様な視点やクリエイティ ビティの恩恵を受けることができます。 33 From “Getting Started with InnerSource” by Andy Oram, an editor for O'Reilly Media
34. インナーソースの布教活動をして 感じた課題 2 つの大きく異なる目的によるインナーソースの混同 34
35. #InnerSource aka.ms/iscslack #jp-general サイロを取り除いた結果生まれること 35 個人や組織に影響 プロダクトに対して影響 価値 最大化 コスト 削減 共創で 新しい価値/イノベーションを創出 組織全体の技術/知識共有で品質向上 チーム連携による、製品間のシナジー オープンで共創が生まれる開発文化育成 技術や知識共有によるスキルレベル向上 キャリア成長促進で、従業員満足度向上 社員の離職率の低下を促す 透明性拡大による効果的なリソース配分 組織のプロセス最適化 車輪の再発明の防止で生産コスト削減 早期検出と対処容易化によるリスク低減 以前使っていたスライド
36. #InnerSource aka.ms/iscslack #jp-general 両方同じインナーソースだが 36 文脈を一緒にすると、キケン。伝わらない Developer Experience のためのインナーソース 競争戦略 (差別化戦略) としてのインナーソース
37. #InnerSource aka.ms/iscslack #jp-general インナーソースが活きる場所 37 Developer Experience のためのインナーソース 競争優位性のためのインナーソース 得られ る効果 対象 共創で 新しい価値/イノベーションを創出 組織全体の技術/知識共有で品質向上 チーム連携による、製品間のシナジー 車輪の再発明の防止で生産コスト削減 透明でコラボラティブな開発文化育成 技術や知識共有によるスキルレベル向上 従業員満足度向上と離職率の低下 車輪の再発明の防止で生産コスト削減 切り分けとしてはこちらのほうが的を得ている ドキュメンテーション / テンプレート 共有ライブラリ / 社内ツール / 開発ツール スニペット / パッケージ / ハッカソンプロジェクト 特許技術 / 知的財産 将来の競争のために一部をOSS化すべき領域 サイロ化組織における製品間のシナジーを強化すべき領域
38. #InnerSource aka.ms/iscslack #jp-general 両方同じインナーソースだが対象が全く違う 38 人材/チームの 価値を最大化する プロダクト/技術の 価値を最大化する Developer Experience のためのインナーソース 競争優位性のためのインナーソース
39. #InnerSource aka.ms/iscslack #jp-general 誰のための戦略か 39 誰の ため 企業と部門のため、 (ひいては技術立国日本のため) 開発者のため (最終的に、企業の成長のため) 対象 アプリケーション開発チーム クラウドプラットフォームチーム DevOps チーム など IT チーム など、多岐にわたる R&D チーム すでに競争優位性のあるプロダクトのチーム Developer Experience のためのインナーソース 競争優位性のためのインナーソース
40. #InnerSource aka.ms/iscslack #jp-general なんのための戦略で評価軸は? 40 評価 生まれた競争領域における共創の数 クロスチームプロジェクト/プロダクトによる利益 開発のベロシティ コストダウンの実現 従業員 (開発者) 満足度 なんの ため 開発者の体験が良くなることを通して、 チームや開発体制の改善につなげる 戦略的な領域を特定し、社内で 共創、シナジー、イノベーションを生む Developer Experience のためのインナーソース 競争優位性のためのインナーソース
41. #InnerSource aka.ms/iscslack #jp-general 普及のアプローチ / 必要な人材 41 普及の アプロ ーチ 必要 人材 • CTO、BDM、中間管理職や、一部の R&D 推進担 当が危機感を持って / 利益最大化を狙い、取り組む • 競争領域であり、IP や利益供与、移転価格税制がセ ンシティブであり、草の根では始まりにくい • CTO、BDM、中間管理職が、 開発や人材に関するインパクトのために / 文化改革の ために取り組む • 草の根で始まり得る • 社内の技術インフルエンサー • 勢いがあり、成長を望む社員 • 意志 / 危機感のあるトップ中間管理職 • 会社や技術・プロダクトを愛し、変革したいと考える社員 が リーダーに働きかける Developer Experience のためのインナーソース 競争優位性のためのインナーソース
42. #InnerSource aka.ms/iscslack #jp-general 抵抗される理由 42 多くの場合、大きなハレーションはない • 「人材」 のための施策であり、プロダクト自体に 大きな価値があまりないとされるケースが多い (会計上の取り扱いなど含め) • 自分のチームの人材の価値を高めて中長期的に 成長してもらうことはポジティブ だが、計測もしにくい。 直近で得られる効果に対して、 法・税・会計の問題をクリアするハードルが高すぎる • 「プロダクトや技術の価値」を移動しようとしているの当 然、問題はついて回る 社員がチームを越えて貢献することを 良しとしない中間管理職 • 「自分のプロダクト/技術価値」 にフォーカスがあり、その成長を 妨げる行動にネガティブなのは当然 Developer Experience のためのインナーソース 競争優位性のためのインナーソース
43. #InnerSource aka.ms/iscslack #jp-general インナーソース戦略のまとめ Developer Experience (非競争領域) のためのインナーソース 差別化の競争戦略(競争領域) のためのインナーソース 何をする 開発文化を変え、DevEx を促進することでチームや開発体制の改善につなげる 企業の差別化領域を拡大し、共創、シナジーからイノベーションを生む 最大化 人材の価値を最大化する プロダクト/技術の価値を最大化する 誰のための戦略? 開発者のため (最終的に、企業の成長のため) 企業と部門のため 戦略の狙い • 透明でコラボラティブな開発文化育成 • 技術や知識共有によるスキルレベル向上 • 従業員満足度向上と離職率の低下 • 車輪の再発明の防止で生産コスト削減 • 共創で 新しい価値/イノベーションを創出 • 組織全体の技術/知識共有で品質向上 • チーム連携による、製品間のシナジー • 車輪の再発明の防止で生産コスト削減 対象技術 ドキュメンテーション, テンプレート, 共有ライブラリ, 社内ツール, ハッカソンプロジェクト 特許技術, 知的財産, 競争のための OSS化領域, 競争優位性のある製品 対象チーム アプリケーション開発 / クラウドプラットフォーム開発 / DevOps チーム など R&D チーム / すでに競争優位性のあるプロダクトのチーム 評価 開発のベロシティ, コストダウンの実現, 従業員 (開発者) 満足度 生まれた競争領域における共創の数, クロスチームプロジェクト/プロダクトによる利益 トップダウン アプローチ リーダー(CTO, BDM, 中間管理職) が開発組織の改善のために実施 意志-危機感のあるリーダー (CTO, BDM, 中間管理職) が、企業や部門の利益最大化を狙い取り組む ボトムアップ アプローチ 草の根で始まり得る (社内の技術インフルエンサー / 成長を望む社員) 競争領域であり、IP や利益供与、移転価格税制がセンシティブであり、草の根では始まりにくい 会社や技術・プロダクトを愛し、変革したいと考える社員 が リーダーに働きかける 抵抗される理由 多くの場合、大きなハレーションはない → 「人材」 のための施策であり、プロダクト自体に大きな価値がないケースが多い プロダクトが大きな価値を産んだ瞬間、それは右の領域に移動する → 自分のチームの人材の価値を高めて中長期的に成長してもらうことはポジティブ 直近で得られる効果に対して、法・税・会計の問題をクリアするハードルが高すぎる → 「プロダクトや技術の価値」を移動しようとしているの当然、問題はついて回る 社員がチームを越えて貢献することを良しとしない中間管理職 → 「自分のプロダクト/技術価値」 にフォーカスがあり、その成長を妨げる行動にネガティブなのは当然 43
44. #InnerSource aka.ms/iscslack #jp-general インナーソースの目的をまず考えましょう Developer Experience なのか、企業の競争戦略なのか。対象が誰なのかを考えます 競争領域においては特に、インナーソースを主語として話さない いきなり全体の話になって、話が止まります。「この技術を社内で共有できたらすごい」「この技術をあの部門と共有したい」 かなり具体的な領域 から会話を始めます 何が利益になるのか、成功なのかを考えて逆算します 社内向け便利ツールの「価値」をプロモーションするのは大変です。 やる意味よりもやらない意味を見つけるほうが楽ですし、やらない理由はたくさん見つかります。 一方で、尖った技術領域の共有はダイレクトに価値をもたらします。この場合「やる意味」が明確です。 評価軸を先に 考え、コミュニケーションをします 44 インナーソース戦略のまとめ
45. #InnerSource aka.ms/iscslack #jp-general 戦略的なインナーソース導入ガイド 45
46. #InnerSource aka.ms/iscslack #jp-general インナーソース戦略に関する誤解 46 • インナーソースは自律的に個人がコントリビューションしあうものである • うちは評価指標がないから無理 • 会計、税務、知財の問題があるから難しい
47. #InnerSource aka.ms/iscslack #jp-general インナーソースは自律的に個人がコントリビューションしあうものである これを考えている人のインナーソースにたいするイメージ (極端な例) 47 あ、インナーソースの プロジェクトだ！ 貢献しよう！ このプロジェクトも インナーソースか PR 送ってみようかな この会社は 風通しがいいなあ コラボレーションが 自律的に生まれてる
48. #InnerSource aka.ms/iscslack #jp-general インナーソースは自律的に個人がコントリビューションしあうものである • 初期から双方向のプロジェクトはほぼない。 • 大抵のオープンソースプロジェクトでそうであるように、多くの場合ほとんどの稼働が一部のメンバーによって なされている。 • インナーソースプロジェクトの王道成長パターンは以下の通り 48 プロジェクトをオープンで作ったが すべてのコントリビューションは 自チームによるもの ユーザーが現れたり、 Issue や バグフィックスの PR による コラボレーションが生まれる 機能単位で PR が来るようになる 特定のチームとの コラボレーションが始まる 特定のチームのメンバーが トラステッドコミッターとして メンテナンスに加わる。 業務として管理を行う ・ ・
49. #InnerSource aka.ms/iscslack #jp-general インナーソースは自律的に個人がコントリビューションしあうものである 現実的なインナーソースの例 49 チームが抱えるプロダクトの中から 競争的な領域や、DevEx に有用な領域 社内のユーザーに使ってもらい 「プロダクトチームが利する領域」 を特定し、戦略的にプロモーションをする 選定 した プロモーション しよう プロダクトA SDK プロダクトA プロダクトA SDK このライブラリ使ったら プロダクトAの統合を 簡単に実装できるよ プロダクトA SDK README.md とか も拡充しよう プロダクトA SDK PR 送ってくるの？ ありがとう！！ メンター シップ うちのプロダクト でも使ったら メリットあるかも 結果的にDevEx 向上したし、 新しく入ったメ ンバーもオンボ ーディングが早 くなった!!
50. #InnerSource aka.ms/iscslack #jp-general 最終的には両方に作用する 50 Developer Experience のためのインナーソース 競争戦略 (差別化戦略) としてのインナーソース
51. #InnerSource aka.ms/iscslack #jp-general うちは評価指標がないから無理 本当にやるべきでないケース (全期間を通して本当に評価されない可能性) • 「評価指標がない」 で止まる場合 その協働が生み出す価値が本当に低い可能性があります 短期的にもやるべきであるが、なぜかできないケース • 競争優位性のあるプロダクト/技術領域/特許技術を 目の前にして、そして生み出される利益を具体化できる にも関わらず、「評価指標がないから無理」 は怠慢です。 • もしも本当に部門や企業にとって大事な領域だったら会社の中を這いずり回ってシナジーを生み出せる領域を探して共創を模索 するはずです。 • 組織に対する利益を具体化しましょう(InnerSource Patterns: クロスチームプロジェクト評価) 中長期的な視点ではやるべきであるケース • 短期的に価値を生み出さないケースでは「短期的な評価指標がない」事が原因になります。 • 中長期的な視点ではコストと利益の算出が難しく、戦略に組み入れにくいことが原因です。 • 期間限定のトライアルとして実施しましょう(InnerSource Patterns: 実験として始める) 51
52. #InnerSource aka.ms/iscslack #jp-general 会計、税務、知財の問題があるから難しい 順序を考えて戦略的に始めましょう 52
53. 一方方向の共有 チームは単純に 完成した 部品を共有する 特定チーム間の 連携 チームにコントリビューショ ンが届く さまざまなチームと の自律的な協働 組織内で広く貢献を受けと る インナーソースのコラボレーション範囲と共有の考え方 複雑で難しいが インパクトが大きい 始めるのに最適 InnerSource Scope InnerSource Sharing Approach 53 社内 コラボレーション グループ内 コラボレーション 国際間 コラボレーション 社外を含めた コラボレーション
54. 一方方向の共有 チームは単純に 完成した 部品を共有する 特定チーム間の 連携 チームにコントリビューショ ンが届く さまざまなチームと の自律的な協働 組織内で広く貢献を受 けとる インナーソースのコラボレーション範囲と共有の考え方 複雑で難しいが インパクトが大きい 始めるのに最適 InnerSource Scope InnerSource Sharing Approach 54 社内 コラボレーション グループ内 コラボレーション 国際間 コラボレーション 社外を含めた コラボレーション 単一法人の場合、InnerSourceは チーム間の合意やコストセンターの調 整だけで InnerSource を実現でき る可能性があり、非常にシンプルで す。 文化変革などの組織改革が必要で す 法人格の垣根を越える際の課題 • 知的財産権に関する問題 • 会計上の問題 • 税務上の問題 • 利益供与 会計上の問題は、グループの連結決 算の枠組み内での扱いにとどまりま す。 共通認識の確立の重要性 ヒント： • ソフトウェア権利の集中化でコラボ レーションの効率化を容易にする • 持株会社やソフトウェア専業会社 にソフトウェア権を集める 国際的な境界を越える際の課題 • 移転価格税制の問題点 • 業界標準のルールがない この分野の現状 • InnerSourceにおける移転価格 税制については、いくつかの論文 がある。 • 業界内の共通認識はまだ得られ ていません。 • 一般的に移転価格税制は、 OECDが制定した参考資料を参 照することが多いですが、ソフト ウェアに最適化されたものではあり ません。 • 類似事例の検索、アプローチのカ スタマイズ、企業独自のルール作 りなどが必要です。 通常、InnerSourceの目的は、企 業内の戦略的領域を共有し、技術 を再利用して競争力を高めることに あるため、資本関係や十分な資本 比率を持たない企業間の協業は対 象外となることが多いです。 一方、SDKや特定ライブラリなど、特 許や価値のある部分を隠すためにブ ラックボックス化された部品は、 InnerSourceを通じて共有すること が可能です。
55. 一方方向の共有 チームは単純に 完成した 部品を共有する 特定チーム間の 連携 チームにコントリビューショ ンが届く さまざまなチームと の自律的な協働 組織内で広く貢献を受 けとる インナーソースのコラボレーション範囲と共有の考え方 55 社内 コラボレーション グループ内 コラボレーション 国際間 コラボレーション 社外を含めた コラボレーション R&D Entries IT資産管理のベストプラクティスを 適用して、会計項目における「ソフ トウェア」を共有する。 チームごとに労務管理・共有ルールを策 定します Software Entries グループ間の共有ルールを制定 移転価格税制に関するルールを制定 コストセンターのつけかたなど、管理方 法について事前に打ち合わせを行い、調 整します InnerSourceライセンスとしてテンプ レートを作成することで、コラボ レーションが起こりやすくします InnerSourceの移転価格税制に関する ルールの組織的な見解について、特定 のプロジェクトに限った場合に共有範 囲は限定的である可能性があり、経理 部門と連携すれば十分な場合がありま す。 Innersource Program Offifceは、事例の Innersourceライセンス化、公式コーポ レートライセンスの開発を支援します InnerSourceライセンスとしてコラボ レーションをモデル化し、コストセン ターや共有ルールを各チームと毎回会 話する必要がないようにします IP利用ルールや利用制限、再利用可能 な部分のブラックボックス化などを考 慮する IP共有のルール設定、IPの限定された部分（使 用SDKやライブラリなどのインターフェースの みを共有するなど、IPの価値ある部分や特許関 連部分を隠す）を共有するためのルールとベス トプラクティスを策定します。 移転価格税制に関するInnerSourceの ルールに対する自社の見解を整理し、 社内資料を作成します 社内のブラックボックス化を超えて自 律的かつ柔軟な共有を目指す場合、 アーキテクチャを分割して共有項目の 範囲を再定義するなど、さらなる連携 のステップが必要です
56. 一方方向の共有 チームは単純に 完成した 部品を共有する 特定チーム間の 連携 チームにコントリビューショ ンが届く さまざまなチームと の自律的な協働 組織内で広く貢献を受 けとる インナーソースのコラボレーション範囲と共有の考え方 56 社内 コラボレーション グループ内 コラボレーション 国際間 コラボレーション 社外を含めた コラボレーション ステップ1：文化醸成とGitHubコラ ボの熟成に注力する ステップ#2.5：分離面の定義、アーキ テクチャとGitHub Collaborationの状 態の整理、SDKの定義を行う。 ステップ#2：モデルの作成、 ライセンスの作成、 活動のスケールアップ ステップ#2.5：モデルの作成、ライセ ンスの作成、活動のスケールアップ 一般的に、共有はグループ内にとどまる必要がありますが、グループを 超えてインナーソーシングを行う必要がある場合は、早い段階でグルー プを超えてコラボレーションする方法を模索する必要があります ステップ#3：小さなエリアから国際 協力を始める ステップ#4：移転価格に関する社内 規則の策定（International InnerSource License） 56
57. #InnerSource aka.ms/iscslack #jp-general Developer Experience の文脈も戦略に含めよう DevEx のなかにおける InnerSource 戦略を考えましょう。 InnerSource の目的を考えよう 企業の競争優位性のため? DevEx のため?? InnerSource はリーダーのための「戦略」です InnerSource ができない? ロードマップをたててましょう 57 Key Takeaways
58. #InnerSource aka.ms/iscslack #jp-general InnerSource Commons もよろしくお願いします 58 https://aka.ms/iscslack #jp-general