Sapiens

◆超高速開発ツールとして、歴史と実績を誇るサピエンスの優位性位性

基幹業務開発にとって、最も重要であるQCD（品質、コスト、高速開発）に対して、サピエンスがいかに対応しているかについて、ご紹介いたします。なお、当ご紹介は、数々のサピエンス・プロジェクトでの経験、サピエンスの教育コースのインストラクターとして経験からえられた株式会社東條経営科学研究所の見解で、サピエンス社（Sapiens International coop. 並びに、サピエンス・ジャパン株式会社）の公式見解ではありませんことをご了承のうえご一読くださればと存じます。

【目次】

プログラムは悪、これを解決しないとプロジェクトマネージは軽減できない。サピエンスはプログラムレスである。
オブジェクト志向は難しく、理解できる人口が少ない。サピエンスはやさしい「オブジェクト志向」である。
サピエンスの動作の本質
望まれるサピエンス人口の拡大

１.プログラムは悪、これを解決しないとプロジェクトマネージは軽減できない。サピエンスはプログラムレスである。

私は、コンピュータ業界に身をおいて４０年以上を経過しています。この間多くの基幹業務開発を経験してきましたが、プロジェクトマネージメント上、昔から言われていることが現代でも、依然としていわれていることに愕然とした思いをもっています。

要件定義があいまいであった。
例外処理が誤っていた。
予想外に工数がかかってしまった。
結果的にコスト・オーバとなってしまった。

これらは、３０年前もいわれていましたし、今日でも全く同じことがいわれています。何故でしょうか。最も大きな問題は、プログラムが必要である、ということではないでしょうか。もし、開発にプログラムが不要ということになれば、問題の多くは解決できるのではないでしょうか。このことに気がついた先人達は多くいますし、製品も多く存在します。

サピエンスもまた、そのひとつです。しかし、サピエンスは、１９８２年に発表されて以来、四半世紀を過ぎてなお、欧米を中心として多くのユーザに採用されています。さらに、現在も進化しています。

２.オブジェクト志向は難しい、理解できる人口が少ない。サピエンスはやさしい「オブジェクト志向システム」である。

私は、現在オープン系で採用されているJAVAによるオブジェクト志向には限界があるものと感じています。コンピュータ・システムを開発するためには、プログラムを書かなければならない、という宿命があります。オブジェクト志向においては、それを合理化しようとした結果、逆に、より複雑化させてしまったのではないでしょうか。結果として、オブジェクト志向は難解となってしまいました。

代表的な例として、実装クラス図、シーケンス図、MVCモデル、インスタンス化、継承、キャスト、ORマッピング等オブジェクト志向を代表する概念が難しすぎるのです。サピエンスでは、これらの概念は必要ではありません。極論すれば不要です。基幹システムを開発する人達は天才の集団ではありませんし、秀才の集団でもないのです。ごく普通のプログラマが、大半を占めています。

正確な統計ではありませんが、ごく一般の方々100人を集めて、BASICのようなごく普通のプログラムを講習した場合、本当に理解できる人は３人といわれています。この理解できた方々を対象として、オブジェクト志向を講習した場合、本当に理解できる人は３０％といわれています。結論として、オブジェクト志向を理解できる人は１％ということになります。日本の就業人口を６０００万人とした場合、６０万人が上限ということになります。

全員がコンピュータ志望ではないですから、大目に見積もって現実の上限はその１０％として、６万人程度でしょう。もっと少ないかもしれません。情報関連産業の人口が約６０万人とすれば、殆どの人たちは、オブジェクト志向を理解する「適性」がない、ということになります。ＳＥ・プログラマに限ってみても総勢約３５万人としますと、「適性」をもった人の絶対数が圧倒的に足りないことになります。所詮無理があるのではないでしょうか。私は、もっとやさしく、基幹業務を開発できる方法論が求められているものと思っています。

サピエンス本体は、オブジェクト志向で開発されています。しかし、基幹業務の開発担当者にそれを意識させません。言葉はオブジェクト志向の言葉を使っていますが、いわゆるオブジェクト志向流に考える必要がないように作られています。インスタンス化する必要すらないのです。サピエンス自体が行なってくれます。

いわば、開発者にとって「やさしいオブジェクト志向」なのです。

☆2週間で作成できたＩＦＲＳ・コアエンジン（コラム）

ＩＦＲＳの導入は、すでに多くの資料等で伝えられておりますとおり、早ければ2015年3月期より強制適用になります。その場合2013年3月までにＩＦＲＳ対応システムを完成しておくことが必要になり、社内方針の検討と決定、それに基づくＩＴシステム開発期間を考えますと、それほど多くの時間は残されていないと考えるべきでしょう。

ＩＦＲＳの導入を考える上で、重要な点は以下のようなものと考えられます。

要件定義があいまいであった。
例外処理が誤っていた。
予想外に工数がかかってしまった。
結果的にコスト・オーバとなってしまった。

