(57)【要約】【課題】複数社のワークフローシステムを統合する際に、企業ごとの役職の違いを吸収して承認権限の設定及び承認者に対する認証処理を効率化する。【解決手段】職位情報管理ＤＢ１０２３は、役職のカテゴリーである職位が複数示され、複数の職位には申請書の承認権限が認められる承認権限職位が含まれており、各企業で用いられている役職が複数の職位のうちのいずれかの職位に対応付けられている職位情報を記憶する。ワークフロー処理部１０１３は、Ａ社の構成員がＡ社で生成された申請書の承認者に選定された場合に、当該構成員の役職が職位情報において承認権限職位に対応付けられているＡ社の役職と一致するか否かを判定する。【選択図】図１
2015170263.tif 000002
【特許請求の範囲】
【請求項１】
複数の企業のワークフローシステムを統合するワークフロー統合システムであって、
役職のカテゴリーである役職カテゴリーが複数示され、複数の役職カテゴリーには申請書の承認権限が認められる承認権限役職カテゴリーが含まれており、各企業で用いられている役職が前記複数の役職カテゴリーのうちのいずれかの役職カテゴリーに対応付けられている役職カテゴリー情報を記憶する役職カテゴリー情報記憶部と、
いずれかの企業の構成員が当該企業で生成された申請書の承認者に選定された場合に、当該構成員の役職が前記役職カテゴリー情報において前記承認権限役職カテゴリーに対応付けられている当該企業の役職と一致するか否かを判定する承認者役職判定部とを有することを特徴とするワークフロー統合システム。
【請求項２】
前記承認者役職判定部は、
申請書の承認者に選定された構成員の役職が前記承認権限役職カテゴリーに対応付けられている役職と一致しない場合に、当該構成員による前記申請書の承認を許可しないことを特徴とする請求項１に記載のワークフロー統合システム。
【請求項３】
前記ワークフロー統合システムは、更に、
企業ごと、かつ申請書ごとに、申請権限者の属性が示される申請権限者情報を記憶する申請権限者情報記憶部と、
いずれかの企業の構成員がいずれかの申請書を生成しようとする場合に、当該構成員の属性が前記申請権限者情報において当該企業の当該申請書の申請権限者の属性と一致するか否かを判定する申請権限者属性判定部とを有することを特徴とする請求項１に記載のワークフロー統合システム。
【請求項４】
前記申請権限者属性判定部は、
申請書を生成しようとする構成員の属性が当該企業の当該申請書の申請権限者の属性と一致しない場合に、当該構成員による前記申請書の生成を許可しないことを特徴とする請求項３に記載のワークフロー統合システム。
【請求項５】
前記ワークフロー統合システムは、
承認を要する申請書が生成されたことを通知する電子メールである通知メールを送信する通知メール送信部と、
企業ごと、又は企業の部門ごとに、通知メールの送信先に、承認権限を有する承認権限者に加えて、前記承認権限者に代わって承認を行う代理承認権限を有する代理承認権限者を含めるか否かが示される通知メール設定情報を記憶する通知メール設定情報記憶部とを有し、
前記通知メール送信部は、
通知メールの送信先に代理承認権限者を含めることが前記通知メール設定情報に示されている企業又は部門で申請書が生成された場合に、代理承認権限者が利用する端末装置に通知メールを送信することを特徴とする請求項１に記載のワークフロー統合システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ワークフローシステムに関する。
【背景技術】
【０００２】
企業等では、ワークフローシステムを利用して、申請書の生成、生成された申請書の承認等が行われている。
このようなワークフローシステムとして、特許文献１に記載のものがある。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００５−３８１７２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
特許文献１のワークフローシステムは企業ごとに利用されることが前提となっている。
このため、企業ごとのワークフローシステムを用意する必要があるが、各社で運用されているワークフローシステムは構成や機能が似通っていることが多く、特に関連会社間で複数社のワークフローシステムを統合して運用できる環境が望まれる。
複数社のワークフローシステムを統合した場合には、申請書の承認権限を各社での役職等をもとに設定する必要がある。
しかしながら、企業ごとに役職の階層構造や役職の名称が異なっており、複数社のワークフローシステムを統合した場合にも、承認権限の設定、承認者に対する認証処理が複雑化するという課題がある。
【０００５】
本発明は、このような事情に鑑みたものであり、複数のワークフローシステムを統合する際に、企業ごとの役職の違いを吸収して承認権限の設定及び承認者に対する認証処理を効率化することを主な目的とする。
【課題を解決するための手段】
【０００６】
本発明に係るワークフロー統合システムは、
複数の企業のワークフローシステムを統合するワークフロー統合システムであって、
役職のカテゴリーである役職カテゴリーが複数示され、複数の役職カテゴリーには申請書の承認権限が認められる承認権限役職カテゴリーが含まれており、各企業で用いられている役職が前記複数の役職カテゴリーのうちのいずれかの役職カテゴリーに対応付けられている役職カテゴリー情報を記憶する役職カテゴリー情報記憶部と、
いずれかの企業の構成員が当該企業で生成された申請書の承認者に選定された場合に、当該構成員の役職が前記役職カテゴリー情報において前記承認権限役職カテゴリーに対応付けられている当該企業の役職と一致するか否かを判定する承認者役職判定部とを有することを特徴とする。
【発明の効果】
【０００７】
本発明によれば、各企業で用いられている役職を役職カテゴリーに集約することで、企業ごとの役職の違いを吸収して承認権限の設定及び承認者に対する認証処理を効率化することができる。
【図面の簡単な説明】
【０００８】
【図１】実施の形態１に係るシステム構成例を示す図。
【図２】実施の形態１に係る会社情報の例を示す図。
【図３】実施の形態１に係るユーザ情報の例を示す図。
【図４】実施の形態１に係る職位情報の例を示す図。
【図５】実施の形態１に係る申請権限者情報の例を示す図。
【図６】実施の形態１に係る代理承認権限者情報の例を示す図。
【図７】実施の形態１に係る通知メール設定情報の例を示す図。
【図８】実施の形態１に係る申請書の生成手順を示すフローチャート図。
【図９】実施の形態１に係る申請書の承認者選定手順を示すフローチャート図。
【図１０】実施の形態１に係る通知メールの送信手順を示すフローチャート図。
【図１１】実施の形態１に係るワークフロー統合システムのハードウェア構成例を示す図。
【発明を実施するための形態】
【０００９】
実施の形態１．
図１は、本実施の形態に係るワークフロー統合システム１００を含むシステム構成例を示す。
【００１０】
図１において、ワークフロー統合システム１００は、Ａ社向けのＡ社ワークフローシステム１０１ａ、Ｂ社向けのＢ社ワークフローシステム１０１ｂ等と、ＤＢシステム１０２で構成される。
なお、Ａ社ワークフローシステム１０１ａ、Ｂ社ワークフローシステム１０１ｂ等を総称して、ワークフローシステム１０１という。
図１では、Ａ社ワークフローシステム１０１ａ、Ｂ社ワークフローシステム１０１ｂのみが図示されているが、他の企業向けのワークフローシステム１０１が実装されていてもよい。
【００１１】
ワークフロー統合システム１００は、Ａ社ユーザ端末装置２００、Ｂ社ユーザ端末装置３００、システム管理者端末装置４００、ＩＤ登録改廃権限者端末装置５００に接続されている。
Ａ社ユーザ端末装置２００は、Ａ社のユーザが利用する端末装置である。
Ｂ社ユーザ端末装置３００は、Ｂ社のユーザが利用する端末装置である。
図１では、Ａ社ユーザ端末装置２００及びＢ社ユーザ端末装置３００は、それぞれ１台しか図示されていないが、それぞれ複数台存在するものとする。
システム管理者端末装置４００は、ワークフロー統合システム１００を管理するシステム管理者が利用する端末装置である。
ＩＤ登録改廃権限者端末装置５００は、ユーザＩＤ（Ｉｄｅｎｔｉｆｉｅｒ）の登録の改廃を行う権限のあるＩＤ登録改廃権限者が利用する端末装置である。
図１では、ＩＤ登録改廃権限者端末装置５００は１台しか図示されていないが、企業ごとにＩＤ登録改廃権限者端末装置５００が存在するものとする。
【００１２】
次に、ワークフロー統合システム１００の内部構成を説明する。
まず、ワークフローシステム１０１の構成例を説明する。
ここでは、代表としてＡ社ワークフローシステム１０１ａの構成例を説明するが、Ｂ社ワークフローシステム１０１ｂの構成も同様とする。
【００１３】
申請情報管理ＤＢ１０１１は、Ａ社において生成された申請書を管理する。
申請・承認履歴管理ＤＢ１０１２は、Ａ社における申請書作成履歴、申請書承認履歴が示される申請・承認履歴情報を管理する。
【００１４】
ワークフロー処理部１０１３は、ワークフローに関する処理を行う。
例えば、ワークフロー処理部１０１３は、申請書を作成しようとする申請者に申請書を作成する権限（申請権限）があるか否かを判定する。
また、ワークフロー処理部１０１３は、申請権限者が指定した承認者に申請書を承認する権限（承認権限）があるか否かを判定する。
ワークフロー処理部１０１３は、承認者役職判定部及び申請権限者属性判定部の例に相当する。
【００１５】
なお、申請権限を有する者を申請権限者という。
申請者は申請書の生成を行おうとする者であり、申請者が必ずしも申請権限者であるとは限らない。
申請権限のない申請者（申請権限者でない申請者）は、ワークフロー処理部１０１３により申請書の生成が禁止される。
また、承認権限がある者を承認権限者という。
申請権限者によって承認を行うべき者として指定された者を承認者という。
承認者が必ずしも承認権限者であるとは限らない。
承認権限のない承認者（承認権限者ではない承認者）は、ワークフロー処理部１０１３により申請書の承認が禁止される。
また、承認権限者に代わって承認する権限（代理承認権限）を有する者を代理承認権限者という。
【００１６】
申請・承認履歴管理部１０１４は、申請書が生成された場合、申請書が承認又は否認された場合に、申請・承認履歴管理ＤＢ１０１２の申請・承認履歴情報を更新する。
【００１７】
通知メール送信部１０１５は、承認が必要な申請書が生成されたことを通知する通知メールを生成し、通知メールを承認権限者（及び代理承認権限者）が利用する端末装置に送信する。
【００１８】
会社情報管理ＤＢ１０２１は、ワークフロー統合システム１００を利用する会社の情報である会社情報を管理する。
会社情報は、例えば、図２に示す情報であり、会社ＩＤ、会社名、住所、電話番号が含まれている。
【００１９】
ユーザ情報管理ＤＢ１０２２は、各社に所属するユーザの情報であるユーザ情報を管理する。
ユーザ情報は、例えば、図３に示す情報であり、会社ＩＤ、ユーザＩＤ、ユーザの氏名、ユーザの所属先、ユーザの役職、メールアドレス、パスワードが含まれている。
【００２０】
職位情報管理ＤＢ１０２３は、職位情報を管理する。
職位情報は、例えば、図４に示す情報である。
職位情報には、役職のカテゴリーである職位（役職カテゴリー）が複数示され、企業ごとに、職位に対応する役職が示される。
図４の例では、職位として、役員、部門長、組織長が示されている。
Ａ社（会社ＩＤ：００１）では、役職として、社長、副社長、部長、課長があり、社長及び副社長は職位としては役員に分類され、部長は部門長に分類され、課長は組織長に分類される。
Ｂ社（会社ＩＤ：００２）では、役職として、社長、副社長、専務、センター長、部長、課長、係長があり、社長、副社長及び専務は職位としては役員に分類され、センター長、部長及び課長は部門長に分類され、係長は組織長に分類される。
また、職位の中には、申請書の承認権限が認められる承認権限職位（承認権限役職カテゴリー）が含まれており、図４の例では、部門長に承認権限が認められている。
職位情報は、役職カテゴリー情報の例に相当し、職位情報管理ＤＢ１０２３は、役職カテゴリー情報記憶部の例に相当する。
【００２１】
申請権限者情報管理ＤＢ１０２４は、申請権限者情報を管理する。
申請権限者情報は、例えば、図５に示す情報である。
申請権限者情報では、企業ごと、かつ申請書ごとに、申請権限者の属性が示される。
図５の例では、申請権限者の属性として、所属先が記述されている。
申請権限者情報管理ＤＢ１０２４は、申請権限者情報記憶部の例に相当する。
【００２２】
代理承認権限者情報管理ＤＢ１０２５は、代理承認権限者情報を管理する。
代理承認権限者情報は、例えば、図６に示す情報である。
代理承認権限者情報では、企業ごとに、代理承認権限が認められる職位（代理承認権限職位）が示される。
図６の例では、Ａ社（会社ＩＤ：００１）、Ｂ社（会社ＩＤ：００２）とも職位：組織長に分類される役職の者に代理承認権限が与えられている。
【００２３】
通知メール設定情報管理ＤＢ１０２６は、通知メール設定情報を管理する。
通知メール設定情報は、例えば、図７に示す情報である。
通知メール設定情報では、企業の部門ごとに、通知メールの送信先が示される。
図７の例では、Ａ社の企画部では、通知メールの送信先として承認権限者と代理承認権限者が定義され、経理部では、通知メールの送信先として承認権限者のみが定義されている。
なお、図７では、企業の部門ごとに通知メールの送信先が定義されているが、企業ごとに通知メールの送信先が定義されるようにしてもよい。
通知メール設定情報管理ＤＢ１０２６は、通知メール設定情報記憶部の例に相当する。
【００２４】
ユーザ情報管理ＤＢ１０２２のユーザ情報は、ＩＤ登録改廃権限者が登録・更新を行い。
その他のＤＢの情報は、システム管理者が登録・更新を行う。
【００２５】
次に、本実施の形態に係るワークフロー統合システム１００の動作例を、図８〜図１０を参照して説明する。
図８は、申請書の生成手順を示すフローチャート図である。
図９は、申請書の承認者選定手順を示すフローチャート図である。
図１０は、通知メールの送信手順を示すフローチャート図である。
以下では、Ａ社のユーザがＡ社ユーザ端末装置２００を用いてワークフローシステム１０１ａにアクセスする例を説明する。
【００２６】
図８では、Ａ社のユーザである申請者がＡ社ユーザ端末装置２００を用いてワークフローシステム１０１ａにアクセスすると、ワークフロー処理部１０１３がログイン認証を行う（Ｓ８０１）。
例えば、Ａ社ユーザ端末装置２００が申請者のユーザＩＤとパスワードをワークフロー処理部１０１３に送信し、ワークフロー処理部１０１３がユーザＩＤとパスワードを用いたログイン認証を行う。
ここでは、ユーザＩＤが「００１−３４５６７」（図３）のユーザからアクセスがあったものと仮定する。
【００２７】
Ｓ８０１のログイン認証に成功した場合に、ワークフロー処理部１０１３は、申請書生成画面をＡ社ユーザ端末装置２００に送信し、申請者は生成しようとする申請書の申請書ＩＤを申請書性生成画面に入力する。
これにより、Ａ社ユーザ端末装置２００から申請書ＩＤが送信され、ワークフロー処理部１０１３はＡ社ユーザ端末装置２００から送信された申請書ＩＤを受信する（Ｓ８０２）。
ここでは、申請書ＩＤとして「ＪＫＬ−００１」を受信したと仮定する。
【００２８】
次に、ワークフロー処理部１０１３は、Ｓ８０１で受信したユーザＩＤから、当該申請者の所属先を特定する（Ｓ８０３）。
Ｓ８０１で受信したユーザＩＤは「００１−３４５６７」であるため、ワークフロー処理部１０１３は、このユーザＩＤが含まれるレコードを図３において検索し、申請者の所属先を「企画部第一課」と特定する。
【００２９】
次に、ワークフロー処理部１０１３は、Ｓ８０２で受信した申請書ＩＤに対する申請権限者属性を特定する（Ｓ８０４）。
Ｓ８０２で受信した申請書ＩＤは「ＪＫＬ−００１」であるため、ワークフロー処理部１０１３は、図５から、Ｓ８０２で受信した申請書ＩＤに対する申請権限者属性を「企画部」と特定する。
【００３０】
次に、ワークフロー処理部１０１３は、申請者が申請権限者属性を満たすかどうかを判定する（Ｓ８０５）。
申請者が申請権限者属性を満たす場合は、ワークフロー処理部１０１３は、当該申請者による申請書の生成を許可し（Ｓ８０６）、申請権限者属性を満たさない場合は、ワークフロー処理部１０１３は、当該申請者による申請書の生成を禁止する（Ｓ８０７）。
Ｓ８０３で特定した所属先は「企画部第一課」であり、Ｓ８０４で特定した申請権限者属性は「企画部」であるため、この場合は、申請権限者属性を満たし、申請書の生成が許可される。
【００３１】
図９では、申請者が申請書を生成すると、ワークフロー処理部１０１３は、Ａ社ユーザ端末装置２００から承認者のユーザＩＤを受信する（Ｓ９０１）。
ここでは、例えば、承認者のユーザＩＤとして「００１−１２３４５」（図３）が送信されたと仮定する。
【００３２】
次に、ワークフロー処理部１０１３は、Ｓ９０１で受信したユーザＩＤから、当該承認者の所属及び役職を特定する（Ｓ９０２）。
Ｓ９０１で受信したユーザＩＤは「００１−１２３４５」であるため、ワークフロー処理部１０１３は、このユーザＩＤが含まれるレコードを図３において検索し、承認者の所属先を「企画部」と特定し、また、承認者の役職を「企画部」と特定する。
【００３３】
次に、ワークフロー処理部１０１３は、承認権限がある役職を特定する（Ｓ９０３）。
具体的には、ワークフロー処理部１０１３は、図４から、承認権限職位である部門長に属する役職は、Ａ社では「部長」であることを特定する。
【００３４】
次に、ワークフロー処理部１０１３は、承認者に承認権限があるかどうかを判定する（Ｓ９０４）。
承認者に承認権限がある場合は、ワークフロー処理部１０１３は、当該申請書をワークフロー処理部１０１３に送信することを許可する（Ｓ９０５）。
一方、承認者に承認権限がない場合は、ワークフロー処理部１０１３は、当該申請書をワークフロー処理部１０１３に送信することを禁止する（Ｓ９０６）。
Ｓ９０２で特定した役職及びＳ９０３で特定した役職は、ともに「部長」であり、また、承認者は、申請者と同じ所属先（企画部）であるため、承認者に承認権限が認められる。
【００３５】
Ｓ９０５で申請書の送信が許可された場合は、Ａ社ユーザ端末装置２００から申請書が送信され、Ａ社ワークフローシステム１０１ａでは、ワークフロー処理部１０１３が会社情報管理ＤＢ１０２１に申請書を登録し、また、申請・承認履歴管理部１０１４が申請・承認履歴管理ＤＢ１０１２の申請・承認履歴情報を更新する。
【００３６】
図１０では、通知メール送信部１０１５が、図７を参照して、通知メールの送信先を特定する（Ｓ１００１）。
図７の例では、Ａ社は、通知メールの送信先として、承認権限者及び代理承認権限者が定義されている。
このため、通知メール送信部１０１５は、通知メールの送信先を承認権限者及び代理承認と特定する。
【００３７】
通知メールの送信先に代理権限者が含まれる場合（Ｓ１００２でＹＥＳ）は、通知メール送信部１０１５は、承認権限者と代理承認権限者に通知メールを送信する（Ｓ１００３）。
具体的には、通知メール送信部１０１５は、図６から、Ａ社の代理承認権限者が「組織長」であることを認識し、図４から、Ａ社では「組織長」は「課長」であることを特定する。
更には、通知メール送信部１０１５は、申請者の所属先が「企画部第一課」であることから、所属先が「企画部第一課」であり、役職が「課長」のレコードを図３において検索する。
この結果、通知メール送信部１０１５は、ユーザＩＤが「００１−２３４５６」のレコードを検索し、このレコードに含まれるメールアドレスを、代理承認権限者のメールアドレスとする。
また、通知メール送信部１０１５は、図９のＳ９０２で検索したレコードに含まれるメールアドレスを、承認権限者のメールアドレスとする。
通知メール送信部１０１５は、このようにして特定したメールアドレスが含まれる通知メールを送信する。
【００３８】
通知メールの送信先に代理権限者が含まれない場合（Ｓ１００２でＮＯ）は、通知メール送信部１０１５は、承認権限者にのみ通知メールを送信する（Ｓ１００４）。
【００３９】
このように、本実施の形態によれば、複数社のワークフローシステムを統合したワークフロー統合システムにおいて、各企業で用いられている役職を職位に集約することで、企業ごとの役職の違いを吸収して承認権限の設定及び承認者に対する認証処理を効率化することができる。
【００４０】
また、本実施の形態では、企業ごと、かつ申請書ごとに、申請権限者の属性が定義されているので、複数社のワークフローシステムを統合しても、企業ごと、かつ申請書ごとに、申請者に申請権限があるかどうかを正確に判別することができる。
【００４１】
また、本実施の形態では、企業ごと、又は企業の部門ごとに、通知メールの送信先が定義されているので、組織の実態に合わせて通知メールを送信することができる。
【００４２】
なお、本発明は、本実施の形態に限定されるものではなく、必要に応じて種々の変更が可能である。
【００４３】
最後に、本実施の形態に示したワークフロー統合システム１００のハードウェア構成例を図１１を参照して説明する。
ワークフロー統合システム１００はコンピュータであり、ワークフロー統合システム１００の各要素をプログラムで実現することができる。
ワークフロー統合システム１００のハードウェア構成としては、バスに、演算装置９０１、外部記憶装置９０２、主記憶装置９０３、通信装置９０４、入出力装置９０５が接続されている。
【００４４】
演算装置９０１は、プログラムを実行するＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）である。
外部記憶装置９０２は、例えばＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）やフラッシュメモリ、ハードディスク装置である。
主記憶装置９０３は、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）である。
通信装置９０４は、例えば、ＮＩＣ（Ｎｅｔｗｏｒｋ  Ｉｎｔｅｒｆａｃｅ  Ｃａｒｄ）である。
入出力装置９０５は、例えばマウス、キーボード、ディスプレイ装置等である。
【００４５】
プログラムは、通常は外部記憶装置９０２に記憶されており、主記憶装置９０３にロードされた状態で、順次演算装置９０１に読み込まれ、実行される。
プログラムは、図１に示す「〜部」として説明している機能を実現するプログラムである。
更に、外部記憶装置９０２にはオペレーティングシステム（ＯＳ）も記憶されており、ＯＳの少なくとも一部が主記憶装置９０３にロードされ、演算装置９０１はＯＳを実行しながら、図１に示す「〜部」の機能を実現するプログラムを実行する。
また、本実施の形態の説明において、「〜の判断」、「〜の判定」、「〜の抽出」、「〜の特定」、「〜の設定」、「〜の登録」、「〜の選択」、「〜の生成」、「〜の受信」等として説明している処理の結果を示す情報やデータや信号値や変数値が主記憶装置９０３にファイルとして記憶されている。
【００４６】
なお、図１１の構成は、あくまでもワークフロー統合システム１００のハードウェア構成の一例を示すものであり、ワークフロー統合システム１００のハードウェア構成は図１１に記載の構成に限らず、他の構成であってもよい。
【符号の説明】
【００４７】
１００  ワークフロー統合システム、１０１  ワークフローシステム、１０２  ＤＢシステム、２００  Ａ社ユーザ端末装置、３００  Ｂ社ユーザ端末装置、４００  システム管理者端末装置、５００  ＩＤ登録改廃権限者端末装置、１０１１  申請情報管理ＤＢ、１０１２  申請・承認履歴管理ＤＢ、１０１３  ワークフロー処理部、１０１４  申請・承認履歴管理部、１０１５  通知メール送信部、１０２１  会社情報管理ＤＢ、１０２２  ユーザ情報管理ＤＢ、１０２３  職位情報管理ＤＢ、１０２４  申請権限者情報管理ＤＢ、１０２５  代理承認権限者情報管理ＤＢ、１０２６  通知メール設定情報管理ＤＢ。
【図１】
2015170263.tif 000003
【図２】
2015170263.tif 000004
【図３】
2015170263.tif 000005
【図４】
2015170263.tif 000006
【図５】
2015170263.tif 000007
【図６】
2015170263.tif 000008
【図７】
2015170263.tif 000009
【図８】
2015170263.tif 000010
【図９】
2015170263.tif 000011
【図１０】
2015170263.tif 000012
【図１１】
2015170263.tif 000013