ファイル名は日付で始めよ

村田聡一郎(Soichiro Murata) 2010-12-09 17:48:00

さて、連載開始から2ヶ月、筆者の自己紹介的な話が続いてしまったが、そろそろ本題である「仕事を楽にするITお作法」についてもご紹介していきたい。

一般に「作法」とは、ひとことで言えば「自己流を排して、正しい所作をおこなうこと」であるが、あなたのチームで真っ先に実践していただきたい所作は、ファイル名の命名ルールである。

といっても難しいことではない。皆がファイル名の先頭に、年月日をYYMMDDと6ケタで入れる、ただそれだけだ。

たとえば、この原稿を下書きしているファイルの名前は、「101208_ZDnetブログ原稿.docx」。この先頭の数字6ケタこそが、ITお作法のまず第一歩である。 

◆ファイル名の先頭にYYMMDDで日付を入れている例◆

-----

■ファイルを「本質的な時系列」で並べる

あらゆる情報の分類軸/検索軸の中で、もっとも強力なのはタイムスタンプ、つまり年月日である。なにしろ日付は必ず「順番」に並んでおり、入れ替わったりはしない。4月2日の出来事は、4月1日の出来事より必ず後に起きている(笑)。

万人に共通の「絶対値」だ、という点も強力だ。誰にとっても4月1日は4月1日である。たとえば、顧客企業A社に提示した見積書が2つあり、ひとつは4月1日版(100401_見積書.doc)、もうひとつが4月2日版(100402_見積書.doc)だとしたら、確実に後者のほうが新しいはずだ。

情報を探すときにも、この情報は○年○月○日よりは必ず後に(あるいは前に)あるはずだ、ということは前後関係から明確に絞り込めることが多い。出来事はまさに「時系列」で起きているから、正確な日付はわからなくても、「あれはこの出来事よりは後である」ということは確実だ。

あたり前すぎることを言っているに過ぎないと感じられるかもしれない。

しかし、この「ファイル名の先頭に日付」を実践すれば、あなたのチームが使っている共有フォルダ内のすべてのファイルが、日付順に、時系列に並ぶことになる。やってみるとすぐにわかるが、これは非常に強力である。

まあ、ファイル整理に限らず、ビジネスでは日付はごく重要な意味を持つことが多いから、ファイル名もそれにならっているまでなのだが。

-----

この話をすると、まず反論されるのが、「Windowsにはファイルの最終更新日があるから、それでいいではないか?」というものだ。

確かに、ファイルの最終更新日はそれはそれで利用価値がある。とくに意識しなくても物理的に保存した年月日(さらには時分秒まで)を正確に記録してくれるのだから便利だ。しかしそこに落とし穴がある。「意識しない」からだ。

  • よくあるケースだが、共有フォルダにある数年前のファイルを誰かが直接開いて、うっかりCtrl+Sで上書き保存してしまったら?その瞬間に日付はたった今のものに変わってしまう。更新日順のソートで探しても、元あった「数年前」近辺にはもうないから、まず見つからなくなってしまう。
  • また、たとえば4月2日のセミナーで使うための資料の片方が3週間前に完成し、もう一つの資料は前日に出来上がったとすると?片方は3月12日、もうひとつは4月1日のところにある。この泣き別れはきっと解消されないだろう。
  • さらに、たとえばSharePointにアップロードされていたファイルをダウンロードすると、そのファイルの日付は元ファイルのもの(=本質的な最終更新日)でなく、今現在のものになってしまう。これではお話にならない。

非常に強力な絶対値であるはずのタイムスタンプだが、マシン任せにしている限り「アテにならない」、つまり使えない。Windowsが物理的、外形的につける「最終更新日」とは別に、そのファイルの内容が持つ「本来的な日付」を、ファイル作成者であるあなたが意識的につけることが必要なのである。 

■日付表記のバリエーション

・・・とここまで「日付を入れるのが正しい所作」だと力説してきたが、実は日付表記にはいくつかのバリエーションがありうる。

【Q1】年月日は8ケタで、YYYYMMDDと書くべきではないか?つまり20101208と書くのがよいのではないか?
【A1】チーム内で統一されていればどちらでも構いません。チーム内で統一されていないと、当然ながら日付順に並ばないので意味がない。

