ライフサイクルを考えたドキュメント管理の「ひと工夫」：PLM導入プロジェクト、検討前に読むコラム（3）（2/2 ページ）

製品ライフサイクル全体を管理するためにはPLMを基軸としたシステム作りが急務。PLM導入・改善プロジェクトを担当する際に事前に知っておくべき話題を、毎回さまざまな切り口から紹介していきます。

[久次昌彦／プログレス・パートナーズ，＠IT MONOist]

ドキュメント管理ソフトウェア活用に必要な「もうひと工夫」とは

　こうしたファイルサーバによるデータ共有が抱える問題は、ドキュメント管理ソフトウェアなどを使うことでほぼ解消できます。しかし、単体のファイルを管理するだけであればこれで十分ですが、ドキュメントを業務に有効活用させる仕組みを考える場合は、もうひと工夫必要です。

　業務の中で活用するドキュメントは1つだけではありません。設計業務の中では設計企画書に関連して、設計仕様書や原価計算書、プロジェクト日程表や設計図面など、さまざまなドキュメントが関係してきます。

　設計者は自分が作業しているドキュメントはもちろん認識していますが、多くの場合、設計作業は並行して行われています。

　グループで行われることが多い設計作業の中で作成されるドキュメントは、複数の作業者が関係するため、設計者自身に対して自身の成果物に関係するドキュメント類がいまどのような状態になっているのかを気付かせることが重要です。

　設計ドキュメントは自社で取り扱う製品に関連して発生しています。そのため製品番号や部品番号および商品番号などをキーとして採番してドキュメント類を見つけやすくすることを併せて検討するといいでしょう。

検索エンジンを用いた情報のマイニング

　Googleなどに代表される検索エンジンの登場により、膨大にあるインターネット上の情報から自分の欲しい情報を簡単に見つけて活用できるようになってきました。会社の中に膨大にある情報を、インターネットの世界と同じように検索できるようにしたいと考えるのは自然な流れでしょう。

　そこで企業のサーバに検索エンジンを導入して、蓄積されている情報を検索するアプローチを取っている企業も見掛けます。

　これらの検索エンジンは個人のPCで管理されている情報を検索する場合は非常に効果的に活用できます。

　しかし部門レベルのサーバや全社的なサーバ内ドキュメントを検索する場合では、検索キーワードに引っ掛かるドキュメントが多過ぎて、どのデータが自分に対して有益なものなのかを判断するのに困ってしまいます。

　そのため検索エンジンを使う場合は検索したものに優先順位を付けて、利用者のニーズに合わせた優先順位を表示しておく必要があります。例えばGoogleの場合は、Webサイト間の被リンク数の多さを1つの目安に、独自のロジックを使ってどのWebサイトの情報が求めているものに近いのかといった優先順位を付けています（ページランク機能）。

　しかし、同様の高度な処理を部門や企業の中で行うのは非常に困難です。検索エンジンを使った情報共有を実現する場合は、検索した結果に対する優先順位を持たせるロジックを併せて検討していく必要があります。

　こうした課題への対策の1つとして、企業活動で発生する情報は自社が取り扱っている（業務として担当している）製品を中心に発生しているという点に着目し、検索した結果に優先順位を付けるという方法があります。

　企業は製品を販売して利潤を上げる活動を行っています。設計部門の設計者は自分が担当する製品の設計を行っていますし、調達部門や製造や営業部門の人も自分が担当している製品に関する活動を行っています。

　このように各部門や担当している業務によって欲しい情報というのはおのずと絞られてきます。

　検索エンジンを使って他部門の情報を簡単に検索できるようにし、部門を超えた情報を正しく入手できるようになることで業務の効率はアップします。

　検索エンジンを使って社内のドキュメントを管理する場合、Googleがベージランクといったロジックを用いた優先順位付けを行っているのと同様に、企業の中の検索エンジンに対しても製品と部門といった切り口で情報を関連付け、必要な情報のみフィルタリングして提供するといった仕掛けを併せて検討するといいでしょう。

Lotus Notesデータベースの有効活用

　Lotus Notesデータベース（以下、Notesと略記）（注3）は、自分が管理したいデータベース構造の設定が簡単にできるため、設計情報を管理するツールとしては非常に有効で、多くの企業で採用されています。

　しかし、Notesデータベースにも欠点があります。各設計者が製品情報を管理するためのデータベースを個別に自由に作成できるため、かえって設計情報が分散してしまい、部門を超えた情報の共有ができなくなってしまう点です。筆者も部門間のデータ共有ができずに困っている企業をよく見掛けます。

　個々のNotesデータベースに蓄積されている情報に横串（よこぐし）を通して情報を流通させる方法としては、より柔軟性のあるシステムに移行するか、Notesデータベースも検索できる検索エンジンを使って個別のNotesデータベースから情報を見つけるという方法が取られています。

注3：Lotus Notesは現在、IBMが開発・販売しているグループウェア用ミドルウェアです。製品詳細はhttp://www-06.ibm.com/software/jp/lotus/products/nd85/を参照ください。

　Notesデータベースから別のシステムに移行する方法を選択した場合は、より柔軟性を持ったシステムに移行できるため、ソフトウェアに引きずられて進まなかった業務効率の改善を一歩進めることができるでしょう。

　しかし、システムの移行作業はかなりの労力を伴うとともに、新しいインターフェイスに対するユーザーへの教育などを含めると大掛かりな作業になる傾向にあります。

