JP2015167005A - 書類、バリデーションチェック及び開発ドキュメント作成用コンパイラ及びそれを用いた稟議システム - Google Patents

Abstract

【課題】 システム更改に対し、柔軟な稟議システムを提供することを目的とする。【解決手段】 組織の階層構造を記述した組織情報を記憶する手段と、書類の項目に入力することが出来る値を定義した型を記憶する手段と、書類の項目と型との対応関係を定義した様式を記憶する手段とを備え、前記型と様式に基づいて、チェックプログラムおよび補完プログラムを生成する手段と、前記型と様式に基づいて、利用者に前記チェックプログラムおよび補完プログラムを含む入力画面を提供する手段を備える。前記入力画面に入力された情報から様式に従った稟議書類を生成し、稟議書類を記憶する手段を備える。前記型の定義は、正規表現か入力することが出来る値を列挙することで行う。複数の値のタプルを列挙することで、複数の項目の組み合わせで判断するチェックプログラムや補完プログラムの生成を可能とする。【選択図】図１０

Description

この発明は稟議システムに関わる。

近年、社内や組織でやり取りされる書類の電子化が進んでおり、書類の承認・決裁についても電子で行う事が少なくない。

書類を電子化し電子的に承認・決裁するにあたり、書類がどのような様式に従うべきか、書類の様式毎にどのような経路で承認・決裁を行うべきかを事前に定めておく事が必要となる。

また、作成された書類は、必要なユーザには参照を許すと同時に、情報漏えいや不正アクセスを防ぐため公開範囲を適切に制限することが必要である。

従来の技術では、書類の様式を定義するために、書類の電子化のためのミドルウェアを導入し、システムの管理者等がミドルウェアに付属するグラフィカルな専用デザインツールによってデータベースの定義及び入力画面のデザインを行っていた。

一方、承認・決裁の経路を定義するためには、ＢＰＥＬなどのビジネスプロセス記述言語により、グラフィカルに経路を記述していく方法がとられていた。この経路の記述は、システムの管理者が書類の様式毎に記述するか、一般利用者が書類を作成する際に選択するといった方法を採ることが一般的であった。

また、作成した書類に対してアクセス制御をおこなうためには、ＡＣＬ（アクセス制御リスト）やファイルのケイパビリティ等を設定することで、ディレクトリ単位やファイル単位に、個々に設定する方法を採ることが一般的であった。

特開２００４−２４６５１６号公報 特開２００７−０７２６９２号公報

上記したように、書類の様式の定義は、グラフィカルな専用ツールを利用して個別に作成して実現することが従来行われていた。

グラフィカルな専用ツールを利用する従来の方法は、試行しながら小量の様式を作成する場合には、利用者のスキルレベルが低くても使いやすいなどのメリットがある。しかしながら、大量の様式を定義しなければならない場合や、大量の様式に対して修正が発生した場合は、既存の様式を再利用しながら修正することが困難であり、該当する全ての様式を利用者が個別に修正しなければならないなど、利用者に困難かつ多大な作業を強いるものであった。

また、会社独自の番号体系のチェック処理を画面に埋め込む必要がある場合は、従来の専用ツールでは想定されていないため、このような画面は作成不可能であるか可能な場合でも定義が難しいことが課題であった。このため、利用者が実用的に使用するためのカスタマイズと称される大規模な改修を行い多大なコストを払って運用することが通例行われてきた。このような改造を行った場合、番号体系やチェックの仕様に変更が発生した場合に、カスタマイズ部分においてこのような変更を考慮していない場合には、十分な対応が行えないか、若しくはさらに多大なコストと時間を費やして対応することなるため、結果的に運用コストが一層増大するか、場合によっては番号体系やチェックの仕様の変更を阻害する要因ともなってきた。

次に、承認経路をＢＰＥＬ等の言語を使って記述して行く方法では、飛び決や、代行決裁などの例外的な経路も含め取り得る経路を様式ごとに全て記述しておかなければ動作させることができず、したがって、あらかじめ例外的な経路を全て記述するための膨大な作業を強いられるため、システム構築のコストが高くなる。そして、組織構造や構成員に変更が発生した場合には、定義された承認経路の見直しを様式毎に行う必要がある。さらに、組織構造の一部を改変する場合でも、例外的な経路を記述する必要があるため、承認経路全体に亘って見直しが発生するうえ、改変後の確認作業も、承認経路全体に渡って行う必要があるため、確認作業が膨大となることが課題であった。

なお、ここでいう、飛び決とは、予め定められた承認者が不在などの理由で承認できない場合、その上位の承認者が承認を行うことを指す。また、代行承認とは、承認者が不在などの理由で承認できない場合、同一組織内のユーザが代わりに承認を行うことを指す。

次に、書類のアクセス制御を、ＡＣＬやケイパビリティを用いて設定する方法では、きめ細かいアクセス制御を行える反面、個々の書類やユーザに対してきめ細かく設定を行う必要があるため、適切に設定するためには多大な労力を必要とする。その結果として必要な制限が行われないか、逆に厳しく制限をしすぎて、情報の共有を阻害してしまうという課題があった。また、組織の構造や構成員に変更が生じた場合、ファイルのアクセス制御やケイパビリティの設定についても設定変更を必要とするが、これらの変更についても多大な労力を必要とするため、組織の変更に柔軟に対応できず、セキュリティのための役割を果たさなくなることが課題であった。

このことは、承認経路の課題と合わせて、組織自体の改変を阻害する要因ともなってきた。

特に、システムが大規模になった場合、小さな仕様変更であってもそれによって影響を受ける範囲が大きく、システム改修のコストが指数関数的に増大する事が課題であった。

本発明は、このような書類の様式、承認経路の作成と変更、及び、アクセス制御の設定と変更の作業を少なくにすることで、システムの開発、及び、修正を容易にする事を目的とする。

上記課題を解決するために、本発明では、様式の定義をするための専用言語を用意する。専用言語は、様式を定義するために必要最低限なことだけを記述すればよく、記述量を少なくすることが出来る。また、実際の様式の構成に近い形式で記述することが出来るような文法に設計することで、実際の様式から直感的に記述することが出来る。そのため、汎用的な言語に比べて習得が容易で、様式の記述も容易に行うことができる。専用言語を用いた方法は、グラフィカルな専用ツールを用いて様式を記述する方法に比べ、過去に作成したものを参考に一部分だけ修正して大量の様式を作成したり、作成した大量の様式に対して、同様な修正を一度に反映したりといったことが効率的に行える。さらに、この専用言語は利用者自身が定義を記述するために直接利用するだけでなく、中間言語としても利用できる。例えば、グラフィカルな専用ツールを製造する際にこの専用言語を中間言語として用いることで開発コストを低く抑えることができる。スキルレベルが低いユーザが作成する場合や、少量を試行しながら作成する場合はグラフィカルな専用ツールを用い、大量の様式を定義する場合や保守を行う場合には、専用言語を用いることで、双方のメリットを享受することができる。

一般的に書類のテンプレートを定義する際には、書類が含む項目とその項目に入力することができる値の制限を型として定義することが多い。本発明にいても様式は、文書を構成する項目と型との対応関係の記述を含む文書構造の定義と、型の定義とを含み、さらに、承認経路の定義と、権限の定義とを含むものとする（承認経路の定義、権限の定義については後述する。）。ここでいう型とは、その項目に入力することができる値の集合に名前を付けたものと言うことができる。例えば、その項目に整数のみ入力できるであれば項目の型は整数型となり、テキストのみ入力できるのであれば項目の型はテキスト型などとなる。テキスト型や整数型のような、集合の要素数が文字の組み合わせにより膨大となってしまう場合は、その項目に入力することができる値の集合を正規表現で記述することができる。値の集合の要素数が少なければ、正規表現を用いて記述してもよいし、すべての要素を列挙することも可能である。このように、型の定義は、正規表現で記述するか、すべての要素を列挙する方法で定義できる。様式に基づいて書類を作成する際に、入力した項目に誤りがないかエラーチェックを行う場合については、項目のエラーチェックとは、入力された値とこれらの集合値とを突き合わせて、入力した値が集合に含まれるか否かを確認するものであるといえる。このような考えに基づけば、入力した値と集合値とを比較するプログラムを作成すれば、集合値である型の定義に基づいてバリデーションを行うエラーチェックプログラムを自動生成することが可能となる。

さらに、項目に入力しうるすべての値を列挙することによって型を定義した場合は、列挙した値は入力値の候補であるといえるので、入力値によって絞り込まれた列挙値を返却するプログラムを作成知れば、入力値の補完プログラムも自動生成することが可能である。

このように、本発明では型を正規表現、列挙、及び、それらの組み合わせで定義することで、エラーチェックプログラムを自動生成し、型を列挙にて定義した場合は、入力値の補完プログラムを自動生成し、エラーチェックと入力値の補完を含む入力画面を提供することが可能である。

入力項目のチェック内容として多くあるのは、入力が必須であるか否かのチェックである。このような場合に対応するために、本発明では型を列挙にて定義する場合に、空集合を意味する記号（例えば「ＮＵＬＬ」のような記号。）を列挙値として利用する方法を提供する。

入力値のチェックは正規表現に従って行いつつ、入力の補完値だけを列挙したい場合がある。このような場合に対応するために、本発明では型を列挙にて定義する場合に、列挙値の一つとして正規表現で定義した型を利用する方法を提供する。別の方法として、本発明では型を列挙にて定義する場合に、「任意」を意味する記号を列挙値として利用する方法を提供する。

入力項目のエラーチェックや入力値の補完は単項目ではなく複数項目の組み合わせで判断する場合も多い。例えば、車種を選択する入力フォームにおいて、メーカーと車種の入力ボックスがある場合などである。このような場合に対応するために、本発明では型を列挙して定義する場合に、複数項目の値からなるタプルを列挙する方法を提供する。

型として列挙値を使用する際には、都道府県のリストや、製品番号など、件数が多く様式にすべて記述することで様式が肥大化するのを避けたい場合や、社内のデータベースに保持する値を直接利用したいといった場合がありうる。このような場合に対応するために、列挙値として外部データベースへの参照を記述する方法や、システム内のデータベースにＣＳＶ等でいったん取り込み、システム内のデータベースへの参照を記述する方法を用いて間接的に入力しうる値を指定する方法を提供する。

以上の方法で型を定義することにより、必須チェックや複数項目の組み合わせで判断するチェックを含むエラーチェック、複数項目の組み合わせで判断する入力値の補完、外部データベースを使ったエラーチェック、及び、外部データベースを使った入力値の補完を行うことが可能となる。

型は入力できる値の集合といえるので、ある定義済みの型の部分集合を定義することで、当該型に基づいてさらに別の型を定義することや、型と型を組み合わせた別の型を定義することも可能である。

型は様式ごとに定義するだけでなく、様式にまたがって共通して利用できるように事前に定義することもできる。例えば、数値やテキストのような基本的な型の他に、一般的な入力フォームで用いられる電話番号や住所といった型を定義しておくことができる。このような型にさらに制限を加えたり組み合わせたりすることで、利用者独自の型も定義可能である。

一般的に、組織において書類を作成する場合、上司からの命令によって書類を作成することがほとんどである。本発明では、様式を元に書類を作ることから、様式が存在することを命令が常時発せられている状態ととらえ、その応答として書類の作成やその途中経過の承認があると考える。つまり、様式を定義するデータを業務上の命令として取扱い、このデータをシステムに格納することが、命令が発せられた状態と考える。その様式に基づいて書類を作成することや、承認プロセスを経ることが、命令の遂行に当たり、命令に対する応答である。この時、命令を発したユーザが最終決裁者となり、応答として返ってきた書類の所有者は、命令を発したユーザとなる。図１は、実際の組織階層の例に当てはめた、命令と応答の説明である。図中の部長００１が命令の発令者であるとする。部長００１は、Ｂ部、及び、Ｂ部の下位部門である、Ｃ課、Ｄ課のメンバー００２に作成させたい書類がある場合、命令の内容に即した様式を定義するデータをシステムに格納する。メンバー００２は、様式に従い書類を作成し、命令に対する応答として、書類を命令の発令者である部長００１へ提出する。部長００１は、書類の内容を確認し、命令に沿った内容であれば、決裁を行う。このとき、決裁された書類の所有者は、書類を作成したメンバー００２ではなく、命令を発した部長００１となる。

承認経路の記述は、発明が解決しようとする課題の節で述べたように、ＢＰＥＬ等の言語を用いた方法では記述のコストが高いという問題があった。これに対して、本発明では、承認経路を直接記述するのではなく、組織の構造に対応した木構造のデータ構造によって表現した組織情報と、様式に記述された承認経路の定義を元に、承認経路を生成する。

前述したように、書類は、命令の発令者である様式の作成者への応答となるが、一般的な階層構造を持つ組織において、書類の作成者から、様式の作成者までの間に、中間管理者が存在すれば、直接応答を返すのではなく、中間管理者による確認を経てから、返されるべきである。すなわち、基本となる承認経路は、書類を作成したユーザから命令者である様式の作成者まで組織階層を上位に辿る経路とする。図２は、実際の組織階層の例に当てはめた、承認経路の説明である。図中の部長００１が命令の発令者で、メンバー００２が応答者である場合、書類の作成から最終決済までの経路は、中間管理者の課長００３を含め、メンバー００２、課長００３、部長００１の順となる。

差戻しや飛び決のような経路については、個々に記述するのではなく、組織全体や様式毎の経路の有無を組織情報か様式にフラグとして記述し、そのフラグに従い、承認経路を生成する（図３）。

承認経路には単純に組織階層を上向きに辿るもののほか、例えば経理部門の確認を必要とするものなど、組織階層を横断するものも多くある。本発明では、このような承認経路を効率的に取り扱うために、組織階層を構成する部門をライン部門とスタッフ部門の２種類に分けて取り扱う（図４）。

ここで、ライン部門とは、例えば、社長→部長→課長→課員のように直線的な命令系統や直系組織のことで、会社の主要な仕事を直接的に担当する部門のことを指す。スタッフ部門とは、社内の共通的な仕事を、間接的に行う部門のことを指す。

本発明では、スタッフ部門とした部門は、組織階層内の異なるライン部門から共通的な仕事を依頼される部門であり、すべてのライン部門配下に仮想的に位置する部門と解釈する（図５）。この解釈に基づいて、スタッフ部門を経由する形で組織階層を横断して行われる承認経路については、スタッフ部門による確認の有無を様式の承認経路の定義にフラグとして記述することで、簡便に定義することができる。

いずれのフラグも、様式の承認経路の定義に記述がなければ組織情報の値に従い、記述があれば様式の承認経路の定義を優先する。

書類のアクセス制御についても、承認経路の定義と同様に、組織情報と権限の定義を元に制御する。

まず、ユーザが新規に書類の作成を開始すると、書類は作成中となる。作成中とはユーザが書類の作成を開始したが、すべての入力が終わっておらず、誰にも提出していない状態である。作成中の状態では、当該書類は書類の作成者しか参照することができない（図６）。書類の作成者が書類を完成したと判断した時点で、提出等のアクションを行うと、前述の方法によって生成された承認経路に従い、上位の承認者へ書類が提出される。

次に、書類を提出された承認者は、当然ながらその書類を参照可能である必要がある。本発明では、承認を行うユーザが、書類の参照権限を変更する権限も保持すると考える。従来、多くのファイルシステムでは、書類の作成者が書類に対する各種権限を変更する権限を持つことがほとんどであったが、本発明においては、書類の参照権限を変更する権限を、それぞれの段階の承認者に移していく（図７）。書類の作成や承認が終わり、承認経路上の次のユーザが承認を行うユーザになった際、元の作成者や承認者は書類の参照権限を変更する権限を持たず、次のユーザが書類の参照権限を変更する権限を持つことになる。最終的に書類の参照権限を変更する権限を持つユーザは命令者である最終決裁者となる（図８）。本発明では、この書類に対する参照権限などの各種権限を変更する権限を持つユーザを書類の所有者と呼び、書類の所有者を作成者とは別に扱った点が特徴である。

さらに、書類の権限の付与対象は、所有者を基準にして組織階層上で相対的に設定することができる。例えば、所有者の上位組織と所有者の下位の組織に対して参照権限を付与するといった具合である（図９）。

書類を削除する権限についても、書類の所有者が持つこととする。

また、これらの書類は、自身に参照権限があれば、作成中の書類であろうと、共有された書類であろうと共通のアクセス方法で検索できるものとする。

このような考えに基づき、本発明は次のような手段をとる。

様式を記憶する手段と、前記様式に基づいてチェックプログラムおよび補完プログラムを生成する手段と、前記様式に基づいて利用者に入力画面を提供する手段とを備える。

前記様式は、文書を構成する項目と型との対応関係の記述を含む文書構造の定義と、項目に入力可能な値の範囲を定義した型の定義とを含む情報であり、前記補完プログラムは、前記様式に含まれる前記型の定義と前記入力画面へ入力された入力値に基づいて入力候補を返却し、前記チェックプログラムは、前記様式に基づいて、入力画面に入力された入力値のチェックを行って、チェック結果を返却し、前記入力画面は、前記補完プログラムを呼び出して、返却された前記入力候補を表示することで入力補助を行うとともに、前記入力画面を呼び出して、入力画面に入力された入力値のチェックを行う。

前記様式に含まれた型の定義は、型名に対して、項目に入力可能な値を１つ以上列挙したもの、型名に対して、項目に入力可能な文字列を正規表現を用いて定義したもの、型名に対して、項目に入力可能な値の範囲を数式を用いて定義したもの、型名に対して、他の型名を対応付けて定義したもののいずれかを含む。

前記稟議システムは、項目に入力可能な値を保存した外部データベースをさらに備え、前記様式に含まれた型の定義は、前記外部データベースへのアクセス方法の定義を含む。

前記様式に含まれた型の定義は、項目間の値の関係の定義を含み、前記チェックプログラムは、前記入力画面に入力された入力値が前記項目間の値の関係を満たすかどうかをチェックするとともに、前記補完プログラムは、前記項目間の値の関係を満たす入力候補を返却する。

前記項目間の値の関係の定義は、項目に入力可能な値の組を列挙したものを含む。

前記文書管理システムは、項目に入力可能な値の組を保存した外部データベースをさらに備え、前記項目間の値の関係の定義は、前記外部データベースへのアクセス方法の定義を含む。

前記チェックプログラムから返却された前記入力候補は複数の入力候補を含み、
前記入力画面は、前記複数の入力候補を一覧表示することで入力補助を行う。

本願発明では、文書構造の定義、型の定義、承認経路の定義、及び、権限の定義を含む様式を、専用言語を用いて記述する事によって、グラフィカルな専用ツールを用いて実現されたものと比較し、多数の様式に関する変更を一度に行うことが容易であり、変更にかかるメンテナンスの時間と経費を節減する効果を有する。

グラフィカルな専用ツールを製造する場合においても、専用言語を開発のための中間言語として製造することで、ツールの開発コストを低く抑えることができる効果を有する。

様式の定義に用いる型を値の集合として定義することで、入力された値と定義された集合と突き合わせる処理を行うエラーチェックプログラムの自動生成が可能となる。型が有限集合の場合に、取りうる値を列挙することによって型を定義できるようにすることで、エラーチェックプログラムに併せて、入力値の補完プログラムも自動生成することが可能である。列挙にて型を定義する際に、空集合を意味する記号を列挙値として利用できるようにすることで、入力項目の必須チェックを行うエラーチェックプログラムを自動生成することが可能である。列挙にて型を定義する方法において、列挙値として定義済みの別の型を利用できるようにするか、「任意」を意味する記号を列挙値として利用できるようにするとともに、型に制限を加えて別の型を定義することによって、正規表現で定義した型に従った入力値の補完を行うプログラムを自動生成することが可能である。このように型の定義を行い、型を使って様式の項目を定義するだけで、チェックプログラムと入力値の補完プログラムを含む入力画面を提供することができ、チェックプログラムと入力値の補完プログラムを含む入力画面の製造コストを大幅に低減する効果を有する。

また、列挙にて型を定義する際に、タプルを使った定義を可能とすることで、通常であれば、複雑なプログラムが必要な複数項目にまたがるエラーチェックや入力値の補助プログラムを生成することができ、様式の記述コスト及び難易度を大幅に低減する効果を有する。

列挙値としてデータベースへの参照を記述できるようにすることで、社内で保持するデータベースの値を用いることができるようになり、件数の多い列挙値の記述コストを低減したり、動的に変更される値を型として利用できたり、社内のデータと連携した入力画面の製造を行うことができるといった効果を有する。

事前に必要な型を定義しておくことで、新たな型の定義なしに様式を記述することができる。型に制限を加えて別の型を定義できるようにすることで、必要に応じて事前に定義した型に制限を加えて新たな型を定義し、様式の記述を行うことができる。これにより、型の記述を最低限にすることができ、様式の記述コストを低減する効果を有する。

承認経路の定義においては組織情報を元に、差戻しや飛び決のような経路の有無をフラグとして記述し、承認経路を自動生成することで、ＢＰＥＬエンジンなどの従来のワークフローエンジンと比較すると、プログラムの記述量が大幅に少なくなり、システムの構築コスト削減、構築速度の向上という効果を有する。

ライン部門とスタッフ部門を定義することで、組織を横断する承認経路についても、容易に定義可能になる効果を有する。

書類のアクセス制御を組織情報に基づいて行い、書類の作成者と、書類の参照権限や削除権限などの各種権限をもつ所有者とで分け、さらに、承認を行うたびに所有者が移り変わるようにすることで、書類に対する権限を持つユーザが適切なユーザとなり、権限を付け替える手間を無しに、セキュリティを高めることができるという効果を持つ。