8ケタか6ケタか、だが、私は6ケタでよいと考えている。理由は単純で、8ケタ表記にした場合、少なくとも今後90年間、上2ケタは「20」に決まっているから、だ。たしかに、世紀の変わり目では8ケタのほうがよい。私のPCにも、古いファイルで98や99で始まるものがないわけではないし、それらは当然00より「後」に並んでしまうから、その点では不便だ。しかし今から始めるのであれば、それが次に問題になるのは90年後なのだから、気にしなくてもよいのではないか?

#昔懐かしい「2000年問題」もこうして起きたのかもしれない。しかしアプリケーションと違って、今のファイルは90年後にはアーカイブ価値しかないだろう。

【Q2】6ケタだと、年月日(YYMMDD)なのか月日年(MMDDYY)なのか日月年(DDMMYY)なのかわからないから、やはり8ケタで書くべきではないか?
【A2】これも同様、チーム内で「YYMMDDで統一する」と決めれば解決です。

たしかに、10/12/06と書いてあったら、アメリカでは06年10月12日と読むのが一般的だし、イギリス系の国では06年12月10日だと読むだろう。つまりアメリカでは一般にMMDDYYと書くし、イギリス系ではDDMMYYと書く。しかしこれも「一般的」であるというに過ぎない。アメリカへの入国審査書類(I-94W)ではDD/MM/YYと書くように指示されるのだから。

なおこの点でも、8ケタで書けばYYYYMMDDであると確実にわかるので、間違いの可能性が減る。とくに海外とのやりとりが多いチームなら、8ケタが適しているのかもしれない。また8ケタとなると区切り位置がパッと見て分かりにくくなる可能性もあるので、YYYYとMMDDの間にセパレーターを入れ、2010-1206とする、という手もある。

【Q3】弊社は年度を元号で、つまり「平成22年」で管理しているのですが?
【A3】悩ましいところだが、元号表記、つまり「221208」で統一することでよいと考えます。

社内で元号が主に通用している日本企業の場合、今年はあくまで「平成22年度」であって、「2010年度」ではない、ことが多いように思う。それならそれを無理に西暦に換算しなくてもいいと筆者は考える。とくに今年の話はともかく、数年前の話だと、たとえば「平成17年度」と言えばすぐにピンとくるが、これを西暦で呼ぼうとすると途端に換算が入って「えーと...2005年だったっけ?」となってしまうケースが多いように思う。それなら、チーム内の誰でもすぐにピンとくる呼称にしたほうがよい。

【Q4】時差のある海外とやりとりするときに不便なのではないか?
【A4】これもチーム内で、あるいはやりとりをする相手と、統一していればよいでしょう。

たしかに、時差が開いている相手(典型的には日米間)でやりとりをするときには、日付が1日ずれる可能性がある。真珠湾攻撃が日本では12月8日とされているのに対し、アメリカでは12月7日の出来事であるのがその例だ。たとえば日本時間4月2日に締結された契約書は、米国側では4月1日のものと認識されるだろう。これもどちらかに統一しておく必要があるだろう。

【Q5】日付のあとに入れるのはアンダースコアがよいのか?ハイフンか?空白か?
【A5】どれでもよいですが、システムによっては考慮する必要があるかもしれません。

英語の感覚でいえば、一番普通なのは半角スペース。だが古いファイルシステムでは半角スペースを扱えなかったため、伝統的にファイル名では半角スペースを避けるようにしている人が多い。したがってファイル名で使うセパレーターとしてはアンダースコアがもっとも一般的であるように思う。筆者も習慣的にアンダースコアを使っている。

ただし、いくつかの検索エンジン、たとえばSharePoint 2007では、アンダースコアの前後に英数字が入るとそれをブレークせず1ワードとして扱ってしまう仕様のようだ。たとえば「101208_ZDnetブログ原稿.docx」というファイル名だと、101208_ZDnet までが1ワード扱いとなるため、「101208」や「ZDnet」で検索してもヒットしない。

いかがなものかと思う仕様だが、とりあえずこれではかなり不便なので、SharePoint2007ユーザーの場合にはアンダースコアのかわりにハイフンを使い101208-ZDnetとする、という選択肢もありうる。(ハイフンの場合は前後とも英数字であってもブレークされる。)

