前回に引き続き、次のPDF論文の一部を紹介します。

C++の学び方

　私たちのIT業界には、上流工程と下流工程、という用語があります。また、アナリスト、コンサルタント、システムエンジニア、プログラマなどの用語があります。現在最も人気を博している用語は、おそらく、コンサルタントやアーキテクト、という称号でしょう。このような用語はなぜ誕生したのでしょうか？

　ソフトウェアへの要求は複雑になり、開発作業期間は短縮されているといわれます。そして、Web技術がビジネス活動の中核に採用されたことにより、運用と保守がこれまで以上に重要な意味を持つようにもなっています。このような時代の流れの中では、IT業界の経営層はいろいろなことを考え、配下の開発者それぞれに名称をつけます。アナリスト、コンサルタントなどなど、と。Bjarne Stroustrup氏はこのような時代の流れをどのように見ているのでしょうか。

　本日は、9ページの「On the other hand,..」で始まる段落の内容を検討します。この段落の結論を言ってしまえば、次のようになるでしょう。

・プログラミング工程は、分析と設計の下僕ではない。
・プログラミング工程を過小評価すべきではない。

　Stroustrup氏は自分自身をプログラマと位置づけています（豊田孝とStroustrup氏の対話）。しかし、C++は大規模プロジェクト向けの機能を多数用意しています。大規模プロジェクトではライブラリというものの役割が大きくなりますが、C++は名前空間や例外処理などの強力なモジュール間連携機能をサポートしています。そして、Java、C#、PHPなどの現在の多くのプログラミング言語は何らかの形でC++設計思想の強い影響を受けています。

　Stroustrup氏は分析と設計をどのように考えているのでしょうか。この問題への回答は、本日は触れません。興味のある方は、このような記事やこのような記事、あるいは、この書籍の第4部などを一読してください。C++設計者Stroustrup氏は、分析と設計を重視した上で、プログラミング工程の重要性も強調している点はきちんと理解しておきましょう。

　Stroustrup氏は、小さなプログラムを作り、それらを組み合わせながら段階的に大規模プログラムを作成することを主張しています（早い段階での結合とテスト）。これは、上流や下流などの工程分離の存在意味がないことを示しています。少なくとも、各工程の優劣は問題になりません。筆者はこの説に賛成です。プロジェクトの破綻原因の多くは、（銀行の統廃合に伴うシステム統合などに見られる）過度な工程分離（系列の維持）にあるといわれています。