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

おわりに

 業務プログラムの開発作業に対して、これまで短中期的に (2 〜 20 年レンジで) 数々の対処療法が行われてきた。しかし、これこそが“銀の弾丸”だといえるようなものはなかったように思う。本来なら、長期的に (100 年レンジで) 将来きっと可能になると思われる 「本当の意味での業務プログラム開発の自動化」 を目指すべきだろう。しかし、そんなものは影だけで形がない現実を考えると、執筆を終えた今、本書の 「部品化再利用」 がますます現実的な“銀の弾丸”に思えてきた。

既に成熟状態にあるツール:

 業務プログラム開発を支援するツールは成熟状態にあり、新たに目覚しい効果を上げるようなものは当面期待できない状態だ。 なだらかな丘への主要ルートは既に開発し尽くされているのである。 その丘まではコンピュータという強力なエンジンが有効に働く。 もちろん、丘までの枝葉のルートはこれからも開発が進むだろうが、それは業務プログラムの開発作業をほんの少し便利にするだけのことである。

本当の意味での人工知能の技術はまだ見えていない:

 業務プログラムを開発するには、その丘からそびえ立つ険しい断崖の上まで登ることが必要である。 人間の柔軟な思考力をもってすれば、この崖を登ることは可能であるが、その崖はあまりにも険しいために、コンピュータ単独では歯が立たない。 その強力なエンジンを十分に活用するテクノロジーがまだ見つかっていないのである。 これまでにいろいろな観点から、この崖をコンピュータが駆け上がれるようにする試みがなされたが、どれも成功していない。

 丘の上の険しい崖は、延々と続いており果てしないようである。 「本当の意味でのコンピュータにアプリケーションプログラムを自動生成させる」 ことを目指すと、どの道を選んでもこの険しい崖にぶちあたってしまう。“業務プログラム開発の上流工程の知的支援”も“業務プログラムのリバースエンジニアリング”も人間が行うような高度な知的作業に迫ろうとするとこの険しい崖にはばまれてしまう。 問題が限定している“2000 年問題の解決”ですら、自動的にはできなかったのである。

 業務プログラムを完全に自動生成する幻のツールは、別の比喩を使うと中世の錬金術のように思われる。 もしも開発できたとすると、コンピュータ産業にとってそのインパクトは絶大である。 だから、ときどき 「金が生成できた」 と人騒がせな発言で注目をあびようとする人が現れる。

 基礎研究が進むと、行く手をはばむ険しい崖の正体が解明され、金は元素なのでその生成は無理だというようなことが分かるかもしれない。 そして、さらに研究が進むと核物理学に基づくテクノロジーが現れて、実際に金を生成することが可能になることだろう。 そのときこそ、人間に代わって未来のコンピュータが自力で険しい崖を駆け登れるようになるのだといえる。 それは、100 年先のことか、もっと先のことか分からないが、そういうタイムスパンで解決される問題だと思う。 小手先のアイデアで解決できることではない。

部品化再利用は現実解:

 このような認識のもとに現在何ができるのかを考えると、‘ビジネスロジック部品技術’を用いた部品化再利用が最善だと思われる。 なだらかな丘の上の険しい崖を登るのは人間でなければできないが、一旦登ったところは、いわばワイヤロープを垂らすなどして、コンピュータのエンジンを使うことができるのである。 これは、険しい崖をコンピュータ自らが駆け登るのとは異なるアプローチなので、現在のソフトウェアの技術レベルで十分に実現可能なことである。

