JP6942374B2 - 情報管理システム、サーバおよびユーザ端末 - Google Patents

Description

本発明は、情報の提供方法、特に、ユーザに応じて情報の提供方法を変化させる技術、に関する。

複数のユーザが情報を共有するためのさまざまなソフトウェア・ツールが提供されている。たとえば、グループ・カレンダーによるスケジュールの確認、ワークフロー・ソフトウェアによる作業進捗の確認などにより、地理的に離れていても、多数のユーザが共同作業を行いやすい環境が整いつつある。

特開２０１６−２０７０１２号公報

関係者が多くなるほど、情報は巨大化し、構造化しやすい。たとえば、製品開発プロジェクトにおいては、研究開発、資材調達、広告宣伝、資金管理などに関わるさまざまな情報が生み出される。また、研究開発にはソフトウェア開発が含まれ、ソフトウェア開発には通信プロトコルの策定作業が含まれるかもしれない。

プロジェクトリーダーは、研究開発から資金管理まで全体を広く見渡したいと考えるが、プロジェクトに関わる情報を詳細まで完璧に知ろうとすることは情報過多となってしまうためにかえって非生産的である。一方、開発エンジニアは研究開発に関わる情報を詳細に知る必要があるが、資金管理など他の分野の仕事についてはそれほど細かい情報を必要としない。同じプロジェクトに参加しているメンバーであっても、各自が知りたい情報はレベルにおいても量においても同一ではない。

本発明は、上記課題認識に基づいて完成された発明であり、その主たる目的は、ユーザが情報集合の中から自分に必要な情報を引き出しやすくするための技術、を提供することにある。

本発明のある態様におけるサーバは、複数のユーザ端末と通信ネットワークを介して接続される。
このサーバは、ユーザ端末に対して、データ構造を定義するフォームおよびフォームにしたがって作成されるデータ集合体であるエンティティの双方を表示可能なユーザ画面を提供するユーザ画面提供部と、ユーザ画面に対するユーザからのフォームの選択、および、選択されたフォームに基づくエンティティの作成指示にしたがって、エンティティを作成するエンティティ設定部と、ユーザ画面に対するユーザからの指定にしたがって、フォームまたはエンティティのメンバーとなる１以上のユーザを設定するメンバー設定部と、を備える。
ユーザ画面提供部は、ユーザ画面を提供するときには、複数のエンティティのうち、提供先のユーザがメンバーとして対応づけられるエンティティを表示対象として選抜する。

本発明のある態様におけるユーザ端末は、データ構造を定義するフォームおよびフォームにしたがって作成されるデータ集合体であるエンティティの双方を表示可能なユーザ画面を表示するユーザ画面表示部と、フォームにおいてあらかじめ準備されている複数の項目のうち、有効化する項目の指定をユーザから受け付ける項目入力部と、フォームにおいて有効化された項目に対する項目データの入力を受け付けるエンティティ作成入力部と、フォームまたはエンティティのメンバーとなる１以上のユーザの指定を受け付けるメンバー入力部と、を備える。
ユーザ画面表示部は、ユーザ画面において、複数のエンティティのうち当該端末のユーザがメンバーとして対応づけられているエンティティを選択的に表示する。

本発明のある態様における情報管理システムは、通信ネットワークを介して相互接続される１以上のユーザ端末とサーバを含む。
サーバは、ユーザ端末に対して、データ構造を定義するフォームおよびフォームにしたがって作成されるデータ集合体であるエンティティの双方を表示可能なユーザ画面を提供するユーザ画面提供部と、フォームにおいてあらかじめ準備されている複数の項目のうちユーザに指定された項目を有効化することでフォームのデータ構造を定義するフォーム設定部と、フォームにおいて有効化された項目に対する項目データの入力を受け付けることにより、フォームに基づくエンティティを設定するエンティティ設定部と、ユーザ画面に対するユーザからの指定にしたがって、フォームまたはエンティティのメンバーとなる１以上のユーザを設定するメンバー設定部と、エンティティの項目データに対するユーザからの更新指示にしたがって、エンティティの項目データを更新するエンティティ更新部と、エンティティの更新をユーザ端末に通知する更新通知部と、を備える。
ユーザ端末は、ユーザ画面を表示するユーザ画面表示部と、フォームにおいて有効化する項目の指定をユーザから受け付ける項目入力部と、フォームにおいて有効化された項目に対する項目データの入力を受け付けるエンティティ作成入力部と、フォームまたはエンティティのメンバーとなる１以上のユーザの指定を受け付けるメンバー入力部と、を備える。
サーバのユーザ画面提供部は、ユーザ画面を提供するときには、複数のエンティティのうち、提供先のユーザがメンバーとして対応づけられるエンティティを表示対象として選抜する。サーバの更新通知部は、更新対象となったエンティティのメンバーを更新の通知先として設定する。ユーザ端末のユーザ画面表示部は、ユーザ画面において、複数のエンティティのうち当該端末のユーザがメンバーとして対応づけられているエンティティを表示する。

本発明によれば、ユーザが情報集合の中から自分に必要な情報を引き出しやすくなる。

情報管理システムのハードウェア構成図である。 サーバの機能ブロック図である。 ユーザ端末の機能ブロック図である。 フォームとエンティティの関係を説明するための模式図である。 フォームの対応設定を説明するための模式図である。 ホーム画面の画面図である。 フォーム作成画面の画面図である。 フォーム第１定義画面の画面図である。 フォーム第２定義画面の画面図である。 メンバー登録画面の画面図である。 エンティティ作成画面の画面図である。 フォームリスト画面の画面図である。 エンティティリスト画面の画面図である。 対応設定画面の画面図である。 エンティティ閲覧画面の画面図である。 エンティティ表示の処理過程を示すフローチャートである。 更新通知時のフォームリスト画面の画面図である。 ジャンルとフォームの関係を説明するための模式図である。 ジャンルを設定したときのフォームリスト画面の画面図である。

本実施形態においては、子供服をデザインする服飾メーカーのプロジェクト管理を対象として説明する。
一般的には、服飾メーカーにおいては、「チーフディレクター」が子供服のコンセプトをつくる。コンセプト段階では、子供服のイメージや特徴だけがラフスケッチのかたちでまとめられる。「デザイナー」は、コンセプトにしたがって複数のデザイン案をつくる。

デザイン案が決まると、「パターナー」はＣＡＤ（Computer-Aided Design）により型紙（パターン）をつくる。次に、型紙に基づいて実際に子供服を試作される。「資材担当者」は、試作用品（生地、ファスナーなど）を調達する。試作と調達を繰り返しながら、シルエット、着心地、生産性（製作可能性）などをチェックする。パターナーは試作品の出来栄えをみながら、適宜、型紙の修正もする。

試作が終了すると、服飾メーカーは工場を運営する「外部業者」に量産発注をする。外部業者は商品に使う予定の生地で試作品を作成する。外部業者は実際に試作してみることで、量産性について検討する。外部業者からの意見を再検討した結果、デザイナーがデザインを再検討することもめずらしくない。

このように１着の子供服が出来上がるまでには、たくさんの人が連携してたくさんの工程を管理しながらプロジェクトを進める必要がある。プロジェクトを管理する「マネージャー」は、子供服が出来上がるまでの複雑なスケジュールを統括する。服飾メーカーは、通常、数百から数千の子供服プロジェクトを同時進行させるため、特に、マネージャーの管理負担は非常に大きなものとなりやすい。

プロジェクトをスムーズに進めるためには、プロジェクトに関わるさまざまな情報の伝達性を高めることが重要である。情報伝達性を高めるためには、受け手が理解しやすい形式にて情報を加工し、規格化して伝えることが望ましい。また、受け手が情報過多となってしまうと、かえって生産性が下がってしまい、ヒューマンエラーにつながる可能性もある。したがって、情報の受け手に応じて必要な情報と不要な情報を選別することも大切である。

本実施形態において説明する情報管理システムにおいては、「エンティティ」という単位で情報を管理する。エンティティは、「袴ａのデザイン案の試作」「レッスンバッグｂの量産の試作」など、ある製品の１つの工程を管理する上で必要な情報の集合体である。エンティティは、「フォーム」とよばれる規格に基づいて作成される。フォームにより、エンティティのデータ構造が定義される。

フォームには、１以上のユーザが「メンバー」として対応づけられる。たとえば、フォームＦ１にユーザＰ１、Ｐ２、Ｐ３が対応づけられたときには、フォームＦ１に基づいて作成されるエンティティＥ１１（情報集合）はユーザＰ１、Ｐ２、Ｐ３のみがアクセス可能となる。いいかえれば、この３人のユーザ以外のユーザは、エンティティＥ１１の情報を知ることができない。このような情報管理方法により、エンティティ（情報集合）ごとにメンバーを絞ることができる。
以下、本実施形態における情報管理システムの詳細を説明する。

