OfficeファイルもRepository & Ticketベースで

ファイルがたくさんある

以前から思っていたのですが、ファイルベースの情報の管理というのは難しいです。ファイルという単位で扱えるものはしょせん1アプリケーションが表現可能なものに制限され、人間の脳内の活動をアウトプットするには非力すぎるからです。

なんて小難しいことが言いたいわけではなく、例えば Web を考えてみれば分かりますが、HTML をテキストファイルで、画像はそれぞれ画像フォーマットで表現します。画像が2つある文書を作ったらその時点でファイルは3つになってしまいます。

さらに画像は今のところ基本的にラスタ画像（PNG, GIF, JPEG）として表現する必要があり、「元画像」や「素材」と呼び分けたベクタ画像（AI, SVG などの XML形式）を別に保存しておく必要があったりします。同じラスタ画像でもより高解像度の画像を素材として残しておく場合もあります。

日付付きファイル名管理の限界

上のような特徴は HTML の場合に特に顕著ですが、Office 系の情報でも似たような状況にはなり得ます。

• Word の提案文書
• Excel の添付資料（比較資料や見積もりなど）
• 製品のマニュアル PDF や関連情報の Web サイトのスクリーンショット

こういった構成の「資料」をやりとりすることは非常にありふれた話だと思います。そしてこれらの情報にはいわゆる「先方」の要望の変化や思い違い、あるいは単純なミスなどから細かく修正、訂正が入ります。つまり、Office 系のファイルでも

• 意外に素材がある
• 意外に変更が多い
• 最終的には1ファイルではなく、セットが管理できないといけない

わけです。

私は以前からファイル名の頭にはほぼ必ず日付を入れて

20100601-hogehoge.xls

のようなファイルを作るようにしているのですが、複数のファイルを扱う場合、素材や、修正を加えた別バージョンと日付がずれていってしまい、頼りの日付の部分が返ってややこしいという問題が起きます。

もっとも、それだけであれば作業の開始日、あるいは締め切りの日付をフォルダ名に加えて、その中でファイルを管理することで回避することも可能です。素材が使い回しだったら単純にコピーでフォルダの中に持ってきても構いません。

共同管理が事態をややこしくする

いわゆる会社というところでこれらのファイルを扱っている場合、

共同編集はしなくても複数人で扱うことが多く、共有コストもバカにならない

という別の問題も発生します。例えば

といった組み合わせで同じファイルに複数の人間が絡むことはよくあります。そしてファイルの共有方法が

• 共有フォルダ
• メールの添付ファイル

などになっており、

オリジナルの管理が難しい

といった事態を生むわけです。一人の作業としてもファイルがバラついて面倒なのにこれを共同管理するなんて考えただけでうんざりです。

共同管理なら Google Docs はどうなの？

• 素材を含めての管理となると決して使いやすくはない
• 最終的にはきれいな「印刷物」も大事
  • 印刷関連機能の充実したローカルアプリの重要性は減らない
• ファイル管理の話にアカウント管理の話が加わってしまう

個人的には OOo を使うよりは Google Docs の方がひょっとして軽くていいかも、という気もするのですが、関わる人みんなを Google Docs に連れてくるのが大変だったり、アカウント管理どうするのよ、という別な問題が出てきます。組織の規模やカタさにもよりますが、解決したい問題に対して解決策が重すぎる場合はやはり不採用でしょう。

Officeファイルを中央集権的バージョン管理で

ということで前振りが長くなりましたが、今はこの方法で管理しようかと思い始めています。まだ安定して継続しているわけではありませんが。

1. 「仕事の単位」でフォルダを作り、全部突っ込む
2. ついでに ITS の milestone などに設定する
3. commit はとりあえず分かってる人だけでやる

関わっている全員が commit できるのは理想かもしれませんが、そこまでの必要性は感じていません。どうせファイルを実際に編集して作業する人間はほとんど決まっています。

それよりもファイルの管理と同時に、雑多なファイルを取りまとめてやりとりする際のゴールを ITS の milestone で、残りの課題を ticket で見える化できることの方が効果としては大きいと思っています。

中央集権的と書きましたが、別に分散バージョン管理でも構いません。ただ、これを考えた段階で自分の環境では

• どうせ作業者はある程度絞られる
• 基本的にはシーケンシャルな使い方しかせず、複雑なマージなどは考える必要がない
• ファイルの数もせいぜい多くて十数個までで、深い階層も必要ない
• 出先作業は考慮しない

ので、別に何を使ってもいいです。基本的には

自分の使っている Trac がデフォルトで svn 対応だから

です。

まぁ、あえて言うなら「オリジナルの管理が難しい」という最初の課題に対する回答としては分散ではなく中央集権的なバージョン管理の方が分かりやすいのではないかと思います。

逆にほぼ自分一人が作業を行い、かつ出先など repository にアクセスできない環境でも変更を加えたいということなら当然分散バージョン管理の方がいいんですが、もうそうなるとそもそもの前提が違います¹。

実は開発の流れと同じ

こうやって道具を持ち替えてみると、意外なことに気づきます。

• 複数の人間が絡んでいろんなファイルのバージョンを管理しなきゃいけない状況は単純なルーチンワークとは違う
• ITSでワークフローや進捗を含めて見える化されると作業の漏れを減らせる
• 要望が上がって作成 or 変更ののちリリース、のセットを回していく

これって何かに似てませんか？

そうです。開発の行程と同じです。いや、逆ですね。同じになるように道具を入れてるんです、ごめんなさい。

いやしかし、同じように回せることが分かればこっちのもの。開発で養ったノウハウが活きます。

• 内容はともかくワークフローはある程度固めることができる
• 定型タスクに落とし込んでどんどん自動化するとよい
  • 例えば相手の名前、例えば日付、こうしたチェックは自動化を考えよう
  • アーカイブなどのパッケージングも自動化すればメールで送る際も楽
• テンプレート（パターンと呼び変えても可）を充実させるとよい
• 道具の使い回しを考えてテキストから変換して生成するのは良いアイディア

ただし、

• 残念ながらタイムボックスを取り入れた iteration とは相性の悪いケースもありがち

なのは現状致し方ないかなと思っています。一つ言えるのは

それでも手帳&メール添付ベースの進捗&バージョン管理よりはずいぶんマシ

ということです。

多少ツールが増えた分のコスト増はありますが、課題の見落としやどれが最新バージョンか分からない、regression などの問題は起きにくくなりますし、ゴールを明確化しやすくなるのでいわゆるビジネスパーソンの好きな PDCA の話にも落としこみやすくなります。

特に最後の効果は新しい道具の導入にあまり積極的でない人にもメリットを伝えやすくて、とてもいいんじゃないかなぁ。何より自分のやろうとしている方法では管理する側の手間は増えないし。とりあえずなんでもバージョン管理、なんでも Trac、を今後はもっと積極的に進めていこうと思っています。

名付けて Ticket Driven Documentation つまり TDD です :-)