InnerSource Learning Path - インナーソースで始める組織内オープンソース開発入門＆実践 -

Slide 1

Slide 1 text

1 小林良岳 (Yoshitake KOBAYASHI) Toshiba Corporation / InnerSource Commons Email: [email protected] InnerSource Learning Path インナーソースで始める組織内オープンソース開発入門＆実践 InnerSource Commons Community Talk

Slide 2

Slide 2 text

2 自己紹介小林良岳 Yoshitake KOBAYASHIInnerSource Commons Japan

Slide 3

Slide 3 text

3 はじめに： InnerSourceを始めたモチベーション似たようなことをするなら一緒に解決したい！内向きなモチベーション興味日本の企業文化を変えたい！外向きなモチベーション危機感社会と組織を変革する

Slide 4

Slide 4 text

4 4 本日の Takeaway ● InnerSource の基本 ● 立ち回り方のヒントとベネフィット ● 実践事例からの気づき

Slide 5

Slide 5 text

5 5 発表の流れ 01 InnerSource とは？ 02 03 04 05 InnerSourceに参加してみよう InnerSourceプロジェクトのまとめ役になろうプロダクトオーナーとしての立ち回り InnerSource の実践

Slide 6

Slide 6 text

6 6 01 InnerSource とは？

Slide 7

Slide 7 text

7 1-1 こんな経験はありませんか？ ● 一緒にやってるプロジェクトで他チームを待っていたら遅れた・・・ ● バグを見つけて、通知したのに何時まで経っても直らない・・・ ● 似たような機能を作ってしまい、両方メンテナンスしないといけない・・・

Slide 8

Slide 8 text

8 1-1 こんな経験はありませんか？ APIを使いたい！同じ会社にある二つのチームが、別々のソフトウェア部品を提供する時、あるチームのソフトウェアが、もう一方のチームのソフトウェアに依存する状況例：表示用データを取得するAPIに依存するサービスケースチームチーム利用提供どうしてもリクエストが届かない場合どうするか？チームごとに事情は異なる・機能の優先度・開発スケジュールなど直ぐには提供出来ない！表示データ提供API （未実装）データ表示サービス

Slide 9

Slide 9 text

9 1-1 こんな時、あなたならどうしますか？１. 「静観」：黙っている３. 「圧力」：上層部を通してやらせるデメリットメリット・圧力という開発に関係のない作業に注力しなければならない・何度も使えるものでもなく発展しない・チーム間や個人間の信頼を損なう必要な機能が手に入る (かもしれない) ２. 「回避」：勝手にやるデメリットメリット・成果は同じ機能を必要としている他の利用者に提供されない・本来の役割範疇でないコードを長期的にメンテナンスしなければならない・会社全体として、同じ課題に対する重複したプロジェクトとコードを取得してしまう要求機能が足りない部分をローカルに変更・機能追加して補なえるデメリットメリット・要求された機能がいつまでたっても提供されない作業を最小限にすることができる

Slide 10

Slide 10 text

10 1-2 InnerSource なら、まとめて解決できます！ InnerSource を使うと全ての欠点を解決し、効果が得られる・・・でも、そもそも InnerSource って？ ● 共通課題に対する解決方法を共有して再利用することで、組織が価値創出に集中できるようになる！ ● 新しい技術が学べる！ ● 一緒に楽しく仕事をする事ができる！

Slide 11

Slide 11 text

11 1-2 InnerSource とは？ ● 企業内の活動にオープンソース実践とベストプラクティスと原則を適用したものです。 ● InnerSource ソフトウェアは、会社として守る資産ですが、内部にはオープンで、誰もが利用したり貢献したりできるようになります。 Dirk Riehle, Inner Source (Software Development), InnerSource Summit 2018 ・・・を企業内で実践することです。 Welcome visitors! Open all artifacts! つまり・・・

Slide 12

Slide 12 text

12 目指す姿サイロを取り払い、コラボレーションが各所で発生！ 1-2 InnerSource で目指す姿今までサイロごとに閉じている何をしているか自部門以外のことは知らない

Slide 13

Slide 13 text

13 1-3 どのように InnerSource は機能するのか？ケースチーム A チーム B 機能を使いたい！期限内に実装して Bチームにリリースすることはできない・・・ゲストホスト Aチームが提供するソフトウェアをBチームが利用する場合「コントリビューション」をします！利用提供

Slide 14

Slide 14 text

14 1-3 InnerSource における役割コントリビュータートラステッドコミッタープロダクトオーナーチーム B 〔ゲスト〕チーム A 〔ホスト〕ホストチームを代表。コントリビューターが正しく貢献するために必要な指導やサポートをタイムリーに提供さばき役。ゲストをサポートするホストチームの家長的存在。受け入れるコントリビューションがどの機能かを決定受け入れられるモノを仕分けする別チームの一員。ホストチームにコード等を投稿。

Slide 15

Slide 15 text

15 コントリビューターをサポート 1-3 InnerSource における役割コントリビュータートラステッドコミッタープロダクトオーナー要求する機能を実装して送信トラステッドコミッターとコミュニケーションしながら、コードを実装・改善するコントリビューションされたものが受け入れ可能な機能かどうかを判断サポートジャッジチーム B 〔ゲスト〕チーム A 〔ホスト〕

Slide 16

Slide 16 text

16 1-4 InnerSource のメリットチーム B 〔ゲスト〕チーム A 〔ホスト〕オープンな場で共通課題の解決策を共有できることは、会社にとっても有効より良い拡張性やサービスを顧客に提供することができる長期的にメンテナンスする責務を負うことなく、必要とする時間までに機能を入手できる

Slide 17

Slide 17 text

