Developer Experience and InnerSource - エンジニアの共創は結局大企業では無理なのだろうか

Slide 1

Slide 1 text

#InnerSource aka.ms/iscslack #jp-general 1 エンジニアの共創は結局大企業では無理なのだろうか服部佑樹 @yuhattor Board Member, The InnerSource Commons Foundation Customer Success Architect, GitHub いや、むりでない

Slide 26

Slide 26 text

#InnerSource aka.ms/iscslack #jp-general Developer Experience (DevEx/DX) 人材の引きつけと定着 ➢ 世界中の優れたエンジニアは、素晴らしいブランドだけでなく、技術文化と高い従業員満足度がある優れたテクノロジー企業で働きたいと考えています。こうした企業では、開発者は彼らが得意とすること、すなわち先進的なツールを使用して優れたソフトウェアを構築することができます。生産性とコスト削減 ➢ ボイラープレート活動に費やす時間を減らすことで、アイデアから顧客の問題を解決するコードまでの時間を数ヶ月から数分に短縮することができます。このような生産性の向上はDXへの投資が必要ですが、その投資は高いROIを持っています。一貫性と品質 ➢ 開発者のための全体のツールスタックを標準化し、製品化することで、DXは向上し、デジタル製品の品質も向上します。さらに、容易に見つけて使用できるツールは、開発者が本当に重要な作業に集中することを可能にします。セキュリティとコンプライアンス ➢ セキュリティとコンプライアンスが最初からコンポーネントに組み込まれている場合、例えば、エンタープライズ全体のCI/CDパイプラインの一部としてセキュリティテストが行われる場合、コンプライアンスは箱から出した状態で既に満たされています。速度 ➢ チーム間のハンドオーバーや調整を減らし、早期の品質チェックによる再作業を排除し、生産へのパスを完全に自動化することで、開発者ははるかに速く進むことができます。これにより、数週間または数ヶ月に一度のデプロイメントではなく、1日に数回のデプロイメントが可能となります。 26 McKinsey 記事のサマリー

Slide 27

Slide 27 text

#InnerSource aka.ms/iscslack #jp-general 優れたDevExを確保するための10のステップユーザーに焦点を当てる : 開発者エクスペリエンスプラットフォームの最も重要な顧客は開発者です。プラットフォームを製品として扱う: DXプラットフォームを所有し、それを適応させる責任を持つ小さな中央チームを設立します。貢献モデルの分散化: 中央チームが開発を完全に所有するのはスケールしません。分散型の継続的な開発が可能な貢献モデルを確立する必要があります。成功を使用率で定義する: 成功の重要な指標は、プラットフォームへのトラフィックを生成し、開発者がそれを日常的に使用する能力です。影響を測定する: KPIを最初の日から測定します。例えば、Salesforceは顧客の問題を解決するコードに至るまでのプロセスの期間を、Spotifyは新しい開発者の生産性を測定します。既存の機能を最大限に活用する: 既に製品化され、採用されているツールを使用し、既存のチームがプラグインを介してプラットフォームに統合するのを支援します。最初の日から機能を構築する: この努力は、優れたプラットフォームエンジニアを集めることではなく、プラットフォームエンジニアリングの能力の重要な質量を築くことについてです。プラットフォームを布教する: エンジニアリング文化と習慣を促進し、DevOpsチーム内での採用を促進します。変化を管理する: DXは、技術だけでなく、プラットフォームの採用と使用をサポートするために必要なすべての前提条件にも関わっています。大きく考え、小さく行動する: プラットフォームが初日から価値を提供し、スケールするようにするため、MVPの範囲は最初の顧客またはユースケースに限定すべきです。 27 McKinsey 記事のサマリー

Slide 43

Slide 43 text

#InnerSource aka.ms/iscslack #jp-general インナーソース戦略のまとめ Developer Experience (非競争領域) のためのインナーソース差別化の競争戦略(競争領域) のためのインナーソース何をする開発文化を変え、DevEx を促進することでチームや開発体制の改善につなげる企業の差別化領域を拡大し、共創、シナジーからイノベーションを生む最大化人材の価値を最大化するプロダクト/技術の価値を最大化する誰のための戦略? 開発者のため (最終的に、企業の成長のため) 企業と部門のため戦略の狙い • 透明でコラボラティブな開発文化育成 • 技術や知識共有によるスキルレベル向上 • 従業員満足度向上と離職率の低下 • 車輪の再発明の防止で生産コスト削減 • 共創で新しい価値/イノベーションを創出 • 組織全体の技術/知識共有で品質向上 • チーム連携による、製品間のシナジー • 車輪の再発明の防止で生産コスト削減対象技術ドキュメンテーション, テンプレート, 共有ライブラリ, 社内ツール, ハッカソンプロジェクト特許技術, 知的財産, 競争のための OSS化領域, 競争優位性のある製品対象チームアプリケーション開発 / クラウドプラットフォーム開発 / DevOps チームなど R&D チーム / すでに競争優位性のあるプロダクトのチーム評価開発のベロシティ, コストダウンの実現, 従業員 (開発者) 満足度生まれた競争領域における共創の数, クロスチームプロジェクト/プロダクトによる利益トップダウンアプローチリーダー(CTO, BDM, 中間管理職) が開発組織の改善のために実施意志-危機感のあるリーダー (CTO, BDM, 中間管理職) が、企業や部門の利益最大化を狙い取り組むボトムアップアプローチ草の根で始まり得る (社内の技術インフルエンサー / 成長を望む社員) 競争領域であり、IP や利益供与、移転価格税制がセンシティブであり、草の根では始まりにくい会社や技術・プロダクトを愛し、変革したいと考える社員がリーダーに働きかける抵抗される理由多くの場合、大きなハレーションはない → 「人材」のための施策であり、プロダクト自体に大きな価値がないケースが多いプロダクトが大きな価値を産んだ瞬間、それは右の領域に移動する → 自分のチームの人材の価値を高めて中長期的に成長してもらうことはポジティブ直近で得られる効果に対して、法・税・会計の問題をクリアするハードルが高すぎる → 「プロダクトや技術の価値」を移動しようとしているの当然、問題はついて回る社員がチームを越えて貢献することを良しとしない中間管理職 → 「自分のプロダクト/技術価値」にフォーカスがあり、その成長を妨げる行動にネガティブなのは当然 43

