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

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

コミットログを曜日別に見比べてみる

自分のコミット履歴を曜日別に見比べてみたことはありますか。月曜日のコミットと金曜日のコミットを並べると、書き方の傾向が違って見えることがあります。

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

心当たりがあるなら、それは意志の弱さというより、週の後半ほど判断が雑になりやすいことの表れかもしれません。

認知資源と意思決定疲れ

判断を続けているうちに判断の質が落ちていく現象は「意思決定疲れ (decision fatigue)」と呼ばれます。ただし、意志の力が燃料のように減っていくという説明については、複数の研究室が参加した事前登録つきの大規模な再現実験 (2016 年) が明確な効果を確認できておらず、仕組みの理解は定まっていません。1 日に下せる判断の数に決まった上限がある、という話ではなく、実感として語られる傾向として読んでください。

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

月曜の朝は、週末に仕事から離れた分だけ 1 つ 1 つの判断に時間をかける余裕があります。金曜の夕方は、1 週間分の判断を積み上げた状態です。細かい選択が面倒になり、「とりあえず動けばいい」というコードが生まれやすくなります。

読書がコーディングの息継ぎになる理由

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

技術書を読む行為は、コードを書く行為とは求められるものが違います。コードを書くときは「判断」と「出力」が続きますが、本を読むときは「入力」と「整理」が中心です。判断を下し続ける状態からいったん離れられるため、読書はコーディングの合間の切り替えとして働きます。

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

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

朝の 15 分読書

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

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

水曜日のリセット

週の真ん中、水曜日に意識的に読書の時間を取ります。月曜・火曜で溜まった疲れを一度リセットし、木曜・金曜のコード品質を保つためです。

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

金曜日は設計に充てる

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

設計の本を参照しながら、来週実装する機能のアーキテクチャをスケッチする。この過ごし方なら、判断を積み上げた金曜でも質の高いアウトプットを出しやすくなります。

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

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

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

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

関連記事

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

まとめ

月曜のコードが金曜より整って見えるのは、週の後半ほど判断が雑になりやすいからだと考えられます。朝の 15 分読書で品質の基準線を引き、水曜にリセットし、金曜は設計に充てる。読書はコーディングとは求められるものが違うため、判断を下し続ける状態から離れる時間になります。週を通じてコード品質を維持するために、読書を戦略的に組み込んでください。