diff --git a/README.md b/README.md index 2a53dcbc..a8a36c0a 100644 --- a/README.md +++ b/README.md @@ -8,3 +8,4 @@ It collects best practices for initiating, nurturing, growing, and maintaining g The Open Source Way is available in the following languages: - [English](https://github.com/theopensourceway/guidebook) (en_US) - [Chinese](https://github.com/theopensourceway/guidebook/tree/main/l10n/cn) (CN) +- [Japanese](https://github.com/theopensourceway/guidebook/tree/main/l10n/ja) (JA) diff --git a/l10n/ja/CODE_OF_CONDUCT.md b/l10n/ja/CODE_OF_CONDUCT.md new file mode 100644 index 00000000..71d246f0 --- /dev/null +++ b/l10n/ja/CODE_OF_CONDUCT.md @@ -0,0 +1,56 @@ +# オープンソースウェイ 貢献者の行動規範(Code of Conduct) + +## 私たちの誓約 + +オープンで歓迎される環境を育むため、私たち貢献者と管理者は、年齢、体型、障害、民族、性別特性、性自認と表現、経験レベル、学歴、社会経済的地位、国籍、外見、人種、宗教、性的アイデンティティや指向にかかわらず、誰もがハラスメントのない体験を得られるよう、プロジェクトとコミュニティへの参加を約束します。 + +## 私たちの基準 + +健全な環境づくりに寄与する行動の例には以下が含まれます。 + +* 歓迎的でインクルーシブ（包摂的）な言葉遣い +* 異なる見解や経験を尊重する +* 建設的な批判を謙虚に受け入れる +* コミュニティにとって最善のことに焦点を当てる +* 他のコミュニティメンバーへの共感を示す + +参加者が行う許容できない行動の例： + +* 性的な表現や画像の使用、望まれない性的関心やアプローチ +* 荒らし行為、侮辱的/貶める発言、個人または政治的攻撃 +* 公的または私的な嫌がらせ +* 明示的な許可なく他者の住所や電子メールアドレスなどの個人情報を公開すること +* プロフェッショナルな環境において不適切と合理的に判断されるその他の行為 + +## 私たちの責任 + +プロジェクト管理者は、許容される行動基準を明確化する責任を負い、不適切な行動事例に対して適切かつ公平な是正措置を講じることを期待されます。 +プロジェクト管理者は、本行動規範に沿わないコメント、コミット、コード、Wiki編集、問題報告、その他の貢献を削除、編集、拒否する権利と責任を有します。 +また、不適切、脅迫的、攻撃的、または有害と判断したその他の行為に対して、貢献者を一時的または恒久的に排除する権利と責任を有します。 + +## 適用範囲 + +本行動規範は、すべてのプロジェクト空間内で適用されます。また、個人がプロジェクトまたはそのコミュニティを代表して公の場で行動する場合にも適用されます。 +プロジェクトまたはコミュニティの代表例には、公式プロジェクトメールアドレスの使用、公式ソーシャルメディアアカウントを通じた投稿、オンライン／オフラインイベントにおける任命代表者としての活動などが含まれます。プロジェクトの代表行為は、プロジェクト管理者がさらに定義・明確化する場合があります。 + +## 施行 + +虐待的、嫌がらせ的、またはその他の容認できない行為の事例は、ombuds@theopensourceway.org 宛てにプロジェクトチームへ連絡することで報告できます。すべての苦情は審査・調査され、状況に応じて必要かつ適切と判断される対応が取られます。プロジェクトチームは +事件の報告者に関する機密保持義務を負います。 + +具体的な施行方針の詳細は別途掲載される場合があります。 + +本行動規範を誠実に遵守・施行しないプロジェクト管理者は、プロジェクト運営陣の判断により一時的または恒久的な処分を受ける可能性があります。 + +## 帰属 + +本行動規範は、[Contributor Covenant][homepage]（バージョン1.4）を改変したものです。 +原文は https://www.contributor-covenant.org/version/1/4/code-of-conduct.html で閲覧可能です。 + +[homepage]: https://www.contributor-covenant.org + +本行動規範に関するよくある質問への回答は以下を参照してください +https://www.contributor-covenant.org/faq + + + diff --git a/l10n/ja/CONTRIBUTING.md b/l10n/ja/CONTRIBUTING.md new file mode 100644 index 00000000..521bdd69 --- /dev/null +++ b/l10n/ja/CONTRIBUTING.md @@ -0,0 +1,147 @@ +# オープンソースウェイへの貢献 + +私たちは、The Open Source Way への貢献がすべてのプロジェクト参加者にとって快適で充実した体験となることを目指しており、あらゆる種類の貢献を歓迎します。 + +## 慣れるために + +このプロジェクトでは、GitHub ベースのワークフローを使用して、**ガイドブック**を構成する Markdown 形式のファイルを管理しています。ガイドブックの各**章**は Markdown ファイルです。章ファイルはフォルダで示される**セクション**に整理されています。最初の貢献先を決めるには、オープンソースウェイガイドブックの[構成](https://github.com/theopensourceway/guidebook)を確認してください。 + +また、未解決の[課題](https://github.com/theopensourceway/guidebook/issues)を確認し、解決に協力することもできます。プロジェクトのメンテナやコミュニティメンバーとアイデアを共有するには、[ディスカッション](https://github.com/theopensourceway/guidebook/discussions)を開始してください。 + +プロジェクトの詳細については、[Wiki](https://github.com/theopensourceway/the-project/wiki)をご覧ください。 + +## コミュニティの構成 + +プロジェクトの目標に最も精通した初期の中核メンバーを中心に、役割と責任を定義しました。今後は新たな貢献者の参加と共に進化し、貢献ガイドラインも適宜更新していきます。 + +現時点での役割分担： + +* プロジェクトリーダー Karsten Wade (@quaid) は、自身の初期版1.0作業から発展させるためのビジョンとリーダーシップを提供する +* 主任編集者 Brian Proffitt (@bproffitt) は、複数の執筆者や情報源と連携し、一貫性のある読みやすいガイド作成に向け編集チームを統率する責任を負う +* 主任ライター Shaun McCance (@shaunix) は、執筆者と直接連携し、コンテンツをガイド全体のレベル・スタイル・語り口に適合させる責任を負う +* 編集チーム（Brian Proffitt, Karsten Wade, Shaun McCance）は、提出されたコンテンツを磨き上げ統合し、品質とトーンの一貫性を確保する責任を負う +* 執筆チーム（Bryan Behrenshausen (@semioticrobotic), Brian Proffitt, Karsten Wade, Shaun McCance）は、ガイドブックに掲載される資料の作成、収集、その他のキュレーションを担当する + +## 貢献プロセス + +### 1. 未解決課題の確認 + +- [未解決課題リスト](https://github.com/theopensourceway/guidebook/issues)を確認し、プロジェクトが必要とする内容で自身が提供可能なものを探してください。 + +### 2. 手を挙げる + +- 対応可能な課題を見つけたら、その課題に関する議論に参加してください。既存の[課題](https://github.com/theopensourceway/guidebook/issues)への返信、新規課題の作成、またはより一般的な[ディスカッション](https://github.com/theopensourceway/guidebook/discussions)の開始で対応可能です。プロジェクト管理者やガイドブック編集者は、新規資料の追加や支援を申し出る人物を把握したいと考えています。 + +### 3. 作業を開始する + +課題は主に3種類に分類されます。 + +- `バグ`：不具合が発生しており修正が必要な事項（リンクが機能しない、単語のスペルミス、脚注の誤った参照先など） +- `機能`：追加すべき要素が不足している事項（既存章の拡充、新規章の追加など） +- `タスク`：必ずしも*壊れている*または*欠けている*わけではないが、それでも*実行*が必要な事項（章の順序変更、ガイドの新バージョン公開など） + +#### バグ修正の提供 + +`Bug`とマークされた課題を選択した場合、以下の手順に従ってすぐに貢献を開始できます。 + +- 選択した[課題](https://github.com/theopensourceway/guidebook/issues)にコメントし、貢献の意思と具体的な内容を表明してください。 +- あるいは、プルリクエストを開いて直接修正に取り掛かることも可能です！プルリクエストを未解決の課題にリンクし、作業対象をメンテナに明確に伝えてください。 +- 修正内容のフォーマット方法については、プロジェクトの[スタイルガイド](https://github.com/theopensourceway/the-project/wiki/Style-Guide)（定期的に更新）を参照してください。 + +#### 機能の追加 + +`Feature`とマークされた課題を選択した場合、以下の手順で直ちに貢献を開始できます。 + +- 新しい章を提案する場合は、ガイドブックに追加したい内容を説明する[課題](https://github.com/theopensourceway/guidebook/issues)を開いてください。準備が整っている場合は、簡潔かつ包括的な概要をスケッチしてください。これは課題自体に直接記入できます。概要に含めるべき内容についてさらにガイダンスが必要な場合は、遠慮なく質問してください！空白のページ（またはファイル）があっても、始めるのを躊躇わないでください。 +- 既存の章への追加内容を提案する場合は、プロジェクトリポジトリをフォークし、選択したトピックに関する内容を追加してください。その後、変更点をまとめたプルリクエストを送信し、編集者が追加内容をレビューし、あなたと協力して磨きをかけることができます。 +- 指針についてはプロジェクトの[スタイルガイド](https://github.com/theopensourceway/the-project/wiki/Style-Guide)（定期的に更新）を参照してください。ただし細かい点にこだわって進捗を遅らせないでください。編集者が完成前に内容を磨き上げます。 + +#### タスクの完了方法 + +`Task`マークの付いた課題を選択した場合、以下の手順で即座に貢献を開始できます。 + +- 選択した[課題](https://github.com/theopensourceway/guidebook/issues)にコメントを投稿し、協力する意思を示してください。 +- タスク完了に向けた提案アプローチを記述してください。この種の課題には*問題点*は記載されていても*解決策*が記載されていない場合があります。解決策の特定にご協力ください！ + +## GitHubプルリクエストによる変更提案 + +ご自身のフォークから本リポジトリへのプルリクエストを歓迎します。推奨される管理方法は以下の通りです。 + +### 上流リポジトリのフォークとクローン + +1. https://github.com/theopensourceway/guidebook にアクセスし、『Fork』ボタンをクリックして、ご自身のリポジトリにフォークを作成してください。 +ヒント: アップストリームのオリジナルではなく自身のフォークであることが明確になるよう、名前を変更してください（例: `yourname-fork-reponame`）。 +2. 自身のフォークページ（`https://github.com/you/forkname`）に移動し、『コード』 > ローカル > SSH をクリックし、URL 右側のコピーアイコンをクリックします。 +3. コマンドラインセッションを開き、リポジトリをローカルにクローンします。 + - `git clone git@github.com:[you]/[you]-tosw-guidebook.git` + - `cd [you]-tosw-guidebook` +4. クローンをアップストリームと同期させるため、アップストリームリポジトリを追加します。 + - `git remote add upstream git@github.com:theopensourceway/guidebook.git` +5. 設定が以下のようにされていることを確認してください。 + +``` +git remote -vv +origin git@github.com:[you]/[you]-tosw-guidebook.git (fetch) +origin git@github.com:[you]/[you]-tosw-guidebook.git (push) +upstream git@github.com:theopensourceway/guidebook.git (fetch) +upstream git@github.com:theopensourceway/guidebook.git (push) +``` + +6. アップストリームとの同期が可能なことを確認します。 + +``` +git fetch origin +git rebase origin/main +Current branch main is up to date. +git branch +* main +``` + +### 変更を加え、プルリクエスト（PR）としてGitHubにプッシュする + +変更を加える際は、クローン内で変更を行い、プルリクエスト（PR）としてアップストリームに提出します。 +クローン内のブランチで作業することをお勧めします。 +異なるPR向けの複数の変更を同時に作業する場合、これは必須です。 +また、現在どのブランチにいるかを確認することで、作業中の変更内容をより容易に把握できます。 + +``` +git checkout -b [branchname] ## 例: you-copyedits-01 +git branch + main +* you-copyedits-01 +``` + +これで`you-copyedits-01`ブランチで作業中であり、01番などの校正提出の準備が整ったことを確認できます。 + +### PRの作成 + +ローカルの変更をGitHubにプッシュする準備ができたら、コミットしてプッシュ設定を行います。 + +``` +git add ./filenames +git commit -m "短い説明メッセージ" ## 複数行のメッセージの場合はテキストエディタを開く +git push --set-upstream origin [branchname] +``` + +出力は以下のような形式になります。出力に含まれるPR作成リンクは、アップストリームではなく自身のフォーク内にPRを作成してしまうことに注意してください。 +アップストリームにPRを作成するには、https://github.com/theopensourceway/guidebook にアクセスしてください。『Compare & pull request』ボタンが表示されるまでページを再読み込みする必要がある場合があります。 + +``` +Enumerating objects: 5, done. +Counting objects: 100% (5/5), done. +Delta compression using up to 12 threads +Compressing objects: 100% (2/2), done. +Writing objects: 100% (3/3), 345 bytes | 345.00 KiB/s, done. +Total 3 (delta 1), reused 0 (delta 0), pack-reused 0 +remote: Resolving deltas: 100% (1/1), completed with 1 local object. +remote: +remote: Create a pull request for 'you-copyedits-01' on GitHub by visiting: +remote: https://github.com/you/you-tosw-guidebook/pull/new/you-copyedits-01 +remote: +To github.com:you/you-tosw-guidebook.git + * [new branch] you-copyedits-01 -> you-copyedits-01 +branch 'you-copyedits-01' set up to track 'origin/you-copyedits-01'. +``` + +プルリクエストダイアログの手順に従い、追加したいコメントがあれば記入してください。 +他の詳細が分かっている場合は記入できますが、そうでない場合でもプルリクエストは完了できます。 diff --git a/l10n/ja/CONTRIBUTORS.md b/l10n/ja/CONTRIBUTORS.md new file mode 100644 index 00000000..45571715 --- /dev/null +++ b/l10n/ja/CONTRIBUTORS.md @@ -0,0 +1,59 @@ +# 貢献者 + +## 章ごとの著者 + +* Introduction: Presenting The Open Source Way + * Author(s): [Karsten Wade](mailto:kwade@redhat.com) +* Community 101 + * Author(s): [Bryan Behrenshausen](mailto:bryan.behrenshausen@sas.com), [Dave Neary](mailto:dneary@redhat.com), [Karsten Wade](mailto:kwade@redhat.com) +* Essentials of Building a Community + * Author(s): [Andy Oram](mailto:andyo@praxagora.com) +* Building a Strategy + * Author(s): [Dave Neary](mailto:dneary@redhat.com) (lead), [Bryan Behrenshausen](mailto:bryan.behrenshausen@sas.com) +* New Project Checklist + * Author(s): [Lisa Caywood](mailto:lcaywood@redhat.com), [Josh Berkus](mailto:jberkus@redhat.com), [Bryan Behrenshausen](mailto:bryan.behrenshausen@sas.com), [Karsten Wade](mailto:kwade@redhat.com) + * Editor: [Bryan Behrenshausen](mailto:bryan.behrenshausen@sas.com) +* Communication Norms in Open Source Software Projects + * Author(s): [Leslie Hawthorn](mailto:lhawthor@redhat.com) + * Editor(s)/Reviewer(s): [Paula Dickerson](mailto:pdickers@redhat.com) (lead), Editorial team +* Building Diverse Open Source Communities by Making Them Inclusive First + * Author(s): [Lauren Maffeo](mailto:laurenmaffeo8@gmail.com) + * Editor(s)/Reviewer(s): [Bryan Behrenshausen](mailto:bryan.behrenshausen@sas.com) (lead), [Marina Zhurakhinskaya](mailto:marinaz@redhat.com) (subject matter expert (SME) reviewer), Editorial team +* Why People Participate in Open Source Communities + * Author(s): [Gordon Haff](mailto:ghaff@redhat.com) + * Editor(s)/Reviewer(s): [Brian Proffitt](mailto:bkp@redhat.com) (lead), Editorial team +* Incentivizing and Rewarding Participants + * Author(s): [Bryan Behrenshausen](mailto:bryan.behrenshausen@sas.com) +* From Users to Contributors + * Author(s): [Dave Neary](mailto:dneary@redhat.com) +* What Is a Contribution? + * Author(s): [Karsten Wade](mailto:kwade@redhat.com) +* Constructing an Onboarding Experience + * Author(s): [Ray Paik](mailto:ray@cube.dev), [Bryan Behrenshausen](mailto:bryan.behrenshausen@sas.com) +* Creating a Culture of Mentorship + * Author(s): [Karsten Wade](mailto:kwade@redhat.com), [Guedis Cardenas](mailto:guedis@palante.co) +* Project and Community Governance + * Author(s): [Dave Neary](mailto:dneary@redhat.com), [Josh Berkus](mailto:jberkus@redhat.com), [Bryan Behrenshausen](mailto:bryan.behrenshausen@sas.com) + * Editor(s)/Reviewer(s): [Bryan Behrenshausen](mailto:bryan.behrenshausen@sas.com) (lead), Editorial team +* Understanding Community Roles + * Author(s): [Andy Oram](mailto:andyo@praxagora.com), [Karsten Wade](mailto:kwade@redhat.com) +* Community Manager Self-Care + * Author(s): [Ashley Nicolson](mailto:ashjayne.nicolson@gmail.com) + * Editor(s)/Reviewer(s): [Karsten Wade](mailto:kwade@redhat.com) (lead), [Dr. Karen Hixson](https://www.karenhixsonlpc.com/) (subject matter expert (SME) reviewer), Editorial team +* Defining Healthy Communities + * Author(s): [Karsten Wade](mailto:kwade@redhat.com) +* Understanding Community Metrics + * Author(s): [Ray Paik](mailto:ray@cube.dev), [Brian Proffitt](mailto:bkp@redhat.com), [Bryan Behrenshausen](mailto:bryan.behrenshausen@sas.com) + * Editor(s)/Reviewer(s): [Brian Proffitt](mailto:bkp@redhat.com) (lead), [Bryan Behrenshausen](mailto:bryan.behrenshausen@sas.com), Editorial team +* Announcing Software Releases + * Author(s): [Brian Proffitt](mailto:bkp@redhat.com) + +## プロジェクトチーム + +### 編集チーム + +* Brian Proffitt (lead) +* Shaun McCance (lead writer) +* Bryan Behrenshausen +* Paula Dickerson +* Karsten Wade diff --git a/l10n/ja/LICENSE.md b/l10n/ja/LICENSE.md new file mode 100644 index 00000000..0d3c7876 --- /dev/null +++ b/l10n/ja/LICENSE.md @@ -0,0 +1,159 @@ +# ライセンス + +クリエイティブ・コモンズ 表示-継承 4.0 国際 (CC BY-SA 4.0) + +ライセンスされた権利（定義は後述します）の行使により、あなたは、クリエイティブ・コモンズ 表示-継承 4.0 国際 パブリック・ライセンス（以下「パブリック・ライセンス」といいます）の条項に規律されることを受諾し、同意します。本パブリック・ライセンスが契約と解釈されるであろう範囲において、あなたはこれらの利用条件のあなたによる受諾と引き換えにライセンスされた権利を付与されます。そして、許諾者は、あなたに対し、それらの条項のもとでライセンス対象物を利用可能にすることから許諾者が受領する利益と引き換えに、そのような権利を付与します。 + +第1条　定義 + + a. 「翻案物」 とは、著作権およびそれに類する権利の対象となり、ライセンス対象物について許諾者が有する著作権およびそれに類する権利に基づく許諾が必要とされるような形で、翻訳され、改変され、編集され、変形され、またはその他の方法により変更されたマテリアルで、ライセンス対象物から派生したか、またはライセンス対象物に基づくものを意味します。本パブリック・ライセンスにおいては、ライセンス対象物が音楽作品、実演または録音物で、これらが動画と同期させられる場合には、翻案物が常に作成されることになります。 + + b. 「翻案者のライセンス」 とは、翻案物に対してあなたが寄与した部分に生じる、あなたの著作権およびそれに類する権利について、本パブリック・ライセンスの条項に従って、あなたが適用するライセンスのことをいいます。 + + c. 「表示-継承互換ライセンス」 とは、本パブリック・ライセンスと本質的に同等であるとクリエイティブ・コモンズによって正式に承認された、creativecommons.org/compatiblelicensesにおいて列挙されたライセンスのことをいいます。 + + d. 「著作権およびそれに類する権利」 とは、その権利がどのように名づけられ、または分類されるかにかかわらず、著作権および／または著作権に密接に関係する類似の権利をいいます（実演、放送、録音物、およびデータベース権を含むが、これに限られません）。本パブリック・ライセンスにおいては、第2条(b)(1)および(2)において規定される権利は、著作権およびそれに類する権利ではありません。 + + e. 「効果的な技術的保護手段」 とは、1996年12月20日に採択されたWIPO著作権条約第11条、および／または類似の国際協定の義務を満たす諸法規の下で、正当な権限なしに回避されてはならないものとされる諸手段をいいます。 + + f. 「例外および権利制限」 とは、ライセンス対象物をあなたが利用する場合に適用される、フェアユース、フェアディーリングおよび／または著作権およびそれに類する権利に対するその他の例外もしくは権利制限をいいます。 + + g. 「ライセンス要素」 とは、クリエイティブ・コモンズ・パブリック・ライセンスの名称中に表示されているライセンスの属性をいいます。本パブリック・ライセンスのライセンス要素は、表示および継承です。 + + h. 「ライセンス対象物」 とは、許諾者が本パブリック・ライセンスを適用した美術的または文学的著作物、データベース、またはその他のマテリアルを意味します。 + + i. 「ライセンスされた権利」 とは、本パブリック・ライセンスの条項に基づき、あなたに与えられる権利をいい、かかる権利は、あなたによるライセンス対象物の利用に適用され、かつ、許諾者がライセンスする権限を有する、全ての著作権およびそれに類する権利に限定されます。 + + j. 「許諾者」 とは、本パブリック・ライセンスのもとで権利を付与する個人または団体を意味します。 + + k. 「共有」 とは、複製、公開の展示、公開の上演・演奏、頒布、配布、通信または輸入のような、ライセンスされた権利に関する許諾を必要とするような手段または手法により、公衆に対しマテリアルを提供すること、および、公衆がマテリアルを利用できるようにすること（公衆の各人が、自ら独自に場所および時間を選択してマテリアルにアクセスすることができる方法を含みます）を意味します。 + + l. 「データベース権」 とは、データベースの法的保護に関する1996年3月11日の欧州議会および理事会指令 96/9/ECの結果として生じた、著作権以外の権利、（この指令が修正および／または継承された場合それらを反映したもの）、および、世界中の本質的に同等な権利を意味します。 + +m. 「あなた」 とは、本パブリック・ライセンスのもとでライセンスされた権利を行使する個人または団体をいいます。「あなたの」もそれに対応した意味となります。 + +第2条　範囲 + + a. ライセンス付与. + + 1. 本パブリック・ライセンスの条項に従い、許諾者はあなたに対し、ライセンス対象物について、以下に掲げるライセンスされた権利を行使できる全世界的な、無償、再許諾不可、非排他的、かつ取消不可なライセンスを付与します： + + A. ライセンス対象物の全部または一部を、複製および共有すること、ならびに + + B. 翻案物を作成、複製および共有すること + + 2. 例外および権利制限誤解を避けるために記すと、例外および権利制限があなたの利用に適用される部分については、本パブリック・ライセンスは適用されず、あなたは本パブリック・ライセンスの条項に従う必要はありません。 + + 3. 有効期間本パブリック・ライセンスの有効期間は第6条(a)にて規定されます。 + + 4. 媒体および形式；許可される技術的改変許諾者は、あなたに対し、あらゆる媒体や形式（現在知られているか、または今後作られるか否かを問いません）において、ライセンスされた権利を行使する権限、およびその行使に必要とされる技術的な改変を行う権限を付与します。許諾者は、あなたが、ライセンスされた権利を行使するために必要とされる技術的な改変（効果的な技術的保護手段を回避するために必要とされる技術的な改変を含みます）を禁止するいかなる権利または権限を放棄し、および／またはこれらの権利または権限を行使しないことに同意します。本パブリック・ライセンスにおいては、本第2条(a)(4)により認められる改変をするだけでは翻案物を作り出すことにはなりません。 + + 5. ダウンストリーム（下流側）の受領者. + + A. 許諾者からの申し出－ライセンス対象物 ライセンス対象物の受領者は、許諾者から本パブリック・ライセンスの条項の下でライセンスされた権利を行使できるという申出を自動的に受け取ります。 + + B. 許諾者からのその他の申し出－翻案物 あなたから翻案物を受領した者は、あなたが適用した翻案者のライセンスの条件にしたがった翻案物におけるライセンスされた権利を行使できるという申出を自動的に許諾者から受け取ります。 + + C. ダウンストリーム（下流側）への制限の禁止 あなたは、ライセンス対象物の受領者がライセンスされた権利を行使するのを制限されることになる場合には、ライセンス対象物に対して、いかなる追加条項または異なる条項も提案または課してはならず、あるいは、いかなる効果的な技術的保護手段も適用してはなりません。 + + 6. 支持表明がないこと 許諾者または第3条(a)(1)(A)(i)に定められている許諾者以外のクレジット表示の対象として指定されている者が、あなたまたはライセンス対象物のあなたによる利用について、関連している、援助・支持している、あるいは正式な地位を付与している、と主張または示唆することを本パブリック・ライセンスは許諾しておらず、またはそのように解釈されてはなりません。 + + b. その他の権利. + + 1. 同一性保持の権利のような著作者人格権は、本パブリック・ライセンスのもとではライセンスされません。パブリシティ権、プライバシー権、および／または他の類似した人格権も同様です。ただし、可能なかぎり、許諾者は、あなたがライセンスされた権利を行使するために必要とされる範囲内で、また、その範囲内でのみ、許諾者の保持する、いかなるそのような権利を放棄し、および／または主張しないことに同意します。 + + 2. 特許権および商標権は本パブリック・ライセンスのもとではライセンスされません。 + + 3. 可能なかぎり、許諾者は、ライセンスされた権利の行使について、直接か、または任意のもしくは放棄可能な法定のもしくは強制的なライセンスに関する仕組みに基づく集中管理団体を介するかを問わず、あなたからライセンス料を得るいかなる権利も放棄します。その他一切の場合において、許諾者はそのようなライセンス料を得るいかなる権利も明確に保持します。 + +第3条　ライセンス利用条件 + +ライセンスされた権利をあなたが行使するにあたっては、以下に記載された諸条件に従う必要があります。 + + a. 表示. + + 1. あなたがライセンス対象物（変更されたものを含む）を共有する場合は以下のことを行う必要があります： + + A. ライセンス対象物と共に許諾者から提供されていれば、以下のものを保持すること。 + + i. ライセンス対象物の作者その他クレジット表示される者として許諾者によって指定されている者を識別する情報を、いかなる形であれ許諾者によってリクエストされた形が合理的である場合はその形で（指定されている場合は仮名も含む） + + ii. 著作権表示 + + iii. 本パブリック・ライセンスを参照する表示 + + iv. 「無保証」を参照する表示 + + v. 合理的に実施可能な場合には、ライセンス対象物のURIまたはライセンス対象物へのハイパーリンク + + B. ライセンス対象物を改変した場合はその旨を記し、従前の改変点についての表示も保持すること。 + + C. ライセンス対象物が本パブリック・ライセンスに基づきライセンスされていることを示すこと、および、本パブリック・ライセンスの全文またはそのURIか本パブリック・ライセンスへのハイパーリンクのいずれかを含めること。 + + 2. 第3条(a)(1)の条件は、あなたがライセンス対象物を共有する媒体・方法・文脈に照らして、いかなる合理的な方法でも満たすことができます。例えば、必要とされる情報を含むリソースのURIやハイパーリンクを付すことで条件を満たすことが合理的な場合があります。 + + 3. 許諾者からリクエストされれば、あなたは第3条(a)(1)(A)に掲げるいかなる情報も合理的に実施可能な範囲で削除しなければなりません。 + + b. 継承. + + 第3条(a)の条件に加えて、あなたが作成した翻案物をあなたが共有する場合、以下の条件も適用されます。 + + 1. あなたが適用する翻案者のライセンスは、本パブリック・ライセンスと同じバージョンもしくはそれ以降のバージョンの、同じライセンス要素を有したクリエイティブ・コモンズ・ライセンス、または表示-継承互換ライセンスでなければなりません。 + + 2. あなたは、あなたが適用する翻案者のライセンスの全文またはそのURIかそのライセンスへのハイパーリンクを含めなければなりません。あなたは、あなたが共有した翻案物における媒体、手段および文脈に基づくいかなる合理的な方法によっても、この条件を満たすことができます。 + + 3. あなたは、翻案物に対し、あなたが適用する翻案者のライセンスによって付与される権利の行使を制限するような、いかなる追加のもしくは異なる条項も提案しもしくは課すことはできず、またはいかなる効果的な技術的保護手段を適用することもできません。 + +第4条　データベース権 + +ライセンスされた権利にデータベース権が含まれており、ライセンス対象物のあなたの利用に適用される場合： + + a. 誤解を避けるために記すと、第2条(a)(1)に従い、データベースの全てまたは実質的な部分のコンテンツの抽出、再利用、複製または共有をする権利をあなたに与えます。 + + b. あなたがデータベース権を持つデータベースに、あなたが、本データベースのコンテンツの全てまたは実質的な部分を含める場合、あなたがデータベース権を持つデータベース（ただし、個々のコンテンツではありません）は翻案物となります（同じことが第3条（b）における翻案物の判断にもあてはまります）。 + + c. あなたは、データベースのコンテンツの全てまたは実質的な部分を共有する場合は、第3条(a)の条件に従わなくてはなりません。 + +誤解を避けるために記すと、 本第4条 は、ライセンスされた権利が他の著作権およびそれに類する権利を含む場合の本パブリック・ライセンス下でのあなたの義務に追加されるものであり、置き換えるものではありません。 + +第5条　無保証および責任制限 + + a. 許諾者が別途合意しない限り、許諾者は可能な範囲において、ライセンス対象物を現状有姿のまま、現在可能な限りで提供し、明示、黙示、法令上、その他に関わらずライセンス対象物について一切の表明または保証をしません。これには、権利の帰属、商品性、特定の利用目的への適合性、権利侵害の不存在、隠れた瑕疵その他の瑕疵の不存在、正確性または誤りの存在もしくは不存在を含みますが、これに限られず、既知であるか否か、発見可能であるか否かを問いません。全部または一部の無保証が認められない場合、この無保証はあなたには適用されないこともあります。 + + b. 可能な範囲において、本パブリック・ライセンスもしくはライセンス対象物の利用によって起きうる直接、特別、間接、偶発、結果的、懲罰的その他の損失、コスト、出費または損害について、例え損失、コスト、出費、損害の可能性について許諾者が知らされていたとしても、許諾者は、あなたに対し、いかなる法理（過失を含みますがこれに限られません）その他に基づいても責任を負いません。全部または一部の責任制限が認められない場合、この制限はあなたには適用されないこともあります。 + + c. 上記の無保証および責任制限は、可能な範囲において、全責任の完全な免責および免除に最も近いものとして解釈するものとします。 + +第6条　期間および終了 + + a. 本パブリック・ライセンスは、ここでライセンスされた著作権およびそれに類する権利が有効な期間、適用されます。しかし、もしあなたが本パブリック・ライセンスに違反すると、本パブリック・ライセンスに定めるあなたの権利は自動的に終了します。 + + b. ライセンス対象物をあなたが利用する権利が第6条(a)の事由により終了した場合でも： + + 1. あなたが違反を発見してから30日以内に違反を是正した場合に限り、違反を是正したその日に、自動的に復活します。または、 + + 2. 許諾者により権利の復活を明示された場合に、復活します。 + + 誤解を避けるために記すと、本第6条(b)は、許諾者が、あなたの本パブリック・ライセンスに関する違反に対する救済を求めるために有するであろういかなる権利にも影響を及ぼしません。 + + c. 誤解を避けるために記すと、許諾者は、いつでも、別の条項の下でライセンス対象物を提供したり、ライセンス対象物の配布を停止することができます。しかし、その場合でも、本パブリック・ライセンスは終了しません。 + + d. 第1条、第5条、第6条、第7条、第8条は、本パブリック・ライセンスが終了してもなお有効に存続します。 + +第7条　その他の条項 + + a. 許諾者は、明確に合意しない限り、あなたが通知するいかなる追加のまたは異なる条項にも拘束されません。 + + b. ライセンス対象物に関する取り決め、了解事項または合意でここに言明されていない一切のものは、本パブリック・ライセンスの条項とは切り離され、独立したものです。 + +第8条　解釈 + + a. 誤解を避けるために記すと、本パブリック・ライセンスは、本パブリック・ライセンスによる許諾に基づかない、ライセンス対象物のいかなる合法的な利用も縮小したり、限定したり、制限したり、条件を課したりするものではなく、またそのように解釈されてはなりません。 + + b. 可能な範囲で、本パブリック・ライセンスのいずれかの規定が執行不能とみなされた場合には、本パブリック・ライセンスは、執行可能とするために必要最小限度の範囲で自動的に変更されます。もしある規定の変更が不可能な場合には、その他の条項の執行可能性に影響を与えることなく、当該規定は本パブリック・ライセンスから切り離されます。 + + c. 本パブリック・ライセンスのいかなる条項も、許諾者の明確な合意なしには、放棄されることはなく、また、順守しないことに同意することはありません。 + + d. 本パブリック・ライセンスのいかなる条項も、許諾者やあなたに適用される、あらゆる特権や免責（司法権や当局の法的手続からの特権や免責を含む）に対する制限や放棄を構成するものではなく、またそのように解釈されるものではありません。 + +https://creativecommons.org/licenses/by-sa/4.0/legalcode diff --git a/l10n/ja/README.md b/l10n/ja/README.md new file mode 100644 index 00000000..36272f9a --- /dev/null +++ b/l10n/ja/README.md @@ -0,0 +1,5 @@ +# The Open Source Way (オープンソースウェイ) + +[The Open Source Way (以降：オープンソースウェイ)](https://www.theopensourceway.org/) は、オープンソースコミュニティの運営に関心を持つすべての人に向けた（やや主観的な）ガイドブックです。 + +情熱的な貢献者たちのグループを立ち上げ、育成し、成長させ、維持するためのベストプラクティスを集めたものです。 \ No newline at end of file diff --git a/l10n/ja/SUMMARY.md b/l10n/ja/SUMMARY.md new file mode 100644 index 00000000..be5e33f0 --- /dev/null +++ b/l10n/ja/SUMMARY.md @@ -0,0 +1,29 @@ +# 目次 + +* [The Open Source Way (オープンソースウェイ)](README.md) +* [序文：オープンソースウェイの提唱](presenting-the-open-source-way.md) +* [入門](getting-started/README.md) + * [コミュニティ101](getting-started/community-101.md) + * [コミュニティ構築の要点](getting-started/essentials-of-building-a-community.md) + * [戦略の構築](getting-started/building-a-strategy.md) + * [新規プロジェクトチェックリスト](getting-started/new-project-checklist.md) +* [ユーザーの獲得](attracting-users/README.md) + * [オープンソースプロジェクトにおけるコミュニケーションの規範](attracting-users/communication-norms-in-open-source-software-projects.md) + * [多様なオープンソースコミュニティ構築：インクルージョン（包摂性）を最優先に](attracting-users/building-diverse-open-source-communities-by-making-them-includive-first.md) +* [参加者のガイド](guiding-participants/README.md) + * [オープンソースコミュニティへの参加理由](guiding-participants/why-people-participate-in-open-source-communities.md) + * [参加者のインセンティブと報酬](guiding-participants/incentivizing-and-rewarding-participants.md) +* [貢献者の育成](growing-contributors/README.md) + * [ユーザーから貢献者へ](growing-contributors/from-users-to-contributors.md) + * [貢献とは何か?](growing-contributors/what-is-a-contribution.md) + * [オンボーディング体験の構築](growing-contributors/constructing-an-onboarding-experience.md) + * [メンターシップ文化の醸成](growing-contributors/creating-a-culture-of-mentorship.md) + * [プロジェクトとコミュニティのガバナンス](growing-contributors/project-and-community-governance.md) + * [コミュニティの役割を理解する](growing-contributors/understanding-community-roles.md) + * [コミュニティマネージャーのセルフケア](growing-contributors/community-manager-self-care.md) +* [成功の測定](measuring-success/README.md) + * [健全なコミュニティの定義](measuring-success/defining-healthy-communities.md) + * [コミュニティ指標の理解](measuring-success/understanding-community-metrics.md) + * [ソフトウェアリリースの告知](measuring-success/announcing-software-releases.md) +* [貢献者](CONTRIBUTORS.md) +* [ライセンス](LICENSE.md) diff --git a/l10n/ja/attracting-users/README.md b/l10n/ja/attracting-users/README.md new file mode 100644 index 00000000..c86f2adc --- /dev/null +++ b/l10n/ja/attracting-users/README.md @@ -0,0 +1,36 @@ +--- +author: Karsten Wade +updated: 2020-12-09T00:00:00.000Z +translated-by: Ken Komazawa powered by DeepL Pro +--- + +# ユーザーの獲得 + +このセクションでは、オープンソースソフトウェアプロジェクトの成功に不可欠な要素について、重要かつ非常に有用でタイムリーなアドバイスを提供します。これらのアドバイスをこのセクションにまとめたのは、例えばコミュニケーションや多様性への配慮といった要素を、貢献者育成プロセスにおける後工程として留保するのではなく、ユーザー獲得を支援することを目的としているためです。 + +このガイドブックは、貢献者コミュニティを成長させる方法はユーザー獲得を通じたものであると述べています。その理由はいくつか簡潔に挙げられます。 + +一つは単純な数の論理です。人材プールが大きければ大きいほど、参加に興味を持ち、やがて貢献するようになる人も増えます。人材プールが多様であればあるほど、その規模は拡大します。つまり、男性だけがプロジェクトに歓迎されると感じている場合、ユーザー／貢献者の潜在的な規模は人類の半数以下に縮小してしまうのです。 + +熟練した貢献者が突然現れて即座に貢献を始めることは稀です。多くの人が、まずソフトウェアのユーザーとなり、次に広範なユーザーコミュニティに参加し、最終的に貢献者としての第一歩を踏み出すという経路を経て貢献者となります。一定期間（短いか長いかは別として）を経て、彼らの専門性はコミュニティ内で認識されます。この道筋を歩み始める人が多ければ多いほど、それを完遂する人も増えることになります。 + +多様性とコミュニケーションはプロジェクトの最前線でも重要です。コミュニケーションは、ソフトウェアの機能や利用価値を世界に伝え、効果的な場でフィードバックを得るために不可欠です。多様性と包括性は、イノベーション、回復力、長期的な持続可能性に強さを与える目標です。もしあなたのコミュニティが現実世界のように多様でなければ、この世界で長く存続することはありません。 + +これを考える一つの方法は、誰かが初めてあなたのコミュニティを見る時、正式な行動規範とリーダーシップ層における多様な顔ぶれが、彼らがあなたのウェブサイトを初めて訪問した瞬間であるべきだということです。コミュニティに自らの姿を反映させる必要が最も高い人々——参加時に身体的・精神的に安全だと知る必要がある人々——は、プロジェクトサイトを初めて訪れた時点で、そのコミュニティの歓迎度を判断します。こうした要素が文化の一部として可視化されていない場合、彼らは協力者や貢献者として関わることを検討する前に、とっくに去っているでしょう。 + +このセクションには以下の章が含まれます。 + +* ユーザーと貢献者からなるコミュニティを構築するオープンソースプロジェクトの基本要素を理解する手助け +* オープンソースプロジェクト内外で効果的にコミュニケーションする方法の説明 +* 関心をユーザーへ転換するための必須ステップの提供 +* 多様なコミュニティ構築は、エンドユーザーが目にし体験する全てにおいて、最初から包括的であることから始まるという示唆 + +このセクションは以下のような場合に有用です。 + +* ユーザー獲得が貢献者コミュニティ構築の第一歩であるという、本ガイドブックの視点を深く理解したい方。 +* オープンソースプロジェクトの主要要素リストの出典や参考資料を探している方（プロジェクト構築中、実現可能性調査中、その他の目的を含む）。 +* 自社ソフトウェアのユーザー増加に役立つヒントやテクニックを求めている方。 +* 特定タイプ、複数タイプ、あるいはあらゆるタイプの貢献者を惹きつけることに苦労している方。 +* より多様で包括的なコミュニティの必要性を確信し、他者を説得したりプログラムを開始したりするなど、その実現に向けた支援を求めている方。 +* 「多様性」という概念や、それがオープンソースソフトウェアにとってなぜ重要なのかが理解できていない方。 +* 前の章を読み、本を最初から最後まで通して読みたい方。 diff --git a/l10n/ja/attracting-users/building-diverse-open-source-communities-by-making-them-includive-first.md b/l10n/ja/attracting-users/building-diverse-open-source-communities-by-making-them-includive-first.md new file mode 100644 index 00000000..914ec69e --- /dev/null +++ b/l10n/ja/attracting-users/building-diverse-open-source-communities-by-making-them-includive-first.md @@ -0,0 +1,182 @@ +--- +description: +author: Lauren Maffeo +updated: 2020-07-19 +translated-by: Ken Komazawa powered by DeepL Pro +--- + +# 多様なオープンソースコミュニティ構築：インクルージョン（包摂性）を最優先に + +COVID-19パンデミックにより大半のテックチームがリモートワーク、あるいは完全に業務停止を余儀なくされたわずか数か月後、George Floydの殺害事件が米国で人種問題への直視を促しました。この運動は特にテクノロジー業界に深刻な打撃を与えました。各社が人種的正義を支持し「ブラック・ライブズ・マター」を宣言する声明を発表する一方で、自社内の黒人従業員の経験値という多様性の実態が、社内外から厳しく検証されることとなりました。 + +一見すると、オープンソースはテクノロジー企業を悩ませる多様性と包摂性に関する複合的な問題の影響を受けないように思えます。オープンソースのエコシステムはオンライン上で機能し、貢献者は国境や言語、タイムゾーンを越えて協働し、技術を進歩させるプロジェクトを支えています。場合によっては、人々は無料のビールや株式のためではなく、純粋にプロジェクトへの愛から貢献する人もいます。こうした利他的な意図が広く見られることから、オープンソースは真の能力主義であり、性別や肌の色に関わらず誰もが活躍できる場だと考えられてきました。しかし業界の支持者が能力主義以上に愛するものがあるとすれば、それはデータです。そしてオープンソースエコシステムへの貢献者を示すデータは、痛烈な現実を浮き彫りにしました。 + +本章では、様々なオープンソースコミュニティが取り組む多様性や包摂性向上の概要を紹介します。また、コミュニティ管理者やプロジェクトメンテナーが実践できる、多様な貢献者基盤から恩恵を受けるコミュニティやプロジェクトを構築するために取るべき初期ステップを提示します。最も重要なのは、少数派グループからの貢献者獲得を試みる前に、オープンソースコミュニティ自体が包摂性を実践すべきだという主張です。人々が継続的に参加するのを妨げる制度的な障壁を修正しようとしない限り、多様化への取り組みは無駄に失敗し続けるでしょう。 + +## オープンソースの多様性の現状 + +2019年、米国労働統計局は「コンピュータおよび情報システム」部門の雇用されている管理職全体の28.7%が[女性であった](https://www.bls.gov/cps/cpsaat11.htm)と報告しました。同部門の管理職全体のうち、黒人またはアフリカ系アメリカ人は9.6%、アジア系は15.8%、ヒスパニックまたはラテン系は4.7%でした。 + +この調査が示す通り、米国テクノロジー業界の管理職は白人および／または男性が圧倒的多数です。オープンソースコミュニティでは、白人および／または男性貢献者の割合がさらに偏っています。2017年の[GitHub調査](https://opensourcesurvey.org/2017/)では、6,000人のオープンソースユーザーと開発者を対象に実施したところ、無作為に選ばれた回答者の95%が男性でした。女性は3%、ノンバイナリー（非二元性）の人々は1%でした。 + +なぜこのような状況が続くのでしょうか？近年、多様なプロジェクト貢献者を募集するダイバーシティ（多様性）とインクルージョン（包摂性）（D&I）イニシアチブが急増しています。Linux Foundationは、オープンソースサミットでD&Iセッションにプログラム全体の一区画を割いています。DrupalConは過小評価された背景を持つ参加者や講演者向けに奨学金を提供しています。All Things Open 2019では複数の基調講演で多様性が議論されました。コミュニティリーダーの注目がこれほど集まっているのに、なぜ貢献者データは依然として厳しい現実を描いているのでしょうか？ + +女性や少数派グループ（underrepresented minorities/URM）のオープンソース活動が相対的に少ないことは一見意外に思えますが、詳しく見るとオープンソースコミュニティにおけるインクルージョン（包摂性）に関する根深い問題が浮かび上がります。包摂性は多様性の同義語として使われることが多いですが、実際には独自の原則です。Meg Bolgerの言葉を借りれば、「包摂性とは、異なるアイデンティティを持つ人々が特定の環境（例：チーム、職場、業界）において、価値を認められ、活用され、歓迎されていると感じること（あるいは実際にそうであること）である」。女性やURMがオープンソースコミュニティに包含されない背景には、根強い構造的障壁が存在します。これらの構造的問題に対処し是正しなければ、オープンソースにおける多様性は改善されません。 + +ここでは3つの障壁を掘り下げましょう。貢献する自由時間の不足、敵対的なオンライン環境、そして不十分なドキュメントです。 + +### 無償で貢献する時間の不足 + +世界的に、女性は同じ専門職を遂行しても白人男性より[収入が低い](https://www.weforum.org/agenda/2019/03/an-economist-explains-why-women-get-paid-less/)状態が続いています。また、家庭の主な稼ぎ手となる可能性も高まっており、家事、育児、[その他の家事労働](https://www.unwomen.org/en/news/in-focus/csw61/redistribute-unpaid-work)という形で無償労働を担う可能性もより高いです。 + +その結果、オープンソースコミュニティへの貢献といったさらなる無償労働に充てる余暇が減少しています。貢献する場合でも、勤務時間内に行うことが多く—それは、そうした活動を許可する組織に既に勤めているからです。 + +Nisha Kumar (She/They)は、VMwareのオープンソース技術センターにおいて、コンテナ構築・パッケージング・配布の技術リーダーを務めています。彼女はTernプロジェクトの共同メンテナを務め、SPDXおよびOCIコミュニティへの貢献者でもあります。これらのプロジェクトと、子供の主な養育者としての役割を両立させています。Kumarにとってこの二重の役割は珍しいものではありません。インドで育った少女時代、彼女は学業と家事、用事の遂行、家族の世話のバランスを取っていました。これらの終わりのないタスクは、情熱を注ぐプロジェクトに取り組む時間を全く残しませんでした。 + +VMwareで日中にオープンソース作業ができる環境がなければ、現在のように貢献できていたか確信が持てないと言います。Kumarはこのように語っています。 +> 「技術分野で働く女性として、本業でオープンソースに貢献し報酬を得ているにもかかわらず、個人的に興味のあるオープンソースプロジェクトへの貢献や、地元のオープンソースコミュニティへのボランティア活動すら時間が取れません。子供の世話や家事もこなさなければならないからです。」 + +### 敵意に満ちたオンライン環境 + +インターネットは平等に居心地の良い場所ではありません。女性、有色人種、LGBTQ+の人々はオンラインハラスメントの標的となりやすく、女性は男性と比べて[オンライン上の性的嫌がらせを経験する確率が2倍](https://hbr.org/2020/06/youre-not-powerless-in-the-face-of-online-harassment)であると言われます。これは2020年以前の状況です。 + +この年は世界的なパンデミックと大規模な市民騒乱が重なり、特にアジア系アメリカ人や黒人アメリカ人など有色人種への攻撃が増加しました。攻撃者が現実世界で人を傷つけることに勇気づけられるなら、これが同様に[オンライン上でも発生する] (https://www.nytimes.com/2020/07/11/business/media/tucker-carlson-writer-blake-neff.html) 事態が起きるのは当然です。黒人やアジア系の貢献者が参加するオープンソースプロジェクトに関わるなら、誤解しないで理解してほしいのですが、彼らは苦しんでいるのです。 + +「インターネット全体が、女性やURM（少数派グループ）に敵意を持つ白人男性によって占められているという認識が欠けている」とKumarは指摘します。「インターネット上で日常的に嫌がらせを受けている人々が、いくら行動規範文書があるからといって、オープンソースコミュニティが自分たちに対して同じように振る舞わないはずだと、どうして期待できるでしょうか？」 + +Kumarの懸念は根拠があります。オープンソースコミュニティは、大多数を歓迎する環境として評判が良いわけではありません。長年にわたり、プロジェクト管理者は「最悪の日には疲れ果て、評価されず、虐待さえ受けていると感じる」と助けを求める声を上げてきました。2017年にGitHubの6,000人の貢献者を対象に行った調査では、21％がネガティブな行動を経験した後、取り組んでいたプロジェクトを離脱したことが判明しました。こうした行動に遭遇する確率が少数派グループの人々にとってはるかに高いことを考えると、彼らがオープンソースプロジェクトに貢献していること自体が驚きです。 + +「オープンソースコミュニティへの貢献に費やす時間は、LGBTQの平等推進や警察の暴力への抗議など、私が関心を持ち、過小評価された人々に不均衡な影響を与える問題へのボランティア活動にも充てられる時間です。実際、こうした問題こそが私たちが過小評価される根本原因なのです。」と、オープンソースプロジェクトをホストする営利テック企業のコミュニティマネージャー、Perry Eising (He/They)は説明します。「（時に敵意を感じる）OSや技術の論争に関与する時間を割くことを、自分自身に正当化するのは難しいです。私の注意と努力を必要とする課題が山積しているのだから。」 + +### 不完全で不十分なドキュメント + +上記の障壁は、おそらく最大の障壁であるオープンソースプロジェクトのドキュメント不足に集約されます。定量データと定性インタビューは、大半のオープンソースプロジェクトがドキュメント作成を優先せず、報いも与えていないことを繰り返し示しています。結果として、外部者はどう支援すべきか全く見当がつかないことになります。 + +これは私自身の経験に基づく話です。2年前にバンクーバーで開催されたオープンソースサミットで講演した後、コミュニティの温かさと歓迎の気持ちに感銘を受け、自分が貢献できるプロジェクトを探そうと決意しました。あらゆる分野のライターとしての経歴から、ドキュメント作成が最適な出発点であり、有意義な影響を与えられると思ったのです。だから、初めてGitHubアカウントを作成し、プラットフォームにログインしたものの、次にどこへ向かえば良いのか全く分からず途方に暮れた時の私の落胆ぶりは想像に難くないでしょう。フォークの方法も、ブランチの統合も、プルリクエストの作成も全く知らなかった私は、どこから手をつければ良いのか見当もつかず、失敗の余地が大きいことも理解していました。 + +幸い、私が住む街には活発なテックコミュニティがあり、あらゆる関心を持つ技術者向けの定期的なミートアップが開催されており、初心者向けのチュートリアルも含まれていました。最初のプルリクエストはカンファレンスで直接行い、その後数十件のGitHub貢献の大半も対面イベントで達成しました。数ヶ月にわたり無料で参加しやすいイベントに複数回出席して初めて、独力で貢献を始められたのです。こうした環境がなければ、承認されるかどうかもわからないプルリクエストを作成するため、GitHubの仕組みを独りで何時間も学ぶことはなかったでしょう。 + +オープンソース貢献者の5人に1人がプロジェクトを離れる理由として「不適切な行為」を挙げた同じGitHub調査では、不完全または混乱を招くドキュメントが最大の課題であることも判明しました。回答者の93%がこの問題に遭遇したと認めながら、60%が「ドキュメントへの貢献はほとんど、あるいは全く行わない」と回答しています。結果として、プロジェクトのベテランでさえ*自身の*プロジェクトのドキュメントを読むのが困難な状況です。 + +外部の人間がどう感じるか想像してみてください。 + +「オープンソースへの貢献は技術的課題であると同時に、社会的課題でもあります」とGitLabのシニアオープンソースプログラムマネージャー、Nuritzi Sanchez (She/Her) は説明します。「コミュニティが機能する基盤である、リモートの非同期コラボレーションを実現するにはドキュメントが不可欠です。全てが人々の頭の中に閉じ込められたままでは、混乱と不満、非効率性が蔓延する環境を生み出します。」 ドキュメントはコードにとって不可欠なだけでなく、各プロジェクトの文化的・コミュニケーション上の規範を理解するためのガイドでもあります（このテーマの詳細については、本ガイドブックのコミュニケーション規範に関する章を参照してください）。 + +オープンソースコミュニティは、異なるタイムゾーンを越えて結束して作業するために非同期コミュニケーションを利用しています。明確なドキュメントがなければ、貢献を検討している人々は、意思決定がどのように行われるのか、プロジェクトのどこに貢献すべきか、チームがどのように協力しているのか、特定のプロセスに従うことがなぜ重要なのかを知ることができません。英語が母国語でない、あるいは特別な支援が必要な貢献希望者にとって、このドキュメント不足は貢献を事実上不可能にします。不十分なドキュメントは広範な影響を及ぼします。透明性の欠如を示し、時間を浪費させ、不信感を招き、多くのオープンソースコミュニティが潜在能力を発揮するのを妨げるのです。 + +## より包括的なプロジェクトとコミュニティ構築のヒント + +こうした参入障壁があるにもかかわらず、メンテナーにとって朗報があります。プロジェクトをより包摂的にすることで、その文化を改善する大きな力をあなたが握っているのです。コミュニティメンバー、特に過小評価されている背景を持つ人々は、多様性と包摂性の欠如について長年議論してきました。今こそ、プロジェクトメンテナーが行動を起こす時です。包摂性をプロジェクト戦略全体に織り込むことです。——後付けではなく。 + +「[多様性と包摂性]に関する基調講演は、意識向上を目的とした崇高な理念を掲げているかもしれません。かつては有用だったと主張する人もいるでしょう（おそらく）。しかし私たちはその段階をすでに超えています」と、世界最大のクラウドネイティブコンピューティング財団（CNCF）ユーザーグループ「Cloud Native Containers」を運営するLisa-Marie Namphy (She/Her)は主張します。「私たちのコミュニティは、今こそ行動する時だと訴えているのです！行動とは、ポリシーの変更、資金調達の取り組み、代表的な目標など、多くのことを意味します。コミュニティは、運営財団から資金提供企業に至るまで、説明責任を求めているのです。」 + +包摂的なコミュニティ構築が困難に思えるなら、コミュニティは支援したいと思っていることを思い出してください。プロジェクトのメンテナー自身も、この作業を一人で担う必要はありません。実際、信頼できるチームと共に以下のステップを踏むことで、プロジェクト全体が改善されるでしょう。 + +### ステップ1：能力主義を標榜するのをやめる + +より包摂的なオープンソースプロジェクトへの第一歩は、能力主義の神話を理解することです。能力主義を信じるほど、プロジェクトは偏見に満ちたものになる可能性が高まります[（原文リンク）](https://www2.deloitte.com/au/en/blog/diversity-inclusion-blog/2019/meritocracy-unraveling-paradox.html)。 + +なぜか？純粋な実力主義プロジェクトは、人々が不平等な立場から参加していることを[認識していません](https://gap.hks.harvard.edu/paradox-meritocracy-organizations)。オープンソースのメンテナーが、女性が貢献する時間が少ないことや、LGBTQ+の貢献者がオンラインでの虐待に遭いやすいことを認識していなければ、コミュニティをより包摂的にする措置を講じることはできません。その結果、苦労して集めた多様な貢献者を失うリスクを負うことになります。 + +Terri Oda (She/Her) は、インテルのオープンソースセキュリティ研究者としての役割と並行して、Python Software FoundationとGoogleのSummer of Codeでボランティア活動を行っています。彼女は、実力主義を主張する発言に嫌悪感を覚えると語ります。なぜか？そのような発言は、オープンソースコミュニティが実際に集まる場合でさえ、より多くの人々をプロジェクトに参加させる機会を管理者が無視する原因となるからです。 + +「例えば、カンファレンスでコードスプリントを開催し、女性の参加者を増やしたい場合を考えてみてください」とOdaは言います。「能力やスキルだけを考えれば、スプリント入門型のコンテンツを多く提供することになるでしょう。しかし、より大きな視点で見れば、カンファレンスは本会議中は保育サービスを提供しているが、スプリントが始まるとそれが止まることに気づくかもしれません。あるいは会場が安全な地域ではなく、スプリントが夜遅くまで続くことも気づくでしょう。」 + +より包摂的な環境を構築する第一歩は自己認識です。オープンソース貢献者は様々な実体験を携えてプロジェクトに参加し、それが参加の有無や方法に影響します。この事実と向き合い、深く考えることが最初にして最も重要なステップです。 + +次のステップは、プロジェクトの現在のコミュニティを正直に見つめ、誰が参加しているか、そして誰が参加していないかに注目することです。もしプロジェクトの貢献者が全員、あるいは大部分があなたと似た背景を持つ人々ばかりなら、それは包摂的な見直しが必要な重大な警告サインです。 + +### ステップ2: プロジェクトのドキュメントを優先する + +[2019年Stack Overflow調査](https://insights.stackoverflow.com/survey/2019#:~:text=Over%2040%25%20of%20respondents%20have,and%20Kotlin%20have%20the%20fewest)によれば、開発者の約41%が経験5年未満です。こうした新規技術者とSTEM教育の現状を鑑みると、新たなオープンソース貢献者を迎える機会は豊富にあります。そのためには、プロジェクト管理者が参入障壁を下げる必要があり、明確で簡潔なドキュメントがその第一歩となります。 + +Zach Corleissen (He/They) はLinux Foundation（LF）の主任テクニカルライターであり、最近LF Energy Foundationの大規模なアーキテクチャ文書を改訂しました。またKubernetesドキュメント特別関心グループ（Special Interest Group/SIG Docs）の共同議長の一人を務めています。Kubernetesは彼にとって初めてのオープンソースソフトウェアプロジェクトであり、それは瞬く間に現代のオープンソースで最も生産性の高いプロジェクトの一つとなりました。その急速な成長により、Corleissenはドキュメントの重要な側面を担当し、より読者に優しいものへと改訂することができました。 + +「コードが自己文書化されていると主張することは、一種のゲートキーパー行為であり、不健全なプロジェクト文化の一例です。」とCorleissenは述べています。「この軽視は往々にして、静的ジェネレータスタックを見て『*そんなに難しいわけないだろ？*』と考える開発者から生まれます。私が最も嫌う軽蔑的な言葉の一つが『*ただのMarkdownの山だ*』です。もしそれがそんなに簡単ならどんなに良いでしょう！チップセットが一つとして同じでない環境、カーネルのデフォルト設定が敵対的である環境、RAMは変動し、ストレージはランダムな外部依存性に左右され、最適な条件下でも本番環境は頻繁に失敗し、逆に明らかなCI失敗にもかかわらず成功することさえある。ドキュメントはこのような状況を説明するためのコードなのです。」 + +進捗を追跡するため、SIG Docsグループは四半期レビューを実施し、前四半期の目標達成度を測定し、次四半期の作業優先順位を決定します。彼らのコミュニティルールの一つはオーナーシップに焦点を当てています。目標を採用するには、それを推進する意思のある特定の担当者が必要です。 + +### ステップ3：明確な行動規範の作成と徹底 + +プロジェクトにまだ行動規範（Code of Conduct/CoC）が存在しない場合、作成するのに遅すぎることはありません（開始方法のヒントはこのガイドブックのガバナンス章を参照）。長期プロジェクトから2日間のカンファレンスまで、現代のオープンソース活動には行動規範が求められています。 + +本章の調査において、複数のオープンソース貢献者が「明確な行動規範のない新規プロジェクトへの参加は検討しない」と述べています。こうしたURM（underrated minority/過小評価されたマイノリティ）にとって、敵対的ではないにせよ歓迎されないコミュニティに参加するリスクは高すぎます。Appleのシニアソフトウェアエンジニア、Natalie Zamani (She/Her) はこう説明します。「行動規範の有無は私にとって非常に重要です」 「また、一見無関係に見えること——例えば人種差別的・性差別的・同性愛嫌悪的・トランスフォビア的な思想を掲げるプロジェクト貢献者を、たとえプロジェクト作業と関係なくとも容認しない姿勢——も重要です。そうした見解を持つ個人とは、絶対に一緒に働きたくありません。興味を持てるはずのプロジェクトで、それが容認されている例をいくつか見てきました」 + +GNOME財団の元会長兼理事長として、SanchezはGNOMEのイベント行動規範策定に貢献しました。彼女は、[貢献者契約](https://www.contributor-covenant.org/)が多くのオープンソースコミュニティのデフォルト行動規範である一方、これをイベント形式に翻訳するには創造的な作業とGNOMEコミュニティからの多くのフィードバックが必要だったと語ります。 + +「導入する行動規範の種類に関わらず、透明性のある計画とタイムラインが鍵です」とSanchezは語ります。「GNOMEでは年次カンファレンス終了後、行動規範の草案作成を開始するワーキンググループを設立しました。作業部会の設置案は理事会に承認を得て、全コミュニティに向けてプロセスを告知しました。作業部会が行動規範を起草し、コミュニティに修正を依頼、修正案を理事会が審議・採決した後、年次総会で会員投票を行うという流れです。」 + +コミュニティのフィードバックが重要であるにもかかわらず、Sanchezは行動規範はプロジェクト内の統治機関が所有すべきだと述べています。行動規範はオープンソースコミュニティでは依然としてデリケートな問題であり、すべての貢献者が必要性を認めているわけではありません。多様な貢献者で構成され、作成プロセスを共有する統治機関（少なくとも委員会）を設けることで、意見の相違を緩和できます。統治機関を設立したら、特定の役割を担うメンバーを割り当てます。これには投票の同数決を打破できる議長、行動規範を執行するモデレーター、コミュニティを育成するメンターが含まれます。全てのコミュニティメンバー（特にURM）が、プロジェクトリーダーは彼らの安全と尊厳を守っている、ということを実感することが不可欠です。 + +「シグナリング（意思表示）は非常に重要だと確信していますが、一度壊れた信頼は修復が難しいです。」とEisingは説明します。「実際に準備が整う前に、[少数派]を受け入れる用意があるというシグナルを送ってはいけません。それはエレベーターのない[高層]階のパーティーに車椅子利用者を招待するようなものです。その人は、あなたが適切に彼らのニーズを考慮するとは二度と信じなくなるでしょう。組織は手を差し伸べる前に、内部を見つめ直し、真に評価する必要があります。」 + +### ステップ4：コード以外の貢献を評価する + +オープンソース活動を通じてSanchezは、多くのプロジェクトが限られた分野（エンジニアリング、デザイン、翻訳、ドキュメント作成、アウトリーチ活動）への貢献者募集に注力していると指摘します。一見広範に思えますが、以下の表は彼女が評価対象としたい、より多様な役割と貢献形態を示しています。 + +アウトリーチ活動の一環としてこの表を活用し、特定のキャリア領域と開発目標に焦点を当ててください。人々がプロジェクトの一員として自らを認識できるよう支援し、キャリア領域におけるスキルや経験がプロジェクトへの貢献にどう結びつくかを示しましょう。 + +| キャリア開発目標 | 確認すべきOSS組織内のチーム | 理由 | +| ------------------------- | ---------- ------------------------ | --- | +| 営業・事業開発 | 資金調達、パートナーシップ | オープンソースコミュニティ／プロジェクトの価値を提案し、コミュニケーションや交渉スキルなどを磨く必要がある点で共通しています。 | +| マーケティングスキル | エンゲージメント、マーケティング、アウトリーチチーム | こうした体制が整っていないプロジェクトもあり、支援を必要としています。経験が浅くても、そのコミュニティ内で最も経験豊富な存在となり、ゼロから構築するチャンスです。これは履歴書で非常に魅力的に映ります！ | +| 戦略スキル | 理事会／ガバナンスチーム、コミュニティチーム | 組織の成熟度にもよりますが、理事会では戦略スキルを磨く余地が通常大きくあります。プロジェクト全体を俯瞰でき、通常は資金管理の決定権を持ち、目標設定やプロジェクト推進を全く新しい次元で支援できます。すぐにその立場にはなれないため、イニシアチブを主導することでスキルを磨けます。オープンソースコミュニティチームでは、大きな役割を担う余地が常に多く存在します。 | +| データサイエンススキル | コミュニティチーム、理事会 | イニシアチブの成功を保証するために、どのようなデータが収集されているか？コミュニティの健全性を測定することは、ますます多くの人が関心を持ち始めており、データ分析に関心のある人々の支援が必要とされています。 | +| グラフィックデザインスキル | マーケティングチーム、技術プロジェクト | ブランドやマーケティング施策、プロジェクト全体の成熟度向上にはグラフィックデザインが不可欠です。ブランドガイドラインすら確立されていないプロジェクトも多く、デザイナー全般の需要は極めて高いです。 | +| プロジェクト管理・プログラム管理スキル | エンゲージメント、マーケティング、アウトリーチ、ドキュメンテーション、コミュニティチーム | プロセスと構造を構築できる高度に組織化された人材への需要が非常に大きい。推進役が不在で実現に至らない取り組みは数多く存在します。 | +| プロダクトマネジメントスキル | 技術プロジェクト全般、新規イニシアチブ、ウェブサイト、新規参加者向け施策 | 企業ではプロダクトマネージャー（PM）が不可欠ですが、オープンソースソフトウェアでは必ずしも容易に見つかりません。PMが参画し、より革新的なプロダクトを創出したり、コミュニティとビジネスの橋渡し役として各プロジェクトのリーチ拡大を支援する余地は大きくあります。 | +| 法的スキル | 理事会またはコミュニティチーム | オープンソース関連の法的問題を処理できる人材への需要が高まっています。弁護士はコミュニティチームでの活動や理事会への参加を通じて貴重な経験を積めます。 | +| 人事/人的スキル | 理事会、コミュニティチーム、新規参加者向け施策 | 人を大切にし、コミュニティを素晴らしいものにしたいと考える人材が必要です。 | + +*表1: プロジェクト役割とキャリア目標・スキルセットの整合* +このリストは網羅的ではなく、全てのプロジェクトに適用できるものでもありません。詳細については、本ガイドブックの「オープンソースプロジェクトにおける役割の範囲」の章を参照してください。目標は、自身のオープンソースプロジェクトの短期的・長期的な全体的なニーズを把握し、特定の不足を補う貢献者を募集することです。これにより、プロジェクトの特定の側面を担当し、その成長に貢献する代表者からなる統治機関を構築できます。 + +Nithya Ruff (She/Her) はコムキャストのオープンソースプログラムオフィス (OSPO) の責任者であり、Linux Foundation理事会の議長を務めています。20年以上にわたるオープンソース活動の中で、著作権や商標権などの法的問題を含む重要なスキルを無視することが、プロジェクトの長期的な成功を妨げる可能性があることを目の当たりにしてきました。また、多様な貢献者を募集し報いることは、プロジェクト管理者がますます声を上げているバーンアウト（燃え尽き症候群）を防ぐ上でも重要な役割を果たします。 + +「プロジェクトを立ち上げた、あるいは主導するメンテナや開発者に、こうした問題のすべてを気にかけたり、対応するスキルを求めたりするのは不公平です」とRuffは語ります。「あらゆる形の貢献を評価すべきです。なぜなら、それによって多様な人材がプロジェクトに参加し、プロジェクトをより活気ある革新的なものにするからです。Apacheソフトウェア財団やLinux Foundationのような財団は、ホストするプロジェクトに対してこうした貢献をすべて提供します。これによりプロジェクトはより広範なエコシステムを構築できます。」 + +### ステップ5：新たな人材を育成しプロジェクトを牽引させる + +Redis共同創設から11年後、Salvatore Sanfilippoは、NoSQLデータベースのプロジェクトメンテナ退任を発表しました。後継者としてYossi GottliebとOran Agraを指名し、Redisプロジェクトの維持を委ねました。これによりRedisのガバナンスモデルは刷新されました。 + +GottliebとAgraは従来のBDFL（単一リーダー）スタイルを維持せず、より軽量な新たなガバナンスモデルを構築しました。これは、長年のRedis開発者からなる少人数のグループを選出し、中核的貢献者としてプロジェクトの行動規範を遵守させる仕組みです。 + +自身のプロジェクトのガバナンスモデルに関わらず、主要な貢献者がリーダーシップの役割を担えるよう育成する仕組みを組み込む必要があります。これにより以下の3つの重要な目標が達成されます。 + +1. 新規貢献者が成長する方法を学ぶ支援 +2. プロジェクトの重要分野を担う貢献者を評価する +3. メンテナの燃え尽きを防ぐ + +この最後の点は注目に値します。SanfilippoはRedisから退任した際、コーディングへの情熱はあってもプロジェクトのメンテナを志したことはないと述べました。新たなリーダーが台頭せず、貢献者がそのような役割を担う方法を共有するドキュメントがなければ、メンテナはもはや望まないプロジェクトに取り組むか、プロジェクトが停滞するリスクを負うことになります。同様に、プロジェクト側も、意欲ある貢献者にステップアップの機会を与えるチャンスを逃すリスクを負います。 + +メンターシッププログラムの構築・維持そのものが、包摂性を体現しています。本書の取材に応じた複数のオープンソースリーダーは、オープンソース全体でメンターシップの必要性が明らかであり、自ら実践したいと語っています。メンターシップの力を強く信じるオープンソース貢献者は、貢献形態を再構築してこれを組み込んだケースもあります。また、自身の時間的制約を認識していたため、新たなリーダーに対しても柔軟性を提供しました。 + +「親になる前から、私のオープンソースへの貢献は確実に変化していました」と Odaは説明します。「夏に実施されるグローバルメンタリングプログラムのコーディネーターとして、私が担う全ての業務を遂行できるボランティアチームを構築するため、数年先を見据えた計画が必要でした。そのため、他のプロジェクトの一部をより完全に引き継ぎ、二度と戻らないようにしたのです。」 + +「新米ママの自由時間は通常1日1時間未満です。私にとっての鍵は、自分がやりたいオープンソース活動と、職場が報酬を支払うオープンソース活動を一致させることでした。産休明けにはCVEバイナリツールのオープンソース化に取り組み、メンターとしての役割で学生を指導する時間を確保できるよう上司と調整しました。」 + +独自のメンターシッププログラムを構築するには、Sanchezは次の4つの行動と取り組みに焦点を当てるよう提言しています。 + +> 学習機会を頻繁に創出する。自分の業務内容や手法を他者が学べる方法を見つける。公式なインターンシップやメンター制度を待つだけでなく、可能ならそれらを活用しよう。動画の録画、AMA（何でも質問会）の開催、イベント参加などを検討する。潜在能力のある人材を育成できるよう、関係性と信頼を築くため、非公式なコミュニケーションにも積極的に応じよう。広く網を張れば、プロジェクトを新たな高みへ導く準備が整った貴重な貢献者を見つけられるだろう。 +> +> 繋ぎ役になろう。コミュニティ内の有力な貢献者と彼らの強みを頭の中で整理しておこう。メンターシップを共有し、新参者を複数の人に紹介する。メンター側の燃え尽き症候群は現実の問題だ。あなたが休憩や多忙で対応できない場合、メンティーが他の支援者にアクセスできる体制を整えよう。 +> +> コミュニティ交流専用のチャットツールを用意しよう。信頼を築くには、プライベートな空間が必要だ。チャットは会話や協働を促進し、直接メッセージを送ることも可能にする。燃え尽き症候群を防ぐため、コミュニティ／仕事用とプライベート用にチャットツールを分けることを検討しよう。そうすれば、休憩が必要な時に一方の通知を全てオフにできるほか、UXの違いによって自然と区別がつくから。 +> +> イベントを通じた繋がりづくり。イベントは潜在的なメンティーと繋がる強力な機会だ。こうした場では、人々が気軽に交流できる楽しいアクティビティを計画しよう。例えば、互いに質問を交わして抽選会に参加する「人ビンゴ」や、市内ツアー、ゲームナイトなどが考えらる。年間を通じた楽しい活動は本物の関係を育み、貢献への恐れを克服する助けにもなる。 + +オープンソースコミュニティにおけるメンタリングのさらなるアイデアについては、本ガイドブックの「メンターシップ文化の構築」の章を参照してください。 + +### ステップ6：継続的改善への取り組み + +インクルージョン（包摂性）の取り組みは決して終わることのない継続的な作業です。プロジェクトが成長するにつれ、新たな課題の発見、文書化すべき疑問点、行動規範への追加事項が次々と現れます。コミュニティがより包摂的になるほど、不足している点が増えたように感じられるかもしれません。これは不快な感覚ですが、実は良い兆候です。継続的な改善に取り組むという困難な作業を成し遂げた証だからです。また、包摂的なチーム構築に取り組んできたなら、この作業は一人で行う必要はありません。コミュニティと作業を共有し、全員にフィードバックを提供する機会を与えましょう。 + +対話を継続的かつオープンに保つため、コミュニティが自身の体験についてフィードバックを残せる選択肢を提供しましょう。四半期ごとのアンケートから、プロジェクトのコミュニケーションプラットフォームにチャンネルを作成する自由を貢献者に与えることまで多岐にわたります。メンタルヘルス、有色人種としての経験、交渉の進め方などについて話し合うためのチャンネルです。こうしたチャンネルは、非同期の協働を促進するために不可欠な、貢献者同士の社会的つながりを生み出します。また、貢献者がより充実した貢献ができるよう支援する新たな方法も提供します。 + +「私は聴覚障害者です。All Things Openカンファレンスに対し、基調講演が行われる大規模会場において、聴覚に障害のある参加者向けの特別な配慮がなされていない状況を踏まえ、聴覚障害への配慮を検討するよう要請しました。」と、Linuxコミュニティで20年にわたり活動するOpenSource.comのコミュニティ・コレスポンデント、Don Watkins (He/Him) は説明します。「[All Things Openにより]聴覚に障害のある私たちのための具体的な配慮が追加されました。」 + +「特に感銘を受けたのは2018年にトロントで開催されたクリエイティブ・コモンズ・グローバルサミットです。ほぼ全てのプレゼンテーションで手話通訳者が同行し、さらに全スピーカーの同時字幕提供が行われていました。」 + +インクルージョン（包摂性）は一度きりのプルリクエストではありません。継続的で重要な活動です。包摂的なコミュニティを構築・維持しなければ、オープンソース貢献者の多様性を向上させる望みはありません。新たな人材を募集し、メンテナの燃え尽きを防ぎ、肯定的なオンライン環境を創出するには、オープンソースメンテナがインクルージョンに取り組むべきです。変化は内部から始まります。多様な背景を持つ技術貢献者があなたの包摂的取り組みを目にすれば、参加する可能性は格段に高まります。 + +「人々が参加し、貢献しやすくすること」とRuffは述べます。「優れたプロジェクトの証は、その複雑さではなく、参加の容易さにある。」 diff --git a/l10n/ja/attracting-users/communication-norms-in-open-source-software-projects.md b/l10n/ja/attracting-users/communication-norms-in-open-source-software-projects.md new file mode 100644 index 00000000..ff62e6a8 --- /dev/null +++ b/l10n/ja/attracting-users/communication-norms-in-open-source-software-projects.md @@ -0,0 +1,314 @@ +--- +author: Leslie Hawthorn +updated: 2020-10-29T00:00:00.000Z +translated-by: Ken Komazawa powered by DeepL Pro +--- + +# オープンソースプロジェクトにおけるコミュニケーションの規範 + +プロジェクトがコミュニケーションに用いるツールは絶えず進化していますが、プロジェクト参加者間のコミュニケーションにおけるベストプラクティスはほとんど変わりません。この章では、プロジェクトコミュニケーションの基本を扱い、特定のツールやプラットフォームを最大限に活用してグローバルな対象者にサービスを提供するためのアドバイスを提供します。特定の規範や手法が、プロジェクトが選択するコミュニケーションツールやプラットフォームに関わらず、あらゆる場所で生産的なコミュニケーションを維持するために有効であることがわかるでしょう。そして最後に、オープンソースプロジェクトにおける絶えず変化するツールやコミュニケーション慣行が、外部観察者（特に学術研究者）にとってどのような課題をもたらすかについての考察と、すべてのプロジェクト参加者に利益をもたらす形でそれらの課題を軽減するための提言をまとめます。 + +## フリー＆オープンソースソフトウェアプロジェクトにおけるコミュニケーションプラットフォームの進化 + +フリー＆オープンソースソフトウェアプロジェクトの数が増加するにつれ、ユーザーとの連携や開発者・貢献者の調整に用いられるコミュニケーションツールも進化してきました。かつてリアルタイムのプロジェクトチャットにはインターネットリレーチャット（IRC）がデフォルトで採用されていました。多くの大規模プロジェクトでは、開発に関する議論は電子メーリングリストのみで行われていました。新規プロジェクトのリリース情報や既存プロジェクトの更新情報は[Freshmeat](https://en.wikipedia.org/wiki/Freecode)で確認するのが一般的でした。機能設計やプロジェクト改善に関する議論はメールで行われ、プロジェクトのメーリングリストアーカイブに記録されていました。 + +今日、この状況は複数の点で変化しています。 + +リアルタイムチャットは現在では以前ほど一般的ではありませんが、プロジェクトが完全に放棄したわけではありません。多くのプロジェクトは、Matrix、Slack、RocketChatなど、よりユーザーフレンドリーでアクセスしやすいとみなされるサービスを採用しています。コミュニティが新しいサービスを取り込むように進化するのを支援するため、プロジェクトがIRCなどの古いチャットシステムにブリッジするツールを使用することさえあります。 + +非同期コミュニケーションにメールを依然として用いるコミュニティもあれば、オンラインフォーラムでの協働機会を提供することでより良い成果を得られると気づいたコミュニティもあります。これは、当時新しく人気を博したRedditやImgurといったフォーラムサイトでニュースや見解を共有しながらコーディングを始めた多くの開発者にとって馴染み深い形式です。フォーラム支持者は視覚的なレイアウトをより魅力的と感じ、フォーラム管理者はモデレーションに使いやすい細かなアクセス制御を好むことが多いです。（例えば、白熱した議論中に特定スレッドの投稿を全て停止する機能は、ほとんどのフォーラムソフトウェアでは比較的容易に実現できるが、メーリングリストではそうではない。） + +[Freshcode](https://freshcode.club/)のようなサイトが初期の精神を維持している一方で、フリーでオープンソースのソフトウェアプロジェクトも、ユーザーや開発者コミュニティとの交流のためにXやFacebookなどのソーシャルメディアサービスを幅広く活用しています。ソーシャルメディアはプロジェクトのマーケティングや主要な進展を関係者に伝える優れた手段となります。 + +ソーシャルメディアは以下の目的にも活用されます。 +* 今後のイベント告知 +* コンテンツや講演のライブ配信 +* プロジェクトへの関心喚起 +* ニュースレター・公式サイト・ブログを超える範囲へのマーケティングや広報活動 +* また多くのユーザーは、これらのプラットフォームを通じた基本的な技術サポートを当然のものと期待しています。 + +メーリングリストのアーカイブがプロジェクト議論の決定的な記録として機能しなくなった一方で、オンライン開発・コラボレーションプラットフォームとしてのGitHubの人気により、多くのプロジェクトが開発議論をGitHubイシューで管理するようになりました。GitHubイシューには_タグ_を付与でき、例えば新機能実装に関する議論と、ソフトウェアが意図した通りに動作しないという報告を区別できます。 +しかし、フリー／オープンソースプロジェクトがコミュニケーション達成に用いるツールが急速に進化する一方で、情報とつながりの感覚に対する人間のニーズは変わっていません。 + +### プロジェクトコミュニケーション：基本原則 + +#### 優れたコミュニケーションが達成すること + +オープンソースソフトウェアコミュニティと協働する上で、人々は「誰が」「何を」「どこで」「いつ」「なぜ」「どのように」行うのかを理解する必要があります。慎重に構築され適切に維持されたコミュニケーションチャネルは、オープンソースプロジェクトとその参加者に以下を可能にします。 + +* ソフトウェアの性質、利用価値、導入方法に関する共通認識を確立する。 +* ソフトウェアの使用方法やプロジェクトへの貢献方法をコミュニティに周知する。 +* プロジェクトのイベント（カンファレンスやウェビナーなど）や進展（新機能の追加、ワーキンググループの結成、新規貢献者の参加など）に関する情報を提供し続ける。 +* プロジェクトの意思決定の規範や慣行に関する知識を保存する。 +* ユーザーがオープンソースプロジェクトのソフトウェア自体に関するエラーを報告し、自身や他者が発見したエラーの修正を提出できるようにする。 +* 参加者間の共通の関心や目的意識を醸成し、プロジェクト関係者がオンライン交流や「たまり場」を設ける。 +* プロジェクトのドキュメント作成やコードベース特定部分のリファクタリング方法の議論など、貢献者が協働できる場を提供する。 + +#### 対象読者を把握する + +プロジェクトのドキュメントや情報リソースを開発する際、この作業には複数の異なる対象読者が存在することを認識しましょう。これらの対象者を理解し、それぞれの固有のニーズを優先することで、より優れた資料を作成できます。 +例えば、プロジェクトの_ユーザー_と_開発者_という基本的な区別を考えてみましょう。ソフトウェアの_使用_に関心のある人は、インストール方法、設定方法、手元のタスク（例：ウェブサイトの構築）を達成するために必要な知識などに興味を持つでしょう。開発者もこうした詳細には関心を持ちますが、プロジェクトに効果的に貢献するためには追加情報が必要となります。 +プロジェクトで特定のコーディング規約を採用している場合は、開発者向けドキュメントに必ずそれらを含めること。特定のインデント方法を守らなかったためにメンテナにパッチを拒否されるのは、やる気を削ぐ結果になりかねません。一方、ユーザーはこうした詳細を必要としない可能性が高いです。 + +{% hint style="success" %} +プロジェクト用のスタイルガイドを作成し、開発者向けドキュメント内で容易に参照できるようにしてください。全てのプロジェクトが独自のスタイルガイドを作成するわけではありませんが、プロジェクトが遵守するコーディング規約を明記することがベストプラクティスです。既存の公開済みスタイルガイドを使用する場合は、開発者向けドキュメント[^guides]内でそのリンクを必ず記載してください。 +{% endhint %} + +### 仮想ショーケース：プロジェクトウェブサイトの構築 + +問題解決に役立つソフトウェアの情報を探す際、人々が最初に訪れるのはプロジェクトウェブサイトでしょう。 +効果的なプロジェクトサイトは複雑なデザインを必要としません（ただし魅力的なサイトはプロジェクトのマーケティングに役立ちます）。GitHub上の詳細な`README.md`ファイルは、ユーザーや潜在的な貢献者にプロジェクトの概要を十分に提供できる限り、プロジェクトサイトとして十分に機能します。基本的なプロジェクトサイトには少なくとも以下のセクションを含めるべきです。 + +#### プロジェクト概要 + +プロジェクトウェブサイトの目立つ場所に、プロジェクトの簡潔な概要を掲載しましょう。この説明には、コードベースが何を目的として設計されているか、そしてそれを使用することで解決できる可能性のある問題を含める必要があります。この情報を簡潔かつ見つけやすくすることが重要です。プロジェクトのホームページに簡単な説明を掲載し、関心のある人がすぐにプロジェクトが自身のニーズを満たすように設計されているかどうかを判断できるようにしましょう。 +この情報は、プロジェクトを全く知らない人に、30秒以内でその重要性を説明する機会と捉えてください。例えばDrupalの[aboutページ](https://www.drupal.org/about)は次のように説明しています。 + +> Drupalはコンテンツ管理ソフトウェアです。日常的に利用する多くのウェブサイトやアプリケーションの構築に使用されています。Drupalは優れた標準機能を備えています。例えば、簡単なコンテンツ作成、信頼性の高いパフォーマンス、優れたセキュリティなどです。しかし、Drupalを際立たせているのはその柔軟性です。モジュール性は中核的な原則の一つです。Drupalのツールは、ダイナミックなウェブ体験に必要な、多様で構造化されたコンテンツを構築するのに役立ちます。 + +この説明（たった1段落）から私たちは次のことを学びます。 +* Drupalとは何か（コンテンツ管理システム）。 +* コンテンツ管理システムとは何か（ウェブサイト構築のためのツール）。 +* Drupalが優れた選択肢である理由（使いやすさ、信頼性、安全性、柔軟性） + +人気プロジェクト「Kubernetes」の例を見てみましょう。 + +プロジェクトホームページ[kubernetes.io](http://kubernetes.io/)にアクセスすると、訪問者はすぐに以下の説明を目にします。 + +> Kubernetes（K8s）は、コンテナ化されたアプリケーションのデプロイ、スケーリング、管理を自動化するオープンソースシステムです。アプリケーションを構成するコンテナを論理的な単位にグループ化し、管理と検出を容易にします。Kubernetesは、Googleにおける15年にわたる本番ワークロードの運用経験と、コミュニティから得た最先端のアイデアや[実践手法](https://kubernetes.io/)を基盤としています。 + +この説明から、私たちは即座に以下のことを学びます。 +* Kubernetesとは何か（コンテナ化されたアプリケーションのデプロイ、スケーリング、管理を含むシステムであること） +* Kubernetesの略称（このような細かい説明は新規訪問者の安心感を即座に高めます。難解な頭字語を最初から知っている必要はありません） +* Kubernetesの開発元（Googleがコードベースの創始者として明記され、プロジェクトがエンタープライズアプリケーションに焦点を当てていること、ソフトウェアが適切に設計・保守されているという信頼性を提供します） +* Kubernetesはオープンソースであること（ユーザーはコードベースの使用、実行、修正、変更の共有を期待でき、ライセンス料や調達プロセスなどによる参入障壁に関する疑問は払拭されます）。 +* プロジェクトはコミュニティ参加を重視している。（コードやドキュメントなどの貢献が歓迎され、奨励されることが期待できる。） + +#### 入門 + +優れた「入門」ドキュメント（時に「オンボーディング文書」と呼ばれる）の作成プロセスは、本章の範囲外です。（詳細は本ガイドブックのオンボーディング専用章を参照のこと）ここでは、オープンソースプロジェクトのウェブサイトには、新規ユーザーや潜在的な貢献者がソフトウェアを使い始めるのを支援するセクションを設けるべきだ、と述べるに留めます。そのセクションを「入門」または「新規ユーザー」と明確にラベル付けすれば、必要な時に見つけやすくなります。オンボーディングドキュメント内で「新規ユーザー」と「新規貢献者」をさらに区別するとより効果的です。両者のニーズは大きく異なるためです。プロジェクトサイトで新規参加者にこれらのリソースを明確に示すことで、フォーラムやリアルタイムチャットルームといった他のコミュニケーションチャネルが、入門方法に関する頻繁な問い合わせで埋まるのを防げます。 + +{% hint style="success" %} +新規ユーザーや参加者を対象としたプロジェクトの「はじめに」ガイドには、プロジェクトに不慣れな人が支援を受けられる他の場所に関する情報を可能な限り含めましょう。例えば、メンタリングや初心者支援を好むメンバーが常駐する「newbies」というSlackチャンネルがある一方、継続的な開発議論は「developer」チャンネルで行われるといったケースが考えられます。 +{% endhint %} + +#### よくある質問 + +プロジェクトの基本情報を掲載するもう一つの優れた場所は、よくある質問（FAQ）ページです。プロジェクト開発が始まったばかりの場合、プロジェクトの概要、コードベースの用途、コードへのアクセス方法などを詳細に説明した基本的なFAQで十分です。しかし、新規ユーザーや開発者、ドキュメンターなど参加者が増えるにつれ、同じ基本的な質問に繰り返し答えることになるでしょう（その過程で、プロジェクトの多くの側面が自分たちには自明でも、新規参加者にはそうではないことに気づくはずです）。こうした繰り返しの質問は、ドキュメントを改善し、コミュニティの助けを求める機会となります。 + +FAQは常に最新の状態に保ち、見つけやすくしてください。さらに良いのは、コミュニティ参加者に改善を手伝ってもらうことです。新規参加者の質問に答える際（プロジェクトメーリングリストのメールでもリアルタイムチャットでも）、その質問と回答をプロジェクトFAQに掲載するよう依頼しましょう。コミュニティに協力を求めることで、以下の効果が得られます。 + +1. ドキュメントの関連性と最新性を維持する支援が得られる。 +2. プロジェクトへのコミュニティ貢献が歓迎され奨励されていることを示す。 +3. 既にプロジェクトに関心を示した人物に協力を依頼することで、さらなる貢献を促す。 + +理想的には、新規参加者が自らFAQを編集できる環境を整えましょう。FAQ編集の手順を貢献依頼と共に送付することで参入障壁を下げ、貢献を得やすくなります。プロジェクトで貢献者リストを管理している場合は、FAQに貢献している人々も必ず含めてください。人々は自分の仕事や貢献（どんなに小さなものでも）が認められることを喜びます。これにより貢献者はプロジェクトへの帰属意識とコミットメントを感じます。自分の仕事が評価され尊重されていると感じる人々は、問題報告や新機能追加など、プロジェクトへの継続的な貢献を続ける可能性が高まります。 + +#### プロジェクトの目標と非目標を文書化する + +プロジェクトのウェブサイトでは、プロジェクトの_目的_と、プロジェクトが重点を置く_活動_も明確に示すべきです。現在進行中の活動や将来の計画が理解できない場合、人々はコミュニティにどう関わるべきか、どう貢献できるかを把握しにくくなります。 + +こうした目標を伝える一般的な手段として、プロジェクトロードマップが挙げられます。たとえプロジェクトにロードマップ作成の十分なリソースがまだ整っていなくても、ユーザーや潜在的な貢献者がプロジェクトの全体像を理解できる方法を何らかの形で確保すべきです。例えば、プロジェクトの活動状況と今後1週間または1か月間の予定をまとめた週次レポートは優れた出発点であり、簡単なブログ記事やフォーラム投稿で提供できます。こうした資料は新規参加者がプロジェクトを理解する上で有益な情報源となり、関心を持つ人々がオンボーディングプロセスの一環として詳細を学ぶための素晴らしい案内役となります。 + +プロジェクトの_非目標_を伝えることも同様に重要です。オープンソースプロジェクトの活気ある性質上、プロジェクト作成者が意図しなかった用途を見出し、特定のユースケースに対応するため機能拡張を望む人が現れるのは当然です。プロジェクト管理者が既存の提供範囲を超える広範なフォーカスを意図していない場合、こうした潜在的な貢献者に事前にその旨を伝えることで、双方の時間と失望を節約できます。[容易なフォーク](https://en.wikipedia.org/wiki/Fork_\(software_development\))が可能な現代においては、プロジェクトの一部のみを利用したいユーザーが、元のプロジェクトの意図したビジョンや設定された範囲から逸脱するよう要求することなく、自身のニーズに合致したコードベースを開発・維持することは比較的容易です。 + +非目標の文書化は、商業的に焦点を当てたプロジェクトにおいて特に重要です。貢献者がオープンソースとして機能を作成したいという願望が、ベンダーが独自機能を開発する目標と衝突する可能性があるためです。貢献者は依然としてその機能をオープンソースとして作成することを選択するかもしれませんが、彼らは最初から、上流のメンテナがその作業をプロジェクトのコードベースの一部として含める意図がないことを知るべきです。ベンダーが代わりに開発していると知れば実装を控える者もいれば、プロジェクトのメインソースツリーに組み込まれないと知れば、継続的なメンテナンス負担を自ら負いたくないため実装を断念する者もいます。また、プロジェクトのメインソースリポジトリに組み込まれるか否かに関わらず、自社のニーズに合致するものを開発しオープンソースとして公開する者もいます。 + +ここで最も重要なのは、プロジェクトの方向性に誰も_驚かされる_ことがないことです。全ての貢献を受け入れる必要はありませんが、貢献者が時間と労力を注いで開発したものが、未知のロードマップ（商用・非商用を問わず）との矛盾を理由に受け入れられないと判明した場合、コミュニティに緊張が生じ、プロジェクト管理者の信頼が損なわれます。これはベンダー製品に代わるオープンソースの代替案の採用を促すことさえあります。 + +### 意図した動作をしない：課題管理ツールを最大限に活用する + +このセクションでは、課題管理ツールを重要なコミュニケーションツールとして活用する方法について詳しく説明します。 + +#### 課題管理ツールとは？ + +_課題管理ツール_（_バグ管理_、_課題リスト_、_課題キュー_とも呼ばれる）とは、ソフトウェアが意図した動作[^not-working]をしていないと思われる事例に遭遇した際に、報告を提出できるツールです。未処理タスクの監視や進行中の作業に対する共同コメント・レビューを可能にする手段として、プロジェクトによっては開発ワークフロー全体を課題管理ツールで管理しています。 +本節では、ソフトウェアの不具合報告を目的とした課題管理ツールの活用法について説明します。プロジェクトの課題管理ツールで問題を報告することで、問題を探しているメンテナが確実に報告を確認し、対応するよう促せます。 + +#### なぜ課題を報告するのか？ + +リアルタイムチャットで直接助けを求めるより面倒に思えるかもしれませんが、以下の理由から重要です。 +プロジェクト貢献者は複数のプラットフォームで交わされる全会話を追跡できませんが、課題管理ツールを参照してプロジェクトを改善することは常に可能です。 + +リアルタイムチャットやソーシャルメディアは一時的なコミュニケーション手段です。課題管理ツールはソフトウェアの問題を記録・検証するために設計された専用ツールです。ソフトウェアプロジェクトでは、今後の作業計画を策定する際、課題管理システムを主要な（場合によっては唯一の）ツールとして活用し、取り組むべき全領域の優先順位付けを行います（端的に言えば、プロジェクトの課題管理システムは往々にしてプロジェクトのToDoリストと同義です）。あなたの問題が課題管理システムに記録されなければ、多忙な担当者が問題の詳細を忘れてしまうだけで、対応されない可能性が高いのです。このため、支援を求めると最初に「問題を記録してください」と求められることがよくあります。そうすることでプロジェクト管理者が問題を追跡できるからです。 + +問題を記録することで、関係者全員がいつでも問題の説明やフォローアップのコメントを参照・アクセスできるため、非同期的にコミュニケーションを取ることが可能になります。 + +ソフトウェアの問題を発見した際、その問題が実は_別の_問題の根本原因である場合や、_複数の_問題が関連している可能性に気づくことがあります。課題管理ソフトウェアは関連する課題をグループ化できるため、問題の根本原因を特定する手助けとなります。 + +ソフトウェアでは同じ問題が頻繁に発生し、多くの人がプロジェクトに課題を報告しています。同一問題の複数報告は、進行中の作業について各報告者へ個別対応する必要が生じるため、プロジェクト管理者の時間を大きく消費します。幸い、課題管理ツールでは既存課題の重複として迅速にクローズし（報告者には「元」報告で進行状況を追跡するよう案内）、このプロセスを効率化できます。 +プロジェクト管理者は、問題を抱える全員に対して一箇所で一斉に情報を発信できるようになり、支援を必要とする全員を助けつつ、自身のワークフローを効率化できます。 + +#### 課題管理ツールを容易に見つけられるようにする + +プロジェクトの課題管理ツールの場所を、FAQや使用方法・開発ドキュメントに目立つように記載してください。課題の提出先がわからない場合、ユーザーはプロジェクト関係者に問い合わせることになります。このような基本的な質問に繰り返し回答することで善意のユーザーをサポートするのは、非常に時間がかかる場合があります。 +自身とコミュニティのために、課題管理ツールを非常に見つけやすくしてください。 + +#### 問題報告テンプレートの活用 + +ソフトウェアを利用するすべてのユーザーが、有用なバグ報告の提出方法に関するコミュニティの慣習に精通しているわけではありません。報告者と自身の双方の時間を節約するため、必要な情報を確実に受け取れるよう問題報告テンプレートを提供しましょう。これにより、報告されたエラーを再現し効果的にトリアージできます。例えば、エラー発生時のソフトウェアバージョンや使用OSの把握が必要な場合があります。エラー再現に共通して必要な情報があるなら、問題報告テンプレートで要求してください。 + +問題報告テンプレートの一般的な項目には、課題の概要、再現手順、ユーザーが実際に観察した動作、ソフトウェアの意図された動作、およびバグ報告の理解を深めるためのログファイルやスクリーンショットの提供依頼が含まれます。バグ報告用のテンプレートをサポートする課題管理ツールには、[GitHub](https://docs.github.com/en/github/building-a-strong-community/configuring-issue-templates-for-your-repository)、[GitLab](https://docs.gitlab.com/ee/user/project/description_templates.html)、 [Redmine](https://www.redmine.org/plugins/redmine_issue_templates)、[Trac](https://trac-hacks.org/wiki/TracTicketTemplatePlugin)などがあります。 + +異なるバグ報告に対して同じ情報を繰り返し要求していることに気づいたら、おめでとうございます。テンプレートの改善が必要な領域を発見したのです。 + +#### 募集：明確化と貢献促進のための課題ラベル付け + +現代の課題管理ツールでは、ユーザーが提出した課題にラベルを付けることが可能です。これはプロジェクト作業の整理に役立ちます。開発対象の機能、ソフトウェアエラーなど、異なる種類の要求を区別することで、プロジェクトの管理者はより組織的に課題を選別し、効率的に対応できます。さらに、オープンソースプロジェクトへの貢献に関心を持つ多くの人々は、プロジェクトの開発メカニズムを理解するために取り組める課題を探しています。課題管理システムでラベルを積極的に使用する場合は、開発ドキュメントにラベル定義を明記し、一貫した使用を確保してください（または課題ラベルの追加をプロジェクト管理者のみに制限）。一貫性のないラベルのリストは、区別のない課題のリストと変わりません。 + +「新規参加者向け」や「協力者募集」といったラベルを付けることで、プロジェクト管理者は新規参加者に特に適した課題を明示できます。このようなラベル付けは、プロジェクトが新規貢献者の受け入れ準備が整っていること、および特定の領域でコミュニティの支援を歓迎していることを示します。プロジェクトのドキュメントやウェブサイト、その他問題と感じる点に対して、遠慮なく課題を提出してください。現在および将来の貢献者がプロジェクト改善に貢献できる箇所があれば、明確なラベルを付けて課題管理システムに記録し、貢献の機会があることを示しましょう。 + +ただし、_非常に明確に_（「協力者募集」ラベルの課題の本文内か、他のプロジェクト文書へのリンクで）こうしたイシューに取り組む際のプロジェクトへの関わり方を示してください。（[Apache Subversion Issuesページ](https://subversion.apache.org/reporting-issues.html)は、ユーザーコミュニティがイシューを提出する前にニーズを明確に伝える優れた例です。） これらの課題に取り組む貢献者には、プロジェクトへの貢献が採用される可能性を高めるため、進行中にプロジェクト管理者と連携するよう促すのが最善です。提示された問題に対する実用的な解決策を持ち込んだにもかかわらず、その実装がプロジェクトの要件を満たさないと言われるほど、貢献者の意欲を削ぐものはありません。 + +#### 明確かつ親切にコミュニケーションを取る + +プロジェクトのユーザーとして問題を報告する場合でも、プルリクエストをレビューするプロジェクトメンテナの場合でも、問題について_明確に_かつ_親切に_コミュニケーションを取ることが常に重要です。ツールが機能しない場合、それを使用している人は苛立ちを感じることがあります。同様に、趣味でプロジェクトを開発している人は、自分自身が直面していない問題を修正するために時間を割くよう要求されても、快く応じる可能性は低いでしょう。プロジェクトの健全性と健全な発展に貢献しているのは、知識を共有するすべての参加者であることを忘れず、他の参加者との議論では礼儀正しく感謝の気持ちを忘れないようにしてください。 + +#### 問題が激しい議論の対象となる場合 + +特定の問題への対処方法の詳細が、コミュニティ内で緊張や議論を引き起こすことがあります。 +健全で敬意ある議論は、ソフトウェアに限らずあらゆる繁栄するプロジェクトの一部ですが、感情が高ぶるのは容易であり、[よく知られているように](https://www.bbc.com/future/article/20180403-why-do-people-become-trolls-online-and-in-social-media)、人々は対面時よりもオンライン上では礼儀正しさを欠いた行動を取りがちです。 +議論が特に紛糾し、発言が粗暴または扇動的になった場合、一定期間（例えば24～48時間）そのイシューへのアクセスを制限し、関係者が冷静さを取り戻し、反省し、より穏やかで建設的な方法で主張を述べられる時間を与えましょう。 + +#### 問題報告のクイックヒント + +特にプロジェクトに初めて参加する場合は、ソフトウェア開発者への感謝の意を伝えましょう。あなたのためにフリーでオープンソースのソフトウェアを（余暇の）時間を使って作成している人々も、自分の時間が尊重され、仕事が評価されていることを知りたいのです。 +遭遇したエラーについて、可能な限り多くの情報を含めてください。プロジェクトが問題報告テンプレートを使用している場合は、可能な限り完全に記入してください。 + +要求された情報が不足している場合や、自分で入手する方法がわからない場合は、情報を得るために試みた手順を簡潔に記述してください。これらの詳細が、メンテナが支援に必要な判断材料となります。 + +プロジェクトが課題テンプレートを使用していない場合は、「解決済み」の課題やマージされたプルリクエストを参照し、他の人がどのようにバグ報告を提出したかを確認してください。課題が修正されている場合、これらの過去の記録を、エラーを再現するために必要な情報の種類の例として利用できる可能性が非常に高いです。これらの報告で見つけた内容を再現し、可能な限り詳細を追加してください。 + +#### イシュー対応のクイックヒント + +> 「開発コミュニティの規模やスキルによってチケット解決の速度は制限されますが、プロジェクトは少なくともチケットが投稿された瞬間に確認の返信を試みるべきです。たとえチケットがしばらく放置されても、返信があれば報告者は関与を続けようとするでしょう。なぜなら、自分の行動が人間に認識されたと感じるからです（チケット作成はメール投稿などよりも労力がかかることを忘れないでください）。」 +> +> — Karl Fogel『Producing OpenSource Software（邦題：オープンソースソフトウェアの生産）』[^fogel-oss] + +問題報告者への感謝を伝えましょう。プロジェクトの改善を支援することは、その健全性への優れた貢献です。さらに、礼儀正しく親切で歓迎の意を示すことで、報告者の継続的な参加と貢献を促せます。 + +問題を「修正しない」としてクローズする際は、修正しない理由を説明してください。メンテナは全てのプルリクエストを受け入れたり、報告された問題を全て修正したりする必要はありませんが、少なくともバグ報告者に対して、特定の課題に対処しない_理由_を伝えるべきです。 + +特に、問題修正や新機能実装のためのコードを伴うイシューが提出された場合、その作業がプロジェクトで受け入れられなかった理由を伝えることが極めて重要です。そうしないと、貢献者は時間を無駄にしたと感じ、別のソフトウェアプロジェクトに力を注ぐべきだと考えるようになります。理想的には、提出物がプロジェクトのニーズを満たさない理由を説明する公開されたプロジェクトロードマップへのリンクを添付できると良いでしょう。(上記参照) + +新規貢献者からの提出物については、軽微な問題をパッチで自ら修正し、修正内容と理由を注記してください。些細な理由でパッチが却下されると、さらなる貢献意欲が損なわれます。また、ごく小さな修正を行うのと同様に、却下理由を説明するのにも同程度の時間がかかることがよくあります。こうした説明は、コーディングスタイルガイドやコミュニケーション規範に関するドキュメントなど、プロジェクトの追加リソースを貢献者に紹介する絶好の機会です。 + +「協力者募集」イシューへの応答として提出される場合は、そのイシューへの関心を表明した人物と早期かつ頻繁に連携してください。これにより、貢献者の提出物が実際にプロジェクトのニーズを満たすことが保証されます。さらに、新規貢献者と定期的に対話する姿勢を示すことで、相互学習を促し、彼らがプロジェクトの継続的な作業に貢献し続ける可能性を高める関係を築けます。 + +#### 開発議論やその他の会話を課題管理ツールで行うこと + +オープンソースソフトウェア開発の初期段階における通説では、コミュニティはプロジェクトの課題管理システムで開発関連の議論を_行わない_べきとされていました。プロジェクトコミュニティは、いくつかの理由から、メーリングリストやフォーラムを通じてそのような会話を続けることを好みました。 + +* メーリングリストをフォローしている人々は、課題管理ツールを精査する必要なく、コメントや意見、ニーズを表明できた +* フォーラムやメーリングリストでの会話は非同期かつ長文のコミュニケーションに適していると見なされ、1990年代から2000年代初頭の主要な課題管理ツールは実際の議論を行うには扱いにくい手段だった +* 技術的決定の背景が課題管理ツールに埋もれていると、その理由を把握するのが困難だった。特に決定後は「クローズ」状態となるため、プロジェクトの技術的方向性を説明するためにクローズ済みイシューを探すのは直感に反すると考えられていた。 + +オンライン開発作業のワンストッププラットフォームとしてGitHubが普及するにつれ、プロジェクトの課題管理ツール内での議論が主流となりました。GitHubの課題システムは、フォーラムソフトウェアに典型的に期待される視覚的インターフェースを視覚的に反映しており、オンラインフォーラムが普及し始めた頃に開発キャリアを始めた人々にとって、そのシステムでの議論は自然なものに感じられました。さらに、他のすべてのインフラが単一のツールで管理できるようになった今、プロジェクトインフラの一部としてMailmanインスタンスや追加のフォーラムソフトウェアを維持するために必要な時間とリソースは煩雑なものとなりました。「イシューに+1する」機能や、特定イシューの通知を細かく制御する機能、プロジェクト管理者のみが編集可能（閲覧は他者も可）なイシューをロックする機能などの追加により、課題管理ツール内での議論への移行はより受け入れやすく効果的なものとなりました。 + +とはいえ、関心のある関係者はプロジェクトの課題管理ツール_外_でも議論を追跡できるべきです。最も深く関与している者だけが全ての課題更新を厳密に追跡するため、カジュアルな貢献者がプロジェクトに参加しにくくなっています。オンライン課題管理ツールの優れた検索機能は閉じた課題の発見を容易にしますが、課題議論の流れは特定の実装に関する記述や決定理由の説明と同じ機能を果たしません。また、プロジェクトに最も精通したメンテナ（特定の議論のイシュー番号を容易に思い出せる者）が、常にプロジェクト作業を支援できるとは限らない点にも留意すべきです。 + +意思決定に関する知識を容易にアクセス可能な形で保存することの利点： +* プロジェクトプロセスの背景を解明する作業者の時間を節約する。 +* メンテナが歴史を定期的に再説明する必要がなくなり、時間を節約する。 +* プロジェクトメンバーが入れ替わっても、決定の経緯や理由に関する重要な詳細が常に利用可能であることを保証する。 + +{% hint style="success" %} +プロジェクトの開発議論の大半を課題管理ツールで行っている場合、関心のある関係者や一般の広い層にとって最もアクセスしやすく発見しやすい方法で、これらの議論を強調する小さな取り組みを検討してください。 +{% endhint %} + +例えば、問題に関する議論をブログ記事、フォーラム投稿、プロジェクトニュースレターで要約することで、プロジェクトの文化的知見を保存しつつ、変更内容を広範なコミュニティに同時に周知できます。ブログや適切な発信手段がない場合は、プロジェクト文書に転換点となった問題の一覧を追加することを検討してください。これにより新規参加者は重要なトピックを迅速に把握でき、長年の参加者も参照しやすくなります。 + +### 地球規模での効果的なコミュニケーション + +#### インターネット共通語としての英語 + +世界には6,500以上の言語が存在しますが、歴史的経緯からインターネット上での主要なコミュニケーション言語——ひいては主要なオープンソースプロジェクトの言語——は英語です。英語を母語としないユーザーや貢献者にとって、この事実は参加への大きな障壁となり得ます。プロジェクトが、英語を第一言語としない人々がより効果的に参加できるよう支援するために取ることができるいくつかのステップがあります。 + +#### 複数の言語で利用可能なコミュニティリソースを目立つように認識する + +プロジェクトが広く採用され、複数の言語でコミュニケーションチャネルをホストするほどに成長した場合、これらのリソースをプロジェクトのウェブサイト上で目立つようにリストアップしてください。プロジェクトのウェブサイトには、英語以外の言語で書かれたリソースについて、コミュニティメンバーからの投稿を歓迎する旨の注記を含めてください。プロジェクトがそのような投稿を受け取った場合は、迅速に対応し、プロジェクトのドキュメントにそれらを含めるようにしてください。 + +コミュニティに紹介するあらゆるリソースと同様に、そのリソースが有用であることを確認するために最善を尽くしてください。プロジェクトの現時点で利用可能な人員時間から、リソースの有用性を検証できない場合は、プロジェクト管理者が自ら評価できていない事実を明記してください。プロジェクトのドキュメントへの掲載について、フィードバックを歓迎している旨を付記しましょう。 + +#### 英語力に関わらず親切で歓迎的な態度を + +本章で繰り返し強調してきたように、プロジェクトに参加するすべての人々との交流において、親切で礼儀正しいコミュニケーションはデフォルトの行動様式であるべきです。英語での文章作成が困難な方とのコミュニケーションにおいても同様です。相手の主張や要求が理解しにくい場合は、喜んで支援する意思を示すため、明確化のための質問を投げかけましょう。英語の文章能力が限られているという理由だけで、相手を無視したりプロジェクトへの参加を拒んだりしてはいけません。 + +{% hint style="success" %} +英語が母国語でない人々は、プロジェクトとのコミュニケーションを始める際、自身の英語力の不足について謝罪から始めることがよくあります。そのような連絡を受けた際は、書き込んでくれたことに感謝し、プロジェクトとコミュニケーションを取ろうとする努力を評価していることを伝えましょう。可能であれば、彼らがより慣れ親しんだ言語で利用できるリソース（例えば、プロジェクトのスペイン語フォーラムや中国語メーリングリストなど）を紹介してください。 +{% endhint %} + +#### 文書化では慣用句を避ける + +あらゆる言語には、文字通りの意味では意図が伝わりにくい様々な表現が存在します。例えば「over the moon」は「非常に嬉しい」「興奮している」を意味し、「raining cats and dogs」は「激しい雨」を指します。特定の文化圏で育った人々にとって、これらの表現の意味は明らかです。しかし、適切な文脈を知らない人々にとっては混乱を招く可能性があります。文書化においては慣用句に頼るのではなく、平易な言葉を使用し、すべての人が理解しやすい文章を心がけましょう。 + +#### 略語は展開し、用語集を用意する + +略語は、その分野に精通した者にとって長い表現を省略する便利な手段ですが、不慣れな者にとっては情報を不明瞭にします。さらに略語は多義的であることが多く、分野によって異なる意味に展開される場合があります。例えば、プロジェクトに全く関わったことのない人は、「LGTM」が「looks good to me（問題ないと思う）」を意味し、自分の作業がプロジェクトのソースリポジトリにマージしても良い状態であることを理解できないかもしれません。プロジェクト内のコミュニケーションで特定の頭字語を頻繁に使用する場合は、これらの用語の簡易用語集を作成する時間を割いてください。この用語集の更新は、ボランティアが貢献できる迅速かつ簡単な方法です。 + +#### ローカライゼーションボランティアの積極的な参加を促す + +本章で先に述べたように、プロジェクト管理者はコミュニティから_どのような支援_を求めているかを常に明確にすべきです。支援を求める重要な分野の一つが、ドキュメントリソースのローカライゼーションです。ソフトウェア開発の実践スキルに関わらず、コミュニティメンバーはドキュメントを翻訳することでプロジェクトを積極的に成長させ、改善できます。これにより、より多くの人々や潜在的な貢献者にとってプロジェクトが利用しやすくなります。管理者は、ローカライゼーションに特化した貢献者を募集したいという意向を明確に示すべきです。 + +### プロジェクトのコミュニケーション規範を文書化する + +人々が新しいプロジェクトに接する際、そのプロジェクトにどう関わり、コミュニティとどう交流すべきかを理解しようとします。プロジェクトの様々なコミュニケーションチャネルを、ドキュメントで明確に概説してください。 + +単にコミュニケーションチャネルを_列挙する_だけでは不十分です。ドキュメントでは、各チャネルの_目的_、特定のコミュニケーション手段を_いつ_使用すべきか、そしてそのチャネルを通じてプロジェクトやコミュニティメンバーから_どのような形で_連絡が来るかを明確に示さなければなりません。例えば、趣味のプロジェクトとして少数のメンテナが開発している場合、プロジェクトウェブサイトに「開発は余暇時間に行っているため、メーリングリストへの問い合わせへの即時対応は期待しないでください」と明記すると良いでしょう。一方、企業で利用されている趣味プロジェクトの担当者は、サポートが「最善を尽くす」ベースで提供されることを明示するとよいでしょう（これにより、オープンソースプロジェクトコミュニティの機能に不慣れな人々の期待を適切に設定できます）。 + +#### 礼儀正しい議論の維持 + +本章で繰り返し議論してきたように、親切で礼儀正しいコミュニケーションを維持することは、プロジェクトの持続的な健全性にとって極めて重要です。「親切で礼儀正しいコミュニケーション」の具体像を全員が理解していると仮定するのは自然に見えるかもしれませんが、参加者全員に共通の意味を期待することはできません。特にグローバルな対象者とのやり取りにおいてはなおさらです。プロジェクトのメンテナやコミュニティメンバーは模範を示すことが望ましいです。しかし、特に紛争を引き起こす可能性のある事項について、プロジェクトとのコミュニケーションにおいて何が礼儀正しい議論を構成するのか、プロジェクトの主題外となる事項は何か、誰に何を期待するのかを明示的に表明することは、プロジェクトに適切な基調を定めることになります。 + +[ドリームウィズプロジェクトの多様性に関する声明](https://www.dreamwidth.org/legal/diversity)より： + +> 「私たちはあらゆる性別アイデンティティや表現、人種、民族、体型、国籍、性的指向、能力レベル、神経タイプ、宗教、高齢者としての立場、家族構成、文化、サブカルチャー、政治的意見、アイデンティティ、自己認識を持つ人々を歓迎します。活動家、アーティスト、ブロガー、クラフト作家、趣味人、音楽家、写真家、読者、作家、普通の人、非凡な人、そしてその中間にある全ての人々を歓迎します。世界を変えたい人、友人と繋がり続けたい人、素晴らしい芸術を作りたい人、仕事の後の一息つきたい人、全てを歓迎します。ファン、オタク、ナード、ピクセルまみれの技術系田舎者も歓迎します。（これらの用語の意味がわからないインターネット初心者の皆さんも大歓迎です。）あなたが中学校に入る頃にはインターネットが日常語になっていたとしても、ワールドワイドウェブが発明された時にはすでに引退していたとしても、私たちはあなたを歓迎します。 +> +> .... +> +> 私たちは十分な経験から、最初から完璧にできるはずがないと知っています。しかし、今知らないことを学びたいという希望とエネルギーと理想は十分にあります。全員を満足させることはできなくとも、誰かを不快にさせることは避けられます。そして、もし間違えた時は、指摘してくださった皆様の声に真摯に耳を傾け、過ちを正すために最善を尽くすことをお約束します。」 + +このドリームウィズプロジェクトの多様性声明からの抜粋は、プロジェクトのコミュニケーション規範を文書化する優れた例です。個人の経歴、技術スキルレベル、プロジェクト利用目的に関わらず、誰もが歓迎されることが明確に示されています。間違いは起こり得ますが、その不完全さを他者を貶める言い訳ではなく、学びの機会として活用することが求められていることも明記されています。この声明は、ユーザーや貢献希望者に対し、プロジェクト管理者から常に望む結果が得られるとは限らないが、誤りは修正され、合理的な要望は実行に移されなくとも耳を傾けられることを伝えています。特に注目すべきは、単なる_禁止事項_のリストではなく、期待される_協調的行動_のリストである点です。プロジェクト管理者とコミュニティメンバーが模範とする行動を特定し、彼らの行動を言葉に変換することで、良きプロジェクト市民としての行動とは何かを全員が理解できるようにしています。 + +#### プロジェクト社会契約の策定 + +プロジェクトがコミュニティのコミュニケーション規範を文書化する際、プロジェクト社会契約の策定が特に効果的な手法となる場合があります。プロジェクト社会契約は、プロジェクトが全参加者に示すことを期待する行動を文書化し、プロジェクトメンバーが他者に対してどのように説明責任を果たすかについての期待を設定します。社会契約は必ずしも禁止行動のリストではなく、むしろプロジェクトのメンバーが全員の成功のために自らを統治する方法についての声明です。対話を通じて社会契約を作成するプロセスに取り組むことで、メンバーは互いに共感し、将来の会話の基盤を築きます。 + +リモートチーム向けの作成ヒントを含む社会契約の作成方法の詳細は、[The Open Practice Library](https://openpracticelibrary.com/practice/social-contract/)で学べます。 + +#### 行動規範 + +一部のプロジェクトでは、礼儀正しい議論に関する期待を文書化する手段として行動規範を採用しています。外部からの貢献を求めるオープンソースプロジェクトは、常に行動規範を整備すべきです。イベント（オンライン／対面）を主催するプロジェクトでは、イベントに特化した行動規範の文言を策定することもベストプラクティスです。行動規範はプロジェクトの社会契約の一側面と捉えましょう。そこにはコミュニティが自らを統治するルール、そして各メンバーが「別の行動を取ればより良い結果が得られたかもしれない」場面において互いに責任を問う方法が含まれます。これらのルールは理解され、明示されなければなりません。さもなければ、人々は自分に何が期待されているのか、またそのプロジェクトが自分の時間と専門知識を喜んで提供できる居心地の良い場所なのかどうかさえも理解できません。 + +行動規範に関する詳細は、本ガイドブックのガバナンスに関する章を参照してください。 + +### オープンソースプロジェクトとの効果的なコミュニケーション + +これまで、主にソフトウェアプロジェクトの_メンテナ_が、プロジェクト内のコミュニケーションで最善の結果を保証する方法に焦点を当ててきました。しかし、貢献者側も、お気に入りのオープンソースコミュニティと効果的にコミュニケーションを取るために、いくつかのステップを踏むことができます。以下はそのほんの一例です。 + +1. **議論に参加する前に、プロジェクトのウェブサイトとドキュメントを読みましょう。** プロジェクトについて読み、そのニュアンスを理解するために時間をかけてください。プロジェクトを制作している人々の時間と注意を尊重していることを示しましょう。 +2. **調査を行い、その旨を伝える。** オープンソースソフトウェアの使用中に問題に遭遇した場合、自ら解決できる限りの努力をしましょう。問題を解決できないことは恥ではありませんし、バグ報告の質向上にもつながります。バグ報告を提出する際やプロジェクトのコミュニケーションチャネルで支援を求める際には、問題解決のために取った手順を必ず記載してください。これにより、既に試した方法を再度尋ねられる手間を省けます。自己解決のための試行を列挙することは、プロジェクト管理者の時間と労力への敬意を示す行為です。 +3. **[基本的なネットエチケット](https://en.wikipedia.org/wiki/Etiquette_in_technology)を実践する。** インターネット上でのコミュニケーションに関する最も基本的な助言は、オープンソースプロジェクトやコミュニティにも適用されます。例えば、すべて大文字で入力することは避けましょう。このスタイルは叫んでいるように読まれ（実際に叫びながら助けを求める人はいません）、好ましくありません。ユーザー名やスクリーンネームは合理的で親しみやすいものを選びましょう。そうしないと、他者から真剣に受け止められないリスクがあります。問い合わせへの返答を待つ時間は、24～48時間程度が適切です。別の連絡手段で催促する前に、この時間を確保しましょう。インターネットコミュニケーションのルールに不慣れな場合は、Verginia Sheaのよく引用される[ネットエチケットの基本ルール](http://www.albion.com/netiquette/corerules.html)が参考になります。 +4. **質問や連絡は適切な場所で行うこと。** 予期せぬ場所で情報に遭遇すると、相手は混乱する可能性があります。例えば、プロジェクトの課題管理ツールを使って「来週ハッカソンを開催します」と告知するのは不適切です。プロジェクトが貢献者向けに質問の方法や場所を明示している場合（本リストの最初の項目に従えば把握できるはず）、必ず適切なフォーラムを利用してください。プロジェクトのメンテナや他のボランティアが求める方法で交流する時間と労力を割いている姿勢は、彼らの努力への敬意を示すものであり、結果としてあなたを支援する彼らの負担を軽減します。 +5. **投稿の件名は可能な限り意味のあるものにしましょう。** メールやフォーラム投稿の件名を書く際は、自分の要望を明確に示してください。例えば「バグを見つけたと思います」という件名は、「バージョン2.2へのアップグレード時に外部ディスプレイが認識されない」という件名よりも対応が遅れる可能性が高いです。後者の件名は、問題の診断方法に関する詳細が記載されている可能性が高いこと、そして読者の限られた時間と注意力を理解している相手とやり取りしていることを伝えます。前者の件名は送信者の問題を何ら区別せず、読者に記憶に残りにくくします。投稿の件名が有用であればあるほど、迅速な返信を得られる可能性が高まります。 +6. **あらゆるコミュニケーションにおいて親切かつ礼儀正しくあること。** 繰り返しになりますが、オープンソースソフトウェアに限らずあらゆるプロジェクトで効果的なコミュニケーションの鍵は、思いやりと礼儀正しさです。オープンソースプロジェクトに怒りを露わにして問題解決を要求したり、即答が得られないからといって無礼な追跡メッセージを送ったり、コミュニケーション相手に対して不親切な態度を取ったりしてはいけません。支援への感謝や、プロジェクトを提供してくれたことへの謝意を伝える時間を必ず取ってください。あなたがコミュニケーションを取っているのは人間であり、その中には自由な時間を割いてあなたのためのフリーソフトウェアを書いている人もいることを忘れないでください。自分が受けたいと思う敬意と礼儀をもって接しましょう。 + +### オープンソースプロジェクトと学術界におけるコミュニケーションの進化 + +オープンソースソフトウェアは今や至る所にあるように見えますが、フリーソフトウェア運動とオープンソースソフトウェア運動は依然として初期段階にあることを思い出すべきです。Linuxオペレーティングシステムの開発は1991年に始まりました。世界的に著名なオープンソースプロジェクトの多くを管理するApache Software Foundationは1999年に設立されました。インターネットの世界では20年や30年が古代史のように思えるかもしれませんが、Ada Lovelaceが世界初のアルゴリズムを1840年代に考案した事実は注目に値します。オープンソースは、はるかに長い技術の歴史の中で（重要な存在ではあるものの）まだ小さな点に過ぎないのです。 + +オープンソースがソフトウェア業界に与えた破壊的影響により、学術研究者はオープンソースソフトウェアプロジェクトとその開発手法を特に研究に値するものと見なしています。 + +しかし、プロジェクトのコミュニケーションツールやプラットフォームが進化するにつれ、研究目的でプロジェクトデータにアクセスする研究者の能力は、時に時代遅れになっています。例えば、プロジェクトのリアルタイムチャットであるIRCログを解析することで、特定のプロジェクトに関する有益な情報を得られることが多かったのですが、一部のプロジェクトが他のチャットシステムに移行したため、そのようなログはもはや一般的に利用できません（また、プロジェクトが選択するコミュニケーションツールによっては、プロジェクトのチャットアーカイブの長期保存が保証されていない）。 + +プロジェクトが立ち上げられる時や少人数のグループで活動している段階では、コミュニケーションの方法や場所の選択は、将来的な影響をほとんど考慮せずに自然発生的に行われることが多いです。しかしプロジェクトのメンテナは、伝承や意思決定の履歴といった貴重なデータや歴史的遺産の源となり得るプロジェクトのコミュニケーションが、参加者や関心を持つ観察者の双方にとって効果的に記録されるよう、慎重に検討すべきです。研究者がコミュニティ活動を評価し、プロジェクト各部の成果を分析する手法を理解するには、[Community Health Analytics in Open Source Software](https://chaoss.community/) (CHAOSS) Projectの成果を参照するとよいでしょう。 + +### 結論 + +オープンソースプロジェクトで効果的なコミュニケーションを実現する最善の方法は、他者への親切と礼儀を示し、初めて接する相手に対して善意を前提とすることです。本章には効果的なコミュニケーションのための有益なベストプラクティスが数多く含まれていますが、他者に対して礼儀正しく振る舞うことが、良好なコミュニケーションを図る上で最も重要な一歩です。あなたの文章を読んでいるのは人間であることを忘れず、自分が望むのと同じ敬意をもって相手を扱うことを心がけてください。 + +[^guides]: スタイルガイドの例については [PEP 8　—　Pythonコードのスタイルガイド](https://www.python.org/dev/peps/pep-0008/) または、複数のプログラミング言語を用いた開発プロジェクトである[Mozilla Firefoxへの貢献のためのスタイルガイド](https://firefox-source-docs.mozilla.org/code-quality/coding-style/index.html)を参照してください。 +[^not-working]: 著者らは、Kent C.DoddsとSara Drasnerによる記事[An Open Source Etiquette Guidebook](https://css-tricks.com/open-source-etiquette-guidebook/)の貢献に感謝します。 +[^fogel-oss]: [https://producingoss.com/en/producingoss-letter.pdf](https://producingoss.com/en/producingoss-letter.pdf)、64ページ。 + + diff --git a/l10n/ja/getting-started/README.md b/l10n/ja/getting-started/README.md new file mode 100644 index 00000000..44cc377d --- /dev/null +++ b/l10n/ja/getting-started/README.md @@ -0,0 +1,24 @@ +--- +description: +author: Karsten Wade +updated: 2020-12-04 +translated-by: Ken Komazawa powered by DeepL Pro +--- + +# はじめに + +オープンソースの実践者として歩む道のどの段階にあっても、基本を理解し注意を払うことは常に有益です。これらの基本には、「コミュニティでは誰もが知っている」とされる_共通認識_の類いが含まれますが、誰もそれをどのように学んだのか確信を持てず、必ずしも文書化されているわけではありません。このセクションの各章は、あらゆるレベルの実践者にとって良い出発点となります。 + +このセクションには以下の章が含まれます。 + +* オープンソースコミュニティに関する中核概念の紹介 +* オープンソースプロジェクト開始時の手順の概要 +* 本ガイドブック全体で使用する主要用語の定義 + +このセクションが役立つのは、次のような場合です。 + +* どこから始めればよいかわからない場合 +* 新しいオープンソースプロジェクトを始める手順の概要を読みたい場合 +* 強力なコミュニティを育てるためのステップを知りたい場合 +* このガイドブックやオープンソースの世界で遭遇した用語や言葉の定義や詳細な意味を探している場合 +* 最初から順を追って読み進めたい場合 \ No newline at end of file diff --git a/l10n/ja/getting-started/building-a-strategy.md b/l10n/ja/getting-started/building-a-strategy.md new file mode 100644 index 00000000..4d783fad --- /dev/null +++ b/l10n/ja/getting-started/building-a-strategy.md @@ -0,0 +1,240 @@ +--- +description: +author: Dave Neary , Bryan Behrenshausen +updated: 2025-06-27T00:00:00.000Z +translated-by: Ken Komazawa powered by DeepL Pro +--- + +# 戦略の構築 + +オープンソースプロジェクトを立ち上げたからといって、その成功が保証されるわけではありません。成功するオープンソースソフトウェアプロジェクトには、アクセス可能なコードや協力する意思以上のものが必要です。最も人気があり効果的なプロジェクトには、パートナーや貢献者のエコシステムを深く理解し、明確な目標を設定し、これらの目標を明確に念頭に置いて協力を構築するコミュニティが存在します。 +つまり、明確で効果的な戦略を持っているのです。Karl Fogelが『Producing Open Source Software（邦題：オープンソースソフトウェアの育て方）』[^fogel-producing-oss]で書いているように、 + +> フリーソフトウェアプロジェクトを立ち上げる上で最も難しいのは、私的なビジョンを公的なものに変えることです。あなたやあなたの組織が何を望んでいるかを完全に理解していても、その目標を世界に向けて包括的に表現するにはかなりの労力が必要です。しかし、そのための時間を割くことは不可欠です。 + +本章では、その作業を行うためのリソースを提供します。その過程で、プロジェクトリーダーやメンテナがオープンソースプロジェクトの戦略を策定するために議論すべき指針となる質問をいくつか提案します。これらの質問に答えることで、プロジェクトの重要な側面が明確になり、メンテナがプロジェクトを成功に導くために_何をすべきか_（そして同様に重要なのは_何をしてはいけないか_）を判断するのに役立つでしょう。 + +さらに、一部のオープンソース_プロジェクト_は最終的にオープンソース_製品_へと発展します。つまり、組織の収益創出活動において何らかの役割を担うようになるのです。この場合、その成功や失敗がビジネス上の意思決定に影響を与え（また影響を受けるため）、プロジェクトを導く戦略はさらに_複雑_になります。したがって本章では、市場での成功を目指すオープンソースコミュニティがそれを達成するための準備を整えられるよう、オープンソース_製品_戦略を策定する追加作業についても議論します。 + +## 戦略とは何か？ + +オープンソース戦略とは、目標を達成し、その達成を妨げる可能性のある障害を克服するための包括的かつ適応可能な手順です。端的に言えば、戦略とは成功するオープンソースプロジェクトを設計し、育成し、成長させるための計画です。 + +今日、「戦略」という言葉は乱用されがちで、その意味が薄れ曖昧になっているかもしれません。プロジェクトの戦略とは、技術的能力のリストや長期目標の羅列、コミュニティの成功像ではありません。それは、状況を深く分析した上で策定される、調整された行動計画なのです。戦略的思考に関する画期的な著書で、Richard P. Rumelt[^rumelt-strategy]は、効果的な戦略の3要素を次のように概説しています。 + +1. **診断**：チームやプロジェクトが直面する問題の正確な性質を説明し、その本質を首尾一貫した管理可能な形に凝縮したもの +2. **指針となる方針**：その診断に対処するアプローチを（大まかに）記述するもの +3. **一貫した行動群**：指針となる方針を実行し成果に結びつけるために、チームが協調して遂行すべき一連の行動 + +Rumeltはこれらを優れた戦略の「中核」と呼んでいます。なぜなら、これらは成功へのあらゆるレシピに不可欠な要素だからです。オープンソースプロジェクトにおける優れた戦略の核を特定する作業は、困難で時間がかかり、メンテナ、貢献者、その他のプロジェクト関係者間で議論が絶えません。しかし、持続可能なプロジェクトを構築するには、この作業が絶対に不可欠です。したがって、オープンソース戦略の策定に関する助言を、Rumeltの三要素構造に沿って整理します。 + +## オープンソース戦略の構築 + +オープンソースプロジェクトの戦略構築には、オープンソースコンサルタントの Emily Omierが「ポジショニング[^positioning]」と呼ぶ作業が含まれます。Omierによれば、オープンソースプロジェクトのポジショニングとは「人々がプロジェクトに対して抱く前提を制御し、潜在的なユーザーの層を可能な限り絞り込むこと」（5ページ）です。オープンソースプロジェクトの戦略を構築する際には、（ますます複雑化する）エコシステムにおいて、他のオープンソースプロジェクトとの間で、対抗して、あるいは並行して、プロジェクトを_位置づける_必要があります。また、様々な対象層を把握し、プロジェクトを_利用する_可能性のある（あるいは可能性のない）様々なグループを見つけ出す必要があります。したがって戦略構築には、自技術の能力だけでなく、より広範なオープンソースプロジェクト・製品・コミュニティのネットワークにおける（現在または潜在的な）関係性の把握が不可欠です。 + +以下では、プロジェクト管理者が戦略決定時に問うべき核心的な質問を含む、こうした状況把握のためのリソースを提示します。 + +### 問題の特定 + +オープンソース戦略策定の初期段階では、問題の特定が求められます。より正確には、_課題_の特定と言えるでしょう。ソフトウェアを利用する人々（開発者も一般ユーザーも）は、克服すべき課題に直面することがよくあります。理想的には、あなたのオープンソースプロジェクトがそれを支援します。しかしプロジェクトとコミュニティ自体も、_認知され、採用され、受け入れられる_ための課題に直面するのです。したがって、プロジェクトに関連する問題を考察する際には、次の2つの観点で考える必要があります。 + +1. **プロジェクトが解決する問題** これは、あなたとコミュニティがユーザーのためにプロジェクトを設計する際に解決を目指す問題です。多くの場合、技術的な問題です。 +2. **採用されるための課題** これは例えば、ユーザーに認知されること、あるいはユーザーに採用され受け入れられることといった課題です。多くの場合、社会的（場合によっては経済的）な課題となります。 + +効果的なオープンソース戦略を構築するには、_両方の_タイプの課題を明確にする必要があります。プロジェクトが_解決する_問題と_直面する_問題を解明するには、Rumeltが「診断」と呼ぶものを構築する必要があります。優れた診断とは、Rumeltが述べるように「状況を命名または分類し、事実をパターンに結びつけ、特定の課題にはより注意を払い、他の課題には注意を払わないよう示唆するもの」です（79ページ）。あるいは別の言い方をすれば、それは単一の問いへの答えです。「ここで何が起きているのか？」 + +プロジェクトを_生み出す_状況的要因は何か？そもそもなぜ必要なのか？そして、オープンソースエコシステムの一部において、そのプロジェクトが支持層を獲得したり勢いを得たりすることを妨げる可能性のある要因や要素は何か？ + +これらの質問に答えることは、成功するオープンソース戦略を立案する上で極めて重要です。しかし、直接的に答えるのは難しいです。したがって、まずはより直接的で把握しやすい質問に答えることを提案します。 + +- プロジェクトとは何か？ +- プロジェクトのユーザーは誰か？ +- 既存の代替案は何か？ + +#### プロジェクトとは何か？ + +一見単純に見えるこの質問ですが、その答えは往々にして単純ではありません。 +オープンソースプロジェクトは、多くの潜在ユーザーにとって馴染みのない用語で自己説明したり、解決できる_問題_ではなく、_手法_に焦点を当てたりしがちです。この質問への回答を考える際は、_プロジェクトがユーザーをどのように支援するか_に焦点を当ててください。以下のような質問を自問しましょう。 + +* このプロジェクトはどのような問題を解決するのか？ +* プロジェクトの潜在的なユーザーに、可能な限り簡潔にプロジェクトを説明するとどうなるのか？ + +例えば、[Istio](https://istio.io/) 開発者に「Istioとは何か」と尋ねるとします。最も基本的な答えは「サービスメッシュです」でしょう。しかし、コンテナアプリケーション開発者の多くは「サービスメッシュ」の概念を完全に理解していないと反論されるかもしれません。つまり「サービスメッシュです！」という簡潔な説明では、初心者がその使用方法や有用性を理解する助けにはなりません。より良い説明としては、例えばネットワークの知識がある相手にはアプリケーションのデータプレーンとコントロールプレーンという観点からIstio[^istio]を説明したり、あるいはサービスメッシュの概念を全く知らない相手には、アプリケーションのコンポーネントに割り当てられた交通警察官のような概念として説明したりする方法が考えられます。 + +プロジェクトが_何ができるか_——つまり_機能の仕組み_だけでなく、採用・利用するユーザーにとって_どのような違いをもたらすか_——をシンプルかつ直感的に理解できるよう、コミュニティが必要とする限りフォローアップ質問を投げかけましょう。 + +#### プロジェクトのユーザーは誰か？ + +多くのオープンソースプロジェクトは、自プロジェクトのユーザー層や、ユーザーがツールをどのように活用しているかを明確に理解していません。「ペルソナ」という概念を用いて主要ユーザーの典型的なグループを特徴づけ、「達成すべき仕事」という観点で考えることを検討してください。 + +例えば、プロジェクトの潜在的または現在のユーザーを以下の基準で分類できます。 + +* プロジェクトは個人向けか、組織向けか？ +* 特定の業界分野やビジネス領域で特に有用か？ +* どの規模の組織が最も有用と感じるか？大企業のシステム管理者か、中小企業の領域をターゲットにしているか？ +* プロジェクトをダウンロード・インストール・使用する人々の役職は何か？同じ人々か？それともユーザーとプロジェクト管理者は異なるか？ + +これらの質問への回答は、コミュニティがプロジェクトの構造化やプロモーションに設定する優先順位、さらには特定の機能に投入するエンジニアリングリソースの規模に影響を与えます。例えば、プロジェクトがデータセンターやサーバークラスター上で動作する場合、対象ユーザーは通常ビジネスユーザー（ITを専門的に運用する人々、または大学でのボランティアとして運用する人々）となります。モバイルアプリケーションやWeb開発フレームワークの場合、ユーザーの大半は個人用PC、ワークステーション、または携帯電話でプロジェクトを実行します。これらのグループはそれぞれ異なるリソース要件を持ち、プロジェクトとそのツールを利用する動機となる課題も異なります。誤ったユーザー層を対象とすると、プロジェクトの普及に課題が生じる可能性があります。 + +さらに、オープンソース_製品_戦略の構築に関心がある者は、プロジェクト_ユーザー_と製品_購入者_の間の重要な関係についても追加で考えるべきです。したがって、戦略に商業的目標が含まれる場合、次のような問いを立てることも有益でしょう。 + +* オープンソースプロジェクトをダウンロード・インストールする人々と、商用製品を評価・購入する人々との関係は何か？ + +企業がオープンソースを採用する道筋は、通常、上流のオープンソースプロジェクトの利用からエンタープライズ向けオープンソース製品への移行という直線的な経路をたどりません。オープンソースの採用は「草の根的」でボトムアップである傾向がある一方、エンタープライズ向けオープンソース製品はトップダウンで評価・購入されることが多いからです。社内でオープンソースプロジェクトを採用する人々は、購買決定の相談役として貴重な影響力を持つ可能性があります——購買プロセスに関与している場合、あるいは購買責任者が自社が既にその製品を使用していることを認識している場合です。 + +#### あなたのプロジェクトに既に存在する代替案は？ + +競合相手（あるいはプロジェクト未公開の場合は、競合すると_予測される_相手）を評価することで、プロジェクトについて多くの知見が得られます。多くの場合、これは分析の_前の_ステップで特定した人々が、_最初の_ステップで特定した同じ（または類似の）タスクを達成するために使用している他のプロジェクトに注目することを意味します。以下のような質問を検討してください。 + +* あなたのプロジェクトに競合が存在しない場合、その理由は何か？ +* このプロジェクトは新興技術の分野で役割を果たしているか？ +* 類似プロジェクトは、あなたのプロジェクトで達成可能な作業を、単に異なる方法で実行するために利用されているか？ +* 他のプロジェクトが同じ機能を提供する場合、問題へのアプローチ方法はどのように異なるか？ +* 競合プロジェクトを利用する人々の動機は何か？ +* オープンソースの競合が存在する場合、それらに参加する（競合するのではなく）選択肢はあるか？ない場合、その理由は？ + +競合分析は、プロジェクトが活動し役割を果たす状況を診断する手助けとなります。戦略策定プロセスの初期段階でこれらの重要質問に回答しておくことは、コミュニティが機能の優先順位付けや潜在ユーザーへの接触方法（後述する一貫性のある行動計画策定時に詳述）を決定する際に有益です。例えば、競合他社の技術に関心を持つ人々の既存の集まりに便乗し、そこでメッセージを広めることができるかもしれません。 + +オープンソース製品の開発を戦略に含める場合、市場競争や顧客に関する以下の質問も検討すべきです。 + +* 競合他社が市場で既存勢力である場合、彼らとその顧客について何が言えるか？ +* 競合他社の顧客は誰か？彼らに共通する特徴は何か？ + +ここで得られる回答は、コミュニティ設計や市場投入戦略に直接影響します。例えば既存市場に参入する新興企業の場合、目標やメッセージは競合他社を軸に構築されるでしょう。「より安価な」「オープンソース代替品としての」「よりシンプルで高速な」といった表現が有効です。新規市場で「市場獲得競争」を展開し、迅速にシェアを拡大する場合、メッセージの拡散に注力する必要があります。これはマーケティング予算の増額や積極的なコミュニティ計画、潜在ユーザーが抱える課題の明確化が求められることを意味します。 + +覚えておいていただきたいのは、_あらゆる_ソフトウェアは、誰かが直面している問題に対する解決策だということです。_あなたの_プロジェクトが形作られる状況を診断する際、最優先すべきは次の点を理解することです。_そのソフトウェアが何であるか_、_どの_問題を解決するのか（そして_誰のために_）、_どのように_広範なオープンソースエコシステム内の他のプロジェクトと関連しているのか、そして_なぜ_ユーザーが他のソリューションではなくあなたの解決策を選ぶのか。 + +### アプローチの骨組み + +プロジェクトが解決すべき問題と、普及過程で直面するであろう課題を診断すれば、プロジェクトの独自性、対象ユーザー層、そのグループにとっての潜在的価値が明確になります。同時に、プロジェクトとコミュニティを構築・成長させる上で乗り越えるべき障壁も認識できるでしょう。 + +次に直面する課題は、ユーザーにソリューションを届け、彼らのニーズや懸念に対応するための全体的なアプローチを確立することです。ソフトウェアをオープンソース化することは、あなたとコミュニティにとって重要な道筋と機会を開きます。ただし、それら全てではなく、_一つの_道筋を共同で選択して進む方が、はるかに成功する可能性が高まります。 + +オープンソースプロジェクトに適切な戦略的アプローチを構築することは、Rumeltが_指針となる方針（guiding policy）_と呼ぶものを明確にすることに近いです。効果的な指針となる方針は、Rumeltが記すように「具体的に何をすべきかを定義せずに、行動を特定の方向へ導く」（84ページ）ものです。この場合、明確な指針はコミュニティの活動を集中させます。具体的には、_行うべき_ことと_行うべきでない_ことを判断する手助けとなります（詳細は次節の協調行動で詳述）。効果的な指針は、優位性の源泉を_創出_するか_活用_します。彼は「戦略の本質は往々にして優位性にある」と記しています。てこが機械的優位性で力を増幅するように、戦略的優位性は資源や行動の効果を増幅する」（85ページ）。ソフトウェアをオープンソース化するという選択は、コミュニティ（ユーザーを含む）にとって多くの潜在的な戦略的優位性の源泉を解き放ちます。しかし、_どの_優位性を活用したいのかを正確に決定する必要があります。本節で提示する質問は、その判断に役立つはずです。具体的には、 + +- このプロジェクトの目標は何か？ +- 関連プロジェクトとどう連携するか？ + +#### このプロジェクトの目標は何か？ + +自らの発明をオープンソースソフトウェアライセンスで公開する決断は、軽率なものであってはなりません。戦略的な意図を持って下されるべきです。_なぜ_、を自問しなければなりません。_ソフトウェアをオープンソース化する理由は何なのか？_ + +驚くべきことに、多くのプロジェクトがこの質問に答えるのに苦労しています。彼らはソフトウェアをオープンソース化したいと既に決めていますが、_なぜ_そうするのかについて十分な考察を欠いています。こうしたプロジェクトにとって「オープンソース」は目的そのもののように見えます。しかし実際には、ソフトウェアをオープンソース化する決定は常に、_他の_何らかの目標に奉仕するものでなければならない——それは複数の潜在的な目的を達成するための特定の手段です。適切かつ効果的なオープンソースプロジェクト戦略は、これらの目的を明確かつ明示的に示さねばなりません。 + +したがって、オープンソースプロジェクトの作成と維持に取り組む前に、プロジェクトをオープンソース化することが、あなた自身、コミュニティ、または組織が特定の目標を達成するのにどのように役立つのか、_なぜ_かを理解してください。例えば、 + +* あなたの仕事に対する**新たな視点**を求めていますか？プロジェクトをオープンソース化することで、他者があなたの仕事を評価し、フィードバックを提供し、ソフトウェア開発者としての成長に役立つ形で貢献できるようになります。 +* **開発負担の軽減**を望んでいますか？プロジェクトをオープンソース化すれば、人気が高まるにつれ、他者が開発・維持管理の重要な役割を担うようになります。 +* **プロジェクトのセキュリティ強化**を図っていますか？ソフトウェアをオープンソース化すれば、自身が気づかなかった問題や脆弱性を他者が発見する助けとなります。 + +こうした問いに答えるには内省が必要かもしれません。しかし、そうすることであなた自身と（既存または形成途上の）コミュニティが、プロジェクトの設計・計画・構築・維持管理の方法を決定する助けとなります。 + +プロジェクトをオープンソース化する理由については、商業的文脈においてさらに重要な問いとなります。オープンソース製品戦略を確立する際、目標はソフトウェアのオープンソース化によって得られる利益を具体的なビジネス目標と結びつけることです。確かに「オープンソース」はビジネスモデルではありません。これは特定の機会を解き放つためのライセンス決定です。例えば、ユーザーとより協働的にソフトウェアを開発する機会や、導入コストを下げることによってプロジェクトの潜在的なリーチを拡大する機会などです。これらの機会は、組織全体のビジネス目標に関連している場合にのみ価値を持ちます。 + +オープンソースアプローチを魅力的にするビジネス上の根拠を理解するには、以下の経済原則を考慮してください。 + +**商品の価格を下げれば、その需要は増加する。** + +オープンソースの場合、導入コストを下げることによって需要が最大化され、結果としてプロジェクトの採用が進みます。ここで言う採用コストは金銭的なものだけでなく、現在使用しているソリューションからの移行に必要な時間と労力も含みます。 + +**ある商品の価格が下がると、その代替品の需要も低下する。** + +オープンソースプロジェクトは、低コストで導入しやすいという利点により、既存のプロプライエタリソフトウェア企業を脅かす可能性があります。この原理は、オープンソースが市場破壊の要因となり得る理由を説明しています。破壊的変化は、代替手段の採用を活用し、新たな市場を成長させる機会です。 + +**他の条件が同じであれば、ある商品の価格が下がると、その補完財への需要が増加する。** + +成功した商用オープンソース戦略はすべて、この原理に基づいています。収益が目的なら、オープンソースとして公開するソフトウェアの補完財を特定する必要があります。それらの補完財は顧客に付加価値を提供すべきです。 + +では、あなたの目的は次のどれでしょうか？ + +* 市場を拡大すること？ +* 競合他社を破壊すること？ +* 標準を推進すること？ +* 自社ポートフォリオ内の他製品の需要を高めること？ + +ソフトウェアプロジェクトをオープンソース化することは、これらの目標達成に役立つ可能性があります。しかし、これらの目標それぞれが、プロジェクトとコミュニティのアーキテクチャに対して異なるアプローチを要求します。Mozillaは、最も一般的なそのようなアーキテクチャ——同社が「[オープンソース・アーキタイプ](https://blog.mozilla.org/wp-content/uploads/2018/05/MZOTS_OS_Archetypes_report_ext_scr.pdf)」と呼ぶもの——をカタログ化しています。——プロジェクトのオープンソース化における組織の目標が、プロジェクトの形成方法と、コミュニティがその成功を支援するために取り組むべき活動の種類にどのように影響するかをより明確に示すために。 + +プロジェクトをオープンソース化する理由を理解することは、あなた自身、あなたの組織、そしてあなたのコミュニティが、目標達成に必要な投資のレベルと種類を明確にするのに役立ちます。言い換えれば、それらは戦略的行動を導く全体的な方針にとって極めて重要となるでしょう。 + +#### 隣接プロジェクトとそのコミュニティとどう連携するか？ + +ユーザーコミュニティを調査する中で、ユーザーがあなたのプロジェクトを別の異なるプロジェクトと併用していることに気づいたかもしれません。あるいは、あなたのプロジェクトが、課題解決のために既に異なるアプローチを採用しているユーザーにも魅力的である可能性に気づいたかもしれません。いずれの場合も、プロジェクト初期段階での認知拡大とユーザーニーズの理解を深める機会と捉えましょう。 + +ここでの目的は、特定のオープンソースプロジェクトエコシステムにおいて、自プロジェクトに「隣接」するプロジェクトを研究することです。例えば、[Ceph](https://ceph.io/en/community/)は[OpenStack](https://www.openstack.org/)や[Kubernetes](https://kubernetes.io/)のストレージ管理が可能です。したがってCephにとって、OpenStackとKubernetesは隣接コミュニティとなります。 + +隣接プロジェクトに対応してユーザー層を開拓することは、技術ロードマップ、ターゲットとするイベント、特定統合プロジェクトへの取り組みなど、様々な影響を及ぼす可能性があります。隣接プロジェクトは、あなたの技術が解決する同じ課題を抱える潜在的に友好的なユーザー層を提供します。これにより、共同市場調査やUXテストの実施、潜在ユーザーとの接触・関与を目的とした共同イベントの調整が可能になります。これは競合理解とも関連しており、競合にとって重要なコミュニティはあなたにとっても重要となるでしょう。これらのコミュニティ、そのニーズ、そしてダイナミクスを理解することは、より大きなエコシステムの中で自プロジェクトの居場所を創出しようとする際に、足場を見つける助けとなります。オープンソース戦略にはこうした機会の分析を含めるべきであり、それらを活用することは、行動を導く総合的な方針の一部であるべきです。 + +### 行動の決定 + +ここまでで、特定のユーザー層に向けたプロジェクトが解決すべき具体的な課題を特定し、プロジェクトと投資家双方の成功に向けた全体的なアプローチを概説しました。次に、全体戦略を実現するために、あなたとコミュニティが実際に_行うべきこと_（そして_行わないべきこと_）を決定する必要があります。Rumeltの用語で言えば、成功を実現するために実行可能な一連の「一貫性のある行動」を特定する必要があります。 + +これらの行動を特定することは極めて重要です。なぜなら、それによってコミュニティの日常的な戦術的作業が研ぎ澄まされるからです。つまり、全員が最も重要なことに集中できるようになるのです。オープンソースプロジェクトのメンテナは、プロジェクトに貢献するユーザーと即座に持続的な接触を持つ余裕があまりありません。代わりに、プロジェクトへの貢献は通常、創設者たちが共有するほどの豊富な文脈を持っていない見知らぬ人々から、自発的に寄せられます。プロジェクトメンテナが望める最善策は、自律的に行動するボランティアがプロジェクトの全体目標を推進する形で行動できるよう支援する足場を構築することです。 + +そこで本節では、オープンソース戦略を策定する際に以下の行動指向の質問を投げかけることを提案します。 + +- ユーザーとどう関わるか？ +- 主要なステークホルダーは誰か？ + +#### ユーザーとどう関わるか？ + +プロジェクトに人が集まり始めたら、_彼らを巻き込むこと_がユーザー基盤とコミュニティを成長させる鍵となります。ユーザーとの関わり方には複数の方法があり、それぞれ異なる労力と結果をもたらします。しかし、特にプロジェクト管理者が最も貴重な資源である時間を考慮すると、どこに注力すべきかを判断するのは困難です。ユーザーと個人的に関わろうとすれば、かなりの時間を要します。 + +したがって、戦略的アプローチが成熟するにつれ、現在のプロジェクトユーザーとの関わり方をすべて見直し、盲点や改善の機会を特定することが有用です。関与手法を「ロータッチ」「ミディアムタッチ」「ハイタッチ」（営業組織から借用した用語）で分類することを検討してください。**ロータッチ**手法は潜在ユーザーとコミュニティリーダー間の相互作用が比較的少なく、**ハイタッチ**手法は1対1または少人数対象の取り組みです。前者は構築と運用開始に多大な時間を要する傾向がありますが、一度設定すれば人的介入が少なくて済みます。後者は「初期段階」での時間・労力の投資は少ないですが、実行時には人的リソースに大きな負担がかかります。以下に分類例を示します。 + +* **ロータッチ**：ウェブサイト、ドキュメント、オンライントレーニング、ニュースレター、ポッドキャスト、ブログ +* **ミディアムタッチ**: メーリングリスト、バグトラッカー、コミュニティフォーラム、カンファレンス発表、ウェビナー、ユーザーグループ +* **ハイタッチ**: 電話対応、1対1または少人数トレーニング、カンファレンスでの対話、コミュニティミーティング + +このモデルは、エンゲージメント活動やプロジェクト目標を検討するコミュニティにとって有用です。例えば、 + +* ロータッチ活動は、プロジェクトの認知度向上や新規ユーザーの初回接触に適しています。ウェブサイトや資料が「プロジェクトの目的」「ユーザーへの利点」「貢献者が簡単に試せる方法」を明確に伝えることが最優先です。同様に、ウェブサイト・ドキュメント・プロモーション資料の整備は、上級メンバーの支援をあまり必要とせず、新規ユーザーが自律的に行動できる基盤となります。 +* 中程度の関与を必要とするミディアムタッチ活動は、プロジェクトの「重心の形成」に最適です。ユーザーとのコミュニケーションを可能にするだけでなく、ユーザー同士が助け合う環境（ネットワーク効果の創出が期待されます）を構築します。バグトラッカー、メーリングリスト、フォーラムは、コミュニティメンバーが交流し、質問し、フィードバックを提供する場となります。この種の活動は、プロジェクトの利用実態をより深く理解する機会を提供します。 +* ハイタッチ活動は、主要なコミュニティユーザーとの関係構築、コミュニティ事例の収集、大規模グループがプロジェクトを活用し推進者となる支援に効果的です。トレーニング、カンファレンス出展とフォローアップ、対面会話といった高負荷活動は一対一では極めて価値がありますが、拡張性に乏しい手法です。 + +理想的には、プロジェクトはこれらを健全に組み合わせるべきです。潜在的な関与経路[^contributor-pathways]を設計するグループにとって重要な考慮点は、_プロジェクトに不慣れな人がどのように利用を開始するか_、そして時間をかけてプロジェクト内で経験を積み、最終的に中核的な貢献者となるまでのプロセスです。 + +#### 主要なステークホルダーは誰か？ + +プロジェクト成功に最も重要な行動を特定したら、それらの行動を実行できる適切な_人材_と_ツール_を確保する必要があります。これらの人々を「ステークホルダー」と呼びましょう。彼らはプロジェクトを最も気にかけ、自らの（間違いなく多大な）才能をプロジェクトに注ぐ準備ができている人々です。 + +オープンソースプロジェクトには、プロジェクトを監督しリソースを管理するメンテナ、コードやその他の素材（ドキュメント、技術記事、ソーシャルメディア発表など）を提供する開発者、プロジェクトへのフィードバックを提供し発見した問題を報告するユーザーなど、多数のステークホルダーが関わります。当然ながら、成功するプロジェクトにはこれら全てが必要です。さらに、特定した行動を遂行するために必要なスキルを持つメンバーが、これらのグループに含まれていることを確認しなければなりません。例えば、プロジェクトが新たな技術標準の推進を目的とし、ターゲット市場向けの開発者ライブラリ提供に注力する方針で、特定の技術標準に基づく詳細なドキュメント作成が伴う場合、経験豊富な[ドキュメンタリスト](https://www.writethedocs.org/documentarians/)がコミュニティに在籍していることを確認すべきです（そうでない場合は、こうした人材をプロジェクトに招致するための十分な時間と労力を確保する必要があります）。 + +ベンダー支援型の商用目的オープンソースプロジェクトの場合、ステークホルダーには通常、組織内部の人員（エンジニアリングリーダー、プロダクトマネジメント、プロダクトマーケティング、現場担当者（フィールドエンジニア、営業））も含まれます。コンテンツサービスやサポート組織の担当者、製品セキュリティ担当者もこのグループに加えることを検討してください。ステークホルダーレビューの準備のためにブリーフィングを行う対象となるのはこのグループであり、6～12か月ごとに集めてプロジェクトの進捗を確認し、目標と目標達成に必要な投資について合意を保つ必要があります。組織内のステークホルダーと協業する際の注意点としては、 + +* 初期段階で関与者を過剰に増やすこととのバランスを取りつつ、多様なメンバーからの初期段階での賛同を確保する。 +* ステークホルダーを拡大する同心円モデルで組織化する。草案を早期かつ頻繁に共有し、懸念事項や制約を把握するために追加グループと連携する中核チームを特定する。これらのステークホルダーを早期に巻き込むことで、致命的な問題を早期に発見・対処できる。 +* すべてのステークホルダーが、あなたの取り組みが対処する課題と、組織にとって有益な形でその課題解決に寄与する全体的なアプローチについて共通認識を持つようにする。要するに、ステークホルダーがプロジェクト戦略と自身の役割を理解していることを確認すること。 + +### 戦略の記録 + +オープンソースプロジェクトの戦略を策定することと同様に重要なのは、_その戦略を文書化し_、現在および将来のユーザー、開発者、メンテナが閲覧できる場所に公開することです。結局のところ、最も優れた戦略でさえ、誰も目にせず、理解せず、従わなければ無意味です。コミュニティの全員がプロジェクトの戦略を認識し、自身の活動がそれをどう推進するかを理解すべきです。 + +幸い、本章で提供するフレームワークに従って戦略を草案化した場合、既に他者が自らを戦略の一部と認識できるよう、戦略を明確化しているはずです。具体的には以下が揃っているでしょう。 +- プロジェクトの概要と、ユーザーが抱える問題を解決する方法を簡潔（かつ正確）に記述したもの +- 他プロジェクトにはない独自の解決手法の説明 +- オープンソースアプローチが有益である明確な根拠 +- プロジェクトに貢献するユーザー・開発者・メンテナの像 +- 認知度向上と参加障壁低減のための活動リスト + +これらの資料をプロジェクトのドキュメントの一部として公開し、他者が戦略を理解し貢献を開始できるようにしましょう。そしてそこで止まらないこと。戦略の明確化は始まりであって終わりではありません。 + +* **プロジェクト目標への進捗を継続的に監視・共有する。** 共同開発者の多様性を育むことがコミュニティ目標なら、新規参加者の貢献を称え、月次ニュースレターに成長数値を掲載しましょう。 +* **成功を可能にするリソース配分を実行する。** 業界全体をプロプライエタリな競合からオープンソースプロジェクトへ移行させるのが目標でありながら、オープンソースプロジェクトの推進に専任者が1名しかいない場合、成功の可能性は低いでしょう。 +* **戦略を生き続ける文書として維持する。** 主要な関係者と共に定期的に見直し、オープンソース戦略が常に新鮮で関連性を保つようにします。 +さらに、商用組織においてオープンソース製品戦略を策定・伝達する場合、以下の要素を含む文書の作成をお勧めします。 +* **エレベーターピッチ**、すなわちオープンソースプロジェクトの目標に関する概要説明と、プロジェクトがスポンサー企業にもたらす利益の簡潔な説明。プロジェクトごとに目標は異なるため、全く同一の製品戦略は存在しません。 +* **ビジネス上の根拠**：コミュニティプロジェクトの成功が、企業または製品チームにとっての成功にどう結びつくかを説明します。例：「本プロジェクトの広範な採用により、当社の他製品からの利益獲得が促進される」「標準規格のオープンソース参照実装は、複数企業による規格採用を促進し、規格を基盤とする他社のネットワーク効果を生み出す」 +* **高水準な実行計画**、すなわち成功判定に重要な主要業績評価指標（KPI）を含む、計画された行動のリスト。プロジェクト目標からこれらのKPIを導出します。例えば、事実上の標準実装と広範な採用が目標なら、標準準拠実装を配布するベンダー数を測定対象とします。市場啓蒙が目標なら、入門資料・学習パス・チュートリアル・雑誌記事の成果が成功指標となります。 + +組織全体がプロジェクトの目標と、組織の商業的野心との関連性を理解すれば、予算やリソース配分に関する合意形成ははるかに容易になるはずです。 + +## 結論 + +本章では、オープンソースプロジェクトにおける戦略策定の重要性について説明しました。効果的なオープンソース戦略の構成要素を概説し、各自のオープンソースプロジェクト向け戦略を練るためにコミュニティと共に検討すべき質問を提示しました。戦略策定セッションを経て、チームやコミュニティはプロジェクトが解決する課題（および対象ユーザー）について共通認識を持つはずです。潜在ユーザーが理解できる言葉でプロジェクトの価値を伝えられるようになります。プロジェクトが広範なオープンソースエコシステムにどう位置づけられるか、そこで何を達成したいかを理解できるでしょう。そして成功に必要な行動を取れるステークホルダーを特定できるはずです。本章ではさらに、効果的なオープンソース_製品_戦略が以下の点を明確化する方法についても説明しました。ターゲットとする市場、技術のオープンソース化によるビジネス上の優位性の確立、プロジェクトが自社の全体的なビジネス戦略および製品ポートフォリオにおいて果たす役割の詳細化、そして成功を測るために適切な成果を測定していることの保証、です。 + +[^rumelt-strategy]: Rumelt, R.P. (2011). Good strategy/bad strategy: The difference and why it matters. New York: Currency. +[^positioning]: Omier, E. (n.d.) Positioning free open source software: How maintainers of open source projects can use positioning strategically to accelerate theirproject’s growth, build a dedicated community, and build exceptional software. Available online at . +[^fogel-producing-oss]: [https://producingoss.com/en/producingoss-letter.pdf](https://producingoss.com/en/producingoss-letter.pdf), 13ページ。 +[^istio]: ちなみに、本書執筆時点においてIstioは自らを次のように説明している：「IstioはKubernetesを拡張し、プログラム可能なアプリケーション認識ネットワークを確立する。Kubernetesと従来型ワークロードの両方と連携し、複雑なデプロイメントに標準的で普遍的なトラフィック管理、テレメトリ、セキュリティをもたらす。」 +[^open-source-archetypes]: Mozilla. (2018). Open source archetypes: A framework for purposeful open source. Available at: https://blog.mozilla.org/wp-content/uploads/2018/05/MZOTS_OS_Archetypes_report_ext_scr.pdf +[^contributor-pathways]: 詳細は「[オンボーディング体験の構築](growing-contributors/constructing-an-onboarding-experience.md)」の「貢献者の道筋」セクションを参照。 diff --git a/l10n/ja/getting-started/community-101.md b/l10n/ja/getting-started/community-101.md new file mode 100644 index 00000000..a77b3c9e --- /dev/null +++ b/l10n/ja/getting-started/community-101.md @@ -0,0 +1,69 @@ +--- +description: +author: Bryan Behrenshausen +updated: 2020-12-16T00:00:00.000Z +translated-by: Ken Komazawa powered by DeepL Pro +--- + +# コミュニティ１０１ + +この章のタイトル_コミュニティ101_は、大学における科目番号付けの慣習に由来します。「101コース」とは、特定の分野を学ぶ学習者が最初に触れる基礎教材を指します。 + +初めてオープンソースコミュニティの形成や参加を検討している方にとって、いくつかの概念は新鮮に映るかもしれません。本章ではオープンソースコミュニティの根本的な側面に関する核心的な疑問に答え、個人や組織がコミュニティに関わる理由を解説します。 + +## コミュニティとは何か？ + +コミュニティとは、共通のアイデンティティと集合的な目的によって結ばれた人々の集団であり、時間をかけて共に活動します。コミュニティは、他と区別する独自の価値観、原則、規範を育み、メンバーに帰属意識を提供します。 + +## オープンソースソフトウェアコミュニティとは何か？ + +オープンソースソフトウェアコミュニティとは、特定のオープンソースソフトウェアの開発、保守、拡張、普及という共通の目的によって結ばれた人々の集団です。これらのコミュニティはしばしば世界中に分散しており、メンバーは異なる地理的地域に居住し、数多くの産業にまたがって活動しています。彼らを結びつけるのは、オープンソースソフトウェアプロジェクトに対する共通のビジョン、そしてコミュニティへの参加がもたらす仲間意識と集団的アイデンティティの精神です。 + +## アップストリームコミュニティとは何か？ + +オープンソースソフトウェアのコミュニティ主導のエコシステムは広大で可視化が難しいため、多くの開発者は比喩を用いて説明し、水路や支流の言語を好みます。他のソフトウェアの基盤となるソフトウェアは、そのソフトウェアから「上流（訳註：アップストリームともいう）」に位置すると表現されます。「上流」ソフトウェアに変更が加えられると、その変更は依存するオープンソースプロジェクトへと「下流（訳註：ダウンストリームともいう）」に流れ下ります。「下流」で働くプログラマーが他者に利益をもたらす可能性のある革新を生み出した場合、それらの変更を親プロジェクトである「上流」に提出できます。これにより、同じ上流プロジェクトを利用する全ての人々に改善が波及していくのです。 +例えばRed Hat Enterprise Linuxは、FedoraやCentOS Streamなど、それを構成する多くのオープンソースソフトウェアプロジェクトから「下流」に位置します。これらのプロジェクトはさらに、LinuxカーネルやGNOMEデスクトップ環境など、数百に及ぶ追加の「上流」プロジェクトに依存しています。 + +## オープンソースソフトウェアコミュニティはどのように形成されるのか？ + +オープンソースソフトウェアコミュニティは、人々が協力してソフトウェアを構築・改善することに合意した時に形成されます。これを実現するには、ソフトウェアを開発する個人またはグループが、そのソフトウェアを他者に利用可能にしなければなりません。具体的には、ソフトウェアのソースコードを公開し、他者がそれを複製、修正、再配布することを明示的に許可することです（通常は特定のオープンソースライセンスの条件下で）。 +オープンソースコミュニティは世界中に分散しているため、電子メーリングリスト、Discourseのようなフォーラム、GitHubのようなコード共有プラットフォームを共有して利用することで、オンライン上で形成されるのが一般的です。 + +## オープンソースコミュニティへの参加方法 + +ほとんどのオープンソースソフトウェアコミュニティには、正式な会員申請や承認プロセスは存在しません。より一般的なのは、何らかの形でプロジェクトに貢献することで参加することです。例えば、ソフトウェアコードのバグ修正、アプリケーションの新機能開発、ドキュメントの作成・編集、ロゴやグラフィックの作成、ソフトウェアの普及促進、カンファレンスやイベントでのプロジェクト代表、ソフトウェアに関する質問を持つ他者の支援などが挙げられます。 +要するに、オープンソースソフトウェアコミュニティにおけるメンバーシップは、そのコミュニティへの貢献と、その貢献によって築かれた良好な評判によって獲得されるのです。 + +## なぜ人々はオープンソースソフトウェアコミュニティに参加するのか？ + +人々がオープンソースソフトウェアコミュニティに参加する理由は様々です。 + +多くの人は、ソフトウェア開発が職務の一部であるため参加します。所属組織が開発を委託している場合もあれば、自身の業務がソフトウェアの正常な動作に依存している場合もあります。コミュニティに参加することで、自身（または所属組織）が重要な業務で依存するソフトウェアの開発に直接影響を与えられるからです。また、コミュニティでは他者と協働し学び合うことでスキルを磨く機会が得られるため参加する人もいます。経験している問題を共同で解決できるから参加するケースもあります。また、誰もが恩恵を受ける共通リソースへの貢献が重要だと信じるから参加する人もいます。さらに、交流や帰属意識・アイデンティティを得る目的で参加するケースもあります。 + +## 組織がオープンソースソフトウェアコミュニティに関わる理由 + +世界で最も革新的かつ効果的なアプリケーションの多くがオープンソースであるため、組織は様々な重要業務においてオープンソースソフトウェアアプリケーションへの依存度を高めています。したがって、組織がオープンソースソフトウェアコミュニティに参加するのは、それらのアプリケーションの長期的な存続可能性、安定性、セキュリティに投資しているからであり、また多くの場合、それらのアプリケーションの機能や性能の開発に影響を与えたいと考えているからです。 + +他の組織は、自らが開発したソフトウェアを業界標準にしたいと考えてオープンソースソフトウェアコミュニティに参加します。彼らは、他者がより迅速に採用し統合することを期待して、自らの成果を公開するのです。 +多くの組織は、オープンソースソフトウェアコミュニティに参加することで、自社内でアプリケーションを開発する場合よりも広い人材プールにアクセスできることに気づいています。 + +## 組織はどのようにオープンソースソフトウェアコミュニティへの参加を始められるか？ + +新しい地域に引っ越すときと同じアプローチでオープンソースコミュニティに関わることから始めてみましょう。大きな変更を提案する前に、自己紹介をし、コミュニティの歴史、価値観、力学を理解するよう努めてください。 +小さな仕事をして新しい友人を作りましょう。ソースコードのバグ修正、ドキュメント編集、インストールスクリプト作成などです。組織がコミュニティ支援に追加リソースを割けるなら、イベントでの後援活動やコミュニティ開発者の雇用を検討しましょう。これにより彼らがプロジェクトに注力する時間を増やせます。 + +ただし、コミュニティが一度に受け入れられる人数を超える規模で参入すると、逆効果となる反応を招く可能性がある点に留意してください。これは組織の長期目標に反する結果を招きかねません。また、コミュニティへの初期参加者を慎重に選定してください。オープンソースコミュニティに参加するのは組織ではなく個人であり、ある参加者が築いた信頼は自動的に別の人物や組織に移転されるものではありません。 + +## 市場で競合する企業は、同じオープンソースコミュニティにどのように参加できるか？ + +多くの企業がこの立場にあります。こうした企業は、互いに有益なソフトウェアアプリケーションや標準規格の共同開発が、互換性のない異なる技術を開発して競合するよりも価値があると判断しています。むしろ、彼らのビジネスモデルは、こうした共有技術基盤の上に、市場差別化と収益創出をもたらすイノベーションを構築することにあります。 + +## 組織はどのようにオープンソースソフトウェアコミュニティへの関与を判断すべきか？ + +オープンソースソフトウェアコミュニティへの関与は、企業にとって組織的、手続き的、法的観点から重要な意味を持ちます。オープンソースソフトウェア開発に真剣に取り組む組織の大半は、オープンソースコミュニティ参加に関連する事項について組織に助言するため、内部のオープンソースプログラムオフィス（OSPO）に資金を提供しています。他の組織は、この業務を助言するためにオープンソースの専門家と提携しています。 + +## 結論 + +本章では、オープンソースコミュニティとは何か、そしてなぜ様々なタイプの人々や組織がそれらに参加するのかという基本を扱いました。その後、新しいオープンソースコミュニティを始めるかどうかを決定する際に人々が考慮すべき点について議論しました。 + + diff --git a/l10n/ja/getting-started/essentials-of-building-a-community.md b/l10n/ja/getting-started/essentials-of-building-a-community.md new file mode 100644 index 00000000..3f9ed071 --- /dev/null +++ b/l10n/ja/getting-started/essentials-of-building-a-community.md @@ -0,0 +1,191 @@ +--- +description: +author: Andy Oram , Karsten Wade , Bryan Behrenshausen +updated: 2025-05-21T00:00:00.000Z +translated-by: Ken Komazawa powered by DeepL Pro +--- + +# コミュニティ構築の要点 + +孤立して活動する企業や技術者は往々にしてこれを忘れがちですが、オープンソースソフトウェアプロジェクトを立ち上げることで、開発対象が実証されたニーズを満たし、ユーザーが求める機能を備え、使いやすいものであることを保証するために必要な人材を集める大きな一歩を踏み出せます。オープンソースでの活動は、優れた技術を創出し受け入れられるためにはコミュニティが不可欠であることを技術者に再認識させます。 + +オープンソースプロジェクトは[健全なコミュニティ](../measuring-success/defining-healthy-communities.md)に依存して成果を上げるため、メンバーは意識的にコミュニティ構築という困難な作業に取り組む必要があります。これには通常、以下のような実践が含まれます。 + +* 集合的な目標と戦略の設定 +* コミュニティガバナンスへの参加とリーダーシップ交代への準備 +* 多様な役割や様々な属性を持つグループを含むメンバーの募集、トレーニング、メンタリング +* 意思決定の導きと対立の解決 +* 健全な規範の維持 +* コミュニティメンバーの貢献を認め報いる +* ミーティングやイベントを通じたコミュニティの結束 +* コミュニティの成長管理と持続可能性の確保 + +本章では、成功するコミュニティのためにプロジェクトリーダーとメンバーが遂行すべきタスクをまとめ、それらの実行に向けたベストプラクティスを列挙します。本書全体で詳細に掘り下げる主要トピックの概要として、一種の「コミュニティクイックスタートガイド」と捉えてください。この簡略版を冒頭で提示するのは、コミュニティリーダーがベストプラクティスを早期に確立すべきだと考えるからです。後手に回って問題の対応や規範の定義を試みると、参加者を混乱させ、多くの人を離脱させる恐れがあります。ただし、コミュニティ構築に着手する前に『オープンソースウェイ』ガイドブック全体を読むことが、多くの人にとって現実的でないことも認識しています。 + +コミュニティの創出と維持には、時間・エネルギー・物的資源・労力・感情といった多大な投資が必要です。したがって、そもそもコミュニティを*創るべきか*、あるいは*創れるのか*という問いを真剣に検討することをお勧めします。ここから始めましょう。 + +## コミュニティ形成の検討 + +全てのオープンソースソフトウェアプロジェクトが独自のコミュニティを必要とするわけではありません。自身以外のコミュニティ形成に関心を示さない人々によってオープンソースソフトウェアが維持されるケースは可能です（むしろ珍しくありません）。 +逆に、いかなるコードベースも、メンテナによるコミュニティ構築行動が一切ないまま、突然その周りに形成されたコミュニティの中心となる可能性があります。 + +要するに、単にオープンソースプロジェクトである*こと*が、そのプロジェクトにコミュニティが生まれることを保証するわけではありません。しかし、*もし*コミュニティが生まれた場合、オープンソースソフトウェア特有の特定の恩恵を得られることを*意味します*。 + +オープンソースソフトウェアコミュニティを形成する際には、他の実践コミュニティを形成する時と同様の倫理的・組織的考慮事項に直面することになります。実践コミュニティとは、共通の関心事を持ち、その領域内で学び実践するために集まる人々の集団です。例を挙げれば、ハンマーダルシマー（訳註：楽器の一種）奏者が年次集会を開き、演奏技術や実践に関する知識を共有するコミュニティが挙げられます。あるいは、スケートボーダーが毎週公園に集まり、新たな技を学び練習するコミュニティも該当します。 + +あなた（および所属組織）がオープンソースソフトウェアコミュニティの形成を検討する際には、まず次の重要な問いを自問する必要があります。他の形態のコミュニティを形成し、その管理者となる意思はありますか？その行為はあなたのビジョンと合致しますか？あなたの仕事の進め方と合致しますか？ + +こうした問いは、コミュニティ形成があなたとチームにとって適切なアプローチか判断する助けとなります。例えば大学と軍隊では、物事を成し遂げる手法が大きく異なります。彼らがコミュニティを形成する動機も、大きく異なる（あるいは意外に一致する）可能性があります。 + +オープンソースソフトウェアコミュニティは、あらゆる実践コミュニティと同様、全く異なる世界から人々を真に結びつけることができます。オープンソースコミュニティでは、共通の関心（共有された実践）を持つ人々が結束し、協働して学び成長します（[コミュニティ](getting-started/community-101.md)）。 + +オープンソースコミュニティを形成する際に直面する可能性のあるその他の考慮事項には以下が含まれます。 + +* オープンな協働とイノベーションのメリットに関心がある。既に新しい技術を保有しているか、計画中で、オープンソースが志を同じくする協力者を見つける手段となる。あるいは単に、これが自身の計画に適したアプローチだと直感している場合もある。 +* プロジェクトへの熱心な参加者を惹きつけることが[成長戦略](getting-started/creating-an-open-source-product-strategy.md)の重要な要素であり、あらゆるタイプのオープンソース貢献者が優れた熱心な参加者となると認識している場合。 +* 科学的アプローチがミッション・目的・実践の中核であり、ソフトウェアツールチェーンやインフラなどのリソースを「ユーザーが貢献・メンテナになれる場」と位置付ける利点を認識している。 +* 組織の性質上、オープンで協力的、共同的な性質を持っている。ユーザーと貢献者が何らかの形で密接に連携する、適切な規模のオープンソースプロジェクトを立ち上げる可能性がある。例：大学の共同研究者たち。プロジェクト開始に法的障壁がないなら、なぜ始めないのでしょうか？将来、誰がそれを見つけ恩恵を受けるか予測できません。 + +コミュニティ構築には課題が伴います。オープンソースプロジェクトのベストプラクティスを定義する際には、以下のコミュニティ特性に留意してください。 + +* 参加者の多くは初心者です。開発技術やツールのトレーニングが必要な者もいれば、グループ内での効果的な交流方法を学ぶ必要がある者が大半です。 +* 特にボランティアの場合、貢献が認められることを人々は望みます。 +* アドボカシーやコミュニティ構築といった非技術的貢献は、見過ごされたり過小評価されたりしがちです。 +* 性別・人種・能力の多様性は、幅広いユーザー層にとって製品が有用であるかどうかに大きく影響しますが、この多様性を実現することは困難です。 + +あなたやあなたの組織がこれらの機会を魅力的だと感じ、それに伴う課題に立ち向かう意思があるなら、コミュニティ構築は適切な選択かもしれません。次に、その選択に伴う作業について詳しく見ていきましょう。 + +## 目標と戦略の設定 + +コミュニティ主導のプロジェクトを開始する際、最初に考慮すべきはプロジェクトの使命、ビジョン、目標、戦略的方向性です。これらを明確に定義し、コミュニティ全体が閲覧・コメントできる場所に文書化することは、プロジェクト初期段階における主要な作業となるでしょう。 +[プロジェクトの効果的な戦略目標設定](getting-started/setting-goals.md)には、以下のような核心的な問いかけが不可欠です。 + +1. プロジェクトの目的は何か？ +1. プロジェクトのユーザー層は誰か？ +1. 現在、ユーザーベースとどのように関わり合っているか？ +1. 既存の代替プロジェクトは何か？ +1. 関連プロジェクトと緊密に連携できるか？ +1. プロジェクトの目標は何か？ +1. 主要な利害関係者は誰か？ + +プロジェクト開始時にこれらの質問に徹底的に答えられるほど、成功の可能性は高まります。 + +## プロジェクトメンバーの募集 + +効果的なコミュニティは、単に門戸を開いて参加者を待つだけでは成り立ちません。リーダーはプロジェクトに必要なスキルや知識を分析し、それらを提供できる人材を調査し、参加者がプロジェクトを見つけ、参加する価値があると判断するよう働きかける必要があります。 + +有用な成果を生み出すためには、プロジェクトの影響を受ける可能性のあるあらゆるグループの代表者を招待することを検討してください。代表者を置くことで恩恵を受ける可能性のある影響グループには、潜在的なユーザー、あなたの作業の影響を受ける他の技術プロジェクト（あなたのプロジェクトに依存する、またはそれを基盤とするプロジェクトなど）、そして現在プロジェクトのリーダーシップにおいて過小評価されている人々が含まれます。プロジェクトリーダーは、[ステークホルダーを特定する](getting-started/setting-goals.md) ための明確な行動を取り、それらのステークホルダーの代表者を巻き込む必要があります。 + +このような関与の背景にある原則は、ユーザーやプロジェクトによって間接的に影響を受ける可能性のある他のグループには、外部からは見えにくいニーズがしばしば存在することです。影響を受けるすべてのグループの代表者を巻き込むことで、プロジェクトは誰もが享受でき、すべての人にとって公平な、より有用な成果を生み出すことができます。早期関与には実用的な動機もあります。プロジェクトの採用を妨げるような、後段階での批判リスクを回避できるのです。 + +### 新規メンバーの受け入れ + +オープンソースコミュニティを率いるには、プロジェクトの[受け入れ体験](growing-contributors/constructing-an-onboarding-experience.md)に対する一定の責任を担うことが往々にして伴います。これは新規メンバーがプロジェクトに参加し関与しようとする際の体験を指します。 + +プロジェクトメンバーの受け入れには通常、以下の作業が含まれます。 + +* プロジェクトの沿革を説明する +* 現在のプロジェクトのニーズや方向性に関する重要な議論を説明する +* プロジェクトのコミュニケーションチャネルを案内する +* プロジェクトへの貢献のメリットを説明し、メンバーの意欲を高める +* ミーティング時間やその他の時間的コミットメントを明確にする + +### 多様なメンバーシップによる包括的なプロジェクトの構築 + +ほとんどの技術プロジェクトのリーダーやチームメンバーは、人種や国籍、性別（男性、女性、LGBTQ+ と自認する人々を含むカテゴリー）、能力（例えば、視覚障害、器用さ、抽象的な情報を処理する能力など）の面で多様性に欠けています。支配的なグループが他の属性グループのニーズに敏感に対応しようとしたとしても、他のグループの人々の身体的および文化的な状況を十分に理解して、そのニーズを適切に表現することはまず不可能でしょう。排除されたコミュニティのメンバーを設計に関与させなければ、プロジェクトの結果は暗黙の差別につながる可能性があります。 + +多様なコミュニティを構築することは、より革新的で回復力のあるプロジェクトにもつながります。レッドハットの元最高人事責任者であるデリーサ・アレクサンダーが書いているように（https://opensource.com/open-organization/19/5/inclusivity-solution-innovation）、 + +> 多様性があり、包括的な組織は、より革新的な組織です。潜在的な問題についてより多くの角度から考察し、その問題の複雑性についてより率直に議論し、より知的で多面的な解決策を想像し、自分たちが作り出しているものの中に偏見がないかを見抜くことができるからです。また、そのような組織は、混乱に陥りにくい組織でもあります。多様な視点を採用することは、独自の訓練を受けた複数の目を地平線に向けて、先にあるものをスキャンすることに注力することを意味します。1か月後、1年後、5年後に組織に影響を与える変化をすべて予測することは不可能ですが、より幅広い洞察を活用することで、変化に直面した際の機敏性と回復力を高められます。また、組織全体に浸透した包括性の精神は、潜在的な脅威を発見した際に誰もが発言できる能力と安心感の両方を保証します。 + +この「包括性の一般的な精神」は、[多様なメンバーで構成されるオープンソースコミュニティの構築](attracting-users/building-diverse-open-source-communities-by-making-them-includive-first.md)に不可欠です。行動規範は多様なグループを受け入れる上で重要ですが、多様性のあるコミュニティ構築には不十分です。なぜなら、それは*否定的な行動*のみに対処するものであり、リーダーや他のプロジェクトメンバーが排除されたグループの代表者を積極的に求めるべき方法には必ずしも触れていないからです。具体的なステップには以下が含まれます。 + +* 過小評価されているグループの潜在的に影響を受けるメンバーをリーダーシップに招待する。「マイノリティ」と認識される人々はこうした要請を頻繁に受け、他のプロジェクトで自身の提言が反映されなかった経験から挫折感を抱くことが多い。そのため招待側は、プロジェクトの影響力を説明し、提言が真剣に受け止められる証拠を示せなければならない。 +* プロジェクトメンバーに対し、排除されたグループのメンバーを特定しプロジェクトへ招待するか、プロジェクトリーダーと繋ぐよう依頼する。 + +ダイバーシティ委員会がプロジェクトにおける多様性の重要性を促進するのに役立つ場合もありますが、多様性はすべてのプロジェクトメンバーの責任であり、あらゆるプロジェクトの決定において考慮されるべきです。 + +## 貢献者の育成 + +プロジェクトリーダーは、メンバーがプロジェクトでより大きなボランティアの役割を担うよう招待する方法に注意を払うべきです。理想的には、[プロジェクトの*ユーザー*を*貢献者*に変える](growing-contributors/from-users-to-contributors.md)ことです。メンバーが関心や自発性を示した際には、リーダーは対話を通じてそれを後押しすべきです。より積極的な参加を促す例を示します。 + +* 「提案されたシャットダウン機能に強い関心をお持ちですね。その開発チームに参加しませんか？週1時間のミーティングを4週間、さらに開発時間が多少必要になる見込みです」 +* 「グループ参加時に、自社で当社製品を導入されたとおっしゃっていましたね。マーケティングチームと30分ほどお時間をいただき、製品の提案方法や承認獲得の経緯を共有していただけませんか？」 +* 「過去に別のグループで類似ソリューションの導入に成功された実績があると承知しています。同じ課題に取り組む当チームの専門知識提供者としてご協力いただけませんか？チームは来週1時間のミーティングを予定しています」 + +各依頼には所要時間の見積もりが含まれている点に留意してください。貢献の依頼すべてにこの時間的コミットメントを示す必要はありません。参加意欲を削ぐほど負担が大きい場合もあるためです。むしろ、依頼される任務の重要性で関心を引かせましょう。そうすれば、彼らの熱意と（できれば他者との協働による好ましい経験）が彼らを後押しするはずです。 + +メンバーの募集や管理において、女性や歴史的に排除されてきたグループが新たな責任を担うよう促すことに、特に意識的に注意を払う必要があります。特定のタイプの人間が特定のタスクに適している（あるいは不適格である）と決して決めつけないでください。疑問があれば、尋ねてください。 + +## 意思決定の指針と対立の解決 + +全てのオープンソースプロジェクトは[ガバナンスモデル](growing-contributors/project-and-community-governance.md)に基づいて運営されます。このモデルはプロジェクトの歴史を通じて不変であることは稀で、コミュニティが成長し、参加者が作業分担や意思決定責任の最適な割り当て方法を模索する中で進化していきます。 + +ほとんどのオープンソースプロジェクトのガバナンスモデルは、重要な決定についてコミュニティの合意を確保することを目指しています。なぜなら、オープンソースプロジェクトは合意形成を通じて最も効果的に運営される傾向があるからです。「オープンソースのガバナンスがメンバーシップや投票に焦点を当てている場合でも、合意は常にそこにある。まるで空気中の酸素のように」と、[長年のコミュニティマネージャーであるカーステン・ウェイドは記しています](https://allthingsopen.org/articles/consensus-and-the-open-source-ai-definition)。「人々は合意に基づいて参加する——決定に不満があれば離脱できる。投票は通常、指導層の指示ではなく社会化の過程を経て行われる。大半の決定は投票が呼びかけられる前から既に合意が形成されている」。合意形成が常に可能とは限らないものの、それはプロジェクト参加者に包括的な行動を促す目標であり続けます。 + +各プロジェクトは異なるガバナンス慣行と仕組みで運営されています。例えば投票はコミュニティの意向を測る手段として有用ですが、議会投票のような決定的な性質を持たない場合もあります。他のプロジェクトでは意思決定権を単一権威（通常は創設者で、**慈悲深い独裁者（benevolent dictator）**と呼ばれることもある）に委ねますが、このモデルは長期的に機能しないことが多いです。そのため多くのプロジェクトでは技術運営委員会やコミュニティ運営委員会を設置し、意思決定責任を分散させています。 + +したがってコミュニティリーダーは、プロジェクトの方向性に影響を与える活動において参加者が真の主体性を感じられるよう、プロジェクトのガバナンスモデルを理解し、意図的に設計・洗練させるべきです。 + +## コミュニティメンバーの認識と報酬 + +[オープンソースプロジェクトに参加するボランティアの動機は様々です](guiding-participants/why-people-participate-in-open-source-communities.md)。専門家は自身の実践に関する標準を確立したいと考え、学生はスキルを磨くために参加し、誰もが世界のためにより良い技術を作りたいと願っています。しかしあらゆるレベルで、人々は自身の仕事に対する報酬を評価し、報われていると感じればより多く貢献します。 + +オープンソースプロジェクトをリードするには、こうした報酬のためのシステムを構築することが往々にして必要です。コミュニティの報酬システムは、プロジェクトの使命とビジョンを反映し、貢献者が参加する動機と結びつくべきです。例えば、バッジ制度は[優れた仕事に対する公的な認知を求める貢献者を報いる](guiding-participants/incentivizing-and-rewarding-participants.md)のに役立ち、より高いレベルで貢献できる可能性のあるコミュニティメンバー、さらにはプロジェクトリーダー候補を特定する助けとなります。 + +## プロジェクトリーダーシップの構築 + +ボランティアをリーダーシップの役割へと導くのは困難な作業です。多くの参加者は技術的スキルを提供したり、個人貢献者として特定の役割を果たすためにプロジェクトに参加しています。リーダーシップを担う時間的負担を恐れたり、本来やりたいことに比べ「退屈な邪魔」と感じるかもしれません。さらにリーダー自身もプロジェクト運営に追われ、新たなリーダーの募集や育成に時間を割くのが困難です。しかしこれらの活動は長期プロジェクトにとって不可欠です。 + +リーダーの育成はオープンソースコミュニティ構築の核心です。プロジェクトリーダーの成功は、新たなリーダーを育成し権限を委譲する能力（そして彼らが同じことを繰り返すことでプロジェクト内に[メンターシップ文化](growing-contributors/creating-a-culture-of-mentorship.md)を創出すること）に大きく依存します。候補者を見極める際には、深い質問を投げかけたり、プロジェクトの新しい方向性や新たなマーケティング手法を提案したり、その他の非公式なリーダーシップを発揮しているメンバーに注目しましょう。関与方法は二つあります。空いているリーダーシップ役職を説明し直接引き受けを打診する方法、あるいは対話を始め、彼らがプロジェクトに何を求めているかを把握した上で、それらの目標達成のためにリーダーシップを担うよう促す方法です。 + +リーダーシップポジションは時間的コミットメントと重大な責任を伴いますが、誰もが経験すべき素晴らしい成長の機会です。プロジェクトでリーダーシップ役割を担うよう招待する際に提供できるインセンティブ例は次の通りです。 +* プロジェクトに望む変更を実装する範囲が格段に広がる +* プロジェクトの目的と影響をより深く理解できる +* 尊敬し、模範としたいプロジェクトリーダーと密接に関わることができる +* プロジェクト管理やコミュニティ対応の新たなスキルを習得できる +* 専門知識や貢献がコミュニティ内外で認められ、ネットワーキングの機会や個人のキャリア成長につながる + +ボランティアが最初に尋ねるのは「どれくらいの時間を割く必要があるのか？」という質問です。回答する際、必ずしも役割に必要な時間を強調する必要はありません。リーダーになった場合にプロジェクトにもたらされる利益、あるいは自身が得る地位の向上とそれによる恩恵（場合によっては所属組織への利益も含む）について、ボランティア自身が考えられるよう導きましょう。メンバーの重要性を説明して褒めることを恐れないでください——それは全て真実なのです！ + +多くのオープンソースソフトウェアプロジェクトは、*技術的*リーダーシップの育成に重点を置く傾向があります。これは通常、技術的貢献（例：プロジェクトへのコードコミット）を行った後に担われる役割です。しかし、リーダーシップの役割は多岐にわたり、以下のようなものがあります。 +* プロジェクトメンバーの募集 +* プロジェクトメンバーの指導 +* プロジェクトのガバナンスモデルに基づく紛争解決 +* 主要なプロジェクトリソースの管理と、それらを利用したい他のメンバーの支援 + +## コミュニティの価値観と規範の維持 + +共通の価値観を持つ人々が一定期間協働すると、暗黙のうちに協働方法を規定する規範が形成されます。こうした規範はオープンソースソフトウェアコミュニティを含む、あらゆる持続可能なコミュニティの基盤です。こうしたコミュニティをリードするには、コミュニティの価値観を守り、それらの規範を示すことが求められます。 + +コミュニティ規範の乱用は即座に対処すべきです。理想的には、誰かが良識ある行動規範に違反した場合、他のメンバーが丁寧に指摘し、違反者が行動を改めることです。しかし誰も指摘しない場合、あるいは違反者がその行為を巡って炎上騒ぎを引き起こした場合（これはグループを疲弊させ、元の違反行為以上の損害をもたらす可能性がある）、モデレーターの介入が必要となります。そしてこのモデレーターは、必要に応じて誰かを追放する権限も含め、規範を執行する権限を持たねばなりません（ただしそれは極めて稀であるべきです）。 + +このモデレーター役を複数人で分担したくなるかもしれませんが、それには危険が伴います。行動規範の曖昧な違反に対して異なる反応を示したり、自ら炎上騒ぎに発展させたりする可能性があり、それは極めて破壊的です。一度に一人のモデレーター（業務量が多い場合は交代制）を置き、議論の負担をメンバーに負わせずにコミュニティ運営委員会が決定を審査する方が良いでしょう。 + +行動規範が、コミュニティメンバーの参加を脅かす形で違反された場合、あるいは議論の質を低下させる恐れがある場合、コミュニティの最優先事項——そして議論を監視するモデレーターの最優先事項——は規範を守り、脅威が除去されることを確実にすることです。これには通常、問題発言に対する明確な批判が必要です。ただし、その方法は様々であり、全ての立場に共感的なアプローチがより良い結果を生む可能性があります。 + +ボランティアはほぼ例外なく善意でプロジェクトに参加し、優れたスキルを提供できる人が多いことを忘れないでください。攻撃的な発言は、強い感情か無知のいずれかから生じることがほとんどです。モデレーターやメンターは、その発言が許容できないと表明しつつ、発言者本人と直接話し、何が引き金となったのかを探ることができます。通常、その人物をコミュニティに残し、より良い交流の方法を導くことが可能です。 + +不快な発言による損害を修復するには、リーダー（できれば他のコミュニティメンバーも）がそれを許容範囲外と宣言する必要があります。ただし発言者は、リーダーとの個別話し合いを経て、謝罪し、今後同様の行為を避けることを約束すべきです。そのような謝罪がなされない場合、発言者は少なくとも一時的に参加禁止となる可能性があります。 + +行動規範に違反する発言は、したがって二段階で対処すべきです。まず、リーダーまたはモデレーターが、その発言が行動規範に違反し許容されないことを宣言する。次にリーダーは発言者と非公開で接触し、発言の背景を尋ねる。強い意見の真っ最中だったのか？意図的に他のメンバーを挑発または萎縮させようとしたのか？発言が不快だと本当に気づかなかったのか？発言の理由を把握した後、リーダーはその発言者と対話し、コミュニティ内で建設的に活動する方法を学ぶ手助けをするべきです。ただし、介入を拒否したり、行動規範違反の「権利」を主張し続ける場合は、その人物を禁止せざるを得ない場合もあります。 + +## 進捗管理と成長測定 + +オープンソースソフトウェアコミュニティへの投資が、そのコミュニティの成長と繁栄につながることを願っています。コミュニティが成長するにつれ、リーダーは意識的（かつ誠実に）にその成長を管理し、コミュニティが健全かつ持続可能であり続けるよう確保しなければなりません。 + +[コミュニティの成長を測定するのは難しい](measuring-success/understanding-community-metrics.md)ですが、その努力に見合う価値があります。測定指標には以下のような重要な役割があります。 +* 誰が貢献したかを明らかにし、メンバーの士気や貢献意欲を高める +* プロジェクトの効果測定（例：新機能の開発状況、バグ報告への対応率） +* プロジェクトの健全性評価と改善点の特定 +[健全なコミュニティ](measuring-success/defining-healthy-communities.md)は人々の貢献を顕在化させます。なぜなら、ほとんどの貢献者は報酬を得ておらず、努力が認められること以外に個人的な利益がないからです。さらに、最も貢献している人物を把握することで、新たなリーダーシップ役割や責任を担う人材を育成できます。幸い、ソフトウェアやテキストベースのプロジェクトでは、特定の貢献度を自動計測するツールが利用可能です。ソース管理システムやバグトラッカーなどを使い、重要と考える指標を追跡しましょう。 + +主な指標例： + +- 特定期間内の修正済みバグ数と採用された変更数（バグ報告が多いことはプロジェクトにとって悪いことではありません。全てのプロジェクトにはバグが存在するため、バグ報告が絶えず寄せられることは製品が利用されている証です。ただしバグは修正されるべきです！） +- プロジェクトのダウンロード数（試用目的でダウンロードして放置するユーザーも多いので、ユーザー基盤の真の成長を測るには他の指標を活用しましょう。例：フォーラム参加人数や質問投稿数） +- コミュニティ内の貢献者経験のバランス（プロジェクトメンバーの適切な構成が重要。長期間在籍し組織的記憶を提供するメンバーと、新たなエネルギーをもたらす新規加入者が共存していること） + +## 結論 + +本章では、オープンソースソフトウェアコミュニティの立ち上げ可否を判断し、その最適な構築方法を決定する際に考慮すべき本質的な要素について概説しました。 diff --git a/l10n/ja/getting-started/new-project-checklist.md b/l10n/ja/getting-started/new-project-checklist.md new file mode 100644 index 00000000..e4d7eb77 --- /dev/null +++ b/l10n/ja/getting-started/new-project-checklist.md @@ -0,0 +1,75 @@ +--- +description: +author: Lisa Caywood , Josh Berkus , Bryan Behrenshausen , Karsten Wade +updated: 2025-11-17 +translated-by: Ken Komazawa powered by DeepL Pro +--- + +# 新規プロジェクトチェックリスト + +これは、新規オープンソースプロジェクトを開始する際に考慮すべき比較的シンプルなチェックリストです。特に、プロジェクトが小規模で始まるものの成長の余地を望む場合に有用です。「シンプル」とは、これらの項目を達成するためのプロセスやプロジェクト管理を提案しないことを意味します。最も単純な形では項目の定義がなく、リストへの従順さを要求せず、将来の指針を示唆するものです。 + +対象領域に応じて、以下の複数のリストに分類されています。 + +## プロジェクトの目標 + +* [ ] プロジェクトが解決する技術的問題 +* [ ] 想定ユーザーと価値提案 +* [ ] マイルストーンを含む初期ロードマップの策定 + +## 市場ポジショニング + +* [ ] 関連/類似プロジェクトのリスト +* [ ] なぜ新規プロジェクトなのか？ +* [ ] 主要な差別化要因 + +## プロジェクト名 + +* [ ] 候補リストの収集と審査 +* [ ] ロゴデザイン +* [ ] 法的審査（必要な場合） +* [ ] 名称の確保（ドメイン名、GitHub、SNSアカウント名など） + +## ライセンスと法的要件 + +* [ ] ライセンス基準の文書化 +* [ ] ライセンスの選択 +* [ ] 商標登録（™）その他のマーク登録が必要か？ + +## ガバナンス + +* [ ] 役員とその責任範囲の定義 +* [ ] 組織構造、投票要件とプロセス +* [ ] ガバナンス改正に関する規則 +* [ ] 貢献、コミッター資格に関する規則 +* [ ] サブプロジェクトとライフサイクル管理に関する規定 +* [ ] プライバシーポリシー +* [ ] 行動規範 +* [ ] 財団会員制度（計画がある場合） + +## プロジェクト基盤 + +* [ ] メールツール（および管理者） +* [ ] フォーラム/チャット（および管理者） +* [ ] 文書リポジトリ（スライド、計画書など） +* [ ] ウェブ会議プラットフォーム +* [ ] コミュニティカレンダー（ツール＋管理者） +* [ ] 公開ウェブサイトとサイト保守 +* [ ] CI/CD、開発環境とテスト環境 +* [ ] ラボ要件、調達方法 +* [ ] コード貢献ツールとプロセス +* [ ] プロジェクト文書プラットフォーム + +## 所有権と資金調達 + +プロジェクト資産を財団に寄付する場合は、これらの項目は無視可能です。 +* [ ] ウェブサイトURL +* [ ] ロゴ +* [ ] ソーシャルメディアアカウント +* [ ] ウェブ会議プラットフォーム（有料の場合） +* [ ] プロジェクト必要資金調達プロセス + +## 立ち上げ計画 + +* [ ] ダイバーシティ（多様性）とインクルージョン（包摂性）（D&I）計画 +* [ ] コミュニティ健全性および指標に関するビジョン/計画 diff --git a/l10n/ja/growing-contributors/README.md b/l10n/ja/growing-contributors/README.md new file mode 100644 index 00000000..51d660fc --- /dev/null +++ b/l10n/ja/growing-contributors/README.md @@ -0,0 +1,34 @@ +--- +description: +author: Karsten Wade +updated: 2020-12-11 +translated-by: Ken Komazawa powered by DeepL Pro +--- + +# 貢献者の育成 + +これはガイドブックの中で最も長く、最も詳細なセクションです。オープンソースソフトウェアプロジェクトの周りにコミュニティを築くという課題は、複雑で興味深く、困難で厄介でありながら、やりがいのあるものだからです。 + +誰かがあなたのソフトウェアをより良くする手助けをしたいと望む段階に達した時、すでにコミュニティ内にいる人間として、あなたには神聖で長老としての責任が生まれます。それは、コミュニティの外にいる誰かが寒さの中を歩み寄ってくるのを迎え入れ、その参加を可能にすることです。その人が貴重な関心だけでなく、それに伴う努力への意欲——世界をより良くしようとする努力——をもたらすために来た場合、この責任はさらに切実なものとなります。 + +なぜなら、誰かが進んでコミュニティ活動に貢献する時、その根底には「世界をより良くしたい」という私たち全員が共有する願望があるからです。貢献とは、その願望が行動となる瞬間です。 + +本セクションでは以下の章を扱います。 + +* 参加者から貢献者への変遷とプロセスを解説 +* オープンソースプロジェクトへの貢献の定義と具体例 +* 完全なオープンソースプロジェクトを組織化する手順 +* 新規貢献者をプロジェクトに迎え入れるための取り組みとプログラム作成の資料を提供 +* メンターシップ文化の重要性を共有 +* メンタープログラム構築に向けた具体的な手順 +* ガバナンスの構築と運営の手段・方法を網羅 +* コミュニティ内の役割の種類とその意義を列挙 +* コミュニティマネージャーと貢献者にとってのセルフケアの重要性と手法に焦点 + +このセクションは以下のような場合に有用です。 + +* 貢献者基盤の拡大を目指す方。 +* 本セクションの主要テーマについて、より深く徹底した理解を求める方。 +* 貢献者やその活動に関する課題の解決に取り組んでいる方。 +* 貢献者コミュニティを導く方法論と理念を説明する参考資料が必要な方。 +* このセクションを楽しみにガイドブックを読み進め、ページを一つ一つ味わっている方。 diff --git a/l10n/ja/growing-contributors/community-manager-self-care.md b/l10n/ja/growing-contributors/community-manager-self-care.md new file mode 100644 index 00000000..17c637a2 --- /dev/null +++ b/l10n/ja/growing-contributors/community-manager-self-care.md @@ -0,0 +1,472 @@ +--- +description: +author: Ashley Nicolson +updated: 2020-07-09 +translated-by: Ken Komazawa powered by DeepL Pro +--- + +# コミュニティマネージャーのセルフケア + +{% hint style="danger" %} + +本章の資料は情報提供のみを目的としており、医療アドバイスを提供するものではありません。本章は専門的な医療アドバイス、診断、または治療の代わりとなることを意図したものではありません。ご自身の健康（精神的・身体的双方）に関する疑問や懸念がある場合は、必ず医師またはその他の資格を持つ医療提供者に相談してください。 + +{% endhint %} + +コミュニティマネージャーは、その役割のため（そしておそらく本質的にも）、コミュニティメンバーやチームの健康と幸福に注力（時には執着）しがちです。安定した安全でインクルーシブ（包摂的）なオンラインコミュニティ、つまり人々が思いやりと共感を見せる場を育むことの難しさと課題を理解しているからです。しかし、彼らは往々にして、他のコミュニティメンバーが克服しようとする感情的に困難な課題に対して、自分たちは免疫があると誤って思い込んでしまいます。 + +さらに、自分の役割を十分に果たせないと思われたり、最悪の場合コミュニティや仲間から完全に拒絶されたりするのを恐れて、自らの弱さを_隠そう_とするかもしれません。この脆弱性への見方は、コミュニティマネージャーを孤立の道へと導く可能性があります。必要な時に助けを求めることができないと感じさせる道です。 + +しかし、自身の健康状態に目を向けず、悪化する症状への対処を先延ばしにするほど、問題は大きくなります。やがて私たちは精神的・肉体的に衰弱し、息が詰まるような状態に陥り、かつて役割が与えてくれた充実感や喜びを奪われてしまうのです。その喜びを取り戻すには数ヶ月、場合によっては数年を要します。実際、かつての職務への情熱を完全に回復できない可能性すらあるのです。 + +コミュニティマネージャーとして自らを支え、ひいては他者を支えるためには、不満・幻滅・燃え尽き症候群の兆候を見抜く術を学ぶ必要があります。これらの兆候は微妙で気づきにくいものですが、行動の変化（まず何よりも自分自身において）を認識し認めることで、コミュニティ内の他者に対しても同様の気づきを適用し始められます。この経験は、バーンアウトの発生と影響を軽減し、身体的・精神的に健全で生産性の高いコミュニティを促進するための社会的規範や仕組みを開発・構築する洞察を提供します。 + +本章では、セルフケアの重要性と、コミュニティマネージャーが自身の役割における対人関係面（ポジティブにもネガティブにも影響し得る要素）に注意を払うべき理由を探ります。また、自身に適用しコミュニティ内で推進できる、健全なワークライフバランスを促進・維持するための実践的なステップも提供します。 + +## セルフケアの重要性 + +セルフケアとは具体的に何か？ + +WHO（世界保健機関）はセルフケアを次のように定義しています。 + +> 「セルフケアとは、個人、家族、コミュニティが、[医療提供者](#user-content-fn-1)[^1]の支援の有無にかかわらず、健康を促進し、疾病を予防し、健康を維持し、疾病や障害に対処する能力である」。 + +つまりセルフケアとは、身体的・情緒的・人間関係的、そして場合によっては精神的ウェルビーイングを根本的に支える活動を、意識的かつ注意深く実践することです。私たちは既に日常的にセルフケアを実践しています。例えば健康的な食事、運動、十分な睡眠といった総合的な健康を守る行動がそれです。しかし時に、こうした行動だけではウェルビーイングを維持しきれず、追加的な支援を意図的に求める必要があることに気づくでしょう。 + +幸福な精神状態にある時、私たちは通常ストレスをより効果的に処理できます。セルフケアを実践することで、避けられないストレス要因に対する回復力を育むことができるのです。 + +このセルフケアの概念は理論上は単純に見えるかもしれませんが、特にコミュニティマネージャーによって見過ごされたり軽視されたりすることがよくあります。その理由を探り（そして分解）してみましょう。 + +## 感情の伝染 + +コミュニティマネージャーは、リーダーとして、誰もが頼れる存在として、他者が模範とするべき存在として見られることが多いです。この一見高い地位は重圧となり、成長するだけでなく生産的なコミュニティを実現するためには、高い感情知性と精神的努力が求められます[^2](#user-content-fn-2)。 + +困難な状況に直面した時、コミュニティにその時期を乗り切らせることは、往々にして私たちの責任（そして私たちの願い）です。しかしそのためには、_私たち自身_が最高の状態にある必要があります。つまり、持続可能な形で他者をケアする前に、まず自分自身をケアしなければなりません。そうしなければ、投げかけられるあらゆる課題に適切に対処することは不可能です——多様な個性との関わり、対立の解決、困難な決断、そして将来の長期目標に向けた取り組みの中で、常に何かしらの課題は発生します。だからこそセルフケアが極めて重要なのです。 + +セルフケアへの第一歩は、自身の感情状態がコミュニティに与える影響を自覚することです。 + +感情（ポジティブ・ネガティブ双方）は[非常に伝染性が高いです](#user-content-fn-3)[^3]。私たちの感情表現は、周囲の人々に無意識に影響を与える力を持っています。その結果、他者は無意識のうちに私たちの感情を[模倣し始める](#user-content-fn-4)[^4]ことさえあります。私たちが不安やストレスの状態にあると、他者はそれを感じ取り、自らのネガティブなエネルギーでそれを増幅させてしまうのです。これは特に有害なコミュニティメンバーが他者に悪影響を与える事例で見られますが、私たち自身も無意識のうちに他者に過度な影響を与え得ることに気づいていないのです。同様に、私たちが純粋に心地よい気分であれば、周囲の人々はそのポジティブな雰囲気に牽引され、より生産的になる傾向があります。 + +要するに、他者の最高の状態を引き出すためには、私たち自身が最高の状態を示す必要があるのです。 + +リーダーとして、私たちはコミュニティに前向きな変化をもたらす膨大な力を有しています。この力を活用しましょう。あらゆる機会を捉え、セルフケアを奨励・促進するために影響力を行使してください——それはコミュニティのためだけでなく、あなた自身のためでもあります。自分にとってのセルフケアとは何かを学び、その理解をチームと共有しましょう。コミュニティマネージャーが最も内密な恐怖や不安を共有する必要はありません。しかし、セルフケアの重要性について単に会話を始めること自体が有益です。それはコミュニティを_運営する_チームだけでなく、_コミュニティ全体_にとって有益なのです。 + +あなた自身とチームの業務負荷の中で、セルフケアを実践するための定期的かつ専用の時間を特定し、確保しましょう。成果物に対する現実的な期待値を設定し、ストレスや負担の潜在的な引き金となる要素についてチーム内で頻繁にコミュニケーションを取りましょう。それらは、自身の身体的・精神的健康に集中するためのより多くの休息時間を必要とする可能性があります。 + +セルフケアを積極的に推進・提唱する姿勢を示すことで、メンバーもあなたの後を追うように行動し始めます。同時に、リーダーは仕事における感情的な側面に対して無敵であるという不健全な前提を崩し、あなたの人間的な側面を明らかにし始めるのです。 + +## 不完全でありながらも共感的な人間であること + +私たちはしばしば、コミュニティマネージャーのあるべき姿（自らまたは他者による）という非現実的な一般化に支配されていることに気づきます。意欲的で、友好的で、成功し、超人的で、完璧であることさえ求められるのです。 + +しかし、リーダーが「あるべき」姿というこうした印象は矛盾に満ち、根本的に欠陥があります。リーダーは多くの人々にとって様々な存在となり得るが、最も重要な側面は人間であることす。欠点も含めて。 + +それにもかかわらず、コミュニティマネージャーはこうしたリーダー像に過剰に合わせようとしがちです——特に「感情的すぎる」と見られること、あるいはさらに悪いことに「制御不能」と見られることを恐れて、ネガティブな感情を抑圧し隠そうとします。 + +しかし、_in_ control（制御している状態）、_controlled_（制御されている状態）、_under_ control（制御下にある状態）には違いがあります。 + +「制御している状態は、自分たちの成果に対する自信の表れだ」という考えは誤りです。むしろそれは、完璧ではない姿や[それ以下のものを受け入れること](#user-content-fn-5)[^5]に苦悩する姿を他者に見せたくないという躊躇を示しています。この表向きの姿勢は一時的に他者の感情や批判から身を守れるかもしれませんが、感情を押し殺すことで自ら招く自己破壊からは守れません。 + +感情を抑圧した代償は必ず、しかも劇的に表面化します。この時、感情が_私たちを支配する_（そして行動も）ようになり、反芻思考（rumination）やチーム・コミュニティとの関係崩壊、バーンアウトなどの負の結果を招くことが多くなります。 + +究極の目標は、感情と仕事量の両方を「コントロール下」に置くことです。ここで私たちの情熱と注意力は建設的かつ目的を持って向けられる——特に過ちを犯した時に重要な状態です。 + +「ありのままの自分を職場に持ち込む」という言葉は、この自己許容を表現するのに適しています。私たちは、知らないことがあるとき、正しい判断ができなかったとき、過ちを犯したとき、それを認めてもいいと感じるべきです。そして、良い日もあれば悪い日もあることを認識し、受け入れるべきです。 + +自分自身に誠実であることは、コミュニティに対して誠実であることと同じくらい重要です。もし自分自身に誠実でなく、感情の状態に敏感でなければ、コミュニティ内の困難な状況を意図せず悪化させる可能性があります（おそらく_私たち自身_が、状況を適切に対処できる明確さを感じるまで一歩引くべきだという認識に失敗したために）。 + +このような感情労働を維持することは、非常に疲弊するものです。完璧であることは達成不可能であり、さらに重要なことに、優れたリーダーであるための要件ではないということを認め、受け入れる必要があります。_本当に_重要なのは、人々があなたの「人間的な側面」に共感できることです。 + +人々は[親近感](#user-content-fn-6)[^6]を共有する相手に惹かれます。この親近感を認識できることが、効果的なコミュニティマネージャーの証の一つです。メンバーがあなたの中に自分たちと同じ資質を見出せれば、より容易に共感できるのです。皮肉なことに、私たちはメンバーやチームへの共感実践の重要性を強調しがちですが、メンバーが私たちに対して思いやりや感謝を示すことも同様に重要です。 + +チームやコミュニティの全員がこのような共感を育むことで、相互のつながりと信頼は次第に深まり、それが非公式な社会的支援ネットワークの構築につながります。このネットワークは、セルフケアの重要性を促進する場となり、批判のない空間を作り出し、個々のメンバー（あなた自身を含む）が感情を整理し、不満を吐露し、業務負担を共有するための安全な避難所を提供します。 + +一部のメンバーが、あなたが万能で絶対的な船長であるという見せかけを貫くことを期待するのは避けられないでしょう。しかし効果的なセルフケア習慣と、この社会的支援ネットワーク内のメンバーの支えがあれば、そうしたストレス要因に対処する自身の能力に自信が持てるようになります。また、あなたの弱さこそが、より優れたコミュニティリーダーたる所以であることも理解できるでしょう。 + +## セルフケアの種類 + +気分や状況によって、人々が好むセルフケアの手法や戦略は異なります。効果的なセルフケアには定期的かつ意識的な実践が不可欠です。したがって、セルフケアを単なる反応的な選択ではなく、日常生活のストレスを軽減する手段として捉えることが重要です。 + +しかし一般的に、健康で幸せな心身を育むという基本的なニーズを満たすために、いくつかの異なるタイプのセルフケアが存在します。それらは以下の通りです：_身体的_、_精神的_、_霊的_、_感情的_、そして_社会的_です。 + +次に、これらの各タイプについて詳しく見ていきましょう。ただし覚えておいてください。健康的な生活のバランスを保ち、あらゆる種類のストレスに適切に対応するためには、_これら全ての_タイプの活動から_選択した_ものを実践することを目指すべきです。 + +### 身体的セルフケア + +身体的セルフケアは通常、最低限無意識に行うセルフケアです（食事、水分補給、睡眠、運動など）。 + +しかし私たちは、仕事のためにこれらの必要性を軽視しがちです（例えば頻繁な徹夜を耐えたり、平日毎日昼食を忘れたり）。栄養を補給することは身体の健康維持に役立ちます。健全な身体的セルフケアの習慣を身につけることは、仕事や_職場環境_から定期的に離れることにもつながります。 + +身体的セルフケアには以下のような活動が含まれます。 + +1. 規則正しい睡眠習慣の維持 +2. 健康的な食事 +3. 昼寝 +4. マッサージを受ける +5. 散歩に出かける +6. ストレッチ +7. ヨガ（またはその他の運動）を行う + +### メンタルセルフケア + +メンタルセルフケアとは、ストレスレベルを軽減するために、前向きで目的意識のある思考で心を刺激する行為です。 + +これは、興味のあるトピックについて知的なレベルで心を働かせ続けることや、思考を整理し再構築するために頭の中を整理整頓することを意味します。 + +メンタルセルフケアは他のタイプに比べて目に見えにくいため、即効性のある効果を実感しにくい場合があります。 + +しかし、継続的に実践することで、精神的な充足感が高まり、人生の他の側面に対する健全な姿勢が育まれるという恩恵が形になって現れてくるでしょう。 + +メンタルセルフケアの具体例： + +1. 新しい本や記事を読む +2. 新しい趣味や興味を試す +3. 目標リストを作成する +4. パズルを解く +5. 部屋のスペースを整理・片付ける + +### スピリチュアルセルフケア + +このタイプのセルフケアは、宗教のみに関わるものと誤解されがちですが、宗教的であるか無神論者、不可知論者、その他を問わず、誰にでも適用できます。 + +スピリチュアルセルフケアとは、あなたとあなたの魂とのつながりを育み、より深い意味や宇宙への理解をもたらす活動です。「魂」という言葉は、あなたを体現していると感じる存在や独自性を表すに過ぎません。これは内なる精神、エネルギー源、あるいは他の概念を指すこともあります。 + +スピリチュアルなセルフケアの例： + +1. 関心のある活動へのボランティア参加 +2. 瞑想 +3. 自然の中で過ごす時間 +4. 祈りや宗教的儀式への参加 +5. 最も重要な価値観や道徳観の明確化 +6. 重要な人間関係への考察 +7. 新たなスピリチュアリティや宗教の形を探求する + +実践するセルフケアの種類や活動が異なっても、その目的は持続可能な方法で私たちを支え、役割に伴う負の影響から身を守ることです。身体的・精神的健康を無視すれば、ストレスや疲労に屈しやすくなり、バーンアウトのような危険な慢性疾患や症候群へとつながる可能性があります。 + +## バーンアウト + +バーンアウトとは具体的に何か？[WHOの定義](#user-content-fn-7)[^7]によれば、 + +> 「バーンアウトとは、慢性的な職場ストレスが適切に管理されなかった結果として生じる症候群と概念化される」 + +バーンアウトはあらゆる職業で発生しますが、長期間にわたり精神的・感情的に消耗する役割でより顕著に見られます。これは、そうした役割において[自己犠牲的で他者を優先する](#user-content-fn-8)[^8]ことが規範化されているためです。クライアントやコミュニティのために、満足のいく環境や雰囲気を維持するために、常に一歩踏み込んだ努力が求められるのです。 + +また、[テクノロジー業界内でも増加傾向にあります](#user-content-fn-9)[^9]。この増加は、業界で容認されている24時間365日の労働意識と競争性に起因するとされ、技術、特にソフトウェア開発に携わる労働者が健康を損なう危険性があるほど圧倒され、精神的に疲弊する結果を招いています。 + +仕事に関連するストレスとバーンアウトは全く異なるものであることを強調すべきです。場合によっては、ストレスがモチベーションの源となることもありますが、それは管理可能で一時的な期間に限られます。職業上のストレスが長期にわたり慢性化し、自身の全体的な健康状態に影響を及ぼすようになると、いわゆる_バーンアウト_へと発展する可能性があります。 + +### 症状に注意 + +バーンアウトは、その兆候が微妙で進行性であるだけでなく、初期段階ではより一時的で一般的な仕事関連のストレスと誤診されやすいため、発見が極めて困難です。これは、両者が類似している状態が続き、手遅れになるまで深刻化して治療が困難な問題へと発展してしまうためです。 + +心理学者Herbert Freudenbergerは、1970年代以降、バーンアウトの潜在的原因・影響・作用に関する研究成果を多数の書籍・論文で発表しています。[彼の研究](#user-content-fn-10)[^10]は様々な症状を定義し、バーンアウト体験の段階を明らかにするのに貢献しました。 + +おそらくあなた自身にもいくつかの症状が当てはまるでしょう。あるいは1つか2つだけかもしれません。兆候を見抜くのは必ずしも容易ではありません。なぜならそれらは時間をかけて徐々に現れるだけでなく、何かが間違っているという事実を自分自身が否定することで隠れてしまうからです。 + +#### 消耗 + +エネルギーの喪失とそれに伴う倦怠感は、特に普段から[高いエネルギーレベルを保っている人に最初に現れる兆候です](#user-content-fn-11) [^11]。ただし、普段通りの活動を続けるのが困難だと感じた場合、無理に自分を追い込まないよう注意が必要です。そうすることで問題は悪化するだけです。 + +感情と同様に、私たちのエネルギーも周囲の人々に影響を与えます。私たちは目標を達成し、その成果を得ることでエネルギーを補充し、それを他者と共有する傾向があります。エネルギー不足のために成果を得られない場合、それは悪循環を生み出します。 + +かつては興奮を覚えたこと――例えば会議を終えて目標達成への意欲に燃えること――が今では日常化し、すでに枯渇しつつあるエネルギーの過剰消費と見なされます。達成感の欠如を他者ほど自覚できないのは、報酬獲得の意義を次第に軽視し、疲労の原因を増加する業務量に帰するからです。 + +#### 距離を置くこと + +私たちは通常、感情的なストレスや苦痛を避けるための自己防衛手段として、距離を置いたり無関心になったりします。チームやコミュニティ、会社、あるいは自分自身でさえも、周囲の状況や人々に失望し始めると、その重要性を軽視したくなります。「どうでもいい、どうせ重要じゃなかったんだ」と、かつて関わっていたものから距離を置く。そうすることで、それらに悪影響を与える力を奪うが、同時に良い影響も遮断してしまいます。これが孤独や孤立を招くのです。 + +#### 退屈と冷笑主義 + +かつて自分を興奮させたものから距離を置くようになると、周囲の出来事に興味を持ち続けることが次第に困難になります。自分の行動や人間関係、ひいては人生のより大きな側面の価値さえ疑い始めます。これが他人の動機や目的に対する懐疑心、あるいは疑念へと発展する可能性があります。 + +#### 焦燥感と高まった苛立ち + +高いエネルギーレベルを持つ人々は、物事を素早く処理して次へ進む能力ゆえに、他人に対しても自分自身に対しても、軽度の焦燥感を抱く傾向があります。しかし燃え尽き症候群を経験すると、物事を過剰に達成しなければならないという認識が生じ、それに伴う焦燥感も増大します。この焦りは周囲への苛立ちとして他者へ波及します。かつて些細だったことが巨大な障害となり、その原因を自分自身ではなく他者に求める傾向が強まります。 + +#### 全能感 + +当初はそう感じていなくても、業務量に圧倒されると「自分以外に誰もできない」という思考に陥りがちです。 + +この種の主張は、他の業務が滞る中で、過剰な努力を正当化し、それに価値を見出そうとする試みであることが多いです。制御不能になりつつある状況で、必死にコントロールを握ろうとする行為です。 + +確かに他の人もそれらの業務を遂行できます。やり方は異なり、あなたが成し遂げたほどの卓越性は伴わないかもしれませんが、常に卓越性が求められる状況ではない場合もあるのです。この種のエゴイズムは、むしろ進歩や他者の自主性を阻害する障害となることが多いです。 + +#### 認められていないという疑念 + +エネルギー不足を補うため、私たちは往々にして努力量を増やしますが、それが必ずしも良い結果に結びつくわけではありません。しかし私たちはこの事実を認めず、費やした努力だけを見てしまいます。するとチームやコミュニティ全体から評価されていないと感じ始めます。「夜遅くまで頑張っているのに、誰も気づかないのか？」この感情は苦々しさや怒りへと発展していきます。 + +#### 被害妄想 + +[評価されていない感覚から「世界が敵だ」という思いへ](#user-content-fn-12) [^12]。物事がうまくいかず、その理由が理解できない、あるいは見えない時、私たちは自分自身ではなく、たとえ非難に根拠が薄くても責める対象を探しがちです。しばしば、犯人とレッテルを貼られた人物が私たちの不満の矛先となります。それはチームメンバー、友人、あるいは家族でさえあり得ます。 + +#### 方向感覚の喪失 + +方向感覚の喪失とは、周囲の環境や状況への理解から切り離された感覚を指します。気づかないうちに置かれた状況に気づいたり、以前は理解していた概念が突然理解できなくなったりする状態です。物事を忘れやすくなり、集中力が低下することで混乱や焦燥が増幅され、妄想などの他の症状を助長します。 + +#### 心身症的症状 + +これは、バーンアウトの兆候を経験している人が身体的に病気ではないという意味ではありません。彼らは実際に身体的な不調を感じることもあります。しかし、長期にわたるストレスにより、風邪が長引く、腰痛、頭痛など、原因に対する二次的な症状として身体的な不調が現れることを強調しています。時には、これらの病気は私たちが感じるより深い感情的なストレスを覆い隠しますが、私たちは精神的なストレスを実際に認めるよりも、病欠を取る方が楽だと感じるのです。 + +## バーンアウトのサイクル + +Freudenbergerと共同研究者Gail Northは、これらの症状の結果を12段階の[バーンアウト症候群の発達過程](#user-content-fn-14)に分類しました[^13]。症状と同様に、患者は複数の段階を順不同で経験し、その期間は任意の長さとなる可能性があります。 + +1. **自己証明への強迫観念**：自己を証明し、同僚に影響を与えたいという欲求は、当初は有益に思えるが、やがて執着へと変わる。 +2. **強度の増大（より一層の努力）**：強迫観念は献身やコミットメントと誤解される。これは、完璧なコントロールを失うことを恐れて仕事を委任しない姿勢、あるいはより長くより激しく働く行動として現れる。 +3. **自身のニーズの軽視**：仕事が支配的になり、睡眠や健康的な食事など、より繊細な義務や楽しみが不要なものとして見なされるようになる。 +4. **葛藤の転移**：他者からの葛藤は干渉的で脅威と見なされる。問題を無視するための対処メカニズムが働き、これが身体的な崩壊として現れることがある。 +5. **価値観の歪み**：仕事のみに焦点を当て、価値観や人間関係が歪められる。結果としてそれらを軽視したり放棄したりするようになる。 +6. **生じつつある問題の否認**：人生の影響やそれに伴う要求から身を守るための防衛機構。曖昧さに耐えられなくなり、受容性を失う。不安や不安定感を外部に投影するようになる。 +7. **引きこもり**：感情や他者から切り離される。テレビや本、アルコール・薬物などの手段で「逃避」することが多い。 +8. **奇妙な行動変化**：友人や家族が、態度・言語・身体活動などにおける行動の変化を次第に明確に認識する。 +9. **自己疎外感**：自己や他者のニーズが著しく過小評価され、無視されるようになる。 +10. **内面の空虚感**：虚ろさや無価値感。満たされたい欲求はあるが、通常は一時的な快楽や偽りの解決策に過ぎず、結局は満たされない。 +11. **抑うつ状態**：絶望感と喜びの喪失。主要な感情は絶望と消耗であり、圧倒的な逃避欲求が伴う。 +12. **バーンアウト症候群**：自殺願望、身体的・精神的崩壊により生命を脅かす状況に至る。直ちに専門的な医療支援が必要不可欠。 + +これらの区別は、自身・チーム・コミュニティメンバーの活動状態や、自己・他者に対する態度の悪化を特定するのに役立ちます。 + +自己批判的になり、すべてが順調だという幻想を打ち破ることが重要です——通常はそうではなく、自然に解決することはありません。 + +## バーンアウトの原因 + +バーンアウトの壊滅的な影響を特定したところで、私たちの役割内、あるいはコミュニティ内でさえ、これらの症状の潜在的な原因を探ってみましょう。 + +先に述べたように、バーンアウトは多くの要因が複合的に作用しますが、繰り返し現れる要素は、無意識的かどうかに関わらず、自分の仕事が以前と同じような報酬や目的意識を与えていないという認識です[かつてそうであったように](#user-content-fn-15)[^15]。報酬とは必ずしも金銭や地位を指すわけではなく、自身の価値観に沿って行動し幸福を達成することによる深い満足感や喜びそのものを意味する場合もあります。 + +### 制御の欠如 + +達成感や業務への主体性を感じるには、それを実現する適切な自律性が求められます。意思決定に影響を与えられない、あるいは適切なツールやリソースにアクセスできない場合、自身の仕事や努力が十分に評価されていない、あるいはこの責任を十分に信頼されていないというやる気を失わせる感覚につながりかねません。 + +コントロール不足は他者の感情に対処する際にも顕在化します。メンバーにコミュニティの行動規範や紛争時の推奨行動を促し導こうとも、彼らの意思を排除することは明らかに不可能です。たとえ破滅的であろうとも、彼らの次の行動を予測するしかありません。これは常に消火活動モードに陥り、何も達成できていない感覚を生みます。 + +### 不公平感 + +役割内での不公平感は、無力感や軽視されている感覚につながる様々な要素として捉えられます。あなた自身や他者が不当に扱われる状況です。例えば、お気に入り主義の文化を生む社内・コミュニティの政治的駆け引き、トップダウン決定における透明性の欠如、あるいはあなたに割り当てられる不釣り合いな量の業務負荷などです。 + +### 報酬の不十分さ + +あなたは評価されていない、当然のことと思われている、あるいは単に自分の役割に満足していないと感じることです。報酬は必ずしも金銭的である必要はありませんが、業務量が増加した際、最初に検討対象となるのは往々にして金銭面です。 + +また、他者からの承認を得る社会的報酬も必要です。承認不足は、企業自体の価値認識不足、チームからの敬意の欠如、あるいは私たちが遂行する「舞台裏」の活動をコミュニティが見落としていることなどから生じ得ます。 + +内発的報酬も、自身の役割に対する健全な認識を維持する上で重要です。これは、良い仕事をしたという自己承認を得て達成感を感じるものです。自らの基準に達していないと感じると、失望しやる気を失い始めます。 + +時には、所属する企業やプロジェクトとの価値観の衝突から不満を感じることもあります。私たちはしばしば、企業の方針をコミュニティに伝達し、時には推進するよう求められますが、それらが自身の価値観と一致しない場合があります。これは自らの道徳観に対する裏切りと捉えられ、企業への憤りを蓄積させる可能性があります。 + +### 仕事の過負荷 + +バーンアウトの最も一般的な要因は、[自身の仕事量の過負荷](#user-content-fn-16)[^16]でしょう。これは自ら招いたものであれ、他者によるものであれ、発生します。仕事の量や期待が、利用可能な時間やリソースを超えた時に起こり得ます。実際には緊急ではない業務でも、他の社員の大半が「緊急」と認識していると錯覚することがあります。増え続ける業務リストに抵抗するためにも、境界線を保ち、自らの立場を貫くことが重要です。 + +### コミュニティの欠如 + +言うまでもなく、コミュニティは非常に重要です。それはモチベーションや仲間意識の源として、役割の目的を推進し、個人としての帰属意識をもたらします。しかし、これが停滞し、有害なメンバーに圧倒され、フィードバックが存在しない場合、仕事は息苦しく感じられるようになります。 + +## バーンアウトの予防・対処 + +自身や他者がバーンアウトに陥りつつあると感じたら、最も直接的な対処法はストレス源（多くの場合仕事そのもの）から距離を置き、[バーンアウトのより根本的な原因](#user-content-fn-17)[^17]を内省することです。 + +### 休暇を活用する + +この時間を活用することを恐れず、罪悪感も抱かないでください。休暇を取ることは職務への献身を損なうものではなく、不在中に全てが崩壊するわけでもありません。この時間を自分自身と向き合い、人生で喜びを感じることに集中するために使いましょう。 + +### 大切な人と過ごす + +燃え尽き症候群が進行する中で、おそらくあなたを恋しく思っているであろう人々との関係を再構築しましょう。自分の気持ちを話し合い、一緒に過ごす時間を楽しみ、全体として心地よい経験にしましょう。 + +人生においてネガティブな人々とは、基本的に距離を置くよう心がけましょう。これは、彼らを自分の社交圏から消すこと、あるいは彼らとの関わりを制限することを意味するかもしれません。覚えておいてください、他人の感情は私たちに良い影響も悪い影響も与えるのです。 + +### 優先順位を見直す + +自分にとって何が重要かを特定し、現在のライフスタイルやワークライフバランスがそれを反映しているかどうかを考察しましょう。もしそうでないなら、より楽しみたいことを優先し、スケジュールに時間を確保して、それにコミットしましょう。 + +また、選択肢を評価し、ストレス要因を解決するための次のステップを考えてください。これは、直属の上司と解決策や妥協点を見出し、仕事量やその他の懸念事項を減らすことかもしれません。人生から特定のストレス要因を取り除く唯一の方法は、仕事を辞めることかもしれないという時点が来るかもしれません。仕事を辞めることが唯一の解決策となる場合もあります。 + +### セルフケアを実践する + +自分が楽しみたいセルフケア活動に完全に没頭する時間を確保し、実行しましょう。可能な限り仕事から距離を置き、「自分」のための時間に専念するため、毎日セルフケアを実践することを心がけましょう。 + +### 専門家の助けを求める + +他の手段が心身の健康にほとんど効果がない場合、または緊急の支援が必要と感じた場合は、至急専門家の助けを求めてください。 + +## ワークライフバランス + +健全なワークライフバランスとは、私生活と仕事生活の間に明確な境界線を設け、一方が他方を支配しない状態を指します。両者は等しく重要であり、どちらかを軽視すべきではありません。どちらか一方の極端な状態に追い込まれると、不健全な思考パターンに陥り、人生のその部分から重要な目的意識や喜びを奪われてしまいます。 + +現代では、物理的に仕事から距離を置くことも困難になっています。テクノロジーがもたらした利便性により、私たちはほぼ常にオンライン状態にあり、オンラインコミュニティと繋がり続けています。時間帯を問わずメールを確認したり、ソーシャルメディア上のコミュニティメンバーに返信したりすることは、もはや日常的な光景です。 + +この物理的な困難に加え、仕事から切り離すことへの感情的な困難も生じます。24時間365日対応可能であることが役割の要求であり、思いやりと活発なコミュニティの反映として反応することが求められると感じるかもしれません。しかし実際にはそうではなく、持続可能なコミュニティ構築やメンバーとの質の高い交流においては逆効果です。優れたリーダーであるために、全てのメッセージに返信する必要はありません。 + +各人のワークライフバランスは異なり、優先順位もそれぞれです。ここでセルフケア活動が、仕事と私生活の境界線を確立する上で重要な役割を果たします。コミュニティのリクエストやメールへの対応、電話や会議の手配など、あなたが「仕事」とみなすものと、仕事に充てる目標時間を明確に区別しましょう。それ以外の時間は、自分自身と他者に対して「私的な時間」であると伝えましょう。一貫した明確な休息時間を確保することで、心身がそれを予期し楽しみに待つ習慣が育まれ、良い習慣の形成と維持が容易になります。 + +## 依存症 + +仕事中毒（ワーカホリズム）は、オンラインコミュニティに深く関わる誰にでも起こり得ます。彼らは長時間の労働をプロジェクトへの献身として正当化しがちです。止められない背景には、地位や成功への強迫的な欲求、あるいは感情的ストレスからの逃避が潜みます。達成感が中毒性のある「高揚感」をもたらす一方で、心身の健康を犠牲にする悪循環に陥りやすく、気づいた時には手遅れとなるケースが多いです。 + +他の依存症と同様、仕事中毒も問題の存在を認めることが難しいです。仕事中毒に苦しむ人々は往々にして否認し、仕事を快楽だと自己説得します。結局、この過剰な努力と時間の代償、人間関係や健康の軽視は、避けられない燃え尽き症候群へとつながります。 + +常に全開でペダルを踏む必要性を感じることなく、自身の役割と健全な関係を築くことが重要です。達成意欲の真の原動力を分析し、現在のオンライン時間を正当化できるか検証しましょう。外部からの称賛を仕事の価値証明として依存していませんか？コミュニティから離れると崩壊すると感じませんか？タスク完了やメンバー・上司からの称賛など「喜びの瞬間」を特定し、現在の頻度で必要か評価しましょう。 + +また、この達成欲求は、チーム内のリソース不足による過重な業務負荷への反応であり、自身の役割やチームがプロジェクトや企業にもたらす価値を他者に証明しようとするものかもしれません。 + +これらの目標を、自身の業務負荷軽減を目的に再考してください。現在のリソースで、品質や良好なワークライフバランスを犠牲にせずに達成・維持可能でしょうか？不可能であれば、チームが達成可能な最も影響力の大きい目標を優先順位付けし、共有することを検討してください。その他のタスクは適切なメンバーに委任するか、より柔軟なタイムラインを設定し、その期限内に発生する可能性のある緊急対応のための時間を組み込んでおきましょう。 + +これによりチームメンバーが達成可能な合理的な期待値を設定できるだけでなく、健全なワークライフバランスがスケジュールに組み込まれることを促進します。この予測可能なスケジュールは、会社やコミュニティへのより正確な予測提供にも役立ちます。 + +## 境界線の維持 + +ワークライフバランスを考える際、両者の間に明確な境界線を引くことが重要です。前述したように、私たちの仕事の性質上、コミュニティ活動に参加せざるを得ず、それが私的な時間を浸食し、何も残らない状態に陥りがちです。これは一時的な対応が必要な場合に限って許容できるものであり、常態化すべきではありません。境界線は、仕事の終わりと楽しみの始まりを明確にします。仕事に楽しみがないと言っているわけではありませんが、仕事以外の多様な活動を持つことで、精神が刺激され、創造性を発揮する別の場が生まれます。 + +こうした境界線は、コミュニティがあなたの期待や、あなたがコミュニティに何を提供できるかを認識し、受け入れる助けにもなります。対応可能な時間を明確に定義し、その時間外に支援を得るためのエスカレーション手順を定めることで、可能な限り透明性を保ちましょう。コミュニティのプロセスを文書化することの重要性を強調し、メンバーが支援の要否にかかわらず、発生時に取るべき行動をより明確に理解できるようにしましょう。目的は一貫したスケジュールを確立し、チームとコミュニティにそれを尊重させることです。毎回守られるとは限りませんが、境界線を設定することで、個人的な時間を自分のものとして受け入れ始め、他者を尊重する際に生じる罪悪感を防ぐ助けとなります。 + +もちろん、オフ時間中にあなたの介入を必要とする重大なインシデントが発生した場合、あなたが「対応できる唯一の人」ではなく、チームが対応できる仕組みを整えておくことが重要です。この仕組みはエスカレーションプロセスでも、チーム全体で対応し対応内容を共同でレビューする取り組みでも構いません。これにより、特にあなたの個人的な時間やメンバーのプライベートな時間を侵食する場合、全員が負担を軽減できるという意識が育まれます。 + +個人の境界線を保つことも極めて重要です。私たちの役割は、メンバーの業務負荷やチーム内の人間関係の問題を支援することですが、あらゆる対人問題や衝突を解決できるわけではないことを認識する必要があります。時には深く関与しすぎないことも必要です。 + +認めたくはないものの、特定のメンバーに心理療法が必要と感じた場合、私たちにそのスキルや義務はないことを尊重しなければなりません。会話や観察からその方向性が明らかになった場合は、医療や精神科の支援を求めるよう説得を目指しましょう。私たちの役割はメンバーを支援することですが、立場上達成できることには限界があり、それで構いません。 + +コミュニティやチーム内のメンバーに関わる状況に対処する方法を学ぶため、あなた自身とチームがメンタルヘルス研修に参加することは有益です。これにより、支援が自分の能力や責任の範囲を超える場合に、適切な対応プロセスを適用できるようになります。 + +## 持続可能性 + +持続可能性はコミュニティにとって極めて重要な目標であり、プロジェクト自体の成功に寄与する要素と見なされることが多いです。コミュニティのためのツールやプロセスを開発する際には、常にこの点を最優先に考え、コミュニティが自立し、自発的で、力を与えられた状態になることを目指すべきです。しかしこれを達成するには多くの作業が必要であり、私たちとチームが対応し続けられることを確保しなければならなりません。 + +自分たち自身やコミュニティに対して非現実的な期待を設定すると、物事は持続不可能になります。自分たちの場合、プロジェクトのタイムラインを過小評価しがちです。なぜなら、最後のハードルを乗り越える原動力となるモチベーションを見積もりの一部とみなしているからです。モチベーションは無尽蔵ではなく、外的・内的要因によって大きく変動します。モチベーションを要因として切り離すよう努めましょう。たとえプロジェクトに非常に興奮していても、それがプロジェクト完了までの期間に関する判断を曇らせてはいけません。そうしなければ、ワークライフバランスに悪影響を及ぼす可能性があります。 + +また私たちは、コミュニティ内の他者のモチベーションも誤って想定しがちです。定義上、コミュニティメンバーはボランティアであり、確かに私たちは求められる以上の貢献をしてくれる優れたメンバーに恵まれています。しかし全員に同じことを期待すべきではなく、むしろ遅延を想定し、それを予測すべきです。 + +明確な境界線を設け、作業負荷の期待値を下げ、見積もりを改善することで、現実的なスケジュールでの成果提供が可能になります。例えば、あるタスクを3倍の時間をかけずに1週間で達成できたと想像してみてください。その理由は、優先度を明確に設定したり、重要度の低いタスクはチームに委任したり（あるいは未完了の可能性を事前に伝えた）、割り当てられた時間内のみ作業したり、そしてオフライン時間を確保して精神的リソースを回復できたからです。こうした活動とプロセスの組み合わせが成功の鍵となり、継続的な報酬の授受という好循環を誘発するのです。またメンバーのバーンアウト発生確率の低減にも寄与します。 + +唯一不変なのは時間です。自らや他者に与えた報酬の内容が、時と共に変化する可能性があることを認識しておきましょう。定期的に時間を取って、自分とコミュニティの原動力となるものを振り返り、進捗を前向きに評価し、健全なワークライフバランスを可能な限り損なわずにプロジェクト目標を調整するためのリソースを評価してください。 + +## 自己内省 + +### 鏡を通して + +マネージャーやリーダーとしての重要な側面は、チームメンバーやコミュニティ全体に対して、良質で建設的なフィードバックを提供することです。上司や他のリーダー、そして直接報告を受ける人々からのフィードバックは、彼らが私たち個人や代表する活動に対して抱く認識を理解する上で極めて重要です。それは私たちの努力を真に反映しているかどうかを知るためです。 + +レトロスペクティブは、個人やチームのパフォーマンスと士気を継続的に向上させ、解決すべき問題を特定するために、ソフトウェア開発チームにおいて今やほぼ不可欠な存在です。しかし、私たちは自分自身のために、自分自身と向き合ってレトロスペクティブを行うことはあまりないことに気づきます。 + +内省とは、自らの意識的な思考や感情を検証することです。これは精神状態を指すこともあれば、霊的な意味では魂を指すこともあります。自己反省、内省、セルフケアはすべて、精神的な成長と発展に向けた前向きな方向性を促進し維持することを目的として相互に関連しています。 + +内省は、自らの行動・思考・振る舞いから得られる目的意識や幸福感を評価する上で極めて重要です。仕事は人生の大部分を占めるため、コミュニティや企業内での役割が自身の価値観と合致していることを確認すべきです。さもなければ、その役割がもたらす報酬の不十分さに次第に不満を募らせるでしょう。 + +しかしまず、自らの価値観とは何か、その役割から得られる喜びとは何か、共に働きたい人々の特性とは何かを知る必要があります。 + +これらの問いに真摯に向き合う時間を取ってください。自己認識は一夜にして得られるものではありません。得られた答えを基に、自らの行動がもたらす感情（ポジティブ・ネガティブ双方）を内省しましょう。思考を整理する手段として、日記をつけることは効果的かつ簡便な実践法です。 + +自己内省の実践は、コミュニティリーダーとして自らに課す内的な制約——無敵である必要性、自己価値の歪んだ認識、目に見える支援の欠如——により、最初は困難に感じられるかもしれません。しかし、セルフケアの一環として内省と自己反省の習慣を築くことで、感情をより制御できるようになります。長期的な目標に対する内面の明確さを得て、感情に駆られた行動ではなく、解決策に焦点を当てた活動を識別する能力が育まれるのです。 + +### インポスター症候群への対処 + +この用語は1970年代に[心理学者Dr. Pauline Clance と、Dr. Suzanne Imes ](#user-content-fn-18)[^18]によって初めて定義されました。これは、圧倒的な証拠が反証しているにもかかわらず、自分が無能であり、専門分野での成功は運や詐欺の結果に過ぎないと感じる内面の体験を指します。 + +インポスター症候群を経験する人々は、肯定的なフィードバックを過小評価したり他者の成果と自身の成果を比較したりすることで、自らの成功を内面化し受け入れることに苦労することが多いです。これは、新しい仕事を始めた時、新たな責任や役割を担った時、あるいはキャリアの中断から復帰した直後に特に頻繁に起こります。この慢性的な自己不信を補うため、私たちは遅くまで働き、先延ばしにし、あるいは不必要な方法で自身の立場を正当化しようとするようになります。 + +Dr. Valerie Youngは、有能であるために必要だと患者が信じているこうした欠陥のある思考を、以下のサブグループにさらに分類しています。 + +#### 完璧主義者 + +完璧主義とインポスター症候群は密接に関連しています。完璧主義者は、不合理なほど高い基準を達成できないと、自身の能力を疑い、現在の立場にふさわしいのかを問います。仮に目標を達成しても、常に「達成すべきだった」と考える到達不可能な目標や、「身につけるべきだった」と考える知識が存在すると感じます。 + +#### 天才主義 + +このタイプの患者は、課題を達成する天性の能力が自身の有能さと直接的に結びついていると感じています。何かを習得するのに長い時間がかかると、その成果の価値が低いと感じてしまいます。高い基準を持つだけでなく、あまり苦労せずにそれを成し遂げなければならないのです。 + +#### ソロイスト + +彼らは助けを求めることを避けます。なぜなら、そうすることで他人が自分を見ていると信じている姿——つまり詐欺師——が露呈するのを恐れるからです。独立心は良いが、二人三脚がしばしば一人より優れていることを認めなければ、平凡な結果に終わる可能性があります。 + +#### エキスパート + +このタイプのインポスター症候群を持つ人々は、その分野や役割について全てを知っているわけではないという理由で、自身の成功を軽視しがちです。こうした人々は、自分が気づいていない側面が露呈し、詐欺師として見破られることを恐れて、場違いな立場に置かれることを嫌う傾向があります。 + +#### 超人的タイプ + +通常、こうした人々は業界内の他者、特に一見成功しているように見える人々と自分を過剰に比較し、彼らに追いつこうとより長く、より懸命に働くことを自分に強います。また、外部からの評価に強く依存する傾向があります。 + +コミュニティマネージャーという役割は、テック業界内の他の職種に比べて比較的新しいものであり、確立されていないため、この分野における専門知識や文書化が不足していることから、自らの判断を容易に定義し確認することに苦労することがあります。特に、会社やプロジェクトがこれまでコミュニティマネージャーを置いたことがない場合、自分が詐欺師と見なされることをより強く意識してしまうことがあります。 + +しかし、インポスター症候群を抑え、自信を高める方法があります。 + +## 成功を祝おう + +頻繁に自らの成功を記録し、それを楽しみましょう。日記をつけることは、過去の成功と現在の成功がどのようにつながっているかを比較する良い方法です。自身の成功体験を記すだけでなく、コミュニティメンバーがスレッド投稿に寄せた反応や、同僚からの称賛など、他者からの証言も加えるとより効果的です。これにより、自分の役割で価値を提供しているという感覚が支えられ、他者からも認められていると実感できるでしょう。 + +> 「私たちは人や物に執着するのではなく、その瞬間に真実だと信じる検証されていない概念に執着している」 +> +> — Byron Katie + +## 視点を変える + +私たちは「詐欺師だと見破られる」という恐怖に阻まれますが、通常その証拠は存在しません。他者の行動を、自分の言動への直接的な因果関係と誤って解釈しがちです。これは、私たちが状況を自分自身の視点、そして自分自身の視点からのみ見ているからです。 + +自分の仕事が対象やコミュニティにもたらす価値に集中し、その成功を視覚化しましょう。良いことが起こることを想像することは、目の前の課題に取り組み、恐怖を克服するための自信と動機を与えてくれます。 + +## 進行中の作業 + +私たちは常に学び、改善し、進歩しています。成功を継続的に発展するプロジェクトと捉え、反復ごとに改良を加えましょう。そうすることで複数の成功を記録できるだけでなく、完璧主義が不可能であること、そして失敗がより良い学びの機会であることを認識する助けとなります。 + +## 支援のネットワーク + +私たちはコミュニティの力、人々を集結させる能力を理解しています。正しい方向性と——そしてたっぷりの愛情があれば——山をも動かせるのです。ではなぜ、自分自身を助けることに対して同じ考え方ができないと感じるのでしょうか？ + +ストレスの多い困難な時期——単なる悪い一日であれ、より慢性的な病気のエピソードであれ——研究によれば、強固な（規模は問わない）社会的支援ネットワークを持つことが[私たちの幸福に有益です](#user-content-fn-20)[^20]。社会的支援ネットワークがなければ孤独や孤立を感じ、それが[さらなる抑うつや不安につながる](#user-content-fn-21)可能性があります[^21]。多くの場合、自分では気づいていなくても、行動の変化を最初に察知してくれるのは、この社会的支援ネットワークなのです。 + +[社会的支援ネットワークは友人、家族、仲間で構成されます](#user-content-fn-22)[^22]。これはより形式的で処方されることが多いサポートグループとは異なりますが、社会的支援ネットワークは、ストレスに対処しセルフケアを促進するために、コミュニティやチーム構造の一部として構築できるものです。 + +良好な関係を築き、打ち明けられると感じる周囲の人々を探しましょう。ストレスを感じたり、単に不満を吐き出したい時には、安全で健全な方法で解放するために、この社会的支援ネットワークに頼るようにしてください。こうした緊張の解放は、感情の整理や意思決定の明確化を促すだけでなく、単に相手と話す楽しさによって気分を軽くしてくれます。 + +私たちが多くの時間を共に過ごすコミュニティ内の存在が、次第に社会的支援ネットワークに組み込まれていくことに気づくでしょう。そして各個人が、それぞれ異なる形で私たちの人生を支える独自の支援を提供してくれるのです。しかし同時に、私たち自身も他者への支えとなるべきだということを忘れてはいけません。 + +セルフケアの利点についてメンバーと教育や対話を重ねるほど、それが実践され他者によって奨励される可能性が高まります。これは結果として、コミュニティにより思いやりと受容の雰囲気を醸成します。教育は、セルフケアを促進する議論、 [メンタルヘルスキャンペーンの推進](#user-content-fn-23)[^23]、[コミュニティガイドライン](#user-content-fn-24)[^24]への追加、[チームメンバーの受け入れ](#user-content-fn-25)[^25]時に「業務負荷やその他の要因が健康に影響している場合はチームに相談する」旨の明記、あるいはメンタルヘルス意識向上のためのチームメンバー向け研修の実施などが挙げられます。 + +チームやコミュニティのメンバーにバーンアウトの兆候が見られたら、その人に連絡を取り、健康状態を気にかけていることを伝えましょう。支援する意思があることを明確にすれば、多くの場合、相手は前向きに応じ、[ストレス軽減に向けて協力し合う](#user-content-fn-26)[^26]でしょう。 + +ただし、ここで明確にすべき重要な点は、コミュニティメンバーの精神的ストレスが自身の役割の範囲を超えて支援できないと判断した場合、直ちに専門的な健康相談を受けるよう促すことです。支援を提供できないことに罪悪感を抱くかもしれませんが、[私たちは専門的な訓練を受けていない](#user-content-fn-27)[^27]ため、善意であっても誤った助言を与える可能性があることを自覚する必要があります。他の感情が周囲に影響を与えること、特にメンバーのストレスが私たち自身のストレスに影響しうることを忘れないでください。 + +同様に、直属の部下との1対1の面談と同様に、自身の直属の上司とも定期的に1対1の面談を持ち、業務量の達成や自身のウェルビーイングに影響する問題点を共有しましょう。他者を助けるのと同じように、自分自身に対しても率直でありましょう。 + +## リソース + +* **ハイオクタン・ウーマン：超達成者が燃え尽き症候群を回避する方法** + 著者：_Sherrie Bourg Carter Psy.D_ +* [燃え尽き症候群、最初の10のステップ](https://www.theburnoutproject.com.au/product/burnoutbookpaperback/) + 著者：_Amy Imms M.D_ +* **バーンアウト：高業績の代償** + 著者：_Dr Herbert Freudenberger and Geraldine Richelson_ +* **女性のバーンアウト：見分け方、回復法、予防法** + 著者：_Dr Herbert Freudenberger and Dr Gail North_ +* **成功する女性の心の内** + 著者： _Dr Valerie Young_ +* **高業績女性のインポスター現象：力学と治療的介入** + 著者： _Dr Pauline Clance and Dr Suzanne Imes_ + +[^1]: 世界保健機関、[ウェブサイト](https://www.who.int/news-room/fact-sheets/detail/self-care-health-interventions) +[^2]: ザ・コミュニティ・ラウンドテーブル, [2019年コミュニティ管理実態調査](https://communityroundtable.com/state-of-community-management/burn-out-risk-is-high-for-online-community-managers/) +[^3]: シェリー・バーグ・カーター博士（心理学）、[感情は伝染する - 付き合う相手を賢く選ぼう](https://www.psychologytoday.com/us/blog/high-octane-women/201210/emotions-are-contagious-choose-your-company-wisely) +[^4]: ソーシャル心理学の原則、[感情の役割：気分と感情](https://opentextbc.ca/socialpsychology/chapter/the-role-of-affect-moods-and-emotions/) +[^5]: Alex Budak, [主導型リーダーシップ vs. 従属型リーダーシップ](https://www.huffpost.com/entry/in-control-vs-under-control-leadership_b_12590650) +[^6]: Psychology Today , [なぜ私たちは自分と似た人を好むのか？](https://www.psychologytoday.com/gb/blog/close-encounters/201812/why-do-we-people-who-are-similar-us) +[^7]: 世界保健機関、[ウェブサイト](https://www.who.int/mental_health/evidence/burn-out/en/) +[^8]: ハーバート・J・フロイデンバーガー、[スタッフのバーンアウト](https://spssi.onlinelibrary.wiley.com/doi/abs/10.1111/j.1540-4560.1974.tb00706.x) +[^9]: Team Blind, [調査対象のテック労働者の約60％がバーンアウト状態](https://www.teamblind.com/blog/ index.php/2018/05/29/close-to-60-percent-of-surveyed-tech-workers-are-burnt-out-credit-karma-tops-the-list-for-most-employees-suffering-from-burnout/) +[^10]: ハーバート・フロイデンベルガー博士とジェラルディン・リチェルソン著『バーンアウト：高業績の代償』 +[^11]: マスラック, C., & ライター, M. P. (2008), [職務バーンアウトとエンゲージメントの早期予測因子. 応用心理学ジャーナル, 93(3), 498–512](https://doi.apa.org/doi/10.1037/0021-9010.93.3.498) +[^12]: R Bianchi, L Janin [バーンアウト、抑うつ、および妄想的思考：クラスター分析による研究](https://academic.oup.com/occmed/article/69/1/35/5151234) +[^13]: ハーバート・フロイデンベルガー博士とゲイル・ノース博士、「女性のバーンアウト：その見分け方、回復法、予防法」 +[^14]: フロイデンベルガーの12段階、[フロイデンベルガーの12段階](https://www.burnoutgeese.com/freudenberger-burnout.html) +[^15]: Adeva [テクノロジー業界における従業員のバーンアウトの原因](https://adevait.com/blog/workplace/burnout-tech-industry#2-what-causes-employee-burnout-in-the-tech-industry) +[^16]: アメリカストレス研究所: 調査、[AIS職場ストレス調査](https://www.stress.org/workplace-stress) +[^17]: サイコロジー・トゥデイ、[人生の意味を見失うとき：高業績の代償](https://www.psychologytoday.com/us/blog/high-octane-women/201109/when-life-loses-its-meaning-the-heavy-price-high-achievement) +[^18]: ポーリン・クランス博士とスザンヌ・アイムズ博士、「高業績女性のインポスター現象：ダイナミクスと治療的介入」 +[^19]: ヴァレリー・ヤング博士「成功した女性の秘めた思い」 +[^20]: アメリカ心理学会「ストレス管理：支援ネットワークの強化」(https://www.apa.org/topics/manage-stress-social-support) +[^21] : Siv Grav, Ove Hellzèn, Ulla Romild, Eystein Stordal, [一般人口における社会的支援とうつ病の関連性：HUNT研究（横断調査）](https://onlinelibrary.wiley.com/doi/abs/10.1111/j.1365-2702.2011.03868.x) +[^22]: メイヨークリニック, [社会的支援：ストレス克服のツールとして活用しよう](https://www.mayoclinic.org/healthy-lifestyle/stress-management/in-depth/social-support/art-20044445) +[^23]: メンタルヘルス財団 [メンタルヘルス啓発週間](https://www.mentalhealth.org.uk/campaigns/mental-health-awareness-week) +[^24]: Ubuntu [Ubuntu Burnout](https://wiki.ubuntu.com/BuildingCommunity/Burnout/) +[^25]: Ubuntu Burnout Help, [Ubuntu Burnout Hehelp](https://wiki.ubuntu.com/BuildingCommunity/Burnout/Help) +[^26]: ジョノ・ベーコン, _バーンアウトの検知と治療_, 「コミュニティの芸術」 +[^27]: 公認経営学会 [職場でうつ病について話す方法](https://www.managers.org.uk/insights/news/2019/september/how-to-talk-about-depression-at-work) diff --git a/l10n/ja/growing-contributors/constructing-an-onboarding-experience.md b/l10n/ja/growing-contributors/constructing-an-onboarding-experience.md new file mode 100644 index 00000000..3c698db2 --- /dev/null +++ b/l10n/ja/growing-contributors/constructing-an-onboarding-experience.md @@ -0,0 +1,110 @@ +--- +description: +author: Ray Paik , Bryan Behrenshausen , Brian Proffitt +updated: +translated-by: Ken Komazawa powered by DeepL Pro +--- + +# オンボーディング体験の構築 + +貢献者の存在は、あらゆるオープンソースプロジェクトの生命線です。新規参加者を継続的に迎え入れないプロジェクトは、停滞したり、さらに悪い場合には崩壊したりする可能性があります。 + +したがって、長期的な持続可能性を求めるオープンソースプロジェクトは、新規貢献者とどのようにつながり、迎え入れ、慣れさせるか——つまり「オンボーディング」の方法——について真剣に考えるべきです。よく設計されたオンボーディングプロセスは、参加者がプロジェクトに貢献するのを容易にし、貢献者ができるだけ早くプロジェクトに良い影響を与えられるようにします。 + +本章では、コミュニティにおけるオンボーディング体験の重要性について議論し、プロジェクトの持続可能性向上に寄与する可能性のある一般的なオンボーディングリソースや実践例を検討します。 + +## オンボーディング体験の重要性 + +多くの点で、新しいオープンソースコミュニティでのオンボーディング体験は、新しい職場での体験とよく似ています。 + +例えば、新しい役職（あるいは全く新しい組織）での仕事を始めるとき、新しい人々、新しいツール、新しいプロセス、新しい規範、新しい方針などに慣れる必要があります。そして、組織に自分の価値を示し、新しい環境に慣れ、最高の仕事ができるようになりたいという思いから、これらのことを素早く行いたいと強く感じるでしょう。影響を与えていると感じるスピードが速ければ速いほど、その場に留まり続ける可能性が高まります。そして満足度も向上するでしょう。 + +しかし同時に、あなたは長い歴史を持つチームに加わるかもしれません——共有された規範や習慣、内輪のジョーク、専門用語、暗黙の了解、共有された絆、そして集団としてのアイデンティティが存在するチームです。要するに、新しいチームや組織には、あなたが加わる以前から存在していた文化があるのです。この文化の側面は主に形のないものですが、他者との協働能力に大きく影響します。効果的なオンボーディング体験は、この文化を理解する力を身につけさせてくれます。 + +オープンソースコミュニティにおけるオンボーディング体験においても、この点は変わりません。特にオープンソースコミュニティでは、次のようなオンボーディング上の課題が生じます。 + +**非同期かつリモートの環境** + +従来のオフィス環境の大きな利点は、同僚や管理者と物理的に近く、対面でのやり取りが可能で、簡単な質問のためにすぐに彼らを見つけられることです。これに対し、新しいオープンソースコミュニティに参加すると、地理的・時間帯的に異なるメンバーと協働することになります。そのため、ドキュメント、動画チュートリアル、Wikiページなどの優れたオンボーディング資料がなければ、経験豊富な自発的な人材であっても、オープンソースコミュニティでのスタートはより困難になるでしょう。 + +**インポスター症候群** + +リアルタイムの支援やフィードバックが得にくい環境では、単純なツールの問題で足止めされやすく、自身の仕事に対する自信を失いがちです。したがって、オープンソースコミュニティにおける良好なオンボーディング体験は、新規参加者が初期段階で挫折感を抱かないために極めて重要です。 + +**大きな差異性** + +オープンソースコミュニティは一つとして同じものはありません。経験豊富な貢献者であっても、新しいコミュニティに参加する際には、新たなツール、プロセス、さらには用語に慣れる必要があります。コミュニティによっては、「貢献」「コミュニティメンバー」「プロジェクト」「アップストリーム」といった一見単純な用語でさえ、微妙に異なる意味を持ち、新規メンバーを容易に混乱させることがあります。 + +## オンボーディングの基本 + +プロジェクトのオンボーディングプロセスと体験を最も効果的にするために、以下の質問を自問してください。 + +* プロジェクトに人々はどのような貢献ができるか？ +* プロジェクトへの貢献はどこで行うか？ +* プロジェクトへの貢献方法は何か？ + +プロジェクトのオンボーディングプロセスに関する最初の質問に答えるには、かなりの作業が必要です。新規貢献者は、自分たちが最も役立つ貢献として何ができるのかを知る必要があります。多くのプロジェクトでは、ソースコードリポジトリに「初回の貢献者」などのタグ付けを設定しており、これは新規貢献者を問題解決やバグ修正に導くと同時に、プロジェクトのソース素材を紹介する優れた方法です。 + +二つ目の質問——「どこで貢献するか」——については、プロジェクトが想定しているほど頻繁に提示されていません。ベテラン開発者は「必要な情報はフォーラムにある」「詳細が欲しければWikiを読め」と軽くあしらいがちです。しかし、具体的にどのリポジトリに資料があるのでしょうか？どの組織の下にあるのでしょうか？類似名称の他のプロジェクトはどうなるのでしょうか？新規貢献者がプロジェクトに影響を与えられる場所への明確なリンクを、プロジェクトウェブサイトに必ず掲載してください。これらのリンクは埋もれてはいけません。可能であればホームページに直接配置すべきです。 + +三つ目は「貢献方法」の問題です。プロジェクトがソースコードを公開し、容易に発見できる状態にしているのに…　それだけで終わっているケースが多すぎます。この手法を「壁越しに投げつける」と表現する人もいますが、これは決して褒め言葉ではありません。多くのプロジェクトがコードやコンテンツを公の場へ公開し「誰でも参加可能」と宣言しながら、なぜ貢献者が集まらないのかと首をかしげるのです。これは、プロジェクトへの貢献を促すためのドキュメントや手順が不足しているという、参入障壁が実際に存在するためです。 + +次に、これらの障壁を取り除き、プロジェクトのオンボーディングプロセスを効率化するために活用できるリソースと実践方法について議論しましょう。 + +## オンボーディングリソース + +非同期環境で効果的に作業するための重要なツール（および実践）は、優れたドキュメントです。貢献者は通常、即座に助言をくれるコミュニティメンバーが近くにいないため、重要なコミュニティの規範、決定事項、プロセスは、従来型の職場環境よりもはるかに詳細に文書化されている必要があります。ランディングページ、プロジェクトドキュメント、Wikiページなど、優れた参照資料は、新規コミュニティメンバーがコミュニティに慣れ、活動を始めるために不可欠です。また、オンボーディング文書が最新状態であり、コミュニティ活動の最新の状況を反映していることを保証することも重要です。そのため、誰もが簡単に内容を最新の状態に保てるようにする必要があります。使いやすいドキュメントツールは確かにこれを助けますが、より重要なのは、信頼性が高く更新されたドキュメントの必要性を全員に認識させるコミュニティ文化を育むことです。 + +当然に思えるかもしれませんが、オンボーディングのもう一つの重要なリソースは他のコミュニティメンバーです。同じオフィスにいない場合でも、経験豊富なメンバーが新規参加者のサポートや質問対応を行うことで、初期段階の孤立感を和らげられます。比較的新しく小規模なコミュニティでは、ウェルカムコールに参加できるオンボーディングバディのようなシンプルな仕組みで十分かもしれません。大規模で確立されたコミュニティでは、オンボーディングに特化したワーキンググループや、コーチやメンターといった正式な肩書きを持つメンバーが存在する場合もあります。 + +オンボーディングリソースが整ったら、この情報（特に支援を求める連絡先）を複数箇所に掲示し、参加者が気軽にオンボーディングリソースに連絡し、質問を促されるようにする必要があります。支援を得るのが困難だと、新規参加者はコミュニティへの関与をためらうようになり、結局このコミュニティは自分には合わないと決めつけてしまうかもしれません。 + +オンボーディング仲間、メンター、ワーキンググループなど形態は問わず、特にコミュニティが成長するにつれて、ボランティアがオンボーディング活動で燃え尽きないように、十分な人数を確保することが重要です。重要なのは、コミュニティ内に「全員が新規メンバーを歓迎する」という文化を醸成することです。理想的には、コーチやメンターといった正式な肩書がなくても、多くの人が自発的に他者を支援する姿が見られるべきです。オンボーディングワーキンググループやメンター制度などの正式プログラムを設ける場合、コミュニティメンバーが公式リソースになるための参入障壁を高く設定すべきではありません。最も重要な資格は、コミュニティでの在籍期間やプロジェクトの技術的専門性といった要素ではなく、他者を支援しようとする意欲であるべきです。オンボーディングを支援する人々が全ての答えを持っている必要はありません。むしろ、新規参加者がより早く答えを見つけられるよう支援し、単独で作業しないことが求められます。 + +## オンボーディングの実践 + +新しいコミュニティに参加した人々は、メーリングリストやSlackなどのコミュニケーションチャネルでの議論を追うことに圧倒されるかもしれません。こうした混乱やストレスを軽減するため、新規メンバーが慣れるまでの間、専用スペースを設けることを検討してください。例えば「はじめに」や「自己紹介」といった専用チャンネルは、初心者が安心して質問できる場となります。経験豊富なメンバーも、新規メンバーの質問に答えたり、励ましたりする形でオンボーディングを支援できます。こうした取り組みは、新規メンバーが歓迎されていると感じながらスタートを切る上で非常に有効です。 + +新規メンバーがオープンソースプロジェクトへの貢献を始める準備が整い、ある程度慣れた段階で次に浮かぶ疑問は「どこに貢献できるのか？」です。 + +そのため、新規メンバーがすぐに始められるよう、特に新規メンバーが取り組める作業項目の一覧を作成することをお勧めします。多くのコミュニティでは、イシュートラッカー上で「初回の貢献者に最適」「初めてのイシューに最適」「協力者募集」といったラベルを付け、新参者がすぐに貢献できるタスクを容易に識別できるようにしています。これらのラベルが付いたイシューには、ドキュメントの誤り修正、簡単なバグ修正、その他の単純なタスクが含まれ、新規貢献者が早期の成功体験を得て自信を築くのに役立ちます。これらの課題には、メンターやコーチとして機能する連絡先（複数可）を記載しておくことも有効です（参加者が開始時に支援を必要とする場合に備えて）。常に留意すべき点は、経験豊富なコミュニティメンバーにとって単純に見える課題も、新規参加者にとってはそうではない可能性があるということです。 + +多くのオープンソースコミュニティは、メンバー間の交流を目的としたイベントを開催しています。対面式であれオンラインであれ、こうしたイベントはコミュニティメンバーがリアルタイムで協働し、その過程で互いを知る絶好の機会を提供します。サミット、ハッカソン、ユーザーカンファレンスなどが該当します。こうしたイベントでは、新規メンバー向けの特別プログラムやスペースを設けることを検討してください。予算が許せば「Day 0」イベントとして正式なオリエンテーションを実施したり、昼食会形式で新規メンバーが他のコミュニティメンバーと交流できる場を設けることで、後で質問できる相手を事前に把握できるようにします。 + +### 貢献者育成パス + +新規貢献者がプロジェクトへの初期貢献を終えると、より大きな影響を与える方法を模索し始めます。そのためには、自身の専門スキルや才能をプロジェクトに活かせる道を探すことが多いでしょう。 + +ボランティアがオープンソースプロジェクトに独自の才能を提供し始める機会は、そのプロジェクトの「貢献者育成パス」と呼ばれます。プロジェクトが提供する貢献者経路の数が多いほど、プロジェクトの成功に必要な多様なスキルを持つ参加者を募集できる可能性が高まります。 + +プロジェクトごとに固有の貢献者経路は様々ですが、これらの経路は一般的に二つの基本カテゴリーに分類されます。一つは、コミュニティに焦点を当てた経路と、もう一つは、技術に焦点を当てた経路です。 + +*コミュニティに焦点を当てた*経路は、参加者側に専門的な技術知識を必要としない貢献の機会です。これらは、新規貢献者がプロジェクトの文書化、認知度向上やマーケティング、コミュニティミーティングやイベントの企画などを支援することに焦点を当てた経路であり、これらはすべてプロジェクトの最終的な成功にとって極めて重要な側面です。例としては以下が挙げられます。 + +1. ワークフローとガバナンスプロセスの文書化 +2. 新規メンバーの受け入れとメンタリング +3. コンテンツの多言語化 +4. コピーライティング（ウェブサイト、ニュースレター、ブログ向け） +5. ソーシャルメディアの管理 +6. イベントの企画・運営 + +*技術的焦点*の貢献経路は、ソフトウェア開発（特定のプログラミング言語を含む）の専門知識を必要とする貢献です。これらはコミュニティが維持するソフトウェア本体を強化・洗練させることに焦点を当てています。例は以下の通りです。 + +1. 新機能とドキュメントの追加 +2. 既存バグの修正と課題の優先順位付け +3. 既存作業のリファクタリングによる改善 +4. 品質保証の実施 +5. ユーザーインターフェースとユーザーエクスペリエンスの改善 +6. リリースエンジニアリング +7. プロジェクトロードマップの作成と維持 +8. コードとユーザーインターフェースのローカライズ + +プロジェクトの貢献者向け経路を評価する際、自問してください。あなたのプロジェクトは現在、新規（および既存）の貢献者がこれらの各領域でやりがいのある貢献（あるいは所有権の取得）を行う機会を提供していますか？そうでない場合、プロジェクトを拡大する一般的な方法の一つは、これらの貢献者パスを体系化し、洗練させ、文書化し、周知する取り組みを集中的に行うことです。 + +これらを「パス」と呼ぶのは、参加者がコミュニティへの関与を*段階的に*深められるためです。これにより、負担を感じることなく、プロジェクトのプロセスや文化に慣れながら、より深く関わるようになるのです。理想的には、コミュニティが成熟するにつれ、貢献者に段階的に責任と権限を付与する経路が構築されます。例えば、イベント関連の貢献経路を辿る貢献者は、コミュニティのフラッグシップとなる年次イベントの単独責任者として始めることはないでしょう。しかし、経験豊富なコミュニティメンバーと共にそのイベントの計画に携わり、会場確保、宣伝、登録業務などを担当する可能性はあります。 + +## リソース：オープンソースコミュニティのオンボーディング事例 + +1. [OpenStack Upstream Institute](https://docs.openstack.org/upstream-training/) +2. [Kubernetes Contributor Experience Special Interest Group](https://github.com/kubernetes/community/tree/master/sig-contributor-experience) +3. [GitLab Merge Request Coach](https://about.gitlab.com/job-families/expert/merge-request-coach/) diff --git a/l10n/ja/growing-contributors/creating-a-culture-of-mentorship.md b/l10n/ja/growing-contributors/creating-a-culture-of-mentorship.md new file mode 100644 index 00000000..2346cf4b --- /dev/null +++ b/l10n/ja/growing-contributors/creating-a-culture-of-mentorship.md @@ -0,0 +1,237 @@ +--- +description: +author: Karsten Wade , Guedis Cardenas +updated: 2020-12-14 +translated-by: Ken Komazawa powered by DeepL Pro +--- + +# メンターシップ文化の醸成 + +本章では、持続可能なプロジェクトとコミュニティの構築を目指すオープンソースメンテナにとって重要な概念であるメンターシップについて論じます。メンタリングとは何か、なぜ重要なのか、そしてオープンソースコミュニティでメンターシップ文化を育むための第一歩をどのように踏み出すかを考察します。 + +## メンターシップとは何か + +メンターシップの意味は、状況・文脈・文化などによって人それぞれ異なります。例えば、スケジュールや議題を伴う正式な活動と捉える人もいれば、仲間同士の非公式なプロセス、あるいは単発の会話と捉える人もいます。「メンターシップ」を定義するよう求めれば、おそらく多様な回答が返ってくるでしょう。 + +この普遍性と個別性の両面こそが、メンターシップを重要かつ強力な概念にしているのです。誰にとっても有益な経験となり得る普遍性を持ちつつ、個人や関係性ごとに異なる形で現れる個別性を併せ持つのです。 + +したがって、メンターシップを次のように捉える方法があります。 + +> メンターシップとは、できる時に、できる方法で、できることを分かち合う行為であり、経験であり、機会である。 + +メンターシップは重要です。それはあなた自身を助け、他者を助け、コミュニティを助け、オープンソースプロジェクトを助けます。 + +### あなた自身を助ける + +メンタリングは個人的にやりがいのある経験となり得ます。あなたが提供する支援や指導は、価値ある持続的な恩恵をもたらします。例えば、 + +* 還元する喜びというポジティブな感情を経験する +* 自分自身についてより深く知る +* 自身の思考における知識の空白を見つける +* 新しいことを学ぶ +* 世界観を広げる +* 新しい友人、協力者、支援者を得る +* その他 + +### 他者の助けとなる + +メンターシップは、キャリアの異なる段階や様々な生活状況にある貢献者を支えます。特定のプロジェクトや取り組みの中で、プロジェクトへの参加初期段階において、また教育やキャリアの成長・発展過程において、メンターシップは（大小さまざまな、しかし等しく価値ある）ポジティブな影響を与える可能性を秘めています。 + +### コミュニティへの貢献 + +メンターシップはコミュニティの結束力とアイデンティティに累積的な効果をもたらします。一人のメンターがもう一人を導くことから始まりますが、そのメンティーがさらに別の誰かを導くことで、ポジティブな波及効果が継続します。助けや助言が必要な時に、あなた自身に返ってくる「助けのブーメラン」のようなものになる可能性さえあります。 +規模が大きくなれば、より包括的で協力的、助け合いと革新に満ちたコミュニティ形成に貢献します。 + +### プロジェクトへの貢献 + +メンターシップの文化——あるいは特定のメンター制度——を構築することは、オープンソースプロジェクトの長期的な健全性にとって重要かつ価値あることです。この章の残りの部分では、その具体的な利点について論じます。 + +## メンターシップの形態とスタイル + +メンターシップとは、できる時に、できる方法で、できることを共有する行為・経験・機会であることを思い出してください。 + +オープンソースプロジェクトでは、これは様々な形で現れます。非公式、公式、ピアツーピア、メンターからメンティーへ、その他のバリエーションなどです。関係性のダイナミクスも異なり、一対一、一対多、多対多などがあります。コミュニケーションの方法やタイミングも、非同期や同期など様々です。質問の種類や回答内容も、メンタリングの進め方に影響を与えます。 + +もう一つ留意すべき点は、人々がどのようにメンタリングを行い、どのような役割を担うかです。以下にいくつかのスタイルを示します（網羅的なリストではありません。他にも多数存在します）。 + +**教育者** + +* 概念やアイデアなどを教え、情報を提供する +* 内容を説明し明確化する +* 知識と経験を共有する + +**励まし役** + +* 励ましを与える +* 進捗や成果を思い出させる +* 素晴らしい仕事を続ける潜在能力を育む + +**傾聴者** + +* 答えや指導を提供するだけでなく、積極的に耳を傾ける +* 連帯感を示し、相手の声が聞かれていることを認める + +**発見者／調査者** + +* 洞察をもたらす質問・リソース・人物を発見する + +**繋ぎ手** + +* 記事・書籍・メディア・イベント・プログラムなどのリソースを共有する。人々を互いに紹介する + +要約すると、メンタリングは従来の指導提供を超えた形でも有益であることを認識することが重要です。メンタリングには様々な方法があり、それによって貢献者、オープンソースプロジェクト、コミュニティに価値ある持続的な利益をもたらします。 + +## 新規貢献者のメンタリング + +成功するオープンソースコミュニティの立ち上げや成長には、持続可能な設計が不可欠です。つまりプロジェクトは、新規参加者を確実に繰り返し迎え入れ、継続的な貢献者へと育成できる体制が必要です。コミュニティの持続可能性を実現する上で、新規貢献者のメンタリングがいかに重要かについて考察しましょう。 + +もしこれがあなたのプロジェクトにおける持続可能性の定義に合致するなら、メンタリングプログラムは絶対に不可欠です。これは「3人で全てを知り、全てを行う」状態から、多くの人が自律的に貢献できるプロジェクトへと発展させる中核的な手法なのです。 + +メンタリングプログラムにおいて自律性は重要な焦点です。そして「人を指導する」状態から「メンタリングプログラム」が偶然生まれるとは考えないでください。論拠は以下の通りです。 + +1. 新規参加者を呼び込むために、プロジェクトへの参入障壁を下げるのが重要だと合意できる場合、かつ +2. 新規参加者が、質問や学習を許可され、むしろ奨励されていると感じられる相手（1人以上）の存在から恩恵を受けると合意できる場合、かつ +3. 新規参加者が既存メンバーと精彩を欠いた、あるいは否定的な交流を持つと、その新規参加者を追い出す可能性が高いと合意できる場合、かつ +4. 新規参加者が頼れる人物（メンターや友人）の存在が、離脱防止、特に*無言のセグメンテーションフォルト*（説明なく消える現象）を防ぐ手段であることに同意できる場合、 +5. わずかな反復可能なプロセス支援を伴うメンタリングが、場当たり的なプロセスよりも優れた満足度の高い結果をもたらすことが理解できるでしょう。 + +たとえ簡易的なプログラムでもアドホックなプロセスより優れていると合意できれば、正しい方向へ進んでいます。この認識のもと、メンタリングプログラムに必ず組み込むべき要素を以下に示します。 + +### 文書化された反復プロセス + +簡易的であっても文書化し、初期段階から試行します。 + +最初の6か月程度は、少数のボランティアにプログラムを試してもらいます。これによりプロセスの不具合を解消する時間が得られ、プログラムを本格化させる際に追加メンターを募る基盤が整います。 + +プロセスを1～2回試行・検証したら、プロジェクトサイトに「メンタリング」セクションを設置し、プログラム全要素へのリンクを掲載してください。プロジェクトへの関与を少しでも考えている人が、新規貢献者としてどのようにサポートされるかを事前に確認できるようにしてください。 + +各メンタリング期間（下記「時間的コミットメント」参照）終了後には振り返りを行い、期間中の学びを活かしプロセスを反復的に改善しましょう。 + +単に「地図と道案内がある」と約束するだけでなく、実際の地図と道案内の構想を示すことです。 + +### メンター向けガイドラインと行動規範 + +メンタリング経験が豊富な人でも、メンタリングの方法やメンティー（指導対象者）との関わり方、メンタリング倫理などに関するガイドラインは有益です。 + +メンタリングプログラム作成時の詳細な参考資料として、[上流プロジェクトのメンタリングガイド](https://www.mentorship.guide/)があります。このプロジェクトの資料を活用して、自プロジェクトに必要な要素を作成できます。 + +メンターは特別な信頼関係を担う役割です——プロジェクトはメンターがコミュニティを代表すると信頼し、メンティー（指導対象者）はメンターが正しい道へ導くと信頼します。メンターは適切な基準で行動する必要があり、その基準への責任を問う仕組みや、メンターの行動上の問題・不正を報告する手段が必須です。このような行動規範は、メンタリングプログラムを閲覧する全ての人々に対して、事前に明確かつ目立つ形で提示される必要があります。 + +メンター向けの行動規範が存在しない、あるいは見つけにくい状態は、新規貢献者候補に対して「このプロジェクトは避けるべき」という警告信号となります。 + +プロジェクトに既存の行動規範がある場合は、それがメンタリングプログラムを十分にカバーしていることを確認し、全参加者がその存在を認識していることを確認してください。 + +### メンターが新たなメンターを育てる + +少数のメンターを集めてメンタリングプログラムを開始することは一つの手段です。しかし持続可能なプログラムとするには、メンターを集めるだけでなく、新たなメンターを育成する仕組みが必要です。 + +核心となる考え方は、メンター自身が「メンターとしての在り方」を明示的に、そして模範を示すことで教える環境を整えることです。メンターは常に、全体的な視点と具体的な場面において「この人が他の貢献者をメンタリングする成功をどう支援できるか」を考えるべきです。そうすることで、メンティーとして良い経験をした人々が新たなメンターとなり、自身のメンタリング活動もさらに促進されます。 + +適切にメンタリングされた新規貢献者は、すぐに他の貢献者（新規・既存問わず）に同様のメンタリングレッスンを提供できます。その日のうちにさえ可能です。 + +新規貢献者の質問に答える際、その回答方法こそがメンタリングの本質です。回答の仕方次第で、その新規貢献者は新たに得た知識を自信を持って共有できるようになります。伝えられた内容だけでなく、伝え方そのものから教訓を得た場合、彼らはこのシンプルなメンタリングの教訓をプロジェクト内のあらゆる交流で実践していくのです。 + +### メンティーのための簡易規範 + +メンターとは異なり、メンティーには最小限の要求と負担を課すことが望ましいです。 + +これはメンタリングプログラムのウェブページで明確に示すべき情報であり、以下を含みます。 + +* 当プロジェクトにおけるメンターの探し方・アプローチ方法 +* メンティーに求められる作業量・労力の目安 +* 関係の明確化（例：メンターは友人関係ではないこと、メンタリングには期間制限（6ヶ月等）があるか、終了条件が設定されていること、メンターはボランティアであり同等の敬意を払うべきこと、メンターは行動規範を遵守し、メンティーもこれを理解・順守すべきことなど） +* 当該プロジェクトにおける標準的なメンター/メンティー関係の具体例 + +メンティーが期待される役割を理解しつつ、技術面から文化面までプロジェクトの規範に対する理解を深める余地をメンターに与える、そのバランスが求められます。 + +### メンタリングプログラムを統括する担当者（個人またはグループ） + +参加者の行き詰まり、メンターの離脱、行動規範違反などあらゆる事態に対応するため、明確な連絡先となる担当者（複数可）が必要です。 + +この連絡先情報とその目的は、メンタリングプログラムのウェブページで目立つように掲載すべきです。 + +このグループは、特定のトピックに関してプライバシーを保持し、透明性への障壁が明確に理解されている、プロジェクト内でも稀な領域の一つとなります。メンターは他のメンターと相談して指導を求める必要がありますが、このグループはそのための非公開の場を提供できます。また、発生する可能性のある機密事項の対応にも役立ちます。 + +このグループまたは役割のガバナンスには、プロジェクト最高責任者層への明確かつ簡潔なエスカレーション経路が必要です。 + +### メンター向けの合理的時間・労力コミットメント計画 + +メンタリング関係は数年続くこともあれば、週末で完結することもあります。リリーススケジュールや、主催する特定のカンファレンス・イベントなど他のリズムに連動した、合理的なスケジュールを設定しましょう。 + +一部のプロジェクトの経験では、6か月のコミットメントが効果的です。これは相互理解を深め、メンターとしての支援方法／メンティーとしての支援の受け方を話し合い、さらに中盤の数か月でメンティーが実際の活動に対するフィードバックを得るのに十分な期間です。 + +特に新規プロジェクトでは、メンターを惹きつけることが重要です。時間的・労力的負担が大きすぎたり、メンタリングの明確な終了条件が示されていない場合、多くの潜在的なメンターは参加を躊躇し、プログラム自体に関心を示さなくなります。 + +時間と労力のコミットメントを曖昧にすることは、プロジェクトに「メンター忌避剤」を撒くようなものです。参加者が何に取り組むのかを明確に示せば、メンタリングプログラムは成功への道を歩み始めます。 + +## 新人コミュニティマネージャーのメンタリング + +このセクションは、コミュニティマネージャーが集まり、メンタリングや新人コミュニティマネージャーに関する経験を話し合った会議を参考にしています。 + +オープンソースの初期には、プロジェクトにコミュニティマネージャーは存在しませんでした。開発者間の協力は当然の前提であり、運が良ければ、コミュニティ内でソフトウェア開発以外のタスク（インフラの管理、イベントの企画、マーケティングチームの統率など）を喜んで引き受ける人々がいました。オープンソースが成熟するにつれ、大企業内部から生まれるプロジェクトが急増し、こうした状況はもはや当然ではなくなりました。企業内部で「コミュニティマネージャー」や「コミュニティアーキテクト」として任命される人材が増加し、プロジェクトが協働的なマルチベンダー活動として円滑に運営されるよう責任を負っています。 + +コミュニティマネージャーの役割について多くの議論がなされてきましたが、確かなのはプロジェクトが進化するにつれ、その役割も進化するということです。 + +プロジェクトのライフサイクルにおいて、初代コミュニティマネージャーが去る時が来るかもしれません——別の仕事へ、プロジェクト内での別の役割へ、あるいは単に生活上の理由で一歩引いていく場合もあります。 + +こうした移行期に、プロジェクト内で新たなコミュニティマネージャーが台頭することがあります。 + +この時期、退任するコミュニティマネージャーとして、飛び込んで新任者を支援し、業務に慣れさせようとする誘惑に駆られるかもしれません。しかしそのリスクは、新任者がその役割を自らのものにする機会を奪ってしまうことです。新任者は、最も重要な業務に対する認識も異なり、プロジェクトに活かせるスキルセットも異なるはずです。 + +メンターとして重要なのは、情報源として関わりつつ、関連する歴史を共有し、これまでの手法を伝えることとのバランスを取ることです。 + +経験豊富なコミュニティマネージャーが新人を効果的に指導する最善の方法は何でしょうか？ 彼らが成功できるよう支援しつつ、たとえ途中で失敗する可能性があっても、新しいことを試す貴重な余地を与えるにはどうすればよいでしょうか？ 役割の範囲を示すことと、彼らが適切と考える方法で役割を定義させることのバランスをどう取りますか？ + +### 航路を定める + +新たな役割に就く際に最も有用なのは、共に働く人々のリストです。 + +支援可能なステークホルダーや、コミュニティ目標に懸念を持つ協力者がいる場合、この情報は新任者が落とし穴や失態を回避する助けとなります。 + +前任のコミュニティマネージャーとして、後任のためにできる最も価値あることの一つは、自分が関わってきた人々を紹介し、引継ぎを円滑にすることです。これにより、後任が「自分が誰で、なぜ予期せぬ場所に現れたのか」を説明するために時間を費やす必要がなくなります。 + +### 失敗の余地を与える + +悪いメンターシップ経験を持つ人々に共通するテーマは、至る所にいるマイクロマネージャーの存在です。あるコミュニティマネージャーは、過重労働状態の担当者から役割を引き継いだ経験を語りました。しかし、その役割で何をやっても、メールで「こうすべきだった」と指摘され、修正を迫られたのです。結果的に、その役割から遠ざかってしまいました。新任者を小さく無力に感じさせる質問は、何よりも「なぜ〜しなかったの？」という一言です。 + +どんな役割でも、新任者は前任者とは異なる方法で物事を進めるものです。その背景にはいくつかの理由が考えられます。過去の方法を知らない可能性もあれば、あなたが特定の方法を選んだ事情を知らないだけかもしれません。あるいは、異なるスキルセットや視点を持ち込んでおり、その方法が同様に有効で優れた選択肢である場合もあるのです。 + +理由が何であれ、メンティーに「なぜ～しなかったの？」と問うことは避けましょう。 + +その役割を担う新人に、異なる方法で物事を行う自由を与える必要があります。たとえミスを犯しても、彼らがその役割に対する主体性を感じることが重要です。 + +メンターとして最も辛いのは、自分が過去に成し遂げたことを相手が苦戦する姿を見ることです。だからといって新任のコミュニティマネージャーを完全に放り出すべきではありません。指示を与える代わりに、その役割で必要なタスクの適切なドキュメントを用意し、それを参照させるようにしましょう。 + +これにより、ガイド付きの経験を積ませつつ、ドキュメント不足の箇所を可視化でき、同時に彼らが途中で調整を加える自由も与えられます。 + +### 可視性の向上を支援する + +皮肉なことに、プロジェクトで最も対外的な役割を担うコミュニティ担当者は、可視性の欠如によってキャリアに悪影響を受けることがあります。複数の人が、自身の業務内容を管理職が認識していない、あるいはその価値を理解していないためにキャリアが損なわれたと述べています。 + +経験豊富なコミュニティマネージャーとして、新人コミュニティ担当者に贈れる最高の贈り物の一つは、彼らの仕事を信頼できる応援団として支えることです。 + +新人コミュニティマネージャーは手一杯になったり、コミュニティに大きな影響を与えない業務に注力してしまうことがあります。 + +メンターとして、コミュニティに利益をもたらすだけでなく、スポンサー企業にも価値を提供する役割の側面に彼らの努力を集中させる手助けをする機会があります。 + +また、彼らの成功を、管理職層がプロジェクトへの貢献価値を理解できる形で伝える力も発揮できるでしょう。 + +## 始め方 + +新人コミュニティマネージャーの最初の数ヶ月を導くことは、非常にやりがいのある経験です。経験者として、彼らの効果的かつ成功した活躍を支援し、新たな役割を遂行する自信を与え、自社および業界におけるコミュニティ知識の蓄積に貢献できます。 + +新任コミュニティマネージャー向けメンターシッププログラムの最初の30日間は、どのような内容になるでしょうか？　例えば以下のような取り組みが考えられます。 + +* 週1回の1対1の通話時間を設け、必要に応じてアドバイスや支援を求められる環境を整える +* プロジェクトの異なる機能領域から5名のステークホルダーとの紹介ミーティングを調整し、プロジェクトの全体像を把握する手助けをする +* 引き継ぐ定期業務を3つ特定し、その業務をどのように管理していたかのドキュメントを提供する +* 初月で成果を出せる高価値・高可視性のプロジェクトを2つ特定し、成果が出た際にその成果を伝える手助けをする + +1か月を過ぎたら、徐々に影を潜め、1対1の面談を隔週に移行し、オンデマンドでの指導のみに切り替えるべきです。 +指導を適切に行えば、メンティーは自立した業務遂行者へと成長する道筋を確実に歩み始めるでしょう。 + +## まとめ + +本章では、メンタリングの定義、オープンソースプロジェクトにおけるその重要性、メンタリングが個人と組織にもたらす効果について論じました。続いて、コミュニティ向けメンタリングプログラムの必要性と構築方法について説明しました。最後に、自身が経験済みの役割を担う新規コミュニティマネージャーを指導する意義と手法を考察しました。 + + diff --git a/l10n/ja/growing-contributors/from-users-to-contributors.md b/l10n/ja/growing-contributors/from-users-to-contributors.md new file mode 100644 index 00000000..fadfc7fe --- /dev/null +++ b/l10n/ja/growing-contributors/from-users-to-contributors.md @@ -0,0 +1,121 @@ +--- +description: +author: Dave Neary +updated: 2020-05-11 +translated-by: Ken Komazawa powered by DeepL Pro +--- + +# ユーザーから貢献者へ + +すべてのオープンソースプロジェクトは、コードと1人以上の開発者から始まります。その*プロジェクト*を*コミュニティ*へと変えるのは、そのコードを*中心に*互いに関わり合う人々です。プロジェクトの成熟度に関わらず、成功を確実にする最も重要な取り組みの一つは、ユーザーや貢献者との関わりを促進し維持することです。 + +プロジェクトのユーザーが開発者との関わりに労力を注いだ時、その貢献を身近な人からの贈り物のように扱ってください。この人は他のことに使える時間を割き、あえてプロジェクトに関わることを選んだのです。バグ報告の提出、機能リクエストの提供、プルリクエストの作成など、貢献の内容は問いません。彼らが最初に生み出す交流は、その人物がプロジェクトとそのコミュニティに対して好意的な印象か否かを決定づける上で極めて重要です。 + +ユーザーとの関わりを贈り物として扱う、歓迎の文化を築くためのいくつかのステップを紹介します。 + +## 贈り物を受け入れる + +例えば、プロジェクトの機能が期待通りに動作せずユーザーが不満を抱いている場合、その関わりに前向きに対応するのは難しいかもしれません。そんな時こそ、この人がわざわざ問題を伝えようとしているのだと思い出してください。それは、あなたの叔母があなたが望んでいたレゴセットではなく、良かれと思って安物の模造ブロックを贈ってきた時のことを思い出すようなものです。誰かが初めてあなたのプロジェクトに関わるとき、良い第一印象を与えるチャンスは一度きりなのです。 + +まず、その人の貢献に感謝し、それを認めてください。多くの場合、プロジェクトに不満を持って現れた人々が最初に求めているのは、自分が問題の原因ではないという安心感です――つまり「確かにこれは本来あるべきものより使いづらい」という確認です。彼らが直面している特定の障害を乗り越える手助けをすれば、批判者からプロジェクトの応援者に変わります。 + +## 実行可能な有益なフィードバックを提供する + +新規貢献者へのフィードバックは、実行可能である範囲でのみ有用です。つまり、提供した内容に基づいて貢献者が*何か行動を起こせる*ものでなければなりません。 + +質問を受けている場合、回答には追加情報が必要な場合があります。例えば、プロジェクトのコーディング規約に合致しない内容を含むプルリクエストをレビューしている場合、貢献者に修正を求めるでしょう。フィードバックを提供したり何かを依頼したりする際は、初心者の視点でプロジェクトを見つめることが重要です。「ドリーガガーをフロブドリングするだけだ！」といった難解な回答で質問が解決され、「一体どうやればいいんだ？」と頭を掻きむしるほど苛立たしいことはありません。 + +コードレビューでは、プログラミング言語やプロジェクトへの高度な習熟度、あるいはGitHubでのプルリクエスト更新方法さえも当然視してはいけません。プロジェクトがKubernetes上で動作している場合でも、相手がそのクラスターの管理者であるとか、Kubernetesの内部構造に精通しているとは仮定しないでください。 + +疑問がある場合は、常にレベル設定の質問を投げかけられます。ただし、設定ファイル内のオプション変更を指示する場合は、必ずそのファイルの*所在*と形式を説明してください。 + +## 関与するユーザーに良い体験を提供する + +誰かがあなたのプロジェクトに関与した時、その交流から良い印象を持って去ってもらうために全力を尽くしてください。これは重要です——直接関わる相手だけでなく、決して声を上げない傍観者たちにとっても。後者は半年後にStackOverflowの質問を見つけた読者かもしれないし、コミュニティチャットの傍観者かもしれません。こうしたユーザーが他者の良好な体験を目撃すれば、プロジェクトへの好感度も高まります。 + +## プロセスより人を優先する + +大規模開発チームは効率的な運営のためにプロセスに依存します。変更の統合可否やタイミングを検証するバグトラッカーのワークフロー管理であれ、プルリクエストごとに実行されるスモークテストであれ、開発者が大量の変更を処理する際に混乱しないよう、ツールの層を構築しています。 + +プロジェクトに積極的に関わる者にとって、こうしたインフラは大きな価値を提供します！しかしプロジェクトの新参者にとっては、すべてが謎に包まれているのです。 + +コミュニティ重視のソフトウェア開発者として、プロジェクトの新規参加者に配慮する必要があります。彼らの最初のプルリクエストがスモークテストに合格しなかった場合、単に「CI失敗」や「空白の問題」と文脈なくコメントするのではなく、テストの内容とその重要性を説明する時間を割く価値があります。 + +要するに、貢献そのものよりも、貢献する人物を高く評価しましょう。 + +## 関係を築く + +最後に、新規貢献者がプロジェクトに参加した際には、これはプロジェクト利用者と直接関わる機会であると認識しましょう。彼らがどのようにプロジェクトを見つけたのか、気に入っている点や不満な点など、より多くの情報を得られるチャンスです。この情報は貴重です。ユーザーへの直接アクセスは、オープンソース開発がプロプライエタリ開発に対して持つ利点の一つです。この機会を最大限に活用しましょう！ + +こうした対話には副次的な効果もあります。あなたのソフトウェアを「顔の見えない企業の製品」と捉えていたユーザーにとって、プロジェクトに名前と顔を与えることになるのです。つまり、人間関係を構築しているのです。 + +新しい学校や地域、会社に来たばかりの頃を思い出してください。ほんの数分前まで見知らぬ人だった誰かと築く*人間的なつながり*こそが、そこに属していると感じさせる要素です。この関係性は、たとえ小さく未熟なものであっても、その人をあなたのプロジェクトに引き戻し、消費者からコミュニティ参加者へと変える原動力となります。 + +## 開発者がコミュニティプロジェクトに参加する支援 + +経験豊富なプロのソフトウェア開発者がコミュニティソフトウェアの開発を始める際、最もよく見られる問題の一つは、メーリングリストなどの公開コミュニケーションチャネルへの参加をためらうことです。その理由を理解し、開発者がコミュニティに関与できるよう支援することは、協力するコミュニティとの成功し実りある関係を築く鍵となります。 + +この躊躇の一般的な理由には、英語の文章力への自信の欠如、技術力の不足という認識、公開されたピアレビューへの緊張感、そしてコミュニティとの交流を「コミュニケーション」や「マーケティング」と捉え、それが自分の仕事の一部ではないと信じていることが挙げられます。 + +### 自信の欠如 + +従来、大学の工学課程では明確な文章表現の訓練が重視されてきませんでした。このため、プロのソフトウェア開発者になっても文章力を十分に磨いていないケースが生じます。オープンソースプロジェクトでは、コミュニティチームと非同期で協業する上で文章によるコミュニケーションが不可欠です。例えば、作業を促進するブログ記事の執筆、機能提案の文書化、メーリングリストでのロードマップ項目の賛否議論などが挙げられます。 + +さらに、優れた論理的思考は評価されるものの、修辞学や議論の技術は通常、工学部の科目に含まれません。結果として、自身の仕事について文書化したり、公開フォーラムで質問したりすることを求められた際、彼らは躊躇してしまいます。 + +また非英語話者にとっては、英語能力への自信の欠如もメーリングリスト参加の障壁となり得ます。 + +私が以前一緒に働いたあるエンジニアは、私たちが議論したトピックについてメールを書くことに非常に躊躇していました。コミュニティと議論する必要があるという点で合意していたにもかかわらずです。彼がメールを書いた場合でも、コミュニティメンバーからの返信や質問を無視しているように見えました。この件について彼と話し合ったところ、公開アーカイブされるメーリングリスト上で、文章による議論に参加することに不安を感じていることが明らかになりました。彼は、誤った発言やマナー違反がコミュニティから厳しく非難されるのではないかと不安に思っていたのです。 + +この問題を解決する最善の方法は、小さな一歩から始めることです。 + +最初の重要な一歩は、エンジニアに質問に答えてもらうことです。そのための方法の一つは、メーリングリスト上で公開的に質問をエンジニアに紹介し、その分野における専門性を認めることです。「TammyはRLEアルゴリズムを熟知しています。Tammy、Franzの質問にお答えいただけませんか？」 + +これは一種のジェダイのマインドトリックであり、三つの目的を果たします。第一に、グループ宛ての質問は個人が無視しやすいですが、直接質問されると答えない人は稀です——これは人間の本性です。 +次に、エンジニアのスキルを認めることで、彼らがその分野の専門家として認識されていることを再確認させ、回答への自信を高めます。第三に、特定のスキルセットを持つ個人エンジニアを特定することで、社外の人々に内部の様子を垣間見せることができます。チームを「Acme社開発者」といった形のない集団ではなく、様々な強みと弱みを持つ個人の集合体として人間味のある存在に映すのです。 + +もう一つ価値ある取り組みは、開発者に定期的な執筆習慣を身につけさせることです。単に「ブログを書け」と指示するだけでは不十分です。執筆が敷居高く感じられるなら、頻度を増すことでその障壁は低くなります。実現方法は多岐にわたります――ブログ投稿への報酬、定期的な進捗報告の義務化、長いコミットメッセージやチケットクローズ時のコメント、創作ワークショップの時間を確保するなど。目的は開発者を小説家にすることではありません。目標は、チームに書く習慣を身につけさせることです。 + +最後に、エンジニアに基本的なネットエチケットと良いメールの書き方を訓練すべきです。開発者はメール作成をパッチ作成と同様に扱うべきです。パッチを生成する際、送信前に最後に確認して不用意な内容が含まれていないかチェックするのが一般的です。この習慣をメールに応用すれば、表現が不自然で曖昧な箇所を特定でき、より良いメールが書けるようになります。 + +### ピアレビューの試練 + +多くのソフトウェアエンジニアにとって文章作成は気が重くなる作業だが、あまり親しくない人々のグループに自分の仕事をピアレビューに晒すのはさらに神経をすり減らすことになります。 + +私の経験では、体系的なピアレビューはソフトウェア業界では一般的ではありません。一部の管理者はピアレビューを無駄な手間と見なします。結局のところ、開発者はその仕事ができる能力があるからこそ雇われたのであり、誰も「コミュニティ」に後から批判されるのは好まないからです。エンジニアがある程度の経験を積むと、ピアレビューは業界のプロフェッショナルなソフトウェア開発者にとって例外的な存在となる傾向があります。 + +コミュニティプロジェクトでは、ピアレビューは当然の期待事項です。実際、これはベストプラクティスであり、成功したコミュニティプロジェクトを他と差別化する要素の一つです。コミュニティ開発者は、機能が開発される前にその内容を知り、より良い実装方法を提案する機会を期待しています。新規貢献者には、レビュー可能なパッチを提出することを求める——コミッターやメンテナの地位を得る前に、新規貢献者が信頼を築く方法なのです。 + +プロのソフトウェアチーム内でピアレビューを定着させる最良の方法は、「初日コミット特権」——入社初日にオープンソースプロジェクトのリポジトリへのコミット権限を得る慣行——を禁止する社内ポリシーを設けることです。企業がスポンサーとなるプロジェクトでは、新規開発者も社外の貢献者と同様のレビュープロセスを経るべきです。 + +コミュニティプロジェクトへの企業貢献においては、内部ブランチの使用や「ゲートキーパー」型プロジェクト構造（1～2名の開発者がチーム内の他者の作業をコミットする形態）を避けるべきです。 + +開発者は社内への提出と同時に、自身の成果をアップストリームへ提出すべきです。社内ブランチのみに適用される変更についても、非公開リポジトリ内でピアレビューを実施する必要があります。gitベースのリポジトリがソフトウェア開発の標準となった現在、これは以前ほど企業にとって困難ではなく、チームを成功に導くコミュニティ貢献者へと移行させるために不可欠です。 + +新規開発者にこのレビュー期間を経させることは、いくつかの理由から重要です。最も重要なのは、従業員も非従業員の貢献者と同様にプロジェクトで実力を証明する責任を負うことを示す点です。また、新入社員がプロジェクトのコーディングやコミュニケーションの慣習・規範に慣れる期間を提供し、同時にコミュニティ全体に自己紹介する機会となります。これは経験豊富なコミュニティ開発者による新規開発者のメンターシップの基盤です。 + +### コミュニケーションとマーケティングは私の仕事ではない + +一部の開発者は、メーリングリストへのプロジェクト計画の投稿を「発表」と見なし、十分な準備が必要だと考えています。こうした開発者は、メーリングリストでのコミュニティユーザーとのコミュニケーションを「サポート」や「コミュニケーション」と同等と位置づけ、エンジニアリング機能の中核部分とは見なしていません。 + +開発者が「メーリングリストへのメール送信」を「発表」と位置づける場合、それは彼らの頭の中で「マーケティング」の枠組みに収まっています。ある開発者は「本業があるからメーリングリストにメールを送る時間はない」と私に語ったことがあります。彼女にとって「コミュニティ対応」はコミュニティマネージャーである私の仕事でした。彼女の認識では、コミュニティ向けメッセージ発信はサポート業務の一種であり、自身の職務範囲外でした。 + +『クルートレイン宣言』の著者らは、現代のネットワーク社会においてマーケティング部門など存在せず、自社社員と社外関係者とのあらゆるやり取りが評判を勝ち取るか失うかの機会だと主張しました。 + +フリーソフトウェア開発チームでは、この傾向がさらに顕著です。プロジェクトコミュニケーションにマーケティング部門は存在しません。生産性を上げるには仲間と対話しなければなりません。だからこそ、コミュニティプロジェクトに関わる者にとって、外部コミュニケーションへの組織的障壁は消え去らねばなりません。 + +オープンソースコミュニケーションへの期待が明確な組織でさえ、エンジニアは自らに制限を課すことがあります。提案を送信する前に何時間も磨き上げるのです。コミュニティプロジェクトではこれは逆効果です。なぜなら、初期提案が洗練されればされるほど、それに感情的な投資がなされているからです。洗練された提案は、すでに完成しているように見えるため、レビューや変更も難しくなります。粗削りな初期草案を公開し、著者が早期のフィードバックを統合する機会を与える方が良いのです。 + +「早期リリース、頻繁なリリース」の利点をチームに示す最良の方法は、自ら実践することです。チームリーダーやマネージャーとして、チームの計画を早期に公開し、頻繁に反復することを率先して実践できます。その際、チームにもたらされるメリットを明確に示すことです。この障壁を打破するには時間がかかるが、「完璧は求めない」ことを明確にし、情報の早期公開を評価し、フィードバックを奨励することで、チームは社外の参加者を「観客」ではなく「仲間」と認識するようになります。 + +もう一つの有用な手法は、エンジニアにタスクを細分化させることです。たとえ最初の部分が高度な基準に達するまで保留しても、情報がより迅速に発信され、フィードバックがプロセスの後段階に反映されるようになります。 + +早期コミュニケーションという目標に反する傾向として、大々的な発表への欲求が挙げられます。企業は製品リリースと発表を主要な展示会に合わせたいと考えることが多く、その結果、大きなサプライズが台無しになることを恐れて、エンジニアに重要な機能を社内で開発するよう求める場合があります。その代替案は、何かを見せられる状態になるまで待つのではなく、プロジェクト開始時に発表することのように思えますが、これは製品が市場に出るまでの長い待ち時間、そして主流メディアからの焦りと悪評を招く可能性があります。 + +重要な機能の設計決定や実装詳細をメーリングリストで議論するエンジニアと、発表を促進するプレスリリースやマーケティングキャンペーンを分けることは可能です。最終発表時にはコミュニティが完全に驚かされることはなく、数ヶ月間秘密裏に作業し、レビューが困難な大規模なコード投入を提案したことで自己弁護に追われる事態も避けられます。 + +## 関係構築 + +重要な教訓は、開発者に社外の人々との繋がりを感じさせる必要がある点です。そのためには、社外の人々も彼らとの繋がりを感じる必要があります。チームの活動、メンバーのスキルや優先事項を明らかにすることで、プロジェクトに関わる人々が互いを対等な仲間として認識し、機能やパッチの価値について率直に議論できる環境が生まれます。 + +この段階に到達した時、戦いは勝利したと言えます。自チームの開発者は、プロジェクトに関わる他の開発者を対等な仲間、同僚、さらには友人として認識するようになるのです。 diff --git a/l10n/ja/growing-contributors/project-and-community-governance.md b/l10n/ja/growing-contributors/project-and-community-governance.md new file mode 100644 index 00000000..0a81443f --- /dev/null +++ b/l10n/ja/growing-contributors/project-and-community-governance.md @@ -0,0 +1,425 @@ +--- +author: >- + Dave Neary , Josh Berkus , Bryan + Behrenshausen +updated: 2020-05-27T00:00:00.000Z +translated-by: Ken Komazawa powered by DeepL Pro +--- + +# プロジェクトとコミュニティのガバナンス + +本章では、オープンソースプロジェクトやコミュニティのガバナンスモデルを評価し、進化させる方法について議論します。 + +あらゆる組織はガバナンス構造の中で、共に運営されています。「ガバナンス」という用語は組織的文脈において複数の意味を持ちます。例えば規制事項やリスク管理問題などを指す場合もあります。しかしより一般的には、組織内の権力がどのように分配されるかを決定する規則・役割・手順の体系を指すこともあります。 + +オープンソースプロジェクトも組織であるため、どのプロジェクトもガバナンス構造を備えています。これらの構造の中には、他のものより_明示的_なものもあります。また、_形式的_なものもあれば、そうでないものもあります。しかし、どのプロジェクトにもそれらは存在します。 +残念ながら、オープンソースプロジェクトのガバナンスに関する議論の多くは、「プロジェクトを代表して発言する」や「ウェブドメインの所有権」といった活動やリソースに焦点が当てられがちです。これらの機能を文書化することは有用ですが、これらはプロジェクトのガバナンスの_一つの側面_であって、その全容ではないことを忘れてはなりません。本質的に、オープンソースプロジェクトとコミュニティのガバナンスは_人_、すなわちプロジェクトの一員としての権利と責任、そして他者が彼らに抱く期待に関するものです。 + +## ガバナンスとは何か？ + +端的に言えば、「ガバナンス」とは「誰が何を（あるいは何をすべきか）、どのように、いつ行うかを決定する規則や慣習」を指します。 + +オープンソースプロジェクトに最も関連するガバナンス関連の問題は、主に二つのカテゴリーに分類されます：_役割_（roles）に関連するものと、_方針と手順_（policies and procedures）に関連するものです。説明のため、ここではそれぞれを別々に論じますが、実際にはこれらは切り離せない関係にあります——これから示す例が示すように、表裏一体の関係なのです。 + +### 役割 + +オープンソースプロジェクトでは、多くの活動が役割関係のガバナンスに依存しています。_役割_とは、プロジェクト内の誰かが担う機能と考えます。 + +自身のプロジェクトの役割関係のガバナンスシステムを分析する際には、以下の質問を投げかけましょう。 + +* プロジェクト貢献者はどのような役割を担う（または担える）のか？ +* プロジェクト内で特定の役割を担う資格は何か？ +* 各役割にはどのような義務、特権、権限形態が伴うか？ +* 特定の役割を担う人々が管轄または責任を負うプロジェクトリソースは何か？ + +### ポリシーと手順 + +貢献者がオープンソースプロジェクトで特定の役割を担う一方で、プロジェクトのガバナンス構造は、それらの人がプロジェクトの一環として活動する方法を決定します。_ポリシーと手順_とは、貢献者が役割を遂行する際に従うプロセスとガイドラインを指します。 + +プロジェクトの手順・方針関係のガバナンスシステムを分析する際には、以下の質問を投げかけましょう。 + +* 様々な貢献はどのようにプロジェクトに受け入れられるのか？ +* 貢献者はどのように特定の役割を担い、最終的にその役割から離れるのか？ +* 役割の説明や責任範囲はどのように変更できるのか？ +* プロジェクトの決定はどのように（誰によって）行われるのか？ +* 議論や対立はどのように（誰によって）解決されるのか？ + +### 役割・ポリシー・手順の具体例 + +覚えておいてください。プロジェクトの役割とポリシー・手順は独立したものではなく、プロジェクト全体のガバナンスモデルの一部として相互に絡み合っています。例えば「ドキュメントメンテナ」という役割を考えてみましょう。プロジェクトはこの役割を以下のように定義するかもしれません。 + +1. 役割名：ドキュメントメンテナ +2. 資格：ドキュメントへの数年にわたる継続的な貢献 +3. 役割へのアクセス：他のドキュメントメンテナが適格な貢献者を指名し、投票によりこの役割を付与 +4. 職務：ドキュメントの作成および他の貢献者によるドキュメントのレビュー +5. 特権：ドキュメントチームを代表して発言、開発会議への参加 +6. 権限：ドキュメントの内容、技術、戦略に関する最終決定権 +7. 変更手順：役割説明の変更には他のドキュメントメンテナによる投票が必要 + +多くの場合、プロジェクトの実際の役割記述はこれよりも詳細です（一部のプロジェクトの役割ハンドブックは数十ページに及ぶ）。プロジェクトが成熟するにつれ、人々が担う役割の種類は増加する可能性があります。さらに、大規模で成熟したプロジェクトでは、役割を_集団_と結びつける——つまり、複数の貢献者が共同で特定の役割を遂行できるようにします。例えば、プロジェクトには複数の「運営委員会」が存在し、それぞれ独自の選出手順を持つ場合があります。これは[Kubernetesプロジェクト](https://kubernetes.io/)にも当てはまり、ここでは「特別関心グループ (Special Interest Group/SIG)」がガバナンスの主要単位となっています。同プロジェクトでは、コード貢献者という役割がさらに関心グループ（チーム）と貢献者レベル（メンバー、レビュアー、承認者、オーナー）によって細分化されています。したがって、コントリビューターの_実際の_役割は「コードコントリビューター」ではなく、「SIG‒Network Approver」のようなものになります。 + +## なぜガバナンスが必要か？ + +一部のオープンソースコミュニティでは、「ガバナンス」という概念は悪い評判を持っています。これは、プロジェクトの貢献者がガバナンスを純粋に否定的な力——つまり、人々に「何をすべきでないか」「どう行動すべきでないか」「特定の境界内でしか行動すべきでない」と指示するだけの規則や手順の集合体——と解釈しがちな場合に当てはまります。 + +しかし、よく練られたガバナンスモデルは、オープンソースコミュニティにおいてむしろ大きなプラス要因となり得ます。プロジェクトのガバナンスモデルは、そのプロジェクトの_関与条件_——つまり、プロジェクト貢献者がコミュニティにとって最適と認めた、協働と意思決定のための具体的かつ実績ある仕組み——を明示するものです。明確なガバナンスモデルは、新規貢献者がプロジェクトに参加する意欲を高めます。 + +曖昧な、あるいは存在しないガバナンスシステムに比べ、よく設計されたガバナンスシステムは、プロジェクト参加者を遠ざけたりやる気を失わせたりする可能性がはるかに低くなります。新規貢献者の視点からプロジェクトを考えてみましょう。新規参加者は、自身の役割や従うべきルールが不明確な状態でプロジェクトに飛び込む可能性が_より高い_でしょうか、それとも_より低い_でしょうか？特に、自身の貢献を真剣に検討してもらいたい場合です。明確なガバナンスモデルは、人々がプロジェクトに即座に貢献する方法、プロジェクトのリズムを乱さずに参加する方法、疑問や問題が生じた際のエスカレーション方法、そして長く関われば目指せるリーダーシップポジションの種類を把握できます。したがって、コミュニティがガバナンスモデルを設計する際の目標は「参加の仕組みを明確にすること」であるべきです。プロジェクトのルールが明確であれば、貢献者は自信を持って関与できます。このガバナンスへのアプローチは、プロジェクトの長期的な存続可能性と成長に好影響を与えます。 + +## ガバナンスの明文化 + +あらゆるオープンソースプロジェクトには、貢献者が担う異なる役割と、それらの役割を担う者が通常（あるいは担うべき）に従う手順が存在することを思い出してください。こうした役割や手順が実際にどこかに文書化されているかどうかは関係ありません。文書化されていない役割は、通常の貢献者の活動に暗黙的に存在し（そしてしばしば議論の種となります）。成功するオープンソースプロジェクトは、自らのガバナンスモデルを明文化します。 + +2018年の研究で、[研究者Javier Canovasは](https://opensource.com/open-organization/18/4/new-governance-model-research)、GitHubで最もスター数の多い25プロジェクトのうち19プロジェクトが、ガバナンスモデルを概説した文書を公開していないことを発見しました。Canovasは、いくつかの理由からこれを残念なことだと考えました。 + +「第一に、\[明示的なガバナンス]は組織の透明性向上に寄与する」と彼は記しています。「あるグループが問題を検討するのに要する時間、貢献が組織に影響を与える可能性、発言した際に誰が耳を傾けるのかといった点が把握できる。第二に、ガバナンスモデルを明示的に定義することで、オープン組織がどのように運営されているかを理解し分類する助けにもなる」 + +その仕組みの一例を挙げましょう。2018年、Kubernetesプロジェクトはリリースチーム向けに詳細かつ包括的な「役割ハンドブック」を追加しました。このハンドブックには、チーム参加に必要な資格、メンバーの職務内容、意思決定プロセスの詳細など、リリースチームの役割に関連する情報が明記されていました。その結果、リリースチームはプロジェクトへの貢献において最も人気のある参入ポイントとなり、新規参加者は何を期待すべきかを正確に理解できました。Kubernetes内の他のチームもこれに追随し、新規貢献者の数が2倍、さらには3倍に増加する経験をしました。 + +明確かつ明示的なガバナンスモデルにはもう一つの重要な利点があります——プロジェクトコミュニティにおける強い信頼感の醸成です。堅牢で詳細なガバナンスモデルを持つプロジェクトのメンバーは、透明性のある手順・方針・役割記述への共通のコミットメントから恩恵を受けます。紛争が生じた際には、広く理解されているガイドラインに訴えることができます。こうした仕組みにより、参加者の動機・意図・目標・権限に関する疑問が紛糾しにくくなります。 + +## コミュニティ発プロジェクトの進化 + +オープンソースプロジェクトが、完璧に事前設計されたガバナンスモデルを「選択」して導入することから始まることは稀です。むしろ、プロジェクトのガバナンスモデルは、コミュニティが成長し多様化するにつれて進化していくことが一般的です。 + +初期段階では、プロジェクトには開発者が1～2名しかおらず、「ガバナンス」に関する議論はほとんど無意味です（プロジェクトが単純に規模が小さすぎて、体系的な意思決定プロセスが必要ないためです）。しかし、プロジェクトが新たな貢献者を惹きつけるにつれ、状況は変化します。プロジェクトのガバナンスモデル、文化、リーダーの行動様式は密接に絡み合っているため、いずれか一つが変化すれば、他の要素にも変化が波及する可能性が高いのです。各プロジェクトはそれぞれ異なり、独自の成長経路と成熟の軌跡をたどりますが、ガバナンスの進化を引き起こす傾向にある、特定の開発段階における共通のマイルストーンが存在することに留意すべきでしょう。 + +### 創設者間の協力 (1～2名) + +単一の開発者（または少数の開発者グループ）で始まるプロジェクトは、多くの場合、正式なガバナンス構造を必要としません。合意形成は容易であり、プロジェクトの初期段階では、何をすべきか（そして誰がそれを行うべきか）についての意見の相違は稀です。プロジェクトの初期メンバーは通常、コードの承認など、プロジェクトにとって最善と考える行動を自由に取ることができます。通常、GitHubリポジトリ以外に構造は不要であり、初期の開発者はほぼ即座にプロジェクトメンバーシップを取得します。 + +### 初期のプロジェクト成長（最大5名） + +プロジェクトが成長し始めると、このアプローチの限界が明らかになります。開発者が5名に達するだけでも、作業の調整はより困難になり、新規開発者は初期開発者が従ってきた設計選択やコーディング標準にすぐには精通していない可能性があります。 + +そのため、プロジェクトが最初に進化する段階として、コードの提出がマージ前にピアレビューを経る必要が生じることが多くなります。プロジェクト階層の「第一レベル」は、プルリクエストやコード・コンテンツの提出をプロジェクトに組み込む権限を持つ者で構成されます。当初、この権限を誰に与えるかは容易に決まります。プロジェクトの初期の信頼できる開発者全員が権限を持ち、意見が対立した場合はプロジェクト創設者が最終的な判断者となります。 + +### 中期的なプロジェクト成長（10～15名のメンバー） + +プロジェクトガバナンスの進化を促す次の契機は、新規参加者がグループの正式メンバーとして認められる仕組みに関連することが多いです。これはプロジェクト規模が約10～15名の開発者に拡大した段階で生じがちです。この段階では、プロジェクトコミュニティは通常、新規メンバーの受け入れに関する、より正式なガイドラインを策定する必要に迫られます。 + +新規メンバーを評価する際にプロジェクトが用いる一般的な基準は、持続的な参加（貢献者がプロジェクトで活動してきた期間と頻度）と、いわゆる「良識」に関する判断——貢献者が提出する作業の質、レビューコメントにおける適切な判断力など——を組み合わせたものです。それでもなお、プロジェクト創設者は、プロジェクト内で誰が昇格するかの門番であり最終的な裁定者となる傾向があります。 + +## 企業発プロジェクトの進化 + +企業環境で活動するプロのソフトウェア開発チームによって始まったオープンソースプロジェクトは、やや異なる進化を遂げる傾向があります。企業環境で生まれたこれらのプロジェクトは、しばしばその組織構造を継承します。例えば、既に独自の階層概念（マネージャー、アーキテクト、ジュニア／シニア開発者など）を持つ強固な開発者グループが存在する場合があります。 + +### 企業発プロジェクトの初期段階 + +プロジェクトへのコミュニティ参加を促進する初期の取り組みは、採用拡大と初期ユーザーとの関わりに焦点が置かれる傾向があります。しかし既存の開発者チームは通常、プロジェクト計画を中央集権的な方法で継続します。このため外部貢献者はプロジェクトへの関与が困難に感じられ、結果としてプロジェクトが十分な牽引力を得られない可能性があります。プロジェクト変更の急速なペース、計画プロセスの不透明さ、既存の開発者間の強固な関係性は、外部貢献者にとって機能開発をより困難にします。初期のパッチ提出は長期間レビューされないまま放置され、提出頻度も比較的低くなります。 + +多くの企業発プロジェクトは、この段階で進化が止まります。コアチームがプロジェクトのユーザーベースと積極的に関わる一方で、開発者ベースを_拡大_するために必要なリソースは膨大であり、多くの組織はその投資を行わない選択をします。 + +しかし、オープンソースモデルの利点としてよく挙げられるのは、業界パートナーや競合他社と協力し、共通要件の開発負担を分担できる点です。これが目標であるならば、単一ベンダーを超えた企業発プロジェクトへの参加拡大が不可欠となります。 + +### マルチベンダー企業オープンソースへの進化 + +企業発プロジェクトにおいて参加を拡大するには、プロジェクトを利用する関心のある個人と、プロジェクトへの投資意欲を持つベンダーの両方との関与が必要です。これらの関係者を結集させることは、プロジェクトガバナンスに影響を及ぼします。 + +多くのプロジェクトは、プロジェクトの実用的な市場を実証することで他ベンダーの貢献を誘引します。ベンダーは通常、投資を正当化できない限りオープンソースプロジェクトに持続的に投資しません。したがって、この段階ではソフトウェアの顕著かつ熱心なユーザー採用を実証することが極めて重要です。初期の取り組みは、採用の勢いを加速させ、ユーザーをプロジェクトロードマップやプロジェクト推進への積極的な参加に誘うことで、ユーザーを貢献者に転換することに焦点を当てます。 + +あるいは、プロジェクトは、協力者に共通プラットフォームを「基盤として構築する」ことを奨励することに焦点を当てて、他のベンダーとの関与を試みることもできます。企業はプロジェクトの「コア」への多額投資を正当化できない場合でも、比較的低コストで自社のビジネスを支えられる_拡張機能_への投資は正当化できる可能性があります。 + +例えば、初期のアウトリーチと関与の取り組みをAPI、拡張機能の開発者体験、拡張機能開発者の流通経路に集中させることで、プロジェクトはコアプラットフォーム自体を改変するのではなく、プラットフォーム上に構築するベンダーの大規模なコミュニティを育成できるのです。「中核」と「周辺」という開発領域を区別するには、各領域固有のガバナンス決定が必要となる場合が多いです（例えば、プロジェクトの「中核」領域で活動する権限は特定の役割のみに付与されるなど）。 + +企業発のプロジェクトが市場における大きな機会を実証した場合（プロジェクトが市場の重要なギャップを埋めることを証明するか、直接的に大規模なユーザーベースを成長させるか）、潜在的なベンダーパートナーとプロジェクトへの協力を協議できます。この議論は技術的側面とビジネス的側面の両方を含みます。 + +ベンダーはプロジェクトにエンジニアリングリソースを大規模に投入する前に、以下を問うでしょう。 + +* 公平な条件でプロジェクトに関与できるか？ あるいはステークホルダーが異なるベンダーからの変更を評価する際に異なるプロセスを用いるか（例：発案ベンダーに他者より優位な権利を与える貢献者ライセンス契約）？ 法的観点から公平性を確保する一般的な方法は、プロジェクトの管理権と商標権を財団に寄託することである。 +* このプロジェクトは顧客のニーズを満たしているか？ベンダーは市場適合性や自社製品ポートフォリオへの適合性を検討する。 + +追加ベンダーの参加を受け入れることは、プロジェクトのガバナンスに重大な影響を与え得ます。潜在的な混乱を緩和する一つの方法は、元々のベンダーと直接競合しないベンダーをターゲットとすることです。例えば、クラウドホスティング企業は、競合するホスティングベンダーを勧誘するよりも、オンプレミスソフトウェア製品ベンダーをプロジェクトに勧誘する方が成功する可能性が高くなります。競合ベンダーは、プロジェクトが複数のベンダーとの継続的な関与実績を示せる場合にのみ参加を承諾するかもしれません。 + +## 持続的な進化のガバナンス + +プロジェクト参加が一定の「臨界点」に達すると、個人または企業がプロジェクトを開始したかに関わらず、多くの共通パターンが現れます。 + +これまで議論してきた全てのケースにおいて、意思決定のルールや手順は暗黙的な傾向があります。また、ほとんどのオープンソースプロジェクトは10人以上のアクティブ開発者（または1つのコアベンダー）を募集することはないため、プロジェクトガバナンスを明文化する必要が生じる段階に到達することはありません。ただし、その段階に到達したプロジェクトは、より精緻で複雑なガバナンスモデルを採用する可能性が高いです。詳細は以下の「オープンソースガバナンスモデルの事例」を参照してください。 + +プロジェクトがこの規模に達すると、管理権と商標権を独立した組織（オープンソース界隈では通常「財団」と呼ばれる）に移管しようとする場合があります。ごく稀に、この目的のために独自の独立コンソーシアムを設立するプロジェクトもあります。しかしより一般的なのは、既存の財団（例：Apache Software Foundation、Linux Foundation、Cloud Native Computing Foundation、Eclipse Foundation、OpenStack Foundation、Software Freedom Conservancyなど）にアプローチし、プロジェクトの採用を依頼する方法です。 + +このような提携先となる財団を選定する際、オープンソースプロジェクトは以下の点を考慮する必要があります。 + +1. コスト構造 +2. 財団が課すガバナンス要件 +3. 財団とプロジェクトのユーザー・開発者基盤との親和性 + +この段階で、プロジェクトは通常、会員費がプロジェクトの技術ガバナンスにどの程度影響を与えるべきかについて議論します。このガバナンスには主に2つのモデルが存在します。 + +一つ目は、資金と技術的インプットの厳格な分離です。最高レベルの会員資格で参加するメンバーは、プロジェクトの予算事項（例えば、インフラ、人員、マーケティング、イベントへの資金配分方法）に意見（および影響力）を行使できますが、技術的価値がプロジェクトの技術的ガバナンスを決定します。二つ目は「純粋な会員組織」モデルであり、会員は技術統治委員会に代表者を指名する権利を有し、どのサブプロジェクトを採用するか、またプロジェクトをどのように統治するかを監督します。 + +財団はプロジェクトの進化において別の重要な役割を果たします。プロジェクト周辺の市場力学を定義することや、プロジェクト商標の管理を含みます。商標は、ベンダーがプロジェクト（またはその派生品）をプロジェクトの評判を損なわない方法で配布していることを保証する上で、オープンソースプロジェクトの最も貴重な資源の一つです。オープンソースプロジェクトでは、市場における特定ベンダー製品を「承認」したり、派生製品の挙動に影響を与える手段として、商標認証が一般的に用いられます。 + +一部のプロジェクトは、貢献者は_個人貢献者_であり、たまたま勤務する企業の代表ではないという考えを強く堅持しています。成熟したオープンソースプロジェクト（Linuxカーネルなど）では、これにより、雇用主が変わってもコミュニティ内での地位や年功を維持できます。 + +## オープンソースプロジェクトのガバナンスモデル例 +### 「ドゥオクラシー (Do-ocracy)」 + +「ドゥオクラシー」ガバナンスモデルを採用するオープンソースプロジェクトは、形式的で複雑なガバナンス慣行を放棄し、「決定は作業を行う者によってなされる」ことを主張する傾向があります。つまり、ドゥオクラシーでは、メンバーは最も一貫した貢献を行うことで権威を獲得します。このモデル下でもピアレビューは一般的ですが、個々の貢献者は、自身が最も深く関わったプロジェクトコンポーネントについて、事実上の意思決定権を保持する傾向があります。 + +このため、一部のドゥオクラシーは「ガバナンスは全く存在しない」と主張し、代わりに個々のステークホルダーが「最も多くの作業を行った分野」について決定を下す権威に依存します。しかし既に説明した通り、ガバナンス不在を主張するこのような見解は誤りです。あらゆるオープンソースプロジェクトにはガバナンスモデルが存在します。多くのドゥオクラシーの場合、そのガバナンスモデルはプロジェクトメンバーの日常的な相互作用に暗黙的に組み込まれているに過ぎません。その結果、新規参加者は参加方法や貢献の承認を得る方法を即座に把握できず、参加が困難で威圧的に感じられることがあります。 + +**このガバナンスモデルを持つプロジェクトで始めるには：** 改善できると感じるプロジェクトの側面を見つけ、単純に作業を開始することです。プロジェクトの変更履歴を確認し、貢献を成功させる上で不可欠なフィードバックを提供してくれる参加者を特定します。プロジェクトがあなたの貢献をより多く受け入れるにつれ、コミュニティ内での影響力は徐々に蓄積されます。成功した貢献の実績を示すことができるようになるまで、ドゥオクラシーにおいて意思決定に影響を与えることは期待しないことです。 + +### 創設者リーダー + +創設者リーダー型ガバナンスモデルは、新規プロジェクトや少数の貢献者しかいないプロジェクトで最も一般的です（ほとんどのオープンソースプロジェクトは貢献者が少ないため、このモデルはかなり普及しています！）。このモデルでは、プロジェクトを立ち上げた個人またはグループが、プロジェクトの運営、ビジョンの確立、コードマージ権限の管理、そして公の場での発言権を担います。一部のプロジェクトでは創設者リーダーを「BDFL（Benevolent Dictator for Life：終身善意独裁者）」と呼称しますが、この用語は廃れつつあります。 + +創設者リーダーモデルを採用するプロジェクトでは、権力と権限のラインが通常非常に明確であり、すべてのプロジェクト事項の最終決定権を持つ創設者リーダーから放射状に広がります。このモデルの限界は、プロジェクトが一定の規模に成長すると明らかになります。創設リーダーの個人的嗜好とプロジェクト設計上の決定を分離することが次第に困難になり、創設リーダーがプロジェクト意思決定のボトルネックとなる可能性があります。極端な場合、創設リーダーモデルはプロジェクト内に一種の「カースト」制度を生み出します。非創設メンバーが、創設者のビジョンに沿わない変更を自分たちが影響できないと感じ始めるからです。意見の相違はプロジェクト分裂を招く恐れがあります。さらに悪いことに、創始者リーダーの離脱（燃え尽き症候群によるものか計画的な引退によるものかを問わず）は、プロジェクト全体の崩壊を引き起こし得ます。 + +**このガバナンスモデルを採用するプロジェクトへの参加方法:** プロジェクトのメーリングリストやディスカッションフォーラムを閲覧し、創始者リーダーを特定します。その後、参加や貢献に関する質問を、コミュニティの公開コミュニケーションチャネルを通じてそれらのリーダーに直接投げかけます。創設者リーダーはプロジェクトのニーズを包括的に把握している傾向があり、あなたの貢献が最も効果を発揮するプロジェクト領域を指示してくれるでしょう。創設者リーダーのプロジェクトに対するビジョンを理解することが重要です。ほとんどの創設者リーダーは、そのビジョンと矛盾すると感じる変更提案を拒否するからです。初期段階では、創設者リーダーのプロジェクトビジョンに沿わない変更を提案しようと期待すべきではありません。 + +### 自己任命型評議会または理事会 + +創設者リーダーモデルの欠点を認識し、自己任命型評議会または理事会モデルはコミュニティのリーダーシップ交代と継承をより円滑にすることを目指しています。このモデルでは、オープンソースプロジェクトのメンバーが、プロジェクトの様々な側面を統治する複数のリーダーシップグループを任命することがあります。こうしたグループは「運営委員会」「コミッター評議会」「技術運営委員会」「アーキテクチャ評議会」「取締役会」などの名称を持ちます。通常、これらのグループは独自の意思決定慣行と後継者選定手順を構築します。 + +自己任命型評議会・理事会ガバナンスモデルは、プロジェクトに支援財団が存在せず、選挙制度の確立が極めて困難な場合に有用です。しかし、自己任命の統治グループが閉鎖的になり、プロジェクトコミュニティ全体を代表しなくなる（メンバー選出プロセスが自己強化的リーダーシップ文化を生み出す傾向があるため）と、このモデルの欠点が明らかになります。さらに、コミュニティメンバーは興味のある活動に主体的に取り組む前に「選ばれるのを待つ」必要があると感じるため、このモデルはリーダーシップ活動へのコミュニティ参加を阻害する可能性があります。 + +**このガバナンスモデルを採用するプロジェクトへの参加方法:** このガバナンスモデルは成熟したオープンソースプロジェクトに典型的なため、このモデルを採用するコミュニティは、潜在的な貢献者を支援するための入門ドキュメントを用意していることが多いです。まずこのドキュメントを探して読みましょう。次にプロジェクトのガバナンス文書を読み、統治機関の構成を確認します。多くの場合、貢献したいプロジェクト領域を統括する評議会や理事会を見つけることができます。その機関はあなたの貢献を監督し、質問に答えることができます。 + +### 選挙型 + +一部のオープンソースプロジェクトは、選挙を通じてガバナンスを実施することを選択します。様々な役割の選挙を実施したり、プロジェクトの方針や手順を承認・更新するための同様の選挙プロセスを実施したりします。選挙型モデルでは、コミュニティは全員が合意した選挙手続きを確立し文書化し、その後、意思決定の通常の手順としてそれらの手続きを実施します。 + +このモデルは、複数の有資格かつ関心のある貢献者が同じ役割を担うことを申し出る、大規模なオープンソースプロジェクトでより一般的です。また、スポンサー（財団など）を持つプロジェクトでも選挙は一般的です。なぜなら選挙プロセスはスポンサー資源の配分をより透明化できるからです。選挙によるガバナンスは、プロジェクトの役割、手順、参加ガイドラインの正確な文書化にもつながる傾向があります。選挙文書がこれらの事項を明示することで、新規貢献者がプロジェクトへの関与を最大化する助けとなります。 + +しかし選挙には欠点もあります。選挙は論争を招き、全プロジェクトメンバー（立候補者か否かを問わず）の注意をそらし、時間を浪費する可能性があります。一部のコミュニティは、著名なプロジェクトメンバーの任期が不確定であることへの解決策として選挙を推進しますが、プロジェクトの方針に任期制限が含まれていない限り、選挙自体が交代を促すことは一般的ではありません。 + +**このガバナンスモデルを採用するプロジェクトへの参加方法：** 選挙でリーダーを選出するコミュニティは、通常、プロジェクトウェブサイトに選挙結果とリーダーシップ名簿を目立つように掲載しています。これらの文書を確認し、プロジェクト内の連絡先を特定してください。適切に運営されるオープンソースコミュニティは、コミュニティが投票できる事項の提案・審査プロセスをプロジェクトサイトで明確に示します。プロジェクトへの有益な貢献で評価を確立すれば、いずれリーダー職への立候補を検討できるでしょう。他の貢献者とは生産的に交流し効果的に協働してください。彼らが将来、あなたをリーダー職に選出する可能性があるからです。 + +### 単一ベンダー + +時折、個々の企業や業界コンソーシアムは、潜在的な開発者やユーザーにリーチする手段として、オープンソースライセンスの条件下でソフトウェアを配布することを選択する場合があります。たとえそれらの対象者からのプロジェクト貢献を受け入れていない場合でもです。彼らは、自社製品の採用を加速させるため、ソフトウェアプラットフォーム上での開発活動を促進するため、プラグインエコシステムを支援するため、あるいは外部開発者コミュニティを育成するために必要なオーバーヘッドを回避するために、このような選択をする可能性があります。 + +このモデルでは、統治組織は通常、外部からの貢献を受け入れません。代わりに、オープンソースとクローズドソースのイノベーションは、プロジェクトが外部と接する境界領域で発生します。このため、一部の評論家はこれを「囲い込み型（walled garden）」ガバナンスモデルと呼びます。このモデルを採用するプロジェクトは、時に強力な「コピーレフト」要件を課すライセンスを採用することがあります。これは、商業的競合他社がプロジェクトでの作業の恩恵を受けることを抑止する手段と見なされています（目的は、生産要件を持つ競合他社や顧客に、ソフトウェアの非オープンソースライセンスを購入させること——いわゆる「デュアルライセンス」アプローチ）。このモデルは、プロジェクトがオープンなコミュニティを標榜しながら実際には企業やコンソーシアムが完全所有している場合に問題となります。 + +**このガバナンスモデルを採用するプロジェクトへの参加方法：** まず、該当する場合、自身の雇用主とプロジェクト発起企業との既存の関係性を検討します。次に、プロジェクトのライセンス条項を評価し、変更履歴やバグトラッカーを確認して、自身が関心を持つプロジェクトの側面に、希望する方法で貢献できるかどうかを判断します。プロジェクトの特定のライセンス規定により、直接貢献するのではなく、特定のプロジェクトと連携して作業したり、その上に構築したりすることになるかもしれません。 + +## 財団支援型 + +リソースやプロジェクトコードに対する管理権限を強化するため、一部のオープンソースプロジェクトは、非営利慈善団体や業界団体などの法人化されたNGO（非政府組織）による管理を選択します。これにより、抽象的な存在である「プロジェクト」が、サーバー、商標、特許、保険契約などのリソースを所有することが可能になります。 + +場合によっては、財団のリーダーシップとプロジェクトのリーダーシップが単一のガバナンス構造を形成し、オープンソースプロジェクトの全側面を管理することがあります。別のケースでは、財団が商標やイベントなどの一部事項を管理し、プロジェクト内の他のガバナンス構造が他の事項（コード承認など）を管理します。 + +通常、このモデルは大規模なオープンソースプロジェクトに限定されます。なぜなら、多額の資金と法的要件が必要だからです。しかし、多くの小規模プロジェクトは、Software Freedom ConservancyやLinux Foundationといった大規模な傘下財団に参加し、このガバナンスモデルの利点を享受することを選択しています。このガバナンスモデルは、第三者（カンファレンス会場など）との法的関係構築を目指すプロジェクトや、主要メンバー離脱後の円滑なリーダーシップ移行を確保したいプロジェクトにとって有利です。また、単一ベンダーによるプロジェクトの商業化を防ぐ助けにもなり得ます。 + +高コスト（厳密には金銭的ではなく、特に貢献者の時間的負担が膨大になり得る点）は、財団支援型ガバナンスモデルの重大な欠点です。一部の財団は業界コンソーシアムとして法人化されており、スポンサー企業が組織を統治します。コンソーシアムによって、個々のプロジェクト貢献者からの参加度合いは異なります。比較的オープンなグループもあれば、企業管理者のみが権限を持つものもあります。 + +**このガバナンスモデルを採用するプロジェクトを始めるには：** 財団が日々のプロジェクト貢献活動を統治していない場合は、プロジェクトの開始手順書を探してそれに従ってください。そうでない場合、特定の財団傘下の個別プロジェクトには独自のリーダーが存在することに留意してください。ただし、財団が統括する全プロジェクトで基本的な貢献プロセスを標準化する共通ガイドラインが存在する可能性があります。特定のプロジェクトのリーダーを特定するには、財団メンバー向けメーリングリストに問い合わせることを検討してください。また、プロジェクトの変更履歴を調査して頻繁な貢献者を特定し、連絡を取ることも可能です。多くの財団では貢献度に基づく投票制度を採用しているため、財団の正式な投票権を持つメンバーになるために必要な手順を把握しておきましょう。財団が会員制の業界コンソーシアムである場合は、所属企業が既に会員かどうかを確認してください。そうでない場合は、プロジェクトが業務に与える重要性について上司と話し合い、所属企業が加盟を検討する可能性について尋ねてみましょう。いずれの場合も、財団プロジェクトでは貢献者向け書類への署名が必要となる場合があります。法務部門が書類のレビューと署名手続きを支援するはずです。 + +## 基本的なガバナンスの実施 + +これまで、オープンソースプロジェクトとコミュニティガバナンスの性質と重要性、プロジェクトガバナンスモデルの進化を引き起こす要因、そして最も一般的なオープンソースガバナンスモデルの数例について議論してきました。最後に、新規プロジェクトを立ち上げる場合でも、既に活動中のプロジェクトを進化させる場合でも、自身のコミュニティのガバナンスを構築するために取ることができる具体的な手順をいくつか検討しましょう。 + +ほとんどのガバナンスモデルは、役割と方針・手順という二つの主要な側面で構成されていることを思い出してください。ここでの基本的な要件は実際には非常に簡素であり、プロジェクトの成長に合わせて進化させることができます。以下は、プロジェクトガバナンスのための_最小限の機能を備えた製品_のようなものです。 + +プロジェクトでは、以下の各セクションはそれぞれ独立した文書となる可能性があります。あるいは、単一の長いREADMEの一部となるかもしれません。あるいはその中間的な形も考えられます。重要なのは、物事の基本的な仕組みを文書化することです。これにより、プロジェクトへの参加を検討している人々が、どこに行けばよいか、誰に話せばよいかを理解でき、何より不意打ちを食らうことがなくなります。 + +### 誠実さの重要性 + +ガバナンス文書を作成する際、プロジェクトを「あるべき姿」——あるいは企業マーケティング部門が望むイメージ——として定義したくなる誘惑に駆られることがあります。実際の姿ではなく。特にプロジェクトリーダーは、文書上でプロジェクトを実際よりも民主的に見せようとする誤りを頻繁に犯します。これは、ユーザーや貢献者がガバナンス文書通りの運営を期待した際に、それが実現されないことで破綻します。当初「単一企業主導」と説明されても納得していた人々が、後になってコミッター権限を申請し拒否されると、強い不満を抱くのです。 + +技術文書と同様に、ガバナンス文書も実際の運用方法を説明すべきです。将来の目標がある場合は、「ロードマップ」や「TODO」セクションに別途記載します。 + +### 役割の定義 + +前述の通り、プロジェクトには様々な実在の役割が存在しますが、開始時に定義すべきはごく一部です。基本的な役割は以下の通りです。 + +1. _メンバー_ +2. _コントリビューター（貢献者）_ +3. _リーダー_ + +意識しているかどうかに関わらず、あなたのプロジェクトには既にこれらの役割が存在しています。それぞれの役割は、プロジェクトのドキュメントかメインソースコードリポジトリのいずれかに、何らかの形で記録されるべきです。これにより、暗黙の了解を明文化でき、参加者の期待値を設定すると同時に、より多くの人々がプロジェクトに参加できるようになります。各役割について、その定義（誰が該当するか）、資格要件、期待される行動、権利と特権を明確に定義する必要があります。将来的にはこれらを超えて、より多くの具体的な役割を定義することになるでしょう。しかし、この3つを詳細に定義するだけで、プロジェクトはかなりの進展を遂げられます。 + +#### メンバー + +オープンソース全体で最も広く存在するにもかかわらず、おそらく最も文書化されていない役割です。メンバーとは、プロジェクトに参加し、そのことを認められている個人または組織です。プロジェクトの運営方法によっては、メーリングリストの購読者、スポンサー企業、既知のエンドユーザー、イベント参加者、財団のメンバーなどが該当します。プロジェクトによっては「メンバー」と「コントリビューター」が同義となる場合もありますが、大半ではそうではありません。多くのプロジェクトでは、何らかの形で関与しているものの、コードやコンテンツを積極的に貢献していない人々がはるかに多く存在します。 + +メンバーを定義するには、プロジェクトが実際に誰に奉仕しているのかを決める必要があり、これは常に重要な議論です。主要スポンサー企業の顧客は自動的にプロジェクトのメンバーとなるのか？企業もメンバーになれるのか、それとも個人のみか？エンドユーザーはメンバーなのか、それとも貢献者に限定されるのか？何よりも、メンバーを定義することは、プロジェクトリーダーが耳を傾けるべき対象を定義することを意味します。 + +ほぼ全てのプロジェクトにおいて、メンバーが従うべきルール（通常は行動規範が中心）と、リーダーや貢献者から何を得られるかを明示する必要があります。特に「メンバーはこのリポジトリに対してバグを報告し、_new bug_テンプレートを使用する」といった、プロジェクトへの参加方法を説明することが有効です。明確な指示を与えられれば、ほとんどの人は喜んで示された方法で参加します。 + +民主的に選出されたリーダーシップを持つプロジェクトでは、メンバーはより厳密に定義された役割となり得ます。なぜならメンバーであることは投票権を伴う可能性があるからです。これにより、投票操作や選挙手続きの妨害を避けるため、メンバーの資格をより慎重に審査する必要があります。 + +#### 貢献者 + +貢献者の定義を文書化しているプロジェクトははるかに多いですが、想像より少ないのが実情です。公開ホスティングされたソースコード管理の時代において、GitHubやGitLabの統計に表示される人物を自動的に貢献者とみなす傾向があります。しかし「このプロジェクトの貢献者とは誰か」を定義することは、一見簡単そうに見えて実は難しいのです。 + +メーリングリストに投稿した者全員か、それとも100件のプルリクエストをマージした者だけか？ コード貢献者のみか、あらゆる種類の貢献者か？ イベントやアドボカシー活動を行う人々は？ 貢献企業に勤めるスタッフは自動的に貢献者とみなされるのか、それとも個人が資格を得る必要があるのか？ 3年前に大量のコードを貢献したが、その後は貢献していない人物はどう扱うか？ リリースクレジットには誰を、どのように記載するか？ + +こうした議論は、文書そのものよりもプロジェクトに大きな影響を与えることが多くなります。 + +また、貢献者に対しては、その活動に対する見返りについてより多くの期待を設定する必要があります。これにはプロジェクトの知的財産ルール（例：貢献者は自身のコードを所有し続けるか否か）の説明だけでなく、貢献者が自身の提出物がどの程度の期間でレビューされ、受け入れられるか、あるいは拒否されるかといった疑問への回答も含まれます。一般的に、貢献者の参加に対するクレジットの付与方法についても説明すべきです。 + +また、貢献者が従うべきルールを明確に定める場でもあります。例えば、一部のプロジェクトでは、貢献者またはその雇用主に、著作権やその他の知的財産権を正式に共有する書類への署名を要求する場合があります（詳細は後述）。プロジェクトの維持管理を支援するため、他の人の提出物のレビューやドキュメント作成の支援など、貢献者に特定の行動を求めることも考えられます。 + +#### リーダー + +前述の通り、リーダーが明確に特定されていなくても、あらゆるプロジェクトには指導層が存在します。したがって、意思決定プロセスを明確にするため、最低限リーダーを透明性をもって特定する必要があります。多くのプロジェクトでは、委員会による選出、選挙、職務に基づく任命など、リーダーになるための資格や手順も説明しています。政治的に洗練されたプロジェクトであれば、これらを選出/選出手順文書（下記参照）に明文化すべきですが、単純な場合は選出手順を役割文書の一部として記載するだけで十分です。 + +リーダーシップの役割文書に記載されることが少ないのは、リーダーの権限と制限、その職務内容、そして役職を離れる方法（自発的か否か）といった他の部分です。リーダーの権限範囲と責任範囲を全員が正確に理解することは極めて重要です。さもなければ、リーダーと他のプロジェクトメンバーとの間で多くの衝突が生じます。文書化された職務内容があれば、参加を停止したにもかかわらず辞任を望まないプロジェクトリーダーをリーダーシップチームが解任する際に、非常に役立ちます。 + +新規／追加リーダーの募集を検討している場合、リーダーが満たすべき詳細な資格要件を定めることも重要です。一部の予想に反し、詳細な資格要件を設けることで、プロジェクト内で昇進を目指す人々に明確な目標を提供できます。 + +## 方針と手順の設定 + +基本的な役割文書に加え、各プロジェクトが自ら作成すべき基本的な文書がいくつか存在します。これらのポリシーと手順（P\&P）文書は、プロジェクトを成長・成熟させるために最低限必要なものと見なされます。貢献者の基盤が拡大し、文書化が必要なプロセスが増えるにつれ、プロジェクトには他のP\&P文書も必要となり、最終的には作成されるでしょう。 + +これらのうち、リリースプロセスやサポートポリシーなど主に技術的なものは、ここでは詳しく取り上げません。 + +しかし、全てのプロジェクトが備えるべき3つのガバナンスP&Pが存在します。 + +1. 行動規範（Code of Conduct） +2. 貢献プロセス（Contribution Process） +3. 連絡情報（Communication Information） + +規模拡大・人気上昇、商用採用、新規貢献者の積極的募集を進めるプロジェクトでは、以下のような追加P&P文書が必要となるでしょう。 + +1. リーダー選出／選挙プロセス +2. 貢献者昇格 +3. リリースプロセス +4. セキュリティ問題の報告と対応 +5. プロジェクト商標の使用 + +以下でこれら8つの文書について説明します。 + +### 行動規範の策定 + +オープンソースコミュニティ向けの行動規範（CoC）を作成することは、プロジェクトのガバナンスモデルに影響を与え始める最もシンプルかつ強力な方法の一つです。行動規範とは、コミュニティメンバーがプロジェクト内で、またはプロジェクトを代表して行動する際の期待される振る舞いを記述したものです。コミュニティが遵守することに合意した価値観を概説し、それらの価値観を実現するためにコミュニティメンバーが互いに示すことを期待する行動を明確にし、規範違反の結果を特定するものです。最も効果的な行動規範は、コミュニティ全体（プロジェクトリーダーシップだけでなく！）の参加者を巻き込んだ共同プロセスを通じて作成されたものです。このように、行動規範の構築は、強力なコミュニティ構築の取り組みとなり得ます。 + +すべての行動規範に必要となる中核的な項目は以下の通りです。 + +1. 推奨される行動の明示 +2. 禁止される行動の明示 +3. 違反報告の連絡先 +4. 執行メカニズムの説明 + +初期段階では、報告の受け手と規範執行者の両方がプロジェクト創設者自身である可能性が高いです。プロジェクトが成長するにつれ、専用の規範委員会を設置する必要がありますが、すぐに必要というわけではありません。 + +### 貢献プロセス + +貢献者を募集するには、プロジェクトへの貢献方法の基本を伝える必要があります。GitHubやGitLab上のプロジェクトでは、通常CONTRIBUTING.mdというドキュメントに記載されますが、プロジェクトのホームページからリンクされていれば、どこに記述しても構いません。既に「貢献者」の役割を文書化している場合は、それを貢献ドキュメントとして流用できます。未作成の場合は、以下の項目を貢献ドキュメントに含めることを推奨します。 + +1. 他の貢献者との連絡手段 +2. 初めてのコード・ドキュメント・その他の貢献の提出方法 +3. テストやフォーマットに関する詳細な要件 +4. レビュープロセスで何が期待されるか +5. メンバーシップ/貢献者ステータスを取得する条件 + +プロジェクトによっては、貢献を受け入れる前に提出が必要な書類があります。例えば、開発者証明書（DCO）や貢献者ライセンス契約（CLA）、本人確認証明書、GPGキーリングなどです。貢献ドキュメントに、これらの手順を段階的に説明してください。 + +### コミュニケーション情報 + +ほとんどのオープンソースプロジェクトでは、メール、チャット、イシュー、コードレビュー、ビデオ会議、さらには対面会議など、プロジェクトメンバーが相互に連絡を取る複数の手段が存在します。プロジェクトが使用するチャネルと参加方法を明記する必要があります。この情報を常に最新の状態に保つことも重要です。 + +ユーザーフォーラムと貢献者向けチャネルの両方をリスト化しておくと、質問の適切な場所が分かりやすくなります。公式なプロジェクト業務用の媒体と、一般的な議論用の非公式チャネルを明確に区別してください。メーリングリストの存在すら知らなかった貢献者に「ああ、それはメーリングリストで決めたことだ」と言われるのは、非常に苛立たしいことです。定期的なミーティングはカレンダーへのリンク、または少なくとも次回開催情報を記載してください。また、年次開発者会議などコミュニティの重要なイベントがあれば言及しましょう。 + +詳細は本ガイドブックの「オープンソースプロジェクトにおけるコミュニケーション規範」の章を参照してください。 + +### リーダーシップ選出／選挙プロセス + +「リーダーシップ」の役割を既に文書化している場合、プロジェクトメンバーがリーダーになる方法に関する情報はその一部となります。ただし、役割文書化が未完了のプロジェクトや、追加文書が必要な多段階選挙手続きを採用するプロジェクトも存在します。選挙・選出プロセスの簡易リファレンスを求めるケースもあります。 + +典型的な新規小規模プロジェクトの場合、この文書は極めて簡潔で、創設者兼プロジェクトリーダーのリストのみを記載すれば十分です。自己任命制の評議会がある場合も、それほど複雑ではありません。選出方法を書けばよいのです。 + +本格的な選挙を実施するプロジェクトでは、選挙に関するすべての規定（投票権者、投票の実施方法と実施者、スケジュール、候補者の選出方法など）を含む、より長い文書が必要になります。選挙の実施に関する追加のアドバイスは、この章の終わりで提供します。 + +### 貢献者昇格 + +プロジェクトに複数の貢献者レベルが存在し、それらの間で明確な昇格経路（いわゆる「貢献者ラダー」）が定義されている場合、その仕組みを説明する文書を作成すると有用です。これにより新規貢献者は今後の道筋と昇格に必要な行動を理解できます。また昇格が公平に行われる保証にもなります。 + +公平性を保つため、昇格ルールは可能な限り客観的に設定することが望ましいです。例えば「サブプロジェクトでコードレビューを継続的に支援している」は良い基準ですが、「過去3ヶ月間にサブプロジェクトで少なくとも40件のコードレビューを完了している」の方がより優れています。定量化可能なルールは、発言は控えめでも価値ある貢献をしているメンバーを見落とすのを防ぎます。 + +貢献者レベルが数種類しかない小規模プロジェクト（例：貢献者とオーナー）では、別途文書化する必要はありません。 + +### リリースプロセス + +ソフトウェアのリリースには、現在のリリースに含める内容と除外する内容の決定が伴います。プロジェクトが小規模な場合は比較的明白ですが、複数の雇用主のもとで働く貢献者がいる大規模プロジェクトでは、何を残し何を削除するかの決定は政治的になる可能性があります。サポートするプラットフォームの決定も議論を呼ぶことがあります。そのため、プロジェクトが成長するにつれて、リリースに関するプロセスを文書化することが必要になります。 + +リリースチームを定義しているプロジェクトでは、この文書は主にリリースチームの役割文書集となります。他のプロジェクトではメンテナがリリースを担当しますが、その場合でも、何が含まれるかをどのように決定するかを説明することは価値があります。これは必ずしもリリース方法の変更を意味するのではなく、特にどの機能やパッチを除外するかを決定する方法を、実際のプロセスを文書化することを意味します。リリース発表文の作成・編集プロセスも、特に複数ベンダーが関与するプロジェクトでは重要です。 + +本ドキュメントには、サーバーの設置場所、パッケージ構築コマンド、ミラー同期の待機時間など、ガバナンス以外の技術的内容も多く含まれます。大半が技術的な手順説明となるでしょう。ただし、_方法_だけでなく_誰が_、_なぜ_行うのかも必ず明記してください。 + +### セキュリティ問題の報告と対応 + +プロジェクトのコードが外部ユーザーによって本番環境で使用されるようになると、セキュリティ問題報告の管理が最優先事項となります。このトピックは単独で一章を割く価値がありますが、セキュリティ問題対応に関連する基本的なガバナンス設定があります。これには以下が含まれます。 + +1. セキュリティチームのメンバー選定方法、選定時期 +2. セキュリティ報告の送信先 +3. 機密保持要件を含む対応方法 +4. セキュリティ研究者が期待できる見返り +5. 開示までの待機期間 + +機密保持要件は、セキュリティチーム自体と、協力するプログラマーやセキュリティ研究者の双方にとって特に重要です。例えば、セキュリティ研究者は、プロジェクト側が発見を公表するまで自らも公表しないことを承諾しますが、それはプロジェクト側のセキュリティチームも同様の約束をする場合に限られます。多くのプロジェクトでは、セキュリティチームメンバーは自社雇用主に対しても特定情報を共有できません。 + +### 商標の使用 + +プロジェクトが人気を得ると、商業・非商業を問わず様々な団体がプロジェクト名・文字商標・グラフィックロゴの使用を求めます。支援表明、プロジェクト名をプリントしたシャツの販売を希望する第三者、派生プロジェクトなど、あらゆるケースにおいて、プロジェクト側はこうした主体が使用に関する公式方針に従うことを必要とします。たとえ政府機関への商標登録をまだ行っていない場合でも、方針と許可のパターンを確立することは、将来的にプロジェクト名やマークを保護する助けとなります。 + +このような方針は4つの要素で構成されます。 + +1. 許容される使用に関する一般的な声明 +2. 具体的な許可申請や問い合わせ先の連絡先 +3. これらの申請を処理する担当チーム・委員会・貢献者の指定 +4. 商標管理チーム向けの追加ガイドライン + +実際の許容使用範囲の声明文やガイドラインについては、プロジェクトは法的支援を得るべきです。ガバナンス面では、「商標管理チーム」（既存の運営委員会などが該当）の選定と、ガイドラインの更新・変更方法の決定が重要です。複数の技術ベンダーが運営するプロジェクトでは、プロジェクト自体のスポンサーがほぼ即時的にその商標を使用したがるため、プロジェクト初期段階でこれを明確にすることが極めて重要です。この責任をプロジェクトのステークホルダー間で共有していることを確認してください。 + +セキュリティ問題と同様に、商標チームは機密保持が必要な問い合わせに対応できる必要があります。なぜなら、リリース前のスタートアップ企業がプロジェクト名を使用したい場合があるためです。 + +## コミュニティ選挙の実施 + +コミュニティプロジェクトが成長するにつれ、多くのプロジェクトがコミュニティ代表者を選出することを選択します。このプロセスは、創設者がコミュニティを去った場合、グループが「統治技術評議会」ガバナンスモデルへの移行を決定した場合、またはプロジェクトが有料会員制の非営利統治団体に移行した場合などに発生します。 + +状況にかかわらず、多くのプロジェクトは選挙を通じてコミュニティ代表者を選出することを選択します。歴史的に、投票システムの選択、有権者の定義、適格候補者のプール制限は、コミュニティプロジェクトにとって複雑な課題でした。 + +本節では、投票権の付与対象、立候補資格、選挙の実施方法を含む、プロジェクト選挙のベストプラクティスを要約します。 + +### 選挙権者と立候補資格者 + +選挙権のルール設定は極めて重要です。プロジェクトサイトに登録した者なら誰でも投票を許可する（非常に低いハードル）一方で、立候補資格をプロジェクトコミッターに限定する（高いハードル）プロジェクトも存在します。しかし、ほぼ全てのプロジェクトは最終的に候補者プールを拡大し、有権者プールと同等にします。したがって選挙で投票できる者は誰でも候補者となる資格を持つことができます。 + +プロジェクトは通常、有権者と候補者プールの定義において以下の3つのアプローチのいずれかを取ります。 + +1. **高いハードル：** 投票者はコミッター、メンテナ、コアコントリビューターなどの内部グループのメンバーである。メンバーシップには長期間の参加歴と仲間から認められた経験年数が必要。 +2. **中程度のハードル：** 明確に定義された参加基準を満たす限り、アクティブな参加者や財団メンバーが投票できる。 +3. **低いハードル：** プログラムへの登録やメーリングリストへの参加など、基本的な手順を完了すれば誰でも投票できる。 + +「参加」の定義となる活動指標と最低基準の設定は、主に適格参加者を区切る恣意的な線引きを伴うため、議論を呼ぶことがあるります。一般的に、プロジェクトでは有権者となるには定量化された継続的な参加が必要と規定されます。 + +選挙における一般的な懸念として、投票操作や集団効果があります。これは大企業が多数の投票ブロックを保有することで代表機関を支配したり、候補者の知人が低ハードルをクリアして投票権を得て単に支持候補に投票したりする現象です。しかし大半の場合、こうした懸念は根拠がありません。技術コミュニティはシステムの悪用を防ぐルールを設けようとすることが多いですが、こうしたルールは往々にして「時期尚早な最適化」に陥ります。これは『コンピュータプログラミングの技法』の著者Donald Knuth[^knuth]が「あらゆる悪の根源」と名付けた概念です。特別なルールを避け、選挙プロセス上の問題は発生時に都度対処する方が、一般的に優れた実践と言えます。 + +最後に考慮すべきは、選挙における立候補プロセスです。最も一般的な選択肢は自己推薦であり、候補者は選挙情報と立候補理由を投稿します。別の選択肢は推薦であり、これは通常自己推薦と同義となります。候補者は通常、他者に自分を推薦し、その推薦を支持するよう依頼するからです。 + +### 投票システム + +もう一つの複雑なコミュニティ決定事項が投票システムです。どのコミュニティにも、投票方法や票の集計方法に熱心な人々が存在します。適切な配慮なしでは、これらの問題に関する議論は数ヶ月も続き、実施がほぼ不可能な提案を生み出す可能性があります。 + +ほとんどのコミュニティプロジェクトでは以下を採用しています。 + +1. 秘密投票による投票 +2. オンライン投票（各人が1回のみ投票できることを保証する個人トークン付き） +3. 候補者を優先順位でリスト化する何らかの優先順位投票 +4. [コンドルセ方式](https://en.wikipedia.org/wiki/Condorcet_method) または [単記移譲式投票](https://en.wikipedia.org/wiki/Single_transferable_vote) (STV) による得票集計と当選者決定 + +一部のプロジェクトでは、依然として「単純小選挙区制」や加重投票システムといった代替投票方式を採用しています。後者の場合、有権者は12個のトークンを受け取り、自由に候補者に配分でき、最も多くのトークンを獲得した候補者が当選します。 + +いくつかのプロジェクトではオンライン集計ソフトウェアを採用しています。検討すべき選択肢には以下が含まれます。 + +1. [Condorcet Internet Voting Service](http://civs.cs.cornell.edu/)：無料のオンライン投票・コンドルセ集計システム +2. [OpaVote](https://www.opavote.com/)（旧称OpenSTV）：商用選挙集計サービスとしてのソフトウェア（SaaS） +3. [OpenSTV](https://github.com/Conservatory/openstv) - 以前は一般公衆利用許諾契約書（GPL）で提供され、現在も複数のプロジェクトで選挙集計に使用されています。 +4. [Helios](https://vote.heliosvoting.org/) - オンライン投票と複数の異なる集計方法を可能にする別の無料選挙サービス + +### 始め方 + +選挙制度を提案する場合は、まずミッションステートメントから始めましょう。 + +例： + +> 目的は、技術運営委員会がプロジェクトの技術的範囲と方向性の定義において、コード以外の貢献をコード貢献と同等に評価し、プロジェクトに積極的に貢献する全員を代表することを保証することです。 + +ミッションステートメントは、選出された機関が誰を代表するのか、その権限は何か、なぜ選出されるのかを明確にします。選出された組織の目標について合意したら、代表される組織の構成員を定義する最もシンプルな方法を選択します。次に、可能な限りシンプルな投票および集計システムを選択します。 + +[^knuth]: Knuth, Donald E, _The Art of Computer Programming_. Reading, Mass: Addison-Wesley Pub. Co, 1968. diff --git a/l10n/ja/growing-contributors/understanding-community-roles.md b/l10n/ja/growing-contributors/understanding-community-roles.md new file mode 100644 index 00000000..6bb3fabc --- /dev/null +++ b/l10n/ja/growing-contributors/understanding-community-roles.md @@ -0,0 +1,192 @@ +--- +description: +author: Andy Oram , Karsten Wade +updated: 2020-12-12 +translated-by: Ken Komazawa powered by DeepL Pro +--- + +# コミュニティの役割を理解する + +オープンソースコミュニティにおける役割は、その役割がコミュニティや様々なコミュニティの成果物に参加し、協力し、貢献する方法に基づいて定義されます。オープンソースプロジェクトへの貢献は、コードを書くことだけが最も価値のある方法だという誤解が一般的です。「すべての貢献は等しく価値がある」という言葉が、取るべき最善のアプローチを要約しています。 + +その一環として、未来を予測しようとしないことが重要です。どの貢献や貢献者がプロジェクトに永続的な影響を与えるか、文字通り知ることも予測することも不可能です。例えば、小さな貢献の積み重ねは、少数の大規模で派手な貢献と同等の影響を容易にもたらし得ます。誰かが短期のユーザー体験ワークショップに参加し、その短い関わりを超えて自らも気づかない貴重な永続的影響を与えることもあるのです。 + +全ての貢献が等しく重みを持つべき最も重要な理由は、コミュニティが人々で構成されており、これらの人々の感情や経験が文字通りコミュニティそのものだからです。各人がコミュニティにもたらすもの——彼らの貢献——は、プロジェクト内で非常に個人的な通貨となり、誰が何を任せられるかを判断する基準となります。 + +歓迎的でインクルーシブ（包摂的）なコミュニティにおいて、人々が時間をかけてスキルを磨くにつれ、貢献の性質が何であれ、その影響力は一人の手の届く範囲をはるかに超えていきます。役割の範囲内で、そしてそれを超えて自らを伸ばすことを許されることで、人々は最大の可能性へと成長できるのです。この「許されること」が表れる一つの形は、貢献の種類の違いに対するあらゆるレベルの判断、価値の違い、あるいは恥さえも取り除くことです。 + +つまりこれは、世界において全ての人が等しく価値を持つことを認め、彼らが日々もたらすものを、その瞬間の「人間としての最善」として単純に評価すべきだという考え方です。これは包摂性を実現する意義深い方法であり、個人がその日どのような形で参加し行動しようとも、100%の貢献者であることを許容するものです。 + +## 貢献の方法 + +参加したいプロジェクトやグループへの貢献方法を考えるのに早すぎることはありません。そうすることで、プロジェクトはあなたのニーズや全ユーザーのニーズを満たすために大きく前進します。さらに、安全な環境でスキルを向上させ、一緒に働く人々を通じてネットワークを構築し、認められる機会を得られます。 + +この文書では、貢献者が担ういくつかの役割について説明します。学術論文向けの[CRediT]()プロジェクトが役割をどのように定義しているか（類似点や相違点）を確認するのも興味深いでしょう。 + +### 文書作成 + +ドキュメントやトレーニング資料は、人材募集や新規メンバーの生産性向上に不可欠です。技術文書の作成は、過小評価されがちな主要な貢献の一つです。あるブロガーが指摘したように[（原文リンク）](http://www.praxagora.com/andyo/professional/documentation_conversations.html)、「コンピュータ文書の扱いは政府資金に似ている。誰も貢献したがらないが、必要な時には誰もが存在を望む」。本節では文書作成の手順を解説します。 + +#### ドキュメントの提案 + +プロジェクトやチームのドキュメントに不足点を見つけたら、プロジェクトリーダーに直接相談するか、コミュニティフォーラムで該当トピックのドキュメント作成者がいないか尋ねてみましょう。GitHubやGitLabのような「イシュー」機能があるサイトでは、イシューを作成してドキュメント作成をリクエストすることも可能ですが、まずは非公式に「誰か作成中ですか？」と尋ねる方が簡単です。 + +必要なドキュメントの作成者が既にいる場合は、レビュー担当として協力することを申し出てください。場合によっては執筆者として関わることも可能ですが、執筆者は異なる担当者が割り当てられたトピックを明確かつ適切に分離するよう注意が必要です。ドキュメントはソフトウェアに比べてモジュール化が不十分な傾向があります。 + +誰もドキュメントを作成しておらず、コミュニティやプロジェクトリーダーが新規ドキュメント作成を支持する場合、次の疑問が生じます：最適な執筆者は誰か？通常、答えは「あなた自身」です。そのトピックに詳しい人は他にもいるかもしれませんが、彼らがまだ文書を作成していないのは、多忙、執筆が苦手、その他の理由でできないからでしょう。最適な執筆者は文書を書きたいという意欲を持つ人であり、あなたが提案したのなら、おそらくその人物はあなた自身です。専門知識を持つ人はアイデアを提供したり、あなたの文章をレビューしたりできます。 + +この段階で、正式な発表（例：イシュー作成）を行ってください。文書完成へのプレッシャーを与えるため、締切日を設定することをお勧めします。文書はレビューが必要であり、プロジェクトに数週間追加される可能性があることを忘れないでください。また、以下のようなマイルストーンを設定することも有用です。 + +1. 執筆開始 +2. 初稿の回覧 +3. 初稿のレビュー期間終了 +4. 最終稿の回覧 +5. 最終稿のレビュー期間終了 +6. 承認申請 +7. 承認・公開 + +プロジェクトへの参加には、当該プロジェクトの責任者またはアドバイザーグループの承認が必要です。リーダー陣は文書作成プロジェクトを寛大に承認すべきです。プロジェクトに関連する新規文書は、少なくとも一部のメンバーにとって有用であることが通常証明されるためです。 + +#### 執筆者になるには + +リーダーシップから文書作成の承認を得た後、以下の手順を踏んでください。 + +#### ツールを学ぶ + +チームが使用する推奨フォーマット（Asciidoc、Markdownなど）を確認してください。ほとんどのプロジェクトでは、文書をソースコードファイルと同様に統合しています。これにより、文書に関するバグ報告などのタスクに特別なツールやプロセスを用意する必要がなくなります。 + +#### 関連文書に精通する + +新規文書の必要性を調査する際、プロジェクトの既存ドキュメントを確認したはずです。執筆開始前には、オンライン検索を行い、類似プロジェクトのドキュメントも参照してください。読者の背景知識となる関連文書や動画、あるいは文書読了後に参照できる高度な情報源へのリンクを収集しましょう。 + +プロジェクト内や他プロジェクトの既存文書（類似トピック）を参照すると執筆のきっかけになります。開発者やエンドユーザーなど、自文書と同等の読者層を対象とした文書を探しましょう。 + +#### 執筆基準 + +文書作成は熟練度が分かれるスキルですが、未経験者でも有用な文書を作成するための指針があります。 + +* 常に読者を意識すること。対象読者を定義することは、主題選定後の文書計画において最も重要な部分です。以下のような質問を自問してください：読者の大半は私が使用する専門用語を理解しているか？エンドユーザーは開発者が扱う技術的詳細を知る必要があるか？リソースの使用方法を説明する前に、そのリソースの検索方法を記述する必要があるか？ + +* 手順は小さなステップに分割したプロセスとして構成しましょう。特に順序リストとして提示すれば、通常最も理解しやすい指示となります。記憶に頼って書かないでください：記述中は必ず手順を実際に実行しながら進めてください。そうしないと、ステップを忘れたり誤った説明をしたりする可能性が極めて高くなります。 + +* 文書を構造化しましょう。文は短く保ち、長い段落は分割します。頻繁に新しい見出しを付けましょう。あるセクションで十数段落以上書き、それをさらに分割する方法がわからない場合は、おそらく流れの悪い、構成の悪い文章を作成している可能性があります。 + +#### 文書作成 + +通常、著者は文書作成前に概要を回覧しレビューを得るべきです。概要は重要なトピックを網羅しつつ、不要な内容を排除します。レビューアは構成の再編成も提案できます。ただし、概要を実際の文書に落とし込む過程で、著者はトピックを追加したり移動させたりする理由をしばしば見つけます。 + +関連文書への参照は、ほとんどの文書において重要な要素です。前述の通り、著者は関連文書を調査し、それらを含めるべきです。インラインリンクは有用であり、特に読者が文書を理解するために特定の基本情報を学ぶ必要がある場合に、背景情報へ誘導するのに効果的です。ただし、一般的に最も有用なのは、文書の末尾に参考文献セクションを設けることです。 + +#### 文書のレビュー + +文書のレビューはクラウドソーシング方式で行われます。つまり、知識や能力、正式な訓練、人種、性別、地理的場所などが異なる多様な人々からのレビューを歓迎します。これにより文書の価値と可読性が大幅に向上します。 + +誤りと思われる点や不足している情報を指摘してください。多忙な読者が時間を割けるよう、文書は簡潔に保つよう努めていることをご理解ください。優れた文書やその他のリソースへの参照は大変貴重です。 + +編集、校正、スペルチェックも貢献の有効な手段です。 + +レビュー作業は、自身の文書作成に向けた当グループの文体やスタイルを習得する良い機会となります。 + +### 運営委員会への参加 + +これらの委員会もリーダーを必要としています。数か月間参加した後、リーダーシップポジションへの昇格をご検討ください。グループの目標に関連する専門知識は有用ですが、リーダーはタスクの調整、会議の進行、その他の組織業務を通じて貢献することもできます。 + +### 他のボランティアの募集 + +尊敬する友人や同僚からの個人的な呼びかけが、新しいチームメンバーを募集する最も効果的な方法です。支援したいプロジェクトを見つけたら、チームに価値ある人材として加わる可能性のある人々を考えてみてください。プロジェクトの目標やチームの運営方法を説明できるほど理解を深めたら、新規メンバー候補者に声をかけてみましょう。 + +### ボランティアへの一般的なガイダンス + +ほとんどのボランティアはプロジェクトに有益な知識を持ち込み、参加する中でさらに学びを深めます。この知識は様々な方法で共有できます：フォーラムやチャットでの質問への回答、メンタリング、グループミーティングへの参加などです。 + +### ソフトウェアとドキュメントの翻訳 + +**翻訳とは？** + +ソフトウェアのインターフェースやドキュメントを別の言語に翻訳することです。その結果、ユーザーが好みの言語でインターフェースやドキュメントを読めるように*ローカライズ*されたソフトウェアパッケージが完成します。 + +**翻訳者の役割は？** + +ツールやプロセスを活用し、ソフトウェアのインターフェース、ドキュメント、マーケティング資料、リリースノートなどを一つ以上の言語に翻訳します。多くのプロジェクトでは共通のプロセスやモデルが採用されているため、あるソフトウェアプロジェクトでの翻訳スキルは別のプロジェクトでも再利用可能です。Fedora LinuxなどのLinuxディストリビューションでは、オペレーティングシステムの全部分を数十言語に翻訳する翻訳者が活動しています。 + +**この役割が好まれる理由** + +オープンソースソフトウェアの普及に貢献する一つの方法として、ソフトウェアやドキュメントを現地語に翻訳する活動があります。彼らはこれを、自由でオープンソースなソフトウェアの恩恵を自らの地域にもたらす手段として活用しています。 + +### プロジェクトシステムの管理支援 + +**システム管理とは？** + +プロジェクトに代わって運用可能なコンピューティングシステムを構築・維持することです。既存システムや計画内容に応じて、システム管理/運用/DevOpsの幅広い経験が求められる場合があります。 + +**システム管理者の役割は？** + +プロジェクトの基盤となるインフラストラクチャのあらゆる側面を担当します。このインフラは、プロジェクトへの参加や共同作業を可能にする手段を提供します。 + +**この役割が好まれる理由** + +新しいスキルを学び、新しい技術と取り組むこと。多くの場合、人々は専門職としてではなくても、真剣な趣味としてこの仕事を行う経験や傾向を持っています。特に現代の自動化技術により、システム管理の役割は変化し続けています。 + +### 資金調達とスポンサーシップの組織化 + +**資金調達とは？** + +プロジェクトとコミュニティを支援するため、資金・ハードウェア・サービスの寄付に興味を持つ個人や組織を探す活動です。スポンサーシップは多様な形態を取ります。現金寄付を受け入れられないプロジェクトでは、イベント参加権、渡航支援、ブーススタッフ提供などの形で提供されることが一般的です。 + +**資金調達担当者の役割は？** + +プロジェクトリーダー、財団などの親組織、寄付やスポンサーシップに関心を持つ個人・組織と連携します。スポンサーシップの詳細（単発か継続的キャンペーンの一部）を調整し、契約の諸条件を確定します。スポンサーシップ、資金、助成金など、寄付形態に応じた追加的な管理業務を含む場合があります。 + +**この役割が好まれる理由** + +オープンソースコミュニティの持続可能性を創出する重要性を理解し、変化をもたらしたいと考える人々です。個々にとって取り組みをより興味深く価値あるものにするスキルや性格的特徴を持っている場合もあります。 + +### マーケティングの実務面 + +**マーケティングとは？** + +オープンソースソフトウェアにおいて、マーケティングとはコミュニティとそのソフトウェア活動を促進する行為を指します。市場調査や広告などの他の実践は、通常コミュニティ内部では行われません。 + +**マーケターは何をするのか？** + +プロジェクトの様々な部門と連携し、ユーザーが求めるものや必要とするものを理解する手助けをし、そのメッセージを簡潔にまとめ、広く発信します。オープンソースにおけるユーザーからのフィードバックは、バグ報告やユーザーヘルプの形で開発チームに直接届くことが多く、クローズドなソフトウェア開発手法とは異なり、コンテンツやコードに最も近い貢献者はユーザーベースについて高い知識を持つ傾向があります。マーケターは、その情報を収集・明確化・整理し、機能セットやロードマップとして優先順位付けする支援が可能です。 + +**この役割が好まれる理由** + +「全てがデジタル」という視点を超えた現代のマーケティングに関心を持つ人々は、オープンソース開発のプロセスそのものに、世界のブランドが掲げる真実性・開放性・透明性といった特徴が反映されていることに気づきます。 + +### プロジェクトのアウトリーチ推進支援 + +**アウトリーチとは？** + +ユーザー、参加者、潜在的な貢献者、そして一般社会との繋がりを構築する業務です。これらの繋がりはマーケティング以上の目的を持ち、採用活動、ユーザー支援、フィードバック収集、オーディエンス分析、技術サポートなどの側面を含む場合があります。 + +**アウトリーチコーディネーターの役割とは？** + +プロジェクト内のクリエイター（コード、コンテンツ、デザイン、マーケティングなど）と直接連携し、プロジェクトから様々なフォーラムへの双方向の窓口として機能します。フォーラムとは、プロジェクトが運営するウェブベースのフォーラムやメーリングリスト、ブログや技術系ジャーナリスト、ユーザーが質問や回答を求めるウェブサイトなどを指します。アウトリーチ担当者はプロジェクトのほぼ全側面について一定の知識を持ち、プロジェクトの各部分と外部世界との接点を特定・構築できる能力を有します。 + +**この役割が好まれる理由** + +この役割は、人々やプロセスを理解し、それらについて伝えることを伴います。プロジェクト内で本来なら声が届かない人々の代理人となり、それらの声を前面に押し出す機会となります。 + +### コミュニティの活性化・管理・アーキテクチャに焦点を当てる + +**コミュニティアーキテクチャとは？** + +オープンソースプロジェクトの成功はコードベースと同様にコミュニティに依存するため、ほとんどのプロジェクトでは、コミュニティそのものを設計・維持する役割を最優先事項として、公式または非公式に担当する人材が存在します。 + +**コミュニティアーキテクトの役割とは？** + +この役割の中核として、本ガイドブックに記載された数多くのベストプラクティスを把握し、監督または直接実施します。この役割が複数人で担われる場合やパートタイムスタッフのみの場合、関与する人々はプロジェクトに最も関連性の高いプラクティスに焦点を当てる傾向があります。このように、コミュニティ管理／活性化リソースが限られているプロジェクトでも、最終的には重要な部分を確実に遂行できます。 + +**この役割が好まれる理由** + +この役割は、コミュニケーションや協働、人との繋がりづくりを楽しむ人向けです。自身の成功と同じくらい、他者の成功を見守り（もちろんその成功を共に祝うことも含め）、そこから喜びを得られることが望ましいです。また、多岐にわたる様々な業務に興味とスキルを持つ人（何でも屋）にとっても魅力的な役割です。 + +## その他の技術的役割 + +特定の分野向けに開発可能なソフトウェアの種類が多岐にわたることは、ここに当てはまる役割の幅を示唆しています。地理情報システム（GIS）プロジェクトにおける地理学者のように、特定の技術的スキルを指す場合もあれば、複雑な問題解決にしばしば必要となる一般的な技術的能力を指す場合もあります。 + +## まとめ + +本章では、オープンソースプロジェクトで担える役割の例をいくつか紹介しました。このリストは網羅的ではありませんが、挙げた役割について、その内容と人々がそれらを担う理由について概略を示しています。 diff --git a/l10n/ja/growing-contributors/what-is-a-contribution.md b/l10n/ja/growing-contributors/what-is-a-contribution.md new file mode 100644 index 00000000..6e25b081 --- /dev/null +++ b/l10n/ja/growing-contributors/what-is-a-contribution.md @@ -0,0 +1,52 @@ +--- +description: +author: Karsten Wade +updated: 2020-12-16 +translated-by: Ken Komazawa powered by DeepL Pro +--- + +# 貢献とは何か? + +オープンソースプロジェクトへの「真の」貢献はコードと、場合によってはドキュメントだけだという誤解が広く存在します。この恐ろしい考え方には「コードこそが王様」という、歴史に埋もれるべき名前がついています。もうそんな考えは捨てましょう。 + +実際のところ、貢献の方法はこれら2つだけにとどまらず、指数関数的に多く存在します。そしてプロジェクトや、多様な貢献者グループにとっての価値も指数関数的に大きいのです。 + +**オープンソースへの貢献** + +オープンソースコミュニティのライセンスのもと、そのコミュニティに無償で提供される、独創的で意図的かつ実質的なあらゆる成果物のことです。貢献は個人またはコミュニティから生まれます。 + +**オープンソース貢献者** + +コミュニティへの貢献に関わる個人のことで、コミュニティは本質的に人間関係で成り立ちます。組織ではなく人間で構成されます。組織は、メンバーやスタッフ、リーダーなどを貢献者としてコミュニティに送り出すことができます。 + +具体的な貢献（オブジェクト）の例： + +* アイデア +* 設計提案 +* プロセスの作成または改善 +* 持続的な取り組みの実行 +* ドキュメント、リリース告知、インタビュー、ハウツー記事、運用ページなどのコンテンツ +* 機械に動作を指示するコンテンツの一種であるコード（コードの種類は問わない） +* サーバーや貢献者向けギフトなどの物理的資材 +* 可能かつ歓迎される場合における金銭的貢献 （多くのオープンソースプロジェクトでは、これが常に容易な貢献方法とは限らず、場合によっては不可能な場合もある。） +* フォーラムのモデレーターを務めること +* イベントでの支援 +* リリースマネージャーを務めること +* ウェブサイトのデザイン +* 自動化スクリプト +* テストスイート +* テストとバグ報告 +* 2つのプロジェクト間の関係構築 +* マーケティング計画の策定 +* ロードマップの作成 +* コミュニティ内の取り組みにおけるプロジェクトマネジメント（PM）スキルの発揮 +* 定量的・定性的分析の実施 +* ロゴの作成 +* プロジェクト行動規範の策定 +* 法的配慮に関するプロジェクト支援 +* 貢献者／メンテナ／リーダー募集プロセスの構築 +* その他 + +カスタマーサービスからプロダクトマネジメントまで、職務で習得するほぼあらゆるスキルが貢献の基盤となり得ます。他のコミュニティが抱えるであろうあらゆるニーズは、オープンソースコミュニティのニーズとなり得るものであり、貢献の基盤を形成し得ます。 + +貢献の種類の幅と深さを意識しておくことは有益です。コミュニティ管理の実践の一環として、人々がプロジェクトに貢献する多様な方法を認識する必要があります。そうすることで、個々の行動を全体やより大きな取り組みへと結びつけ、貢献に対して感謝の意を示すことができるのです。 diff --git a/l10n/ja/guiding-participants/README.md b/l10n/ja/guiding-participants/README.md new file mode 100644 index 00000000..e9ba27f6 --- /dev/null +++ b/l10n/ja/guiding-participants/README.md @@ -0,0 +1,33 @@ +--- +description: +author: Karsten Wade +updated: 2020-12-11 +translated-by: Ken Komazawa powered by DeepL Pro +--- + +# 参加者のガイド + +オープンソースプロジェクトにおける「参加」とは、説明するのが興味深く、かつやや曖昧な概念です。「私はただのユーザーです！それ以上のことは話さないでください」と「このプロジェクトにどう貢献できるでしょうか？」を分ける境界線は、一見明確に見えます。しかし、プロジェクトへの積極的な参加は、誰かがソフトウェアを単なる消費以上の形で気にかけ始めた瞬間に始まります。そしてオープンソースソフトウェアは本質的に包摂的で参加型であるため、ほとんどの*ユーザー*は*参加者*へと、非常に迅速かつ容易に移行します。プロジェクトのブログにコメントを残す、プロジェクトのトラッカーに問題を報告する、ソーシャルメディアでプロジェクトと関わる——こうした行為だけで十分なのです。オープンソースソフトウェアを使用する時点で、彼らは*すでに*ソフトウェアをより良くするプロセスに参加し始めているのです。 + +参加の様々な形態の例を以下に示します。 + +* 友人に対して、そのソフトウェアやオープンソースプロジェクトの目標をいかに気に入っているかを話すこと。 +* カンファレンスやイベントで、そのソフトウェアについて廊下やブース脇で議論すること。 +* 様々なフォーラムで、そのソフトウェアに関する質問を投稿し、賛成票を投じ、回答すること。 +* ノートパソコンにステッカーを貼って、そのソフトウェアへの支持をアピールすること。 +* ソフトウェアやプロジェクトについて、貢献者に対して建設的なフィードバックを提供すること。 +* 他の人にソフトウェアの導入や使用を勧め、支援を申し出ること。 + +このセクションには以下の章が含まれます。 + +* 参加意欲の背景にある考え方と原動力について論じる章。 +* 積極的な参加者がプロジェクトにどのような利益をもたらすかについて詳細を提示する章。 + +このセクションは、以下のような場合に役立ちます。 + +* 関与度の低いユーザー、熱心な参加者、積極的な貢献者で構成されるコミュニティの違いを理解したい場合。 +* 貢献への道筋において、人々を参加に駆り立てる要素を理解したい方。 +* 自身の参加コミュニティの体験を向上させたい方。 +* 参加者が貢献者へと成長するための架け橋を構築したい方。 +* オープンソースソフトウェアにおけるユーザーフィードバックの利点を探求したい方。 +* このガイドブックを最初から読み進め、中盤に到達し、終盤へ向かっている方。 diff --git a/l10n/ja/guiding-participants/incentivizing-and-rewarding-participants.md b/l10n/ja/guiding-participants/incentivizing-and-rewarding-participants.md new file mode 100644 index 00000000..372a38f2 --- /dev/null +++ b/l10n/ja/guiding-participants/incentivizing-and-rewarding-participants.md @@ -0,0 +1,78 @@ +--- +description: +author: Bryan Behrenshausen +updated: 2021-09-15 +translated-by: Ken Komazawa powered by DeepL Pro +--- + +# 参加者の動機付けと報酬 + +前章では、オープンソースプロジェクトに参加し貢献する参加者の動機について論じました。オープンソースプロジェクトへの参加を促す動機は数多く存在します。外発的動機付け（貢献に対する金銭的報酬の約束など）もあれば、内発的動機付け（コミュニティ開発ソフトウェアへの貢献という利他的な欲求など）もあります。これらの動機の性質が何であれ、コミュニティマネージャーやアーキテクトはそれらを理解する必要があります。なぜなら、理解することで、現在および将来の参加者にとってよりやりがいのあるプロジェクトやコミュニティを設計し、最も望ましい貢献形態をより効果的に促進できるからです。本章では、繁栄するオープンソースプロジェクトとコミュニティにとって最も有益な行動を促進・奨励・報いるための様々なモデルと仕組みについて議論します。 + +## インセンティブと報酬について + +オープンソースコミュニティの管理者や設計者は、参加者が自身の貢献を評価されていると感じられる場づくりを目指します。貢献者が自身の仕事が重要だと感じれば、プロジェクトへの*継続的な*貢献意欲が高まり、その過程でコミュニティを強化し文化に影響を与えます。貢献者は、プロジェクトが彼らの貢献動機を*報酬*として満たす（あるいは何らかの形で報いる）場合に、オープンソースプロジェクトへの参加から最大の価値を得ます。コミュニティアーキテクトにとって、貢献者にやりがいのある体験を提供するための課題の核心は、参加者の動機と、プロジェクトへの貢献を報いる様々なモデルや仕組みを整合させることです。 + +しかし、誰もが同じ理由でオープンソースプロジェクトに貢献するわけではありません。例えば、オープンソースプロジェクトへの貢献動機に関する最近の研究（[https://https://arxiv.org/abs/2101.10291](https://https://arxiv.org/abs/2101.10291)）によれば、利他主義や仲間意識の追求が貢献者の動機に与える影響は、10年前よりも顕著になっています。さらに、参加者はプロジェクトへの*継続的な*貢献の動機が、*初期の貢献*の動機と必ずしも一致しないことを報告しています。ある人は、雇用主がアップストリーム（上流）への採用を望んでいたパッチを提供するためにプロジェクトに参加するかもしれませんが、プロジェクト参加者を仲間と認識し、メンバーとの連帯感を育んだ後、プロジェクトに残り続けることもあります。オープンソースコミュニティの構築には、参加者が価値を見出せる新たな活動や機会を提供することで、貢献者の絶えず変化する参加動機に対応し、継続的な貢献を促すことが含まれます。 + +オープンソースプロジェクトへの貢献者全員が、プロジェクトに深い関与を育むわけではありません。不定期でカジュアルな貢献者を、継続的で繰り返し貢献する存在に変えることは常に可能ではなく、また必ずしもそのことが目標であるべきでもありません。より重要なのは、参加者の貢献が、その貢献を*行う*動機とどのように整合し、あるいは反映しているかを理解し、それに応じて対応することです。[研究者Ann Barcombが記すように](https://opensource.com/article/17/10/managing-casual-contributors)「履歴書を充実させるため、あるいは煩わしいバグを修正するために貢献する人々は、その必要が満たされれば継続する可能性が低くなる」のです。しかし一方で、こうした定期的な貢献者（Barcombが「エピソード的貢献者」と呼ぶ層）は、複雑性が低く、説明しやすく、迅速に対処可能な課題を求める傾向が強くなります。これはまさに、長期貢献者が他者に解決を任せ、自身は他の課題に集中したいと願う類の課題です。 + +したがってコミュニティ管理者は、*自分たちが考える*「誰もがプロジェクトに参加・貢献する動機付けとなる体験」を創出しようと努めるよりも、参加者自身がプロジェクトに貢献する*固有の*動機を理解し、その動機を活性化・充足させるプロジェクト体験を設計すべきです。そうすることで（おそらく）より高いエンゲージメントが生まれます。これは、コミュニティメンバーとそのニーズを最優先するだけでなく、時間・リソース・知識・スキルの異なる貢献者が、自身にとって快適な方法でプロジェクトに関わり、他の参加者と同様のやりがいを感じられるようにするためにも極めて重要です。 + +## プロジェクトの報酬モデルを理解する + +オープンソースプロジェクトへの多様な貢献を認め称える戦略は、そのプロジェクトの「報酬モデル」と呼ばれます。プロジェクトが構築する報酬モデルが多様であればあるほど、異なる動機で貢献する参加者を効果的に巻き込めます。既に述べた通り、人々がプロジェクトに貢献する理由は様々であり、最も人気のあるプロジェクトとは、貢献の形態に関わらず、参加者に「報われた」「評価された」「尊重された」と感じさせるものです。こうした感情を参加者に抱かせることは、プロジェクトを「やりがいがあり、歓迎される場所」として評判を築く優れた方法です。ただし常に留意すべきは、コミュニティの報酬モデルが*報いる*行為を*奨励する*点です。人々はコミュニティが参加者をどう評価・称賛するかを理解すると、その称賛対象となる行動を自ら取るようになります。したがってコミュニティ管理者や設計者は、プロジェクト固有の報酬モデルを確立・修正する際、常に慎重に考え、意図的に行動すべきです。意図的か否かを問わず、彼らが報酬を与える行為こそが、人々にさらに多く行わせるよう促すものとなるのです。 +本章の残りの部分では、今日のオープンソースプロジェクトで広く採用されている報酬モデルをいくつか概説します。各モデルは、参加者がプロジェクトに貢献する動機となる特定の要素に訴えかけることを目的としているため、特定のモデルが最も有用となる状況を詳しく説明します。 + +### ポイントシステムとリーダーボード + +一部のオープンソースコミュニティでは、参加者がプロジェクトへの貢献履歴を追跡・公開できるポイントシステムとリーダーボードを導入しています。コミュニティは、促進したいプロジェクト活動（ドキュメントの誤字修正、パッチの提出、フォーラムでの新規ユーザー支援など）にポイント値を割り当て、それらの活動に従事した人に対応するポイントを報酬として付与します。ユーザーは、プロジェクトサイトやソーシャルメディアプロフィールに自身の累積ポイントを表示するオプションを選択できます。 + +ポイントシステムは貢献度を可視化し、その規模を公に示して参加者を報います。一部のコミュニティでは、さらに一歩進めてプロジェクトの「リーダーボード」を導入し、最も多くのポイントを蓄積した貢献者をリスト化しています。例えば、コミュニティが「トップ貢献者」や「今月最も活発な貢献者」のリストを維持することで、プロジェクトへの貢献を促す軽妙な競争を生み出す場合があります。実際、コード共有やコラボレーションプラットフォームの中には、この種の「リーダーボード」機能を標準装備しているものもあります。例えばGitHubリポジトリには、プロジェクトで最も活発な貢献者をハイライト表示する「Insights」タブが備わっています。 + +この報酬モデルは、技術的実力をアピールしたいという動機を持つ貢献者（自身の貢献の深さと幅を広く知らせられる）や、プロジェクトへの関与履歴を公開履歴書として記録したい貢献者との接点として有用です。要するに、コミュニティ内での貢献者の評判形成を支援する一つの手段です。また、プロジェクトの最も活発な貢献者を容易に特定し、さらなる関与を促したいメンテナにとっても有益です。 + +しかし特にリーダーボードシステムは、参加者にとって*やる気を削ぐ*可能性もあります。「競争を楽しみ、リーダーボードのスコアに反映される活動に従事する貢献者にとって、リーダーボードに掲載されるという願望は参加意欲を高める」と[コミュニティメトリクスの専門家Georg Linkは記しています](https://opensource.com/article/21/9/community-leaderboard)。「しかし、スコアに反映されない形で参加する貢献者は、リーダーボードに表示される機会が全くなく、むしろ意欲を削がれる可能性があります」とLinkは指摘します。リーダーボードシステムは、プロジェクト管理者が報酬対象と選んだ活動のみを評価する——つまり、どの貢献がより価値あるかを暗に示しているのです。そして全ての潜在的な貢献者が、まさにその方法で貢献するための時間、才能、リソースを持っているわけではありません。「結果として」とLinkは述べます。「リーダーボードは、オープンソースが直面する『歓迎的で包摂的な環境づくり』の問題を悪化させる可能性があります。なぜなら、リーダーボードがどれだけ優れた設計であっても、特定の貢献者のサブセットのみが報酬を得られるからです」 + +### バッジシステム + +ポイントシステムやリーダーボードと密接に関連するものが、コミュニティバッジシステムです。オープンソースプロジェクトへの貢献を参加者に報いるため、コミュニティは独自のデジタルトークンや「バッジ」を作成することがあります。貢献者は特定の活動を完了するとこれらを受け取ることができます（この報酬モデルの代表例として[Fedoraプロジェクト](https://badges.fedoraproject.org/)を参照）。こうした活動には、コミュニティイベントへの参加、コミュニティ選挙での投票、プロジェクト文書の更新、新規メンバーの質問対応などが含まれます。貢献者はこれらのバッジをプロジェクトプロフィールに表示し、プロジェクトへの多様かつ継続的な貢献の証として活用できます。 + +実際、この報酬モデルはコミュニティが多様な貢献を促進したい場合に有効です。ポイントシステムが同じタスクの反復実行を報いるのに対し、バッジシステムは「これまで試みたことのない新たな挑戦を達成するたびに」毎回異なる報酬を与えることで、多様な貢献方法を促進します。これにより、プロジェクトの複数分野への関与が促されるのです。ポイントシステムやリーダーボードと同様に、バッジは参加者がコミュニティ内での評価向上を動機とする場合に有効な報酬モデルと言えます。 + +しかし、恣意的な操作や「ゲーム化」が容易な場合、バッジシステムはコミュニティエンゲージメントの取り組みを複雑化させる可能性があります。Matt Cantu Snellが[この分野の最近の研究](https://opensource.ieee.org/community-advisory-group/community-badging/about/-/issues/26)で指摘するように、バッジシステムは参加者に、バッジ獲得に必要な最低限の貢献のみを行うよう促す可能性があります。したがってバッジシステムは、貢献者に「コミュニティの健全性よりもバッジ取得に注力する」という利己的な行動を促す恐れがあります。Snellはバッジ要件を明確に文書化し、新規コミュニティバッジは導入前に必須の審査（または「インキュベーション」）期間を設けることを推奨しています。 + +### コミュニティブランド品 + +貢献者への報酬として、コミュニティへの帰属を示す様々なアイテムを贈呈する方法があります。例えば、プロジェクトのロゴ入りシャツ、帽子、ステッカー、キーホルダーなどを参加者に提供し、プロジェクトとの繋がりを強化する方法を検討できます。リーダーボード形式の報酬モデル（前節参照）を採用している場合、特定のブランドアイテムの受領をボード上の達成条件と連動させることも可能です（「参加ポイントを100ポイント集めるとコミュニティブランドTシャツを贈呈」など）。この報酬モデルは、プロジェクトへの参加やコミュニティとの関わりから強いアイデンティティを得る貢献者と繋がりたい場合に特に有効です。重要な仲間集団への所属を公に表明できるアイテム、あるいは*その集団内での*自身の地位を示すアイテムを受け取ることで、プロジェクトへの貢献意欲が高まる可能性があります。 +ただしこの報酬モデルには多大なリソースが必要となる場合が多いです。グローバルコミュニティのメンバーへブランドアイテムを梱包・発送する作業には時間がかかりますし、さらにブランド素材の制作と配布には多額の費用が発生する可能性があります。 + +### コミュニティの注目人物と表彰 + +コミュニティの注目人物と表彰は、コミュニティを素晴らしいものにしている人々を紹介するのに役立ちます。オープンソースコミュニティの中には、プロジェクトに大きな影響を与えた貢献者を紹介するブログ記事や動画シリーズを不定期で公開しているところもあります。例えば、主要な貢献者を紹介する月次の「Meet the Contributors」や「Community Spotlight」シリーズを設け、彼らがコミュニティに向けて自己紹介する機会を提供します。他のコミュニティでは「年間最優秀貢献者」や「最も価値あるメンテナ」を表彰する年次アワードシリーズを企画する場合もあります。プロジェクトはその後、受賞者をイベントで紹介したり、オンラインで特集インタビューを掲載したりします。 + +この報酬モデルは認知度向上の機会を伴うため、参加者が個人の評判向上や専門的ネットワークの拡大を動機としている場合に有効です。また、多様な貢献者を惹きつけ維持する上でも特に有用です。過小評価されがちなグループ出身の貢献者をスポットライトに当てることで、それらのグループに属する新規・潜在的な貢献者がプロジェクトに「自分たちの存在を見出し」、参加への自信を深める道筋を提供します。さらに、*メンバー自身*が仲間を推薦・投票・表彰する仕組みは、共同体の価値観を強化し社会的絆を深めます。したがってこの報酬モデルは、コミュニティ参加を「他者との絆形成」「集団帰属感」「目的意識への繋がり」と捉える貢献者との接点創出にも有効です。 + +ただし、特定の貢献者を顕彰する選択は、その貢献者がコミュニティが最も重要視する原則を体現し、行動を実践している印象を与え、より多くの貢献者が彼らを模範とすべきだというメッセージを伝えることに留意すべきです。さらに、この報酬モデルを導入するコミュニティは「お気に入り扱い」や閉鎖的な文化の醸成を非難される可能性があります。これを軽減するため、顕彰対象や受賞者を選定する基本的な手順を正式に定め、公開することを検討するとよいでしょう。この手順では、コミュニティメンバーが互いを推薦し、プロジェクトへの影響やプロジェクトの指針となる価値観を体現していると感じる点について証言を提出する形が考えられます。また、推薦された個人が注目を避けたい場合に推薦を辞退できる機会を設けることも可能です。 + +### コミュニティの役割と称号 + +オープンソースプロジェクトへの貢献者を報いる簡便な方法の一つは、プロジェクト内で追加の権利・責任・特権を付与することです。例えば、プロジェクトメンテナへの任命、運営委員への指名、コードリポジトリでの権限昇格、プロジェクト公式SNSアカウントの管理権限付与などが挙げられます。これにより、プロジェクトへの関与が最も深いと感じる貢献者は、プロジェクトへの投資を深化させ、その成功に対する責任感を高めることができます。 + +この新たなエンパワーメントの感覚は、コミュニティの重要な進化も引き起こす可能性があります。例えば、[Open Organizationコミュニティ](https://theopenorganization.org/)のメンバーが[プロジェクトの5周年](https://opensource.com/open-organization/20/6/scaling-energetic-community)を迎える頃には、「停滞感」を覚えるようになりました。「コア貢献者——多くはプロジェクト発足時から関わってきた者たち——は、自らの努力が本来あるべき影響力を発揮していないと感じ始めました。彼らは成長し、限界を押し広げ、プロジェクトを前進させる新たな方法を模索していました」。プロジェクトは「社会的経済の課題に直面している」と認識し、次のような核心的な問いを投げかけるに至りました。「貢献者たちはコミュニティに何を投資しているのか？その理由は？貴重な投資（時間、エネルギー、情熱、そして重要な知識労働）の結果として、彼らは何を得たい、あるいは感じたいと思っていたのか？ そしてコミュニティは、それらの投資を促進し、認識し、報いるように構成されていたのか？」そこでプロジェクトは新たなメンテナー権限を創設し、長年のメンバーをその地位に据え、主要な貢献者にプロジェクトの将来に対するより大きな影響力を与えました。 + +この報酬モデルは、コミュニティメンバーが専門的経験を広げるためにプロジェクトに参加していると認識できる場合に有用です。プロジェクト内での地位向上により新たな肩書きを得た貢献者は、それらを履歴書やその他の専門文書に記載することを検討できます。また、自身の能力を示す手段として、プロジェクト内でのより注目度の高い作業実績を他者に提示することも可能です。特定のコミュニティメンバーがプロジェクトへの影響力を深めようと努力していることを認識している場合にも、このモデルの採用は有用です。継続的な活動がプロジェクト内での権利と責任の拡大につながる可能性があることを認識させることで、より一貫した貢献を促すインセンティブとなります。 + +この報酬モデルは、付与した権利や特権を取り消すことが困難であるため、広範かつ潜在的に不可逆的な結果を伴うインセンティブを伴うことに留意してください。 + +### スポンサーシップ + +業界イベントや専門会議への参加費（宿泊費を含む）を負担するスポンサーシップも、プロジェクト参加への報酬手段です。プロジェクトメンバーがプロジェクトやコミュニティへの関与を深めるにつれ、こうした場でプロジェクトについて発表する機会を求め、他プロジェクトの貢献者と交流・知識共有・相互学習を図るケースが増加します。 + +したがって、この報酬モデルは、貢献者が専門的なネットワーク拡大を動機としていると認識している場合に特に適しています。これは貢献者の個人的・職業的成長への投資であり、プロジェクトへの参加が自己研鑽の全体計画の一部であることを認め、プロジェクト成長を支援するより公的な役割を担うよう促す手段となります。 +これまで検討した報酬モデルの中で、おそらく最も多くのリソースを必要とします。端的に言えば、金銭的に高額になり得ます。また、プロジェクト管理者やリーダーが複雑な事務作業（購入、スケジュール調整、調整など）を担う必要があるため、労働集約的な報酬モデルでもあります。 + +## 結論 + +本章では、オープンソースプロジェクトへの多様な貢献を認め称えるためのコミュニティ報酬モデルの重要性と戦略を探求しました。複数の報酬モデルを説明し、それぞれの利点と欠点を議論しました。コミュニティマネージャーやアーキテクトは、貢献者がプロジェクトに参加する動機に共鳴する報酬モデルをコミュニティが実装するのを支援することで、魅力的なコミュニティ体験を構築します。コミュニティが提供できる報酬モデルが多ければ多いほど、多様な動機でプロジェクト参加を希望する参加者との関わり方を増やせます。結果として、様々な背景・動機・才能を持つ貢献者からの熱意ある参加を導き出す可能性が高まります。次節では、貢献者のプロジェクトへの関与を深化させる方法について考察します。 + diff --git a/l10n/ja/guiding-participants/why-people-participate-in-open-source-communities.md b/l10n/ja/guiding-participants/why-people-participate-in-open-source-communities.md new file mode 100644 index 00000000..476cb05e --- /dev/null +++ b/l10n/ja/guiding-participants/why-people-participate-in-open-source-communities.md @@ -0,0 +1,62 @@ +--- +description: +author: Gordon Haff +updated: 2020-05-14 +translated-by: Ken Komazawa powered by DeepL Pro +--- + +# オープンソースコミュニティへの参加理由 + +なぜ人々はオープンソースコミュニティに参加するのでしょうか？そこから何を得ているのか？自身のニーズに焦点を当てているのか、それとも主に他者を考えているのか？ + +人々が関与している以上、答えは—ご想像の通り—複雑で多様です。 + +オープンソースコミュニティで見られる行動パターンを観察するだけで、単一の動機が作用しているわけではないと直感的に理解できます。結局のところ、多くの大規模オープンソースプロジェクトでは、本業の一環として貢献している参加者が数多く存在します。これは彼らが給料以外の理由でオープンソースに関心を持っていないという意味ではありません。しかし、夜や週末に自身が情熱を持つプロジェクトに取り組む貢献者とは異なる参加理由を示唆しています。さらに、興味深い技術的課題の解決に焦点を当てる貢献者もいれば、明確に社会的利益をもたらそうとする貢献者も存在します。 + +とはいえ、共通のパターンを見出せないわけではありません。オープンソース貢献に特化した学術研究があるだけでなく、動機付けを扱う心理学文献も数多く存在します。したがって本章では、動機付けというレンズを通して、貢献者がオープンソースに参加する理由を考察します。 + +## 外発的動機付け + +この種の動機付けは「金を出せ！」と単純化できるかもしれません。外発的動機付けはそれほど単純ではありませんが、特定の時代や場所で一般的な形態を問わず、報酬は歴史的に人々に行動を促す定番の方法でした。富を蓄積するためであれ、食料や住居といった基本的な必要を満たすためであれ。価値あるものと引き換えに、本来なら手を付けないような仕事を行うという考え方は、ほとんどの人間社会に深く根付いています。 + +外発的動機付けの存在が一般の人にとっていかに明白に見えても、1940年代に行動主義者のClark Hull（後にKenneth Spenceと共同研究）が衝動抑制理論を提唱するまで、正式な研究分野とはなりませんでした。この理論は飢えや渇きといった一次的欲求の抑制に焦点を当てたものです。空腹なら食べる。喉が渇けば飲む。衝動抑制理論が廃れた理由の一つは、金銭など二次的な手段でしか欲求を抑制させられない要素に焦点を当てなかったことにあります。とはいえ、マズローの欲求段階説など身近な概念には、この理論の痕跡が見られます。 + +オープンソース開発者の動機に戻ると、金銭は確かに大きなインセンティブとなり得ます。20年ほど前でも、多くの主要オープンソースプロジェクトには、企業から報酬を受けながらオープンソース開発に従事する貢献者が相当数存在しました。 + +キャリアアップは報酬と密接に関連しています。しかしこの点において、オープンソースソフトウェアはプロプライエタリソフトウェア開発と異なるのでしょうか？異なる可能性はあります。複数の研究者が実証的証拠を提示し、公開されたコードを開発することにはキャリア上の利点があるという主張を支持する「少なくとも認識上の利点」が存在することを示唆しています。実際、「GitHubを履歴書代わりに」という概念は（時に不適切に適用されることもあるが）一般的なテーマとなっています。 + +## 内発的動機付け + +1970年代に始まった研究は、活動そのもの以外に明らかな報酬を必要としない内発的動機付けに注目し始めました。Edward DeciとRichard Ryanによって発展した自己決定理論は、内発的動機付けと外発的動機付けの比較研究、および行動において内発的動機付けが果たす支配的な役割への理解の深化から後に発展しました。 + +オープンソースソフトウェアに関して言えば、おそらく最初に思い浮かぶのはイデオロギー的あるいは利他的な動機付けでしょう。少なくともフリーソフトウェアの場合、ユーザーがソースコードにアクセスできる実用的な利点があったとしても、最初から常にイデオロギー的・政治的要素が存在していたからです。 + +調査からは、貢献者がこうした要因に多少動機づけられる可能性を示す証拠もあります。ただし研究結果はまちまちです。一部の貢献者は調査で、イデオロギー的・利他的な理由が参加の一因だと回答しています。しかしこの効果は、趣味としてオープンソースに取り組む貢献者で最も顕著です。また利他主義がプロの貢献者に影響を与えることは確かですが、これは主に、報酬やキャリアの他の側面にも*同時に*満足している貢献者に当てはまるようです。 + +利他主義の変種として「血縁的親和性」があります。これは贈与経済の概念に関連しますが、計算された*見返り*を期待しない家族（血縁）集団に特有です。（つまり、家族は互いに助け合うが、少なくとも体系的な形で、最近誰が責任を果たしていないかといった帳簿をつけることは通常ありません。） 利他主義との違いは、オープンソースコミュニティなど、自身が属するグループに限定される点にあります。ここでも研究結果はまちまちです。研究では概して、認識された血縁的親和性と、週当たりの労働時間数など様々な努力の測定値との間に正の相関関係が認められていますが、その相関は往々にしてかなり弱いという結果です。 + +最後に、純粋な「楽しさ」があります。オープンソース開発者、デザイナー、コンテンツクリエイターと交流する者にとって、これは驚くべきことではありません。彼らの大半はオープンソースプロジェクトへの参加を*好んで*行っています。2007年の大規模な研究（Luthiger and Jungwirth）では、プロジェクトへの努力（時間）の28％が「楽しさ」によるものと結論づけられました。ただし、趣味として取り組んでいる場合や、職業的に満足している場合など、楽しさや利他主義による動機付けを感じやすいのは確かです。 + +## 内面化された外発的動機付け + +現代の心理学の文献では、内面化された外発的動機付けの概念も取り上げられています。これはキャリア機会の拡大に向けたスキル習得といった外発的動機付けですが、他者による「人参（報酬）」の提示という直接的な結果ではなく、内面から湧き上がる動機として内面化されたものです。例えば「新技術の習得が長期的に利益をもたらす」という認識から（プログラミング）言語を学ぶことと、「資格取得の直接的な見返りとして給与が上がる」ことの違いがそれにあたります。オープンソース開発において、この種の動機付けがどのように作用するかの好例が、コミュニティ内部関係者や潜在的な雇用主からの評価獲得です。様々な調査が、仲間からの評価が参加の推進力となることを裏付けています。 + +学習もまた、オープンソースプロジェクト参加の大きな利点として頻繁に挙げられます。学習はそれ自体が満足感をもたらすだけでなく、キャリアアップの重要な要素となり得ます。ただし、ここで内発的動機付けと外発的動機付けを明確に区別するのは難しいです。純粋な学習のためか？それとも業務で必要な特定スキルの習得のためか？ + +このカテゴリーの最終的な動機は、研究者が「自己使用価値」と呼ぶもので、より分かりやすく言えば「自分の痒いところを掻く」ようなものです。自分が欲しいものを開発し、その過程で他者のためにも何かを生み出す。その成果は最終的に自分自身への外部報酬となりますが、誰も強制はしていません。 + +## 結論 + +前述の通り、多くの事柄における動機付けは多面的であり、オープンソースソフトウェアへの貢献も例外ではありません。ただし、以下に役立つかもしれない三つの要点を挙げます。 + +**非外発的動機付けに過度の負担を期待しないこと。** + +確かに理想主義や利他主義から貢献する人も多くいます。しかしそれらは通常、唯一の動機ではなく、重要な要素ですらない場合がほとんどです。特に商業的支援のあるプロジェクトでは、報酬やその他の専門的な労働上の利点が非常に重要になります。 + +**学習や仲間からの評価といった非外発的動機を積極的に活用する。** + +直接的な利益の代わりにはなりませんが、仲間からの評価を得る機会や新しい技術分野で働く機会は動機付けとなります。組織は、これらの動機付け要因を最大限に活用するために、仲間からの評価プログラムを検討し、学習を明確に奨励すべきです。 + +**動機付け要因は、過剰に活用すると逆効果になる可能性があります。** + +動機付けが多面的であるからこそ、単一の要因に過度に依存すべきではありません。イデオロギーや利他主義の限界については既に議論しました。しかし、例えば「自分の痒いところを掻く」といった動機も考慮すべきです。もしそれが*唯一の*貢献理由なら、個人は自身の特定のニーズに応じてプロジェクトに出入りする傾向があります。これは全く問題ない結果かもしれませんが、長期的なメンテナを育成する道筋ではありません。 diff --git a/l10n/ja/measuring-success/README.md b/l10n/ja/measuring-success/README.md new file mode 100644 index 00000000..4021c095 --- /dev/null +++ b/l10n/ja/measuring-success/README.md @@ -0,0 +1,32 @@ +--- +description: +author: Brian Proffitt +updated: 2020-12-10 +translated-by: Ken Komazawa powered by DeepL Pro +--- + +# 成功の測定 + +オープンソース以前の時代、ソフトウェア開発の成功は厳密に金銭的な観点で定義されることが多かったです。企業はソフトウェアを何箱（そう、箱単位で）販売したか？ その収益からサポート、制作、流通（これも箱単位）のコストを差し引けば、ほら！ 利益こそが成功の尺度でした。 + +オープンソースの世界では、そう単純にはいきません。まず、商業的に成功したオープンソースプロジェクトは存在しますが、それらの成功は依然として財務面だけに厳密に結びついているわけではありません。また、成功はダウンロード数という一般的な指標で測られるわけでもありません。例えば、ソフトウェアプロジェクトが数百万回のダウンロードを達成していれば、非常に順調だと推測するのは非常に容易です。しかしユーザーがソフトウェアを安定して利用しているからといって、プロジェクトコミュニティ内に問題がないとは限りません。プロジェクトを停止に追い込む要因は数多く存在します。逆に、大々的な報道や爆発的人気を伴わない非常に成功したプロジェクトも数多く存在します。 + +では、オープンソースソフトウェアプロジェクトにおいて、金銭や名声が成功要因でないなら、何が成功要因なのでしょうか？ + +オープンソースプロジェクトの成功は、商業的・消費的な成功だけで測られるものではありません。分散型バージョン管理やコラボレーションツールの普及により、フリーでオープンなプロジェクトの開発プロセスははるかに透明性が高まりました。gitを基盤とするこれらのツールは、貢献者がプロジェクトを構築する上で大きな利点をもたらしただけでなく、プロジェクトの進捗状況をより堅牢かつ定量的に観察できるという別の利点も生み出しました。 + +かつては、特定のプロジェクトのプロセスが成功しているかどうかをリアルタイムで把握することは困難でした。プロジェクトの成果は確認できても、そこに至るまでの過程のステップは見えませんでした。少なくとも、多大な労力をかけなければ見えなかったのです。そのため、プロジェクトの健全性や成功を判断するには、多くの文化に根付いた社会学的・ビジネス志向の原則に基づく主観的な方法が用いられることが多かったのです。しかし現在では、オープン開発によって公開されたデータに容易にアクセスし、プロジェクトの健全性に関する定量的な情報を導き出すことが可能です。本セクションでは、こうした概念を探求します。 + +本セクションには以下の章が含まれます。 + +* 健全で参加型のコミュニティ形成について議論する。 +* プロジェクトへのメトリクス適用方法の検証 +* プロジェクトにとって最も有用なメトリクスの選定 +* プロジェクト発表への参加促進手法の提示 + +本セクションは以下のような場合に有用です。 + +* コミュニティの健全性を確認したい場合 +* 成功と失敗を示すデータを求めている場合 +* プロジェクトへの貢献者を増やしたい場合 +* ここまで読んだのなら、ここで止めてしまうのはもったいないでしょう？ diff --git a/l10n/ja/measuring-success/announcing-software-releases.md b/l10n/ja/measuring-success/announcing-software-releases.md new file mode 100644 index 00000000..2ef2ef04 --- /dev/null +++ b/l10n/ja/measuring-success/announcing-software-releases.md @@ -0,0 +1,129 @@ +--- +description: +author: Brian Proffitt +updated: 2019-12-14 +translated-by: Ken Komazawa powered by DeepL Pro +--- + +# ソフトウェアリリースの告知 + +オープンソースプロジェクトの機能の一つは、可能な限り多くのユーザーに届けることを目的としたソフトウェアのリリースです。プロジェクトの成功を支援するためには、リリース情報をタイムリーに、関連する最も広い層に、適切な内容で配布することが必要です。 +リリース発表の調整に関する基本的なガイドラインに従うことで、優れた成果が埋もれるのを防げます。これらはあくまで指針であり、コミュニティの実践は異なる場合があることを覚えておいてください。 + +## 一般的なガイドライン + +* リリース日を金曜日や主要な祝日に設定しないでください。最大限の注目を得る理想的なリリース日は火曜日です。 +* 可能な限り、主要なリリースを関連するカンファレンスやイベントと調整してください。 +* リリース告知やブログは、ソフトウェアの*利用*と*貢献*の両方を促すように調整してください。 +* プロジェクトがユーザーにもたらす利点について説明し、技術的な詳細に焦点を当てるよりも利点を説明してください。 + +## トラック: 主要ポイントリリース X.0 のリリース候補版と最終リリース + +主要ポイントリリース (X.0) では、以下のプロセスに従うか準拠してください。 + +1. リリース日から少なくとも3週間前: + a. リリース告知、プレスリリース、ブログ記事向けに、注目機能を記載した共同編集文書 (Etherpad、Google Doc) を作成する。 +2. リリース日の2週間前: + a. 主要な変更点をまとめた変更履歴（changelog）を生成し、メインの変更履歴ファイルに記録・組み込む必要がある内容を整理する。 + b. 更新された変更履歴から関連する内容を、リリース告知文、プレスリリース、ブログ投稿に統合する。 + c. プレスリリースを作成し、組織のメディア対応チームに提出して審査を受ける。 +3. リリース日の1週間前: + a. リリース日前後および当日に配信するソーシャルメディアコンテンツをスケジュールする。 +4. リリース3日前: + a. リリースマネージャーとエンジニアリングリーダーがリリース告知文とブログ投稿を承認したことを確認する。 + b. メディアリレーションズ担当者がプレスリリースを承認したことを確認する。 +5. リリース2日前: + a. 最終QA/スモークテストを全て完了する。 + b. ビルドを適切なサーバーに配置する。 + c. 全ドキュメントをステージングし、表示上の問題がないか確認する。 +6. リリース前日: + a. 関連メディアにプレスリリースを送付する。 +7. リリース当日: + a. 全てのコードとドキュメントを公開する。 + b. 予定されたソーシャルメディア投稿とブログ記事の公開を開始する。 + c. ニュースワイヤーにプレスリリースを掲載する（メディアリレーションズチームと連携）。 + +## トラック: ポイントリリース X.Y のリリース候補版および最終リリース + +Y ポイントリリース (X.Y) では、以下のプロセスに従うか準拠してください。 + +1. リリース日から少なくとも2週間前: + a. リリース発表およびブログ投稿用のハイライト機能を記載した共同編集文書 (Etherpad、Google Doc) を作成する。 +2. リリース日の1週間前: + a. リリース日前後および当日に配信するソーシャルメディアコンテンツをスケジュールする。 + b. 主要な変更点をまとめた変更履歴（changelog）を生成し、メインの変更履歴ファイルに記録・組み込む必要がある。 + c. 更新された変更履歴から関連する内容をリリース告知文およびブログ投稿に統合する。 +3. リリース2日前: + a. リリースマネージャーとエンジニアリングリーダーがリリース告知文とブログ投稿を承認済みであることを確認する。 + b. 最終QA/スモークテストを全て完了する。 + c. ビルドを適切なサーバーに配置する。 + d. 全ドキュメントをステージングし、表示上の問題がないか確認する。 +4. リリース当日: + a. 全コードとドキュメントを公開する。 + b. 予定されているソーシャルメディアおよびブログ素材の公開を開始する。 + c. プレスリリースを関連メディアに送付する。 + +## トラック: マイナーポイントリリース X.Y.Z の最終リリース + +マイナーZポイントリリース（X.Y.Z）については、以下のプロセスに従うか準拠してください。 + +1. リリース日から少なくとも1週間前: + a. リリース日前後およびリリース期間中に配信するソーシャルメディアコンテンツをスケジュールする。 + b. 主な変更点をまとめた変更履歴（changelog）を作成し、メインの変更履歴ファイルに含める。 + c. 更新された変更履歴から関連する内容をリリース告知文とブログ記事に統合する。 +2. リリース日の2日前： + a. リリースマネージャーとエンジニアリングリーダーがリリース告知文とブログ記事に承認済みであることを確認する。 + b. 最終QA/スモークテストを全て完了する。 + c. ビルドを適切なサーバーに配置する。 + d. 全ドキュメントをステージングし、表示上の問題がないか確認する。 +3. リリース当日: + a. リリース成果物とドキュメントを、まだ公開されていない場合は全世界に公開する（リリースは実際の発表前にミラーサイトに同期される場合がある）。 + b. スケジュールされたソーシャルメディアおよびブログ素材の公開を開始する。 + +## 主要リリース及び重要なポイントリリース後 + +1. 次回リリースサイクル改善のため、改善点がないか振り返りを行う。 + +## プレスリリース/リリース発表文の作成 + +リリース発表文の作成・配信は比較的単純に見えますが、効果的な手法が存在します。特に、メディアに取り上げられやすい形式で発表文を作成すべきです。 + +以下にリリース発表のテンプレートとガイドラインを示します。あくまで参考例であり、そのまま流用するとプロジェクトに不適切となる可能性がある点に留意してください。 + +公式発表では情報を率直かつ事実に基づいて伝えることです。誇張表現（「史上最高のプロジェクトです!!!」）や憶測（「これを実現できる唯一のプロジェクト」）は避けましょう。メディアはこうした誇張を即座に見抜き、リリース情報を一切伝えない可能性があります。 + +リリース発表はプロジェクトを誇大宣伝する機会ではありません（その誘惑は強いかもしれませんが）。この機会を活用して、尽力したコミュニティへの感謝を表明すべきです。これにより貢献者に敬意を表し、プロジェクトのフリーでオープンソースな性質を強調できます。 + +明確かつ簡潔に。主張は事実で裏付けましょう。これにより発表の拡散が促進されます。 + +## プレスリリース／リリース発表のサンプル + +> `Project X`（`[プロジェクトの主な目的：目標、機能、ガバナンス...]`）は本日、コミュニティ主導の`[プロジェクトの説明]`である`Project X x.y`の一般提供開始を発表しました。この最新のコミュニティリリースには、`[最新機能の一覧]`を含む複数の新機能が搭載されています。 +> +> グローバルコミュニティによって開発された`Project X`は、`[プロジェクトの性質、機能、その他関連情報を詳細に記述する段落をここに含める]`です。 +> +> `Project X x.y`の主な機能強化は以下の通りです： +> +> `[主要機能1の詳細説明]` +> +> `[主要機能2の詳細説明]` +> +> `[主要機能3の詳細説明]` +> +> `Project X x.y`の全機能一覧は、`Project X`コミュニティリリース発表ページ`[URL]`でご確認いただけます。`Project X x.y`は`[追加機能2～3の詳細説明]`を実現します。 +> +> `[可能であれば、著名なコミュニティメンバーや技術リーダーによる新リリースに関するコメントをここに追加してください。]` +> +> **追加リソース** +> +> * `Project X x.y` リリースのハイライトについて詳しく読む `[URL]` +> +> * Twitterで`Project X`の最新情報を入手 `[URL]` +> +> * `Project X`コミュニティイベントについて詳しく読む `[URL]` +> +> **`Project X`について** +> +> `Project X`は `[プロジェクトの内容と機能に関する非常に詳細な説明]` です。 + + diff --git a/l10n/ja/measuring-success/defining-healthy-communities.md b/l10n/ja/measuring-success/defining-healthy-communities.md new file mode 100644 index 00000000..7cf961f7 --- /dev/null +++ b/l10n/ja/measuring-success/defining-healthy-communities.md @@ -0,0 +1,313 @@ +--- +author: Karsten Wade +updated: 2020-12-12T00:00:00.000Z +translated-by: Ken Komazawa powered by DeepL Pro +--- + +# 健全なコミュニティの定義 + +誰も不健全なコミュニティで生活や仕事を望まないことは理解していますが、健全性を定義し維持することは複雑です。まず、健全な状況や行動様式をどう捉えるかを明確にする必要があります。次に、それらの状況や行動様式を時間をかけて検証（テスト）し、健全性を維持するために動的に予測・対応できるようにしなければなりません。 + +健全性の定義は、コミュニティの進化に伴い時間とともに変化する可能性があります。初期段階では、特にフィードバックの収集・管理方法を中心に、ユーザーにとって健全なコミュニティ構築に多大な労力を注ぐことになるでしょう。貢献者プロジェクトとして進化・成長するにつれ、健全性の定義と維持方法は指数関数的に複雑化します。 + +しかし、貢献者ベースのオープンソースソフトウェアコミュニティを目標と決めた時点で、最初から全体像を認識し注力できます。貢献者レベルで健全性を理解し実践するプロジェクトは、その健全性を他の参加層やエンドユーザーへ自然に波及させます。つまり、健全な貢献者は、自らの健全性を保つ活動の結果として、あるいは直接的な焦点として、他者にとって安全で健全な環境づくりに関与するのです。 + +例として、貢献者同士の間で「親切さ」が健全な行動だと仮定しましょう。直接の仲間への親切な行為はその一形態です。しかしオープンソースでは、プロジェクトに関わる全ての人へ親切さを拡張することで、彼らに良い体験を与えるだけでなく、その親切がプロジェクト全体の交流に波及することが確認できます。あなたの親切心が10人のユーザーを仲間の貢献者に対してより親切にするよう導くなら、その親切はあなたが直接その仲間に与えられる範囲を超えて増幅されたことになります。 + +オープンソースコミュニティの健全性を評価する際、主に二つの観点から検討します。 + +ユーザーを惹きつけることが成功の鍵であるため、世界がプロジェクトをどう見ているかを検証します。活動レベルからメンテナとの交流まで、人々がプロジェクトを評価する際に注目する指標です。 + +参加者と貢献者を惹きつけ維持することが存続の鍵であるため、プロジェクトが自らの健全性をどう捉えているかも検証します。 + +## 外部から見たプロジェクト像 + +本章後半では、この側面の健全性を測定する監査の実施方法について説明します。監査では、ここで挙げた主要な質問項目が、より詳細な質問のカテゴリーとして登場します。監査セクションの質問は、各カテゴリーの詳細を掘り下げた内容となります。 + +### 構造 + +これは、人々がプロジェクトを訪れた際に目にする、認識される構造です。建物に例えるなら、階数、正面玄関からの出入りができるか、車椅子やベビーカーのアクセス性、住所が明記された看板の有無、行き先がわかるロビー案内板の有無、ロビーの照明や安全性の印象などが該当します。 + +* プロジェクトはユニークで覚えやすい名前のウェブサイトを持っていますか？ +* ウェブサイトにはオープンソースプロジェクトに必要な要素が揃っていますか？ +* ウェブサイトはプロジェクトの目的、ソフトウェアの入手方法・使用方法などを明確に伝えていますか？ +* プロジェクトには行動規範（Code of Conduct）がありますか？ +* プロジェクトは多様性と包摂性（ダイバーシティ＆インクルージョン）への取り組みを行っていますか？ +* プロジェクトはその取り組みを前面に打ち出していますか？ + +### リリース管理 + +エンドユーザー向けソフトウェアのリリースに関する規律とプロセスは？ + +* プロジェクトはソフトウェアをリリースしているか？ +* 過去にリリース実績があるか？ +* その他の公開されている成果物には何があるか？ +* どのような開発サイクル／モデルを目指しているか？ + +### 活動状況 + +プロジェクトのコードおよびコンテンツ開発はどの程度活発か？ これにはプロジェクトのコードリポジトリとコンテンツリポジトリの確認が必要です。 + +* リリース活動のデータは？ +* コミット活動の状況は？ +* バグ報告活動の状況は？ +* イベントやミーティング活動の状況は？ +* メーリングリスト活動の状況は？ +* プロジェクトが使用するコミュニケーションチャネルと優先順位は？ + +### ドキュメント + +エンドユーザー、ソフトウェアを使用または統合する開発者、プロジェクトへの貢献者など、幅広い人々に役立つコンテンツです。 + +* ドキュメントの全体的な品質はどうか？ +* ドキュメントはどのように作成されているか？ +* ドキュメントの作成者は誰か？ + +### コード品質 + +これは進化を続ける健全性領域です。このガイドブックがバージョン1.0で初めてコード品質を扱った当時から現在まで、言語、開発環境、共通課題の解決手法に関する思想が大幅に拡大しました。このカテゴリーは本章で最も主観的な評価となります。 + +* コードの全体的な品質はどうか？ + +### アウトリーチ + +ユーザーを惹きつけ、参加意欲を高め、協働のための人的つながりを構築する——プロジェクトが世界へ発信する方法は、プロジェクト健全性の重要な側面です。 + +* ダウンロードデータはどうか？ +* ブログデータはどうか？ +* ソーシャルメディアデータはどうか？ +* イベントデータはどうか？ +* コミュニケーションデータはどうか？ + +### ライセンス + +これは二者択一の状況です。プロジェクトは[オープンソースイニシアチブ承認ライセンス](https://opensource.org/licenses)を採用しているか、していないか？ + +* プロジェクトはどのようなライセンスを採用しているか？ + +## プロジェクトが自らをどう認識し理解しているか + +これは非常に主観的な混合要素であり、このガイドブックの著者たち自身もプロジェクトとして、この内容をまだ模索中です。本章では、一般的に適用可能と思われる考慮事項のリストを提供します。 + +* 多様性はあらゆる角度からどう捉えられているか？ +* 組織的多様性は、他のより重要なグループと並んでどう位置づけられているか？ +* これはオープンソースソフトウェア特有の非専門的な認識である。単一組織／企業に支配されたプロジェクトは、組織的多様性を欠くことで潜在能力を制限している。つまり、多様性がもたらす価値は、多様な組織に属する人々を擁することにも適用される。 +* 心理的安全性はどの程度か？全体として、またチーム内では？ +* プロジェクト内で責任・リーダーシップ・影響力を高める進め方は明確か？（これは日常的に機能するガバナンス／実力主義の全てを指す） +* 何かを**実行する**のはどれほど難しいか？ +* 自動化のレベルは？このレベルは技術的負債、雇用安定、その他の要因によるものか？ +* クッキーなめ行為（既知の貢献者が発言や存在感によって、問題や状況の責任を負っていると他者に想定される現象）の発生頻度は？ +* 派閥の現状は？派閥はオープンソースコミュニティに自然に生じる社会的メカニズムであり、喜びや楽しさ、生産性の源となる一方、悲しみや不安、疎外感の源にもなり得る。 +* ルールは常に守られているわけではない。プロジェクトが自身のガイドラインに従っている割合と実感は？遵守されにくいルールと遵守されやすいルールの種類は？ +* プロジェクト全体で健全なワークライフバランスが保たれていると感じられるか？ +* メンターシップの文化はあるか？ +* 自己文書化のプロセス、それに伴う苦労、結果はどのようであるか？ +* 子供たちに靴はあるか？屋根は雨漏りしていないか？ +* 壊れた階段とは何か？_壊れた階段_とは、コミュニティ内で機能不全に陥っているものの比喩であり、誰もがそれを話題にせず、回避する方法だけを学んでしまう状態を指す。 +* 個人の間の相互理解（sympatico）、つまり人間関係の質はどうか？ + +## 健全なコミュニティの構築 + +オープンソースコミュニティを構築する実際のプロセスと経験は、状況ごとに特有のものです。つまり、その構成要素自体は唯一無二ではありませんが、それらの組み合わせは唯一無二なのです。これは、様々な_truisms_（ベストプラクティス）を特定の状況に適用できることを意味します。たとえその状況が段階的なプロセスに似ていなくともです。 + +以下は健全なコミュニティの構築と成長を可能にする要素です。 + +### コミュニティは開始時に手入れ・養分・除草を必要とする + +野心的な庭師が庭を育てる場面を想像してください。初年度に苗を過剰に植え、間引きを拒みます。結果として、過密で不健康な植物が育つことになります。 + +オンラインコミュニティ（オープンソースコミュニティを含む）では、即座で爆発的な成長への強い欲求が存在します。これは通常、適切な環境でプロジェクトを積極的に宣伝することで達成され、その結果、多くの人が軽い興味からコミュニティに参加します。初期採用者をコミッターとして受け入れる強い衝動もよく見られ、それは健全で強力なチームという印象を作り出すためです。 + +プロジェクトの実際の方向性に影響を与える貢献メンバーは、実際の貢献量、貢献の価値、そして全体的な合意に基づいて選ぶべきです。例えば、多くの重大なバグ修正に貢献した人物には、プロジェクトへの書き込み権限（およびそれに伴う発言権）を与えるべきかもしれません。しかし、その人物がコミュニティに有害な雰囲気を作り出しているなら、メンテナへの昇格は良い考えではありません。 + +また、コアコミュニティメンバーに注目し、コーディング能力に関わらず貢献する者を評価することも重要です。例えば、新規ユーザー支援に長けているがバグ修正を試みたことがない人物を考えてみましょう。そうした貢献を認めることは、そのユーザーと他の全員にとって好印象を与えます。ポジティブな動機付けは、報酬を得た行動を他者に促し、結果としてコミュニティ全体の強化につながります。 + +成長は常にコミュニティ全体で奨励すべきです。ただし、その成長が「メンバーとしての資格を勝ち取った候補者」によって構成されるよう配慮してください。これは全員が常に完璧に仲良くする必要があるという意味ではありません。性格の不一致は確かに起こり得ます（場合によっては必然です）。しかし、コミュニティ全体として特定のメンバーの意見がこのような主要な決定を左右することを許すべきではありません。少数派の強い要求に応えるのではなく、合意形成を求めましょう。 + +もちろん、メンバーの行動が深刻な対応を必要とする場合もあります。理性を働かせましょう。行動を起こすことで誰かが不意を突かれるかどうかを考えましょう。 + +### 失敗を受け入れる + +見事に失敗しても、メモを取ることを忘れないでください。ここには群衆の知恵が働いています。これは物理学の基本でもあります——突進して顔から転んでも、少なくとも前進はしたのです。暗闇で手探りするよう、触れるもの、ぶつかるもの、つま先を打つたびに環境への理解が深まります。プロセスや技術を、繰り返し失敗の瀬戸際まで追い込めば、大抵の人間が近づきたがらない領域で極めて快適に過ごせるようになります。同時にコミュニティにとっての「快適」の基準を刷新し、さらなる拡大の余地を生み出すのです。 + +### 透明性の文化 + +オープンソースコミュニティにおいて最も重要な要素の一つは、透明性のレベルと質です。人間には確かにプライベートな空間が必要であり、それは公共の場での行動を支えます。しかし最終的には、全ての議論と決定はコミュニティ全体の前で行われる必要があります。これにより信頼が築かれ、フィードバックを解決策として取り入れることで異論に対処し、コミュニティが合唱のように一体となって行動する基盤が形成されます。この要素の重要な部分には以下が含まれます。 + +#### あらゆる議論を公開で行うよう、特に特に特に注意を払う + +たとえ公開/アーカイブされた場所で会話を中断し再開することを意味しても、常にこの点を心に留めておいてください。公開記録にないものは存在しないのと同じです。つまり、非公開の議論やHallwayでの会話が発生した場合、参加者が可能な限り会話内容を記録する責任があります——途中と終了時のメモが記録として十分です。この議論の結果（個人情報の機密事項を除く）は、コミュニティメーリングリストなどの主要な公開アーカイブ領域に送付されなければなりません。このような議論の場は意思決定の場ではないことを忘れないでください。提案を決定することは可能ですが、それはより大きな集団に対して行われ、全員が参加できる形で公開的に決定されなければなりません。信頼はするが検証しましょう。参加型透明性への取り組みは、相互に共有される信頼の貯金箱への投資です。「ただ私たちを信じて」という密室での決定は、その貯金箱から引き出す行為です。貯金は簡単に底をつきます。 + +#### 常に徹底的に可視化された会議 + +Hallwayでの会話からメール/IRC、電話に至るまで、あらゆる非公開のやり取りはプロジェクトにとってリスクです。最低限、直接対話の結果を報告する意識は必須です。しかし、それだけでは不十分です。会議の要約は論理的な議論の過程を示さず、事実上コミュニティを意思決定プロセスから排除します。フォーラム、メーリングリスト、公開チャットネットワーク、リポジトリコメントやログが、成功したオープンソースプロジェクトにおける全てのコミュニケーションの基盤となっているのには理由があります。 + +#### メーリングリストへの事前告知が不要な決定事項など存在しない + +技術的決定やその他の判断に対するコミュニティの信頼は育むことができますが、回避可能な問題状況は存在します。企業スポンサーやスタッフは常に疑いの目を向けられやすいため、意思決定プロセスを共有する際に特に注意を払う必要があります。貢献者にとって何が重要か、その理由を推測することはできません。彼らが決定を気にしないと思い込むのは誤りです。方法は、特定の種類の決定が別の方法/場所で可能だと人々が不満を言い始めるまで、全ての決定をオープンなフォーラムに持ち込むことです。これは「煩わしい透明性による証明で信頼を築く」と呼ばれます。 + +#### 失望は許されるが、驚きは決して許されない + +全ての決定を誰もが好むわけではなく、失望は避けられない現実です。しかし、特にネガティブと受け取られる事柄で驚かせるべきではありません。それは士気を殺し、最終的に人を遠ざけます。失望を懸念して情報の伝達を控える場合もありますが、誤った対応では失望と驚きという最悪の組み合わせを生みます。非公開のコミュニケーションチャネルで情報を伝える必要がある場合もあります。決定事項を知らない、あるいは知り得ない可能性がある場面では、頻繁にそうすべきです。人々が頻繁に驚いていることに気づいたら、コミュニケーション方法を真剣に見直しましょう。何らかの理由で、情報が十分に広まっていないのです。誰も読まない他のテキストの中に決定事項を埋もれさせてはいけません。ソフトウェアのパッチと同様に、メーリングリストやブログプラットフォームといったコミュニティ共有スペースに、変更点を個別のチャンクとして提供すれば、人々は変化をより理解しやすくなります。決定事項や議論ポイントを個別のスレッドに分割し、人々が「森」だけでなく「木々」も把握できるようにする必要があるかもしれません。議論の中に決定事項や詳細が埋もれて見落とされる可能性がある場合は、後で驚かれないよう、それを強調する方法を考えましょう。 + +#### 設計決定は特に公開で行うよう細心の注意を払う + +たとえ全てのコンテンツが公開リソースで作成されていても、対面会議・Hallwayでの雑談・昼食時・通勤中などで設計決定を行うなら、コミュニティを真に重要な作業から排除していることになります。彼らは気づき、気にかけます。人々が互いに話すのは問題ありません。ただし、それらを「決定前の議論」と位置付け、以下のルールに従ってください。 + +* 共通フォーラムで議論されない限り、決定は存在しないものとみなす。 +* 結論を導いた議論とそれを裏付ける証拠が公開されない限り、結論は正当化されない。 +* コミュニティフォーラム上で行われない限り、議論は存在しないものとみなす。非公開の議論は少なくとも要約をメーリングリストに送信し、結論についてはさらなる議論を開放する。 + +#### プロセスに非公開のブロック要因を一切含まない + +リリースや開発プロセスをブロックする可能性のある要素を非公開にしてはなりません。例えば、非公開のテスト環境で問題が発生したのに、コミュニティにその再現方法を説明できない状況は避けなければなりません。プロセス全体を見直し、非公開部分を特定し、公開する方法を検討してください。非公開のテスト環境や開発インフラがある場合は、それらを公開する方法を探る必要があります。場合によっては（少なくとも短期的には）、報告内容を公開することが最善策となります。プロセスを継続させるためだけに、他者がパブリッククラウドで類似環境を構築する手助けをすることもあるでしょう。 + +#### コードだけでなくコンテンツにもバージョン管理を適用する + +そうすれば全員が変更を追跡できます。作業をロールバックできる環境は、大胆で革新的な取り組みを促進します。プロジェクト作業における価値の一つは、コードベースや文書への変更そのものが説明となる点です。変更内容はコミット自体で自明です。だからこそ、全ての変更には変更の_理由_を説明するコメントや要約が必須となります。ドキュメントのバージョン管理は、その「理由」の文脈を提供するメタドキュメントなのです。同様に重要なのは、全てのプロジェクトメンバーがこれらの変更を監視することです。フォーラム、バグ報告、ドキュメントのディスカッションページで変更に対応することで、議論は元のノードに関連付けられたまま維持されます。 + +#### 拡張可能なオープンツールを選択する + +小規模チームが最も熟知しているという理由だけでツールを選択してはいけません。急いでいるから、すぐに何かが必要だからという理由で選択することには注意が必要です。ツールに関しては、信頼できるコミュニティリーダーと相談して、何を使用すべきか話し合いましょう。ガバナンスを可能な限り明確にし、たとえ他のコミュニティメンバーと足並みが揃わない選択をした場合でも、少なくともその理由を理解し、リスクを軽減する準備が整っているはずです。コミュニティが容易にスケールできないクローズドなツールを選択することは危険です。 + +#### オープンツールへの書き込みコミット権限について、全員が平等かつ明確なアクセス方法を確保する + +コードやコンテンツのバージョン管理下では、より多くの人々にアクセスを開放できます。例えば、長大なプロセスを経ることを要求したり、X件のパッチで「実力を証明」させるべきではありません。たとえ実際に使用しなくても、変化をもたらすために必要なアクセス権を人々に与えましょう。ウィキペディアはここでの好例です。彼らはコンテンツ変更の執筆要件をルールで制限する代わりに、コミュニティ規模の力を活用して悪質な内容変更を監視しています。悪意を持って行動する人よりも、プロジェクトに貢献したいと考える人の数の方が圧倒的に多いのです。誰かが悪事を働く可能性があるからといって、善意の貢献者を罰してはいけません。 + +#### ガバナンスは可能な限り明確に + +貢献者コミュニティが求めるもの、必要とするものは何であれ、彼らは複雑なガバナンス構造を望んでいません。フィードバックに耳を傾け、文書を改訂して言語と理解を進化させてください。そこからガバナンスそのものの進化が生まれ、そこに至る過程の透明性も伴うでしょう。 + +#### 毒のある人間にコミュニティを停滞させない + +[寛容のパラドックス](https://en.wikipedia.org/wiki/Paradox_of_tolerance)を忘れないでください。無制限に寛容であれば、その寛容さは最終的に不寛容な者たちによって奪われ、破壊されるのです。 + +#### 合意形成を追求し、投票は最終手段とする + +オープンコミュニティにおける意思決定の大半は投票で決まりません。健全な民主主義と同様、意思決定は周囲の意思を反映して責任を負う専門家や知識人によって行われます。投票は責任者の選出や、ごく稀な深刻な争点に限定すべきです。争いがなければいいのにと思いませんか？ 戻って合意形成できればと願いませんか？ + +### 早期リリースと頻繁なリリースを忘れるな + +オープンな共同作業の成功には、作業のどの部分も「完璧になるまで」保留しないことが極めて重要です。多くの人は、コードやコンテンツ、アイデアを、他者がレビューできるほど十分に完成させ、磨き上げるまで自分だけで抱え込む傾向があります。オープンソース開発手法において、この完璧を追い求める姿勢は「十分良い」状態の敵です。イノベーションとは、既存のアイデアを基に、斬新な方法、あるいは繰り返しの方法によって構築していくプロセスなのです。アイデアが固定化される前に改善されるよう、他者に早期かつ頻繁に提示する必要があります。完成するまで何も保留しないことを原則としましょう。禅の修行のように——必要なら毎日、毎時間でも——早期かつ頻繁にリリースするのです。 + +#### 早期リリースと頻繁なリリースはコードだけに限らない + +あらゆるアイデアは、可能な限り早く日の目を見る価値があります。よくある過ちは、文書やプロセス、マーケティング計画などを「完璧になるまで」公開を待つことです。コード開発ではこの過ちを完全に理解している人々が、プロジェクトの他の部分ではそれを忘れてしまいます。このルールを適用しましょう。 + +* 情報が機密なら非公開に保つ +* それ以外は、以下の手法で可能な限り早く公開する： + * メーリングリスト/フォーラムでアイデアを投げかける + * ウィキページを作成する + * 既存のウィキページに追加する + * トラッキングシステムにチケットを登録する + * 非コーディングのプロトタイプを作成する + * WYSIWYGエディタでウェブページのワイヤーフレームを作成 + * グラフィカルなモックアップ/コラージュを作成 + * バーのナプキンとペン、スキャンまたは写真 + +### ユーザーと貢献者の成長に合わせて進化する + +「特定のユーザー層向けに、こうこうした理由で設計しました」と言うのは簡単です。しかし、唯一の制作者兼管理者であることはそう簡単ではありません。自分とニッチなグループを超えて成長したいなら、オープンなコラボレーションに伴う新たなアイデアや方向性の流入を受け入れる覚悟が必要です。 + +### 予測可能なスケジュール体系を採用し、それを厳守する + +オープンソースプロジェクトの進捗速度については意見が分かれます。多くのプロジェクトが6ヶ月リリースサイクルを最適と認識しています。どのスケジュール体系を選ぼうとも、それを厳守し、コミュニティに進行状況を常に共有する必要があります。覚えておいてください。時には人々を失望させることはあっても、驚かせることは避けるべきです。オープンソースの成果物提供には主に2種類のスケジュールがあります。 + +* 時間ベース +* 機能ベース + +時間ベースのスケジュールがオープンソースで頻繁に採用される理由の一つは、開発者に早期かつ頻繁なリリースを強制し、機能完成を待ってコードを放置するのを防ぐためです。段階的な更新はコミュニティに追従・支援・貢献の機会を提供します。機能ベースのスケジュールを採用する場合でも、それをより小さな時間ベースの成果物に分解すると効果的です。これによりコミュニティは、定期的に予測可能な間隔で試せるものが提供されることを理解し、関心を持ち続け、テストを継続できます。 + +### 優れた教師は優れた生徒である (質問し、自らを教えを受ける立場に置くこと) + +あらゆる年齢層や経験レベルの人々が、貢献できる知識と好奇心を持っています。たとえ相手があなたから学んでいる場合でも、自らを学ぶ立場に置くことで、彼らの知識や知りたいことに積極的に関わることができます。オープンソースの在り方を実践する一環として、この働き方や考え方、行動様式をなぜ、どのように採用すべきかを他者に教えることが重要です。あらゆる交流において、自分が専門家であり全てを知り尽くしていると決めつけないことが有益です。熟知している分野であっても、基礎的で愚かな、オープンで本質を問う質問を投げかけましょう。オープンソースの精神の原則を個々の領域に明らかにし、適用するための確証を得るのに役立つあらゆる質問を投げかけましょう。 + +### 障壁を可能な限り低くする努力 + +オープンプロジェクトは参入障壁が低い必要があります。個人や組織が時間やその他のリソースを提供しているのですから、彼らに障壁を飛び越えさせるなら、その障壁は明確な理由を持つ明白なものでなければなりません。さもなければ、それは目に見えない問題となり、人々が存在すら気づかれないうちに消えてしまう原因となります。新規参加者が実際の障壁、暗黙の障壁、偶発的な障壁に遭遇した場合、一定割合の参加者はその場で離脱します。少なくとも障壁の内容とその理由を説明すれば、参加者は無知ゆえの離脱ではなく、理解した上での離脱となります。オープンな協力者を求めるなら、あらゆる障壁を可能な限り低く設定すべきです。このアクセスレベルを明確に告知する必要があります。「メーリングリストへの書き込みやバグ報告が可能」から「ソースリポジトリへの主要なコード変更のコミットが可能」まで、アクセスレベルが存在する場合、それらのレベルと取得方法を明確に示さねばなりません。 + +Wikipediaは全員が同一レベルで参加する例です。ただし、情報ページ群を中心に暗黙的に形成されるコミュニティレベルは存在します。ページ編集自体は匿名でも容易ですが、その編集を定着させる（情報コミュニティ内の他の監視者によって元に戻されないようにする）には、より目に見えない障壁を乗り越える必要があります。特定のページ群を取り巻く情報コミュニティが匿名編集を厳しく制限している場合、このことがカジュアルな編集者を遠ざける可能性があります。他のページ群では情報コミュニティの規制が緩いため、匿名編集が定着しやすいのです。結局、これはウィキペディアの評判に影響する可能性があります——一部の人々は、目に見えず乗り越えられない参入障壁がウィキペディアにあると経験したり感じたりしているのです。 + +### 活動と参加を可視化する + +人は自分自身や他者の活動を見たいと願うものです。カフェでコーヒーを飲むことが自宅でのそれより特別に感じられるのもそのためです。それは社会的空間であり、オープンソースコミュニティの要素が社会的空間で発生するのと同じです。コミュニティ内の活動を強調しやすくするシステムとプロセスを構築しましょう。場合によっては、バッジやリーダーボードなどを用いたゲーミフィケーションが有効です。多くの場合、リリース時に_全員_の名前と貢献の種類／分野を明記することが含まれます。 + +### ドキュメントの力で、新規参加者を即座に貢献者に変える + +助けを求める際には、その回答をドキュメント化することをコミュニティの文化にしましょう。理想的には、質問者自身がドキュメント化を行うべきです。そして、その作業が簡単に行えるようなシステムを用意すべきです。助けを提供する側は、その助けをドキュメント化することを要求することができます。質問者がコミュニティの新規メンバーである場合、これはその人を即座に貢献者に変える素晴らしい方法です。 + +### 4つの共有美徳 + +この4つの美徳は、Brian Fitzpatrick と Ben Collins-Sussmanによる、[コミュニティにおける有害な人々を避ける方法](https://www.youtube.com/watch?v=-F-3E8pyjFo) に関する画期的な講演で述べられたものです。 + +* 礼儀正しさ +* 敬意 +* 信頼 +* 謙虚さ + +これらの美徳は、コミュニティのあらゆる部分で実践される必要があります。公開および非公開の議論、対面から IRC まであらゆるコミュニケーションチャネル、そして時にはプロジェクトそのものの性質においてもです。 + +### 支援し、関与したいユーザー（および貢献者）を明確に理解する + +これは、プロジェクトとコミュニティの初期計画から生まれるものです。これは、コミュニティがメンバーに提供する価値の継続的な健全性を測定する方法として、指標計画の一部を形成すべきです。プロジェクトの変化に伴い、この考え方に進化が生じた場合、この明確な理解を更新する必要があります。機能の追加（原文：feature creep）には副作用があります。開発進行中にユーザーやステークホルダーからの入力によって機能が量的に増加する現象です。リリースに忍び込むように追加された機能は、より多く、そして異なるユーザーや貢献者を惹きつける結果となる可能性があります。こうした新規参加者は決して悪いものではありません。しかし予期せず見過ごされると、コミュニティ内で十分な支援を受けられない層となります。この支援不足のグループは、自分たちのバブルの中で、プロジェクトやソフトウェアが自分たちに何を提供すべきか独自の理解を持っています。そのバブルを解き、コミュニティ全体の見解に彼らを含めるまで、プロジェクトに変化が生じるたびに彼らの世界観全体が危険に晒されるのです。 + +### 健全なプロジェクトには、徹底的に文書化され（かつ継続的に進化する）ガバナンスモデルが不可欠である。 + +ガバナンスは、毎年遵守すべき静的な文書やプロセスではありません。プロジェクトが多方面で進化するにつれ、ガバナンスもそれに応じて、さらには先回りして進化すべきです。ガバナンスには堅牢な変更管理を設け、早期かつ頻繁に活用するよう促す必要があります。ガバナンスの詳細は「プロジェクトとコミュニティのガバナンス」の章でさらに解説します。 + +### 可視化されたリーダーシップ + +大小を問わず、誰が何を担当しているのか、その人物への連絡方法などが明確である必要があります。リーダーは最前線に立ち、他のメンバーと共に作業を行うべきです。これは「ドゥオクラシー（行動主義）」と呼ばれる概念の一部であり、行動する者が物事を成し遂げる責任を負う文化を指します。 + +### リーダーの明確な責任 + +健全なプロジェクトでは、メンバーは正式に文書化されたリリースプロセスを持ち、そのプロセスを監督するリリースマネージャーを特定しています。健全なオープンソースプロジェクトは、公に共有された目標と、それらの目標を達成するための明確なプロセスを有しています。目標は達成可能であり、目標達成に向けた進捗を追跡するための明確な期限が存在します。 + +## コミュニティ監査 + +本章で概説する監査プロセスでは、監査実施時にワークシートを使用します。この場合、外部健康診断用の最初のワークシートが利用可能です。 + +ファイルはこちらからダウンロードできます： +[https://github.com/theopensourceway/guidebook/blob/master/worksheet\_for\_community\_audits.ods](https://github.com/theopensourceway/guidebook/blob/master/worksheet_for_community_audits.ods) + +これは以下の特徴を持つオープンドキュメントフォーマットのスプレッドシートです。 + +* 最初のシート「Overview」は全質問の単一の概要です。 +* 各質問は、サブ質問の基盤となる主要質問の形式で構成されています。サブ質問はプロジェクトごとに適用されない場合がありますが、主要質問は常に適用されます。 +* 「構造」「リリース管理」「アウトリーチ」などの各セクションには、サブ質問を含む専用のシートがあります。 +* 各シートには集計用のスコアリングやメモを記録できます。 +* 各セクションの質問に対する「はい」または肯定的な回答率に基づく健全性パーセンテージの概念があります。「いいえ」または否定的な回答は、プロジェクトにおいて重要な要素が欠落しているか問題がある可能性を示します。 + +このリスト自体は網羅的ではありませんが、1～4時間の注意と関心をもって個人がプロジェクトについて把握できる概要をよく表していると考えます。つまり、ユーザーがあなたのウェブサイトを訪れ、貢献者となる前向きな体験を得るかどうかは、この監査が注目する要素群に大きく影響されます。これらは、その体験を前向きなものにするための管理ポイントです。 + +このワークシートの使用プロセス概要は以下の通りです。 + +1. 各セクション（ラベル付きシート）に最大30分までを割り当ててください。それ以上の時間がかかる場合は、問題のある領域か、監査プロセスに適合しない要素を示している可能性があります。メモを残して次に進んでください。 +2. 公開情報のみを活用してください。プロジェクト管理者に直接問い合わせず、一般利用者の体験を把握することが本監査の目的です。 +3. 必要に応じて、各分野の専門家へシートの担当を割り振っても構いません。 +4. 現状で整備済みまたは十分な状態の項目数を、不足または改善が必要な項目数と比較集計することで、健全性の「スコア」を算出できます。 +5. 完了後、不足点や改善が必要な部分を説明する記述付き報告書を作成してください。 + +プログラミング言語やビルドシステムなどの特性上、十分ではあるが明確でない慣行に気付かない場合があることに留意してください。 + +## モデレーターとコミュニティリーダーのメンタルヘルスとバーンアウト対策 + +このサブセクションは、コミュニティメンバーのメンタルヘルスとバーンアウトリスクを真剣に考慮するよう促すものです。 + +コミュニティリーダーは、特に他の貢献者の世界や生活がうまくいっていない時に、プロジェクトをまとめる重要な役割を担っています。このため、コミュニティマネージャー向けセルフケア戦略の章では、この役割を担う人々に向けた包括的な議論を展開しています。 + +個々のコミュニティメンバーも、リーダーと同様のストレスや反応、状況に直面します。当該章は主にコミュニティマネージャーを対象としていますが、ほぼ全てのメンバーに適用可能です。 + +これらの資料に加え、コミュニティ全メンバーに適用される考慮事項は以下の通りです。 + +### バーンアウト + +プロジェクトに関わる誰もがバーンアウトを経験する可能性があります。個人の選択がバーンアウトにつながる影響に加え、システム的・制度的な原因も数多く存在します。それら全てを解決できない場合でも、その存在を認識することは、個人の手に負えない事象に対する個人的責任感を軽減する上で大いに役立ちます。 + +### セルフケアからコミュニティケアへ + +セルフケアは個人の責任に焦点が当てられがちです。確かに個人の健康には自己責任がありますが、私たちは往々にして関わるシステム（組織・政策・手順）の文化に反応しているのです。コミュニティケアのアプローチは、コミュニティ全体の構造と支援を取り入れることで個人の負担を軽減することに重点を置きます。 + +### 社会的戦略 + +コミュニティケアの一環として、セルフケアを管理する戦略を提供することがあります。感謝、喜び、受容をもって人々と関わることは、「十分でない」「やる気が出ない」「孤立している」という感情、さらには罪悪感や恥の感情に至るまでの解毒剤となります。 diff --git a/l10n/ja/measuring-success/understanding-community-metrics.md b/l10n/ja/measuring-success/understanding-community-metrics.md new file mode 100644 index 00000000..6c16723e --- /dev/null +++ b/l10n/ja/measuring-success/understanding-community-metrics.md @@ -0,0 +1,218 @@ +--- +description: +author: Ray Paik , Brian Proffitt , Bryan Behrenshausen +updated: 2020-09-17 +translated-by: Ken Komazawa powered by DeepL Pro +--- + +# コミュニティ指標の理解 + +本章では、オープンソースコミュニティの構築・維持・成長において、メトリクス（指標）駆動型アプローチの重要性を詳細に説明します。オープンソースプロジェクトとコミュニティの健全性を評価する際に考慮すべき重要な要素を概説します。コミュニティごとに特性が異なるため成功を測る指標も異なりますが、自コミュニティの成功を測定する際の参考となる指標例をいくつか提示します。 + +## 健全なコミュニティとは？ + +健全なオープンソースコミュニティとは、持続可能性を高めることを目標に、オープンな実践を示し、オープンなインフラを利用し、オープンな文化を育むコミュニティです。しかし、最も経験豊富なコミュニティマネージャーやコミュニティアーキテクトにとってさえ、オープンソースコミュニティの健全性を測定することは複雑で困難、時に気が遠くなるような作業です。 + +なぜなら、プロジェクトの健全性を示す全体像は実際にはモザイクのようなものだからです。複数の要素が組み合わさってコミュニティの総合的な健全性を描き出します。「ほら、コミュニティは健全だ」と指さして示せる単一の指標など決して存在しないのです。 + +さらに、プロジェクトとコミュニティの総合的な健全性を決定する要素は常に変化しています。例えば過去には、「総ダウンロード数」を健全性の指標として挙げる人もいました。しかし今日では、たとえ数百万回のダウンロードがあっても、コミュニティの生産プロセスと品質保証プロセスが同期していない可能性や、プロジェクトのメーリングリストで*荒らし*が暴れている事実を反映していないと理解されています。より完全な状況把握には、*結果*や*成果*（ダウンロード数、リリース頻度、 など）だけでなく、*プロセス*（新規参加の障壁、プロジェクトがメンテナを発見・昇格させる容易さなど）も考慮すべきです。 + +## コミュニティ指標が重要な理由 + +コミュニティ指標を確立・維持することが重要な理由はいくつかあります。 + +* 客観的な測定基準の提供 +* 透明性の文化の促進 +* コミュニティ参加の促進 +* 潜在的なコミュニティのボトルネックの特定 + +これらをそれぞれ詳しく見ていきましょう。 + +### 客観的な測定基準の提供 + +あらゆる組織において、自らのパフォーマンスを理解するための客観的な測定基準セットが必要です。ビジネスの場合、収益、新規顧客獲得数、コストなどが該当し、これらを定期的に（例：四半期ごと）確認することで進捗を把握できます。オープンソースプロジェクトにおいても、コミュニティの健全性を測る指標セットが有用です。これには貢献者数、バグ/課題の解決期間、レビュアーの対応速度、貢献者の多様性などが含まれます。 + +### 透明性文化の促進 + +透明性は全てのオープンソースプロジェクトの重要な要素です。そのため、プロジェクトへの貢献者全員を把握することが重要です。これは必ずしも最も活発な貢献者をランク付けしたり強調したりするためではありません。むしろ、貢献がどこから来ているのか（例：異なる地理的地域、組織など）をよりよく把握するためです。コミュニティメンバーが20～30人を超えると、適切な指標セットがなければ、すべての貢献者を十分に把握することが難しくなり始めます。 + +### コミュニティ参加の促進 + +コミュニティ指標は必ずしもコミュニティの全体像を示すものではありませんが、コミュニティの状態に関する重要な洞察を提供します。例えば、プロジェクトのコード、バグ/課題、ドキュメントなどで定期的な活動があるかどうかを指標で確認できます。また、新しいコミュニティに参加した人は、経験豊富なメンバーを見つけ、つながることに苦労することが一般的です。メトリクスダッシュボードに「活発なドキュメント貢献者」リストを掲載すれば、プロジェクト文書への貢献に関心のある者にとって有用です。新規メンバーを強調するため*初回*貢献者のダッシュボードを設けるコミュニティもあります。些細に思えるかもしれませんが、こうした取り組みは新規メンバーのプロジェクト参入や受け入れ感を大きく促進します。 + +### 潜在的なコミュニティボトルネックの特定 + +オープンソースプロジェクトが成長するにつれ、コミュニティメンバーへの対応速度に関する課題に直面することが一般的です。例えば、コードレビューに時間がかかるようになったり、未解決課題のバックログが増加したりする可能性があります。定期的なレビューを行う適切な指標セット（例：課題解決までの平均時間、コードレビューの中央値時間など）があれば、不満を持つコミュニティメンバーが増加する前に早期警告サインとして機能します。 + +## 基本となる考慮事項 + +プロジェクトとコミュニティの健全性をどのように測定するかを決定する前に、何を測定するかを明確にする必要があります。以下の観点から検討を始めることができます。 + +* プロジェクトのライフサイクル +* 対象とするユーザー層 +* ガバナンス +* プロジェクトリーダー +* リリースマネージャーとプロセス +* 目標とロードマップ +* オンボーディングプロセス +* 内部コミュニケーション +* アウトリーチ +* 認知度 +* エコシステム + +これらをそれぞれ詳細に検討してみましょう。 + +### プロジェクトライフサイクル + +オープンソースプロジェクトのライフサイクルは、プロジェクト健全性に関する他の多くの要素に影響を与えます。プロジェクトがライフサイクルのどの段階にあるかを理解することで、評価を文脈化できます（例：プロジェクトが若い段階では個人によるガバナンスが一般的ですが、成熟した段階では効果的ではありません）。貢献者の動向を監視することで、プロジェクトの短期的・長期的な将来に関する重要な情報が得られる可能性があります。 + +プロジェクトのライフサイクルを評価する際には、以下のような質問を考慮してください。 + +* プロジェクトはいつ設立され、どのくらいの歴史があるか？ +* 新規貢献者はどのくらいの頻度でプロジェクトに参加しているか？ +* プロジェクトはどのくらいの頻度で新たな貢献を受け入れているか？ + +### 対象ユーザー + +適切に運営されているオープンソースプロジェクトは、支援・関与を望むユーザー（および貢献者）を明確に理解しています。プロジェクトの対象ユーザーを評価する際には、以下のような質問を考慮してください。 + +* プロジェクトは対象ユーザーを明確に特定しているか？その対象は誰か？ +* 対象ユーザーは本プロジェクトにとって最適か？ +* 対象ユーザーは競合プロジェクトや補完プロジェクトに関与しているか？ + +### ガバナンス + +ガバナンスとは、オープンソースプロジェクトにおける役割分担と行動規範を定義する規則や慣習を指します。健全なプロジェクトには、徹底的に文書化され（かつ継続的に進化する）ガバナンスモデルが不可欠です。プロジェクトのガバナンスを評価する際には、以下のような質問を考慮してください。 + +* プロジェクトのガバナンスモデルは何か、そしてそれは公開文書化されているか？ +* モデルは技術的懸念とビジネス的懸念の両方を考慮しているか？ +* プロジェクトメンバーはどのように意思決定を行い、それを実行に移すか？ + +このトピックに関するさらなる考察については、このガイドブックのガバナンスに関する章を参照してください。 + +### プロジェクトリーダー + +健全なプロジェクトでは、リーダーは可視化され、容易に識別可能です。リーダーはプロジェクト作業の調整やビジョン策定を担い、通常はプロジェクトの経緯に精通しています。プロジェクトのリーダーシップを評価する際には、以下のような点を考慮してください。 + +* プロジェクトリーダーは誰か？ +* プロジェクトリーダーの責任範囲は何か？エンジニアリング、マーケティング、あるいはその両方の組み合わせに重点が置かれているか？ + +### リリース管理者とプロセス + +健全なプロジェクトでは、メンバーは正式に文書化されたリリースプロセスを持ち、そのプロセスを監督するリリース管理者を明確にしています。プロジェクトのリリース管理者とプロセスを評価する際には、以下のような質問を考慮してください。 + +* プロジェクトのリリースプロセスは文書化されていますか？ +* プロジェクトには明確なリリース管理者が存在しますか？ +* プロジェクトのリリース更新はどのくらいの頻度で行われていますか？ +* プロジェクトのリリースは安定して予測可能なスケジュールで実施されていますか？ + +### 目標とロードマップ + +健全なオープンソースプロジェクトは、公に共有された目標と、それらの目標を達成するための明確なプロセスを有しています。目標は達成可能であり、進捗を追跡するための明確な期限が設定されています。プロジェクトの目標とロードマップを評価する際には、次のような質問を考慮してください。 + +* プロジェクトの目標は明確かつ公開されていますか？ +* プロジェクトには明確に伝達されたプロセスがあり、それも公開されていますか？ +* プロジェクト参加者は、プロジェクトの期限を遵守してきた実績がありますか？ + +### オンボーディングプロセス + +新規貢献者は、プロジェクトの革新と成功に不可欠です。健全なプロジェクトでは、参加を希望する新規メンバーを支援する明確で歓迎的なオンボーディング資料が用意されています。プロジェクトのオンボーディングプロセスを評価する際には、以下のような点を考慮してください。 + +* ドキュメントはプロジェクトの内容と使用方法を正確に説明していますか？ +* ドキュメントは新規貢献者がプロジェクトに参加する手助けになりますか？ +* プロジェクトは複数の種類の貢献（例：開発、マーケティング、プロジェクト管理、イベント企画）を受け入れていますか？ + +### 内部コミュニケーション + +コミュニケーションチャネルは、プロジェクトの健全性を示す重要な指標であり、プロジェクトの内部コミュニケーション慣行も同様です。コミュニティの健全性に影響を与える問題は、多くの場合、貢献者とユーザーが交流するメーリングリストやチャットプラットフォームなどの内部チャネルで最初に顕在化します。プロジェクトの内部コミュニケーションを評価する際には、次のような質問を考慮してください。 + +* プロジェクトには十分なコミュニケーションチャネルが存在するか？ +* 人々はこれらのチャネルを効果的に見つけ、利用できるか？ +* チャネルは定期的にモデレートされているか？ +* チャネル上のコミュニケーションは行動規範によって管理されているか？ +このトピックに関する詳細な考察については、本ガイドブックの「コミュニケーション規範」の章を参照してください。 + +### アウトリーチ + +アウトリーチとは、プロジェクトを積極的に宣伝し、他者に認知させるプロセスです。コミュニティは、アウトリーチのために書面による資料（例：ソーシャルメディア、ブログ、ホワイトペーパー）、イベント（例：ミートアップ、コンベンション）、教育的な手法（例：デモ、トレーニングセッション）を利用します。健全なプロジェクトは、アウトリーチに十分なエネルギーとリソースを割いています。プロジェクトのアウトリーチ活動を評価する際には、以下のような点を考慮してください。 + +* コミュニティは明確で一貫したアウトリーチ手法を採用していますか？そうでない場合、アウトリーチ手法の体系化を計画していますか？ +* 人々は、このプロジェクトとその技術について執筆し、議論し、宣伝していますか？ + +### 認知度 + +プロジェクトの想定対象者は、プロジェクトの存在を認識し、それが解決する問題を理解している必要があります。認知度はプロジェクトのアウトリーチ活動の望ましい成果であり、ユーザーや貢献者へのアンケート調査、あるいは一般的なマーケティング分析を通じて測定できます。プロジェクトの認知度を評価する際には、以下のような質問を考慮してください。 + +* 対象ユーザーはプロジェクトの存在を認識しているか？ +* 対象ユーザーは、プロジェクトの用途、機能、代替手段に対する優位性を説明できるか？ +* プロジェクトの恩恵を受け得る業界で働く他の人々は、プロジェクトの存在を知っているか？ + +### エコシステム + +プロジェクトは孤立して存在しません。プロジェクトは互いに依存し合うことが多く、場合によっては類似プロジェクトが同じ対象層の獲得で競合することもあります。コミュニティがエコシステム内の他プロジェクトと交わす相互作用は、プロジェクトの健全性を反映します。プロジェクトのエコシステムを評価する際には、以下のような質問を考慮してください。 + +* プロジェクトの依存関係は何か？また、どのプロジェクトが当プロジェクトに依存しているか？ +* コミュニティは、プロジェクト全体のエコシステム、対象業界、プロジェクトを利用する可能性のある組織に十分に統合されているか？ +* そのエコシステムのメンバーは、このプロジェクトを好意的に捉えているか？ + +## コミュニティに適した指標の選択 + +オープンソースコミュニティは一つとして同じものがないため、健全性と成功を測る指標は各コミュニティごとに固有のものとなります。コミュニティが指標を選択する際には多くの要因が影響しますが、最も重要な影響要因の一つはコミュニティの目標です。 + +例えば、コードを迅速にマージできることを優先するコミュニティは、この能力に関連する指標を追跡します。一方、エネルギーや医療など規制の厳しい業界で活動するユーザーや貢献者で構成されるコミュニティでは、新たな修正や機能のマージ決定に時間がかかるのが必然です。こうしたコミュニティでは、コードレビューの速度よりも、例えばコードレビューの効率性を重視するでしょう。 + +コミュニティは目標に応じて、作業バックログ、貢献者の多様性（組織・地理的背景など）、新規貢献者の流入、ローカライゼーションと国際化、議論トピックの人気度などを測定する指標を設定する可能性があります。指標は常に共同で策定し、全員で合意すべきです。指標が包括的でコミュニティの一部のみに偏らないよう、多様なメンバーの意見を聴取することが重要です。 + +また、定期的にコミュニティと指標を見直し、調整の必要性を議論することも良い慣行です。同じコミュニティ内でも、ニーズの変化に応じて指標を進化させる必要があるでしょう。 + +## コミュニティ向け指標開発リソース + +### ソフトウェアツールの既存機能を活用する + +かつては、コミュニティの指標取得に複雑なスクリプトやクエリを記述するケースが多かったです。しかし現在では、オープンソースプロジェクトで一般的に使用されるソフトウェアツール（コードリポジトリ、フォーラム、課題管理ツール、Wikiなど）のほとんどが、APIやプラグイン、あるいは組み込みダッシュボードを備えており、コミュニティデータの収集を容易にしています。したがって、Discourse、GitHub、GitLab、Jiraなどのツールを利用している場合、新しいメトリクスをゼロから実装する前に、それらのドキュメントを読むことで多くの時間を節約できる可能性があります。 + +### CHAOSSプロジェクト + +当然ながら、コミュニティメトリクスに特化したオープンソースプロジェクトが存在します。CHAOSS（Community Health Analytics for Open Source software）と呼ばれるこのプロジェクトには、学術機関、多数のオープンソースプロジェクトに参加する企業、オープンソース財団などからのコミュニティメンバーが参加しています。[CHAOSSウェブサイト](https://chaoss.community)にアクセスすると、様々なカテゴリにわたるメトリクスの詳細と、それらの多くに対する実装例を確認できます。 + +CHAOSSのメトリクスを閲覧すれば、自コミュニティに適用可能なメトリクス（および実装例）を多数見つけられるでしょう。CHAOSSに未掲載の新メトリクス案があれば、CHAOSSコミュニティ内で議論を始めることも可能です。 + +### 他コミュニティのリソース/事例 + +多くのオープンソースコミュニティでは、他のコミュニティも活用できる優れたドキュメントやコードをコミュニティダッシュボード向けに公開しています。読者の多くは[CNCFダッシュボード](https://k8s.devstats.cncf.io/)をご存知でしょう。CNCFのリポジトリでは、ダッシュボードの基盤となる`devstats`プロジェクトの詳細を確認できます。 + +もう一つの良い例は[Rubyコミュニティダッシュボード](https://contributors.rubyonrails.org/contributors)とその[FAQページ](https://contributors.rubyonrails.org/faq)です。ダッシュボード開発の背景や実装上の判断について有益な知見が得られます。 + +一部のコミュニティは各リリース後に貢献度メトリクスを公開しています。最近のリリース後の[WordPressの好例](https://jeanbaptisteaudras.com/en/2020/03/wordpress-5-4-core-contribution-statistics/)では、貢献の発生源を示す優れた可視化が多数確認できます。 + +## メトリクスの落とし穴 + +メトリクスは確かに重要ですが、認識すべき欠点も存在します。 + +* 人は最も測定しやすい指標を優先しがち：これは人間の本性であり、誰もが容易な方法を選びたがるからです。しかし、コミュニティにおいて測定しやすい指標のみに焦点を当てると、重要な側面を見落とすリスクがあります。例えば、コミット数やマージリクエスト数といった「入力」を、コミットやマージリクエストがもたらす「影響」といった「出力」よりも簡単に測定できるケースが多いです。言うまでもなく、コミュニティからの出力を無視すれば、コミュニティの全体像は不完全なものになります。 +* 指標への過度の依存は不完全な洞察をもたらす：いかなる指標群もコミュニティ（あるいは組織全般）の全体像を提供することはできません。時間の経過に伴うコミュニティの進捗を測るための標準化された指標セットは重要ですが、測定や定量化が極めて困難な要素は常に存在します。例えば、貢献者がコミュニティに強い帰属意識を持ち、他のメンバーとの協働を楽しむことは誰もが望むことです。これが実現されているか否かを定量化するのは困難ですが、指標収集以外の手段を必要とする場合でも、コミュニティの健全性におけるこの側面を適切に把握したいと考えるでしょう。 +* 内発的動機付けの無視：人々は（特にボランティア組織に）内発的動機付けによって参加することが多いです。例えば、グループの使命に強く共感したり、他のメンバーとの帰属意識を楽しんだりするためです。メトリクスにおいて個人の貢献度（またはインプット）を過度に重視すると、人々が組織に参加した本来の理由を見失うリスクがあります。オープンソースコミュニティの貢献者の大半は、自身の時間を使って貢献するボランティアです。彼らの内発的動機付けを無視することは、コミュニティに悪影響を及ぼすことが多いのです。 + +内発的動機付けに関する詳細は、「参加者の動機」の章を参照してください。 + +こうした指標全般の欠点に加え、オープンソースコミュニティに特に該当する問題点が以下にあります。 + +* 貢献度指標の悪用：コミュニティ内での評価基準として指標が主要（あるいは唯一の）根拠とされる場合に発生しがち。当然ながら、単一のコミット/マージリクエスト/プルリクエストで済む作業を、些細な変更ごとに複数回に分けて提出するといった行動が見られる。 +* 虚栄の指標（バニティメトリクス）：オープンソース以外でも見られる現象です。ソーシャルメディアのフォロワー数などに過度に重点を置くのが典型例です。ソーシャルメディア同様、量だけが全てではありません。また、コミュニティメンバーの内発的動機付けを満たすことを望むなら、虚栄の指標は明らかに適切な手段とは言えません。 +* 限られた指標で異なるオープンソースコミュニティを比較する：例えば「プロジェクトAのカンファレンスには前回5,000人以上が参加した」「プロジェクトBには1,000人の貢献者がいる」といった話を耳にすることがあり、人々は自身のコミュニティにも同様の成果を期待しがちです。他コミュニティと比較したくなる前に、それが「リンゴとリンゴの比較」、つまり同等の条件下での比較かどうかを慎重に検討することが重要です。異なる業界に属している、プロジェクトの成熟度が異なる、スコープが異なるなど、直接比較が適切でない場合もあります。コミュニティに1,000人の貢献者を求める前に、基本的な問いを自問すべきです。例えば「プロジェクト目標達成に本当に1,000人が必要か？」といった点です。 +* コード貢献への過度な焦点：コード活動を計測するツールが増えたためか、オープンソースコミュニティではコード貢献に偏りがちです。しかし、フォーラムでの質問への回答、課題の優先順位付け、Wikiページの維持管理など、他の貴重な貢献も忘れてはなりません。コミュニティの指標が（コードと非コードの両方の）多様な貢献を反映し、コミュニティの誰も取り残されたと感じないように努めるべきです。 + +## 指標の適切な活用と避けるべき点 + +最後に、オープンソースコミュニティの指標を扱う際の適切な活用法と避けるべき点を示します。 + +### 推奨事項 + +* 指標を公開すること：当然のことかもしれませんが、オープンソースにおける透明性は指標にも及ぶべきです。指標を開発する際には、多様な人々をプロセスに含めることで、包括的であらゆる貢献を考慮した指標となります。また、コミュニティ指標の調整が必要な場合、最初にフィードバックや提案を得られるのはコミュニティメンバーである可能性が高いです。また、データの信頼性を確保するため、全てのメトリクスは誰もが閲覧できる状態にすべきです。 +* 外れ値の発見にメトリクスを活用する：メトリクスは特に、調子の悪い領域を浮き彫りにするのに有用です。良い例としては、課題のクローズ時間、フォーラム投稿への回答時間、コードレビューなど、スループットに関連する事項が挙げられます。これらの事例では、メトリクスは潜在的なボトルネックを早期に特定する優れたツールとなります。 +* コミュニティの健全性を深く理解する出発点としてメトリクスを活用する：メトリクスはコミュニティで*何が*起きているかを示しますが、数字だけを見て*なぜ*起きているかは通常わかりません。例えば新規貢献者の数が減少している場合、その原因を特定するには個別面談や電話での対話が必要になるでしょう。メトリクスは出発点として症状を浮き彫りにしますが、そこから先は人々が作業を進める必要があります。 + +### 避けるべきこと +* 報酬の唯一の基準として指標を使用しない：コミュニティで報酬を指標のみに依存すると、貢献指標の不正操作が生じることは既に議論しました。さらに、報酬や評価が主に作業量（またはインプット）に基づくと認識されると、プロジェクトに多くの時間を割けない人やコミュニティを始めたばかりの人を落胆させるリスクがあります。人々は単に作業量を増やすためだけにオープンソースコミュニティに参加するわけではなく、彼らの内発的動機を見失ってはなりません。 +* 適切な文脈なしにメトリクスを提示しない：「コミュニティの貢献者数は？」といった単純な質問に見えても、その背景にある文脈を把握することが常に重要です。質問者によって、求めている内容は微妙に異なります。例えば、プロジェクトの歴史における総貢献者数はある文脈では適切でも、別の文脈では期間ごとの貢献者数の増加が真の目的である場合があります。また「貢献者」の定義は？国際化対応、課題の優先順位付け、イベント企画などへの貢献者も含むのか？したがって、単に指標セットを示す前に、質問の背景にある文脈や動機を理解することが重要です。 +* 非指標の無視：前述の通り、全てが容易に測定・定量化できるわけではありません。たとえ洗練された指標ダッシュボードを構築しても、コミュニティの動向を把握し、指標では捉えきれない要素をメンバーから指摘してもらうため、人間同士の対話を継続すべきです。 diff --git a/l10n/ja/presenting-the-open-source-way.md b/l10n/ja/presenting-the-open-source-way.md new file mode 100644 index 00000000..66171993 --- /dev/null +++ b/l10n/ja/presenting-the-open-source-way.md @@ -0,0 +1,87 @@ +--- +author: Karsten Wade +updated: 2020-11-03T00:00:00.000Z +translated-by: Ken Komazawa powered by DeepL Pro +--- + +# 序文：オープンソースウェイの提唱 + +英語の慣用句に「私の狂気には道理がある[^method]」というものがあります。大抵の場合、私たちの行動は外部から見ると全く意味をなしません。文脈を離れると、それはまったくの狂気のように見えます。しかし、その混沌の中——活動という旋風のなか——にいる者たちにとっては、そこには一定の規則性、一定の予測可能性、そして一定の動機があるのです。そう道理があるのです。 + +道理とは_何かを行う方法_、特定のやり方や実践スタイルです。オープンソースコミュニティ運営の実践は、特にオープンソースソフトウェアの制作過程に不慣れな者や、他者を巻き込んで制作に参加させる調整を迫られる立場にある者にとって、理解不能な狂気そのもののように映りかねません。このガイドが提供したいのは、絶えず進化する方法論、実践の形態に対する洞察です。その核心にあるのは単純な問いです。「オープンソースのやり方を実践するにあたり、あなたの好みは何ですか？」 + +しかしそれ以上に、この作業は本質的に_なぜ_その方法で取り組むのかという問いを掘り下げています。なぜ様々な方法で狂気を組織化するのでしょうか？ + +この序文から二つの重要な点を理解してください。 + +1. オープンソースソフトウェアを成功裏に、かつ持続的に創出し維持する実践には、_何を_（目的）、_どのように_（方法）、そして_なぜ_（理由）が存在します。 +2. このガイドは、数多くのオープンソース実践者たち——常に「なぜ我々はオープンソースをこの方法で進めるのか？」という問いに答えざるを得ない人々——の意見を凝縮したものです。 + +特に、このガイドは生きている文書であり、オープンソースソフトウェアコミュニティを構築・管理する最良の方法を（多少の主張を交えつつ）同様に収集している多様なグループの声を集め、広めることを目指しています。 +これらの声はすべて、[オープンソースソフトウェアコミュニティ管理に関する実践コミュニティ](https://theopensourceway.org)の一部です。 + +## 物事の構造（すなわち、私たちが前提としていること） + +このガイドの目次を見ると、組織的な流れに気づくでしょう。ユーザーから参加者へ、そして貢献者へと。この構成は、コミュニティがどのように生まれ成長するかという私たちの見解を具体的に辿っています。そしてすべてはニーズから始まります。オープンソースプロジェクトやコミュニティで働いた経験があれば、このサイクルを何度も目にしたことがあるでしょう。その流れは次のようなものです。 + +1. 問題に取り組む個人またはグループが、その問題に対する一つの解決策を提供するソフトウェアの最初のバージョンを作成する。 +2. 同様のニーズを持つ他の人がそれを使い始め、ユーザーベースの中核を形成する。 +3. ユーザーベースから熱心な支持者が現れ、ソフトウェアと、その周りに生まれるコミュニティ（つまり、プロジェクトが掲げる価値観や原則）を推進する。 +4. やがてユーザーや熱心な支持者の中から、何らかの形でソフトウェアに貢献することに興味を持ち（かつその能力を身につけた）人々が現れます。彼らはプロジェクトが活発な状態を維持し、当初開発された問題の性質の変化に対応することを保証します。 + +したがって、プロジェクトの主要かつ継続的な焦点は_ユーザーを大切にすること_です。なぜなら、ユーザーの一部は貢献者となる可能性があり、その貢献が不満ではなく愛着から生まれることを望むからです。 + +このすべてにおいて重要なのは、あらゆる種類・レベルの貢献に価値を見出すことです。単一の貢献形態だけを称賛するのではなく、プロジェクトへのあらゆる贈り物を平等に扱うことが最善の実践です。こうした貢献には、コンテンツやコード、時間や労力、さらにイベントやディスカッションフォーラム、インフラ維持など、プロジェクトへのあらゆる広範な貢献が含まれます。 + +参加の障壁を低くすれば、プロジェクトはあらゆるレベルで歓迎される場となります。これは_全ての障壁を取り除く_ことではなく、大半の障壁を適切に下げることを意味します。例えばシステムへのアクセス権限を付与する際には適切な障壁が必要であり、ヘルプ記事の執筆や構成管理システムへのパッチ貢献が特定の参加者だけに許可されることとは異なります。 + +## 私たちの核心的な考え方 + +この作業の核心には、コンテンツの構成方法や、オープンソース実践の旅路において自分がどこにいるのかを把握できるよう、道筋のステップを明らかにする方法を説明する考え方があります。 + +> エンドユーザーに焦点を当て、あらゆる参加障壁を低くしましょう。 +> +> 貢献者は参加者から生まれ、参加者も皆、ユーザーとして始まります。 +> +> ユーザー中心の取り組みでソフトウェアを大成功させつつ、コミュニティをオープンにし、ソフトウェアの作り方に興味を持つユーザーを歓迎しましょう。 + +したがって、このガイドブックの道筋は次の通りです。 + +1. **ユーザーを惹きつける**：ソフトウェアが彼らの問題を解決するため +2. **参加者を導く**：オープンソースと優れた解決策の共有に関心を持つ人々が、ソフトウェアの効果的な愛好者となれるよう +3. **貢献者を育成する**：この豊かで肥沃なユーザー・熱心な支持者層がソフトウェアの作り方を調べた時に、自分たちのことが表現されていると感じ、どう関われるか想像できるようにする。彼らが貢献者の場に参加する時、障壁が明確に低く、迎え入れられる状態にすること。 + +こう考えてみてください。素晴らしいダンスパーティーの存在を知らせるとしましょう。しかし、そのダンサーたちに「あなたのダンスパーティーのスタイル」を支持する力を与えるのは別次元のことです。さらにできると素晴らしいのは、世界中のあらゆる音楽やダンスを受け入れられるよう、ダンスパーティーを進化させることです。 + +ポスターを見て参加してくれるダンサーを獲得することは、彼らが居続けられるための第一歩です。そして、ここが自分たちの居場所だとすぐに理解できる環境が重要です。 + +プロジェクト成功へのこの道筋は、専門知識（あるいはプロジェクトに関連する既存スキル）よりも、好奇心やソフトウェアを試す意欲、ソフトウェアへの関心、そしてソフトウェアの創造への参加意欲を重視していることがお分かりいただけるでしょう。これは人々がプロジェクトにスキルを持ち込まないという意味ではありません。多くの場合、プロジェクトとの最初の接触時点から既にスキルは存在します。しかし、スキルを教えることは、誰かにあなたのプロジェクトを心から気にかけさせることよりも容易なのです。 + +この旅路において、コミュニティの進捗を測定する計画の立て方を含め、私たちが推奨するベストプラクティスは数多くあります。また、コミュニティ管理者自身のセルフケアやメンタルヘルスへの配慮に関する活発な議論を含め、注意すべき具体的な領域もいくつか挙げています。 + +こうした情報を深く伝える最良の方法は、事例紹介です。章本文で自然に生まれる事例に加え、ガイドブックや[The Open Source Wayコミュニティ](https://theopensourceway.org)には、その「理由」を説明する事例が数多く集められています。 + +## 本ガイドの構成 + +本ガイドの各セクションは、1つ以上の章で構成されています。 + +章は、独立したトピックまたは密接に関連するトピック群の議論を表します。 +各章は単独で読める構成となっており、ガイド全体の他の部分を読まずとも、その章の内容を理解し実践に移せるよう設計されています。 + +各章は以下の要素で構成されることを目指しています。 + +* **導入部** +* **主要な内容**：三人称視点で記述され、「何を」「どのように」「なぜ」のバランスに焦点を当てます。ここで語られる事例（ストーリー）は簡潔で三人称で記述されます。 +* **用語集**：章内で使用される専門用語の定義を最後に記載する。 +* **体験談**：実践者による有用で有益な経験を共有する（一人称で記述される場合あり）。 +いずれかの要素が欠けている章を見つけた場合は、ぜひご自身の知見や視点を本プロジェクトへご寄稿ください！ + +## 常に自らを再構築する実践コミュニティ + +ここで読んでいる内容は、このコミュニティが集め、育み、維持している原則・実装例・事例の集合体の一端に過ぎません。 + +結局のところ、これは資料をまとめる一つの方法に過ぎません（ある意味、混沌を整理する手法と言えるでしょう）。このガイドは更新され、類似の新たなガイドも発行されます。また、この資料を理解し提示する他の方法も模索していくでしょう。 + +しかし核心部分では——オープンソースコミュニティに利益をもたらす_何を_と_どのように_に加えて——_なぜ_を理解し、その物語をどこへでも広められるようになるでしょう。 + +[^method]: ウィリアム・シェイクスピア作『ハムレット』第2幕第2場より：ポローニアス（独白）「気が狂っているが、そこには道理があるのだ。」