　そのため検索エンジンを使う場合は検索したものに優先順位を付けて、利用者のニーズに合わせた優先順位を表示しておく必要があります。例えば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システムというアプローチ」も参照ください。

PTCがアプリケーションライフサイクル管理ソフトウェア開発企業を買収
PTCは、アプリケーションライフサイクル管理ソフトウェア「Codebeamer」の開発、販売を手掛けるIntland Softwareを買収した。単体またはPLMソフトウェア「Windchill」や「Arena PLM」と組み合わせて提供する予定だ。
製造業DXに必要なPLMの3段階デジタル化
本連載では製造業DXの成否において重要な鍵を握るPLM／BOMを中心に、DXと従来型IT導入における違いや、DX時代のPLM／BOM導入はいかにあるべきかを考察していく。第2回はDXを実現するまでに必要な「3段階のデジタル化」を解説する。
PLM的な情報管理なんて実現しない？
製品ライフサイクル全体を管理するためにはPLMを基軸としたシステム作りが急務。PLM導入・改善プロジェクトを担当する際に事前に知っておくべき話題を、毎回さまざまな切り口から紹介していきます。
PLMはTime to MarketからTime to Profit
日本にPLMを紹介する先駆けとなった書籍「CRM、SCMに続く新経営手法　PLM入門」（2003年刊）を執筆したアビームコンサルティングの執筆チームが、その後のPLMを取り巻く環境変化と今後のあるべき姿について、最新事例に基づいた解説を行う。
PLM雌伏の10年、これからは飛躍の10年となるか
2000年代前半から製造ITツール業界で話題になり始めた「PLM」。しかし、MONOistが2007年に開設してからこの10年間、PLMの実際の運用状況はPDMの延長線にすぎなかったかもしれない。しかし、IoTの登場により、PLMは真の価値を生み出す段階に入りつつある。