３.サピエンスの動作の本質

基幹業務開発のQCDに対するサピエンスによる開発の優位性に関して、さらにサピエンスの動作の本質をいくつかの観点からみていきましょう。以下では、下記観点につきまして、特徴を述べていきます。

データからものをみる。
データが変化すると、ルールが起動する。
コード量は、プログラムに比し、約１／５０となり、劇的に品質が高まる。
ポジティブシンキングとネガティブシンキング
開発内容は１００％知識ベースに収められる。ソースコードは生成されない。
基幹業務処理に耐える機能（フォーム、DB、エラー処理、コミット／ロールバック）
運用を支えるBISと知識ベース　運用コストが１／５になる。
進化の歴史（文字画面、C/S、Web、SOA、クラウドコンピューティング）
サピエンスが不得意な分野

（1）データからものをみる。データ構造を定義するとシステムが動作します。

サピエンスの開発は何はともあれ、データ構造の関係を定義することから始まります。
ER図を描く感じと考えていただければ結構です。オブジェクト志向流にいいますと、概念モデルを作成することに相当します。
ER図を描くということはそれなりに、データ・モデルを理解している必要があります。従って、一般のエンドユーザには無理ということになりますので、サピエンスはプロフェッショナル向けのツールということになります。
データ・モデルを絵を描くように描いてやって、そのキーとデータ項目（属性）を指定してやります。特徴的なのは、実装ボタンを押してやりますと、ほんの数秒で、実装されるという点にあります。

実装されると何ができるのでしょうか。

(1) DBができます。
(2) 画面（フォーム）ができます。
(3) 画面データをDBに送るプログラムが生成されます。オペレーションと呼びます。
このオペレーションは、追加、削除、変更、参照の機能をもっています。
(4)その他カレンダー等、画面支援のツールが用意されます。

すなわちこの時点で、テストデータを打ち込むことができることとなります。動作しているのです。

単純なER図の場合でしたら、画面遷移も含めて、実用的なものが生成されてしまいます。
伝統的な開発方法論では、画面を決めて、DBを決めて、操作するためのプログラム（トランザクション）を作成します。
サピエンスでは全く逆転発想をします。DBを決めれば、画面は自動生成されます。データの橋渡したるトランザクションは、オペレーションとして、サピエンスが勝手に作ってくれます。開発者がコーディングする必要がありません。自動生成された画面はユーザビリティに合わせて、フォーム・エディタと呼ばれる HTMLエディターで配置修正、色修正、追加文字、四角枠等をつけてお化粧できます。

オペレーションは、サピエンスに備えられた１個のプログラムです。
これに対して番号をつけてやって、使いまわすという考えから成り立っています。
この時点までは何のコード（プログラム）も作成する必要がありません。 DB構造（ER図）を定義すれば、動作するシステムができてしまうのです。これをもとにお客様と仕様確認を行なうことができます。

修正も極めて簡単であり、お客様が気に入るまで繰り返せばよいのです。
ただ、この段階では、フィールド間の計算ロジック等は入っていません。いわば、がらんどうではあるものの、画面遷移と外観の必要条件の確認が行なえます。
これは開発の比較的初期の段階で、仕様確認が行なえるということを意味していますので、お客様もご安心されることになります。もうここまできたのか、と評価いただけることが多いものです。

（2）データが変化するとルールが起動する。

がらんどうではビジネス・プロセスはなりたちません。ここにルールを設定することになります。

ルールのご説明に先立ち、データ構造表現を若干追加ご説明いたします。

設計段階では、データ構造は、エンティティ、ウイークエンティティ、アソーシエーション等と表現いたしますが、実装しますと、それらは全てクラスという表現に統一されます。
以降、クラスという表現を使って説明いたします。
クラスとは、データを入れる器であると同時に、そのクラスにルールを着けることができます。
例えば、フィールド間計算、金額＝単価＊数量のようなルールを記述します。
このルールは誰が起動するのでしょうか。
一般のオブジェクト志向では、実装クラスであるコントロールクラスがその役割を担います。
シーケンス図を描いて、誤りなくクラスをインスタンス化し、計算処理を行なうメソッドを呼び出すコードを作成します。
サピエンスの場合、通常、このようなコントロールクラスを設けることはありません。サピエンスの本体（BLPといいます）がこの役割を担っています。
動作のアルゴリズムは、クラスのデータ内容を変化させるような事象（イベントといいます、Insertが代表です）が発生すると、ルールが動作するように作られています。
開発者はこのことを知っている必要はありますが、自分でコードを書いて起動させる必要はありません。
すなわち、業務固有の、金額＝単価＊数量のみコードとして記載してやります。

この一群のコードのことをルールと呼びます。

ルールの起動は開発者の責任ではなく、サピエンスの責任です。
すなわち、そのクラスのデータが変化するということを、サピエンスは管理しています。

