前回は、ウォーターフォール的な開発におけるテストのあり方について述べました。
ほんの十数年程前まで、一般の方々が直接コンピュータに触れる場面はそう多くなく、せいぜい銀行のATM/CDくらいだったでしょうか。ATM/CDでやることといえばお金を預けて、下ろして、送金。利用する人は多くてもあれもこれもとやりたいことの要求が出てくることはなかったと思います。
さて時は流れ、誰もがコンピュータを利用する時代。特にWindowsとインターネットの普及が世の中を大きく変えました。様々なコトがコンピュータで実現され、様々なヒトがコンピュータを利用し、様々な要求が出ては、新たなサービスとして提供される。
ネットワークやハードウェア、ソフトウェア技術は劇的に進化しましたが、残念ながらソフトウェアの生産性はさほど進化できていないのが実情です。ソフトウェアのほとんどがまだ人間の能力に依存して作られている以上、人間の根本的な能力の進化がない限りは劇的に変化することは期待てきません。十年や百年で人間の能力が進化することはありえませんが。
ソフトウェアの生産性が大きく進化しない以上は、見た目の生産性を上げるような工夫をするしかありません。
様々な要求、見えない要求などの中から真に必要・有用な要求を導き出そうとする要求開発や、GUIアプリケーションや典型的な業務モデル（いわゆるCRUD）の自動コード生成ツール、より少ないコード量で目的のことが達成できるような言語や汎用的なフレームワークなど。
ウォーターフォールに変わるソフトウェア開発プロセスも様々なものが提案されています。代表的なものでは統一プロセス(United Process:UP、ラショナル統一プロセスなどを含む)や、弊社でも積極的にとりいれているアジャイル開発プロセスなど。いずれも反復型開発といわれ、一連の開発工程を繰り返し実行することでより要求にあったソフトウェアを開発することを目的にしています（ただし、工程の内容や繰り返す期間、繰り返す回数と意味はプロセスによって大きく異なります。それぞれのプロセスについては弊社のコラムや他のサイトをご参照ください）。
これらはいずれも絶対的な生産性を上げるものではなく、必要なモノを（プログラマが書く）最低限のコード量で達成しようとする取り組みだと言えます。また、それぞれが相容れないものではなく、うまくこれらを組み合わせて適用することが重量だろうと考えられます。
例えば、要求開発した要求に沿って、アジャイル開発プロセスにてより優先度の高いものからインクリメンタルにソフトウェアを開発する。プログラマは本質的なビジネスロジックのみのコードを書き、ユーザインタフェースやエンティティモデルなどはより柔軟に要求を取り込めるよう自動コード生成ツールを用いる。さらに全てを一つの言語で統一するのではなく、コンポーネントによって、例えば基盤となるところはより高度なプログラミングが可能な言語を用い、その上に載るビジネスロジックは汎用的で品質にバラつきが生じにくい（加えてコードを書けるプログラマの多い）言語と使い分けるようなことも可能です。
残念ながら現時点ではどのようなソフトウェア開発にも有効な確立した方法論というものはなく、またソフトウェアが多様化した結果、そのソフトウェアの性質（用途、信頼性、性能など）に応じたソフトウェア開発がなされることが必要です。ウォーターフォールが現代のソフトウェア開発に合致しないなどということもなく、アジャイルがどのようなソフトウェアであってもうまくいくということもない。単にソフトウェアの性質だけではなく、開発に携わるメンバやお客様の理解など総合的に判断してより適切な方法やツールを用いるのが現代のソフトウェア開発だと考えています。
hogehoge
hugahuga
7月 082008