The-Next-gen-Dev-Strategy-InnerSource

Transcript

1. 1 次世代の開発戦略 InnerSource 服部 佑樹 @yuhattor Vice President, The InnerSource Commons Foundation Sr. Customer Success Architect, GitHub
3. 統合と API The AI Powered Developer Platform to Build, Scale, and Deliver Secure Software コラボレーション プロダクティビティ セキュリティ スケール AI による強化
4. 単⼀の統合された エンタープライズ対応 プラットフォーム 開発者向けの 業界最⾼の コラボレーションツール ワークフロー全て におけるセキュリ ティ AI が埋め 込まれた The GitHub experience
5. GitHub Copilotによって コーディングのスピードが55%加 速 20,000以上のプ ロジェクトで利⽤ コード全体の46%が GitHub Copilotによって 提案されたコード 75%の開発者の 満⾜度が向上 開発者が利⽤
8. 今後の課題: AIをパーソナライズさせて、 チームに⾼い⽣産性をもたらし、 エンジニアに⾼い創造性を発揮させる 必要な状況 • AIが学ぶ/参照するためのリソース (知識/ソースコード) が存在する • そのリソースにアクセスできる • そのリソースがメンテナンスされている 多くの組織における現状 • 組織内にソースコードが存在しない • 組織のサイロに阻まれ、リソースは共有されていない • 開発したコードはメンテナンスされていない
9. AIが読みやすいコードとは ü メンテナンスされている ü ⽐較的メジャーな書き⽅/バージョンで書かれている ü コード⾃体が記述的(ディスクリプティブ) で読みやすい ü コードベースが巨⼤すぎず、コンテキストを取り出して作業が可能 オープンソースのコードの条件と⾮常に類似
10. オープンソースのソースコード管理を根付かせ、 価値のあるコードが共有され、AIからも使えるような状況を作るため には仕組みと⽅法論が必要
11. InnerSource とは オープンソースの原則を 社内のソフトウェア開発に適⽤すること InnerSource is the application of open source principles to company-internal software development 11
12. InnerSourceは、 企業⽂化や組織内部の制限を尊重しつつ、 オープンソースに似た内部のシェアリングエコノミーに向けて ⽂化的に変⾰し、組織のサイロを壊していく旅です 12
13. なぜ今 InnerSource なのか 13
14. なぜ今 InnerSource なのか 14 Technology の進化と マーケットの急拡⼤ 2000 2023
15. なぜ今 InnerSource なのか 15 01-Jan-94 01-Jan-95 01-Jan-96 01-Jan-97 01-Jan-98 01-Jan-99 01-Jan-00 01-Jan-01 01-Jan-02 01-Jan-03 01-Jan-04 01-Jan-05 01-Jan-06 01-Jan-07 01-Jan-08 01-Jan-09 01-Jan-10 01-Jan-11 01-Jan-12 01-Jan-13 01-Jan-14 01-Jan-15 01-Jan-16 01-Jan-17 01-Jan-18 01-Jan-19 01-Jan-20 01-Jan-21 01-Jan-22 Technology の進化と マーケットの急拡⼤ 39,100⼈ 221,100⼈
16. なぜ今 InnerSource なのか 16 01-Jan-94 01-Jan-95 01-Jan-96 01-Jan-97 01-Jan-98 01-Jan-99 01-Jan-00 01-Jan-01 01-Jan-02 01-Jan-03 01-Jan-04 01-Jan-05 01-Jan-06 01-Jan-07 01-Jan-08 01-Jan-09 01-Jan-10 01-Jan-11 01-Jan-12 01-Jan-13 01-Jan-14 01-Jan-15 01-Jan-16 01-Jan-17 01-Jan-18 01-Jan-19 01-Jan-20 01-Jan-21 01-Jan-22 39,100⼈ 221,100⼈ ⼤量のプロダクトと⼤量のチーム サイロが簡単にできてしまう状況
17. InnerSourceは、 企業⽂化や組織内部の制限を尊重しつつ、 オープンソースに似た内部のシェアリングエコノミーに向けて ⽂化的に変⾰し、組織のサイロを壊していく旅です 17
18. The InnerSource Commons Foundation InnerSource Commons は、InnerSourceの実践者の世界最⼤のコミュニティです。 組織という枠の中でソフトウェア開発にオープンソースのベストプラクティスを活⽤する InnerSourceに関するナレッジの創出と共有に特化しています。 2015年に設⽴された InnerSource Commons は、現在 750 以上の企業、学術機 関、政府機関から2000⼈以上の個⼈をサポートしつないでいます。 18
20. InnerSource とは 20
21. InnerSource の4つの原則 Openness - オープンなプロジェクト リポジトリのトップに置かれる README.md ファイルと CONTRIBUTING.md ファイルによって⼗分にドキュメント化され発⾒できるようになって いなければなりません。 Transparency - 透明性 プロジェクト/リポジトリとその⽅向性未解決の機能要件機能要件の進捗ホストチームの意思決事項を透明にします。 Prioritized Mentorship - 優先的なメンターシップ Trusted Committer によるホストチームからゲストチームへの優先的なメンターシップにより、ゲストチームの コントリビューター は、ホストチームの プロジェクト/リポジトリについて⼗分理解し、変更できるようにレベルアップされます。 Voluntary Code Contribution - ⾃発的なコードコントリビューション ゲストチームとホストのチームの両⽅からInnerSourceに参加することが、彼らの⾃由意志に基づいて⾏われること 21
22. InnerSource はエンジニアの共創を実現する鍵 22 XP ソースコードの共同所有 DevOps 組織のサイロを削減する Team Topologies チーム間の相互作⽤ Platfrom Engineering ⾞輪の再発明をしない InnerSource
23. InnerSourceは企業規模でチームとコードをつなぐ 23 DevOps DevOps DevOps Waterfall DevOps Kanban InnerSource InnerSource InnerSource InnerSource InnerSource InnerSource InnerSource InnerSource InnerSource
24. InnerSource を実現する 4 ポイント Discoverable - 発⾒可能である パートナーチームがコードベース、ドキュメント、およびその他の関連資料をすべて検索し、事前のドメイン知識なしでプロジェクトを探索すること Composable – 構成可能である パートナーチームがソースコードを迅速かつ簡単にコンパイルおよび実⾏できる、または別プロジェクトの⼀部としてソースコードを簡単に使⽤できる こと。カプセル化されており、即実⾏できる。 Contributable - 貢献可能である パートナーチームが問題を簡単に報告し、質問し、新しい機能を提案し、障壁なく前向きな⽅法でコミットをアップストリームすること Maintainable – 継続的維持が可能である チームがコードをメンテナンスし続けること 24
25. InnerSource Program Office - ISPO InnerSource Program Office (ISPO) は、InnerSourceを組織内で実現するための⼿段と環境を提供します。 プログラムオフィスは開発を促進しますが、開発部⾨やゲートキーパーではありません 主な役割 • InnerSource ⽅針の共有 • メンタリング / トレーニングの実施 • InnerSourceのアドバイザリー • インセンティブモデルの開発 • ⽀援活動の組織化 • 適切なツーリングの確保 (ex: BI Dashboard, InnerSource Portal, GrimoireLab – CHAOSS toolset) 25
26. InnerSource の推奨計測メトリクス リポジトリごとの状況の１ヶ⽉ごとの推移 • Contributor が複数いるリポジトリ数 • CONTRIBUTING.md の存在するリポジトリ数 • README.md が存在するリポジトリ数 • Fork の数 プルリクエスト数の推移 • 期中のプルリクエストの数* • チームを越えたプルリクエストの数 26 * 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%
27. InnerSource べースドキュメント の整備 • ドキュメントの整備 • 明確なマージ条件 • Issue, Pull Requestテンプレート • Issue, Pull Requestラベル • CODEOWNERS 27
28. プラクティス集 - InnerSource Patterns (⼀部) 28 ソフトウェアライフサイクル全体で参加型システムを作成し、デザインドキュメントを公開して早期のディスカッションを促進する。 30⽇の保証期間 社内兼業コントリビューター インナーソースライセンス インナーソースベースドキュメント インナーソースポータル インナーソースデザインドキュメント 基本原則ガイダンスの⽂書化 トラステッドコミッター コントリビューターが30⽇間のサポート付きでバグ修正や機能提案をすることで、両チームの信頼を向上させる。 ボランティアではなく、組織内で正式な契約と合意をすることによって、InnerSourceへの貢献を促す。 組織内でソースコードを共有するための法的枠組みを提供し、新たなコラボレーションオプションを提供する。 InnerSourceプロジェクト情報をインデックス化し、コントリビューターが興味を持つプロジェクトを発⾒しやすくする。 継続的なコントリビューターの仕事を認識し、報酬を与える⽅法を定義する 標準的なプロジェクトドキュメントを提供し、新規コントリビューターに⾃⼰サービスプロセスを提供する。 InnerSourceの主要原則を⽂書化し、広く公開する。 パターン名 パターンの概要
29. やってはいけない - InnerSource アンチパターン 29 ISPO の⽅針 対象プロジェクトの選定 マインドセット • ⾮継続的なプロジェクト • ⾃社の開発者がいない • 特定⽬的の複雑なソリューション • コードのエンドユーザーが開発者意外 • ⼈の働き⽅を決める • 新しい統制プロセスを追加 • コードベースのキュレーション • 新しいツールを⾃前で構築 • 新タイプのリポジトリを作成 • ⾃分のコードは⾃分のもの • 貢献は「気晴らし」である • ⾞輪の再発明 • 製品 = コード
30. ⼀⽅⽅向の共有 チームは単純に 完成した 部品を共有する 特定チーム間の 連携 チームにコントリビューショ ンが届く さまざまなチームと の⾃律的な協働 組織内で広く貢献を受けと る インナーソースのコラボレーション範囲と共有の考え⽅ 複雑で難しいが インパクトが⼤きい 始めるのに最適 Note: This documentation does not represent a formal GitHub position based on accounting, tax, or legal considerations. It is a list of items for each of the considerations as a starting point for discussion of the technical InnerSource adoption in the company. It is intended to be used as a reference document under the rules of the NDA. InnerSource Scope InnerSource Sharing Approach 30 社内 コラボレーション グループ内 コラボレーション 国際間 コラボレーション 社外を含めた コラボレーション
31. ⼀⽅⽅向の共有 チームは単純に 完成した 部品を共有する 特定チーム間の 連携 チームにコントリビューショ ンが届く さまざまなチームと の⾃律的な協働 組織内で広く貢献を受 けとる インナーソースのコラボレーション範囲と共有の考え⽅ 複雑で難しいが インパクトが⼤きい 始めるのに最適 Note: This documentation does not represent a formal GitHub position based on accounting, tax, or legal considerations. It is a list of items for each of the considerations as a starting point for discussion of the technical InnerSource adoption in the company. It is intended to be used as a reference document under the rules of the NDA. InnerSource Scope InnerSource Sharing Approach 31 社内 コラボレーション グループ内 コラボレーション 国際間 コラボレーション 社外を含めた コラボレーション 単⼀法⼈の場合、InnerSourceは チーム間の合意やコストセンターの調 整だけで InnerSource を実現でき る可能性があり、⾮常にシンプルで す。 ⽂化変⾰などの組織改⾰が必要で す 法⼈格の垣根を越える際の課題 • 知的財産権に関する問題 • 会計上の問題 • 税務上の問題 • 利益供与 会計上の問題は、グループの連結決 算の枠組み内での扱いにとどまりま す。 共通認識の確⽴の重要性 ヒント： • ソフトウェア権利の集中化でコラボ レーションの効率化を容易にする • 持株会社やソフトウェア専業会社 にソフトウェア権を集める 国際的な境界を越える際の課題 • 移転価格税制の問題点 • 業界標準のルールがない この分野の現状 • InnerSourceにおける移転価格 税制については、いくつかの論⽂ がある。 • 業界内の共通認識はまだ得られ ていません。 • ⼀般的に移転価格税制は、 OECDが制定した参考資料を参 照することが多いですが、ソフト ウェアに最適化されたものではあり ません。 • 類似事例の検索、アプローチのカ スタマイズ、企業独⾃のルール作 りなどが必要です。 通常、InnerSourceの⽬的は、企 業内の戦略的領域を共有し、技術 を再利⽤して競争⼒を⾼めることに あるため、資本関係や⼗分な資本 ⽐率を持たない企業間の協業は対 象外となることが多いです。 ⼀⽅、SDKや特定ライブラリなど、特 許や価値のある部分を隠すためにブ ラックボックス化された部品は、 InnerSourceを通じて共有すること が可能です。
32. GitHub Customer Success アドバイザリー #1 ⽂化醸造の熟成とGitHubのコラボ レーションに集中 モデルやライセンスを作成し、活動をス ケールさせる ⼩さなエリアから国際協⼒を始める 移転価格に関する社内規 程の整備（International InnerSource License） #2 #3 #4 社内コラボレーション グループ内コラボレーション 国際コラボレーション 国際コラボレーション Customer Success Offering • InnerSourceトレーニング（GitHub Collaboration) • InnerSourceプログラムオフィス設⽴⽀援 • InnerSourceプロジェクトおよびコミュニティ 構築⽀援 • サーバー統計など、インナーソース活性化に 関連するメトリクスの測定⽅法に関するア ドバイス Customer Success Offering • InnerSourceライセンスの構築を⽀援し、 ベストプラクティスを共に創るためのアドバイ ザリー • 会社のGitHubとInnerSourceのコミュニ ティの活性化⽀援 • InnerSourceプロジェクトを成功させるため のケース作りの⽀援 Customer Success Offering • 状況に応じてカスタムで提供します。 32
33. ⼀⽅⽅向の共有 チームは単純に 完成した 部品を共有する 特定チーム間の 連携 チームにコントリビューショ ンが届く さまざまなチームと の⾃律的な協働 組織内で広く貢献を受 けとる インナーソースのコラボレーション範囲と共有の考え⽅ Note: This documentation does not represent a formal GitHub position based on accounting, tax, or legal considerations. It is a list of items for each of the considerations as a starting point for discussion of the technical InnerSource adoption in the company. It is intended to be used as a reference document under the rules of the NDA. 33 社内 コラボレーション グループ内 コラボレーション 国際間 コラボレーション 社外を含めた コラボレーション R&D Entries IT資産管理のベストプラクティスを 適⽤して、会計項⽬における「ソフ トウェア」を共有する。 チームごとに労務管理・共有ルールを策 定します Software Entries グループ間の共有ルールを制定 移転価格税制に関するルールを制定 コストセンターのつけかたなど、管理⽅ 法について事前に打ち合わせを⾏い、調 整します InnerSourceライセンスとしてテンプ レートを作成することで、コラボ レーションが起こりやすくします InnerSourceの移転価格税制に関する ルールの組織的な⾒解について、特定 のプロジェクトに限った場合に共有範 囲は限定的である可能性があり、経理 部⾨と連携すれば⼗分な場合がありま す。 Innersource Program Offifceは、事例の Innersourceライセンス化、公式コーポ レートライセンスの開発を⽀援します InnerSourceライセンスとしてコラボ レーションをモデル化し、コストセン ターや共有ルールを各チームと毎回会 話する必要がないようにします IP利⽤ルールや利⽤制限、再利⽤可能 な部分のブラックボックス化などを考 慮する IP共有のルール設定、IPの限定された部分（使 ⽤SDKやライブラリなどのインターフェースの みを共有するなど、IPの価値ある部分や特許関 連部分を隠す）を共有するためのルールとベス トプラクティスを策定します。 移転価格税制に関するInnerSourceの ルールに対する⾃社の⾒解を整理し、 社内資料を作成します 社内のブラックボックス化を超えて⾃ 律的かつ柔軟な共有を⽬指す場合、 アーキテクチャを分割して共有項⽬の 範囲を再定義するなど、さらなる連携 のステップが必要です
34. ⼀⽅⽅向の共有 チームは単純に 完成した 部品を共有する 特定チーム間の 連携 チームにコントリビューショ ンが届く さまざまなチームと の⾃律的な協働 組織内で広く貢献を受 けとる インナーソースのコラボレーション範囲と共有の考え⽅ Note: This documentation does not represent a formal GitHub position based on accounting, tax, or legal considerations. It is a list of items for each of the considerations as a starting point for discussion of the technical InnerSource adoption in the company. It is intended to be used as a reference document under the rules of the NDA. 34 社内 コラボレーション グループ内 コラボレーション 国際間 コラボレーション 社外を含めた コラボレーション ステップ1：⽂化醸成とGitHubコラ ボの熟成に注⼒する ステップ#2.5：分離⾯の定義、アーキ テクチャとGitHub Collaborationの状 態の整理、SDKの定義を⾏う。 ステップ#2：モデルの作成、ライセンスの作成、 活動のスケールアップ ステップ#2.5：モデルの作成、ライセ ンスの作成、活動のスケールアップ ⼀般的に、共有はグループ内にとどまる必要がありますが、グループを 超えてインナーソーシングを⾏う必要がある場合は、早い段階でグルー プを超えてコラボレーションする⽅法を模索する必要があります ステップ#3：⼩さなエリアから国際 協⼒を始める ステップ#4：移転価格に関する社内 規則の策定（International InnerSource License） 34
35. サイロを取り除いた結果⽣まれること 35 個⼈や組織に影響 プロダクトに対して影響 可能性 最⼤化 コスト 削減 共創で 新しい価値/イノベーションを創出 組織全体の技術/知識共有で品質向上 チーム連携による、製品間のシナジー オープンで共創が⽣まれる開発⽂化育成 技術や知識共有によるスキルレベル向上 キャリア成⻑促進で、従業員満⾜度向上 社員の離職率の低下を促す 透明性拡⼤による効果的なリソース配分 組織のプロセス最適化 ⾞輪の再発明の防⽌で⽣産コスト削減 早期検出と対処容易化によるリスク低減
36. よくある誤解 36 GitHub を使ってるから InnerSourceできてるでしょ？ InnerSourceって、 内製化のことだよね InnerSourceは ツールを⼊れたらできるらしい
37. よくある誤解 InnerSourceって、内製化のことだよね 37 InnerSourceとは 企業内でオープンソース開発⼿法を活⽤すること* を表す⽤語として、 2000年にTim O’Reilly によって考案された⾔葉です。 もしかしたらあなたのお知り合いの⽅は以下の⾔葉とInnerSourceを混同しているかもしれません。 • インソーシング (アウトソーシングに対して) • インハウス化 (内製化) * “Inner-sourcing is the use of open source development techniques within the corporation.” by Tim O’Reilly in 2000
38. よくある誤解 GitHub を使ってるからInnerSourceはできてるでしょ？ 38 InnerSourceの実現には GitHub が必要だという意⾒は、私達が毎⽇戦っている概念です。 GitHub は組織におけるコードの透明性を上げますが、それだけで組織の縦割り問題が解決するわけで はありません。 ほとんどの⼈々は、GitHub の活⽤よりもはるかに⼤変なことに気づいていません。 それは、社内におけるオープンソースの源を⾒つけ、コミュニティとし て育ててゆくことなのです。 コミュニティがソフトウェアを作るのであって他の何者でもないのですが、 ⼤企業にはそれに気づくための全体的なコミュニティに対する センスがないのです。 From “Understanding the Innersource Checklist” by Silona Bonewald, the founding member of the InnerSource Commons.
39. よくある誤解 InnerSourceはツールを⼊れたらできるらしい 39 InnerSourceを実現する第⼀歩は、信頼を育むことと透明性のあるコミュニケーションを増やすことです。 これにより、新たな協働を引き起こして改善してゆくためのセンスを磨く機会が⽣まれるのです。 さて、我々はどうすれば良い意思決定と多くの協働をコストを抑えて実現 できるでしょうか？これこそがInnerSourceにできて GitHub にはできないことなのです。 GitHub のようなバージョン管理とコード検索のツールを使うこと⾃体は、InnerSourceの実現に向けた正 しい⽅向です。 ですが、ツールの良し悪しよりも⼈を考慮する必要があります。 企業は、⼈々の恐れ、習慣、定型作業、階級、動機によって形成されており、技術よりも社内の政治 的⼒学によって動いているのです From “Understanding the Innersource Checklist” by Silona Bonewald, the founding member of the InnerSource Commons.
40. InnerSource の整理 InnerSourceは、企業⽂化や組織内部の制限を尊重しつつ、オープンソースに似 た内部のシェアリングエコノミーに向けて⽂化的に変⾰し、組織のサイロを壊してい く旅 Why: 良い意思決定と多くの協働をコストを抑えて実現し、サイロ間の摩擦をなくすこと How: ⼈を考慮した⽂化を育み、社内でオープンソースの源を⾒つけ、コミュニティとして育てる What: 企業内でオープンソース開発⼿法を活⽤する 40