2008年11月8日土曜日

Alfresco Enterprise 3.0 Delivers Collaboration at Dramatically Lower Cost than Proprietary Alternatives

Alfresco Enterprise 3.0 Delivers Collaboration at Dramatically Lower Cost than Proprietary Alternativesalfresco.com



こんにちは。aegif技術担当役員の石井です。



いよいよAlfrescoのEnterprise版もメジャーバージョンアップとなりました。数ヶ月前からLabs(旧Community版)としては利用可能な状態でしたが、各所に強力な機能強化が施され、Alfrescoにとって戦略的に重要なバージョンになっています。さっそく日本語のランゲージパックも更新しForgeサイトで公開してあります。(毎度のことで恐縮なのですが、配布されているAlfresco本体のパッケージには最新の日本語ランゲージパックは同梱されていません)



本リリースの機能強化の中でも特に重要な点をご紹介しますと、
 ・Sharepointライクな(と敢えて言ってしまっても良いでしょう)コラボレーション環境を実現するオルタナティブクライアントであるAlfresco Shareの同梱
 ・テンプレートとスクリプト言語を組み合わせて軽快な追加開発を実現するSurfフレームワークの提供
 ・ECMの世界の共通言語となることを期待されている新規格CMISに準拠したAPIの提供
などがあげられるかと思います。



追加開発の容易性を伸ばすとともに、コラボレーション環境としての機能充実が図られています。単純な文書管理よりも広い範囲のニーズにより手軽に対応していくことが可能になっています。



��文責 Ishii Akinori ITC)

ようやく策定されたECMのための共通言語 CMIS(2/3) (Insight Now!より転載)

少し間があいてしまいましたが、CMIS(Content Management Interoperability Service)の内容紹介を続けたいと思います。前稿では、CMISがどのような利用のシーンを前提として策定されているのか、という話題を中心にご紹介しました。本稿では続くメソッドレベルでのAPIの解説の前提知識となるデータモデルについてご説明します。



CMISではいわゆるフルスペックのECM製品で取り扱われるオブジェクト群のすべてが規格化されているわけではありません。たとえば追加開発用のインターフェースに使われるトランジェント(永続化対象外)なエンティティや、ユーザプロファイルのような管理目的のエンティティ、ヴァーチャル文書やビジネスプロセスそして購読などの付加価値的な機能であつかわれるエンティティもスコープ外になっています。それでも、データの格納先として求められるリポジトリの構成要素については一通り網羅されていますし、その構成要素間の複雑な関係性も表現できるようになっています。まずは最上位の概念である"リポジトリ"からはじめて、4つの基本オブジェクトタイプを説明します。個々の構成要素である"文書""フォルダ"、その関係性を表現する"関連"、標準的なサービス(アクセス制限など)を表現する"ポリシ”の4つがCMISにおける基本オブジェクトタイプです。それからさらに追加のオブジェクトタイプの定義方法を紹介するまでを本稿の範囲としたいと思います。



リポジトリ



ECM製品毎にリポジトリの実装方法は様々です。したがって、CMISにおいては最上位概念であるリポジトリについてもすべての機能を網羅することを求めてはいません。例えば以下に挙げる機能は"オプショナルな"ものとして取り扱われます。また、当該リポジトリがこれらの機能をサポートしているかどうかは、getRepositoryInfoサービスによって通知されなければなりません。
・文書(あるいはフォルダに格納可能なその他のオブジェクト)を複数のフォルダに格納する機能。マルチファイリング。
・文書(あるいはフォルダに格納可能なその他のオブジェクト)をどのフォルダにも格納しないまま保持する機能。アンファイリング。
・文書の特定のバージョン(群)だけをフォルダに格納する機能。バージョン指定ファイリング。
・チェックアウトされた文書のワーキングコピーを更新する機能。ワーキングコピー編集。
・最新版ではない文書もスコープに含めた検索機能。全バージョン検索。
・チェックアウトされた文書のワーキングコピーもスコープに含めた検索機能。ワーキングコピー検索。
・検索クエリのサポート。「なし」「メタデータのみ」「全文検索のみ」「両方」
・クエリにおけるジョインのサポート。「なし」「インナージョインのみ」「インナージョインおよびアウタージョイン」
・全文検索サポート。「なし」「全文検索のみ」「全文検索と属性情報の組み合わせ」



これら機能のサポート状況だけでなくgetRepositoryInfoサービスからは関連するその他のリポジトリへのリンクを得ることもできるようになっています(規格上はMAYと表現)。CMISにおいてはリポジトリは単一のものではなく、いくつものリポジトリが併存する状況が前提となっています。getRepositoriesサービスによってアクセスの対象となりえるリポジトリの一覧が取得できます。上記の関連する他のリポジトリの一覧というのは、そのサブセットになります。また、getRepositoryInfoサービス以外でもgetTypesサービスやgetTypeDefinitionを利用してリポジトリについての情報を取得することもできます。



基本オブジェクトタイプ



CMISの基本オブジェクトタイプは、文書・フォルダ・関連・ポリシの4つです。文書はリポジトリに格納されるもっとも基本的な構成要素です。フォルダは文書をはじめとする「格納可能なオブジェクト」の集合のコンテナです。関連は2つの独立したオブジェクト(インスタンス)を繋ぐ関係性を定義します。ポリシは1つ以上の「コントロール可能なオブジェクト」に「適用」される管理目的のポリシを表現します。文書とフォルダとポリシの3つは独立したオブジェクトとして位置づけられているため、関連の対象となります。



また、各オブジェクトはオブジェクトIDというユニークな識別子を持ちます。このIDはタイプによらずリポジトリ内でユニークであることが保証されていなければなりません。また、必須ではありませんが、このIDは「永続的」であることが望ましいとされています。(永続的とは、すくなくともそのオブジェクトのライフスパンが終わるまでの間は不変である、ということを意味します。そのオブジェクトが消滅した後で同一のIDが新しい別のオブジェクトにアサインされる可能性については特に規定されていません)。さらに内部的なIDだけでなく、URIを割り振ることもできます(これも必須ではありません。MAYと表現されています)。ただし、URI自体の検証や外部接続性等々についての細かい規定はCMISの対象外となります。



各オブジェクトには属性が定義されます。属性は必ず名前をもちますが、厳密な順番付けは必要としません。(ただし、同一リポジトリの同一クラスの属性のセットについては常に一貫した順番で取得できることが求められています)属性には、String(文字列 xsd:string)・Decimal(小数 xsd:decimal)・Integer(整数 xsd:integer)・Boolean(真偽値 xsd:boolean)・DateTime(日付 xsd:dateTime)・URI(URI xsd:URI)などの型が用意されています。また、ID(xsd:string)とXML(xs:any)とHTML(xs:any)という3つ独自の属性型も定義されています。IDがxsd:idではないことに注意してください。XMLとHTMLはそれぞれのマークアップ言語の断片を格納します。



文書



リポジトリの最も基本的な構成要素です。格納可能で独立したオブジェクトです。他の基本オブジェクト型とは違い、いわゆるファイルの実体にあたるContentStreamをもっています。ContentStreamはバイナリのデータ列で、その最大長はリポジトリの実装に依存します(特に規定はありません)。また、各ContentStreamにはMIMEタイプが設定されます。ContentStream自体には名前はつかず、文書オブジェクトを経由することになります。