現実のビジネス環境に目を向けると:

 さて、将来の展望はこれくらいにして、現実のビジネス環境に目を向けてもみよう。

 本書の執筆は、不況の真っただ中で行った。 そして、その内情を見ると本書で指摘したような慢性的なバブル状態が潜んでいる。したがって、合理化を進めて、バブル状態を解消していくことは、大きなビジネスチャンスと言えるのではないだろうか?

 カスタマイズやメンテナンスのことを考えずに人海戦術で大量のソフトウェアを作り続けていると、遅かれ早かれ競争力がなくなることは目に見えている。 なぜなら、多くのビジネス分野の業務プログラムに‘ビジネスロジック部品技術’を適用して、ぴたりと合う特注対応業務パッケージがリーズナブルな価格で供給されるようになり、厳しい自然選択がなされる時代になるからである。 また、海外からの ERP パッケージの進出は、業務パッケージへの関心を高めて、このような動きを後押ししている。

 そして、やがては業務プログラム開発に関する仕事がすっかり様変わりして、特注対応業務パッケージ開発業と、それを基に部品カスタマイズをして顧客(企業)の要求仕様に合わせるためのカスタマイズ業の分業化が進展することだろう。 つまり、“部品化する仕事”と“再利用する仕事”の分業化である。

 このような将来が予想されるので、ビジネス分野の業務プログラムの開発に関係している方々には、次のような方向に進むことをお勧めする。

 ・ 特定の業種・業務分野の業務プログラムのノウハウがあるのなら、それを特注対応業務パッケージに仕立て直して、カスタマイズ業者に供給する特注対応業務パッケージ開発業を始めるのがよいだろう。

 ・ 数多くのお客様をかかえているのなら、カスタマイズ業を始めて、お客様に競争力のある業務プログラムを提供するのがよいだろう。 なお、これはチューニングサービスという形に発展拡大していくことが予想される。

 ・ 自社向け業務システムがメンテナンス地獄に象徴される行き詰まり状態に陥りそうなら、‘ビジネスロジック部品’という形の洗練された資産体系に切り換えていくのがよいだろう。 そうすれば、メンテナンス地獄を回避するだけでなく、自社システムを特注対応業務パッケージとして外販する道も開ける。

 これらのいずれに対しても、‘ビジネスロジック部品技術’は、有効であり、必須だといえる。 合理化を進めて、バブル状態を解消する中にビジネスチャンスを求めるのであれば、このテクノロジーを活用することを強くお勧めする。

 なお、インターネット上の下記の Web ページに、本書の内容に基づく‘ビジネスロジック部品’のプログラムサンプルなどを掲載しておくので、ご参照いただきたい。 それから、本書の内容に関する感想や意見などは下記「ご意見をおよせください」へお送りくださることをお待ちする。

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

 末筆になったが、ウッドランド株式会社において SSS を開発された元社長の柴田隆介様と開発主任の大西司様からは SSS の開発思想に関する教えをいただいた。 感謝の意とともに、その独創性に敬意を表したいと思う。 そして、元会長の浅田隆治様と元取締役の尾崎穣治様からは、RRR ツールを分担開発する中で有益な意見をいただき、本書をまとめる際にも大変参考になった。 この本ができたのは、これらの皆様のおかげであり、ここにお礼を申し上げる。

 本書の草稿はインターネット上の Web ページに2年間ほど掲載していた。 これをご覧になった多くの方々から、はげましやご意見をいただくことができた。 あらためてお礼を申し上げる。 特に先輩の吉田征教授には、200 個所にも及ぶご指摘をいただき、本書をまとめる上で大いに役立った。 ここにお礼を申し上げる。

2008 年 4 月
對馬 靖人 

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



付録1.プログラムの実行とは

 この付録では、プログラムを実行するとは、どういうことなのかという説明から始めて、合わせてこの周辺の事柄をご紹介する。

 プログラムを実行するということは、本を読んだり、音楽を演奏したりするのと同様に、時間の経過とともに“あること”を進めていくことである。 ここで“あること”とは何かというと、本の場合には、人間の目が各ページの字を追いながら理解していくことであるし、音楽の場合には、人間の目が楽譜の音符を追いながら音を出していくことであるし、プログラムの場合には、コンピュータの CPU がプログラムの中の文 (命令文) を追いながら演算をしていくことである。 つまり、コンピュータの中には CPU という装置があって、人間の目が字や音符を追うのと同様に、CPU が文を追っていくのである。 ただし、コンピュータは、人間には太刀打ちできないスピードでこれを行う。 すなわち1秒間に数百万から数千万にも及ぶ文を追いながら演算をしていくのである。 ここがコンピュータパワーの原点である。

 ところで、楽譜の中の音符は 「ある音を出せ」 と命じていると捉えることができる。 楽譜の音符を追いながら音を出していくのが演奏なのだから、各音符はそれぞれの音を出せと命じているのだとみなせるわけだ。 これと同様に、プログラムの中の文は、足し算を行えとか、大小の比較をせよとか、というように、どのような演算を行うのか命じているものだと捉らえることができる。 したがって、これらの文は命令文だということができる。

 楽譜の中には、繰り返し演奏することを命じる記号や楽譜の中の指定の所にジャンプすることを命じる記号 (前述の音を発することを命じる記号とは役割が異なる) がある。 これらと同様に、プログラムの中にも、繰り返し演算することを命じる命令文やプログラムのある点にジャンプすることを命じる命令文 (前述の演算することを命じる命令文とは役割が異なる) がある。 これらの役割が異なる記号や命令文は、演奏の流れを制御したり、プログラムの流れを制御したりするものである。 なお、本書で制御構造と言っているのは、プログラムの流れを制御する命令文の書き方のことである。

 プログラムを開発するには、プログラミング言語を用いるのが普通だ。 プログラミング言語は、自然言語と異なる人工的な言語であり、例外のない文法をもち、語彙もわずかである。 いわば、コンピュータに命じるだけの単純な言語である。 このような違いがあるが、似ている点もあり、共通の言い回しをする。 自然言語を使って文を書くのと同様に、プログラムを開発することを 「書く」 とか 「記述する」 とか 「作る」 とか 「作成する」 とか、あるいは 「組む」 と言う。 なお、プログラムを書くときに少しでも間違えると、CPU は人間が意図した処理とは異なる処理をしてしまうことになる。 CPU は命じられたとおりのことしかしない。 人間の意図をおもんぱかることはないのである。 そこで、デバッグが必要になる。 デバッグとは、CPU が人間の意図した処理から外れる動作をするかどうかをチェックして、必要に応じてプログラムを正すことである。

 プログラミング言語は、語彙がわずかなので、複雑な表現がしにくいことがある。 このような場合、 いわば新たな単語に相当するサブルーチンを定義して、サブルーチンを使うことで複雑な表現を簡略化する仕組みがある。 これは、部品化再利用の仕組みだといえる。 複雑な意味をもつ用語を使うことで文章を短くできるのと同様に、サブルーチンを使うことでプログラムを短くできるのである。 なお、サブルーチンを使うことを 「呼び出す」 と言う。

 CPU が文を追っていくスピードは、1秒間に数百万から数千万にも及ぶために、小さなプログラムは、すぐに実行が終わってしまいそうである。 しかし、プログラムの流れを制御することによって、たとえば何回もループさせることができるので、小さなプログラムであっても、高速の CPU に演算を実行させたにもかかわらず1時間もかかるような科学技術計算もある。 他方、ビジネス分野の業務アプリケーションプログラムは、一般に科学技術計算のような複雑な計算はしないものである。 しかし、ビジネス分野では大量のデータを取り扱うことが普通であり、そのために繰り返し同じような処理を大量に行うことが多い。

 プログラムに関する理解を深めるには、他人の書いたプログラムを読んだり、自分でプログラムを書いたりしてみることが近道である。 たとえば、Windows 系 OS を搭載した広く使われているパソコンがあれば、マイクロソフト社のビジュアル開発支援ツール Visual Basic を用いることで、簡単にプログラムを書いて実行させることができる。 Visual Basic には、プロの開発者向けの機能だけでなく、ホビープログラマ向けの機能もあるので、プログラミングの入門には最適だといえよう。 なお、本書を理解する際に、イベント駆動方式に習熟していると好都合なので、イベント駆動方式が採用されている Visual Basic を使ってみることをお勧めする。



