仕様書、設計書について

1 ：11/11/26

外部だの内部だの基本だの詳細だの…
曖昧な基準で書かれた、いろいろな名前で呼ばれてて
「これってどうなの？」「意味あるの？」といった物に出くわす事も少なくない
しかし、純粋にプログラミングだけをして食べていくことは、昨今じゃ難しく
避けて通れない、否が応でも作る機会に出くわしてしまう、そんなドキュメントたち
設計書や仕様書についても、マ視点で語ろうぜ
・自分のなかでの仕様書/設計書の呼び方と分け方
・成功談、失敗談
・仕様書/設計書は何を使って作成する？(Word/Excel/HTML/手書き！)
・仕様書/設計書に含める図の作成方法や使っているツール紹介
・炎上プロジェクトでみた(よくない意味で)素晴らしい仕様書/設計書
・そもそも仕様書/設計書って本当に必要なの？
・こんな仕様書/設計書は、ぶっちゃけアリ？ナシ？
などなど、設計書にまつわる話題を募集

2 ：11/11/26

関連スレ
【その２】Excelで仕様書を作る会社の奴の数→
http://hibari.2ch.net/test/read.cgi/prog/1177362668/
DBAがテーブルの仕様の説明資料作らんのだが
http://hibari.2ch.net/test/read.cgi/prog/1318690907/
仕様書の書き方
http://hibari.2ch.net/test/read.cgi/prog/1191806449/
仕様書とか意味あるの？
http://hibari.2ch.net/test/read.cgi/prog/1267241758/
(´･ω･｀)仕様書ぶちす！
http://hibari.2ch.net/test/read.cgi/prog/1195826467/
設計書を作ってるせいで生産性落ちてないか？
http://hibari.2ch.net/test/read.cgi/prog/1169735232/
詳細設計をしても逆にコーディングしにくくなるだけ
http://hibari.2ch.net/test/read.cgi/prog/1280647235/

3 ：11/11/26

投げっぱなしもあれなので
・俺の中の定義
外部設計==基本設計、内部設計==詳細設計
プログラム設計はソースコードで代用できるため不要
外部設計/基本設計
　UIやエンドユーザーが意識するレベルでのI/O、やりたい事などを纏めた資料
　理由があって意図的に制限する場合を除いて、実装方針の変更には影響のしないレベルの情報
内部設計/詳細設計
　入出力の詳細や分岐条件、メッセージ、処理順序など並べた
　フローチャートのような分岐やループなど、コーディング上で表現する方法が複数あるような
　意味のない情報は「明記してはいけない」
プログラム設計
　2重管理になるだけで無駄なので、ソースコードが全て
　javadocやXMLドキュメントコメント、コード内のコメントなど、コードでは表現できない情報
　クラス図などコードより抽出できる情報

4 ：11/11/26

・実際の運用
外部設計/基本設計、内部設計/詳細設計
　箇条書きの要件定義、またはループや分岐を書いたフローチャート
　外部/基本設計が詳しい場合、内部/詳細は内容のコピペか焼き直し
　内部/詳細の修正でも必ず外部/基本設計が修正される
プログラム設計
　そんなの作ってる余裕なんてないです＞＜；
　コピペが何割かを占めるコードだけが絶対でありそれコメント(そもそもない)含めて他は不要
---
正直マ暦はあんまり長くはないのだけれど、これって普通のことなのかな…？

5 ：11/11/26

ちなみに作るのに使うのは基本的にExcelです。
もちろん方眼紙です。
図はオブジェクトたち。
たまーにWordもありますが、終盤はファイルがいくつか見事にぶち壊されてます。
レビュアーが意図してる「仕様書」が何かを察することが、うまくやるコツなのかなって
最近思うようになってきました。書きたくない、じゃ通らないですし…。

6 ：11/11/26

ソースコードは設計書だと考えるべし。
設計はなるべくコードとして書くべし。
コードから自動生成できるたぐいの情報は、
別にドキュメントにまとめる必要はない。
仕様書はソースコードにコメントとして書くべし。
またはテストとして書くべし。
Excel、他形式のドキュメントはたたき台としての意味はあるが、
最終的にはソースコードに全て記述するべし。
別の形式として見たければ、ソースコードから変換すべし。

7 ：11/11/27

ケースバイケース
以上終了

8 ：11/11/28

結局ある程度の実装経験がないと設計なんて出来ないよ
でも、設計から入れ実装は後だっていう微妙な風潮
しかも、つくる設計書の記述内容は、実装前に作るものとしてはイマイチな内容

9 ：11/11/29

設計書とプログラムが食い違っていないか、機械的に検証する手段がないから、どんなに頑張って設計書作っても立派なプログラムが出来るわけじゃない。
結局設計書作るのって自己満足でしかないよね。

10 ：11/11/29

設計書作ること自体が目的になるとページ数だけ多くなって誰も読まなくなるな
そして設計書があるのにまったく見ずにソース見ながら電話対応するようになる

11 ：11/12/01

ソース見て判断できない人が見てるフリするための資料になってることが多いな

12 ：11/12/01

大手だと品質保証のためとか言ってコーディング前に設計書を要求されるけど、
誰もまともにレビューしてなくて結局実コードのテストで
設計段階の間違いがボロボロ発見されるような現場ばかり。

13 ：11/12/01

設計書なんて大枠だけきっちりしてればいいんだよ
あとインターフェイス部分とエラー処理と

14 ：11/12/01

現状のドキュメントはバッチ処理にはソコソコ役に立つけど
オンラインだと矛盾が多い
新しい設計書の技法出来ないかな？
UMLに拡充する形でいいけど
あと、各社マチマチな工程名称も統一して情報処理試験でキッチリ記述と読み取りを出して欲しい
納品の為にしか存在価値のないものがおおすぎる

15 ：11/12/01

>>12 想像力があっても実物の挙動は予想不可能なんだぜﾋｧｯﾊｰ

16 ：11/12/02

文章での説明にしても図説（もちろんフローチャート()）にしても
例外をうまいこと表現できないから、なんか書いてて、ウアーってなる
他のとこだけコードよりの内容が要求されるのにｗｗ
でも他の人みると、そもそも例外なんてアウトオブ思考だったわ

17 ：11/12/02

>>14
確かに、設計まわりの明確な名称はあるとかなり嬉しいな
とにかく何もかもが曖昧すぎるんだよな

18 ：11/12/02

>>12
レビューしないだけマシだわ
設計書段階で馬鹿みたいレビュー繰り返してる内に
フローチャートを作ってた事あったし
挙げ句に設計書レビューに無駄に時間がかかった結果
実装はデスマーチになってるから本末転倒の極み

19 ：11/12/02

設計段階で何するかは煮詰めたほうがいいよ。
実装者がアイディアマンになってしまうのは良くない。
俺が実装して痛い目見た経験から。

20 ：11/12/02

>>19
詰めるべきは客先交えて決める外部仕様だろ
設計で内部ロジックなんか詰めてもしょうがねーよ

21 ：11/12/03

DB設計と画面のモック作るだけ。

22 ：11/12/04

マなんて信用してないから書かせる

23 ：11/12/05

マはマで設計が信用ならないって言ってたりするからな
どっちであっても、出来る奴と出来ない奴の差が激しすぎるんだよな
なまじ形だけなら誰でも出来るもんだから、ひどい物でもなんとかなってしまうっていう

24 ：11/12/05

つか、システム全体の設計はともかく詳細設計書はコード書く本人に書かせてレビューするだろ。
新人とかなら詳細設計書まで書いてやって渡すこともあるけど。

25 ：11/12/05

>>24
新人じゃないならそれこそ実装したコードレビューした方が早いだろ

26 ：11/12/06

こういうのみると、つくづく設計関連の用語の意味が統一されてないのが
諸悪の根源だって気がしてくるわ

27 ：11/12/06

>>26
諸悪の根源は別のところにあります
本質を見抜く目を養わないと一緒ドカタですよ？

28 ：11/12/06

建築業界って、大工が「俺の作ったもんが設計書だ！」って思う人いるんだろうか

29 ：11/12/06

この前ブックオフで「仕様書の書き方」みたいな本があったんだけど、結局サンプルはオマケ程度で中身スカスカだった。
ちなみに俺が超参考になったのは、某大手の社員用サイトにある雛形だった。
しかしそれを下請に見せない理由がよく分からん。
その形式で納品すればそこそこな品質になるはずだが、社外秘なんだよ

30 ：11/12/07

基本的にそこらの書店にあるような仕様書サンプルってプログラム素人向け、顧客が理解できる程度のものだからね。

31 ：11/12/07

この業界自体土方だけどな
土方根性土方思想がはびこりすぎて個人でどうにかできる状況じゃねーよ(´･ω･｀)はあまじああ

32 ：11/12/07

>>28
モジュールを指して設計書という奴は居ないだろう
ソースに該当するのはなんだろうな

33 ：11/12/07

>>28
大工が建築物にコメント書くのが許されるんなら設計書にならなくもない
物置程度ならそれで充分なんじゃないかな、よくわからんけど

34 ：11/12/08

>>33
建材に印ついてたりはするよな

35 ：11/12/09

うちのポストにもたまに印がついてる

36 ：11/12/09

書いてるとこ見つけたら器物損壊で訴えれるんだっけ、あれｗ
きっちりかっちりしすぎても、緩すぎても仕様書って成り立たないよな
降車は言うまでもなく、前者も全員が守れない無駄な仕組みになってることが多くて、破綻しやすい
いい仕様書の共通仕様でもできればいいのにな！！

37 ：11/12/09

>>33
墨つぼが大工のコメント

38 ：11/12/10

「昔、城を建てた無名の木工は、自分がその仕事に携わった証として、
屋根裏に自分の名を刻んだ工具を態と忘れたそうだ。そんな些細な思いすら、お前達は消し去るのか？」

39 ：11/12/10

たまに外科手術で縫合終わった後にﾒｽが一本足りないことに気が付いたりとか？

40 ：11/12/12

sierなんかで働くから悪い

41 ：11/12/16

ドキュメントの枠だけ用意されて中身の書き方が決まっていない現場って
文章の語順や言い回しとか表現の仕方ばかり気にする人多いけど
正直馬鹿にしか見えないんだよな
共有鯖から過去の資料や既にＯＫ出てる仕様書を真似て作成しても
人によって作り方が違うからＮＧになるし
そもそも同じﾌﾞﾂ出して見る人によってＯＫ・ＮＧ別れる時点でおかしいが
本人たちは指摘して偉い気分にでもなってるのかね
「ここは太線で区切ろう」とか
「ここは�@、�Aを使おう」とか
「ここは図を入れよう」とか
「ここは→・↓・←・↑を使おう」とか
「ここはカッコ使おう」とか
「待てよ！〜が〜の〜を…うーむ」とか…
こんな指摘ばかり受けてる間に
５時間でコーディング終わるＰＧの仕様書に３日かかったし
完全に遅れが発生してこの指摘馬鹿と一緒に毎日２２時過ぎまで残業開始
結局終盤の方からはＰＧの仕様書は時間がないからと指摘馬鹿が作成
どれ程のもん作ってるのかとこっそり覗いたが１時間くらいあれば
作れるような普通の仕様書だった
要するにこいつの趣味の書き方というだけだった
指摘馬鹿は人に「こっちの方がいい」とか指摘する前に
本当にそれをする必要があるのかどうかを考えた方がいいわ
必要ないことに時間掛けてる奴多すぎ

42 ：11/12/17

まったくだわ
うちの職場だと、能無しPLとか老害連中や口うるさいバカ女が
しょっちゅうどうでもいいことにばっか力注いでて、もうウンザリ
その決定を行わない無駄なボールの投げあいしてる時間で
解決してしまえる内容をぐだぐだやって、時間が浪費されてく
無駄に細かい仕様を早いうちから書こうとして要点はつめないまま、
後になって仕様変更のなみで外設あたりからいろいろ詰んでるし、頭痛いわ…

43 ：11/12/17

>>41
それを顧客側が要求してくることもあるからな。
プログラムは正しくても、仕様書の記述ミスを理由に検収拒否してきたり、
些細な記述漏れを引き合いに、仕様が明確でないシステムは稼働させられないとか言い出して、稼働延期&稼働まで強制的に立会い延長になったり。

44 ：11/12/20

>>43
それはお前のせいじゃ、ドアホ

45 ：11/12/20

アホでもわかりやすいところは詳細に書いて、説明が面倒臭いところは適当にごまかす
初期処理と終了処理はソースコードレベルの細かいこと書いてるのに
肝心の主処理は「ファイル変換を行う」の一言だけ
コーダーのための詳細設計書なんて見たことないんで書き方もわかりません

46 ：11/12/20

そうそう。
納品物件としての仕様書は誤りが書いてないこと、体裁が整ってることが最重要。
それを見てコーディングができるかどうかはまったく評価対象外。

47 ：11/12/21

だから設計と製造は切り離したほうがある意味確実なんだよね…
保守さえ考えなければ

48 ：11/12/22

わかってない奴がわかった気分になるための説明書であることが多いよな
実装を前提とした検討用の設計書になってるものを見たことがない

49 ：11/12/22

わかってない奴に見せてわかった気分にさせるための説明書、か
そして出来ない奴ほど体裁に死ぬほどこだわる
まったくこだわらない奴も出来ない奴だけど
あと文体とかかき方にルールを設けるくせに
Excel方眼紙を卒業できない馬鹿も多いよな
自由度が高いツールを強制して、自由に出来ないように無駄なルールをつくりあげ、
仕事を増やすのが得意技！みたいな
Excelで方眼紙で糞ルールたくさん作られるくらいなら、まだ糞Word使ったほうがマシだわ

50 ：11/12/22