図１は、情報管理システム１００のハードウェア構成図である。
情報管理システム１００においては、サーバ２００に対して、複数のユーザ端末１１０ａ、１１０ｂ・・・１０４ｎ（以下、まとめて言うときや特に区別しないときには「ユーザ端末１１０」と総称する）がインターネット１０２を介して接続される。本実施形態におけるユーザ端末１１０は、スマートフォンを想定している。ユーザ端末１１０は、ラップトップＰＣなどの汎用コンピュータであってもよい。ユーザ端末１１０とインターネット１０２は無線接続される。

ユーザ端末１１０は、服飾メーカーのユーザ（従業員または外部業者）により使用される。サーバ２００は、ユーザ端末１１０に対して、子供服プロジェクトに関わる情報共有サービスを提供する。ユーザ端末１１０には専用のソフトウェアをインストール必要はなく、ユーザ端末１１０はウェブブラウザからサーバ２００にアクセスすることでサービスを受けることが可能である。

図２は、サーバ２００の機能ブロック図である。
サーバ２００の各構成要素は、ＣＰＵ（Central Processing Unit）および各種コプロセッサなどの演算器、メモリやストレージといった記憶装置、それらを連結する有線または無線の通信線を含むハードウェアと、記憶装置に格納され、演算器に処理命令を供給するソフトウェアによって実現される。コンピュータプログラムは、デバイスドライバ、オペレーティングシステム、それらの上位層に位置する各種アプリケーションプログラム、また、これらのプログラムに共通機能を提供するライブラリによって構成されてもよい。以下に説明する各ブロックは、ハードウェア単位の構成ではなく、機能単位のブロックを示している。
ユーザ端末１１０についても同様である。

サーバ２００は、通信部２０２、データ処理部２０４およびデータ格納部２０６を含む。
通信部２０２は、通信処理を担当する。データ格納部２０６はフォームおよびエンティティに関連する各種データを格納する。データ処理部２０４は、通信部２０２により取得されたデータおよびデータ格納部２０６に格納されているデータに基づいて各種処理を実行する。データ処理部２０４は、通信部２０２およびデータ格納部２０６のインタフェースとしても機能する。

通信部２０２は、送信部２０８と受信部２１０を含む。
送信部２０８はユーザ端末１１０に各種データを送信し、受信部２１０はユーザ端末１１０から各種データを受信する。送信部２０８は、更新通知部２１２を含む。更新通知部２１２は、エンティティに含まれるデータが更新されたとき、このエンティティのメンバーを対象として更新があった旨を通知する（図１７等に関連して後述）。

データ処理部２０４は、ユーザ画面提供部２１４、フォーム設定部２１６、エンティティ設定部２１８、メンバー設定部２２０、エンティティ更新部２２２、対応登録部２２４、検索部２２６、友達設定部２２８およびジャンル設定部２２９を含む。

ユーザ画面提供部２１４は、各種のユーザ画面を生成し、ユーザ端末１１０に提供する。ユーザ画面はウェブページとして提供される。フォーム設定部２１６は、ユーザからの指示にしたがってフォームを作成する。フォームにはフォームＩＤが付与される。エンティティ設定部２１８は、ユーザからの指示にしたがってエンティティを作成する。エンティティにはエンティティＩＤと、エンティティが由来するフォームのフォームＩＤが付与される。

メンバー設定部２２０は、フォームに対するメンバーを設定する。フォームの作成者は、他のユーザをメンバーとして招待することで、フォームＩＤとメンバーのユーザＩＤを対応づける（図１０に関連して後述）。エンティティ更新部２２２は、ユーザからの指示にしたがって、エンティティに含まれるデータを更新する。対応登録部２２４は、ユーザからの指示にしたがって、フォームとフォームの対応づけを行う（以下、「対応設定」とよぶ）（図１４に関連して後述）。検索部２２６は、ユーザからの検索指示にしたがって、フォームあるいはエンティティを検索する。

友達設定部２２８は、ユーザ間の友達設定を管理する。友達の設定方法は一般的なＳＮＳ（Social Networking Service）と同様である。たとえば、ユーザＰ１は、サーバ２００に登録されているユーザから友達になりたいユーザＰ２を選択し、「友達申請」を送信する。ユーザＰ２が「承認」すれば、友達設定部２２８はユーザＰ１とユーザＰ２を「友達」として登録する。ジャンル設定部２２９は、フォームのグループとして「ジャンル」を設定する（図１８に関連して後述）。

図３は、ユーザ端末１１０の機能ブロック図である。
ユーザ端末１１０は、ユーザインタフェース処理部１１４、データ処理部１１６、通信部１１８およびデータ格納部１２０を含む。

通信部１１８は、通信処理を担当する。ユーザインタフェース処理部１１４は、ユーザからの操作を受け付けるほか、画像表示や音声出力など、ユーザインタフェースに関する処理を担当する。データ格納部１２０は各種データを格納する。データ処理部１１６は、通信部１１８およびユーザインタフェース処理部１１４により取得されたデータおよびデータ格納部１２０に格納されているデータに基づいて各種処理を実行する。データ処理部１１６は、ユーザインタフェース処理部１１４、通信部１１８およびデータ格納部１２０のインタフェースとしても機能する。

通信部１１８は、サーバ２００に各種データを送信する送信部１３４とサーバ２００からデータを受信する受信部１３６を含む。ユーザからの入力結果は、送信部１３４によりサーバ２００に適宜送信される。

ユーザインタフェース処理部１１４は、ユーザからの入力を受け付ける入力部１２２とユーザに各種情報を出力する出力部１２４を含む。
入力部１２２は、フォーム作成入力部１２５、エンティティ作成入力部１２８、メンバー入力部１３０、対応入力部１３２およびジャンル作成入力部１３３を含む。フォーム作成入力部１２５は、フォームの作成および更新を受け付ける。フォーム作成入力部１２５は項目入力部１２６を含む。項目入力部１２６は、フォームの「項目（後述）」の有効／無効設定を受け付ける。エンティティ作成入力部１２８は、エンティティの作成および更新を受け付ける。メンバー入力部１３０は、フォームにメンバーを対応づける設定を受け付ける。対応入力部１３２は、フォームとフォームの対応設定を受け付ける。ジャンル作成入力部１３３は、ジャンルの作成および更新を受け付ける。

出力部１２４は、更新通知部１２９を含む。更新通知部１２９は、エンティティの更新をユーザに画面上にて通知する。詳細は図１７に関連して後述する。

図４は、フォームとエンティティの関係を説明するための模式図である。
上述したように、エンティティは情報集合であり、フォームはエンティティのデータ構造（形式）を定義する規格（型枠）である。フォームに対してはあらかじめ多数の項目が用意されている（以下、「基礎項目群」とよぶ）。詳細は後述するが、フォームの作成に際しては基礎項目群から使用したい項目を選んで有効化することで、エンティティのデータの種類と量を定義できる。

たとえば、フォームＦａが項目１、項目２、項目３を有効化しているときには、フォームＦａから作られるエンティティＥａ１も項目１、項目２、項目３を含み、これら３つの項目に対応するデータ（以下、「項目データ」とよぶ）が設定される。また、フォームＦｂが項目１、項目４、項目５、項目６、項目７を有効化しているときには、フォームＦｂから作られるエンティティＥｂ１も項目１、項目４、項目５、項目６、項目７を含み、５つの項目データを含む。エンティティＥａ１に比べるとエンティティＥｂ１はデータ量が多く、項目１、項目４、すなわち、データ構造の一部は共通している。

このように、フォーム（規格）から、エンティティ（実体）がつくられる。１つのフォームから複数のエンティティをつくることができる。図４においては、フォームＦ１から３つのエンティティＥ１１、Ｅ１２、Ｅ１３が作成されている。また、フォームＦ２からは１つのエンティティＥ２１、Ｅ２２が作成されている。

本実施形態におけるエンティティは、子供服製作に関わる多数の工程のうちの１工程のスケジュールを管理するための情報集合である。以下、フォームＦ１は「量産入荷予定」に対応し、エンティティＥ１１は「袴ａの量産入荷予定」、エンティティＥ１２は「レッスンバッグｂの量産入荷予定」、エンティティＥ１３は「お弁当袋ｃの量産入荷予定」であるとする。また、フォームＦ２は「設計パターン製作」に対応し、エンティティＥ２１は「袴ａの設計パターン製作」、エンティティＥ２２は「エプロンｄの設計パターン製作」であるとする。

