Coming Together to Support the Open Source Community

Over the last few weeks, conference and event cancellations around the world have heavily impacted the open source community. These events play an important role in the ecosystem that supports free and open source software. If we want that ecosystem to remain healthy, it is important for us to act now.

Why support matters now more than ever

Conferences and events provide essential opportunities for the open source community to:

  • Coordinate activities
  • Raise funds
  • Grow their user bases
  • Support each other
  • Evangelize their technologies
  • Educate and onboard new contributors
  • Ship new releases
  • Share knowledge

Running these events requires a lot of time, effort, and money. When they are cancelled, the event organizers bear the brunt of the losses. If we want these events to continue—and the open source community to sustain itself and grow—all users of free and open source software must respond.

The FOSS Responders

Open source community leaders from across the industry have come together to form a working group called FOSS Responders. We’re focused on identifying open source events, communities, foundations, and community members who are most in need of support. We also want to support individuals who are unable to absorb conference-related cancellation fees. Our goals: amplify these community needs and mobilize organizational and individual resources to help.

This working group of committed industry professionals includes participants from Indeed, GitLab, Open Collective, the Sustain community, the Drupal Association, and several other organizations. You can find more information about this working group—including information on how to join and participate—at fossresponders.com.

Virtual funding event

Indeed and Open Collective are collaborating to host a virtual funding event on May 22, 2020. We want to raise funds for conference organizers that have suffered irrecoverable losses due to event cancellations. We are calling on our peers in the industry to join us at this event as fellow FOSS Funders.

By coming together to share knowledge, collaborate on decision making, and coordinate our collective response, we can ensure that these events will continue to serve and support the community in the months and years to come. You can find more information about this event here.

Taking action

Regardless of your need or your capacity to help, the time to act is now. Here are some specific actions you can take.

How to help

Now is the time to give back to the projects we depend on. This is how we future-proof our open source infrastructure investments and help millions who built the software we benefit from:

  • Donate and buy membership to foundations that support your projects
  • Donate to individuals working on projects you use via GitHub Sponsors and Open Collective
  • Donate to the FOSS Responders Open Collective—your funds will be used to help individuals who might otherwise fall through the cracks

How to get help

FOSS Responders will amplify your need so others can easily see who and how to help. By sharing your need, we can connect you with helpers.

  • If you are an individual who needs help paying for conference-related cancellation fees, fill out the FOSS Responders Individual Request
  • If you had to cancel an event and your organization needs financial assistance as a result, open an EVENT issue
  • If you need other kinds of help, open an ORGANIZE issue

How to get involved

The FOSS Responders working group is growing quickly and we could use your help.


Cross-posted on Medium.

Tweet about this on TwitterShare on FacebookShare on LinkedInShare on RedditEmail this to someone

インシデントのレトロスペクティブの改善

この記事は最初に『learningfromincidents.io』に掲載されました。

man standing in front of waterfall with rainbow

Photo by Jared Erondu on Unsplash

Indeed の Site Reliability Engineer (SRE) として、インシデントの後のレトロスペクティブという振り返りの工程に数多く参加しています。Indeed では2015年後半頃から導入されているレトロスペクティブは、我々のエンジニアリングカルチャーの一部になっています。その重要性に疑問を感じたことはありませんでしたが、最近のレトロスペクティブでは次のような傾向が見られるようになり、レトロスペクティブの本来の利点が活かされていないのではないかと思い始めました。

  • 割り当てられた時間の30% 程度しか活用していない。
  • 出席しなくても、インシデントのチケットやレトロスペクティブの議事録などを見れば、内容がわかる。
  • インシデントを「引き起こした」条件に時間が割かれすぎている。
  • レトロスペクティブ開催の要否の判断基準が、影響が大きいものや、ビジビリティの高いインシデントに偏りがちである。
  • 参加者は新しい事を学んでいるのか? インシデントに基づく学びの機会を最大限に活用できていない。

私は、なぜこのように感じたのか、どうしたら改善できるのか考えることにしました。

典型的なレトロスペクティブとは

Indeed のレトロスペクティブは通常1時間で、多い時は70〜80人が参加します。社内の誰でも参加できますが、インシデントのレスポンスに関わった人やインシデントの結果に関心がある人たちが参加することが多いです。

