個人開発のコミット数とトレ達成率を、同じ表に並べた

last month
1

個人開発のコミット数とトレ達成率を、同じ表に並べた

金曜の夜、スプレッドシートで12週分のデータを結合し終わった。
個人開発のリポジトリのコミット数と、ジムのトレ達成率を、週単位で1枚の表に並べただけだ。並べる前にざっくり予想を立てておいたが、結果は予想とちょっと違った。

両方のデータは前から取っていた。コミット数は GitHub の Insights から週次で吸い出せる。トレ達成率は、自分で組んだ週次プログラム(ベンチ・スクワット・デッドリフトを含む計5種目)に対して、計画したセット数のうち何割を実際にこなせたかの%値だ。半年くらい両方つけていたが、別ファイルに入っていたので一緒に見たことがなかった。

今日たまたま結合してみた。気づいたことを残しておく。

12週分のデータ

2026年Q1〜Q2の頭、12週分。

個人開発コミット数トレ達成率本業残業(h/週)体感
W0118100%5普通
W0222100%4
W03960%14きつい
W04440%18きつい
W051480%8普通
W0625100%3
W0719100%6普通
W081160%12きつい
W09640%16きつい
W1020100%5普通
W1123100%4
W121680%7普通

コミット数は merge commit を除いた個人開発リポジトリの数値。トレ達成率は、その週に計画した全セット数(だいたい週60〜70セット)に対して実際に挙げたセット数の比率。

並べた瞬間に、自分でも結構驚いた。

コミット数とトレ達成率が、ほぼ同じ動きをしている

12週のうち、コミット数が10件以下に落ちた週は3週(W03、W04、W09)。
このうち、トレ達成率が60%以下に落ちているのも同じ3週だった。

逆にコミット数が20件を超えた週は4週(W02、W06、W10、W11)。
このうち、トレ達成率100%を達成しているのは4週とも全部だった。

ためしに2列の相関係数を計算してみたら、約0.91だった。サンプル12個だから統計的な強い主張はできないが、見た目の傾向としてはほぼ同調している。これは予想していなかった。

自分の最初の予想は「コミット数とトレ達成率は逆相関するか、無相関だろう」だった。両方とも時間を食うアクティビティだから、片方をやれば片方が削れるだろう、と思っていた。並べた結果は完全に逆だった。

「忙しい週は両方落ちる」

整理し直すと、こういうことだ。

  • 本業が忙しい週は、本業以外の活動が全体的に落ちる
  • 本業の負荷が軽い週は、個人開発もトレも両方伸びる
  • 片方が伸びて片方が落ちる、という相互排他は12週で1回も起きていない

これは「個人開発の時間とトレの時間が競合する」という自分の仮説を否定している。実際には、競合しているのは「本業の残業時間」と「本業以外の活動の総量」のほうだった。

W03、W04、W09はいずれも本業の残業が週14時間を超えている週。月曜から金曜まで毎日21時過ぎ帰宅、というやつだ。この状態だとジムにも行けないし、個人開発の PC も開かない。両方が同時に止まる。
逆にW06、W11は残業が週4時間以下。20時前に帰れる日が多い週は、ジムで法定セット全部こなし、家に帰ってからもコードを書く余裕がある。

なぜ両方同時に動くのか、考えてみる

スプレッドシートを閉じて、プロテイン飲みながら考えていた。仮説を3つ書いてみる。

1つ目。意思決定のスタミナが共通リソースになっている仮説。個人開発もトレも、本業のあとに「やるかやらないか」を選ぶ必要がある。本業で消耗していると、この選択コストが払えない。だから両方とも「やらない」に寄る。ベッドに直行する選択肢が最強になる週、というやつだ。

2つ目。生活リズムが同じ依存関係を持っている仮説。個人開発は夜21時から22時、トレは平日朝6時か終業後19時、というのが自分のパターンだ。残業すると終業後19時のジムが流れる。終業後ジムが流れると朝6時ジムにシフトしようとして睡眠時間が削れ、夜の個人開発も精度が落ちる。スケジュールがドミノで倒れる構造になっている。

3つ目。そもそも余裕の出る週と出ない週が、自分の意志ではなく本業のフローで決まっている仮説。これがいちばんありえると思っている。個人開発もトレも、自分が主体的にコントロールしているように見えて、実際は本業の繁忙度に従属している。

3つ目の仮説が正しいなら、「個人開発を頑張ろう」「トレを頑張ろう」と気合いを入れるのはほぼ意味がなく、本業の残業を週10時間以下に抑える運用のほうが、個人開発とトレの両方に効く、ということになる。

これは自分のなかでは結構大きな結論だ。

次の12週で検証したい

データを取って分かったことを、運用に落とし込みたい。

  • 本業の残業時間を週次でログする(これは Linear から取れる)
  • 残業が週10時間を超えそうな週は、個人開発もトレも事前に低めの目標に書き換える
  • 「忙しい週ほど両方頑張る」の精神論を捨てる。落ちる週は両方落とす前提で計画する
  • 余裕のある週は、両方を意図的に詰める

要するに、両者を独立して頑張るのではなく、本業の残業時間という共通変数で運用する、ということだ。

次の12週で同じ表を取って、運用変更が効くか見たい。仮説が正しければ、W03・W04のような両方ダブル落ちの週でも、計画段階で目標を落としているぶん「達成率」のような相対指標は維持できるはずだ。

表に並べないと見えないものがある

データを取っていても、別のファイルに入れたままだと一生気づかない、というのは前から思っていた。今回はそれが個人開発とトレで起きていた。

別の言い方をすると、自分の「忙しさで何が削れるか」は、自分が思っているほど自分でコントロールできていない。コミット数とトレ達成率という、見た目はぜんぜん関係ない2つの指標が、実は本業の残業時間という1つの変数に同調していた、というのが今回の発見だ。

次に並べてみたいのは、コミット数と睡眠時間の相関だ。これは Apple Watch から吸い出せるが、結果が怖い。たぶん0.9くらい出る気がする。

0
0
0