たとえば、子供服の量産入荷予定のスケジュールを管理する場合、「量産入荷予定」のためのフォームＦ１をつくる。次に、袴ａの量産入荷予定を管理するためにフォームＦ１（量産入荷予定）からエンティティＥ１１（袴ａの量産入荷予定）をつくる。レッスンバッグｂについても同一のフォームＦ１から別のエンティティＥ１２（レッスンバッグｂの量産入荷予定）をつくることができる。エンティティ１１（袴ａの量産入荷予定）とエンティティ１２（レッスンバッグｂの量産入荷予定）は同じフォームＦ１（量産入荷予定）からつくられているので、２つのエンティティの項目データ（コンテンツ）は異なるがデータ構造（項目）は同じである。フォームによってデータ構造を定義することにより、エンティティのデータ構造を共通化・規格化できるので、情報視認性を高めることができる。

上述したように、フォームには１以上のメンバー（ユーザ）が対応づけられる。図４においてはフォームＦ１（量産入荷予定）のメンバーは、ユーザＰ１、Ｐ２、Ｐ３の３人である。フォームＦ１（量産入荷予定）に由来するエンティティＥ１１、Ｅ１２、Ｅ１３へのアクセス権限者はユーザＰ１、Ｐ２、Ｐ３に限定される。

同様にして、フォームＦ２（設計パターン製作）のメンバーは、ユーザＰ１、Ｐ４である。フォームＦ２（設計パターン製作）に由来するエンティティＥ２１（袴ａの設計パターン製作）とエンティティＥ２２（エプロンｄの設計パターン製作）へのアクセス権限者はユーザＰ１、Ｐ４に限定される。

したがって、ユーザＰ２、Ｐ３はエンティティＥ１１、Ｅ１２、Ｅ１３にアクセスできるが、エンティティＥ２１、Ｅ２２にはアクセスできない。ユーザＰ１はこれら５つのエンティティすべてにアクセスできる。ユーザＰ４はエンティティＥ２１、Ｅ２２のみへのアクセスが可能である。ユーザＰ５はこの図４にあるいずれのエンティティにもアクセスできない。

以上のように、フォームにメンバーを対応づけることで、そのフォームに由来するエンティティへのアクセス権限者を限定できる。このため、プロジェクトに関わる個々のユーザ（関係者）に対して、伝えるべき情報と伝える必要がない情報、伝えてはいけない情報を分けることができる。情報共有性を高めつつ、不必要な情報の提供を制限することで情報過剰にともなうストレスを軽減できる。また、エンティティへのアクセス権限を設定することは、情報漏洩を防止する上でも有効である。

図５は、フォームの対応設定を説明するための模式図である。
ユーザは、フォームとフォームを対応づけることができる。図５においては、ユーザＰ１はフォームＦ１（量産入荷予定）にフォームＦ２（設計パターン製作）を対応づけたとする。このとき、対応づける側のフォームＦ２を「関連フォーム」とよぶ。また、対応づけられる側のフォームＦ１を「上位フォーム」とよぶ。

フォームＦ１にフォームＦ２を対応づけることにより、フォームＦ１に由来するエンティティＥ１１（袴ａ）、Ｅ１２（レッスンバッグｂ）、Ｅ１３（お弁当袋ｃ）のうち、エンティティＥ１１（袴ａ）に対して、フォームＦ２に由来するエンティティＥ２１（袴ａ）が対応づけられる。この場合、エンティティＥ２１を「関連エンティティ」、エンティティ１１を「上位エンティティ」とよぶ。対応登録部２２４は、上位エンティティの選択時において、「袴ａ」のような一部の項目データが共通する関連エンティティをサーチする（詳細後述）。

より具体的には、ユーザＰ１がエンティティＥ１１（袴ａの量産入荷予定：上位エンティティ）を表示させるとき、エンティティＥ２１（袴ａの設計パターン製作：関連エンティティ）も付随表示される。このため、ユーザＰ１は袴ａの量産入荷予定について確認するときには、あわせて、袴ａの設計パターン製作に関する進捗状況も確認できる（図１５に関連して後述）。

フォームの対応設定はユーザごとに行われる。たとえば、ユーザＰ１がフォームＦ１にフォームＦ２を対応づけることは、他のユーザへの情報提供方法には影響しない。したがって、ユーザＰ４がエンティティＥ１１（袴ａの量産入荷予定）を表示させるとき、ユーザ画面提供部２１４はエンティティＥ２１（袴ａの設計パターン製作）を関連エンティティとして付随表示させない。ユーザは、自分の職域や個人的なわかりやすさ等に鑑みて、複数のフォームを自由に対応づけることができる。

ユーザＰ１がフォームＦ１（量産入荷予定）にフォームＦ２（設計パターン製作）を対応づけた場合、エンティティＥ２１（袴ａの設計パターン製作）を表示させるときにはエンティティＥ１１（袴ａの量産入荷予定）は関連エンティティとして表示されない。フォームＦ２はフォームＦ１の関連フォームであるが、フォームＦ１はフォームＦ２の関連フォームではないためである。このように、対応設定は一方向性を有する。

ユーザＰ１が、更に、フォームＦ２（設計パターン製作）にフォームＦ１（量産入荷予定）を対応づけた場合、フォームＦ１とフォームＦ２はお互いの関連フォームかつ上位フォームとなる。この場合、ユーザＰ１がエンティティＥ２１（袴ａの設計パターン製作）を表示させるときにはエンティティＥ１１（袴ａの量産入荷予定）も関連エンティティとして付随表示される。
以下、ユーザ画面を中心として主要処理の流れを説明する。

図６は、ホーム画面１５０の画面図である。
ユーザが、ユーザ端末１１０からサーバ２００にアクセスするとき、まず、ユーザＩＤ（メールアドレス）とパスワードを入力することにより、ユーザ登録を行う。ユーザ登録後にサーバ２００にアクセスすると、サーバ２００のユーザ画面提供部２１４はホーム画面１５０をユーザ端末１１０に表示させる。

本実施形態における「ユーザ画面」は、ホーム画面１５０などのサーバ２００からユーザ端末１１０に提供される複数種類の画面の総称である。ユーザ画面の下部には、ホームボタン１５２、フォームボタン１５４、ユーザボタン１５６、ジャンルボタン１５８およびカスタムボタン１６０が表示される。ユーザは、ホームボタン１５２をタッチすることによりいつでもホーム画面１５０を表示させることができる。フォームボタン１５４等については後述する。

ホーム画面１５０の中央には検索領域１６２が表示される。ユーザが検索領域１６２に検索ワードを入力すると、検索ワードは情報管理システム１００からサーバ２００に送信される。検索部２２６は検索ワードを含むフォームまたはエンティティを検索する。ユーザ画面提供部２１４は検索結果をユーザ端末１１０に表示させる。
以下においては、ユーザＰ１がフォームＦ１を作成すると想定して説明する。

図７は、フォーム作成画面１７０の画面図である。
ユーザＰ１がフォームボタン１５４をタッチしたあと、画面表示される新規作成ボタン（図示せず）をタッチしたとき、ユーザ画面提供部２１４はフォーム作成画面１７０をユーザ端末１１０に表示させる。フォーム作成画面１７０の中央にはフォーム名領域１７２が表示される。ユーザは、フォーム名領域１７２にフォームＦ１のフォーム名を入力する。図７においては「量産入荷予定」というフォーム名が入力されている。フォーム名は任意である。キャンセルボタン１７４をタッチするとフォームの作成はキャンセルされる。ユーザＰ１が保存ボタン１７６をタッチすると、フォーム設定部２１６は新規フォームを作成する。フォーム設定部２１６は、フォームＩＤを生成し、フォームＩＤ（フォームＦ１）、フォーム名（量産入荷予定）および作成者（ユーザＰ１）を対応づけてデータ格納部２０６に登録する。

図８は、フォーム第１定義画面１８０の画面図である。
フォームＦ１が新規作成されたとき、ユーザ画面提供部２１４はフォーム第１定義画面１８０を表示させる。ユーザは、フォーム第１定義画面１８０においてフォームＦ１のデータ構造、すなわち、有効な項目と無効な項目を定義する。ユーザＰ１は、カスタムボタン１６０をタッチすることにより、フォーム第１定義画面１８０を表示させることができる。

名称変更ボタン１８２をタッチすると、フォームの名称を変更できる。対応設定ボタン１８４をタッチすると対応設定、すなわち、関連フォームの選択が可能である（図１４に関連して後述）。

公開ボタン１８６をタッチすると、一般公開または限定公開を選択できる。一般公開の場合には、メンバーを限定することなくフォームＦ１に由来するエンティティ（以下、「エンティティ（Ｆ１）」のように表記することがある）へのアクセスを制限しない。この場合、エンティティ設定部２１８は、エンティティ（Ｆ１）は通常のウェブページとして公開させてもよい。

項目定義ボタン１８８をタッチすると、基礎項目群からフォームＦ１において有効化すべき項目（以下、「有効項目」ともよぶ）を選択できる。詳細は、次の図９に関連して説明する。