17 1-4 InnerSource のメリット・ニーズが確定している機能を受け取れるので、良いプロダクトを作るための支援となる長期メンテナンスの負担をせず、必要な時に機能要求を手に入れられる・スケーラブルな戦略ができるようになる・必要とする時と場所にエンジニアリングの時間を有機的に投入することが可能・全ての利用者との間で優先順位の調整を行うことができる品質向上会社リソース配分を最適化できる余力ができ、他へ注力できる必要な機能が手に入るチーム B 〔ゲスト〕チーム A 〔ホスト〕必要な機能が手に入る要求X OK! 要求Y 要求Z 機能X 機能Y 機能Z 開発の利点戦力倍増する

Slide 18

Slide 18 text

18 1-4 InnerSource のメリット当事者の利点ポジティブなFBの繰り返しでポジティブなFBの繰り返しでトレーニングや教育にもなるコントリビュータートラステッドコミッター従来の会社のサイロがなくなる仕事への満足度が高くなるプロジェクト全体をより理解できるプロジェクトを理解している人が増える同僚や新しいチームに参加を推奨するホストチームの負担が軽減するようになるプロジェクトに貢献する人が増え、アイデアが自然に融合し生まれる

Slide 19

Slide 19 text

19 1-5 InnerSource での役割と心構え自宅にお客様を招くような・・・チーム B ゲストチーム A ホスト物事が整理整頓されていることを保証（居心地のいい環境を提供）家のルールに従いながら、設備などを利用させてもらう

Slide 20

Slide 20 text

20 1-6 InnerSource の原則オープン性 → 透明性 → 常にドアが解放されていて、受け入れ可能な状態意思決定プロセス、コード、ToDoなどが見えるようになってる状態 (ゲストに対して) ありとあらゆるサポートを惜しまない共通の課題意識に基づき、お互いに協力する優先的なメンターシップ → 自発的なコードコントリビューション → オープンな場で、誰もが目的のプロジェクトを見つけられるようにする

Slide 21

Slide 21 text

21 21 1-7 ここまでのまとめ ● InnerSource は、企業内のソフトウェア開発にオープンソースのベストプラクティスと原則を適用したものです。 ● これは、提供側のチームが必要な機能要件を提供することができない時に、利用者に追加オプションを提供するものです。 ● InnroSource の成功には、「ホストチーム」のプロダクトオーナーとトラステッドコミッター、そして「ゲストチーム」のコントリビューターが関わります。 ● 効果的に行うと、InnerSource は両方の参加チームに多くの効果をもたらします。 ● 効果的な InnerSource 実施の主要な原則は、オープン性、透明性、自発的なコードコントリビューションと優先的なメンターシップです。オープンにコラボレーションすることで楽しみながら戦力を倍増すること！

Slide 22

Slide 22 text

22 22 02 参加してみよう【コントリビューター】

Slide 23

Slide 23 text

23 2-1 InnerSource における役割コントリビュータートラステッドコミッタープロダクトオーナーチーム B 〔ゲスト〕チーム A 〔ホスト〕ホストチームを代表。コントリビューターが正しく貢献するために必要な指導やサポートをタイムリーに提供さばき役。ゲストをサポートするホストチームの家長的存在。受け入れるコントリビューションがどの機能かを決定受け入れられるモノを仕分けする別チームの一員。ホストチームにコード等を投稿。インナーソースには3つの役割があります。ここからはコントリビューターの話をします。もうひとつ重要なことは共通の課題！まずは、それについて話していきましょう。コントリビューター

Slide 24

Slide 24 text

24 開発視点 2-1 共通の課題(一般的な課題)とは何か？共通課題発見の起点になりそうなもの • 共通サービス • ○○プラットフォーム • ○○フレームワーク • ミドルウェア • ライブラリ • ツール • 開発環境 • ドキュメント • 組織横断活動・プロジェクト • ボトムアップ活動 • (公認・非公認によらず) 社内○○コミュニティコミュニティ視点

Slide 25

Slide 25 text

25 2-1: こんな経験はありませんか？〔再掲〕 ● 一緒にやってるプロジェクトで他チームを待っていたら遅れた・・・ ● バグを見つけて、通知したのに何時まで経っても直ってこない・・・ ● 似たような機能を作ってしまい、両方メンテナンスしないといけない・・・

Slide 26

Slide 26 text

26 2-1 共通の課題(一般的な課題)とは何か？なにかを作ろうとするとき・・・「なにか似たことを考えている人はいないかな？」と探してみると言っても・・・コントリビューションするモチベーションは何だろう？ ● 作る前に ● 考えていることを共有して ● 似たことを考えていたり、やっていたりする人がいないか見つけてみるつまり・・・

Slide 27

Slide 27 text

27 2-1 皆さんも、このような事を考えるのでは… それぞれのプロジェクトの進行ペースが違うよね !? 前にも伝えたのに、誰も動かなかったよ！使おうとしたけど、バグばかりで使えなかったよ …（誰も直してくれないよ…） InnerSource のプロジェクトではソースコードをチェックアウトして変更を加え、改良したバージョンを利用する自由があるんです！ InnerSource そこで・・・

Slide 28

Slide 28 text

28 2-1 コントリビューターになってみよう！プロジェクトのコピーを作成して、そこに変更を加えて、自分の手元に置く ! 確かに、仕事は終わるけれど・・・コピーしたコードをメンテナンスし、ホストチームが作成する新しいリリースのいずれにも、その変更を追随させないといけないメリット InnerSource の自由を間違えると、こんな問題を抱えてしまう！デメリット

Slide 29

Slide 29 text

29 2-1 コントリビューターになってみよう！自由に直せるのであれば、チェックアウト元に直接変更を加えよう！第3の解決策があることを認識するマインドセットを変える • 機能やバグの修正を待つ代わりに・・・ • 問題を回避する代わりに・・・ • InnerSourceプロジェクトでニーズを確認 • 共有されたプロジェクトに直接変更を加えますそこで！

