ビジネスロジック部品 (本体)

はじめに

 従来のいわば気ままなソフトウェア開発と‘ビジネスロジック部品’(注1) を活用した開発とは大違いである。 この違いは、ヨットでの帆走と車による道路上の走行との差異に似たところがある。

注1: ビジネスロジック部品という言葉の曖昧さを避けるために、本書では明確な定義を与えており、この定義に従っている場合には‘ビジネスロジック部品’のようにシングルコーテーションで括った表記にしてある。 なお、‘ビジネスロジック部品’を一般化したものをソフトウェア部品と呼び、‘ソフトウェア部品’という表記にしてある。

帆走

 海上には地上にあるような障害物もなければ舗装された道路も存在しない。 そのかわり、風の強い波の立つ海面とそうではない部分が模様をなしているのが見える。 最短の時間でゴールに着くには、その模様の移り変わりを予測しながら風を求めて最速のジグザグコースを取るという奥義を必要とする。 しかし、レースでなければ気ままにコースを選んでも構わないし、ある程度風まかせにしても構わない。 そうしたとしても目的地に到着することはできるだろう。

都会の道路

 これに対して、道路を車で走る場合はだいぶ様子が異なる。 たとえば、ある地点から別の地点へタクシーで行くときには、どの運転手さんもほぼ同じコースをたどるものである。 これは、2 点を結ぶ直線でもなければ、風や潮の流れに依存するジグザグコースでもない。 どの道路がふさわしいかによって決まるコースである。 道路上では、信号や交通法規を守って運転しなければならないが、エンジンパワーを意のままに活用して快適に目的地に到着できる。

 従来の多くのソフトウェア開発は、ヨットで大海原を走るようなものであった。 もしも、その奥義を追求するとすれば、それぞれの開発にとっての最良のコースが見えてくるに違いない。 しかし、無理にがんばって奥義を極めなくてもソフトウェアを開発することは可能である。 実際のところ、ほとんどのソフトウェア開発は、あたかも奥義を追求しているような仮面をかぶって、その実、開発者の気ままを許していたのが実態なのではなかろうか?

部品

 これに対して、‘ビジネスロジック部品技術’(注2) を用いたソフトウェア開発は、道路を車で走るようなものである。 いわば、道路や付帯設備を整備し、交通法規を充実させることによって、その恩恵に浴するのである。 こうすれば、コンピュータパワーを上手に活用して、どの開発者も同じコースを快適にたどれるようになる。 こうすることは、奥義の追求という仮面をはぎ取ることになるが、経済的な便利な交通手段を提供することに結び付く。

注2: 本書の定義に従った実用的で効果的な‘ビジネスロジック部品’に関するテクノロジーについては、シングルコーテーションで括った表記にしてある。 同様に、‘ソフトウェア部品’に関するテクノロジーについても、シングルコーテーションで括った表記にしてある。

 本書は、‘ビジネスロジック部品技術’がビジネス分野の業務アプリケーションプログラムの開発に有効なことを明らかにするものである。 これがなぜ有効だと確信できるのか。 その根底には同じような業務アプリケーションプログラムが重複開発されているという事実があるからなのだ。 同じ種類のアプリケーションプログラムだと思われるものでも、たとえば A 社向けと B 社向けのそれぞれに何らかの違いがあることが普通なので、これを理由に、それぞれ独立に開発する場合がほとんどなのである。 ところで 「その違いは?」 というと、それがわずかな場合が多い (というように認識できるのである)。 したがって、同じ種類のアプリケーションプログラムならば共通に開発できるはずである。 たとえば1割の違いがあるのなら、残りの9割は共通にできるはずなのだ。 しかるに、共通部分を共通にするというごく当然のことが難しいと考えられている。 非常識だと思われるかもしれないが、これが業務アプリケーションプログラム開発業界の常識になっている。

 このような変な常識が形成されるには、それなりの理由がある。 本書は主に技術的な観点からこの原因を解明して、変な常識を改めて合理的な開発を行えるようにする一つの方法を提示する。 つまり、‘ビジネスロジック部品技術’によって、実用的で効果的な部品化再利用が現実に可能なことを明らかにする。 そして、ビジネス分野の業務アプリケーションプログラムの開発を効率的にする道を示す。

 ところで、本書を読む前のこの段階で、ちょっと質問をさせていただきたい。 「ビジネスロジック部品とは何のことだとお考えになっていますか?」 と。

 一般には、汎用サブルーチンのことを思い浮かべる方が多いのではないだろうか? あるいは部品化再利用の話では定番になっているオブジェクト指向に基づくオブジェクトなるものがビジネスロジック部品になると主張する人もおられるに違いない。 これらの他にも、これこそがビジネスロジック部品であると宣伝されているものもいくつかある。 また、ビジネスロジック部品に対して漠然とした期待をもってはいるものの、その具体化は今後の課題だと考えている方も多いことだろう。 かと思うと、ソフトウェアに部品などというものは存在しないのだから 「ビジネスロジック部品とは何か」 という質問自体ナンセンスであると主張する人もおられる。 こういう方は、「汎用サブルーチンを単に組み合わせるだけでは、思いどおりの業務アプリケーションプログラムにはならない。 この程度のことは経験からお分かりだよね。」 と逆に痛烈な批判をあびせてくる。

 このように、ビジネスロジック部品とは何かについて定説があるわけではない。 ビジネスロジック部品やソフトウェア部品に漠然と期待をかける方がいる一方、そうしたものの存在を否定する方もおられる。

 本書は、ビジネスロジック部品に疑問を投げかける人々に明快な解答を提示するとともに、実用的で効果的な‘ビジネスロジック部品’とはどんなものかを明らかにする。 本書の‘ビジネスロジック部品’は、未開拓の分野に少数の人が取り組んで獲得した成果であり、この有用性を知らせる活動がまだ十分に行われていない。 そこで、この新たに開拓した‘ビジネスロジック部品’を真正面から取りあげて報告するのが本書である。 ただし、‘ビジネスロジック部品’そのものだけを説明しても理解しにくいと思われるので、本書では、その周辺のテクノロジーについても比較して論じることにした。 したがって、本書は‘ビジネスロジック部品’を解説する書であると同時に、既存の開発支援ツールの一部を解明する書にもなっている。

 本書は、ビジネス分野の業務アプリケーションプログラム開発を合理化することに興味のある方であれば、どなたにでも読んでいただけるように努めた。 このために、本書の論点に関係する話題を“トピック”という形で挿入して、少しでも分かりやすくなるようにした。 また、本書はいろいろな立場の方々の視点で論じるようにした。

 あえて言えば、本書は次のような方々に読んでいただくことを想定しているが、これら以外の方々も歓迎したいと考えながら書いた。

 ・ 企業の中で業務アプリケーションプログラムの開発に携わっている方、
  およびそれを利用されている方

 ・ 業務パッケージの開発に携わっている方、
  およびそれを利用されている方

 ・ お客様からのご注文に従って業務アプリケーションプログラムを開発されている方、
  およびその注文主の方 (お客様)

 ・ ここに挙げたような仕事をしたいと考えている学生の方

 ERP (enterprise resource planning) パッケージ (統合パッケージ) がよく話題になり、このことによって従来の業務パッケージも見直され、特注アプリケーションプログラムとの競争が発生している。 本書の‘ビジネスロジック部品技術’は、統合パッケージを含む業務アプリケーションプログラム一般の開発作業を合理化するものであり、その適用範囲はビジネス分野全体に及ぶ。 また、このテクノロジーは業務パッケージと特注アプリケーションプログラムの垣根を取り払う働きもある。 したがって、本書は、こういった広範囲な開発作業を合理化することに、必ずやお役に立つことと思う。

