- 1 名前：仕様書無しさん mailto:sage [2011/11/26(土) 11:26:56.24 ]
- 外部だの内部だの基本だの詳細だの…
曖昧な基準で書かれた、いろいろな名前で呼ばれてて
「これってどうなの？」「意味あるの？」といった物に出くわす事も少なくない
しかし、純粋にプログラミングだけをして食べていくことは、昨今じゃ難しく
避けて通れない、否が応でも作る機会に出くわしてしまう、そんなドキュメントたち
設計書や仕様書についても、マ視点で語ろうぜ
・自分のなかでの仕様書/設計書の呼び方と分け方
・成功談、失敗談
・仕様書/設計書は何を使って作成する？(Word/Excel/HTML/手書き！)
・仕様書/設計書に含める図の作成方法や使っているツール紹介
・炎上プロジェクトでみた(よくない意味で)素晴らしい仕様書/設計書
・そもそも仕様書/設計書って本当に必要なの？
・こんな仕様書/設計書は、ぶっちゃけアリ？ナシ？
などなど、設計書にまつわる話題を募集
- 22 名前：仕様書無しさん mailto:sage [2011/12/04(日) 09:16:18.07 ]
- マなんて信用してないから書かせる
- 23 名前：仕様書無しさん [2011/12/05(月) 23:13:04.70 ]
- マはマで設計が信用ならないって言ってたりするからな
どっちであっても、出来る奴と出来ない奴の差が激しすぎるんだよな
なまじ形だけなら誰でも出来るもんだから、ひどい物でもなんとかなってしまうっていう
- 24 名前：仕様書無しさん mailto:sage [2011/12/05(月) 23:25:10.52 ]
- つか、システム全体の設計はともかく詳細設計書はコード書く本人に書かせてレビューするだろ。
新人とかなら詳細設計書まで書いてやって渡すこともあるけど。
- 25 名前：仕様書無しさん mailto:sage [2011/12/05(月) 23:39:09.72 ]
- >>24
新人じゃないならそれこそ実装したコードレビューした方が早いだろ
- 26 名前：仕様書無しさん mailto:sage [2011/12/06(火) 02:16:54.87 ]
- こういうのみると、つくづく設計関連の用語の意味が統一されてないのが
諸悪の根源だって気がしてくるわ
- 27 名前：仕様書無しさん mailto:sage [2011/12/06(火) 10:45:11.60 ]
- >>26
諸悪の根源は別のところにあります
本質を見抜く目を養わないと一緒ドカタですよ？
- 28 名前：仕様書無しさん [2011/12/06(火) 22:37:20.22 ]
- 建築業界って、大工が「俺の作ったもんが設計書だ！」って思う人いるんだろうか
- 29 名前：仕様書無しさん mailto:sage [2011/12/06(火) 23:41:22.45 ]
- この前ブックオフで「仕様書の書き方」みたいな本があったんだけど、結局サンプルはオマケ程度で中身スカスカだった。
ちなみに俺が超参考になったのは、某大手の社員用サイトにある雛形だった。
しかしそれを下請に見せない理由がよく分からん。
その形式で納品すればそこそこな品質になるはずだが、社外秘なんだよ
- 30 名前：仕様書無しさん mailto:sage [2011/12/07(水) 00:40:48.22 ]
- 基本的にそこらの書店にあるような仕様書サンプルってプログラム素人向け、顧客が理解できる程度のものだからね。
- 31 名前：仕様書無しさん mailto:sage [2011/12/07(水) 02:34:21.03 ]
- この業界自体土方だけどな
土方根性土方思想がはびこりすぎて個人でどうにかできる状況じゃねーよ(´･ω･｀)はあまじああ
- 32 名前：仕様書無しさん mailto:sage [2011/12/07(水) 13:03:05.04 ]
- >>28
モジュールを指して設計書という奴は居ないだろう
ソースに該当するのはなんだろうな
- 33 名前：仕様書無しさん mailto:sage [2011/12/07(水) 15:22:16.38 ]
- >>28
大工が建築物にコメント書くのが許されるんなら設計書にならなくもない
物置程度ならそれで充分なんじゃないかな、よくわからんけど
- 34 名前：仕様書無しさん mailto:sage [2011/12/08(木) 18:17:02.74 ]
- >>33
建材に印ついてたりはするよな
- 35 名前：仕様書無しさん mailto:sage [2011/12/09(金) 09:12:42.17 ]
- うちのポストにもたまに印がついてる
- 36 名前：仕様書無しさん mailto:sage [2011/12/09(金) 19:33:18.78 ]
- 書いてるとこ見つけたら器物損壊で訴えれるんだっけ、あれｗ
きっちりかっちりしすぎても、緩すぎても仕様書って成り立たないよな
降車は言うまでもなく、前者も全員が守れない無駄な仕組みになってることが多くて、破綻しやすい
いい仕様書の共通仕様でもできればいいのにな！！
- 37 名前：仕様書無しさん mailto:sage [2011/12/09(金) 20:25:54.02 ]
- >>33
墨つぼが大工のコメント
- 38 名前：仕様書無しさん mailto:sage [2011/12/10(土) 17:34:18.45 ]
- 「昔、城を建てた無名の木工は、自分がその仕事に携わった証として、
屋根裏に自分の名を刻んだ工具を態と忘れたそうだ。そんな些細な思いすら、お前達は消し去るのか？」
- 39 名前：仕様書無しさん mailto:sage [2011/12/10(土) 22:37:29.19 ]
- たまに外科手術で縫合終わった後にﾒｽが一本足りないことに気が付いたりとか？
- 40 名前：仕様書無しさん mailto:sage [2011/12/12(月) 02:53:25.99 ]
- sierなんかで働くから悪い
- 41 名前：仕様書無しさん mailto:sage [2011/12/16(金) 21:00:08.96 ]
- ドキュメントの枠だけ用意されて中身の書き方が決まっていない現場って
文章の語順や言い回しとか表現の仕方ばかり気にする人多いけど
正直馬鹿にしか見えないんだよな
共有鯖から過去の資料や既にＯＫ出てる仕様書を真似て作成しても
人によって作り方が違うからＮＧになるし
そもそも同じﾌﾞﾂ出して見る人によってＯＫ・ＮＧ別れる時点でおかしいが
本人たちは指摘して偉い気分にでもなってるのかね
「ここは太線で区切ろう」とか
「ここは①、②を使おう」とか
「ここは図を入れよう」とか
「ここは→・↓・←・↑を使おう」とか
「ここはカッコ使おう」とか
「待てよ！～が～の～を…うーむ」とか…
こんな指摘ばかり受けてる間に
５時間でコーディング終わるＰＧの仕様書に３日かかったし
完全に遅れが発生してこの指摘馬鹿と一緒に毎日２２時過ぎまで残業開始
結局終盤の方からはＰＧの仕様書は時間がないからと指摘馬鹿が作成
どれ程のもん作ってるのかとこっそり覗いたが１時間くらいあれば
作れるような普通の仕様書だった
要するにこいつの趣味の書き方というだけだった
指摘馬鹿は人に「こっちの方がいい」とか指摘する前に
本当にそれをする必要があるのかどうかを考えた方がいいわ
必要ないことに時間掛けてる奴多すぎ
- 42 名前：仕様書無しさん mailto:sage [2011/12/17(土) 01:23:21.94 ]
- まったくだわ
うちの職場だと、能無しPLとか老害連中や口うるさいバカ女が
しょっちゅうどうでもいいことにばっか力注いでて、もうウンザリ
その決定を行わない無駄なボールの投げあいしてる時間で
解決してしまえる内容をぐだぐだやって、時間が浪費されてく
無駄に細かい仕様を早いうちから書こうとして要点はつめないまま、
後になって仕様変更のなみで外設あたりからいろいろ詰んでるし、頭痛いわ…
- 43 名前：仕様書無しさん mailto:sage [2011/12/17(土) 10:53:56.91 ]
- >>41
それを顧客側が要求してくることもあるからな。
プログラムは正しくても、仕様書の記述ミスを理由に検収拒否してきたり、
些細な記述漏れを引き合いに、仕様が明確でないシステムは稼働させられないとか言い出して、稼働延期&稼働まで強制的に立会い延長になったり。
- 44 名前：仕様書無しさん mailto:sage [2011/12/20(火) 15:47:53.04 ]
- >>43
それはお前のせいじゃ、ドアホ
- 45 名前：仕様書無しさん mailto:sage [2011/12/20(火) 18:27:26.88 ]
- アホでもわかりやすいところは詳細に書いて、説明が面倒臭いところは適当にごまかす
初期処理と終了処理はソースコードレベルの細かいこと書いてるのに
肝心の主処理は「ファイル変換を行う」の一言だけ
コーダーのための詳細設計書なんて見たことないんで書き方もわかりません
- 46 名前：仕様書無しさん mailto:sage [2011/12/20(火) 18:36:16.08 ]
- そうそう。
納品物件としての仕様書は誤りが書いてないこと、体裁が整ってることが最重要。
それを見てコーディングができるかどうかはまったく評価対象外。
- 47 名前：仕様書無しさん mailto:sage [2011/12/21(水) 18:35:33.03 ]
- だから設計と製造は切り離したほうがある意味確実なんだよね…
保守さえ考えなければ
- 48 名前：仕様書無しさん mailto:sage [2011/12/22(木) 00:37:25.26 ]
- わかってない奴がわかった気分になるための説明書であることが多いよな
実装を前提とした検討用の設計書になってるものを見たことがない
- 49 名前：仕様書無しさん mailto:sage [2011/12/22(木) 00:40:23.62 ]
- わかってない奴に見せてわかった気分にさせるための説明書、か
そして出来ない奴ほど体裁に死ぬほどこだわる
まったくこだわらない奴も出来ない奴だけど
あと文体とかかき方にルールを設けるくせに
Excel方眼紙を卒業できない馬鹿も多いよな
自由度が高いツールを強制して、自由に出来ないように無駄なルールをつくりあげ、
仕事を増やすのが得意技！みたいな
Excelで方眼紙で糞ルールたくさん作られるくらいなら、まだ糞Word使ったほうがマシだわ
- 50 名前：仕様書無しさん mailto:sage [2011/12/22(木) 03:04:13.29 ]
- 個人的には、体裁が整ってることは大切であり、
納品物あるいは後々の保守を考えれば最低条件であると考える
問題は文書作成環境にある
Excel/Wordとも短いレポートを手軽に作成するのには最適なツール
ただし、これを数百ページにおよぶ技術系文書(仕様書/設計書/マニュアル等)に
利用する発想が、適材適所という言葉を知らぬ人が犯す基本的な間違い
- 51 名前：仕様書無しさん mailto:sage [2011/12/22(木) 06:20:58.90 ]
- >>48
> 実装を前提とした検討用の設計書
うちはこういうのばかりだ。
おかげで、他人が見たら「どうコーディングするべきなのか」はわかっても
「どういう意図でそうなってるのか」がまったくわからない状態になってる。
> わかってない奴がわかった気分になるための説明書
メンテナンスする立場で言うと、わかってる奴にしかわからない設計書なんか
残されても、まったく嬉しくないんだ。
- 52 名前：仕様書無しさん mailto:sage [2011/12/22(木) 08:42:43.20 ]
- >>51
どういう意図で、は要件定義から追えば分かるんじゃないの？
分からないと保守更改で死ねる
- 53 名前：仕様書無しさん mailto:sage [2011/12/22(木) 11:53:45.51 ]
- >>50
むかし社内で議論したけど、誰でも開けて編集できて、となると他に候補が無いんだよね。
でも開く環境が変わるとテキストがズレて崩れるけど（爆笑
Word使うなら箇条書きの範疇で済ます。
凝りたいならPowerPoint＋PDFかInDesignでごゆっくりどうぞ。
ということにしてる。
- 54 名前：仕様書無しさん mailto:sage [2011/12/23(金) 13:38:32.56 ]
- 「Excel方眼紙滅べ！それで仕様書つくるやつもぜんぶ滅んでしまえ！」
「Wordは糞だが選択肢が他にないんだよな」ってのが前提にある奴です
Wordを推したいわけではないけど、Excel方眼紙で設計書作るくらいならWordのほうがいい
>>50
使いやすいとか最適だとは一切思わんけど、Wordはそういう文書作成に使う物じゃね
もちろんExcelはない。使い捨てのレポートみたいなフリーフォーマットで使い捨てるものなら方眼紙は便利だと思うけど
>>51
言葉足りずで申し訳ない
48で言ってるのは、あくまでも「設計書」に書く内容の話な
そういうわかってない人への説明や方針決めの経緯は、
もっと上流の要件定義だったり、補足資料として別に纏めるものだと思う
そういうのがかかれてないドキュメントに恵まれてるのは、いい環境だと思うけどな
>>53
Wordの基本機能ですら、世間一般に「凝ってる」レベルだって捕らえられちゃうことが一番の原因だと思うわｗ
ドキュメント関連でWordを使う利点は、文章を書く以外のことに気を使わなくてよくなる、ってところと
体裁だけを全体纏めて修正でき、印刷のことも考えなくて済む、ってところ。このあたりが表計算ソフトのExcelにはない
ただ、それぞれの機能が使い難いし、理解しづらい
なにより、そういう基本機能ですら理解出来ない、しようとしない奴が多すぎて、まともに使われることが少なく、
仮にちゃんと作られてるドキュメントでも、そういう理解能力がない馬鹿が一人チームに混じってるだけで
簡単に設定されてる体裁の破壊が出来てしまうから、使えないツールになりがちなのよね
- 55 名前：仕様書無しさん mailto:sage [2011/12/23(金) 13:40:57.60 ]
- >>51
>おかげで、他人が見たら「どうコーディングするべきなのか」はわかっても
>「どういう意図でそうなってるのか」がまったくわからない状態になってる。
うちではわかってないヤツ向けの仕様書書いてるけど、そのわかってないヤツが
意図とか書くと余計なこと書くなって言ってくる
なもんで「どういう意図でそうなってるのか」は偉い人から口頭で聞いてソースのコメントに書いておく
> メンテナンスする立場で言うと、わかってる奴にしかわからない設計書なんか
> 残されても、まったく嬉しくないんだ。
わかってないヤツの想定が違う
OSって何ですかレベルのヤツを指してる
>>51の組織ならそのプロジェクトに参画してなくてもコーダーなら理解でできる仕様書を書きやすい気がするが
そういう組織に属したことないからよくわからんけど
- 56 名前：仕様書無しさん mailto:sage [2011/12/23(金) 13:54:01.69 ]
- >>53
あ、あと、PowerPointとかinDesignで設計書はないわｗ
何のための設計書かがわからなくなる
それやるくらいならまだExcel方眼紙にオブジェクト張って済ませばいいと思う
そういや、ここじゃないどっかでみたけど、
Wikiを設計書に使うってのも結構面白い発想だなって思った
バックアップ含めて管理面での自動化できるし、差分や履歴も簡単に見れる
2拠点間での共有も楽で、一元管理もしやすい
図説みたいな自由度への制限とか、環境の構築が必要だとか、他に提出するときどうするの、とか
ドキュメントとレイアウトがどうしても混ざってしまうような欠点もいっぱいあるんだけど、
外に出ないものなら結構便利そうではある
- 57 名前：仕様書無しさん mailto:sage [2011/12/23(金) 14:14:41.55 ]
- >>55
> わかってないヤツの想定が違う
そうそうｗ
文章を読むことすら出来ないような人とか、特にそういうこといってくるｗ
箇条書き、図説、表あたりしか理解してもらえない。
そういうのは設計書じゃないだろって思うけど、その思いは言葉にしても届かない！
結局本当の設計書は各担当の頭の中で作成されちゃうのよね
自分も他に書ける場所がないする事はできるだけコメントに残したりしちゃう派だけど、
ソース弄る奴にも、先にあげたようなのが混ざったりする事もあるから
保守されないコメントが、現状の実装と異なる状態になるかもしれなくて、コメントに残しすぎるのも怖いんだよな
マに免許とかそういうのはないし、コーダーのレベルもピンキリ激しい
あとコメントじゃレビューとかもないから、誤記ったりしてもそのまま残る可能性が怖い…
- 58 名前：仕様書無しさん mailto:sage [2011/12/23(金) 15:10:40.62 ]
- はぁ？
設計書って言ったら図だろ。
お前車とか家とかの設計書見たことあるのか？
- 59 名前：仕様書無しさん mailto:sage [2011/12/23(金) 15:24:27.50 ]
- あはっ♪
設計書って言ったら、ﾌﾂｰ「設計書がどうしたんや！何して欲しいんかちゃんと云いなはれ。そんなんで伝わると思うたらおお間違いや」
設計書是也設計書。
設計書見たことあったらどうなのか？ 無かったらどうなのか？ もったいぶってても大した話じゃないならとっとと話を進めなさい。
- 60 名前：仕様書無しさん mailto:sage [2011/12/23(金) 15:44:03.59 ]
- つーか、設計書を曖昧に自然言語で書くなよ。
- 61 名前：仕様書無しさん mailto:sage [2011/12/23(金) 16:52:30.19 ]
- たしかにマも土方だが、そういう方面の土方ではないぞ。
- 62 名前：仕様書無しさん mailto:sage [2011/12/23(金) 16:56:26.25 ]
- 理解能力がない人に見せる資料は設計書とは分けたほうがいいけど、理想どおりにはいかないしな。
結局頭の中が下の連中に合わせないといけなくなる。
- 63 名前：仕様書無しさん mailto:sage [2011/12/23(金) 18:12:55.40 ]
- >>60
自然言語で表現できないかしづらい内容までドキュメント化しろなんては思ってないよ
シーケンス図とかクラス図で済むことならそっちでやるし
きっちりかっちり自然言語を使わず表現できる部分なら、それはもうコーディングしちゃえばいいんじゃね
>>62
まぁ結局そうなるんだよな
- 64 名前：仕様書無しさん mailto:sage [2011/12/23(金) 18:14:46.69 ]
- > きっちりかっちり自然言語を使わず表現できる部分なら、それはもうコーディングしちゃえばいいんじゃね
うん。だから設計書＝コードなんだってば。
日本語は、コメントとして書けばいい。
- 65 名前：仕様書無しさん mailto:sage [2011/12/23(金) 18:27:27.47 ]
- プログラム設計書は要らないと思うが、それより上の工程でのドキュメントは必要。
- 66 名前：仕様書無しさん mailto:sage [2011/12/23(金) 18:31:32.60 ]
- >>65
ISOなんとかのためなのかどうかは知らないけど、
プログラム設計書は求められる現場が多い。
それより上の工程のドキュメントは無くても。
- 67 名前：仕様書無しさん mailto:sage [2011/12/23(金) 19:26:36.89 ]
- >>66
上の工程のドキュメントはどんなにわけわからんこと書いてても
我々に文句言う権利ないしね
- 68 名前：仕様書無しさん [2011/12/29(木) 20:13:18.23 ]
- >>4
プログラム設計書は重要じゃないけど
プログラム設計は重要
この重要性が現場でも理解されてないからプログラマの地位は低い
- 69 名前：仕様書無しさん mailto:sage [2011/12/29(木) 23:33:00.91 ]
- 設計書くのは重要だと思うけど、最低限まともにレビューできる奴がいないと、作る意味がないんだよな
的外れな指摘しかされてない、半端な設計書なんて用意しても、結局糞の役にも立たないなんてことになるしなぁ
- 70 名前：仕様書無しさん [2011/12/29(木) 23:48:36.19 ]
- レビューは、その場で見て思いつきで指摘して終わるからな
ちゃんと修正されたか再レビューしないことも多いし
儀式的なものになり果てている
担当を複数人にしてお互いにチェックするという仕組みにしたらいいと思うんだが
- 71 名前：仕様書無しさん mailto:sage [2011/12/30(金) 03:36:34.51 ]
- >>70
それは単純に開発プロセスの問題な気がする。
プロセス監査とか無いの？
結局開発者自身が本当に改善したいと思ってるかどうかと、
さけるリソースがあるか、によるんだよなぁ。
実際真面目に取り組むとちょーメンドくてしんどい。
けど効果はある。
- 72 名前：仕様書無しさん mailto:sage [2011/12/30(金) 10:14:50.14 ]
- 開発プロセスの問題じゃなくて、
各々の文章チェック能力、設計力の問題だろ。
- 73 名前：仕様書無しさん mailto:sage [2011/12/30(金) 13:08:13.71 ]
- そら有能な個人の力に頼るのが早いてのは分かるけどさ。
再レビューが無いのが問題だと感じてるなら、
再レビューしたかチェックする機構があるべきだし、
「指摘がその場の思い付き」「儀式的になってる」とか、
不具合流出の分析とそれによる対策がされて無いわけじゃん。
レビュー観点の整理とか、インスペクションの導入とか。
実際>>70自身言ってる「チェックの仕方」自体プロセスそのものだし。
低レベルでの開発プロセス定義なんて、最低以下の人間に
最低限の仕事させるためのもんだよ。
高生産性や高品質はその次の話。
- 74 名前：仕様書無しさん mailto:sage [2011/12/30(金) 13:43:16.95 ]
- d.hatena.ne.jp/iad_otomamay/20111207/1323276264
- 75 名前：仕様書無しさん mailto:sage [2011/12/30(金) 13:44:56.99 ]
- 低レベルの人間に何回チェックさせても無駄。
プロセス重視することと、内容を軽視することは同義。
- 76 名前：仕様書無しさん mailto:sage [2011/12/30(金) 14:32:32.56 ]
- ＞プロセス重視することと、内容を軽視することは同義。
レベル低くて笑える。
それ素振りやっただけで上手くなった気分になって満足してる奴らの話だろ。
まぁ好きにしたらいいよ。
- 77 名前：仕様書無しさん mailto:sage [2011/12/30(金) 14:43:31.28 ]
- プロセスを突き詰めて問題が解決するなら
docomoの障害は起きなかっただろう
- 78 名前：仕様書無しさん mailto:sage [2011/12/30(金) 14:50:18.73 ]
- 無駄なプロセスばかりが増えていく。
内部統制とかいい例。
- 79 名前：仕様書無しさん mailto:sage [2011/12/30(金) 14:55:27.70 ]
- プロセスを突き詰めても
人間がある以上トラブルは発生する。
だがプロセスがなければ
もっと多くのトラブルが発生する。
- 80 名前：仕様書無しさん mailto:sage [2011/12/30(金) 14:57:06.08 ]
- >>73が自分で言っているように
＞低レベルでの開発プロセス定義なんて、最低以下の人間に
＞最低限の仕事させるためのもんだよ。
こういうことなんだろう。
そもそも最低の人間を使わなければいいのに。
- 81 名前：仕様書無しさん mailto:sage [2011/12/30(金) 15:01:14.00 ]
- 自称上級者が簡単なことを
やらないからいけないんだろうな。
- 82 名前：仕様書無しさん mailto:sage [2011/12/30(金) 16:38:54.26 ]
- 低レベルの人間大量に投入してプロジェクト上手く回すのがプロマネの仕事です。
レベル高い人間を集めるられることを前提に計画建ててる時点で破綻してる。
- 83 名前：仕様書無しさん mailto:sage [2011/12/30(金) 16:54:01.72 ]
- >低レベルの人間大量に投入してプロジェクト上手く回す
ってのは可能なのか？
- 84 名前：仕様書無しさん mailto:sage [2011/12/30(金) 17:23:42.55 ]
- >>82
ソフトの世界は量ではなく質なので
その方法では一流になれません。
- 85 名前：仕様書無しさん mailto:sage [2011/12/30(金) 17:26:31.44 ]
- 質の良いソフトがビジネス的に成功した例は皆無だよ。
WindowsとかOracleとかのバグの多さを見れば明らかだろう。
- 86 名前：仕様書無しさん [2011/12/30(金) 17:29:43.68 ]
- ビジネス的に成功 と バグの多さ にどういう関係が？
- 87 名前：仕様書無しさん mailto:sage [2011/12/30(金) 17:30:54.35 ]
- >>85
低レベルの人間を大量に集めて
WindowsとかOracleを作れると思ってるなら
おめでたいな
- 88 名前：仕様書無しさん mailto:sage [2011/12/30(金) 17:33:25.76 ]
- 質より量を重視した結果バグだらけになっても、多機能を売りにビジネス的には成功するって話。
- 89 名前：仕様書無しさん mailto:sage [2011/12/30(金) 17:35:04.30 ]
- >>87
本気で高レベルの人間が、少数精鋭で作ってると思ってるなら頭おめでたいですね。
- 90 名前：仕様書無しさん [2011/12/30(金) 17:39:40.42 ]
- 人が大量にいないと作れんが
その人達は全員がある程度高レベルの人間でないと作れない
特に優秀な人が必要なのはプログラマレベルだろう
例えば日本のゼネコンシステム会社にMFCとか.NETライブラリとか作れるか?
上流工程(藁)SEには作れないし、寄せ集めプログラマ作れるものではない
- 91 名前：仕様書無しさん mailto:sage [2011/12/30(金) 17:40:06.15 ]
- Microsoftはバグですらビジネスに利用して一流になったわけだし。
新しいバージョンではバクやセキュリティホールが治って価値が上がってる、だから新バージョンを買ってくれってね。
- 92 名前：仕様書無しさん mailto:sage [2011/12/30(金) 17:45:26.88 ]
- 残念ながらOS作ってる奴らの大半は、寄せ集めの短期契約プログラマーだよ。
- 93 名前：仕様書無しさん mailto:sage [2011/12/30(金) 17:47:53.64 ]
- え、マジで？
デビッドカトラーとかは伝説なの？
- 94 名前：仕様書無しさん [2011/12/30(金) 17:54:50.00 ]
- >>92
正社員か下請けか派遣かとかの所属のことを言ってるんじゃないよ
- 95 名前：仕様書無しさん mailto:sage [2011/12/30(金) 18:07:55.47 ]
- 著名な人間の間違いは指摘できないから、それが正式な仕様としてドキュメント化されるプロセスが定着してしまったんだろうね。
今のwindowsは糞仕様が多すぎる。
- 96 名前：仕様書無しさん [2011/12/30(金) 18:16:30.51 ]
- 「仕様がクソ」と多くの人が言うが、「どこがクソ」かを言う人は少ない
- 97 名前：仕様書無しさん [2011/12/30(金) 18:21:10.54 ]
- >>96
そいつが、そういう仕様になってる理由を理解できる頭がなく
分かってないだけのことも多い
単に自分の分担分の作業が増えて面倒だというだけの理由の場合もあるな
- 98 名前：仕様書無しさん mailto:sage [2011/12/30(金) 18:24:17.49 ]
- バグ報告のサイトで散々言ってるから。
- 99 名前：仕様書無しさん mailto:sage [2011/12/30(金) 21:04:55.59 ]
- >>87 >>90
多人数大規模の開発ってのをなんか勘違いしてるでしょｗ
まず前提条件として、大規模っていうの数万、十数万人月という工数で
すごいプログラマが通常の10倍の生産性だったとしても
1000ヶ月、83年、そんなに時間かけられますかって話なんだよ。
WindowsとかOracleとかそんなのは難しいだけで工数はそんなに必要ない。
簡単だけど工数は大きいという仕事のほうが世の中には多いんだよ。
OSやDBMSなんて殆どの人は使うだけで作ったりしないでしょ？
そしてOSやDBMSを使うだけの仕事に、OSやDBMSを開発できる人間を
担当させるのは、どう考えても仕事の振り方間違ってるよね？
そして仕事である以上、納期とコストの事を考えないといけない。
工数から考えて、少数のすごいプログラマだけで作れる期間は与えられない。
なら、すごくないプログラマを投入するしかない。これは絶対条件。
じゃあどうするか。ここまで考えてものを言ってる？
- 100 名前：仕様書無しさん mailto:sage [2011/12/30(金) 21:05:54.53 ]
- >>93
戦うプログラマー読んだけど、優秀な人間を大量に集めてやっとNTが作れた
からな。 アレで分かったことは、大規模開発には大量の人が必要です、
可能な限り優秀な人間が大量に。ただ人を入れればいいというわけでは
ありませんってこと。 人月の神話で言われてる、人を入れてもロスが多い
云々ってのをロスがあっても優秀な人間で底上げするっていうこと。
- 101 名前：仕様書無しさん mailto:sage [2011/12/30(金) 21:09:50.44 ]
- > 可能な限り優秀な人間が大量に。
それは現実的ではない。
そんなに人捕まえられないし、
優秀な人間はコストがかかる。
俺が提案する方法（普通の方法だが）は
システム全体を難しい部分と簡単な部分に分離していく。
難しい部分は優秀な人間が、簡単なところは技術力が低いプログラマが。
Windowsみたいにいくらでもコストが掛けられるような場合はいいが
実際はこういうふうにして行かないとやっていけないでしょ。
- 102 名前：仕様書無しさん mailto:sage [2011/12/30(金) 21:17:54.26 ]
- システムに簡単な部分と難しい部分があることに
気づかない人って理解出来ない。
一人でシステムすべてを作っているからその違いを考える必要がないのかな？
上級プログラマ、つまりアーキテクトとしての力があると自然とシステムを
難しいコアの部分と簡単な末端部分に分けると思うんだが。
コアの部分は重要だけど規模としては小さくなる。末端部分は簡単だけど数は多い。
普通こうなるし、こうなるように設計するはずなんだ。
そしてシステムを分離した時、他に人がいるなら簡単な末端部分を
アーキテクトである自分がやるのは効率が悪い。
一介のプログラマで十分って気づくよね？
これが最適化されたシステム開発の姿だと思うんだが。
- 103 名前：仕様書無しさん mailto:sage [2011/12/30(金) 21:36:32.25 ]
- 80:20の法則ってのがある。プログラムのパフォーマンスの80%はソースコードの
20%が出しているっていうやつ。オフショアに出して安く上げることを考えるに
しても、そういうコアな20%の部分を自分の所でキープ出来るかでプロジェクトの
成否が別れたりする。たいがい、まとめてドーンて出してドーンて失敗するん
だけどね。
- 104 名前：仕様書無しさん mailto:sage [2011/12/30(金) 21:44:22.22 ]
- 80歳まで20本の歯をｷｰﾌﾟって歯無し
- 105 名前：仕様書無しさん mailto:sage [2011/12/31(土) 02:30:31.77 ]
- そもそも大規模な仕事をやる必要があるのか？
金掛けて糞積むようなもんでしょ。
- 106 名前：仕様書無しさん mailto:sage [2011/12/31(土) 02:44:58.74 ]
- 金さえあればどんな仕事もやる必要はないよｗ
- 107 名前：仕様書無しさん mailto:sage [2011/12/31(土) 02:57:52.93 ]
- >>105
この業界に生きるものとしてそれを言ってはいけないwww
俺らが生活できるのは誰のおかげかwww
あるテーブルの値を合計して別なテーブルに書きこむとかいう処理を
何十万かけて作って、それを何百本と作って、何十億円の巨大プロジェクトとか
作ってて虚しくならないかと思うんだけどだけど >>99 とかはそういう巨大さに充実感を感じるんだろう
実際に稼働することで開発費以上の利益を生むわけだし、お客が納得してれば別にいいんだけど
- 108 名前：仕様書無しさん mailto:sage [2011/12/31(土) 03:07:08.76 ]
- >>107
充実感？
お前の個人的な基準を人に押し付けないでね。
- 109 名前：仕様書無しさん mailto:sage [2011/12/31(土) 03:09:36.92 ]
- >>107
俺にとっての充実感は多くの人を管理して
少ないコストで大規模なシステムを作り上げること。
末端の作業をやって充実感があるわけ無いだろｗ
そんなものは部下にやれと命令する。これもまた充実感。
- 110 名前：仕様書無しさん mailto:sage [2011/12/31(土) 09:43:06.33 ]
- ソフトは
大規模 = 価値がある
わけじゃないんだよね。
- 111 名前：仕様書無しさん mailto:sage [2011/12/31(土) 09:47:30.43 ]
- Gmailはシンプルな仕様で工数的にはそんなに掛かってないはず
でも世界中の人が利用してる。
これからの時代、SIerも淘汰が始まると言われている。
金持ちに粗悪品売るような商売も長く続かないだろう。
- 112 名前：仕様書無しさん mailto:sage [2011/12/31(土) 09:55:41.34 ]
- 請負やってりゃ客の金をたくさん取るのが正しいんだろうけど
それがソフトのあり方だと思わないで欲しいね。
自社サービスやってればそんな発想は出てこないだろうに。
- 113 名前：仕様書無しさん mailto:sage [2011/12/31(土) 10:30:52.64 ]
- >>110
そんなの当たり前だろｗ
なんでそんなことを言うのかしらんが、
もしかして、大規模なら価値がないとでも
言いたいのか？
- 114 名前：仕様書無しさん mailto:sage [2011/12/31(土) 10:39:48.70 ]
- >>111-112
何をそんなに否定したいのかさっぱりわからんのだが。
話をまとめるぞ。
・優秀なプログラマを必要な数だけ揃えられるとは限らない。
・優秀なプログラマであっても、ものを作るには時間がかかる。
・どこの会社にも、優秀なプログラマよりも、技術力の低いプログラマはいる。
・手に入るカードで最短の時間とコストで作る必要がある
・うまく人を配置しましょう。
・そのためにシステム全体を重要なコアとそうでない部分に分ける必要があります。
（・俺の仕事は重要なコアの作成とそうでない部分の分離です）
・簡単なところは技術力の低いプログラマにまかせます。
・技術力の低いプログラマは経験を積んで技術がついてきたら徐々に重要な所を担当させます。
これのどれを否定したいんだ？ 現実的なやり方だろ。
否定しなきゃならない理由でもあるのか？
- 115 名前：仕様書無しさん mailto:sage [2011/12/31(土) 10:44:25.43 ]
- >>113
大規模 = コンパクトにする努力をしてない
と思う。
- 116 名前：仕様書無しさん mailto:sage [2011/12/31(土) 10:50:43.25 ]
- >>114
規模が大きければそうせざるを得ない。
ただ、その規模必要なの？
- 117 名前：仕様書無しさん mailto:sage [2011/12/31(土) 10:53:25.11 ]
- docomoの障害だってそうだよな
何重ものいらんチェック付けて工数増大させてる割には
肝心なところが抜けてる
- 118 名前：仕様書無しさん mailto:sage [2011/12/31(土) 12:00:58.87 ]
- >>115がすべて
規模の大小なんて大した問題ではない。
努力が足りないだけ。
- 119 名前：仕様書無しさん mailto:sage [2011/12/31(土) 12:09:58.89 ]
- >>116
規模の大小に関係なく、
開発期間とコストを下げるには必要なこと。
大規模ではもちろんのこと、小規模であっても
小規模なら会社も小さく、優秀なプログラマを雇う金もないし
人も来ない。
最初から技術力が高い人を手に入れられるわけじゃないんだよ。
金があったとしても、必要なときにすぐに来てくれるわけでもない。
それが現実。
- 120 名前：仕様書無しさん mailto:sage [2011/12/31(土) 12:14:56.82 ]
- >>117
そうだよね。
難しいコアの部分と簡単なところを分離してないからいけない。
docomoなんかは、コア優秀な人を十分に割り当てられなかったのが原因。
大会社になれば優秀な人は社内のどこかにいるはず。
そういう人がつまらない仕事をしていたのだろう。
コアと簡単な所を分離する。こがまさに大規模なものを
コンパクトにするということだよ。
そして少数のコアと多くの簡単な所に分けられる。
そして優秀な人の仕事を減らしつつ、簡単だが量が多い所に
適当に集めた人材を大量投入する。
- 121 名前：仕様書無しさん mailto:sage [2011/12/31(土) 12:34:56.56 ]
- 神は細部に宿る
これはソフトにも当てはまると思う。
簡単だからといって適当な仕事をされたら、たまったもんじゃない。
アーキテクトの目が届かない範囲にまで規模が膨れたら
それはもう分を超えているのではないか。
- 122 名前：仕様書無しさん mailto:sage [2011/12/31(土) 13:12:47.30 ]
- プログラマとして、自分の受け持つ設計やコード等に神を宿す努力をするべきだが、ビジネスの場にそれを持ち込むのは、切り分けができていない二流。
全体のレベルが高くある必要があると思うなら、均一なレベルにできるシステムを考えろよ。(そもそも、俺が考えた最強のが多い気がするが)
お前らは、自分ができる奴だと思いたい、出来ない奴を叩きたいだけで、実際はご近所さんで毎日集まって愚痴ばかり並べてる様なそこらの主婦となんら変わらないクズなんだよ。
|
 |