付録2.ビジネス分野の業務プログラムの一般的な特徴

 この付録では、ビジネス分野の業務プログラムとは、どのような特徴をもっているのか、最も注目すべき特徴を三つ挙げてみる。

◎ ビジネス分野の業務プログラムはバラエティに富む

 業務処理の内容は、各会社の歴史的な経緯、トップの方針、各部門の力関係、特殊な業務遂行の方法 (企業特性)、取り扱う商品やサービスの種類、業界の慣行、関心事 (業種特性)、および他社差別化を図るための創造的な活動などの要素に依存しているために、バラエティに富む。 したがって、たとえば A 社向けの業務プログラムは、そのままの形で B 社に適用できるわけではない。

 また、一般にビジネス分野は創適応の必要性が大きいので、業務パッケージを開発してパラメタの設定によって A 社向けにしたり、B 社向けにしたりとカスタマイズできるようにしたとしても、別の C 社からは、パラメタに値を設定するだけでは対応できないような変更要求が出されることが、しばしばあるものである。

◎ ビジネス分野の業務プログラムは多種類のデータを取り扱う

 ビジネス分野の業務プログラムが取り扱うデータの種類は、数百から数万に及ぶことが普通である。 そして、それぞれのデータの種類をデータ項目と呼び、データ項目名を付けて区別する習わしである。 たとえば 「商品コード」 とか 「売上日付」 などのデータ項目名によって、どんな種類のデータかということが一目瞭然になる。

◎ ビジネス分野の業務プログラムは大量の繰り返しデータを取扱う

 ビジネス分野の業務プログラムの取り扱うデータは、種類が多いだけでなく、量も多いのであるが、それらは単純な繰り返しデータである。 この種のデータは、何種類かのレコードというデータの入れ物を設けて、そこに格納するのが常套手段である。 レコードとは関係するいくつかのデータ項目の値を収めた入れ物であり、数多くのレコードを設けることによって、そこに大量の繰り返しデータを格納することができる。

 そして、ある一件のレコードに関するプログラム手続きを同種の数多くのレコードに適用ことによって、大量のレコードを次から次へと順番に、または要求のあるごとにそのレコードを、処理することができる。 なお、あるレコードを処理している最中は、そのレコードの内容が変更される可能性のあるクリティカルな状況なので、そのレコードを他からアクセスすることを禁止するための、排他制御が必要になる。 また、各伝票を処理するごとに複数のレコードをディスクなどの不揮発性媒体に書き出す場合には、トランザクション制御が必要になる。

 ビジネス分野の業務プログラムとは対照的に、科学技術分野では、しばしば少数のデータを基にして非常に奥深い計算を行う。 いわば奥の深い“うなぎの寝床”の様相を呈する。 これと同様な表現をビジネス分野の業務プログラムに関して行うと、間口が広く奥行きの浅い“縁日の露店の並び”の様な姿がうかがえる。 というのは、業務プログラムを構成するプログラムにおいては、各データ項目に関するそれぞれの演算はそんなに複雑ではないのであるが、取り扱うデータ項目の種類が莫大だからである。

 なお、このような特徴をもつビジネス分野の業務アプリケーションプログラムを分割して、データ項目と対応づけたとしたら、各プログラムの断片がどうなるのかを考えていただくと、本書の内容に納得していただけると思う。