書類のアクセス制御を組織情報に基づいて行い、書類の作成者と、書類の参照権限を変更する権限をもつ所有者とで権限を分け、さらに、承認を行うたびに所有者が移り変わるようにすることで、書類の参照権限を変更することができるユーザが適切なユーザとなり、書類の共有を行う自由を残しつつ、セキュリティを高めることができるという効果を持つ。

書類のアクセス制御を組織情報の階層情報に従い、書類の所有者から相対的に設定できるようにすることで、組織変更があった場合においても、権限を付け替える手間を無しに、適切なセキュリティを保つことができるという効果を持つ。

自分自身が作成中の書類で提出前のものについては、作成者自身しか参照できないことを保証することで、作成者にとってはローカルファイルと同様な感覚で書類を扱えるようになり、同時に共有された書類と、作成中の書類をシームレスに検索できるようにすることで、書類が物理的にどこにあるかにかかわらず、容易に見つけることができるようになるという効果を持つ。

１． システム構成
本発明を実現するために必要な構成要素のブロック図を図１０に示す。本発明の稟議システムは、組織情報・様式・既存の型を保存するサーバ０１００１と、組織情報、様式、及び、既存の型を解釈し、チェックプログラム、補完プログラム、及び、様式中間情報を生成する様式コンパイラ０１００２を実行する様式コンパイルサーバ０１００３と、組織情報参照部０１００４と様式検索部０１００５からなるアプリケーションサーバ０１００６と、生成されたチェックプログラム０１００７、及び、補完プログラム０１００８を実行するアプリケーションサーバ０１００９と、書類起案部０１０１０、書類提出部０１０１１、書類承認部０１０１２、書類検索部０１０１３、書類参照部０１０１４、及び、書類削除部０１０１５からなるアプリケーションサーバ０１０１６と、書類を保存するサーバ０１０１７と、様式選択画面０１０１８、書類検索画面０１０１９、書類入力画面０１０２０、書類承認画面０１０２１、及び、書類参照画面０１０２２を保存し配信するＷｅｂサーバ０１０２３と、認証サーバ０１０２４と、画面を表示するＷＥＢブラウザ０１０２５を持つ複数の利用者端末０１０２６から構成される。

組織情報とは、組織の階層構造、ユーザの役職や氏名、及び、承認経路を生成するためのルールや書類に対する操作の可否を定義した権限の定義を記述するものである。

組織情報を記述する言語はどのようなものでも構わないが、本実施例ではこれらの情報を、専用の言語（以下、「組織情報記述言語」と呼ぶ。）を設計し記述する。

組織情報記述言語は、ユーザ情報０１０２７と組織階層情報０１０２８で構成される。

ユーザ情報０１０２７は、ユーザの識別子０１０２９、氏名０１０３０、役職０１０３１、及び、パスワード０１０３２を１レコードとするリストである。組織階層情報０１０２８は組織を構成する部門０１０３３の階層構造で構成される。部門０１０３３が持つ情報は、部門名０１０３４、部門の長０１０３５、部門のメンバー０１０３６、権限の定義０１０３７、下位の部門０１０３３、及び、下位のスタッフ部門０１０３８である。

組織情報をユーザの階層構造とせず、部門の階層構造とし、部門にユーザを所属させる構造としたことが特徴である。（図１１）

様式とは、利用者が最終成果物である書類を作成するための枠組みを定義する情報であり、一般的にテンプレートと呼ばれるものである。様式を記述する言語はどのようなものでも構わないが、本実施例では専用の言語（以下、「様式記述言語」と呼ぶ。）とする。

様式記述言語は、型の定義０１０３９、文書構造の定義０１０４０、承認経路の定義０１０４１、権限の定義０１０４２から成る。

型の定義０１０３９とは、書類を構成する項目に入力可能な値の範囲を定義したものである。様式中に定義される型を、ユーザ定義型０１０４３と呼ぶこととする。型の定義０１０３９には、型名０１０４４と型の定義内容０１０４５の組を複数記述できる。型の定義内容０１０４５は、正規表現、列挙値、又は定義済みの別の型名によって型を定義する。列挙値には、テキスト値の他、空集合を意味する特殊記号“ＮＵＬＬ”と定義済みの別の型名が列挙できる。

文書構造の定義０１０４０とは、書類の項目名０１０４６と、項目名に対応する型名０１０４７を記述し、その定義を実際の書類の構造に合わせて配置して、書類の構造を定義するものである。書類の項目名に対応づける型名は前述のユーザ定義型０１０４３の他に、既存の型も利用できる。既存の型とは、複数の様式から共通的によく使う型を、事前に定義しておくものである。

承認経路の定義０１０４１は、作成された書類の承認経路を定義するものである。承認経路すべてを記述するのではなく、組織情報に示される組織の階層構造に沿わない部分のみを記述する。

承認経路の定義０１０４１は、起案可能部門０１０４８、スタッフによる承認の有無０１０４９、承認不要部門０１０５０を記述する。

組織情報に記述される権限の定義０１０３７、及び、様式に記述される権限の定義０１０４２は、作成された書類の参照や変更の権限の定義を記述するものである。権限の定義０１０４２は、所有時の権限０１０５１、承認権限０１０５２、決裁後の権限０１０５３を記述する。

書類は、様式に定義された項目と、ユーザからの入力値、承認経路の設定から構成されるひとまとまりの情報である。本実施例ではＸＭＬを用いて記述するが、ＪＳＯＮ、ＹＡＭＬなどの他の周知の方法を用いても本発明を実現しうる。

２． 処理の流れ
２−１． 認証
利用者が利用者端末を用いて本システムにアクセスすると認証が行われる。本発明では、認証を行う方法としてログインダイアログが表示される方式を例示するが、ＩＣカードを用いる方法、利用者の指紋を読み取らせる方法、静脈認証、網膜認証など他の周知の方法を用いてもよい。

利用者が、組織情報・様式・既存の型を保存するサーバ０１００１、又は、ＷＥＢサーバ０１０２３へアクセスすると、認証サーバ０１０２４がログインダイアログをＷＥＢブラウザ０１０２５に表示させる。利用者が、ユーザＩＤとパスワードの組を入力すると、認証サーバ０１０２４は、組織情報・様式・既存の型を保存するサーバ０１００１からユーザ一覧を取得し、ユーザＩＤとパスワードの組が正しいか確認する。ユーザＩＤとパスワードの組が正しければ利用者は各サーバにアクセスできる。認証サーバ０１０２４を通したアクセスにおいては、通信の度に各サーバに保証されたユーザＩＤが渡さているものとする。認証は、必ず行われているものとし、以後の処理手順の説明からは省略する。

２−２． 組織情報と様式の作成
最初に、組織情報及び様式の作成からプログラムの生成までを説明する。

２−２−１．組織情報の作成
利用者は組織の構造や、ユーザの所属に関する情報として、実際の組織の階層情報に対応した組織情報を作成し、組織情報・様式・既存の型を保存するサーバ０１００１に保存する。組織情報の作成は、専用のエディタを開発し、それを用いて記述してもよいし、テキストエディタ等で記述してもよい。ＬＤＡＰ等外部の情報を取り込んで加工する方法も考えられる。

２−２−２．様式の作成
様式の作成は、専用のエディタを開発して記述してもよいし、テキストエディタ等で記述してもよい。本発明において、様式の作成者は様式に従って作成された書類の承認経路の最終決裁者であるとともに、書類の最終的な所有者となる。このため、様式中の様式所有者の領域に様式の作成者のユーザＩＤと作成者が所属する部門ＩＤを記述しておくものとする。

２−２−３．組織情報と様式のコンパイル
様式が、組織情報・様式・既存の型を保存するサーバ０１００１に保存されると、組織情報、様式、既存の型を様式コンパイルサーバ０１００３へ送信し、様式コンパイルサーバ０１００３において様式コンパイラ０１００２が起動されて、以下に説明する手順に基づいてチェックプログラム、および、補完プログラムを生成する。

様式コンパイラ０１００２は、まず、組織情報・様式・既存の型を保存するサーバ０１００１に保存された既存の型、及び、様式に記述されたユーザ定義型を用いて、画面からの入力値を引数にとり、入力値を型の定義と比較し、エラー判定結果を返却するチェックプログラムを定義された全ての型について生成する。チェックプログラムの処理内容は以下のようになる。

（１）入力値を受け取る
（２）入力値が空でない場合
（２．１）型が列挙型の場合
（２．１．１）入力値と同じ値の有無を調べる
（２．１．２）同じ値があった場合：判定結果ＯＫを返却する
（２．１．３）同じ値がなかった場合
（２．１．３．１）列挙値中に型名がないか探す
（２．１．３．２）型名があり型が列挙型の場合：（２．１．１）に戻る
（２．１．３．３）型名があり型が正規表現型の場合：
（２．１．３．３．１）正規表現にマッチするか調べる
（２．１．３．３．２）マッチした場合：判定結果ＯＫを返却する
（２．１．３．３．３）マッチしない場合：判定結果ＮＧを返却する
（２．２）型が正規表現型の場合
（２．２．１）正規表現にマッチするか調べる
（２．２．１．１）マッチした場合：判定結果ＯＫを返却する
（２．２．１．２）マッチしない場合：判定結果ＮＧを返却する
（３）入力値が空の場合
（３．１）型が列挙型の場合
（３．１．１）ｎｕｌｌ記号の有無を調べる
（３．１．２）ｎｕｌｌ記号があった場合：判定結果ＯＫを返却する
（３．１．３）ｎｕｌｌ記号がなかった場合
（３．１．３．１）列挙値中に型名がないか探す
（３．１．３．２）型名があり型が列挙型の場合：（３．１．１）に戻る
（３．１．３．３）型名があり型が正規表現型の場合：
（３．１．３．３．１）正規表現にマッチするか調べる
（３．１．３．３．２）マッチした場合：判定結果ＯＫを返却する
（３．１．３．３．３）マッチしない場合：判定結果ＮＧを返却する
（３．２）型が正規表現型の場合
（３．２．１）正規表現にマッチするか調べる
（３．２．１．１）マッチした場合：判定結果ＯＫを返却する
（３．２．１．２）マッチしない場合：判定結果ＮＧを返却する

上記処理内容のフローチャートを図１２、１３に示す。

様式コンパイラ０１００２は、チェックプログラムを、例えは、Ｊａｖａ、ＪａｖａＳｃｒｉｐｔ、Ｃ言語などのプログラミング言語によって生成したのち、実行可能な形式でアプリケーションサーバ０１００９へ保存する。

様式コンパイラ０１００２は、次に、既存の型、及び、様式に記述されたユーザ定義型を用いて、画面からの入力値を引数にとり、補完値を戻り値とする補完プログラムを定義された全ての型について生成する。補完プログラムの処理内容は以下のようになる。

（１）入力として 入力値を受け取る
（２）入力値が空の場合
（２．１）型が列挙型の場合
（２．１．１）列挙値の数だけ繰り返す
（２．１．１．１）列挙値が値の場合：補完値のリストに値を加える
（２．１．１．２）列挙値が列挙型の場合：（２．１）に戻る
（２．１．１．２）列挙値が正規表現型の場合：何もしない
（２．１．２）補完値のリストを返却し終了する
（２．２）型が正規表現型の場合：何もしない
（２）入力値が空でない場合：何もしないで終了する

様式コンパイラ０１００２は、生成した補完プログラムを、アプリケーションサーバ０１００９へ保存する。

上記処理内容のフローチャートを図１４に示す。

２−３． 書類の作成から提出
次に書類の作成から提出までを説明する。

２−３−１．様式の選択
書類の作成者は、まず、様式選択画面０１０１８にアクセスし、自身が作成できる様式を検索する。検索を実行すると、様式選択画面０１０１８は、様式検索部０１０５４に作成者のユーザＩＤを渡す。様式検索部０１０５４は、様式の承認経路の定義の内容から、当該ユーザＩＤが起案可能な様式の、様式の識別子を含む一覧を返却する。様式選択画面０１０１８は、返却された内容から様式の一覧を表示する。

２−３−２．書類の作成
書類の作成者は、一覧から作成したい様式を選択し、書類の作成を実行する。作成を実行すると、様式選択画面は、書類起案部０１０１０に、ユーザＩＤと様式の識別子を送信する。書類起案部０１０１０は、様式検索部０１０５４に様式の識別子を送信し、当該様式を取得する。

２−３−２−１．書類の作成権限の確認
書類起案部０１０１０は、組織情報参照部０１００４から組織情報を取得し、様式と組織情報を確認から、書類の作成権限の確認を行う。様式の承認経路の定義に、起案可能部門０１０４８の記述がある場合、ユーザＩＤが起案可能部門に含まれていれば書類を作成可能と判断する。様式の承認経路の定義に、起案可能部門０１０４８の記述がない場合、様式の所有者の所属部門を組織情報の組織階層情報から特定し、様式の所有者の所属部門の下位の部門をすべて特定する。ユーザＩＤが、特定した部門に含まれれば、書類を作成可能であると判断する。

２−３−２−２．様式からＸＭＬ形式の書類への変換
作成権限に問題がなければ、書類起案部０１０１０は、次の処理を行い、様式からＸＭＬ形式の書類を作成する。

（１）ルート要素である書類要素０１０５５を作成する。
（２）書類の識別子を発行し、書類要素０１０５５のＩＤ属性０１０５６に記述する。
（３）書類要素０１０５５の下位に様式の識別子を内容とした様式ＩＤ要素０１０５７を作成する。
（４）書類要素０１０５５の下位に様式の所有者の部門ＩＤを内容とした様式所有者要素０１０５８を作成する。
（５）書類要素０１０５５の下位に承認経路要素０１０５９を作成する。
（６）書類要素０１０５５の下位に書面要素０１０６０を作成する。
（７）承認経路要素０１０５９の下位に承認経路の設定を作成する。承認経路の設定については後述する。
（８）様式の項目名と型名の定義の数だけ繰り返す。
（８．１）項目名を要素名とした項目要素０１０６１を作成する。
（８．２）型名を項目要素０１０６１の型属性０１０８９に記述する。

上記処理内容のフローチャートを図１５に示す。

２−３−２−３．承認経路の作成
承認経路の設定は以下の手順で作成する。

まず、組織情報参照部０１００４から取得した組織情報の省略値を補完し、組織階層情報に様式の承認経路の定義、及び、権限の定義を反映した中間情報０１０６２を作成する。

（１）すべての部門を対象に処理を行う。
（１．１）権限の定義が記述されていなければ、上位の部門の権限の定義を、コピーする。
（１）承認経路の定義に記述された定義の数だけ繰り返す。
（１．１）承認経路の定義に承認不要部門０１０５０が記述されていた場合
（１．１．１）組織階層情報の対象部門に承認不要０１０６３を追加する
（１．２）承認経路の定義にスタッフによる承認の有無０１０４９が記述されていた場合
（１．２．１）組織階層情報の対象部門にスタッフ部門承認要０１０６４を追加する
（２）権限の定義に記述された定義の数だけ繰り返す。
（２．１）すべての部門を対象に処理を行う。
（２．１．１）権限の定義に承認権限の定義が記述されていた場合
（２．１．１．１）組織階層情報の承認権限の定義０１０６５を変更する。
（２．１．２）権限の定義に所有時権限の定義が記述されていた場合
（２．１．２．１）組織階層情報の所有時権限の定義０１０６６を変更する。
（２．１．３）権限の定義に決裁後権限の定義が記述されていた場合
（２．１．３．１）組織階層情報の決裁後権限の定義０１０６７を変更する。

上記処理内容のフローチャートを図１６に示す。

また、作成された「組織階層情報に様式の承認経路の定義、及び、権限の定義を反映した中間情報０１０６２」の例を図１７に示す。

次に、組織階層情報に承認経路の定義を反映した中間情報０１０６２から以下の手順で承認経路０１０６８を作成する。

（１）中間情報０１０６２から書類の作成者が所属する部門を特定する。
（２）承認経路０１０６８に作成者だけを残した当該部門を追加する。
（３）承認経路０１０６８にメンバーを削除し長だけにした当該部門を追加する。
（４）上位の部門を特定する。
（４．１）特定した部門が様式の所有者が所属する部門でない場合。
（４．１．１）特定した部門に承認不要０１０６３が追加されていない場合。
（４．１．１．１）承認経路０１０６８に、メンバーを削除し長だけにした当該部門を追加する。
（４．１．２）処理（４）へ戻る。
（４．２）特定した部門が様式の所有者が所属する部門である場合。
（４．２．１）承認経路０１０６８に、メンバーを削除し長だけにした当該部門を追加し、処理を終了する。

上記処理内容のフローチャートを図１８に示す。

最後に、承認経路０１０６８をＸＭＬに変換し、書類の承認経路要素０１０５９の下位に追加する。ＸＭＬへの変換ルールは以下となる。

（１）承認経路０１０６８の部門の数だけ繰り返す。
（１．１）ひとつ目の時
（１．１．１）起案者要素０１０６９を作成する。
（１．１．２）起案者要素０１０６９の下位に予定者要素０１０７０を作成する。
（１．１．３）予定者要素０１０７０の下位に、作成者の部門名を内容に、部門の識別子をＩＤ属性とした、部門要素０１０７１を作成する。
（１．１．４）予定者要素０１０７０の下位に、作成者のユーザ名を内容に、ユーザの識別子をＩＤ属性とした、ユーザ要素０１０７２を作成する。
（１．１．５）起案者要素０１０６９の下位に、実施者要素０１０７３を作成する。実施者要素０１０７３の内容は空とする。
（１．１．６）起案者要素０１０６９の下位に、権限要素０１０７４を作成する。
（１．１．７）対象が作成者になっている承認権限の定義０１０６５から、承認権限要素０１０７５を作成し、権限要素０１０７４の下位に追加する。
（１．１．８）対象が作成者になっている所有時権限の定義０１０６６から、所有時権限要素０１０７６を作成し、権限要素０１０７４の下位に追加する。
（１．１．９）対象が作成者になっている決裁後権限の定義０１０６７から、決裁後権限要素０１０７７を作成し、権限要素０１０７４の下位に追加する。
（１．２）ひとつ目でも最後でもない時
（１．２．１）承認者要素０１０７８を作成する。
（１．２．２）承認者要素０１０７８の下位に予定者要素０１０７０を作成する。
（１．２．３）予定者要素０１０７０の下位に、承認者の部門名を内容に、部門の識別子をＩＤ属性とした、部門要素０１０７１を作成する。
（１．２．４）予定者要素０１０７０の下位に、承認者のユーザ名を内容に、ユーザの識別子をＩＤ属性とした、ユーザ要素０１０７２を作成する。
（１．２．５）承認者要素０１０７８の下位に、実施者要素０１０７３を作成する。実施者要素０１０７３の内容は空とする。
（１．２．６）承認者要素０１０７８の下位に、権限要素０１０７４を作成する。
（１．２．７）対象が承認者になっている承認権限の定義０１０６５から、承認権限要素０１０７５を作成し、権限要素０１０７４の下位に追加する。
（１．２．８）対象が承認者になっている所有時権限の定義０１０６６から、所有時権限要素０１０７６を作成し、権限要素０１０７４の下位に追加する。
（１．２．９）対象が承認者になっている決裁後権限の定義０１０６７から、決裁後権限要素０１０７７を作成し、権限要素０１０７４の下位に追加する。
（１．３）最後の時
（１．２．１）最終決裁者要素０１０７９を作成する。
（１．２．２）最終決裁者要素０１０７９の下位に予定者要素０１０７０を作成する。
（１．２．３）予定者要素０１０７０の下位に、最終決裁者の部門名を内容に、部門の識別子をＩＤ属性とした、部門要素０１０７１を作成する。
（１．２．４）予定者要素０１０７０の下位に、最終決裁者のユーザ名を内容に、ユーザの識別子をＩＤ属性とした、ユーザ要素０１０７２を作成する。
（１．２．５）最終決裁者要素０１０７９の下位に、実施者要素０１０７３を作成する。実施者要素０１０７３の内容は空とする。
（１．２．６）最終決裁者要素０１０７９の下位に、権限要素０１０７４を作成する。
（１．２．７）対象が最終決裁者になっている承認権限の定義０１０６５から、承認権限要素０１０７５を作成し、権限要素０１０７４の下位に追加する。
（１．２．８）対象が最終決裁者になっている所有時権限の定義０１０６６から、所有時権限要素０１０７６を作成し、権限要素０１０７４の下位に追加する。
（１．２．９）対象が最終決裁者になっている決裁後権限の定義０１０６７から、決裁後権限要素０１０７７を作成し、権限要素０１０７４の下位に追加する。

上記処理内容のフローチャートを図１９、２０に示す。

また、承認経路要素を追加したＸＭＬ形式の書類の例を図２１に示す。

２−３−２−４．書類の保存
書類起案部０１０１０は、書類を保存するサーバ０１０１７に、以上の手順によって作成したＸＭＬ形式の書類を送信し、正常に終了した場合は作成した書類の識別子を様式選択画面０１０１８に返す。書類を保存するサーバ０１０１７は、送信されたＸＭＬ形式の書類を保存する。

２−３−３．書類の表示
様式選択画面０１０１８は、リダイレクト等の方法で、書類入力画面０１０２０を呼び出す。この時書類の識別子を渡す。

書類入力画面０１０２０は、先ほど作成した書類を表示するために、書類参照部０１０１４に、ユーザＩＤと書類の識別子を渡す。書類参照部０１０１４は、書類の識別子を使って書類を保存するサーバ０１０１７から書類を取得し、書類の変更権限の確認を行う。書類の変更権限を確認する条件は以下のとおりである。

