上記リンクをクリックすると、ページ内の該当箇所に移動します。
2010年7月6日に開催された「IBM Software Impact 2010」（主催：日本アイ・ビー・エム株式会社）にて、京都大学情報環境部 情報企画課課長 上條春穀様から「京都大学の電子事務局構想における電子申請構築事例」についてご講演いただきました。ここに講演の概要をご紹介します。
電子事務局構想
電子申請システム構築の背景と目的
電子申請システム構築にあたっての考慮点
申請処理を電子化する際に特に考慮した点は以下の5点になります。
第1は、「職員だけで新しい申請様式の準備ができる」こと。申請様式の追加作業をその都度ベンダーに依頼すると費用が高くなり、電子化する意味が半減してしまいます。
第2は、「申請処理がツールによる制約を受けない」こと。ITベンダーは自社製品を「使いやすい」と主張しますが、一般的にワークフロー・ツールの操作は職員には難しいことが多くあります。
第3は、「申請と決裁の違いを認識するツールである」こと。申請処理が制度に従って粛々と実施されるのに対し、決裁処理は処理の都度、担当者が決定される複雑な経路をとります。ところが、ワークフロー・ツールの開発者は往々にしてこの申請と決裁の違いを認識しておらず、電子申請に必要以上の機能を搭載しがちで、運用上の大きな混乱要因となってしまいます。
第4は、「電子決裁システムとのシームレスな連携ができる」こと。例えば、申請された書類の承認処理には、複数の担当者の決裁が必要となります。こうした連携を実現するためには、任意の処理と電子申請をシームレスに連結することが不可欠です。
第5は、「TCOの削減ができる」こと。具体的には、簡単なシステム変更を職員だけで実施できるようにすることです。書類を作成するための電子フォームと経路を制御するためのフロー・システム、および電子フォームのデータ項目を保存するデータベースが渾然一体として実装されているツールの場合、一見簡単に見える変更でもシステム全体に影響が及び、結局ベンダーに依頼せざるを得なくなります。簡単な機能改修などには電子事務局推進室職員が対応し、TCOが削減できることは重要なことです。また、ライセンス費用が、職員数の増減や新しい申請追加に影響されないことも、重要なポイントです。
電子申請のツールとしてDOLCEの採用
こうした中で、2007年12月にIBMから「書類を中心とした業務の特性にあったIT基盤アーキテクチャー：DOLCE（ドルチェ）」の紹介があり、2008年11月に試行を開始しました。DOLCEを採用した理由は以下のとおりです。
まず、DOLCEは上記5つの考慮点によく合致していた点。次に、DOLCEでは、書類は書類（XML）、経路は処理待ち箱（WS-BPEL）というように「素直なイメージ」で実装されており、理解しやすかった点。さらに、DOLCEは、XMLやWS-BPEL等の要素技術が業界標準に準拠したオープンな技術で構成されていたので、ベンダー・ロックインの危険性が少ないと判断しました。デモを見て、職員によるエンドユーザー・コンピューティング（EUC）の実現ができそうだと感じたことはDOLCE採用にあたって重要な点でした。また、大学の教職員は多様なブラウザーを使用しているので、DOLCEがInternet Explorer, Fire Fox, Safari等の大学の職員が使用している複数ブラウザーに対応できている点も高く評価できました。
電子申請で実現できたこと、できなかったこと
2009年5月にDOLCEを利用したNotes®/Domino®ユーザー申請の本格的運用を開始しました。また、2010年2月からは上記ユーザー申請に項目を追加して、ICカード発行申請についても運用を開始しています。これらの経験から、DOLCEによって、外部発注せずに職員により新しい電子申請サービスを開始できることと、職員による運用・管理の実施ができることが確認できました。
しかし、その一方で、電子申請フォームの修正・追加と経路定義は当初想定していた部局事務担当者が行うのではなく、電子事務局推進室職員が行わざるを得ない状況にあります。これはライセンス的な課題と個人のスキルに依存するという課題によるためであり、とりわけ経路定義については、当初の想定よりかなり難しく部局事務担当者には事実上、実施不可能な作業であることが判明しました。
将来展望
DOLCEとは？
書類を中心とした業務の特性に合った
ITアーキテクチャー
（クリックで拡大します）
DOLCEとは、「Document Oriented business process on Loosely Coupled Environment using service oriented web2.0 architecture」の略で、書類を中心とした業務の特性に合ったアーキテクチャーです。
書類を中心に処理が進む申請業務などにおいては、書式が異なることからそれぞれが個別の処理のように見えますが、書式の観点ではなく、書類の処理手順の観点から分析してみると、申請者が「申請する」、申請された書類を「受け付ける」、それを自・他部門で「審査する」、審査結果に基づいて「承認をもらう」、その後申請に基づく処理を「実行する」という処理パターンはほぼ同一であることがわかりました。これらを状態管理（申請、受付などの状態）の観点で共通化することによって、従来個別に開発していた書式の異なる業務システムを、オープンなミドルウェアで構築された「共通のシステム基盤」で処理できるように構築し、改修コストを劇的に低減させるアーキテクチャーがDOLCEです。
