GitHubの草，なぜ「連続記録」をやめたのか

配信ステータス：未配信 配信URL：（配信済みになったら記入）

台本

オープニング

【ジングル】 はい，どうもこんにちは．「雨宿りとWEBの小噺」始まりました．Keethこと桑原です．

この番組では，Webテクノロジーの歴史や裏側にある，ちょっとした小噺をご紹介しております．

今回のお題は「GitHubの草，なぜ『連続記録』をやめたのか」です．

本題

GitHubのプロフィールページを開くと，緑色の小さいマス目がびっしり並んだ表が出てきますよね．一年分の活動量を，マスの色の濃さで見せてくれるやつです．日本のエンジニアは，あれを「草」と呼んでいます．「今日も草を生やした」とか，「最近ちょっと草が枯れてる」とか，そういう言い方をしますよね．正式な名前はContributions Calendar，日本語にすると貢献カレンダーです．コントリビューショングラフと呼ぶ人もいます．

自分の草をなんとなく眺めたことがある人は，かなり多いと思います．濃い緑がずらっと続いていると気分がいいですし，逆に真っ白な期間があると，別に誰に怒られるわけでもないのに，ちょっと後ろめたい．あの感覚，けっこう共通体験なんじゃないかと思います．

で，今日の入口なんですけど．あの草，昔は今より機能が一個多かったんですよ．グラフのすぐ下に，数字が二つ表示されていました．一つが「今，何日連続でコミットしているか」．もう一つが「これまでの最長記録は何日か」．英語だとcurrent streakとlongest streakですね．streakというのは連続記録という意味です．

今のGitHubには，これ無いんですよ．どこを探しても出てきません．消えました．しかも自然消滅とか，リニューアルのついでに紛れて無くなった，という話でもなくて，GitHubが明確に自分の意思で，機能ごと削除しています．

一度出した数字って，普通は消しにくいと思うんですよ．みんなが見てるし，盛り上がってるし，指標としてわかりやすいですから．それでもGitHubは消しました．で，この消した理由が，僕は調べていて完全に予想を外しました．技術的な都合でもないですし，誰も使ってなかったからでもない．全然そういう話じゃないんです．今日はそこに向かって話していきます．

まず，そもそも草がいつ生まれたのかというところからいきます．

草の誕生日は2013年1月7日です．GitHubの公式ブログに「Introducing Contributions」，コントリビューション機能のご紹介，という記事が出ました．このとき発表されたのは草だけじゃなくて，プロフィールページ全体のリニューアルなんですよ．よく使われているリポジトリの一覧，自分が貢献したリポジトリの一覧，直近の活動のフィード，そしてその一部として，あの一年分のマス目のカレンダーが入っていました．

2013年のGitHubがどういう状況だったかというと，創業が2008年なので，まだ5年目くらいです．前の年の2012年に大型の資金調達をして，一気に有名になっていった時期ですね．エンジニアが自分の仕事を外から見える場所に置く，という文化が本格的に広まりはじめた頃です．そのタイミングで「あなたが一年間に何をしたか」を一枚の絵にする機能が出てきた，という順番です．

ここで面白いのが，発表記事に書かれていた使い方なんですよ．GitHubの社員が自分のカレンダーに注釈を書き込んで遊んでいた，という話が紹介されています．しかも何を書き込んでいたかというと，リリースした日，休暇を取った日，登壇した日，そして卒業した日です．出荷とバケーションと登壇と卒業ですよ．仕事の記録だけじゃなくて，完全に人生の記録として扱ってるんですよね．記事にはティム・クレムさんという社員の方の，注釈だらけのカレンダーの画像まで載っています．

つまり最初の草は，「頑張り度合いを測る計測器」じゃなくて，「一年を振り返るアルバム」として作られていたわけです．ここ，今日の話でけっこう大事なところなので，頭の片隅に置いておいてください．作った側の気分としては，年賀状に添える一年の写真みたいなノリだったんだと思います．

ちなみに日本語の「草」という呼び名なんですけど，これは英語圏にはあまり無い言い方です．英語だと普通にcontribution graphとか，green squares，緑のマス，と呼ばれます．日本だとマス目の緑が芝生っぽく見えることと，「草」という言葉自体がネットスラングとしてもともと馴染みがあったことが重なって，「草を生やす」という言い方が定着したと言われています．技術用語ってだいたい英語がそのまま入ってくるものですけど，これはローカルで名前が付き直した珍しい例だと思います．

