本記事は、Octoverse (オクトバース) 2019年次レポートに続き、COVID-19感染拡大の初期段階において、GitHub上でのソフトウェア開発活動に関する傾向と知見を提供する特別レポートです。執筆は、GitHubデータサイエンスチームが担当しています。
注：本レポートの図やグラフは、モバイル画面向けに最適化されていないため、大型画面でご覧いただくことをお勧めします
概要
テーマ1：生産性と活動
テーマ2：就業リズム
テーマ3：共同作業
所見：Pull Requestのマージ時間
所見：オープンソースへのコントリビューション
分析データについて
概要
新型コロナウイルス感染症（COVID-19）の発生により、突如として世界の人々が自宅で過ごすことを余儀なくされました。その結果、多くの組織が可能な限り、何らかの形でのリモートワークへの対応に迫られ、数日間で何百万にのぼる人々の日常や環境が変化しています。つまり、ソフトウェア開発者などのテクノロジー専門家がリモートファーストの世界へと移行が進んでいます。、その多くが子供や家族の面倒も見ながら、同時に新たな就業リズムを見出し、仕事とプライベートのバランスを保つ（あるいは、単にそれぞれを維持する）ということの本質を捉え直しています。
このような変化が、開発者の仕事にどのように影響を及ぼしているのでしょうか。本レポートでは、生産性と活動、就業リズム、共同作業という３つのテーマを設定し、そこから得られたデータを分析しているものです。まず、所見でにおていは、ソフトウェア開発者や企業のリーダーに向けた知見を提供するほか、不透明な時代によって新たな形で分散されたチームを率いる状況におけるの課題を取り上げます。
世界最大のグローバル開発プラットフォームを提供するGitHubは、ソフトウェアの開発活動のパターンや変化を把握できる独自の立場にあります。これらを分析し、本レポートを共有することで、コミュニティが開発活動の状況を把握し、将来的なビジネスの混乱にも上手く備え適応できるようにサポートすることを目指しています。GitHubの年次レポート「State of the Octoverse」の発表に向けて、今年はこれらの分析をさらに拡大させていく予定です。これにより、状況の経時的な推移を把握することができるので、ご期待ください。
主な所見
2020年1～3月期の状況（対2019年同期）：
- 開発活動は昨年とほぼ同じか、増加した。ユーザ1人あたりPush、Pull Request、Pull Requestのレビュー、Issueへのコメントなどの開発活動は、昨年よりもわずかに増加しました。不透明な時期であっても、開発者の貢献や力強さは失われていないことが読み取れます。
- GitHub Issueへのコメント数の変化は、作業の分散化や各地でのウイルス対策を反映していると考えられる。分析から、COVID-19が拡大し、外出制限が発令された頃に、GitHub Enterprise Cloudアカウントが所有するリポジトリ内で Issueへのコメントが増加していることが判明しました。このコメント増加は、作業の分散化に伴い企業のソフトウェア開発の形式、構造、調整が混乱していることが原因と見られます。GitHub上では、Issueによってチームは機能強化、タスクやバグの管理といった調整が行われているからです。
- 就業リズムが変化している。平日および休日ともに、開発者の労働時間が1日あたり最大1時間延びました。労働時間の増加は、多くの開発者が自宅で仕事をするようになり、仕事以外の中断時間（家族や子供の世話など）が発生していることが、原因かもしれません。
- 開発活動パターンにバーンアウト（燃え尽き症候群）の兆候が見える。新しい業務体制へと移行したにも関わらず、開発活動が維持されている理由は、開発者のオンライン時間が増えている可能性があります。休息や考える時間、公私の切り替えに必要なプライベートやオフの時間との引き換えとして、仕事量が増えているのであれば、長期的には続かない可能性があるため注意が必要です。
- オープンソースプロジェクトを中心に、共同作業が増加している。昨年と比較し、一部のオープンソースプロジェクトの活動は急増し、オープンソースプロジェクトにおけるPull Requestのマージ時間は減少しています。これらの傾向から、コミュニティがオープンソースプロジェクトに関わる時間が増えていることが推測できます。
分析結果に基づく提案
- 柔軟性を強化することが組織を強化する。分析から、開発者の変化に対する適応力が証明されました。この危機的な状況下であっても、開発活動に変化はなく、むしろ活発化しています。企業側もプロセスや手順を順応させ、開発者と同様に、素早く新しい体制を取り入れることができれば、変化に適応し、成功も収めることができます。そのためには、機能強化、タスク、新機能、バグなどのプラニングや管理作業のための柔軟なツールやプロセスを導入し、作業場所に関わらず、開発者の生産性をサポートすることが必要です。
- 共同作業やオープンソースを取り入れる。開発者は、学習、成長、交流の場として、オープンソースコミュニティを利用しています。各開発者は、これをクリエイティビティや学習の場と見なし、たとえ同じコンピューターの画面上であっても、心理的に仕事から「踏み出し」、クリエイティブや学習関連プロジェクトに「入り込む」ことができます。企業は、業務外の活動や外部の技術に関するポリシーを精査し、開発者が学習プログラムに参加する時間や、外部プロジェクトへの関与を認めるポリシーを確立するべきです。オープンソースプロジェクトは仕事に必要なだけでなく、開発者の息抜きや自己啓発にも役立つものであることを認識することが重要です。
- バーンアウト（燃え尽き症候群）を警戒する。自宅での労働時間、仕事量、責務が増加すると、バーンアウトに陥る可能性が上昇します。休憩を取り、自身とチームメンバーにとって持続可能な仕事量を維持し、仕事とプライベートの区別することで適切なワークコミュニティを形成してください。
本レポートの読み方
本レポートの分析では、テーマごとに異なるデータセットを使用しました。各セクションの研究課題に適したデータセットが選択されています。各データセットの詳細については、このようなボックス内で説明します。テーマ3では、2種類の説明が提供されています。本分析に関する全般的な情報（GitHubユーザのデータ）、調査手法の選択、限界、今後の示唆については、本レポートの末尾をご覧ください。
テーマ1：生産性と活動
COVID-19の拡大後、ビデオ会議を始めとする様々なテクノロジープラットフォーム（ZoomやMicrosoft Teamsなど）を利用した活動が増加しました。同僚や顧客とのコミュニケーション、あるいは会議の手段にに関する興味深いデータではありますが、単純に、人々の交流の在り方が対面式からオンライン方式へと変化している証かもしれません。
開発者の労働状況（ここでは、COVID-19流行下における開発作業の変化）を把握するには、インタビューやアンケート調査を通して、開発者に直接尋ねるか、開発の際に作成されるアーティファクト（メモ、ソースコード、システムログなど）を調べることが考えられますが、開発者の生産性と活動に関するこの調査では、GitHub上の開発者の活動を分析しました。
生産性などの複雑な要素を、コードの行数やクローズしたIssueの数などの一つの指標で単純に測ることはできません。これらの指標には、タスクの影響度、煩雑性、成果などが反映されていません。最近の調査から、開発者の生産性には、コードの記述、完成、検討にかけた時間など、複数の要素が組み合わさっていることが分かりました（Meyer et al. 2014）。本分析でも同様のアプローチを採用し、複数の開発活動要素を測定することで、開発者の生産性を複合的に示すほか、開発者自身の感覚も反映させています（Meyer et al. 2014）。
開発は変わらない
業務体制の変化に上手く順応している活動については、GitHub上の開発活動を指標として利用することができます。カンバンボードなど、一部の作業はホワイトボードからオンラインツールへと移行しているかもしれませんが、オフィスでも自宅でも作業場所に関わらず、開発状況はPush数、Pull Request数、Issueへのコメント数などから把握することができます。このため、前年のデータと比較し、信頼できる分析を行うことができます。
一方、ビデオ会議に関して、会議数そのものは変化していなくても、利用するケースが増えています。そのため、これまでリモートワークをしていなかった開発者に関しては信頼できる対前年比分析はできません。
テーマ1：データ
本セクションの分析では、公開（オープンソースを含むパブリックリポジトリ）および非公開（プライベートリポジトリ）のGitHubプラットフォーム上のすべての活動について、前年のデータと比較しました。2019年1月1日～2019年3月31日の間と2020年1月1日～2020年3月31日の間のデータを比較しています。分析対象のアクティブユーザの地理的分布における対前年比変化は、以下の通りです。
図：テーマ1の分析対象アクティブユーザの地理的分布（2019年1月から2020年3月の変化）
太平洋時間5月6日午後2時に更新：オーストラリアの増加率を修正。
所見
前年データとの比較を容易にするため、本レポートの分析では、別途記載がある場合を除き、ユーザ1人あたりを数値を掲載しています。
ユーザ1人あたりのPull Request数、Push数、Pull Requestのレビュー数、Issueへのコメント数が増加
開発者の複合的な生産性を調べるため、ユーザ1人あたりのPull Request数、Push数、Pull Requestのレビュー数、Issueへのコメント数を調査しました。全体的に、これらの活動は昨年と同等か、もしくは昨年よりも増加しています。
まず、1日のユーザ1人あたりのPull Request数を見てみましょう。グラフに記載の通り、定期的に活動が落ち込む部分は週末を表しています。
グラフ：アクティブユーザ1人あたりのPull Request数比較（週末を含む）
週末を除外すると、より起伏が少なく分かり易いグラフになります。下図は、1日のユーザ1人あたりのPull Request数を示すグラフから週末を除いたものです。別途記載する場合を除き、今後は分かり易いように、下図のようなユーザ1人あたりの活動を、週末を除いて平坦化したグラフを提示します。
グラフ：アクティブユーザ1人あたりのPull Request数比較（週末を除く）
次に、週末を除く、1日のユーザ1人あたりのPush数を示すグラフをご覧ください。
グラフ：アクティブユーザ1人あたりのPush数比較（週末を除く）
Pull Requestのレビュー数とIssueへのコメント数も調査したところ、2020年においては3月まで一貫して昨年よりも増加という、同様のパターンが見られました。（Pull Requestのレビュー数やIssueへのコメント数のグラフは本レポートでは省略しています。）
一見、パンデミックがもたらしたリモートワークへの移行における初期段階を通して、開発活動は変わらない、あるいはわずかに増加しているように思われます。ところが、テーマ2で労働時間や就業リズムに注目して詳しく調査したところ、開発者がこれらの活動レベルをどのようにして達成しているのかという、さらなる知見が得られました。
ユーザ1人あたりのIssueへのコメント数の変動は、作業の分散化を反映
開発活動について、ユーザ1人あたりのGitHub Issueへのコメント数からも調査を行いました。2020年を通して、1日のGitHubユーザ1人あたりのIssueコメント数は、2019年とほぼ同等、あるいはそれ以下でしたが、2月には大きく減少しています。グラフの矢印が示すように、この傾向には3月中旬から変化が現れ、3月下旬まで続いています。こちらのグラフでも、週末は除外しています。
グラフ：アクティブユーザ1人あたりのIssueへのコメント数比較（週末を除く）
この変化について追加調査を行ったところ、同時期にすべてのリポジトリでIssueへのコメント数が増加していました。最も大きく増加したのは、無料ユーザと有料のTeamアカウントが所有するリポジトリでした。下のグラフは、Issueへのコメント数の前年との変化をリポジトリごとに示したものです（週末を除く）。
グラフ：リポジトリ所有者タイプ別のアクティブユーザ1人あたりの対前年比Issueコメント増加率（%）
この比較グラフを見ると、GitHub Enterprise Cloudアカウントが所有するリポジトリにおける2020年3月までの活動データから、興味深い洞察が得られます。Issueへのコメント数について、注目すべきは二つの傾向があることです。まず、2月中旬にかけて、Issueへのコメント数が著しく減少しています（グラフ内の矢印A）。これは、アジアとヨーロッパでCOVID-19が拡大し、北米西海岸がリモートワークに移行し始めた時期と一致しています。2月下旬から3月上旬には、昨年の活動レベルに戻り、GitHub Enterprise Cloudアカウントが所有するリポジトリの活動は、やはり週末に落ち込んでいます。このような週末における活動の落ち込みは、無料アカウントや有料のTeamアカウントが所有するリポジトリには見られません。これらのリポジトリには、オープンソースプロジェクト作業がホストされている可能性が高いことを踏まえると、これは当然の結果かもしれません。次に、無料アカウントや有料のTeamアカウントが所有するリポジトリほど急激ではないものの、Issueへのコメント数が昨年のレベルを超えている時期があります（グラフ内の矢印B）。これは、開発者がリモートワークに適応し、企業のソフトウェア開発関連活動が再開されたことを示している可能性があります。
なぜ、GitHub Enterprise CloudアカウントでIssueへのコメント数が大きく変動しているのでしょうか。GitHub Issueの使われ方を理解すれば、その答えが分かるかもしれません。Issueは、コミュニケーションやプラニングの場所として使われています。Issueへのコメント数は、タスク、機能強化、機能、バグを管理するユーザの数を表します。個人的な開発や趣味の開発では、わざわざプラニングを行わないでしょう（少なくとも、Issueとして記録せず、ポストイットにメモして貼っておく程度だと思います）。ところが、企業が開発を行う場合、遥かにしっかりとした構造化や調整が必要となるため、プラニングするプロジェクトや機能も大型かつ複雑で、チーム内のコミュニケーションが必要とされることが一般的です。そうした調整がIssueという機能を使ってで進められるため、作業形式の変化や混乱による影響を受けやすい傾向があります。
ここで見たIssueへのコメント数の大きな変動は、ソフトウェア開発を取り巻く既存のプラニングプロセスに混乱が生じたり、リモートワークへ移行したことでほぼ強制的に初めてチームが分散されたりした結果かもしれません。つまり、以下のようなシナリオが考えられます。
-
- チームメンバーがリモートワークに急転換し、（Issueに記録された）タスクを追加するための会議が停滞した。Issue数が変化しない。
- 開発者はリモートワークに切り替えながら、Issueに登録済みの問題を継続的に処理した。Issue数が徐々に減少。
- 分散した環境下で、チームメンバーが、アドホック会議、分散型のカンバンボード、スタンドアップなど、新たな手法を覚えた。Issue数は変化しないか、徐々に増加。
- チームメンバーがリモートワークに適応したか、対応すべきIssue項目がなくなったため、Issueに今後のタスクを追加することで、急いで開発の管理やプラニングを再開し、再び今後の作業をIssueにまとめる構造や可能性に順応した。Issue数が急増。
このように、比較的早い段階でIssueを通したコミュニケーション量が元の状況に回復したのは喜ばしいことです。2月の急激な落ち込みからの最初のリバウンドかもしれません。仕事上の新たなニーズや条件に適応する際の煩雑性や、全般的に経済が不透明で、外出制限令が延長されたことを踏まえると、今年の夏を終えるまで、この変動は続くことが予想されます。
テーマ2：就業リズム
活動パターンに注目しても、開発者の1日について全容を把握することはできません。COVID-19が開発者に与えている影響を詳しく理解するため、労働状況の変化についても調査しました。
日常的に自宅で仕事をする人の労働時間は、1週間あたり最大1～2日は8時間よりも長い傾向があります（Hill et al. 2010）。プライベート時間にも仕事をするようになり、仕事とプライベートの境界が曖昧になることが原因と考えられます。突如、リモートワークに移行となりましたが、増加した労働時間にもパターンがあるのでしょうか。
テーマ2：データ
本セクションでは、以下の条件を満たす有料の企業/ 官公庁/教育向けアカウントを分析しました。
- 2019年1月1日以前にアカウントが作成された
- 2020年3月まで、毎月アクティブであった
- 有料のTeamまたはGitHub Enterprise Cloudアカウントを使用している
40,000以上の組織を分析しました。下図のとおり、北米の組織が最も多く（40%）、次いで、ヨーロッパ（35%）、アジア（17%）が大きな割合を占めています。
所見
リポジトリのデフォルトのブランチにgit pushコマンドが最初に実行されてから、最後に実行されるまでの時間を1日の労働時間と見なしました。これは大まかな労働時間であり、1就業日の始業から終業までを示す一つの見方です。
この分析では、米国の二つのタイムゾーン（西海岸と東海岸）に絞り、労働時間と作業量を調査しました。米国中部とは異なり、米国の東海岸と西海岸では、かなり周到な外出制限令が発動されたため、その影響がデータに現れる可能性が高く、またサンプル数が充分にあり、一握りの組織による過剰な影響も回避できることから、これらの二つのタイムゾーンを調査対象に選択しました。
労働時間と作業量：米国西海岸
まず、米国西海岸ユーザの就業リズムに注目しました。この分析から、労働時間が昨年よりもばらつきが大きくなった後、3月中旬から大幅に増加（1日あたり30～60分程度）していることが分かりました。特に週末に労働時間が増加しています。
グラフ：米国西海岸ユーザによる最初のPushから最後のPushまでの対昨年比平均時間変化（週末を含む）
この分析を補足するため、同じ期間に開発者が行った作業量も併せて調査しました。これにより、同量の作業を行う時間が延びているのかどうかが確認できます。つまり、開発者は家事や子供の世話のために仕事を小分けにしており、1日の労働時間は延びたものの、行っている作業量は以前とほぼ同じであるということも考えられます（例えば、12時間の間に3時間の作業を3回に分けて行った場合、この分析の基準ではその日の労働時間が12時間と見なされますが、実際には作業スケジュールを延長しない、8時間労働プラス1時間のランチ休憩を取る一般的な9時間労働と同じことになります）。そのため、行った作業量の大まかな指標として、就業時間内にコードをPushした回数も調査しました。これを作業量とします。
米国西海岸のユーザの作業量は、一貫して昨年よりも増えていることが分かりました。特に3月を中心に、米国西海岸ユーザは、労働時間と開発作業量の両方が増加していることをこの分析は示しています。これは、普段オフィスに通勤していた開発者が、リモートワークに切り替え、浮いた時間を「埋め合わせ」している影響かもしれません。浮いた時間は家事と仕事の両方に使えるものの、開発者はPush頻度を上げなければならないというプレッシャーを感じているため、このような作業量の増加が確認されたのかもしれません。経済の不透明性から解雇されないように業務を全うしたいという気持ち、自宅から出られない暇な時間を仕事で紛らわしている、製品発売に向けた経営陣からのプレッシャー、迅速かつ安定したソフトウェアデリバリーを維持するために頻繁にPushすべきというチームのノルマなどが、このプレッシャーの理由と考えられます。
グラフ：米国西海岸ユーザによる対昨年比平均Push回数の変化（週末を含む）
労働時間と作業量：米国東海岸
次に、米国東海岸を分析したところ、2020年のほぼ全期間を通して労働時間は減少し、その後3月中旬から西海岸のユーザと同様に増加していることが分かりました（ただし、増加幅は西海岸よりも少ない15～30分程度）。こちらも、労働時間の増加は主に週末に見られます。
グラフ：米国東海岸ユーザによる最初のPushから最後のPushまでの対昨年比平均時間変化（週末を含む）
この労働時間に伴う作業量で見ると、Push回数はいったん上昇した後、2月以降、減少傾向に入りました。特に、この傾向が外出制限令の発動時期と一致していることから、米国東海岸ユーザは作業の分散化をさらに進めていると推測できます。
グラフ：米国東海岸ユーザによる対昨年比平均Push回数の変化（週末を含む）
バーンアウト（燃え尽き症候群）
分析から、開発者の開発量は変わっていないか、あるいは、増加しているいることが分かります。このような不透明な時期であっても、生産性が保たれている証拠として喜ぶ方もいるかもしれませんが、就業リズムに関する分析も踏まえ、開発者、リーダー、組織は、バーンアウトを防ぐための対策を講じ、チームメンバーや同僚がバーンアウトを起こさないように警戒するべきです。
世界保健機関（WHO）は、「慢性的な職場ストレスが適切に管理されないことで生じる職業病」としてバーンアウトを認めました。バーンアウトは、職場でのストレスを指して使われる言葉ですが、仕事がプライベート空間に侵入している現在、これを管理することは難しいかもしれません。
心の健康のためには、職場だけでなく、プライベート生活でもバーンアウトに対処することが重要です。チームやリーダーが柔軟で持続可能な就業スケジュールをサポートし、バーンアウトを警戒していれば、その下で働くメンバーの幸福度や生産性は上がります。これは全員に関係する問題であることを忘れないでください。
バーンアウトやその対策の詳細については、職場のバーンアウトに関する専門家であるChristina Maslach博士の記事「Understanding Job Burnout （職場のバーンアウトについて理解する）」をご覧ください。ラスベガスで開催されたDevOps Enterprise Summit 2018でのMaslach博士の講演もご視聴いただけます。
テーマ3：共同作業
テレビや映画では、開発者の仕事が孤独な活動として描かれていることが多いようです。しかし、本来のソフトウェア開発とは、互いに協力し合って作業を行うもので、すべての読者の方に、誤解がないようにお願いしたい点です。自分ひとりで問題を解決することも楽しく、やり甲斐も感じられますが、チームやコミュニティで一緒に何かを作り上げる作業には、特別なものがあります。
リモートワークへの移行は、仕事の在り方を大きく変化させました。コミュニケーションや調整する方法の形式が変わり、アーティファクトも、対面式のホワイトボードやポストイットといった以前から使われているアナログ手段をデジタルで再現したものや、まったく新しいテクノロジーが用いられるように変化してきました。
最後のセクションでは、ソフトウェア開発における協力について洞察をお伝えします。
所見 テーマ3：Pull Request分析のデータ
本セクションでは、以下の条件を満たす有料の企業/ 官公庁/教育向けアカウントを分析しました。
- 2019年1月1日以前にアカウントが作成された
- 2020年3月まで、毎月アクティブであった
- 有料のTeamまたはGitHub Enterprise Cloudアカウントを使用している
上記の条件に当てはまる40,000以上の組織を分析しました。注：これはテーマ2と同じ対象データです。
Pull Requestのマージ時間
Pull Requestは、開発者がリポジトリに行った変更を他者に伝える手段です。Pull Requestのマージには、関係開発者グループによる変更の検討と、修正に関する議論、時にはコミットを介した追加作業が必要とされます。その後、Pull Requestは、該当のリポジトリの適切なブランチにマージされます。このような完全協働型のプロセスを測れる指標を利用し、昨年からの変化を確認するため、Pull Requestのマージ時間を測定しました。
テーマ1：生産性と活動では、ユーザ1人あたりのPull Request数は、昨年とほぼ同じ、あるいは増加していることを確認しました。ところが、Pull Request関連のユーザ行動には変化が見られます。1月、GitHub Enterprise Cloudアカウントが所有するリポジトリにおけるマージ時間は、昨年に対して4～5時間も増加し、有料のTeamアカウントが所有するリポジトリでは、約1時間の増加が見られました。年初に出現したこのPull Requestのマージ時間の増加という傾向は、非常に興味深い知見ではありますが、その理由は定かではありません。
3月、Pull Requestのマージ時間の平均値に減少が見られます。GitHub Enterprise Cloudアカウントが所有するリポジトリについては、Pull Requestのマージ時間が昨年に対して15～30分の増加（1月から3時間以上改善）、有料のTeamアカウントが所有するリポジトリでは、マージ時間が昨年と同レベルになりました（1月から約1時間改善）。このような1月以降のマージ時間の減少（特に、多くの地域で外出制限が発令された3月）は、オンラインでPull Requestをすぐに検討できるようになった、集中できる時間が増えた、自宅にいるためPull Requestに対応し易くなったなど、オンライン時間が増えた影響が現れているのかもしれません。
グラフ：有料アカウントによるPull Requestのマージ時間の対前年比変化（週ごとの平均）
テーマ3：オープンソースの分析データ
本サブセクションの分析では、GitHubプラットフォーム上でのオープンソースソフトウェアに関わる活動として取得したデータを使用しました。2019年1月1日から2020年3月31日までのデータを対象に、昨年のデータとの比較分析を行いました。
オープンソースプロジェクトのコントリビューター
オープンソースプロジェクトのリポジトリにおけるPull Requestのマージ時間に対して追加分析を行ったところ、年初のマージ時間が、昨年よりも数時間長いことが分かりました。一方で、3月のマージ時間は、昨年に対して45分から4時間近く短くなりました。これは、特に3月に開発者が自宅で行えるプロジェクトを見つけるケースが増加したため、オープンソースプロジェクトへの参加人数が増え、反応が良くなったことが理由とも考えられます。
グラフ：オープンソースプロジェクトにおけるPull Requestのマージ時間の対前年比変化（週ごとの平均）
このようにオープンソースコミュニティへの貢献や交流が増えたことは、非常に喜ばしいことであるため、詳しく調査しました。
オープンソースプロジェクトの生成状況を分析したところ、今年は継続して増加しています。今年の3月下旬までにオープンソースプロジェクトが生成したリポジトリ数は、前年比で 27.62% 増加しました。注：下のグラフには週末が含まれています。
グラフ：オープンソースプロジェクト生成率の対前年比変化（週末を含む）
有力な公開プロジェクトを分析したところ、Pull Requestのマージ時間のデータと同様に、3月中旬に共同作業が急増しています（コントリビューションを行うコントリビューター別に測定）。
グラフ：2020年にコントリビューターが大幅に増加したオープンソースプロジェクトの一部
Jitsi
Jitsiは、音声の完全暗号化（VoIP）、ビデオ会議、インスタントメッセージを提供している無料オープンソースプロジェクト群です。Jitsi Videobridge（マルチパーティー音声通話）やJitsi Meet（ウェブ、Android、iOSでの完全ビデオ会議）などがあります。
jitsi.orgによると、これらのプロジェクトは、2003年に学生プロジェクトとして立ち上がり、2011年に音声と動画に対応後、ブルガリア語で電線を意味する「жици」からJitsiに改名されました。2020年、Jitsiの平均マンスリーユーザ数は、1千万人を超えました。
COVID-19関連の公開プロジェクトにおいても、コミュニティは素晴らしく活発な活動を見せています。その活動は1月に勢いを増し、3月中旬にも同様にコントリビューター数が急増しています。
グラフ：2020年にコントリビューター数が著しく増加したCOVID-19関連の公開オープンソースプロジェクトの一部
注記：分析データについて
背景：GitHubプラットフォーム
全体的に、GitHubのアクティブユーザ数は、昨年よりも増加しました。2019年からの増加は、COVID-19拡大後も、2020年3月までを通して概ね一貫しています。前年比での増加率は昨年と同等レベルですが、全般的な経済状況や経済不安を踏まえると、著しい成長と言えるかもしれません。機密情報であるため、これらの数字を開示することはできませんが、昨年からの傾向をご覧いただけるグラフを提供します。定期的な落ち込みは、グラフ内にグレーの棒線で示される週末と対応しています。
グラフ：1日のアクティブユーザ数の対前年比較（週末を含む）
詳細：データ収集と分析方法
本レポートでは、就業パターンと昨年からの変化に注目しながら、GitHub上のソフトウェア開発活動を分析しました。COVID-19の感染拡大が、世界の就業体制に影響を及ぼし始めた2020年3月までの3ヶ月間を対象としています。比較し易くするため、データを2日分ずらし（年毎のずれを調整するために1日と、閏年を調整するための1日）、1年前のデータと曜日を一致させた上で分析を行いました。今回のレポートでは、対象期間を調査目的に適うように2020年3月までに絞り込み、比較分析を行いました。分析対象時期をより広げることで、より長期的な傾向が見つかる可能性もありますが、一時的な要素や時期的な要素（夏季の活動減少など）を考慮する必要性が生じるため、本レポートを期限内に完成できなくなる可能性があります。今年中に発表予定の年次レポート「State of Octoverse」で、本レポートの分析を拡大させ、今回の所見について再度検討する予定です。今後の分析においてそれらの要素を反映させるかもしれません。
すべてのデータは、集約したうえで報告しています。サンプルの選定方法については、各セクション内で詳述していますが、匿名性を保護するため、実際のデータを提供することはできません。
謝辞
GitHubのデータサイエンティスト、コントリビューター、レビュアーの皆さんに感謝いたします。協力いただいた内容に沿ってアルファベット順に名前を記載させていただきます。
- データサイエンティスト： Greg Ceccarelli、Anna Filippova、Taylor Holland、Derek Jedamski、Scot Kelly、Rowan Wing
- レビュアー： Martin Fowler、Sam Guckenheimer、Caitie McCaffrey、Rachel Potvin
- コピーエディター：Mandy Campbell、Cheryl Coupe
- デザイナー：Jobey Greenwood、Sabrina Majeed
