仕様書、設計書について

[表示 : 全て最新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/手書き！)
・仕様書/設計書に含める図の作成方法や使っているツール紹介
・炎上プロジェクトでみた(よくない意味で)素晴らしい仕様書/設計書
・そもそも仕様書/設計書って本当に必要なの？
・こんな仕様書/設計書は、ぶっちゃけアリ？ナシ？

などなど、設計書にまつわる話題を募集
4 名前：仕様書無しさん mailto:sage [2011/11/26(土) 11:48:15.20 ]: ・実際の運用
外部設計/基本設計、内部設計/詳細設計
　箇条書きの要件定義、またはループや分岐を書いたフローチャート
　外部/基本設計が詳しい場合、内部/詳細は内容のコピペか焼き直し
　内部/詳細の修正でも必ず外部/基本設計が修正される

プログラム設計
　そんなの作ってる余裕なんてないです＞＜；
　コピペが何割かを占めるコードだけが絶対でありそれコメント(そもそもない)含めて他は不要
---

正直マ暦はあんまり長くはないのだけれど、これって普通のことなのかな…？
5 名前：仕様書無しさん mailto:sage [2011/11/26(土) 11:50:47.01 ]: ちなみに作るのに使うのは基本的にExcelです。
もちろん方眼紙です。
図はオブジェクトたち。
たまーにWordもありますが、終盤はファイルがいくつか見事にぶち壊されてます。

レビュアーが意図してる「仕様書」が何かを察することが、うまくやるコツなのかなって
最近思うようになってきました。書きたくない、じゃ通らないですし…。
6 名前：仕様書無しさん mailto:sage [2011/11/26(土) 12:34:32.02 ]: ソースコードは設計書だと考えるべし。

設計はなるべくコードとして書くべし。

コードから自動生成できるたぐいの情報は、
別にドキュメントにまとめる必要はない。

仕様書はソースコードにコメントとして書くべし。
またはテストとして書くべし。

Excel、他形式のドキュメントはたたき台としての意味はあるが、
最終的にはソースコードに全て記述するべし。

別の形式として見たければ、ソースコードから変換すべし。
7 名前：仕様書無しさん [2011/11/27(日) 16:30:57.65 ]: ケースバイケース
以上終了
8 名前：仕様書無しさん [2011/11/28(月) 23:25:34.20 ]: 結局ある程度の実装経験がないと設計なんて出来ないよ
でも、設計から入れ実装は後だっていう微妙な風潮
しかも、つくる設計書の記述内容は、実装前に作るものとしてはイマイチな内容
9 名前：仕様書無しさん mailto:sage [2011/11/29(火) 12:00:52.51 ]: 設計書とプログラムが食い違っていないか、機械的に検証する手段がないから、どんなに頑張って設計書作っても立派なプログラムが出来るわけじゃない。
結局設計書作るのって自己満足でしかないよね。
10 名前：仕様書無しさん [2011/11/29(火) 21:12:13.15 ]: 設計書作ること自体が目的になるとページ数だけ多くなって誰も読まなくなるな
そして設計書があるのにまったく見ずにソース見ながら電話対応するようになる
11 名前：仕様書無しさん [2011/12/01(木) 02:11:54.00 ]: ソース見て判断できない人が見てるフリするための資料になってることが多いな
12 名前：仕様書無しさん mailto:sage [2011/12/01(木) 02:28:22.31 ]: 大手だと品質保証のためとか言ってコーディング前に設計書を要求されるけど、
誰もまともにレビューしてなくて結局実コードのテストで
設計段階の間違いがボロボロ発見されるような現場ばかり。
13 名前：仕様書無しさん [2011/12/01(木) 02:33:40.32 ]: 設計書なんて大枠だけきっちりしてればいいんだよ
あとインターフェイス部分とエラー処理と
14 名前：仕様書無しさん mailto:sage [2011/12/01(木) 13:57:54.56 ]: 現状のドキュメントはバッチ処理にはソコソコ役に立つけど
オンラインだと矛盾が多い
新しい設計書の技法出来ないかな？
UMLに拡充する形でいいけど
あと、各社マチマチな工程名称も統一して情報処理試験でキッチリ記述と読み取りを出して欲しい
納品の為にしか存在価値のないものがおおすぎる
15 名前：仕様書無しさん mailto:sage [2011/12/01(木) 21:10:59.29 ]: >>12 想像力があっても実物の挙動は予想不可能なんだぜﾋｧｯﾊｰ
16 名前：仕様書無しさん [2011/12/02(金) 02:08:25.70 ]: 文章での説明にしても図説（もちろんフローチャート()）にしても
例外をうまいこと表現できないから、なんか書いてて、ウアーってなる
他のとこだけコードよりの内容が要求されるのにｗｗ

でも他の人みると、そもそも例外なんてアウトオブ思考だったわ
17 名前：仕様書無しさん mailto:sage [2011/12/02(金) 02:43:20.88 ]: >>14
確かに、設計まわりの明確な名称はあるとかなり嬉しいな
とにかく何もかもが曖昧すぎるんだよな
18 名前：仕様書無しさん mailto:sage [2011/12/02(金) 20:25:06.46 ]: >>12
レビューしないだけマシだわ
設計書段階で馬鹿みたいレビュー繰り返してる内に
フローチャートを作ってた事あったし
挙げ句に設計書レビューに無駄に時間がかかった結果
実装はデスマーチになってるから本末転倒の極み
19 名前：仕様書無しさん mailto:sage [2011/12/02(金) 20:50:32.61 ]: 設計段階で何するかは煮詰めたほうがいいよ。

実装者がアイディアマンになってしまうのは良くない。
俺が実装して痛い目見た経験から。
20 名前：仕様書無しさん mailto:sage [2011/12/02(金) 21:18:28.12 ]: >>19
詰めるべきは客先交えて決める外部仕様だろ
設計で内部ロジックなんか詰めてもしょうがねーよ
21 名前：仕様書無しさん mailto:sage [2011/12/03(土) 17:02:41.63 ]: DB設計と画面のモック作るだけ。
22 名前：仕様書無しさん mailto:sage [2011/12/04(日) 09:16:18.07 ]: マなんて信用してないから書かせる
23 名前：仕様書無しさん [2011/12/05(月) 23:13:04.70 ]: マはマで設計が信用ならないって言ってたりするからな
どっちであっても、出来る奴と出来ない奴の差が激しすぎるんだよな
なまじ形だけなら誰でも出来るもんだから、ひどい物でもなんとかなってしまうっていう
24 名前：仕様書無しさん mailto:sage [2011/12/05(月) 23:25:10.52 ]: つか、システム全体の設計はともかく詳細設計書はコード書く本人に書かせてレビューするだろ。
新人とかなら詳細設計書まで書いてやって渡すこともあるけど。
25 名前：仕様書無しさん mailto:sage [2011/12/05(月) 23:39:09.72 ]: >>24
新人じゃないならそれこそ実装したコードレビューした方が早いだろ
26 名前：仕様書無しさん mailto:sage [2011/12/06(火) 02:16:54.87 ]: こういうのみると、つくづく設計関連の用語の意味が統一されてないのが
諸悪の根源だって気がしてくるわ
27 名前：仕様書無しさん mailto:sage [2011/12/06(火) 10:45:11.60 ]: >>26
諸悪の根源は別のところにあります
本質を見抜く目を養わないと一緒ドカタですよ？
28 名前：仕様書無しさん [2011/12/06(火) 22:37:20.22 ]: 建築業界って、大工が「俺の作ったもんが設計書だ！」って思う人いるんだろうか
29 名前：仕様書無しさん mailto:sage [2011/12/06(火) 23:41:22.45 ]: この前ブックオフで「仕様書の書き方」みたいな本があったんだけど、結局サンプルはオマケ程度で中身スカスカだった。
ちなみに俺が超参考になったのは、某大手の社員用サイトにある雛形だった。
しかしそれを下請に見せない理由がよく分からん。
その形式で納品すればそこそこな品質になるはずだが、社外秘なんだよ
30 名前：仕様書無しさん mailto:sage [2011/12/07(水) 00:40:48.22 ]: 基本的にそこらの書店にあるような仕様書サンプルってプログラム素人向け、顧客が理解できる程度のものだからね。
31 名前：仕様書無しさん mailto:sage [2011/12/07(水) 02:34:21.03 ]: この業界自体土方だけどな
土方根性土方思想がはびこりすぎて個人でどうにかできる状況じゃねーよ(´･ω･｀)はあまじああ
32 名前：仕様書無しさん mailto:sage [2011/12/07(水) 13:03:05.04 ]: >>28
モジュールを指して設計書という奴は居ないだろう
ソースに該当するのはなんだろうな
33 名前：仕様書無しさん mailto:sage [2011/12/07(水) 15:22:16.38 ]: >>28
大工が建築物にコメント書くのが許されるんなら設計書にならなくもない
物置程度ならそれで充分なんじゃないかな、よくわからんけど
34 名前：仕様書無しさん mailto:sage [2011/12/08(木) 18:17:02.74 ]: >>33
建材に印ついてたりはするよな
35 名前：仕様書無しさん mailto:sage [2011/12/09(金) 09:12:42.17 ]: うちのポストにもたまに印がついてる
36 名前：仕様書無しさん mailto:sage [2011/12/09(金) 19:33:18.78 ]: 書いてるとこ見つけたら器物損壊で訴えれるんだっけ、あれｗ

きっちりかっちりしすぎても、緩すぎても仕様書って成り立たないよな
降車は言うまでもなく、前者も全員が守れない無駄な仕組みになってることが多くて、破綻しやすい
いい仕様書の共通仕様でもできればいいのにな！！
37 名前：仕様書無しさん mailto:sage [2011/12/09(金) 20:25:54.02 ]: >>33
墨つぼが大工のコメント
38 名前：仕様書無しさん mailto:sage [2011/12/10(土) 17:34:18.45 ]: 「昔、城を建てた無名の木工は、自分がその仕事に携わった証として、
屋根裏に自分の名を刻んだ工具を態と忘れたそうだ。そんな些細な思いすら、お前達は消し去るのか？」
39 名前：仕様書無しさん mailto:sage [2011/12/10(土) 22:37:29.19 ]: たまに外科手術で縫合終わった後にﾒｽが一本足りないことに気が付いたりとか？
40 名前：仕様書無しさん mailto:sage [2011/12/12(月) 02:53:25.99 ]: sierなんかで働くから悪い
41 名前：仕様書無しさん mailto:sage [2011/12/16(金) 21:00:08.96 ]: ドキュメントの枠だけ用意されて中身の書き方が決まっていない現場って
文章の語順や言い回しとか表現の仕方ばかり気にする人多いけど
正直馬鹿にしか見えないんだよな
共有鯖から過去の資料や既にＯＫ出てる仕様書を真似て作成しても
人によって作り方が違うからＮＧになるし
そもそも同じﾌﾞﾂ出して見る人によってＯＫ・ＮＧ別れる時点でおかしいが
本人たちは指摘して偉い気分にでもなってるのかね

「ここは太線で区切ろう」とか
「ここは①、②を使おう」とか
「ここは図を入れよう」とか
「ここは→・↓・←・↑を使おう」とか
「ここはカッコ使おう」とか
「待てよ！～が～の～を…うーむ」とか…

こんな指摘ばかり受けてる間に
５時間でコーディング終わるＰＧの仕様書に３日かかったし
完全に遅れが発生してこの指摘馬鹿と一緒に毎日２２時過ぎまで残業開始
結局終盤の方からはＰＧの仕様書は時間がないからと指摘馬鹿が作成

どれ程のもん作ってるのかとこっそり覗いたが１時間くらいあれば
作れるような普通の仕様書だった
要するにこいつの趣味の書き方というだけだった
指摘馬鹿は人に「こっちの方がいい」とか指摘する前に
本当にそれをする必要があるのかどうかを考えた方がいいわ
必要ないことに時間掛けてる奴多すぎ
42 名前：仕様書無しさん mailto:sage [2011/12/17(土) 01:23:21.94 ]: まったくだわ
うちの職場だと、能無しPLとか老害連中や口うるさいバカ女が
しょっちゅうどうでもいいことにばっか力注いでて、もうウンザリ
その決定を行わない無駄なボールの投げあいしてる時間で
解決してしまえる内容をぐだぐだやって、時間が浪費されてく

無駄に細かい仕様を早いうちから書こうとして要点はつめないまま、
後になって仕様変更のなみで外設あたりからいろいろ詰んでるし、頭痛いわ…
43 名前：仕様書無しさん mailto:sage [2011/12/17(土) 10:53:56.91 ]: >>41
それを顧客側が要求してくることもあるからな。
プログラムは正しくても、仕様書の記述ミスを理由に検収拒否してきたり、
些細な記述漏れを引き合いに、仕様が明確でないシステムは稼働させられないとか言い出して、稼働延期&稼働まで強制的に立会い延長になったり。
44 名前：仕様書無しさん mailto:sage [2011/12/20(火) 15:47:53.04 ]: >>43
それはお前のせいじゃ、ドアホ
45 名前：仕様書無しさん mailto:sage [2011/12/20(火) 18:27:26.88 ]: アホでもわかりやすいところは詳細に書いて、説明が面倒臭いところは適当にごまかす
初期処理と終了処理はソースコードレベルの細かいこと書いてるのに
肝心の主処理は「ファイル変換を行う」の一言だけ

コーダーのための詳細設計書なんて見たことないんで書き方もわかりません
46 名前：仕様書無しさん mailto:sage [2011/12/20(火) 18:36:16.08 ]: そうそう。
納品物件としての仕様書は誤りが書いてないこと、体裁が整ってることが最重要。
それを見てコーディングができるかどうかはまったく評価対象外。
47 名前：仕様書無しさん mailto:sage [2011/12/21(水) 18:35:33.03 ]: だから設計と製造は切り離したほうがある意味確実なんだよね…

保守さえ考えなければ
48 名前：仕様書無しさん mailto:sage [2011/12/22(木) 00:37:25.26 ]: わかってない奴がわかった気分になるための説明書であることが多いよな
実装を前提とした検討用の設計書になってるものを見たことがない
49 名前：仕様書無しさん mailto:sage [2011/12/22(木) 00:40:23.62 ]: わかってない奴に見せてわかった気分にさせるための説明書、か
そして出来ない奴ほど体裁に死ぬほどこだわる
まったくこだわらない奴も出来ない奴だけど

あと文体とかかき方にルールを設けるくせに
Excel方眼紙を卒業できない馬鹿も多いよな
自由度が高いツールを強制して、自由に出来ないように無駄なルールをつくりあげ、
仕事を増やすのが得意技！みたいな
Excelで方眼紙で糞ルールたくさん作られるくらいなら、まだ糞Word使ったほうがマシだわ
50 名前：仕様書無しさん mailto:sage [2011/12/22(木) 03:04:13.29 ]: 個人的には、体裁が整ってることは大切であり、
納品物あるいは後々の保守を考えれば最低条件であると考える

問題は文書作成環境にある
Excel/Wordとも短いレポートを手軽に作成するのには最適なツール
ただし、これを数百ページにおよぶ技術系文書(仕様書/設計書/マニュアル等)に
利用する発想が、適材適所という言葉を知らぬ人が犯す基本的な間違い
51 名前：仕様書無しさん mailto:sage [2011/12/22(木) 06:20:58.90 ]: >>48
> 実装を前提とした検討用の設計書
うちはこういうのばかりだ。
おかげで、他人が見たら「どうコーディングするべきなのか」はわかっても
「どういう意図でそうなってるのか」がまったくわからない状態になってる。

> わかってない奴がわかった気分になるための説明書
メンテナンスする立場で言うと、わかってる奴にしかわからない設計書なんか
残されても、まったく嬉しくないんだ。
52 名前：仕様書無しさん mailto:sage [2011/12/22(木) 08:42:43.20 ]: >>51
どういう意図で、は要件定義から追えば分かるんじゃないの？
分からないと保守更改で死ねる
53 名前：仕様書無しさん mailto:sage [2011/12/22(木) 11:53:45.51 ]: >>50
むかし社内で議論したけど、誰でも開けて編集できて、となると他に候補が無いんだよね。
でも開く環境が変わるとテキストがズレて崩れるけど（爆笑

Word使うなら箇条書きの範疇で済ます。
凝りたいならPowerPoint＋PDFかInDesignでごゆっくりどうぞ。
ということにしてる。
54 名前：仕様書無しさん mailto:sage [2011/12/23(金) 13:38:32.56 ]: 「Excel方眼紙滅べ！それで仕様書つくるやつもぜんぶ滅んでしまえ！」
「Wordは糞だが選択肢が他にないんだよな」ってのが前提にある奴です
Wordを推したいわけではないけど、Excel方眼紙で設計書作るくらいならWordのほうがいい

>>50
使いやすいとか最適だとは一切思わんけど、Wordはそういう文書作成に使う物じゃね
もちろんExcelはない。使い捨てのレポートみたいなフリーフォーマットで使い捨てるものなら方眼紙は便利だと思うけど

>>51
言葉足りずで申し訳ない
48で言ってるのは、あくまでも「設計書」に書く内容の話な
そういうわかってない人への説明や方針決めの経緯は、
もっと上流の要件定義だったり、補足資料として別に纏めるものだと思う
そういうのがかかれてないドキュメントに恵まれてるのは、いい環境だと思うけどな

>>53
Wordの基本機能ですら、世間一般に「凝ってる」レベルだって捕らえられちゃうことが一番の原因だと思うわｗ

ドキュメント関連でWordを使う利点は、文章を書く以外のことに気を使わなくてよくなる、ってところと
体裁だけを全体纏めて修正でき、印刷のことも考えなくて済む、ってところ。このあたりが表計算ソフトのExcelにはない

ただ、それぞれの機能が使い難いし、理解しづらい
なにより、そういう基本機能ですら理解出来ない、しようとしない奴が多すぎて、まともに使われることが少なく、
仮にちゃんと作られてるドキュメントでも、そういう理解能力がない馬鹿が一人チームに混じってるだけで
簡単に設定されてる体裁の破壊が出来てしまうから、使えないツールになりがちなのよね
55 名前：仕様書無しさん mailto:sage [2011/12/23(金) 13:40:57.60 ]: >>51
>おかげで、他人が見たら「どうコーディングするべきなのか」はわかっても
>「どういう意図でそうなってるのか」がまったくわからない状態になってる。
うちではわかってないヤツ向けの仕様書書いてるけど、そのわかってないヤツが
意図とか書くと余計なこと書くなって言ってくる
なもんで「どういう意図でそうなってるのか」は偉い人から口頭で聞いてソースのコメントに書いておく

> メンテナンスする立場で言うと、わかってる奴にしかわからない設計書なんか
> 残されても、まったく嬉しくないんだ。
わかってないヤツの想定が違う
OSって何ですかレベルのヤツを指してる
>>51の組織ならそのプロジェクトに参画してなくてもコーダーなら理解でできる仕様書を書きやすい気がするが
そういう組織に属したことないからよくわからんけど
56 名前：仕様書無しさん mailto:sage [2011/12/23(金) 13:54:01.69 ]: >>53
あ、あと、PowerPointとかinDesignで設計書はないわｗ
何のための設計書かがわからなくなる
それやるくらいならまだExcel方眼紙にオブジェクト張って済ませばいいと思う

そういや、ここじゃないどっかでみたけど、
Wikiを設計書に使うってのも結構面白い発想だなって思った
バックアップ含めて管理面での自動化できるし、差分や履歴も簡単に見れる
2拠点間での共有も楽で、一元管理もしやすい

図説みたいな自由度への制限とか、環境の構築が必要だとか、他に提出するときどうするの、とか
ドキュメントとレイアウトがどうしても混ざってしまうような欠点もいっぱいあるんだけど、
外に出ないものなら結構便利そうではある
57 名前：仕様書無しさん mailto:sage [2011/12/23(金) 14:14:41.55 ]: >>55
> わかってないヤツの想定が違う
そうそうｗ
文章を読むことすら出来ないような人とか、特にそういうこといってくるｗ
箇条書き、図説、表あたりしか理解してもらえない。
そういうのは設計書じゃないだろって思うけど、その思いは言葉にしても届かない！
結局本当の設計書は各担当の頭の中で作成されちゃうのよね

自分も他に書ける場所がないする事はできるだけコメントに残したりしちゃう派だけど、
ソース弄る奴にも、先にあげたようなのが混ざったりする事もあるから
保守されないコメントが、現状の実装と異なる状態になるかもしれなくて、コメントに残しすぎるのも怖いんだよな
マに免許とかそういうのはないし、コーダーのレベルもピンキリ激しい
あとコメントじゃレビューとかもないから、誤記ったりしてもそのまま残る可能性が怖い…
58 名前：仕様書無しさん mailto:sage [2011/12/23(金) 15:10:40.62 ]: はぁ？

設計書って言ったら図だろ。

お前車とか家とかの設計書見たことあるのか？
59 名前：仕様書無しさん mailto:sage [2011/12/23(金) 15:24:27.50 ]: あはっ♪
設計書って言ったら、ﾌﾂｰ「設計書がどうしたんや！何して欲しいんかちゃんと云いなはれ。そんなんで伝わると思うたらおお間違いや」
設計書是也設計書。
設計書見たことあったらどうなのか？無かったらどうなのか？もったいぶってても大した話じゃないならとっとと話を進めなさい。
60 名前：仕様書無しさん mailto:sage [2011/12/23(金) 15:44:03.59 ]: つーか、設計書を曖昧に自然言語で書くなよ。
61 名前：仕様書無しさん mailto:sage [2011/12/23(金) 16:52:30.19 ]: たしかにマも土方だが、そういう方面の土方ではないぞ。
62 名前：仕様書無しさん mailto:sage [2011/12/23(金) 16:56:26.25 ]: 理解能力がない人に見せる資料は設計書とは分けたほうがいいけど、理想どおりにはいかないしな。
結局頭の中が下の連中に合わせないといけなくなる。
63 名前：仕様書無しさん mailto:sage [2011/12/23(金) 18:12:55.40 ]: >>60
自然言語で表現できないかしづらい内容までドキュメント化しろなんては思ってないよ
シーケンス図とかクラス図で済むことならそっちでやるし
きっちりかっちり自然言語を使わず表現できる部分なら、それはもうコーディングしちゃえばいいんじゃね

>>62
まぁ結局そうなるんだよな
64 名前：仕様書無しさん mailto:sage [2011/12/23(金) 18:14:46.69 ]: > きっちりかっちり自然言語を使わず表現できる部分なら、それはもうコーディングしちゃえばいいんじゃね

うん。だから設計書＝コードなんだってば。

日本語は、コメントとして書けばいい。
65 名前：仕様書無しさん mailto:sage [2011/12/23(金) 18:27:27.47 ]: プログラム設計書は要らないと思うが、それより上の工程でのドキュメントは必要。
66 名前：仕様書無しさん mailto:sage [2011/12/23(金) 18:31:32.60 ]: >>65
ISOなんとかのためなのかどうかは知らないけど、
プログラム設計書は求められる現場が多い。
それより上の工程のドキュメントは無くても。
67 名前：仕様書無しさん mailto:sage [2011/12/23(金) 19:26:36.89 ]: >>66
上の工程のドキュメントはどんなにわけわからんこと書いてても
我々に文句言う権利ないしね
68 名前：仕様書無しさん [2011/12/29(木) 20:13:18.23 ]: >>4
プログラム設計書は重要じゃないけど
プログラム設計は重要
この重要性が現場でも理解されてないからプログラマの地位は低い
69 名前：仕様書無しさん mailto:sage [2011/12/29(木) 23:33:00.91 ]: 設計書くのは重要だと思うけど、最低限まともにレビューできる奴がいないと、作る意味がないんだよな
的外れな指摘しかされてない、半端な設計書なんて用意しても、結局糞の役にも立たないなんてことになるしなぁ
70 名前：仕様書無しさん [2011/12/29(木) 23:48:36.19 ]: レビューは、その場で見て思いつきで指摘して終わるからな
ちゃんと修正されたか再レビューしないことも多いし
儀式的なものになり果てている

担当を複数人にしてお互いにチェックするという仕組みにしたらいいと思うんだが
71 名前：仕様書無しさん mailto:sage [2011/12/30(金) 03:36:34.51 ]: >>70
それは単純に開発プロセスの問題な気がする。
プロセス監査とか無いの？

結局開発者自身が本当に改善したいと思ってるかどうかと、
さけるリソースがあるか、によるんだよなぁ。
実際真面目に取り組むとちょーメンドくてしんどい。
けど効果はある。
72 名前：仕様書無しさん mailto:sage [2011/12/30(金) 10:14:50.14 ]: 開発プロセスの問題じゃなくて、
各々の文章チェック能力、設計力の問題だろ。
73 名前：仕様書無しさん mailto:sage [2011/12/30(金) 13:08:13.71 ]: そら有能な個人の力に頼るのが早いてのは分かるけどさ。

再レビューが無いのが問題だと感じてるなら、
再レビューしたかチェックする機構があるべきだし、
「指摘がその場の思い付き」「儀式的になってる」とか、
不具合流出の分析とそれによる対策がされて無いわけじゃん。
レビュー観点の整理とか、インスペクションの導入とか。
実際>>70自身言ってる「チェックの仕方」自体プロセスそのものだし。

低レベルでの開発プロセス定義なんて、最低以下の人間に
最低限の仕事させるためのもんだよ。
高生産性や高品質はその次の話。
74 名前：仕様書無しさん mailto:sage [2011/12/30(金) 13:43:16.95 ]: d.hatena.ne.jp/iad_otomamay/20111207/1323276264
75 名前：仕様書無しさん mailto:sage [2011/12/30(金) 13:44:56.99 ]: 低レベルの人間に何回チェックさせても無駄。
プロセス重視することと、内容を軽視することは同義。
76 名前：仕様書無しさん mailto:sage [2011/12/30(金) 14:32:32.56 ]: ＞プロセス重視することと、内容を軽視することは同義。

レベル低くて笑える。
それ素振りやっただけで上手くなった気分になって満足してる奴らの話だろ。
まぁ好きにしたらいいよ。
77 名前：仕様書無しさん mailto:sage [2011/12/30(金) 14:43:31.28 ]: プロセスを突き詰めて問題が解決するなら
docomoの障害は起きなかっただろう
78 名前：仕様書無しさん mailto:sage [2011/12/30(金) 14:50:18.73 ]: 無駄なプロセスばかりが増えていく。
内部統制とかいい例。
79 名前：仕様書無しさん mailto:sage [2011/12/30(金) 14:55:27.70 ]: プロセスを突き詰めても
人間がある以上トラブルは発生する。

だがプロセスがなければ
もっと多くのトラブルが発生する。
80 名前：仕様書無しさん mailto:sage [2011/12/30(金) 14:57:06.08 ]: >>73が自分で言っているように

＞低レベルでの開発プロセス定義なんて、最低以下の人間に
＞最低限の仕事させるためのもんだよ。

こういうことなんだろう。

そもそも最低の人間を使わなければいいのに。
81 名前：仕様書無しさん mailto:sage [2011/12/30(金) 15:01:14.00 ]: 自称上級者が簡単なことを
やらないからいけないんだろうな。
82 名前：仕様書無しさん mailto:sage [2011/12/30(金) 16:38:54.26 ]: 低レベルの人間大量に投入してプロジェクト上手く回すのがプロマネの仕事です。
レベル高い人間を集めるられることを前提に計画建ててる時点で破綻してる。
83 名前：仕様書無しさん mailto:sage [2011/12/30(金) 16:54:01.72 ]: >低レベルの人間大量に投入してプロジェクト上手く回す
ってのは可能なのか？
84 名前：仕様書無しさん mailto:sage [2011/12/30(金) 17:23:42.55 ]: >>82
ソフトの世界は量ではなく質なので
その方法では一流になれません。
85 名前：仕様書無しさん mailto:sage [2011/12/30(金) 17:26:31.44 ]: 質の良いソフトがビジネス的に成功した例は皆無だよ。
WindowsとかOracleとかのバグの多さを見れば明らかだろう。
86 名前：仕様書無しさん [2011/12/30(金) 17:29:43.68 ]: ビジネス的に成功　と　バグの多さ　にどういう関係が？
87 名前：仕様書無しさん mailto:sage [2011/12/30(金) 17:30:54.35 ]: >>85
低レベルの人間を大量に集めて
WindowsとかOracleを作れると思ってるなら
おめでたいな
88 名前：仕様書無しさん mailto:sage [2011/12/30(金) 17:33:25.76 ]: 質より量を重視した結果バグだらけになっても、多機能を売りにビジネス的には成功するって話。
89 名前：仕様書無しさん mailto:sage [2011/12/30(金) 17:35:04.30 ]: >>87
本気で高レベルの人間が、少数精鋭で作ってると思ってるなら頭おめでたいですね。
90 名前：仕様書無しさん [2011/12/30(金) 17:39:40.42 ]: 人が大量にいないと作れんが
その人達は全員がある程度高レベルの人間でないと作れない
特に優秀な人が必要なのはプログラマレベルだろう

