仕様書、設計書についてat PROG
仕様書、設計書について - 暇つぶし2ch150:仕様書無しさん
12/01/06 20:31:44.49
作る物も教えずに設計図出せってw
マジシャンじゃないんだからw

151:仕様書名無しさん
12/01/06 20:44:29.53
画面設計書とかある程度の叩き台先に作って見せないと打ち合わせが進まない。
要件がよく分からないからって設計書作らずに打ち合わせ行ったら、何も用意せずやって来て無駄な時間取らせるんじゃないと、一蹴されるよ。

152:仕様書無しさん
12/01/06 20:51:37.53
それは設計じゃなく要件定義だろ

153:仕様書無しさん
12/01/06 21:17:18.58
>>151,152

See >>142

154:仕様書無しさん
12/01/06 22:06:44.06
>>153
だから、要求を洗い出して、客に提案して、合意をとった上で始めて設計が固まるだろ。
その安価は何が言いたいんだ?

155:仕様書名無しさん
12/01/06 22:07:24.61
要件定義で画面レイアウト決めるのは要件定義ですか?

156:仕様書無しさん
12/01/06 22:07:36.12
>>151
あとそれ、サンプルと提案書な

157:仕様書無しさん
12/01/06 22:11:34.32
外部設計と内部設計の話を混ぜるな

158:仕様書無しさん
12/01/06 22:54:36.05
画面仕様を設計だと言い張るSEがいたなぁ。
自分が設計までしたんだから、あとはPGの仕事だと。

159:仕様書無しさん
12/01/06 23:47:00.77
今できる最適解は、
プロジェクトやメンバの性質にマッチした仕様書・設計書を適切なタイミングで作成すること。
これに尽きる。
必要な成果物は常に考えながらプロジェクト遂行しなければならない。
成功プロジェクトや経験だけに頼ったやり方はダメ。怠るとデスマ確定。

嫌なら法整備して厳格にすべき。この産業はいつになったら法整備されんだよ。


160:仕様書無しさん
12/01/06 23:51:47.90
合意をとった上で始めて設計が固まる と思ってるなら、まだ青臭いな。
合意はその時点での合意でしかない。

161:仕様書無しさん
12/01/07 00:20:57.53
>>99
サラリーマン思考で乙としか言えないな。

>WindowsとかOracleとかそんなのは難しいだけで工数はそんなに必要ない。
あんた業務システムしか経験したことないでしょ?
知らない分野のことは安易に言い切るなよ。
一般に高難易度のものは工数積むだろ。



162:仕様書無しさん
12/01/07 00:53:57.55
>>160
いや、そうあるべきって話しであって、必ずそうでなければならないとは言っていない。
設計と要件定義をごっちゃにしてる奴がいたから言っただけ。
会社にとって総合的に利益のほうが上回る事が見込まれるのであれば、カチカチの行程なんてたどる必要はない。

163:仕様書無しさん
12/01/07 02:37:44.26
顧客要求事項が曖昧なまま設計しても、すぐに行き詰まって、手戻りが起こる。
コストばかり費やして成果物は完成しない。
予算も納期も限られてるのだから、ある程度踏ん切りつけさせろ。
機能を諦めさせるか次の開発に乗っけさせて貰うとか交渉が必要。

164:仕様書無しさん
12/01/07 02:47:34.20
>>159
法整備って、何を定めるんだよw

165:仕様書無しさん
12/01/07 03:00:02.21
>>163
結局、金ある所からなーなーで仕事もらうのが一番無難に儲かるという。

166:仕様書無しさん
12/01/07 06:57:07.49
>>159
>プロジェクトやメンバの性質にマッチした仕様書・設計書を適切なタイミングで作成すること。

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

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

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

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

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

>怠るとデスマ確定。

なんだろねw

167:仕様書無しさん
12/01/07 08:06:00.21
デスマするかしないかはドキュメントで決まるだろ
デスマで食ってるやつはドキュメントをわざと書かせないから、分かるよドキュメントなくて作業なんか進まないところにザコを沢山投入して上まえハネテ儲ける
そうゆうヤクザなやり方してんだよ



168:仕様書無しさん
12/01/07 10:55:22.07
>>162
カチカチの行程のほうが開発会社の利益になるんだ
臨機応変に効率的に要件を満たすソフトを作ってしまったら
工数も次フェーズの仕事も減ってしまう

169:仕様書無しさん
12/01/07 11:23:10.97
結局実現可否まで判断しきれないと、ちゃんとした設計はできないし、手戻りも増えるから、
設計担当でも最低限のコーディング知識くらいは必要だよなホンと。
無能なSEやSIが上流に居座ってると、いいことがまったくない。

170:仕様書無しさん
12/01/07 11:28:21.52
デスマに必要な要素っていうと

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

こういうのがあるんじゃないかなと思うけど、
考えてみたらうちの職場は上3つが全部当てはまってる素敵なところだった
そんな状況で工数が不足し、新人投入しはじめたから4番目のもヒットしそうな勢い
やったね!

171:仕様書無しさん
12/01/07 11:33:07.84
>>168
あー…書き方わるかったかな。
カチカチのほうが確実な見込みが取れるから安全だけど、わがままな客やあまり頭の良くない客だとしても、利益が見込まれるなら受けるって話。

172:仕様書無しさん
12/01/07 11:33:15.22
デスマってるところは、大概何も考えずに
行き当たりばったりでコーディングしてる。

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

簡単に作れるというのも考えものだよ。
何も考えずに動いてしまうってことだから。
でへんなやり方になっていって、デスマに陥る。

173:仕様書無しさん
12/01/07 11:35:48.66
本来は設計レベルを担当する人が
フレームワークの正しい使い方、ベストプラクティスを調べて
それを下っ端のプログラマに伝えるべき。

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

で下っ端は管理されてない状況で好きかってやって
デスマを引き起こす。

174:仕様書無しさん
12/01/07 11:49:32.69
昔みたいに要件や仕様をしっかりまとめてから開発するというやり方は変化が激しい今は
通用しなくなってる。だから、素早い開発が重要。そのためには拡張性と柔軟性を
備えたシステム基盤を作れないといけない。

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

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

ここまでの説明でわかったとおり、要件とか仕様とかそういう話よりも
今は基盤の実装技術が極めて重要なんだ。そこができてればあとはどうとでもなる。
(正確には、どうとでもなるようなぐらいに基盤を作り込んでおく)
デスマを起こすところは作りたいものだけを考えて、基盤のことを一切考えていない。

175:仕様書無しさん
12/01/07 11:52:16.58
>>171
おまえは何回後付けしてんだよ。
現場にたまにいるわ。
そういう意味じゃないとか言いながら、ジワジワと意味を変えるやつ。
確固たる主張がないなら折れろよ。

言い逃れ野郎は、ひとつ否定されると全人格を否定されてるんじゃないかと思い込むからな。素直に認めろよ。
間違ったことだったとしても認めたらその場だけの馬鹿認定で済むんだぞ?


176:仕様書無しさん
12/01/07 12:03:40.41
>>174
君の考える基盤って、いわゆるフレームワークに限定してないか?
基盤というともっと低レベルだったり、ハードウェア選、インフラ系を含んだりする。



177:仕様書無しさん
12/01/07 12:17:26.68
>>174
変化が早いから素早い開発が要件されてるわけじゃなくて、
金がないから開発期間を短く設定するしかないんだよ。
本来は、3年5年かける規模をわずか半年で開発しているのが現状。
単にゴールを決めて開発してるに過ぎないんだよ。
だから、出荷後や運用開始後に『保守という名目や、改善という名目でバグ修正』

システム開発の世界では、スカイツリー完成に与えられる期間は半年である。

178:仕様書無しさん
12/01/07 12:29:36.70
>>173
システムエンジニアとプログラマを上下関係の階層構造で考えるのは限界があると思うよ
プログラミングを高いレベルで習得してる人と
業務ロジックを高いレベルで基本設計にまとめられる人は別人でもいい

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

設計書を書くだけのシステムエンジニアは
詳細設計書見てコーディングするだけのコーダー同様に
要らなくなるかもしれん

179:仕様書無しさん
12/01/07 12:53:59.54
設計にプログラムの作成とかやらせたらダメだよ。
本来やるべき設計に手が回らなくなって、デスマ化する。

180:仕様書無しさん
12/01/07 13:12:21.58
デスマ化するかはお客との調整がすべてだと思う。

181:仕様書無しさん
12/01/07 13:13:00.33
設計者と実装者を別けた時点でデスマ率UP


182:仕様書無しさん
12/01/07 13:21:09.93
>>181
> 設計者と実装者を別けた時点でデスマ率UP
現実問題、人・金がないのだから分けるしか無い。

その場合、設計者がサンプル実装を行なって
それにそったやり方で実装するように決めれば良い。
もちろんレビューも行う。


183:仕様書無しさん
12/01/07 13:31:21.51
>>181
納期までに一人で何でもかんでも出来るなら、苦労しないんだよ。

184:仕様書無しさん
12/01/07 13:36:31.46
>>175
後付してねぇし、言い逃れしてねぇよ。。
言っていることの真意と異なることを返してくるから、細かく答えてるんだろうが。
挑発して勝ったつもりになってんじゃねーぞ。

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

