[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 2chのread.cgiへ]
Update time : 10/16 11:50 / Filesize : 244 KB / Number-of Response : 935
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

仕様書、設計書について



1 名前:仕様書無しさん mailto:sage [2011/11/26(土) 11:26:56.24 ]
外部だの内部だの基本だの詳細だの…
曖昧な基準で書かれた、いろいろな名前で呼ばれてて
「これってどうなの?」「意味あるの?」といった物に出くわす事も少なくない

しかし、純粋にプログラミングだけをして食べていくことは、昨今じゃ難しく
避けて通れない、否が応でも作る機会に出くわしてしまう、そんなドキュメントたち
設計書や仕様書についても、マ視点で語ろうぜ

・自分のなかでの仕様書/設計書の呼び方と分け方
・成功談、失敗談
・仕様書/設計書は何を使って作成する?(Word/Excel/HTML/手書き!)
・仕様書/設計書に含める図の作成方法や使っているツール紹介
・炎上プロジェクトでみた(よくない意味で)素晴らしい仕様書/設計書
・そもそも仕様書/設計書って本当に必要なの?
・こんな仕様書/設計書は、ぶっちゃけアリ?ナシ?

などなど、設計書にまつわる話題を募集

341 名前:仕様書無しさん mailto:sage [2012/01/26(木) 08:34:24.44 ]
50億だかの設計料払って、それは回収しないんでしょ?
原因が東芝側なら損害賠償ものだと思うけど、
そうしないということは特許庁の問題で東芝が泥を被ったか。

342 名前:仕様書無しさん mailto:sage [2012/01/27(金) 01:12:28.48 ]
>>341
製造までいけてれば東芝はアウトだったろうけど、設計すら終わってないからな。
東芝もダメダメだったろうけど、それ以上に特許庁の担当がダメだったんだろ。
まあ、この展開だと、他の公官庁向けの大型案件に東芝は入れないだろうけど。

343 名前:仕様書無しさん mailto:sage [2012/01/27(金) 01:37:23.86 ]
管理がアクセンチュアの時点でやな予感しかしない…

344 名前:仕様書無しさん [2012/01/27(金) 08:06:06.70 ]
組み込み系開発で
設計書にRAMマップやROMマップを書いてるんだが、
ほとんど見る機会もないのに、載っける必要性ってあるの?

345 名前:仕様書無しさん mailto:sage [2012/01/27(金) 13:33:46.50 ]
お前が見ないからって、他の全員が見ないと思い込んでないか?

346 名前:仕様書無しさん [2012/01/27(金) 21:45:40.69 ]
俺も見ないぞ

347 名前:仕様書無しさん [2012/01/27(金) 23:45:08.48 ]
お前が人からシステム預かって
どれどれプログラム見てみるか、まずはメモリマップから・・・ってメモリマップねえじゃん!
って想像してみろよ、どうすんだよ
メモリマップ想像すんのか?

348 名前:仕様書無しさん mailto:sage [2012/01/28(土) 19:12:08.54 ]
仕様書書き上げるまでコーディングはさせんぞ


349 名前:仕様書無しさん [2012/01/29(日) 12:33:26.05 ]
>>347
メモリマップ見るより、コード見たほうが早くね?
それと、ほぼCとかで書いてるはずだから、システムによっちゃ
メモリマップはそれほど重要でないことが多いし



350 名前:仕様書無しさん mailto:sage [2012/01/29(日) 12:59:59.30 ]
メモリマップは誰かの頭の中だけにあります
なんて状況よりは、ドキュメントに書いといた方がいいだろ。

351 名前:仕様書無しさん [2012/01/29(日) 23:46:26.87 ]
>>349
コード見る方が遅いだろ
ROMとRAMくらいの分け方ならまだしも
「ここからここまでは揮発、ここからは不揮発」みたいなのも入ってくると大変だろ
コードにコメント書いとけってのは無しな

352 名前:仕様書無しさん [2012/01/29(日) 23:58:35.26 ]
WindowsとかPhotoShopとかの開発ドキュメントってどんなの書いてるんだろう?