1998 年 4 月 
對馬 靖人 

p.s. ご意見をおよせください


改訂にあたって

 本書を執筆してから5年が経過した。 ここで用語の見直しなどを行い時代に合わせるとともに、タイトルを 「ソフトウェア部品」 から 「ビジネスロジック部品」 に変更した。 その理由は、世間一般に後述するような変なプロパガンダがなされていて“部品”に関する認識が捻じ曲げられているので、論点・焦点をより明確にする必要があると感じたからである。

 マイクロソフト社は、VBX (Visual Basic Extension) なるもの (その後 OCX と改名され、さらに ActiveX コントロールと改名されたもの) を部品として宣伝してきたが、これは画面デザインの際にフォームに貼り付けて使う GUI 部品である。“部品市場”を形成した功労者であるが、ビジネスロジック部品ではない。 また、サンマイクロシステムズ社が打ち出した EJB (Enterprise JavaBeans) なるものを部品だと言ってかついでいる人々もいるが、EJB はアプリケーションサーバと呼ばれる一種のミドルウェアとの相性がよい塊なのであって、ビジネスロジック部品とは言いがたい。 なぜなら、工夫に工夫を重ねないと EJB の再利用性を高めることができないからである。 ちなみに、大抵のソフトウェアは工夫を重ねることによって、再利用性を高めることができるものであり、EJB もその例外ではない。 EJB という形態にしただけで再利用性が高くなるとは言えないのである。 このような‘ビジネスロジック部品’まがいの出現によって“部品”への関心が高まったのは、結構なことであるが、本来の‘ビジネスロジック部品’の実力を 「この程度のもの」 と低く評価されることが心配でならない。

 本書の前身である 「ソフトウェア部品」 の中では実用的で効果的な部品と呼ぶための要件を明確にした。 しかし、多くの“部品”信奉者はこうした要件を考えもせずに“部品”という言葉を乱用しているのは全く困ったものである。 独自の要件を打ち出すなり本書で述べた要件に議論を交えるなりするのなら話は分かるが、宣伝のキャッチコピーとしてだけの“部品”はいただけない。

 しかし、そういった“部品”もある種の軽いノリの“部品”であるとみなすことができなくもない。 そこで、本書のタイトルを 「ビジネスロジック部品」 として、ビジネスロジックの 100 % 近くを部品だけでまかなえるのかというハードルを改めて設定したのである。

 さて、こうした世の中の動きを眺めると、業務プログラムの開発技術は進歩していないと思ってしまう。 そして“部品”なるものが話題になるだけで、まだ深く追求されていないことが分かる。 などと悲観的になったものの、着実な進歩もある。 というのは、本書の前身の執筆時に何と呼んだらよいのか分からなかった概念が、世間一般に通用する用語で表現できるようになってきたのである。

 たとえば、ごちゃ混ぜ (混雑) 状態の業務仕様に関係するプログラムと操作仕様に関係するプログラムを分離する大手術は、リファクタリングという言葉 (エクストリームプログラミングで使われている用語) をあてることができる。

 また、共通メインルーチンに関係して本書の 「ものを認識する際のの分離について」 で述べたことは、制御の反転 (inversion of control) という言葉を使って表現できる。

 さらに、本書の骨格ルーチン (スケルトン) は、フローズンエリアをカバーするプログラムであり、狭義のフレームワークだともいえる。 同様に、本書のスロットは、ホットスポットであり、本書の補填ルーチンユニット群は、フックメソッド群に他ならない。 しばらく時間を置いて眺めると、世の中の進歩が確認できる。

 こうした一般に流布している言葉とは別に、操作ベースなど新たに考えついた用語を使い始めた個所もある。 操作ベースとは、バックエンドにあるデータベースとは対照的にフロントエンドに位置する操作に関するプログラムのことである。そして、その形態はというと、狭義のフレームワークとして設計されることが普通である。

 最後に、創造的適応の必要度という長い用語を創適応の必要性と短くしたことをお断りしておく。 模倣による適応ではなく、創造的な (すなわちこれまで世の中に存在しなかったので新たに創めて生み出さなければない)“適応”という意味である。 ちなみに今回の用語のリファインは、創適応の必要性は低かったが、気を使う仕事であった。