どこが意味変わっているのか答えてみろよ。
確固たる主張してんだろカス。

185:仕様書無しさん
12/01/07 13:48:34.72
>>184
ま、利益優先や短納期だと、工程ごっちゃにしちゃうのは、よくある話。
技術者に無理強いする訳だから、ほぼデスマ化するよね。


186:仕様書無しさん
12/01/07 14:12:45.08
>>177
いまどき、ソフト開発に3年もかけてたら製品発売した時点で時代遅れだってw

187:仕様書無しさん
12/01/07 14:28:08.70
>>185
それは、利益優先や短納期が悪いっていうより、後出しじゃんけんさせるのが悪いんじゃないの。

188:仕様書無しさん
12/01/07 14:30:29.06
新製品のoffice2000向けのツールを作ってたらoffice2003がでました!どうしましょう?
えぇぃ、再設計だ。とわいわいがやがやしてるうちにoffice2007リボンになってましてどうしましょう?
で、ちんたら勉強してたらoffice2010で標準装備で、実はツール無用で済みました。てへ。

189:仕様書無しさん
12/01/07 14:52:30.13
>>181

両方やれるような優秀な人間にプログラムさせるのはもったいない

190:仕様書無しさん
12/01/07 15:33:58.78
>>187
後出しジャンケンは対応次第で次の開発につながったりするから、一概に悪いとは言い切れない。
対応を誤れば、デスマ化するけどね。

191:仕様書無しさん
12/01/07 16:41:35.24
>>189
実装しかできない奴に渡してもいいような資料を作る方が時間がかかる。


192:仕様書無しさん
12/01/07 17:10:21.04
既に火を噴いてる状況なのに、横から口出してきて
更にいらんことやらせようとする、自称優秀SEがさらに引っ掻き回してくれそうな予感がするこの頃。

193:仕様書無しさん
12/01/07 17:21:50.18
>>191
仕事を誰かに割り振るようにできないと
一人に負担がかかり過ぎて、うつ病や廃人になるぞ。

194:仕様書無しさん
12/01/07 17:45:05.81
設計を誰かに渡してしまえばいい。

195:仕様書無しさん
12/01/07 17:54:56.32
そうか折衝や設計から外注にやらせればいいんだ
不況で人余ってるから買い叩けるし
失敗したら責任取らせて別の会社にやらせればいい

196:仕様書無しさん
12/01/07 18:13:07.31
>>195
お前・・・
責任を取ったからって、システムが出来上がるわけじゃないぞ。
失敗した時点で、システムの完成はできていない。
そして儲けが出るほど責任を取らせれられるわけじゃない。
最悪、会社倒産でお前は損して終わりだろ。

197:仕様書無しさん
12/01/07 18:21:04.60
だから最後は誰かが必死に仕上げるんだ
俺ら孫受けがな

198:仕様書無しさん
12/01/07 18:21:35.04
で仕上がるのか?

199:仕様書無しさん
12/01/07 20:10:11.48
>>195
実際はそのとおり。
だけど、それだとお前が間抜けないよな。
って訳で、1枚邪魔がはいるのよ。

200:仕様書無しさん
12/01/07 23:09:29.11
>>184
どうした?図星すぎてテンパったか?

201:仕様書無しさん
12/01/07 23:55:59.98
>>200
お前の人格まで否定しないから、反論してみろよ。

202:仕様書無しさん
12/01/07 23:58:54.79
図星と指摘することが反論そのものだろw

203:仕様書無しさん
12/01/08 01:44:23.33
ゆとりは会話もできないのな

204:仕様書無しさん
12/01/08 04:23:40.76
>>201
やっぱりね。おまえは打たれ慣れてないっつーか、社会に揉まれてないっつーか、そんなところだな。
経験浅いから使ってる言葉に重みがねーんだよ。
後出しジャンケンの意味も履き違えてるみたいだし。
聞きかじった言葉だろ?

すぐに感情的な反応するとこ見ると
あながち間違いじゃなかったみたいだ。認めろよ。


205:仕様書無しさん
12/01/08 04:32:41.63
もう一つ言うとだな、お前の思ってる言葉の裏に隠されてる真意なんて誰も知らないって。
何だよ真意って。最初から真意言えばいいのでは?
利益優先だとか工程ガーとか、そんなんじゃ仕様書いたことあるかどうかも疑わしいわ。
背伸びしなくていいよ。等身大でいいんだって。

206:仕様書無しさん
12/01/08 05:35:43.65
※関係ない人ごめんなさい。



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

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

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

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

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

で、俺が
「カチカチのほうが確実な見込みが取れるから安全だけど、
実際には利益が見込まれるならそういう客にも付き合う。」

207:仕様書無しさん
12/01/08 05:36:06.12
で、お前が
「話を後付けするな。確固たる主張がないなら折れろよ。
言い逃れ野郎。人格否定されてると勘違いするな。素直に認めろよ。」

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

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

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

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



ここから、返信 ← new!
「真意って言ったけど、書いてなかったことではなく書いていたこと。
お前が話しの流れを読めていない上に、どんどん話をずらしていった。
そして、図星が反論になっているという意味がいまだにわからない。
冷静に自分のレスとスレの進行を眺めなおしてこい。」

208:仕様書無しさん
12/01/08 05:38:28.50
そろそろダルいのと、もうだいぶ他の人に迷惑かけてるから、
次で誤解が埋められなかったら終わりにしよう。

209:仕様書無しさん
12/01/08 10:48:23.37
こうゆうやつらがいたらデスマになりそう

210:仕様書無しさん
12/01/08 12:15:41.06
細かい事はいいんだよ見たいな奴は危険。
また、一見細かく見えてどんどん話がずれて行く奴も危険。

211:仕様書無しさん
12/01/08 12:50:18.74
話の発端は、要件定義やらずに設計書を要求してくる客がいるというところから始まってる。
おそらく、お互いが最終的なシステムをどういったものにしたいかイメージできないからだと思う。
このような場合、試作を見て要件を出してもらうプロトタイプモデルとかがあるわけで、
その変形版って捉え方でいいんじゃないかな?

212:仕様書無しさん
12/01/08 12:53:45.13
>>207
あんたまたやらかしてるよ。。認めればいいのに。
頭凝り固まってる。

213:仕様書無しさん
12/01/08 13:00:43.93
>>212
相変わらず、何の具体的な指摘も反論も出来ないのな。
という事で終わりな。

214:仕様書無しさん
12/01/08 13:09:57.07
>>209
PM,PLだったら最悪だな。
特に行き詰まったときに、精神論や人格論ばかり振りかざす奴。
うつ病患者量産するからな。
PEだったら、チームから外してもらうよ。

215:仕様書無しさん
12/01/08 13:29:04.39
そろそろ仕様書、設計書の話に戻そうぜ。

216:仕様書無しさん
12/01/08 13:45:19.85
相手の意見なんて一切お構いなしに、自分の信念に基づいた見えない弱点を作り出して、
そこを突くことで勝ちに浸る、って奴はどこにでもいる

そもそも発端が、憶測から相手を過小評価することで気持ちよくなりたい相手なんだろ
んなの、いち早くレスする価値がない相手だって気づいて、スルー決め込むのが最適解だわ
わざわざ同レベルで争い続けるから、無駄レスが続くんだよ

217:仕様書無しさん
12/01/08 13:46:21.94
>>216
自分に言え

218:仕様書無しさん
12/01/08 13:47:49.66
>>204
やべぇ、こういうおっさんうちの職場にいるわw
こいつの書く仕様書が半端じゃなく使えないけど、声でかいからみんな困ってる

219:仕様書無しさん
12/01/08 14:01:32.66
反論しなければ周りにバカ遺伝子撒き散らすし、やりあえば不毛だし、生きている事自体が害でしかない。

220:仕様書無しさん
12/01/08 14:08:21.26
討論はどんどんすべきだし、途中まではいい感じだったけど
人格否定が始まったら終わりにすべきだな
「現場にたまにいるわ」のあたりからディベートとして成立しなくなったな

221:仕様書無しさん
12/01/08 14:25:44.51
仮想敵設定を誤るとこうなる

222:仕様書無しさん
12/01/08 16:03:21.72
はいはいぬるぽ

223:仕様書無しさん
12/01/08 18:31:36.88
2chに何か期待した時点で負けだろ。

224:仕様書無しさん
12/01/08 22:39:22.01
自分の書き込みに、全部同一人物がレスしてると思うなw
ここはIDもついてない板だぞ
IT開発者は少しくらいはアスペルガー気味なところがあっていいけどもちょっとは気付け

ちなみに >>144 >>168 >>174 >>178 とかは同一人物
>>168 の書き込みが悪かったな。
>>162のカキコの意図を取り違えていたよ。ていうか半分は論点ずらしだったわけだが
それも2ちゃんだ

225:仕様書無しさん
12/01/08 23:30:03.79
設計書の形式、ExcelもWordもダメだとすると、何がいいんだ?

226:仕様書無しさん
12/01/08 23:43:04.95
最後に頼りになるのはTEXTでしょう。

227:仕様書無しさん
12/01/08 23:48:33.49
jpg