個人的には、体裁が整ってることは大切であり、
納品物あるいは後々の保守を考えれば最低条件であると考える
問題は文書作成環境にある
Excel/Wordとも短いレポートを手軽に作成するのには最適なツール
ただし、これを数百ページにおよぶ技術系文書(仕様書/設計書/マニュアル等)に
利用する発想が、適材適所という言葉を知らぬ人が犯す基本的な間違い

51 ：11/12/22

>>48
> 実装を前提とした検討用の設計書
うちはこういうのばかりだ。
おかげで、他人が見たら「どうコーディングするべきなのか」はわかっても
「どういう意図でそうなってるのか」がまったくわからない状態になってる。
> わかってない奴がわかった気分になるための説明書
メンテナンスする立場で言うと、わかってる奴にしかわからない設計書なんか
残されても、まったく嬉しくないんだ。

52 ：11/12/22

>>51
どういう意図で、は要件定義から追えば分かるんじゃないの？
分からないと保守更改でる

53 ：11/12/22

>>50
むかし社内で議論したけど、誰でも開けて編集できて、となると他に候補が無いんだよね。
でも開く環境が変わるとテキストがズレて崩れるけど（爆笑
Word使うなら箇条書きの範疇で済ます。
凝りたいならPowerPoint＋PDFかInDesignでごゆっくりどうぞ。
ということにしてる。

54 ：11/12/23

「Excel方眼紙滅べ！それで仕様書つくるやつもぜんぶ滅んでしまえ！」
「Wordは糞だが選択肢が他にないんだよな」ってのが前提にある奴です
Wordを推したいわけではないけど、Excel方眼紙で設計書作るくらいならWordのほうがいい
>>50
使いやすいとか最適だとは一切思わんけど、Wordはそういう文書作成に使う物じゃね
もちろんExcelはない。使い捨てのレポートみたいなフリーフォーマットで使い捨てるものなら方眼紙は便利だと思うけど
>>51
言葉足りずで申し訳ない
48で言ってるのは、あくまでも「設計書」に書く内容の話な
そういうわかってない人への説明や方針決めの経緯は、
もっと上流の要件定義だったり、補足資料として別に纏めるものだと思う
そういうのがかかれてないドキュメントに恵まれてるのは、いい環境だと思うけどな
>>53
Wordの基本機能ですら、世間一般に「凝ってる」レベルだって捕らえられちゃうことが一番の原因だと思うわｗ
ドキュメント関連でWordを使う利点は、文章を書く以外のことに気を使わなくてよくなる、ってところと
体裁だけを全体纏めて修正でき、印刷のことも考えなくて済む、ってところ。このあたりが表計算ソフトのExcelにはない
ただ、それぞれの機能が使い難いし、理解しづらい
なにより、そういう基本機能ですら理解出来ない、しようとしない奴が多すぎて、まともに使われることが少なく、
仮にちゃんと作られてるドキュメントでも、そういう理解能力がない馬鹿が一人チームに混じってるだけで
簡単に設定されてる体裁の破壊が出来てしまうから、使えないツールになりがちなのよね

55 ：11/12/23

>>51
>おかげで、他人が見たら「どうコーディングするべきなのか」はわかっても
>「どういう意図でそうなってるのか」がまったくわからない状態になってる。
うちではわかってないヤツ向けの仕様書書いてるけど、そのわかってないヤツが
意図とか書くと余計なこと書くなって言ってくる
なもんで「どういう意図でそうなってるのか」は偉い人から口頭で聞いてソースのコメントに書いておく
> メンテナンスする立場で言うと、わかってる奴にしかわからない設計書なんか
> 残されても、まったく嬉しくないんだ。
わかってないヤツの想定が違う
OSって何ですかレベルのヤツを指してる
>>51の組織ならそのプロジェクトに参画してなくてもコーダーなら理解でできる仕様書を書きやすい気がするが
そういう組織に属したことないからよくわからんけど

56 ：11/12/23

>>53
あ、あと、PowerPointとかinDesignで設計書はないわｗ
何のための設計書かがわからなくなる
それやるくらいならまだExcel方眼紙にオブジェクト張って済ませばいいと思う
そういや、ここじゃないどっかでみたけど、
Wikiを設計書に使うってのも結構面白い発想だなって思った
バックアップ含めて管理面での自動化できるし、差分や履歴も簡単に見れる
2拠点間での共有も楽で、一元管理もしやすい
図説みたいな自由度への制限とか、環境の構築が必要だとか、他に提出するときどうするの、とか
ドキュメントとレイアウトがどうしても混ざってしまうような欠点もいっぱいあるんだけど、
外に出ないものなら結構便利そうではある

57 ：11/12/23

>>55
> わかってないヤツの想定が違う
そうそうｗ
文章を読むことすら出来ないような人とか、特にそういうこといってくるｗ
箇条書き、図説、表あたりしか理解してもらえない。
そういうのは設計書じゃないだろって思うけど、その思いは言葉にしても届かない！
結局本当の設計書は各担当の頭の中で作成されちゃうのよね
自分も他に書ける場所がないする事はできるだけコメントに残したりしちゃう派だけど、
ソース弄る奴にも、先にあげたようなのが混ざったりする事もあるから
保守されないコメントが、現状の実装と異なる状態になるかもしれなくて、コメントに残しすぎるのも怖いんだよな
マに免許とかそういうのはないし、コーダーのレベルもピンキリ激しい
あとコメントじゃレビューとかもないから、誤記ったりしてもそのまま残る可能性が怖い…

58 ：11/12/23

はぁ？
設計書って言ったら図だろ。
お前車とか家とかの設計書見たことあるのか？

59 ：11/12/23

あはっ♪
設計書って言ったら、ﾌﾂｰ「設計書がどうしたんや！何して欲しいんかちゃんと云いなはれ。そんなんで伝わると思うたらおお間違いや」
設計書是也設計書。
設計書見たことあったらどうなのか？ 無かったらどうなのか？ もったいぶってても大した話じゃないならとっとと話を進めなさい。

60 ：11/12/23

つーか、設計書を曖昧に自然言語で書くなよ。

61 ：11/12/23

たしかにマも土方だが、そういう方面の土方ではないぞ。

62 ：11/12/23

理解能力がない人に見せる資料は設計書とは分けたほうがいいけど、理想どおりにはいかないしな。
結局頭の中が下の連中に合わせないといけなくなる。

63 ：11/12/23

>>60
自然言語で表現できないかしづらい内容までドキュメント化しろなんては思ってないよ
シーケンス図とかクラス図で済むことならそっちでやるし
きっちりかっちり自然言語を使わず表現できる部分なら、それはもうコーディングしちゃえばいいんじゃね
>>62
まぁ結局そうなるんだよな

64 ：11/12/23

> きっちりかっちり自然言語を使わず表現できる部分なら、それはもうコーディングしちゃえばいいんじゃね
うん。だから設計書＝コードなんだってば。
日本語は、コメントとして書けばいい。

65 ：11/12/23

プログラム設計書は要らないと思うが、それより上の工程でのドキュメントは必要。

66 ：11/12/23

>>65
ISOなんとかのためなのかどうかは知らないけど、
プログラム設計書は求められる現場が多い。
それより上の工程のドキュメントは無くても。

67 ：11/12/23

>>66
上の工程のドキュメントはどんなにわけわからんこと書いてても
我々に文句言う権利ないしね

68 ：11/12/29

>>4
プログラム設計書は重要じゃないけど
プログラム設計は重要
この重要性が現場でも理解されてないからプログラマの地位は低い

69 ：11/12/29

設計書くのは重要だと思うけど、最低限まともにレビューできる奴がいないと、作る意味がないんだよな
的外れな指摘しかされてない、半端な設計書なんて用意しても、結局糞の役にも立たないなんてことになるしなぁ

70 ：11/12/29

レビューは、その場で見て思いつきで指摘して終わるからな
ちゃんと修正されたか再レビューしないことも多いし
儀式的なものになり果てている
担当を複数人にしてお互いにチェックするという仕組みにしたらいいと思うんだが

71 ：11/12/30

>>70
それは単純に開発プロセスの問題な気がする。
プロセス監査とか無いの？
結局開発者自身が本当に改善したいと思ってるかどうかと、
さけるリソースがあるか、によるんだよなぁ。
実際真面目に取り組むとちょーメンドくてしんどい。
けど効果はある。

72 ：11/12/30

開発プロセスの問題じゃなくて、
各々の文章チェック能力、設計力の問題だろ。

73 ：11/12/30

そら有能な個人の力に頼るのが早いてのは分かるけどさ。
再レビューが無いのが問題だと感じてるなら、
再レビューしたかチェックする機構があるべきだし、
「指摘がその場の思い付き」「儀式的になってる」とか、
不具合流出の分析とそれによる対策がされて無いわけじゃん。
レビュー観点の整理とか、インスペクションの導入とか。
実際>>70自身言ってる「チェックの仕方」自体プロセスそのものだし。
低レベルでの開発プロセス定義なんて、最低以下の人間に
最低限の仕事させるためのもんだよ。
高生産性や高品質はその次の話。

74 ：11/12/30

http://d.hatena.ne.jp/iad_otomamay/20111207/1323276264

75 ：11/12/30

低レベルの人間に何回チェックさせても無駄。
プロセス重視することと、内容を軽視することは同義。

76 ：11/12/30

＞プロセス重視することと、内容を軽視することは同義。
レベル低くて笑える。
それ素振りやっただけで上手くなった気分になって満足してる奴らの話だろ。
まぁ好きにしたらいいよ。

77 ：11/12/30

プロセスを突き詰めて問題が解決するなら
docomoの障害は起きなかっただろう

78 ：11/12/30

無駄なプロセスばかりが増えていく。
内部統制とかいい例。

79 ：11/12/30

プロセスを突き詰めても
人間がある以上トラブルは発生する。
だがプロセスがなければ
もっと多くのトラブルが発生する。

80 ：11/12/30

>>73が自分で言っているように
＞低レベルでの開発プロセス定義なんて、最低以下の人間に
＞最低限の仕事させるためのもんだよ。
こういうことなんだろう。
そもそも最低の人間を使わなければいいのに。

81 ：11/12/30

自称上級者が簡単なことを
やらないからいけないんだろうな。

82 ：11/12/30

低レベルの人間大量に投入してプロジェクト上手く回すのがプロマネの仕事です。
レベル高い人間を集めるられることを前提に計画建ててる時点で破綻してる。

83 ：11/12/30

>低レベルの人間大量に投入してプロジェクト上手く回す
ってのは可能なのか？

84 ：11/12/30

>>82
ソフトの世界は量ではなく質なので
その方法では一流になれません。

85 ：11/12/30

質の良いソフトがビジネス的に成功した例は皆無だよ。
WindowsとかOracleとかのバグの多さを見れば明らかだろう。

86 ：11/12/30

ビジネス的に成功　と　バグの多さ　にどういう関係が？

87 ：11/12/30

>>85
低レベルの人間を大量に集めて
WindowsとかOracleを作れると思ってるなら
おめでたいな

88 ：11/12/30

質より量を重視した結果バグだらけになっても、多機能を売りにビジネス的には成功するって話。

89 ：11/12/30

>>87
本気で高レベルの人間が、少数精鋭で作ってると思ってるなら頭おめでたいですね。

90 ：11/12/30

人が大量にいないと作れんが
その人達は全員がある程度高レベルの人間でないと作れない
特に優秀な人が必要なのはプログラマレベルだろう
例えば日本のゼネコンシステム会社にMFCとか.NETライブラリとか作れるか?
上流工程(藁)SEには作れないし、寄せ集めプログラマ作れるものではない

91 ：11/12/30

Microsoftはバグですらビジネスに利用して一流になったわけだし。
新しいバージョンではバクやセキュリティホールが治って価値が上がってる、だから新バージョンを買ってくれってね。

92 ：11/12/30

残念ながらOS作ってる奴らの大半は、寄せ集めの短期契約プログラマーだよ。

93 ：11/12/30

え、マジで？
デビッドカトラーとかは伝説なの？

94 ：11/12/30

>>92
正社員か下請けか派遣かとかの所属のことを言ってるんじゃないよ

95 ：11/12/30

著名な人間の間違いは指摘できないから、それが正式な仕様としてドキュメント化されるプロセスが定着してしまったんだろうね。
今のwindowsは糞仕様が多すぎる。

96 ：11/12/30

「仕様がクソ」と多くの人が言うが、「どこがクソ」かを言う人は少ない

97 ：11/12/30

>>96
そいつが、そういう仕様になってる理由を理解できる頭がなく
分かってないだけのことも多い
単に自分の分担分の作業が増えて面倒だというだけの理由の場合もあるな

98 ：11/12/30

バグ報告のサイトで散々言ってるから。

99 ：11/12/30

>>87 >>90
多人数大規模の開発ってのをなんか勘違いしてるでしょｗ
まず前提条件として、大規模っていうの数万、十数万人月という工数で
すごいプログラマが通常の10倍の生産性だったとしても
1000ヶ月、83年、そんなに時間かけられますかって話なんだよ。
WindowsとかOracleとかそんなのは難しいだけで工数はそんなに必要ない。
簡単だけど工数は大きいという仕事のほうが世の中には多いんだよ。
OSやDBMSなんて殆どの人は使うだけで作ったりしないでしょ？
そしてOSやDBMSを使うだけの仕事に、OSやDBMSを開発できる人間を
担当させるのは、どう考えても仕事の振り方間違ってるよね？
そして仕事である以上、納期とコストの事を考えないといけない。
工数から考えて、少数のすごいプログラマだけで作れる期間は与えられない。
なら、すごくないプログラマを投入するしかない。これは絶対条件。
じゃあどうするか。ここまで考えてものを言ってる？