付録3.積み上げ方式で生産性の向上率を求める例

 積み上げ方式で生産性の向上率を求める際には、どうしても主観や感性に頼らざるを得ない部分がある。 主観的な要素がどの程度幅をきかしているのかは、実際に見積作業を行ってみると実感できる。 この付録では、そのような試みをする際の参考にしていただくために、ある一つのネタ (材料、施策、仕掛け、仕組み) の効果を見積もる過程をレポートしてみる。

 なお、積み上げ方式で生産性の向上率を求める一般的な説明は 「4.2 ソフトウェア開発の生産性の計り方いろいろ」 にある。

 ここでは、見積もる際にいろいろと配慮が必要なネタ、すなわち見積もり作業が難しいネタを選んでみた。 それは、CASE ツールに組み込まれているポピュラーなネタの一つであり、上流工程 CASE ツールによって各種のダイアグラムを記述する作業を支援することである。 このネタは、広い意味では要求仕様の明確化作業を支援するものであり、具体的にはダイアグラムを記述する際にワープロ的な支援をするものである。 そして、このネタには、直接的および間接的な省力化効果があるので、それぞれを支援対象作業の割合と省力化の割合の積として見積もることにする。

 まず、直接的な効果を見積もってみる。 要求仕様の明確化作業は開発作業全体の延べ 20 %ほどに及ぶこともあり、その中には注文主やエンドユーザとのインタビューなど様々な作業が含まれている。 ダイアグラム作成作業は、その中の一部であることを考えると、支援対象作業の割合は多く見積もっても開発作業全体の延べ5%程度だろう。

 これについての省力化の割合はどう見積もるべきか、意見が分かれるところだろう。 単にダイアグラムを作成するためのいわばワープロとして修正作業を支援しているだけのことであり、それ以上の支援はないという見方もあり得る。 実際にダイアグラムとして書くべき内容は、人間が頭に浮かべたものであり、どういうダイアグラムを頭に浮かべるべきかについての支援があるわけではない。 したがってこの支援で得られる効果は限られているように思われる。 しかし、このネタは書き直しを億劫なものではないと思わせるので、考え落ちを見つけることに躊躇をなくす心理的な効果がある。 これら以外にも何らかの協調的効果があるかもしれない。 あれやこれやを考えて、このネタによる省力化の割合をここでは、仮に 40 %だとみなすことにしよう。 こうすると、このネタによる直接的な省力化率は、支援対象作業の割合が延べ5%であり、省力化の割合が 40 %なので、これら割合の積である。 2%だと見積もることができる。

 この2%という値は直接的な支援だけについての見積なので、この他に間接的な支援も計算に入れなければならない。 すなわち、ダイアグラムを作成した後の要求仕様の実現 (インプリメント) 作業に関する効果の計算も必要である。 もしも要求仕様の明確化が不十分であったために発生させていた後工程の無駄な作業があれば、それを少なくするという意味での間接的な支援があるはずである。 つまり、このことによって、生産性を向上させているのである。

 この間接的な効果も、直接的な効果と同様に、支援対象作業の割合と省力化の割合を見積もってから、その積を計算する。 まず支援対象作業の割合の方は開発作業全体の延べ 80 %だと見積もることにする。 次に省力化の割合はどうかというと、要求仕様を把握する際によく誤りを犯す開発プロジェクトかどうかに依存して、その値が違ってくるし、またその誤りに気づく時期にも依存する。 誤りが多い開発プロジェクトでは生産性を向上させる余地があるので、この間接的な効果の数値が大きくなるはずである。 そこで、要求仕様を把握する際の誤り率を x だと仮定し、誤りに気づく時期は平均して作業の中間であるとして見積もることにする。 こう仮定すると、後工程で 0 〜 0.8x ほどの無駄な作業を行っていたはずであり、平均すると 0.4x の無駄な作業をなくすことができるといえる。

 ここまで準備すれば、このネタを適用する前と後の間接的な効果を比較できる。

 このネタを適用する前、すなわち鉛筆と消しゴムでダイアグラムを作成していたときに、たとえば要求仕様を把握する際に平均して 20 %の誤りがあったとすると (つまり x を 20 %と仮定すると)、後工程において平均8% (80 %×20 %×1/2) の無駄な作業を実施していたはずである。

 このネタを適用した後、すなわち誤りを少なくすべくダイアグラムの作成支援を行うツールを使うことによって、要求仕様を把握する際の誤り率が 20 % から15 %に低下したとしよう。 すると無駄な作業は平均的に8%から6% (80 %×15 %×1/2) に減らすことができる。

 よって、このネタを適用することによって平均して2%の無駄な作業を省けることが分かる。

 この間接的な効果を前述の規定の形式で表現すると、支援対象作業の割合が延べ 80 %であり、省力化の割合が 2.5 % (誤りが5%だけ減り、それが工程の中ほどで検出されるとした) なので、これらを掛け合わせた2%が間接的な省力化率だというように計算できる。

 これらの効果を積み上げる (すなわち累積する) と、省力化率は直接的な2%と間接的な2%を加えた4%になる (図A3-1 参照)。


 要求仕様を把握する際に平均して 20 % の誤りを犯す開発プロジェクトにおいて、ダイアグラムを記述する作業を手書きから CASE ツールを使うように切り換える場合の省力化率の計算例:

      図A3-1: 省力化率として得られた値


 なお、ここでは要求仕様を把握する際の誤り率を 20 %と仮定したが、誤り率がもっと高い開発プロジェクトの場合にはもっと生産性を向上させることができるし、そうでない場合にはあまり生産性を向上させることができない。 つまり、既にいろいろな工夫をしている開発プロジェクトの生産性を向上させるのは簡単ではないという至極当然のことなのである。

 また、ここでは既にダイアグラムに書き下すという手法を用いている開発プロジェクトを想定して、効果の見積もりをした。 しかし、その手法をまだ用いていない開発プロジェクトであれば、その手法とこのツールを用いることによって、これらを合わせた効果が期待できる。

 繰り返しになるが、ここでは 「CASE ツールが与えてくれるダイアグラム作成支援というネタによって、4%ほど省力化でき、生産性が 1.042 (1/0.96) 倍になる」 というようなことを主張しているわけではない。 上記の計算はいろいろな仮定が入った値であり、この値が独り歩きすると誤解を生むことになる。 ここでの説明の狙いはあくまでも見積方法にあったのであり、皆様が適当なネタを取りあげて生産性の向上率を見積もる際に、これを参考していただきたいと考えただけのことである。 さあ、どんな見積値が得られるか、適当なネタを選んで是非とも試してみていただきたい。