Slide 30

Slide 30 text

30 2-1 コントリビューターになってみよう！チェックアウト元に直接変更を加える行為をするのがコントリビューターです！コントリビューターになれば、こんなメリットがあります！ • チェックアウト元のプロジェクトの専門家らから、より深い知識が得られる！ • 本番でしか明らかにならないようなパッチの問題が早く明らかになって品質も上がる！

Slide 31

Slide 31 text

31 2-1 どんなことがコントリビューションできる？ ⚫ コンポーネントやコード、サービス利用時の問題報告 ⚫ 問題を再現するためのテストケース ⚫ バグのトリアージの支援 ⚫ ビルドの改善 ⚫ ドキュメントの改善 ⚫ 他のユーザのサポート ⚫ 使っていることの報告どんなことでも、ノウハウを共有するのは正しいコントリビューション！

Slide 32

Slide 32 text

32 2-2 コントリビューターの心構え物事が整理整頓されていることを保証機能や設備を利用することができ、従うべきいくつかの家のルールがあるチーム B ゲストチーム A ホスト物事が整理整頓されていることを保証チーム A ホストそれから、自分を売り込もう！ソースコードを、どのようにコントリビューションすればよいか確認しよう • ドキュメントがあれば、それを確認 • 情報が不足している時は、問い合わせできそうな人 (トラステッドコミッター) に確認

Slide 33

Slide 33 text

33 2-2 コントリビューターになるときの ”考え方ポイント” 「何か見つけたら」コントリビューションしてみよう！と考えてみる 1 2 コントリビューションの過程は、オープンにする 3 コメントをもらったら感謝する 4 もし、受け入れてもらえない時は・・・

Slide 34

Slide 34 text

34 2-2 コントリビュータになるときの ”考え方ポイント” コントリビューションする先のプロジェクトへの責任はなし！・・・という軽い気持ちで始めてみよう（※）（※）変更が正しいか確認して取り込むのはホスト側なので確認しているはず間違えた時には、ゴメンでOK 変更箇所へのホストから問い合わせには答えよう！「何か見つけたら」コントリビューションしてみよう！と考えてみる 1

Slide 35

Slide 35 text

35 2-2 コントリビュータになるときの ”考え方ポイント” 2 他の人が同じところでハマる・・・経緯が分からないと、他の人も時間が掛かる・・・オープンに議論することで、・もっといい解決策の提案や・バグを直してくれたりなどがあり、品質向上するかもしれない！コントリビューションの過程は、オープンにしておこう！

Slide 36

Slide 36 text

36 2-2 コントリビュータになるときの ”考え方ポイント” 3 コメントをもらったら感謝するポジティブなFBの繰り返し

Slide 37

Slide 37 text

37 2-2 コントリビュータになるときの ”考え方ポイント” なぜ受け入れてくれないか解決策を (ホストチームと) 一緒に考えよう！ 4 もし、受け入れてもらえない時は・・・

Slide 38

Slide 38 text

38 2-3 コントリビューションを始めてみよう基本は、次の3ステップコードを作成するホストチームにプルリクエストを送るコントリビューションの準備をする

Slide 39

Slide 39 text

39 2-3 コントリビューションを始めてみよう基本は、次の3ステップコードを作成するホストチームにプルリクエストを送るコントリビューションの準備をする

Slide 40

Slide 40 text

40 2-3 コントリビューションの準備をする考え方のポイントはホストと「共通課題」になりそうかどうか他に考えておくべきことは？

Slide 41

Slide 41 text

41 2-3 コントリビューションの準備をする取り組む前に… 考える必要がある3つのポイントリードタイム信頼関係の構築変更を受け取ってもらうための戦略

Slide 42

Slide 42 text

42 2-3 コントリビューションの準備をする ● コミュニティに参加して馴染むまでの時間（開発環境、コード、雰囲気） ● 何回かコントリビューションすると、リードタイムは短くなりますリードタイム

Slide 43

Slide 43 text

43 2-3 コントリビューションの準備をする信頼関係の構築方法 ● 期待を裏切らないようにしよう！ →ちょっと時間がかかりそうなことは事前に伝えよう ● いろいろなコミュニケーション方法を使い分けよう！ →メールだけでは細かなニュアンスが伝わらない Web会議で話す、F2Fで合う機会を作ることも必要

Slide 44

Slide 44 text

44 2-3 コントリビューションの準備をする変更を受け取ってもらうための戦略 ● 何かコードを書く前に、方向性の確認をしておく（それが本当に必要なものなのか？） ● オープンな場で議論して、議論の過程が見えるようにする

Slide 45

Slide 45 text

45 2-3 コントリビューションを始めてみよう基本は、次の3ステップコードを作成するホストチームにプルリクエストを送るコントリビューションの準備をする

Slide 46

Slide 46 text

46 2-3 コードを作成する ●相手のルールは守ろうコーディング規約 ●事を起こす前のコミュニケーションで、仲良くなろうコミュニケーションの過程は、オープンな場で行おう ●自分で解決できそうにない部分は、できないと言おうでは機会が見つかったら… コードを書こう！ …その前に、壁になりそうなものは取り除こう！それを取り除くには？次の人のためになるよ自分も検索できるようになるよ

Slide 47

Slide 47 text

47 2-3 コントリビューションを始めてみよう基本は、次の3ステップコードを作成するホストチームにプルリクエストを送るコントリビューションの準備をする

Slide 48

Slide 48 text

48 2-3 プルリクエストを送ろう！一気に、大きな変更入れないようにしよう！少しづつ順番に入れていこう • できるだけ簡単に取り込んでもらえるように、送るときには、テストしよう！ • 説明をつけよう！送るときのポイントマナー

