ソフトウェア開発の改革

加賀博昭
第一版 1994.2.17 作成
第二版 1996.6.25 修正

改革の必要性
1.1.ソフトウェア開発の現状

現在の社会は大きな変革期を迎えており、その影響で社会の急速な変化、個人の価値観の多様化、地球規模での経済競争の激化などの現象が起きている。このような企業をとりまく環境の変化は、対応次第では危機にもなり得るし、好機にもなり得るものである。対応を誤れば窮地に陥ることになるが、適切に対応すれば大きな利益を得ることもできるのである。

多くの企業では、この変化に適切に対応し企業組織を維持発展させるための中心的手段として情報技術の利用が考えられている。このような状況から考えると、ソフトウェアに対する潜在的な需要は非常に大きいと思われる。しかし、現在のソフトウェア市場においては、この潜在的な需要を顕在化させるには至っていない。

その理由は、顧客が現在のソフトウェア開発に対し、大きな不満を持っているためである。そして、その不満は次のようなものである。期待していたソフトウェアが期限までに納品されない、ソフトウェアの開発にかかる費用が高い、開発期間が長いため必要なタイミングに間に合わない、開発が必ずしも成功しないなどである。これらの問題によって、顧客はこれまでに大きな被害を受けているのである。これでは、顧客が新たなソフトウェアの開発に躊躇するのは当然のことである。

顧客は自身が置かれている厳しい状況を反映して、ソフトウェア開発に対する要求を非常に厳しくしており、より少ない経費での開発、より短期間での開発、より品質の高いソフトウェア、より大規模で複雑なソフトウェアの開発を求めているのである。しかし、現在のソフトウェア開発企業ではこれらの要求に十分に応えることができていないのが現実である。

ソフトウェア開発企業がこれらの要求に対応できない理由は、作成されたソフトウェアの品質が、投下される資金、投入される人員、費やされる時間などに比べて、非常に低いためである。もちろん、ソフトウェアの開発企業が、開発効率を上げるための努力をしていないわけではない。開発効率向上のための長期に渡る努力にもかかわらず、その開発効率はいぜんとして低いままなのである。このことは、現在のソフトウェアの開発体制や開発効率向上のための努力に、何らかの問題が存在することを示唆している。

また、たとえ開発効率が低くても企業としては、顧客の要求を全く無視するわけにはいかないため、ソフトウェアの開発技術者に過大な作業を割り当てることによって顧客の要求に応えようとしている。この結果、開発技術者は次のような問題に直面している。仕事がきつくトラブルが多いためストレスが高い、開発管理者から納期や品質について無理な要求を出される、開発に必要な開発資源が足りない、賃金が十分に支払われないなどである。これでは、問題の解決とは言えない、顧客の問題を解決するために開発技術者の問題生み出しているだけである。真の問題解決は、顧客、開発技術者、開発企業がそれぞれ満足できる解決策でなければならない。そのためには、開発体制の抜本的な改革が必要なのである。

既存の開発体制に手を加えることは非常に難しいことのように思えるかもしれないが、ソフトウェアの開発効率が劇的に解決されないかぎり、ソフトウェア市場の拡大は期待できず、ソフトウェア産業は今後、困難な事態に直面することも考えられる。しかし、開発体制を改革することによって問題を解決することができれば、それによる波及効果は非常に大きく、社会全体にわたる飛躍的な生産性の向上が期待できるものである。また、個々のソフトウェア開発企業にとっては、企業を発展させるための大きなチャンスになるのである。

1.2.問題の原因

ソフトウェアの投入される資源に比べた開発効率の低さは、現在の開発組織や開発プロセスでは解決することができない。なぜなら、現在のソフトウェアの開発組織、開発プロセスは、大量生産型の工業製品を開発するための階層型の生産組織、生産プロセスを基本としており、ソフトウェアのような開発型の製品を開発するには不適切なのである。

つまり、問題の原因はソフトウェアのような開発型の製品を開発するための信頼性が高く安定した開発組織と開発プロセスが確立されていないことである。ソフトウェアは従来型の工業製品とは異なるため、その開発のために最適な組織やプロセスがまだ確立されていないのである。

人間がこれまで作ってきた製品は、その多くは長い製品寿命をもち、それらを生産するための組織を長い期間変える必要がないものである。そして、高い品質や生産性が要求されるのは生産プロセスであって、開発プロセスではなかったのである。ソフトウェアはそのような製品とは大きく性質が異なり、開発プロセスに適した組織が要求される。また、その開発プロセスもこれまでの製品の開発とは違い、開発そのものに高い開発効率や品質が要求されるのである。

現在のソフトウェアの開発組織、開発プロセスは大量生産型の製品の開発作業で使われていた組織やプロセスを基礎とするものである。大量生産型の製品では開発がその製品の全体のコストに及ぼす影響は、その製品が大量に生産されるものであればあるほど小さいものであった。開発は主たる業務ではなくいわば補助的な作業であり、業務の中心は製品を生産することなのである。開発のための組織やプロセスが、全体の組織やプロセスに占める割合はそれほど大きなものではなく、開発自体にそれほど高い生産性が要求されることはなかったのである。しかし、ソフトウェア開発では、開発こそがその業務の中心であり、そのコストの大部分を占めているのである。

そして、組織のなかで開発に携わる人間は非常におおきな割合を占め、開発されるソフトウェアに要求される品質、開発効率やその作業の複雑さは、大量生産型の製品と比較して非常に高くなっている。つまり、ソフトウェアの開発においては、階層型の組織や生産プロセスを基礎とした、従来型の開発組織や開発プロセスとは異なった、より開発作業に適した、柔軟性の高い開発組織や信頼性の高い開発プロセスが要求されているのである。ソフトウェアの品質や開発効率を向上させるためには、ソフトウェアの開発組織や開発プロセスをより開発作業に適したものに改革する必要があるのである。このようなことから考えて、現在広く行なわれている、ソフトウェアの開発を大量生産型の製品の生産プロセスを模倣することによって、開発効率や品質を向上させるといった、考えや試みは明らかに誤りである。

また、現在では従来型の製品においても商品寿命の短命化や、商品の多品種化によって、開発が占める比重が大きくなり、開発にも品質や生産性の高さが強く要求されるようになってきており、大量生産品と考えられてきた製品でも次第に開発費の負担が重要な意味を持つようになってきているのである。本来開発型の組織とプロセスによって開発すべきものを、無理をして大量生産型の組織とプロセスによって開発しなければならない理由はどこにもないはずである。

1.3.改革の目標

改革の目標は、ソフトウェアの開発に適した組織とプロセスを設計し実現することである。つまり、現在の大量生産型の製品の生産を効率的に行なうための階層型組織、その階層型組織の中で新製品の開発を行なうための開発組織であるプロジェクト・チームと、大量生産品の開発生産のプロセスを基本とする考えにもとづいた開発プロセスを改革し、ソフトウェアの開発を最適に行ない得るように組織構造と開発プロセスに作り直すことである。それによって、顧客のニーズを満たした、顧客にとって支払い可能なソフトウェアを、間発技術者に無理な負担をかけることなく、かつ開発企業としても採算が取れるように間発できるようにすることである。

この改革の実現によって次のことが期待できる。
- 顧客満足度の向上
- 開発リスクの低下
- 開発効率の向上による、開発費の削減と利益の増加
- 開発期間の短縮
- 開発技術者の士気の向上
- 開発可能なソフトウェアの規模の拡大
- ソフトウェアの品質の向上と価格の低下による、ソフトウェアの需要の拡大
開発プロセス
2.1.現在の開発プロセスの問題

現在のソフトウェアの開発プロセスは、設計フェーズと実現フェーズに対する認識に誤りがある。大量生産品の生産プロセスで使用される設計書は、開発が終わった後の設計書であり、開発で作成された最初の設計書とは、その完成度が全く異なるものである。ソフトウェアの開発で作成される設計書とは、この最初に作成された設計書と同じ程度の完成度しか持たないものである。それにもかかわらずこの完成度の低い設計書にたいして過大な評価が行なわれ。実験の必要性が過小評価されているのである。

ソフトウェア開発も開発作業である以上、その開発プロセスの中でかなりの量の実験が必要である。仮定が必ずしも正しいわけではないことは、日常生活においてもよく見られることである。この仮定の誤りを発見するためには、実際にそれを実現してテストする必要がある。しかし、現在のソフトウェアの開発プロセスでは、開発の実現化の部分が大量生産品の生産と同じものと考えられているため、この部分に対して不当に低い評価がなされている。この結果、実験がおろそかになり品質の高いソフトウェアの開発が難しくなっている。品質の高いソフトウェアを開発するためには、この実験の作業を充実させることが絶対に不可欠である。

また、大量生産の工業製品とソフトウェアでは複製を作成する難しさが全く異なる。工業製品では複製品を作成すること事体かなり困難な作業であり、完全な複製品を作成するのは不可能である。しかし、ソフトウェアでは複製を作ることはきわめて容易である。しかも、完全な複製品を作成することができる。また、ソフトウェア自体が壊れることはない。工業製品では何年かたつとどんなものでも壊れてしまうものである。現在の開発プロセスでは、このようなソフトウェアの工業製品に比べて有利な特徴が十分に活用されていない。そのため、不必要な作業が多くなり開発効率を下げることになっている。

2.2.要件の実現

開発したソフトウェアは顧客の要件を満たしていなければならない。そうでなければ、顧客にとっては意味がなく、社会的にも全くの無駄である。顧客にとっては、期待していたソフトウェアが手に入らなければ、その影響は大きい。顧客としてもそのソフトウェアによって業務を改善し、生産性を向上させ、商品の競争力を改善しようとしているのである。期待していたソフトウェアが入手できなければ、競争力の向上ができず、競争に破れてしまうことも考えられる。