付録4.ものを認識する際の図と地の分離について

 人間がものを認識する際には、何らかの概念やイメージに照らし合わせるという脳の中での内部的な操作があるようだ。 この際にとその背景のとの分離 (線引き) がなされて、ものが認識できるようになる。 すなわち、ある概念やイメージにうまくマッチングできた部分が図として浮かび上がってきて認識できるということである。

 図A4-1 に示す 「向かい合う二つの顔と壺」 の絵は、二つの認識ができるので有名である。 白いところを図と捉らえると (黒いところが地になって) 壺だと認識できるし、黒いところを図と捉らえると (白いところが地になって) 二つの顔だと認識できる。


      図A4-1: 向かい合う二つの顔と壺

 これまでのソフトウェア開発では、サブルーチンをと捉らえる見方が一般になされていて、大抵の開発プロジェクトでは積極的に共通サブルーチンを括り出すことが行われていた。 しかし、メインルーチンの方をと捉らえる見方は思い付かなかったので、共通メインルーチンを見つけ出す努力はなされていなかったのではなかろうか。 後者の見方をすると従来とは異なる認識ができるので、これまで見えていなかった共通部分が見つかる可能性がある。

 ちなみに、オブジェクト指向の用語に制御の反転 (Inversion of Control) があるが、こうした逆転の発想に基づく認識と関係している。

 ところで、メインルーチンとサブルーチンとの関係は、絶対的なものではない。 極めて相対的なものである。 したがって、ある一つのルーチンを取りあげると、それは他のルーチンを呼び出すメインルーチンである。 と同時に、他のルーチンから呼び出されるサブルーチンでもあることがある。 このような二面性から、次のような誤解を受けることがある。 それは、メインルーチンのことなど気にせずに、従来どおりサブルーチンを括り出すことだけを考えればよいという誤解である。

 ここで問題にしているのは、共通部分を発見するときのものの見方であって、サブルーチンという形にするかどうかという実現 (インプリメント) 方法を問題にしているわけではない。

 実現方法について言うと、1行のプログラムからなる根源的なメインルーチンをつくれば、他のルーチンをすべてサブルーチンにしてしまうという芸当も可能である。 なぜなら、メインルーチンだと見なされるものがあったならば、それを (根源的なメインルーチンから呼び出される) サブルーチンに変えることは非常に簡単なので、それらすべてをサブルーチンにできることは明らかである。 したがって、この観点からはサブルーチンだけで事足りる。 ただし、こうしたとしても、今まで見つからなかった共通部分が見つけやすくなることにはならない。

 問題は、共通部分を見つけるためのものの見方である。 呼び出す側呼び出される側との間に適当な線引きをして、共通部分を見つけようとするときに、従来は呼び出される側の共通性ばかりに目が向いていた。 このために、呼び出す側の共通性が見えていなかった。 見つけようとしなかったのだから、見つからなかったのも当然である。 呼び出す側の共通性に注目すれば、そうした共通部分の存在が見えてくるものであり、嵌め込みシステムの骨格ルーチン、ある操作仕様を実現している操作ベース、4GL の操作ベース、GUI の操作ベースなどは共通メインルーチンだということが分かってくる。 分かってしまうと簡単なことなのだが、気がつかないと共通部分を見逃してしまうものである。

 なお、呼び出す側の共通部分が見つかれば、それをどういう形に実現させるのかは全く自由である。 実際に呼び出す側の共通部分は、その中にローカルなメインルーチンやサブルーチンをもつ構成にすることが普通である。 これは、呼び出される側の共通部分 (従来のサブルーチンの構成) の中にもローカルなメインルーチンやサブルーチンの関係があるのと同様である。



