2014年7月10日木曜日

文書・コンテンツ・ファイル 半構造データ(XML)とCCMS

最近、自社関連の各Blogが、書き出し部分にスマートに近況報告的な世間話を混ぜ込んでいくスタイルに収斂しつつあることに危機感を感じています。



前回の、補足でもあるのですが、ECMはファイルが基本の管理単位になります。従って、図面管理においても物理的には1ファイルにまとめてある中で「特定のページをめがけたリンクを埋め込みたい」、というニーズがある場合は、そのまま適用するのは難しくなります。(例えば1ページ毎のレンディション(PDF版)を別途作成し、そちらを参照させる、などのテクニックはありますが)



今回は、ファイルが主役である、という特性を改めてご説明した上で、CCMS(Component Content Management System) コンポーネント・コンテンツ・マネジメントシステムというコンセプトについてもご紹介したいと思います。



ECMの基本とする管理単位が「ファイル」であるということ



あちこちの講演でも繰り返しご紹介していますが、ECMはかつてはEDMS、電子的文書管理システムといわれたコンセプトの後継にあたります。時期としてはおおよそ2000年あたりにこのキーワードの交代劇が発生しました。なぜ、文書(Document)をコンテンツ(Contents)と読み替えることになったのでしょうか?



1つには、Webに代表されるインターネット技術の台頭があります。HTMLで記述される「ページ」は、その呼び名とは裏腹にあえて再現性の低い印刷工程を通さないと「頁」もなく、文書という従来からある言い回しに収まらないインパクトを持つものでした。また、技術的にも、体裁情報を定義したスタイルシートや画像ファイルなど複数の「ファイル」によって構成されていますし、特定のポイントを指さすリンク構造も持っています。そのため、当時はWebページを管理するためのコンテンツ管理システム、WCM(Web Content Management)の製品が多数出荷されました。このジャンルは後にPHPベースのシンプルで安価な製品群が席巻し、カジュアルにCMS(Content Management System) コンテンツ管理システムと言った場合、一般的にはECMの様な文書管理ではなくこれらのWebコンテンツの管理システムを指すようになっています。



2000年代においては、EDMSから進化したECM製品もWebコンテンツの管理機能を取り込もうとしていましたし、Javaで構築されたような重厚なWCM製品もECM的な文書管理やワークフロー、コラボレーション機能などを製品に取り込む努力をしていました。例えば、2005年に立ち上がったAlfrescoにおいても、WCMモジュールが後から追加されています。この時は、「重厚なWCM製品」の代表格であったInterwovenのチームのエンジニアを引き抜いて、かなり大がかりなフォルダ仮想化技術を実装していました。これは素晴らしい機構でしたが、ここでお話しているようにECMがファイルを基本単位としている一方でWebコンテンツはその枠組みに収まらないというギャップがあり、Alfrescoの内部構造に異なる2つのリポジトリエンジンを抱える構造を余儀なくされていました。結果、数年後彼らはこの重厚な仕組みを放棄して軽量なWebページ作成機能を別途開発します。そしてさらに、現在ではWebサイト側にもそれなりに複雑な要件があるケースではDrupalなどのPHPベースのCMSを別途立ててインテグレーションしたり、Liferayを並立させたりする構造が一般的になっています。



それだけ何を基本の管理単位としてシステムを設計するのか、というのは大きな問題であるということだと思います。



ワンソースマルチユース



全社的にECMが導入された場合、所謂コンテンツ・文書・非構造データについても、ワンファクト・ワンプレイスが実現します。冗長なコピーを作る必要がなく、漏洩の恐れもなく、必要な時に必要な人に必要なコンテンツへのアクセスを提供できます。(かなりの理想論ですが)



一つの文書が、色々な目的で使い回されることになります。



ワンソースマルチユースというキーワードがありますが、これはここでいうような「複数の業務プロセスや部門から横断的に同一のコンテンツが利用可能になる」というのとは少し違うニュアンスを持った言葉です。具体的には、コンテンツの意味内容をXMLなどのプレーンな形式で管理し、体裁情報をスタイルシートとして別管理しておけば、印刷用、Webページ用、ダイジェスト出力用、など同一の内容で体裁が異なる出力結果を得られる、という状態を指しています。これにより、意味内容に変更があった場合は1カ所だけ修正すれば、すべての出力結果にその修正を反映させることができるようになるわけです。



弊社の取り扱い製品のラインナップの中では、Alfresco上にDITAというXML標準を扱う機能を実装したComponizeが、このワンソースマルチユースを実現するための仕組みになります。