この機能を司るエンジンという意味で、「イベント・ドリブン・ルールベースド・エンジン」といいます。

データが変化すると動作する関係は、相互に変化する関係にあるクラスでも有効に機能します。
例えば、受注クラスが変化する（Insertする）と、在庫クラスが変化するようにルールを書くでしょう。
在庫クラスが変化すると、最小在庫を割ることが判るでしょう。その場合には、発注準備クラスに、発注量を書き込むようにルールを作成することができます。
これらは一連のトランザクションを引き起こしますが、サピエンスは、これらを一括管理し、途中で何らかの不都合が起こった場合には、それまでのコミットデータをロールバックしてくれます。
これら一連のトランザクション・チェーンの管理は、開発者に何の負担もかけません。
サピエンスが管理してくれます。

それでは、データが変化しない場合はどうなるのでしょうか。
例えば、受注数量が１０であったものを、打ち直して１０とした場合ですが、このような場合は、何も起こりません。
ルールが起動しないのです。

このように大胆な方法論で、本当に基幹システムが動作するのだろうか、と疑いたくなる方も多いことと思います。
しかし、イスラエルでは、１９８２年にサピエンスを発表する前、１０年間をかけて、この命題の実験を行なったと言われています。その結果、欧米で多くのシステムが導入されることとなり、この方法でよいことが実証されているのです。
日本でも多くの実例があり、この方法論は実証済みのものなのです。
私をこのことを称して、「イスラエル人は頭がいい」という表現を使っています。

「やさしいオブジェクト志向」の本質はここに実現されている、と思っています。

（3）コード量が約１／５０となり、劇的に品質が高まる。

ルールは、プログラムではありません。

プログラムとは、クラスをインスタンス化し、初期設定を行い、ファイルをオープンし、必要なメソッドを定義し、それらを起動させる等の処理を行なうものです。
サピエンスでは、これらのことを、コンピュータ機能と呼び、手順型言語の宿命と考えています。
一般の手順型言語（ＪＡＶＡもそうです）の調査では、プログラム・コード量のうち、コンピュータ機能部分は８割、業務処理部分は２割と言われています。
サピエンスでは、このコンピュータ機能を開発者から切り離し、業務機能開発に専念できるように設計されています。

この業務機能を記述する言語をルールと呼んでいます。

しかし、ルールもプログラムもコードであることには変わりありません。
ルールの記述は伝統的なＣＯＢＯＬに似ています。

このような設計が行なわれた結果、4項に述べるポジティブシンキング機能と合わせますと、開発コード量は、通常の手順型言語（ＣＯＢＯＬ、ＪＡＶＡ等）に比し、約１／３０～１／５０に激減することが実証されています。
５００万ラインのオンラインプログラムが、約１０万ラインになることとなります。５００万ラインを人間が追いかけるのは、至難の技になりますが、１０万ラインなら、追いかけてみようか、と思うのが人情ではないでしょうか。

このコード量の激減は、誰にでもわかるとおり、開発の高速化、品質の安定化に劇的に寄与しています。

さらに、私にとって、重大な関心事があります。
私は、４０年以上のコンピュータ経験がありますが、お分かりのとおり、高齢であります。しかし、今でもサピエンス開発の現役であります。これはひとえに、この開発コード量の激減が故と考えております。
コンピュータ部門の方々の中には、豊富な経験を有しておられる方々が多くおられます。しかし、現役の開発には携わっていない方々も多いことと思います。
開発は若者の仕事である、という固定概念がありますが、それはそれなりに納得できることであります。
プログラムの開発は、若い人の方がいいでしょう。
一方、ルールの開発はあまり若い人には向いていません。
理由は、ルールは業務を記述する言語ですから、業務をわかっている人の方が向いています。経験の豊富なコンピュータ技術者は一般的に業務のことをよくわかっている方々が多いと思います。

実はこの人たちにこそ、サピエンスを使って欲しいのです。
このことは

(1) 業務をよくわかっている経験豊富な人たちが、こんなものを作りたい、と考えたとき、自らの思いを託した業務の開発ができるのです。
(2) 経験豊富な方々は、現役の開発要員にカウントされておらず、折角の力が発揮されていない、というコンピュータ業界の悪弊を解決できるのです。

ということを意味していると考えています。

因みに、サピエンス・ジャパン社の社長であられる岡田様も、私よりご高齢ではあられますが、今も現役の開発者として、社員をリードしておられます。

コード量の削減は、高速化、品質安定化に止まらず、人材の活用にも役立っているのです。

（4）ポジティブシンキングとネガティブシンキング

ルールの動作を支えるもうひとつの重要な概念は、ポジティブシンキングと呼ばれるものです。

データを処理する場合、追加（Insert）、変更（Change）、削除（Delete）、参照（Reference）が行なわれます。
例として、受注クラスの商品コード、受注数量、在庫クラスの商品コード、在庫数量を考えてみましょう。