ファシリテーターは次のような、あらかじめ決められた手順に従ってレトロスペクティブを進行させます。

  1. タイムラインの振り返り
  2. テンプレート内の改善項目の確認
  3. 改善項目の担当者の決定
  4. 質疑応答

改善点

2018年の夏、Indeed のテックオフィスでレトロスペクティブに数回参加し、最近のインシデントについて話し合いました。私は SRE なので、レトロスペクティブに参加するのは珍しいことではありませんし、当該インシデントに関するテクノロジーは、私の専門分野でした。

ファシリテーターは5分ほどタイムラインに触れ、8 〜10分かけて改善項目を確認し、インシデントの原因と結果に関わるテクノロジーについての質疑応答でレトロスペクティブを終えました。新たな学びはありませんでした。インシデントのチケット、レトロスペクティブの議事録やスライドを見れば同じ情報を得ることができました。総力を結集して問題に立ち向かおう、という意欲を持った熱心なメンバーが1つの会議室に集まるという滅多にない機会でしたが、そのチャンスを最大限に活かすことはできませんでした。

どのレトロスペクティブもこうだと言うわけではありません。出席者が詳細な情報を提供し、議論が1時間というタイムリミットを越え、最後には会議室の外で身を寄せ合って話し続けるようなレトロスペクティブに参加したこともあります。

先ほどのファシリテーターは、レトロスペクティブをきちんと進行させてはいましたが、時間を30%程度しか活用できていませんでした。レトロスペクティブのやり方そのものに改善が必要なことは、明らかでした。

セーフティカルチャーを育てる

改善点を把握するため、レトロスペクティブを行う理由を聞くことから始めました。集まった主な意見は次のとおりで、ソフトウェア開発に携わる人たちには馴染みのあるものだと思います。

  • アウテージの原因を解明するため
  • 影響の大きさを測定するため
  • アウテージの再発防止を徹底するため
  • 改善項目をリストアップし、担当者を決めるため

これらの意見には、Indeed 社員の強い当事者意識が表れています。あるサービスがインシデントに関係していた場合、そのチームは、自分たちが思っていた以上に障害発生が近かったのかもしれないという懸念を持ちます。優先順位を一時的に変更し、チームのメンバーはプロセスや設計の選択肢をより注意深く検討するようになります。

重要なのは、このような機会を活用して Indeed のシステム (人とテクノロジーの両方) と立てた推測をより詳しく分析するように労力をシフトさせることです。これまでとは異なる Indeed 社内でのセーフティカルチャーへのこのようなアプローチはまだ比較的新しく、広がりを見せ始めている段階です。

提案: 改善をレトロスペクティブから切り離す

私は、改善項目の作成プロセスの変更を提案しました。レトロスペクティブは、改善項目のリストアップと担当者の決定を促すための会議ではありません。

プロダクション環境が安定してから改善項目のピックアップが行われるのを日々目にしますが、インシデント発生後には、たくさんの修正が必要になってきます。

「発生後」のアクティビティをレトロスペクティブから切り離すべきだと考える理由は一つではありません。

  • 改善項目のピックアップは、暗黙の停止地点となり、それ以降のより詳しい調査を止めてしまう。
  • 改善項目の担当者決定の責任は、インシデントの担当者と確実に結びつけられるべき。
  • レトロスペクティブは、任意のアクティビティとすべき。担当チームは、義務だから、チェックリストにあるから、ではなく、参加する価値があるかどうかで参加を決定する。
  • 参加者は、改善項目のピックアップや浅薄な説明といった負担から解放され、より深い調査ができるようになる。

提案: テンプレートの柔軟性を高める

レトロスペクティブ用のテンプレートの変更は有益でした。

レトロスペクティブ用のテンプレートを使用すると、空欄に情報を入力するだけの作業になってしまいます。自由な議論ではなく、アクティビティを完結させることに焦点が向けられてしまいます。テンプレートではなく、何も書かれていない白紙のドキュメントを使用すると、別の形での共有が始まります。白紙のドキュメントに変えただけで回答者のモチベーションが高まり、自分の意見や説明を共有し、詳細な分析を書いてくれたことが何度かありました。

