- 1 名前：仕様書無しさん mailto:sage [2011/11/26(土) 11:26:56.24 ]
- 外部だの内部だの基本だの詳細だの…
曖昧な基準で書かれた、いろいろな名前で呼ばれてて
「これってどうなの？」「意味あるの？」といった物に出くわす事も少なくない
しかし、純粋にプログラミングだけをして食べていくことは、昨今じゃ難しく
避けて通れない、否が応でも作る機会に出くわしてしまう、そんなドキュメントたち
設計書や仕様書についても、マ視点で語ろうぜ
・自分のなかでの仕様書/設計書の呼び方と分け方
・成功談、失敗談
・仕様書/設計書は何を使って作成する？(Word/Excel/HTML/手書き！)
・仕様書/設計書に含める図の作成方法や使っているツール紹介
・炎上プロジェクトでみた(よくない意味で)素晴らしい仕様書/設計書
・そもそも仕様書/設計書って本当に必要なの？
・こんな仕様書/設計書は、ぶっちゃけアリ？ナシ？
などなど、設計書にまつわる話題を募集
- 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
設計書ださないと要件ださないって、、順序おかしくね？
設計書じゃなくてそれは提案だとおもうのだけど 、先に設計書つくらせるのは大手なら先行着手でコンプライアンス違反だな
- 149 名前：仕様書無しさん mailto:sage [2012/01/06(金) 09:00:07.04 ]
- >>148
頭の悪い客に付き合わされてるんだろ
- 150 名前：仕様書無しさん mailto:sage [2012/01/06(金) 20:31:44.49 ]
- 作る物も教えずに設計図出せってw
マジシャンじゃないんだからw
- 151 名前：仕様書名無しさん mailto:sage [2012/01/06(金) 20:44:29.53 ]
- 画面設計書とかある程度の叩き台先に作って見せないと打ち合わせが進まない。
要件がよく分からないからって設計書作らずに打ち合わせ行ったら、何も用意せずやって来て無駄な時間取らせるんじゃないと、一蹴されるよ。
- 152 名前：仕様書無しさん mailto:sage [2012/01/06(金) 20:51:37.53 ]
- それは設計じゃなく要件定義だろ
- 153 名前：仕様書無しさん mailto:sage [2012/01/06(金) 21:17:18.58 ]
- >>151,152
See >>142
- 154 名前：仕様書無しさん mailto:sage [2012/01/06(金) 22:06:44.06 ]
- >>153
だから、要求を洗い出して、客に提案して、合意をとった上で始めて設計が固まるだろ。
その安価は何が言いたいんだ？
- 155 名前：仕様書名無しさん mailto:sage [2012/01/06(金) 22:07:24.61 ]
- 要件定義で画面レイアウト決めるのは要件定義ですか？
- 156 名前：仕様書無しさん mailto:sage [2012/01/06(金) 22:07:36.12 ]
- >>151
あとそれ、サンプルと提案書な
- 157 名前：仕様書無しさん mailto:sage [2012/01/06(金) 22:11:34.32 ]
- 外部設計と内部設計の話を混ぜるな
- 158 名前：仕様書無しさん mailto:sage [2012/01/06(金) 22:54:36.05 ]
- 画面仕様を設計だと言い張るSEがいたなぁ。
自分が設計までしたんだから、あとはPGの仕事だと。
- 159 名前：仕様書無しさん mailto:sage [2012/01/06(金) 23:47:00.77 ]
- 今できる最適解は、
プロジェクトやメンバの性質にマッチした仕様書・設計書を適切なタイミングで作成すること。
これに尽きる。
必要な成果物は常に考えながらプロジェクト遂行しなければならない。
成功プロジェクトや経験だけに頼ったやり方はダメ。怠るとデスマ確定。
嫌なら法整備して厳格にすべき。この産業はいつになったら法整備されんだよ。
- 160 名前：仕様書無しさん mailto:sage [2012/01/06(金) 23:51:47.90 ]
- 合意をとった上で始めて設計が固まる と思ってるなら、まだ青臭いな。
合意はその時点での合意でしかない。
- 161 名前：仕様書無しさん mailto:sage [2012/01/07(土) 00:20:57.53 ]
- >>99
サラリーマン思考で乙としか言えないな。
>WindowsとかOracleとかそんなのは難しいだけで工数はそんなに必要ない。
あんた業務システムしか経験したことないでしょ？
知らない分野のことは安易に言い切るなよ。
一般に高難易度のものは工数積むだろ。
- 162 名前：仕様書無しさん mailto:sage [2012/01/07(土) 00:53:57.55 ]
- >>160
いや、そうあるべきって話しであって、必ずそうでなければならないとは言っていない。
設計と要件定義をごっちゃにしてる奴がいたから言っただけ。
会社にとって総合的に利益のほうが上回る事が見込まれるのであれば、カチカチの行程なんてたどる必要はない。
- 163 名前：仕様書無しさん mailto:sage [2012/01/07(土) 02:37:44.26 ]
- 顧客要求事項が曖昧なまま設計しても、すぐに行き詰まって、手戻りが起こる。
コストばかり費やして成果物は完成しない。
予算も納期も限られてるのだから、ある程度踏ん切りつけさせろ。
機能を諦めさせるか次の開発に乗っけさせて貰うとか交渉が必要。
- 164 名前：仕様書無しさん mailto:sage [2012/01/07(土) 02:47:34.20 ]
- >>159
法整備って、何を定めるんだよw
- 165 名前：仕様書無しさん mailto:sage [2012/01/07(土) 03:00:02.21 ]
- >>163
結局、金ある所からなーなーで仕事もらうのが一番無難に儲かるという。
- 166 名前：仕様書無しさん mailto:sage [2012/01/07(土) 06:57:07.49 ]
- >>159
>プロジェクトやメンバの性質にマッチした仕様書・設計書を適切なタイミングで作成すること。
「性質」やら「適切」とやらの定義が曖昧だね
これが
>成功プロジェクトや経験だけに頼ったやり方はダメ。
の典型例なのかな？
しかも
>必要な成果物は常に考えながらプロジェクト遂行しなければならない。
という精神論
たぶん>>159の担当プロジェクトは、いつも
>怠るとデスマ確定。
なんだろねw
- 167 名前：仕様書無しさん mailto:sage [2012/01/07(土) 08:06:00.21 ]
- デスマするかしないかはドキュメントで決まるだろ
デスマで食ってるやつはドキュメントをわざと書かせないから、分かるよドキュメントなくて作業なんか進まないところにザコを沢山投入して上まえハネテ儲ける
そうゆうヤクザなやり方してんだよ
- 168 名前：仕様書無しさん mailto:sage [2012/01/07(土) 10:55:22.07 ]
- >>162
カチカチの行程のほうが開発会社の利益になるんだ
臨機応変に効率的に要件を満たすソフトを作ってしまったら
工数も次フェーズの仕事も減ってしまう
- 169 名前：仕様書無しさん mailto:sage [2012/01/07(土) 11:23:10.97 ]
- 結局実現可否まで判断しきれないと、ちゃんとした設計はできないし、手戻りも増えるから、
設計担当でも最低限のコーディング知識くらいは必要だよなホンと。
無能なSEやSIが上流に居座ってると、いいことがまったくない。
- 170 名前：仕様書無しさん mailto:sage [2012/01/07(土) 11:28:21.52 ]
- デスマに必要な要素っていうと
-要件をまとめ切れない、仕様を確定できないままずるずる時間を無駄遣いする
-実現不可能な妄想をして手戻りを起こし時間を無駄遣いする
-時間がないや知識不足で仕様書を作成できず、実装担当に情報を渡さない
-スキル不足で実装ができないか大幅に遅れ、テストや改修時間がなくなる
こういうのがあるんじゃないかなと思うけど、
考えてみたらうちの職場は上3つが全部当てはまってる素敵なところだった
そんな状況で工数が不足し、新人投入しはじめたから4番目のもヒットしそうな勢い
やったね！
- 171 名前：仕様書無しさん mailto:sage [2012/01/07(土) 11:33:07.84 ]
- >>168
あー…書き方わるかったかな。
カチカチのほうが確実な見込みが取れるから安全だけど、わがままな客やあまり頭の良くない客だとしても、利益が見込まれるなら受けるって話。
- 172 名前：仕様書無しさん mailto:sage [2012/01/07(土) 11:33:15.22 ]
- デスマってるところは、大概何も考えずに
行き当たりばったりでコーディングしてる。
Railsとかフレームワーク使えば簡単に作れるとかいって
フレームワークの正しい使い方も調べずに
へんなやり方でトライして動いた、じゃあOK。で進めてる。
簡単に作れるというのも考えものだよ。
何も考えずに動いてしまうってことだから。
でへんなやり方になっていって、デスマに陥る。
- 173 名前：仕様書無しさん mailto:sage [2012/01/07(土) 11:35:48.66 ]
- 本来は設計レベルを担当する人が
フレームワークの正しい使い方、ベストプラクティスを調べて
それを下っ端のプログラマに伝えるべき。
だから設計者はプログラミングを高いレベルで習得してなければならない。
デスマってるところは、設計者はプログラミングをしない。
そして全部下っ端プログラマに任せる。
で下っ端は管理されてない状況で好きかってやって
デスマを引き起こす。
- 174 名前：仕様書無しさん mailto:sage [2012/01/07(土) 11:49:32.69 ]
- 昔みたいに要件や仕様をしっかりまとめてから開発するというやり方は変化が激しい今は
通用しなくなってる。だから、素早い開発が重要。そのためには拡張性と柔軟性を
備えたシステム基盤を作れないといけない。
この拡張性や柔軟性というのは、どんなものにも耐えられるものが目標だから、
要件や仕様は参考程度確定していればいい。そして作りたいシステムとは独立した、
汎用的な拡張性、柔軟性を持った設計の基盤の実装をシステム開発よりも先に行う。
作りたいシステムは短いコードですぐに実装できるよう、多くのものを汎用的な基盤に持っていく。
そこまで行っていれば、要件や仕様が変わってもすぐに対応できるし、
実現不可能かどうかを試すのもすぐに出来るようになる。
ここまでの説明でわかったとおり、要件とか仕様とかそういう話よりも
今は基盤の実装技術が極めて重要なんだ。そこができてればあとはどうとでもなる。
（正確には、どうとでもなるようなぐらいに基盤を作り込んでおく）
デスマを起こすところは作りたいものだけを考えて、基盤のことを一切考えていない。
- 175 名前：仕様書無しさん mailto:sage [2012/01/07(土) 11:52:16.58 ]
- >>171
おまえは何回後付けしてんだよ。
現場にたまにいるわ。
そういう意味じゃないとか言いながら、ジワジワと意味を変えるやつ。
確固たる主張がないなら折れろよ。
言い逃れ野郎は、ひとつ否定されると全人格を否定されてるんじゃないかと思い込むからな。素直に認めろよ。
間違ったことだったとしても認めたらその場だけの馬鹿認定で済むんだぞ？
- 176 名前：仕様書無しさん mailto:sage [2012/01/07(土) 12:03:40.41 ]
- >>174
君の考える基盤って、いわゆるフレームワークに限定してないか？
基盤というともっと低レベルだったり、ハードウェア選、インフラ系を含んだりする。
- 177 名前：仕様書無しさん mailto:sage [2012/01/07(土) 12:17:26.68 ]
- >>174
変化が早いから素早い開発が要件されてるわけじゃなくて、
金がないから開発期間を短く設定するしかないんだよ。
本来は、3年5年かける規模をわずか半年で開発しているのが現状。
単にゴールを決めて開発してるに過ぎないんだよ。
だから、出荷後や運用開始後に『保守という名目や、改善という名目でバグ修正』
システム開発の世界では、スカイツリー完成に与えられる期間は半年である。
- 178 名前：仕様書無しさん mailto:sage [2012/01/07(土) 12:29:36.70 ]
- >>173
システムエンジニアとプログラマを上下関係の階層構造で考えるのは限界があると思うよ
プログラミングを高いレベルで習得してる人と
業務ロジックを高いレベルで基本設計にまとめられる人は別人でもいい
>>174
顧客と折衝し開発範囲と仕様を定義するシステムエンジニアと
それをソフトウェアとして構築するプログラマは別モンてことだな
設計書を書くだけのシステムエンジニアは
詳細設計書見てコーディングするだけのコーダー同様に
要らなくなるかもしれん
- 179 名前：仕様書無しさん mailto:sage [2012/01/07(土) 12:53:59.54 ]
- 設計にプログラムの作成とかやらせたらダメだよ。
本来やるべき設計に手が回らなくなって、デスマ化する。
- 180 名前：仕様書無しさん mailto:sage [2012/01/07(土) 13:12:21.58 ]
- デスマ化するかはお客との調整がすべてだと思う。
- 181 名前：仕様書無しさん mailto:sage [2012/01/07(土) 13:13:00.33 ]
- 設計者と実装者を別けた時点でデスマ率UP
- 182 名前：仕様書無しさん mailto:sage [2012/01/07(土) 13:21:09.93 ]
- >>181
> 設計者と実装者を別けた時点でデスマ率UP
現実問題、人・金がないのだから分けるしか無い。
その場合、設計者がサンプル実装を行なって
それにそったやり方で実装するように決めれば良い。
もちろんレビューも行う。
|
 |
