板検索:
ソースコードを日本語訳したレベルの詳細設計書ってどう? (423)
まとめビュー
1
仕様書無しさん[sage]   投稿日:2016/09/26 22:56:23
これって普通なん?


2
仕様書無しさん[]   投稿日:2016/09/26 23:08:52
それは設計書じゃなくて、
ソースを変換しただけじゃないの?

簡潔でわかりやすい詳細設計書というのは、
ソースを作るよりずっと時間がかかるんだよ。

3
仕様書無しさん[]   投稿日:2016/09/26 23:09:49
おれの経験では、
詳細設計書に3日かけたところは、
ソースを打ち込むのは1時間とか、
そんな感じ。

4
仕様書無しさん[sage]   投稿日:2016/09/27 00:58:24
詳細設計という紙が大事なんじゃなくて
そこに詰め込まれているアイデアや予想、下調べの積み重ねが大事なんだよ
いきなりコーディングをはじめるやつは、ソースをいじりながら設計してるだけ
紙とエクセルとコードのどれで設計するかは個性の問題だろう
結局はアウトプットで勝負するしかないのだから

5
仕様書無しさん[]   投稿日:2016/09/27 01:11:11
設計が悪ければ、いくらコードを書いてもやり直しだ。

6
仕様書無しさん[sage]   投稿日:2016/09/27 02:59:17
設計書書くよりコード書いてる方が実際の動きが読めるんだけど
設計書じゃ矛盾ないように書かれてるけど、実際コード書くと矛盾が見えてきたり
コード書く前に完璧な設計書ってできてるの見たことないわ
コメント3件

7
仕様書無しさん[]   投稿日:2016/09/27 03:12:17
設計が悪いとは、そもそもの実装の方向性から間違ってるという意味で、
コードで矛盾を修正したところで設計は良くならない。
適切な設計ならコード量が1/10になったりする。

8
仕様書無しさん[]   投稿日:2016/09/27 06:57:03
詳細設計書とかいらねえから適切な要件定義書を残しておいてください(小声)

9
仕様書無しさん[sage]   投稿日:2016/09/27 08:22:42
要件曖昧ズブズブなお仕事
楽しいです(^q^)

10
仕様書無しさん[sage]   投稿日:2016/09/28 00:03:56
>6
考えてから書けって言ってるだけだよ
紙やエクセルシートが大事だとは言ってない
コードを書きながら考えるという手法も間違ってないよ
もちろん、削除して書き直しだけどね(失敗した設計図の紙を丸めて捨てるように)

ある程度の経験を積めば、コードを書かないとわからないってことは
ほとんどなくなるんだろうね
毎回同じようなものを書いてると特にね
コメント1件

11
仕様書無しさん[sage]   投稿日:2016/09/28 21:27:17
>10
学ぶことをやめたジジイおつ

12
仕様書無しさん[sage]   投稿日:2016/09/28 23:41:28
考えてからコーディングしないと飽きるよ

13
仕様書無しさん[sage]   投稿日:2016/10/01 23:01:25
で、詳細設計書には結局なに書けばいいの?
コメント2件


14
仕様書無しさん[]   投稿日:2016/10/01 23:03:14
疑似コードとコメント書いてますよw

15
仕様書無しさん[]   投稿日:2016/10/02 19:27:50
>6
それはあなたの経験が足りないから。

16
仕様書無しさん[]   投稿日:2016/10/02 19:31:22
>13
コードを見なくても作りがわかるドキュメント

17
仕様書無しさん[sage]   投稿日:2016/10/02 21:49:15
結局コード読めない人でもレビューできるようにするための文書でしょ。
実装の上では全く不要な代物。
コメント1件

18
仕様書無しさん[sage]   投稿日:2016/10/02 21:54:09
>13
そこには処理を箇条書きにして、何を入力にして何を出力するのか書くんじゃね?

19
仕様書無しさん[sage]   投稿日:2016/10/02 22:22:23
それは構成仕様

20
仕様書無しさん[sage]   投稿日:2016/10/02 22:35:13
改修作業請け負ったものの設計書が影も形も存在せず
とりあえずの体裁としてVB和翻訳設計書を書かされる羽目になった思い出

コード自体当時の担当者を(自主規制)したくなるほどのクオリティだったが
それはまた別の話

21
仕様書無しさん[]   投稿日:2016/10/03 06:00:33
>17
実装なら設計書ありきの話だろ。

プロは設計に時間をかけて、コーディングは超短時間で終わる。
コメント1件

22
仕様書無しさん[sage]   投稿日:2016/10/03 08:14:36
設計を頭の中でするっていう人はいるかもしれないけど
設計せずに実装する人はいないよね?
コーディングしながら書き換えていくっていうのは
経験のない初心者なら仕方ないけど・・・

23
仕様書無しさん[]   投稿日:2016/10/03 10:15:14
どんなに、きちんとした日本語だとしても解釈問題って永久に消えない。
だから、ユーザー現場で開発するアジャイルが一番なんだよ。
コメント1件

24
仕様書無しさん[]   投稿日:2016/10/03 20:09:06
>23
アジャイルというよりスパイラルだけどな。

アジャイルは技術的検証が必要な小さなものになら向いているが、そうでなければうまくいかない。

もともと欧米人は文章だけの資料を作りたがるから、認識がなかなか合わない。

だからアジャイルなんてものが出てくるw

25
仕様書無しさん[]   投稿日:2016/10/03 21:14:02
改修だったら事前に絶対ソース見る訳だから

コーディングせずに設計するって
直し方分かってるのにその場は我慢してまず紙に書いておいて
改めてもう一度ソースに戻るってだけだよな

特にオリジナルのソースが汚い場合にはこの方法はキツイ

26
仕様書無しさん[sage]   投稿日:2016/10/04 00:08:34
改修の一番最初の段階(現場レベル)ってのは
既存バグの修正やリファクタリングだろ?
コメント2件

27
仕様書無しさん[]   投稿日:2016/10/04 01:53:26
>26
リファクタリングはありえない。

いきなり仕様が勝手に変わる、障害がおきる可能性もあるし。

リファクタリングは何か改修のついでにやる程度。

もう本番が動いているものに対してはリスクが大きすぎる。

28
仕様書無しさん[sage]   投稿日:2016/10/04 06:49:43
>26
リファクタリングはありえる

リファクタ無き強引な改修はさらなるバグを誘発、将来の改修が更に困難になることも
コメント1件

29
仕様書無しさん[sage]   投稿日:2016/10/04 08:31:14
動いてるもん弄るな。

30
仕様書無しさん[sage]   投稿日:2016/10/04 22:43:38
これから弄るんだからリファクタリングしたっていいんだよ
どうせ最終的にはテストするんだからな

31
仕様書無しさん[]   投稿日:2016/10/05 01:52:02
>28
それはリファクタリングではなく作り替え。
コメント1件

32
仕様書無しさん[]   投稿日:2016/10/05 05:03:20
リファクタリングができない是即ち動いてるのが奇跡だからで候

33
仕様書無しさん[]   投稿日:2016/10/05 05:52:26
>6
> コード書く前に完璧な設計書ってできてるの見たことないわ

それはお前が若いからだ。
おそらく30代ぐらいまでで、簡易言語やWeb系やってる人のなかには
見たことないってのも沢山いると思う。

それは時代の流れで
しかたのないことかもしれない。

みんながドキュメント書けない(書かない)馬鹿プログラマに
なってゆくんだよ。
コメント1件

34
仕様書無しさん[はげ]   投稿日:2016/10/05 06:57:33
>31
リファクタリング=作り替えw
脳みそ動いてますか?

35
仕様書無しさん[sage]   投稿日:2016/10/05 06:59:49
>33

>みんながドキュメント書けない(書かない)馬鹿プログラマに
なってゆくんだよ。

ここまでくると宗教のような洗脳ですね
ドキュメント教w
コメント1件

36
仕様書無しさん[sage]   投稿日:2016/10/05 08:35:04
必要に応じて必要な粒度で作りゃいいだけのことじゃないかね
俺の職場では納品物として形だけ作る文化だぜ、アプリ作った後にな

37
仕様書無しさん[]   投稿日:2016/10/05 19:18:07
いまはもうないがプログラム設計書のことを詳細設計書というやつがいるけど、それがソースコードを言葉で書いたようなものなんだよな。

38
仕様書無しさん[]   投稿日:2016/10/05 19:25:09
ソースコードをただ日本語訳したようなものは設計書ではない。

そんな設計書があるなら、それは設計自体がおかしい。

39
仕様書無しさん[sage]   投稿日:2016/10/05 20:25:04
>21
設計に時間かけるのは分かるけど、ソースの日本語訳レベルの設計書が必要って言ってるならあなたはかなりハイレベルだと思う。
コメント2件

40
仕様書無しさん[sage]   投稿日:2016/10/05 20:47:07
>39
デマゴーグ

41
仕様書無しさん[sage]   投稿日:2016/10/05 21:11:10
NASAなんかでは、プログラマは余計なことを考えず仕様書をただひたすらプログラムコードに変換するだけの存在らしい
仕様書の品質についてどうやって保ってるのかは知らないが
コメント2件

42
仕様書無しさん[]   投稿日:2016/10/05 21:26:15
>39
そんなコードそのままみたいな設計書はいらないけど、プログラマでも低レベルのコーダーにやらせるとなると、サンプルプログラムがないとひどいものにはなる。

だからいまは詳細設計とコーディングは同じひとがやるのが普通だけど、汎用機の世界のひとや年配は、いまだにプログラム設計書レベルの設計書を作るよな。
コメント1件

43
仕様書無しさん[]   投稿日:2016/10/05 21:27:58
>41
それは一部の人間だろw

どうせインド人だろうな。

44
仕様書無しさん[]   投稿日:2016/10/05 21:30:24
それと仕様書と設計書の違いが分からない人間がいるのは万国共通らしい。
コメント1件

45
仕様書無しさん[]   投稿日:2016/10/05 22:41:28
紙→鉄に変わる機械の製造のと違って
記号→記号だからな

変数とか関数とかエディタ介した方が見やすいし

46
仕様書無しさん[]   投稿日:2016/10/05 23:08:37
モジュールなりクラスの入出力を「厳格に」決めればいいだけだろ。
使用したアルゴリズムをコメント2,3行で書いとけばいい。

47
仕様書無しさん[sage]   投稿日:2016/10/05 23:10:32
>41
なんだNASAの真似をすれば良いわけか。
簡単そうだな。

48
仕様書無しさん[sage]   投稿日:2016/10/05 23:11:49
いきなりエクセル使って設計すんな。
なんどもエクセル書き直して
恥ずかしいと思わんのか?

49
仕様書無しさん[sage]   投稿日:2016/10/06 00:54:47
>44
テスト仕様書とテスト設計署の違いを説明できる人をまだ見たことがない
コメント1件

50
仕様書無しさん[sage]   投稿日:2016/10/06 06:36:58
>49
前者は文書で
後者は分署だな
コメント1件

51
仕様書無しさん[sage]   投稿日:2016/10/07 02:01:14
>50
ポリスかよw
コメント1件

52
仕様書無しさん[sage]   投稿日:2016/10/07 10:24:41
誤字のせいで台無しだなw

53
仕様書無しさん[]   投稿日:2016/10/07 19:57:35
>51
消防署だろw
コメント1件

54
仕様書無しさん[sage]   投稿日:2016/10/07 22:01:28
しょーもない
コメント1件

55
仕様書無しさん[]   投稿日:2016/10/07 23:30:25
>54
おまえのところは署もないのか?

ああ、刑務所に入っているから分からないのか。
コメント1件

56
仕様書無しさん[sage]   投稿日:2016/10/07 23:36:17
>53
くだらない

57
仕様書無しさん[]   投稿日:2016/10/07 23:40:56
>55
刑務所風に言えば6点

58
仕様書無しさん[]   投稿日:2016/10/07 23:43:24
私は1日署長をやったことあります!

59
仕様書無しさん[sage]   投稿日:2016/10/07 23:46:22
詳細設計書つくるんならソースでもきれいにして桶

60
仕様書無しさん[sage]   投稿日:2016/10/08 00:40:35
>42
いや、サンプルプログラムはあった方がそりゃいいよ。それはまさに設計じゃん。
ここで言ってるのは個別の業務ロジックそれぞれに対する日本語訳レベルの設計書が必要なのかって話でしょ。

61
仕様書無しさん[sage]   投稿日:2016/10/08 02:22:30
詳細設計があれば修正しやすいでしょ
だっておまえら実装すぐ間違えるから、仕様の推理にノイズが入るし

62
仕様書無しさん[sage]   投稿日:2016/10/08 14:41:09
詳細設計にノイズが入っているのが100%だからな

63
仕様書無しさん[sage]   投稿日:2016/10/15 23:52:42
どいつもこいつもだめだな
詳細設計ってものは言語は何であれ同じ業務ロジックが記述できるように作るものなんだよ
お前ら何十年後とかにシステムのリプレースとかやったことないんだろ
そのときに基本設計、詳細設計のありがたみが分かるよ
入社5年目の俺が言う

しっかりした思想とロジックが入っていればあとはどうとでもなる
糞コードができるのは、プログラマの力量不足でもあり、設計思想が貧弱だった所為でもある

効率の悪いコードとコメントアウト(コメントではない)の嵐
同じコードを2度書くなと何度言えばわかるのか
適切なデータ構造もアルゴリズムも選べないやつは必要ない

ああ、すっきり
怖かった〜

64
仕様書無しさん[sage]   投稿日:2016/10/16 04:17:06
> お前ら何十年後とかにシステムのリプレースとかやったことないんだろ
> そのときに基本設計、詳細設計のありがたみが分かるよ

せやな。だから

http://cloud.watch.impress.co.jp/docs/news/597350.html
>  長期にわたって運用されるシステムの保守開発現場では、保守運用のために
> ソースコードの修正・変更が発生するが、そうした変更は設計書に反映されるのが前提になっている。
> しかし、度重なるシステム改修や技術者不足などの理由により、修正・変更内容の
> 反映漏れによるソースコードと設計書の隔たりといった不備や、ソースコード内容が
> 記載されていないなど、設計書自体の不足がしばしば発生する。


こんなことにならないように、基本設計、詳細設計を修正があるたびに
バグや矛盾や曖昧なところがないようにに書き換えような。
そしてちゃんとテストもしような。基本設計、詳細設計の段階で。


ソースコードではできてることを、基本設計、詳細設計になると
怠けるやつは誰だろうな。

65
仕様書無しさん[sage]   投稿日:2016/10/18 07:59:09
初期段階の設計書があるだけでも
保守は楽

66
仕様書無しさん[sage]   投稿日:2016/10/20 22:27:01
仕様書と設計書は普通
詳細設計書はあほ

67
仕様書無しさん[sage]   投稿日:2016/11/06 16:42:56
詳細設計書とソースコードが漏れなく一致していればいいけど
過去の担当者がそれをおざなりにしてるせいでえらい苦労したわ

なんで過去の担当者の責任をこっちが被らないといけないんだよ・・・

