12/01/30 22:17:22.55
仕様を完璧に決めるために案件とって来た部署を徹底的に問いつめて
少しでも矛盾や未決定事項が見つかったら追い込みをかけ、次の日
朝一で顧客の所にいかせて仕様をきめさせ、持ち帰りになったら毎晩
催促の電話をさせ.... ってやってたらなんかこっちが悪者にされた。
もう仕様を適当に決めて仕様変更を下請けに吸収させた方が気楽でいいことに
きがついた。よく考えたら上流行程にせっかくいるのにわざわざ苦労することないし。
354:仕様書無しさん
12/01/30 22:42:09.94
>>353
>仕様を完璧に決めるために案件とって来た部署を徹底的に問いつめて
>少しでも矛盾や未決定事項が見つかったら追い込みをかけ、次の日
>朝一で顧客の所にいかせて仕様をきめさせ、持ち帰りになったら毎晩
>催促の電話をさせ.... ってやってたらなんかこっちが悪者にされた。
明らかに悪者だろ。
355:仕様書無しさん
12/01/30 22:47:05.53
>>354
そっか・・
その後の手戻りは明らかに少なく予算内にも収まったんだけどな..
今度から多少の仕様の矛盾は目をつぶることにしたいんだが、どの矛盾は
無視してよくてどの矛盾は指摘しないといけないかの見分けが一瞬でつくほどには
まだスキルがないんだよな。
356:仕様書無しさん
12/01/30 22:59:12.84
「矛盾がある・未決定事項である」ってことがわかればそれでいいんじゃね？
どっちに転んでも大した違いが無い項目ならどっちに転んでも大丈夫なように作業進めるし、
そうじゃなきゃ「決めないと作業進まないんですけど」って言ってくるだろ。
357:仕様書無しさん
12/01/30 23:11:52.78
>>356
確かにいわれてから決めればいいんだけど、その間2,3日下流行程を止めていることに
ものすごい罪悪感を感じちゃうんだよね..
むかし止められる立場だったこともあるからなおさら。
358:仕様書無しさん
12/01/31 01:16:11.99
きちんと回る範囲ではきっちりかっちり決めといたほうがいいし、そういう人も一人くらいは居たほうが便利だとは思う
でも人付き合いが下手な人がそれやると、できない連中から敵意向けられたりして
くだらないことで対立始めたりして、あほな気苦労増やすだけになったりするしな
上流のほうはスキルがあるのは最低条件で、人をうまく乗せたり、信頼されるようなとこが重要なんじゃないかな
結果がよくても、悪者にされたのならそのあたりが不足してたってことだと思う
359:仕様書無しさん
12/01/31 01:34:13.11
詳細設計書から要件が読み取れないのが厳しい。
目的が書かれず、手段だけ書かれても物理的な矛盾しか指摘できない。
詳細設計書が完璧な前提なら成り立つけど、人が作成する以上、ミスは避けられない。
足元だけを照らす詳細設計書じゃなくて、目的地を見据えた上で「それを実現するためにこの手段が必要ですよ」っていう
詳細設計書がほしい。
360:仕様書無しさん
12/01/31 01:43:23.54
>>359
設計者やお客さんに聞いて仕様を確認するのが本来だけど
詳細設計書を元にプログラム作るコーディング請負の仕事なら
わけわからんまま設計書に書いてあるとおり作るしかないんじゃないか
361:仕様書無しさん
12/01/31 01:53:55.52
理屈としては指摘するのがただしい。
ただ、人間は正しい正しくないだけで動くとは限らない。
言い方次第では正しく動いてくれなくなる。
相手を見て言い方や伝え方を変えたり、根回しをするなどする事も一つの技術。
仕事の成果を優先するも、自分のやり方を優先するも、あなた次第。
自分の人生に有益な戦略をどうぞ。
362:仕様書無しさん
12/01/31 02:03:20.30
>>359
>詳細設計書から要件が読み取れないのが厳しい。
それは、詳細設計書の意義から外れるのではないかと思う
詳細設計書は実装の大まかな枠組み(論理構造)を記述するもの
システムの目的/要求/前提といった事柄は、さらに上流の設計書で記述されるべきで、
詳細設計書での重複した記述は避けるべきだと考える
もしも、>>359が「詳細設計書だけ」を渡されて実装段階で悩んでいるのなら、
まずはそれを率直に上流工程の担当者に伝えて、上流の設計書を入手することを考えよう
そして、もしもその要請が拒否されたのなら(「オマヘハイハレタコトダケヤレ！！」)、
それを(証拠として)記録した上で、(>>360の言うように)そのまま実装するしかない
363:仕様書無しさん
12/01/31 02:26:52.62
普通は詳細設計書を読んだだけで、要件が分かる訳がない。
要件を満たすために処理をそれぞれ分解して詳細設計書に落とし込んでいるはず。
きっちりと部品化して設計されていれば要件を知ってる必要ない。
そんなに要件が知りたいなら、要件定義書を見せてもらえばいい。
364:仕様書無しさん
12/01/31 05:32:00.34
>>357
未決定事項があれば
依頼側にそれらの情報をいつまでに出せるのかをヒアリングして、
製造側にそれで作業スケジュールに問題が出ないかをヒアリングして、
その結果を整理してスケジュール決めてくのも仲介役のお仕事。
もし一件未決定事項があるだけで作業が何日も止まるようなら、
そもそもそんな作業スケジュール(というよりワークフロー？)がおかしい気がする。
365:仕様書無しさん
12/01/31 07:23:51.68
>>358
できないというか決めないといけないことをそもそも理解していない部署に
その必要性をわかってもらう柔らかい言い方ってどういうんだろうな..
どんな言い方しても相手の考慮不足を指摘している以上反発は食らうわけで
しかものんびり待っていたら1ヶ月以上ほっておかれた過去の経緯もある。
これが組織間の板挟みって言うならそうなんだろうけどなんか違う気がする。
366:仕様書無しさん
12/01/31 11:35:44.82
上長を通じて申し立てる。
個人で動くべきでない。
367:仕様書無しさん
12/01/31 23:29:21.14
>>365
> どんな言い方しても相手の考慮不足を指摘している以上反発は食らうわけで
考慮不足＝ちゃんと考えろやボケェ！
ってニュアンスになってない？
「このあたりの仕様が抜けてるような気がするんで、いついつまでに確認お願いできませんかね～？(∀｀*ゞ)ﾃﾍｯ」
ってな感じでアプローチしたら、そんなにモメないような気がする。経験上。
そこで決まらなかったら、後は野となれ山となれ～だよ。
エビデンスだけは押さえといてね。
368:仕様書無しさん
12/02/01 00:00:22.13
毎日、朝と晩に呼び出されて催促されたら、その担当者が鬱病になっちゃうぜ。
お客さんの事情もあるし、すぐに回答できない質問事項もあるだろうよ。
質問の仕方も
「どうするんだ!?」っていう相手に丸投げの質問するより
「A案とB案のどちらにしますか？」って質問した方が
相手を誘導しやすいし、回答を得やすい。
相手に案を提示できるようになるには、それなりの能力が必要だけどね。
369:仕様書無しさん
12/02/01 00:27:31.85
「A案とB案のどちらにしますか？」
客「良くて安い方」
370:仕様書無しさん
12/02/01 00:36:13.06
そんなこまめに催促したって、体が二つになるわけじゃ無いんだから、スケジュールのネックになる事を伝えて優先度つけて作業してもらえば済む事だよな。
それで全体が遅れたらそれはそれで仕方がないよな。
自分に非がないと攻撃しちゃうタイプなのかな？無意識？
371:仕様書無しさん
12/02/01 02:08:37.57
>>370
世の中には進捗表に優先度の項目があるけど、それが全て高になっている
プロジェクトもあるわけなのだが。
372: 忍法帖【Lv=3,xxxP】
12/02/01 04:20:31.74
アプリの質にもよるが、推奨案まで持って行けたらベストだわね。
決められない人たちに判断基準を示してあげるのも大事だと思うよ。
上流でやっとけや！(#ﾟДﾟ)って話はあるがね。。。
373:仕様書無しさん
12/02/01 08:53:43.17
>>371
俺も見た事あるけどさw
スケジュールの足引っ張る項目を伝えればさすがに優先してもらえるし、ぶつかってたらマネージャーが仕事する番だろ。
374:仕様書無しさん
12/02/01 08:55:04.48
>>372
こっちが考えてやると、次から当然の様に仕事押し付けてくるってのもあるなw
375:365
12/02/01 23:53:42.85
>>368
たしかに担当者を追い込みすぎる癖があることはわかってる。
特に担当者が最初に「何でそんなの決めないといけないんだ」的な
反応をしてきたときに、徹底的に追い込んだことは何度かあるな。
コミュニケーションスキルは本当に難しいな
376:仕様書無しさん
12/02/02 00:03:28.03
気持ちは分かるがやっちゃだめだ。
頭にきても手を出しちゃいけないのと同じだ。
377:仕様書無しさん
12/02/02 00:34:12.11
足ならいいか！？な？
378:仕様書無しさん
12/02/02 01:11:29.64
反感をもたれるような持ち掛け方をしてるか、
既に嫌われてて煙たがられてるかのどちらかって可能性もある
慕われるように仕向けて、自分からやっとこうって思わせれるようにしたほうがメリットあるのにね
379:仕様書無しさん
12/02/02 01:24:48.60
>>360
>>362
レスありがとう。
実際それが正論で、そうあるべきだと思う。
けど、(今の現場では)詳細設計書が基本設計書を満たしているか否かのチェックが機能していないんだ。
詳細設計～テスト実施にかかわる人が要件を把握できれば、詳細設計書の漏れや、要件の漏れがある程度チェックできるはずだけどその工数は
なかなか認められない。けど、請負う側はそのリスク(要件の漏れや、詳細設計のミスによる仕様変更)まで背負わされる(「普通に考えればわかるでしょ」って言われる)。
んな事を考えると行き着くところはアジャイルだけど、発注側はリスクを背負いたくないから契約形態は変わらない。
「より良い物を作りたい」だけなのに責任の擦り付け合いになっちゃう。
あ～明日の仕事も憂鬱だなぁ。。。
380:仕様書無しさん
12/02/02 07:51:31.68
>>378
そりゃ理想論としてはそうだけどそんな平和な現場って実際あるのか？
もっとギスギスしているのが普通だと思ってた
381:仕様書無しさん
12/02/02 11:40:11.82
>>379
お前またはお前の会社は、詳細設計書を渡されて実装～単体テストのみを請け負ってるのか？
だとしたら、要件への適合性なんか考える必要無い。
382:仕様書無しさん
12/02/02 11:46:19.58
>>379
>(今の現場では)詳細設計書が基本設計書を満たしているか否かのチェックが機能していないんだ。
問題は、詳細設計書から要件を導き出せないことではなくて、これが問題なんだろ？
だったら、詳細設計書をアウトプットする奴らにちゃんとしろと言えよ
それとお前の成果物を受け取る奴の受け入れ基準を聞けよ
383:仕様書無しさん
12/02/02 12:30:55.71
>>380
むしろ、わざわざ反感買うような奴が続けられるようなヌルい職場が
まだ残ってるんだと驚いた。
反感買うような言動する奴は徹底的に苛められて追い出されるのが普通じゃね？
384:仕様書無しさん
12/02/02 14:32:30.36
>>382
おそらく詳細設計書を複数人でレビューしてなくて
上流で発生する仕様漏れや間違いが発見されずに
実装させられてるんだろう。
SEがスキル不足でPEが毎回墓穴を掘らされてれば、
自衛手段として実装前に要件を確認して、
設計に問題が無いかくらいは確認するようになるよ。
385:sage
12/02/02 14:48:04.24
>>384
PEって何だろ
386:仕様書無しさん
12/02/02 14:56:35.24
プログラマー
387:仕様書無しさん
12/02/02 14:59:48.68
>>379
設計担当と実装担当が別会社なら、渡された設計書をそのまま実装した方がいい。
自分の仕事以外の余計な事して、コストをかけるのは無駄。
仕様変更があれば、その仕事分を集計して、請求するか交渉の材料にする。
同じ会社なら、
設計が正しいかSE達でレビューをしっかりやってもらうしかないと思う。
あまりにもミスが目立つなら、リーダーや上司に訴えろ。
388:sage
12/02/02 15:14:13.03
>>387
全くその通り。
自衛が必要なら、前工程の成果物の妥当性を再検討するのではなくて、別の手段で。
>>384
詳細設計書かく人をSEと呼ぶですか・・・。
389:仕様書無しさん
12/02/02 15:15:06.06
おっと、超久しぶりにブラウザで書き込んだもんだから、sage間違い
390:仕様書無しさん
12/02/02 19:20:40.56
>>388
詳細設計を素人の客が見るならSEが書いた方がいいよ
PGが書いた詳細設計はいい意味でも悪い意味でも素人には読めません
391:仕様書無しさん
12/02/02 20:13:31.67
そもそも、詳細設計を素人が見る必要があるのか？
何のために見せるんだ？
392: 忍法帖【Lv=4,xxxP】
12/02/02 22:01:53.32
詳細設計なんぞお客に見せない（見たがらない）もんだと思ってた(´・ω・｀)
393:仕様書無しさん
12/02/02 22:29:04.38
詳細設計書作成がなかなか進まない
分からないところがあってソースを確認するはずが、気が付いたらコーディングしてる
どうしよう
394:仕様書無しさん
12/02/02 23:06:49.83
>>393
その場合はコーディングしてから設計書書いてコード見直す
プログラミング言語のほうが直感的にロジックを記述できるのは自明
で同時に設計書も書くことで仕様が整理されてコードの間違いにも気付く
395:仕様書無しさん
12/02/02 23:34:02.01
>>381
>>382
>>387
ありがとう！ふっきれた！
今まで、自分が製造担当した箇所で(要件漏れやドキュメント不備による)不具合、トラブルが発生したとき、
責任を感じてしまってた。
「製造担当」は製造に責任を持つべきで、「設計」の責任まで負う必要はない。
ただ、馬鹿正直に詳細設計書通りに実装するんじゃなくて、気づける箇所があれば要件を聞く。
その結果変更が必要なら変更分を請求すればいい(自社が設計して、変更にかかる工数を確保できなければエスカレーションする)。
(なんか文字に起こすと当たり前のことすぎるね。。)
よし、明日もがんばろう！
396:仕様書無しさん
12/02/02 23:39:06.15
>>393
スケジュール通りに成果物(設計書とソース)が上げられるならそれでもいいんじゃない？
けど、try and error だと残工数見積もりにくいよね。
詳細設計書に求めてる粒度が細かすぎるのでは。。。
397:仕様書無しさん
12/02/02 23:50:15.45
>>394>>396
アドバイスありがとうございます。
今までは先にコーディングしていたのですが、今回のプロジェクトは詳細設計書だけ先に提出しなければいけなくて…。
細かくやろうとしすぎてるかもですね。
398:仕様書無しさん
12/02/02 23:53:08.30
>>383
いやな奴や、客観的にみてもその場にいない方がましな奴でも平気で居座るのが
デスマというものなんだが。。
仕事はきついけど連帯感が生まれて現場は和気藹々だとでも妄想しているのか？
399:仕様書無しさん
12/02/03 01:15:19.64
詳細設計書の書き方がよく分からなくて、
自分がコーディングした場合を想定したロジックを
そのまま言葉に起こした設計書を提出したことがあったな。
その後に上司に注意されたよw
400:仕様書無しさん
12/02/12 15:15:49.08
みんなUML使ってる？
401:仕様書無しさん
12/02/12 15:21:47.20
クラス図とかシーケンス図とかよく使うな。
402:仕様書無しさん
12/02/12 16:12:31.26
ユースケース図とかアクティビティ図とかよく使うな。
403:仕様書無しさん
12/02/14 20:03:34.03
>>398
お前かわいそう。人を人として見られなくなったら終わりです。
仕事は仲間とする方が円滑に進む。綺麗事じゃなく。
徹底的に追い込むとかお前何様よ。お前も雇われの身だろーが。
お前の思考回路って、都会的と言うよりも在日じゃねーか？
404:仕様書無しさん
12/02/14 23:35:26.51
>>403
アンカは>>383のタイポかな？
内容については、同感
そういった職場の雰囲気は、リーダの性格によって形成されるのだと思う
405:仕様書無しさん
12/02/15 19:57:04.45
>>403
仲良し同士で低レベルなシステム作って一生喜んでいればいいじゃん。
そのうちインド人に取って代わられるだろうけどね。
本当のチームはチーム同士切磋琢磨するし、自らの責任を果たさない
フリーライダーはあっという間に排除する。
406:仕様書無しさん
12/02/15 21:22:19.88
>>403
お前は草野球。
プロ野球でスタメンになりたければ、人より秀でる必要があるって話。
プロのメンバー選考で手をつないでゴールしても落とされるだけだろ。
407:仕様書無しさん
12/02/15 23:00:20.08
仲良しごっこだろうとライバルごっこだろうと結果が出せなければ意味無いな。
408:仕様書無しさん
12/02/15 23:26:09.20
>>407
その通り。
自分以外の部署の人間が鬱病になろうがそれはその部署のマネジメントの問題。
中ではチームの力を最大限に生かすチームビルディングを行ってマネジメント能力をあぴーるし、
ほかの組織に対しては弱みを見せた瞬間に徹底的に追い込んで弱体化させるのが
組織の中で生き抜く秘訣。
409:仕様書無しさん
12/02/16 01:19:21.65
結果を出すことと組織の中で生き抜くことは全く関係ないな。
410:仕様書無しさん
12/02/17 21:34:01.27
仕事仲間のことだと思ってるんだが、どこで仲良しに変わったの？
お前らコンプレックスで過剰反応し過ぎじゃね？
この10数年の会社教育は嘘で洗脳だから、そろそろ目覚ましの時間ですよ？
411:仕様書無しさん
12/02/17 23:37:50.44
アットホーム()とか、まぁ良くも悪くも日本っぽい事ではあるし、それで成功してるとこもいっぱいある
別に和気藹々やるのがダメだとは思わん
ただ、そういうのを強調する人は、大抵自分から学んぼうとかしないで
低いレベルで仲良しごっこしたがる人が多いからなｗ
仲間意識をつかって停滞することに安心してる、みたいな
無理やりスレタイの話題に振るなら、そういう人が書いた仕様書は、割とひどいｗ
412:仕様書無しさん
12/02/18 12:34:04.54
新人が作った顧客に出す設計書のタイトルが↓だった
～♪♪ ○○設計書 ♪♪～
413:仕様書無しさん
12/02/18 12:44:36.23
客も喜ぶかもよ？
414:仕様書無しさん
12/02/18 20:03:22.26
中身がしっかりしてれば、外見なんて気にしない。
中身がなければ、怒りが増すがな。
415:仕様書無しさん
12/02/18 21:50:57.90
客によるとしか言えないな。
416:仕様書無しさん
12/02/19 16:45:07.13
新人なりに見栄え良く見せようとしたんだろ。
OJTで放し飼いして、ロクな教育してなかった奴が悪い。
417:仕様書無しさん
12/02/19 17:16:55.09
新人だと思ったら４０才くらいのおっさん個人事業者が作った設計書らしい
418:仕様書無しさん
12/02/21 21:41:55.34
ジョエルのファンなんだろ
419:仕様書無しさん
12/02/22 00:40:09.25
>>392
完全なエンドユーザーが見るわけじゃなく、
客先のシステム担当が次のシステム改修の際に使うんだろ。
それか、基本設計書にエラーコードとか、要点じゃない
雑多な仕様が記述されてない場合とか。
420:仕様書無しさん
12/02/26 14:08:13.66
システム改修など、細かい部分が重要なのに、それが抜けてる仕様書は困るんだよね。
エラーコードとかは分からなければ、ユニークなコードで追加していけば問題ないが
データの抽出条件とかは、複雑だと調査に時間がかかってしまう。
421:仕様書無しさん
12/02/26 16:48:07.30
そういうのとても書ける量じゃないときがあるけどどうやって管理してんだろう？
結果の合否判定がやたらと複雑で仕様書にもどこにものってない箇所とか普通にあるんだけど
ソース見ながらでもうんざりするぐらい長いんだけど
422:仕様書無しさん
12/02/26 17:02:57.34
管理してないんじゃねｗ
担当が居なくなってから火を噴く、みたいな
423:仕様書無しさん
12/02/26 19:20:31.66
出来上がったソフトの動きが仕様です。
424:仕様書無しさん
12/02/26 19:27:21.27
そもそも要件が定義されていない。
回路図を渡され、顧客とやりとりしたメールの断片が転送されてきて
1ヵ月後までに仕様書と実装とテストを終わらせておけ
といわれる俺は既に色々あきらめている。
某日本で一番入りたい家電メーカのとある職場の風景
425:仕様書無しさん
12/02/26 22:18:18.42
日本の家電メーカーとか最初から終わってんじゃん
入りたくねーｗ
426:仕様書無しさん
12/02/27 18:03:50.33
家電とかの電子回路は商品ごとに作り直せるから無問題
427:仕様書無しさん
12/02/27 18:09:50.12
日本のものづくりw
技術者を大切にしないから、衰退の一方だなwww
428:仕様書無しさん
12/02/27 18:25:14.20
>>421
誰かが何らかの形で残してなければ、何も無いんだよ。
大概は、最初のうちはちゃんと作ってるけど、
プロジェクトがヤバくなると、ドキュメントの修正も手がまわらなくなる。
ある程度、体裁が整った設計書をコピペして使い回すから、
潜在的なバグ・仕様上のバグが爆発的に広がる。
まさに負の連鎖w
429:仕様書無しさん
12/02/27 22:30:36.51
>>424
それはマネしたさんではなくてエスプーさんのことですね。
430:仕様書無しさん
12/02/27 23:50:58.83
人売りが技術系にはびこってしまったからなぁ
スキルの安売り状態で業界がどんどんだめな方向に向かってる気がするわ
スキルなくても底辺で食ってけるから、そこで安心しちゃってるようなの多いし
431:仕様書無しさん
12/02/28 20:36:35.55
仕様書については未だに悩んでる。
1つの提案なんだが、コードにlatexで埋め込んで
仕様書を自動生成するか
そうでなくてもワードよりはtexのほうがいいとおもう。
どうせpdfで出図すればいいんだから。
なんでwordを進めるのだろう。
酷い場合はexcelで書く馬鹿がいる。
しかし上司だからこき下ろすこともできない。
432:仕様書無しさん
12/02/28 20:57:17.60
WordもExcelもMicrosoft Office Personalに入っているから
どの会社のPCでも導入時の状態のままで確実に読み書きできる、だろ？
433:仕様書無しさん
12/02/28 20:57:59.49
texは他人と共有したいとは思わないね。
環境ごとに使えるテンプレやマクロが違うとかやってらんない。
434:仕様書無しさん
12/02/28 21:02:30.53
latexはWYSIWYGじゃないからダメ。
逆にWYSIWYGで編集できるなら、
その中身がなんだろうと関係ないから
latexの必要性がない、
435:仕様書無しさん
12/02/28 21:03:37.42
ドキュメントは結局糞Wordしか使えないって事が多いから諦めて一通りは覚えた
使いにくいだけでスタイルと文書は一応分かれてるし
初期設定さえできてしまえばあとは書くだけになるし、そこまで手間はかからない
使いにくいだけで
Excelドキュメント作るやつは全員ばくはつしてしまうといい…
436:仕様書無しさん
12/02/28 21:10:37.92
>>431
お前はこれでも読んで勉強するといいよ。
Excelプロトタイピング―表計算ソフトで共有するデザインコンセプト・設計・アイデア
URLﾘﾝｸ(www.oreilly.co.jp)
なんでExcelはだめなんですかと聞くと、
Excelは表計算なんだから表計算にしか使ったらダメだ！という
それ以外の理由がない。頭が固いと思う。
Excelが優れている理由ならたくさんみつかるな。
ワークシート単位だから、文書が増えてもワードみたいにページが変わったりしない。
ワークシート＝タブと考えれば、タブと同じ便利さがある。
図形を入れられる。それでいて文書も数値計算もできる。
大まかな座標が合わせやすい。
Excel=表計算という固定観念を捨てて、方眼用紙ソフトと考えれば、万能ソフトだって分かるだろう。
437:仕様書無しさん
12/02/28 21:33:58.47
万能ソフトだろうが何だろうが、まともに文章が入力ができないソフトはダメだ。
438:仕様書無しさん
12/02/28 21:44:46.71
挿入 - オブジェクトで「Microsoft Word 文書」を選べばいいよ
439:仕様書無しさん
12/02/28 22:18:24.23
WordよりはExcelの方がいいな
440:仕様書無しさん
12/02/28 23:42:43.31
Excelが万能って理由もあるけど、Wordがダメ過ぎるってのもあるんだよ。
441:仕様書無しさん
12/02/28 23:46:53.03
>>431
ソフトウェア開発ではなくてネットワーク構築の事例になるけど、
UNIXサーバの設定仕様書をLatexで書いて、PDF文書として納品していたことがある
・Latexを選んだ理由は、文書を自動生成できるから（機械にできることは機械にやらせよう！）
・サーバの設定ファイルからLatexの章/節/リスト/テーブルを生成するスクリプトを開発 - (a)
・自動生成できない部分は、独自の定義言語を設計してその言語からLatexソースを生成 - (b)
・仕様書全体では100ページを超えたけど、Latex手書きは設計方針を記述した先頭20ページだけ
・スクリプト等のツール類の記述言語は、(a) Ruby と (b) Prolog
・事前にPDF文書による納品が可能かどうか確認要(大半の顧客はWordを希望/要求する)
あと、「コードにlatexで埋め込んで仕様書を自動生成する」提案については、
「文芸的プログラミング」という発想がある（詳しくは、ググると解説が見つけられる）
さらに付け加えると、将来性の面で(Latexよりも)「DocBook」と呼ばれるXML文書形式がオヌヌメ
まだ実用上の課題は多いけど、HTML/PDF/EPUB/ODF(Open.Office)等への変換が可能
442:仕様書無しさん
12/02/29 01:13:30.98
Excelで作られた文書って、目先しか考えてないからなぁ
文章を書く、ってのが前提にあるなら、Excel使ってる時点で全部糞以下だわ
更改されない使い捨てなら別に何でもいいけど、仕様書とかをアレでやられてると、げんなりする
Excel方眼紙仕様書は高確率で、
章番号段落番号とか、修正自色変えとか、一部分だけ取り消し線とか
挙句の果てには印刷レイアウト見ながら列幅の調整、文章の分割を行わないといけない、とか
糞ルールのおまけがいっぱいついてくるしなｗ
操作性悪いI/Fや、ちょっとした誤操作で設定してるスタイルぶっとばしてしまうような
うんｋWordはダメダメのダメダメダメダメだけど、それでもちゃんと使えばExcelよりかは手抜きできるから使いようだと思う
問題の根本原因は、Wordですら理解できないのが多すぎることだと思う
そういう奴らも仕事に関わる以上、結局サルでもわかるExcel方眼紙！みたいなのに助けてもらうしかない
443:仕様書無しさん
12/02/29 01:31:29.80
普通の人はデータそのものと視覚的デザインの分離が正義だとは微塵も思ってない。
いかに正確に、効果的に読ませるかに関してのアプローチにおいて
文章データと視覚デザイン、場合によってはアニメ、効果音すらも一体化しており切り離せない。
だから理系脳の連中がデザインの分離を叫ぶたびにこいつら頭沸いてんじゃねーのかと思ってる。
444:仕様書無しさん
12/02/29 01:34:21.70
>>436
別に何でも出来るわけじゃないし、「万能」とはちょい違うと思うなー
Excelは、理解しなくても方眼紙としては使えるので、馬鹿でもわかるって感じだと思う
列幅行高さ変更を禁止される事多い方眼紙を使ってしまうと、改行するだけでカットペースト必要だったり、
笑えないギャグがてんこ盛り状態にはなるけど、それでも方眼紙として使う上での殆どのことは特に理解しなくてもわかるレベルだし
ほんとExcelすごいな…！！１
あと、Excel仕様書の反対理由で、表計算だからって理由を前面押ししてる人はそんな居ないんじゃね
「そもそもあれは表計算ソフトで、文章を書くためのものじゃない」っていうような言われ方ならちょいちょい見るけど
それって「表計算ソフトだからー」、じゃなくて「文章作成機能付いてがないからー」って意味っしょ
もし、前者のように捕らえちゃってたのなら、多分Wordの機能と、Excelの機能の差をちゃんと理解しきれてないんだと思うぽ
修正の履歴つけたり、番号振ってくれたり、用語を参照してくれたり、目次つけたり、段落やレイアウトやってくれたり、
印刷を面倒みてくれたり、みたいな文章の作成向きの機能がExcelには殆どついてないから、
どっちも一通り触ったことある人は、流石に文書作るのにExcelはねーな、ってなるんだと思う
445:仕様書無しさん
12/02/29 01:45:40.62
文書を電子データのまま活用するか、プリントアウトして活用するかの文化の違いに見える。
446:仕様書無しさん
12/02/29 01:47:08.58
ついてる機能を知らなくても、方眼紙エクセルなら力技で何とかできるからなぁ…。
ワードだとその機能を知らないと出来ない事が多数あるから、学ばない連中は拒絶反応を示すんだと思うよ。
検索や置換機能のあるエディタが手元にあっても、その機能知らないから、全部手作業で単語の書き換えをやる奴いるのと同じ話。
別に個々の仕事で簡潔する事なら、どうぞ好きに力技披露してくって感じだけど、
俺までそれに合わせないといけないってなるのは、すごく面倒。
447:仕様書無しさん
12/02/29 01:56:21.53
UMLって全部、多次元配列で表現できるような気がするんだ。
いや、具体的に検討したわけじゃないんだけど。
wiki文法に組み込めないかな。
448:仕様書無しさん
12/02/29 01:58:01.72
>>443
ここマ板だしなｗ
仕様の修正で、中身となんも関係ない見た目まで毎度再調整とか、無駄じゃね
ブレブレの仕様とかだと、仕様ちょっと変わるたびに見た目まで再調整とかになったりするんだぜ
基地外じみた章番号の修正とか、気が狂う奴が出兼ねない…！
そういうのがめんどくせぇ、ってのに理系だの文系だのは関係ないと思うｗ
>>445
印刷する気ないのに、印刷レイアウトではみ出しがないかチェックしろ、みたいなアホなルールも結構みるけどなｗ
レビューでんなとこチェックしてる時間あったら、内容の不備がないかをチェックしろよって思うこと多々
449:仕様書無しさん
12/02/29 07:30:37.21
基本的に方眼Excelのくせに、一部分だけ表を書きたいためなのか
横長なセルがあったりすると非常に萎える。
450:仕様書無しさん
12/02/29 07:39:14.85
プログラマだけど文系だからな俺
Texとかまじわからん
Excelが文章作成ソフトじゃないのはわかるんだが、Wordは不親切な親切が多すぎて使っててイライラする
はっきり言ってどっちも使いたくないけど二択ならExcelの方が扱いやすい
451:仕様書無しさん
12/02/29 07:44:22.12
> Texとかまじわからん
HTMLわからんって言ってるようなものなので、ちょっと恥ずかしい。
452:仕様書無しさん
12/02/29 12:33:47.48
方眼紙にするだけならまだ許そう。お前ならまだ切り貼りもだいたいできるし、他からのペーストもわりと受け入れてくれる包容力がある。
だがセル結合、テメーはダメだ！
>>450
イライラすんのは理解力がない自分のせいだと思うぞ。
俺も前は、Wordは勝手に○○されるから糞って思ってたけど、結局それはなんでそうなるかを知らないからなわけだし。
項目名が意味フだったり、ヘルプも微妙だったりで、覚えるまで面倒なのはすごく同意できるが、
イライラしてても埒が明かんって調べたら、数十分ありゃ解決するような話だったこと多々。
Texも別に調べりゃすぐわかるレベルだし、わかるわからない以前に単にやる気がないだけだと思うわ。
453:仕様書無しさん
12/02/29 18:07:40.78
Wordで章だてから真面目に書けば、そう悲惨なことにはならない。
書式は統一されたものを適応するのみ。
なんでも適当にやるからだろ……
454:仕様書無しさん
12/02/29 18:16:16.13
>>450
Wordで文章書くとき、
一つの文なのに改行で行替えしたり、
タブや全角スペースで文字下げしたりインデントしたり、
文の一部を選択してフォントやサイズを変えたり、
目次を手でかいたり
してない？
そりゃ大変だよ。
455:仕様書無しさん
12/02/29 19:58:09.40
>>450
TeXなんかなんかプログラム言語の文法と比べると簡単なもんだぞ。
文系と言うのなら不親切な親切って言う表現はおかしいだろう。
Wordは大きなお世話が多いのは確か。
456:仕様書無しさん
12/02/29 21:09:57.02
Excel否定する長文をよく読むと
否定する理由の根拠が激しく乏しい件について。
457:仕様書無しさん
12/02/29 21:11:03.88
>>453
> Wordで章だてから真面目に書けば
章立てする理由は？
本書いてるわけじゃないんだから
そんなの必要ないよ。
458:仕様書無しさん
12/02/29 23:02:20.84
Ctrl+クリック(だっけ？)で即ジャンプできるじゃん
459:仕様書無しさん
12/02/29 23:22:27.66
>>457
ぐちゃっと書かれてる仕様書はわけわからん。
いや、書いてる奴自身はわかってるのかもしれないけど。
コードと同じように、スパゲティ仕様書もダメダメだ。
460:仕様書無しさん
12/02/29 23:33:53.31
章＝ディレクトリでいいやん
461:仕様書無しさん
12/02/29 23:39:02.75
Wordはもうちょっとアウトラインが使いやすければなあ。
462:仕様書無しさん
12/03/01 01:02:50.34
ファイルがひとつにまとめられてると
同時編集が面倒なんだよねぇ。
ほら、仕様書作成なんて一人でやらないでしょ普通。
463:仕様書無しさん
12/03/01 01:17:53.14
モジュールに分けて仕様書つくればいいんじゃないのか
464:仕様書無しさん
12/03/01 01:27:04.63
SEになって数年たつけど、Excelで仕様書作ってるよ。
請負中心だから客先ですでに決まってるフォーマットを使ってる。
Excel設計書に不満があるけど、
だからと言ってWordの利点も見出せないから現状維持。
465:仕様書無しさん
12/03/01 01:33:49.86
使う人が使いやすいならエクセルでもいい。
自分しか使わないなら好きなので書けばいい。
ただ、Wordを批判するやつの九割以上がWordを使いこなせないことを責任転嫁しているのは納得いかない。
466:仕様書無しさん
12/03/01 01:44:53.48
Word好きじゃないが、Wordでもファイル分けくらいできるぞ。
複数ファイル参照とかは普通に使うでしょ。
467:仕様書無しさん
12/03/01 01:46:44.31
>>465
あるあるすぎるｗ
自分も昔そうだったからすごくわかるわ
不勉強だった自分を見てるみたいで、もにょる…
468:仕様書無しさん
12/03/01 01:47:13.73
>>465
使いこなせない人には糞にしか見えないってだけだべ
責任転嫁とは違う
469:仕様書無しさん
12/03/01 01:51:09.63
>>467
素直に言い給え、Wordも使いこなせないクズと
470:仕様書無しさん
12/03/01 02:09:21.40
仕様書はExcelで良いと思うが操作説明書をExcelで作るのは止めて欲しい。
しかも章ごとにブックは分かれているし目次もページ番号も手で振っている。
471:仕様書無しさん
12/03/01 11:53:26.64
>>457
仕様書っていう本書いてるんだよ。何言ってんの？
472:仕様書無しさん
12/03/01 14:04:06.28
本や説明書って、フォーマットは何を使ってるんだろうな。
473:仕様書無しさん
12/03/01 14:17:52.13
>>472
だいたいインデザとか。
所によっては、ページの少ないものはイラレでざくっと作る。
474:仕様書無しさん
12/03/01 16:07:19.00
>>472
Adobeの製品ラインナップなら、FrameMaker一択
中小出版社の製本業務や企業の製品マニュアル作成における、
統一されたスタイルによる高品質出版に威力を発揮する
InDesignはSOHOやフリーランス向けの製品(イラレは論外)
あとASCIIの技術系書籍では、TexをエンジンにしたEWBと呼ばれる
独自の出版システムが使われているらしい(詳細はPDF版のマニュアルを参照)
・EWB(Editor's Work Bench)の概要
URLﾘﾝｸ(ascii.asciimw.jp)
また海外大手のO'Reilly & Associatesの入稿では、DocBookと呼ばれる
XML文書形式が推奨されている(DocBookについては、まずWikipediaを参照)
実際にDocBook仕様書のソース(原稿)はDocBook自身で書かれ、ソースと
オンライン版は無償公開、印刷版は有償でO'Reilly Mediaから発売されている
475:仕様書無しさん
12/03/01 16:41:29.09
>>474
そーなのか。まぁ義弟の勤めてる会社は弱小だからかな。
見開き数Pの特集、小冊子くらいなんかは、チラシの延長でやっちゃうと言ってたけど。
476:仕様書無しさん
12/03/01 21:24:00.18
trac + wiki で書いてる
477:仕様書無しさん
12/03/02 18:13:53.79
断定できないけど、
本や説明書のフォーマットはWordやExcelを使ってないってこと？
478:仕様書無しさん
12/03/02 18:29:06.12
>>477
ちゃんとしたところだと、それ用のソフトは普通DTPと呼ばれる物を使う。
Wordを使ってる場合もあるだろうが。
479:仕様書無しさん
12/03/03 15:22:19.03
説明書ならWordで作るのも普通にあるよ
480:仕様書無しさん
12/03/03 17:24:16.16
仕様書の表から構造体やクラスＤＢのテーブルまで作ってくれるようなソフトが求められている
481:仕様書無しさん
12/03/03 17:28:24.39
ソースコードの構造体やクラスＤＢのテーブルから仕様書作ってくれるソフトのほうがいい。
482:仕様書無しさん
12/03/03 19:10:26.35
次点として、そういうことができる専任の人間を雇ってくれ。
483:仕様書無しさん
12/03/03 20:06:16.35
texがもう少し使い易かったら広まったろうに。
484:仕様書無しさん
12/03/03 20:27:41.81
>>483
texが使いやすくても無理だろうと思う。理由は四つあって、
一つ目は仕事はあくまでも体育会系のパフォーマンスであって、マクロ組んで楽したりすると上司に怒られるという風土。
○○したら作業効率ＵＰするよ、と提案すると「俺の仕事を取るな」と怒られる場合もこれ。
二つ目は一般の人はデザイナーとかイラストレーターみたいな人種に異様な憧れと畏怖を抱いていて
テンプレに必要事項を記入しただけみたいな書類を提出しても、仕事したと見てもらえない風土。
最後、HTMLの歴史を見ても本来データ構造を記述する言語だったのに使う側は見た目とべったり癒着する記述しか知らない。
情報とその表現を分離するというITリテラシの欠如がある。
485:仕様書無しさん
12/03/03 20:50:54.77
四つ？
486:仕様書無しさん
12/03/04 00:20:29.87
>>484
>一つ目は仕事はあくまでも体育会系のパフォーマンスであって、(....以下略)
確かに、そういった風土はある
対応策としては、Tex活用を個人レベルで(こっそりと)実践して、最終的に業務上で
具体的成果を示す事ができれば、そんな上司も納得せざるをえないのではないかと思う
よくある失敗は、マクロを組む楽しさや細部の装飾ばかりに夢中になってしまうこと
一言で言えば、業務改善という「目的」とTex活用という「手段」の取り違え
>○○したら作業効率ＵＰするよ、と提案すると「俺の仕事を取るな」と怒られる場合もこれ。
これも、人にやらせるのではなく、提案者自身がリスクを背負ってでも実践する姿勢が大切
どこまで自分を信じて有言実行できるか、という話に帰着する
>二つ目は一般の人はデザイナーとかイラストレーターみたいな人種に(....以下略)
これはよく分からないなあ....
提出する書類というのは、最終的なPDF文書または印刷物だと思うから、何が問題なんだろ？
>最後、HTMLの歴史を見ても本来データ構造を記述する言語だったのに(....以下略)
その問題点を改善して文書の論理構造と物理構造を明確に分離した新しい技術が、
>>474で紹介したDocBook(論理: XML, 物理: XSLT)になる
487:仕様書無しさん
12/03/04 00:27:09.44
まず論理構造と物理構造を明確に分離する理由がないよね。
488:486
12/03/04 00:56:36.22
>>486の最初の事柄の補足として、>>441のLatex活用事例を取り上げる
・Latex文書自動生成ツールは、「上司の目を盗んで」業務の合間に、あるいは
自宅で少しずつ開発/改良を進め、最終的なPDF文書だけを上司に見せた
・独自のTexマクロ定義は一切使わず、標準マクロと流通パッケージ(longtable等)だけで作った
・業務上の成果として、
・Latexから変換したPDF文書を納品物として顧客(大手SIer)に認めてさせた(認めてもらえた)
・当初は単なる構築案件だったのが、保守サポートという追加受注を得る事ができた
・当初はSIerから他社ベンダを介した孫請けだったのを、SIerからの直請けに変えることができた
を上げたことで、以降はLatex活用が「黙認」されるようになった
489:仕様書無しさん
12/03/04 01:29:25.09
>>484
デザイナーやらイラストレーターから、本文の体裁とか段落付けとか取り上げると滅茶苦茶喜ぶぞ。
テンプレートエンジン作ったことあるが、狂喜乱舞して、むしろあっちから、ちゃんと表題は表題と表現してくれとMLで流れたり、
タグ定義を増やしてくれと直談判しにきたり、
甘い文書は開発者権限でおまえで止めろ、俺達の事わかってくれてるじゃねーか、と無茶言ってきたり、
色々いい経験をした。
俺が論文のtexのコンパイル環境を毎回解説して構築させんのが面倒だっただけなのにな。
490:仕様書無しさん
12/03/04 01:33:25.24
作り話乙ｗ
491:仕様書無しさん
12/03/04 14:58:35.98
向いてないのにこういう仕事選ぶ奴が多いのがなー
体育会系脳っぽいのが多くて、土方に拍車がかかる
492:仕様書無しさん
12/03/04 15:03:23.43
そういうデザイン部分と文章部分を分けるための道具や仕組みの使い方を
理解できない頭が悪い奴を除けば、そのあたりを分離するデメリットって別に無いからなー
まぁ、そういう頭が悪い奴がいっぱい居る環境にはつかえないっていうのが、ある意味デメリットか
493:仕様書無しさん
12/03/04 15:25:32.67
流し込み機能とか使っていれば
内部で自然と文章とデザインが分かれてるからね。
ファイル自体を分けたりして
見るときは合成する。
書くときは分離する。
なんてことやらなくていいからね
WYSIWYGエディタを使えば。
494:仕様書無しさん
12/03/04 15:46:29.40
>>491
就職氷河期の時なんかはこの業界以外は人をあんまり募集してなかったからな。
特に専門知識なし未経験者歓迎みたいなのは他に無いし。 今でもそういう業界は
介護位しか無いんじゃない？ 何もない人は介護かITかの究極の選択という。
495:仕様書無しさん
12/03/06 21:45:54.91
あーマ等向けの校正ツールが欲しい。
仕様書の何がめんどくせぇってホント誤字脱字がメンドイ。
496:仕様書無しさん
12/03/06 23:03:10.69
>>495
そんなの気がついたら直すぐらいでいいよ
致命的なのは別として意味さえ通じれば流す方向で
ところで「あーマ等向け」ってなんだ？
497:仕様書無しさん
12/03/06 23:12:02.64
糞リーダーになると設計上のバグよりも
誤字脱字やレイアウトを気にする馬鹿が意外と多い。
498:仕様書無しさん
12/03/06 23:35:47.97
誤字脱字指摘してドヤ顔になってるのに、設計やユーザの使用感などの重要なこと指摘してもさっぱり伝わらない。
終いにゃ、やらなくていいって言って、切羽詰まってから自分でひらめいたかのように変更を決めて、丸投げ。
死んでくれ。
499:仕様書無しさん
12/03/06 23:44:18.18
だが誤字脱字だらけの仕様書も困るだろ
内容が本当に正しいかすら信用できなくなる
値が一つ違うだけでもかなりマズイ
500:仕様書無しさん
12/03/07 00:12:46.05
誤字脱字だったら、印刷した設計書に赤ペン引いておけばいい。
わざわざレビューの時にドヤ顔で指摘することじゃないよ。
501:仕様書無しさん
12/03/07 00:47:06.58
いや、指摘するかどうかじゃなくて単に誤字脱字がマズイって話でな
502:仕様書無しさん
12/03/07 01:07:26.69
誤字脱字はできるだけしない、レビューでみつけてなくす、ってのはそりゃまぁあたりまえだけど
それだけで満足するバカが多いこと、って話じゃないの
実際内容をきちんと理解できてるレビュアー少ないし
余計なことばっか指摘して、大事な中身まったく見てない糞な奴も結構見かける
能力ないのに長くいて微妙な肩書きだけがついちゃった系のオッサンとか、結構ひどい
>>496
「嗚呼、マ等(ら)向け」、じゃないかな。 == 「あー(感嘆詞)、ぷろぐらまーたちのための～」
糞仕様書の行間を読み解くよりは簡単な問題…！
503:仕様書無しさん
12/03/07 01:19:54.52
誤字脱字、正しくない日本語、誤解を招く日本語、全部良くはない事は皆わかってるんだよ。
ただ、物書きのレベルをプログラマに求めるのは酷だろ。
それができるならプログラマ辞めて物書きになってるって。
必要な能力なんだけどね…
時間は限られてるから、なかなかそのレベルをクリアできる人は少ない…
504:仕様書無しさん
12/03/07 01:24:57.69
でもあれだぞ。物かけない奴は概してプログラム下手だぞ。
とっちらかった文章だな、と思ったら、案の定プログラムもとっちらかってたりする。
箇条書きをうまく文章にやっつけました。って人の方がプログラムは良いことが多い。
505:仕様書無しさん
12/03/07 01:27:57.41
日本人って学校で文章の書き方に関するエッセンスを習わないし教えないからな。
みんな自己流っていう笑えない状況。
506:仕様書無しさん
12/03/07 01:35:52.28
とりあえずよ、校正じゃなくても、インテリセンス(オムニ補完)的なツール欲しいなぁ
章名を一部打ったら章の候補が出てきて、「.」押したら商に所属する値や名詞が並んで、
んで、エンター押したら指定の値がフィールドとして埋め込まれるとか。
とにかく下らないミス減らすツールが欲しいわ。どうでもいいことに時間掛けたくない。
507:仕様書無しさん
12/03/07 01:36:25.43
形だけは教えられるんだよね。原稿用紙の使い方、とか。
フォーマット地獄は既に小学校から用意されてんのよ。
508:仕様書無しさん
12/03/07 02:19:10.60
まぁ、プロの物書きですら難しいからな。
プログラムと一緒で、絶対的な正解ってのが無いのが辛いよな。
コーディング並みにガチガチするって手もあるけど、それこそ形だけのルールで本末転倒になりそうだし。
コードのレビューならコードをレビュー。
文章のレビューなら文章をレビュー。
正しい指摘を毎回できるようにして、プログラマを成長させる環境を作る事が、健全な業界の発展につながって望ましいと思うんだけどなぁー。
509:仕様書無しさん
12/03/07 02:36:09.33
正解は本当変わる。読み手次第だよ。
俺は何度となく言葉足らずだと怒られてきた。
「ちょっと考えたら分かることでしょ、pp2-3と、p10で既に説明してるから省いただけです」といった感じで。でも怒られた。
怒られたことを教訓に、いちいち懇切丁寧に書くようになって、怒られる事は減った位の頃、転職した。
「君、これは、馬鹿にしてるのかな？もうpp2-3とp10で説明してることをくどくど書く必要は無いんじゃないの？」と転職先では怒られた。
どっちが正しいか判断はつかんな…
510:仕様書無しさん
12/03/07 06:03:20.85
文章って好みがあるからね
だから軋轢生みやすい
ただ、指摘はいいけど怒ったり嫌味言ってくる奴はダメだと思う
表現の違いや誤字脱字なんかはどうしたところで発生するんだから
ドヤ顔してこれでもかと優越感に浸る奴は小物だしたかがしれてる
そういう上司とかリーダーは多いけどなｗ
511:仕様書無しさん
12/03/07 06:33:24.66
レビューの場でいろいろと指摘が発生するのは当然のことだと思っているのだが
それを嫌がる管理者がいるのが嫌だな
512:仕様書無しさん
12/03/07 09:36:41.36
>>509
このパターンは非常に多い。
好みによっても違うが、同じ人でもコンディションによって言う事が変わるのは腹が立つ。
513:仕様書無しさん
12/03/07 13:00:10.93
デファクトスタンダードが無い以上、各組織においては過去の書類を参考にしながら書けということだな。
514:仕様書無しさん
12/03/08 00:48:08.41
ごくごく自然にに考えよう。
設計とか分析とか工程というのは、
その次の工程を行うためにやる。
つまり、その次の工程の内容を理解していなければ、
使えないものが出来るのは当たり前の話。
たとえば使えない設計書。これができてしまうその原因は
その次の工程を全く知らないからだ。
自分の担当工程だけやって、下流の内容は知らないじゃだめなんだよ。
プログラミングができないSEはクズと言うのは正しいということが分かる。
515:仕様書無しさん
12/03/08 01:31:36.31
>>509
あるあるｗｗｗｗｗｗｗ
内容読みきれず、そのときの気分だけで思いつきの指摘する奴多すぎ
レベルの低いレビュアーに当たったときは何を書いてもなんかしら指摘される
とりあえず「わかりました！」って言っておくのが解決策だと思うようになったわ…
516:仕様書無しさん
12/03/08 02:50:41.70
>>28
勝手に大工やっていろ。
517:仕様書無しさん
12/03/08 03:52:41.46
>>514
分析や設計はユーザーの要件を満たすモノを作るためにやる。
それを実現するための技術的な知識は必要だけど、
次の工程はあまり深く気にする必要はない。
518:仕様書無しさん
12/03/08 19:39:40.79
>>515 わかりました、というと「課題」扱いになって再レビュー扱いになるから嫌だ。
519:仕様書無しさん
12/03/08 23:27:34.08
>>517
通訳と一緒だよ。
間に入る人は、両方のことを
知っていなければならない。
520:仕様書無しさん
12/03/08 23:29:57.69
>>517
> 分析や設計はユーザーの要件を満たすモノを作るためにやる。
当たり前の話。それは反論になっていない。
なぜなら、ユーザーの要件を満たすものを
作るためにどうするか？
その答えが、下流に適切な資料を渡すということだからだ。
ユーザーの方だけ見ていてもいいものは作れない。
521:仕様書無しさん
12/03/09 00:01:44.11
下流に適切な資料って何だ？
522:仕様書無しさん
12/03/09 00:03:28.89
少なくとも通信フォーマットがかっちり決まってる資料
523:仕様書無しさん
12/03/09 00:05:10.80
>521
馬鹿な設計になってないこと。
524:仕様書無しさん
12/03/09 00:09:21.51
エンドユーザーは素人だから
めちゃくちゃな要求をしてくるのは仕方ないけど
それ以外は、めちゃくちゃな要求しちゃだめだよね。
プロなんだから。
525:524
12/03/09 00:12:36.91
今言った、「めちゃくちゃな要求」ってのは実現が難しいって意味じゃなくて
ナンセンスな要求ってことね。どう考えても使いづらくなるのがわかりきってる仕様とか
書いてる内容に矛盾があるとか、そのとおりに作ったら破綻するのが目に見えてるシステムとか。
526:仕様書無しさん
12/03/09 00:14:07.33
>>523
Ａボタン：ジャンプ
Ａボタン長押し：しゃがむ
プレイヤ「うん？」
527:仕様書無しさん
12/03/09 00:21:14.50
>>523
Ａボタン：ジャンプ
Ａボタンまわす：回転
プログラマ「まわす？」
528:仕様書無しさん
12/03/09 00:28:51.04
初版
→→（すばやく２回）：ダッシュ
←←（すばやく２回）：ブレーキ
プレイヤ「左にダッシュしたいです」
改訂版
→→（すばやく２回）：ダッシュ
←（長押し）：ブレーキ
プレイヤ「左に行きたいです」
529:仕様書無しさん
12/03/09 00:37:24.74
>>522
>少なくとも通信フォーマットがかっちり決まってる資料
通信フォーマットとは、ネットワーク上を流れるメッセージの形式的仕様のことでいいのかな？
たとえばテキストであればXML SchemaとかバイナリならIDLやASN.1で書かれた仕様
で、そういった通信フォーマットは実装に着手する以前に仕様書としてかっちり決めるのが当たり前
もしそれが実践できていないとしたら、>>714の
>自分の担当工程だけやって、下流の内容は知らないじゃだめなんだよ。
>プログラミングができないSEはクズと言うのは正しいということが分かる。
うんぬんは些細な話で、それ以前のプロジェクト全体の品質管理に致命的な問題があると思う
530:仕様書無しさん
12/03/09 00:41:40.20
その、通信フォーマットというのを
通信システム知らない素人が作れるかといったら作れないだろうね。
シリアル通信の通信フォーマットはこんな感じでお願いと
言われた資料に、接続先のポート番号は8080で～とか書いてあったら
お前馬鹿かって思うよ。
531:仕様書無しさん
12/03/09 00:55:55.25
>>526
あー…
あるな。
しかも仕様切った奴は「一つのボタンで合理的だろ」とか言ってる感じ。
ワープロって本当に使いやすかったよね。
倍角にしたけりゃ倍角ボタン、平仮名にしたけりゃ無変換ボタン、
単漢字もボタン。罫線ひきたきゃ罫線ボタン
532:仕様書無しさん
12/03/09 01:09:34.81
>>528
もう設計書レビュー通して印鑑まで押したから変更はできないよ。
533:仕様書無しさん
12/03/09 01:17:08.27
>>532
納品直前にユーザーの怒りを買って、デスマが始まるんだね。
534:仕様書無しさん
12/03/09 01:31:59.99
>>532
レビュー通っちゃうとねー。
明らかにヤバそうなのは「試食してもらいませんか？モックアップと評価版で」とか言うと共に、
いけいけな人捕まえて「ちょっとここ突っ込んでもらうように伝えて下さい」と、両方の顔を潰さぬように大打撃を回避してる。
なんで下っ端がこんな事してるのかわからん。
535:仕様書無しさん
12/03/09 02:19:25.21
>>519
うちいま両方とも知らない奴が間にはいってるもんだから、手の内ようが無い状況だｗ
納品直前なのにまだドキュメントやらテスト仕様書やらつくってたりするｗｗ
笑えねぇけど笑うしかねぇｗｗｗ
536:仕様書無しさん
12/03/09 02:22:41.82
>>534
あー、あるわー
調整する立場の人間が調整する能力なくて、間接的に誘導して調整にもってったりとか…
何の仕事だかわからなくなる
537:仕様書無しさん
12/03/09 02:46:00.45
事後と増やす仕事は、内向きにやらないで欲しいな。
538:仕様書無しさん
12/03/13 12:29:12.58
空気を読まずに質問ｗ
おまいら、
スタイルシート編集ツール
は何使ってます？
539:仕様書無しさん
12/03/13 18:31:35.61
ふつーのてきすとえでぃた
540:仕様書無しさん
12/03/13 20:30:53.74
CSS用にエディタって使ったことないな
っていうか仕様書とはちがくねｗ
541:538
12/03/14 10:38:15.91
あれ、CSSってＧＵＩでグイグイ書けないんですか？
それをキャプチャーして貼り付けたら仕様書、みたいなことを考えていたのですが。
542:仕様書無しさん
12/03/14 16:10:40.53
CSS編集ツールの話題はスレ違いだよ
Web製作板の「CSS初心者スレッド＝11th＝」スレヘ逝け
543:538
12/03/14 16:32:20.70
Web製作板ね。WebProgを見て”無いな～”と思ってました。 つ ㌧
544:仕様書無しさん
12/03/14 23:33:46.33
>>542
545:仕様書無しさん
12/03/17 16:37:19.87
UMLで設計を書いている。
asterのフリー版を使っているのだけど、使いにくくて気が狂いそうだ。
546:仕様書無しさん
12/03/19 22:34:57.77
>>545
マウスアイコン近づけるだけで線引きモードになる奴か？
あれ、親切のつもりだってんだから、参るよ。
547:仕様書無しさん
12/04/18 20:33:01.78
ｘｘ設計とか、設計書フォーマットが標準化されてくれりゃいいのになぁ
548:仕様書無しさん
12/04/18 20:34:14.04
ｘｘ設計とか、
↓
xx設計とかの呼称や、
各々が考えてるレベルが食い違いすぎてて、すれ違い多かったり認識あわせが面倒だったりで
全くいいことないわ…
549:仕様書無しさん
12/04/28 11:58:14.08
詳細設計と基本設計のメジャー2つの範囲ですら人によって違うって変な話だよな
っていうか、詳細とか基本みたいな概念で分けようとしてるのがそもそもおかしいんじゃないか
550:仕様書無しさん
12/04/29 16:10:07.02
仕様が決まってないうちに作り始めたものなんて大抵ろくなもんじゃないよな
つまり、仕様書の仕様が決まってないから、ろくでもないものしか作れないのは至極当然のこと！
551:仕様書無しさん
12/04/29 22:29:39.25
自分で仕様書書くよね、普通
552:仕様書無しさん
12/05/04 11:08:21.59
仕様書というか通信仕様や状態遷移は書くけどね。
会議で了承とかはとらない。
承認をとろうとDRをやっても、あげあし取りばかりで
開発期間が短くなるだけ。まぁ潰れるだろうな。
553:仕様書無しさん
12/05/04 11:37:25.60
<Sale>中国語版の書籍<文系・理系・ＩＴの諸分野>(格安) 280円より
URLﾘﾝｸ(lang-8.com)
554:仕様書無しさん
12/05/04 12:09:30.10
>>550
最近は仕様が固まる前から作り始めないと
間に合わない鬼畜納期の案件が多いよ。
555:仕様書無しさん
12/05/04 12:18:52.12
仕様書設計書程、意味わからんものないな
行く場所行く場所で作法が違うw
まともなところは普通に作れるが、
今いるところだと要件定義が２行くらいしか書いてなかったり
しかも書いた奴が２年前に退社してるとか・・・・
そこから基本設計、詳細設計まで落とすのは苦しいわけで
つか何年前に始まったプロジェクトなんだよとツッコミ入れたくなった
556:仕様書無しさん
12/05/04 16:37:48.84
仕様書で、同じ事柄を指す表記がまちまちなのはやめてくれんかね？ と思うことがある。
557:仕様書無しさん
12/05/04 21:24:48.28
昔の大規模システム開発だと用語定義から始めたりしたんだが
まあ設計２年とか普通にあったからなぁ
558:仕様書無しさん
12/05/04 21:40:24.68
お作法レベルのものじゃなくてもっとグローバルスタンダードなものがほしいよな
この業界の無駄な仕事がかなり減って、残業も減ると思うわ
それで損する奴なんて、いるとしても能無しと中抜きしてる奴くらいだし
559:仕様書無しさん
12/05/04 21:43:42.33
>>556
とりあえずプロジェクト開始時につけた名前と、マーケティング的な都合でつけられた名前と、
ソースコード上の名前がバラバラってのはよくあるw
マーケティングの話とか現場まで伝わってこないから、上の人たちが話してるのを
「俺には関係ないや」とおもって聞き流してると、実は自分が担当してる機能の仕様変更
の話だったりしてあとで慌てる。
560:仕様書無しさん
12/05/04 21:59:08.48
>>557
基本設計書レベルでも今の詳細設計より詳しかったりするからね。
561:仕様書無しさん
12/05/06 11:57:21.57
機能設計:UI設計(ユーザー及び外部装置からの入出力を伴う機能及び画面設計)と、
詳細設計:データ構造、モジュール間IF設計
だと思ってた。
本当に場所によってバラバラなんだね…
562:仕様書無しさん
12/05/06 21:54:13.90
ばらばらだって事に気づいてない奴がリーダーとかやってるとマジ糞
俺の知識が正しいを信じてるからな
563:仕様書無しさん
12/05/07 11:35:37.42
>>561
ビジネスロジックはUIじゃないだろ
564:仕様書無しさん
12/05/07 11:43:07.65
UIから作るのはまずい手だと私の設計の教科書は言ってる。
565:仕様書無しさん
12/05/07 14:14:27.00
プロトタイピングという言葉がなかった時代の教科書か
566:仕様書無しさん
12/05/07 14:38:04.43
プロトタイピングって、ハリボテを拡張していくことじゃないと思うんだ。
567:仕様書無しさん
12/05/07 15:30:28.23
UIに噛みついてる奴、まともな意見がないな
568:仕様書無しさん
12/05/07 15:35:40.23
では、まともな意見どうぞ
569:仕様書無しさん
12/05/07 15:57:14.87
友愛に噛みつくのですか？
570:仕様書無しさん
12/05/07 21:56:25.92
プロトタイプは所詮ハリボテなんだから途中で捨てないといけないんだけど
現実はハリボテという砂上を拡張して製品作っちゃうんだよな
571:仕様書無しさん
12/05/08 00:14:17.41
楼閣の方はどうするの？
572:仕様書無しさん
12/05/08 07:41:52.38
>>570
プロトタイプなのに細部に凝り始めるとヤバイ
トリガーとフィードバックのデモ程度で良いのに
573:仕様書無しさん
12/05/11 01:59:24.95
仕様書に書かなくてもいいことまで書かないといけないルールがあったりするのがクソ
まともな内容ならむしろ作るほうに賛成なんだけどな
リファクタリングで変わるような内容まで設計書として作成するとかアホ
コードからじゃ判断できないもう少し外から見るための情報をメインに書かないと意味ないだろ･･･
574:仕様書無しさん
12/05/11 02:10:39.19
>>573
誰に見せるのか、何の目的で作るのか
ここがキッチリしてないと飛んでも無いものが出来上がるよな…
575:仕様書無しさん
12/05/11 02:29:28.88
お前等見ても結局理解しないだろ
んならそれはソースの中の情報で留めておいても問題ないじゃねーか
ってレベルの内容ですら書けっていうこともあったりするからな
仕様書設計書のグローバルスタンダードが欲しい
576:仕様書無しさん
12/05/18 00:01:40.17
テレビ番組の制作では、視聴者の知能を小学校低学年程度と想定して作るそうだけど
詳細設計書も作ってると、なんかそんな感じの気分になってくる
これなしでもだいたいのプログラマはコード書けると思うんだけどなあ・・・
577:仕様書無しさん
12/05/18 09:20:29.77
詳細設計書＝日本語で実装だからなぁ～
あとは日本語からプログラミング言語（あるいはバイナリ）に変換できれば
ソフトウェアが出来上がるようになるのが理想なんでしょう
578:仕様書無しさん
12/05/18 15:51:40.57
>>576
馬鹿にわからないことは書かなかったりウソ書いたりするから
そういう状況で詳細設計の有無とコード書けるかは関係しないと思う
むしろ有ると詳細設計に縛られるせいで実装の難易度が上がることが多い
>>577
詳細設計からコード精製できるぐらい細かい事書いたら
詳細設計を要求する人には読めない複雑な代物になる
特に障害時の処理を漏れなく書くと怒られる
オフショアとかだとうまく書くんだろうけど俺には想像つかない世界
579:仕様書無しさん
12/05/18 23:17:32.06
> 詳細設計を要求する人には読めない複雑な代物になる
詳細設計を要求する人っていうのは
プログラマだよ。
プログラマがコードで書いているものを
読めないわけがないじゃないｗ
580:仕様書無しさん
12/05/19 02:07:08.39
オフショアはだいたいゴミだよ
あの手この手つくしてごまかして成り立ってる
コーダーはできる連中多いけど、橋渡ししてるところがクソ
581:仕様書無しさん
12/05/19 09:17:38.12
>>579
プログラマにプログラムレベルの仕様書見せるなら、自分でプログラム書いた方が早いから意味ないだろ。
かと言って、プログラム組めない奴にプログラムレベルの仕様書見せても理解出来ない。
大いなる無駄なんだよプログラムレベルの仕様書っていうのは。
582:仕様書無しさん
12/05/19 09:58:14.71
>>581
なんで仕様書の話になってるんだよｗ
馬鹿じゃないのか？
583:仕様書無しさん
12/05/19 11:25:50.90
徹夜で詳細設計書書いて出したけど、どうでもいいところばっかり増やして
肝心なところは仕様わかんねえから抽象的なことに終始した
自分で言うのもなんだが、あれじゃプログラム組めないな
584:仕様書無しさん
12/05/19 11:43:55.35
そりゃそうよｗ
コードの内容を省略して書こうとしても絶対に無理。
コード＝設計なんだから省けないものを省けるわけがない。
585:仕様書無しさん
12/05/19 11:44:35.84
あれをみて、プログラムを書くのではなく
あんな方針で、プログラムを書く。
方針が書いてあれば良い。
586:仕様書無しさん
12/05/19 14:58:33.24
むしろコードに関わる内容が書いてある仕様はクソ
出来ないコーダーにはそういうの渡さないとクソコード上げてくるから難しいとは思うけど
機能のIFなりI/Oなりが変わらないようなコードの修正が、
仕様書の修正を引き起こすような内容で設計書に記載されてたら、基本的にそれらは全部ゴミ仕様書だわ
設計図じゃないんだからそんなに事細かに書く必要なんかない
2重管理するハメになって、管理できずに放置されてゴミに変わるのが目に見えてる
587:仕様書無しさん
12/05/19 16:12:15.98
コードを書くまえに仕様書があるのは
当然のことだが、その当然を妨害するものが多すぎる
仕様書の何が嫌だって、
気分屋の上司どものお伺いをたてて
承認をとらなきゃいけないこと。
有意義な指摘なら受け入れるんだが
どうでもいいようなことを指示して、それがしかも曖昧だったりすると
真面目につきあってたら、納期までに仕様書すらあがらない。
588:仕様書無しさん
12/05/19 16:22:44.89
仕様書と設計書をごっちゃにしてないか？
仕様書が無いのに作るとかあり得無いだろ
589:仕様書無しさん
12/05/19 17:17:04.54
設計って、プログラムレベルの設計の話してんだよな？
詳細仕様書的な物の話だろ？
なんか、何人か噛み合ってなくね？
590:仕様書無しさん
12/05/19 21:22:49.51
設計はお客さんに見せたってしょうがない。
プログラマにとって必要な物が設計だ。
プログラマがゴミと言ったらそれはゴミでしか無い。
591:仕様書無しさん
12/05/20 11:43:48.55
>>587が言ってるのは設計書そのものではなくレビューに関する愚痴なので、要否ではなく日記だな
592:仕様書無しさん
12/05/20 22:59:12.54
仕様書って、作るのしんどいわりにスキル的に得るものがないな
593:仕様書無しさん
12/05/20 23:20:05.32
>>592
他のところでも同じフォーマットでやれるなら、それなりに得るものはあるかと。
それ以上に、得たものをどう活かすかの方が大切なことですよ。
594:仕様書無しさん
12/05/20 23:22:36.32
> 他のところでも同じフォーマットでやれるなら、
それはない。やるのなら、自分がPMとして仕様書のフォーマットまで決める権限持たないと無理。
595:仕様書無しさん
12/05/21 06:18:45.79
フォーマットがあればいいけど、それすらない俺の職場は
596:仕様書無しさん
12/05/21 07:14:30.81
仕様書はそもそも使う側、若しくは作る側との決め事を明確にするためにあるんだから労力関係無く無きゃ駄目
それに受け入れテストや品質管理上、作る側は実装の責任範囲の保証にもなる
無いとグダグダで無限ループのデスマ地獄になっちゃうよ(ノД`)
597:仕様書無しさん
12/05/21 18:04:44.00
>>596
仕様書があればそうならない環境であれば多分無くてもそうはならないよ
598:仕様書無しさん
12/05/21 18:18:29.30
>>597
そういうことじゃないよ。
仕様書がなければそうなる場合でも、仕様書があればそうならない場合もあるということ。
言い換えると、
仕様書があったためにそうならかった場合、仕様書がなければそうなる場合もあるということ。
599:仕様書無しさん
12/05/22 00:26:22.53
>>598
> 仕様書がなければそうなる場合でも、仕様書があればそうならない場合もあるということ。
これマジか
どちらかというと仕様書を曲解されるせいでグダグダで無限ループのデスマ地獄のイメージだが
600:仕様書無しさん
12/05/22 00:32:36.45
>>599
ハッキリと言っておこう、仕様書を曲解されるとかあり得無い、嫌、あってはなら無い事だからな
コミュニケーション力が低いじゃ済まされ無いですよ
仕様書も設計書も、「伝える」事の為にあるという事をきちんと考えていきましょうか
601:仕様書無しさん
12/05/22 01:53:54.69
書く方はわかりやすく誤解をうまないように書くべきだし、読む方は読めるだけの予備知識と読解力が必要。
どっちがかけてもうまくいかないので、両方揃ってるのが理想。
でも、実際にドキュメントだけで作業を渡すと非効率。
ドキュメントとは別に、分担部分の概要を伝えて、一部を作って見せるのが望ましい。
ドキュメント読めって突き放す奴は無能。
602:仕様書無しさん
12/05/22 10:53:38.81
>>600
書く側に多くを求めるのは難しいんじゃないかな
待遇的に考えて
>>601
読む側に悪意がないこととそもそも読む気がある、も必要
603:仕様書無しさん
12/05/22 22:05:14.12
>>589
それな
実際仕事の現場でもよく見るけど、XX仕様書のレベルが
職場というかもはや人単位ですら微妙に異なってるから、ちょっとしたことのすれ違い多くてめんどくさいわ
いいかげん共通規格が必要だと思うわｗ
604:仕様書無しさん
12/05/22 23:08:05.36
>>603
2chはいつもここに気づくまで会話がかみ合わなくて、気づいたところで終わるんだよなw
そしてまた同じ会話をはじめるw
605:仕様書無しさん
12/05/24 22:15:30.49
クラス図はいいけど
他はあんまり役に立たない気がする
606:仕様書無しさん
12/05/24 22:59:28.59
要件すら定義されてない機種のコードをどうやって書けばいいんだよ？
俺は最底辺なのに、なんで製品の動作の責任までとらされるのか
607:仕様書無しさん
12/05/24 22:59:50.07
ステートチャートは捗るぞ
608:仕様書無しさん
12/05/25 13:41:41.18
>>606
コード書けまではないけど要件定義前にステップ数出せってのはある
609:仕様書無しさん
12/05/25 14:15:28.15
あるな…
610:仕様書無しさん
12/05/25 15:06:07.34
で、2,000行1人月な、的な話もちょっと前まではたまにあった。
だから逆算して行数を出すことにしてた。
611:仕様書無しさん
12/05/26 11:30:11.77
そもそも行数なんて今日日なんの意味もないことが明白だのに、いまだ使い続けてるあたりがアレだよなぁ
612:仕様書無しさん
12/05/26 19:03:42.37
俺が三角関数や微分方程式を駆使して数値を出す計算式を1ステップで書いたら、
何も仕事してねえとか言われたよ。
先輩は単純な放物線を求めるだけで50ステップ以上。
単純な数式をあんなスパゲティでピラミッド構造に作っていたら、修正とかとんでもないことになると思うんだが。
613:仕様書無しさん
12/05/26 19:45:40.20
>>608
なんでそんなの出るんだよ
バッカじゃーんって出せって言った奴に言ってみればよくね？
614:仕様書無しさん
12/05/27 00:28:17.84
洋服に付いている洗濯方法の絵表示が全面変更される。経済産業省は、
日本国内だけで使われている日本工業規格（ＪＩＳ）表示を２０１４年にも改正し、
国際標準化機構（ＩＳＯ）が定めた国際規格にそろえる方針。
ＩＳＯ規格は欧州などで普及している記号がベース。大きな変更点は、洗いの表示から
「洗濯機」がなくなり、「たらい」に統一されること。手洗いは、たらいに手を浸した
絵で表す。
乾燥方法の表示は「服」や「手絞り」の絵が廃止され、「四角」に一本化。乾燥機使用
の表示は「四角の中に丸」。自然乾燥は「四角の中に棒」となる。
URLﾘﾝｸ(alp.jpn.org)
615:仕様書無しさん
12/05/27 18:39:27.91
>>612
分解がめんどくさいコードは一長一短だけどなー
コスト差ないなら、馬鹿がコードに触る可能性がある場合はあえて崩して書くこともある
まぁその先輩()とやらがやってたのはクソコードなのはなんとなくわかるｗ
ステップ数が多い、ってのは、仕事してるんじゃなく大半はただ無駄が多いだけだからな
616:仕様書無しさん
12/06/17 16:13:44.20
公開メソッドの多いクラスなんかのコードだと、行数の1/3はコメントだったりするわ…
ステップ数で仕事量測るくらいなら、ツール使ったユニットテストのケース数とか数えたほうがまだ幾分かマシ
617:仕様書無しさん
12/06/18 01:38:39.32
無駄な仕様書を減らして、有用な情報だけを残すにはどうすればいいのか…
「既存」の呪いを解呪できるアイテムの実装が必要？(´・ω・｀)
618:仕様書無しさん
12/06/18 09:39:09.74
デスマプロジェクトで、詳細設計書が顧客にボロクソに言われて全面修正してるのに
他所で作ってるそこのプログラムは完成して、客にも渡したみたいなんだけど、どういうことなの
619:仕様書無しさん
12/06/18 10:50:08.03
コードに合わせて詳細設計書を修正しろってことだろ。
620:仕様書無しさん
12/06/18 13:30:18.11
>>617
術者を○す
621:仕様書無しさん
12/06/18 23:42:10.71
世の中にはびこる負の遺産や呪いの術者を殲滅することが次の世代のマに託されてる…？
622:仕様書無しさん
12/06/19 14:33:23.74
>>618
根回し重要
623:仕様書無しさん
12/06/19 22:32:12.33
物の品質よりそういうところが重要ってあたりが、土方くさくてやんなるな
624:仕様書無しさん
12/06/19 22:54:27.82
とりあえず納品物に仕様書を要求するんじゃなくて読み安いコードを要求するようにしろや
品質に直結してウハウハだぞ
625:仕様書無しさん
12/06/21 10:44:31.63
>>624
コードくれないところ多いよ
626:仕様書無しさん
12/06/22 04:52:34.33
要求が曖昧なら
どういう資料作っても無駄になるだけでしょ
627:仕様書無しさん
12/06/22 04:57:00.54
プログラム読めない系の人が完成後に
資料、資料
って騒ぐみたいだよ
628:仕様書無しさん
12/06/22 06:38:29.74
>>627
そういう人が欲しいのは、仕様書設計書じゃなくて、多分操作マニュアルが
欲しいんだろうね。
629:仕様書無しさん
12/06/22 19:23:22.84
大工さんに、家の作り方を一から書いてください的な、資料？
630:仕様書無しさん
12/06/22 22:20:11.84
いいえ、他の大工さんが仕事を引き継げるような資料です。
631:仕様書無しさん
12/06/22 22:43:08.90
それ、設計士が図面書いた時点で終わってるでしょ
図面通りじゃないところぐらいじゃ、必要なのは
632:仕様書無しさん
12/06/22 23:06:34.32
引き継ぎどころか、一緒にやってるメンバーでさえ見ない(見てもわけわからん)
資料を大金かけて作ってるわけだが。。
633:仕様書無しさん
12/06/22 23:08:13.94
SEという人種が要求を噛み砕けんから、おかしくなるんじゃねえの？
客の太鼓道程度じゃ、そのうち...
634:仕様書無しさん
12/06/22 23:08:42.06
>>631
一般的に設計士は、どういうものを作れという資料しか作らないので、
どうやって作ったかの資料が必要。
635:仕様書無しさん
12/06/22 23:11:19.12
>どうやって作ったかの資料が必要。
はあああああああああああああああああああああああああああああああ
ソースが読めません系？
636:仕様書無しさん
12/06/23 00:08:18.24
>>635
なんで資料残しとけば節約できた無駄な工数かけてまでソースを解読しないといけないんだよ。
趣味でやってるんならソース読めで済ませられるけど、職業人でそんな態度なら初心者だね。
637:仕様書無しさん
12/06/23 00:14:10.78
ソースが読めないから工数がかかるって言ってるような
638:仕様書無しさん
12/06/23 00:36:50.60
ソースしかないけどよろしくっていうプロジェクトの場合、
普通システム解析の工数を計上するだろ。
工数計上しなくて済むのは、数千行程度の極小さなプログラムのときくらい。
639:仕様書無しさん
12/06/23 00:38:42.65
読めないのに、ソースの間違い探しができるのかい？
640:仕様書無しさん
12/06/23 00:42:17.75
うん、ソース読めるからソース読む工数を計上してるんだね。
641:仕様書無しさん
12/06/23 02:22:41.06
書けるのに読めません系が作る完成後の資料ってどういう内容なんだろうね？
読めません系が集団の職場って？
642:仕様書無しさん
12/06/23 13:10:25.03
>>641
世の中には驚くほど文章を読めない人が多い。2chの3行以上のレスは
読まないってのがネタじゃなくてマジな奴が普通にいるし、Twitterの
140文字ですら読めてるか怪しい人が数多くいる。
643:仕様書無しさん
12/06/23 16:20:17.99
仕様書に明記してあれば数分で済むロジックの目的を、
ソースコード上から解析して文章としての仕様にデコードするのは、面倒なケースも多いぞ
ソースと実装が異なる可能性があるから最終的にはコードを見る必要はあるとしても
それがバグなのか仕様どおりの実装なのかは、コードでしか表現されてないと判断つかない
UTがちゃんと作成されているなら別だが、
日本の土方系プロジェクトでちゃんとしたテストコードを作れてるものなんてかなりレアだし
それが出来てるところはちゃんとした仕様書、設計書に値するドキュメントもある
644:仕様書無しさん
12/06/23 16:27:15.12
>>643
仕様的に欲しいのは入力に対する結果であって経緯ではないから。
645:仕様書無しさん
12/06/23 16:31:17.44
そもそも、有用なドキュメント残せないようなプロジェクトのコード自体信用できるわけねーしな。
何をやりたかったかっていう目的はにコードだけじゃ判別つかん。
コードが絶対だ、既存だからバグじゃないっていう、糞コーダーの言い訳と同じ。
646:仕様書無しさん
12/06/23 17:24:21.80
なぜ、仕様書作成に時間を割きながらして、ソースコードはスパゲッティなのかが腑に落ちない。
設計からしてめちゃくちゃな可能性があるけど。
647:仕様書無しさん
12/06/23 17:35:09.87
単純な話で、何の意識合わせもなく多人数で手分けしてつくるからだよ。
648:仕様書無しさん
12/06/23 18:03:33.39
スパゲッティになるのは単純に知識不足だと思うな。興味が持てないから知識が増えないんだろうけど
好きこそ物の上手なれってやつ
よくある系のアルゴリズムについての知識だったり、言語仕様的な通例や制約をしっているかどうかだったり、
デザインパターンみたいなのを知ってるかどうかだったり、こういう差がスパゲッティを作らないうえで重要だと思う
経験から、どう書いてあると後から見るのが大変か、どうなってると後から修正とかしやすいか
なんかを学んでいくだけでもマシにはなるけど、職場が同じようなレベルのとこばっかだと
視野が狭いままで、そんなに学べることは多くない場合が多い
仕様書設計書の話題ではないけどなｗ
649:仕様書無しさん
12/06/23 18:13:52.30
スパゲッティになるのは仕様書作成に時間を掛けすぎて、
ソースコードを書く時間が足りないからだよ。
本来なら十分な時間を掛けて、
ソース設計→ソースコードを書く→リファクタリングをやらないといけないのに、
スキルに対して納期が短すぎて「ソースコードを書く」部分だけをするから
スパゲッティになるのは必然。
650:仕様書無しさん
12/06/23 20:56:29.84
ソース設計ってより
何作るかわかってないから、ワケワカになるじゃね
問題に対する読解力が足りないと数学解けないのと同じ感じ？
651:仕様書無しさん
12/06/23 23:02:28.11
仕様書作りとコーディングが同時に動いてる現場って少なくないけど
そういうのに放り込まれると、本当このEXCEL方眼紙に書きなぐってるものは何なんだろうなって思う
652:仕様書無しさん
12/06/23 23:39:07.55
クソ仕様書から正確な仕様書を書く作業から始まる
653:仕様書無しさん
12/06/24 01:08:52.21
昔からバグのまったく無いプログラムは作れないといわれているが、
実際には、バグのまったく無いプログラムは見たことあるが、
バグのまったく無い仕様書は見たこと無いw
654:仕様書無しさん
12/06/24 01:23:50.99
>>652
地味にそういう事からやるほうがいいんじゃね
余裕があるならコーディングしながら矛盾点を洗い出していくとか
655:仕様書無しさん
12/06/24 03:30:05.08
>>652
だいたいそれやってるけど、必ず既存のバグ見つかってアレ
656:仕様書無しさん
12/06/24 10:19:20.59
>>655
たしかにそうだけど、それは仕様書再作成作業による机上バグ摘出という成果であると
前向きに考えているよ
657:仕様書無しさん
12/06/24 14:32:24.06
>>656
コンパイラができること（エラーチェック）を脳内でヤルわけですね？
658:仕様書無しさん
12/06/24 14:41:26.41
コンパイルできることと、バグが無いことは違うよ？
659:仕様書無しさん
12/06/24 14:49:36.03
テストがあることと
バグがないことも違うよ。
660:仕様書無しさん
12/06/24 15:39:55.23
>>657
何を言いたいのか意味不明なんだが、もしかすると>>657はコードと
一対一に対応するような設計書(仕様書???)を書いているのか？
それとも>>657のコンパイラとは、
Z/VDM/CSPのような形式的仕様記述言語の検証系を指しているのかな？
まさかコンパイラが(構文エラー以外の)論理的なバグまで検出できると本気で思っているの？
訳が分からんわwww
661:仕様書無しさん
12/06/24 15:51:32.09
>>660
”コンパイラができること” ってちゃんと書いてますよね？
コンパイラができないことが、コンパイラできるなんて
どうしてそんな変なことを言い出してるの？
662:仕様書無しさん
12/06/24 16:17:42.24
>>661
>”コンパイラができること” ってちゃんと書いてますよね？
>>657では、「ちゃんと」書いているつもりなのか？
自分は、”コンパイラができることを” とは構文エラー検査であり、
"脳内でヤル" とは(>>656の)仕様書再作成作業のことだと解釈し、
「構文エラー検査を仕様書作成作業内でヤル」という>>657の発想が意味不明だと>>660で書いた
もしもこの解釈が間違っていたのなら教えて下さいませ
あと、仕様書再作成作業の前に全コードをコンパイル通過させておくのは、常識だと考えているよ
663:仕様書無しさん
12/06/24 19:37:25.95
コンパル時にエラー出ても読まない、わからない人が仕様書書くことがあるからね
664:仕様書無しさん
12/06/24 19:38:10.50
×コンパル時
○コンパイル時
665:仕様書無しさん
12/06/24 20:25:56.27
こんぱそ時
666:仕様書無しさん
12/06/24 23:39:28.20
>>663
それって>>657のことかしら？
667:仕様書無しさん
12/06/24 23:46:19.00
リアル会社でそういう人がいたんですよ
コンパイルのエラーって何？
って、感じの人が
668:仕様書無しさん
12/06/25 06:24:49.76
またまたご冗談を
669:仕様書無しさん
12/06/25 06:43:59.74
PC触ったことない、持ってないようなのも
口がうまければ普通に入ってくる業界だからな
670:仕様書無しさん
12/06/25 20:56:34.12
20世紀末ごろのエラーメッセージが英語の頃はなにそれが普通だった
エラーメッセージが日本語化されてもなにそれは状態な人がいっぱいいそうだけど
671:仕様書無しさん
12/06/26 02:43:52.29
エラー出た、で思考停止する馬鹿は結構いるぞ
まじ辞めればいいと思うわ…
672:仕様書無しさん
12/06/30 03:05:17.20
工数稼ぐためにそういう人達が完成図書みたいなの作ってるんかね
673:仕様書無しさん
12/06/30 21:27:28.45
>>671
赤バッテンのアイコンでエラー表示するとパニクって思考停止するヤツが
後を絶たないので黄色の警告アイコンにしてやったwwww
674:仕様書無しさん
12/06/30 21:32:56.59
シイタケ？
675:仕様書無しさん
12/07/03 02:36:38.73
｢我々は高い技術力を持っている｣｢業務ソフトを開発した経験がないとわからないだろ｣が口癖のガイキチは、
グローバル変数とローカル変数の違いもわからず、
それこそプログラマ1年目でも小学生でも簡単に作れるようなサンプルプログラムを作らせてみたら
思った通り一目で動作しないとわかるものを出して来やがった。
676:仕様書無しさん
12/07/03 20:31:28.12
資料だって言ってる割には、時代についていってないような書き方だけが伝承されてるだけだったりして
677:仕様書無しさん
12/07/13 01:47:24.24
＞仕様書再作成作業の前に全コードをコンパイル通過させておくのは、常識
何言ってんだこいつ。
678:仕様書無しさん
12/08/22 00:52:30.02
メンテナンス出来ない/しにくい仕様書はいらんな～
679:仕様書無しさん
12/08/23 17:15:51.25
うちの画面仕様書びっくりするほど横長だった。UXGA×2枚、SXGA×1枚でおさまりきらない。
書くのも大変だけど見るというか読むのも大変そうだ。
680:仕様書無しさん
12/08/23 19:05:10.57
まるでWindows8のスタート画面みたいだな。
681:仕様書無しさん
12/08/24 00:27:36.99
今日気がついた。仕様書を書いてるときってかなりコピペしてる。
似たような記述が仕様書にいっぱいちりばめられてる。
仕様変更時にこれを全部メンテする自信はまったくない。
682:仕様書無しさん
12/08/24 13:14:29.14
ソースコードの解読が容易な案件は仕様書なくていい。
糞みたいなソースコードの案件は、仕様書も糞。
仕様書いらね。
683:仕様書無しさん
12/08/25 00:01:23.36
>>682
ソースコードの解読が容易だが
バグが含まれているコードの場合はどうなるんだ？
684:仕様書無しさん
12/08/28 18:59:19.16
>>678
メンテしやすい仕様書ってどうやったらできるんだろう？
685:仕様書無しさん
12/08/28 19:46:59.05
使うためのマニュアルをメンテとかならわかるんだけど
プログラムのプの字もわからんでもやれる虎の巻みたいなのが欲しいだけなのかな
686:仕様書無しさん
12/08/28 20:12:03.95
仕様書は上司と実際に作った俺の頭の中にしかなく、
しかも上司が実装可能と考えていた仕様はほとんど実装不可能で、大幅に改変せざるを得なかった。
にもかかわらず上司の初期構想の仕様書しかなく、俺にはそんな時間はなかったため
引き継いだ奴らが実装をわからずメンテナンスしたためにとんでもないスパゲティに。
コメント文で仕様書の実装は不可能なのでこう実装したと全て書いたんだけどなあ。
687:仕様書無しさん
12/08/30 09:18:06.05
>>685
仕様変更あったときに楽に間違いなく書き直せる仕様書であってほしいってことじゃね？
688:仕様書無しさん
12/08/30 16:05:00.50
>>687
仕様書直したら、ソースが直ると、思ってるとか？
689:仕様書無しさん
12/08/30 16:07:07.41
回路図方面の解説書とか見たことないなあ
見れるのは図面とやれることが書いてあるもんぐらい
690:仕様書無しさん
12/08/30 16:12:05.41
ソース直してると仕様の漏れが山ほど見つかる。
フィードバックするのもめんどくさいぐらいに。
691:仕様書無しさん
12/08/30 19:01:44.84
>>684
う～ん、難しいんだよね。
いま社内で仕様書の標準/統一化を進めてるんだけど、一向に進まないし…
確実に統一できそうなものは目次、表紙だけだわw
そもそも仕様書って誰のためのもの？プログラマ？ユーザー？上司？
ここをまず明確にすべきだと思うな～
それによって、どう書いていった方がメンテナンスしやすいかが定まってくると思う
けど、これも難しいんだよね～。あぁ死にたい。
692:仕様書無しさん
12/08/30 19:48:40.68
ソースの中身を検証できるようにするほうがよくねえか？
客、上司に媚びうる資料でもうけようってのならわかるけど
693:仕様書無しさん
12/08/30 20:15:15.09
>>691
> そもそも仕様書って誰のためのもの？プログラマ？ユーザー？上司？
一つで済まそうとせずに、それぞれ書き分けたほうがいい。
694:仕様書無しさん
12/08/30 20:49:05.16
書き分けるとそれぞれの内容が整合しなくてどこかでモメることになりそうな悪寒
695:仕様書無しさん
12/08/30 20:50:24.03
分けるにしても
どう分けるか考えんと
696:仕様書無しさん
12/08/30 22:25:35.19
>>691
＞そもそも仕様書って誰のためのもの？プログラマ？ユーザー？上司？
引き継ぎをする人のためのものだよ。 客側、開発側関係なく開発時に
いなかった人間に対して、5W1Hじゃないけどソースを読んだだけじゃ
分からない、ソースを読まなくても最低限のことが分かることが書いて
あればいい。 逆に言うと、ずっと生き字引並にシステムに精通したのが
面倒見てくれるなら仕様書なんていらない。
697:仕様書無しさん
12/08/30 22:52:23.45
受験の虎の巻みたいなのが欲しいだけでしょ
698:仕様書無しさん
12/08/31 01:19:12.12
ソースの改定記録残したほうが下手な完成図書作るよりマシだろうに
699:仕様書無しさん
12/08/31 02:06:46.95
>>697
受験の問題には正解があるけど
仕様書には正解はないからな。
他人の考えや決めたルールを知るには仕様書が必要。
700:仕様書無しさん
12/08/31 02:47:08.70
>>698
残すも何も、普通はVSSやCVS、Gitなんかのソースコード管理を使うはずで、
よっぽどアホなことしない限りは履歴は残る。
まあ、そのアホなことをする企業は少なからずあるし、小さい企業より
日常的に使わない大企業のSヨさんとかがやらかしてくれるけどね。
なんでSCM使ってるのに紙で別出しで台帳管理をしようとするかな、、、
701:仕様書無しさん
12/08/31 10:05:42.42
ソースコード管理すると言ってる人が
実はソース読めませんというオチが
702:仕様書無しさん
12/08/31 12:25:05.09
> なんでSCM使ってるのに紙で別出しで台帳管理をしようとするかな、、、
台帳管理を仕事としてる人の仕事を奪っちゃいけません。
703:仕様書無しさん
12/08/31 20:01:57.98
紙で承認受けないと管理したことにならない社内標準があるんだよ。
勘弁してくれ。
704:仕様書無しさん
12/08/31 20:32:11.37
電子データになってるのを知らない老害がいるの？
705:仕様書無しさん
12/08/31 21:31:51.33
もうボケが始まってて、現代でもパンチカードでプログラム書いてると思ってるんだよ
706:仕様書無しさん
12/09/01 07:15:19.81
電子データは見方が判らんし、変更しても判らない。
紙で自分のサインがある書類がなきゃ信用しない老害は多い。
そしてそんな老害は、紙の2ページ目以降が丸ごと差し代わっていることを知らない。
707:仕様書名無しさん
12/09/01 11:33:55.42
>>691
仕様書の標準化をする上で必ず議題となるのは、
•設計情報の網羅性
•誰が書いても同じ物になる記述レベルの統一性
•ドキュメント間の整合性
•ドキュメントのメンテナンス性
•作成コストおよび作成時間
•納品物件としての仕様書要求レベル
•設計するためのドキュメント
•プログラマーのためのドキュメント
•保守のためのドキュメント
•読ませる奴の技術レベル
•ドキュメント作る奴の技術レベル
•実際ドキュメントがいい加減でもプログラムはちゃんと出来たりする。
これらを考えると、結局みんなが幸せになる標準化なんて不可能って早々に気づく•••
708:仕様書無しさん
12/09/01 16:51:17.22
盗撮して御用になる元IBM社長みたいな老害がいっぱいの世の中
709:仕様書無しさん
12/09/02 03:17:23.15
大手ほど無能も多いからなー
なまじ職場は同じなだけに、技術職との開発業務に対する温度差が激しい
結局、出来ること出来ないことを理解してない層は調整とかそういうのは無理なんよ
ノウハウがないなら勉強しないといけないけど、そういうのしないでもなーなーでやって桁利するから、余計に成長しない
ドキュメントが詳細に必要になるのは、客と開発の間に人が無駄に入りすぎるせいだわなー
710:仕様書無しさん
12/09/02 03:18:44.51
なまじ職場は同じなだけに、同じような仕事に見られるけど
実際に作ってる技術職してる人と、客とのやり取りだったりドキュメント弄繰り回したりする人とだと、
開発業務って部分に対する興味の温度差が激しい
訂正しようとしてたら書き込み押してしまったよ('`)
711:仕様書無しさん
12/09/02 06:27:16.93
ちょっとスレ違い気味になるけど、日本の役所はいい加減ウォーターフォールに固執するの止めて欲しい。
役所の仕様基準の元がMILなのは良いけど、そのMILは30年以上前に改訂されとっくに廃止されてる。
かなり前からプロトタイプ推奨に変わったし、今はアジャイルやスパイラル前提だ。
ウォーターフォールの失敗を認めて非推奨にしてる。
で、アジャイル以降の場合、ドキュメントの自動化が必須なんだ。
そんな細かな修正、いちいち直してらんないから。
なのにウォーターフォールと手で作ったドキュメント求め続ける役所。
見積りの精査も出来ず、高々100行程度の改修で億払うって、ほんとバカしか居ない。
712:仕様書無しさん
12/09/02 06:38:20.92
> このため現実のウォーターフォール・モデルの開発プロジェクトでは、
> 前工程の完了要件（要件定義局面であれば、要件定義書などの成果物の完成）を
> 徹底して品質を高め、後戻りの発生率を可能な限り低下させるとともに、
> 後戻りが発生する場合は変更管理によって公式に決定し、
> 後戻りや横展開を確実にフォローする。
２０年前ぐらいなら通用した考え方だね
今の情報量は半端じゃないからね
> 要件定義
って、うるさい文系院卒がいたけど
今のコンピュータのことが全然わかってなかった
今だに、非力なパソコンの流行りはじめの事例が通用するとか思ってるんかね
時代についていけてない人は...
紙の上で終わらせたいとか？
713:仕様書無しさん
12/09/02 07:12:36.41
昔はのんびりと時間がかけられたからね。
例えば一年単位でプロジェクトを回しているところとかだと、
プログラマに仕事が回ってくるのは年度の後半(10月とか11月～)だったり
したもんだ。SEはそれまでに半年かけて文書の作成をやってればよかった。
ところが、今みたいに同じ作業を3～4ヶ月で終わらせないといけない状況だと、
文書化とコード作成を同時並行で動かさないといけないわ、期間が短い分
精度が落ちてるから手戻りが増えてるわ(しかも、ウォーターフォールだと
手戻りがやたら面倒くさい管理方法とってるから大変)で、破綻してるんだよね。
714:仕様書無しさん
12/09/02 07:28:41.54
無理に短納期にして、自分の首絞めてるだけでしょ
人月計算が時代に合わなくなってきてる？
715:仕様書無しさん
12/09/03 02:37:04.18
客と作り手の間に挟まる人数をもっと減らすしかない
716:仕様書無しさん
12/09/03 03:02:52.38
大手から下請けにっていう構図があれなんだよな
リスク回避のための保険という意味はわかるんだけど
無駄を無駄だって言える人がいればなぁ
717:仕様書無しさん
12/09/03 03:05:20.03
大手が下請けって思いたいだけなの、今や
下請けいじめとかTVで報道されて恥ずかしくないのかね、大手系
718:仕様書無しさん
12/09/03 18:12:13.96
大手とか関係なく、自社に人が確保出来ないってのは大きいよ。
常に人を確保出来るほどの仕事がある会社は少ないから、必要な時に集める。
実際、土方と同じ理由だよね。
719:仕様書無しさん
12/09/03 20:22:23.42
人海戦術が通用しなくなってきてるから、困ってんじゃないの？
短納期にこだわりすぎて
短期で仕様と設計まとめれる人いるんかい
720:仕様書無しさん
12/09/04 06:48:07.12
色々無理のある業界だよね。
本当に設計を纏められる人は一握り。
なのに短期間でのウォーターフォールだから、ドキュメントすら作るのに精一杯。
そこにレベルの下がる派遣かき集めても、OJTする時間すらない。
しかも見積りは人月の数字を舐めさえすれば安くなるから営業は無理な案件でも取ってくる。
せめて、プロトタイプ手法でも使えれば、少数精鋭でプロトタイプ作った後、レベルの下がる派遣に展開する手が使えるのに。
721:仕様書無しさん
12/09/05 16:42:22.18
人海戦術でのソフト開発は、映画作りに似てるね？
原作という要件書があっても
監督のアタマの中のイメージと絵コンテを頼りに
セット制作を指示し、本番突入で何とか試行錯誤で
作り上げる。
映画と違う点は、その後も山のようなバグ取りと運用サポートに忙殺される。
722:仕様書無しさん
12/09/05 21:00:16.80
マとSEは時間少なすぎて、残業まみれでしまいに頭おかしくなって
客はバグまみれでちょっと動かすと落ちたり計算結果が狂うシステムにイライラして
携わった人間だけをみると、Lose-Loseな状態だよなあ。こんなITで誰か幸せになってんのか？
723:仕様書無しさん
12/09/05 23:08:08.10
余裕のない状況作って、実は喜んでる人がいたりするのがなんとも
724:仕様書無しさん
12/09/06 00:42:28.17
安かろう悪かろうの需要がまだあるうちは何とかなるだろうけど、未来はないよね
725:仕様書無しさん
12/09/06 01:18:00.25
今の状況がわかってない人達が、自分で自分の首を絞めてるだけ？
726:仕様書無しさん
12/09/06 06:06:54.00
>>722
ろくな仕事もないのに仕事をした振りできる公益法人やら天下り団体の職員が喜ぶんですよね。
そういう予算だけはあるけど仕事がないところがなんでもかんでも発注するし、
使い勝手とか機能とかがでたらめな内容で発注しまくるものだから
システム開発する側もろくなものを作らず、
結果として無能の再生産をする。
727:仕様書無しさん
12/09/06 08:08:29.54
基本も詳細も設計書は顧客向けに出すものではなく、V字モデルのテスト設計資料として活用するもの
そうやれてる企業は存在しないけどｗ
顧客向けなんてマニュアルと営業パワポでいい
728:仕様書無しさん
12/09/08 11:30:54.54
このスレダメすぎ。
仕様書、設計書、言ってる地点でアウトなんだよ。
いいかげん、ウォーターフォールを滅ぼさないと日本が滅びる。
729:仕様書無しさん
12/09/08 11:50:04.08
顧客
↓
マニュアル
↓
結合テスト
↓
単体テスト
↓
コーディング
↓
仕様書
どうしてもウォーターフォールやりたいなら、こういう順序がいいと思うよ、本気で。
730:仕様書無しさん
12/09/08 12:11:47.34
「コードもないのにどうやって結合テストするの？」
とか言ってんの、もうねアホかとバカかと。
これはソフトだけの話じゃないんだよ、ハードだって開発はそういうもんなんだよ。
車の開発をしようとしたら、まずテストコースを準備する。
開発チームごとニュルに行く。
そこから始まる。当たり前の話。
731:仕様書無しさん
12/09/08 12:41:35.07
テストコースなんてどこにでもあるじゃん。
俺なんか公道でドリフトの練習しまくったよ。
字乞田けど。
732:仕様書無しさん
12/09/08 13:52:16.21
ツーホー
733:仕様書無しさん
12/09/08 13:52:42.14
面白いと思って言ってるんだろうから、そっとしておいてあげような
734:仕様書無しさん
12/09/08 15:11:28.44
「どこにでもある」
つまり、顧客環境＝開発環境が当たり前の場合、
理論と実際の誤差が生じていてもなんとかなってるんだ。
逆に、特殊環境で動かさなければならないソフトの場合だ。
そのエミュレータを手前に準備しなければコーディングしにくい。
「当たり前にないテスト環境を整えることを先にやらなければならない」
この手順を突き詰めると、ウォーターフォールの誤謬に直面する。
そこから、テスト・ファーストという考えに辿りつく。
735:仕様書無しさん
12/09/08 15:30:21.57
> そのエミュレータを手前に準備しなければコーディングしにくい。
そんな事情は考慮しない。設計どおりのコーディングをすれば、
問題なく動くコードが出きるはずだ。
736:仕様書無しさん
12/09/08 15:50:09.51
>>735
それは、ベテランの人間が小規模なプロジェクトをクリアする場合には当てはまる。
それ以上にはならない。
普通レベルの人間に真似させられないだけでなく、
高品質なプログラムにならない。
結果、顧客のダメだし確率も上がり、開発期間短縮にもならない。
リスクが高いので、趣味の範囲にとどめるべき手法だといえる。
737:仕様書無しさん
12/09/08 17:56:39.57
よく、アジャイルは、ウォーターフォールを細かく繰り返すことだと言うけれど、
その認識じゃー、うまくいかないに決まってる。
なぜなら、ウォーターフォールモデルの手順自体が真逆だから。
>>729が正しい順序なのである。
それで、アジャイルがうまくいかないと嘆くことになるんだが、
ウォーターフォールの根源的問題を繰り返したら、
もっとうまくいかなくなるのは当たり前。
738:仕様書無しさん
12/09/08 18:38:52.54
ボトムアップ的なやり方だけじゃダメじゃね
ボトムアップとトップダウンを混ぜたようなやり方のほうが
739:仕様書無しさん
12/09/08 20:07:59.54
顧客←──┐
↓ │
マニュアル←─-┤
↓ │
結合テスト←─-┤
↓ │
単体テスト←─-┤
↓ │
コーディング─→┤
↓ │
詳細設計─→┤
↓ │
基本設計─→┤
↓ │
要求定義─→┘
トップダウンとボトムアップはそうなんだけど、
実際的な流れをより明確にするとこうなる。
テスト⇔コーディングが日常。
より大枠のところで、バージョンアップだ。