CMISではContentStreamに対するCRUD操作のサービスも定義されています。setContentStreamサービスは文書オブジェクトに対して新しいContentStreamを割り当てる、あるいは既存のContentStreamを置き換えるという操作を行います。getContentStreamでは対象の文書オブジェクトのContentStreamを取得します。削除はdeleteContentStreamサービスです。さらに、編集後の文書をチェックインするcheckInサービスによってもContentStreamは更新されます。以上が、ContentStreamを直接操作することになるメソッドのすべてです。属性取得のgetPropertiesや検索クエリ経由ではContentStreamそのものを取得することはできません。また、setContentStreamやdeleteContentStreamの操作はそのContentStreamを保持している文書オブジェクトそのものについての更新行為とみなされるため最終更新日を保管する属性LastModificationDateの値も更新されます。



フォルダ



フォルダは他のオブジェクト(主に文書オブジェクトとサブフォルダになるフォルダオブジェクト)をリポジトリの階層構造を構成する基本要素です。それ自身も格納可能なオブジェクトであり、独立したオブジェクトでもあります。文書オブジェクトとは異なり、ContentStreamを持ちませんしバージョン管理の対象にもなりません。フォルダは親となるそのフォルダ自身を格納しているフォルダと、子となる「格納可能なオブジェクト」の集合から構成されます。



CMISのフォルダには他の基本オブジェクトにはない2つの制約がかけられています。1つは「全体のルートであるRoot Folder以外のフォルダオブジェクトは、必ずただ1つの親フォルダを持つ」、もう1つは「循環する包含関係は成立しない。自分自身を子孫にもつフォルダは作成できない」というものです。この2つからの帰結として、フォルダオブジェクトはリポジトリ内にツリー構造を構築することになります。(この制約は他の格納可能なオブジェクトには設定されていません。マルチファイリングが可能なリポジトリでは、複数のフォルダに格納される文書が存在しえますし、アンファイリングをサポートするリポジトリにはどのフォルダにも格納されない文書というものがありえます)



格納するオブジェクトのタイプに制限をかけることも可能です。フォルダオブジェクトにはAllowedChildObjectTypeIDsという復数の値を持ちうる属性が定義されており、そこに格納を許可する格納可能なオブジェクトのタイプの集合をセットします。この属性が設定されていない場合はすべての格納可能なオブジェクトのタイプが許可されたことになります。(オブジェクトタイプによる格納制限の機能をもたないリポジトリ製品の場合はこの値を設定しないことで整合をとります)



フォルダオブジェクトに対してもCRUD操作のメソッドが提供されています。オブジェクトをフォルダに格納するaddObjectToFolderサービス。フォルダからオブジェクトを取り除くremoveObjectサービス。オブジェクトの移動をさせるmoveObjectサービス。ツリー構造毎取り除くdeleteTreeサービス(アンファイリングのサポートがあれば取り除かれたサブツリーを保持されるが、そうでない場合は予め格納されているオブジェクトを削除する必要がある)。フォルダ構造のナビゲートして各種ノードの情報を取得するためのgetChildren、getDescendants、getFolderParent、getObjectParentなどのサービスがあります。ツリー構造のトラバースが深さ優先か幅優先かはリポジトリ製品の実装に依存します。ページング機能についても特に規定はありません。



フォルダの階層構造によるパスは"/"区切りで表現されます。また、文書オブジェクト自体はパス表現を持ちません。



関連



関連は、独立したオブジェクトではなく、ContentStreamを持たず、バージョン管理もされず、クエリの対象外で、格納可能でもありませんが、コントロール可能なオブジェクトです。つまり、関連の関連はつくれず、フォルダに格納されることもありませんが、ポリシの適用は受ける可能性があります。関連は、文書・フォルダ・ポリシなどの独立したオブジェクトを2つ、ソースオブジェクトとターゲットオブジェクトとして指定する形でそれらの関係性を表現するオブジェクトとして作成されます。関連は対象のオブジェクトを「汚染しません」。対象のオブジェクトに対して関連を設定したり、その関連の状態を変更しても、それらのオブジェクト自体が更新されたとはみなされません。(結果としてLastModificationDateの値も変わりません)



1つのオブジェクトに複数の関連を設定することもできますし、同じソースオブジェクトとターゲットオブジェクトの間に別の関連をさらに設定することも可能です。関連づけされているオブジェクトが削除された場合に関連を自動削除するかどうかについてはリポジトリの実装依存となります。また、関連自体にもタイプ付けが可能であり、アプリケーション独自の属性が割り当てられる可能性があります。



関連についてもベーシックなCRUD操作のサービスが提供されます。生成はcreateRelationshipサービスで行い、削除にはdeleteObjectサービスを使います。関連独自の操作としてはgetRelationshipsサービスを使って対象のオブジェクトに設定されている関連のセットを取り出すという方法も提供されています。



ポリシ



ポリシはアクセスコントロールリストや有効期限管理などの管理的な操作に関する情報を表現するオブジェクトです。しかし管理的な操作の詳細定義はCMISのスコープ外であるため、ここでは基本的なモデルだけが定義されています。詳細の機能はリポジトリ製品に依存しますが、このポリシオブジェクトを使うことでそれぞれの機能を識別するための文字列をハンドリングすることができるようになっています。



ポリシオブジェクトの生成、管理だけでなく、個々のオブジェクトにそれらのポリシを適用するための仕組みも定義されています。ポリシを適用できるオブジェクトを、「コントロール可能なオブジェクト」と呼びます。ポリシとそれらのオブジェクトの関係は多対多です。1つのポリシを複数のオブジェクトに適用することも、1つのオブジェクトに複数のポリシを適用することもできます。ポリシの適用は関連の設定と異なり対象のオブジェクトの状態を変更します。



ポリシのCRUD操作についても基本的なサービスが提供されています。createPolicyサービスで作成し、deleteObjectサービスで削除できます。独自の操作としてはポリシの適用を行うapplyPolicyサービス、適用済みのポリシを取り外すremovePolicyサービス、適用されているポリシのリストを取得するgetAppliedPoliciesサービスなどがあります。



��文責 Ishii Akinori ITC)

ようやく策定されたECMのための共通言語 CMIS(1/3) (Insight Now!より転載)

