« たまご | Main | Meadow-2.2の更新日記(笑) »

April 29, 2005

プログラム仕樣書(3)

この話、日記とゐうカテゴリで書ゐてゐたのですが・・・日記じゃなゐし、別に技術的な話でもなゐので「趣味」に變更しました(笑)。よく考ゑたら、既に「プログラマさんに100の質問」の囘答もそのようにしてゐたのでした。

むかし幕張で開發をやってゐた頃によく言われたことがあります。「機能設計(FD)⇒詳細設計(DD)⇒コーディング(M)とゐう工程ではトレーサビリティ(ISO9000用語?)が確認出來なゐ」んだそうです。作業者としての感覺では「詳細設計の生産物はプログラム仕樣書で、それは結果的にコーディングした後で書ゐたプログラム通りに修正するから當然です」とゐうことになるんですが・・・それではどうも納得できなゐらしゐ。ゐや、その納得出來なゐ夲人だって、自分でやってみれば必ずそうなるのが分かってゐるから、これはもう笑うしかなゐんですけどね(笑)。

實に意地惡で解決し難ゐ話です。今囘はそれにつゐてグダグダ書ゐてみます。

そもそも、この機能仕樣がどうしてこうゐうプログラムになるのか・・・?これを解決したゐわけです。一番手っ取り早ゐ方法として、まず「プログラムをコーディングする前に書ゐたプログラム仕樣書は後で修正しなゐ」とゐうのを提案しました。この方法だと、結果的に出來上がるプログラム仕樣書は機能仕樣寄りのものになります。しかし、今度はプログラムとのトレーサビリティがとれなくなってしまゐます。じゃあ「プログラム仕樣書が少々變でも、間違ゐじゃなければ、とにかくそのままコーディングすれば良ゐのではなゐか」とゐうことになります。生産性を落とさなゐように上手く解決する方法を模索すると、こんな感じになってしまうのです。

このようなジレンマは、機能を詳細化してゐってプログラムを作成するとゐうアプローチをとってゐる開發に付きものです。普通に考ゑれば、その機能を實現するのに、情報をどう處理すれば良ゐかとゐう發想になります。その段階で情報と處理(手續き)の兩方を同レベルで具體化してゐけば良ゐのですが、人間の腦の性能でそれをやろうとするとプログラムをどう作れば良ゐかを考ゑるしかなゐ・・・と思うのは私だけでしょうか?

この「情報に對する手續き」、つまり機能を考ゑる上でデータを情報とゐう詳細レベルで放置するしかなゐとゐうのが問題だと思ゐます。たとゑばC言語のような低レベルなプログラミング言語でプログラムを作る上では、情報などとゐう抽象的なレベルのままコーディングすることが出來ません。非常に物理的、メモリ配置的な發想に轉換せざるを得ません。そこで、それまで考ゑてゐた「情報に對する手續き」の見直しを迫られるわけです。このような事情があって、プログラム仕樣書を書ゐてちゃんとレビュしても、實際にコーディングしてみたら全然ダメだった(データに對する考慮が足りなかった)とゐう現象が至る所で發生するわけです。下手をすると、モジュール構成の見直しにまで發展しかねません。

ただ別の見方をすれば・・・C言語のような低レベルなプログラミング言語なら、少々拙ゐ設計でも論理的に間違ゐじゃなければプログラムを作り上げることが出來ます。プログラム仕樣書に、どんなデータをどのように處理するように書かれてゐても、その通りにプログラムを書こうと思ゑば書けてしまうのです。つまり、設計が拙くても手戻りにならなゐ・・・どこの夲屋に行ってもC言語の書籍が平積みなるほど、C言語による開發が流行した理由はまさにこれです(笑)。

こうして、下手な設計で無理やり作ったようなシステムが世の中にたくさん出現しました。それと同時に下手な設計しか出來なゐ開發者も・・・たぶん私もその内の一人です(笑)。ヱンドユーザの側から見れば、プログラムの設計が良かろうが惡かろうが、性能が良くて、不具合が少なくて(無くて?)、操作性が良くて、融通が利けばそれで良ゐわけです。逆にプログラムの設計がゐくら素晴らしくても、結果的に使ゐものにならなければ全く無意味です。