図９は、フォーム第２定義画面１９０の画面図である。
図８のフォーム第１定義画面１８０において、項目定義ボタン１８８がタッチされたとき、ユーザ画面提供部２１４はフォーム第２定義画面１９０を表示させる。フォーム第２定義画面１９０は、基礎項目群を一覧表示させる。ユーザＰ１は、基礎項目群からフォームＦ１に必要な項目、すなわち、有効項目を選択する。ユーザＰ１は、各項目のオン（有効化）とオフ（無効化）を選ぶ。オン設定された項目はフォームＦ１の有効項目となる。項目入力部１２６は、項目のオン／オフを検出し、ユーザ端末１１０の送信部１３４は選択結果をサーバ２００に送信し、フォーム設定部２１６は選択結果にしたがってフォームＦ１の有効項目を登録する。

あらかじめ複数の項目が基礎項目群として用意されているため、ユーザはその中から有効項目を選ぶだけでフォーム（エンティティ）に含まれる情報の量と質を制御できる。いずれのフォームも基礎項目群に基づくため、フォーム作成者によってフォームのデータ構造がばらつきにくいというメリットもある。項目選択方式により、フォームの作成のしやすさ、フォーム作成の自由度とともに全体としてのデータ構造の統一性を実現できる。

図１０は、メンバー登録画面２３０の画面図である。
フォームＦ１の選択したあと、画面表示されるメンバー追加ボタン（図示せず）を選ぶことで、ユーザＰ１は、フォームＦ１にメンバーを追加できる。メンバーとなるユーザは、サーバ２００にユーザ登録しているユーザであって、フォームの作成者であるユーザＰ１に対して「友達」として登録されているユーザが対象となる。

たとえば、ユーザＰ１がフォームＦ１を作成したあと、画面右隅などの所定位置に表示されるメンバー追加ボタンをタッチすると、友達設定部２２８はユーザＰ１の「友達」となっているユーザをメンバー候補として選抜する。図１０のメンバー登録画面２３０によれば、編集対象となっているフォームＦ１については、ユーザＰ１のほかに二人、すなわち、合計３名がメンバーとして登録されている。ユーザＰ１は、退会ボタン２３２をタッチすることで自主的にフォームＦ１のメンバーからはずれることもできる。メンバー入力部１３０が退会ボタン２３２のタッチを検出したとき、メンバー設定部２２０はフォームのメンバーリストから退会ボタン２３２をタッチしたユーザを外す。

ユーザＰ１が招待ボタン２３４をタッチしたとき、メンバー設定部２２０はユーザＰ１の友達リストを表示させる（図示せず）。ユーザＰ１はこの友達リストから招待したいユーザ、いいかえれば、フォームＦ１の新たなメンバーを選択する。

また、メンバー名をタッチすることにより、メンバーに項目データの閲覧のみを許可するか、編集（項目データの入力および変更）を許可するかを設定できる。メンバー設定部２２０は、フォームごとにメンバーおよび編集権限の有無を対応づけてデータ格納部２０６に登録する。

図１１は、エンティティ作成画面２４０の画面図である。
作成済みのフォームＦ１を選択したあと、ユーザが画面右隅に表示される新規作成ボタン（図示せず）をタッチしたとき、ユーザ画面提供部２１４はフォームＦ１に基づくエンティティを作成するためのエンティティ作成画面２４０を表示させる。フォームＦ１の有効項目に対して項目データを入力することでエンティティＥ１１等を生成する。
以下においては、ユーザＰ１が、フォームＦ１（量産入荷予定）に基づいてエンティティＥ１１（袴ａの量産入荷予定）を作成するものとして説明する。

エンティティ作成入力部１２８は、エンティティ作成画面２４０に対する項目データの入力を検出する。ユーザ端末１１０の送信部１３４は、入力された項目データを項目ＩＤとともにサーバ２００に送信する。サーバ２００のエンティティ設定部２１８は、エンティティ作成時にエンティティＩＤを設定する。エンティティ設定部２１８は、フォームＩＤ、エンティティＩＤおよび項目ＩＤとともに項目データを登録する。

エンティティ名称領域２４２は、エンティティ名を入力するための領域である。エンティティ名称領域２４２は常に有効項目であり、図１１においては「新作袴セット入荷」と入力されている。このエンティティＥ１１は、フォームＦ１「量産入荷予定」に基づく「新作袴セット（袴ａ）」の「量産入荷予定」に関する情報集合となる。

写真領域２４４は、写真を登録するための領域である。スケジュール領域２４６は、エンティティのスケジュールとして開始日と終了日を登録するための領域である。スケジュール領域２４６も常に有効項目である。写真を登録することは必須ではない。品番領域２４８は、品番を入力するための領域である（図９参照）。品番領域２４８は、有効／無効を選択可能である。図１１においては袴ａに対応する品番「１２０７４」が入力されている。ロット領域２５０は、ロットを入力するための領域である（図９参照）。ユーザＰはエンティティ作成画面２４０をスクロールさせながら他の有効項目の項目データを入力する。このほかにもさまざまな項目を有効化可能である。ユーザＰ１は、エンティティ作成画面２４０をスクロールさせることでエンティティＥ１１のすべての項目データを入力・確認できる。

ユーザが削除ボタン２５２をタッチすると、作成中のエンティティＥ１１は保存されることなく削除される。また、作成済みのエンティティを編集するときであっても、削除ボタン２５２がタッチされるとエンティティ設定部２１８はエンティティを削除する。キャンセルボタン２５４をタッチすると、エンティティは残るが新たに入力した項目データは登録されることなく破棄される。複製ボタン２５６をタッチすることによりエンティティを複製できる。保存ボタン２５８をタッチすると、エンティティ設定部２１８はフォームＦ１に基づくエンティティＥ１１をデータ格納部２０６に正式に登録する。

図１２は、フォームリスト画面２７０の画面図である。
いくつかのフォームを作成したあと、あるいは、他のユーザが作成したフォームにメンバーとして参加したあと、フォームボタン１５４をタッチするとフォームのリストが表示される。フォームリスト画面２７０は、作成フォーム領域２７２と参加フォーム領域２７４に分割される。

ユーザＰ１のユーザ端末１１０においては、作成フォーム領域２７２はユーザＰ１が作成したフォームがリスト表示される。参加フォーム領域２７４は、ユーザＰ１以外のユーザが作成したフォームのうち、ユーザＰ１がメンバーとなっているフォームがリスト表示される。図７のフォーム作成画面１７０においてユーザＰ１が作成したフォームＦ１（量産入荷予定）は作成フォーム領域２７２に表示されている。

サーバ２００のフォーム設定部２１６は、多数のユーザからのフォーム作成指示により多数のフォームをつくる。フォーム設定部２１６は、上述したように、フォームＩＤ、フォームの作成者、メンバー、有効項目を対応づけてデータ格納部２０６に登録する。ユーザ画面提供部２１４は、ユーザＰ１のユーザ端末１１０に対しては、ユーザＰ１がメンバーとなっていないフォームは表示させない。ユーザＰ１は自分に関係のないフォームやエンティティを視認することはできない。このため、サーバ２００のデータ格納部２０６に蓄積される膨大な情報のうち、ユーザＰ１に必要な情報だけを選んでユーザＰ１に提供できる。

図１３は、エンティティリスト画面２８０の画面図である。
図１３に示すエンティティリスト画面２８０は、ユーザＰ１がフォームリスト画面２７０（図１２参照）において、フォームＦ１（量産入荷予定）をタッチしたときに表示される。ここでは、フォームＦ１に基づいて多数のエンティティＥ１１、Ｅ１２が作成済みであるとする。エンティティリスト画面２８０は、フォームＦ１（量産入荷予定）に由来するエンティティをサムネイル（抄本画像）としてリスト表示する。

サムネイル２８２は、図１１のエンティティ作成画面２４０において作成したエンティティ（袴ａの量産入荷予定（エンティティ名：新作袴セット入荷））のサムネイルである。サムネイル２８２にはエンティティ作成画面２４０において入力した複数の項目データのうち、写真領域２４４の縮小画像、エンティティ名称領域２４２、スケジュール領域２４６、品番領域２４８等のほか進捗状態「未処理」など一部の項目データのみが表示される。ユーザＰ１はエンティティリスト画面２８０を参照することにより、フォームＦ１（量産入荷予定）に関わるエンティティのスケジュールや進捗状態等をまとめて確認できる。

エンティティリスト画面２８０において、ユーザＰ１がサムネイル２８２をタッチすると、エンティティ作成画面２４０に示したのと同様の表示形式にてエンティティＥ１１（袴ａの量産入荷予定）の項目データ群が詳細表示される。