ECM業界の主要プレーヤ達が共同で策定した新しい規格、Content Management Interoperability Service (CMIS)についての概要説明をしていきます



 9月10日にIBM、EMC、Microsoftという現在ECMの世界でも特に強い影響力を持っている3社が共同開発した仕様「Content Management Interoperability Service(CMIS)」をOASISへ提出予定であるという発表がありました。この3社が協力した、というだけでもECMという分野の中では非常に大きなインパクトを持ちますが(IBMはFilenetを、EMCはDocumentumを買収して製品ラインナップを整えています)、さらにAlfresco、Open Text、Oracle、SAPの4社が合流し、メジャーどころすべてが関与した本格的な業界標準ともいうべき仕様になっています。



 直訳すると、「コンテンツ管理相互運用サービス」、つまり、異なるコンテンツ管理システム(ECM製品)の間での相互運用を可能にするための規格です。「ECMの世界の(RDBMSで言うところの)SQLを作る」という野心的な試みと言えるでしょう。



 具体的にはRESTとSOAPで呼び出すことができるメソッドの名前と仕様を共有化していく、というアプローチをとっています。したがって、この仕様で定められた名前のメソッドを呼び出す形でリモートからECMリポジトリの機能へアクセスする、というアーキテクチャで構築されたアプリケーションは、背後にたてるリポジトリの土台が他のECM製品になってもそのまま動作させることができる、ということになります。



 本稿では3回にわけてこのCMISの仕様の概要を紹介していきたいと思います。第1回の今回は仕様の概要を、第2回ではそこで前提となっているデータモデルについて、第3回では実際にサービスとして規程されている各メソッドについての説明をしていく予定です。



 まず、この野心的な取り組みの第一歩として今回のバージョン0.5のカバー範囲がどこまでなのか、という定義から仕様書はスタートしています。この仕様のユースケースを例示していくというスタイルで、ECM製品の基本機能を活用する「コアECMサービス」、それらECM製品の上にアプリケーションを構築することで実現する「ECMベースアプリケーション(原語ではECM Applicationですが)」、加えて今回対象としなかったユースケースのサンプルとしての「スコープ外」という3つのカテゴリが提示されています。



 「コアECMサービス」の枠では、コンテンツ生成コラボレーション、ポータル構築、マッシュアップの3つのユースケースが挙げられています。コンテンツ生成の場としてのECMリポジトリ、企業ポータルの構成要素(時として基盤として活用されるECM製品もありますが)としてのECMリポジトリ、マッシュアップ対象としてのコンテンツ(あるいはコンテンツ断片)提供元としてのECMリポジトリ、といった形で、現代的なECMリポジトリの活用方法が一通りカバーされていると言えるでしょう。



 次に、「ECMベースアプリケーション」のカテゴリ。自動アーカイブ、ヴァーチャル(合成)文書、eディスカバリーの3つが提示されています。コンテンツと属性情報のハンドリングというECMの基本サービスを適切に組み合わせることで、個別に実現可能な機能ですが製品によって実現方法に差があったり、あるいは標準機能として提供されていなかったりする領域ですので、ECMベースのアプリケーションという切り口で整理するのは非常に理に適っているのではないかと思います。



 最後に「スコープ外」と識別されたユースケース群ですが、レコードマネジメント、デジタルアセットマネジメント、Webコンテンツマネジメント、購読管理の4つです。非常に注目度が高い領域ではあるのですが、今回は直接のスコープからは外されています。上述2つのカテゴリに含まれていたユースケース群と比べると若干粒度が大きいソリューションレベルのアイテムが並んでいます。



 また、実際に整備するAPIの範囲についても幾つかの領域をスコープ外にするという形で対象領域を定義づけています。具体的には、システム管理と設定、セキュリティ、認証、アクセス権、ローカライズ、5つがスコープ外となっています。これらの操作を行うためのメソッドというのは今回のバージョン0.5のAPIセットの中には含まれていません。複雑であり仕様策定が困難であったことはもちろんですが、やはり製品毎の差が大きすぎるということもこうした作業範囲の絞り込みが実施された背景にはあるのではないかと思います。



 まとめますと、今回のスコープは、ECMの基本的なサービスを共通基盤上で提供していくということが大きな目的としてあり、実際に提供されるAPIはコンテンツやメタデータの物理的な操作に直結したものが中心である、ということになります。



 次回は、リポジトリ、文書、フォルダ、関連、ポリシ、といったこの仕様上で識別されている各種モデルの詳細に入っていこうと思います。



��文責 Ishii Akinori ITC)

2008年9月12日金曜日

Alfresco Provides First Draft CMIS Implementation via Alfresco Labs

Alfresco Press Releases - Alfresco Provides First Draft CMIS Implementation via Alfresco Labsalfresco.com

こんにちは。aegif技術担当役員の石井です。

先日、Alfresco社から重要な発表があったのですが、ご紹介が遅れてしまっていました。予てよりIBMやEMCをはじめとする大手ベンダーと協力して策定していたECMのためのSQLにあたる規格、CMISの仕様のドラフトが作成されOASISに提出されました。しかも、単に紙上でのスペックに留まらず、Alfrescoの新バージョン上で試験実装まで完了しているとのことです。

CMISはContent Management Interoperability Serviceの略で、日本語に訳すと「コンテンツ管理の相互運用サービス 」とでも言ったところでしょうか。以前はiECMという名前で検討されていたものの進化形ということになると思います。他にもこの分野における標準化の動きとしてはJCR(JSR-170)などの規格がありましたが、今回はIBM、EMC、Microsoftに加えAlfresco、Opentext、Oracle、SAPなども含めた広範な賛同者がいるということと、言語を限定しない仕組み(例えばJCRは基本的にJavaのみ)という所が新しく、実際に普及に対する期待がもてるのではないかと思います。

例えば最新版からAlfrescoに付属しているSharePoint的な第2のクライアント「Share」なども、この仕組みを使って将来他のECMリポジトリ上で実行させるようなことも可能になるかもしれません。

仕様の中身の具体的なポイントやAlfresco最新バージョンについてのお話も、また機会をみてさせて頂こうと思います。

��文責 Ishii Akinori ITC)

2008年8月17日日曜日

CRIX International Eases Pharmaceutical Processes with Red Hat and Alfresco Solutions

Alfresco Press Releases - CRIX International Eases Pharmaceutical Processes with Red Hat and Alfresco Solutionsalfresco.com

こんにちは。aegif技術担当役員の石井です。

金融業界と並んでいわゆるECM製品の中心的な市場である製薬業界に関連したAlfrescoのニュースがあがっていました。
米国食品医薬品局 FDA由来の非営利コンソーシアムであるCRIX(Clinical Research Information Exchange)が、コラボレーション基盤にAlfrescoを採用したそうです。他にもRHELやJBoss Portalなどもあわせて採用されているようなので、積極的にオープンソース製品を採用したのだということがわかります。やはり公共的な組織によるオープンソースの採用が進んでいるということでしょうか。

製薬業界はその複雑なワークフローと文書に対する法的な保管要件の厳しさから文書管理システムの大口顧客でありつづけた経緯があります。今回のリリースの段階ではまだワークフロー自体は深く追求されていないようですが、将来プランとしてjBPMを積極的に活用したワークフローの実現についても言及されています。

��文責 Ishii Akinori ITC)

2008年8月15日金曜日

Alfresco Wins InfoWorld’s “Bossie” Award for Second Consecutive Year

Alfresco Wins InfoWorld’s “Bossie” Award for Second Consecutive Yearalfresco.com

こんにちは。aegif技術担当役員の石井です。

またアワードについてのリリースが出ています。AlfrescoのLabs(少し前までCommunity Networkと言われていたいわゆる無償版のことです)がIDGの2008年のベスト・オブ・オープンソース賞”Bossie”を獲得しました。もちろん企業向けアプリケーションの部門で、です。今回は、前年度に受賞した製品が引き続き受賞したというケースが非常にまれで、Alfrescoはそのうちの1つ、ということのようです。(他にはVoIPのAsteriskとCRMのSugarCRMが同じく連続受賞のようですね)

