Upgrade to Pro — share decks privately, control downloads, hide ads and more …

組織のサイロを打破する!エンジニアがオーナーシップを持って共創する開発プロセス「インナーソース」

 組織のサイロを打破する!エンジニアがオーナーシップを持って共創する開発プロセス「インナーソース」

このセッションでは、組織のサイロを打破してエンジニアが幸せにコラボレーションするための考え方である "インナーソース" について紹介します。

サイロ化した組織においてはコラボレーションが困難となり車輪の再発明が繰り返されることになってしまいます。そんな組織ではソースコードの共有やオーナーシップ確立が不十分であるため、コードの管理やメンテナンスに関する情報が不透明になっていることでしょう。

これらの課題に対処するため、アメリカやヨーロッパの大手企業が2015年から取り組み始めた活動が インナーソース です。この取り組みは、オープンソースのコラボレーションモデルを企業内に導入することで、エンジニアたちが風通しの良い環境で働けるようにし、エンジニア文化や組織の改善を促すものです。

インナーソースが実践されているのは Microsoft や Adobe などの Tech企業だけにとどまらず、ボッシュやシーメンス、鉄道や通信大手の企業がどんどん採用しています。このセッションでは、 インナーソース の考え方や、基本的なロール・プラクティスに触れつつ、 インナーソース戦略の各社の採用状況や事例についてご紹介します。

Outline/Structure of the Talk
本セッションでは、インナーソースについて解説したのち、海外の成功事例や、彼らが取り入れたインナソースにおける最重要ロールであるトラステッドコミッターについて紹介していきます。

セッションの最後には、AI時代における将来のエンジニアコラボレーションに関しても触れたいと思います。

組織がサイロ化し、コラボレーションが困難になる問題について
オープンソースのコラボレーションモデルを企業内に導入する方法: インナーソース
PayPal や Nike なども採用しているインナーソースにおける最重要ロール: トラステッドコミッター
インナーソースのプラクティスをまとめた インナーソースパターン
AI 時代にかわる (かもしれない) エンジニアのコラボレーション、企業はどう対応すべきか
Learning Outcome
企業におけるサイロ化やコラボレーションの問題を解決するヒントを得られます
インナーソースとは何かについて理解し、プラクティスと成功事例を知ることができます。
オープンソースのコラボレーションモデルを企業内に導入する方法について学ぶことができます
このセッションがエンジニア文化の改善についてのきっかけになれば幸いです。

Target Audience
車輪の再発明をなくしたい全てのエンジニア、組織のサイロに悩むリーダー、風通しの良いエンジニア文化を作りたい全ての人

Prerequisites for Attendees
特にありません。

Links
【動画】
インナーソースについて: https://www.youtube.com/watch?v=NJcj8UHC1PY
内製化の一歩先を見つめるコードの共同所有の取り組み: https://www.youtube.com/watch?v=Cr1TXHZ1KE8
GitHubを活用した組織でのインナーソース推進方法: https://www.youtube.com/watch?v=aOnbCecj1QI

【資料】
インナーソース入門: https://speakerdeck.com/yuhattor/innasosuru-men-qi-ye-niokerukoraboresiyontosheng-chan-xing-wogao-merumi-jue-54e823d9-9fdf-4acc-ae30-ef961b00a13a
インナーソースパターン: https://patterns.innersourcecommons.org/v/ja/

Yuki Hattori

April 18, 2023
Tweet

More Decks by Yuki Hattori

Other Decks in Technology

