- 1 名前：仕様書無しさん mailto:sage [2011/11/26(土) 11:26:56.24 ]
- 外部だの内部だの基本だの詳細だの…
曖昧な基準で書かれた、いろいろな名前で呼ばれてて
「これってどうなの？」「意味あるの？」といった物に出くわす事も少なくない
しかし、純粋にプログラミングだけをして食べていくことは、昨今じゃ難しく
避けて通れない、否が応でも作る機会に出くわしてしまう、そんなドキュメントたち
設計書や仕様書についても、マ視点で語ろうぜ
・自分のなかでの仕様書/設計書の呼び方と分け方
・成功談、失敗談
・仕様書/設計書は何を使って作成する？(Word/Excel/HTML/手書き！)
・仕様書/設計書に含める図の作成方法や使っているツール紹介
・炎上プロジェクトでみた(よくない意味で)素晴らしい仕様書/設計書
・そもそも仕様書/設計書って本当に必要なの？
・こんな仕様書/設計書は、ぶっちゃけアリ？ナシ？
などなど、設計書にまつわる話題を募集
- 302 名前：仕様書無しさん [2012/01/18(水) 21:40:45.99 ]
- r.vb程
- 303 名前：仕様書無しさん mailto:sage [2012/01/20(金) 00:38:11.54 ]
- みんなはＤＦＤとか書いたりしてる？
- 304 名前：仕様書無しさん mailto:sage [2012/01/20(金) 00:45:15.74 ]
- 書かない。そんな暇はない。
- 305 名前：仕様書無しさん mailto:sage [2012/01/20(金) 05:04:10.03 ]
- DFDって、書きにくくて分かりにくいと思うけど。
業務フローならアクティビテ図がいいと思う。
- 306 名前：仕様書無しさん mailto:sage [2012/01/20(金) 10:05:07.33 ]
- なんだろう、よくUMLを既存のダイアグラムのスーパーセットのように捉える意見を見るが、そもそもの視点・指向が違うしな。
こっちの方がいい、いやあっちの方がいいという意見は首肯し辛いな。
- 307 名前：仕様書無しさん mailto:sage [2012/01/20(金) 10:05:57.06 ]
- と思ったが、ちょっと穿った見方だった。すまん。
- 308 名前：仕様書無しさん mailto:sage [2012/01/20(金) 11:09:45.53 ]
- いや、事実宗教戦争になりつつある
- 309 名前：仕様書無しさん mailto:sage [2012/01/20(金) 12:55:20.15 ]
- 単なる民族間抗争だろ。
- 310 名前：仕様書無しさん mailto:sage [2012/01/20(金) 20:58:36.49 ]
- アジャイル開発やってる人は何をドキュメントに残しているんだろ。
- 311 名前：仕様書無しさん mailto:sage [2012/01/20(金) 23:41:08.97 ]
- 色々。プログラムに関するドキュメントは殆ど書かないけど
- 312 名前：仕様書無しさん mailto:sage [2012/01/21(土) 05:14:25.24 ]
- 色々って？
- 313 名前：仕様書無しさん mailto:sage [2012/01/21(土) 07:10:14.71 ]
- 赤とか青とか
- 314 名前：仕様書無しさん mailto:sage [2012/01/21(土) 11:50:38.19 ]
- 立体的に見えるやつだな
- 315 名前：仕様書無しさん mailto:sage [2012/01/21(土) 15:56:17.93 ]
- ホワイトボードに描いた落書きとか、いっぱい入ってるよ。
- 316 名前：仕様書無しさん mailto:sage [2012/01/22(日) 11:21:53.13 ]
- >>315
ホワイトボードの落書きをドキュメントとして納品してるってことか？
アジャイル開発でも、最終的には確定した仕様書や設計書を納品しなきゃいけないと思うんだが、
どういう形式でやってるのか、よく分からないんだよな。
- 317 名前：仕様書名無しさん mailto:sage [2012/01/22(日) 12:40:40.50 ]
- >>316
最終的に確定したら、それはアジャイルじゃないよ。
アジャイルは常に進化し続ける事にメリットがある。
- 318 名前：仕様書無しさん mailto:sage [2012/01/22(日) 12:56:30.27 ]
- >>316
そもそも納品をしないから。
- 319 名前：仕様書無しさん mailto:sage [2012/01/22(日) 13:16:53.57 ]
- 納品しないのは、誰の都合？
少なくとも顧客の都合じゃないよね？
- 320 名前：仕様書無しさん mailto:sage [2012/01/22(日) 13:23:57.95 ]
- >>317,>>318
納品しないってことは、準委任契約で開発するってことか？
それでも、内部設計書くらいは残すんだよな？
- 321 名前：仕様書無しさん mailto:sage [2012/01/22(日) 16:13:59.79 ]
- 自社サービスなら納品て概念が無いんじゃないの
- 322 名前：仕様書無しさん [2012/01/22(日) 17:00:17.40 ]
- 偽装請負なら、「作業報告書」って言って週報レベルのものを出してもＯＫだよ
- 323 名前：仕様書名無しさん mailto:sage [2012/01/22(日) 17:18:14.31 ]
- 常に進化し続けるシステムを作りつづける方式がアジャイルであるのに、開発費用を抑えたり、要件がまとまらない場合の銀の弾丸みたいな考えでアジャイルやろうとするから、納品物がどうとか話がおかしくなるんだよ。
予算確保→システム作成依頼→納品物受領→プロジェクト終了
これはアジャイルでは無い。
その時々にある予算の範囲内で、無理なくシステムを作り続けることがアジャイルなんだよ。
発注形態なんて作業請負、派遣、定期雇用に決まってる。
- 324 名前：仕様書無しさん mailto:sage [2012/01/22(日) 17:29:00.61 ]
- 本来はマだけど、最近は見積もりするばっかり。
- 325 名前：仕様書無しさん mailto:sage [2012/01/22(日) 18:51:37.87 ]
- アジャイルって、作る側も顧客側もどっち側にもメリットはあるんだけど、
作る側個々の能力とか結構重要だから、にわかは死ぬし、
理解力の無い顧客の場合もすぐ破綻するし、土方産業には向いてないんだろうな
人売りとか中抜きがしづらいやり方になるから、そういうので食ってるとこにメリットないし
そもそも、上のやり取りからしても、既存の枠が染み付いてるお偉いさんとかは、なかなか理解しきれない
- 326 名前：仕様書無しさん [2012/01/22(日) 19:12:20.56 ]
- awabi.2ch.net/test/read.cgi/poverty/1327050821/3
- 327 名前：仕様書無しさん mailto:sage [2012/01/25(水) 00:41:11.40 ]
- うちの場合、アジャイルに対する理解度合いがばらばらで、アジャイルを推進してる人は、要件の管理方法くらいにしか思ってない。技術的な考慮なんて一切なく、WFの考え方から抜け出せていないまま押し付けてくるから、現場は混乱。
現場は現場で、WFでやってた事そのままで、テストコード書けばアジャイルだよね~ってことで始めるが、テストコードのメンテはされずコストだけがかさむ。
- 328 名前：仕様書無しさん mailto:sage [2012/01/25(水) 01:01:10.32 ]
- >>327
WFとはおそらくウォーターフォールの事だと思うけど、
そういったローカル用語(俺様用語)が飛び交う現場では
混乱と混迷の渦から抜けきれないのは当たり前だな
アジャイル手法うんぬん以前に問題がある
- 329 名前：仕様書無しさん mailto:sage [2012/01/25(水) 03:39:24.24 ]
- ウォーターフォールって、ローカル用語か？
それに、アジャイル開発なら少数精鋭でチーム組むんだから、ローカル用語でやってもいいんじゃん。
- 330 名前：仕様書無しさん mailto:sage [2012/01/25(水) 07:10:54.88 ]
- >>329
変な略語使うなって事だろ。
- 331 名前：仕様書無しさん mailto:sage [2012/01/25(水) 14:09:21.70 ]
- この文脈でWFが何の略語かわからない奴はもぐり
- 332 名前：仕様書無しさん mailto:sage [2012/01/25(水) 20:37:44.76 ]
- 浮いてる奴はもぐり
- 333 名前：仕様書無しさん mailto:sage [2012/01/25(水) 22:32:52.84 ]
- 文脈から推測はできたけど、んな略記は初めて見たな。
使うなとは言わんけど、俺々略語って恥かくことあるし、多用はしないほうがいいとおもう。
- 334 名前：仕様書無しさん mailto:sage [2012/01/25(水) 23:50:25.24 ]
- 同じく推測はできた。
ただ、一般的ではない用語や略語を使う人間は仕事場では混乱を招く人の可能性が高い。
同じ現象がコードにも現れる。
>>331みたいな返しをする所が論外。
- 335 名前：仕様書無しさん mailto:sage [2012/01/26(木) 00:00:06.04 ]
- 自分の勤めてる会社の常識しか知らない人なんだろうね。
井の中の蛙になってる。
- 336 名前：仕様書無しさん mailto:sage [2012/01/26(木) 00:34:18.10 ]
- 瞬間的にワークフローと読んだ
- 337 名前：仕様書無しさん mailto:sage [2012/01/26(木) 02:17:13.01 ]
- 井の中の蛙
大海を知らず
知ったところで
海水じゃぁ蛙は生きていけない
よかったね
知らなくて
- 338 名前：仕様書無しさん mailto:sage [2012/01/26(木) 02:47:36.87 ]
- 特許庁の新システムの開発中断のニュース、
原因が東芝ソリューション側の設計遅れになってるけど、
実際のところ、何が悪かったんだろうな？
- 339 名前：仕様書無しさん mailto:sage [2012/01/26(木) 03:05:31.24 ]
- ユーザが出す要件が矛盾だらけとか、二転三転したという可能性はないのかな？ とシステム屋を擁護してみる。
- 340 名前：仕様書無しさん mailto:sage [2012/01/26(木) 07:58:01.59 ]
- 中国の特許を日本語で検索できるシステムなんて、嫌な予感しかしない。
- 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 ]
- ユースケース図とかアクティビティ図とかよく使うな。
|
 |
