こんにちは。数年ぶりにス〇バで買ったデカフェのアイスコーヒーが麦茶みたいで、濃いめの麦茶に砂糖とミルクを入れればス〇バのコーヒーになるという知見を得られた人です。

コードは残るが、記憶は残らない

開発者として日々仕事をしていく中で、次のようなまぁまぁ致命的な問題に悩まされていました。

• タスクをいくつもこなしたはずなのに、その日の終わりに何をやったか思い出せない
• 機能を追加・修正したときに、動作確認はしたのに手順を忘れて「ほんとに大丈夫？」と自分を疑う
• 「なぜそうしたのか？」という意思決定の背景も忘れる
  • コミット履歴だと意外と分からない

結果として同じ調査をしたり、成果を自信をもって語れない──そんなことが起きていました。

正直、私はダチョウ並みの記憶力しかないので、実装が多岐にわたるとやったことをすぐに忘れてしまいます。

そこで記憶するのは諦め、毎日の作業を開発ログとして残す仕組みを作りました。これが初日からかなり効果を発揮したので、そのやり方をシェアします。

Notionではなく、あえてMarkdown

ドキュメント管理といえば、まず思い浮かんだのはNotionといったオンラインツールです。実際に試してみたのですが、どうにも自分にはフィットしませんでした。

• オンラインツールに機密情報は書けない
• シンプルに階層化しつつ一覧もできる構造が作れない
• 綺麗に整えたくなってしまい、肝心のログを書くのが面倒になる

ツールとしては非常に優秀で、他の用途には今でも愛用しています。ただ「日々の開発ログを残す」という目的には、私には向きませんでした。

選んだのは VSCode + Markdown + Git

そこでもっと気軽に、かつ整理しやすい仕組みを探した結果、「VSCode + Markdown + Git(リモートリポジトリなし)という、ある意味原始的な構成に落ち着きました。シンプルかつ普段からなじみのあるツールで完結するのが気に入っています。

参考にしたのは以下の記事です。
Amazonのシニアエンジニアの方の投稿ですが、世界のトップエンジニアでも自分と同じ悩みを抱えていると知り、少し安心しました。

My notes taking app story with markdown, git, VS Code and LLM

朝に書いて夜に更新(運用スタイル)

ここからは、実際に私がどのように開発ログを書いているかをご紹介します。
基本はシンプルで、「朝は今日やることを書き出し、夜にやったことへ更新」 という流れです。
詰まったポイントや気づきも、思いついたときにメモしておきます。

ログのひな形 (Markdown)

# 開発ログ

## 取り組み

- XX APIのレスポンス改善に向けてキャッシュ実装を試す
    実行結果 → 動作確認ログ/案件/913_APIのXXの動作確認.md
    - 全パターン問題なし

## 詰まったポイント・気づき

- 動作確認する時はXXの状態も合わせて確認すること
- 

## 次にやること

- 単体テスト追加（ヒット/ミス/期限切れ）

ディレクトリ構成の例

私の場合、案件ごとにディレクトリを分けつつ、知見・ログ・動作確認ログを整理してます。
ざっくりイメージは以下のようになります。

dev-log/  # ここをgitで管理
  ├── 00_知見Doc/     # Tipsをまとめる場所
  │   └── AWS/
  │       └── IAMロール設定まとめ.md
  │
  ├── 01_案件1/
  │   ├── 開発ログ/
  │   │   └── 2025/
  │   │       ├── 913.md    # 日次ログ
  │   │       └── 914.md
  │   │
  │   └── 動作確認ログ/
  │       └── 913_APIのXXの動作確認.md
  │
  ├── 02_案件2/
  │   └── ...
  │
  └── 99_その他/    # 雑多なメモや一時的なメモ置き場

ログがくれる安心感と自信

実際に運用を始めてみると、すぐに効果を実感できました。

迷わなくなった

過去のログを見返せば「何をしたか」「どう確認したか」が一目で分かるので、翌日以降もスムーズに作業を再開できます。

自信を持って成果を報告できるようになった

実装内容や動作確認の記録が残っているので、進捗報告の場でも精確に、自信をもって成果を伝えられるようになりました。確認漏れの不安が軽減したもの大きいですね。

小さなドキュメントも完結できる

関数の役割や引数の整理といった、実装前に軽くまとめておく程度の小さなドキュメントも、この仕組みで一緒に残せるようになりました。
まだ実践中ですが、これを出発点にすることで、そのままコードや仕様書へと展開できるようになるのではないかと思います。

まとめ

その日やったことを思い出せないのは、自分のダチョウ並みの記憶力のせいだと長らく思っていました。ところが、どうやらトップエンジニアでも同じ悩みを抱えているらしいと知り、少し安心しました。

外部の高度なツールではなく、VSCode + Markdown + Git という素朴な構成だからこそ、気負わずに続けられ、整理もしやすいのだと思います。

今後もこの方法を続けて、より確実で安定した開発を重ねていきたいです。

（担当：低音）