100 ：11/12/30

>>93
戦うプログラマー読んだけど、優秀な人間を大量に集めてやっとNTが作れた
からな。　アレで分かったことは、大規模開発には大量の人が必要です、
可能な限り優秀な人間が大量に。ただ人を入れればいいというわけでは
ありませんってこと。　人月の神話で言われてる、人を入れてもロスが多い
云々ってのをロスがあっても優秀な人間で底上げするっていうこと。

101 ：11/12/30

> 可能な限り優秀な人間が大量に。
それは現実的ではない。
そんなに人捕まえられないし、
優秀な人間はコストがかかる。
俺が提案する方法（普通の方法だが）は
システム全体を難しい部分と簡単な部分に分離していく。
難しい部分は優秀な人間が、簡単なところは技術力が低いプログラマが。
Windowsみたいにいくらでもコストが掛けられるような場合はいいが
実際はこういうふうにして行かないとやっていけないでしょ。

102 ：11/12/30

システムに簡単な部分と難しい部分があることに
気づかない人って理解出来ない。
一人でシステムすべてを作っているからその違いを考える必要がないのかな？
上級プログラマ、つまりアーキテクトとしての力があると自然とシステムを
難しいコアの部分と簡単な末端部分に分けると思うんだが。
コアの部分は重要だけど規模としては小さくなる。末端部分は簡単だけど数は多い。
普通こうなるし、こうなるように設計するはずなんだ。
そしてシステムを分離した時、他に人がいるなら簡単な末端部分を
アーキテクトである自分がやるのは効率が悪い。
一介のプログラマで十分って気づくよね？
これが最適化されたシステム開発の姿だと思うんだが。

103 ：11/12/30

80:20の法則ってのがある。プログラムのパフォーマンスの80%はソースコードの
20%が出しているっていうやつ。オフショアに出して安く上げることを考えるに
しても、そういうコアな20%の部分を自分の所でキープ出来るかでプロジェクトの
成否が別れたりする。たいがい、まとめてドーンて出してドーンて失敗するん
だけどね。

104 ：11/12/30

80歳まで20本の歯をｷｰﾌﾟって歯無し

105 ：11/12/31

そもそも大規模な仕事をやる必要があるのか？
金掛けて糞積むようなもんでしょ。

106 ：11/12/31

金さえあればどんな仕事もやる必要はないよｗ

107 ：11/12/31

>>105
この業界に生きるものとしてそれを言ってはいけないwww
俺らが生活できるのは誰のおかげかwww
あるテーブルの値を合計して別なテーブルに書きこむとかいう処理を
何十万かけて作って、それを何百本と作って、何十億円の巨大プロジェクトとか
作ってて虚しくならないかと思うんだけどだけど >>99 とかはそういう巨大さに充実感を感じるんだろう
実際に稼働することで開発費以上の利益を生むわけだし、お客が納得してれば別にいいんだけど

108 ：11/12/31

>>107
充実感？
お前の個人的な基準を人に押し付けないでね。

109 ：11/12/31

>>107
俺にとっての充実感は多くの人を管理して
少ないコストで大規模なシステムを作り上げること。
末端の作業をやって充実感があるわけ無いだろｗ
そんなものは部下にやれと命令する。これもまた充実感。

110 ：11/12/31

ソフトは
大規模 = 価値がある
わけじゃないんだよね。

111 ：11/12/31

Gmailはシンプルな仕様で工数的にはそんなに掛かってないはず
でも世界中の人が利用してる。
これからの時代、SIerも淘汰が始まると言われている。
金持ちに粗悪品売るような商売も長く続かないだろう。

112 ：11/12/31

請負やってりゃ客の金をたくさん取るのが正しいんだろうけど
それがソフトのあり方だと思わないで欲しいね。
自社サービスやってればそんな発想は出てこないだろうに。

113 ：11/12/31

>>110
そんなの当たり前だろｗ
なんでそんなことを言うのかしらんが、
もしかして、大規模なら価値がないとでも
言いたいのか？

114 ：11/12/31

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

115 ：11/12/31

>>113
大規模 = コンパクトにする努力をしてない
と思う。

116 ：11/12/31

>>114
規模が大きければそうせざるを得ない。
ただ、その規模必要なの？

117 ：11/12/31

docomoの障害だってそうだよな
何重ものいらんチェック付けて工数増大させてる割には
肝心なところが抜けてる

118 ：11/12/31

>>115がすべて
規模の大小なんて大した問題ではない。
努力が足りないだけ。

119 ：11/12/31

>>116
規模の大小に関係なく、
開発期間とコストを下げるには必要なこと。
大規模ではもちろんのこと、小規模であっても
小規模なら会社も小さく、優秀なプログラマを雇う金もないし
人も来ない。
最初から技術力が高い人を手に入れられるわけじゃないんだよ。
金があったとしても、必要なときにすぐに来てくれるわけでもない。
それが現実。

120 ：11/12/31

>>117
そうだよね。
難しいコアの部分と簡単なところを分離してないからいけない。
docomoなんかは、コア優秀な人を十分に割り当てられなかったのが原因。
大会社になれば優秀な人は社内のどこかにいるはず。
そういう人がつまらない仕事をしていたのだろう。
コアと簡単な所を分離する。こがまさに大規模なものを
コンパクトにするということだよ。
そして少数のコアと多くの簡単な所に分けられる。
そして優秀な人の仕事を減らしつつ、簡単だが量が多い所に
適当に集めた人材を大量投入する。

121 ：11/12/31

神は細部に宿る
これはソフトにも当てはまると思う。
簡単だからといって適当な仕事をされたら、たまったもんじゃない。
アーキテクトの目が届かない範囲にまで規模が膨れたら
それはもう分を超えているのではないか。

122 ：11/12/31

プログラマとして、自分の受け持つ設計やコード等に神を宿す努力をするべきだが、ビジネスの場にそれを持ち込むのは、切り分けができていない二流。
全体のレベルが高くある必要があると思うなら、均一なレベルにできるシステムを考えろよ。(そもそも、俺が考えた最強のが多い気がするが)
お前らは、自分ができる奴だと思いたい、出来ない奴を叩きたいだけで、実際はご近所さんで毎日集まって愚痴ばかり並べてる様なそこらの主婦となんら変わらないクズなんだよ。

123 ：11/12/31

>>115
100万行のコードをいくらコンパクトにしても一万行に収まるわけじゃないからなぁ。

124 ：11/12/31

>>111
> Gmailはシンプルな仕様で工数的にはそんなに掛かってないはず
> でも世界中の人が利用してる。
お前みたいに、UIだけで中身を判断する馬鹿がいるから苦労すんだよ

125 ：11/12/31

>>114
横レスになるが、自分も同感だね
>>123が現実だから

126 ：11/12/31

>>124
中国意外な。

127 ：11/12/31

>>114
理念としては正しい方向性であると思う
というか、昔から同じような事は言われてきた
では、そんな当たり前の事を実践できていないプロジェクトが現実に多いのはナゼか？
という話になる
自分の想像を二点挙げる
まず最初に、>>114では「優秀」という単語が何度も使われているが、
この優秀度を定量的に(=公平かつ正確に)計測するのが難しい点
いわゆる自己申告というものはアテニナラナイ
次に、それら稀少かつ優秀な人材を「開発に着手する前に」最適に配置するのが難しい
まだシステムが形になっていない段階で最適な配置を決定するのは、
高度な未来予測(いわゆる「見積もり」)能力が要求される
また優秀な人物でもすべての分野で完璧という訳ではなくて得手不得手な分野がある
そして優秀な人物は自己過信になりがちだから、ここでも自己申告はアテニナラナイ

128 ：11/12/31

よくある失敗パターンが、システムのコア部分は精鋭を集めて作れたんだけど、
人数集めて作り始めた周辺部分がぐだぐだになってしまうというやつだな。
ユーザの要望や度重なる仕様変更に晒されて肥大していくのは周辺部分なんだから、
ここに大規模ソフト開発や膨大な仕様の把握などに対応し切れない人を当てると
ぐだぐだになる。

129 ：11/12/31

目に見えない制御部分が優れていることより、目に見えるUIが優れていることが優先されるからな。

130 ：12/01/03

>>96
いろいろとあるが、
OS領域と、ユーザーアプリケーション領域、ユーザーデータ領域が、明確に別れていない部分が糞。
OSが不安定になって再インストールとか、それによってユーザーデータが消えるとか、アプリケーション一つずつ入れ直すとか本来あり得ない思想が前提になってる。

131 ：12/01/03

>>130
それは *** Windowsが糞 *** という話だね
すべてはレジストリが癌になっている

132 ：12/01/03

>>131
お前、レジストリがシステムデータと
ユーザーデータでファイル自体分離されてるの知ってる？

133 ：12/01/03

>>130
それはお前がフォーマットして
インストールするから消えるんだろｗ

134 ：12/01/03

>>132
システムデータとユーザデータの分離なんて当然の事だろ
レジストリが癌なのは、集中型データベースかつバイナリ形式で保存されること

135 ：12/01/03

>>134の名前欄を訂正
X: 130
O: 131

136 ：12/01/03

>>134
ユーザーデータがレジストリとして管理上分離されてても、それのバックアップをとって他環境に復元出来なけりゃ意味ないよ。

137 ：12/01/03

ユーザー用のレジストリファイルならコピーして
他環境に持って行って普通に使える。

138 ：12/01/04

可能ではないけど手間が段違いだからな
しかもあまり一般的じゃないから情報も少ないし保障もない
そういう事が考慮されていない糞設計ってことには違いないよな

139 ：12/01/04

>>41-44
ワロタエナイ
文書表現ばかりこだわる奴が炎上プロジェクトに投入されると、ますます燃え盛るw

140 ：12/01/04

>>138
じゃあ、一般的に
レジストリをエクスポートして
インポートすればいいだけじゃね？
何難しく考えてるのよｗ

141 ：12/01/04

要件定義がぜんぜんできてない段階で、設計書に着手してるアホばっかだから、
設計書を書いてそれを客に提示して、お伺いを立てるなんて発想が出るんだよ･･･。
だから設計書も設計ではなく要件を書くようになっていって、
肝心の部分がぜんぜん詰められてない状態になって、ただのゴミドキュメントと化す。
全部爆発しろよもう！
っていう愚痴

142 ：12/01/04

>>141
「お客は いったいどんなプログラムを作って欲しいのか、
　そのプログラムの仕様を自分でも理解していない」
「プログラマは客の要求する仕様に合わせてプログラムを作るのではなくて、
　自分の作ったプログラムの仕様を客の仕様だとごまかしている」

143 ：12/01/04

http://local.joelonsoftware.com/wiki/ビッグピクチャー

144 ：12/01/05

>>141>>142
何でみんな作る前に仕様を決めたがるんだろうね
作りながら仕様決めながら要件定義するスパイラルでいいじゃん
やたら細部の体裁にこだわってる仕様書を改訂する作業は面倒だと思うが
プログラマまで仕様変更を嫌がるんだもんな

145 ：12/01/05

>>141
客が設計書を出さないと要件は言わないってさ
しかも要件に合わせて設計書の修正は禁止
>>144
プログラマの立場で仕様変更を嫌がる理由は大抵は仕様改悪にしか見えないから

146 ：12/01/05

>>141
SI側も客自身も業務を理解してないし、
どういう仕組みを作ればいいかも明確じゃないんだろうね。
漠然と市販ソフトみたいにシステム入れれば、コストが削減できるとか思ってる。

147 ：12/01/05

要求定義書→総合テスト
基本設計書→結合テスト
詳細設計書→単体テスト
設計書にはテスト項目の定義を書く。
テストは設計書の内容が確実に実装された事を確認する。
テストってのは、外部から見た動きだから、設計書も
内部的なとこはわりとどうでもいいんだよね。

148 ：12/01/06

>>145
設計書ださないと要件ださないって、、順序おかしくね？
設計書じゃなくてそれは提案だとおもうのだけど 、先に設計書つくらせるのは大手なら先行着手でコンプライアンス違反だな

149 ：12/01/06

>>148
頭の悪い客に付き合わされてるんだろ

150 ：12/01/06

作る物も教えずに設計図出せってw
マジシャンじゃないんだからw

151 ：12/01/06

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

152 ：12/01/06

それは設計じゃなく要件定義だろ

153 ：12/01/06

>>151,152
See >>142

154 ：12/01/06

>>153
だから、要求を洗い出して、客に提案して、合意をとった上で始めて設計が固まるだろ。
その安価は何が言いたいんだ？

155 ：12/01/06

要件定義で画面レイアウト決めるのは要件定義ですか？

156 ：12/01/06

>>151
あとそれ、サンプルと提案書な

157 ：12/01/06

外部設計と内部設計の話を混ぜるな

158 ：12/01/06

画面仕様を設計だと言い張るSEがいたなぁ。
自分が設計までしたんだから、あとはPGの仕事だと。

159 ：12/01/06

今できる最適解は、
プロジェクトやメンバの性質にマッチした仕様書・設計書を適切なタイミングで作成すること。
これに尽きる。
必要な成果物は常に考えながらプロジェクト遂行しなければならない。
成功プロジェクトや経験だけに頼ったやり方はダメ。怠るとデスマ確定。
嫌なら法整備して厳格にすべき。この産業はいつになったら法整備されんだよ。

160 ：12/01/06

合意をとった上で始めて設計が固まる　と思ってるなら、まだ青臭いな。
合意はその時点での合意でしかない。

161 ：12/01/07

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

162 ：12/01/07

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

163 ：12/01/07

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

164 ：12/01/07

>>159
法整備って、何を定めるんだよw

165 ：12/01/07

>>163
結局、金ある所からなーなーで仕事もらうのが一番無難に儲かるという。