これまで、AlfrescoはハイエンドECM製品と同等の安全性・スケーラビリティと共有フォルダ同様の操作性の両立、ということを製品の特徴として強調してきたと思います。しかし、今年に入ってからは、Microsoft社のSharePointのプレゼンスが急速に高まっているということもあり、そのオープンソースオルタナティブ、という側面もまたクローズアップされるようになってきました。共有フォルダはOSのファイル管理の使い勝手をそのまま延長したものであり、SharePointはOffice製品とのシームレスな連携、つまりは操作性の高さをそのセールスポイントの1つとしています。「安全性・スケーラビリティと操作性の両立」、さらには「それをオープンソースで実現する」、というAlfrescoの戦略と実績が今回も高く評価された、ということだと思います。

��文責 Ishii Akinori ITC)

2008年8月12日火曜日

Canonical To Offer Alfresco Labs Pre-Packaged Within Ubuntu Distribution

Alfresco Press Releases - Canonical To Offer Alfresco Labs Pre-Packaged Within Ubuntu Distributionalfresco.com

こんにちは。aegif技術担当役員の石井です。

ビジネス上のインパクトはあまりないかもしれませんが個人的には少しだけ嬉しいニュースが入ってきました。ubuntuのCanonical社が提供するパートナーリポジトリにAlfrescoのLabs3が含まれるようになってそうです。LinuxマシンのセットアップからAlfrescoのサンドボックス構築までが非常に簡単になりました。Zimbraあたりも同じ仕組みで提供されているので企業向けのアプリケーションの検証環境としてもなかなか面白いのではないでしょうか。
#日本語ランゲージパックも常に最新のものを同梱できるようになるといいのですが・・・

��文責 Ishii Akinori ITC)

2008年8月2日土曜日

Alfresco Gives Microsoft Office Users a SharePoint Alternative

Alfresco Press Releases - Alfresco Gives Microsoft Office Users a SharePoint AlternativeAlfresco.com

こんにちは。aegif技術担当役員の石井です。

ついに、Alfresco無償版の新バージョンの姿が明らかになりました。今までCommunity Networkという名前で公開されていた無償版ですが、今回からAlfresco Labsという名前で公開されています。プレスリリース自体の表題にも含まれていますが、今回は対SharePointの姿勢をより一層強調したバージョンになりました。AlfrescoはSharePointよりも大規模なリポジトリを扱っていたいわゆるEDMSの流れを組む製品ですが、Alfresco自体がオープンソースモデルによって比較的低価格を実現したという点と、AIIMでも話題になるほどSharePointの機能強化やMicrosoft社の強力なプロモーションもあって、SharePointファミリと比較されることが多くなってきています。

これまでのところAlfrescoのメリットとして我々では、「スケーラビリティ」「非MS製品への対応力」「追加開発の容易さ」などを強調してきました。逆に言えば、規模と利用頻度がある程度予測でき、常に最新のWindows OSとOfficeファミリを利用していく方針が正式に決定していて、なおかつ複雑なシステム連携が必要とされない状況であれば、Alfrescoをわざわざ持ち出す理由はないだろうな、という認識でした。やはりすべてを同一ベンダの製品で統一することによる操作感上のメリットというのは否定しがたいものがあります。Alfrescoも独自にWordやExcelのアドインを提供することでそれらの製品から透過的にAlfrescoリポジトリにアクセスできるようにしていましたが、あくまでアドインですので、操作性も完全に統一されているわけではありませんし、なによりAlfrescoのコンセプトの1つであるゼロフットプリントに抵触してしまっています。今回のバージョンでは強力に機能強化されたRESTful APIとスクリプティングの機能を使って、SharePointのサービスと同等のインターフェースを実装する方針を採用したようです。これによりクライアントのWordやExcelはSharePointへ接続しているつもりで(つまりは統一的な操作感を維持したままで)よりオープンで強力なAlfrescoリポジトリへアクセスできるようになります。RESTful APIの強化自体もかなり可能性を感じさせるポイントなのですが、このSharePointコンパチブルという方向性はそれを端的に示すものとしても非常に面白いのではないかと思います。

他にも重要な点としてAlfresco Shareというクライアント製品が同梱されるようになっています。今までのWebclientとは別に、これもまたSharePointライクといいますか、コラボレーション環境としての使い方にフォーカスした作業環境を実現するWebアプリケーションに仕上がっています。Siteという単位で複数のプロジェクト単位の作業領域を作成することができ、そこには文書の保管庫の他にディスカッションやカレンダーが含まれています(以前のバージョンでもプロジェクトスペースとして提供されていた機能が大幅に強化されたイメージだと考えてください)。このSiteはAlfresco上は特殊なスペース(フォルダ)として作成されているので通常のWebclientからも中身を確認することは可能ですが、Alfresco Shareを通じたアクセスをした場合により利便性の高い環境を提供できるようになっています。たとえばSiteごとに「自分がチェックアウト中のファイル」「誰かがチェックアウト中のファイル」などの条件でフォルダ構造を無視したファイルのフィルタリング表示が標準で設定されていて、そこにカテゴリなどの独自のフィルタ定義を混ぜ込むことができたり、Site毎とSite横断のカレンダーイベントを一覧でみることができたり、と文書を中心とした業務ポータルの土台としてかなりの完成度を持っているのではないかと思います。このあたりは近いうちにもっと突っ込んだご紹介(たとえばセミナーなど)をしたいと思います。

��文責 Ishii Akinori ITC)

2008年7月30日水曜日

Documentum 6.5リリース

リンク: Press Release: Content Management Meets Web 2.0 Without Enterprise Risk: EMC Delivers Version 6.5 Of Documentum ECM Suite.



こんにちは。aegif技術担当役員の石井です。



Alfrescoにとっては競合になりますが、コア開発メンバーの古巣であるDocumentumのチームが新製品をリリースしました。EMC買収後のバージョンアップの中でも特に大きな意味を持つリリースになりそうです。



特に目を引くのは、Web2.0対応(タスク指向のコラボレーション環境の提供)と軽快なドキュメントモデル(High-Volume)の採用の2点です。



Documentum製品はクライアントサーバ型のデスクトップクライアントからWebベースのクライアントへと移行してきた歴史を持っています。ユーザに対する操作モデルの改変だけでなくJavaアプレットを含めた実装テクノロジも変遷をとげており、その流れの中からでてきたWeb2.0的インターフェースというのは興味深いと思います。Alfrescoの場合は次のバージョンで現在の「Web2.0」インターフェースであるJSF+Ajaxのものを棄てて、さらに新しい展開を見せる予定なので、その比較というのもAlfresco側の形が見えてきた段階でやってみたいと思います。



次にHigh-Volumeについてですが、大量の帳票データなどDocumentumのようなECM製品が持つ重厚なコンテンツモデル(標準ですべてのファイルに割り当てられる属性情報)を一元的に割り付けられることが不合理なものに対して、より軽快なモデルを適用するという考え方のようです。確かにマニュアル編集が全く発生しないファイル群にバージョン管理用の管理データがぶら下がるというのは合理的ではありません。Alfrescoは基本モデルにはあまり属性情報を定義せず「アスペクト」という形で後から割り振る仕組みなので、こういった問題ははじめから存在しないわけですが、他の製品からHigh-Volumeというキーワードで新しくこういう仕組みがリリースされるというのは、面白いと思います。Alfrescoは後発であることのメリットを活かして、従来型のコンテンツに対してもHigh-Volumeなものにも統一的な仕組みで対応できるようにしているのに対し、Documentumは基本設計自体を2本並列させることにしたわけです。統一することのメリットも専門特化することのメリットもそれぞれ当然あると思われますので、今後はECM製品選定の切り口としてこういった下層の基本設計がより明示的に問われることになるかもしれません。