新しい受注が発生して、A商品、１００個の受注が入ったとします。
この場合、受注クラスのルールとして、在庫クラスのＡ商品の数量を１００個マイナスするルールを記述してやります。
結果１０００個あった在庫が９００になるものとします。

ルールの記述は、在庫数量を１００個マイナスする、と記述するだけでよいのです。
JUCHUU-SURYOU IS SUBTRACTED FROM ZAIKO-SURYO.
のように記述してやります。

この状態で、受注数量が１００ではなく、９０個だったとして修正処理が入ったとします。

画面から、受注クラスの数量に、９０を入力します。不思議なことが起こります。
先ほど作ったルールでは、この数量をマイナスするのですから、在庫は９００－９０＝８１０になると思われます。
しかし、そうはなりません。
サピエンスでは、次のようにルールが動作します。

１．受注数量のOldValueである１００を在庫に加えます。

もともと在庫から引くとなっていたので、反対操作として足すのです。結果在庫数量は、９００＋１００＝１０００となります。

２．続いて、在庫数量のNewValueである９０を在庫から引きます。

１０００－９０＝９１０となります。この結果は、欲しい結果ですね。

このように、サピエンスのルール処理は常に、OldValueとNewValueを管理しています。
記述するルールは、受注数量がInsertされたときを想定して記述してやればよいと、約束されています。

このことをポジティブシンキングと呼びます。

ポジティブシンキングは、一般人が常識的に考えている業務処理知識と一致しています。
一方、今回のように数量修正が入ることをネガティブシンキングと呼びます。

サピエンスでは、開発者はネガティブシンキングを記述する必要がありません。

ネガティブシンキングは、人間の常識ではあっても、コンピュータ処理の常識ではありませんので、一般の言語では、プログラムを作る必要があります。
サピエンスは人間の常識に近づくように配慮されています。
ポシティブシンキングのみを記述すれば、サピエンスがネガティブシンキングの動作を論理的に行ないます。

このことは、開発者にとって大きな便益をもたらします。
一般的にデータ量はポシティブシンキングデータが大半です。
数量変更、商品変更等は頻度的には少ないものです。ネガティブシンキングは、商品変更でも対応してくれます。
Old商品の在庫を戻し、 New商品の在庫を減らしてくれます。

しかしながら、一般の手順型言語には、このような機能はありませんから、開発者が苦労して数量変更、商品変更といった例外処理を延々と記述することになります。

サピエンスでは、これら例外処理を開発関心外とできるのです。

このことも、コード量削減に大きく寄与していますし、例外処理の漏れ、バグの発生解決に寄与でき、品質向上をもたらすのです。以上の

ご説明で、すでに気がつかれたと思いますが、ルールの動作は手順型言語と全く異なります。

一件プログラムのように見えるルールですが、全く異なる動作を行なわせることによって、開発者への負担を大きく削減しているのです。このことを企業経営的にみてみましょう。
企業経営では、滅多に起こらない事象に対して投資することは余りありません。
しかし、ITの世界は不思議な世界で、滅多に起こらない例外処理に多額の投資をしているのです。
多分、普通の現象を処理する投資額より、例外的に起こる現象を処理する投資額の方が大きくなっているでしょう。
おかしいと思いませんか。

サピエンスは、経営の常識を反映できるように設計されているのです。

（

それでは、以上述べてきました、データ構造、画面、オペレーション、ルール等といったものはどこで管理されているのでしょうか。

サピエンスの場合、開発された各々の要素は１００％全て、知識ベースと呼ばれるリポジトリに格納されます。
JAVA等のソースプログラムは生成されません。

サピエンスにとって、業務システムを開発するということは、システムを動作させるための要素を、知識ベースに埋め込んでいく、ことを意味しています。
開発要素は１００％知識ベース内で管理されることになります。
容易に想像いただけると思いますが、リポジトリ構造をもって管理されますので、例えば、開発要素である特定のフィールドが、どのフォームで使われているか、どのルールで使われているか、等を実に簡単に参照できます。何らかの保守の必要性が発生した際、影響する画面やルールは１００％正確に、かつ迅速に特定することができます。その箇所を保守すればよいのです。

このことを、「影響分析」と呼びます。

サピエンス以外にも多く開発ツールが発表されていますが、それらの中には、ソースコードを生成するものもあります。
それらとの対比を行なうと、紙面が多くなりますので、別の機会に譲りますが、要約いたしますと、サピエンスのような知識ベースをもとに動作させるシステムは、

(1) 開発手順が簡単になります。
(2) 運用管理をやさしくします。
(3) 保守を確実にします。

のような便益をもたらします。

（6）基幹業務処理に耐える機能（フォーム、DB、エラー処理、コミット／ロールバック）