166 ：12/01/07

>>159
>プロジェクトやメンバの性質にマッチした仕様書・設計書を適切なタイミングで作成すること。
「性質」やら「適切」とやらの定義が曖昧だね
これが
>成功プロジェクトや経験だけに頼ったやり方はダメ。
の典型例なのかな？
しかも
>必要な成果物は常に考えながらプロジェクト遂行しなければならない。
という精神論
たぶん>>159の担当プロジェクトは、いつも
>怠るとデスマ確定。
なんだろねw

167 ：12/01/07

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

168 ：12/01/07

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

169 ：12/01/07

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

170 ：12/01/07

デスマに必要な要素っていうと
-要件をまとめ切れない、仕様を確定できないままずるずる時間を無駄遣いする
-実現不可能な妄想をして手戻りを起こし時間を無駄遣いする
-時間がないや知識不足で仕様書を作成できず、実装担当に情報を渡さない
-スキル不足で実装ができないか大幅に遅れ、テストや改修時間がなくなる
こういうのがあるんじゃないかなと思うけど、
考えてみたらうちの職場は上3つが全部当てはまってる素敵なところだった
そんな状況で工数が不足し、新人投入しはじめたから4番目のもヒットしそうな勢い
やったね！

171 ：12/01/07

>>168
あー…書き方わるかったかな。
カチカチのほうが確実な見込みが取れるから安全だけど、わがままな客やあまり頭の良くない客だとしても、利益が見込まれるなら受けるって話。

172 ：12/01/07

デスマってるところは、大概何も考えずに
行き当たりばったりでコーディングしてる。
Railsとかフレームワーク使えば簡単に作れるとかいって
フレームワークの正しい使い方も調べずに
へんなやり方でトライして動いた、じゃあOK。で進めてる。
簡単に作れるというのも考えものだよ。
何も考えずに動いてしまうってことだから。
でへんなやり方になっていって、デスマに陥る。

173 ：12/01/07

本来は設計レベルを担当する人が
フレームワークの正しい使い方、ベストプラクティスを調べて
それを下っ端のプログラマに伝えるべき。
だから設計者はプログラミングを高いレベルで習得してなければならない。
デスマってるところは、設計者はプログラミングをしない。
そして全部下っ端プログラマに任せる。
で下っ端は管理されてない状況で好きかってやって
デスマを引き起こす。

174 ：12/01/07

昔みたいに要件や仕様をしっかりまとめてから開発するというやり方は変化が激しい今は
通用しなくなってる。だから、素早い開発が重要。そのためには拡張性と柔軟性を
備えたシステム基盤を作れないといけない。
この拡張性や柔軟性というのは、どんなものにも耐えられるものが目標だから、
要件や仕様は参考程度確定していればいい。そして作りたいシステムとは独立した、
汎用的な拡張性、柔軟性を持った設計の基盤の実装をシステム開発よりも先に行う。
作りたいシステムは短いコードですぐに実装できるよう、多くのものを汎用的な基盤に持っていく。
そこまで行っていれば、要件や仕様が変わってもすぐに対応できるし、
実現不可能かどうかを試すのもすぐに出来るようになる。
ここまでの説明でわかったとおり、要件とか仕様とかそういう話よりも
今は基盤の実装技術が極めて重要なんだ。そこができてればあとはどうとでもなる。
（正確には、どうとでもなるようなぐらいに基盤を作り込んでおく）
デスマを起こすところは作りたいものだけを考えて、基盤のことを一切考えていない。

175 ：12/01/07

>>171
おまえは何回後付けしてんだよ。
現場にたまにいるわ。
そういう意味じゃないとか言いながら、ジワジワと意味を変えるやつ。
確固たる主張がないなら折れろよ。
言い逃れ野郎は、ひとつ否定されると全人格を否定されてるんじゃないかと思い込むからな。素直に認めろよ。
間違ったことだったとしても認めたらその場だけの馬鹿認定で済むんだぞ？

176 ：12/01/07

>>174
君の考える基盤って、いわゆるフレームワークに限定してないか？
基盤というともっと低レベルだったり、ハードウェア選、インフラ系を含んだりする。

177 ：12/01/07

>>174
変化が早いから素早い開発が要件されてるわけじゃなくて、
金がないから開発期間を短く設定するしかないんだよ。
本来は、3年5年かける規模をわずか半年で開発しているのが現状。
単にゴールを決めて開発してるに過ぎないんだよ。
だから、出荷後や運用開始後に『保守という名目や、改善という名目でバグ修正』
システム開発の世界では、スカイツリー完成に与えられる期間は半年である。

178 ：12/01/07

>>173
システムエンジニアとプログラマを上下関係の階層構造で考えるのは限界があると思うよ
プログラミングを高いレベルで習得してる人と
業務ロジックを高いレベルで基本設計にまとめられる人は別人でもいい
>>174
顧客と折衝し開発範囲と仕様を定義するシステムエンジニアと
それをソフトウェアとして構築するプログラマは別モンてことだな
設計書を書くだけのシステムエンジニアは
詳細設計書見てコーディングするだけのコーダー同様に
要らなくなるかもしれん

179 ：12/01/07

設計にプログラムの作成とかやらせたらダメだよ。
本来やるべき設計に手が回らなくなって、デスマ化する。

180 ：12/01/07

デスマ化するかはお客との調整がすべてだと思う。

181 ：12/01/07

設計者と実装者を別けた時点でデスマ率UP

182 ：12/01/07

>>181
> 設計者と実装者を別けた時点でデスマ率UP
現実問題、人・金がないのだから分けるしか無い。
その場合、設計者がサンプル実装を行なって
それにそったやり方で実装するように決めれば良い。
もちろんレビューも行う。

183 ：12/01/07

>>181
納期までに一人で何でもかんでも出来るなら、苦労しないんだよ。

184 ：12/01/07

>>175
後付してねぇし、言い逃れしてねぇよ。。
言っていることの真意と異なることを返してくるから、細かく答えてるんだろうが。
挑発して勝ったつもりになってんじゃねーぞ。
162で書いた
「会社にとって総合的に利益のほうが上回る事が見込まれるのであれば」
が、何を上回るかって部分をお前は
「カチカチに決めることより利益を上回るなら」
って解釈してイチャモンつけるから
「そうじゃなくて、ビジネスとして利益が上がるのであればという意味だ」
と認識を正してるんだろ。
どこが意味変わっているのか答えてみろよ。
確固たる主張してんだろカス。

185 ：12/01/07

>>184
ま、利益優先や短納期だと、工程ごっちゃにしちゃうのは、よくある話。
技術者に無理強いする訳だから、ほぼデスマ化するよね。

186 ：12/01/07

>>177
いまどき、ソフト開発に3年もかけてたら製品発売した時点で時代遅れだってw

187 ：12/01/07

>>185
それは、利益優先や短納期が悪いっていうより、後出しじゃんけんさせるのが悪いんじゃないの。

188 ：12/01/07

新製品のoffice2000向けのツールを作ってたらoffice2003がでました！どうしましょう？
えぇぃ、再設計だ。とわいわいがやがやしてるうちにoffice2007ﾘﾎﾞﾝになってましてどうしましょう？
で、ちんたら勉強してたらoffice2010で標準装備で、実はﾂｰﾙ無用で済みました。てへ。

189 ：12/01/07

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

190 ：12/01/07

>>187
後出しジャンケンは対応次第で次の開発につながったりするから、一概に悪いとは言い切れない。
対応を誤れば、デスマ化するけどね。

191 ：12/01/07

>>189
実装しかできない奴に渡してもいいような資料を作る方が時間がかかる。

192 ：12/01/07

既に火を噴いてる状況なのに、横から口出してきて
更にいらんことやらせようとする、自称優秀SEがさらに引っ掻き回してくれそうな予感がするこの頃。

193 ：12/01/07

>>191
仕事を誰かに割り振るようにできないと
一人に負担がかかり過ぎて、うつ病や廃人になるぞ。

194 ：12/01/07

設計を誰かに渡してしまえばいい。

195 ：12/01/07

そうか折衝や設計から外注にやらせればいいんだ
不況で人余ってるから買い叩けるし
失敗したら責任取らせて別の会社にやらせればいい

196 ：12/01/07

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

197 ：12/01/07

だから最後は誰かが必死に仕上げるんだ
俺ら孫受けがな

198 ：12/01/07

で仕上がるのか？

199 ：12/01/07

>>195
実際はそのとおり。
だけど、それだとお前が間抜けないよな。
って訳で、1枚邪魔がはいるのよ。

200 ：12/01/07

>>184
どうした？図星すぎてテンパったか？

201 ：12/01/07

>>200
お前の人格まで否定しないから、反論してみろよ。

202 ：12/01/07

図星と指摘することが反論そのものだろｗ

203 ：12/01/08

ゆとりは会話もできないのな

204 ：12/01/08

>>201
やっぱりね。おまえは打たれ慣れてないっつーか、社会に揉まれてないっつーか、そんなところだな。
経験浅いから使ってる言葉に重みがねーんだよ。
後出しジャンケンの意味も履き違えてるみたいだし。
聞きかじった言葉だろ？
すぐに感情的な反応するとこ見ると
あながち間違いじゃなかったみたいだ。認めろよ。

205 ：12/01/08

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

206 ：12/01/08

※関係ない人ごめんなさい。
>>204>>205
話の流れをいったん整理する
設計してから要件を定義するという話をしていたから、俺が
「それは設計ではなく、要件を定義するために顧客から要求を引き出す作業であって、
要件が明確化して、機能が確定した段階ではじめて設計が固まる」
という話をしていたわけだ。
そこで、お前が
「合意をとった上で始めて設計が固まる　と思ってるなら、まだ青臭いな。
合意はその時点での合意でしかない。」
って頓珍漢な横槍を入れたよな？(本人？)
合意を取ったことに対して"その時点での"設計が固まって、
後で変更を依頼されたら、仕様変更で再設計だよな？
で、俺が返したのは、
「"俺が"初期段階の決定事項が全てだと思っているわけではなく、
設計と要件定義の区別がついていないやつがいるからそういう答えをした。
会社として利益が見込みがあるのであればそういう仕事もする。」
で、お前が
「カチカチの行程のほうが開発会社の利益になる。
臨機応変に対応したら仕事が減る。」
で、俺が
「カチカチのほうが確実な見込みが取れるから安全だけど、
実際には利益が見込まれるならそういう客にも付き合う。」

207 ：12/01/08

で、お前が
「話を後付けするな。確固たる主張がないなら折れろよ。
言い逃れ野郎。人格否定されてると勘違いするな。素直に認めろよ。」
で、俺が
「>>162で書いたことの意味を正しく認識できていない。
カチカチにするより利益が上がるという意味ではなく、
利益が上がるなら仕事として受けるという意味。」
で、お前が
「どうした？図星すぎてテンパったか？」
で、俺が
「お前の人格まで否定しないから、反論してみろよ。」
で、お前が
「図星と言ったのが反論。」
「経験不足にみえる。言葉に重みがないからわかる。
言葉づかいも間違えている。図星だろ認めろよ。」
「お前の心の中なんか知るか。最初から真意言え。
利益優先だとか工程ガーとか、そんなんじゃ仕様書いたことあるかどうかも疑わしいわ。
背伸びしなくていいよ。等身大でいいんだって。」
ここから、返信 ← new!
「真意って言ったけど、書いてなかったことではなく書いていたこと。
お前が話しの流れを読めていない上に、どんどん話をずらしていった。
そして、図星が反論になっているという意味がいまだにわからない。
冷静に自分のレスとスレの進行を眺めなおしてこい。」

208 ：12/01/08

そろそろダルいのと、もうだいぶ他の人に迷惑かけてるから、
次で誤解が埋められなかったら終わりにしよう。

209 ：12/01/08

こうゆうやつらがいたらデスマになりそう

210 ：12/01/08

細かい事はいいんだよ見たいな奴は危険。
また、一見細かく見えてどんどん話がずれて行く奴も危険。

211 ：12/01/08

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

212 ：12/01/08

>>207
あんたまたやらかしてるよ。。認めればいいのに。
頭凝り固まってる。

213 ：12/01/08

>>212
相変わらず、何の具体的な指摘も反論も出来ないのな。
という事で終わりな。

214 ：12/01/08

>>209
PM,PLだったら最悪だな。
特に行き詰まったときに、精神論や人格論ばかり振りかざす奴。
うつ病患者量産するからな。
PEだったら、チームから外してもらうよ。

215 ：12/01/08

そろそろ仕様書、設計書の話に戻そうぜ。

216 ：12/01/08

相手の意見なんて一切お構いなしに、自分の信念に基づいた見えない弱点を作り出して、
そこを突くことで勝ちに浸る、って奴はどこにでもいる
そもそも発端が、憶測から相手を過小評価することで気持ちよくなりたい相手なんだろ
んなの、いち早くレスする価値がない相手だって気づいて、スルー決め込むのが最適解だわ
わざわざ同レベルで争い続けるから、無駄レスが続くんだよ

217 ：12/01/08

>>216
自分に言え

218 ：12/01/08

>>204
やべぇ、こういうおっさんうちの職場にいるわｗ
こいつの書く仕様書が半端じゃなく使えないけど、声でかいからみんな困ってる

219 ：12/01/08

反論しなければ周りにバカ遺伝子撒き散らすし、やりあえば不毛だし、生きている事自体が害でしかない。

220 ：12/01/08

討論はどんどんすべきだし、途中まではいい感じだったけど
人格否定が始まったら終わりにすべきだな
「現場にたまにいるわ」のあたりからディベートとして成立しなくなったな

221 ：12/01/08

仮想敵設定を誤るとこうなる

222 ：12/01/08