(文責 Ishii Akinori ITC)



Rivet Logic and Alfresco Selected by New Gravity Ventures to Develop Large Scale Social Networking Application Using the Facebook® Platform

リンク: Alfresco Press Releases - Rivet Logic and Alfresco Selected by New Gravity Ventures to Develop Large Scale Social Networking Application Using the Facebook® Platform.

ConnectedWeddings.com



こんにちは。aegif技術担当役員の石井です。



先日もご紹介した通り、Alfrescoは企業向けシステムとしては珍しく、SNSサービスのFacebookとの連携を実現しています。Facebookは国内の主要なSNSであるmixiなどとは違ってそのシステム内に日記などのコンテンツをためていくというよりは、各種の外部Webアプリケーションへのインターフェースを集約する個人向けポータル的な利用がなされています。ユーザはFacebookにさえログインすれば複数のアプリケーションからの情報を一覧でき、またFacebook上で繋がっている友人知人とそのアプリケーションを共有することもできます。アプリケーションプロバイダはFacebookの豊富なユーザ層が潜在顧客となり、またSNSならではのユーザ同士の人間関係にのった展開も期待できます。



今回発表されたのはAlfrescoそのものへのアクセスを提供するという話ではなく、このエコシステムにのった新しいサービスがその基盤としてAlfrescoを採用した、というニュースです。ConnectedWeddings.comというサービスで、Facebook上で結婚式の準備を進められるというもののようです。案内を送ったり、会の写真を共有したり、と色々な展開が期待できそうです。



国内でもAlfrescoを基盤としてSaaSモデルで新しいサービスを立ち上げるという事例が増えてきています。顧客のデータを格納する保管庫として一定以上の安全性を確保するためにAlfrescoを活用し、認証基盤やユーザプールを(あるいはGUIも)Facebookに任せるというコンセプトは非常に合理的です。今後はこういうスタイルのサービスが増えてくるのではいかと思います。



(文責 Ishii Akinori ITC)



2008年7月28日月曜日

アドビ システムズ社、LiveCycle Enterprise Suiteを拡張した新製品「Adobe LiveCycle Enterprise Suite Update 1」を発表

リンク: About Adobe - Press Room -アドビ システムズ社、LiveCycle Enterprise Suiteを拡張した新製品「Adobe LiveCycle Enterprise Suite Update 1」を発表.



こんにちは。aegif技術担当役員の石井です。



ミドルウェアとしての(バックエンドエンジンとしての)ECMの利用という意味でまた一つ面白い事例がでてきました。AlfrescoのOEMプログラムを活用してAdobe社が自社のPDF関係製品ファミリーを拡充しています。



実は先日、米国ワシントンDCでAlfrescoの新しいトレーニングを受講してきたのですが、そこにもAdobe社からの受講者が数名来ていました。Alfrescoのコンセプトからすると印刷禁止などのクライアント依存技術は積極的に採用されづらかったため、従来からもAdobe社製品との連携の事例はあったのですが、それがまた一つ推し進められた形とも言えるかもしれません。ECMの製品の活用方法のショーケースとしても、これからのPDF文書の管理レベルのリファレンスとしても、非常に興味深い製品であると思います。



(文責 Ishii Akinori ITC)



2008年7月26日土曜日

Alfresco Software Receives 2008 Editor’s Choice Award from Business Computing Magazine

リンク: Alfresco Press Releases - Alfresco Software Receives 2008 Editor’s Choice Award from Business Computing Magazine.



こんにちは。aegif技術担当役員の石井です。



先月の上旬のことですので、若干ご紹介の時期を逸した感もありますが、Alfrescoがまたアワードを受賞したという話題がプレスリリースで紹介されていました。



ビジネスコンピューティングマガジン(Business Computing Magazine)の2008年エディターズチョイスという賞だそうです。ビジネスコンピューティングマガジンは2005年からWeb出版の形でビジネスユーザ向けにITの情報を発信している雑誌で、毎月各種プロプライエタリのものも含めたビジネスソフトウェア、ハードウェアなどのレビューを掲載しています。最新号ではAlfrescoに対して、オープンソースのCMSの中で最高ランクのものであること、Web2.0関係の機能が充実していること、特にネガティブな要素がみあたらないこと、などが目立った特徴として記載されています。



他にはいくつかの仮想化のソフトウェアや、Spam Firewallをはじめとするインテリジェントなネットワーク機器などが紹介されており、英語圏ではコンテンツ管理がビジネスユーザ向けのメディアでも一定の存在感を持っているということがよくわかります。



(文責 Ishii Akinori ITC)



2008年7月24日木曜日

Capgemini incorporates Alfresco into the French Air Force Document Information System

リンク: Alfresco Press Releases - Capgemini incorporates Alfresco into the French Air Force Document Information System.



ごぶさたしています。aegif技術担当役員の石井です。



前回の投稿からもまたかなり間があいてしまいました。弊社としてもAlfrescoに絡んだビジネスは継続的に展開中で、近くまた色々と発表させて頂くものもある予定なのですが、そういった話題の多さが逆に一つ一つのトピックをBlog記事化するモチベーションを阻害していたようです。Alfrescoの注目度は日に日に増しているため、日本語での情報発信という意味で我々の責任も重くなってきています。このBlogだけではありませんが今後はさらにアウトプットを増大させる努力をしていくつもりです。



さて、前回からのブランクの間にAlfresco社からも何件か重要なプレスリリースがありました。これから数回にわけてご紹介していきたいと思います。



まず、第一弾ですが、キャップジェミニ社と共同でフランス空軍の技術文書センターへのAlfrescoの導入に成功しました。「文書管理機能における所定の要求水準を満たす」「オープンソースで、なおかつ各種の標準に準拠している」という二つの基準をもって製品選定をした結果、Alfrescoが選ばれた、という経緯がリンク先のプレスリリースの中で紹介されています。



「オープンソースであること」そのものが要件となっているという部分は、非常に欧州的であると感じますね。機能要件に関しては以下のようなものが列挙されています。



* 紙文書のデジタル化(別のサービスと連携)

* 空軍文書リポジトリの管理

* 電子出版と配信

* 指図の管理と計画

* 各種アクティビティのモニタリング



このプロジェクトもプロプライエタリのECM製品上に構築されたシステムをオープンソース製品(Alfresco)で置き換えていく、というやりかたで実装されています。2002年から計画されたプロジェクトで、2007年11月に第一フェーズが完了。プロジェクト全体としては2009年3月に開発を完了する予定のようです。ECM製品は重厚な追加開発をされていることが多いため、今後はこういう案件はさらに増えていくのではないかと思います。



(文責 Ishii Akinori ITC)



2008年5月30日金曜日

ECM製品の基本的な仕組み(Insight Nowより転載)

