InnerSource Pattern: コミュニケーションツーリング

コミュニケーションツーリング
InnerSource Patterns
Speaker: Yuki Hattori (@yuhattor)
Pattern Author: Isabel Drost-Fromm

View Slide

概要
インナーソースのプロジェクトは、開発チームの外で使用されていますが、ユーザーはヘルプを得たり、プ
ロジェクトチームと連絡を取ったりするのに苦労しています。このアイデアは、ディスカッションが可視化
され、アーカイブされ、検索可能になることを可能にする標準的なコミュニケーションツールを設定し、文
書化することです。
InnerSource Patterns:
@yuhattor
2

View Slide

状況
チームは別のチームのコンポーネントに依存しており、そのコンポーネントにコントリビュートしたいと思
いっています。コミュニケーションは文書で行われる場合でも、1
対1
で行われています。
@yuhattor
3

View Slide

問題
チームは、そのコンポーネントのダウンストリームユーザーからのコントリビューションを受け入れること
ができます。しかし、調整とコミュニケーションはアドホックな方法で行われ、支離滅裂な情報が共有され
たり、回答が遅れたり、コントリビューターが明確な回答を受け取る前に複数のホストチームのメンバーに
問い合わせをしたりすることがあります。
@yuhattor
4

View Slide

組織に働く力学
ホストチームはコントリビューションを受けることに興味があり、コントリビューターを指導すること
に積極的です。
チームは口頭でのコミュニケーション文化が強く、プロジェクト特有の非同期コミュニケーションチャ
ンネルを設定する経験は浅いです。
コミュニケーションチャネルは、連絡を取るべき特定のグループと連携しているかもしれませんが、コ
ミュニケーションの目的によって連携しているわけではありません。
@yuhattor
5

View Slide

ソリューション
ホストチームは、社内で公開され、アーカイブされ、検索可能で、リンク可能なコミュニケーション・チャ
ネルを提供することの利点を明確にする必要があります。
インナーソースプロジェクトのコミュニケーションチャネルを合理化する際の目標は、特定の人々の周りで
はなく、トピックの周りのコミュニケーションを調整することであるべきです。
注意
共有のチャンネル以外でもコミュニケーションは可能ですが、できるだけ多くの情報を非同期チャンネ
ルにつなぐべきです。
すべてのコミュニケーション・チャンネルはプロジェクトの
README.md
で文書化されるべきです。ホ
ストチームのメンバーは、個人的に受けた質問を公式のコミュニケーションチャンネルに戻すよう努力
する必要があります。
@yuhattor
6

View Slide

ソリューション:
ポイント
プロジェクトは、ホストチームのメンバーだけでなく、ダウンストリームユーザーやコントリビュータ
ーもフォローできるように、構造化されたコミュニケーション、意思決定、進捗追跡が透過的に行われ
る独自のイシュートラッカーを持っている必要があります。
プロジェクトは、あまり厳密でない構造を持つ1
つ以上のディスカッションチャンネルを持つべきです。
一般的に、これはメーリングリスト、オンラインフォーラム、あるいはアーカイブされたチャットチャ
ンネルになります。通常、プロジェクトのためのチャンネルは1
つで十分ですが、トラフィックが増えす
ぎた場合は、プロジェクトの使用に関する議論とプロジェクトの開発に関する議論を分けることが有用
です。
さらに、プロジェクトはトラステッドコミッターの間で機密のやりとりができるプライベートチャンネ
ルを一つ持つべきです -
たとえば、ホストチームにさらにトラステッドコミッターを追加するなどで
す。このチャンネルは、デフォルトではオープンで、非常に稀な状況下でのみ非公開になるように、細
心の注意を払って使用されるべきです。
@yuhattor
7

View Slide

結果の状況
公式の非同期コミュニケーションチャネルを設定し、一貫して使用することで、同様の質問が再び出てきた
ときに再び参照できる受動的なドキュメントのベースレベルを作成することができます。
コミュニケーションがオープンに行われることで、他の人も簡単にプロジェクトの進捗を追うことができ、
積極的に貢献することができます。また、他の参加者が潜んで読んでいることで、参加するための障壁が低
くなり、コントリビューションを受ける可能性が高くなります。
質問に対する回答が公開されることで、より多くの人が自分の視点を追加し、全体像を把握することができ
ます。これは、ホストチームのメンバーだけでなく、プロジェクトのユーザーも含みます。
非同期チャネルでコミュニケーションをとることで、タイムゾーンや会議のスケジュール、チームのルーチン
など、異なるスケジュールの参加者がプロジェクトに有意義に貢献することができます。
このようなチャンネルで質問に答えることは、他のチームメンバーがそれを聞いて追加情報を提供できるだ
けでなく、同じ質問をした他のユーザーが前回の回答を見る(
または後で見つける)
ことで、説明を繰り返す
必要性を低くすることを意味します。
@yuhattor
8

View Slide

事例
Europace AG
Paypal Inc.
@yuhattor
9

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
10

View Slide

InnerSource Pattern: コミュニケーションツーリング

InnerSource Pattern: コミュニケーションツーリング

Yuki Hattori

More Decks by Yuki Hattori

Other Decks in Technology

Featured

Transcript