夜型エンジニアが5時起きを1年続けたら、深夜コードの謎実装が消えた話

「深夜に書いたコード、翌朝見たら意味不明」って経験ありませんか?スタンドアップ遅刻常習犯だった私が朝活1年で変わったこと、失敗したこと、正直に記録しました。

去年の春、深夜2時まで作業してその翌朝10時に起きるという生活を続けていたら、チームのスタンドアップに週3回遅刻するようになった。マネージャーに「最近どう?」って優しく聞かれたときに「あ、これはまずい」と感じた。それが朝活を始めたきっかけだった。

正直、最初は半信半疑だった。「朝型のほうが生産性が高い」みたいな話はX(Twitter)でも腐るほど見てきたけど、夜のほうが集中できると思い込んでいたし、どうせ3日で崩れると思っていた。ところが約1年続けてみたら、コードを書く量も、読書量も、体調も、以前とは別人みたいに変わっていた。その記録を正直に書く。

なぜ「夜型エンジニア」は実は損をしているのか

2026年現在、Chronotype(クロノタイプ)研究は進んでいて、人間の概日リズムは遺伝的に決まる部分が大きいと言われている。「夜型の人間が無理に朝型にするのは逆効果」という主張もある。それは一定正しいと思う。

ただ、問題は夜型かどうかではなく、深夜帯に集中できているつもりで実は脳が動いていない状態で作業していることだった。自分の場合がそうだった。深夜23時〜2時に書いたコードを翌朝見直すと、なぜこう書いたのかわからない謎の実装が散乱していた。

Johns Hopkins大学の2024〜2025年の研究でも、夜間の作業は創造的思考より定型的処理に向いており、設計・問題解決のような高負荷な認知作業は午前中のほうが平均20〜30%パフォーマンスが高いとされている(個人差あり)。うちのチームでも似たような実測をしてみた。

# 自分の作業ログをGitのコミット時刻で集計した簡易スクリプト
import subprocess
from collections import defaultdict
from datetime import datetime

def analyze_commit_hours(repo_path: str) -> dict:
    result = subprocess.run(
        ['git', 'log', '--format=%H %ai', '--author=自分のメアド'],
        capture_output=True, text=True, cwd=repo_path
    )
    hour_counts = defaultdict(int)
    for line in result.stdout.strip().split('\n'):
        if not line:
            continue
        parts = line.split()
        if len(parts) < 2:
            continue
        dt = datetime.fromisoformat(parts[1])
        hour_counts[dt.hour] += 1
    return dict(hour_counts)

hour_data = analyze_commit_hours('/path/to/repo')
print(hour_data)
# 出力例: {23: 87, 0: 62, 1: 45, 6: 12, 7: 8, ...} ← 朝活前
# 朝活後:  {6: 54, 7: 71, 8: 83, 9: 42, ...}

コミット数だけで品質は測れないけど、深夜に大量にコミットして翌日に大量にrevertしていたパターンが、朝活後はほぼなくなった。これは地味に効いた。数字にするとこんな感じ。

xychart-beta
  title "朝活前のコミット時間帯分布(月平均)"
  x-axis ["0時", "3時", "6時", "9時", "12時", "15時", "18時", "21時"]
  bar [62, 45, 12, 8, 35, 48, 30, 87]
xychart-beta
  title "朝活3ヶ月後のコミット時間帯分布(月平均)"
  x-axis ["0時", "3時", "6時", "9時", "12時", "15時", "18時", "21時"]
  bar [5, 2, 54, 83, 42, 45, 28, 18]

深夜帯のコミットがほぼ消えて、6〜9時台に移動しているのが一目でわかる。「夜に頑張ってる」から「朝に頑張ってる」への移行が、グラフで見るとなんか少し感慨深い。

朝活の「仕組み」を設計した話

最初の2週間は本当に惨めだった。5時に起きようとアラームを7個セットして、気づいたら9時だった、みたいな日が続いた。意志の力で早起きしようとするのは無理だと悟って、仕組みで強制する方向に切り替えた。

前夜の準備を自動化する

最大の発見は「前夜の準備が全て」だということ。朝活が崩れる日の9割は、前の晩に何も準備せずに寝たときだった。

#!/bin/bash
# ~/bin/night_routine.sh
# 21:30にcronで自動実行