68
仕様書無しさん[sage]   投稿日:2016/11/06 16:54:31
まぁそういうドブ仕事させるためにお前に金払ってるわけだから

69
KAC[]   投稿日:2016/12/03 13:00:42
詳細設計書がなぜあるのか考えたほうがいい

詳細設計書は三十年前にもあった概念だろ?
三十年前といえば、コンピュータなんてほとんどない時代。
設計は全て机上(紙)で行われていた。PCなんて使わない。

限られたマシン時間の中で如何に早く入力するかというのが
コーディングに求められる唯一の事。
コーディング指示書レベルの詳細設計書がなければ、
入力時間がもったいない。(マシンの時間は人件費よりも高かった)

詳細設計書というのは、そういう時代の名残。
いまでは作業者全員がPC持ってるだろうし、PCがターゲットだったり、
ターゲットとの接続はネットワーク化されて共有化されていたり・・・

とにかく、入力と設計を同時に行っても他人に迷惑のかからない
環境になった今では、詳細設計書にそこまで時間を書ける必要はない。
詳細設計のアウトプットはソースコードで十分だろう。

70
仕様書無しさん[sage]   投稿日:2016/12/03 13:21:29
そういう雑な設計で作ると設計やコードが重複するし保守方法も機能ごとにバラバラになるしアスペクトの追加やアーキテクチャの変更も難しくなる
機械には迷惑かけないかもしれないけど人間にとっては完全に迷惑行為だよ
コメント1件

71
仕様書無しさん[sage]   投稿日:2016/12/03 13:46:07
>70
どんなに完璧な詳細設計書を作っても、いきなり、数人で
コーディング開始すると、コードは滅茶苦茶になったりするんですけど

優秀精鋭(1,2人程度)でコーディングを開始し、
共通のコードや、お手本となるプログラムを作成し、
その後、徐々に人数を増やしていくやり方なら、失敗しにくいと思うわ

開発初期の頃のコードの作りがかなり重要だと思ってる
コメント1件

72
仕様書無しさん[]   投稿日:2016/12/03 13:47:25
優秀精鋭なんて言葉はおかしいな
文章書きなおしてたらそうなた

73
仕様書無しさん[sage]   投稿日:2016/12/03 14:28:06
>71
そういう状況なら最初から設計パターンを設計書に書けばいい
適切なモデル図と適度な説明はコードよりも正確に早く理解出来る
後は設計書に書かれたパターンに従いコードを書くだけ
コードからパターンを再発見する手間とリスクがないので生産性が高くなる
コメント1件

74
仕様書無しさん[sage]   投稿日:2016/12/03 14:32:02
要するに完璧な設計書と思っていたものが間違っているだけで
優秀なプログラマが書いたコードのエッセンスを設計書に書くべきだった
使えない設計書を完璧な設計書と言って納めてきたクズを否定するのは正しい
しかし設計書の利点を否定する理由にはならない

75
仕様書無しさん[sage]   投稿日:2016/12/03 15:04:48
>73
> 後は設計書に書かれたパターンに従いコードを書くだけ

それやってみたいわw

で、コードに書くだけでいいという
「設計書に書かれたパターン」の一例を見せてくれ。

そんなの見たことないんでなw
コメント1件

76
仕様書無しさん[sage]   投稿日:2016/12/03 15:10:27
>75
一例はあなたがもう知ってるでしょ
優秀精鋭が書いたコードを解析すれば後続も書けるって自分で言ってるじゃない
それを設計書に図と文章で書くだけだよ

77
仕様書無しさん[sage]   投稿日:2016/12/03 15:17:52
> 優秀精鋭が書いたコードを解析すれば後続も書けるって自分で言ってるじゃない
> それを設計書に図と文章で書くだけだよ

それってコードと何が違うの?w
内容的に同じものを2回書く理由は?
ないよね。じゃあどちらか一つにしましょう。
コメント1件

78
仕様書無しさん[sage]   投稿日:2016/12/03 15:24:32
じゃあどちらか一つにしましょう。
と言われた時、設計書だけ書いてコードは書かない。
自動生成しましょう。ってならないのはなぜか?

まあ分かるよねw
設計書にはコードに書いてある情報の一部しかない。
それみてもコードは書けないということ。
コメント1件

79
仕様書無しさん[sage]   投稿日:2016/12/03 15:25:42
>77
レス読んでよ
図と文章で説明するってレスしたでしょ
コードに画像組み込むわけにはいかないだろう
そんなんで設計書が悪いなんて言っても説得力ゼロだよ
マトモに読んでないだけだろ
コメント1件

80
仕様書無しさん[sage]   投稿日:2016/12/03 15:34:49
>78
なんでこの手の人ってすぐに自動生成に持って行きたがるんだろう
設計書はコード生成のソースではなくコードを書く人間にとって読みやすく理解しやすい形で情報をまとめたものだ
新人研修で教わるような基本的なことでしょこれ
コメント1件

81
仕様書無しさん[sage]   投稿日:2016/12/03 15:36:06
>79
だから、で、コードに書くだけでいいという
「設計書に書かれたパターン」の一例を見せてくれ。
って言ってるんだが?

設計書にはコードに書いてある情報の一部しか書かれていない。
設計書を見てもコンポーネントの構成がわかるだけだ。

コードを読むことの助けになるだけであって、
設計書から誰もが同じコードをかけるわけがない。

優秀精鋭が書いたコードを解析すれば後続も書けるのは
そこに、設計書の内容+コード の情報があるから
だけどコードがない設計書は、明らかに情報が足りてないんだよ。

足りてるというのなら・・・話は最初に戻るな
コードに書くだけでいいという
「設計書に書かれたパターン」の一例を見せてくれ。

82
仕様書無しさん[sage]   投稿日:2016/12/03 15:39:45
>80
> なんでこの手の人ってすぐに自動生成に持って行きたがるんだろう
> 設計書はコード生成のソースではなくコードを書く人間にとって読みやすく理解しやすい形で情報をまとめたものだ

なんでこの手の人ってコードが読みにくくて理解できないと思い込んでるんだろ?
技術力がないから?w

自動生成っていうのは、すべての情報が曖昧ではなく
揃っているのであれば、自動生成が可能だからだ。

自動生成ができないのであれば「読みやすく理解しやすい形で情報をまとめたもの」には
情報が曖昧で欠けているということの証明になる。

だから自動生成できない=設計書には情報がかけている=そこからコードを作り出すことは出来ない。
これが成り立つ。

83
仕様書無しさん[sage]   投稿日:2016/12/03 15:44:35
で、設計書を詳細にすればするほど、それをコードに落としやすくはなるが、
現実にある設計書は、ほとんどコードに落とせないものばかりだ。

コンポーネントの構成を理解する程度が関の山だろう。

コードに落とせるレベルまでの設計書を書いたらコストが膨大になってしまうからだ。
自然言語という曖昧な言語で、動くわけでもないからテストも不可能だしな。
コメント1件

84
仕様書無しさん[sage]   投稿日:2016/12/03 15:45:09
仕様変更があると設計書とソースのリンクが取れなっていくって
単純に仕様書担当のSEなりプログラマなりの怠慢でしかないよな
コメント1件

85
仕様書無しさん[sage]   投稿日:2016/12/03 15:47:35
>84
怠慢をやめるのはいいが、リンクを取るための作業をするなら
単にコストがかかるだけだぞw

仕様変更があったとき一箇所を変えるだけで良くしておくと、
コストはかからなくなる。

怠慢というのは、同じ情報を複数箇所に分散させる行為だろう。
だから、どちらか一箇所にしましょう。

86
仕様書無しさん[sage]   投稿日:2016/12/03 15:57:29
アンチ設計書くんは設計書はプログラマ以外の利害関係者も読むし口を挟むって前提をどこかに置き忘れてるよな
コード読めない利害関係者とコードでコミュニケーションをとるなんて凄まじいコストになるぞ
コメント1件

87
仕様書無しさん[sage]   投稿日:2016/12/03 16:01:17
>86
だったら「うちでは利害関係のために設計書は書くものです」って
言えばいいだけでは?

ソフトウェアを作る上では必要ないと言ってることに対して
矛盾はしないだろう?w
コメント1件

88
仕様書無しさん[sage]   投稿日:2016/12/03 16:07:09
>83
逆だよ
詳細まで煮詰めすぎるとコード化しにくくなる
自動生成できるほど詳細な設計書から自動生成したコードは整合性が取れないから動かないことがほぼ保証される
コードの生成ができるほどの濃密な設計書は役立たずってことだ
だから完全性は無いが殆ど正確でコードを書く人が理解しやすい図と文章という構成で設計書を作らなければならない
完全なコードに置き換える作業は人間が手で行う必要がある
最初から完全なコードを書くことは完全な設計書を書くことができないように不可能だから必ず設計書からスタートしなければならない
コメント2件

89
仕様書無しさん[sage]   投稿日:2016/12/03 16:09:12
>87
必須ではないが有用だよ
もちろん使いこなせないバカにとっては有害になりうる
君や君の同僚にとっては有害だった
それだけの話なんだよね
これ以上は不毛な議論になってしまうな
コメント1件

90
仕様書無しさん[sage]   投稿日:2016/12/03 16:09:23
設計書なんて客から金をむしり取るためのものなのに、
そこに技術的価値があると言い張るからいけない。

91
仕様書無しさん[sage]   投稿日:2016/12/03 16:12:08
>88
> 自動生成できるほど詳細な設計書から自動生成したコードは整合性が取れないから動かないことがほぼ保証される

なんで自動生成したコードを書き換えるんw
自動生成できるなら書き換える必要が無いはずだ。

自動生成できずに、手動で書き換えるから
整合性が取れなくなってんだろw

いい加減設計書からコードは自動生成できないって認めてしまえよ。
そしてその理由が、設計書には情報が足りてないからだって理解しろ。
自動生成が悪なんじゃないんだよ。(例えばソースコードからバイナリの生成は自動化できてる)

その元となる設計書の存在が悪なんだよ。

92
KAC[]   投稿日:2016/12/03 16:15:08
>88
> 詳細まで煮詰めすぎるとコード化しにくくなる

はぁ?
いくら何でもそりゃただの馬鹿だ。
なんのために設計するのか理解してから設計しろ。

93
仕様書無しさん[sage]   投稿日:2016/12/03 16:18:29
>89
> 必須ではないが有用だよ
俺は有用かどうかの話なんかしてない。

コードに書くだけでいいという
「設計書に書かれたパターン」

というものは存在しないと言ってる。


設計書なんてコンポーネントの構成を理解するため物でしかない。
そこからコードは作れない。理由は何度も言うが設計書には必要な情報がかけているから。


コストを無視するならば、有用なものであるのは確かだよ?
設計書を読んでそこから理解するのと、何もない状態から理解するのでは設計書を読むほうが早いだろう。

だけどそこには「設計書を作るというコスト」と「設計書を読むというコスト」がかかっている。
そして有用なのは0(設計書もコードもない)場合との比較だ。

設計書を作るコストを、優秀精鋭がコードを作るコストに転用してしまえば、
もっとコストを抑えられる。そういう意味で無用なものとなる。

あんたが言ってるのは「0に比べれば有用」と言ってるだけで
コードに比べれば有用ではないしコストを無視している。

まあ、コストを釣り上げるために設計書を作っているというのであるならば
わざとコストがかかる方法を選んでいるんだろうけどなw
コメント2件

94
仕様書無しさん[sage]   投稿日:2016/12/03 16:21:52
どうせコードを書くことは省略できないのだから
設計書なんてものは、必要最小限であればあるほど良い。

そうすれば、設計書を書くコストは抑えられるし、
設計書を読むコストも抑えられる。

(コードはどうせ読まなければならない。
ただしコードの量を減らして読まなければならない量を減らすことは重要。)

95
仕様書無しさん[sage]   投稿日:2016/12/03 16:24:08
一人のプログラマで最初から最後まで開発して、システムが死ぬまでずっと面倒みるなら
詳細設計書なしでもなんとかなるとは思うが、そんなもん理想論だからなあ
コメント1件

96
仕様書無しさん[sage]   投稿日:2016/12/03 16:25:41
>95
でもコードあるでしょ?
コメント1件


97
KAC[]   投稿日:2016/12/03 16:26:26
>93
話が変な方向に飛躍しているな。
本来の詳細設計書とは、
「コードに書くだけでいい」というレベルの記載がされているものをさす。

設計書からコードが起こせないというのはお前の勝手な思いこみ。
コメント1件

98
仕様書無しさん[sage]   投稿日:2016/12/03 16:27:41
詳細設計書があるからバッチリです!
システム修正できます!
ってコード読まないで言うやつはいないだろうね。

詳細設計書あった所でそこからコードを推察出来ないことの証拠な。

いや、コードを推察できるレベルの詳細設計書というものを
見せてくれることができれば、俺も納得するんだよ?w

99
仕様書無しさん[sage]   投稿日:2016/12/03 16:27:52
プログラマだけでコードで設計とかありえないだろ
コードは正確だけどモデルがそもそも間違ってるから矛盾が発生して製造が滞るなんて現場じゃよくあることじゃん
そういう時にコードしか設計資料がなかったらステークホルダーとどうコミュニケーションとるんだよ
コード原理主義者の理想論はビジネスじゃ全く通用しないぞ
学生のお遊びじゃないんだから責任感持ってしっかりしてよ
コメント1件

100
仕様書無しさん[sage]   投稿日:2016/12/03 16:29:14
>97
> 本来の詳細設計書とは、
> 「コードに書くだけでいい」というレベルの記載がされているものをさす。

だからそいうのを見せてくれって言ってるんだが。


神がいれば、どんな問題でも解決できる。
といった所で、実際には神いねーだろ?って話
いくら偶像つくってこれが神だぞーと言った所で
それ神じゃねーしwww
コメント1件

101
仕様書無しさん[sage]   投稿日:2016/12/03 16:32:01
>99
> ステークホルダーとどうコミュニケーションとるんだよ

やっぱりそこにたどりつくんだよなw
開発するために必要なものじゃなくて、
非技術者とのコミュニケーション用だって言えばいいじゃん。

俺だって、投資家に出資してもらうための
派手なデモは必要だって思うよ?
コメント1件

102
仕様書無しさん[sage]   投稿日:2016/12/03 16:35:06
>96
自分が一切開発に携わってないプロジェクトでも、何してるかはコード見ればギリギリわかるが
なぜしてるのかはより上位ドキュメントがないと無理。時間制限もあるのに解読なんてしてられん

103
仕様書無しさん[sage]   投稿日:2016/12/03 16:37:06
>93
コストの話だしたら余計にコードベース設計の方が不利だぞ
設計とは無縁のコーダーにはわからないだろうけど設計するには対象となるドメインを理解しなければならない
そしてドメインを理解するには残念ながら顧客と真剣に議論し合うしかないのが現実だ
もちろん顧客はコードなど読めないからこのプロセスにはコード以外の資料が絶対に必要になる
その資料を整理して体裁を整えると設計書になるんだよ
コードだけで顧客と議論してもなんの進展もしないで時間ばかりが過ぎていく
この業界では時間ってのは最も重いコストだ
コメント2件