技術的な面からECM、EDMSの製品のアーキテクチャを簡単にご紹介することで、実際にそれらのシステムでどういうことができるのか(技術的な意味では、それらのシステムの内部でどういうことがおきているのか)をご紹介したいと思います。



 前稿では今現在ECM(企業向けコンテンツ管理)製品と呼ばれている製品が、かつて電子的文書管理システムEDMSと呼ばれていた製品群の系譜にあり、SOAのニーズに対応する正統進化形であるというお話をさせて頂きました。本稿では、技術的な面からECM、EDMSの製品のアーキテクチャを簡単にご紹介することで、実際にそれらのシステムでどういうことができるのか(技術的な意味では、それらのシステムの内部でどういうことがおきているのか)をご紹介したいと思います。



 今回も、電子的文書管理システムEDMSの初期製品群に多く見られたアーキテクチャから順を追って現在のECM製品のアーキテクチャまでをご紹介するという形で、EDMSからECMへの流れに沿ってご説明します。



 

初期EDMS



 当時はクライアントサーバ型のアプリケーションが全盛であったため、基本的な構造はそれにならったものになっています。各クライアントPCには専用の EDMSクライアントソフトウェアを導入する必要がありました。この方式は、すべての文書のやりとりをクライアントソフトウェアのレイヤで押さえることができるため、アクセス制御や操作記録の取得のためには有利でした。しかし、ソリューション実現のために必要な追加開発も、ある程度の部分は「クライアントソフトウエアの改修」という形で行わざるを得なかったため、保守性という意味では多くの課題を抱えていました。また、サーバ側ですが、基本的には文書の実体を保存するファイルシステムと文書の付帯情報(属性、メタデータ)を保存するデータベースの 2つのコンポーネントをラッピングした作りになっていることがわかります。データベースに属性情報専用の記憶領域を用意することで、標準ファイルシステムが持つ属性の制限(所有者、最終更新日など)に捕らわれず各文書とそれを利用する業務に必要な各種付帯情報を一括管理できる、というのが以後ECMまで続く一連のコンセプトの根幹をなしているアイデアです。この属性情報を操作することで、文書のステータス管理やワークフローなどの複雑な機能が実現されてきました。



 

後期EDMS



 このタイプは初期型EDMSが近年のIT環境の変化の中で成熟していった結果であると言えます。やはり、インターネットの影響は大きく、Webアプリケーションとしてクライアントインストールを要求しないモデルの製品が増えてきました。これにより初期のEDMSの最大の問題点であった保守性は、それなりに向上したと言えそうです。また、他の業務システムとの連携に対するニーズも高まる一方であったため、各種の「ブリッジ」「コネクタ」と言われるオプション製品が各EDMSベンダから発表されました。これらの連携ソリューションは製品設計のターゲットに近い利用形態であれば非常に強力なものとなりえましたが、連携対象とEDMS製品の双方に対するバージョン依存や利用事例の少なさからくるソフトウェアの品質の問題で広く普及するには至らなかったようです。また、これは初期の頃からも言われていたことですが、「ホワイトカラーの業務時間の80%が情報の探索に消費されている!」というスローガン(?)のもと、コンプライアンス向上だけでなく業務効率向上に繋がる機能が強く求められました。インターネットの世界での検索エンジンの台頭とあわせて各EDMS製品に実効的な全文検索エンジンが搭載されたのもこの世代の製品群の特徴と言えそうです。これ以降、前述のファイルシステムとリレーショナルデータベースに加えて全文検索エンジンもこれらの製品の柱となる要素の一つに数えられるようになりました。



 

ECM



 最後に現代の製品群のアーキテクチャをご紹介したいと思います。ご覧の通りその実態は後期EDMSとほとんど変わるところがありません。つまり、誤解を恐れずに言い切ってしまえば、EDMSからECMへの進化の過程にこれといって大きな技術的なブレークスルーは存在しなかった、ということの証左でもあるかと思います。それでも、文書からコンテンツ(=企業内の全ての非定型データ)と対象を広く捉え直しより広い範囲で単一のリポジトリを活用するモデルを提示したことと、それをSOAを背景とした標準的な手法で統合するという方法を実現したことのインパクトはそれなりに意味があるものだと思います。





 上記の「後者のSOAを背景にして」の部分は前稿からの筆者の主張でありますが、「文書からコンテンツ」のところに関しては込み入った議論がありますので、次稿にて所謂CMSとここでいうECMの違いという形でもう一度ご説明したいと思います。555_1210581101_1_2

555_1210581101_2_2

555_1210581101_3_2



2008年5月28日水曜日

SOA時代のファイル(情報)管理基盤 ECMとは (Insight Nowより転載)

 ECM - 企業向けコンテンツ管理というキーワードは、ERPやCRMなどと並ぶ"ITに関するコンセプトとそれを実現するための製品群を示す言葉"として、ここ数年で急速に市民権を得たものの一つであると言えます。本稿ではECMを、SOA時代のファイル(情報)管理基盤、と位置づけ、その狙いや求められる機能などについて概説していきたいと思います。



 ECM - Enterprise Content Management、企業向けコンテンツ管理というキーワードは、ERPやCRMなどと並ぶ"ITに関するコンセプトとそれを実現するための製品群を示す言葉"として、ここ数年で急速に市民権を得たものの一つであると言えます。そのコンセプトを一文で表現するのであれば、「企業内のコンテンツを統一的なプラットフォームに集約し管理精度を向上させる」といったところでしょうか。AIIM(Association for Information and Image Management)という米国の団体では「ECM(Enterprise Content Management)とは、企業内全域に渡って、「コンテンツ」を、獲得capture・管理manage・保持store・保管preserve・配布deliverするための、技術やツールや手法のことである」という言い方をしています。



 本稿ではECMを、SOA時代のファイル(情報)管理基盤、と位置づけ、その狙いや求められる機能などについて概説していきたいと思います。



 まず、先ほどの表現における「企業内のコンテンツを」の部分から、考えてみましょう。ここでいう"コンテンツ"とは「企業内にある非定型データ」を意味しています。従来の業務システムで取り扱われるデータがRDBMSなどに格納される定型データであるのに対し、実際に企業内に存在する情報の大部分は実はWordやExcelなどのオフィスツールで作成された文書や電子メールなどの非定型データであると言われています。この非定型データを如何に効率良く管理していくか、というのが今後大きなテーマとなっていくだろう、というのがコンセプトとしてのECMの出発点です。



 次にそのコンセプトを実現するソフトウェアとしてのECM製品に必要な機能について解説したいと思います。非定型データ、という抽象的な言い回しを持ち出すまでもなく、文書というものはずっと以前から企業内に存在していましたし、その管理が大きな経営課題であることもよく知られていました。文書管理システム、電子的文書管理と言われるソリューションにはすでに数十年の歴史があります。ECMはそれらの議論の延長線上にあるものであり、ECM製品と呼ばれるソフトウェアは基本的にかつて文書管理システムと呼ばれたパッケージの機能を継承したものだと言えます。そのため、以下にご紹介する機能の多くが文書管理システムが伝統的に備えてきた機能でもあります。