その結果、顧客はその役に立たないソフトウェアにたいする支払いを渋るのは確実である。もし、その支払いについて裁判で争うことになれば、その裁判費用の負担は開発企業にとって非常に大きなものになる。このことは開発企業にとって経営上の大きな負担になることは間違いない。

また、顧客がその代金の支払いを行なったとしても、開発されたソフトウェアが有効に利用されなければ、社会的には大きな損失でしかない。一度失った時間は二度と取り戻すことはできないのである。もし無駄なソフトウェアの開発に費やした時間や労力を、他の有効なソフトウェアの開発にふりむけることが可能なら、社会的な生産性の向上は非常に大きなものになる。

2.2.1.要件作業の過程の誤り

現在のソフトウェアの開発プロセスが、顧客の要件を満たしたソフトウェアの開発に成功していない理由は、要件定義からプログラミングに至るまでに、適切な要件作業が行なわれていないためである。あいまいさを含んだ要件定義を、厳密化していき、最終的に動作するプログラムに変換する過程こそがソフトウェア開発のプロセスである。プログラムを動作させるためには、全てのあいまいさは排除しなければならないため、この過程で要件定義書が持つあいまいさはどのような形であれすべて排除される。つまり、ソフトウェアの開発者は顧客と合意したあいまいさを多く含んだ要件文書を、最終的なコンピュータが理解できる厳密な命令へ変換しなければならないのである。

人間同士のコミュニケーションでは、多少の誤解が生じることがあっても、だいたいの意思の伝達が可能である。しかし、コンピュータにはどのような処理を要求しているのかを一命令ごとに正確に伝えなければならないのである。現在の開発プロセスでは、この厳密化の作業が適切に行なわれていないため、プログラムに多くの誤りが入り込むことになり、顧客の要件を満たしたソフトウェアの開発ができなくなっているのである。

そして適切な要件作業が行なわれない理由は、設計書に対して過大な評価が行なわれているためである。現在のソフトウェアの開発プロセスは、設計者が設計の対象となっているものについて、完全な知識を持っているのであれば、設計書にその実現方法完全に記述できると考えられていて、プログラミングの作業自体は、その完全な設計に従って忠実に行なうものであると考えられている。この設計書に対する過大評価によって、要件作業の過程で多くの誤りが発生し、本来の要件を満たすことができなくなるのである。

要件は設計書の文書や図形で完全に伝達できると考えられているが、これは明らかに誤りである。人間が持つ知識は言葉や文章や絵によって表わされるが、それらは人によってさまざまな意味に解釈されうるものである。この解釈の違いによって、伝えたいことが正確に伝達されないのである。

いくら設計書を厳密に記述したとしても、それが自然言語で記述されているのであれば、その記述に対する解釈は人によってさまざまである。そのため、その設計書の作成者が伝えたい要件が、プログラムを作成する技術者に正確に伝わるとは限らない。つまり、自然言語ではプログラミングで必要なレベルの厳密な要件の伝達は不可能なのである。設計書で実現できる厳密さのレベルとプログラムで要求される厳密さのレベルでは、大きな違いがある。そのため、その間のギャップを埋めるためにプログラム作成者による、多くの決定が行なわれることになる。そして、この決定の過程で設計書の解釈の違いによる多くの誤りが入り込むことになるのである。

2.2.2.誤りの排除

顧客の要求した要件を満たすソフトウェアを開発するためには、まず顧客の要件を正確に理解する必要がある。顧客の要件を開発者側が正確に捉らえるのである。これは絶対に必要なことである。次にその要件の実現方法を正確に設計書に記述する。要件を正確に設計書に反映させるためには、要件定義と設計は同じチームの同じメンバーによって行なう必要がある。これによって少なくとも顧客の要件が設計者によって誤解されることはなくなる。

そして、設計レベルからプログラミングのレベルへ要件を伝達する場合は、設計書だけではなく必ずコードで伝達する部分を含めるべきである。文章や図形だけではなくそれがどのようにプログラムで実現されるかが明確にわかるようにしないかぎり、その文章や図形はさまざまな解釈がなされ、要求したものが手に入る可能性は極めて低くなる。つまり、設計までの作業は紙の上だけで行なわざるをえないので、本格的なプログラミングのフェーズに移行する前にサンプルプログラムを作成すべきである。

サンプルプログラムを作成することによって、設計書とコードがどのように対応しているかをプログラマに伝えることが可能になる。また、サンプルプログラムがあれば、それをコピーすることによって、プログラミングの作業は非常に容易になるであろう。それに、設計者が自分の設計書をもとにプログラムを作成することは、自分の仕事に対するよいフィードバックになる。

設計書に対するの解釈の違いによって生じる誤りを最小限におさえるためには、解釈の違いが生じる機会をできるだけ少なくする必要がある。つまり、要件定義からプログラミング・テストまでの、開発プロセスの全工程を同じメンバーが中心になって行うのが、解釈の違いによる誤りが入り込む余地を少なくするための最も効果的な方法である。

2.3.開発効率

ソフトウェアの開発プロセスの開発効率は、顧客の支払い可能な価格で開発が可能で、なおかつ開発する側でも利益の出せる水準でなければならない。顧客にとってソフトウェアの価格があまり高いと、顧客自身が激しい競争にさらされている現状から考えて、なかなか開発に踏み切ることはできない。また、ソフトウェア開発企業にとっては、ソフトウェアの価格が開発にかかった経費を支払っても利益が出るものでなければ、ソフトウェアを開発する意味はない。ソフトウェア開発企業としても利益がでなければ、企業として存続できないのである。つまり、顧客が支払ってもよいと考えている価格でも利益が確保できる程度の経費で開発できなければならないのである。しかし、開発技術者を現在以上に酷使することによって、この問題を解決することはできない。なぜならば、現在でも開発技術者は十分に酷使されており、その状況はかなり悲惨である。この問題を解決するためには、開発プロセスの作業量を減らすことによって開発効率を向上させる以外にはないのである。

しかし、現在の開発プロセスはソフトウェア開発に最適な形に設計されておらず、設計プロセスの不必要な作業に多くの時間が割かれていたり、ソフトウェアの特徴を適切に利用していなかったりしている。そのため、不必要な作業が多く、開発期間の長期化、開発費の高騰化、開発技術者への過大な負担など問題が生じている。また、開発効率を向上させるためのさまざまな試みが行なわれているが、その試み自体が作業量をさらに増やす結果になっている。

2.3.1.不必要な作業

現在の開発プロセスの設計フェーズには不必要な作業があり、そのために作業量が非常に多くなっており、開発効率を低下させる大きな原因になっている。開発効率を上げるためには、この不必要な作業を無くし、作業の絶対量を減らすことが不可欠である。不必要な作業が多ければ、どうしても開発期間が長くなり、投入しなければならない資金が多くなる。これは開発企業にとっては大変な重荷である。

また、不必要な作業を行なうことによって、変更があった場合に飛躍的に作業量が増えてしまう。余計な作業を行なうことによって、何か変更があった場合、本来不必要な作業の結果に対する変更も行なわなければならなくなってしまうのである。作業量が減少すれば、その分変更に対応することが楽になり、変更が発生する可能性も低くなる。また、不必要な作業があることによって、本来必要な作業がおろそかになったり、手抜きが行なわれたりしている。これでは、品質の高いソフトウェアの開発は無理である。

さらに、開発技術者にとっても、不必要な作業を行なうことは非常にいらだたしいことである。開発技術者は既に超過労働の状態にあるので、作業量を減らしてやらないと、十分に品質の高いソフトウェアの開発はできない。多少の余裕がないと、質の高い仕事はできないものである。このようなことから考えても、ソフトウェアの開発プロセスに不必要な作業があってはならないのである。

そして、現在の開発プロセスにおける、プログラムの構造やロジックに対する詳細な設計は、完全に不必要な作業である。ごく単純な製品ならば完全な設計書を作成することも可能である。しかし、ソフトウェアは非常に複雑なものである。しかも、設計の段階ではそれがどのように動作するかを確認することはきない。そして、そのソフトウェアが動作するイメージを頭のなかで完全に組み立てることもできないものである。このようなものを、詳細なレベルまで完全に正確に設計することは不可能である。よって、詳細レベルの設計書を作成した場合、その設計書は非常に誤りの多いものになることは確実である。

つまり、プログラム内のルーチンの構造や機能の実現方法まで記述した設計書は、間違いだらけであり、もしプログラマがその設計書にしたがって、プログラムを作成しようとすれば大混乱に陥ることはまちがいない。さらに、メンテナンスという観点から考えてみても、実際にはプログラムと対応していないような設計書は、まぎらわしいだけでなんの役にも立たないことは確実である。このような作業は本来必要ないのである。この作業を取り除くことによって、そのために費やされていた莫大な時間や人員を減らすことが可能になる。そして、ソフトウェアの間発効率を大幅に改善することが可能になる。

2.3.2.長い開発期間

ソフトウェアの開発に非常に長い期間がかかることは、非常に大きな問題である。開発に長い期間が必要だとすれば、顧客にとってそのソフトウェアの完成時に、本当にそのソフトウェアを必要としているのかを判断するのが難しくなる。開発が終了したときには、既にそのソフトウェアは必要なくなっているかも知れないのである。