例えば日本のゼネコンシステム会社にMFCとか.NETライブラリとか作れるか?
上流工程(藁)SEには作れないし、寄せ集めプログラマ作れるものではない
91 名前：仕様書無しさん mailto:sage [2011/12/30(金) 17:40:06.15 ]: Microsoftはバグですらビジネスに利用して一流になったわけだし。
新しいバージョンではバクやセキュリティホールが治って価値が上がってる、だから新バージョンを買ってくれってね。
92 名前：仕様書無しさん mailto:sage [2011/12/30(金) 17:45:26.88 ]: 残念ながらOS作ってる奴らの大半は、寄せ集めの短期契約プログラマーだよ。
93 名前：仕様書無しさん mailto:sage [2011/12/30(金) 17:47:53.64 ]: え、マジで？
デビッドカトラーとかは伝説なの？
94 名前：仕様書無しさん [2011/12/30(金) 17:54:50.00 ]: >>92
正社員か下請けか派遣かとかの所属のことを言ってるんじゃないよ
95 名前：仕様書無しさん mailto:sage [2011/12/30(金) 18:07:55.47 ]: 著名な人間の間違いは指摘できないから、それが正式な仕様としてドキュメント化されるプロセスが定着してしまったんだろうね。
今のwindowsは糞仕様が多すぎる。
96 名前：仕様書無しさん [2011/12/30(金) 18:16:30.51 ]: 「仕様がクソ」と多くの人が言うが、「どこがクソ」かを言う人は少ない
97 名前：仕様書無しさん [2011/12/30(金) 18:21:10.54 ]: >>96
そいつが、そういう仕様になってる理由を理解できる頭がなく
分かってないだけのことも多い
単に自分の分担分の作業が増えて面倒だというだけの理由の場合もあるな
98 名前：仕様書無しさん mailto:sage [2011/12/30(金) 18:24:17.49 ]: バグ報告のサイトで散々言ってるから。
99 名前：仕様書無しさん mailto:sage [2011/12/30(金) 21:04:55.59 ]: >>87 >>90
多人数大規模の開発ってのをなんか勘違いしてるでしょｗ

まず前提条件として、大規模っていうの数万、十数万人月という工数で
すごいプログラマが通常の10倍の生産性だったとしても
1000ヶ月、83年、そんなに時間かけられますかって話なんだよ。

WindowsとかOracleとかそんなのは難しいだけで工数はそんなに必要ない。
簡単だけど工数は大きいという仕事のほうが世の中には多いんだよ。
OSやDBMSなんて殆どの人は使うだけで作ったりしないでしょ？

そしてOSやDBMSを使うだけの仕事に、OSやDBMSを開発できる人間を
担当させるのは、どう考えても仕事の振り方間違ってるよね？

そして仕事である以上、納期とコストの事を考えないといけない。
工数から考えて、少数のすごいプログラマだけで作れる期間は与えられない。
なら、すごくないプログラマを投入するしかない。これは絶対条件。

じゃあどうするか。ここまで考えてものを言ってる？
100 名前：仕様書無しさん mailto:sage [2011/12/30(金) 21:05:54.53 ]: >>93
戦うプログラマー読んだけど、優秀な人間を大量に集めてやっとNTが作れた
からな。　アレで分かったことは、大規模開発には大量の人が必要です、
可能な限り優秀な人間が大量に。ただ人を入れればいいというわけでは
ありませんってこと。　人月の神話で言われてる、人を入れてもロスが多い
云々ってのをロスがあっても優秀な人間で底上げするっていうこと。
101 名前：仕様書無しさん mailto:sage [2011/12/30(金) 21:09:50.44 ]: > 可能な限り優秀な人間が大量に。
それは現実的ではない。

そんなに人捕まえられないし、
優秀な人間はコストがかかる。

俺が提案する方法（普通の方法だが）は
システム全体を難しい部分と簡単な部分に分離していく。
難しい部分は優秀な人間が、簡単なところは技術力が低いプログラマが。

Windowsみたいにいくらでもコストが掛けられるような場合はいいが
実際はこういうふうにして行かないとやっていけないでしょ。
102 名前：仕様書無しさん mailto:sage [2011/12/30(金) 21:17:54.26 ]: システムに簡単な部分と難しい部分があることに
気づかない人って理解出来ない。
一人でシステムすべてを作っているからその違いを考える必要がないのかな？

上級プログラマ、つまりアーキテクトとしての力があると自然とシステムを
難しいコアの部分と簡単な末端部分に分けると思うんだが。

コアの部分は重要だけど規模としては小さくなる。末端部分は簡単だけど数は多い。
普通こうなるし、こうなるように設計するはずなんだ。

そしてシステムを分離した時、他に人がいるなら簡単な末端部分を
アーキテクトである自分がやるのは効率が悪い。
一介のプログラマで十分って気づくよね？

これが最適化されたシステム開発の姿だと思うんだが。
103 名前：仕様書無しさん mailto:sage [2011/12/30(金) 21:36:32.25 ]: 80:20の法則ってのがある。プログラムのパフォーマンスの80%はソースコードの
20%が出しているっていうやつ。オフショアに出して安く上げることを考えるに
しても、そういうコアな20%の部分を自分の所でキープ出来るかでプロジェクトの
成否が別れたりする。たいがい、まとめてドーンて出してドーンて失敗するん
だけどね。
104 名前：仕様書無しさん mailto:sage [2011/12/30(金) 21:44:22.22 ]: 80歳まで20本の歯をｷｰﾌﾟって歯無し
105 名前：仕様書無しさん mailto:sage [2011/12/31(土) 02:30:31.77 ]: そもそも大規模な仕事をやる必要があるのか？
金掛けて糞積むようなもんでしょ。
106 名前：仕様書無しさん mailto:sage [2011/12/31(土) 02:44:58.74 ]: 金さえあればどんな仕事もやる必要はないよｗ
107 名前：仕様書無しさん mailto:sage [2011/12/31(土) 02:57:52.93 ]: >>105
この業界に生きるものとしてそれを言ってはいけないwww
俺らが生活できるのは誰のおかげかwww

あるテーブルの値を合計して別なテーブルに書きこむとかいう処理を
何十万かけて作って、それを何百本と作って、何十億円の巨大プロジェクトとか
作ってて虚しくならないかと思うんだけどだけど >>99 とかはそういう巨大さに充実感を感じるんだろう

実際に稼働することで開発費以上の利益を生むわけだし、お客が納得してれば別にいいんだけど
108 名前：仕様書無しさん mailto:sage [2011/12/31(土) 03:07:08.76 ]: >>107
充実感？
お前の個人的な基準を人に押し付けないでね。
109 名前：仕様書無しさん mailto:sage [2011/12/31(土) 03:09:36.92 ]: >>107
俺にとっての充実感は多くの人を管理して
少ないコストで大規模なシステムを作り上げること。
末端の作業をやって充実感があるわけ無いだろｗ
そんなものは部下にやれと命令する。これもまた充実感。
110 名前：仕様書無しさん mailto:sage [2011/12/31(土) 09:43:06.33 ]: ソフトは

大規模 = 価値がある

わけじゃないんだよね。
111 名前：仕様書無しさん mailto:sage [2011/12/31(土) 09:47:30.43 ]: Gmailはシンプルな仕様で工数的にはそんなに掛かってないはず
でも世界中の人が利用してる。

これからの時代、SIerも淘汰が始まると言われている。
金持ちに粗悪品売るような商売も長く続かないだろう。
112 名前：仕様書無しさん mailto:sage [2011/12/31(土) 09:55:41.34 ]: 請負やってりゃ客の金をたくさん取るのが正しいんだろうけど
それがソフトのあり方だと思わないで欲しいね。

自社サービスやってればそんな発想は出てこないだろうに。
113 名前：仕様書無しさん mailto:sage [2011/12/31(土) 10:30:52.64 ]: >>110
そんなの当たり前だろｗ

なんでそんなことを言うのかしらんが、
もしかして、大規模なら価値がないとでも
言いたいのか？
114 名前：仕様書無しさん mailto:sage [2011/12/31(土) 10:39:48.70 ]: >>111-112
何をそんなに否定したいのかさっぱりわからんのだが。
話をまとめるぞ。

・優秀なプログラマを必要な数だけ揃えられるとは限らない。
・優秀なプログラマであっても、ものを作るには時間がかかる。
・どこの会社にも、優秀なプログラマよりも、技術力の低いプログラマはいる。
・手に入るカードで最短の時間とコストで作る必要がある
・うまく人を配置しましょう。
・そのためにシステム全体を重要なコアとそうでない部分に分ける必要があります。
（・俺の仕事は重要なコアの作成とそうでない部分の分離です）
・簡単なところは技術力の低いプログラマにまかせます。
・技術力の低いプログラマは経験を積んで技術がついてきたら徐々に重要な所を担当させます。

これのどれを否定したいんだ？現実的なやり方だろ。
否定しなきゃならない理由でもあるのか？
115 名前：仕様書無しさん mailto:sage [2011/12/31(土) 10:44:25.43 ]: >>113
大規模 = コンパクトにする努力をしてない
と思う。
116 名前：仕様書無しさん mailto:sage [2011/12/31(土) 10:50:43.25 ]: >>114
規模が大きければそうせざるを得ない。
ただ、その規模必要なの？
117 名前：仕様書無しさん mailto:sage [2011/12/31(土) 10:53:25.11 ]: docomoの障害だってそうだよな
何重ものいらんチェック付けて工数増大させてる割には
肝心なところが抜けてる
118 名前：仕様書無しさん mailto:sage [2011/12/31(土) 12:00:58.87 ]: >>115がすべて
規模の大小なんて大した問題ではない。
努力が足りないだけ。
119 名前：仕様書無しさん mailto:sage [2011/12/31(土) 12:09:58.89 ]: >>116
規模の大小に関係なく、
開発期間とコストを下げるには必要なこと。

大規模ではもちろんのこと、小規模であっても
小規模なら会社も小さく、優秀なプログラマを雇う金もないし
人も来ない。

最初から技術力が高い人を手に入れられるわけじゃないんだよ。
金があったとしても、必要なときにすぐに来てくれるわけでもない。

それが現実。
120 名前：仕様書無しさん mailto:sage [2011/12/31(土) 12:14:56.82 ]: >>117
そうだよね。

難しいコアの部分と簡単なところを分離してないからいけない。
docomoなんかは、コア優秀な人を十分に割り当てられなかったのが原因。

大会社になれば優秀な人は社内のどこかにいるはず。
そういう人がつまらない仕事をしていたのだろう。

コアと簡単な所を分離する。こがまさに大規模なものを
コンパクトにするということだよ。
そして少数のコアと多くの簡単な所に分けられる。

そして優秀な人の仕事を減らしつつ、簡単だが量が多い所に
適当に集めた人材を大量投入する。
121 名前：仕様書無しさん mailto:sage [2011/12/31(土) 12:34:56.56 ]: 神は細部に宿る
これはソフトにも当てはまると思う。

簡単だからといって適当な仕事をされたら、たまったもんじゃない。

アーキテクトの目が届かない範囲にまで規模が膨れたら
それはもう分を超えているのではないか。
122 名前：仕様書無しさん mailto:sage [2011/12/31(土) 13:12:47.30 ]: プログラマとして、自分の受け持つ設計やコード等に神を宿す努力をするべきだが、ビジネスの場にそれを持ち込むのは、切り分けができていない二流。

全体のレベルが高くある必要があると思うなら、均一なレベルにできるシステムを考えろよ。(そもそも、俺が考えた最強のが多い気がするが)
お前らは、自分ができる奴だと思いたい、出来ない奴を叩きたいだけで、実際はご近所さんで毎日集まって愚痴ばかり並べてる様なそこらの主婦となんら変わらないクズなんだよ。
123 名前：仕様書無しさん mailto:sage [2011/12/31(土) 13:31:33.09 ]: >>115
100万行のコードをいくらコンパクトにしても一万行に収まるわけじゃないからなぁ。
124 名前：仕様書無しさん mailto:sage [2011/12/31(土) 13:35:08.15 ]: >>111
> Gmailはシンプルな仕様で工数的にはそんなに掛かってないはず
> でも世界中の人が利用してる。

お前みたいに、UIだけで中身を判断する馬鹿がいるから苦労すんだよ
125 名前：仕様書無しさん mailto:sage [2011/12/31(土) 14:29:12.55 ]: >>114
横レスになるが、自分も同感だね

>>123が現実だから
126 名前：仕様書無しさん mailto:sage [2011/12/31(土) 15:43:10.30 ]: >>124
中国意外な。
127 名前：仕様書無しさん mailto:sage [2011/12/31(土) 16:06:58.09 ]: >>114
理念としては正しい方向性であると思う
というか、昔から同じような事は言われてきた
では、そんな当たり前の事を実践できていないプロジェクトが現実に多いのはナゼか？
という話になる
自分の想像を二点挙げる

まず最初に、>>114では「優秀」という単語が何度も使われているが、
この優秀度を定量的に(=公平かつ正確に)計測するのが難しい点
いわゆる自己申告というものはアテニナラナイ

次に、それら稀少かつ優秀な人材を「開発に着手する前に」最適に配置するのが難しい
まだシステムが形になっていない段階で最適な配置を決定するのは、
高度な未来予測(いわゆる「見積もり」)能力が要求される
また優秀な人物でもすべての分野で完璧という訳ではなくて得手不得手な分野がある
そして優秀な人物は自己過信になりがちだから、ここでも自己申告はアテニナラナイ
128 名前：仕様書無しさん mailto:sage [2011/12/31(土) 17:28:04.53 ]: よくある失敗パターンが、システムのコア部分は精鋭を集めて作れたんだけど、
人数集めて作り始めた周辺部分がぐだぐだになってしまうというやつだな。

ユーザの要望や度重なる仕様変更に晒されて肥大していくのは周辺部分なんだから、
ここに大規模ソフト開発や膨大な仕様の把握などに対応し切れない人を当てると
ぐだぐだになる。
129 名前：仕様書無しさん mailto:sage [2011/12/31(土) 18:47:22.24 ]: 目に見えない制御部分が優れていることより、目に見えるUIが優れていることが優先されるからな。
130 名前：仕様書無しさん mailto:sage [2012/01/03(火) 04:25:04.28 ]: >>96
いろいろとあるが、
OS領域と、ユーザーアプリケーション領域、ユーザーデータ領域が、明確に別れていない部分が糞。
OSが不安定になって再インストールとか、それによってユーザーデータが消えるとか、アプリケーション一つずつ入れ直すとか本来あり得ない思想が前提になってる。
131 名前：仕様書無しさん mailto:sage [2012/01/03(火) 08:09:39.88 ]: >>130
それは *** Windowsが糞 *** という話だね
すべてはレジストリが癌になっている
132 名前：仕様書無しさん mailto:sage [2012/01/03(火) 08:57:05.39 ]: >>131
お前、レジストリがシステムデータと
ユーザーデータでファイル自体分離されてるの知ってる？
133 名前：仕様書無しさん mailto:sage [2012/01/03(火) 08:58:20.12 ]: >>130
それはお前がフォーマットして
インストールするから消えるんだろｗ
134 名前：130 mailto:sage [2012/01/03(火) 16:14:34.56 ]: >>132
システムデータとユーザデータの分離なんて当然の事だろ
レジストリが癌なのは、集中型データベースかつバイナリ形式で保存されること
135 名前：131 mailto:sage [2012/01/03(火) 16:15:34.55 ]: >>134の名前欄を訂正

X: 130
O: 131
136 名前：130 mailto:sage [2012/01/03(火) 19:40:30.02 ]: >>134
ユーザーデータがレジストリとして管理上分離されてても、それのバックアップをとって他環境に復元出来なけりゃ意味ないよ。
137 名前：仕様書無しさん mailto:sage [2012/01/03(火) 19:43:09.84 ]: ユーザー用のレジストリファイルならコピーして
他環境に持って行って普通に使える。
138 名前：仕様書無しさん mailto:sage [2012/01/04(水) 02:09:53.63 ]: 可能ではないけど手間が段違いだからな
しかもあまり一般的じゃないから情報も少ないし保障もない
そういう事が考慮されていない糞設計ってことには違いないよな
139 名前：仕様書無しさん mailto:sage [2012/01/04(水) 03:07:19.18 ]: >>41-44
ワロタエナイ
文書表現ばかりこだわる奴が炎上プロジェクトに投入されると、ますます燃え盛るw
140 名前：仕様書無しさん mailto:sage [2012/01/04(水) 08:10:08.82 ]: >>138
じゃあ、一般的に
レジストリをエクスポートして
インポートすればいいだけじゃね？
何難しく考えてるのよｗ
141 名前：仕様書無しさん mailto:sage [2012/01/04(水) 13:00:51.83 ]: 要件定義がぜんぜんできてない段階で、設計書に着手してるアホばっかだから、
設計書を書いてそれを客に提示して、お伺いを立てるなんて発想が出るんだよ･･･。
だから設計書も設計ではなく要件を書くようになっていって、
肝心の部分がぜんぜん詰められてない状態になって、ただのゴミドキュメントと化す。
全部爆発しろよもう！

っていう愚痴
142 名前：仕様書無しさん mailto:sage [2012/01/04(水) 13:50:23.51 ]: >>141
「お客はいったいどんなプログラムを作って欲しいのか、
　そのプログラムの仕様を自分でも理解していない」

「プログラマは客の要求する仕様に合わせてプログラムを作るのではなくて、
　自分の作ったプログラムの仕様を客の仕様だとごまかしている」
143 名前：仕様書無しさん mailto:sage [2012/01/04(水) 18:31:27.55 ]: local.joelonsoftware.com/wiki/ビッグピクチャー
144 名前：68 mailto:sage [2012/01/05(木) 00:05:27.92 ]: >>141 >>142
何でみんな作る前に仕様を決めたがるんだろうね
作りながら仕様決めながら要件定義するスパイラルでいいじゃん

やたら細部の体裁にこだわってる仕様書を改訂する作業は面倒だと思うが
プログラマまで仕様変更を嫌がるんだもんな
145 名前：仕様書無しさん mailto:sage [2012/01/05(木) 00:27:20.87 ]: >>141
客が設計書を出さないと要件は言わないってさ
しかも要件に合わせて設計書の修正は禁止

>>144
プログラマの立場で仕様変更を嫌がる理由は大抵は仕様改悪にしか見えないから
146 名前：仕様書無しさん mailto:sage [2012/01/05(木) 01:50:55.46 ]: >>141
SI側も客自身も業務を理解してないし、
どういう仕組みを作ればいいかも明確じゃないんだろうね。
漠然と市販ソフトみたいにシステム入れれば、コストが削減できるとか思ってる。
147 名前：仕様書無しさん mailto:sage [2012/01/05(木) 23:12:42.51 ]: 要求定義書→総合テスト
基本設計書→結合テスト
詳細設計書→単体テスト

設計書にはテスト項目の定義を書く。
テストは設計書の内容が確実に実装された事を確認する。
テストってのは、外部から見た動きだから、設計書も
内部的なとこはわりとどうでもいいんだよね。
148 名前：仕様書無しさん mailto:sage [2012/01/06(金) 08:30:59.17 ]: >>145

設計書ださないと要件ださないって、、順序おかしくね？
設計書じゃなくてそれは提案だとおもうのだけど、先に設計書つくらせるのは大手なら先行着手でコンプライアンス違反だな
149 名前：仕様書無しさん mailto:sage [2012/01/06(金) 09:00:07.04 ]: >>148
頭の悪い客に付き合わされてるんだろ
150 名前：仕様書無しさん mailto:sage [2012/01/06(金) 20:31:44.49 ]: 作る物も教えずに設計図出せってw
マジシャンじゃないんだからw
151 名前：仕様書名無しさん mailto:sage [2012/01/06(金) 20:44:29.53 ]: 画面設計書とかある程度の叩き台先に作って見せないと打ち合わせが進まない。
要件がよく分からないからって設計書作らずに打ち合わせ行ったら、何も用意せずやって来て無駄な時間取らせるんじゃないと、一蹴されるよ。
152 名前：仕様書無しさん mailto:sage [2012/01/06(金) 20:51:37.53 ]: それは設計じゃなく要件定義だろ
153 名前：仕様書無しさん mailto:sage [2012/01/06(金) 21:17:18.58 ]: >>151,152

See >>142
154 名前：仕様書無しさん mailto:sage [2012/01/06(金) 22:06:44.06 ]: >>153
だから、要求を洗い出して、客に提案して、合意をとった上で始めて設計が固まるだろ。
その安価は何が言いたいんだ？
155 名前：仕様書名無しさん mailto:sage [2012/01/06(金) 22:07:24.61 ]: 要件定義で画面レイアウト決めるのは要件定義ですか？
156 名前：仕様書無しさん mailto:sage [2012/01/06(金) 22:07:36.12 ]: >>151
あとそれ、サンプルと提案書な
157 名前：仕様書無しさん mailto:sage [2012/01/06(金) 22:11:34.32 ]: 外部設計と内部設計の話を混ぜるな
158 名前：仕様書無しさん mailto:sage [2012/01/06(金) 22:54:36.05 ]: 画面仕様を設計だと言い張るSEがいたなぁ。
自分が設計までしたんだから、あとはPGの仕事だと。
159 名前：仕様書無しさん mailto:sage [2012/01/06(金) 23:47:00.77 ]: 今できる最適解は、
プロジェクトやメンバの性質にマッチした仕様書・設計書を適切なタイミングで作成すること。
これに尽きる。
必要な成果物は常に考えながらプロジェクト遂行しなければならない。
成功プロジェクトや経験だけに頼ったやり方はダメ。怠るとデスマ確定。

嫌なら法整備して厳格にすべき。この産業はいつになったら法整備されんだよ。
160 名前：仕様書無しさん mailto:sage [2012/01/06(金) 23:51:47.90 ]: 合意をとった上で始めて設計が固まる　と思ってるなら、まだ青臭いな。
合意はその時点での合意でしかない。
161 名前：仕様書無しさん mailto:sage [2012/01/07(土) 00:20:57.53 ]: >>99
サラリーマン思考で乙としか言えないな。

>WindowsとかOracleとかそんなのは難しいだけで工数はそんなに必要ない。
あんた業務システムしか経験したことないでしょ？
知らない分野のことは安易に言い切るなよ。
一般に高難易度のものは工数積むだろ。
162 名前：仕様書無しさん mailto:sage [2012/01/07(土) 00:53:57.55 ]: >>160
いや、そうあるべきって話しであって、必ずそうでなければならないとは言っていない。
設計と要件定義をごっちゃにしてる奴がいたから言っただけ。
会社にとって総合的に利益のほうが上回る事が見込まれるのであれば、カチカチの行程なんてたどる必要はない。
163 名前：仕様書無しさん mailto:sage [2012/01/07(土) 02:37:44.26 ]: 顧客要求事項が曖昧なまま設計しても、すぐに行き詰まって、手戻りが起こる。
コストばかり費やして成果物は完成しない。
予算も納期も限られてるのだから、ある程度踏ん切りつけさせろ。
機能を諦めさせるか次の開発に乗っけさせて貰うとか交渉が必要。
164 名前：仕様書無しさん mailto:sage [2012/01/07(土) 02:47:34.20 ]: >>159
法整備って、何を定めるんだよw
165 名前：仕様書無しさん mailto:sage [2012/01/07(土) 03:00:02.21 ]: >>163
結局、金ある所からなーなーで仕事もらうのが一番無難に儲かるという。
166 名前：仕様書無しさん mailto:sage [2012/01/07(土) 06:57:07.49 ]: >>159
>プロジェクトやメンバの性質にマッチした仕様書・設計書を適切なタイミングで作成すること。

「性質」やら「適切」とやらの定義が曖昧だね
これが

>成功プロジェクトや経験だけに頼ったやり方はダメ。

の典型例なのかな？
しかも

>必要な成果物は常に考えながらプロジェクト遂行しなければならない。

という精神論
たぶん>>159の担当プロジェクトは、いつも

>怠るとデスマ確定。

なんだろねw
167 名前：仕様書無しさん mailto:sage [2012/01/07(土) 08:06:00.21 ]: デスマするかしないかはドキュメントで決まるだろ
デスマで食ってるやつはドキュメントをわざと書かせないから、分かるよドキュメントなくて作業なんか進まないところにザコを沢山投入して上まえハネテ儲ける
そうゆうヤクザなやり方してんだよ
168 名前：仕様書無しさん mailto:sage [2012/01/07(土) 10:55:22.07 ]: >>162
カチカチの行程のほうが開発会社の利益になるんだ
臨機応変に効率的に要件を満たすソフトを作ってしまったら
工数も次フェーズの仕事も減ってしまう
169 名前：仕様書無しさん mailto:sage [2012/01/07(土) 11:23:10.97 ]: 結局実現可否まで判断しきれないと、ちゃんとした設計はできないし、手戻りも増えるから、
設計担当でも最低限のコーディング知識くらいは必要だよなホンと。
無能なSEやSIが上流に居座ってると、いいことがまったくない。
170 名前：仕様書無しさん mailto:sage [2012/01/07(土) 11:28:21.52 ]: デスマに必要な要素っていうと

-要件をまとめ切れない、仕様を確定できないままずるずる時間を無駄遣いする
-実現不可能な妄想をして手戻りを起こし時間を無駄遣いする
-時間がないや知識不足で仕様書を作成できず、実装担当に情報を渡さない
-スキル不足で実装ができないか大幅に遅れ、テストや改修時間がなくなる

こういうのがあるんじゃないかなと思うけど、
考えてみたらうちの職場は上3つが全部当てはまってる素敵なところだった
そんな状況で工数が不足し、新人投入しはじめたから4番目のもヒットしそうな勢い
やったね！
171 名前：仕様書無しさん mailto:sage [2012/01/07(土) 11:33:07.84 ]: >>168
あー…書き方わるかったかな。
カチカチのほうが確実な見込みが取れるから安全だけど、わがままな客やあまり頭の良くない客だとしても、利益が見込まれるなら受けるって話。
172 名前：仕様書無しさん mailto:sage [2012/01/07(土) 11:33:15.22 ]: デスマってるところは、大概何も考えずに
行き当たりばったりでコーディングしてる。

Railsとかフレームワーク使えば簡単に作れるとかいって
フレームワークの正しい使い方も調べずに
へんなやり方でトライして動いた、じゃあOK。で進めてる。

簡単に作れるというのも考えものだよ。
何も考えずに動いてしまうってことだから。
でへんなやり方になっていって、デスマに陥る。
173 名前：仕様書無しさん mailto:sage [2012/01/07(土) 11:35:48.66 ]: 本来は設計レベルを担当する人が
フレームワークの正しい使い方、ベストプラクティスを調べて
それを下っ端のプログラマに伝えるべき。

だから設計者はプログラミングを高いレベルで習得してなければならない。
デスマってるところは、設計者はプログラミングをしない。
そして全部下っ端プログラマに任せる。

で下っ端は管理されてない状況で好きかってやって
デスマを引き起こす。
174 名前：仕様書無しさん mailto:sage [2012/01/07(土) 11:49:32.69 ]: 昔みたいに要件や仕様をしっかりまとめてから開発するというやり方は変化が激しい今は
通用しなくなってる。だから、素早い開発が重要。そのためには拡張性と柔軟性を
備えたシステム基盤を作れないといけない。

この拡張性や柔軟性というのは、どんなものにも耐えられるものが目標だから、
要件や仕様は参考程度確定していればいい。そして作りたいシステムとは独立した、
汎用的な拡張性、柔軟性を持った設計の基盤の実装をシステム開発よりも先に行う。

作りたいシステムは短いコードですぐに実装できるよう、多くのものを汎用的な基盤に持っていく。
そこまで行っていれば、要件や仕様が変わってもすぐに対応できるし、
実現不可能かどうかを試すのもすぐに出来るようになる。

ここまでの説明でわかったとおり、要件とか仕様とかそういう話よりも
今は基盤の実装技術が極めて重要なんだ。そこができてればあとはどうとでもなる。
（正確には、どうとでもなるようなぐらいに基盤を作り込んでおく）
デスマを起こすところは作りたいものだけを考えて、基盤のことを一切考えていない。
175 名前：仕様書無しさん mailto:sage [2012/01/07(土) 11:52:16.58 ]: >>171
おまえは何回後付けしてんだよ。
現場にたまにいるわ。
そういう意味じゃないとか言いながら、ジワジワと意味を変えるやつ。
確固たる主張がないなら折れろよ。

