(57)【要約】【課題】本発明は、機能仕様の分析・設計から対象システムの実装まで一貫して行うことを可能とする装置、方法、プログラムの提供。【解決手段】システムの機能要件を分析した結果を、Ｓを役割を示すロール、Ｖをイニシアティブターゲットに対する操作内容を表すイニシアティブ、Ｏをロールの操作対象であるイニシアティブターゲット、を含むＳＶＯステートメントの形式で記憶する手段を備え、前記記憶された前記機能に関するＳＶＯステートメントから、プロセスのリストを生成する。【選択図】図４
2010055562.tif 000002
【特許請求の範囲】
【請求項１】
システムの機能要件の分析結果を、
Ｓを役割を示すロール、
Ｖをイニシアティブターゲットに対する操作内容を表すイニシアティブ、
Ｏをロールの操作対象であるイニシアティブターゲット、
を含むＳＶＯステートメントの形式で記憶する記憶手段と、
前記記憶手段に記憶された前記ＳＶＯステートメントから、前記イニシアティブターゲットに対する操作の手順を規定したプロセスリストを生成する第一の手段と、
を備えた、情報処理装置。
【請求項２】
前記記憶手段に記憶された前記イニシアティブターゲットのデータモデルを生成する第二の手段を備えた、請求項１記載の情報処理装置。
【請求項３】
前記プロセスリストは、前記イニシアティブターゲットの前記データモデルに対する操作を規定する、請求項１又は２記載の情報処理装置。
【請求項４】
前記プロセスリストのプロセスは、
操作対象のイニシアティブターゲット、
プロセス操作を含み、
前記プロセス操作は、
プロセスの前提条件と終了条件、
プロセスの入力、出力、検索項目の少なくとも１つを含む、請求項１乃至３のいずれか１項に記載の情報処理装置。
【請求項５】
前記プロセスから、モデル、前記システムで扱う業務の項目シート、コンテント、エリア、ページのうち少なくとも一つを導出する手段を備えた、請求項１乃至４のいずれか１項に記載の情報処理装置。
【請求項６】
前記ロールは、前記イニシアティブターゲットの取り扱い方によって、
イニシアティブターゲットを新規に作成する役割（ＡＣＴＩＶＥ）、
イニシアティブターゲットを受け取って処理する役割（ＰＡＳＳＩＶＥ）、
イニシアティブターゲットを参照する役割（ＲＥＦＥＲＥＮＣＥ）、
マスタ・ルールの登録又は参照する役割（ＣＯＮＴＲＯＬ）、
のロールタイプのいずれか一つに属する、請求項１乃至５のいずれか１項に記載の情報処理装置。
【請求項７】
前記ロール、前記イニシアティブターゲットシートから、シーケンスチャートを作成し、前記シーケンスチャートにおいて、ＡＣＴＩＶＥからＰＡＳＳＩＶＥの流れに基づいて、一側から他側にロール間をイニシアティブターゲットが移動するかどうかをチェックすることで、ロールの導出、ロール間のイニシアティブターゲットのやりとりが正しく行われているかの検証が行われる、請求項６記載の情報処理装置。
【請求項８】
前記ステートメントの導出にあたり、
ロールとその対象のイニシアティブターゲットを特定し、
前記イニシアティブターゲットの取り扱いに基づき、ロールに分解し、
ロールタイプに基づくロール間の連携を元に、ロールとイニシアティブターゲット間の関連付けを行い、
ロールタイプに基づく、ロールが保持するイニシアティブと前提条件をチェックし、
ロール毎に保持しているイニシアティブに基づきステートメントの一覧に展開する、請求項７記載の情報処理装置。
【請求項９】
ロールの抽出にあたり、ロールの元になる参加者を抽出し、
参加者が操作するイニシアティブターゲットを特定し、イニシアティブターゲットの取り扱い方に着目して参加者のロールカテゴリを決定する、請求項８記載の情報処理装置。
【請求項１０】
前記プロセスリスト及び／又はデータモデルに基づき、前記機能を実装するシステムを稼動させるエンジンを備えた、請求項１乃至９のいずれか１項に記載の情報処理装置。
【請求項１１】
前記導出されたモデル、前記システムで扱う業務の項目シート、コンテント、エリア、ページのうち少なくとも一つに基づき、前記機能を実装するシステムを稼動させるエンジンを備えた、請求項５記載の情報処理装置。
【請求項１２】
システムの機能要件の分析結果を、
Ｓを役割を示すロール、
Ｖをイニシアティブターゲットに対する操作内容を表すイニシアティブ、
Ｏをロールの操作対象であるイニシアティブターゲット、
を含むＳＶＯステートメントの形式で記憶手段に記憶し、
前記記憶手段に記憶された前記機能に関するＳＶＯステートメントから、イニシアティブターゲットに対する操作の手順を規定したプロセスリストを生成する、システム構築方法。
【請求項１３】
前記記憶手段に記憶されたイニシアティブターゲットのデータモデルを生成する、請求項１２記載のシステム構築方法。
【請求項１４】
前記プロセスリストのプロセスは、
操作対象のイニシアティブターゲット、
プロセス操作を含み、
前記プロセス操作は、
プロセスの前提条件と終了条件、
プロセスの入力、出力、検索項目の少なくとも１つを含む、請求項１２記載のシステム構築方法。
【請求項１５】
前記プロセスから、モデル、前記システムで扱う業務の項目シート、コンテント、エリア、ページのうち少なくとも一つを導出する手段を備えた、請求項１２乃至１４のいずれか１項に記載のシステム構築方法。
【請求項１６】
前記ロールは、前記イニシアティブターゲットの取り扱い方によって、
イニシアティブターゲットを新規に作成する役割（ＡＣＴＩＶＥ）、
イニシアティブターゲットを受け取って処理する役割（ＰＡＳＳＩＶＥ）、
イニシアティブターゲットを参照する役割（ＲＥＦＥＲＥＮＣＥ）、
マスタ・ルールの登録又は参照する役割（ＣＯＮＴＲＯＬ）、
のロールタイプのいずれか一つに属する、請求項１２乃至１５のいずれか１項に記載のシステム構築方法。
【請求項１７】
前記ロール、前記イニシアティブターゲットシートから、シーケンスチャートを作成し、前記シーケンスチャートにおいて、ＡＣＴＩＶＥからＰＡＳＳＩＶＥの流れに基づいて、一側から他側にロール間をイニシアティブターゲットが移動するかどうかをチェックすることで、ロールの導出、ロール間のイニシアティブターゲットのやりとりが正しく行われているかの検証が行われる、請求項１６記載のシステム構築方法。
【請求項１８】
システムの機能要件の分析結果を、
Ｓを役割を示すロール、
Ｖをイニシアティブターゲットに対する操作内容を表すイニシアティブ、
Ｏをロールの操作対象であるイニシアティブターゲット、
を含むＳＶＯステートメントの形式で記憶手段に記憶する第一の処理、
前記記憶手段に記憶された前記機能に関するＳＶＯステートメントから、イニシアティブターゲットに対する操作の手順を規定したプロセスリストを生成する第二の処理をコンピュータに実行させるプログラム。
【請求項１９】
請求項１８記載のプログラムにおいて、
前記記憶手段に記憶されたイニシアティブターゲットのデータモデルを生成する第三の処理を前記コンピュータに実行させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は情報処理システム、方法に関し、特に、伝票処理等の業務システムの構築等に用いて好適なシステムの構築技術に関する。
【背景技術】
【０００２】
＜企業向けシステムの構築手順＞
現在、企業の業務を支援するシステム（エンタープライズシステム）は下記のような手順にて構築が行われている。
【０００３】
（S1）仕様書の作成、
（S2）要求に基づく機能・ルールを記述した仕様書を作成、
（S3）プログラムコードの作成、
（S4）上記の仕様書に基づきそれをコンピュータ上で実現する範囲についてプログラムコードを作成、
（S5）実行環境の構築とテスト・運用、
（S6）プログラムコードを実行する環境の導入、
（S7）上記の環境におけるテストと運用。
【０００４】
システム構築は、仕様書に基づきその内容を正確に反映したプログラムコード記述するという作業によって成立している。
【０００５】
＜企業向けシステム（エンタープライズシステム）＞
基本的に企業および、企業間は伝票とそれを取り扱う組織からなっている。企業向けシステムとは企業とそれに関わる利用者に対して伝票とその取り扱いに関するルールを制御する手段を提供する。該手段は、主にネットワークを含むコンピュータシステムまたは、マニュアルと紙、電話、ＦＡＸ等の通信手段を用いて構成される。
【０００６】
ところが、実際のシステム構築作業（開発プロジェクト）においては、仕様書自体の品質の問題、仕様書とプログラムコードの不一致の問題により多くのプロジェクトが失敗したり、大幅な遅延または予算オーバーが発生している。
【０００７】
なお、情報システムの汎用的な設計指針を構築可能とし検証可能とするシステムとして、特許文献１等の記載が参照される。またシステムの構築・検証・実装化までをシームレスに行うシステムとして特許文献２等が参照される。
【０００８】
【特許文献１】特開２００７−１８８３３４号公報
【特許文献２】特開２００３−３３７６９７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００９】
以下に、本発明による分析結果を述べる。
【００１０】
（A）仕様書の記述に関する一貫した導出手法が存在しない。
【００１１】
（B）また、要求を仕様が満たしているかどうか一貫した検証する方法が存在しない。
【００１２】
（C）また、仕様書からプログラムコードを構築可能な形式に展開する一貫した手法が存在しない。
【００１３】
（D）仕様書とプログラムコードが一致していることを検証または保証する一貫した仕組みが存在せず、仕様とプログラムの間に明確な導出関係が存在しない。
【００１４】
（E）最終的な納品物であるプログラムコードが動作可能になるまで実質的な検証がほとんど不能であり、テストとそこで発生した問題点の解消に非常にコストが発生する。特に仕様とプログラム間に明確な導出関係が存在しないため、プログラムコードだけが修正され、個々の担当プログラマが局所のみ把握しているという実質的に仕様そのものが不在な状況すら発生している。
【００１５】
上記の状況は企業においては、企業統治が成立していない状況であり、ＪＳＯＸ（日本版サーベンス・オクスリー法）に代表される法遵守や、競争のために企業が変革する上でコスト的にも大きな問題になっている。
【００１６】
＜プログラミング技術による解決の限界＞
上記の問題の原因は仕様書自身または、仕様書とプログラムコード間の間に存在するためプログラミング言語、ツールなどこれまで主流であったプログラム作成のための技術によっては根本的に解決することができない。
【００１７】
＜現状における仕様書の記述方法とその問題点＞
基本的に文章又は、それを補助する絵などによって記述されており、厳密性にかけている上に内容に対する一貫した導出手法が存在しない。厳密性をうたっている手法についてもその対象は書式に対するものあり、内容並びに導出する手法に対する物でない。あるいは特定の業種向けのテンプレート（パッケージの導入）などであり、汎用性がない。
【００１８】
厳密な導出方法の不在は、書き手によって同じ入力に対して結果が異なることになり、品質が一定しないと同時に要求に対してその仕様が、
必要な機能を満たしているか？（不要な機能は無いか？）
それが運用可能か？
既存の組織・運用に対してどれだけ影響を与えるのか？
どれだけの規模であるコストが発生するのか？
などを要求者が検証することが非常に困難である。
【００１９】
＜仕様記述に関する従来の対応＞
経験と知識がある担当者によるレビューを行うことで、品質および、内容の統一性に関して制御を行ってきた。ただし、特定の経験・知識は原則、特定の業種業態に依存するのと、仕様書とプログラムの一貫性の確認においては、業務的な知識とプログラムに対する知識の双方がもとめられ、レビュー可能な人間はきわめて少数に限られる。
【００２０】
また、レビュー担当者による知識・経験による差異が発生する。このため、少数のレビュー担当者では扱うことが困難な大規模プロジェクトにおいては十分な数のレビュー担当者をそろえることが出来ない場合、レビュー担当者自身がボトルネックになったり、レビュー担当者毎の記述内容、品質のばらつきが問題になり対応が出来ない。
【００２１】
＜現状の仕様書の記述の状況に関する考察＞
現在の仕様書の記述は特定の本に対する説明文の記述とその内容の検証に状況的に似ている。読書感想文の内容は記述の道具によって解決することは出来ない（プログラミング技術での解決が不能）。また、使う原稿用紙のフォーマットを決めても内容を規定することにはならない。同じ本を読んでも書き手によっては全く異なる内容によって記述される
説明内容が元の本と一致しているかどうかは、元の本の内容に対する深い知識が必要である。
【００２２】
元の本の内容を理解していても説明文に対する評価が出来るとは限らない、評価・検証をするにはその双方に対する深い知識が必要である。結果としてエキスパートたる国語教師が記述しても内容も異なるし、その評価も異なり、その評価の明確な基準も存在しない（点数化、定量化が出来ない）。
【００２３】
説明文の場合は上記でもあまり問題は発生しないが、システム構築の場合、それを元に厳密なコマンドの組み合わせであるプログラムコードを記述し、それを道具に実際の業務の運営をする必要がある。
【００２４】
＜仕様からプログラムコードへの展開＞
仕様書は原則業務内容を元に記述されており、人間を対象とした概念的なものなのに対して、プログラムコードはコンピュータに対する指示であり両者は根本的に異なる種類の成果物である。これまでは、仕様書からプログラムコードまたはプログラムコードへ直接変換可能な形式への一貫した導出手法が存在しなかった。また、仕様書の書き手とプログラムコードの書き手はＳＥとプログラマという違う種類の職種として分類されており、通常両者は異なる人間によって担当される。このため、プログラム担当者が仕様書を業務的な内容を含めて理解してプログラムコードまたは、プログラムコードに近い内容の成果物を記述するという対応がなされていた。
【００２５】
また、上記を支援するため業務的な様々な関連性を絵で記述するなど全員が業務を理解させる（または、業務担当者にプログラムの構造を理解させる）努力がなされてきた。絵などによる記述や担当者が理解を深める努力自体は健全であるが、いずれも担当者の能力に依存した方法であり、検証が難しい上に変更の管理が困難である（参考資料をたくさんかけばかくほど、一貫した変更の反映が難しくなる）。
【００２６】
＜一貫した導出手法の要件＞
一貫した導出手法の要件として以下がある。
【００２７】
同じ入力に対して、別の担当者が行っても同じ結果が得られる。
【００２８】
導出関係が明確であり、入力に不足がある場合、結果が出ないかつ何が不足しているのかを明示することができる。
【００２９】
現状の文章や絵を元に解釈し、別の文章や絵を記述していく手法では、一貫した導出手法用の要件を実現することは出来ない。
【００３０】
本発明の目的は、機能仕様の分析・設計から対象システムの実装まで一貫して行うことを可能とする装置、方法、プログラムを提供することにある。
【課題を解決するための手段】
【００３１】
本発明においては、システムの機能要件の分析結果を、
Ｓを役割を示すロール、
Ｖをイニシアティブターゲットに対する操作内容を表すイニシアティブ、
Ｏをロールの操作対象であるイニシアティブターゲット、
を含むＳＶＯステートメントの形式で記憶手段に記憶し、
前記記憶手段に記憶された前記機能に関するＳＶＯステートメントから、イニシアティブターゲットに対する操作の手順を規定したプロセスリストを生成する。
また、本発明においては、前記記憶手段に記憶されたイニシアティブターゲットのデータモデルを生成する。
【００３２】
本発明において、前記ロールは、前記イニシアティブターゲットの取り扱い方によって、
イニシアティブターゲットを新規に作成する役割（ＡＣＴＩＶＥ）、
イニシアティブターゲットを受け取って処理する役割（ＰＡＳＳＩＶＥ）、
イニシアティブターゲットを参照する役割（ＲＥＦＥＲＥＮＣＥ）、
マスタ・ルールの登録又は参照する役割（ＣＯＮＴＲＯＬ）、
のロールタイプのいずれか一つに属する。
【００３３】
本発明において、前記プロセスリストの各プロセスには、操作対象のイニシアティブターゲット、プロセス操作を含み。プロセス操作は、プロセスの前提条件と終了条件、プロセスの入力、出力、検索項目の少なくとも１つを含む。
【００３４】
本発明において、前記プロセスから、モデル、前記システムで扱う業務の項目シート、コンテント、エリア、ページのうち少なくとも一つを導出する構成としてもよい。
【００３５】
本発明において、前記ロール、前記イニシアティブターゲットシートから、シーケンスチャートを作成し、該シーケンスチャートにおいて、ＡＣＴＩＶＥからＰＡＳＳＩＶＥの流れに基づいて、一側から他側に、ロール間をイニシアティブターゲットが移動するかどうかをチェックすることで、ロールの導出、ロール間のイニシアティブターゲットのやりとりが正しく行われているかを検証するようにしてもよい。
【発明の効果】
【００３６】
本発明によれば、機能要件から仕様を定義する分析・設計と、システムの実装の自動化とを一貫したツールで提供することができる。
【発明を実施するための最良の形態】
【００３７】
本発明は、業務要件から仕様を定義する分析・設計手法とそれをシステム化するためのツール・環境を一体で提供することで対応している。
【００３８】
本発明においては、システムの機能要件の分析結果を、
Ｓを役割を示すロール、
Ｖをイニシアティブターゲットに対する操作内容を表すイニシアティブ、
Ｏをロールの操作対象であるイニシアティブターゲット、
を含むＳＶＯステートメントの形式で記憶手段に記憶する。
【００３９】
図１には、ＳＶＯステートメントの構成が示されており、ロール、イニシアティブ、イニシアティブターゲットからなるＳＶＯステートメントの形式で、記憶手段に記憶される。
【００４０】
図２に示すように、ロール（S）はロールタイプに属する。
【００４１】
イニシアティブターゲット（O）は、ロール（S）の操作対象である。
【００４２】
ロールタイプは、イニシアティブターゲット（O）に対する操作内容を表すイニシアティブ（V）を指定する。
【００４３】
図３に示すように、業務システムの参加者（ユーザ、組織、部門）はロール（S）に関連付けされる。ロールの抽出にあたり、ロールの元になる参加者を抽出し、  参加者が操作するイニシアティブターゲットを特定し、イニシアティブターゲットの取り扱い方に着目して参加者のロールカテゴリを決定する。
【００４４】
図４に示すように、記憶手段に記憶されたＳＶＯステートメントからイニシアティブターゲットに対する操作の手順を規定したプロセスリストを生成する。
【００４５】
また、図５に示すように、記憶手段に記憶されたイニシアティブターゲット（例えば帳票）のデータモデルを展開する。
【００４６】
プロセスリストのプロセスは、操作対象のイニシアティブターゲット、プロセス操作を含む。プロセス操作は、プロセスの前提条件と終了条件、プロセスの入力、出力、検索（ソート）項目の少なくとも１つを含む。
【００４７】
プロセスリストから、インタフェース（ページ、エリア、コンテント、画面パネル）、データモデル、サービス定義ファイル（データモデルに対するプロセス操作）を展開し、アプリケーションサーバ（エンジン）にて、前記機能要件を実装するシステムを稼動させる（図６参照）。以下に実施例に即して説明する。
【実施例】
【００４８】
本発明は、顧客の業務要件を、業種・業態に依存しない抽象的な名詞（ラベル）で定義する。
【００４９】
ラベルを適用する為の条件、
ラベル間の関連と制約に関する条件、
ラベル間の関連・制約に基づく成果物の導出、
に基づき、システム構築可能な形式の成果物までの一貫した導出方法を提供する。
【００５０】
本発明は、物理学な手法に近い考え方に基づいている。すなわち、方程式という抽象的なパラメータとその数学的な展開に基づく次の形式への展開、および、方程式の抽象的なパラメータに対して値をいれることによる具体的な結果の取得に対応した処理が行われる。
【００５１】
本発明では、機能を英文のＳＶＯ形式で記述する。ただし、選択できるＳの種類はあらかじめ決められており、それはＯの取り扱い方で決まっている。
【００５２】
また、Ｖもあらかじめ種類が決められており、Ｓの種類によって、選択可能なＶが制限されている。これは、物理学におけるＦ＝ＭＶ（力と、質量と速度の関係）のように抽象的かつ明確な関連性によって記述されている。本発明における導出手法は、表現方法のみを規定するのではなく、物理学における方程式のように、汎用的かつ演繹的に利用することが出来る。よって同じ入力に対しては同じ結果が得られかつ、それが正しいかどうか作成者以外から検証することが可能である。
【００５３】
本発明によれば、定量的分析を実現可能とし、客観的な規模の把握、進捗管理をスループット（どれだけ終わったか）の管理することが可能であり、一連の設計から、実システムの実装までを一括管理できる。また、本発明によれば、設計指示書、仕様書等の文書のように最初から最後まで読む必要がない
【００５４】
本発明においては、成果物毎に扱う内容が決められており、その成果物を確認すれば、成果物がそこにあるかないかを確認することができる。また、各成果物毎にＩＤが振られており、成果物毎の一覧で管理されており必要な資料をピンポイントで取得することができる。さらに成果物の検証が可能である。
【００５５】
本発明によれば、成果物をＤＢに保存して、業務的な知識なしに形式的な分類によるソートや導出関係に基づくクロスリファレンスチェックなどが可能である。
【００５６】
本発明は、従来のソフトウェア開発における分析と設計に関する範囲をカバーし、以下の２つの分析手法から構成される。
【００５７】
本発明の分析（RIT分析）は、
機能の一覧を定義する、
アクティビティ分析を行う、
各機能ごとのプロセスを定義する、
の３つの処理を含む。
【００５８】
RIT分析は、顧客の要望・業務内容を独立した実行可能な機能（SVOステートメント）の一覧に変換する。入力として、顧客の機能要件（インタビューまたは、資料）、テンプレートを含む。導出される成果物として、ステートメントシート、独立に実行可能な機能の一覧を含む。
【００５９】
アクティビティ分析は、ステートメントをシステム化可能な形式に変換する。導出される成果物（出力）は、
＜アクティビティシート（１ステートメントに１つ）＞
各機能毎のプロセス（実現手順）に関する定義
＜業務項目シート＞
プロセスが扱う入出力項目の一覧とその型・値、取り扱い範囲に関する定義
＜モデルシート＞
操作対象（モデル）とそれが保持する業務項目・ルールに関する定義
＜ルールシート＞
業務的な仕様に基づくルールが必要な項目一覧とその詳細を定義
分析フェーズ成果物関連図
【００６０】
＜ＲＩＴ分析＞
顧客の機能要件を、顧客の要求書（ＲＦＰ），顧客へのインタビュー・資料など定式からされてない情報からから英文のＳＶＯ形式の一覧にまとめる。機能を英文のＳＶＯ形式にまとめたものを、ステートメントとよび、その一覧をステートメントシートと呼ぶ
【００６１】
＜ステートメント（ＳＶＯ）＞
業務の遂行に必要な機能を英文のＳＶＯ形式で記述した物。
【００６２】
ロール・イニシアティブ・イニシアティブターゲットならびにステートメント前提条件からなる（図１参照）。
【００６３】
＜Ｓ：ロール＞  具体的な人、組織とは独立な役割、
ロールはあらかじめ決められたロールタイプのいずれかに属す。
【００６４】
具体的な人、組織を参加者と呼ぶ。
【００６５】
ロールは少なくとも一つ以上の参加者を持つ。
【００６６】
参加者は一つ以上のロールを属する。
【００６７】
＜Ｖ：イニシアティブ＞例えば伝票（イニシアティブターゲット）に対する操作内容。
【００６８】
利用可能な動詞はロールタイプによってあらかじめ決まっている。
【００６９】
＜Ｏ：イニシアティブターゲット＞  ロールの操作対象伝票。
【００７０】
ロールタイプ、イニシアティブの種類によっては複数の伝票を同時に操作する場合もある。
【００７１】
＜ステートメント前提条件＞  ステートメントを実行する際に対象になるＯの状態。
【００７２】
＜ステートメントの導出手順＞
参加者とその対象の伝票の特定する。
【００７３】
伝票の取り扱い方法に基づき、参加者をロールに分解する。
【００７４】
ロールタイプに基づくロール間の連携を元にロール・イニシアティブターゲット間の関連を整理する。
【００７５】
ロールタイプに基づくロールが保持するイニシアティブとその前提条件を確認する。
【００７６】
ロール毎に保持しているイニシアティブに基づきステートメントの一覧に展開する。
【００７７】
＜ロールの抽出＞
ヒアリング、資料からまずロールの元になる参加者を抽出する。
【００７８】
その参加者操作している伝票（イニシアティブターゲット）を特定する。
【００７９】
伝票の取り扱い方に着目して参加者のロールの種類（ロールカテゴリ）を決定する。
【００８０】
＜ロールの分類（ロールカテゴリ）＞
伝票の取り扱いかたからロールを下記の３つに分類する。
ＡＣＴＩＶＥ：（無から）伝票を作っている。
ＰＡＳＳＩＶＥ：誰かから伝票を受け取っている。
ＲＥＦＥＲＥＮＣＥ：誰かの作った伝票を見ている。
【００８１】
＜ＰＡＳＳＩＶＥの分類＞
ＰＡＳＳＩＶＥなロールについてさらに伝票の取り扱い方から下記のサブカテゴリに分類する。
【００８２】
同一伝票に対して処理を行っている。
【００８３】
ＰＡＳＳＩＶＥ＿ＡＣＣＥＰＴ：承認、受付（ハンコを押す）。
【００８４】
ＰＡＳＳＩＶＥ＿ＳＥＮＤ，ＰＡＳＳＩＶＥ＿ＲＥＣＥＩＶＥ：誰かにそのまま渡す、受け取っている。
【００８５】
処理することで伝票の状態がどのように変わったのかを確認。
【００８６】
ＰＡＳＳＩＶＥ＿ＰＲＯＤＵＣＥ：別の伝票を起こしている。
【００８７】
ＲＥＦＥＲＥＮＣＥ：何から何を作っているのかを確認。
【００８８】
ＰＲＯＤＵＣＥすることで導出物伝票の状態がどのように変わるかを確認。
【００８９】
＜ＲＥＦＥＲＥＮＣＥの分類＞
ＲＥＦＥＲＥＮＣＥのロールについて伝票の参照の仕方に応じて下記のサブカテゴリに分類する。
【００９０】
原則一つの伝票を参照（印刷）している。ＲＥＦＥＲＥＣＥ＿ＳＥＡＲＣＨ。
複数の伝票を組み合わせた表を参照（印刷）している。ＲＥＦＥＲＥＮＣＥ＿ＰＯＲＴＦＯＬＩＯ。
【００９１】
＜ロールの定義＞
一つのロールは必ず一つだけの分類に属する。ある登場人物が複数のカテゴリに分類される場合は、ロールも複数存在する。ある登場人物が複数のロールに分解される。登場人物の組織、人を各ロールの参加者として記録する。各ロールにその対象伝票名に対してカテゴリ分類が確認可能なロール名を定義する（例：見積依頼作成者）。
【００９２】
＜ロールスキーマ＞
ロール名
ロールカテゴリ
イニシアティブターゲット（操作対象伝票）
導出の場合は（ＳＯＵＲＣＥ，ＤＥＳＴで複数）
イニシアティブターゲットの操作前状態、操作後状態
【００９３】
＜ロールの導出とロール・イニシアティブターゲット一覧の作成＞
顧客のインタビュー、資料から確認できた登場人物、ロールからＡＣＴＩＶＥに対するＰＡＳＳＩＶＥ、ＰＡＳＳＩＶＥのＳＯＵＲＣＥなど連携を元に業務全体のロール・イニシアティブターゲットの抽出を行う。
【００９４】
＜シーケンスチャートの作成と業務フローの確認＞
シーケンスチャートの縦軸にロール、各列に角無しの箱でイニシアティブターゲットを配置して、各ロールおよび、イニシアティブターゲット（伝票）間の連携を記述する。イニシアティブターゲット名の後ろに各ロールが操作後の状態を記述する。図７にシーケンスチャートの一例を示す。見積依頼申請者、見積依頼承認者、見積依頼受付者、取引先見積依頼送付者、取引先見積依頼受付者、取引先見積回答受付者、取引先見積回答送付者、見積回答検収者のロールが左から右に順に配置され、各ロールのロールタイプとイニシアティブターゲットの流れが図示される。
【００９５】
ＡＣＣＥＰＴの場合は、各ロール間で渡されるイニシアティブターゲットは同じなるが、ただし状態は異なる。図７の例では、ACCEPTの場合、各ロール間で渡されるイニシアティブターゲットは見積依頼書、見積回答書である。
【００９６】
ＰＲＯＤＵＣＥの場合は、渡されたイニシアティブターゲットから別のイニシアティブターゲットが同じ列内で矢印で導出される。図７の例では、取引先見積依頼送付者において、同じ列内の下向矢印による導出で、見積依頼書から取引先見積依頼書がPRODUCEされ、SEND（送付）される。また渡される前後でＳＯＵＲＣＥのイニシアティブターゲットの状態が変化する。
【００９７】
導出関係に着目してそれが１：１か、１：Ｎか、Ｎ：１、Ｎ：Ｍなど多重度を確認する最後に各ロール（参加者＝登場人物）の業務が成立しており、ＳＯＵＲＣＥのないＰＡＳＳＩＶＥなど矛盾点がないことを確認する。シーケンス図の一例を図７に示す。
【００９８】
＜ロールからステートメントへの展開＞
各ロールカテゴリに対して利用可能な動詞の種類（イニシアティブ）は決まっている。原則上記の動詞を展開するとロールを主語（Ｓ）にイニシアティブ（Ｖ）、イニシアティブターゲット（Ｏ）でＳＶＯ＝Ｓｔａｔｅｍｅｎｔに展開される。ただし、上記のイニシアティブに対して非必須のイニシアティブについては、それが存在するのかどうかを確認する。
【００９９】
Ｓｔａｔｅｍｅｎｔを行うに当たっての条件（通常は、イニシアティブターゲットの状態に紐づけられる）を確認する。上記の条件を「ステートメント前提条件」とよぶ
【０１００】
＜ＡＣＴＩＶＥのステートメント例＞
注文伝票作成者が注文伝票を作成する。
【０１０１】
ロール：注文伝票作成者
イニシアティブ：ＣＲＥＡＴＥ（作成）
イニシアティブターゲット：注文伝票
注文伝票作成者が注文伝票を更新する。
【０１０２】
ロール：注文伝票作成者
イニシアティブ：ＵＰＤＡＴＥ（更新）
イニシアティブターゲット：注文伝票
注文伝票作成者が注文伝票を削除する。
【０１０３】
ロール：注文伝票作成者
イニシアティブ：ＲＥＭＯＶＥ（削除）
イニシアティブターゲット：注文伝票
【０１０４】
＜ＰＡＳＳＩＶＥ＿ＡＣＣＥＰＴのステートメント例＞
注文伝票受付者が注文伝票を受け付ける。
【０１０５】
ロール：注文伝票受付者
イニシアティブ：ＡＣＣＥＰＴ（受付）
イニシアティブターゲット：注文伝票
注文伝票受付者が注文伝票を返却する。
【０１０６】
ロール：注文伝票受付者
イニシアティブ：ＵＮＡＣＣＥＰＴ（返却）
イニシアティブターゲット：注文伝票
【０１０７】
＜ＰＡＳＳＩＶＥ＿ＰＲＯＤＵＣＥＲのステートメント例＞
出荷伝票作成者が出荷伝票を作成する。
【０１０８】
ロール：出荷伝票作成者
イニシアティブ：ＰＲＯＤＵＣＥ（導出）
イニシアティブターゲット：注文伝票、出荷伝票
出荷伝票作成者が出荷伝票を取り消す。
【０１０９】
ロール：出荷伝票作成者（参加者：出荷担当）
イニシアティブターゲット：出荷伝票、注文伝票
イニシアティブ：ＣＡＮＣＥＬ（取消）
【０１１０】
＜ステートメントの特徴＞
ロールタイプの分類とその制約に基づき、原則書き手によって異なる成果物が作成されない。抽象化されているため、特定の業種・業態にしない。業務担当者、システム構築者の双方が理解可能である。記述の粒度が同じで、業務の実行手順に依存していない（Ｓｔａｔｅｌｅｓｓ）な機能の一覧で伝票に対する操作が完了している単位に記されている。シーケンスチャートなどにより業務が成立するかどうかの検証が容易である。機能のリストであり、後工程の直接利用可能な成果物になっている。
【０１１１】
＜ＲＩＴ分析の適用＞
ＲＩＴ分析は、システム構築を行わない場合でも現状の問題点把握などで活用することが可能である。
【０１１２】
プロジェクト予算の算定
現行システムを再構築すべきかどうかに関するコンサルテーション、
現行のシステム構成に基づきＳｔａｔｅｍｅｎｔを記述（ＡｓＩｓ分析実施）、
Ｓｔａｔｅｍｅｎｔのイニシアティブ（Ｖ）に着目して分類、
ＰＡＳＳＩＶＥ＿ＳＥＮＤ，ＰＡＳＳＩＶＥ＿ＲＥＣＥＩＶＥの比率を取得する。
例えば、比率が１７％の場合、システムを統合することで削減できる機能であり、１７％にかかっているメンテナンスコストからシステムに投資可能なコストをもとめることが可能になる。
【０１１３】
一年間のメンテナンスコストから上記のＳｔａｔｅｍｅｎｔに対する保守に発生しているコストを算出。ＰＡＳＳＩＶＥ＿ＳＥＮＤ，ＰＡＳＳＩＶＥ＿ＲＥＣＥＩＶＥを除外するだけでどれだけのコスト効果が見込めるかを算出する。５年償却でおおよそどれほどのプロジェクト費用をかけられるかを算出する。
【０１１４】
＜ＪＳＯＸ対応＞
ＪＳＯＸ法対応に関してどの業務のどの部分を変更すべきかの検討する。現行の業務に基づきステートメントを記述する。ＰＡＳＳＩＶＥ＿ＡＣＣＥＰＴの操作対象のイニシアティブターゲット（Ｏ）を抽出する。
【０１１５】
上記のイニシアティブターゲットを操作対象とするＰＡＳＳＩＶＥ＿ＡＣＣＥＰＴ（承認）が行われていない物をリストアップする。
【０１１６】
追加が必要なステートメントの数を算出する。
【０１１７】
上記のステートメントのロールを担当する担当部署・システムを検討する。
【０１１８】
システム化（ワークフローの導入など）により不必要になる機能を確認する。上記のＢＰＲの結果のステートメント・シーケンス図からグループ各社で運用可能かどうかの検証と同時にロールに対する組織・担当の再構成を実施した。
【０１１９】
＜アクティビティ分析＞アクティビティ分析はＲＩＴ分析の成果物の各ステートメントに対して、それがどのような手順ならびに項目の入出力によって成立しているのかを定義する作業である。アクティビティ分析を通じてステートメントはシステムの構成要素である。
【０１２０】
モデル：データ・ルールの保持
プロセス：モデルの操作
インタフェース：プロセスに対する利用者のインタフェースの提供
ルール
手続き：動的な項目値の決定
条件：プロセスの実行・終了可否に関する判断
バリデーション：インタフェース上の入力値の制限
業務項目：項目の定義（取り扱い、型、多重度他）に直接又は、変換可能な形式に展開される。
【０１２１】
原則、全てのシステムは下記の構成要素によって成立する。
モデル
プロセス
インタフェース
ルール
手続き：モデルに紐づくルール
条件：プロセスに紐づくルール
バリデーション：インタフェースに紐づくルール
【０１２２】
システム化とは、業務的な機能要件（ステートメント）を上記のモデル・プロセス・インタフェース・ルールに展開することによって実現される。
【０１２３】
＜アクティビティ分析の成果物＞
アクティビティシート：一ステートメント毎に一つ作成し、ステートメントの機能が成立するための手順（プロセス）を記述する。
【０１２４】
各プロセスでは、操作対象のイニシアティブターゲット（伝票）とおそれに対する操作（アクション）ならびに、入出力項目、プロセスの前提条件（実行の可否とその結果のアクション）および、終了条件（プロセスが正常終了するための条件式）が記述される。
【０１２５】
業務項目シート
アクティビティシートの各プロセスの入出力項目を正規化した物。
基本的に項目は全て独立で項目名で一意に認識される。
各項目毎のメタ情報（項目種別、型、多重度）を記述する。
【０１２６】
＜手続きリスト＞
プロセスの出力項目で動的に項目値が決定されるもので合計値や平均値などの単純な関数では表現できない物について、出力の業務項目とルール名を管理する。アクティビティシートの入出力のミスマッチから導出される。各手続きの詳細は別途、手続き詳細仕様に業務項目を使って記述する。
【０１２７】
＜条件リスト＞
プロセスの前提条件（プロセスの実行の可否および偽だった場合のアクション）および、終了条件（プロセスを終了するための条件）について単純な項目の有無または値の条件式では記述できない物について条件名とその条件を適用するプロセスを管理する。各条件の詳細は別途、条件詳細仕様に業務項目を使って記述する。
【０１２８】
＜モデル＞
イニシアティブターゲットが保持する項目リストに対してのインタフェース
入力：アクティビティのプロセス、プロセスの入出力項目、手続き
【０１２９】
本発明の成果物から決められたルールに基づく展開によって作成される。プログラミングのようにプログラマの自由裁量があるわけではない。上記により本発明の成果物との導出関係が明確であり、クロスリファレンスチェックや、形式的なチェックリストにもとづく検証が可能。
【０１３０】
導出された成果物はＥｎｇｉｎｅにて検証ならびに運用が行われる。アクティビティ分析の成果物を元に利用者に対するインタフェースを定義する。
入力：アクティビティシート、デザイン規約
出力（導出される成果物）：
インタフェース
利用者に提供する画面
ページ（インタフェース内に配置するエリアの情報ならびにページの遷移を定義する）
エリア：各ページにどのような画面部品を配置するか、画面部品とコンテントの対応関係を記述する。
コンテント（アクティビティのプロセスのプロセス操作に対応する抽象的な画面機能部品）
【０１３１】
＜サービス設計＞
サービスの機能＝プロセスに対するモデルの操作内容を記述する。
入力：アクティビティのプロセス
出力（導出される成果物）：サービス（図６参照）。
【０１３２】
＜データベース設計＞モデルに対してデータベース上のテーブルカラムに関する情報を追記する。
入力：業務項目シート、モデル
出力（導出される成果物）：モデルシート（図６参照）。
【０１３３】
＜ルール設計・実装＞：アクティビティシートのプロセスにおいて出力項目または、入力項目がルールによって動的に決定しているものについてその内容を業務項目に基づく式として記述する。
入力：アクティビティシートのプロセスで宣言されたルール
出力：ルール定義またはルール実装クラス。
【０１３４】
なお、上記の特許文の各開示を、本書に引用をもって繰り込むものとする。本発明の全開示（請求の範囲を含む）の枠内において、さらにその基本的技術思想に基づいて、実施形態ないし実施例の変更・調整が可能である。また、本発明の請求の範囲の枠内において種々の開示要素の多様な組み合わせないし選択が可能である。すなわち、本発明は、請求の範囲を含む全開示、技術的思想にしたがって当業者であればなし得るであろう各種変形、修正を含むことは勿論である。
【図面の簡単な説明】
【０１３５】
【図１】本発明の一実施例のＳＶＯステートメントの構成を説明する図である。
【図２】本発明の一実施例のＳＶＯステートメントを説明する図である。
【図３】本発明の一実施例のロールと参加者を説明する図である。
【図４】本発明の一実施例を説明する図である。
【図５】本発明の一実施例を説明する図である。
【図６】本発明の一実施例を説明する図である。
【図７】本発明の一実施例を説明する図である。
【符号の説明】
【０１３６】
Ｓ  ロール
Ｖ  イニシアティブ
Ｏ  イニシアティブターゲット
【図１】
2010055562.tif 000003
【図２】
2010055562.tif 000004
【図３】
2010055562.tif 000005
【図４】
2010055562.tif 000006
【図５】
2010055562.tif 000007
【図６】
2010055562.tif 000008
【図７】
2010055562.tif 000009