ソフトウェアの開発は、要件定義から完成まで長い期間がかかるので、その間の状況の変化によって、要件定義時の仕様が陳腐化する可能性がある。そのため、開発されるソフトウェアは、顧客にとって意味のあるタイミングに間に合うように、遅滞なく開発されなければならないのである。また、顧客にとってはより短い期間でソフトウェアが開発できるのであれば、ソフトウェアの利用できる分野が広がり、より広い範囲で業務の改善が期待できる。

また、開発企業にとっては、開発の遅れによって顧客がビジネスの機会を喪失するようなことがあれば、顧客との間に紛争が発生する可能性は高くなる。顧客との間に紛争が発生すれば、開発企業が開発に投下した資金の回収は極めて困難になる。それに、開発期間が長くなればなるほど、開発にかかる経費は増大し負担が重くなる。そして、その間になんらかの問題が発生する可能性が高くなり、開発を行なうことに対するリスクが大きくなる。もし、短い期間でソフトウェアが開発可能であれば、それだけビジネスの機会は広がり、投下した資金の回収が早くなり、財務面での健全化ができるのである。

さらに、開発技術者にとっても、一つのプロジェクトに長い期間がかかってしまうのでは、一定の期間で経験できるプロジェクトの数が少なくなってしまうため、経験の積み重ねによる技術力の向上ができない。また、一つのプロジェクトに長い期間拘束されるため、異なった種類のソフトウェアの開発に参加する機会が少なくなり、技術者にとって仕事が刺激のないものになってしまう。

2.3.3.開発効率向上のための努力

ソフトウェア開発の開発効率の向上するための作業は、組織や従業員に多大なコストを要求するようなものであってはならない。新しい方法論やツールの導入によって一時的にせよ開発効率が低下してはならないのである。通常、新しい方法論やツールの導入は、その導入時に技術者や開発組織に大きな負担をかけるばかりではなく、プロジェクト全体を破滅させかねないものである。

例えば、開発効率向上のための新しい開発効率の高い言語や開発ツールを導入した場合でも、一時的な開発効率の低下は避けることができない。新しいツールを導入した場合、過去のソフトウェア資産がつかえなくなることや、開発技術者がその新しいツールを使いこなせるようになるまで、開発効率が大幅に低下してしまうからである。それに、開発技術者がそれらの新しいツールの使い方を覚えるまでの費用を誰かが負担しなければならない。現在の状況ではこの費用を顧客に負担させることは無理である。また、現在のツールでは、柔軟性に乏しくユーザーが満足するようなソフトウェアの開発が困難であり、汎用性がないため開発技術者にとってもあまり魅力のないものである。このような理由から、開発技術者自身にこれらの費用を負担させることは困難である。さらに、これらの新しいツールはより多くのハードウェア資源を必要とする場合が多い。最近は、ハードウェアの価格が下がってきているとはいえ、無視できない問題である。

また、ソフトウェアの再利用は、開発効率の向上や品質の向上に大きな効果が期待できるものである。しかし、この再利用のための作業も、開発プロセスに大きな負担をかけるようなものであってはなってはならない。これは再利用を促進するための重要なことである。もし開発プロセスに大きな負担をかけるのであれば技術者にとっても開発企業にとっても、再利用を積極的に行なう気にはなれないからである。多くの技術者や開発企業が、再利用ついて意欲的であるにもかかわらず、実行に移されることが少ないのは、その再利用のために新たに多くの作業が生じてしまうためである。

再利用を行なうために、開発プロセスでの作業が増えてはならない理由は他にもある。再利用を行なうことはソフトウェアを開発することよりも重要なことではない。顧客から見れば、再利用を行なうことによって受ける利益は、ほとんどないのである。再利用のために開発が遅れたとすれば、顧客にとっては大変な迷惑である。再利用のために開発を遅れさせるもよいという理由はどこにもない。

少なくとも、顧客はその再利用の作業からは、直接利益を得ることはできないのである。もし顧客が再利用のために作業量が増加し、そのソフトウェアの開発に余分な費用がかかることに同意しているのでなければ、道義上の問題もある。開発プロセスで行なわれる作業は、その開発作業に対して最終的に代金を支払う顧客にとって意味があるものでなくてはいけない。そうでなければ、顧客の競争相手のために、その顧客が金を支払うことにもなりかねない。これでは、顧客の信頼を得ることはできない。これは別に、再利用を行なうべきではないといっているわけではない。再利用のための作業は、必要不可欠な開発プロセスの中に無理なく組み込まれるべきであるといいたいだけである。

それに、ソフトウェア全体の中で単独のルーチンとして再利用されるような、汎用性の高いルーチンが大量に存在するわけではない。確かに、そのソフトウェア内でも共通に利用されるような、共通ルーチンは再利用される可能性は高い。しかし、その他の同じソフトウェア内でも共通に利用されないようなルーチンが、単独で他のソフトウェアの開発で利用されるとは考えられない。

顧客から要求される要件がほとんど同じものであれば、ソフトウェアの一部を修正することによって、ソフトウェア全体の再利用を行なうことができる。また、プログラムが汎用性の高いものであれば、それも若干の修正を行なうことによって再利用可能である。つまり、ソフトウェア全体やプログラム全体がわずかな修正によって、その中に含まれるルーチンも再利用されることになる。しかし、それはソフトウェアやプログラムの一部としての利用であって、ルーチンそのものが意味を持って利用されるわけではない。

再利用を経済的に行なうためには、独立したブロック単位で行なうのが最善である。例えば、ソフトウェア全体で使われるような共通ルーチン、汎用性の高いプログラム、ソフトウェア全体などといった単位である。このような再利用であれば、開発プロセスに無理なく組み込むことができ、開発効率の向上が期待できる。しかし、ソフトウェア全体に対するルーチンレベルの再利用は、それを行なうために費やした労力に見合った効果を上げることはできない。再利用のために費やされる労力が削減できる労力を上まってしまうからである。もし、開発されるすべてのルーチンをルーチンそのものとして利用するために、開発プロセスに大きな負担をかけているのであれば、それは間違いである。

2.4.不十分な作業

設計に多くの時間が取られるため、あまり重要な作業とはみなされていないなどの理由により、本来必要な作業が十分行なわれていない。つまり、プログラミングやテスト、メンテナンスのための準備等が十分に行なわれていないのである。品質の高いソフトウェアや、完成後の運用費用が少ないソフトウェアを開発するためには、これらの作業を十分に行なう必要がある。

2.4.1.プログラミング・テスト

現在の開発プロセスでは、プログラミングやテストに十分な時間が割かれていないため、顧客に納品したあとで、大量のバグが発見されたり、ソフトウェアが動作しなっかったりという問題がおきている。このため、顧客は大きな損失を受けている。この問題を放置していたのでは、顧客から信用されなくなってしまう。どのような理由があっても、プログラミングやテストに必要な時間は、十分に割り当てるべきである。

また、プログラムの構造や実現方法について、設計書による拘束を受けているため、プログラム作成者は最適なプログラムの作成ができなくなっている。つまり、設計書にあわせるために、プログラムが不自然な形で実現されることになり、その結果、プログラムのサイズが不必要に大きくなったり、プログラムの実行速度が遅くなったりしているのである。テストされていないプログラム構造やロジックに拘束されていたのでは、このような結果を避けることができない。

実行速度の速い、サイズの小さいプログラムを作成するためには、プログラム作成者に、プログラムの実現方法についての自由を与える必要がある。その実現方法が最適であるかどうかは、実際にプログラムを動作させ、結果を確認しなければ知ることできない。そして結果が満足できるものでなければ、最適な結果を得るために実現方法を変更する必要があるのである。

2.4.2.メンテナンス

完成した後のメンテナンスのために十分な対策が取られていないため、メンテナンスに不必要に多くの費用がかかっている。いくらテストを厳重に行なったとしても、そのソフトウェアの使用中に発生するすべての状況を予測することはできないので、なんらかの問題が発生する可能性がある。また、ソフトウェアを新規に開発するのは、非常に金のかかることである。もし、メンテナンスによって対応できるようであれば、新規の開発をできるだけ避けて、メンテナンスによって対応することは、開発のリスクや費用から考えて魅力的な選択肢である。

社会の変化はますます高速化しており、このような変化に適切に対応して行くためには、開発したソフトウェアを随時メンテナンスして行くことが必要になってくる。そして、メンテナンスを効率的に行なうためには、そのソウトウェアがメンテナンスしやすく、作成されていなければならない。しかも、比較的簡単な方法でメンテナンスしやすくできるのである。

ソフトウェアがメンテナンスしやすいように作成されてあれば、新規にソフトウェアを開発しなくても、メンテナンスによって十分に対応できるようなものは、非常に多い。しかし、あらかじめメンテナンスしやすいようにしておかないと、メンテナンスの作業量は非常に大量のものとなり、新規の開発と変わらなくなってきてしまう。メンテナンスにかかる費用は莫大なものになる。また、メンテナンス用の情報が正確なものでなければ、間違いが生じやすくメンテナンスによって新たな問題が起こる可能性が高い。

メンテナンスを効率的行なうためには、ソースファイルそのものをメンテナンスしやすくするのが、最も簡単で費用のかからない方法である。そして、メンテナンスのしやすいソースファイルとは、その処理内容について正確に説明が行なわれているソースファイルである。ソースコードに完全に対応した説明を残すためには、ソースファイル中にコメントを記述するしかない。命令文のすぐ近くに、その処理の内容を記述するのである。コメントは処理の内容が、たいていの人間が明確にわかるように記述しなければならない。そして、ソースファイルに正確なコメントを効率的に入れることができるのは、そのプログラムを実際に作成した人だけである。それ以外の人がソースコードを見ながらコメントを入れたとしても、それが間違っている可能性が高いためあまり意味がない。