228:仕様書無しさん
12/01/08 23:57:47.71
>>224
現場にたまにいるわ。
詭弁使ってドヤ顔してるやつ。
確固たる主張がないなら折れろよ。

229:仕様書無しさん
12/01/08 23:59:11.28
>>224
ごめんなさい。
「確固たる主張がないなら折れろよ。」
って言って見たかっただけです。

230:仕様書名無しさん
12/01/09 03:41:58.89
そもそもマイクロソフト様は設計書は何で書いてるんだろうな?
まさか、Word?

231:仕様書無しさん
12/01/09 03:42:20.26
Excelは保守を考えないなら楽だけどな

232:仕様書無しさん
12/01/09 04:05:14.81
>>230
HTML

233:仕様書無しさん
12/01/09 09:11:55.31
>>232
技術資料は全てMSDNとして公開されるわけだからHTMLだな。

234:仕様書無しさん
12/01/09 11:05:24.05
>>231
保守は、設計書の保守って意味?

235:仕様書名無しさん
12/01/09 11:27:49.61
>>233
ということはhtmlは何で書いてるの?
メモ帳?Word?


236:仕様書無しさん
12/01/09 14:56:46.29
ホームページビルダーだよ

237:仕様書無しさん
12/01/09 14:59:52.64
プロが包丁でじゃがいもの皮を向いていても
一般の人は皮むき器でいいと思うよ。
真似することはない。

238:仕様書無しさん
12/01/09 15:19:34.57
>>235
独自の管理?ツールがあるんだろ。
ドキュメントコメントと関連付けられたフォームに、
入力するとMSDN生成してくれるやつが。

239:仕様書名無しさん
12/01/09 16:03:59.55
>>238
ドキュメントコメントって設計書か?
少なくともソースが存在しない時点では書けないよな?

240:仕様書名無しさん
12/01/09 16:05:43.03
>>236
他社製品www

241:仕様書無しさん
12/01/09 16:35:25.48
>>239
ドキュメントコメントは仕様書だな。
作る順序は作業の進め方によるけど。
何かツールでモデリングしてコードの雛形作ってる事のほうがおおいか。

242:仕様書無しさん
12/01/09 23:07:12.36
>>235
HTMLはVisualStudioでだ。

243:仕様書無しさん
12/01/09 23:18:19.04
HTML形式で文書を作成するってのが想像つかないんだよな。
一般企業だと、文書は文書作成ソフトで作成して
提出時に用紙に出力するって流れで固まってるよね。
HTML形式を用紙に出力すると、体裁崩れちゃうし…。

244:仕様書無しさん
12/01/10 00:05:27.42
>>243
それは、HTMLとCSSが使いこなせていないからでは…?

245:仕様書無しさん
12/01/10 00:15:59.17
ネスケの4がデフォだった時代のオジサンなんだけれど、今からHTMLとかCSSとか覚えようとしたら
どっから覚えたらいいんだ? テーブルとTRとTDで組むとかしたらシーラカンス級の扱い受けるんだろうなぁ

246:仕様書無しさん
12/01/10 01:01:16.88
CSS3使えばいいよ。
テーブル使う理由の3カラムレイアウトとか
やっとCSS3に含まれることになったから。
URLリンク(www.htmq.com)





対応しているブラウザはまだないけどなw

247:仕様書無しさん
12/01/10 01:29:42.23
レビューの議事録って誰が書いてる?
レビューされる人(設計を説明する人)?レビューする人(レビューアー)?

248:仕様書無しさん
12/01/10 01:54:55.38
特に決めてないけど、される方が書いてるかな。

249:仕様書無しさん
12/01/10 02:06:52.77
テーブルレイアウトは、方眼紙の延長だわな。
それだけである程度のレイアウトができてしまうから、
それぞれに適した手段を一つ一つ学ぶ手間がかからないので、馬鹿でもなんとかなる。

HTMLは文章や単語に文字で表せない意味付けをするためのもので、
スタイルシートはその文書などの部品をどう配置するか、どういう見た目にするか、
みたいなただのの設定だから、誰でもすぐ覚えれるし、別に難しいことはないはずなんだけどな。

250:仕様書無しさん
12/01/10 02:10:21.59
>>247
れびゅーいが書いてれびゅーあが確認するって事が多いんじゃないかな
指摘事項とかを書き出して、対応内容まで書いて、対応してるかどうかを確認する、って流れになるだろうし

どうでもいいけど、このレビューイって呼び方がなんかこう好きになれない
キャハハ レビューイ

251:仕様書無しさん
12/01/10 02:28:18.68
>>249
CSSには長らく段組という機能が無かった。
また角丸を実現する方法もなかった。

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

CSSは要求するデザインを満たせるものではなかったんだよ。
十数年たってこれからやっとましになるかなってのが現在の状況

252:仕様書無しさん
12/01/10 15:11:04.08
>>245
なぜそのような発想になるのでしょうか

253:仕様書無しさん
12/01/10 20:28:00.12
ネスケの4がデフォだった時代のオジサン が、Web全盛期の世の中でHTMLを無視してきたってやばいよ。
たとえ、まったく異なる分野の技術者だったとしてもです。
そんなことだから「どっから覚えたら」などという発想になるんです。


254:仕様書無しさん
12/01/10 20:32:50.83
ネスケの4がデフォだった時代のオジサンなんだけれど 

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

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

HTMLとかCSSとか覚えようとしたらどっから覚えたらいいんだ?
テーブルとTRとTDで組むとかでいいの?


255:仕様書無しさん
12/01/10 21:20:09.14
>>254
お前、病気じゃないか…?

>>245
今時、Webのフリーツール沢山あるんだし、UIライブラリも沢山あるし、適当に中身覗いてみればいいんで無い?

256:仕様書名無しさん
12/01/10 21:53:22.32
納品用にhtml印刷した時に目次とページとかフッターとか入れられますか?

257:仕様書無しさん
12/01/11 00:32:30.20
>>256
CSSでメディアタイプってのがあってそれを使うと画面表示と印刷するときで
ちょっと違う出力に出来る。

258:仕様書無しさん
12/01/11 09:29:40.98
Officeソフトには、オートシェイプ機能があるけど
HTML形式で、オートシェイプと同じように自由に挿入したり、コメント入れたりできるの?

259:仕様書無しさん
12/01/11 10:12:05.94
>>258
SVGでやればいいのでは?

260:仕様書無しさん
12/01/11 10:58:59.68
HTMLの印刷だけはもうやりたくないわ…。今はマシになってんのか?
仕様書というか納品物レベルの印刷ロジック組むのが死ぬほど面倒だった。
一画面一ページで収まるように書かれていれば楽なんだがな。
ページまたぎのテーブルとか死ねる。

261:仕様書無しさん
12/01/11 15:00:13.71
>>259
SVG対応してるブラウザ少なくない?
それともHTMLで仕様書作るなら、IE9は必須って事なのか?

262:仕様書無しさん
12/01/11 20:04:28.50
そんなの客と取り決めろよ…

263:仕様書無しさん
12/01/11 20:05:43.30
HTML使いこなせないのと使いたくない理由で、言い訳並べてないか…?
ドキュメントの媒体なんて臨機応変に使い分けろよ。

264:仕様書無しさん
12/01/11 20:14:04.33
だからってExcel方眼紙スタイルはないわ

265:仕様書無しさん
12/01/11 20:18:44.11
早くて便利なら、理解できる仲間うちで使う分にはいいだろ。
まぁ、俺は使わないけど。

266:仕様書無しさん
12/01/11 20:55:37.15
xhtml なら簡単に変換できそう。

267:仕様書無しさん
12/01/12 00:23:55.42
xhtmlは出力形式。
何かからxhtmlに出力するのはありだが、
xhtmlから他の何かに変換するものではない。

なぜならXML(データ)にHTML(人間用文書構造)が含まれた結果
データとして処理しにくくなるからだ。

268:仕様書無しさん
12/01/12 00:56:32.52
印刷なんて紙の無駄でしかないと思ってるけど、
印刷が前提ならWordあたり使ってちゃんとやるのが一番手っ取り早いわ

あと、ただの愚痴だけど、番号つき段落で処理途中に挿入されて番号がずれる、みたいなものや
変更点の文字色を変えるような必要になるものを、Excel方眼紙で作るな市ね

269:仕様書無しさん
12/01/12 01:12:45.76
>>267
さすがに xhtml を直に書きたくはないけれど、
目次付きの印刷品質の pdf にするのは簡単だよ。
見出しも番号を自動で付けてくれるし。

270:仕様書無しさん
12/01/12 08:32:38.92
>>267
引っ掛かるんです一応言うがxhtmlは、
htmlをxml基準で曖昧さを排除し、
パーサーの簡略化と互換性の強化を目指したものだぞ。
別に人間用情報が入ってても構わん。
そういう部分を分離したけりゃXSLTを使う


271:仕様書無しさん
12/01/12 10:25:06.15
>>269
rest?興味だけで実用してないんだよな。
ツールはやっぱりSphynx?

272:仕様書無しさん
12/01/13 01:03:38.06
>>270
曖昧さを排除したからといって扱いやすいとは限らない。

