仕様書、設計書についてat PROG
仕様書、設計書について - 暇つぶし2ch4:仕様書無しさん
11/11/26 11:48:15.20
・実際の運用
外部設計/基本設計、内部設計/詳細設計
 箇条書きの要件定義、またはループや分岐を書いたフローチャート
 外部/基本設計が詳しい場合、内部/詳細は内容のコピペか焼き直し
 内部/詳細の修正でも必ず外部/基本設計が修正される

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

正直マ暦はあんまり長くはないのだけれど、これって普通のことなのかな…?

5:仕様書無しさん
11/11/26 11:50:47.01
ちなみに作るのに使うのは基本的にExcelです。
もちろん方眼紙です。
図はオブジェクトたち。
たまーにWordもありますが、終盤はファイルがいくつか見事にぶち壊されてます。

レビュアーが意図してる「仕様書」が何かを察することが、うまくやるコツなのかなって
最近思うようになってきました。書きたくない、じゃ通らないですし…。

6:仕様書無しさん
11/11/26 12:34:32.02
ソースコードは設計書だと考えるべし。

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

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

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

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

別の形式として見たければ、ソースコードから変換すべし。

7:仕様書無しさん
11/11/27 16:30:57.65
ケースバイケース
以上終了

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

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

10:仕様書無しさん
11/11/29 21:12:13.15
設計書作ること自体が目的になるとページ数だけ多くなって誰も読まなくなるな
そして設計書があるのにまったく見ずにソース見ながら電話対応するようになる


11:仕様書無しさん
11/12/01 02:11:54.00
ソース見て判断できない人が見てるフリするための資料になってることが多いな

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

13:仕様書無しさん
11/12/01 02:33:40.32
設計書なんて大枠だけきっちりしてればいいんだよ
あとインターフェイス部分とエラー処理と

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

15:仕様書無しさん
11/12/01 21:10:59.29
>>12 想像力があっても実物の挙動は予想不可能なんだぜヒァッハー

16:仕様書無しさん
11/12/02 02:08:25.70
文章での説明にしても図説(もちろんフローチャート())にしても
例外をうまいこと表現できないから、なんか書いてて、ウアーってなる
他のとこだけコードよりの内容が要求されるのにww

でも他の人みると、そもそも例外なんてアウトオブ思考だったわ

17:仕様書無しさん
11/12/02 02:43:20.88
>>14
確かに、設計まわりの明確な名称はあるとかなり嬉しいな
とにかく何もかもが曖昧すぎるんだよな

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

19:仕様書無しさん
11/12/02 20:50:32.61
設計段階で何するかは煮詰めたほうがいいよ。

実装者がアイディアマンになってしまうのは良くない。
俺が実装して痛い目見た経験から。

20:仕様書無しさん
11/12/02 21:18:28.12
>>19
詰めるべきは客先交えて決める外部仕様だろ
設計で内部ロジックなんか詰めてもしょうがねーよ

21:仕様書無しさん
11/12/03 17:02:41.63
DB設計と画面のモック作るだけ。


22:仕様書無しさん
11/12/04 09:16:18.07
マなんて信用してないから書かせる

23:仕様書無しさん
11/12/05 23:13:04.70
マはマで設計が信用ならないって言ってたりするからな
どっちであっても、出来る奴と出来ない奴の差が激しすぎるんだよな
なまじ形だけなら誰でも出来るもんだから、ひどい物でもなんとかなってしまうっていう

24:仕様書無しさん
11/12/05 23:25:10.52
つか、システム全体の設計はともかく詳細設計書はコード書く本人に書かせてレビューするだろ。
新人とかなら詳細設計書まで書いてやって渡すこともあるけど。

25:仕様書無しさん
11/12/05 23:39:09.72
>>24
新人じゃないならそれこそ実装したコードレビューした方が早いだろ

26:仕様書無しさん
11/12/06 02:16:54.87
こういうのみると、つくづく設計関連の用語の意味が統一されてないのが
諸悪の根源だって気がしてくるわ