2003 年 11 月 
對馬 靖人 

p.s. ご意見をおよせください


改改訂にあたって

 コンピュータ関係の時代の流れは相変わらず早いが、ところどころ流れがよどんでいる。 たとえば、業務アプリケーションの開発技術に関しては、渦が生じているのかもしれないが、大局的に見ると停滞している。 そのために、本書の存在意義は薄れていない。 というように、ここを書き始めたところである。 すでに改改訂の作業はあらかた済んでいるので、ここを書き終えれば、一段落ということになる。 (執筆中)

2008 年 4 月 
對馬 靖人 

p.s. ご意見をおよせください


執筆にあたって注意した点

 本書は、次のような注意を払って執筆した。 これらをご理解いただくことによって、本書をより上手に活用していただけることだろう。

 最初に用語について述べておこう。 ビジネス分野の業務アプリケーションプログラムの世界では、データ中心アプローチという考え方があり、同音異義語や異名同義語の使用を戒めている。 本書は基本的に、この戒めに従っているが、何点かの例外事項がある。

 異名同義については、基本的には避けるようにした。 しかし、あまりにも長い次の用語については、省略形 (ニックネーム) を用いた。 「業務アプリケーションプログラム」 を 「業務アプリ」 とし、「業務アプリケーションシステム」 を 「業務システム」 とし、「特注アプリケーションプログラム」 を 「特注業務プログラム」 と省略した。 ただし、プログラムであることを強調したい場合には、省略せずに 「業務アプリケーションプログラム」 などとしているところもある。また、この省略に伴い、「特注アプリケーションプログラム開発業 (界)」 を 「特注業務プログラム開発業 (界)」 と省略した。

 近い意味でも、微妙な違いのある言葉については、できるだけ慣用に従い、あえて統一していない。 たとえば 「ソフトウェア」、「プログラム」、「手続き (プロシージャ)」 とか、「遺伝子」、「DNA」 とかはこの典型である。

 同じ意味にもかかわらず、技術用語の出身母体の違いによって異なる言葉が当てられている場合がある。 こうした場合は、異名同義であることが分かるように努めたが、あえて統一していない。

 同音異義についてもできるだけ避けるようにした。 このために修飾語などを付けたり、表記を工夫して区別しやすいようにした。 たとえば 「システム」 という用語は、あいまいになりがちである。 そこで本書では、何らかの修飾語を付けて、「業務システム」、「生産管理システム」、「販売管理システム」、「部品化再利用システム」、「嵌め込み (はめこみ) システム」、「部品検索システム」、「部品管理システム」、「プロトタイプシステム」、「部品化アプリ再利用システム」 などとし、明らかに意味が分かる場合を除いて修飾語のない 「システム」 という用語を用いないようにした。 また、同音異義を避けるために、「case 文」 と 「CASE ツール」 のように書き分けたり、 違う種類の括弧を用いて『パラメタ』と 「パラメタ」 のように区別がつくようにしたりした。

 本書では、一般に使われている用語に、本書独特の意味付けをした場合には、シングルコーテーションで括ることで、区別がつくようにした。 これらには、‘ビジネスロジック部品’,‘ソフトウェア部品’,‘ビジネスロジック部品技術’,‘ソフトウェア部品技術’,‘ブラックボックス部品’および‘ホワイトボックス部品’がある。

 本書では、できるだけ一般に使われている用語の用法に従ったが、本書独特の用語も出現するそういう用語については、本文中にも説明があるが、「本書を理解するためのキーワード」 としてその意味をまとめておいた。 これらに加え、本書独特の意味付けをした用語についても同様である。 これらの説明の中には、用語と用語の関係なども明らかにしてあるので、適宜ご参照いただきたい。

 用語とは少し外れるが、本書の中のイタリック (斜体) の部分は、読者の方々への本書の読み方などに関する案内である。

 次に本書の執筆にあたっての姿勢について触れておく。

 本書は、‘ビジネスロジック部品’が実力以上にかいかぶられることもなく、また無視されることもなく、正当に評価されることを目指して書いたものである。 そして、大げさな言い方を慎むように気を配った。

 現代は、コンピュータが神の座から遊びの座に移る時代だとみることができる。 大昔、言葉や文字やその媒体の紙が、神のごとく扱われた時代のように、コンピュータが出現した初期には神格化された見方がなされた。 この名残があるためか、コンピュータを使ったのだから正確だとか、最適だとかという神話が今でも無批判に受け入れられる傾向にある。 こういった神話には、コンピュータを普及させる一種のマインドコントロールとしての効果があるので、コンピュータ関係者にとっては都合のよいことかもしれない。 したがって、これを矯正しようとする力は働かない。 しかし、コンピュータを神格化するのはもういい加減に止めにすべきである。 コンピュータは、文房具として使われ、ゲームなどのエンターテインメント分野の道具にもなっているのだから、もはや神話はふさわしくない。 ありのままの力を示した方がどれだけ分かりやすいか知れない。 コンピュータの世界には多様なテクノロジーが渦巻いていて、ただでさえ分かり難いのだから、幻想を生むような言い方は慎むべきである。 本書をまとめるにあたっては、少なくとも幻想を助長しないように、また場合によっては幻想を打ち消すように努めた。

 本書では、‘ビジネスロジック部品’そのものだけでなく、その周辺のテクノロジーとの比較も行っている。 こうすると、困ったことにそういうテクノロジーのいくつかを批判する結果になってしまった。 商業主義やそれに迎合するコンピュータジャーナリズムは、開発支援ツールについて実力以上に宣伝したり評価したりしていることがあるので、それを矯正することが必要だったのである。 そこで、いわば裸の王様は 「裸の王様だ」 とはっきり言う姿勢を貫いたつもりである。

 一般に、現代もてはやされているハイテク分野のキーワードにはオーバな点が多々見受けられる。 そういうものに慣れっこになっている方には、本書のような非センセーショナルな言い方は地味に映るかもしれない。 また、本書にはハイテクの香りが不足しているのでインパクトがないと思われるかもしれない。 ハイテク分野の変な常識である 「きらびやかでなければならない」 という不文律に従うと、本書は一刀のもとに切って捨てられてしまいそうである。 心あれば、ハイテク分野の輝きをもつキーワードに少しは疑いの目をもった上で、本書の‘ビジネスロジック部品’に接していただきたい。 また、本書はこれまで取り残されていた視点を開くものだから、時間をかけてじっくりと吟味していただきたい。 もちろん、本書を読むにあたっても、批判的な姿勢を保って‘ビジネスロジック部品’に関して言い過ぎがないかどうかを厳しく見ていただくようにお願する。

 本書は本来であれば、数式を使うことで物理学を明快に論じるのと同様に、プログラムの実例を示すことによって‘ビジネスロジック部品’について具体的に論じるべきだと初めは考えた。 ところが、一般にプログラムになれている方も他人の書いたプログラムを読むことに躊躇しがちだし、ましてやプログラムになれていない方にも読んでいただこうとするのだから、本書にはプログラムの例を含めるべきでないと考えた。

 なお、こうしたために本書の説明は具体的でないと思われる方もおられることだろう。 実際のプログラムのサンプルを使って本書の内容を確かめてみたい方は、インターネットで以下にアクセスすると、プログラムのサンプルなどの情報を得ることができる。

 http://www.applitech.co.jp/

 一般にプログラミングなるものは各個人の頭の中でなされる仕事であり、それを体験している人は全人口に比べてわずかであるし、その実態を示す努力があまりなされていない。 しかも、プログラミングをしている人を外部から観察するだけでは、なかなかその実態は捉え難くい。 そこで、本書ではプログラミングの本質を解き明かすことによって、プログラミングなるものに関する理解を深めていただけるように努めた。 なお、プログラミングに関して全く不案内な方は、「付録1.プログラムの実行とは」 を一読するようにお願いする。

 また、もしもこれまでプログラミングについて単なる想像によって推測していたことがあれば、それは一旦白紙にもどして、本書を読んでいただきたい。 たとえば、プログラムの作成はモノの製造に似ていると決め付けていたら、それを撤回し白紙に戻していただきたい。 また、ソフトウェア開発の生産性は簡単に数値化可能であると決めつけていたら、それについても同様である。

 最後に本書のメインテーマである部品化再利用システムに関係する注意事項にふれておく。

 本書の説明の流れは、業務パッケージに関する話題から始まっているために‘ビジネスロジック部品’は業種業務パッケージのカスタマイズ作業だけに関係するものだという印象を与えてしまうかもしれない。 しかし、実際にはそうではないことを、ここでお断りしておく。 当然メンテナンス作業にも効果的である。 また、より重要なことなのだが、既に開発済みのどこかの分野に隣接していて、共通化できそうな部分があるならば、新規アプリケーションプログラムの開発作業にも有効である。 たとえば、少なくとも第四世代言語 (4GL) が効果を発揮したようなビジネス分野においては、その分野で開拓された成果を再利用できるので、新規開発にも有効である。

 ただし、部品化再利用システムなるものは既開発の分野とつながりのない (ビジネス分野ともつながりのない) 全く新たな分野のソフトウェア開発には、残念ながら効果がない。 こうは言ったものの、新分野をひとたび開拓してしまえば、‘ソフトウェア部品’などが活躍できる舞台に変えることができるかもしれない。 もしも、そうできれば、新分野の開発成果を活用するために部品化再利用システムが効果を発揮できるようになる。 いずれにしても、開拓が済むまでの間はご支援できないということなのだ。 このことは、本書の‘ビジネスロジック部品’だけでなく部品化再利用システム一般に言えることである。 当然のことなのではあるが、誤解のないように付け加えておく。