Slide 49

Slide 49 text

49 2-4 コントリビューションするメリットは？（個人） • 必要な部分へのコントリビューションでモチベーションを維持して取り組むことができる単独で作業する代わりに、ホストチーム(アップストリーム)と作業するメリット他の人と時間を過ごすメリット自分が必要なところに取り組むことのメリット • レビューと改善のサポートと指導を受けられる → 開発作業が大幅にスピードアップ • 新しいツール、ソフトウェアについて実践的に学べる機会がある → 自分も後で使える • 複数の異なるプロジェクトに関係する → それぞれの良い点が活かせる • 自分のチームの境界を超えて人間関係と評判が広がる → いろんなところに意見を反映できる

Slide 50

Slide 50 text

50 2-4 コントリビューションするメリットは？（チーム） • 「独自実装で自分で全てのバグ抱える」ことと、「既存実装で時間とお金を節約するが、自由に仕様が決められない」ということの中間の解を得られる • 再実装と再利用とのバランスをとることが容易になるアップストリームで取り組むメリット他チームのプロジェクトでアクティブなコントリビュータとして働くことのメリット InnerSource の方法を使うメリット • メンテナンスのコストと時間をアップストリームプロジェクトに任せられる • プロジェクト方向性とスケジュールに発言権を持てる → 自チームに有益となる可能性 ➢ アップストリームで新しいリリースごとテストが行われる ➢ コントリビューションしたものの互換性のチェックはアップストリームで確認される

Slide 51

Slide 51 text

51 2-4 コントリビューションするメリットは？（会社） • 複数の実装が維持されなくなる • 理解しやすく、再利用しやすくなり、結果としてモジュール化される • より多くの視点でコードの変更が精査され、品質とセキュリティの向上につながる企業レベルで InnerSource を行うことのメリット会社全体で共有することのメリットプロジェクトの透明性が高まることのメリット • チーム間のコラボレーション促進で、イノベーションを推進できる • バスファクター(いなくなったら困る人)が1～2人という状況を回避できるリスクのあるプロジェクトがわかりやすくなる • ベストプラクティスやポジティブなイノベーションが、簡単に組織全体に広がる職場環境の改善が組織全体に広がりやすくなり、従業員が定着する

Slide 52

Slide 52 text

52 52 03 プロジェクトのまとめ役になろう【トラステッドコミッター】

Slide 53

Slide 53 text

53 プロジェクトの立ち上げ時には PJリーダー、開発チームリーダー的な役割がありますよね？プロダクトオーナー InnerSource ではがそれらに該当します！トラステッドコミッター 3-1 トラステッドコミッターの役割の紹介 InnerSource では、トラステッドコミッター(TC)の役割がとても重要！トラステッドコミッター

Slide 54

Slide 54 text

54 3-1 トラステッドコミッターの役割の紹介 • 品質の確保 • コミュニティの健全性維持 • コミュニティへの参入障壁を下げる • コミュニティのレベル向上 • コミュニティのニーズを支持（トラステッドコミッター）責任の範囲トラステッドコミッターはの両方の面倒をみる技術コミュニティ（コラボレーションする人全員） +

Slide 55

Slide 55 text

55 ポイント 3-2 品質の確保について TCは技術や品質に関する意思決定または意思決定の調停を行う権利を持つやり方コミュニティ(とコード)の寿命を伸ばすための将来への投資・・・だからです何故修正を行わないの？・品質基準を決める・コードのピアレビューを行って受け入れ可否を判断する・ (修正する代わりに) レビューの結果をフィードバックする・コードのマージを行う・時間がかかる場合、新しい要求が生じる場合などは、スケジュールの修正を行う

Slide 56

Slide 56 text

56 ●健全なコミュニティとは？ • コントリビューターがソフトウェア開発に時間を費やすことができる • コントリビューターが能力を高めることができるようになっている 3-3 コミュニティーの健全性維持 ●なぜコミュニティができるのか？ • 共通の課題や目的があるから • コミュニティーの他のメンバーと一緒に仕事をするのが楽しいから → 結果として継続的に成長

Slide 57

Slide 57 text

57 • コミュニティー共通の課題を明確に表現して宣伝する → つまりはマーケティング • コントリビューションを贈り物として扱い、称賛する • メンタリングを行う（何故改善する必要があるか、どう改善する必要があるか、理由と方向性を示す） • 必要に応じて、行動規範を作成して実行する • 双方が定期的にお互いを知り合う機会を提供する • 紛争を平和的に解決する機会を作る 3-3 コミュニティーの健全性維持コントリビューターが歓迎されて感謝される環境を作るように努力するトラステッドコミッターが行うことコミュニティー健全性維持のための行うこと

Slide 58

Slide 58 text

58 3-4 コミュニティメンバーのレベルアップ • コミュニティの維持（利用者やコントリビュータから将来トラステッドコミッターを発掘） • コミュニティの活性化（スピードアップ、アウトプット品質の向上） • 製品やコミュニティのマーケティング • 貢献する機会の創出（例：ドキュメンテーション、テスト自動化） • メンタリング（コードを受け入れ可能なレベルにする指導） • 成長する可能性のあるコントリビューターを発掘 • コントリビュータ、TC双方の学習と成長（例：メンタリング能力向上） • トップタレントの維持貢献する機会を伝え、コントリビューターを支援したり指導するより優れたソフトウェアをより早く作成するコミュニティ能力向上につながるコミュニティメンバーのレベルアップは何故必要？トラステッドコミッターがコミュニティメンバーのレベルアップのために行うこと

Slide 59

Slide 59 text

59 3-5 コミュニティへの参入障壁を下げる • (会社の中なので)潜在的なコントリビューターの数が少ない中で、見つけやすくする • 他の仕事もある中で、なるべく手間を掛けずにコントリビューションできるようにする何故、参入障壁を下げないといけないか？