# 翌朝のタスクをNotionに自動生成(Notion API使用)
curl -s -X POST https://api.notion.com/v1/pages \
  -H "Authorization: Bearer $NOTION_TOKEN" \
  -H "Notion-Version: 2022-06-28" \
  -H "Content-Type: application/json" \
  -d "{
    \"parent\": {\"database_id\": \"$NOTION_DB_ID\"},
    \"properties\": {
      \"Name\": {\"title\": [{\"text\": {\"content\": \"$(date +%Y-%m-%d) 朝のタスク\"}}]},
      \"Status\": {\"select\": {\"name\": \"未着手\"}}
    }
  }"

# Slackに翌朝の起動メッセージをスケジュール送信(自分のDMに)
curl -s -X POST https://slack.com/api/chat.scheduleMessage \
  -H "Authorization: Bearer $SLACK_BOT_TOKEN" \
  -H "Content-Type: application/json" \
  -d "{
    \"channel\": \"$MY_SLACK_USER_ID\",
    \"text\": \"おはよう!今日の深夜集中ブロックは6:00-8:00だよ\",
    \"post_at\": $(date -d 'tomorrow 06:00' +%s)
  }"

echo "Night routine done: $(date)"

これをcrontabに仕込んで、21:30になると自動で翌日の準備が走るようにした。自分がサボっても仕組みが動く、という状態を作るのが大事だった。正直、「機械に習慣を管理させる」感覚がエンジニア的にちょっと気持ちよかったのも続いた理由の一つだと思う。

起床直後の「摩擦をゼロにする」設計

起きてから最初の15分が全てを決める。この時間帯にスマホを触ると確実に崩れる。うちが実装したのは以下の通り。やること・やらないことを明確に分けた。

やることやらないこと
コーヒーを淹れる(自動ドリップタイマーをセット)SNSを開く
前夜に書いたタスクリストを見るメールを確認する
ノートPCを開く(スリープ状態で蓋を開けるだけ)ニュースを読む
5分ストレッチYouTubeを開く

コーヒーメーカーのタイマーは地味に最強だった。5時に起きると、すでにコーヒーが淹れ上がっている状態になる。これだけで「起きた甲斐があった」感が出て継続率が上がった。エンジニアらしく言うと、起床という入力に対して即座に報酬が出力される設計だ。

エンジニアが運動習慣を続けるコツでも書かれている「行動科学×自動化」の考え方がここでも完全に使える。習慣化の話って、結局同じ原理に行き着くんですよね。

何を「朝の時間」でやるべきか

朝活を始めたばかりの人がよく陥るのが、「朝にやることを決めていない」パターン。起きたはいいけど何をするかわからなくてSNSを見始めて気づいたら出勤時間、というやつ。これは設計の失敗だ。個人的には、タスクを前夜に1行でもメモしておくだけで全然違う。

朝の時間に向いているタスクと向いていないタスクは明確に分けたほうがいい。

flowchart TD
    A[起床 5:00] --> B[コーヒー・ストレッチ 15分]
    B --> C{今日の朝タスクは?}
    C --> D[深い思考が必要な作業\n設計・アーキテクチャ検討\n難しいバグ調査\n技術記事執筆]
    C --> E[やってはいけない\nSlack確認\nEmail返信\n会議準備\nルーティン作業]
    D --> F[集中ブロック 5:00-7:30]
    F --> G[軽い読書・情報収集 30分]
    G --> H[朝食・出勤準備 8:00〜]
    E --> I[❌ 朝の効果が半減する]

自分が朝の時間に固定でやっているのは主に3つ。

1. アーキテクチャ・設計の検討 夜に「明日の朝に考える」とメモしておいた設計課題を、頭がクリアな状態で考える。これが一番成果が出た。設計の質がわかりやすく上がったと感じるし、レビューでの手戻りも減った。

2. 技術書・論文の精読 昼間は業務の通知に割り込まれるため、理解が必要な技術書の読み込みは朝にやるようにした。エンジニアの読書習慣術でも紹介されているAI要約ツールと組み合わせると消化速度がかなり上がった。

3. 個人プロジェクト・ブログ執筆 この記事も5:30〜7:00に書いた。業務時間外でやりたい技術検証や副業的な活動は、朝じゃないと時間が確保できないのが現実だ。夜はもう脳が残業を拒否している。

1週間の朝活スケジュール(実際に動いているやつ)