DITAの詳細の説明はここでは省きますが、トピックという単位で意味内容を表現した(主にテキストの)部品をなるべく文脈に依存しない形で構成し、マップという単位でそれらのトピックの構造をまとめあげ(目次を定義して、どの順番でトピックを並べるのか、を決めてあげます)、そこにスタイルシートを適用して体裁情報を加えた出力結果を得る、という仕組みです。意味と体裁、ではなく、意味の断片と構造と体裁、を独立したコンポーネントとして管理するわけです。



これらの管理をシステム的にサポートするのが、CCMS コンポーネント・コンテンツ・マネジメントです。この仕組みでは最終的には1つのファイルとして提供されるマニュアルの中の特定の箇所をめがけてリンクをはったり、そこを書き換えたりということも可能になるわけです。



CCMSではファイルが基本単位になっていない?(=ECMとは相性が悪い?)



DITAはXMLの規格ですから、通常ECMが扱うような文書ファイル、Word Excel Powerpoint PDF、の類いに比べてHTMLやWebページに近い技術です。そう考えると、ECMによるWCMの取り込みが失敗に終わった歴史を振り返るに、Alfresco上にDITAコンテンツの管理機能を実装するというComponizeの取り組みは一見筋が悪いものにも見えてきそうです。



しかし、私はこれは非常に洗練された仕組みだと考えています。つまり、出力結果の1ファイルに主眼を置いてしまうと、その構成要素は複雑に絡み合う複数の部品となり、ECMが苦手とする領域に踏み込んでいるように見えますが、通常直接編集を行う個別のトピックを定義するファイルに注目して考えた場合は、依然として1ファイルが基本の単位になっているからです。



AlfrescoもECM製品として十分な「ファイル同士の」関連付け機能を備えていますので(残念ながら基本のUIからはその機能は見えづらいのですが、内部機構には強力な仕組みがあります)、どのトピックがどの出力結果に利用されているか、などの情報はファイルを基本単位としたまま適切に管理されています。



これらはDITAという標準規格がしっかりと定義されていて、わざわざ関連付けまで含めた管理機構を実装するに足るメリットがあるからこそ実現している仕組みであるとも言えるでしょう。



DITA/CCMSのメリットや必要性



残念ながらこれでワンソースマルチユースの洗練された管理機構を実現できるのはDITAが対象としているようなマニュアルや仕様書などのテクニカルドキュメントだけですが、その導入メリットは非常に高いものであると考えられます。



もちろん、管理の仕組みが大きく変わるだけでなく文書の作成方法も従来通りとは行かないため学習コストは相対的に高くなりますし、いかにDITAが洗練された規格であったとしても、既存の規格を知らずに作成されたコンテンツをその枠組みに押し込むには難しい判断を求められるケースも多くなります。(最近では、規格自体のアップデートなどもあり得るので、その動向に目配せをしながら判断した方がより望ましい、なんていう面もあります)



それでも、最終的なコンテンツの管理コストを下げ、陳腐化したコンテンツが滞留しないようにしていくことのメリットは非常に大きいはずです。未だ多くの企業においてはコンテンツの整備は製品・サービスそのものの提供と比べると副二次的なものであるという扱いを受け、管理人員が十分に提供されない状況があります。製品・サービスそのものと違い、コンテンツは何もしなければ堆積していきます。活用機会を失うだけでなく、誤った情報が残り続けることで、様々な領域で問題を生じる可能性があるわけです。



こうした観点から、広く技術系のコミュニケーションに問題意識を持っている方も徐々に増えているのではないかと思います。Componizeはクラウド上でのトライアルも可能な製品ですので、是非お気軽にお声がけを頂けると幸いです。



あー、また長文ポストになってしまった。一応、営業っぽいメッセージも入れたから許して欲しい、という業務メッセージを追加して、結びの挨拶とさせて頂きます。



(文責 Ishii Akinori IT-Coordinator)




2014年7月8日火曜日

文書管理と図面管理

最近、図面管理についてのご相談を頂くことが増えてきました。がっちりしたPLM(製品ライフサイクル管理)やPDM(製品データ管理)のコンセプトを実装した製品は複雑で高価、顧客にとって不要な機能を包含したものになりがちなため、文書管理ソフトウェアを使って図面を管理できないか、という着眼点からのお問い合わせ、というのがある種のパターンになりつつあります。