言い逃れ野郎は、ひとつ否定されると全人格を否定されてるんじゃないかと思い込むからな。素直に認めろよ。
間違ったことだったとしても認めたらその場だけの馬鹿認定で済むんだぞ？
176 名前：仕様書無しさん mailto:sage [2012/01/07(土) 12:03:40.41 ]: >>174
君の考える基盤って、いわゆるフレームワークに限定してないか？
基盤というともっと低レベルだったり、ハードウェア選、インフラ系を含んだりする。
177 名前：仕様書無しさん mailto:sage [2012/01/07(土) 12:17:26.68 ]: >>174
変化が早いから素早い開発が要件されてるわけじゃなくて、
金がないから開発期間を短く設定するしかないんだよ。
本来は、3年5年かける規模をわずか半年で開発しているのが現状。
単にゴールを決めて開発してるに過ぎないんだよ。
だから、出荷後や運用開始後に『保守という名目や、改善という名目でバグ修正』

システム開発の世界では、スカイツリー完成に与えられる期間は半年である。
178 名前：仕様書無しさん mailto:sage [2012/01/07(土) 12:29:36.70 ]: >>173
システムエンジニアとプログラマを上下関係の階層構造で考えるのは限界があると思うよ
プログラミングを高いレベルで習得してる人と
業務ロジックを高いレベルで基本設計にまとめられる人は別人でもいい

>>174
顧客と折衝し開発範囲と仕様を定義するシステムエンジニアと
それをソフトウェアとして構築するプログラマは別モンてことだな

設計書を書くだけのシステムエンジニアは
詳細設計書見てコーディングするだけのコーダー同様に
要らなくなるかもしれん
179 名前：仕様書無しさん mailto:sage [2012/01/07(土) 12:53:59.54 ]: 設計にプログラムの作成とかやらせたらダメだよ。
本来やるべき設計に手が回らなくなって、デスマ化する。
180 名前：仕様書無しさん mailto:sage [2012/01/07(土) 13:12:21.58 ]: デスマ化するかはお客との調整がすべてだと思う。
181 名前：仕様書無しさん mailto:sage [2012/01/07(土) 13:13:00.33 ]: 設計者と実装者を別けた時点でデスマ率UP
182 名前：仕様書無しさん mailto:sage [2012/01/07(土) 13:21:09.93 ]: >>181
> 設計者と実装者を別けた時点でデスマ率UP
現実問題、人・金がないのだから分けるしか無い。

その場合、設計者がサンプル実装を行なって
それにそったやり方で実装するように決めれば良い。
もちろんレビューも行う。
183 名前：仕様書無しさん mailto:sage [2012/01/07(土) 13:31:21.51 ]: >>181
納期までに一人で何でもかんでも出来るなら、苦労しないんだよ。
184 名前：仕様書無しさん mailto:sage [2012/01/07(土) 13:36:31.46 ]: >>175
後付してねぇし、言い逃れしてねぇよ。。
言っていることの真意と異なることを返してくるから、細かく答えてるんだろうが。
挑発して勝ったつもりになってんじゃねーぞ。

162で書いた
「会社にとって総合的に利益のほうが上回る事が見込まれるのであれば」
が、何を上回るかって部分をお前は
「カチカチに決めることより利益を上回るなら」
って解釈してイチャモンつけるから
「そうじゃなくて、ビジネスとして利益が上がるのであればという意味だ」
と認識を正してるんだろ。

どこが意味変わっているのか答えてみろよ。
確固たる主張してんだろカス。
185 名前：仕様書無しさん mailto:sage [2012/01/07(土) 13:48:34.72 ]: >>184
ま、利益優先や短納期だと、工程ごっちゃにしちゃうのは、よくある話。
技術者に無理強いする訳だから、ほぼデスマ化するよね。
186 名前：仕様書無しさん mailto:sage [2012/01/07(土) 14:12:45.08 ]: >>177
いまどき、ソフト開発に3年もかけてたら製品発売した時点で時代遅れだってw
187 名前：仕様書無しさん mailto:sage [2012/01/07(土) 14:28:08.70 ]: >>185
それは、利益優先や短納期が悪いっていうより、後出しじゃんけんさせるのが悪いんじゃないの。
188 名前：仕様書無しさん mailto:sage [2012/01/07(土) 14:30:29.06 ]: 新製品のoffice2000向けのツールを作ってたらoffice2003がでました！どうしましょう？
えぇぃ、再設計だ。とわいわいがやがやしてるうちにoffice2007ﾘﾎﾞﾝになってましてどうしましょう？
で、ちんたら勉強してたらoffice2010で標準装備で、実はﾂｰﾙ無用で済みました。てへ。
189 名前：仕様書無しさん mailto:sage [2012/01/07(土) 14:52:30.13 ]: >>181

両方やれるような優秀な人間にプログラムさせるのはもったいない
190 名前：仕様書無しさん mailto:sage [2012/01/07(土) 15:33:58.78 ]: >>187
後出しジャンケンは対応次第で次の開発につながったりするから、一概に悪いとは言い切れない。
対応を誤れば、デスマ化するけどね。
191 名前：仕様書無しさん mailto:sage [2012/01/07(土) 16:41:35.24 ]: >>189
実装しかできない奴に渡してもいいような資料を作る方が時間がかかる。
192 名前：仕様書無しさん mailto:sage [2012/01/07(土) 17:10:21.04 ]: 既に火を噴いてる状況なのに、横から口出してきて
更にいらんことやらせようとする、自称優秀SEがさらに引っ掻き回してくれそうな予感がするこの頃。
193 名前：仕様書無しさん mailto:sage [2012/01/07(土) 17:21:50.18 ]: >>191
仕事を誰かに割り振るようにできないと
一人に負担がかかり過ぎて、うつ病や廃人になるぞ。
194 名前：仕様書無しさん mailto:sage [2012/01/07(土) 17:45:05.81 ]: 設計を誰かに渡してしまえばいい。
195 名前：仕様書無しさん mailto:sage [2012/01/07(土) 17:54:56.32 ]: そうか折衝や設計から外注にやらせればいいんだ
不況で人余ってるから買い叩けるし
失敗したら責任取らせて別の会社にやらせればいい
196 名前：仕様書無しさん mailto:sage [2012/01/07(土) 18:13:07.31 ]: >>195
お前・・・
責任を取ったからって、システムが出来上がるわけじゃないぞ。
失敗した時点で、システムの完成はできていない。
そして儲けが出るほど責任を取らせれられるわけじゃない。
最悪、会社倒産でお前は損して終わりだろ。
197 名前：仕様書無しさん mailto:sage [2012/01/07(土) 18:21:04.60 ]: だから最後は誰かが必死に仕上げるんだ
俺ら孫受けがな
198 名前：仕様書無しさん mailto:sage [2012/01/07(土) 18:21:35.04 ]: で仕上がるのか？
199 名前：仕様書無しさん mailto:sage [2012/01/07(土) 20:10:11.48 ]: >>195
実際はそのとおり。
だけど、それだとお前が間抜けないよな。
って訳で、1枚邪魔がはいるのよ。
200 名前：仕様書無しさん mailto:sage [2012/01/07(土) 23:09:29.11 ]: >>184
どうした？図星すぎてテンパったか？
201 名前：仕様書無しさん mailto:sage [2012/01/07(土) 23:55:59.98 ]: >>200
お前の人格まで否定しないから、反論してみろよ。
202 名前：仕様書無しさん mailto:sage [2012/01/07(土) 23:58:54.79 ]: 図星と指摘することが反論そのものだろｗ
203 名前：仕様書無しさん mailto:sage [2012/01/08(日) 01:44:23.33 ]: ゆとりは会話もできないのな
204 名前：仕様書無しさん mailto:sage [2012/01/08(日) 04:23:40.76 ]: >>201
やっぱりね。おまえは打たれ慣れてないっつーか、社会に揉まれてないっつーか、そんなところだな。
経験浅いから使ってる言葉に重みがねーんだよ。
後出しジャンケンの意味も履き違えてるみたいだし。
聞きかじった言葉だろ？

すぐに感情的な反応するとこ見ると
あながち間違いじゃなかったみたいだ。認めろよ。
205 名前：仕様書無しさん mailto:sage [2012/01/08(日) 04:32:41.63 ]: もう一つ言うとだな、お前の思ってる言葉の裏に隠されてる真意なんて誰も知らないって。
何だよ真意って。最初から真意言えばいいのでは？
利益優先だとか工程ガーとか、そんなんじゃ仕様書いたことあるかどうかも疑わしいわ。
背伸びしなくていいよ。等身大でいいんだって。
206 名前：仕様書無しさん mailto:sage [2012/01/08(日) 05:35:43.65 ]: ※関係ない人ごめんなさい。

>>204 >>205
話の流れをいったん整理する

設計してから要件を定義するという話をしていたから、俺が
「それは設計ではなく、要件を定義するために顧客から要求を引き出す作業であって、
要件が明確化して、機能が確定した段階ではじめて設計が固まる」
という話をしていたわけだ。

そこで、お前が
「合意をとった上で始めて設計が固まる　と思ってるなら、まだ青臭いな。
合意はその時点での合意でしかない。」
って頓珍漢な横槍を入れたよな？(本人？)
合意を取ったことに対して"その時点での"設計が固まって、
後で変更を依頼されたら、仕様変更で再設計だよな？

で、俺が返したのは、
「"俺が"初期段階の決定事項が全てだと思っているわけではなく、
設計と要件定義の区別がついていないやつがいるからそういう答えをした。
会社として利益が見込みがあるのであればそういう仕事もする。」

で、お前が
「カチカチの行程のほうが開発会社の利益になる。
臨機応変に対応したら仕事が減る。」

で、俺が
「カチカチのほうが確実な見込みが取れるから安全だけど、
実際には利益が見込まれるならそういう客にも付き合う。」
207 名前：仕様書無しさん mailto:sage [2012/01/08(日) 05:36:06.12 ]: で、お前が
「話を後付けするな。確固たる主張がないなら折れろよ。
言い逃れ野郎。人格否定されてると勘違いするな。素直に認めろよ。」

で、俺が
「>>162で書いたことの意味を正しく認識できていない。
カチカチにするより利益が上がるという意味ではなく、
利益が上がるなら仕事として受けるという意味。」

で、お前が
「どうした？図星すぎてテンパったか？」

で、俺が
「お前の人格まで否定しないから、反論してみろよ。」

で、お前が
「図星と言ったのが反論。」
「経験不足にみえる。言葉に重みがないからわかる。
言葉づかいも間違えている。図星だろ認めろよ。」
「お前の心の中なんか知るか。最初から真意言え。
利益優先だとか工程ガーとか、そんなんじゃ仕様書いたことあるかどうかも疑わしいわ。
背伸びしなくていいよ。等身大でいいんだって。」

ここから、返信 ← new!
「真意って言ったけど、書いてなかったことではなく書いていたこと。
お前が話しの流れを読めていない上に、どんどん話をずらしていった。
そして、図星が反論になっているという意味がいまだにわからない。
冷静に自分のレスとスレの進行を眺めなおしてこい。」
208 名前：仕様書無しさん mailto:sage [2012/01/08(日) 05:38:28.50 ]: そろそろダルいのと、もうだいぶ他の人に迷惑かけてるから、
次で誤解が埋められなかったら終わりにしよう。
209 名前：仕様書無しさん mailto:sage [2012/01/08(日) 10:48:23.37 ]: こうゆうやつらがいたらデスマになりそう
210 名前：仕様書無しさん mailto:sage [2012/01/08(日) 12:15:41.06 ]: 細かい事はいいんだよ見たいな奴は危険。
また、一見細かく見えてどんどん話がずれて行く奴も危険。
211 名前：仕様書無しさん mailto:sage [2012/01/08(日) 12:50:18.74 ]: 話の発端は、要件定義やらずに設計書を要求してくる客がいるというところから始まってる。
おそらく、お互いが最終的なシステムをどういったものにしたいかイメージできないからだと思う。
このような場合、試作を見て要件を出してもらうプロトタイプモデルとかがあるわけで、
その変形版って捉え方でいいんじゃないかな？
212 名前：仕様書無しさん mailto:sage [2012/01/08(日) 12:53:45.13 ]: >>207
あんたまたやらかしてるよ。。認めればいいのに。
頭凝り固まってる。
213 名前：仕様書無しさん mailto:sage [2012/01/08(日) 13:00:43.93 ]: >>212
相変わらず、何の具体的な指摘も反論も出来ないのな。
という事で終わりな。
214 名前：仕様書無しさん mailto:sage [2012/01/08(日) 13:09:57.07 ]: >>209
PM,PLだったら最悪だな。
特に行き詰まったときに、精神論や人格論ばかり振りかざす奴。
うつ病患者量産するからな。
PEだったら、チームから外してもらうよ。
215 名前：仕様書無しさん mailto:sage [2012/01/08(日) 13:29:04.39 ]: そろそろ仕様書、設計書の話に戻そうぜ。
216 名前：仕様書無しさん mailto:sage [2012/01/08(日) 13:45:19.85 ]: 相手の意見なんて一切お構いなしに、自分の信念に基づいた見えない弱点を作り出して、
そこを突くことで勝ちに浸る、って奴はどこにでもいる

そもそも発端が、憶測から相手を過小評価することで気持ちよくなりたい相手なんだろ
んなの、いち早くレスする価値がない相手だって気づいて、スルー決め込むのが最適解だわ
わざわざ同レベルで争い続けるから、無駄レスが続くんだよ
217 名前：仕様書無しさん mailto:sage [2012/01/08(日) 13:46:21.94 ]: >>216
自分に言え
218 名前：仕様書無しさん mailto:sage [2012/01/08(日) 13:47:49.66 ]: >>204
やべぇ、こういうおっさんうちの職場にいるわｗ
こいつの書く仕様書が半端じゃなく使えないけど、声でかいからみんな困ってる
219 名前：仕様書無しさん mailto:sage [2012/01/08(日) 14:01:32.66 ]: 反論しなければ周りにバカ遺伝子撒き散らすし、やりあえば不毛だし、生きている事自体が害でしかない。
220 名前：仕様書無しさん [2012/01/08(日) 14:08:21.26 ]: 討論はどんどんすべきだし、途中まではいい感じだったけど
人格否定が始まったら終わりにすべきだな
「現場にたまにいるわ」のあたりからディベートとして成立しなくなったな
221 名前：仕様書無しさん mailto:sage [2012/01/08(日) 14:25:44.51 ]: 仮想敵設定を誤るとこうなる
222 名前：仕様書無しさん mailto:sage [2012/01/08(日) 16:03:21.72 ]: はいはいぬるぽ
223 名前：仕様書無しさん mailto:sage [2012/01/08(日) 18:31:36.88 ]: 2chに何か期待した時点で負けだろ。
224 名前：仕様書無しさん mailto:sage [2012/01/08(日) 22:39:22.01 ]: 自分の書き込みに、全部同一人物がレスしてると思うなw
ここはIDもついてない板だぞ
IT開発者は少しくらいはアスペルガー気味なところがあっていいけどもちょっとは気付け

ちなみに >>144 >>168 >>174 >>178 とかは同一人物
>>168 の書き込みが悪かったな。
>>162のカキコの意図を取り違えていたよ。ていうか半分は論点ずらしだったわけだが
それも2ちゃんだ
225 名前：仕様書無しさん mailto:sage [2012/01/08(日) 23:30:03.79 ]: 設計書の形式、ExcelもWordもダメだとすると、何がいいんだ？
226 名前：仕様書無しさん mailto:sage [2012/01/08(日) 23:43:04.95 ]: 最後に頼りになるのはTEXTでしょう。
227 名前：仕様書無しさん mailto:sage [2012/01/08(日) 23:48:33.49 ]: jpg
228 名前：仕様書無しさん mailto:sage [2012/01/08(日) 23:57:47.71 ]: >>224
現場にたまにいるわ。
詭弁使ってドヤ顔してるやつ。
確固たる主張がないなら折れろよ。
229 名前：仕様書無しさん mailto:sage [2012/01/08(日) 23:59:11.28 ]: >>224
ごめんなさい。
「確固たる主張がないなら折れろよ。」
って言って見たかっただけです。
230 名前：仕様書名無しさん mailto:sage [2012/01/09(月) 03:41:58.89 ]: そもそもマイクロソフト様は設計書は何で書いてるんだろうな？
まさか、Word？
231 名前：仕様書無しさん mailto:sage [2012/01/09(月) 03:42:20.26 ]: Excelは保守を考えないなら楽だけどな
232 名前：仕様書無しさん mailto:sage [2012/01/09(月) 04:05:14.81 ]: >>230
HTML
233 名前：仕様書無しさん mailto:sage [2012/01/09(月) 09:11:55.31 ]: >>232
技術資料は全てMSDNとして公開されるわけだからHTMLだな。
234 名前：仕様書無しさん mailto:sage [2012/01/09(月) 11:05:24.05 ]: >>231
保守は、設計書の保守って意味？
235 名前：仕様書名無しさん mailto:sage [2012/01/09(月) 11:27:49.61 ]: >>233
ということはhtmlは何で書いてるの？
メモ帳？Ｗord？
236 名前：仕様書無しさん mailto:sage [2012/01/09(月) 14:56:46.29 ]: ホームページビルダーだよ
237 名前：仕様書無しさん mailto:sage [2012/01/09(月) 14:59:52.64 ]: プロが包丁でじゃがいもの皮を向いていても
一般の人は皮むき器でいいと思うよ。
真似することはない。
238 名前：仕様書無しさん mailto:sage [2012/01/09(月) 15:19:34.57 ]: >>235
独自の管理？ツールがあるんだろ。
ドキュメントコメントと関連付けられたフォームに、
入力するとMSDN生成してくれるやつが。
239 名前：仕様書名無しさん mailto:sage [2012/01/09(月) 16:03:59.55 ]: >>238
ドキュメントコメントって設計書か？
少なくともソースが存在しない時点では書けないよな？
240 名前：仕様書名無しさん mailto:sage [2012/01/09(月) 16:05:43.03 ]: >>236
他社製品www
241 名前：仕様書無しさん mailto:sage [2012/01/09(月) 16:35:25.48 ]: >>239
ドキュメントコメントは仕様書だな。
作る順序は作業の進め方によるけど。
何かツールでモデリングしてコードの雛形作ってる事のほうがおおいか。
242 名前：仕様書無しさん mailto:sage [2012/01/09(月) 23:07:12.36 ]: >>235
HTMLはVisualStudioでだ。
243 名前：仕様書無しさん mailto:sage [2012/01/09(月) 23:18:19.04 ]: HTML形式で文書を作成するってのが想像つかないんだよな。
一般企業だと、文書は文書作成ソフトで作成して
提出時に用紙に出力するって流れで固まってるよね。
HTML形式を用紙に出力すると、体裁崩れちゃうし…。
244 名前：仕様書無しさん mailto:sage [2012/01/10(火) 00:05:27.42 ]: >>243
それは、HTMLとCSSが使いこなせていないからでは…？
245 名前：仕様書無しさん mailto:sage [2012/01/10(火) 00:15:59.17 ]: ﾈｽｹの4がﾃﾞﾌｫだった時代のｵｼﾞｻﾝなんだけれど、今からHTMLとかCSSとか覚えようとしたら
どっから覚えたらいいんだ？ﾃｰﾌﾞﾙとTRとTDで組むとかしたらｼｰﾗｶﾝｽ級の扱い受けるんだろうなぁ
246 名前：仕様書無しさん mailto:sage [2012/01/10(火) 01:01:16.88 ]: CSS3使えばいいよ。
テーブル使う理由の3カラムレイアウトとか
やっとCSS3に含まれることになったから。
www.htmq.com/css3/column-count.shtml

対応しているブラウザはまだないけどなｗ
247 名前：仕様書無しさん [2012/01/10(火) 01:29:42.23 ]: レビューの議事録って誰が書いてる？
レビューされる人(設計を説明する人)？レビューする人(レビューアー)？
248 名前：仕様書無しさん mailto:sage [2012/01/10(火) 01:54:55.38 ]: 特に決めてないけど、される方が書いてるかな。
249 名前：仕様書無しさん mailto:sage [2012/01/10(火) 02:06:52.77 ]: テーブルレイアウトは、方眼紙の延長だわな。
それだけである程度のレイアウトができてしまうから、
それぞれに適した手段を一つ一つ学ぶ手間がかからないので、馬鹿でもなんとかなる。

HTMLは文章や単語に文字で表せない意味付けをするためのもので、
スタイルシートはその文書などの部品をどう配置するか、どういう見た目にするか、
みたいなただのの設定だから、誰でもすぐ覚えれるし、別に難しいことはないはずなんだけどな。
250 名前：仕様書無しさん mailto:sage [2012/01/10(火) 02:10:21.59 ]: >>247
れびゅーいが書いてれびゅーあが確認するって事が多いんじゃないかな
指摘事項とかを書き出して、対応内容まで書いて、対応してるかどうかを確認する、って流れになるだろうし

どうでもいいけど、このレビューイって呼び方がなんかこう好きになれない
ｷｬﾊﾊﾚﾋﾞｭｰｲ
251 名前：仕様書無しさん mailto:sage [2012/01/10(火) 02:28:18.68 ]: >>249
CSSには長らく段組という機能が無かった。
また角丸を実現する方法もなかった。

結局は、段組用、角丸用に調整したHTMLを書かないといけず
それを実現するためのテクニック（バッドノウハウ）が必要なので
難しいものとなってる。

CSSは要求するデザインを満たせるものではなかったんだよ。
十数年たってこれからやっとましになるかなってのが現在の状況
252 名前：仕様書無しさん mailto:sage [2012/01/10(火) 15:11:04.08 ]: >>245
なぜそのような発想になるのでしょうか
253 名前：仕様書無しさん mailto:sage [2012/01/10(火) 20:28:00.12 ]: ﾈｽｹの4がﾃﾞﾌｫだった時代のｵｼﾞｻﾝ　が、Web全盛期の世の中でHTMLを無視してきたってやばいよ。
たとえ、まったく異なる分野の技術者だったとしてもです。
そんなことだから「どっから覚えたら」などという発想になるんです。
254 名前：仕様書無しさん mailto:sage [2012/01/10(火) 20:32:50.83 ]: ﾈｽｹの4がﾃﾞﾌｫだった時代のｵｼﾞｻﾝなんだけれど　

の裏に長年苦労してきて、あんたらの知らないことイッパーイ知ってる俺様
って含みがあるから腹立つ。

↓どうしてこれで止められなかったんだ？HTMLを知らない、それだけでいいじゃん。

HTMLとかCSSとか覚えようとしたらどっから覚えたらいいんだ？
ﾃｰﾌﾞﾙとTRとTDで組むとかでいいの？
255 名前：仕様書無しさん mailto:sage [2012/01/10(火) 21:20:09.14 ]: >>254
お前、病気じゃないか…？

>>245
今時、Webのフリーツール沢山あるんだし、UIライブラリも沢山あるし、適当に中身覗いてみればいいんで無い？
256 名前：仕様書名無しさん mailto:sage [2012/01/10(火) 21:53:22.32 ]: 納品用にhtml印刷した時に目次とページとかフッターとか入れられますか？
257 名前：仕様書無しさん mailto:sage [2012/01/11(水) 00:32:30.20 ]: >>256
CSSでメディアタイプってのがあってそれを使うと画面表示と印刷するときで
ちょっと違う出力に出来る。
258 名前：仕様書無しさん mailto:sage [2012/01/11(水) 09:29:40.98 ]: Officeソフトには、オートシェイプ機能があるけど
HTML形式で、オートシェイプと同じように自由に挿入したり、コメント入れたりできるの？
259 名前：仕様書無しさん mailto:sage [2012/01/11(水) 10:12:05.94 ]: >>258
SVGでやればいいのでは？
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
設計者やお客さんに聞いて仕様を確認するのが本来だけど
詳細設計書を元にプログラム作るコーディング請負の仕事なら
わけわからんまま設計書に書いてあるとおり作るしかないんじゃないか
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 ]: アットホーム()とか、まぁ良くも悪くも日本っぽい事ではあるし、それで成功してるとこもいっぱいある
別に和気藹々やるのがダメだとは思わん

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

無理やりスレタイの話題に振るなら、そういう人が書いた仕様書は、割とひどいｗ
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 ]: 新人だと思ったら４０才くらいのおっさん個人事業者が作った設計書らしい
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 ]: 管理してないんじゃねｗ
担当が居なくなってから火を噴く、みたいな
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 ]: 日本の家電メーカーとか最初から終わってんじゃん
入りたくねーｗ
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)等への変換が可能
442 名前：仕様書無しさん mailto:sage [2012/02/29(水) 01:13:30.98 ]: Excelで作られた文書って、目先しか考えてないからなぁ
文章を書く、ってのが前提にあるなら、Excel使ってる時点で全部糞以下だわ

更改されない使い捨てなら別に何でもいいけど、仕様書とかをアレでやられてると、げんなりする
Excel方眼紙仕様書は高確率で、
章番号段落番号とか、修正自色変えとか、一部分だけ取り消し線とか
挙句の果てには印刷レイアウト見ながら列幅の調整、文章の分割を行わないといけない、とか
糞ルールのおまけがいっぱいついてくるしなｗ

操作性悪いI/Fや、ちょっとした誤操作で設定してるスタイルぶっとばしてしまうような
うんｋWordはダメダメのダメダメダメダメだけど、それでもちゃんと使えばExcelよりかは手抜きできるから使いようだと思う

問題の根本原因は、Wordですら理解できないのが多すぎることだと思う
そういう奴らも仕事に関わる以上、結局サルでもわかるExcel方眼紙！みたいなのに助けてもらうしかない
443 名前：仕様書無しさん mailto:sage [2012/02/29(水) 01:31:29.80 ]: 普通の人はデータそのものと視覚的デザインの分離が正義だとは微塵も思ってない。
いかに正確に、効果的に読ませるかに関してのアプローチにおいて
文章データと視覚デザイン、場合によってはアニメ、効果音すらも一体化しており切り離せない。
だから理系脳の連中がデザインの分離を叫ぶたびにこいつら頭沸いてんじゃねーのかと思ってる。
444 名前：仕様書無しさん mailto:sage [2012/02/29(水) 01:34:21.70 ]: >>436
別に何でも出来るわけじゃないし、「万能」とはちょい違うと思うなー
Excelは、理解しなくても方眼紙としては使えるので、馬鹿でもわかるって感じだと思う

列幅行高さ変更を禁止される事多い方眼紙を使ってしまうと、改行するだけでカットペースト必要だったり、
笑えないギャグがてんこ盛り状態にはなるけど、それでも方眼紙として使う上での殆どのことは特に理解しなくてもわかるレベルだし
ほんとExcelすごいな…！！１

あと、Excel仕様書の反対理由で、表計算だからって理由を前面押ししてる人はそんな居ないんじゃね
「そもそもあれは表計算ソフトで、文章を書くためのものじゃない」っていうような言われ方ならちょいちょい見るけど
それって「表計算ソフトだからー」、じゃなくて「文章作成機能付いてがないからー」って意味っしょ
もし、前者のように捕らえちゃってたのなら、多分Wordの機能と、Excelの機能の差をちゃんと理解しきれてないんだと思うぽ

修正の履歴つけたり、番号振ってくれたり、用語を参照してくれたり、目次つけたり、段落やレイアウトやってくれたり、
印刷を面倒みてくれたり、みたいな文章の作成向きの機能がExcelには殆どついてないから、
どっちも一通り触ったことある人は、流石に文書作るのにExcelはねーな、ってなるんだと思う
445 名前：仕様書無しさん mailto:sage [2012/02/29(水) 01:45:40.62 ]: 文書を電子データのまま活用するか、プリントアウトして活用するかの文化の違いに見える。
446 名前：仕様書無しさん mailto:sage [2012/02/29(水) 01:47:08.58 ]: ついてる機能を知らなくても、方眼紙エクセルなら力技で何とかできるからなぁ…。
ワードだとその機能を知らないと出来ない事が多数あるから、学ばない連中は拒絶反応を示すんだと思うよ。
検索や置換機能のあるエディタが手元にあっても、その機能知らないから、全部手作業で単語の書き換えをやる奴いるのと同じ話。
別に個々の仕事で簡潔する事なら、どうぞ好きに力技披露してくって感じだけど、
俺までそれに合わせないといけないってなるのは、すごく面倒。
447 名前：仕様書無しさん mailto:sage [2012/02/29(水) 01:56:21.53 ]: UMLって全部、多次元配列で表現できるような気がするんだ。
いや、具体的に検討したわけじゃないんだけど。
wiki文法に組み込めないかな。
448 名前：仕様書無しさん mailto:sage [2012/02/29(水) 01:58:01.72 ]: >>443
ここマ板だしなｗ
仕様の修正で、中身となんも関係ない見た目まで毎度再調整とか、無駄じゃね
ブレブレの仕様とかだと、仕様ちょっと変わるたびに見た目まで再調整とかになったりするんだぜ
基地外じみた章番号の修正とか、気が狂う奴が出兼ねない…！
そういうのがめんどくせぇ、ってのに理系だの文系だのは関係ないと思うｗ