Slide 60

Slide 60 text

60 • リポジトリに何があるのか、何に使えるのかを説明 • ライセンスに関する情報（InnerSourceライセンス） • ソフトウェアの入手方法、ビルド方法、テスト方法、使用方法についての詳細な指示を提供 • バグレポートや機能リクエストはどうやって提出すればいいですか? • 質問がある場合は誰にどのように連絡すればいいのか? • コードスタイル、分岐、コミットメッセージの規約は？ • 貢献の「完了」の定義は？ • 貢献を管理するプロセスステップとは？ • 貢献が承認された後、貢献したコードをサポートするという点ではどのようなことが期待されていますか? • 行動規範とは何ですか? 3-5 コミュニティへの参入障壁を下げる • HELPWANTED を作成して、どのようなものが足りていないか明示する (例：アートワーク、イベントの企画、要求機能) 参加までに迷わない道筋を用意する！繋がれる README を用意 CONTRIBUTING を作成してコントリビューターに何が期待されているかを説明オプショントラステッドコミッターが参入障壁を下げるために行うこと使えるわかる

Slide 61

Slide 61 text

61 3-5 コミュニティへの参入障壁を下げる参加までに迷わない道筋を用意する！繋がれる使えるわかるトラステッドコミッターが参入障壁を下げるために行うことできるだけ多くの人が貢献できるように・ドキュメントを用意して基本的な質問に答えられるようにする・貢献することがポジティブになる雰囲気を作りだす

Slide 62

Slide 62 text

62 3-6 コミュニティのニーズを支持する • 組織との信頼関係を構築する • コミュニティの利益と社内のソフトウェアの長期的な健全性のために行動する • 技術的なリスクだけでなく、コミュニティに関連するリスクをマネージャーに伝える • コミュニティや個々のコントリビューターの仕事を外から評価（称賛）する • (必要に応じて)コントリビューターのマネージャーと話し合いを行うなどのロビー活動をするトラステッドコミッターが行うこと個々の投稿者の利益とコミュニティ全体の利益を考えてコミュニィの健全性を維持することで、コミュニティと組織の両者の信頼関係を構築

Slide 63

Slide 63 text

63 3-7 トラステッドコミッターになるトラステッドコミッターを1人持つか複数持つか (規模やリスクで判断する) 例：トラステッドコミッターの仕事を分担するローテーション・システムトラステッドコミッターになるにはどうすればいいの？ • 開発リーダー（クラス）になる • コミュニティ活動で、周りから認められるトラステッドコミッターになるために行うことは？ • プロジェクトについて深い技術的能力を持つ • プロダクトオーナーやマネージャーと効果的にコミュニケーションをとれるようになる • コントリビューターをレベルアップさせる意欲と忍耐力を示す • 感情的ならずに意見を受け止められるようになる • コーディングより、コミュニケーション・メンタリングに注力するトラステッドコミッターになるための心構えは？ • 自発的に引き受ける会社やマネジメント層で考えること

Slide 64

Slide 64 text

64 コラム：”トラステッドコミッター”という名前について他のコミュニティにおけるトラステッドコミッターと似た役割 • Apache Software FoundationにあるCommitter（コミッター） • GitHubにあるMaintainer（メンテナー）トラステッドコミッターは何が違うのか？ • マネージメント層とコミュニティの両方から「信頼されている」からこその役割 • コミュニティに対する責任が追加され、オープン性と透明性を醸成する • 開発プロセスやプロダクトに対する他からの信頼を構築する技術指向の責任範囲なぜトラステッドなのか？コミュニティ指向の責任信頼の獲得

Slide 65

Slide 65 text

65 65 04 プロダクトオーナーとしての立ち回り【プロダクトオーナー】

Slide 66

Slide 66 text

66 プロジェクトの立ち上げ時には PJリーダー、開発チームリーダー的な役割がありますよね？プロダクトオーナー InnerSource ではがそれらに該当します！トラステッドコミッター 4-1 プロダクトオーナーとは？ InnerSource におけるプロダクトオーナーとは？プロダクトオーナー

Slide 67

Slide 67 text

67 4-1 プロダクトオーナーとは？「中間管理職 (ミドルマネージャー)」と呼ばれる人？ • それぞれの組織において、上層部のビジョンの執行に責任を負う人 • 予算管理や執行をする人 • 部・課・プロジェクト・チームなどの単位の責任者 InnerSource におけるプロダクトオーナー • 方向性に対して責任を持つ人（※注：開発だけでなく）トラステッドコミッターとプロダクトオーナーが同一人物の場合もある

Slide 68

Slide 68 text

68 4-2 InnerSource のプロダクトオーナーとして最初に心がけることオープンプランニング・オープンドキュメント計画とそれに関係する文書オープンコードソースコードの公開

Slide 69

Slide 69 text

69 4-2 InnerSource のプロダクトオーナーとして最初に心がけることオープンコード • コードを会社の全員が見えるようにする • 修正や機能実装を待ったり、エスカレーションしたり・されたりする必要がなくなる • それぞれの優先順位に基づいて、コントリビューションできるようになる効果 • 他の開発者が他のコードベースでコントリビューションでき、それを受け入れるプロセスがある

Slide 70

Slide 70 text

70 4-2 InnerSource のプロダクトオーナーとして最初に心がけることオープンプランニング・オープンドキュメント • 標準化された方法(同じ場所)でプランニングプロセスやドキュメントを公開すること • プロジェクトや製品ごとにドキュメントがどこにあるのかわかる(検索できる) • 見つけてもらえ、利用してもらえ、フィードバックがもらえる • 他のチームが何に取り組んでいるのか、現在何を優先しているのかを知ることで、より効果的にチーム間の調整を行うことができる • 議論の履歴を元に、優先順位が変更される理由などが明確になり、チーム同士の信頼関係構築につながる • コラボレーション可能なチームを簡単に見つけられる • お互いの開発文化の違いを知ることができる効果