英語の語感としては、複数語を複数語のままで扱いたい場合のセパレーターはアンダースコア、逆に1ワードとして扱いたい場合はハイフン、というのが一般的なので、SharePointの仕様は真逆のような気がするのだが... なお同じMS製品でも、SQLサーバーのフルテキストサーチやWindowsファイルシステムはハイフンでもアンダーバーでもワードブレークする。

【Q6】日付とあまり関係ないファイルはどうしたらよいですか?
【A6】本質的に時系列整理する意味がないものなら、無理にファイル名に日付を入れる必要はないです。

典型例は画像ファイル。たとえば会社のロゴ画像、logo.jpeg とかいうファイルに日付を入れたら、かえっておかしいかもしれない。

ただしその場合でも、ロゴをいろいろ検討していて、毎日バージョンアップしているようなケースなら、101208_logo.jpeg にしたほうがいいかもしれない。つまりあくまで「本質的に日付で管理するのが合理的か」で判断すればよい。

-----

こうしてみると、日付そのものはたしかに時系列であり絶対値だが、その表記の仕方にはバリエーションがあることがわかる。さらに上記【A5】のように、使用しているシステムの仕様に依存して変えなくてはならないとかでは、お作法と呼ぶには心もとない。この点はメーカーにぜひ改善を求めたいものだ。

しかし、これがファイル名に年月日を入れるという習慣が根付いていない理由だろうか?筆者はそうは思わない。チーム単位あるいは企業単位で考えれば、ファイルの圧倒的多数はひとつの表記体系に統一できるはずだからだ。

習慣が根付いていないのは単に「そうせよ」と言われたことがないから、だろう。つまりお作法の指導がされていなかっただけだ。

一見、面倒に感じるのもわかるが、まずは自分のチームで始めてみてほしい。効果はすぐに表れる。

⇒12月10日 筆者追記: 多くの方から、「バージョン管理はどうするべきなのか?」というコメントをいただいた。ご指摘どおりで、実際にはこの「ファイル名」は「バージョン管理」の話と切り離せないところがある。今回は長さの都合で日付のみを取り上げているので、急ぎバージョン管理についてもご説明したいと思う。少々お待ちください。ご指摘いただいた皆様に感謝申し上げます。今後ともよろしくお願いいたします。

