InnerSource Patterns: 基本原則ガイダンスの文書化

基本原則ガイダンスの文書化
InnerSource Patterns
Speaker: Yuki Hattori (@yuhattor)
Pattern Authors:
Isabel Drost-Fromm
Georg Grütter

View Slide

概要
「オープンソースのベストプラクティスを組織内に適用する」という通常のインナーソースの説明は、オープ
ンソースのバックグラウンドがない人々にはうまく機能しません。
解決策として、インナーソースの最も重要な原則を文書化し広く公開します。
InnerSource Patterns:
@yuhattor
2

View Slide

問題
組織は、インナーソースをより大規模に展開しようとしています。
インナーソースの取り組みは、オープンソース愛好家の中で始まった
現段階の目標は、オープンソースの経験がない人たちからの賛同を得ることです。
「オープンソースのベストプラクティスを適用する」という典型的なスローガンは最適ではなく、イン
ナーソースが何であるか、またどのようなツールを使うべきなのかを伝えることができない
結果として、組織におけるインナーソースの適用が遅くなることにつながります
チームはインナーソースのゴールが何であるか、そしてどうやったら最適の実装方法を見出せるのかを
場当たり的なアイデアをもとに解決しようと試みます。
それはコントリビューターがチームの境界を越え始めたときに混乱を引き起こす結果にも繋がってしま
うことがあります。
@yuhattor
3

View Slide

ケーススタディ
ある組織での初期の実験では、オープンソースコラボレーションのベストプラクティスが有益であるこ
とが示されました。次のステップは、オープンソースの深いバックグラウンドがないチームや個人にそ
のイニシアチブを移すことです。
そして今の目標は、インナーソースイニシアチブの目標と、これらの目標達成に向けた明確な道筋を明
確に伝えることです。
@yuhattor
4

View Slide

状況
インナーソースという言葉が社員の間で広がり始めています。
イニシアチブ自体はオープンソースの愛好家の間で始まった取り組みでした。
@yuhattor
5

View Slide

組織に働く力学
チームは、インナーソースの重要な側面が何であるかを正確に伝えるのに苦労しています。
オープンソースの経験が不足している人々は、オープンソースのベストプラクティスを組織にもたらすこ
との意味を理解することができません。
日常的にインナーソースのベストプラクティスに従おうとするチームは、自分たちがやっていることが
一般的なインナーソースの典型例に沿っているのかを判断するのに苦労しています。
@yuhattor
6

View Slide

ソリューション
組織内でインナーソースの取り組みを推進する人は、オープンソースの深いバックグランドを持たず、イン
ナーソースを直感的に理解できていないチームや個人を支援する必要があります。
以下の2
つの分野を文書化することで、チームや個人に対して明確な情報を提供する必要があります。
1.
目的:
なぜ組織はインナーソースを採用するのか？
2.
原則:
どのインナーソースの原則は、これらの課題に対処するのに役立つのか？
以下のセクションでは、この2
つの詳細について説明します。あなたの組織が目的と原則を文書化するため
に、このセクションはよい出発点になるでしょう。
@yuhattor
7

View Slide

なぜ組織はインナーソースを採用したいのか？
かつてよりインナーソースは、組織で発生する一般的な問題を解決するのに役立つことが証明されていま
す。しかし幾多ある組織的な課題のうち、あなたの組織がインナーソースを用いて解決したい課題はなんで
しょうか。その問題を特定するためには一般化するのではなく、組織の課題に一致するソリューションを正
確に特定するようにしてください。できれば、目に見える変化を求めているチャレンジを特定するのが好ま
しいです。
@yuhattor
8

View Slide

インナーソースで対処できる課題
他の個人や組織がインナーソースのベストプラクティスに従うことによって対処しているいくつかの課題が
あるので、見ていきましょう。
強力なオーナーシップを求める文化によって引き起こされる開発のサイロを減らすため
健全なコードの再利用を促進することにより、類似の問題の解決に費やす時間を短縮し、イノベーショ
ンの速度を向上させるため
より良いクロスチームのコラボレーションによって開発速度を向上させるため
依存関係があるプロジェクトやチームの連携を、ワークアラウンドを開発したり、ただ単純に待つので
はなくエンジニアリングにおけるボトルネックを減らすことによって解決するため
品質を向上させるため
従業員の幸福度を高めるため
新入社員の成功の数を増やす
アクショナブルなドキュメントをつくる
@yuhattor
9

View Slide