・承認経路要素に却下要素、又は、削除要素が無く、起案者要素の予定者要素に自身のユーザＩＤが存在し、当該起案者要素の実施者要素が空であり、当該起案者要素の所有時権限要素に値“ｗｒｉｔｅ”がある。

書類の変更権限に問題がなければ、書類参照部０１０１４は、書類入力画面０１０２０に当該書類を返却する。なお、承認経路の状態から判断して、自身が書類の作成や承認を行う順番にある状況を、書類の所有者であると呼ぶ。

書類入力画面０１０２０は、返却された書類をＨＴＭＬ形式に変換し、入力フォームを作成する。ＨＴＭＬへの変換方法は、ＸＭＬスタイルシートを使用する方法、ＪａｖａＳｃｒｉｐｔを使って変換する方法等が考えられる。変換はどのような方法を用いてもいいが、書面要素以下の項目要素を項目名のラベルと、インプットボックスに変換する。書類入力画面０１０２０は、作成した書類を提出するためのボタンを備えているものとする。項目の型属性から、チェックプログラムと補完プログラムの呼出を作成する。本実施例では、入力フォームの値が変更されたイベントで、補完プログラムを呼び出し、提出ボタンが押されたイベントでエラーチェックプログラムが呼び出されることとする。

書類入力画面０１０２０は、ｊａｖａｓｃｒｉｐｔのＸｍｌ＿Ｈｔｔｐ＿Ｒｅｑｕｅｓｔ等を用いて非同期で入力フォームの内容を送信し結果を受け取る。

利用者が入力フォームに値を入力すると、書類入力画面０１０２０から補完プログラムに入力された内容が送信され、補完プログラムによって補完値の取得が行われる。補完プログラムの結果、補完候補があれば、補完プログラムから補完候補が返却され、テキストボックスの下部に選択値を一覧表示する等の方法で補完候補を表示する。

２−３−４．書類の提出
利用者が必要事項を全て入力し、提出ボタンをクリックすると、書類入力画面からチェックプログラムに入力フォームの内容が送信され、チェックプログラムによってエラーチェックが行われる。チェックプログラムの結果が返却されてエラーであれば、入力画面にエラーを表示する。入力画面にエラーを表示する方法としては、ダイアログボックスを使って警告する方法、入力値をフォーム要素の色を変えて警告する方法、ブロック要素の色や形等の属性値を変更して警告を行う方法などが用いられる。

エラーチェックの結果問題がなければ、書類入力画面０１０２０は、ユーザＩＤ、書類の識別子、及び、入力フォームの内容を書類提出部０１０１１に送信する。

書類提出部０１０１１は、チェックプログラム０１００７を呼び出し、入力フォームの内容を再度チェックする。エラーチェックの結果問題がなければ、入力フォームの内容を当該書類の項目に反映する。

書類提出部０１０１１は、書類の起案者要素０１０６９から作成者のユーザＩＤを探し、権限の確認を行う。提出の権限を確認する条件は以下のとおりである。

・承認経路要素に却下要素、又は、削除要素が無く、起案者要素の予定者要素に自身のユーザＩＤが存在し、当該起案者要素の実施者要素が空であり、当該起案者要素の所有時権限要素に値“ａｐｐｒｏｖａｌ”、及び、“ｗｒｉｔｅ”があり、当該起案者要素の承認権限要素に値“ｆｏｒｗａｒｄ”がある。

権限に問題がなければ、起案者要素０１０６９の実施者要素に作成者の所属部門ＩＤを内容にした部門要素、作成者のユーザＩＤを内容にしたユーザ要素、提出した日時を内容にした日付要素を追加する。ここで、実施者要素の内容を作成するということは、書類の作成が完了したことを意味するとともに、当該ユーザが所有者でなくなり、承認経路上の次のユーザが所有者になることを意味する。これは、所有時権限要素に記述された権限が無効になるということである。

更新した書類を、書類を保存するサーバ０１０１７に送信し、保存されている書類を更新する。

２−４． 承認
次に、承認を行う際の処理手順について説明する。

２−４−１．対象書類の検索
承認者が書類を承認する場合は、書類検索画面０１０１９から、書類が却下も削除もされておらず、自身が承認予定者で、まだ承認を実施していない書類を検索する。
書類の承認経路要素に対する具体的な検索条件は、以下のいずれかである。

・承認経路要素に却下要素、又は、削除要素が無く、承認者要素の予定者要素に自身のユーザＩＤが存在し、当該承認者要素の実施者要素が空であり、当該承認者要素の所有時権限要素に値“ａｐｐｒｏｖａｌ”があり、当該承認者要素の承認権限要素に値“ｆｏｒｗａｒｄ”があり、当該承認者要素の一つ前の起案者要素か、承認者要素の実施者要素に値がある。

・承認経路要素に却下要素、又は、削除要素が無く、最終決裁者要素の予定者要素に自身のユーザＩＤが存在し、当該最終決裁者要素の実施者要素が空であり、当該最終決裁者要素の所有時権限要素に値“ａｐｐｒｏｖａｌ”があり、当該最終決裁者要素の承認権限要素に値“ｆｏｒｗａｒｄ”があり、当該最終決裁者要素の一つ前の起案者要素か、承認者要素の実施者要素に値がある。

なお、書類検索画面０１０１９は、このような検索条件をユーザが任意に指定できるようにしてもよいし、事前に用意して、“承認待ち”のようなリンクを押下することで実行するようにしてもよい。

書類検索画面０１０１９は、検索条件を書類検索部０１０１３へ送信する。書類検索部０１０１３は、書類の承認経路要素に対して検索を実行し、該当書類を特定する。書類検索部０１０１３は該当書類の一覧を、書類検索画面０１０１９へ返す。書類検索画面０１０１９は該当書類の一覧を表示する。

図２２に検索画面の例を示す。

２−４−２．書類の表示
承認者が、該当書類の一覧から承認対象の書類を選択すると、書類承認画面０１０２１が表示される。このとき書類検索画面０１０１９からは書類の識別子が渡される。書類承認画面０１０２１は書類参照部０１０１４へユーザＩＤと書類の識別子を渡す。書類参照部０１０１４は、書類を保存するサーバ０１０１７から、書類の識別子で特定される書類を取得する。書類参照部０１０１４は、検索を行った時と同じ条件で書類の承認が可能か確認する。条件は以下のいずれかである。

・承認経路要素に却下要素、又は、削除要素が無く、承認者要素の予定者要素に自身のユーザＩＤが存在し、当該承認者要素の実施者要素が空であり、当該承認者要素の所有時権限要素に値“ａｐｐｒｏｖａｌ”があり、当該承認者要素の承認権限要素に値“ｆｏｒｗａｒｄ”があり、当該承認者要素の一つ前の起案者要素か、承認者要素の実施者要素に値がある。

・承認経路要素に却下要素、又は、削除要素が無く、最終決裁者要素の予定者要素に自身のユーザＩＤが存在し、当該最終決裁者要素の実施者要素が空であり、当該最終決裁者要素の所有時権限要素に値“ａｐｐｒｏｖａｌ”があり、当該最終決裁者要素の承認権限要素に値“ｆｏｒｗａｒｄ”があり、当該最終決裁者要素の一つ前の起案者要素か、承認者要素の実施者要素に値がある。

権限に問題がなければ、書類参照部０１０１４は、取得した書類を書類承認画面０１０２１に返却し、書類承認画面０１０２１は返却されたＸＭＬ形式の書類をＨＴＭＬに変換し表示する。この時、書類承認画面０１０２１は、あらかじめ用意した承認ボタンを押下可能にする。

図２３に承認画面の例を示す。

２−４−３．承認の実施（承認の場合）
承認者は、書類に問題がなければ、書類承認画面０１０２１に備えられた承認ボタンを押下する。書類承認画面０１０２１は、書類の識別子、利用者のユーザＩＤ、及び、承認を意味するフラグを引数に、書類承認部０１０１２を呼び出す。

書類承認部０１０１２は、検索を行った時、及び、書類を表示した時と同じ条件で書類の承認が可能か確認する。条件は以下のいずれかである。

・承認経路要素に却下要素、又は、削除要素が無く、承認者要素の予定者要素に自身のユーザＩＤが存在し、当該承認者要素の実施者要素が空であり、当該承認者要素の所有時権限要素に値“ａｐｐｒｏｖａｌ”があり、当該承認者要素の承認権限要素に値“ｆｏｒｗａｒｄ”があり、当該承認者要素の一つ前の起案者要素か、承認者要素の実施者要素に値がある。

・承認経路要素に却下要素、又は、削除要素が無く、最終決裁者要素の予定者要素に自身のユーザＩＤが存在し、当該最終決裁者要素の実施者要素が空であり、当該最終決裁者要素の所有時権限要素に値“ａｐｐｒｏｖａｌ”があり、当該最終決裁者要素の承認権限要素に値“ｆｏｒｗａｒｄ”があり、当該最終決裁者要素の一つ前の起案者要素か、承認者要素の実施者要素に値がある。

権限に問題がなければ、書類の承認者の実施者要素に承認者の所属部門ＩＤを内容にした部門要素０１０８０、承認者のユーザＩＤを内容にしたユーザ要素０１０８１、承認した日時を内容にした日時要素０１０８２、承認した旨を意味する承認要素０１０８３を追加する。書類承認部０１０１２は、変更した書類を書類を保存するサーバ０１０１７に送信し、保存されている書類を更新する。

図２４は、承認後の書類の承認者要素の例である。

２−４−４．承認の実施（却下の場合）
書類を却下する場合も、同様の処理の流れとなる。却下の場合は、承認時の条件で確認する承認権限要素の値は“ｒｅｊｅｃｔ”となる。また、書類の実施者要素に追加する要素は、承認要素０１０８３ではなく却下要素０１０８４とする。

２−４−５．承認の実施（差戻の場合）
書類を差戻しする場合に、書類参照部０１０１４が確認する条件は以下のいずれかである。これは、承認時の条件において、確認する承認権限要素の値を“ｒｅｔｕｒｎ”に置き換えたものである。

・承認経路要素に却下要素、又は、削除要素が無く、承認者要素の予定者要素に自身のユーザＩＤが存在し、当該承認者要素の実施者要素が空であり、当該承認者要素の所有時権限要素に値“ａｐｐｒｏｖａｌ”があり、当該承認者要素の承認権限要素に値“ｒｅｔｕｒｎ”があり、当該承認者要素の一つ前の起案者要素か、承認者要素の実施者要素に値がある。

・承認経路要素に却下要素、又は、削除要素が無く、最終決裁者要素の予定者要素に自身のユーザＩＤが存在し、当該最終決裁者要素の実施者要素が空であり、当該最終決裁者要素の所有時権限要素に値“ａｐｐｒｏｖａｌ”があり、当該最終決裁者要素の承認権限要素に値“ｒｅｔｕｒｎ”があり、当該最終決裁者要素の一つ前の起案者要素か、承認者要素の実施者要素に値がある。

書類承認画面０１０２１は“ｒｅｔｕｒｎ”のキーワードがあれば、差戻しボタンを押下可能にする。承認者が差戻しボタンを押下すると、書類承認画面０１０２１は、書類の識別子、承認者のユーザＩＤ、及び、差戻しを意味するフラグを引数に、書類承認部０１０１２を呼び出す。

書類承認部０１０１２は、書類参照部０１０１４と同様の条件で、所有者と権限の確認を行う。

書類を差戻しする場合に、書類承認部０１０１２が確認する条件は、書類参照部０１０１４が確認する条件と同じく、以下のいずれかである。

・承認経路要素に却下要素、又は、削除要素が無く、承認者要素の予定者要素に自身のユーザＩＤが存在し、当該承認者要素の実施者要素が空であり、当該承認者要素の所有時権限要素に値“ａｐｐｒｏｖａｌ”があり、当該承認者要素の承認権限要素に値“ｒｅｔｕｒｎ”があり、当該承認者要素の一つ前の起案者要素か、承認者要素の実施者要素に値がある。

・承認経路要素に却下要素、又は、削除要素が無く、最終決裁者要素の予定者要素に自身のユーザＩＤが存在し、当該最終決裁者要素の実施者要素が空であり、当該最終決裁者要素の所有時権限要素に値“ａｐｐｒｏｖａｌ”があり、当該最終決裁者要素の承認権限要素に値“ｒｅｔｕｒｎ”があり、当該最終決裁者要素の一つ前の起案者要素か、承認者要素の実施者要素に値がある。

問題がなければ、まず、一つ前の承認者要素か起案者要素の実施者要素の要素名を実施履歴要素０１０８５に変更し、新しく内容が空の実施者要素０１０９０を作成する。次に、承認者要素の下にも実施履歴要素０１０９１を作成し、承認者の所属部門ＩＤを内容にした部門要素０１０８０、承認者のユーザＩＤを内容にしたユーザ要素０１０８１、承認した日時を内容にした日時要素０１０８２、差戻しした旨を意味する差戻要素０１０９２を追加する。書類承認部０１０１２は、変更した書類を書類を保存するサーバ０１０１７に送信し、保存されている書類を更新する。

図２５は、差戻し後の書類の承認経路要素の例である。

２−４−６．承認の実施（飛ばし承認）
書類の飛ばし承認（強制承認）や飛ばし決裁（強制決裁）を行う場合に、書類参照部０１０１４が確認する条件は以下のいずれかである。

・承認経路要素に却下要素、又は、削除要素が無く、起案者要素の実施者要素に値があり、承認者要素の予定者要素に自身のユーザＩＤが存在し、当該承認者要素の実施者要素が空であり、当該承認者要素の所有時権限要素に値“ａｐｐｒｏｖａｌ”があり、当該承認者要素の承認権限要素に値“ｓｋｉｐ”があり、当該承認者要素の前の承認者要素の実施者要素に値がない。

・承認経路要素に却下要素、又は、削除要素が無く、起案者要素の実施者要素に値があり、最終決裁者要素の予定者要素に自身のユーザＩＤが存在し、当該最終決裁者要素の実施者要素が空であり、当該最終決裁者要素の所有時権限要素に値“ａｐｐｒｏｖａｌ”があり、当該最終決裁者要素の承認権限要素に値“ｓｋｉｐ”があり、当該最終決裁者要素の前の承認者要素の実施者要素に値がない。

書類承認画面０１０２１は“ｓｋｉｐ”のキーワードがあれば、飛ばし承認ボタンを押下可能にする。承認者が飛ばし承認ボタンを押下すると、書類承認画面０１０２１は、書類の識別子、承認者のユーザＩＤ、及び、飛ばし承認を意味するフラグを引数に、書類承認部０１０１２を呼び出す。

書類承認部０１０１２は、所有者と権限の確認を行う。

書類を飛ばし承認、又は、飛ばし決裁する場合に、書類承認部０１０１２が確認する条件は、書類参照部０１０１４が確認する条件と同じく、以下のいずれかである。

・承認経路要素に却下要素、又は、削除要素が無く、起案者要素の実施者要素に値があり、承認者要素の予定者要素に自身のユーザＩＤが存在し、当該承認者要素の実施者要素が空であり、当該承認者要素の所有時権限要素に値“ａｐｐｒｏｖａｌ”があり、当該承認者要素の承認権限要素に値“ｓｋｉｐ”があり、当該承認者要素の前の承認者要素の実施者要素に値がない。

・承認経路要素に却下要素、又は、削除要素が無く、起案者要素の実施者要素に値があり、最終決裁者要素の予定者要素に自身のユーザＩＤが存在し、当該最終決裁者要素の実施者要素が空であり、当該最終決裁者要素の所有時権限要素に値“ａｐｐｒｏｖａｌ”があり、当該最終決裁者要素の承認権限要素に値“ｓｋｉｐ”があり、当該最終決裁者要素の前の承認者要素の実施者要素に値がない。

問題がなければ、一つ前の承認者の実施者要素０１０８６と自身の実施者要素双方に、承認者の所属部門ＩＤを内容にした部門要素０１０８０、承認者のユーザＩＤを内容にしたユーザ要素０１０８１、承認した日時を内容にした日時要素０１０８２、承認した旨を意味する承認要素０１０８７を追加する。書類承認部０１０１２は、変更した書類を書類を保存するサーバ０１０１７に送信し、保存されている書類を更新する。

図２６は、飛ばし承認後の書類の承認経路要素の例である。

２−４−７．承認（取戻し）
書類の取戻しを行う場合に、書類参照部０１０１４が確認する条件は以下のいずれかである。

・承認経路要素に却下要素、又は、削除要素が無く、起案者要素の実施者要素に自身のユーザＩＤが存在し、当該起案者要素の所有時権限要素に値“ａｐｐｒｏｖａｌ”があり、当該起案者要素の承認権限要素に値“ｇｅｔｂａｃｋ”があり、当該起案者要素の一つ後の承認者要素に値が無い。

・承認経路要素に却下要素、又は、削除要素が無く、承認者要素の実施者要素に自身のユーザＩＤが存在し、当該承認者要素の所有時権限要素に値“ａｐｐｒｏｖａｌ”があり、当該承認者要素の承認権限要素に値“ｇｅｔｂａｃｋ”があり、当該承認者要素の一つ後の承認者要素に値が無い。

書類承認画面０１０２１は“ｇｅｔｂａｃｋ”のキーワードがあれば、取戻しボタンを押下可能にする。承認者が取戻しボタンを押下すると、書類承認画面０１０２１は、書類の識別子、承認者のユーザＩＤ、及び、取戻しを意味するフラグを引数に、書類承認部０１０１２を呼び出す。

書類承認部０１０１２は、所有者と権限の確認を行う。
書類を取戻しする場合に、書類承認部０１０１２が確認する条件は、書類参照部０１０１４が確認する条件と同じく、以下のいずれかである。

・承認経路要素に却下要素、又は、削除要素が無く、起案者要素の実施者要素に自身のユーザＩＤが存在し、当該起案者要素の所有時権限要素に値“ａｐｐｒｏｖａｌ”があり、当該起案者要素の承認権限要素に値“ｇｅｔｂａｃｋ”があり、当該起案者要素の一つ後の承認者要素に値が無い。

・承認経路要素に却下要素、又は、削除要素が無く、承認者要素の実施者要素に自身のユーザＩＤが存在し、当該承認者要素の所有時権限要素に値“ａｐｐｒｏｖａｌ”があり、当該承認者要素の承認権限要素に値“ｇｅｔｂａｃｋ”があり、当該承認者要素の一つ後の承認者要素に値が無い。

問題がなければ、まず、自身が実施した承認者要素か起案者要素の実施者要素の要素名を実施履歴要素０１０８５に変更し、新しく内容が空の実施者要素０１０９０を作成する。次に、次の承認者要素の下にも実施履歴要素０１０９１を作成し、取戻しを行ったユーザの所属部門ＩＤを内容にした部門要素０１０８０、取戻しを行ったユーザのユーザＩＤを内容にしたユーザ要素０１０８１、取戻しした日時を内容にした日時要素０１０８２、取戻しを意味する取戻要素０１０９３を追加する。書類承認部０１０１２は、変更した書類を書類を保存するサーバ０１０１７に送信し、保存されている書類を更新する。

２−５． 削除
書類の削除を行う際の処理手順について説明する。

２−５−１．対象書類の検索
利用者が書類を削除する場合は、書類検索画面０１０１９から自身が所有者で削除権限を付与されている書類の検索を行う。削除可能な書類を検索するための条件は以下のいずれかとなる。

・承認経路要素に却下要素、又は、削除要素が無く、起案者要素の予定者要素に自身のユーザＩＤが存在し、当該起案者要素の実施者要素が空であり、当該起案者要素の所有時権限要素に値“ｄｅｌｅｔｅ”がある。

・承認経路要素に却下要素、又は、削除要素が無く、承認者要素の予定者要素に自身のユーザＩＤが存在し、当該承認者要素の実施者要素が空であり、当該承認者要素の所有時権限要素に値“ｄｅｌｅｔｅ”あり、当該承認者要素の一つ前の承認者要素、又は、起案者要素の実施者要素に値がある。

・承認経路要素に却下要素、又は、削除要素が無く、最終決裁者要素の予定者要素に自身のユーザＩＤが存在し、当該最終決裁者の実施者要素が空であり、当該最終決裁者の所有時権限要素に値“ｄｅｌｅｔｅ”があり、当該最終決裁者の一つ前の承認者要素、又は、起案者要素の実施者要素に値がある。

・承認経路要素に削除要素が無く、すべての実施者要素が値を持ち、起案者要素、承認者要素、又は、最終決裁者要素の決裁後権限要素に値“ｄｅｌｅｔｅ”があり、決裁後権限要素の所属部門、及び、所属メンバーが示す範囲に、自身のユーザＩＤが含まれる。

・承認経路要素に削除要素が無く、承認経路要素に却下要素があり、起案者要素、承認者要素、又は、最終決裁者要素の決裁後権限要素に値“ｄｅｌｅｔｅ”があり、決裁後権限要素の所属部門、及び、所属メンバーが示す範囲に、自身のユーザＩＤが含まれる。

最後の二つの条件については、所属部門、及び、所属メンバーが示す範囲を求めるために組織情報が必要である。書類検索部０１０１３は、組織情報・様式・既存の型を保存するサーバ０１００１から、組織情報を取得し、組織情報の組織階層情報から、決裁後権限要素を持つ実施者要素に書かれたユーザＩＤを特定する。