付録5.部品化アプリ再利用システムの一般化した構成法

 この付録では、まず、実用的で効果的な部品化再利用システムにするための三つの要件を元にして、部品化アプリ再利用システムの一般化した構成法をどのようにして導き出したのか、その過程を説明する。 次に、もしもあるソフトウェア製品をこの一般化した構成法に従って部品化アプリとして構成できれば、すなわちこの一般化した構成法に従った部品化アプリ再利用システムが存在すれば、そのシステムは確かに三つの要件を満たしているという定理の証明をする。

 実用的で効果的な部品化再利用システムにするための三つの要件とは、次を指している。

 ・ 部品を組み合わせるだけでソフトウェア製品ができあがるものであること

 ・ どんなカスタマイズ要求にも対応できるものであること

 ・ 大勢の開発者が組織的に部品化再利用の恩恵にあずかれるものであること

 また、部品化アプリ再利用システムの一般化した構成法とは、次を指している。

 ・ ソフトウェア製品がカバーする領域を創適応の必要性が小さい領域と大きい領域の二つに分割する

 ・ 次の性質 (すなわち‘ブラックボックス部品’に求められる性質) を備えた‘ビジネスロジック部品’または‘ソフトウェア部品’によって創適応の必要性が小さい領域をすべてカバーする

  - カバーすべき領域に想定されるどんな要求にも部品セットからの部品選択やパラメタの指定によって対応できる (汎用性)

 ・ 次の四つの性質 (すなわち‘ホワイトボックス部品’に求められる性質) をすべて備えた‘ビジネスロジック部品’または‘ソフトウェア部品’によって創適応の必要性が大きい領域をすべてカバーする

  - 目指す部品が簡単に捜し出せる (検索性)

  - 修正すべき部品の数が限定される (局所性)

  - 一つ一つの部品のサイズが手頃である (手頃な大きさ)

  - 一つ一つの部品が解読しやすい (読みやすさ)