27:仕様書無しさん
11/12/06 10:45:11.60
>>26
諸悪の根源は別のところにあります
本質を見抜く目を養わないと一緒ドカタですよ?

28:仕様書無しさん
11/12/06 22:37:20.22
建築業界って、大工が「俺の作ったもんが設計書だ!」って思う人いるんだろうか

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

30:仕様書無しさん
11/12/07 00:40:48.22
基本的にそこらの書店にあるような仕様書サンプルってプログラム素人向け、顧客が理解できる程度のものだからね。

31:仕様書無しさん
11/12/07 02:34:21.03
この業界自体土方だけどな
土方根性土方思想がはびこりすぎて個人でどうにかできる状況じゃねーよ(´・ω・`)はあまじああ

32:仕様書無しさん
11/12/07 13:03:05.04
>>28
モジュールを指して設計書という奴は居ないだろう
ソースに該当するのはなんだろうな

33:仕様書無しさん
11/12/07 15:22:16.38
>>28
大工が建築物にコメント書くのが許されるんなら設計書にならなくもない
物置程度ならそれで充分なんじゃないかな、よくわからんけど

34:仕様書無しさん
11/12/08 18:17:02.74
>>33
建材に印ついてたりはするよな

35:仕様書無しさん
11/12/09 09:12:42.17
うちのポストにもたまに印がついてる

36:仕様書無しさん
11/12/09 19:33:18.78
書いてるとこ見つけたら器物損壊で訴えれるんだっけ、あれw

きっちりかっちりしすぎても、緩すぎても仕様書って成り立たないよな
降車は言うまでもなく、前者も全員が守れない無駄な仕組みになってることが多くて、破綻しやすい
いい仕様書の共通仕様でもできればいいのにな!!

37:仕様書無しさん
11/12/09 20:25:54.02
>>33
墨つぼが大工のコメント

38:仕様書無しさん
11/12/10 17:34:18.45
「昔、城を建てた無名の木工は、自分がその仕事に携わった証として、
屋根裏に自分の名を刻んだ工具を態と忘れたそうだ。そんな些細な思いすら、お前達は消し去るのか?」

39:仕様書無しさん
11/12/10 22:37:29.19
たまに外科手術で縫合終わった後にメスが一本足りないことに気が付いたりとか?

40:仕様書無しさん
11/12/12 02:53:25.99
sierなんかで働くから悪い

41:仕様書無しさん
11/12/16 21:00:08.96
ドキュメントの枠だけ用意されて中身の書き方が決まっていない現場って
文章の語順や言い回しとか表現の仕方ばかり気にする人多いけど
正直馬鹿にしか見えないんだよな
共有鯖から過去の資料や既にOK出てる仕様書を真似て作成しても
人によって作り方が違うからNGになるし
そもそも同じブツ出して見る人によってOK・NG別れる時点でおかしいが
本人たちは指摘して偉い気分にでもなってるのかね

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

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

どれ程のもん作ってるのかとこっそり覗いたが1時間くらいあれば
作れるような普通の仕様書だった
要するにこいつの趣味の書き方というだけだった
指摘馬鹿は人に「こっちの方がいい」とか指摘する前に
本当にそれをする必要があるのかどうかを考えた方がいいわ
必要ないことに時間掛けてる奴多すぎ






42:仕様書無しさん
11/12/17 01:23:21.94
まったくだわ
うちの職場だと、能無しPLとか老害連中や口うるさいバカ女が
しょっちゅうどうでもいいことにばっか力注いでて、もうウンザリ
その決定を行わない無駄なボールの投げあいしてる時間で
解決してしまえる内容をぐだぐだやって、時間が浪費されてく

無駄に細かい仕様を早いうちから書こうとして要点はつめないまま、
後になって仕様変更のなみで外設あたりからいろいろ詰んでるし、頭痛いわ…

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

44:仕様書無しさん
11/12/20 15:47:53.04
>>43
それはお前のせいじゃ、ドアホ

45:仕様書無しさん
11/12/20 18:27:26.88
アホでもわかりやすいところは詳細に書いて、説明が面倒臭いところは適当にごまかす
初期処理と終了処理はソースコードレベルの細かいこと書いてるのに
肝心の主処理は「ファイル変換を行う」の一言だけ

コーダーのための詳細設計書なんて見たことないんで書き方もわかりません

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

47:仕様書無しさん
11/12/21 18:35:33.03
だから設計と製造は切り離したほうがある意味確実なんだよね…

保守さえ考えなければ

48:仕様書無しさん
11/12/22 00:37:25.26
わかってない奴がわかった気分になるための説明書であることが多いよな
実装を前提とした検討用の設計書になってるものを見たことがない

49:仕様書無しさん
11/12/22 00:40:23.62
わかってない奴に見せてわかった気分にさせるための説明書、か
そして出来ない奴ほど体裁に死ぬほどこだわる
まったくこだわらない奴も出来ない奴だけど

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

50:仕様書無しさん
11/12/22 03:04:13.29
個人的には、体裁が整ってることは大切であり、
納品物あるいは後々の保守を考えれば最低条件であると考える

問題は文書作成環境にある
Excel/Wordとも短いレポートを手軽に作成するのには最適なツール
ただし、これを数百ページにおよぶ技術系文書(仕様書/設計書/マニュアル等)に
利用する発想が、適材適所という言葉を知らぬ人が犯す基本的な間違い

51:仕様書無しさん
11/12/22 06:20:58.90
>>48
> 実装を前提とした検討用の設計書
うちはこういうのばかりだ。
おかげで、他人が見たら「どうコーディングするべきなのか」はわかっても
「どういう意図でそうなってるのか」がまったくわからない状態になってる。

> わかってない奴がわかった気分になるための説明書
メンテナンスする立場で言うと、わかってる奴にしかわからない設計書なんか
残されても、まったく嬉しくないんだ。

52:仕様書無しさん
11/12/22 08:42:43.20
>>51
どういう意図で、は要件定義から追えば分かるんじゃないの?
分からないと保守更改で死ねる

53:仕様書無しさん
11/12/22 11:53:45.51
>>50
むかし社内で議論したけど、誰でも開けて編集できて、となると他に候補が無いんだよね。
でも開く環境が変わるとテキストがズレて崩れるけど(爆笑

Word使うなら箇条書きの範疇で済ます。
凝りたいならPowerPoint+PDFかInDesignでごゆっくりどうぞ。
ということにしてる。

54:仕様書無しさん
11/12/23 13:38:32.56
「Excel方眼紙滅べ!それで仕様書つくるやつもぜんぶ滅んでしまえ!」
「Wordは糞だが選択肢が他にないんだよな」ってのが前提にある奴です
Wordを推したいわけではないけど、Excel方眼紙で設計書作るくらいならWordのほうがいい

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

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

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

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

ただ、それぞれの機能が使い難いし、理解しづらい
なにより、そういう基本機能ですら理解出来ない、しようとしない奴が多すぎて、まともに使われることが少なく、
仮にちゃんと作られてるドキュメントでも、そういう理解能力がない馬鹿が一人チームに混じってるだけで
簡単に設定されてる体裁の破壊が出来てしまうから、使えないツールになりがちなのよね

55:仕様書無しさん
11/12/23 13:40:57.60
>>51
>おかげで、他人が見たら「どうコーディングするべきなのか」はわかっても
>「どういう意図でそうなってるのか」がまったくわからない状態になってる。
うちではわかってないヤツ向けの仕様書書いてるけど、そのわかってないヤツが
意図とか書くと余計なこと書くなって言ってくる
なもんで「どういう意図でそうなってるのか」は偉い人から口頭で聞いてソースのコメントに書いておく

> メンテナンスする立場で言うと、わかってる奴にしかわからない設計書なんか
> 残されても、まったく嬉しくないんだ。
わかってないヤツの想定が違う
OSって何ですかレベルのヤツを指してる
>>51の組織ならそのプロジェクトに参画してなくてもコーダーなら理解でできる仕様書を書きやすい気がするが
そういう組織に属したことないからよくわからんけど

56:仕様書無しさん
11/12/23 13:54:01.69
>>53
あ、あと、PowerPointとかinDesignで設計書はないわw
何のための設計書かがわからなくなる
それやるくらいならまだExcel方眼紙にオブジェクト張って済ませばいいと思う

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

図説みたいな自由度への制限とか、環境の構築が必要だとか、他に提出するときどうするの、とか
ドキュメントとレイアウトがどうしても混ざってしまうような欠点もいっぱいあるんだけど、
外に出ないものなら結構便利そうではある

57:仕様書無しさん
11/12/23 14:14:41.55
>>55
> わかってないヤツの想定が違う
そうそうw
文章を読むことすら出来ないような人とか、特にそういうこといってくるw
箇条書き、図説、表あたりしか理解してもらえない。
そういうのは設計書じゃないだろって思うけど、その思いは言葉にしても届かない!
結局本当の設計書は各担当の頭の中で作成されちゃうのよね

自分も他に書ける場所がないする事はできるだけコメントに残したりしちゃう派だけど、
ソース弄る奴にも、先にあげたようなのが混ざったりする事もあるから
保守されないコメントが、現状の実装と異なる状態になるかもしれなくて、コメントに残しすぎるのも怖いんだよな
マに免許とかそういうのはないし、コーダーのレベルもピンキリ激しい
あとコメントじゃレビューとかもないから、誤記ったりしてもそのまま残る可能性が怖い…

58:仕様書無しさん
11/12/23 15:10:40.62
はぁ?

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

お前車とか家とかの設計書見たことあるのか?

59:仕様書無しさん
11/12/23 15:24:27.50
あはっ♪
設計書って言ったら、フツー「設計書がどうしたんや!何して欲しいんかちゃんと云いなはれ。そんなんで伝わると思うたらおお間違いや」
設計書是也設計書。
設計書見たことあったらどうなのか? 無かったらどうなのか? もったいぶってても大した話じゃないならとっとと話を進めなさい。

60:仕様書無しさん
11/12/23 15:44:03.59
つーか、設計書を曖昧に自然言語で書くなよ。

61:仕様書無しさん
11/12/23 16:52:30.19
たしかにマも土方だが、そういう方面の土方ではないぞ。

62:仕様書無しさん
11/12/23 16:56:26.25
理解能力がない人に見せる資料は設計書とは分けたほうがいいけど、理想どおりにはいかないしな。
結局頭の中が下の連中に合わせないといけなくなる。

63:仕様書無しさん
11/12/23 18:12:55.40
>>60
自然言語で表現できないかしづらい内容までドキュメント化しろなんては思ってないよ
シーケンス図とかクラス図で済むことならそっちでやるし
きっちりかっちり自然言語を使わず表現できる部分なら、それはもうコーディングしちゃえばいいんじゃね

>>62
まぁ結局そうなるんだよな

64:仕様書無しさん
11/12/23 18:14:46.69
> きっちりかっちり自然言語を使わず表現できる部分なら、それはもうコーディングしちゃえばいいんじゃね

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

日本語は、コメントとして書けばいい。

65:仕様書無しさん
11/12/23 18:27:27.47
プログラム設計書は要らないと思うが、それより上の工程でのドキュメントは必要。

66:仕様書無しさん
11/12/23 18:31:32.60
>>65
ISOなんとかのためなのかどうかは知らないけど、
プログラム設計書は求められる現場が多い。
それより上の工程のドキュメントは無くても。

67:仕様書無しさん
11/12/23 19:26:36.89
>>66
上の工程のドキュメントはどんなにわけわからんこと書いてても
我々に文句言う権利ないしね

68:仕様書無しさん
11/12/29 20:13:18.23
>>4
プログラム設計書は重要じゃないけど
プログラム設計は重要
この重要性が現場でも理解されてないからプログラマの地位は低い

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

70:仕様書無しさん
11/12/29 23:48:36.19
レビューは、その場で見て思いつきで指摘して終わるからな
ちゃんと修正されたか再レビューしないことも多いし
儀式的なものになり果てている

担当を複数人にしてお互いにチェックするという仕組みにしたらいいと思うんだが

71:仕様書無しさん
11/12/30 03:36:34.51
>>70
それは単純に開発プロセスの問題な気がする。
プロセス監査とか無いの?

結局開発者自身が本当に改善したいと思ってるかどうかと、
さけるリソースがあるか、によるんだよなぁ。
実際真面目に取り組むとちょーメンドくてしんどい。
けど効果はある。

72:仕様書無しさん
11/12/30 10:14:50.14
開発プロセスの問題じゃなくて、
各々の文章チェック能力、設計力の問題だろ。


73:仕様書無しさん
11/12/30 13:08:13.71
そら有能な個人の力に頼るのが早いてのは分かるけどさ。

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


低レベルでの開発プロセス定義なんて、最低以下の人間に
最低限の仕事させるためのもんだよ。
高生産性や高品質はその次の話。

74:仕様書無しさん
11/12/30 13:43:16.95
URLリンク(d.hatena.ne.jp)

75:仕様書無しさん
11/12/30 13:44:56.99
低レベルの人間に何回チェックさせても無駄。
プロセス重視することと、内容を軽視することは同義。


76:仕様書無しさん
11/12/30 14:32:32.56
>プロセス重視することと、内容を軽視することは同義。

レベル低くて笑える。
それ素振りやっただけで上手くなった気分になって満足してる奴らの話だろ。
まぁ好きにしたらいいよ。

77:仕様書無しさん
11/12/30 14:43:31.28
プロセスを突き詰めて問題が解決するなら
docomoの障害は起きなかっただろう

78:仕様書無しさん
11/12/30 14:50:18.73
無駄なプロセスばかりが増えていく。
内部統制とかいい例。

79:仕様書無しさん
11/12/30 14:55:27.70
プロセスを突き詰めても
人間がある以上トラブルは発生する。


だがプロセスがなければ
もっと多くのトラブルが発生する。

80:仕様書無しさん
11/12/30 14:57:06.08
>>73が自分で言っているように

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

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

そもそも最低の人間を使わなければいいのに。

81:仕様書無しさん
11/12/30 15:01:14.00
自称上級者が簡単なことを
やらないからいけないんだろうな。

82:仕様書無しさん
11/12/30 16:38:54.26
低レベルの人間大量に投入してプロジェクト上手く回すのがプロマネの仕事です。
レベル高い人間を集めるられることを前提に計画建ててる時点で破綻してる。


83:仕様書無しさん
11/12/30 16:54:01.72
>低レベルの人間大量に投入してプロジェクト上手く回す
ってのは可能なのか?

84:仕様書無しさん
11/12/30 17:23:42.55
>>82
ソフトの世界は量ではなく質なので
その方法では一流になれません。

85:仕様書無しさん
11/12/30 17:26:31.44
質の良いソフトがビジネス的に成功した例は皆無だよ。
WindowsとかOracleとかのバグの多さを見れば明らかだろう。


86:仕様書無しさん
11/12/30 17:29:43.68
ビジネス的に成功 と バグの多さ にどういう関係が?

87:仕様書無しさん
11/12/30 17:30:54.35
>>85
低レベルの人間を大量に集めて
WindowsとかOracleを作れると思ってるなら
おめでたいな

88:仕様書無しさん
11/12/30 17:33:25.76
質より量を重視した結果バグだらけになっても、多機能を売りにビジネス的には成功するって話。

89:仕様書無しさん
11/12/30 17:35:04.30
>>87
本気で高レベルの人間が、少数精鋭で作ってると思ってるなら頭おめでたいですね。

90:仕様書無しさん
11/12/30 17:39:40.42
人が大量にいないと作れんが
その人達は全員がある程度高レベルの人間でないと作れない
特に優秀な人が必要なのはプログラマレベルだろう

例えば日本のゼネコンシステム会社にMFCとか.NETライブラリとか作れるか?
上流工程(藁)SEには作れないし、寄せ集めプログラマ作れるものではない

91:仕様書無しさん
11/12/30 17:40:06.15
Microsoftはバグですらビジネスに利用して一流になったわけだし。
新しいバージョンではバクやセキュリティホールが治って価値が上がってる、だから新バージョンを買ってくれってね。

92:仕様書無しさん
11/12/30 17:45:26.88
残念ながらOS作ってる奴らの大半は、寄せ集めの短期契約プログラマーだよ。


93:仕様書無しさん
11/12/30 17:47:53.64
え、マジで?
デビッドカトラーとかは伝説なの?

94:仕様書無しさん
11/12/30 17:54:50.00
>>92
正社員か下請けか派遣かとかの所属のことを言ってるんじゃないよ

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

96:仕様書無しさん
11/12/30 18:16:30.51
「仕様がクソ」と多くの人が言うが、「どこがクソ」かを言う人は少ない

97:仕様書無しさん
11/12/30 18:21:10.54
>>96
そいつが、そういう仕様になってる理由を理解できる頭がなく
分かってないだけのことも多い
単に自分の分担分の作業が増えて面倒だというだけの理由の場合もあるな

98:仕様書無しさん
11/12/30 18:24:17.49
バグ報告のサイトで散々言ってるから。

99:仕様書無しさん
11/12/30 21:04:55.59
>>87 >>90
多人数大規模の開発ってのをなんか勘違いしてるでしょw

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

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

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

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

じゃあどうするか。ここまで考えてものを言ってる?

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

101:仕様書無しさん
11/12/30 21:09:50.44
> 可能な限り優秀な人間が大量に。
それは現実的ではない。

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

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

Windowsみたいにいくらでもコストが掛けられるような場合はいいが
実際はこういうふうにして行かないとやっていけないでしょ。

102:仕様書無しさん
11/12/30 21:17:54.26
システムに簡単な部分と難しい部分があることに
気づかない人って理解出来ない。
一人でシステムすべてを作っているからその違いを考える必要がないのかな?

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

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

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

これが最適化されたシステム開発の姿だと思うんだが。

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

104:仕様書無しさん
11/12/30 21:44:22.22
80歳まで20本の歯をキープって歯無し

105:仕様書無しさん
11/12/31 02:30:31.77
そもそも大規模な仕事をやる必要があるのか?
金掛けて糞積むようなもんでしょ。

106:仕様書無しさん
11/12/31 02:44:58.74
金さえあればどんな仕事もやる必要はないよw

107:仕様書無しさん
11/12/31 02:57:52.93
>>105
この業界に生きるものとしてそれを言ってはいけないwww
俺らが生活できるのは誰のおかげかwww

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

実際に稼働することで開発費以上の利益を生むわけだし、お客が納得してれば別にいいんだけど

108:仕様書無しさん
11/12/31 03:07:08.76
>>107
充実感?
お前の個人的な基準を人に押し付けないでね。



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

110:仕様書無しさん
11/12/31 09:43:06.33
ソフトは

大規模 = 価値がある

わけじゃないんだよね。

111:仕様書無しさん
11/12/31 09:47:30.43
Gmailはシンプルな仕様で工数的にはそんなに掛かってないはず
でも世界中の人が利用してる。

これからの時代、SIerも淘汰が始まると言われている。
金持ちに粗悪品売るような商売も長く続かないだろう。

112:仕様書無しさん
11/12/31 09:55:41.34
請負やってりゃ客の金をたくさん取るのが正しいんだろうけど
それがソフトのあり方だと思わないで欲しいね。

自社サービスやってればそんな発想は出てこないだろうに。

113:仕様書無しさん
11/12/31 10:30:52.64
>>110
そんなの当たり前だろw

なんでそんなことを言うのかしらんが、
もしかして、大規模なら価値がないとでも
言いたいのか?

114:仕様書無しさん
11/12/31 10:39:48.70
>>111-112
何をそんなに否定したいのかさっぱりわからんのだが。
話をまとめるぞ。

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

これのどれを否定したいんだ? 現実的なやり方だろ。
否定しなきゃならない理由でもあるのか?

115:仕様書無しさん
11/12/31 10:44:25.43
>>113
大規模 = コンパクトにする努力をしてない
と思う。

116:仕様書無しさん
11/12/31 10:50:43.25
>>114
規模が大きければそうせざるを得ない。
ただ、その規模必要なの?

117:仕様書無しさん
11/12/31 10:53:25.11
docomoの障害だってそうだよな
何重ものいらんチェック付けて工数増大させてる割には
肝心なところが抜けてる

118:仕様書無しさん
11/12/31 12:00:58.87
>>115がすべて
規模の大小なんて大した問題ではない。
努力が足りないだけ。

119:仕様書無しさん
11/12/31 12:09:58.89
>>116
規模の大小に関係なく、
開発期間とコストを下げるには必要なこと。

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

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

それが現実。

120:仕様書無しさん
11/12/31 12:14:56.82
>>117
そうだよね。

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

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


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

そして優秀な人の仕事を減らしつつ、簡単だが量が多い所に
適当に集めた人材を大量投入する。

121:仕様書無しさん
11/12/31 12:34:56.56
神は細部に宿る
これはソフトにも当てはまると思う。

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

アーキテクトの目が届かない範囲にまで規模が膨れたら
それはもう分を超えているのではないか。

122:仕様書無しさん
11/12/31 13:12:47.30
プログラマとして、自分の受け持つ設計やコード等に神を宿す努力をするべきだが、ビジネスの場にそれを持ち込むのは、切り分けができていない二流。

全体のレベルが高くある必要があると思うなら、均一なレベルにできるシステムを考えろよ。(そもそも、俺が考えた最強のが多い気がするが)
お前らは、自分ができる奴だと思いたい、出来ない奴を叩きたいだけで、実際はご近所さんで毎日集まって愚痴ばかり並べてる様なそこらの主婦となんら変わらないクズなんだよ。

123:仕様書無しさん
11/12/31 13:31:33.09
>>115
100万行のコードをいくらコンパクトにしても一万行に収まるわけじゃないからなぁ。

124:仕様書無しさん
11/12/31 13:35:08.15
>>111
> Gmailはシンプルな仕様で工数的にはそんなに掛かってないはず
> でも世界中の人が利用してる。

お前みたいに、UIだけで中身を判断する馬鹿がいるから苦労すんだよ


125:仕様書無しさん
11/12/31 14:29:12.55
>>114
横レスになるが、自分も同感だね

>>123が現実だから

126:仕様書無しさん
11/12/31 15:43:10.30
>>124
中国意外な。

127:仕様書無しさん
11/12/31 16:06:58.09
>>114
理念としては正しい方向性であると思う
というか、昔から同じような事は言われてきた
では、そんな当たり前の事を実践できていないプロジェクトが現実に多いのはナゼか?
という話になる
自分の想像を二点挙げる

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

次に、それら稀少かつ優秀な人材を「開発に着手する前に」最適に配置するのが難しい
まだシステムが形になっていない段階で最適な配置を決定するのは、
高度な未来予測(いわゆる「見積もり」)能力が要求される
また優秀な人物でもすべての分野で完璧という訳ではなくて得手不得手な分野がある
そして優秀な人物は自己過信になりがちだから、ここでも自己申告はアテニナラナイ

128:仕様書無しさん
11/12/31 17:28:04.53
よくある失敗パターンが、システムのコア部分は精鋭を集めて作れたんだけど、
人数集めて作り始めた周辺部分がぐだぐだになってしまうというやつだな。

ユーザの要望や度重なる仕様変更に晒されて肥大していくのは周辺部分なんだから、
ここに大規模ソフト開発や膨大な仕様の把握などに対応し切れない人を当てると
ぐだぐだになる。

129:仕様書無しさん
11/12/31 18:47:22.24
目に見えない制御部分が優れていることより、目に見えるUIが優れていることが優先されるからな。


130:仕様書無しさん
12/01/03 04:25:04.28
>>96
いろいろとあるが、
OS領域と、ユーザーアプリケーション領域、ユーザーデータ領域が、明確に別れていない部分が糞。
OSが不安定になって再インストールとか、それによってユーザーデータが消えるとか、アプリケーション一つずつ入れ直すとか本来あり得ない思想が前提になってる。


131:仕様書無しさん
12/01/03 08:09:39.88
>>130
それは *** Windowsが糞 *** という話だね
すべてはレジストリが癌になっている

132:仕様書無しさん
12/01/03 08:57:05.39
>>131
お前、レジストリがシステムデータと
ユーザーデータでファイル自体分離されてるの知ってる?

133:仕様書無しさん
12/01/03 08:58:20.12
>>130
それはお前がフォーマットして
インストールするから消えるんだろw

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

135:131
12/01/03 16:15:34.55
>>134の名前欄を訂正

X: 130
O: 131

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



137:仕様書無しさん
12/01/03 19:43:09.84
ユーザー用のレジストリファイルならコピーして
他環境に持って行って普通に使える。

138:仕様書無しさん
12/01/04 02:09:53.63
可能ではないけど手間が段違いだからな
しかもあまり一般的じゃないから情報も少ないし保障もない
そういう事が考慮されていない糞設計ってことには違いないよな

139:仕様書無しさん
12/01/04 03:07:19.18
>>41-44
ワロタエナイ
文書表現ばかりこだわる奴が炎上プロジェクトに投入されると、ますます燃え盛るw

140:仕様書無しさん
12/01/04 08:10:08.82
>>138
じゃあ、一般的に
レジストリをエクスポートして
インポートすればいいだけじゃね?
何難しく考えてるのよw

141:仕様書無しさん
12/01/04 13:00:51.83
要件定義がぜんぜんできてない段階で、設計書に着手してるアホばっかだから、
設計書を書いてそれを客に提示して、お伺いを立てるなんて発想が出るんだよ・・・。
だから設計書も設計ではなく要件を書くようになっていって、
肝心の部分がぜんぜん詰められてない状態になって、ただのゴミドキュメントと化す。
全部爆発しろよもう!

っていう愚痴

142:仕様書無しさん
12/01/04 13:50:23.51
>>141
「お客は いったいどんなプログラムを作って欲しいのか、
 そのプログラムの仕様を自分でも理解していない」

「プログラマは客の要求する仕様に合わせてプログラムを作るのではなくて、
 自分の作ったプログラムの仕様を客の仕様だとごまかしている」

143:仕様書無しさん
12/01/04 18:31:27.55
URLリンク(local.joelonsoftware.com)ビッグピクチャー

144:68
12/01/05 00:05:27.92
>>141>>142
何でみんな作る前に仕様を決めたがるんだろうね
作りながら仕様決めながら要件定義するスパイラルでいいじゃん

やたら細部の体裁にこだわってる仕様書を改訂する作業は面倒だと思うが
プログラマまで仕様変更を嫌がるんだもんな

145:仕様書無しさん
12/01/05 00:27:20.87
>>141
客が設計書を出さないと要件は言わないってさ
しかも要件に合わせて設計書の修正は禁止

>>144
プログラマの立場で仕様変更を嫌がる理由は大抵は仕様改悪にしか見えないから


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

147:仕様書無しさん
12/01/05 23:12:42.51
要求定義書→総合テスト
基本設計書→結合テスト
詳細設計書→単体テスト

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

148:仕様書無しさん
12/01/06 08:30:59.17
>>145

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

149:仕様書無しさん
12/01/06 09:00:07.04
>>148
頭の悪い客に付き合わされてるんだろ

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

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

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

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

See >>142

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

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

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

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

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

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

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


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

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

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



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

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

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

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

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

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

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

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

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

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

>怠るとデスマ確定。

なんだろねw

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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



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

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

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

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

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

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

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

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


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

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


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

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

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

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

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


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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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



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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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





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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

やるんだ。

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

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

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

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

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

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


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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

よかったね
 知らなくて

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

明らかに悪者だろ。


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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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


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


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