- 1 名前：仕様書無しさん mailto:sage [2011/11/26(土) 11:26:56.24 ]
- 外部だの内部だの基本だの詳細だの…
曖昧な基準で書かれた、いろいろな名前で呼ばれてて
「これってどうなの？」「意味あるの？」といった物に出くわす事も少なくない
しかし、純粋にプログラミングだけをして食べていくことは、昨今じゃ難しく
避けて通れない、否が応でも作る機会に出くわしてしまう、そんなドキュメントたち
設計書や仕様書についても、マ視点で語ろうぜ
・自分のなかでの仕様書/設計書の呼び方と分け方
・成功談、失敗談
・仕様書/設計書は何を使って作成する？(Word/Excel/HTML/手書き！)
・仕様書/設計書に含める図の作成方法や使っているツール紹介
・炎上プロジェクトでみた(よくない意味で)素晴らしい仕様書/設計書
・そもそも仕様書/設計書って本当に必要なの？
・こんな仕様書/設計書は、ぶっちゃけアリ？ナシ？
などなど、設計書にまつわる話題を募集
- 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
現実問題、人・金がないのだから分けるしか無い。
その場合、設計者がサンプル実装を行なって
それにそったやり方で実装するように決めれば良い。
もちろんレビューも行う。
- 183 名前：仕様書無しさん mailto:sage [2012/01/07(土) 13:31:21.51 ]
- >>181
納期までに一人で何でもかんでも出来るなら、苦労しないんだよ。
- 184 名前：仕様書無しさん mailto:sage [2012/01/07(土) 13:36:31.46 ]
- >>175
後付してねぇし、言い逃れしてねぇよ。。
言っていることの真意と異なることを返してくるから、細かく答えてるんだろうが。
挑発して勝ったつもりになってんじゃねーぞ。
162で書いた
「会社にとって総合的に利益のほうが上回る事が見込まれるのであれば」
が、何を上回るかって部分をお前は
「カチカチに決めることより利益を上回るなら」
って解釈してイチャモンつけるから
「そうじゃなくて、ビジネスとして利益が上がるのであればという意味だ」
と認識を正してるんだろ。
どこが意味変わっているのか答えてみろよ。
確固たる主張してんだろカス。
- 185 名前：仕様書無しさん mailto:sage [2012/01/07(土) 13:48:34.72 ]
- >>184
ま、利益優先や短納期だと、工程ごっちゃにしちゃうのは、よくある話。
技術者に無理強いする訳だから、ほぼデスマ化するよね。
- 186 名前：仕様書無しさん mailto:sage [2012/01/07(土) 14:12:45.08 ]
- >>177
いまどき、ソフト開発に3年もかけてたら製品発売した時点で時代遅れだってw
- 187 名前：仕様書無しさん mailto:sage [2012/01/07(土) 14:28:08.70 ]
- >>185
それは、利益優先や短納期が悪いっていうより、後出しじゃんけんさせるのが悪いんじゃないの。
- 188 名前：仕様書無しさん mailto:sage [2012/01/07(土) 14:30:29.06 ]
- 新製品のoffice2000向けのツールを作ってたらoffice2003がでました！どうしましょう？
えぇぃ、再設計だ。とわいわいがやがやしてるうちにoffice2007ﾘﾎﾞﾝになってましてどうしましょう？
で、ちんたら勉強してたらoffice2010で標準装備で、実はﾂｰﾙ無用で済みました。てへ。
- 189 名前：仕様書無しさん mailto:sage [2012/01/07(土) 14:52:30.13 ]
- >>181
両方やれるような優秀な人間にプログラムさせるのはもったいない
- 190 名前：仕様書無しさん mailto:sage [2012/01/07(土) 15:33:58.78 ]
- >>187
後出しジャンケンは対応次第で次の開発につながったりするから、一概に悪いとは言い切れない。
対応を誤れば、デスマ化するけどね。
- 191 名前：仕様書無しさん mailto:sage [2012/01/07(土) 16:41:35.24 ]
- >>189
実装しかできない奴に渡してもいいような資料を作る方が時間がかかる。
- 192 名前：仕様書無しさん mailto:sage [2012/01/07(土) 17:10:21.04 ]
- 既に火を噴いてる状況なのに、横から口出してきて
更にいらんことやらせようとする、自称優秀SEがさらに引っ掻き回してくれそうな予感がするこの頃。
- 193 名前：仕様書無しさん mailto:sage [2012/01/07(土) 17:21:50.18 ]
- >>191
仕事を誰かに割り振るようにできないと
一人に負担がかかり過ぎて、うつ病や廃人になるぞ。
- 194 名前：仕様書無しさん mailto:sage [2012/01/07(土) 17:45:05.81 ]
- 設計を誰かに渡してしまえばいい。
- 195 名前：仕様書無しさん mailto:sage [2012/01/07(土) 17:54:56.32 ]
- そうか折衝や設計から外注にやらせればいいんだ
不況で人余ってるから買い叩けるし
失敗したら責任取らせて別の会社にやらせればいい
- 196 名前：仕様書無しさん mailto:sage [2012/01/07(土) 18:13:07.31 ]
- >>195
お前・・・
責任を取ったからって、システムが出来上がるわけじゃないぞ。
失敗した時点で、システムの完成はできていない。
そして儲けが出るほど責任を取らせれられるわけじゃない。
最悪、会社倒産でお前は損して終わりだろ。
- 197 名前：仕様書無しさん mailto:sage [2012/01/07(土) 18:21:04.60 ]
- だから最後は誰かが必死に仕上げるんだ
俺ら孫受けがな
- 198 名前：仕様書無しさん mailto:sage [2012/01/07(土) 18:21:35.04 ]
- で仕上がるのか？
- 199 名前：仕様書無しさん mailto:sage [2012/01/07(土) 20:10:11.48 ]
- >>195
実際はそのとおり。
だけど、それだとお前が間抜けないよな。
って訳で、1枚邪魔がはいるのよ。
- 200 名前：仕様書無しさん mailto:sage [2012/01/07(土) 23:09:29.11 ]
- >>184
どうした？図星すぎてテンパったか？
- 201 名前：仕様書無しさん mailto:sage [2012/01/07(土) 23:55:59.98 ]
- >>200
お前の人格まで否定しないから、反論してみろよ。
- 202 名前：仕様書無しさん mailto:sage [2012/01/07(土) 23:58:54.79 ]
- 図星と指摘することが反論そのものだろｗ
- 203 名前：仕様書無しさん mailto:sage [2012/01/08(日) 01:44:23.33 ]
- ゆとりは会話もできないのな
- 204 名前：仕様書無しさん mailto:sage [2012/01/08(日) 04:23:40.76 ]
- >>201
やっぱりね。おまえは打たれ慣れてないっつーか、社会に揉まれてないっつーか、そんなところだな。
経験浅いから使ってる言葉に重みがねーんだよ。
後出しジャンケンの意味も履き違えてるみたいだし。
聞きかじった言葉だろ？
すぐに感情的な反応するとこ見ると
あながち間違いじゃなかったみたいだ。認めろよ。
- 205 名前：仕様書無しさん mailto:sage [2012/01/08(日) 04:32:41.63 ]
- もう一つ言うとだな、お前の思ってる言葉の裏に隠されてる真意なんて誰も知らないって。
何だよ真意って。最初から真意言えばいいのでは？
利益優先だとか工程ガーとか、そんなんじゃ仕様書いたことあるかどうかも疑わしいわ。
背伸びしなくていいよ。等身大でいいんだって。
- 206 名前：仕様書無しさん mailto:sage [2012/01/08(日) 05:35:43.65 ]
- ※関係ない人ごめんなさい。
>>204>>205
話の流れをいったん整理する
設計してから要件を定義するという話をしていたから、俺が
「それは設計ではなく、要件を定義するために顧客から要求を引き出す作業であって、
要件が明確化して、機能が確定した段階ではじめて設計が固まる」
という話をしていたわけだ。
そこで、お前が
「合意をとった上で始めて設計が固まる と思ってるなら、まだ青臭いな。
合意はその時点での合意でしかない。」
って頓珍漢な横槍を入れたよな？(本人？)
合意を取ったことに対して"その時点での"設計が固まって、
後で変更を依頼されたら、仕様変更で再設計だよな？
で、俺が返したのは、
「"俺が"初期段階の決定事項が全てだと思っているわけではなく、
設計と要件定義の区別がついていないやつがいるからそういう答えをした。
会社として利益が見込みがあるのであればそういう仕事もする。」
で、お前が
「カチカチの行程のほうが開発会社の利益になる。
臨機応変に対応したら仕事が減る。」
で、俺が
「カチカチのほうが確実な見込みが取れるから安全だけど、
実際には利益が見込まれるならそういう客にも付き合う。」
- 207 名前：仕様書無しさん mailto:sage [2012/01/08(日) 05:36:06.12 ]
- で、お前が
「話を後付けするな。確固たる主張がないなら折れろよ。
言い逃れ野郎。人格否定されてると勘違いするな。素直に認めろよ。」
で、俺が
「>>162で書いたことの意味を正しく認識できていない。
カチカチにするより利益が上がるという意味ではなく、
利益が上がるなら仕事として受けるという意味。」
で、お前が
「どうした？図星すぎてテンパったか？」
で、俺が
「お前の人格まで否定しないから、反論してみろよ。」
で、お前が
「図星と言ったのが反論。」
「経験不足にみえる。言葉に重みがないからわかる。
言葉づかいも間違えている。図星だろ認めろよ。」
「お前の心の中なんか知るか。最初から真意言え。
利益優先だとか工程ガーとか、そんなんじゃ仕様書いたことあるかどうかも疑わしいわ。
背伸びしなくていいよ。等身大でいいんだって。」
ここから、返信 ← new!
「真意って言ったけど、書いてなかったことではなく書いていたこと。
お前が話しの流れを読めていない上に、どんどん話をずらしていった。
そして、図星が反論になっているという意味がいまだにわからない。
冷静に自分のレスとスレの進行を眺めなおしてこい。」
- 208 名前：仕様書無しさん mailto:sage [2012/01/08(日) 05:38:28.50 ]
- そろそろダルいのと、もうだいぶ他の人に迷惑かけてるから、
次で誤解が埋められなかったら終わりにしよう。
- 209 名前：仕様書無しさん mailto:sage [2012/01/08(日) 10:48:23.37 ]
- こうゆうやつらがいたらデスマになりそう
- 210 名前：仕様書無しさん mailto:sage [2012/01/08(日) 12:15:41.06 ]
- 細かい事はいいんだよ見たいな奴は危険。
また、一見細かく見えてどんどん話がずれて行く奴も危険。
- 211 名前：仕様書無しさん mailto:sage [2012/01/08(日) 12:50:18.74 ]
- 話の発端は、要件定義やらずに設計書を要求してくる客がいるというところから始まってる。
おそらく、お互いが最終的なシステムをどういったものにしたいかイメージできないからだと思う。
このような場合、試作を見て要件を出してもらうプロトタイプモデルとかがあるわけで、
その変形版って捉え方でいいんじゃないかな？
- 212 名前：仕様書無しさん mailto:sage [2012/01/08(日) 12:53:45.13 ]
- >>207
あんたまたやらかしてるよ。。認めればいいのに。
頭凝り固まってる。
|
 |