非常に大雑把なくくり方をすると、PLMをゴールとした場合のCAD図面の管理体制には以下の様な成熟度が考えられます。(図にするのであれば高い成熟度を上に持ってきたいところですが、Markdownで書いているので、ひとまず項番=Lvという解釈で下へ行くほど成熟度が高くなります)




  1. 図面ファイルを単なるファイルとして管理し、メールやファイルサーバで管理

  2. ローカルではCADツール付属の図面管理機能で図面番号などの属性を管理

  3. シンプルな図面管理ソフトウェアを使って共有

  4. PDMツールを導入し、パーツ品番の管理や各種採番などもシステム化

  5. PLMツールを導入し、関係各所とも一貫した情報管理を実施



紙図面を脱却し、パーツ情報の共有や生産情報などの基幹系システムとの連動を実現できるようなシステム的にユニークで一貫したIDの管理など、図面情報の高度化が希求されています。



IDの管理や図面全体に割り当てられるような図面番号や顧客名などの属性情報の管理などについては、まさしく文書管理やECMで行われていることと同じ機能が求められています。そのため、高価なPDMなどを導入しなくても当面必要な管理精度や検索の利便性などについては文書管理でもできそうだな、という印象を持たれる方も多いわけです。



しかし、パーツの管理や、パーツそのものに付加された属性まで管理しようとすると、なかなかに複雑になります。ECM製品であれば文書同士の関連情報を保持することも可能なので、サーバ内でパーツの図面と製品全体の図面を結びつけておくこと自体は可能ですが、CADファイルの中身を書き換える機能があるわけではないので、それを持ってパーツ側での仕様変更を製品図面に反映させる、などの機能を実現するのは無理があります。(せいぜい、パーツ図面の更新時に利用してる製品の一覧を表示するくらいでしょうか)



文書管理ソフトウェアやECM製品は、各文書の内部構造に踏み込んだ処理はあまり得意ではありません。



全文検索インデックスをつけるというのがこれらのツールにとって最も内部に踏み込んだ処理、と言っても良いかもしれません。もちろん、文書管理ツールで図面管理を考えておられる方が関心を持っている、プレビューやサムネイル作成の機能などもファイルの中身を使っての処理ですし、Excelの特定セルを読みこんで属性値として割り当てるとかPDFの属性情報を吸い上げるなんていう処理もありえます。しかし、これらの機能も、本体そのものはそのままの形で保持することを前提として、プレビュー用の補助ファイル(レンディションと呼びます)や属性値を周囲に配置することを目的としたもので、図面の内部へ変更を自動反映していくような位置づけのものではありません。



では、図面管理は専用のソフトウェアで行うべきであり、文書管理ソフトウェアやECM製品を無理矢理適用するのは間違っているのでしょうか? 