今まで述べてきましたサピエンスの機能は、サピエンスを支える根幹の機能ですが、もう少し、中味を詳しくみていきましょう。
サピエンスは基幹業務を支える機能が多くあります。それらをいくつかみていきましょう。

まず、オンラインのユーザ・インターフェースの代表であるフォームについて述べます。

フォームは、画面入出力機能を抽象化・一般化したものです。オンラインシステム開発の高速化を図る上で画面は極めて重要なものです。
具体的には、

(1) デバイスの進化を支える必要があります。
キャラクタ・ディスプレイ、Ｗｅｂブラウザ、携帯電話　　等に対応する必要があります。さらに、進化するでしょう。
(2) 多くのクラスに格納されたデータを１画面内に表示する必要があります。
(3) ユーザの操作性を向上させる必要があります。
ボタン、ドロップダウンリスト、PFキーなどです。さらに、色、配置、デザイン等も重要な要素です。

などでしょう。

サピエンスでは、デバイス固有の問題と、内部アルゴリズムとを分離しています。
特に重要なのは内部アルゴリズムでしょう。
内部アルゴリズムは、フォームの機能の抽象化・一般化を意味しています。これを実現するための、最も基本は、フォームをブロックという機能に分割し、ブロックは、原則、1つのクラスに対応させるということです。
クラスに対応させないブロックもありますが、詳細過ぎますので、ここでは割愛いたします。

すなわち、一画面の中には、複数のブロックが存在する＝複数のクラスに対応している、ということになります。
この場合、複数のクラス間で共有される値は、どのように受け渡されるかということが重大な関心事になります。
サピンスでは、システムの動作時、フォームがアクティベートされると、DynamicDispatchingAreaとして、メモリが確保されます。
このメモリのことを、フォーム・コンテキストとよびます。
複数のクラス間で受け渡されるデータは、このフォーム・コンテキスト内で受け渡され､画面に表示されることとなります。

通常、これらの受け渡し方法は、開発時、サピエンスが決定してくれますので、開発者が意識しなくても良いのですが、大規模基幹システムの開発においては、サピエンスが自動決定するものでは、なかなか、お客様のご要望にお答えすることができないことが発生いたします。
このような場合には、開発者が、フォーム・コンテキスト内のデータ受け渡しを指定してやります。
この指定は、ルールのような複雑な指定ではなく、パラメータのチェックボックスに受け渡し方をチェックして指定するだけです。

サピエンスでは、一般のオンラインでトランザクションと呼ばれるものをオペレーションと呼んでいます。

オペレーションは、1個のクラスに対応しています。
これでは複雑な業務は開発できないのではないか、との疑問をもたれるでしょう。
サピエンスはこの問題を解決するためにフォームにブロックをもたせ、フォームコンテキストでクラス間データを受け渡すという設計を行なったことにより、開発の自動化に成功しているのです。その意味でサピエンスにとってフォームは極めて重要なコンポーネントということになります。

また、フォーム開発の手順も、伝統的な方法論と異なります。
若干細目の説明となりますが、クラスを定義しますと、それを操作するためのオペレーションが作成されます。
オペレーションは、対象クラスがどれであるかを知っていると同時に、クラス内の対象フィールドがどれであるかも知っています（デフォールトでは、全フィールドです）。
フォームのブロックではこのオペレーションを指定してやります。
すなわち、オペレーションに格納されたフィールドがフォームに表示されることになります。
すでに述べましたように、これにお化粧をするのは、開発時、内臓されたHTMLエディタで行います。
フォームに必要なフィールドはフォームで指定するのではなく、オペレーションで指定します。通常、オペレーションは大量のフィールドをもっていますので、開発者は、必要なフィールドのみをオペレーションに対して選択指定します。
その結果、業務に必要なフォームが生成されることになります。

ご理解いただけたでしょうか。
伝統的な開発では、フォームにフィールドを定義し、プログラムとの関係性を指定します。
サピエンスでは、クラスを決定し、必要なフィールドをオペレーションで選択した結果として、フォームが生成されるのです。
どちらが良いのか、というのは、一長一短があると思いますが、正直、私の実体験では、サピエンスの方が圧倒的に高速に開発できます。論理性が高いため、惑いません。

フォームにつきましては、まだ、述べたいことがありますが、このくらいにしましょう。

次にデータ・ベースについて考えて見ましょう。

データ・ベースに対して、入出力するということは、ひらたくいいますと、ＲＥＡＤ、WRITEする、ということです。
サピエンスのルールにＲＥＡＤ、WRITEというものはありません。
各々、FETCH、DERIVATIONとよびます。

FETCH、DERIVATIONはサピエンスのルールを支える極めて重要な概念ですが、

(1) 対象たる物理DBを抽象化している。
(2) DERIVATIONはトランザクション・チェーンを引き起こす。

