うまくルールを定めてラクラク情報共有

最初のルールが大切

システムを導入して一息つく間もなく、現実の業務はスタートして、メンバーは書類を作成し始めます。うかうかしていると、それぞれ独自のスタイルに基づいたファイルがどんどん増えて行き、共有しようにもどこにどんな資料があるのか分からなかったり、必要な情報が欠けていて使いにくいという事態に陥ってしまいます。

ファイルが増えてしまってから、共有にふさわしい方法を考えているのでは間に合いません。ネットワークが開通したら、すぐに情報共有のためのルールをまとめ、それを徹底することが、共有環境を生かす上での重要なポイントになってきます。

どんなルールが必要か

情報を効率よく共有するには、書類にどんな情報を盛り込むかということから、そのファイルをどこにどうやって保存するかということまで、いくつかのルールが必要です。ここではまず最初に、情報の記述内容に関するルールを考えてみます。

同じ仕事をしていても、あるメンバーの作成した書類が別のメンバーの必要な情報を全てカバーしているとは限りません。情報収集の段階で多くのデータが集まっても、当面の目的に必要でないものは、書類をまとめる時に捨てられてしまうことがあるからです。また、本人にとって当たり前の情報は、いちいち明記されないこともあります。

共通ルールとして記載内容が定められていれば、自分には不要と思われる項目でも書類に記入することになりますね。その結果、次に利用するメンバーは、もういちどデータを調べ直すという手間を省くことができるのです。

共通項目を設定する

たとえば、学術論文で引用文献を示す場合は

（例）著者『書名』（出版社，出版年）ページ

という項目を典拠の情報として記述するのが一般的なルールとなっています。このルールのおかげで、読者は論文に示された文献を確実に辿ることができます。この書式が個人の自由に任されていると、人によって記載する情報が異なってしまったり、初学者や学生はどのような情報を書くべきか悩むことになってしまいますね。

オフィスにおいても同じように、全ての報告書に

（例）件名，年月日，場所，出席者，参考資料

の項目を必ず記載するというようなルールを作ることで、だれもが間違いなく必要な情報を記述できるようになります。

必須項目を絞り込むときは、設計者が頭の中だけで考えて現実離れしたものとならないよう注意しましょう。実際の仕事に直結するルールを考える際には、ブレストやヒアリングでメンバーの意見を集め、「使える」ものを目指すことが重要です。

書式の統一

共通する情報の項目を決めたら、その記述スタイルも一定のルールを定めておくと、書類が読みやすくなるだけでなく、のちのちの応用の可能性が広がります。たとえば、項目を個条書きするときは

（例）項目名：項目内容

というように「：」で区切るとか、リストとして列挙するときは行の最初に「・」を置くなどといったルールです。これらの書式が定められていると、あとでその文書をHTML化してイントラネットで共有しようという話がでても、AppleScriptやPerlで簡単なスクリプトを書くだけで、全てのドキュメントを一度に変換するというようなことが可能になります（図1）。

また、日時や人名の書き方のような細かい約束も、想像以上に重要です。例えば日時を記載する場合に、「年月日を省略せず記述する」というルールが徹底していないと、月日しか書かれていないためいつの情報か分からず使いものにならないというケースは少なくありません（図2）。最初に約束を確認しておくことで、こうした古典的なトラブルを回避し、情報を広く活用することができるのです。

テンプレートを使う

これらの共有ルールは、規定集のようなものを作って配布してもなかなか徹底できません。簡単で確実な実現方法は、「ひな型」もしくは「テンプレート」ファイルの利用です。

たとえばクラリスワークスならば、基本的な必要事項を組み入れた書類を作成し、「ファイル・保存」メニューのダイアログで、「ひな型」ボタンを選んでから保存します（図3）。このとき、情報を登録するダイアログが表示されるので、それぞれの項目に利用者に分かりやすい説明を記入してOKしてください（図4）。ひな型ファイルは、「クラリスワークス」アプリケーションのサブフォルダ「クラリスワークスステーショナリ」に保存されます。

新しい文書を作成するとき、クラリスワークスでは最初に図5のような選択画面が表示されます。ここで画面右下の「ひな型選択」ボタンを選ぶと、図6のように利用できるひな型の一覧が示されます。ここでリストアップされるのは、ファイル名ではなく、さきほどの情報ダイアログで登録しておいた「タイトル」の一覧です。リスト上部のポップアップメニューを使うと、分類ごとに一覧を切り替えることもできます。選択したひな型の最初の部分が「プレビュー」として右に示され、さらに説明として記入した内容はリストの下に表示されています。これらの情報によって、利用者はこれから作る書類にもっとも適したひな型を確実に選ぶことができるわけです。

