公式文書のプロセス管理におけるSOA適用例

都道府県CIOフォーラムとは、各都道府県および関係団体の情報化統括責任者（CIO）または情報化推進担当責任者（役職等は問わない）をもって構成する任意団体です。
日本アイ・ビー・エムでは、2007年2月に開催された春季会合でも講演を行いました。 「強固なセキュリティーを実現するアーキテクトアプローチ」　都道府県CIOフォーラム春季会合でIBMが講演 8月30日（木曜日）から31日（金曜日）まで佐賀県武雄市で開催された、第5回都道府県CIOフォーラム年次総会では、海外からの講演者や総務省の情報政策企画官などから、組織・地域に変革を起こすCIOの役割や電子自治体の推進に向けた総務省の取り組みについてなど、興味深い講演が行われました。
日本IBMでは、IT企業という立場からこのフォーラムに協賛しており、今回、「公式文書のプロセス管理におけるSOA適用例」というテーマで講演を行いました。

高度な処理の共通化で開発コストを削減
SOA/Web2.0ベースの文書処理環境「DOLCE」

日本IBM
公共事業CTO技術理事
長島哲也 地方自治体や中央省庁における基幹業務とは何か。日本アイ・ビー・エムでは、このような“最も根元的な問い”に立ち戻り、新たな提案を始めています。SOAとWeb2.0に基づく文書処理・管理環境「DOLCE（ドルチェ）」を提案し、公的文書の処理プロセスを支えるシステムを、低コストかつ短期間で実現できる方法論をご説明しました。

「製造業でも金融業でも、ビジネスの根幹をなす“基幹業務”というものがあります。それでは地方自治体や中央省庁の基幹業務とは何か。私たちはこの最も基本的な視点からスタートしました」と、日本アイ・ビー・エムの公共事業CTO長島哲也は話します。その結果導き出したのは、「公的文書処理こそが地方自治体や中央省庁の基幹業務」という答えでした。
「地方自治体でも中央省庁でもこの原則は変わりません。公的文書処理を支えるシステムをいかに早く安く作れるか。これは自治体にとっても極めて重要な課題になるはずです」

地方自治体や中央省庁の基幹業務は公的文書処理
その現状を徹底的に分析
この課題を解決するために当社が提案しているのが、SOAとWeb2.0をベースにした文書処理・管理環境「DOLCE（ドルチェ）」です。DOLCEとは「Document Oriented business process on Loosely Coupled Environment using service oriented web2.0 architecture」の略でとなっています。
「地方自治体や中央省庁の文書処理システムを棚卸しすると、実に興味深いことがわかります」と長島哲也は述べます。多くの場合、利用者管理や認証、承認といった基本的な“共通処理”と、それぞれの文書を処理する個別処理の2層構造になっていますが、個別処理の中には共通化可能な部分がかなり残っているのです。
「それぞれの文書処理には、状態管理、共通文書操作、個別処理が含まれていますが、状態管理と共通文書操作の機能は共通化できるにもかかわらず、重複した状態で実装されているのです」（下図）。

文書管理共通化のイメージ図(クリックすると拡大します）

この重複した部分を共通化することで、文書処理システムの開発コストは大幅に削減できます。それはなぜでしょうか。状態管理と共通文書操作は、データベース・マネージメントシステムを用いた“ステートフル”なシステムとする必要があるため、開発に高いスキルが要求され、開発コストも高額になる傾向にあります。これに対して個別処理部分のほとんどは、帳票画面開発によって占められているので、それほど高いスキルは要求されません。状態管理と共通文書操作を共通部分として切り離すことができれば、高いスキルを持つエンジニアを多数揃える必要がなくなり、その結果としてコストも削減できることになるのです。

「DOLCE」ではこのコンセプトを実現するために、文書処理環境を大きく3つのレイヤーに分けています（下図）。

文書処理環境レイヤーのイメージ図(クリックすると拡大します）

まず状態管理を司る部分は、SOAのテクノロジーを活用して共通化します。具体的には、各文書の状態遷移を管理する「BPEL（Business Process Execution Language）」と、現在の文書の状態がどのユーザーの処理を必要としているのかを管理する「HT（Human Task）」、さらにこれらの機能を他のレイヤーから利用するための「共通プロセス操作（API）」から構成しています。
文書処理を司る部分は「共通書類操作」と呼ばれるWebアプリケーションで実現します。具体的な機能としては、書類検索や書類検証、書類保存が含まれます。BPELエンジンが文書の“状態”を管理する一方で、共通書類操作では“文書そのもの”を管理しています。
また、個別処理レイヤーとのやり取りは、HTTPベースのプロトコルで行います（Web2.0標準のRESTとして実装）。そして個別処理はWebブラウザとJavaScriptを用いたAjaxで実現します。W3C帳票定義規格XForms準拠の「IBM Workplace Forms Designer」ツールを使えば、「所得税の確定申告書」のように多数のフィールドで構成される画面でも、タグの定義を含め5～10時間程度で作成できます。「DOLCEなら月額100万円のSEでも、1日1枚の帳票開発が可能」と長島は説明します。仮にテストなども考慮し2人日/1帳票の開発ワークロードがかかるとして、100枚の帳票開発の場合でも、1000万円ですむ計算になります。
「従来の開発方法では1画面50万～100万円程度かかると言われていますので、100枚の帳票開発では5000万円～1億円のコストが必要となります。この差を単純には比較できませんが、理論上帳票開発コストを1/5程度まで圧縮できることになります」
なお「DOLCE」のデモ・システムは、東京・丸ビルのイノベーションラボと、東京・渋谷のSWCOCに常設される予定になっています。またリモートからでもアクセスできるため、必要であればお客様の会議室などでデモを行うことも可能です。

「DOLCE」についてのお問い合わせはこちらまでお願いします。

※　このページは日経BP社から許諾を得て転載しています。