もし、インシデントが雪の結晶のような形をしていたら、インシデントごとの特徴を捉えられるテンプレートを作成するのは不可能です。テンプレートを使用すると、詳しく説明しようとした時に制約が出てしまい、回答選択式の質問を使用した説明になってしまいます。白紙というキャンバスであれば、自由に答えられます。テンプレートは、深い分析の妨げになる、もうひとつの暗黙の停止地点なのです。インシデント分析にテンプレートを応用するのはおすすめですが、レトロスペクティブでは白紙のドキュメントをおすすめします。

組織的な変化を促す

急成長を続ける Indeed では、変化を促すことで、多くのことを学んできました。社内での経歴や、何百というインシデントに立ち会った経験、そのドキュメントとの関わりなどが、自分の取り組みに役立ちました。前進はしていますが、まだまだやることがあります。

ここまでの前進は、社内で賛同者を見つけ、連絡を取り続けてきたから実現できたと思っています。

賛同者を見つける

賛同者は、同じ目標を持っている同僚たちで、改善できる点を指摘してくれ、どう改善できるかというビジョンを共有してくれます。こうした賛同者を見つけるのにはまったく苦労しませんでした。同僚たちは、熱心に話を聞いてくれ、自分とは異なる視点を受け入れられる広い心と忍耐強さを持っています。組織内のリーダーや関係者とも何度も1対1で話し合いましたし、ミーティングでもこのようなトピックを提案する機会がありました。世界各地の Indeed のテックオフィスに行くときは、テックトークを行い、潜在的な賛同者に働きかけてきました。

何度も伝える

自分が取り組んでいることをしっかり伝えられていると自分では思っていましたが、十分には伝わっていませんでした。何度も何度も伝える必要があるのだと気づきました。複数の方法でくり返し伝えてきたので、私の身近にいた人たちは、同じことばかり、何度も言っているなと思ったでしょう。しかし、こうでもしないと私の話が耳に入らないような、社内でも遠く離れた誰かには伝わりませんでした。メールや社内ブログにすべて目を通す時間がある人ばかりではないからです。

先を見据える

こうした変更への反応は、おおむね好意的です。レトロスペクティブでの焦点は、人的要素に注目すべき場合でも、やはり技術的な要素に向けられています。こうした取り組みをさらに多くの人たちに広めて効果をあげるために、さまざまな方法を検討しています。これには、Instructional Design チームと連携したデブリーフのファシリテータープログラムの作成、より頻繁に幅広くコミュニケーションを取ること、さらなるプロセスの変更、継続したチームの生産性向上の支援と質の高いドキュメントの共有、教育の機会の提供などがあります。現時点では、この取り組みはまだ始まったばかりですが、成果が楽しみです。


投稿者の紹介

Alex Elman は、Indeed の Site Reliability Engineering (SRE) チームの創立メンバーです。現在は、Resilience Engineering チームと、Job Search という Indeed の主要プロダクトのチームのリーダーです。過去8年間にわたり、複雑さを増しつづけるシステムの拡張に対応するために、信頼性の施策の導入支援を行っています。Alex を Twitter でぜひフォローしてみてください。 @_pkill.

Tweet about this on TwitterShare on FacebookShare on LinkedInShare on RedditEmail this to someone

d 曲線: 第一種過誤と第二種過誤を用いて契約のないチャーンを定義する手法の改善

事業者は、顧客が取引関係をいつ終わらせるのか、つまり「チャーン」という離脱行為がいつなされるのかを知る必要があります。サブスクリプションビジネスモデルでは、顧客は契約を能動的に解約することで取引関係から離脱します。したがって、企業はこのチャーンを確実に検知して記録することができます。しかし、明示的契約が存在しない場合、チャーンはむしろ受動的であり、検知することが困難です。顧客から直接何らかのフィードバックがなければ、企業は、その顧客が取引関係から一時的に離れているのか永久的に離れたのかを判断することができません。

これまでは、そういった契約のない取引関係のチャーンの検知は、ほとんど恣意的なものであり、科学的というよりも感覚的なものでした。