>>445
印刷する気ないのに、印刷レイアウトではみ出しがないかチェックしろ、みたいなアホなルールも結構みるけどなｗ
レビューでんなとこチェックしてる時間あったら、内容の不備がないかをチェックしろよって思うこと多々
449 名前：仕様書無しさん mailto:sage [2012/02/29(水) 07:30:37.21 ]: 基本的に方眼Excelのくせに、一部分だけ表を書きたいためなのか
横長なセルがあったりすると非常に萎える。
450 名前：仕様書無しさん mailto:sage [2012/02/29(水) 07:39:14.85 ]: プログラマだけど文系だからな俺
Texとかまじわからん

Excelが文章作成ソフトじゃないのはわかるんだが、Wordは不親切な親切が多すぎて使っててイライラする
はっきり言ってどっちも使いたくないけど二択ならExcelの方が扱いやすい
451 名前：仕様書無しさん mailto:sage [2012/02/29(水) 07:44:22.12 ]: > Texとかまじわからん
HTMLわからんって言ってるようなものなので、ちょっと恥ずかしい。
452 名前：仕様書無しさん mailto:sage [2012/02/29(水) 12:33:47.48 ]: 方眼紙にするだけならまだ許そう。お前ならまだ切り貼りもだいたいできるし、他からのペーストもわりと受け入れてくれる包容力がある。
だがセル結合、テメーはダメだ！

>>450
イライラすんのは理解力がない自分のせいだと思うぞ。
俺も前は、Wordは勝手に○○されるから糞って思ってたけど、結局それはなんでそうなるかを知らないからなわけだし。

項目名が意味フだったり、ヘルプも微妙だったりで、覚えるまで面倒なのはすごく同意できるが、
イライラしてても埒が明かんって調べたら、数十分ありゃ解決するような話だったこと多々。
Texも別に調べりゃすぐわかるレベルだし、わかるわからない以前に単にやる気がないだけだと思うわ。
453 名前：仕様書無しさん mailto:sage [2012/02/29(水) 18:07:40.78 ]: Wordで章だてから真面目に書けば、そう悲惨なことにはならない。
書式は統一されたものを適応するのみ。
なんでも適当にやるからだろ……
454 名前：仕様書無しさん mailto:sage [2012/02/29(水) 18:16:16.13 ]: >>450
Wordで文章書くとき、
一つの文なのに改行で行替えしたり、
タブや全角スペースで文字下げしたりインデントしたり、
文の一部を選択してフォントやサイズを変えたり、
目次を手でかいたり
してない？

そりゃ大変だよ。
455 名前：仕様書無しさん mailto:sage [2012/02/29(水) 19:58:09.40 ]: >>450
TeXなんかなんかプログラム言語の文法と比べると簡単なもんだぞ。
文系と言うのなら不親切な親切って言う表現はおかしいだろう。
Wordは大きなお世話が多いのは確か。
456 名前：仕様書無しさん mailto:sage [2012/02/29(水) 21:09:57.02 ]: Excel否定する長文をよく読むと

否定する理由の根拠が激しく乏しい件について。
457 名前：仕様書無しさん mailto:sage [2012/02/29(水) 21:11:03.88 ]: >>453
> Wordで章だてから真面目に書けば

章立てする理由は？
本書いてるわけじゃないんだから
そんなの必要ないよ。
458 名前：仕様書無しさん mailto:sage [2012/02/29(水) 23:02:20.84 ]: Ctrl+クリック(だっけ？)で即ジャンプできるじゃん
459 名前：仕様書無しさん mailto:sage [2012/02/29(水) 23:22:27.66 ]: >>457
ぐちゃっと書かれてる仕様書はわけわからん。
いや、書いてる奴自身はわかってるのかもしれないけど。
コードと同じように、スパゲティ仕様書もダメダメだ。
460 名前：仕様書無しさん mailto:sage [2012/02/29(水) 23:33:53.31 ]: 章＝ディレクトリでいいやん
461 名前：仕様書無しさん mailto:sage [2012/02/29(水) 23:39:02.75 ]: Wordはもうちょっとアウトラインが使いやすければなあ。
462 名前：仕様書無しさん mailto:sage [2012/03/01(木) 01:02:50.34 ]: ファイルがひとつにまとめられてると
同時編集が面倒なんだよねぇ。
ほら、仕様書作成なんて一人でやらないでしょ普通。
463 名前：仕様書無しさん mailto:sage [2012/03/01(木) 01:17:53.14 ]: モジュールに分けて仕様書つくればいいんじゃないのか
464 名前：仕様書無しさん mailto:sage [2012/03/01(木) 01:27:04.63 ]: SEになって数年たつけど、Excelで仕様書作ってるよ。
請負中心だから客先ですでに決まってるフォーマットを使ってる。
Excel設計書に不満があるけど、
だからと言ってWordの利点も見出せないから現状維持。
465 名前：仕様書無しさん mailto:sage [2012/03/01(木) 01:33:49.86 ]: 使う人が使いやすいならエクセルでもいい。
自分しか使わないなら好きなので書けばいい。

ただ、Wordを批判するやつの九割以上がWordを使いこなせないことを責任転嫁しているのは納得いかない。
466 名前：仕様書無しさん mailto:sage [2012/03/01(木) 01:44:53.48 ]: Word好きじゃないが、Wordでもファイル分けくらいできるぞ。
複数ファイル参照とかは普通に使うでしょ。
467 名前：仕様書無しさん mailto:sage [2012/03/01(木) 01:46:44.31 ]: >>465
あるあるすぎるｗ
自分も昔そうだったからすごくわかるわ

不勉強だった自分を見てるみたいで、もにょる…
468 名前：仕様書無しさん mailto:sage [2012/03/01(木) 01:47:13.73 ]: >>465
使いこなせない人には糞にしか見えないってだけだべ
責任転嫁とは違う
469 名前：仕様書無しさん mailto:sage [2012/03/01(木) 01:51:09.63 ]: >>467
素直に言い給え、Wordも使いこなせないクズと
470 名前：仕様書無しさん mailto:sage [2012/03/01(木) 02:09:21.40 ]: 仕様書はExcelで良いと思うが操作説明書をExcelで作るのは止めて欲しい。
しかも章ごとにブックは分かれているし目次もページ番号も手で振っている。
471 名前：仕様書無しさん mailto:sage [2012/03/01(木) 11:53:26.64 ]: >>457
仕様書っていう本書いてるんだよ。何言ってんの？
472 名前：仕様書無しさん mailto:sage [2012/03/01(木) 14:04:06.28 ]: 本や説明書って、フォーマットは何を使ってるんだろうな。
473 名前：仕様書無しさん mailto:sage [2012/03/01(木) 14:17:52.13 ]: >>472
だいたいインデザとか。
所によっては、ページの少ないものはイラレでざくっと作る。
474 名前：仕様書無しさん mailto:sage [2012/03/01(木) 16:07:19.00 ]: >>472
Adobeの製品ラインナップなら、FrameMaker一択
中小出版社の製本業務や企業の製品マニュアル作成における、
統一されたスタイルによる高品質出版に威力を発揮する
InDesignはSOHOやフリーランス向けの製品(イラレは論外)