104
KAC[]   投稿日:2016/12/03 16:38:38
>100
なんだ。ただの無知か。

SPDとかYACとか見ればどういうものかわかるだろ。
詳細設計書見たこと無いならさっと言えよ。。。

105
仕様書無しさん[sage]   投稿日:2016/12/03 16:46:02
>101
前提から噛み合ってないんだから話し合っても無駄だよね
顧客を含めたプロジェクトメンバーとのコミュニケーションを設計プロセスに含めるか含めないか
そこからズレてるんだからどこまでいっても平行線だよ

106
KAC[]   投稿日:2016/12/03 16:46:05
>103
話をややこしくすんな。
「その資料を整理して体裁を整えると設計書になるんだよ」
それは仕様書でやるべき話。
少なくとも、このスレの議題である"詳細設計書"はそこには使わない。
コメント1件

107
仕様書無しさん[sage]   投稿日:2016/12/03 16:48:27
>103
基本設計書までは客とレビューするけど
詳細設計書はいちいち客とレビューとかする?

108
仕様書無しさん[sage]   投稿日:2016/12/03 16:53:29
>106
モデル設計は仕様じゃなくて文字通り設計でしょ
金額と消費税率を入力してボタンを押すと税込価格が表示される
これは仕様
税込価格とは金額と消費税率+1の積である
これはモデル設計
コメント1件

109
KAC[]   投稿日:2016/12/03 17:02:31
>108
モデル設計と詳細設計を混同すんな。

つか、モデル設計を顧客の合意とんなよ・・・
モデル設計の内容にミスがあって仕様を満たせなくても
この内容は「顧客と合意済みだ」とか言いはるのか?

客と合意をとるのはあくまでも「仕様」の範囲にしとけ。
コメント1件

110
仕様書無しさん[sage]   投稿日:2016/12/03 17:09:28
>109
合意の有る無しの話じゃねぇよ
顧客の協力なしに正しくモデリングできるわけないだろ
妄想の世界を相手にシステム開発してるんじゃねえんだよ
コメント1件

111
KAC[]   投稿日:2016/12/03 17:11:47
>110
で、その仕様を詰めるための「モデリング」と
今回話題になってる「詳細設計書」に何の関係が?

112
仕様書無しさん[sage]   投稿日:2016/12/03 17:13:39
何かバグが見つかった
調べてみるとコードに誤りはなさそうだ
どいやら詳細設計書のこのモデルのページに間違いがあるようだ
お客さんに設計書を見せて正しいモデルになるよう議論しよう

これがまっとうな対応な
コメント1件

113
仕様書無しさん[]   投稿日:2016/12/03 17:17:49
>112
ちゃんとした仕様書を作って客と合意してから作業しましょう。
これが普通の対応な?

詳細設計書にしか客との合意事項が現れない時点で異常だと気づけ。
コメント1件

114
仕様書無しさん[sage]   投稿日:2016/12/03 17:28:29
>113
顧客とコミュニケーションを取れる、かつ、仕様書から容易にソースに反映できる形式であること
バグがあっても良いが、随時、修正を施さなければならない
顧客との同意書ではなく、顧客の業務知識をより正確にコードに反映させるためのツール
詳細設計書ってのはそういうものだ
何を作るかの同意は別の文書でやるべきことであってその文書の話はしていない
コメント3件

115
KAC[]   投稿日:2016/12/03 19:00:12
>114
>詳細設計書ってのはそういうものだ

はぁ?
詳細設計書とはなにか調べてから出直してこい

116
仕様書無しさん[sage]   投稿日:2016/12/03 20:46:05
さあ盛り上がってきまたし!

117
仕様書無しさん[sage]   投稿日:2016/12/03 21:12:56
さあ盛り下がってしまいました↓

118
仕様書無しさん[sage]   投稿日:2016/12/04 01:14:49
>114
ん?
>顧客の業務知識をより正確にコードに反映させる
これはちょっと違うな。

業務知識とコード(具体的な実装)の間には、最低限もう1枚挟まないといけないと思うよ。

119
仕様書無しさん[sage]   投稿日:2016/12/04 01:16:31
というか、そもそもプログラマとSEでは必要なスキルセットが違うので、
無理して顧客とか業務とか要件とか解ったふりして語らなくていいと思う。
「知りません」「できません」で問題ないんじゃない?

120
仕様書無しさん[sage]   投稿日:2016/12/04 01:21:19
>35
普通は、要件定義書と基本設計書は同じレベルの人が作って、
詳細設計とコーディングは、これまた同じレベルの人が作る。
なので、通常はコードが欠ける人は詳細設計がかけるレベルであると思ってよい。
基本設計と詳細設計のほうに大きな溝があるんだよ。
ドキュメント教うんぬんよりも、スキルとしてくっついてるんだよ。
だからかけないこともないと思うが、書かない習慣もどうかと思う。

121
仕様書無しさん[sage]   投稿日:2016/12/04 02:01:34
>114
> 顧客との同意書ではなく、顧客の業務知識をより正確にコードに反映させるためのツール
> 詳細設計書ってのはそういうものだ

実際には伝言ゲームで間に一人増えただけだけどなw

業務知識を正確に反映させるためには、顧客が直接プログラミングするのがいい。
当たり前だろ?コミュニケーションの数は少なければ少ないほどより正確なる。

それができないなら、顧客とプログラマが直接やり取りする。
その時に使うコミュニケーションツールは両者がわかるものでなければ意味がない。
これも当たり前だろ?

じゃあ詳細設計書は顧客が理解できるのか?って話。顧客は詳細設計書を理解できない。
つまり詳細設計書では顧客の業務知識を正確にコードに反映させることは出来ない。

詳細設計書でできることは詳細設計書を書いたやつと、それを見るやつの
コミュニケーションツールだよ。けっして顧客の業務知識を伝えられるもの
なんて思ってはいけない。

122
仕様書無しさん[]   投稿日:2016/12/04 03:30:11
皆さんの詳細設計書に対する思い入れは凄いですね〜
はっきり言ってバカです

123
仕様書無しさん[sage]   投稿日:2016/12/04 04:48:05
ここいらでバーンと詳細設計書を公開すれば
流れは変わるんだけどな。
オープンソースはできるのだから詳細設計書を公開することが
できないわけがない。
コメント2件

124
仕様書無しさん[sage]   投稿日:2016/12/04 08:38:13
>123
フェイスブックやツイッターを公開してるのだから、
源泉徴収票や健康診断結果を公開することができないわけがない。
コメント1件

125
仕様書無しさん[sage]   投稿日:2016/12/04 08:51:52
そもそも詳細設計書ってひとくくりにして議論するのが間違いですよね
唯一普遍の詳細設計書など存在しないのだから、うちの会社ではこうしてます、へえそうなんですか、以上の議論はできません
以上をもちまして、このディスカッションは閉じさせて頂きます
以後、書き込みは控えてください

126
仕様書無しさん[sage]   投稿日:2016/12/04 10:13:39
>124
まとはずれ

127
KAC[]   投稿日:2016/12/04 17:32:58
>123
公開もなにも・・・
フローチャートとか見た事ないか?
コメント1件

128
仕様書無しさん[sage]   投稿日:2016/12/04 20:21:27
時間がないときはソースコードの日本語訳どころか
ソースコードそのものをコピペしたものを納品したりしてるわ
コメント1件

129
仕様書無しさん[]   投稿日:2016/12/04 20:29:35
>128
いや、流石にDoxygenくらいかけようぜ・・・

130
仕様書無しさん[sage]   投稿日:2016/12/04 20:50:17
>127
> フローチャートとか見た事ないか?

何のソフトウェアの?
コメント1件

131
仕様書無しさん[sage]   投稿日:2016/12/04 20:55:31
>130
素人は黙ってたほうがいいよ
コメント1件

132
仕様書無しさん[sage]   投稿日:2016/12/04 21:01:42
>131
いや質問しているだけだが?
別にフローチャートじゃなくてもいいよ

話を戻すぞ。
ソースコード公開できるんだから
その詳細設計だって公開できるはずだろ。
それを公開しているソフトウェアを教えてくれ
コメント1件

133
仕様書無しさん[sage]   投稿日:2016/12/04 21:04:54
>132
話が戻ってないぞ。
素人は黙ってたほうがいいよ

134
仕様書無しさん[sage]   投稿日:2016/12/04 21:15:08
戻ってるよな?
意味は同じだからまんま前の話を持ってきてもいいんだぜ?

123 自分:仕様書無しさん[sage] 投稿日:2016/12/04(日) 04:48:05.42
ここいらでバーンと詳細設計書を公開すれば
流れは変わるんだけどな。
オープンソースはできるのだから詳細設計書を公開することが
できないわけがない。
コメント1件

135
仕様書無しさん[]   投稿日:2016/12/04 21:20:15
>134
話の流れくらい読もうぜ
コメント1件

136
仕様書無しさん[sage]   投稿日:2016/12/04 21:43:05
図や表ってソースコードでどう書くんだ?
アスキーアート?
コメント2件

137
仕様書無しさん[sage]   投稿日:2016/12/04 22:13:55
>135
それでソースコードとともに公開されている
詳細設計書はどこにあるの?

138
仕様書無しさん[sage]   投稿日:2016/12/04 22:14:10
>136
PlantUML

139
仕様書無しさん[]   投稿日:2016/12/04 22:15:04
>136
文章で説明するんじゃないか?
20cmの線分ABの中点Pに直行する10cm線分PDがあり・・・・とか
コメント1件

140
仕様書無しさん[sage]   投稿日:2016/12/04 22:21:18
>139
そんな文章書くぐらいならコードでよくね?

141
仕様書無しさん[sage]   投稿日:2016/12/04 22:22:40
うむ、COBOL以外の言語は
自然言語を直接翻訳したような文法ではなくて
数学的な式に近いから曖昧さがなくて簡潔に記述できるんだよな。
結局コードで書くのが一番という結論

142
仕様書無しさん[sage]   投稿日:2016/12/05 13:17:18
うん。
これから仕様書や設計書は図も含めて全てプログラムで書こう。

143
仕様書無しさん[sage]   投稿日:2016/12/05 18:51:06
微積分とか数学記号はどう書くの?
TeXコード埋め込むの?

144
仕様書無しさん[sage]   投稿日:2016/12/06 00:54:35
アスキーアート並みに苦心して書くんだ。

145
仕様書無しさん[sage]   投稿日:2016/12/06 18:57:22
黒塗りの四角と白抜きの四角でドット絵でどうだ
フォントを小さくすれば滑らかで美しいグラフィックになる

146
仕様書無しさん[]   投稿日:2016/12/06 19:11:47
コボルの文法って曖昧さがあるのか?

147
仕様書無しさん[]   投稿日:2016/12/06 23:06:58
ない。
一切ない。
絶対にない!
あったらびっくりだろうな。

148
仕様書無しさん[sage]   投稿日:2016/12/06 23:57:54
じゃあCOBOLは曖昧さがないのに
自然言語に近づける意味あるのか?

149
仕様書無しさん[sage]   投稿日:2016/12/07 00:50:15
昔は簡潔な記述よりも、自然言語に近い方が
可読性が高いって考えられていた時代があったんだよ。

だってみんなプログラミング言語を知らなかったわけだからね。
今のようにプログラミング言語をスラスラとみんな読めるように
なるとは考えていなかった。

150
仕様書無しさん[sage]   投稿日:2016/12/15 23:07:36
基本設計書は「こう作ります」ってのを書いて
詳細設計書はどこの会社でも書くところはもうソース貼り付けろよってレベルのもんを
深夜残業して書かされたな
ぶっちゃけ詳細設計書はソース書いてから作ったほうが早い気がする

そもそもこの粒度で詳細設計書を書くことは絶対見積りに入ってないし
おそらく詳細設計書は作るだけで検討などしてる時間はないのではないか?

という経験から詳細設計書は基本設計書とソースのつなぎをする程度の内容でいいのではないかと思う

クラス図→絶対役に立たない
シーケンス図→何も表現できない
処理フロー→ソース見たほうが早い

詳細設計書によくある項目って全部役に立たない

151
仕様書無しさん[sage]   投稿日:2016/12/15 23:14:34
コードだと複数ファイルを開き処理を追わなければ関連やシーケンスが見えてこない
絵に書いておけば紙一枚眺めるだけで一瞬で内容を理解できる
コードが設計として役に立つのはメソッドまでだよ
メソッド程度のサイズならコードの方が早く理解できて正確である事が多いことを認めよう
コメント2件

152
仕様書無しさん[sage]   投稿日:2016/12/16 00:38:15
>151
関連っていらなくね?
大事なのはどの機能がどのクラスやメソッドで実現されているかであって
関連は別にいらねぇ

153
仕様書無しさん[sage]   投稿日:2016/12/16 03:08:34
>151
設計なんてディレクトリツリーを見ればわかることだよ

154
仕様書無しさん[sage]   投稿日:2016/12/16 03:08:52
ディレクトリツリーとファイル名な

155
仕様書無しさん[sage]   投稿日:2016/12/16 05:59:58
変なおじさん「道路の写真が何枚かあれば道路網がどうなってるかわかるよ」

常識人「地図って知ってる?」

156
仕様書無しさん[sage]   投稿日:2016/12/16 08:15:43
仕様を固めないで行き当たりばったりのプロジェクトに参加させられた時が一番きついわ

何回仕様変更して何回ソース書き直せばいいんだよ
コメント1件

157
仕様書無しさん[sage]   投稿日:2016/12/16 08:19:20
R&D部門だとよくあるけど

158
仕様書無しさん[sage]   投稿日:2016/12/16 09:06:10
変なおじさん「青写真が何枚かあれば設計がどうなってるかわかるよ」

常識人「ソースコードって知ってる?」

159
仕様書無しさん[sage]   投稿日:2016/12/16 09:13:59
>156
問題は仕様変更した時に再見積りしない空気
ケツそのままで走るのを作業をボイコットしてでもやめさせないと
でもその辺は状況に応じてって感じだと思う

160
仕様書無しさん[sage]   投稿日:2016/12/16 09:17:18
基本設計書にやることが書いてあって
詳細設計書に基本設計書とソースのつなぎが書いてあれば情報は十分だよ
大手の求める詳細設計書はソースの逆変換に他ならない

161
仕様書無しさん[sage]   投稿日:2016/12/16 18:53:20
みたいなこと言ってる子って仕事で設計書書いたことないんだろうな

162
仕様書無しさん[]   投稿日:2016/12/16 19:29:49
いい年したオッサンに向かって子とかいうオッサンwキモwww

163
仕様書無しさん[sage]   投稿日:2016/12/16 19:34:19
ここは社会人が来るスレだよ
君みたいな坊やにはまだ早いんじゃないかな
コメント1件

164
仕様書無しさん[]   投稿日:2016/12/16 19:43:04
>163
いや俺もオッサンなんだがwお前ほどキモくないけどwww
コメント1件