書類検索部０１０１３は、組織階層情報で特定した実施者のユーザＩＤを軸に、当該実施者の決裁後権限要素の対象部門要素に記述された相対的に対象部門を特定するキーワードを用いて、具体的な部門ＩＤを特定する。相対的に対象部門を特定するキーワードとは、例えば、“ｓｅｌｆ”であれば、実施者の所属部門、“ｃｈｉｌｄ”であれば、一つ下位の部門、“ａｎｃｅｓｔｏｒ”であれば上位の部門すべてを示す。

次に、書類検索部０１０１３は、決裁後権限要素の対象ユーザ要素に記述された対象メンバーの種類を示すキーワードと、特定した部門ＩＤから、最終的に参照権限を持ったユーザＩＤのリストを特定する。対象メンバーの種類を示すキーワードとは、例えば“ｈｅａｄ”であれば、部門の長を、“ｍｅｍｂｅｒ”であれば、部門のメンバーを示す。

この処理は、処理速度に問題がなければ、検索の度に行ってもよいし、書類ごとに事前に求めておいてもよい。

書類検索画面０１０１９は、検索条件を書類検索部０１０１３へ送信する。書類検索部０１０１３は、書類の承認経路要素に対して検索を実行し、該当書類を特定する。書類検索部０１０１３は該当書類の一覧を、書類検索画面０１０１９へ返す。書類検索画面０１０１９は該当書類の一覧を表示する。

２−５−２．書類の表示
利用者が、該当書類の一覧から削除対象の書類を選択すると、書類参照画面０１０２２が表示される。このとき書類検索画面０１０１９からは書類の識別子が渡される。書類参照画面０１０２２は書類参照部０１０１４へユーザＩＤと書類の識別子を渡す。書類参照部０１０１４は、書類を保存するサーバ０１０１７から、書類の識別子で特定される書類を取得し、権限の確認を行う。書類参照部０１０１４が確認する権限の条件は、書類を検索する場合の条件と同じく、以下のいずれかである。

・承認経路要素に却下要素、又は、削除要素が無く、起案者要素の予定者要素に自身のユーザＩＤが存在し、当該起案者要素の実施者要素が空であり、当該起案者要素の所有時権限要素に値“ｄｅｌｅｔｅ”がある。

・承認経路要素に却下要素、又は、削除要素が無く、承認者要素の予定者要素に自身のユーザＩＤが存在し、当該承認者要素の実施者要素が空であり、当該承認者要素の所有時権限要素に値“ｄｅｌｅｔｅ”があり、当該承認者要素の一つ前の承認者要素、又は、起案者要素の実施者要素に値がある。

・承認経路要素に却下要素、又は、削除要素が無く、最終決裁者要素の予定者要素に自身のユーザＩＤが存在し、当該最終決裁者の実施者要素が空であり、当該最終決裁者の所有時権限要素に値“ｄｅｌｅｔｅ”があり、当該最終決裁者の一つ前の承認者要素、又は、起案者要素の実施者要素に値がある。

・承認経路要素に削除要素が無く、すべての実施者要素が値を持ち、起案者要素、承認者要素、又は、最終決裁者要素の決裁後権限要素に値“ｄｅｌｅｔｅ”があり、決裁後権限要素の所属部門、及び、所属メンバーが示す範囲に、自身のユーザＩＤが含まれる。

・承認経路要素に削除要素が無く、承認経路要素に却下要素があり、起案者要素、承認者要素、又は、最終決裁者要素の決裁後権限要素に値“ｄｅｌｅｔｅ”があり、決裁後権限要素の所属部門、及び、所属メンバーが示す範囲に、自身のユーザＩＤが含まれる。

最後の二つの条件については、確認のために組織情報が必要であるから、組織情報・様式・既存の型を保存するサーバ０１００１から組織情報を取得して判定を行う。

書類参照部０１０１４は、組織情報・様式・既存の型を保存するサーバ０１００１から、組織情報を取得し、組織情報の組織階層情報から、決裁後権限要素を持つ実施者要素に書かれたユーザＩＤを特定する。

書類参照部０１０１４は、組織階層情報で特定した実施者のユーザＩＤを軸に、当該実施者の決裁後権限要素の対象部門要素に記述された相対的に対象部門を特定するキーワードを用いて、具体的な部門ＩＤを特定する。相対的に対象部門を特定するキーワードとは、例えば、“ｓｅｌｆ”であれば、実施者の所属部門、“ｃｈｉｌｄ”であれば、一つ下位の部門、“ａｎｃｅｓｔｏｒ”であれば上位の部門すべてを示す。

次に、書類参照部０１０１４は、決裁後権限要素の対象ユーザ要素に記述された対象メンバーの種類を示すキーワードと、特定した部門ＩＤから、最終的に参照権限を持ったユーザＩＤのリストを特定する。対象メンバーの種類を示すキーワードとは、例えば“ｈｅａｄ”であれば、部門の長を、“ｍｅｍｂｅｒ”であれば、部門のメンバーを示す。

書類参照部０１０１４は、参照画面から渡された、参照を行おうとしているユーザＩＤが、上記方法で割り出した参照権限を持ったユーザＩＤのリストに含まれれば、書類を参照可能と判断する。

権限に問題がなければ、書類承認部０１０１２は、取得した書類を書類承認画面０１０２１に返却し、書類承認画面０１０２１は返却されたＸＭＬ形式の書類をＨＴＭＬに変換し表示する。

２−５−３．削除の実施
利用者は、書類を参照し、削除対象の書類であることを確認し、書類参照画面０１０２２に備えられた削除ボタンを押下する。書類参照画面０１０２２は、書類の識別子、利用者のユーザＩＤ、及び、削除を意味するフラグを引数に、書類削除部０１０１５を呼び出す。

書類削除部０１０１５は、書類を検索する際の条件、及び、書類参照部０１０１４が確認する条件と同じ条件で確認を行う。削除を実施できる条件は、以下のいずれかである。

・承認経路要素に却下要素、又は、削除要素が無く、起案者要素の予定者要素に自身のユーザＩＤが存在し、当該起案者要素の実施者要素が空であり、当該起案者要素の所有時権限要素に値“ｄｅｌｅｔｅ”がある。

・承認経路要素に却下要素、又は、削除要素が無く、承認者要素の予定者要素に自身のユーザＩＤが存在し、当該承認者要素の実施者要素が空であり、当該承認者要素の所有時権限要素に値“ｄｅｌｅｔｅ”があり、当該承認者要素の一つ前の承認者要素、又は、起案者要素の実施者要素に値がある。

・承認経路要素に却下要素、又は、削除要素が無く、最終決裁者要素の予定者要素に自身のユーザＩＤが存在し、当該最終決裁者の実施者要素が空であり、当該最終決裁者の所有時権限要素に値“ｄｅｌｅｔｅ”があり、当該最終決裁者の一つ前の承認者要素、又は、起案者要素の実施者要素に値がある。

・承認経路要素に削除要素が無く、すべての実施者要素が値を持ち、起案者要素、承認者要素、又は、最終決裁者要素の決裁後権限要素に値“ｄｅｌｅｔｅ”があり、決裁後権限要素の所属部門、及び、所属メンバーが示す範囲に、自身のユーザＩＤが含まれる。

・承認経路要素に削除要素が無く、承認経路要素に却下要素があり、起案者要素、承認者要素、又は、最終決裁者要素の決裁後権限要素に値“ｄｅｌｅｔｅ”があり、決裁後権限要素の所属部門、及び、所属メンバーが示す範囲に、自身のユーザＩＤが含まれる。

最後の二つの条件については、確認のために組織情報が必要であるから、組織情報・様式・既存の型を保存するサーバ０１００１から組織情報を取得して判定を行う。

書類削除部０１０１５は、組織情報・様式・既存の型を保存するサーバ０１００１から、組織情報を取得し、組織情報の組織階層情報から、決裁後権限要素を持つ実施者要素に書かれたユーザＩＤを特定する。

書類削除部０１０１５は、組織階層情報で特定した実施者のユーザＩＤを軸に、当該実施者の決裁後権限要素の対象部門要素に記述された相対的に対象部門を特定するキーワードを用いて、具体的な部門ＩＤを特定する。相対的に対象部門を特定するキーワードとは、例えば、“ｓｅｌｆ”であれば、実施者の所属部門、“ｃｈｉｌｄ”であれば、一つ下位の部門、“ａｎｃｅｓｔｏｒ”であれば上位の部門すべてを示す。

次に、書類削除部０１０１５は、決裁後権限要素の対象ユーザ要素に記述された対象メンバーの種類を示すキーワードと、特定した部門ＩＤから、最終的に参照権限を持ったユーザＩＤのリストを特定する。対象メンバーの種類を示すキーワードとは、例えば“ｈｅａｄ”であれば、部門の長を、“ｍｅｍｂｅｒ”であれば、部門のメンバーを示す。

書類削除部０１０１５は、参照画面から渡された、参照を行おうとしているユーザＩＤが、上記方法で割り出した参照権限を持ったユーザＩＤのリストに含まれれば、書類を削除する権限を有していると判断する。

権限に問題がなければ、当該ユーザの実施者要素に削除したユーザの所属部門ＩＤを内容にした部門要素０１０８０、削除したユーザのユーザＩＤを内容にしたユーザ要素０１０８１、削除した日時を内容にした日時要素０１０８２、削除した旨を意味する削除要素０１０８８を追加し、書類を保存するサーバ０１０１７に保存されている書類を更新する。

２−６． 参照
次に、書類の参照を行う際の処理手順について、説明する。

２−６−１．書類の検索
利用者は、書類検索画面０１０１９を表示し、書類の検索を行う。

書類検索画面０１０１９は、検索条件を書類検索部０１０１３へ送信する。書類検索部０１０１３は、書類の承認経路要素に対して検索を実行し、該当書類を特定する。
自身が参照できる書類を検索する条件は、以下のいずれかである。

・承認経路要素に却下要素、又は、削除要素が無く、起案者要素の予定者要素に自身のユーザＩＤが存在し、当該起案者要素の実施者要素が空であり、当該起案者要素の所有時権限要素に値がある。

・承認経路要素に却下要素、又は、削除要素が無く、承認者要素の予定者要素に自身のユーザＩＤが存在し、当該承認者要素の実施者要素が空であり、当該承認者要素の所有時権限要素に値があり、当該承認者要素の一つ前の承認者要素、又は、起案者要素の実施者要素に値がある。

・承認経路要素に却下要素、又は、削除要素が無く、最終決裁者要素の予定者要素に自身のユーザＩＤが存在し、当該最終決裁者の実施者要素が空であり、当該最終決裁者の所有時権限要素に値があり、当該最終決裁者の一つ前の承認者要素、又は、起案者要素の実施者要素に値がある。

・すべての実施者要素が値を持つか、又は、承認経路要素に却下要素があり、起案者要素、承認者要素、又は、最終決裁者要素の決裁後権限要素の所属部門、及び、所属メンバーが示す範囲に、自身のユーザＩＤが含まれる。

最後の条件については、所属部門、及び、所属メンバーが示す範囲を求めるために組織情報が必要であるから、組織情報・様式・既存の型を保存するサーバ０１００１から組織情報を取得して判定を行う。書類検索部０１０１３は、組織情報・様式・既存の型を保存するサーバ０１００１から、組織情報を取得し、組織情報の組織階層情報から、決裁後権限要素を持つ実施者要素に書かれたユーザＩＤを特定する。

書類検索部０１０１３は、組織階層情報で特定した実施者のユーザＩＤを軸に、当該実施者の決裁後権限要素の対象部門要素に記述された相対的に対象部門を特定するキーワードを用いて、具体的な部門ＩＤを特定する。相対的に対象部門を特定するキーワードとは、例えば、“ｓｅｌｆ”であれば、実施者の所属部門、“ｃｈｉｌｄ”であれば、一つ下位の部門、“ａｎｃｅｓｔｏｒ”であれば上位の部門すべてを示す。

次に、書類検索部０１０１３は、決裁後権限要素の対象ユーザ要素に記述された対象メンバーの種類を示すキーワードと、特定した部門ＩＤから、最終的に参照権限を持ったユーザＩＤのリストを特定する。対象メンバーの種類を示すキーワードとは、例えば“ｈｅａｄ”であれば、部門の長を、“ｍｅｍｂｅｒ”であれば、部門のメンバーを示す。

この処理は、処理速度に問題がなければ、検索の度に行ってもよいし、書類ごとに事前に求めておいてもよい。

値“ｒｅａｄ”以外の権限についても、各操作を行うためには参照が必要であるため、参照権限があると判断する。

なお、書類検索画面Ｘ０１５３は上記条件に加えて、日付や書類名などで、さらに絞り込む機能を持たせてもよい。

書類検索部０１０１３は該当書類の一覧を、書類検索画面０１０１９へ返す。書類検索画面０１０１９は該当書類の一覧を表示する。

２−６−２．書類参照画面の表示
利用者が、該当書類の一覧から承認対象の書類を選択すると、書類参照画面０１０２２が表示される。このとき書類検索画面０１０１９からは書類の識別子が渡される。書類参照画面０１０２２は書類参照部０１０１４へ利用者のユーザＩＤと書類の識別子を渡す。

２−６−３．書類の所有者と権限の確認
書類参照部０１０１４は、書類を保存するサーバ０１０１７から、書類の識別子で特定される書類を取得し権限の確認を行う。権限を確認するための条件は、書類を検索する場合の条件と同じく、以下のいずれかである。

・承認経路要素に却下要素、又は、削除要素が無く、起案者要素の予定者要素に自身のユーザＩＤが存在し、当該起案者要素の実施者要素が空であり、当該起案者要素の所有時権限要素に値がある。

・承認経路要素に却下要素、又は、削除要素が無く、承認者要素の予定者要素に自身のユーザＩＤが存在し、当該承認者要素の実施者要素が空であり、当該承認者要素の所有時権限要素に値があり、当該承認者要素の一つ前の承認者要素、又は、起案者要素の実施者要素に値がある。

・承認経路要素に却下要素、又は、削除要素が無く、最終決裁者要素の予定者要素に自身のユーザＩＤが存在し、当該最終決裁者の実施者要素が空であり、当該最終決裁者の所有時権限要素に値があり、当該最終決裁者の一つ前の承認者要素、又は、起案者要素の実施者要素に値がある。

・すべての実施者要素が値を持つか、又は、承認経路要素に却下要素があり、起案者要素、承認者要素、又は、最終決裁者要素の決裁後権限要素の所属部門、及び、所属メンバーが示す範囲に、自身のユーザＩＤが含まれる。

最後の条件については、確認のために組織情報が必要であるから、組織情報・様式・既存の型を保存するサーバ０１００１から組織情報を取得して判定を行う。

書類参照部０１０１４は、組織情報・様式・既存の型を保存するサーバ０１００１から、組織情報を取得し、組織情報の組織階層情報から、決裁後権限要素を持つ実施者要素に書かれたユーザＩＤを特定する。

書類参照部０１０１４は、組織階層情報で特定した実施者のユーザＩＤを軸に、当該実施者の決裁後権限要素の対象部門要素に記述された相対的に対象部門を特定するキーワードを用いて、具体的な部門ＩＤを特定する。相対的に対象部門を特定するキーワードとは、例えば、“ｓｅｌｆ”であれば、実施者の所属部門、“ｃｈｉｌｄ”であれば、一つ下位の部門、“ａｎｃｅｓｔｏｒ”であれば上位の部門すべてを示す。

次に、書類参照部０１０１４は、決裁後権限要素の対象ユーザ要素に記述された対象メンバーの種類を示すキーワードと、特定した部門ＩＤから、最終的に参照権限を持ったユーザＩＤのリストを特定する。対象メンバーの種類を示すキーワードとは、例えば“ｈｅａｄ”であれば、部門の長を、“ｍｅｍｂｅｒ”であれば、部門のメンバーを示す。

書類参照部０１０１４は、参照画面から渡された、参照を行おうとしているユーザＩＤが、上記方法で割り出した参照権限を持ったユーザＩＤのリストに含まれれば、書類を参照する権限を有していると判断する。

２−６−４．書類の表示
書類参照部０１０１４は、権限の確認に問題がなければ、書類参照画面０１０２２へ当該書類を返却する。書類参照画面０１０２２は、返却されたＸＭＬ形式の書類をＨＴＭＬへ変換して表示する。

３． 権限のまとめ
処理の流れで説明した各処理における、権限の確認方法について図２７、２８にまとめる。

権限の確認は、ＷＥＢサーバ０１０２３の各画面が、対応するボタンを表示するかしないかを判断する場合や、アプリケーションサーバ０１０１６の各部が実際に処理を行ってよいかどうかを判断する場合に行われる。

なお、ハードウェアの構成について、本実施例では複数台のサーバとして記載しているが、もちろん単体のサーバとして実装してもよく、また、複数の筐体で構成することを否定するものではない。

実施例１において使用する、組織情報記述言語の一例を述べる。

組織情報はユーザ情報と組織階層情報で構成される。

ユーザ情報は、ユーザの識別子、氏名、役職のリストである。組織階層情報は組織を構成する部門の階層構造と、各部門に所属するユーザを定義する。部門には必ず部門を代表するユーザが一人存在する。ユーザの階層構造とせず、部門の階層構造とし、部門にユーザを所属させる構造としたことが特徴である。

以下に組織情報を定義する専用言語一例を示す。

１．ユーザ情報
まず、ユーザ情報は以下の文法とする。
Ｕｓｅｒｓ ｛
ユーザ０２００１
ユーザ０２００１
｝
ユーザ０２００１はユーザ一人の情報で、複数記述できる。
ユーザ０２００１は次のような構成になる。
Ｕｓｅｒ（ユーザ識別子０２００２）｛
Ｎａｍｅ：氏名０２００３
Ｐｏｓｔ：役職０２００４
Ｐａｓｓｗｏｒｄ：パスワード０２００５
｝

ユーザ識別子０２００２はユーザの識別子である。ユーザ情報内でユニークである必要がある。

氏名０２００３はユーザの氏名である。

役職０２００４はユーザの役職である。複数記述することができる。

ユーザ情報の記述例を図２９に示す。

２．組織階層情報
次に組織階層情報は以下の文法とする。
Ｏｒｇａｎｉｚａｔｉｏｎ｛
部門０２００６
｝

部門０２００６は部門一つの情報で、最上位では一つ記述できる。

部門０２００６は次のような構成になる。
Ｓｅｃｔｉｏｎ（部門識別子０２００７）｛
Ｓｅｃｔｉｏｎ−ｎａｍｅ：部門名０２００８
Ｈｅａｄ：部門の長０２００９
Ｍｅｍｂｅｒ：所属メンバー０２０１０
権限の定義０２０１１
部門０２００６
スタッフ部門０２０１２
｝

部門識別子０２００７は部門の識別子である。組織階層情報の中でユニークである必要がある。

部門名０２００８は部門の名前である。

部門の長０２００９は、部門の長である。ユーザ情報で定義されたユーザ識別子を記述する。

所属メンバー０２０１０は部門に所属するユーザである。ユーザ情報で定義されたユーザ識別子を記述する。複数記述することができる。

部門０２００６は、当該部門の下位の部門である。複数記述することができる。

スタッフ部門０２０１２は、スタッフ部門である。スタッフ部門０２０１２は次のような構成になる。構成する各要素は、部門０２００６と同様である。
Ｓｔａｆｆ−Ｓｅｃｔｉｏｎ（部門識別子０２００７）｛
Ｓｅｃｔｉｏｎ−ｎａｍｅ：部門名０２００８
Ｈｅａｄ：部門の長０２００９
Ｍｅｍｂｅｒ：所属メンバー０２０１０
権限の定義０２０１１
部門０２００６
スタッフ部門０２０１２
｝

権限の定義０２０１１は、書類の権限を記述する。

権限の定義０２０１１は、次のように記述する。承認権限の定義０２０１３、所有時の権限定義０２０１４、最終決裁後の権限定義０２０１５がそれぞれ０回以上記述できる。
ｐｅｒｍｉｓｓｉｏｎ｛
承認権限の定義０２０１３
所有時の権限定義０２０１４
最終決裁後の権限定義０２０１５
｝

承認権限の定義０２０１３は、承認時に実行可能な操作を記述する。
ａｐｐｒｏｖａｌ−ｐｅｒｍｉｓｓｉｏｎ：（承認操作０２０１６，…，承認操作０２０１６），所有者の種類０２０１７
承認操作０２０１６は、キーワード“ｆｏｒｗａｒｄ”、“ｒｅｊｅｃｔ”、“ｒｅｔｕｒｎ”、“ｓｋｉｐ”、“ｇｅｔｂａｃｋ”のいずれかが記述できる。“ｆｏｒｗａｒｄ”は提出、承認、又は決裁を、“ｒｅｊｅｃｔ”は却下を、“ｒｅｔｕｒｎ”は差戻しを、“ｓｋｉｐ”は飛ばし承認（強制承認）、又は、飛ばし決裁（強制決裁）を、“ｇｅｔｂａｃｋ”は取戻しを意味する。

所有時の権限定義０２０１４は、書類の所有者の権限を記述する。
ｏｗｎｅｒ−ｐｅｒｍｉｓｓｉｏｎ：（権限０２０１８，…，権限０２０１８），所有者の種類０２０１７
権限０２０１８は、キーワード“ｒｅａｄ”、“ｗｒｉｔｅ”、“ｄｅｌｅｔｅ”、“ａｐｐｒｏｖａｌ”が記述できる。“ｒｅａｄ”は参照権限を、“ｗｒｉｔｅ”は変更権限を、“ｄｅｌｅｔｅ”は削除権限を、“ａｐｐｒｏｖａｌ”は承認権限を意味する。承認操作０２０１６は、“ａｐｐｒｏｖａｌ”が記述されている場合のみ有効である。