Transcript

  1. #InnerSource aka.ms/iscslack #jp-general The InnerSource Commons Foundation InnerSource Commons は、InnerSourceの実践者の世界最⼤のコミュニティです。

    組織という枠の中でソフトウェア開発にオープンソースのベストプラクティスを活⽤する InnerSourceに関するナレッジの創出と共有に特化しています。 2015年に設⽴された InnerSource Commons は、現在 750 以上の企業、学術機 関、政府機関から2000⼈以上の個⼈をサポートしつないでいます。 2
  2. #InnerSource aka.ms/iscslack #jp-general DevOps とはなにか 6 “DevOps とは 開発チームと運⽤チームの コラボレーションのことだ”

    “DevOps とは IaC を扱うことだ” “DevOps とは ⾃動化することだ” “Ops 向けの Kanbanのこと?” “DevOps とは ⽂化のことだ” “DevOps とは ⼩さなデプロイを 繰り返すことだ”
  3. #InnerSource aka.ms/iscslack #jp-general Patrick Debois ⽒: DevOps とは サイロ間の摩擦を取り除くこと Since

    the term was first coined, I’ve settled on my own definition of “DevOps”: everything you do to overcome the friction between silos. 7
  4. #InnerSource aka.ms/iscslack #jp-general DevOps が扱う5つの領域 Reduce organizational silos - 組織のサイロを削減する

    Accept failure as normal - エラーが発⽣するのを前提とする Implement gradual change - 段階的に変更する Leverage tooling and automation - ツールと⾃動化を活⽤する Measure everything - 全てを計測する 8
  5. #InnerSource aka.ms/iscslack #jp-general なぜ今 InnerSource なのか 13 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⼈
  6. #InnerSource aka.ms/iscslack #jp-general なぜ今 InnerSource なのか 14 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⼈ ⼤量のプロダクトと⼤量のチーム サイロが簡単にできてしまう状況
  7. #InnerSource aka.ms/iscslack #jp-general 経済の状況: 景気後退 グローバル • コスト削減 - 被っているプロダクト・機能の統合

    • 成熟したプロダクトおよび組織の最適化 • 肥⼤化・サイロ化した組織の単純化 ⽇本 • 引き続きエンジニア不⾜ / 少⼦⾼齢化 • 業界の多重請負構造は硬直したまま • (ようやく) 企業は少しずつ内製化 💪 ⾵通しの良い⽂化と、コスト削減、新しい価値の創造の必要性 15
  8. #InnerSource aka.ms/iscslack #jp-general InnerSource の4つの原則 Openness - オープンなプロジェクト リポジトリのトップに置かれる README.md

    ファイルと CONTRIBUTING.md ファイルによって⼗分にドキュメント化され発⾒できるようになって いなければなりません。 Transparency - 透明性 プロジェクト/リポジトリとその⽅向性未解決の機能要件機能要件の進捗ホストチームの意思決事項を透明にします。 Prioritized Mentorship - 優先的なメンターシップ Trusted Committer によるホストチームからゲストチームへの優先的なメンターシップにより、ゲストチームの コントリビューター は、ホストチームの プロジェクト/リポジトリについて⼗分理解し、成功裏に変更できるようにレベルアップされます。 Voluntary Code Contribution - ⾃発的なコードコントリビューション ゲストチームとホストのチームの両⽅からInnerSourceに参加することが、彼らの⾃由意志に基づいて⾏われること 18
  9. #InnerSource aka.ms/iscslack #jp-general InnerSourceは企業規模でチームとコードをつなぐ 20 DevOps DevOps DevOps Waterfall DevOps

    Kanban InnerSource InnerSource InnerSource InnerSource InnerSource InnerSource InnerSource InnerSource InnerSource
  10. #InnerSource aka.ms/iscslack #jp-general サイロを取り除いた結果⽣まれること 21 個⼈や組織に影響 プロダクトに対して影響 可能性 最⼤化 コスト

    削減 共創で 新しい価値/イノベーションを創出 組織全体の技術/知識共有で品質向上 チーム連携による、製品間のシナジー オープンで共創が⽣まれる開発⽂化育成 技術や知識共有によるスキルレベル向上 キャリア成⻑促進で、従業員満⾜度向上 社員の離職率の低下を促す 透明性拡⼤による効果的なリソース配分 組織のプロセス最適化 ⾞輪の再発明の防⽌で⽣産コスト削減 早期検出と対処容易化によるリスク低減
  11. #InnerSource aka.ms/iscslack #jp-general よくある誤解 InnerSourceって、内製化のことだよね 23 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
  12. #InnerSource aka.ms/iscslack #jp-general よくある誤解 GitHub を使ってるからInnerSourceはできてるでしょ? 24 InnerSourceの実現には GitHub が必要だという意⾒は、私達が毎⽇戦っている概念です。

    GitHub は組織におけるコードの透明性を上げますが、それだけで組織の縦割り問題が解決するわけで はありません。 ほとんどの⼈々は、GitHub の活⽤よりもはるかに⼤変なことに気づいていません。 それは、社内におけるオープンソースの源を⾒つけ、コミュニティとし て育ててゆくことなのです。 コミュニティがソフトウェアを作るのであって他の何者でもないのですが、 ⼤企業にはそれに気づくための全体的なコミュニティに対する センスがないのです。 From “Understanding the Innersource Checklist” by Silona Bonewald, the founding member of the InnerSource Commons.
  13. #InnerSource aka.ms/iscslack #jp-general よくある誤解 InnerSourceはツールを⼊れたらできるらしい 25 InnerSourceを実現する第⼀歩は、信頼を育むことと透明性のあるコミュニケーションを増やすことです。 これにより、新たな協働を引き起こして改善してゆくためのセンスを磨く機会が⽣まれるのです。 さて、我々はどうすれば良い意思決定と多くの協働をコストを抑えて実現 できるでしょうか?これこそがInnerSourceにできて

    GitHub にはできないことなのです。 GitHub のようなバージョン管理とコード検索のツールを使うこと⾃体は、InnerSourceの実現に向けた正 しい⽅向です。 ですが、ツールの良し悪しよりも⼈を考慮する必要があります。 企業は、⼈々の恐れ、習慣、定型作業、階級、動機によって形成されており、技術よりも社内の政治 的⼒学によって動いているのです From “Understanding the Innersource Checklist” by Silona Bonewald, the founding member of the InnerSource Commons.
  14. #InnerSource aka.ms/iscslack #jp-general InnerSource を実現する 4 ポイント Discoverable - 発⾒可能である

    パートナーチームがコードベース、ドキュメント、およびその他の関連資料をすべて検索し、事前のドメイン知識なしでプロジェクトを探索すること Composable – 構成可能である パートナーチームがソースコードを迅速かつ簡単にコンパイルおよび実⾏できる、または別プロジェクトの⼀部としてソースコードを簡単に使⽤できる こと。カプセル化されており、即実⾏できる。 Contributable - 貢献可能である パートナーチームが問題を簡単に報告し、質問し、新しい機能を提案し、障壁なく前向きな⽅法でコミットをアップストリームすること Maintainable – 継続的維持が可能である チームがコードをメンテナンスし続けること 28
  15. #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) 29
  16. #InnerSource aka.ms/iscslack #jp-general InnerSource の推奨計測メトリクス リポジトリごとの状況の1ヶ⽉ごとの推移 • Contributor が複数いるリポジトリ数 •

    CONTRIBUTING.md の存在するリポジトリ数 • README.md が存在するリポジトリ数 • Fork の数 プルリクエスト数の推移 • 期中のプルリクエストの数* • チームを越えたプルリクエストの数 30 * 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%
  17. #InnerSource aka.ms/iscslack #jp-general プラクティス集 - InnerSource Patterns (⼀部) 32 ソフトウェアライフサイクル全体で参加型システムを作成し、デザインドキュメントを公開して早期のディスカッションを促進する。

    30⽇の保証期間 社内兼業コントリビューター インナーソースライセンス インナーソースベースドキュメント インナーソースポータル インナーソースデザインドキュメント 基本原則ガイダンスの⽂書化 トラステッドコミッター コントリビューターが30⽇間のサポート付きでバグ修正や機能提案をすることで、両チームの信頼を向上させる。 ボランティアではなく、組織内で正式な契約と合意をすることによって、InnerSourceへの貢献を促す。 組織内でソースコードを共有するための法的枠組みを提供し、新たなコラボレーションオプションを提供する。 InnerSourceプロジェクト情報をインデックス化し、コントリビューターが興味を持つプロジェクトを発⾒しやすくする。 継続的なコントリビューターの仕事を認識し、報酬を与える⽅法を定義する 標準的なプロジェクトドキュメントを提供し、新規コントリビューターに⾃⼰サービスプロセスを提供する。 InnerSourceの主要原則を⽂書化し、広く公開する。 パターン名 パターンの概要
  18. #InnerSource aka.ms/iscslack #jp-general やってはいけない - InnerSource アンチパターン 33 ISPO の⽅針

    対象プロジェクトの選定 マインドセット • ⾮継続的なプロジェクト • ⾃社の開発者がいない • 特定⽬的の複雑なソリューション • コードのエンドユーザーが開発者意外 • ⼈の働き⽅を決める • 新しい統制プロセスを追加 • コードベースのキュレーション • 新しいツールを⾃前で構築 • 新タイプのリポジトリを作成 • ⾃分のコードは⾃分のもの • 貢献は「気晴らし」である • ⾞輪の再発明 • 製品 = コード
  19. #InnerSource aka.ms/iscslack #jp-general みんな気になること: スーパーAI の到来 🤖 ⽣成AI の隆盛: ⽣き延びるための戦いになった

    •エンジニアの開発が変わる •チームの開発も変わる •組織/プロジェクト/プロダクトの開発もかわる 35
  20. #InnerSource aka.ms/iscslack #jp-general 個⼈の開発が変わる GitHub Copilot の活躍領域の例 37 ⾃然⾔語 ロー

    コンテキスト コメント ot Code (テンプレーティングを含む) ドキュメント to Code (設計ドキュメント) コメント to Code (リファクタリング / 微調整) コーディング ⽇々のコーディングの補完 専⾨技術/ハイコンテキストな領域に おけるコーディング⽀援 調査 / デバッグ / 最適化 デバッグ / リファクタリング ハイ コンテキスト
  21. #InnerSource aka.ms/iscslack #jp-general ⽇々のエンジニアリング効率化で⼤幅な時間節約は可能 コメント ot Code /⽇々のコーディングの補完 / 繰り返し

    / 定型的な作業 などのコーディング業務および、 それらの作業の中での ドキュメントリーディング / 検索の時間を短縮可能 コンテキストがすべて ビジネスやプロジェクト・設計に関するコンテキスト: 背後にある事柄や⼈間関係・規制の把握 技術的なコンテキスト: フレームワークやライブラリ、現在のファイル内の変数、関連ファイルやスコープなどの要因 経験や知識が豊富な開発者はさらにブーストされる AI からの提案を評価する能⼒、AI に⽂脈にあった指令を出せる開発者は有利 38 個⼈の開発が変わる GitHub Copilot は魔法のようだが、スキルも必要
  22. #InnerSource aka.ms/iscslack #jp-general • 裏で .csv を開いているだけで⼀瞬でコード化 • ビジネスサイドも PowerPoint

    や Excel ではなく Markdown や csv で保持する必要性 39 個⼈の開発が変わる ⇨ 組織の開発も変わらなければいけない 精度の⾼い提案のためには、AI が読めるファイルである必要がある。 参考DB 厚⽣労働省 「シームレスな健康情報活⽤基盤実証事業」 地域連携システム https://www.mhlw.go.jp/seisakunitsuite/bunya/kenkou_iryou/iryou/johoka/johokatsuyou/dl/tenpu03_06.pdf
  23. #InnerSource aka.ms/iscslack #jp-general 40 組織の開発も変わらなければいけない GitHub Copilot X = AI

    がエディタを⾶び出す = 開発プロセスにAIが⼊る GitHub Copilot for PR GitHub Copilot for Docs GitHub Copilot for PR
  24. #InnerSource aka.ms/iscslack #jp-general • 開発者個⼈の環境に AI が介在する • 開発プロセスの中に、AI が介在する

    • AI が読める内容を、AI がアクセスできる場所に格納する必要性 41 Copilot との協業はエンジニアだけにとどまらない チームとしてドキュメントドリブンな開発ができる組織が有利 Markdown, CSV などでコードと⼀緒に格納可能であると有利
  25. #InnerSource aka.ms/iscslack #jp-general 1. 特定機能向けの AI 開発は、未来の LLM によって簡単に上 書きされる可能性がある。

    2. 企業は “エコシステム” に AI を埋め込む戦いをしている 例: • 業界の既存のプロセスの中に埋め込む • 既存顧客の習慣の中に埋め込む • 法規制が絡み、簡単には壊せない優位性のある領域… 43 LLM の進化により、世の中の⽅向が変わった
  26. #InnerSource aka.ms/iscslack #jp-general 企業が守るべきプロプライエタリな領域 • 単体開発の機能の多くは GPT-5 や GPT-6 /

    マルチモーダルAI にふっ⾶ ばされる。 • コンテキストや、業界の既存のプロセスの中に埋め込む既存顧客の習慣 の中に埋め込む法規制が絡み、簡単には壊せない優位性のある領域や、 特許を含む企業秘密の領域を守り、育て、シナジーで拡⼤する必要があ る。 今こそ組織として、壁を壊して、⼀丸にならなければいけない。 44
  27. #InnerSource aka.ms/iscslack #jp-general DevOps はサイロ間の摩擦を取り除くこと。 サイロ間の摩擦を取り除くために、 InnerSource を実践しよう!! InnerSource は企業の⽂化変⾰の旅。

    ⼈を考慮した⽂化を育み、社内でオープンソースの源を⾒つけ、コミュニティとして育てよう AI で世界は変わった。 あなたの企業の競争⼒の源泉をコードに埋め込み、シナジーを⽣み出し、エコシステムを強化しよう 46 Key Takeaways