人間用に手を加えたXHTMLはCSSやJavaScriptで
必要なdivやspanがあちこちはいるから純粋なデータではなくなる。

やってみればわかるが、純粋ではないデータ(それはしばしば変更される)
であるXHTMLからXSLTを使って変換するのは苦痛でしかない。


273:仕様書無しさん
12/01/13 17:05:57.86
様式に口うるさいヤツいるけど、矛盾点を突くと
「それは別の工程だから」とか「それは前のプロジェクトのでいまはこうだから」
とかいって結局、「いまの自分の書き方が正しいからね、既に書き終えた人は修正してね」の一点張り

274:仕様書無しさん
12/01/13 18:43:45.12
>>273
それ、お前の理解力が低いだけじゃないよな…?

275:仕様書無しさん
12/01/13 22:23:18.64
一度書き終えてOK貰った書類を、全部書き直せなんてマジキチ。デスマじゃん。

276:仕様書無しさん
12/01/14 02:51:22.99
>>275
書き直しの理由くらい添えてレスしろよ。

277:仕様書無しさん
12/01/14 03:02:21.06
リクエストパラメータで渡す項目一個一個書いたり、
入力チェックエラー時のメッセージを一個一個書いたり、
これくらいソースだけでいいだろと思ってしまうんだが。
ドキュメントに必要なのは画面イメージと処理フロー図、
簡単な処理詳細と、処理で使うDBのテーブル情報くらいでいいと思うんだが…

278:仕様書名無しさん
12/01/14 03:38:48.42
>>276
ただ一言、『わかりづらい』という理由だったりする。
ユーザー側の設計者だけでなく、誰が見ても何がどこに書いてあり、内容が即座に理解できるようにと。

279:仕様書無しさん
12/01/14 06:53:39.69
それは妥当な理由だ。
理解できない書類作る方が無駄な作業だろ?

280:仕様書無しさん
12/01/14 09:29:54.69
わかってないね
金がとれるドキュメントであることが重要なんだよ
日本のプログラマーは嫌儲なのか
金儲けが下手くそ

281:仕様書無しさん
12/01/14 12:54:34.34
>>277
パラメータやメッセージは、ちゃんと書かないとプログラム作れないだろ。
不要なのは、項目名の後に項目IDをつけろ、つけるなとか言う文章表現的なものや、
外部設計書なのにプログラマが実装できるように、集計ロジックを書けとか言うもの。
Excel設計書だから、枠から文字がはみ出てるとか、漢字に誤植があるとか…

282:仕様書無しさん
12/01/14 13:00:45.89
>>278
それは無理難題かもしれないな。
俺も昔やられた。

プログラムと一緒で、ある一定レベルまではわかりやすく書けるのは事実。
(日本語の使い方や、用語の定義の仕方、書く順番等)
ただ、想定する読者の優先度による可読性のトレードオフが発生する。
だから、誰が見ても解るドキュメントなんてない。

まずやるべきは、ドキュメントが誰にどのように使われるのかを定義する事。
次に、前提とする読者の知識レベルを定義。
次に、読者が複数いる場合、優先順位を決める。

相手の立場になって考える事は重要だが、無理なものは無理だ。
から、先に予防線をはる。
そういう文句を言う上司は多い。

283:仕様書無しさん
12/01/14 13:01:43.89
>>277
何に使われるドキュメントか理解してない事が原因だな

284:仕様書無しさん
12/01/14 13:25:26.71
そういう見た目や体裁、文体への指摘は、
レビュアー側が自分の好みでレビュー結果のブレが出るから、一概にどっちが悪いとは判断できないな
書式を厳格にするなら、プログラミングでの制約などと同じように
個々の裁量にまかせず仕組みで解決するのが最適解なんだけどな

言語みたいな感じで共通の書式がほしいわ
そういう金に直結しないドキュメント整理に費やす時間が勿体無い
いろんな人が見るようなマニュアルとかだとそりゃちゃんとやるべきだけど
業務系の割と簡単なWebシステムとか、万人が確認するわけでもない
仕様まわりの内部向けドキュメントとかでそういう事繰り返して工数削ってるのは、すごく無駄を感じちゃう
その体裁まわりの時間で、モック作ったりそれでUI検討したり、実装したりテストしたりしたほうが有意義だろうに…

285:仕様書名無しさん
12/01/14 14:00:03.50
俺自身は、本当に誰にでも理解できる設計書が存在するとは思ってないが、
受け入れを行う顧客担当者が考える「誰にでも理解できる設計書」を求められる。

結果として、顧客担当者が納得するレベルかどうかを手探りで設計書を作るわけだが、
俺はそいつじゃ無いので、何度も何度もやり直しを喰らうハメになる。

286:仕様書無しさん
12/01/14 15:01:28.91
>>285
顧客担当者が考える「誰にでも理解できる設計書」の段階で、だいぶ無理があるよな。
審査する人間がどの程度スキルや経験持ってるか分からないから
初心者向けに書くのか、経験者向けに書くのか凄く曖昧なんだよ。

大抵、見積時点では後者向けのドキュメントを想定してるみたいだけど、
開発が進むにつれて人数増えてくると、初心者とかいろんな人間が混じるから、
より詳しいドキュメントが必要になってしまってる現実もある。

俺は、設計書渡されたPEがプログラム作れる最低限必要な条件や項目が記載されていればいいと思ってる。

287:仕様書無しさん
12/01/14 15:03:10.54
>>285
そもそも顧客担当者が理解不足をドキュメントのせいにしている可能性もあるな…

288:仕様書名無しさん
12/01/14 16:00:50.97
>>287
担当者いわく、自分なら今まで打ち合わせをしてるから理解できるけど、今後担当が変わった時に仕様が伝わらないような設計書はダメってことらしい。
俺には、人ん家の未来の担当者レベルを予知する能力は無いっての。



289:仕様書無しさん
12/01/14 16:35:55.38
>>288
具体的に指摘してもらって、そこだけなおせ。
自分で考えろって言われたらそのまま出して、これで解るレベルの奴を雇えって言え。
両方ダメなら殴っていいぞ

290:仕様書無しさん
12/01/14 16:39:53.41
>>288
レベルの低い担当者だと、自社の業務の流れすら分かってない奴もいるからな。
そんな奴にまで分かる設計書書けとか言われても困るw

291:仕様書無しさん
12/01/14 17:27:53.80
説明書とかじゃないんだから、日本語の言い回しレベルでの指摘しかしない奴は、
すぐにでも担当からはずしてほしいわー。
よくそういう指摘をしてる場面を見かけるから、
ああいう人はレビュアーからはずしたほうがいいんじゃないか、って思ってしまう。

レビューする奴が当てにならないときは、わざと間違えた内容を混ぜてみるといいな。
ちゃんと要点を確認する人ならすぐに指摘してくれる。
もし仮に通ってしまっても、そこは後で気づいたことにして再修正かければいいし。
性格悪いやり方だけど、事前に危険回避できるって意味では手のうちだと思う。

292:仕様書無しさん
12/01/15 15:38:38.07
誤字脱字はレビュー以前の問題だからな。
勘違いすんなよ。
言い回しへの言及は説明書レベルなら普通にやる。これもレビュー以前の問題だ。
ワザワザレビューで指摘されてんだから有難くおもえ。

293:仕様書無しさん
12/01/15 18:18:25.72
>>286
> 俺は、設計書渡されたPEがプログラム作れる最低限必要な条件や項目が記載されていればいいと思ってる。
そんな丁寧に書かれた設計書なんて滅多にないけどな。
その業務特有の用語すら説明されていない設計書ばかりだ。

294:仕様書無しさん
12/01/16 00:08:26.23
プログラム仕様書をA HotDocumentで作るから使い方を調べとけといわれてる
で、やってみたら~.designer.vbを読み込んでくれない
やり方わかる人いたら、教えてくださいな

295:仕様書無しさん
12/01/16 21:24:11.70
HotDocumentは仕様書を作るものではなく、
仕様がわからないソフトの解析の
ちょっとしたヘルプができるかな?みたいなもの。

あとは、客にこんなに作りました!って
騙すものだから、

designer.vb程度読めなくても
いいじゃないかアハハハはは

296:仕様書無しさん
12/01/18 11:48:26.13
>>293
それでどうやってプログラム作ってるの?


297:仕様書無しさん
12/01/18 12:15:35.23
>>296
知ってる人に聞けばいい。

298:仕様書無しさん
12/01/18 13:37:44.51
知ってる人「知らない」(嘘)

とか、平気であるけどな。
人格破壊の負のスパイラル。

299:仕様書無しさん
12/01/18 14:19:36.20
できるできないじゃない。

やるんだ。

300:仕様書無しさん
12/01/18 16:57:42.59
>>299さんがこわいです。

301:仕様書無しさん
12/01/18 17:45:14.51
>>299
とりあえず仕様固めて頂けませんかw

302:仕様書無しさん
12/01/18 21:40:45.99
r.vb程

303:仕様書無しさん
12/01/20 00:38:11.54
みんなはDFDとか書いたりしてる?

304:仕様書無しさん
12/01/20 00:45:15.74
書かない。そんな暇はない。

305:仕様書無しさん
12/01/20 05:04:10.03
DFDって、書きにくくて分かりにくいと思うけど。
業務フローならアクティビテ図がいいと思う。