はいはいぬるぽ

223 ：12/01/08

2chに何か期待した時点で負けだろ。

224 ：12/01/08

自分の書き込みに、全部同一人物がレスしてると思うなw
ここはIDもついてない板だぞ
IT開発者は少しくらいはアスペルガー気味なところがあっていいけどもちょっとは気付け
ちなみに >>144 >>168 >>174 >>178 とかは同一人物
>>168 の書き込みが悪かったな。
>>162のカキコの意図を取り違えていたよ。ていうか半分は論点ずらしだったわけだが
それも2ちゃんだ

225 ：12/01/08

設計書の形式、ExcelもWordもダメだとすると、何がいいんだ？

226 ：12/01/08

最後に頼りになるのはTEXTでしょう。

227 ：12/01/08

jpg

228 ：12/01/08

>>224
現場にたまにいるわ。
詭弁使ってドヤ顔してるやつ。
確固たる主張がないなら折れろよ。

229 ：12/01/08

>>224
ごめんなさい。
「確固たる主張がないなら折れろよ。」
って言って見たかっただけです。

230 ：12/01/09

そもそもマイクロソフト様は設計書は何で書いてるんだろうな？
まさか、Word？

231 ：12/01/09

Excelは保守を考えないなら楽だけどな

232 ：12/01/09

>>230
HTML

233 ：12/01/09

>>232
技術資料は全てMSDNとして公開されるわけだからHTMLだな。

234 ：12/01/09

>>231
保守は、設計書の保守って意味？

235 ：12/01/09

>>233
ということはhtmlは何で書いてるの？
メモ帳？Ｗord？

236 ：12/01/09

ホームページビルダーだよ

237 ：12/01/09

プロが包丁でじゃがいもの皮を向いていても
一般の人は皮むき器でいいと思うよ。
真似することはない。

238 ：12/01/09

>>235
独自の管理？ツールがあるんだろ。
ドキュメントコメントと関連付けられたフォームに、
入力するとMSDN生成してくれるやつが。

239 ：12/01/09

>>238
ドキュメントコメントって設計書か？
少なくともソースが存在しない時点では書けないよな？

240 ：12/01/09

>>236
他社製品www

241 ：12/01/09

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

242 ：12/01/09

>>235
HTMLはVisualStudioでだ。

243 ：12/01/09

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

244 ：12/01/10

>>243
それは、HTMLとCSSが使いこなせていないからでは…？

245 ：12/01/10

ﾈｽｹの4がﾃﾞﾌｫだった時代のｵｼﾞｻﾝなんだけれど、今からHTMLとかCSSとか覚えようとしたら
どっから覚えたらいいんだ？ ﾃｰﾌﾞﾙとTRとTDで組むとかしたらｼｰﾗｶﾝｽ級の扱い受けるんだろうなぁ

246 ：12/01/10

CSS3使えばいいよ。
テーブル使う理由の3カラムレイアウトとか
やっとCSS3に含まれることになったから。
http://www.htmq.com/css3/column-count.shtml
対応しているブラウザはまだないけどなｗ

247 ：12/01/10

レビューの議事録って誰が書いてる？
レビューされる人(設計を説明する人)？レビューする人(レビューアー)？

248 ：12/01/10

特に決めてないけど、される方が書いてるかな。

249 ：12/01/10

テーブルレイアウトは、方眼紙の延長だわな。
それだけである程度のレイアウトができてしまうから、
それぞれに適した手段を一つ一つ学ぶ手間がかからないので、馬鹿でもなんとかなる。
HTMLは文章や単語に文字で表せない意味付けをするためのもので、
スタイルシートはその文書などの部品をどう配置するか、どういう見た目にするか、
みたいなただのの設定だから、誰でもすぐ覚えれるし、別に難しいことはないはずなんだけどな。

250 ：12/01/10

>>247
れびゅーいが書いてれびゅーあが確認するって事が多いんじゃないかな
指摘事項とかを書き出して、対応内容まで書いて、対応してるかどうかを確認する、って流れになるだろうし
どうでもいいけど、このレビューイって呼び方がなんかこう好きになれない
ｷｬﾊﾊ ﾚﾋﾞｭｰｲ

251 ：12/01/10

>>249
CSSには長らく段組という機能が無かった。
また角丸を実現する方法もなかった。
結局は、段組用、角丸用に調整したHTMLを書かないといけず
それを実現するためのテクニック（バッドノウハウ）が必要なので
難しいものとなってる。
CSSは要求するデザインを満たせるものではなかったんだよ。
十数年たってこれからやっとましになるかなってのが現在の状況

252 ：12/01/10

>>245
なぜそのような発想になるのでしょうか

253 ：12/01/10

ﾈｽｹの4がﾃﾞﾌｫだった時代のｵｼﾞｻﾝ　が、Web全盛期の世の中でHTMLを無視してきたってやばいよ。
たとえ、まったく異なる分野の技術者だったとしてもです。
そんなことだから「どっから覚えたら」などという発想になるんです。

254 ：12/01/10

ﾈｽｹの4がﾃﾞﾌｫだった時代のｵｼﾞｻﾝなんだけれど　
の裏に長年苦労してきて、あんたらの知らないことイッパーイ知ってる俺様
って含みがあるから腹立つ。
↓どうしてこれで止められなかったんだ？HTMLを知らない、それだけでいいじゃん。
HTMLとかCSSとか覚えようとしたらどっから覚えたらいいんだ？
ﾃｰﾌﾞﾙとTRとTDで組むとかでいいの？

255 ：12/01/10

>>254
お前、病気じゃないか…？
>>245
今時、Webのフリーツール沢山あるんだし、UIライブラリも沢山あるし、適当に中身覗いてみればいいんで無い？

256 ：12/01/10

納品用にhtml印刷した時に目次とページとかフッターとか入れられますか？

257 ：12/01/11

>>256
CSSでメディアタイプってのがあってそれを使うと画面表示と印刷するときで
ちょっと違う出力に出来る。

258 ：12/01/11

Officeソフトには、オートシェイプ機能があるけど
HTML形式で、オートシェイプと同じように自由に挿入したり、コメント入れたりできるの？

259 ：12/01/11

>>258
SVGでやればいいのでは？

260 ：12/01/11

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

261 ：12/01/11

>>259
SVG対応してるブラウザ少なくない？
それともHTMLで仕様書作るなら、IE9は必須って事なのか？

262 ：12/01/11

そんなの客と取り決めろよ…

263 ：12/01/11

HTML使いこなせないのと使いたくない理由で、言い訳並べてないか…？
ドキュメントの媒体なんて臨機応変に使い分けろよ。

264 ：12/01/11

だからってExcel方眼紙スタイルはないわ

265 ：12/01/11

早くて便利なら、理解できる仲間うちで使う分にはいいだろ。
まぁ、俺は使わないけど。

266 ：12/01/11

xhtml なら簡単に変換できそう。

267 ：12/01/12

xhtmlは出力形式。
何かからxhtmlに出力するのはありだが、
xhtmlから他の何かに変換するものではない。
なぜならXML（データ）にHTML（人間用文書構造）が含まれた結果
データとして処理しにくくなるからだ。

268 ：12/01/12

印刷なんて紙の無駄でしかないと思ってるけど、
印刷が前提ならWordあたり使ってちゃんとやるのが一番手っ取り早いわ
あと、ただの愚痴だけど、番号つき段落で処理途中に挿入されて番号がずれる、みたいなものや
変更点の文字色を変えるような必要になるものを、Excel方眼紙で作るな市ね

269 ：12/01/12

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

270 ：12/01/12

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

271 ：12/01/12

>>269
rest？興味だけで実用してないんだよな。
ツールはやっぱりSphynx？

272 ：12/01/13

>>270
曖昧さを排除したからといって扱いやすいとは限らない。
人間用に手を加えたXHTMLはCSSやJavaScriptで
必要なdivやspanがあちこちはいるから純粋なデータではなくなる。
やってみればわかるが、純粋ではないデータ（それはしばしば変更される）
であるXHTMLからXSLTを使って変換するのは苦痛でしかない。

273 ：12/01/13

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

274 ：12/01/13

>>273
それ、お前の理解力が低いだけじゃないよな…？

275 ：12/01/13

一度書き終えてOK貰った書類を、全部書き直せなんてマジキチ。デスマじゃん。

276 ：12/01/14

>>275
書き直しの理由くらい添えてレスしろよ。

277 ：12/01/14

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

278 ：12/01/14

>>276
ただ一言、『わかりづらい』という理由だったりする。
ユーザー側の設計者だけでなく、誰が見ても何がどこに書いてあり、内容が即座に理解できるようにと。

279 ：12/01/14

それは妥当な理由だ。
理解できない書類作る方が無駄な作業だろ？

280 ：12/01/14

わかってないね
金がとれるドキュメントであることが重要なんだよ
日本のプログラマーは嫌儲なのか
金儲けが下手くそ

281 ：12/01/14

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

282 ：12/01/14

>>278
それは無理難題かもしれないな。
俺も昔やられた。
プログラムと一緒で、ある一定レベルまではわかりやすく書けるのは事実。
(日本語の使い方や、用語の定義の仕方、書く順番等)
ただ、想定する読者の優先度による可読性のトレードオフが発生する。
だから、誰が見ても解るドキュメントなんてない。
まずやるべきは、ドキュメントが誰にどのように使われるのかを定義する事。
次に、前提とする読者の知識レベルを定義。
次に、読者が複数いる場合、優先順位を決める。
相手の立場になって考える事は重要だが、無理なものは無理だ。
から、先に予防線をはる。
そういう文句を言う上司は多い。

283 ：12/01/14

>>277
何に使われるドキュメントか理解してない事が原因だな

284 ：12/01/14

そういう見た目や体裁、文体への指摘は、
レビュアー側が自分の好みでレビュー結果のブレが出るから、一概にどっちが悪いとは判断できないな
書式を厳格にするなら、プログラミングでの制約などと同じように
個々の裁量にまかせず仕組みで解決するのが最適解なんだけどな
言語みたいな感じで共通の書式がほしいわ
そういう金に直結しないドキュメント整理に費やす時間が勿体無い
いろんな人が見るようなマニュアルとかだとそりゃちゃんとやるべきだけど
業務系の割と簡単なWebシステムとか、万人が確認するわけでもない
仕様まわりの内部向けドキュメントとかでそういう事繰り返して工数削ってるのは、すごく無駄を感じちゃう
その体裁まわりの時間で、モック作ったりそれでUI検討したり、実装したりテストしたりしたほうが有意義だろうに…

285 ：12/01/14

俺自身は、本当に誰にでも理解できる設計書が存在するとは思ってないが、
受け入れを行う顧客担当者が考える「誰にでも理解できる設計書」を求められる。
結果として、顧客担当者が納得するレベルかどうかを手探りで設計書を作るわけだが、
俺はそいつじゃ無いので、何度も何度もやり直しを喰らうハメになる。

286 ：12/01/14

>>285
顧客担当者が考える「誰にでも理解できる設計書」の段階で、だいぶ無理があるよな。
審査する人間がどの程度スキルや経験持ってるか分からないから
初心者向けに書くのか、経験者向けに書くのか凄く曖昧なんだよ。
大抵、見積時点では後者向けのドキュメントを想定してるみたいだけど、
開発が進むにつれて人数増えてくると、初心者とかいろんな人間が混じるから、
より詳しいドキュメントが必要になってしまってる現実もある。
俺は、設計書渡されたPEがプログラム作れる最低限必要な条件や項目が記載されていればいいと思ってる。

287 ：12/01/14

>>285
そもそも顧客担当者が理解不足をドキュメントのせいにしている可能性もあるな…

288 ：12/01/14

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

289 ：12/01/14

>>288
具体的に指摘してもらって、そこだけなおせ。
自分で考えろって言われたらそのまま出して、これで解るレベルの奴を雇えって言え。
両方ダメなら殴っていいぞ

290 ：12/01/14

>>288
レベルの低い担当者だと、自社の業務の流れすら分かってない奴もいるからな。
そんな奴にまで分かる設計書書けとか言われても困るw

291 ：12/01/14

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

292 ：12/01/15

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

293 ：12/01/15

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

294 ：12/01/16

プログラム仕様書をA HotDocumentで作るから使い方を調べとけといわれてる
で、やってみたら〜.designer.vbを読み込んでくれない
やり方わかる人いたら、教えてくださいな

295 ：12/01/16

HotDocumentは仕様書を作るものではなく、
仕様がわからないソフトの解析の
ちょっとしたヘルプができるかな？みたいなもの。
あとは、客にこんなに作りました！って
騙すものだから、
designer.vb程度読めなくても
いいじゃないかアハハハはは

296 ：12/01/18

>>293
それでどうやってプログラム作ってるの？

297 ：12/01/18

>>296
知ってる人に聞けばいい。

298 ：12/01/18

知ってる人「知らない」(嘘)
とか、平気であるけどな。
人格破壊の負のスパイラル。

299 ：12/01/18

できるできないじゃない。
やるんだ。

300 ：12/01/18

>>299さんがこわいです。

301 ：12/01/18

>>299
とりあえず仕様固めて頂けませんかw

302 ：12/01/18

r.vb程

303 ：12/01/20

みんなはＤＦＤとか書いたりしてる？

304 ：12/01/20

書かない。そんな暇はない。

305 ：12/01/20

DFDって、書きにくくて分かりにくいと思うけど。
業務フローならアクティビテ図がいいと思う。

306 ：12/01/20

なんだろう、よくUMLを既存のダイアグラムのスーパーセットのように捉える意見を見るが、そもそもの視点・指向が違うしな。
こっちの方がいい、いやあっちの方がいいという意見は首肯し辛いな。

307 ：12/01/20

