1 ：
仕様書無しさん：
「仕様書は大事だ」とはだれもが言うものの、この業界の会社に
就職してはや２年、いまだにまともな仕様書というものをみた
ことがありません。
あるのは断片的なDFD、妙に抽象的なフローチャート、もしくは
クラス図っぽい雰囲気のなにかぐらいです。
プロのプログラマの仕様書って、どんなものなんですか？
（っていうワシもプロのプログラマ。鬱。）
失敗した時とかに書かされるもの。
3 ：
仕様書無しさん：01/12/31 03:56
３
4 ：
仕様書無しさん：01/12/31 03:57
ある意味、履歴書と同じ物。
5 ：
仕様書無しさん：01/12/31 04:00
こういう風に作りました
って事を書く報告書。
仕事の履歴。
7 ：
仕様書無しさん：01/12/31 04:01
自分が仕事をしたことを説明するもの。
8 ：
4(チャールズ皇太子)：01/12/31 04:01
Happy new year!!
9 ：
仕様書無しさん：01/12/31 04:27
書かないとしようがないときに書くもの。
…アレ？ なんで座布団持ってっちゃうんです？
>>1 本来は「こういうものを作ってくれ」という要求要件をまとめたものが仕様書です。
従ってクライアントから提出してもらうものですが、クライアントが馬鹿な場合、
こちらのSEが書き、クライアントに承認印をもらうことになります。
なぜそこまでして書かなければならないのでしょう？
答えは簡単。納入直前になって立会い検査で「ここはこうして欲しかった」とか
「そんな仕様で作ってくれなんて言っていない」といったお決まりの大混乱を
避けるためです。
で、仕様書とはどういう物を作るかという事を定義したものなので、逆に仕様書を
観れば「どういう物を作ったか」というのが見えてきます。それが皆さんの言う
「仕事の履歴」という側面です。
どういう場合に使うのでしょう？
ハイ、簡単ですね。転職した時です。職務経歴書にも書きますが、ここで仕様書が
絶大なる効力を発揮します。当然機密保持契約の観点から守秘義務も発生しますので
面接などで「その場で見せるだけ」となりますが、それでじゅうぶんです。
最終的にそのプロジェクトが頓挫していようが、外注に丸投げしていようが
知ったこっちゃないですね。「私が作りました」と言い張ればおっけーです。
ですから
>>1さんもイザという時のために自分が参加しているプロジェクトの
仕様書を貰っておくことをお薦めします。
え？ホントに仕様書が無い！？それは危険です。仕様書が必要か否かは別にしても、
仕様書をまとめる能力が無い企業は間違いなくDQNです。危険です。こわいよー。
11 ：
仕様書無しさん：01/12/31 05:15
つか、SEが作るのが仕様書。プログラマが作るのは設計書だよ。
>>10 なるほど。感動。
仕様書の正しい使い方ってそうだったんだ。
13 ：
仕様書無しさん：01/12/31 05:41
もう少しきちんというなら、仕様書はお客さんの要望を聞いて
文書の形にまとめたもので、プログラムで実現に必要な情報が
過不足なくかかれているもの。
だから、画面とか操作性とかが主になる。
設計書は、その仕様書をどのようにしてプログラムで実現する
のかを書いたもの。外部設計書だと、大枠を規定する。
詳細設計書だと、そのへんのバイトのあんちゃんに渡しても
それ見れば必ずプログラムが書ける程度に落とし込んだもの。
んでも、SEがドキュンだったりすると、プログラマの設計書
に仕様書にあるべきものが載ってたりすることもある。詳細設計書
も、数人での開発だったりして、開発者のレベルもわかっている
場合、手抜きすることもあったりするんだな。。。
14 ：
仕様書無しさん：01/12/31 05:59
そんで、一番お金になる部分がお客さんの話し聞いて仕様をまとめる仕事。
だから、SEとかコンサルが一番もうかる。んで、プログラマの単価はそ
れに比べると下がる。
プログラムのみならず、業務知識も必要になるし、ネットワーク、データ
ベースなどの選定もできるほど熟知してなければならない。上流工程にい
けばいくほど、正しい仕様にまとめたり、正しい設計書を出すには幅広い
知識が要求されるので当然といえば当然といえる。
んでも、大企業なんかだと単価の低いプログラム工程を下請けに投げるの
が普通。んで、新卒で採用される人間はいきなりSEやコンサルタントとい
う上流工程からはじめることになる。
もちろん、きちんとした教育を施す企業もあるんだが、日本の企業のほと
んどでは、そういうものはない。そうすると、自然に自社に技術が残らな
くなるし、使えないSEが大企業に蔓延するってわけ。
15 ：
仕様書無しさん：01/12/31 06:07
>>10 ほぅ、それじゃあ俺が面接するとほぼ間違いなく落すな。
持ち出す時点で終わってるし、
そこをなんかでｸﾘｱしてても仕様書が分厚ければ厚いほど落す。
正当に持ち込めるならば、製品そのものを持ち込んでﾃﾞﾓるべきだね。
わかってないんだねぇ。
1時間も話せば相手がどんなｽｷﾙ、ｸｵﾘﾃｨ持ってるかは概ね判断つくんだよ。
16 ：
仕様書無しさん：01/12/31 06:22
仕様書の書き方は、受け仕事ならﾕｰｻﾞに合わせるのが基本だねぇ。
半年ぐらい前にどっかのｽﾚで叩かれてた、
ﾃﾞｨﾉｸﾗｲｼｽに出てくるﾁﾋﾞ恐竜の会社はそりゃあひどかった...
作った後もどんどん更新されると判ってる仕様書を数ヶ月もかけ、
しかもそれで力尽きたのか更新がかからない。そもそもそんなご大層な仕様書はいらねぇって言ってるのにさ。
いや、出来上がりは実は仕様書とも呼べないんだけどさ。
ｺｰﾃﾞｨﾝｸﾞ遅れるは、当然だけど周辺知識0だから話もかみ合わん。
仕方ないから人を代えさせれば代わったやつも片っ端からｸｽﾞ。
2度と頼まんﾘｽﾄに追加。
>>15 その通り！
相手が本質を解っていないDQN会社だったら充分ハッタリに使える。
相手が本質を知っている本物だったら話の「つかみ」程度に留めておくのが吉。
相手がDQNか本物かはあなたが言う通り、5分も話せば解る。
さらっと口頭で説明しようが仕様見せようがプレゼンしようが大して変わらない。
18 ：
仕様書無しさん：01/12/31 06:27
>>10 >>15が言う通り、前の職場の仕様書を外部に持ち出すって
いうのは問題外だと思います。
自分のスキルを口頭で説明出来る程度のプレゼンテーション能力を身に
付けましょう。
19 ：
仕様書無しさん：01/12/31 06:28
ちなみに、
>>15は社会にも出たことない学生かドキュンである
のに俺は1票
20 ：
仕様書無しさん：01/12/31 06:35
21 ：
仕様書無しさん：01/12/31 06:35
という事で本質を掴んでいないのは
>>19ただひとりという事でよろしいか？
23 ：
仕様書無しさん：01/12/31 06:39
改めて言っておくが、
>>10の文章は
>>1のみに向けて書いた文章だ。
だから一般性を大きく欠いている。他の人はそれが解っているから
その一般性の部分をフォローしてくれた。
・・・などと日本語を論じるつもりは無い。厨房がきたからお開き。あーあ。
25 ：
仕様書無しさん：01/12/31 06:51
しゃーない。じゃ、解説してみるか。
> ほぅ、それじゃあ俺が面接するとほぼ間違いなく落すな。
まずこの文章は、おそらく彼は面接などやったことない「臭い」がします。
また、権力指向で、そういった権力を持ってみたいという欲望を持ってい
るけれども、現実とは遊離しているwannabeな「臭い」がします。
> 持ち出す時点で終わってるし、そこをなんかでクリアしてても仕様書が
> 分厚ければ厚いほど落す。正当に持ち込めるならば、製品そのものを持
> ち込んでデモるべきだね。
いかにももっともらしそうなことをいってるように聞こえますが、こうい
えば自分を誇示できると勘違いしている「臭い」がします。
> わかってないんだねぇ。
この文章も、えらぶりたい、という「臭い」がします。
> 1時間も話せば相手がどんなスキル、クオリティ持ってるかは概ね判断つくんだよ。
そもそも判断できていない「臭い」がします。とくに「1時間」っていうとこ
ろが。
26 ：
仕様書無しさん：01/12/31 06:58
>>25 「臭い」って....
凄いな君、臭いで判断するなんて犬並みじゃん。
28 ：
仕様書無しさん：01/12/31 07:01
29 ：
仕様書無しさん：01/12/31 07:13
>>11 ＞つか、SEが作るのが仕様書。プログラマが作るのは設計書だよ。
会社によって呼び方は違うんじゃない？
前の会社ではプログラマが仕様書を書いてたけど，
今はＳＥが設計書を書いてたりする。
仕様書と設計書を厳密に使い分けている人はあまりいないと思うが。
30 ：
仕様書無しさん：01/12/31 09:20
>>15 > 1時間も話せば相手がどんなｽｷﾙ、ｸｵﾘﾃｨ持ってるかは概ね判断つくんだよ。
すごいねぇあんた。あんたが居れば会社の人事は万事オッケーだね。
あんたの関わるプロジェクトはDQNPGもいないだろうし、デスマーチとは
無縁だろうね。
まぁほらか思い上がりだろうけどね（ぷ
仕様書という言葉だと範囲が広すぎてなんともいえない
ユーザー用件を取りまとめることから始まり
設備、基盤選定、業務用件などなど
膨大な資料が発生する
ちなみに作成資料なんかも、各企業の工程管理資料に明記されている
が、こういった資料は守秘義務バリバリなんであまり
くわしくかけないのではないかと
うえでも言われたとおり
他社のプロジェクトへそういった資料を持っていくのはＮＧですね
こういった資料は、自分のノウハウとして蓄積しておくのが吉
33 ：
仕様書無しさん：01/12/31 09:43
VB房ですが俺は
>>10と
>>13を読む限り、要件定義書と設計書の区別が
できてない人が自分が分かってるつもりになって書いた文章に見えるが？
>>33 まあ １ のいう仕様書も ＰＧ詳細設計 をさしている気がするが
大雑把に言えば、仕様書はプログラムを外部から見たときの動作を規定した
もので、設計書は内部の動作や構造を記述したものと言えるかな。
36 ：
仕様書無しさん：01/12/31 11:15
みんな自分の会社の表現を使ってるけど、さっぱり分からん。
要件定義書、設計書
ＰＧ詳細設計
ユーザー用件、設備、基盤選定、業務用件、工程管理資料
外部設計書、詳細設計書
結局何を決めて、書類にしとかなきゃいけないの?
上記プラス、スケジュールやテスト仕様書も必要なんでしょ?
37 ：
仕様書無しさん：01/12/31 11:53
俺の会社では，画面レイアウトからコーディングの変数名称まで
複数の仕様書で記述する。
設計書というドキュメントはなかったと思う。
みなさんありがとうございます。
ウチは上司(SE)からの仕事依頼が一行メールだったりするので、
皆さんの話にカルチャーショック受けてます。
鬱．．．。
39 ：
仕様書無しさん：01/12/31 14:44
>>38 一行メールの仕様でプログラムを作れるあんたはすごい！！
これでユーザーからクレームがなければ神の域。
40 ：
仕様書無しさん：01/12/31 14:52
仕様書。
お客が発した言葉。
「俺は何度もこれで修羅場を潜ってきたんだ！！
一字一句見直せ！」
と自分の部下に叱責していた。
41 ：
仕様書無しさん：01/12/31 15:00
「何ぃ！？ 仕様書が無いだと！？
しようがねぇ～なぁ！」
って駄洒落を言う為に存在する物。
業界人なら一度は発した事があるハズ。
42 ：
仕様書無しさん：01/12/31 15:32
仕様書って、プログラムが完成してから作るものじゃなかったの？？
客先にだす仕様書は作る前からあるだろが。
製作者利用した設計書・仕様書は
提出するかしないかは契約しだいでしょ。
>>36 こればっかはほんとにメーカ単位だもの
私のしっているのは
２メーカー
いずれにしても 輸出禁止書類に指定されるし
守秘義務も適用される
一度そこいらの資料のあとがきとかみてみると面白いです
>>30 いままで、面接して
スキルとかは確かにわかるが．．．
結局は個人の資質が大きく左右するもんなぁ
どうなることかとおもっていたら化けるやつとか
経験と話し方で台ジョブとおもったら．．．．
結局最後は 運 だと思うようになった
仕様書、仕様書・・・、あぁ、あの足が生えてて時々どっかに逝っちゃう
奴な。役職はなんだっけかなぁ。
47 ：
仕様書無しさん：02/01/07 00:27
未熟者の俺の仕事振りでは、仕様書とは
FD1枚では納得してくれそうにないときに、水増しとしてつけるもの。だな。
でも、実を言うと、スゲェ分かりやすい仕様書というものに、
過去1回だけ出逢ったことがある。
仕様書が無いなんて言ってる人は、一体何人で仕事してんの？
>>47 今時FD一枚って・・・。
MOかCD-ROMの間違いか？
50 ：
仕様書無しさん：02/01/09 02:21
仕様書？ プログラムソースの日本語訳の事でしょ？
52 ：
仕様書無しさん：02/01/12 10:28
＞クラス図っぽい雰囲気のなにか
（・∀・）ﾅﾝﾅﾝﾀﾞﾖ！
53 ：
仕様書無しさん：02/01/12 13:11
>>51 んなわきゃねーだろ。ソース自体が仕様書なんだよ。
モジュール設計書＝ソースの日本語訳
モジュール仕様書＝UnitTestのソースの日本語訳
56 ：
仕様書無しさん：02/01/13 12:18
OMGなどは、仕様書をそのままソースにしようとしている
（UML+XMLで）。
まあ、昔からこの考えはいろいろ出てきたが、皆失敗だった。
57 ：
仕様書無しさん：02/01/13 13:23
とある携帯電話開発プロジェクトでは、ボタンの操作説明（アイデア）を仕様書と読んでいたな。
本来仕様書と呼ばれそうなものは「資料」という単語だった。
58 ：
仕様書無しさん：02/01/13 13:25
個人的見解！
仕様書＝高級取管理職が暇つぶしに、書いた落書き
としか、思えない。
59 ：
仕様書無しさん：02/01/13 14:21
ちがう、アイデアノートさ
60 ：
仕様書無しさん：02/01/13 17:01
このスレ見ると、とんでもない会社ばっかだなと思う・・・
Cで作ってた頃はプログラム仕様書は大切だった。
テキストの長いソースを読んで理解するのは、時間がかかるから。
VB・ACCESSの開発になってからは、仕様書はあまり重要じゃない。
ボタンのソースはボタンにくっついているから、処理部分はすぐに見つかる。
画面自体がソースの索引になっている感じ。
DB全体のER図と画面遷移図と要求仕様の一覧があれば良い。
62 ：
仕様書無しさん：02/01/13 18:54
>>60 新規発足会社は、大抵しっかりしているから安心しろ
大手企業は大抵ダメだ
63 ：
仕様書無しさん：02/01/13 19:05
要件定義書(自分)-仕様変更依頼票(客)
→お金とかバグ扱いするとかの話。
概要仕様書/機能設計書(運用フロー/画面イメージ等)
→客にこれでいいっすかと文句をあとで言わせない為の資料。
自分にとっては、外部I/Fなども書いといて使う。
詳細設計書
→処理概要、マニアックな処理のメモや注意点、エラー処理方法など。
64 ：
仕様書無しさん：02/01/13 19:11
Extreme Programming では仕様書は
--
どうせ仕様は変わるんだし、すぐに古くなるんだから、それなら
仕様書は最期に書くべきだ。
--
これこそ真理。
65 ：
仕様書無しさん：02/01/13 19:22
仕様書がコロコロ変わることに慣れているｱﾌｫらしい発言だな
本来、仕様変更なんてのが開発中に発生すること自体がｸｿなんだよ
XPは「現実はクソである」事を前提としているからな。
ウォーターフォールでもきちんと動くプロジェクトばっかり
なら、誰も苦労しない。
>>64 オンサイトクライアントとメタファー、ストーリーカードの話し無しに
「仕様書は無い」というと誤解を受けるかも。
68 ：
仕様書無しさん：02/01/13 22:49
>>66 システムの信頼性とか規模にもよって変わるね。
高い信頼性を求められているところでは、
たくさんの途中の仕変はすべきでないし。
逆に動けば多少バグあってもいい、みたいなQuick Releaseに
重点をおくのだとXPが適していそうな気がする。
で、もし、それらが適切に考慮されていないなら、
仕事引き受けてしまった奴が問題ですな。
現実は問題だらけかもしれんが、そういう奴には退場してもらわないと。
営業氏ね(w。
顧客から上がってきた仕様をただ校正しただけみたいな仕様書しか書けないSEは逝ってよし！
70 ：
narucy56：02/01/13 23:02
>>66 > XPは「現実はクソである」事を前提としているからな。
いや、XP 流に言うなら。仕様が変わることは「素晴らしい事」なんだ。
顧客が学習していることなんだから。
プログラマもそれを通じていろいろなことを学ぶことができる。
> 仕事引き受けてしまった奴が問題ですな。
うん。やはりプログラマが見積もりに口を出せないのは、絶対ダメ。
（・・・ちゅうか、XP 導入編読んでいれば大体イメージできることだ
とは思うんだけど）
>>69 ああ、はげしく同意・・・。まじでいなくなって・・・。
72 ：
仕様書無しさん：02/01/14 00:23
体裁はともかく、大事なことだけは書いて置いて欲しいなー。>仕様書
後でプログラム直すときの楽さが全然ちがうかんね。
分厚いだけで、中身無いのとか多いよね。無いよりマシだけど。
プログラムがわからないSEでも構わないけど、
データの流れとか、データの値がもつ重要性について疎いヤツはいなくなって欲しいよ・・・。
プログラムってのは基本的にデータ（情報）を扱うためのものってのだけは理解して欲しい。
74 ：
仕様書無しさん：02/01/14 01:14
>>69 うぅ、耳が異体。
一次受けのSEが訳の判らん日本語もどきの仕様書だしてくるもんだから、
二次受けのSE(つまり俺)は暗号解読してクラス図に置き換えるだけで手一杯
なのよ。。。力関係もあって、あからさまな苦情を出す訳にもいかず。。。
「システム設計はうちでやりますから、おたくは詳細設計からやってください」
とかいわれて値切られた営業の馬鹿～っ
>>73 ああ、またしてもはげしく同意だ・・・。
最近思うんだけど、サブシステムごとに設計者を分けてるプロジェクトが多いが
これがいかんのではないかな、と。
データってシステム全体を流れるものなのに、サブシステムまたがる検討を
全然しないし、責任もあいまいになるし。
>>75 スキルの低い設計者を人数で補おうとすると、必然的に各員の得意分野毎
に分割されてしまうから、むしろ各設計者をきちんと束ねられて、緻密な
連係を促すことのできるリーダシップのほうが嬉しい。
>>76 >スキルの低い設計者を人数で補おうとすると
これがそもそも間違ってると思われ。
しかしなぁ、PGのレベルはともかくとしてだ。
設計者にあまりにもDQNが多いのは折れだけか？
汎用系上がりでちゃんと設計してくれる奴少ないYO!
×折れだけ
○折れの会社だけ
ﾊﾊｯ、折れもDQNさ...
>>78 汎用とか限定するのはどうかと思うが、うちの会社もそんな感じ。
設計は晒されないから、というのが原因じゃないかと思ってますがどうでしょう？
自分の設計が他人のそれと比較して優れてるとか劣ってるとか、
そういう進歩を促すような尺度が無いからかと。
どうも見てると、あの環境では成長のしようが無いんだよね。
プログラミングは下手だとすぐ叩かれるんだけど、
設計は下手でも叩かれないことが多い気がする
ま、たいてい設計してるような人間は立場が上、ということもあるけど。
>80
設計が下手でも叩かれないのは、
設計書が上がった時点で顧客とのやり取りは行われないから、と思われ。
問題があっても内部的な問題として扱うくらい。（だから顧客には見えない問題となる。）
顧客の人間が一人でも常駐してれば、
PGに「この仕様、これだとアウトプット変ですよ」なんて言われたSEはさんざん叩かれるだろうね。
コーディング中に赤入れしまくった設計書を顧客に見せてやりたいよ。
オレも仕様書が欲しいぜ！特にデザイン、インタフェース周りは変更があるたびに大改造になる。
ミーティングのときのホワイトボードの汚い落書きが仕様書だと言われたら鬱だな
俺「あの～ここが、仕様書と異なる動作をするのですが、この仕様書、間違っていませんか」
人「そういう仕様です」
俺「？？？」
人「仕様書と異なる動きをするという仕様です。要求どおりに動くようになおしてください」
俺「それは仕様変更ということになりませんか。私の権限だと手を入れられないのですが」
人「仕様ですので、」
俺「……」
結局何？
>83
あー、いるいる。そういうSE。
そういう問題を分析して、問題がありそうなら
顧客と相談するのがお前の仕事だろって言いたい。
前の仕事のときさぁ、SEが遠方にいて、仕様だけ送りつけてくるのよ。
んで、PG作ってユーザに収めて
仕様違い指摘されて
ボコボコに叩かれて
新しい仕様書起こして
PG直して
やっと収束させた頃そのSEが発した言葉
「その仕様違うので直してください」
ﾊｰｿ
86 ：
仕様書無しさん：02/01/14 16:58
>>83-84 俺 「すみません、さっきの指摘は仕様書と異なるのですが・・・」
人 「あー、その仕様書古いですね。最新の仕様では変更になっているんです」
俺 「あ、そうでしたか。最新の仕様書はどこにありますか？」
人 「ありません」
俺 「え？ ・・無いんですか？」
人 「最近忙しくて、まだ文書にしてないんですよね」
俺 「え、でもさっき最新の仕様は、っておっしゃいませんでしたか」
人 「私はちゃんと認識していますよ」
俺 「でも、それって文書にしてないから誰も知らないんじゃないですか」
人 「だからこうやって口頭で伝えているんじゃないですか！」
俺 「仕様書はいつできます？」
人 「さーねー。最近忙しいから、時間かかるんじゃないかなあ」
俺 「・・・」
というのもある
>86
あっはっは。あるねぇ、そういうの！
そういうのが積み重なるからソースが仕様書になっちゃうんだよなぁ。
顧客に納品するのが、プログラムモジュールの成果物だけだから
甘えた考えしてるんだと言いたい。
そういうSEは、アホかと。バカかと。
忙しいならスケジュール調整をちゃんとしろと。
88 ：
仕様書無しさん：02/01/14 22:16
鉛筆書きのときは消しゴムで消してからレビューに出せばよかったけど
ワープロ書きになったらなんでこの仕様書が使い物にならないくずなのかを
説明せねばならないからやりにくくてしょうがない
>>83 開発時に仕様書が用意してあるなんて恵まれてるじゃん。
漏れのところは全部口頭仕様だよ。
こないだなんか、「日付Aと日付Bを比較して、Aが大きい場合は…」
と指示されたのでそのとおりに作ったら、「これは月次処理なんだから、
先頭6桁だけで比較しなければいけないに決まっているだろう」とか言われるし…
そんな事一言も言ってないじゃん。
そうそう。思わず「知るかよ！」or「知らねーよそれ！」とかいう内容に限って、
最初から教えてくれずに、納期ぎりぎりになって口頭で指摘してくんのな。
マジ、逆ギレしそうになるヨ。
いいから文書に書いてよこせ、と。
ツリー構造のトップノードを納期ギリギリになって
しゃーしゃーと追加してくんじゃねぇ！！ こっちの身にもなれってんだ！
吐くぞｺﾞﾙｧ!!
>89
それをPGに伝えるのがSEの仕事だと思う今日この頃。
>90
そういうのもあるねぇ。
先日、仕様書にはちゃんと書いてないけど、
サブクエリを書いてjoinするんだよ、って言われて鬱になった。
しかもテスト入ってから。なんじゃｿﾙｧ!
92 ：
仕様書無しさん：02/01/15 22:27
仕様書内にある「～の資料を参照」というコメントを見たので、
その資料の提供を求めたら「ああ、ここはあなたの作業には関係ないですよ」と言われてそれを信じて
テストまで作業してたら、「なぜこの資料を要求しなかったのですか？必要でしょう！」とテスト開始直後に言われ、
事実上仕様変更で２ヶ月遅れ。
仕様書を作った人間が、仕様書のつながりを把握してないケースも多いよなあ
今日、晴れてソースが最新の設計書と認可されました！
つーか、もうあんたみたいなSヨは設計書に触らんでくれ・・・鬱だ。
95 ：
仕様書無しさん：02/01/19 01:40
客と話して、基本設計してプロジェクト管理する人の世代が、まんまバブル
世代だから、しょうがないんだよね。質の低いやつが多い、えらそうなこと
いって、客にコビ売るだけのヤツがほとんど。
客先(大手)は、体裁より実績重視。へこへこしても、なにも出ないよ。
旧情報処理の質問範囲や内容をよく理解すれば、システム開発とは何か
見えてくるかも。
あくまで、設計するのも製造するのも使うのも人ってことで閉めちゃだめ？
保全age!
>>95 激しく同意！
バブル入社組ってロクな人材がいない。
保全sage
仕様書ねーからひとりデスマーチなんだよゴルァ！！
ということで憂さ晴らしあげ
100ゲッツ！
101 ：
仕様書無しさん：02/03/06 22:36
典型的なコボル仕様書
初期処理 ファイルオープン
主処理
××ファイルを読む
・・に戻る
終了処理 ファイルクローズ
>>37 変数名まで仕様書に書くの！？
アホらしいー。
103 ：
仕様書無しさん：02/03/06 23:56
外注に丸投げするなら、仕様書は必要です
自社開発では、要するに～程度のメモ書きで十分です
いったんコーディングに入ったら、仕様のメンテより先にソースが最新情報を反映されます
から、伝言版になるドキュメントを作成し部下に指示できればよい
※新規に投入されるメンバーの教育用のドキュメントが、実は有効な資料にもなるよ
∧,,∧∩ ／
ミ,,ﾟДﾟ彡 ＜ 仕様書を後生大事に作ったり
U ミ ＼見たりしている人で
～ﾐ ﾐ ろくな人を見たことがありません。
∪''∪
仕様書を書かない人の中には
まともなのと、ｽﾊﾞﾗｼｸろくでもない奴の2種いたけど。
>>103,
>>104 >>103 漏れ外注だけど、仕様書なんて全然無かったよ。
「仕様書は無いんですか？」と聞いたら
「ﾃﾒｰが書け。書いたら俺が点検してやる」
と言われたし、新規開発で仕様提示が一切無かった時に仕様を尋ねたら
「ﾊｧ? xxカードのデータで区分が1だったらこれこれこういう処理
をするのが当たり前だろう。ﾃﾒｰ何年この業界にいるんだ。こんな事
知ってて当然だろーが」
と言われたyo!