所有者の種類０２０１７は、キーワード“ｃｒｅａｔｏｒ”、“ａｐｐｒｏｖｅｒ”、“ｌａｓｔ−ａｐｐｒｏｖｅｒ”を記述できる。“ｃｒｅａｔｏｒ”は書類の作成者を、“ａｐｐｒｏｖｅｒ”は承認者を、“ｌａｓｔ−ａｐｐｒｏｖｅｒ”は最終決裁者を意味する。

最終決裁後の権限定義０２０１５は、最終決裁後の書類の権限を記述する。
ａｐｐｒｏｖｅｄ−ｐｅｒｍｉｓｓｉｏｎ：（権限０２０１９，…，権限０２０１９），所有者の種類０２０１７，対象部門０２０２０，対象ユーザ０２０２１

権限０２０１９は、キーワード“ｒｅａｄ”、“ｗｒｉｔｅ”、“ｄｅｌｅｔｅ”が記述できる。“ｒｅａｄ”は参照権限を、“ｗｒｉｔｅ”は変更権限を、“ｄｅｌｅｔｅ”は削除権限を意味する。

対象部門０２０２０は、書類の所有者を軸に相対的に部門の範囲を指定する。対象部門０２０２０は、キーワード“ａｌｌ”、“ｓｅｌｆ”、“ｐａｒｅｎｔ”、“ｃｈｉｌｄ”、“ｂｒｏｔｈｅｒ”、“ａｎｃｅｓｔｏｒ”、“ｄｅｓｃｅｎｄａｎｔ”を記述できる。“ａｌｌ”は全部門を、“ｓｅｌｆ”は所有者の所属部門を、“ｐａｒｅｎｔ”は所有者の所属部門の一つ上位の部門を、“ｃｈｉｌｄ”は所有者の所属部門の一つ下位の部門すべてを、“ｂｒｏｔｈｅｒ”は所有者の所属部門と上位部門を同じとする同会層の部門を、“ａｎｃｅｓｔｏｒ”は所有者の所属部門の上位全ての部門を、“ｄｅｓｃｅｎｄａｎｔ”は所有者の所属部門の下位全ての部門を意味する。

対象ユーザ０２０２１は、対象部門０２０２０で指定した部門において、部門に所属するユーザの種類を指定する。対象ユーザ０２０２１は、キーワード“ｓｅｌｆ”、“ｈｅａｄ”、“ｍｅｍｂｅｒ”、“ａｌｌ”を記述できる。“ｓｅｌｆ”は所有者自信を、“ｈｅａｄ”は部門の長を、“ｍｅｍｂｅｒ”は部門に所属するメンバーを、“ａｌｌ”は長とメンバー両方を意味する。

組織階層情報の記述例を図３０に示す。

実施例１において使用する、様式記述言語の一例を述べる。

様式は以下のような文法で定義する。
Ｔｅｍｐｌａｔｅ（様式名０３００１）｛
Ｏｗｎｅｒ：様式所有者０３００２
Ｔｙｐｅ｛
型定義部０３００３
｝
Ｓｔｒｕｃｔｕｒｅ｛
文書構造定義部０３００４
｝
Ａｐｐｒｏｖａｌ ｛
承認経路定義部０３００５
｝
Ｐｅｒｍｉｓｓｉｏｎ｛
権限定義部０３００６
｝
｝

様式名０３００１は様式の識別子になる。

様式所有者０３００２は、この様式の作成者である。

様式所有者０３００２は、部門の識別子と、ユーザの識別子で構成される。部門の識別子とユーザの識別子については実施例２で述べる。

型定義部０３００３には実施例４、実施例７、及び、実施例９で示す、型の定義を記述する。

文書構造定義部０３００４には実施例４、実施例７、及び、実施例９で示す、文書構造の定義を記述する。

承認経路定義部０３００５には実施例５で示す、承認経路の定義を記述する。
権限定義部０３００６には実施例６で示す、権限の定義を記述する。

様式の記述例を図３１に示す。

実施例１における、様式に記述される型、及び、文書構造の定義をするための専用言語の詳細を述べる。

型の定義は以下のように行う。
型名０４００１：型の定義０４００２

型名０４００１は、型の名前である。様式内でユニークである必要がある。

型の定義０４００２は、型の定義を行う。型の定義には、正規表現型０４００３、列挙型０４００４、型名０４００５が記述できる。

正規表現型０４００３は次のように記述する。
型名０４００１：［“正規表現０４００６”］

正規表現０４００６は正規表現を記述する。

列挙型０４００４は次のように記述する。
型名０４００１：（列挙値０４００７，列挙値０４００７，…列挙値０４００７）

列挙値０４００７は、テキスト値、ＮＵＬＬ記号、又は型名を、カンマで区切って複数個記述する。テキスト値を記述する場合は、ダブルクォートで囲う。

次のように型の定義として型名を記述した場合、型に別名を付けたことになる。
型名０４００１：型名０４００５

また、次のようにスペースで区切って複数の型名を記述することも可能である。
型名０４００１：型名０４００５ 型名０４００５ 型名０４００５

この場合、型を組み合わせた、新しい型を定義したことになる。これは、例えばテキストボックスを３つ並べた、電話番号入力項目を定義したい場合等に用いる。

文書構造の定義は以下のように行う。
項目名０４００８：型０４００９

項目名０４００８は、書類の項目名である。複数並べて記述することで、文書構造を定義する。項目名０４００８様式中でユニークである必要がある。

型０４００９は、型名０４０１０、又は、型の定義０４００２を記述できる。型名０４０１０は型定義部で定義した型名か、システムで事前に用意した型があればその型名を記述できる。

図３２に型、及び、文書構造の定義の一例を示す。

様式に記述される承認経路の定義をするための専用言語の詳細を述べる。

承認経路の定義には、起案可能０５００１、起案不可０５００２、承認不要部門０５００３、スタッフ部門承認０５００４、承認ポリシー０５００５がそれぞれ０回以上記述できる。
Ａｐｐｒｏｖａｌ ｛
起案可能０５００１
起案不可０５００２
承認不要部門０５００３
スタッフ部門承認０５００４
｝

起案可能０５００１はこの様式から書類を作成できるユーザを指定する。起案可能０５００１は次のように記述する。
ａｌｌｏｗ−ｃｒｅａｔｅ：対象部門０５００６，ユーザ範囲０５００７

対象部門０５００６は、部門を指定する。対象部門０５００６は、部門の識別子か、キーワード”ｓｅｌｆ”、“ｃｈｉｌｄ”、”ｄｅｓｃｅｎｄａｎｔ”、“ｂｏｔｔｏｍ”を記述できる。”ｓｅｌｆ”は、様式の所有者が所属する部門を指し示す。“ｃｈｉｌｄ”は様式の所有者の所属する部門の一つ下位の部門を指し示す。”ｄｅｓｃｅｎｄａｎｔ”は様式の所有者が所属する部門の下位の部門すべてを指し示す。“ｂｏｔｔｏｍ”は様式の所有者が所属する部門から見て、組織階層の最下層になる部門を指し示す。

ユーザ範囲０５００７は、部門に所属するユーザの範囲を指定する。ユーザ範囲０５００７は、はキーワード“ｈｅａｄ”、“ｍｅｍｂｅｒ”、“ｂｏｔｈ”が記述できる。”ｈｅａｄ”は部門の長を指し示す。“ｍｅｍｂｅｒ”は部門に所属するメンバーを指し示す。”ｂｏｔｈ”はその両方を指し示す。

もし起案可能０５００１を一つも記述しなかった場合は、「ａｌｌｏｗ−ｃｒｅａｔｅ：ｄｅｓｃｅｎｄａｎｔ，ｂｏｔｈ」が記述されているものとする。つまり様式の所有者の所属する部門の下位の部門すべてに所属する全てのユーザが起案可能となる。

起案不可０５００２はこの様式から書類を作成できないユーザを指定する。起案不可０５００２は次のように記述する。
ｄｅｎｙ−ｃｒｅａｔｅ：対象部門０５００６，ユーザ範囲０５００７

対象部門０５００６、及び、ユーザ範囲０５００７は、起案可能０５００１と同様である。

承認不要部門０５００３は、承認を必要としない部門を指定する。承認不要部門０５００３は、以下のように記述する。
ｄｅｎｙ−ａｐｐｒｏｖａｌ：対象部門０５００６
対象部門０５００６は前述のとおりである。

スタッフ部門承認０５００４は、スタッフ部門による承認の有無を指定する。スタッフ部門承認０５００４は以下のように記述する。
ａｐｐｒｏｖａｌ−ｓｔｕｆｆ−ｓｅｃｔｉｏｎ：対象部門０５００８，対象スタッフ部門０５００９，担当スタッフ部門０５０１０

対象部門０５００８は、スタッフ部門による承認を必要とする部門を指定する。対象部門０５００８は、部門の識別子か、キーワード”ｓｅｌｆ”、“ｃｈｉｌｄ”、“ｂｏｔｔｏｍ”が記述できる。キーワードの説明は前述のとおりである。

対象スタッフ部門０５００９は、スタッフ部門の識別子を指定する。

担当スタッフ部門０５０１０は、スタッフ部門の識別子を指定する。担当スタッフ部門０５０１０は、組織階層情報上で対象スタッフ部門０５００９の配下の部門である必要がある。

承認経路の定義の記述例を図３３に示す。

様式に記述される権限の定義をするための専用言語の詳細を述べる。

権限の定義は実施例２で示した組織情報の権限の定義と同じである。

権限の定義には、承認権限の定義０２０１３、所有時の権限定義０２０１４、最終決裁後の権限定義０２０１５がそれぞれ０回以上記述できる。
ｐｅｒｍｉｓｓｉｏｎ｛
承認権限の定義０２０１３
所有時の権限定義０２０１４
最終決裁後の権限定義０２０１５
｝

承認権限の定義０２０１３は、承認時に実行可能な操作を記述する。
ａｐｐｒｏｖａｌ−ｐｅｒｍｉｓｓｉｏｎ：（承認操作０２０１６，…，承認操作０２０１６），所有者の種類０２０１７

承認操作０２０１６は、キーワード“ｆｏｒｗａｒｄ”、“ｒｅｊｅｃｔ”、“ｒｅｔｕｒｎ”、“ｓｋｉｐ”、“ｇｅｔｂａｃｋ”のいずれかが記述できる。“ｆｏｒｗａｒｄ”は提出、承認、又は決裁を、“ｒｅｊｅｃｔ”は却下を、“ｒｅｔｕｒｎ”は差戻しを、“ｓｋｉｐ”は飛ばし承認（強制承認）、又は、飛ばし決裁（強制決裁）を、“ｇｅｔｂａｃｋ”は取戻しを意味する。

所有時の権限定義０２０１４は、書類の所有者の権限を記述する。
ｏｗｎｅｒ−ｐｅｒｍｉｓｓｉｏｎ：（権限０２０１８，…，権限０２０１８），所有者の種類０２０１７

権限０２０１８は、キーワード“ｒｅａｄ”、“ｗｒｉｔｅ”、“ｄｅｌｅｔｅ”、“ａｐｐｒｏｖａｌ”が記述できる。“ｒｅａｄ”は参照権限を、“ｗｒｉｔｅ”は変更権限を、“ｄｅｌｅｔｅ”は削除権限を、“ａｐｐｒｏｖａｌ”は承認権限を意味する。承認操作０２０１６は、“ａｐｐｒｏｖａｌ”が記述されている場合のみ有効である。

所有者の種類０２０１７は、キーワード“ｃｒｅａｔｏｒ”、“ａｐｐｒｏｖｅｒ”、“ｌａｓｔ−ａｐｐｒｏｖｅｒ”を記述できる。“ｃｒｅａｔｏｒ”は書類の作成者を、“ａｐｐｒｏｖｅｒ”は承認者を、“ｌａｓｔ−ａｐｐｒｏｖｅｒ”は最終決裁者を意味する。

最終決裁後の権限定義０２０１５は、最終決裁後の書類の権限を記述する。
ａｐｐｒｏｖｅｄ−ｐｅｒｍｉｓｓｉｏｎ：（権限０２０１９，…，権限０２０１９），所有者の種類０２０１７，対象部門０２０２０，対象ユーザ０２０２１

権限０２０１９は、キーワード“ｒｅａｄ”、“ｗｒｉｔｅ”、“ｄｅｌｅｔｅ”が記述できる。“ｒｅａｄ”は参照権限を、“ｗｒｉｔｅ”は変更権限を、“ｄｅｌｅｔｅ”は削除権限を意味する。

対象部門０２０２０は、書類の所有者を軸に相対的に部門の範囲を指定する。対象部門０２０２０は、キーワード“ａｌｌ”、“ｓｅｌｆ”、“ｐａｒｅｎｔ”、“ｃｈｉｌｄ”、“ｂｒｏｔｈｅｒ”、“ａｎｃｅｓｔｏｒ”、“ｄｅｓｃｅｎｄａｎｔ”を記述できる。“ａｌｌ”は全部門を、“ｓｅｌｆ”は所有者の所属部門を、“ｐａｒｅｎｔ”は所有者の所属部門の一つ上位の部門を、“ｃｈｉｌｄ”は所有者の所属部門の一つ下位の部門すべてを、“ｂｒｏｔｈｅｒ”は所有者の所属部門と上位部門を同じとする同会層の部門を、“ａｎｃｅｓｔｏｒ”は所有者の所属部門の上位全ての部門を、“ｄｅｓｃｅｎｄａｎｔ”は所有者の所属部門の下位全ての部門を意味する。

対象ユーザ０２０２１は、対象部門０２０２０で指定した部門において、部門に所属するユーザの種類を指定する。対象ユーザ０２０２１は、キーワード“ｓｅｌｆ”、“ｈｅａｄ”、“ｍｅｍｂｅｒ”、“ａｌｌ”を記述できる。“ｓｅｌｆ”は所有者自信を、“ｈｅａｄ”は部門の長を、“ｍｅｍｂｅｒ”は部門に所属するメンバーを、“ａｌｌ”は長とメンバー両方を意味する。

権限の定義の記述例を図３４に示す。

実施例１を拡張し、項目間の値の関係を定義することで、複数項目にまたがるエラーチェック、及び、補完を可能とする方法を述べる。

本発明を実現するために必要な構成要素は実施例１と同様である。

１． 専用言語の拡張
まず、型及び文書構造の定義をするための専用言語において、新たに、型を定義する方法として、タプルを使った項目間の値の関係の定義を可能とする。
（型名０７００１，型名０７００１…型名０７００１）：タプルの列挙型０７００２

型名０７００１は定義する型の名前である。カッコでくくり、カンマで区切ることで複数の型名を記述する。

タプルの列挙型０７００２は、以下のようにタプル０７００３を列挙したものになる。
（タプル０７００３，タプル０７００３，…タプル０７００３）

タプル０７００３は、以下のように列挙値０７００４を要素とするタプルである。
（列挙値０７００４，列挙値０７００４，…列挙値０７００４）

型名のタプルと、列挙値のタプルの要素数は同じで、要素の位置は対応している必要がある。つまり、型名のタプルの先頭の型名に対応する列挙値は、列挙値のタプルにおいても先頭である必要がある。

列挙値０７００４は実施例４の場合と同様に、テキスト値、ＮＵＬＬ記号、又は、正規表現型の型名を、カンマで区切って複数個記述する。

図３５に実際に定義した様式の一例を示す。

２． チェックプログラムの生成手順、及び、生成されるプログラムの変更
次に、実施例１の様式コンパイラ０１００２における、チェックプログラムの生成手順、及び、生成されるプログラムを次のように変更する。

実施例１の様式コンパイラ０１００２は、まず、既存の型、及び、様式に記述されたユーザ定義型を用いて、画面からの入力値のリストを引数にとり、入力値を型の定義と比較し、エラー判定結果を返却するチェックプログラムを定義された全ての型について生成する。チェックプログラムの処理内容は以下のようになる。

（１）当該型の定義をタプルの列挙を行、タプル内の要素を列とした２次元配列に格納する。
（２）行の数だけ繰り返す。行の添え字はｉとし、初期値は１とする。
（２．１）列の数だけ繰り返す。列の添え字はｊとし、初期値は１とする。
（２．１．１）ｉ番目の行のｊ番目の列がＮＵＬＬ記号の場合。
（２．１．１．１）入力値のｊ番目の値が空の場合。
（２．１．１．１．１）当該行を削除する。
（２．１．２）ｉ番目の行のｊ番目の列がテキスト値の場合。
（２．１．２．１）入力値のｊ番目の値を、当該テキスト値と比較する。
（２．１．２．１．１）比較した結果が同じ場合
（２．１．２．１．１．１）何もしない
（２．１．２．１．２）比較した結果が違う場合
（２．１．２．１．２．１）当該行を削除する。
（２．１．３）ｉ番目の行のｊ番目の列が正規表現型の場合。
（２．１．３．１）入力値のｊ番目の値が当該正規表現にマッチするか確認する。
（２．１．３．１．１）マッチする場合
（２．１．３．１．１．１）何もしない
（２．１．３．１．２）マッチしない場合
（２．１．３．１．２．１）当該行を削除する。
（２．１．４）ｊを１増やす。
（２．２）ｉを１増やす。
（３）２次元配列の行数を確認する。
（３．１）行数が０の場合
（３．１．１）ＮＧを返却する。
（３．２）行数が１以上の場合
（３．２．１）ＯＫを返却する。

なお、この処理内容は、列数ｊを１とすれば、１項目の列挙型についても問題なく動作する。

上記処理内容のフローチャートを図３６に示す。

３． 補完プログラムの生成手順、及び、生成される補完プログラムの変更
最後に、実施例１の様式コンパイラ０１００２における、補完プログラムの生成手順、及び、生成される補完プログラムを次のように変更する。

実施例１の様式コンパイラ０１００２は、まず、既存の型、及び、様式に記述されたユーザ定義型を用いて、画面からの入力値のリストを引数にとり、入力値を型の定義と比較し、補完値の２次元配列を返却する補完プログラムを定義された全ての型について生成する。補完プログラムの処理内容は以下のようになる。

（１）当該型の定義をタプルの列挙を行、タプル内の要素を列とした２次元配列に格納する。
（２）行の数だけ繰り返す。行の添え字はｉとし、初期値は１とする。
（２．１）列の数だけ繰り返す。列の添え字はｊとし、初期値は１とする。
（２．１．１）ｉ番目の行のｊ番目の列がＮＵＬＬ記号の場合。
（２．１．１．１）入力値のｊ番目の値が空の場合。
（２．１．１．１．１）当該行を削除する。
（２．１．２）ｉ番目の行のｊ番目の列がテキスト値の場合。
（２．１．２．１）入力値のｊ番目の値を、当該テキスト値と比較する。
（２．１．２．１．１）比較した結果が同じ場合
（２．１．２．１．１．１）何もしない
（２．１．２．１．２）比較した結果が違う場合
（２．１．２．１．２．１）当該行を削除する。
（２．１．３）ｉ番目の行のｊ番目の列が正規表現型の場合。
（２．１．３．１）入力値のｊ番目の値が当該正規表現にマッチするか確認する。
（２．１．３．１．１）マッチする場合
（２．１．３．１．１．１）何もしない
（２．１．３．１．２）マッチしない場合
（２．１．３．１．２．１）当該行を削除する。
（２．１．４）ｊを１増やす。
（２．２）ｉを１増やす。
（３）２次元配列を返却する。

この処理内容についても、列数ｊを１とすれば、１項目の列挙型についても問題なく動作する。

上記処理内容のフローチャートを図３７に示す。

実施例１、及び、実施例７を拡張し、複数項目にまたがるエラーチェックと同時に単項目のエラーチェックを行う方法を述べる。

本実施例を実現するために必要な構成要素は実施例１と同様である。また、使用する専用言語は実施例１に実施例７を適用したものと同様である。

実施例７において、複数項目のエラーチェックを行う方法を述べたが、実施例７の方法では、複数項目で定義した型について、単項目でのエラー判定を行うことができない。

このような課題を解決するために、単項目の型の定義についても、チェックプログラムを生成するようにする。例えば、型の定義が（型名１、型名２、型名３）：（（値１１、値１２、値１３），（値２１、値２２、値２３），…（値ｎ１、値ｎ２、値ｎ３））となっていた場合、型（型名１、型名２、型名３）だけでなく、型名１、型名２、型名３についても、チェックプログラムを生成する。

実施例１の様式コンパイラ０１００２が、複数項目にまたがる列挙型の定義から、チェックプログラムを生成する際、まず、複数項目にまたがる列挙型を単項目に分解する。これは、同一列の型名と列挙値だけの型定義を生成し、列挙値に同一の値があった場合は集約を行うことで、作成できる。

次に、既存の型、様式に記述されたユーザ定義型、及び、複数項目にまたがる列挙型を単項目に分解した型を用いて、画面からの入力値のリストを引数にとり、入力値を型の定義と比較し、エラー判定結果を返却するチェックプログラムを既存の型、様式に記述されたユーザ定義型、及び、複数項目にまたがる列挙型を単項目に分解した型の数だけ作成する。チェックプログラムの処理内容は実施例７と同様である。

実施例１の書類入力画面０１０２０は、エラーチェックプログラムの結果を画面に表示する際、単項目のチェック結果と、複数項目のチェック結果をそれぞれ表示したり、エラー結果をテキストボックスや文字の色を警告色にすることで示す場合に、複数項目のチェックでエラーとなっても、単項目のチェックでエラーとならなければ、テキストボックスや文字の色を警告色に変更しなかったりと、より利用者に分かりやすい形でエラーを表示できる。

