オルタナティブ・ブログ > Allegro Barbaro >

開発ツールビジネスの再生に格闘。マーケティングの視点で解説

ドキュメントレビューの話

»

先日のプレスリリースの作成は、3社共同リリースであり、かつ日米双方で配信という、関係者いっぱいの中での作業でした。プレスリリースはせいぜい4ページぐらいですから、ドキュメントとしてのボリュームはたいしたことはありません。でも、社内だけでもレビューにかかわる人が大勢いるため、それなりにバージョン管理をしていないと面倒なことになります。

ソフトウェア開発だとバージョン管理ツールなどを入れて、それなりに履歴や分岐を管理しますが、たかだかドキュメントとなると、結構いい加減になりがちです。しかも、ソフトウェア開発などを経験していない法務、PR、営業などの関係者もレビューに加わるため、そもそもバージョン管理という概念を気にしていなかったりします。

最も原始的な方法は、ファイル名による管理です。オリジナルドキュメントのうしろに、_draft1、_draft2 とか _rev1、_rev1_1 などと付けていきます。個人的には、スペースを入れたり、大文字小文字を混在させたりというのは、何かとトラブルを生みそうなので避けていますが、もはやファイル名にスペースが当たり前の世代は気にしてないようです。

もうひとつよくあるのが、_0603_hf とか、_rev2_by_fujii とか、レビューした人の名前や頭文字をファイル名につけちゃうやり方です。これだと、更新したのが誰か分かりますから便利。ときに複数のレビューワーが同時に違う修正を加えてきたときなど、_rev_by_michael_and_laura のようにマージした状態をファイル名で表すこともできます。

ファイル内の修正内容を明示する方法は、WORDの修正履歴、赤字、マーカー、いろいろありますが、原始的な方法でも、とりあえず分かればいいのですね。

ひとつ気をつけなければならないのが、プロセスのまわし方です。チェックイン/チェックアウトなどで、だれがいじっているかをシステム的に管理することができないので、だれにいじらせるかをプロセス的に制御することが重要です。レビューにまわしたら自分はしばらくいじらないで放置しておくとか、あえて日本語のレビューと英語のレビューを並行して実行させて、内容の乖離については、後で解決するように開き直るとか、時間と見てもらいたい内容/人によって、うまくコントロールすることが、こんがらかったレビュー結果で苦しまないコツです。

中には、作業が佳境に入ったころにちゃぶ台ひっくり返すようなレビューをよこすような人もいて、頭を抱えてしまうこともあります。でも、そういうときはあれやこれや勝手に悩んでも仕方がないので、直談判ですね。

Comment(2)