図１４は、対応設定画面２９０の画面図である。
対応設定画面２９０は、ユーザＰ１はフォームＦ１（量産入荷予定）を選択したあと、フォーム第１定義画面１８０（図８）において「対応設定」をオンしたときに表示される。対応入力部１３２は対応設定のオンを検出し、送信部１３４は対応設定のオンをサーバ２００に通知し、サーバ２００のユーザ画面提供部２１４は対応設定画面２９０をユーザ端末１１０に表示させる。

ユーザ画面提供部２１４は、ユーザＰ１に関わる６つのフォーム（図１２参照）のうち、フォームＦ１（量産入荷予定）以外の５つのフォームをリスト表示する。各フォームにはチェックボックス２９２が設けられる。ユーザＰ１はフォームＦ１（量産入荷予定）に対応づけたいフォーム、いいかえれば、フォームＦ１（上位フォーム）の関連フォームのチェックボックス２９２にチェックをつける。複数のフォームにチェックをつけてもよい。

図１４においては、ユーザＰ１はフォームＦ２（設計パターン製作）にチェックをつけている。この状態で、ユーザＰ１が保存ボタン２９６をタッチすると、フォームＦ２（設計パターン製作）はフォームＦ１（量産入荷予定：上位フォーム）の関連フォームとなる。ユーザ端末１１０の送信部１３４は、これら２種類のフォームの関連づけをサーバ２００に通知し、サーバ２００の対応登録部２２４は２種類のフォームを対応づけて登録する。ユーザＰ１がキャンセルボタン２９４をタッチしたときにはフォームの対応設定はなされない。

対応設定はユーザ単位で行われる。このため、ユーザＰ１がフォームＦ１（上位フォーム）にフォームＦ２（関連フォーム）を対応づけたとしても、他のユーザの情報管理には影響しない。上述したように、フォームＦ２（設計パターン製作）はフォームＦ１（量産入荷予定）の関連フォームとなるが、フォームＦ１（量産入荷予定）はフォームＦ２（設計パターン製作）の関連フォームとはならない。このように対応設定は一方向性を有するため、複数のフォームあるいはそれらに由来するエンティティに階層性をもたせることができる。図１４においては、ユーザＰ１はフォームＦ１（量産入荷予定）に由来するエンティティを確認するとき、その関連フォームＦ２（設計パターン製作）に由来するエンティティの進捗をあわせて確認できる。詳細は次の図１４に関連して後述する。

ユーザＰ１がフォームＦ２（設計パターン製作）とフォームＦ１（量産入荷予定）を相互に対応づけたいときには、ユーザＰ１はフォームＦ２を上位フォームとして選択し、対応設定画面２９０においてフォームＦ１（関連フォーム）を対応づければよい。以下、ユーザＰ１について、フォームＦ１は上位フォーム、フォームＦ２はその関連フォームであるとして説明する。

図１５は、エンティティ閲覧画面３００の画面図である。
図１５のエンティティ閲覧画面３００は、ユーザＰ１がエンティティＥ１１（袴ａの量産入荷予定）をエンティティリスト画面２８０で選択したときに表示される。エンティティ閲覧画面３００においてはエンティティＥ１１の項目データを確認できる。エンティティ閲覧画面３００の最下部には関連エンティティ領域３０２が表示される。

ユーザＰ１は、フォームＦ１（量産入荷予定）にフォームＦ２（設計パターン製作）を対応づけている（図１４参照）。フォームＦ１（上位フォーム）からはエンティティＥ１１が作られ、フォームＦ２（関連フォーム）からはエンティティＥ２１（袴ａの設計パターン（エンティティ名：新作袴の型紙づくり））がつくられたとする。この場合、エンティティＥ２１（袴ａの設計パターン）は、エンティティＥ１１（袴ａの量産入荷予定（エンティティ名：新作袴セット入荷））の関連エンティティとなる。ユーザＰ１がエンティティＥ１１（上位エンティティ）を表示させるとき、エンティティ閲覧画面３００の下部の関連エンティティ領域３０２にはエンティティＥ２１が関連エンティティとして表示される。

ユーザ画面提供部２１４は、エンティティＥ１１の表示に際しては、関連フォームのほかに「キー項目」の項目データである「キーデータ」もチェックする。基礎項目群のうち一部の項目はあらかじめキー項目として設定されている。本実施形態においては項目「品番」がキー項目（図１１の品番領域２４８参照）である。

ユーザ画面提供部２１４は、ユーザＰ１によりエンティティＥ１１（上位エンティティ）が選択されたとき、まず、エンティティＥ１１が由来するフォームＦ１（上位フォーム）の関連フォームであるフォームＦ２を特定する。次に、フォームＦ２（関連フォーム）に由来するエンティティＥ２１、Ｅ２２を特定する。エンティティＥ１１（上位エンティティ）のキー項目（品番）の項目データは「１２０７４（袴ａ）」である（図１１参照）。ユーザ画面提供部２１４は、エンティティＥ２１、Ｅ２２のキー項目（品番）をチェックし、エンティティＥ１１と同じく品番が「１２０７４」であるエンティティＥ１１（袴ａの設計パターン製作）を関連エンティティとして特定する。このような制御方法によれば、ユーザＰ１は同一品番（同一製品）を対象として、あるエンティティを確認しているときにそれに関連する別のエンティティの情報も確認できる。

図１５においては、ユーザＰ１は袴ａ（品番：１２０７４）の量産入荷予定を確認しているとき、同じ袴ａの設計パターン製作の進捗状態も確認できる。ユーザＰ１が関連エンティティ領域３０２をタッチしたときには、エンティティＥ２１（袴ａの設計パターン製作（エンティティ名：新作袴の型紙づくり））が詳細表示される。

図１６は、エンティティ表示の処理過程を示すフローチャートである。
ユーザは、まず、フォームリスト画面２７０においてフォームを選択し、この選択したフォームに由来するエンティティをサムネイルによって示すエンティティリスト画面２８０を表示させる（Ｓ１０）。具体的には、ユーザ端末１１０の送信部１３４は、フォームＩＤとユーザＩＤをサーバ２００に送信し、サーバ２００のユーザ画面提供部２１４はエンティティリスト画面２８０のウェブページを生成してユーザ端末１１０に送信する。ユーザは、エンティティリスト画面２８０において詳細表示させたいエンティティを選択する（Ｓ１２）。

ユーザ画面提供部２１４は、関連フォームを検索する。関連フォームがあれば（Ｓ１４のＹ）、ユーザ画面提供部２１４は、キーデータをチェックする（Ｓ１６）。関連フォームがなければ（Ｓ１４のＮ）、処理はＳ２０にスキップする。キーデータが一致するエンティティが存在するとき（Ｓ１６のＹ）、関連エンティティ領域３０２に関連エンティティを追加する（Ｓ１８）。キーデータが一致するエンティティが存在しなければ（Ｓ１６のＮ）、別のエンティティをチェックする。すべてのエンティティをチェックしたあと（Ｓ１４のＮ）、ユーザ画面提供部２１４はエンティティ閲覧画面３００を画面表示させる（Ｓ２０）。

図１７は、更新通知時のフォームリスト画面２７０の画面図である。
フォームのメンバーのうち、編集権限を与えられたユーザは（図１０参照）、そのフォームに由来するエンティティの項目データを書き換えることができる。たとえば、ユーザＰ２がエンティティＥ１１の項目データを書き換えたとする。このとき、エンティティ更新部２２２はエンティティＥ１１の項目データを変更・登録するとともに、更新通知部２１２に対して更新通知の送信を指示する。

エンティティ更新部２２２は、エンティティＥ１１のメンバーとしてユーザＰ１、Ｐ２、Ｐ３を特定する（図４参照）。ユーザＰ２による更新であるため、エンティティ更新部２２２はユーザＰ１、Ｐ３を対象とした更新通知を指示する。更新通知部２１２は、エンティティＥ１１のエンティティＩＤとともに更新通知をユーザＰ１、Ｐ３のユーザ端末１１０へ送信する。

ユーザ端末１１０の更新通知部１２９は、まず、フォームボタン１５４に更新マーク３１２を表示させる。また、エンティティＥ１１の元であるフォームＦ１（量産入荷予定）の横にも更新マーク３１２を表示させる。ユーザＰ１がフォームＦ１を選択し、エンティティをサムネイル表示させたときには、エンティティＥ１１に対応する位置に更新通知部１２９は更新マーク３１２を表示させる。更新マーク３１２により、ユーザは、自分に関係するエンティティ（工程のスケジュールなど）に変化があったときには速やかに知ることができる。たとえば、進捗状況を示す項目データが「未処理」から「処理済」に変更されたときには、更新マーク３１２により状況の変化を認識し、リアルタイムにて自分に関わるスケジュールの進捗を確認できる。

