今日もお疲れ様です。
前回は、故障したキーボードをメーカー保証で交換してもらったときの体験をブログ記事にまとめました。
「保証って本当に使えるの？」
「交換までどれくらい時間がかかるの？」
そんな疑問をお持ちの方は、ぜひこちらもご覧ください。
👉 【実録】Logicool K855がチャタリング。元社内SEがメーカー保証で新品交換を受けるまでの5日間
今回は、プログラムを書いたことがある人なら、一度は経験したことがあるかもしれない「あるある話」です。
「……これ、何してるんや？」
コードを開いて、最初に出てきた言葉がこれでした。
きっかけは、プログラムの再調整依頼です。
「ここ、少し仕様を変えたいんですが対応できますか？」と言われて対象のコードを開いた瞬間、思い出しました。
「……あ、これ自分で作ったやつや。」しかも、結構最近作ったプログラムです。
それなのに数秒後には、「……これ、何してるんや？」となっていました。
よく「昔書いたプログラムだから忘れる」と思われますが、実際はそんなこともありません。
プログラムを書けば書くほど、自分のコードは増えていきます。
その結果、数か月前の自分でも普通に”他人”になります。
コメントとは何か
プログラムにはコメントという機能があります。
簡単に言えば、「なぜこの処理を書いたのか」を未来に残すためのメモです。
コードを見れば処理の流れはある程度分かります。
でも、「なぜそうしたのか」という意図まではコードだけでは残りません。
その意図を残すのがコメントの役割です。
分かっていても後回しになるコメント
ただ、このコメント。
現場では意外と後回しになりがちです。
コメントを書かなくても、プログラムは動きます。
納期が迫っていたり、急ぎの修正だったりすると、「まずは動かそう。」という気持ちがどうしても優先になります。
その場では、それが正しい判断だったのかもしれません。
でも数か月後。
そのプログラムを修正することになった自分が、「……これ、何してるんや？」と言いながらコードを読み返すことになります。
未来の自分からすると、「その数分を惜しまんといてくれ。」と言いたくなります。
過去の自分をほめたくなる時と、殴りたくなる時
プログラムを保守していると、よく思います。
過去の自分をほめたくなる時と、殴りたくなる時がある。
ほめたくなる時
コメントが残っているときです。
- 「ああ、この分岐はこのケースのためか。」
- 「この処理はこの不具合対策だったんだ。」
少しずつ当時の考え方が見えてきます。
特に助かったのは、複雑なSQLです。
SQLは読めます。
でも、
- 「なぜこのJOINをしているのか。」
- 「なぜこの条件が必要なのか。」
こうした意図は、コメントがないと分かりません。
コメントが残っているだけで、改修作業が驚くほど早く終わることもありました。
殴りたくなる時
逆にコメントが何もないと、本当に大変です。
コードを一つずつ追い、仕様を推測し、動作確認を繰り返す。
コードは読めます。
仕様も時間をかければ何とか理解できます。
でも、本当に困るのはその後です。
修正するときです。
保守で一番怖いのは「修正後」
修正前は、少なくとも安定して動いています。
だから安心できます。
でも、一度コードを書き換えると、修正後に何が起きるのかが本当に分かりません。
- 「ここを書き換えて本当に大丈夫か。」
- 「別の処理まで壊さないか。」
そんなことを考えながら、一つひとつ慎重に修正していきます。
コメントがあれば、「この処理はこういう意図だった。」と判断できます。
逆に何もないと、
- 「これは過去の不具合対策なのか。」
- 「たまたまこう書いただけなのか。」
その判断ができません。
さらに、修正した箇所ではなく、2〜3行前の処理を見落としてエラーになることもあります。
プログラムは、一行だけを見ればいいものではありません。
前後の流れや条件まで理解して初めて、安全に修正できます。
コードは読める。
でも、意図が分からない。これが一番怖いんです。
コメントがないと修正が難しい理由
コメントがない状態での修正は、
まず理解することから始まります。
コードを読めば、「何をしているか」はある程度分かります。
でも、「なぜそうしているのか」は分かりません。
例えば、
- 過去の不具合対応
- 特定の条件を回避するための処理
- 将来の拡張を見越した処理
こういった背景はコードだけでは残りません。
そして一番怖いのが、「理解したつもり」で修正すること。
表面的には分かっていても、前提や意図を理解していないと、少しの変更で簡単にバグが発生します。
「え、なんで？」となるのは、保守ではよくある話です。
プログラムの規模によっては、理解するだけで一日終わってしまうこともあります。
修正作業は30分で終わるのに、理解するために半日、一日かかる。
そんなことも珍しくありません。
頭では分かっていても
コメントが大切なのは分かっています。
実際、コメントが残っていると改修は本当に楽です。
私自身、コメントを書くときは、
- 修正した日付
- まとまりごとの処理内容
- なぜこの処理を書いたのか
を残すようにしていました。
でも、忙しくなると後回しになってしまいます。
急ぎの修正だったり、
障害対応だったり。
まずは動かすことが優先になります。
そして正直に言うと、「このプログラムにコメントだけ付けておいて。」と言われると、あまり気が進みません。
コメントを書くためには、もう一度コードを読み返し、処理を整理し、意図を思い出さなければならないからです。
つまり、コメントを書くために、もう一度保守作業をすることになります。
これが結構大変なんです。
もちろん、一度やり始めると最後までやります。
処理を追いながら、「ああ、このためだったな。」と思い出していくうちに、気が付けば全部終わっています。
でも、その最初の一歩が重い。
だから私は、後からまとめて書くより、その場で一行でも残す方が圧倒的に楽だと思っています。
結局、未来の自分を助けるのは今の自分
よく、「他人が書いたコードは読めない。」と言います。
でも私は、昔の自分も十分他人だと思っています。
数か月前の自分でも、何を書いたのか忘れていることがあります。
だからコメントは、他人のためだけではありません。
未来の自分への引き継ぎでもあります。
もちろん、「今でも毎回ちゃんとコメントを書けているのか。」と聞かれれば、胸を張って「はい」とは言えません。
それでも、一行だけでも残しておけば、未来の自分は少しだけ楽になります。
プログラムを書く時間は限られています。
だからこそ、未来の自分が安心して修正できるように、そのとき考えていたことを少しだけ残しておく。
その数行のコメントが、数か月後、あるいは数年後の自分を助けてくれるのかもしれません。
▼ 関連記事（おすすめ）
プログラムは「書くこと」よりも、「安全に修正すること」の方が難しい場面が多くあります。
今回の記事とあわせて、こちらの記事もぜひご覧ください。
👉 【元社内SE実録】「確認してください」では解決しない。誤配送を減らすため、送り状をバーコード対応にした話
👉 【元社内SE実録】正論だけではハンコはもらえない｜私が徹底した「事前相談」の仕事術
次回予告
次回は、多くの会社でバタバタしがちな「期末・期初」の時期についてお話しします。
実は、社内SEもこの時期は普段以上に慌ただしく動いています。
普段あまり知られることのない、社内SEの裏側を実体験を交えながらご紹介しますので、ぜひご覧ください。
👉 【元社内SE実録】期末・期初は何をしている？忙しい理由と実際の業務を紹介
「もしこの記事が役に立ったと感じたら、SNSでシェアしていただけると嬉しいです！」
その際、インスタグラムやX（Twitter）で**「フォロー」や「シェア」**してもらえると、次の記事を書く大きな励みになります！
他にもSEの裏話や便利なガジェットやちょっと一息つけるようなコラムも用意していますので、ぜひご覧ください。
コメント