コミットメッセージと言うものを5W1Hで捉えなおしてみる。

5W1H とは以下の６個をまとめたものです。

• What なにを
• Why なぜ
• When いつ
• Where どこで
• Who だれが
• How どのように

ニュース記事の慣行とか、情報伝達のポイントらしいです。

さて、gitなどソースコード管理システムでは、コミットにメッセージを残しながら開発を進めますが、これと5W1Hを並べて考えて見ました。

• When と Who は、管理システムが機械的に残してくれます。
• What と Where は、考え方次第なところがありますが、修正を入れる前のコミット（あるいはリビジョン）か、修正を入れる箇所（どのファイルの何行目）と考えられます。
• How は、修正前後の差分です。

以上のものは管理システムが機械的に残してくれますが、そうでないものがあります。 Why。これはシステムが機械的に残してはくれません。開発者が人力で頑張ってコミットメッセージで残す必要があります。これの書き方についてはいろいろな意見があるようですね。

個人的にはコミットを一覧で見る事が多いので、「何のために何を修正した」という体裁の一文にするようにしています。（ボリューム的にも一文で済む量に抑える。）「何のために」というのを毎回考えるのはちょっと頭の切り替えが必要だったりしますが、後々どうしてこうなったのかを調べたいときには有益なのかと。ちょっとした文言直しとか、CSSのデザイン修正だと単に「UI改善のため」とか簡単なものに割り切ることもあります。無理すぎたら諦めたりもします。（"fix typo" みたいな小さい修正とか。）

コミットでの修正内容とメッセージをわかりやすい形で残していく。コミット職人にでもなったような気分です。

別の話ですが、共有フォルダにExcel方眼紙で仕様を書いているところもあります。このやり方は5W1Hはまったくない世界ということになりますね。更新履歴を書くシートがあったり、古いファイルはコピーしてリネームというローカルルールもあったりしますが、どんなときでも全員守っている保証はありません。人力の使い所を間違えているのです。5W1Hを諦める前提なら良いかもしれませんね。（超短期間のうちに仕様検討をする。長期的な仕様書のメンテナンスはしない。とか？）