付録5-a 部品化アプリ再利用システムの一般化した構成法を導き出した過程

 部品化アプリ再利用システムの一般化した構成法は、以下のように考えて導き出した。

 少なくともビジネス分野では、汎用サブルーチンだけでアプリケーションプログラムを構成できることはめったにない。 なぜなら、汎用サブルーチンがカバーしているのは創適応の必要性が小さい領域だけであり、創適応の必要性が大きい領域は手つかずのまま残ってしまうからである。 したがって、創適応の必要性が大きい領域をカバーするために、汎用サブルーチン以外の何らかの新たな“部品”すなわち‘ソフトウェア部品’のようなものが必要になる。 なお、汎用サブルーチンだけで創適応の必要性が小さい領域のすべてをカバーしようとがんばるよりも、共通メインルーチンなども併用することが一般には必要になるものである。

 これらのことから、汎用サブルーチン以外の何種類かの‘ビジネスロジック部品’または‘ソフトウェア部品’を組み合わせて用いることになると予想して、汎用ルーチン以外の‘ソフトウェア部品’の探索を始めた。

 ところで、なぜ創適応の必要性が大きい領域が汎用サブルーチンでカバーできないのかを考えてみると、それはプログラムカスタマイズを許さないという前提があるためだということが分かる。 もしもプログラムカスタマイズを認めれば、創適応の必要性が大きい領域をカバーできるはずである。

 そこで、上記の考察をヒントにして、プログラムカスタマイズを一切の許さない部品と、それを覚悟する部品とに分けてみることにした。 そして、前者をブラックボックス部品、後者をホワイトボックス部品と名づけることにした。

 この後に、それぞれの部品のあるべき姿を探るために、上記の三つの要件のうちの二番目と三番目の要件を満足するかどうかをチェックしてみた。

 ブラックボックス部品だけで部品化再利用システムを構成すると、大勢の開発者が組織的に部品化再利用の恩恵にあずかることができるが、対応できるカスタマイズ要求の範囲が限られてしまう。

 ホワイトボックス部品だけで部品化再利用システムを構成すると、どんなカスタマイズ要求にも対応できるが、組織的な部品化再利用が困難なシステムになってしまいそうである。

 いずれにしても、三つの要件のうちの二番目と三番目の要件を両立させることは簡単ではない。 そこで、プログラムを創適応の必要性が小さい領域と大きい領域の二つに分けて、それぞれを個別に攻略する方向を模索してみた。 つまり、それぞれの領域をブラックボックス部品とホワイトボックス部品に分担させようと考えたのである。

 まず、創適応の必要性が小さい領域については、ブラックボックス部品でカバーできるはずだという予想を立てた。 そして、実際の「この予想どおり」と言えるようにするにはどうあるべきかを考えた。

 ブラックボックス部品を使うと、対応できるカスタマイズ要求の範囲が限られてしまうという点が問題になる。 ところが、創適応の必要性が小さい領域は、どんなカスタマイズ要求があり得るのか、あらかじめ想定できる領域 (すなわち扱いやすい領域) なので、パラメタカスタマイズだけで対応できるはずである。 このように考えて、ブラックボックス部品が以下に述べる汎用性という性質を備えていればよいと判断した。 なお、この性質を‘ブラックボックス部品’に求められる性質と呼ぶことにする。

 ・ カバーすべき領域に想定されるどんな要求にも部品セットからの部品選択やパラメタの指定によって対応できる (汎用性)

 ブラックボックス部品がこの性質を備えていれば、カバーすべき創適応の必要性が小さい領域に想定されるどんなカスタマイズ要求にも部品セットからの部品選択やパラメタの指定によって対応できる。 したがって、ブラックボックス部品によって、創適応の必要性が小さい領域をカバーできることになる。 なお、この性質を備えたブラックボックス部品は、本書の‘ビジネスロジック部品’または‘ソフトウェア部品’の定義に合致する。 そして、こうしたブラックボックス部品を本書では‘ブラックボックス部品’と表記している。

 次に、残りの創適応の必要性が大きい領域については、どんなカスタマイズ要求にも対応できるようにするためにホワイトボックス部品でカバーせざるを得ないと考えた。 こうした場合に問題になるのは、どうやってホワイトボックス部品を“大勢の開発者が組織的に再利用できる”ようにするかという点である。

 そこで、この問題をブレークダウンして考えてみたところ、次の四つの性質が浮かび上がってきた。 そして、もしもホワイトボックス部品がこれらの性質をすべて備えていれば、大勢の開発者が組織的に再利用できるものと思われた。 なお、これら四つを合わせて‘ホワイトボックス部品’に求められる性質と呼ぶことにする。

 ・ 目指す部品が簡単に捜し出せる (検索性)

 ・ 修正すべき部品の数が限定される (局所性)

 ・ 一つ一つの部品のサイズが手頃である (手頃な大きさ)

 ・ 一つ一つの部品が解読しやすい (読みやすさ)

 もしも、この四つの性質をすべて備えた‘ホワイトボックス部品’によってプログラムを構成できれば、大勢の開発者による組織的な再利用が可能になる。 なぜなら、あるカスタマイズ要求に対処する場合に、目指す部品がすぐ見つかり、それは限られた一つか二つの部品に限定され、その一つ一つの部品はそんなに大きなものではなく、また解読しやすいものだからである。 言い換えると、検索性のおかげで、従来ありがちであった気ままなモジュール分割に悩まされてうろうろすることもないし、局所性と手頃な大きさと読みやすさのおかげで、プログラム全体をなめまわすように解読する必要もない。 少しばかりプログラムの解読は必要であるが、それは大勢の開発者が組織的に再利用する上で許容できる範囲だといえる。 いや、逆に解読作業が許容範囲におさまるように、十分な検索性や局所性や手頃な大きさや読みやすさを‘ホワイトボックス部品’に求めているのだと考える方が分かりやすいかもしれない。

 したがって、もしもこうした性質をすべて備えた‘ホワイトボックス部品’であれば、大勢の開発者による組織的な再利用が可能である。 そして、ホワイトボックス部品はプログラムカスタマイズを覚悟したものなので、創適応の必要性が大きい領域をカバーできる。 なお、これらの性質をすべて備えた‘ホワイトボックス部品’は、本書の‘ビジネスロジック部品’ または‘ソフトウェア部品’の定義に合致する。 そして、こうしたホワイトボックス部品を本書では‘ホワイトボックス部品’と表記している。

 ここでは、‘ホワイトボックス部品’に求められる性質として上記の四つを挙げて、これらの性質をすべて完備することとしたが、ひょっとすると、これ以外にも適切な性質の組合せがあるかもしれない。 これについては深く追求していない。 興味をもたれた方は、考えてみてはいかがだろうか?

 以上が、部品化アプリ再利用システムの一般化した構成法を導き出した過程である。

 ここで、注意事項が一つある。 厳密にいうと創適応の必要性が小さい領域をカバーするのは、‘ブラックボックス部品’でも、‘ホワイトボックス部品’でも、これらの組合せであっても構わない。 とは言っても、できれば‘ブラックボックス部品’でカバーする方が望ましい。 なぜなら、プログラムへの手入れが不要にできればそれに越したことはないからである。 プログラムへの手入れが必要になる (かもしれない)‘ホワイトボックス部品’はできる限り少なくして、‘ブラックボックス部品’でまかなえるならば、そうすべきである。

 なお、創適応の必要性が大きい領域は、‘ブラックボックス部品’でカバーすることができないことは、既に説明してあるとおりである。 だからこそ、‘ホワイトボックス部品’の登場が必要だったのである。