2.5.新しい開発プロセス

新しい開発プロセスは、次の五つのフェーズによって構成される。
(1).要件定義
(2).設計
(3).共通ルーチン・サンプルプログラムの作成
(4).プログラミング及びテスト
(5).品質保証テスト

2.5.1.要件定義

このフェーズは顧客との合意で始まり、顧客との合意によって終わる。顧客の要件を正確に理解するように、最大限の努力をしなければならない。そして、合意された要件について、顧客と認識が一致していなければならない。

このフェーズで作成される要件定義書は顧客が理解できる文章や図形で記述される。要件定義書は、必ず顧客が理解できる文章や図形で記述されなければならない。そうでなければ顧客との要件についての合意はまったく無意味である。なぜならその場合、顧客と開発担当者の認識は確実に違っているからである。

また、この顧客との合意を行なう前に、要件定義書をにたいして、ブラックボックス・テストを行ない要件の記述に誤りがないかをチェックする。このフェーズで正確な要件の定義ができなければ、これ以後のフェーズは全て無意味である。

2.5.2.設計

このフェーズは顧客とコンピュータとの中間段階である。このフェーズで作成した文章や図形は、顧客にもコンピュータにも理解できない。すべての作業は紙の上で行なわれる。

このフェーズで要求される厳密さのレベルは、作成された文章や図形によってプログラマが、プログラムを作成でき、作成されたプログラムがソフトウェアの一部として完全に動作するレベルである。

このフェーズで作成するものは、ソフトウェア全体で共通に使用するものについての設計書であり、次のようなものである。
```
   ソフトウェア構造図  ファイル設計書  データベース設計書 
   ネットワーク構成図  ユーザーインタフェース設計書
   データフロー図      プロセスフロー図
   共通ルーチン設計書  プログラム設計書
```
プログラム設計書には、ルーチンの構造やロジックを記述する必要はない。プログラム設計書に記述されるべきものは、ファイルやデータベースに対する入出力とそのプログラムの機能とプログラムに課せられる制約のみ記述されるべきである。間違っても、ステップレベルまで記述した設計書やそれに類するものを作成してはならない。そんなものは何の役にも立たないばかりで、ただ単に作業量が増えるだけである。それに、プログラムのルーチン構造やロジックはプログラムを作成する人間が考えてこそ意味があるものである。

プログラム設計書に記述された入出力データや機能、制約などに誤りがあってはならない。誤りはできるだけ取り除くように努力しなければならない。設計書として要求されるものは、プログラマがプログラミングを行なうために、必要な情報が正確に記述されたものである。つまり、共通ルーチンのインターフェースと仕様、ファイルやデータベースのレイアウト、入出力されるデータ、ユーザインターフェースのレイアウト、プログラムの機能・制約などの記述である。

このフェーズでも設計書の正確性をチェックするために、設計の最終段階で設計書に対してブラックボックス・テストを行なう。

2.5.3.共通ルーチン・サンプルプログラムの作成

プログラミングのフェーズに移行する前に、共通ルーチンの作成、サンプルプログラムの作成を行なう。サンプルプログラムを作成することによって、設計書とプログラムとの対応関係を明確化することができ、プログラマに対して要件を正確に伝達することができる。また、設計者が自分の設計についてのフィードバックを得ることが出来る。

共通ルーチンはこのフェーズでのみ作成し、プログラミングのフェーズでは行なわない。プログラミングの最中に共通ルーチンを作成すると、テストしたプログラムに対しても変更が発生し、作業量がかえって増えてしまい。共通化するメリットがなくなってしまう。

このフェーズの作業は、設計作業を行なったプロジェクトの中核メンバーによって行なわれる。特にサンプルプログラムは設計を行なった技術者が担当するべきである。また、このフェーズでプログラミングの際に発生する問題は、できるだけ解決しておかなければならない。

2.5.4.プログラミング・テスト

このフェーズですべての要件は完全に厳密化される。設計書をもとにプログラマが最終的にコンピュータに理解できるように、厳密にコード化されるのである。このフェーズでは設計に参加しなかったプログラマが開発に参加することもあるため、特に注意すべきである。要件の誤りを避けるため、できるだけ多くのプログラムをプロジェクトの中核メンバーが作成すべきである。

プログラミングとテストは分けることの出来ない一連のプロセスである。通常、プログラムはテストを行ないながらプログラミングを行ない作成される。先にプログラミングを行ない、次のフェーズとしてテストを行なうのではない。プログラミングとテストは交互に行なわれるのである。

プログラミングは、トップダウンでルーチンごとにコード化を行ないながらテストしていくのが望ましい。また、プログラミングの前段階として、だいたいのプログラムの構造や処理の流れを考えるための、ラフスケッチを行なう。

プログラミングの最終段階ではメンテナンスに備えて、ソースファイルにはそのプログラムの構造や処理内容が、プログラムの作成者以外にもわかるようにコメントを記述する。また、プログラムが作成者以外の技術者にとってもわかりやすく記述されるように、いくつかのコーディング規則を設けるべきである。

このフェーズで作成されるものは、設計書の要件を満たした完全に動作するプログラムとメンテナンス用にコメントが記述されたソースファイルである。

2.5.5.品質保証テスト

このフェーズでは開発されたソフトウェアが、顧客の要件を満たしているかどうかについて開発者以外の技術者によるチェックが行なわれる。この品質保証テストが終了してから顧客にソフトウェアが引き渡される。

この作業は品質管理部門の技術者が中心となり、開発プロジェクトの中核メンバーの協力によって行なわれる。この作業が終了したあとは、顧客にソフトウェアがわたるため、作業は厳重に行なわれる必要がある。この作業が終了したあとでソフトウェアに問題が発見された場合は、品質管理部門でその対応を行なう。
開発組織
3.1.現在のプロジェクト・チームの問題

現在のプロジェクト・チームは、階層的な組織においていわば例外的に発生する開発作業や問題の解決を行なうためのものである。つまり、階層型の組織をその基礎とし、その中に一時的に組織されるものである。そのため、階層型の組織における問題をそのまま引き継いでいる。例えば、さまざまな部門の人間によってプロジェクト・チームが構成されるため、その部門間の対立がプロジェクト・チーム内に持ち込まれたり、それぞれのメンバーが、プロジェクト・チームの一員である以前に、階層型組織の特定の部門に属していることになるため、プロジェクトの利益よりも、自分が属している部門の利益を優先させたりすることなどである。そのほかにも次のような問題がある。

プロジェクト・チームは一時的なものと考えられているため、プロジェクト・チームの位置づけや役割についての、組織内での明確なコンセンサスがなく。そのため、プロジェクトのリーダーの権限と、プロジェクトに参加しているメンバーの本来の上司の権限の優先順位や、プロジェクト・リーダーの各メンバーに対する命令権が不明確である。そして、プロジェクトの各メンバーの立場も特に明確になっているわけではないため、なにをやるにしても不自由である。

また、プロジェクト・チーム内のメンバー間の関係も明確に決まっていないため、各メンバーはプロジェクトが始まってから、お互いの関係を新たに構築していかなければならない。プロジェクトのメンバーがお互いに知り合いであれば、この関係の構築はうまくいく可能性があるが、そうでなければたいていの場合はなんらかの問題を抱えることになる。このメンバー間の関係がうまく構築されなければ、そのプロジェクトが成功する可能性はほとんどない。

そして、プロジェクト・リーダー以外のメンバーが、そのプロジェクトの結果によって評価されるわけではないので、プロジェクトを成功させることにそれほど熱意を持つことはない。その理由は、プロジェクトのメンバーに対する評価は、本来所属する部門で行なわれるからである。しかし、プロジェクトが失敗すればプロジェクト・リーダーはその責任を問われることになる。このため、メンバーの本来の上司がプロジェクト・リーダーのライバルであれば、プロジェクトがそのメンバーによって妨害される可能性がないとはいえない。

それに、現在のプロジェクト・チームは単に人を集めただけなので、そのプロジェクトを遂行するだけの能力が、そのプロジェクト・チームに備わっているとは限らない。むしろ、備わっていないほうが普通である。それに、プロジェクト・チームは公式の組織ではないため、プロジェクトの遂行に必要な開発資源を確保するための、公式の規定がなく開発資源の確保がうまくいかないことも多い。

このように大量産製品の開発プロジェクトにおいても、さまざまな問題があるのである。このプロジェクト・チームを、そのままの形でソフトウェアの開発に適用した場合、問題はさらに複雑になる。業務の中心が開発作業であるソフトウェア開発企業に、階層型の組織を適用する理由もなければ必要性もないのに、多くのソフトウェア開発企業でこの方式が採用されている。これではまともにソフトウェアの開発ができなくても別に不思議なことではない。

3.2.人間的な要因

現状では、人間的な要因によってソフトウェアの開発効率が受ける影響が大きいため、正確な見積りや品質その他の計測データはあまり意味をなさない。そのため、見積りが技術者の勘で行なわれることが多い。しかし、これではその見積りが当たる可能性は非常に低いため大きな問題がある。

見積りを正確に行なうことは、非常に重要である。この見積りによって投入する人員の決定やス開発ケジュールの作成、価格の交渉が行なわれるためである。これらは開発企業の経営に大きな影響を与えるものである。見積りが不正確であれば、誰かがそのつけを払わなければならないのである。