これらの課題を解決するのに役立つインナーソースの原則
チームがインナーソースがどのような問題に対処するのに役立つかをひとたび理解したら、次のステップ
は、これらの課題に対処するのに役立つ原則を説明することです。
基本的なオープンソース開発の原則に基づき、以下のガイドラインが成功に役立つと証明されています。
1.
コードは組織内で透明性を持ってホストされている
2.
機能リクエストよりもコントリビューション
3.
失敗することは学習をするチャンスであるということ
4.
口頭より文字で伝える
5.
書面によるアドバイスを永続的で検索可能なアーカイブに蓄積できるようにする
6.
トラステッドコミッターに対するリワード
@yuhattor
10

View Slide

1.
コードは組織内で透明性を持ってホストされている
ソースコード、ドキュメント、プロジェクト開発に関連するデータは、組織内の誰もが利用でき、簡単に見
つけることができる必要があります。
@yuhattor
11

View Slide

2.
機能リクエストよりもコントリビューション
プロジェクトのすべての関係者は、潜在的なコントリビューターとして扱われ、サポートされます。コント
リビューションはリクエストではなく、提案にとどめましょう。
コントリビューション前にきちんと連携をしておくことにより、無駄な労力を省くことができます。プロジ
ェクトは摩擦を避けるためにコントリビューションのガイドラインを提供します。
@yuhattor
12

View Slide

3.
失敗することは学習をするチャンスであるということ
組織全体で仕事が見えるため、どんなミスもメンバーに見えてしまいます。「ミスは何としても避けなけれ
ばならない失敗」ではなく「学習のための機会である」という文化が確立されなければなりません。
@yuhattor
13

View Slide

4.
口頭より文字で伝える
複数のチームにまたがるプロジェクトでは、潜在的に会議のスケジュールが異なるため、非同期でのコ
ラボレーションを可能にする必要があります。
インナーソースのプロジェクトのゴールは、新しいコントリビューターを集めることです。
潜在的な将来のコントリビューターがプロジェクトに参加するハードルを下げることが必要であり、セ
ルフサービスでプロジェクトの進捗状況を追跡することができるようにしておく必要があります。
プロジェクトに関連するコミュニケーションが同期的なコミュニケーションを介して行われる場合、議
論された内容は、ドキュメンテーションのチャネルで透明化しておく必要があります
最終的な意思決定はそのコミュニケーションチャネルでのみ決定されるべきです。
これによって、新しく参加する人にとって非常に価値のある受動的なベースドキュメンテーションが生
まれます。
@yuhattor
14

View Slide

5.
書面によるアドバイスを永続的で検索可能なアーカイブに蓄積でき
るようにする
プロジェクトのすべてのコミュニケーション、特に決定事項やその決定に至るまでの議論はアーカイブされ
る必要があります。また、コミュニケーションは安定したURL
で参照できるようにする必要があり、過去の
コミュニケーションも、簡単に検索できる形で保存される必要があります。
ただし、2
つの注意点があります。
1.
これは構造化された文書に取って代わるものではありません。しかし一方で、構造化されたドキュメン
トを収集するための出発点として機能もします。
2.
すべてを文書化し、組織全体がアクセスできるようにするというルールには例外があります。人に関す
る議論やセキュリティに関する議論は機密事項であり、人前で行うべきではありません。
@yuhattor
15

View Slide

6.
トラステッドコミッターに対するリワード
すべての貢献(
ソースコード、ドキュメント、バグレポート、議論への意見、ユーザーサポート、マーケティ
ングなど)
は歓迎され、リワードの対象になります。プロジェクトをサポートする人は、トラステッドコミッ
ターとしてプロジェクトに招待され、全てのトラステッドコミッターのリストは公開されます。
@yuhattor
16

View Slide

結果の状況
組織のメンバーは、インナーソースのベストプラクティスを適用することによって、どのような課題に
対処することができるのかを理解しています。
オープンソースの経験がないメンバーが、インナーソースプロジェクトの基本的な価値観や原則を理解
することができます。
オープンソースの経験がないメンバーが、自分たちが日々行っていることを、共通の価値観に照らして
確認することができる。
組織の開発手法がオープンソースプロジェクトと類似しているため、組織のメンバーがオープンソースプ
ロジェクトに参加しやすくなります。
@yuhattor
17

View Slide

事例: Europace AG
上記のソリューションに記載されているインナーソースの原則は、ほとんどが Europace
の経験に基づいてい
ます。
詳細はEuropace
のインナーソース原則(
ドイツ語)
をご覧ください。
@yuhattor
18

View Slide