353 名前:仕様書無しさん [2012/01/30(月) 22:17:22.55 ]
仕様を完璧に決めるために案件とって来た部署を徹底的に問いつめて
少しでも矛盾や未決定事項が見つかったら追い込みをかけ、次の日
朝一で顧客の所にいかせて仕様をきめさせ、持ち帰りになったら毎晩
催促の電話をさせ.... ってやってたらなんかこっちが悪者にされた。

もう仕様を適当に決めて仕様変更を下請けに吸収させた方が気楽でいいことに
きがついた。よく考えたら上流行程にせっかくいるのにわざわざ苦労することないし。

354 名前:仕様書無しさん mailto:sage [2012/01/30(月) 22:42:09.94 ]
>>353
>仕様を完璧に決めるために案件とって来た部署を徹底的に問いつめて
>少しでも矛盾や未決定事項が見つかったら追い込みをかけ、次の日
>朝一で顧客の所にいかせて仕様をきめさせ、持ち帰りになったら毎晩
>催促の電話をさせ.... ってやってたらなんかこっちが悪者にされた。

明らかに悪者だろ。


355 名前:仕様書無しさん [2012/01/30(月) 22:47:05.53 ]
>>354

そっか・・
その後の手戻りは明らかに少なく予算内にも収まったんだけどな..

今度から多少の仕様の矛盾は目をつぶることにしたいんだが、どの矛盾は
無視してよくてどの矛盾は指摘しないといけないかの見分けが一瞬でつくほどには
まだスキルがないんだよな。


356 名前:仕様書無しさん mailto:sage [2012/01/30(月) 22:59:12.84 ]
「矛盾がある・未決定事項である」ってことがわかればそれでいいんじゃね?
どっちに転んでも大した違いが無い項目ならどっちに転んでも大丈夫なように作業進めるし、
そうじゃなきゃ「決めないと作業進まないんですけど」って言ってくるだろ。

357 名前:仕様書無しさん [2012/01/30(月) 23:11:52.78 ]
>>356

確かにいわれてから決めればいいんだけど、その間2,3日下流行程を止めていることに
ものすごい罪悪感を感じちゃうんだよね..

むかし止められる立場だったこともあるからなおさら。

358 名前:仕様書無しさん mailto:sage [2012/01/31(火) 01:16:11.99 ]
きちんと回る範囲ではきっちりかっちり決めといたほうがいいし、そういう人も一人くらいは居たほうが便利だとは思う

でも人付き合いが下手な人がそれやると、できない連中から敵意向けられたりして
くだらないことで対立始めたりして、あほな気苦労増やすだけになったりするしな

上流のほうはスキルがあるのは最低条件で、人をうまく乗せたり、信頼されるようなとこが重要なんじゃないかな
結果がよくても、悪者にされたのならそのあたりが不足してたってことだと思う

359 名前:仕様書無しさん mailto:sage [2012/01/31(火) 01:34:13.11 ]
詳細設計書から要件が読み取れないのが厳しい。
目的が書かれず、手段だけ書かれても物理的な矛盾しか指摘できない。
詳細設計書が完璧な前提なら成り立つけど、人が作成する以上、ミスは避けられない。
足元だけを照らす詳細設計書じゃなくて、目的地を見据えた上で「それを実現するためにこの手段が必要ですよ」っていう
詳細設計書がほしい。



360 名前:仕様書無しさん mailto:sage [2012/01/31(火) 01:43:23.54 ]
>>359
設計者やお客さんに聞いて仕様を確認するのが本来だけど
詳細設計書を元にプログラム作るコーディング請負の仕事なら
わけわからんまま設計書に書いてあるとおり作るしかないんじゃないか

361 名前:仕様書無しさん mailto:sage [2012/01/31(火) 01:53:55.52 ]
理屈としては指摘するのがただしい。
ただ、人間は正しい正しくないだけで動くとは限らない。
言い方次第では正しく動いてくれなくなる。
相手を見て言い方や伝え方を変えたり、根回しをするなどする事も一つの技術。
仕事の成果を優先するも、自分のやり方を優先するも、あなた次第。
自分の人生に有益な戦略をどうぞ。