165
仕様書無しさん[sage]   投稿日:2016/12/16 20:21:22
>164
背伸びしたい年頃なのはわかるよ

166
仕様書無しさん[]   投稿日:2016/12/16 20:37:46
なにこいつ常軌を逸したキモさだなw

167
仕様書無しさん[]   投稿日:2016/12/17 08:41:53
顧客・ユーザーと直接話をして仕様書等々を作成したことないやつは、語る資格なし
コメント2件

168
仕様書無しさん[]   投稿日:2016/12/17 09:27:08
>167
そもそも、プログラム組めないバカはそれすら語る資格ないわけで・・・

169
仕様書無しさん[]   投稿日:2016/12/17 15:55:31
プログラム組めるのは前提条件です
そのうえで>167をやってないやつは語る資格なし

170
仕様書無しさん[sage]   投稿日:2016/12/17 22:14:16
細かすぎる設計書でもあるだけマシだろ
現実世界の詳細設計書は細かすぎるどころかスカスカのゴミじゃねえか
上流が悉く仕事をしていないからな
細かすぎるなんて贅沢な不満なら言ってみたいわ

171
仕様書無しさん[sage]   投稿日:2016/12/17 22:35:49
> 現実世界の詳細設計書は細かすぎるどころかスカスカのゴミじゃねえか

だからいらんって言ってるの。

そもそも当たり前だろ。
細かいことを考えるレベルじゃないのに、
細かいことなんてかけるわけない。

できもしないことをすんなって言ってんの

172
仕様書無しさん[sage]   投稿日:2016/12/17 23:01:44
詳細設計書を書く上流って…そういう世界もあるのか……
コメント1件

173
仕様書無しさん[sage]   投稿日:2016/12/17 23:55:55
>172
そういう現場はもちろんソース書いてから設計書書くよ
担当者もそうするであろうことを見越してスケジュールをする
厄介なのは精度はソースレベルを要求するくせに期間がそれに伴っていないとき

174
仕様書無しさん[sage]   投稿日:2016/12/18 01:26:39
http://qiita.com/nnnmanatsuxu/items/99114f0400b2d79ecc4f

COBOLの現場にいた時は、上の例以上の粒度で詳細設計書書かされてたよ。
ワークレコードの何バイト目にセットするかだったり、繰り返し処理の開始、終了、増分も書いたり。
メリットはほとんどない(どころかデメリットが圧倒的に大きい)けど昔からそうやってるから今もそれを踏襲してる、みたいなことがやたら多い現場だった

175
仕様書無しさん[sage]   投稿日:2016/12/18 08:36:22
コボルは知らんがコボルには固定長フィールドの読み込みAPIしかないってんならフィールド長を設計書に書くべきだろ
自分がデリミタだと思ってたカンマは実はデータの一部で正しくはフィールド長を根拠に読み込む必要があるってことも当然あり得るわけだ
フィールド長を設計書から省略していいのはファイル形式が明確にCSVでありCSVを読み込むAPIがサポートされてる時だけだ
コメント1件

176
仕様書無しさん[]   投稿日:2016/12/18 09:10:04
>175
いまはいろんな読み方できるけど、
コボルは固定長が基本、で設計書にフィールド情報は絶対にのせる
ほぼそれがメインと言っていい。

177
仕様書無しさん[sage]   投稿日:2016/12/18 22:48:17
              ミミ ヽヽヽヽリリノノノノ
             ミ   ,,、,、,、,、,、,、,、、 彡 / ̄`Y  ̄ヽ
              l  i''"        i彡/ / / l | | lヽヽ
             .| 」   ⌒' '⌒  |/ // ⌒  ⌒ヽ
             ,r-/   -・=-, 、-・=- ||/  (●) (●)
             l       ノ( 、_, )ヽ  || |   ⌒ ・ィ  ヽ
              ー'    ノ、__!!_,.  ||   ト-=-ァ ノ
              |.     ヽニニソ   l |   |-r 、/ /|
              ヽ           /.|| | \_`ニ'_/ ||
          /⌒\〆⌒ヽ"ーー" ⌒ヽ/⌒ヽ _ノ          
         ../  ノつ\ ・     ・ /_人. ヽ /     
  グッポ o0○/  /( 3  \  ∩  / `-と ) ○0o         
      (  ` /、_ノヽ     (:::)(:::)    /_ノ' '!   )゜
       \_)    |   : : : __   : : :|  ノ(_ノ
     グッポ    ((  ヽ__ | | __ノ /     ))   
            / ⌒    (:::)(:::)    ⌒ー―、
       ( ⌒ ̄ ̄       人          ヽ 
       \  \______ノ ヽ____./   )  .__/ ̄/   /二二二/_  /'''7    / ̄  ̄/  / ̄/ /'''7
.        \  \              /  /  /___.    ̄./ / __  /  / / ___ /  ̄   ̄/   ̄  / ./ 
          \  \           /  /    ノ / /i ̄!. ̄  __,ノ /  / /_ノ / ~/ /二,.´  ____.ノ ./ 
          ε(  ̄ ̄)         ( ̄ ̄ )3   /_,./__./ ヽ、_>  /____,/ /_____,.ノ i____/  /______./


178
仕様書無しさん[sage]   投稿日:2016/12/20 02:08:55
無いよりは合った方が断然良いけど
ちゃんとメンテできないならいらない
コメント1件

179
仕様書無しさん[sage]   投稿日:2016/12/20 14:00:40
>178
ちゃんとメンテできる書き方ってのもあるじゃない?

180
仕様書無しさん[sage]   投稿日:2016/12/20 19:50:01
メンテはまず不可能だから要点をうまく捉えた抽象的な内容にせざるをえない
だから作図が有効なんだね

181
仕様書無しさん[sage]   投稿日:2016/12/22 23:42:11
文芸的プログラミング

182
仕様書無しさん[sage]   投稿日:2016/12/23 09:51:30
設計書はアート

183
仕様書無しさん[sage]   投稿日:2016/12/23 22:22:31
アートは引越しセンター

184
仕様書無しさん[sage]   投稿日:2017/01/11 19:44:30
詳細設計のお仕事が回ってきて憂鬱だ
コーディングより高難度の詳細設計を書かされて
コーディングは低品質な外注にぶん投げ
マネジメントと受け入れテストも押し付けられた
もうやだ一人で仕事したい
コメント1件

185
仕様書無しさん[sage]   投稿日:2017/01/11 22:19:47
>184
意味が解らん。
一人で仕事すりゃいいじゃねーか。

誰かいないと仕事できないのか?

186
仕様書無しさん[sage]   投稿日:2017/01/11 22:50:27
営業とか居ないと困るな

187
仕様書無しさん[sage]   投稿日:2017/01/13 21:52:22
詳細設計として価値のあるコンテンツって何だ?
コメント2件

188
仕様書無しさん[sage]   投稿日:2017/01/13 22:01:41
>187
APIマニュアル、テストコード、サンプル

189
仕様書無しさん[sage]   投稿日:2017/01/13 22:21:29
>187
状態遷移図・表
プロセス・タスク構成/関連図
コメント1件

190
仕様書無しさん[]   投稿日:2017/01/13 22:39:01
>189
それ結構欲しいけど、図とか表ってアップデートするのめんどくセーんだよなぁ
なんとかならんかねぇ
コメント1件

191
仕様書無しさん[sage]   投稿日:2017/01/13 22:55:41

192
仕様書無しさん[sage]   投稿日:2017/01/13 23:00:09
>191
そっちの方が難易度たけーよw
コメント1件

193
仕様書無しさん[sage]   投稿日:2017/01/13 23:01:38
図を生成するコードとデータを書く
なお製品コードより複雑な模様

194
仕様書無しさん[sage]   投稿日:2017/01/14 06:21:23
>192
>191じゃないけど、AAを書くお手軽ツールがあるんだよ
コメント1件

195
仕様書無しさん[sage]   投稿日:2017/01/14 08:55:37
>194
画像から変換する奴じゃなくて?
urlくださいな

196
仕様書無しさん[sage]   投稿日:2017/01/16 19:54:37
複雑なSQLの詳細設計をどう書くべきかいつも悩む
SQLは頭の中に出来てるけど日本語で説明って難しいんだよな
設計して外注するよりその場でコード書いた方が時間かからない……
営利企業としてなんか見失ってる
コメント4件

197
仕様書無しさん[sage]   投稿日:2017/01/16 20:52:02
>196
手書きで書いた図をスマホで撮って貼り付けしたらいいんじゃないか?

198
KAC[sage]   投稿日:2017/01/17 21:12:11
>196
詳細設計終わってから外注する事自体が間違いだろ
詳細設計から外注するか、試験から外注すべきだと思うが

199
仕様書無しさん[sage]   投稿日:2017/01/21 12:54:40
>196
マジレス

別シートとかに生のSQL文を書いて、管理番号で参照する

結果取得 (SELECT-1-1)
DB更新 (UPDATE-2-1)

もしくは、SQLを詳細設計書に記述する独自記法を決めて、それで記述すればおk
テーブルセルの背景色とかフォントを工夫する
構造的な見た目はSQLと殆ど同じw
Fとかでは、そうだった

あまりにも馬鹿らしいな・・・
もうそういうのに関わる仕事はしなくなったけど

200
仕様書無しさん[sage]   投稿日:2017/01/21 12:57:15
>196
引数を渡す時は

SELECT-1-1に
SELECT * FROM USERS WHERE ID = :ID
とか引数を記述して

SELECT-1-1 (ID: 画面[ユーザID])
みたいな感じ

ああ、思い出してもあほらしいわ

201
仕様書無しさん[]   投稿日:2017/02/07 18:42:00
なぜかSQLをベタ書きするところはいまだにあるんだよな。あれ謎だわ。
コメント1件

202
仕様書無しさん[sage]   投稿日:2017/02/07 22:05:13
のちのちのメンテで役に立つのは
・コーディングの元となった詳細設計書
・コーディングが終わってから書いた詳細設計書
さて、どっちかな?...
コメント3件

203
仕様書無しさん[]   投稿日:2017/02/07 23:31:08
>202
コーディングの元になった設計書。
コメント1件

204
仕様書無しさん[sage]   投稿日:2017/02/07 23:35:38
>201
引当に使うキーは別として
フィールドの粒度で細かく説明しないとだめな時点で設計が失敗してるとは思うが
世の中結構そうやって作っちゃうやつが多い

205
仕様書無しさん[]   投稿日:2017/02/08 07:37:52
何もしていない普通の一般人の自宅に隠しカメラを取り付け
それをネットでリアルタイム配信

仲間という人間に対する盗聴盗撮生ネット配信の会

しかけたカメラの映像
乗っ取っているPCの画像をリアルタイムで生配信中
集団で仲間の私生活を覗いて楽しんでいる

そんなことが今この国では行われています

206
仕様書無しさん[sage]   投稿日:2017/02/08 12:10:19
>203
正解

207
仕様書無しさん[sage]   投稿日:2017/02/09 01:29:54
>202
どっちも殆ど役に立たん。
コメント1件

208
仕様書無しさん[sage]   投稿日:2017/02/09 01:58:13
>207
お前は無能

209
仕様書無しさん[]   投稿日:2017/02/11 14:26:18
詳細設計書って後から見ても、殆ど役にたたない
メンテされずにコードと乖離してたり、嘘や間違いだらけ
そもそも、ドキュメントって、簡単に馬鹿でもメンテできる概要レベルしか残しちゃダメだわ

210
仕様書無しさん[sage]   投稿日:2017/02/11 15:29:03
>202
> のちのちのメンテで役に立つのは

コードだろ?

既存システムのソースコード解析および設計書作成を自動化「設計書リカバリーサービス」を提供開始
http://www.nttdata.com/jp/ja/news/release/2013/042402.html

> 長期にわたって運用されるシステムでは人手のかかる設計書整備の不備・不足による保守開発の
> 困難さや有識者依存の業務が問題となっています。また、システム更改を行う場合も仕様が
> 不明確で問題化するケースもあります。システムを正しく理解するために設計書の
> 不備・不足を解消するには、既存システムのソースコードを解析する必要があるため、
> 多大な時間を要していました。

> 背景

> システムの保守開発現場では保守運用の為、ソースコードの修正・変更が随時発生し、
> その対応内容を設計書へ反映させます。しかし度重なるシステム改修や技術者不足などの理由により、
> 修正・変更内容の反映漏れによるソースコードと設計書の乖離といった不備や、ソースコード内容が
> 記載されていないという設計書自体の不足がしばしば発生していることがあります。

> 特に長期にわたって運用されているシステムではこの傾向が顕著で、システム改修などの保守開発が
> 困難となる問題が発生しています。その一方で保守開発の現場では、変更要求発生時などに迅速かつ
> 正確な対応が求められており、設計書の不備・不足はシステム改修内容の決定判断や、
> 正確なシステム改修の妨げになるため大きな問題となっています。
コメント4件

211
仕様書無しさん[sage]   投稿日:2017/02/11 18:14:44
>210
営業乙

212
仕様書無しさん[sage]   投稿日:2017/02/11 20:47:34
>210
お前、自分で貼った文章の内容すら理解できないのか?

213
仕様書無しさん[sage]   投稿日:2017/02/11 21:10:15
>210
各設計書のマークがExcelであることに不安を感じた

214
仕様書無しさん[]   投稿日:2017/02/12 10:34:50
詳細設計の粒度はプログラミングをする人間のレベルに合わせるのが現実的。
コメント1件

215
仕様書無しさん[]   投稿日:2017/02/12 10:47:29
pseudo code

216
仕様書無しさん[sage]   投稿日:2017/02/12 11:06:18
>214
おい、なんで新卒様に俺らが合わせないといかんのだ?
コメント2件

217
仕様書無しさん[]   投稿日:2017/02/12 11:12:24
>216
出来上がってきたプログラムを書き直すのが面倒だから。

218
仕様書無しさん[sage]   投稿日:2017/02/12 13:46:18
>216
修正するのも将来の新卒や質や経緯のわからない借りてきた派遣の仕事になるんだろうから、意味のある詳細設計なら新卒にあわせないと。
形だけ納品して後は知らない、なら適当に書いておけばいいさ。後で呼び出される心配なければね。
その前に読めんわからんとクレーム上がってくるかもしれないけど。
コメント1件

219
仕様書無しさん[sage]   投稿日:2017/02/12 13:53:53
入社したばかりの新卒が作ったシステムです
高いのは仕方ないでしょう?

とか言うつもりかwww

220
仕様書無しさん[sage]   投稿日:2017/02/12 14:06:44
>218
役に立つなら良いんだけど、放置されてるのたくさん見てるからなあ。

ドキュメントが殆ど無いような案件でリフォームするような仕事したことあるけど作業も半ばまできて、たまたま雑談してる時に別の案件で終了した奴の中に今作業しているのと殆ど同じものがあることを聞いた。
こっちはドキュメントがかなり詳細に残っていて作りもしっかりしてるし、DBで言えばフィールドを少し増やせばそのまま使えるような奴だったけど結局使われなかったな。

詳細なドキュメントが残ってても詳細を知ってる奴が残っていないと放置されたままゴミ箱行きになることも多い。

221
仕様書無しさん[sage]   投稿日:2017/02/12 15:06:44
結局SI業界っていうのは、素人がシステム作ってるんだよ

222
仕様書無しさん[]   投稿日:2017/02/12 15:14:34
そもそもpseudo codeというれっきとした名前が有るんだからそれを使ってくれ。

223
仕様書無しさん[sage]   投稿日:2017/02/12 16:37:39
pseudo codeってなんだ擬似コードのことか。
日本語で言えよ。わかりづらい
コメント1件

224
仕様書無しさん[]   投稿日:2017/02/12 18:15:43
>223
常識レベルだよ・・・頭大丈夫かい?

225
仕様書無しさん[]   投稿日:2017/02/12 18:24:28
常識レベルの低い奴に限って
それ常識だよ、とか言うんだよな。

根性がひんまがってる低知能に多い現象。
これ常識www

226
仕様書無しさん[sage]   投稿日:2017/02/12 18:41:12
時々仕事できないくせにカッコつけた言葉使いたがる奴には「それって何なの?」と圧力的に聞くことがあるな。
で、説明受けた後で「なんだ、〜のことかあ」って返す。

勿論、こちらが上司+自他共に技術レベルが上と認められてる場合だけどね。

227
仕様書無しさん[]   投稿日:2017/02/12 18:45:37
カッコつけた言葉って?
「ちょ待てよ」とか?

228
仕様書無しさん[]   投稿日:2017/02/12 18:50:15
>210
それテラソルナの売り文句だろ

229
仕様書無しさん[]   投稿日:2017/02/12 20:28:33
Pseudocode程度でカッコ付けって、どんだけレベル低いんだよ。

230
仕様書無しさん[sage]   投稿日:2017/02/12 20:33:17
日本語で通るもので且つ日本語の方が分かりやすい場合は全部カッコつけてると判断するな。
但し、既に日本で浸透している場合は除く。

けれど、知らない奴に"常識"とか言うような奴ならカッコつけてるという判断をするさ。
コメント1件

231
仕様書無しさん[]   投稿日:2017/02/12 20:49:31
成長しないな、それじや

232
仕様書無しさん[sage]   投稿日:2017/02/12 20:57:10
(常識)

233
仕様書無しさん[sage]   投稿日:2017/02/12 21:08:12
プログラム歴1年未満の兵隊をたくさんかき集めて、
無駄に時間をかけて開発するのが
SI業界の常識だろ

234
仕様書無しさん[]   投稿日:2017/02/12 21:57:56
>230
お前が分かりやすいから皆が分かりやすいという訳でもない
同様に日本語の約語より外来のカタカナ語の方が浸透してる例はいくらでもある
コメント1件

235
仕様書無しさん[sage]   投稿日:2017/02/12 22:03:32
漢字が読めない人のために
全部カタカナ or ひらがなで書くべきだ。
可読性重視な
コメント1件

236
仕様書無しさん[sage]   投稿日:2017/02/12 22:07:40
プ…pseudo codeってなんだ?

237
仕様書無しさん[]   投稿日:2017/02/12 23:31:54
>235
可読性を上げるために漢字が使われているんたか?

238
仕様書無しさん[sage]   投稿日:2017/02/12 23:58:47
たか?

239
仕様書無しさん[sage]   投稿日:2017/02/13 02:03:49
>234
何言ってんの?
浸透してたら除くって日本語分からんのか?
それに当然分かりやすいなら何の問題も無い。
しかし少なくともPseudocodeが分からなかった奴も擬似コードは分かってたわけだよな。
つまりその時点では意志疎通という意味では擬似コードの方が優秀だったわけだ。
にもかかわらず"常識"とか言うから言われちゃうんじゃ無いの?俺みたいな奴に。

あとやたらプロジェクトって言葉を使う奴も地雷臭がするな。
お前1人でチマチマやってるのの何がプロジェクトだよって言いたくなる。
当然、それなりの規模ならプロジェクトで問題ないけど。

自分を大きく見せようとする奴は要注意。
コメント3件

240
仕様書無しさん[]   投稿日:2017/02/13 07:41:50
>239
fizzbuzzでもプロジェクトだけど?
訳のわからんオレオレ定義振りかざして何言っちゃってんのお前w

241
仕様書無しさん[]   投稿日:2017/02/13 07:48:28
>239
プロジェクトの定義もわからんのか


242
仕様書無しさん[sage]   投稿日:2017/02/13 08:08:11
>239
お前が言葉を知らなさすぎるだけですので

243
仕様書無しさん[sage]   投稿日:2017/02/13 10:24:56
定義の話じゃない。
そりゃ、分類すればプロジェクトだろうよ。
でも、しょうもなくて自分からはプロジェクトなんて恥ずかしくて言えないような案件もあるだろ。
コメント2件

244
仕様書無しさん[sage]   投稿日:2017/02/13 10:44:50
英語の文章を日常的に読むんだから、日本語より先に英語が出てくるのは自然だと思うが

245
仕様書無しさん[sage]   投稿日:2017/02/13 12:00:18
>243
プロジェクトの定義もわからんのか
コメント1件

246
仕様書無しさん[sage]   投稿日:2017/02/13 12:08:24
既存アプリの劣化クローン作ってひとりプロジェクトとか言ってる奴いるよな
なにかっこつけてんだハゲって周りから思われてることも知らずに

247
仕様書無しさん[sage]   投稿日:2017/02/13 12:09:24
>245
日本語が理解出来ないなら反論しなくて良いぞ。

248
仕様書無しさん[]   投稿日:2017/02/13 12:25:44
>243
いや恥ずかしいとかそういう問題じゃないからw
どんなプロジェクトでもプロジェクトはプロジェクト
てかお前の方がなんか勘違いしてんじゃね?w
コメント1件

249
仕様書無しさん[sage]   投稿日:2017/02/13 12:30:02
不要なコメントを削除するプロジェクト

250
仕様書無しさん[sage]   投稿日:2017/02/13 13:22:00
>248
だから日本語分からんのなら反論しなくって良いって。
どんなプロジェクトだろうとプロジェクトはプロジェクトだよ。
これでも分からんか?

251
仕様書無しさん[sage]   投稿日:2017/02/13 18:34:47
プロジェクトひとり

252
仕様書無しさん[]   投稿日:2017/02/13 19:21:40
あ〜あ、ムキになっちゃったw

253
仕様書無しさん[sage]   投稿日:2017/02/13 19:57:25
ムキムキー

    (・∀・ )
  /⌒"ー ― ⌒ヽ
  | (_ (__人 )
 (三0∧ミキ)彡ノヽ )
   ̄ ノー―-イ 0三)
   / ヽレ′ヽ  ̄
  /__/ヽ  \
  \ ヽ  \_ )
   Lノ  | /
        ヒ二)