あとASCIIの技術系書籍では、TexをエンジンにしたEWBと呼ばれる
独自の出版システムが使われているらしい(詳細はPDF版のマニュアルを参照)
・EWB(Editor's Work Bench)の概要
　ttp://ascii.asciimw.jp/ascii/EWB/gaiyo/index.html

また海外大手のO'Reilly & Associatesの入稿では、DocBookと呼ばれる
XML文書形式が推奨されている(DocBookについては、まずWikipediaを参照)
実際にDocBook仕様書のソース(原稿)はDocBook自身で書かれ、ソースと
オンライン版は無償公開、印刷版は有償でO'Reilly Mediaから発売されている
475 名前：仕様書無しさん mailto:sage [2012/03/01(木) 16:41:29.09 ]: >>474
そーなのか。まぁ義弟の勤めてる会社は弱小だからかな。
見開き数Pの特集、小冊子くらいなんかは、チラシの延長でやっちゃうと言ってたけど。
476 名前：仕様書無しさん mailto:sage [2012/03/01(木) 21:24:00.18 ]: trac + wiki で書いてる
477 名前：仕様書無しさん mailto:sage [2012/03/02(金) 18:13:53.79 ]: 断定できないけど、
本や説明書のフォーマットはWordやExcelを使ってないってこと？
478 名前：仕様書無しさん mailto:sage [2012/03/02(金) 18:29:06.12 ]: >>477
ちゃんとしたところだと、それ用のソフトは普通DTPと呼ばれる物を使う。
Wordを使ってる場合もあるだろうが。
479 名前：仕様書無しさん mailto:sage [2012/03/03(土) 15:22:19.03 ]: 説明書ならWordで作るのも普通にあるよ
480 名前：仕様書無しさん mailto:sage [2012/03/03(土) 17:24:16.16 ]: 仕様書の表から構造体やクラスＤＢのテーブルまで作ってくれるようなソフトが求められている
481 名前：仕様書無しさん mailto:sage [2012/03/03(土) 17:28:24.39 ]: ソースコードの構造体やクラスＤＢのテーブルから仕様書作ってくれるソフトのほうがいい。
482 名前：仕様書無しさん mailto:sage [2012/03/03(土) 19:10:26.35 ]: 次点として、そういうことができる専任の人間を雇ってくれ。
483 名前：仕様書無しさん mailto:sage [2012/03/03(土) 20:06:16.35 ]: texがもう少し使い易かったら広まったろうに。
484 名前：仕様書無しさん mailto:sage [2012/03/03(土) 20:27:41.81 ]: >>483
texが使いやすくても無理だろうと思う。理由は四つあって、
一つ目は仕事はあくまでも体育会系のパフォーマンスであって、マクロ組んで楽したりすると上司に怒られるという風土。
○○したら作業効率ＵＰするよ、と提案すると「俺の仕事を取るな」と怒られる場合もこれ。
二つ目は一般の人はデザイナーとかイラストレーターみたいな人種に異様な憧れと畏怖を抱いていて
テンプレに必要事項を記入しただけみたいな書類を提出しても、仕事したと見てもらえない風土。
最後、HTMLの歴史を見ても本来データ構造を記述する言語だったのに使う側は見た目とべったり癒着する記述しか知らない。
情報とその表現を分離するというITリテラシの欠如がある。
485 名前：仕様書無しさん mailto:sage [2012/03/03(土) 20:50:54.77 ]: 四つ？
486 名前：仕様書無しさん mailto:sage [2012/03/04(日) 00:20:29.87 ]: >>484
>一つ目は仕事はあくまでも体育会系のパフォーマンスであって、(....以下略)

確かに、そういった風土はある
対応策としては、Tex活用を個人レベルで(こっそりと)実践して、最終的に業務上で
具体的成果を示す事ができれば、そんな上司も納得せざるをえないのではないかと思う
よくある失敗は、マクロを組む楽しさや細部の装飾ばかりに夢中になってしまうこと
一言で言えば、業務改善という「目的」とTex活用という「手段」の取り違え

>○○したら作業効率ＵＰするよ、と提案すると「俺の仕事を取るな」と怒られる場合もこれ。

これも、人にやらせるのではなく、提案者自身がリスクを背負ってでも実践する姿勢が大切
どこまで自分を信じて有言実行できるか、という話に帰着する

>二つ目は一般の人はデザイナーとかイラストレーターみたいな人種に(....以下略)

これはよく分からないなあ....
提出する書類というのは、最終的なPDF文書または印刷物だと思うから、何が問題なんだろ？

>最後、HTMLの歴史を見ても本来データ構造を記述する言語だったのに(....以下略)

その問題点を改善して文書の論理構造と物理構造を明確に分離した新しい技術が、
>>474で紹介したDocBook(論理: XML, 物理: XSLT)になる
487 名前：仕様書無しさん mailto:sage [2012/03/04(日) 00:27:09.44 ]: まず論理構造と物理構造を明確に分離する理由がないよね。
488 名前：486 mailto:sage [2012/03/04(日) 00:56:36.22 ]: >>486の最初の事柄の補足として、>>441のLatex活用事例を取り上げる

・Latex文書自動生成ツールは、「上司の目を盗んで」業務の合間に、あるいは
　自宅で少しずつ開発/改良を進め、最終的なPDF文書だけを上司に見せた
・独自のTexマクロ定義は一切使わず、標準マクロと流通パッケージ(longtable等)だけで作った
・業務上の成果として、
　・Latexから変換したPDF文書を納品物として顧客(大手SIer)に認めてさせた(認めてもらえた)
　・当初は単なる構築案件だったのが、保守サポートという追加受注を得る事ができた
　・当初はSIerから他社ベンダを介した孫請けだったのを、SIerからの直請けに変えることができた
　を上げたことで、以降はLatex活用が「黙認」されるようになった
489 名前：仕様書無しさん mailto:sage [2012/03/04(日) 01:29:25.09 ]: >>484
デザイナーやらイラストレーターから、本文の体裁とか段落付けとか取り上げると滅茶苦茶喜ぶぞ。
テンプレートエンジン作ったことあるが、狂喜乱舞して、むしろあっちから、ちゃんと表題は表題と表現してくれとMLで流れたり、
タグ定義を増やしてくれと直談判しにきたり、
甘い文書は開発者権限でおまえで止めろ、俺達の事わかってくれてるじゃねーか、と無茶言ってきたり、
色々いい経験をした。
俺が論文のtexのコンパイル環境を毎回解説して構築させんのが面倒だっただけなのにな。
490 名前：仕様書無しさん mailto:sage [2012/03/04(日) 01:33:25.24 ]: 作り話乙ｗ
491 名前：仕様書無しさん mailto:sage [2012/03/04(日) 14:58:35.98 ]: 向いてないのにこういう仕事選ぶ奴が多いのがなー
体育会系脳っぽいのが多くて、土方に拍車がかかる
492 名前：仕様書無しさん mailto:sage [2012/03/04(日) 15:03:23.43 ]: そういうデザイン部分と文章部分を分けるための道具や仕組みの使い方を
理解できない頭が悪い奴を除けば、そのあたりを分離するデメリットって別に無いからなー

まぁ、そういう頭が悪い奴がいっぱい居る環境にはつかえないっていうのが、ある意味デメリットか
493 名前：仕様書無しさん mailto:sage [2012/03/04(日) 15:25:32.67 ]: 流し込み機能とか使っていれば
内部で自然と文章とデザインが分かれてるからね。

ファイル自体を分けたりして
見るときは合成する。
書くときは分離する。
なんてことやらなくていいからね

WYSIWYGエディタを使えば。
494 名前：仕様書無しさん mailto:sage [2012/03/04(日) 15:46:29.40 ]: >>491
就職氷河期の時なんかはこの業界以外は人をあんまり募集してなかったからな。
特に専門知識なし未経験者歓迎みたいなのは他に無いし。　今でもそういう業界は
介護位しか無いんじゃない？　何もない人は介護かITかの究極の選択という。
495 名前：仕様書無しさん mailto:sage [2012/03/06(火) 21:45:54.91 ]: あーマ等向けの校正ツールが欲しい。
仕様書の何がめんどくせぇってホント誤字脱字がメンドイ。
496 名前：仕様書無しさん mailto:sage [2012/03/06(火) 23:03:10.69 ]: >>495
そんなの気がついたら直すぐらいでいいよ
致命的なのは別として意味さえ通じれば流す方向で

ところで「あーマ等向け」ってなんだ？
497 名前：仕様書無しさん mailto:sage [2012/03/06(火) 23:12:02.64 ]: 糞リーダーになると設計上のバグよりも
誤字脱字やレイアウトを気にする馬鹿が意外と多い。
498 名前：仕様書無しさん mailto:sage [2012/03/06(火) 23:35:47.97 ]: 誤字脱字指摘してドヤ顔になってるのに、設計やユーザの使用感などの重要なこと指摘してもさっぱり伝わらない。
終いにゃ、やらなくていいって言って、切羽詰まってから自分でひらめいたかのように変更を決めて、丸投げ。

死んでくれ。
499 名前：仕様書無しさん mailto:sage [2012/03/06(火) 23:44:18.18 ]: だが誤字脱字だらけの仕様書も困るだろ
内容が本当に正しいかすら信用できなくなる
値が一つ違うだけでもかなりマズイ
500 名前：仕様書無しさん mailto:sage [2012/03/07(水) 00:12:46.05 ]: 誤字脱字だったら、印刷した設計書に赤ペン引いておけばいい。
わざわざレビューの時にドヤ顔で指摘することじゃないよ。
501 名前：仕様書無しさん mailto:sage [2012/03/07(水) 00:47:06.58 ]: いや、指摘するかどうかじゃなくて単に誤字脱字がマズイって話でな
502 名前：仕様書無しさん mailto:sage [2012/03/07(水) 01:07:26.69 ]: 誤字脱字はできるだけしない、レビューでみつけてなくす、ってのはそりゃまぁあたりまえだけど
それだけで満足するバカが多いこと、って話じゃないの
実際内容をきちんと理解できてるレビュアー少ないし
余計なことばっか指摘して、大事な中身まったく見てない糞な奴も結構見かける
能力ないのに長くいて微妙な肩書きだけがついちゃった系のオッサンとか、結構ひどい

>>496
「嗚呼、マ等(ら)向け」、じゃないかな。　==　「あー(感嘆詞)、ぷろぐらまーたちのための～」

糞仕様書の行間を読み解くよりは簡単な問題…！
503 名前：仕様書無しさん mailto:sage [2012/03/07(水) 01:19:54.52 ]: 誤字脱字、正しくない日本語、誤解を招く日本語、全部良くはない事は皆わかってるんだよ。
ただ、物書きのレベルをプログラマに求めるのは酷だろ。
それができるならプログラマ辞めて物書きになってるって。

必要な能力なんだけどね…
時間は限られてるから、なかなかそのレベルをクリアできる人は少ない…
504 名前：仕様書無しさん mailto:sage [2012/03/07(水) 01:24:57.69 ]: でもあれだぞ。物かけない奴は概してプログラム下手だぞ。
とっちらかった文章だな、と思ったら、案の定プログラムもとっちらかってたりする。
箇条書きをうまく文章にやっつけました。って人の方がプログラムは良いことが多い。
505 名前：仕様書無しさん mailto:sage [2012/03/07(水) 01:27:57.41 ]: 日本人って学校で文章の書き方に関するエッセンスを習わないし教えないからな。
みんな自己流っていう笑えない状況。
506 名前：仕様書無しさん mailto:sage [2012/03/07(水) 01:35:52.28 ]: とりあえずよ、校正じゃなくても、インテリセンス(オムニ補完)的なツール欲しいなぁ
章名を一部打ったら章の候補が出てきて、「.」押したら商に所属する値や名詞が並んで、
んで、エンター押したら指定の値がフィールドとして埋め込まれるとか。
とにかく下らないミス減らすツールが欲しいわ。どうでもいいことに時間掛けたくない。
507 名前：仕様書無しさん mailto:sage [2012/03/07(水) 01:36:25.43 ]: 形だけは教えられるんだよね。原稿用紙の使い方、とか。
フォーマット地獄は既に小学校から用意されてんのよ。
508 名前：仕様書無しさん mailto:sage [2012/03/07(水) 02:19:10.60 ]: まぁ、プロの物書きですら難しいからな。
プログラムと一緒で、絶対的な正解ってのが無いのが辛いよな。

コーディング並みにガチガチするって手もあるけど、それこそ形だけのルールで本末転倒になりそうだし。

コードのレビューならコードをレビュー。
文章のレビューなら文章をレビュー。
正しい指摘を毎回できるようにして、プログラマを成長させる環境を作る事が、健全な業界の発展につながって望ましいと思うんだけどなぁー。
509 名前：仕様書無しさん mailto:sage [2012/03/07(水) 02:36:09.33 ]: 正解は本当変わる。読み手次第だよ。
俺は何度となく言葉足らずだと怒られてきた。
「ちょっと考えたら分かることでしょ、pp2-3と、p10で既に説明してるから省いただけです」といった感じで。でも怒られた。
怒られたことを教訓に、いちいち懇切丁寧に書くようになって、怒られる事は減った位の頃、転職した。
「君、これは、馬鹿にしてるのかな？もうpp2-3とp10で説明してることをくどくど書く必要は無いんじゃないの？」と転職先では怒られた。
どっちが正しいか判断はつかんな…
510 名前：仕様書無しさん mailto:sage [2012/03/07(水) 06:03:20.85 ]: 文章って好みがあるからね
だから軋轢生みやすい

ただ、指摘はいいけど怒ったり嫌味言ってくる奴はダメだと思う
表現の違いや誤字脱字なんかはどうしたところで発生するんだから

ドヤ顔してこれでもかと優越感に浸る奴は小物だしたかがしれてる
そういう上司とかリーダーは多いけどなｗ
511 名前：仕様書無しさん mailto:sage [2012/03/07(水) 06:33:24.66 ]: レビューの場でいろいろと指摘が発生するのは当然のことだと思っているのだが
それを嫌がる管理者がいるのが嫌だな
512 名前：仕様書無しさん mailto:sage [2012/03/07(水) 09:36:41.36 ]: >>509
このパターンは非常に多い。
好みによっても違うが、同じ人でもコンディションによって言う事が変わるのは腹が立つ。
513 名前：仕様書無しさん mailto:sage [2012/03/07(水) 13:00:10.93 ]: デファクトスタンダードが無い以上、各組織においては過去の書類を参考にしながら書けということだな。
514 名前：仕様書無しさん mailto:sage [2012/03/08(木) 00:48:08.41 ]: ごくごく自然にに考えよう。

設計とか分析とか工程というのは、
その次の工程を行うためにやる。

つまり、その次の工程の内容を理解していなければ、
使えないものが出来るのは当たり前の話。

たとえば使えない設計書。これができてしまうその原因は
その次の工程を全く知らないからだ。

自分の担当工程だけやって、下流の内容は知らないじゃだめなんだよ。
プログラミングができないSEはクズと言うのは正しいということが分かる。
515 名前：仕様書無しさん mailto:sage [2012/03/08(木) 01:31:36.31 ]: >>509
あるあるｗｗｗｗｗｗｗ
内容読みきれず、そのときの気分だけで思いつきの指摘する奴多すぎ

レベルの低いレビュアーに当たったときは何を書いてもなんかしら指摘される
とりあえず「わかりました！」って言っておくのが解決策だと思うようになったわ…
516 名前：仕様書無しさん mailto:sage [2012/03/08(木) 02:50:41.70 ]: >>28
勝手に大工やっていろ。
517 名前：仕様書無しさん mailto:sage [2012/03/08(木) 03:52:41.46 ]: >>514
分析や設計はユーザーの要件を満たすモノを作るためにやる。
それを実現するための技術的な知識は必要だけど、
次の工程はあまり深く気にする必要はない。
518 名前：仕様書無しさん mailto:sage [2012/03/08(木) 19:39:40.79 ]: >>515 わかりました、というと「課題」扱いになって再レビュー扱いになるから嫌だ。
519 名前：仕様書無しさん mailto:sage [2012/03/08(木) 23:27:34.08 ]: >>517
通訳と一緒だよ。
間に入る人は、両方のことを
知っていなければならない。
520 名前：仕様書無しさん mailto:sage [2012/03/08(木) 23:29:57.69 ]: >>517
> 分析や設計はユーザーの要件を満たすモノを作るためにやる。
当たり前の話。それは反論になっていない。

なぜなら、ユーザーの要件を満たすものを
作るためにどうするか？

その答えが、下流に適切な資料を渡すということだからだ。
ユーザーの方だけ見ていてもいいものは作れない。
521 名前：仕様書無しさん mailto:sage [2012/03/09(金) 00:01:44.11 ]: 下流に適切な資料って何だ？
522 名前：仕様書無しさん mailto:sage [2012/03/09(金) 00:03:28.89 ]: 少なくとも通信フォーマットがかっちり決まってる資料
523 名前：仕様書無しさん mailto:sage [2012/03/09(金) 00:05:10.80 ]: >521
馬鹿な設計になってないこと。
524 名前：仕様書無しさん mailto:sage [2012/03/09(金) 00:09:21.51 ]: エンドユーザーは素人だから
めちゃくちゃな要求をしてくるのは仕方ないけど

それ以外は、めちゃくちゃな要求しちゃだめだよね。
プロなんだから。
525 名前：524 mailto:sage [2012/03/09(金) 00:12:36.91 ]: 今言った、「めちゃくちゃな要求」ってのは実現が難しいって意味じゃなくて
ナンセンスな要求ってことね。どう考えても使いづらくなるのがわかりきってる仕様とか
書いてる内容に矛盾があるとか、そのとおりに作ったら破綻するのが目に見えてるシステムとか。
526 名前：仕様書無しさん mailto:sage [2012/03/09(金) 00:14:07.33 ]: >>523
Ａボタン：ジャンプ
Ａボタン長押し：しゃがむ

プレイヤ「うん？」
527 名前：仕様書無しさん mailto:sage [2012/03/09(金) 00:21:14.50 ]: >>523
Ａボタン：ジャンプ
Ａボタンまわす：回転

プログラマ「まわす？」
528 名前：仕様書無しさん mailto:sage [2012/03/09(金) 00:28:51.04 ]: 初版
→→（すばやく２回）：ダッシュ
←←（すばやく２回）：ブレーキ

プレイヤ「左にダッシュしたいです」

改訂版
→→（すばやく２回）：ダッシュ
←（長押し）：ブレーキ

プレイヤ「左に行きたいです」
529 名前：仕様書無しさん mailto:sage [2012/03/09(金) 00:37:24.74 ]: >>522
>少なくとも通信フォーマットがかっちり決まってる資料

通信フォーマットとは、ネットワーク上を流れるメッセージの形式的仕様のことでいいのかな？
たとえばテキストであればXML SchemaとかバイナリならIDLやASN.1で書かれた仕様

で、そういった通信フォーマットは実装に着手する以前に仕様書としてかっちり決めるのが当たり前
もしそれが実践できていないとしたら、>>714の

>自分の担当工程だけやって、下流の内容は知らないじゃだめなんだよ。
>プログラミングができないSEはクズと言うのは正しいということが分かる。

うんぬんは些細な話で、それ以前のプロジェクト全体の品質管理に致命的な問題があると思う
530 名前：仕様書無しさん mailto:sage [2012/03/09(金) 00:41:40.20 ]: その、通信フォーマットというのを
通信システム知らない素人が作れるかといったら作れないだろうね。

シリアル通信の通信フォーマットはこんな感じでお願いと
言われた資料に、接続先のポート番号は8080で～とか書いてあったら
お前馬鹿かって思うよ。
531 名前：仕様書無しさん mailto:sage [2012/03/09(金) 00:55:55.25 ]: >>526
あー…
あるな。
しかも仕様切った奴は「一つのボタンで合理的だろ」とか言ってる感じ。
ワープロって本当に使いやすかったよね。
倍角にしたけりゃ倍角ボタン、平仮名にしたけりゃ無変換ボタン、
単漢字もボタン。罫線ひきたきゃ罫線ボタン
532 名前：仕様書無しさん mailto:sage [2012/03/09(金) 01:09:34.81 ]: >>528
もう設計書レビュー通して印鑑まで押したから変更はできないよ。
533 名前：仕様書無しさん mailto:sage [2012/03/09(金) 01:17:08.27 ]: >>532
納品直前にユーザーの怒りを買って、デスマが始まるんだね。
534 名前：仕様書無しさん mailto:sage [2012/03/09(金) 01:31:59.99 ]: >>532
レビュー通っちゃうとねー。
明らかにヤバそうなのは「試食してもらいませんか？モックアップと評価版で」とか言うと共に、
いけいけな人捕まえて「ちょっとここ突っ込んでもらうように伝えて下さい」と、両方の顔を潰さぬように大打撃を回避してる。
なんで下っ端がこんな事してるのかわからん。
535 名前：仕様書無しさん mailto:sage [2012/03/09(金) 02:19:25.21 ]: >>519
うちいま両方とも知らない奴が間にはいってるもんだから、手の内ようが無い状況だｗ
納品直前なのにまだドキュメントやらテスト仕様書やらつくってたりするｗｗ
笑えねぇけど笑うしかねぇｗｗｗ
536 名前：仕様書無しさん mailto:sage [2012/03/09(金) 02:22:41.82 ]: >>534
あー、あるわー
調整する立場の人間が調整する能力なくて、間接的に誘導して調整にもってったりとか…
何の仕事だかわからなくなる
537 名前：仕様書無しさん mailto:sage [2012/03/09(金) 02:46:00.45 ]: 事後と増やす仕事は、内向きにやらないで欲しいな。
538 名前：仕様書無しさん mailto:sage [2012/03/13(火) 12:29:12.58 ]: 空気を読まずに質問ｗ

おまいら、
スタイルシート編集ツール
は何使ってます？
539 名前：仕様書無しさん mailto:sage [2012/03/13(火) 18:31:35.61 ]: ふつーのてきすとえでぃた
540 名前：仕様書無しさん mailto:sage [2012/03/13(火) 20:30:53.74 ]: CSS用にエディタって使ったことないな
っていうか仕様書とはちがくねｗ
541 名前：538 mailto:sage [2012/03/14(水) 10:38:15.91 ]: あれ、CSSってＧＵＩでグイグイ書けないんですか？
それをキャプチャーして貼り付けたら仕様書、みたいなことを考えていたのですが。
542 名前：仕様書無しさん mailto:sage [2012/03/14(水) 16:10:40.53 ]: CSS編集ツールの話題はスレ違いだよ
Web製作板の「CSS初心者スレッド＝11th＝」スレヘ逝け
543 名前：538 mailto:sage [2012/03/14(水) 16:32:20.70 ]: Web製作板ね。WebProgを見て”無いな～”と思ってました。　つ㌧
544 名前：仕様書無しさん mailto:sage [2012/03/14(水) 23:33:46.33 ]: >>542
545 名前：仕様書無しさん [2012/03/17(土) 16:37:19.87 ]: UMLで設計を書いている。
asterのフリー版を使っているのだけど、使いにくくて気が狂いそうだ。
546 名前：仕様書無しさん mailto:sage [2012/03/19(月) 22:34:57.77 ]: >>545
マウスアイコン近づけるだけで線引きモードになる奴か？
あれ、親切のつもりだってんだから、参るよ。
547 名前：仕様書無しさん [2012/04/18(水) 20:33:01.78 ]: ｘｘ設計とか、設計書フォーマットが標準化されてくれりゃいいのになぁ
548 名前：仕様書無しさん [2012/04/18(水) 20:34:14.04 ]: ｘｘ設計とか、
↓
xx設計とかの呼称や、

各々が考えてるレベルが食い違いすぎてて、すれ違い多かったり認識あわせが面倒だったりで
全くいいことないわ…
549 名前：仕様書無しさん mailto:sage [2012/04/28(土) 11:58:14.08 ]: 詳細設計と基本設計のメジャー2つの範囲ですら人によって違うって変な話だよな
っていうか、詳細とか基本みたいな概念で分けようとしてるのがそもそもおかしいんじゃないか
550 名前：仕様書無しさん [2012/04/29(日) 16:10:07.02 ]: 仕様が決まってないうちに作り始めたものなんて大抵ろくなもんじゃないよな

つまり、仕様書の仕様が決まってないから、ろくでもないものしか作れないのは至極当然のこと！
551 名前：仕様書無しさん mailto:sage [2012/04/29(日) 22:29:39.25 ]: 自分で仕様書書くよね、普通
552 名前：仕様書無しさん [2012/05/04(金) 11:08:21.59 ]: 仕様書というか通信仕様や状態遷移は書くけどね。
会議で了承とかはとらない。

承認をとろうとDRをやっても、あげあし取りばかりで
開発期間が短くなるだけ。まぁ潰れるだろうな。
553 名前：仕様書無しさん [2012/05/04(金) 11:37:25.60 ]: <Sale>中国語版の書籍<文系・理系・ＩＴの諸分野>(格安)　280円より
lang-8.com/194279/journals/1457398/
554 名前：仕様書無しさん [2012/05/04(金) 12:09:30.10 ]: >>550
最近は仕様が固まる前から作り始めないと
間に合わない鬼畜納期の案件が多いよ。
555 名前：仕様書無しさん [2012/05/04(金) 12:18:52.12 ]: 仕様書設計書程、意味わからんものないな
行く場所行く場所で作法が違うw

まともなところは普通に作れるが、
今いるところだと要件定義が２行くらいしか書いてなかったり
しかも書いた奴が２年前に退社してるとか・・・・
そこから基本設計、詳細設計まで落とすのは苦しいわけで

つか何年前に始まったプロジェクトなんだよとツッコミ入れたくなった
556 名前：仕様書無しさん mailto:sage [2012/05/04(金) 16:37:48.84 ]: 仕様書で、同じ事柄を指す表記がまちまちなのはやめてくれんかね？　と思うことがある。
557 名前：仕様書無しさん mailto:sage [2012/05/04(金) 21:24:48.28 ]: 昔の大規模システム開発だと用語定義から始めたりしたんだが
まあ設計２年とか普通にあったからなぁ
558 名前：仕様書無しさん mailto:sage [2012/05/04(金) 21:40:24.68 ]: お作法レベルのものじゃなくてもっとグローバルスタンダードなものがほしいよな
この業界の無駄な仕事がかなり減って、残業も減ると思うわ
それで損する奴なんて、いるとしても能無しと中抜きしてる奴くらいだし
559 名前：仕様書無しさん mailto:sage [2012/05/04(金) 21:43:42.33 ]: >>556
とりあえずプロジェクト開始時につけた名前と、マーケティング的な都合でつけられた名前と、
ソースコード上の名前がバラバラってのはよくあるw
マーケティングの話とか現場まで伝わってこないから、上の人たちが話してるのを
「俺には関係ないや」とおもって聞き流してると、実は自分が担当してる機能の仕様変更
の話だったりしてあとで慌てる。
560 名前：仕様書無しさん mailto:sage [2012/05/04(金) 21:59:08.48 ]: >>557
基本設計書レベルでも今の詳細設計より詳しかったりするからね。
561 名前：仕様書無しさん mailto:sage [2012/05/06(日) 11:57:21.57 ]: 機能設計:UI設計(ユーザー及び外部装置からの入出力を伴う機能及び画面設計)と、
詳細設計:データ構造、モジュール間IF設計
だと思ってた。
本当に場所によってバラバラなんだね…
562 名前：仕様書無しさん mailto:sage [2012/05/06(日) 21:54:13.90 ]: ばらばらだって事に気づいてない奴がリーダーとかやってるとマジ糞
俺の知識が正しいを信じてるからな
563 名前：仕様書無しさん mailto:sage [2012/05/07(月) 11:35:37.42 ]: >>561
ビジネスロジックはUIじゃないだろ
564 名前：仕様書無しさん mailto:sage [2012/05/07(月) 11:43:07.65 ]: UIから作るのはまずい手だと私の設計の教科書は言ってる。
565 名前：仕様書無しさん mailto:sage [2012/05/07(月) 14:14:27.00 ]: プロトタイピングという言葉がなかった時代の教科書か
566 名前：仕様書無しさん mailto:sage [2012/05/07(月) 14:38:04.43 ]: プロトタイピングって、ハリボテを拡張していくことじゃないと思うんだ。
567 名前：仕様書無しさん mailto:sage [2012/05/07(月) 15:30:28.23 ]: UIに噛みついてる奴、まともな意見がないな
568 名前：仕様書無しさん mailto:sage [2012/05/07(月) 15:35:40.23 ]: では、まともな意見どうぞ
569 名前：仕様書無しさん mailto:sage [2012/05/07(月) 15:57:14.87 ]: 友愛に噛みつくのですか？
570 名前：仕様書無しさん mailto:sage [2012/05/07(月) 21:56:25.92 ]: プロトタイプは所詮ハリボテなんだから途中で捨てないといけないんだけど
現実はハリボテという砂上を拡張して製品作っちゃうんだよな
571 名前：仕様書無しさん mailto:sage [2012/05/08(火) 00:14:17.41 ]: 楼閣の方はどうするの？
572 名前：仕様書無しさん mailto:sage [2012/05/08(火) 07:41:52.38 ]: >>570
プロトタイプなのに細部に凝り始めるとヤバイ
トリガーとフィードバックのデモ程度で良いのに
573 名前：仕様書無しさん mailto:sage [2012/05/11(金) 01:59:24.95 ]: 仕様書に書かなくてもいいことまで書かないといけないルールがあったりするのがクソ
まともな内容ならむしろ作るほうに賛成なんだけどな
リファクタリングで変わるような内容まで設計書として作成するとかアホ
コードからじゃ判断できないもう少し外から見るための情報をメインに書かないと意味ないだろ･･･
574 名前：仕様書無しさん mailto:sage [2012/05/11(金) 02:10:39.19 ]: >>573
誰に見せるのか、何の目的で作るのか
ここがキッチリしてないと飛んでも無いものが出来上がるよな…
575 名前：仕様書無しさん mailto:sage [2012/05/11(金) 02:29:28.88 ]: お前等見ても結局理解しないだろ
んならそれはソースの中の情報で留めておいても問題ないじゃねーか
ってレベルの内容ですら書けっていうこともあったりするからな

仕様書設計書のグローバルスタンダードが欲しい
576 名前：仕様書無しさん mailto:sage [2012/05/18(金) 00:01:40.17 ]: テレビ番組の制作では、視聴者の知能を小学校低学年程度と想定して作るそうだけど
詳細設計書も作ってると、なんかそんな感じの気分になってくる
これなしでもだいたいのプログラマはコード書けると思うんだけどなあ・・・
577 名前：仕様書無しさん mailto:sage [2012/05/18(金) 09:20:29.77 ]: 詳細設計書＝日本語で実装だからなぁ～

あとは日本語からプログラミング言語（あるいはバイナリ）に変換できれば
ソフトウェアが出来上がるようになるのが理想なんでしょう
578 名前：仕様書無しさん mailto:sage [2012/05/18(金) 15:51:40.57 ]: >>576
馬鹿にわからないことは書かなかったりウソ書いたりするから
そういう状況で詳細設計の有無とコード書けるかは関係しないと思う
むしろ有ると詳細設計に縛られるせいで実装の難易度が上がることが多い

>>577
詳細設計からコード精製できるぐらい細かい事書いたら
詳細設計を要求する人には読めない複雑な代物になる
特に障害時の処理を漏れなく書くと怒られる
オフショアとかだとうまく書くんだろうけど俺には想像つかない世界
579 名前：仕様書無しさん mailto:sage [2012/05/18(金) 23:17:32.06 ]: > 詳細設計を要求する人には読めない複雑な代物になる

詳細設計を要求する人っていうのは
プログラマだよ。

プログラマがコードで書いているものを
読めないわけがないじゃないｗ
580 名前：仕様書無しさん mailto:sage [2012/05/19(土) 02:07:08.39 ]: オフショアはだいたいゴミだよ
あの手この手つくしてごまかして成り立ってる
コーダーはできる連中多いけど、橋渡ししてるところがクソ
581 名前：仕様書無しさん mailto:sage [2012/05/19(土) 09:17:38.12 ]: >>579
プログラマにプログラムレベルの仕様書見せるなら、自分でプログラム書いた方が早いから意味ないだろ。
かと言って、プログラム組めない奴にプログラムレベルの仕様書見せても理解出来ない。
大いなる無駄なんだよプログラムレベルの仕様書っていうのは。
582 名前：仕様書無しさん mailto:sage [2012/05/19(土) 09:58:14.71 ]: >>581
なんで仕様書の話になってるんだよｗ
馬鹿じゃないのか？
583 名前：仕様書無しさん mailto:sage [2012/05/19(土) 11:25:50.90 ]: 徹夜で詳細設計書書いて出したけど、どうでもいいところばっかり増やして
肝心なところは仕様わかんねえから抽象的なことに終始した
自分で言うのもなんだが、あれじゃプログラム組めないな
584 名前：仕様書無しさん mailto:sage [2012/05/19(土) 11:43:55.35 ]: そりゃそうよｗ

コードの内容を省略して書こうとしても絶対に無理。
コード＝設計なんだから省けないものを省けるわけがない。
585 名前：仕様書無しさん mailto:sage [2012/05/19(土) 11:44:35.84 ]: あれをみて、プログラムを書くのではなく

あんな方針で、プログラムを書く。

方針が書いてあれば良い。
586 名前：仕様書無しさん mailto:sage [2012/05/19(土) 14:58:33.24 ]: むしろコードに関わる内容が書いてある仕様はクソ
出来ないコーダーにはそういうの渡さないとクソコード上げてくるから難しいとは思うけど

機能のIFなりI/Oなりが変わらないようなコードの修正が、
仕様書の修正を引き起こすような内容で設計書に記載されてたら、基本的にそれらは全部ゴミ仕様書だわ

設計図じゃないんだからそんなに事細かに書く必要なんかない
2重管理するハメになって、管理できずに放置されてゴミに変わるのが目に見えてる
587 名前：仕様書無しさん mailto:sage [2012/05/19(土) 16:12:15.98 ]: コードを書くまえに仕様書があるのは
当然のことだが、その当然を妨害するものが多すぎる

仕様書の何が嫌だって、
気分屋の上司どものお伺いをたてて
承認をとらなきゃいけないこと。

有意義な指摘なら受け入れるんだが
どうでもいいようなことを指示して、それがしかも曖昧だったりすると
真面目につきあってたら、納期までに仕様書すらあがらない。
588 名前：仕様書無しさん mailto:sage [2012/05/19(土) 16:22:44.89 ]: 仕様書と設計書をごっちゃにしてないか？
仕様書が無いのに作るとかあり得無いだろ
589 名前：仕様書無しさん mailto:sage [2012/05/19(土) 17:17:04.54 ]: 設計って、プログラムレベルの設計の話してんだよな？
詳細仕様書的な物の話だろ？
なんか、何人か噛み合ってなくね？
590 名前：仕様書無しさん mailto:sage [2012/05/19(土) 21:22:49.51 ]: 設計はお客さんに見せたってしょうがない。
プログラマにとって必要な物が設計だ。

プログラマがゴミと言ったらそれはゴミでしか無い。
591 名前：仕様書無しさん mailto:sage [2012/05/20(日) 11:43:48.55 ]: >>587が言ってるのは設計書そのものではなくレビューに関する愚痴なので、要否ではなく日記だな
592 名前：仕様書無しさん mailto:sage [2012/05/20(日) 22:59:12.54 ]: 仕様書って、作るのしんどいわりにスキル的に得るものがないな
593 名前：仕様書無しさん mailto:sage [2012/05/20(日) 23:20:05.32 ]: >>592
他のところでも同じフォーマットでやれるなら、それなりに得るものはあるかと。

それ以上に、得たものをどう活かすかの方が大切なことですよ。
594 名前：仕様書無しさん mailto:sage [2012/05/20(日) 23:22:36.32 ]: > 他のところでも同じフォーマットでやれるなら、
それはない。やるのなら、自分がPMとして仕様書のフォーマットまで決める権限持たないと無理。
595 名前：仕様書無しさん mailto:sage [2012/05/21(月) 06:18:45.79 ]: フォーマットがあればいいけど、それすらない俺の職場は
596 名前：仕様書無しさん mailto:sage [2012/05/21(月) 07:14:30.81 ]: 仕様書はそもそも使う側、若しくは作る側との決め事を明確にするためにあるんだから労力関係無く無きゃ駄目
それに受け入れテストや品質管理上、作る側は実装の責任範囲の保証にもなる
無いとグダグダで無限ループのデスマ地獄になっちゃうよ(ノД`)
597 名前：仕様書無しさん mailto:sage [2012/05/21(月) 18:04:44.00 ]: >>596
仕様書があればそうならない環境であれば多分無くてもそうはならないよ
598 名前：仕様書無しさん mailto:sage [2012/05/21(月) 18:18:29.30 ]: >>597
そういうことじゃないよ。
仕様書がなければそうなる場合でも、仕様書があればそうならない場合もあるということ。
言い換えると、
仕様書があったためにそうならかった場合、仕様書がなければそうなる場合もあるということ。
599 名前：仕様書無しさん mailto:sage [2012/05/22(火) 00:26:22.53 ]: >>598
> 仕様書がなければそうなる場合でも、仕様書があればそうならない場合もあるということ。
これマジか
どちらかというと仕様書を曲解されるせいでグダグダで無限ループのデスマ地獄のイメージだが
600 名前：仕様書無しさん mailto:sage [2012/05/22(火) 00:32:36.45 ]: >>599
ハッキリと言っておこう、仕様書を曲解されるとかあり得無い、嫌、あってはなら無い事だからな
コミュニケーション力が低いじゃ済まされ無いですよ
仕様書も設計書も、「伝える」事の為にあるという事をきちんと考えていきましょうか
601 名前：仕様書無しさん mailto:sage [2012/05/22(火) 01:53:54.69 ]: 書く方はわかりやすく誤解をうまないように書くべきだし、読む方は読めるだけの予備知識と読解力が必要。
どっちがかけてもうまくいかないので、両方揃ってるのが理想。

でも、実際にドキュメントだけで作業を渡すと非効率。
ドキュメントとは別に、分担部分の概要を伝えて、一部を作って見せるのが望ましい。
ドキュメント読めって突き放す奴は無能。
602 名前：仕様書無しさん mailto:sage [2012/05/22(火) 10:53:38.81 ]: >>600
書く側に多くを求めるのは難しいんじゃないかな
待遇的に考えて

>>601
読む側に悪意がないこととそもそも読む気がある、も必要
603 名前：仕様書無しさん mailto:sage [2012/05/22(火) 22:05:14.12 ]: >>589
それな

実際仕事の現場でもよく見るけど、XX仕様書のレベルが
職場というかもはや人単位ですら微妙に異なってるから、ちょっとしたことのすれ違い多くてめんどくさいわ
いいかげん共通規格が必要だと思うわｗ
604 名前：仕様書無しさん mailto:sage [2012/05/22(火) 23:08:05.36 ]: >>603
2chはいつもここに気づくまで会話がかみ合わなくて、気づいたところで終わるんだよなw
そしてまた同じ会話をはじめるw
605 名前：仕様書無しさん mailto:sage [2012/05/24(木) 22:15:30.49 ]: クラス図はいいけど
他はあんまり役に立たない気がする
606 名前：仕様書無しさん mailto:sage [2012/05/24(木) 22:59:28.59 ]: 要件すら定義されてない機種のコードをどうやって書けばいいんだよ？
俺は最底辺なのに、なんで製品の動作の責任までとらされるのか
607 名前：仕様書無しさん mailto:sage [2012/05/24(木) 22:59:50.07 ]: ステートチャートは捗るぞ
608 名前：仕様書無しさん mailto:sage [2012/05/25(金) 13:41:41.18 ]: >>606
コード書けまではないけど要件定義前にステップ数出せってのはある
609 名前：仕様書無しさん mailto:sage [2012/05/25(金) 14:15:28.15 ]: あるな…
610 名前：仕様書無しさん mailto:sage [2012/05/25(金) 15:06:07.34 ]: で、2,000行1人月な、的な話もちょっと前まではたまにあった。
だから逆算して行数を出すことにしてた。
611 名前：仕様書無しさん mailto:sage [2012/05/26(土) 11:30:11.77 ]: そもそも行数なんて今日日なんの意味もないことが明白だのに、いまだ使い続けてるあたりがアレだよなぁ
612 名前：仕様書無しさん mailto:sage [2012/05/26(土) 19:03:42.37 ]: 俺が三角関数や微分方程式を駆使して数値を出す計算式を1ステップで書いたら、
何も仕事してねえとか言われたよ。

先輩は単純な放物線を求めるだけで50ステップ以上。
単純な数式をあんなスパゲティでピラミッド構造に作っていたら、修正とかとんでもないことになると思うんだが。
613 名前：仕様書無しさん mailto:sage [2012/05/26(土) 19:45:40.20 ]: >>608
なんでそんなの出るんだよ
バッカじゃーんって出せって言った奴に言ってみればよくね？
614 名前：仕様書無しさん [2012/05/27(日) 00:28:17.84 ]: 洋服に付いている洗濯方法の絵表示が全面変更される。経済産業省は、
日本国内だけで使われている日本工業規格（ＪＩＳ）表示を２０１４年にも改正し、
国際標準化機構（ＩＳＯ）が定めた国際規格にそろえる方針。

ＩＳＯ規格は欧州などで普及している記号がベース。大きな変更点は、洗いの表示から
「洗濯機」がなくなり、「たらい」に統一されること。手洗いは、たらいに手を浸した
絵で表す。

乾燥方法の表示は「服」や「手絞り」の絵が廃止され、「四角」に一本化。乾燥機使用
の表示は「四角の中に丸」。自然乾燥は「四角の中に棒」となる。
alp.jpn.org/up/s/9905.jpg
615 名前：仕様書無しさん mailto:sage [2012/05/27(日) 18:39:27.91 ]: >>612
分解がめんどくさいコードは一長一短だけどなー
コスト差ないなら、馬鹿がコードに触る可能性がある場合はあえて崩して書くこともある

まぁその先輩()とやらがやってたのはクソコードなのはなんとなくわかるｗ
ステップ数が多い、ってのは、仕事してるんじゃなく大半はただ無駄が多いだけだからな
616 名前：仕様書無しさん mailto:sage [2012/06/17(日) 16:13:44.20 ]: 公開メソッドの多いクラスなんかのコードだと、行数の1/3はコメントだったりするわ…
ステップ数で仕事量測るくらいなら、ツール使ったユニットテストのケース数とか数えたほうがまだ幾分かマシ
617 名前：仕様書無しさん [2012/06/18(月) 01:38:39.32 ]: 無駄な仕様書を減らして、有用な情報だけを残すにはどうすればいいのか…

「既存」の呪いを解呪できるアイテムの実装が必要？(´・ω・｀)
618 名前：仕様書無しさん mailto:sage [2012/06/18(月) 09:39:09.74 ]: デスマプロジェクトで、詳細設計書が顧客にボロクソに言われて全面修正してるのに
他所で作ってるそこのプログラムは完成して、客にも渡したみたいなんだけど、どういうことなの
619 名前：仕様書無しさん mailto:sage [2012/06/18(月) 10:50:08.03 ]: コードに合わせて詳細設計書を修正しろってことだろ。
620 名前：仕様書無しさん mailto:sage [2012/06/18(月) 13:30:18.11 ]: >>617
術者を○す
621 名前：仕様書無しさん [2012/06/18(月) 23:42:10.71 ]: 世の中にはびこる負の遺産や呪いの術者を殲滅することが次の世代のマに託されてる…？
622 名前：仕様書無しさん mailto:sage [2012/06/19(火) 14:33:23.74 ]: >>618
根回し重要
623 名前：仕様書無しさん [2012/06/19(火) 22:32:12.33 ]: 物の品質よりそういうところが重要ってあたりが、土方くさくてやんなるな
624 名前：仕様書無しさん mailto:sage [2012/06/19(火) 22:54:27.82 ]: とりあえず納品物に仕様書を要求するんじゃなくて読み安いコードを要求するようにしろや
品質に直結してウハウハだぞ
625 名前：仕様書無しさん mailto:sage [2012/06/21(木) 10:44:31.63 ]: >>624
コードくれないところ多いよ
626 名前：仕様書無しさん mailto:sage [2012/06/22(金) 04:52:34.33 ]: 要求が曖昧なら
どういう資料作っても無駄になるだけでしょ
627 名前：仕様書無しさん mailto:sage [2012/06/22(金) 04:57:00.54 ]: プログラム読めない系の人が完成後に
資料、資料
って騒ぐみたいだよ
628 名前：仕様書無しさん mailto:sage [2012/06/22(金) 06:38:29.74 ]: >>627
そういう人が欲しいのは、仕様書設計書じゃなくて、多分操作マニュアルが
欲しいんだろうね。
629 名前：仕様書無しさん mailto:sage [2012/06/22(金) 19:23:22.84 ]: 大工さんに、家の作り方を一から書いてください的な、資料？
630 名前：仕様書無しさん mailto:sage [2012/06/22(金) 22:20:11.84 ]: いいえ、他の大工さんが仕事を引き継げるような資料です。
631 名前：仕様書無しさん mailto:sage [2012/06/22(金) 22:43:08.90 ]: それ、設計士が図面書いた時点で終わってるでしょ
図面通りじゃないところぐらいじゃ、必要なのは
632 名前：仕様書無しさん mailto:sage [2012/06/22(金) 23:06:34.32 ]: 引き継ぎどころか、一緒にやってるメンバーでさえ見ない(見てもわけわからん)
資料を大金かけて作ってるわけだが。。
633 名前：仕様書無しさん mailto:sage [2012/06/22(金) 23:08:13.94 ]: SEという人種が要求を噛み砕けんから、おかしくなるんじゃねえの？
客の太鼓道程度じゃ、そのうち...
634 名前：仕様書無しさん mailto:sage [2012/06/22(金) 23:08:42.06 ]: >>631
一般的に設計士は、どういうものを作れという資料しか作らないので、
どうやって作ったかの資料が必要。
635 名前：仕様書無しさん mailto:sage [2012/06/22(金) 23:11:19.12 ]: >どうやって作ったかの資料が必要。
はあああああああああああああああああああああああああああああああ
ソースが読めません系？
636 名前：仕様書無しさん mailto:sage [2012/06/23(土) 00:08:18.24 ]: >>635
なんで資料残しとけば節約できた無駄な工数かけてまでソースを解読しないといけないんだよ。
趣味でやってるんならソース読めで済ませられるけど、職業人でそんな態度なら初心者だね。
637 名前：仕様書無しさん mailto:sage [2012/06/23(土) 00:14:10.78 ]: ソースが読めないから工数がかかるって言ってるような
638 名前：仕様書無しさん mailto:sage [2012/06/23(土) 00:36:50.60 ]: ソースしかないけどよろしくっていうプロジェクトの場合、
普通システム解析の工数を計上するだろ。
工数計上しなくて済むのは、数千行程度の極小さなプログラムのときくらい。
639 名前：仕様書無しさん mailto:sage [2012/06/23(土) 00:38:42.65 ]: 読めないのに、ソースの間違い探しができるのかい？
640 名前：仕様書無しさん mailto:sage [2012/06/23(土) 00:42:17.75 ]: うん、ソース読めるからソース読む工数を計上してるんだね。
641 名前：仕様書無しさん mailto:sage [2012/06/23(土) 02:22:41.06 ]: 書けるのに読めません系が作る完成後の資料ってどういう内容なんだろうね？
読めません系が集団の職場って？
642 名前：仕様書無しさん mailto:sage [2012/06/23(土) 13:10:25.03 ]: >>641
世の中には驚くほど文章を読めない人が多い。2chの3行以上のレスは
読まないってのがネタじゃなくてマジな奴が普通にいるし、Twitterの
140文字ですら読めてるか怪しい人が数多くいる。
643 名前：仕様書無しさん mailto:sage [2012/06/23(土) 16:20:17.99 ]: 仕様書に明記してあれば数分で済むロジックの目的を、
ソースコード上から解析して文章としての仕様にデコードするのは、面倒なケースも多いぞ
ソースと実装が異なる可能性があるから最終的にはコードを見る必要はあるとしても
それがバグなのか仕様どおりの実装なのかは、コードでしか表現されてないと判断つかない

UTがちゃんと作成されているなら別だが、
日本の土方系プロジェクトでちゃんとしたテストコードを作れてるものなんてかなりレアだし
それが出来てるところはちゃんとした仕様書、設計書に値するドキュメントもある
644 名前：仕様書無しさん mailto:sage [2012/06/23(土) 16:27:15.12 ]: >>643
仕様的に欲しいのは入力に対する結果であって経緯ではないから。
645 名前：仕様書無しさん [2012/06/23(土) 16:31:17.44 ]: そもそも、有用なドキュメント残せないようなプロジェクトのコード自体信用できるわけねーしな。
何をやりたかったかっていう目的はにコードだけじゃ判別つかん。
コードが絶対だ、既存だからバグじゃないっていう、糞コーダーの言い訳と同じ。
646 名前：仕様書無しさん mailto:sage [2012/06/23(土) 17:24:21.80 ]: なぜ、仕様書作成に時間を割きながらして、ソースコードはスパゲッティなのかが腑に落ちない。

設計からしてめちゃくちゃな可能性があるけど。
647 名前：仕様書無しさん mailto:sage [2012/06/23(土) 17:35:09.87 ]: 単純な話で、何の意識合わせもなく多人数で手分けしてつくるからだよ。
648 名前：仕様書無しさん [2012/06/23(土) 18:03:33.39 ]: スパゲッティになるのは単純に知識不足だと思うな。興味が持てないから知識が増えないんだろうけど
好きこそ物の上手なれってやつ

よくある系のアルゴリズムについての知識だったり、言語仕様的な通例や制約をしっているかどうかだったり、
デザインパターンみたいなのを知ってるかどうかだったり、こういう差がスパゲッティを作らないうえで重要だと思う

経験から、どう書いてあると後から見るのが大変か、どうなってると後から修正とかしやすいか
なんかを学んでいくだけでもマシにはなるけど、職場が同じようなレベルのとこばっかだと
視野が狭いままで、そんなに学べることは多くない場合が多い

仕様書設計書の話題ではないけどなｗ
649 名前：仕様書無しさん mailto:sage [2012/06/23(土) 18:13:52.30 ]: スパゲッティになるのは仕様書作成に時間を掛けすぎて、
ソースコードを書く時間が足りないからだよ。

本来なら十分な時間を掛けて、
ソース設計→ソースコードを書く→リファクタリングをやらないといけないのに、
スキルに対して納期が短すぎて「ソースコードを書く」部分だけをするから
スパゲッティになるのは必然。
650 名前：仕様書無しさん mailto:sage [2012/06/23(土) 20:56:29.84 ]: ソース設計ってより
何作るかわかってないから、ワケワカになるじゃね

問題に対する読解力が足りないと数学解けないのと同じ感じ？
651 名前：仕様書無しさん mailto:sage [2012/06/23(土) 23:02:28.11 ]: 仕様書作りとコーディングが同時に動いてる現場って少なくないけど
そういうのに放り込まれると、本当このEXCEL方眼紙に書きなぐってるものは何なんだろうなって思う
652 名前：仕様書無しさん mailto:sage [2012/06/23(土) 23:39:07.55 ]: クソ仕様書から正確な仕様書を書く作業から始まる
653 名前：仕様書無しさん mailto:sage [2012/06/24(日) 01:08:52.21 ]: 昔からバグのまったく無いプログラムは作れないといわれているが、
実際には、バグのまったく無いプログラムは見たことあるが、

バグのまったく無い仕様書は見たこと無いw
654 名前：仕様書無しさん mailto:sage [2012/06/24(日) 01:23:50.99 ]: >>652
地味にそういう事からやるほうがいいんじゃね
余裕があるならコーディングしながら矛盾点を洗い出していくとか
655 名前：仕様書無しさん mailto:sage [2012/06/24(日) 03:30:05.08 ]: >>652
だいたいそれやってるけど、必ず既存のバグ見つかってアレ
656 名前：仕様書無しさん mailto:sage [2012/06/24(日) 10:19:20.59 ]: >>655
たしかにそうだけど、それは仕様書再作成作業による机上バグ摘出という成果であると
前向きに考えているよ
657 名前：仕様書無しさん mailto:sage [2012/06/24(日) 14:32:24.06 ]: >>656
コンパイラができること（エラーチェック）を脳内でヤルわけですね？
658 名前：仕様書無しさん mailto:sage [2012/06/24(日) 14:41:26.41 ]: コンパイルできることと、バグが無いことは違うよ？
659 名前：仕様書無しさん mailto:sage [2012/06/24(日) 14:49:36.03 ]: テストがあることと
バグがないことも違うよ。
660 名前：仕様書無しさん mailto:sage [2012/06/24(日) 15:39:55.23 ]: >>657
何を言いたいのか意味不明なんだが、もしかすると>>657はコードと
一対一に対応するような設計書(仕様書???)を書いているのか？
それとも>>657のコンパイラとは、
Z/VDM/CSPのような形式的仕様記述言語の検証系を指しているのかな？
まさかコンパイラが(構文エラー以外の)論理的なバグまで検出できると本気で思っているの？
訳が分からんわwww
661 名前：仕様書無しさん mailto:sage [2012/06/24(日) 15:51:32.09 ]: >>660
”コンパイラができること” ってちゃんと書いてますよね？

コンパイラができないことが、コンパイラできるなんて
どうしてそんな変なことを言い出してるの？
662 名前：仕様書無しさん mailto:sage [2012/06/24(日) 16:17:42.24 ]: >>661
>”コンパイラができること” ってちゃんと書いてますよね？

>>657では、「ちゃんと」書いているつもりなのか？

自分は、”コンパイラができることを” とは構文エラー検査であり、
"脳内でヤル" とは(>>656の)仕様書再作成作業のことだと解釈し、
「構文エラー検査を仕様書作成作業内でヤル」という>>657の発想が意味不明だと>>660で書いた
もしもこの解釈が間違っていたのなら教えて下さいませ

あと、仕様書再作成作業の前に全コードをコンパイル通過させておくのは、常識だと考えているよ
663 名前：仕様書無しさん mailto:sage [2012/06/24(日) 19:37:25.95 ]: コンパル時にエラー出ても読まない、わからない人が仕様書書くことがあるからね
664 名前：仕様書無しさん mailto:sage [2012/06/24(日) 19:38:10.50 ]: ×コンパル時
○コンパイル時
665 名前：仕様書無しさん mailto:sage [2012/06/24(日) 20:25:56.27 ]: こんぱそ時
666 名前：仕様書無しさん mailto:sage [2012/06/24(日) 23:39:28.20 ]: >>663
それって>>657のことかしら？
667 名前：仕様書無しさん mailto:sage [2012/06/24(日) 23:46:19.00 ]: リアル会社でそういう人がいたんですよ
コンパイルのエラーって何？
って、感じの人が
668 名前：仕様書無しさん mailto:sage [2012/06/25(月) 06:24:49.76 ]: またまたご冗談を
669 名前：仕様書無しさん mailto:sage [2012/06/25(月) 06:43:59.74 ]: PC触ったことない、持ってないようなのも
口がうまければ普通に入ってくる業界だからな
670 名前：仕様書無しさん mailto:sage [2012/06/25(月) 20:56:34.12 ]: 20世紀末ごろのエラーメッセージが英語の頃はなにそれが普通だった
エラーメッセージが日本語化されてもなにそれは状態な人がいっぱいいそうだけど
671 名前：仕様書無しさん mailto:sage [2012/06/26(火) 02:43:52.29 ]: エラー出た、で思考停止する馬鹿は結構いるぞ
まじ辞めればいいと思うわ…
672 名前：仕様書無しさん mailto:sage [2012/06/30(土) 03:05:17.20 ]: 工数稼ぐためにそういう人達が完成図書みたいなの作ってるんかね
673 名前：仕様書無しさん mailto:sage [2012/06/30(土) 21:27:28.45 ]: >>671
赤バッテンのアイコンでエラー表示するとパニクって思考停止するヤツが
後を絶たないので黄色の警告アイコンにしてやったwwww
674 名前：仕様書無しさん mailto:sage [2012/06/30(土) 21:32:56.59 ]: シイタケ？
675 名前：仕様書無しさん mailto:sage [2012/07/03(火) 02:36:38.73 ]: ｢我々は高い技術力を持っている｣｢業務ソフトを開発した経験がないとわからないだろ｣が口癖のガイキチは、
グローバル変数とローカル変数の違いもわからず、
それこそプログラマ1年目でも小学生でも簡単に作れるようなサンプルプログラムを作らせてみたら
思った通り一目で動作しないとわかるものを出して来やがった。
676 名前：仕様書無しさん mailto:sage [2012/07/03(火) 20:31:28.12 ]: 資料だって言ってる割には、時代についていってないような書き方だけが伝承されてるだけだったりして
677 名前：仕様書無しさん mailto:sage [2012/07/13(金) 01:47:24.24 ]: ＞仕様書再作成作業の前に全コードをコンパイル通過させておくのは、常識

何言ってんだこいつ。
678 名前：仕様書無しさん mailto:sage [2012/08/22(水) 00:52:30.02 ]: メンテナンス出来ない/しにくい仕様書はいらんな～
679 名前：仕様書無しさん [2012/08/23(木) 17:15:51.25 ]: うちの画面仕様書びっくりするほど横長だった。UXGA×2枚、SXGA×1枚でおさまりきらない。
書くのも大変だけど見るというか読むのも大変そうだ。
680 名前：仕様書無しさん mailto:sage [2012/08/23(木) 19:05:10.57 ]: まるでWindows8のスタート画面みたいだな。
681 名前：仕様書無しさん [2012/08/24(金) 00:27:36.99 ]: 今日気がついた。仕様書を書いてるときってかなりコピペしてる。
似たような記述が仕様書にいっぱいちりばめられてる。
仕様変更時にこれを全部メンテする自信はまったくない。
682 名前：仕様書無しさん mailto:sage [2012/08/24(金) 13:14:29.14 ]: ソースコードの解読が容易な案件は仕様書なくていい。
糞みたいなソースコードの案件は、仕様書も糞。

仕様書いらね。
683 名前：仕様書無しさん mailto:sage [2012/08/25(土) 00:01:23.36 ]: >>682
ソースコードの解読が容易だが
バグが含まれているコードの場合はどうなるんだ？
684 名前：仕様書無しさん [2012/08/28(火) 18:59:19.16 ]: >>678
メンテしやすい仕様書ってどうやったらできるんだろう？
685 名前：仕様書無しさん mailto:sage [2012/08/28(火) 19:46:59.05 ]: 使うためのマニュアルをメンテとかならわかるんだけど

プログラムのプの字もわからんでもやれる虎の巻みたいなのが欲しいだけなのかな
686 名前：仕様書無しさん mailto:sage [2012/08/28(火) 20:12:03.95 ]: 仕様書は上司と実際に作った俺の頭の中にしかなく、
しかも上司が実装可能と考えていた仕様はほとんど実装不可能で、大幅に改変せざるを得なかった。
にもかかわらず上司の初期構想の仕様書しかなく、俺にはそんな時間はなかったため
引き継いだ奴らが実装をわからずメンテナンスしたためにとんでもないスパゲティに。

コメント文で仕様書の実装は不可能なのでこう実装したと全て書いたんだけどなあ。
687 名前：仕様書無しさん [2012/08/30(木) 09:18:06.05 ]: >>685
仕様変更あったときに楽に間違いなく書き直せる仕様書であってほしいってことじゃね？
688 名前：仕様書無しさん mailto:sage [2012/08/30(木) 16:05:00.50 ]: >>687
仕様書直したら、ソースが直ると、思ってるとか？
689 名前：仕様書無しさん mailto:sage [2012/08/30(木) 16:07:07.41 ]: 回路図方面の解説書とか見たことないなあ
見れるのは図面とやれることが書いてあるもんぐらい
690 名前：仕様書無しさん [2012/08/30(木) 16:12:05.41 ]: ソース直してると仕様の漏れが山ほど見つかる。
フィードバックするのもめんどくさいぐらいに。
691 名前：仕様書無しさん mailto:sage [2012/08/30(木) 19:01:44.84 ]: >>684
う～ん、難しいんだよね。

いま社内で仕様書の標準/統一化を進めてるんだけど、一向に進まないし…

確実に統一できそうなものは目次、表紙だけだわw

そもそも仕様書って誰のためのもの？プログラマ？ユーザー？上司？

ここをまず明確にすべきだと思うな～

それによって、どう書いていった方がメンテナンスしやすいかが定まってくると思う

けど、これも難しいんだよね～。あぁ死にたい。
692 名前：仕様書無しさん mailto:sage [2012/08/30(木) 19:48:40.68 ]: ソースの中身を検証できるようにするほうがよくねえか？
客、上司に媚びうる資料でもうけようってのならわかるけど
693 名前：仕様書無しさん mailto:sage [2012/08/30(木) 20:15:15.09 ]: >>691
> そもそも仕様書って誰のためのもの？プログラマ？ユーザー？上司？
一つで済まそうとせずに、それぞれ書き分けたほうがいい。
694 名前：仕様書無しさん [2012/08/30(木) 20:49:05.16 ]: 書き分けるとそれぞれの内容が整合しなくてどこかでモメることになりそうな悪寒
695 名前：仕様書無しさん mailto:sage [2012/08/30(木) 20:50:24.03 ]: 分けるにしても
どう分けるか考えんと
696 名前：仕様書無しさん mailto:sage [2012/08/30(木) 22:25:35.19 ]: >>691
＞そもそも仕様書って誰のためのもの？プログラマ？ユーザー？上司？

引き継ぎをする人のためのものだよ。　客側、開発側関係なく開発時に
いなかった人間に対して、5W1Hじゃないけどソースを読んだだけじゃ
分からない、ソースを読まなくても最低限のことが分かることが書いて
あればいい。　逆に言うと、ずっと生き字引並にシステムに精通したのが
面倒見てくれるなら仕様書なんていらない。
697 名前：仕様書無しさん mailto:sage [2012/08/30(木) 22:52:23.45 ]: 受験の虎の巻みたいなのが欲しいだけでしょ
698 名前：仕様書無しさん mailto:sage [2012/08/31(金) 01:19:12.12 ]: ソースの改定記録残したほうが下手な完成図書作るよりマシだろうに
699 名前：仕様書無しさん mailto:sage [2012/08/31(金) 02:06:46.95 ]: >>697
受験の問題には正解があるけど
仕様書には正解はないからな。

他人の考えや決めたルールを知るには仕様書が必要。
700 名前：仕様書無しさん mailto:sage [2012/08/31(金) 02:47:08.70 ]: >>698
残すも何も、普通はVSSやCVS、Gitなんかのソースコード管理を使うはずで、
よっぽどアホなことしない限りは履歴は残る。　

まあ、そのアホなことをする企業は少なからずあるし、小さい企業より
日常的に使わない大企業のSヨさんとかがやらかしてくれるけどね。
なんでSCM使ってるのに紙で別出しで台帳管理をしようとするかな、、、
701 名前：仕様書無しさん mailto:sage [2012/08/31(金) 10:05:42.42 ]: ソースコード管理すると言ってる人が
実はソース読めませんというオチが
702 名前：仕様書無しさん mailto:sage [2012/08/31(金) 12:25:05.09 ]: > なんでSCM使ってるのに紙で別出しで台帳管理をしようとするかな、、、
台帳管理を仕事としてる人の仕事を奪っちゃいけません。
703 名前：仕様書無しさん mailto:sage [2012/08/31(金) 20:01:57.98 ]: 紙で承認受けないと管理したことにならない社内標準があるんだよ。
勘弁してくれ。
704 名前：仕様書無しさん mailto:sage [2012/08/31(金) 20:32:11.37 ]: 電子データになってるのを知らない老害がいるの？
705 名前：仕様書無しさん mailto:sage [2012/08/31(金) 21:31:51.33 ]: もうボケが始まってて、現代でもパンチカードでプログラム書いてると思ってるんだよ
706 名前：仕様書無しさん mailto:sage [2012/09/01(土) 07:15:19.81 ]: 電子データは見方が判らんし、変更しても判らない。
紙で自分のサインがある書類がなきゃ信用しない老害は多い。
そしてそんな老害は、紙の2ページ目以降が丸ごと差し代わっていることを知らない。
707 名前：仕様書名無しさん mailto:sage [2012/09/01(土) 11:33:55.42 ]: >>691
仕様書の標準化をする上で必ず議題となるのは、

•設計情報の網羅性
•誰が書いても同じ物になる記述レベルの統一性
•ドキュメント間の整合性
•ドキュメントのメンテナンス性
•作成コストおよび作成時間
•納品物件としての仕様書要求レベル
•設計するためのドキュメント
•プログラマーのためのドキュメント
•保守のためのドキュメント
•読ませる奴の技術レベル
•ドキュメント作る奴の技術レベル
•実際ドキュメントがいい加減でもプログラムはちゃんと出来たりする。

これらを考えると、結局みんなが幸せになる標準化なんて不可能って早々に気づく•••
708 名前：仕様書無しさん mailto:sage [2012/09/01(土) 16:51:17.22 ]: 盗撮して御用になる元IBM社長みたいな老害がいっぱいの世の中
709 名前：仕様書無しさん mailto:sage [2012/09/02(日) 03:17:23.15 ]: 大手ほど無能も多いからなー
なまじ職場は同じなだけに、技術職との開発業務に対する温度差が激しい
結局、出来ること出来ないことを理解してない層は調整とかそういうのは無理なんよ
ノウハウがないなら勉強しないといけないけど、そういうのしないでもなーなーでやって桁利するから、余計に成長しない
ドキュメントが詳細に必要になるのは、客と開発の間に人が無駄に入りすぎるせいだわなー
710 名前：仕様書無しさん mailto:sage [2012/09/02(日) 03:18:44.51 ]: なまじ職場は同じなだけに、同じような仕事に見られるけど
実際に作ってる技術職してる人と、客とのやり取りだったりドキュメント弄繰り回したりする人とだと、
開発業務って部分に対する興味の温度差が激しい

訂正しようとしてたら書き込み押してしまったよ('`)
711 名前：仕様書無しさん mailto:sage [2012/09/02(日) 06:27:16.93 ]: ちょっとスレ違い気味になるけど、日本の役所はいい加減ウォーターフォールに固執するの止めて欲しい。
役所の仕様基準の元がMILなのは良いけど、そのMILは30年以上前に改訂されとっくに廃止されてる。
かなり前からプロトタイプ推奨に変わったし、今はアジャイルやスパイラル前提だ。
ウォーターフォールの失敗を認めて非推奨にしてる。
で、アジャイル以降の場合、ドキュメントの自動化が必須なんだ。
そんな細かな修正、いちいち直してらんないから。
なのにウォーターフォールと手で作ったドキュメント求め続ける役所。
見積りの精査も出来ず、高々100行程度の改修で億払うって、ほんとバカしか居ない。
712 名前：仕様書無しさん mailto:sage [2012/09/02(日) 06:38:20.92 ]: > このため現実のウォーターフォール・モデルの開発プロジェクトでは、
> 前工程の完了要件（要件定義局面であれば、要件定義書などの成果物の完成）を
> 徹底して品質を高め、後戻りの発生率を可能な限り低下させるとともに、
> 後戻りが発生する場合は変更管理によって公式に決定し、
> 後戻りや横展開を確実にフォローする。
２０年前ぐらいなら通用した考え方だね
今の情報量は半端じゃないからね

> 要件定義
って、うるさい文系院卒がいたけど
今のコンピュータのことが全然わかってなかった

今だに、非力なパソコンの流行りはじめの事例が通用するとか思ってるんかね
時代についていけてない人は...

紙の上で終わらせたいとか？
713 名前：仕様書無しさん mailto:sage [2012/09/02(日) 07:12:36.41 ]: 昔はのんびりと時間がかけられたからね。
例えば一年単位でプロジェクトを回しているところとかだと、
プログラマに仕事が回ってくるのは年度の後半(10月とか11月～)だったり
したもんだ。SEはそれまでに半年かけて文書の作成をやってればよかった。

ところが、今みたいに同じ作業を3～4ヶ月で終わらせないといけない状況だと、
文書化とコード作成を同時並行で動かさないといけないわ、期間が短い分
精度が落ちてるから手戻りが増えてるわ(しかも、ウォーターフォールだと
手戻りがやたら面倒くさい管理方法とってるから大変)で、破綻してるんだよね。
714 名前：仕様書無しさん mailto:sage [2012/09/02(日) 07:28:41.54 ]: 無理に短納期にして、自分の首絞めてるだけでしょ
人月計算が時代に合わなくなってきてる？
715 名前：仕様書無しさん mailto:sage [2012/09/03(月) 02:37:04.18 ]: 客と作り手の間に挟まる人数をもっと減らすしかない
716 名前：仕様書無しさん mailto:sage [2012/09/03(月) 03:02:52.38 ]: 大手から下請けにっていう構図があれなんだよな
リスク回避のための保険という意味はわかるんだけど

無駄を無駄だって言える人がいればなぁ
717 名前：仕様書無しさん mailto:sage [2012/09/03(月) 03:05:20.03 ]: 大手が下請けって思いたいだけなの、今や

下請けいじめとかTVで報道されて恥ずかしくないのかね、大手系
718 名前：仕様書無しさん mailto:sage [2012/09/03(月) 18:12:13.96 ]: 大手とか関係なく、自社に人が確保出来ないってのは大きいよ。
常に人を確保出来るほどの仕事がある会社は少ないから、必要な時に集める。
実際、土方と同じ理由だよね。
719 名前：仕様書無しさん mailto:sage [2012/09/03(月) 20:22:23.42 ]: 人海戦術が通用しなくなってきてるから、困ってんじゃないの？
短納期にこだわりすぎて
短期で仕様と設計まとめれる人いるんかい
720 名前：仕様書無しさん mailto:sage [2012/09/04(火) 06:48:07.12 ]: 色々無理のある業界だよね。
本当に設計を纏められる人は一握り。
なのに短期間でのウォーターフォールだから、ドキュメントすら作るのに精一杯。
そこにレベルの下がる派遣かき集めても、OJTする時間すらない。
しかも見積りは人月の数字を舐めさえすれば安くなるから営業は無理な案件でも取ってくる。
せめて、プロトタイプ手法でも使えれば、少数精鋭でプロトタイプ作った後、レベルの下がる派遣に展開する手が使えるのに。
721 名前：仕様書無しさん [2012/09/05(水) 16:42:22.18 ]: 人海戦術でのソフト開発は、映画作りに似てるね？

原作という要件書があっても
監督のアタマの中のイメージと絵コンテを頼りに
セット制作を指示し、本番突入で何とか試行錯誤で
作り上げる。

映画と違う点は、その後も山のようなバグ取りと運用サポートに忙殺される。
722 名前：仕様書無しさん mailto:sage [2012/09/05(水) 21:00:16.80 ]: マとSEは時間少なすぎて、残業まみれでしまいに頭おかしくなって
客はバグまみれでちょっと動かすと落ちたり計算結果が狂うシステムにイライラして
携わった人間だけをみると、Lose-Loseな状態だよなあ。こんなITで誰か幸せになってんのか？
723 名前：仕様書無しさん mailto:sage [2012/09/05(水) 23:08:08.10 ]: 余裕のない状況作って、実は喜んでる人がいたりするのがなんとも
724 名前：仕様書無しさん mailto:sage [2012/09/06(木) 00:42:28.17 ]: 安かろう悪かろうの需要がまだあるうちは何とかなるだろうけど、未来はないよね
725 名前：仕様書無しさん mailto:sage [2012/09/06(木) 01:18:00.25 ]: 今の状況がわかってない人達が、自分で自分の首を絞めてるだけ？
726 名前：仕様書無しさん [2012/09/06(木) 06:06:54.00 ]: >>722
ろくな仕事もないのに仕事をした振りできる公益法人やら天下り団体の職員が喜ぶんですよね。

そういう予算だけはあるけど仕事がないところがなんでもかんでも発注するし、
使い勝手とか機能とかがでたらめな内容で発注しまくるものだから
システム開発する側もろくなものを作らず、
結果として無能の再生産をする。
727 名前：仕様書無しさん [2012/09/06(木) 08:08:29.54 ]: 基本も詳細も設計書は顧客向けに出すものではなく、V字モデルのテスト設計資料として活用するもの
そうやれてる企業は存在しないけどｗ
顧客向けなんてマニュアルと営業パワポでいい
728 名前：仕様書無しさん [2012/09/08(土) 11:30:54.54 ]: このスレダメすぎ。
仕様書、設計書、言ってる地点でアウトなんだよ。
いいかげん、ウォーターフォールを滅ぼさないと日本が滅びる。
729 名前：仕様書無しさん mailto:sage [2012/09/08(土) 11:50:04.08 ]: 顧客
↓
マニュアル
↓
結合テスト
↓
単体テスト
↓
コーディング
↓
仕様書

どうしてもウォーターフォールやりたいなら、こういう順序がいいと思うよ、本気で。
730 名前：仕様書無しさん [2012/09/08(土) 12:11:47.34 ]: 「コードもないのにどうやって結合テストするの？」
とか言ってんの、もうねアホかとバカかと。

これはソフトだけの話じゃないんだよ、ハードだって開発はそういうもんなんだよ。
車の開発をしようとしたら、まずテストコースを準備する。
開発チームごとニュルに行く。
そこから始まる。当たり前の話。
731 名前：仕様書無しさん mailto:sage [2012/09/08(土) 12:41:35.07 ]: テストコースなんてどこにでもあるじゃん。
俺なんか公道でドリフトの練習しまくったよ。
字乞田けど。
732 名前：仕様書無しさん mailto:sage [2012/09/08(土) 13:52:16.21 ]: ツーホー
733 名前：仕様書無しさん mailto:sage [2012/09/08(土) 13:52:42.14 ]: 面白いと思って言ってるんだろうから、そっとしておいてあげような
734 名前：仕様書無しさん mailto:sage [2012/09/08(土) 15:11:28.44 ]: 「どこにでもある」
つまり、顧客環境＝開発環境が当たり前の場合、
理論と実際の誤差が生じていてもなんとかなってるんだ。

逆に、特殊環境で動かさなければならないソフトの場合だ。
そのエミュレータを手前に準備しなければコーディングしにくい。

「当たり前にないテスト環境を整えることを先にやらなければならない」

この手順を突き詰めると、ウォーターフォールの誤謬に直面する。
そこから、テスト・ファーストという考えに辿りつく。
735 名前：仕様書無しさん mailto:sage [2012/09/08(土) 15:30:21.57 ]: > そのエミュレータを手前に準備しなければコーディングしにくい。
そんな事情は考慮しない。設計どおりのコーディングをすれば、
問題なく動くコードが出きるはずだ。
736 名前：仕様書無しさん [2012/09/08(土) 15:50:09.51 ]: >>735
それは、ベテランの人間が小規模なプロジェクトをクリアする場合には当てはまる。
それ以上にはならない。
普通レベルの人間に真似させられないだけでなく、
高品質なプログラムにならない。
結果、顧客のダメだし確率も上がり、開発期間短縮にもならない。
リスクが高いので、趣味の範囲にとどめるべき手法だといえる。
737 名前：仕様書無しさん mailto:sage [2012/09/08(土) 17:56:39.57 ]: よく、アジャイルは、ウォーターフォールを細かく繰り返すことだと言うけれど、
その認識じゃー、うまくいかないに決まってる。

なぜなら、ウォーターフォールモデルの手順自体が真逆だから。
>>729が正しい順序なのである。

それで、アジャイルがうまくいかないと嘆くことになるんだが、
ウォーターフォールの根源的問題を繰り返したら、
もっとうまくいかなくなるのは当たり前。
738 名前：仕様書無しさん mailto:sage [2012/09/08(土) 18:38:52.54 ]: ボトムアップ的なやり方だけじゃダメじゃね
ボトムアップとトップダウンを混ぜたようなやり方のほうが
739 名前：仕様書無しさん [2012/09/08(土) 20:07:59.54 ]: 顧客←────┐
↓　　　　　　 │
マニュアル←─-┤
↓　　　　　　 │
結合テスト←─-┤
↓　　　　　　 │
単体テスト←─-┤
↓　　　　　　 │
コーディング─→┤
↓　　　　　　 │
詳細設計──→┤
↓　　　　　　 │
基本設計──→┤
↓　　　　　　 │
要求定義──→┘

トップダウンとボトムアップはそうなんだけど、
実際的な流れをより明確にするとこうなる。
テスト⇔コーディングが日常。
より大枠のところで、バージョンアップだ。
740 名前：仕様書無しさん mailto:sage [2012/09/08(土) 20:11:22.02 ]: >>739
試行錯誤が抜けてる。

全く同じ物のパラメータ違いを
作るなら話は別だけど、

プログラムで同じものは作らない
（自動生成すればいいから）

となると、ほとんどが新しいものであり、
試行錯誤しないと実現可能であるかもわからないものがある。
やってみて（コーディングしてみて）、この方法はダメだから
違う方法にするというのはよくある話。

そういう試行錯誤コーディングで
いちいちテストなんてやっても無駄。
741 名前：仕様書無しさん [2012/09/08(土) 20:29:03.63 ]: >>740
テスト⇔コーディングが試行錯誤だよ？
というか、試行錯誤のコーディングでテストをやらない？

なんて、嘆かわしい。
むしろ、そこはTDDを絶対オススメしたい。
742 名前：仕様書無しさん mailto:sage [2012/09/08(土) 20:47:43.94 ]: 基本的にはテストケース考えながら、作り込む方だな、俺は

底辺部分はテストケースはわりと考えなくてもいいんだけど
中間部分はテストケースを考えながらやるし、単体テストもやりやすい
上位部分は流してみないとわからないから、ラフに作って
全体流すときに徹底的につぶすほうかな

要求が一般的なわりと知られてるやり方が出来るのは
先に設計書作れってうるさいみたいだね
743 名前：仕様書無しさん mailto:sage [2012/09/08(土) 21:32:23.97 ]: >>742
「テストケース考えながら」って、リストをエクセルなんかで書きなぐりながらってこと？
実行しながらじゃなく？
744 名前：仕様書無しさん mailto:sage [2012/09/08(土) 21:43:20.95 ]: え、分岐のないやつしかやったことないの？
745 名前：仕様書無しさん [2012/09/08(土) 21:56:30.34 ]: テスト駆動の話なんだけど、テスト用プログラム、走らせてる？
慣れると楽だよ。ある程度使いまわせるし。
なにより、脳内シミュでは完璧だったのに、バグがはじき出される時ある。
焦るけどホッとする。
そして、性能テストも同時にやっちゃう。
劇的な速度増加手段がそこで発見できることもある。
絶対いい。

テスト用プログラムっていっても、うまく作る必要なんか全然なくてさ、
つーか、統合開発環境がすでにテストプログラムなわけだし、
誰でも無意識にやってるはずのものなんだよね。
それを意識的に、プロジェクトフォルダの中には必ずテストソース入れるフォルダも作る。
で、なれると、テストコードを先に作った方がいいことに気づく。

結合テスト←─-┤
↓　　　　　　 │
単体テスト←─-┤
↓　　　　　　 │
コーディング─→┤

結合テストから入るってのは、C言語なら最初main()作って動かす。
PHPならZAMPP入れて動かす。
ただ、それだけのもの。出力真っ白、それがバージョン0.01
それをやるべき。つーか誰でもやってる。当たり前の話。
746 名前：仕様書無しさん mailto:sage [2012/09/08(土) 22:08:12.21 ]: >>739 続き
どうして要求定義が一番最後なのか？
顧客ヒアリングの段階でまとめなければいけないのではないか？

もうね、アホかとバカかと。

例えば、「wordのドキュメントをそのままwebページにしてくれ」と
顧客が言ってくるとする。
はいはいと言って、見積もって基本設計やって

そして、・・・その要求が不可能なことに「途中で」気づくのだ！

もちろん、これはごく単純な例で最初の段階で無理だと断れるパターンだが、
実際問題、コーディングをちょっとやってみないと、
どんな要求が実際消化できるかわからない！（そして正確な見積も！）
そういうときは、正直に一巡するまで待ってもらう。
もしくはその顧客はあきらめ、次のために研究しておくべきだ。

それを、顧客即要求定義みたいに書くから、それが可能であると
勘違いされてしまう。これは深刻なミステイクだ。
後から顧客に怒鳴られ減額されるのは本当に嫌なものだ！
747 名前：仕様書無しさん mailto:sage [2012/09/08(土) 22:08:27.74 ]: > 当たり前の話
?
748 名前：仕様書無しさん [2012/09/08(土) 22:32:38.48 ]: 当たり前の話！
ウォーターフォール滅びろ！
みんな迷惑してる！
749 名前：仕様書無しさん mailto:sage [2012/09/08(土) 22:37:38.90 ]: その手の流れにもってくと、勘違いする人が出るような
当たり前だと思ってるだけで、実際にやってる人が...
750 名前：仕様書無しさん mailto:sage [2012/09/08(土) 22:43:31.84 ]: テスト書く為に早出、退行テストとベンチマークの為にサー残するならやっていいよ。つまり時間外でやれ
みたいなのだから一向に流行らん
それでもやるのが何人かいるのだけがまだ救いか
751 名前：仕様書無しさん mailto:sage [2012/09/08(土) 22:45:38.41 ]: 時間で働いてる人に効率化とか無いですから
752 名前：仕様書無しさん mailto:sage [2012/09/08(土) 22:50:00.81 ]: >>741
> テスト⇔コーディングが試行錯誤だよ？
> というか、試行錯誤のコーディングでテストをやらない？

やらない。テストの工数ってのをちゃんと意識していれば、
とてもやろうとは思わない。

試行錯誤ってのは、何度も仕様に修正が入るということ。
つまり、テストもそれだけ修正が入るということ。

テストがあればリグレッションを防げるが
試行錯誤中はリグレッションを防げない。
なぜなら仕様が変わるからテストが失敗するのがほとんど。
だからそんな状態では人間が流行ったほうが早い。
753 名前：仕様書無しさん mailto:sage [2012/09/08(土) 22:52:41.52 ]: 工数稼ぎのためにまともそうに書いてるだけですから
754 名前：仕様書無しさん mailto:sage [2012/09/08(土) 22:57:11.69 ]: 一生懸命やってますアピールしても土方の保身には全く役に立たないからね
755 名前：仕様書無しさん [2012/09/08(土) 23:04:23.41 ]: >>752
そこまでカオスな研究段階だったそうだろうか。
それでも、可能な限りテストプログラムの稼働、テスト環境の整備、
テストデータの自動生成など提案したいが・・・
テスト工数は多くなっても自動化すれば、トイレ行ってる間に終わるからな。
756 名前：仕様書無しさん mailto:sage [2012/09/08(土) 23:26:13.67 ]: > テスト工数は多くなっても自動化すれば、トイレ行ってる間に終わるからな。

どんだけ少ないんだ？

極端な例を出せば、網羅テストなんかやると
数年単位の時間がかかって現実的ではない。

必要ないテストを省くなどして、
どうやってテスト時間を短くするか考えなきゃならないのに。
757 名前：仕様書無しさん mailto:sage [2012/09/08(土) 23:30:14.81 ]: >>756
そこまでタイトな網羅テストが必要なプログラムかよ！
そんなの知らねーな、今は一般的な話しをしているのだ。
758 名前：仕様書無しさん mailto:sage [2012/09/08(土) 23:31:31.81 ]: テストがテストになっているかをテストするためのテストで今忙しい
759 名前：仕様書無しさん mailto:sage [2012/09/08(土) 23:36:16.58 ]: TDDのテストは品質保証が目的ではないいう流儀か
そういう類のテストを工数稼ぎと看做す場では受け入れられんだろうな
760 名前：仕様書無しさん mailto:sage [2012/09/08(土) 23:36:43.91 ]: 自己採点が基本でしょ、プログラム系は
受験みたいに点数つけてくれる人はいない
書いて終わりじゃないところが、紙の試験とは違う
761 名前：仕様書無しさん mailto:sage [2012/09/08(土) 23:41:28.27 ]: 自己採点でクビか契約更新かを決めれたらいいのにね
762 名前：仕様書無しさん mailto:sage [2012/09/08(土) 23:43:24.26 ]: > クビか契約更新か
それは、人が人を判断してるってことでしょ
763 名前：仕様書無しさん mailto:sage [2012/09/08(土) 23:58:01.12 ]: なぁんだ
なぁんだとはなんだ
なんだとはなんだとはなんだ
なんだとはなんだとはなんだとはなんだ
オペレーターズサイドもいっかいやってみようっと。あれ？マイクどこにしまったかなぁ・・・
764 名前：仕様書無しさん mailto:sage [2012/09/08(土) 23:59:02.33 ]: >>756
テストしたことないでしょ。
765 名前：仕様書無しさん mailto:sage [2012/09/09(日) 00:01:40.83 ]: 雇用側とかの認識がおかしいから、人集めるにしても、とんでもになってるとか
766 名前：仕様書無しさん mailto:sage [2012/09/09(日) 00:12:03.67 ]: >>764
テストしたことないでしょ？

スローテストって言葉知ってる？
テストが短時間で終わるためには、
短時間で終わるように工夫しなきゃいけないんだよ。

自動化すればすぐに終わる？
アホだな。

銀の弾丸はない。
767 名前：仕様書無しさん mailto:sage [2012/09/09(日) 00:16:03.48 ]: 自動化してもテストは際限なく増えていく。
増えていけば必ず時間がかかる。

自動テストに時間が掛かるって状況になっていないのなら
それはまだテストが少ない段階なんだなぁとしか思えない。
768 名前：仕様書無しさん mailto:sage [2012/09/09(日) 00:27:15.25 ]: やってる内容によっては、いくら自動化しようがダメ出し食らうだけじゃね
テスト自動化したら終わりってわけじゃないような
769 名前：仕様書名無しさん mailto:sage [2012/09/09(日) 02:15:34.13 ]: ウォーターフォール否定的なヤツが多いが、一時的に大量に人集めて、大規模システムを納期どおりに一定の完成させるにはウォーターフォールしかないのが現実。

小規模で最適な開発方式をそのまま大規模に適用させられると思ってるおバカさんが多すぎる。
770 名前：仕様書名無しさん mailto:sage [2012/09/09(日) 02:18:18.41 ]: プロマネにも言えるが小規模PJを幾つも上手く回すスキルと、大規模PJを完遂させる能力は質が違う。
771 名前：仕様書無しさん mailto:sage [2012/09/09(日) 02:30:21.49 ]: ちゃんとした体裁のドキュメントなんて完成に近づいてからやりゃいいけど、
ある程度決めないといけない内容を残す必要もあるから、そういう意味では先に造らないといけない部分はあるんだよなー
でも、ウォーターフォールはその残すためのものを最初から完璧に作ろうとしては
書き直して無駄な工数を裂くことがおおくて、その帳尻あわせにケツが縮まって燃える(´・ω・｀)
772 名前：仕様書無しさん mailto:sage [2012/09/09(日) 02:31:09.88 ]: まともなとこは、人海戦術的なことはやらんでしょ
773 名前：仕様書無しさん mailto:sage [2012/09/09(日) 02:32:32.61 ]: TDDはある程度コーディングの実力が伴わないと難しいと思うよ
試行錯誤して手探りしてるレベルの人だと、いきなり適切なテストケースを用意するのはかなり難しい
だって、はじめたばかりだったり知識が足りてない段階だと、
どういうテストを用意すればいいかわからないし、そもそも作るものがどういう実装になるかを想定できないからね

もちろん、要所を押さえれば知識が浅いうちでもそれなりにはできるようにはなるとは思うけれど
試行錯誤があまり必要ないくらいにすぐ目的のコーディングに入れるようになるまでは、いきなりテスト作成はきつい
自分も結構実装前段階でテスト準備はうまくやれないから、そういうのはなんとなくわかる

でも一通りやれる事や実装の見通しが実装に入らなくても想定できるようになってくると、
テスト作成から入るって意味もわかると思うけどなー

網羅テストのような(大して意味がないけどｗ)のがテストとして求められてるようなものなら、そういうわけには行かないけどさー
774 名前：仕様書無しさん mailto:sage [2012/09/09(日) 02:32:54.97 ]: 今の要求は、人がいれば出来るような簡単なもんじゃないと思うけどね
簡単なの探すほうが大変じゃね
775 名前：仕様書無しさん mailto:sage [2012/09/09(日) 02:34:31.80 ]: つかまずその大規模プロジェクトって物自体が否定されてるようなもんだからなｗ
頭とケツしか考えられないから、ウォーターフォールしか選択肢がない
仕様書とか設計書とかって、この無駄にピザってしまった縦割り開発の
伝言ゲームのためにあるようなもんだし、無駄だよやっぱ
776 名前：仕様書無しさん mailto:sage [2012/09/09(日) 02:38:21.62 ]: 新規じゃないのは、枯れてくれば、少人数になっていくような
777 名前：仕様書無しさん mailto:sage [2012/09/09(日) 02:53:54.52 ]: >>770
料理人とかでも同じだな、大規模宴会料理と小料理屋の料理じゃ全然違うと。
まあ、どの業種でも言えることだけどね。
778 名前：仕様書無しさん mailto:sage [2012/09/09(日) 02:59:07.84 ]: 料理系とかは下積み長い人達が割と集まる（める）から成り立つんだよ
人がいればこなせるほど、甘い世界じゃないだろ、歴史があるところは

味抜きでやってるとこは、先ないだろうね、料理系
779 名前：仕様書無しさん mailto:sage [2012/09/09(日) 03:05:01.39 ]: 好きこそ物の上手なれっつーか、興味をどれくらい持ってるかでのピンキリ差が激しいし、
実際の土方みたいに体動かしてりゃなんとかなるわけでもないから、数いりゃいいってもんでもないしな。
780 名前：仕様書無しさん mailto:sage [2012/09/09(日) 03:27:22.13 ]: > 実際の土方
やってる人に経験値高い人達がいるから、成り立ってんじゃねえの？
781 名前：仕様書無しさん mailto:sage [2012/09/09(日) 03:57:35.35 ]: >>778
> 人がいればこなせるほど、甘い世界じゃないだろ、歴史があるところは

そうでもない。
例えば皮むき。下ごしらえなんかは、時間がかかる上に
テクニックはそんなに必要ない。そういう所に人を入れれば
○人でできる量を増やすことが出来る。

うまく人を配置すれば、一流の料理人をたくさん集めなくても
同じ質で生産量を増やすことが出来る。

そして、現実問題に対応しないといけない。
現実問題というのは、団体さん100人が来た時に対応できないといけない。
できるかどうかではなく、要求が先にある。

機材を増やした所で生産量は増えない。
人を増やすことでしか対応できないこともある。
782 名前：仕様書無しさん mailto:sage [2012/09/09(日) 04:01:40.32 ]: どっかが、やれば出来るって言って素人に刺身切らせてましたのと同じ発想なのがお笑い
783 名前：仕様書無しさん mailto:sage [2012/09/09(日) 04:04:10.22 ]: >>781
逆読みすれば、
ど素人でも出来るようなことをやってる
っていってるような
784 名前：仕様書無しさん mailto:sage [2012/09/09(日) 04:04:18.37 ]: 素人と刺身を切るスペシャリストの
違いがわかってないの？

一流の料理は作れなくても
刺身を切るのはうまいって人もいるだろう。
785 名前：仕様書無しさん mailto:sage [2012/09/09(日) 04:09:37.97 ]: 料理自慢って言われてる人はいるだろうけど
自分からいう人は、あんまりいないんじゃね
786 名前：仕様書無しさん mailto:sage [2012/09/09(日) 04:14:56.89 ]: >>783
だれもど素人がやるなんて言ってないしｗ

えとさ、ある作業があっとして、
それを一つスキルが低い人でも出来るようにしたら
その分、生産量は上がるよね。

お前も、この考え方のその恩恵に預かってるはずだが？
例えば音声合成をするための技術はないが、
ライブラリがあれば、スキルが低くても音声合成ができる。
787 名前：仕様書無しさん mailto:sage [2012/09/09(日) 04:35:32.42 ]: >>786
その時点で開き直ってるような
ま、やらせる相手によるのかもしれんけど
788 名前：仕様書無しさん mailto:sage [2012/09/09(日) 04:41:04.15 ]: >>787
日本語でお願いします
789 名前：仕様書無しさん mailto:sage [2012/09/09(日) 04:43:07.15 ]: 一流でなければど素人って言うような人だからねぇ。

そいつにとっては、一流の野球選手じゃなければ
甲子園に行ったとしてもど素人なんっだろうねｗ
790 名前：仕様書無しさん mailto:sage [2012/09/09(日) 04:46:30.03 ]: そういう例え方しかできんの？
791 名前：仕様書無しさん mailto:sage [2012/09/09(日) 04:48:48.86 ]: 20年前のやり方が通用せん分野も出てきてるのにね
792 名前：仕様書無しさん mailto:sage [2012/09/09(日) 05:37:09.93 ]: >>766
そうか。
お自動化して数年かかるようなテストやってるんだろ？
自動化しなかったら、もっと時間がかかるだろw
793 名前：仕様書無しさん mailto:sage [2012/09/09(日) 06:06:09.63 ]: テストの実行にそんなに時間がかかるのだとしても、
それでもテストは繰り返すべき、だな。
基本、マシンスペックを上げる。放置プレイも重要。

そこまでの規模なら、テストの前にコンパイルで相当時間がかかるはず。
Googleはコンパイル時間が短い言語を独自開発してる。
Cでも満足できないらしい。
これはとどのつまり、テストの周期を短くするためだ。
場合によっては新言語開発さえ必要、ということ。
794 名前：仕様書無しさん mailto:sage [2012/09/09(日) 07:38:36.42 ]: 料理人どうののたとえ話じゃなくて、普通にマの話で説明すべきだろう
マ板住人が料理人の仕事の詳細を例えに使えるほど理解してるわけないだろう
余計ややこしくなるだけ
795 名前：仕様書無しさん mailto:sage [2012/09/09(日) 12:36:01.37 ]: >>793
> そこまでの規模なら、テストの前にコンパイルで相当時間がかかるはず。

ん？なんでテストの時間と
コンパイル時間が関係あると思ってんの？
796 名前：仕様書無しさん mailto:sage [2012/09/09(日) 12:59:17.63 ]: >>792
たとえば新しいOSが増えたら、テストがその分増えるわけ。
ウェブアプリだったら、テスト時間×ブラウザ数になるわけ。

自動化関係なく、テストは時間がかかるもの。
完璧なテストは数年かかるからやれない。
だから手抜きする。

自動化でそれが0になるわけじゃなく減らせるだけ。
自動化してもやっぱり手抜きは必要。
797 名前：仕様書無しさん mailto:sage [2012/09/09(日) 15:17:34.16 ]: >>796
君が「自動化＝テスト項目の削減をしない」って勝手に定義してるだけだろ。
798 名前：仕様書無しさん [2012/09/09(日) 16:26:27.82 ]: 自動化は時間の削減であって項目の削減ではないだろ
区別して考えろよ
799 名前：仕様書無しさん mailto:sage [2012/09/09(日) 16:28:24.71 ]: 日本語化したら、コンピュータが勝手に動いてくれると思ってるのかしら、かしら
テスト自動化したら、問題が減っていくと思いたいのかしら、かしら
800 名前：仕様書無しさん [2012/09/09(日) 16:52:44.47 ]: ランダムテストみたいに入力をランダムに振るテストを「自動化」とか呼んでそうだな
801 名前：仕様書無しさん mailto:sage [2012/09/09(日) 17:14:45.41 ]: CI
802 名前：仕様書無しさん mailto:sage [2012/09/09(日) 17:19:29.48 ]: 動かすより、テストすること考えて作るほうが難易度高いこともあるのにね
テストの自動化出来ましただけ言ってると誤解する人増えそう
803 名前：仕様書無しさん mailto:sage [2012/09/09(日) 19:05:42.06 ]: 全自動になる前の麻雀で初心者がハマる状況に似てるな、この業界
804 名前：仕様書無しさん mailto:sage [2012/09/09(日) 20:17:35.37 ]: 連チャンに耐えられる人達ってどんくらいいるんだろうね
805 名前：仕様書無しさん mailto:sage [2012/09/09(日) 21:34:54.77 ]: 曖昧な書き方して逃げ道作ってる奴ばっかｗ
806 名前：仕様書無しさん mailto:sage [2012/09/09(日) 21:36:21.09 ]: 保身に拘るのは最早職業病
807 名前：仕様書無しさん mailto:sage [2012/09/09(日) 21:44:46.40 ]: 書いたら、終わりじゃないのにね
808 名前：仕様書無しさん mailto:sage [2012/09/09(日) 22:32:58.63 ]: >>755
> テスト工数は多くなっても自動化すれば、トイレ行ってる間に終わるからな。

終わらねーよｗ
809 名前：仕様書無しさん mailto:sage [2012/09/09(日) 22:38:07.65 ]: テストを自動化したって、時間がかかるものはかかる。

make testをしたらわかるだろ？
810 名前：仕様書名無しさん mailto:sage [2012/09/09(日) 23:44:51.16 ]: 1.日本は新卒文化
2.経験不要、コミュ力重視で採用。
3.プログラムは下っ端の仕事

上記理由から、プログラマの大部分は
ド素人であることが昔からこの業界の常識。

ド素人集団でもシステムを作り上げられる唯一の開発手法がウォーターフォール。
811 名前：仕様書無しさん mailto:sage [2012/09/09(日) 23:53:34.93 ]: 自動化はJenkinsみたいなCIサーバー使ってコミットされたらビルド→自動テストを
裏で動かせるのが肝だろ。CIサーバー使わなくてもビルドスクリプト使って
ある程度の自動化が出来てないと恩恵は少ないわな。
812 名前：仕様書無しさん mailto:sage [2012/09/10(月) 00:13:41.27 ]: え、大規模でも統合環境じゃないの？
813 名前：仕様書無しさん mailto:sage [2012/09/10(月) 01:27:43.84 ]: >>811
うん、コミットする前に自動テストやったら
コミットするまで時間かかるから
自動テストは、コミットが終わった後でやるんだよねｗ
814 名前：仕様書無しさん mailto:sage [2012/09/10(月) 01:49:17.50 ]: >>813
普通に自分の環境でビルド通して、自分が書いた分の自動テストが通ったら
コミットするだろ。　

ただプログラム書いたやつなら分かるが、自分の環境だと問題なくても
他人が修正してコミットしたモジュールと合わせるとビルド環境やデプロイ
環境でビルドが通らなかったりテストが通らなかったりするから、要所要所
でビルドと自動テストをして早い段階でエラーを検知する仕組みにする。　

今はCIサーバーとかがあって、そういうのが自動で組み込める便利なツールが
あるからそれを使えるならそういうのを使えばいいだけ。

設計書だけしか書けない人はこういうツール類が昔に比べ遥かに便利で
高速化されてることを知らないのが多いね。　まあ、普通に開発してる
人間でもアンテナ張ってても引っかからないことが多いけどね。
815 名前：仕様書無しさん mailto:sage [2012/09/10(月) 07:08:33.88 ]: 設計書だけしか書けない奴ってホントつかえねーよな
使えなすぎてガンガン首切られてる
スキル0のゴミだから転職もできない
816 名前：仕様書無しさん mailto:sage [2012/09/10(月) 15:26:31.58 ]: 本日見つけた迷言

「フレームワークを使わないのがXXX(言語名)だ。」
「俺のOOPはフレームワークには負けない。」
817 名前：仕様書無しさん [2012/09/11(火) 09:48:33.01 ]: すべてのプロジェクトに当てはまる万能な開発手法はない。
しかし、脱ウォーターフォールは万人にオススメできる。
日常のツール作りから原発まで脱ウォーターフォールを真剣に考えるべきだ。
あなたが、ウォーターフォールでうまくいっていると思っているなら、
実際は、ウォーターフォールが実践されていないからだ。
818 名前：仕様書無しさん mailto:sage [2012/09/11(火) 10:46:38.85 ]: それは言えてる
819 名前：仕様書無しさん mailto:sage [2012/09/12(水) 06:48:45.39 ]: ウォーターフォールでも何でもいいけど、下流の馬鹿マが内部設計すら出来ないのは勘弁してくれ。
概要設計から製造までお前んとこで請け負ってるのに、何でもいちいち聞いてくんな!!
「こんな内部変更が必要になるなんて聞いてない。」って、外部インターフェースのプロトコル変更は真っ先に挙げてるし、その対応見積り出したのあんただろ。
しかも、「じゃあ、そのプロトコルのサンプルソースくれ。」とか、知らないで見積ったのかよ!!
100歩譲って知らなかったとしても、今まで何も調べてないのかよ!!
820 名前：仕様書無しさん [2012/09/12(水) 06:54:58.89 ]: 印刷設計書が書きにくいから計算結果もDBに書き込むようにしてほしいと言われた。
書きにくいから・・・・そこ書くのがてめぇらの仕事だろ。
821 名前：仕様書無しさん mailto:sage [2012/09/13(木) 00:39:01.05 ]: >>755
お前、それただのデバッグなんだが。
デバッグのことをテストって言ってね？ｗ
822 名前：仕様書無しさん mailto:sage [2012/09/13(木) 01:45:54.74 ]: 中抜きは下選べるだけマシじゃん
上は選べないんだぞ
823 名前：仕様書無しさん mailto:sage [2012/09/13(木) 01:50:06.87 ]: >>819
その程度の会社と知らないで契約したのかよ!!

>>821
えっ
824 名前：仕様書無しさん mailto:sage [2012/09/13(木) 06:53:32.86 ]: >>823
情報漏洩防止手続きとか、レートとかあって、選択肢無いんだよ!!
しかも、中のマはコロコロ変わるし、ハズレが多いんだよ!!
825 名前：仕様書無しさん mailto:sage [2012/09/13(木) 21:08:09.33 ]: たまに聞くコーディングやインフラまったくできない人の書く仕様書ってどんななんだろう
もう設計以前に、客の要望をそのまま横流しにして見栄えのする紙を作るくらいしか
やれることなさそうなんだが・・・
826 名前：仕様書無しさん mailto:sage [2012/09/14(金) 01:54:19.87 ]: >>824
ほんと、上も下も誰も幸せになれないお仕事だよなぁ…!!
827 名前：仕様書無しさん mailto:sage [2012/09/14(金) 04:18:00.46 ]: 負の連鎖を断ち切られると困る人達がいるからでしょ
828 名前：仕様書無しさん mailto:sage [2012/09/14(金) 06:42:22.85 ]: >>826
せめて、お国の仕事だけでもウォーターフォールで、設計審査してから製造って方式止めて欲しい。
某所の基準は30年以上前にMIL和訳して戦前からの基準に合わせただけで、以後ほとんど変わって無いぞ。
MILはウォーターフォールの失敗を認めて数年ごとに改訂を繰り返して、今はISOに移ったのに。
理系が多い某所でこれなんだから...
829 名前：仕様書無しさん mailto:sage [2012/09/14(金) 06:51:24.83 ]: 日本語の説明書読んで、設計審査とかバカじゃねえの？
日本語しか読めない人がこの手分野やってるんだ
830 名前：仕様書無しさん mailto:sage [2012/09/14(金) 14:04:12.64 ]: そこでドイツ軍採用のVモデルですよ。
831 名前：仕様書名無しさん mailto:sage [2012/09/15(土) 02:02:06.30 ]: うまくいったプロジェクトの最大公約数をとるとウォーターフォールという開発方式が経験則的に導きだされる。
その結果ウォーターフォール適用プロジェクトが多くなるが、開発方式だけで成功するわけじゃないから、失敗プロジェクト担当者にアンチが増える。それがおまいら。
832 名前：仕様書名無しさん mailto:sage [2012/09/15(土) 02:09:13.53 ]: >>828
お国の仕事は、プログラムが動くことよりも規則に則った手続きを踏むことの方が遥かに重視される。
まったく結果が伴わなくとも、定められたルール通りにやりさえすれば、官僚が成功のストーリーをでっち上げてくれる。
833 名前：仕様書無しさん mailto:sage [2012/09/15(土) 03:17:41.12 ]: そのうち晒し者なるところが出そうな話？
834 名前：仕様書無しさん mailto:sage [2012/09/15(土) 03:43:02.77 ]: > 経験則的
20年以上前に出来上がったもんのメンテかなんかしてるんか？
835 名前：仕様書名無しさん mailto:sage [2012/09/15(土) 14:02:34.94 ]: 日本だと経営者がシステム開発に興味無い老人だから、大規模PJともなると組織の中間管理職10人以上が会議室で顔つきあわせて、あーでもないこーでもないって自分の立場優先の意見しか言わない。アジャイルなんてしてたら仕様が決まる前に予算が尽きるわw

欧米だと外部から来たCEOがまず大規模リストラして、捻出した金(自分が使って良い金)で自分の気にいるシステム導入するからうまく行くわけで。
836 名前：仕様書無しさん mailto:sage [2012/09/15(土) 14:42:46.11 ]: >>835
> 欧米だと外部から来たCEOがまず大規模リストラして、捻出した金(自分が使って良い金)で自分の気にいるシステム導入するからうまく行くわけで。

その導入したシステムを作った会社の話をしてくれ。
837 名前：仕様書無しさん mailto:sage [2012/09/15(土) 14:46:43.87 ]: 上司は上司で部下潰しに余念が無い
838 名前：仕様書名無しさん mailto:sage [2012/09/15(土) 16:24:08.76 ]: 顧客内部での利害関係を解決しないままでも、なんとか落としどころを探して(同意したという証拠を残す)システムを成立させるのが、SIerの仕事。
イテレーションで、理想的な状態に近づけると考えるのは幻想でしかない。
関係者全員にとって理想的なシステムなんて存在しないことの方が多いから、やればやるほど迷走する。
839 名前：仕様書名無しさん mailto:sage [2012/09/15(土) 16:36:53.91 ]: アジャイルの実情を見てもまだやろうとする奴いるのか？
ssff.hateblo.jp/touch/entry/2012/06/12/230847
840 名前：仕様書無しさん mailto:sage [2012/09/15(土) 16:48:32.49 ]: ネゴシエーター
841 名前：仕様書無しさん mailto:sage [2012/09/15(土) 17:03:39.06 ]: えらくレイアウトぶっ壊れたサイトだな
842 名前：仕様書無しさん [2012/09/16(日) 08:26:57.84 ]: >>831
経験があって、たまたまで一気呵成でできたから、
それをすべてのプロジェクトで真似するのは違うよ。

ウォーターフォールというのは一息でやるってこと。
吐くだけで、吸わないわけで、
これはつまり、呼吸の手順が抜けてるってこと。

上手い歌手が、一息で長いフレーズを素晴らしく歌い上げたとする。
その素晴らしさを真似して、歌全体を一息で歌うのを目指すとか、狂ってるだろ？

そこには呼吸がないんだから、当然、酸欠で死亡することになる。
そういうアホで危険なことは今すぐやめるんだ。
843 名前：仕様書無しさん mailto:sage [2012/09/16(日) 08:38:01.44 ]: うちの会社ではコーディング仕様とか実装仕様の話になると
すげー嫌な空気がでるんだがうちだけ？
他はそうでもないの？
いやもうなんつーかほんとやだって感じ。
844 名前：仕様書無しさん mailto:sage [2012/09/16(日) 13:27:56.64 ]: コーディング仕様や実装仕様ってのがどういうのかがよくわからない

多くのところが、(名前なんかは違うと思うけど、)
だいたいこういう3段階+コーディング、みたいな事やってんじゃね

1. 要件定義　客の望むシステムを聞き出して仕様を起こすための情報を纏める
2. 基本設計、外部設計など　UIや使用方法的な、外から見える部分の仕様、環境の仕様など
3. 詳細設計、内部設計など　業務ロジック的な仕様

4. プログラム設計、というか実装
　頭の中でやる、もしくはソースコード自体をプログラム設計って呼んでいいと思う
　この名前のドキュメント起こすプロジェクトも稀にあるけど、中身は詳細設計とかのレベルのものだし

それとも、コーディング規約(コーディングルール)とかの話なのかな？
845 名前：仕様書無しさん mailto:sage [2012/09/16(日) 15:44:16.74 ]: >>843
そんな下流作業は外注に丸投げしとけって話だろ？
上司からは、そんな暇あるなら客の機嫌とって金巻き上げてこいって顔され、文系ゆとり部下からは泥臭い仕事はお断りって感じだろ？
846 名前：仕様書無しさん mailto:sage [2012/09/17(月) 08:06:53.09 ]: >>843
うちは嫌って感じではないが、あからさまに逃げられる。
要するにコードも書けないし、設計も出来ないから判断出来ないんだよね。
うちは、お国のソースを長年メンテするけど、元がムチャクチャだから基準作ってもどうしようもないし。
847 名前：仕様書無しさん [2012/09/21(金) 07:14:11.14 ]: 設計書の構成とかの標準が古くさすぎて困る。
標準ってだけだから融通きく筈なのに、頭硬い奴のせいで作業やりずれぇ。
848 名前：仕様書無しさん mailto:sage [2012/09/23(日) 12:20:02.92 ]: SIerの設計書はCOBOLがメインターゲットだからな。
一時期UMLを標準ドキュメントにしようとする流れもあったが、顧客も下請ソフトハウスが読めないから完全に廃れた
849 名前：仕様書無しさん [2012/09/23(日) 16:07:16.65 ]: UML読めるとこに仕事まわせばいいのに
850 名前：仕様書無しさん mailto:sage [2012/09/23(日) 16:58:38.42 ]: UML読めない客もお断り！
UML以外の設計書を納品する必要があるなら、見積り2倍で出します！キリッ
851 名前：仕様書無しさん [2012/09/23(日) 17:37:55.58 ]: 刑法第２４６条詐欺罪（十年以下の懲役)