362 名前:仕様書無しさん mailto:sage [2012/01/31(火) 02:03:20.30 ]
>>359
>詳細設計書から要件が読み取れないのが厳しい。

それは、詳細設計書の意義から外れるのではないかと思う
詳細設計書は実装の大まかな枠組み(論理構造)を記述するもの
システムの目的/要求/前提といった事柄は、さらに上流の設計書で記述されるべきで、
詳細設計書での重複した記述は避けるべきだと考える

もしも、>>359が「詳細設計書だけ」を渡されて実装段階で悩んでいるのなら、
まずはそれを率直に上流工程の担当者に伝えて、上流の設計書を入手することを考えよう
そして、もしもその要請が拒否されたのなら(「オマヘハイハレタコトダケヤレ!!」)、
それを(証拠として)記録した上で、(>>360の言うように)そのまま実装するしかない

363 名前:仕様書無しさん mailto:sage [2012/01/31(火) 02:26:52.62 ]
普通は詳細設計書を読んだだけで、要件が分かる訳がない。
要件を満たすために処理をそれぞれ分解して詳細設計書に落とし込んでいるはず。
きっちりと部品化して設計されていれば要件を知ってる必要ない。
そんなに要件が知りたいなら、要件定義書を見せてもらえばいい。

364 名前:仕様書無しさん mailto:sage [2012/01/31(火) 05:32:00.34 ]
>>357
未決定事項があれば
依頼側にそれらの情報をいつまでに出せるのかをヒアリングして、
製造側にそれで作業スケジュールに問題が出ないかをヒアリングして、
その結果を整理してスケジュール決めてくのも仲介役のお仕事。

もし一件未決定事項があるだけで作業が何日も止まるようなら、
そもそもそんな作業スケジュール(というよりワークフロー?)がおかしい気がする。

365 名前:仕様書無しさん [2012/01/31(火) 07:23:51.68 ]
>>358

できないというか決めないといけないことをそもそも理解していない部署に
その必要性をわかってもらう柔らかい言い方ってどういうんだろうな..

どんな言い方しても相手の考慮不足を指摘している以上反発は食らうわけで
しかものんびり待っていたら1ヶ月以上ほっておかれた過去の経緯もある。

これが組織間の板挟みって言うならそうなんだろうけどなんか違う気がする。


366 名前:仕様書無しさん mailto:sage [2012/01/31(火) 11:35:44.82 ]
上長を通じて申し立てる。
個人で動くべきでない。

367 名前:仕様書無しさん mailto:sage [2012/01/31(火) 23:29:21.14 ]
>>365

> どんな言い方しても相手の考慮不足を指摘している以上反発は食らうわけで

考慮不足=ちゃんと考えろやボケェ!
ってニュアンスになってない?