Slide 71

Slide 71 text

71 4-3 プロダクトオーナーの役割と責任トラステッドコミッターの選抜とサポート他のプロダクトオーナーとの交渉環境の整備（仕事をすすめる上での）社内マーケティング

Slide 72

Slide 72 text

72 4-3 プロダクトオーナーの役割と責任トラステッドコミッターの選抜とサポート他のプロダクトオーナーとの交渉環境の整備（仕事をすすめる上での）社内マーケティング

Slide 73

Slide 73 text

73 4-3 プロダクトオーナーの役割と責任 ● 見積などの協力を依頼 ● トラステッドコミッターのメンタリングトラステッドコミッターの選抜とサポート

Slide 74

Slide 74 text

74 4-3 プロダクトオーナーの役割と責任トラステッドコミッターの選抜とサポート他のプロダクトオーナーとの交渉環境の整備（仕事をすすめる上での）社内マーケティング

Slide 75

Slide 75 text

75 4-3 プロダクトオーナーの役割と責任 ● 制約（人・時間・資金など）の中で、自チームの意見を代弁して理解してもらう ● 個々のチームのプロセスを尊重しつつ、必要に応じて他チームにも指導を行う他のプロダクトオーナーとの交渉

Slide 76

Slide 76 text

76 4-3 プロダクトオーナーの役割と責任トラステッドコミッターの選抜とサポート他のプロダクトオーナーとの交渉環境の整備（仕事をすすめる上での）社内マーケティング

Slide 77

Slide 77 text

77 4-3 プロダクトオーナーの役割と責任 ● チームに対するドキュメンテーションの時間の確保 • オープンドキュメンテーションに時間を割くことへの理解 • UXやUIの標準、API標準、テスト要件等の明確化依頼 ● 開発者が安心して活動できる環境の整備 • 標準的な開発ツールの整備の許可環境の整備（仕事をすすめる上での）

Slide 78

Slide 78 text

78 4-3 プロダクトオーナーの役割と責任トラステッドコミッターの選抜とサポート他のプロダクトオーナーとの交渉環境の整備（仕事をすすめる上での）社内マーケティング

Slide 79

Slide 79 text

79 4-3 プロダクトオーナーの役割と責任 ● コードを利用してもらえそうなプロジェクトの発掘 (似たような機能開発をしているプロジェクトの発掘) ● コードを提供してもらえそうなプロジェクトの発掘 ● ベストプラクティスや失敗談の共有 ● Codeathon / Hackathon開催など、さまざまな種類のアナウンス社内マーケティング

Slide 80

Slide 80 text

80 80 4-4 InnerSource のプロダクトオーナーになる利点 ⚫ コラボレーションで、より少ないリソースでより多くのことを達成できる実感が得られる ⚫ チームの冗長性が向上する ⚫ プロセスを公開することで政治的な問題にも対処できる ⚫ トラステッドコミッターのサポートなど、新たな役割と責任を得ることができる ⚫ 社内マーケティングスキルを身につけるチャンスが得られる ⚫ 仕事に対する評価が高くなる

Slide 81

Slide 81 text

81 81 05 InnerSource の実践

Slide 82

Slide 82 text

82 1. 問題意識を共有する・発見する 2. 共通の問題意識をもつ人達で意見交換する 3. 課題を解決する 4.（個別対応が必要な部分も作る） 5. 4の途中に出る共通課題も共有する 6. ノウハウが共有され、新しいアイデアが出る（可能性がある） 7. １に戻る 5-1 InnerSource 実践のための準備 InnerSource 実践に必要なもの：「共通」の問題・課題賛同者（有識者）提案者賛同者（開発者やユーザー）オープンな場課題解決のアイデア課題解決策を具現化する実装(ソースコード)

Slide 83

Slide 83 text

83 5-2 「共通課題」を見つけるには？ ●まずは身近なところから・同じ部門・組織の中から・同じような事業の関係者の中から・会社全体で ●どのようなタイミングで考えるのが良いか？・新しいプロジェクトを始めるとき・要件定義やシステム設計するとき・改造・リファクタリングするとき

Slide 84

Slide 84 text

84 5-3 「共通課題」の範囲はどこか？（コラボレーション可能なポテンシャル） Unique Innovation (企業が顧客に提供する価値) Commodity Platform Ref: How to Contribute to the Linux Kernel, and Why it Makes Economic Sense (James Bottomley, Novell; LinuxCon Japan 2009) Delivery Support for the innovation (価値提供に必須の技術) OSSが主に対象とする領域 Commodity Platform (導入するだけでOK) Delivery Support for the innovation (価値提供に必須の技術) Unique Innovation (企業が顧客に提供する価値) InnerSourceが対象とする領域会社内なら外に出せない「共通課題」も解決できる！

Slide 85

Slide 85 text

85 5-3 InnerSource 実践：3つの武器 (場としての) システム (実践可能な) ルールマインド解決する課題人

Slide 86

Slide 86 text

86 5-4 「共通課題」解決の場の準備共有されたオープンな場所トラステッドコミッターコントリビューターポータルサイトソースコードリポジトリ登録参加発見オープン性や透明性の確保に向けて、共通の場を用意システム

Slide 87

Slide 87 text

87 5-5 InnerSource実践ルールの整備（InnerSourceライセンスの例）共有されたオープンな場所リポジトリ InnerSourceライセンス：自由に利用・改変OK、フィードバックしてね（製品利用要相談）開発部門A 開発部門C 開発部門B 開発部門D コントリビューションコントリビューション (InnerSource or OSS License) 参照・利用参照・利用ルール