本書を理解するためのキーワード

 ここには、本書独特の用語および本書独特の意味付けをした用語についての説明がある。

 一般に、プログラムの先頭部分では、そのプログラムで使う変数や定数の宣言をする習慣がある。 これにならって、本書の先頭部分のここで、変数や定数に相当する本書の重要なキーワードを説明しておく。

 以下はキーワード一覧である。クリックすると、その説明箇所に進む。

 4GL (第四世代言語) の操作ベース
 GUI の操作ベース
 RRR ファミリー
 SSS
 共通メインルーチン (狭義のフレームワーク)
 コピー実施型再利用
 コピー排除型再利用
 再利用による生産性の向上率
 創適応 (creative adaptation) の必要性
 ソフトウェア部品
 ソフトウェア部品技術
 データ項目部品
 特注対応業務パッケージ
 二段構えカスタマイズ
 ネタ (生産性を向上させるための)
 バブル (プログラムの中の冗長部分)
 汎用メインルーチン (狭義のフレームワーク)
 ビジネスロジック部品
 ビジネスロジック部品技術
 部品化アプリ再利用システム
 部品化イベント駆動方式
 部品化再利用システム
 部品カスタマイズ
 部品合成ツール
 部品セット
 ブラックボックス部品
 フレームワーク
 補正生産性
 ホワイトボックス部品

 これらの用語は、本文中にも説明があるので、ここはざっと目を通す程度にして、本文に進むことをお勧めする。 そして、用語の意味が分からなくなったときに、ここを参照していただけばよいだろう。