「このあたりの仕様が抜けてるような気がするんで、いついつまでに確認お願いできませんかね〜?(∀`*ゞ)テヘッ」
ってな感じでアプローチしたら、そんなにモメないような気がする。経験上。

そこで決まらなかったら、後は野となれ山となれ〜だよ。
エビデンスだけは押さえといてね。

368 名前:仕様書無しさん mailto:sage [2012/02/01(水) 00:00:22.13 ]
毎日、朝と晩に呼び出されて催促されたら、その担当者が鬱病になっちゃうぜ。
お客さんの事情もあるし、すぐに回答できない質問事項もあるだろうよ。

質問の仕方も
「どうするんだ!?」っていう相手に丸投げの質問するより
「A案とB案のどちらにしますか?」って質問した方が
相手を誘導しやすいし、回答を得やすい。
相手に案を提示できるようになるには、それなりの能力が必要だけどね。

369 名前:仕様書無しさん mailto:sage [2012/02/01(水) 00:27:31.85 ]
「A案とB案のどちらにしますか?」
客「良くて安い方」




370 名前:仕様書無しさん mailto:sage [2012/02/01(水) 00:36:13.06 ]
そんなこまめに催促したって、体が二つになるわけじゃ無いんだから、スケジュールのネックになる事を伝えて優先度つけて作業してもらえば済む事だよな。
それで全体が遅れたらそれはそれで仕方がないよな。
自分に非がないと攻撃しちゃうタイプなのかな?無意識?

371 名前:仕様書無しさん mailto:sage [2012/02/01(水) 02:08:37.57 ]
>>370
世の中には進捗表に優先度の項目があるけど、それが全て高になっている
プロジェクトもあるわけなのだが。

372 名前: 忍法帖【Lv=3,xxxP】 mailto:sage [2012/02/01(水) 04:20:31.74 ]
アプリの質にもよるが、推奨案まで持って行けたらベストだわね。
決められない人たちに判断基準を示してあげるのも大事だと思うよ。

上流でやっとけや!(#゚Д゚)って話はあるがね。。。

373 名前:仕様書無しさん mailto:sage [2012/02/01(水) 08:53:43.17 ]
>>371
俺も見た事あるけどさw
スケジュールの足引っ張る項目を伝えればさすがに優先してもらえるし、ぶつかってたらマネージャーが仕事する番だろ。

374 名前:仕様書無しさん mailto:sage [2012/02/01(水) 08:55:04.48 ]
>>372
こっちが考えてやると、次から当然の様に仕事押し付けてくるってのもあるなw

375 名前:365 [2012/02/01(水) 23:53:42.85 ]
>>368

たしかに担当者を追い込みすぎる癖があることはわかってる。
特に担当者が最初に「何でそんなの決めないといけないんだ」的な
反応をしてきたときに、徹底的に追い込んだことは何度かあるな。

コミュニケーションスキルは本当に難しいな


376 名前:仕様書無しさん mailto:sage [2012/02/02(木) 00:03:28.03 ]
気持ちは分かるがやっちゃだめだ。
頭にきても手を出しちゃいけないのと同じだ。

377 名前:仕様書無しさん mailto:sage [2012/02/02(木) 00:34:12.11 ]
足ならいいか!?な?

378 名前:仕様書無しさん mailto:sage [2012/02/02(木) 01:11:29.64 ]
反感をもたれるような持ち掛け方をしてるか、
既に嫌われてて煙たがられてるかのどちらかって可能性もある

慕われるように仕向けて、自分からやっとこうって思わせれるようにしたほうがメリットあるのにね

379 名前:仕様書無しさん mailto:sage [2012/02/02(木) 01:24:48.60 ]
>>360
>>362
レスありがとう。
実際それが正論で、そうあるべきだと思う。
けど、(今の現場では)詳細設計書が基本設計書を満たしているか否かのチェックが機能していないんだ。
詳細設計〜テスト実施にかかわる人が要件を把握できれば、詳細設計書の漏れや、要件の漏れがある程度チェックできるはずだけどその工数は
なかなか認められない。けど、請負う側はそのリスク(要件の漏れや、詳細設計のミスによる仕様変更)まで背負わされる(「普通に考えればわかるでしょ」って言われる)。
んな事を考えると行き着くところはアジャイルだけど、発注側はリスクを背負いたくないから契約形態は変わらない。
「より良い物を作りたい」だけなのに責任の擦り付け合いになっちゃう。
あ〜明日の仕事も憂鬱だなぁ。。。




380 名前:仕様書無しさん [2012/02/02(木) 07:51:31.68 ]
>>378

そりゃ理想論としてはそうだけどそんな平和な現場って実際あるのか?
もっとギスギスしているのが普通だと思ってた


381 名前:仕様書無しさん mailto:sage [2012/02/02(木) 11:40:11.82 ]
>>379
お前またはお前の会社は、詳細設計書を渡されて実装〜単体テストのみを請け負ってるのか?
だとしたら、要件への適合性なんか考える必要無い。

382 名前:仕様書無しさん mailto:sage [2012/02/02(木) 11:46:19.58 ]
>>379
>(今の現場では)詳細設計書が基本設計書を満たしているか否かのチェックが機能していないんだ。

問題は、詳細設計書から要件を導き出せないことではなくて、これが問題なんだろ?
だったら、詳細設計書をアウトプットする奴らにちゃんとしろと言えよ
それとお前の成果物を受け取る奴の受け入れ基準を聞けよ

383 名前:仕様書無しさん mailto:sage [2012/02/02(木) 12:30:55.71 ]
>>380
むしろ、わざわざ反感買うような奴が続けられるようなヌルい職場が
まだ残ってるんだと驚いた。
反感買うような言動する奴は徹底的に苛められて追い出されるのが普通じゃね?

384 名前:仕様書無しさん mailto:sage [2012/02/02(木) 14:32:30.36 ]
>>382
おそらく詳細設計書を複数人でレビューしてなくて
上流で発生する仕様漏れや間違いが発見されずに
実装させられてるんだろう。

SEがスキル不足でPEが毎回墓穴を掘らされてれば、
自衛手段として実装前に要件を確認して、
設計に問題が無いかくらいは確認するようになるよ。

385 名前:sage [2012/02/02(木) 14:48:04.24 ]
>>384
PEって何だろ


386 名前:仕様書無しさん mailto:sage [2012/02/02(木) 14:56:35.24 ]
プログラマー

387 名前:仕様書無しさん mailto:sage [2012/02/02(木) 14:59:48.68 ]
>>379
設計担当と実装担当が別会社なら、渡された設計書をそのまま実装した方がいい。
自分の仕事以外の余計な事して、コストをかけるのは無駄。
仕様変更があれば、その仕事分を集計して、請求するか交渉の材料にする。

同じ会社なら、
設計が正しいかSE達でレビューをしっかりやってもらうしかないと思う。

あまりにもミスが目立つなら、リーダーや上司に訴えろ。

388 名前:sage [2012/02/02(木) 15:14:13.03 ]
>>387
全くその通り。
自衛が必要なら、前工程の成果物の妥当性を再検討するのではなくて、別の手段で。

>>384
詳細設計書かく人をSEと呼ぶですか・・・。

389 名前:仕様書無しさん mailto:sage [2012/02/02(木) 15:15:06.06 ]
おっと、超久しぶりにブラウザで書き込んだもんだから、sage間違い



390 名前:仕様書無しさん mailto:sage [2012/02/02(木) 19:20:40.56 ]
>>388
詳細設計を素人の客が見るならSEが書いた方がいいよ
PGが書いた詳細設計はいい意味でも悪い意味でも素人には読めません

391 名前:仕様書無しさん mailto:sage [2012/02/02(木) 20:13:31.67 ]
そもそも、詳細設計を素人が見る必要があるのか?
何のために見せるんだ?

392 名前: 忍法帖【Lv=4,xxxP】 mailto:sage [2012/02/02(木) 22:01:53.32 ]
詳細設計なんぞお客に見せない(見たがらない)もんだと思ってた(´・ω・`)