Slide 88

Slide 88 text

88 5-5 InnerSource実践ルールの整備（コストの考え方の一例） Ref: Transfer Pricing for InnerSource - Max Capraro (Kolabri) & Oliver Treidler (TP&C) - IS Summit 22, https://youtu.be/91srcPMcmBY?si=CJzeuhwthmtykRah Sustaining Arm’s Length Cost Allocations for Highly Integrated Development Functions—An Explorative Case Study of Transfer Pricing for InnerSource Communities https://bth.diva-portal.org/smash/get/diva2:1837328/FULLTEXT01.pdf users contributors “users only” → have to pay into cost pool “contributors only” → contract developer? price separately “users with self-interest to contribute” → nothing to be paid! コストの考え方の一例ルール

Slide 89

Slide 89 text

89 5-5 InnerSource実践ルールの整備（例：コンソーシアム設立）共有されたオープンな場所リポジトリ自由に利用・改変OK、フィードバックしてね（製品利用要相談）開発部門A 開発部門C 開発部門B 開発部門D コントリビューション参照・利用参照・利用コンソーシアム加入者は製品利用可（保守契約別途）コントリビューション (InnerSource or OSS License) ルール

Slide 90

Slide 90 text

90 5-6 マインド醸成（株式会社東芝の事例）マニフェストの作成各種イベントの実施（ハッカソン・Webinarなど）マインド Ref: 共に創る未来：ソフトウェア開発における共創・協働のアプローチと戦略、小林良岳 https://speakerdeck.com/ystk

Slide 91

Slide 91 text

91 5-7 実践事例１：組込みLinux®ディストリビューションの展開 Linuxディストリビューション開発元部門開発部門A 開発部門C 開発元が展開開発部門B Linuxディストリビューション Ref:インナーソースをはじめてみよう！共通課題解決にむけた革新的な取組み、小林良岳 https://qiita.com/ystk-k/items/9045c17a4b529e8cda48 ※ Linuxは、Linus Torvalds 氏の米国およびその他の国における登録商標です

Slide 92

Slide 92 text

92 5-7 実践事例１：組込みLinuxディストリビューションの展開 Linuxディストリビューション開発元部門開発部門A 開発部門C 開発元が展開開発部門B Linuxディストリビューションコピー Ref:インナーソースをはじめてみよう！共通課題解決にむけた革新的な取組み、小林良岳 https://qiita.com/ystk-k/items/9045c17a4b529e8cda48

Slide 93

Slide 93 text

93 5-7 実践事例１：組込みLinuxディストリビューションの展開 Linuxディストリビューション開発元部門開発部門A 開発部門C オープンな場で共有開発部門B Linuxディストリビューション設定情報 Ref:インナーソースをはじめてみよう！共通課題解決にむけた革新的な取組み、小林良岳 https://qiita.com/ystk-k/items/9045c17a4b529e8cda48

Slide 94

Slide 94 text

94 5-7 実践事例１：組込みLinuxディストリビューションの展開 Linuxディストリビューション開発元部門開発部門A 開発部門C オープンな場開発部門B 委託先A 委託先C Linuxディストリビューション Ref:インナーソースをはじめてみよう！共通課題解決にむけた革新的な取組み、小林良岳 https://qiita.com/ystk-k/items/9045c17a4b529e8cda48

Slide 95

Slide 95 text

95 5-7 実践事例１：組込みLinuxディストリビューションの展開 Linuxディストリビューション開発元部門開発部門A オープンな場開発部門B Linuxディストリビューション OSS コミュニティ開発部門C 委託先C 開発部門D 委託先A Ref:インナーソースをはじめてみよう！共通課題解決にむけた革新的な取組み、小林良岳 https://qiita.com/ystk-k/items/9045c17a4b529e8cda48

Slide 96

Slide 96 text

96 5-8 実践事例２：技術カタログをコードで作成共有されたオープンな場所技術カタログサイトデプロイフィードバック閲覧部門メンバー技術カタログソースコードリポジトリ編集＆プルリクエストトラステッドコミッターレビュー＆マージプロダクトオーナー Ref:インナーソースをはじめてみよう！共通課題解決にむけた革新的な取組み、小林良岳 https://qiita.com/ystk-k/items/9045c17a4b529e8cda48

Slide 97

Slide 97 text

97 5-8 実践事例２：技術カタログをコードで作成(プロダクトオーナーの活動) トラステッドコミッターの選抜とサポート他のプロダクトオーナーとの交渉環境の整備（仕事をすすめる上での） • ドキュメンテーションの時間の確保 → 社内展向け活動 • 安心して活動できる環境の整備 → 共通開発環境社内マーケティング • 社内向け展示会のコンテンツとしてそのまま利用

Slide 98

Slide 98 text

98 5-8 実践事例２：技術カタログをコードで作成共有されたオープンな場所技術カタログサイトデプロイフィードバック閲覧コントリビューター技術カタログソースコードリポジトリ編集＆プルリクエストトラステッドコミッターレビュー＆マージプロダクトオーナー編集＆プルリクエスト Ref:インナーソースをはじめてみよう！共通課題解決にむけた革新的な取組み、小林良岳 https://qiita.com/ystk-k/items/9045c17a4b529e8cda48

Slide 99

Slide 99 text

99 5-8 実践事例３：技術中計を公開形式で実施（InnerSourceの思想を利用）共有されたオープンな場所テーマリーダー Teams / OneDrive （会社メンバ誰でもアクセス可）投稿・編集・コメント返信レビューアレビュー意見投稿プロダクトオーナー意見・要望修正案の提案部門長メンバ社内SNS 閲覧役員・他部門長・メンバなど投稿確認・承認 Ref:インナーソースをはじめてみよう！共通課題解決にむけた革新的な取組み、小林良岳 https://qiita.com/ystk-k/items/9045c17a4b529e8cda48

Slide 100

Slide 100 text

100 5-9 そして暗躍… ① InnerSource Learning Pathを全て翻訳！（Upstream first!） ② CodeZineに記事執筆引用元：https://innersourcecommons.org/ja/learn/learning-path/ https://codezine.jp/article/detail/14809 https://innersourcecommons.connpass.com/event/271207/ ③ 各種イベントで発表

Slide 101

Slide 101 text

101 101 外堀から埋めていく・・・

Slide 102

Slide 102 text

102 102 06 InnerSource FAQ

Slide 103

Slide 103 text

103 6-1 なんでも共有すれば良いのでしょうか？回答：いいえ共通の課題か気づかないことも有るため、早い段階からアイデアや悩みを共有しておくことが大切です望ましい共有のケース • 共通課題に基づく共有 • 自分が問題意識を持っているものの共有 (もしかしたら誰かの課題解決になるかも) 望ましくない共有のケース • 捨てたいものを共有 • なにかあっても答えられないものの共有ポイント

Slide 104

Slide 104 text

104 6-2 オーナー(リーダー) になりたくない！ • 必要だから作るのではないでしょうか？（自分で好きなように作るために始めてみませんか？） • 使ってもらいたい技術を作っているのではないですか？（たとえ Under the Table であったとしても） • 困ったときだけ相談すると、回答に時間かかります（はじめて問題を見た人は、それを理解しないといけません）回答：リーダーを強く意識するより次のことを考えてみてください • 一人で作ることに比べて、仲間がいることは次の利点があります ➢ 困った時にすぐ相談できます（仲間は、質問の意図を深く理解しているかもしれません） ➢ バグを指摘してもらえるかもしれません（後で困ったことにならずに済むかもしれません） ➢ バグを直してもらえる（かもしれません） • オーナーの役割は、興味を持っている人が増えれば分担すれば良いのです (調整できるかもしれません) • オーナーとしての負荷は調整可能ですポイント

Slide 105

Slide 105 text

105 6-3 公開とか貢献とは言っても、何で人のために・・・ • 自分が使いたい(作りたい)という判断したのでは？ • バグ報告するだけでも貢献です • 自分で修正することになっても、報告していれば仲間が増えます • 全部自分で作ると、大変ですよね？ • 一緒に考えられるところは一緒にやって、研究の時間を作ってください • 自分だけでは気づかない点の気付きが得られるかもしれません回答：「自分が必要なもの」という前提のもとに行動するので、結果として人のためではなくて自分のためになりますポイント間違って同じものを作らなくて済むかもしれません

Slide 106

Slide 106 text

106 6-4 全然自分に得じゃないよね？回答：損得の話ではなくて、Give & Given の話です • ある部分は負担かもしれませんが、別の所で助けてもらえるかもしれません • 常にバランスするとは言えませんが、継続することで効果を実感できる日が来るかもしれません • 課題をオープンにしているだけでも貢献です。なぜなら同じ課題を持つ人が集まるきっかけを作っているのでポイント

Slide 107

Slide 107 text

107 107 07 まとめ

Slide 108

Slide 108 text

108 InnerSource は企業文化に変革をもたらす活動です！一緒に InnerSource をはじめましょう！ 7 まとめ ● InnerSource の多くのメリット • 開発スピード、品質、メンテナンス性の向上 • 開発リソースのスケール • 開発者の満足度向上 ● InnerSource における役割コントリビューター、トラステッドコミッター、プロダクトオーナー ● InnerSource の実践オープンな場で透明性を確保して開発を行うことの大切さ

Slide 109

Slide 109 text

109 共創・協調領域はコントリビューションオープンな活動は社内も世界も変えられるオープンに(仲間と)暗躍する！ 109 7 本当のまとめ

Slide 110

Slide 110 text

110 Think OPEN

Slide 111

Slide 111 text

111 Thank you!

Slide 112

Slide 112 text

112

Slide 113

Slide 113 text

113 参考情報 ⚫ InnerSource Learning Path • http://innersourcecommons.org/resources/learningpath/ ➢Copyright： Johannes Tigges (English), Yoshitake Kobayashi (Japanese) ➢License： CC-BY-SA 4.0 • https://github.com/InnerSourceCommons/InnerSourceLearningPath ⚫ InnerSource Commons • http://innersourcecommons.org/

Slide 114

Slide 114 text

114 114 Appendix

Slide 115

Slide 115 text

115 カラー情報メインカラー ① HEX：0aa8a7 RGB：10/168/167 HSL：180/89%/35% メインカラー ③ HEX：ffffff RGB：255/255/255 HSL：180/89%/35% メインカラー ② HEX：edf6f5 RGB：237/246/245 HSL：180/89%/35% メインカラー ④ HEX：000000 RGB：0/0/0 HSL：0/0%/0% サブカラー ⑤ HEX：435964 RGB：67/89/100 HSL：200/20%/33% サブカラー ⑦ HEX：a7a8a8 RGB：167/168/168 HSL：180/1%/66% サブカラー ⑥ HEX：edf6f5 RGB：236/236/236 HSL：0/0%/93% サブカラー ⑧ HEX：5c5c5c RGB：92/92/92 HSL：0/0%/36% サブカラー ① HEX：85d4d4 RGB：133/212/212 HSL：180/48%/68% サブカラー ③ HEX：feba9c RGB：254/189/156 HSL：20/98%/80% サブカラー ② HEX：005d05 RGB：0/93/93 HSL：180/100%/18% サブカラー ④ HEX：ae6359 RGB：174/99/89 HSL：7/34%/52%