254
仕様書無しさん[]   投稿日:2017/02/13 20:06:32
一般人が思うプロジェクトのイメージで言われたら普通あきれるよ。

255
仕様書無しさん[]   投稿日:2017/02/13 22:07:56
詳細設計って、C言語設計の名残だろ

OOP対応言語で作ってたら
爆笑しちゃう
コメント2件

256
KAC[sage]   投稿日:2017/02/13 22:19:51
>255
Rational Roseとか知らない世代なんだろうな

257
仕様書無しさん[]   投稿日:2017/02/13 22:25:22
Roseでもmember functionの処理をPseudocodesで書く。
コメント1件

258
仕様書無しさん[sage]   投稿日:2017/02/13 22:30:15
>257
それは詳細設計では?

259
仕様書無しさん[sage]   投稿日:2017/02/14 00:26:19
詳細設計だな

260
仕様書無しさん[]   投稿日:2017/02/14 01:34:15
>255の爆笑はまだなの?

261
仕様書無しさん[]   投稿日:2017/02/14 03:50:10
>255
詳細設計がどんなレベルかによる。

262
仕様書無しさん[sage]   投稿日:2017/02/14 08:18:23
コードにdocかけよ
そこからドキュメントを起こすツールがあるんだから
コメント1件

263
仕様書無しさん[]   投稿日:2017/02/14 08:31:35
>262
それだと文字がメインになってしまう
コメント1件

264
仕様書無しさん[sage]   投稿日:2017/02/14 10:31:21
>263
ソースが文字で見づらいってこと?
コメントなんだから邪魔なら畳めばええやん

265
仕様書無しさん[sage]   投稿日:2017/02/14 12:06:47
図が書けないじゃんってことじゃね

266
仕様書無しさん[sage]   投稿日:2017/02/14 12:50:40
あ〜確かにめんどいな
htmlには出来るけどわざわざタグ書くのめんどいんだよね

267
仕様書無しさん[sage]   投稿日:2017/02/14 13:10:08
そこで罫線ですよ

268
仕様書無しさん[sage]   投稿日:2017/02/14 15:53:13
そこでAAですよ
コメント1件

269
仕様書無しさん[sage]   投稿日:2017/02/14 18:14:08
>268
なるほどaaジェネレータ的なので生成しpreで囲めば行けるかもしれんな…

270
仕様書無しさん[sage]   投稿日:2017/02/14 23:42:43
使い捨てのソフトは設計書いらないけど、長期的に使用する
ソフトは設計書いるよと思う。
設計書の粒度は製品(ソフト)の特性に依ると思う。

271
仕様書無しさん[]   投稿日:2017/02/20 13:29:24
設計書(仕様書)無かったら、3000行程度で混乱する
むしろ500行超えた辺りから頭パンクしそうだし、

用途によるけど、(GUIを除いた)
純粋な処理コードだけなら、200行有れば十分だと思うんだが?
[(基本80*200=16000文字)空白除く]
コメント1件

272
仕様書無しさん[]   投稿日:2017/02/21 00:01:55
>271
1クラス3000行?
1メソッド3000行?
コメント1件

273
仕様書無しさん[]   投稿日:2017/02/21 00:37:01
>272
1クラスだけど?

274
仕様書無しさん[]   投稿日:2017/02/21 12:32:27
お前らって現実に起きている問題には近視眼的なくせに
ソースコードに対峙したとたん全てを把握する神になろうとするよな
要領のいい人とは真逆だよそれ
コメント2件

275
仕様書無しさん[sage]   投稿日:2017/02/21 12:48:37
>274
あるある
ソース書いてる時点なんて問題の殆どが解決してなきゃいけない状態なのにね

276
仕様書無しさん[sage]   投稿日:2017/02/21 14:44:14
>274
> お前らって現実に起きている問題には近視眼的なくせに
え?なに?アフリカの飢餓問題とかそういう話?w
コメント1件

277
仕様書無しさん[sage]   投稿日:2017/02/21 18:29:00
>276
ワカンネーなら食いつくなよカス
コメント1件

278
仕様書無しさん[sage]   投稿日:2017/02/21 18:58:43
>277
ワカンネーなら食いつくなよカス

279
仕様書無しさん[sage]   投稿日:2017/02/21 19:23:27
オウム返しがやっとか
コメント1件

280
仕様書無しさん[]   投稿日:2017/02/21 19:40:24
>279
ワカンネーなら食いつくなよカス

281
仕様書無しさん[sage]   投稿日:2017/03/02 17:26:47
わっかんねー
何もかもがわっかんねー

282
仕様書無しさん[sage]   投稿日:2017/05/21 21:01:50
詳細設計書に動くサンプルコード添付したら協力会社さんに喜んでもらえた
いい仕事をした後は気分がいいな
コメント2件

283
05/22(月) 10:37:40.63 .net[ 概念とそれに対する処理を明確に定義し、全体のアーキテクチャを記述する
これが設計書であり、あとはフォーマットの違いだけだ ]
  投稿日:0000/00/00 00:00:00

284
仕様書無しさん[]   投稿日:2017/05/22 12:28:09
どうやら「僕が考えた最強の設計書」のようだけど残念ながら意味不明

285
仕様書無しさん[]   投稿日:2017/05/22 14:37:25
意味わからんだろ?
所詮その程度の頭ってことだ
コメント1件

286
仕様書無しさん[sage]   投稿日:2017/05/22 15:03:24
>285
なんで自分の公開批評してんの?

287
仕様書無しさん[sage]   投稿日:2017/05/22 22:56:07
>282
同じ様な事あって、配列の添え字にまた配列とか配列使いまくりだったから、
思いっきりポインタにしてやった事あるなぁ〜。
今思えば無駄な自己主張だったなぁ〜。

288
仕様書無しさん[sage]   投稿日:2017/05/25 10:05:53
>282
まさに重要なのは動くサンプルコードであって
詳細設計書なんていらないって話だなw

289
仕様書無しさん[]   投稿日:2017/05/28 21:39:22
ウチの会社は部署によってやり方が全然違うんだけど
今度のところはソースをExcelに張っつけたのが詳細設計書

以前のところも少ない人数で我流でやってて色々問題を感じていたけど
今回はさすがにちょっと驚いた

でもまー古い既存システムの改修がメインだから
どうやれば正解と言えるのかは実際には難しいんだけどね・・・

290
仕様書無しさん[]   投稿日:2017/05/28 21:42:44
あともう1つ驚いたのが
ソースにコメントをロクに書かないという慣習
なんかそれに美学でも持ってるようだwww

僅かに書いてあるコメントも奇妙な言葉使いでほとんど暗号
職人の世界のようでもあるが、とてもアホらしいwww

291
仕様書無しさん[sage]   投稿日:2017/05/29 00:26:54
設計書だってフローチャートだってあるのに、
なんでコメント書かなきゃならないんだ?
コメント1件

292
仕様書無しさん[sage]   投稿日:2017/05/29 00:34:51
設計書だってフローチャートにかかれている情報は
概要でしかないから。ほんの一部でしかないし
概要からは省くような詳細な情報がコメントとして必要

293
仕様書無しさん[sage]   投稿日:2017/05/29 01:25:01
未だにウォーターフォールモデルで開発やってんのか

294
仕様書無しさん[sage]   投稿日:2017/05/29 03:16:11
>291
あるのに?
なかったらどーすんの?
あっても間違ってたり古い仕様だったらどーすんの?
ソースを読めばいいとでも?
flagという変数を使うクソ野郎もたくさんいるぞ。
せめて何のフラグかコメントしとけば読みやすくなる。
なぜかコメントを邪魔なものだと思ってる人も多いが、
実際は逆なんだよ。
百利あって一害なしだ。
コメント2件

295
仕様書無しさん[sage]   投稿日:2017/05/29 05:43:38
>294
コメントは行数を増やすためだけのモノ

296
仕様書無しさん[sage]   投稿日:2017/05/29 07:33:21
>294
仕事でコード書いたことないんだろうな
コメントはコードと同期しないし
コメントを書き換えるのが面倒だからと変な修正をする奴も居る
プライベートのリポジトリ以外ではコメントを禁止した方が良いぞ
コメント1件

297
仕様書無しさん[sage]   投稿日:2017/05/29 09:41:38
>296
カスしかいない職場で働いてるんだな
かわいそうに