事例: GitHub
目的
GitHub
ではしばしば、チームが自分の担当外の領域に機能を提供するモデルで作業をします。よくある例と
しては、セールスエンジニアリングが営業におけるブロッカー要素を排除するために機能を提供したり、緊
急なニーズに対する特別なプロジェクトがあり、インパクトの強い機能をプロダクト全体に提供したり、チ
ームが複数のエリアにまたがって機能を提供したりすることです。
@yuhattor
19

View Slide

事例: GitHub (2)
原則
全体として、このドキュメントで説明されている原則は、オーナーとなるチームの技術的負債とサポートの
負担を増加させないようにすることに焦点を当てています。
多くの場合、チームは責任範囲内のサポートとメンテナンスのコストのために遅れており、機能に貢献する
ための余裕がないため、チームにヘルプが求められています。しかし別のチームによって新機能にかかるサ
ポートの負担や技術的負担が追加されることになると、所有するチームが新機能に取り組む時間がさらに短
縮されることを意味するため、それらが正しく行われていることを確認する必要があります。同時に、私た
ちはエンジニアが境界を越えて自由に仕事ができる会社を目指しており、ビジネスの優先事項では、コアオ
ーナーシップ以外の分野にコントリビュートすることが求められることがよくあります。
これらの原則をまとめると、「見つけたときと同じか、それ以上の状態で残す」ということになります。
@yuhattor
20

View Slide

事例: GitHub (3)
原則の例
機能負債を抱えるようなMVP
（Minimum Viable Product
）は避ける。顧客からのフィードバックを得るた
めにMVP
を出荷することは構いませんが、コントリビュートするチームはその機能セットを完成させる
ことを約束しなければなりません。例えば、以下のようなことです。
MVP
を越えて、ほとんどの顧客を満足させるソリューションにするためのコミットメント
新機能の管理を完全にサポートすること
API
のみを提供するのではなく UI
と API
の両方のインタフェースを提供する（またはその逆）
本番環境へのデプロイまで、またそれ以降も機能作業をサポートする
インクリメンタルなロールアウトの連携
顧客からの(
機能やバグに関する)
フィードバックに対応するための時間をプランニングする
正しい方法で機能を構築する(
技術的負債を作らない)
プロダクトチームおよびエンジニアリングチームとの要件およびソリューションの合意
適切なアーキテクチャと設計
クラウドおよびローカルの本番環境でサポートされている
バグの修正とドキュメントの更新
@yuhattor
21

View Slide

事例: GitHub (4)
エンゲージメント
エンゲージメントモデルを使用するのは、チームが責任範囲外の領域に機能を提供するときに、チームが実
行できる具体的な手順を示すためです。
GitHub
の一般的なエンゲージメントモデルは以下です。
プロダクトオーナーから、機能のセッティングとロールアウトプランの承認を得る
エンジニアリングオーナー(
通常、エンジニアリングマネージャーとディレクター)
から、非機能要件(
テ
レメトリ、テストカバレッジ、マルチ環境テストとサポート)
への対応を含むエンジニアリング設計の承
認を得る
新規または変更された要件のレビューとともに、コードレビューを実施する。
@yuhattor
22

View Slide

事例: Robert Bosch
のインナーソース原則
Bosch
のインナーソースイニシアチブBIOS
は以下の原則を持ちます
オープン性: BIOS
コミュニティへの参入障壁を低くします。
透明性:
徹底的に透明性を高め、仕事上の成果物、コミュニケ
ーション、意思決定を社内の全社員と共有します
自発性: BIOS
コミュニティに参加し、コントリビュートするか
どうかの判断は、各人に任されています。社員は上司に言われ
たからではなく、自発的な動機で BIOS
に参画すべきです
自己決定: BIOS
コミュニティは、何に取り組むか、いつ取り組
むか、どのようなツールやプロセスを使って取り組むかを自由
に選択することができます
功績至上主義: BIOS
プロジェクトメンバーには、その功績に基
づいて、つまりコントリビューションの質と量に基づいて権力
が付与されます
@yuhattor
23

View Slide

その他の呼び方
インナーソース原則の明示
Explicit InnerSource Principles
@yuhattor
24

View Slide

InnerSource
についてもっと知る
InnerSource Commons: https://innersourcecommons.org
Join our Slack community: https://innersourcecommons.org/slack
InnerSource Patterns: https://patterns.innersourcecommons.org
Twitter: @InnerSourceOrg
日本語 Slack
チャンネル: #jp-general
日本語 Twitter: @InnerSourceJP
@yuhattor
25

View Slide

InnerSource Patterns: 基本原則ガイダンスの文書化

InnerSource Patterns: 基本原則ガイダンスの文書化

Yuki Hattori

More Decks by Yuki Hattori

Other Decks in Technology

Featured

Transcript