393 名前:仕様書無しさん mailto:sage [2012/02/02(木) 22:29:04.38 ]
詳細設計書作成がなかなか進まない
分からないところがあってソースを確認するはずが、気が付いたらコーディングしてる
どうしよう

394 名前:仕様書無しさん mailto:sage [2012/02/02(木) 23:06:49.83 ]
>>393
その場合はコーディングしてから設計書書いてコード見直す
プログラミング言語のほうが直感的にロジックを記述できるのは自明
で同時に設計書も書くことで仕様が整理されてコードの間違いにも気付く

395 名前:仕様書無しさん mailto:sage [2012/02/02(木) 23:34:02.01 ]
>>381
>>382
>>387
ありがとう!ふっきれた!
今まで、自分が製造担当した箇所で(要件漏れやドキュメント不備による)不具合、トラブルが発生したとき、
責任を感じてしまってた。
「製造担当」は製造に責任を持つべきで、「設計」の責任まで負う必要はない。
ただ、馬鹿正直に詳細設計書通りに実装するんじゃなくて、気づける箇所があれば要件を聞く。
その結果変更が必要なら変更分を請求すればいい(自社が設計して、変更にかかる工数を確保できなければエスカレーションする)。
(なんか文字に起こすと当たり前のことすぎるね。。)

よし、明日もがんばろう!

396 名前:仕様書無しさん mailto:sage [2012/02/02(木) 23:39:06.15 ]
>>393
スケジュール通りに成果物(設計書とソース)が上げられるならそれでもいいんじゃない?
けど、try and error だと残工数見積もりにくいよね。
詳細設計書に求めてる粒度が細かすぎるのでは。。。