306:仕様書無しさん
12/01/20 10:05:07.33
なんだろう、よくUMLを既存のダイアグラムのスーパーセットのように捉える意見を見るが、そもそもの視点・指向が違うしな。
こっちの方がいい、いやあっちの方がいいという意見は首肯し辛いな。

307:仕様書無しさん
12/01/20 10:05:57.06
と思ったが、ちょっと穿った見方だった。すまん。

308:仕様書無しさん
12/01/20 11:09:45.53
いや、事実宗教戦争になりつつある

309:仕様書無しさん
12/01/20 12:55:20.15
単なる民族間抗争だろ。

310:仕様書無しさん
12/01/20 20:58:36.49
アジャイル開発やってる人は何をドキュメントに残しているんだろ。



311:仕様書無しさん
12/01/20 23:41:08.97
色々。プログラムに関するドキュメントは殆ど書かないけど

312:仕様書無しさん
12/01/21 05:14:25.24
色々って?

313:仕様書無しさん
12/01/21 07:10:14.71
赤とか青とか

314:仕様書無しさん
12/01/21 11:50:38.19
立体的に見えるやつだな

315:仕様書無しさん
12/01/21 15:56:17.93
ホワイトボードに描いた落書きとか、いっぱい入ってるよ。

316:仕様書無しさん
12/01/22 11:21:53.13
>>315
ホワイトボードの落書きをドキュメントとして納品してるってことか?
アジャイル開発でも、最終的には確定した仕様書や設計書を納品しなきゃいけないと思うんだが、
どういう形式でやってるのか、よく分からないんだよな。

317:仕様書名無しさん
12/01/22 12:40:40.50
>>316
最終的に確定したら、それはアジャイルじゃないよ。
アジャイルは常に進化し続ける事にメリットがある。

318:仕様書無しさん
12/01/22 12:56:30.27
>>316
そもそも納品をしないから。

319:仕様書無しさん
12/01/22 13:16:53.57
納品しないのは、誰の都合?
少なくとも顧客の都合じゃないよね?

320:仕様書無しさん
12/01/22 13:23:57.95
>>317,>>318
納品しないってことは、準委任契約で開発するってことか?
それでも、内部設計書くらいは残すんだよな?

321:仕様書無しさん
12/01/22 16:13:59.79
自社サービスなら納品て概念が無いんじゃないの

322:仕様書無しさん
12/01/22 17:00:17.40
偽装請負なら、「作業報告書」って言って週報レベルのものを出してもOKだよ

323:仕様書名無しさん
12/01/22 17:18:14.31
常に進化し続けるシステムを作りつづける方式がアジャイルであるのに、開発費用を抑えたり、要件がまとまらない場合の銀の弾丸みたいな考えでアジャイルやろうとするから、納品物がどうとか話がおかしくなるんだよ。

予算確保→システム作成依頼→納品物受領→プロジェクト終了
これはアジャイルでは無い。

その時々にある予算の範囲内で、無理なくシステムを作り続けることがアジャイルなんだよ。
発注形態なんて作業請負、派遣、定期雇用に決まってる。

324:仕様書無しさん
12/01/22 17:29:00.61
本来はマだけど、最近は見積もりするばっかり。

325:仕様書無しさん
12/01/22 18:51:37.87
アジャイルって、作る側も顧客側もどっち側にもメリットはあるんだけど、
作る側個々の能力とか結構重要だから、にわかは死ぬし、
理解力の無い顧客の場合もすぐ破綻するし、土方産業には向いてないんだろうな
人売りとか中抜きがしづらいやり方になるから、そういうので食ってるとこにメリットないし
そもそも、上のやり取りからしても、既存の枠が染み付いてるお偉いさんとかは、なかなか理解しきれない

326:仕様書無しさん
12/01/22 19:12:20.56
スレリンク(poverty板:3番)

327:仕様書無しさん
12/01/25 00:41:11.40
うちの場合、アジャイルに対する理解度合いがばらばらで、アジャイルを推進してる人は、要件の管理方法くらいにしか思ってない。技術的な考慮なんて一切なく、WFの考え方から抜け出せていないまま押し付けてくるから、現場は混乱。
現場は現場で、WFでやってた事そのままで、テストコード書けばアジャイルだよね~ってことで始めるが、テストコードのメンテはされずコストだけがかさむ。

328:仕様書無しさん
12/01/25 01:01:10.32
>>327
WFとはおそらくウォーターフォールの事だと思うけど、
そういったローカル用語(俺様用語)が飛び交う現場では
混乱と混迷の渦から抜けきれないのは当たり前だな
アジャイル手法うんぬん以前に問題がある

329:仕様書無しさん
12/01/25 03:39:24.24
ウォーターフォールって、ローカル用語か?
それに、アジャイル開発なら少数精鋭でチーム組むんだから、ローカル用語でやってもいいんじゃん。

330:仕様書無しさん
12/01/25 07:10:54.88
>>329
変な略語使うなって事だろ。

331:仕様書無しさん
12/01/25 14:09:21.70
この文脈でWFが何の略語かわからない奴はもぐり

332:仕様書無しさん
12/01/25 20:37:44.76
浮いてる奴はもぐり

333:仕様書無しさん
12/01/25 22:32:52.84
文脈から推測はできたけど、んな略記は初めて見たな。
使うなとは言わんけど、俺々略語って恥かくことあるし、多用はしないほうがいいとおもう。

334:仕様書無しさん
12/01/25 23:50:25.24
同じく推測はできた。
ただ、一般的ではない用語や略語を使う人間は仕事場では混乱を招く人の可能性が高い。
同じ現象がコードにも現れる。
>>331みたいな返しをする所が論外。

335:仕様書無しさん
12/01/26 00:00:06.04
自分の勤めてる会社の常識しか知らない人なんだろうね。
井の中の蛙になってる。

336:仕様書無しさん
12/01/26 00:34:18.10
瞬間的にワークフローと読んだ

337:仕様書無しさん
12/01/26 02:17:13.01
井の中の蛙
大海を知らず

知ったところで
 海水じゃぁ蛙は生きていけない

よかったね
 知らなくて

338:仕様書無しさん
12/01/26 02:47:36.87
特許庁の新システムの開発中断のニュース、
原因が東芝ソリューション側の設計遅れになってるけど、
実際のところ、何が悪かったんだろうな?

339:仕様書無しさん
12/01/26 03:05:31.24
ユーザが出す要件が矛盾だらけとか、二転三転したという可能性はないのかな? とシステム屋を擁護してみる。

340:仕様書無しさん
12/01/26 07:58:01.59
中国の特許を日本語で検索できるシステムなんて、嫌な予感しかしない。

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

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

343:仕様書無しさん
12/01/27 01:37:23.86
管理がアクセンチュアの時点でやな予感しかしない…

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

345:仕様書無しさん
12/01/27 13:33:46.50
お前が見ないからって、他の全員が見ないと思い込んでないか?

346:仕様書無しさん
12/01/27 21:45:40.69
俺も見ないぞ

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

348:仕様書無しさん
12/01/28 19:12:08.54
仕様書書き上げるまでコーディングはさせんぞ


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

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

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

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

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

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

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

明らかに悪者だろ。


355:仕様書無しさん
12/01/30 22:47:05.53
>>354

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

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


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

357:仕様書無しさん
12/01/30 23:11:52.78
>>356

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

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

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

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

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

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

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

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

362:仕様書無しさん
12/01/31 02:03:20.30
>>359
>詳細設計書から要件が読み取れないのが厳しい。

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

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

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

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

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

365:仕様書無しさん
12/01/31 07:23:51.68
>>358

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

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

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


366:仕様書無しさん
12/01/31 11:35:44.82
上長を通じて申し立てる。
個人で動くべきでない。

367:仕様書無しさん
12/01/31 23:29:21.14
>>365

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

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

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

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

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

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

369:仕様書無しさん
12/02/01 00:27:31.85
「A案とB案のどちらにしますか?」
客「良くて安い方」


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

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

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

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

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

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

375:365
12/02/01 23:53:42.85
>>368

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

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


376:仕様書無しさん
12/02/02 00:03:28.03
気持ちは分かるがやっちゃだめだ。
頭にきても手を出しちゃいけないのと同じだ。

377:仕様書無しさん
12/02/02 00:34:12.11
足ならいいか!?な?

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

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

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


380:仕様書無しさん
12/02/02 07:51:31.68
>>378

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


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

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

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

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

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

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

385:sage
12/02/02 14:48:04.24
>>384
PEって何だろ


386:仕様書無しさん
12/02/02 14:56:35.24
プログラマー

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

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

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

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

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

389:仕様書無しさん
12/02/02 15:15:06.06
おっと、超久しぶりにブラウザで書き込んだもんだから、sage間違い

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

391:仕様書無しさん
12/02/02 20:13:31.67
そもそも、詳細設計を素人が見る必要があるのか?
何のために見せるんだ?

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

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

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

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

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

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

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

398:仕様書無しさん
12/02/02 23:53:08.30
>>383

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

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


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

400:仕様書無しさん
12/02/12 15:15:49.08
みんなUML使ってる?