という点が重要です。
抽象化の根本は、キーを指定して、FETCH（読んでくる）、 DERIVATION（書き出す）するということです。

対象となる物理DBは、VSAM、各社RDB製品（ＤＢ２、Ｏｒａｃｌｅ、ＳＱＬサーバ等）ＩＢＭ社製ＩＭＳ等です。
現状の実装は、RDB関連が圧倒的ですが、IMSのお客様もおられます。

ルールでは、FETCH、DERIVATIONを使うのが一般的ですが、対象をRDBに固定する場合にはSQLも使えるようになっています。

すでに述べたとおり、ＤＥＲＩＶＡＴＩＯＮは、対象のクラスを変化させますので、そのクラスにつけられたルールが起動されることになります。この関係は次々とクラスがつながっていく関係となりますが、サピエンスの実行モジュールはこれを管理してくれます。
開発者にコンピユータ固有技術（コミット／ロールバック等）の負担はかけません。

ＤＥＲＩＶＡＴＩＯＮの働きをもう少しみてみましょう。ここでは会計の処理である転記、残高更新について考えてみます。
コンピュータがなかったころから会計は手作業で行なわれてきています。
その根本は

(1) 仕訳伝票を起票する。
(2) 総勘定元帳に転記する。
(3) 残高票に記入する。

ということです。
この手作業の詳細をみてみましょう。

人間は、まず仕訳伝票を切ります。
そして、その各行の勘定科目、借方、貸方の金額を、総勘定元帳という分厚い帳簿の各勘定科目に転記します。
そして、総勘定元帳の各勘定科目の残高を残高表に纏めます。
人間は長い間、コンピュータがない時代にこの作業を営々と行なってきました。
コンピュータが導入されるに到って、この処理を行なうことになったのですが、この処理を行なうのはどのようにするのが妥当でしょうか。

伝統的な手順型言語の場合には、仕訳伝票をＤＢとして保存し、該当日付の範囲内のデータに対して、総勘定元帳ＤＢに転記してやります。
さらに、仕訳伝票から、残高表ＤＢに対して、残高更新を行ないます。
この方法が妥当な方法と私もそう思います。
何故なら、総勘定元帳から、残高更新をかけるのは、一段余分の処理が入りますので、仕訳伝票から行なう方が良いでしょう。
着目しておくべき点は、人間が行なってきた方法とは異なる、ということです。

サピエンスでは、このようには考えません。

仕訳伝票クラスに対して、総勘定元帳クラスへ転記するルールをＤＥＲＩＶＡＴＩＯＮを使って記述します。
続いて、総勘定元帳クラスに対して、残高クラスヘ残高更新するルールをＤＥＲＩＶＡＴＩＯＮを使って記述します。
クラスが変化するからルールが起動する、かつ、連動するというルールのメカニズムを利用しているのです。
人間が処理する手順とソックリの手順を行います。

どちらが良いのでしょうか。
これも一長一短のある話です。
サピエンスでは、クラスのもつ役割はクラスのルールとして記述し、クラスの中に閉じ込めようとします。
クラスの機能を特定し、分散させたくないからです。
どこかで聞いた話ではないでしょうか。
オブジェクト志向では、クラスの機能を隠蔽する（カプセル化）ことができる、といわれています。

実はサピエンスでも同じことを考えているのです。
それをカプセル化というような難解な言葉や手順を使わずに自然にできるように設計されているのです。
「やさしいオブジェクト志向」はここでも実現されています。

次に「エラー処理」について考えてみましょう。
基幹業務開発する際、エラー処理は避けて通ることができません。
サピエンスは、実行モジュールの中で多くのエラー処理を行なってくれます。
当たり前の話で恐縮ですが、例えば、フィールド属性として数値を指定したものに、画面で文字を入力した場合などは、キチンとメッセージを送り、入力できなくなります。
システム設計エラーが残った場合にも勿論返してくれます。
ここでは、業務処理上のエラー処理について述べます。
エラー処理は、ルールの1つの要素である、ＶＡＬＩＤＡＴＩＯＮルールを使用します。
ＶＡＬＩＤＡＴＩＯＮルールでエラーと指定した場合、そのレコードはコミットされません。自動的にロールバックされます。
画面には、入力されたデータが表示されますが、ＤＢは更新されません。
エラー・メッセージは開発者が指定します。エラー番号を体系化する場合には、その番号も指定してやります。
エラーのタイプには、エラー、ウオーニング、インフォメーション等のレベルがあり、ウオーニングやインフォメーションの場合には、レコードはコミットされます。

ＶＡＬＩＤＡＴＩＯＮルールは極めて簡単に指定できますので、開発者への負担は極めて小さくなります。

以下のような感じです。

　メッセージ：「数量は１０００未満でなければなりません」
ルール記述：SURYO MUST BE LT 1000.
レベル：エラーにチェックする（デフォールトは、エラーです。）