現在、見積りが正確に行なわれない最大の要因は、ソフトウェアの開発規模や期間が、そのプロジェクトのメンバーの関係に大きく影響を受けるためである。つまり、ソフトウェア開発の規模や期間、コスト等はこのプロジェクト内のメンバー間の関係によって大きく変化し、ソフトウェア開発を計測するための様々なデータはあまり意味をなさないのである。そのため、現状のままでは要件を見ただけでは開発規模や開発期間を正確に見積もることは不可能である。見積りを正確に行なうためには、この人間的な要因による影響をなくす必要がある。

見積りを正確に行なうための前提条件は、ソフトウェアが人間的な要因による影響を受けずに、ソフトウェアが開発可能であるということである。人間的な要因を取り除くことによって、はじめてさまざまな計測値は意味を持ち、そのデータをもとに正確な見積りを行なうことが可能になる。

3.2.1.プロジェクト内の人間関係

現在のプロジェクト・チームでは、プロジェクト内でのメンバー間の関係が確立されていないため、プロジェクトを編成するたびに、メンバー間の関係を確立しなければならない。

この関係の確立は必ずしもうまくいくとは限らない。これがうまく行かない場合は、メンバー間でのチームワークやコミュニケーションは期待できなくなる。そして、関係の確立がうまくいくかどうかは、プロジェクトのリーダーやメンバーの能力や力関係によって決まってしまうため、偶然うまくいく場合以外は大きな問題を抱えることになる。また、プロジェクトのリーダーにとってもプロジェクトに参加する各メンバーにとっても、他のメンバーがどのような個性の人間かがわからないため、関係の確立はなかなか進行しない。

プロジェクト毎にメンバー間の関係を確立を行なってたのでは、プロジェクトの規模が拡大すればその確立にかかる期間は長くなり、関係の確立に成功する可能性は非常に低くなる。その結果、プロジェクトごとのオーバーヘッドが増大し、プロジェクトが失敗する可能性が増大する。このため、成功するのはほとんど小規模なプロジェクトだけということになる。

また、メンバー間の関係の確立がうまくいった場合でも、プロジェクトのたびに発生するオーバーヘッドが大きく、プロジェクトの立ち上がりが遅くれてしまう。大量生産品の開発であればこのオーバーヘッドは無視できるが、ソフトウェアの開発では、開発作業が中心であるため無視することはできない。そして、この関係の確立はプロジェクトの初期に行なわれるため、要件定義の作業がおろそかになってしまい、設計以降の作業が行き詰まってしまう。

3.2.2.効率的なプロジェクト・チーム

現状では効率的なプロジェクト・チームを作り出すためには、メンバーが互いに知り合いで、その間には安定した関係が確立されている必要がある。しかし、これでは開発効率の高いプロジェクト・チームを作り出すことに長い期間がかかるだけでなく、ごく少数のプロジェクトにしか適用することができない。それでは、品質の高いソフトウェアを大量に開発することはできない。

ソフトウェア産業が成長するためには、市場規模の拡大が不可欠である。そしてソフトウェアの市場規模を拡大して行くためには、品質の高いソフトウェアを低い価格で顧客に提供する以前に、品質の高いソフトウェアを大量に開発できなければならない。品質の高いソフトウェアを大量に開発できないのであれば、いくら需要があったとしても、ソフトウェア市場の規模拡大は無理である。そして、品質の高いソフトウェアを大量に開発するためには、一般的な労働市場で採用することができる技術者によって構成され、人間的な要因によって問題が起きない、効率的に機能する開発組織を編成する必要がある。

これは不可能なことではない。開発組織内のメンバー間の関係をよく検討し、その関係付けを慎重に行なうことで、開発組織内の個々の技術者が、互いにその個性や文化的背景を知らなくてもソフトウェア開発作業を行なううえで要求される程度のチームワークやコミュニケーションは引き出せるはずである。ソフトウェア開発のために開発組織に要求されるチームワークやコミュニケーションがそれほど高いものが要求されるとは考えられない。

もし、偶然構築されたプロジェクト・チームだけが、開発に必要なチームワークやコミュニケーションを得ることができるのであれば、その希少性によって、開発にかかる人件費は莫大なものになってしまう。これは、ソフトウェアの開発に携わる多くの人間にとって不幸なことである。ソフトウェアの開発ではその経費の多くの割合が、人件費で占められており、ある特定の技術者でなければ、品質の高いソフトウェアを開発できないのであれば、その特定の技術者に支払われる報酬は非常に高くなるであろうが、その他の技術者は、開発するソフトウェアの品質の低さによって、その報酬は非常に低い水準に留まることになる。

3.2.3.規則による人間関係の安定化

プロジェクトを編成するたびに、そのプロジェクト内で関係を確立する必要はないはずである。たしかに、そのプロジェクトのメンバーによって、チーム内の力関係は微妙に変わってくる。しかし、あらかじめプロジェクトのメンバーとして期待される行動を明示的に規定することによって、開発プロセスで要求される関係を作り出し、プロジェクト発足後に関係を確立する必要性をなくすことができるはずである。つまり、プロジェクトの各メンバーが、あらかじめ決められた規則を守るようにすることによって、開発組織に要求されるチームワークやコミュニケーションを実現するのである。

これらの規則によって、これまでのようにプロジェクト内で、良好な人間関係が築かれるようになるまで待つ必要はなくなり、プロジェクトの発足時から十分なチームワークやコミュニケーションが期待できる。このことは開発プロセスの重要な部分が初期の段階で行なわれることから考えて重要なことである。また、技術者がプロジェクトが変わった場合でも、規則にもとづいた周囲との関係は変化しないため、他のメンバーとの関係の確立に多くの労力をさく必要がなくなり、各メンバーは開発作業に専念することができる。

このような規則がないかぎり、幸運な場合でもこの寄せ集めの集団が自主的にチーム内の新しい人間関係を築くまで、チームは有効には機能しない。最悪の場合、メンバー間の対立によりチームは空中分解してしまう。

3.3.役割・権限・責任

現在のプロジェクト・チームでは、メンバーに要求される役割や権限・責任が明示的に決まっているわけではないため、多くのメンバーは何をやればよいかわからないし、どのような権限をもち、どのような責任を負わなければならないかもわからない。また、役割がプロジェクト毎に変わってしまい。その結果、プロジェクトに参加するメンバーにとって、分担する役割が参加するプロジェクトごとに変わるため、普段どのような技術や知識を得ておけばよいかがわからず、プロジェクトが開始されて役割分担が決まってから、そのプロジェクトに必要な情報を収集しなければならないため、自分の持っている知識を有効に利用することができない。

また、役割が不明確であるために、プロジェクト・リーダーに過度の負担がかかることになる。このため、プロジェクト・リーダーは、自分かつぶれてしまうか本来行なわなければならない仕事をやらないかのどちらかを選択しなければならなくなってしまう。このようなことから考えて、たとえプロジェクト・チームであっても、プロジェクト内でのメンバーの役割やそれにともなう権限と責任は明確にする必要がある。

つまり、プロジェクト内で各メンバーは、各自の得意な専門分野に応じて、特定の専門分野の役割をメンバーの個性や能力に応じて割り当てられる。そのプロジェクト内で公式の果たすべき役割を明示され、その役割にともなう権限と責任を持つことになるのである。

そして、役割の明確化によって、次のような効果が期待できる。人には様々な得意な分野があるので、その得意分野に合った役割を与えることによって、メンバーに心理的な充足感を与えることができる。また、プロジェクトが変わっても担当する分野が変わらないため、一貫して特定の分野について専門的な知識を増やすことができる。これによって技術者は取得した知識が利用される効率を高めることができる。そして、権限や責任が明確になっていいるため問題が発生した場合の責任を、本来責任を負うべき人間が負わなければならなくなるため、問題の処理が迅速になることなどである。

3.3.1.プロジェクト内の情報の利用

プロジェクト内の情報を有効に利用するためには、役割の明確化が必要である。つまり、プロジェクトの他のメンバーが知り合いでない場合は、そのメンバーがどんな情報を持っているかがわからないため、聞けば簡単にわかるようなことも、調査するために、多くの時間や労力を割かなければならなくなる。だが、誰がどんな情報を持っているかがわからなければ、情報の交換は無理である。つまり、たとえチーム全体として必要な情報は十分に持っていたとしても、その情報が十分に利用されないことになってしまう。

また、他のメンバーがどんな人間かがわからなければ、そのメンバーから情報を提供された場合でも、その情報が正確なものかどうかわからないし、他のメンバーに対して自分の提供する情報が正確なものであるということを示すことができない。受け手にとってその情報が正確なものかどうかがわからなければ、その情報は無視されることも考えられる。

つまり、情報が伝達された情報が有効に利用されるためには、その情報が信頼できるものであるという根拠が必要である。その根拠を与えるためには、情報の発信者の権威づけと、情報が間違っている場合は、情報の発信者に責任を負うように義務づける必要がある。権威づけを行なわない場合は、情報はたとえ正確に伝達されたとしても、受け手によってその情報が利用されない可能性がある。また、発信者に責任を負わせない場合は、不正確な情報が発信される可能性が高くなってしまう。

しかし、役割が明確になっていれば、その役割に対応した情報を持っていることが期待できるため、誰がどんな情報を持っているかが明確になる。そして、権限や責任が明確になっているため、情報は信頼性が高く、受け手によって利用される可能性が高くなるのである。

3.4.柔軟な開発組織

現在のプロジェクト・チームでは、大規模なソフトウェアの開発ができない。中小規模のソフトウェアの開発は比較的容易であり、従来型のプロジェクト・チームであってもチーム内の関係がうまくいけば、十分に開発可能である。しかし、問題は大規模なソフトウェアの開発である。ある一定のレベルを超えた規模のソフトウェアでは、効率的なプロジェクト・チームの編成が不可能になるのである。その理由は、チームの規模が大規模なものになればなるほどプロジェクト・チーム内のコミュニケーションやチームワークを維持することは困難になり、そのプロジェクト内で意志決定を行なうことが事実上不可能になるからである。プロジェクト内に階層型の組織を作るのも一つの案であるが、これでは情報の流れが滞りかえって混乱してしまう可能性が高い。