　一方、既存のNotesデータベースの情報を検索できるようにして複数のデータベースから必要な情報を見つけ出す方法では、検索データの精度の問題が残ります。

　Notesデータベースのデータを有効活用したドキュメント管理を目指すなら、データベース化されている情報のうちどこまでの情報が必要なのかを見極める必要があります。ここでは、分かりやすく説明するために電子メールクライアントソフトウェア（以下メールソフトと略記）を例に考えてみましょう。

　一般的なメールソフトでは重要な電子メールをフォルダに分けて管理して保管する機能があります。しかし、フォルダに管理されているメールを皆さんはどれだけ活用しているでしょうか？ メールを受け取った週であればかなり頻繁に見返すこともあると思いますが、1カ月たったメールをどれだけの頻度で見ているでしょうか。また、昨年受信したメールを見る頻度はどれくらいかを考えてみてください。

　昨年のメールを見る頻度は1年に1回あるかないか程度で、ほとんどの場合では、受け取ったことも忘れていると思います。

　組織を超えてNotesデータベースを有効活用できるソリューションにすることを考え、個別に作成されている何百ものデータベースをどのようにまとめていくのかで悩んでいるプロジェクトは多数あります。

　こうした問題に対しては、有益な情報が蓄積されているデータベースから必要な情報を抽出して吟味した後にシステムを完全移行するのか、それとも他システムとの連携でも十分に情報を活用できるのかを検討し、システム化の方針を打ち出すといいでしょう。

　さて、皆さんがPLMシステム構築・改革プロジェクトの担当者ならば、本稿で説明した代表的なドキュメントの管理方法の特徴を把握し、メリット・デメリットを検討して自社に合ったドキュメント管理方式を選択した後に仕組みを構築していくことになることと思います。

　ドキュメント管理システムを構築するうえでは次の2つのポイントに関して自社の運用ルールを明確にしておく必要がありますので、よく読んでおきましょう。

1. ドキュメントライフサイクルの定義

　ドキュメントには作成されてから廃棄されるまでのライフサイクルがあります。

　一般的には

作成→レビュー→公開→再利用→保存→廃棄

といったライフサイクルになるはずです。

　ドキュメント管理システムを構築する際にはステージごとにそれぞれの管理方法を個別に検討しておくべきです。

　例えば共有フォルダで管理する場合は、作成や公開の方法に関しては検討されていますが、レビューや再利用に関する検討がされていない場合が多いため、さまざまなレベルのファイルがたくさん共有フォルダに保存され、どれを使えばいいのかが分からなくなってしまいます。

　ドキュメントのライフサイクルを検討すると必ず「公開」や「再利用」を検討する必要が出てきます。これらのドキュメントライフサイクルステージを検討することで、部門を超えた情報インフラを構築していくことが可能となります。

2. ドキュメントを活用する“登場人物”の管理

　組織を超えた情報流通を実現する場合、ドキュメントの作成者だけでなくドキュメント情報を活用する集約たる“登場人物”も併せて設計しておく必要があります。

　関係者には主に下記のカテゴリーがあります。

• 作成者：コンテンツの作成者
• プロデューサー：アウトプットするコンテンツに対する責任者
• 関係者：コンテンツを使って作業を行う人
• 参照者：コンテンツを参照するだけの人

　先のドキュメントライフサイクルにこれらの登場人物のロールを組み合わせることで、コンテンツとしてのドキュメントの振る舞いが明確になってくるはずです。

3. 業務シナリオの設計

　ドキュメント管理システムは、あくまでも業務で使えるシナリオに沿って活用できないと意味がありません。そこで最後のポイントとして、ドキュメントの使われ方を踏まえた業務シナリオを設計していきます。

　具体的には、業務シナリオに沿ったドキュメントフローチャートを作成し、ドキュメントのライフサイクルと各ステージでの登場人物を組み合わせてドキュメント管理のあるべき姿を構築します。

　作成した業務フローはこれから実現するフローなので、実際に検証されたものではありません。

　そこで、あらかじめ想定される不具合もこの業務フローを使って検討する必要があります。想定される不具合が検討できたら、併せて不具合に対する対策も考慮してソリューションとして組み込んでいきます。

“ソーシャルPLM”による情報共有の可能性

　ドキュメント管理システムの構築の難易度レベルは、状態に応じてかなりの差があります。

　ドキュメント管理は小さな規模で実現するのであれば簡単に実現できますが、部門を超えた情報共有を実現しようとするとしっかりした考え方を持ってプロジェクトを進めていく必要があります。しかし、部門を超えたドキュメント管理を実現した方が必ず得る効果も高いのも事実です。

　最近では、組織に分散している知識を組織の壁を超えて有効に活用して方法として、SNSやマイクロブログ、ブックマークや動画共有などのソーシャルメディアの活用も盛んです。

　これらのソーシャルメディアはインターネットという媒体を通じて瞬く間に国や組織の壁を超えて情報を共有することを実現しています。

　ソーシャルメディアのテクノロジをそのまま活用することもできますが、企業で情報共有する場合は、ソーシャルメディアのコンテンツに、企業活動の成果物としてのドキュメントや製品情報などを併せて管理できるようにする必要があります。

　最近ではこのような技術を積極的にPLMシステムに取り込んだ「ソーシャルPLM」とでもいうべきシステムの提供も始まっています（注4）。

注4：ブログ記事「ソーシャルPLMシステムというアプローチ」も参照ください。