- 1 名前：仕様書無しさん mailto:sage [2011/11/26(土) 11:26:56.24 ]
- 外部だの内部だの基本だの詳細だの…
曖昧な基準で書かれた、いろいろな名前で呼ばれてて
「これってどうなの？」「意味あるの？」といった物に出くわす事も少なくない
しかし、純粋にプログラミングだけをして食べていくことは、昨今じゃ難しく
避けて通れない、否が応でも作る機会に出くわしてしまう、そんなドキュメントたち
設計書や仕様書についても、マ視点で語ろうぜ
・自分のなかでの仕様書/設計書の呼び方と分け方
・成功談、失敗談
・仕様書/設計書は何を使って作成する？(Word/Excel/HTML/手書き！)
・仕様書/設計書に含める図の作成方法や使っているツール紹介
・炎上プロジェクトでみた(よくない意味で)素晴らしい仕様書/設計書
・そもそも仕様書/設計書って本当に必要なの？
・こんな仕様書/設計書は、ぶっちゃけアリ？ナシ？
などなど、設計書にまつわる話題を募集
- 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 ]
- プログラマとして、自分の受け持つ設計やコード等に神を宿す努力をするべきだが、ビジネスの場にそれを持ち込むのは、切り分けができていない二流。
全体のレベルが高くある必要があると思うなら、均一なレベルにできるシステムを考えろよ。(そもそも、俺が考えた最強のが多い気がするが)
お前らは、自分ができる奴だと思いたい、出来ない奴を叩きたいだけで、実際はご近所さんで毎日集まって愚痴ばかり並べてる様なそこらの主婦となんら変わらないクズなんだよ。
- 123 名前：仕様書無しさん mailto:sage [2011/12/31(土) 13:31:33.09 ]
- >>115
100万行のコードをいくらコンパクトにしても一万行に収まるわけじゃないからなぁ。
- 124 名前：仕様書無しさん mailto:sage [2011/12/31(土) 13:35:08.15 ]
- >>111
> Gmailはシンプルな仕様で工数的にはそんなに掛かってないはず
> でも世界中の人が利用してる。
お前みたいに、UIだけで中身を判断する馬鹿がいるから苦労すんだよ
- 125 名前：仕様書無しさん mailto:sage [2011/12/31(土) 14:29:12.55 ]
- >>114
横レスになるが、自分も同感だね
>>123が現実だから
- 126 名前：仕様書無しさん mailto:sage [2011/12/31(土) 15:43:10.30 ]
- >>124
中国意外な。
- 127 名前：仕様書無しさん mailto:sage [2011/12/31(土) 16:06:58.09 ]
- >>114
理念としては正しい方向性であると思う
というか、昔から同じような事は言われてきた
では、そんな当たり前の事を実践できていないプロジェクトが現実に多いのはナゼか？
という話になる
自分の想像を二点挙げる
まず最初に、>>114では「優秀」という単語が何度も使われているが、
この優秀度を定量的に(=公平かつ正確に)計測するのが難しい点
いわゆる自己申告というものはアテニナラナイ
次に、それら稀少かつ優秀な人材を「開発に着手する前に」最適に配置するのが難しい
まだシステムが形になっていない段階で最適な配置を決定するのは、
高度な未来予測(いわゆる「見積もり」)能力が要求される
また優秀な人物でもすべての分野で完璧という訳ではなくて得手不得手な分野がある
そして優秀な人物は自己過信になりがちだから、ここでも自己申告はアテニナラナイ
- 128 名前：仕様書無しさん mailto:sage [2011/12/31(土) 17:28:04.53 ]
- よくある失敗パターンが、システムのコア部分は精鋭を集めて作れたんだけど、
人数集めて作り始めた周辺部分がぐだぐだになってしまうというやつだな。
ユーザの要望や度重なる仕様変更に晒されて肥大していくのは周辺部分なんだから、
ここに大規模ソフト開発や膨大な仕様の把握などに対応し切れない人を当てると
ぐだぐだになる。
- 129 名前：仕様書無しさん mailto:sage [2011/12/31(土) 18:47:22.24 ]
- 目に見えない制御部分が優れていることより、目に見えるUIが優れていることが優先されるからな。
- 130 名前：仕様書無しさん mailto:sage [2012/01/03(火) 04:25:04.28 ]
- >>96
いろいろとあるが、
OS領域と、ユーザーアプリケーション領域、ユーザーデータ領域が、明確に別れていない部分が糞。
OSが不安定になって再インストールとか、それによってユーザーデータが消えるとか、アプリケーション一つずつ入れ直すとか本来あり得ない思想が前提になってる。
- 131 名前：仕様書無しさん mailto:sage [2012/01/03(火) 08:09:39.88 ]
- >>130
それは *** Windowsが糞 *** という話だね
すべてはレジストリが癌になっている
- 132 名前：仕様書無しさん mailto:sage [2012/01/03(火) 08:57:05.39 ]
- >>131
お前、レジストリがシステムデータと
ユーザーデータでファイル自体分離されてるの知ってる？
- 133 名前：仕様書無しさん mailto:sage [2012/01/03(火) 08:58:20.12 ]
- >>130
それはお前がフォーマットして
インストールするから消えるんだろｗ
- 134 名前：130 mailto:sage [2012/01/03(火) 16:14:34.56 ]
- >>132
システムデータとユーザデータの分離なんて当然の事だろ
レジストリが癌なのは、集中型データベースかつバイナリ形式で保存されること
- 135 名前：131 mailto:sage [2012/01/03(火) 16:15:34.55 ]
- >>134の名前欄を訂正
X: 130
O: 131
- 136 名前：130 mailto:sage [2012/01/03(火) 19:40:30.02 ]
- >>134
ユーザーデータがレジストリとして管理上分離されてても、それのバックアップをとって他環境に復元出来なけりゃ意味ないよ。
- 137 名前：仕様書無しさん mailto:sage [2012/01/03(火) 19:43:09.84 ]
- ユーザー用のレジストリファイルならコピーして
他環境に持って行って普通に使える。
- 138 名前：仕様書無しさん mailto:sage [2012/01/04(水) 02:09:53.63 ]
- 可能ではないけど手間が段違いだからな
しかもあまり一般的じゃないから情報も少ないし保障もない
そういう事が考慮されていない糞設計ってことには違いないよな
- 139 名前：仕様書無しさん mailto:sage [2012/01/04(水) 03:07:19.18 ]
- >>41-44
ワロタエナイ
文書表現ばかりこだわる奴が炎上プロジェクトに投入されると、ますます燃え盛るw
- 140 名前：仕様書無しさん mailto:sage [2012/01/04(水) 08:10:08.82 ]
- >>138
じゃあ、一般的に
レジストリをエクスポートして
インポートすればいいだけじゃね？
何難しく考えてるのよｗ
- 141 名前：仕様書無しさん mailto:sage [2012/01/04(水) 13:00:51.83 ]
- 要件定義がぜんぜんできてない段階で、設計書に着手してるアホばっかだから、
設計書を書いてそれを客に提示して、お伺いを立てるなんて発想が出るんだよ･･･。
だから設計書も設計ではなく要件を書くようになっていって、
肝心の部分がぜんぜん詰められてない状態になって、ただのゴミドキュメントと化す。
全部爆発しろよもう！
っていう愚痴
- 142 名前：仕様書無しさん mailto:sage [2012/01/04(水) 13:50:23.51 ]
- >>141
「お客は いったいどんなプログラムを作って欲しいのか、
そのプログラムの仕様を自分でも理解していない」
「プログラマは客の要求する仕様に合わせてプログラムを作るのではなくて、
自分の作ったプログラムの仕様を客の仕様だとごまかしている」
- 143 名前：仕様書無しさん mailto:sage [2012/01/04(水) 18:31:27.55 ]
- local.joelonsoftware.com/wiki/ビッグピクチャー
- 144 名前：68 mailto:sage [2012/01/05(木) 00:05:27.92 ]
- >>141>>142
何でみんな作る前に仕様を決めたがるんだろうね
作りながら仕様決めながら要件定義するスパイラルでいいじゃん
やたら細部の体裁にこだわってる仕様書を改訂する作業は面倒だと思うが
プログラマまで仕様変更を嫌がるんだもんな
- 145 名前：仕様書無しさん mailto:sage [2012/01/05(木) 00:27:20.87 ]
- >>141
客が設計書を出さないと要件は言わないってさ
しかも要件に合わせて設計書の修正は禁止
>>144
プログラマの立場で仕様変更を嫌がる理由は大抵は仕様改悪にしか見えないから
- 146 名前：仕様書無しさん mailto:sage [2012/01/05(木) 01:50:55.46 ]
- >>141
SI側も客自身も業務を理解してないし、
どういう仕組みを作ればいいかも明確じゃないんだろうね。
漠然と市販ソフトみたいにシステム入れれば、コストが削減できるとか思ってる。
- 147 名前：仕様書無しさん mailto:sage [2012/01/05(木) 23:12:42.51 ]
- 要求定義書→総合テスト
基本設計書→結合テスト
詳細設計書→単体テスト
設計書にはテスト項目の定義を書く。
テストは設計書の内容が確実に実装された事を確認する。
テストってのは、外部から見た動きだから、設計書も
内部的なとこはわりとどうでもいいんだよね。
- 148 名前：仕様書無しさん mailto:sage [2012/01/06(金) 08:30:59.17 ]
- >>145
設計書ださないと要件ださないって、、順序おかしくね？
設計書じゃなくてそれは提案だとおもうのだけど 、先に設計書つくらせるのは大手なら先行着手でコンプライアンス違反だな
|
 |