401:仕様書無しさん
12/02/12 15:21:47.20
クラス図とかシーケンス図とかよく使うな。

402:仕様書無しさん
12/02/12 16:12:31.26
ユースケース図とかアクティビティ図とかよく使うな。

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

404:仕様書無しさん
12/02/14 23:35:26.51
>>403
アンカは>>383のタイポかな?

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

405:仕様書無しさん
12/02/15 19:57:04.45
>>403

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

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


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


407:仕様書無しさん
12/02/15 23:00:20.08
仲良しごっこだろうとライバルごっこだろうと結果が出せなければ意味無いな。

408:仕様書無しさん
12/02/15 23:26:09.20
>>407

その通り。

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

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


409:仕様書無しさん
12/02/16 01:19:21.65
結果を出すことと組織の中で生き抜くことは全く関係ないな。

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




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

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

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

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

~♪♪ ○○設計書 ♪♪~


413:仕様書無しさん
12/02/18 12:44:36.23
客も喜ぶかもよ?

414:仕様書無しさん
12/02/18 20:03:22.26
中身がしっかりしてれば、外見なんて気にしない。
中身がなければ、怒りが増すがな。

415:仕様書無しさん
12/02/18 21:50:57.90
客によるとしか言えないな。

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

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

418:仕様書無しさん
12/02/21 21:41:55.34
ジョエルのファンなんだろ

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

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

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

422:仕様書無しさん
12/02/26 17:02:57.34
管理してないんじゃねw
担当が居なくなってから火を噴く、みたいな

423:仕様書無しさん
12/02/26 19:20:31.66
出来上がったソフトの動きが仕様です。

424:仕様書無しさん
12/02/26 19:27:21.27
そもそも要件が定義されていない。

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

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

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

426:仕様書無しさん
12/02/27 18:03:50.33
家電とかの電子回路は商品ごとに作り直せるから無問題

427:仕様書無しさん
12/02/27 18:09:50.12
日本のものづくりw
技術者を大切にしないから、衰退の一方だなwww

428:仕様書無しさん
12/02/27 18:25:14.20
>>421
誰かが何らかの形で残してなければ、何も無いんだよ。

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


429:仕様書無しさん
12/02/27 22:30:36.51
>>424
それはマネしたさんではなくてエスプーさんのことですね。

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

431:仕様書無しさん
12/02/28 20:36:35.55
仕様書については未だに悩んでる。

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

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

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

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

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

434:仕様書無しさん
12/02/28 21:02:30.53
latexはWYSIWYGじゃないからダメ。

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

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

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

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

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

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

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

437:仕様書無しさん
12/02/28 21:33:58.47
万能ソフトだろうが何だろうが、まともに文章が入力ができないソフトはダメだ。

438:仕様書無しさん
12/02/28 21:44:46.71
挿入 - オブジェクトで「Microsoft Word 文書」を選べばいいよ

439:仕様書無しさん
12/02/28 22:18:24.23
WordよりはExcelの方がいいな

440:仕様書無しさん
12/02/28 23:42:43.31
Excelが万能って理由もあるけど、Wordがダメ過ぎるってのもあるんだよ。

441:仕様書無しさん
12/02/28 23:46:53.03
>>431
ソフトウェア開発ではなくてネットワーク構築の事例になるけど、
UNIXサーバの設定仕様書をLatexで書いて、PDF文書として納品していたことがある

・Latexを選んだ理由は、文書を自動生成できるから(機械にできることは機械にやらせよう!)
・サーバの設定ファイルからLatexの章/節/リスト/テーブルを生成するスクリプトを開発 - (a)
・自動生成できない部分は、独自の定義言語を設計してその言語からLatexソースを生成 - (b)
・仕様書全体では100ページを超えたけど、Latex手書きは設計方針を記述した先頭20ページだけ
・スクリプト等のツール類の記述言語は、(a) Ruby と (b) Prolog
・事前にPDF文書による納品が可能かどうか確認要(大半の顧客はWordを希望/要求する)

あと、「コードにlatexで埋め込んで仕様書を自動生成する」提案については、
「文芸的プログラミング」という発想がある(詳しくは、ググると解説が見つけられる)

さらに付け加えると、将来性の面で(Latexよりも)「DocBook」と呼ばれるXML文書形式がオヌヌメ
まだ実用上の課題は多いけど、HTML/PDF/EPUB/ODF(Open.Office)等への変換が可能

442:仕様書無しさん
12/02/29 01:13:30.98
Excelで作られた文書って、目先しか考えてないからなぁ
文章を書く、ってのが前提にあるなら、Excel使ってる時点で全部糞以下だわ

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

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

問題の根本原因は、Wordですら理解できないのが多すぎることだと思う
そういう奴らも仕事に関わる以上、結局サルでもわかるExcel方眼紙!みたいなのに助けてもらうしかない

443:仕様書無しさん
12/02/29 01:31:29.80
普通の人はデータそのものと視覚的デザインの分離が正義だとは微塵も思ってない。
いかに正確に、効果的に読ませるかに関してのアプローチにおいて
文章データと視覚デザイン、場合によってはアニメ、効果音すらも一体化しており切り離せない。
だから理系脳の連中がデザインの分離を叫ぶたびにこいつら頭沸いてんじゃねーのかと思ってる。

444:仕様書無しさん
12/02/29 01:34:21.70
>>436
別に何でも出来るわけじゃないし、「万能」とはちょい違うと思うなー
Excelは、理解しなくても方眼紙としては使えるので、馬鹿でもわかるって感じだと思う

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

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

修正の履歴つけたり、番号振ってくれたり、用語を参照してくれたり、目次つけたり、段落やレイアウトやってくれたり、
印刷を面倒みてくれたり、みたいな文章の作成向きの機能がExcelには殆どついてないから、
どっちも一通り触ったことある人は、流石に文書作るのにExcelはねーな、ってなるんだと思う

445:仕様書無しさん
12/02/29 01:45:40.62
文書を電子データのまま活用するか、プリントアウトして活用するかの文化の違いに見える。

446:仕様書無しさん
12/02/29 01:47:08.58
ついてる機能を知らなくても、方眼紙エクセルなら力技で何とかできるからなぁ…。
ワードだとその機能を知らないと出来ない事が多数あるから、学ばない連中は拒絶反応を示すんだと思うよ。
検索や置換機能のあるエディタが手元にあっても、その機能知らないから、全部手作業で単語の書き換えをやる奴いるのと同じ話。
別に個々の仕事で簡潔する事なら、どうぞ好きに力技披露してくって感じだけど、
俺までそれに合わせないといけないってなるのは、すごく面倒。

447:仕様書無しさん
12/02/29 01:56:21.53
UMLって全部、多次元配列で表現できるような気がするんだ。
いや、具体的に検討したわけじゃないんだけど。
wiki文法に組み込めないかな。

448:仕様書無しさん
12/02/29 01:58:01.72
>>443
ここマ板だしなw
仕様の修正で、中身となんも関係ない見た目まで毎度再調整とか、無駄じゃね
ブレブレの仕様とかだと、仕様ちょっと変わるたびに見た目まで再調整とかになったりするんだぜ
基地外じみた章番号の修正とか、気が狂う奴が出兼ねない…!
そういうのがめんどくせぇ、ってのに理系だの文系だのは関係ないと思うw

>>445
印刷する気ないのに、印刷レイアウトではみ出しがないかチェックしろ、みたいなアホなルールも結構みるけどなw
レビューでんなとこチェックしてる時間あったら、内容の不備がないかをチェックしろよって思うこと多々

449:仕様書無しさん
12/02/29 07:30:37.21
基本的に方眼Excelのくせに、一部分だけ表を書きたいためなのか
横長なセルがあったりすると非常に萎える。

450:仕様書無しさん
12/02/29 07:39:14.85
プログラマだけど文系だからな俺
Texとかまじわからん

Excelが文章作成ソフトじゃないのはわかるんだが、Wordは不親切な親切が多すぎて使っててイライラする
はっきり言ってどっちも使いたくないけど二択ならExcelの方が扱いやすい

451:仕様書無しさん
12/02/29 07:44:22.12
> Texとかまじわからん
HTMLわからんって言ってるようなものなので、ちょっと恥ずかしい。

452:仕様書無しさん
12/02/29 12:33:47.48
方眼紙にするだけならまだ許そう。お前ならまだ切り貼りもだいたいできるし、他からのペーストもわりと受け入れてくれる包容力がある。
だがセル結合、テメーはダメだ!

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

項目名が意味フだったり、ヘルプも微妙だったりで、覚えるまで面倒なのはすごく同意できるが、
イライラしてても埒が明かんって調べたら、数十分ありゃ解決するような話だったこと多々。
Texも別に調べりゃすぐわかるレベルだし、わかるわからない以前に単にやる気がないだけだと思うわ。

453:仕様書無しさん
12/02/29 18:07:40.78
Wordで章だてから真面目に書けば、そう悲惨なことにはならない。
書式は統一されたものを適応するのみ。
なんでも適当にやるからだろ……

454:仕様書無しさん
12/02/29 18:16:16.13
>>450
Wordで文章書くとき、
一つの文なのに改行で行替えしたり、
タブや全角スペースで文字下げしたりインデントしたり、
文の一部を選択してフォントやサイズを変えたり、
目次を手でかいたり
してない?