Slide 54

Slide 54 text

一方方向の共有チームは単純に完成した部品を共有する特定チーム間の連携チームにコントリビューションが届くさまざまなチームとの自律的な協働組織内で広く貢献を受けとるインナーソースのコラボレーション範囲と共有の考え方複雑で難しいがインパクトが大きい始めるのに最適 InnerSource Scope InnerSource Sharing Approach 54 社内コラボレーショングループ内コラボレーション国際間コラボレーション社外を含めたコラボレーション単一法人の場合、InnerSourceはチーム間の合意やコストセンターの調整だけで InnerSource を実現できる可能性があり、非常にシンプルです。文化変革などの組織改革が必要です法人格の垣根を越える際の課題 • 知的財産権に関する問題 • 会計上の問題 • 税務上の問題 • 利益供与会計上の問題は、グループの連結決算の枠組み内での扱いにとどまります。共通認識の確立の重要性ヒント： • ソフトウェア権利の集中化でコラボレーションの効率化を容易にする • 持株会社やソフトウェア専業会社にソフトウェア権を集める国際的な境界を越える際の課題 • 移転価格税制の問題点 • 業界標準のルールがないこの分野の現状 • InnerSourceにおける移転価格税制については、いくつかの論文がある。 • 業界内の共通認識はまだ得られていません。 • 一般的に移転価格税制は、 OECDが制定した参考資料を参照することが多いですが、ソフトウェアに最適化されたものではありません。 • 類似事例の検索、アプローチのカスタマイズ、企業独自のルール作りなどが必要です。通常、InnerSourceの目的は、企業内の戦略的領域を共有し、技術を再利用して競争力を高めることにあるため、資本関係や十分な資本比率を持たない企業間の協業は対象外となることが多いです。一方、SDKや特定ライブラリなど、特許や価値のある部分を隠すためにブラックボックス化された部品は、 InnerSourceを通じて共有することが可能です。

Slide 55

Slide 55 text

一方方向の共有チームは単純に完成した部品を共有する特定チーム間の連携チームにコントリビューションが届くさまざまなチームとの自律的な協働組織内で広く貢献を受けとるインナーソースのコラボレーション範囲と共有の考え方 55 社内コラボレーショングループ内コラボレーション国際間コラボレーション社外を含めたコラボレーション R&D Entries IT資産管理のベストプラクティスを適用して、会計項目における「ソフトウェア」を共有する。チームごとに労務管理・共有ルールを策定します Software Entries グループ間の共有ルールを制定移転価格税制に関するルールを制定コストセンターのつけかたなど、管理方法について事前に打ち合わせを行い、調整します InnerSourceライセンスとしてテンプレートを作成することで、コラボレーションが起こりやすくします InnerSourceの移転価格税制に関するルールの組織的な見解について、特定のプロジェクトに限った場合に共有範囲は限定的である可能性があり、経理部門と連携すれば十分な場合があります。 Innersource Program Offifceは、事例の Innersourceライセンス化、公式コーポレートライセンスの開発を支援します InnerSourceライセンスとしてコラボレーションをモデル化し、コストセンターや共有ルールを各チームと毎回会話する必要がないようにします IP利用ルールや利用制限、再利用可能な部分のブラックボックス化などを考慮する IP共有のルール設定、IPの限定された部分（使用SDKやライブラリなどのインターフェースのみを共有するなど、IPの価値ある部分や特許関連部分を隠す）を共有するためのルールとベストプラクティスを策定します。移転価格税制に関するInnerSourceのルールに対する自社の見解を整理し、社内資料を作成します社内のブラックボックス化を超えて自律的かつ柔軟な共有を目指す場合、アーキテクチャを分割して共有項目の範囲を再定義するなど、さらなる連携のステップが必要です

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Slide 38

Slide 38 text

Slide 39

Slide 39 text

Slide 40

Slide 40 text