298
仕様書無しさん[sage]   投稿日:2017/05/29 10:49:21
基本、自分も含めてカスだと思う事が不具合を出さない工夫だと思うけどな。
コメントとコードが一致しないなんてのは普通にあるから、むしろコメントを書かないって選択も有効

299
仕様書無しさん[sage]   投稿日:2017/05/29 11:21:21
一致してないなら直してやれよ
と思うんだけどなぁ
まぁめんどくさいのはわかるけどさぁ
コメント1件

300
仕様書無しさん[sage]   投稿日:2017/05/29 13:25:50
>299
一応言っとくが、コメント直しても試験やり直せよ?
コメント1件

301
仕様書無しさん[sage]   投稿日:2017/05/29 13:48:23
>300
やり直すわけないだろ
バカか?
コメント消したらなぜか動かないとかいつの時代だよ
ていうかビルドと自動テストで十分なレベルだろ
コメント1件

302
仕様書無しさん[sage]   投稿日:2017/05/29 14:14:10
いまどきは修正したコードが通るパターンを通すだけだからなぁ〜。

303
仕様書無しさん[sage]   投稿日:2017/05/29 16:25:07
てか、IDE使ってるならコメント行非表示にする機能あるだろ?
邪魔だと思ったら表示しなければいいだけ。
なんかさ、一部の勘違い野郎は自分が基準で周りも自分に合わせてくれると
思ってるみたいだが、そんな考え方してると仕事できないだろ。
周りを自分に合わせようとするのはやめれ。
自分が周りに合わせなよ。
コメント1件

304
仕様書無しさん[sage]   投稿日:2017/05/29 16:43:03
>303
> 周りを自分に合わせようとするのはやめれ。
> 自分が周りに合わせなよ。
両方バランス良くあるべきだと思うよ
クソな環境は可能なら正すべきだし、微妙なラインは妥協すべきだろうし

305
仕様書無しさん[sage]   投稿日:2017/05/29 20:18:00
ドキュメントコメントからXMLを生成する
そのXMLにはデータやスクリプトが埋め込まれてる
それらがないとまともに動かない
そんなクソシステムを保守させられて以来コメントを見ると吐き気や頭痛に襲われるようになってしまった
コメント1件

306
仕様書無しさん[sage]   投稿日:2017/05/29 23:18:59
>301
あほか
ソースファイル更新したら試験は必須
お前、働いたことすら無いだろ?
コメント1件

307
仕様書無しさん[sage]   投稿日:2017/05/29 23:39:30
>306
よっぽど暇と人がある部署でダラダラと働いてるんだね
コメント2件

308
仕様書無しさん[]   投稿日:2017/05/29 23:44:13
>307
いまどきテストじゃなくて試験(笑)って言ってるアレな人だから、あんまり刺激するなよ
コメント1件

309
仕様書無しさん[sage]   投稿日:2017/05/30 00:28:18
phpunitとかjunitに通すってことじゃない?
コメント1件

310
仕様書無しさん[sage]   投稿日:2017/05/30 00:41:09
>308
試験とテストは意味が違うから
コメント1件

311
仕様書無しさん[sage]   投稿日:2017/05/30 00:41:48
>307
こういう馬鹿がいるから事故が起きる

312
仕様書無しさん[sage]   投稿日:2017/05/30 01:09:20
>305
俺はPL/SQLで頭痛がする(1関数5000行の衝撃)

>309
「試験」と言ってる人はおそらく業務系かつ基幹系で、年期入ってる人のようだから
「テスト仕様書記載の項目を手作業でチェックし直し」のことだろう

diff取ってコメント欄しか変わってないならテスト不要だろうが
版管理使ってない所なら誤爆タイプ(ソースを探してるときになんか a とか誤タイプしちゃうアレ)の
チェックって意味でやってもいいかも

俺だったらgitかsvnでローカルに保存しといてdiff取ると思うが
現場によっては勝手にアプリ入れるな、申告しても「そんなツールはダメ」の場合がある
diffっつかWinMergeの類すらもダメ(だからフォルダ別保存でdiffも取れない)
まぁそんな環境ならコメント直しただけでもテストやり直しってのはあるかも

その手の現場で「試験とは不具合を見つけるのが目的、検査表が一回目で全部〇になるのはおかしい」
とか言われたの思い出したことあるな
事前にテスト用コード書いて流して直したりしたんでエラーないのわかってたんだが
以後無作為に1〜2コ×にして、二回目欄に〇にするとかやったな

313
仕様書無しさん[sage]   投稿日:2017/05/30 01:45:08
> その手の現場で「試験とは不具合を見つけるのが目的、検査表が一回目で全部〇になるのはおかしい」

理屈はわからなくはないけど、じゃあ検査表が全部○になるのは
だいたい何回目ぐらいですか?って聞きたくなるな。


試験が不具合を見つけるものであるならば、
試験より前に不具合を見つけるのはやったらいけないのか?

試験より前に不具合を見つけなければ、
それは何十回も試験しなければ全部○になることはないだろう。
どうせその工数入れてないくせに
コメント1件

314
仕様書無しさん[sage]   投稿日:2017/05/30 02:25:20
>313
なんかよくわからんが、そこの検査表は確か5回目まで欄があったから
あの会社では5回までミスることがあったんだろう

xxxxxをドコソコに入れると何とかと表示されること | × | 2009/3/23 | 〇 | 2009/3/24
yyyyをドコソコに入れるとホゲホゲの値が入ること | 〇 | 2009/3/23 |

みたいなフォーマットだったかな、たしか
まぁ一発書きして適当に手入力で値入れて、そっからテスト仕様書見て動かしてたんじゃないか? 知らんけど……
コメント1件

315
仕様書無しさん[sage]   投稿日:2017/05/30 02:29:49
だいぶ昔か、俺も年食ったな……なんかハンコつくだけでカネがすげぇ入ってくる仕事ない?
あったらカネもらって万札握りしめてサーバラックとか買いに行っちゃうよ

316
仕様書無しさん[]   投稿日:2017/05/30 08:19:37
せめてコメントちゃんと書いてくれれば
開発の能率がだいぶ上がることはみんな分かっているはずだと思うが

どうやら「ソースで読む」ことを楽しんでいるようだw

317
仕様書無しさん[sage]   投稿日:2017/05/30 08:56:21
コメント不要って言ってる人たちは、コメントがいらないということを主張したいんじゃなくて、
コメントいらないくらい綺麗なコードを書いてる自分アピールなんだよ
そりゃ自分で実装したコードなら、無茶苦茶な英語で関数や変数の命名してても、コメントなしで読めるよねっていうw

318
仕様書無しさん[sage]   投稿日:2017/05/30 08:57:31
>310
じゃぁ試験って英語の単語はなんですか?

>314
NE○だろ
そこの子会社に派遣されてた頃、本部から押し付けられたてたっぽい
かれこれ数年前の話だな
コメント1件

319
仕様書無しさん[sage]   投稿日:2017/05/30 09:38:20
コメント修正くらいじゃコンパイル結果の比較くらいしかしないなぁ。
で、なぜか一致しないんだよなw

320
仕様書無しさん[sage]   投稿日:2017/05/30 19:19:02
>318
英語と日本語が一対一だと思ってるのか?

鱒は英語でなんて言うか知ってる?
コメント1件

321
仕様書無しさん[sage]   投稿日:2017/05/30 21:32:52
>320
めんどくさいやつだな

プログラミング系なんて英語圏から来ている文化なんだから、
独自文化でもない限り英語で定義されてるだろうに

英語わからないなら、日本語でいいから違いを説明して見てよ
コメント1件

322
仕様書無しさん[sage]   投稿日:2017/05/31 00:47:15
>321
日本の品質管理は英語圏とは全く違うんだが。。。
コメント1件

323
仕様書無しさん[sage]   投稿日:2017/05/31 07:27:11
「僕ちゃんは絶対正しいの!白いカラスはいるの!!」
プログラマーってこんなんばっか
コメント3件

324
仕様書無しさん[sage]   投稿日:2017/05/31 07:32:05
>322
はいはい、日本語でも説明できないのね

325
仕様書無しさん[sage]   投稿日:2017/05/31 07:57:05
>323
いるぞ?

326
仕様書無しさん[sage]   投稿日:2017/05/31 09:28:55
アルビノからすか。

327
仕様書無しさん[sage]   投稿日:2017/05/31 09:33:17
ソースコードと同等レベルに詳細な設計書だって何の意味があるのか分からない
それソースコードで良くね
コメント1件

328
仕様書無しさん[sage]   投稿日:2017/05/31 09:39:10
>327
客からすればなんの意味もない
提供する側としては余分に金をもらえるチャンス
同じ金額でそのドキュメント作らされるならふざけんな

329
仕様書無しさん[sage]   投稿日:2017/05/31 09:47:05
ググッたら、白いカラスかわええなw

330
仕様書無しさん[sage]   投稿日:2017/05/31 10:13:27
自然界でも変わり者はイジメ頃されるんだなぁ

331
仕様書無しさん[sage]   投稿日:2017/05/31 19:14:35
>323みたいな思い込み激しいやつが居るとプロジェクトは苦労する

332
仕様書無しさん[sage]   投稿日:2017/05/31 19:17:48
ソースコードを日本語に変換するツールを作れば儲かるね
コメント1件

333
仕様書無しさん[sage]   投稿日:2017/05/31 19:39:32
>323
やぶ蛇でしたね

334
仕様書無しさん[sage]   投稿日:2017/05/31 21:30:54
自然言語からコードは難しいけどコードから自然言語への変換はそうでもないんじゃないかな
構文木からコードを生成するのと同程度の手間で自然言語を生成できるはず
めちゃくちゃ機械的で読みにくいドキュメントになるだろうけど
設計書原理主義者の言うコードと一対一で対応する設計書を作る唯一の手段だと思う
コメント1件

335
仕様書無しさん[]   投稿日:2017/05/31 21:39:22
>334
設計書原理主義者ってなんだ?
コードと一対一で対応する設計書ってのも初めて聞いた

設計書が書けなすぎて仮想敵を作りだしてしまったんじゃないかお前?
コメント1件

336
仕様書無しさん[sage]   投稿日:2017/05/31 21:47:51
>335
過去ログを読めばわかるけど
時々いるんだよそういうのがね

337
仕様書無しさん[sage]   投稿日:2017/05/31 22:39:50
日本のSI系は無駄にドキュメント量が多い。
昔から疑問だったのだが、皆それが合理的だと思っているの?

因みにUSのエンタープライズなプロジェクトを数年やっていたのだが文化が全然違う。
フローを説明すると、初期の詳細設計フェーズでのドキュメントは説明用のパワポ数枚程度で、
アーキテクトと呼ばれる人達が直接コードを書き始める。
設計の説明に関係ない所はモックかインターフェース定義のみになっていて、
データ構造の定義も含まれる。プロジェクトが本格稼働しエンジニアが増え始めると、
アーキテクトはコードを書かなくなりコードレビューに回るという流れ。
ドキュメント類(データ構造仕様書、API仕様書,etc.)は基本ソースコードから出力される。

日本的な人月換算で言うと1000人月位のプロジェクト規模かな。
(それ以上に大きくても小さくても基本的には同じフロー)
日本のSIerが上記の様な開発ができないのは何が問題?
コメント3件

338
仕様書無しさん[sage]   投稿日:2017/05/31 22:48:48
>337
日本ではコードを書けないクズが指揮をとるからね

339
仕様書無しさん[]   投稿日:2017/05/31 22:53:47
いきなり詳細設計から始められる程度に単純な仕事しか経験がなかったら
そら「設計書いらねー」ってなるわな
無理もない
コメント1件

340
仕様書無しさん[sage]   投稿日:2017/05/31 22:57:56
小さい規模の案件でもいきなり詳細設計は無理だろ
コードを書きながらリファクタリングしながらドキュメントを書かないと整合性取れん

341
仕様書無しさん[sage]   投稿日:2017/05/31 22:59:14
まだお前らウォーターフォールモデルで開発してんのか

342
仕様書無しさん[sage]   投稿日:2017/05/31 23:06:55
>339
じゃあその「単純じゃない仕事」と類似したUSの事例を調べてみてくれ。
それともUSには「単純な仕事」しか無いとでも主張するのかな?

因みにコミュニケーションコストが日本の方が高いという事もない。
何故なら向こうでは人種も宗教も多様なので、
日本的な"常識"を元にしたコミュニケーションが通用しない。

343
仕様書無しさん[sage]   投稿日:2017/05/31 23:11:05
>337
コード書いた経験がないか極端に少ない人間が上に立つからだよ。
彼らは自分でコード書いたことある人なら誰でも分かってることを理解していない。
だから、客から聞き取った要件をどうコードに落とすか想像できない。
設計書というのは要件をどう実現するかという書類なのに、
コード書いた経験がないから意味不明なものになってしまう。
俺は必ず彼らが書いた設計書をリライトするようにしている。
そうしないと、俺の下で働いてる若手が設計書と何時間もにらめっこすることになるからね。
日本もエンジニアがもっと認められて出世しないとダメだと思ってるよ。
そのためにはコードだけ書いてちゃダメで、経営のことも勉強しなきゃならないけど。
大変やね。

344
仕様書無しさん[sage]   投稿日:2017/05/31 23:23:38
自分は日本のSI系はまだ競争が穏やかだった為、合理化圧力が緩かったと考えている。
ただ昨今の人手不足や労働時間規制で合理化圧力が高まっているので、今後健全化する方向に進む可能性も有るかな。

345
仕様書無しさん[sage]   投稿日:2017/05/31 23:24:18
>332
富士通のいんでぶとか、あるっちゃあるよ
仕様書と辞書(単語をコードに変換する規則集)を突き合わせてコードをゲロるの
内容に関しては、みずほの件でお察しください

>337
極端に言ってしまえば日本では「仕様書」にこそ価値があると考えられているから
あるいはコードそのものは単なるパンチカードの紙切れと同じものだ、とでも言うべきか
まあ実際のところそこまで極端な表現をしやしないし、コードもある程度は大事ってのはわかってるんだが
すんげー強調した言い方だと「仕様書のほうが価値が高い」と判断する人は発注元には多いんじゃないだろうか

仕様書をパンチャーに渡せば同一品質あるいは同一内容のコードが出てくるはず、と
メインフレーム時代からそういう価値観を育んできたわけ
日本は世界一速くメインフレーム時代に突入して、世界一長くメインフレーム・オフコン時代過ごしたんで
どうしても昔流の文化ってか「机上の設計が大事」の文化が抜けきらないし
たぶんあと100年くらい「設計書が大事」主義からの脱却はムリじゃねえかな

346
仕様書無しさん[]   投稿日:2017/05/31 23:31:17
いつまでもグズグズ言ってないで少しはSEの人を納得させられる設計書書く努力したら?
所詮お前らはコードを書いて設計書でっちあげるだけの派遣コーダーなんだから
人間、身の程を知るって大事な事だぜ
コメント2件