そりゃ大変だよ。

455:仕様書無しさん
12/02/29 19:58:09.40
>>450
TeXなんかなんかプログラム言語の文法と比べると簡単なもんだぞ。
文系と言うのなら不親切な親切って言う表現はおかしいだろう。
Wordは大きなお世話が多いのは確か。

456:仕様書無しさん
12/02/29 21:09:57.02
Excel否定する長文をよく読むと

否定する理由の根拠が激しく乏しい件について。

457:仕様書無しさん
12/02/29 21:11:03.88
>>453
> Wordで章だてから真面目に書けば

章立てする理由は?
本書いてるわけじゃないんだから
そんなの必要ないよ。

458:仕様書無しさん
12/02/29 23:02:20.84
Ctrl+クリック(だっけ?)で即ジャンプできるじゃん

459:仕様書無しさん
12/02/29 23:22:27.66
>>457
ぐちゃっと書かれてる仕様書はわけわからん。
いや、書いてる奴自身はわかってるのかもしれないけど。
コードと同じように、スパゲティ仕様書もダメダメだ。

460:仕様書無しさん
12/02/29 23:33:53.31
章=ディレクトリでいいやん

461:仕様書無しさん
12/02/29 23:39:02.75
Wordはもうちょっとアウトラインが使いやすければなあ。

462:仕様書無しさん
12/03/01 01:02:50.34
ファイルがひとつにまとめられてると
同時編集が面倒なんだよねぇ。
ほら、仕様書作成なんて一人でやらないでしょ普通。

463:仕様書無しさん
12/03/01 01:17:53.14
モジュールに分けて仕様書つくればいいんじゃないのか

464:仕様書無しさん
12/03/01 01:27:04.63
SEになって数年たつけど、Excelで仕様書作ってるよ。
請負中心だから客先ですでに決まってるフォーマットを使ってる。
Excel設計書に不満があるけど、
だからと言ってWordの利点も見出せないから現状維持。

465:仕様書無しさん
12/03/01 01:33:49.86
使う人が使いやすいならエクセルでもいい。
自分しか使わないなら好きなので書けばいい。

ただ、Wordを批判するやつの九割以上がWordを使いこなせないことを責任転嫁しているのは納得いかない。

466:仕様書無しさん
12/03/01 01:44:53.48
Word好きじゃないが、Wordでもファイル分けくらいできるぞ。
複数ファイル参照とかは普通に使うでしょ。

467:仕様書無しさん
12/03/01 01:46:44.31
>>465
あるあるすぎるw
自分も昔そうだったからすごくわかるわ

不勉強だった自分を見てるみたいで、もにょる…

468:仕様書無しさん
12/03/01 01:47:13.73
>>465
使いこなせない人には糞にしか見えないってだけだべ
責任転嫁とは違う

469:仕様書無しさん
12/03/01 01:51:09.63
>>467
素直に言い給え、Wordも使いこなせないクズと

470:仕様書無しさん
12/03/01 02:09:21.40
仕様書はExcelで良いと思うが操作説明書をExcelで作るのは止めて欲しい。
しかも章ごとにブックは分かれているし目次もページ番号も手で振っている。

471:仕様書無しさん
12/03/01 11:53:26.64
>>457
仕様書っていう本書いてるんだよ。何言ってんの?

472:仕様書無しさん
12/03/01 14:04:06.28
本や説明書って、フォーマットは何を使ってるんだろうな。

473:仕様書無しさん
12/03/01 14:17:52.13
>>472
だいたいインデザとか。
所によっては、ページの少ないものはイラレでざくっと作る。

474:仕様書無しさん
12/03/01 16:07:19.00
>>472
Adobeの製品ラインナップなら、FrameMaker一択
中小出版社の製本業務や企業の製品マニュアル作成における、
統一されたスタイルによる高品質出版に威力を発揮する
InDesignはSOHOやフリーランス向けの製品(イラレは論外)

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

また海外大手のO'Reilly & Associatesの入稿では、DocBookと呼ばれる
XML文書形式が推奨されている(DocBookについては、まずWikipediaを参照)
実際にDocBook仕様書のソース(原稿)はDocBook自身で書かれ、ソースと
オンライン版は無償公開、印刷版は有償でO'Reilly Mediaから発売されている

475:仕様書無しさん
12/03/01 16:41:29.09
>>474
そーなのか。まぁ義弟の勤めてる会社は弱小だからかな。
見開き数Pの特集、小冊子くらいなんかは、チラシの延長でやっちゃうと言ってたけど。

476:仕様書無しさん
12/03/01 21:24:00.18
trac + wiki で書いてる

477:仕様書無しさん
12/03/02 18:13:53.79
断定できないけど、
本や説明書のフォーマットはWordやExcelを使ってないってこと?

478:仕様書無しさん
12/03/02 18:29:06.12
>>477
ちゃんとしたところだと、それ用のソフトは普通DTPと呼ばれる物を使う。
Wordを使ってる場合もあるだろうが。

479:仕様書無しさん
12/03/03 15:22:19.03
説明書ならWordで作るのも普通にあるよ

480:仕様書無しさん
12/03/03 17:24:16.16
仕様書の表から構造体やクラスDBのテーブルまで作ってくれるようなソフトが求められている

481:仕様書無しさん
12/03/03 17:28:24.39
ソースコードの構造体やクラスDBのテーブルから仕様書作ってくれるソフトのほうがいい。

482:仕様書無しさん
12/03/03 19:10:26.35
次点として、そういうことができる専任の人間を雇ってくれ。

483:仕様書無しさん
12/03/03 20:06:16.35
texがもう少し使い易かったら広まったろうに。


484:仕様書無しさん
12/03/03 20:27:41.81
>>483
texが使いやすくても無理だろうと思う。理由は四つあって、
一つ目は仕事はあくまでも体育会系のパフォーマンスであって、マクロ組んで楽したりすると上司に怒られるという風土。
○○したら作業効率UPするよ、と提案すると「俺の仕事を取るな」と怒られる場合もこれ。
二つ目は一般の人はデザイナーとかイラストレーターみたいな人種に異様な憧れと畏怖を抱いていて
テンプレに必要事項を記入しただけみたいな書類を提出しても、仕事したと見てもらえない風土。
最後、HTMLの歴史を見ても本来データ構造を記述する言語だったのに使う側は見た目とべったり癒着する記述しか知らない。
情報とその表現を分離するというITリテラシの欠如がある。

485:仕様書無しさん
12/03/03 20:50:54.77
四つ?

486:仕様書無しさん
12/03/04 00:20:29.87
>>484
>一つ目は仕事はあくまでも体育会系のパフォーマンスであって、(....以下略)

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

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

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

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

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

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

その問題点を改善して文書の論理構造と物理構造を明確に分離した新しい技術が、
>>474で紹介したDocBook(論理: XML, 物理: XSLT)になる

487:仕様書無しさん
12/03/04 00:27:09.44
まず論理構造と物理構造を明確に分離する理由がないよね。

488:486
12/03/04 00:56:36.22
>>486の最初の事柄の補足として、>>441のLatex活用事例を取り上げる

・Latex文書自動生成ツールは、「上司の目を盗んで」業務の合間に、あるいは
 自宅で少しずつ開発/改良を進め、最終的なPDF文書だけを上司に見せた
・独自のTexマクロ定義は一切使わず、標準マクロと流通パッケージ(longtable等)だけで作った
・業務上の成果として、
 ・Latexから変換したPDF文書を納品物として顧客(大手SIer)に認めてさせた(認めてもらえた)
 ・当初は単なる構築案件だったのが、保守サポートという追加受注を得る事ができた
 ・当初はSIerから他社ベンダを介した孫請けだったのを、SIerからの直請けに変えることができた
 を上げたことで、以降はLatex活用が「黙認」されるようになった

489:仕様書無しさん
12/03/04 01:29:25.09
>>484
デザイナーやらイラストレーターから、本文の体裁とか段落付けとか取り上げると滅茶苦茶喜ぶぞ。
テンプレートエンジン作ったことあるが、狂喜乱舞して、むしろあっちから、ちゃんと表題は表題と表現してくれとMLで流れたり、
タグ定義を増やしてくれと直談判しにきたり、
甘い文書は開発者権限でおまえで止めろ、俺達の事わかってくれてるじゃねーか、と無茶言ってきたり、
色々いい経験をした。
俺が論文のtexのコンパイル環境を毎回解説して構築させんのが面倒だっただけなのにな。

490:仕様書無しさん
12/03/04 01:33:25.24
作り話乙w

491:仕様書無しさん
12/03/04 14:58:35.98
向いてないのにこういう仕事選ぶ奴が多いのがなー
体育会系脳っぽいのが多くて、土方に拍車がかかる

492:仕様書無しさん
12/03/04 15:03:23.43
そういうデザイン部分と文章部分を分けるための道具や仕組みの使い方を
理解できない頭が悪い奴を除けば、そのあたりを分離するデメリットって別に無いからなー

まぁ、そういう頭が悪い奴がいっぱい居る環境にはつかえないっていうのが、ある意味デメリットか