さまざまなアナリストが、あらゆる方法で、契約のないチャーンの難問に取り組んでいます。ある一般的なアプローチでは、顧客が十分に長い連続した期間にわたり取引を行わない場合に、その顧客が離脱したものと推定します。このアプローチの問題点は、それが根拠のない推測であることに加え、チャーンと判定するまでの期間の長さのしきい値を高くし過ぎることが多いという点です。これでは、事業者が相当長く待たなければチャーンの問題を識別できないことになります。『Prediction of Advertiser Churn for Google Adwords』では、著者は12か月後までチャーンを測定できないのです。そのように長期間待っていたのでは、チャーンを検知する意味は薄くなり、事業者が問題に対処する能力も下がります。チャーン判定期間を購入サイクル (顧客の購入から次の購入までの期間) の分布における特定のパーセンタイルとして推定する分析で、最適なパーセンタイル (90番目、95番目、99番目等) を選択することは困難です。

このブログでは、契約のないチャーンを定義するための、科学的なアプローチを紹介します。このアプローチでは、第一種過誤と第二種過誤を良定義の目的関数で最小化することにより、苦労して最適なパーセンタイルを選択する手間を回避できます。

理論

チャーン判定期間 (d) とは、これを超えると顧客との取引関係が終了したと考えられる、連続した沈黙 (取引のない) 期間の最小値です。企業は一般的に、顧客をアクティブ顧客とチャーン顧客とに分けます。顧客との取引関係が契約に依存しない場合、特定の d には、第一種過誤および第二種過誤があります。したがって、これらの過誤の目的関数を最小化する定義を選択しなければなりません。このアプローチでは、関数を過誤の加重平均であると規定します。

ここでの定義は次のようになります。

  • e1(d) は、チャーン定義 d に関連して予想される第一種過誤です。この場合の第一種過誤とは、アクティブな顧客をチャーン顧客に分類することです。
  • e2(d) は、チャーン定義 d に関連して予想される第二種過誤です。この場合の第二種過誤とは、チャーン顧客をアクティブ顧客に分類することです。
  • w は、第二種過誤との関係でアナリストにより第一種過誤に設定された加重です。これは過誤の相対コストと解釈できます。

したがって、最適なチャーン定義 (d* で表す) で、F(d) が最小になります。この F(d) を d 曲線と呼びます。

誤差関数 e1(d) と e2(d) を計算するため、別の一連の表記法を紹介する必要があります。

  • ci は、顧客 i の実際の離脱状況を表すもので、0はアクティブ、1はチャーンの状態を意味します。
  • li は、顧客 i が取引を止めていた連続期間の数を表します。

上記の定義を使用すると、e1(d) と e2(d) は次のように導き出されます。

(2) と (3) から、e1(d) は誤ってチャーン顧客に分類されたアクティブ顧客の全体的な割合であることがわかります。同様に、e2(d) は誤ってアクティブ顧客に分類されたチャーン顧客の全体的な割合です。

理論の実装

ある時点 S から時点 T までの、すべての顧客取引に関する期間を記録したデータがあるとします。

最適なチャーン定義を判断するため、次の実験を行います。

  1. これを超えるとチャーン顧客だと判定できる最小の期間 D を定義します。これは、顧客の購入サイクルの分布 (連続する顧客取引日の期間の差) を調査し、十分高いパーセンタイルを選択することで可能です。ここでは、D を検証期間と呼ぶことにします。つまり、調査の対象が T-D より前に少なくとも1件の取引があった顧客に限定されなければ、顧客の本当の離脱状況 ci を算出することはできません。また、データ全体の長さ (T-S) は、d 曲線 F(d) の選択したチャーン定義の範囲を評価できる程度に、十分に長い必要があります。たとえば、範囲を {d:d<K+1) とする場合、T-S は K+D を超えていなければなりません。
  2. 自発的なチャーンのみに注目したい場合は、企業により非自発的に終了させられたその他すべての顧客を除去します。
  3. 各顧客 i について、時点 T における最終購入期間を確定します。

    時点 T における休眠期間を算出します。

    それから、本当の離脱状態を算出します。
  4. 各顧客 i について、時点 T-D における最終購入期間を確定します。
    時点 T-D における休眠期間を算出します。
  5. チャーン定義の範囲 {d:dK}、つまり、F(d) を最小化したい範囲を選択します。
  6. 選択した範囲の各チャーン定義 d =0, 1, 2…K について、時点 T-D における各顧客の離脱状態を予測し、第一種過誤 e1(d) と第二種過誤 e2(d) を測定します。データから、 e1(d) と e2(d) は次のように計算できることがわかります。
  7. 適切な加重 w を選択します。
  8. d=0, 1, 2, …K は、(1) を使用して F(d) となります。
  9. F(d) が最小になる d を、最適な d として選択します。