村田聡一郎リアルコム お問い合わせはこちら
(■Twitter始めました。よろしければフォローお願いします

 

※このエントリはZDNetブロガーにより投稿されたものです。朝日インタラクティブ および ZDNet編集部の見解・意向を示すものではありません。

5件のコメント
  • takuticle

    「なんの日付なのか」が定義できないので結局管理がグチャグチャになっていくような...

    私は普段、すべての資料がSubversionかGitで管理され、それぞれのコミットリビジョンがITSのチケットに結びつくように管理された職場にいるので、
    その場合は、ファイル名に「そのファイルがどういうものであるかの要約」以外の情報を含めると利便性が低下してしまう、という事がよくあります。

    単純な共有フォルダでファイル管理する場合、日付はフォルダ名に入れて、関連ファイルはそのフォルダ配下で管理、ファイルは常に最新版、などとやることも多いです。

    2015年09月02日

  • np

    いい記事です。
    私もファイル名の先頭を日付にする記名法を採用していて、これがベストと感じています。

    下記、YAMAさんの疑問ですが、このような場合も私は、先頭に「作成日」をつけています。
    ただし、「作成日」とともに、「プロジェクト名の文字列を入れる」ルールを採用することが大切です。

    たとえば、「2012年04月02日に開催されるZD小学校の同窓会幹事を任された」というプロジェクトにおいて、作らなければいけない一つの資料が「出席者名簿」、もう一つの資料は「校歌の歌詞カード」だとします。
    このプロジェクトはたとえば「ZD小同窓会(120402開催)」と名づけます。そして、ファイル名に必ず入れるようにします。複数人で運用する場合は、そのことを共有します(昔の同級生だとPCへの知識レベルに差があって難しいですが、会社の同僚では比較的楽ですね)。

    日が近づくにつれ、出席者名簿は何度も修正が入ります。ただし修正があっても、上書き保存はせず、日付だけ替えて新たなファイル名で保存していきます。以下のようにいくつものファイルが作られることになりますが、結局はそれぞれ一番最近の日付のファイルを参照し、修正を重ねていけばいいのです。

    120312_ZD小同窓会(120402開催)_歌詞カード.doc
    120312_ZD小同窓会(120402開催)_出席者名簿.xls
    120324_ZD小同窓会(120402開催)_出席者名簿.xls
    120401_ZD小同窓会(120402開催)_出席者名簿.xls

    なお、ファイル名に「完成版」「当日版」「提出版」といった文字列を入れることに、私は賛成できません。ぐちゃぐちゃのつくりかけのものから、他人に発表したものまで、日付以外は同じファイル名にすべきと思います。なぜならば、「完成した!」と思っても、その後、その書類を直したくなるケースはしばしばしばしばあるからです(笑)。

    2011年07月29日

  •  

    いやいや。
    更新日時じゃなくて作成日時でもソートできる。
    そもそも、こういう記事で述べるべきなのは、”方法”よりも、”目的”や”結果”だろ。
    チーム内で取り決めするという前提なら、ファイル名がどうの、という以前に、”話しあって”ルールを決めるべきだ。多機能なファイル管理ツールはいくらでもある。

    >効果はすぐに表れる。
    「騙されたと思ってやってみろ」的な文句ほど説得力がないことを知っていてほしいな。
    記事の半分以上を使ってまで”6桁が云々”などと持論をグダグダ書く必要はない。

    2010年12月13日

  • 村田聡一郎

    Yamaさん、ご質問ありがとうございます。

    > 質問です。
    > >たとえば4月2日のセミナーで使うための資料の片方が3週間前に完成し、
    > >もう一つの資料は前日に出来上がったとすると?
    > >片方は3月12日、もうひとつは4月1日のところにある。
    >
    > この場合、作成日を頭につけると、片方は100312_となり、もう一方は100401_となるので、
    > やはり永遠に泣き別れになると思います。
    > これを避けるためには、頭の日付は作成日ではなく、利用する日を入れるべきでしょうか?
    > その場合はバージョン管理はどうすればよいでしょうか?(末尾に日付を入れる?)

    はい、おっしゃる通りです。説明不足ですみません。(バージョン管理はまた後日のネタにと思っていたのですが(笑))

    まず頭の日付は、作成日でなく、「そのファイルの内容が持つ「本来的な日付」」を入れます。
    ですので上記の例では、どちらも初めから100402_です。「4月2日のセミナー資料ですよ」ということですね。

    -----

    ※ただこれも、現実には、いつも一発で決まるというわけではありません。

    たとえば、「4月2日に行うセミナー」の講演資料のドラフトをもって主催者と打ち合わせをするのが3月31日であるとすると、その資料は

      「100331_4月2日セミナー資料ドラフト.pptx」

    とかになるかもしれません。で、打ち合わせの結果、内容が確定したら、

      「100402_4月2日セミナー資料(完成版).pptx」

    となる、と。(この場合、前者の資料はあくまで「3月31日の打ち合わせ用のドラフト」という意識で作っているので、実際にはあまり違和感ないはずです。)

    ただこれとは逆に、たとえば

      「100402_4月2日セミナー資料ドラフト(3月31日版).pptx」

    という名称にしたい、という方もきっといらっしゃるはずです。これはこれでスジは通っているので、私はどちらも可だと思います。

    2010年12月09日

  • YAMA

    質問です。
    >たとえば4月2日のセミナーで使うための資料の片方が3週間前に完成し、
    >もう一つの資料は前日に出来上がったとすると?
    >片方は3月12日、もうひとつは4月1日のところにある。

    この場合、作成日を頭につけると、片方は100312_となり、もう一方は100401_となるので、
    やはり永遠に泣き別れになると思います。
    これを避けるためには、頭の日付は作成日ではなく、利用する日を入れるべきでしょうか?
    その場合はバージョン管理はどうすればよいでしょうか?(末尾に日付を入れる?)

    2010年12月09日

このサイトでは、利用状況の把握や広告配信などのために、Cookieなどを使用してアクセスデータを取得・利用しています。 これ以降ページを遷移した場合、Cookieなどの設定や使用に同意したことになります。
Cookieなどの設定や使用の詳細、オプトアウトについては詳細をご覧ください。
[ 閉じる ]