397 名前:仕様書無しさん mailto:sage [2012/02/02(木) 23:50:15.45 ]
>>394>>396
アドバイスありがとうございます。
今までは先にコーディングしていたのですが、今回のプロジェクトは詳細設計書だけ先に提出しなければいけなくて…。
細かくやろうとしすぎてるかもですね。

398 名前:仕様書無しさん [2012/02/02(木) 23:53:08.30 ]
>>383

いやな奴や、客観的にみてもその場にいない方がましな奴でも平気で居座るのが
デスマというものなんだが。。

仕事はきついけど連帯感が生まれて現場は和気藹々だとでも妄想しているのか?


399 名前:仕様書無しさん mailto:sage [2012/02/03(金) 01:15:19.64 ]
詳細設計書の書き方がよく分からなくて、
自分がコーディングした場合を想定したロジックを
そのまま言葉に起こした設計書を提出したことがあったな。
その後に上司に注意されたよw



400 名前:仕様書無しさん [2012/02/12(日) 15:15:49.08 ]
みんなUML使ってる?

401 名前:仕様書無しさん mailto:sage [2012/02/12(日) 15:21:47.20 ]
クラス図とかシーケンス図とかよく使うな。

402 名前:仕様書無しさん mailto:sage [2012/02/12(日) 16:12:31.26 ]
ユースケース図とかアクティビティ図とかよく使うな。

403 名前:仕様書無しさん mailto:sage [2012/02/14(火) 20:03:34.03 ]
>>398
お前かわいそう。人を人として見られなくなったら終わりです。
仕事は仲間とする方が円滑に進む。綺麗事じゃなく。
徹底的に追い込むとかお前何様よ。お前も雇われの身だろーが。
お前の思考回路って、都会的と言うよりも在日じゃねーか?

404 名前:仕様書無しさん mailto:sage [2012/02/14(火) 23:35:26.51 ]
>>403
アンカは>>383のタイポかな?

内容については、同感
そういった職場の雰囲気は、リーダの性格によって形成されるのだと思う

405 名前:仕様書無しさん [2012/02/15(水) 19:57:04.45 ]
>>403

仲良し同士で低レベルなシステム作って一生喜んでいればいいじゃん。
そのうちインド人に取って代わられるだろうけどね。

本当のチームはチーム同士切磋琢磨するし、自らの責任を果たさない
フリーライダーはあっという間に排除する。


406 名前:仕様書無しさん mailto:sage [2012/02/15(水) 21:22:19.88 ]
>>403
お前は草野球。
プロ野球でスタメンになりたければ、人より秀でる必要があるって話。
プロのメンバー選考で手をつないでゴールしても落とされるだけだろ。


407 名前:仕様書無しさん mailto:sage [2012/02/15(水) 23:00:20.08 ]
仲良しごっこだろうとライバルごっこだろうと結果が出せなければ意味無いな。

408 名前:仕様書無しさん [2012/02/15(水) 23:26:09.20 ]
>>407

その通り。

自分以外の部署の人間が鬱病になろうがそれはその部署のマネジメントの問題。

中ではチームの力を最大限に生かすチームビルディングを行ってマネジメント能力をあぴーるし、
ほかの組織に対しては弱みを見せた瞬間に徹底的に追い込んで弱体化させるのが
組織の中で生き抜く秘訣。


409 名前:仕様書無しさん mailto:sage [2012/02/16(木) 01:19:21.65 ]
結果を出すことと組織の中で生き抜くことは全く関係ないな。



410 名前:仕様書無しさん mailto:sage [2012/02/17(金) 21:34:01.27 ]
仕事仲間のことだと思ってるんだが、どこで仲良しに変わったの?
お前らコンプレックスで過剰反応し過ぎじゃね?
この10数年の会社教育は嘘で洗脳だから、そろそろ目覚ましの時間ですよ?




411 名前:仕様書無しさん mailto:sage [2012/02/17(金) 23:37:50.44 ]
アットホーム()とか、まぁ良くも悪くも日本っぽい事ではあるし、それで成功してるとこもいっぱいある
別に和気藹々やるのがダメだとは思わん

