「ソフトウェアを部品化し、それらを再利用することで開発生産性を高める」これは古くから言われていたことですが、はなばなしい成功例はありませんでした。

アプリテック社では、この難しい問題に取り組み、データ項目オブジェクトに分解した部品を、ポスト生成ツールで合成するという方法によって、実用的で効果的な部品化再利用を実現しました。

ところで、特注アプリの開発において、請け負ったソフトハウスが思わぬ高利益を上げることがあります。それは、同じような業務アプリを２箇所以上から受注した場合です。２箇所目以降の開発に同じ担当者をうまく割り当てることができると、開発作業の大部分を省略できるからです。いわゆる“転用”とか“流用”と呼ばれる手段を使うのです。要するに“再利用”です。なお、ここでの再利用開発とは、A 社向けに開発した業務アプリを再利用して、似たような B 社向けの業務アプリを開発することを意味します。個人ベースに限って言えば、こうした再利用開発は、今までも行われていたのです。

再利用開発をする場合には、オリジナル版の開発担当者を割り当てることがポイントです。オリジナルの開発に関与していない開発者を割り当てると、そのプログラムの解読作業に手間取ってしまい、利益をあげられなくなってしまうからです。

アプリテック社のテクノロジーは、こういった再利用開発を個人ベースという呪縛から解放して、大勢の人々が組織的に行うことができるようにするものです。これによって、業務アプリ開発において高収益をあげる展開を可能にいたします。

アプリテック社の部品化再利用のテクノロジーは、カスタマイズしやすいパッケージを開発するためにも非常に効果的です (例：ウッドランド社の ERP パッケージ)。

　実用的で効果的な部品化再利用には、次の３つが必要だと考えます。

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

・ どのような業務要求にも対応できる

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

　これら３つの要件が満たされると、従来からあった個人ベースの部品化再利用を大勢の開発者が参加できる組織的なものにできますし、従来の業務パッケージとは異なりどんなカスタマイズ要求にも対応できるようになりますし、サブルーチンライブラリやクラスライブラリとは異なりすべて部品でまかなえるようになります。そして、業務アプリの部品を“開発する人”と“再利用する人”に分けることができるようになるのです。

第一に、プログラム全体を“業務仕様を実現する部分”と“操作等の仕様を実現する部分”に明確に分離して、後者は操作ベースにまかせました。こうすることで、アプリ開発者の方々は“業務仕様を実現する部分”だけに取り組めばよいようにしました。

第二に、プログラムのうち“業務仕様を実現する部分”を (誰にとっても区切りが明快に分かり識別しやすい) データ項目対応の塊に切れよく区切りました。データ項目オブジェクトに分解したのです。なお、データ項目とは、商品コードとか、商品名とか、商品単価とか、顧客コードとかといったもののことです。

データ項目対応に区切った塊は、ソースコードに手を入れて修正可能なもの (ホワイトボックス) という位置付けにしたので、どのような業務要求にも対応できるようにできました。

しかし、このようにソースコードに手を入れることにすると、プログラムを解読しなければならなくなり、大勢の人々による組織的な再利用が困難になりがちです。ところが、データ項目オブジェクトは、次の四つの望ましい性質を備えていたのです。いや、これらの性質をもつデータ項目オブジェクトに切れよく分解したのです。

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

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

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

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

A 社向けに開発した業務アプリを再利用して、似たような B 社向けの業務アプリを開発する際に、上記の四つの望ましい性質を備えていると、解読しなければならない塊は、すぐに分かり、限られた個数にすぎません。したがって、解読作業の手間は大してかからないので大勢の人々による組織的な再利用が可能になるのです。

また“業務仕様を実現する部分”をデータ項目オブジェクトに分解したのですから、それらを合成することで“業務仕様を実現する部分”が完成することになります。ですから、もしも、データ項目オブジェクトが部品と呼べるようなものであるとしたら、部品を組み合わせるだけでソフトウェア製品ができあがると言えます。しかるに、データ項目オブジェクトは、上記の４つの性質を備えているので、部品と呼ぶに相応しいものなのです。

結論として、実用的で効果的な部品化再利用の３つの要件を満たしたと言えます。

部品に分解したものを合成しないと業務アプリにはなりませんが、この合成作業を人手で行わなければならないようだと効率的ではありません。

アプリテック社では、この合成作業を MANDALA というプログラム生成ツールで行わせています。

なお、一般にプログラム生成ツールは、プレ生成ツールとポスト生成ツールに分類できますが、MANDALA は洗練された方のポスト生成ツールです。ですから、手入れの全く不要な完璧ソースを生成してしまいます。

プレ生成ツールでは、こうは都合よくいきません。とにかく最初に、プログラムを生成してくれますが、そこに手を入れてプログラムを完成させるのは、人間の役割となるからです。人間が解読して手直ししなければならないのでは、生産性は大して上げることができません。

プレ生成ツールにおいては、再生成を行うことは、もう一度はじめから作業やり直すことを意味します。しかし、ポスト生成ツールでは、そうではありません。再生成は、手を煩わせない非常に簡単な作業なのです。なぜなら、再生成の後に手を入れるといった作業は、全く必要ないからです。

再生成は、いわば日常的に行われる作業です。例えば、生成ツールへのパラメタを変えて再生成するとか、また画面に項目を追加したりプログラム (部品) を付け加えたりして、その後で再生成することなどは、MANDALA を使った開発ではしばしば行われる軽い作業です。

まとめ (部品化再利用)

一般に、個人ベースの部品化再利用は、自然発生的になされるものです。この種の個人的な効率化を大勢の人々による組織的な効率化に持ち上げることができると高収益をあげるようなビジネスが展望できるでしょう。

これを実現すべく、MANDALA を使った開発では、業務プログラムを (誰にとっても区切りが明快に分かる) データ項目対応の塊に区切ることで組織的な再利用を可能にしました。即ち、他人の書いたプログラムのうち解読しなければならない部分を局所化することで、(常識では大きな負荷だと考えられていた) 解読の手間を少なくして、大勢の人々による組織的な再利用を可能にしたのです。

たとえて言えば、文書を再利用するときには、全体を読み直す手間 (プログラムの場合はこれが極端に大きな負荷となる) がかかりますが、次のようにできれば効率的だといえます。

即ち、文書が数多くの (1,000 個くらいの) 塊に区切られていて、それらのどれとどれ (数個) を変更すべきかすぐに分かり、それらの数個の塊を読み直して修正するだけでよければ、全体を読み直す手間がかからなくなります。ですから、従来の常識「他人の書いたプログラムを解読して再利用する手間を考えると、新規に作成した方が得」は、私どもの方法を使うと通用しなくなります。なお、数多くの塊がスムーズにつながるようにする作業は、(私どものテクノロジーによって) 人手を煩わせずに、コンピュータに処理させますから、これに関する心配はご無用です (文章の場合は、こういったことをコンピュータに行わせるのは難しいのですが、プログラムの場合は、これをコンピュータに処理させることができるのです)。

アプリテック社のテクノロジーを用いると、業務に関するプログラムをデータ項目対応の塊に区切っても、それらを簡単に“合成”することが可能になるのです。ですから、このように区切ったために取り扱いにくくなるというようなことはありません。

むしろ、プログラムをデータ項目対応の塊に区切ることによって、各塊は他の塊に影響されずに使える独立性の高いものになりますから、再利用が大変にしやすくなります。ですから、アプリテック社の“合成”テクノロジーは、業務アプリの“部品化再利用を支援し推進する”のです。

なお、この“合成”に関するテクノロジーは、データ項目オブジェクト間の関係を調べて、それらを制御する技術として特許審査中です。