虚偽のマージン率または派遣料金の明示により労働契約を締結する行為は詐欺罪の「人を欺いて財物を交付」にあたると見られる。

職業安定法第４４条の労働者供給事業の禁止規定違反

偽装請負、多重派遣と同様に、事前面接、履歴書の提出を行うと「派遣労働者を特定する行為」にあたり派遣会社の実態が労働者供給業と見なされるため、職業安定法第４４条の禁止規定違反となる。
罰則の適用には被害者による刑事告訴か関係諸局・内部関係者による刑事告発が必要となる。
・職業安定法第５章第六十四条、1年以下の懲役または100万円以下の罰金

処罰は派遣先、派遣元の両者に科される。職業紹介を行う紹介予定派遣では例外として事前面接が認められている。

労働基準法第１章第６条違反（中間搾取の禁止）

再派遣は労働基準法第６条の違反となる。罰則の適用には被害者による刑事告訴か関係諸局・内部関係者による刑事告発が必要となる。
・労働基準法第１３章第１１８条、1年以下の懲役又は50万円以下の罰金

両罰規定（労働基準法第１２１条）

労働基準法第１章第６条違反については両罰規定が設けられている。労働基準法第１２１条には

この法律の違反行為をした者が、当該事業の労働者に関する事項について、事業主のために行為した代理人、使用人その他の従業者である場合においては、事業主に対しても各本条の罰金刑を科する。