ひな型を開くと、あらかじめ用意した書式が「名称未設定」ウィンドウとして現れます（図7）。利用者はここに必要事項を書き込み、名前を付けて新たに保存します。ひな型自身には一切変更が加わりませんから、誰が何回使っても、新しい用紙をめくるのと同じ感じで書類を書き始めることができるのです。

データベースを文書作成に使う

もうひとつ広く応用できる方法は、データベースによる書類作成です。これは、データベースのフォーム印刷機能を応用したものです。

このためには、書類の形式ごとにデータベースを作成し、それぞれ入力用と印刷用のフォームを用意します。利用者は入力用のフォームを使って必要事項を記入していきます（図8）。記入を終えて「印刷」ボタンをクリックすると、出力フォーマットを使って印刷されるというわけです（図9）。

このメリットは、項目の入力漏れがなくなること、誰が使っても同じアウトプットが得られること、データベースの自動入力機能が利用できること、検索と複製が簡単なことなどがあげられます。入力用の画面に記入内容に関する説明や約束を表示し、間違いを少なくするという工夫ができるのも利点です。

いいことずくめのようですが、ひな形に比べると書式の柔軟性は少なくなります。また、運用に注意しないと、以前のデータを書き替えてしまって、記録がでたらめになる危険も伴います。データベース型共通書式は、発注書、送り状など形式が一定で、オリジナリティをそれほど求められないものから試してみるとよいでしょう。

共有フォルダと分類

今回の環境では、サーバー上に共有フォルダを設け、そこに共通情報を保存していきます。個人のマシンをそれぞれ「ファイル共有」機能で公開しても情報共有は可能ですが、検索などの手間を考えると、一カ所にまとめる方が遥かに効率的です。

情報をうまく共有するには、この共有フォルダを使いやすくする工夫も大切です。多くの場合、この中にいくつかのサブフォルダを設けて、メンバーが必要な情報を探しやすいよう、ファイルを分類保管するという約束をつくります。

ここで問題になるのが、フォルダの分類をどの程度細かくするかという、情報整理の永遠の課題です。単純なフォルダ構成では、ファイルが増えるにしたがって一覧の中から目的の情報を探すのは困難になっていきます。かといって分類を細かくし過ぎると、いわゆる「こうもり問題」に陥って、保存場所が人によって異なるという事態になってしまいます（図10）。

フォルダは、情報の内容で分類するよりも、むしろ「報告書」「企画書」のような形式的なくくりで分けた方が混乱しません。さらに、サブフォルダを年度、月という形で作っていけば、分類に迷うこともなく、多数のファイルで溢れ返る心配も不要です。（図11）。

進行中のプロジェクトに関しては、特別なフォルダを用意して、エイリアスを入れておくと便利でしょう。もっとも、これは結構手間のかかる作業ですから、うまく実現するには、プロジェクト単位で責任を持たせるなどの工夫が必要になりそうです。

ファイル名の情報価値

もうひとつ考えておきたいのが、ファイル名の付け方です。マッキントッシュで使えるファイル名は最長31文字。せっかくの長さを生かし、誰にでも理解できる名前を付ける工夫が必要です。

たとえば、「3月プレゼン」という名前では、誰に対してのどんなプレゼンテーション資料なのか見当がつきません。これを「MacFan 3-15号企画プレゼン」という名前にすれば、はるかに明快で、いちいちファイルを開かなくてもそのファイルが必要かどうか判断できますね。

ファイル名は、ともすれば個人用のコンピュータと同じ感覚でつけがちです。共有環境ではとにかく具体的な名前を使うという考え方を確認しておきましょう。ただ、ここであまり複雑なルールを決めるのはかえって混乱のもと。名前の先頭に"980515-PR-3-"のようなIDを加えると一見管理しやすそうですが、煩雑すぎて破綻する可能性が高いので、やめておいた方が無難です。

また、Windowsとの共存環境も考慮する場合は、最初からファイルの拡張子（.txt、.xlsなどファイル名の最後に付ける識別文字）を使うことをルール化しておくと、共有がスムーズになります（図12）。

ルールはできるだけシンプルに

こういったルールは「言うは易く行うは難し」の典型です。完璧を追究して複雑なルールを作っても、かえって実用性が低くなってしまうもの。まず誰でも確実に実行可能な分かりやすいものを考えることが大切です。また、ルールを決めるだけでなく、それが自然に実施されるような環境を用意することも忘れてはなりません。今回取り上げたひな形やデータベースの利用はその具体例です。

情報共有のルールは、無くても当面の仕事に支障がないものだけに、最初の段階で徹底して「文化」にしてしまわないと、絵に描いた餅に終わる危険があります。半年、１年と運用を重ねるとその威力がはっきり現れて、メンバーも自然と協力してくれるようになるものですが、そこに至るまでに挫折してしまうことも少なくありません。ルールづくりは、効果の見えにくい、最初の段階が肝心なのです。

(MacFan 1998-06-15号)