さて，この草に，先ほど言った連続記録の数字がくっついていました．今日で何日連続，最長記録は何日．これがですね，予想以上に人の心に火をつけてしまうんですよ．

ここから今日の本題です．

草の連続記録がなぜあれほど盛り上がったのかというと，実は下地になった文化があるんです．

2014年4月10日，ジョン・レシグさんという方がブログを書きます．ご存じの方も多いと思いますが，jQueryの作者です．JavaScriptのライブラリで，一時期は世界中のWebサイトが軒並みこれで動いていた，あのjQueryですね．当時はカーンアカデミーという教育系の非営利団体で働いていました．

そのレシグさんが書いた記事のタイトルが「Write Code Every Day」．毎日コードを書け，です．内容は，自分自身を実験台にした習慣づくりの記録でした．ルールが決められていて，これがなかなか厳しいんですよ．

一つ，毎日コードを書く．ドキュメントやブログ記事は，コードを書いたうえでの追加分としてしかカウントしない．二つ，インデントの調整はコードとして認めない．コードの整形もダメ．できる限りリファクタリング，つまり動きを変えずに書き方だけ整える作業も避ける．三つ，コードは日付が変わる前に書き終える．四つ，書いたコードはオープンソースとしてGitHubに上げる．

四つ目，GitHubに上げるってところがポイントですよね．つまり毎日の実践が，そのまま草として可視化されるわけです．記事を書いた時点で，レシグさんは20週近く続けていたと書いています．

で，この「毎日続ける」という発想自体には，さらに元ネタがあります．コメディアンのジェリー・サインフェルドさんが使っていたと言われる方法で，「Don't break the chain」，鎖を断ち切るな，と呼ばれています．やり方はシンプルで，壁のカレンダーに，ネタを書いた日は大きくバツ印を付けていく．バツが並んで鎖みたいに見えてくると，今度はそれを途切れさせたくなくなる．だから続く，という理屈です．

この「鎖を切りたくない」という感覚，わかる人はめちゃくちゃわかると思うんですよ．そしてGitHubの連続記録は，このバツ印を自動で，しかも全世界公開で付けてくれる装置だったわけです．これは効きますよね．

実際，すごい記録を持っていた人がいます．ジェド・ワトソンさんという方で，KeystoneJSというNode.js向けのフレームワークを作った人です．この方の連続記録が，1000日を超えていました．1000日ですよ．3年弱，一日も欠かさずです．しかも本人があとで書いていたところによると，その連続記録はただの数字じゃなくて，KeystoneJSを世に出した日も，娘さんが生まれた日も，全部その中に含まれていた．つまり人生の節目が，全部その鎖の上に乗っかっていたわけです．

もう一人，freeCodeCampというプログラミング学習サービスの創業者，クインシー・ラーソンさんも，このカルチャーのど真ん中にいた人です．2014年10月に，まさにレシグさんの記事に影響を受けて毎日コードを書きはじめて，60日以上続けた．その時期に作っていたのがfreeCodeCampなんですよね．今や世界中の初学者が使っている学習サービスが，「毎日コードを書く」という個人の習慣の副産物として立ち上がっている．これはこれで，かなりいい話だと思います．

こうして2014年から2016年くらいにかけて，連続記録は一種のステータスになっていきました．プロフィールを開けば，その人がどれだけ継続しているかが数字で見える．採用の場面でも「この人は毎日コードを書いている」という証拠として持ち出されるようになっていきます．

ただですね，光が強いと影も濃いわけで，副作用も同時に出てきます．

一つは，中身のないコミットが増えたことです．今日まだコミットしてない，鎖が切れる，というときに，READMEの誤字を一文字直してプッシュする．タイポ修正で草を一マス生やす，というやつですね．これ，やったことある人いるんじゃないでしょうか．連続記録を守るためだけのコミットなので，リポジトリにとっては特に価値がない．