とあり、事業主（中間搾取行為をした事業者の経営担当者、労働者に関する事項について事業主の為に行為をするすべての者）と事業主の代理人についても処罰が科される。被害を受けた労働者は派遣先および派遣元の会社、従業員などに対して刑事告訴を行える。
852 名前：仕様書無しさん [2012/09/23(日) 18:22:46.39 ]: ＞　UML読めるとこに仕事まわせばいいのに

UMLとプログラムは相性が悪いんだ。
UML読める奴に限ってプログラムが作れない。
もし作ってもむちゃくちゃで何やりたんだかわからない。

UMLでは大事な情報が抜け落ちてしまうから、
同じ仕事を５年も１０年もやるような大企業ならいいけど。
それ以外では使い物にならないんだ。

UMLがいいと言ってる奴に限ってぐちゃぐちゃの
ソースコードを書くのは、いまとなっては誰でも知ってることだ。
853 名前：仕様書無しさん mailto:sage [2012/09/23(日) 18:32:50.96 ]: UMLで書けるような仕様なんて、大した仕様じゃないんだよ
それが何のためのシステムなのかを知っていれば、
誰でも類推できてしまう程度のことしか書けない
854 名前：仕様書無しさん mailto:sage [2012/09/23(日) 19:26:03.90 ]: 勤勉な無能が一番厄介なのは知ってるだろ？
そういう無能にはUMLという名の落書きを書かせて
プログラマの仕事の邪魔をさせないようにするんだ
もちろん落書きだから後で使わない
855 名前：仕様書無しさん mailto:sage [2012/09/23(日) 21:49:40.04 ]: UML読めないって、フローチャート読めないレベルじゃね？
856 名前：仕様書無しさん mailto:sage [2012/09/23(日) 21:54:41.67 ]: UML、フローチャート読み書きできるのと、コード読み書きできるかは別なんだよ
857 名前：仕様書無しさん mailto:sage [2012/09/23(日) 22:02:22.62 ]: フローチャート読めないほど頭が弱い奴に、
まともなコードを期待するのは間違ってる。
858 名前：仕様書無しさん mailto:sage [2012/09/23(日) 22:37:13.28 ]: 両方求めるほうがおかしいの
高学歴パー系がそういう無茶なこと要求するからね
859 名前：仕様書無しさん [2012/09/24(月) 00:52:28.63 ]: UMLはwordで書けないから使えない
860 名前：仕様書無しさん mailto:sage [2012/09/24(月) 01:51:21.29 ]: 全部できる奴以外死ねって事だろ
861 名前：仕様書無しさん mailto:sage [2012/09/24(月) 03:17:05.67 ]: 読めないからダメって言ってる人はさすがにアレだと思うわ
別にUMLを使いたいとは思わんけど、簡単だからかじるくらいには覚えたよ
読めないと困るときもあるし