本来ソフトウェアの開発組織は、あらゆる規模・種類のソフトウェアの開発に適用できる柔軟性を備えていなければならないはずである。そうでなければ、プロジェクト毎に規模や種類が変化するソフトウェアを、効率的に開発することはできない。

ソフトウェアの開発では、ソフトウェアごとにその規模や種類が著しく変化するため、この変化に無駄なく迅速に対応できることは不可欠である。これができなければソフトウェアの開発組織としては不十分である。つまり、ソフトウェアの開発組織はソフトウェアであれば規模の小さいものでも非常に大規模なものであっても、どのような種類のソフトウェアであっても対応できるものでなくてはならない。中小規模のソフトウェアしか開発できないのでは、大規模な組織に対応したソフトウェアの開発ができず、その顧客は限られたものになる。

また、ソフトウェアの開発に熱心な企業は、比較的大企業であり、大企業では大規模なソフトウェアに対する強い潜在的なニーズがある。ソフトウェア開発企業にとっては大規模なソフトウェアを効率的に開発できることは、営業上有利である。

3.5.プロジェクト・ユニット

プロジェクト・ユニットはプロジェクト・チームの欠点を改良したものであり、開発組織の基本となるものである。新しい開発組織では、開発するソフトウェアの種類に適した専門技術者から構成されるプロジェクト・ユニットのモデルを作成し、そのモデルに基づいてプロジェクトを編成する。単一の標準プロジェクト・ユニットを編成できるだけの規模ではない場合は、一人の開発技術者が複数の役割を担当する。

プロジェクト・ユニットを構成する開発技術者は、ソフトウェア開発の全プロセスの作業を行なうための基本的な知識や技能をもち、さらに特定の専門分野についての専門的な知識を持っていなければならない。開発プロセスの全体に参加し責任を負う。その作業内容は、一般的な開発作業と担当する分野で中心的な役割を果たすことである。これらの技術者は、担当する専門分野について専門的な知識を持っていることを証明する必要がある。

また、開発プロセスで発生する問題は極めて多いので、それらの問題を適切に解決できなければ、そのプロジェクト・ユニットは効率的に機能しない。プロジェクト・ユニット内で問題を適切に解決するためには、それらを解決するための権限をプロジェクト・ユニットに委譲する必要ある。つまり、その状況下でプロジェクト・ユニットのリーダーが最善と判断した処置を取ることを認めることによって、問題が深刻化する前に、プロジェクト・ユニット内で自主的に問題を解決できるようにするのである。

3.5.1.プロジェクト・ユニットの編成モデル

標準的なプロジェクト・ユニットとして次のようなものが考えられる。プロジェクト・ユニットの各技術者は専門分野を担当するだけでなく、開発作業全体を協力して行なう。また、プログラミングのフェーズでプログラマを加える場合もある。

(1).プロジェクト管理
- 開発計画を作成する。
- 開発資源を調達する。
- プロジェクトの進捗管理を行なう。
- プロジェクト管理部門とメンバーの連絡を行なう。
- 開発資源の調達に関する権限を持ち責任を負う。
(2).データベース技術
- データベース関連の技術情報の収集や配布を行なう。
- データベースに関する優先的な決定権を持つ。
- データベース関連の技術的な問題の解決に責任を負う。
(3).ネットワーク技術
- ネットワーク関連の技術情報の収集や配布を行なう。
- ネットワークに関する優先的な決定権を持つ。
- ネットワーク関連の技術的な問題の解決に責任を負う。
(4).ユーザーインタフェース技術
- ユーザーインタフェース技術情報の収集や配布を行なう。
- ユーザーインタフェースに関する優先的な決定権を持つ。
- ユーザーインタフェース関連の技術的な問題の解決に責任を負う。
(5).プログラミング技術
- 開発環境を整備する。
- 共通ルーチンの設計と作成を行なう。
- 特殊なアルゴリズムのプログラム作成を行なう。
- ソフトウェアの実現方法についての優先的な決定権を持ち責任を負う。
- サンプルプログラム作成の支援。
(6).業務知識
- ソフトウェアの開発対象となる業務知識の収集や配布を行なう。
- 業務に関する決定についての優先的な決定権を持つ。
- 業務関連の問題の解決に責任を負う。
(7).品質管理
- ソフトウェアの品質管理や評価を中心になって行なう。
- テスト関連の技術の収集や配布を行なう。
- テスト方法ついての優先的な決定権を持つ。
- ソフトウェアの品質に責任を負う。
(8).顧客情報
- 顧客の情報についての収集や配布を行なう。
- 営業部門に対して技術的な情報を提供する。
(9).リーダー
- 上記の技術者の一人がそのユニットのリーダーを兼ねる。
- プロジェクト・ユニット内の諸問題を解決する。
- 該当する分野がないものについて優先的な決定権を持つ。
- プロジェクト全体の結果に責任を負う。
3.5.2.運営規則

プロジェクト・ユニットの運営を行なうための規則である。各メンバーは、これらの規則に従って開発作業を行なう。

規則例
- 各専門分野の担当者は、その担当する分野における問題の解決や機能の実現方法について優先的な権限を持つ。
- 該当する分野があいまいな分野については、ユニット・リーダーがその問題の担当者を決定する。
- 各分野の担当者はその担当する分野についての支援を、プロジェクトの他のメンバーから要請された場合はこれを拒否できない。
- 他のメンバーにとって有用な情報や知識を持っている場合は、その情報や知識をそのメンバーに提供しなければならない。
- あるメンバーが提供した情報に誤りがある場合は、そのメンバーはその情報を提供した相手全員に対して、その誤りを訂正しなければならない。
- 変更が発生した場合は、その変更によって影響を受けることになる他のメンバー全員に、その変更内容を伝えなければならない。
- ある機能を実現する方法が何通りもある場合は、最も経費のかからない方法でその機能を実現しなければならない。
- 進捗会議は特別な事情がある場合を除き週一回の割合で必ず行ない、出席者は進捗状況及び開発作業上問題になっている事柄を報告する。
- 進捗会議で進捗上問題となる事柄があった場合、次の進捗会議までにその問題は解決されていなければならない。
- プロジェクト内で、一時間を超えるような長時間の会議を行なう場合は、リーダーの承認を必要とし、議事録を作成しなければならない。
- 特定のフェーズから次のフェーズに移行する場合は、プロジェクトのメンバー全員が出席する会議で移行の決定を行なう。
- プロジェクト終了した時点で、そのプロジェクトで良かった点と悪かった点について各プロジェクト・メンバーから意見を収集する。
- 特定のプロジェクトでだけ必要となる規則は、プロジェクト・ユニット発足時に規定しプロジェクトが終了した時点で無効とする。
3.5.3.編成規則

プロジェクト・ユニットの編成及び解体を行なうための規則である。

規則例
- プロジェクト・ユニットの編成はプロジェクト管理部門が行なう。
- 品質管理部門がソフトウェアの完成を認めた段階でプロジェクト・ユニットはプロジェクト管理部門によって解体される。
- プロジェクト・ユニットはできるだけ少数の人員で編成を行なう。
- リーダーは専門技術者の中の一人が兼務する。
- プロジェクト・ユニットのリーダーは、暫定的にプロジェクト管理部門が決めて、一定の期間後にメンバーの投票によって正式に決定する。
3.6.プロジェクト組織

単独のプロジェクト・ユニットでは対応できないような大規模プロジェクトの場合には、プロジェクト・ユニットと同様な構成を持ち、開発するソフトウェアの種類に対応した専門技術者で編成された、複数のユニットから構成されるプロジェクト組織を構築する。さらに、ユニット内の専門技術者ごとに情報交換や技術的な調整を行なうための協議会を編成する、この協議会は議長を選出し、定期的に会合を開催する。これによって、プロジェクト全体の一貫性の維持や、開発プロセスでの情報の共有を行なう。

この方式でかなりの規模のソフトウェアの開発が可能になるが、この組織も無限に拡大できるわけではない。おそらく、協議会の規模が協議会として機能する規模を超えない程度までである。それ以上の規模になった場合は、この協議会をさらに組織化する必要が出てくる。例えば、協議会内に互いに関係の深い数人からなるグループを作成し、通常の情報交換はこのグループ内で行ない。プロジェクト全体に係わる事柄を調整する場合は、それぞれのグループの代表者で構成され協議委員会で行なうといったものである。

プロジェクトの編成はプロジェクト管理部門が行ない、暫定的なリーダーもプロジェクト管理部門がプロジェクトのメンバーの経歴をもとに決定する。しかし、ユニット内のメンバーがお互いについての知識を十分に獲得した段階で、ユニット内のメンバーの投票によってそのユニットの正式なリーダーを決定する。これは、任命されたリーダーと実質的なリーダーとの二重権力構造の発生を防ぎ、ユニット内で最もリーダーに適した人物をリーダーにするためである。これらの手続きは、組織内で公式な手続きとして認められたものでなければならない。

特定の作業フェーズでのみ必要になる技術者は、そのフェーズでのみプロジェクトに参加する。例えばプログラミングのフェーズでのみ必要とされるような、プログラマなどである。その結果、プログラミングフェーズの作業量や作業内容に応じてプロジェクト組織の規模が拡大したり縮小したりする。

