毎日コミット生活をやってみた

## まえがき

某Webサービスにてフロントエンドエンジニアをしている「Chocomint」と申します。
掲題の内容について社内LT会にてお話する機会があったので、こちらでも書き残したいと思います。
どなたかの参考になれれば幸いです。

## 毎日コミット生活を始めるきっかけ

私が毎日コミット生活を始めたきっかけは主に4つありました。

### 1. 友達と企画したペアプロ勉強会が霧散
企画したものの2回ほど実施してフェードアウトしていきました。
PRやIssue達を残し...不完全燃焼間を抱える事になりました。

### 2. 現場業務で使っている技術への学習欲
当時の現場は割とモダンな開発環境で、1度に多くのことをインプットしたため定着しているか不安を抱えていました。

### 3. 新しいことへの好奇心
日々新しい技術やサービスが生まれているなかで、ちょっとでも触れてみて歩み寄れたら良いな、と思っていました。

### 4. Write Code Every Day に出会った
昔1度読んだことのある記事ですが久しぶりに読む機会があり、
何でもいいので学習に取り組みたいという気持ちが高まる大きな要因となりました。

## Write Code Every Day とは

jQuery 生みの親である John Resig 氏が提唱した取り組みで、その名の通り毎日コードを書くことを意味しています。

これは John 氏が週末にサイドプロジェクトを開発していく中で感じた、以下のような問題点を解消すべく実施した取り組みです。

- 毎週末が自由な保証がないし、時間があってもリラックスしたり他に楽しいことをやる時間がなくなるかもしれない
- 週末に室の高い仕事をやろうとするとストレスがかかるし、できなかったときに失敗したような気持ちになる
- 作業が1週間空くと何をやっていたか忘れがちになるし、仮に週末時間が取れないと2週間も空いてしまう

これらの問題を解決するために、 John 氏はルールに従って毎日コードを書くことに取り組みました。

ルールの詳細や記事本文はこちらのブログ記事を読んで頂ければと思います。
https://johnresig.com/blog/write-code-every-day

## 継続するための工夫・モチベーションの保ち方

Write Code Every Day を読んでやる気が出たことで、私も毎日コミットすることを目標に取り組み始めました。
その中でいくつか意識したことを紹介させていただきます。

### 1. ルールはある程度緩くてOK
何事も続けられないと成し得ないと考えたので、 **続けられるレベルから始めていく** ことにしました。(小さな修正やPRコメントなど何でもコミットにカウントしてOKなど)

本来の Write Code Every Day はルールが厳しく、特に **「有益なコードを書かなければならない(フォーマット修正やリファクタはカウント外など)」** や、 **「書いたコードを Github ですべて OSS にすること」** は除外しました。

### 2. やっていて楽しい形を目指す

プライベートの時間を使うからには **楽しむことが何より大事** だと考え、やりたい技術の学習・復習や好奇心を満たせるもの(ツールやサービス)に触れることをモットーにしました。

### 3. 習慣化し「頑張らないこと」を頑張る

日々意識せずに自然と取り組む事ができればプレッシャーにはならないので、「早起き30分、夕食後の15分、寝支度前の30分」などのタイミングで実施しルーティン化するようにしました。

### 4. 小さなコミットネタをストック

3に関連しますが、5分程度でできる以下のようなコミットネタをたくさん用意し、サクッとこなすことを心がけました。

- 自分で立てた PR にセルフレビュー

- PR 作成時に自動で Vercel に上がる Preview 版をモンキーテスト

- 違和感や改善点、盛り込みたい技術や要素を Issue として立てる

これらは基本的には電車移動中に実施していましたが、消化しきれないほどのネタが溜まっていきました。
アイディアがどんどん浮かんでくる様になり、考える時間がめちゃくちゃ楽しかった思い出です。

## 取り組みを通して経験できたこと

### 1. 約3ヶ月連続のコミット

コミット数は日によりけりですが、約3ヶ月間(未push含め100日分ほど)の連続コミットを達成しました。

2週間を過ぎたあたりからはコミットすることが生活の一部になり、「今日は何をやろうかな」「ストックしているあれ、それともこっちをやろうかな」と手を動かすことが楽しくて、コミットできる時間が空くのが楽しみで仕方なかったです。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/283305/4651a485-2d5c-4ce6-1fca-af8e72706b07.png)


※後述しますが、習慣が崩れ去るのは一瞬でした...

### 2. いくつかの技術・サービスへの歩み寄り

この3ヶ月の中で色々な技術に触れることができました。その中でも個人的に記憶に残っているものを3つ紹介します。

#### 1. micro CMS

そもそもヘッドレスCMSとはなんぞや？を調べるところからたどり着き、「Web上からリッチエディタでマークダウン記事を入稿 → データを API で取得 → HTML で出力 + コードブロックはパースしてハイライト」をして簡易ブログとして利用するデモを作成しました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/283305/49e55241-cd38-e648-50a6-70a2cf101a2c.png)


#### 2. Figma

LP作成に際して簡単にデザイン起こしをしたく利用しましたが、自分のセンスの無さに絶望するとともに、デザイナーさんへの尊敬の念が高まりました。
コンポーネント化だったりカラートークンだったり、現場で使っている事柄を多少かじることができました。

#### 3. Issue駆動開発

Issue に基づきブランチを作成し、コミットや PR を紐づけてタスクをこなしていく流れで自己学習、LP作成を進めることを行いました。
私は以下のような流れで取り組むことで、実際の業務での案件開発に近い形で学習に取り組むようにしていましたが、結構しっくり来たので今後も取り入れていきたいと思います。

```
1. 実装したい事柄をタイトルにし Issue を立てる
2. 要件の詳細を Description に記載し、ざっくりとした見積もりを出す
3. Issue からブランチを切ってコミットし、 PR を立てる
4. 要件に対しての試験内容を記載して Preview 版で試験実施
5. コードも問題なければマージし、かかった工数を計上する
```

### 3. 人生初の OSS Contribution

レーダーチャートを使いたくて利用した [Chart.js](https://github.com/chartjs/Chart.js) にて軽微な Typo があったため Issue を立てて修正 PR を作成しました。

内容としては本当に軽微でしたが流れを経験することで OSS Contribution へのハードルが下がりましたし、自分の名前が Contributor として残ることは地味に嬉しいなと感じました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/283305/626794cc-6fe0-6bd3-69d9-a5ff463f7f62.png)
https://github.com/chartjs/Chart.js/releases/tag/v4.4.1

## まとめ

何と言っても **「継続は力なり！」** ですね！
新しいことを学ぶことより継続することのほうが難しく、継続さえしていれば多くの学びに出会えると感じました。

ちなみにあれだけ楽しく毎日コミットしていたのに、諸事情で3日ほど作業できない日が続いてしまった結果、途端に習慣がリセットされてしまいました...

また4月から毎日コミット生活を再開しようと思っているので、習慣化目指してゆるりと頑張っていきたいです💪