と思ったが、ちょっと穿った見方だった。すまん。

308 ：12/01/20

いや、事実宗教戦争になりつつある

309 ：12/01/20

単なる民族間抗争だろ。

310 ：12/01/20

アジャイル開発やってる人は何をドキュメントに残しているんだろ。

311 ：12/01/20

色々。プログラムに関するドキュメントは殆ど書かないけど

312 ：12/01/21

色々って？

313 ：12/01/21

赤とか青とか

314 ：12/01/21

立体的に見えるやつだな

315 ：12/01/21

ホワイトボードに描いた落書きとか、いっぱい入ってるよ。

316 ：12/01/22

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

317 ：12/01/22

>>316
最終的に確定したら、それはアジャイルじゃないよ。
アジャイルは常に進化し続ける事にメリットがある。

318 ：12/01/22

>>316
そもそも納品をしないから。

319 ：12/01/22

納品しないのは、誰の都合？
少なくとも顧客の都合じゃないよね？

320 ：12/01/22

>>317,>>318
納品しないってことは、準委任契約で開発するってことか？
それでも、内部設計書くらいは残すんだよな？

321 ：12/01/22

自社サービスなら納品て概念が無いんじゃないの

322 ：12/01/22

偽装請負なら、「作業報告書」って言って週報レベルのものを出してもＯＫだよ

323 ：12/01/22

常に進化し続けるシステムを作りつづける方式がアジャイルであるのに、開発費用を抑えたり、要件がまとまらない場合の銀の弾丸みたいな考えでアジャイルやろうとするから、納品物がどうとか話がおかしくなるんだよ。
予算確保→システム作成依頼→納品物受領→プロジェクト終了
これはアジャイルでは無い。
その時々にある予算の範囲内で、無理なくシステムを作り続けることがアジャイルなんだよ。
発注形態なんて作業請負、派遣、定期雇用に決まってる。

324 ：12/01/22

本来はマだけど、最近は見積もりするばっかり。

325 ：12/01/22

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

326 ：12/01/22

http://awabi.2ch.net/test/read.cgi/poverty/1327050821/3

327 ：12/01/25

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

328 ：12/01/25

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

329 ：12/01/25

ウォーターフォールって、ローカル用語か？
それに、アジャイル開発なら少数精鋭でチーム組むんだから、ローカル用語でやってもいいんじゃん。

330 ：12/01/25

>>329
変な略語使うなって事だろ。

331 ：12/01/25

この文脈でWFが何の略語かわからない奴はもぐり

332 ：12/01/25

浮いてる奴はもぐり

333 ：12/01/25

文脈から推測はできたけど、んな略記は初めて見たな。
使うなとは言わんけど、俺々略語って恥かくことあるし、多用はしないほうがいいとおもう。

334 ：12/01/25

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

335 ：12/01/26

自分の勤めてる会社の常識しか知らない人なんだろうね。
井の中の蛙になってる。

336 ：12/01/26

瞬間的にワークフローと読んだ

337 ：12/01/26

井の中の蛙
大海を知らず
知ったところで
　海水じゃぁ蛙は生きていけない
よかったね
　知らなくて

338 ：12/01/26

特許庁の新システムの開発中断のニュース、
原因が東芝ソリューション側の設計遅れになってるけど、
実際のところ、何が悪かったんだろうな？

339 ：12/01/26

ユーザが出す要件が矛盾だらけとか、二転三転したという可能性はないのかな？ とシステム屋を擁護してみる。

340 ：12/01/26

中国の特許を日本語で検索できるシステムなんて、嫌な予感しかしない。

341 ：12/01/26

50億だかの設計料払って、それは回収しないんでしょ？
原因が東芝側なら損害賠償ものだと思うけど、
そうしないということは特許庁の問題で東芝が泥を被ったか。

342 ：12/01/27

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

343 ：12/01/27

管理がアクセンチュアの時点でやな予感しかしない…

344 ：12/01/27

組み込み系開発で
設計書にRAMマップやROMマップを書いてるんだが、
ほとんど見る機会もないのに、載っける必要性ってあるの？

345 ：12/01/27

お前が見ないからって、他の全員が見ないと思い込んでないか？

346 ：12/01/27

俺も見ないぞ

347 ：12/01/27

お前が人からシステム預かって
どれどれプログラム見てみるか、まずはメモリマップから・・・ってメモリマップねえじゃん！
って想像してみろよ、どうすんだよ
メモリマップ想像すんのか？

348 ：12/01/28

仕様書書き上げるまでコーディングはさせんぞ

349 ：12/01/29

>>347
メモリマップ見るより、コード見たほうが早くね？
それと、ほぼCとかで書いてるはずだから、システムによっちゃ
メモリマップはそれほど重要でないことが多いし

350 ：12/01/29

メモリマップは誰かの頭の中だけにあります
なんて状況よりは、ドキュメントに書いといた方がいいだろ。

351 ：12/01/29

>>349
コード見る方が遅いだろ
ROMとRAMくらいの分け方ならまだしも
「ここからここまでは揮発、ここからは不揮発」みたいなのも入ってくると大変だろ
コードにコメント書いとけってのは無しな

352 ：12/01/29

WindowsとかPhotoShopとかの開発ドキュメントってどんなの書いてるんだろう？

353 ：12/01/30

仕様を完璧に決めるために案件とって来た部署を徹底的に問いつめて
少しでも矛盾や未決定事項が見つかったら追い込みをかけ、次の日
朝一で顧客の所にいかせて仕様をきめさせ、持ち帰りになったら毎晩
催促の電話をさせ.... ってやってたらなんかこっちが悪者にされた。
もう仕様を適当に決めて仕様変更を下請けに吸収させた方が気楽でいいことに
きがついた。よく考えたら上流行程にせっかくいるのにわざわざ苦労することないし。

354 ：12/01/30

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

355 ：12/01/30

>>354
そっか・・
その後の手戻りは明らかに少なく予算内にも収まったんだけどな..
今度から多少の仕様の矛盾は目をつぶることにしたいんだが、どの矛盾は
無視してよくてどの矛盾は指摘しないといけないかの見分けが一瞬でつくほどには
まだスキルがないんだよな。

356 ：12/01/30

「矛盾がある・未決定事項である」ってことがわかればそれでいいんじゃね？
どっちに転んでも大した違いが無い項目ならどっちに転んでも大丈夫なように作業進めるし、
そうじゃなきゃ「決めないと作業進まないんですけど」って言ってくるだろ。

357 ：12/01/30

>>356
確かにいわれてから決めればいいんだけど、その間2,3日下流行程を止めていることに
ものすごい罪悪感を感じちゃうんだよね..
むかし止められる立場だったこともあるからなおさら。

358 ：12/01/31

きちんと回る範囲ではきっちりかっちり決めといたほうがいいし、そういう人も一人くらいは居たほうが便利だとは思う
でも人付き合いが下手な人がそれやると、できない連中から敵意向けられたりして
くだらないことで対立始めたりして、あほな気苦労増やすだけになったりするしな
上流のほうはスキルがあるのは最低条件で、人をうまく乗せたり、信頼されるようなとこが重要なんじゃないかな
結果がよくても、悪者にされたのならそのあたりが不足してたってことだと思う

359 ：12/01/31

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

360 ：12/01/31

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

361 ：12/01/31

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

362 ：12/01/31

>>359
>詳細設計書から要件が読み取れないのが厳しい。
それは、詳細設計書の意義から外れるのではないかと思う
詳細設計書は実装の大まかな枠組み(論理構造)を記述するもの
システムの目的/要求/前提といった事柄は、さらに上流の設計書で記述されるべきで、
詳細設計書での重複した記述は避けるべきだと考える
もしも、>>359が「詳細設計書だけ」を渡されて実装段階で悩んでいるのなら、
まずはそれを率直に上流工程の担当者に伝えて、上流の設計書を入手することを考えよう
そして、もしもその要請が拒否されたのなら(「オマヘハイハレタコトダケヤレ！！」)、
それを(証拠として)記録した上で、(>>360の言うように)そのまま実装するしかない

363 ：12/01/31

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

364 ：12/01/31

>>357
未決定事項があれば
依頼側にそれらの情報をいつまでに出せるのかをヒアリングして、
製造側にそれで作業スケジュールに問題が出ないかをヒアリングして、
その結果を整理してスケジュール決めてくのも仲介役のお仕事。
もし一件未決定事項があるだけで作業が何日も止まるようなら、
そもそもそんな作業スケジュール(というよりワークフロー？)がおかしい気がする。

365 ：12/01/31

>>358
できないというか決めないといけないことをそもそも理解していない部署に
その必要性をわかってもらう柔らかい言い方ってどういうんだろうな..
どんな言い方しても相手の考慮不足を指摘している以上反発は食らうわけで
しかものんびり待っていたら1ヶ月以上ほっておかれた過去の経緯もある。
これが組織間の板挟みって言うならそうなんだろうけどなんか違う気がする。

366 ：12/01/31

上長を通じて申し立てる。
個人で動くべきでない。

367 ：12/01/31

>>365
> どんな言い方しても相手の考慮不足を指摘している以上反発は食らうわけで
考慮不足＝ちゃんと考えろやボケェ！
ってニュアンスになってない？
「このあたりの仕様が抜けてるような気がするんで、いついつまでに確認お願いできませんかね〜？(∀｀*ゞ)ﾃﾍｯ」
ってな感じでアプローチしたら、そんなにモメないような気がする。経験上。
そこで決まらなかったら、後は野となれ山となれ〜だよ。
エビデンスだけは押さえといてね。

368 ：12/02/01

毎日、朝と晩に呼び出されて催促されたら、その担当者が鬱病になっちゃうぜ。
お客さんの事情もあるし、すぐに回答できない質問事項もあるだろうよ。
質問の仕方も
「どうするんだ!?」っていう相手に丸投げの質問するより
「A案とB案のどちらにしますか？」って質問した方が
相手を誘導しやすいし、回答を得やすい。
相手に案を提示できるようになるには、それなりの能力が必要だけどね。

369 ：12/02/01

「A案とB案のどちらにしますか？」
客「良くて安い方」

370 ：12/02/01

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

371 ：12/02/01

>>370
世の中には進捗表に優先度の項目があるけど、それが全て高になっている
プロジェクトもあるわけなのだが。

372 ：12/02/01