(例によって議論の幅が拡がり過ぎてしまいそうなので、ここから先は文書管理ソフトウェアというよりはECM製品を前提に続けたいと思います。弊社には文書管理ソフトウェア並に低価格なECM製品もありますし!



図面管理分野でECMが活躍する局面



上述したPLMを頂点とした図面管理は、製品を設計し、材料を調達、製造して、販売し、(場合によっては)保守をする、というストレートな製品出荷を前提としています。そして、製品の種類が多ければ多いほど、効果が大きいと予想されます。また、どちらかといえば製品のライフサイクルが短く、どんどん新しいものを出荷する、というスタイルに向いているとも言えるのではないでしょうか。



しかし、製造業にも色々なスタイルがあります。例えば、私の実家は天井クレーンの製造販売を行っていますが、基本的には個別受注生産で、どの案件にどのパーツを使ったのかという情報は必要ですが、そのパーツも他社からの購入品であるため個別に図面を管理したりはしていません。では、図面管理の必要が無いかと言えばそんなことはありません。顧客毎、案件毎の管理をロングスパンで行う必要があります。クレーンは何年も使い続ける装置ですので、初期設置時はなかった安全装置を後で取り付けたり、古くなった部品を新しいものと交換する際に従来の部品が手に入らず新しい互換品を採用したり(あるいは互換品がなくて修正工事を行ったり)ということをしていきます。これらの情報が散逸してしまっては都合が悪いわけです。



もっと大きなビジネスをしている製造業でも、標準品の図面管理と、案件毎のカスタマイズによる施工図面を二重に管理せざるを得ないケースはたくさんあると思います。図面の内部に踏み込んでCADの内部で扱えるパーツ間の関係などにフォーカスするのではなく、図面の外にある(あるいは業務的な意味で設計の外にある)情報とのリンクを取り扱いたいのであれば、ECM製品を利用する意味合いが出てきます。



非常に大雑把なまとめ方をすると、製品と部品の関係をメインで取り扱いたいのであれば図面管理、製品と案件(工事)などの関係に着目する必要があるのであればECM製品を検討するのが良いのではないかと思います。



実際には他にも色々なケースが考えられますし、そういった事例もいくつか持っていますので、ご関心をお持ちの方はお気軽にお声がけ頂けると幸いです!



(文責 Ishii Akinori IT-Coordinator)




2014年7月4日金曜日

エンジニアの仕事環境と『小さな成功』のはなし

パートナーさんとの合宿のために軽井沢に向かっています。新幹線も空いているのでこれ見よがしにMacを広げたところです。



普段ならTwitterに書き散らすようなネタなのですが、うまいこと140文字に収まりそうにないので、こっちの自由記述欄に。



個人的には「ネット」という言い回し自体あまり好きではないのですが、TVや新聞ではなく基本的な情報収集の手段がインターネットになり、アグリゲートされた後の記事をナナメ読むことが多いので、私自身はかなりネット寄りな情報や論調に偏ったポジションにいる、という自覚はあります。その中で、これも嫌らしい単語だと思うのですがリテラシーという面では上級職扱いのIT業界の住人でもあります。自戒を込めて言うのであれば、そういう人種はやはり進歩的であったり、欧米的な価値観に寄り添った立ち場から社会を見ているような印象があります。その例の一つ、「(日本は)もっと失敗を許す社会であるべき」という意見について、少し思い付いたことがあります。



まず、私自身はこの意見に対して、どちらかというと賛成、くらいのスタンスです。言っている内容に妥当性を感じるが、殊更自分が声を上げて現状を否定するほどのものでもないし、なるようになるんじゃないか、という位の温度感です。(現状それなりに恵まれた環境で仕事をさせてもらっていることと、独立だの起業だのというリスクを一応は取っているということのバランス、がこのあたりに落ちてきています)



また前置きが長くなってきています。



(IT業界の)エンジニアは人から見えないところで小さな失敗と成功を繰り返せる環境を持っているので、ある種成熟した視点を会得しやすい



という仮説を考えました。



システム開発、特にコーディング部分に関わることのない人には本当に何を言ってるのかわからないと思うので、少し細かく説明します。(単純に私が注意力散漫とうこともあると思いますが、)通常、最初に書いたプログラムというのは上手く動きません。上手く、どころか、まず動かないことの方が多いくらいかもしれません。で、機械にだめ出しをされ、修正をし、どうにか動いてくれるのを確認、でも結果が想定と違うのでまた修正、そうするとまた動かなくなって、、、というのを本当に細かいレベルで繰り返します。



実際、こんなに頻繁にネガティブなフィードバックに晒される職種は珍しいんじゃないかと思います。ただ、あまりにも些細なものであり、相手が機械であるという点で、心理的なダメージは非常に小さくなっています。(ここに人間味があるネガティブコメントが付加されると一気に耐えきれなくなる、というのは感覚的にはあり得そうな話で、業界にメンタルを損なう人が多いことの数多い原因の一つだったりするのかもしれません)



一方で、そういう作業が上手く意図通りに行った場合の小さな達成感というのも当然あります。顧客に何らかの変革を強いる、いわゆるコンサルティングの仕事では、「小さな成功(win)」を顧客に感じてもらうことがプロジェクト全体の成功を握る鍵である、というような話がよくされるんですが、まさに「小さな成功」です。



つまり、多くの失敗と、そこそこの頻度で訪れる小さな成功、というサイクルで仕事を回しているエンジニアは、「失敗の許容」という冒頭の大人な意見に同調しやすくなってるんじゃないか、と。



Railsのブームの出始めあたりに、生産性に絡む評価として、個々のエンジニアが「俺すげー」って思えるポイントをチラしてある感じが憎い、みたいな視点があったような気がします。(ソースとなる記事がないかなと思いましたが、それらしいものはうまく見つけられませんでした)。最近だとVagrantとかChef/Puppet/AnsibleとかDocker界隈の技術にも似たような受け止められ方をされてる部分があるように思います。



やっぱり思ったより長くなってしまったので、さっさとまとめると、そういう個々人の体感の部分で「小さな成功」や高い生産性を感じさせてくれるツールが受けているということなのだとしたら、それをエンジニアだけでなくナレッジワーカー全体に適用するような工夫ができると楽しそうだな、と。細かいアイディアは幾つかあるので、実現しそうになったらまたご紹介します。



(文責 Ishii Akinori IT-Coordinator)