■

最近の個人的な傾向として、
『プログラムは要望から作成する』
ってのがある。
要望に沿ったものを作った後でいろいろ変更を出してもらう形式。
小規模向けっちゃーその通りなのだが、
その際に設計書を必要としていない。
このへん小規模は脳内で行っているのはある。
しかしてプログラム作成に必要な手順というかやらなきゃいけないことってのは
システムが変わろうが言語が変わろうがそんなに変化があるわけじゃないもんだ。
ゆえに成り立ったりする。

そして。
今、目の前に仕様書がある。
画面がある。
こんな機能を実装してということも記してある。
しかしてこれから即プログラムが作れるかというとそんなことはない。
外部設計、内部設計、プログラム設計といわれるものにしても
ほぼ全て「要望書」だ。
「設計」じゃねぇ。
設計図に従ってそのまま作成できない現実がある。
なんで設計図と完成像が毎回違うのだろう。
なんで同じ設計図からまったく違う構造が出来上がるのだろう。
そんな疑問がわきあがりまくる。

とある前提をもって結果がおかしいなら前提が間違っている。

であるとするのならば、それは設計図ではないのだ。
あくまでも「要望書」なのだ。
やっぱり「設計」じゃないのだ。
こんなことがやりたいっってのをまとめ上げたに過ぎない代物なのだ。

そこからプログラムデザインもコーディングもこなす
「プログラマ」の「設計」が始まる。
そういえば「設計書はソースコード」なんて話が記憶にあったけれども、
実装という名の設計書定義作業はまさしくそうなんだろなと
しみじみそう思える。

そう思うと。
要望概要から要望一覧書を作成し、さらに詳細要望書をつくってから
設計にはいるのが我らが業界の仕事の流れ。
言葉にしてみると
要望書つくりすぎだろ( ･ω･)ゞｫｨ
って思えてきた。

きっとあれだな。
要望をまとめてあれこれ言葉変換しているうちに
もともとの要望を忘れちゃうんだな。
自分で仕事増やして、自分で自滅するパターンだよな( ´∀｀)ケラケラ
って
わ　ら　い　ご　と　じ　ゃ　ね　ぇ　(ﾟДﾟ)！！

我らプログラムを創る者達としては、
そんなおばかさんな自滅の影響は受けたくないのです。
受けたくなかったらお守りしなきゃいけない場面もでてきそうです。
(´-`).｡oO(ってかそんな状況よくあったな・・・・・。)

要望書ひとつにしても、現実問題としての右往左往があるなら考慮しなきゃならんかな。
ならんよな。
ならんにちがいない。

(　ﾟдﾟ)o[悩みの種]・・・・・

(ﾟдﾟ)o[悩みの種]