実世界に応用した結果

Indeed の契約のないサービスの1つとして有料のオプション (スポンサー求人) を識別し、パーセンタイル手法と d 曲線手法の両方を用いてチャーン判定期間を定めました。2016年9月 (S) から2019年9月 (T) までの月間取引データを使用しました。

ただし、公開するトレンドとインサイトは実際の調査結果に沿うものですが、Indeed のデータのセキュリティを保護するため、実際の結果を調整したものを示していますので留意してください。

パーセンタイル手法

このアプローチで、各顧客の購入サイクルを算出します。その結果、各顧客の購入サイクルの要約統計量 (平均値、中央値、および最大値) で各顧客を示すことができます。その後、別々の顧客に対して要約統計量の分布を作成します。

分位数 平均値 中央値 最大値
0 1 1 1
0.2 2 2 2
0.4 2 2 2
0.6 3.5 3 5
0.8 4.7 3 9
0.9 6.2 5 13
0.95 8 7 17
0.99 15 15 25
1 38 38 38
すべて説明用の数値

 

これらの結果は、パーセンタイル手法に関連する分析のジレンマを例証するものです。分布は要約統計量の選択次第で変わります。一定の要約統計量を使用したとしても、どのパーセンタイル (90番目、95番目、または99番目) が最適なのかは明らかになりません。それとは別に、いずれのパーセンタイルを選択する場合でも、不必要に高いチャーン定義となります。たとえば、平均購入サイクルの分布の95パーセンタイルは8か月である一方、最大購入サイクルの分布では、なんと同じパーセンタイルが17か月にもなります。次のアプローチで、そのように定義が長くなるほど第一種過誤が減少する一方、第二種過誤が増大することを確認していきましょう。

d 曲線アプローチでは、第一種および第二種過誤の加重合計の最小値を用いてチャーン定義を選択することにより、これらの問題のすべてに対処します。

d 曲線アプローチ

このモデルを次のようにパラメーター化しました。

  • w=0.5
  • D=12
  • S= 09-2016
  • K=12
  • T=09-2019
  • T-D=09-2018
チャーン判定期間 第一種過誤 (%) 第二種過誤 (%) 過誤の加重平均 (%)
0 100.0 0.0 50.0
1 43.8 6.4 25.1
2 33.0 13.1 23.1
3 26.6 19.0 22.8
4 21.9 24.8 23.3
5 17.8 30.8 24.3
6 14.7 36.8 25.7
7 12.2 42.4 27.3
8 10.4 46.7 28.6
9 8.9 50.8 29.9
10 8.0 54.1 31.0
11 6.9 58.2 32.5
12 5.8 62.6 34.2

d 曲線を使用して、最適なチャーン定義として3か月を選択します。有意水準1%での仮説検定は、d=3の過誤は d=4の過誤に等しいとする帰無仮説を棄却します。

d 曲線のさらなる応用

しきい値を最適に選択できるよう、フレームワークを公式化しました。このアプローチは、契約のない取引関係のチャーン判定期間を定義するために適用できると同時に、代表的なものとしては分類におけるしきい値確率の決定など、その他の実世界での応用が数多くなされています。

謝辞

レビューと優れたフィードバックを寄せてくれた Trey Causey、Ehsan Fakharizadi、ならびに Yaoyi Chen に深く感謝します。この記事の内容に間違いがあった場合は、筆者である Gyasi Dapaa と Adesewa Adegoke にお知らせください。

Tweet about this on TwitterShare on FacebookShare on LinkedInShare on RedditEmail this to someone