一般に、ソフトウェアを開発した経験のない方々は、ソフトウェアの開発を物の製造と同じだと考えたがるが、これは大いなる誤解を発生させる。また、ソフトウェア開発の生産性は簡単に数値化可能であると考えるのも誤りである。そして、ソフトウェア開発の実態に立ち入らずにその生産性を議論するようでは、有効な成果は期待できない。意味をなさない議論が展開されて、生産性の数値が一人歩きをするだけである。これでは、何の実りもない。
この章では、まずソフトウェア開発とは何なのかをある程度深く認識してから、その生産性の正しい計り方について考察してみる。その後で、これまでのソフトウェア開発の歴史を振り返って生産性が向上しているかどうかを調べ、最終的には、生産性を向上させる方法を探ることにする。
この章は、プログラムの中のバブル、すなわち冗長な部分を取りあげたためか、本文までも少しばかり冗長になったようである。この章の内容を常識どおりで冗長だと感じた方は、興味のある部分だけを拾い読みするのがよいかもしれない。この章には、第３章および第５章の記載内容を裏付ける事柄が書いてあるので、第３章および第５章の記載内容に納得していただけるようであれば、この章は飛ばしても本書の趣旨は通じる。しかし、常識とは異なることを述べているなとの印象をもたれた方は、慎重にじっくり読んでいただくのがよいだろう。
ソフトウェア開発を管理する立場の方々は、もしもソフトウェア開発の生産性に何らかの関与をしたいと考えたとしても、必ずしも細かな開発作業の内容を知る必要はない。しかし、少なくともソフトウェア開発とはどんな作業なのかを正しく認識することは必要である。
この節では、ソフトウェア開発とはどんな作業なのかを見ることから始めて、その生産性についての理解を深めることにする。
｢ハードウェアの生産性は飛躍的に向上しているわりに、ソフトウェアの生産性は向上していない｣ といわれることがある。この言い方には、ソフトウェアに関わる技術者の奮起を促す意味が込められている。これはこれで素直に受け止めるべきだろうが、この文の意味は次のように解釈すべきだろう。
飛躍的に向上しているのは、ハードウェア (物) の製造に関する生産性だとみなしてよいだろうし、向上していないのは、ソフトウェア開発という設計を人間が行う際の生産性だと考えるのが妥当だろう。したがって ｢ハードウェア (物) の製造の生産性は飛躍的に向上しているわりに、ソフトウェアの設計の生産性は向上していない｣ というように理解できる。
そもそも、ハードウェアの生産性とかソフトウェアの生産性というような言い方は曖昧である。意味を明確にするには、ハードウェアについてもソフトウェアについても“設計の生産性”と“製造の生産性”とに分けるべきである。すなわち、ハードウェアの設計、ハードウェアの製造、ソフトウェアの設計、ソフトウェアの製造の四つを比較すべきである。こうすると、設計か製造かという点にこそ本質的な違いがあるのであって、対象がハードウェアかソフトウェアかという違いはわずかで、むしろこれらには共通点が多いことに気がつく。たとえば、支援ツールを比べてみると、ハードウェアの設計を支援する CAD (computer aided design) はソフトウェアの設計を支援する各種のエディタやコンパイラに相当するし、ハードウェアのシミュレータはソフトウェアのデバッガに相当するというように、それぞれに対応するものがある。このような認識に立つと、ソフトウェアであってもハードウェアであっても ｢製造の生産性は飛躍的に向上しているわりに、設計の生産性は向上していない｣ という本質が見えてくる。
この辺りの理解を深めるために､“設計”と“製造”という言葉の意味を明確に定義することから始めよう。
ここで“製造”とは、既に設計が済んでいることを前提にして、設計作業を通して明確にされたものの“実体を作る”ことを意味するものとする。 車とかコンピュータハードウェアとか建造物とか印刷機とかの製造とは、設計図面で明確にされた何らかの物体を作ることであるし、ソフトウェアとか書籍とかの製造とは原本のコピーが入ったフロッピーディスクとか CD-ROM とか綴じた紙の束を作ることに他ならない。
そして“設計”とは、製造対象物を明確にすること、すなわち製造対象物に関する曖昧さを一切なくすことを意味するものとする。 設計をするという行為によって、もはや製造段階では何を作るのかという迷いが一切生じなくなり、創造性を発揮する余地もなくなるのである。 言い換えると、製造対象物に関しては (詳細な製造方法を別にすると) 一かけらの創造性も必要としないようにすべてのお膳立てをすることが“設計”なのである。
“設計”とは、小説を例にとると、構想を練って、取材をして、執筆して、推敲して、装丁をデザインするというような作業である。 これに対して､“製造”とは、活字を組んで原版をつくり、印刷機を回し、製本するというような作業である。
なお、第３章では、要求仕様の明確化という作業とそれを実現させる作業とを区別したが、これら二つの作業の後に続くのが“製造”工程である。 そして、これら二つの作業は、広義の“設計”作業だと捉らえることができる。どうしても区別したければ、要求仕様の明確化とは、狭義の“設計”の前に行うものであり、要求仕様を実現させること (実現させた姿を考え出すこと) が狭義の“設計”に相当すると捉らえても構わない。
ソフトウェアの開発は、ウォータフォールモデルに基づこうがスパイラルモデルに基づこうが、計画／分析、概要設計、プログラミング、テストなどの作業が含まれている。 これらの中のプログラミングを製造と呼ぶので誤解が生じるのであるが、少し考えれば分かるようにプログラミングは決して製造ではない。 製造工程とは、製造対象物が明確になった後に、ソフトウェア製品となるフロッピーディスクや CD-ROM などにデータを焼きつける工程のことである。 プログラミング作業は、ソフトウェアという製造対象を明確にする作業に他ならないので、設計工程に含まれるものである。 いわば、設計図を仕上げる作業に相当すると考えるのが正しい。
そもそも、ソフトウェア開発はそのほとんどすべてが設計作業である。 したがって、その生産性を向上させたければ、設計作業の生産性向上策を練るべきなのである。 ソフトウェア開発を製造工程に無理にたとえて、製造作業の生産性向上の成果にあやかりたいと思っても、それは単なる希望にしか過ぎない。 この後の ｢４．３ ソフトウェア開発の生産性は向上しているか｣ で述べるように、製造作業の生産性向上策を設計作業に適用するのは難しいのである。 ソフトウェア開発を製造工程にたとえるのはご自由であるが、誤解を生み幻想を育てることになるだけなのでお勧めできない。
生産性とは“成果物の量”を成果物の製造または開発に費やした“延べ作業時間”で割った値であり、単位作業時間当たりの成果物の量を意味する。 生産性の値は、従来の生産方法と比較して、成果物の量を増やすか、あるいは延べ作業時間を減らせば、高くなるという関係があり、生産性はこの二つ (成果物の量と延べ作業時間) の比によって決まる。
生産性 ＝ 成果物の量 ／ 延べ作業時間
まず延べ作業時間の計り方については、人間が直接かかわった時間だけをカウントすることにする。 ソフトウェア開発の場合には、開発費の大半は人件費なので、こうしても大きな誤差はないだろう。
ただし、多額の設備投資を必要とする装置産業の場合には、装置のコストも考慮すべきである。 つまり、もっと精密にするには、装置の開発や製造のために費やした人間の作業時間も含めるべきだろう。 これはもっともな考え方なのだが、ここではソフトウェア開発の生産性を取りあげているので、話を簡単にするために、そうした設備類は開発や製造のための基盤 (インフラストラクチャ) だと考え、それらを前提とした上で、開発や製造に人間が直接かかわった延べ作業時間だけを用いて生産性を算出することにする。
延べ作業時間はこのように片がつくのであるが、成果物の量の計り方は難問である。 特にソフトウェア開発のような設計作業の成果物の量の計り方は難しい。
参考にできるかもしれないと、製造作業の成果物の計り方を調べてみると、これも決して簡単ではない。 種類が異なる成果物を比較しようと考えると、たとえば車の製造と本の印刷製本とを比較しようとすると、成果物の量の尺度をどう合わせるのか問題になる。 あえて比較するのであれば、それぞれの作業による付加価値を金額に換算して計るしかなさそうである。 一般に、成果物の種類が異なるとその量を比較することは困難である。
同じ種類の製品については、たとえば車であれば、成果物の量を台数で計る (数える) ことができる。 ただし、一口に車といっても、製造に手のかかる高級車もあれば、製造にあまり手をかけない大衆車もある。 成果物の量を単純に台数で計ると、その生産性は高級車よりも大衆車の方が高いことになってしまう。 だからといって、高級車の製造よりも大衆車の製造の方が生産性を向上させる製造技術が優れている (という傾向が見受けられるが) とは限らない。 成果物の量を台数で計った生産性を比較するのならば、同じ種類の同じグレードの製品同士でないと、フェアな比較にならない。
ユニークな設計の高層ビルのように世の中に一つまたは極めて少数しか作らないものの場合、成果物の量をどういう単位で表現すべきかとい点は、特に難しい問題である。 というのは、１棟２棟のような大雑把な値を基に生産性を算出しても、それは他と比較しようがないので意味のあるデータとはいえないからである。 たとえば、クフ王のピラミッドの建造に 100 万人年の延べ作業時間がかかったものとすると、その生産性は 0.000001 棟／人年であるということになる。 しかし、これは生産性の数値としての意味をもつわけではなく、単なる延べ作業時間の逆数にしか過ぎない。 １棟２棟のような単位ではなく、他と比較しやすい表現にしないと、生産性としての意味をもつデータにならない。 ある意味では建造物の価値を無視するかもしれないが、たとえば成果物の量を床面積とか体積というような共通の尺度で計る工夫が必要である。
小量生産とは違って大量生産される工業製品の場合には、同じ製品の生産性を比較することは簡単である。 １台２台という単位で成果物の量を計って (数えて) で生産性を算出すれば、少なくともその製品に関する限り十分に意味のあるデータになる。 たとえば、ある車が０．３台／人日で製造できるという生産性データは、その車の製造方法を変更するような場合、それが生産性向上に有効かどうかを示すデータとして役立つ。 その車に関する製造技術を評価する際のバロメータとして意味をもつのである。
このように繰り返し行われる作業の場合は、その個数 (回数) で成果物の量を表した生産性は十分に意味がある。 しかし、小量しか生産されないものの場合とか、成果物の種類やグレードが異なる場合には、成果物の量を表す適当な共通の尺度を見つけないと、生産性を比較できない。
ここまで製造作業の成果物の計り方を見てきたが、ソフトウェア開発のような設計作業の成果物の量についても似たようなことが言える。
一般に、ソフトウェアは一品一品開発するのが普通であったので (本書はこれをお勧めしていないことに注意していただきたいが実態はこうなので)、ユニークな設計の高層ビルの場合と同じように小量生産にまつわる問題がある。 しかも、一口にソフトウェアといっても、開発に手のかかるソフトウェアもあれば、あまり手のかからないソフトウェアもある。 したがって、成果物の量を１システム２システムという大雑把な計り方 (数え方) をして算出した生産性では、他と比較のしようがない。 この業務システムは、0.01 システム／人月の生産性であったといわれても、その数値は延べ 100 人月かかったことを示すだけで、生産性としての意味をもつことにはならない。 それぞれの開発の生産性を比較できるようにするためには、成果物の量をどう表現するのかという工夫が求められる。 ピラミッドという成果物の量を床面積とか体積で代表させるというような工夫が必要になるのである。
この共通の尺度に関してはいろいろな提案や議論がある。 ｢コメント文 (注釈文) を除いたプログラム行数は、いくらでも水増しできるという問題点があるが、他に良い尺度がないのでこれを用いるしかない｣ とか、｢画面や帳票やレコードやデータ項目の数に、ある重み付けした点数で計るべきだ｣ とか、｢その成果物による収入で計るべきだ｣ とか、苦肉の策と思われるようなものも含めていろいろなことがいわれている。 なお、プログラム行数に近い計り方だけでもいろいろな種類があり、プログラムの文の数でカウントした方が正確だとか、文字数でカウントすべきとか、細かい議論がある。 本書では、そこまでは立ち入らずに、これらを“コメント文を除いたプログラム行数”で代表させることにする。
ソフトウェア開発の成果物の計り方を十分に納得できるものにするには、何らかの理論的な裏付けが欲しい。 情報理論の基礎をなす有名なシャノン (Shannon) の定理は、情報量と通信容量との関係を明確にしたものであり、情報の中から冗長性を取り除く理論的な裏付けになっている。 したがって、その“情報量”を用いて成果物の量を計れば、納得のいく客観データが得られることになるはずである。 つまり、あるプログラムを開発した際に、そのプログラムを記述する (あるいは通信回線を通して送る) のに必要なミニマム情報量がもしも分かるとすると、その値を成果物の量とすることによって一つの客観的な生産性を定義できる。 このミニマム情報量とは、平たく言うと、そのプログラムを最もコンパクトにしたときのプログラムサイズのことである。 これをもう少しシャノンの定理に沿うように言うと、そのプログラムをうまく作り替えて、そのプログラムを通信回線で送るときのバイト数が最も少なくなるようにした場合の、そのバイト数のことである。 なお、成果物の量としてプログラムのミニマム情報量を用いた生産性のことを真の生産性と呼ぶことにする。
これで準備ができたので、いざプログラムのミニマム情報量を求めようとすると、これを求めるアルゴリズムが見つかっていないことに愕然とすることだろう。 さらに言えば、コンピュータの理論に登場する有名なチューリング (Turing) マシーンの停止問題には一般解法が存在しない (注８) のと同様に、プログラムのミニマム情報量を求めるアルゴリズムはどうも存在しないようだということに気づく。 一般解法がないとなると、ミニマム情報量は個々のプログラムごとに創造性を発揮して実践的に求めていくしかない。 すなわち、プログラムの中の無駄な部分を省いて、共通部分を共通サブルーチンや共通メインルーチンとして括り出し、プログラム情報を圧縮して (注９) というようなテクニックを駆使して、できるだけ小さなプログラムに変えていくのである。 この作業は非常に難しい作業であり、プログラムを開発することと比べ物にならないほど多くの労力がかかることだろう。 しかも、これ以上小さくすることはできないと言い切るのは難しいので、いつ果てるともない仕事になってしまう。 要するにミニマム情報量を求めることは極めて困難なのである。
注８： チューリングマシーンとは、コンピュータの理論を展開する際に用いられる仮想的なコンピュータのこと。 チューリング (Turing,A.) が考え出したのでこの名が付けられた。 なお、コンピュータ分野で貢献した個人またはグループに米国計算機学会 (ACM) から与えられるチューリング賞も彼の名にちなんでいる。
チューリングマシーンの停止問題とは、いわばあるプログラムを走らせたときに、いつか停止することになるのか、あるいは複雑なループをするなどして永遠に動き続けることになるのか、のどちらなのかを判定する問題のこと。 特定のプログラムを取りあげると、停止問題の答えを出すことができる場合がある。 しかし、どんなプログラムが与えられてもその答えを出せる、といえるような一般的なアルゴリズムは存在しないことが (すなわち停止問題の答えを出すようなプログラムをつくれないことが) チューリングによって証明されている｡“停止問題の答えを出せない”というコンピュータサイエンスの世界におけるこの定理は、ゲーデル (Gödel,K.) の不完全性定理に対応するものであり、世の中には絶対に解けない問題が存在することの例になっている。
注９： シャノンは、情報圧縮の限界を理論的に次のように示した。 もしも、すべてのプログラムに関して、それぞれが使用される確率分布が分かれば、確率 P で使用されるプログラムは次のビット数に圧縮できる。
Log2 (1/P)
たとえば、1/8 の確率で使用されるプログラムは 3 ビットに圧縮できるし、1/256 の確率で使用されるプログラムは 8 ビット、すなわち 1 バイトに圧縮できることになる。 これは常識的な値よりも大幅に小さいように思われるかもしれないが、プログラムに付けた名前 (またはプログラムを識別するためのコード) だと考えると理解できる値である。 部品化再利用の究極の姿は、もはやプログラムを開発することがなくなり、既に開発済みのプログラムの識別コードを唱えるだけになることを理論的に示したものだと捉らえればよいだろう。 なお、この理論的なシャノンの圧縮の成果を得るためには、圧縮結果を解凍するための莫大な解凍プログラム (いやプログラム名からその本体を引き出すための莫大なプログラムライブラリと呼ぶべきかもしれない) が必要になることにご注意いただきたい。
ここでは、理論的な限界から現実的な情報量の算出方法の話に立ち戻って、すなわちすべてのプログラムについてどの程度使用されるのかという確率分布が分かるわけではないし、部品化再利用の究極の終焉まで行き着けるわけでもないので、次のように解凍処理に配慮した考え方をとるのがよさそうである。
圧縮・解凍プログラムを新規に開発して、プログラムを圧縮するのが得策であれば、そうすればよいのであるが、この場合、算出する情報量には、その解凍プログラム自体のミニマム情報量を加えるものとする。 なぜなら、解凍プログラムも一緒に通信回線を通して送らないことには、送り先で解凍できないからである。 いわば、自己解凍形式のファイルにするのと同等の処置が必要だとお考えいただきたい。
それでは、既存の圧縮・解凍プログラム (たとえば ZIP) を用いる場合はどうかというと、算出する情報量には、その解凍プログラムの名前 (一般には解凍プログラムを識別するためのコードとして拡張子が使われている) に相当する情報量 (拡張子であれば 3 バイトほど) を加えることとする。 なぜなら、解凍プログラムまでも通信回線を通して一緒に送る必要はないだろうが、解凍プログラムの名前が分からなければ、送り先で解凍できないからである。
ミニマム情報量は簡単に求められないので、これに代わる成果物の量として ｢コメント文を除いた開発プログラム行数｣ を採用するのが普通である。 もしもこの値がミニマム情報量に比例するものとすれば、これは客観的な意味をもつ生産性だとみなすことができる。 確かに、コメント文を除いた開発プログラム行数とミニマム情報量とは、統計的には比例する傾向があるように思われる。 しかし、個々の開発をみると、コンパクトに引き締まったプログラムもあれば、バブル (冗長部分) でふくれ上がったプログラムも存在する。 このふくれ具合を何らかの形で推定して補正しないことには、上げ底、水増しのとんでもないプログラムだとは知らずに、高い生産性を上げたと誤った評価を下すことになってしまう。
これをピラミッド建造の生産性にたとえると、｢コメント文を除いた開発プログラム行数｣ とは、外から計れるピラミッドの体積に相当するようなものである。 しかし、ピラミッドにはぎっしりと石の詰まったものや、大量の隙間を含むいわばバブルでふくれ上がったものもあるかもしれない。 もしもこうだと仮定すると、見かけの体積という尺度で成果物の量を表現するのは、必ずしも適切ではない。 中に隙間のあるピラミッドは、石を詰め替えて見かけの体積を最小にしたミニマムピラミッドに作り替えて、その実質の体積 (ミニマム情報量) を成果物の量とすべきである。 しかし、ピラミッドを作り替えるのは莫大な作業量を必要とするので、仕方なく見かけの体積で成果物の量を計っているということになる。 大袈裟な作り替えなどせずに、簡単にミニマムピラミッドの実質の体積を求める方法があるとよいのだが、プログラムに関してはそういう方法がないのである。
ソフトウェア開発の生産性としては、誰もが納得できるような計測方法があるわけではない。 そこで少しでも納得できるようにするには、一つの計測方法だけを頼りにするのではなく、複数の計測方法を併用して総合的に判断する方がよさそうである。 そのために、いくつかの計測方法をご紹介することにする。
まずは、ソフトウェア開発という設計作業の生産性の実績を示すために広く用いられる、次の式で表される生産性から説明する。
コメント文を除いた開発プログラム行数 ／ 延べ作業時間
本書では、何の補正もせずにこの式の通りに計算した値を単純生産性と呼ぶことにする。 単純生産性は簡単に求められる点はよいのであるが、これに頼ると次のような弊害がある。 すなわち、中身が詰まったコンパクトなプログラムを開発すると生産性が低く評価され、逆にふくれ上がったものを開発すると高く評価されることになる。 このような評価方法をとっていると、プログラムをコンパクトにする努力を阻害して、バブルでふくらませる安直な手段を推奨することになってしまう。 悪意をもって水増しして見かけの生産性を高めることはめったにないとしても、これでは知らず知らずの間にふくれ上がったプログラムを当たり前だと思うように慣らされてしまう。 いや、既にそうなっているように見受けられる。
こういった問題点は、成果物の量として開発プログラムの行数という、いわば見かけの体積を採用したことにより発生した不具合である。 これを正すには、単純生産性をそのまま用いるのではなく、中身の詰まり具合によって成果物の量に補正を施すことである。 そして､“真の生産性のように完全にバブルを取り除いた生産性値”に近づけるべきである。 なお、単純生産性を補正したものを本書では補正生産性と呼ぶことにする。
生産性の補正方法としては、単純にバブルが見つかる度にその分を成果物の量から差し引くのが分かりやすいと思う。 たとえを挙げると、ピラミッドの中に隙間が見つかる度にその分を差し引いていくのである。
具体的には、不要なプログラムステップが見つかったら、開発プログラム行数からその分を差し引く。 また、ライブラリに登録されている共通サブルーチンが再利用できるにもかかわらず、新たに開発していたという重複が見つかったら、それはバブルなので、開発プログラムからその行数を差し引くことで補正を施す。
再利用できるソフトウェア資産はいろいろある。 共通サブルーチンだけでなく、操作性に関係する共通メインルーチンや業務仕様に関係するデータ項目部品なども再利用できることは、本書で明らかにしたとおりである。 したがって、これらに対しても部品ライブラリに登録されている資産を徹底的に再利用するという原則は適用すべきである。 したがって、もしもこれに反して新たに共通メインルーチンやデータ項目部品またはそれ相当のルーチンを重複して開発しているのが見つかったら、補正を施す。
このようにして求めることのできる補正生産性は、次のように表現できる。 ちなみに、単純生産性についても、同様の表現を示しておく。 なお、｢実際に開発したプログラム行数｣ は、｢実質的に開発が必要なプログラム行数｣ よりも ｢発見したバブル行数｣ だけ大きな値を示す。
補正生産性 ＝ (実際に開発したプログラム行数 − 発見したバブル行数) ／ 延べ作業時間
＝ 実質的に開発が必要なプログラム行数 ／ 延べ作業時間
単純生産性 ＝ 実際に開発したプログラム行数 ／ 延べ作業時間
上記の補正方法は単純で分かりやすいのであるが、バブルを人手で検出しなければならないために見落としがあるかもしれないという問題がある。 つまり、バブルの検出の感度によって、補正生産性の値が異なってしまう。 うっかりしてバブルを見つけ損なうこともあるだろうし、また元々バブルだとは思いも寄らなかった部分は検出できない。 たとえば、操作性に関係する共通メインルーチンのことを教えられないと、その部分を重複して開発してもバブルだとは気がつかないかもしれない。 気がつかないと補正できないので、補正生産性は“真の生産性のように完全にバブルを取り除いた生産性値”にはならない。 確かにまだ誰も気づかない部分は検出のしようがないが、バブルに関する認識を深め、気づいたものは必ず補正することがこの方法の基本なのである。 補正生産性をきっちりと求める別法があるとよいのであるが、残念ながら上記のように補正する以外にうまい方法はなさそうである。
このように理解すると、あまり意味をなさない単純生産性は別として、意味のあるソフトウェア開発の生産性は簡単には数値化できないことがお分かりいただけると思う。
いくつか問題点はあるが、何も補正を施さない単純生産性よりも補正生産性の方がずっと“真の生産性 (完全にバブルを取り除いた生産性値)”に近い値を示す。 しかも、単純生産性を用いることからくる弊害は、補正生産性の採用によって大幅に緩和される。 現状では単純生産性が幅をきかせているが、補正生産性に速やかに切り換えるべきだろう。 切り換えるには、これまで必要のなかった補正作業という手間がかかる点が障害になるかもしれないが、これはプログラムのレビューの際に並行して行えばよいだろう。
トピック 7： パソコンによる開発とレビュー
あるところで ｢補正生産性を求めるための補正作業は、プログラムのレビューの際に並行して行うのがよい｣ という話をしたのであるが、キョトンという顔をされてしまった。 なぜかと尋ねてみたところ、最近はプログラムのレビューを行わなくなっている実態が分かった。 そこの出席者の場合は、１割ほどしかレビューの習慣がないとのことであった。
昔はコンピュータが高価だったので、それを使える時間が限られていた。 そこで、短時間の内にデバッグが終わるように、レビューに力を入れたものであった。 パソコンが普及して、いつでもコンピュータが使える環境になったのは良いのであるが、レビューが忘れ去られているようである。
念のためにレビューとは何かというと、書いたプログラムを見直す作業である。 いわば、文章の推敲に相当する作業なのである。 レビューには、一人で行う自己レビューもあるが、大抵は開発プロジェクトの関係者数人で行うことが普通である。 レビューの目的は、インタフェースの不整合を見つけたり、バグを見つけたりすることであるが、これら以外にプログラミングに関する情報交換という意味もある。 つまり、美しいプログラムを見たり、美しいプログラムにしたりするための意見交換の場でもあったのである。
情報交換がないと、プログラムは一人よがりのものになり、磨きがかけられるチャンスを逸する。 また、お互いのプログラムの中の共通部分が見つからないまま残るので、再利用が阻害される。 これらは、恐るべき大問題である。 なぜなら、コンピュータパワーをふんだんに使えるようになっても、バブルでふくれたプログラムを作っているのでは、開発要員をいくら増やしても追いつかないからである。 補正生産性を求めてみれば、このことが立証できるはずである。
“人月”という単位で見積もった値が売上に直結する開発業者は、いっときは、うるおうかもしれないが、そのツケはメンテナンス作業にまわる。 つまり、メンテナンスのためにさらに人手を食うことになる。 これはメンテナンスという売上を得る業者には好都合なのかもしれないが、発注者側にとっては踏んだり蹴ったりの酷い仕打ちだといえよう。
したがって、パソコンを使うようになってもレビューを行わせるべきである。 以前とは違って、WAN や LAN などのネットワークと適切なグループウェアを活用すれば、地理的に離れていてもレビューができるような環境が整ってきている。 このように良い環境が整備されてきたにもかかわらず、パソコンがふんだんに使えるために、かえってレビューが行われなくなっているのは全く皮肉なことである。
ちなみに、レビューとは少し異なる観点で生まれたリファクタリングによっても、レビューのねらいは実現できる。したがって、もしもレビューは古いというのなら、リファクタリングを行うのがよいだろう。 こう考えると ｢レビューをしていますか｣ ではなく ｢リファクタリングをしていますか｣ と尋ねるべきだったかもしれない。 リファクタリングとは、プログラムの冗長部分を少なくするだけでなく、プログラムを変形することによって、あるねらった状況化での再利用をしやすいものにすることに他ならない。
少しでも納得できる生産性の値を求めるために、複数の計測方法を併用することをお勧めしているが、ここではソフトウェア開発の生産性の絶対値を問うのではなく、あるネタ (材料、施策、仕掛け、仕組み) を適用することによって生産性が何倍になるかという相対値、すなわち倍率に着目してみよう。 ここでは、各ネタがどれだけ生産性を向上させるのかを、そのネタの生産性の向上率と呼ぶことにする。
生産性の向上率は明快で分かりやすい意味のあるデータになり得る。 この値は、どのネタから順番に適用していくのがよいかを示す合理的な判断材料になる。 また、あるネタを適用した結果、生産性がどうなったかを評価する場合、この生産性の向上率さえ得られれば事足りる。 わざわざ生産性の絶対値を求めるには及ばない。
生産性の向上率を求める方法は二つある。 まずは実施検証によって求める方法から始めよう。
あるネタの適用による生産性の向上率は、一見すると、実施検証によって簡単に測定できるような気がする。 すなわち、最初はそのネタを適用しないで、次にそのネタを適用して同じチームが同じ開発対象を開発してみれば、生産性の向上率は (延べ作業時間の比の逆数として) 求まるように思われる。 たとえば、そのネタを適用しないときに 200 人月、適用したときに 100 人月かかったとすると、そのネタによって生産性が２倍だけ向上したということができる。 これは、いわば生産性の向上率を実施検証によって求めたことに他ならない。
ところが、こういった実施検証はそう簡単ではない。 もしも、同じチームが同じソフトウェアを２回開発すると、開発者は以前の開発内容を記憶しているので２回目の方が生産性を高くできるに決まっている。 暗黙のうちに再利用がなされてしまうのである。 したがって、同じ開発対象を異なるチームに開発させなければ測定にならない。 こうすると困ったことに各チームの開発能力が等しいことを保証できなくなる。 そこで、統計的に意味のある値を得るために、複数のチームに同じものを開発させて平均値をとる必要が生じる。 たとえば、10 チームがそのネタを適用せずに開発し別の 10 チームがそのネタを適用して開発して、これらの結果を比較するような大規模な実施検証をしなければならなくなる。 いわば新薬の効果を検証する実験に似たことをするのである。
この測定方法は大掛かりになりそうであるが、精度の高い測定結果が得られそうである。 成果物をどう計るのかとか、どうやってバブルを検出して単純生産性を補正するのかなどに悩まずに、成果物の量は同じだとして延べ作業時間の方を比べればよいからである。 この実施検証をする際の問題点は、性能の良いもの悪いもの、バグの多いもの少ないものなど様々な質の成果物が得られることだろう。 したがって、その質までも問題にしないと公正な測定結果にはならない。 成果物の質を合わせるのは実際には難問であるが、ソフトウェアの品質に関する具体的な基準を設けて、ある水準以上にすることを条件にして比較すれば、かなり妥当な生産性の向上率を求めることができそうである。
このような実施検証は大いに意味があると思うのであるが、実施したという報告を聞いたことがない。 大がかりで面倒だとみなされて敬遠されてしまうかもしれないし、非生産的だとみなされて開発メンバに応募しようとする人が現れないかもしれない。 また、何といっても費用がかさむのは難点である。 しかし、莫大な金を食うモータスポーツが車の安全性を向上させたように、開発レースは生産性の向上に寄与することは確かだろう。 遊び心に訴えて、開発レースを楽しむことに賛同してくれる方々を増やすことで資金が調達できれば、実施検証がスムーズに行えるかもしれない。
そもそもソフトウェア開発は人間の精神活動というパラメタに全面的と言ってよいほどに依存している。 そして、生産性を左右するこのパラメタはいろいろな意味でばらつきが大きいために、各ネタの効果を測定しようとしても、その影に隠れてしまい、てこずっているのが現実である。 しかし、もしも生産性の向上率を真剣に測定しようとするのであれば、このような実施検証をしてもよさそうである。 そして、この程度の細心の注意を払って実施検証をしない限り、正確な生産性の向上率を求めることはできそうにない。
このように考えると、ソフトウェア開発の生産性や生産性の向上率は、簡単には数値化できないことが、またもやお分かりいただけると思う。
あるネタの適用による生産性の向上率を求める方法には、実施検証の他に積み上げ方式がある。
積み上げ方式では、まず個々の作業における効果を推定するステップがあり、次にこれを積み上げるステップによって総省力化率を算出して、生産性の向上率を求める。 後者の積み上げステップは誰が計算しても同じ結果が得られるのであるが、前者、すなわち効果推定ステップの方はどうしても主観や感性に頼らざるを得ないものである。 こういう悪条件のもとで生産性の向上率を求めるには、できるだけ客観性を持たせて根拠らしきものを明らかにするための努力が大切である。 そこで、効果の推定に当たっては支援対象作業の割合と省力化の割合の積として表現することを推奨する。 一つの数値ではなく二つの数値の積にするには、より深く効果を分析することが要求されるし、もしも他の人の見積値と大幅な違いが生じたときにその違いを分析するためにも有効である。
生産性の向上率を求めるには、以下の二つのパーセンテージを推定して、それらを (100 ％を１とする) 割合に変換して、それらの積の逆数を計算すればよい。
・ 支援対象作業の割合
(そのネタがソフトウェアの開発作業全体の中の何％ほどの作業を支援するのかを延べにして示す。 メンテナンス作業を除いたソフトウェア開発作業を１、すなわち 100 ％として、延べにした支援対象作業の割合をパーセンテージで示す。)
・ 省力化の割合
(支援対象作業の作業内容の何％を自動化省力化するのかを示す。 完全に省力化できれば 100 ％、何の支援もなければ 0 ％として、省力化の程度をパーセンテージで示す。)
たとえば、開発全体の 20 ％を占める作業を５％支援すれば、それぞれの割合の積を求めることで、１％だけ省力化できることが分かる。 そして、この１％の省力化は、約 1.01 倍に (１／0.99 倍に) 生産性を向上させることを意味する。
実際には“支援対象作業の割合”も“省力化の割合”もなかなか数値化しにくいものであり、主観や感性に頼ってエイヤッと見積もる以外にないかもしれない。 しかし、少なくとも 40 ％なのか 20 ％なのか 10 ％なのか 5 ％なのかという程度の荒っぽさであれば、あまり誤りを犯すことなく推定できることだろう。 その程度の精度だと割り切ることにしても、とにかく数値化していただきたい。
ところで、生産性を向上させるネタの中には、特定の作業を支援するだけでなく、その後の工程にも効果を与えるものもある。 たとえば、要求仕様の明確化を支援するネタは、その作業そのもの生産性を向上させるだけではなく、後工程の作業の手戻りを少なくする効果をもつものである。 こういう場合は後工程に関する省力化率も同様に“支援対象作業の割合”と“省力化の割合”の積の形で表現して、これらを積み上げる (累積する) ことでトータルな省力化率を計算することにする。
ちなみに、この算出方法は、信頼性の向上による生産性向上の効果を数量的に理論づける方法としても使えそうである。 信頼性を向上させると、後工程で費やされる無駄な作業を少なくできるので生産性を向上させることができるからだ。
さて、実際にこの積み上げ方式で、ツールの改良点などのネタごとにその生産性向上の度合いを計算してみると、ほとんどのネタは１％にも満たない極めて小さな値になってしまい、がっかりすることがほとんどである。 塵も積もれば山になるのだと自分に言い聞かせて、効果の薄いネタを数多く適用するのも一つの方向かもしれない。 しかし、既に効果的なネタは拾い尽くされているので大幅な効果があるものは残っていないのは、全く残念なことである。
なお、この積み上げ方式で生産性向上の度合いを計算する実施例が ｢付録３．積み上げ方式で生産性の向上率を求める例｣ にあるので、ご参照いただきたい。
この節では、ソフトウェア開発の生産性は向上しているかどうかという問題に取り組む。 ただし、この問いかけに明確な証拠を示した上で答えることは非常に難しい。 そこで、製造作業の生産性などと比較したり、ソフトウェア開発の歴史を振り返ったりしながら、ソフトウェア開発の生産性は向上しているかどうかの状況証拠を示す。
最初に、参考のために製造作業の生産性が向上している理由を調べてみよう。
製造作業の中でも大量のコピーを作る繰り返し作業の生産性は、工業製品の大量生産を経験することによって相当高いレベルに達している。 既に多くの工業製品の製造において、人間ではなく機械が製造作業の主要部分を実施するようになっている。 そこでは人間は補助的な仕事をするに過ぎない。 現在の進んだ技術をもってすれば、費用がかかるかもしれないが、製造作業を完全に自動化することも、既に多くの製品分野において可能になっている。 たとえば、ロボットを製造する工場に行くと、ある種の機械を自動的に製造しているロボットの活動が見学できる。 そして、こうしたロボット自体がロボットによって自動的に昼夜の区別なく製造されているのを目の当たりにしたりする。
十分な設備投資をすれば、人間が直接かかわる“延べ作業時間”をゼロに近づけられるから、生産性 (ある基盤を前提にした生産性) を無限大に近づけることが可能である。
しかし、実際にはどの程度の価格の製品をいくつぐらい製造するのかによって基盤の整備にさける投資額がおさえられるので、限られた投資の範囲でどれだけ生産性を上げられるかの勝負になっている。 言い換えると、生産性を上げることは可能なのであるが、それを安価に実現することに苦労しているのである。
大量のコピーを製造する際の生産性は、なぜ高いレベルに上げることができたのだろうか？ もちろんそこには多くの人々のアイデアや努力の積み重ねによるところも大きいのであるが、コピーを製造することについては、次の二つの特徴があったためだということもできる。
一つは、生産性を客観的な数値で表せる点である。 生産性を向上させる新たな提案がなされたときに、その効果の程度や副作用の程度を正確に把握できるので、迷信の生まれる余地がない。 新たな提案を正確に明快に評価できる。
もう一つは、何といっても製造作業そのものが創造的な知的作業を必要としない機械的に処理できるものだという点である。 実際には、何らかの製品の製造工程を機械化しようとすると、そこには実施上のいろいろな問題点があることだろうし、その解決には製造技術者たちの知的作業を必要とすることだろう。 しかし、既に数多くの製造作業の機械化の実績が示すように、そういったもののほとんどは技術的に解決可能だといって間違いない。
製造作業の生産性とは対照的に、ソフトウェア開発などの設計作業は、生産性を高める際に都合がよい前述の二つの特徴を備えていない。
第一に、生産性を客観的な数値で表わすことが困難である。 生産性に関する共通認識を得るために、できるだけ科学的な手法を採用して、しかも複数の方法を併用して判断するといった最善の努力をしたとしても、その数値を求める際にどうしても主観や感性に頼らざるを得ない部分がある。 あるいは、これらに頼らないためには、大規模な実施検証が必要になる。 この辺りは、前節 ｢４．２ ソフトウェア開発の生産性の計り方いろいろ｣ で述べたとおりである。 したがって、生産性を向上させる新たな提案がなされたときに、どの程度の効果があるものなのか本当のところがなかなかはっきりしない。 こういう状況では、それぞれの人がそれぞれの手法を最善だと考えることになりがちである。
第二に、設計には機械的に処理しにくい作業が含まれている。 設計の根幹には、これから作ろうとするものを頭の中に思い浮かべて、それを誰もが製造できるように具体化する作業がある。 この種の知的作業の大半は、どうしても機械的に処理できないために、人間が遂行する他ないのが現状である。
コンピュータにできるのは、人間が立てた数式に従って計算することか、あるいは人間の設計作業を補助的にまたは間接的に支援することのどれかである。 本来ならば、人間ではなくコンピュータに設計作業の中心部分をまかせたいところである。 しかし、人間が行っている設計作業の大半は、数式で表現できるような部類には含まれない。 そして、そういった作業をコンピュータに代行させるにはどういうアプローチを取ればよいのかさえも、今のところは暗中模索の状態である。 製造作業の方は、大概のことは機械で処理できると自信をもって言えるのと対照的である。
このように決して生産性を向上させやすい条件が整っていない中で、ソフトウェア開発の生産性は向上しているのだろうか？ 一般には ｢ハードウェア製造の生産性は飛躍的に向上しているわりに、ソフトウェア設計の生産性は向上していない｣ との認識である。 ソフトウェア開発にかかわっている大多数の人々も、本音のところで、生産性はほとんど向上していないと思っていることだろう。
ここでは問題をきわだたせるために、ソフトウェア開発の生産性はほとんど向上していないと決め付けてみる。 そして、これに反論できるかどうかで、生産性が向上しているかどうかを判断したいと思う。
そもそも生産性を向上させるには何らかのネタ (施策、仕掛け、仕組み) があるはずなので、それらをピックアップして、本当に生産性を向上させてきたかどうか、ソフトウェア開発の歴史をざっと振り返る中で検証してみたいと思う。
このように考えると、古き良き時代にはソフトウェア開発の生産性を向上させることができたという次のような反論がありそうである。
プログラミング言語については、第一世代の機械語か、第二世代のアセンブラ言語へ、そして第三世代のコンパイラ言語へと世代交代していくにつれ目にみえる生産性向上効果があったことは、万人が認めるところである。 また、インターラクティブな (会話的な) コンピュータ利用やエディタの発展などもそれなりに効果があったことも間違いない。 たとえば、アセンブラ言語からコンパイラ言語へと変えることで、開発の延べ 60 ％にあたる作業を、5/6 ほど省力化して、1/6 にしたと見積もるとすれば、開発全体で 50 ％の省力化を果たしたことになり、つまり生産性を２倍にしたことになる。
このようにコンピュータが開発された初期の頃には、コンピュータに処理させやすく、かつ効果の大きなネタ (施策、仕掛け、仕組み) がいくつもあったので、そういうネタをツールに組み込むことで、大いに生産性を向上させることができた。
したがって、上述の反論は納得がいくものである。 したがって、古き良き時代には、ソフトウェア開発の生産性は向上したということを認めることにする。 そして、コンパイラ言語などを活用することにより、あるレベルにまで生産性が上がり、その生産性レベルが世間相場になったところまでは認めることにする。
ところで、その後はどうかと考えてみると、古き良き時代に効果の大きなネタはすぐに拾い尽くされてしまい、その延長線上では、ほんの少ししか生産性を向上させることができなくなったように思われる。 このことによって、ここ 20 年ほどの間はツールによる生産性の伸びが停滞しているのではないだろうか？ つまり、以前の世間相場よりも高い値に生産性を向上させることができていないように思われる。
さて、これに反論することはできるだろうか？ それには、効果の大きなネタをいくつか取りあげて、その効果を明確に示すことが必要である。 ネタの効果を評価する方法は、｢４．２ ソフトウェア開発の生産性の計り方いろいろ｣ および ｢付録３．積み上げ方式で生産性の向上率を求める例｣ に詳しく説明してあるので、それを使って反論すればよいのである。
読者の皆様方は、反論できるようなネタを何かご存知だろうか？
1990 年代の前半から開発支援ツールベンダの端くれになった筆者は、本来ならその職業がらこれに反論してしかるべきである。 しかし、残念ながらこれに反論することができない。 これに反論したいのであるが、コンピュータに処理させやすく、かつ効果の大きなネタは、古き良き時代に既に拾い尽くされている。 したがって、設計作業の中の機械的に処理できる部分を人間に代わって遂行するというネタの延長線上には、大したネタは残っていないのである。
一人が１日に書く (完成させる) プログラム行数の平均値に着目してある集団を調べてみたところ、ここ 10 年ほどの間 20〜30 行のレベルにとどまっており、ほとんど増加がないように思われる。 もう少し多くのプログラムが書けるようになっても良さそうであるが、いまだにこんなところが相場である。 この値は、人間が知的作業をこなす速度そのものに依存しているので、人間自身が設計作業の中心部分を遂行する限り大きな伸びは期待できない。 もちろん、プログラムを生み出す速度には個人差があることだろうし、訓練による速度の向上も期待できることだろう。 こういった変動要素はあるものの、トータルに見てその平均値を２倍３倍にすることは困難だと思われる。 もしもソフトウェアの開発能力を飛躍的に向上させる突然変異が発生して、それが人類全体に広まるようなことがあると話は別であるが、... 。
こう考えると、設計の根幹をなす知的作業をコンピュータに実施させるというネタに期待をかけたくなる。 つまり、人間ではなくコンピュータが設計作業の中心部分を実施するようにできればよいのである。 ところが、この辺りは今なお実現の見通しが全く得られていない。 これが現状の技術レベルなのである。このことを認めたとすると、できることは次の二つである。
・ これまでの延長線上のネタ、すなわち ｢設計作業の中から機械的に処理できる部分を抜き出してコンピュータに遂行させる｣ というネタをツールに組み込む
・ ツールによる支援に伴う協調的効果を狙う
前者は、残念なことに、ほんのわずかの効果しかもたないネタが残っているだけである。 しかし、塵も積もれば山となると言うので、こつこつと塵のような生産性向上のネタをサポートしていくことも無駄ではないだろう。 しかし、もはや大きな効果は期待できない。
後者の協調的効果とは、機械的な処理をコンピュータに遂行させることによって醸しだされる効果を指す。 たとえば、ワープロ機能は、単に文章の追加・変更・削除などの修正作業を簡単にできるように支援するだけでなく、曰く言い難い文書作成支援効果をもっているのも事実である。 悪筆の手書きにたくさんの修正が入った文章は読む気がしないが、ワープロの綺麗なアウトプットであれば、推敲が楽しくなるし、不揃いのところを見つけると形式を統一しようという意欲もわくものである。 効果を数値化しにくいとはいえ、こうしたことで生産性が向上することは確かである。 コンピュータとハサミは使いようなのである。
一人の人間が１日に書く (完成させる) プログラム行数の平均値を見る限り、生産性の向上はあったとしてもわずかだということになると、一体全体ツール類は何をしてきたのか、また生産性を向上させるツール類の実力とはそんなものなのかと疑問に思われるかもしれない。 そこで、これにお答えしよう。
ほとんどのツールは、人間にとって過酷な面倒な作業を代行することによって人間の作業を大いに楽にした。 CASE ツールのダイアグラムエディタはうんざりするようなダイアグラムの書き直し作業の負荷を軽減してくれるし、ワープロやプログラムエディタは追加・変更・削除などの修正作業を億劫ではないものにしてくれるし、ドキュメンタはドキュメントのかなりをプログラム情報から抽出してくれるし (この結果プログラム情報とドキュメントの不一致を人間がチェックしなくてもよいようになる)、... と何とありがたい召使たちではないだろうか？ ツールによる支援に伴う協調的効果とあいまって、開発の作業を大変に楽にしてくれている。
こう見てくると、ここ 10 年ほどの間ツール類に組み込まれてきたネタは、本当の意味での生産性の向上に貢献しているというよりも、むしろソフトウェアの開発作業を快適にすることを追求してきたことが分かる。 たとえば、車の基本機能が成熟した後には、快適な空間の提供を目指して車が開発されている。 これと同様で、ソフトウェア開発支援ツールにおいても ｢快適なソフトウェア開発環境の提供｣ は重要テーマである。 そして、これは広い意味で“生産性を向上させるもの”だといって間違いない。 しかし、その“生産性の向上”というのは、いわば“掛け声”のようなものであり、｢４．２ ソフトウェア開発の生産性の計り方いろいろ｣ で述べたようにして計ることを想定した“厳密な意味での生産性の向上”ではないのである。
トピック 8： ツールでどれだけ生産性が向上するか
開発支援ツールベンダの端くれの筆者は、ときどき困った質問を受ける。 それは、特定のツールを指して、そのツールによって生産性がどれだけ向上するのかと聞かれることである。 特定のツールの生産性の向上率を質問されても、その答えは質問した人が握っているので、困惑してしまうのである。
生産性の向上率を求める方法は二つご紹介したので、実施検証か積み上げ方式かのどちらかで求めればよいだけなのであるが、その際にいろいろと明らかにしなければならないことがある。
ここで、｢付録３．積み上げ方式で生産性の向上率を求める例｣ に例示した“ツールによるダイアグラムの記述支援というネタの効果の求め方”をご参照いただきたい。 この中には、要求仕様を把握する際の誤り率が高い開発プロジェクトの場合には、ある程度生産性を向上させることができるが、そうでない場合にはあまり生産性を向上させられないということが説明してある。 したがって、この例の場合には、要求仕様を把握する際の誤り率が分からないと、ツールによる生産性の向上率が求まらない。 また、既にダイアグラムに書き下すという手法を用いている開発プロジェクトかどうかによっても、ツールの効果の程度は違ってくる。 このように、開発プロジェクトの資質やそこで採用している開発手法によって、ツールによる生産性の向上率は大幅に違ってしまう。
100 年先ならいざ知らず、現状ではすべての開発作業を自動化するツールは存在しない。 したがって、あくまでも人間が中心にいてツールを使って仕事を進めていくことを前提にしなければならない。 こうすると、人間がどのような行動をとっていたのかということが問題になり、それによって生産性の向上率は変わってしまうということなのである。
そこで、特定のツールの生産性の向上率を問われたときに、筆者は次のように答えることにしている。
一般に、ツールが生産性を向上させるのは、そのツールの狙いどころに合った使い方をするときである。 したがって、ツールを選択するときには、どこが優れているかという話を聞いて納得するだけでなく、実際に試用して開発プロジェクトに合っているものかどうかの感触を得ることが大切である。 一般的にいって、どんな場合にも生産性を何倍にすると断言できるようなツールなどは存在しない。 したがって、お客様の業務プログラム開発の場合についてはどうかと試すことで、どの程度の生産性を上げられるのかが見えてくるものである。
ケネディ大統領風に言うなら、｢ツールがどれだけ生産性を向上させられるかと問うのではなく、お客様ならそのツールによってどれだけ生産性を向上させられるのかと自問していただけませんか｣ ということなのである。
ソフトウェア開発の生産性は、ここ 10 年ほどの間ほとんど向上していないという否定的な意見を述べてきた。 一応これを認めたとすると、果たして生産性を向上させる道は全く閉ざされてしまったのだろうか？ いや、生産性を向上させるのが困難だとしたら ｢生産性の向上と同等の効果を発揮する道はないのだろうか？｣ と問うべきかもしれない。 言い換えれば、中身の詰まったプログラムを開発するスピードは限られているものとして、何ができるのかというように問題を設定し直してみる。
幸いなことにといっては語弊があるが、これまでに開発されたプログラムの多くはバブルでふくれあがっている。だから、ここに着目するのがよさそうである。 バブルを減らして無駄な作業を省くための方策、すなわち部品化再利用を推進することによって生産性を向上させるのである。 これは、ツールだけではなく、ツールと部品の組合せによって、生産性を向上させる道だということができる。
部品化再利用を推進していくと、面白いことに、極端な場合にはプログラムを生産 (開発) しなくても、ある機能のソフトウェア製品が生産 (開発) できるという事態に遭遇する。 したがって、ソフトウェア開発の生産性に関して認識を新たにすることが必要になる。 ここで、｢１．１ 特注業務プログラムと業務パッケージの違い｣ の中の ｢トピック 1： 金の卵を生む業務パッケージへの夢｣ の内容を思い出していただきたい。
そもそも“生産性”という言葉は、ソフトウェアを開発せずに徹底的に再利用するアプローチにはしっくりこない｡“生産”という言葉の響きに惑わされると、単純に成果物の量を増やせばよいという単純生産性至上主義に陥ることになりがちである。 成果物の量を増やすことばかり考えるのではなく、発想を変えて部品化再利用を推進することは、すなわち再利用率 (非生産率) を高めることは、開発に費やす延べ作業時間を少なくするので、実質的に生産性を向上させるもう一つの方法なのである。
そこで、再利用によって実質的にどれだけ生産性が向上するのかを表わす指標として再利用による生産性の向上率を導入する。 この指標は、あるソフトウェアの中のバブルを取り除けば、すなわち再利用できるところは徹底的に再利用すれば、無駄な作業を省けるので、実質的にどれだけ生産性が向上することになるのかを示すものである。 この値を正確に求めるには、再利用をしない場合と再利用をする場合のそれぞれについて前述の実施検証を行う必要がある。 しかし、おおよその値でよければ次の計算式によって求めることができる。
再利用による生産性の向上率 ＝ 単純生産性 ／ 補正生産性
この計算式の値は、実際に開発したプログラム行数を実質的に開発が必要なプログラム行数で割った値 (以下の計算式の値) と同じことなので、プログラム行数当たりの作業時間 (開発にかかる時間) が一定だと仮定すると、再利用による生産性の向上率を示すことになる。
実際に開発したプログラム行数 ／ 実質的に開発が必要なプログラム行数
ちなみに、この計算式を使って、特別な二つのケースについて、再利用による生産性の向上率を求めてみよう。 一つのケースはすべてバブルの場合である。 この場合は、補正生産性がゼロになり、再利用による生産性の向上率は無限大になる。 もう一つのケースはバブルが全然ない場合である。 この場合は、単純生産性と補正生産性が一致する。 したがって、再利用による生産性の向上率は１となる。 この１という値の意味は、バブルが見つからないので、再利用という手段では生産性を向上させることができないということである。 このことは観点を変えると、バブルがあれば、再利用によって生産性を向上させる余地があるということができる。 したがって、これまでに開発されたプログラムの多くがバブルでふくれあがっていることに着目したのである。
本書では、これまでにたびたび、各種のソフトウェア資産を再利用することによって生産性が向上すると述べてきた。 このことは、再利用による生産性の向上率が１以上であることを意味する。 言い換えれば、バブルを開発するという無駄を行っていた場合には、そういう無駄な作業を再利用によって駆逐できるので、生産性を向上させることになるのである。
なお、部品化再利用を積極的に推進しても、補正生産性の値は上がることにはならない。 なぜなら、補正生産性は、バブルを成果物だとはみなさない尺度、すなわち無駄は無駄だとする“厳しい尺度”だからである。 これに対して、単純生産性の方はバブルまでも開発の成果物に含めてしまう、いわば“おうような尺度”だと言える。
一般的に ｢ツールによってどれだけ生産性を向上させられるのか？｣ という問いが意味をなさないのと同様に、一般的に ｢再利用によってどれだけ生産性を向上させられるのか？｣ という問いも意味をなさない。 しかし、特定の開発プロジェクトの特定の業務プログラムの開発に的を絞ると、両方のどちらの問いも意味をもつことになる。 そして、ある種の発展途上の開発プロジェクトでは、ほんの少しの改善で、目を見張るような生産性向上効果を発揮する場合がある。
たとえば、共通サブルーチンを括り出すという習慣のない開発プロジェクトにとっては、重複開発していた部分を共通サブルーチンにして、再利用するように切り換えることが目を見張る効果を発揮する。 また、各開発者ごとに別々の操作性に関するプログラムを重複して開発していたプロジェクトにとっては、操作性に関係する一つのメインルーチンのひな型を配布して、それをコピーして適当な修正を施すような開発方法に変えることが生産性の向上に有効である。
このように、どの程度の部品化再利用をしていたかによって、再利用による生産性の向上の度合いが異なるものである。 元来、再利用の程度が低い開発プロジェクトであればあるほど、大きな効果が得られる。 そして、100 ％の部品化再利用をしている開発プロジェクトでない限り、何らかの効果を上げることができる。 なお、100 ％の再利用とは、部品を組み合わせるだけで業務プログラムに仕立てることを意味する。
こう考えてくると、ほとんどすべての開発プロジェクトは 100 ％の部品化再利用をしているわけではないので、大いに生産性を向上する余地のあることが分かってくる。 つまり、部品とツールの組合せによって (または 4GL のように部品を内包したツールによって) 再利用を推進すればよいのである。 これとは対照的に、ツールだけによる生産性向上策は、既にネタ切れになっており、生産性を向上させあぐねていることは、既に述べたとおりである。
部品化再利用には、図4-1 のように二つの方式がある。 このどちらを採用したとしても、開発者の気ままにまかせた開発方法よりは良い結果を生む。 開発者の気ままにまかせた開発では、共通にできるプログラムであっても、各開発者があたかも新たな発明をしたかのような創造の喜びの代償として、ばらばらなものにしてしまいがちである。 このようにばらばらになるよりは、素性の知れたコピーの方がまだましであるし、できれば整然と再利用することの方が良いに決まっている。
コピー実施型再利用
プログラムの開発スピードを上げることができる
しかし、バブルでふくれたプログラムになる
プログラムが大量にできあがるので、生産性が高いように見える
しかし、メンテナンス対象資産を増やしメンテナンスを難しくする
コピー排除型再利用
１本のプログラムの開発に要する行数が 1/2 なり 1/3 なりに減る
(例：共通サブルーチンライブラリを充実させて、それを徹底的に再利用)
コンパクトなプログラムになる
見かけの生産性は向上しないが、真の意味で生産性は向上する
メンテナンス対象資産が少なくなりメンテナンスが楽になる
図4-1: 再利用の二つの方式
部品化再利用の方式の一つは、コピー実施型再利用である。 バブルでふくれたプログラムになることは構わずに、プログラムの開発スピードを上げることである。
中身の詰まっていないプログラムの開発ならば、スピードを付ける方法はいろいろ考えられる。 たとえば、しばしば使用されるプログラムの言い回しを教育して、空で言えるようなベテラン開発者を養成することである。 空で言うのが難しければ、手本となるプログラム群の教育を行い、適当なものをコピーするように推奨する方法も考えられる。 そういう方法の中で特に、操作性に関係するメインルーチンをコピーすることなどは、真先に推奨するのがよいだろう。
こうして、コピーした分も新規開発行数に含めてカウントすれば、見かけの生産性 (単純生産性) は大いに上がることになる。 そして、こうすることは、従来の気ままな開発以上に問題を拡大することにはならない。 これまでと同様にバブルでふくらんだソフトウェア資産を増やしてメンテナンス負荷を増大させるという問題は残ったままであるが、気ままな開発者たちが再発明するばらばらのバブルプログラムよりも、素性の分かるコピー (バブルプログラム) の方がまだメンテナンスしやすいものである。
もう一つの方式は、コピー排除型再利用である。 少ない新規開発行数で同等の処理をするプログラムの開発を目指すことである。 バブルを徹底して排除するのである。
こうすると、これまで１本のプログラムに必要とした 1/2 なり 1/3 なりの少ない新規開発行数でこれまでと同等の処理を実施するプログラムが開発できるようになる。 たとえば、汎用サブルーチンライブラリを充実させて、それを徹底的に再利用するように開発者を教育するのである。 しかし、主要な汎用サブルーチンは既に洗い出されており、また共通サブルーチンを括り出して利用するのが当たり前になっている現状を鑑みると、これまで以上に少ない新規開発行数にするのは困難かもしれない。 確かにそのとおりだろうが、本書で取りあげた共通メインルーチンやデータ項目部品は、これまであまり利用されていなかった玉なのだから、これらの玉を使うことで相当の成果が上げられるかもしれない。 すなわち、共通メインルーチンやデータ項目部品のライブラリを充実させて積極的に再利用することにすれば、少ない行数で同等の処理を実施するプログラムを作れる余地は大いに残っている。
念のために言うと、コピー排除型再利用は、作るのではなく再利用を追求するアプローチであり、プログラムをふくらませないのだから見かけの生産性 (単純生産性) は向上しない。 しかし、それにもかかわらず生産性を向上させるのと同等の効果を上げることになる。
ここでこの二つの方法を評価してみよう。
コピー実施型再利用は、開発者に再利用の習慣を付けさせて、組織的にコピーを推奨するアプローチなので、バブル資産が蓄積されることになる。 そして、コピーしたソフトウェア資産は時とともに変更されていくために、段々とその素性が分かり難くなっていき、コピーした部分はコピー元とは独立した新たなソフトウェア資産だと考えざるを得なくなる。 これは取りも直さず、メンテナンス対象資産が増えることを意味し、メンテナンス負荷を増大させることになる。
コピー排除型再利用は、開発者に再利用の習慣を付けさせる点は同じであるが、コピーを推奨しない点が異なる。 これは、ソフトウェアを再利用しやすい構造に変えていくアプローチであり、バブル資産を排除することになる。 たとえば‘ビジネスロジック部品’を再利用しても、メンテナンスしなければならないソフトウェア資産を増加させることにはならない。
メンテナンスの観点からは、コピー排除型再利用の方が断然望ましい。 さらに、コピー排除型再利用の方には輝く未来が期待できる。 製造作業においては機械化によって生産性を無限大に近づける道があったのと同様に、ソフトウェア開発においては、コピー排除型再利用を徹底的に追求すれば生産性を無限大に近づけることができる。 なぜなら‘ビジネスロジック部品’を充実させることによって、新規開発をゼロに近づければよいからである。 これは現状の技術で十分に可能なことである。
従来の業務プログラム (第一段階)
第四世代言語などを用いて開発した業務プログラム (第二段階)
部品化アプリ (第三段階)
ハッチングの部分は､‘ビジネスロジック部品’でカバーすることによって、実際に再利用された部分、または再利用しやすくなる部分である。
図4-2: 部品化再利用の拡大の歴史
もちろん、無限大の効果を上げるための道のりは簡単ではないだろう。 工業製品の製造においては製品ごとにその製造工程を機械化する基盤が必要だったように、コピー排除型再利用においても応用分野ごとに‘ビジネスロジック部品’の一式という基盤が必要になる｡‘ビジネスロジック部品’を充実させるための継続的な努力などの課題もあることだろう。 しかし、コピー排除型再利用は本質的にソフトウェア開発を合理化するものであることは間違いない。
ビジネス分野の典型的な業務プログラムに関する部品化再利用には、図4-2 のように三つの発展段階があることだろう。
大抵の開発プロジェクトは、汎用サブルーチンを再利用すること、および共通サブルーチンを括り出して再利用することを行っており、こういったサブルーチンの再利用は既に習慣にまでなっているのが普通である。 そういうプロジェクトが開発する業務プログラムは、少なくとも第一段階に達していて、プログラムの２割〜３割程度を汎用サブルーチンの再利用でまかなえることだろう。 当然のことであるが、そういうプロジェクトに対して、もっとサブルーチンを再利用するように勧めても、もはや生産性を向上させることはできない。 たとえできたとしても、再利用し損ねていた分に対するわずかな生産性の向上があるだけである。
ところで、操作性に関係する共通メインルーチンを再利用していないプロジェクトは、かなり存在するものと思われる。 そういうプロジェクトでは、共通メインルーチンの再利用を実施し始めることによって生産性を向上させることができる。 こうすることで、第二段階に持ち上げられた業務プログラムケーションプログラムは、その２割〜３割程度を汎用サブルーチンの再利用でまかなうことに加えて、新たな３割〜４割程度を共通メインルーチンの再利用でまかなえることだろう。 そして、共通メインルーチンを新たに再利用し始める分だけ、すなわち第一段階から第二段階に上げる分だけ生産性を向上させることができる。
さらに再利用を徹底的に行おうとするプロジェクトには、データ項目部品の再利用を始める道がある。 これを適用することによって、第三段階に持ち上げることができる。こうなると、業務アプリケーションプログラムは、データ項目部品の恩恵を受けることができる。汎用サブルーチンの再利用および共通メインルーチンの再利用ではカバーできなかった残りの部分をデータ項目部品でまかなえることだろう。 すなわち、部品化アプリにするのである。 ただし、第二段階から第三段階に上げても、初版の業務プログラムを開発する際の生産性はあまり向上しない。 生産性が向上するのは、初版の業務プログラム (すなわち部品化アプリ) を再利用するような局面である。 たとえば、初版の業務プログラムを他の顧客向けにカスタマイズするような場合とか、初版の業務プログラムをメンテナンスしていくような場合である。
ここで、第一段階から第二段階に向かう過程を詳しくみてみよう。 メインルーチンを再利用する方法は、２種類ある。 一つは、操作性に関係するメインルーチンのひな型を配布して、それをコピーしてから適当な修正を施す形態の“コピー実施型再利用”である。 もう一つは、4GL (すなわち部品を内包したツール) や嵌め込みシステム (すなわち部品とツールの組合せ) によって共通メインルーチンを再利用する形態の“コピー排除型再利用”である。 なお、｢３．２．３ SSS から RRR ファミリーへ｣ の中の ｢トピック 6： 部品化イベント駆動方式を実現したツール｣ で述べたプレ生成ツールによる開発は、コピー実施型再利用であり、ポスト生成ツールによる開発は、コピー排除型再利用だということができる。
どちらの方法をとっても、同じように生産性を向上させることができる。 ただし、コピー実施型再利用の場合はメンテナンスの負荷が大きくなるので、是非ともコピー排除型再利用にすべきである。 このメンテナンスの負荷の違いは、たとえばオリジナル (原本) に変更が必要になった場合を考えてみるとよく分かる。 なぜなら、コピー排除型再利用の場合は、オリジナル (原本) に対してだけ変更を行えばよいのであるが、コピー実施型再利用の場合は、コピーして作ったプログラムをすべて変更することが必要になるからである。
ここまで、ビジネス分野の典型的な業務プログラムを第三段階の部品化アプリにする方法を述べてきた。 ほとんどすべての開発プロジェクトはまだ 100 ％の部品化再利用をしているわけではないので、こうすることによって大いに生産性を向上させることができることがお分かりいただけたと思う。
トピック 9： 開発生産性とメンテナンス生産性の向上率
本書では、開発作業だけを対象にした生産性、すなわちメンテナンス作業を考慮に入れない生産性について考察してきた。 しかし、メンテナンス地獄という言葉がときどき話題にのぼることを考えると、開発作業の２〜４倍にも及ぶメンテナンス作業 (開発が終わった後で行われる機能追加や機能変更やバク修正など) に押しつぶされないようにする対策も重要である。 実際のメンテナンス作業の割合は、各企業の情報部門の様々な事情によって差はあるが、メンテナンス費用という見方をすると、固定費として大きな割合を占め、無視できないくらいになっていることが普通である。
なお、ここで述べる開発生産性とメンテナンス生産性の向上率に関する説明は、メンテナンスという言葉をカスタマイズという言葉に置き換えることによって、開発生産性とカスタマイズ生産性の向上率の説明になる。 したがって、メンテナンスとカスタマイズの両方の視点から以下を読むようにお願いする。 たとえば、業務パッケージのカスタマイズを行うビジネスにとっては、カスタマイズ作業を対象にした生産性は採算を左右するキーファクタだから、以下の話は重要である。
ここでは、これまでのように開発作業だけを対象にした生産性の向上率だけでなく、メンテナンス作業を対象にした生産性の向上率についても考察する。 なお、前者を開発生産性の向上率と呼び、後者をメンテナンス生産性の向上率と呼ぶことにする。 そして、ライフサイクル全体をとおした生産性の向上率を生涯生産性の向上率と呼ぶことにする。
これら三つの生産性の向上率の間には次の関係が成り立つ。
１＋α １ α
───────── ＝ ───────── ＋ ─────────────
生涯生産性の向上率 開発生産性の向上率 メンテナンス生産性の向上率
ここで、α はメンテナンス比を表す。 これは、開発にかかった延べ作業時間の何倍をメンテナンスのために費やすかという倍率である。 たとえば、開発の３倍の延べ作業時間をメンテナンスに費やすものとすると、α の値は３になる。
ちなみに、あるケースについて上の式にあてはめて、生涯生産性の向上率を評価してみよう。 上の式は直感的には理解しにくいので、数値例を挙げた方が分かりやすいと思う。
開発の延べ作業時間が 10000 時間、メンテナンスの延べ作業時間が 30000 時間だとする。 したがって、α の値が３になる。 この場合に、開発生産性を５倍にするのと、メンテナンス生産性を２倍にするのとでは、どちらが効果的なのかを計算してみよう。 上の計算式によると、前者の生涯生産性の向上率は 1.25 になり、後者の生涯生産性の向上率は 1.6 になるので、メンテナンス生産性を２倍にした方が効果的なことが分かる。
これは、次のようにして検算できる。 前者の場合は、以前 40000 時間かかった仕事が、32000 時間 (すなわち 10000 × (1／5) ＋ 30000) で済むことになるが、後者の場合は、25000 時間 (すなわち 10000 ＋ 30000 × (1／2)) で済むことになる。 したがって、メンテナンス生産性を２倍にした方が効果的だということが分かる。
ソフトウェアの生産性を向上させようとするときに、開発生産性の向上率だけを問題にしがちであるが、これでは改善方法の選択を誤ることになりかねない。 正しくは、生涯生産性の向上率を問題にすべきである。 そして、α の値が１より小さいか大きいかによって、開発かメンテナンスか、どちらの改善により力を入れるべきかが決まるので、力の配分を誤らないようにすることが大切である。 α が１より大きい場合、すなわちいわゆるメンテナンス地獄の場合を想定すると、生涯生産性の向上率を大きくするには、開発生産性よりもメンテナンス生産性の向上率の方を大きくすることに努めた方が有効である。 これは極めて常識的な判断だと思うが、こうした合理的な判断がしばしば忘れられたり無視されたりしているのが現状ではなかろうか？
ところで、生産性を向上させるネタの中には開発作業に効果のあるものとメンテナンス作業に効果のあるものがある。 したがって、各ネタの効果を知るには開発生産性の向上率とメンテナンス生産性の向上率の二つの値が必要になる。 たとえば、プログラムの構造を美しくするあるネタは、開発生産性の向上率が１％でメンテナンス生産性の向上率が 10 ％だというように二つの値で表現すれば、そのネタの効果をはっきりと理解できる。 そして、α の値が１より大きいか小さいかによって、生産性を向上させるためにどんなネタを選択するのがよいかが決まる。 α の値が１より大きいか場合にはメンテナンス生産性を向上させるネタを重視すべきであるし、そうでない場合には開発生産性を向上させるネタの方を優先すべきである。
これまでは、開発生産性ばかりに気を取られて、メンテナンス生産性には無頓着であったというのが一般的な傾向である。 したがって、これまでおろそかにしていたメンテナンス生産性はまだまだ低いレベルに留まっており、大きな効果を上げるネタが拾いつくされていないものと思われる。 もしもそうなら、メンテナンスに有効なネタを適用することによって、生涯生産性を向上させることができそうである。
ただし、メンテナンス生産性を向上させるネタを適用するには、小手先だけでは改善できず、開発当初からの配慮を必要とする場合が多い。 たとえば､‘ビジネスロジック部品’による部品化再利用は、開発当初からの配慮が必要である。 つまり､‘ビジネスロジック部品’を活用した資産体系へ乗り移ることが必要なのである。 しかし、乗換えを行えばメンテナンス対象資産を整理してバブルを減らすことになり、メンテナンス生産性を大いに向上させるという大成果が得られる。
アプリテック株式会社
Copyright © 1995-2008 by AppliTech, Inc. All Rights Reserved.