実施例１、及び実施例７を拡張し、項目に入力可能な値、及び／又は、項目間の値の関係を外部データベースに保存することで、外部データベースの値を列挙値として利用することを可能とする方法を述べる。

１． システム構成の変更
実施例１の構成要素に加え、新たに外部データベース接続サーバ０９００１と、外部データベース接続インターフェース０９００２を用意する。

外部データベース接続インターフェース０９００２は、ＪＤＢＣやＯＤＢＣのような、データベース接続のインターフェース製品を用いて実現する。利用者は、あらかじめ利用する外部データベースを外部データベース接続インターフェース０９００２に登録しておく。

２． 専用言語の変更
また、様式記述言語の型定義部を次のように拡張する。

外部データベースを使った型の定義は以下のように行う。
一番単純な方法は、次のように列挙型の代わりに外部データベース参照０９００４を記述する方法である。
型名０９００３：外部データベース参照０９００４

列挙型の列挙値として外部データベース参照０９００４を記述することもできる。
型名０９００３：（外部データベース参照，列挙値１，…，列挙値ｎ）

また、複数項目にまたがった場合も、以下のように記述できる。
（型名０９００３１，…，型名０９００３Ｎ）：外部データベース参照０９００４
又は、
（型名０９００３１，…，型名０９００３Ｎ）：（外部データベース参照０９００４，（列挙値１１，…，列挙値１Ｎ），…，（列挙値ｎ１，…，列挙値ｎＮ））

さらに、タプルの一部として外部データベース参照０９００４を記述することもできる。
（型名０９００３１，型名０９００３２，…，型名０９００３Ｎ）：（（列挙値１１，列挙値２１，外部データベース参照０９００４），（列挙値１２，列挙値２２，外部データベース参照０９００４））

いずれの場合も、外部データベース参照０９００４は、
＠外部データベース（“接続文字列０９００５”，”検索クエリ０９００６”）
と記述する。

接続文字列０９００５は、ＪＤＢＣまたはＯＤＢＣの接続文字列とする。

検索クエリ０９００６は、ＳＱＬ文とする。
ＳＱＬ文のＳＥＬＥＣＴ句には“＊”（アスタリスク）は記述できないものとする。

また、ＳＱＬ文の中では型名変数０９００７が記述できる。
型名変数０９００７は、
＄型名
のように記述する。
型名変数０９００７は、ＳＱＬ実行前に、対応する型に対して実際に入力した値に置き換えられる。

なお、ＳＱＬの実行結果の列数（タプルの一部として記述した場合は、ＳＱＬの実行結果の列数と要素数の合計）は、型の要素数と同じである必要がある。

外部データベース参照０９００４は、接続文字列０９００５とＳＱＬ文を使って、外部データベース接続インターフェース０９００２経由で取得した値が代入されることを意味する。

例えば、都道府県名が格納された“都道府県マスタ”テーブルが外部データベースにあったとし、
都道府県：＠外部データベース（″ｊｄｂｃ：ｐｏｓｔｇｒｅｓｑｌ：ｈｅｌｌｏｄｂ″，″ＳＥＬＥＣＴ ｐｒｅｆｅｃｔｕｒｅｓ ＦＲＯＭ′都道府県マスタ′″）
のように記述すると、
都道府県：（“北海道”，”青森県”，…，”沖繩県”）
と記述した場合と同じになる。

ここで、“都道府県マスタ”にはない”全国“という値を列挙値として含めたければ、
都道府県：（“全国”，＠外部データベース（″ｊｄｂｃ：ｐｏｓｔｇｒｅｓｑｌ：ｈｅｌｌｏｄｂ″，″ＳＥＬＥＣＴ ｐｒｅｆｅｃｔｕｒｅｓ ＦＲＯＭ′都道府県マスタ′″））
のように記述する。

都道府県名と対応する市町村名が格納された“市町村マスタ”テーブルが外部データベースにあったとすると、
（都道府県，市町村）：＠外部データベース（″ｊｄｂｃ：ｐｏｓｔｇｒｅｓｑｌ：ｈｅｌｌｏｄｂ″，″ＳＥＬＥＣＴ ｐｒｅｆｅｃｔｕｒｅｓ，ｃｉｔｉｅｓ ＦＲＯＭ′市町村マスタ′″）
と記述し、
（都道府県，市町村）：（（“北海道”，”札幌市”），（“北海道”，”函館市”），…，（“沖縄県”，”那覇市”））
のようになる。

タプルの一部として記述する場合は、
（都道府県，市町村）：（（“北海道”，＠外部データベース（″ｊｄｂｃ：ｐｏｓｔｇｒｅｓｑｌ：ｈｅｌｌｏｄｂ″，″ＳＥＬＥＣＴ ｃｉｔｉｅｓ ＦＲＯＭ′市町村マスタ′ＷＨＥＲＥ ｐｒｅｆｅｃｔｕｒｅｓ＝‘北海道’″）），（“青森県”，＠外部データベース（″ｊｄｂｃ：ｐｏｓｔｇｒｅｓｑｌ：ｈｅｌｌｏｄｂ″，″ＳＥＬＥＣＴ ｃｉｔｉｅｓ ＦＲＯＭ′市町村マスタ′ＷＨＥＲＥ ｐｒｅｆｅｃｔｕｒｅｓ＝‘青森県’″）））
又は
（都道府県，市町村）：（（“北海道”，＠外部データベース（″ｊｄｂｃ：ｐｏｓｔｇｒｅｓｑｌ：ｈｅｌｌｏｄｂ″，″ＳＥＬＥＣＴ ｃｉｔｉｅｓ ＦＲＯＭ′市町村マスタ′ＷＨＥＲＥ ｐｒｅｆｅｃｔｕｒｅｓ＝‘＄都道府県’）），（“青森県”，＠外部データベース（″ｊｄｂｃ：ｐｏｓｔｇｒｅｓｑｌ：ｈｅｌｌｏｄｂ″，″ＳＥＬＥＣＴ ｃｉｔｉｅｓ ＦＲＯＭ′市町村マスタ′ＷＨＥＲＥ ｐｒｅｆｅｃｔｕｒｅｓ＝‘＄都道府県’″）））
のように記述できる。

型名変数０９００７は、タプルの要素に記述する列挙値に、正規表現型を用いた場合に効果的である。
テキスト：［“．＋”］
（都道府県，市町村）：（（テキスト，＠外部データベース（″ｊｄｂｃ：ｐｏｓｔｇｒｅｓｑｌ：ｈｅｌｌｏｄｂ″，″ＳＥＬＥＣＴ ｃｉｔｉｅｓ ＦＲＯＭ′市町村マスタ′ＷＨＥＲＥ ｐｒｅｆｅｃｔｕｒｅｓ＝‘＄都道府県’″）））
このように記述すれば、都道府県を任意のテキスト入力とし、実際に入力された値で、市町村を取得できる。

３． チェックプログラムの生成手順、及び、生成されるプログラムの変更
実施例１の様式コンパイラ０１００２における、チェックプログラムの生成手順、及び、生成されるプログラムを次のように変更する。

実施例１の様式コンパイラ０１００２は、まず、既存の型、及び、様式に記述されたユーザ定義型を用いて、画面からの入力値のリストを引数にとり、入力値を型の定義と比較し、エラー判定結果を返却するチェックプログラムを定義された全ての型について生成する。チェックプログラムの処理内容は以下のようになる。

（１）当該型の定義をタプルの列挙を行、タプル内の要素を列とした２次元配列に格納する。
（２）行の数だけ繰り返す。行の添え字はｉとし、初期値は１とする。
（２．１）ｉ番目の行が外部データベース参照でない場合。
（２．１．１）列の数だけ繰り返す。列の添え字はｊとし、初期値は１とする。
（２．１．１．１）ｉ番目の行のｊ番目の列がＮＵＬＬ記号の場合。
（２．１．１．１．１）入力値のｊ番目の値が空の場合。
（２．１．１．１．１．１）当該行を削除する。
（２．１．１．１．２）ｊを１増やす。
（２．１．１．２）ｉ番目の行のｊ番目の列がテキスト値の場合。
（２．１．１．２．１）入力値のｊ番目の値を、当該テキスト値と比較する。
（２．１．１．２．１．１）比較した結果が同じ場合
（２．１．１．２．１．１．１）何もしない
（２．１．１．２．１．２）比較した結果が違う場合
（２．１．１．２．１．２．１）当該行を削除する。
（２．１．１．２．２）ｊを１増やす。
（２．１．１．３）ｉ番目の行のｊ番目の列が正規表現型の場合。
（２．１．１．３．１）入力値のｊ番目の値が当該正規表現にマッチするか確認する。
（２．１．１．３．１．１）マッチする場合
（２．１．１．３．１．１．１）何もしない
（２．１．１．３．１．２）マッチしない場合
（２．１．１．３．１．２．１）当該行を削除する。
（２．１．１．３．２）ｊを１増やす。
（２．１．１．４）ｉ番目の行のｊ番目の列が外部データベース参照の場合。
（２．１．１．４．１）外部データベース参照のＳＱＬ中に変数＄型名がある場合
（２．１．１．４．１．１）＄型名を入力値に置き換える。
（２．１．１．４．２）ＳＱＬのＷＨＥＲＥ句にＡＮＤ条件で対応する列と入力値のイコール条件を追加する。
（２．１．１．４．３）ＳＱＬの実行結果を得る。
（２．１．１．４．４）実行結果の行数を確認する。
（２．１．１．４．４．１）ＳＱＬの結果が１件以上の場合。
（２．１．１．４．４．１．１）何もしない
（２．１．１．４．４．２）ＳＱＬの結果が０件の場合。
（２．１．１．４．４．２．１）当該行を削除する。
（２．１．１．４．５）ｊをＳＱＬの実行結果の列数分増やす。
（２．２）ｉ番目の行が外部データベース参照の場合。
（２．２．１）ＳＱＬのＷＨＥＲＥ句にＡＮＤ条件で対応する列と入力値のイコール条件を追加する。
（２．２．２）ＳＱＬの実行結果を得る。
（２．２．３）実行結果の行数を確認する。
（２．２．３．１）ＳＱＬの結果が１件以上の場合。
（２．２．３．１．１）何もしない
（２．２．３．２）ＳＱＬの結果が０件の場合。
（２．２．３．２．１）当該行を削除する。
（２．２．４）ｊをＳＱＬの実行結果の列数分増やす。
（２．３）ｉを１増やす。
（３）２次元配列の行数を確認する。
（３．１）行数が０の場合
（３．１．１）ＮＧを返却する。
（３．２）行数が１以上の場合
（３．２．１）ＯＫを返却する。

なお、ＳＱＬの実行結果は、エラーの判定は１件以上あれば判断できるので、上限値を設けてもよい。

上記処理内容のフローチャートを図３８、３９に示す。

４． 補完プログラムの生成手順、及び、生成される補完プログラムの変更
実施例１の様式コンパイラ０１００２における、補完プログラムの生成手順、及び、生成される補完プログラムを次のように変更する。
実施例１の様式コンパイラ０１００２は、まず、既存の型、及び、様式に記述されたユーザ定義型を用いて、画面からの入力値のリストを引数にとり、入力値を型の定義と比較し、補完値の２次元配列を返却する補完プログラムを定義された全ての型について生成する。補完プログラムの処理内容は以下のようになる。

（１）当該型の定義をタプルの列挙を行、タプル内の要素を列とした２次元配列に格納する。
（２）行の数だけ繰り返す。行の添え字はｉとし、初期値は１とする。
（２．１）ｉ番目の行が外部データベース参照でない場合。
（２．１．１）列の数だけ繰り返す。列の添え字はｊとし、初期値は１とする。
（２．１．１．１）ｉ番目の行のｊ番目の列がＮＵＬＬ記号の場合。
（２．１．１．１．１）入力値のｊ番目の値が空の場合。
（２．１．１．１．１．１）当該行を削除する。
（２．１．１．１．２）ｊを１増やす。
（２．１．１．２）ｉ番目の行のｊ番目の列がテキスト値の場合。
（２．１．１．２．１）入力値のｊ番目の値を、当該テキスト値と比較する。
（２．１．１．２．１．１）比較した結果が同じ場合
（２．１．１．２．１．１．１）何もしない
（２．１．１．２．１．２）比較した結果が違う場合
（２．１．１．２．１．２．１）当該行を削除する。
（２．１．１．２．２）ｊを１増やす。
（２．１．１．３）ｉ番目の行のｊ番目の列が正規表現型の場合。
（２．１．１．３．１）入力値のｊ番目の値が当該正規表現にマッチするか確認する。
（２．１．１．３．１．１）マッチする場合
（２．１．１．３．１．１．１）何もしない
（２．１．１．３．１．２）マッチしない場合
（２．１．１．３．１．２．１）当該行を削除する。
（２．１．１．３．２）ｊを１増やす。
（２．１．１．４）ｉ番目の行のｊ番目の列が外部データベース参照の場合。
（２．１．１．４．１）外部データベース参照のＳＱＬ中に変数＄型名がある場合
（２．１．１．４．１．１）＄型名を入力値に置き換える。
（２．１．１．４．２）ＳＱＬのＷＨＥＲＥ句にＡＮＤ条件で対応する列と入力値のイコール条件を追加する。
（２．１．１．４．３）ＳＱＬの実行結果を得る。
（２．１．１．４．４）実行結果の行数を確認する。
（２．１．１．４．４．１）ＳＱＬの結果が１件以上の場合。
（２．１．１．４．４．１．１）当該行の内容を実行結果の行数−１行複製し追加する
（２．１．１．４．４．１．２）元の行と複製した行の数だけ繰り返す。添え字はｋとし、初期値は１とする。
（２．１．１．４．４．１．２．１）２次元配列のｋ＋ｉ行目のＳＱＬ文の書かれた列を実行結果のｋ行目の内容で置き換える。
（２．１．１．４．４．１．３）ｉをｋの数だけ増やす。
（２．１．１．４．４．２）ＳＱＬの結果が０件の場合。
（２．１．１．４．４．２．１）当該行を削除する。
（２．１．１．４．５）ｊをＳＱＬの実行結果の列数分増やす。
（２．２）ｉ番目の行が外部データベース参照の場合。
（２．２．１）ＳＱＬのＷＨＥＲＥ句にＡＮＤ条件で対応する列と入力値のイコール条件を追加する。
（２．２．２）ＳＱＬの実行結果を得る。
（２．２．３）実行結果の行数を確認する。
（２．２．３．１）ＳＱＬの結果が１件以上の場合。
（２．２．３．１．１）当該行の内容を実行結果の行数−１行複製し追加する
（２．２．３．１．１．２）元の行と複製した行の数だけ繰り返す。添え字はｌとし、初期値は１とする。
（２．２．３．１．１．２．１）２次元配列のｌ＋ｉ行目のＳＱＬ文の書かれた列を実行結果のｌ行目の内容で置き換える。
（２．２．３．１．１．３）ｉをｌの数だけ数増やす。
（２．２．３．２）ＳＱＬの結果が０件の場合。
（２．２．３．２．１）当該行を削除する。
（２．２．４）ｊをＳＱＬの実行結果の列数分増やす。
（２．３）ｉを１増やす。
（３）２次元配列を返却する。

なお、ＳＱＬの実行結果は、ハードウェアの処理能力メモリサイズを考慮し、実際に画面に表示できる件数を下回らない範囲で、上限値を設けてもよい。

上記処理内容のフローチャートを図４０、４１、４２、４３に示す。

実施例１の入力画面生成方法を拡張し、ラベル、ラジオボタン、チェックボックス、セレクトボックス、及び、コンボボックスを列挙数や列挙値の内容から判断して、生成する方法を述べる。

書類承認画面０１０２１は、書類を表示する際、型の定義を参照し、書類をＨＴＭＬに変換するルールを次のようにする。

型が列挙型で、列挙数が１の場合、これは、利用者は値の選択の余地がないため、ラベルとなる。インプット要素ではなくスパン要素として表示する。

型が列挙型で、列挙値にＮＵＬＬ記号も、正規表現型もない場合、これは、複数の選択値から一つを必ず選ぶことになるため、ラジオボタンか、セレクトボックスとなる。列挙数に閾値を設けるか、レンダリング後の幅を計算し、その幅に閾値を設けるかして、ラジオボタンにするか、セレクトボックスにするか決定する。

型が列挙型で、正規表現型を含む場合、ラジオボタンを列挙数分並べ、さらに、その他を意味するラジオボタンを設け、その他を入力するテキストボックスを作成するか、コンボボックスとする。ラジオボタンにするか、コンボボックスにするかは、同様に閾値を設けて決定する。

型が列挙型で、ＮＵＬＬ記号を含む場合、選択数１のチェックボックスにするか、選択値に“選択しない“を含むセレクトボックスに変換する。チェックボックスにするか、セレクトボックスにするかは、同様に閾値を設けて決定する。

型がＮＵＬＬ記号とテキスト値の２値の列挙型の場合、チェックボックスに変換する。

型がスペースで区切った複数の型で構成され、それぞれの型がＮＵＬＬ記号とテキスト値の２値の列挙型の場合、複数選択可能なチェックボックスに変換する。

実施例１、実施例４、及び、実施例７を拡張し、型に数値範囲の制限を加える方法を説明する。
本実施例を実現するために必要な構成要素は実施例１と同様である。

１． 専用言語の拡張
まず、型を定義する専用言語に、型に制限を加える新しい文法を加える。

型名１１００１：型の定義１１００２ 型の制限１１００３

型名１１００１、及び、型の定義１１００２の意味は、実施例４と同じであるが、型の定義１１００２は正規表現型で、数値に変換可能である必要がある。

型の制限１１００３は以下のように記述する。
＠値域（式１１００４，…，式１１００４）

式１１００４には比較演算子“＞”、“＜”、“＞＝”、“＜＝”及び“＝”が記述でき、比較演算子の右辺と左辺に、変数１１００５と数値が記述できる。

変数１１００５は、型に対して実際に入力された値が代入される。
以下のように記述する。
＄型名

例えば、
年齢：［“￥ｄ＋”］＠値域（＄年齢＞＝０，＄＜１５０）
のように記述すれば、０以上、１４９以下の数値となる。

２． チェックプログラムの生成手順、及び、生成されるプログラムの変更

次に、実施例１の様式コンパイラ０１００２における、チェックプログラムの生成手順、及び、生成されるプログラムを次のように変更する。

実施例１の様式コンパイラ０１００２は、まず、既存の型、及び、様式に記述されたユーザ定義型を用いて、画面からの入力値のリストを引数にとり、入力値を型の定義と比較し、エラー判定結果を返却するチェックプログラムを定義された全ての型について生成する。チェックプログラムの処理内容は以下のようになる。

（１）当該型の定義をタプルの列挙を行、タプル内の要素を列とした２次元配列に格納する。
（２）行の数だけ繰り返す。行の添え字はｉとし、初期値は１とする。
（２．１）列の数だけ繰り返す。列の添え字はｊとし、初期値は１とする。
（２．１．１）ｉ番目の行のｊ番目の列がＮＵＬＬ記号の場合。
（２．１．１．１）入力値のｊ番目の値が空の場合。
（２．１．１．１．１）当該行を削除する。
（２．１．２）ｉ番目の行のｊ番目の列がテキスト値の場合。
（２．１．２．１）入力値のｊ番目の値を、当該テキスト値と比較する。
（２．１．２．１．１）比較した結果が同じ場合
（２．１．２．１．１．１）何もしない
（２．１．２．１．２）比較した結果が違う場合
（２．１．２．１．２．１）当該行を削除する。
（２．１．３）ｉ番目の行のｊ番目の列が正規表現型の場合。
（２．１．３．１）入力値のｊ番目の値が当該正規表現にマッチするか確認する。
（２．１．３．１．１）マッチする場合。
（２．１．３．１．１．１）数値に変換する。
（２．１．３．１．１．１．１）数値に変換できなかった場合。
（２．１．３．１．１．１．１．１）しない。
（２．１．３．１．１．１．２）数値に変換できた場合。
（２．１．３．１．１．１．２．１）値域の定義があれば、範囲内であるか確認する。
（２．１．３．１．１．１．２．１．１）範囲内である。
（２．１．３．１．１．１．２．１．１．１）何もしない。
（２．１．３．１．１．１．２．１．２）範囲外。
（２．１．３．１．１．１．２．１．２．１）当該行を削除する。
（２．１．３．１．２）マッチしない場合
（２．１．３．１．２．１）当該行を削除する。
（２．１．４）ｊを１増やす。
（２．２）ｉを１増やす。
（３）２次元配列の行数を確認する。
（３．１）行数が０の場合
（３．１．１）ＮＧを返却する。
（３．２）行数が１以上の場合
（３．２．１）ＯＫを返却する。

上記処理内容のフローチャートを図４４、４５に示す。

実施例１にて、組織を横断する承認経路を求める方法の詳細を述べる。

様式に、承認経路の定義として、スタッフ部門承認が記述されていた場合、当該部門の承認の前に、指定したスタッフ部門の承認が必要となる。

実施例１の承認経路生成部行われる処理を以下のように変更する。

