- 1 名前：仕様書無しさん mailto:sage [2011/11/26(土) 11:26:56.24 ]
- 外部だの内部だの基本だの詳細だの…
曖昧な基準で書かれた、いろいろな名前で呼ばれてて
「これってどうなの？」「意味あるの？」といった物に出くわす事も少なくない
しかし、純粋にプログラミングだけをして食べていくことは、昨今じゃ難しく
避けて通れない、否が応でも作る機会に出くわしてしまう、そんなドキュメントたち
設計書や仕様書についても、マ視点で語ろうぜ
・自分のなかでの仕様書/設計書の呼び方と分け方
・成功談、失敗談
・仕様書/設計書は何を使って作成する？(Word/Excel/HTML/手書き！)
・仕様書/設計書に含める図の作成方法や使っているツール紹介
・炎上プロジェクトでみた(よくない意味で)素晴らしい仕様書/設計書
・そもそも仕様書/設計書って本当に必要なの？
・こんな仕様書/設計書は、ぶっちゃけアリ？ナシ？
などなど、設計書にまつわる話題を募集
- 260 名前：仕様書無しさん mailto:sage [2012/01/11(水) 10:58:59.68 ]
- HTMLの印刷だけはもうやりたくないわ…。今はマシになってんのか？
仕様書というか納品物レベルの印刷ロジック組むのが死ぬほど面倒だった。
一画面一ページで収まるように書かれていれば楽なんだがな。
ページまたぎのテーブルとか死ねる。
- 261 名前：仕様書無しさん mailto:sage [2012/01/11(水) 15:00:13.71 ]
- >>259
SVG対応してるブラウザ少なくない？
それともHTMLで仕様書作るなら、IE9は必須って事なのか？
- 262 名前：仕様書無しさん mailto:sage [2012/01/11(水) 20:04:28.50 ]
- そんなの客と取り決めろよ…
- 263 名前：仕様書無しさん mailto:sage [2012/01/11(水) 20:05:43.30 ]
- HTML使いこなせないのと使いたくない理由で、言い訳並べてないか…？
ドキュメントの媒体なんて臨機応変に使い分けろよ。
- 264 名前：仕様書無しさん mailto:sage [2012/01/11(水) 20:14:04.33 ]
- だからってExcel方眼紙スタイルはないわ
- 265 名前：仕様書無しさん mailto:sage [2012/01/11(水) 20:18:44.11 ]
- 早くて便利なら、理解できる仲間うちで使う分にはいいだろ。
まぁ、俺は使わないけど。
- 266 名前：仕様書無しさん mailto:sage [2012/01/11(水) 20:55:37.15 ]
- xhtml なら簡単に変換できそう。
- 267 名前：仕様書無しさん mailto:sage [2012/01/12(木) 00:23:55.42 ]
- xhtmlは出力形式。
何かからxhtmlに出力するのはありだが、
xhtmlから他の何かに変換するものではない。
なぜならXML（データ）にHTML（人間用文書構造）が含まれた結果
データとして処理しにくくなるからだ。
- 268 名前：仕様書無しさん mailto:sage [2012/01/12(木) 00:56:32.52 ]
- 印刷なんて紙の無駄でしかないと思ってるけど、
印刷が前提ならWordあたり使ってちゃんとやるのが一番手っ取り早いわ
あと、ただの愚痴だけど、番号つき段落で処理途中に挿入されて番号がずれる、みたいなものや
変更点の文字色を変えるような必要になるものを、Excel方眼紙で作るな市ね
- 269 名前：仕様書無しさん mailto:sage [2012/01/12(木) 01:12:45.76 ]
- >>267
さすがに xhtml を直に書きたくはないけれど、
目次付きの印刷品質の pdf にするのは簡単だよ。
見出しも番号を自動で付けてくれるし。
- 270 名前：仕様書無しさん mailto:sage [2012/01/12(木) 08:32:38.92 ]
- >>267
引っ掛かるんです一応言うがxhtmlは、
htmlをxml基準で曖昧さを排除し、
パーサーの簡略化と互換性の強化を目指したものだぞ。
別に人間用情報が入ってても構わん。
そういう部分を分離したけりゃXSLTを使う
- 271 名前：仕様書無しさん mailto:sage [2012/01/12(木) 10:25:06.15 ]
- >>269
rest？興味だけで実用してないんだよな。
ツールはやっぱりSphynx？
- 272 名前：仕様書無しさん mailto:sage [2012/01/13(金) 01:03:38.06 ]
- >>270
曖昧さを排除したからといって扱いやすいとは限らない。
人間用に手を加えたXHTMLはCSSやJavaScriptで
必要なdivやspanがあちこちはいるから純粋なデータではなくなる。
やってみればわかるが、純粋ではないデータ（それはしばしば変更される）
であるXHTMLからXSLTを使って変換するのは苦痛でしかない。
- 273 名前：仕様書無しさん mailto:sage [2012/01/13(金) 17:05:57.86 ]
- 様式に口うるさいヤツいるけど、矛盾点を突くと
「それは別の工程だから」とか「それは前のプロジェクトのでいまはこうだから」
とかいって結局、「いまの自分の書き方が正しいからね、既に書き終えた人は修正してね」の一点張り
- 274 名前：仕様書無しさん mailto:sage [2012/01/13(金) 18:43:45.12 ]
- >>273
それ、お前の理解力が低いだけじゃないよな…？
- 275 名前：仕様書無しさん mailto:sage [2012/01/13(金) 22:23:18.64 ]
- 一度書き終えてOK貰った書類を、全部書き直せなんてマジキチ。デスマじゃん。
- 276 名前：仕様書無しさん mailto:sage [2012/01/14(土) 02:51:22.99 ]
- >>275
書き直しの理由くらい添えてレスしろよ。
- 277 名前：仕様書無しさん mailto:sage [2012/01/14(土) 03:02:21.06 ]
- リクエストパラメータで渡す項目一個一個書いたり、
入力チェックエラー時のメッセージを一個一個書いたり、
これくらいソースだけでいいだろと思ってしまうんだが。
ドキュメントに必要なのは画面イメージと処理フロー図、
簡単な処理詳細と、処理で使うDBのテーブル情報くらいでいいと思うんだが…
- 278 名前：仕様書名無しさん mailto:sage [2012/01/14(土) 03:38:48.42 ]
- >>276
ただ一言、『わかりづらい』という理由だったりする。
ユーザー側の設計者だけでなく、誰が見ても何がどこに書いてあり、内容が即座に理解できるようにと。
- 279 名前：仕様書無しさん mailto:sage [2012/01/14(土) 06:53:39.69 ]
- それは妥当な理由だ。
理解できない書類作る方が無駄な作業だろ？
- 280 名前：仕様書無しさん mailto:sage [2012/01/14(土) 09:29:54.69 ]
- わかってないね
金がとれるドキュメントであることが重要なんだよ
日本のプログラマーは嫌儲なのか
金儲けが下手くそ
- 281 名前：仕様書無しさん mailto:sage [2012/01/14(土) 12:54:34.34 ]
- >>277
パラメータやメッセージは、ちゃんと書かないとプログラム作れないだろ。
不要なのは、項目名の後に項目IDをつけろ、つけるなとか言う文章表現的なものや、
外部設計書なのにプログラマが実装できるように、集計ロジックを書けとか言うもの。
Excel設計書だから、枠から文字がはみ出てるとか、漢字に誤植があるとか…
- 282 名前：仕様書無しさん mailto:sage [2012/01/14(土) 13:00:45.89 ]
- >>278
それは無理難題かもしれないな。
俺も昔やられた。
プログラムと一緒で、ある一定レベルまではわかりやすく書けるのは事実。
(日本語の使い方や、用語の定義の仕方、書く順番等)
ただ、想定する読者の優先度による可読性のトレードオフが発生する。
だから、誰が見ても解るドキュメントなんてない。
まずやるべきは、ドキュメントが誰にどのように使われるのかを定義する事。
次に、前提とする読者の知識レベルを定義。
次に、読者が複数いる場合、優先順位を決める。
相手の立場になって考える事は重要だが、無理なものは無理だ。
から、先に予防線をはる。
そういう文句を言う上司は多い。
- 283 名前：仕様書無しさん mailto:sage [2012/01/14(土) 13:01:43.89 ]
- >>277
何に使われるドキュメントか理解してない事が原因だな
- 284 名前：仕様書無しさん mailto:sage [2012/01/14(土) 13:25:26.71 ]
- そういう見た目や体裁、文体への指摘は、
レビュアー側が自分の好みでレビュー結果のブレが出るから、一概にどっちが悪いとは判断できないな
書式を厳格にするなら、プログラミングでの制約などと同じように
個々の裁量にまかせず仕組みで解決するのが最適解なんだけどな
言語みたいな感じで共通の書式がほしいわ
そういう金に直結しないドキュメント整理に費やす時間が勿体無い
いろんな人が見るようなマニュアルとかだとそりゃちゃんとやるべきだけど
業務系の割と簡単なWebシステムとか、万人が確認するわけでもない
仕様まわりの内部向けドキュメントとかでそういう事繰り返して工数削ってるのは、すごく無駄を感じちゃう
その体裁まわりの時間で、モック作ったりそれでUI検討したり、実装したりテストしたりしたほうが有意義だろうに…
- 285 名前：仕様書名無しさん mailto:sage [2012/01/14(土) 14:00:03.50 ]
- 俺自身は、本当に誰にでも理解できる設計書が存在するとは思ってないが、
受け入れを行う顧客担当者が考える「誰にでも理解できる設計書」を求められる。
結果として、顧客担当者が納得するレベルかどうかを手探りで設計書を作るわけだが、
俺はそいつじゃ無いので、何度も何度もやり直しを喰らうハメになる。
- 286 名前：仕様書無しさん mailto:sage [2012/01/14(土) 15:01:28.91 ]
- >>285
顧客担当者が考える「誰にでも理解できる設計書」の段階で、だいぶ無理があるよな。
審査する人間がどの程度スキルや経験持ってるか分からないから
初心者向けに書くのか、経験者向けに書くのか凄く曖昧なんだよ。
大抵、見積時点では後者向けのドキュメントを想定してるみたいだけど、
開発が進むにつれて人数増えてくると、初心者とかいろんな人間が混じるから、
より詳しいドキュメントが必要になってしまってる現実もある。
俺は、設計書渡されたPEがプログラム作れる最低限必要な条件や項目が記載されていればいいと思ってる。
- 287 名前：仕様書無しさん mailto:sage [2012/01/14(土) 15:03:10.54 ]
- >>285
そもそも顧客担当者が理解不足をドキュメントのせいにしている可能性もあるな…
- 288 名前：仕様書名無しさん mailto:sage [2012/01/14(土) 16:00:50.97 ]
- >>287
担当者いわく、自分なら今まで打ち合わせをしてるから理解できるけど、今後担当が変わった時に仕様が伝わらないような設計書はダメってことらしい。
俺には、人ん家の未来の担当者レベルを予知する能力は無いっての。
- 289 名前：仕様書無しさん mailto:sage [2012/01/14(土) 16:35:55.38 ]
- >>288
具体的に指摘してもらって、そこだけなおせ。
自分で考えろって言われたらそのまま出して、これで解るレベルの奴を雇えって言え。
両方ダメなら殴っていいぞ
- 290 名前：仕様書無しさん mailto:sage [2012/01/14(土) 16:39:53.41 ]
- >>288
レベルの低い担当者だと、自社の業務の流れすら分かってない奴もいるからな。
そんな奴にまで分かる設計書書けとか言われても困るw
- 291 名前：仕様書無しさん mailto:sage [2012/01/14(土) 17:27:53.80 ]
- 説明書とかじゃないんだから、日本語の言い回しレベルでの指摘しかしない奴は、
すぐにでも担当からはずしてほしいわー。
よくそういう指摘をしてる場面を見かけるから、
ああいう人はレビュアーからはずしたほうがいいんじゃないか、って思ってしまう。
レビューする奴が当てにならないときは、わざと間違えた内容を混ぜてみるといいな。
ちゃんと要点を確認する人ならすぐに指摘してくれる。
もし仮に通ってしまっても、そこは後で気づいたことにして再修正かければいいし。
性格悪いやり方だけど、事前に危険回避できるって意味では手のうちだと思う。
- 292 名前：仕様書無しさん mailto:sage [2012/01/15(日) 15:38:38.07 ]
- 誤字脱字はレビュー以前の問題だからな。
勘違いすんなよ。
言い回しへの言及は説明書レベルなら普通にやる。これもレビュー以前の問題だ。
ワザワザレビューで指摘されてんだから有難くおもえ。
- 293 名前：仕様書無しさん mailto:sage [2012/01/15(日) 18:18:25.72 ]
- >>286
> 俺は、設計書渡されたPEがプログラム作れる最低限必要な条件や項目が記載されていればいいと思ってる。
そんな丁寧に書かれた設計書なんて滅多にないけどな。
その業務特有の用語すら説明されていない設計書ばかりだ。
- 294 名前：仕様書無しさん mailto:sage [2012/01/16(月) 00:08:26.23 ]
- プログラム仕様書をA HotDocumentで作るから使い方を調べとけといわれてる
で、やってみたら〜.designer.vbを読み込んでくれない
やり方わかる人いたら、教えてくださいな
- 295 名前：仕様書無しさん mailto:sage [2012/01/16(月) 21:24:11.70 ]
- HotDocumentは仕様書を作るものではなく、
仕様がわからないソフトの解析の
ちょっとしたヘルプができるかな？みたいなもの。
あとは、客にこんなに作りました！って
騙すものだから、
designer.vb程度読めなくても
いいじゃないかアハハハはは
- 296 名前：仕様書無しさん mailto:sage [2012/01/18(水) 11:48:26.13 ]
- >>293
それでどうやってプログラム作ってるの？
- 297 名前：仕様書無しさん mailto:sage [2012/01/18(水) 12:15:35.23 ]
- >>296
知ってる人に聞けばいい。
- 298 名前：仕様書無しさん mailto:sage [2012/01/18(水) 13:37:44.51 ]
- 知ってる人「知らない」(嘘)
とか、平気であるけどな。
人格破壊の負のスパイラル。
- 299 名前：仕様書無しさん mailto:sage [2012/01/18(水) 14:19:36.20 ]
- できるできないじゃない。
やるんだ。
- 300 名前：仕様書無しさん mailto:sage [2012/01/18(水) 16:57:42.59 ]
- >>299さんがこわいです。
- 301 名前：仕様書無しさん mailto:sage [2012/01/18(水) 17:45:14.51 ]
- >>299
とりあえず仕様固めて頂けませんかw
- 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
設計者やお客さんに聞いて仕様を確認するのが本来だけど
詳細設計書を元にプログラム作るコーディング請負の仕事なら
わけわからんまま設計書に書いてあるとおり作るしかないんじゃないか
|
 |