「柔軟なアクセス管理機能」通常のOSレベルの読み書き権限よりも数段細やかな設定ができる製品が多いです。文書ファイル本体に対する読み書き権限とそのファイルの属性への読み書き権限を個別に与えたり、新規ファイルの作成はできるが既存のファイルは編集できないという権限や、逆に既存のファイルの編集はできるが新規ファイルの作成はできないという権限を設定することができます。また、文書毎のステータスに応じてアクセス権限設定を変更するという機能を持つものもあります。



「バージョン管理機能」各文書の過去バージョンを全てリポジトリ上に保存しておく機能です。操作ミス等による作業途中バージョンの散逸を防ぐだけでなく、コンテンツの編集経緯を共有できるというメリットもあります。



「チェックアウト・チェックイン機能」リポジトリ内のコンテンツを編集する際に他のユーザと同時書き込みを行ってしまうリスクを回避するために、あらかじめロックをかける機構です。チェックアウトの処理を実行すると、リポジトリ内の別の場所、もしくはユーザのローカルに「ワーキングコピー」と呼ばれるファイルが生成されます。そのファイルを編集した後でチェックインすることによりリポジトリ内のコンテンツのバージョンが更新されます。チェックアウトされている間、リポジトリ内のコンテンツ本体は編集不可の状態になります。



「独自属性の定義機能」業務上の要請により企業内の文書には様々な付帯情報が割り当てられています。どのような属性情報を持たせるかは文書の種類によって異なるため、多くの製品にユーザが独自に属性情報を定義する機能が備わっています。文書の種類によってアクセス権を変更する、などのコントロールを持たせることもあります。この文書の種別の特定と、管理すべき属性情報の定義は、文書管理やECMの導入プロジェクトの中でも特に重要なステップとなります。



「ワークフロー機能」各ユーザに対して「編集」「レビュー」「承認」などのタスクを依頼し、その流れを管理する機能です。予め定義された業務の流れに従って各タスクが実行されるため業務遂行の精度向上が期待できます。また、各ユーザは自分に割り当てられたタスクの一覧を常に確認できるようになります。専用の所謂ワークフローツールと違い、原則的には社内にある文書全てを同様の業務フローの遡上に載せることができるというのが、文書管理システム(あるいはECM)でワークフローを実現することのメリットであると言われています。



「監査証跡機能」リポジトリ内の各コンテンツに対して、いつ誰がどのような操作を行ったのか、を記録していく機能です。操作ログがコンテンツ管理に保管されていく形式が一般的であるようです。内部統制、コンプライアンスなどの文脈によって注目度が高まっている機能です。伝統的な文書管理システムの多くは高価なパッケージ製品であったため、強制力のあるコンプライアンスの法的要件をもつ金融業界や製薬業界での稼働事例が多く、この監査証跡機能も必須機能と認識されてきました。



 さて、ここまで挙げた各機能は、かつて文書管理システムと呼ばれていた現在のECM製品の祖先にあたるソフトウェアにもすでに備わっていたものばかりです。「コンテンツ」という用語の定義もすでにご紹介しましたので、管理対象が文書からコンテンツへとより抽象化されたのがECM製品である、という解釈をされている方もいらっしゃるかもしれません。それはそれで正しい見方であるとも言えるのですが、本稿においては表題にもあります通り、SOAの文脈を絡めた視点を提示したいと思います。



 SOA的な視座からシステム設計を考える時、そこにファイル単位の情報を保管あるいは流通させるのであれば、それらの情報の管理手法や管理精度に対してもある程度抽象的なインターフェースを提示し、他のコンポーネントとの連携方法を捉える必要があります。そこで要求される機能は、伝統的な文書管理システムが培ってきた上記の各種機能とほぼ同じものです。今までの文書管理システムは、中央集権的なリポジトリに各種文書を集約することで、各ユーザが適切な手法で文書を活用できるような基盤を提供していく、ということをしてきたわけですが、SOAの文脈においては人間のユーザだけでなく他のシステムも同様にこのリポジトリの恩恵にあずかるように方向付けていくことが求められている、というわけです。それを実現しているのが、現在のECM製品群であるといえるでしょう。(文書管理システムと他システムの連携ということ自体は以前からも積極的に行われてきたことですが、連携の方法がサービスという粒度で捉えられ、また標準的なプロトコルによって実行されるというところが相違点になると思われます)



 単純にECM製品と呼ばれるソフトウェアを導入し、重要文書から順に格納していくという方針でもコンテンツの管理精度を向上させることは可能です。しかし、本当にECMを効果的に導入しようと考えた場合は、現在あるいは将来の各ユーザと各連携対象システムのニーズに柔軟に対応できるような計画をたてて行く必要があります。基盤として活用されたときに最も効果を発揮する、という性質があるため、計画段階から慎重に導入製品を選定する必要もあるでしょう。



 次稿以降では、ECM製品の基本的な仕組み(物理的な構成要素)やWebコンテンツ管理のためのCMSと呼ばれる製品群との相違、オープンソースで実現するECMなどの話題に触れていきたいと思います。ECM導入計画の立案や製品選定などのご参考にしていただくことを目標に、順次記事をアップロードしていく予定です。



2008年5月26日月曜日

Alfresco Asia Pacific Community Conferenceに参加してきました

こんにちは、aegif技術担当役員の石井です。



先日、シドニーで開催されたAlfrescoのコミュニティカンファレンスに参加してきました。前回のパリに続いてaegifからは2度目の参加になります。アジアパシフィックエリアではやはり英語圏であるオーストラリアがAlfrescoの展開という意味ではかなり先行しており、事例紹介のトラックもかなり興味深いものでした。



パリの時に加納が書いた記事でも触れられていますが、今回も着席式でしっかりとしたランチが饗され、近くに座った人と「ネットワーキング」するという形式でした。(途中のティーブレイクとプログラム終了後のカクテルパーティは立食形式でしたが。)



参加者は、Alfrescoのパートナであり今回のホストであるLateral Minds社のメンバーや各ユーザ企業の担当者、近頃技術的な連携を深めているオープンソースDBベンダのIngresの人たちなど様々でした。特にIngresは参加人数といい、ノベルティといい、力が入っているようでした。



私はあまりこういった「ネットワーキング」的な会は得意ではないのですが、保険会社や医療関係の出版社のユーザ側の担当の方から事例のお話を聞いたり、ホストのLateral Mindsの技術者の方とRecord Managementの詳しい話を聞いたり、となかなか面白い収穫がありました。機会があればまた詳しいところをご紹介したいと思います。



(文責 Ishii Akinori ITC)



リンク: Alfresco Events - Alfresco Asia Pacific Community Conference.



2008年4月4日金曜日

企業結合会計が変わる:日本のM&A会計はどうなるのか(3)

前回、国際会計基準が定める企業結合会計は親会社説から経済的単一体説への転換がなされたということをみていきました。



今回はその他の改訂内容についても確認しましょう。その他の改訂点は公正価値による測定を一貫して行うように処理を定めたものであるといえます。







段階取得の処理



まず、段階取得の処理については過去に取得した持分の帳簿価額と公正価値の差額を損益とする処理が規定されました。過去に取得した持分が支配獲得時の公正価値により再測定されます。そのことで段階取得によって過去に取得した持分の価格がいくらであっても支配獲得時ののれんの金額が同じとなります。