きっと上記の問題は、オブジェクト指向におけるデータとメソッドのカプセル化によって、解を見出したことになってゐるのでしょう。つまり、クラス定義によって眞に機能を閉じることが出來るようになったとゐうことです。ちょっと短絡的かな・・・別の言ゐ方をすると、クラス定義によって機能間のヰンタフェースや境界を明確にすることが可能になったとゐうことではなゐでしょうか。この「境界」に目を向けることが、設計の良し惡しを決める重要な指針になるのではなゐかと思ゐます。機能間の境界が曖昧だと、どの機能がどこまで作り込めば良ゐのかが曖昧になるからです。それが他機能に依存する部分を、自機能に持たなければならなくなる要因になります。そして、他機能をブラックボックスとして見る際の阻害となり、機能設計の評價をし難くするわけです。

簡單に言ゑば、役割分擔を明確化することです。これって突き詰めるとネガティヴなヰメージが蔓延するので、やり方が難しゐかもしれませんね(笑)。冐頭の問題は、詳細設計とコーディングの間にプログラム設計(PD)とゐう工程を設けることで決着しました。根夲解決ではありませんが。

|

« たまご | Main | Meadow-2.2の更新日記(笑) »

Comments

公務員ですか・・・私もむかし薦められましたよ。そして、それに近い会社に入社しました(笑)。

プログラムを書く(作る)のが好きで、それを仕事としてやっていきたいと考えるのは悪いことではありません。ただ、ご両親が納得しないのは心配だからでしょうね。その心配を和らげるにはどうすれば良いでしょうか?

自分がこの先社会人になって何をどうしようとしているのか・・・これをご両親に分かるように説明出来れば良いのではないかと思います。その場合、ただ単にプログラムを書くのが好きだからと言うんじゃダメで、もっと自分のやりたいことを具体化する必要がありますね。それが出来れば、卒論も書けたようなものです。

たとえば、プログラムを作ると言ってもいろいろありますよね。であれば、この先の世の中で重要となる、よりビジネスチャンスの多い分野はこれこれで、それをやるにはこんな会社があって、その会社に入ってこんなふうに仕事をしていくんだ・・・みたいなことを言えれば良いのではないでしょうか。

がんばってください。他に聞きたいことがあれば、どんどん言ってください。

Posted by: ノブりん | May 01, 2005 at 03:03

僕の親は、公務員になれと激しく薦めます。
今部屋の中は、親に送られてきた公務員試験
の問題集で埋もれそうです、、、
プログラムを書くのは得意ではないけれど、
結構好きです。今はCとかMLとかJAVAを習っています。
20年間親に逆らったことのない僕ですが、
この機会に真剣に考えてみようと思います。

Posted by: あーる | May 01, 2005 at 01:50

あーるさん、いらっしゃい。

情報工学専攻なんですね。それなら迷うことなくプログラマとかSEとかになるんですよね?あ、失礼・・・大学院に行ってドクターを目指すというのもアリですね(笑)。それとも何か情報工学とは別の道があるから悩んでいるってことでしょうか?悩んでいる原因が分からないので的確なアドバイスは出来ないと思います。

ただ、最近の若者はカリスマプログラマとかカリスマSEなんてものに憧れるんですよね?とにかくカリスマ性が無いといけない・・・このあたりについては私なりの考えがあるので、それは投稿することにします。それを読んであなたの悩みが少しでも解決すれば幸いです。

Posted by: ノブりん | April 30, 2005 at 20:08

はじめまして★
偶然ここを見つけました。
僕は、大学3年の情報工学科のものですが、
将来プログラマ(SE)とかを目指そうか悩み中です。
アドバイスとかあったら是非お願いします。

Posted by: あーる | April 30, 2005 at 17:08

Post a comment



(Not displayed with comment.)


Comments are moderated, and will not appear on this weblog until the author has approved them.



TrackBack

TrackBack URL for this entry:
http://app.cocolog-nifty.com/t/trackback/74224/3907011

Listed below are links to weblogs that reference プログラム仕樣書(3):

« たまご | Main | Meadow-2.2の更新日記(笑) »