ただ、そういうのを強調する人は、大抵自分から学んぼうとかしないで
低いレベルで仲良しごっこしたがる人が多いからなw
仲間意識をつかって停滞することに安心してる、みたいな

無理やりスレタイの話題に振るなら、そういう人が書いた仕様書は、割とひどいw

412 名前:仕様書無しさん [2012/02/18(土) 12:34:04.54 ]
新人が作った顧客に出す設計書のタイトルが↓だった

〜♪♪ ○○設計書 ♪♪〜


413 名前:仕様書無しさん mailto:sage [2012/02/18(土) 12:44:36.23 ]
客も喜ぶかもよ?

414 名前:仕様書無しさん mailto:sage [2012/02/18(土) 20:03:22.26 ]
中身がしっかりしてれば、外見なんて気にしない。
中身がなければ、怒りが増すがな。

415 名前:仕様書無しさん mailto:sage [2012/02/18(土) 21:50:57.90 ]
客によるとしか言えないな。

416 名前:仕様書無しさん mailto:sage [2012/02/19(日) 16:45:07.13 ]
新人なりに見栄え良く見せようとしたんだろ。
OJTで放し飼いして、ロクな教育してなかった奴が悪い。

417 名前:仕様書無しさん [2012/02/19(日) 17:16:55.09 ]
新人だと思ったら40才くらいのおっさん個人事業者が作った設計書らしい

418 名前:仕様書無しさん mailto:sage [2012/02/21(火) 21:41:55.34 ]
ジョエルのファンなんだろ

419 名前:仕様書無しさん mailto:sage [2012/02/22(水) 00:40:09.25 ]
>>392
完全なエンドユーザーが見るわけじゃなく、
客先のシステム担当が次のシステム改修の際に使うんだろ。
それか、基本設計書にエラーコードとか、要点じゃない
雑多な仕様が記述されてない場合とか。



420 名前:仕様書無しさん mailto:sage [2012/02/26(日) 14:08:13.66 ]
システム改修など、細かい部分が重要なのに、それが抜けてる仕様書は困るんだよね。
エラーコードとかは分からなければ、ユニークなコードで追加していけば問題ないが
データの抽出条件とかは、複雑だと調査に時間がかかってしまう。

421 名前:仕様書無しさん mailto:sage [2012/02/26(日) 16:48:07.30 ]
そういうのとても書ける量じゃないときがあるけどどうやって管理してんだろう?
結果の合否判定がやたらと複雑で仕様書にもどこにものってない箇所とか普通にあるんだけど
ソース見ながらでもうんざりするぐらい長いんだけど

422 名前:仕様書無しさん mailto:sage [2012/02/26(日) 17:02:57.34 ]
管理してないんじゃねw
担当が居なくなってから火を噴く、みたいな

423 名前:仕様書無しさん mailto:sage [2012/02/26(日) 19:20:31.66 ]
出来上がったソフトの動きが仕様です。

424 名前:仕様書無しさん mailto:sage [2012/02/26(日) 19:27:21.27 ]
そもそも要件が定義されていない。

回路図を渡され、顧客とやりとりしたメールの断片が転送されてきて
1ヵ月後までに仕様書と実装とテストを終わらせておけ
といわれる俺は既に色々あきらめている。

某日本で一番入りたい家電メーカのとある職場の風景

425 名前:仕様書無しさん mailto:sage [2012/02/26(日) 22:18:18.42 ]
日本の家電メーカーとか最初から終わってんじゃん
入りたくねーw

426 名前:仕様書無しさん mailto:sage [2012/02/27(月) 18:03:50.33 ]
家電とかの電子回路は商品ごとに作り直せるから無問題

427 名前:仕様書無しさん mailto:sage [2012/02/27(月) 18:09:50.12 ]
日本のものづくりw
技術者を大切にしないから、衰退の一方だなwww

428 名前:仕様書無しさん mailto:sage [2012/02/27(月) 18:25:14.20 ]
>>421
誰かが何らかの形で残してなければ、何も無いんだよ。

