« レガシーの呪いを解くには勇気が必要だ | トップページ | 「設計情報の構造」に現れる設計品質 »

2005.09.25

詳細設計とコーディングの融合

「CONCEPTWARE/財務管理」で例示したような「実装独立な基本設計」にもとづいて、「実装依存な設計」をまとめる。それが「詳細設計」と呼ばれる工程で、なかなか問題の多い局面だ。その扱いにくさは、この工程が実装技術の未発達さゆえの「本来は不要な手順」である点に端を発している。しかし、実装技術の発展にともなって詳細設計の工程はプログラミングに吸収されつつある。その変化はプログラマとアプリケーションエンジニアとの適正な棲み分けをもたらすものでもある。

◆詳細設計の悩ましさ

 経験者ならよくわかると思うが、詳細設計作業のいちばんやっかいな点は、手を抜いても誠実にやっても問題を生じる点だ。まず手を抜くと、プログラマの能力差にしたがったバラバラな品質のプログラムが出来上がる。プログラマからの問い合わせも増えるので、けっきょく手間がとられる。手を抜いてろくなことはない。

 では、誰が作ってもそっくりなプログラムになるように詳細設計書を作ろうとすればどうなるかというと、プログラミングするのと同じか、下手をすればそれ以上の工数をかけて詳細設計書を作るハメになる。設計者1に対して2とか3以上のプログラマの人員比率で分業することで工期短縮を狙うはずが、何人ものプログラマが詳細設計書が出来上がるのを待ってぼーっと待機しているなんて状況になったりする。

 詳細設計書は「プログラミング指示書」ではなく、提出されるべき詳細レベルの設計ドキュメントである――そのように理解されているのなら、プログラミングと同じくらいに工数をかけて設計書を作る状況も許容されるかもしれない。そうだとしても、プログラムと詳細設計書との不整合という別の問題が生じる。こまごました修正が入るたびに詳細設計書とコードとを確実に修正・同期してゆくための手間は、プログラムの本数が多いほど等比級数的に増える(と思えるくらいしんどい)。

 「中庸」を狙えばいいと思われるかもしれないが、言うは易しだ。プログラマの能力差が歴然とあるからには、どんなに適正な加減を想定できたとしても必ず無理は生じる。けっきょくのところ、ヤルゾーとがんばっても、イーカゲンにやり過ごしても、フツーに取り組んでも、禍根と悔恨を残す因果な仕事、それが詳細設計だ。

◆ユーザーインタフェースが発展途上ゆえの問題

 「上流工程入門」の本でも指摘したように、このような詳細設計作業の扱いにくさはコンピュータのユーザーインタフェース、より正確に言えば「業務システムの開発者とコンピュータとのインタフェース」の発展過程に深くかかわっている。

 かつてコンピュータに何かの指示を与える際には、穴の開いた紙(パンチカード)を用いるしかなかった。プログラマの仕事はプログラムの詳細設計にもとづいて必要なコードをコーディング用紙に書くまでで、コンピュータ内にコードを実際に書き込む作業は「コーダ」や「パンチャ」と呼ばれる別の職種によってパンチカードを使ってなされていた。しかし、画面を使ってコード編集ができるようになってからは、コーダやパンチャの仕事は消えて、パンチカードは博物館の展示物となった。現在では、詳細設計をする担当者とその内容をコードに落とす担当者との分業体制になっている。

 この歴史からわかることは何か。開発者にとってのコンピュータとのインタフェースの無骨さが、構築過程で求められるさまざまな「本来余計な手順」を専門職として成立させてきたということだ。無骨さがなくなるほどに、ある種の専門性が不要になるのも当然の成り行きだし、そのことへの抵抗もまた自然に起こる。かつてコードの編集作業がオンライン化されたときには、「画面に向かっていきなりコーディングするとバグを作りこみやすい。だから、紙の上でコーディングする手順をスキップすべきではない」なんて主張がまじめにされていたものだ。

◆変わる「プログラミング」の位置づけ

 では、現在の実装上の分業体制は今後どのように変化してゆくのだろう。これまでのインタフェースの発展は入出力機器とそれに付随するソフトウエア周辺で起こっていたが、今後はソフトウエア単独でも進展し続けるだろう。その変化は、構築の過程から「コーディング」の手間を減らせるような形で進展するはずだ。理由は単純。コーディングが、構築フェーズでもっとも手間ひま(コスト)のかかる作業だからだ。

 すでにフレームワークや軽量コンテナといった技術にきざしが現れている。それらの道具立てを使うと、「プログラム言語を用いたコードの編集」に代わって「機能の見かけや動作条件を規定する設定ファイルの編集」のような作業が構築作業の中心になる。業務システムはそれぞれ個性的なように見えるが、じつはデータモデルの局所的なパターンにしたがった決まりきった機能タイプの組み合わせでできている。これらの機能タイプに対応するフレームワークやコンテナクラスがあらかじめ確立されていて、しかもその設定ファイルを編集するための専用フォームなんかが使われていたりすれば、傍から見ればその編集作業はプログラミングではなく詳細設計にしか見えない。

 けっきょくのところ、ソフトウエアの実装作業というのはコンピュータに動作手順を理解させるための「指示内容を規定様式へ変換する作業」でしかない。コンピュータ側の理解力が向上すれば、究極的には「指示内容の宣言」としての単一作業だけが開発者側の仕事として残る。それは「コーディング不要な詳細設計」とでも表現できる作業だ。何年かすれば「かつてはコーディングという仕事があって、コードと呼ばれる文字列を何千行も書いていたんだよ。しかも、コーディングする前には詳細設計書というものを別途書いて、後にはコンパイルという手順があって...」なんて古株の繰り言が、新人技術者をげんなりさせているかもしれない。

◆「別室」のプログラマ

 ただしこれは「プログラミングが廃(すた)れる」という意味ではない。たしかに、販売管理システムや生産管理システムといった業務支援システムの個別案件の開発現場において、伝統的な「コーディング」の工数比率が低下して、「コーディングの不要な詳細設計」の比率が増大してゆくだろう。いっぽう、その体制をもたらす実装技術は少数精鋭のプログラマの技能によって支えられ続ける。それらを用いて事前に機能タイプ別のコンポーネントやクラスを作りこんでゆく過程でも、彼らの技能が必要だ。

 こうして業務システム開発の世界では、プログラミングの一部が「詳細設計」に吸収されると同時に、実装用フレームワークを洗練させるためのプログラミングが個別の開発案件から分離されるだろう。そして有能なプログラマは、従来とは異なるミッションのために「別室」に招じ入れられることになるだろう。別室のプログラマ、それもまた目指すべき専門職のひとつにはちがいない。

|

« レガシーの呪いを解くには勇気が必要だ | トップページ | 「設計情報の構造」に現れる設計品質 »

コメント

コメントを書く



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




トラックバック


この記事へのトラックバック一覧です: 詳細設計とコーディングの融合:

» プログラミングレス [Yuuntim’s Memo]
プログラミングレスというものにどれほど価値をおくべきなのだろうか?そこが大きな分かれ目になると思う.プログラムの代わりに設定ファイルを書いてしまえば,こんどはそれがプログラムにはならないだろうか? ... [続きを読む]

受信: 2005.09.26 14:46

« レガシーの呪いを解くには勇気が必要だ | トップページ | 「設計情報の構造」に現れる設計品質 »