4GL (第四世代言語) の操作ベース

 何かがイベント駆動タイプの 4GL のイベントプロシージャを呼び出しているはずだと考えたときに気づく、その何かのこと。 つまり、4GL の操作ベースがイベントプロシージャを呼出し、各イベントプロシージャの実行の契機を決めている。

 なお、操作ベースを開発する際には、狭義のフレームワークという形態になるように設計するのが普通である。そして、操作ベースを上手に設計・開発できたならば、コピー排除型再利用ができるフレームワークとして、生産性を向上させる切り札になることだろう。

 この用語に関係する話題は 「3.2.2 第四世代言語」 あたりに登場する。


GUI の操作ベース

 何かが GUI アプリケーションプログラムのイベントプロシージャを呼び出しているはずだと考えたときに気づく、その何かのこと。 つまり、GUI の操作ベースがイベントプロシージャを呼び出しており、各イベントプロシージャの実行の契機を決めている。

 なお、GUI (graphical user interface) とは、ウィンドウの中に配置した各種のボタンやメニュー項目やリストボックスやテキストボックスなどの GUI コントロール (または widget とも呼ばれる) を用いたビジュアルな操作方法のこと。

 この用語に関係する話題は 「2.2.2-m オブジェクト指向と GUI 操作」 あたりに登場する。


RRR ファミリー

 ‘ビジネスロジック部品技術’を用いた SSS の後継製品。 SSS の開発時にはなかった新方式である部品化イベント駆動方式を採用。 販売管理、財務会計、生産管理などをカバーする ERP パッケージ (統合パッケージ) へと発展している。 RRR は、RRR ツールと RRR 部品セットから構成されている。

 この用語に関係する話題は 「3.2.3-q RRR ファミリーに向けた改善点」 あたりに登場する。


SSS

 ‘ビジネスロジック部品技術’を用いて開発された最初の販売管理業務向けの特注対応業務パッケージ。 約 2000 個のデータ項目部品からなり、カスタマイズしやすい点が特長。 SSS は、SSS ツールと SSS 部品セットから構成されている。 SSS の後継製品には RRR ファミリー がある。

 この用語に関係する話題は 「1.3-i データ項目に対応づけたプログラムの細分化」 あたりに登場する。


共通メインルーチン (狭義のフレームワーク)

 プログラムの中の下請け的な働きをする部分ではなく、メインルーチンとして働く部分に注目して、共通部分を括り出したもののこと。 大抵の開発プロジェクトにおいては、プログラムの中で下請け的な働きをする共通サブルーチンを括り出す習慣があるので、少し視点を変えれば共通メインルーチンも括り出すことができるはずである。

 共通メインルーチンの例としては、原始的なプログラムのひな型、古典的な嵌め込み (はめこみ) システムの骨格ルーチン、4GL の操作ベースGUI の操作ベース、狭義のフレームワークなどがある。 これらの多くは、主に操作に関係する処理において共通的に利用される機能をもつ。

 共通サブルーチンという見方だけしかしていなかった開発プロジェクトにおいては、それまで行わなかった共通メインルーチンを見つけ出す努力によって、それまで気づかなかった共通部分を見つけ出せるかもしれない。 もしも共通メインルーチンを見つけることができれば、それを再利用することによって、生産性を向上させることができる。

 オブジェクト指向言語を用いると、共通メインルーチンの記述がしやすくなる。 これは、いわゆる制御の反転 (Inversion of Control) に対応しやすいためである。

 この用語に関係する話題は 「3.2.2-n 4GL と嵌め込みシステム」 あたりに登場する。


コピー実施型再利用

 オリジナルのソフトウェアのコピーを作成してから、そのコピーを利用するという形態の再利用のこと。 なお、ソフトウェアを再利用する方法は、コピー実施型再利用の他に、コピー排除型再利用がある。

 コピー実施型再利用の例としては、プログラムのひな型を配布して、コピーしてから適当な修正を施すという開発がある。 また、プレ生成ツールを使った開発もコピー実施型再利用の一種である。

 コピー実施型再利用は、一見するとソフトウェアの開発スピードを上げ、単純生産性を高めるように思われる。 しかし、バブルでふくれたプログラムになり、メンテナンスの負荷を増大させることになりがちである。

 この用語に関係する話題は 「4.4-n 再利用によって生産性を向上させる二つの方式」 あたりに登場する。


コピー排除型再利用

 オリジナルのソフトウェアのコピーは作成せずに、それを指し示し参照することによって利用するという形態の再利用のこと。 なお、ソフトウェアを再利用する方法は、コピー排除型再利用の他に、コピー実施型再利用がある。

 コピー排除型再利用の例としては、汎用サブルーチンライブラリを充実させて徹底的に再利用することなどがある。 また、ポスト生成ツールを使った開発もコピー排除型再利用の一種である。

 コピー排除型再利用は、プログラムをふくらませないために見かけの生産性は向上しない。 しかし、それにもかかわらず生産性が向上したのと同等の効果を上げることができる。 そして、バブル資産を排除することになり、メンテナンスしなければならないソフトウェア資産を少なくする働きをする。

 この用語に関係する話題は 「4.4-n 再利用によって生産性を向上させる二つの方式」 あたりに登場する。