もう一つ，こっちが深刻なんですけど，休みにくくなるんですよ．土日を完全に休むと，その時点で鎖が切れます．旅行に行っても切れる．体調を崩しても切れる．つまり「健康的に休む人ほど，グラフ上は成績が悪く見える」という構造になっていた．

そして採用の場面です．これは当時の海外の掲示板，Hacker Newsという技術者がよく集まる掲示板があるんですけど，そこで実際に語られていた話で，面接で「この数ヶ月，コミットが無いようですが」と詰められた，という体験談が複数出てきます．採用側が「情熱のあるエンジニアが欲しい」「コードを書くことがDNAに刻まれている人が欲しい」というような言い方をしてきた，という話まであります．

草が，一年を振り返るアルバムから，勤怠表になってしまったわけです．

さて，ここからが今日一番話したかったところです．

2016年4月1日，一本のissueが立ちます．issueというのは，GitHub上でバグ報告や要望を書き込む場所ですね．投稿したのは，エリック・ロメインさんというオランダのエンジニアで，GitHub上のハンドルはmxsashaです．セキュリティやオープンソースまわりで活動されている方です．

issueのタイトルが「Contribution graph can be harmful to contributors」．貢献グラフは貢献者にとって有害になりうる，です．同じ日に，自分のブログにも同趣旨の記事を書いています．

まず日付が味わい深いですよね．2016年4月1日，エイプリルフールです．冗談だと思われてもおかしくない日に，かなり真面目な問題提起をしている．

内容はこうです．自分は週末に働かないようにしている．意識的に休みを取っている．それは働き方として健全なはずなのに，そうすると連続記録は絶対に伸びない．長い連続記録を持ちたければ，週末も働くしかない．つまりこのグラフは，休まない人を上位に表示する仕組みになっている，と．

そして，こういう言い方をされています．「休憩を取ることや，一歩下がることを避けるように人を動かす仕組みは，貢献者の健康にとって有害でありうる．そしてそれは，オープンソース全体にとっても有害である」．

ここ，論の運びがすごく良いと思っていて．「僕がしんどいからやめてくれ」という個人の話にしていないんですよね．オープンソースというのは，多くの場合，本業を持っている人が，その外側の時間で支えているものです．そういう人たちが燃え尽きたら，困るのはプロジェクトの側，つまりコミュニティ全体である．だからこれは個人のメンタルの話じゃなくて，エコシステムの持続可能性の話だ，という組み立てになっています．

具体例として挙げていたのが，416日連続という記録を持っている人を見かけた，という話です．416日連続ということは，一年以上，一日も休んでいないということですよね．それを「すごい」で終わらせていいんだっけ，と．この指摘の仕方は，僕はけっこう鋭いと感じました．同じ数字を見て，賞賛と心配のどちらが先に出てくるか，という話なので．

しかも，この人の提案が「グラフを消せ」じゃないんですよ．そこもフェアで，提案としては「休むという行動が正しく評価される形にグラフを組み替えられないか」という方向でした．潰すんじゃなくて設計し直せ，という話をしている．

で，このissueが投稿された場所が，また面白いんです．issueが立ったリポジトリは，isaacs/githubというところなんですけど，これGitHubの公式リポジトリじゃないんですよ．

どういうことかというと，当時のGitHubには，GitHub本体に対して要望を出すための公開の場所が無かったんです．サポートにメールを送ることはできますけど，みんなが見えるところで議論する場所は無かった．そこで，アイザック・シュルーターさんという方，Node.jsのパッケージ管理ツールであるnpmを作った人なんですけど，この方が「自分がGitHubに言いたいことを書き溜めておく場所」として個人のリポジトリを作ったんですね．そうしたら，世界中の開発者が「ここに書けばいいのか」となって，どんどん集まってきてしまった．非公式なのに，事実上のGitHubの要望箱として何年も機能していた，というリポジトリです．ちなみに2021年11月にアーカイブ，つまり読み取り専用として凍結されています．

世界最大のコード共有サービスに対する要望が，一個人のリポジトリに集まっていたというのは，改めて考えると面白い話ですよね．しかも，そこに書かれた声が，ちゃんと本体に届いてしまうわけです．

