月曜朝イチのコードが金曜夕方より美しい理由

この記事は約 5 分で読めます。

Git のコミットログが語る真実

自分のコミット履歴を曜日別に分析したことはありますか。月曜日のコミットと金曜日のコミットを比べると、興味深い傾向が見えます。

月曜日のコードは、命名が丁寧で、関数が小さく分割されていて、コメントも適切。金曜日のコードは、変数名が雑で、関数が長く、「TODO: あとでリファクタリング」のコメントが増える。

これは意志の問題ではなく、認知資源の問題です。

認知資源と意思決定疲れ

人間の脳が 1 日に下せる質の高い意思決定の数には限りがあります。これを「意思決定疲れ (decision fatigue)」と呼びます。

コードを書く行為は、連続的な意思決定の塊です。変数名をどうするか、関数をどこで分割するか、エラーをどう処理するか。1 行書くたびに複数の判断を下しています。

月曜の朝は認知資源が満タンです。週末の休息で脳がリフレッシュされ、1 つ 1 つの判断に十分なリソースを割ける。金曜の夕方は、1 週間分の意思決定で認知資源が枯渇しています。判断の質が下がり、「とりあえず動けばいい」というコードが生まれます。

読書が認知資源を回復させる仕組み

ここで読書の話につながります。

技術書を読む行為は、コードを書く行為とは異なる種類の認知活動です。コードを書くときは「判断」と「出力」が求められますが、本を読むときは「入力」と「整理」が中心。使う脳の領域が異なるため、読書はコーディングで疲弊した認知資源を間接的に回復させる効果があります。

設計の本を昼休みに 15 分読むだけで、午後のコーディングの質が変わることがあります。

週を通じてコード品質を維持する方法

朝の 15 分読書

出社してすぐコードを書き始めるのではなく、最初の 15 分を読書に充てます。設計原則やベストプラクティスの本を読むことで、「良いコードとは何か」の基準が頭の中にセットされます。

この 15 分は、1 日のコード品質の基準線を引く作業です。基準線が高い状態でコーディングを始めれば、疲れてきても品質の下限が保たれます。

水曜日のリセット

週の真ん中、水曜日に意識的に読書の時間を取ります。月曜・火曜で蓄積した認知疲労をリセットし、木曜・金曜のコード品質を維持するためです。

昼休みに 20 分、あるいは午後の始まりに 15 分。短い読書でも、認知のモード切り替えとして機能します。

金曜日は設計に充てる

金曜の午後は、新しいコードを書くのではなく、来週の設計を考える時間に充てます。設計は「判断」の連続ですが、コーディングほどの精密さは求められません。

設計の本を参照しながら、来週実装する機能のアーキテクチャをスケッチする。この過ごし方なら、認知資源が枯渇した金曜でも質の高いアウトプットが出せます。

コード品質の曜日変動を減らすもう 1 つの方法

読書以外にも、コード品質の変動を減らす方法があります。それは「判断を減らす」ことです。

コーディング規約、リンター、フォーマッター。これらのツールは、命名やフォーマットの判断を自動化し、認知資源の消費を減らします。判断が減れば、金曜でも月曜に近い品質を維持できます。

技術書で学んだ設計原則を、チームのコーディング規約に落とし込む。これは「読書の知識をツールに変換する」行為であり、個人の認知資源に依存しない品質保証の仕組みです。

関連記事

• 技術書を読むベストな時間帯はいつか - 朝型・夜型エンジニアの読書事情
• 寝る前の 10 分間読書が翌朝のコードに効く理由

まとめ

月曜のコードが金曜より美しいのは、認知資源の残量の差です。朝の 15 分読書で品質の基準線を引き、水曜にリセットし、金曜は設計に充てる。読書はコーディングとは異なる認知活動であり、疲弊した脳を間接的に回復させます。週を通じてコード品質を維持するために、読書を戦略的に組み込んでください。