図１８は、ジャンルとフォームの関係を説明するための模式図である。
フォームが増えてくると、フォームリスト画面２７０において情報の視認性が悪くなる可能性がある。そこで、本実施形態においてはフォームのグループとして「ジャンル」を定義する。ユーザは、ジャンルを作成し、１つのジャンルに対して複数のフォームを対応付けることができる。図１８においては、ジャンルＪ１（製作）に対して、フォームＦ１（量産入荷予定）、フォームＦ２（設計パターン製作）、フォームＦ３（試作）が対応づけられている。また、ジャンルＪ２（在庫管理）にはフォームＦ１（量産入荷予定）、Ｆ４（ネット販売）が対応づけられている。フォームＦ１のように、１つのフォームを複数のジャンルに対応づけてもよい。

図１９は、ジャンルを設定したときのフォームリスト画面２７０の画面図である。
ユーザは、ジャンルボタン１５８をタッチすることにより、ジャンル作成画面（図示せず）を表示させることができる。ジャンル作成画面においては、ジャンル名を入力するとともに、ジャンルに対応づけるフォームを選択する。図１４に示した対応設定画面２９０と同様のユーザインタフェースにより対応づけが行われる。ジャンル作成入力部１３３は、ユーザからの入力結果に基づいて、ジャンルＩＤとフォームＩＤを対応付ける。ジャンルもユーザごとに設定される。サーバ２００のジャンル設定部２２９は、ユーザＩＤ、ジャンルＩＤおよびフォームＩＤを対応付けることにより、ユーザごとにジャンルとフォームの関係を設定する。

図１９のフォームリスト画面２７０においては、ジャンルＪ１（製作）、ジャンルＪ２（在庫管理）、ジャンルＪ３（プライベート）の２つのジャンル名と「全てのフォーム」がリスト表示されている。ユーザがジャンルＪ１（製作）を選択したときには、ジャンルＪ１（製作）に対応づけられるフォームＦ１、Ｆ２、Ｆ３が図１２と同様の表示形式にてリスト表示される。ユーザが「全てのフォーム」を選択したときには、ユーザＰ１が関連する全てのフォームがリスト表示される。

ジャンルの設定は任意である。ユーザＰ１は、フォームボタン１５４をタッチしてフォームリスト画面２７０を表示させたあと、ジャンル、フォーム、エンティティの順に選択することで、複数のエンティティに含まれる情報に階層的にたどり着くことができる。

［総括］
以上、実施形態に基づいて情報管理システム１００を説明した。
情報管理システム１００によれば、ユーザは、１つのフォームを「規格（型枠）」にして複数のエンティティをつくることができる。フォームからエンティティをつくるので情報生産性が高くなる。フォームにはあらかじめ複数の項目（基礎項目群）が用意されており、ユーザはその中から有効項目を選択することでフォームのデータ構造を簡単に定義できる。いずれのフォームも基礎項目群がベースになるため、複数のフォームに統一性をもたせることができる。基礎項目群からフォームがカスタマイズされ、フォームから個別の情報集合としてのエンティティが生産される。

有効項目の種類および数により、エンティティの情報の質と量が決まる。たとえば、フォーム（量産入荷予定（全体））には品番やスケジュールなどの最低限の有効項目を含ませ、フォーム（量産入荷予定（現場））については価格や返品率、入荷時に確保すべき陳列棚の場所などの項目をきめ細かく有効化すればよい。この場合、マネージャーはフォーム（量産入荷予定（全体））に由来するエンティティを確認し、現場担当者はフォーム（量産入荷予定（詳細））に由来するエンティティを確認すればよい。このように、職掌・職位に基づいてユーザごとに必要な情報量を調整できる。

フォーム作成者は、フォームに対してメンバーを登録できる。フォームごとにアクセス権限者を設定することで、プロジェクトの複数の関係者それぞれに対して必要な情報を選別して提供できる。アクセス権限者を限定することはプロジェクトからの情報漏洩を防ぐ上でも有用である。たとえば、外部業者と協力してプロジェクトを進める場合でも、外部業者に提供すべき情報と提供する必要のない情報がある。この場合にも、フォームへのメンバー登録により、プロジェクトの内部情報が過度に外部業者に漏れるのを防止できる。

エンティティの項目データに更新があったときには、そのエンティティの関係者に対してすみやかに更新通知が送信される。このため、状況の変化を関係者が速やかに共有できる。

たとえば、あるプロジェクトのエンティティＥｘにおいて項目データが更新されたとき、このプロジェクトの関係者すべてに更新通知をしたとする。この場合、ほとんどのユーザにとってはこの項目データの更新は知る必要がないかもしれない。このため、このような方法を採用した場合、ユーザは更新通知をわずらわしく感じ、更新通知に注意を払わなくなる可能性がある。本実施形態においては、フォームにメンバーを対応づけることで、更新通知の対象者を限定できるので、無駄な更新通知を減らすことができる。これにより、ユーザは更新通知に注意を払いやすくなると考えられる。

フォームにメンバーを対応づけてもよいし、フォームを一般公開してもよい。たとえば、イベント企画に関するエンティティをつくり、関係者だけで作業を進める。作業が進んだところでエンティティのメンバーを拡大し、最終的には一般公開することでイベントに関する露出を順次拡大してもよい。このような制御方法によれば、エンティティを一般に対する広告宣伝のツールとして使うこともできる。

ユーザは、フォームとフォームの対応設定により、フォームおよびフォームに由来するエンティティを階層化できる。たとえば、エンティティＥＡの関連エンティティとしてエンティティＥＢを対応設定し、エンティティＥＢの関連エンティティとしてエンティティＥＣを対応設定したとする。この場合、エンティティＥＡを最上位、エンティティＥＢを中位、エンティティＥＣを下位とする情報の階層性を定義できる。個人単位でこのような階層化が可能であるため、たとえば、ユーザＰ１は自分なりの情報整理スタイルにしたがってエンティティを自由に階層化できる。ユーザに応じた柔軟な情報階層化により、ユーザにわかりやすく情報を提供できる。たとえば、エンティティＥＡを確認しているときに、関連するエンティティＥＢの進捗状況を確認する、といったワークフロー管理が可能となる。

なお、本発明は上記実施形態や変形例に限定されるものではなく、要旨を逸脱しない範囲で構成要素を変形して具体化することができる。上記実施形態や変形例に開示されている複数の構成要素を適宜組み合わせることにより種々の発明を形成してもよい。また、上記実施形態や変形例に示される全構成要素からいくつかの構成要素を削除してもよい。

［変形例］
本実施形態においては、子供服のデザインに関するプロジェクトのスケジュール管理を想定して説明した。子供服に限らず、ソフトウェア開発、製品プロモーション、スポーツイベントの企画など、複数のユーザによる情報共有を前提とする場面であれば情報管理システム１００は幅広く応用可能である。

本実施形態においては、フォームにメンバーを対応づけるとして説明した。変形例として、メンバー設定部２２０はフォームではなくエンティティごとにメンバーを対応づけてもよい。たとえば、メンバー設定部２２０はフォームＦ１に由来するエンティティＥ１１にはユーザＰ１、Ｐ２を対応づけ、同じフォームＦ１に由来するエンティティＥ１２にはユーザＰ１，Ｐ３を対応づけてもよい。このような制御方法によれば、フォーム単位ではなくエンティティ単位にてアクセス権限者を調整できる。

本実施形態においては、フォームを一般公開対象として説明した。変形例として、フォームではなくエンティティごとに一般公開の有無を決定してもよい。

本実施形態においては、フォームとフォームの間で対応設定をするとして説明した。変形例として、エンティティとエンティティの間で対応設定を可能としてもよい。

エンティティ更新部２２２は、キー項目に基づいて、更新通知先を選択してもよい。たとえば、項目「品番」が「１３０６８」を含むエンティティＥＹの他の項目データ（例：スケジュール開始日）が更新されたとする。このとき、エンティティ更新部２２２は、品番「１３０６８」をキーデータとして含むすべてのエンティティを検出し、これらのエンティティのメンバーを更新通知の対象として設定してもよい。このように、エンティティ単位ではなく、項目単位にて更新通知の対象を選択してもよい。

エンティティの更新者は、項目データの入力に際して、更新要否を入力してもよい。たとえば、ユーザＰ１がエンティティＥ１６の項目Ｑ１の項目データを変更したとする。このとき、情報管理システム１００の出力部１２４は、更新通知の要否をユーザＰ１に確認する。ユーザＰ１が「通知必要」と入力したとき、エンティティ更新部２２２はエンティティＥ１６のメンバーに更新通知させる。「通知不要」と入力したときには、エンティティ更新部２２２は項目Ｑ１の更新をメンバーに通知させない。このような制御方法によれば、些細な更新によって更新通知が頻発するのを防ぐことができる。

