JP5500662B2 - 銀行業務処理システム、方法及びプログラム - Google Patents

Description

本発明は、信用リスク管理等の銀行業務を処理するための銀行業務処理システム、方法及びプログラムに関する。

＜信用リスク＞
融資等の金融取引により経済主体間で資金が融通され、資金の過不足が調整されると、経済活動が一段と円滑に進む。借り手は、貸し手に利息又は配当を支払うという確約をすることで資金の融通を受ける。利息又は配当は、借り手の将来収入という不確実な資産から支払われる。このため、借り手の状況変化により、貸し手は約定通りの元本の返済及び利息等の対価支払いを受け取ることができなくおそれがある。借り手が約定通りの返済等を行わないことで、貸し手が損害を受ける可能性を、信用リスクという（より詳細な説明は、例えば、非特許文献１第２頁から第５頁）。

貸し手は、信用リスクを回避し、資産の安全性を確保すために、借り手の支払能力を審査して融資の適格性を判断する。さらに、貸し手は、融資実行後も、借り手の業況変化や経済環境の変化が借り手に与える影響等を個別かつ継続的にモニタリングする。
また、貸し手の融資総額がある特定の性質の分野（市場）に偏っていると、その分野へ不測の状況変化が生じた場合には、その分野の多くの借り手の収入が低下するため、融資総額の多くが約定通りに返済されない可能性が高まる。このような分野の偏りによる信用集中リスクの増加を回避するためには、貸し手は、多種多様な借り手を探し、かつ、分野に偏りのないようにポートフォーリオの戦略を定め、実行しなければならない。

貸し手は、借り手の将来の支払能力の審査と、担保価値及び保証による回収可能性の評価と、法的に瑕疵のない契約と、借り手の状況のモニタリングと、さらにポートフォーリオの戦略など、高度に専門的な作業を行うことで、融資資金（債権）の安全性を保持することができる。借り手が企業であり、決算による財務諸表を公表している場合には、借り手の財務内容を詳細に分析することで、借り手の資産や、営業状態や、返済能力（債務償還能力）の変化を把握することができる。

資金に余裕のある個人や企業が資金の融資を行おうとしても、信用リスクを回避しつつ融資の対価である利息収入を得るためには、上述のように、多くの事柄を判断し、また行動しなければならない。貸し手が信用リスクを適切に管理できない環境では、経済主体間の資金の過不足の調整は限定されたものとなり、経済を円滑に進ませる金融取引が行われなくなってしまう（非特許文献１第８頁から第９頁等）。

＜預金等受入金融機関＞
金融機関は、この金融取引の仲介に特化した法人である。金融機関の内、預金等受入金融機関は、貸し手から預金により調達した資金を融資の原資とするものであり、間接金融と呼ばれる。ここでは、預金等受入金融機関（信用金庫、信用組合等を含む）を銀行と呼ぶ。銀行は、貸し手から預金を受入れ（預金受入業務）、これを借り手に貸し出す（貸出業務）。預金は、流動性に富むため、経済主体間の決済にも利用されている。例えば、我が国では、銀行の事務処理の正確性への信任が厚く、預金残高を利用した自動的な決済である口座振替が発達している。口座振替は、借り手が銀行に融資残高を返済する際にも利用されている。

銀行は、銀行法等の金融法など下記の多様な規律による要請を満たさなければならない。
・銀行法等の金融法（銀行業務の健全性及び適切性）
・財務会計基準
・バーゼルＩＩ合意（「自己資本の測定と基準に関する国際的統一化：改訂された枠組」２００４年６月、バーゼル銀行監督委員会）
・バーゼルＩＩ第１の柱による自己資本比率規制（金融庁告示第１９号：銀行法第十四条の二の規定に基づき、銀行がその保有する資産等に照らし自己資本の充実の状況が適当であるかどうかを判断するための基準（２００６年３月２７日）
・バーゼルＩＩ第２の柱による監督（監督指針：主要行等向けの総合的な監督指針（２００７年６月）、中小・地域金融機関向けの総合的な監督指針（２００７年６月）； 預金等受入金融機関に係る検査マニュアル（非特許文献５［「検査マニュアル」という］）
・バーゼルＩＩ第３の柱による自己資本比率等の開示（金融庁告示第１５号： 銀行法施行規則第十九条の二第一項第五号ニ等の規定に基づき、自己資本の充実の状況等について金融庁長官が別に定める事項）
・バーゼルＩＩ及び検査マニュアルの要請による内部統制（善感注意義務、会社法第３６２条第４項第６号）
・金融商品取引法による財務報告に係る内部統制（金融商品取引法第２４条の４の４）
・財務報告に係る内部統制の評価及び監査の基準並びに財務報告に係る内部統制の評価及び監査に関する実施基準の改訂について（意見書）（非特許文献８）

銀行法（昭和五十六年六月一日法律第五十九号）第１条（目的）は、次のように規定する。
「１ この法律は、銀行の業務の公共性にかんがみ、信用を維持し、預金者等の保護を確保すると共に金融の円滑を図るため、銀行の業務の健全かつ適切な運営を期し、もつて国民経済の健全な発展に資することを目的とする。
２ この法律の運用に当たっては、銀行の業務の運営についての自主的な努力を尊重するよう配慮しなければならない。」
「銀行の業務の健全性」は、銀行の財務の健全性であり、貸出債権（金銭債権）の厳格な査定（評価額の測定）に基づいた財務会計上の（一般及び個別）貸倒引当金の計上と、銀行業務をとりまくリスク量の測定に応じた自己資本比率の計算に応じて判断される。
貸倒引当金の算定に関しては、上記のうち、主に、財務会計基準と検査マニュアルとに準拠しなければならない。リスク量の測定と計算、開示については、バーゼルＩＩ関係の告示及び検査マニュアルに準拠しなければならない。
貸倒引当金及びリスク量の測定の正確性を確保するために、強固な内部統制の構築が求められる。内部統制については、上記のように、バーゼルＩＩ、検査マニュアル、会社法、及び金融商品取引法による要請がある。
「銀行の自主的な努力」には、銀行による創意工夫が含まれる。
以下、金銭債権の査定（貸倒引当金の額の算出）、リスク量の測定、及び内部統制についての従来例を説明する。

＜貸倒引当金： 財務会計＞
財務会計は、企業の経済活動を、貨幣額などを用いて計数的に測定し、その結果を報告書にまとめて利害関係者に伝達するためのものである。財務会計の報告書で最も重要な二つが貸借対照表（Ｂ／Ｓ，balance sheet）と、損益計算書（Ｐ／Ｌ： profit and loss statement）とである。銀行を例とすると、Ｂ／Ｓは、経済活動に必要な資金を、出資者から拠出を受けた資本を含む純資産と、預金者等から調達した負債とに分けて示すと共に、それらの資金が経済活動のために投下されている資産とを対比して表した一覧表である。

銀行のＢ／Ｓでは、預金は負債であり、融資（金銭債権）は資産である。銀行は、資本及び預金による負債を貸金（金銭債権）に投下し、その貸金である資産（金銭債権）から利息収入を得る。Ｐ／Ｌは、銀行が保有する資産により経済活動を行った結果、その成果である収益と、これに要した費用とを事業年度内にて対応させて対比することにより、その差額としての純利益を明らかにするものである（より詳細な説明は、例えば、非特許文献２第１頁から第５頁）。

企業の経済活動の結果、どの程度利益を得たかを計算するために、その企業を解散し、全ての資産を売却してその残額を利益とすることはできない。財務会計では、１年間等の事業年度の期間（期首から期末）で区切り、この期間内の経済活動による利益を算出する。このため、Ｂ／Ｓについては、決算期末時点での資産等を、Ｐ／Ｌについてはその期首から期末までの収益及び費用等を測定する（継続企業の公準： Going Concern，非特許文献２第５４頁から第５８頁）。

企業会計原則の一般原則は種々あるが、信用リスクとの関係では、保守主義の原則がある。これは、「企業の財政に不利な影響を及ぼす可能性がある場合には、これに備えて適切に健全な会計処理をしなければならない」とする原則であり、「予想の損失は計上しなければならないが、予想の利益を計上してはならない」という格言で表される（非特許文献２第６４頁から第６５頁）。

金銭債権の一部が回収不能となると、貸倒れによる損失が発生する。この貸倒れ損失は、信用を供与したことに伴うコストであるから、売上収益に対応する費用であると考えられる。従って金銭債権につき、過去の実績等に基づいて貸倒れ見積高を算定し、「予想の損失」として、貸倒引当金を設定する（非特許文献２第１３９頁から１４２頁）。一般に「引当金の設定は、企業にとって避けられない将来の経済的負担のうち、当期の収益に負担させることが妥当な項目のみに限定されなければならない」（非特許文献２第２１９頁から第２２１頁）。

貸倒引当金は、資産から控除する引当金であり、金銭債権からの「控除によって債権の回収可能評価額を評価していると考えられることから、評価性引当金とよばれることがある。」（非特許文献２第２２１頁）。財務会計での金銭債権の評価は、金融商品会計基準に定められており、貸倒引当金の見積について、債務者の状態に従って一般債権と、貸倒懸念債権と、破産更生債権とに債権を区分し、区分毎に適正な評価法で評価をする。
例えば、債務者の経営状態に重大な問題が生じていない一般債権については、過去の貸倒実績率等の合理的な基準で算定する。経営破綻ではないが、弁済に重大な問題が生じているか、その可能性が高いとされる貸倒懸念債権については、債権額から担保の処分可能額又は保証による回収可能額を減算し、これに過去の実績率などから算出する。また、貸倒懸念債権については、将来の見積キャッシュ・フローを約定利子率で割引いた現在価値と、帳簿価格との差額を引当金としても良い。債務者が法的又は実質的に経営破綻に陥っている破産更正債権等については、債権額から担保の処分可能額又は保証による回収可能額を減算する。
銀行がその資産を査定するというのは、主に、銀行が借り手に対して有する金銭債権の経済的価値を評価し、一般及び個別の貸倒引当金の額を算出する作業である。貸倒引当金を計上すると、自己資本が減少する。銀行の資産（金銭債権等）に対する自己資本の比率について、国際的なバーゼル合意がある。

＜バーゼル合意＞
バーゼル銀行監督委員会は、世界各国の銀行監督当局・中央銀行の代表者が意思疎通・協議を行う機関であり、スイスのバーゼルにある国際決済銀行（ＢＩＳ）で開催される。信用リスクを対象とするバーゼルＩ（ＢＩＳ規制）は１９８８年に合意され、日本では１９９１年３月から適用開始、１９９３年３月から本格適用されている。自己資本比率は、自己資本の額（分子）をリスク資産（リスク・アセット）の総額（分母）で除した割合で示すこととし、その比率が８％以上となることを求めている（非特許文献３第２６頁）。

このバーゼルＩに対して、次の課題が見いだされた。課題１：金融取引の自由化・国際化・高度化と、銀行が抱えるリスクの多様化・複雑化と、リスク管理手法の高度化とに対応した監督手法の進化が必要。課題２：汎用性・簡便性を確保しつつ、リスク計測の精度（精密性及び正確性）を向上すること。課題３：リスク計測の漏れの防止。課題４：規制として統一性を有しつつもリスク管理技術の高度化を促す仕組み。課題５：銀行の自己責任による自主性と市場規律の強調（非特許文献３第５０頁から第５１頁）。

新たな自己資本比率規制（バーゼルＩＩ）は、１９９８年に見直し作業が開始され、２００４年に最終合意され、「自己資本の測定と基準に関する国際的統一化：改訂された枠組」（以下、「バーゼルＩＩテキスト」という）が公開された。このバーゼルＩＩテキストについては、一般社団法人全国銀行協会による日本語への仮訳案（平成１６年８月１２日掲載、平成２０年６月５日更新）がある。
バーゼルＩＩは３本の柱により構成されている。第１の柱は、自己資本比率規制であり、信用リスク、市場リスク、オペレーショナルリスクのリスク量に対する自己資本の比率を所定の算式で計算し、自己資本の質と量を確保させる仕組みである。第２の柱は、リスク管理と健全性の維持は銀行自身の責任において遂行され、監督当局はそれを検証することを原則として、監督当局は、例えば、各銀行の内部管理態勢（内部統制）の妥当性・有効性を検証・評価する仕組みである。第３の柱は、市場規律であり、自己資本比率をめぐる関連情報の開示を充実させ市場による評価を得る仕組みである（非特許文献３第５１頁から第６３頁）。
我が国では、上記のように、第１の柱に対して金融庁告示第１９号、第３の柱に対して金融庁告示第１５号、第２の柱に関して総合的な監督指針及び検査マニュアルが定められ、公開されている。

バーゼルＩＩでは、信用リスク管理に関しては、標準的手法と、内部格付手法とが用意されている。標準的手法は、財務会計上の金銭債権等の資産額をもとに、資産のカテゴリーや、外部格付や、担保や保証等の信用リスク削減手法の勘案や、資産の小口分散効果や、貸倒引当金による引当率を加味して、リスク・アセットを計算する手法である。
内部格付手法は、銀行内で測定した長期平均デフォルト率ＰＤを使用してリスク・アセットを計算する手法であり、当局設定のデフォルト時損失率ＬＧＤ及びデフォルト時エクスポージャーＥＡＤを用いる基礎的内部格付手法と、銀行内でＬＤＧ及びＥＡＤを測定する先進的内部格付手法とがある。

バーゼルＩＩによる自己資本比率の算式と信用リスク量の算式とは、バーゼルＩＩテキスト及び金融庁告示第１９号に規定されている。その内容の一部は、検査マニュアルの自己資本管理態勢の確認検査用チェックリストと、信用リスク管理態勢の確認検査用チェックリストとにまとめられている。自己資本比率を算出する算式の解説は非特許文献３の第７８頁から第２３０頁、内部格付手法により信用リスク量を算出する算式の解説は非特許文献３の第１３８頁から第１５２頁や非特許文献４に記載されている。

さらに、バーゼル銀行監督委員会は、２００８年に表面化した金融危機の経験に応じて、２０１０年１２月に「バーゼルＩＩＩ： より強靱な銀行及び銀行システムのためのグローバルな規制の枠組み」を公表した。バーゼルＩＩＩでは、自己資本の質を高めるため損失吸収性の高い資本の最低水準を定め、さらに自己資本比率の質と量の強化を図る規制（レバレッジ規制と流動性規制）が導入された。

＜資産査定＞
金融監督行政は、従前より早期是正措置制度等を採用している。その金融監督行政の基本は、銀行の自己資本比率であり、自己資本比率算定に使用する財務諸表を作成するには金銭債権の償却・引当が正確に行われることが必要であり、償却・引当を正確に行うにはその準備作業である銀行自らによる資産査定が適切に行われることが必要である。
資産査定とは、金融機関の保有する資産（金銭債権等）を個別に検討して、回収の危険性又は価値の毀損の危険性の度合いに従って区分することであり、金融機関自らが行う資産査定を自己査定という。自己査定は、金融機関が信用リスク管理をするための手段であると共に、適正な償却・引当を行うための準備作業である（非特許文献５第１８７頁：検査マニュアル、資産査定管理態勢の確認検査用チェックリスト、検証ポイント）。

金銭債権の自己査定は、債務者を区分し、債権を分類することである。債権は、貸出金及び貸出金に準ずる金銭債権（貸付有価証券、外国為替、未収利息、未収金、貸出金に準ずる仮払金、支払承諾見返）をいう。また、信用リスクの管理には、この債権以外に信用リスクを有する資産及びオフ・バランス項目が含まれる。

検査マニュアルは、資産査定管理態勢の確認検査用チェックリスト、自己査定（別表１）、１．債権の分類方法、（１）基本的な考え方として「債権の自己査定に当たっては、原則として、信用格付を行い、信用格付に基づき債務者区分を行った上で、債権の資金使途等の内容を個別に検討し、担保や保証等の状況を勘案の上、債権の回収の危険性又は価値の毀損の危険性の度合いに応じて分類を行うものとする」（非特許文献５第１９８頁）としている。
信用格付は、債務者のデフォルト率又は倒産確率に応じた格付であり、例えばＡ，Ｂ，Ｃの記号で特定する。債務者区分は、融資先である債務者を、その債務者の財務状況や収益力に応じて「正常先」「要注意先」「破綻懸念先」「実質破綻先」及び「破綻先」に区分するものである。信用格付は、債務者区分と整合的でなければならない。債務者区分では、その債務者が赤字か、延滞があるか、実質債務超過であるか等に着目し、財務内容や債務償還能力等を勘案して上記区分を行う。債権分類は、債務者区分と、担保や保証による保全状況とを考慮し、回収の可能性に応じて、Ｉ分類（非分類），ＩＩ分類、ＩＩＩ分類，ＩＶ分類に分類する。

＜債務者区分＞
債務者区分と債権分類と償却・引当との関係については、上記検査マニュアルの自己査定（別表１，非特許文献５第１９７頁から２２９頁）と、償却・引当（別表２，非特許文献第２３１頁から第２４７頁）に記載されている。この債務者区分及び債権分類の用語の意味や具体例は、非特許文献６第１２２頁から４１７頁等にも記載されている。
それぞれの債務者区分は言語を用いて次のように定義されている。
「正常先」とは、業況が良好であり、かつ、財務内容にも特段の問題がないと認められる債務者をいう。
「要注意先」とは、金利減免・棚上げを行っているなど貸出条件に問題のある債務者、元本返済もしくは利息支払いが事実上延滞しているなど履行状況に問題がある債務者のほか、業況が低調ないしは不安定な債務者又は財務内容に問題がある債務者など今後の管理に注意を要する債務者をいう。
「破綻懸念先」とは、現状、経営破綻の状況にはないが、経営難の状態にあり、経営改善計画の進捗状況が芳しくなく、今後、経営破綻に陥る可能性が大きいと認められる債務者（金融機関等の支援継続中の債務者を含む）をいう。具体的には、現状、事業を継続しているが、実質債務超過の状態に陥っており、業況が著しく低調で貸出金が延滞状態にあるなど元本及び利息の最終の回収について重大な懸念があり、従って損失の発生の可能性が高い状況で、今後、経営破綻に陥る可能性が大きいと認められる債務者をいう。
「実質破綻先」とは、法的・形式的な経営破綻の事実は発生していないものの、深刻な経営難の状態にあり、再建の見通しがない状況にあると認められるなど実質的に経営破綻に陥っている債務者をいう。具体的には、事業を形式的には継続しているが、財務内容において多額の不良資産を内包し、あるいは債務者の返済能力に比して明らかに過大な借入金が残存し、実質的に大幅な債務超過の状態に相当期間陥っており、事業好転の見通しがない状況で、元金又は利息について実質的に長期間延滞している債務者などをいう。
「破綻先」とは、法的・形式的な経営破綻の事実が発生している債務者をいい、例えば、破産、清算、会社整理、会社更正、和議、手形交換所の取引停止処分等の事由により経営破綻に陥っている債務者をいう。

このように、債務者区分では、債務者の財務状況、融資返済の延滞の有無や貸出条件変更の有無、収益力等の事業の状況等に着目して債務者を区分する。債務者を区分すると、続いて、債権の分類を行う。債権の分類においては、債務者区分と、債権（与信明細）の担保等による保全状況により調整する。

＜債権分類＞
「Ｉ分類（非分類）」は、「ＩＩ分類、ＩＩＩ分類、ＩＶ分類としない資産」であり、回収の危険性又は価値の毀損の危険性について、問題のない資産である。
「ＩＩ分類」とするものは、「債権確保上の諸条件が満足に満たされないため、あるいは、信用上疑義が存在する等の理由により、その回収について通常の度合いを超える危険を含むと認められる債権等の資産」である。なお、ＩＩ分類とするものには、一般担保・保証で保全されているものと保全されていないものとがある。
「ＩＩＩ分類」とするものは、「最終の回収又は価値について重大な懸念が存し、従って損失の可能性が高いが、その損失額について合理的な推計が困難な資産」である。但し、ＩＩＩ分類については、金融機関にとっての推計がまったく不可能とするものではなく、個々の資産の状況に精通している金融機関自らのルールと判断により損失額を見積もることが適当とされるものである。
「ＩＶ分類」とするものは、「回収不能又は無価値と判定される資産」である。なお、ＩＶ分類については、その資産が絶対的に回収不能又は無価値であるとするものではなく、また、将来において部分的な回収があり得るとしても、基本的に、査定基準日において回収不能額又は無価値と判定できる資産である。
銀行の債権には、種々のものがある。自己査定により、その総額を上記各分類に分類する。以下、「分類する」というときには、対象となる債権の全部又は該当部分をＩＩ分類以下のものと認定し、その額を算定することをいう。「分類しない」というときには、Ｉ分類とすることをいう。

債権分類に際しては、その担保等による保全状況によって調整する。貸し手は、借り手の信用リスクに応じて、融資に見合った担保の提供や、借り手以外の保証人による保証を求める。仮に、借り手が返済しない場合や、倒産する場合には、保証人にその債務を履行させ、または、裁判上の強制執行により担保を売却し、弁済を受ける。保証の種類としては、特定債務の保証と、銀行が手形を買い取る手形割引や当座貸越など継続的な取引から発生する債務を包括的に保証する根保証とに分けられる。担保としては、抵当権や質権等の物権の利用が多い。担保目的物としては、土地、建物等の不動産担保や、銀行（自行）に対する定期預金等を担保とする預金担保や、国債、株式等の有価証券担保などがある。

＜金融再生法＞
金融再生法では、債権区分を定めている。債権区分は、債権を、正常債権、要管理債権、危険債権、破産更正債権及びこれに準ずる債権に区分することをいう。金融再生法は、担保や保証の状況を考慮せず、この債権区分に係る資産の合計額等を公表しなければならない旨定めている。債務者区分との関係は次の通りであり、非特許文献６では、第１４２頁から第１５１頁に記載されている。
正常債権 国及び地方公共団体に対する債権、特別公的管理銀行及び被管理金融機関に対する債権、正常先に対する債権、及び要注意先に対する債権のうち要管理債権に該当する債権以外の債権。
要管理債権 要注意先に対する債権のうち、３ヶ月以上延滞債権及び貸出条件緩和債権
危険債権 破綻懸念先に対する債権
破産更正債権及びこれらに準ずる債権 実質破綻先及び破綻先に対する債権
上記「貸出条件緩和債権」は、経済的困難に陥った債務者の再建又は支援を図り、当該債権の回収を促進すること等を目的に、債務者に有利な一定の譲歩を与える約定条件の改定等を行った貸出債権（破産更正債権及びこれらに準ずる債権，危険債権及び３ヶ月以上延滞債権を除く）である。

＜リスク管理債権＞
銀行法２１条は、リスク管理債権を営業年度ごとに業務及び財産の状況に関する事項を記載した説明書類を公衆の縦覧に供しなければならない旨定めている。業務及び財産の状況には、破綻先債権、延滞債権、３ヶ月以上延滞債権、貸出条件緩和債権の４種類の貸出金が含まれている。これをリスク管理債権という。非特許文献６では、第１４６頁から第１４７頁に記載されている。

＜償却・引当＞
債務者区分と債権分類とに基づいて、償却・引当を行う。償却・引当は、企業の会計原則に従って、かつ、検査マニュアルの指摘に沿って処理する。償却（貸倒償却、貸倒損失）は、税法に準拠することが多く（有税償却）、会社更生法による更正計画認可決定等の法律上の手続きによる債権消滅時に、債権の回収を不能として償却する。従って、破綻懸念先等のＩＩＩ分類等は、償却とならない。これらの分類額について、税法上損金とならないが、会計上償却とすることもある（無税償却）。償却・引当については、非特許文献６第４５３頁から第５１３頁に記載されている。

銀行の償却・引当は、正常先及び要注意先の債権については一般貸倒引当金を算出し、破綻懸念先以下については、個別貸倒引当金を算出する。
一般貸倒引当金については、正常先に対する債権及び要注意先に対する債権について、信用格付の区分又は債務者区分毎に、償却・引当基準に基づき、予想損失額を合理的に見積もる。信用格付の区分毎に予想損失額を見積もる場合には、債権を分類した自己査定の査定結果による債務者区分と、その時点での信用格付とが整合的でなければならない。

正常先及び要注意先に対する債権について、原則として信用格付の区分（少なくとも債務者区分）毎に、信用格付の区分の債権額に当該信用格付の予想損失率を乗じて予想損失額を算定し、この予想損失額を一般貸倒引当金とする（非特許文献５第２３２頁、非特許文献６第４６８頁から第４７４頁）。予想損失率は、過去の貸倒実績率又は倒産確率に基づいて求める。また、要管理債権を有する要注意先（要管理先）の大口債務者や、要管理先又は破綻懸念先からその他要注意先に上位遷移した大口債務者は、ＤＣＦ法を採用して元本と債権評価額との差額を個別に計算しつつ、一般貸倒引当金に計上する（非特許文献５第２３７頁から２３９頁、非特許文献６第４６１頁から第４６７頁）。

破綻懸念先に対する債権については、優良担保・保証部分が非分類、一般担保の処分可能見込額及び一般保証による回収が可能と見込まれる部分については、ＩＩ分類、その他はＩＩＩ分類となる。
破綻懸念先に対する債権の引当では、ＩＩＩ分類とされた債権額に予想損失率を乗じた額を予想損失額として個別貸倒引当金に計上する。予想損失率は、原則として個別債務者毎に、経済状況の変化、債務者の業況見込み、債務者の営業地区における地域経済の状況等を斟酌の上、過去の貸倒実績率又は倒産確率に将来の予測を踏まえた必要な修正を加えて決定する（非特許文献５第２４１頁、非特許文献６第４７９頁から第４８４頁）。
また、金銭債権を売却可能な市場を有する債権について、合理的に算定された売却可能額を回収見込額とし、債権額から回収見込額を控除した残額を予想損失額とする方法もある。そして、大口債務者については、ＤＣＦ法を適用することが望ましいとされている。

実質破綻先及び破綻先（以下、（実質）破綻先という）に対する債権については、優良担保・保証部分が非分類、一般担保の処分可能見込額及び一般保証による回収が可能と見込まれる部分については、ＩＩ分類、担保の評価額と、処分可能見込額との差額については、ＩＩＩ分類となり、保全のない部分については、ＩＶ分類となる。（実質）破綻先のＩＩＩ分類及びＩＶ分類については、全額を個別貸倒引当金として計上するか、又は直接償却する（非特許文献５第２４３頁、非特許文献６第４８５頁から第４８６頁）。

＜財務分析と信用リスク管理＞
債務者の財務諸表に基づいて、財務分析を行い、信用格付を区分することは、古くより行われている。財務分析は、Ｐ／ＬやＢ／Ｓで公表された計数から種々の比率を算出し、その比率から収益性、成長性、安全性等の財務内容を判断するものである。例えば、安全性の指標である流動比率は、流動資産／流動負債と定義され、１年以内に現金化できる資産と、１年以内に返済等しなければならない負債との比率であり、短期の資金繰りが良好であるか否か等を表す。流動資産のうち、特に早期に現金化できる流動資産を用いて算出する当座比率は、短期の返済能力を表すとされている。固定資産と長期資産の関係は、固定資産／資本である固定比率や、固定資産／（資本＋固定負債）である固定長期適合率等を用いる。これらの値が１００％よりも大きいと、短期資金を固定資産に投下していることとなり、資金繰りが不安定となる。
Ｐ／Ｌに基づく指標としては、例えば、インタレスト・カバレッジ・レシオがある。これは、利息を支払うのに十分な利益が獲得できているか否かを判断するために、利益の金額を利息の金額で割って計算される比率であり、Ｐ／Ｌに基づくことから、債務者の支払能力の変化を早期に把握することができる。この比率やその推移により、借入金の返済能力を評価することができる。

債務者区分については、例えば、赤字企業が正常先であるかそれとも要注意先であるかについては、正常先と判断できる基準が示される一方、本基準を機械的・画一的に適用してはならず、業種の特性、業況、赤字決算の原因、企業の内部留保の状況、今後の決算見込み等を総合的に勘案して行うものとしている。従って、赤字企業については、機械的、自動的な判断を行うことができず、自己査定作業にて作業者が個別に判断しなければならない。

銀行の信用リスク管理としては、会計原則及び検査マニュアル等に沿って、決算検討（債務者の財務分析等）、債務者の信用格付、自己査定による債務者区分及び債権分類、自己査定結果及びこれと整合した信用格付に基づいた償却・引当、さらに自己資本比率を算出する。信用格付及び自己査定については、債務者の数が多く、また、単純な計算ではなく種々の判断が必要であるため、市販のアプリケーションソフトウエアをそのまま利用しても、銀行全体として均質で精度良い判断を行うことはできない。

＜信用リスク管理等にコンピュータシステムを利用する従来例＞
特許文献１には、与信先の信用リスクをタイムリーに再評価することなどを目的として、債務者の決算検討など定期的に発生する事象に応じて与信先の信用格付を行う定期モニタリング工程と、延滞・金利減免など特許文献１の図４に示される不定期に生じる事象が生じたときに、与信先の信用格付を行う経常モニタリング工程とを備えた手法（段落００４３から００４５）が開示されている。

特許文献１の経常モニタリング工程では、特許文献１の図４等に示される事象が生じたとき、又は、延滞の発生から一定期間経過後に、自己査定を行う。自己査定の結果、要注意先以下と判断された場合には、信用格付の変更を行う。この特許文献１では、債務者の公表財務を詳細に検討すべき先の数を減らし、自己査定作業の対象先の数を減らし、一方、債務者の状況に変化が生じた場合には、経常モニタリングとして随時に自己査定及び信用格付の変更とを行っている。

特許文献２には、自己査定業務を効率的に行うことを目的として、財務指標と、信用格付との自動算出を行い、さらに、必要な追加格付と、自己査定額算出用の債務者格付を行い、保全情報と貸金明細情報とから自己査定額を自動算出する手法（段落第００４６から段落００７１、図２）が開示されている。

特許文献３には、自己査定の精度向上と事務合理化の両立を図ることを目的として、自動起票と手動起票とを可能としつつ、同一の債務者について重複して起票された際には重複を表示し、一方の取消を促す手法が開示されている。

特許文献４には、取引先に関する文字データの柔軟な取扱及び他システムとの良好な連携を維持することを目的として、取引先の組織の内容を示す組織データと、事業の内容を示す事業データと、当該取引先の主要動向を示す動向コメントデータとの入力及び編集を制御し、当該入力及び編集された文字データと、他システムから自動的に取得する文字データとを一体的な体系で要項データとして管理する手法が開示されている。

特許文献５には、融資等の稟議書の起案及び回付（回覧）、決裁処理を少ないコンピュータ資源を用いて迅速かつ効率的に行うことを目的として、各営業店の担当者が、顧客特定情報と稟議書の種別情報とを入力し、対応する稟議書の作成及び回付に必要な情報をダウンロードし、このダウンロードした情報に基づいて稟議書の作成を行う仕組みが開示されている。
この従来例では、融資の実行を起案するための融資稟議では、その稟議書の作成・決裁の効率化・迅速化を図るため、その作成に用いる語句は極力簡便に表現されるべきであり、その意味については記載されないことから、金融の専門用語に不慣れな新入行員などの初心者にとって、稟議書の作成は困難であるとの課題が指摘されている（特許文献５，段落０００８等）。そして、本部で管理されている顧客に関するデータから、当該顧客に財務上の問題点があることが明らかな場合には、ダウンロード直後の表示画面等で起案者に知らせる等の処理を行っている。また、稟議書作成に関して不足している情報が存在している場合には、不足情報の入力後に再ダウンロードするか否か等の判断を起案者に行わせるなどして、注意喚起を行っている（特許文献５，段落００５６）。また、稟議書作成誘導部が、必須入力画面等を生成し、各画面中の情報を修正し、また追加することで、各画面を完成させ、当該顧客の稟議書として適正化される旨、開示されている（特許文献５，段落００５７から６０）。

特許文献６には、融資審査を効率的に行うことを目的として、直前の業務が処理されない限り次の業務を処理できないように管理する手法が開示されている。例えば、実態財務データが作成されない限り、自己査定の自動判定を行う判定ボタンは出現しないようになっており、融資担当者は、予め定められた手順以外の順序で電子的な稟議書を起票することができず、融資審査に恣意性が入り込むのを防止する手法（段落００４４）が開示されている

特許文献７は、金融関連ではないが、ワークフローシステムにて電子書類を差し戻す方法について開示されている。この従来例では、ワークフローを使用した業務において、書類不備発生時に効率的に書類を差し戻すことを目的として、電子書類内の情報項目毎に文責者の識別情報を登録しておき、任意の担当者端末にて差戻し操作がなされた場合には、その差し戻す情報項目に対応する文責者をシステム的に特定する手法が開示されている。

特許文献８では、金融関連ではないが、複数の画面を用いて情報設定作業を行うインタフェース装置にて、「次へ」ボタンと「戻る」ボタンにて一画面ずつ画面推移させると共に、画面名リスト等を操作することで、画面名リストを使用して選択された画面へ直接移動するインタフェースを提供する仕組みが開示されている。

＜内部統制＞
信用リスク管理に関するコンピュータシステムの開発に際しては、各種の内部統制の要請と整合的であることが求められる。内部統制（インターナル・コントロール）は、業務の品質・信頼性を向上させるための業務上のプロセスである。バーゼル銀行監督委員会は１９９８年「銀行組織における内部管理体制のフレームワーク」を公表した。検査マニュアルは、各種の内部統制フレームワークを底流とし、例えばプロセス・チェックを重視している。
さらに、内部統制は、2005年経済産業省の報告書にて「企業経営者の経営戦略や事業目的等を組織として機能させ達成していくための仕組み」と定義されている（「コーポレート・ガバナンス及びリスク管理・内部統制に関する開示・評価の枠組みについて-構築及び開示のための指針-」、非特許文献７第２頁から第３頁）。
財務報告に係る内部統制の評価及び監査の基準では、「内部統制とは、基本的に、業務の有効性及び効率性、財務報告の信頼性、事業活動に関わる法令等の遵守並びに資産の保全の４つの目的が達成されているとの合理的な保証を得るために、業務に組み込まれ、組織内のすべての者によって遂行されるプロセスをいい、統制環境、リスクの評価と対応、統制活動、情報と伝達、モニタリング（監視活動）及びＩＴ（情報技術）への対応の６つの基本的要素から構成される。」と定義する（非特許文献８第２頁）。
バーゼルＩＩテキスト第７４４パラグラフで、自己資本の評価に際して銀行がどのような内部統制を有しているかは重要であり、銀行の取締役会の責任として、様々なリスクを評価するためのシステムの構築を挙げている。
また、バーゼル銀行監督委員会「実効的な銀行監督のためのコアとなる諸原則」（２００６年１０月）は、原則１７： 内部統制及び監査として、「監督当局は、銀行が業務の規模や複雑性に照らして適切な内部統制機能を有していることを確認しなければならない。」と述べている。

検査マニュアルでは、経営管理態勢、法令等遵守態勢、顧客保護等管理態勢、統合的リスク管理態勢、自己資本管理態勢、信用リスク管理態勢、資産査定管理態勢などの「態勢」を確認検査するためのチェックリストが充実したが、これらのリストは、内部統制の要素であるとも考えられる。そして、自己資本比率の算出に際して内部格付手法を採用しようとする際には、内部統制について一定の基準を満たし独立した信用リスク管理部署を設け、内部監査の対象とすることが求められている（金融庁告示第１９号第２０１条、２０２条、２０３条）。

検査マニュアルは、経営管理態勢について「取締役会は、経営方針に則り、代表取締役等に委任することなく、当該金融機関の全体の収益目標及びそれに向けたリスクテイクや人的・物的資源配分の戦略を定めた当該金融機関全体の戦略目標を明確に定めているか」と、収益目標、リスクテイク及び人的・物的資源配分に関する戦略目標の定めを要請する。さらに、自己資本管理態勢では、自己資本管理方針の整備・周知を要請し「取締役は、自己資本管理を軽視することが戦略目標の達成に重大な影響を与えることを十分に認識し、自己資本管理を重視しているか」を確認することとしている。

自己資本管理部門は自己資本管理規程に従い自己資本充実度を評価することとなるが、検査マニュアルは、「自己資本管理部門は、与信集中リスク及び銀行勘定の金利リスクを自己資本充実度の評価における管理対象とし、また、自己資本比率の算定において対象としていないリスクについても管理対象とすべきかを検討しているか」を確認する。そして、自己資本充実度の評価に際しては、「期待損失ＥＬに対する貸倒引当金の過不足を考慮しているか」を確認することとしている。

このように、検査マニュアルによると、自己資本の充実は収益目標を含めた戦略目標の達成に重要であり、自己資本比率の算定で考慮されないリスクをも管理対象とする一方、期待損失ＥＬと貸倒引当金との対比を求めている。バーゼルＩＩや金融庁告示第１９号等は、期待損失ＥＬや非期待損失ＵＬの算出（内部格付手法の採用）に際して、内部統制の構築・運用を求めている。貸倒引当金の算定では、検査マニュアルの資産査定管理態勢の確認用チェックリストとその別表１，２に従った信用格付、債務者区分及び債権分類をし、償却・引当を厳格に行わなければならない。

自己資本比率の算定は、銀行の内部統制としては、自己資本充実度の評価の一部である。この自己資本比率の算定は、非期待損失ＵＬ額という信用リスクを信頼区間99.9%で金額評価したリスク量と、自己資本とを対比するものである。一方、貸倒引当金及び償却額の算定は、企業会計原則に従い、予想される損失を費用（コスト）として保守的に求めるものである。そして、非期待損失ＵＬ額の算定で使用する期待損失ＥＬと、貸倒引当金とを対比することが求められる。

内部統制が機能する態勢で自己資本比率算定のパラメーター（債務者格付、長期平均デフォルト率ＰＤ、デフォルト時損失率ＬＧＤ等）を推計すると共に、推計されたパラメーターは、「内部格付手法採用行の与信審査、リスク管理、内部の資本配賦及び内部統制において、重要な役割を果たすものでなければならない。（金融庁告示第１９号第２０４条，バーゼルＩＩテキスト第４４４パラグラフ）」

２００５年会社法制定前から、判例は、取締役の善良なる管理者の注意義務として、内部統制の構築義務を認めていた（非特許文献７第１６頁から第２４頁）。２００５年会社法第３６２条第４項第６号は、取締役会の義務として「取締役の職務の執行が法令及び定款に適合することを確保するための体制その他株式会社の業務の適正を確保するために必要なものとして法務省令で定める体制の整備」を定めている。また、会社法施行規則第１００条（業務の適正を確保するための体制）は、次の通り規定する。
一 取締役の職務の執行に係る情報の保存及び管理に関する体制
二 損失の危険の管理に関する規程その他の体制
三 取締役の職務の執行が効率的に行われることを確保するための体制
四 使用人の職務の執行が法令及び定款に適合することを確保するための体制
五 当該株式会社並びにその親会社及び子会社から成る企業集団における業務の適正を確保するための体制
１号は、情報の保存及び管理、２号はリスク管理、３号は効率性、４号は法令等違反行為の把握、監視、予防等である（非特許文献７，第７８頁から第８０頁）。

２００６年金融商品取引法により、財務計算に関する書類その他の情報の適正性を確保するための体制を評価した報告書（内部統制報告書）の提出（同法第２４条の４の４）、公認会計士、監査法人による内部統制報告書の監査（同法第１９３条の２第２項）が法制化された。非特許文献８は、企業会計審議会による財務報告に係る内部統制の評価及び監査の基準と実施基準の改訂についての意見書である。財務報告に係る内部統制は、次の４つの目的を達成するために６つの基本要素から構築される。

・企業の４つの目的：
1. 業務の有効性及び効率性： 事業目的を達成するための有効性及び効率性。
2. 財務報告の信頼性： 財務諸表に関する情報の信頼性の確保。
3. 事業活動に関わる法令等の遵守： 事業活動に関わる法令そのた規範の遵守。
4. 資産の保全： 資産の取得、使用及び処分が正当な手続及び承認の下に行われるようにすること。

・６つの基本的要素：
1. 統制環境： 組織の気風を決定し組織内全ての者の統制に対する意識に影響を与え、他の基本的要素の基礎となる基盤。
2. リスクの評価と対応： 組織目標の達成に影響を与える事象について、組織目標の達成を阻害する要因をリスクとして識別、分析及び評価し、当該リスクへ適切な対応を行う一連のプロセス。
3. 統制活動： 経営者の命令及び指示が適切に実行されることを確保するために定める方針及び手続で、業務プロセスに組み込まれるべきものであり、組織内の全ての者において遂行されることにより機能する。
4. 情報と伝達： 必要な情報が識別、把握及び処理され、組織内外及び関係者相互に正しく伝えられることを確保することをいう。一般に、人的及び機械化された情報システムが利用される。
5. モニタリング： 内部統制が有効に機能していることを継続的に評価するプロセス。
6. ＩＴへの対応： 組織目標を達成するために、予め適切な方針及び手続を定め、それを踏まえて、業務の実施において組織の内外のＩＴに対して適切に対応することをいい、ＩＴ環境への対応と、ＩＴの利用及び統制からなる。

ＩＴへの対応は、ＩＴの利用は、ＩＴを利用することにより、上記６つの基本的要素の有効性を確保することである。ＩＴの統制は、ＩＴ自体を内部統制の対象とし、ＩＴの統制目標を次の通りとしている。
・ＩＴの利用と内部統制の基本的要素
1. 統制環境の有効性の確保： ＩＴを利用することで組織の基本的方針や決定事項等を組織の適切な者に適時に伝達することを可能にする等。
2. リスクの評価と対応の有効性の確保： リスクの測定とリスク情報の共有をＩＴの利用により効率的に行うことができる。
3. 統制活動の有効性を確保するためのＩＴの利用： ＩＴを利用した統制活動を、適切に設計して業務プロセスに組み込むことにより、統制活動の自動化が可能となる。このＩＴによる自動化により、手作業による統制活動（マニュアル統制）に比べて迅速な情報処理が期待できるほか、人間の不注意による誤謬等の防止も可能となる。一方で、プログラムの不正な改ざん等があった場合には、不正等の適時の発見が困難という問題点も考えられる。
このように統制活動の有効性を確保するためのＩＴの利用では、ＩＴが業務プロセスに求められる様々な要請に対して明確に準拠していることが必須である。準拠性は確保しなければならず、技術的課題としては、そのコストをどのように低減させるかが問題となる。
4. 情報と伝達の有効性の確保： 必要な承認や作業完了が一定期間に実施されない際にはその旨が上司に伝達される機能など、業務管理に必要な情報の伝達を業務プロセスに組み込むことができる。
5.モニタリングの有効性の確保： 日常的モニタリングは、業務管理システムに組み込み自動化することでより網羅的に実施することが可能となる。その結果、財務報告の信頼性を阻害する要因（リスク）の評価を低く見積もることが可能となる。

・ＩＴの統制目標
1.有効性及び効率性： 情報が業務に対して効果的、効率的に提供されていること。
2.準拠性： 情報が関連する法令や会計基準、社内規則等に合致して処理されていること。
3.信頼性： 情報が組織の意思・意図に沿って承認され、漏れなく正確に記録・処理されること（正当性、完全性、正確性）。
4.可用性： 情報が必要とされるときに利用可能であること。
5.機密性： 情報が正当な権限を有する者以外に利用されないように保護されていること。

内部統制に求められる性質を整理すると、次の通りとなる。
（１）．銀行法、バーゼルＩＩ、金融庁告示１９号等、検査マニュアル
（１．１）．健全性： 健全性は、銀行の財務の健全性であり、上記銀行法、バーゼルＩＩ、金融庁告示、検査マニュアルの要請は、全て健全性を確保するための要請である。健全性は、リスク量に対して適切な自己資本を有することとして定量化される。
収益向上可能性： 健全性を確保するために自己資本を充実するには、収益力が高くなければならない。
損失発生防止可能性： 健全性を確保するために自己資本を充実するには、損失の発生を防止しなければならない。
（１．２）．適切性： 適切性は、銀行の業務の適切性であり、業務の適切性を確保するためには、法令等へ準拠性、統合的管理性及び適時報告性が必要である。

（２）．適正［会社法］
会社法の要請する内部統制は、主に、不祥事の発生などを防止することであり、損失派生防止とも考えられる、会社法の要請する内部統制は、情報の管理、信頼性、保存性、検索性、可用性、リスク管理、内部監査、を要素としている。

（３）．財務報告の信頼性（金融商品取引法・実施基準）
（３．１）ＩＴの利用
上記の通り、財務報告の信頼性確保のための内部統制は、ＩＴの利用が推奨されている。そして、当該内部統制の基本的要素である統制環境の有効性、リスクの評価と対応の有効性、統制活動の有効性、情報の伝達の有効性及びモニタリングの有効性の確保をＩＴの利用により行うことが望ましい。
（３．２）ＩＴの統制
ＩＴの統制としては、有効性及び効率性、準拠性、信頼性、可用性、機密性がある。
本明細書にて、「内部統制の質の向上」という際には、上記内部統制の有効性を確保し、向上させ、または、一定の質を維持しつつ所要費用を低減することをいう。

以下、先行技術文献一覧を開示する。下記特許文献のうち、特許文献３及び４は、本願と同一の出願人による出願である。その他、下記特許文献は、本出願の発明者が技術的思想の創作に際して参照した文献ではなく、本願の特許性を判断するために、発明完成後に調査したものである。また、出願人は本発明の前提となる信用リスク管理に関連して種々の規定、要領、ガイドライン、Ｑ＆Ａ等を作成しているが、これらの文献は非公開である。
このため、検査マニュアルでの用語や、融資の態様等の銀行取引や、財務会計、財務分析や、銀行決算の実務などについては、内部資料の公開ではなく、対応事項が記載されており、すでに公開されている書籍を非特許文献として引用した。これらの書籍も、本発明の技術的意義の理解を容易とする観点から本願の出願用に選定したものであり、発明の参照文献であったとは限らない。また、金融取引に関連する主要な用語の定義については上述したが、さらなる詳細や背景については下記文献等を参照されたい。

特開２００２-２３０２９７号公報（図３，段落００１７，００４４等） 特開２００３-１６２６３７号公報 特許第３７１４４６８号公報（図４、図７等） 特許第４３７３６４２号公報（図３等） 特開２００２-１４０６５６号公報（図８，段落００５６，００７４等） 特開２００５-１３４９３７号公報 特開平９-３４９４８号公報（図３，図７等） 特開平１１-２０３１１８号公報（図２，段落００２８から００３９）

酒井良清・鹿野嘉昭著，「金融システム」，株式会社有斐閣，第４版，２０１１年１１月，ＩＳＢＮ978-4-641-12449-3 桜井久勝著，「財務会計講義」，株式会社中央経済社，第１３版，２０１２年３月，ＩＳＢＮ978-4-502-45140-9 佐藤隆文編著，「バーゼルＩＩと銀行監督 新しい自己資本比率規制」，東洋経済新報社，初版，２００７年４月，ＩＳＢＮ978-4-492-65394-4 監査法人トーマツ金融インダストリーグループ編，「バーゼルII対応のすべて リスク管理と銀行経営」，社団法人金融財政事情研究会，２００８年３月，ＩＳＢＮ978-4-322-11200-9 金融庁，「預金等受入金融機関に係る検査マニュアル」，[online]，１９９９年７月（改訂：２０１２年５月），金融庁，［２０１２年５月検索］， インターネット＜ＵＲＬ：www.fsa.go.jp＞ 検査マニュアル研究会編，「金融機関の信用リスク・資産査定管理態勢 平成２３年度版 検査マニュアルハンドブックシリーズ」，社団法人金融財政事情研究会，第１版，２０１１年１０月，ＩＳＢＮ978-4-322-11914-5 経済産業省企業行動課編，「コーポレート・ガバナンスと内部統制 信頼される経営のために」，（財）経済産業調査会，初版，平成２００７年１月，ＩＳＢＮ978-4-8065-2765-7 企業会計審議会，「財務報告に係る内部統制の評価及び監査の基準並びに財務報告に係る内部統制の評価及び監査に関する実施基準の改訂について（意見書）」，[online]，２０１１年３月３０日，金融庁，［２０１２年５月検索］，インターネット＜ＵＲＬ：www.fsa.go.jp＞

上記特許文献１から８、非特許文献１から８、及び、これらを組み合わせた技術では、創意工夫されたコンピュータシステムの活用により、個別の判断についての整合性と、個別の判断相互の整合性とを確保するために、判断の基準を統一するのみならず、コンピュータシステムの情報処理を利用して判断の過程を統一する業務プロセスを構築し、さらに、信用リスク管理及び資産査定に関してＩＴを利用した内部統制の質を向上させることができない、という不都合があった。

［発明の目的］本発明の目的は、銀行業務に関して、整合的判断の積み上げをＩＴの利用により統制し、複数の担当者間によるリスク評価の均質性を確保し、データの可用性を高めることのできる銀行業務処理システム、資産査定方法とプログラムを提供することにある。

［着眼点］本発明の発明者は、従来の帳票による作業では、銀行業務の処理結果について監査等の観点で検証する際に、作業の担当者がどのような手順で作業を行い、どの範囲で整合性の確認をしたのかについて把握することが難しい、という点に着目した。すなわち、帳票では、帳票に記入した作業者が、どの部分から記載を始め、どのような順序で作業し、また修正をしたのかという作業プロセスについて、監査部門等で検証することはできない。
そして、個別の判断についての整合性や、個別の判断相互の整合性の確保のために、判断の基準や手順を統一するのみならず、コンピュータシステムの情報処理を利用して判断の過程を統一できるのではないか、との着想に至った。

上記目的を達成するため、本発明に係る銀行業務処理システムは、リスク評価を含む複数の関連するタスクからなる銀行業務の担当者によって使用される端末とネットワークを介して接続されたコンピュータシステムを有している。このコンピュータシステムが、基礎データ、入力データ、導出データ及び査定データを作業対象毎に有する作業データを格納する作業データ格納部と、端末の画面に表示する画面要素の入力編集可否及び配置を定義する画面定義情報を銀行業務のタスク毎に格納する画面定義情報格納部と、タスク毎に画面定義情報に従って作業データを端末に表示制御すると共に当該端末の画面要素への操作に応じて入力される入力データと、当該入力データを使用して導出する導出データと、作業対象への担当者によるリスク評価を含む査定データとを作業データ格納部に格納するタスク処理部と、画面要素の操作により端末から送信される推移コマンドに応じて、当該タスク間の推移を、作業対象を特定する開始画面から当該担当者による査定データを確定する終了画面に向けて、複数のタスクの推移を一方向に制御する進捗制御部とを備えている。
そして、この進捗制御部は、作業中のタスクより開始画面側にあり担当者の任意で指定されるタスクにジャンプして戻るジャンプ戻り要求を推移コマンドとして受信した際には、作業中であったタスクとは別の一以上のタスクを開始画面側に向けて飛び越して、当該任意で指定された当該ジャンプ戻り先のタスクを現タスクに特定する戻りタスク特定処理とを備えている。
さらに、タスク処理部が、画面定義情報に従って、タスクのために入力され又は導出したリスク評価に関する作業データの一部を、一以上の別のタスクの作業後に作業中である現タスクの画面に入力編集不可で再表示することで、当該再表示した作業データの修正に際して、当該作業データを入力したタスクに、一以上の別のタスクを飛び越すことでジャンプして戻ることを当該担当者に促す強制再表示処理を備えている。
そして、次タスク特定処理が、戻りタスク特定処理によるジャンプ戻り先のタスクを作業完了の現タスクとする次タスク照会要求を受信した際に、当該ジャンプ戻り先である当該現タスクまでの作業データ及び当該現タスクから予め唯一に定められた次タスクを特定することで、再表示の画面までジャンプして進むジャンプ進みを禁止した、という構成を採っている。
これにより、上記課題を解決した。

上記目的を達成するため、本発明に係る銀行業務処理方法は、銀行業務処理システムを使用して銀行業務を処理する方法であって、タスク毎に画面定義情報に従って作業データを端末に表示制御すると共に当該端末の画面要素への操作に応じて入力される入力データと、当該入力データを使用して導出する導出データと、作業対象への担当者によるリスク評価を含む査定データとを作業データ格納部に格納するタスク処理工程と、画面要素の操作により端末から送信される推移コマンドに応じて、当該タスク間の推移を、作業対象を特定する開始画面から当該担当者による査定データを確定する終了画面に向けて、複数のタスクの推移を一方向に制御する進捗制御工程とを備えている。
そして、この進捗制御工程は、作業完了した現タスクの次に作業するタスクを要求する次タスク照会要求を推移コマンドとして受信した際には、当該現タスクまでの作業データ及び当該現タスクから予め唯一に定められた次タスクを特定する次タスク特定工程と、作業中のタスクより開始画面側にあり担当者の任意で指定されるタスクにジャンプして戻るジャンプ戻り要求を推移コマンドとして受信した際には、作業中であったタスクとは別の一以上のタスクを開始画面側に向けて飛び越して、当該任意で指定された当該ジャンプ戻り先のタスクを現タスクに特定する戻りタスク特定工程とを備えている。
そして、タスク処理工程が、画面定義情報に従って、タスクのために入力され又は導出したリスク評価に関する作業データの一部を、一以上の別のタスクの作業後に作業中である現タスクの画面に入力編集不可で再表示することで、当該再表示した作業データの修正に際して、当該作業データを入力したタスクに、一以上の別のタスクを飛び越すことでジャンプして戻ることを当該担当者に促す強制再表示処理工程を備えている。
さらに、次タスク特定工程が、戻りタスク特定工程によるジャンプ戻り先のタスクを作業完了の現タスクとする次タスク照会要求を受信した際に、当該ジャンプ戻り先である当該現タスクまでの作業データ及び当該現タスクから予め唯一に定められた次タスクを特定することで、再表示の画面までジャンプして進むジャンプ進みを禁止した、という構成を採っている。
これにより、上記課題を解決した。

上記目的を達成するため、本発明に係る銀行業務処理用プログラムは、上記コンピュータに、タスク毎に画面定義情報に従って作業データを端末に表示制御すると共に当該端末の画面要素への操作に応じて入力される入力データと、当該入力データを使用して導出する導出データと、作業対象への担当者によるリスク評価を含む査定データとを作業データ格納部に格納するタスク処理手順と、画面要素の操作により端末から送信される推移コマンドに応じて、当該タスク間の推移を、作業対象を特定する開始画面から当該担当者による査定データを確定する終了画面に向けて、複数のタスクの推移を一方向に制御する進捗制御手順とを実行させる。
さらに、作業完了した現タスクの次に作業するタスクを要求する次タスク照会要求を推移コマンドとして受信した際には、当該現タスクまでの作業データ及び当該現タスクから予め唯一に定められた次タスクを特定する次タスク特定手順と、作業中のタスクより開始画面側にあり担当者の任意で指定されるタスクにジャンプして戻るジャンプ戻り要求を推移コマンドとして受信した際には、作業中であったタスクとは別の一以上のタスクを開始画面側に向けて飛び越して、当該任意で指定された当該ジャンプ戻り先のタスクを現タスクに特定する戻りタスク特定手順とを実行させる。
さらに、画面定義情報に従って、タスクのために入力され又は導出したリスク評価に関する作業データの一部を、一以上の別のタスクの作業後に作業中である現タスクの画面に入力編集不可で再表示することで、当該再表示した作業データの修正に際して、当該作業データを入力したタスクに、一以上の別のタスクを飛び越すことでジャンプして戻ることを当該担当者に促す強制再表示処理手順と、戻りタスク特定手順によるジャンプ戻り先のタスクを作業完了の現タスクとする次タスク照会要求を受信した際に、当該ジャンプ戻り先である当該現タスクまでの作業データ及び当該現タスクから予め唯一に定められた次タスクを特定することで、再表示の画面までジャンプして進むジャンプ進みを禁止する手順とを実行させる、という構成を採っている。
これにより、上記課題を解決した。

本発明の銀行業務処理システムは以上のように構成され機能するので、これによると、強制再表示処理が、リスク評価に関する作業データの一部を、一以上の別のタスクの作業後の画面に入力編集不可で再表示することで、当該再表示した作業データの修正に際して、当該作業データを入力したタスクに、一以上の別のタスクを飛び越すことでジャンプして戻ることを当該担当者に促し、戻りタスク特定処理が、ジャンプ戻り要求を受信した際に、当該画面要素への操作により指定された当該ジャンプ戻り先のタスクを特定することで、作業中のタスクより開始画面側にある画面へジャンプして戻す。そして、次タスク特定処理は、次タスク照会要求を受信した際に、ジャンプ戻り後に作業完了した現タスクの作業データ及び現タスクから予め唯一に定められる次タスクを特定することで、再表示の画面へのジャンプ進みを禁止する。このため、ジャンプして戻ることはできるが、ジャンプして進むことはできず、終了画面に至るまでには、必ず唯一の順序に従った画面推移がなされ、このため、ＩＴの利用により全てのユーザに対して整合的判断を積み重ねる判断過程を統一する作用を営む。この判断過程統一作用により、本発明により得られる作業データは必ず一定の順序での思考が積み重なった判断であることが保証され、これにより、作業データに誤り・誤解又は不整合が含まれる可能性をＩＴの利用により予防することができる。そして、判断過程の統一により、リスク評価に関する担当者間の判断の均質性をＩＴ統制により予防的に確保し、内部統制の質を向上させ、リスク評価に関するデータの可用性を向上させることで、リスク管理の精度を高めることができる。
銀行業務処理方法及びプログラムについても同様である。

図１は、本実施形態の構成を示すブロック図である。 図２は、本実施形態で使用するデータの一例を示す説明図である。 図３は、画面定義情報の一例を示す説明図であり、図３（Ａ）は画像情報のデータ構造の一例を示す図で、図３（Ｂ）は画面要素と要素属性情報の一例を示す図である。 図４は、画面推移を一方向とするための進捗データのデータ構造を示す説明図であり、図４（Ａ）は、連結リストによる例を示し、図４（Ｂ）はスタックを参照する例を示し、図４（Ｃ）はテーブルを参照する例を示す図である。 図５は、本発明の実施形態の技術的課題と、構成と、作用効果との関係を示す説明図である。 図６は、本発明の各実施例の技術的課題と、構成と、作用効果との関係を示す説明図である。 図７は、本発明の実施例１の構成例を示すブロック図である。 図８は、進捗ステータスの一例を示す説明図である。 図９は、作業ステータスの一例を示す説明図である。 図１０は、進捗ステータステーブルの一例を示す説明図である。 図１１は、各タスク及びその順序の一例を示す説明図である。 図１２は、作業プロセスデータ６ｈのＥＲの一例を示す説明図である。 図１３は、顧客別承認テーブルの一例を示す説明図である。 図１４は、作業ステータステーブルの一例を示す説明図である。 図１５は、進捗ステータステーブルの一例を示す説明図である。 図１６は、本発明の実施例２の構成例を示すブロック図である。 図１７は、本発明の実施例のユースケース図である。 図１８は、本実施例による作業での個別判断に必要なシステム要素の関係を示すロバストネス図である。 図１９は、本実施例による作業での進捗作業に必要なシステム要素の関係を示すロバストネス図である。 図２０は、進捗制御部による進捗処理の一例を示すシーケンス図である。 図２１は、本実施例のハードウエアとソフトウエアとの関係を示すブロック図である。 図２２は、本実施例のシステムをオブジェクト指向のプログラム言語で開発する際のフレームワークの構成例を示すクラス図である。 図２３は、主要なクラスの主要なメソッドの一例を示すクラス図である。 図２４は、タスクフレームワークの各インスタンスのダイナミックリンケージの作用を示すコラボレーション図である。 図２５は、タスクマネージャーの作用を示す説明図である。 図２６は、タスクデータの一例を示す説明図であり、図２６（Ａ）はタスクデータをハッシュマップで構成した例を示す図で、図２６（Ｂ）はハッシュマップと配列とを用いてテーブル情報をタスクデータに集約する例を示す図である。 図２７は、次へボタンの操作に応じたタスク・インヴォーカーの制御の一例を示すシーケンス図である。 図２８は、コンディショナル・タスクの関係を示すシーケンス図である。 図２９は、戻るボタン又はジャンプして戻るボタンの操作に応じたタスク・インヴォーカーの制御の一例を示すシーケンス図である。 図３０は、各個別タスク・インスタンスと計算確認クラス・インスタン等との関係を示すシーケンス図である。 図３１は、本発明の実施例３及び実施例４の構成例を示すブロック図である。 図３２は、スコアリングによる信用格付と債務者区分との関係を示す説明図である。 図３３は、抽出符号と自動化との関係を示す説明図である。 図３４は、ＣＩＦ番号等をキーとするＥＲを例示するＥＲ図である。 図３５は、決算年月等をキーとするＥＲを例示するＥＲ図である。 図３６は、査定部門コード等をキーとするＥＲを例示するＥＲ図である。 図３７は、進捗ステータステーブル等の制御用のテーブルの一例を示すＥＲ図である。 図３８は、各コメントのキー項目を例示する説明図である。 図３９は、各タスクに含まれる画面の一例を示す説明図である。 図４０は、メイン画面の一例を示す説明図である。 図４１は、状況速報起動画面の一例を示す説明図である。 図４２は、作業要否選択画面の一例を示す説明図である。 図４３は、決算検討作業選択画面の一例を示す説明図である。 図４４は、決算検討・雑科目の資産性検討画面の一例を示す説明図である。 図４５は、決算検討・決算の実態登録画面の一例を示す説明図である。 図４６は、決算検討・決算検討（法人）画面の一例を示す説明図である。 図４７は、抽出符号照会画面の一例を示す説明図である。 図４８は、主要経営比率（単体）照会画面の一例を示す説明図である。 図４９は、信用格付・定量的要因評価画面（法人）の一例を示す説明図である。 図５０は、信用格付・一次評価の一例を示す説明図である。 図５１は、自己査定・取引先の事象チェック画面の一例を示す説明図である。 図５２は、自己査定・抽出基準チェック１（債務者単位）画面の一例の上側を示す説明図である。 図５３は、自己査定・抽出基準チェック１（債務者単位）画面の一例の下側を示す説明図である。 図５４は、自己査定・抽出基準チェック２-１（貸出金明細）画面の一例を示す説明図である。 図５５は、自己査定・抽出条件確認画面の一例を示す説明図である。 図５６は、自己査定・債務償還力の確認画面の一例を示す説明図である。 図５７は、自己査定・債務者区分確認画面の一例の上側を示す説明図である。 図５８は、自己査定・画面スキップ確認画面の一例を示す説明図である。 図５９は、自己査定・優良与信チェック（商手明細）画面の一例を示す説明図である。 図６０は、自己査定・優良与信確認画面の一例を示す説明図である。 図６１は、自己査定・担保・保証確認画面の一例の上側を示す説明図である。 図６２は、自己査定・担保・保証確認画面の一例の下側を示す説明図である。 図６３は、自己査定・基礎査定額確認画面の一例を示す説明図である。 図６４は、自己査定・償却予定額計算画面の一例の上側を示す説明図である。 図６５は、自己査定・償却予定額計算画面の一例の下側を示す説明図である。 図６６は、自己査定・分類結果確認画面の一例（Ｃ株式会社要注意先の場合）を示す説明図である。 図６７は、自己査定・分類結果確認画面の一例（Ｃ株式会社破綻懸念先の場合）を示す説明図である。 図６８は、管理・回収方針画面の一例を示す説明図である。 図６９は、債務者の概況画面の一例の上側を示す説明図である。 図７０は、債務者の概況画面の一例の下側を示す説明図である。 図７１は、統括者指定画面の一例を示す説明図である。 図７２は、営業店統括者・承認画面の一例を示す説明図である。 図７３は、差戻し理由登録画面の一例を示す説明図である。 図７４は、取引先要項システムの画面例を示す説明図である。

次に、図面を参照して、各請求項に記載されている発明の実施をするための形態を説明する。この実施の形態である銀行業務処理システムは、一群の処理を実行するコンピュータシステム４を備える。このコンピュータシステム４として、サーバーを採用することができる。サーバーは、パーソナルコンピュータや携帯端末１などの情報機器（以下「端末１」という）へデータを表示し、入力を促し、そして、端末１の操作による要求に応答する。また、サーバー側での情報処理ではなく、一群の処理を各端末１のＣＰＵを用いて実行し、データについてはオフライン又はオンラインで電子的に送信するようにしても良い。

まず実施形態として、一方向制御と、一方向制御をしつつ強制再表示をする手法を説明する。その後、いくつかの実施例を開示する。
部材の符号中、記号「x」は、任意の数字を示す。例えば、Txxxxと表記されるタスクＩＤは、図１０に示すタスクＩＤのように、「x」が数字であり、T1300、T1600などを包括的に示す。ボタンＢxxというときには、次へボタンＢ１や、戻るボタンＢ３や、前回内容照会ボタンＢ３８などを含む。

＜実施形態： 一方向制御＞
図１を参照すると、本実施形態での銀行業務処理システムは、端末１とネットワーク２を介して接続されたコンピュータシステム４を備えている。
コンピュータシステム４は、主要な構成として、作業データ格納部６と、画面定義情報格納部７と、タスク処理部１０と、進捗制御部３０とを備えている。そして、進捗制御部３０は、次タスク特定処理３４と、戻りタスク特定処理３２とを備えている。

作業データ格納部６は、基礎データ６ｂ、入力データ６ｃ及び導出データ６ｄからなる作業データ６ａを格納する。基礎データ６ｂは過去に蓄積したデータや他システム７０から取得するデータである。入力データ６ｃは端末１から入力されるデータである。導出データ６ｄは、基礎データ６ｂ及び入力データ６ｃから予め定められた計算式等に従った計算により導出したデータである。

画面定義情報格納部７は、前記端末１の画面に表示する画面要素の入力編集可否及び配置を定義する画面定義情報７ａを前記銀行業務のタスク毎に格納する。画面要素は、例えば、データを表示するテーブルや、入力を受け付けるフィールドや、推移コマンド３０ａ等の送信と関連付けられたボタン又はリンク等である。画面定義情報７ａは、これらの画面要素の入力編集可否や、画面上での配置（座標）を特定する。

タスク処理部１０は、前記タスク毎に前記画面定義情報７ａに従って前記作業データ６ａを前記端末１に表示制御する。１つのタスクが１つの画面のみを有するようにしても良いし、１つのタスクが複数の画面を有するようにしても良い。そして、タスク処理部１０は、当該端末１の前記画面要素への操作により入力され又は導出する前記作業データ６ａを前記作業データ格納部６に格納する。この作業データ６ａの格納は、端末１で使用された全ての作業データ６ａを格納対象としても良いし、差分のみを格納対象としても良い。タスク処理部１０は、特に、当該タスクにて入力された入力データ６ｃと計算した導出データ６ｄとを作業データ格納部６に格納する。

進捗制御部３０は、前記画面要素の操作により前記端末１から送信される推移コマンド３０ａに応じて、当該タスク間の推移を前記銀行業務の開始画面から終了画面に向けた一方向に制御する。銀行業務は複数のタスクからなり、このタスクには論理的な順序がある。進捗制御部３０は、予め定められた画面推移の方向及び順序に従ってタスク間を推移するように制御する。個々のタスクでの情報処理はタスク処理部１０が処理する。
進捗制御部は、戻りタスク特定処理３２と、次タスク特定処理３４とを備える。

戻りタスク特定処理３２は、作業中のタスクより前記開始画面側にある任意の画面へジャンプして戻るジャンプ戻り要求を前記推移コマンド３０ａとして受信した際には、当該画面要素への操作により指定された当該ジャンプ戻り先のタスクを特定する。この戻りタスク特定処理３２は、前記一方向の画面推移制御中、ジャンプ戻りが要求された際には、当該要求で指定された開始画面側のタスク（画面）へと１以上の開始画面側の画面を飛び越して（ジャンプして）戻る。従って、作業者は、開始画面側の任意の画面に戻って作業をしたい際に、戻り先の画面までの全ての画面を１画面ずつ戻る必要がない。

次タスク特定処理３４は、作業完了したタスクの次に作業するタスクを要求する次タスク照会要求を前記推移コマンド３０ａとして受信した際には、前記ジャンプ戻り後に又はジャンプ戻り無しに作業完了した現画面の作業データ６ａ及び現タスクから予め唯一に定められる次タスクを特定する。これにより、進捗制御部３０は、前記一方向にて次タスクの画面よりも終了画面側の画面へのジャンプ進みを禁止する。すなわち、本実施形態では、ジャンプ戻りは許容するが、ジャンプ進みは禁止する。
このように、次タスク特定処理３４は、予め定められた画面推移の順序に従って次のタスク（画面）を特定することで、現在の画面から終了画面側に１以上画面を飛び越して（ジャンプして）推移する処理を禁止する。

本実施形態では、作業者は、ジャンプして戻ることはできても、ジャンプして進むことはできず、特に、ジャンプして戻った後も、ジャンプして進むことはできないため、予め定められた一方向での作業が強制される。途中でジャンプして戻ったとしても、複数のタスクが関連する銀行業務を唯一の順序で判断を積み重ねなければならない（判断過程統一作用，図５参照）。
この判断過程統一作用により、当該銀行業務の作業の順序を本実施形態のＩＴの利用により強制するため、作業に関するリスクの発現を予防することができる（予防的統制効果）。そして、判断過程統一作用により、不慣れな担当者に早期の熟達を促しつつ、ＩＴの利用による事務合理化を図ることができる。
そして、この判断過程統一作用により、銀行業務を多人数で熟達の程度に差のある作業者群によって遂行する際にも、判断過程を強制的に統一するという業務プロセスが構築される（業務プロセス構築作用）。この業務プロセスの構築により、多人数による判断を均質とすることができ、そのため、作業結果で得られるデータの可用性を向上させることができる（均質性と可用性の向上効果）。
また、複数のタスクからなる銀行業務の判断過程が統一されることで、大量のデータの依存関係を一方向制御に基づいて管理することができ、当該銀行業務を組み立てる大量の判断基準について、タスク又はタスク群を単位として局所化することができる（局所化作用）。この判断基準の局所化により、様々なルール（規律）への準拠性を確保する作業負荷が軽減され、システム開発及び規律の進化に応じたシステムの局所的な変更も容易となる（開発変更容易効果）。
本実施形態では、このＩＴを利用した一方向制御により、予防的統制効果、結果の均質性と可用性の向上及び開発変更の容易性等により、内部統制の質を向上させることができる。
銀行業務処理方法及びプログラムについても同様である。
これを詳細に説明する。

図２に、信用リスクに関する作業データ６ａの一例を示す。図２に示す例では、基礎データ６ｂは、銀行の勘定系システムや、情報系システムや、不動産担保評価システムなどの他システム７０から取得する債務者及び債権についてのデータである。基礎データ６ｂとしては、例えば、会社名、業種などの債務者の属性データと、債務者の単独又は連結の公表財務データと、債権である貸金（融資）の明細データと、担保や保証に関する保全データと、担保の一種である不動産担保評価データなどがある。

入力データ６ｃは、作業者によって端末１に入力されるデータであり、作業者の判断を示す各種コードやコメントである。コメントはテキスト・データで入力される。各種コードはコードの数値等の入力を受けても良いし、リストを提示して選択を促すようにしても良い。

導出データ６ｄは、基礎データ６ｂ及び入力データ６ｃとから導出するデータであり、例えば公表財務計数に関する異常の有無を示す異常マークや、信用格付に際してのスコアリングの評点（スコア）の合計点や、債権の分類額などである。画面へ表示する際に基礎データ６ｂから導出するデータについては、基礎データ６ｂに含め、導出データ６ｄは、作業者から入力されるデータのみ又は入力データ６ｃと基礎データ６ｂとから導出するデータとする。

また、好適な例では、作業データ６ａに、査定データ６ｅを含めても良い。この査定データ６ｅは、決裁された作業データ６ａからなる査定結果データ６ｆと、部門別の結果データである査定作業結果データ６ｇとを有するようにしてもよい。
さらに、作業データ６ａに、作業のプロセスがどのようになされたかを作業毎に記録する作業プロセスデータ６ｈを含めると良い。この作業プロセスデータ６ｈは、債務者毎に作業がなされたか否かを示す作業有無コードや、作業の状態を示すコード（例えば、作業ステータス）や、個別のタスク毎の進捗を示すコード（例えば、進捗ステータス等）を有すると良い。

再度図１を参照すると、画面定義情報格納部７は、画面定義情報７ａを格納する。画面定義情報７ａは、端末１のグラフィカル・作業者・インタフェース（ＧＵＩ）の制御と協調して、端末１に表示する画面要素と、その位置と、その属性とを定義する。画面定義情報７ａの形式には種々のものがあるが、端末１がＷｅｂブラウザーであれば画面定義情報７ａはタスク・マネージャー・インスタンス１０８Ｉ（図２８等参照）ファイルに含まれる。端末１がＪＡＶＡ（登録商標）の仮想マシンであれば、仮想マシンのランタイムシステム１００が解釈可能なコードとなる。このようなコードとして、例えば、画面要素の内容と、画面上の位置と、入力編集の可否などの属性とをＸＭＬで記述するようにしても良い。
端末１でアプリケーションソフトウエアを実行する際には、画面定義情報７ａは、アプリケーションソフトウエアか、または端末１のオペレーティングシステムが解釈可能なコードとなる。このように、画面定義情報７ａの具体例は端末１動作するソフトウエアとの関係で定まり、バイナリーコードや、ＸＭＬやＨＴＭＬによるテキストの指定となる。

画面定義情報７ａとなるコードは、プログラマーが直接に記述するようにしても良いし、ソフトウエアの開発環境が提供するＧＵＩ構築用の機能を用いて、画面要素を開発者の端末１の画面上で定義し、属性を定めることで、開発環境が画面定義情報７ａとなるコードを自動生成するようにしても良い。画面定義情報格納部７は、この画面定義情報７ａとなるコードのデータを格納するハードディスクや、データベースのファイルであり、コンピュータシステム４側で格納しても良いし、端末１側に格納するようにしても良い。すなわち、画面定義情報７ａは、個々の作業毎に変化するものではなく、一定であるため、予め端末１側に格納するようにしても良いし、コンピュータシステム４の起動時に端末１側に送信するようにしても良い。

図３（Ａ）を参照すると、本実施形態では、画面ＩＤに対してレイアウト情報を対応付け、このレイアウト情報にて画面要素とその要素属性情報とを対応付ける。作業の進捗を画面ＩＤではなくタスクＩＤで管理する例では、タスクＩＤとレイアウト情報とを対応付ける。

図３（Ｂ）に示すように、画面要素としては、表示ウインドウであるフレームと、そのフレームを区画するペインと、入力や表示の単位となるフィールドと、作業者の操作の単位となるボタンＢｘｘと、複数の選択肢から複数同時選択可にて選択を受け付けるチェックボックスと、複数の選択肢から唯一の選択を受け付けるラジオボタンやリストと、唯一の選択肢又は未選択を受け付けるコンボボックスと、階層データを表示しその階層データの要素（ノード）の選択を受け付けるツリーなどがある。その他、フィールドを二次元の行列としたものをテーブルと呼ぶ。

ボタンＢｘｘの要素属性情報がクリック不可の際には、現在の状態ではそのボタンＢｘｘによる操作を行えないことを作業者に示す。例えば、必須入力のフィールドへの入力がないときにはボタン操作が不可で、そのフィールドに入力があった際にはクリック可とするように、要素属性情報は固定的ではない場合がある。

［一方向制御］
進捗制御部３０は、ボタンＢｘｘ等の画面要素の操作により前記端末１から送信される推移コマンド３０ａに応じて、当該タスク間の推移を前記銀行業務の開始画面から終了画面に向けた一方向に制御する。銀行業務の「タスク」は、１又は複数の画面を有する。タスクを一方向に制御するのは、画面を一方向に制御することと同義である。

図４に、１つのタスクを１画面で構成し、画面を画面ＩＤで識別する際の一方向の種々の例を示す。
図４（Ａ）を参照すると、この「一方向」は、画面ＩＤが１、２、３等となる予め定められた順序での一方向である。一方向というときには、画面ＩＤが１、２、３と進捗する方向のみであり、画面ＩＤが３、２、１となる逆方向を含まない。すなわち、コンピュータシステム４は、一方向制御下の通常の操作では、予め定義された順序で画面が推移するように画面の進捗を制御する。開始画面である画面ＩＤ：１から終了画面である画面ＩＤ：８までの画面推移を一方向に制御する。

図４（Ａ）から図４（Ｃ）に示すように、画面の一方向が画面ＩＤ：１、２、３、４、５の順序で、画面ＩＤ：４から画面ＩＤ：１の画面に戻った後、当該画面ＩＤ：１の画面の次タスク特定処理３４が、画面ＩＤ：１の画面から、画面ＩＤ：３及び４の画面へのジャンプを禁止する制御を行う。この例では、画面ＩＤ：１の次には、画面ＩＤ：２を経由しなければ、画面ＩＤ：３の画面に進むことができない。

図４（Ａ）は、連結リストによる例を示し、図４（Ｂ）はスタックを参照する例を示し、図４（Ｃ）はテーブルを参照する例を示す図である。図４に示す例では、一方向には、作業分岐３４ａと、画面分岐３４ｂとが含まれている。図４（Ａ）の画面ＩＤ：３では、作業分岐条件を満たす場合に次画面ＩＤは４であり、満たさない場合には５となる。この作業分岐３４ａでは、画面ＩＤ：３の画面にて作業分岐条件を満たさない場合には、画面ＩＤ：４の画面は作業せず、スキップする。

続いて、画面ＩＤ：５では、画面分岐条件を満たす場合に次画面ＩＤは６であり、満たさない場合に次画面ＩＤは７となる。画面ＩＤ：６と７とは選択的であり、いずれの画面に進捗してもその次の画面ＩＤは８となる。すなわち、画面ＩＤ：５の画面分岐３４ｂは、択一的な画面を選択する分岐であり、画面ＩＤ：３の作業分岐３４ａは作業の分岐である。

図４（Ａ）に示す例では、画面ＩＤのデータ構造を連結リストとしており、この連結の順序にて一方向の定義を格納する。この例では、次タスク特定処理３４は、各画面の作業完了時に連結リストを操作して現画面ＩＤを検索し、その画面ＩＤに連結している次の画面ＩＤを次画面ＩＤとする。次画面ＩＤが２つ以上ある際には、作業分岐３４ａか画面分岐３４ｂであるため、現タスクまでの作業データ６ａが分岐条件を満たすか否かを確認し次画面ＩＤを特定する。

図４（Ｂ）に示す例では、スタック等の参照型として、作業の開始時に当該作業の一方向を画面ＩＤのスタックとしてプッシュしておき、次タスク特定処理３４は、各画面の作業完了後に一つずつ画面ＩＤをポップすることで、次画面ＩＤを特定する。図４（Ｃ）に示す例では、画面ＩＤと分岐条件とをテーブルに格納しておき、現画面ＩＤを引数としてテーブルを探索し、次画面ＩＤを特定する。

このように、一方向制御を実現するためのソフトウエアとしては、種々のデータ構造及びアルゴリズムを使用することができる。一方向制御は、作業の進捗を管理するのみならず、ジャンプして戻った際に戻り先よりも終了画面側での作業をなかったこととする制御である。これにより、全ての作業者の判断過程を統一する作用を得ることができる。
また、図４（Ａ）から図４（Ｃ）いずれの構成であっても、一方向制御を採用すると、各画面の開発に際しては、その画面での整合性を確保する情報処理を開発すればよく、個別の画面やタスクの開発のドメインは局所化される。ソフトウエアの開発として、一方向制御を採用し作業手順の強制のためのロジックを開発すれば、個々の画面間の全体的な整合性の確保については、作業者が行うこととなり、ソフトウエア開発の負担が大幅に軽減される。

例えば、図４（Ａ）の画面ＩＤ：４の開発にて、画面ＩＤ：３から引き続いた作業である場合と、画面ＩＤ：７からジャンプして戻った場合とに対応した開発をするのは、極めて煩雑となる。具体的には、画面ＩＤ：７で表示された内容を修正するために画面ＩＤ：３にジャンプして戻り、画面ＩＤ：３の内容を修正した場合、続く画面ＩＤ：４の情報処理がこの画面ＩＤ：３で入力されるデータに依存する可能性があると、画面ＩＤ：４の開発に際して、画面ＩＤ：４で使用する個別のデータに影響があるか否かを検討しなければならなくなる。すると、例えば、全ての個々のデータの有効性をステータスとして保持し、その有効性を確認しつつ計算等を実装しなければならなくなる。または、「ジャンプして戻る」という情報処理を実現できなくなる。すると、大量の画面を有する業務のシステム化及び安定した運用に別途の課題を生じさせてしまう。例えば、ジャンプして戻るための作業負荷及び時間が膨大であれば、誤りや不整合を発見した際に対応する画面まで戻って修正するというインセンティブを低下させてしまう。

この判断基準の局所化は、オブジェクト指向等に基づく開発環境によっては解決されないものであり、一方向制御により奏することのできる効果である。すなわち、現状のサーバーサイドのコンピュータソフトウエア開発に際して、モデル・ビュー・コントローラー（ＭＶＣ）等の構成を採用しても、各データの依存関係が複雑で、大量の画面を取り扱う際には、ビューとモデルとの関係の整理に多大な作業負荷がかかってしまう。例えば、Ｗｅｂを利用した情報処理システムにて、一方向に進んでいくことができるが、戻ることができないシステムが多数ある。サーバーサイドやＥＵＣ（エンド・作業者・コンピューティング）のアプリケーションにて、直前の画面にのみ戻ることができるシステムもあるが、ジャンプして戻る処理が実装されているシステムは発見できない。直前の画面に戻ることしかできないのは、レスポンスの悪化要因として意識されてしまう。

また、判断基準を局所化できると、開発するコンピュータシステム４の実際のデータ処理の結果（プログラミングの結果）が、業務上の要件を満たしているか否かを検証しやすくなる。これにより、コンピュータシステム４が業務上の要件に準拠していることの確保を行いやすくなる。
また法規制や金融機関への要請などが変化・進化した際に新しいルールに準拠させるためのソフトウエアの変更もデータへの影響を一方向の元で可視化でき、局所的とすることができる。すなわち、ソフトウエアの変更の負担も大幅に軽減される。

＜一方向制御の効果＞
図５に示すように、一方向制御は、判断過程統一作用により、予防的統制効果を奏し、業務プロセス構築作用により、結果の均質性及び可用性向上効果を奏する。さらに、判断基準の局所化作用により、開発・変更容易効果を奏する。
具体的には、例えば、予め定めた判断過程による作業者の判断が積み重なることを「ＩＴを用いて統制」することで、例えば信用リスク管理に関する銀行業務の作業に伴い発生し得る数値（信用格付、債務者格付、債務者区分、分類額等の作業結果と、これらの作業結果を使用する貸倒引当金及び自己資本比率等）への誤りの混入を「予防」することができる。
この予防に際して、単に自己査定業務をシステム化した場合と比較して、本実施形態による一方向制御というＩＴを利用すると、判断過程統一及び業務プロセス構築を人手によらずにコンピュータシステム４により統制することができる。この統制はマニュアル統制ではなく、システム統制であるため、判断過程の統一という業務上の新しい要請についてまでＩＴを適用可能としたことで、内部統制の質を向上させ、業務自体の有効性及び効率性を高めることができる。
この内部統制の質を向上させるという一方向制御の効果は、当該一方向制御を採用するコンピュータシステム４という製品の製品市場における優位性となる。一方向制御を行うコンピュータシステム４という製品は、判断基準の局所化作用により、異なる金融機関等への適用に際しても導入に必要な情報処理内容の修正を最小限とすることができる。

＜実施形態： 強制再表示処理１２＞
再度図１を参照すると、好適な本実施形態では、タスク処理部１０は、強制再表示処理１２を備える。強制再表示処理１２は、前記画面定義情報７ａに従って、前画面までのタスクのために入力され又は導出した作業データ６ａの一部を作業中である別のタスクの画面に入力編集不可で再表示する。
複数のタスクからなる銀行業務について、個別の判断と総合的な判断とを整合させたいという課題に対して、本実施形態では、強制再表示処理１２が、各タスク（画面）での個別の判断の結果をより終了画面側の画面にて再表示する。
例えば、信用リスク管理を例とすると、決算検討用の画面で入力したコメントを自己査定用の画面で一部再表示するなどして、決算検討での作業者の判断を自己査定用の画面にて再表示する。この強制再表示処理１２という情報処理により、決算検討作業自体の整合性を確保しつつ、さらに、決算検討と自己査定との整合性を確保する。この強制再表示処理１２は、再表示の対象を画面定義情報７ａに予め定義しておき、現画面の照会要求に応じて、前画面までに入力されたデータを端末１に表示させる処理である。

本実施形態では、この強制的な再表示を行うことにより、一方向制御による判断の積み上げを作業者に強制し、同一のデータであっても、個別のタスクの視点から再度の確認を促し、個別の及び総合した整合性の確保を作業者に促すことができる。これにより、多面的な判断が必要な銀行業務について、査定結果データ６ｆの総合的な一貫性を安定して確実に確保することができる。

この強制再表示処理１２という情報処理は、個別作業の整合性及び個別作業間の整合性を確保する作用を営む。この強制再表示により、作業に必要な多面的で総合的な判断についての一貫性を確保することができる。すなわち、複雑に関連する項目を個別作業の目的ごとに予め整理された状態で再表示することで、別の画面を使用して判断したことと、現画面で判断すべきこととの整合性の確保を作業者に促すことができる。この再表示により、作業者は、例えば、決算検討として判断したことと、債務者区分の理由との整合性の有無を自然に判断することとなる。

信用リスク管理に使用する銀行業務処理システムを例とすると、再表示する同一のデータとしては、各種コメントや、決算の財務項目の数値や、作業者によって判断された信用格付や、債務者区分などがある。

［強制再表示：入力データ６ｃ］
強制再表示処理１２は、前画面までに入力された入力データ６ｃを入力編集不可の入力編集不可属性とし、現画面の前記画面定義情報７ａに従った位置に再表示すると良い。
この例では、再表示のデータについては、変更を不可とするため、終了画面側の画面では再表示される入力データ６ｃの修正を行うことができない。従って、再表示された入力データ６ｃを修正するには、作業者は、当該入力データ６ｃを入力した画面まで戻らなければならない。なお、戻りタスク特定処理３２により、戻り先のタスク（画面）へ戻る作業自体は少ない操作数により短時間で完了する。
本実施形態では、この修正のために強制的に画面を戻らせるという一方向制御により、個別判断と個別判断との総合的な整合性の確保を作業者に促す業務プロセスを強制的に確保することができる。

すなわち、作業者は、終了画面側の画面で修正したくとも、修正できないため、終了画面側である現画面にて作業データ６ａの内容の矛盾を発見した作業者は、その再表示されたデータを当初に入力した画面へ戻る操作を行い、入力し直すこととなる（修正時再作業強制作用）。
そして、前画面までに入力された入力データ６ｃを、編集を不可とする入力編集不可属性で強制的に再表示し、この修正作業については、画面を戻す処理を強制すると、総合的な整合性のために修正が必要な入力を前画面以前で行った作業者の手間及び作業負荷は強制的に増加することとなる。一方、作業の要領等の全体構造を把握している作業者にとっては、修正のために画面等を戻る処理が不要で、一度の画面推移で、短時間で作業を終了させることができる（事務合理化）。このように、一方向制御下の入力編集不可での強制再表示処理１２という情報処理により、「総合的な整合性を確保するために修正する際に作業者の作業負荷が増大する」という業務プロセスをコンピュータシステム４の情報処理により強制的に構築している。これにより、作業に必要な知識・経験に関して、作業者の早期熟達を促すことができる（早期熟達と事務合理化）。

すなわち、不慣れな作業者が、作業の全体の構造を把握することなく、目前の画面にのみ注目して作業すると、終了画面側の画面で種々の矛盾を生じさせることとなる。この場合には、作業者は、当初の画面に戻って再作業をしなければならない。この画面を戻した再作業には、時間を要し、煩雑となり、作業負荷が増大する。従って、この銀行業務処理システムは、その業務プロセスの強制を介して、不慣れな作業者に対して、作業の全体の構造を早期に習得し、個々の作業を短時間で完了できるように努めることを促す。

［強制再表示：導出データ６ｄ］
好適な実施形態では、強制再表示処理１２は、画面定義情報７ａに従って、前画面までに確認された作業データ６ａをから計算される導出データ６ｄを入力編集不可の入力編集不可属性として再表示する。
すなわち、前画面までに入力された入力データ６ｃ及び基礎データ６ｂを使用して導出データ６ｄを導出し、導出データ６ｄを現画面に表示する。この情報処理により、複雑な依存関係にあるデータの関連を予め統一した基準で整理し、画面の推移による判断の積み上げを業務プロセスとして確立することができる。導出データ６ｄの再表示という構成により、画面表示するデータの精度向上作用による均質な判断積み上げ作業を有し、異なる作業者間の判断の均質化を促し、また、形式的なミス防止のための確認作業の負荷を軽減することができる。

＜強制再表示処理１２の作用効果＞
図５に示すように、強制再表示処理１２により、各画面の個別の判断と、より終了画面側での個別の判断とについて、それぞれ必要なデータを表示又は再表示しつつ、再表示については、作業全体に関する一貫した判断を促すことができる。すなわち、強制再表示処理１２というＩＴの利用により、作業者に、個別判断と、全体判断とのそれぞれ整合性を促し、整合的な判断の積み上げが自然になされる業務プロセスを構築することができる（整合的判断積み上げ作用）。
強制再表示処理１２による整合的判断積み上げ作用は、再表示された画面にて当該画面内部の整合性が確保されず、従って、再表示されたデータの修正が必要となる際に、修正時の作業を強制するという業務プロセスが構築される。すなわち、再表示されたデータを修正するには、当該データを入力する画面までジャンプして戻らなければならず、ジャンプして戻り、必要な修正を行うと、一方向制御により、再表示の画面までジャンプして進むことができない。従って、作業者は、全体的整合性の不備を発見すると、一定の作業を強いられることとなる（修正時の作業強制作用）。
この修正時の作業強制作用により、作業に不慣れな作業者が、早期に熟達するという効果を奏する。すなわち、終了画面側で不整合が発見されると、作業の業務を効率的に行うことができない。従って、業務の効率化のために、作業全体の構造を早期に把握しようと努め、その結果、全ての作業者の早期な熟達が図られる。この点、単に資産査定業務をシステム化すると、作業者が判断すべき事項が減っていき、全体的整合性の判断を促すことがなくなる結果、作業者は、作業という業務の内容についての知識を蓄積する機会が大幅に減少する。一方、強制再表示処理１２を採用すると、システム化により事務合理化しつつ、全ての作業者の早期熟達を図ることができる。
一方、熟達した作業者にとっては、作業を要する債務者それぞれについて全ての画面を経由するのは、業務の効率性を悪化させる懸念もある。しかし、作業を要する債務者全てについて必要最低限の作業がなされており、特に、強制再表示により個別判断の整合性が確認されていることを前提とできるため、内部統制に必要なコストを含め全体として事務合理化することができる。
このように、早期熟達効果と、事務合理化効果とにより、強制再表示処理１２というＩＴを利用して、資産査定に必要な業務の適切性、有効性及び効率性を高めることができる。

＜実施例について＞
本実施形態は、下記４つの実施例を有する。実施例１から３は銀行業務処理システム、方法及びプログラムで、実施例４は債務者等の信用格付と債務者への債権の資産査定とを業務とする格付自己査定システムである。
図６に、本発明の各実施例の課題解決手段と作用効果のポイントを示す。
実施例１（進捗ステータス統制）では、進捗制御部３０は、タスクの進捗状況をタスク毎の進捗ステータスで管理する。進捗ステータスとして、未着手、作業中及び作業済を有する。進捗制御部３０は、作業の起票時に全てのタスクの進捗ステータスを未着手とし、作業が完了するごとにタスク単位で作業済とする。そして、ジャンプして戻った際には、戻った間のタスクの進捗ステータスを作業済から作業中に変更する。これにより、一方向制御をする。
この実施例１では、タスク毎の進捗ステータスを格納することで、銀行業務処理の作業プロセスをデータとして保存することができる。作業データ６ａのみならず、作業プロセスデータ６ｈとして進捗ステータスを記録しておくことで、作業が完了した銀行業務についての作業データ６ａの可用性と検証性とを向上させることができる。そして、作業データ６ａの可用性を高めることで業務に必要な情報の伝達の有効性を高めることができる。また検証性を向上させると、品質・信頼性向上のためのモニタリングの有効性を高めることができる。

実施例２（タスク処理とトランザクション管理）では、作業データ６ａをタスク毎にまとめたタスクデータｔｄを単位として、予め定められた処理セット（表示制御、計算、条件確認及び格納）を有することで、オブジェクト指向技術に基づく一方向制御の実装をすることができる。すなわち、タスク処理部１０が、予め定められた処理セットを有することで、オブジェクト指向での抽象メソッドによる共通性と個々のタスク処理の独立性を得ることができる。抽象メソッドによる共通性を高めることで、進捗制御や他の要請からタスク処理を共通して使用することができる。すなわち、進捗制御等は個別のタスクの実装を知ることなく、共通した処理セットを使用することができる。一方、この処理セット内で個別のタスク毎に実装すると、一方向制御と協調して、個別のタスク処理の独立性を高めることができる。すなわち、タスク及びその画面に生じる修正によって他のタスクの内容や進捗の管理処理などの処理の修正を惹起しないフレームワークとすることができる。これにより、開発の柔軟化と局所化とを実現し、また、タスク間の依存関係を緩めることでタスク毎の開発や入れ替えを容易とすることができる。
そして、トランザクション管理では、一方向制御下にて、作業のトランザクションの管理を、作業通番を単位とする作業トランザクションと、タスクＩＤを単位とする個別トランザクションとに分けて、それぞれＡＣＩＤ特性の全てを要求せず、操作性を向上させつつ、システムのデータ管理上、安定した仕組みを構築する。すなわち、作業タスクの全体の一貫性については作業の全体の終了時に確保し、一方、タスクについては、タスク毎に永続性を確保する。すなわち、作業全体として一貫性がない状態であっても、一方向制御下で、タスクに永続性を与える。これにより、コンピュータシステム４の障害発生時にも作業データ６ａを正確に管理することができ、また、システム開発を柔軟に行うことができる。例えば、作業を途中のタスクで中断する中断制御６２（図１６参照）を実装することができる。

実施例３（特定操作要求）では、一方向制御の下、銀行業務の作業上保守的な判断を作業者の判断として初期値表示し、例外判断については、特定操作を要求する。この初期値表示と特定操作要求という情報処理の構成により、本実施例による銀行業務処理システムは、例外判断の手順を強制する作用を営み、重要な判断に関してその判断の根拠を明確にする効果を奏する。

実施例４（特定操作要求と強制再表示）では、格付自己査定を銀行業務の一例として、複数のタスク群からなる格付自己査定作業での特定操作要求と強制再表示の例を開示する。格付自己査定作業は、債務者の財務諸表に基づく財務分析が重要であり、この決算検討のタスクの判断結果は、信用格付のタスクにも、債務者区分のタスクにも、債権分類のタスクにも影響する。この点、実施例４では、決算検討の結果に基づいて債務者区分のタスクにて特定操作要求をし、また、決算検討時のコメントデータを作業者による作業の終了画面側で強制再表示する。特定操作要求や強制再表示により整合的では無いと判断される際には、作業者は決算検討にジャンプして戻り、再度財務分析を行う。この仕組みにより、整合的判断の積み上げをＩＴの利用により強制し、例外判断の根拠を管理し、早期熟達と事務合理化の両立を図り、判断過程を統一できる業務プロセスを確立し、これらにより、ＩＴの利用による内部統制の質を向上させ、そして、本実施例４による格付自己査定システムを使用する銀行の業務の適切性及び健全性の向上を促すことができる。

＜実施例１： 進捗ステータス統制＞
図７に示すように、実施例１では、コンピュータシステム４が、進捗ステータス格納部８を備えている。
進捗ステータス格納部８は、作業プロセスデータ６ｈとして、進捗ステータステーブル８ａを格納する。進捗ステータステーブル８ａは、タスクを識別するタスクＩＤを単位として、当該タスクで使用する作業データ６ａの全体に対して未着手、作業中及び作業済の進捗ステータスを特定するテーブルである。
図８に示す例では、進捗ステータスとして、さらに、省略と取消とを有すると良い。

未着手との進捗ステータスは、初期状態を示し、作業中との進捗ステータスは、タスクの開始処理がされた状態を示し、作業済との進捗ステータスは、タスクの完了処理がされた状態を示す。
また、進捗ステータスとして省略を有する例では、省略は、作業分岐３４ａによりスキップしたタスクを示す。スキップは、その作業分岐３４ａの条件に応じて作業を必要としないタスクのタスクＩＤについて、作業分岐３４ａのタスクまでのタスクを省略する進捗管理である。図４（Ａ）又は（Ｃ）に示す例では、画面ＩＤ：３のタスクから画面ＩＤ：５のタスクに進捗する際、スキップするタスクＩＤは画面ＩＤ：４のタスクＩＤである。
進捗ステータステーブル８ａは、図１０に示すように、作業通番毎に、１つのテーブルとなり、タスクＩＤ毎の進捗ステータスを有する。

図７に示す例では、作業プロセスデータ６ｈとして、作業を管理するための作業ステータステーブル９ａを有する。
図９に示すように、作業ステータスとして、起票後、作業の開始又は振り分けを待機する状態を示す待機中と、営業店担当者等のコンピュータシステム４へのログイン作業者による作業中を示す実行中と、作業が決裁され作業全体が終了した決裁済と、同一債務者の作業が重複して起票された状態を示す重複と、作業の取消を示す取消とを用いると良い。
進捗制御部３０は、この作業ステータスを更新し、参照することで作業のワークフローを管理すると良い。ここでは、「ワークフロー」は、作業者間で作業を回付する処理をいい、「進捗」は、同一の作業者による作業内のタスクの推移をいう。

図１０に、進捗ステータステーブル８ａの具体例を示す。この例では、作業通番Ｓ００１の作業について、作業者ＩＤＵＳＥＲ００１の作業者がタスクＩＤ（T1000)から（T1339)まで作業する。進捗制御部３０は、当該作業通番の進捗ステータスとして全て未着手をセットする。開始画面がタスクＩＤ（T1000)の最初の画面または当該最初の画面を呼び出すメイン画面であり、終了画面は、タスクＩＤ（T1339)の最後の画面とする。進捗制御部３０は、タスクＩＤ（T1000)に属する画面の作業が完了すると、進捗ステータスを作業済とする。タスクＩＤ（T1319)のタスクは、作業分岐３４ａにより予め定めた一方向の順序に含まれないタスクで、タスクＩＤ（T1310)のタスクに作業済を記録する際にあわせて、タスクＩＤ（T1319)に省略を記録する。タスクＩＤ（T1330)のタスクも同様である。
そして、作業者は、図１０に示す進捗ステータステーブル８ａに示される状況では、タスクＩＤ（T1331)のタスクを作業中である。
各タスクに、タイムスタンプが与える例では、各タスク（少なくとも１つの画面群）についての個別作業を完了した時刻が記録される。すると、タスクＩＤ間の所要時間なども事後的に検証できる。

図１１に、信用リスク管理を対象とする銀行業務処理の各タスクが有する画面の一例を示す。この銀行業務のタスクは、メイン、決算検討、信用格付、自己査定、管理・回収方針、債務者の概況、統括者指定、統括者、支店長、再査定一審、再査定二審、再査定上級、監査一審、監査二審、監査上級の順序となる。営業店担当者が作業をするのはタスクＩＤを併記した債務者の概況、統括者指定までである。進捗ステータスは、メインタスクから、監査上級まですべてのタスクについて与える。信用格付のスコアリングを実態財務ではなく公表財務で計算する際には、メインの次を信用格付とし、その次に決算検討とするようにしても良い。

タスクＩＤ（T1110)の決算検討・実態検討（法人）は、債務者が法人の場合のみ作業を行うタスクであり、債務者が個人の場合には省略となる。タスクＩＤ（T1330)の自己査定・画面スキップ確認は、作業分岐３４ａがある。画面スキップは、正常先で保全内容の修正をする必要がない債務者について、優良与信確認画面から分類結果確認画面までを画面スキップするものである。この画面スキップをする際には、当該画面スキップ確認タスクの進捗ステータスが作業済となり、画面スキップをしない際には、当該画面スキップ確認タスクの進捗ステータスが省略となる。図１１に示す例では、作業者は、債務者の概況までの作業が完了し、次フロー先となる統括者を指定する作業まで完了している。その後、統括者による承認作業が未着手となっている。

再度図７を参照すると、実施例１の進捗制御部３０は、起票時処理３６（A3, startForm()）と、タスク開始処理３８（C24, S3x, startTask()）と、タスク完了処理４０（C20, S4x, endTask()）と、一方向制御処理４２とを備えている。また、実施形態と同様に、次タスク特定処理３４と、戻りタスク特定処理３２とを備えている。

起票時処理３６（startForm()，Ａ３に対応）は、前記銀行業務のタスク群からなる作業が起票された際に当該作業を識別する作業通番の進捗ステータステーブル８ａの全てのタスクの進捗ステータスを未着手とする。例えば、図１０又は図１１に示す全てのタスクＩＤの進捗ステータスを未着手とする。

タスク開始処理３８（startTask()，Ｃ２４に対応）は、前記推移コマンドが前記タスクの開始要求（start()）である際に、当該開始要求のタスクＩＤで指定されるタスクの進捗ステータスを作業中に変更する。すなわち、タスク開始処理３８は、そのタスクの作業を最初に行う際に未着手である進捗ステータスを作業中に変更する。このタスク開始処理３８は、図１９に示す例では、符号Ｃ２４で示す処理であり、図２０に示すシーケンス図では符号Ｓ３ａ及びＳ３ｂで示す処理である。

タスク完了処理４０（done()，Ｃ２０に対応）は、前記推移コマンドが前記タスクの終了要求（done()）である際に、現タスクの進捗ステータスを作業済に変更する。具体的には、作業中である進捗ステータスを作業済に変更する。このタスク完了処理４０は、図１９に示す例では、符号Ｃ２０で示す処理であり、図２０に示すシーケンス図では符号Ｓ４ａ及びＳ４ｂで示す処理である。

次タスク特定処理３４（getNextTask()，getPrevTask()，Ｃ２３に対応）は、実施例１では、タスク完了処理４０に続いて、現タスクのタスクＩＤの指定により次タスクＩＤが照会された際に、前記進捗ステータステーブル８ａを参照して、未着手又は作業中のタスクＩＤのうち最も開始タスクに近いタスクＩＤを、次タスクＩＤとして特定する。すなわち、進捗ステータステーブル８ａをタスクＩＤの小さい開始画面側から走査し、進捗ステータスが作業済の場合には次のタスクＩＤの進捗ステータスを確認し、未着手が現れた際に、この進捗ステータスが未着手であるタスクＩＤを次タスクＩＤとする。この次タスク特定処理３４は、図１９に符号Ｃ２３で示す処理であり、図２０の符号Ｓ２ａ及びＳ２ｂで示す処理である。

後述する実施例２で開示する中断制御６２があった後に、作業通番で指定される作業の再開のためには、再開すべきタスクＩＤを特定しなければならない。次タスク特定処理３４は、中断後、再開する場合に、進捗ステータスが作業中であるタスクＩＤを次タスクＩＤに特定する。

戻りタスク特定処理３２（Ｃ２７に対応）は、実施例１では、現タスクより二以上前のタスクへジャンプして戻るジャンプ戻り要求である際に、当該ジャンプして戻るタスクＩＤを特定する。ジャンプ戻り要求は、例えば、図１０に示す例では、タスクＩＤ：T1200からタスクＩＤ：T1120に戻ることではなく、T1120等を飛び越して、T1100又はT1000に戻る要求である。

そして、一方向制御処理４２（Ｃ２８に対応）は、前記戻りタスク特定処理３２によるジャンプ戻り先のタスクについて前記タスク開始処理３８（C24, S3x)をした後に、当該戻り先のタスクＩＤから前記一方向の順序での前記戻り元のタスクのタスクＩＤまでの作業済の進捗ステータスを作業中に変更する。 例えば、図１０に示す例では、タスクＩＤ：T1310からT1100にジャンプして戻ったとする。このとき、進捗ステータステーブル８ａでは、T1310の進捗ステータスが作業中で、T1100からT1230までの進捗ステータスは作業済となっている。一方向制御処理４２は、T1100にジャンプして戻った後、このタスクT1100のタスク開始処理３８の一部として、T1100からT1230までの進捗ステータスを作業中に変更する。

次タスク特定処理３４は、現タスクT1100のタスクＩＤの指定により次タスクＩＤが照会された際に、前記進捗ステータステーブル８ａを参照して、未着手又は作業中のタスクＩＤのうち最も開始タスクに近いタスクＩＤを指定するため、T1100にジャンプして戻った後、T1100の再度の作業が完了した際には、次タスクＩＤは作業中のタスクＩＤのうち最も開始タスクに近いタスクＩＤであるT1120となる。これにより、ジャンプして戻る処理がなされても一方向制御を実現する。

＜実施例１： 進捗ステータス統制の個別機能＞
［進捗ステータス統制： タイムスタンプ］
再度図７を参照すると、好適な例では、タスク完了処理４０が、タイムスタンプ処理４４を備えている。タイムスタンプ処理４４は、当該完了するタスクの進捗ステータスを作業済に変換した際に、当該変換した時刻を前記タイムスタンプに格納する。そして、進捗ステータステーブル８ａが、このタイムスタンプを管理する。タイムスタンプは、例えば、当該進捗ステータスを作業済みに変換した時点の時刻をとする。このタイムスタンプは、進捗ステータステーブル８ａへ作業済のタイムスタンプを格納する処理の他、進捗ステータスの格納を行った全てのログを記録するようにしても良い。

タイムスタンプは、図１０に示すように、タスクＩＤ毎に格納する。省略についても、省略と格納した時刻を格納する。未着手については、起票時処理３６が未着手を格納した時刻としても良いし、タイムスタンプなしとしても良い。このタイムスタンプ処理４４により、タスク毎に作業者の作業の完了時刻を管理することができ、タスク毎の平均リードタイム（所要時間）などを事後検証することができる。また、進捗ステータスの格納のログを記録する例では、作業者が、タスクを戻して修正等を行ったか否かなどを事後的に検証することができる。すなわち、進捗ステータスの格納のログを記録する例では、同一のタスクに戻って再作業した場合には、再作業のタイムスタンプが当初のタイムスタンプとは別に格納されるため、営業店担当者がどのような順序で作業したのかを事後検証することができる。

［進捗ステータス統制： 作業分岐］
好適な例では、作業分岐３４ａをタスク完了処理４０にて実装する。この例では、前記タスク完了処理４０は、作業分岐処理４６を備える。この作業分岐処理４６は、当該作業の作業データ６ａと、予め定められた作業分岐３４ａの条件とを比較して、当該比較結果に応じて次タスクＩＤを特定する。作業分岐３４ａの条件としては、債務者の態様（法人、個人、ノンバンク等の種類）や、債務者区分（正常先、要注意先等の種類）がある。作業分岐条件を満たし、作業分岐３４ａする際に、この作業分岐３４ａによってスキップするタスクＩＤの進捗ステータスを省略に変更する。作業分岐３４ａしない際には、通常の進捗制御となる。

［進捗ステータス統制： 特定スキップ］
好適な例では、一方向制御による作業者の任意での画面やタスクの終了画面側へのジャンプを禁止しつつ、予め定められた許容される終了画面側へのジャンプ（特定スキップという）を一方向制御に組み込むようにしても良い。この例では、前記タスク完了処理４０が、特定スキップ処理４８を備える。特定スキップ処理４８は、前記タスクの作業データ６ａの内容が予め定められた作業分岐条件を満たすとして前記作業者によるスキップの操作がなされた際に、前記一方向の順序によるタスクの予め定められた画面表示をスキップし、当該スキップしたタスクの作業データ６ａを自動的に生成し、当該スキップした各タスクの進捗ステータスをそれぞれ作業済に変更する。

また、画面スキップによる作業分岐３４ａと、債務者の態様による作業分岐３４ａとを別途管理するには、進捗ステータスに「自動」を追加しても良い。しかし、画面スキップの確認用のタスク及び画面（例えば、画面ＩＤ：13-30-01、図５８）を用意し、この画面スキップ確認タスク（T1330）の進捗ステータスが省略であるか作業済であるかを確認することで、特定スキップ処理４８が使用されたか否かを作業通番毎に導出することができる。すなわち、画面スキップ確認タスク（T1330）の進捗ステータスが作業済であれば特定スキップ処理４８が使用され、省略であれば使用されていない。

［進捗ステータス統制： 戻り先開始時］
次に、タスク開始処理３８の一部として、一方向制御処理４２を実装する例を説明する。このタスク開始処理３８は、戻った画面についてのタスク開始処理３８中に、それより終了画面側の全てのタスクＩＤの進捗ステータスを作業中に変更する。すなわち、タスク開始処理３８が、作業対象のタスクの進捗ステータスを作業中に変換する前後に、当該作業対象のタスクよりも終了タスク側の全てのタスクのうち作業済のタスクの進捗ステータスを作業中に変更することで、前記一方向制御処理４２を行う。

この例では、ジャンプして戻る要求に応じて、作業対象のタスクＩＤが開始画面側に戻った際に、その戻り対象画面のタスク開始処理３８にて、戻った画面のタスクＩＤより終了画面側の全てのタスクＩＤを作業中に変更する。すなわち、ジャンプして戻った際には、戻ったタスクＩＤより終了画面側の全てのタスクＩＤの「タスク完了処理４０」をなかったこととする。これは、ジャンプして戻った際には、戻ったタスクＩＤから戻る直前のタスクＩＤまでに作業者が入力し、確認したデータは全て作業中として扱うことを意味する。この例では、ジャンプして戻るのみで、戻ることによりジャンプした全てのタスクＩＤの作業を作業済の状態から作業中へ変更する。従って、一度ジャンプして戻ると、戻り先のタスクＩＤから終了画面側の全てのタスクについて再度作業することを強制する。

［進捗ステータス統制： 戻り先完了時］
次に、一方向制御処理４２を、タスク開始処理３８ではなく、タスク完了処理４０にて実装する例を説明する。この例では、戻った画面で入力変更があることを確認したときに、作業済のタスクを作業中に変更すると良い。例えば、前記タスク完了処理４０が、作業対象のタスクの進捗ステータスを作業済に変更する前後に、当該作業対象のタスクよりも終了タスク側の全ての作業済の進捗ステータスを作業中に変更することで、前記一方向制御処理４２を行う。この例では、入力対象画面が戻り、その戻り対象画面又は戻り対象画面より後の画面で入力があった場合に、入力された画面以後の進捗ステータスを作業中にする。戻った後も、作業した画面まで進むことができる。

［進捗ステータス統制： ジャンプ戻りと省略］
銀行業務のタスクの順序が単純な一次元ではなく並列があり、図４に示す作業分岐３４ａがある場合、進捗ステータスとして図８に示す省略を使用すると良い。この例では、進捗ステータステーブル８ａは、当該銀行業務の態様別に進捗が並列であるタスクＩＤを前記一方向の順序で一次元の並びとして有すると共に、前記進捗ステータスとして省略を有する。

そして、タスク完了処理４０は、前記銀行業務の態様別に異なる次タスクＩＤが定められている際には、前記完了処理のタスクＩＤから当該次タスクＩＤまでの進捗ステータスを省略に変更する。すなわち、作業分岐３４ａにより使用しないタスクＩＤについては、未着手から省略に変更する。

そして、一方向制御処理４２が、戻り先のタスクの進捗ステータスを作業中に変換する前後に、当該戻り先のタスクよりも終了タスク側の全てのタスクのうち省略の進捗ステータスを未着手に変更する。これにより、作業分岐３４ａのある例でジャンプ戻りがあっても、一方向制御をすることができる。

＜実施例１： 作業プロセス保存＞
図１２に、作業プロセスデータ６ｈのエンティティー・リレーションシップを示す。各ボックスの一段目はエンティティーの名称、二段目は主キー、三段目は項目である。例えば、進捗ステータステーブル８ａのエンティティーは、各作業を識別する主キーが作業通番とタスクＩＤとであるため、作業通番毎で、タスクＩＤ毎に、三段目に示す項目を有する。この項目は、進捗ステータスコード、作業者（作業者）ＩＤ、作業者名、タイムスタンプ等である。

図１２に示す例では、作業ステータス等の「判定」は、作業ステータステーブル９ａのエンティティーにて定義している。作業ステータスは、債務者を唯一に識別するＣＩＦ番号と、作業通番とを主キーとする。ＣＩＦ番号と作業通番とが定まると、当該作業の基準日を唯一に定めることができる。このエンティティーには、作業ステータスの他、実施例４に対応する例では、基礎データ６ｂを用いた計算にて作業が不要に該当するか否かを識別する作業不要該当コードと、作業者が選択した作業要否を示す作業要否コードと、作業者が選択した画面スキップの有無を示すスキップ有無とを有する。この作業不要該当コードと、作業要否コードと、スキップ有無は、「判定」の一例である。

また、図１２に示す例では、顧客別承認履歴テーブル９ｂのエンティティーを有している。このエンティティーは、ＣＩＦ番号と、作業通番と、店番や部門であるワークフローの単位を識別するノードＩＤとを主キーとする。各部門にて承認に該当する作業済が何時なされたかは進捗ステータステーブル８ａにも記録されるが、ここでは、重畳して、店番や部門単位の承認履歴を記録する。この顧客別承認履歴テーブル９ｂは、差戻し等のワークフローによっても利用される。
また、図１０に示す例では、営業店担当者から監査上級まであるが、全ての債務者の作業が再査定上級や監査上級までなされることはなく、信用リスク等に応じて、最終査定部門は異なる。また、信用リスクが類似する一群の債務者について、標本を抽出して監査をする際もある。このように、作業毎に最終査定部門がある例では、作業ステータステーブル９ａのエンティティーにて最終査定部門コードを保持すると良い。

図１３に、顧客別承認テーブル９ｂの一例を示す。この例では、再査定上級、監査上級まで作業が成されている。顧客別承認テーブル９ｂでは、承認日と、タイムスタンプと、承認店名・部門名と、承認者の作業者名とを管理する。顧客別承認履歴テーブル９ｂのみでは、最終査定されているか否か識別できないが、作業ステータステーブル９ａの最終査定部門コードを参照すると、最終決裁されているか否かを特定できる。

図１４に、作業ステータステーブル９ａの一例を、図１５に進捗ステータステーブル８ａの一例を示す。図１４及び図１５にて、作業通番が同一の作業は同一の作業である。
・例１： 作業通番１： 債務者の業況に変化が生じて手動（状況速報）にて作業を起票した。
・例２： 作業通番２： 債務者の決算書類を入手したため自動にて作業を起票し（決算検討）、債権額が一定額未満であるため作業不要該当コードにて不要とされていたが、作業者の判断で作業を要として作業している。
・例３： 決算検討で自動起票し、作業者が画面のスキップを選択した。
・例４： 決算検討で自動起票したが、作業不要となった。

作業通番１では、作業不要該当コードが要、作業者の判断結果を示す作業要否コードも要、画面のスキップは選択されず、作業ステータスは最終査定部門コード監査にて決裁である。決裁済であるため、作業通番１の進捗ステータスコードは、画面のスキップを除いて全て作業済となる。
作業通番２では、作業不要該当コードが不要として起票されたが、作業者が作業を要として作業中である。進捗ステータスを参照すると、管理・回収方針を作業中である。画面のスキップをしていないため、画面スキップタスクに省略が記録されている。
作業通番３では、画面のスキップをしている。作業ステータステーブル９ａのスキップ有無は、有となる。進捗ステータスは、統括者まで作業済で支店長の作業待ちであり、画面スキップも作業済となる。
作業通番４では、作業不要とされ、作業要否コードは否と記録される。作業ステータスは取消（確定）で、この場合、すべての進捗ステータスを取消に更新する。

このように、進捗ステータス統制により作業プロセス保存制御では、作業の最終的な結果のデータのみならず、その結果に至る作業プロセスについてのデータを明確に記録することができる。この作業プロセスに関する情報は、各種ステータスやコードなどであり、それは、作業者の判断の過程の記録となる。
そして、作業プロセスの保存は、判断過程を記録するため、判断過程の種類（過程や日時等）を検索キーとした検索が可能となり、データの可用性を向上させ、多様な情報伝達が可能となり、内部統制でいう情報の伝達の有効性を向上させることができる。判断過程が記録されると、作業者の判断の思考過程を追認しやすくなり、内部統制に必要なモニタリングの有効性を向上させ、そして判断の検証性を向上させることができる。また、判断過程の態様に応じた案件の抽出をコンピュータシステム４の利用により行うことができる。これらにより、モニタリングの有効性を向上させることができる。

＜実施例２： タスク処理のオブジェクト指向分析＞
図１６に示すように、実施例２では、タスク処理部１０の詳細構成と、トランザクション管理部５０の詳細構成とを開示する。
また、図１６に示す例では、コンピュータシステム４は、通信制御部３と、ワークフロー制御部９４とを備えている。コンピュータシステム４は、サーバーやメインフレームであり、通信制御部３を介して、勘定系システム及び情報系システム等のオンラインシステム７２や、債務者の情報を登録する取引先要項システム７４（特許文献４）や、不動産担保評価システム等のその他各種システム７６と接続されている。端末１は、据え置き型又は携帯用のパーソナルコンピュータとしても良いし、専用の端末１としても良い。ネットワーク２は、物理的なケーブルと、コネクタとを有し、ＴＣＰ／ＩＰなどのプロトコルによる通信信号を伝送する。

ここで、一方向制御、強制再表示、タスク処理部１０に必要な機能など各実施例のコンピュータシステム４の構成の要件を検討するために、図１７から図１９を参照して、ＵＭＬ（Unified Modeling Language, 統一モデリング言語）等によるオブジェクト指向分析を行う。
システムの実装に関しては、オブジェクト指向言語に限定するものではなく、手続型言語でも良いし、一部を直接に論理回路としても良い。オブジェクト指向によるモデルを手続型言語へのモデルへ変更することは、当業者にとって容易であるから、ここでは、オブジェクト指向分析により、本実施形態の各実施例に必要な情報処理内容の本質を開示する。
その後、この分析を参照しつつ、タスク処理部１０の構成及びその利点を説明する。

図１７に示すユースケースを参照して本実施例による銀行業務処理システムの開発要求を整理し、銀行業務処理システムに要求されるシナリオを可視化する。主に銀行が有する債権の価値を評価する資産査定作業（自己査定）を中心としつつ、銀行業務処理一般を対象とする分析をする。
ユースケースは、作業者の一般的な要求に応じて結びつけられた一群のシナリオである。この要求は、本実施例では、債権等の資産を管理し、監査する部門から発せられる。すなわち、作業者はユースケースを要求する作業者の一部ではあるが、全てではない。資産査定に必要な牽制効果等により、作業のシナリオは資産（債権）の監査部門が定める。一方向制御は、自己査定の監査のために、プロセスチェックを行うとして、そのプロセスそのものである。すなわち、一方向制御されたコンピュータシステム４を使用した作業は、必ず、同一のプロセスの牽制の元で実行されたことが保証される。

図１７のユースケース図に現れるユースケース（楕円で囲んだ文字で示される操作及び処理）を、コンピュータシステム４のデータ及び処理の振る舞いとして分析するために、図１８及び図１９のロバストネス図を用いる。ロバストネス図は、ユースケースの実現に必要な要素を画面に表示するボタンなどの境界（作業者インタフェース、ビュー）と、ビジネスロジックの実装となるコントローラーと、データベースやコンピュータシステム４のメモリー１０２（図２１参照）に格納されるデータ（モデル）との３種類（いわゆるＭＶＣ，Model, View and Controller）に分けてそれぞれの関係を整理するものである。
モデルの概要は、図２に示すデータ名であり、リレーショナルデータベースを活用する例では、図３４から図３７に示すエンティティー・リレーションシップである。ビューは、作業者インタフェースであり、画面要素の組み合わせと配置（レイアウト）である。画面要素やレイアウトは、図３に示すほか、例えば、図４０以下の具体的な画面例である。コントローラーは、ビジネスロジックの実装であるから、「処理（コンピュータシステム４の情報処理）」の組み合わせである。処理は、条件分岐と、繰り返しとを含む。

ロバストネス図では、境界とデータとは直接関係を持つことができず、必ずコントローラーを介して関係を持つ。すなわち、コンピュータシステム４では、端末１の画面と、データベースとが存在しても、コンピュータシステム４による情報処理がなければデータベースに格納されているデータと画面表示とは関係できない。コントローラーによる情報処理を必要とする。ロバストネス図でのコントローラーは、実装の具体的なオペレーティングシステムや開発言語を特定せずに、必須の情報処理の内容を特定するものである。ロバストネス図でのコントローラーは、図１６や図３１等のブロック図での各処理に対応し、図２３に示すクラス図等では、メソッド及びそのプログラムに対応し、図２０や図２７等のシーケンス図では、各工程に対応する。

コンピュータシステム４の開発に従事する当業者は、ロバストネス図と、タスクの要件と、画面のレイアウト情報とから任意のプログラム言語を用いて本実施例による銀行業務処理システムを開発することができる。すなわち、図１８及び図１９に示すロバストネス図は、本実施例によるシステムの作り方を開示する図である。ユースケース図とロバストネス図による開示は、本実施例によるシステムの使い方を明らかにする。すなわち、画面やボタンＢｘｘなどの境界（ビュー）に対して、コンピュータシステム４がどのように応答しなければならないかが明確となる。

図１７を参照すると、本発明の実施例のユースケースは、営業店担当者（Ａ１）とコンピュータシステム４との関係では、作業全体の操作（Ａ２）と、作業の各内容の判断（Ａ１０）と、個別作業の進捗の操作（Ａ２０)とを有する。ここでは、各画面での作業又は各タスクでの作業を、個別作業という。作業全体の操作（Ａ２）は、作業対象を選択し、作業を開始する操作（Ａ３）と、作業を終了する操作（Ａ４）とを含む。作業を終了する操作（Ａ４）の後に、当該作業を次のワークフロー先（例えば、当該営業店担当者（Ａ１）の上司である統括者等）へのワークフローを制御（Ａ５）する。また、作業の終了（Ａ４）は、作業の中断制御６２（Ａ６）に拡張しても良い。

作業の各内容の判断（Ａ１０）は、内容の確認処理（Ａ１２）と、内容の入力（Ａ１３）と、入力データ６ｃと基礎データ６ｂからの導出データ６ｄの計算（Ａ１４）とを含む。内容の確認（Ａ１２）を営業店担当者に促すには、先行して作業データ格納部等のデータベースにアクセス（Ａ１１）し、各作業の内容を端末１等に表示する。

格付自己査定の個別作業の進捗の操作（Ａ２０）には、次の個別作業に進む操作（Ａ２２）と、一つ前の個別作業へ戻る操作（Ａ２４）と、一つ前の個別作業よりも開始画面側に近い個別作業にジャンプして戻る操作（Ａ２５）とがある。次の個別作業に進む操作に先行して、その完了処理する個別作業の内容が所定の条件を満たすか否かを確認する情報処理（Ａ２１）を行っても良い。また、個別作業の進捗の操作に応じて、作業データ格納部等のデータベースへアクセス（Ａ２３）し、作業データ６ａを格納する。

本実施例では特に、個別作業の進捗の操作（Ａ２０）に関して、個別作業を一方向として、その方向への画面及びタスクのジャンプを禁止する。従って、「ジャンプして進む」というユースケースは存在せず、個別作業の完了時には、予め定められた次の個別作業へ進む。ジャンプして戻った後も、その戻った個別作業の完了時には、その戻った先の個別作業に対して予め定められた次の個別作業へ進むのみである。一方向制御下では、いかなる場合も終了画面側へのジャンプはできない。但し、条件分岐や省略など予め定義されている場合には、一定の個別作業を飛ばして終了画面側へ画面を進捗させることがあるが、これは、条件分岐や省略として予め定義されている際に可能であり、一方向制御による業務プロセスの例外ではない。

この画面（タスク）の進捗を一方向に制御（Ａ２６）するための情報処理は、ユースケース（Ａ２２、Ａ２４及びＡ２５）に含まれており、これらの進捗の操作との関係で情報処理内容を検討することとなる。この進捗の一方向制御（Ａ２６）は、営業店担当者等の作業者が操作できないものであり、作業者にとって強制的なシステム要件となる。このため、営業店担当者（Ａ１）が直接に一方向制御のユースケースにアクセスすることはない。あくまで、個々の進捗操作の内側の情報処理となる。これをシステム要件として検討すると、この一方向制御は、一般的な画面推移のための情報処理を拡張するものとなる。

図１８は、本実施例による作業での個別判断に必要なシステム要素の関係を示すロバストネス図である。図１８に示す例では、営業店担当者（作業者）によって使用される端末１に表示する境界（作業者インタフェース）として、個別作業の判断と関係する境界を例示する。この境界は、図１７に示すユースケースから導かれる。
・内容を確認するユースケース（Ａ１２）に対して、内容を端末１に表示するための個別作業画面（Ｃ１）と、画面要素（Ｃ３）。
・内容を入力するユースケース（Ａ１３）に対して、要素属性が入力編集可である画面要素（Ｃ３）。
・計算するユースケース（Ａ１４）に対して、計算をコンピュータシステム４に指示する操作を受け付けるための計算ボタンＢ７。
・本実施例では特に、ワークフローに関して作業を開始し、終了するユースケース（Ａ３，Ａ４）と、個別作業に関して次の個別作業に進むユースケース（Ａ２２）とに対して、次へボタンＢ１。
・作業の終了の拡張である作業の中断のユースケース（Ａ６）に対して、中断ボタンＢ４。

このように、図１８に示す例では、境界として、作業データ６ａを表示する枠となる個別作業画面（Ｃ１）と、この画面の入力フィールド（Ｃ３）と、計算要求をコンピュータシステム４に送信する操作を受け付ける計算ボタンＢ７と、個別作業画面またはタスクの完了要求をコンピュータシステム４に送信する操作を受け付ける次へボタンＢ１と、作業の中断要求をコンピュータシステム４に送信する操作を受け付ける中断ボタンＢ４とを有する。ここでは、説明の簡略化のために境界をボタンＢｘｘとしているが、メニューの項目としても良いし、コンボボックスの選択肢としても良いし、次へ・戻る等の指定を受信するラジオボタンと、唯一の実行ボタンとの組み合わせとしても良い。

本実施例では、上記のユースケースと境界との関連付けでは、作業の開始や、終了や、作業開始から終了までの画面やタスクの推移について、次へボタン（Ｂ１）の操作としている。この次へボタンの多様性により、作業者にとって理解しやすい操作を実現する。従って、「次へボタン」の画面表示用の名称は、「開始」「次へ」「終了」「○○社へ」「登録」などその画面に応じて作業者が理解しやすい名称とするとよい。
また、図１７では、各内容の判断についての情報処理（ビジネスロジック部分）を抽出する分析であるため、ユースケース（Ａ２４）及び（Ａ２５）に対応する境界は定義しない。

また、モデル（データ構造）としては、図１８に示す例では、リレーショナル又は階層型などのデータベースを採用し、各種データを作業データ格納部６に格納する。作業データ格納部６に格納するデータとしては、基礎データ６ｂ、入力データ６ｃ及び導出データ６ｄがある。また、作業者によって作業が開始された作業データ６ａは、一時変数ｔｄとしてコンピュータシステム４のメモリー１０２（図２１参照）に格納すると良い。データ構造として、その他、各画面の画面定義情報７ａを格納する画面定義ファイル７（図１６等に示す例では、画面定義情報格納部７）を有する。
コントローラーは、このモデルと境界との関係を制御する情報処理となる。

個別作業画面（Ｃ１）に対して、表示制御（Ｃ２）が必要となる。この表示制御（Ｃ２）には、図１８中、右上の次の個別作業に進む（Ａ２２）という処理が先行している。次の個別作業に進むには、さらに、作業が選択され作業を開始する（Ａ３）という処理が先行する。従って、作業開始（Ａ３）、次の個別作業へ進む（Ａ２２）という処理を経て、表示制御（Ｃ２）が実行される。なお、格付自己査定開始直後の最初の画面では、ユースケース（Ａ３）と（Ａ２２）とを一体としても良い。

作業の個別作業画面を端末１に表示するには、先行して、作業の作業対象を選択して作業が開始（Ａ３）され、次の個別作業に進む操作がなされる。そして、作業データ格納部から基礎データ６ｂ及び導出データ６ｄを読み出して、コンピュータシステム４のメモリー中に一時変数ｔｄとして格納する。この一時変数ｔｄを一定のレイアウトで個別作業画面に表示するための処理が必要となる。この処理を表示制御（Ｃ２）とする。

表示制御（Ｃ２）は、図１６に示す例では、表示制御処理１６である。表示制御処理１６（Ｃ２）は、作業画面を特定する画面ＩＤやタスクＩＤと、債務者を識別するＩＤ等を引数として、作業データ格納部に格納されたデータのうち、当該債務者で、当該画面に関連した作業データ６ａを読み出して一時変数ｔｄに格納する。そして、画面ＩＤに対応するレイアウト情報や要素属性情報を画面定義情報７ａから読み出して、この画面定義情報７ａの指定に応じて作業データ６ａを個別作業画面（Ｃ１）に表示する。

この表示制御（Ｃ２）は、例えば、個別作業画面がＷｅｂブラウザーであれば画面定義情報７ａに応じたＨＴＭＬファイルに作業データ６ａを合成し、端末１に当該ＨＴＭＬファイルを送信する処理である。特別なアプリケーションプログラムなどを端末１にインストールし、実行させるのであれば、画面定義情報７ａと作業データ６ａとをフィールド名やＸＭＬのタグで関連させ、表示用のデータは端末１側で生成してもよい。コンピュータシステム４をメインフレームとする場合には、画面表示用のデータをコンピュータシステム４側で完全に生成してその画面表示用のデータを端末１に送信する。また、個別作業画面が携帯用端末１である際には、携帯端末１で表示できるプロトコルのデータに変換して送信する。この表示制御（Ｃ２）の内容は、コンピュータシステム４のオペレーティングシステムと端末１の種類によって定めれば良い。

個別作業画面（Ｃ１)は、その画面に画面要素（Ｃ３）を有する。画面要素（Ｃ３)に入力されるデータは、営業店担当者によるコメントである文字データや、財務項目の実態修正値である数字データや、チェックボックスやラジオボタンの選択結果などである。この画面要素（Ｃ３)に入力されたデータは一時的に端末１のメモリー（Ｃ４，図１８）に格納される。画面要素は、ＧＵＩ（graphical User Interface)を使用しても良いし、特別な端末１のキーボード上の特殊な物理的ボタンとしても良い。
端末１にて入力内容の保持をするメモリー（Ｃ４）に保持される入力データ６ｃは、計算ボタンＢ７又は次へボタンＢ１の操作に応じて、コンピュータシステム４に送信される。

計算ボタンＢ７は、営業店担当者が、入力データ６ｃから導出データ６ｄを計算する指示を端末１及びコンピュータシステム４に対して命じる際に操作される画面要素である。この計算ボタンＢ７の操作に応じて、端末１のメモリー１０２（Ｃ４）に保持された入力データ６ｃと、他の基礎データ６ｂ等とを使用して、導出データ６ｄを算出する計算処理１８（Ｃ６）が必要である。そして、計算処理１８（Ｃ６）した結果は、一時変数ｔｄを介して表示制御処理１６（Ｃ２）により個別の作業画面（Ｃ１）に表示する。

一方、入力編集可の画面要素に入力データ６ｃが入力されたが、計算ボタンＢ７が操作されないまま、次へボタンＢ１が操作されることが想定できる。このため、計算処理１８（Ｃ６）は、次へボタンＢ１が操作されたときも実行すべき処理である。従って、計算処理１８（Ｃ６）は、計算ボタンＢ７の操作による場合と、次へボタンＢ１の操作による場合とがある。

また、作業では、ある画面又はタスクについて、作業が完了したとの作業者の判断が入力された際には、図１８に示す例では、次へボタンＢ１が操作された際には、その画面又はタスクにて入力された入力データ６ｃがその画面内で予め定められた条件を満たしているか否か確認する処理があると良い。例えば、貸借対照表は、資産と、負債及び資本との合計が一致するものであるところ、流動資産の資産性を検討し、実態値を入力した際には、実態値の入力による資産の減額と同額分資本を減額させるなどの処理が必要となる。この資産と資本で減額した額が相違するのは整合性がないため、資産と資本の減額が同額であるか否か確認し、同額でない場合には、営業店担当者に注意を促し、次の画面又はタスクに進むことを許可しない条件確認処理２０（Ｃ１２，図３１参照）が考えられる。また、ある画面にて特定の操作をした際に、付随的に必須とする操作がある際に、その必須の操作を行っているか否かを確認する条件確認処理２０（Ｃ１２）も想定できる。この条件確認処理２０（Ｃ１２）は、端末１のメモリー（Ｃ４）と、一時変数ｔｄとに格納された作業データ６ａを用いて行う。

次へボタンＢ１が操作された際には、条件確認処理２０（Ｃ１２）と共に、格納処理２２（Ｃ１３）が必要となる。すなわち、次へボタンＢ１が操作された画面又はタスクの作業用のデータ（一時変数ｔｄ）を作業データ格納部に格納する。計算ボタンＢ７ではなく、次へボタンＢ１の操作によって必要となる計算処理１８（Ｃ６）については、格納処理２２（Ｃ１３）の一部としても良い。すなわち、条件確認処理２０（Ｃ１２）にて例外が発生する際には、営業店担当者（Ａ１）に満たさない条件を知らせるためのアラート用のパネルを表示するなどの処理が必要となる。このとき、計算ボタンＢ７を操作してその結果を端末１の個別作業画面（Ｃ１）にて確認すべき際には、アラート用のパネルにて計算ボタンＢ７の操作を営業店担当者に促すことができる。一方、このような端末１での確認を必要としない計算処理１８（Ｃ６）については、格納処理２２（Ｃ１３）の一部とすることができる。

中断ボタンＢ４は、作業の終了の拡張として、作業の全体を完了させることなく当該作業を終了させるための中断要求をコンピュータシステム４に送信するものである。中断ボタンＢ４が操作される際には、現画面による作業も中途であると想定することができる。中断ボタンＢ４からの中断要求の際には、条件確認を行わず、作業データ６ａの格納を行い、その後、作業を終了させる。これにより、再開した際には、すでに入力した入力データ６ｃが画面に表示され、再入力する必要がない。このような処理を実装するには、一時変数ｔｄを強く型付けし、作業データ格納部の型と関連させておくと良い。

図１８に示すように、図１７のユースケースから、次へボタンＢ１に多様性を持たせる構成では、表示制御（Ｃ２）、計算（Ｃ６）、条件確認（Ｃ１２）及び格納（Ｃ１３）というコントローラーをコンピュータシステム４に実装することで、個別作業の各内容の判断を作業者に促す情報処理を実現することができる。
これは、図１６に示すタスク処理部の表示制御処理１６、計算処理１８、条件確認処理２０及び格納処理２２に対応する。

図１８に示す例では、各処理（Ｃ２、Ｃ６、Ｃ１２及びＣ１３）は、一時変数ｔｄを共有し、一時変数ｔｄを対象とした情報処理としている。この点、まず、一時変数ｔｄと作業データ格納部との間の情報処理を、ＤＢアクセス（Ｃ８、Ｃ９，図２１のデータベースアクセス１１８）として、各処理（Ｃ２、Ｃ６、Ｃ１２及びＣ１３）から隠蔽することで、この各処理と作業データ格納部の詳細構成とを独立させることができる。次に、コンピュータシステム４と端末１との通信についても、端末１にて表示し、又は入力される作業データ６ａと、一時変数ｔｄとのデータ授受がなされれば、各処理（Ｃ２、Ｃ６、Ｃ１２及びＣ１３）はこの端末１とのデータの送受信の処理から独立できることとなる。すなわち、図１８に示す処理（Ｃ２、Ｃ６、Ｃ１２及びＣ１３）は、一時変数ｔｄを対象とする情報処理として、そのビジネスロジックのみを実装すればよい。

このビジネスロジックのプログラマーは、端末１と一時変数ｔｄとの間のデータの送受信や、一時変数ｔｄとデータベース（作業データ格納部）との間のデータの読み出し及び書き込みの具体的な処理内容を知る必要がない。
この一時変数ｔｄを、タスクを単位とした作業データ６ａとすると、情報処理が極めて簡易となる。このタスク毎の作業データ６ａである一時変数ｔｄを、タスクデータｔｄという。
図１６に示す例では、タスク処理部１０は、タスクデータ管理処理１４を備えており、このタスクデータ管理処理１４は、一時変数ｔｄをこのタスクデータｔｄとして取り扱う。

＜実施例２： タスク処理の共通性と独立性＞
図１８を参照して分析したように、実施例２のタスク処理部１０は、図１６に示すように、タスクデータ管理処理１４と、表示制御処理１６と、計算処理１８と、条件確認処理２０と、格納処理２２とを備えている。タスク処理部１０は、表示制御と、計算と、条件確認と、格納とを必ず備えることで、複数のタスクを含む銀行業務処理システムにて、個別のタスクの個々の情報処理について、共通性と独立性の良いバランスを得ることができる。

タスクデータ管理処理１４は、前記タスクＩＤで識別される各タスクで使用する前記作業データ６ａをタスク毎の一体のタスクデータｔｄとして管理する。すなわち、個別タスク毎に特別のデータ構造を採用するのではなく、タスクが取り扱う対象はすべてタスクデータｔｄのデータ構造を基本とする。

表示制御処理１６（Ｃ２，query（））は、作業対象のタスクＩＤのタスクデータｔｄとなる作業データ６ａを前記作業データ格納部から読み出して当該タスクＩＤに対応する前記画面定義情報７ａに従って当該画面要素及び当該作業データ６ａを前記端末１の画面に表示する。
計算処理１８（Ｃ６，calculate（））は、前記入力編集可の画面要素に入力される入力データ６ｃを含む前記タスクデータｔｄを使用して前記導出データ６ｄを算出する。
条件確認処理２０（Ｃ１２，confirm（））は、当該タスクＩＤのタスクデータｔｄの予め定められた整合性を確認する。
格納処理２２（Ｃ１３，set（））は、当該整合性の確認された当該タスクデータｔｄを前記作業データ格納部６に格納する。

この表示制御処理１６と、計算処理１８と、条件確認処理２０と、格納処理２２とを備えることで、進捗制御やワークフロー制御を除くと、複数のタスクからなる銀行業務に必要な多様な情報処理に対応することができる。すなわち、一方向制御がなされ、タスクデータを単位とするタスクで必要なメソッドはこの４つのみである。
この表示制御処理１６と、計算処理１８と、条件確認処理２０と、格納処理２２のセットは、オブジェクト指向での抽象メソッドとなり得る。すなわち、銀行業務処理を構成する個別のタスクの個々のタスクは、取り扱うデータや計算内容は異なるが、タスクデータと、抽象メソッドの組み合わせにより共通性を取り出し、抽象化することができる。すると、全ての銀行業務の処理をタスクという単位でとらえ、必要な情報処理を表示制御処理１６と、計算処理１８と、条件確認処理２０と、格納処理２２の４つの何れかに対応させることができる。
これにより、例えば、銀行業務処理の個別のタスクは、抽象クラスのタスクを継承すれば良く、この４つの抽象メソッドをＪＡＶＡ（登録商標）のインタフェースとして必ず装備する仕組みとすると、タスクを利用する側のプログラムを何ら変更することなく、個別のタスクの追加・修正をすることができる。

このように、タスク処理部１０が、予め定められた処理セット（表示制御、計算、条件確認及び格納）を有することで、オブジェクト指向での抽象メソッドによる共通性と個々のタスク処理の独立性を得ることができる。抽象メソッドによる共通性を高めることで、進捗制御等（のプログラマー）や、端末１は、個別のタスクの実装を知ることなく、共通した処理セットを利用して全ての個別のタスクを呼び出し、使用することができる。
個別のタスクについてこの処理セットを実装すると、一方向制御との協調により、個別のタスク処理の独立性を高め、情報処理内容を局所化し、タスク間の依存関係を緩めることでタスク毎の開発や変更を容易とすることができる。

図１６に示す例では、タスク処理部１０が、照会表示処理２８（Ｃ２）を備えている。各タスクの処理中に参考となる情報群がある一方、その情報を全ての事例で参照すべきではない場合、一方向に並べるタスク群とは別に、情報の照会機能を設けると良い。
タスク処理部１０の照会表示処理２８（Ｃ２）は、タスクに対応する画面の表示中に参考情報の照会要求を受信した際に、当該作業対象のタスクの画面とは別に当該参考情報を入力編集不可の状態で表示する。参考情報は、銀行業務処理システムにて一方向制御されないデータ群でも良いし、一方向制御される開始画面側のデータ群でも良い。

図１９は、本実施例による作業での進捗作業に必要なシステム要素の関係を示すロバストネス図である。図１９に示す例では、境界（作業者インタフェース）として、個別作業の進捗の操作と関係する境界を例示する。この境界は、図１８に示す例と同様に、図１７に示すユースケースから導かれる。
・次の個別作業に進むユースケース（Ａ２２）に対して、次へボタンＢ１。
・一つ前の個別作業に戻るユースケース（Ａ２４）に対して、戻るボタンＢ３。
・ジャンプして戻るユースケース（Ａ２５）に対して、ジャンプして戻るボタンＢ２。

このように、図１８に示す例では、ＧＵＩとして、現在の画面又はタスクの完了と次画面の表示の要求をコンピュータシステム４に送信する次へボタンＢ１と、現在の画面又はタスクの一つ前の画面又はタスクを呼び出す要求をコンピュータシステム４に送信する戻るボタンＢ３と、一つ前の画面又はタスクより開始画面側の画面又はタスクへ戻る要求をコンピュータシステム４に送信するジャンプして戻るボタンＢ２を備えている。図１８に示す次へボタンＢ１と、図１９に示す次へボタンＢ１とは同一の境界である。

図１９に示す例で境界（各ボタン）Ｂ１、Ｂ２及びＢ３と、この進捗ステータス格納部８との間の情報処理は、進捗の状態を進捗ステータスとして管理し、さらに、進捗を一方向に制御するユースケース（Ａ２６）を実装する。図１９に示す例では、進捗ステータスは、作業の完了を示す進捗ステータスと、作業の開始を示す進捗ステータスとである。

図１９に示すロバストネス図では、図中上側の格付自己査定の各内容を判断するとのユースケースが、図中下側にも現れる。上側のユースケースをＡ１０ａとし、下側をＡ１０ｂとする。上側Ａ１０ａは、作業完了する画面又はタスクであり、下側Ａ１０ｂは、進捗制御の直後に表示される次の画面又はタスクである。格付自己査定の各内容の判断（Ａ１０ａ）が完了すると、次へボタンＢ１が操作され、条件確認（Ｃ１２）、計算（Ｃ６）を含む格納（Ｃ１３）が処理される。格納（Ｃ１３）が正常に完了すると、続いて、図１９に示す個別作業の完了（Ｃ２０）を処理する。個別作業の完了（Ｃ２０）に応じて、進捗ステータスを作業済に更新しなければならない。この進捗ステータスの更新を進捗ステータス管理（Ｃ２２）が処理する。

また、この個別作業の完了（Ｃ２０）では、図４に示す作業または画面の分岐（Ｃ２１）を処理する。図４（Ａ）に示す例では、画面ＩＤ：３の完了処理に作業分岐３４ａが定義され、この分岐処理（Ｃ２１）が一時変数ｔｄの要素を参照して次画面ＩＤを４又は５とする。

個別作業の完了（Ｃ２０）に続いて、次画面ＩＤまたは次タスクＩＤの特定処理を行う。次の個別作業の特定（Ｃ２３）は、例えば図４に示す各種のデータ構造の実装に応じて、次画面ＩＤ又は次タスクＩＤを特定する。このデータ構造は、進捗ステータスのテーブルとして実装しても良いし、個別作業の完了のプログラム内に実装しても良い。一方向制御処理４２（Ｃ２８）を実装するには、次タスク特定処理３４（Ｃ２３）を強制的な処理とする。

戻るボタンＢ３と、ジャンプして戻るボタンＢ２の操作に応じた戻り先の個別作業の特定については、図１９に示す例では、端末１側で処理する。次に対象となる画面又はタスクが特定されると、この画面又はタスクの開始（Ｃ２４）を処理する。進捗ステータス管理（Ｃ２２）は、開始した画面又はタスクの進捗ステータスを開始に更新する。この開始（Ｃ２４）は、開始対象の画面ＩＤ又はタスクＩＤを画面定義制御（Ｃ２９）及び表示制御（Ｃ２）に渡す。画面定義制御（Ｃ２９）及び表示制御（Ｃ２）は、この画面ＩＤを用いて個別作業画面（Ｃ１）に作業データ６ａを表示する。

ジャンプして戻るボタンＢ２は、現画面又は現タスクより開始画面側の画面ＩＤ又はタスクＩＤを唯一に指定する選択肢の集まりである。進捗フロー管理（Ｃ２７）は、進捗ステータスを参照して、進捗ステータスが完了の画面ＩＤ又はタスクＩＤを読み出して、これをリスト又はツリーとして、端末１の画面に表示する。このリスト又はツリーは、進捗フローを示し、同時に、ジャンプして戻るボタンＢ２となる。

図１９に示すように、進捗制御に関するコントロールでは、タスクの完了処理（done()、Ｃ２０）、次タスク特定処理（getNextTask()、Ｃ２３）、タスクの開始処理（start()、Ｃ２４）、及び、タスクの表示制御処理（query()、Ｃ２）の繰り返しと、ジャンプして戻る処理とがあれば良い。
これに対応して、図７、図１６及び図３１に示す進捗制御部３０は、タスク完了処理４０（done()、Ｃ２０）、次タスク特定処理３４（getNextTask()、Ｃ２３）、タスク開始処理３８（start()、Ｃ２４）とを備え、図１６に示すタスク処理部１０は、表示制御処理１６（query()、Ｃ２）を備えている。

図２０は、進捗制御部３０による進捗管理処理の一例を示すシーケンス図である。図２０に示す例では、端末１からコンピュータシステム４へ送信される進捗管理に関する要求は、タスク開始要求と、タスク完了要求との繰り返しである。次へボタンＢ１の操作に応じて、現タスクであるタスク完了処理４０（Ｃ２０）と、次タスク特定処理３４（Ｃ２３）と、次タスクのタスク開始処理３８（Ｃ２４）とが要求される。

図２０に示すように、端末１にて銀行業務処理システム用の画面を呼び出すと、ログイン処理などを経て、銀行業務処理システム用のメイン画面の表示要求をコンピュータシステム４に送信する。進捗制御部３０の起票時処理３６は、各作業の進捗ステータステーブルを生成し、タスクＩＤの列と、全ての進捗ステータスについて未着手を格納する。

コンピュータシステム４は、各作業の図２０のステップＳ１では、作業の一覧をメイン画面（例えば、図４０）として表示する。メイン画面の操作に応じて作業が選択されると、最初の画面を表示する。この画面の次へボタンＢ１が操作されると、端末１は、まず、タスク完了処理要求（done()）をコンピュータシステム４に送信する。コンピュータシステム４では、タスク完了処理４０が、この画面のタスクの進捗ステータスを作業中から作業済に変更する。

図２０に示す例では、タスク完了処理４０の次に、次タスク特定処理３４を行う。具体的には、端末１が、次タスク特定要求（getNextTask()）をコンピュータシステム４に送信する。また、タスク完了処理要求の後にコンピュータシステム４が自動的に次タスク特定要求を発しても良い。コンピュータシステム４では、次タスク特定処理３４は、進捗ステータステーブル８ａを参照して、進捗ステータスが未着手又は作業中であるタスクＩＤのうち最も開始タスク（T1000）側に近いタスクＩＤを特定する（Ｓ２ａ）。
この次タスク特定処理３４は、作業通番から当該作業の進捗ステータステーブル８ａを特定し、この進捗ステータステーブル８ａの進捗ステータスをタスクＩＤの小さい順に走査し、最初に未着手又は作業中を発見した際に、そのタスクＩＤを次タスクＩＤとする。中断制御６２が行われた場合には未着手ではなく作業中を発見する。
図２０に示す例では、次タスク特定処理３４は、この次タスクＩＤを端末１に返し、タスク開始要求の受信を待機する。別の例では、特定した次タスクＩＤを使用して、端末１からの再度の要求の受信処理を行わずに、タスク開始処理３８を処理するようにしてもよい。

端末１は、次タスクＩＤが特定されると、タスクＩＤを引数として、タスク開始要求を送信する。コンピュータシステム４のタスク開始処理３８は、このタスクＩＤの進捗ステータスを未着手から作業中に変更する（ステップＳ３ａ）。続いて、当該タスクの画面の表示制御等を処理し、端末１の画面に作業データ６ａを表示し、営業店担当者による作業を促す。営業店担当者は、チェックボックスなどの画面要素を操作し、入力編集可のフィールドに数値やコメントなどを入力することで、タスクの作業を行う。

タスクの作業が完了すると、営業店担当者は、次へボタンＢ１を操作することで、当該タスクの作業完了要求をコンピュータシステム４に送信する。コンピュータシステム４では、作業データ６ａを確認し、必要な計算処理１８をし、作業データ格納部に格納する。続いて、タスク完了処理４０は、このタスクの進捗ステータスを作業中から作業済に変更する。

続いて、このタスクについての営業店担当者の作業が完了すると、次タスクＩＤの特定処理（Ｓ２ｂ）にて、進捗ステータステーブル８ａを参照して、次タスクを特定する（Ｓ２ｂ）。さらに、この特定されるタスクＩＤのタスク開始処理３８を実行することで、進捗ステータスを作業中に変更する（Ｓ３ｂ）。このタスクに対する営業店担当者の作業が完了すると、タスク完了処理４０を行うことで、進捗ステータスを作業済に変更する（Ｓ４ｂ）。このように、進捗制御部３０は、次へボタンＢ１の操作に応じて、タスク完了処理４０（Ｓ４ｘ）、次タスク特定処理３４（Ｓ２ｘ）、タスク開始処理３８（Ｓ３ｘ）とを一方向の順序で定義されたタスクＩＤの順序にて繰り返すことで、タスクの進捗を制御する。

＜実施例２： タスクデータとクラス体系＞
［ハードウエア資源］
図１８及び図１９に示すロバストネス図では、個別作業の各内容を判断するために必要な境界及びコントローラーと、個別作業の進捗を操作するために必要な境界及びコントローラーとを導出した。そして、各処理につき、図１６等にブロック図の要素として符号と名称とを付与し、図１０及び図１１に示す進捗ステータステーブル８ａとの関係や、具体的なタスク処理部１０の内容等を説明した。
次に、実施形態及び各実施例の銀行業務処理システムをどのようなクラス体系で実装することができるかについて、図２１から図３０を参照して開示する。図２１及び図２２に示すクラス構成は、主にＪＡＶＡ（登録商標）での用語と技術的前提で説明する。このようなクラス体系をフレームワークという。プロセス管理についての説明では、このようなフレームワークに依存せずにプロセス管理に必要な処理を独立させる手法を説明する。

図２１は、銀行業務処理システムのハードウエアとソフトウエアとの関係を示すブロック図である。端末１、ネットワーク２、他システム７０の構成、通信制御部３につては、図１６等に示す構成と同様である。
コンピュータシステム４（サーバー４Ａ）は、ランタイムシステム１００と、メモリー１０２と、ＣＰＵ１０３と、クラス群１０４とを備えている。このサーバー４Ａは、銀行業務データベース１２１と、プログラムファイル格納部１２２とを備えると良い。

ＣＰＵ１０３は、所定の命令セットを有しメモリー１０２に格納される命令とデータとに従って命令を実行する。メモリー１０２は、このＣＰＵ１０３の主記憶となる。
銀行業務データベース１２１は、作業データ６ａ等を図３４から図３９に示す構成で格納するリレーショナルデータベースである。また、プログラムファイル格納部１２２は、プログラムの中間コードであるクラスファイルや、画面定義情報７ａを格納するハードディスク等である。銀行業務データベース１２１は、図１６等に示す作業データ格納部６、進捗ステータス格納部８及び作業ステータス格納部９として機能する。

ランタイムシステム１００は、ＣＰＵ１０３とメモリー１０２とを使用して仮想マシンとしてクラスファイルを実行する。ランタイムシステム１００は、プログラムファイル格納部１２２に格納されたクラスファイルをロードし、端末１からの要求に応じて、要求名に対応するメソッドを特定し、そのメソッドを実行することで、銀行業務データベース１２１からデータを読み出し、または、書き込み、計算し、端末１に作業データ６ａを送信する。クラスファイルは、本実施形態による銀行業務用プログラム１２４を有する。
また、サーバー４Ａは、開発環境で開発されたクラスファイルや画面定義情報７ａ等を記録媒体から読み出すためのドライブ又は端子を備えると良い。

［クラス体系］
クラス群１０４は、銀行業務用プログラム１２４のクラスファイルに定義されたクラスのうち、本実施形態及び各実施例の情報処理に関連するクラスである。図２１のクラス群１０４に示す各要素がクラスであることを明示する際には、「・クラス」を付し、符号にＣを付加する。また、図２４に示すように、インスタンスである際には、「・インスタンス」を付し、符号にＩを付加する。

タスク・インヴォーカー１０６は、前記端末１との通信を制御して、端末１からの要求に応答する。
タスクマネージャー１０８は、個別タスク・インスタンス１１２Ｉのメモリー１０２での位置等、タスクについてのデータを管理する。
タスク１１０は、個別タスク１１２の抽象クラスであり、図１８及び図１９を参照した分析により導かれた個別タスクが有すべきメソッドの基本が定義されている。
個別タスク群１１２ｘは、タスク１１０を承継し、当該各個別作業での前記作業データ６ａに対する個々の情報処理でタスク１１０のメソッドを上書きする。

プログレスマネージャー１１４は、上位クラスのメソッドを承継しつつ、進捗ステータステーブル及び作業ステータステーブル９ａを管理する進捗メソッド及び作業メソッドを有する。すなわち、プログレスマネージャー１１４は、完了処理メソッド（done()）及び表示制御メソッド（query()）とに応じて、個別タスク群１１２ｘの各タスクＩＤに依存せずに進捗ステータステーブル８ａを管理する。プログレスマネージャー１１４は、タスク開始処理３８及びタスク完了処理４０の部品で、起票時処理３６の実装であり、実際に進捗ステータスを更新する処理を行う。

タスクデータ１１５は、タスクデータアレイｔｄａを集約してタスクデータｔｄとして機能させる。
進捗ステータステーブル１１６は、進捗ステータスを管理する。
データベースアクセス１１８は、銀行業務データベース１２１とのＩ／Ｏについての抽象クラスである。
タスクデータライター１２０は、銀行業務データベース１２１から読み出した作業データ６ａからタスクデータｔｄを構築し、またタスクデータｔｄを格納する。

図２２に示す例では、個別タスク毎に、個別タスク・クラス１１２Ｃｘを有する。この個別タスク・クラス１１２Ｃａ，１１２Ｃｂ，…は、タスク・クラス１１０Ｃのサブクラスである。個別タスク・クラス１１２Ｃａ，１１２Ｃｂ，…は、銀行業務を構成する個々のタスクである。
また、タスク・インヴォーカー・クラス１０６Ｃは、サーブレット１３０のサブクラスであり、端末１とサーバー４Ａとの通信を制御する。

図２２中、白抜三角の実線で示す関係は、継承関係である。例えば、各ＤＢアクセス・クラス１３６Ｃａ，１３６Ｃｂ，…，１３８Ｃａ，１３８Ｃｂ，…は、ＤＢアクセス・クラス１１８Ｃを承継したサブクラスである。
菱形と実線で示す関係は、集約である。例えば、タスクデータ・クラス１１５Ｃは、タスクデータアレイを集約し、タスクデータアレイは、明細や、作業を集約する。白抜き三角で点線は、インタフェースの実装を示す。タスククラス１１０Ｃ又はタスクは、タスク・インタフェース１３４で定義されるメソッドの全てを実装する。

各クラスは、図２３に示すメソッドを有する。図２３に示す例では、パブリックなメソッドのうち、図１８及び図１９に示す各コントローラーや、図３１に示す各処理と対応するメソッドを示しており、各クラスが有するすべてのメソッドを示すものではない。

タスク１１０は、タスク処理部１０の表示制御処理１６（Ｃ２，query（））、計算処理１８（Ｃ６，calculate（））、条件確認処理２０（Ｃ１２，confirm（））及び格納処理２２（Ｃ１３，set（））に対応したメソッド（query（），calculate（），confirm（），set（））を有する。さらに、タスク１１０は、進捗制御部３０のタスク完了処理４０（done()、Ｃ２０）、タスク開始処理３８（start()、Ｃ２４）に対応したメソッド（done()，start()）を有する。タスク・クラス１１０Ｃを承継する個別タスク群１１２Ｃはもこのタスク処理部に必要なメソッドを実装する。進捗ステータステーブル１１６Ｃは、次タスク特定処理３４に対応するメソッド（getNextTask()）を有する。
各メソッドについては、クラス体系と銀行業務用プログラム１２４との関係で後述する。

［ダイナミックリンケージ］
図２４は、タスクとタスク・インヴォーカーとの協調の仕組みを示すＵＭＬによるコラボレーション図である。図２４中、１，１．１，１．２等とあるのは、処理の順序を示す。また、図２４に示す構成はクラスというひな形ではなく、実際にメモリー１０２にロードされたインスタンス（オブジェクト）である。
図２４に示すように、本実施例では、各コマンド（start(), done(), confirm(), calculate(), set()）の実行に際して、実行を要求するタスクを実行時に指定するダイナミックリンケージを採用すると良い。また、図２５に示すように、タスクのインスタンスのメモリー１０２上の位置をタスクマネージャー１０８が管理するフライウェイトを採用すると良い。

この例では、タスクマネージャー１０８は、前記サーバー４Ａの起動時に、前記タスクのインスタンス１１２Ｉｘを唯一に生成し、当該インスタンス１１２Ｉｘへの参照であるメモリー１０２上の位置を管理する。このタスクマネージャー１０８は、タスク・インヴォーカー１０６から呼び出された際に、タスクＩＤから前記タスクのインスタンス１１２Ｉｘへの参照を返すことで、当該タスクのインスタンス１１２Ｉｘを特定する（タスク特定メソッド（getTask()））。そして、タスク・インヴォーカー１０６は、前記端末１からの要求に応じて前記タスクのインスタンス１１２Ｉのメソッドを呼び出す際に、前記タスク特定メソッド（getTask()）を呼び出して当該タスクのインスタンス１１２Ｉを特定する。

このタスクマネージャー１０８の振る舞いは、２つのデザインパターンの組み合わせとなっている。すなわち、ダイナミックリンケージと、フライウェイトの性格を有する。タスク・インヴォーカー１０６は、端末１からタスクＩＤを引数として、タスクの開始要求や、完了要求や、格納要求や、計算要求を受信する。しかし、タスク・インヴォーカー１０６は、そのタスクＩＤのタスクTxxxのメソッドがメモリー１０２上のどこに存在するかの情報を有していない。
すなわち、クラスファイル等へのコンパイル時には、端末１からの要求をどのタスクTxxxから呼び出すのかは、タスク・インヴォーカー１０６には決定されていない。例えば、タスクTxxxのクラスが存在しないとしても、コンパイルのエラーとはならない。
タスク・インヴォーカー１０６が、端末１からタスクＩＤを引数とする要求を受信したときに、どのタスクTxxxのインスタンスのメソッドを呼び出すかを決定する。すなわち、コンパイル時ではなくて、実行時に決定する。

タスクマネージャー１０８は、タスクTxxxのインスタンスを管理する。各タスクTxxxでの表示制御処理１６や、条件確認処理２０や、計算処理１８の内容は異なる。しかし、タスク毎に各処理のメソッド名を変更すると、タスク・インヴォーカー１０６の構成が煩雑となる。このため、本実施例では、端末１とサーバー４Ａとの通信では、start(), done(), query(), confirm(), calculate, set()という６つのメソッド名のみを使用する。各個別タスク・クラス１１２Ｃｘは、この６つのメソッドを個々に実装する。
図２７及び図２９に示すように、端末１からは、この６つのメソッド名のみが使用される。一方、サーバー４Ａでは、図２２に示すように、クラス分けをしている。タスクTxxxは、それぞれ、query(), confirm(), calculate(), set()の４つのメソッドの実行にて、必要な他のクラスのメソッドを呼び出す。

タスクTxxxのインスタンスは、サーバー４Ａの稼働中、１つで良い。作業は各営業店の各担当者が平行して行うが、それぞれのタスクTxxxのインスタンスは１つで、多数の端末１からのアクセスに応答できる。なお、ＤＢアクセスに関するクラスは、アクセスに応じて、メモリー１０２の確保と、解放とが必要となる。タスクTxxxに関しては、サーバー４Ａの稼働中、それぞれ１つで良いため、タスクマネージャー１０８は、サーバー４Ａを起動時に、タスクＩＤとタスクTxxxのクラスファイル（クラスプログラム）が記録されたタスク定義ファイルを参照して、タスク・クラス１１０Ｃのインスタンスをメモリー１０２に生成し、そのアドレスへの参照（例えば、ポインタ）を保持する。このように、インスタンス（オブジェクト）を唯一に管理する点で、タスクマネージャー１０８はフライウェイト・パターンの実装例である。図２５に示すように、タスクマネージャー１０８は、タスクＩＤと、そのインスタンスへの参照とを管理するのである。

そして、タスクマネージャー１０８は、タスク特定メソッド（getTask()）を有する。タスク特定メソッドは、タスクＩＤを引数として呼び出されると、そのタスクTxxxのインスタンスへの参照（例えば、ポインタ）を返す。すなわち、タスク・インヴォーカー１０６は、端末１からの要求を受信する毎に、そのタスクＩＤを引数としてタスクマネージャー１０８のタスク特定メソッドを呼び出すと、そのタスクＩＤのタスクTxxxのインスタンスへの参照を得ることができる。このように、実際のインスタンスへの参照を実行時に定める点で、タスクマネージャー１０８はダイナミックリンケージ・パターンの実装例である。

図２４を参照すると、端末１から、タスクＩＤを引数とするコマンドを受信する。コマンドは、上記６つのメソッド名のいずれかである。タスク・インヴォーカー・インスタンス１０６Ｉは、まず、タスクデータライター・インスタンス１２０Ｉのタスクデータ構築メソッド（buildTaskData()）を呼び出して、端末１から送信されたデータをハッシュマップ型のデータ構造であるタスクデータｔｄに変換する（図２４，１．１）。
タスク・インヴォーカー・インスタンス１０６Ｉは、続いて、タスクマネージャー・インスタンス１０８Ｉのタスク特定メソッドを呼び出し、taskへの参照を得る（図２４，１．２）。
そして、タスク・インヴォーカー・インスタンス１０６Ｉは、そのtaskで示されるタスクに対して、端末１から送信されたデータを含むタスクデータｔｄを引数として、confirm(),set(),calculate(),query(),start(),done()のメソッドを呼び出す。
タスク特定メソッドで特定されたタスクのインスタンス１１２Ｉは、このコマンドを実行し、その結果をタスクデータｔｄに格納する。そして、タスクデータライター１２０のインスタンス１２０Ｉは、タスクデータｔｄを端末１で解析できるデータ形式（例えば、ＨＴＭＬや、ＸＭＬや、バイナリー形式）に変換する。タスク・インヴォーカー１０６のインスタンス１０６Ｉは、このデータを端末１に返す。

このように、タスクマネージャー１０８が、タスクTxxxのインスタンスを管理するため、タスク・インヴォーカー１０６は、コンパイル時に呼び出すべきタスクTxxxを特定する必要がない。仮に、極めて例外的なタスクTxxxを使用する際には、サーバー４Ａのプログラムファイル格納部１２２ではなく、外部の記録媒体にその例外的なタスクのクラスファイルを格納しておいても動作する。すなわち、タスクＩＤと、タスクのインスタンスとの関係は、実行時に定まる。このダイナミックリンケージを採用したことで、タスク・インヴォーカー１０６は、タスク毎に条件分岐するなどの処理が不要であり、６つのコマンドを受信した際に、タスクマネージャーにそのタスクのインスタンスのアドレスを問い合わせるだけでよい。また、この構成では、タスクの追加や、削除や、一方向の順序の入れ替えに際して、タスク定義ファイル等を書き直し、done()やendTask()のコードを修正するのみで、タスクフレームワークの全体へ影響することがない。このように、タスクマネージャー１０８を使用することで、タスクの独立性を確保することができる。

［タスクデータ］
図２２に示す例では、タスク・インヴォーカー１０６とタスクとは、タスクデータ・クラス１１５Ｃのインスタンス１１５Ｉを介して協調する。タスクデータｔｄは、図２６に示す例では、ハッシュマップとする。この場合、ハッシュマップでは二次元のデータを直接取り扱うことができないため、図２６（Ｂ）に示すように、ハッシュマップにさらにハッシュマップを集約するデータ構造を採用する。

図２６は、タスクデータｔｄの一例を示す説明図であり、図２６（Ａ）はタスクデータｔｄをハッシュマップで構成した例を示す図で、図２６（Ｂ）はハッシュマップと配列ｔｄａとを用いてテーブル情報をタスクデータｔｄに集約する例を示す図である。リレーショナルデータベースを使用したシステムでは、データベースへのアクセスが処理速度の低下の要因となる。データベースのアクセスを含めた全体的な処理速度の低下を防止するには、データベースからのデータの読み出しや、書き込みや、その回数が少ない方が良い。すなわち、少しのデータを頻繁に読み書きするよりは、多量のデータを少ない回数読み書きする方が、全体的な処理速度は高速である。本実施例では、データの読み出しと、書き込みは、タスクTxxxの全データを単位として行う。そして、図１８及び図１９に示すように、サーバー４Ａにて、各クラスの処理は、タスクTxxxを単位とした一群のデータ（一時変数ｔｄ）に対して行うようにすると、フレームワークの構成が簡易となり、端末１との通信に必要なデータ形式の変更を標準化することができる。本実施例では、このサーバー４Ａの一時変数ｔｄとなるデータ形式に、ハッシュマップを採用した。マップは、ＪＡＶＡ（登録商標）のデータ構造として用意されているコレクションの一種である。

図２６（Ａ）に示すように、タスクデータｔｄは、キーと値との組み合わせである。キーは、そのタスクデータｔｄ内で唯一のものでなければならない。タスクTxxxや、ＤＢアクセス１１８や、計算クラスの各メソッドは、タスクデータｔｄとして作業データ６ａを読み出し、計算や条件確認等を行った後、タスクデータｔｄにキーと値とを書き込むことで、タスク・インヴォーカー１０６に作業データ６ａを引き渡す。

図４０以下の具体的な画面例で示すように、銀行業務に関する実施例では、テーブル形式の表示が多い。マップでは、キーと値との組み合わせであるため、そのままでは、一時元のデータしか管理できない。この点、図２６（Ｂ）に示す例では、マップを入れ子にすることで、二次元のデータをタスクデータとして取り扱う。すなわち、元のタスクデータｔｄの値に配列型（array型）の値（例えば、配列ｔｄａへのポインタ）を格納し、符号ｔｄａで示すインデックスと、集約したマップへのポインタとを格納する配列ｔｄａを生成する。この配列ｔｄａに、複数のマップを集約することで、二次元のデータを格納する。例えば、配列ｔｄａのインデックスを行とし、各マップのキーを列とする行列をマップの集約として格納することができる。

銀行業務では、種々の条件下、詳細な計算処理１８をプログラミングしなければならないこともある。また、図２２に示すように、タスクTxxxから、計算確認処理を独立させ、この計算確認処理を、別の自動処理１４０から呼び出す構成も考えられる。この例では、計算確認クラスのプログラマーは、タスク処理や進捗制御とは無関係に、詳細な計算処理１８のみをコーディングできれば、タスクデータｔｄの集約や、タスクマネージャー１０８の働きなどとは無関係に、プログラミング作業を行うことができる。
このような課題に対して、与信明細や、各種の作業に関して、マップではなく、コレクションに変換するようにしても良い。すなわち、マップの集約は、画面でのテーブル構成に素直なデータ形式であるが、分類額の算出ではロジックが複雑であるため、単純なデータ構造に変換し、計算確認クラスを作成するようにしても良い。
この場合、図２６（Ｂ）に示すように、ハッシュマップの値にオブジェクト型の値を埋め込み、そのオブジェクトを、ＪＡＶＡ（登録商標）のデータ構造であるコレクションのセットとする。プログラム上の配列操作を可能とするようにしても良い。配列操作が可能となると、部門別にデータを管理するためプログラミングの行数を少なくすることができる。

［プロセス管理：コンディショナル・タスク］
また、作業分岐３４ａを行うために、コンディショナル・タスクを有するようにしても良い。コンディショナル・タスクは、クラス体系上は個別タスクである。コンディショナル・タスクのタスクの完了処理メソッド（done()）は、債務者の態様別に次タスクＩＤが定められている際には、当該条件に応じて、次の処理を行う。
まず、現タスクＩＤから予め定められた次タスクＩＤまでのタスクを使用しない際には、前記プログレスマネージャー１１４のタスクスキップメソッド（skipTasks()）を呼び出して、当該タスクスキップメソッド（skipTasks()）は、当該前記一方向の順序で前記現タスクＩＤの次のタスクＩＤから当該債務者の態様から特定した次タスクＩＤまでのタスクＩＤの進捗ステータスを省略に更新する。
一方、現タスクＩＤから次タスクＩＤまでの予め定められたタスクを自動計算する際には、前記プログレスマネージャー１１４のタスク完了メソッド（endTask()）呼び出して、当該タスク完了メソッド（endTask()）は、現タスクＩＤから自動計算の対象となる予め定められたタスクの進捗ステータスを作業済に更新する。

これにより、図４に示す作業分岐３４ａを実装しつつ、どのルートでの一方向であるかを進捗ステータスの利用により管理することができる。図実現することができる。例えば、図４（Ｃ）を参照すると、画面ＩＤ：３までの作業結果と基礎データ６ｂ（債務者の属性等）に応じて作業分岐条件が定められている際に、画面ＩＤ：４を使用せずに画面ＩＤ：５に進む場合、タスクスキップメソッド（skipTasks()）により画面ＩＤ：４の進捗ステータスを省略として、続いて、画面：５の進捗ステータスを作業中にする。また、図５８に示す自己査定・画面スキップ確認画面での画面スキップについては、当該画面スキップ確認画面のタスクを作業済とし、さらに、優良与信確認画面のタスクから管理・回収方針画面の一つ前のタスクまでを作業済とする。

［クラス体系と銀行業務用プログラム１２４］
ここで、銀行業務用プログラム１２４の構成をクラス体系に応じて再度説明する。

銀行業務用プログラム１２４は、前記ランタイムシステム１００上で実行することで、作業者による作業を支援する。この銀行業務用プログラム１２４は、ランタイムシステム１００上で実行されるメソッドと、当該メソッドによって管理されるデータとを有するオブジェクトであるインスタンスを生成するためのひな形であるクラスプログラム（クラスファイル）を有している。

この銀行業務用プログラム１２４は、図２２に示すように、クラスファイルとして、下記の名称のクラスファイルを有する。

・タスク・インヴォーカー・クラス１０６Ｃ
タスク・インヴォーカー・クラス１０６Ｃは、前記端末１との通信を制御して、端末１からの要求に応答するメソッドとデータとのひな形を有する。タスク・インヴォーカー・クラス１０６Ｃは、タスクマネージャー・クラス１０８Ｃを使うことで、実行時にタスクＩＤに対応するインスタンスを特定する。またタスク・インヴォーカー・クラス１０６Ｃは、タスク・インタフェース・クラス１３４Ｃを使うことで、端末１との通信内容を単純化することができる。

・個別タスク・クラス１１２Ｃ
個別タスク・クラス１１２Ｃｘは、前記作業の個別作業毎に、当該各個別作業での前記作業データ６ａに対する個々の情報処理であるメソッドとデータとのひな形を有する。図２２に示す例では、符号１１２Ｃａで示すタスク・クラス１と、符号１１２Ｃｂで示すタスク２と、符号１１２Ｃｎで示すタスクｎとを記載したが、実施例によっては、図３９に示す多数のタスクTxxxを有する。それぞれの個別タスク・クラス１１２Ｃｘは、ＤＢアクセス・クラス１１８Ｃのサブクラスを使用して銀行業務データベース１２１に格納されたデータを読み出し、また、端末１から送信された入力データ６ｃを銀行業務データベース１２１に格納する。
また、タスク・クラス群１１２Ｃｘの計算メソッド（calculate()）や、条件確認メソッド（confirm()）では、そのメソッド中に直接処理内容をコーディングせず、確認計算クラス１４２Ｃを作成し、その確認計算クラス１４２Ｃのメソッドで複数の詳細なメソッドを持たせる構成としてもよい。この場合、タスク・クラス群１１２Ｃｘでは、対応する確認計算クラス１４２Ｃｘの各メソッドを呼び出すことで、計算メソッド等を実行する。

・タスクマネージャー・クラス１０８Ｃ
タスクマネージャー・クラス１０８Ｃは、タスク・インヴォーカー・インスタンス１０６Ｉからのタスクの特定のための呼び出しに応じて、当該タスクＩＤから前記タスクのインスタンス１１２Ｉｘへの参照を返すタスク特定メソッド（getTask()）と、データとのひな形を有する。タスクマネージャー・クラス１０８Ｃの振る舞いについては、図２４及び図２５を参照して上述した。

・ＤＢアクセス・クラス１１８Ｃ
ＤＢアクセス・クラス１１８Ｃは、各タスク・インスタンス１１２Ｉｘからの呼び出しに応じて、前記銀行業務データベース１２１に対する前記作業データ６ａの読み出し及び書き込みを制御するメソッドとデータとのひな形を有する。ＤＢアクセス・クラス１３６（セレクト）Ｃｘは、表示制御メソッド（query()）等の、ＤＢアクセス・クラス１３８（アップデート）Ｃｘは格納メソッド（set()）等の要件定義に応じて、対応するデータベースの検索式であるＳＱＬ文を有する。また、このＳＱＬ文は、ハードコードするのではなく、外部のテーブルに格納するようにしても良い。

・プログレスマネージャー・クラス１１４Ｃ
プログレスマネージャー・クラス１１４Ｃは、作業の起票及び承認を制御し、前記作業者による前記作業の進捗に応じて前記進捗ステータステーブル８ａに進捗ステータスを記録するメソッドとデータとのひな形を有する。図２３に示す例では、プログレスマネージャー・クラス１１４Ｃは、進捗ステータステーブル・クラス１１６Ｃのサブクラスであるため、プログレスマネージャー・クラス１１４Ｃのメソッドの呼び出しでは、進捗ステータステーブル・クラス１１６Ｃのメソッドを呼び出すことができる。

前記プログレスマネージャー・クラス１１４Ｃ又は進捗ステータステーブル・クラス１１６Ｃは、進捗制御部３０の諸機能を実装するため、図２３に示すように、下記のメソッドを有する。
・初期化メソッド（startForm()）
初期化メソッド（startForm()）は、前記作業を唯一に識別する作業通番を有する作業が起票される際に、予め定められた一方向の順序で開始タスクから終了タスクまでのタスクＩＤの列と、各タスクＩＤの進捗ステータスである未着手とを前記進捗ステータステーブル８ａに格納する。初期化メソッド（startForm()）は、例えば、タスク定義ファイルを参照して、進捗ステータステーブル８ａを生成し、全ての進捗ステータステーブル８ａに未着手を格納する。この初期化メソッド（startForm()）は、図７に示す起票時処理３６を実行する。

・タスク開始メソッド（startTask()）
タスク開始メソッド（startTask()）は、開始制御処理（start()）に際して、当該開始するタスクＩＤの進捗ステータスを作業中に更新し、当該タスクＩＤより終了タスク側の進捗ステータスに作業済がある際には、当該作業済を作業中に更新する（一方向制御処理４２）。タスク開始メソッドは、図７に示すタスク開始処理３８の具体的処理内容である。

・タスク完了メソッド（endTask()）
タスク完了メソッド（endTask()）は、完了制御処理（done()）に際して、当該完了するタスクＩＤの進捗ステータスを作業済に更新する。タスク完了メソッドは、図７に示すタスク完了処理４０の具体的処理内容である。タイムスタンプ処理４４は、このタスク完了メソッド（endTask()）で実装すると良い。作業分岐処理４６や、画面スキップ処理は、それぞれのタスクの完了時の処理として定義できるため、すなわち、図４（Ａ）に示す連結リスト型で次画面（次タスク）を特定するため、タスクの完了制御処理（done()）にて実装すると良い。この例では、作業分岐処理４６がない完了処理（進捗ステータステーブルに従い、省略の格納等を行わない）について、図２２に示すタスククラス１１０Ｃに実装すると、作業分岐３４ａがある個別タスク・クラス１１２Ｃｘでのみ完了制御処理done()をオーバーライドすれば良い。

すなわち、オブジェクト指向の継承関係では、サブクラスのメソッドが呼ばれた際に、サブクラスにメソッドが定義されていればそのメソッドを実行し、この例では、作業分岐処理４６を含むdone()を実行し、一方、サブクラスにメソッドの定義がなければ、スーパークラスのメソッドを実行する。この例では、通常の進捗ステータスの更新のみの処理を実行する。すると、通常の処理については１つのメソッドのみの記載で、全ての個別タスク・クラス１１２Ｃｘにコーディングしたのと同様の振る舞いとなり、一方、作業分岐処理４６のある例外的な個別タスク・クラス１１２Ｃｘについてのみdone()を書き改めれば良い。

・次タスク特定メソッド（getNextTask()）
次タスク特定メソッド（getNextTask()）は、進捗ステータステーブル８ａを参照して、現タスクＩＤよりも終了画面側の個別タスク群１１２ｘで、進捗ステータスが未着手又は作業中のタスクのＩＤを特定して当該次タスクＩＤを端末１に返す。この次タスク特定メソッド（getNextTask()）は、図７に示す次タスク特定処理３４の実装である。

・前タスク特定メソッド（getPrevTask()）
前タスク特定メソッド（getPrevTask()）は、進捗ステータステーブル８ａを参照して、現タスクよりも開始画面側で最も近い作業済のタスクＩＤを特定して当該前タスクＩＤを端末１に返す。

・タスクスキップメソッド（skipTasks()）
タスクスキップメソッド（skipTasks()）は、一方向の順序で前記現タスクＩＤの次のタスクＩＤから当該債務者の態様から特定した次タスクＩＤまでのタスクＩＤの進捗ステータスを省略に更新する。

前記タスクマネージャー１０８のインスタンス１０８Ｉは、上述したように、前記サーバーの起動時に、前記個別タスク・クラス１１２Ｃｘのインスタンス１１２Ｉｘを前記ランタイムシステム１００にロードしておき、当該ロードした各タスク・インスタンス１１２Ｉへの参照（例えば、ポインタ）をタスクＩＤ毎に保持する。

前記複数の個別タスク・クラス１１２Ｃｘは、それぞれ、前記メソッドとして、開始制御メソッド（start()）と、表示制御メソッド（query()）と、計算メソッド（calculate)と、条件確認メソッド（confirm)と、格納メソッド（set）と、完了処理メソッド（done)とを必ず実装する。「必ず実装する」というのは、ＪＡＶＡ（登録商標）であれば、タスク・インタフェース・クラス１３４Ｃに、この６つのメソッドが定義されており、全ての個別タスク・クラス１１２Ｃｘは、このタスク・インタフェース・クラス１３４Ｃをインプリメントしているか、または同様の状態となっていることを意味する。すなわち、タスク・インヴォーカー１０６等は、必ずタスクがこれらのメソッドを有していることを前提として処理を実装し、実行することができる。

図２３に示すように、タスククラス１１０Ｃ及び個別タスク群１１２ｘは、次のメソッドを備える。
・開始制御メソッド（start()）
開始制御メソッド（start()）は、タスク開始処理３８，Ｃ２４の一部であり、当該個別タスク群１１２ｘの開始を制御する。進捗ステータスの更新処理は、図２３に示す例では、進捗ステータステーブル・クラス１１６Ｃのタスク開始メソッドstartTask()が処理する。

・表示制御メソッド（query()）
表示制御メソッド（query()）は、当該個別タスク群１１２ｘの基礎データ６ｂを前記タスクＩＤをキーとして前記銀行業務データベース１２１から読み出す制御をし、当該基礎データ６ｂを当該タスクＩＤに関連する画面ＩＤの前記画面定義情報７ａの指定に応じて前記端末１の画面に表示する。表示制御メソッドは、表示制御処理１６，Ｃ２に対応する。

・計算メソッド（calculate()）
計算メソッド（calculate()）は、前記基礎データ６ｂ及び前記画面にて入力される入力データ６ｃから前記導出データ６ｄを算出する。計算メソッドは、計算処理１８，Ｃ６に対応する。図２２に示すように確認計算クラス１４２Ｃを別に作成する例では、計算メソッドは当該確認計算クラス１４２Ｃのメソッドを呼び出すメソッドである。

・条件確認メソッド（confirm()）
条件確認メソッド（confirm()）は、当該タスクの作業データ６ａが予め定められた条件を満たしているか否かを確認する。条件確認メソッドは、条件確認処理２０，Ｃ１２に対応する。

・格納メソッド（set()）
格納メソッド（set()）は、当該個別タスク群１１２ｘのタスクデータｔｄ（作業データ６ａ）を前記銀行業務データベース１２１に格納する制御をする。格納メソッドは、格納処理２２，Ｃ１３に対応する。図２２に示すように、ＤＢアクセスクラス１３６Ｃ，１３８Ｃを使用できる際には、格納メソッドは、ＤＢアクセスクラス１３６Ｃ，１３８Ｃのメソッドを使用してタスクデータｔｄを銀行業務データベースに格納させる。

・完了処理メソッド（done()）
完了処理メソッド（done()）は、当該個別タスク群１１２ｘの完了を制御する。完了処理メソッドは、タスク完了処理４０，Ｃ２０の一部である。進捗ステータスの更新は、図２３に示す例では、進捗ステータステーブル・クラス１１６Ｃのタスク完了メソッドendTask()が処理する。

［各部と手順（プログラムコード)］
サーバー４Ａのコンピュータを、図７、図１６等に示すタスク処理部１０及び進捗制御部３０等の各部として機能させるには、コンピュータに、各部の処理に対応した手順を実行させると良い。
例えば、タスク処理部１０が、「前記タスク毎に前記画面定義情報７ａに従って前記作業データ６ａを前記端末１に表示制御すると共に当該端末１の前記画面要素への操作により入力され又は導出する前記作業データ６ａを前記作業データ格納部６に格納する」と定義される際には、「前記タスク毎に前記画面定義情報７ａに従って前記作業データ６ａを前記端末１に表示制御すると共に当該端末１の前記画面要素への操作により入力され又は導出する前記作業データ６ａを前記作業データ格納部６に格納する手順」をコンピュータに実行させることで、コンピュータがタスク処理部１０として機能する。
本実施例では、プログラムは図２３に示すメソッドを有し、図２２に示す関係を有する図２１に示すクラス群１０４のクラスファイル群（プログラムの中間コード）である。このため、コンピュータをタスク処理部１０として動作させる手順は、対応するクラスファイルである。

例えば、実施形態に対応する銀行業務システム用プログラムは、タスク処理手順（図１、図７等に示すタスク処理部１０に対応）と、進捗制御手順（進捗制御部３０に対応）とを備え、進捗制御手順が、戻りタスク特定処理手順（戻りタスク特定処理３２に対応，Ｃ２３）と、次タスク特定処理手順（次タスク特定処理３４に対応，Ｃ２３，getNextTask()）と、を備えると良い。
同様に、例えば、実施例１に対応する銀行業務システム用プログラムは、起票時処理手順（図７等に示す起票時処理３６に対応，（startForm()）と、タスク開始処理手順（タスク開始処理３８に対応，Ｃ２４, S3x, start ()）と、タスク完了処理手順（タスク完了処理４０に対応，Ｃ２０, S4x, done()）と、一方向制御処理手順（一方向制御処理４２に対応，startTask()）とを備えると良い。他の実施例についても同様である。

［シーケンス図： 現タクス完了から次タスク開始］
図２７から図３０は、次へボタンＢ１の操作や、戻るボタン等の操作に応答するシーケンス図である。このシーケンス図は、実施形態及び実施例の銀行業務処理方法についての詳細な開示である。

次に、図２７のシーケンス図を参照して、端末１にて次へボタンＢ１が操作され、現タスクＩＤのタスクを完了させ、次タスクＩＤを特定し、次タスクＩＤの画面を表示するまでの振る舞いを説明する。この図２７では、特に、次タスク特定工程（getNextTask()）と、一方向制御処理工程（startTask()）とを開示する。
図２７に示す例では、端末１の仮想マシンは、次へボタンの操作を受信すると、まずconfirm()をサーバー４Ａに送信して、その応答を受信すると、図２７の図中上から下への順序で、次々とコマンドを送信する。

図２７に示す例では、タスク・インヴォーカー１０６のインスタンス１０６Ｉ（以下、「タスク・インヴォーカー・インスタンス１０６Ｉ」という）は、条件確認要求（confirm)を受信すると（図２７，Ｓ１０）、タスクマネージャーのインスタンス１０８Ｉ（以下、「タスク・マネージャー・インスタンス１０８Ｉ」という）のタスク特定処理（getTask()）を呼び出し、当該タスクのインスタンスへの参照を得る（図２７，Ｓ１１）。ここでは、タスクＩＤ： T0001のインスタンス１１２Ｉａとする。タスク・インヴォーカー・インスタンス１０６Ｉは、続けて、このタスク・インスタンス１１２Ｉａの条件確認メソッド（confirm()）を呼び出す（図２７，Ｓ１２）。
このインスタンス１１２Ｉａの条件確認メソッドは、図４０以下の各画面例では、金額の比較をし、ある条件下で各種のコメントの入力があるか否か等の予め定められた条件を確認する。すなわち、条件確認処理２０を実行する。条件確認に成功すると、成功を端末１に戻し、不成功であれば、エラーメッセージを端末１に表示するための処理を呼び出す。

端末１は、条件確認に成功したとの応答をサーバー４Ａから受信すると（図２７，Ｓ１３）、次に、格納要求（set)を送信する。タスク・インヴォーカー・インスタンス１０６Ｉは、タスクＩＤを使用して、タスク・マネージャー・インスタンス１０８Ｉから当該タスクＩＤのタスクのインスタンスの参照を得る。続いて、タスク・インヴォーカー・インスタンス１０６Ｉは、そのタスクの計算処理１８（calculate()）を呼び出し、さらに、格納処理２２（set()）を呼び出す（図２７，Ｓ１４）。タスク１の計算処理１８や、格納処理２２では、ＤＢアクセス・クラス１１８Ｃのインスタンス１１８Ｉのメソッドや、確認計算クラスのメソッド等を呼び出して、計算及び格納を完了させる。格納に成功すると、タスク・インヴォーカー・インスタンス１０６Ｉは、端末１に応答を返す。

端末１は、格納に成功すると、このタスクの完了処理（done()）を要求する。タスクインヴォーカー・インスタンス１０６Ｉは、端末１から現タスクＩＤを引数とする完了要求を受信した際に（図２７，Ｓ１５）、当該現タスクＩＤからタスクマネージャ・インスタンス１０８Ｉの前記タスク特定メソッド（getTask()）によりタスクのインスタンスへの参照を得る。そして、この参照先の当該タスクのインスタンスの完了処理メソッド（done()）を呼び出す（図２７，Ｓ１６）。当該完了処理メソッド（done()）は、プログレスマネージャー１１４のインスタンス１１４Ｉのタスク完了処理４０（endTask()）を呼び出す（図２７，Ｓ１７）。このタスク完了処理４０（endTask()）は、当該現タスクＩＤの進捗ステータスを作業済に更新する。

画面スキップを行う際には、作業済とするタスクが複数となる。この場合、ステップＳ１５の完了処理メソッド（done()）にて、タスク完了処理４０（endTask()）が複数呼び出すようにしても良いし、タスク完了処理４０（endTask()）が作業済とする開始タスクと終了タスクとを引数とするようにしても良い。いずれにしても、画面スキップを行う際には、ステップＳ１７Ａにて画面スキップ確認画面のタスクの完了処理メソッド（done()）に予め定められたタスクについて、タスク完了処理４０（endTask()）を実行する。

一方、Ｓ１６で示す前記タスクのインスタンスの完了処理メソッド（done()）の処理では、債務者の態様別に次タスクＩＤが定められている際には、省略するタスクについて、前記プログレスマネージャー１１４のインスタンス１１４Ｉのタスクスキップメソッド（skipTasks()）を呼び出す（図２７，Ｓ１６）。当該タスクスキップメソッド（skipTasks()）は、当該前記一方向の順序で前記現タスクＩＤの次のタスクＩＤから当該債務者の態様から特定した次タスクＩＤまでのタスクＩＤの進捗ステータスを省略に更新する（Ｓ１７Ｂ）。これにより、作用分岐処理がされた際に、その分岐の結果を進捗ステータステーブル８ａに保存する。例えば、上記図１１に示す進捗ステータステーブル８ａの各進捗ステータスの状態は、債務者が個人要注意先である際に、作業が完了した状態の進捗ステータスである。図１１に示すように、債務者が個人である際には、実態検討（法人のみ）のタスクは、タスクスキップメソッドにより、省略が格納されている。

端末１は、タスク完了要求が成功すると、続いて、次タスクＩＤ特定要求（query（TAA10:TaskID)）をサーバー４Ａに送信する。タスク・インヴォーカー・インスタンス１０６Ｉは、前記端末１から現タスクＩＤを引数とする次タスクＩＤ特定要求（query（TAA10:TaskID)）を前記端末１から受信した際に（図２７，Ｓ１８）、前記プログレスマネージャーのインスタンス１１４Ｉを取得して、前記次タスク特定メソッド（getNextTask()）を呼び出す（図２７，Ｓ１９）。
なお、本実施例では、この次タスクＩＤ特定メソッドを有するクラスを、タスクの一種としている。このクラスのタスクＩＤは、TAA10である。図２７に示す例では、タスク・インヴォーカー・インスタンス１０６Ｉは、まず、TAA10のタスクＩＤのインスタンスの参照をタスク・マネージャー・インスタンス１０８Ｉから得る。そして、このTAA10のインスタンスの次タスク特定メソッド（getNextTask()）を呼び出す。次タスク特定メソッドは、当該現タスクＩＤから、進捗ステータステーブル８ａを参照して、当該次タスクＩＤ特定し、当該次タスクＩＤを端末１に返す。

端末１は、この次タスクＩＤ： T0002を引数として、タスク開始要求（start)をサーバー４Ａに送信する。タスク・インヴォーカー・インスタンス１０６Ｉは、タスク開始要求を受信すると（図２７，Ｓ２１）、タスク・マネージャー・インスタンス１０８Ｉを使用してタスクのインスタンスを特定する。図２７に示す例では、タスクＩＤ：T0002のタスク２が特定される。
タスク・インヴォーカー・インスタンス１０６Ｉは、当該特定したタスク２のインスタンス１１２Ｉｂの開始制御メソッド（start()）を呼び出す（図２７，Ｓ２２）。当該開始制御メソッド（start()）は、前記プログレスマネージャー１１４のインスタンス１１４Ｉのタスク開始メソッド（startTask()）を呼び出す（図２７，Ｓ２３）。この当該タスク開始メソッド（startTask()）は、当該次タスクＩＤの進捗ステータスを作業中に更新する。タスク開始メソッド（startTask()）は、当該次タスクＩＤよりも終了画面側のタスクの進捗ステータスに作業済があれば作業中に更新する（一方向制御処理４２）。

端末１は、続いて、表示制御要求（query)をサーバー４Ａに送信する（ステップＳ２４）。タスク・インヴォーカー・インスタンス１０６Ｉは、タスク２のインスタンス１１２Ｉｂへの参照を得て、その表示制御メソッド（query()）を呼び出す。この表示制御メソッドは、ＤＢアクセス１１８のメソッド等を使用して、銀行業務データベース１２１から作業データ６ａを読み出して、端末１に送信する。

［シーケンス図： コンディショナル・タスクによる作業分岐］
図２８に示す例では、コンディショナル・タスクにより、作業分岐３４ａを行う。現タスクをタスク３、作業分岐３４ａにより選択される２つのタスクをタスク３Ａ，３Ｂとする。タスク３が完了すると、タスク３Ａ又は３Ｂの一方に進む。
この例では、図２７に示す例と同様に、タスク・インヴォーカー・インスタンス１０６Ｉは、前記端末１から現タスクＩＤを引数とする次タスクＩＤ特定要求（query（TAA10:TaskID)）を前記端末１から受信した際に、次タスク特定メソッド（getNextTask()）を呼び出す。コンディショナル・タスクでは、次タスク特定メソッドは、委譲元となるタスク３のタスクＩＤを返す。タスク３には、作業分岐先特定メソッドselectDelegate()が定義されており、作業分岐条件に従ってタスク・インヴォーカー・インスタンス１０６Ｉからのメソッドの実行を委譲するタスクを特定する。

端末１は、次へボタンＢ１が操作されると、タスク開始要求start()の処理（Ｓ２１，Ｓ２２及びＳ２３）をした後、表示制御要求（query()）の処理を行う（Ｓ２４）。コンディショナル・タスクでは、タスク・インヴォーカー・インスタンス１０６Ｉは、まず、具体的な処理内容が実装されていないコンディショナル・タスクであるタスク３の表示制御要求（query()）を呼び出す。コンディショナル・タスクである委譲元のタスク３は、作業分岐先特定メソッド（selectDelegate()）を実行して、条件判断を行う。条件１に該当すると、タスク３Ａに当該表示制御要求（query()）の処理を委譲し、具体的処理内容が実装されたタスク３Ａは、この表示制御要求（query()）を実行する（Ｓ２７）。一方、条件２の場合には、図中二点鎖線で示すように、タスク３Ｂに当該表示制御要求（query()）の処理を委譲する。タスク３Ｂは、この表示制御要求（query()）を処理する（Ｓ２８）。これにより、作業分岐３４ａを簡易に実現することができる。

［シーケンス図： 戻る／ジャンプして戻る］
図２９は、戻るボタンＢ３や、ジャンプして戻るボタンＢ２の操作に応じたサーバー４Ａの振る舞いを示すシーケンス図である。このシーケンス図では、特に、一方向制御処理工程（startTask()）を開示する。図２９では、戻るボタンＢ３の操作の際に、二点鎖線で示すＳ３０，Ｓ３１及びＳ３２の処理を行う。ジャンプして戻る際には、戻った先のタスクＩＤは端末１側にて取得できるため、タスクＩＤを特定するサーバー４Ａ側の処理は不要である。戻る処理の際には、作業分岐３４ａでの省略等との関係から、サーバー４Ａ側で戻り先のタスクＩＤを特定している。

戻るボタンＢ３又はジャンプして戻るボタンＢ２が操作されると、まず、表示中の現画面の中断制御６２を行う。このため、端末１は、格納要求（set）をサーバー４Ａに送信する。タスク・インヴォーカー・インスタンス１０６Ｉは、格納要求を受信すると（図２９，Ｓ１３)、条件確認処理２０を行わず、計算メソッドを呼び出して実行し（図２９，Ｓ１４ａ）、入力データ６ｃを銀行業務データベース１２１に格納する。

戻るボタンＢ３の操作の際には、端末１では、続いて、戻り先タスクＩＤ特定要求をサーバー４Ａに送信する。この要求を受信したタスク・インヴォーカー・インスタンス１０６Ｉは、タスクＩＤ：TAA11の照会要求query()を呼び出し（図２９，Ｓ３１）、続いて、プログレスマネージャー１１４の戻り先タスクＩＤ特定メソッド（getPrevTask()）を呼び出す。このメソッドは、進捗ステータスを参照して、現タスクＩＤよりも開始画面側のタスクのうち、進捗ステータスが作業済であるタスクで、現タスクＩＤに最も近いタスクＩＤを戻り先のタスクＩＤとして特定する。すなわち、進捗ステータスが作業済であるタスクＩＤのうち、最も終了画面側に近いタスクＩＤを、戻り先のタスクＩＤとして特定する。

戻るボタンＢ３の操作の際には、続いて、タスクの開始制御メソッドstart()を実行し（図２９，Ｓ２１，Ｓ２２ａ，Ｓ２３ａ）、さらに、表示制御メソッドを実行する（図２９，Ｓ２４，Ｓ２５）。

一方、タスク・インヴォーカー・インスタンス１０６Ｉは、前記端末１から戻り先のタスクＩＤを引数としてジャンプして戻る要求を受信した際に（図２９，Ｓ１３）、上記格納メソッドを実行し（図２９，Ｓ１３，Ｓ１４）、続いて、タスク・マネージャー・インスタンス１０８Ｉを使用して当該戻り先のタスクＩＤのタスクのインスタンスを特定する。そして、当該タスクのインスタンスの開始制御メソッド（start()）を呼び出す（図２９，Ｓ２１）。この開始制御メソッド（start()）は、前記プログレスマネージャー１１４のインスタンス１１４Ｉのタスク開始メソッド（startTask()）を呼び出す（Ｓ２３ａ）。

本実施例では、特に、このタスク開始メソッド（startTask()）は、当該タスクＩＤより終了タスク側の作業済の進捗ステータスを作業中に更新する。省略は、未着手に更新すると良い。本実施例では、この当該タスクＩＤより終了タスク側の進捗ステータスを更新することで、ジャンプして戻る処理の後も、一方向制御を厳格に実行する。

［シーケンス図： ＤＢアクセス・クラス］
図３０は、個別タスク群１１２ｘと、確認計算タスク群１４２Ｃｘと、ＤＢアクセス・クラス１１８Ｃとの関係を示すシーケンス図である。例えば、端末１から表示制御要求（query)を受信すると、タスク１のインスタンス１１２Ｉａは、ＤＢアクセス１のセレクト１のインスタンス１３８Ｉａを生成する。すなわち、このクラスのインスタンスをメモリー１０２に確保する（図３０，Ｓ４０）。そして、このインスタンス１３８Ｉａは、ＳＱＬ文を銀行業務データベース１２１に発行するなどし、端末１に表示する作業データ６ａを読み出し、一時変数であるタスクデータｔｄに格納する。タスク・インヴォーカー・インスタンス１０６Ｉは、このタスクデータｔｄを端末１で解釈できるデータ形式に変更させ、端末１に送信する。

また、条件確認メソッドや、格納メソッドを受信すると（図３０，Ｓ１０，Ｓ１３)、タスク・インヴォーカー・インスタンス１０６Ｉは、確認計算タスクや、ＤＢアクセス１のアップデート１のインスタンスを生成させ、そのインスタンスのメソッドを用いて条件確認処理２０（図３０，Ｓ４１)や計算処理１８（図３０，Ｓ４２）や、格納処理２２（図３０、Ｓ４３）を実行する。

［シーケンス図： まとめ］
・次タスク特定要求
次に、次タスクＩＤ特定要求等を端末１から受信した際のサーバー４Ａの動作例を説明する。
前記タスク・インヴォーカー・インスタンス１０６Ｉは、前記端末１から現タスクＩＤを引数とする次タスクＩＤ特定要求（TAA10: query()）を前記端末１から受信した際に（図２７，Ｓ１８）、前記プログレスマネージャー１１４の次タスク特定メソッド（getNextTask()）を呼び出す（図２７，Ｓ１９）。この次タスク特定メソッドは、進捗ステータステーブルを参照して、現タスクＩＤよりも終了画面側の個別タスク群１１２ｘで、進捗ステータスが未着手又は作業中のタスクのＩＤを特定して当該次タスクＩＤを端末１に返す（図２７，Ｓ２０）。

・タスク開始要求
タスク・インヴォーカー・インスタンス１０６Ｉは、前記端末１から次タスクＩＤを引数とするタスク開始要求を受信した際に（図２７，Ｓ２１）、当該タスク開始要求の次タスクＩＤからタスク２を特定し、当該特定したタスク２・インスタンス１１２Ｉｂの開始制御メソッド（start()）を呼び出す（図２７，Ｓ２２）。この開始制御メソッド（start()）は、前記プログレスマネージャー・インスタンス１１４Ｉのタスク開始メソッド（startTask()）を呼び出す（図２７，Ｓ２３）。ランタイムシステム１００は、プログレスマネージャー・インスタンス１１４Ｉにタスク開始メソッドが存在しないため、スーパークラスである進捗ステータステーブル・クラス１１６Ｃのメソッドを探索し、このタスク開始メソッドを実行する。タスク開始メソッド（startTask()）は、当該次タスクＩＤの進捗ステータスを作業中に更新する。

・ジャンプして戻る要求
タスク・インヴォーカー・インスタンス１０６Ｉは、ジャンプして戻る要求を受信した際には（図２９，Ｓ２１）、当該戻り先のタスクＩＤからタスクを特定する。続いて、当該タスク１・インスタンス１１２Ｉａの開始制御メソッド（start()）を呼び出す（図２９，Ｓ２２ａ）。この当該開始制御メソッド（start()）は、前記プログレスマネージャー１１４のタスク開始メソッド（startTask()）を呼び出す（図２９，Ｓ２３ａ）。進捗ステータステーブル・インスタンス１１６Ｉのタスク開始メソッド（startTask()）は、当該タスクＩＤより終了タスク側の作業済の進捗ステータスを作業中に更新する。

・タスク処理
タスク・インヴォーカー・インスタンス１０６Ｉは、前記端末１から表示制御要求、計算要求、条件確認要求又は格納要求を受信した際に、当該現タスクＩＤからタスクを特定して、当該タスクの表示制御メソッド（query()）、計算メソッド（calculate()）、条件確認メソッド（confirm()）又は格納メソッド（set()）を呼び出す。各メソッドは、当該タスク毎に定義された各処理を実行する。

・完了要求
タスク・インヴォーカー・インスタンス１０６Ｉは、前記端末１から現タスクＩＤを引数とする完了要求を受信した際には、当該現タスクＩＤからタスクを特定して、当該タスクの完了処理メソッド（done()）を呼び出す（図２７，Ｓ１５）。この完了処理メソッド（done()）は、前記プログレスマネージャー１１４のタスク完了処理４０（endTask()）を呼び出す（図２７，Ｓ１７Ａ）。進捗ステータステーブル・インスタンスのタスク完了処理４０（endTask()）は、当該現タスクＩＤの進捗ステータスを作業済に更新する。

また、前記タスクの完了処理メソッド（done()）は、債務者の態様別に次タスクＩＤが定められている際には、すなわち、作業分岐３４ａを実行する際には、前記プログレスマネージャー１１４のタスクスキップメソッド（skipTasks()）を呼び出す（図２７，Ｓ１７Ｂ）。当該タスクスキップメソッド（skipTasks()）は、当該前記一方向の順序で前記現タスクＩＤの次のタスクＩＤから当該債務者の態様から特定した次タスクＩＤまでのタスクＩＤの進捗ステータスを省略に更新する。

このように、本実施例では、タスクの開始と、完了とに応じて、進捗ステータスを更新することで、一方向制御を実現する。そして、個々のタスク処理は、計算メソッド、条件確認メソッド、格納メソッドによって実行する。本実施例では、多数のタスクがあり、多数の画面があるが、このメソッドの存在（インタフェースの実装）は、全てのタスクに共通する。そして、端末１との通信はタスク・インヴォーカー・クラス１０６Ｃの責任範囲であり、個々のメソッドの役割はタスク・インタフェース・クラス１３４Ｃに定義されているため、タスクの開発作業では、端末１との通信や、他のタスクとの関係の詳細を検討せずに、個々のタスクに関して独立して、プログラムのコーディングを行うことができる。従って、タスクフレームワークは、開発に要する負荷を軽減する。また、タスク間の依存関係を限りなく小さくしたため、タスク間に別のタスクを追加したり、修正したりする際に、そのプログラムの修正の影響が及ぶ範囲を極小化することができる。従って、保守が容易で、修正に必要な開発期間を短くすることができる。すなわち、タスクフレームワークにより、一方向制御を簡単に実装できるため、タスクの開発に際しては、実際のビジネスロジックのみをコーディングすればよい。そして、その修正は、タスクフレームワーク全体とは無関係に行うことができる。

＜実施例２： トランザクション管理＞
次に、本実施例でのトランザクション管理について開示する。この例では、作業通番単位の作業トランザクションと、タスク単位の個別トランザクションとのＡＣＩＤ特性を調整することで、一方向制御下での必要なトランザクション管理を行う。
再度図１６を参照すると、コンピュータシステム４は、トランザクション管理部５０と、作業ステータス格納部９とを備えている。

作業ステータス格納部９は、前記作業を識別する作業通番を単位として、当該作業通番で使用する作業データ６ａの全体に対して、待機中、実行中及び決裁済の作業ステータスを特定した作業ステータステーブル９ａを格納する。作業ステータステーブル９ａは、例えば図１４に示すテーブルである。

トランザクション管理部５０は、前記作業通番で使用する作業データ６ａの全体に対する処理を作業トランザクションとして管理すると共に、前記タスクＩＤで使用するタスクデータｔｄへの処理を個別トランザクションとして管理する。そして、このトランザクション管理部５０は、全体排他制御５２と、全体一貫性制御５４と、個別原子性制御５６と、個別隔離性制御５８と、個別永続性制御６０と、中断制御６２とを備えている。

全体排他制御５２は、作業通番の作業ステータスが実行中である場合には、当該作業通番の作業開始を禁止する。一方、全体排他制御５２は、当該作業ステータスが待機中である場合には、当該待機中を実行中に変更して前記次タスク特定処理３４（Ｃ２３，getNextTask()）に当該作業通番を引き渡して作業開始を許可する。全体排他制御５２は、これにより、当該作業通番を単位とした前記作業トランザクションの実行を唯一に排他制御して、当該作業トランザクションに隔離性（独立性）を与える。すなわち、作業ステータスを利用して、同一の作業通番の作業に対して複数の作業者が同時にアクセスすることを禁止する。

全体一貫性制御５４は、前記作業トランザクションの決裁となる前記タスクの前記タスク完了処理４０（ C20, S4x)の後に、当該作業トランザクションの作業ステータスを実行中から決裁済に変更することで、当該作業トランザクションに一貫性を与える。個々のタスクの完了時ではなく、複数のタスクからなる銀行業務処理を一方向制御して当該作業が決裁された際に、１つのトランザクションの完了として一貫性を与え、この決裁された作業トランザクションの作業データ６ａに一貫性があるとする。

個別原子性制御５６は、前記タスク毎の進捗ステータスを管理させることで前記個別トランザクションに原子性を与える。個々のタスクへのトランザクションの結果には一貫性はないが、原子性を与える。

個別隔離性制御５８は、前記タスクを一方向に制御することで前記個別トランザクションに隔離性（独立性）を与える。隔離性は、各タスクの作業データ６ａが相互に独立しており、他のタスクの作業結果が他のタスクの作業結果に影響を与えないようにする性質である。本実施形態及び実施例では、一方向制御により、すでに完了したタスクのデータが、より終了画面側のタスクの都合で上書きされることがない。開始画面側で入力し、または確認した作業データ６ａを修正するには、その開始画面側のタスクまでジャンプして戻らなくてはならない。ジャンプして戻ると、戻ったタスクより終了画面側のタスクの作業データ６ａは作業中の扱いとなる。このように、本実施形態及び実施例では、一方向制御により、個別トランザクションの個別隔離性を得ることができる。

個別永続性制御６０は、タスクの進捗ステータスが作業済に変換された際に、当該進捗ステータスが作業済である前記個別トランザクションに永続性を与える。すなわち、進捗ステータスが作業済となったデータは、作業トランザクションの作業データ６ａとしての一貫性はないが、データベースに作業済として永続的に登録することができる。

そして、中断制御６２は、前記端末１から中断要求を受信した際に、当該作業トランザクションに一貫性を与えないまま、当該タスクまでの各タスクの個別トランザクションに永続性を与える。これにより、複数のタスクからなる銀行業務処理システムにて、一方向制御をしつつ、画面の途中で作業を中断する仕組みを実装することができる。
また、個別トランザクションに原子性や永続性を与えつつ、一貫性を与えない取り扱いとすることで、作成過程の未完成のデータが他システム７０等に影響を与えることがない。
図１６に示すトランザクション管理部５０の機能により、作業トランザクションの一貫性と、個別トランザクションの永続性とを確保し、業務プロセスを厳格に管理することができる。

この中断制御６２を有する例では、営業店担当者にとって突然の電話や来客などとの対応でき、セキュリティーを確保しつつ、それまでの入力を事後に活用することができる。すなわち、一連の作業をそのまま保存しつつ、作業を即座に中断し、所要の後、中断した画面又はタスクから開始することのできる中断制御６２を実装すると、利便性が向上する他、さらに、極めて例外的な理由で作業者がログイン後に端末１を放置することを想定しても、タイムアウトによる中断制御６２を実行することができる。

＜特定操作要求制御＞
本実施例３では、銀行業務の作業を柔軟かつ均質に行うという課題に対して、保守的な初期値の表示と、例外判断については入力を必須とする情報処理により、例外判断時の手順を強制する作用を営み、判断根拠を明確にするという効果を得る（図６参照）。

図３１に示す例では、銀行業務処理システムは、端末１とネットワーク２を介して接続されたコンピュータシステム４と、ネットワーク２を介して端末１とコンピュータシステム４との通信を制御する通信制御部３と、他システム７０とを備えている。他システム７０は、勘定系システムや、情報系システムであるオンラインシステム７２と、債務者（取引先）毎の情報（図７４の動向コメント２２２）を管理する取引先要項システム７４と、不動産担保評価システム等のその他各種システム７６とを備えると良い。

そして、コンピュータシステム４は、作業データ格納部と、進捗ステータス格納部８と、画面定義情報格納部７と、タスク処理部１０と、進捗制御部３０と、ワークフロー制御部９４とを備えている。また、本実施例では、起票制御部９６を備えている。起票制御部９６は、銀行業務処理の作業を予め定められた条件に従って自動起票し、又は、前記作業者の前記端末１の操作に応じて手動起票し、当該起票する作業に作業通番を付する。

そして、本実施例では、タスク処理部１０の前記表示制御処理１６は、特定操作要求処理２４を備えている。この特定操作要求処理２４は、銀行業務の作業上保守的な内容の作業データ６ａを前記作業者の入力データ６ｃとして初期値表示すると共に、当該初期値表示する入力データ６ｃが当該作業者によって変更される際には、前記画面要素の選択又は前記画面要素への入力を含む特定操作用の画面要素を特定操作要素として表示制御する。
特定操作要求処理２４が、情報処理として、保守的初期値の表示と、例外判断時に特定操作を要求するため、作業者の保守的な判断を導きつつ、一方、個々の債務者の実態に応じた判断を可能とすることで、柔軟で、かつ均質である銀行業務処理を促す。

また、図３１に示す例では、タスク処理部１０の条件確認処理２０が、特定操作確認処理２２を備えている。この特定操作確認処理２２は、初期値表示する入力データ６ｃが変更されている場合に、次タスクへの推移が要求された際には、前記特定操作要素が操作されたか否かを確認し、当該特定操作要素に対する特定操作が前記作業者によってなされていない際には、当該特定操作を当該作業者に要求する特定操作要求を表示する。これにより、当該特定操作がなされない状態での前記次タスクへの推移を禁止することができる。

＜実施例３： 格付自己査定システム＞
再度図１１を参照すると、銀行業務として信用格付及び資産査定を行う格付自己査定システムは、当初の作業者が担当するタスクとして、１０メイン、１１決算検討、１２信用格付・スコアリング、１３自己査定、１５管理・回収方針、１６債務者の概況、１９統括者指定のタスク群を有する。以下、先頭文字のＴと、４ケタの数字の組み合わせをタスクＩＤとする。さらに２ケタの数字の組み合わせを画面ＩＤとする。
図１１に示す例では、当初の作業者が担当するタスクは、タスクＩＤ：T1000からタスクＩＤ：T1600までのタスクである。

［格付自己査定のタスク群］
メインタスク（T1000)は、複数の作業を表示して作業開始する作業の選択等を促す。
決算検討タスク群（T11xx)は、前記債務者から徴求した決算書類による財務データの登録がなされた際に、当該財務データを基礎データ６ｂとして当該決算検討及び財務の実態登録を前記作業者に促す。
信用格付タスク群（T12xx)は、主に前記基礎データ６ｂによる財務データを使用して、信用格付の一次評価の確認を前記作業者に促す。
債務者区分タスク群（T1310, T1320)は、信用格付タスク群（T12xx)までの作業データ６ａと、前記債務者及び当該債務者の債権に関する基礎データ６ｂとを使用して、財務状態又は事象として予め定められた抽出基準に該当する債務者について、債務者区分及び信用格付の判定を促す。情報処理として、抽出基準に対応する抽出符号を定めておき、抽出基準に該当する場合には抽出符号をオンとする。
債権分類タスク群（T133x, T1359)は、債務者区分タスク群（T1310, T1320)までの作業データ６ａと、当該債務者の債権に関する基礎データ６ｂとを使用して、当該各債権の保全の確認及び修正を促す。
管理・回収方針（T1500)は、債務者区分が一定以下の債務者の債権について管理・回収方針を文章で表記することを促す。
債務者の概況（T1600)は、信用格付及び資産査定の作業完了に際して、当該債務者についての情報の要約を促す。
これらのタスクに含まれる画面の一覧を図３９に示す。画面例を参照しての開示は実施例４で行う。

［信用格付と債務者区分］
次に、信用格付と自己査定の債務者区分との関係を説明する。
信用格付タスク群（T12xx)では、主に債務者から提出された公表財務データに基づいて債務者の信用格付を判定する。実施例によっては、実態登録後の実態財務データを使用して信用格付をしても良い。一般に、信用格付は、恣意のない一律の判断をするために、財務データの財務数値をスコアリングモデルで評価し、その評点の合計点等から当該債務者の信用格付を算出する。
一方、債務者区分は、財務データ（債務者の貸借対照表と損益計算書から分析できる事実）のみならず、取引先（債務者）の行為や、債権の返済状況等の事象の観察結果の情報も加味して区分する。金融検査マニュアルは、信用格付と債務者区分とが整合的であることが必要であるとしている。本実施例では、信用格付タスク群（T12xx)での信用格付を一次評価とし、債務者区分タスク群（T1310, T1320)での債務者区分の結果に応じて確認し、債務者区分の判断と一体として一次評価に必要な修正をする。このように、財務データによる信用格付を、具体的な取引先の事象に応じて修正する業務プロセスを構築したことで、両者の整合性を確保している。

図３２を参照すると、横軸は信用格付及び債務者区分で、図中左側は信用リスクが小さく良好で、右側が悪化であり、縦軸はスコアリングモデルによる評点である。図３２中、信用格付はＡからＺ、正常先、要注意先の後、要管理は要管理先債権を含む要注意先、懸は破綻懸念先、実は実質破綻先、破は破綻先である。
スコアリングモデルの評点は、信用格付を区分するものであるから、評点が大きいほど信用格付が高くなければならない。正常先については、この関係が成り立つが、正常先と要注意先との区分については、スコアリングモデルのみでは信用格付を区分することができない。すなわち、スコアリングモデルは、財務分析による判断であるが、自己査定は、延滞の有無、延滞の期間など、取引先に生じている事象による判断である。このため、財務分析のみでは、正常先と要注意先とを区分することができない。

端的な例では、業況が悪化し、売上が１／３に、利益が１／１０になった債務者があるとすると、この売上が１／３になった事業年度では、財務分析によって経営成績の悪化を把握することができる。しかし、売上が１／３になった後、その水準で数年経過していると、売上や利益に変動がなく、経営の不安定性が財務に現れにくくなる。この業績悪化後の一定水準での経年経過に関し、延滞や、貸出条件の緩和などが生じていなければ、安定していると判断できるが、融資返済の延滞などの事象が生じている際には、財務分析としては安定しているのかも知れないが、信用リスク管理として要注意先と把握しなければならない。
信用格付でのスコアリングモデルにて、この業績悪化後の一定水準での経年経過について、信用リスクの低下を把握しようとしても、３つの点で問題が生ずる。

第１に、この信用リスクの再度の低下を把握するための手法をスコアリングモデルに導入すると、正常先のスコアリングの精度が悪化しかねない。
例えば、この例で信用リスクの再度の低下を把握できるように、スコアリング項目のウェイト（重み付け）を変化させたとすると、当該信用リスクの再度の低下を把握できるようになるかも知れないが、正常先の判断が実際の信用リスクから乖離しかねないのである。例えば、スコアリングモデルでは、各スコアリング項目の評点の加算により最終的な評点を求める。従って、延滞等をスコアリング項目に入れたとしても、他のスコアリング項目の評点が高ければ、結果的に正常先の範囲内の評点となることも想定され得る。この評点の加算により合計評点を求めるというスコアリングモデルの仕組みでは、特定の事象が生じていることによって合計評点を下げることはできない。この合計評点を下げることを行おうとすると、スコアリングモデルが二本立てになるなどし、比較可能性を減少させ、実際の信用リスクとの乖離が生じてしまう恐れがある。

第２に、延滞や、貸出条件緩和などの事象の発生は、業種によっても異なり、経営者によっても異なる個別性の高い信用リスクであるため、財務分析の判断を精密にすると、信用リスクが低下していない先についても抽出されてしまい、結局、個別の事象による判断が必要となってしまう。これでは、均質な財務分析にならない。

第３に、財務分析にて延滞等の事象の発生を予測するには、経営者の個人資産を会社の資本金に加算するなど、公表された財務項目の数値への加減算が多くなりすぎ、正常先のスコアリングによる信用格付の精度が悪化してしまう恐れがある。すなわち、スコアリングは、公表財務データから客観的に定量的なスコアリングを行うことが望ましい。経営者の主たる事業外の収入から回収確実な際に、正常先と判断できるのは、例外的な判断であって、自己査定作業では、そのような判断の経過と例外判断の根拠とを明確にすべきである。
従って、実態財務として経営者から会社への融資を資本金に組み入れるのではなく、実態財務の分析では債務超過との数値を得ておき、スコアリングは公表財務の数値により他社との比較を行う。そして、自己査定の判断基準として、家族等収入で回収確実と判断できるのであれば、その適用を明確にし、公表財務等では債務超過となるが、実質債務超過ではないとして、正常先に区分すべきである。すなわち、判断の結果のみならず、判断の過程の明確さが必要であり、このためには、自己査定作業と同時に信用格付を必要に応じて修正する本実施例による業務プロセスが好ましい。特に、判断の過程を明確にすると、検証可能性を向上させ、監査・検査時間の短縮させることができる。

このように、信用格付でのスコアリングに際しては、公表された財務計数を尊重し、不良資産による減額は行うものの、経営者の個人資産を会社の資産に加算する等の調整は行わない。これにより、全ての債務者につき、公表された財務計数に基づいたスコアリングを保守的に行うことができる。一方、より実態を参酌した判断は、保守的かつ限定的に自己査定作業での例外と位置づけつつ判断する。そして、本実施例では、信用格付は、財務分析により行い、自己査定作業では、事象や個別事情を考慮して判断し、最終的に、自己査定作業にて要注意先以下と判断された際には、信用格付を修正する。これにより、スコアリングモデルを精緻に維持することができ、信用リスク管理として予見可能性を高めることができる。

図３２を参照すると、信用格付のＡからＧは正常先であり、そのスコア（合計評点）は、ＡからＧへ段階的に小さくなっており、スコアと信用格付とは強く相関している。一方、要注意先のＨでは、正常先のＦと同一のスコアの債務者もあれば、正常先のＧと同一のスコアの債務者もある。従って、スコアでは、正常先と要注意先とを明確に切り分けることができない。この正常先と要注意先をスコアで切り分けることができるようにスコアリングモデルの調整をしたとすると、その調整によって、信用格付のＡからＧまでをスコアによって区分することができないモデルとなってしまう。すなわち、正常先と要注意先の切り分けは、自己査定作業によって行うべきであり、その自己査定作業によって、要注意先と区分された債務者については、最終的に信用格付をＨ以下とする。同様に、正常先を区分できるスコアリングモデルでは、要注意先、破綻懸念先等をスコアで区分することができない。なお、信用格付作業にて、定性的要因の判断により、ランクアップ、ランクダウンを行うと、そのスコアによる格付から、信用格付を１段階上下に移動することとなる。この場合、同一のスコアであるが、１段階上下の信用格付に所属する先が生じる。

本実施例では、信用格付作業を公表財務によるスコアリングモデルにてスコアを使用して信用格付を格付し、一方、自己査定作業では個別の事象の発生や取引先の事情に応じて債務者区分を行う。そして、自己査定作業にて要注意先以下となった債務者については、正常先に相当する信用格付の一次評価であっても、自己査定作業の後に、信用格付を修正する。これにより、信用格付作業では、正常先を有意に区分できる信用格付を得ることができる。
財務諸表を作成する基準として、継続企業の公準（ゴーイング・コンサーン）がある。継続企業の公準は、財務諸表は、その企業が永続することを前提に、事業年度を単位として、作成するというものである。従って、資産は、清算価格ではなく、企業の永続性を前提として、取得原価を減価償却した金額である。債務者区分として、破綻懸念先は、この継続企業の公準が満たされない可能性を懸念するものである。そして、継続企業の公準を満たさなければ、その財務諸表は不正確である可能性がある。このため、正常先ではない債務者の財務諸表は、会計基準からして、正常な財務分析ができない可能性がある。従って、財務分析は、正常先に最適化することが最も精緻であり、適切である。一方、要注意先以下の判断については、財務分析ではなく、取引先に生じた事象を加味すべきである。この点、本実施例にて、自己査定作業後に信用格付の確定を行う業務プロセスは、正常先を有意に区分し、かつ、要注意先以下を正確に区分することのできるものとなっている。特に、一方向制御により、自己査定作業と同時に、信用格付の確定作業を促すため、全ての自己査定作業に関し、自己査定による債務者区分と、信用格付との整合性を強力に確保することができる。

［抽出符号］
図３３は、本実施例で使用する抽出符号の一覧を示す説明図である。抽出符号は、確認を要する正常先、要注意先及び破綻懸念先以下と判断する抽出基準に該当するか否かをシステム上管理する符号である。
図３３に示すように、抽出符号は基礎データ６ｂから導出することができる。例えば、オンラインシステム７２では与信明細を管理するコードを保持しており、そのコードの種類によって当該与信債権がリスク管理債権であるか否かをシステム的に取り扱うことができる。そして、債務の返済に関しては、口座振替や、オンライン端末１のオペレーションにより債務者の口座を用いて決済するため、仮に延滞が発生した場合にはその延滞情報をオンラインで管理することができる。そして、延滞日数に応じて延滞金が発生し、その延滞金の額をオンラインシステム７２で計算するため、延滞情報もオンラインシステム７２で管理している。また、融資の資金使途が利息返済である場合や、融資条件を変更した場合や、当初から返済期日を極端に長期とした等の与信条件に問題がある場合等を、融資先管理コードとして管理している。この与信明細管理コードと、融資先管理コードとにより、抽出符号のほとんどを導出することができる。

また、例えば、不動産プロジェクト資金与信先で、プロジェクトの事業化又は販売の目処が当初計画より一年以上遅れている先（抽出符号「不」）について、与信債権明細管理コード等による管理を行っていない場合には、これを手動抽出符号とし、債務者決算検討時の作業で作業者による手動による抽出符号の設定を促すようにしてもよい。財テク資金（投機資金ではない）与信先で、含み損がある先等をオンラインシステム７２で管理しない場合にも、抽出符号の内容からして、債務者の財務諸表の分析時に判明するため、手動抽出符号として、基礎データ６ｂからの導出を行わないようにしても良い。

抽出符号「赤」や、無配先又は低株価先を示す「株」は、公表財務計数から導出することができる。「赤」は、決算書に欠損金を計上している先である。これは、経常損失又は当期損失を計上している先や、繰越欠損金を計上している先や、償却不足等により実態が欠損となっている先である。債務超過先を示す「債」は、公表財務計数を修正した実態財務計数や、個人事業主の場合の簡易登録等から導出することができる。当行の役員関連与信先というのは、融資先の取締役が役員の親族である等の場合であり、コンプライアンスの観点から正常先であっても監査の権限により詳細な資産査定を行うものである。

信用格付は、実態財務計数に基づいて定量評価を行い、債務者の状況から定性評価を行うことが多い。この場合、評価の項目毎に内容に応じた評点があり、その合計点数で信用格付を定める。「格」のスコアリングというのは、この信用格付の定量又は定性評価の評点である。関連融資先「グ」は、例えば親会社が要注意先以下の場合の子会社等であり、関連融資先データから導出することができる。

抽出符号と債務者区分等の関係については、例えば、赤字先については、赤字先であれば必ず要注意先に区分されるとは限らない。赤字先は一般的に今後の管理に注意を要する債務者であり、原則的に要注意先に債務者区分することとなる。しかし赤字企業でも、それが一過性の原因によるものや、創業赤字と見られる場合には、要注意先とする必要はない。一過性の原因としては、例えば、不要設備の除却損など、特別な損失の発生や、一時的な原因によるもので、体質的・構造的な要因によるものでないこと等である。

［エンティティー・リレーションシップ］
次に、格付自己査定作業で使用する作業データ６ａのデータ項目を説明する。
図３４から図３７は、作業データ６ａの各データ項目のキーを示すＥＲ図である。エンティティー・リレーションシップ図（ＥＲ図）は、リレーショナル・データベスのデータ項目のキーを明示する図である。このＥＲ図は、３つのボックスからなり、上段がエンティティーの名称、中段がキー、下段が項目である。
例えば、顧客５０６では、上段の「顧客」がエンティティーの名称で、中段の「ＣＩＦ番号」がこの顧客のデータ項目を特定するためのキーで、顧客についてＣＩＦ番号のみで特定できるデータ項目は下段の業種コード、人格コード、親会社顧客番号等である。顧客５０６のキーはＣＩＦ番号のみであるため、ＣＩＦ番号を唯一に特定すると、業種コードは唯一に特定される。
基準日顧客５０８は、ＣＩＦ番号のみならず、基準日もキーとする複合キーである。例えば、代表者氏名や、企業グループを識別するグループ番号等は、ＣＩＦ番号と基準日とで特定する。この中段のキーと下段のデータ項目との関係は、図３４から図３７、及び図１２に示す全てのエンティティについて同様である。点線は、キーを共通とする外部キーのうち、特に注目する外部キーの共通性を示す。

図３４に、ＣＩＦ番号、基準日及び／又は作業通番をキーとするエンティティーを示す。
図３５に、決算年月等をキーとする顧客別決算年月５３０や、顧客別財務計数比率５３４を開示する。
図３６に、査定部門コード等をキーとする顧客部門別作業５４０や、与信明細査定結果計数５４８を開示する。
図３７に、疎明資料索引５５４等の制御用のテーブルの一例を開示する。

［特定操作要求］
・コメント
図３８に、格付自己査定作業のタスクにて必要に応じて入力を促すコメント名と、そのキー項目を掲げた。
本実施例では、特定操作要求処理２４が、銀行業務の作業上保守的な内容の作業データ６ａを作業者の入力データ６ｃとして初期値表示すると共に、当該初期値表示する入力データが当該作業者によって変更される際には、コメント入力フィールドを特定操作要素として、当該コメントの入力を促すと良い。
この例では、条件確認処理２０の特定操作確認処理２６の一部として、コメント入力フィールドに、何らかのコメントが入力されたか否かについては確認すると良い。この場合であっても、コンピュータシステム４の情報処理として入力されたコメントの内容については確認しない。入力されたコメントの適切性については、コメントの強制再表示処理１２によってコメントを入力した当初の作業者自身によって確認され、また、ワークフロー制御部９４による作業のワークフローによって、二次査定部門や監査部門にて確認される。

この例では、入力データ６ｃがコメントであり、コメントの入力がなされない場合には次タスクへ推移するボタンＢ２の操作を禁止するため、例外判断については必ずコメントが入力される。このため、二次査定部門や監査部門にて作業者の当初の思考を追認しやすい。また、例外判断の根拠を業務プロセスとして明確とすることができる。すなわち、作業者の個々のスキルによらず、例外判断については必ずコメントが入力されるため、部門間の牽制効果を高めることができ、不適切な例外判断であるか否かを二次査定部門及び監査部門で発見しやすい。また、例外判断についてコメント入力を必須とすることで、事後的な検証可能性を高めることができる。

・理由コード
好適な例では、前記特定操作要素を、前記債務者の実態に応じた当該作業者の判断の理由について予め定められた理由等のコード４ｘｘの選択の入力を求める理由コードフィールドとすると良い。理由等のコード４ｘｘは、例えば、信用格付判定理由コード４２３（図５７）である。これは、信用格付の一次評価と、債務者区分による信用格付とが異なる際に、債務者区分と信用格付とを整合させる判断をした際にも入力を促すコートである。

・抽出基準の例外
好適な例では、前記導出データ６ｄとして、抽出基準に該当するか否かをオン／オフで示す抽出符号（破綻懸念先以下抽出符号８０，要注意先抽出符号８２，正常先抽出符号８４）を有する。この例では、債務者区分タスク群（T1310, T1320)が、抽出基準確認タスク（T1310）を備える。
抽出基準確認タスク（T1310）は、図３３に示す作業データ６ａを使用して、各抽出符号（８２，８４）のオン／オフを計算する。そして、前記計算した各要注意先抽出符号８２及び前記各正常先抽出符号８４のオン／オフを、前記特定操作要素である当該作業者の初期値として、入力編集可の要素属性で表示制御する。さらに、前記各抽出符号のオン／オフの確認及び入力を当該作業者に促すと共に、前記要注意先抽出符号８２の一部がオンとされた債務者について、当該作業者の判断により債務者の財務状態の実態に応じて正常先に区分しようとされる際には、前記特定操作確認処理２６として、抽出基準修正コメント２１０の入力を要求する。

この実施例３では、一方向制御により判断過程を統一しつつ、特定操作要求処理２４が、予め定められた事項・項目について作業者の入力データ６ｃを初期値表示し、当該初期値が変更される際には、特定操作を要求し、特定操作がされない状態での画面遷移を禁止する。従って、予め定められた事項について、作業者の判断根拠を記録することができ、例外判断の根拠をデータとして管理することができる。そして、例外判断を許容しつつその根拠に相当するデータの入力を求めることで、作業者の柔軟な判断と均質な判断との調和を保持し、統制することができる。これにより、内部監査の有効性と効率性を向上させることができる。

＜格付自己査定システム：画面の具体例＞
次に、具体的な画面例を参照しつつ、銀行業務処理システムの一例として格付自己査定システムの一例を開示する。
図３９に、画面の一覧例を示す。図３９に示す一覧例は、図１１に示すタスクＩＤT1000からT1600までのタスクに含まれる画面例で、債務者が法人の場合の進捗を左側に、個人の場合の進捗を右側に示した。本実施形態及び各実施例での一方向は、図３９では図中上側の画面から下側の画面に向かう方向である。
また、図４０以下に図示した画面については図中左端の図面欄に丸を付した。

実施例４の格付自己査定システム（銀行業務処理システム）は、前記タスク処理部１０が、前記一方向制御処理４２に従って推移させるタスクとして、図３９に示すように、決算検討タスク群（T11xx）と、信用格付タスク群（T12xx）と、債務者区分タスク群（T1310, T1320）と、債権分類タスク群（T133x）と、債務者の概況タスク（T16xx）とを備えている。

そして、前記債務者区分タスク群（T1310, T1320）が抽出基準確認タスク（T131x）を備えている。この抽出基準確認タスク（T131x）は、まず、決算検討タスク群で登録された実態財務データを含む作業データ６ａから前記抽出基準に該当するか否かを示す複数の抽出符号のオン／オフを計算すると共に当該抽出符号のオン／オフを前記特定操作要素である当該作業者の初期値として入力編集可の要素属性で表示制御する。そして、抽出基準確認タスク（T131x）は、前記各抽出符号のオン／オフの確認及び入力を当該作業者に促す。さらに、当該作業者の判断により前記抽出符号のオン／オフの初期値を修正しようとされる際には、特定操作要求処理２４として、抽出基準修正コメント２１０の入力を促す。

さらに、本実施例４では、債務者の概況タスク（T16xx)にて債務者の概況を担当者による最後の内容確認画面として、この債務者の概況画面を使用して、一方向制御の最後に総合的な整合性の判断を促すと良い。この場合、債務者の概況タスクが、強制再表示処理１２として、決算検討コメントの一部（206, 207, 208）又は全部（203, 204, 205, 206, 207, 208）を入力編集不可の属性で再表示する。すなわち、決算検討タスク群（T11xx)が、当該債務者の決算を検討した作業者へ当該決算検討コメント（204, 205, 206, 207, 208)の入力を要求し、作業者は、例えば、図４６に示す画面にて決算検討コメント（204, 205, 206, 207, 208)を入力する。

そして、前記債務者の概況タスク（T16xx)が、前記一方向制御処理４２の実行下で、前記決算検討コメントの一部（206, 207, 208)又は全部（203, 204, 205, 206, 207, 208)を入力編集不可の属性で再表示するとよい。このように、債務者の概況タスクにて、決算検討のコメントを表示し、決算検討コメントを修正する際には、強制的に、決算検討画面まで処理を戻し、決算検討、信用格付、自己査定の全ての画面を再度経過しなければ、債務者の概況タスク（T16xx)に戻ることができない。すなわち、決算検討作業が作業の骨幹であって、この決算検討作業の結果を集約した決算検討コメントの一部又は全部が債務者の概況の判断にて矛盾することは許されない。

この債務者の概況タスク（T16xx)により、柔軟な判断を許容しつつ、総合的整合性の確保を促す。債務者の概況タスクにて、総合的な整合性が確認できない場合には、一方向制御により、信用格付や債務者区分の判定用の画面まで作業を戻すこととなる。債務者の概況画面の一例を図６９及び図７０に示す。
本実施例は、この抽出基準確認タスクの特定操作要求と、債務者の概況タスクでのコメントの強制再表示により、早期熟達と事務合理化との両立を図り、業務プロセスを確立し予防的統制効果を得て、検証性を高め、ＩＴによる内部統制の質を向上させることができる。

また、一方向制御下にて、ワークフロー制御部９４による差戻しがある際には、差戻し先４２８のタスクを債務者の概況タスク（T16xx)とすると良い。これにより、具体的にどのタスクからやり直しを行うかについては、営業店担当者が自ら判断することができる。
この例では、サーバー４Ａが、ワークフロー制御部９４を備える。このワークフロー制御部９４は、前記作業者による作業の完了後、同一又は他の査定部門のワークフロー先へ当該作業を電子的に回付し、当該ワークフロー先にて当該作業を前記作業者へ差し戻す操作がなされた場合には、当該作業を前記作業者に電子的に差し戻す。そして、前記進捗制御部３０が、前記一方向制御処理４２の実行下で、前記ワークフロー制御部９４によって電子的に差し戻された作業の作業対象のタスクＩＤを、前記債務者の概況タスク（T16xx)のタスクＩＤとする。
この例では、差戻しの内容に応じて、差し戻された作業者自らが修正すべき画面を選択でき、これにより、最小限の作業で差戻しに対応することができる。実際には、差戻し時に進捗ステータステーブル８ａにアクセスし、作業済である債務者の概況の進捗ステータスを作業中に変更する。すると、メインタスク（T10xx)を現タスクＩＤとして次タスク特定処理３４を実行すると、債務者の概況タスク（T16xx)が次タスクＩＤとなる。

［チェック・確認］
各タスクは、チェック画面と、確認画面とを有すると良い。すなわち、チェック画面としては、図３９に示すように、基礎データ６ｂ及び導出データ６ｄを表示して入力データ６ｃの入力を促すチェック画面（例えば、タスクＩＤ13-10-01から13-10-04や、13-32-01から13-32-04）がある。確認画面としては、前画面までに入力された作業データ６ａを一覧として表示し当該作業データ６ａの整合性の確認を促す確認画面（例えば、タスクＩＤ13-10-05以後や、13-32-05）がある。
タスクがこのようなチェック画面と確認画面とを有すると、確認画面の繰り返しにより、個別の判断の整合性を保ちつつ、全体の整合性の確保を促すことができる。確認画面では、チェック画面又はそれ以前に入力された入力データ６ｃや、導出データ６ｄを再表示すると良い。

図３９中、xx-xx-xxの画面ＩＤで識別する各画面につき、画面の名称に「チェック」が含まれている画面がチェック画面であり、名称に「確認」が含まれている画面が確認画面である。例えば、図１１に示す自己査定の抽出基準確認タスク（T1310）は、図３９に示す例では、取引先の事象チェック：13-10-01（図５１）、抽出基準チェック１（債務者単位）：13-10-02（図５２及び図５３）、抽出基準チェック２-１（貸出金明細）：13-10-03（図５４）及び抽出基準チェック２-２（商手・オフバラ明細）：13-10-04（図示なし）の４つのチェック画面と、確認画面：13-10-05（図５５）とを有する。

＜実施例４： 画面の具体例＞
それでは、以下、実施例４の格付自己査定システムの画面の具体例を説明する。画面例では、下記の架空の事例とし、架空の数値を開示する。事例及び数値や事象は架空のものであるが、これらの数値や事象に応じた作業者の判断や、コンピュータシステム４の情報処理内容は通常の自己査定に関する様々な要請に整合したものである。一方、各事例での個別の判断手法等は、必ずしも出願人自身の実際の要領とは一致しない場合や、出願時点にて一致していても出願後の法制度及び実務の変化により一致しなくなる場合もある。また、本実施例による格付自己査定システム（銀行業務処理システムの一態様）を使用する金融機関の規模によっては、債務者も中小・個人事業主から大企業までとその規模が異なるため、下記の事例についての判断とは異なる判断となる場合もある。
図４０に示す符号Ｄ１は、６桁の画面ＩＤである。この画面ＩＤのうち、上四桁はタスクＩＤの番号である。操作できるボタンには右下に影を付した。入力不可の表示項目（フィールドの表示用の名称など）は白抜きで表示している。右下に影を付したフィールドは入力編集可である。他の画面例についても左上に画面ＩＤと画面名を示す。

図３９及び図４０以下に示す例では、コンピュータシステム４のデータ読み出しや通信による負荷を軽減するために、コンピュータシステム４と端末１とのデータの送受信はタスク毎に行う。従って、同一のタスクに属する複数の画面の進捗は、端末１側で管理する。すなわち、同一のタスク内で戻るボタンや次へボタンを操作した際には、コンピュータシステム４との通信を発生させず、端末１側で画面の切り替えをする。コンピュータシステム４の進捗制御部３０がタスクの進捗（「次へ進む」と「戻る」）を管理するのは、タスクの最後の画面で次へボタンが操作された際と、タスクの最初の画面で戻るボタンが操作された際である。

図４０は、画面ＩＤ：00-00-01の格付自己査定システムメイン（営業店）画面の一例である。図中左上の符号Ｄ１で示す00-00-01がこの画面の画面ＩＤである。この画面は、メインタスクT0000に含まれる。画面ＩＤの上位４桁がタスク番号である。作業者名は、図中右上に表示される。ここでは、作業者名は「作業者１」であり、作業者１は、営業店の担当者である。このメイン画面では、起票された作業の一覧が表示される。作業者が、取引先名Ｄ２等をみて、リストの任意の位置にてクリック操作等をすると右端の選択Ｄ４がチェックされ、右下の作業開始ボタンＢ１を操作すると、選択した債務者の作業が開始される。
図４０に示す例では、ＣＩＦ番号10-XXX-XX1のＡ株式会社の作業がチェックされている。この状態で、画面右下の作業開始（次へ）ボタンＢ１ボタンを操作すると、Ａ株式会社の作業の開始となる。この作業開始ボタンＢ１の操作に応じた要求を受信すると、ワークフロー制御部９４は、この作業通番の作業ステータスを実行に変更する。

続いて、進捗制御部３０は、起票時処理３６を実行することで、この作業通番の進捗ステータスを生成して、全てのタスクに未着手を格納する。また、作業の開始時ではなく、伝票に作業通番を与えて起票し、当該メイン画面に表示可能とする段階で、進捗ステータスを生成し未着手を格納するようにしても良い。進捗制御部３０は、さらに、次タスク特定処理３４を実行することで次タスクＩＤをT1100と特定し、そして、T1100（決算検討作業選択，図示せず）のタスク開始処理３８を実行する。また、この画面にて、状況速報ボタンＢ１１を操作すると、状況速報による作業を起票するため、図４１に示す画面ＩＤ： 02-00-01の状況速報起動画面を呼び出す。
終了ボタンＢ６が操作されると、作業を終了する。

図４０に示すメイン画面では、画面右上の並び替えボタンＢ２１と、「融資先番号順」とあるコンボボックスとの操作により、作業の一覧を並べ替えることができる。また、データ一覧更新ボタンＢ１２の操作を受信すると、ワークフロー制御部９４は、作業ステータス等を参照して、最新の情報を端末１に送信する。作業は、起票されると、営業店の振り分け担当者に振り分けられる。なお、状況速報による起票の際には直接担当者に振り分けるようにすると良い。営業店の振り分け担当者は、振り分け待ち一覧ボタンＢ１３を操作し、振り分けされていない作業の一覧をメイン画面に表示する。振り分け待ち一覧ボタンＢ１３が操作されると、ワークフロー制御部９４は、当該営業店の作業のうち、作業ステータスが待機である作業の一覧を端末１に送信する。振り分け担当者の指名等は、権限変更の権限を有する例えば支店長等が本システム又は別システムの操作により行う。担当者変更は、担当者変更ボタンＢ２０等の操作により行う。

処理待ち一覧ボタンＢ１４が操作されると、振り分け作業、営業店担当者の作業、統括者や支店長の承認待ちなど、手続毎の作業の一覧を表示することができる。作業の手続の状態は、作業ステータスの他、進捗ステータスとして管理されている。ワークフロー制御部９４は処理待ち一覧ボタンＢ１４，担当者作業待ちボタンＢ１５，承認待ちボタンＢ１６、確認待ちボタンＢ１７及び店一覧ボタンＢ１８の操作による要求に応じて、作業ステータスや進捗ステータスを参照し、作業の一覧を生成し、端末１に送信する。

取消起票は、営業店担当者が行う。例えば、図４０に示す例では、起動条件が決算登録である△株式会社と、起動条件が状況速報である△株式会社とが起票されている。決算登録は自動的な起票であり、状況速報は手動による起票であるから、このような重複して起票される状態を要件定義として意図的に許容している。ワークフロー制御部９４は、異なる作業通番で、同一のＣＩＦ番号の作業が重複しているため、ＣＩＦ番号の重複により、作業の重複と判断する。そして、重複フィールドＤ３に「不可」を表示する。
２つの作業のうち、決算登録の作業は必須であるため、状況速報による作業を取り消す。営業店担当者は、状況速報の△株式会社を選択し、データ取消ボタンＢ１９を操作すると、取消理由の入力を要求された後、当該状況速報による作業の取消を起票する。この取消は、例えば統括者に電子的に回付され、統括者の承認によって取消を行う。この作業が取り消されると、決算登録による△株式会社の作業の不可が外れ、作業を開始することができるようになる。ワークフロー制御部９４は、取り消された作業通番の作業については、作業ステータスを取消とする。

図４０下の取引先要項ボタンＢ２４が操作されると、コンピュータシステム４は、取引先要項システム７４を起動する。取引先要項システムについては、特許文献４に詳細が開示されている。作業の前に、取引先要項システム７４の要項ＩＩの画面（例えば、図７４、特許文献４の図４等）に、主要動向区分４３０と動向コメント２２２とを入力する。主要動向区分４３０は、動向コメント２２２の種類を示すもので、例えば特許文献４の図３に例示されている。図６９に示す例では、主要動向区分４３０は、「創業」「法人成り」「事業の展開・変動」等である。

照会ボタンＢ２３を操作すると、作業のための各種の情報を照会することができる。疎明資料ボタンＢ５は、電子的な疎明資料をコンピュータシステム４に登録するための操作を受信するボタンである。疎明資料の登録は、通常の作業では入力できない情報を登録するものである。具体的には、表計算ソフトウエアのファイルや、ワードプロセッシングソフトウエアのファイルや、画像データのファイルを、疎明資料として、作業通番毎に、コンピュータシステム４に登録する。
印刷ボタンＢ２２が操作されると、印刷するための画面に推移する。ヘルプボタンＢ２７が操作されると、ヘルプを表示する。

図４０に示す例では、ＣＩＦ番号10-XXX-XX5のＦ株式会社について、差戻のマークが付されている。これは、実態バランス再修正を起動条件とした作業について、一度担当者の作業を完了させてワークフローとして回付したが、上級審から差し戻された作業である。

図４１は、画面ＩＤ：02-00-01の状況速報起動画面の一例を示す説明図である。状況速報起動画面は、メイン画面00-00-01の状況速報ボタンＢ１１の操作により呼び出される。状況速報起動画面では、営業店担当者は、図中左上のＣＩＦ番号入力フィールド３００に状況速報を起動する債務者のＣＩＦ番号を入力し、登録ボタンＢ１を操作する。すると、融資先番号600-xxx-xx3の「Ｃ株式会社」との取引先名と、主担当店である「本店営業部」とが表示される。また、勘定系システム等のオンラインシステム７２との整合を確保するために、オンラインシステム７２の操作の手順が表示されるため、営業店担当者は、この内容を確認し、オンラインシステム７２に必要な操作を行う。そして、営業店担当者は、状況速報起動理由コード４００の一覧から、該当する状況速報起動理由コード４００を選択する。ここでは、取引先の業況変化を選択する。登録ボタンＢ１の操作を受信すると、起票制御部９６は、状況速報による作業を起票し、作業通番を付し、進捗ステータステーブル８ａを初期化する。例えば、全てのタスクについて未着手とする。その後、メイン画面に戻ると、この状況速報による作業が起票されている。

画面ＩＤ：10-00-01の作業開始確認画面（図示せず）では、債務者の業種や人格（法人、個人、ノンバンク）を確認し、事実と異なる際には、オンラインシステム７２についても変更が必要であるため、オンラインシステム７２に変更を登録し、その後、本実施例による格付自己査定システムに取り込む。また、作業開始確認画面では、円換算レートを入力する。業況変化による状況速報による際には、作業開始確認画面にて、変化の理由コード４０１（主要動向区分４３０としても良い）を選択し、さらに、その内容について業況変化の詳細内容コメント２００を入力する。ここでは、図４１の状況速報起動画面に、この変化の理由コード等の表示例を示す。変化の理由コード４０１としては、周辺状況の悪化、法的手続申立など従来融資先管理で使用していた理由を用いると良い。この変化の理由コード４０１は、取引先要項システムで利用する主要動向区分４３０を使用することもできる。

図４２に示す画面ＩＤ：10-00-02の作業要否選択画面では、格付作業の要否を確認し、選択する。作業要否判定コード４０３は、基礎データ６ｂを用いて情報処理により判定した要否であり、予め定められた条件に従って作業の要否の自動判定結果を表示する。作業者は、作業要の際には次へボタンＢ１を操作する。作業不要の際には作業不要ボタンＢ９の操作により次画面に遷移する。
また、作業の参考とするために、スコアリング評点照会ボタンＢ３０と、抽出符号照会ボタンＢ３１と、個人定量評点ボタンＢ３２と、財務要約照会ボタンＢ３３と、財務分析帳票ボタンＢ３４とを表示し、これらボタンの操作に応じて判断の参考となる情報を表示する。
例えば、抽出符号照会ボタンＢ３１が操作されると、図４７に示す抽出符号照会画面を表示する。
取扱要領ボタンＢ２５が押し下されると、信用リスク管理及び資産査定に関する行内規程（取扱要領）を表示する。Ｑ＆ＡボタンＢ２６が押し下されると、信用リスク管理及び資産査定に関するＱ＆Ａを表示する。

図４３に示す画面ＩＤ：11-00-00の決算検討作業選択画面では、決算検討、信用格付及び自己査定のうち、決算検討作業を開始することを作業者に示す。財務登録がある先の場合には、財務登録有り４０４のラジオボタンについてオンを初期値表示し、次へボタンＢ１の操作により図４４に示す画面へ進む。財務登録がなく決算検討及び信用格付が不能な債務者については、作業では、自己査定作業から開始するようにする。この場合、自己査定４０５のラジオボタンについてオンが初期値表示されるため、この状態で次へボタンＢ１を操作する。

図４４に示す画面ＩＤ：11-10-21の決算検討・雑科目の資産性検討画面は、図３９に示すように、債務者が個人又は個人事業主のときには使用しない画面である。営業店担当者は、この画面で、雑科目毎の公表金額について、債務者から徴求した資料に基づいて、内訳金額４０７と雑科目明細４０８とを入力する。そして、資産性を三段階評価（○△×）し、この資産性コード４０６を入力する。そして、その根拠を文字データとして雑科目資産性・査定根拠コメント２０１に入力する。×は全額資産性なしで、△は評価損など一部に資産性ないことを示す。この「資産性」についての評価は、当該自己査定を行う債権者による信用リスク管理上の判断である。
営業店担当者は、例えば、未収入金について、その雑科目明細４０８に株式会社第２○○社と、第３○○社であることを入力し、第２○○社については業況芳しくないことから、保守的に、資産性なしと査定する。そして、雑科目資産性・査定根拠コメント２０１に「業況芳しくなく、資産性なしとする」と入力する。その内訳金額４０７は、40,000千円である。

図４４の図中画面左側に、フォルダのツリー形式で、進捗フローＢ２が示されている。符号Ｂ２で示す「開始条件確認」から「次フロー」までの流れを、進捗フローという。進捗フローＢ２では、作業済のタスクについては実線で表示し、現在作業中のタスクについては、符号Ｄ１１で示すように黒地に白抜き文字で表示し、現タスクより終了画面側のタスクについては、操作不能として点線で表示する。また、進捗フローは、符号Ｄ１０で示すように、「決算検討」という作業のさらに詳細なタスクを表示するか、または、「決算検討」「自己査定」等の大枠の作業のみを表示するかを選択することができる。符号Ｄ１０の開いたフォルダのアイコンは、その作業の詳細を画面に表示していることを示す。この進捗フローは、進捗フロー非表示ボタンＢ２９の操作によって非表示と表示とを入れ替えることができる。進捗フローＢ２を非表示中には、このボタンは進捗フロー表示ボタンＢ２９となる。進捗フローＢ２を非表示とすると、その範囲を作業のペインに割り当てることができる。

この進捗フローＢ２は、本実施例では、画面やタスクを開始画面側に戻す際のジャンプして戻るボタンＢ２である。すなわち、すでに作業済となったタスクについては、進捗フローＢ２の実線部分をクリックすることで、そのタスクの最初の画面にジャンプして戻ることができる。また、本実施例では、「ジャンプして進む」ことはできないため、現タスクよりも終了画面側のタスクは符号Ｄ１２で示すように点線表示し、クリックすることはできない。
符号Ｄ１０で示すフォルダーは、作業手順の大概念であり、複数の手順を含む。符号Ｄ１０で示す決算検討では、決算実態検討のための手順と、決算総評登録のための手順とを含む。符号Ｄ１１で示す文字反転の表示は、現在のタスクが属している手順である。
この進捗フローＢ２の表示により、業務プロセス全体の流れと、現在の作業の位置付けとを表示する。

図４４の図中画面下側に、ボタン群が配置されている。戻るボタンＢ３は、画面を１つ戻す要求を端末１に送信する。その画面がタスクの最初の画面であれば、タスクを１つ戻す要求を端末１及びコンピュータシステム４に送信する。コンピュータシステム４では、このタスクに対して中断制御６２を実行し、続いて、戻りタスク特定処理３２，Ｃ２３を実行し、当該戻りタスク特定処理３２，Ｃ２３にて特定されたタスクＩＤのタスク開始処理３８，Ｃ２４を実行する。これにより、開始画面側のタスクに作業対象を戻すことができる。

次へボタンＢ１は、この画面の次の画面に画面を推移させる要求を端末１に送信する。その画面がタスクの最後の画面であれば、タスクを１つ進める要求を端末１及びコンピュータシステム４に送信する。コンピュータシステム４では、進捗制御部３０が、タスク完了処理４０，Ｃ２０を実行し、次タスク特定処理３４，Ｃ２３を実行し、タスク開始処理３８，Ｃ２４を実行する。これにより、終了画面側のタスクに作業対象を進めることができる。

図４４に示す例では、画面ＩＤ：11-10-21の雑科目の資産性検討画面と、図４５に示す画面ＩＤ：11-10-22の決算の実態登録画面とは同一のタスク内であるため、画面ＩＤ：11-10-21の次へボタンＢ１の操作により、端末１側で画面ＩＤ：11-10-22の画面を表示させる。１画面１タスクとする際には、サーバー側で画面表示制御を行う。
顧客属性表示ボタンＢ２８が操作されると、当該画面に顧客の属性を表示する。
前回内容照会ボタンＢ３８が操作されると、照会表示処理２８は、前回の決算検討の内容を別途表示する。前回内容取込ボタンＢ３９が操作されると、前年度の決算検討の結果を今回の画面の対応欄に取り込み、表示する。
貸借対照表（単体）ボタンＢ３７が操作されると一覧形式の貸借対照表を表示し、損益計算書（単体）ボタンがＢ３６操作されると一覧形式の損益計算書（単体）を表示する。主要経営比率（単体）ボタンＢ３５が操作されると、図４８に示す主要経営比率（単体）の照会画面を表示する。この画面では、経営比率に関する主な問題点とポイントコメント２０９を自動表示すると良い。
資産性の検討にて、疎明資料を添付する際には、作業者は、疎明資料ボタンＢ５を操作する。コンピュータシステム４は、疎明資料となるファイルを登録するための画面を表示する。

図４５に示す画面ＩＤ：11-10-22の決算検討・決算の実態登録画面では、雑科目の資産性の検討結果に応じて、財務諸表の公表金額の実態を登録する。Ｂ／ＳへボタンＢ４０と、Ｐ／ＬへボタンＢ４１とで、両者を切り替え表示することができる。ここでは、流動資産の一部の科目を例示する。例えば、未収入金であれば、第２○○社についての未収入金の資産性なしと判断したため、その資産性修正額４０９として40,000を入力する。この資産性修正額４０９の多くはマイナスであるため、システム側でマイナスを自動的に付加するようにしても良い。また、雑科目の資産性検討画面11-10-21での入力結果に応じて、資産性修正額４０９の入力内容を自動的に登録しても良いが、この決算の実態登録画面11-10-22にて再度の登録を求めることが好ましい。
計算ボタンＢ７が操作されると、修正額をＢ／Ｓ等に反映させる計算をする。

雑科目の資産性検討画面の入力データ６ｃを自動的に実態登録画面に反映させない理由は、第１に、決算検討作業は営業店担当者のスキル向上にとって重要な作業であるため、コンピュータシステム４ではなく、営業店担当者が計算すべきであり、第２に、雑科目の資産性検討では、内訳を把握し、個々に資産性を検討することが主眼である一方、実態登録では、その検討結果を科目毎に合算する作業である。この２つの手順を営業店担当者が検討し、判断することで、入力内容の正確さ及び精密さを向上させることができ、第３に、二次査定部門や監査部門にて営業店担当者の検討の程度を検証しやすい。
また、条件確認処理２０，Ｃ１２は、この決算の実態登録にて入力した雑科目に関する修正額の絶対値が、雑科目の資産性検討にて資産性なしとした内訳金額４０７よりも少ない際に、エラーを表示し、両画面の整合性を求めるようにしても良い。

営業店担当者は、図４５に示す画面の作業が完了すると、次へボタンＢ１を操作する。タスク処理部１０は、次へボタンＢ１の操作に応じて、計算処理１８，Ｃ６、条件確認処理２０，Ｃ１２及び格納処理２２，Ｃ１３を実行する。そして、次へボタンＢ１の操作に応じて、進捗制御部３０は、作業通番と現タスクＩＤ： T1110とを引数として、進捗ステータステーブル８ａを参照し、現タスクＩＤに作業済を格納する。

進捗制御部３０は、続いて、次タスク特定処理３４を実行する。次タスク特定処理３４，Ｃ２３では、当該作業通番の進捗ステータステーブル８ａを参照して、進捗ステータスが未着手又は作業中のうち、最もタスクＩＤの小さいタスクＩＤを特定する。ここでは、T1120が特定される。タスク開始処理３８，Ｃ２４は、タスクＩＤ： T1120のタスクの開始を制御する。タスク処理部１０は、タスクＩＤ： T1120の画面定義情報７ａを読み出して、端末１に送信する。また、表示制御処理１６は、画面定義情報７ａのフィールドの検索式から、作業データ格納部を検索し、基礎データ６ｂ及び前画面までに入力された入力データ６ｃとを端末１に送信する。端末１では、画面定義情報７ａと受信した作業データ６ａとを合成し、タスクＩＤ： T1120の最初の画面を表示する。

図４６に示す画面ＩＤ：11-20-11の決算検討・決算検討（法人）画面では、前々期の公表と、前期の公表と、今期の公表と、対前期の増減額とを勘定科目毎に表示される。ここでは、流動資産の項目の一部を表示する。この画面にて、前期又は前々期に実態修正されていた際には図４６に示す公表の数値に実態修正されたことを示すマーク等を表示するようにしても良い。また、過去に実態修正されていが、今期実態修正しておらず、その理由を把握できない際には、営業店担当者は、前回内容照会ボタンＢ３８等を操作して前期の内容を確認し、必要に応じて雑科目の資産性検討画面11-10-21に戻って決算検討作業をやり直す。
本実施例では、雑科目の資産性検討として整合性のある判断を入力し、決算の実態登録として整合性のある判断を入力し、さらに、前々期及び前期との関係での整合性を確認した上で、総合的な決算検討を行うことが情報処理により構築された業務プロセスとして強制されている。従って、全ての作業の査定結果は、この手順により判断されたことが保証されている。すなわち、一方向制御により、全ての営業店担当者の判断過程を一定範囲統一し、その判断内容を標準化している。

また、財務項目には、財務分析の知識によって予め定められた「異常」が定義されている。例えば、受取手形や売掛金であれば、その回転期間や売上高の変動比率との関係で一定値以上（未満）の際に異常とし、異常マークを表示して、その異常値についての説明を求めるようにしても良い。

この決算検討画面11-20-11では、異常マークがある際に、システムで自動的に主要アラームコメント２０３を表示する。その他、異常マークについてコメント２０４、当期の業況総評コメント２０５、業況・財務の特徴コメント２０６、赤字・延滞解消の見込みコメント２０７、今後の業況等の見通しコメント２０８を入力する。図中「→」が付されているコメント２０６，２０７及び２０８については、タスクＩＤ： T1600の債務者の概況画面で再度表示するコメントである。これは、強制再表示処理１２であり、営業店担当者は、債務者の概況確認にてコメントの内容が他の判断と不整合と思料する際には、この決算検討（法人）画面までジャンプして戻り、以後の全ての画面を再度確認し再度作業しなければならない。

強制再表示処理１２としては、この決算検討（法人）画面では、実態修正額の欄に修正額を表示し、今期実態金額にこの修正後の金額を表示することで、雑貨目の資産性検討画面及び決算の実態登録画面で入力した数値を再度表示し、公表財務での対前期増減額との関係なども考慮して、決算の実態値が整合しているかの判断を営業店担当者に求めている。この決算検討（法人）画面にて、今期実態値を修正することはできない。今期実態値を修正するには、実態登録画面に戻らなければならない。また、実態登録と、雑科目の資産性検討とは整合していなければならないため、雑科目の資産性検討の作業まで戻らなければ、今期実態値を修正することはできない。

特定操作要求処理２４としては、異常マークが付されているのに、異常マークについてのコメントが何ら入力されていない状態で、次へボタンが操作された際に、当該異常マークについてのコメントの入力を営業店担当者に求めるための表示をするようにしても良い。また、次へボタンＢ１が操作された際に、異常マークについてコメント２０４と、赤字・延滞解消の見込みコメント２０７の２つを拡大表示し、入力されたコメントの整合性の確認を求めるようにしても良い。このように、特定操作要求処理２４は、個々の内容をコンピュータシステム４により条件確認するのではなく、営業店担当者等の作業者に種々の視点を提示することで、作業の整合性を向上させることを求めるのである。すなわち、本実施例では、作業自体を自動化するのではなく、作業の業務プロセスを強制的に一定のものとするための自動化（コンピュータシステム４による情報処理）を行うのである。この自動化が、一方向制御であり、強制再表示処理１２であり、特定操作要求処理２４である。

図４７に示す画面ＩＤ：43-20-00は、図４２や図４６に示す抽出符号照会ボタンＢ３１が操作された際に表示する抽出符号の照会画面である。図中、要注意先抽出符号８２のうち、債務超過先及び赤字先に公表と実態とがあるのは、公表された決算の計数にてそのまま計算した場合と、実態登録後の計数により計算した場合とである。

図４９に示す画面ＩＤ：12-10-05の信用格付・定量的要因評価画面では、営業店担当者が入力する項目はない。ここでは、公表財務計数を使用して、予め定められたスコアリングモデルを適用し、予め定められた一律の計算式により評点又はスコアを算出した結果を表示するものである。このスコアリングモデルは、デフォルト率の実績値との相関等から予測性の高いモデルを継続的に採用するとよい。なお、この信用格付の定量的要因評価の具体的な手法については、数多くの手法が存在する。
営業店担当者は、図４９に表示される内容を確認し、次へボタンＢ１を操作する。

図５０に示す画面ＩＤ：12-30-01の信用格付・一次評価では、スコアリングの結果に応じて一次評価を信用格付（債務者格付）の一次評価として表示する。また、外部格付機関コード４１０や、特定の調査機関の企業番号４１１を入力し、検索ボタンＢ８を操作することで、外部評価を照会することもできる。

図５０までで決算検討作業及び信用格付の一次評価作業が終了し、次に、自己査定作業に進む。
図５１に示す画面ＩＤ13-10-01の取引先の事象チェック画面では、自己査定作業として、まず、要管理先以下の事象チェックを行う。要管理先以下については、コンピュータシステム４による自動的な判断や初期値の表示はほとんど行わず、図５１に示すような文章を表示して、該当するか否かの判断を営業店担当者に促す。営業店担当者は、図５１に示す文章で表される要件を満たすか否かを個々に判断し、該当する事象チェックコード４１２のチェックボックスをオンとする。この事象チェックでは、債務者区分を特定できるように要件を分けて表示することで、正確で均質な債務者区分の判断を促している。

図５２及び図５３に示す画面ＩＤ：13-10-02の自己査定・抽出基準チェック１（債務者単位）では、タスク処理部１０は、抽出基準毎に抽出符号のオン／オフを算出し、自動抽出欄に表示する。営業店担当者は、債務者の現況から抽出基準の該当性を判断し、該当する抽出基準があれば、破綻懸念先以下抽出符号コード４１３，要注意先抽出符号コード４１４，正常先抽出符号コード４１５及び検査・考査符号コード４１６の営業店欄の該当するチェックボックスにオンを入力する。

強制再表示処理１２としては、財務項目から導出される抽出符号がある。例えば、「債」、「赤」、「売」、「過」、「急」、「格」などである。これらの抽出符号の該当が営業店担当者にとって意外であった際には、決算検討の不足が懸念される。
特定操作要求処理２４としては、初期表示した抽出符号を外し、また、初期表示にない抽出符号をチェックした後に次へボタンＢ１を操作した際に、そのチェックの内容の確認を求める画面を表示するようにしても良い。
図５３に示す例では、売上減少との正常先抽出符号８４がオンとなっており、営業店欄にもこのオンが初期値表示される。
また、抽出符号のオン／オフの選択で疎明すべき事情がある際には、疎明資料を電子的に作成し、疎明資料ボタンＢ５を操作して、電子的な疎明資料ファイルをコンピュータシステム４に送信する。

図５４に示す画面ＩＤ：13-10-03の自己査定・抽出基準チェック２-１（貸出金明細）画面では、条件緩和債権に該当する際には、条件緩和コード４１８が表示される。担当者は、与信明細のデータに修正があれば、与信明細修正４１７に修正内容を登録する。担当者はさらに、与信明細毎の抽出符号４１９のオン／オフを判断する。タスク処理部１０は、この画面で与信明細毎の抽出符号がオンとされた際には、債務者単位の対応する抽出符号をオンとする導出データ６ｄを算出する。
画面ＩＤ13-10-04の抽出基準チェック２-２（商手・オフバラ明細）（図示せず）は、商業手形の合算値を表示する。オフ・バランスの明細については、個々の明細毎に表示する。

図５５に示す画面ＩＤ：13-10-05の自己査定・抽出条件確認画面は、確認用の画面であり、抽出基準に関連する画面で入力された入力データ６ｃと、確認された基礎データ６ｂ及び導出データ６ｄを再度表示する。営業店担当者は、内容を再度確認し、抽出基準を修正した際には、すなわち、抽出符号のオン／オフを自動から変更した際には、抽出基準修正コメント２１０にコメントを入力する。

強制再表示処理１２としては、この確認画面にて、抽出符号のオン／オフを入力編集不可の状態で表示する。自己査定作業では、１つのテーマにてチェックすべき項目が多いため、確認用の画面にて入力編集不可の状態で再度表示し、画面内での整合性の判断を再度求めるようにすると良い。

特定操作要求処理２４としては、図５５に示す画面にて次へボタンＢ１が操作された際に、抽出符号のチェックへの操作の有無を確認し、初期値からチェックを外し、例えば、自動抽出にて「赤」とあるチェックを営業店担当者が疎明する情報にてチェックを外し、当該債務者は「赤」に該当しないと判断した際に、抽出基準修正コメント２１０に何らかの文字データが入力されたか否かを確認し、抽出符号への操作があったのに、抽出基準修正コメント２１０に入力が無かった際には、次の画面へ進めないようにしても良い。この抽出基準修正コメント２１０は、債務者の概況画面に強制再表示される。

図５７に示す画面ＩＤ：13-20-02の自己査定・債務者区分確認画面では、債務者区分及び信用格付についての最終的な判断を行う。この画面では、信用格付の一次評価と、抽出基準による債務者区分とを表示する。
事象チェックによる債務者区分は、抽出基準の確認までの判断から導出する債務者区分である。債務者区分判定の欄では、抽出基準による債務者区分が初期値表示されるため、営業店担当者は、債務償還力の確認結果などを考慮して、信用格付一次評価との整合性を検討し、債務者区分及び信用格付を判定する。

債務者区分については、抽出符号の確認結果による債務者区分を債務者区分判定コード４２０として初期値表示する。図５７に示す例では、正常先と表示する。営業店担当者は、債務者の債務者格付を確定し、債務者格付コード４２１を入力する。ここでは、信用格付Ｂを登録する。特定与信格付コード４２２は、債務者単位ではなく、特定の与信を対象とする信用格付のコードである。そして、この債務者区分の判定と整合させた信用格付の判定理由を一覧から選択する。図５７に示す例では、営業店担当者は、信用格付判定理由コード４２３の内容を表示して選択する。
また、営業店担当者は、債務者区分及び信用格付の判定に際して、参考情報照会ボタンＢ４５を操作し、参考情報を照会することができる。

強制再表示処理１２としては、図５７に示す例では、信用格付作業による信用格付一次評価を再表示している。また、抽出符号による債務者区分を再表示している。そして、事象チェックによる債務者区分も表示する。これらの多面的な判断材料を示した上で、債務者区分の入力を営業店担当者に促す。例えば、要注意先抽出符号８２に該当せず、正常先抽出符号８４の「急」にのみ該当し、形式的区分では正常先であるが、債務償還年数が長期で償還力に不安がある際には、要注意先と判定することもある。この場合、実際には、要注意先抽出符号８２の「財」に該当することとなるため、自己査定・抽出基準チェック（債務者単位）に戻るよう促すか、また、強制的に抽出符号の「財」をオンとするようにしてもよい。
また、このケースで、営業店担当者が、債務者が正常先であるとの心証で、決算検討コメントを入力していた際には、決算の実態登録画面に戻り、コメントを修正しなければならない。一方、信用格付と債務者区分の整合性については、最終的な判断をより最終画面に近い画面にて行う。

このように、一方向制御と、強制再表示との組み合わせにより、多面的な判断材料をより終了画面側の画面にて再表示することで、作業の種々の判断を全体的に整合させることを作業者に促すことができる。
そして、この段階での整合的な判断について、コメントの入力を求める。図５７に示す例では、債務者区分・信用格付判定理由コメント２１１の入力を求めている。この債務者区分・信用格付判定理由コメント２１１は、債務者の概況画面に強制再表示する。従って、債務者の概況画面にて、決算検討や債権分類との関係でこの債務者区分・信用格付判定理由コメント２１１記載した文章の根拠となる判断に不整合がある際には、この債務者区分確認画面まで作業を戻さなければならない。

タスク完了処理４０は、コメントの内容のチェックは行わないが、コメントが入力されているか否かのチェックを行う。すなわち、コンピュータシステム４による情報処理としては、文字データが入力されていれば、コメントの入力有りとして、特定操作確認処理２６の条件を満たす。例えば、「あいうえお」という作業としては意味のない文字列であっても、特定操作確認処理２６の条件を満たす。このコメントの適切性については、営業店内の承認権限を有する別の担当者による判断の対象であり、情報処理によりコメントの内容の適切性を判断することはない。情報処理としては、何らかのコメントの入力を必ず求めるという業務プロセスを強制的に構築している。この業務プロセスの強制的な構築により、別の担当者による判断が容易となり、均質・一律な結果を低コストでもたらすことができる。

債務者区分の作業が終了すると、次タスクに進む。ここでは、図５７の特定スキップ有り４２６のラジオボタンを選択することで、保全内容の修正に関する作業のスキップを選択することもできる。すなわち、「優良与信確認以降の画面をスキップする」の特定スキップ有り４２６のラジオボタンを選択し、次へボタンＢ１を操作すると、図５８に示す自己査定・画面スキップ確認画面へ推移する。一方、初期値である「スキップしない」際には、特定スキップ無し４２７のラジオボタンをチェックしておき、次へボタンＢ１を操作すると、優良与信のチェック画面へ推移する。このスキップは、作業分岐３４ａの一例である。

図５８に示す画面ＩＤ：13-30-01の自己査定・画面スキップ確認画面では、画面スキップする内容を表示し、確認を求める。この画面にて、画面スキップを行わないと判断する際には、戻るボタンＢ３を操作して図５７に示す画面に戻る。この画面スキップ確認画面にて、次へボタンＢ１が操作されると、この画面スキップ確認画面のタスク完了処理４０は、特定スキップ処理４８を実行する。この特定スキップ処理４８は、進捗ステータステーブル８ａへの処理としては、この画面スキップ確認画面のタスクの進捗ステータスを作業済とし、次タスクＩＤまでのタスクＩＤの進捗ステータスに作業済を格納する。特定スキップ処理４８は、具体的な分類額等の算出では、債務者区分確認画面までに入力された入力データ６ｃと、基礎データ６ｂとを使用して、分類額の算出を行う。
なお、画面スキップしない際には、画面スキップ確認画面の進捗ステータスが省略となる。

債務者区分の判定が完了すると、続く画面では、分類額の算出を行う。
図５９に示す画面ＩＤ：13-31-01の自己査定・優良与信チェック１（商手明細）画面では、債務者に支払われた商手の一覧又はその一部を表示する。支払人が銀行の融資先である際には、ＣＩＦ番号と、債務者区分とを表示する。支払人が取引先でない際には、信用照会の結果を表示し、また、企業番号４１１を入力して、評点を検索し、表示させる。このような画面構成は、債権譲渡等を保全とする与信の確認にも利用できる。
図５９に示す例では、優良与信を認定するために商手の一覧を表示するが、振出人が破綻懸念先以下であるなど、決済懸念がある商手の確認を行うようにしても良い。また、支払場所や、金額も表示するため、信用リスクの高い兆候となる融通手形となっているか否かの判断にも役立つ。ここで融通手形を発見した際には、その金額の影響を検討し、必要であれば、決算検討に戻るか、抽出符号にて「財」を付するなど再度の作業が必要となる。

画面ＩＤ：13-31-02の優良与信チェック２（買入外為）（図示せず）では、別枠買入外為明細を全て優良与信として初期値表示する。営業店担当者は、明細の表示内容を確認の上優良与信の対象外のものは優良与信ではないとしてチェックボックスをオフにする。

図６０に示す画面ＩＤ：13-31-03の自己査定・優良与信確認画面では、商手と別枠買入外為についてチェックした内容を強制再表示処理１２する。優良与信を修正した際には、そのコメントを優良与信修正コメント２１２に入力する。

画面ＩＤ：13-32-01、02、03、04で示す担保・保証チェック（図示せず）では、貸出金明細（13-32-01）、商手・オフバラ明細（13-32-02）、優良の根担保・根保証（13-32-03）、一般の根担保・根保証（13-32-04）について担保の種類、評価額、保全額、保全内容、処分可能見込額等を入力する。

図６１及び図６２に示す画面ＩＤ：13-32-05の担保・保証確認画面では、チェック画面にて入力し、確認したデータを強制再表示処理１２する。優良担保保証について修正点があれば、優良担保保証修正コメント２１３を入力し、保証人による一般保証について回収可能と見込む際にはその理由を保証人回収可能理由コメント２１４に入力し、一般担保保証について修正点があれば一般担保保証修正コメント２１５に入力する。このコメント２１３、２１４及び２１５は、この確認画面ではなく、チェック画面にて入力を促すようにしても良い。

図６３に示す画面ＩＤ：13-39-01の自己査定・基礎査定額確認画面では、優良与信と、担保・保証について確認し、入力したデータから、分類対象外債権の額及び基礎査定額を導出し、表示する。基礎査定額は、与信残高から、優良与信等の分類対象外債権の額を減額したものである。自己査定では、債務者区分と一般担保等に従って、この基礎査定額を分類する。営業店担当者は、この画面で基礎査定額等を確認し、修正があれば画面を戻って再度作業する。

図６４及び図６５に示す画面ＩＤ：13-59-01の自己査定・償却予定額計算画面では、債務者区分が破綻懸念先以下である際には、優良担保・保証の内容と、一般担保・保証の内容とから、償却予定額が表示されるため、確認する。

図６６及び図６７に示す画面ＩＤ：13-59-09の分類結果確認画面では、債権の科目毎に分類額が表示されるため、内容を確認し、自己査定全般に関して特記すべき事項があれば、自己査定特記事項コメント２１６に入力する。
図６８に示す画面ＩＤ：15-00-01の管理・回収方針画面では、債務者区分が要注意先以下の際に管理回収方針コメント２１７を入力する。

図６９及び図７０に示す画面ＩＤ：16-00-01の債務者の概況画面では、取引先要項システム７４から読み出した動向コメント２２２と、決算検討作業での各種のコメントと、自己査定作業の結果とを強制再表示処理１２する。具体的には、図４６に示す画面ＩＤ： 11-20-11の決算検討（法人）画面にて入力する「業況・財務の特徴コメント２０６」と、「赤字・延滞解消の見込みコメント２０７」と、「今後の業況等の見通しコメント２０８」とを債務者の概況画面にて強制再表示処理１２する。また、図５７に示す画面ＩＤ：13-20-02の債務者区分確認画面にて入力する「債務者区分・信用格付判定理由コメント２１１」を債務者の概況画面にて強制再表示処理１２する。

図６９にて、業況・財務の特徴コメント２０６に、決算年月２０１１／６とあるのは、このコメントが当該債務者の決算年月での公表財務に基づいてコメントされたものであることを示す。一方、抽出符号については、起動理由「状況速報」とあり、この抽出符号は、状況速報による作業時に当該抽出基準に該当すると判断されたものであることを示す。

また、図６９の債務者の概況画面にて、取引の経緯テーブルは、取引先要項システム７４の図７４に示す要項ＩＩ画面の取引の経緯の一部を抽出し、表示したものである。この債務者の概況画面での取引の経緯に抽出するのは、主要動向区分４３０が、当行融資取引開始、創業、法人成り、改組、Ｍ＆Ａ、事業の展開・変動、金融取引の異動である動向コメント２２２である。

この債務者の概況画面の表示を使用して、各タスクの作業結果について、相互に矛盾がないか作業の全体的な整合性を確認する。また、状況速報にて起票された際には、変化の要因コメント２１８と、変化に対する対応と見通しコメント２１９とを入力する。貸出条件緩和債権を有する債務者については、その補足説明コメント２２０を入力する。この債務者の概況画面16-00-01の作業が完了すると、作業のすべてが完了となる。

債務者の概況画面にて、新たに入力するコメント欄としては、変化の要因コメント２１８と、変化に対する対応と見通しコメント２１９と、補足説明コメント２２０とがある。「変化の要因」は、決算検討時の自己査定作業による判断の後、業況の変化などによって債務者の信用リスクが変化した際に、その変化の要因を記載する。変化に対する対応と見通しは、その変化への対応と見通しである。従って、この２つのコメント２１８，２１９は、決算検討時の格付自己査定作業では使用せず、状況速報による作業にて使用する。

図７１に示す画面ＩＤ：19-00-00統括者指定画面は、ワークフロー用の画面である。次にフロー可能な先が人名のリストとして表示されるため、営業店担当者は、次フロー先を指定して、統括者へボタンＢ１を操作する。

図７２に示す画面ＩＤ：21-00-00は、営業店統括者・承認画面である。この画面は、サマライズ画面ともいう。サマライズ画面では、営業店担当者が作業した結果を、決算検討作業、信用格付作業、自己査定作業及び管理・回収方針作業に分けて要約を表示する。この要約では、重要なコメントを表示する。営業店統括者は、図中右上の登録内容全照会ボタンＢ４３の操作により全ての確認画面をチェックすることができる。また、営業店統括者は、このサマライズ画面に表示される営業店のコメントを修正することができる。営業店の統括者は、承認ボタンＢ１を操作することで、この作業を支店長に回付する。また、営業店担当者の検討不足を発見し、差し戻す際には、差戻しボタンＢ４４を操作する。

図７３に示す画面ＩＤ：20-10-00の差戻し理由登録画面は、差戻しボタンＢ４４の操作によって表示される。差戻しを行う主体は、差戻し理由コメント２２１に文章で差戻し理由を入力し、差戻し先４２８の担当者を指定して、差戻しボタンＢ４４を操作する。差戻し先４２８の担当者の一覧は、進捗ステータステーブル８ａ等から自動生成する。その担当者のメイン画面に当該作業が表示される。

上述したように、営業店担当者は、一方向制御の下、次々と画面を表示させることで、作業を行うことができる。そして、個々の画面に表示された項目間の整合性を各画面で判断しつつ、より終了画面側の画面にて、逐次、その画面までの作業の全体の整合性を判断する。作業の全体の整合性に疑義がある際には、検討不足の画面まで戻り、再度、戻った画面以降の画面による作業を行う。例えば、債務者の概況画面にて、決算検討のコメントと、自己査定の債務者区分との関係が整合していない際には、決算検討画面まで戻り、再度コメントを入力し直さなければならない。そして、信用格付作業及び自己査定作業等の一切を再度作業する。決算検討画面に戻ってコメントを修正する際には、財務項目の数値を読み間違ったか、または、財務項目の実態値の検討不足である。財務項目の実態値を修正すると、抽出符号が変化し、また長期債務償還力が変化する可能性がある。従って、債務者の概況にて決算に関するコメントが自己査定と整合しない際には、全ての作業をやり直すこととなる。このような作業のやり直しは、煩雑で、時間を要し、営業店担当者にとっては避けたい事項である。従って、決算検討をより適切に行うための知識と理解とを早期に得ようとする。これにより、営業店担当者の早期習熟を促す。また、熟達者にとっても、多数の条件が複雑に関連する作業を多数の債務者について一時期に大量に処理する際に、一方向の画面の推移という業務プロセスを経ることを情報処理として強制しているため、単純なミスの発生を防止することができる。

＜強制再表示１２後の戻り事例＞
次に、強制再表示処理１２等に応じて、作業者が信用リスク管理の深淵を発見し、画面を戻り、再作業する例を説明する。
・戻り事例１： 信用格付作業から決算検討に戻る。
１．１ 営業店担当者は、図４９に示す画面ＩＤ： 12-10-05の定量的要因評価（法人）画面にて定量的要因を評価する際に、長期債務償還年数や、インタレスト・カバレッジ・レシオなどによる債務償還力が前期より悪化していることを見いだした。この債務償還力の悪化から、今期設備投資の過大と、手元流動性の悪化とを懸念し、図４５に示す画面ＩＤ：11-10-22の決算の実態登録画面に戻った。具体的には、進捗フローＢ２の決算検討をクリックすることで個々のタスクを開き、そのうちの決算の実態登録をクリックすることで、図４５に示す画面まで戻った。再度の決算検討によると、関連会社への投資の資産性を懸念し、事情確認のところ、関連会社の業績悪化で配当がなく、インタレスト・カバレッジ・レシオが悪化していた。このため、当該関連会社への投資の評価損を見積もり、実態登録した。その結果、自己資本比率等が悪化した。このため、自己査定作業中の債務償還力による検証を重視することとした。
なお、ジャンプして戻る戻り先を画面単位ではなくタスク単位とする際には、図４９に示す画面から決算の実態登録に戻る際には、決算検討の当初のタスクである図４４に示す雑科目の資産性検討画面に戻ることとなる。

１．２ 図５０に示す画面ＩＤ： 12-30-01の信用格付一次評価にて、外部格付機関の格付が低く、実態検討不足を懸念し、図４６に示す決算検討（法人）画面まで戻り、異常マークの付された項目を再検討した。その結果、売上の減少と棚卸資産の増加を看過できず、棚卸資産回転率を確認したところ、時系列及び業種平均との比較において不自然で、棚卸資産の不良資産化を認定した。その理由は必ずしも明らかではないが、さらに決算の実態登録画面まで戻り、理由不明としつつ、実態修正した。この結果、債務償還力検証式の固定資産対応負債額の修正必要額（ツ）が増加し、長期債務償還年数が長期となり、その他総合判断により、要注意先となった。

・戻り事例２： 自己査定作業から戻る。
２．１ 図５２及び図５３に示す画面ＩＤ： 13-10-02の自己査定・抽出基準チェック１（債務者単位）画面にて、「売」の抽出となっており、決算検討時の売上高増減コメントとの整合性が脆弱となった。このため、決算検討を再度行うこととして、当期の業況総評コメント２０５や、今後の業況等の見通しコメント２０８を修正するために、画面ＩＤ： 11-20-11の決算検討（法人）画面に戻った。

２．２ 図５２及び図５３に示す画面ＩＤ： 13-10-02の自己査定・抽出基準チェック１（債務者単位）にて、「急」の抽出となっており、純利益の減少及び他行借入増加で、当行債権が実質的かつ結果的な利貸しとなっていることが懸念された。利貸し先をチェックし、対応する金額分、債権に使途条件問題を指定した。そして、「業況・財務の特徴コメント２０６を修正するために、決算検討（法人）画面に戻り、あわせて、資産性を再検討したが、資産の評価損を見いだすことはできず、実質債務超過の懸念があるものの、確認できなかった。債務償還力では通常の償還年数となるものの、キャッシュ・フローが大幅に悪化しており、財務内容要注意として、要注意先に区分した。今後の管理では、遊休資産の売却や増資等が急がれる旨のコメントに修正し、今後の管理に注意することとした。

２．３ 自己査定・抽出基準チェック１（債務者単位）画面にて、「赤」、「売」等で抽出されたが、財務内容の問題ないと判断し、正常先とした。しかし、赤字・延滞解消の見込みのコメントと、正常先と判定する理由のコメントとの整合性に難があり、決算検討（法人）画面に戻り、赤字・延滞解消の見込みコメント２０７を修正し、再度作業をした。

２．４ 自己査定・抽出基準チェック１（債務者単位）画面にて、「株（低株価先）」で抽出され、低株価先であることを把握していなかったため、決算検討作業に戻り、異常マークを再検討し、実態修正したところ実質債務超過の懸念が認められた。長期負債償還年数は減価償却期間の倍となっており、処分可能な固定資産も認められず、抜本的な経営改善計画の作成が必要と判断し、作業を当初からやり直すこととした。

２．５ 図５９に示す優良与信チェック１（商手明細）画面にて、商手の支払人が割引後に破綻懸念先となっていて、金額が大きいため、決算検討作業に戻り、受取手形の精査をしたところ融通手形であると判明したため、対象の受取手形の全額を控除した。その結果、財務内容問題先での要注意となった。

２．６ 正常先抽出符号８４で抽出され、図６１、図６２等に示す担保・保証確認画面にて個々の債権を精査したところ、事業利用している不動産の担保評価額が大幅に減少していることを発見した。評価損が大きいため、決算検討に戻り、固定資産の評価損を実態登録した。しかし、実質債務超過とはならなかったため、正常先との判断を維持した。

２．７ 図６９及び図７０に示す画面ＩＤ： 16-00-01の債務者の概況画面で、各コメント間の整合性に欠ける部分が認められたため、決算検討コメント及び債務者区分・信用格付判定理由コメント２１１を修正するために決算検討画面に戻った。

上述のように、一方向制御による業務プロセスでは、何らかの修正を行う際には、その画面まで作業対象を戻し、作業を戻した画面から再度行わなければならない。特に、決算検討時のコメントに不備があると、すなわち、決算検討不足の際には、再作業に長時間を要することとなる。このため、不慣れな担当者は、決算検討時のコメントの修正や、実態登録の再作業を行う毎に、決算検討時に注意深く検討する方が、結果的に短時間で作業を完了することができることを体感する。これにより、決算検討に必要なスキルの向上を早期に促すことができる。

＜事例を参照した各処理の詳細＞
次に、具体的な事例を参照して、営業店担当者の作業と、情報処理内容とを説明する。事例は、仮想的な下記のものである。
・Ａ社（事例１，図４４から図５８）： 決算検討で流動資産の実態を登録する。「売」の抽出符号にて抽出され、債務償還力を検証したところ、債務償還力有り、正常先とした。
・Ｂ社（事例２及び事例３，図５９から図６８）： 赤字先で、債務償還力確認式にて業種相当外の年数となり、要注意先であり、ＩＩ分類額を算出する。
・Ｃ社（事例４，図４１、図６９から図７４）： 民事再生手続申立につき、状況速報による手動で作業を起票し、破綻先とする。

［事例１：Ａ社］
例１： 図４０を参照すると、本システムにログインした営業店担当者である作業者１には、Ａ株式会社が振り分けられている。Ａ株式会社の作業の進捗状況は担当者作業待ちである。作業者１（以下、「営業店担当者」という）は、Ａ株式会社の選択にチェックをし、作業開始ボタンＢ１を操作する。すると、進捗制御部３０は、タスク開始処理３８として、次タスクＩＤをT1000と特定する。そして、タスク処理部１０の表示制御処理１６は、タスクＩＤがT1000の基礎データ６ｂと、画面定義情報７ａとを端末１に送信する。端末１は、図示しない作業開始確認画面を表示し、続いて、図４２に示す作業要否選択画面を表示する。営業店担当者は、作業要否選択画面にて作業要否判定コード４０３が要の状態で当該画面の次へボタンＢ１を操作する。進捗制御部３０及びタスク処理部１０は、同様に、図４３に示すタスクＩＤがT1100の決算検討作業選択画面を表示する。Ａ株式会社は決算検討作業を行うため、営業店担当者は、決算検討作業を選択し、この画面の次へボタンＢ１を操作する。

タスク処理部１０の表示制御処理１６は、図４４に示す雑科目の資産性検討画面を表示する。営業店担当者は、財務諸表や附属明細から、まず、Ａ株式会社の短期貸付金20,000（単位千円、以下同じ）の全額の貸付先が（有）第１○○社であることを把握し、この（有）第１○○社の業況を調査した。その結果、第１○○社は業況が悪化しており、貸付金が返済されない可能性が高いとして、内訳金額20,000の全体の資産性をなしと入力した。また、未収入金85,000については、（株）第２○○社からの未収入金につき、第２○○社の業況芳しくないことから、回収できない可能性が高いとし、第２○○社からの未収入金40,000の資産性をなしと評価した。（株）第３○○社の20,000や、残額の25,000については資産性有りと評価した。
同様に、その他流動資産や、投資などの項目の内訳を把握し、それぞれの資産性を評価する。このような雑科目としては、繰延資産等がある。

また、Ｐ／Ｌに関しては、雑収入、雑損失、特別利益、特別損失について、その内訳金額４０７と、雑科目明細４０８と、雑科目資産性・査定根拠コメント２０１とを臨時損益混入として実態を把握し、登録する。
雑科目の資産性の検討が終了すると、営業店担当者は、この画面の次へボタンＢ１を操作する。タスクＩＤがT1110である決算検討タスクは、この画面と、次の決算の実態登録画面とを有するため、この次へボタンＢ１の操作があると、端末１は、コンピュータシステム４へアクセスせずに、すでに受信した画面定義情報７ａと作業データ６ａとにより、図４５に示す決算の実態登録画面を表示する。

営業店担当者は、図４５に示す公表財務データの科目毎に、資産性を検討した修正額を合計し、登録する。修正額の欄では、数値を入力すると、マイナスを自動的に付加するようにしても良い。
異常マークの付された売掛金について精査し、（有）第４○○社向け売掛金60,000を第４○○社の業況悪化により控除した。
さらに、未収入金については、公表金額85,000に対して、第２○○社からの未収入金40,000の資産性をなしとしたため、40,000との数値を当該欄に入力し、マイナス40,000を登録する。そして、その実態修正コメント２０２として、第２○○社との文字を入力する。同様に、他の科目についても修正額の登録を行う。Ｐ／Ｌについても、臨時損益等の検討結果を反映させる。なお、流動資産で減算した修正額については、その合計額を資本剰余金から減算することで、実態財務のバランスを得る。この資本剰余金からの減算は、図４５に示す計算ボタンＢ７が操作された際に、計算処理１８が自動的に計算するようにしても良い。

営業店担当者は、決算の実態登録が完了すると、次へボタンＢ１を操作する。すると、タスク処理部１０は、まず、条件確認処理２０を実行する。例えば、雑科目の公表金額と、その内訳金額４０７の合計額とを比較し、不一致の場合には条件を満たさないとして端末１にエラー表示するようにしても良い。また、公表金額の絶対値よりも修正額の絶対値が大きい場合には、エラー表示するようにしても良い。合計金額の算出等が必要な場合には、条件確認処理２０の一部として、計算処理１８を実行する。この計算処理１８により、資本剰余金からの減算額が再度計算され、最新の状態となる。

サーバー４Ａは、図４５に示す次へボタンＢ１を操作に応じて、図１８、図１９、図２７及び図２８に示す情報処理を実行することで、営業店担当者の端末１の画面に図４６に示す決算検討（法人）画面を表示制御する。営業店担当者は、前々期から今期までの公表財務データと、対前期増減額と、財務比率による異常マークの有無と、実態修正額の登録の有無と、今期実態金額とを参照して、決算検討コメント（２０３，２０４，２０５，２０６，２０７及び２０８）を登録する。主要アラームコメント２０３については、異常マークの有無（及び程度）に応じて予め準備したコメントを自動的な表示とし、入力を不可としても良い。

図４６に示す例では、例えば、売掛金の欄に、異常を示すアスタリスクが付されており、さらに、実態修正額が登録されている。これは、前画面にて売掛金245,000のうち、（有）第４○○社向け売掛金60,000を控除したため、その実態の金額は、公表財務データの245,000から60,000を減額し、185,000となる。また、売掛金の今期公表は、前期公表の50,000と比較して、195,000のプラスと、３倍以上に急激に増加している。主要アラームコメント２０３を参照すると、売上高急減、売掛金急増とのコメントが表示されている。担当者は、この売掛金急増について当社にヒアリングをして異常マークについて２０４にコメントを記入し、また売掛金の実態修正の内容についても当該コメント欄に記入する。

未収入金については、今期の公表財務データは85,000で、第２○○社からの未収入金40,000を実態修正額とし、今期実態金額は45,000となっている。そして、営業店担当者は、業況・財務の特徴コメント２０６では、この40M（40,000）は同社（第２○○社）の業況思わしくなく資産性なしとした旨を記載した。その他、実態財務に基づいて、財務分析と将来予測とを合理的に行い、それぞれのコメントの項目につき、営業店担当者の所見をコメントする。

営業店担当者は、この決算検討（法人）画面にて、強制再表示処理１２された今期実態の財務計数が、不自然である際には、前回内容照会ボタンＢ３８等を操作し、その理由を検討する。実態登録を修正すべきであると判断した際には、雑科目の資産性検討画面等に戻って作業をやり直すこととなる。なお、雑科目の資産性検討画面では、前回内容の照会や、前回内容の取り込みができるため、営業店担当者は、雑科目の資産性検討に関し、前回までの判断を参照して作業しておけば、図４６に示す画面から戻って再作業するという手間を発生させることがない。この一方向制御と、再表示により総合的な確認を求める業務プロセスにより、営業店担当者の早期の習熟を促すことができる。

営業店担当者は、決算コメントの登録が完了すると、次へボタンＢ１を操作する。コンピュータシステム４は、図４９に示す定量的要因評価（法人）画面を端末１に表示する。営業店担当者は、この画面にて入力すべき項目はない。固定負債対有形固定資産比率等の評価指標は、前画面までに確認した公表財務計数からタスク処理部１０が導出した導出データ６ｄである。タスク処理部１０の表示制御処理１６は、それぞれの評価指標の数値を作業データ格納部から読み出し、または元の公表財務計数を読み出して財務比率を算出し、端末１に送信する。
格付は、評点やスコアの小計から、Ａ，Ｂ，Ｃ等の信用格付の値とするものである。
営業店担当者は、続いて、図５０に示す画面にて、Ａ株式会社の信用格付の一次評価を確認する。

信用格付作業が完了すると、営業店担当者は、自己査定作業を行う。図５１に示す例では、要管理先、破綻懸念先、実質破綻先及び破綻先の判断を行うために、事象をチェックする画面である。営業店担当者は、Ａ株式会社では、図５１に示す事象は生じていないため、何も入力せず、次へボタンＢ１を操作する。

Ａ株式会社は、図５２の要注意先抽出符号８２のオンには該当していない。すなわち、オンラインシステム７２に延滞は登録されておらず、実態財務では黒字であり、債務超過を伴ってはいない。図５３は、図５２に示す画面をスクロールした際の下側の画面である。図５３に示すように、Ａ株式会社は、予め定められた比率より大きく売上の減少があり、正常先抽出符号８４の「売」にて自動的に抽出されている。そして、営業店担当者の欄には、「売」のチェックが初期値表示されている。営業店担当者は、図４６に示す決算検討の段階で、売上の減少を認識しており、売上の減少後の今後の業況等の見通しについても利益率の高い受注の伸びに着目したコメントを記載しているため、「売」での抽出は認識済であり、他の抽出符号に該当していないことを確認し、次へボタンを操作する。

図５４に示す画面では、貸出金明細単位に、抽出基準に該当するか否かを確認する。与信明細等の詳細の記載は省略しているが、また、開示債権や、条件緩和は、債権を単位とした判断であり、延滞についても、債権に生じる事象であるため、営業店担当者は、債権毎に、抽出基準に該当するか否かを確認する。例えば、与信明細毎に貸出条件等を確認し、実質的な貸出条件緩和債権となっているか否かなどを判断する。Ａ株式会社については、抽出基準や問題与信債権に該当する債権がなく、営業店担当者は、次へボタンＢ１を操作する。

図５５は、抽出条件確認画面であり、抽出基準のチェック画面（画面ＩＤ： 13-10-01,13-10-02,13-10-03,13-10-04）にて確認し、入力した内容をこの図５５に示す確認画面（画面ＩＤ： 13-10-05）に強制再表示処理１２により表示している。タスク処理部１０又は端末１は、債権毎の抽出符号のチェックがあった際には、対応する債務者単位の抽出符号をオンとする。営業店担当者は、Ａ株式会社は、抽出符号を初期値から修正していないため、抽出基準修正コメント２１０は入力せずに、次へボタンＢ１を操作する。

図５６に示す債務償還力の確認画面では、債務償還力確認式の計算の過程及び結果を表示している。固定資産は、公表財務の数値である。修正必要額ツは、図４５の流動資産の資産性検討の修正額の合計の絶対値であり、図４５の＜流動資産計＞実態修正額に示すように、Ａ株式会社の今期については120,200である。債務償還力確認式では、自己資本から、流動資産中の不良資産の額を減算する。図４５に示す例では、170,200から、この修正額の絶対値120,200を減算する。すると、50,000となる。この50,000は、実態の自己資本である。そして、固定資産対応負債額は、公表固定資産から、実態自己資本を減算するから、公表固定資産＋公表繰延資産510,000から、実態自己資本50,000を減算する。すると、固定資産対応負債額は、460,000となる。

当期純利益は当社の税引き後の利益額であり、要修正額は、臨時損益の混入等の実態を調整するもので、減価償却額は、公表減価償却額である。要修正額は、臨時損益や減価償却不足を振り替えた特別利益・特別損失の実態値であり、決算検討・雑科目の資産性検討画面11-10-21で検討し、決算の実態登録画面11-10-22画面で確認した内容である。
この当期純利益（ト）、要修正額（ナ）及び減価償却額（ニ）を二期分合計して一期の平均値を計算することで、Ａ株式会社の１年分の償還可能額を求めると、50,000となった。固定資産対応負債額（テ）をこの償還可能額（ヌ）で割ると長期債務償還年数を求めることができ、9.2年となる。この9.2年は、概ね正常先と判断できる15年以内を超えないため、債務償還力有りと判定できる。 この概ね正常先と判断できる償還年数は、業種によっては、さらに10年加算して25年となる。

また、図５６に示す例では、有利子負債償還年数の計算結果を参照することで、多面的な判断を促すことができる。有利子負債償還年数と、長期債務償還年数との年数との乖離が著しい際には、担当者は、決算検討の実態登録が適切であったか等を再検討する。
図５６に示す流動資産の実態である修正必要額（ツ）と、臨時損益や減価償却不足その他特別利益・特別損益への振り替える損益の実態である要修正額（ナ）の値が整合的ではない場合、雑科目の資産性検討画面11-10-21に戻り、決算コメントも入力し直し、自己査定作業をやり直すこととなる。
なお、図５６に示すように、実態債務超過がある先についての判断材料として、債務超過償還解消年数を計算し、表示するようにしても良い。
図５６に示す各財務計数は、公表財務計数と、実態財務計数とが入り交じっている。実施例によっては、実態財務登録がされた計数については、実態財務登録がされた数値による旨が画面表示上簡易に判明するようなマークを表示したり、公表財務の数値に対する実態財務の比率を参考情報として表示するようにしても良い。

また、中小企業等で法人・個人の一体判断を行う先や、公表財務データが粉飾されており通常の実態バランス修正では対応できないような場合には、債務償還力確認式を組み込んだ表計算ソフトウエア用のファイルなどに数値を入力し、計算して疎明資料として添付すると良い。

決算検討の実態バランス修正と、債務償還力確認式の計算結果により、営業店担当者は、Ａ株式会社については、実態バランスの修正後、長期債務償還力あり、正常先と判定した。また、保全内容の修正もないため、特定スキップ有り４２６のラジオボタンをチェックし、次へボタンＢ１を操作すると、図５８に示す画面が表示され、図６８に示す管理・回収方針画面へ進む。正常先であるため管理・回収方針は記入せず、図６９及び図７０に示す債務者の概況を確認して、作業を終了し、図７１に示す画面にて営業店の統括者の名前を特定し、当該作業を特定した統括者に電子的に回付する。

［事例２：Ｂ社］
例３： Ｂ株式会社は、要注意先であるとする。営業店担当者は、Ｂ株式会社の作業をメイン画面で選択し、決算検討作業を行い、信用格付作業を行い、債務者区分の判定を作業する。そして、債務者区分を登録し、図５７に示す債務者区分確認画面で画面スキップしないを選択すると、まず、図５９に示す優良与信チェック１（商手明細）画面となる。

商手は、図５９に示す支払人名の支払人から、Ｂ株式会社に支払われたものである。支払人は、当行（格付自己査定を実施する金融機関）の取引先である場合と、取引のない場合とがある。図５９に示す例では、当行取引先の商手支払人については、ＣＩＦ番号を表示し、融資取引が有れば、最新の債務者区分を表示する。例えば、（株）乙であれば、当行前月債務者区分は正常先である。乙が正常先であるから、乙が振りだした商手に決済懸念はない。甲製作所は、当行取引先ではないため、企業番号４１１を用いて、信用照会を行う。信用照会の結果、決済懸念なしである。従って、Ｂ株式会社の商手に決済懸念はなく、全て優良与信である。

営業店担当者は、次へボタンＢ１を操作して、画面ＩＤ： 13-31-02の優良与信チェック２（買入外為）画面（図示せず）に進む。この画面では、当初貸出日や、期日や、延滞の有無や、使途内容を表示し、優良与信の対象外の案件の選択を営業店担当者に促す。営業店担当者は、優良与信であるか否かを判断し、優良与信又は優良与信でないものを特定する登録をして、次へボタンＢ１を操作する。Ｂ株式会社は、別枠買入外為がないため、何ら操作を行わずに、次へボタンＢ１を操作する。

優良与信に関するチェック画面での作業が完了したため、確認画面が表示される。すなわち、端末１は、図６０に示す優良与信確認画面を表示する。Ｂ株式会社に関して、優良与信は修正していないため、優良与信修正コメントにはなんら登録を行わず、次へボタンＢ１を操作する。

次に、担保・保証のチェック及び確認を行う。担保・保証のチェック画面（13-32-01, 13-32-02, 13-32-03, 13-32-04）では、与信明細、オフ・バランス、根担保・根保証について基礎データ６ｂを画面表示する。営業店担当者は、自動計算される評価額や処分可能見込額を確認し、修正する際には、営業店欄に修正額を登録する。担保・保証のチェック作業が完了すると、図６１及び図６２に示す確認画面に至る。営業店担当者は、チェック又は入力した数値を確認し、問題なければ、次へボタンＢ１を操作する。なお、評価額と処分可能見込額とは、担保・保証の種類によって予め定められた掛け目を評価額に掛けることで、保守的な処分可能見込額を合理的に見積もる。

本実施例では、図６２に示すように一般担保・一般保証のチェック・確認を行う。要注意先の債権は、一般担保・保証の有無や内容に関わらずＩＩ分類となるため、債権分類では、要注意先について一般担保・一般保証の内容の精査は必ずしも求められてはいない。信用リスク管理として、保全状況を管理し、回収率を統計的に扱う等の要請のため、優良担保・保証と共に、一般担保・保証のチェック・確認を行うと良い。
一般担保等の確認もするため、本実施例では、要注意先が仮に破綻懸念先となった際に不良債権残高にどのような影響を与えるかを営業店担当者に知らせることができる。
一般保証のチェック画面では、保証人の信用格付・債務者格付を表示して確認するようにしてもよい。
優良担保・保証や、一般担保・保証について初期表示した内容を修正した際には、チェック画面又は確認画面にて、優良担保保証修正コメント２１３や、一般担保保証修正コメント２１５の入力を促す。

与信残高のうち、優良与信と、優良担保付の与信と、優良保証付の与信とは、分類対象外である。与信残高から分類対象外債権の額を減算した額が、基礎査定額である。図６３に示す基礎査定額確認では、与信の科目毎に、基礎査定額を確認する。なお、要注意先以下の債務者区分に分類されたが、全てが分類対象外債権で、分類額がないこともある。
図６３に示す例では、与信残高から優良与信等の分類対象外債権を減額した基礎査定額は、5,170となった。

図６４及び図６５は、要注意先判定・（破綻懸念先以下の場合の）償却予定額計算画面である。要注意先については、この画面で債務者区分を再確認し、Ｂ社が仮に破綻懸念先や（実質）破綻先である際の償却予定額となる仮定の金額を表示する。

図６６は、分類結果の確認画面である。Ｂ株式会社は要注意先であるため、与信残高は、非分類額と、ＩＩ分類額とに分類される。例えば、貸出金８，２００に関しては、ＩＩ分類額が４，６００で、非分類額が３，６００である。
また、貸倒引当金に対応する期待損失ＥＬ額を別途計算し、対比用に表示するようにしても良い。

［事例３：Ｂ社（破綻先の場合）］
図６７は、Ｂ株式会社が仮に破綻先である際の分類結果である。破綻先の場合には、一般担保、保証の内容との関係で、非分類額と、ＩＩ分類額と、ＩＩＩ分類額とＩＶ額とに分類する。この例では、非分類５，８００，ＩＩ分類３，１２０、ＩＩＩ分類１，４５０、ＩＶ分類６００となった。

債権の分類が完了すると、図６８に示す管理・回収方針等を登録し、債務者の概況を確認し、作業を統括者に電子的に回付することで、Ｂ株式会社の作業が完了する。

［事例４：Ｃ社］
Ｃ株式会社は、２０１１年６月の決算登録時には、破綻懸念先であったが、主要受注先からの受取手形が不渡となり、資金繰りが逼迫し、２０１２年１月に民事再生手続の申立となった事例である。民事再生の申立という情報を取得した営業店担当者は、まず電話等で与信管理の担当者等へ報告し、火急の作業を完了させた後、取引先要項システム７４に法的手続の申立を動向コメント２２２として登録する。例えば、図７４に示すように、２０１２年１月２０日付けで、主要動向区分を法的手続申立として、民事再生申請と登録する。

続いて、Ｃ株式会社の作業を状況速報として起動する。例えば、図４０に示すメイン画面にて、状況速報ボタンＢ１１を操作する。進捗制御部３０は、次タスクＩＤとしてT0200を指定するため、表示制御処理１６は、図４１に示す状況速報起動画面を端末１に表示させる。営業店担当者（ここでは、本店営業部の担当者）は、Ｃ株式会社のＣＩＦ番号を入力し、登録ボタンＢ１を操作する。すると、図４１に示す融資先番号、取引先名及び主担当店が表示される。営業店担当者は、状況速報起動理由コード４００として取引先の業況変化を選択する。

営業店担当者は、図４１に示す状況速報起動画面にて、変化の理由コード４０１（又は主要動向区分４３０）として、法的手続申立を選択し、業況変化の詳細内容コメント２００として、「H24.1.20 民事再生手続申立（主要取引先からの受取手形が不渡となり資金繰りが逼迫）」を入力する。状況速報では、決算検討作業及び信用格付一次評価作業は行わず画面表示のみとし、自己査定作業を行う。図５１に示す取引先の事象チェックにて、図示しない民事再生手続申立にチェックをする。図５２に示す抽出基準チェックでは、担当者は、事象チェックにより、「破」、「開」、「債」、「条」、「金」、「日」、「自」、「管」、「売」、「グ」を抽出する。債務者区分確認画面にて債務者区分を判定し、破綻先に応じた信用格付とする。図５７はＡ株式会社についての事例を開示しているが、民事再生手続を申し立てたＣ株式会社について図５７に示す債務者区分確認画面を操作する際には、担当者は、法的整理に該当４２４のチェックボックスをオンとする。この法的整理に該当コードがオンとされると、計算処理１８は、本画面以降のタスクにて法的整理先である際の分類額の算出手法を適用する。
債務者区分及び信用格付を判定し、担保・保証等をチェックし、確認すると、続いて、債務者の概況画面が表示される。

図６９に示すように、債務者の概況画面では、図７４に示す動向コメント２２２のうち、事業の展開・変動等に該当する動向コメント２２２を読み出して表示する。業況・財務の特徴コメント２０６は、直近決算登録時のコメントである。状況速報では、決算登録時のコメントをそのまま表示する。自己査定の抽出基準、分類算式、債務者区分については、状況速報による今回の作業の内容を強制再表示処理１２している。

図７０の符号２０７で示す赤字・延滞解消の見込みコメントと、符号２０８で示す今後の業況等の見通しコメント２０８についても、直近の決算登録時のコメントをそのまま表示する。続いて、営業店担当者は、変化の要因コメント２１８に、状況速報の原因となった変化の要因についてコメントする。続いて、変化に対する対応と見通しについて、状況速報時の所見としてコメントを登録する。

債務者の概況画面にて、決算検討時のコメントをそのまま表示し、状況速報時のコメントをさらに追加する業務プロセスを強制しているため、債務者の動向をより正確に記述することができる。決算検討時の「今後の業況等の見通し」コメントが、事後に発生した状況速報の変化の要因にそぐわないとしても、決算検討時のコメントをそのまま表示する。

図７２は、Ｃ株式会社の作業を承認する統括者用のサマライズ画面である。決算検討作業のコメントは、決算検討時のコメントである。信用格付は、債務者区分確認画面での判定結果が表示される。自己査定作業は、状況速報によるものである。統括者は、登録内容全照会ボタンＢ４３を操作することで、各確認画面の精査を行うことができる。

上述したように、一方向制御と強制再表示処理１２とにより、多種多様な債務者の債権を均質に査定する業務プロセスを構築することができる。特に、作業を素早く正確に完了させるための業務プロセスではなく、不慣れな担当者に早期習熟を促し、熟達者の思考を妨げずに、判断漏れをなくす程度に冗長な強制再表示処理１２を行うため、作業に不慣れな作業者から、熟達者にとって使いやすく、かつ、帳票ではなく、コンピュータシステム４を使用して作業を行っても、作業に必要なスキルを作業者が失うことのないように、各画面にて総合的な整合性の確保と判断への熟慮を求めることができる。すなわち、本実施例では、作業を自動化するのではなく、業務プロセスの確立を自動化したため、営業店担当者のスキルが失われることはない。また、一方向制御と強制再表示処理１２という強固な業務プロセスにより、多様な債務者に応じた個々の判断と、作業者に依存しない均質な判断とを両立させることができる。

＜実施形態及び各実施例の効果＞
上述したように本実施形態及び各実施例によると、実施形態及び実施例で開示した銀行業務処理システムは、次の効果を奏する。
・判断過程統一作用： 予防的統制効果
本発明では、マニュアル（人手）ではなく、ＩＴの利用により、画面や個別タスクの終了画面側へのジャンプを厳格に禁止することで、作業の順序を必ず一方向で行う強制をＩＴの利用により実現することができる。特に、開始画面側へ戻った後であっても終了画面側へのジャンプを禁止すると、作業者は、戻った画面より終了画面側の各画面の内容を少なくとも確認し、そして、必要な再作業する作業手順が強制される。
本発明では、ＩＴの利用により作業手順を強制するため、査定結果に至る判断の過程を統一することができる。すなわち、予め定められた判断過程以外の判断過程による査定結果を生じさせない（判断過程統一作用）。
一方向制御による判断過程統一作用により、想定外の誤解による作業の発生とその誤りの発生とを有効に予防することができる。すなわち、一方向制御というＩＴの利用により、格付自己査定という業務について予め定めた業務手順から逸脱した作業やその誤りを予防することができる。従って、ＩＴの利用による予防的統制を実現でき、これにより、内部統制の質を向上させることができる（予防的統制効果）。

・業務プロセス構築作用： 業務標準化効果、結果の均質化効果、可用性向上効果
この一方向制御というＩＴを利用した判断の「過程（プロセス）」の統一により、厳格な業務プロセスを構築することができる。すなわち、ＩＴを利用した判断過程の統一により、予め定められた基準による各画面又は各個別タスクでの作業者の判断が、予め定められた判断過程にてなされるため、不慣れな作業者であっても、熟達した作業者であっても、判断の過程が統一される。これにより、作業者によらず共通した業務プロセスを構築することができる（業務プロセス構築作用）。そして、ＩＴを利用した業務プロセスの構築により、ＩＴの利用による業務の標準化を実現し（業務標準化効果）、作業の結果を均質とすることができる（均質化効果）。
すなわち、一方向制御というＩＴを利用した判断過程の統一により、業務の標準化効果と、結果の均質化という効果を奏する。結果の均質化という効果には、一定の結果の均質化を確保するための業務上の作業負荷の軽減が含まれる。
さらに、この業務の標準化と結果の均質化とにより、一方向制御下での判断を標準的に積み上げる業務プロセスとなり、このため、総合的な整合性についての一貫性を確保することができる。すなわち、査定結果データ６ｆの一貫性を保ち、その信頼性及び正確性を全ての債務者及び全ての作業者について確実に確保することができる。すなわち、内部統制等のために何らかの統計的処理を行う際に、高度な統計処理を行うために必要となるデータの信頼性及び精度を確保することができる。これらにより、データの可用性を大幅に向上させることができる（可用性向上）。
また、本発明は、予め定められた手順での判断を作業者に強制するため、各過程で判断すべき事項が予め統一して特定されており、従って、個別の判断に使用するデータと、そのデータに基づく判断の根拠とが明確となる。このため、査定結果の検証可能性をより一層向上させることができる。すなわち、データの可用性として、検証可能性を向上させることができる。

・判断基準の局所化作用： 準拠性確保効果、開発容易効果
そして、本発明は、作業者の判断過程を統一するための情報処理であり、個々の作業の判断基準には依存しない。従って、一方向制御は、判断基準の変更に応じたコンピュータシステム４の変更があっても、引き続き利用できる情報技術である。さらに、判断基準の変更に伴ってコンピュータシステム４の変更が必要となっても、多くの場合、判断過程（作業のプロセス）自体の変更までは要さない。
そして、一方向制御を採用すると、判断基準自体は、判断の過程と独立して要件定義することができる。また、必ず同一の画面推移により作業者の判断及び作業データ６ａが蓄積されることを前提とすることができる。このため、個々の判断基準や計算式は、作業全体の業務プロセスへの組み込みを最低限とし、局所化することができる（判断の局所化作用）。
さらに、一方向制御を採用し、画面推移が一律（予め定められた複数のパターンの推移を含む）であり、個々の詳細な計算式等が局所化され、可能性の組み合わせの数が少なくなるため、業務に熟達した発明者と、情報技術に熟達した発明者との対話が容易となる。このため、業務上必要な計算式や表示等のルールにコンピュータシステム４を準拠させてその確認をする開発負荷を、一方向制御を採用しないコンピュータシステム４と比較して、大幅に軽減することができる（準拠性確保効果）。
例えば、一方向制御を採用しないと、判断過程の統一を実現できず、さらに、各データの状態（全体の中での位置付け）を管理するための情報処理（プログラム）と、各データを計算するための情報処理とが混在しがちとなる。すると、判断基準の変更に伴うプログラムの開発や修正について、その影響を抽出する作業自体が膨大となり、さらに、開発や修正の作業自体も複雑で、修正後にはさらに情報処理内容全体の見通しが悪化しがちとなり、保守負担も増加する。すなわち、リーズナブルな変更が困難となってしまう。
本発明では、各データの状態を個別に管理する必要がなく、作業のプロセスである一方向制御自体は変更される可能性が低いため、判断基準の変更に伴って必要となる開発作業の人的負荷及び費用を軽減することができる（開発容易効果）。

・内部統制の質の向上効果
上述のように、一方向制御を採用すると、その判断過程統一作用により、予防的統制を高度に実現することができる。さらに、一方向制御による業務プロセス構築作用により、業務の標準化をＩＴの利用により実現し、結果を均質とし、これらにより作業の結果として蓄積されるデータの可用性を大幅に高めることができる。データの可用性を高めることで、発見的統制の手法を拡大し、またコストを低減することができる。そして、一方向制御による判断基準の局所化作用により、コンピュータシステム４の要件定義に対する準拠性を低コストで確保し、開発及び変更の作業負荷を軽減することができる。
このように、本発明は、一方向制御というＩＴの利用により、予防的統制を高度に実現し、発見的統制の手法を多様化すると共にコストを低減し、そして、ＩＴ統制としても準拠性の確保をしやすく、開発及び変更の見通しを良好とすることができる。
従って、本発明を採用するコンピュータシステム４は、内部統制の質を高め、業務の有効性及び効率性の確保に寄与することができる。
これらにより、本発明は、ＩＴの利用により内部統制の質を向上させると共に信用リスク・信用コストに関連するデータの可用性を安定的に確保することで、業務の健全性、適切性及び適正を向上させることができる。

上記本発明の実施形態及び実施例による効果を内部統制の用語との関係で再度整理すると、以下の通りとなる。

（１）．銀行法、バーゼルＩＩ、告示１９号等、改訂金融検査マニュアル
（１．１）健全性： 一方向制御というＩＴを利用したコンピュータシステム４により、信用リスクと信用コストとに関するデータについて、検証可能性、検索可能性、可用性及び準拠性の高い統計的データを安定して蓄積することができる。この信頼性の高い統計的データの蓄積により、信用リスク及び信用コストを測定することで、損失の発生を低減しつつ、収益性を管理することができる。好適な例では、柔軟かつ均質なデータの蓄積が可能となる。
・収益向上可能性： 一方向制御により、信用リスク及び信用コストを測定し、自己資本の資本配賦のための判断材料となるデータを精度良く測定することができ、さらに、自己資本管理部門への適時報告が可能となる。
・損失発生防止可能性： 一方向制御等のＩＴを利用することで、信用リスク及び信用コストの管理に必要な内部統制の質を向上させることができ、信用リスク及び信用コストを精度良く管理できるため、早期の対応が可能となり、損失発生やその拡大を有効に防止することができる。
（１．２）適切性： 一方向制御というＩＴでは、画面の確認により開発の早期の段階から準拠性を確保することができる。また、一方向制御下では、データの依存関係が明確に明示的に整理されているため、準拠性を確認するための試験を低コストで実施することができる。そして、判断過程の統一により、信用リスク及び信用コストの測定・評価に必要な手続を標準化し、個別の判断や全体的判断の整合性を有意に確保することができる。そして、好適な例では、進捗ステータス等を利用したトランザクション管理により適時の報告を可能とし、さらには、基準等の変更に対応してコンピュータ・プログラムを修正する負荷を軽減することができる。このように、準拠性を確保するための様々な業務の作業負荷を軽減するため、信用リスク及び信用コストの管理に関する銀行の業務の適切性を低コストで維持することができる。
・法令準拠性： 一方向制御を用いて、判断過程及び作業手順を一律に強制することで、法令準拠性に必要となる個別判断の位置付けを明確化し、不慣れな作業者であっても早期の熟達を促すことができる。そして、例えば特性操作要求により、個別判断の積み上げと総合的判断とによる一貫性を確保することができる。
・統合的管理性： 一方向制御と、必要な強制再表示や特性操作要求等により、信用格付・債務者区分と自己査定とを一体的に管理することができる。
・適時報告性： 作業プロセスデータ６ｈの管理や、トランザクション管理によりデータの取扱い容易性を向上させ、例えば、進捗ステータスや作業ステータスにより各データの有効性を確認しつつ、日中にデータを抜き出して必要な報告することができる。
・変更対応性： 一方向制御やプロセス管理により、制度変更に際してその変更を局所化して反映することができる。

（2).適正［会社法］
・情報の管理： 一方向制御により、統計処理の母集団として安定したデータを蓄積することができ、プロセス管理等により、判断過程や判断根拠を含めたデータを生成でき、データの可用性を向上させると共に、様々な切り口の検索及び適時報告を実現することができる。
・業務の信頼性： 一方向制御により、不慣れな作業者も熟達した作業者も判断の過程が統一されることにより、強固な業務プロセスを構築することができる。さらに、特定操作要求等により、判断の根拠をデータとして記録することで、検証可能性を向上し、モニタリングの有効性をより確保することができる。
・保存性： 好適な例では、作業データ６ａと、作業プロセスデータ６ｈとの両者を蓄積するため、データの進捗上の意味を明確化することができる。特定操作要求など予めシステムに組み込むことで、予め定められた事項については判断根拠をデータとして保存することが可能となる。
・検索性： 好適な実施例では、全ての項目をサーバーで管理するため、エンド・作業者・コンピューティングによる場合と比較して、各項目の意味を唯一に明確に定めておくことができ、検索の精度を格段に向上させることができる。また作業プロセスデータ６ｈの項目を用いた検索も可能となる。
・可用性： 好適な実施例では、個々の信用格付及び債務者区分等のデータを活用できる他、検証容易性、統計的処理を安定して行うことができる。
・リスク管理： 上述のように、信用リスク管理の基礎データ６ｂ蓄積に必要な準拠性、信頼性、検証可能性及び検索活用性を確保することができる。期待損失ＥＬと貸倒引当金との比較などに際して、事後検証可能で準拠性あり信頼できるデータで比較することができる。
・内部監査： 内部監査手続をシステム化したため、監査手順等をＩＴで統制することができる。また、作業プロセスデータ６ｈや、判断根拠についてのデータを用いたモニタリングをすることもできる。

（３）．財務報告の信頼性（金融商品取引法・実施基準）
（３．１）．ＩＴの利用： 自己査定は償却・引当という財務報告の要素を計算する業務プロセスの一部であり、この貸倒引当金の算出等の業務の有効性・効率性・信頼性をＩＴの利用により確保し、向上することができる。特に、自己査定業務の手順を標準化し、その手続に強制的に従わせることで、ＩＴを利用した内部統制の質を向上させ、有効性を確保することができる。なお、バーゼルＩＩの第３の柱に対応した金融庁告示第１５号による開示は財務報告ではないが、債務者格付は信用リスク量の測定という信用リスク管理に必要な業務プロセスの一部であり、その数値の信頼性を確保するために、一方向制御というＩＴを利用することができる。
・統制環境の有効性： 一方向制御という作業者の理解が容易なＩＴに信用リスク及び信用コストの管理に必要な判断基準を組み込むことで、この判断基準及び業務の結果を組織の適切な者に適時に伝達することが可能となり、統制環境の有効性を確保することができる。
・リスクの評価と対応： 信用格付、債務者区分、債権分類を測定し、判定する業務は、信用リスク及び信用コストを評価する業務であり、一方向制御により、判断過程が強制的に統一されているため、貸倒引当金や自己資本比率の算出に誤りが含まれる可能性を大幅に低減することができる。そして、質の高い統計的データを蓄積し、データの可用性が高いため、リスク情報の共有を良好に低コストで行うことができる。
・統制活動： 一方向制御というＩＴは、判断過程を統一するという業務上困難な課題をコンピュータシステム４の利用により実現するものであり、この判断過程の統一により、統制活動の有効性を良好に低コストで確保することができる。すなわち、判断過程を統一するというＩＴの利用は、予防的システムによる統制となり、統制活動の質を向上させることができる。また、好適な実施例では、作業手順上、初回判断を別途保存することで、判断の相違を記録し、事後検証を容易にすることができる。
・情報の伝達： 上記の他、一方向制御により、一定の準拠性及び信頼性を確保しつつ必要な情報を要約していく作業を強制することで、伝達の有効性を向上することができる。
・モニタリング： 信用格付、債務者区分の判断等について、内部監査部門がコンピュータシステム４を利用して監査する際、一方向制御というＩＴが利用されているため、作業者の判断思考を追認しやすく、内部監査の有効性を上昇させることができる。また、作業結果のみならず、作業プロセスに関するデータも蓄積されるため、抽出監査を行う際に、様々な切り口での自動的な抽出が可能となる。また、差戻しという作業プロセスの記録により、モニタリングの結果を有効に機能させることができる。

（３．２）ＩＴの統制： 信用リスク及び信用コストの測定や管理に関する業務については、一方向制御により均質なデータを蓄積することができる。システム開発に関する業務については、一方向制御により準拠性確保の開発負荷を低減でき、このため、変更容易性も確保できる。
・有効性及び効率性： 一方向制御により個別の作業漏れを防止し、判断の柔軟性と均質性とを確保しつつ、好適な実施形態・実施例では、熟達者にとっては事務合理化に役立ち、不慣れな者にとっては早期の熟達を促すことができる。
・準拠性： 一方向制御では、画面設計時に情報処理の大まかな流れが特定されるため、開発の早い段階から準拠性を確保することができ、また、リリースに至るまで、画面での実際の入力をしながら準拠性を確認することができるため、準拠性の確度を大幅に向上させつつ、早期の確認を可能とすることで、全般的な作業負荷を軽減することができる。
・データ信頼性： 一方向制御により、判断の過程が統一されているため、粒度の揃ったデータを蓄積することができる。
・可用性： 上記の他、クライアントサーバーの利用により、項目の意味が明確で安定した信頼性の高い集計を可能とする。また、取り扱う数値（金額）の単位を合わせることも容易である。
・機密性： 各データに対するもののみならず、作業プロセスデータ６ｈについてのアクセスログを残すこともでき、機密性確保と確認とを多面的に行うことができる。

１ 端末
２ ネットワーク
３ 通信制御部
４ コンピュータシステム
６ 作業データ格納部
６ａ 作業データ
６ｂ 基礎データ
６ｃ 入力データ
６ｄ 導出データ
６ｅ 査定データ
６ｆ 査定結果データ
６ｇ 査定作業結果データ
６ｈ 作業プロセスデータ
７ 画面定義情報格納部
７ａ 画面定義情報
１０ タスク処理部
１２ 強制再表示処理
１４ タスクデータ管理処理
１６ 表示制御処理
１８ 計算処理
２０ 条件確認処理
２２ 格納処理
２４ 特定操作要求処理
２６ 特定操作確認処理
３０ 進捗制御部
３０ａ 推移コマンド
３２ 戻りタスク特定処理
３４ 次タスク特定処理
３４ａ 作業分岐
３４ｂ 画面分岐
３６ 起票時処理
３８ タスク開始処理
４０ タスク完了処理
４２ 一方向制御処理
４４ タイムスタンプ処理
４６ 作業分岐処理
４８ 特定スキップ処理
５０ トランザクション管理部
５２ 全体排他制御
５４ 全体一貫性制御
５６ 個別原子性制御
５８ 個別隔離性制御
６０ 個別永続性制御
６２ 中断制御
７０ 他システム
７２ オンラインシステム
７４ 取引先要項システム
７６ その他各種システム
８０ 破綻懸念先以下抽出符号
８２ 要注意先抽出符号
８４ 正常先抽出符号
９４ ワークフロー制御部
９６ 起票制御部
１００ ランタイムシステム
１０２ メモリー
１０３ ＣＰＵ
１０４ クラス群
１０６ タスク・インヴォーカー
１０８ タスクマネージャー
１１０Ｃ タスククラス
１１２Ｃｘ 個別タスク・クラス群
１１４ プログレスマネージャー
１１５ タスクデータ（ｔｄ）
１１６ 進捗ステータステーブル
１１８ ＤＢアクセス
１２０ タスクデータライター
１２１ 銀行業務データベース
１２２ プログラムファイル格納部
１２４ 信用リスク・コスト統制用プログラム
１３０ サーブレット
１３４ タスク・インタフェース
１３６ ＤＢアクセス・クラス
１４０ 自動処理等
１４２Ｃ 確認計算クラス
２００ 業況変化の詳細内容コメント
２０１ 雑科目資産性・査定根拠コメント
２０２ 実態修正コメント
２０３ 主要アラームコメント
２０４ 異常マークについてコメント
２０５ 当期の業況総評コメント
２０６ 業況・財務の特徴コメント
２０７ 赤字・延滞解消の見込みコメント
２０８ 今後の業況等の見通しコメント
２０９ 主な問題点とポイント
２１０ 抽出基準修正コメント
２１１ 債務者区分・信用格付判定理由コメント
２１２ 優良与信修正コメント
２１３ 優良担保保証修正コメント
２１４ 保証人回収可能理由コメント
２１５ 一般担保保証修正コメント
２１６ 自己査定特記事項コメント
２１７ 管理回収方針コメント
２１８ 変化の要因コメント
２１９ 変化に対する対応と見通しコメント
２２０ 補足説明コメント
２２１ 差戻し理由コメント
２２２ 動向コメント
４００ 状況速報起動理由コード
４０１ 変化の理由コード
４０２ 変化の発生日
４０３ 作業要否判定コード
４０４ 財務登録有り
４０５ 財務登録無し
４０６ 資産性コード
４０７ 内訳金額
４０８ 雑科目明細
４０９ 資産性修正額
４１０ 外部格付機関コード
４１１ 企業番号
４１１ 企業番号
４１２ 事象チェックコード
４１３ 破綻懸念先以下抽出符号コード
４１４ 要注意先抽出符号コード
４１５ 正常先抽出符号コード
４１６ 検査・考査符号コード
４１７ 与信明細修正
４１８ 条件緩和コード
４１９ 問題与信債権コード
４２０ 債務者区分判定コード
４２１ 債務者格付コード
４２２ 特定与信格付コード
４２３ 信用格付判定理由コード
４２４ 法的整理
４２５ 与信額補正
４２６ 特定スキップ有り
４２７ 特定スキップ無し
４２８ 差戻し先
４２９ 動向発生年月日
４３０ 主要動向区分
Ｂ１ 次へボタン（作業開始、登録、承認）
Ｂ２ ジャンプして戻るボタン
Ｂ３ 戻るボタン
Ｂ４ 中断ボタン
Ｂ５ 疎明資料ボタン
Ｂ６ 終了ボタン
Ｂ７ 計算ボタン
Ｂ８ 検索ボタン
Ｂ９ 作業不要ボタン
Ｂ１０ 作業基準日
Ｂ１１ 状況速報ボタン
Ｂ１２ データ一覧更新ボタン
Ｂ１３ 振分け待ち一覧ボタン
Ｂ１４ 処理待ち一覧ボタン
Ｂ１５ 担当者作業待ちボタン
Ｂ１６ 承認待ちボタン
Ｂ１７ 確認待ちボタン
Ｂ１８ 店一覧ボタン
Ｂ１９ データ取消ボタン
Ｂ２０ 担当者変更ボタン
Ｂ２１ 並び替えボタン
Ｂ２２ 印刷ボタン
Ｂ２３ 照会ボタン
Ｂ２４ 取引先要項ボタン
Ｂ２５ 取扱要綱ボタン
Ｂ２６ Ｑ＆Ａボタン
Ｂ２７ ヘルプボタン
Ｂ２８ 顧客属性表示ボタン
Ｂ２９ 進捗フロー表示（非表示）ボタン
Ｂ３０ スコアリング評点照会ボタン
Ｂ３１ 抽出符号照会ボタン
Ｂ３２ 個人定量評点
Ｂ３３ 財務要約照会
Ｂ３４ 財務分析帳票
Ｂ３５ 主要経営比率
Ｂ３６ 損益計算書（単体）
Ｂ３７ 貸借対照表（単体）
Ｂ３８ 前回内容照会ボタン
Ｂ３９ 前回内容取込ボタン
Ｂ４０ Ｂ／Ｓへボタン
Ｂ４１ Ｐ／Ｌへボタン
Ｂ４２ 関連融資先ボタン
Ｂ４３ 登録内容全照会ボタン
Ｂ４４ 差戻しボタン
Ｂ４５ 参考情報照会ボタン

Claims (8)

1. リスク評価を含む複数の関連するタスクからなる銀行業務の担当者によって使用される端末とネットワークを介して接続されたコンピュータシステムを有し、このコンピュータシステムが、
   基礎データ、入力データ、導出データ及び査定データを作業対象毎に有する作業データを格納する作業データ格納部と、
   前記端末の画面に表示する画面要素の入力編集可否及び配置を定義する画面定義情報を前記銀行業務の前記タスク毎に格納する画面定義情報格納部と、
   前記タスク毎に前記画面定義情報に従って前記作業データを前記端末に表示制御すると共に、当該端末の前記画面要素への操作に応じて入力される前記入力データと、当該入力データを使用して導出する導出データと、前記作業対象への前記担当者による前記リスク評価を含む査定データとを前記作業データ格納部に格納するタスク処理部と、
   前記画面要素の操作により前記端末から送信される推移コマンドに応じて、当該タスク間の推移を、前記作業対象を特定する開始画面から当該担当者による前記査定データを確定する終了画面に向けて、複数の前記タスクの推移を一方向に制御する進捗制御部とを備え、
   この進捗制御部は、
   作業完了した現タスクの次に作業するタスクを要求する次タスク照会要求を前記推移コマンドとして受信した際には、当該現タスクまでの前記作業データ及び当該現タスクから予め唯一に定められた次タスクを特定する次タスク特定処理と、
   作業中のタスクより前記開始画面側にあり前記担当者の任意で指定されるタスクにジャンプして戻るジャンプ戻り要求を前記推移コマンドとして受信した際には、前記作業中であった前記タスクとは別の一以上のタスクを前記開始画面側に向けて飛び越して、当該任意で指定された当該ジャンプ戻り先の前記タスクを現タスクに特定する戻りタスク特定処理とを備え、
   前記タスク処理部が、前記画面定義情報に従って、前記タスクのために入力され又は導出した前記リスク評価に関する前記作業データの一部を、一以上の別のタスクの作業後に作業中である現タスクの画面に入力編集不可で再表示することで、当該再表示した作業データの修正に際して、当該作業データを入力した前記タスクに、前記一以上の別の前記タスクを飛び越すことでジャンプして戻ることを当該担当者に促す強制再表示処理を備え、
   前記次タスク特定処理が、前記戻りタスク特定処理によるジャンプ戻り先のタスクを作業完了の現タスクとする前記次タスク照会要求を受信した際に、当該ジャンプ戻り先である当該現タスクまでの前記作業データ及び当該現タスクから予め唯一に定められた次タスクを特定することで、前記再表示の前記画面までジャンプして進むジャンプ進みを禁止した、
   ことを特徴とする銀行業務処理システム。
2. 前記作業対象毎に、前記タスクを識別するタスクＩＤを使用して前記開始画面を含む開始タスクから前記終了画面を含む終了タスクに向けた一方向の順序で一次元の並びとして複数の前記タスクを有すると共に、当該各タスクでそれぞれ使用する作業データの全体に対して当該タスクを単位として未着手、作業中及び作業済の進捗ステータスを特定する進捗ステータステーブルを格納する進捗ステータス格納部を備え、
   前記進捗制御部は、
   前記銀行業務のタスク群からなる作業が起票された際に当該作業対象を識別する作業通番の進捗ステータステーブルの全ての前記タスクの進捗ステータスを前記未着手とする起票時処理と、
   前記推移コマンドが前記タスクの開始要求である際に、当該開始要求の前記タスクＩＤで指定される前記タスクの進捗ステータスを前記作業中に変更するタスク開始処理と、
   前記推移コマンドが前記タスクの終了要求である際に、当該現タスクの進捗ステータスを前記作業済に変更するタスク完了処理と、
   前記戻りタスク特定処理によるジャンプ戻り先の前記タスクについて前記タスク開始処理をした後に、当該戻り先である当該現タスクのタスクＩＤから前記一方向の順序での前記戻り元の前記タスクのタスクＩＤまでの全ての前記作業済の進捗ステータスを前記作業中に変更する一方向制御処理とを備え、
   前記次タスク特定処理は、前記戻りタスク特定処理によるジャンプ戻り後のタスクを現タスクとする際と、ジャンプ戻りではないタスクを現タスクとする際とのいずれにあっても、当該現タスクへの前記タスク完了処理の後に前記次タスク照会要求を受信した際には、前記進捗ステータステーブルを参照して前記未着手又は前記作業中の前記タスクＩＤのうち最も前記開始タスクに近い前記タスクＩＤの前記タスクを次タスクに指定する、
   ことを特徴とする請求項１記載の銀行業務処理システム。
3. 前記進捗ステータステーブルは、当該銀行業務の態様別に進捗が並列であるタスクを前記一方向の順序で一次元の並びとして有すると共に、前記進捗ステータスとして省略を有し、
   前記進捗制御部は、
   前記タスク完了処理が、前記銀行業務の態様別に異なる次タスクが定められている際には、前記タスク完了処理のタスクから当該次タスクまでの進捗ステータスを省略に変更し、
   前記一方向制御処理が、戻り先のタスクの進捗ステータスを作業中に変換する前後に、当該戻り先のタスクよりも終了タスク側の全てのタスクのうち前記省略の進捗ステータスを前記未着手に変更する、
   ことを特徴とする請求項２記載の銀行業務処理システム。
4. 前記作業を識別する前記作業通番を単位として、当該作業通番で使用する作業データの全体に対して、待機中、実行中及び決裁済の作業ステータスを特定した作業ステータステーブルを格納する作業ステータス格納部と、
   前記作業通番で使用する作業データの全体に対する処理を作業トランザクションとして管理すると共に、前記タスクＩＤで使用するタスクデータへの処理を個別トランザクションとして管理するトランザクション管理部を備え、
   このトランザクション管理部は、
   前記作業通番の作業ステータスが前記実行中である場合には、当該作業通番の作業開始を禁止する一方、当該作業ステータスが前記待機中である場合には、当該待機中を前記実行中に変更して前記次タスク特定処理に当該作業通番を引き渡して作業開始を許可することで、当該作業通番を単位とした前記作業トランザクションの実行を唯一に排他制御して、当該作業トランザクションに隔離性を与える全体排他制御と、
   前記作業トランザクションの決裁となる前記タスクの前記タスク完了処理の後に、当該作業トランザクションの作業ステータスを前記実行中から前記決裁済に変更することで、当該作業トランザクションに一貫性を与える全体一貫性制御と、
   前記タスク毎の進捗ステータスを管理させることで前記個別トランザクションに原子性を与える個別原子性制御と、
   前記タスクを一方向に制御することで前記個別トランザクションに隔離性を与える個別隔離性制御と、
   前記タスクの進捗ステータスが作業済に変換された際に、当該進捗ステータスが作業済である前記個別トランザクションに永続性を与える個別永続性制御と、
   前記端末から中断要求を受信した際に、当該作業トランザクションに一貫性を与えないまま、当該タスクまでの各タスクの個別トランザクションに永続性を与える中断制御とを備えると共に、
   当該トランザクション管理部は、前記端末からジャンプ戻り要求を受信した際に、当該戻り元の当該タスクに前記中断制御をすることで、当該作業トランザクションに一貫性を与えないまま、当該戻り元の当該タスクの作業データに永続性を与える、
   ことを特徴とする請求項３記載の銀行業務処理システム。
5. 前記タスク処理部は、前記銀行業務の前記リスク評価の作業上保守的な内容の作業データを前記担当者の入力データとして初期値表示すると共に、当該初期値表示する入力データが当該担当者によって変更される際には、前記画面要素の選択又は前記画面要素への入力を含む特定操作用の画面要素を特定操作要素として表示制御してコメントの入力を促すと共に、作業データの修正に際して、当該作業データを入力した前記タスクに、前記一以上の別の前記タスクを飛び越すことでジャンプして戻ることを当該担当者に促す特定操作要求処理を備えた、
   ことを特徴とする請求項４記載の銀行業務処理システム。
6. 前記タスク処理部が、前記一方向制御処理に従って推移させるタスクとして、
   前記基礎データとして債務者の決算による公表財務データの登録がなされた際に、当該公表財務データの検討、実態財務データの登録、及び予め定められた複数の決算検討コメントの入力を前記担当者に促す決算検討タスク群と、
   当該決算検討タスク群の完了後、当該決算検討タスク群での入力データ、前記基礎データ及び導出データを使用して、当該債務者の信用格付の一次評価の検討を前記担当者に促す信用格付タスク群と、
   前記信用格付タスク群の完了後、当該信用格付タスク群までの作業データと、前記債務者及び当該債務者の債権に関する基礎データとを使用して、財務状態又は事象として予め定められた抽出基準に該当する債務者について、債務者区分及び信用格付の判定を促す債務者区分タスク群と、
   前記債務者区分タスク群の完了後、当該債務者区分タスク群までの作業データと、当該債務者の債権に関する基礎データとを使用して、当該各債権の保全の確認及び修正を促す債権分類タスク群と、
   債権分類タスク群に続いて、当該債権分類タスク群までの作業データの一部を入力編集不可の属性で債務者の概況として再表示すると共に、決算検討時の決裁後に当該債務者に変化があった際には変化検討コメントの入力を促す債務者の概況タスクとを備え、
   前記債務者の概況タスクにて、
   前記強制再表示処理が、前記決算検討コメントの一部又は全部を入力編集不可の属性で当該債務者の概況タスクの画面に再表示し、
   前記戻りタスク特定処理が、当該入力編集不可で再表示した決算検討コメントについて前記担当者による修正がなされる際に、前記決算検討タスク群に前記ジャンプして戻るジャンプ戻り要求の送信と関連付けられた前記画面要素を当該債務者の概況タスクの画面に表示する、
   ことを特徴とする請求項５記載の銀行業務処理システム。
7. リスク評価を含む複数の関連するタスクからなる銀行業務の担当者によって使用される端末とネットワークを介して接続されたコンピュータシステムを有し、このコンピュータシステムが、
   基礎データ、入力データ、導出データ及び査定データを作業対象毎に有する作業データを格納する作業データ格納部と、
   前記端末の画面に表示する画面要素の入力編集可否及び配置を定義する画面定義情報を前記銀行業務の前記タスク毎に格納する画面定義情報格納部とを備えた銀行業務処理システムを使用して前記複数の関連するタスクを実行する方法であって、
   前記タスク毎に前記画面定義情報に従って前記作業データを前記端末に表示制御すると共に当該端末の前記画面要素への操作に応じて入力される前記入力データと、当該入力データを使用して導出する導出データと、前記作業対象への前記担当者による前記リスク評価を含む査定データとを前記作業データ格納部に格納するタスク処理工程と、
   前記画面要素の操作により前記端末から送信される推移コマンドに応じて、当該タスク間の推移を、前記作業対象を特定する開始画面から当該担当者による前記査定データを確定する終了画面に向けて、複数の前記タスクの推移を一方向に制御する進捗制御工程とを備え、
   この進捗制御工程は、
   作業完了した現タスクの次に作業するタスクを要求する次タスク照会要求を前記推移コマンドとして受信した際には、当該現タスクまでの作業データ及び当該現タスクから予め唯一に定められた次タスクを特定する次タスク特定工程と
   作業中のタスクより前記開始画面側にあり前記担当者の任意で指定されるタスクにジャンプして戻るジャンプ戻り要求を前記推移コマンドとして受信した際には、前記作業中であった前記タスクとは別の一以上のタスクを前記開始画面側に向けて飛び越して、当該任意で指定された当該ジャンプ戻り先の前記タスクを現タスクに特定する戻りタスク特定工程とを備え、
   前記タスク処理工程が、前記画面定義情報に従って、前記タスクのために入力され又は導出した前記リスク評価に関する前記作業データの一部を、一以上の別のタスクの作業後に作業中である現タスクの画面に入力編集不可で再表示することで、当該再表示した作業データの修正に際して、当該作業データを入力した前記タスクに、前記一以上の別の前記タスクを飛び越すことでジャンプして戻ることを当該担当者に促す強制再表示処理工程を備え、
   前記次タスク特定工程が、前記戻りタスク特定工程によるジャンプ戻り先のタスクを作業完了の現タスクとする前記次タスク照会要求を受信した際に、当該ジャンプ戻り先である当該現タスクまでの前記作業データ及び当該現タスクから予め唯一に定められた次タスクを特定することで、前記再表示の前記画面までジャンプして進むジャンプ進みを禁止した、ことを備えたことを特徴とする銀行業務処理方法。
8. リスク評価を含む複数の関連するタスクからなる銀行業務の担当者によって使用される端末とネットワークを介して接続されたコンピュータシステムを有し、このコンピュータシステムが、
   基礎データ、入力データ、導出データ及び査定データを作業対象毎に有する作業データを格納する作業データ格納部と、
   前記端末の画面に表示する画面要素の入力編集可否及び配置を定義する画面定義情報を前記銀行業務の前記タスク毎に格納する画面定義情報格納部とを備えた銀行業務処理システムのコンピュータを使用して銀行業務を処理するための銀行業務処理用プログラムであって、
   前記タスク毎に前記画面定義情報に従って前記作業データを前記端末に表示制御すると共に当該端末の前記画面要素への操作に応じて入力される前記入力データと、当該入力データを使用して導出する導出データと、前記作業対象への前記担当者による前記リスク評価を含む査定データとを前記作業データ格納部に格納するタスク処理手順と、
   前記画面要素の操作により前記端末から送信される推移コマンドに応じて、当該タスク間の推移を、前記作業対象を特定する開始画面から当該担当者による前記査定データを確定する終了画面に向けて、複数の前記タスクの推移を一方向に制御する進捗制御手順と、
   作業完了した現タスクの次に作業するタスクを要求する次タスク照会要求を前記推移コマンドとして受信した際には、当該現タスクまでの作業データ及び当該現タスクから予め唯一に定められた次タスクを特定する次タスク特定手順と
   作業中のタスクより前記開始画面側にあり前記担当者の任意で指定されるタスクにジャンプして戻るジャンプ戻り要求を前記推移コマンドとして受信した際には、前記作業中であった前記タスクとは別の一以上のタスクを前記開始画面側に向けて飛び越して、当該任意で指定された当該ジャンプ戻り先の前記タスクを現タスクに特定する戻りタスク特定手順と、
   前記画面定義情報に従って、前記タスクのために入力され又は導出した前記リスク評価に関する前記作業データの一部を、一以上の別のタスクの作業後に作業中である現タスクの画面に入力編集不可で再表示することで、当該再表示した作業データの修正に際して、当該作業データを入力した前記タスクに、前記一以上の別の前記タスクを飛び越すことでジャンプして戻ることを当該担当者に促す強制再表示処理手順と、
   前記戻りタスク特定手順によるジャンプ戻り先のタスクを作業完了の現タスクとする前記次タスク照会要求を受信した際に、当該ジャンプ戻り先である当該現タスクまでの前記作業データ及び当該現タスクから予め唯一に定められた次タスクを特定することで、前記再表示の前記画面までジャンプして進むジャンプ進みを禁止する手順と、
   を実行させることを特徴とする銀行業務処理用プログラム。

Images