反応はどうだったかというと，見事に割れました．Hacker Newsでもかなり議論になっていて，「グラフを見てプレッシャーを感じるなら，それは自分の頭の中の問題だ」という冷ややかな意見がかなりありました．「機能を消したところで根っこの心理は変わらない」という指摘もありました．一方で，さっき紹介した「面接で草の空白を詰められた」という体験談が出てきたのもこの議論の中です．あとは折衷案として，「日単位じゃなくて週単位の連続記録にすればいいのでは」という提案も出ていました．それなら週末を休んでも鎖は切れないので，たしかに理屈は通っています．

でも，GitHubが選んだのは折衷案じゃありませんでした．

2016年5月19日，GitHubの公式ブログに「More contributions on your profile」という記事が出ます．プロフィールにもっと多くの貢献を，というタイトルです．

この記事のメインの発表は，実は別の話なんですよ．プライベートリポジトリ，つまり非公開のリポジトリでの作業も，草としてカウントできるようにする，という機能追加です．しかも初期設定ではオフで，オンにしても外から見える形は完全に匿名化される．どのリポジトリで何をしたかは見えず，「この日に活動があった」ということだけが緑になる，という作りです．

これはこれで大きなアップデートでした．仕事のコードはほとんど非公開のリポジトリにある，という人は多いですからね．その人たちの草が真っ白なのは実態と違う，という話です．

で，その発表と同じ記事の中に，一文だけ，こう書いてありました．「このアップデートの一環として，コードの連続記録はコントリビューショングラフに表示されなくなります」．

これだけです．これだけなんですよ．長い説明も，謝罪も，議論の経緯も無い．続く説明として，「よりシンプルな見た目にして，活動の長さよりも，あなたが取り組んでいる仕事そのものに目が向くようにした」という趣旨のことが添えられているだけです．

issueが立ったのが4月1日で，発表が5月19日ですから，2ヶ月経っていません．世界中の開発者が毎日見ている画面の仕様が，一人の問題提起から2ヶ月弱で変わったことになります．

しかも，この静かさが僕はいいなと思っていて．「あなたの健康のために消しました」みたいな大々的な物言いをしていないんですよね．別の大きな機能追加のついでに，一行だけ書いて，そっと引っ込めた．消したこと自体を成果として売らない．この引き際は，かなり品があると感じます．

もちろん，惜しむ声もちゃんとありました．削除の4日後，5月23日に，さっき名前を出したfreeCodeCampのクインシー・ラーソンさんが記事を書いています．タイトルが「Don't break the chain」，まさに鎖を断ち切るな，です．連続記録は多くの人にとって前に進む力になっていた，それが失われたのは損失だ，という内容ですね．この記事の中で，1000日超えのジェド・ワトソンさんの記録も紹介されています．3年近く積み上げたものが，ある日サイトの仕様変更で表示ごと消える．これ，本人の気持ちを考えると，なかなかしんどいですよね．

つまりこれ，「悪い機能を消しました，めでたし」という単純な話ではないんですよ．誰かにとっては明確に燃料だった．その燃料が，別の誰かにとっては人を追い詰める仕組みでもあった．同じ数字が両方の顔を持っていた，という話です．

ここからは，そのあとの話をいくつかしていきます．

まず，連続記録は完全には死んでいません．GitHubが公式に出すのをやめたあと，有志が同じものを作りました．github-readme-streak-statsというツールがあって，これを使うと，現在の連続日数と最長記録を画像として生成して，自分のプロフィールに貼り付けられます．GitHubが引っ込めた数字を，ユーザーが自力で復活させたわけです．

これ，人間の性質がよく出ていると思います．数えられるものは数えたい．そして数えたら，記録を伸ばしたい．公式が「その数え方はやめよう」と言っても，欲しい人は自分で数えはじめる．ただ，決定的に違うのは，今のそれは自分で選んで付けている，というところです．全員のプロフィールに強制的に表示されるのと，欲しい人が自分で貼るのとでは，意味がまったく違いますよね．

次に，草をめぐる遊びの話もしておきます．gitfitiというツールがあります．gitとgraffiti，落書きを合わせた名前ですね．何をするツールかというと，草でドット絵を描くんです．