フォームの作成時において、ユーザは通知項目と非通知項目を設定してもよい。項目データが更新されたとき、更新通知部２１２は通知項目の項目データが更新されたときには通知し、非通知項目の項目データが更新されたときには通知しないとしてもよい。このような制御方法によれば、重要度の低い項目について項目データが変更されたときには更新通知をしないようにできるので、重要ではない更新によって更新通知が頻発するのを防ぐことができる。

複数種類の更新通知を設定してもよい。たとえば、重要通知の場合には更新マーク３１２のサイズを大きく表示させ、準重要通知のときには更新マーク３１２を小さく表示させるとしてもよい。また、これに合わせて、フォームの作成時においては、重要通知項目、準重要通知項目、非通知項目を設定してもよい。

本実施形態においては、フォームの対応設定はユーザごとに行われるとして説明した。たとえば、ユーザＰ１がフォームＦ１とフォームＦ４を対応づけたとしても、ユーザＰ２についてはフォームＦ１とフォームＦ４の対応設定はなされない。変形例として、フォームの対応設定は共通化されてもよい。たとえば、フォームＦ１の作成者がフォームＦ１とフォームＦ４を対応づけたときには、すべてのユーザについて同様の対応設定がなされるとしてもよい。

キー項目は複数あってもよい。たとえば、２つのキー項目Ｑ１、Ｑ２が設定されるとする。ユーザ画面提供部２１４は、キー項目Ｑ１、Ｑ２それぞれのキーデータが完全一致することを条件として関連エンティティを選ぶとしてもよいし、１つでも一致していれば関連エンティティとして選ぶとしてもよい。

サーバ２００のエンティティ設定部２１８は、アクセスの少ないエンティティの削除をエンティティ作成者に提案してもよい。たとえば、エンティティＥ３５が作成されてから１年以上、編集も閲覧もされていないときには、エンティティ設定部２１８はエンティティＥ３５を作成したユーザに対して削除提案を送信してもよい。ユーザが削除に同意したとき、エンティティ設定部２１８はこのエンティティＥ３５を削除する。このような制御方法によれば、大量のエンティティが作成されたあとも不要化したエンティティを合理的に削除することで、不必要な情報が蓄積するのを防ぎやすくなる。

フォーム設定部２１６はエンティティをもたないフォームの削除を提案してもよい。エンティティ設定部２１８は、古いスケジュールに関わるエンティティ、たとえば、１年以上前のスケジュールに関わるエンティティの削除を提案してもよい。

検索部２２６は、ホーム画面１５０の検索領域１６２に入力された検索ワードにしたがってエンティティを検索する。たとえば、ユーザが検索領域１６２に検索ワードを入力したときには、この検索ワードを項目データとして含むエンティティのうち、検索者がメンバーとなっているエンティティを検出してもよい。

情報管理システム１００のユーザ端末１１０は、フォームの階層関係、エンティティの階層関係、あるいは、ジャンルとフォームの関係を図４，図５，図１８に示したように図案化し、可視化表示してもよい。

フォームあるいはエンティティのメンバーは１人ずつではなく、複数人をその属性に基づいてまとめて対応づけてもよい。たとえば、フォームＦ６に対して、マーケティング部に所属するすべてのユーザをまとめて対応づけてもよい。このように、「マーケティング部所属」というユーザ属性を用意しておき、ユーザ属性に基づいてメンバーを設定してもよい。このような制御方法によれば、あるユーザＰ５がマーケティング部からはずれたときには、ユーザＰ５はそれ以後、マーケティング部に関連するエンティティへのアクセス権を失う。このような制御方法によれば、ユーザの所属変更に対応して、エンティティに対するアクセス権を適切に管理しやすくなる。

本実施形態においてはサーバ２００が存在することを前提として説明した。これは、複数のユーザ端末１１０により情報共有することを前提としている。グループではなく、個人的な情報管理に対しても本発明の一部は応用可能である。たとえば、フォームに基づくエンティティの作成、フォームの対応設定等の機能をユーザ端末１１０に実装し、ユーザ端末１１０だけでユーザのスケジュールや備忘録をエンティティ単位で管理してもよい。

［付記］
本実施形態に基づいて、更に、下記の発明が認識される。
Ｂ１．複数のユーザ端末と通信ネットワークを介して接続され、
ユーザ端末に対して、データ構造を定義するフォームおよびフォームにしたがって作成されるデータ集合体であるエンティティの双方を表示可能なユーザ画面を提供するユーザ画面提供部と、
ユーザ画面において、ユーザにより第１のフォームに第２のフォームが対応づけられたとき、前記第１のフォームに対する前記第２のフォームの対応を登録する対応登録部と、
ユーザ画面に対するユーザからのフォームの指定および前記指定されたフォームに基づくエンティティの作成がなされたとき、エンティティを作成するエンティティ設定部と、を備え、
前記ユーザ画面提供部は、前記第１のフォームに基づいて作成される第１のエンティティをユーザ画面に表示させるときには、前記第２のフォームに基づいて作成される第２のエンティティを前記第１のエンティティの関連エンティティとして表示させることを特徴とするサーバ。

Ｂ２．前記対応登録部は、第１のユーザが前記第１のフォームに前記第２のフォームを対応づけたとき、前記第１のフォーム、前記第２のフォームおよび前記第１のユーザを対応づけて登録し、
前記ユーザ画面提供部は、前記第１のエンティティを前記第１のユーザのユーザ画面に対して表示させるときには、前記第２のエンティティを前記第１のエンティティの関連エンティティとして表示させ、前記第１のフォームに前記第２のフォームを対応づけていない第２のユーザのユーザ画面に前記第１エンティティを表示させるときには、前記第２のエンティティを前記第１のエンティティの関連エンティティとして表示させないことを特徴とするＢ１に記載のサーバ。

Ｂ３．前記エンティティ設定部は、フォームに含まれる１以上の項目への項目データの入力を受け付けることにより、エンティティのデータ集合を設定し、
前記ユーザ画面提供部は、前記第１のエンティティにおけるキー項目の項目データと前記第２のエンティティに含まれる前記キー項目の項目データが一致することを条件として、前記第２のエンティティを前記第１のエンティティの関連エンティティとして表示させることを特徴とするＢ１またはＢ２に記載のサーバ。

Ｂ４．前記ユーザ画面提供部は、前記第１のフォームに前記第２のフォームが一方向にて対応づけられた場合において、前記第１のエンティティをユーザ画面に表示させるときには前記第２のエンティティを前記第１のエンティティの関連エンティティとして表示させ、前記第２のエンティティをユーザ画面に表示させるときには前記第１のエンティティを前記第２のエンティティの関連エンティティとして表示させないことを特徴とするＢ１からＢ３のいずれかに記載のサーバ。

Ｂ５．前記ユーザ画面提供部は、前記第１のフォームに前記第２のフォームが対応づけられ、かつ、前記第２のフォームに前記第１のフォームが対応づけられた場合には、前記第２のエンティティをユーザ画面に表示させるときにも前記第１のエンティティを前記第２のエンティティの関連エンティティとして表示させることを特徴とするＢ４に記載のサーバ。

Ｂ６．データ構造を定義するフォームおよびフォームにしたがって作成されるデータ集合体であるエンティティの双方を表示可能なユーザ画面を表示するユーザ画面表示部と、
ユーザ画面において第１のフォームに第２のフォームを対応づけるユーザからの指示を取得する対応入力部と、
ユーザ画面においてフォームに基づくエンティティの作成指示を取得するエンティティ作成入力部と、を備え、
前記ユーザ画面表示部は、前記第１のフォームに基づいて作成される第１のエンティティをユーザ画面に表示させるときには、前記第１のフォームに対応づけられる前記第２のフォームに基づいて作成される第２のエンティティを前記第１のエンティティの関連エンティティとして表示させることを特徴とするユーザ端末。

Ｂ７．前記ユーザ画面表示部は、前記第１のエンティティをユーザ画面に表示させるときには前記第２のエンティティを前記第１のエンティティの関連エンティティとして表示させ、前記第２のエンティティをユーザ画面に表示させるときには前記第１のエンティティを前記第２のエンティティの関連エンティティとして表示させないことを特徴とするＢ６に記載のユーザ端末。