（１）経路中間情報から起案したユーザが所属する部門を特定する
（２）起案したユーザが所属する部門が起案可能である場合
（２．１）承認経路リストに当該部門を追加する
（２．２）組織階層情報から様式の所有者が所属する部門を特定する
（２．３）起案したユーザが所属する部門から、所有者が所属する部門まで繰り返す
（２．３．１）上位の部門を特定する
（２．３．２）特定した部門が承認不要でない場合
（２．３．２．１）特定した部門がスタッフ部門承認要の場合
（２．３．２．１．１）担当スタッフ部門と対象スタッフ部門を特定する
（２．３．２．１．２）承認経路リストに担当スタッフ部門を追加する
（２．３．２．１．３）担当スタッフ部門から対象スタッフ部門まで繰り返す
（２．３．２．１．３．１）上位の部門を特定する
（２．３．２．１．３．２）特定した部門が承認不要でない場合
（２．３．２．１．３．２．１）承認経路リストに当該部門を追加する
（２．３．２．２）承認経路リストに当該部門を追加する
（３）起案したユーザが所属する部門が起案可能でない場合
（３．１）エラーを返却する
（４）作成した承認経路リストをＸＭＬの承認経路要素Ｘ９０１に変換する

上記処理内容のフローチャートを図４６に示す。

実施例１、実施例２、及び 実施例６を拡張し、書類の所有者が権限を変更できるようにする方法を説明する。本発明では、書類に関する権限を変更する権限を持つユーザを所有者と呼ぶ。

実施例１の構成要素に加え、アプリケーションサーバ０１０１６に、権限変更部１３０１２を、ＷＥＢサーバ０１０２３に権限変更画面１３００１を用意する。（図４７）

１． 専用言語の拡張
まず、組織情報及び様式の権限の定義を記述する専用言語を次のように変更する。なお、文法に変更がない場合も、説明を省略せずに記述する。

権限の定義には、承認権限の定義１３００２、所有時の権限定義１３００３、所有時の変更権限定義１３００４、最終決裁後の権限定義１３００５、最終決裁後の変更権限定義１３００６がそれぞれ０回以上記述できる。
ｐｅｒｍｉｓｓｉｏｎ｛
承認権限の定義１３００２
所有時の権限定義１３００３
所有時の変更権限定義１３００４
最終決裁後の権限定義１３００５
最終決裁後の変更権限定義１３００６
｝

承認権限の定義１３００２は、承認時に実行可能な操作を記述する。
ａｐｐｒｏｖａｌ−ｐｅｒｍｉｓｓｉｏｎ：（承認操作０２０１６，…，承認操作０２０１６），所有者の種類０２０１７

承認操作０２０１６は、キーワード “ｆｏｒｗａｒｄ”、“ｒｅｊｅｃｔ”、“ｒｅｔｕｒｎ”、“ｓｋｉｐ”、“ｇｅｔｂａｃｋ”のいずれかが記述できる。“ｆｏｒｗａｒｄ”は提出、承認、又は決裁を、“ｒｅｊｅｃｔ”は却下を、“ｒｅｔｕｒｎ”は差戻しを、“ｓｋｉｐ”は飛ばし承認（強制承認）、又は、飛ばし決裁（強制決裁）を、“ｇｅｔｂａｃｋ”は取戻しを意味する。

所有時の権限定義１３００３は、書類の所有者の権限を記述する。
ｏｗｎｅｒ−ｐｅｒｍｉｓｓｉｏｎ：（権限０２０１８，…，権限０２０１８），所有者の種類０２０１７，対象部門０２０２０，対象ユーザ０２０２１

権限０２０１８は、キーワード“ｒｅａｄ”、“ｗｒｉｔｅ”、“ｄｅｌｅｔｅ”、“ａｐｐｒｏｖａｌ”が記述できる。“ｒｅａｄ”は参照権限を、“ｗｒｉｔｅ”は変更権限を、“ｄｅｌｅｔｅ”は削除権限を、“ａｐｐｒｏｖａｌ”は承認権限を意味する。承認操作０２０１６は、“ａｐｐｒｏｖａｌ”が記述されている場合のみ有効である。

所有者の種類０２０１７は、キーワード“ｃｒｅａｔｏｒ”、“ａｐｐｒｏｖｅｒ”、“ｌａｓｔ−ａｐｐｒｏｖｅｒ”を記述できる。“ｃｒｅａｔｏｒ”は書類の作成者を、“ａｐｐｒｏｖｅｒ”は承認者を、“ｌａｓｔ−ａｐｐｒｏｖｅｒ”は最終決裁者を意味する。

対象部門０２０２０は、書類の所有者を軸に相対的に部門の範囲を指定する。対象部門０２０２０は、キーワード“ａｌｌ”、“ｓｅｌｆ”、“ｐａｒｅｎｔ”、“ｃｈｉｌｄ”、“ｂｒｏｔｈｅｒ”、“ａｎｃｅｓｔｏｒ”、“ｄｅｓｃｅｎｄａｎｔ”を記述できる。“ａｌｌ”は全部門を、“ｓｅｌｆ”は所有者の所属部門を、“ｐａｒｅｎｔ”は所有者の所属部門の一つ上位の部門を、“ｃｈｉｌｄ”は所有者の所属部門の一つ下位の部門すべてを、“ｂｒｏｔｈｅｒ”は所有者の所属部門と上位部門を同じとする同会層の部門を、“ａｎｃｅｓｔｏｒ”は所有者の所属部門の上位全ての部門を、“ｄｅｓｃｅｎｄａｎｔ”は所有者の所属部門の下位全ての部門を意味する。

対象ユーザ０２０２１は、対象部門０２０２０で指定した部門において、部門に所属するユーザの種類を指定する。対象ユーザ０２０２１は、キーワード“ｓｅｌｆ”、“ｈｅａｄ”、“ｍｅｍｂｅｒ”、“ａｌｌ”を記述できる。“ｓｅｌｆ”は所有者自信を、“ｈｅａｄ”は部門の長を、“ｍｅｍｂｅｒ”は部門に所属するメンバーを、“ａｌｌ”は長とメンバー両方を意味する。

例えば、書類の作成者自身に参照権限、変更権限、削除権限及び、承認権限を付与する場合は、以下のように記述する。
ｏｗｎｅｒ−ｐｅｒｍｉｓｓｉｏｎ：（ｒｅａｄ，ｗｒｉｔｅ．ｄｅｌｅｔｅ，ａｐｐｒｏｖａｌ），ｃｒｅａｔｅｒ，ｓｅｌｆ，ｓｅｌｆ
作成者の所属する部門の他のメンバーに参照権限を付与する場合は、以下のように記述すればよい。
ｏｗｎｅｒ−ｐｅｒｍｉｓｓｏｎ：（ｒｅａｄ），ｃｒｅａｔｅｒ，ｓｅｌｆ，ｍｅｍｂｅｒ

所有時の権限は、自身が所有者でなくなった時に、権限が無効になる。これは、付与された所有者以外のユーザも同じである。

所有時の変更権限定義１３００４は、自身が書類の所有者の時に、所有者が他のユーザに付与できる権限を記述する。
ｏｗｎｅｒ−ｃｈａｎｇｅｍｏｄｅ−ｐｅｒｍｉｓｓｉｏｎ：（権限０２０１８，…，権限０２０１８），所有者の種類０２０１７

例えば、
ｏｗｎｅｒ−ｃｈａｎｇｅｍｏｄｅ−ｐｅｒｍｉｓｓｉｏｎ：（ｒｅａｄ，ｗｒｉｔｅ，ａｐｐｒｏｖａｌ），ｃｒｅａｔｏｒ
と記述すれば、書類の作成者が所有者の時、別のユーザに、書類の参照権限、変更権限、提出権限を付与する権限が与えられる。後述する権限変更画面を利用することで、書類の代理作成を実現することが出来る。

最終決裁後の権限定義１３００５は、最終決裁後の書類の権限を記述する。
ａｐｐｒｏｖｅｄ−ｐｅｒｍｉｓｓｉｏｎ：（権限０２０１９，…，権限０２０１９），所有者の種類０２０１７，対象部門０２０２０，対象ユーザ０２０２１
権限０２０１９は、キーワード“ｒｅａｄ”、“ｗｒｉｔｅ”、“ｄｅｌｅｔｅ”が記述できる。“ｒｅａｄ”は参照権限を、“ｗｒｉｔｅ”は変更権限を、“ｄｅｌｅｔｅ”は削除権限を意味する。

最終決裁後の変更権限定義１３００６は、最終決裁後に、所有者が他のユーザに付与できる権限を記述する。
ａｐｐｒｏｖｅｄ−ｃｈａｎｇｅｍｏｄｅ−ｐｅｒｍｉｓｓｉｏｎ：（権限０２０１９，…，権限０２０１９），所有者の種類０２０１７

例えば、
ａｐｐｒｏｖｅｄ−ｃｈａｎｇｅｍｏｄｅ−ｐｅｒｍｉｓｓｉｏｎ：ｒｅａｄ，ｌａｓｔ− ａｐｐｒｏｖｅｒ
と記述した場合、書類が最終決裁された後に、最終承認者によって、参照権限を他のユーザに付与できることを意味する。

２． 書類の作成処理の変更
次に、実施例１の「２−３−３．書類の作成」で説明した書類の作成の処理を次のように変更する。

２−１．様式からＸＭＬ形式の書類の作成
書類の作成者は、一覧から作成したい様式を選択し、書類の作成を実行する。作成を実行すると、様式選択画面は、書類起案部０１０１０に、ユーザＩＤと様式の識別子を送信する。書類起案部０１０１０は、様式検索部０１０５４に様式の識別子を送信し、当該様式を取得する。書類起案部０１０１０は、次の処理を行い、様式からＸＭＬ形式の書類を作成する。

（１）ルート要素である書類要素０１０５５を作成する。
（２）書類の識別子を発行し、書類要素０１０５５のＩＤ属性０１０５６に記述する。
（３）書類要素０１０５５の下位に様式の識別子を内容とした様式ＩＤ要素０１０５７を作成する。
（４）書類要素０１０５５の下位に様式の所有者の部門ＩＤを内容とした様式所有者要素０１０５８を作成する。
（５）書類要素０１０５５の下位に承認経路要素０１０５９を作成する。
（６）書類要素０１０５５の下位に書面要素０１０６０を作成する。
（７）承認経路要素０１０５９の下位に承認経路の設定を作成する。承認経路の設定については後述する。
（８）様式の項目名と型名の定義の数だけ繰り返す。
（８．１）項目名を要素名とした項目要素０１０６１を作成する。
（８．２）型名を項目要素０１０６１の型属性０１０８９に記述する。

上記処理内容のフローチャートを図４８に示す。

２−２．承認経路の設定の作成
承認経路の設定は以下の処理で作成する。

まず、組織情報参照部０１００４から組織情報を取得し、組織情報の省略値を補完し、組織階層情報に様式の承認経路の定義、及び、権限の定義を反映した中間情報１３０１３を作成する。

（１）すべての部門を対象に処理を行う。
（１．１）権限の定義が記述されていなければ、上位の部門の権限の定義を、コピーする。
（１）承認経路の定義に記述された定義の数だけ繰り返す。
（１．１）承認経路の定義に承認不要部門が記述されていた場合
（１．１．１）組織階層情報の対象部門に承認不要０１０６３を追加する
（１．２）承認経路の定義にスタッフ部門承認が記述されていた場合
（１．２．１）組織階層情報の対象部門にスタッフ部門承認要０１０６４を追加する
（２）権限の定義に記述された定義の数だけ繰り返す。
（２．１）すべての部門を対象に処理を行う。
（２．１．１）権限の定義に承認権限の定義が記述されていた場合
（２．１．１．１）組織階層情報の承認権限の定義０１０６５を変更する。
（２．１．２）権限の定義に所有時権限の定義が記述されていた場合
（２．１．２．１）組織階層情報の所有時権限の定義０１０６６を変更する。
（２．１．３）権限の定義に所有時変更権限の定義が記述されていた場合
（２．１．３．１）組織階層情報の所有時変更権限の定義１３００７を変更する。
（２．１．４）権限の定義に決裁後権限の定義が記述されていた場合
（２．１．４．１）組織階層情報の決裁後権限の定義０１０６７を変更する。
（２．１．５）権限の定義に決裁後変更権限の定義が記述されていた場合
（２．１．５．１）組織階層情報の決裁後変更権限の定義１３００８を変更する。

上記処理内容のフローチャートを図４９に示す。

また、図５０は、「組織階層情報に様式の承認経路の定義、及び、権限の定義を反映した中間情報１３０１３」の例である。

次に、組織階層情報に承認経路の定義を反映した中間情報から承認経路１３００９を作成する。

（１）組織階層情報から書類の作成者が所属する部門を特定する。
（２）承認経路に作成者だけを残した当該部門を追加する。
（３）承認経路にメンバーを削除し長だけにした当該部門を追加する。
（４）上位の部門を特定する。
（４．１）特定した部門が様式の所有者が所属する部門でない場合。
（４．１．１）特定した部門に承認不要０１０６３が追加されていない場合。
（４．１．１．１）承認経路にメンバーを削除し長だけにした当該部門を追加する。
（４．１．２）処理（４）へ戻る。
（４．２）特定した部門が様式の所有者が所属する部門である場合。
（４．２．１）承認経路１３００９にメンバーを削除し長だけにした当該部門を追加し、処理を終了する。

上記処理内容のフローチャートを図５１に示す。

次に、承認経路１３００９をＸＭＬに変換し、書類の承認経路要素０１０５９の下位に追加する。ＸＭＬへの変換ルールは以下となる。

（１）承認経路１３００９の部門の数だけ繰り返す。
（１．１）ひとつ目の時
（１．１．１）起案者要素０１０６９を作成する。
（１．１．２）起案者要素０１０６９の下位に予定者要素０１０７０を作成する。
（１．１．３）予定者要素０１０７０の下位に、作成者の部門名を内容に、部門の識別子をＩＤ属性とした、部門要素０１０７１を作成する。
（１．１．４）予定者要素０１０７０の下位に、作成者のユーザ名を内容に、ユーザの識別子をＩＤ属性とした、ユーザ要素０１０７２を作成する。
（１．１．５）起案者要素０１０６９の下位に、実施者要素０１０７３を作成する。実施者要素０１０７３の内容は空とする。
（１．１．６）起案者要素０１０６９の下位に、権限要素０１０７４を作成する。
（１．１．７）対象が作成者になっている承認権限の定義０１０６５から、承認権限要素０１０７５を作成し、権限要素０１０７４の下位に追加する。
（１．１．８）対象が作成者になっている所有時権限の定義０１０６６から、所有時権限要素０１０７６を作成し、権限要素０１０７４の下位に追加する。
（１．１．９）対象が作成者になっている所有時変更権限の定義１３００７から、所有時変更権限要素１３０１０を作成し、権限要素０１０７４の下位に追加する。
（１．１．１０）対象が作成者になっている決裁後権限の定義０１０６７から、決裁後権限要素０１０７７を作成し、権限要素０１０７４の下位に追加する。
（１．１．１１）対象が作成者になっている決裁後変更権限の定義１３００８から、決裁後変更権限要素１３０１１を作成し、権限要素０１０７４の下位に追加する。
（１．２）ひとつ目でも最後でもない時
（１．２．１）承認者要素０１０７８を作成する。
（１．２．２）承認者要素０１０７８の下位に予定者要素０１０７０を作成する。
（１．２．３）予定者要素０１０７０の下位に、承認者の部門名を内容に、部門の識別子をＩＤ属性とした、部門要素０１０７１を作成する。
（１．２．４）予定者要素０１０７０の下位に、承認者のユーザ名を内容に、ユーザの識別子をＩＤ属性とした、ユーザ要素０１０７２を作成する。
（１．２．５）承認者要素０１０７８の下位に、実施者要素０１０７３を作成する。実施者要素０１０７３の内容は空とする。
（１．２．６）承認者要素０１０７８の下位に、権限要素０１０７４を作成する。
（１．２．７）対象が承認者になっている承認権限の定義０１０６５から、承認権限要素０１０７５を作成し、権限要素０１０７４の下位に追加する。
（１．２．８）対象が承認者になっている所有時権限の定義０１０６６から、所有時権限要素０１０７６を作成し、権限要素０１０７４の下位に追加する。
（１．２．９）対象が承認者になっている所有時変更権限の定義１３００７から、所有時変更権限要素１３０１０を作成し、権限要素０１０７４の下位に追加する。
（１．２．１０）対象が承認者になっている決裁後権限の定義０１０６７から、決裁後権限要素０１０７７を作成し、権限要素０１０７４の下位に追加する。
（１．２．１１）対象が承認者になっている決裁後変更権限の定義１３００８から、決裁後変更権限要素１３０１１を作成し、権限要素０１０７４の下位に追加する。
（１．３）最後の時
（１．２．１）最終決裁者要素０１０７９を作成する。
（１．２．２）最終決裁者要素０１０７９の下位に予定者要素０１０７０を作成する。
（１．２．３）予定者要素０１０７０の下位に、最終決裁者の部門名を内容に、部門の識別子をＩＤ属性とした、部門要素０１０７１を作成する。
（１．２．４）予定者要素０１０７０の下位に、最終決裁者のユーザ名を内容に、ユーザの識別子をＩＤ属性とした、ユーザ要素０１０７２を作成する。
（１．２．５）最終決裁者要素０１０７９の下位に、実施者要素０１０７３を作成する。実施者要素０１０７３の内容は空とする。
（１．２．６）最終決裁者要素０１０７９の下位に、権限要素０１０７４を作成する。
（１．２．７）対象が最終決裁者になっている承認権限の定義０１０６５から、承認権限要素０１０７５を作成し、権限要素０１０７４の下位に追加する。
（１．２．８）対象が最終決裁者になっている所有時権限の定義０１０６６から、所有時権限要素０１０７６を作成し、権限要素０１０７４の下位に追加する。
（１．２．９）対象が最終決裁者になっている所有時変更権限の定義１３００７から、所有時変更権限要素１３０１０を作成し、権限要素０１０７４の下位に追加する。
（１．２．１０）対象が最終決裁者になっている決裁後権限の定義０１０６７から、決裁後権限要素０１０７７を作成し、権限要素０１０７４の下位に追加する。
（１．２．１１）対象が最終決裁者になっている決裁後変更権限の定義１３００８から、決裁後変更権限要素１３０１１を作成し、権限要素０１０７４の下位に追加する。

上記処理内容のフローチャートを図５２、５３に示す。
また、承認経路要素を追加したＸＭＬ形式の書類の例を図５４に示す。

書類起案部０１０１０は、書類を保存するサーバ０１０１７に、以上の手順によって作成したＸＭＬ形式の書類を送信し、正常に終了した場合は作成した書類の識別子を様式選択画面０１０１８に返す。

３． 権限の変更処理
書類の権限の変更を行う際の処理手順について説明する。ここでいう権限の変更とは、「１．専用言語の定義」において説明した権限の定義を変更することをいう。

３−１．対象書類の検索
利用者が書類の権限の変更をする場合は、書類検索画面０１０１９から自身が所有者で権限の変更権限を付与されている書類の検索を行う。
書類の承認経路要素に対する具体的な検索条件は、以下のとおりである。

・起案者要素の予定者要素に、自身のユーザＩＤが存在し、起案者要素の実施者要素が空であり、起案者要素の所有時変更権限要素に値がある。
又は、
・承認者要素の予定者要素に、自身のユーザＩＤが存在し、承認者要素の実施者要素が空であり、当該承認者要素の所有時変更権限要素に値があり、当該承認者要素の一つ前の起案者要素か、承認者要素の実施者要素に値がある。
又は、
・実施者要素がすべて値を持ち、自身のユーザＩＤがいずれかの実施者要素に存在し、自身のユーザＩＤが存在した、実施者要素の親の、起案者要素か、承認者要素か、最終決裁者要素の決裁後変更権限に値がある。

上記検索条件は、作成されているが未提出の書類の作成者であるか、次の承認を行うべき承認者であるか、最終決裁後に変更権限を有するように設定された者であるかを書類の内容に基づいて照合するものである。

書類検索画面０１０１９は、検索条件を書類検索部０１０１３へ送信する。書類検索部０１０１３は、書類の承認経路要素に対して検索を実行し、該当書類を特定する。書類検索部０１０１３は該当書類の一覧を、書類検索画面０１０１９へ返す。書類検索画面０１０１９は該当書類の一覧を表示する。

３−２．書類の表示
利用者が、該当書類の一覧から権限変更対象の書類を選択すると、権限変更画面１３００１が表示される。このとき書類検索画面０１０１９からは書類の識別子が渡される。権限変更画面１３００１は書類参照部０１０１４へユーザＩＤと書類の識別子を渡す。書類参照部０１０１４は、書類を保存するサーバ０１０１７から、書類の識別子で特定される書類を取得する。書類参照部０１０１４は、検索を行った時と同じ条件で権限の変更が可能か確認する。条件は以下のとおりである。

・起案者要素の予定者要素に、自身のユーザＩＤが存在し、起案者要素の実施者要素が空であり、起案者要素の所有時変更権限要素に値がある。
又は、
・承認者要素の予定者要素に、自身のユーザＩＤが存在し、承認者要素の実施者要素が空であり、当該承認者要素の所有時変更権限要素に値があり、当該承認者要素の一つ前の起案者要素か、承認者要素の実施者要素に値がある。
又は、
・実施者要素がすべて値を持ち、自身のユーザＩＤがいずれかの実施者要素に存在し、自身のユーザＩＤが存在した、実施者要素の親の、起案者要素か、承認者要素か、最終決裁者要素の決裁後変更権限要素に値がある。

権限に問題がなければ、書類参照部０１０１４は、取得した書類を権限変更画面１３００１に返却し、権限変更画面１３００１は返却されたＸＭＬ形式の書類をＨＴＭＬに変換し表示する。この時、権限変更画面１３００１には、所有時変更権限要素、又は、決裁後変更権限要素に記述された付与可能な権限の一覧を、選択できるように画面に表示する。また、権限を変更する対象部門と対象メンバーを選択できるように画面に表示する。