従来は(日本の現行の処理も同じですが)過去に取得した持分の価格がのれんの金額に影響を与えていました。これでは過去の持分の取得の経緯によってのれんの金額が変わってしまうことになり、それが理論的でないというのが国際会計基準審議会(IASB)の主張です。段階取得でも一括取得であっても支配獲得時の公正価値が同じであればのれんの金額も同じであるべきと考えているのです。









偶発事象の評価方法



偶発事象については評価の方法が変わりました。従来偶発事象は引当金として処理されることになっていました。発生の可能性が高く、信頼性を持って測定が可能な場合に買収原価に含められていました。









改訂により、偶発事象も支配獲得時の公正価値で測定することになりました。企業結合では資産、負債を公正価値で測定するのが原則ですが、偶発債務だけ、「発生の可能性が高い」場合のみに認識するのは他の債務の認識と整合しないからです。非常に理論的ですが、実務上は偶発債務の公正価値をどうやって測定するのか、難しいところだと思います。 









取引費用の処理



取引費用というのは企業結合取引に関連して発生した費用で仲介手数料、弁護士費用、デューデリジェンス費用などのコンサルティング費用のことです。これらの費用は被取得企業の公正価値に含めていましたが、改訂により発生時の費用として処理することになりました。









被取得企業の公正価値に含めないとした理由は取引費用の金額によって被取得企業の公正価値が変わってしまうのは取引の実態にそぐわないからです。そもそもコンサルティングなどのサービスは提供を受けたときに消費されているもので企業結合取引とは別個のものと考えています。確かにコンサルティングにお金を掛けるほど被取得企業ののれんの金額が大きくなるというのはおかしい話です。 



























(文責 Yumiko Noguchi)

















































2008年3月28日金曜日

企業結合会計が変わる:日本のM&A会計はどうなるのか(2)

前回は、国際会計基準との差異を解消するため日本の企業結合会計を改訂する検討がなされていることをご紹介しました。それでは、日本が共通化を目指す国際会計基準では企業結合会計をどのように定めているのでしょうか。









国際会計基準はさらに先を行く



実は持分プーリング法を廃止するよりもっと先の「進んだ」会計処理が定められています。国際会計基準は米国会計基準との共通化プロジェクトのひとつとして企業結合に関する会計基準を改訂したばかりです。









ここで「進んだ」という表現を使ったのは従来採用されてこなかったような考え方に基づいた会計処理が採用されるようになったからです。それでは今年の1月に改訂された国際会計基準での企業結合会計を見ていきます。









国際会計基準審議会(IASB)から今年の1月に公表されたIAS 27「企業結合」、IFRS 3「連結及び個別財務諸表」の主な改訂点は以下のようなものです。





     少数株主持分に対するのれんの処理





     支配継続時の持分変動の処理





     段階取得の処理





     偶発事象の評価





     取引費用の処理









これらの改訂内容について、IASBから公表されている資料を見ていると、従来の考え方を大きく変更するものではないという説明がなされています。しかし、実際には経済的単一体説による処理が定められており、従来の親会社説によっていた連結財務諸表の基礎概念が変更されたことになります。









親会社説VS経済的単一体説



親会社説というのは連結財務諸表の作成目的は親会社の株主のためと考えます。それに対して、経済的単一体説では親会社株主だけでなく、少数株主も含めた企業集団のためであると考えます。この考え方の違いにより、今回の改訂内容にもある少数株主持分に対するのれんと支配継続時の持分変動の処理の仕方が異なることになります。































親会社説

経済的単一体説

少数株主持分に対するのれん

購入のれん説による処理

全部のれん説による処理

支配継続時の持分の変動

損益取引として処理

資本取引として処理









親会社説ではあくまでも親会社株主の視点に立つので他の企業を取得した場合のれんは親会社株主の持分についてのみ認識します。一方、経済的単一体説によれば親会社株主と少数株主を区別しないので親会社株主の持分だけでなく少数株主持分も含めたのれん全部を認識することになります。









全部のれん説の採用



今回の改訂ではこの全部のれん説による処理が選択適用できることになりました。全部のれん説を採用した理由は、支配を獲得すると取得企業は持分の割合にかかわらず被取得企業の資産、負債、経営活動の全てに責任があると考えられるからです。









親会社の支配が継続している状況で持分が変動した場合の処理もこの二つの考え方の違いにより処理が変わってきます。親会社説では少数株主は外部のものであると考えるので少数株主に持分を売買した場合、損益取引となります。しかし、経済的単一体説では少数株主との取引も株主と親会社との取引と考えますので資本取引となります。









このような改訂内容を見てどのように思われたでしょうか。日本では現在親会社説が採用されていますので、私たちの感覚とは大きく違うという印象をもたれる方も多いのではないでしょうか。























(文責 Yumiko Noguchi)











































































































2008年3月18日火曜日

企業結合会計が変わる:日本のM&A会計はどうなるのか

aegif blogでは、これから会計に関するトピックもご紹介していきたいと思います。よろしくお願いします。



今回は企業結合会計を取り上げます。





日本の企業結合に関する会計基準の改訂が現在検討されています。日本の会計基準は国際会計基準との共通化に向けて改訂作業を加速させていますが、日本の会計基準はどのように変わっていくのでしょうか。そして統合を目指している国際会計基準とは何なのか、企業結合会計を読み解きながら考えていきます。







228日付け日経新聞の朝刊に日本の企業結合に関する会計基準の改訂されることが報じられました。これは企業会計基準委員会から企業結合会計の見直しに関する論点整理が公表されたことを言っています。具体的には持分プーリング法を廃止するなどの改訂が検討されています。





持分プーリング法とは何か







持分プーリング法というのは買収などで取り込む企業の資産、負債を簿価で計上するというもので、国際会計基準や米国会計基準では認められていない処理です。なぜ認められていないかというと、簿価で計上すると、含み益のある不動産などがあった場合経営者は自分の好きなときにその含み益を出して利益を作り出すことができますし、濫用されてしまう可能性があるからです。





そもそも簿価で計上するという処理は、企業結合の当事者企業間に支配する、支配されるという関係でなく、対等な関係であるという実態に即したものと考えられているのですが、現実にはそのような企業結合の取引はほとんどないものと考えられています。





日本の会計基準と国際会計基準の考え方の違い



会計基準というものはできるだけ処理に選択の余地をなくし、例外的な取り扱いをなくしたシンプルなものであるべきだと考えられていますので国際会計基準などでは持分プーリング法を認めていません。





それでも日本では実態として当事者の企業が対等な企業結合はあると考え、一定の要件のもとに持分プーリング法を認めてきました。しかし、要件が厳しく実際に持分プーリング法によって処理された企業結合取引はあまりありませんでした。持分プーリング法を認めるという日本独自の意見を貫いてきたわけですがついにそれも取り下げざるを得ない状況になっています。





日本の会計基準が遅れていたわけではない、という日本独自の会計基準にこだわることを擁護する意見はありますが、独自性を貫こうとしたあまり国際会計基準との差異が広がってしまい現在日本は苦労しているというのは事実だと思います。今後も日本の会計基準は急ピッチで整備していく必要があり、実務を担当される方々には相当な負担となりそうです。





次回は日本の会計基準が統合を目指そうとしている国際会計基準では企業結合会計がどのように処理されるのか、国際会計基準の内容を見ていきたいと思います。







(文責 Yumiko Noguchi)