基幹業務開発を支える機能は、詳細には、更に深い説明が必要になりますが、別の機会とさせていただきます。

（7）運用を支えるBIS（Business Integrity Server）と知識ベース【運用コストが１／５】になる。

サピエンスは何者であるかについて解説いたします。

私は個人的にイスラエルのサピエンス開発者達の思いを理解できます。直接会話したことはありませんが、実現されているサピエンスをみると、以下のようなものであったのではないでしょうか。

(1) 目標は、開発、運用、保守の生産性を劇的に向上させることである。
(2) 将来、進化が予想される、ユーザ・インタフェース、マシーン・インタフェース DBの進化に対応しなければならない。
(3) 解決するためには、OSの下で自立的に機能するミドルウエアが必要である。かつ、進化する多くのOSの下で機能しなければならない。

サピエンスはこれらの課題に対して、見事に回答を出しています。世の中にこんなに巨大な構想を実現できると思った人がいるでしょうか。私はいくつかの開発ツールを経験してきています。また、調査もしてきています。しかし、こんなに大きな構想を実現したものにお目にかかったことがありません。

よくいわれることですが、サピエンスは元々、IBM　ＯＳ／３９０用に開発されました。（現在のＺ－ＯＳも勿論サポートされています。）その
後、ＩＢＭ　ＯＳ／４００にポーティングされ、さらに、ＨＰ－ＵＸ、ＬＩＮＵＸ、ＷＯＮＤＯＷＳへと拡大されています。
今後さらに拡大されていくことでしょう。

話を続けましょう。ミドルウエアたるサピエンスの実体をご説明いたします。

本体はＢＩＳ（Business Integrity Server）といいます。
ＢＩＳの役割は、荒っぽい表現をしますと、ＴＰモニタの機能であるといえます。ＢＩＳをスタートさせますと。まず、リスナーがスタートします。リスナーはいわゆるリスナーと思っていただいて結構です。端末からのセッション・リクエストを待っています。端末は、キャラクタ端末であろうと、Ｗｅｂブラウザであろうと、携帯端末であろうと、関係ありません。ＢＩＳの中では抽象化されています。端末からのセッションが確立すると、ＢＩＳは、各端末に対して、各々1個のＢＬＰ（Business Logic Processor）を割り当てます。Business Logic Processorは、サピエンスの業務処理実行本体です。頭の中で、メモリ空間の中に、1個のBISがあり、その下に、セッションしている端末の数分の BLPが同時並行的に動作している姿を思い描いてください。サーバの中で、多くの複数個のＢＬＰが動作しています。

一体、何故、ＢＩＳが必要なのでしょうか。
本来、別のＴＰモニタをもってきて、それに端末管理を行なわせればよいではないか、と疑問をもってしまいます。それではうまくいかないのです。
やはり、サピエンスは、業務を動作させるメカニズですから、ＢＬＰと密接にやりとりする必要があります。
ＢＩＳをもたせたことにより、Ｚ－ＯＳのもとで動作するＣＩＣＳ等のＴＰモニタとの共存を可能になりました。
さらにＷｅｂサーバであるＩＩＳとのインタフェースも可能になりました。
ＣＩＣＳを例にとりますと、一般のＣＩＣＳの端末はＣＩＣＳで制御されますが、サピエンスの端末はサピエンスが管理します。
ＣＩＣＳからみるとサピエンスは1個のトランザクションに見えます。サピエンスアプリケーションからきたリクエストに対して、ＣＩＣＳは何もしません。サピエンスにパススルーします。後はサピエンスが全て管理します。サピエンスをＣＩＣＳに登録する作業は、極めて定型的になります。何故ならＣＩＣＳに1個のトランザクションを定義するだけで済むからです。
Ｗｅｂサーバも同じように考えればよいでしょう。ＢＩＳの機能は、サピエンスの業務運用環境を極めて容易にしているのです。
サピエンスを入れたからといって、運用が複雑化することはありません。むしろ簡単になるのです。

以上、ＢＩＳのリスナーモードを解説いたしましたが、端末数が巨大化した場合、ＢＬＰの数も巨大化します。
メモリ不足が起こる可能性があります。この場合には、リスナーではなくＴＡＭというものを使います。
ＴＡＭは端末からのメッセージをキューイングします。ＢＩＳはメッセージをスケジュールし、空いているＢＬＰを割り当てます。
巨大な基幹業務に対する対策も準備されているのです。

リスナーを使うかＴＡＭを使うかといった問題は、サピエンスの構成ファイルであるアドミニストレーション・ファイル（テキストファイル）を、調整することで行ないます。

さらに知識ベースについても補足しておきましょう。
ＢＩＳは何を根拠にして、運用しているのでしょうか。実は知識ベースに収められた情報を元に運用します。
知識ベースは、開発の要素を納めているだけではありません。

アクセスするユーザに関する情報の保管ログ・データの保存
セキュリティ管理に必要なデータの保管