493:仕様書無しさん
12/03/04 15:25:32.67
流し込み機能とか使っていれば
内部で自然と文章とデザインが分かれてるからね。

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

WYSIWYGエディタを使えば。

494:仕様書無しさん
12/03/04 15:46:29.40
>>491
就職氷河期の時なんかはこの業界以外は人をあんまり募集してなかったからな。
特に専門知識なし未経験者歓迎みたいなのは他に無いし。 今でもそういう業界は
介護位しか無いんじゃない? 何もない人は介護かITかの究極の選択という。

495:仕様書無しさん
12/03/06 21:45:54.91
あーマ等向けの校正ツールが欲しい。
仕様書の何がめんどくせぇってホント誤字脱字がメンドイ。


496:仕様書無しさん
12/03/06 23:03:10.69
>>495
そんなの気がついたら直すぐらいでいいよ
致命的なのは別として意味さえ通じれば流す方向で

ところで「あーマ等向け」ってなんだ?

497:仕様書無しさん
12/03/06 23:12:02.64
糞リーダーになると設計上のバグよりも
誤字脱字やレイアウトを気にする馬鹿が意外と多い。

498:仕様書無しさん
12/03/06 23:35:47.97
誤字脱字指摘してドヤ顔になってるのに、設計やユーザの使用感などの重要なこと指摘してもさっぱり伝わらない。
終いにゃ、やらなくていいって言って、切羽詰まってから自分でひらめいたかのように変更を決めて、丸投げ。

死んでくれ。

499:仕様書無しさん
12/03/06 23:44:18.18
だが誤字脱字だらけの仕様書も困るだろ
内容が本当に正しいかすら信用できなくなる
値が一つ違うだけでもかなりマズイ

500:仕様書無しさん
12/03/07 00:12:46.05
誤字脱字だったら、印刷した設計書に赤ペン引いておけばいい。
わざわざレビューの時にドヤ顔で指摘することじゃないよ。

501:仕様書無しさん
12/03/07 00:47:06.58
いや、指摘するかどうかじゃなくて単に誤字脱字がマズイって話でな

502:仕様書無しさん
12/03/07 01:07:26.69
誤字脱字はできるだけしない、レビューでみつけてなくす、ってのはそりゃまぁあたりまえだけど
それだけで満足するバカが多いこと、って話じゃないの
実際内容をきちんと理解できてるレビュアー少ないし
余計なことばっか指摘して、大事な中身まったく見てない糞な奴も結構見かける
能力ないのに長くいて微妙な肩書きだけがついちゃった系のオッサンとか、結構ひどい

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

糞仕様書の行間を読み解くよりは簡単な問題…!

503:仕様書無しさん
12/03/07 01:19:54.52
誤字脱字、正しくない日本語、誤解を招く日本語、全部良くはない事は皆わかってるんだよ。
ただ、物書きのレベルをプログラマに求めるのは酷だろ。
それができるならプログラマ辞めて物書きになってるって。

必要な能力なんだけどね…
時間は限られてるから、なかなかそのレベルをクリアできる人は少ない…

504:仕様書無しさん
12/03/07 01:24:57.69
でもあれだぞ。物かけない奴は概してプログラム下手だぞ。
とっちらかった文章だな、と思ったら、案の定プログラムもとっちらかってたりする。
箇条書きをうまく文章にやっつけました。って人の方がプログラムは良いことが多い。

505:仕様書無しさん
12/03/07 01:27:57.41
日本人って学校で文章の書き方に関するエッセンスを習わないし教えないからな。
みんな自己流っていう笑えない状況。

506:仕様書無しさん
12/03/07 01:35:52.28
とりあえずよ、校正じゃなくても、インテリセンス(オムニ補完)的なツール欲しいなぁ
章名を一部打ったら章の候補が出てきて、「.」押したら商に所属する値や名詞が並んで、
んで、エンター押したら指定の値がフィールドとして埋め込まれるとか。
とにかく下らないミス減らすツールが欲しいわ。どうでもいいことに時間掛けたくない。

507:仕様書無しさん
12/03/07 01:36:25.43
形だけは教えられるんだよね。原稿用紙の使い方、とか。
フォーマット地獄は既に小学校から用意されてんのよ。

508:仕様書無しさん
12/03/07 02:19:10.60
まぁ、プロの物書きですら難しいからな。
プログラムと一緒で、絶対的な正解ってのが無いのが辛いよな。

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

コードのレビューならコードをレビュー。
文章のレビューなら文章をレビュー。
正しい指摘を毎回できるようにして、プログラマを成長させる環境を作る事が、健全な業界の発展につながって望ましいと思うんだけどなぁー。

509:仕様書無しさん
12/03/07 02:36:09.33
正解は本当変わる。読み手次第だよ。
俺は何度となく言葉足らずだと怒られてきた。
「ちょっと考えたら分かることでしょ、pp2-3と、p10で既に説明してるから省いただけです」といった感じで。でも怒られた。
怒られたことを教訓に、いちいち懇切丁寧に書くようになって、怒られる事は減った位の頃、転職した。
「君、これは、馬鹿にしてるのかな?もうpp2-3とp10で説明してることをくどくど書く必要は無いんじゃないの?」と転職先では怒られた。
どっちが正しいか判断はつかんな…

510:仕様書無しさん
12/03/07 06:03:20.85
文章って好みがあるからね
だから軋轢生みやすい

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

ドヤ顔してこれでもかと優越感に浸る奴は小物だしたかがしれてる
そういう上司とかリーダーは多いけどなw

511:仕様書無しさん
12/03/07 06:33:24.66
レビューの場でいろいろと指摘が発生するのは当然のことだと思っているのだが
それを嫌がる管理者がいるのが嫌だな

512:仕様書無しさん
12/03/07 09:36:41.36
>>509
このパターンは非常に多い。
好みによっても違うが、同じ人でもコンディションによって言う事が変わるのは腹が立つ。

513:仕様書無しさん
12/03/07 13:00:10.93
デファクトスタンダードが無い以上、各組織においては過去の書類を参考にしながら書けということだな。


514:仕様書無しさん
12/03/08 00:48:08.41
ごくごく自然にに考えよう。

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

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

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

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

515:仕様書無しさん
12/03/08 01:31:36.31
>>509
あるあるwwwwwww
内容読みきれず、そのときの気分だけで思いつきの指摘する奴多すぎ

レベルの低いレビュアーに当たったときは何を書いてもなんかしら指摘される
とりあえず「わかりました!」って言っておくのが解決策だと思うようになったわ…

516:仕様書無しさん
12/03/08 02:50:41.70
>>28
勝手に大工やっていろ。

517:仕様書無しさん
12/03/08 03:52:41.46
>>514
分析や設計はユーザーの要件を満たすモノを作るためにやる。
それを実現するための技術的な知識は必要だけど、
次の工程はあまり深く気にする必要はない。

518:仕様書無しさん
12/03/08 19:39:40.79
>>515 わかりました、というと「課題」扱いになって再レビュー扱いになるから嫌だ。

519:仕様書無しさん
12/03/08 23:27:34.08
>>517
通訳と一緒だよ。
間に入る人は、両方のことを
知っていなければならない。

520:仕様書無しさん
12/03/08 23:29:57.69
>>517
> 分析や設計はユーザーの要件を満たすモノを作るためにやる。
当たり前の話。それは反論になっていない。

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

その答えが、下流に適切な資料を渡すということだからだ。
ユーザーの方だけ見ていてもいいものは作れない。


521:仕様書無しさん
12/03/09 00:01:44.11
下流に適切な資料って何だ?

522:仕様書無しさん
12/03/09 00:03:28.89
少なくとも通信フォーマットがかっちり決まってる資料

523:仕様書無しさん
12/03/09 00:05:10.80
>521
馬鹿な設計になってないこと。


524:仕様書無しさん
12/03/09 00:09:21.51
エンドユーザーは素人だから
めちゃくちゃな要求をしてくるのは仕方ないけど

それ以外は、めちゃくちゃな要求しちゃだめだよね。
プロなんだから。

525:524
12/03/09 00:12:36.91
今言った、「めちゃくちゃな要求」ってのは実現が難しいって意味じゃなくて
ナンセンスな要求ってことね。どう考えても使いづらくなるのがわかりきってる仕様とか
書いてる内容に矛盾があるとか、そのとおりに作ったら破綻するのが目に見えてるシステムとか。

526:仕様書無しさん
12/03/09 00:14:07.33
>>523
Aボタン:ジャンプ
Aボタン長押し:しゃがむ

プレイヤ「うん?」

527:仕様書無しさん
12/03/09 00:21:14.50
>>523
Aボタン:ジャンプ
Aボタンまわす:回転

プログラマ「まわす?」


528:仕様書無しさん
12/03/09 00:28:51.04
初版
→→(すばやく2回):ダッシュ
←←(すばやく2回):ブレーキ

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


改訂版
→→(すばやく2回):ダッシュ
←(長押し):ブレーキ

プレイヤ「左に行きたいです」



次ページ
最新レス表示
レスジャンプ
類似スレ一覧
スレッドの検索
話題のニュース
おまかせリスト
オプション
しおりを挟む
スレッドに書込
スレッドの一覧
暇つぶし2ch