« ツール開発には変人が必要である | トップページ | 設計者がひとりで実装できる時代に »

2009.03.02

詳細設計に吸収されるプログラミング

 生産管理システムや販売管理システムといった「業務システム(基幹システム)」を開発する場合、ふつうは何らかのフレームワークを用いる。フレームワークを利用する際、オブジェクト指向等の「言語特性」を意識する必要があればあるほど、フレームワークはプリミティブである――「フレームワークはオブジェクト指向を隠蔽する」でそのように説明したが、その話題に関連して、フレームワークの「成熟度」を測るための別の観点を述べたい。そのフレームワークが「実装作業をどれだけ詳細設計作業に似せることができているか」という観点だ。

 この見方は、開発スタイルの発展に関する歴史認識にもとづくものである(ってなんか大げさな言い方だ)。拙書「上流工程入門」で説明したように、「業務システム」の実装工程は以下のような「後工程の前工程への吸収合併」の過程として発展してきた。それぞれの段階でいくつかの作業が関わるが、それぞれが異なる職種として実施されていた点が重要だ。たとえばAの段階では、詳細設計者、プログラマ、コーダ、パンチャー、コード入力(パンチカードの読み込ませ作業)担当者という5つの職種によってまかなわれていた。

A.詳細設計→プログラミング→コーディング→パンチング→コード入力

B.詳細設計→プログラミング→コーディング→コード入力

C.詳細設計→プログラミング→コード入力

D.詳細設計→プログラミング

E.詳細設計

 変遷の過程をみよう。まず、「パンチカード読取機」が「オンラインでコード編集できるパネル端末」に置き換わってパンチング作業が要らなくなった(A→B)。その後、言語が高級化してプログラマ自身がコード入力できるようになった(B→C)。ついで、端末やCPUが安価になってプログラマが自分の端末を持てるようになり、机上プログラミングが不要となってコード入力作業がプログラミングに吸収された(C→D)。工業の世界では技術の発展にともなっていっぱんに分業が進むが、ソフト開発の世界では技術の発展にともなって分業が解消されてゆく点がおもしろい。

 さて、Aが成立したのが1960年代だとすると、Dの段階に至るまで1世代くらいしかかかっていない。ところが、Dに達してからゆうに1世代は過ぎているのに、いまだにEが実現できていない。それはなぜか。原理的に不可能であるためと考える向きもあるが、私はソフトウエアの実装技術の発展を待つ必要があったためと考えている。そして現在ようやく、実装技術はEを実現するために十分なものになったと感じている。

 だから私の考えでは、来るべきフレームワークの役割は「プログラミングを詳細設計に吸収合併させること」である。どんなに高機能であっても「それを利用している様子が詳細設計作業に見えない」としたら、実装用フレームワークとして成熟しているとは言えない。具体的に言えば、フレームワークを使いつつもプログラミング言語(マークアップ言語やSQLを含めてもいい)を使ってコードをチマチマ書いているようであれば、それは「D世代のフレームワーク」である。

 なお、Eの段階でプログラマが不要になるように見えるが、プログラマという職種一般が不要になるという話ではない。「E世代のフレームワーク」そのものを開発するのはプログラマだ。あたりまえの話だが、技術変化の発火点となるソフトウエアを創造するプログラマは、いつの時代でも必要とされる。そのいっぽう、「個々の開発案件」に専属するプログラミングは、かつてのパンチングと同じ運命をたどるだろう。それも案外近いうちに。

|

« ツール開発には変人が必要である | トップページ | 設計者がひとりで実装できる時代に »

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: 詳細設計に吸収されるプログラミング:

« ツール開発には変人が必要である | トップページ | 設計者がひとりで実装できる時代に »