再利用による生産性の向上率

 再利用によって実質的にどれだけ生産性が向上するのかを表わす指標のこと。 単純生産性を補正生産性で割った商を求めることで、再利用による生産性の向上率の概略値が得られる。

 再利用により生産性を向上させる代表例は、‘ビジネスロジック部品技術’を用いることである。

 なお、再利用はコピー実施型再利用コピー排除型再利用の二つに分類できる。

 この用語に関係する話題は 「4.4-l 再利用による生産性の向上率」 あたりに登場する。


創適応 (creative adaptation) の必要性

 創造的適応の必要度合いのこと。 創造的適応、すなわち創適応とは、ある応用分野または領域に関するいろいろな要求に対応する際に、用意されたパラメタの設定という非創造的な手段ではうまくいかず、新たなプログラムを創造して対処すること。 創適応の必要性が小さい領域ではパラメタカスタマイズによって要求に対応できるが、創適応の必要性が大きい領域はそうはいかない。 そういう領域では、新たなプログラムを創造して適応させることが、すなわちプログラムカスタマイズが必要になる。 なお、ここでパラメタとは、パラメタカスタマイズのパラメタと同様に、外部からみて意味の明快な宣言的な情報のこと。

 一般にビジネス分野は創造的な発展があるために創適応の必要性が大きい。 しかし、例外的に財務会計に関しては、遵守すべき法律の規定という制約があり、創造的な発展が制約されているために創適応の必要性はあまり高くない。

 この用語に関係する話題は 「5.1-b 実用的で効果的な部品化再利用システムの要件その2」 あたりに登場する。


ソフトウェア部品

 ビジネスロジック部品を一般化したもののこと。

 ソフトウェアの部品化再利用システムで使用される部品セットの構成要素。

 ソフトウェア部品の代表例は、汎用サブルーチン。

 本書では、特別の性質を備えたソフトウェア部品のことを‘ソフトウェア部品’のような表記にしてある。‘ソフトウェア部品’には、汎用性を備えた‘ブラックボックス部品’と検索性、局所性、手頃な大きさ (粒度)、読みやすさの四つの性質をすべて備えた‘ホワイトボックス部品’がある。

 ‘ソフトウェア部品’の例としては、汎用サブルーチン、汎用メインルーチン、データ項目部品などがある。

 この用語に関係する話題は 「5.3‘ビジネスロジック部品’の意味と意義」 あたりに登場する。


ソフトウェア部品技術

 ‘ソフトウェア部品’を活用するというテクノロジーのこと。

 本書では、所定の性質を備えた‘ソフトウェア部品’を活用するテクノロジーのことを‘ソフトウェア部品技術’のような表記にしてある。

 ‘ソフトウェア部品技術’を用いると、プログラムカスタマイズ作業の生産性を高める“部品カスタマイズ”が使えるので、カスタマイズ作業がけた違いに簡単になる。

 この用語に関係する話題は 「5.3‘ビジネスロジック部品’の意味と意義」 あたりに登場する。


データ項目部品

 業務アプリをそれぞれのデータ項目に対応づけて分割した部品。 ビジネス分野ではデータ項目名によって仕様変更要求が表現されるので、データ項目部品の名前を、それぞれのデータ項目名で始まるものとすると、大袈裟な検索システムなしでも、簡単に検索できるようになる。

 データ項目部品は、検索性、局所性、手頃な大きさ (粒度)、読みやすさの四つの性質をすべて備えているので‘ホワイトボックス部品’の代表例だといえる。 なお、‘ホワイトボックス部品’は‘ビジネスロジック部品’または‘ソフトウェア部品’の一種であり、データ項目部品は‘ビジネスロジック部品’の一種。

 データ項目部品の例としては、商品コード部品、商品単価部品、得意先小売店名称部品など様々なものがある。

 この用語に関係する話題は 「1.3-i データ項目に対応づけたプログラムの細分化」 あたりに登場する。


特注対応業務パッケージ

 特注業務プログラムのように、顧客の特別な注文 (特注) にも対応する (対処できる) 業務パッケージのこと。 特注対応業務パッケージは、顧客の特別な注文にぴたりと合わせるために、何らかの形でプログラムカスタマイズを行うことが必要。 もしも、カスタマイズコストを低くおさえることができれば、特注対応業務パッケージは、特注業務プログラムに比較して大幅なコストダウンになる。

 特注対応業務パッケージの例としては、SSSRRR ファミリーがある。 これらは、部品カスタマイズによって、カスタマイズのコストを低くおさえている。

 この用語に関係する話題は 「1.3 特注対応業務パッケージ」 あたりに登場する。


二段構えカスタマイズ

 パラメタカスタマイズとプログラムカスタマイズの良いとこ取りをしたカスタマイズのこと。

 二段構えカスタマイズでは、よくあるタイプのカスタマイズ要求にはパラメタカスタマイズで対応して、それでは対応できないときに、プログラムカスタマイズという奥の手を使うという二段構えの方式を採用する。

 こうすることによって、ある範囲のカスタマイズ作業は、パラメタカスタマイズという手段で簡単に済むようになると同時に、顧客からのどんなカスタマイズ要求にも、プログラムカスタマイズによって対応できるようになる。

 この用語に関係する話題は 「1.1-b カスタマイズの方式」 あたりに登場する。