なぜそんなことができるかというと，gitはコミットの日付を後から指定できるからです．コミットには作った人の日付と，記録した人の日付という情報が入っているんですけど，これは環境変数で好きな値を渡せます．つまり「2年前の3月14日にコミットしたことにする」ができてしまう．gitfitiは，狙った日付にだけコミットを打つスクリプトを自動生成してくれて，結果として草の畑にドット絵が浮かび上がる，という仕組みです．リポジトリの説明文が「abusing github commit history for the lulz」，直訳すると「面白半分でGitHubのコミット履歴を悪用する」で，もうこの一文で全部わかりますよね．

これがなぜ愛されたかというと，「草は努力の証だ」という空気に対する，わりと上手い皮肉になっているからだと思います．真面目に毎日コードを書いた人の草と，スクリプトで作った草が，画面上ではまったく同じ緑なんですよ．数字で人を測ることの限界が，一発でわかる．

あともう一つ，草にまつわる誤解の話をしておきます．「ちゃんとコミットしているのに草が生えない」という現象，これはよくあります．公式ドキュメントにちゃんと条件が書いてあって，けっこう厳しいんですよ．

まず，コミットがカウントされるのは，そのリポジトリのデフォルトブランチ，つまり本流の枝と，あとgh-pagesという特別な枝だけです．自分用の作業ブランチにいくら積んでも，本流にマージされるまではカウントされません．

次に，フォークしたリポジトリでのコミットはカウントされません．フォークというのは，他人のリポジトリを自分のところに複製することですね．そこで作業した分は，元のリポジトリにプルリクエストを出して取り込まれない限り，草にならない．

そして地味に一番ハマるのが，メールアドレスです．コミットには書いた人のメールアドレスが記録されるんですけど，そのアドレスがGitHubアカウントに登録されていないと，本人のものと認識されません．会社のPCと個人のPCで設定が違う，というときによく起きます．しかもアドレスを追加してグラフが作り直されるまで，最大24時間かかると書かれています．

つまり，草の濃さって「その人がどれだけ働いたか」じゃなくて，「その人の作業が，GitHubがカウントする条件に，たまたまどれだけ合致していたか」なんですよね．ここ，かなり大事なところだと思います．

というわけで，最後に僕の仕事の話に少しだけ寄せさせてください．

僕は今，エンジニアの採用や技術広報に近いところで仕事をしているので，「GitHubの草を採用で見るべきか」という論点は，けっこう身近な話なんですよ．結論から言うと，僕は草の濃さを評価に使うのは筋が悪いと思っています．

理由は今日話してきたことがほぼ全部です．業務のコードは非公開のリポジトリにあることが多いですし，そもそも会社が自前のGitLabやBitbucketを使っていたらGitHubには何も出ません．フォークで作業していればカウントされない．メールアドレスの設定がずれているだけでも真っ白になる．

そして一番大きいのは，オープンソースに使える時間の量って，本人の情熱じゃなくて生活環境で決まる，というところです．小さい子どもがいるとか，介護をしているとか，体調の波があるとか，単に本業が忙しいとか．夜と週末にコードを書ける状態にある人だけが濃い緑になる指標を，能力の証拠として扱ってしまうと，何を測っているのかわからなくなります．熱意を測っているつもりで，可処分時間の多さを測ってしまうわけです．

だから草が濃い人を見たときに「おっ」と思うのは全然いいと思うんですけど，草が薄い人を見て「この人は勉強していない」と読むのは，ただの誤読だと思っています．情報として非対称なんですよね．あるのは強い証拠になるけど，無いのは何の証拠にもならない．

あと，これはグラフに限らない話なんですけど，何かを数字にして人に見せると，人はその数字を上げにきます．しかも大抵は，こちらが意図した上げ方じゃない方法で上げてくる．連続記録の場合はタイポ修正のコミットでしたけど，会社の中でもまったく同じことが起きますよね．レビュー数を評価に使えばレビューは雑になりますし，コミット数を見るようにすればコミットは細かくなる．メトリクスが目標になった瞬間に，メトリクスとして死ぬ，というやつです．

GitHubがやったのは，自分たちが作った指標について，それが起きていることを認めて，指標のほうを引っ込めた，ということです．計測をやめるという判断は，計測をはじめる判断よりずっと難しいと思います．やめると，それまで見えていたものが見えなくなりますし，「なんで消したんだ」という声も来ますから．それでも，測り方が人の行動を歪めているなら，測るのをやめる．これは組織を運営する側から見ても，かなり示唆のある判断だと感じます．