347
仕様書無しさん[]   投稿日:2017/05/31 23:33:41
今の国内SIerの競争力の無さを考えると100年とか待ってたら
他業種の競争力を支えるはずのSIerが逆に足を引っ張って日本ごと沈没しそう
コメント1件

348
仕様書無しさん[]   投稿日:2017/05/31 23:36:45
>346
自己紹介乙

349
345[sage]   投稿日:2017/05/31 23:45:48
時折「マなんかバイトで十分、SEは設計だけするべき」論の人がいるのは
設計書さえあればSEが想定した品質のコードが上がってきて当然(=コードには価値がない)
って論調が一定数存在する証拠でもある

問題は、アセンブラがもっと高級な言語に切り替わってしまった時点で
設計書(まあ日本語とかフローチャートのアレ)とコードが1対1で対応しなくなってしまい
設計書が単なる「意識合わせの書類」に化けてしまったことだが……

350
仕様書無しさん[sage]   投稿日:2017/05/31 23:52:41
大した実力もないPGが、SEさえいなければうまく回るって声を大にして主張してんの笑えるな
なんかの受け売りで熱くなってるんだろうけど、身の丈に合った発言しろやw
コメント2件

351
345[sage]   投稿日:2017/05/31 23:56:20
>350
俺のことか?

業務系のドキュメント書きタスクの負荷が重い理由を
説明しようとしているだけだが

352
仕様書無しさん[sage]   投稿日:2017/06/01 00:12:03
>350
冷静に非合理的なフローに対する分析もできない頭とは可哀想。

所で、日本のSIerに勤めた事が無いせいかPG/SEという区分にも違和感を感じる。
System Engineerって本来保守サポート要員の事なので、
日本以外でSEと名乗るとかなり軽く見られるので注意。

353
345[sage]   投稿日:2017/06/01 00:41:55
まぁ日本には「仕様書に価値がある」ということで
Σプロジェクト(コードジェネレータ + 専用OS・ハード開発)を試みてオオゴケしたとか
日本は世界に先駆けて積極的に業務でコードジェネレータ使ったとか(主に金融とか自治体のフレームワーク用)
そういう独特の文化がある

日本のSIにおけるドキュメント重い問題の解決策は今のところ
「仕様書からコードを生成する超高速開発ツールの使用」以外ないと思う
まぁ「超高速開発」のアレはAccessのアレ程度の機能しかないんで
規模が大きくなるとみずほになるが
コメント1件

354
仕様書無しさん[sage]   投稿日:2017/06/01 00:43:47
んだよフレームワーク用て……メインフレームだろ……ワロス……orz

355
仕様書無しさん[sage]   投稿日:2017/06/01 00:44:37
>347
すでに手遅れ
日本はITから滅びる

356
仕様書無しさん[sage]   投稿日:2017/06/01 00:47:45
>353
仕様書からコードを生成するには
仕様書が機械可読で曖昧性が全くない状態でなければならない
そこまで行くともう生成するまでもなくコードだよね
コメント1件

357
仕様書無しさん[sage]   投稿日:2017/06/01 00:58:39
自然言語からプログラミング言語を出力するという発想がなー
そもそもステートマシンを記述するための形式言語ではない物で記述しようとすると
機能が大幅に限られるか、記述量が膨大になるかの何方かだからな
形式言語にすると実質プログラミング言語になるし

要件を入力してコードを出力するAIが登場すると変わるだろうけど
そんな物が登場したら、そもそもその過程で社会の有り様が変わるので
SI業界がとかそういった問題では無くなるなw
コメント1件

358
仕様書無しさん[sage]   投稿日:2017/06/01 00:59:37
>356
実際のところ、特定の単語とクラス定義をセットにして
コードゲロったりCREATE TABLEったりして、Insertしてデータ中出しする程度の話
ちょっと変なことするなら独自のスクリプトを書く
仕様書でイジるのは文字数とかその辺

たとえば、仕様書に「給与」って単語が出たら、給与テーブルおよびそれをCRUDするクラスとメソッドが
データ辞書からコピペされる
あとはAccessのあの図よろしく主キーとか引っ付ければできるよねってハナシ
よくある詳細設計書のフォーマットで書けばそれっぽいのができるって感じかな

機械可読とか曖昧性がないって計算機工学の話じゃなくって力業やで
……曖昧性については、確かデータ辞書に定義突っ込むときに類義語をハネる機能があったと思うが

359
仕様書無しさん[sage]   投稿日:2017/06/01 01:03:56
>357
「限られる」のほうやね

例えば「あなたへのオススメ: ドラッガーを読んでも勝てないと悟った女子マネージャーが肉体を駆使したら」
みたいなレコメンドエンジンつけようとしたら死ぬと思う

360
仕様書無しさん[sage]   投稿日:2017/06/01 01:15:45
自然言語からのコード生成は昔から研究されていて
限界を示すある程度の証明が成された論文があった気がするのだが
どうしてそんな方向性に進もうと考えたのだろうか?よく分かってない人達を騙す用?
コメント1件

361
仕様書無しさん[sage]   投稿日:2017/06/01 01:24:23
>360
だますというより……たぶん、相手方のエラい人にITの素養がある人がおらず
(こっちからしたら)常識のことが(相手には)理解できないので
レベルを下げに下げて下げまくって日本語でわかるように説明しなければ
カネが出てこないせいかもしれない
あるいは、日本語でそれっぽい文章がないと(相手からしたら不満点の指摘ができず)怖いのかもしれない
俺の個人的な意見だけど

一番やっかいなのは、相手の企業さんが自社の業務フローを説明できないことか
個人的にはこっちのほうが問題だと思うんだが、まぁこっちは100年どころか1000年無理かもな

362
仕様書無しさん[sage]   投稿日:2017/06/01 01:25:54
あー、酔っ払ってどうでもいい話を長々と済まん

……ノートPCの修理が雨で中断(傷埋めてパテ埋めまでしたが)、ここで酒を飲んだのがいけない

363
仕様書無しさん[sage]   投稿日:2017/06/01 01:26:06
開発者「限界は有るが少しは役に立ちそうなので作ってみた」
分かってない上司「これで全て行けるんじゃね?」
分かってない営業「これで全て解決ですよ」
分かってない顧客「じゃそれで行こう」
開発者「...」
みたいな感じ?
コメント1件

364
仕様書無しさん[sage]   投稿日:2017/06/01 01:30:10
>363
開発者が主導ってことはたぶんないかも
あるとしたらパッケージソフトの外販だけ

内製であったとしても各部署からのご連絡が先
外からの仕事ならまず相手企業から営業にそういう連絡がある感じ

365
仕様書無しさん[sage]   投稿日:2017/06/01 02:02:28
めちゃくちゃな設計から目をそらしてコード生成でなんとかしようとするのって典型的なアンチパターンだよね
コード生成があるから大丈夫つって当たり前のように非正規系で大量の列がある制約がぶっ壊れたマジキチテーブルを量産するバカSEは死んでくれ

366
仕様書無しさん[sage]   投稿日:2017/06/01 06:52:05
>346
SEの人は何をやる人なん
サボる係?

367
仕様書無しさん[sage]   投稿日:2017/06/01 10:39:03
この問題はPG側の要因も大きい。
実際の話、いくら設計書が大切と言っても、顧客が本当に欲しいのは動くシステムなんだ。
エクセルだかワードのクソ設計書じゃない。
設計書じゃ金儲けできないからね。
「ドキュメントはいいからシステム作ってよ」
とPGに言うと、
「仕様がわからないと無理ですぅ」
となるわけだ。
つまり、俺らが顧客の要件をまとめて形にできるところまで一括してできれば、
クソ設計書の量を減らせるってわけだ。
マジでコードだけ書いてちゃダメなんだよ。
技術という殻に閉じこもって営業批判するだけじゃ、俺らの評価は低いままだ。
コメント1件

368
仕様書無しさん[sage]   投稿日:2017/06/01 11:40:25
>367
そもそもAgile的なフローじゃ駄目なの?
日本では大規模なAgile回した経験者が居なくて厳しい感じ?
コメント1件

369
仕様書無しさん[sage]   投稿日:2017/06/01 11:43:30
ここでは一人前ぶってるけど職場ではSEの言いなりだからな
だって、できるプログラマの受け売りしてるだけだから、「そこまで言うなら責任与えるからやって成果出してみろ」って言われたらなにもできないもんねw

370
仕様書無しさん[sage]   投稿日:2017/06/01 12:03:59
そもそも日本的なSE/PGというroleの分けられ方がイマイチ分からないのだが意味有るのそれ?
世界から不合理とディスられまくってる日本のSIer固有文化じゃん。

今後、日本のSIerでも合理化圧力が高まるだろうから、
俺はSE/PGだからと謎のroleで自らの役割を制限しているエンジニアはそのうち困ると思うよ。
コメント3件

371
仕様書無しさん[sage]   投稿日:2017/06/01 12:21:36
>370
自らの役割を制限しないと、なんでもやらないといけなくなるじゃんw
ただのサラリーマンなんだし、それなりに食っていけるぐらいの給料さえもらえてれば、やることは少ないに越したことはない
コメント1件

372
仕様書無しさん[]   投稿日:2017/06/01 12:24:41
>370
お前が無能だからカゴに入れて飼われてるんやでコーダー君
能力があるやつはそれでも自分でカゴから出てくんねん
コメント1件

373
仕様書無しさん[sage]   投稿日:2017/06/01 12:43:35
>371
その合理性の無いrole分けに疑問を抱かないのか?という話。
無限の役割を求める訳じゃない。

>372
お前も日本のSIerというカゴから出てみたら?
コメント2件

374
仕様書無しさん[sage]   投稿日:2017/06/01 12:48:23
>373
やること増やしたくない人にとっては合理的

375
仕様書無しさん[]   投稿日:2017/06/01 12:57:40
>373
君の相談にのってあげとんのやで無能コーダー君
話をそらして自分の問題から目をそむけてたらいつまでたってもなんも解決出来んで
コメント1件

376
仕様書無しさん[sage]   投稿日:2017/06/01 13:11:23
>368
最近はそうでもないんじゃない?
ソーシャルゲームなんかはユーザ百万人規模のシステムを延々とアジャイルで回してるからね。
俺もソーシャルゲームに関わったことあるけど、完全にアジャイルでやってると
必然的にミスが多くなるんだよ。
ゲームだったら謝罪文とアイテムばら撒いて終わりだけど、他の業種はそうもいかない。
金融機関は特にそうだよね。
いくら設計書は少ない方がいいと言っても、アジャイルはリスクが高すぎる。
コメント1件

377
337[sage]   投稿日:2017/06/01 13:21:04
>375
無能はH1-Bとれないんやで?万が一取れても無能さらすと即クビになるしな。
まあお前には縁の無い話かもしれんけど。

しっかしまともに自らの業務の効率化の話ができる人が少ないな。
顧客の業務を効率化する事が大きなミッションのはずなのに。

378
仕様書無しさん[sage]   投稿日:2017/06/01 13:26:44
>376
業務系こそAgileやで。元々エンタープライズな所から出てきた考え方だし。
分かりやすい事例も海外だと多いよ。
コメント1件

379
仕様書無しさん[sage]   投稿日:2017/06/01 13:44:34
>378
だから案件によるとしか・・・。
小規模で責任がない案件ならいいんだけどね。
アジャイルのデメリットは品質を担保する機能が小さいかまったく無いってとこなんだよ。
だからそのシステムを知ってる人間を業務に縛りつけてしまう。
俺なんか1月1日に女房子供置いて実家から東京に始発の新幹線で戻ったこともあるよ。
しんどいぞアレは。

380
仕様書無しさん[sage]   投稿日:2017/06/01 14:35:18
MSやGoogleが未だに完全なウォーターフォール型で作ってるとか
そんな事はなかろう

381
仕様書無しさん[sage]   投稿日:2017/06/01 15:10:37
なんでお前らってゼロサム的な考え方しかできないの?
コメント1件

382
仕様書無しさん[sage]   投稿日:2017/06/01 16:24:24
完全にウォーターフォールなんて所まだ存在してんの?

ウォーターフォールって数ヶ月や数年先の事を考えて計画するんでしょ?
数年先の事まで完全に予想するなんて神でもなきゃ無理じゃね

一度作ったら作り直しが難しい建築業界はそれで良くても
ソフトウェアでそれやったら他社に置いていかれるじゃん

383
仕様書無しさん[sage]   投稿日:2017/06/01 16:24:58
>381
NG: お前ら
OK: 俺ら

384
仕様書無しさん[sage]   投稿日:2017/06/01 16:28:07
>小規模で責任がない案件ならいいんだけどね。
>アジャイルのデメリットは品質を担保する機能が小さいかまったく無いってとこなんだよ。

Agileのフレームワークってスプリント毎に見直しが入って、
プロジェクトが進行する過程で起きる様々な問題点に対応しやすい事がメリットだと思うのだが、
それによって品質に対する責任問題が起きるのって全然別問題じゃね?
っていうかフレームワーク的に問題が起きたのであれば見直しが入り是正されないといけない。

だた、日本は規模が大きく外注/派遣が多い開発では、
開発者が品質責任を主体的に果たしにくいってのは聞いたこと有る。
その様な問題の事を指している?

385
仕様書無しさん[sage]   投稿日:2017/06/01 16:49:50
アジャイルは日本でそれほど浸透している訳ではないので
まだまだ定義自体、人に依って違う

386
仕様書無しさん[sage]   投稿日:2017/06/01 17:08:18
ウォーターフォールで最後まで軌道修正されないと
この記事のようになるんでしょ?

顧客が本当に必要だったものとは (コキャクガホントウニヒツヨウダッタモノとは) [単語記事] - ニコニコ大百科
http://dic.nicovideo.jp/a/%E9%A1%A7%E5%AE%A2%E3%81%8C%E6%9C%AC%E5%BD%...

387
仕様書無しさん[sage]   投稿日:2017/06/01 17:10:58
NECでさえアジャイル開発始めてきてるのにお前等ときたら

388
仕様書無しさん[sage]   投稿日:2017/06/01 17:38:43
アジャイルならその辺のサラリーマンPGでもいいシステムを作れるようになる

389
仕様書無しさん[sage]   投稿日:2017/06/01 17:58:46
>アジャイルならその辺のサラリーマンPGでもいいシステムを作れるようになる
それはどうだろう?
Agileな仕組みで回そうとしたら開発者に求められるスキルもそれなりに必要。
ただ全員高いスキルが必要なわけでもないし、ナレッジシェアもしやすいけどね。

390
仕様書無しさん[sage]   投稿日:2017/06/01 18:48:22
アジャイルというかプログラミングの基本である分割統治を徹底するだけだろ
丸ごと設計して丸ごと実装っていう流れがいかにアホなことか
サービスをコンテキストで分割してそれぞれアジャイルで回して行けばいいんだよ

391
仕様書無しさん[sage]   投稿日:2017/06/01 18:59:39
偉い人にはそれがわからんのです

392
仕様書無しさん[]   投稿日:2017/06/01 19:03:13
お前ら本当にアジャイル好きだよなwうけるw
コメント1件