等の働きももっています。
ＢＩＳはこれらの情報をみながら、運用しているのです。

サピエンスで開発された業務システムは、サピエンスが面倒をみる、ということを実現しています。

本項の冒頭で、ＯＳの下で、自立するミドルウエアが必要であると書きましたが、運用面でも自立していることにより、運用の生産性を向上させているのです。

実例では、運用コストは１／５程度になることが実証されております。

（8）進化の歴史（文字画面、C/S、Web、SOA、クラウドコンピューティング）

サピエンスは１９８２年に発表されて以来、数々の進化の歴史があります。四半世紀を過ぎてなお、進化するソフトウエアは、数少ないものと思っています。一体どのような構想があってこうなっているのでしょうか。７項でも述べた通り、サピエンスは、将来の技術進化に対応することを念頭において開発されたものと思います。

ＢＩＳやＢＬＰといったサピエンスの根幹を支える思想はこの間何ら変化していません。
この根幹を支える部分を触ることなく、進化する部分を外付けで、開発する方策を用意していたのではないか、と想像されます。私達にはそれを、アダプタという名称で紹介されています。アダプタはオブジェクト志向にもある考え方ですので、サピエンスの開発者達は、１９８２年の時代、まだオブジェクト志向が明解な回答を出していない時期にすでにその考えに到っていたものと想定できます。

アダプタの開発の結果何が実現されてきたのでしょうか。
アダプタ以外の要因のものもありますが、進化の代表的なものを以下に記載いたします。

(1) キャラクタ・ディスプレイから脱却し、クラサバを実現した。
(2) 三層設計の思想を導入し、ＵＩ層、ビジネス・ロジック層、データ層の分離に成功した。
(3) Ｗｅｂを実現した。
(4) ＸＭＬデータ交換に成功した。
(5) 他システムで開発されたビジネス・コンポーネントとの接続に成功した。（Ｗｅｂｓｐｈｅｒｅコンポーネント等）
(6) ＳＯＡを実現した。
(7) ＢＰＥＬ等ＢＰＭとの接続に成功した。
(8) レガシーシステムのラッピングに成功した。
(9) 多くのＤＢＭＳとの接続に成功した。ＤＢ２、Ｏｒａｃｌｅ、ＳＱＬサーバ、ＡＤＡＢＡＳ、ＶＳＡＭ、ＩＭＳ等
(10) クラウド・コンピューティングへの道も切り拓いている。
(11) 携帯電話からのデータ入力も可能にした。

これらの中には、英文のみのサポートで、日本語化されていないものもありますので、全てが日本で使えるわけではありませんが、四半世紀を経て、これほどの進化を遂げたソフトは現存するでしょうか。
これほどの進化を遂げたソフトですから、今後の進化に追随していくだろうということは容易に想像できます。
安心して使ってよいソフトウエアなのです。

（9）サピエンスが不得意な分野

最後に、いかにサピエンスとはいえ、サピエンスは、コンピュータ・システム開発にとって、あらゆる分野をカバーするものではありません。
不得意な分野を以下に列挙いたします。

科学技術計算には、全く不向きです。できないと断言いたします。
サピエンスでCＡＤ／ＣＡＭシステムを開発することはあり得ません。科学技術計算に必要な、浮動小数点や、マトリクス（アレイ）がサポートされていません。手が出ません。
プロセスコントロール等科学技術計算に近いものも不得意です。
実装例がありません。
エンベッディッド・システム開発も現状ではできません。
バッチ処理は考慮が必要です。
元々、基幹オンライン業務用に開発されていますので、バッチ処理につきましては、考慮点があります。
原則、オン中バッチは問題ありません。夜間に一般的に行なわれるスケジュールド・バッチは慎重に対応する必要があります。
ＳＯＲＴ／ＭＥＲＧＥ等を介在させた一連のファイル処理は得意ではありません。
そもそも、サピエンスには、ＳＯＲＴ／ＭＥＲＧＥがありません。
これらの処理は、大量データ処理のパフォーマンスを向上させる目的でさまざまなテクニックを使って、手順型言語で開発されています。
ただ、最近では、ＳＳＤ（半導体メモリ）が次第に普及しつつあります。スケジュールド・バッチでも、サピエンスで開発できる時代が近づきつつあります。今後は変わっていくと思われます。サピエンスはバッチにも適用できる、という時代が来るでしょう。
帳票開発には向いていません。
多くのERP系のソフトがそうであるように、サピエンスも帳票作成機能は弱いです。日本ではきめ細かい設計ができるソフトを必要とする場合が多いので、その場合は帳票作成ソフトを別途用意される必要があります。

日	月	火	水	木	金	土
« 1月
	1	2	3	4	5	6
7	8	9	10	11	12	13
14	15	16	17	18	19	20
21	22	23	24	25	26	27
28	29	30