改めて振り返ります．2013年，一年を振り返るアルバムとして草が生まれました．社員が休暇や卒業を書き込んで楽しむような，そういう機能でした．そこに連続記録という数字が付いていて，毎日コードを書く文化と噛み合って，みんなが競うようになった．1000日連続という人まで現れた．でも同時に，休むと減点される仕組みでもあった．それに気づいた一人のエンジニアが，エイプリルフールの日に，公式でもないリポジトリのissueに問題提起をした．2ヶ月経たずに，GitHubは連続記録を消した．発表は一文だけでした．

一人が書いたissueが，世界中の開発者が毎日見る画面を変えた，という話です．しかも変わったのが「機能が増えた」じゃなくて「機能が減った」なのが，僕はいいなと思います．

今も草は生えます．濃いときもあるし，真っ白な週もある．でも，何日続いているかを数える機能は，もうGitHubには無いです．今日から皆さんの草は，少しだけ違って見えるかもしれません．鎖じゃなくて，アルバムのほうに戻して見てもらえたら，作った人たちも本望なんじゃないかと思います．

📎 https://github.blog/news-insights/product-news/introducing-contributions/ 📎 https://github.blog/2016-05-19-more-contributions-on-your-profile/ 📎 https://github.com/isaacs/github/issues/627 📎 https://news.ycombinator.com/item?id=11404482 📎 https://johnresig.com/blog/write-code-every-day/ 📎 https://www.freecodecamp.org/news/dont-break-the-chain-why-github-s-streaks-will-be-sorely-missed-by-many-4fff90bc2a38/ 📎 https://github.com/DenverCoder1/github-readme-streak-stats 📎 https://github.com/gelstudios/gitfiti 📎 https://docs.github.com/en/account-and-profile/how-tos/contribution-settings/troubleshooting-missing-contributions 📎 https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-github-profile/managing-contribution-settings-on-your-profile/viewing-contributions-on-your-profile

エンディング

【エンディングBGM】 さて，そろそろ今回もクロージングです． 今回は「GitHubの草，なぜ『連続記録』をやめたのか」について話しました．

次回も，Webテクノロジーの小噺をお届けします．

この番組が気に入った方は，ぜひチャンネル登録をお願いします． また，あなたからの感想やリクエストもお待ちしております！ 𝕏で #WEB小噺 をつけて投稿していただくか，概要欄のお便りフォームからお送りください．

それでは，また次回の雨宿りでお会いしましょう！「雨宿りとWEBの小噺」お相手は Keeth でした．さようなら！ 【ジングル】

📚 参考情報

未検証（要確認）：「草」という日本語呼称の定着経緯（一次情報なし．台本では「と言われています」に留めている）／2013 年当時の GitHub の規模感／isaacs/github が事実上の要望箱として機能していた経緯（アーカイブ日 2021 年 11 月は確認済み）．

🎙️ 収録メモ

  • トーン
    • つかみは軽く．「草の下に数字があったのを覚えてますか」を思い出させる調子で
    • 背景（2013 年）は懐かしむ調子．アルバムとして作られた，を強めに置く
    • streak 文化のくだりは熱量を上げる．1000 日連続はゆっくり，間を取って読む
    • issue のくだりから声のトーンを一段落とす．ここが本題の芯
    • 「一文だけです」は，本当に一拍置いてから
    • Engineering HR の所感は説教くさくならないよう，淡々と
  • 強調ポイント
    • 最初の草は「計測器」ではなく「一年を振り返るアルバム」だった
    • 提案は「消せ」ではなく「休むことが評価される形にしろ」だった
    • 削除の告知はたった一文．消したことを成果として売らなかった
    • 草の濃さは働いた量ではなく，GitHub のカウント条件への合致度
    • 無いことは何の証拠にもならない（採用で草の薄さを読まない）
  • 尺
    • 合計：約 28〜30 分
    • オープニング：30 秒〜1 分
    • 本編：27〜29 分
    • クロージング：1 分
  • タグ

    • WEB小噺 #GitHub #草 #オープンソース #開発者体験

results matching ""

    No results matching ""