1. 深く考えずに単純な開発方法を採用すると
--- 単純な開発方法 ---
例えば１５０画面から構成される画面アプリを１０名の開発者によって作成するときに、どのようにすればよいでしょうか？
一番単純な方法は、１５０画面を１５画面ずつ適当に分けて、各々を１０名の開発者に作成させることです。こうすれば、１５×１０ということで１５０画面が作成できるはずです。
以下の図のように、開発者 Aさんが A1,
A2, ... , Am の画面アプリを作成して、開発者 Bさんが B1, B2, ... , Bm の画面アプリを作成して、... 、開発者 Nさんが N1,
N2, ... , Nm の画面アプリを作成するというような単純な開発方法です。
なお、以下の図では、一つの楕円が一つの画面アプリを表しているとみなしてください。
開発者Ａ (またはＡチーム) が作成する画面プログラム
A1 A2 A3 A4 A5 Am
開発者Ｂ (またはＢチーム) が作成する画面プログラム
B1 B2 B3 B4 B5 Bm
開発者Ｎ (またはＮチーム) が作成する画面プログラム
N1 N2 N3 N4 N5 Nm
上の三つの図において、下記のような赤色の部分が“業務仕様を実現するプログラム部分”を示し、青、緑、黄の部分が“操作等の仕様を実現するプログラム部分”を示します。
この単純な開発方法を評価してみると、次の三つの問題点があります。
問題点のその１は、各画面の操作性がバラバラになってしまうことです。
例えば、Aさんの作成したもの、Bさんの作成したもの、...
それぞれに Visual Basic との格闘の後が見受けられて興味深いのですが、それらを合わせてみるとテンデンバラバラな成果物だと言わざるを得ないことが普通です。
いや反論があるですって！「操作性の標準化規約をつくってから開発するのが当然なのだからバラバラになることはない」と言われるかもしれませんが、本当にそうでしょうか？
ソフト開発を管理した経験がある方ならば、規約を決めても細部が大いに異なってくることは、よくご存じのはずです。同じ機能を実現するのであっても
Visual Basic ではいろいろな組み方ができますから、Aさんの作成したものは
Aさんの色が出てしまいますし、Bさんの作成したものは Bさんの色が出てしまいます。このような違いに加えて、同じ Aさんの作成したものであっても、未熟なときに作成したもの（上図では濁った色で表現）と、スキルが高くなってから作成したもの（上図では澄んだ色で表現）では、大分異なることが普通です。
こんなわけで、一応完成した１５０の画面アプリを並ベて見てみると、不揃いなところが目立って、どうしようかと頭をかかえることになるケースが多いようです。納期まで余裕があれば直したいところですが、大抵は納期ぎりぎりで出来上がってくるものですから、余裕などないのが普通です｡「お客様 (最終顧客) に何と言われようと目をつむって完成とするか、納期を遅らせても不揃いなところを直すべきか、それが問題だ」と苦渋の選択をしなければならなくなるのではないでしょうか。
問題点のその２は、各画面アプリのメンテナンスがやっかいなものになってしまうことです。
Aさんの作成したもの、Bさんの作成したもの、...
それぞれに Visual Basic との格闘の後が見受けられて興味深いのですが、それぞれの画面アプリは各開発者のスタイルやテクニックを用いた芸術作品？
になってしまいがちです。ですから、Aさんの作成したものを Bさんにメンテナンスさせようとしても、なかなかうまくいきません。
いや反論があるですって！「仕様書を作ってあるので、他人の作ったプログラムでもメンテナンスできる」といわれるかもしれませんが、本当にそうでしょうか？
ソフト開発を管理した経験がある方ならば、仕様書があっても他人の作ったプログラムをメンテナンスしにくいことは、よくご存じのはずです。
Windows 系のアプリは、イベント駆動というプログラミングスタイルをとることが普通なのですが、これは昔の
COBOL によるプログラミングと大いに異なります。プログラムの入り口から出口までダラダラと流れる昔のスタイルと異なり、イベントの発生を契機に呼び出される数多くのツブツブのプログラムから構成されるようになります。ですから
COBOL よりも切れ切れになっている分だけ、メンテナンスの必要な個所を特定しやすくなります。しかし、操作性に関係するプログラム（上図では赤色以外の色で表現）と業務仕様に関わるプログラム（上図では赤色で表現）がごちゃまぜになってしまいがちで、その分だけメンテナンスしにくくなってしまいます。特に操作性に関する部分は、複雑なプログラムになりがちですから、それが混ざっている
Aさんの作成したプログラムを Bさんにメンテナンスさせようとしても、なかなかうまくいきません。なぜなら、Bさんは、Aさん流儀の色の着いた操作性に関するプログラムを学習することから始めなければならないからです。
問題点のその３は、開発の生産性が上がらないということです。開発にムダが多く、効率的でないのです。
開発者 Aさんが A1, A2, ... ,
Am の画面アプリを作成する際に、最初の A1 画面アプリを作成するときには、産みの苦しみを味わうことが普通です。最初の画面アプリの作成には、かなりの日数がかかることでしょう。
しかし、A1 画面アプリを完成させてしまうと、次の
A2 画面アプリは、以前よりも簡単に作成できるものです。なぜなら、Aさんは、A1 画面アプリのプログラムコードや開発ノウハウを A2 画面アプリの作成に再利用するからです。
一般に、自分で作成したものを自分で再利用するという形の個人の枠内での再利用は、ごく自然に行われるものです。
一番うまくいくケースでは、A1 画面アプリのコピーをつくり、それを
A2 画面アプリの原形にします。そして、その一部を修正するだけで A2 画面アプリが完成させることができます。この場合、修正する部分は、赤色の“業務仕様を実現するプログラム部分であり、青色の“操作等の仕様を実現するプログラム部分”は、うまくいくケースでは、そっくりそのまま再利用できることでしょう。
実際には、そんなにはうまくいかないケースも多いものですが、とにかく再利用できるところがある分だけ、最初の画面アプリの開発よりも、それ以降の開発の方が簡単に素早くできるようになるのは間違いありません。
以上、開発者 Aさんに着目してきましたが、B さんも
C さんも ... N さんにも同じことが言えます。開発者の全員が産みの苦しみを味わい、かなりの日数がかけて最初の画面アプリを開発するのですから、ムダなことです。
単に個人の枠内での再利用だけでなく、個人の枠をこえた再利用ができれば、もっと効率的な開発になるはずです。
以上を整理すると、単純な開発方法には、以下の三つの問題点があるといえます。
・ 画面アプリの操作性がバラバラになりがち
・ 他人の開発したプログラムがメンテナンスしにくくなってしまう
・ 開発作業が効率的でない
|
|
|
|
|
|
|
|
|