393
仕様書無しさん[sage]   投稿日:2017/06/01 20:57:41
>392
下っ端PGがなw
じゃあお前やってみろよって言われたらできないんだぜw
ま、野球見て監督の采配批判するのに野球経験はいらないからな

394
仕様書無しさん[sage]   投稿日:2017/06/01 21:34:11
アジャイルなんてただのプロセスだからね
導入したからってお前らの能力が上がるわけでもない

395
仕様書無しさん[sage]   投稿日:2017/06/01 22:09:26
電卓なんてただの道具だからね
導入したってお前らの能力が上がるわけでもない

こうですかね?

396
仕様書無しさん[sage]   投稿日:2017/06/01 22:28:13
むしろ今時アジャイルベースの開発を検討してない所ってヤバない?
金融系でさえアジャイル言い始めているのに
SIのレベルが著しく低い日本で上手く行くかは知らんけど

397
仕様書無しさん[sage]   投稿日:2017/06/01 23:21:08
うちに会社(メーカー)はウォーターフォールで開発。
アジャイルにしたらもっと良い製品作れるかな?
コメント1件

398
仕様書無しさん[sage]   投稿日:2017/06/01 23:28:35
>397
普通にええんじゃないの?
Teslaとか車をアジャイルで作ってて上手く行ってるらしいし

399
仕様書無しさん[sage]   投稿日:2017/06/02 00:04:59
今日は酒入ってねえぞっと……ヤケ酒はいかん orz

>370
SEとプログラマーは「設計者」と「パンチャー」の関係
今だと「パンチャー」ではなく「コード奴隷」とでも言うべきか

少なくとも、1次受けとかユーザーに近ければ近いほどそういう発想が優勢

400
仕様書無しさん[sage]   投稿日:2017/06/02 00:30:52
日本は

・顧客自身が要求仕様を書けない(業務のマニュアル化ができなさすぎるし、できる人材を雇ったり教育することはない)
・要件変更の柔軟性要求・瑕疵担保の要求がキツい

っておっそろしい状況があるので一応SE/PGの区分には合理性がある
SEは「客との折衝」と「瑕疵担保責任」を負担する
特に大規模プロジェクトではメー子か大手しか受けられない、瑕疵担保っつか遅延損害金支払い能力の有無で

PGはまぁ一応、瑕疵担保は限定的
そのプロジェクトがgdgd過ぎたら親請けがカネよこせってことはあり得るにせよ
その代わり、親請けが書いた設計書に近いことしかできない
(「仕様書の通り」は95%くらいの確率でありえない、特にエラー処理)
設計書の文言にそう書いてるっぽいこと以外のコトをやったらこっちが瑕疵担保責任取ることになるんで

401
仕様書無しさん[sage]   投稿日:2017/06/02 00:32:54
ベンダー企業がウダウダやってる内に
愛想を尽かしたユーザ企業は内製化に舵をきるのであった
多分近々発表される内製化に関する話がやばば
現場のエンジニアの人にとっては悪い話ではないかも知れないけど

402
仕様書無しさん[sage]   投稿日:2017/06/02 00:36:37
どういやいいのかな、要件は決まってないけど品質や納期は製造業グレードの要求、が日本ではデフォルトだから
日本のSI仕事は(おそらく)海外に比べてリスクがでかい

昔だったら(銀行様がメインフレーム入れてたような時代)だったらそのリスクがペイする程度のカネにはなったが
ダウンサイジングだとかオープンがどうとかそういうので単価下がりまくってしまったので
まぁビジネスとしてはアレだわね
そりゃ介護並みの重労働・低賃金な見られ方をするわな

403
仕様書無しさん[sage]   投稿日:2017/06/02 00:57:00
アジャイル・コング

404
仕様書無しさん[sage]   投稿日:2017/06/02 03:04:29
「アジャイルはイイ!」とみんなが言うと、お前らも「イイ!」と言う
馬鹿ですか?
コメント2件

405
仕様書無しさん[sage]   投稿日:2017/06/02 03:55:44
>404
イイというつもりはない、どっちかってとあきらめかなぁ

手戻りなしのウォーターフォールですべてが一発で動くなんてあり得ない
ずっとそうあるべきだと信じて努力したけど俺にはわからんことのほうが多かった
だから最速で結合までもっていって早期にミスを狩りだして直すしかない

その程度だと思う

406
仕様書無しさん[sage]   投稿日:2017/06/02 05:50:48
設計する
製造する
試験する
販売する

ウォーターフォールってこういうことだろ
基本的に不具合修正以外は試験のフィードバックなし
つまり試験で判明した不足機能の追加や品質改善はしないわけだ
対象がシステムだから誤魔化せてるけど
これが普通の製造業だったらそんなことあり得るのか?
製造業って最初に作ったプロトタイプをそのまま商品にするものなの?
普通は何度か試作品を作って検討するんじゃないの?
それってアジャイルじゃないのか?
コメント1件

407
仕様書無しさん[]   投稿日:2017/06/02 06:11:18
プロトタイプは上流で作成、検討されてるだけでお前らの仕事ではないというだけのこと
無理だろお前らにはwやさしい世界なんやでw

408
仕様書無しさん[sage]   投稿日:2017/06/02 09:28:18
>404
自分で馬鹿な話考えて
自分の話が馬鹿だなって言ってんの?

409
仕様書無しさん[sage]   投稿日:2017/06/02 11:49:46
俺らの一番悪いとこは自分は優れてる、自分が正しいと思ってることだよね。
コメント1件

410
仕様書無しさん[sage]   投稿日:2017/06/02 12:21:14
>409
誰しもそんなもんさ
上司の悪口言ってるサラリーマンなんてごまんといるが、そいつらがその上司のポジションに就いたとき何ができるかというと、
無能呼ばわりしてた上司と似たり寄ったりw

411
仕様書無しさん[sage]   投稿日:2017/06/02 12:27:03
民主党の悪口はそこまでだ

412
仕様書無しさん[]   投稿日:2017/06/02 12:34:20
そういう教育を受けてきたのだから仕方ない
お前らが悪いんじゃないよ
お前らのアタマは悪いけど

413
仕様書無しさん[sage]   投稿日:2017/06/02 20:11:25
>上司の悪口言ってるサラリーマンなんてごまんといるが、そいつらがその上司のポジションに就いたとき何ができるかというと、
>無能呼ばわりしてた上司と似たり寄ったりw

ピータの法則ってのがあってだな...
https://ja.wikipedia.org/wiki/ピーターの法則

要するに、例えばエンジニアとして優秀であっても管理職として優秀とは限らないだろ?
しかし、優秀なエンジニアであったが為、組織の中で"出世"してしまい無能な管理職になってしまう(可能性が高い)。
そこら辺を分かっている企業であればキャリアパスとして、職位(給料)とroleを分けていて、
PMより給料が高いエンジニアとかも割と居たりする。

因みにそういったキャリアパスがある企業は日本だと、
エンジニアの質が競争力に直結する自社サービスで食べている様な企業が多いかなー。あと外資系全般。
コメント1件

414
仕様書無しさん[sage]   投稿日:2017/06/02 20:43:04
>・顧客自身が要求仕様を書けない(業務のマニュアル化ができなさすぎるし、できる人材を雇ったり教育することはない)
>・要件変更の柔軟性要求・瑕疵担保の要求がキツい
USでも基本顧客は要求仕様を書けない。ただ昨今は内製化が進んで有る意味変わってきたが。
仕様変更が多いのも同じかな、だた瑕疵担保は違う。

瑕疵担保に対するリスク負担の割合が所謂SE/PGを分けているという事であれば、
SEと呼ばれるroleは元請け企業を頂点に受託報酬が少なくなっていく順で
少なくなって行くはずだが、そんな感じの構造だっけ?
コメント1件

415
仕様書無しさん[sage]   投稿日:2017/06/02 20:50:37
>413
うわ、知ってることぐだぐだ説明されちゃったよ

416
仕様書無しさん[sage]   投稿日:2017/06/02 21:03:31
>406
Agileと言っても最近は色んなフレームワークが有って、製造業向けの物はソフトウェア開発向けの物とは違う。
ただ、Teslaとかは製造ラインも柔軟に組み替えられる仕組みがあって、ソフトウェアの開発プロセスに近い。

因みにAgileの重要要素の1つとして、メンバー全員のタスクやvelocityの可視化、
プロジェクトの問題点の改善プロセスがあったりするのだが、
その過程で無能やサボりが明らかになるという副次効果がある。
自分は評価の厳しいUS企業で体験したのだが、無能には割とドラスティックな対応が入ってて色々凄かった。
日本であれを適用するとSE/PG問わず阿鼻叫喚になりそうw(雇用規制が邪魔してできないだろうけど)

417
仕様書無しさん[sage]   投稿日:2017/06/02 21:10:14
ベロは関係ないだろ!
ふざけんな!

418
仕様書無しさん[sage]   投稿日:2017/06/02 21:23:46
>ベロは関係ないだろ!
velocityは個人の能力に関係がないと言いたいのであれば、基本的にそれは正しいのだけど、
同じチームで相対的に著しく低い場合はやはり関係有る。
もちろん改善プロセスや可視化されたその他諸々との総合評価だけど。

419
仕様書無しさん[sage]   投稿日:2017/06/03 00:06:06
舌がなんだって?

420
仕様書無しさん[sage]   投稿日:2017/06/03 01:02:35
無能を排除しない
有能を評価しない

ジャップランドのなにがダメかってこういう基本的なところだよな
ウォーターフォールとかアジャイルとか実は大して関係ないんだわ
コメント1件

421
仕様書無しさん[sage]   投稿日:2017/06/03 01:47:48
>420
自虐かよw

422
仕様書無しさん[sage]   投稿日:2017/06/03 09:20:06
解雇規制なんか撤廃されて
みんなクビになっちゃえ!

423
仕様書無しさん[sage]   投稿日:2017/06/04 05:11:47
>414
自治体案件だとそんな感じ、大手SIerが高値で契約を結び、
それっぽいキックオフをやり、
その後下請けか孫請けが安値で臨時に招喚される
更新情報
・スレッド一覧ページで過去ログのタイトル検索・一覧表示ができるようになりました(2016/1/20)
NGワード登録
登録する
スレッド内検索

プログラマー板 タイトル検索

このスレッドが人気です(実況系)
情報ライブ ミヤネ屋★3 (388)NTV実況
バイキングとグッディ★5 (793)フジ実況
実況 ◆ TBSテレビ 28143 江藤愛を衆参両院で閉経中審査 (918)TBS実況
連続テレビ小説 ひよっこ★200 (702)NHK実況
NHK総合を常に実況し続けるスレ 136162 吉原 (521)NHK実況
羽鳥慎一モーニングショー★4 (992)テレ朝実況
実況 ◆ 日本テレビ 55903こん (554)NTV実況
国会中継「衆議院予算委員会質疑」★22 (140)NHK実況
このスレッドが人気です(ニュース系)
【LIVE】9:00〜15:00衆議院予算委員会加計問題等集中審議★3 (1003)ニュー速+
【ラジオ】<森田まさのり氏 >ヒット前に有名漫画家から言われた屈辱的なひと言!「コイツらには負けるか」「絶対に売れてやる」 ★2 (929)音楽・芸能ニュース
【話題】文学部って何の役に立つの? 阪大・文学部長「本領を発揮するのは、人生の岐路に立ったとき」★2 (869)ニュー速+
【FNN世論調査】加計問題「どちらが説得力があるか」 前川氏52・2% 加戸氏23・5%★2 (896)ニュー速+
【ラジオ】<森田まさのり氏 >ヒット前に有名漫画家から言われた屈辱的なひと言!「コイツらには負けるか」「絶対に売れてやる」 (1001)音楽・芸能ニュース
【FNN世論調査】加計問題「どちらが説得力があるか」 前川氏52・2% 加戸氏23・5% (1001)ニュー速+
【LIVE】9:00〜15:00衆議院予算委員会加計問題等集中審議★2 (1006)ニュー速+
【話題】文学部って何の役に立つの? 阪大・文学部長「本領を発揮するのは、人生の岐路に立ったとき」 (1001)ニュー速+
プログラマー板の人気スレ
プログラマの雑談部屋 ★10 (73)
プログラマの雑談部屋 ★9 (1001)
【ウンコ歓迎】50代のプログラマーいる?Part21 (423)
Re: 35歳、発達障害の無職ですが...3 (328)
競技プログラミングにハマるプログラマのスレ 11 (538)
プログラマーの仕事って楽過ぎ、クソワロタwww3 (739)
プログラマーはアニメをみよう! 20クール (920)
土曜・日曜も岡部健のオナニーを嘲笑おう!★24 (1001)
COBOLって今需要増えてるの?Part6 (467)
14歳、発達障害の登校拒否ですが...1 (238)
硫化水素自殺で生き延びた俺に質問ある? (94)
アジャイルを考えたやつの死を願うスレ Part.2 (177)
学生ほどVBAとかシェルスクリプトとか覚えたほうがいい (914)
◆個人事業主専門スレ48本目◆ (1001)
【鬱病】壊れたプログラマー 46人目 【憤死】 (157)
勤務中眠くて眠くてたまらない (130)
【有能】東京コンピュータサービス Ver3【無能】 (903)
下流風情でほざいているお前らコレ企画設計してみろ (754)
プログラムセンスがある人とない人の違い 4 (887)
おもしろいコピペがあったら貼るスレinマ板part44 (584)
この世界が神のシミュレーションプログラムなら (99)
36歳ゴミPGが会社に頼らず生きていきたい (204)
スレ立てるまでもない質問はここで (794)
プログラマーのコテハンが集まる雑談所(プロコテ雑) (74)
上流工程やりたくない (223)
このサイトについて
このサイトは2ちゃんねるからデータを取得し、表示するサービスです。
画像のインライン表示機能について
画像のURLの後ろにある[画像をインライン表示]をクリックすると、URLの下に表示します。
表示される画像は横幅100pxに縮小されていて、クリックすると原寸で表示します。
このサイトの特徴
1)スレッド内検索ができます
2)レス(「>>1」など)のポップアップができます
3)不適切な言葉を含む投稿を表示しません
4)ページ内で画像を直接表示できます
5)2ch他スレッドへのリンクはタイトル・板名つきでリンクします
6)すっきりとしたデザインで表示します
7)最新スレや前スレをチェック・一覧表示します
8)NGワード機能の搭載でイヤな言葉が目に入りません
9)荒らしを自動チェックします
10)スレッド内・同一IDの書き込みだけ表示できます
11)レスの返事をレスされた発言の下に表示する「まとめビュー」が利用できます
12)シリーズ化したスレッドの一覧を表示します
13)最新のスレッドがある場合はお知らせします
削除について
こちらをご覧ください
機能要望について
現在機能要望受付中です。
問い合わせについて
こちらのページからどうぞ
広告


首都圏の方、ソフトバンク光オススメですよ


このサイトは2ch.scからデータを取得・表示しています。削除などについてはこちらをご覧ください。 アクセスモード:差分取得 - 新着書き込みなし(304)