これらのプロジェクト組織の構築やその運営のための手続きは、全て公式な手続きとして規則によって、あらかじめ定められていなければならない。

3.6.1.プロジェクト組織の規則

プロジェクト組織の構築や運営を行なうための規則である。

規則例
- 各ユニットのリーダーから構成される協議会によって、プロジェクト全体の方針が決定される。
- 各ユニットの専門技術者は専門分野ごとに協議会を構成する。この協議会によって情報交換や調整を行なう。
周辺組織
4.1.現在の組織構造の問題

社会的な変化が早くなったため、これまでと比較して格段に高速な情報の処理が要求されるようになってきている。変化の速度が早くなればなるほど、その変化に対応するため、組織内での高速で大量の情報処理が必要になるのである。しかし、これまでの階層型の組織構成では、高速な情報の処理の必要はなかったため、高速な情報処理を行なうための公式の仕組みは存在しない。現在の階層型の組織では、階層を利用した上下方向にしか情報の流れがなく、組織内の情報を十分に活用することはできないのである。そのため、組織内の業務にさまざまな問題が生じている。

また、顧客に対しても開発組織内の情報を正確に提供するように求められるようになってきているが、階層型の組織においては、部門間での情報交換の公式の仕組みが不十分であるため、開発組織と営業部門の間で十分な情報交換が行なわれなかった。しかも、開発組織の技術者と営業部員のどちらが顧客との交渉を行なうのかがはっきりしていないため、顧客に対する対応が一貫していなかった。そのため、開発組織と顧客のとの間で正確な情報をリアルタイムに交換を行なうことができない。これまでは、それでもたいして問題なかったが、現在では最新の正確な情報が求められている。

そして、現在のプロジェクト制では、開発の終了でプロジェクトが解体されてしまうため、顧客に対して開発したソフトウェアの一貫したサービスができないにもかかわらず、この問題について十分な配慮がなされていない。

4.2.不適切なプロジェクト管理

現在多くの企業で採用されている階層型の組織構造は、ソフトウェアの開発を行なうには不適切である。現在の組織構造は、大量生産品のための組織構造であり、開発型のソフトウェアのためのものではない。このため、管理のための権限や責任の所在てが不明確になっている。権限や責任の割り当てが不明確なため、組織内のあらゆる場所で、権限をめぐる紛争が発生し、無責任な態度がはびこっている。これでは何をやるにしても無理があり、効果的な管理を行なうことはできない。その結果、現在のソフトウェア開発企業の組織は、開発を行なう上での必要な資源を必要な時に十分に供給することができなくなっている。開発資源が必要のないときに確保されていたり、必要なときになかったりするのである。

効率的にソフトウェアを開発するためには、プロジェクトで必要な開発資源は、必要なタイミングでリアルタイムで供給される必要がある。開発資源の供給不足や供給の遅れがボトルネックになることによってによって、開発作業が遅れるようなことがあればその損失は非常に大きなものになる。

4.3.非公式人脈ネットワーク

現在多くの組織は、組織内に存在する非公式の人脈ネットワークに依存する情報交換システムしかない。開発に役に立つ情報を得るための、公式の情報交換の仕組みが存在しないのである。そのため、部門間やプロジェクト間で情報の交換が十分に行なわれず、日常業務にさまざまな障害が発生している。このような状況下では非公式の人脈情報ネットワークを持っている人間のみが、十分な情報を得ることが出来る。これでは、情報は特定のネットワークに属する人物に集中することになり不公平である。新参者や外部の人間には不利なのである。また、このような非公式の人脈ネットワークを構成して情報の交換を行ない、情報を活用している人間は企業組織内の一部でしかないため、組織内の情報を十分に活用しているとは言えない。組織内に存在する情報は、その信頼性、情報を取得するためにかかる時間や費用、情報の完全性から考えて、取得コストが低く質の高い情報である。このような情報は最大限利用すべきである。

組織内のすべての情報を有効に活用するためには、企業組織内を情報が流れるように設計し、組織内のどの人間にとっても組織内の情報の流れる経路が一目瞭然にわかるようにする必要がある。つまり、公式の情報交換ネットワークを構築する必要があるのである。

これによって、組織内の人間にとってどこにどのような情報が存在するかが明確になるため、必要な情報を容易に入手することが可能になるのである。また、外部からも情報を取得できるようにする必要もある。組織内の情報だけでは十分な情報が得られないことも多いからである。このようにすれば、組織内の人間は計画的に組織内の情報ネットワークに接続されているため、そのネットワークを通して、その情報が外部のものであるかを意識せずに、必要な情報をすぐに入手できるようになる。

しかし現状では、外部の情報を専門的に収集するための部門がないため、有用な外部の情報を効率的に取得することが出来ない。現状では開発技術者による、個人的な努力だけがたよりである。個人ごとにばらばらに情報を収集するのでは、作業が重複し無駄が多く効率的とはいえない。また、ソフトウェア開発時に必要となる情報はますます増えてきており、開発技術者の個人的な努力では、必要な情報を十分に収集することは事実上不可能になってきている。やはり、外部の情報を効率的に収集するためには、情報収集についての専門的な知識をもつ専門家が行なうのが効率的である。これによって、開発技術者は開発に専念することができる。

4.4.顧客との情報交換

顧客との間に十分な情報交換がないため、顧客のニーズを正確に把握したり、開発組織内の開発力を、営業上の利点とすることができない。この結果、顧客の要件を正確に理解することができなかったり、顧客を獲得できなかったりしている。顧客のニーズを満たすためには、開発者そのニーズについての情報を正確に把握しておく必要があり、営業活動を有利に進めるためには、どの程度のソフトウェアがどの程度の費用で開発できるのかを顧客に知らせる必要があるのである。

しかし、開発担当者と顧客が常時直接の接触を保つことはできない。開発担当者はソフトウェアの開発を行なうことが中心であり、そこまでは出来ないのである。そのため、顧客のニーズを的確に把握し、企業組織の開発力を営業力に結び付けるためには、開発組織と顧客との間に、開発担当者と顧客の間を仲介する情報交換のための部門が必要である。開発担当者はこの部門を通して顧客との間の情報の交換を行なう。そして、正確な情報交換を行なうためには、この部門との間の連絡を緊密にする必要がある。しかし、現在のソフトウェア開発企業では、そのための部門である営業部門との連係がうまくいっておらず。営業部門からの顧客についての情報の提供も不足しているし、営業部門に対する技術情報の提供も不十分である。

4.5.不十分な顧客サービス

一つは、開発したソフトウェアに対する第三者的な品質管理部門がないことである。開発当事者のチェックだけではどうしてもチェックが甘くなりがちなので、第三者的な立場の人間によるチェックも必要である。これによって、開発当事者では気がつかないような誤りをチェックすることが出来る。開発した技術者が考えているように、顧客がそのソフトウェアを使うとは限らないのであるから、このことは運用段階でのトラブルをあらかじめ防止するという意味で重要である。また、このような品質管理を行なっているということで、顧客の信頼感を高めることが出来る。

もう一つは、完成後のソフトウェアのサポート体制が不十分であることである。プロジェクトが終了した段階で、プロジェクトは解体されそのプロジェクトの参加していた技術者は、他のプロジェクトに入ることになるため、完成後のソフトウェアに問題があったとしても、その問題に迅速に対応することはできないし、対応を行なう開発技術者としても新しいプロジェクトに集中することができない。そして最悪の場合は、ソフトウェアを開発した技術者が退社してしまい。問題の対応ができなくなることも考えられる。これでは、顧客に対してあまりにも不親切である。この問題を解決するためには、顧客に対してサポートを行なうための固定的な組織が必要である。

4.6.新しい組織の構成

ソフトウェア開発企業の組織には、さまざまな異なった役割を担う部門が必要である。しかし、その中心となるのは、ソフトウェアの開発プロセスの中心となる開発組織と、それを管理・支援する周辺組織である。

新しいソフトウェア開発企業の組織は、原則的にプロジェクトを編成し開発の中心となる技術者の集団からなる開発組織と、その開発組織に対して管理や情報の交換を行なう複数の周辺組織によって構成される。開発作業そのものは開発組織が行ない、その企業組織外との接触は原則的に周辺組織が行なう。外部からの情報は、その種類毎に特定の部門で集中的に管理を行なう。これは全ての情報を組織内の特定の部分に集中させるのではなく、情報の種類別に開発組織の周辺に配置することによって、開発組織が必要な情報に直接アクセスできるようにするのである。

また、新しい組織構造では、顧客に納品したソフトウェアのサポートを一貫した窓口で行なう。これによって、ソフトウェアに問題が発生した場合に、迅速なサポートを行なうことが可能になる。また、営業活動の窓口を一元化し、営業活動のために必要な情報は、営業部門でも迅速に入手できるようにする。これで、顧客に対して正確な情報を迅速に提供し、営業活動を有利に進めることができる。

そして、組織内の各支援部門はプロジェクト内の各担当者に連結され、その担当者を介して管理業務を行なう。階層的な組織構造ではなく、平準化された組織構造を持つ。組織内の全ての情報に対して、公式のアクセス経路を持ち、組織内の有用な情報はすべて活用できるような構成になっている。また、かなり大規模な組織であっても十分効率的に管理でき、さらに情報技術を利用することによって管理部門を縮小できる。そのため、新しい組織構造では、旧来型の管理組織は必要なくなり、中間管理職は必要なくなる。

また、開発組織と周辺組織の関係だけでなく、周辺組織と周辺組織の関係も重要である。特に、プロジェクト管理部門と営業部門の関係やプロジェクト管理部門と品質管理部門の関係は重要である。この組織構造では、プロジェクト管理部門がかなり重要な位置を占めることになる。