付録5-b 三つの要件を満たすという定理の証明

 ここでは、あるソフトウェア製品を上記の一般化した構成法に従って部品化アプリとして構成できれば、すなわち上記の一般化した構成法に従った部品化アプリ再利用システムが存在すれば、そのシステムは確かに三つの要件を満たしているという定理の証明をしてみる。

 三つのうちの一番目の要件、すなわち部品を組み合わせるだけでソフトウェア製品ができあがるものであることという要件は、満たされる。 なぜなら、ソフトウェア製品がカバーする領域のうちの創適応の必要性が小さい領域は、‘ブラックボックス部品’に求められる性質をもつブラックボックス部品がカバーするし、創適応の必要性が大きい領域は、‘ホワイトボックス部品’に求められる性質をもつホワイトボックス部品がカバーするからである。

 このような抽象的な言い方をすると、「ソフトウェア製品のカバー範囲を創適応の必要性が小さい領域と大きい領域に分割するとはどういうことなのか」 とか、「部品がある領域をカバーすることと、部品を組み合わせるだけでソフトウェア製品ができあがることとは同じことなのか」 とかなどに関する具体的なイメージが沸かないかもしれない。 もしもそう感じたら、「5.2 部品化再利用システムの構成法とその具体例」 に述べてある具体例と対比しながらイメージをふくらませていただきたい。

 三つのうちの二番目の要件、すなわちどんなカスタマイズ要求にも対応できるものであることという要件に関しては、創適応の必要性が小さい領域と大きい領域のそれぞれについて調べてみよう。

 創適応の必要性が小さい領域については、どんなカスタマイズ要求があり得るのか想定できるはずである。 そして、その領域をカバーするブラックボックス部品は 「‘ブラックボックス部品’に求められる性質」 、すなわち 「カバーすべき領域に想定されるどんな要求にも部品セットからの部品選択やパラメタの指定によって対応できる」 という性質 (汎用性) を備えているので、要件その2が満たされる。

 創適応の必要性が大きい領域については、ホワイトボックス部品でカバーし、プログラムカスタマイズを覚悟するので、どんな要求にも対応できる。 したがって、要件その2が満たされる。

 三つのうちの三番目の要件、すなわち大勢の開発者が組織的に部品化再利用の恩恵にあずかれるものであることという要件に関しては、ブラックボックス部品とホワイトボックス部品のそれぞれについて調べてみる。

 ブラックボックス部品については、その中身のプログラムを解読せずに、外部からみて意味の明快な宣言的な情報を指定するだけで利用できるので、要件その3が満たされる。

 ホワイトボックス部品については、カスタマイズ要求によっては中身のプログラムの解読が必要になる場合があるが、「‘ホワイトボックス部品’に求められる性質」 を備えていることによって、大勢の開発者が組織的に再利用できることが保証される。 したがって、要件その3が満たされる。

 これを詳しく言うと、あるカスタマイズ要求に対処する際に、目指す部品がすぐ見つかり、それは限られた一つか二つの部品に限定され、その一つ一つの部品はそんなに大きなものではなく、また解読しやすいものなので、大勢の開発者が組織的に再利用できるのである。 繰り返しの説明になるが、検索性のおかげで、従来ありがちであった気ままなモジュール分割に悩まされて、うろうろすることもないし、局所性と手頃な大きさと読みやすさのおかげで、プログラム全体をなめまわすように解読する必要もない。 少しばかりプログラムの解読は必要であるが、簡単に解読でき、その範囲がズルズル増えることにはならないので、解読が許容できるのである。

 以上によって、あるソフトウェア製品をこの一般化した構成法に従って部品化アプリとして構成できれば、すなわちこの一般化した構成法に従った部品化アプリ再利用システムが存在すれば、そのシステムは上記の三つの要件を満たしているという定理が証明できた。

 ここで注意が必要なのは、どのような分野に対しても、このような部品化アプリ再利用システムが構成できるという保証があるわけではないということである。 ここで言えるのは、ビジネス分野においては、この一般化した構成法に従った部品化アプリ再利用システムの実例が存在するということである。 そして、少なくビジネス分野の普通のアプリケーションプログラムに対しては、この一般化した構成法に従って部品化アプリ再利用システムを構成できるといってよいだろう。 しかし、たとえば、人ゲノム計画の支援に使われるソフトウェアがこの一般化した構成法に従って構成できるかどうかは何ともいえない。 また、ビジネス分野においても特殊な領域では、この一般化した構成法に従って部品化アプリ再利用システムを構成できないかもしれない。 なお、これらに関係して、第5章の 「‘ビジネスロジック部品’とは」 の中の部品化可能部分に関する説明をご参照いただきたい。

 最後に、いま証明した定理の逆についても考えてみよう。 すなわち部品化再利用システムが三つの要件を満たすためには、この一般化した構成法に従うことが必要であるということが言えるかどうかという命題である。これについては、残念ながら証明ができていない。 本書では、単に、この一般化した構成法を導き出した過程を説明したに過ぎない。 予想としては、三つの要件を満たすには、この一般化した構成法そのものか、これに若干の修正を加えたもの以外にはないと考えている。しかし、この点に関してはきちんとした証明ができていない。 したがって、別の構成法があるかもしれない。 興味をもたれた方は、考えてみてはいかがだろうか? そして、もしも新たな構成法がひらめいたら、その構成法も三つの要件を満たすということを証明してみていただきたい。

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