アプリの質にもよるが、推奨案まで持って行けたらベストだわね。
決められない人たちに判断基準を示してあげるのも大事だと思うよ。
上流でやっとけや！(#ﾟДﾟ)って話はあるがね。。。

373 ：12/02/01

>>371
俺も見た事あるけどさw
スケジュールの足引っ張る項目を伝えればさすがに優先してもらえるし、ぶつかってたらマネージャーが仕事する番だろ。

374 ：12/02/01

>>372
こっちが考えてやると、次から当然の様に仕事押し付けてくるってのもあるなw

375 ：12/02/01

>>368
たしかに担当者を追い込みすぎる癖があることはわかってる。
特に担当者が最初に「何でそんなの決めないといけないんだ」的な
反応をしてきたときに、徹底的に追い込んだことは何度かあるな。
コミュニケーションスキルは本当に難しいな

376 ：12/02/02

気持ちは分かるがやっちゃだめだ。
頭にきても手を出しちゃいけないのと同じだ。

377 ：12/02/02

足ならいいか！？な？

378 ：12/02/02

反感をもたれるような持ち掛け方をしてるか、
既に嫌われてて煙たがられてるかのどちらかって可能性もある
慕われるように仕向けて、自分からやっとこうって思わせれるようにしたほうがメリットあるのにね

379 ：12/02/02

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

380 ：12/02/02

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

381 ：12/02/02

>>379
お前またはお前の会社は、詳細設計書を渡されて実装〜単体テストのみを請け負ってるのか？
だとしたら、要件への適合性なんか考える必要無い。

382 ：12/02/02

>>379
>(今の現場では)詳細設計書が基本設計書を満たしているか否かのチェックが機能していないんだ。
問題は、詳細設計書から要件を導き出せないことではなくて、これが問題なんだろ？
だったら、詳細設計書をアウトプットする奴らにちゃんとしろと言えよ
それとお前の成果物を受け取る奴の受け入れ基準を聞けよ

383 ：12/02/02

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

384 ：12/02/02

>>382
おそらく詳細設計書を複数人でレビューしてなくて
上流で発生する仕様漏れや間違いが発見されずに
実装させられてるんだろう。
SEがスキル不足でPEが毎回墓穴を掘らされてれば、
自衛手段として実装前に要件を確認して、
設計に問題が無いかくらいは確認するようになるよ。

385 ：12/02/02

>>384
PEって何だろ

386 ：12/02/02

プログラマー

387 ：12/02/02

>>379
設計担当と実装担当が別会社なら、渡された設計書をそのまま実装した方がいい。
自分の仕事以外の余計な事して、コストをかけるのは無駄。
仕様変更があれば、その仕事分を集計して、請求するか交渉の材料にする。
同じ会社なら、
設計が正しいかSE達でレビューをしっかりやってもらうしかないと思う。
あまりにもミスが目立つなら、リーダーや上司に訴えろ。

388 ：12/02/02

>>387
全くその通り。
自衛が必要なら、前工程の成果物の妥当性を再検討するのではなくて、別の手段で。
>>384
詳細設計書かく人をSEと呼ぶですか・・・。

389 ：12/02/02

おっと、超久しぶりにブラウザで書き込んだもんだから、sage間違い

390 ：12/02/02

>>388
詳細設計を素人の客が見るならSEが書いた方がいいよ
PGが書いた詳細設計はいい意味でも悪い意味でも素人には読めません

391 ：12/02/02

そもそも、詳細設計を素人が見る必要があるのか？
何のために見せるんだ？

392 ：12/02/02

詳細設計なんぞお客に見せない（見たがらない）もんだと思ってた(´・ω・｀)

393 ：12/02/02

詳細設計書作成がなかなか進まない
分からないところがあってソースを確認するはずが、気が付いたらコーディングしてる
どうしよう

394 ：12/02/02

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

395 ：12/02/02

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

396 ：12/02/02

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

397 ：12/02/02

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

398 ：12/02/02

>>383
いやな奴や、客観的にみてもその場にいない方がましな奴でも平気で居座るのが
デスマというものなんだが。。
仕事はきついけど連帯感が生まれて現場は和気藹々だとでも妄想しているのか？

399 ：12/02/03

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

400 ：12/02/12

みんなUML使ってる？

401 ：12/02/12

クラス図とかシーケンス図とかよく使うな。

402 ：12/02/12

ユースケース図とかアクティビティ図とかよく使うな。

403 ：12/02/14

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

404 ：12/02/14

>>403
アンカは>>383のタイポかな？
内容については、同感
そういった職場の雰囲気は、リーダの性格によって形成されるのだと思う

405 ：12/02/15

>>403
仲良し同士で低レベルなシステム作って一生喜んでいればいいじゃん。
そのうちインド人に取って代わられるだろうけどね。
本当のチームはチーム同士切磋琢磨するし、自らの責任を果たさない
フリーライダーはあっという間に排除する。

406 ：12/02/15

>>403
お前は草野球。
プロ野球でスタメンになりたければ、人より秀でる必要があるって話。
プロのメンバー選考で手をつないでゴールしても落とされるだけだろ。

407 ：12/02/15

仲良しごっこだろうとライバルごっこだろうと結果が出せなければ意味無いな。

408 ：12/02/15

>>407
その通り。
自分以外の部署の人間が鬱病になろうがそれはその部署のマネジメントの問題。
中ではチームの力を最大限に生かすチームビルディングを行ってマネジメント能力をあぴーるし、
ほかの組織に対しては弱みを見せた瞬間に徹底的に追い込んで弱体化させるのが
組織の中で生き抜く秘訣。

409 ：12/02/16

結果を出すことと組織の中で生き抜くことは全く関係ないな。

410 ：12/02/17

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

411 ：12/02/17

アットホーム()とか、まぁ良くも悪くも日本っぽい事ではあるし、それで成功してるとこもいっぱいある
別に和気藹々やるのがダメだとは思わん
ただ、そういうのを強調する人は、大抵自分から学んぼうとかしないで
低いレベルで仲良しごっこしたがる人が多いからなｗ
仲間意識をつかって停滞することに安心してる、みたいな
無理やりスレタイの話題に振るなら、そういう人が書いた仕様書は、割とひどいｗ

412 ：12/02/18

新人が作った顧客に出す設計書のタイトルが↓だった
〜♪♪　○○設計書　♪♪〜

413 ：12/02/18

客も喜ぶかもよ？

414 ：12/02/18

中身がしっかりしてれば、外見なんて気にしない。
中身がなければ、怒りが増すがな。

415 ：12/02/18

客によるとしか言えないな。

416 ：12/02/19

新人なりに見栄え良く見せようとしたんだろ。
OJTで放し飼いして、ロクな教育してなかった奴が悪い。

417 ：12/02/19

新人だと思ったら４０才くらいのおっさん個人事業者が作った設計書らしい

418 ：12/02/21

ジョエルのファンなんだろ

419 ：12/02/22

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

420 ：12/02/26

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

421 ：12/02/26

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

422 ：12/02/26

管理してないんじゃねｗ
担当が居なくなってから火を噴く、みたいな

423 ：12/02/26

出来上がったソフトの動きが仕様です。

424 ：12/02/26

そもそも要件が定義されていない。
回路図を渡され、顧客とやりとりしたメールの断片が転送されてきて
1ヵ月後までに仕様書と実装とテストを終わらせておけ
といわれる俺は既に色々あきらめている。
某日本で一番入りたい家電メーカのとある職場の風景

425 ：12/02/26

日本の家電メーカーとか最初から終わってんじゃん
入りたくねーｗ

426 ：12/02/27

家電とかの電子回路は商品ごとに作り直せるから無問題

427 ：12/02/27

日本のものづくりw
技術者を大切にしないから、衰退の一方だなwww

428 ：12/02/27

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

429 ：12/02/27

>>424
それはマネしたさんではなくてエスプーさんのことですね。

430 ：12/02/27

人売りが技術系にはびこってしまったからなぁ
スキルの安売り状態で業界がどんどんだめな方向に向かってる気がするわ
スキルなくても底辺で食ってけるから、そこで安心しちゃってるようなの多いし

431 ：12/02/28

仕様書については未だに悩んでる。
1つの提案なんだが、コードにlatexで埋め込んで
仕様書を自動生成するか
そうでなくてもワードよりはtexのほうがいいとおもう。
どうせpdfで出図すればいいんだから。
なんでwordを進めるのだろう。
酷い場合はexcelで書く馬鹿がいる。
しかし上司だからこき下ろすこともできない。

432 ：12/02/28

WordもExcelもMicrosoft Office Personalに入っているから
どの会社のPCでも導入時の状態のままで確実に読み書きできる、だろ？

433 ：12/02/28

texは他人と共有したいとは思わないね。
環境ごとに使えるテンプレやマクロが違うとかやってらんない。

434 ：12/02/28

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

435 ：12/02/28

ドキュメントは結局糞Wordしか使えないって事が多いから諦めて一通りは覚えた
使いにくいだけでスタイルと文書は一応分かれてるし
初期設定さえできてしまえばあとは書くだけになるし、そこまで手間はかからない
使いにくいだけで
Excelドキュメント作るやつは全員ばくはつしてしまうといい…

436 ：12/02/28

>>431
お前はこれでも読んで勉強するといいよ。
Excelプロトタイピング――表計算ソフトで共有するデザインコンセプト・設計・アイデア
http://www.oreilly.co.jp/books/9784873114415/
なんでExcelはだめなんですかと聞くと、
Excelは表計算なんだから表計算にしか使ったらダメだ！という
それ以外の理由がない。頭が固いと思う。
Excelが優れている理由ならたくさんみつかるな。
ワークシート単位だから、文書が増えてもワードみたいにページが変わったりしない。
ワークシート＝タブと考えれば、タブと同じ便利さがある。
図形を入れられる。それでいて文書も数値計算もできる。
大まかな座標が合わせやすい。
Excel=表計算という固定観念を捨てて、方眼用紙ソフトと考えれば、万能ソフトだって分かるだろう。

437 ：12/02/28

万能ソフトだろうが何だろうが、まともに文章が入力ができないソフトはダメだ。

438 ：12/02/28

挿入 - オブジェクトで「Microsoft Word 文書」を選べばいいよ

439 ：12/02/28

WordよりはExcelの方がいいな

440 ：12/02/28

Excelが万能って理由もあるけど、Wordがダメ過ぎるってのもあるんだよ。

441 ：12/02/28

>>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

Excelで作られた文書って、目先しか考えてないからなぁ
文章を書く、ってのが前提にあるなら、Excel使ってる時点で全部糞以下だわ
更改されない使い捨てなら別に何でもいいけど、仕様書とかをアレでやられてると、げんなりする
Excel方眼紙仕様書は高確率で、
章番号段落番号とか、修正自色変えとか、一部分だけ取り消し線とか
挙句の果てには印刷レイアウト見ながら列幅の調整、文章の分割を行わないといけない、とか
糞ルールのおまけがいっぱいついてくるしなｗ
操作性悪いI/Fや、ちょっとした誤操作で設定してるスタイルぶっとばしてしまうような
うんｋWordはダメダメのダメダメダメダメだけど、それでもちゃんと使えばExcelよりかは手抜きできるから使いようだと思う
問題の根本原因は、Wordですら理解できないのが多すぎることだと思う
そういう奴らも仕事に関わる以上、結局サルでもわかるExcel方眼紙！みたいなのに助けてもらうしかない

443 ：12/02/29

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

444 ：12/02/29

>>436
別に何でも出来るわけじゃないし、「万能」とはちょい違うと思うなー
Excelは、理解しなくても方眼紙としては使えるので、馬鹿でもわかるって感じだと思う
列幅行高さ変更を禁止される事多い方眼紙を使ってしまうと、改行するだけでカットペースト必要だったり、
笑えないギャグがてんこ盛り状態にはなるけど、それでも方眼紙として使う上での殆どのことは特に理解しなくてもわかるレベルだし
ほんとExcelすごいな…！！１
あと、Excel仕様書の反対理由で、表計算だからって理由を前面押ししてる人はそんな居ないんじゃね
「そもそもあれは表計算ソフトで、文章を書くためのものじゃない」っていうような言われ方ならちょいちょい見るけど
それって「表計算ソフトだからー」、じゃなくて「文章作成機能付いてがないからー」って意味っしょ
もし、前者のように捕らえちゃってたのなら、多分Wordの機能と、Excelの機能の差をちゃんと理解しきれてないんだと思うぽ
修正の履歴つけたり、番号振ってくれたり、用語を参照してくれたり、目次つけたり、段落やレイアウトやってくれたり、
印刷を面倒みてくれたり、みたいな文章の作成向きの機能がExcelには殆どついてないから、
どっちも一通り触ったことある人は、流石に文書作るのにExcelはねーな、ってなるんだと思う

445 ：12/02/29

文書を電子データのまま活用するか、プリントアウトして活用するかの文化の違いに見える。

446 ：12/02/29

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

447 ：12/02/29

UMLって全部、多次元配列で表現できるような気がするんだ。
いや、具体的に検討したわけじゃないんだけど。
wiki文法に組み込めないかな。

448 ：12/02/29

>>443
ここマ板だしなｗ
仕様の修正で、中身となんも関係ない見た目まで毎度再調整とか、無駄じゃね
ブレブレの仕様とかだと、仕様ちょっと変わるたびに見た目まで再調整とかになったりするんだぜ
基地外じみた章番号の修正とか、気が狂う奴が出兼ねない…！
そういうのがめんどくせぇ、ってのに理系だの文系だのは関係ないと思うｗ
>>445
印刷する気ないのに、印刷レイアウトではみ出しがないかチェックしろ、みたいなアホなルールも結構みるけどなｗ
レビューでんなとこチェックしてる時間あったら、内容の不備がないかをチェックしろよって思うこと多々

449 ：12/02/29

基本的に方眼Excelのくせに、一部分だけ表を書きたいためなのか
横長なセルがあったりすると非常に萎える。

450 ：12/02/29

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

451 ：12/02/29

> Texとかまじわからん
HTMLわからんって言ってるようなものなので、ちょっと恥ずかしい。

452 ：12/02/29

方眼紙にするだけならまだ許そう。お前ならまだ切り貼りもだいたいできるし、他からのペーストもわりと受け入れてくれる包容力がある。
だがセル結合、テメーはダメだ！
>>450
イライラすんのは理解力がない自分のせいだと思うぞ。
俺も前は、Wordは勝手に○○されるから糞って思ってたけど、結局それはなんでそうなるかを知らないからなわけだし。
項目名が意味フだったり、ヘルプも微妙だったりで、覚えるまで面倒なのはすごく同意できるが、
イライラしてても埒が明かんって調べたら、数十分ありゃ解決するような話だったこと多々。
Texも別に調べりゃすぐわかるレベルだし、わかるわからない以前に単にやる気がないだけだと思うわ。

453 ：12/02/29

Wordで章だてから真面目に書けば、そう悲惨なことにはならない。
書式は統一されたものを適応するのみ。
なんでも適当にやるからだろ……

454 ：12/02/29

>>450
Wordで文章書くとき、
一つの文なのに改行で行替えしたり、
タブや全角スペースで文字下げしたりインデントしたり、
文の一部を選択してフォントやサイズを変えたり、
目次を手でかいたり
してない？
そりゃ大変だよ。

455 ：12/02/29

>>450
TeXなんかなんかプログラム言語の文法と比べると簡単なもんだぞ。
文系と言うのなら不親切な親切って言う表現はおかしいだろう。
Wordは大きなお世話が多いのは確か。

456 ：12/02/29

Excel否定する長文をよく読むと
否定する理由の根拠が激しく乏しい件について。

457 ：12/02/29

>>453
> Wordで章だてから真面目に書けば
章立てする理由は？
本書いてるわけじゃないんだから
そんなの必要ないよ。

458 ：12/02/29

Ctrl+クリック(だっけ？)で即ジャンプできるじゃん

459 ：12/02/29

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

460 ：12/02/29

章＝ディレクトリでいいやん

461 ：12/02/29

Wordはもうちょっとアウトラインが使いやすければなあ。

462 ：12/03/01

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

463 ：12/03/01

モジュールに分けて仕様書つくればいいんじゃないのか

464 ：12/03/01

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

465 ：12/03/01

使う人が使いやすいならエクセルでもいい。
自分しか使わないなら好きなので書けばいい。
ただ、Wordを批判するやつの九割以上がWordを使いこなせないことを責任転嫁しているのは納得いかない。

466 ：12/03/01

Word好きじゃないが、Wordでもファイル分けくらいできるぞ。
複数ファイル参照とかは普通に使うでしょ。

467 ：12/03/01

>>465
あるあるすぎるｗ
自分も昔そうだったからすごくわかるわ
不勉強だった自分を見てるみたいで、もにょる…

468 ：12/03/01

>>465
使いこなせない人には糞にしか見えないってだけだべ
責任転嫁とは違う

469 ：12/03/01

>>467
素直に言い給え、Wordも使いこなせないクズと

470 ：12/03/01

仕様書はExcelで良いと思うが操作説明書をExcelで作るのは止めて欲しい。
しかも章ごとにブックは分かれているし目次もページ番号も手で振っている。

471 ：12/03/01

>>457
仕様書っていう本書いてるんだよ。何言ってんの？

472 ：12/03/01

本や説明書って、フォーマットは何を使ってるんだろうな。

473 ：12/03/01

>>472
だいたいインデザとか。
所によっては、ページの少ないものはイラレでざくっと作る。

474 ：12/03/01

>>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 ：12/03/01

>>474
そーなのか。まぁ義弟の勤めてる会社は弱小だからかな。
見開き数Pの特集、小冊子くらいなんかは、チラシの延長でやっちゃうと言ってたけど。

476 ：12/03/01

trac + wiki で書いてる

477 ：12/03/02

断定できないけど、
本や説明書のフォーマットはWordやExcelを使ってないってこと？

478 ：12/03/02

>>477
ちゃんとしたところだと、それ用のソフトは普通DTPと呼ばれる物を使う。
Wordを使ってる場合もあるだろうが。

479 ：12/03/03

説明書ならWordで作るのも普通にあるよ

480 ：12/03/03

仕様書の表から構造体やクラスＤＢのテーブルまで作ってくれるようなソフトが求められている

481 ：12/03/03

ソースコードの構造体やクラスＤＢのテーブルから仕様書作ってくれるソフトのほうがいい。

482 ：12/03/03

次点として、そういうことができる専任の人間を雇ってくれ。

483 ：12/03/03

texがもう少し使い易かったら広まったろうに。

484 ：12/03/03

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

485 ：12/03/03

四つ？

486 ：12/03/04

>>484
>一つ目は仕事はあくまでも体育会系のパフォーマンスであって、(....以下略)
確かに、そういった風土はある
対応策としては、Tex活用を個人レベルで(こっそりと)実践して、最終的に業務上で
具体的成果を示す事ができれば、そんな上司も納得せざるをえないのではないかと思う
よくある失敗は、マクロを組む楽しさや細部の装飾ばかりに夢中になってしまうこと
一言で言えば、業務改善という「目的」とTex活用という「手段」の取り違え
>○○したら作業効率ＵＰするよ、と提案すると「俺の仕事を取るな」と怒られる場合もこれ。
これも、人にやらせるのではなく、提案者自身がリスクを背負ってでも実践する姿勢が大切
どこまで自分を信じて有言実行できるか、という話に帰着する
>二つ目は一般の人はデザイナーとかイラストレーターみたいな人種に(....以下略)
これはよく分からないなあ....
提出する書類というのは、最終的なPDF文書または印刷物だと思うから、何が問題なんだろ？
>最後、HTMLの歴史を見ても本来データ構造を記述する言語だったのに(....以下略)
その問題点を改善して文書の論理構造と物理構造を明確に分離した新しい技術が、
>>474で紹介したDocBook(論理: XML, 物理: XSLT)になる

487 ：12/03/04

まず論理構造と物理構造を明確に分離する理由がないよね。

488 ：12/03/04

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

489 ：12/03/04

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

490 ：12/03/04

作り話乙ｗ

491 ：12/03/04

向いてないのにこういう仕事選ぶ奴が多いのがなー
体育会系脳っぽいのが多くて、土方に拍車がかかる

492 ：12/03/04

そういうデザイン部分と文章部分を分けるための道具や仕組みの使い方を
理解できない頭が悪い奴を除けば、そのあたりを分離するデメリットって別に無いからなー
まぁ、そういう頭が悪い奴がいっぱい居る環境にはつかえないっていうのが、ある意味デメリットか

493 ：12/03/04

流し込み機能とか使っていれば
内部で自然と文章とデザインが分かれてるからね。
ファイル自体を分けたりして
見るときは合成する。
書くときは分離する。
なんてことやらなくていいからね
WYSIWYGエディタを使えば。

494 ：12/03/04

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

495 ：12/03/06

あーマ等向けの校正ツールが欲しい。
仕様書の何がめんどくせぇってホント誤字脱字がメンドイ。

496 ：12/03/06

>>495
そんなの気がついたら直すぐらいでいいよ
致命的なのは別として意味さえ通じれば流す方向で
ところで「あーマ等向け」ってなんだ？

497 ：12/03/06

糞リーダーになると設計上のバグよりも
誤字脱字やレイアウトを気にする馬鹿が意外と多い。

498 ：12/03/06

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

499 ：12/03/06

だが誤字脱字だらけの仕様書も困るだろ
内容が本当に正しいかすら信用できなくなる
値が一つ違うだけでもかなりマズイ

500 ：12/03/07

誤字脱字だったら、印刷した設計書に赤ペン引いておけばいい。
わざわざレビューの時にドヤ顔で指摘することじゃないよ。

501 ：12/03/07

いや、指摘するかどうかじゃなくて単に誤字脱字がマズイって話でな

502 ：12/03/07

誤字脱字はできるだけしない、レビューでみつけてなくす、ってのはそりゃまぁあたりまえだけど
それだけで満足するバカが多いこと、って話じゃないの
実際内容をきちんと理解できてるレビュアー少ないし
余計なことばっか指摘して、大事な中身まったく見てない糞な奴も結構見かける
能力ないのに長くいて微妙な肩書きだけがついちゃった系のオッサンとか、結構ひどい
>>496
「嗚呼、マ等(ら)向け」、じゃないかな。　==　「あー(感嘆詞)、ぷろぐらまーたちのための〜」
糞仕様書の行間を読み解くよりは簡単な問題…！

503 ：12/03/07

誤字脱字、正しくない日本語、誤解を招く日本語、全部良くはない事は皆わかってるんだよ。
ただ、物書きのレベルをプログラマに求めるのは酷だろ。
それができるならプログラマ辞めて物書きになってるって。
必要な能力なんだけどね…
時間は限られてるから、なかなかそのレベルをクリアできる人は少ない…

504 ：12/03/07

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

505 ：12/03/07

日本人って学校で文章の書き方に関するエッセンスを習わないし教えないからな。
みんな自己流っていう笑えない状況。

506 ：12/03/07

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

507 ：12/03/07

形だけは教えられるんだよね。原稿用紙の使い方、とか。
フォーマット地獄は既に小学校から用意されてんのよ。

508 ：12/03/07

まぁ、プロの物書きですら難しいからな。
プログラムと一緒で、絶対的な正解ってのが無いのが辛いよな。
コーディング並みにガチガチするって手もあるけど、それこそ形だけのルールで本末転倒になりそうだし。
コードのレビューならコードをレビュー。
文章のレビューなら文章をレビュー。
正しい指摘を毎回できるようにして、プログラマを成長させる環境を作る事が、健全な業界の発展につながって望ましいと思うんだけどなぁー。

509 ：12/03/07

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

510 ：12/03/07

文章って好みがあるからね
だから軋轢生みやすい
ただ、指摘はいいけど怒ったり嫌味言ってくる奴はダメだと思う
表現の違いや誤字脱字なんかはどうしたところで発生するんだから
ドヤ顔してこれでもかと優越感に浸る奴は小物だしたかがしれてる
そういう上司とかリーダーは多いけどなｗ

511 ：12/03/07

レビューの場でいろいろと指摘が発生するのは当然のことだと思っているのだが
それを嫌がる管理者がいるのが嫌だな

512 ：12/03/07

>>509
このパターンは非常に多い。
好みによっても違うが、同じ人でもコンディションによって言う事が変わるのは腹が立つ。

513 ：12/03/07

デファクトスタンダードが無い以上、各組織においては過去の書類を参考にしながら書けということだな。

514 ：12/03/08

ごくごく自然にに考えよう。
設計とか分析とか工程というのは、
その次の工程を行うためにやる。
つまり、その次の工程の内容を理解していなければ、
使えないものが出来るのは当たり前の話。
たとえば使えない設計書。これができてしまうその原因は
その次の工程を全く知らないからだ。
自分の担当工程だけやって、下流の内容は知らないじゃだめなんだよ。
プログラミングができないSEはクズと言うのは正しいということが分かる。

515 ：12/03/08

>>509
あるあるｗｗｗｗｗｗｗ
内容読みきれず、そのときの気分だけで思いつきの指摘する奴多すぎ
レベルの低いレビュアーに当たったときは何を書いてもなんかしら指摘される
とりあえず「わかりました！」って言っておくのが解決策だと思うようになったわ…

516 ：12/03/08

>>28
勝手に大工やっていろ。

517 ：12/03/08

>>514
分析や設計はユーザーの要件を満たすモノを作るためにやる。
それを実現するための技術的な知識は必要だけど、
次の工程はあまり深く気にする必要はない。

518 ：12/03/08

>>515 わかりました、というと「課題」扱いになって再レビュー扱いになるから嫌だ。

519 ：12/03/08

>>517
通訳と一緒だよ。
間に入る人は、両方のことを
知っていなければならない。

520 ：12/03/08

>>517
> 分析や設計はユーザーの要件を満たすモノを作るためにやる。
当たり前の話。それは反論になっていない。
なぜなら、ユーザーの要件を満たすものを
作るためにどうするか？
その答えが、下流に適切な資料を渡すということだからだ。
ユーザーの方だけ見ていてもいいものは作れない。

521 ：12/03/09

下流に適切な資料って何だ？

522 ：12/03/09

少なくとも通信フォーマットがかっちり決まってる資料

523 ：12/03/09

>521
馬鹿な設計になってないこと。

524 ：12/03/09

エンドユーザーは素人だから
めちゃくちゃな要求をしてくるのは仕方ないけど
それ以外は、めちゃくちゃな要求しちゃだめだよね。
プロなんだから。

525 ：12/03/09

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

526 ：12/03/09

>>523
Ａボタン：ジャンプ
Ａボタン長押し：しゃがむ
プレイヤ「うん？」

527 ：12/03/09

>>523
Ａボタン：ジャンプ
Ａボタンまわす：回転
プログラマ「まわす？」

528 ：12/03/09

初版
→→（すばやく２回）：ダッシュ
←←（すばやく２回）：ブレーキ
プレイヤ「左にダッシュしたいです」
改訂版
→→（すばやく２回）：ダッシュ
←（長押し）：ブレーキ
プレイヤ「左に行きたいです」

529 ：12/03/09

>>522
>少なくとも通信フォーマットがかっちり決まってる資料
通信フォーマットとは、ネットワーク上を流れるメッセージの形式的仕様のことでいいのかな？
たとえばテキストであればXML SchemaとかバイナリならIDLやASN.1で書かれた仕様
で、そういった通信フォーマットは実装に着手する以前に仕様書としてかっちり決めるのが当たり前
もしそれが実践できていないとしたら、>>714の
>自分の担当工程だけやって、下流の内容は知らないじゃだめなんだよ。
>プログラミングができないSEはクズと言うのは正しいということが分かる。
うんぬんは些細な話で、それ以前のプロジェクト全体の品質管理に致命的な問題があると思う

530 ：12/03/09

その、通信フォーマットというのを
通信システム知らない素人が作れるかといったら作れないだろうね。
シリアル通信の通信フォーマットはこんな感じでお願いと
言われた資料に、接続先のポート番号は8080で〜とか書いてあったら
お前馬鹿かって思うよ。

531 ：12/03/09

>>526
あー…
あるな。
しかも仕様切った奴は「一つのボタンで合理的だろ」とか言ってる感じ。
ワープロって本当に使いやすかったよね。
倍角にしたけりゃ倍角ボタン、平仮名にしたけりゃ無変換ボタン、
単漢字もボタン。罫線ひきたきゃ罫線ボタン

532 ：12/03/09

>>528
もう設計書レビュー通して印鑑まで押したから変更はできないよ。

533 ：12/03/09

>>532
納品直前にユーザーの怒りを買って、デスマが始まるんだね。

534 ：12/03/09

>>532
レビュー通っちゃうとねー。
明らかにヤバそうなのは「試食してもらいませんか？モックアップと評価版で」とか言うと共に、
いけいけな人捕まえて「ちょっとここ突っ込んでもらうように伝えて下さい」と、両方の顔を潰さぬように大打撃を回避してる。
なんで下っ端がこんな事してるのかわからん。

535 ：12/03/09

>>519
うちいま両方とも知らない奴が間にはいってるもんだから、手の内ようが無い状況だｗ
納品直前なのにまだドキュメントやらテスト仕様書やらつくってたりするｗｗ
笑えねぇけど笑うしかねぇｗｗｗ

536 ：12/03/09

>>534
あー、あるわー
調整する立場の人間が調整する能力なくて、間接的に誘導して調整にもってったりとか…
何の仕事だかわからなくなる

537 ：12/03/09

事後と増やす仕事は、内向きにやらないで欲しいな。

538 ：12/03/13

空気を読まずに質問ｗ
おまいら、
スタイルシート編集ツール
は何使ってます？

539 ：12/03/13

ふつーのてきすとえでぃた

540 ：12/03/13

CSS用にエディタって使ったことないな
っていうか仕様書とはちがくねｗ

541 ：12/03/14

あれ、CSSってＧＵＩでグイグイ書けないんですか？
それをキャプチャーして貼り付けたら仕様書、みたいなことを考えていたのですが。

542 ：12/03/14

CSS編集ツールの話題はスレ違いだよ
Web製作板の「CSS初心者スレッド＝11th＝」スレヘけ

543 ：12/03/14

Web製作板ね。WebProgを見て”無いな〜”と思ってました。　つ �d

544 ：12/03/14

>>542

545 ：12/03/17

UMLで設計を書いている。
asterのフリー版を使っているのだけど、使いにくくて気が狂いそうだ。

546 ：12/03/19

>>545
マウスアイコン近づけるだけで線引きモードになる奴か？
あれ、親切のつもりだってんだから、参るよ。