ネタ (生産性を向上させるための)

 ソフトウェア開発の生産性を向上させる施策、仕掛け、仕組み、理由、アイデアなどのこと。 生産性を向上させたい場合、いくつかのネタが候補としてあがるだろうから、それぞれのネタの効果を評価した上で、効果的なものから適用するのがよい。 そのためには、たとえば積み上げ方式などでそれぞれのネタの生産性の向上率を求めることが必要。

 ネタの例としては、古くから知られたものをあげると、アセンブラによるアドレス計算の代行、プログラミング言語から機械語への変換、各種のダイアグラムを記述する作業の支援、プログラムからドキュメントとして使えそうな情報の抽出など様々なものがある。

 この用語に関係する話題は 「4.2-e 生産性の向上率を求める実施検証」 あたりに登場する。


バブル (プログラムの中の冗長部分)

 プログラムの中の冗長な部分のこと。 一般に、同じ結果を出すようなプログラムは何通りも作れるが、それらの中で最もコンパクトなプログラムを基準にして、それにはバブルがないと考える。 こうした基準を設けると、それ以外のプログラムには、最もコンパクトなプログラムとの差の分だけのバブルが存在することが明確になる。

 バブルの代表例は、プログラムの中の無駄な部分 (取り除いても構わない部分) である。 この他にバブルの例としては、共通サブルーチンに書き換えることで、プログラムをよりコンパクトにできるにもかかわらず、そうしていない部分がある。 また、既にライブラリに登録済みのプログラムを再利用せずに、それに相当するものを新たに開発したならば、それもバブルである。

 この用語に関係する話題は 「4.1-c プログラムのミニマム情報量」 あたりに登場する。


汎用メインルーチン (狭義のフレームワーク)

 共通メインルーチンを汎用化したもののこと。 共通サブルーチンを汎用化すると汎用サブルーチンになるのと同様に、共通メインルーチンを汎用化すると汎用メインルーチンになる。

 なお、汎用化とは、そのルーチンがカバーする領域に対して、想定されるどのような要求にも部品セットからの部品選択やパラメタの指定によって対応できるようにすることをいう。 すなわち、汎用化するということは‘ブラックボックス部品’に求められる性質を持たせることに他ならない。

 オブジェクト指向言語を用いると、共通メインルーチンの記述がしやすくなる。 これは、いわゆる制御の反転 (Inversion of Control) に対応しやすいためである。

 この用語に関係する話題は 「5.2-g RRR ファミリーの構成法を一般化した構成法に照らすと」 あたりに登場する。


ビジネスロジック部品

 ソフトウェアの部品化再利用システムで使用される部品セットの構成要素。

 ビジネスロジック部品の代表例は、データ項目部品

 本書では、特別の性質を備えたビジネスロジック部品のことを‘ビジネスロジック部品’のような表記にしてある。‘ビジネスロジック部品’およびこれを一般化した‘ソフトウェア部品’には、汎用性を備えた‘ブラックボックス部品’と検索性、局所性、手頃な大きさ (粒度)、読みやすさの四つの性質をすべて備えた‘ホワイトボックス部品’がある。

 ‘ビジネスロジック部品’およびこれを一般化した‘ソフトウェア部品’の例としては、汎用サブルーチン、汎用メインルーチンデータ項目部品などがある。

 この用語に関係する話題は 「5.3‘ビジネスロジック部品’の意味と意義」 あたりに登場する。


ビジネスロジック部品技術

 ‘ビジネスロジック部品’を活用するというテクノロジーのこと。

 本書では、所定の性質を備えた‘ビジネスロジック部品’を活用するテクノロジーのことを‘ビジネスロジック部品技術’のような表記にしてある。

 ‘ビジネスロジック部品技術’を用いると、プログラムカスタマイズ作業の生産性を高める“部品カスタマイズ”が使えるので、カスタマイズ作業がけた違いに簡単になる。

 この用語に関係する話題は 「5.3‘ビジネスロジック部品’の意味と意義」 あたりに登場する。


部品化アプリ再利用システム

 部品化アプリを再利用する形態の部品化再利用システムのこと。 部品化アプリとは、アプリケーションプログラムをうまい具合に切れ切れにして、それぞれの断片が‘ビジネスロジック部品’または‘ソフトウェア部品’になるようにしたもののこと。

 本書では、部品化アプリ再利用システムという形態の部品化再利用システムにスポットをあてて論じている。

 部品化アプリ再利用システムを製品化した例としては、SSSRRR ファミリーなどがある。

 この用語に関係する話題は 「2.2 部品化アプリ再利用システムとオブジェクト指向」 あたりに登場する。


部品化イベント駆動方式

 一般のイベント駆動方式を改良して、イベントプロシージャが‘ホワイトボックス部品’に求められる性質を具備するようにした方式のこと。

 部品化イベント駆動方式を採用したツールの例には、RRR ツールの中核をなす MANDALA (マンダラ) がある。 一般のイベント駆動方式のイベントプロシージャはデータ項目ごとの区切りがぼやけがちであった。 部品化イベント駆動方式ではこの区切りを明確にすることが必要だということが分かり、MANDALA はアップデートプロパゲーション (更新伝播) の機構を用いて、これを実現した。

 この用語に関係する話題は 「3.2.3-s 部品を区切る分割指針に関する改善点その2」 あたりに登場する。