4.6.1.プロジェクト管理部門

プロジェクトの管理を行なうための部門であり、プロジェクトにかかる費用の管理、進捗状況の管理、技術者の管理、開発に必要な機材の調達などの管理業務のほかにも、営業部門の情報にもとづいた新プロジェクトの編成、品質管理部門からの情報にもとづいたプロジェクトの開発技術者の評価なども行なう。また、組織内の開発プロセスに直接関与しない他の部門とプロジェクトとの連絡も行なう。これらの連絡はプロジェクト内のプロジェクト管理担当者を通して行なう。さらに、プロジェクトに参加していない技術者の管理もこの部門で行なう。プロジェクトが終了してから、次のプロジェクトに入るまで、多少の期間があることは十分に考えられるので、それらの技術者の管理を行なわなければならない。

そして、プロジェクト内で問題を処理できない場合も、この部門でその問題の処理を行なう。厳格な管理はたとえそれが可能だとしても、その管理の為には高い管理費用が要求される。それよりも、プロジェクト内で発生した問題はできるかぎりプロジェクト内で解決させ、それでも問題が解決しない場合のみ、プロジェクト管理部門でその問題の解決を行なう。また、企業組織内のプロジェクト間または部門間の問題の解決も行なう。

すべてのプロジェクトを一つの部門で管理することによって、開発を行なう技術者の評価や管理を公平に効率的に行なうことが可能になる。この管理方法ならば、技術者が特定の上司に所属するということがないため、上司との対立によって不利な扱いを受けることはなくなる。昇進ということはほとんどなくなり、技術者の業績に対する報酬は、賃金のみになる。

4.6.2.技術情報管理部門

技術情報の収集管理を専門とする部門である。この部門で外部の技術情報を収集し企業組織内に配付する。また、組織内で開発したソフトウェアについての情報もこの部門で管理する。

また、技術情報管理の存在意義は次のようなものである。各開発技術者に対する技術サポートが強化されるため、プロジェクト進行中に発生する技術的なトラブルに迅速に対応できるようになる。技術サポート部門にあらかじめ情報が集められているため、エンジニアが必要な情報を入手するために要する作業や時間を少なくすることができる。技術情報の内容や利用頻度を調べることによって、現在自社がどの程度の技術水準にあるのかを判断できる。非公式な人脈に頼らなくても各技術者間の情報交換ができる。技術情報の共有化することが可能になり、情報の再利用性が向上することなどである。

そして、その具体的な役割は技術情報の収集や調査を行ない、収集した技術情報を分類・整理し、それらの技術情報を開発組織に配付したり、社内の情報交換の仲介を行なったりすることである。つまり、この部門は組織内や組織外の技術情報を組織内に配布するための中継点となるのである。

4.6.3.営業部門

営業活動の専門家によって構成される部門である。潜在的な顧客を顕在的な顧客にするのが仕事である。その開発組織の開発力をもとに顧客に対し提案を行ない、顧客から仕事獲得したりする。つまり、開発組織の開発力を提示し、情報技術を利用して業務の改革を行なうように提案するのである。契約の際には顧客との交渉の中心となる。また、開発技術者と顧客との間の情報の仲介役となり、開発技術者に顧客がどのようなソフトウェアを欲しいのかといった顧客のニーズを伝え、顧客に対しては開発組織内の営業部門担当者を通して、ソフトウェアの開発力についての最新の情報を提供し、ソフトウェアの開発を促すのである。

この部門は、顧客に関する情報の一元的な窓口になる。そして、次の役割を果たす。営業情報をもとにプロジェクト管理部門に対して、新プロジェクトの編成を促す。品質管理部門からの情報をもとにして、どの程度の品質のソフトウェアが、開発可能かを顧客に対して提示する。プロジェクト管理部門からの情報をもとに、どの程度の費用でソフトウェアの開発が可能かを顧客に対して提示するなどである。

また、仕事だけとってきても、それを開発する技術者がいなければどうしようもないので、プロジェクト管理部門から、どの程度の技術者が確保できるかという情報を取得して、営業活動をコントロールする。

4.6.4.品質管理部門

ソフトウェアの品質とテストについての、専門的や知識や技術を持つ技術者によって構成される部門であり、その役割は完成したソフトウェアに対する品質保証と納品後のサポートである。つまり、この部門の業務内容は、開発プロセスの最終段階における品質保証テストと顧客にソフトウェアを納品した後も、一貫してそのソフトウェアに対する追跡を行ない、顧客に対してのサポートを行なうことである。

品質保証テストでは、開発されたソフトウェアが要件を満たしているかどうかをテストし、顧客に対して作成されたソフトウェアの品質を保証する。

また、完成後のサポートについては、ソフトウェア開発では開発が終了した時点で、プロジェクトは解体してしまうので、その後はこの部門でそのソフトウェアのバグやトラブルに対応する。このような対応を適切に行なうためには、バグの調査やトラブルの処理についての、かなり特殊で高度な専門知識が必要である。顧客に対するサポートを一元化することによって、バグやトラブルに関する情報が集中的に集まることになる。この情報をもとにソフトウェアの完成後に、どのような問題が起きるやすいかを把握することができる。

品質保証テストや顧客サポート以外にも、開発組織内の品質管理担当者を通して、間発プロセスのすべてのフェーズにかかわっていく。品質のよいソフトウェアを開発するために、役に立つ情報を開発組織に提供していくのである。そして、プロジェクト管理部門や営業部門にも、開発されたソフトウェアの品質についての情報を提供する。

4.7.各部門間の規則

組織内の各部門との関係を規定するための規則が必要である。どのような組織であってもその組織を維持するためにはなんらかの規則が必要である。

新しい組織構造では、これまでの階層型の組織とは異なった規則が必要になる。これまでの組織とは違い、暗黙の了解事項というものがないので、組織内の全ての関係は規則によって決めなければならない。これまでの組織内での常識は全く通用しなくなる。そのため明示的に規則を定める必要がある。規則によって組織内の関係をコントロールするのである。企業組織内の各部門の関係はそれぞれ違ったものになるのでそれぞれ違った規則が必要になる。具体的には、それぞれの組織内に他の部門との連絡担当者が存在することになるので、それらの担当者と各部門との関係が規定されることになる。
改革の問題
5.１.改革案の問題点

これまで述べてきた改革案を実現するためには、いくつかの問題がある。

そのひとつは、現在のソフトウェア技術者は、フェーズ毎に分割された開発プロセスに慣れているため、同じメンバーが一貫して要件定義からプログラミング・テストまで行なう開発プロセスには嫌悪感を持つことが予想されることである。特にプログラミングの経験のないシステムエンジニアにとっては、実際にプログラミングをすることは大きな苦痛になるかも知れない。しかし、設計だけしてプログラミングをしないのは、非常に無責任なことである。

どのようなソフトウェアを開発したいかをもっともよく知っているはずの技術者が、その実現作業を行なわないのであれば、実現作業の過程で誤りが発生する可能性は非常に高くなる。また、それをどうやって実現するかを知らないのであれば、その設計の実現性はまったく保証されていないのと同然である。これではたとえ設計に問題があったとしても、設計段階でその問題を見つけだすことは不可能である。この結果、問題はすべてプログラミングを担当する技術者に押しつけられることになる。

もうひとつは、現在の階層型の組織において、その組織構造からなんらかの利益を得ている人々で、新しい組織構造においては、その利益が保証されなくなる人々である。

これらの人々は改革を実行しようとする人々に対し、激しい非難と攻撃を加えるであろう。この攻撃は非常に激しく徹底的なものであるから、これに対する何の備えもしない場合は、改革は途中で失敗することになるのは確実である。しかし、このようなことはどのような改革を行なう場合でも起きることである。

このような問題があったとしても、この改革を実行する意味はある。経済的な競争は非常に厳しいものであり、他の企業と比較して効率の劣る企業の存在を許さない。企業の維持拡大を望むのであれば、どのような抵抗があったとしても改革は行なう必要がある。そうでなければ、他の効率的な開発組織や開発プロセスを採用した企業によって追い詰められることになってしまう。しかし、効率的な開発組織や開発プロセスを採用すれば、逆に他の企業を追い詰めることができるのである。

それに、この改革案はその実現のために、莫大な先行投資を必要とするものではなく、実行に移すために必要な費用はたいしたものではない。しかし、成功すればその効果は非常に大きく、改革を実行に移した企業は大きな利益を上げることができるのである。

5.2.今後の課題

今後の課題としては、次のようなものが考えられる。この改革案を実際の企業に適用するためには、さらに多くの問題を解決していかなければならないことである。つまり、この改革案を実際に実行し、その過程で発生する問題がなぜ発生するかをつきとめ、その原因を取り除くことによって、開発プロセスや企業組織をより効率的なものにしていかなければならないのである。あらゆるものの開発に実験が必要なように、この改革案にも実験が必要なのである。

また、この改革案のうちの一部は現在のソフトウェア開発においても行なわれていて、部分的な効果は上げている。しかし、主要な部分については、少なくとも私が調べたかぎりにおいては、まだ実行に移されたことはない。そのため、本当に効果を上げることができるかどうかは、現実社会が非常に複雑ものであることから考えて、完全に保証することはできない。つまり、この改革案はある意味では仮定である。しかしながら、どのような理論であっても、その最初は仮定である。それにもかかわらず、現在までに多くの仮定が試されてきているのである。そして、数多くの失敗があったにもかかわらず、数少ない仮定が実際に正しかったことによって、今日の文明が存在するのである。

ソフトウェア開発の改革

目次