つか、UMLの仕様すら頭に入らない人が、まともなコーディングできるわけないっしょ
862 名前：仕様書無しさん [2012/09/24(月) 06:51:03.86 ]: UMLだから、駄目/完璧ってのは無いよな。
使える図は使う、要らない図は使わない。
まぁ、要らないけど要求されるから、無駄と判っていても作るってのは多いけど。
863 名前：仕様書無しさん [2012/09/24(月) 07:06:13.13 ]: しかし、最近のマってデータ定義疎かにする奴増えた気がする。
どんな言語でも開発手法でも、データ定義決まらなきゃ内部設計出来ないだろ。
むしろデータ定義さえ正しく出来れば、よほど特殊な処理以外はイメージ出来るもの。
データも固めずに内部処理が判らん、って何言ってんだこいつ？
864 名前：仕様書無しさん mailto:sage [2012/09/24(月) 10:17:18.98 ]: ドメインモデルはニホンザルには無理か
865 名前：仕様書無しさん mailto:sage [2012/09/24(月) 12:22:37.54 ]: > どんな言語でも開発手法でも、データ定義決まらなきゃ内部設計出来ないだろ。
> むしろデータ定義さえ正しく出来れば、よほど特殊な処理以外はイメージ出来るもの。
そんなのは、ごく一部の領域だけ。
866 名前：仕様書無しさん mailto:sage [2012/09/24(月) 15:51:45.19 ]: 元々、帳票系ベースだから、分野によっては使える使えない（ところ）があるのに
867 名前：仕様書無しさん mailto:sage [2012/09/24(月) 23:59:55.41 ]: まー閉じた世界にいると、その中で優劣考えるようになって
「あれ、俺できる奴じゃね？」って思っちゃったりすることは、誰にでもあることだしね
868 名前：仕様書無しさん [2012/09/25(火) 06:31:59.18 ]: >>867
おれにすらあることだな
869 名前：仕様書無しさん [2012/09/28(金) 00:12:11.73 ]: 結局EXCEL方眼紙最強ってことだね
870 名前：仕様書無しさん mailto:sage [2012/09/29(土) 01:18:33.33 ]: いいえ
最狂のうんこ
871 名前：仕様書無しさん mailto:sage [2012/09/29(土) 01:59:41.94 ]: レビューの時に新たな仕様書の存在を聞かされた
あるあるwww
ワロタwww

ワロタ・・・
872 名前：仕様書無しさん [2012/09/30(日) 09:02:46.71 ]: 「設計書」と「テストスクリプト」を一体化したいと漠然と思ってるんだが、何か問題ある？
最近はレビューばっかで自分で書かないからそこまで具体的に考えてる訳じゃないんだけど、

見てると「テストスクリプト」が「設計書」からのコピペと化していて
同じことを二度やっているようにか思えない

書いてある内容は、

＜設計書＞
これをやったら　→　こうなる

＜テストスクリプト＞
これをやったら　→　こうなる　＋　必要なエビデンス　＋　OK/NG欄

の違いでしかない

「設計書」はWordで、何となく章立てや起承転結があるかのような装いをしていて
「テストスクリプト」はExcelで、表と言うか箇条書きと言うか、項目が１意に識別しやすい
というくらいの違いしかない
873 名前：仕様書無しさん mailto:sage [2012/09/30(日) 12:47:48.39 ]: うちは設計書の右にチェック欄つけて、それをテスト仕様書として提出することにしてる
仕様に書ききれてない処理については別項目のテスト作る感じで

テストコードなんて誰も作ってないまま数年経過したアレプロジェクトだから、こうするしかないってのもある
874 名前：仕様書無しさん mailto:sage [2012/09/30(日) 12:49:20.91 ]: あ、うんこExcel仕様書なので、一処理が一セルにかかれてるみたいなやつね
改定と仕様変更でちゃんとあってるかはだいぶ怪しくなってるけど、
ドキュメントはそれしかないからテストはそれでやってる感じ
875 名前：仕様書無しさん [2012/09/30(日) 16:09:26.66 ]: ありがとう

出来はともかく、方法としてはそれでいいように思うんだよな
10年前はプログラム作るだけでよかったんだが、
業界の規制が厳しくなってきたのと、会社もISO9001取ったりで文書類作るようになって、
ノウハウの蓄積のない分野を力技でやってる感じで、無駄に時間ばかりくってるんだよね

いつか初めてのところに外注で出したときに
失敗させる訳にいかんかったので考えられる全分岐を書き出してURSを作ったことがあって
（要するにベンダーには何も考えてもらうことを期待しない）、
そんときも、それがそのまま設計になると同時にテストパターンになるなと思った
876 名前：仕様書無しさん mailto:sage [2012/09/30(日) 18:40:18.43 ]: ISOで設計書の標準規格作ってくれよ
プロジェクト毎に設計書フォーマットが違う、取引先の気分や社内ルール次第で納品書式が変わるのはおかしいだろ。
877 名前：仕様書無しさん mailto:sage [2012/09/30(日) 19:11:36.45 ]: >>876
UML

すべての仕様を書き切れるなら神
878 名前：仕様書無しさん [2012/09/30(日) 23:19:04.83 ]: UMLでUIはどこに書くんだっけ？
879 名前：仕様書無しさん mailto:sage [2012/09/30(日) 23:25:46.46 ]: ゆ、ユースケース図
880 名前：仕様書無しさん mailto:sage [2012/10/02(火) 00:44:26.80 ]: ぶっちゃけUI周りはドキュメントに起こす意味のないものも多いけどな
そんなのしこしこ用意するより動くもの、モックなんかをドキュメントの変わりに使ったほうがいい
結局何か居ても客は理解しないから、触ってからはじめて違うっていい始めるわけだし
881 名前：仕様書無しさん mailto:sage [2012/10/02(火) 00:48:11.09 ]: 結局何か居ても
→結局何書いても

そういや、ダンボールとか切り貼りして工作でWebUIのモックつくるようなの
前にどっかの企業の勉強会かなんかの記事でみたなｗ

>>876
変化についていけない層がへばりついてる会社が多いから、規格が定まっても難しそうな気がするけどなー
あると嬉しいけれど
882 名前：仕様書無しさん mailto:sage [2012/10/02(火) 09:01:30.61 ]: 変化を制御しようって考えのない会社はおおいよな。
変化を抑圧しようって会社はおおいけどｗ
883 名前：仕様書無しさん mailto:sage [2012/10/02(火) 17:26:16.50 ]: >>879
どうしても、ユースケ・サンタマリアを思い出す。
884 名前：仕様書無しさん mailto:sage [2012/10/03(水) 02:10:46.19 ]: サタンマリアを思い出す
885 名前：仕様書無しさん mailto:sage [2012/10/06(土) 19:29:18.82 ]: UMLがいまいち普及しないのは、保守的云々以前に
単純にExcel方眼紙と対等に戦える糞だからじゃね？
886 名前：仕様書無しさん mailto:sage [2012/10/07(日) 01:52:17.45 ]: UMLで設計したら時間も労力も余分に必要だからだよ。
細部の設計も表現しづらいし。
887 名前：仕様書無しさん mailto:sage [2012/10/07(日) 02:28:43.71 ]: UMLはモデリング言語の名前の通り、
設計したものを、UMLで記述するという風に使うものであって、
UMLで設計するという言い方はおかしいぞ。
888 名前：仕様書無しさん mailto:sage [2012/10/07(日) 04:14:36.37 ]: 単純に、UMLだけで設計書が完結するわけじゃないからな。
ある程度書き方に自由度があるから、伝えやすいというのと誤解させやすいと
いうのがあるから、結局のところ短納期で毎回違う人とやり取りするには精度の
問題が今までと変わらんから。

実装側に厳密にするとコード書くのと変わらないし、設計側に厳密にすると
実装に支障をきたすし、学習しなければならないというところまできてないよな。

フローチャートレベルで授業のカリキュラムや情報処理技術者試験みたいな
公的な資格試験に組み込まれてれば違ってくるんだろうけどね。
889 名前：仕様書無しさん [2012/10/07(日) 11:16:50.29 ]: >>887
じゃあどうやって設計すんだよ
論理的じゃない設計してそうだな～～お前
890 名前：仕様書無しさん mailto:sage [2012/10/07(日) 13:52:56.45 ]: UMLで論理的な設計wwww
891 名前：仕様書無しさん [2012/10/07(日) 14:58:29.08 ]: UMLはお客さんも理解できる（ﾄﾞﾔｧ
とか書いてあった時期あったけどそんな奴居た事無いよな
国のエロい人が色々決めてたけどあんなの揃えてたら金いくらあっても足らんし
892 名前：仕様書無しさん mailto:sage [2012/10/07(日) 17:18:57.20 ]: そもそも、ちゃんとした設計とか学んだことなくてニュアンスでやってるひとは多いと思うわー
893 名前：仕様書無しさん [2012/10/07(日) 18:10:41.62 ]: Excelで結合セルを駆使して設計する方法は完璧に学習した。
894 名前：仕様書無しさん mailto:sage [2012/10/07(日) 18:16:43.07 ]: 途中から別のプロジェクトに入ってまず困るのは、全体を概観できる資料がないこと。
よくあるのが、全体構成図では、「営業サーバ」、「総務サーバ」とか書いてあるのに、
設計資料ではいきなり、「○○（パッケージソフト名）サーバ#1」とかになってて、
「○○#1」と「営業サーバ」の対応は、設定やってる運用グループに聞かないとわからないとか。
895 名前：仕様書無しさん mailto:sage [2012/10/08(月) 01:35:51.59 ]: UMLってIT業界において、この十年間で最も衰退した技術だよな。
フレームワークや開発手法が成熟するのが早かったから、大部分が実際の開発には不要になってしまった。
本当にドキュメントが必要な部分は、UMLで記述しきれないような複雑な仕様やシステム外の業務的な背景。
896 名前：仕様書無しさん mailto:sage [2012/10/08(月) 01:40:26.22 ]: いや、普通に書籍等に書いてある図は
UMLなんだが・・・
897 名前：仕様書無しさん mailto:sage [2012/10/08(月) 02:06:38.91 ]: フレームワークもなぁ。
要件やメカニズムのどの部分が、どのフレームワークのどの機能で実現されてるのかが
分かる資料がつくられてなかったりすると悲惨。
DI多用してたりして、末端のPGのコードとDIしたコードがバッティングしてたりすると、
PGには原因がわからない(開発用と顧客用で切り替えとかをやってたりすると最悪）
それでもそのあたりを設計したアーキテクトがプロジェクトに残ってれば聞けばわかるが、
基本設計行程が終わったら別のプロジェクトに移るなんてやりかたしてたら、
プロジェクト内に問題解決できる人がいない（または解析しないとわからない）
状態になる。
898 名前：仕様書無しさん mailto:sage [2012/10/08(月) 08:03:32.57 ]: >>895がフレームワークべったりな開発だけしか経験してないんだなとしか。
899 名前：仕様書無しさん mailto:sage [2012/10/08(月) 11:14:39.30 ]: フレームワーク作る側がUMLを書いてると思ってるのかな？ww
あんなのドカタ専用ツールだと見なして無視してるけどね
900 名前：仕様書無しさん mailto:sage [2012/10/08(月) 11:58:23.35 ]: とりあえず、本当にフレームワーク・・・というか、
その種のプロジェクトの中心人物は、社交的で、
不用意に他人をけなしたりしないけどね。
901 名前：仕様書無しさん mailto:sage [2012/10/08(月) 12:04:37.02 ]: 社交的で人当たり良くても、内心で「こいつらアホだな～、猿か？」と思ってます
902 名前：仕様書無しさん mailto:sage [2012/10/08(月) 12:11:50.57 ]: いや、おまえにとってそう見える相手はフレームワーク製作者に限らないだろ。
903 名前：仕様書無しさん mailto:sage [2012/10/08(月) 12:19:55.89 ]: アホに生まれた子って可哀想。
ただでさえアホだと馬鹿にされてるのに、
死ぬ程働いても給料1000万にも届かないし。
ほんと同じ立場に立ったら自殺するわ。
904 名前：仕様書無しさん mailto:sage [2012/10/08(月) 19:52:14.70 ]: >>896
だいたい書籍書いてる奴なんて実際の大規開発現場知らない奴ばかりだろ
UMLだけで書くのに都合の悪い例を排除してるというか…そもそも実務経験がなさ過ぎて想像もできないんじゃないか？
905 名前：仕様書無しさん mailto:sage [2012/10/08(月) 20:06:20.83 ]: UML知らない奴ほど、全部UMLで書こうとする。
906 名前：仕様書無しさん mailto:sage [2012/10/08(月) 23:54:32.38 ]: ユースケース図は粒度の決め方がアナログ過ぎ、ロバスト図はある程度以上の複雑さを表現しようとすると、2次元じゃ無理ゲー。
907 名前：仕様書無しさん mailto:sage [2012/10/09(火) 00:02:11.70 ]: ユースケース図の仕様に粒度は定められてない。
どう決めるかは使う側の問題。
ロバストネス図はそもそも、不必要な複雑さを省くために考えられたもので、
本当に複雑なものをわざわざモデリングしようとするのは本末転倒。
というか、批判するなら、規格書とか、発案者の書いた本ちゃんと読めよ。
908 名前：仕様書無しさん mailto:sage [2012/10/09(火) 02:15:14.11 ]: UMLがない時代でもそれなりに設計なんかしてたんだし、特に必要という訳ではないかもしれんが、
あればより良いものだけど、要る派の言ってる事も要らない派の言ってる事も極端だよ。
909 名前：仕様書無しさん mailto:sage [2012/10/09(火) 03:24:36.52 ]: まて、ここ最近のレスで要る派なんていたか？
910 名前：仕様書無しさん mailto:sage [2012/10/09(火) 03:31:45.51 ]: 極端なのは、要る派と要らない派しかいない前提の　>>908
の言ってることじゃね？
911 名前：仕様書無しさん mailto:sage [2012/10/09(火) 03:32:44.01 ]: 利用価値0じゃないという意見はあったけど、
アンチからみるとちょっとでも使ってる人は要るよ派に見えてると思ってる
敵を作って戦わわないと気がすまない的な
912 名前：仕様書無しさん mailto:sage [2012/10/09(火) 10:09:17.74 ]: じゃぁUMLの代わりに何つかう？っていう話になると、
結局UMLが無難ってことになる。
913 名前：仕様書無しさん [2012/10/09(火) 10:19:01.02 ]: Excelのセルをちまちま埋めて仕様書を書いていく快感はUMLごときでは得られはせぬ。
914 名前：仕様書無しさん mailto:sage [2012/10/09(火) 12:34:17.78 ]: それは仕様書だね。設計書とは違う。
915 名前：仕様書無しさん mailto:sage [2012/10/09(火) 20:20:14.25 ]: UMLがどうのとかはぶっちゃけどうでもいいよ。求められれば使うだけ
だがな、ドキュメントとして文章めいたこと書くのにExcel使うのはいい加減やめにしてもらいたい
二度と修正を入れない使い捨てなら構わんが、保守を考えたらExcelドキュメントなんてうんこよりひどい
916 名前：仕様書無しさん mailto:sage [2012/10/09(火) 21:19:43.34 ]: ワードで書くよ～って言ったら嫌な顔するくせに
917 名前：仕様書無しさん [2012/10/09(火) 22:27:10.85 ]: まともに変更履歴も残さないUMLは使い物にならない

設計書で重要なのは変更履歴と変更理由
現状はソース見れば誰でもわかる
918 名前：仕様書無しさん mailto:sage [2012/10/09(火) 23:41:24.45 ]: それはバージョン管理システムの仕事だろ。
UMLでも、変更ごとにコミットしてコメントちゃんと入れれば無問題。
バージョン管理システム使わずにコメントだけで変更履歴残そうとして
しっちゃかめっちゃかになったソースだと、ろくに流れも追えなくなる。
919 名前：仕様書無しさん mailto:sage [2012/10/10(水) 07:15:32.32 ]: たとえバージョン管理システム使ってても
diff取れないバイナリで書いてりゃ威力半減
920 名前：仕様書無しさん mailto:sage [2012/10/10(水) 07:40:25.34 ]: そのあたりは使うツールによりけりだが・・・
とりあえず、diff が取れる代替え手段ってなんかあるの？
921 名前：仕様書無しさん mailto:sage [2012/10/10(水) 07:42:02.80 ]: diff とか言い出すと、 word や Excel より TeX だよな。
922 名前：仕様書無しさん mailto:sage [2012/10/10(水) 17:36:08.65 ]: TeXだと冗長になるし、なんかそれ用のエンジン使うのが賢いんだろうな。本当は。
923 名前：仕様書無しさん [2012/10/10(水) 20:40:25.74 ]: >>920

エクセルに1文1セルで書いて、隣の列に
1列1バージョンで改変有無と理由を記載

フィルタを使えば瞬時に差分が見られる
924 名前：仕様書無しさん mailto:sage [2012/10/10(水) 20:54:09.99 ]: >>923
それで事足りる案件なら、自分だって Diff もバージョン管理システムも、
UML も使わないよ。
925 名前：仕様書無しさん mailto:sage [2012/10/10(水) 23:46:17.39 ]: そういうのは大抵が打ち消し線だらけだったりカラフルだったりになるから
いろいろ糞だけどね
場当たり対応をコード以外でも多用してるだけだし
926 名前：仕様書無しさん mailto:sage [2012/10/11(木) 06:43:08.22 ]: 技術文章としての体裁を要求されたり、図表使ったら終わるだろ、それ。
927 名前：仕様書無しさん [2012/10/13(土) 13:18:12.48 ]: 上流工程の資料の作成が凄いネックになってる気がしてならない。
開発者の視点で厳密に書くと「こんなんじゃユーザがわからん」といってハネられる。
ユーザにわかるように書くと表現があいまいになって、開発者には意味不明になる。
この矛盾に悩みつつ、ダメだしを回避する資料を完成させるのに絶望的に時間がかかって、
プロジェクトの予備工数がほとんど消える。
最後にはタイムオーバでダメ出しする人間が折れることになるが、
なんだかんだで、ユーザにも開発者にも3割方意味不明な資料ができあがる。
この3割方意味不明な資料を使って予備工数がない状態で開発がスタートする・・・。
928 名前：仕様書無しさん mailto:sage [2012/10/13(土) 15:51:58.47 ]: ユーザー用と開発者用それぞれ別のドキュメント作ればいいだけでは？
むしろ作るべきでは？
929 名前：仕様書無しさん mailto:sage [2012/10/13(土) 16:10:43.54 ]: まず、そのための工数がとられてるプロジェクトをみたことがない。
あと、開発スタート後に鬼のように湧いてくる仕様変更を、
二重化したドキュメントに反映してメンテナンスしていくコストも大変。
930 名前：仕様書無しさん mailto:sage [2012/10/14(日) 17:30:47.51 ]: dfdとer(テーブルと多重度のみでOK。カラムは主キーのみでいい)意外不要。
931 名前：仕様書無しさん mailto:sage [2012/10/14(日) 17:43:10.49 ]: 一人で作る程度のシステムで、クライアントがそれで納得してくれて、
その後の運用メンテも同じ担当者が続ける前提なら、それでなんとかなるかもしれん。
932 名前：仕様書無しさん mailto:sage [2012/10/15(月) 02:52:27.14 ]: 成果物が糞じゃない前提なら、ドキュメントの必要性は減ると思うよ

webとかだったら画面遷移とかあると理解度は上がると思うけど、
マニュアルと動くものがあれば事足りるからなくてもいい

クラス図があると関連は理解しやすいけど
名前やパッケージ、IDEの機能で追っかけるのは簡単だからなくてもいい

まぁ作成や保守にかかるコストと教育にかけるコストと、教育対象者の質次第だな
劣悪なのはドキュメントがいくらあっても結局理解しないし、
できる奴は(ちゃんとしたシステムであれば)その場にあるので難なくこなせると思う
933 名前：仕様書無しさん mailto:sage [2012/10/15(月) 12:49:11.89 ]: 技術的なドキュメントとして重要なのは基本設計と運用設計のほうだと思う。
基本設計資料がちゃんとしていれば、詳細設計は無くてもなんとかなる。
でも今、実際は、基本設計、運用設計、詳細設計で、ドキュメント量の比率としては、2:1:7 ぐらいじゃないか。
自分は、6:3:1 ぐらいでもいいと思う。
934 名前：仕様書無しさん mailto:sage [2012/10/15(月) 15:22:41.07 ]: 詳細設計書 = ソースコードだからねぇ。
本当の必要な量で言えば、一番多い。
だけど、ソースコードを補足するものだけに
すれば、逆に少なくなる。

詳細設計の量が多いところは
ソースコードが詳細設計書だって
わかってない。

[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

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