皆さんの会社には、ファイル名称の命名規約はありますか？
プロジェクトで仕事をするのが常態化してはや21年。プロジェクトでなくても、会議資料を複数人で手分けして作成する経験をお持ちのビジネスパーソンはきっと多いはず。そして、私と同じような疑問を持つ人も少なからずいらっしゃるのではないでしょうか。
はたして、Excelやパワーポイントのファイル名称に付けるべき日付は、「会議日」か、それともファイルの「作成日」のいずれか？
常に、会議のためだけに資料作成しているわけではなくて、誰かと情報を共有する場合や、上司に「ちょっとこれ数字調べておいてよ。できたらメール添付で送ってね」という場合のExcelによるワークシートを提出する場合もきっとあるはず。
そういう場合は、必ず会議日があるとは限らないので、会議日でない日付を付けたくなるかもしれません。メール送付日かな？
ええっと、面倒くさいから、ファイル名称なんていい加減でいい、という人は脇に置いといて、ここでは、どうしたら同僚や上司、時にはクライアントと卒ない感じで、ファイル共有できるのか、ファイル名称について、ちょっと語ってみたいと思います。
世の中には「構成管理」という考え方がありまして
IT系の人なら、誰しも、プログラミングをモジュールごとに手分けして分担し、並行作業で仕事を進める経験がおありだと思います。そして、テスターの人たちにテストをしてもらって、OKをもらったものから、システム本体のコードに加えることになります。
その時、バージョン1.0から分派して、自分の担当するモジュールの開発を行い、そのモジュールの開発が終わったら、どのバージョンの本体に戻すのかが大きな問題点となります。戻す際に、他の人が先にそれぞれの担当範囲を仕上げていて、最新版は、バージョン1.5になっているかもしれません。
にもかかわらず、あなたが自分の担当範囲のモジュールを、バージョン1.0に統合してしまったとしたら、最新バージョンのものが２つ同時に存在してしまいます。そして、それらは、どちらも完全体ではないのです。さあ、困った。。。^^;)
また、複数人で会議資料を作成している際に、みんなが、バージョン1.9に対して更新していっているのに、自分だけバージョン1.7をずっと更新していた場合で、自分が最後に印刷やクライアントにファイル送付をする担当になっていた時、よく確認しないで、バージョン1.7を配布や送付してしまい、仲間から非難を受けてしまうこともよくあることです。さあ、困った。。。^^;)
こういう事件が起こらないように、世の中には、「構成管理」という考え方があり、その考え方に則って、作成物のバージョン管理や、部分的な修正を複数人が同時に加えても、デグレ を起こさないよう、更新の食い違いが起きないようにふせいでくれるツール（ソフトウェア）が存在しています。
また、非構造化データを統合管理し、みんなで使いやすいようにしてくれるツールとして、ECM（Enterprise Content Management）という名称で、パッケージソフトが販売されていたりします。
ここで、非構造化データというのは、リレーショナル・データベースのような形で正規化されて、マスタとトランザクションみたいな形で蓄積やデータ処理されにくい、設計図や手順書のようなドキュメント一般をさすものと、ご理解ください。
専門のツールを使わないときはどうすればいいんだ？
前章では、あえて、特定のソフトウェアを紹介するサイトの表示を避けておきました。気になる方は、「構成管理」「ECM」「コンテンツマネジメント」で検索いただくと、山ほど、ソフトウェアを提案するサイトがでてきます。
最近流行りのグループウェアでもリッチな機能を持っているのですが、どの企業でもアクセスできるツールで、しかも追加コストがかからないとしたら、普通に、Windows の Office 製品（まあ、Google や Apple という人もいるかもしれませんが）でどうしたらよいか、知恵を探している人がまだまだ多いのではないかと思います。
その場合、①ファイルの命名規約と、②エクスプローラーのサブフォルダ分けルールの2つだけで、疑似的な構成管理を行うことができます。
ファイル命名規約
私がお勧めの形式は次の通り。
プロジェクト名_チーム名_ドキュメント名称_バージョン_作成日付.拡張子
です。
例えば、パワーポイントで、全社業務刷新プロジェクトにおける、管理会計チームが作成する会議資料ならば、
BPRPJ_管理会計_業務要件定義書_v1.05_20200324.pptx
という感じです。
ちなみに、「BPRPJ」は、Business process re-engineering project の略です。
ここで大事なのは、区切り文字に「アンダースコアー（アンスコ）」を用いていること、日付は必ずYYYYMMDDの8桁を使用すること。区切り文字は、ハイフン（-）でもいいかもしれません。8桁日付について、グローバルでは、米国式と英国式（欧州式）の流儀の違いがありますが、年月日いずれも分かるようにすることが肝要です。
自分が作った資料の寿命は、その資料を産んだ時点ではまだ不明です。資料は更新されることを前提に作るべきなので、日付はきちんと年まで入れるべきです。管理会計に限らず、営業や製造、開発部門でも、年を跨いだ案件や、前年比較をするはずです。いざというときに困らないように、年まで含めた時点管理を強く推奨します。
バージョンは、「1.05」とありますが、どういう場合にインクリメントするか、内部できちんとルール付けがなされている必要があります。
これは、私の管理するプロジェクトでの決まりなのですが、
1.00、2.00：正式に、承認機関（プロジェクトの場合はステアリング・コミッティー）に提出・共有・確認・承認された場合に、インクリメントさせます。
1.10、1.20：チーム内部の意思決定者（プロジェクトマネージャーやチームリーダーなど）に提出・共有・確認・承認された場合に、インクリメントさせます。小規模プロジェクトでは、次の下位レイヤーと統合させて、1.09→1.10→1.11 という運用でも問題ありません。厳密に3レイヤー制をとるなら、この場合は、1.09→1.010→1.011 となります。
ちょっと見難いですよね。慣れないと逆にここで間違う恐れがあります。ですので、通常は2レイヤー制をとります。しかし、ワンチーム内の承認段階が一つである場合に、資料のバージョンが0~9を超える数になってしまう場合、それは逆の意味で、その更新管理の品質は大丈夫かという疑問が生まれますが。。。
1.11、1.12：自分ではない第三者の目に触れるいかなる場合にでも、インクリメントさせます。特に、構成管理ツールを用いていない場合、バージョン管理は、ファイル物理名称でしか判断することができません。自分のPCのローカル環境で日を跨いで更新する場合はいいですが、一度でもメール添付や、ファイル共有環境にアップロードした場合は要注意です。その後、一旦第三者の目に触れた資料・ファイルがどのように使われるか保証の限りではないので、自分のローカルから旅立だったファイルは、必ず独立したバージョンを与えます。
おそらく、デグレを頻発させる事故は、この最後のレイヤーでそのほとんどが起きるといっても過言ではありません。
もう一度、例証して再確認します。
＜メールで共有・修正する場合＞
- 3/23（月）：自分のローカルPCで、v0.01を作成し、メール添付でAさんに送付する
- 3/24（火）：自分のローカルPCで、v0.01をいったんv0.02の名前で保存してからv0.02に対して修正をかける
- 3/25（水）：Aさんから、v0.01に対して、Aさんが手を加えたものが送り返される
- 3/26（木）：自分のローカルPCで、Aさんから送られてきたv0.01（修正後）と、自分が更新したv0.02の差分をチェックし、差分だけを反映したものをv0.03とする
- 3/27（金）：v0.03をファイル共有環境にアップロードして、チーム全員に公開する
＜ファイル共有環境で修正する場合＞
- 3/23（月）：自分のローカルPCで、v0.01を作成し、共有環境にアップロードする
- 3/24（火）：共有環境にあるv0.01をいったんv0.02の名前で保存してからv0.02に対して修正をかける
- 3/25（水）：Aさんは、共有環境にある最新版であるv0.02に対して、Aさんの作業分の更新をかける
- 3/26（木）：関係者全員にメールで通知したうえで、v0.02を自分のローカルPCへ、v0.03として保存し、これに自分の最終作業を加える
- 3/27（金）：v0.03をファイル共有環境にアップロードして、チーム全員に公開する
ご覧の通り、メール添付は使わない流儀の方が事故が起こる可能性を事前に少なくすると共に、作業が効率化されている（資料更新にかかる所要時間が短くなっている）ことが見て取れると思います。
特に、自分がローカル環境で行う、差分管理（自分の更新分とAさんの更新分の差分を確認し、両方が最新になるようにファイルを編集すること）のリスクと手間暇がとてつもなくコストがかかるやり方だと思いますが、如何でしょうか。
さて、制限文字数を軽くオーバーしてしまったので、②エクスプローラーのサブフォルダ分けルール については、次回説明することにします。
コメント