大概は、最初のうちはちゃんと作ってるけど、
プロジェクトがヤバくなると、ドキュメントの修正も手がまわらなくなる。
ある程度、体裁が整った設計書をコピペして使い回すから、
潜在的なバグ・仕様上のバグが爆発的に広がる。
まさに負の連鎖w


429 名前:仕様書無しさん mailto:sage [2012/02/27(月) 22:30:36.51 ]
>>424
それはマネしたさんではなくてエスプーさんのことですね。



430 名前:仕様書無しさん mailto:sage [2012/02/27(月) 23:50:58.83 ]
人売りが技術系にはびこってしまったからなぁ
スキルの安売り状態で業界がどんどんだめな方向に向かってる気がするわ
スキルなくても底辺で食ってけるから、そこで安心しちゃってるようなの多いし

431 名前:仕様書無しさん mailto:sage [2012/02/28(火) 20:36:35.55 ]
仕様書については未だに悩んでる。

1つの提案なんだが、コードにlatexで埋め込んで
仕様書を自動生成するか

そうでなくてもワードよりはtexのほうがいいとおもう。
どうせpdfで出図すればいいんだから。

なんでwordを進めるのだろう。
酷い場合はexcelで書く馬鹿がいる。
しかし上司だからこき下ろすこともできない。

432 名前:仕様書無しさん mailto:sage [2012/02/28(火) 20:57:17.60 ]
WordもExcelもMicrosoft Office Personalに入っているから
どの会社のPCでも導入時の状態のままで確実に読み書きできる、だろ?

433 名前:仕様書無しさん mailto:sage [2012/02/28(火) 20:57:59.49 ]
texは他人と共有したいとは思わないね。
環境ごとに使えるテンプレやマクロが違うとかやってらんない。

434 名前:仕様書無しさん mailto:sage [2012/02/28(火) 21:02:30.53 ]
latexはWYSIWYGじゃないからダメ。

逆にWYSIWYGで編集できるなら、
その中身がなんだろうと関係ないから
latexの必要性がない、

435 名前:仕様書無しさん mailto:sage [2012/02/28(火) 21:03:37.42 ]
ドキュメントは結局糞Wordしか使えないって事が多いから諦めて一通りは覚えた
使いにくいだけでスタイルと文書は一応分かれてるし
初期設定さえできてしまえばあとは書くだけになるし、そこまで手間はかからない
使いにくいだけで

Excelドキュメント作るやつは全員ばくはつしてしまうといい…

436 名前:仕様書無しさん mailto:sage [2012/02/28(火) 21:10:37.92 ]
>>431
お前はこれでも読んで勉強するといいよ。
Excelプロトタイピング――表計算ソフトで共有するデザインコンセプト・設計・アイデア
www.oreilly.co.jp/books/9784873114415/

なんでExcelはだめなんですかと聞くと、
Excelは表計算なんだから表計算にしか使ったらダメだ!という
それ以外の理由がない。頭が固いと思う。

Excelが優れている理由ならたくさんみつかるな。
ワークシート単位だから、文書が増えてもワードみたいにページが変わったりしない。
ワークシート=タブと考えれば、タブと同じ便利さがある。
図形を入れられる。それでいて文書も数値計算もできる。
大まかな座標が合わせやすい。

Excel=表計算という固定観念を捨てて、方眼用紙ソフトと考えれば、万能ソフトだって分かるだろう。

437 名前:仕様書無しさん mailto:sage [2012/02/28(火) 21:33:58.47 ]
万能ソフトだろうが何だろうが、まともに文章が入力ができないソフトはダメだ。

438 名前:仕様書無しさん mailto:sage [2012/02/28(火) 21:44:46.71 ]
挿入 - オブジェクトで「Microsoft Word 文書」を選べばいいよ

439 名前:仕様書無しさん mailto:sage [2012/02/28(火) 22:18:24.23 ]
WordよりはExcelの方がいいな



440 名前:仕様書無しさん mailto:sage [2012/02/28(火) 23:42:43.31 ]
Excelが万能って理由もあるけど、Wordがダメ過ぎるってのもあるんだよ。

441 名前:仕様書無しさん mailto:sage [2012/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)等への変換が可能






[ 続きを読む ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<244KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef