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

Transcript

1. 1 小林 良岳 (Yoshitake KOBAYASHI) Toshiba Corporation / InnerSource Commons Email: yoshitake.kobayashi@toshiba.co.jp InnerSource Learning Path インナーソースで始める 組織内オープンソース開発入門＆実践 InnerSource Commons Community Talk
2. 2 自己紹介 小林 良岳 Yoshitake KOBAYASHIInnerSource Commons Japan
3. 3 はじめに： InnerSourceを始めたモチベーション 似たようなことをするなら 一緒に解決したい！ 内向きなモチベーション 興味 日本の企業文化を 変えたい！ 外向きなモチベーション 危機感 社会と組織を変革する
4. 4 4 本日の Takeaway • InnerSource の基本 • 立ち回り方のヒントとベネフィット • 実践事例からの気づき
5. 5 5 発表の流れ 01 InnerSource とは？ 02 03 04 05 InnerSourceに参加してみよう InnerSourceプロジェクトのまとめ役になろう プロダクトオーナーとしての立ち回り InnerSource の実践
6. 6 6 01 InnerSource とは？
7. 7 1-1 こんな経験はありませんか？ • 一緒にやってるプロジェクトで他チームを待っていたら遅れた ・・・ • バグを見つけて、通知したのに何時まで経っても直らない ・・・ • 似たような機能を作ってしまい、両方メンテナンスしないといけない ・・・
8. 8 1-1 こんな経験はありませんか？ APIを使いたい！ 同じ会社にある二つのチームが、別々のソフトウェア部品を提供する時、 あるチームのソフトウェアが、もう一方のチームのソフトウェアに依存する状況 例：表示用データを取得するAPIに依存するサービス ケース チーム チーム 利用 提供 どうしてもリクエストが届かない場合 どうするか？ チームごとに事情は異なる ・機能の優先度 ・開発スケジュール など 直ぐには提供出来ない！ 表示データ 提供API （未実装） データ表示 サービス
9. 9 1-1 こんな時、あなたならどうしますか？ １. 「静観」：黙っている ３. 「圧力」：上層部を通してやらせる デメリット メリット ・圧力という開発に関係のない作業に注力しなければならない ・何度も使えるものでもなく発展しない ・チーム間や個人間の信頼を損なう 必要な機能が手に入る (かもしれない) ２. 「回避」：勝手にやる デメリット メリット ・成果は同じ機能を必要としている他の利用者に提供されない ・本来の役割範疇でないコードを長期的にメンテナンスしなければならない ・会社全体として、同じ課題に対する重複したプロジェクトとコードを取得してしまう 要求機能が足りない部分を ローカルに変更・機能追加して 補なえる デメリット メリット ・要求された機能がいつまでたっても提供されない 作業を最小限にすることができる
10. 10 1-2 InnerSource なら、まとめて解決できます！ InnerSource を使うと全ての欠点を解決し、効果が得られる ・・・ でも、そもそも InnerSource って？ • 共通課題に対する解決方法を共有して再利用することで、 組織が価値創出に集中できるようになる！ • 新しい技術が学べる！ • 一緒に楽しく仕事をする事ができる！
11. 11 1-2 InnerSource とは？ • 企業内の活動にオープンソース実践とベストプラクティスと原則を適用 したものです。 • InnerSource ソフトウェアは、会社として守る資産ですが、 内部にはオープンで、誰もが利用したり貢献したりできるようになります。 Dirk Riehle, Inner Source (Software Development), InnerSource Summit 2018 ・・・ を企業内で実践することです。 Welcome visitors! Open all artifacts! つまり ・・・
12. 12 目指す姿 サイロを取り払い、コラボレーションが各所で発生！ 1-2 InnerSource で目指す姿 今まで サイロごとに閉じている 何をしているか自部門以外のことは知らない
13. 13 1-3 どのように InnerSource は機能するのか？ ケース チーム A チーム B 機能を使いたい！ 期限内に実装して Bチームにリリースすることはできない・・・ ゲスト ホスト Aチームが提供するソフトウェアをBチームが利用する場合 「コントリビューション」をします！ 利用 提供
14. 14 1-3 InnerSource における役割 コントリビューター トラステッドコミッター プロダクトオーナー チーム B 〔ゲスト〕 チーム A 〔ホスト〕 ホストチームを代表。 コントリビューターが正しく貢献するために 必要な指導やサポートをタイムリーに提供 さばき役。ゲストをサポートする ホストチームの家長的存在。 受け入れるコントリビューションが どの機能かを決定 受け入れられるモノを仕分けする 別チームの一員。 ホストチームにコード等を投稿。
15. 15 コントリビューターをサポート 1-3 InnerSource における役割 コントリビューター トラステッドコミッター プロダクトオーナー 要求する機能を実装して送信 トラステッドコミッターとコミュニケーションしながら、 コードを実装・改善する コントリビューションされたものが 受け入れ可能な機能かどうかを判断 サポート ジャッジ チーム B 〔ゲスト〕 チーム A 〔ホスト〕
16. 16 1-4 InnerSource のメリット チーム B 〔ゲスト〕 チーム A 〔ホスト〕 オープンな場で共通課題の解決策を共有できることは、会社にとっても有効 より良い拡張性やサービスを 顧客に提供することができる 長期的にメンテナンスする責務 を負うことなく、必要とする時間 までに機能を入手できる
17. 17 1-4 InnerSource のメリット ・ニーズが確定している機能を受け取れるので、 良いプロダクトを作るための支援 となる 長期メンテナンスの負担をせず、 必要な時に機能要求を手に入れられる ・スケーラブルな戦略ができるようになる ・必要とする時と場所に エンジニアリングの時間を 有機的に投入することが可能 ・全ての利用者との間で優先順位の 調整を行うことができる 品質向上 会社 リソース配分を最適化できる 余力ができ、他へ注力できる 必要な機能 が手に入る チーム B 〔ゲスト〕 チーム A 〔ホスト〕 必要な機能 が手に入る 要求X OK! 要求Y 要求Z 機能X 機能Y 機能Z 開発の利点 戦力倍増する
18. 18 1-4 InnerSource のメリット 当事者の利点 ポジティブなFBの繰り返しで ポジティブなFBの繰り返しで トレーニングや教育にもなる コントリビューター トラステッドコミッター 従来の会社のサイロがなくなる 仕事への満足度が高くなる プロジェクト全体をより理解できる プロジェクトを理解している人が増える 同僚や新しいチームに参加を推奨する ホストチームの負担が軽減するようになる プロジェクトに貢献する人が増え、アイデアが自然に融合し生まれる
19. 19 1-5 InnerSource での役割と心構え 自宅にお客様を招くような・・・ チーム B ゲスト チーム A ホスト 物事が整理整頓されていることを保証 （居心地のいい環境を提供） 家のルールに従いながら、 設備などを利用させてもらう
20. 20 1-6 InnerSource の原則 オープン性 → 透明性 → 常にドアが解放されていて、受け入れ可能な状態 意思決定プロセス、コード、ToDoなどが見えるようになってる状態 (ゲストに対して) ありとあらゆるサポートを惜しまない 共通の課題意識に基づき、お互いに協力する 優先的な メンターシップ → 自発的な コードコントリビューション → オープンな場 で、 誰もが目的のプロジェクトを見つけられるようにする
21. 21 21 1-7 ここまでのまとめ • InnerSource は、企業内のソフトウェア開発にオープンソースのベストプラクティスと 原則を適用したものです。 • これは、提供側のチームが必要な機能要件を提供することができない時に、 利用者に追加オプションを提供するものです。 • InnroSource の成功には、「ホストチーム」のプロダクトオーナーとトラステッドコミッター、 そして「ゲストチーム」のコントリビューターが関わります。 • 効果的に行うと、InnerSource は両方の参加チームに多くの効果をもたらします。 • 効果的な InnerSource 実施の主要な原則は、オープン性、透明性、 自発的なコードコントリビューションと優先的なメンターシップ です。 オープンにコラボレーションすることで楽しみながら戦力を倍増すること！
22. 22 22 02 参加してみよう 【コントリビューター】
23. 23 2-1 InnerSource における役割 コントリビューター トラステッドコミッター プロダクトオーナー チーム B 〔ゲスト〕 チーム A 〔ホスト〕 ホストチームを代表。 コントリビューターが正しく貢献するために 必要な指導やサポートをタイムリーに提供 さばき役。ゲストをサポートする ホストチームの家長的存在。 受け入れるコントリビューションが どの機能かを決定 受け入れられるモノを仕分けする 別チームの一員。 ホストチームにコード等を投稿。 インナーソースには3つの役割があります。 ここからは コントリビューター の話をします。 もうひとつ重要なことは 共通の課題！ まずは、それについて話していきましょう。 コントリビューター
24. 24 開発視点 2-1 共通の課題(一般的な課題)とは何か？ 共通課題発見の起点になりそうなもの • 共通サービス • ◦◦プラットフォーム • ◦◦フレームワーク • ミドルウェア • ライブラリ • ツール • 開発環境 • ドキュメント • 組織横断活動・プロジェクト • ボトムアップ活動 • (公認・非公認によらず) 社内◦◦コミュニティ コミュニティ視点
25. 25 2-1: こんな経験はありませんか？ 〔再掲〕 • 一緒にやってるプロジェクトで他チームを待っていたら遅れた ・・・ • バグを見つけて、通知したのに何時まで経っても直ってこない ・・・ • 似たような機能を作ってしまい、両方メンテナンスしないといけない ・・・
26. 26 2-1 共通の課題(一般的な課題)とは何か？ なにかを作ろうとするとき ・・・ 「なにか似たことを考えている人はいないかな？」と探してみる と言っても ・・・ コントリビューションするモチベーションは何だろう？ • 作る前に • 考えていることを共有して • 似たことを考えていたり、やっていたりする人がいないか見つけてみる つまり ・・・
27. 27 2-1 皆さんも、このような事を考えるのでは… それぞれのプロジェクトの進行ペースが違うよね !? 前にも伝えたのに、誰も動かなかったよ！ 使おうとしたけど、バグばかりで使えなかったよ …（誰も直してくれないよ…） InnerSource のプロジェクトではソースコードをチェックアウトして 変更を加え、改良したバージョンを利用する自由があるんです！ InnerSource そこで・・・
28. 28 2-1 コントリビューターになってみよう！ プロジェクトのコピーを作成して、そこに変更を加えて、自分の手元に置く ! 確かに、仕事は終わるけれど・・・ コピーしたコードをメンテナンスし、ホストチームが作成する 新しいリリースのいずれにも、その変更を追随させないといけない メリット InnerSource の自由を間違えると、 こんな問題を抱えてしまう！ デメリット
29. 29 2-1 コントリビューターになってみよう！ 自由に直せるのであれば、チェックアウト元に直接変更を加えよう！ 第3の解決策があることを認識する マインドセットを変える • 機能やバグの修正を待つ代わりに・・・ • 問題を回避する代わりに・・・ • InnerSourceプロジェクトでニーズを確認 • 共有されたプロジェクトに直接変更を加えます そこで！
30. 30 2-1 コントリビューターになってみよう！ チェックアウト元に直接変更を加える行為をするのが コントリビューターです！ コントリビューターになれば、こんなメリットがあります！ • チェックアウト元のプロジェクトの専門家らから、より深い知識が得られる！ • 本番でしか明らかにならないようなパッチの問題が早く明らかになって品質も上がる！
31. 31 2-1 どんなことがコントリビューションできる？ ⚫ コンポーネントやコード、サービス利用時の問題報告 ⚫ 問題を再現するためのテストケース ⚫ バグのトリアージの支援 ⚫ ビルドの改善 ⚫ ドキュメントの改善 ⚫ 他のユーザのサポート ⚫ 使っていることの報告 どんなことでも、ノウハウを共有するのは 正しいコントリビューション！
32. 32 2-2 コントリビューターの心構え 物事が整理整頓されていることを保証 機能や設備を利用することができ、 従うべきいくつかの家のルールがある チーム B ゲスト チーム A ホスト 物事が整理整頓されていることを保証 チーム A ホスト それから、自分を売り込もう！ ソースコードを、どのようにコントリビューションすればよいか確認しよう • ドキュメントがあれば、それを確認 • 情報が不足している時は、問い合わせできそうな人 (トラステッドコミッター) に確認
33. 33 2-2 コントリビューターになるときの ”考え方ポイント” 「何か見つけたら」 コントリビューションしてみよう！と考えてみる 1 2 コントリビューションの過程は、オープンにする 3 コメントをもらったら感謝する 4 もし、受け入れてもらえない時は・・・
34. 34 2-2 コントリビュータになるときの ”考え方ポイント” コントリビューションする先のプロジェクトへの責任はなし！ ・・・ という軽い気持ちで始めてみよう（※） （※）変更が正しいか確認して取り込むのはホスト側なので確認しているはず 間違えた時には、ゴメンでOK 変更箇所へのホストから問い合わせには答えよう！ 「何か見つけたら」 コントリビューションしてみよう！と考えてみる 1
35. 35 2-2 コントリビュータになるときの ”考え方ポイント” 2 他の人が同じところでハマる・・・ 経緯が分からないと、他の人も時間が掛かる・・・ オープンに議論することで、 ・ もっといい解決策の提案や ・ バグを直してくれたりなど があり、品質向上するかもしれない！ コントリビューションの過程は、オープンにしておこう！
36. 36 2-2 コントリビュータになるときの ”考え方ポイント” 3 コメントをもらったら感謝する ポジティブなFBの繰り返し
37. 37 2-2 コントリビュータになるときの ”考え方ポイント” なぜ受け入れてくれないか 解決策を (ホストチームと) 一緒に考えよう！ 4 もし、受け入れてもらえない時は・・・
38. 38 2-3 コントリビューションを始めてみよう 基本は、次の3ステップ コードを作成する ホストチームにプルリクエストを送る コントリビューションの準備をする
39. 39 2-3 コントリビューションを始めてみよう 基本は、次の3ステップ コードを作成する ホストチームにプルリクエストを送る コントリビューションの準備をする
40. 40 2-3 コントリビューションの準備をする 考え方のポイントは ホストと「共通課題」になりそうかどうか 他に考えておくべきことは？
41. 41 2-3 コントリビューションの準備をする 取り組む前に… 考える必要がある3つのポイント リードタイム 信頼関係の構築 変更を受け取ってもらうための戦略
42. 42 2-3 コントリビューションの準備をする • コミュニティに参加して馴染むまでの時間 （開発環境、コード、雰囲気） • 何回かコントリビューションすると、 リードタイムは短くなります リードタイム
43. 43 2-3 コントリビューションの準備をする 信頼関係の構築方法 • 期待を裏切らないようにしよう！ →ちょっと時間がかかりそうなことは事前に伝えよう • いろいろなコミュニケーション方法を使い分けよう！ →メールだけでは細かなニュアンスが伝わらない Web会議で話す、F2Fで合う機会を作ることも必要
44. 44 2-3 コントリビューションの準備をする 変更を受け取ってもらうための戦略 • 何かコードを書く前に、方向性の確認をしておく （それが本当に必要なものなのか？） • オープンな場で議論して、 議論の過程が見えるようにする
45. 45 2-3 コントリビューションを始めてみよう 基本は、次の3ステップ コードを作成する ホストチームにプルリクエストを送る コントリビューションの準備をする
46. 46 2-3 コードを作成する •相手のルールは守ろう コーディング規約 •事を起こす前のコミュニケーションで、仲良くなろう コミュニケーションの過程は、オープンな場で行おう •自分で解決できそうにない部分は、できないと言おう では機会が見つかったら… コードを書こう！ …その前に、壁になりそうなものは取り除こう！それを取り除くには？ 次の人のためになるよ 自分も検索できる ようになるよ
47. 47 2-3 コントリビューションを始めてみよう 基本は、次の3ステップ コードを作成する ホストチームにプルリクエストを送る コントリビューションの準備をする
48. 48 2-3 プルリクエストを送ろう！ 一気に、大きな変更入れないようにしよう！少しづつ順番に入れていこう • できるだけ簡単に取り込んでもらえるように、送るときには、テストしよう！ • 説明をつけよう！ 送るときのポイント マナー
49. 49 2-4 コントリビューションするメリットは？ （個人） • 必要な部分へのコントリビューションでモチベーションを維持して取り組むことができる 単独で作業する代わりに、ホストチーム(アップストリーム)と作業するメリット 他の人と時間を過ごすメリット 自分が必要なところに取り組むことのメリット • レビューと改善のサポートと指導を受けられる → 開発作業が大幅にスピードアップ • 新しいツール、ソフトウェアについて実践的に学べる機会がある → 自分も後で使える • 複数の異なるプロジェクトに関係する → それぞれの良い点が活かせる • 自分のチームの境界を超えて人間関係と評判が広がる → いろんなところに意見を反映できる
50. 50 2-4 コントリビューションするメリットは？ （チーム） • 「独自実装で自分で全てのバグ抱える」ことと、「既存実装で時間とお金を節約するが、 自由に仕様が決められない」ということの中間の解を得られる • 再実装と再利用とのバランスをとることが容易になる アップストリームで取り組むメリット 他チームのプロジェクトでアクティブなコントリビュータとして働くことのメリット InnerSource の方法を使うメリット • メンテナンスのコストと時間をアップストリームプロジェクトに任せられる • プロジェクト方向性とスケジュールに発言権を持てる → 自チームに有益となる可能性 ➢ アップストリームで新しいリリースごとテストが行われる ➢ コントリビューションしたものの互換性のチェックはアップストリームで確認される
51. 51 2-4 コントリビューションするメリットは？ （会社） • 複数の実装が維持されなくなる • 理解しやすく、再利用しやすくなり、結果としてモジュール化される • より多くの視点でコードの変更が精査され、品質とセキュリティの向上につながる 企業レベルで InnerSource を行うことのメリット 会社全体で共有することのメリット プロジェクトの透明性が高まることのメリット • チーム間のコラボレーション促進で、イノベーションを推進できる • バスファクター(いなくなったら困る人)が1～2人という状況を回避できる リスクのあるプロジェクトがわかりやすくなる • ベストプラクティスやポジティブなイノベーションが、簡単に組織全体に広がる 職場環境の改善が組織全体に広がりやすくなり、従業員が定着する
52. 52 52 03 プロジェクトのまとめ役になろう 【トラステッドコミッター】
53. 53 プロジェクトの立ち上げ時には PJリーダー、開発チームリーダー 的な役割がありますよね？ プロダクトオーナー InnerSource では がそれらに該当します！ トラステッドコミッター 3-1 トラステッドコミッターの役割の紹介 InnerSource では、トラステッドコミッター(TC)の役割がとても重要！ トラステッドコミッター
54. 54 3-1 トラステッドコミッターの役割の紹介 • 品質の確保 • コミュニティの健全性維持 • コミュニティへの参入障壁を下げる • コミュニティのレベル向上 • コミュニティのニーズを支持 （トラステッドコミッター） 責任の範囲 トラステッドコミッターは の両方の面倒をみる 技術 コミュニティ（コラボレーションする人全員） +
55. 55 ポイント 3-2 品質の確保について TCは技術や品質に関する意思決定または意思決定の調停を行う権利を持つ やり方 コミュニティ(とコード)の寿命を伸ばすための将来への投資 ・・・ だからです 何故修正を行わないの？ ・ 品質基準を決める ・ コードのピアレビューを行って受け入れ可否を判断する ・ (修正する代わりに) レビューの結果をフィードバックする ・ コードのマージを行う ・ 時間がかかる場合、新しい要求が生じる場合などは、スケジュールの修正を行う
56. 56 •健全なコミュニティとは？ • コントリビューターがソフトウェア開発に時間を費やすことができる • コントリビューターが能力を高めることができるようになっている 3-3 コミュニティーの健全性維持 •なぜコミュニティができるのか？ • 共通の課題や目的があるから • コミュニティーの他のメンバーと一緒に仕事をするのが楽しいから → 結果として継続的に成長
57. 57 • コミュニティー共通の課題を明確に表現して宣伝する → つまりはマーケティング • コントリビューションを贈り物として扱い、称賛する • メンタリングを行う （何故改善する必要があるか、どう改善する必要があるか、理由と方向性を示す） • 必要に応じて、行動規範を作成して実行する • 双方が定期的にお互いを知り合う機会を提供する • 紛争を平和的に解決する機会を作る 3-3 コミュニティーの健全性維持 コントリビューターが歓迎されて感謝される環境を作るように努力する トラステッドコミッターが行うことコミュニティー健全性維持のための行うこと
58. 58 3-4 コミュニティメンバーのレベルアップ • コミュニティの維持（利用者やコントリビュータから将来トラステッドコミッターを発掘） • コミュニティの活性化（スピードアップ、アウトプット品質の向上） • 製品やコミュニティのマーケティング • 貢献する機会の創出（例：ドキュメンテーション、テスト自動化） • メンタリング（コードを受け入れ可能なレベルにする指導） • 成長する可能性のあるコントリビューターを発掘 • コントリビュータ、TC双方の学習と成長（例：メンタリング能力向上） • トップタレントの維持 貢献する機会を伝え、コントリビューターを支援したり指導する より優れたソフトウェアをより早く作成するコミュニティ能力向上につながる コミュニティメンバーのレベルアップは何故必要？ トラステッドコミッターがコミュニティメンバーのレベルアップのために行うこと
59. 59 3-5 コミュニティへの参入障壁を下げる • (会社の中なので)潜在的なコントリビューターの数が少ない中で、見つけやすくする • 他の仕事もある中で、なるべく手間を掛けずにコントリビューションできるようにする 何故、参入障壁を下げないといけないか？
60. 60 • リポジトリに何があるのか、何に使えるのかを説明 • ライセンスに関する情報（InnerSourceライセンス） • ソフトウェアの入手方法、ビルド方法、テスト方法、使用方法についての詳細な指示を提供 • バグレポートや機能リクエストはどうやって提出すればいいですか? • 質問がある場合は誰にどのように連絡すればいいのか? • コードスタイル、分岐、コミットメッセージの規約は？ • 貢献の「完了」の定義は？ • 貢献を管理するプロセスステップとは？ • 貢献が承認された後、貢献したコードをサポートするという点ではどのようなことが期待されていますか? • 行動規範とは何ですか? 3-5 コミュニティへの参入障壁を下げる • HELPWANTED を作成して、どのようなものが足りていないか明示する (例：アートワーク、イベントの企画、要求機能) 参加までに迷わない道筋を用意する！ 繋がれる README を用意 CONTRIBUTING を作成して コントリビューターに 何が期待されているか を説明 オプション トラステッドコミッターが参入障壁を下げるために行うこと 使える わかる
61. 61 3-5 コミュニティへの参入障壁を下げる 参加までに迷わない道筋を用意する！ 繋がれる 使える わかる トラステッドコミッターが参入障壁を下げるために行うこと できるだけ多くの人が貢献できるように ・ドキュメントを用意して基本的な質問に答えられるようにする ・貢献することがポジティブになる雰囲気を作りだす
62. 62 3-6 コミュニティのニーズを支持する • 組織との信頼関係を構築する • コミュニティの利益と社内のソフトウェアの長期的な健全性のために行動する • 技術的なリスクだけでなく、コミュニティに関連するリスクをマネージャーに伝える • コミュニティや個々のコントリビューターの仕事を外から評価（称賛）する • (必要に応じて)コントリビューターのマネージャーと話し合いを行うなどのロビー活動をする トラステッドコミッターが行うこと 個々の投稿者の利益とコミュニティ全体の利益を考えて コミュニィの健全性を維持することで、 コミュニティと組織の両者の信頼関係を構築
63. 63 3-7 トラステッドコミッターになる トラステッドコミッターを1人持つか複数持つか (規模やリスクで判断する) 例：トラステッドコミッターの仕事を分担するローテーション・システム トラステッドコミッターになるにはどうすればいいの？ • 開発リーダー（クラス）になる • コミュニティ活動で、周りから認められる トラステッドコミッターになるために行うことは？ • プロジェクトについて深い技術的能力を持つ • プロダクトオーナーやマネージャーと効果的にコミュニケーションをとれるようになる • コントリビューターをレベルアップさせる意欲と忍耐力を示す • 感情的ならずに意見を受け止められるようになる • コーディングより、コミュニケーション・メンタリングに注力する トラステッドコミッターになるための心構えは？ • 自発的に引き受ける 会社や マネジメント層で 考えること
64. 64 コラム：”トラステッドコミッター”という名前について 他のコミュニティにおけるトラステッドコミッターと似た役割 • Apache Software FoundationにあるCommitter（コミッター） • GitHubにあるMaintainer（メンテナー） トラステッドコミッターは何が違うのか？ • マネージメント層とコミュニティの両方から「信頼されている」からこその役割 • コミュニティに対する責任が追加され、オープン性と透明性を醸成する • 開発プロセスやプロダクトに対する他からの信頼を構築する 技術指向の責任範囲 なぜトラステッドなのか？ コミュニティ指向の責任 信頼の獲得
65. 65 65 04 プロダクトオーナーとしての立ち回り 【プロダクトオーナー】
66. 66 プロジェクトの立ち上げ時には PJリーダー、開発チームリーダー 的な役割がありますよね？ プロダクトオーナー InnerSource では がそれらに該当します！ トラステッドコミッター 4-1 プロダクトオーナーとは？ InnerSource におけるプロダクトオーナーとは？ プロダクトオーナー
67. 67 4-1 プロダクトオーナーとは？ 「中間管理職 (ミドルマネージャー)」と呼ばれる人？ • それぞれの組織において、上層部のビジョンの執行に責任を負う人 • 予算管理や執行をする人 • 部・課・プロジェクト・チームなどの単位の責任者 InnerSource におけるプロダクトオーナー • 方向性に対して責任を持つ人（※注：開発だけでなく） トラステッドコミッターとプロダクトオーナーが 同一人物の場合もある
68. 68 4-2 InnerSource のプロダクトオーナーとして最初に心がけること オープンプランニング・ オープンドキュメント 計画とそれに関係する文書 オープンコード ソースコードの公開
69. 69 4-2 InnerSource のプロダクトオーナーとして最初に心がけること オープンコード • コードを会社の全員が見えるようにする • 修正や機能実装を待ったり、 エスカレーションしたり・されたりする必要がなくなる • それぞれの優先順位に基づいて、コントリビューションできるようになる 効果 • 他の開発者が他のコードベースでコントリビューションでき、 それを受け入れるプロセスがある
70. 70 4-2 InnerSource のプロダクトオーナーとして最初に心がけること オープンプランニング・オープンドキュメント • 標準化された方法(同じ場所)でプランニングプロセスやドキュメントを公開すること • プロジェクトや製品ごとにドキュメントがどこにあるのかわかる(検索できる) • 見つけてもらえ、利用してもらえ、フィードバックがもらえる • 他のチームが何に取り組んでいるのか、現在何を優先しているのかを 知ることで、より効果的にチーム間の調整を行うことができる • 議論の履歴を元に、優先順位が変更される理由などが明確になり、 チーム同士の信頼関係構築につながる • コラボレーション可能なチームを簡単に見つけられる • お互いの開発文化の違いを知ることができる 効果
71. 71 4-3 プロダクトオーナーの役割と責任 トラステッドコミッターの選抜とサポート 他のプロダクトオーナーとの交渉 環境の整備（仕事をすすめる上での） 社内マーケティング
72. 72 4-3 プロダクトオーナーの役割と責任 トラステッドコミッターの選抜とサポート 他のプロダクトオーナーとの交渉 環境の整備（仕事をすすめる上での） 社内マーケティング
73. 73 4-3 プロダクトオーナーの役割と責任 • 見積などの協力を依頼 • トラステッドコミッターのメンタリング トラステッドコミッターの選抜とサポート
74. 74 4-3 プロダクトオーナーの役割と責任 トラステッドコミッターの選抜とサポート 他のプロダクトオーナーとの交渉 環境の整備（仕事をすすめる上での） 社内マーケティング
75. 75 4-3 プロダクトオーナーの役割と責任 • 制約（人・時間・資金など）の中で、 自チームの意見を代弁して理解してもらう • 個々のチームのプロセスを尊重しつつ、 必要に応じて他チームにも指導を行う 他のプロダクトオーナーとの交渉
76. 76 4-3 プロダクトオーナーの役割と責任 トラステッドコミッターの選抜とサポート 他のプロダクトオーナーとの交渉 環境の整備（仕事をすすめる上での） 社内マーケティング
77. 77 4-3 プロダクトオーナーの役割と責任 • チームに対するドキュメンテーションの時間の確保 • オープンドキュメンテーションに時間を割くことへの理解 • UXやUIの標準、API標準、テスト要件等の明確化依頼 • 開発者が安心して活動できる環境の整備 • 標準的な開発ツールの整備の許可 環境の整備（仕事をすすめる上での）
78. 78 4-3 プロダクトオーナーの役割と責任 トラステッドコミッターの選抜とサポート 他のプロダクトオーナーとの交渉 環境の整備（仕事をすすめる上での） 社内マーケティング
79. 79 4-3 プロダクトオーナーの役割と責任 • コードを利用してもらえそうなプロジェクトの発掘 (似たような機能開発をしているプロジェクトの発掘) • コードを提供してもらえそうなプロジェクトの発掘 • ベストプラクティスや失敗談の共有 • Codeathon / Hackathon開催など、 さまざまな種類のアナウンス 社内マーケティング
80. 80 80 4-4 InnerSource のプロダクトオーナーになる利点 ⚫ コラボレーションで、 より少ないリソースでより多くのことを達成できる実感が得られる ⚫ チームの冗長性が向上する ⚫ プロセスを公開することで政治的な問題にも対処できる ⚫ トラステッドコミッターのサポートなど、 新たな役割と責任を得ることができる ⚫ 社内マーケティングスキルを身につけるチャンスが得られる ⚫ 仕事に対する評価が高くなる
81. 81 81 05 InnerSource の実践
82. 82 1. 問題意識を共有する・発見する 2. 共通の問題意識をもつ人達で意見交換する 3. 課題を解決する 4.（個別対応が必要な部分も作る） 5. 4の途中に出る共通課題も共有する 6. ノウハウが共有され、新しいアイデアが出る（可能性がある） 7. １に戻る 5-1 InnerSource 実践のための準備 InnerSource 実践に必要なもの： 「共通」の問題・課題 賛同者 （有識者） 提案者 賛同者 （開発者やユーザー） オープンな場 課題解決のアイデア 課題 解決策を具現化する実装(ソースコード)
83. 83 5-2 「共通課題」 を見つけるには？ •まずは身近なところから ・ 同じ部門・組織の中から ・ 同じような事業の関係者の中から ・ 会社全体で •どのようなタイミングで考えるのが良いか？ ・ 新しいプロジェクトを始めるとき ・ 要件定義やシステム設計するとき ・ 改造・リファクタリングするとき
84. 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が対象とする領域 会社内なら外に出せない「共通課題」も解決できる！
85. 85 5-3 InnerSource 実践：3つの武器 (場としての) システム (実践可能な) ルール マインド 解決する課題 人
86. 86 5-4 「共通課題」 解決の場の準備 共有されたオープンな場所 トラステッドコミッター コントリビューター ポータルサイト ソースコードリポジトリ 登録 参加 発見 オープン性や透明性の確保に向けて、共通の場を用意 システム
87. 87 5-5 InnerSource実践ルールの整備（InnerSourceライセンスの例） 共有されたオープンな場所 リポジトリ InnerSourceライセンス：自由に利用・改変OK、フィードバックしてね （製品利用要相談） 開発部門A 開発部門C 開発部門B 開発部門D コントリビューション コントリビューション (InnerSource or OSS License) 参照・利用 参照・利用 ルール
88. 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! コストの考え方の一例 ルール
89. 89 5-5 InnerSource実践ルールの整備（例：コンソーシアム設立） 共有されたオープンな場所 リポジトリ 自由に利用・改変OK、フィードバックしてね （製品利用要相談） 開発部門A 開発部門C 開発部門B 開発部門D コントリビューション 参照・利用 参照・利用 コンソーシアム加入者は製品利用可（保守契約別途） コントリビューション (InnerSource or OSS License) ルール
90. 90 5-6 マインド醸成（株式会社 東芝の事例） マニフェストの作成 各種イベントの実施 （ハッカソン・Webinarなど） マインド Ref: 共に創る未来：ソフトウェア開発における共創・協働のアプローチと戦略、小林良岳 https://speakerdeck.com/ystk
91. 91 5-7 実践事例１：組込みLinux®ディストリビューションの展開 Linuxディストリビューション 開発元部門 開発部門A 開発部門C 開発元が展開 開発部門B Linuxディストリビューション Ref:インナーソースをはじめてみよう！共通課題解決にむけた革新的な取組み、小林良岳 https://qiita.com/ystk-k/items/9045c17a4b529e8cda48 ※ Linuxは、Linus Torvalds 氏の米国およびその他の国における登録商標です
92. 92 5-7 実践事例１：組込みLinuxディストリビューションの展開 Linuxディストリビューション 開発元部門 開発部門A 開発部門C 開発元が展開 開発部門B Linuxディストリビューション コピー Ref:インナーソースをはじめてみよう！共通課題解決にむけた革新的な取組み、小林良岳 https://qiita.com/ystk-k/items/9045c17a4b529e8cda48
93. 93 5-7 実践事例１：組込みLinuxディストリビューションの展開 Linuxディストリビューション 開発元部門 開発部門A 開発部門C オープンな場で共有 開発部門B Linuxディストリビューション 設定 情報 Ref:インナーソースをはじめてみよう！共通課題解決にむけた革新的な取組み、小林良岳 https://qiita.com/ystk-k/items/9045c17a4b529e8cda48
94. 94 5-7 実践事例１：組込みLinuxディストリビューションの展開 Linuxディストリビューション 開発元部門 開発部門A 開発部門C オープンな場 開発部門B 委託先A 委託先C Linuxディストリビューション Ref:インナーソースをはじめてみよう！共通課題解決にむけた革新的な取組み、小林良岳 https://qiita.com/ystk-k/items/9045c17a4b529e8cda48
95. 95 5-7 実践事例１：組込みLinuxディストリビューションの展開 Linuxディストリビューション 開発元部門 開発部門A オープンな場 開発部門B Linuxディストリビューション OSS コミュニティ 開発部門C 委託先C 開発部門D 委託先A Ref:インナーソースをはじめてみよう！共通課題解決にむけた革新的な取組み、小林良岳 https://qiita.com/ystk-k/items/9045c17a4b529e8cda48
96. 96 5-8 実践事例２：技術カタログをコードで作成 共有されたオープンな場所 技術カタログサイト デプロイ フィードバック 閲覧 部門メンバー 技術カタログ ソースコードリポジトリ 編集＆プルリクエスト トラステッドコミッター レビュー ＆マージ プロダクトオーナー Ref:インナーソースをはじめてみよう！共通課題解決にむけた革新的な取組み、小林良岳 https://qiita.com/ystk-k/items/9045c17a4b529e8cda48
97. 97 5-8 実践事例２：技術カタログをコードで作成(プロダクトオーナーの活動) トラステッドコミッターの選抜とサポート 他のプロダクトオーナーとの交渉 環境の整備（仕事をすすめる上での） • ドキュメンテーションの時間の確保 → 社内展向け活動 • 安心して活動できる環境の整備 → 共通開発環境 社内マーケティング • 社内向け展示会のコンテンツとしてそのまま利用
98. 98 5-8 実践事例２：技術カタログをコードで作成 共有されたオープンな場所 技術カタログサイト デプロイ フィードバック 閲覧 コントリビューター 技術カタログ ソースコードリポジトリ 編集＆プルリクエスト トラステッドコミッター レビュー ＆マージ プロダクトオーナー 編集＆プルリクエスト Ref:インナーソースをはじめてみよう！共通課題解決にむけた革新的な取組み、小林良岳 https://qiita.com/ystk-k/items/9045c17a4b529e8cda48
99. 99 5-8 実践事例３：技術中計を公開形式で実施（InnerSourceの思想を利用） 共有されたオープンな場所 テーマリーダー Teams / OneDrive （会社メンバ誰でもアクセス可） 投稿・編集・コメント返信 レビューア レビュー意見投稿 プロダクトオーナー 意見・要望 修正案の提案 部門長 メンバ 社内SNS 閲覧 役員・他部門長・メンバなど 投稿 確認・承認 Ref:インナーソースをはじめてみよう！共通課題解決にむけた革新的な取組み、小林良岳 https://qiita.com/ystk-k/items/9045c17a4b529e8cda48
100. 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/ ③ 各種イベントで発表
101. 101 101 外堀から埋めていく・・・
102. 102 102 06 InnerSource FAQ
103. 103 6-1 なんでも共有すれば良いのでしょうか？ 回答：いいえ 共通の課題か気づかないことも有るため、 早い段階からアイデアや悩みを共有しておくことが大切です 望ましい共有のケース • 共通課題に基づく共有 • 自分が問題意識を持っているものの共有 (もしかしたら誰かの課題解決になるかも) 望ましくない共有のケース • 捨てたいものを共有 • なにかあっても答えられないものの共有 ポイント
104. 104 6-2 オーナー(リーダー) になりたくない！ • 必要だから作るのではないでしょうか？ （自分で好きなように作るために始めてみませんか？） • 使ってもらいたい技術を作っているのではないですか？ （たとえ Under the Table であったとしても） • 困ったときだけ相談すると、回答に時間かかります （はじめて問題を見た人は、それを理解しないといけません） 回答：リーダーを強く意識するより次のことを考えてみてください • 一人で作ることに比べて、仲間がいることは次の利点があります ➢ 困った時にすぐ相談できます（仲間は、質問の意図を深く理解しているかもしれません） ➢ バグを指摘してもらえるかもしれません（後で困ったことにならずに済むかもしれません） ➢ バグを直してもらえる（かもしれません） • オーナーの役割は、興味を持っている人が増えれば分担すれば良いのです (調整できるかもしれません) • オーナーとしての負荷は調整可能です ポイント
105. 105 6-3 公開とか貢献とは言っても、何で人のために・・・ • 自分が使いたい(作りたい)という判断したのでは？ • バグ報告するだけでも貢献です • 自分で修正することになっても、報告していれば仲間が増えます • 全部自分で作ると、大変ですよね？ • 一緒に考えられるところは一緒にやって、研究の時間を作ってください • 自分だけでは気づかない点の気付きが得られるかもしれません 回答：「自分が必要なもの」という前提のもとに行動するので、 結果として人のためではなくて自分のためになります ポイント 間違って同じものを作らなくて済むかもしれません
106. 106 6-4 全然自分に得じゃないよね？ 回答：損得の話ではなくて、Give & Given の話です • ある部分は負担かもしれませんが、 別の所で助けてもらえるかもしれません • 常にバランスするとは言えませんが、 継続することで効果を実感できる日が来るかもしれません • 課題をオープンにしているだけでも貢献です。 なぜなら同じ課題を持つ人が集まるきっかけを作っているので ポイント
107. 107 107 07 まとめ
108. 108 InnerSource は企業文化に変革をもたらす活動です！ 一緒に InnerSource をはじめましょう！ 7 まとめ • InnerSource の多くのメリット • 開発スピード、品質、メンテナンス性の向上 • 開発リソースのスケール • 開発者の満足度向上 • InnerSource における役割 コントリビューター、トラステッドコミッター、プロダクトオーナー • InnerSource の実践 オープンな場で透明性を確保して開発を行うことの大切さ
109. 109 共創・協調領域はコントリビューション オープンな活動は社内も世界も変えられる オープンに(仲間と)暗躍する！ 109 7 本当のまとめ
110. 110 Think OPEN
111. 111 Thank you!
113. 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/
114. 114 114 Appendix
115. 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%