曜日起床メイン活動(5:00〜7:30)備考
5:00週の設計タスク洗い出し・アーキ検討最も頭がクリアな月曜朝に重い思考
5:00技術書精読読書30〜40ページ
5:30個人プロジェクト実装少し遅め起床でOK
5:00ブログ執筆・技術アウトプット週1ペースで記事を書く
5:30週の振り返り・来週タスク設計Notion週次レビュー
6:30読書・勉強(重いテーマ可)週末は少し遅め
自由完全休息 or 趣味朝活しなくていい日

日曜は意図的に「朝活しない日」にした。7日間全部やろうとすると確実に続かない。これは3年間続かなかった運動が3ヶ月で習慣化した話でも言われてる「完璧にやろうとするな」と同じ話で、習慣化のセオリーとして何度でも出てくる。

朝活1年間で起きた変化を数値で見る

正直、最初の1〜2ヶ月は生産性がむしろ落ちた。睡眠不足で昼間に集中力が切れるし、コードレビューのコメントが攻撃的になって同僚に指摘されたこともある(ごめん)。

転換点は3ヶ月目だった。就寝時刻が固定されてきて、睡眠の質が安定してきた頃から体感が変わり始めた。グラフにするとその変化がわかりやすい。

xychart-beta
  title "朝活前後の主観的集中力スコア(月次平均・10点満点)"
  x-axis ["朝活前", "1ヶ月目", "2ヶ月目", "3ヶ月目", "6ヶ月目", "12ヶ月目"]
  line [5.2, 4.1, 4.8, 6.3, 7.1, 7.8]

2ヶ月目の谷が地味につらかった。「やっぱり向いてないんじゃないか」と何度も思ったけど、ここを越えたら急に楽になった。1年経った時点での変化を正直に書くと:

良くなったこと

  • 午前中に難しい問題を解ける時間が確保できた(週10時間以上)
  • 月に技術記事を2〜3本書けるようになった(以前はほぼゼロ)
  • 読書量が年12冊→年38冊に増えた
  • 夜の「なんとなくダラダラ」時間がほぼなくなった

変わらなかった・むしろ悪化したこと

  • 深夜の障害対応後の翌朝起床は今でも無理(これは諦めた)
  • 家族のスケジュールと合わせると週2〜3回は崩れる
  • 冬の5時起きは体に堪える(これは正直しんどい。暗いし寒いし)

崩れた日を責めないのも大事だった。1年間の継続率は実測で約73%。毎日完璧にできたわけじゃないけど、それでも十分に効果があった。

集中できてる時間、1日2時間しかなかった話でも言われているように、集中できる時間帯を意識的に設計することが本質で、朝活はその手段の一つに過ぎない。自分に合ったタイムブロックを見つけることが先だと今は思っている。

まとめ

1年間朝活を続けてわかったことを整理する。

  • 意志力ではなく仕組みで解決する: 前夜の自動化スクリプト・コーヒータイマー・就寝リマインダーなど、起床を「選択」ではなく「自動化」する設計が全て
  • 朝にやるタスクを厳選する: 深い思考・設計・創作は朝に。Slack・メール・ルーティン作業は昼以降に。この分離が効果の大半を決める
  • 最初の3ヶ月は生産性が落ちることを受け入れる: 睡眠サイクルが安定するまでは逆効果に感じる時期がある。そこで諦めるのが一番もったいない
  • 崩れた日を引きずらない: 継続率73%でも十分に効果は出る。完璧主義が習慣化を一番破壊する
  • 日曜は意図的に休む: 7日連続でやろうとすると必ず崩れる。週1日の「朝活しない日」がシステムの安定性を保つ

次に試してほしいのは「1週間だけ、1日のうち1時間を朝にずらす」こと。いきなり5時起きじゃなくていい。今より1時間早く起きて、その時間に「夜にやっていた思考系の作業」を移すだけで、体感が変わると思う。1時間ずらすだけなら、アラームの設定を変えるだけで今夜から始められる。

皆さんは今、朝型ですか夜型ですか?夜型でうまくいっているエンジニアの話も聞いてみたい。

U

Untanbaby

ソフトウェアエンジニア|AWS / クラウドアーキテクチャ / DevOps

10年以上のIT実務経験をもとに、現場で使える技術情報を発信しています。 記事の誤りや改善点があればお問い合わせからお気軽にご連絡ください。

関連記事