March 13, 2007
「先祖返り」ってご存じでしょうか？
せっかく作っていたデータを、古い日付のもので上書きしてしまい、古い状態に戻してしまうことを言います。
よくWeb制作で起きがちで、複数人で一つのフォルダのソースをいじくっていたり、不注意な人がざっくり古いファイルを上書きしてしまったりすることでおきます。特に忙しい納期直前ほど起きる現象です。
不注意な人のやることと言ってしまえばそれまでですが、人は必ずミスをするものです。
不注意な人のミスをいかになくすか？というのが、世の中の生産管理の肝と考えれば、単純にソースコードの管理手法がなっていないと考える方が僕は自然だと思います。
世の中には、バージョン管理システムという名前で、CVSとかSubversionとか便利なシステムがあるのですが、これがちょっと難しい。何が難しいというと、まず用語が難しい。コミットだのチェックアウトだの聞き慣れないキーワードがついていてとっつきにくくて、そこからバージョン管理システムを使う気が起きなくて変えられないという人はいると思います。僕もそうでした。
ということで、CVSやSVNを使いたいと思いつつも腰が重いあなたに、それなら最低限これやっといた方が良いですよという書き込みです。先祖返りが一番起きる可能性が高いWebの制作行程をターゲットにしてみたいと思います。
■そもそも先祖返りを呼び寄せるデータ管理手法とは？
（１）一つのフォルダをみんなでいじくる。
特にHTMLはリンクがあってファイル間の関係が複雑なので、開発のようにいじるソースコードのエリアを分担するというのが結構難しいように思えます。（commonとか、CSSとか）なので、一つのフォルダをいじくるのは結構仕方ないかなと思うので、Webの制作においては、そもそも先祖返りがおきやすい環境であることを認識した方が良いです。
無理矢理フォルダを分担してしまって、制作中に沢山のデッドリンクを放置するのも無駄だと思うし、マージするときの先祖返りの危険性を考えると、ただ分ければ良いってものでもないと思います。
（２）ローカルで作って最新の反映をするためにフォルダ丸ごと上書きをする行程がある。
外の人にお願いしたりするケースでは必ずありうるのではないでしょうか？
上書きしちゃいけないデータを上書きするタイミング、ナンバー１って感じですね。
上書きは、そもそも危険だということを認識すべし。
後述するファイル差分ツールを使って、必ず上書きして良いか確認しましょう。
上書きされる側のバックアップも重要です。
（３）PSDやFlaファイルを作るときに、○○_new.flaなどというファイル名もしくは、○○_2.flaというファイル名をつける。
なんとか_newなどという相対的なファイル名はつけてはいけません。100%何に対してのnewかがわからなくなります。
Flashファイルなどで_newという名前をつけたくなるファイル名は、結構、忙しい時にテストなどで使う試作のデータだったりもします。そういうデータがフォルダに残ってしまうと最悪。結局、古い方が本流のファイルになって、タイムスタンプが更新され、_newは何に対してのnewかわからぬまま誰も消せなくなります。3ヶ月もたてば作った本人も何のnewかは覚えていません。
じゃぁ日付なら良いだろうと、○○_0313.flaなどとつけるのも危険です。まず、1年経ったらこのファイル名は新旧がわからなくなります。うかつに保存して更新日付を最新にしてしまったら、もはや何がなんだかわかりません。
しかも、何のファイル名のポリシーもない場合は、何故か最初は、○○_newとつき、さらにnewのnewを作りたくなった時に、○○_new0313などと非論理的な枝番がつくことがあります。これも結局、どっちが本当のnewかがわからなくなる原因です。どうしてもやりたいなら○○_new_newとしてもらった方がわかりやすいですね。
また場合によってですが、日付によるファイル名は、「前後のバージョンのファイルがあるのかないのか」がわからなくなります。仕様書のリビジョン管理などでは気にした方が良いかもしれません。
（４）ゴミデータを残してしまう。
そここそ○○_temp.htmlとか○○_new.htmlなどという使われないファイルが、納品すべき本番のファイルの横にあるのは、間違えて消してしまう原因です。
ゴミはその場で整理整頓。整理整頓したくなる環境を作ることが大事です。
製造業時代、先輩から「良い仕事をするには整理整頓からだよ」って言われた物です。
こういう名前のファイルを作りたくなるのは、ずばりソースコードの管理ができていないからです。こういうことをしなくても元ファイル名のまま古いデータを残しておけるようにすることがソースコード管理では重要なことと言えます。
■先祖返りを起こさないデータ管理手法とは？
（１）ソースコードが入ってるフォルダのに年月日をつける。
そのサイトデータが入っているルートのフォルダ名に「○○○○_20070313」という年月日をつけましょう。
（２）このフォルダを毎日コピーして全部のサイトデータコピーを毎日作っていく。
朝、ディレクターの人が出社したら、今日の分として昨日のサイトフォルダをコピーして増やしましょう。フォルダ名は今日の日付がつきます。もし、そこにあるフォルダが最新と言い切れる運用ならば、最新のデータは固定のフォルダ名でも構いません。（プレビュー用にバーチャルホストを切ってる場合なども）
いずれにせよ可能な限りのコピーを作っておくことで、古いファイルに戻したくなったら、1日前や２日前のフォルダからコピーしてくれば良いのです。
先祖返りをやりそうな人に限って、何故かこういうところが貧乏性というか几帳面だったりして、同じようなフォルダが増えていくのを嫌う人がいるんですが、「消しちゃうよりマシ」です。
コピーされた昨日の日付のフォルダは、もういじってはいけません。それは昨日までの作業ファイルなのです。過去の物なのです。
なので、oldというフォルダを作ってコピーが終わった古いフォルダを毎朝そこに移動してしまいましょう。万が一、HDDの容量がなくなったら、oldフォルダを丸ごと消してしまえば良いだけのことですし、oldと書いてあることで編集してはいけないことがわかります。（「new」ではなく「old」であることが重要）
もし、それでも古いフォルダをいじりそうなうっかり者がいるなら、古いフォルダをアーカイブしてしまうのも手です。
この管理手法に慣れると、oldフォルダを丸ごと消して大事なファイルが消えたらどうしよう、などと削除することが結構怖くなります。
そう思うようになることが、先祖返りを防ぐ重要な気持ちの持ち方です。
本番にリリースするとか、お客様のプレビューの直前には、何かそれとわかる目印をフォルダ名につけておくと良いですね。こういうクセをつけておくと後で役に立ちます。
（３）古いフォルダとの差分を意識する。
あなたのプロジェクトフォルダは、初回リリースのソースコードを再現できますか？
例えばアップロードした後で、10日前の状態に戻してよと言われて、正しく戻せますか？
以前、クライアントの意向で、古いバージョンの方が良いと言われて、以前のバージョンに戻すために再度、制作作業をするという寒いケースを見たことがあります。まともなソースコード管理をしていないからこそ起きる現象です。
また、リリースしてから、これは出してはいけない情報だった。
もしくは、来週リリースする新製品情報を先にリリースしてしまった。
これらは全てソースコード管理ができていないのが原因です。
日付によるフォルダ名とバックアップができていることが前提で、これからアップするデータが本当に今アップして良い物なのか？を認識するために差分管理ツールを使いましょう。
Macに入れたい７つのWindowsソフトでも紹介した、DF.exeをオススメします。
上の写真は、２つのソースコードをドラッグしたときの表示です。ソースコードで同じ場所は白くなり、違う場所は色が変わります。
これにより一目で、二つのソースコードの違うところがわかります。
フォルダ毎の比較にも対応しているので、一ヶ月前のフォルダと、今日のフォルダをdf.exeにドラッグすると、何のファイルが更新されているのかが一目でわかります。ファイルの中身で比較するので、例えば何も変更しないのに保存してタイムスタンプだけが更新されたファイルが変わっていないこともすぐにわかります。
これで効率的に更新された部分だけを確認し、リリースして良いものかを確認するクセをつけましょう。本番環境は、あなたの身勝手な行動で汚染させてはいけない神聖な場所なのです。
時より、本番からデータをダウンロードしてきて、制作環境と比較してみましょう。思わぬアップし忘れが発覚するかも？！
（４）flaファイルやpsdもバージョン管理しましょう。
元データと呼ばれるフォトショップのpsdや、Flashのflaファイルなどは、バージョン管理システムなどを使っても忘れられがちなデータです。何故なら置き場所が違うケースが多いから。こういうデータは仕様書と同じようなところに置いてしまい、バージョンがわからなくなる筆頭です。
出力されたswfやjpegは正しく管理されているのに、元ファイルが何が何だかわからないというのは何の意味もありません。
flaやpsdは、○○○_20070313.flaなどとしておくのも良いですが、もしwikiなどを利用してリリース管理をするなら、バージョン名で管理した方が便利です。
例えば、○○○○_ver0.1.flaなどとしましょう。
なお、リリース時をバージョン１にしたいので、初期値は0.1とか0.01から始めましょう。これは某一部上場のSIさんから教わりました。
仕様書は0.01から書き始め、お客様のレビュー毎に0.1ずつ増やしていく。これによってどういう行程のファイルかが一発でわかるという次第。正式リリース版で、バージョン1.0にリネームする。以降のメンテではまた同じようにして次回のメジャーリリースでは2.0などと行った具合です。
■まとめ
これらの作業を人手で正しくやれるようにしましょう。
この方法は、ソースコードを管理する「たった一人の作業」でカバーすることができます。他の作業者は最新のフォルダを使うだけで、特に運用ルールを意識する必要はありません。
大事なのは意識の問題で、フォルダを日付で管理し、差分を意識することを覚えると、むやみに上書きするような行為が段々怖くなってきます。
リリースするときに、本当に必要なファイルだけをアップロードすることを心がけ始めたら最高です。
SVNなどのバージョン管理システムの導入は、これらの運用ができてからでも遅くはありません。
バージョン管理システムを使っても、ゴミファイルを作って、むやみやたらにコミットするのは避けたいのです。
例えば、なんとか.php.bakなど、うっかり拡張子を変えたファイルをバージョン管理システムに登録してしまい、他の誰かがうっかりリリースしてしまったとしたら、それがきっかけでセキュリティホールにもなりかねません。結局、バージョン管理システムを使っても、ファイルの管理意識が高いことは求められるのです。
とまぁ僕的ソースコード管理手法を書いてみました。僕はソースコードはSVNとかCVSで管理し、Flash や仕様書のようなデータをここで書いた手法で管理しています。近いうちに全部SVNに移行しようかなと思っていますが、既存の管理領域との絡みで、なかなか面倒なことが多いです。
バージョン管理システムに移行するのは、運用ルールが変わるので精神的に結構大変な作業です。せめてそれまでのタイミングまででも、少しでも先祖返りのリスクを防ぐことを思っていただければ幸いです。
もし、みなさんが実践されてる良い方法があったら是非コメントなどででも教えてください。
##あえて書きませんでしたが、これはバージョン管理システムがやってることを、人手でやるにはどうしたらいいの？というのと同じことであったりもします。
##というか長文すぎて多分、読まれてない(w
##「今日から使えるバージョン管理手法」とタイトルをつけるべきだったかも。