こんにちは！深夜のテンションで勢いで書いたコードを3ヶ月後に読み返して、「この処理、一体何のためにやってるの？」と頭を抱えて絶望した経験はありませんか？
私はあります。しかも、犯人は過去の自分。あの時の自分を問い詰めたい気分になりますよね。
結論から言うと、コードは「何をしているか（How）」ではなく「なぜそうしたか（Why）」をコメントに残すだけで、未来の自分を劇的に救うことができます。
プログラム自体はコードを読めば何をしているか分かりますが、「なぜその手法を選んだか」という意図は、時間が経てば必ず忘れてしまうからです。
今回は、未来の自分（という名の他人）を絶望させない、読みやすく、かつ感謝されるコメントの書き方について、現場で使えるテクニックを解説します。
これを読み終える頃には、あなたの書くコードは「未来のあなたへの思いやり」に溢れたものになっているはずです。
🗑️「当たり前のこと」を説明するな！まずは引き算の美学
多くの人がやりがちな失敗は、コードをそのまま日本語に翻訳してしまうことです。
例えば、`i++ // iをインクリメントする` とか、`user.name = "田中"; // 名前を田中に入れる` といったコメント。これ、本当に必要でしょうか？
コードを見れば誰でも分かることをコメントに書くと、視覚的なノイズが増えるだけで、本当に重要な情報が埋もれてしまいます。
コメントは「コードから読み取れない情報を補完するもの」です。自明な処理へのコメントは、今すぐ削除ボタンを押しましょう。
そもそも、「コメントがないと何をしているか分からない」というコードであれば、コメントを書く前に「変数名や関数名を改善する」ことが先決です。
良いコードは、コメントがなくても流れるように読めるものです。まずはコードの構造を美しく整えることから始めましょう。
🤔「なぜ」を残すのが最強の防衛策
未来の自分を一番困らせるのは、「なぜこんな変な実装にしたんだ？」という、一見すると非効率に見える処理です。
例えば、APIの仕様が特殊だったり、ライブラリのバグを回避するために泥臭いコードを書いていたりする場合です。
こういう時こそ、「ここはAPI側のレスポンスが壊れているため、手動でパースしている」や「〇〇ライブラリの既知のバグを避けるための暫定措置」と書いておくのです。
この「背景」さえあれば、3ヶ月後のあなたは「ああ、ここは直さなくていいんだな」と瞬時に判断できます。
逆にこのコメントがないと、あなたは「え、なんでこんなコードになってるの？直してやる！」とリファクタリングを始め、結果としてバグを生み出すことになります。
「なぜ（Why）」をコメントに書くことは、未来のあなたが罠を踏まないための「警告看板」を立てるのと同じなのです。
📝未来の自分へのラブレターとして書く
コメントを書くときは、「今の自分が、3ヶ月後の自分に引き継ぎメモを残す」と考えてみてください。
「あー、ここ分かりにくいよね。ごめんね！」という気持ちで、ちょっとした補足や、「ここは〇〇という記事を参考にした」というリンクを貼っておくのも有効です。
特に複雑なアルゴリズムや、特定の条件下でしか動かない難解なロジックには、ドキュメントコメント（Docstringなど）を活用しましょう。
「何を入力して、何が返ってくるのか」を定義しておくだけで、開発効率は劇的に変わります。
コードは、ただコンピュータを動かすための命令文ではなく、人間とのコミュニケーションツールです。
あなたのコードを次に読むのは、あなた自身かもしれませんし、もしかしたら他の誰かかもしれません。その時、あなたのコメントが誰かの救いになるのです。
まとめ：未来の自分は、自分自身しか救えない
コメントは、未来の自分へのラブレターであり、チームメイトへの贈り物です。
3ヶ月後のあなたが、過去の自分の書いたコードを読んで「よし、分かりやすいぞ！」とニヤリと笑ってくれる未来を想像してみてください。
コードの行数が増えることを恐れる必要はありません。意味のないコードを100行書くよりも、深い意図が伝わるコメントを1行残す方が、ずっと価値があります。
今日からあなたのコードに、未来の自分への「思いやり」を少しだけ書き添えてみませんか？
きっと、半年後のあなたは「あの時の自分、GJ！」と感謝しているはずですよ！