図５５に権限変更画面の例を示す。

３−３．権限変更の実施
利用者は、書類を参照して、権限の変更対象の書類であることを確認し、付与する権限と、変更対象を選択して、権限変更画面１３００１に備えられた権限変更ボタンを押下する。書類参照画面０１０２２は、書類の識別子、利用者のユーザＩＤ、付与する権限、変更対象、及び、権限の変更を意味するフラグを引数に、権限変更部１３０１２を呼び出す。

権限変更部１３０１２は、書類の検索時、書類の表示時と同様に、次の条件で、権限を変更する権限があるか確認する。

・起案者要素の予定者要素に、自身のユーザＩＤが存在し、起案者要素の実施者要素が空であり、起案者要素の所有時変更権限要素に付与しようとしている権限がある。
又は、
・承認者要素の予定者要素に、自身のユーザＩＤが存在し、承認者要素の実施者要素が空であり、当該承認者要素の所有時変更権限要素に値があり、当該承認者要素の一つ前の起案者要素か、承認者要素の実施者要素に付与しようとしている権限がある。
又は、
・実施者要素がすべて値を持ち、自身のユーザＩＤがいずれかの実施者要素に存在し、自身のユーザＩＤが存在した、実施者要素の親の、起案者要素か、承認者要素か、最終決裁者要素の決裁後変更権限要素に付与しようとしている権限がある。

権限に問題がなければ、条件にマッチした起案者要素、承認者要素、又は、最終決裁者要素に、書類が最終決裁前ならば所有時権限要素を、書類が最終決裁後ならば決裁後権限要素を作成し、変更した権限、対象部門、及び、対象メンバーの範囲を記述する。権限変更部１３０１２は、変更した書類を書類を保存するサーバ０１０１７に送信し、保存されている書類を更新する。

図５６は、最終決裁後に最終決裁者の所属部門の下位の部門の長に参照権限を付与した承認経路の例である。

３−４．権限を付与されたユーザの操作
権限を付与されたユーザの、参照、変更、削除、及び、承認の処理手順は実施例１と同じである。それぞれの処理手順における、検索の条件、書類表示時の権限確認の条件、及び、操作時の権限確認の条件は、以下のとおりになる。

３−４−１．参照
参照可能となる条件は、以下のいずれかとなる。

・承認経路要素に却下要素、又は、削除要素が無く、起案者要素の実施者要素が空であり、当該起案者要素の所有時権限要素の所属部門、及び、所属メンバーが示す範囲に、自身のユーザＩＤが含まれる。

・承認経路要素に却下要素、又は、削除要素が無く、承認者要素の実施者要素が空であり、当該承認者要素の所有時権限要素の所属部門、及び、所属メンバーが示す範囲に、自身のユーザＩＤが含まれ、当該承認者要素の一つ前の承認者要素、又は、起案者要素の実施者要素に値がある。

・承認経路要素に却下要素、又は、削除要素が無く、当該最終決裁者の実施者要素が空であり、当該最終決裁者の所有時権限要素の所属部門、及び、所属メンバーが示す範囲に、自身のユーザＩＤが含まれ、当該最終決裁者の一つ前の承認者要素、又は、起案者要素の実施者要素に値がある。

・すべての実施者要素が値を持つか、又は、承認経路要素に却下要素があり、起案者要素、承認者要素、又は、最終決裁者要素の決裁後権限要素の所属部門、及び、所属メンバーが示す範囲に、自身のユーザＩＤが含まれる。

３−４−２．変更
変更可能となる条件は、以下のいずれかとなる。

・承認経路要素に却下要素、又は、削除要素が無く、起案者要素の実施者要素が空であり、当該起案者要素の所有時権限要素に値“ｗｒｉｔｅ”があり、当該起案者要素の所有時権限要素の所属部門、及び、所属メンバーが示す範囲に、自身のユーザＩＤが含まれる。

・承認経路要素に却下要素、又は、削除要素が無く、承認者要素の実施者要素が空であり、当該承認者要素の所有時権限要素に値“ｗｒｉｔｅ”があり、当該承認者要素の所有時権限要素の所属部門、及び、所属メンバーが示す範囲に、自身のユーザＩＤが含まれ、当該承認者要素の一つ前の承認者要素、又は、起案者要素の実施者要素に値がある。

・承認経路要素に却下要素、又は、削除要素が無く、当該最終決裁者の実施者要素が空であり、当該最終決裁者要素の所有時権限要素に値“ｗｒｉｔｅ”があり、当該最終決裁者の所有時権限要素の所属部門、及び、所属メンバーが示す範囲に、自身のユーザＩＤが含まれる、当該最終決裁者の一つ前の承認者要素、又は、起案者要素の実施者要素に値がある。

・すべての実施者要素が値を持ち、起案者要素、承認者要素、又は、最終決裁者要素の決裁後権限要素のに値“ｗｒｉｔｅ”があり、当該決裁後権限要素の所属部門、及び、所属メンバーが示す範囲に、自身のユーザＩＤが含まれる。

３−４−３．削除
削除可能となる条件は、以下のいずれかとなる。

・承認経路要素に却下要素、又は、削除要素が無く、起案者要素の実施者要素が空であり、当該起案者要素の所有時権限要素に値“ｄｅｌｅｔｅ”があり、当該起案者要素の所有時権限要素の所属部門、及び、所属メンバーが示す範囲に、自身のユーザＩＤが含まれる。

・承認経路要素に却下要素、又は、削除要素が無く、承認者要素の実施者要素が空であり、当該承認者要素の所有時権限要素に値“ｄｅｌｅｔｅ”があり、当該承認者要素の所有時権限要素の所属部門、及び、所属メンバーが示す範囲に、自身のユーザＩＤが含まれ、当該承認者要素の一つ前の承認者要素、又は、起案者要素の実施者要素に値がある。

・承認経路要素に却下要素、又は、削除要素が無く、当該最終決裁者の実施者要素が空であり、当該最終決裁者要素の所有時権限要素に値“ｄｅｌｅｔｅ”があり、当該最終決裁者の所有時権限要素の所属部門、及び、所属メンバーが示す範囲に、自身のユーザＩＤが含まれ、当該最終決裁者の一つ前の承認者要素、又は、起案者要素の実施者要素に値がある。

・承認経路要素に削除要素が無く、すべての実施者要素が値を持ち、起案者要素、承認者要素、又は、最終決裁者要素の決裁後権限要素のに値“ｄｅｌｅｔｅ”があり、当該決裁後権限要素の所属部門、及び、所属メンバーが示す範囲に、自身のユーザＩＤが含まれる。

・承認経路要素に削除要素が無く、承認経路要素に却下要素があり、起案者要素、承認者要素、又は、最終決裁者要素の決裁後権限要素のに値“ｄｅｌｅｔｅ”があり、当該決裁後権限要素の所属部門、及び、所属メンバーが示す範囲に、自身のユーザＩＤが含まれる。

３−４−４．提出
提出可能となる条件は、以下となる。

・承認経路要素に却下要素、又は、削除要素が無く、起案者要素の実施者要素が空であり、当該起案者要素の所有時権限要素に値“ａｐｐｒｏｖａｌ”があり、当該起案者要素の承認権限要素に値“ｆｏｒｗａｒｄ”があり、当該起案者要素の所有時権限要素の所属部門、及び、所属メンバーが示す範囲に、自身のユーザＩＤが含まれる。

３−４−５．承認（承認、却下、差戻し）
承認可能（承認、却下、差戻し）となる条件は、以下のいずれかとなる。
・承認経路要素に却下要素、又は、削除要素が無く、承認者要素の実施者要素が空であり、当該承認者要素の所有時権限要素に値“ａｐｐｒｏｖａｌ”があり、当該承認者要素の承認権限要素に値“ｆｏｒｗａｒｄ”、“ｒｅｊｅｃｔ”、又は、“ｒｅｔｕｒｎ”があり、当該承認者要素の所有時権限要素の所属部門、及び、所属メンバーが示す範囲に、自身のユーザＩＤが含まれ、当該承認者要素の一つ前の承認者要素、又は、起案者要素の実施者要素に値がある。

・承認経路要素に却下要素、又は、削除要素が無く、当該最終決裁者の実施者要素が空であり、当該最終決裁者要素の所有時権限要素に値“ａｐｐｒｏｖａｌ”があり、当該最終決裁者要素の承認権限要素に値“ｆｏｒｗａｒｄ”、“ｒｅｊｅｃｔ”、又は、“ｒｅｔｕｒｎ”があり、当該最終決裁者の所有時権限要素の所属部門、及び、所属メンバーが示す範囲に、自身のユーザＩＤが含まれ、当該最終決裁者の一つ前の承認者要素、又は、起案者要素の実施者要素に値がある。

３−４−６．承認（取戻し）
承認可能（取戻し）となる条件は、以下のいずれかとなる。

・承認経路要素に却下要素、又は、削除要素が無く、起案者要素の実施者要素に値があり、当該起案者要素の所有時権限要素に値“ａｐｐｒｏｖａｌ”があり、当該起案者要素の承認権限要素に値“ｇｅｔｂａｃｋ”があり、当該起案者要素の所有時権限要素の所属部門、及び、所属メンバーが示す範囲に、自身のユーザＩＤが含まれ、当該起案者要素の一つ後の承認者要素に値が無い。

・承認経路要素に却下要素、又は、削除要素が無く、承認者要素の実施者要素に値があり、当該承認者要素の所有時権限要素に値“ａｐｐｒｏｖａｌ”があり、当該承認者要素の承認権限要素に値“ｇｅｔｂａｃｋ”があり、当該承認者要素の所有時権限要素の所属部門、及び、所属メンバーが示す範囲に、自身のユーザＩＤが含まれ、当該承認者要素の一つ後の承認者要素に値が無い。

３−４−７．承認（飛ばし承認、飛ばし決裁）
承認可能（飛ばし承認、飛ばし決裁）となる条件は、以下のいずれかとなる。

・承認経路要素に却下要素、又は、削除要素が無く、起案者要素の実施者要素に値があり、承認者要素の実施者要素が空であり、当該承認者要素の所有時権限要素に値“ａｐｐｒｏｖａｌ”があり、当該承認者要素の承認権限要素に値“ｓｋｉｐ”があり、当該承認者要素の所有時権限要素の所属部門、及び、所属メンバーが示す範囲に、自身のユーザＩＤが含まれ、当該承認者要素の前に実施者要素が空の連続した承認者要素が一つ以上ある。

・承認経路要素に却下要素、又は、削除要素が無く、起案者要素の実施者要素に値があり、最終決裁者要素の実施者要素が空であり、当該最終決裁者要素の所有時権限要素に値“ａｐｐｒｏｖａｌ”があり、当該最終決裁者要素の承認権限要素に値“ｓｋｉｐ”があり、当該最終決裁者要素の所有時権限要素の所属部門、及び、所属メンバーが示す範囲に、自身のユーザＩＤが含まれ、当該最終決裁者要素の前に実施者要素が空の連続した承認者要素が一つ以上ある。

＜付記１＞
なお、本明細書において説明した実施例１乃至１３は、任意のものを組み合わせることでも、本願の目的を達成しうる。

＜付記２＞
また、実施例に含まれる各装置及びサーバは、合わせて一つの装置として実現してもよいし、任意のものを組み合わせて一つの装置としても、本願の目的を達成しうる。

＜付記３＞
また、実施例に含まれる上記各機能は、任意のものをハードウェアとして構成してもよいし、コンピュータによって実行させることで、上記各機能として動作させるためのコンピュータプログラムとして構成してもよい。プログラムとして構成する場合は、磁気ディスク、光ディスク、光磁気ディスク、フラッシュメモリなどの任意の記録媒体に格納される。

実際の組織階層の例に当てはめた、命令と応答の説明の図である。 実際の組織階層の例に当てはめた、承認経路の説明の図である。 差戻しや飛び決の承認経路の図である。 組織階層を横断する承認経路の例である。 ライン部門配下の仮想的なスタッフ部門の図である。 書類の作成中の参照権限の図である。 書類が承認中の参照権限の図である。 書類の最終決裁後の参照権限の図である。 所有者を基準に組織階層上で相対的に参照権限を設定する例である。 本発明を実現するために必要な構成要素のブロック図である。 組織図のツリー構造を示したブロック図である。 チェックプログラムの処理のフローチャートである。 チェックプログラムの処理のフローチャートである。 補完プログラムの処理のフローチャートである。 書類の作成のフローチャートである。 承認経路の設定のフローチャートである。 組織階層情報に様式の承認経路の定義、及び、権限の定義を反映した中間情報０１０６２の例である。 組織階層情報に承認経路の定義を反映した中間情報０１０６２から承認経路０１０６８を作成するフローチャートである。 承認経路と書類の承認経路要素のＸＭＬへの変換ロジックのフローチャートである。 承認経路と書類の承認経路要素のＸＭＬへの変換ロジックのフローチャートである。 承認経路要素を追加したＸＭＬ形式の書類の例である。 検索画面の例である。 権限変更画面の例である。 承認後の書類の承認者要素の例である。 差戻し後の書類の承認経路要素の例である。 飛ばし承認後の書類の承認経路要素の例である。 権限のまとめの図である。 権限のまとめの図である。 組織情報記述言語（ユーザ情報）の記述例である。 組織情報記述言語（組織階層情報）の記述例である。 様式記述言語の構成の図である。 様式に記述される型、及び、文書構造の定義の記述例である。 様式記述言語（承認経路の定義）の記述例である。 様式記述言語（権限の定義）の記述例である。 複数項目にまたがるエラーチェック及び補完を可能とした型及び文書構造の記述例である。 エラー判定結果を返却するチェックプログラムの処理のフローチャートである。 補完値の２次元配列を返却する補完プログラムの処理のフローチャートである。 外部データベースの値を列挙値として利用した場合のチェックプログラムの処理ジックのフローチャートである。 外部データベースの値を列挙値として利用した場合のチェックプログラムの処理ジックのフローチャートである。 外部データベースの値を列挙値として利用した場合のチェックプログラムの処理ジックのフローチャートである。 外部データベースの値を列挙値として利用した場合のチェックプログラムの処理ジックのフローチャートである。 外部データベースの値を列挙値として利用した場合のチェックプログラムの処理ジックのフローチャートである。 外部データベースの値を列挙値として利用した場合のチェックプログラムの処理ジックのフローチャートである。 型に数値範囲の制限を加える方法の処理のフローチャートである。 型に数値範囲の制限を加える方法の処理のフローチャートである。 組織を横断する承認経路を求める処理のフローチャートである。 本発明を実現するために必要な構成要素のブロック図である。 書類の作成処理のフローチャートである。 承認経路の処理のフローチャートである。 組織階層情報に様式の承認経路の定義、及び、権限の定義を反映した中間情報１３０１３の例である。 組織階層情報に承認経路の定義を反映した中間情報から承認経路１３００９を作成する処理のフローチャートである。 承認経路と書類の承認経路要素のＸＭＬへの変換ロジックのフローチャートである。 承認経路と書類の承認経路要素のＸＭＬへの変換ロジックのフローチャートである。 承認経路要素を追加したＸＭＬ形式の書類の例である。 権限変更画面の例である。 最終決裁後に最終決裁者の所属部門の下位の部門の長に参照権限を付与した承認経路の例である。

０１００１ 組織情報・様式・既存の型を保存するサーバ
０１００２ 組織情報、様式、及び、既存の型を解釈し、チェックプログラム、補完プログラム、及び、様式中間情報を生成する様式コンパイラ
０１００３ 組織情報、様式、及び、既存の型を解釈し、チェックプログラム、補完プログラム、及び、様式中間情報を生成する様式コンパイラ０１００２を実行する様式コンパイルサーバ
０１００４ 組織情報参照部
０１００５ 様式検索部
０１００６ 組織情報参照部０１００４と様式検索部０１００５からなるアプリケーションサーバ
０１００７ 生成されたチェックプログラム
０１００８ 補完プログラム
０１００９ 生成されたチェックプログラム０１００７、及び、補完プログラム０１００８を実行するアプリケーションサーバ
０１０１０ 書類起案部
０１０１１ 書類提出部
０１０１２ 書類承認部
０１０１３ 書類検索部
０１０１４ 書類参照部
０１０１５ 書類削除部
０１０１６ 書類起案部０１０１０、書類提出部０１０１１、書類承認部０１０１２、書類検索部０１０１３、書類参照部０１０１４、書類削除部０１０１５、及び、権限変更部１３０１２からなるアプリケーションサーバ
０１０１７ 書類を保存するサーバ
０１０１８ 様式選択画面
０１０１９ 書類検索画面
０１０２０ 書類入力画面
０１０２１ 書類承認画面
０１０２２ 書類参照画面
０１０２３ 様式選択画面０１０１８、書類検索画面０１０１９、書類入力画面０１０２０、書類承認画面０１０２１、書類参照画面０１０２２、及び、権限変更画面１３００１を保存し配信するＷｅｂサーバ
０１０２４ 認証サーバ
０１０２５ 画面を表示するＷＥＢブラウザ
０１０２６ 画面を表示するＷＥＢブラウザ０１０２５を持つ複数の利用者端末
１３００１ 権限変更画面
１３０１２ 権限変更部

Claims (9)

1. 様式を記憶する手段と、前記様式に基づいてチェックプログラムおよび補完プログラムを生成する手段と、前記様式に基づいて利用者に入力画面を提供する手段とからなる文書管理システムにおいて、
   前記様式は、文書を構成する項目と型との対応関係の記述を含む文書構造の定義と、項目に入力可能な値の範囲を定義した型の定義とを含む情報であり、
   前記補完プログラムは、前記様式に含まれる前記型の定義と前記入力画面へ入力された入力値に基づいて入力候補を返却し、
   前記チェックプログラムは、前記様式に基づいて、入力画面に入力された入力値のチェックを行って、チェック結果を返却し、
   前記入力画面は、前記補完プログラムを呼び出して、返却された前記入力候補を表示することで入力補助を行うとともに、前記入力画面を呼び出して、入力画面に入力された入力値のチェックを行うことを特徴とする文書管理システム。
2. 前記様式に含まれた型の定義は、型名に対して、項目に入力可能な値を１つ以上列挙したもの、型名に対して、項目に入力可能な文字列を正規表現を用いて定義したもの、型名に対して、項目に入力可能な値の範囲を数式を用いて定義したもの、型名に対して、他の型名を対応付けて定義したもののいずれかを含むことを特徴とする請求項１に記載の文書管理システム。
3. 前記稟議システムは、項目に入力可能な値を保存した外部データベースをさらに備え、前記様式に含まれた型の定義は、前記外部データベースへのアクセス方法の定義を含むことを特徴とする請求項１、２に記載の文書管理システム。
4. 前記様式に含まれた型の定義は、項目間の値の関係の定義を含み、
   前記チェックプログラムは、前記入力画面に入力された入力値が前記項目間の値の関係を満たすかどうかをチェックするとともに、
   前記補完プログラムは、前記項目間の値の関係を満たす入力候補を返却することを特徴とする請求項１−３に記載の文書管理システム。
5. 前記項目間の値の関係の定義は、項目に入力可能な値の組を列挙したものを含むことを特徴とする請求項４に記載の文書管理システム。
6. 前記文書管理システムは、項目に入力可能な値の組を保存した外部データベースをさらに備え、
   前記項目間の値の関係の定義は、前記外部データベースへのアクセス方法の定義を含むことを特徴とする請求項４、５に記載の文書管理システム。
7. 前記チェックプログラムから返却された前記入力候補は複数の入力候補を含み、
   前記入力画面は、前記複数の入力候補を一覧表示することで入力補助を行うことを特徴とする請求項１−６に記載の文書管理システム
8. 様式を記憶する手段と、前記様式に基づいてチェックプログラムおよび補完プログラムを生成する手段と、前記様式に基づいて利用者に入力画面を提供する手段とからなる文書管理システムにおいて用いられる文書管理方法であって、
   前記様式は、文書を構成する項目と型との対応関係の記述を含む文書構造の定義と、項目に入力可能な値の範囲を定義した型の定義とを含む情報であり、
   前記補完プログラムが、前記様式に含まれる前記型の定義と前記入力画面へ入力された入力値に基づいて入力候補を返却するステップと、
   前記チェックプログラムが、前記様式に基づいて、入力画面に入力された入力値のチェックを行って、チェック結果を返却するステップと、
   前記入力画面が、前記補完プログラムを呼び出して、返却された前記入力候補を表示することで入力補助を行うとともに、前記入力画面を呼び出して、入力画面に入力された入力値のチェックを行うステップとを有することを特徴とする文書管理方法。
9. コンピュータを、様式を記憶する手段と、前記様式に基づいてチェックプログラムおよび補完プログラムを生成する手段と、前記様式に基づいて利用者に入力画面を提供する手段とからなる文書管理システムとして動作させるためのコンピュータプログラムであって、
   前記様式は、文書を構成する項目と型との対応関係の記述を含む文書構造の定義と、項目に入力可能な値の範囲を定義した型の定義とを含む情報であり、
   前記補完プログラムが、前記様式に含まれる前記型の定義と前記入力画面へ入力された入力値に基づいて入力候補を返却するステップと、
   前記チェックプログラムが、前記様式に基づいて、入力画面に入力された入力値のチェックを行って、チェック結果を返却するステップと、
   前記入力画面が、前記補完プログラムを呼び出して、返却された前記入力候補を表示することで入力補助を行うとともに、前記入力画面を呼び出して、入力画面に入力された入力値のチェックを行うステップとを有することを特徴とするコンピュータプログラム。