部品化再利用システム

 ソフトウェア資産を部品という形にして再利用するシステムのこと。

 部品化再利用システムは、通常、部品セット部品合成ツールから構成される。

 本書では、部品化アプリ再利用システムという形態の部品化再利用システムについてのみ論じている。

 汎用サブルーチンのライブラリとサブルーチンの組込み呼出し機構は、古典的な部品化再利用システムだと言える。 この古典的システムを‘ビジネスロジック部品技術’を用いて拡張すると、ビジネス分野の業務アプリを‘ビジネスロジック部品’および‘ソフトウェア部品’だけで構成可能な部品化再利用システムにできる。

 この用語に関係する話題は 「2.2 部品化アプリ再利用システムとオブジェクト指向」 あたりに登場する。


部品カスタマイズ

 ‘ビジネスロジック部品技術’を用いたアプリケーションプログラムに関するカスタマイズのこと。 つまり‘ホワイトボックス部品’を用いたプログラムカスタマイズのことである。

 部品カスタマイズは、広義のプログラムカスタマイズに分類されるものだが、一般のプログラムカスタマイズに比べてその作業量を桁違いに小さくできる。

 なぜなら、カスタマイズの対象となるプログラムの 100 % が“部品”(と呼ぶにふさわしもの) だからである。 つまり、‘ホワイトボックス部品’はその内部のプログラムに手を入れる作業が発生するのであるが、実にその種の作業負荷を軽減させる上で効果的な四つの性質 (検索性、局所性、手頃な大きさ、読みやすさ) をすべて備えているからだと言える。 ちなみに、本書ではこの種の性質を備えていないものは“部品”と呼ぶべきでないと主張している。

 部品カスタマイズの例としては、データ項目部品からなる業務プログラムに関するカスタマイズをあげることができる。

 この用語に関係する話題は 「1.3-j 特注業務プログラムか業務パッケージか (その3) 結論」 あたりに登場する。


部品合成ツール

 部品化再利用システムを構成するツールのこと。 なお、部品化再利用システムは、通常、部品合成ツールと部品セットから構成される。

 部品合成ツールは、指定されたビジネスロジック部品群を合成してアプリケーションプログラムに仕立て上げる働きをする。

 部品合成ツールの例としては、古典的な嵌め込み (はめこみ) システムや最先端の RRR ツールがある。

 この用語に関係する話題は 「3.2.3-q RRR ファミリーに向けた改善点」 あたりに登場する。


部品セット

 部品化再利用システムを構成する部品の集合のこと。 なお、部品化再利用システムは、通常、部品セットと部品合成ツールから構成される。

 部品セットの例としては、汎用サブルーチンのライブラリ、および RRR 部品セットの販売管理や財務会計などがある。

 この用語に関係する話題は 「3.2.3-q RRR ファミリーに向けた改善点」 あたりに登場する。


ブラックボックス部品

 中身のプログラムを解読せずに利用する (利用できる) 部品のこと。 すなわち、プログラムカスタマイズを一切の許さない部品であり、そのソースプログラムは開示しないことが普通。 これと対極をなすのがホワイトボックス部品

 本書では、汎用性を備えたブラックボックス部品については‘ブラックボックス部品’のような表記にしてある。‘ブラックボックス部品’は‘ビジネスロジック部品’または‘ソフトウェア部品’の一種。

 ‘ブラックボックス部品’の例としては、汎用サブルーチン、および汎用メインルーチンがある。

 この用語に関係する話題は 「5.2-f 部品化アプリ再利用システムの一般化した構成法」 あたりに登場する。


フレームワーク

 狭義には、共通メインルーチンまたは汎用メインルーチンのことと考えて、ほぼあたっている。

 広義には、共通メインルーチン汎用メインルーチンだけでなく、共通サブルーチン汎用サブルーチンなども含め、うまくモジュール分割 (部品分け) した成果のこと。

 この用語に関係する話題は 「3.2.1-j 嵌め込みシステムの第二の分かれ道」 あたりに登場する。


補正生産性

 単純生産性を補正することによって、“真の生産性、つまり完全にバブルを取り除いた生産性値”に近づけたもののこと。

 単純生産性は簡単に求められるが、これに頼ると、中身が詰まったコンパクトなプログラムを開発すると生産性が低く評価され、逆にふくれ上がったものを開発すると高く評価されることになる。 そして、プログラムをコンパクトにする努力を阻害して、バブルでふくらませる安直な手段を推奨することになる。 このような弊害を回避するために考え出されたモノサシが、補正生産性である。

 生産性の補正をするには、プログラムの中にバブルが見つかる度にその分を成果物の量から差し引いて、生産性の計算をしなおす。

 この用語に関係する話題は 「4.2-d プログラム行数を用いて算出した生産性の補正方法」 あたりに登場する。


ホワイトボックス部品

 中身のプログラムの解読が必要になる可能性のある部品のこと。 すなわち、ホワイトボックス部品とは広義のプログラムカスタマイズが必要になるかもしれない部品であり、そのソースプログラムは開示される。 これと対極をなすのがブラックボックス部品

 本書では、検索性、局所性、手頃な大きさ (粒度)、読みやすさの四つの性質をすべて備えたホワイトボックス部品については‘ホワイトボックス部品’と表記してある。‘ホワイトボックス部品’は‘ビジネスロジック部品’または‘ソフトウェア部品’の一種。

 ‘ホワイトボックス部品’の代表例は、データ項目部品。 なお、‘ホワイトボックス部品’に対するプログラムカスタマイズのことを特別に部品カスタマイズと呼ぶ。

 この用語に関係する話題は 「5.2-f 部品化アプリ再利用システムの一般化した構成法」 あたりに登場する。

アプリテック株式会社
アプリテック株式会社
Copyright © 1995-2008 by AppliTech, Inc. All Rights Reserved.