Ｂ８．通信ネットワークを介して相互接続される１以上のユーザ端末とサーバを含み、
前記サーバは、
ユーザ端末に対して、データ構造を定義するフォームおよびフォームにしたがって作成されるデータ集合体であるエンティティの双方を表示可能なユーザ画面を提供するユーザ画面提供部と、
ユーザ画面において、第１のユーザにより、第１のフォームに第２のフォームが対応づけられたとき、前記第１のユーザ、前記第１のフォームおよび前記第２のフォームを対応づけて登録する対応登録部と、
ユーザ画面に対するユーザからのフォームの指定および前記指定されたフォームに基づくエンティティの作成がなされたとき、エンティティを作成するエンティティ設定部と、を備え、
前記ユーザ端末は、
ユーザ画面を表示するユーザ画面表示部と、
ユーザ画面において前記第１のフォームに前記第２のフォームを対応づけるユーザからの指示を取得する対応入力部と、
ユーザ画面においてフォームにおいてあらかじめ準備される項目に対する項目データの入力を受け付け、フォームに基づくエンティティの作成指示を取得するエンティティ作成入力部と、を備え、
前記サーバの前記ユーザ画面提供部は、前記第１のエンティティを前記第１のユーザのユーザ画面に対して表示させるときであって、前記第１のエンティティにおけるキー項目の項目データと前記第２のエンティティにおける前記キー項目の項目データが一致することを条件として、前記第１のフォームに対応づけられる前記第２のフォームに基づいて作成される第２のエンティティを前記第１のエンティティの関連エンティティとして表示させることを特徴とする情報管理システム。

１００ 情報管理システム、１０２ インターネット、１１０ ユーザ端末、１１４ ユーザインタフェース処理部、１１６ データ処理部、１１８ 通信部、１２０ データ格納部、１２２ 入力部、１２４ 出力部、１２５ フォーム作成入力部、１２６ 項目入力部、１２８ エンティティ作成入力部、１２９ 更新通知部、１３０ メンバー入力部、１３２ 対応入力部、１３３ ジャンル作成入力部、１３４ 送信部、１３６ 受信部、１５０ ホーム画面、１５２ ホームボタン、１５４ フォームボタン、１５６ ユーザボタン、１５８ ジャンルボタン、１６０ カスタムボタン、１６２ 検索領域、１７０ フォーム作成画面、１７２ フォーム名領域、１７４ キャンセルボタン、１７６ 保存ボタン、１８０ フォーム第１定義画面、１８２ 名称変更ボタン、１８４ 対応設定ボタン、１８６ 公開ボタン、１８８ 項目定義ボタン、１９０ フォーム第２定義画面、２００ サーバ、２０２ 通信部、２０４ データ処理部、２０６ データ格納部、２０８ 送信部、２１０ 受信部、２１２ 更新通知部、２１４ ユーザ画面提供部、２１６ フォーム設定部、２１８ エンティティ設定部、２２０ メンバー設定部、２２２ エンティティ更新部、２２４ 対応登録部、２２６ 検索部、２２８ 友達設定部、２２９ ジャンル設定部、２３０ メンバー登録画面、２３２ 退会ボタン、２３４ 招待ボタン、２４０ エンティティ作成画面、２４２ エンティティ名称領域、２４４ 写真領域、２４６ スケジュール領域、２４８ 品番領域、２５０ ロット領域、２５２ 削除ボタン、２５４ キャンセルボタン、２５６ 複製ボタン、２５８ 保存ボタン、２７０ フォームリスト画面、２７２ 作成フォーム領域、２７４ 参加フォーム領域、２８０ エンティティリスト画面、２８２ サムネイル、２９０ 対応設定画面、２９２ チェックボックス、２９４ キャンセルボタン、２９６ 保存ボタン、３００ エンティティ閲覧画面、３０２ 関連エンティティ領域、３１２ 更新マーク

Claims (8)

1. 複数のユーザ端末と通信ネットワークを介して接続され、
   ユーザ端末に対して、データ構造を定義するフォームおよびフォームにしたがって作成されるデータ集合体であるエンティティの双方を表示可能なユーザ画面を提供するユーザ画面提供部と、
   ユーザ画面に対するユーザからのフォームの選択および前記選択されたフォームに基づくエンティティの作成指示にしたがって、エンティティを作成するエンティティ設定部と、
   ユーザ画面に対するユーザからの指定にしたがって、フォームまたはエンティティのメンバーとなる１以上のユーザを設定するメンバー設定部と、
   ユーザ画面に対するユーザからのエンティティの指定と、前記指定されたエンティティの属性値の更新指示にしたがって、前記指定されたエンティティの項目データを更新するエンティティ更新部と、
   前記指定されたエンティティの更新をユーザ端末に通知する更新通知部と、を備え、
   前記ユーザ画面提供部は、ユーザ画面を提供するときには、複数のエンティティのうち、提供先のユーザがメンバーとして対応づけられるエンティティを表示対象として選抜し、
   前記更新通知部は、更新対象となったエンティティのメンバーを対象として更新を通知することを特徴とするサーバ。
2. ユーザ画面に対するユーザからのフォームの作成指示にしたがって、フォームを作成するフォーム設定部、を更に備え、
   前記フォーム設定部は、フォームにおいてあらかじめ準備されている複数の項目のうちユーザに指定された項目を有効化することでフォームのデータ構造を定義し、
   前記エンティティ設定部は、フォームにおいて有効化された項目に対する項目データの入力を受け付けることにより、エンティティのデータ集合を設定することを特徴とする請求項１に記載のサーバ。
3. 前記フォーム設定部は、ユーザからの指定にしたがって、フォームまたはエンティティの一般公開の可否を設定し、
   前記ユーザ画面提供部は、一般公開を可能として設定されたエンティティを公開のウェブページとして提供することを特徴とする請求項１または２に記載のサーバ。
4. エンティティは、製品またはサービスの開発プロジェクトに含まれる工程の管理単位であり、期限を含む日程情報と工程の進捗を示す進捗情報の双方をエンティティの属性値として含むことを特徴とする請求項１から３のいずれかに記載のサーバ。
5. 前記メンバー設定部は、フォームまたはエンティティのメンバーとなっているユーザから退会指示が取得されたときには、前記フォームまたはエンティティのメンバーから前記退会指示したユーザを除外することを特徴とする請求項１から４のいずれかに記載のサーバ。
6. 案４
   前記メンバー設定部は、フォームに対してメンバーとなるユーザが設定されたときには、前記フォームにしたがって作成されるエンティティに対しても前記ユーザをメンバーとして設定することを特徴とする、請求項１から５のいずれかに記載のサーバ。
7. データ構造を定義するフォームおよびフォームにしたがって作成されるデータ集合体であるエンティティの双方を表示可能なユーザ画面を表示するユーザ画面表示部と、
   フォームにおいてあらかじめ準備されている複数の項目のうち、有効化する項目の指定をユーザから受け付ける項目入力部と、
   フォームにおいて有効化された項目に対する項目データの入力を受け付けるエンティティ作成入力部と、
   フォームまたはエンティティのメンバーとなる１以上のユーザの指定を受け付けるメンバー入力部と、を備え、
   前記ユーザ画面表示部は、前記ユーザ画面において、複数のエンティティのうち当該ユーザ端末のユーザがメンバーとして対応づけられているエンティティを選択的に表示することを特徴とするユーザ端末。
8. 通信ネットワークを介して相互接続される１以上のユーザ端末とサーバを含み、
   前記サーバは、
   前記ユーザ端末に対して、データ構造を定義するフォームおよびフォームにしたがって作成されるデータ集合体であるエンティティの双方を表示可能なユーザ画面を提供するユーザ画面提供部と、
   フォームにおいてあらかじめ準備されている複数の項目のうちユーザに指定された項目を有効化することでフォームのデータ構造を定義するフォーム設定部と、
   フォームにおいて有効化された項目に対する項目データの入力を受け付けることにより、前記フォームに基づくエンティティを設定するエンティティ設定部と、
   ユーザ画面に対するユーザからの指定にしたがって、フォームまたはエンティティのメンバーとなる１以上のユーザを設定するメンバー設定部と、
   エンティティの項目データに対するユーザからの更新指示にしたがって、エンティティの項目データを更新するエンティティ更新部と、
   エンティティの更新をユーザ端末に通知する更新通知部と、を備え、
   前記ユーザ端末は、
   ユーザ画面を表示するユーザ画面表示部と、
   フォームにおいて有効化する項目の指定をユーザから受け付ける項目入力部と、
   フォームにおいて有効化された項目に対する項目データの入力を受け付けるエンティティ作成入力部と、
   フォームまたはエンティティのメンバーとなる１以上のユーザの指定を受け付けるメンバー入力部と、を備え、
   前記サーバの前記ユーザ画面提供部は、ユーザ画面を提供するときには、複数のエンティティのうち、提供先のユーザがメンバーとして対応づけられるエンティティを表示対象として選抜し、
   前記サーバの前記更新通知部は、更新対象となったエンティティのメンバーを更新の通知先として設定し、
   前記ユーザ端末の前記ユーザ画面表示部は、ユーザ画面において、複数のエンティティのうち当該ユーザ端末のユーザがメンバーとして対応づけられているエンティティを表示することを特徴とする情報管理システム。

Images