設計書が開発に役立った事があるか本気で考えてみよ
契約のために必要とかそういうのはどうでもいい。
ユーザーサイドのやりたい事（仕様書） と
それを実現するコードがあれば十分ではないか？
コードではないエクセルなんかの設計書が
役だったことがあるのか？
ないだろう？
いい加減作るだけ無駄だとはっきりさせようか
ユーザーサイドのやりたい事（仕様書） と
それを実現するコードがあれば十分ではないか？
コードではないエクセルなんかの設計書が
役だったことがあるのか？
ないだろう？
いい加減作るだけ無駄だとはっきりさせようか
|
|
|
2 ：仕様書無しさん：2014/03/11(火) 07:23:55.74
え？
設計書なしでどーやって作ってんの？ww
設計書なしでどーやって作ってんの？ww
設計書作るまでがNEC NCSの仕事。
設計書がなかったらNEC NCSは何をすればいいのか。
丸投げだけしろ というのか
設計書がなかったらNEC NCSは何をすればいいのか。
丸投げだけしろ というのか
中小だと設計書、仕様書がないところだらけ
設計書ないと、設計の意図がわからなかったり、仕様と実装の区別がつかなくなる可能性がある。
つまり、本人が生きてる間忘れずにメンテナンスし続けられるのなら不要。
他人が触る可能性があるなら必要。
コードを日本語にしたような設計書は不要。
つまり、本人が生きてる間忘れずにメンテナンスし続けられるのなら不要。
他人が触る可能性があるなら必要。
コードを日本語にしたような設計書は不要。
>>4
やることの規模が小さい上に、客が「ドキュメントには金払わん！」って言う案件を営業が普通にとってきちゃうからだろうな。
ふつうに考えたら、後で自社が割を食う可能性があるから、ドキュメント書く時間も含めて見積もりするべきなんだが。
やることの規模が小さい上に、客が「ドキュメントには金払わん！」って言う案件を営業が普通にとってきちゃうからだろうな。
ふつうに考えたら、後で自社が割を食う可能性があるから、ドキュメント書く時間も含めて見積もりするべきなんだが。
>>6
しかし、それだと他の安いところに発注されてしまうというジレンマ
しかし、それだと他の安いところに発注されてしまうというジレンマ
8 ：仕様書無しさん：2014/03/11(火) 20:08:51.84
そうやってコードだけ残った仕事を受けて、
ソースからプログラム仕様書を書き起こして機能拡張して仕事した。
たぶん今でもそれ流用されてると思う、設計の骨子はそこにしかなかった。
仕様書を全部仕上げる前に会社無くなって、次の人が完全版に仕上げたんだと思うけど。
ソース見れば判るって人やチームを雇えていたら安泰だろうけど、
RTOS制御下で動いてたから状態遷移やらの仕様書が必要、1から調査するパワーのあるチームが引き継いだと考える。
でも今なら、RTOSで動いてるからわかんねーよwで通じるのかｗ
ソースからプログラム仕様書を書き起こして機能拡張して仕事した。
たぶん今でもそれ流用されてると思う、設計の骨子はそこにしかなかった。
仕様書を全部仕上げる前に会社無くなって、次の人が完全版に仕上げたんだと思うけど。
ソース見れば判るって人やチームを雇えていたら安泰だろうけど、
RTOS制御下で動いてたから状態遷移やらの仕様書が必要、1から調査するパワーのあるチームが引き継いだと考える。
でも今なら、RTOSで動いてるからわかんねーよwで通じるのかｗ
9 ：仕様書無しさん：2014/03/11(火) 23:43:45.47
むしろ設計書が無い現場では死ぬ思いをした記憶しか無い。
>>9
死ぬ思いをしたことがあると「必要なドキュメントは絶対に残すべき」事を身を持って学ぶよね…
現場知らない人が契約で無駄なドキュメント作る約束して、無駄だと分かりながら作る誰も読まないドキュメントは要らない
死ぬ思いをしたことがあると「必要なドキュメントは絶対に残すべき」事を身を持って学ぶよね…
現場知らない人が契約で無駄なドキュメント作る約束して、無駄だと分かりながら作る誰も読まないドキュメントは要らない
11 ：仕様書無しさん：2014/03/12(水) 06:18:55.07
バイナリしか残ってないわろちん
前の会社（孫請けやってるような小さい会社）が社内wikiにメモ程度しか書かないところで、改善提案したら「うちは開発スピード重視です」って言われたな
結局後でカオスになって、「急がば回れ」という言葉の重みを知った
結局後でカオスになって、「急がば回れ」という言葉の重みを知った
>>10
まったく同感だ
死ぬまでの思いは経験したことは無いが、もう20年ほど昔、
同じ部署のプロジェクトが大炎上したことがあった
出荷日程の延長も限度があり見切りでリリースせざるをえなかったが、
結果として6年間に渡って障害対応に追われ、最終的にメンバー全員が退職に追い込まれた
当時は今ほど転職情報も無く終身雇用が当たり前の時代、
しかも協力会社とはいえ大手メーカ系企業へ就職して将来は安泰だと思っていたはず
退職したメンバー達は自分と同じ会社の同僚であり、どれだけ悔しかったか
当時、自分は別プロジェクトでサブリーダをしていたが、
自分と自分のメンバー達には同じ思いをさせたくなかったから、
品質確保を最優先に必死に頑張った
もちろん大炎上した大きな要因の一つがドキュメンテーションであったのは言うまでもない
>>12
当時は、自分のところだち「急がば回れ」よりも「先憂後楽」という言葉が使われていたね
まったく同感だ
死ぬまでの思いは経験したことは無いが、もう20年ほど昔、
同じ部署のプロジェクトが大炎上したことがあった
出荷日程の延長も限度があり見切りでリリースせざるをえなかったが、
結果として6年間に渡って障害対応に追われ、最終的にメンバー全員が退職に追い込まれた
当時は今ほど転職情報も無く終身雇用が当たり前の時代、
しかも協力会社とはいえ大手メーカ系企業へ就職して将来は安泰だと思っていたはず
退職したメンバー達は自分と同じ会社の同僚であり、どれだけ悔しかったか
当時、自分は別プロジェクトでサブリーダをしていたが、
自分と自分のメンバー達には同じ思いをさせたくなかったから、
品質確保を最優先に必死に頑張った
もちろん大炎上した大きな要因の一つがドキュメンテーションであったのは言うまでもない
>>12
当時は、自分のところだち「急がば回れ」よりも「先憂後楽」という言葉が使われていたね
「設計書が」とか言ってるうちは駄目だ。
まずは、ちゃんと設計しろ。
開発メンバーでその設計を共有しろ。
コードを書くのはそれからだ。
共有したり、読み返したりするのに設計書が必要なら作ればいい。
まずは、ちゃんと設計しろ。
開発メンバーでその設計を共有しろ。
コードを書くのはそれからだ。
共有したり、読み返したりするのに設計書が必要なら作ればいい。
設計をレビューするのには必要。
>>14
>まずは、ちゃんと設計しろ。
設計が「ちゃんとしているか」をどうやって判断するのか、それが問題の焦点だよ
自分は、設計の成果物が設計書であると考える
そして(>>15が指摘しているように、)設計がちゃんとしているかを判断する場がレビューであり、
そのレビューの対象物が設計書になる
>まずは、ちゃんと設計しろ。
設計が「ちゃんとしているか」をどうやって判断するのか、それが問題の焦点だよ
自分は、設計の成果物が設計書であると考える
そして(>>15が指摘しているように、)設計がちゃんとしているかを判断する場がレビューであり、
そのレビューの対象物が設計書になる
>>16
設計書作りが目的になったらアウトな。
そんなことになってると、>>1みたいな疑問が出てくるんだ。
設計書を残すのは当たり前だが、
設計書のレビューは「設計どおりに記載できているか」を見るものだぞ。
ちゃんと設計できてるかも解らないうちからレビューなんてするから
ろくに設計されていないまま突き進むんだよ。
設計書作りが目的になったらアウトな。
そんなことになってると、>>1みたいな疑問が出てくるんだ。
設計書を残すのは当たり前だが、
設計書のレビューは「設計どおりに記載できているか」を見るものだぞ。
ちゃんと設計できてるかも解らないうちからレビューなんてするから
ろくに設計されていないまま突き進むんだよ。
設計より、仕様を固める方が有意義
仕様がキッカリ決まっていて矛盾が無ければ
むしろ設計なんて蛇足でしかない。
仕様がキッカリ決まっていて矛盾が無ければ
むしろ設計なんて蛇足でしかない。
>>18
仕様定義と設計くらい区別しろよ
仕様定義と設計くらい区別しろよ
日本語ソースコードもどきの設計書なら役には立たないだろうなあ
>>17
レビューしなくても完成された設計ができるほど簡単な仕事で羨ましいな。
レビューしなくても完成された設計ができるほど簡単な仕事で羨ましいな。
話しながら設計だと、なんで暇そうになるんだ？
ただ働き？ なんで？
どうしてそんな馬鹿な発想をしたのか
お前の頭のなかが見てみたいから
説明してください。
ただ働き？ なんで？
どうしてそんな馬鹿な発想をしたのか
お前の頭のなかが見てみたいから
説明してください。
全員拘束して一つの設計しかできない。
もしかして、一人では設計できない無能なのか。
もしかして、一人では設計できない無能なのか。
>>17
>設計書作りが目的になったらアウトな。
言わずもがなで当たり前の前提だよ
>設計書のレビューは「設計どおりに記載できているか」を見るものだぞ。
いや、自分の考えは違うな
記載を見るのではなく、記載を通して「設計がちゃんとしているか(>>14)」を見るものだと考える
記載という仕様表現は「ちゃんとした設計」を記述する為の手段であり、
手段と「設計がちゃんとしていることを確認する」というレビューの目的を取り違えるべきではない
>ちゃんと設計できてるかも解らないうちからレビューなんてするから
>ろくに設計されていないまま突き進むんだよ。
ここもまた、考え方が違うみたいだね
自分のところでは、レビューの結果として設計がちゃんとしていないと判断されたなら、
設計を差し戻して再レビューを実施することになる
で、日程ぎりぎりでの一発レビュー通過なんてのはリスクが高すぎるから、
メンバーには100%の完成品でなくてもいいから、早め早めにレビュー準備完を報告するよう伝えている
>>17のところのような、レビューしさえすれば無条件に次へ進めるような品質管理は、怖すぎて自分には無理だ
>設計書作りが目的になったらアウトな。
言わずもがなで当たり前の前提だよ
>設計書のレビューは「設計どおりに記載できているか」を見るものだぞ。
いや、自分の考えは違うな
記載を見るのではなく、記載を通して「設計がちゃんとしているか(>>14)」を見るものだと考える
記載という仕様表現は「ちゃんとした設計」を記述する為の手段であり、
手段と「設計がちゃんとしていることを確認する」というレビューの目的を取り違えるべきではない
>ちゃんと設計できてるかも解らないうちからレビューなんてするから
>ろくに設計されていないまま突き進むんだよ。
ここもまた、考え方が違うみたいだね
自分のところでは、レビューの結果として設計がちゃんとしていないと判断されたなら、
設計を差し戻して再レビューを実施することになる
で、日程ぎりぎりでの一発レビュー通過なんてのはリスクが高すぎるから、
メンバーには100%の完成品でなくてもいいから、早め早めにレビュー準備完を報告するよう伝えている
>>17のところのような、レビューしさえすれば無条件に次へ進めるような品質管理は、怖すぎて自分には無理だ
いや、>>17のケースは全員で設計するから、設計そのものは最適なはずだという主張だと思うぞ。
>>28
「設計そのものは最適なはず」という前提で進んで、
時には日程通りに終わったり時には大炎上したりするわけか...
冒険的というかギャンブラー的だけど、そんな考え方もあるのかもしれないね
でも自分は気が小さいから、「.....なはず」と確証できるほど自身の技術力に自信がない
だから、一歩一歩、レビューによって設計がちゃんとしているかの確認作業を重ねることで、
品質を積み上げていく方法を選ぶしかないや
「設計そのものは最適なはず」という前提で進んで、
時には日程通りに終わったり時には大炎上したりするわけか...
冒険的というかギャンブラー的だけど、そんな考え方もあるのかもしれないね
でも自分は気が小さいから、「.....なはず」と確証できるほど自身の技術力に自信がない
だから、一歩一歩、レビューによって設計がちゃんとしているかの確認作業を重ねることで、
品質を積み上げていく方法を選ぶしかないや
こういう話する時、ドキュメントの種類が多すぎて話が噛み合ってないこと多いよね。
hoge仕様書とかいっても、それぞれ定義が会社の風土によって違ったり、プロジェクトの規模によっても作る意味のあるドキュメントが変わってくるから。
hoge仕様書とかいっても、それぞれ定義が会社の風土によって違ったり、プロジェクトの規模によっても作る意味のあるドキュメントが変わってくるから。
一度文書システムに登録された設計書は改版に妙な手間がかかる某社某工場への常駐は
長く関わるとよく人がぶっ壊れる為ぶっ壊れても良い程度の奴が割り当てられる。
出来た製品はお察し。
長く関わるとよく人がぶっ壊れる為ぶっ壊れても良い程度の奴が割り当てられる。
出来た製品はお察し。
>>29
お前さんの懸念は、それこそ
各自が設計した物を持ち寄って「レビューした物は大丈夫なはず」
って前提で突き進んで大炎上するパターンだろ。
なんで各自まかせでまともな物に仕上がるとか思えるんだ。
ふつうは、みんなで意識を合わせながら設計を進めるもんだよ。
「レビューだけで何とかなる」なんて思ってるから、
ろくに設計できない とか言われるのにそろそろ気づけ。
つか、なにかバグ出したとき設計した本人以外対応できないとか
言い出すパターンなんじゃないか？
お前さんの懸念は、それこそ
各自が設計した物を持ち寄って「レビューした物は大丈夫なはず」
って前提で突き進んで大炎上するパターンだろ。
なんで各自まかせでまともな物に仕上がるとか思えるんだ。
ふつうは、みんなで意識を合わせながら設計を進めるもんだよ。
「レビューだけで何とかなる」なんて思ってるから、
ろくに設計できない とか言われるのにそろそろ気づけ。
つか、なにかバグ出したとき設計した本人以外対応できないとか
言い出すパターンなんじゃないか？
設計書も適切なメンテがされてないと無いのと同じくらい厄介なんだよな。
Chromiumなどオープン系はこれで困ったことないな
・svn,git blameでコミットした人、コメント、ハッシュキーを確認
・ハッシュキーでコードレビューを検索、どういう経緯でコードが書き込まれたか確認
・レビューに紐付けられたイシュートラッカーで変更の目的を確認
・構成など全体的な作りはwikiに記入、全文検索できる
・svn,git blameでコミットした人、コメント、ハッシュキーを確認
・ハッシュキーでコードレビューを検索、どういう経緯でコードが書き込まれたか確認
・レビューに紐付けられたイシュートラッカーで変更の目的を確認
・構成など全体的な作りはwikiに記入、全文検索できる
コードを書くのは下々の仕事、
設計書は作業指示書なので必須。
というゼネコン思想がまだ強いのでしょうか
設計書は作業指示書なので必須。
というゼネコン思想がまだ強いのでしょうか
うちは下々だけど全部丸投げされてる
箇条書きで要望が書かれてるA4の紙わたされるだけ
設計も全部やってる
箇条書きで要望が書かれてるA4の紙わたされるだけ
設計も全部やってる
だから3回作り直す工数でやればいいんだよ
どうせ設計しても客の要望どうりには作れない
客が要望をわかってないから
どうせ設計しても客の要望どうりには作れない
客が要望をわかってないから
結局のところメンバーの質、企業の質による。
信頼して仕事を任せられるメンバーしかいないなら、対面やチャットでアーキテクチャの認識合わせを行って
コードレビューで修正していくだけで十分まともな成果物に辿り着ける。
ウォーターフォールによくある感じの内容の詳細設計書なんてものは、UTやFTの実装で代替できる。
顧客と認識をあわせるための要件定義、触って確かめるためのモック、
アーキテクチャの認識合わせに使った簡単な資料、自動生成されたドキュメント類で十分な感じになると思うよ。
底辺な場所ほど、無知識メンバーが増えるから、コードと対になるような設計書がないとまともなものが作れなくなる。
信頼して仕事を任せられるメンバーしかいないなら、対面やチャットでアーキテクチャの認識合わせを行って
コードレビューで修正していくだけで十分まともな成果物に辿り着ける。
ウォーターフォールによくある感じの内容の詳細設計書なんてものは、UTやFTの実装で代替できる。
顧客と認識をあわせるための要件定義、触って確かめるためのモック、
アーキテクチャの認識合わせに使った簡単な資料、自動生成されたドキュメント類で十分な感じになると思うよ。
底辺な場所ほど、無知識メンバーが増えるから、コードと対になるような設計書がないとまともなものが作れなくなる。
>>40
それを5年10年続けられるのならそれでいいんだけどな。
情報系の学校を卒業してこの業界に入って10数年やっているけど、入って
驚いたのが、割りとあっさりと書いたコードが本番に流れるのと、思った以上に
長く使われ続けることだな。
当たり前なんだけど、1ライセンス数万でも数十人数百人が使うとなると
数十万、数百万円になるわけで気軽に買い換えれるものじゃないから
長く使われるよな。億単位のシステムならそりゃしがみつくだろうよ。
自衛の意味でも取り残された所に縛り付けられたく無ければドキュメントを
ある程度以上は残しておかないとって考えになれない人はヤバイよ。
それを5年10年続けられるのならそれでいいんだけどな。
情報系の学校を卒業してこの業界に入って10数年やっているけど、入って
驚いたのが、割りとあっさりと書いたコードが本番に流れるのと、思った以上に
長く使われ続けることだな。
当たり前なんだけど、1ライセンス数万でも数十人数百人が使うとなると
数十万、数百万円になるわけで気軽に買い換えれるものじゃないから
長く使われるよな。億単位のシステムならそりゃしがみつくだろうよ。
自衛の意味でも取り残された所に縛り付けられたく無ければドキュメントを
ある程度以上は残しておかないとって考えになれない人はヤバイよ。
ドキュメントがなくて複雑なコードを相手にしているから
ドキュメントがあれば～、ドキュメントさえあれば～っていう
そういう間違った思い込みをしてしまうんだよ。
ドキュメントがあるところなら身を持って知っているはずだけど、
ドキュメントがあっても役に立たない。
作る方は楽だよね。今相手にしているコードのドキュメントを書けばいいだけだから。
コードが変わっても、メンテしなくても動くわけだから必須じゃないんだから
後から読む方は大量にあってそれを読む時間はないし記憶することも不可能。
そして間違っている可能性もある。結局コードを読むことに変わりはない。
問題は複雑なコードを書いてしまう技術力の低さになる。
そういう技術力が低い所はドキュメントの質も低いと見るべき。
結局のところ複雑なものをいかに単純化出来るかにかかってる。
コード見ただけでわからないからドキュメントを書くべきという発想は
複雑さを回避することにはならない。
ドキュメントがあれば～、ドキュメントさえあれば～っていう
そういう間違った思い込みをしてしまうんだよ。
ドキュメントがあるところなら身を持って知っているはずだけど、
ドキュメントがあっても役に立たない。
作る方は楽だよね。今相手にしているコードのドキュメントを書けばいいだけだから。
コードが変わっても、メンテしなくても動くわけだから必須じゃないんだから
後から読む方は大量にあってそれを読む時間はないし記憶することも不可能。
そして間違っている可能性もある。結局コードを読むことに変わりはない。
問題は複雑なコードを書いてしまう技術力の低さになる。
そういう技術力が低い所はドキュメントの質も低いと見るべき。
結局のところ複雑なものをいかに単純化出来るかにかかってる。
コード見ただけでわからないからドキュメントを書くべきという発想は
複雑さを回避することにはならない。
>>41
つってもドキュメントが動いてるわけじゃないし、時間が経つほど結局実装を見ないと確証とれないってなるじゃん。
そういうのが理解されてきたから、実装に紐付いたドキュメントをしこしこ作る流れから、
読みやすいコードを書いて、コードから生成できるドキュメントを作って、みたいな流れになってきてるんだと思うよ。
あと、転職を念頭に入れてるかって違いもありそう。
低水準用のドキュメントがないと縛り付けられるような企業から
抜け出せないって感じなら、そういう考えなのは理解できなくもないけれど、
自分としては、そういう企業に貢献し続けたいって意識が持てないな。
つってもドキュメントが動いてるわけじゃないし、時間が経つほど結局実装を見ないと確証とれないってなるじゃん。
そういうのが理解されてきたから、実装に紐付いたドキュメントをしこしこ作る流れから、
読みやすいコードを書いて、コードから生成できるドキュメントを作って、みたいな流れになってきてるんだと思うよ。
あと、転職を念頭に入れてるかって違いもありそう。
低水準用のドキュメントがないと縛り付けられるような企業から
抜け出せないって感じなら、そういう考えなのは理解できなくもないけれど、
自分としては、そういう企業に貢献し続けたいって意識が持てないな。
「わかりやすコード」の定義には二種類あるんだよ。
その一つがCOBOLという言語の特徴にもなってる。
それは「プログラム言語という言語がわかりにくいから
自然言語（英語）と同じであればわかりやすいはず」という考え
本当にそれがわかりやすいかといえば、今のCOBOLの評判をきけば
わかるでしょう？ （自然言語に近いから）冗長なコードと言われている。
ドキュメントも同じで「プログラム言語がわかりにくいから
日本語で書けばわかりやすいはず」という発想にすぎない。
そういう、能力が低い原因（つまりプログラム言語がわからない）を
補うための手段は、言語障害を解決した（？）かもしれないが
処理を記述する能力不足を解決する事にはならなかった。
英語で優れた小説が書けない。日本人だから。
じゃあ日本語で書けば優れた小説書けるんじゃない？
↑
書けるわけないよね？ つまりそういういこと。
その一つがCOBOLという言語の特徴にもなってる。
それは「プログラム言語という言語がわかりにくいから
自然言語（英語）と同じであればわかりやすいはず」という考え
本当にそれがわかりやすいかといえば、今のCOBOLの評判をきけば
わかるでしょう？ （自然言語に近いから）冗長なコードと言われている。
ドキュメントも同じで「プログラム言語がわかりにくいから
日本語で書けばわかりやすいはず」という発想にすぎない。
そういう、能力が低い原因（つまりプログラム言語がわからない）を
補うための手段は、言語障害を解決した（？）かもしれないが
処理を記述する能力不足を解決する事にはならなかった。
英語で優れた小説が書けない。日本人だから。
じゃあ日本語で書けば優れた小説書けるんじゃない？
↑
書けるわけないよね？ つまりそういういこと。
>>45
すげーなっとくだわ
すげーなっとくだわ
>>43
どういう要求があったか、それによってシステム設計がどういった思想の元にどうなり、プログラム的にどんなインターフェイスで区切られているか。
あとは適切な命名がされているならプログラムのdocがあればほとんどのことはわかる。
そういうレベルの話をしている。
プログラムを日本語に翻訳したアホなドキュメントの話ははなからしてない。
どういう要求があったか、それによってシステム設計がどういった思想の元にどうなり、プログラム的にどんなインターフェイスで区切られているか。
あとは適切な命名がされているならプログラムのdocがあればほとんどのことはわかる。
そういうレベルの話をしている。
プログラムを日本語に翻訳したアホなドキュメントの話ははなからしてない。
これは、自然言語 と 数式
どちらがわかりやすいか？って話にもなる。
これは「知識を持った人」にとっては明らかに数式の方なんだよ。
x=(-b±√(b2-4ac))/2a
たとえば、これを自然言語になおしたら冗長になる。
知識を持ってる人にとってはこれだけで十分であっても
知識を持ってない人にとってはわからない。
わからないコードを目の前にした時、
自然言語に直して理解するか、数式を直接理解できるようになるか。
どちらもわかるかもしれないが、前者では冗長にならざるを得ない。
自然言語に直すというアプローチは失敗して、
今のプログラム言語を見ればわかるように、数式にかなり近くなっている。
どちらがわかりやすいか？って話にもなる。
これは「知識を持った人」にとっては明らかに数式の方なんだよ。
x=(-b±√(b2-4ac))/2a
たとえば、これを自然言語になおしたら冗長になる。
知識を持ってる人にとってはこれだけで十分であっても
知識を持ってない人にとってはわからない。
わからないコードを目の前にした時、
自然言語に直して理解するか、数式を直接理解できるようになるか。
どちらもわかるかもしれないが、前者では冗長にならざるを得ない。
自然言語に直すというアプローチは失敗して、
今のプログラム言語を見ればわかるように、数式にかなり近くなっている。
>>44
＞自分としては、そういう企業に貢献し続けたいって意識が持てないな。
あなたは不労所得が大量にあるのですか？ それともコミュニストですか？
自分のやりたいことをやりたいようにやって、周りから笑顔で受け入れられる
人なんてほんの一握りですよ。不本意であろうがなかろうが生きていくために
受け入れたり抵抗しながらやっているのが人間だと思いますよ。
それに程度が低いと思っている会社で質の高い仕事ができない人が
どこか他の会社に行ったからといって、出来るようになることは無いと
私は思います。 実際そういう人は多いし。
＞自分としては、そういう企業に貢献し続けたいって意識が持てないな。
あなたは不労所得が大量にあるのですか？ それともコミュニストですか？
自分のやりたいことをやりたいようにやって、周りから笑顔で受け入れられる
人なんてほんの一握りですよ。不本意であろうがなかろうが生きていくために
受け入れたり抵抗しながらやっているのが人間だと思いますよ。
それに程度が低いと思っている会社で質の高い仕事ができない人が
どこか他の会社に行ったからといって、出来るようになることは無いと
私は思います。 実際そういう人は多いし。
どうでもいいことで話を膨らませてもしょうがない
結局のところ、設計書は大して役に立たないのは時代が証明してるし
それくらいしか任せられない人間のために仕事を作り出してるに過ぎない
結局のところ、設計書は大して役に立たないのは時代が証明してるし
それくらいしか任せられない人間のために仕事を作り出してるに過ぎない
ドキュメントもコードと同じで単純にして量を少なくしないといけない。
量を少なくするにはどうすればいいか。それは、量を知識に変えること。
たとえば、微積分を教える時に、掛け算の説明までしないでしょう？
知識があることで、説明するべきことを大幅に減らすことが可能。
だからドキュメントには、知識があれば十分であることは省くべきである。
とはいってもなんでも覚えればいいかというと覚えられるわけがない。
そこで覚えるべき知識と覚える必要はないものを明確にする。
覚えるべき知識というのは、汎用性があってどこでも使える知識。
特定の会社でしか使えないような知識は覚えても、会社辞めれば役に立たないし、
中途で採用した人であっても、使うことが出来ない。
ドキュメントの量を減らすために、世の中で一般的に使われている技術や
設計パターンを取り入れて、ドキュメントの中からはその説明は省くべき。
それが出来るのが技術者であり、それをよめるのも技術者。
ドキュメントは技術力を補うために作るものじゃない。
技術力を補うためのものは教科書である。
量を少なくするにはどうすればいいか。それは、量を知識に変えること。
たとえば、微積分を教える時に、掛け算の説明までしないでしょう？
知識があることで、説明するべきことを大幅に減らすことが可能。
だからドキュメントには、知識があれば十分であることは省くべきである。
とはいってもなんでも覚えればいいかというと覚えられるわけがない。
そこで覚えるべき知識と覚える必要はないものを明確にする。
覚えるべき知識というのは、汎用性があってどこでも使える知識。
特定の会社でしか使えないような知識は覚えても、会社辞めれば役に立たないし、
中途で採用した人であっても、使うことが出来ない。
ドキュメントの量を減らすために、世の中で一般的に使われている技術や
設計パターンを取り入れて、ドキュメントの中からはその説明は省くべき。
それが出来るのが技術者であり、それをよめるのも技術者。
ドキュメントは技術力を補うために作るものじゃない。
技術力を補うためのものは教科書である。
自由度が高いプロジェクトなら設計書が無いと無理。
フレームワークとか使いまくって、ある程度誰が書いても同じようなコードになる
プロジェクトなら、設計書無くても何とかなる。
フレームワークとか使いまくって、ある程度誰が書いても同じようなコードになる
プロジェクトなら、設計書無くても何とかなる。
顧客から全関数と変数の説明を書類化してくれと依頼が来た。
今更doxygen用にコメント整形する暇もねえしどうすんよ。
今更doxygen用にコメント整形する暇もねえしどうすんよ。
いずれにせよ、そんな仕事に金だしてくれるいい客じゃないか。
ドキュメントつっても、ファイルで管理してる資料はろくなことないんだよな。
結局管理に失敗するか、無駄な工数吸い取られてく感じだ。
特に、方眼紙が大量にある場合の絶望感はやばい。
印刷レイアウトで見た場合の整形にこだわる老害とかいたりすると、更に酷いことになるｗ
>>49
え、なに？そんなにそこが気になったんなら謝るよ、ごめんね。
結局管理に失敗するか、無駄な工数吸い取られてく感じだ。
特に、方眼紙が大量にある場合の絶望感はやばい。
印刷レイアウトで見た場合の整形にこだわる老害とかいたりすると、更に酷いことになるｗ
>>49
え、なに？そんなにそこが気になったんなら謝るよ、ごめんね。
>>56
開発費として既に受け取り済みで、開発期間の最後に思い出したように言われるんだよ。
開発費として既に受け取り済みで、開発期間の最後に思い出したように言われるんだよ。
>>52
まともなコーダーだけで構成されてて、全員声の届く範囲にいるなら、自由度が高くてもなんとかなるし
フレームワーク使っててもアホが混じるとうんコードが生み出される
自由度っていうか、フレームワークで線をひくのはちょっと乱暴な感じもするな
やっぱり人間っていうか技術者のスキルに左右されると思うわ
>>57
wikiが手っ取り早く準備できて使い勝手いいな
検索も履歴も管理できるし章立てた文書も書きやすい
49は図星だったんだろう
ウォーターフォール開発、オフショア開発みたいなのを続けてる大手だと、そういう感じの人間多い
若いヤツは見切りをつけてベンチャーに流れたりもできるが、歳食うとどうにもできなくなるしな
>>58
よくあるやつだなｗ
契約時に納品物が明確にされてても、言ってくる場合もあるし
そういう時に限って営業がYESしか言わなかったりで…
まともなコーダーだけで構成されてて、全員声の届く範囲にいるなら、自由度が高くてもなんとかなるし
フレームワーク使っててもアホが混じるとうんコードが生み出される
自由度っていうか、フレームワークで線をひくのはちょっと乱暴な感じもするな
やっぱり人間っていうか技術者のスキルに左右されると思うわ
>>57
wikiが手っ取り早く準備できて使い勝手いいな
検索も履歴も管理できるし章立てた文書も書きやすい
49は図星だったんだろう
ウォーターフォール開発、オフショア開発みたいなのを続けてる大手だと、そういう感じの人間多い
若いヤツは見切りをつけてベンチャーに流れたりもできるが、歳食うとどうにもできなくなるしな
>>58
よくあるやつだなｗ
契約時に納品物が明確にされてても、言ってくる場合もあるし
そういう時に限って営業がYESしか言わなかったりで…
>>59
wikiは図が描きにくいからなー
wikiは図が描きにくいからなー
61 ：仕様書無しさん：2014/03/15(土) 15:26:44.39
＞49は図星だったんだろう
2chでこういう勝利宣言みたいなのいらないから
2chでこういう勝利宣言みたいなのいらないから
62 ：仕様書無しさん：2014/03/15(土) 15:31:47.90
要件定義や設計思想、インフラの資料は必要だけど、実装の資料はコードに勝るものなし。
読めないコードしか書けない奴に設計書なんて書かせても、読めないものしか書けない。
作った成果物の説明資料や、メンバーとの認識合わせに使った資料は、開発に役立つと思う。
けど、スレタイにある「設計書」っていう括りだと、作業指示を行うためのドキュメントか、
これから実装するコードを自然言語化した資料みたいなイメージ。
大抵そういうのは、コードを読めない人が設計をレビューするために、
Excel方眼紙なんかに自然言語で実装してるだけにすぎない。
このような設計書は殆ど開発には役に立たないと思う。
むしろ、保守がメインになる段階では、負の遺産になってる事のほうが多い。
読めないコードしか書けない奴に設計書なんて書かせても、読めないものしか書けない。
作った成果物の説明資料や、メンバーとの認識合わせに使った資料は、開発に役立つと思う。
けど、スレタイにある「設計書」っていう括りだと、作業指示を行うためのドキュメントか、
これから実装するコードを自然言語化した資料みたいなイメージ。
大抵そういうのは、コードを読めない人が設計をレビューするために、
Excel方眼紙なんかに自然言語で実装してるだけにすぎない。
このような設計書は殆ど開発には役に立たないと思う。
むしろ、保守がメインになる段階では、負の遺産になってる事のほうが多い。
63 ：仕様書無しさん：2014/03/15(土) 16:14:35.85
>>60
全部を1つで賄う必要はないから、図は別のツールで作ればいいんじゃないかなー。
最近のWebシステムなら画像ファイルとかだってDnDでアップロードできるし、添付もそこまで面倒だとは思わない。
あとで修正するように元データもつけておけば、保守もしやすいしそっちのバージョン管理にもできる。
ER図にしても、クラス図にしても、ポンチ絵にしても、適したツールで編集するのが一番楽できると思う。
あと、Wikiでできないようなとてもステキな資料は、おそらく開発には役立つことがない。
全部を1つで賄う必要はないから、図は別のツールで作ればいいんじゃないかなー。
最近のWebシステムなら画像ファイルとかだってDnDでアップロードできるし、添付もそこまで面倒だとは思わない。
あとで修正するように元データもつけておけば、保守もしやすいしそっちのバージョン管理にもできる。
ER図にしても、クラス図にしても、ポンチ絵にしても、適したツールで編集するのが一番楽できると思う。
あと、Wikiでできないようなとてもステキな資料は、おそらく開発には役立つことがない。
>>62
ひねくれてるなー
設計書っていうからには、設計思想が記述されているのが普通。
> 作業指示を行うためのドキュメント
作業指示書
> これから実装するコードを自然言語化した資料
このレベルになると、普通はコードから自動生成するわな。
ひねくれてるなー
設計書っていうからには、設計思想が記述されているのが普通。
> 作業指示を行うためのドキュメント
作業指示書
> これから実装するコードを自然言語化した資料
このレベルになると、普通はコードから自動生成するわな。
> あと、Wikiでできないようなとてもステキな資料は、おそらく開発には役立つことがない。
UML万能だとは思わないが、シーケンス図・状態遷移図は大体どんな開発でも使うなぁ。
あと、ハードが絡めばタイミングチャートも。
UML万能だとは思わないが、シーケンス図・状態遷移図は大体どんな開発でも使うなぁ。
あと、ハードが絡めばタイミングチャートも。
>>64-65
UMLツールで作ってWikiに貼ればいいって話じゃ
UMLツールじゃ要件定義書や基本設計書みたいなのは書けないし
道具は使い分けてナンボ
つーても俺はUMLは事後で実装の説明をする必要がある場合くらいしか使わないので
設計ツールとしてUMLを使ったりはしないが
あと「普通」って言い切って突っかかるのは井戸の蛙すぎじゃね
なんたら設計書の認識ズレなんて何年も前からこの板に限らず話題に上がってることだし
そもそも設計思想なんて微塵も書いてない糞の役にも立たない「設計書」なんてごまんとある
情報が存在するかもしれない僅かな可能性にかけてクソ資料を漁ったり
コードの行間から実装者の考えを想像するような、国語の授業みたいな作業をしてる時間が多いと
「そういうのがまとめられてたら、ボクももう少しだけ幸せになれたのかな・・・」って気分になるわ・・・
UMLツールで作ってWikiに貼ればいいって話じゃ
UMLツールじゃ要件定義書や基本設計書みたいなのは書けないし
道具は使い分けてナンボ
つーても俺はUMLは事後で実装の説明をする必要がある場合くらいしか使わないので
設計ツールとしてUMLを使ったりはしないが
あと「普通」って言い切って突っかかるのは井戸の蛙すぎじゃね
なんたら設計書の認識ズレなんて何年も前からこの板に限らず話題に上がってることだし
そもそも設計思想なんて微塵も書いてない糞の役にも立たない「設計書」なんてごまんとある
情報が存在するかもしれない僅かな可能性にかけてクソ資料を漁ったり
コードの行間から実装者の考えを想像するような、国語の授業みたいな作業をしてる時間が多いと
「そういうのがまとめられてたら、ボクももう少しだけ幸せになれたのかな・・・」って気分になるわ・・・
Wikiは設計メモ集として有益なツールだと思う
プロジェクトが進行する中では様々な検討課題や問題点が生まれる
そういった雑多で不定形であるけれど重要な情報を記録する手段としてWikiは最適
もちろんクラス図や遷移図/表などは別のツールで作成してWikiへ添付すればいい
ただしWikiはあくまでも設計のメモ(断片)であって、Wikiそのものは設計書ではないと考える
Wikiに記録されたメモを最終的に保守に役立つよう筋道をたてて整理し、
最終的に設計書という成果物としてまとめることが望ましい
プロジェクトが進行する中では様々な検討課題や問題点が生まれる
そういった雑多で不定形であるけれど重要な情報を記録する手段としてWikiは最適
もちろんクラス図や遷移図/表などは別のツールで作成してWikiへ添付すればいい
ただしWikiはあくまでも設計のメモ(断片)であって、Wikiそのものは設計書ではないと考える
Wikiに記録されたメモを最終的に保守に役立つよう筋道をたてて整理し、
最終的に設計書という成果物としてまとめることが望ましい
メインはコードであって
設計書はそれを補佐するもの。
つまり断片にしかならん。
説明不要な小さなコードに設計書は不要。
大きくなったら？ 必要な物だけを作ればいいだろう？
設計書はそれを補佐するもの。
つまり断片にしかならん。
説明不要な小さなコードに設計書は不要。
大きくなったら？ 必要な物だけを作ればいいだろう？
何かを修正するとき、設計書は見なくても、コードは見ないことはない。
だからドキュメントはコードの近くにあると良い。
そしてコードと同じことをドキュメントと二重管理するのは無駄。
と考えればドキュメントはソースコードそのものか
それを格納しているディレクトリに書くのが良い
ソースコードではない所に、ソースコードの説明を書いたって
意味不明なドキュメントになるだろう？
なぜなら「完全なドキュメント － ソースコードの部分」が
書くべき無駄のないドキュメントなのだから
だからドキュメントはコードの近くにあると良い。
そしてコードと同じことをドキュメントと二重管理するのは無駄。
と考えればドキュメントはソースコードそのものか
それを格納しているディレクトリに書くのが良い
ソースコードではない所に、ソースコードの説明を書いたって
意味不明なドキュメントになるだろう？
なぜなら「完全なドキュメント － ソースコードの部分」が
書くべき無駄のないドキュメントなのだから
>>70
一行目から間違えてるな。
ソースコードだけ見てるのは、そもそもケアレスミスとか馬鹿みたいな修正だけだろ？
設計に関わるような修正する時は、コードなんて見ない。
設計書を使ってイメージを合わせて、修正を検討してコミットする。
ソースコードなんて見るのは最終的に書き直すときからだよ。
ソースコードだけ見てても、木を見て森が見えないだろ？
・・・・つか、たとえばセキュリティ評価とかソースコードじゃそもそもできないだろうに
いったいどんな品質評価してんだ？
一行目から間違えてるな。
ソースコードだけ見てるのは、そもそもケアレスミスとか馬鹿みたいな修正だけだろ？
設計に関わるような修正する時は、コードなんて見ない。
設計書を使ってイメージを合わせて、修正を検討してコミットする。
ソースコードなんて見るのは最終的に書き直すときからだよ。
ソースコードだけ見てても、木を見て森が見えないだろ？
・・・・つか、たとえばセキュリティ評価とかソースコードじゃそもそもできないだろうに
いったいどんな品質評価してんだ？
>>71
いいから動くコードを書いてください。
いいから動くコードを書いてください。
ドキュメントの品質を上げても
動くコードの品質は上がりません。
動くコードの品質は上がりません。
>>74
あれ？書くスレ間違えてるぞ
それ書くなら↓だろ。
プロのプログラマなら言ってはいけないセリフ
http://kohada.2ch.net/test/read.cgi/prog/1381223399/
あれ？書くスレ間違えてるぞ
それ書くなら↓だろ。
プロのプログラマなら言ってはいけないセリフ
http://kohada.2ch.net/test/read.cgi/prog/1381223399/
>>75
お前が書いたら？ｗ
お前が書いたら？ｗ
77 ：仕様書無しさん：2014/03/16(日) 01:43:45.20
>>78
おいおい、お前を馬鹿にしていたのは俺だぜ
おいおい、お前を馬鹿にしていたのは俺だぜ
あ、やっぱり馬鹿にしていたことに気づいていなかったみたいだなｗ
だね、馬鹿にされていることにまったく気付いていないw
馬鹿ばっか
馬鹿が馬鹿を馬鹿にしているのを見ると
本当に馬鹿馬鹿しく感じるものだな
本当に馬鹿馬鹿しく感じるものだな
まさに、馬鹿っていうほうが馬鹿なんだの
格言（笑）通りだね。
格言（笑）通りだね。
85 ：仕様書無しさん：2014/03/16(日) 13:19:44.42
Deoxyge
Doyxgne
>>71
こいつ、これ単体でみると妥当な発言に見えるんだけど、序盤に言ってた事が馬鹿なんだよな。
それが、こんな過疎板で名前付けちゃってる痛さと同時に記憶されてて、名前見るだけで読む気しないほどキモい。
まぁ、一応読んだけど。
くだらない馬鹿にしあいはやめなよ。
それと、あいかわらずお互い話してるドキュメントのレベルがずれてて会話噛み合ってないと思うんだけど。
こいつ、これ単体でみると妥当な発言に見えるんだけど、序盤に言ってた事が馬鹿なんだよな。
それが、こんな過疎板で名前付けちゃってる痛さと同時に記憶されてて、名前見るだけで読む気しないほどキモい。
まぁ、一応読んだけど。
くだらない馬鹿にしあいはやめなよ。
それと、あいかわらずお互い話してるドキュメントのレベルがずれてて会話噛み合ってないと思うんだけど。
必要も何も、納品物にリストアップされてんだから作るしか無いだろって
つまりそれは開発に役に立たないという意味でいいのか？
>>90
いいんではないのかな
・コードを日本語にしたような設計書は不要。(>>5)
という認識は、このスレ住人なら誰でも同意するのではないかと
ただし、残念ながら
・納品物にリストアップされてんだから作るしか無い (>>89)
のが現状で、役に立たない設計書を「作らされている」と感じている
いいんではないのかな
・コードを日本語にしたような設計書は不要。(>>5)
という認識は、このスレ住人なら誰でも同意するのではないかと
ただし、残念ながら
・納品物にリストアップされてんだから作るしか無い (>>89)
のが現状で、役に立たない設計書を「作らされている」と感じている
作れって指示あるから実装完了後にやっつけで書きました
みたいなケースが多いんじゃね
みたいなケースが多いんじゃね
つうか、納品用に作る設計書って、あれは実際はソフトウェア実装説明書だからなぁ
本来の意味の設計書って、作成前に作る青写真であって出来上がりと食い違うのは当たり前なんだよなぁ。
それを出来上がりに合わせて修正する事自体無駄な話だよなぁ
それがえらい人にはわからないのが一番の問題。
本来の意味の設計書って、作成前に作る青写真であって出来上がりと食い違うのは当たり前なんだよなぁ。
それを出来上がりに合わせて修正する事自体無駄な話だよなぁ
それがえらい人にはわからないのが一番の問題。
ソースにコメント書いてもらった方がよっぽどありがたい
もちろん設計とまでは言わないが処理概要くらいはいる
もちろん設計とまでは言わないが処理概要くらいはいる
設計書と同じものを、ソースコードに書いて
納品しても、意味は全く一緒だよな？
納品しても、意味は全く一緒だよな？
大の男がチマチマとポチポチキーボード叩いて
そのうえ、あーでもないこーでもないと細かい話をして
あーくだらないくだらない
さっさといらないドキュメントと、いらないドキュメントを要求する客を抹殺しろお前ら
そのうえ、あーでもないこーでもないと細かい話をして
あーくだらないくだらない
さっさといらないドキュメントと、いらないドキュメントを要求する客を抹殺しろお前ら
>>94
何百ファイルとあるソースファイルから目的の部分を見つけるのが簡単だとでも？
趣味や仕事でも小規模なので、自分で作り始めたのならそれでも回せるんだろうけど、
普通の仕事だとそうじゃないってことが理解出来てない人が多いいんだよな。
何百ファイルとあるソースファイルから目的の部分を見つけるのが簡単だとでも？
趣味や仕事でも小規模なので、自分で作り始めたのならそれでも回せるんだろうけど、
普通の仕事だとそうじゃないってことが理解出来てない人が多いいんだよな。
まともな設計やったことがないから「設計書」ときいても
何を書く物なのかすら想像できないんだろう。
何を書く物なのかすら想像できないんだろう。
>>101は逃げたようなので、まともに仕様すら出てこないよ。。
>>103
いいからあっち行ってくれ
いいからあっち行ってくれ
教えてもらう立場の>>101があまりにも馬鹿でわろたwwww
あっちでもこっちでも、わかりやすい自演だな
仕様書書けるまで帰ってくんなよ
仕様書書けるまで帰ってくんなよ
必死だなww
ユーザだって処理詳細は把握しておきたいわけで、
でもユーザはソースコードが読めないだろ。
その為にも設計書は必要なんだよ。
今１０年以上前のシステムをリプレースしているが、
設計書無いし、ユーザは誰も詳細が把握できないから、
早い段階から火吹いてる。
今、急遽客先常住で入れられて>1みたいな奴が作った
ソースコードを解析して設計書におこしているよ。
仕事内容としては楽でいいけどね。
でもユーザはソースコードが読めないだろ。
その為にも設計書は必要なんだよ。
今１０年以上前のシステムをリプレースしているが、
設計書無いし、ユーザは誰も詳細が把握できないから、
早い段階から火吹いてる。
今、急遽客先常住で入れられて>1みたいな奴が作った
ソースコードを解析して設計書におこしているよ。
仕事内容としては楽でいいけどね。
あまり細かく書いてはいかん
設計書よりテスト確認書の方が無駄だわ
あんなん自動化できるだろ
あんなん自動化できるだろ
コボラーの皆さん。
あなた達の世界の設計書というものは
どういうものなのか、こちらで書いてくれませんか？
KACがテキストエディタの設計書を書くスレ
http://kohada.2ch.net/test/read.cgi/prog/1394963270/
あなた達の世界の設計書というものは
どういうものなのか、こちらで書いてくれませんか？
KACがテキストエディタの設計書を書くスレ
http://kohada.2ch.net/test/read.cgi/prog/1394963270/
>>111
内容による。シミュレータ作ってる時間が無いこともあるし。
内容による。シミュレータ作ってる時間が無いこともあるし。
設計書のうちのどれを指してるのか分からないが、いくつかは絶対必要だし、いくつかは不要。
客に見せなくても、必要なものは必要。
先日元請けが適当なもの寄越して死にかけた。というか死んだ。
客に見せなくても、必要なものは必要。
先日元請けが適当なもの寄越して死にかけた。というか死んだ。
116 ：仕様書無しさん：2014/03/17(月) 21:54:09.96
設計書がいらないと言ってる奴は、設計書を必要とする立場に立ったことが無いんだろうなー
ちなみに、設計書を書く奴にとって、設計書が役に立たないのは当たり前。
「俺が設計理解してるんだから、設計書なんていらないだろ」って言ってるSEと同じ。
ちなみに、設計書を書く奴にとって、設計書が役に立たないのは当たり前。
「俺が設計理解してるんだから、設計書なんていらないだろ」って言ってるSEと同じ。
何十万行というソースコードと、仕様書だけ渡されて
「ここの仕様をこう変えるからよろしく」と言われたときは地獄だったなー
モジュール構造とかイベントの伝播経路とか解析しつつ作業進めていったんだけど、
後になって設計思想と違う修正してたところが判明する度に、そのまま進めるか
再修正するかで揉めてたわ。
「ここの仕様をこう変えるからよろしく」と言われたときは地獄だったなー
モジュール構造とかイベントの伝播経路とか解析しつつ作業進めていったんだけど、
後になって設計思想と違う修正してたところが判明する度に、そのまま進めるか
再修正するかで揉めてたわ。
そういや、怪しい中国語サイトから元になった製品のプレゼン資料とかを
ダウンロードしてなんとか解析を進めてたな。
ダウンロードしてなんとか解析を進めてたな。
モジュール構造とかイベントの伝播経路とかって
詳細設計じゃないの？
そんあのSEがやる仕事じゃないと思うけど？
詳細設計じゃないの？
そんあのSEがやる仕事じゃないと思うけど？
詳細から追っていかないとどうしようもない。
モジュールも書いていない設計って何なんだ？
え？ SEはコード書かないでしょ？
設計する前にコード書いたらダメなんだよ。
設計する前にコード書いたらダメなんだよ。
はははこやつめ
>>123
ずっと昔にそういう従来のやり方だと小さい規模でも複雑さがでかくなりすぎて
どうしようも無くなってるんだけどね。 そういう部分を解消できないから日本の
IT業界、特にSIerとか言われるところの利益率が低いままに何十年と続いている。
ずっと昔にそういう従来のやり方だと小さい規模でも複雑さがでかくなりすぎて
どうしようも無くなってるんだけどね。 そういう部分を解消できないから日本の
IT業界、特にSIerとか言われるところの利益率が低いままに何十年と続いている。
126 ：仕様書無しさん：2014/03/18(火) 03:14:25.84
>>123
何で？
何で？
127 ：仕様書無しさん：2014/03/18(火) 04:59:16.80
>>117
役に立たない設計書とやらを紹介してくれ
役に立たない設計書とやらを紹介してくれ
お堅い客相手だと、300行のコードに1000ページの仕様書とか必要になったりする。こういう設計書は明らかに過剰。
ただ3000行のコードに10数ページ程度の仕様書はほしい。
各ソースファイルの概要や構成、全体の動き、要求事項がわかる程度の。
ただ3000行のコードに10数ページ程度の仕様書はほしい。
各ソースファイルの概要や構成、全体の動き、要求事項がわかる程度の。
>>128
それは設計書が役に立たないんじゃなくて、
まともに設計書が作れていないだけだろ。残念ながら。
>>117
このスレ見てると、設計できない(というか理解していない)奴が居るのに愕然とするよ。
仕様と設計と実装の区別くらい流石につけろ。
それは設計書が役に立たないんじゃなくて、
まともに設計書が作れていないだけだろ。残念ながら。
>>117
このスレ見てると、設計できない(というか理解していない)奴が居るのに愕然とするよ。
仕様と設計と実装の区別くらい流石につけろ。
とりあえず、要求仕様書とか要件定義書とか設計書がどんなものか知りたければ、
software requirements specifiction tempalte
software design template
とかでググってみるといいんじゃないかな。
software requirements specifiction tempalte
software design template
とかでググってみるといいんじゃないかな。
ググっても間違ったものがヒットするから、
わかっている人がググって、
そのリンクを書いてくれよ。
わかっている人がググって、
そのリンクを書いてくれよ。
133 ：仕様書無しさん：2014/03/19(水) 01:00:11.63
設計書が古くてコードとの整合性が保たれてないから当てにならない。
元請けが要求する設計書がゴミなだけで役に立つ設計書もあるはずだよ
俺は見たことないけど
俺は見たことないけど
設計書ってどう実装するかしか書かれてないからな
実装の意図とか目的を知りたければソースのコメント見るしかない
実装の意図とか目的を知りたければソースのコメント見るしかない
実装に関してはソースコード見るのが一番。
設計の意図とか目的を知りたければ設計書を見るしかないしな。
設計の意図とか目的を知りたければ設計書を見るしかないしな。
設計の意図ってさ、ソースコードの量に比べて
かなり少なくなるはずなんだけど？
設計がコピペじゃない限り、つまりあの画面とこの画面、
画面ごとに同じような設計を書く必要はなく、
設計の意図だけ書けば、ソースコードの量の100分1ぐらいにならないか？
かなり少なくなるはずなんだけど？
設計がコピペじゃない限り、つまりあの画面とこの画面、
画面ごとに同じような設計を書く必要はなく、
設計の意図だけ書けば、ソースコードの量の100分1ぐらいにならないか？
馬鹿じゃねーの
>>137
仕様書の話？
仕様書の話？
いや、設計の話。
設計に何を書いて何を書かないかをはっきりさせれば
コード以外で書かないといけない部分は
ごくわずかになるのはわかると思う。
書く書かないで考えるからわからない。
意味があるかどうか、実際に役に立ったかで考えてみよう。
設計に何を書いて何を書かないかをはっきりさせれば
コード以外で書かないといけない部分は
ごくわずかになるのはわかると思う。
書く書かないで考えるからわからない。
意味があるかどうか、実際に役に立ったかで考えてみよう。
画面ごとに設計を書くなんて聞いたこと無いけど。
画面ごとに仕様を書くなら聞いたことある。
画面ごとに仕様を書くなら聞いたことある。
画面仕様を設計した結果の仕様書？
禅問答ばかりのくだらんスレだな
仕様書まで自社で作成して、コーディングを外注するとき設計書がいる
裁判沙汰になったときも設計書が必要
裁判沙汰になったときも設計書が必要
>>143
答えは「役に立つ設計書もあるし、役に立たない設計書もある」でしかないからな。
答えは「役に立つ設計書もあるし、役に立たない設計書もある」でしかないからな。
役に立つ設計書って、ソースコードの100分の1程度の量になるよね。
何でもかんでもあったって意味ないし。
何でもかんでもあったって意味ないし。
文芸的プログラミングをどうぞ
一事が万事、役に立たないとか言ってやらない理由を探すの奴は使えない奴が
多いよな。 お前は未来のことを知ってるエスパーか何かのかと。
どんなことでも役に立てようと心がけがで、出来ないのかと思うよ。
禍福は糾える縄の如し、人間万事塞翁が馬とかいう諺が昔からあるくらい、
将来のことなんか分からんのに、知ってるふりしながら先に備えないのは
ただの馬鹿のやることだよ。
多いよな。 お前は未来のことを知ってるエスパーか何かのかと。
どんなことでも役に立てようと心がけがで、出来ないのかと思うよ。
禍福は糾える縄の如し、人間万事塞翁が馬とかいう諺が昔からあるくらい、
将来のことなんか分からんのに、知ってるふりしながら先に備えないのは
ただの馬鹿のやることだよ。
ノイズばかりと切り捨てるのがバカがやる仕事だな。2chなんて十中八九ノイズな
スレばかりなんだから、その中からどう役に立てるかッて言うことが分からんの
だろうな。 まあ、2chに限らずインターネット、リアル共にノイズが溢れてるけどね。
今どき言われているビッグデータなんてのはノイズが大量にあるデータで、
役に立つかどうかもよく分からないのを役に立てようっていう試みなんだけどな。
スレばかりなんだから、その中からどう役に立てるかッて言うことが分からんの
だろうな。 まあ、2chに限らずインターネット、リアル共にノイズが溢れてるけどね。
今どき言われているビッグデータなんてのはノイズが大量にあるデータで、
役に立つかどうかもよく分からないのを役に立てようっていう試みなんだけどな。
>>150
何が言いたいの？
何が言いたいの？
>>145
伊武雅刀様の声で再生された
伊武雅刀様の声で再生された
一々他人を批判しないとモノを言えんのか
はい、そうです。
>>131
最近RDRAっての知ったが、あのシステムの地図を作るという思想は有用だと思う。
最近RDRAっての知ったが、あのシステムの地図を作るという思想は有用だと思う。
設計書っていうのは意図を伝えるものであって
自分の欲しいものを自分で作る人には関係ない話だよ
自分の欲しいものを他人に作らせるにはどうしても必要
自分の欲しいものを自分で作る人には関係ない話だよ
自分の欲しいものを他人に作らせるにはどうしても必要
>>157
それは違う。
自分で作るときに、その作り方を間違えないように計画を立てるのが設計。
自分で作るときの計画を単に他人に見せるだけ。
自分が使う計画として何が必要か？を考えれば設計に何が必要で
何が必要ないかがわかってくる。計画書に必要ないものは設計に書く必要はない。
今の設計書の多くは無駄なことばかりなんだよ。
どうせ全部の作成手順なんかかけやしないのに中途半端に書いてある。
中途半端に書くからバグや漏れもある。それを放置するから
設計書と実装が違うということになって混乱を招く。それなら書かない方がいい。
設計書には全体の計画だけを書いておいて、あとはコードレビューをすればいい。
どうせコードレビューは誰かがするもの。コードレビューが必要ないほどの設計書なんてかけやしない。
特に開発の初期に考えた設計書なんて、実際のコードに当てはまるわけがない。
それは違う。
自分で作るときに、その作り方を間違えないように計画を立てるのが設計。
自分で作るときの計画を単に他人に見せるだけ。
自分が使う計画として何が必要か？を考えれば設計に何が必要で
何が必要ないかがわかってくる。計画書に必要ないものは設計に書く必要はない。
今の設計書の多くは無駄なことばかりなんだよ。
どうせ全部の作成手順なんかかけやしないのに中途半端に書いてある。
中途半端に書くからバグや漏れもある。それを放置するから
設計書と実装が違うということになって混乱を招く。それなら書かない方がいい。
設計書には全体の計画だけを書いておいて、あとはコードレビューをすればいい。
どうせコードレビューは誰かがするもの。コードレビューが必要ないほどの設計書なんてかけやしない。
特に開発の初期に考えた設計書なんて、実際のコードに当てはまるわけがない。
どこにつっこめばいいか迷うレベル
新人なんだろ。
指導してやれよ
指導してやれよ
設計書と実装がちぐはぐになっている→書かなければいいじゃん(ｷﾘｯ)
という極論思考な時点でどうかと思う
「アホなの？」で片付けてしまいたい
という極論思考な時点でどうかと思う
「アホなの？」で片付けてしまいたい
言い返せないのなら
レスしなくていいと思うよｗ
レスしなくていいと思うよｗ
馬鹿にされまくってることにも気付かないのか。可哀想に。
馬鹿にするのではなくて、
言い返せということ。
言い返せないから代わりに馬鹿にするってのは
お前のかーちゃんでーべーそって
言ってるのと同じ。
言い返せということ。
言い返せないから代わりに馬鹿にするってのは
お前のかーちゃんでーべーそって
言ってるのと同じ。
166 ：仕様書無しさん：2014/04/10(木) 02:01:52.80
ほんと可哀想な頭なんだな
だから言い返せないのなら
レスしなくていいってｗ
何が目的でレスしてるのさ？
レスしなくていいってｗ
何が目的でレスしてるのさ？
いや、みんなツッコミどころ多すぎて呆れてるだけだから…
今度時間ある時に気が向いたら突っ込むけど、その前に一度自分のレスが噛み合ってるか見直してごらん…
今度時間ある時に気が向いたら突っ込むけど、その前に一度自分のレスが噛み合ってるか見直してごらん…
目的は、ばーかーばーかって言うためなんだろうな。
ほんとレスの価値がない。
ほんとレスの価値がない。
相当おかしいこと言ってることに全く気付きもしないような馬鹿に何言っても
自分の非を認めるわけないんだから時間の無駄ですわ
論拠が妄想って時点で相手にする価値も無いし
自分の非を認めるわけないんだから時間の無駄ですわ
論拠が妄想って時点で相手にする価値も無いし
発狂してるアホガキ晒しage
だから、そんなレスすることが目的なのか？
反論できてないってことしかわからんのだが。
反論できてないってことしかわからんのだが。
結局、なにかムカついて言い返したいんだけど、
それをやる力がないから、
ばーかばーかというようなお前はガキか
みたいな発言しかできんのよ。
それをやる力がないから、
ばーかばーかというようなお前はガキか
みたいな発言しかできんのよ。
お前の目的も謎。
俺の目的は、レスする内容がないのなら
黙っていたほうが、馬鹿に見られなくてすみますよって話。
内容がないただの悪口は、俺には
「ばーか、ばーか」って書いているようにしか見えないから。
黙っていたほうが、馬鹿に見られなくてすみますよって話。
内容がないただの悪口は、俺には
「ばーか、ばーか」って書いているようにしか見えないから。
長々と馬鹿晒してるお前が言うと説得力ないわ。
俺にレスするからだろｗ
俺は、これだけしか言ってない。
言い返せないのなら
レスしなくていいと思うよｗ
俺は、これだけしか言ってない。
言い返せないのなら
レスしなくていいと思うよｗ
キミまだいたの
181 ：仕様書無しさん：2014/04/10(木) 13:08:56.07
今はタッチパネルが主流だが、昔は専用ボタン等を配置する操作盤を
設計し専門業者に発注してた。 同じように、タッチパネルでもボタンの
配置と機能をあらかじめデザイン（＝設計）する作業は必要だろ？
それに始まり、目に見える内容（グラフ、表、印刷帳票）は全て
あらかじめデザインを決め、顧客に提示する必要があるだろ？
さらに、操作仕様の詳細も決める必要がある。 最低でも、これらの
設計を行い、設計書にまとめないと、とても技術者とは云えない。
小規模なスマホアプリのようなものなら、これで組み始めても良いが
大規模なソフトだと、サブシステム間の連携仕様（インターフェース）を
設計しないとダメだわ。
モジュール設計も必要だ。 モジュール内のルーチン設計などは
現代では不要かも知れんな。 上級ＰＧなら、モジュール間の連携を
設計できる技量が必要だな。
あとな、設計作業には実現可能性を細かく探る意味もある。
組み始めてから、それは出来ないでは、手戻り作業が大きすぎて
プロジェクトが破綻する。
設計し専門業者に発注してた。 同じように、タッチパネルでもボタンの
配置と機能をあらかじめデザイン（＝設計）する作業は必要だろ？
それに始まり、目に見える内容（グラフ、表、印刷帳票）は全て
あらかじめデザインを決め、顧客に提示する必要があるだろ？
さらに、操作仕様の詳細も決める必要がある。 最低でも、これらの
設計を行い、設計書にまとめないと、とても技術者とは云えない。
小規模なスマホアプリのようなものなら、これで組み始めても良いが
大規模なソフトだと、サブシステム間の連携仕様（インターフェース）を
設計しないとダメだわ。
モジュール設計も必要だ。 モジュール内のルーチン設計などは
現代では不要かも知れんな。 上級ＰＧなら、モジュール間の連携を
設計できる技量が必要だな。
あとな、設計作業には実現可能性を細かく探る意味もある。
組み始めてから、それは出来ないでは、手戻り作業が大きすぎて
プロジェクトが破綻する。
デザイン業界に居たけど、マが用意した設計書よりもデザイナーの絵のほうが役に立ってた
センスの無い文書は何であろうが罪
センスの無い文書は何であろうが罪
デザイナーが絵でどうやって、モジュール間の連携とかの
設計書を書くっていうの？
いや、設計書がなにかわかってないでしょ？
完成図（絵）は設計というよりも仕様だよ。
設計書を書くっていうの？
いや、設計書がなにかわかってないでしょ？
完成図（絵）は設計というよりも仕様だよ。
>>183
デザイナーが設計書を書いたとは言ってない
デザイナーが設計書を書いたとは言ってない
プログラマが書いた設計書をデザイナー(?)が見て何をしたいのかよくわからん。
普通の人がクラス構成とか、シーケンス図とか見てなにをするつもりなのか。
普通の人がクラス構成とか、シーケンス図とか見てなにをするつもりなのか。
>>184
よくわからんけど、たとえば
車を選ぶとき、車のデザインカタログの方が役に立っていた。
エンジンやギアなど、車を作るのに必要な機械的な情報は
役に立たなかったという話？
いやそれは馬鹿な意見だろうｗ
俺らは車を作る側の人間なわけで。
よくわからんけど、たとえば
車を選ぶとき、車のデザインカタログの方が役に立っていた。
エンジンやギアなど、車を作るのに必要な機械的な情報は
役に立たなかったという話？
いやそれは馬鹿な意見だろうｗ
俺らは車を作る側の人間なわけで。
二刀流かよｗ
>>190
vim知らん奴にもわかるように文書起こせ。基本中の基本だろ。
vim知らん奴にもわかるように文書起こせ。基本中の基本だろ。
>>194
やっぱりそれ仕様じゃんか
やっぱりそれ仕様じゃんか
>>195
仕様じゃないんだなこれが
仕様じゃないんだなこれが
設計がなにかわかってないようだから、
といっても俺が何を言っても納得しそうもないから、
ソフトウェア開発に関する有名なサイトの
「設計/アーキテクチャ に関するすべてのコンテンツ」の
リンクを張っておくわ。
これが設計ってものだから。
http://www.infoq.com/jp/architecture-design/
といっても俺が何を言っても納得しそうもないから、
ソフトウェア開発に関する有名なサイトの
「設計/アーキテクチャ に関するすべてのコンテンツ」の
リンクを張っておくわ。
これが設計ってものだから。
http://www.infoq.com/jp/architecture-design/
>>194
ソフトウェア業界では仕様と言います。
ソフトウェア業界では仕様と言います。
ソフトウェアだけど仕様じゃないよ
それだけ特殊なモノを作ってただけ
ってか仕様にされたら設計書が白紙になる
それだけ特殊なモノを作ってただけ
ってか仕様にされたら設計書が白紙になる
映像を人の手で制御する何かか
ドキュメントをどう呼ぶかは業界によって違うからどうでもいいけど、
「貼る絵、座標、線色、光源、音など」についての設計をプログラマに書かせる意味がわからない。
コンサートホール設計した建築家に、コンサートのセットリスト作らせるようなものだ。
「貼る絵、座標、線色、光源、音など」についての設計をプログラマに書かせる意味がわからない。
コンサートホール設計した建築家に、コンサートのセットリスト作らせるようなものだ。
まあ、何故か知らないがデザイナーさんはマをかなり敵視してることが多いよな。
馬鹿「仕様書書いてやるから、仕様教えろ。機能だけ聞いてもわからない」
お前いらねーじゃん
お前いらねーじゃん
>>204
お前は仕様書書いたこと無いのか・・・？
お前は仕様書書いたこと無いのか・・・？
>>205
お前暇そうだな
お前暇そうだな
>>205
テキストエディタの仕様書すら書けないKACに言われても....
テキストエディタの仕様書すら書けないKACに言われても....
私が1ですが逃げてないですよ。
仕様書はvimと一緒。何度もそう言ってるはずですが？
仕様書はvimと一緒。何度もそう言ってるはずですが？
私が本当の1です。
vimの仕様は私もよくわかってません。
仕様の提示は無理ですので無かった事にしてください。
vimの仕様は私もよくわかってません。
仕様の提示は無理ですので無かった事にしてください。
211 ：仕様書無しさん：2014/04/12(土) 21:09:09.71
123 名前: 仕様書無しさん Mail: sage 投稿日: 2014/03/31(月) 00:33:32.86
>>121
客は1だからな。
金も出さない、要望も仕様も出さないから
何作ってほしいのかよくわからんが
124 名前: 仕様書無しさん Mail: sage 投稿日: 2014/03/31(月) 00:39:56.60
コテ忘れてますよw
127 名前: 仕様書無しさん Mail: sage 投稿日: 2014/03/31(月) 21:53:16.16
>>124
コテ付けたり名無しになったり一人二役で忙しいのだから、見逃してやれ
>>121
客は1だからな。
金も出さない、要望も仕様も出さないから
何作ってほしいのかよくわからんが
124 名前: 仕様書無しさん Mail: sage 投稿日: 2014/03/31(月) 00:39:56.60
コテ忘れてますよw
127 名前: 仕様書無しさん Mail: sage 投稿日: 2014/03/31(月) 21:53:16.16
>>124
コテ付けたり名無しになったり一人二役で忙しいのだから、見逃してやれ
ゴミだな早く消えろゴミ
213 ：仕様書無しさん：2014/04/13(日) 01:07:34.73
実装仕様を細かく考え文書化すると云うことだな。
目的は、誰か別の人に作らせる場合に、指示書として渡すためと
後で保守する場合、内容理解の助けとし、保守工数を減らさせるため。
実装は、同じ仕様内容でも、デスクトップＰＣ／スマホ／タブレット
メインフレームなどのプラットフォームが違えば、どういうＯＳ使って
どの言語つかって組むかなど、いろいろな方法があるよな。
目的は、誰か別の人に作らせる場合に、指示書として渡すためと
後で保守する場合、内容理解の助けとし、保守工数を減らさせるため。
実装は、同じ仕様内容でも、デスクトップＰＣ／スマホ／タブレット
メインフレームなどのプラットフォームが違えば、どういうＯＳ使って
どの言語つかって組むかなど、いろいろな方法があるよな。
「デスクトップＰＣ／スマホ／タブレット
メインフレームなどのプラットフォームが違えば、どういうＯＳ使って
どの言語つかって組むかなど」
これは要求仕様。言語は自由に選べるなら設計に含まれるかもしれないレベル。
メインフレームなどのプラットフォームが違えば、どういうＯＳ使って
どの言語つかって組むかなど」
これは要求仕様。言語は自由に選べるなら設計に含まれるかもしれないレベル。
他のシステムと連携する時はいるな
データベースとか、処理のタイミングとか
ネットワークの構成とか
ユーザしか使わない閉じた系のシステムなら、設計は要らないけどなぁ
データベースとか、処理のタイミングとか
ネットワークの構成とか
ユーザしか使わない閉じた系のシステムなら、設計は要らないけどなぁ
設計なしで客が要求した性能をどうやって達成するの？
たとえばレスポンス1秒以内っていわれて、適当なハード買って後から何とかできるの？
LinuxやMySQLで作って、後からWin鯖とOracleじゃないと手に負えませんってなったらどうすんの？
意思疎通と契約確認の２つの意味で設計書は必要だと思うけど
全部口頭でやるってこと？
たとえばレスポンス1秒以内っていわれて、適当なハード買って後から何とかできるの？
LinuxやMySQLで作って、後からWin鯖とOracleじゃないと手に負えませんってなったらどうすんの？
意思疎通と契約確認の２つの意味で設計書は必要だと思うけど
全部口頭でやるってこと？
>>217
作ってからテストすんの？もしそれがNGで追加予算つかなきゃプロジェクト倒れるって事？
作ってからテストすんの？もしそれがNGで追加予算つかなきゃプロジェクト倒れるって事？
いや、作らないきゃ検証できんからｗ
検証なしに、できます！（根拠なし）って言ってんの？
検証なしに、できます！（根拠なし）って言ってんの？
言ってるんだろ？
言うだけなら簡単だからなｗ
言うだけなら簡単だからなｗ
>>222
その検証用のテストプログラムはどこで走らせるんだ？
その検証用のテストプログラムはどこで走らせるんだ？
>>221
普通は性能見積りは机上でやるもんだ。
どれだけの仕事量をどのくらいの早さで処理させるのか計算すりゃでるだろ。
経験が少なくてブラックボックスぎみの部分がある場合とか、
ボトルネックが大きそうな所なんかは実測することもあるけど、
それはその部分だけに集中した環境をつくって、確認・計測で十分。
見積りなんてのは、いかに素早く正確にできるかが肝なんだから
作ってからとかアホの極み。
普通は性能見積りは机上でやるもんだ。
どれだけの仕事量をどのくらいの早さで処理させるのか計算すりゃでるだろ。
経験が少なくてブラックボックスぎみの部分がある場合とか、
ボトルネックが大きそうな所なんかは実測することもあるけど、
それはその部分だけに集中した環境をつくって、確認・計測で十分。
見積りなんてのは、いかに素早く正確にできるかが肝なんだから
作ってからとかアホの極み。
>>224
特殊なHWが必要とかじゃ無い限り、レンタルできる環境はいくらでもある。
特殊なHWが必要とかじゃ無い限り、レンタルできる環境はいくらでもある。
>>227
自社のハードウェアだとしても、無制限に借りられるわけじゃないし
テスト要員の確保だって無料じゃない
どこかの時点で設計と実測のすり合わせはするだろうし
設計の根拠として既存システムやベンチマークは利用すると思うけど
それでもシステムを開発する前に設計するんじゃないの？
それにその方法だとハードウェアの見積もりが提案できない
そして、作ってから性能を全く満たせなかった場合に対策がなくなる
ハードの増強で対策できればいいが、そもそも実現できない要求だった場合に手がなくなる
自社のハードウェアだとしても、無制限に借りられるわけじゃないし
テスト要員の確保だって無料じゃない
どこかの時点で設計と実測のすり合わせはするだろうし
設計の根拠として既存システムやベンチマークは利用すると思うけど
それでもシステムを開発する前に設計するんじゃないの？
それにその方法だとハードウェアの見積もりが提案できない
そして、作ってから性能を全く満たせなかった場合に対策がなくなる
ハードの増強で対策できればいいが、そもそも実現できない要求だった場合に手がなくなる
>>225 >>226
初期のプロジェクト定義の段階では
見積りに60%から160%に及ぶ誤差が生じる
ということが、ソフトウェア開発の経験
（俺の経験じゃないよ）から明らかになってる。
これは研究の結果であり事実だから
これを否定することに意味は無い。
じゃあどうするかと言ったら、短いサイクルで開発とリリースと検証を
繰り返して精度を上げるしかない。
作ってみなきゃわからないことは、作ってみなければわからない。
当たり前の事実。根性論で解決できる問題ではない。
初期のプロジェクト定義の段階では
見積りに60%から160%に及ぶ誤差が生じる
ということが、ソフトウェア開発の経験
（俺の経験じゃないよ）から明らかになってる。
これは研究の結果であり事実だから
これを否定することに意味は無い。
じゃあどうするかと言ったら、短いサイクルで開発とリリースと検証を
繰り返して精度を上げるしかない。
作ってみなきゃわからないことは、作ってみなければわからない。
当たり前の事実。根性論で解決できる問題ではない。
見積もりが甘かった。
それは見積もりをオーバーすることだけではなく、
見積もりを下回った場合も「見積もりが甘い」ことになる。
見積もりをオーバーしないように、見積の数倍をふっかけるのは
仕事が出来ない証拠。責任取りたくないから自己保身でやってるだけ。
高すぎる見積もりは仕事を取られることになるのだから
見積もりは正確でなければいけない。
それは見積もりをオーバーすることだけではなく、
見積もりを下回った場合も「見積もりが甘い」ことになる。
見積もりをオーバーしないように、見積の数倍をふっかけるのは
仕事が出来ない証拠。責任取りたくないから自己保身でやってるだけ。
高すぎる見積もりは仕事を取られることになるのだから
見積もりは正確でなければいけない。
自称プロ根性ある奴の中には
やる気だけで、それをやるための手段（技術）が伴ってない奴がいるからな。
そういう奴は、それを実現する方法は何かあるのか？って言ったら
頑張りますとかしか言えない。
やる気だけで、それをやるための手段（技術）が伴ってない奴がいるからな。
そういう奴は、それを実現する方法は何かあるのか？って言ったら
頑張りますとかしか言えない。
>>229
「100％なんて、無理じゃないか」は見積もり作れないやつがよく言う言い訳。
100％じゃ無くても見積もり要求されてるんだから、見積もりを出すしか無い。
いやなら、見積もり無しでゴーサインだすように客を説得すること。
「100％なんて、無理じゃないか」は見積もり作れないやつがよく言う言い訳。
100％じゃ無くても見積もり要求されてるんだから、見積もりを出すしか無い。
いやなら、見積もり無しでゴーサインだすように客を説得すること。
客は神さまなのだから
こちらから提案するのはなく
言われたものを作ればいいだけ。
こちらから提案するのはなく
言われたものを作ればいいだけ。
236 ：仕様書無しさん：2014/04/14(月) 03:06:02.24
>>220
性能見積もりも、簡単に精度良く出来る場合と
雲をつかむようなケースもあり、ケースバイケースだな。
前提事項から調査しないと、ハイ直ぐ出来ますと
云う内容では無いよ。 機能保障よりはるかにハードルは
高い。
既にあるシステムの改良なら、どんな巨大で複雑なシステムでも
やりようはあるし、精度もある程度保障は可能だがな。
性能見積もりも、簡単に精度良く出来る場合と
雲をつかむようなケースもあり、ケースバイケースだな。
前提事項から調査しないと、ハイ直ぐ出来ますと
云う内容では無いよ。 機能保障よりはるかにハードルは
高い。
既にあるシステムの改良なら、どんな巨大で複雑なシステムでも
やりようはあるし、精度もある程度保障は可能だがな。
>>225
すげーな
秒間何リクエスト捌けるとか何ミリセクかかるとか具体的な数値あげて言えるわけ？
俺は客からざっくりとこう言うの大丈夫？聞かれてざっくりと試してみないとなんともですがと但し書きつけた上でそれぐらいなら大丈夫とかトントンですかねーとかしか言えんわ。
すげーな
秒間何リクエスト捌けるとか何ミリセクかかるとか具体的な数値あげて言えるわけ？
俺は客からざっくりとこう言うの大丈夫？聞かれてざっくりと試してみないとなんともですがと但し書きつけた上でそれぐらいなら大丈夫とかトントンですかねーとかしか言えんわ。
リクエストが1日50万くるけど1秒以内に返してね
ぐらいの大雑把な要求しかないよね
実際に要求を満たしているかは実機で構築するまでわかんないけど
今これぐらいのスペックで導入機がこれぐらいだから大丈夫っしょぐらいの見積もり
もちろん、DBやWEBサーバで色んなデータ計測してるけどやってみなきゃわからん
ぐらいの大雑把な要求しかないよね
実際に要求を満たしているかは実機で構築するまでわかんないけど
今これぐらいのスペックで導入機がこれぐらいだから大丈夫っしょぐらいの見積もり
もちろん、DBやWEBサーバで色んなデータ計測してるけどやってみなきゃわからん
241 ：仕様書無しさん：2014/04/17(木) 13:08:38.97
機械設計だって手直しができないから、やらないことが多いが
設計の不具合がでる
つまり設計で見通せる範囲なんちゅもんは全体の1/10程度と思っていい
後で、見通しができていなかったいうのは簡単だが、
見通せることが可能だ、という視点がなんであるのかわからんね
設計の不具合がでる
つまり設計で見通せる範囲なんちゅもんは全体の1/10程度と思っていい
後で、見通しができていなかったいうのは簡単だが、
見通せることが可能だ、という視点がなんであるのかわからんね
設計書書く前に、せめて要求管理くらいはしろよと思う。
>>241
設計の不具合だとわかるだけでも、設計をやる意味がある。
設計の不具合だとわかるだけでも、設計をやる意味がある。
244 ：仕様書無しさん：2014/04/25(金) 14:37:30.41
>>1
＞ ユーザーサイドのやりたい事（仕様書） と
＞ それを実現するコードがあれば十分ではないか？
これ見るだけで、わりと簡単な仕事しかしてこなかったのでは？と思う。
Web系とかモバイルアプリの開発は、一部難しい部分もあるが、
サンプルを見ながら作れば、ほとんどが初心者でもなんとか作れる。
そして、そういう仕事なら設計書は不要だと思うだろう。
コードを直して、設計書を直している時間がもったいないと
感じるのだろう。
>>1のような意見を言う場合、どういうシステムの開発について
述べているのか書いてくれないと、どう評価していいのかわからない。
だから書いてね！
どういうシステムの開発なの？
＞ ユーザーサイドのやりたい事（仕様書） と
＞ それを実現するコードがあれば十分ではないか？
これ見るだけで、わりと簡単な仕事しかしてこなかったのでは？と思う。
Web系とかモバイルアプリの開発は、一部難しい部分もあるが、
サンプルを見ながら作れば、ほとんどが初心者でもなんとか作れる。
そして、そういう仕事なら設計書は不要だと思うだろう。
コードを直して、設計書を直している時間がもったいないと
感じるのだろう。
>>1のような意見を言う場合、どういうシステムの開発について
述べているのか書いてくれないと、どう評価していいのかわからない。
だから書いてね！
どういうシステムの開発なの？
書類がないとどのサーバにどんなバージョンのどんなアプリが入ってるかわからないじゃないか
そんなもの管理画面とかで見ないか？
特にクラウドとか使っていれば、頻繁にマシン構成や台数とかも変わるし、
書類だと同期取るの大変だろう？実機調べないとわからん状況になるぞ。
特にクラウドとか使っていれば、頻繁にマシン構成や台数とかも変わるし、
書類だと同期取るの大変だろう？実機調べないとわからん状況になるぞ。
247 ：仕様書無しさん：2014/04/26(土) 00:36:24.96
開発環境と本番環境が違うなんて当たり前のように発生する中で
開発環境にあわせてチューニングしていくのはありえない
開発環境にあわせてチューニングしていくのはありえない
250 ：仕様書無しさん：2014/04/26(土) 02:06:35.43
変え(･∀･)わきゃ
> プログラマがそんなに頻繁にマシン構成変えわきゃねーだろバカ！
変えるだろ。テストする以上実行環境に近いものでテストしないといけない。
開発は最新環境で最新ツール使ってやりたいのに
まさか実行環境に合わせて古い開発ツール使ってんのか？
それに違うマシン構成を簡単に作れるようにしておかなきゃ
実行環境のバージョンアップとか出来ねぇだろ。
お前、新旧環境のどちらでも動くように作るとか
テストするとかしないのか？
変えるだろ。テストする以上実行環境に近いものでテストしないといけない。
開発は最新環境で最新ツール使ってやりたいのに
まさか実行環境に合わせて古い開発ツール使ってんのか？
それに違うマシン構成を簡単に作れるようにしておかなきゃ
実行環境のバージョンアップとか出来ねぇだろ。
お前、新旧環境のどちらでも動くように作るとか
テストするとかしないのか？
わざわざ金出してVPSなんか借りんでも・・
わざわざ金を出すというほどか？
今のVPSの価格を当てはめると、
わざわざ月500円だしてVPSなんかを借りんでも
って言ってるようなもんなんだが。
24時間つけっぱなしした時の電気代よりも
安いぐらいなんだが。
今のVPSの価格を当てはめると、
わざわざ月500円だしてVPSなんかを借りんでも
って言ってるようなもんなんだが。
24時間つけっぱなしした時の電気代よりも
安いぐらいなんだが。
別にレンタルか自鯖かっていうのは本質じゃないよ
257 ：仕様書無しさん：2014/04/26(土) 13:22:28.91
>>252
テストするに決まってるじゃないか！
おまえの言ってるのは、少人数でやるような仕事の話ばかりなんだよ。
どのような仕事をしているから、この仕事では設計書は不要だ、
というように書かないから、たとえば銀行のシステムでも仕様書が
不必要だと主張しているようにしか見えないだろ？
そんな簡単なこともわからんの？
テストするに決まってるじゃないか！
おまえの言ってるのは、少人数でやるような仕事の話ばかりなんだよ。
どのような仕事をしているから、この仕事では設計書は不要だ、
というように書かないから、たとえば銀行のシステムでも仕様書が
不必要だと主張しているようにしか見えないだろ？
そんな簡単なこともわからんの？
旧実行環境で動作するかなんてテストしないよ
ミドルウェアのバージョンも違うし動くわけがない
ミドルウェアのバージョンも違うし動くわけがない
そんな揚げ足取りみたいな話はお腹いっぱい。もう少し建設的な話を頼む(´･_･`)
建設的な業界じゃないからそんな話はでない
262 ：仕様書無しさん：2014/04/26(土) 18:40:54.78
>>258
おれは旧実行環境で動作確認が必要な仕事もずいぶんとやった。
ミドルウェアのバージョンが違っても、なんとか動くようにしてくれ！
というのはときどきあったよ。
>>261
その「仕様書ってテストコードの話」という部分が理解できない
仕様書とテストコードは全く別のものだから
再び書くけど、そもそもどういう仕事を
どのぐらいやっているのかを教えてくれ。
どのような仕事を念頭において、設計書が必要ないと言っているのか
わからないと有意義な話ができない。
おれは旧実行環境で動作確認が必要な仕事もずいぶんとやった。
ミドルウェアのバージョンが違っても、なんとか動くようにしてくれ！
というのはときどきあったよ。
>>261
その「仕様書ってテストコードの話」という部分が理解できない
仕様書とテストコードは全く別のものだから
再び書くけど、そもそもどういう仕事を
どのぐらいやっているのかを教えてくれ。
どのような仕事を念頭において、設計書が必要ないと言っているのか
わからないと有意義な話ができない。
仕様書＝テストコードじゃなかったら、
仕様にあっているかどうかどうやって
どうやってテストするの？
まさか手作業？
それコードを修正したら、全部手作業で
テストしなおしになるってことじゃない？
仕様を満たしているか機械的にわかるようにしておかなきゃ。
仕様にあっているかどうかどうやって
どうやってテストするの？
まさか手作業？
それコードを修正したら、全部手作業で
テストしなおしになるってことじゃない？
仕様を満たしているか機械的にわかるようにしておかなきゃ。
下流向けの仕様はテストコードでいいよな。
下流ってシステムで一番重要なところなんだよな。
その重要な所で必要とされるのがテストコード。
その重要な所で必要とされるのがテストコード。
せめて仕様書からテストコード書けるくらいのスキルがあればいいけど。
267 ：仕様書無しさん：2014/04/26(土) 20:39:05.08
>>263
だからどういう仕事をやるとそういう発想になるのか知りたい。
だからさっさとかけ！
この馬鹿が！
意味不明なことばっかり書いてんじゃねーよクズ！
どうせ学生のアルバイトが小さなソフトちょっとつくったからって
マ板にいって、いっぱしのプログラマのふりしてやろう！
というだけのことだろうが、
どういう仕事をやってるのか書かないなら、もう聞かない。
めんどうだから 単にバカよばわりしてやるだけだから。
だからどういう仕事をやるとそういう発想になるのか知りたい。
だからさっさとかけ！
この馬鹿が！
意味不明なことばっかり書いてんじゃねーよクズ！
どうせ学生のアルバイトが小さなソフトちょっとつくったからって
マ板にいって、いっぱしのプログラマのふりしてやろう！
というだけのことだろうが、
どういう仕事をやってるのか書かないなら、もう聞かない。
めんどうだから 単にバカよばわりしてやるだけだから。
雑魚がうるせぇなぁ
>>268
せめてテストコード書けるようになってから参加してね。
せめてテストコード書けるようになってから参加してね。
>>269
雑魚だって自覚はあるようだねｗ
雑魚だって自覚はあるようだねｗ
>>272
仕様書無しで検収担当はどうやってチェックするんだ・・・
仕様書無しで検収担当はどうやってチェックするんだ・・・
テストコード＝仕様書だよ。
っていうか、仕様書があったとして
その仕様書でOKだってどうやって判断すると思ってるんだ？
っていうか、仕様書があったとして
その仕様書でOKだってどうやって判断すると思ってるんだ？
わからないから、仕様書があっても
思っていたのと違うって出来てから文句言うんだろ？
思っていたのと違うって出来てから文句言うんだろ？
設計と実装を別契約にしようぜって話ですか
>>274
仕様書ってのは、「仕様が正しく書かれているもの」
これはさすがに異論はないな？
今回の話題は、この「正しく」ってのをどう担保するか。って事だよな。
一般的に仕様とは、システムを要求する者が求めた事に対する答えが記載される。
この仕様書は、仕様を求めている者に対して確認を依頼することで正しさが担保される。
なので、自然言語を使って記載するのが通常。
テストコードを仕様書として扱う特殊な例があることは否定しないが、
ここでそれのみを正しいものとして主張されても困る。
仕様書ってのは、「仕様が正しく書かれているもの」
これはさすがに異論はないな？
今回の話題は、この「正しく」ってのをどう担保するか。って事だよな。
一般的に仕様とは、システムを要求する者が求めた事に対する答えが記載される。
この仕様書は、仕様を求めている者に対して確認を依頼することで正しさが担保される。
なので、自然言語を使って記載するのが通常。
テストコードを仕様書として扱う特殊な例があることは否定しないが、
ここでそれのみを正しいものとして主張されても困る。
そうやっていつまでも何が「正しい」で仕事してりゃいいさ
スレタイに立ち返る
スレタイに立ち返る
設計書と仕様書の区別すらつかん奴って多いよな・・・
280 ：仕様書無しさん：2014/04/26(土) 21:48:45.34
設計書が書けないKACさんに言われても....
>>280
仕様が提示されないのにどうやって設計を書くのか・・・
仕様が提示されないのにどうやって設計を書くのか・・・
282 ：仕様書無しさん：2014/04/26(土) 22:10:26.84
1本人からはvimという指定があったはずだ
もともと設計について議論していたのだから、
もしvimの仕様が不満なら自分で仕様を想定してもかまわないはず
対人コミュニケーション不全症でもないかぎり、常識で分かるだろ
もともと設計について議論していたのだから、
もしvimの仕様が不満なら自分で仕様を想定してもかまわないはず
対人コミュニケーション不全症でもないかぎり、常識で分かるだろ
283 ：仕様書無しさん：2014/04/27(日) 00:12:23.04
納品物として必要だからって理由で渋々作った設計書なんて糞の役に立たないよな
俺は組み込みやってて、少人数のチームの一員として１つのソフト開発をしてる
仕様追加／変更／不具合修正を分担して、それぞれで設計／実装／デバッグする感じ
設計書にまとめなくていいけど、有効な設計レビューが出来るレベルの資料は必須だわ
コードレビューでは設計通りに作れているかだけ確認したい
俺は組み込みやってて、少人数のチームの一員として１つのソフト開発をしてる
仕様追加／変更／不具合修正を分担して、それぞれで設計／実装／デバッグする感じ
設計書にまとめなくていいけど、有効な設計レビューが出来るレベルの資料は必須だわ
コードレビューでは設計通りに作れているかだけ確認したい
287 ：仕様書無しさん：2014/04/27(日) 02:38:42.46
最近、異動した先のチームの設計レビューが形骸化してたので、意識改革中
仕様書＝テストコード？？？
関数単位のコーダーなら成り立つのかな
担当業務と経験年数を知りたいな
仕様書＝テストコード？？？
関数単位のコーダーなら成り立つのかな
担当業務と経験年数を知りたいな
>>279
どんな区別をしてるんだ？
機能仕様書（機能設計書）、画面設計書（画面仕様書）、基本設計書（基本仕様書）、
構造設計書（構造仕様書）、DB設計書（DB仕様書）、詳細設計書（詳細仕様書）
あたりは、ほぼ区別なしで、現場の用語に準拠してる。
試験仕様書だけは、試験設計書って日本語は聞いたことがない。
どんな区別をしてるんだ？
機能仕様書（機能設計書）、画面設計書（画面仕様書）、基本設計書（基本仕様書）、
構造設計書（構造仕様書）、DB設計書（DB仕様書）、詳細設計書（詳細仕様書）
あたりは、ほぼ区別なしで、現場の用語に準拠してる。
試験仕様書だけは、試験設計書って日本語は聞いたことがない。
基本設計書（基本仕様書）、
機能仕様書（機能設計書）、画面設計書（画面仕様書）
構造設計書（構造仕様書）、DB設計書（DB仕様書）
詳細設計書（詳細仕様書）
機能仕様書（機能設計書）、画面設計書（画面仕様書）
構造設計書（構造仕様書）、DB設計書（DB仕様書）
という感じでいいよ
役立つのは実際のクラス名の表とか、画面を表示している変数名とか
遷移状態を表す命名とかさ、そういうのがまとめられているといいよ
機能仕様書（機能設計書）、画面設計書（画面仕様書）
構造設計書（構造仕様書）、DB設計書（DB仕様書）
詳細設計書（詳細仕様書）
機能仕様書（機能設計書）、画面設計書（画面仕様書）
構造設計書（構造仕様書）、DB設計書（DB仕様書）
という感じでいいよ
役立つのは実際のクラス名の表とか、画面を表示している変数名とか
遷移状態を表す命名とかさ、そういうのがまとめられているといいよ
292 ：仕様書無しさん：2014/04/27(日) 13:54:52.31
さっさと答えろ。
開発工程が標準化されてないから必要なドキュメントの定義も各社、各自でてんでバラバラというｗ
>>291
他所から買ってくるようなモジュールなら、基本設計書だろう。
プロジェクト内で作成する部分の作り方は、構造設計書。
けど、構造設計書をまともに書けるヤツは、極めて少ないな。
業界30年のベテランでも、見たことすらないって人が、ほとんどだろう。
他所から買ってくるようなモジュールなら、基本設計書だろう。
プロジェクト内で作成する部分の作り方は、構造設計書。
けど、構造設計書をまともに書けるヤツは、極めて少ないな。
業界30年のベテランでも、見たことすらないって人が、ほとんどだろう。
>>255
500円のVPSなんてウンコみたいな性能じゃん
500円のVPSなんてウンコみたいな性能じゃん
じゃあ1000円だせば？
メリットがない
ソフトウェア設計本を一冊読んだ。だが、読む価値もないというのが感想。
業務用を例にとって、工程管理、画面設計とかユースケースとやっている。
実際、客との立会いで、先に出されていた画面から、
あたらに追加項目が出てくるということがあるわけ。
プログラミングではそうしたことに柔軟に対応できる作り方ができているといい。
プログラマにとって、そういう設計の仕方なんかに言及してあると読む価値があるわけ。
業務用を例にとって、工程管理、画面設計とかユースケースとやっている。
実際、客との立会いで、先に出されていた画面から、
あたらに追加項目が出てくるということがあるわけ。
プログラミングではそうしたことに柔軟に対応できる作り方ができているといい。
プログラマにとって、そういう設計の仕方なんかに言及してあると読む価値があるわけ。
304 ：仕様書無しさん：2014/04/28(月) 13:18:28.89
＞SE向けの、ようするに仕様書まとめることしか書いてない エセ本だろうさ。
多分、ソフトウェア設計という題名の本は、そういう世界だろうと思うよ
また構造化プログラミングという題名やつもだめだな。中身はポンチ絵を描くこと。
そうすると、構造化であるとやっている
俺はある本で、「何万行書いてもバグの出ない書き方がある」という記述を見たが、
その具体例は出ていなかった。そういうのを知りたいな
多分、ソフトウェア設計という題名の本は、そういう世界だろうと思うよ
また構造化プログラミングという題名やつもだめだな。中身はポンチ絵を描くこと。
そうすると、構造化であるとやっている
俺はある本で、「何万行書いてもバグの出ない書き方がある」という記述を見たが、
その具体例は出ていなかった。そういうのを知りたいな
＞俺はある本で、「何万行書いてもバグの出ない書き方がある」という記述を見たが、
俺は、それはありえない、と思うよ。
いやバグの出にくい書き方はあるかも、それは読みやすい書き方だな
最近こういうのを見たが笑っちゃうね。馬鹿みたいな書き方
for (q = &array[i + x + x2]; j <= nSize; j += x, p += x, q += x) {
こういう書き方がいいのよ
for (q = 0; q <= nSize; q++) {
俺は、それはありえない、と思うよ。
いやバグの出にくい書き方はあるかも、それは読みやすい書き方だな
最近こういうのを見たが笑っちゃうね。馬鹿みたいな書き方
for (q = &array[i + x + x2]; j <= nSize; j += x, p += x, q += x) {
こういう書き方がいいのよ
for (q = 0; q <= nSize; q++) {
もうKACはマ板から出ていけよ
話すこと話すこと的外れで、あらゆるスレ荒らして歩いて
staticおじさん並に自分は正しいと思ってるから手に負えない
話すこと話すこと的外れで、あらゆるスレ荒らして歩いて
staticおじさん並に自分は正しいと思ってるから手に負えない
つか質問スレ荒らすのやめてくれ＞コテ
>>307-308
もういいから。お前がうざい。
もういいから。お前がうざい。
馬鹿がこんなところにもきた
もういいから隔離スレ作ってそこで騒いどけよ
もういいから隔離スレ作ってそこで騒いどけよ
「バグではなく仕様」と言えば、バグは無くなる。
バグを直すというのではなく、仕様を変更すると言え。
バグのないプログラムだよ。それが。
バグを直すというのではなく、仕様を変更すると言え。
バグのないプログラムだよ。それが。
そんないいわけさせない為に仕様書が必要なんだよ
このスレでは、「要件定義書」という言葉を使う奴がほんと少ないな
>>313
だってそれ基本的に客が作るもんだし
だってそれ基本的に客が作るもんだし
>>302
要求管理、要件管理でググれ。
要求管理、要件管理でググれ。
316 ：仕様書無しさん：2014/04/28(月) 20:26:15.82
>>295
ほんとにKACは無知だな....
「仕様」を定める活動を「設計」と呼ぶ
たとえば、機能設計工程では機能仕様を定める
言い換えると、機能設計工程の成果が機能仕様になる
ここで機能仕様を記述した文書の命名について、
工程を視点にすれば機能設計書になるし、成果物を視点にすれば機能仕様書になる
国内では機能設計書という用語と機能仕様書という用語を使う現場があるけど、
両者は同義語だから現場組織内で統一されてさえいれば、どちらでもかまわない(>>289,290)
ほんとにKACは無知だな....
「仕様」を定める活動を「設計」と呼ぶ
たとえば、機能設計工程では機能仕様を定める
言い換えると、機能設計工程の成果が機能仕様になる
ここで機能仕様を記述した文書の命名について、
工程を視点にすれば機能設計書になるし、成果物を視点にすれば機能仕様書になる
国内では機能設計書という用語と機能仕様書という用語を使う現場があるけど、
両者は同義語だから現場組織内で統一されてさえいれば、どちらでもかまわない(>>289,290)
317 ：仕様書無しさん：2014/04/28(月) 20:31:18.27
機能仕様書と機能設計書が同じとか、いかれた現場もあるんだなぁ
320 ：仕様書無しさん：2014/04/28(月) 20:48:20.80
だって仕事を出す側だもんよ
仕様書と設計書なんてまったく別のモンなのになぁ
視点の問題じゃなくてよ、書くべきものが違うんだよ
同じとかいかれているとしかいいようがない
仕様書と設計書なんてまったく別のモンなのになぁ
視点の問題じゃなくてよ、書くべきものが違うんだよ
同じとかいかれているとしかいいようがない
321 ：仕様書無しさん：2014/04/28(月) 20:52:47.03
>>320
いつから発注仕様の話になったの？
いつから発注仕様の話になったの？
322 ：仕様書無しさん：2014/04/28(月) 20:55:46.96
323 ：仕様書無しさん：2014/04/28(月) 21:00:48.58
>おまえんところは、機能設計書と機能仕様書、納品しないの？
しないよ。そして納品後、客先にいってデバッグ 。そんあのあたりまえ
しないよ。そして納品後、客先にいってデバッグ 。そんあのあたりまえ
324 ：仕様書無しさん：2014/04/28(月) 21:03:41.99
325 ：仕様書無しさん：2014/04/28(月) 21:05:07.94
納品後に客先でデバッグ？それ検収どうなってんの？
納期遅延だと違約金がきついだろ
無能なんだな、おまえらも客も
客の担当も相当のペナルティ負ってるんだろうな
なんにせよ、今後のために仕様書と設計書は違うもの、くらいのことは
知っておいたほうがいいよ
納期遅延だと違約金がきついだろ
無能なんだな、おまえらも客も
客の担当も相当のペナルティ負ってるんだろうな
なんにせよ、今後のために仕様書と設計書は違うもの、くらいのことは
知っておいたほうがいいよ
326 ：仕様書無しさん：2014/04/28(月) 21:09:46.45
327 ：仕様書無しさん：2014/04/28(月) 21:11:40.34
>>325
上から目線うぜえ。
上から目線うぜえ。
329 ：仕様書無しさん：2014/04/28(月) 21:15:09.19
期日までに納品して、検収があがる。
操作マニュアルというやつがあるだろ。そんなもん後から提出。
その後、二、三ヶ月後によーやく作業者が扱いだして、
ここ直してくなーい、と反応が出る
操作マニュアルというやつがあるだろ。そんなもん後から提出。
その後、二、三ヶ月後によーやく作業者が扱いだして、
ここ直してくなーい、と反応が出る
330 ：仕様書無しさん：2014/04/28(月) 21:15:29.75
ん？おまえらのところは購入仕様書とか書かないの？
何を納品するかは全部購入仕様書にかいてあんだろ
何を納品するかは全部購入仕様書にかいてあんだろ
331 ：仕様書無しさん：2014/04/28(月) 21:18:23.03
ちなみに、機能設計工程の納品物って、うちだと
・機能仕様書
・機能設計書
・機能仕様レビュー議事録
・機能設計レビュー議事録
・機能設計工程品質分析報告書
こんだけある
もっとあったかもしれない
・機能仕様書
・機能設計書
・機能仕様レビュー議事録
・機能設計レビュー議事録
・機能設計工程品質分析報告書
こんだけある
もっとあったかもしれない
332 ：仕様書無しさん：2014/04/28(月) 21:18:44.02
KAC消えろよマジ気持ち悪い
334 ：仕様書無しさん：2014/04/28(月) 21:37:44.59
335 ：仕様書無しさん：2014/04/28(月) 21:42:17.37
ちなみに、機能設計工程の納品物って、うちだと
・機能仕様書
・機能設計書
・機能仕様レビュー議事録
・機能設計レビュー議事録
・機能設計工程品質分析報告書
>こんだけある
で、ぺこぺこしている状況なん？
おれの商品なんて、注文が殺到するしている、と客にいばっていいればいいよ
・機能仕様書
・機能設計書
・機能仕様レビュー議事録
・機能設計レビュー議事録
・機能設計工程品質分析報告書
>こんだけある
で、ぺこぺこしている状況なん？
おれの商品なんて、注文が殺到するしている、と客にいばっていいればいいよ
336 ：仕様書無しさん：2014/04/28(月) 21:44:53.12
>>316だけど、KACからのレスが見当たらないのは
また反論できずに逃げ出したってことでいいのかね？
また反論できずに逃げ出したってことでいいのかね？
337 ：仕様書無しさん：2014/04/28(月) 21:46:51.44
>>334
機能仕様が書いてあるか、機能設計が書いてあるか、の違いだってば
何をつくるか、と、どう作るかって全然違うだろ？そのくらいわかるよな
小規模開発では機能仕様書兼設計書みたいに合体することもある
きみらのところだって、仕様と設計は違うってわかった上で、
機能仕様書兼設計書のことを仕様書と呼んだり設計書と呼んだりしてる
だけだろ？そう信じたいね
機能仕様が書いてあるか、機能設計が書いてあるか、の違いだってば
何をつくるか、と、どう作るかって全然違うだろ？そのくらいわかるよな
小規模開発では機能仕様書兼設計書みたいに合体することもある
きみらのところだって、仕様と設計は違うってわかった上で、
機能仕様書兼設計書のことを仕様書と呼んだり設計書と呼んだりしてる
だけだろ？そう信じたいね
842 ： KAC [sage] DATE:2014/04/27(日) 15:04:43.46
>>841
あぁ、基本的にバカは相手しないことにしてるんで、
お前の出没したところでは話が途中で終わってるかもな。
844 ： 仕様書無しさん [sage] DATE:2014/04/27(日) 15:08:25.19
要は論破されて逃げてるだけじゃん
>>841
あぁ、基本的にバカは相手しないことにしてるんで、
お前の出没したところでは話が途中で終わってるかもな。
844 ： 仕様書無しさん [sage] DATE:2014/04/27(日) 15:08:25.19
要は論破されて逃げてるだけじゃん
341 ：仕様書無しさん：2014/04/28(月) 22:20:53.34
>>337
>>316で書いたように、機能の「仕様」を定める活動が「設計」だよ
設計は人間の活動を表す言葉だから成果ではないし、活動を文書化しても意味がない
>何をつくるか、と、どう作るかって全然違うだろ？そのくらいわかるよな
「何をつくるか」という中にある「何」こそが「機能」だよ
言い換えると、作ろうとしている何か(=機能)を具体化する活動が「機能設計」で
その成果が「機能仕様」であり、成果物は１つだけ
文書量に応じて分冊することはあるけど、
その場合は具体的に、たとえばUI設計書やDB設計書として命名する
そうではなく機能設計書と機能仕様書とへ曖昧に分けて呼ぶことは
単にプロジェクトへ混乱を招くだけだと考える
そして「どうつくるか」に該当するのは構造設計になる
また、いくら小規模開発であっても機能設計書と構造設計書を合体させることは、
少なくとも自分のいる/いた現場では非常識だと考えられているよ
>>316で書いたように、機能の「仕様」を定める活動が「設計」だよ
設計は人間の活動を表す言葉だから成果ではないし、活動を文書化しても意味がない
>何をつくるか、と、どう作るかって全然違うだろ？そのくらいわかるよな
「何をつくるか」という中にある「何」こそが「機能」だよ
言い換えると、作ろうとしている何か(=機能)を具体化する活動が「機能設計」で
その成果が「機能仕様」であり、成果物は１つだけ
文書量に応じて分冊することはあるけど、
その場合は具体的に、たとえばUI設計書やDB設計書として命名する
そうではなく機能設計書と機能仕様書とへ曖昧に分けて呼ぶことは
単にプロジェクトへ混乱を招くだけだと考える
そして「どうつくるか」に該当するのは構造設計になる
また、いくら小規模開発であっても機能設計書と構造設計書を合体させることは、
少なくとも自分のいる/いた現場では非常識だと考えられているよ
342 ：仕様書無しさん：2014/04/28(月) 22:22:37.38
設計の成果が仕様？
一生分かり合えないなこいつとは
一生分かり合えないなこいつとは
設計→仕様→PG
こうじゃねーの？
こうじゃねーの？
>設計→仕様→PG
あいまいな要件定義だけをどうにか守ったようなトンデモ仕様のものが
出来上がるのは、これが原因だな。
あいまいな要件定義だけをどうにか守ったようなトンデモ仕様のものが
出来上がるのは、これが原因だな。
デザインパターンってPGレベルの話だよね？
プログラマー板だからな。
仕様を設計することと、機能を設計することは違うんだぜ。
仕様を設計することを機能設計とはいわん。
仕様を設計することを機能設計とはいわん。
①要件定義→②外部設計→③内部設計→④詳細設計→⑤実装
②と③の成果が仕様
②と③の成果が仕様
350 ：仕様書無しさん：2014/04/28(月) 22:45:45.28
仕様と設計をわかっていないやつが多いんだな
例のブランコの絵をコピペしたくなる
本当に客がほしかったものってやつ
例のブランコの絵をコピペしたくなる
本当に客がほしかったものってやつ
>>344
同意。
リクエスト側が出すのが、実現して欲しい事を書いた仕様書(スペック)。
それに対して、実現方法を書いたものが設計書(デザイン)。
客===>SE===>PGが仕様書。
逆方向が設計書。
だから本来はPGも設計書を書くべきだが、
日本では、コーダーとプログラマーが混同されて来たから、設計書の書き方を教えて居ない。
もっとも現在では状況によっては、プログラムソースにアノテーションという形で設計情報を埋め込むのも可。
設計手法が確立している分野、例えば航空機産業では、仕様例=高度10,000mで巡航出来る事===>設計例=レシプロではなくジェットエンジンを使う、とかになる。
同意。
リクエスト側が出すのが、実現して欲しい事を書いた仕様書(スペック)。
それに対して、実現方法を書いたものが設計書(デザイン)。
客===>SE===>PGが仕様書。
逆方向が設計書。
だから本来はPGも設計書を書くべきだが、
日本では、コーダーとプログラマーが混同されて来たから、設計書の書き方を教えて居ない。
もっとも現在では状況によっては、プログラムソースにアノテーションという形で設計情報を埋め込むのも可。
設計手法が確立している分野、例えば航空機産業では、仕様例=高度10,000mで巡航出来る事===>設計例=レシプロではなくジェットエンジンを使う、とかになる。
>>348
仕様は設計するものではなく定義するものじゃね？
仕様は設計するものではなく定義するものじゃね？
日本では詳細設計を書くのはPGの仕事だとされていますがどう思われますか？
ソースは？
データベースの設計だけはしっかりやった方がいい。
358 ：仕様書無しさん：2014/04/29(火) 07:36:39.99
>大抵のPGはまさにその用途で設計書書いてるよ
それは普通のプログラマにはありえんだろう。
プログラマがよそにソースコードを渡す場合、まともに設計図というのが付いてきたら
すごいよ。そんなのはまずいないだろうと思う。
よそにコードを渡さない場合というと社内システムだな。
そこはソースコードだけの世界。設計図があったとしても読まない。
普通のプログラマにはソースコードが設計みたいな思考だから。よって書かれない
設計図は、リファクタリングされ、保守ができやすいようになったところから
生まれていないと、機能を果たさないだろう
後のものが設計図から保守できるところをたぐれるようなやつだな。
後のものが、ソースコードをたぐって解析しているようでは設計図とはいわんだろ。
普通のプログラマが設計図を書けないのは、コードがスパゲッティなんで、
本人にもわからなくなっているよ
他人に読まれることを意識してコードを書けると三流プログラマからの脱出しているのだが、
そこまでいかないな
それは普通のプログラマにはありえんだろう。
プログラマがよそにソースコードを渡す場合、まともに設計図というのが付いてきたら
すごいよ。そんなのはまずいないだろうと思う。
よそにコードを渡さない場合というと社内システムだな。
そこはソースコードだけの世界。設計図があったとしても読まない。
普通のプログラマにはソースコードが設計みたいな思考だから。よって書かれない
設計図は、リファクタリングされ、保守ができやすいようになったところから
生まれていないと、機能を果たさないだろう
後のものが設計図から保守できるところをたぐれるようなやつだな。
後のものが、ソースコードをたぐって解析しているようでは設計図とはいわんだろ。
普通のプログラマが設計図を書けないのは、コードがスパゲッティなんで、
本人にもわからなくなっているよ
他人に読まれることを意識してコードを書けると三流プログラマからの脱出しているのだが、
そこまでいかないな
359 ：仕様書無しさん：2014/04/29(火) 08:02:52.24
俺は制御系だが、そこで目にするスパゲッティなのは盤内配線だな
そこで役立つのは、配線図というやつ。
ＰＧに役立つ設計図というのはこういうふうに役に立つものがほしい。
ソースコードというのは変数だらけ。
で、そこをどう探っていくかを示してくれなきゃ。
それがＰＧに役立つ設計図といえる
そこで役立つのは、配線図というやつ。
ＰＧに役立つ設計図というのはこういうふうに役に立つものがほしい。
ソースコードというのは変数だらけ。
で、そこをどう探っていくかを示してくれなきゃ。
それがＰＧに役立つ設計図といえる
変数なんて見たらわかるだろ。
361 ：仕様書無しさん：2014/04/29(火) 10:23:48.85
>変数なんて見たらわかるだろ。
だろ-、これが一般的なＰＧの反応。一般的なＰＧの立ち位置
コードというのは変数だらけな。ＰＧにとっては、それがあたりまえという世界に住んでいる
で、ぐちゃぐちゃのコードもあたりまえ
だろ-、これが一般的なＰＧの反応。一般的なＰＧの立ち位置
コードというのは変数だらけな。ＰＧにとっては、それがあたりまえという世界に住んでいる
で、ぐちゃぐちゃのコードもあたりまえ
変数が少ないコードの方が怖いわ。
変数は少ないほうが良いけど。
変数という概念が存在しない言語もあるけどね
365 ：仕様書無しさん：2014/04/29(火) 11:30:41.47
【IT】みずほの次期システムは相当ヤバイらしい…新人でもいい、とにかくSEを集めろ！！！
http://hayabusa3.2ch.net/test/read.cgi/news/1398642773/
http://hayabusa3.2ch.net/test/read.cgi/news/1398642773/
>>366
いやいや、変数じゃなく関数で意味を表現したほうが良いってこと
いやいや、変数じゃなく関数で意味を表現したほうが良いってこと
>>363
アセンブラみたいにか
アセンブラみたいにか
369 ：仕様書無しさん：2014/04/29(火) 14:36:08.13
＞いやいや、変数じゃなく関数で意味を表現したほうが良いってこと
コードというのは関数が羅列されているな
たとえばこんなんだ。
GetWoman();
GetKiss();
GetGirls();
で、こうやると関数名に意味付けがあるとかいう
しかし後から見る者にとって、そのコードはGet＊＊だらけとしか映らないのよ
そして、ここにとどまっているかぎり三流プログラマよ
ここから、ソースコードに基づいた設計図をおこせたらプログラマの進歩だ
コードというのは関数が羅列されているな
たとえばこんなんだ。
GetWoman();
GetKiss();
GetGirls();
で、こうやると関数名に意味付けがあるとかいう
しかし後から見る者にとって、そのコードはGet＊＊だらけとしか映らないのよ
そして、ここにとどまっているかぎり三流プログラマよ
ここから、ソースコードに基づいた設計図をおこせたらプログラマの進歩だ
>>369
何が言いたいのかよく解らん
「どうあるべきだ」ってのが示されてないのと、
Get＊＊だらけの何が問題だと考えているのが示されていない。
ちゃんと説明するか、正しいと思えるソース貼るか
もうちょっと意見をわかりやすく書いてくれ。
何が言いたいのかよく解らん
「どうあるべきだ」ってのが示されてないのと、
Get＊＊だらけの何が問題だと考えているのが示されていない。
ちゃんと説明するか、正しいと思えるソース貼るか
もうちょっと意見をわかりやすく書いてくれ。
糞コテはスレタイも読めないのか
372 ：仕様書無しさん：2014/04/29(火) 15:44:46.57
＞何が言いたいのかよく解らん
おまえは、ローカル変数とグローバル変数の違いがわかるか
for(int i = 0; i < 10; i++)){
int a;
a++;
}
変数のiもaも括弧の外では寿命が尽きている。こういうのが寿命が短い変数という
つまりだ、お前は投稿が369,370,371とかわると、話題の寿命が尽きていると映るのではないか
グローバル変数というのが取り上げられていたが、こういうのは寿命がながいやつな
グローバル変数のあつかいにプログラマは悩まされる。
どこでどう変わっているのを把握して行くのが面倒だから。
お前の頭は、長いコードを追いかけていると、プッチンと途切れてしまうから、
グローバル変数みたいなのは使わないほうがいいな。
おまえは、ローカル変数とグローバル変数の違いがわかるか
for(int i = 0; i < 10; i++)){
int a;
a++;
}
変数のiもaも括弧の外では寿命が尽きている。こういうのが寿命が短い変数という
つまりだ、お前は投稿が369,370,371とかわると、話題の寿命が尽きていると映るのではないか
グローバル変数というのが取り上げられていたが、こういうのは寿命がながいやつな
グローバル変数のあつかいにプログラマは悩まされる。
どこでどう変わっているのを把握して行くのが面倒だから。
お前の頭は、長いコードを追いかけていると、プッチンと途切れてしまうから、
グローバル変数みたいなのは使わないほうがいいな。
>>372
名前か何か書かないことには前の発言とのリンクなんて取れんだろ。
名無しで書くなら1レスの中に情報詰めろ。
勝手に>>369と同一人物だと仮定して話をすすめるけど、
また話が飛んでるぞ。
「ローカル変数とグローバル変数の違い」なんてどこから沸いてきたんだ？
「しかし後から見る者にとって、そのコードはGet＊＊だらけとしか映らないのよ」
の話題はどこへ消えたんだ？
名前か何か書かないことには前の発言とのリンクなんて取れんだろ。
名無しで書くなら1レスの中に情報詰めろ。
勝手に>>369と同一人物だと仮定して話をすすめるけど、
また話が飛んでるぞ。
「ローカル変数とグローバル変数の違い」なんてどこから沸いてきたんだ？
「しかし後から見る者にとって、そのコードはGet＊＊だらけとしか映らないのよ」
の話題はどこへ消えたんだ？
842 ： KAC [sage] DATE:2014/04/27(日) 15:04:43.46
>>841
あぁ、基本的にバカは相手しないことにしてるんで、
お前の出没したところでは話が途中で終わってるかもな。
844 ： 仕様書無しさん [sage] DATE:2014/04/27(日) 15:08:25.19
要は論破されて逃げてるだけじゃん
>>841
あぁ、基本的にバカは相手しないことにしてるんで、
お前の出没したところでは話が途中で終わってるかもな。
844 ： 仕様書無しさん [sage] DATE:2014/04/27(日) 15:08:25.19
要は論破されて逃げてるだけじゃん
>>373
>名無しで書くなら1レスの中に情報詰めろ。
2chは名無しが基本だよ
相手が名無しだからという理由でコミュニケーションができないなら、
2chに向いていないってことだ
あと、板違いスレ違いの話をいつまで続ける気だ？
いいかげんにしろ
>名無しで書くなら1レスの中に情報詰めろ。
2chは名無しが基本だよ
相手が名無しだからという理由でコミュニケーションができないなら、
2chに向いていないってことだ
あと、板違いスレ違いの話をいつまで続ける気だ？
いいかげんにしろ
また粘着登場か。死ねばいいのに
378 ：仕様書無しさん：2014/04/29(火) 19:42:34.08
また粘着認定登場か。いちち書かなきゃいいのに。
>>369が何を言いたいのかは分からん。
色んな関数内で同じグローバル変数使うなってこと？
色んな関数内で同じグローバル変数使うなってこと？
ごまかそうとしてアラシてんだからさわっちゃだめ
>>336を繰り返す
>>316だけど、KACからのレスが見当たらないのは
また反論できずに逃げ出したってことでいいのかね？
それとも>>316の冒頭で書いた
「KACは設計書について無知である」という指摘が図星だったから
あわてて逃げ出した、ってことでいいのかな
>>316だけど、KACからのレスが見当たらないのは
また反論できずに逃げ出したってことでいいのかね？
それとも>>316の冒頭で書いた
「KACは設計書について無知である」という指摘が図星だったから
あわてて逃げ出した、ってことでいいのかな
粘着キモイ
>>369
関数型言語の話になるかと思ったら、何この化石みたいな知識で偉そうにうんちく垂れてるバカは(´･_･`)
関数型言語の話になるかと思ったら、何この化石みたいな知識で偉そうにうんちく垂れてるバカは(´･_･`)
384 ：仕様書無しさん：2014/04/30(水) 01:43:27.72
底辺ブラック企業の奴隷とまあまともなIT企業の差が
もろに出てるな
もろに出てるな
385 ：仕様書無しさん：2014/04/30(水) 01:48:37.04
話が不利になると荒らすのは底辺以前の能無し
差分開発だと前の設計書ないと死ねるよな
自分を守るためだなぁ。それ以外に挙げるとしたら外注のためか。
388 ：仕様書無しさん：2014/04/30(水) 20:58:01.67
設計書を書かないプログラマなんて必要ない。
つかプログラマじゃない。
うちは雇用しない。
仕事も出さない。
あたりまえすぎて話にもならないことで
何を遊んでいるんだね？
このスレそのものが愉快なプログラマたちの
ジョークとしか思えないんだが？
つかプログラマじゃない。
うちは雇用しない。
仕事も出さない。
あたりまえすぎて話にもならないことで
何を遊んでいるんだね？
このスレそのものが愉快なプログラマたちの
ジョークとしか思えないんだが？
389 ：仕様書無しさん：2014/04/30(水) 21:08:48.02
要求仕様書とかいいつつロジックレベルで仕様が書かれてる場合は、設計書など納品のために仕方なく書いてるだけだわ
390 ：389：2014/04/30(水) 21:24:53.52
設計書を元にレビューしてもあんまり理解出来てないような雰囲気だし、ここを教えてくれとも言わない。
それでも納品しろとは言われるから確かに必要なものではあるが、設計書なしで同じもの作れと言われたら作れる自信はあるわ
まあ、テストパターンを把握するためのものだな
それでも納品しろとは言われるから確かに必要なものではあるが、設計書なしで同じもの作れと言われたら作れる自信はあるわ
まあ、テストパターンを把握するためのものだな
大規模システムの子請け孫受けで、
検収のために文書が必要な会社（富士通日立NEC。。。）は
文書書けとか騒ぐのかもしれんけど
中規模でとにかく商材ありきで
開発をプログラマの能力に依存してるCMMIレベル２以下の場所は
どこもこんなもんだよ。
CMMIレベル３以上とか絶対うそやで。
そんなもん存在しないよ。
存在してたら日本はもっとソフトが強いはず。
検収のために文書が必要な会社（富士通日立NEC。。。）は
文書書けとか騒ぐのかもしれんけど
中規模でとにかく商材ありきで
開発をプログラマの能力に依存してるCMMIレベル２以下の場所は
どこもこんなもんだよ。
CMMIレベル３以上とか絶対うそやで。
そんなもん存在しないよ。
存在してたら日本はもっとソフトが強いはず。
CMMIの基準ってもっと評価されるべきだよな。
393 ：仕様書無しさん：2014/05/01(木) 00:46:18.42
ドキュメントは、作成した分だけ確実に開発速度が落ちるよ。
ある程度以上の精度を求めると、メンテナンス含めてプログラムと同等かそれ以上のコストがかかってしまう。
だから、お役所系の大規模PJを受ける企業だと、ドキュメント周りだけの仕事があったりするくらい。(閑職だったけど。)
組織や発注がアレだと、設計書のC/Pとか考えること無いんだろうな。
で、アリバイのために作って捨てる設計書が量産されると。
本来は、許される属人性の範囲や開発速度をトレードオフして、必要な分だけ作るべきだと思う。
ある程度以上の精度を求めると、メンテナンス含めてプログラムと同等かそれ以上のコストがかかってしまう。
だから、お役所系の大規模PJを受ける企業だと、ドキュメント周りだけの仕事があったりするくらい。(閑職だったけど。)
組織や発注がアレだと、設計書のC/Pとか考えること無いんだろうな。
で、アリバイのために作って捨てる設計書が量産されると。
本来は、許される属人性の範囲や開発速度をトレードオフして、必要な分だけ作るべきだと思う。
俺は頭の整理のために、要件や会議の記録をもとに
仕様書を書いて、それを元にプログラムを書くよ。
その仕様書はレビューしない。
しても無駄。誰もちゃんと読まないから。
レビュワーにはパワポ10枚くらいで適当に説明して
会議をやった記録だけは残しておく。
ちな大手電機
仕様書を書いて、それを元にプログラムを書くよ。
その仕様書はレビューしない。
しても無駄。誰もちゃんと読まないから。
レビュワーにはパワポ10枚くらいで適当に説明して
会議をやった記録だけは残しておく。
ちな大手電機
制御系、盤内配線なんかスパゲッティじょうたい。でも配線図があれば
すぐ探れる。
同じ制御系の話だが、ＰＣＬの制御をすこしかえるとき、
開発者だったらすぐに直せるのに、ほかの人にやらせると一周間とかかる
といっていた。スパゲッティでも配線図があればすぐわかるのに。
ソースコードを解き明かす、ほかの人でもすぐにわかるように
という設計図がないから。
そこでは、ソースコードが設計図な。
プログラミングできるだけでは、三流ということ。
設計図をつくれたら、三流プログラマからぬけだしているよ
すぐ探れる。
同じ制御系の話だが、ＰＣＬの制御をすこしかえるとき、
開発者だったらすぐに直せるのに、ほかの人にやらせると一周間とかかる
といっていた。スパゲッティでも配線図があればすぐわかるのに。
ソースコードを解き明かす、ほかの人でもすぐにわかるように
という設計図がないから。
そこでは、ソースコードが設計図な。
プログラミングできるだけでは、三流ということ。
設計図をつくれたら、三流プログラマからぬけだしているよ
＞ある程度以上の精度を求めると、メンテナンス含めてプログラムと同等かそれ以上のコストがかかってしまう。
三流プログラマにはわからないかもしれないが、
プログラミングというのはソースコードを生産して
しかし、これを捨てるという作業を行う。
ロジックの変更があったりすると、必要でなくなるルーチンがでたりする
最初に考えたロジックより、中途で変更するということは、合理性のためだ
そういうのをペーパに残しとくのよ。
三流プログラマにはわからないかもしれないが、
プログラミングというのはソースコードを生産して
しかし、これを捨てるという作業を行う。
ロジックの変更があったりすると、必要でなくなるルーチンがでたりする
最初に考えたロジックより、中途で変更するということは、合理性のためだ
そういうのをペーパに残しとくのよ。
ソースコードが汚くていいとは思わないよ。
ネストは浅くして
コマンド毎の応答処理への分岐部分なんかは
馬鹿でもわかるように
スイッチケース文で箇条書きにする。
人間は時系列で物事を考えるのが一番得意だから
それに合わせて書いてやるのが一番良い。
割り込みやマルチスレッドは必要な場合に使うべき。
ネストは浅くして
コマンド毎の応答処理への分岐部分なんかは
馬鹿でもわかるように
スイッチケース文で箇条書きにする。
人間は時系列で物事を考えるのが一番得意だから
それに合わせて書いてやるのが一番良い。
割り込みやマルチスレッドは必要な場合に使うべき。
＞ネストは浅くして コマンド毎の応答処理への分岐部分なんかは
＞馬鹿でもわかるように スイッチケース文で箇条書きにする。
そから先があるわけ、設計書を作る作業だな。
画面描画のソースコードがひとかたまり、
ファイル処理のコードがひとかたまり。
そうなっていないと設計図をおこせない
ファイル処理があっちにあり、こっちにあるというのがいけない
＞馬鹿でもわかるように スイッチケース文で箇条書きにする。
そから先があるわけ、設計書を作る作業だな。
画面描画のソースコードがひとかたまり、
ファイル処理のコードがひとかたまり。
そうなっていないと設計図をおこせない
ファイル処理があっちにあり、こっちにあるというのがいけない
>>394
それは、正しいドキュメントを見たことがないんだよ。
適切なドキュメントを作成しながら作業を進めれば、開発工数は、半分にも1/3にもなる。
デスマの多くは、上流担当者のドキュメント作成能力の欠如に起因してる。
まあ、しかし実際に書けるやつが全然いないんで、
もうドキュメントに期待しない開発方法の方が主流になってきてるがな。
それは、正しいドキュメントを見たことがないんだよ。
適切なドキュメントを作成しながら作業を進めれば、開発工数は、半分にも1/3にもなる。
デスマの多くは、上流担当者のドキュメント作成能力の欠如に起因してる。
まあ、しかし実際に書けるやつが全然いないんで、
もうドキュメントに期待しない開発方法の方が主流になってきてるがな。
過剰なドキュメントは足がかりじゃなく足枷になるな。
ソースコード以外のドキュメントは補足に過ぎない事を念頭に書くべき。
あと設計者はモジュールのインターフェースとテストコードぐらいは書くべき。
それらは活きた仕様書になる。
ソースコード以外のドキュメントは補足に過ぎない事を念頭に書くべき。
あと設計者はモジュールのインターフェースとテストコードぐらいは書くべき。
それらは活きた仕様書になる。
なるかよ
>>397
顧客との間に証跡として残すドキュメントなら同意。
内部のコミュニケーションのためというならお前の方が三流だ。
ある程度以上の精度でドキュメント起こすなんて、実質自然言語とプログラム言語の両方で設計するようなもの。
理想像に近づくまでスクラップ＆ビルドする間、設計書分のオーバーヘッドが乗っかるんだぞ？
関係者の合意形成が済んでるなら、完全に無駄コストじゃねえか。
例外は、実装コストが高すぎる場合と、ビジネスロジックが密で複雑になる場合くらい。
そうでなければ、設計書作る工数でテスト書くべき。
第一、どうやってソースと設計書を同期取るんだよ。
余程工数があって温い環境なんだろうな。
>>400
正しいドキュメントって何？
設計書が無くて困る場合って、大体は人間同士(顧客や開発者、運用担当者)の摺りあわせ不足だろ。
極端な話、関係者全員に必要な情報が行き渡り、滞りなく合意形成と記録が行われているならドキュメントなんて無くてもシステムは作れるし、運用も回るんじゃないか？
設計書の効力って、正直技術的妥当性よりも政治的な部分が大きいと思うんだ。
顧客との間に証跡として残すドキュメントなら同意。
内部のコミュニケーションのためというならお前の方が三流だ。
ある程度以上の精度でドキュメント起こすなんて、実質自然言語とプログラム言語の両方で設計するようなもの。
理想像に近づくまでスクラップ＆ビルドする間、設計書分のオーバーヘッドが乗っかるんだぞ？
関係者の合意形成が済んでるなら、完全に無駄コストじゃねえか。
例外は、実装コストが高すぎる場合と、ビジネスロジックが密で複雑になる場合くらい。
そうでなければ、設計書作る工数でテスト書くべき。
第一、どうやってソースと設計書を同期取るんだよ。
余程工数があって温い環境なんだろうな。
>>400
正しいドキュメントって何？
設計書が無くて困る場合って、大体は人間同士(顧客や開発者、運用担当者)の摺りあわせ不足だろ。
極端な話、関係者全員に必要な情報が行き渡り、滞りなく合意形成と記録が行われているならドキュメントなんて無くてもシステムは作れるし、運用も回るんじゃないか？
設計書の効力って、正直技術的妥当性よりも政治的な部分が大きいと思うんだ。
逆に言えば、設計書が無ければいちいち人間同士の摺り合わせから行わないといけないということ
摺り合わせた結果を設計書として残しておけば、設計書に従って作業ができるのに。
摺り合わせた結果を設計書として残しておけば、設計書に従って作業ができるのに。
設計書と一言でいうがどのレベルを指しているのか、システムの規模はどの程度なのか。
これを明確にしないで話しても意味ないと思うんだが…
これを明確にしないで話しても意味ないと思うんだが…
>>407
規模によって変わる物って、具体的には？
規模によって変わる物って、具体的には？
＞理想像に近づくまでスクラップ＆ビルドする間、設計書分のオーバーヘッドが乗っかるんだぞ？
理想像というのを、設計図を起こせるよな、というところに置いておくといいよ
動きゃいい、というところにとどまっていると三流プログラマ
俺は二時間で書き上げたぞ、と自己満足しているやつも、そう。
理想像というのを、設計図を起こせるよな、というところに置いておくといいよ
動きゃいい、というところにとどまっていると三流プログラマ
俺は二時間で書き上げたぞ、と自己満足しているやつも、そう。
410 ：仕様書無しさん：2014/05/02(金) 11:52:52.06
社内向けには、引継ぎ用の詳細仕様書（手書きでもいい、客に見せない）
そして偉い人用のかいつまんで説明したパワポ
客用には外見の動作を記述した納入仕様書
納品用と設計用を一緒にしようとおもったこともあるが
無駄であっても2つは分離したほうがいい。
設計用に書いたドキュメントを、
ある程度設計が固まった時点で納品用に分岐させて詳細部分を消してる。
そして偉い人用のかいつまんで説明したパワポ
客用には外見の動作を記述した納入仕様書
納品用と設計用を一緒にしようとおもったこともあるが
無駄であっても2つは分離したほうがいい。
設計用に書いたドキュメントを、
ある程度設計が固まった時点で納品用に分岐させて詳細部分を消してる。
設計を念頭できないＰＧ
＞第一、どうやってソースと設計書を同期取るんだよ。
＞余程工数があって温い環境なんだろうな。
設計ということを念頭におけれるＰＧ
＞どういう形にするかはポンチ絵レベルでも普通書くだろ。
＞荒く書くところ詳細に書くところ緩急つけてコードと絵をラウンドトリップしながらブラッシュアップするだけ。
＞第一、どうやってソースと設計書を同期取るんだよ。
＞余程工数があって温い環境なんだろうな。
設計ということを念頭におけれるＰＧ
＞どういう形にするかはポンチ絵レベルでも普通書くだろ。
＞荒く書くところ詳細に書くところ緩急つけてコードと絵をラウンドトリップしながらブラッシュアップするだけ。
複数人で開発する場合のことを考えてみろ。
全く設計書が存在しない場合、コミュニケーションコストは増大し、現場はカオスになることは目に見えている。
そこに、ちょっとした設計情報（整ったドキュメント出なくともよい）が投入されれば、その合意情報分の
コミュニケーションコストは減り、誤ったコードも少し減り、誤ったテストも少し減るだろう。
もう少しましな設計情報が投入されれば、もう少し開発全体のコストが下がる。
ただし、投入する設計情報を増やせば増やすほど、開発全体のコストが下がるかというとそうではなく、
どこかの時点で再びコストが増大し始める。
この境目あたりのまでの分量の設計情報であれば有用。
全く設計書が存在しない場合、コミュニケーションコストは増大し、現場はカオスになることは目に見えている。
そこに、ちょっとした設計情報（整ったドキュメント出なくともよい）が投入されれば、その合意情報分の
コミュニケーションコストは減り、誤ったコードも少し減り、誤ったテストも少し減るだろう。
もう少しましな設計情報が投入されれば、もう少し開発全体のコストが下がる。
ただし、投入する設計情報を増やせば増やすほど、開発全体のコストが下がるかというとそうではなく、
どこかの時点で再びコストが増大し始める。
この境目あたりのまでの分量の設計情報であれば有用。
>>413
設計書にコード実装例が書いていなければ
どっちみちカオスになるよ。
少なくとも、CRUDを備えた機能
一式の（無駄のない）コードが必要。
これがなければ、てんでバラバラのコードになるし
同じ機能をそれぞれが作っちゃうから
誤ったコードもテストも大きく増えてしまう。
設計書にコード実装例が書いていなければ
どっちみちカオスになるよ。
少なくとも、CRUDを備えた機能
一式の（無駄のない）コードが必要。
これがなければ、てんでバラバラのコードになるし
同じ機能をそれぞれが作っちゃうから
誤ったコードもテストも大きく増えてしまう。
>>408
俺は>>407ではないが、例えば一日以内にで誰でも作れて
それでいて客の業務に深い影響がなく、金を取れる受注。
こんなの特にインタプリタなら設計書作る方がバカレベルだと思うね。
俺なら絶対ソースのバックアップ以外残さない。
俺は>>407ではないが、例えば一日以内にで誰でも作れて
それでいて客の業務に深い影響がなく、金を取れる受注。
こんなの特にインタプリタなら設計書作る方がバカレベルだと思うね。
俺なら絶対ソースのバックアップ以外残さない。
っていうか、そのレベルの設計書が無いと
> これがなければ、てんでバラバラのコードになるし
> 同じ機能をそれぞれが作っちゃうから
みたいになるって、レベル低すぎじゃないの？
> これがなければ、てんでバラバラのコードになるし
> 同じ機能をそれぞれが作っちゃうから
みたいになるって、レベル低すぎじゃないの？
>>414
共通化しろよ。テンプレートメソッドでもいいし。
共通化しろよ。テンプレートメソッドでもいいし。
ははｗ やっぱこのレベルだ。
たかが設計書どまりで
コードの質が安定すると思ってやがる。
そんなので安定してたら
人によって10倍以上も差がつくかよ。
たかが設計書どまりで
コードの質が安定すると思ってやがる。
そんなので安定してたら
人によって10倍以上も差がつくかよ。
>>421
設計書がなければ、人によって100倍以上差がつくんだけどな
設計書がなければ、人によって100倍以上差がつくんだけどな
>>422
差が付く要因は何？
俺は実装者の力量や、関係者間のコミュニケーションの不足だと思う。
これらは設計書書くことでもある程度対処できるが、効率が悪すぎるんだよ。
設計書なんて、合意形成の証跡だけ残せば要らないことが多い。
設計意図なんて、ソースのコメントやテストとして残すべきだろう。
一覧性が無いなら、社内wiki辺りに全体像だけ書けばいい。
自社開発かつ性善説で仕組みを作れる組織に限るだろうけど、どうしてそこまで設計書を求めるのか解らない。
差が付く要因は何？
俺は実装者の力量や、関係者間のコミュニケーションの不足だと思う。
これらは設計書書くことでもある程度対処できるが、効率が悪すぎるんだよ。
設計書なんて、合意形成の証跡だけ残せば要らないことが多い。
設計意図なんて、ソースのコメントやテストとして残すべきだろう。
一覧性が無いなら、社内wiki辺りに全体像だけ書けばいい。
自社開発かつ性善説で仕組みを作れる組織に限るだろうけど、どうしてそこまで設計書を求めるのか解らない。
>>425
コストが高すぎるから｡
初期コストはそうでもないが、もろもろのメンテナンスコストが膨大すぎる。
メンテナンスしないなら、作らないほうがまだマシだし。
設計書書くしかないなら仕方ないけど、他の方法で目的が満たせるなら作らずに済ませたいよ。
コストが高すぎるから｡
初期コストはそうでもないが、もろもろのメンテナンスコストが膨大すぎる。
メンテナンスしないなら、作らないほうがまだマシだし。
設計書書くしかないなら仕方ないけど、他の方法で目的が満たせるなら作らずに済ませたいよ。
＞設計書書くしかないなら仕方ないけど、他の方法で目的が満たせるなら作らずに済ませたいよ。
書くしかないって。でもってコードの書き直し。
ソースコードの構造を変える。
画面の描画をひとまとめにするとか。
描画ルーチンだけがタイマーで回っているとうように
ほかのクラスは表示変数をかえているだけ。
リアルタイムに表示をしない、ということ。
書くしかないって。でもってコードの書き直し。
ソースコードの構造を変える。
画面の描画をひとまとめにするとか。
描画ルーチンだけがタイマーで回っているとうように
ほかのクラスは表示変数をかえているだけ。
リアルタイムに表示をしない、ということ。
>>427
で、そのポンチ絵はメンテナンスするのか？
周囲の状況が変わる度に、経年劣化するだろろ？
問題は、伝える道具の種類よりも、その維持にかかるコストなんだよ。
説明の都度ポンチ絵書くような状況を、設計書が存在するって言えるか？
>>428
テストコード+CIじゃだめなのか？
で、そのポンチ絵はメンテナンスするのか？
周囲の状況が変わる度に、経年劣化するだろろ？
問題は、伝える道具の種類よりも、その維持にかかるコストなんだよ。
説明の都度ポンチ絵書くような状況を、設計書が存在するって言えるか？
>>428
テストコード+CIじゃだめなのか？
431 ：405=426=429：2014/05/02(金) 20:08:32.48
ああ、IDないんだっけここ。
詳細設計書が無いと、テストの適合性が客観的にわからんと思うのだが。
設計書不要って人はテスト仕様書を別に作ってるとか？
設計書不要って人はテスト仕様書を別に作ってるとか？
>>429
必要ならメンテすればいいだけ。
お前も必要だからコメントをメンテしてるんだろ？
コードとの距離がコメントより遠くなるからメンテされなくなる可能性が高くなるのはわかるが。
折角だから聞いとくわ。
・お前にとって文章やコードで書くよりも図で描いた方がわかりやすいことは一つもないのか？
・あるのならどうするんだ？エクセル方眼紙並みにコメント使って絵を描くのか？
それがしやすいツールあるならコードとの距離も近くなっていいから教えてくれ。
必要ならメンテすればいいだけ。
お前も必要だからコメントをメンテしてるんだろ？
コードとの距離がコメントより遠くなるからメンテされなくなる可能性が高くなるのはわかるが。
折角だから聞いとくわ。
・お前にとって文章やコードで書くよりも図で描いた方がわかりやすいことは一つもないのか？
・あるのならどうするんだ？エクセル方眼紙並みにコメント使って絵を描くのか？
それがしやすいツールあるならコードとの距離も近くなっていいから教えてくれ。
>>432
作ってる。むしろ設計書よりそっちのほうが重要。
自動テストで対応できるなら、その方が良いけどな。
>>433
> ・お前にとって文章やコードで書くよりも図で描いた方がわかりやすいことは一つもないのか？
ある。
> ・あるのならどうするんだ？エクセル方眼紙並みにコメント使って絵を描くのか？
ホワイトボードに書く。で、その場で説明して終わり。
メンテすればいいと簡単に言うが、コスト対効果を考えてみろよ。
ソフトに改修入る時の影響度調査は？機械的に調査できないんだから、かなりの範囲を確認することになるんだぜ？
大幅改修が入ったときの維持ポリシーは？現状維持とか言われたら、同程度の複雑さの設計、全部図に起こすことになるんだぜ？
余程工数があったり、関係者が多いところなら別かもしれないが、掛けたコストをペイしないだろう。
>それがしやすいツールあるならコードとの距離も近くなっていいから教えてくれ。
残念ながら、実用に耐えるものは知らない。
プログラム言語とそれ以外の表現方法との差が埋まらないから、結局何処かに無駄なコミュニケーションコストが発生する。
作ってる。むしろ設計書よりそっちのほうが重要。
自動テストで対応できるなら、その方が良いけどな。
>>433
> ・お前にとって文章やコードで書くよりも図で描いた方がわかりやすいことは一つもないのか？
ある。
> ・あるのならどうするんだ？エクセル方眼紙並みにコメント使って絵を描くのか？
ホワイトボードに書く。で、その場で説明して終わり。
メンテすればいいと簡単に言うが、コスト対効果を考えてみろよ。
ソフトに改修入る時の影響度調査は？機械的に調査できないんだから、かなりの範囲を確認することになるんだぜ？
大幅改修が入ったときの維持ポリシーは？現状維持とか言われたら、同程度の複雑さの設計、全部図に起こすことになるんだぜ？
余程工数があったり、関係者が多いところなら別かもしれないが、掛けたコストをペイしないだろう。
>それがしやすいツールあるならコードとの距離も近くなっていいから教えてくれ。
残念ながら、実用に耐えるものは知らない。
プログラム言語とそれ以外の表現方法との差が埋まらないから、結局何処かに無駄なコミュニケーションコストが発生する。
コードを書く前に設計レビューしたほうが、結果的に戻り作業が少ない
設計レビューするには、設計意図を伝える最低限の資料が必要
チームで開発してたらそうあるべき
自動生成レベルの納品物としての設計書しか知らない奴は可哀想
あれはマジで意味ないからな
設計レビューするには、設計意図を伝える最低限の資料が必要
チームで開発してたらそうあるべき
自動生成レベルの納品物としての設計書しか知らない奴は可哀想
あれはマジで意味ないからな
>>434
>ソフトに改修入る時の影響度調査は？機械的に調査できないんだから、かなりの範囲を確認することになるんだぜ？
>大幅改修が入ったときの維持ポリシーは？現状維持とか言われたら、同程度の複雑さの設計、全部図に起こすことになるんだぜ？
何で全体の構造わかるようなポンチ絵かけばいいってんのに、影響範囲とか全部図に起こすとかなんのよ。
改修入るなら新しい構造のポンチ絵描くだけ。そこにざっくり前とどう違うか何で変えるかなどの補足情報があればなをよし。
何をどう捉えてるのか知らんがお前が全ての情報をコンパイルできるソースコードとテストコードに落としてるなら分かるがコメントやWIKIにかいてる時点で論理なりたたんだろ。それらも話し同様だろ。
>ソフトに改修入る時の影響度調査は？機械的に調査できないんだから、かなりの範囲を確認することになるんだぜ？
>大幅改修が入ったときの維持ポリシーは？現状維持とか言われたら、同程度の複雑さの設計、全部図に起こすことになるんだぜ？
何で全体の構造わかるようなポンチ絵かけばいいってんのに、影響範囲とか全部図に起こすとかなんのよ。
改修入るなら新しい構造のポンチ絵描くだけ。そこにざっくり前とどう違うか何で変えるかなどの補足情報があればなをよし。
何をどう捉えてるのか知らんがお前が全ての情報をコンパイルできるソースコードとテストコードに落としてるなら分かるがコメントやWIKIにかいてる時点で論理なりたたんだろ。それらも話し同様だろ。
末端作業員しかいないなｗ設計書ってのは自分を守るためのもんだよ。
自分を守るとかそういう本来の目的から外れた事を考えたくないから
サラリーマンになりたくないんだよ
サラリーマンになりたくないんだよ
>>434
設計をちゃんとやって、結果を残さないのはもったいないぞ。
ホワイトボードに書いて説明したとしても、正しく伝わっている保証はない。
伝えた相手に設計書を書かせてレビューすると伝わりきってないことに気がつくぞ。
メンテナンスや類似開発のときに参照もできるから、残す方がトータルコストは安くなる。
メンテナンスに工数がかかるというのは、後で設計が変更されるということだよな。
それは設計バグであり、設計段階で取り去るべき問題が出てるだけ。
対応としては設計書を諦めるんじゃなくて、設計書を書く段階でバグを取り去る努力をすべき。
結果として後工程でのバグが減って、トータルコストは下がる。
設計をちゃんとやって、結果を残さないのはもったいないぞ。
ホワイトボードに書いて説明したとしても、正しく伝わっている保証はない。
伝えた相手に設計書を書かせてレビューすると伝わりきってないことに気がつくぞ。
メンテナンスや類似開発のときに参照もできるから、残す方がトータルコストは安くなる。
メンテナンスに工数がかかるというのは、後で設計が変更されるということだよな。
それは設計バグであり、設計段階で取り去るべき問題が出てるだけ。
対応としては設計書を諦めるんじゃなくて、設計書を書く段階でバグを取り去る努力をすべき。
結果として後工程でのバグが減って、トータルコストは下がる。
>>439
自営でもかわんねーよ。
自営でもかわんねーよ。
>>423
お前も気づいているだろうが、設計書なしのプロジェクトなんて
・システムについて熟知しているメンテナーが常に存在する
・新しく入ったメンバーがシステムを学ぶ間の
コミュニケーションコストは考慮しなくてよい
などの条件が揃った稀なケースでしか成立しないんだよ。
お前も気づいているだろうが、設計書なしのプロジェクトなんて
・システムについて熟知しているメンテナーが常に存在する
・新しく入ったメンバーがシステムを学ぶ間の
コミュニケーションコストは考慮しなくてよい
などの条件が揃った稀なケースでしか成立しないんだよ。
>>440
「メンテナンスや類似開発のときに参照もできる」ように作成・管理するのはかなりコストがかかるだろう。一つのプロジェクトに押し込めないくらいの。
結果、ただの雛形になったりコピペで済ましちゃったりが現れる弊害があると思うんだが、KAC界隈ではその辺の環境が整備されているということか？
「メンテナンスや類似開発のときに参照もできる」ように作成・管理するのはかなりコストがかかるだろう。一つのプロジェクトに押し込めないくらいの。
結果、ただの雛形になったりコピペで済ましちゃったりが現れる弊害があると思うんだが、KAC界隈ではその辺の環境が整備されているということか？
補足すると、再利用の為のコストが決して余計だとは思わないし、
記録を残すことは重要なのは理解している。
ただ、その思想がきちんと引き継がれないと意味がないし、
ここいらでは結果的に前ドキュメントのコピペで済まされて肝心な情報がなにもない記録が溢れてしまっている。
「必要なものを必要なだけ作ったものを記録」する環境が整っていないのさ。
で、KAC界隈ではどうやってるんだろうかと伺っている。
記録を残すことは重要なのは理解している。
ただ、その思想がきちんと引き継がれないと意味がないし、
ここいらでは結果的に前ドキュメントのコピペで済まされて肝心な情報がなにもない記録が溢れてしまっている。
「必要なものを必要なだけ作ったものを記録」する環境が整っていないのさ。
で、KAC界隈ではどうやってるんだろうかと伺っている。
>>429
ポンチ絵のメンテナンスにコストがかかるのは、
ポンチ絵書くのが下手な可能性が高い。
ポンチ絵に必要以上に実装に関わる情報を記載してしまうと、
実装が少し変わるだけで剥離が起きてしまって「つかえねー」と判断される。
ポンチ絵のメンテナンスにコストがかかるのは、
ポンチ絵書くのが下手な可能性が高い。
ポンチ絵に必要以上に実装に関わる情報を記載してしまうと、
実装が少し変わるだけで剥離が起きてしまって「つかえねー」と判断される。
>>447
ごめ、前後したな。
「統一された書式」ってのがきちんとしてるんだね。
ここいらで統一された書式っていうと、Excel方眼の納品物で、
いつから使ってるのかわからない上に必要な情報がまるでないものに
なってしまっててさ。
で、「統一された書式」にコストがかかるだろうに、って思った。
ごめ、前後したな。
「統一された書式」ってのがきちんとしてるんだね。
ここいらで統一された書式っていうと、Excel方眼の納品物で、
いつから使ってるのかわからない上に必要な情報がまるでないものに
なってしまっててさ。
で、「統一された書式」にコストがかかるだろうに、って思った。
>>446
いや、設計は当然やるしソース以外でも話はできると思う。
名前つけてないから憶測になるが、434と同一人物だと思う。(違ったらごめん)
ただ>>423は、それを設計書として残すコストがかかりすぎて
それを使うメリットよりもコストが悪化する要因になるって意見を述べている。
いまは「そんなにかからんだろ」って話に、「いやいやかかるだろ」って状態だから、
>>446の意見はちょっと外してる。
いや、設計は当然やるしソース以外でも話はできると思う。
名前つけてないから憶測になるが、434と同一人物だと思う。(違ったらごめん)
ただ>>423は、それを設計書として残すコストがかかりすぎて
それを使うメリットよりもコストが悪化する要因になるって意見を述べている。
いまは「そんなにかからんだろ」って話に、「いやいやかかるだろ」って状態だから、
>>446の意見はちょっと外してる。
>>450
確かに書式がなくて各自が好き勝手に書いてたら
メンテナンスとか再利用とかは難しいと思う。
まあ、敢えてそういう方針でメンテナンス性よりも
出荷速度なんかを優先するのもアリだとは思う。
その場合は、設計書なんて作ってられるかと言ってもいいとは思う。
けど、やっぱり一般的な話としては
「設計書はちゃんと作った方が良い」と言いたいところ。
確かに書式がなくて各自が好き勝手に書いてたら
メンテナンスとか再利用とかは難しいと思う。
まあ、敢えてそういう方針でメンテナンス性よりも
出荷速度なんかを優先するのもアリだとは思う。
その場合は、設計書なんて作ってられるかと言ってもいいとは思う。
けど、やっぱり一般的な話としては
「設計書はちゃんと作った方が良い」と言いたいところ。
書けないのに
言いたいんだ
言いたいんだ
454 ：仕様書無しさん：2014/05/03(土) 07:37:52.28
＞ソフトに改修入る時の影響度調査は？機械的に調査できないんだから、かなりの範囲を確認することになるんだぜ？
大幅改修が入ったときの維持ポリシーは？現状維持とか言われたら、同程度の複雑さの設計、全部図に起こすことになるんだぜ？
客先にシステムを導入できたとしよう。一年後にまた注文が来る
するとだな、追加の仕様とか変更とかある。でバージョンアップしていく
作り手のほうも、一回目より、二回目のほうがうまくできる。
一回目はトライアルなのが、二回目は洗練されているとおもうのではないか
ソフトに限らず、機械設計でもそういう。
そういうときがソースコードの改変のチャンス。
また受注がくる、というのが続く、そうするとき、視点が変わってくる、保守しやすい作り方というように
じじいになったお前でなく、後輩がひきつげれるようにとな
大幅改修が入ったときの維持ポリシーは？現状維持とか言われたら、同程度の複雑さの設計、全部図に起こすことになるんだぜ？
客先にシステムを導入できたとしよう。一年後にまた注文が来る
するとだな、追加の仕様とか変更とかある。でバージョンアップしていく
作り手のほうも、一回目より、二回目のほうがうまくできる。
一回目はトライアルなのが、二回目は洗練されているとおもうのではないか
ソフトに限らず、機械設計でもそういう。
そういうときがソースコードの改変のチャンス。
また受注がくる、というのが続く、そうするとき、視点が変わってくる、保守しやすい作り方というように
じじいになったお前でなく、後輩がひきつげれるようにとな
＞補足すると、再利用の為のコストが決して余計だとは思わないし、 記録を残すことは重要なのは理解している。
ただ、その思想がきちんと引き継がれないと意味がないし、
おれは自分で書いたソースコードを一年後に読めない自信がある
どういう処理だったろうかーと思うだろう
ソースコードを見ながら、
Case文でbreak；を書き落としているとき
バグかもしれないとつぶやく
やがて、それはわざと落としていたことに気づく
ただ、その思想がきちんと引き継がれないと意味がないし、
おれは自分で書いたソースコードを一年後に読めない自信がある
どういう処理だったろうかーと思うだろう
ソースコードを見ながら、
Case文でbreak；を書き落としているとき
バグかもしれないとつぶやく
やがて、それはわざと落としていたことに気づく
無駄な設計書は無駄<==単なるトートロジー。
設計書無しだぜ！<==アノテーションすら無いなら、toyレベルなので設計情報は不要。
自明だな。
設計書無しだぜ！<==アノテーションすら無いなら、toyレベルなので設計情報は不要。
自明だな。
>>452
＞>>450
＞確かに書式がなくて各自が好き勝手に書いてたら
＞メンテナンスとか再利用とかは難しい
(中略)
＞出荷速度なんかを優先するのもアリだとは思う。
両立させる為のルールには、例えばSysMLなどが有る。
あと、小規模PGでは設計情報無しで凌げても、大規模になると破綻する。
趣味のレベルを脱したいなら、小規模の案件の時からセルフトレーニング。
＞>>450
＞確かに書式がなくて各自が好き勝手に書いてたら
＞メンテナンスとか再利用とかは難しい
(中略)
＞出荷速度なんかを優先するのもアリだとは思う。
両立させる為のルールには、例えばSysMLなどが有る。
あと、小規模PGでは設計情報無しで凌げても、大規模になると破綻する。
趣味のレベルを脱したいなら、小規模の案件の時からセルフトレーニング。
>>454
で、その後輩は古びた設計書と変わり果てた姿のシステムを目にした上で、調査に明け暮れる訳だな。
当然、納期は設計書を前提にひかれたまま。
何度も言うが、メンテナンスされてないドキュメントなら無い方がマシ。
お前は、実態とはまるで別物となった設計書を引き継いで一から作り直したことはないのか？
設計書肯定の意見って、実装前に設計を見える化したいからって理由ばかりだよな。
リリースしたら終わりで、運用やったこと無い奴しか居ないのか？
実装開始時やリリース前に設計書の更新止まるなら、ホワイトボードに書くのとあまり差が無いだろ。
ここ見てる奴らに是非聞きたい。
お前らの組織では、リリース時orリリース後に設計書を実態に合わ続ける作業を誰がやってるんだ？
で、その後輩は古びた設計書と変わり果てた姿のシステムを目にした上で、調査に明け暮れる訳だな。
当然、納期は設計書を前提にひかれたまま。
何度も言うが、メンテナンスされてないドキュメントなら無い方がマシ。
お前は、実態とはまるで別物となった設計書を引き継いで一から作り直したことはないのか？
設計書肯定の意見って、実装前に設計を見える化したいからって理由ばかりだよな。
リリースしたら終わりで、運用やったこと無い奴しか居ないのか？
実装開始時やリリース前に設計書の更新止まるなら、ホワイトボードに書くのとあまり差が無いだろ。
ここ見てる奴らに是非聞きたい。
お前らの組織では、リリース時orリリース後に設計書を実態に合わ続ける作業を誰がやってるんだ？
>で、その後輩は古びた設計書と変わり果てた姿のシステムを目にした上で、調査に明け暮れる訳だな。
後輩は古びた黄色く変色した紙にあるブロック図と
今はもはもう廃盤になったＮＥＣ98のＩ/Ｏインターフェースと
ＶＢのソースがあるわけだな
そいうのは一から作り直したほうがいいな。ＮＥＣ98を保守できる人が今もっているよ
その人がいなくなったらどうするんだろうな、とおもう
そのよこで、これはいただきとＷindowｓ７のを作って収める
あいてもなかなかのもので俺のをコピーする。
俺のを勝手にコピーするな！ とやっているのだが
後輩は古びた黄色く変色した紙にあるブロック図と
今はもはもう廃盤になったＮＥＣ98のＩ/Ｏインターフェースと
ＶＢのソースがあるわけだな
そいうのは一から作り直したほうがいいな。ＮＥＣ98を保守できる人が今もっているよ
その人がいなくなったらどうするんだろうな、とおもう
そのよこで、これはいただきとＷindowｓ７のを作って収める
あいてもなかなかのもので俺のをコピーする。
俺のを勝手にコピーするな！ とやっているのだが
>>458
だからお前のところで文書メンテの工数設けてないだけじゃん。
ソースを見れば分かる様なもの、テストの方がチェックしやすいものはそっちでやって、ソースやコメントに書きにくいものをラフに描いたりしておけば良いだけ。
なんでその加減が分からんのかマジで分からん。
だからお前のところで文書メンテの工数設けてないだけじゃん。
ソースを見れば分かる様なもの、テストの方がチェックしやすいものはそっちでやって、ソースやコメントに書きにくいものをラフに描いたりしておけば良いだけ。
なんでその加減が分からんのかマジで分からん。
斧の切れ味に興味がある会社なんて、業務系では上から下までで見たことない。
工数割いてくれるのは自社開発限定なのか？
工数割いてくれるのは自社開発限定なのか？
自社でも派遣先でも文書メンテの工数あったよ
というか大手メーカーだと文書メンテ専門部隊いたよ
噂に聞いてた仕様スペシャリストもいたし
やっぱ大手はすげーな
というか大手メーカーだと文書メンテ専門部隊いたよ
噂に聞いてた仕様スペシャリストもいたし
やっぱ大手はすげーな
>やっぱ大手はすげーな
文書の中を見てごらん、すごくないから。昔ながらのしきたりと
ソースコードも書かずに小さくなった脳みそのＳＥの作文
俺の根拠は「ソフトウェア設計｣というたぐいの書籍にある。
ここでとりあげられたが、アホが読むものといわれていた
そんなレベルということね
文書の中を見てごらん、すごくないから。昔ながらのしきたりと
ソースコードも書かずに小さくなった脳みそのＳＥの作文
俺の根拠は「ソフトウェア設計｣というたぐいの書籍にある。
ここでとりあげられたが、アホが読むものといわれていた
そんなレベルということね
一番馬鹿なのが、何度も設計をしなおすやつ。
プログラマに指摘されるのはもう最悪。
一回で設計をきちんと書け。
プログラマに指摘されるのはもう最悪。
一回で設計をきちんと書け。
>>458
> 何度も言うが、メンテナンスされてないドキュメントなら無い方がマシ。
無いよりはあった方がマシ。
バージョン違いの設計書しかなくても、
どんな思想で作られてるか・大まかなモジュール構造がどうなってるか
を理解してるだけで作業効率が全然違う。
> お前は、実態とはまるで別物となった設計書を引き継いで一から作り直したことはないのか？
おまえは、設計書が全くないコードを引き継いで一から設計起こしたこと無いだろ。
> 何度も言うが、メンテナンスされてないドキュメントなら無い方がマシ。
無いよりはあった方がマシ。
バージョン違いの設計書しかなくても、
どんな思想で作られてるか・大まかなモジュール構造がどうなってるか
を理解してるだけで作業効率が全然違う。
> お前は、実態とはまるで別物となった設計書を引き継いで一から作り直したことはないのか？
おまえは、設計書が全くないコードを引き継いで一から設計起こしたこと無いだろ。
>>467
キングファイル数百冊を全員把握してろと？ 全部を把握するのが無理だし
無駄が多いから分業するようになっているわけで。 問題は全体や他所との
つなぎ部分を把握しなければならないのまで細部しか見てないことだよな。
キングファイル数百冊を全員把握してろと？ 全部を把握するのが無理だし
無駄が多いから分業するようになっているわけで。 問題は全体や他所との
つなぎ部分を把握しなければならないのまで細部しか見てないことだよな。
分が悪くなると極論に逃げるのは基地外の基本。
金融系や何十年も続いてるのだと普通にあるぞ。ピーク時に100人月超えるような
プロジェクトなんかだと数百は言い過ぎでも数十～百数十位になるし。
納品の時に実際に印刷して呆れた記憶があるよ。
プロジェクトなんかだと数百は言い過ぎでも数十～百数十位になるし。
納品の時に実際に印刷して呆れた記憶があるよ。
今更だけど設計書と仕様書って何が違うの？
>>458
> メンテナンスされてないドキュメントなら無い方がマシ。
↑たとえメンテナンスされていなくても、あったほうがいいぞ。
設計書ってのは、設計担当者が何をしたかったのかが書かれている物だ。
ソースから意図を汲み取るよりも、そういう資料があった方が背景を理解しやすい。
メンテナンスについての情報だったり、そもそもの考え方がおかしかったり、
そのプロジェクトにどう関わっていくべきかの大きな手がかりであり、証拠資料なんだから。
> メンテナンスされてないドキュメントなら無い方がマシ。
↑たとえメンテナンスされていなくても、あったほうがいいぞ。
設計書ってのは、設計担当者が何をしたかったのかが書かれている物だ。
ソースから意図を汲み取るよりも、そういう資料があった方が背景を理解しやすい。
メンテナンスについての情報だったり、そもそもの考え方がおかしかったり、
そのプロジェクトにどう関わっていくべきかの大きな手がかりであり、証拠資料なんだから。
>>474
仕様書ってのは、仕様を書いた書類。
設計書ってのは、設計された内容を書いた書類。
大雑把に言えば、
仕様は対外的に決まっている内容。
設計は自分達で自由に設定できる内容。
厶板のお題スレでいえば、
問題は仕様
各自で考えた実現方法は設計
提出された回答が実装
こんな感じと思ってれば大まかには大丈夫。
仕様書ってのは、仕様を書いた書類。
設計書ってのは、設計された内容を書いた書類。
大雑把に言えば、
仕様は対外的に決まっている内容。
設計は自分達で自由に設定できる内容。
厶板のお題スレでいえば、
問題は仕様
各自で考えた実現方法は設計
提出された回答が実装
こんな感じと思ってれば大まかには大丈夫。
仕様を書いたのが仕様書
設計を書いたのが設計書
設計を書いたのが設計書
>>463
文書を作成すると、その分、トータル工数が増えるような文書じゃ、作成してる意味がないだろう。
メンテ含めたトータル工数を少なくするために、文書を作成する。
継続的にメンテが必要なシステムなら、担当者が変わったり、
初版開発関係者が何人かいなくなってたりするから、
文書作成による工数削減効果はより大きくなる。
文書を作成すると、その分、トータル工数が増えるような文書じゃ、作成してる意味がないだろう。
メンテ含めたトータル工数を少なくするために、文書を作成する。
継続的にメンテが必要なシステムなら、担当者が変わったり、
初版開発関係者が何人かいなくなってたりするから、
文書作成による工数削減効果はより大きくなる。
479 ：仕様書無しさん：2014/05/03(土) 19:04:37.66
＞今更だけど設計書と仕様書って何が違うの？
マックの店員がマニュアル通りに動けば繁盛する。
それと同じ考えで、ソフト開発にPGに対してマニュアル通りにコーデングすること
それがPGの役目だと。そういうのではプロジェクトの破綻がおきる
ソフト開発は創造の世界だということなわけよ。
多分ソフト開発というのは、できる人に支えられている。それを属人的というが、
そういう世界だろう。
組織というのは、その人がいなくなっても代わりに誰かが役目をはたす
しかしソフトは開発者がいなくなれば、またゼロから作り直し、そういうことがおきる。
マックの店員がマニュアル通りに動けば繁盛する。
それと同じ考えで、ソフト開発にPGに対してマニュアル通りにコーデングすること
それがPGの役目だと。そういうのではプロジェクトの破綻がおきる
ソフト開発は創造の世界だということなわけよ。
多分ソフト開発というのは、できる人に支えられている。それを属人的というが、
そういう世界だろう。
組織というのは、その人がいなくなっても代わりに誰かが役目をはたす
しかしソフトは開発者がいなくなれば、またゼロから作り直し、そういうことがおきる。
>>468
> おまえは、設計書が全くないコードを引き継いで一から設計起こしたこと無いだろ。
あるよ。
信頼できない設計書が存在する場合より、調査の工数もらえるだけマシ。
>>475
他の担当者や会社が手を入れていて、それが設計書に反映されてないパターンを体験したこと無い？
最初のリリース直後ならまだしも、寿命長いものなら思想やモジュール構造すら参考にならない事は多い。
そのほかにも政治的な理由で設計が無視されたり、運用でカバーされて全く異なるユースケースに対応してたり、
設計書が使い物にならないケースはいくらでも見たことがある。
メンテナンスされてなきゃ害悪なんだよ。
ドキュメントのメンテナンスって、担当者だけが頑張ったって仕方ないんだよな。
まともにメンテナンスするなら、ドキュメントの運用ルールを関係者に徹底して、かつ誰かしら必要な知識を持った人間をシステム廃止まで張り付け続けないといけない。
こんなの、一部の金も人もあるプロジェクトしか無理。
> おまえは、設計書が全くないコードを引き継いで一から設計起こしたこと無いだろ。
あるよ。
信頼できない設計書が存在する場合より、調査の工数もらえるだけマシ。
>>475
他の担当者や会社が手を入れていて、それが設計書に反映されてないパターンを体験したこと無い？
最初のリリース直後ならまだしも、寿命長いものなら思想やモジュール構造すら参考にならない事は多い。
そのほかにも政治的な理由で設計が無視されたり、運用でカバーされて全く異なるユースケースに対応してたり、
設計書が使い物にならないケースはいくらでも見たことがある。
メンテナンスされてなきゃ害悪なんだよ。
ドキュメントのメンテナンスって、担当者だけが頑張ったって仕方ないんだよな。
まともにメンテナンスするなら、ドキュメントの運用ルールを関係者に徹底して、かつ誰かしら必要な知識を持った人間をシステム廃止まで張り付け続けないといけない。
こんなの、一部の金も人もあるプロジェクトしか無理。
>>479 属人資産レベルの開発現場をＣＭＭＩレベル１～２とよぶ
>>476 テンプレに載せたいレベルの素晴らしいレスだと思う。
483 ：仕様書無しさん：2014/05/03(土) 20:08:06.43
>属人資産レベルの開発現場をＣＭＭＩレベル１～２とよぶ
Vistaの失敗は2000人規模の多きさにあったといわれる。
規模の大きさでだめになったというわけ。
多分ソフト開発というのは、属人の世界からぬけていないよ
あほが上に立つとだめになるというパターン。
ソフト開発ばかかりでなく民主党の例なんかそうだね。
Vistaの失敗は2000人規模の多きさにあったといわれる。
規模の大きさでだめになったというわけ。
多分ソフト開発というのは、属人の世界からぬけていないよ
あほが上に立つとだめになるというパターン。
ソフト開発ばかかりでなく民主党の例なんかそうだね。
糞コテを褒めると調子に乗るぞ
>>480
もうお前と>>468,475は相入れないから好きにすればいいんじゃないの？
俺も全体の概略がつかめるポンチ絵なり概要の資料はないよりはあった方がいい派。
メンテされてないならないでその旨が付記されてればいいだけ。
よっぽどよく整理されたソースだとしてもソースから仕様を把握するとか無駄なことこの上ない。
もうお前と>>468,475は相入れないから好きにすればいいんじゃないの？
俺も全体の概略がつかめるポンチ絵なり概要の資料はないよりはあった方がいい派。
メンテされてないならないでその旨が付記されてればいいだけ。
よっぽどよく整理されたソースだとしてもソースから仕様を把握するとか無駄なことこの上ない。
>>480
> 他の担当者や会社が手を入れていて、それが設計書に反映されてないパターンを体験したこと無い？
ソースコードからじゃ設計わかんなかったから(解析してる時間無かったし)、
とりあえず仕様を満たせばいいやと適当に手を入れたことならある。
> 他の担当者や会社が手を入れていて、それが設計書に反映されてないパターンを体験したこと無い？
ソースコードからじゃ設計わかんなかったから(解析してる時間無かったし)、
とりあえず仕様を満たせばいいやと適当に手を入れたことならある。
>>480
ドキュメントは完璧にメンテナンスされないとダメだと考えているようだが、
どうせ完璧にメンテナンスされないからドキュメント作らないというプロジェクトのほうがダメ。
それに、適切な方法を選べば実際の設計に合わせてドキュメントを改版していくのに
そんなに手間はかからない。
ドキュメントは完璧にメンテナンスされないとダメだと考えているようだが、
どうせ完璧にメンテナンスされないからドキュメント作らないというプロジェクトのほうがダメ。
それに、適切な方法を選べば実際の設計に合わせてドキュメントを改版していくのに
そんなに手間はかからない。
役に立つ設計書しか見たこと無い人と役に立たない設計書しか見たこと無い人で話が噛み合うわけがない
両方見たことある人がうまく説明して欲しい
両方見たことある人がうまく説明して欲しい
>>485
メンテされてない旨を誰が残すんだよｗ
>>486
そりゃ、付くだろ。客観的に考えたら必要なんだから。
ドキュメントのメンテ具合次第では、ドキュメントの裏取りだけで調査より時間食うけどな。
>>488
メンテナンスされていないドキュメントでも、残っていれば解決するのか？
>>487のように、その場しのぎの対処にならざる得ないのが現実じゃね。
その場しのぎが積み重なった先はどうなるか想像してみようよ。
>>489
無理。
その設計書が最新化されていないなら調査するしかない。
そもそも設計者自身が認識し得ないケースも多い。(リリース後にシステムを離れてしまう場合とか。)
>>490
> そんなに手間はかからない。
具体的に書いてよ。きっと、工数に余裕があるプロジェクトなんだろうね。
メンテされてない旨を誰が残すんだよｗ
>>486
そりゃ、付くだろ。客観的に考えたら必要なんだから。
ドキュメントのメンテ具合次第では、ドキュメントの裏取りだけで調査より時間食うけどな。
>>488
メンテナンスされていないドキュメントでも、残っていれば解決するのか？
>>487のように、その場しのぎの対処にならざる得ないのが現実じゃね。
その場しのぎが積み重なった先はどうなるか想像してみようよ。
>>489
無理。
その設計書が最新化されていないなら調査するしかない。
そもそも設計者自身が認識し得ないケースも多い。(リリース後にシステムを離れてしまう場合とか。)
>>490
> そんなに手間はかからない。
具体的に書いてよ。きっと、工数に余裕があるプロジェクトなんだろうね。
じゃぁ設計書を書かないことが解決になるのか？
どうせ役に立たない(と自分は思う)から設計書書きませんって
ただ面倒だから設計書書きたくない言い訳でしかないだろ。
>>492
> メンテナンスされていないドキュメントでも、残っていれば解決するのか？
0か0.1かで言えば、0.1の方が良い。
どうせ役に立たない(と自分は思う)から設計書書きませんって
ただ面倒だから設計書書きたくない言い訳でしかないだろ。
>>492
> メンテナンスされていないドキュメントでも、残っていれば解決するのか？
0か0.1かで言えば、0.1の方が良い。
>>492
> そりゃ、付くだろ。客観的に考えたら必要なんだから。
へー。設計書残しておけばそんな工数掛けなくてすんだのに。
お金と時間がたくさんあるんだね。
> ドキュメントのメンテ具合次第では、ドキュメントの裏取りだけで調査より時間食うけどな。
どう考えても、裏取りができるのと裏取りすらできずにゼロから解析するのでは
裏取り工数 <= ゼロからの解析
だけどな。
他人のドキュメントなんかメンテしたくないです。
自分たちでゼロから作りたいですっていう気持ちはわかるが、それは甘え。
> そりゃ、付くだろ。客観的に考えたら必要なんだから。
へー。設計書残しておけばそんな工数掛けなくてすんだのに。
お金と時間がたくさんあるんだね。
> ドキュメントのメンテ具合次第では、ドキュメントの裏取りだけで調査より時間食うけどな。
どう考えても、裏取りができるのと裏取りすらできずにゼロから解析するのでは
裏取り工数 <= ゼロからの解析
だけどな。
他人のドキュメントなんかメンテしたくないです。
自分たちでゼロから作りたいですっていう気持ちはわかるが、それは甘え。
>>492
> そりゃ、付くだろ。客観的に考えたら必要なんだから。
客の観点から考えたら
・以前の担当者が使ってたもの(ソースコード)はある
・ちょっと変更加えるだけ
なのに、調査費用が必要ですはありえない。
以前の担当者は調査なんかしなかったのに。
> そりゃ、付くだろ。客観的に考えたら必要なんだから。
客の観点から考えたら
・以前の担当者が使ってたもの(ソースコード)はある
・ちょっと変更加えるだけ
なのに、調査費用が必要ですはありえない。
以前の担当者は調査なんかしなかったのに。
>>498
いや、>>492 みたいな考え方の人が、
部長やPMみたいなポジションにいるプロジェクトがたくさんある。
ドキュメントの有用性を強硬に主張すると、退場になることの方が多いんじゃないか。
おそらく、ドキュメントが役に立ったためしが一度もないから、
ドキュメントを作成するとトータル工数が、激減するというのが理解できない。
いや、>>492 みたいな考え方の人が、
部長やPMみたいなポジションにいるプロジェクトがたくさんある。
ドキュメントの有用性を強硬に主張すると、退場になることの方が多いんじゃないか。
おそらく、ドキュメントが役に立ったためしが一度もないから、
ドキュメントを作成するとトータル工数が、激減するというのが理解できない。
502 ：仕様書無しさん：2014/05/04(日) 00:28:47.04
ドキュメントを役に立てるには
猿よりちょっと利ロである
必要があるからね。
猿よりちょっと利ロである
必要があるからね。
モンキー集めてモノづくりする日本の企業にはドキュメントなんて不要だよね
>>495
金融も昔やってた。
耐用年数の長いシステムをやってた事が多かったな。
>>497
お前は、本当に酷いドキュメントを見たことが無いんだな。
インターフェースはおろか、考え方すら全く実態と合わないドキュメントで仕事させられたことは無いのか？
全く収穫がなかったら、その調査コストをドブに捨てたのと一緒なんだぞ。
>>499
契約が不適切じゃね？それ。
ソースごと納めてるんなら、設計情報の維持も当然客の責任。
運用メンバへの引継ぎを契約上で明記したり、規模によっては開発会社から人身御供納めたりするのが普通。
サービス提供なら、運用費用確保して判る人間を抑え続ける感じ。
つーか、お前らは何でそんなにドキュメントを信用できるんだよ。
考え方を読み取れるとかそういう意見もあったけど、そもそもその設計が今採用されているか自体は疑わないのか？
結局、人伝いに情報を得るしかないんだよ。
金融も昔やってた。
耐用年数の長いシステムをやってた事が多かったな。
>>497
お前は、本当に酷いドキュメントを見たことが無いんだな。
インターフェースはおろか、考え方すら全く実態と合わないドキュメントで仕事させられたことは無いのか？
全く収穫がなかったら、その調査コストをドブに捨てたのと一緒なんだぞ。
>>499
契約が不適切じゃね？それ。
ソースごと納めてるんなら、設計情報の維持も当然客の責任。
運用メンバへの引継ぎを契約上で明記したり、規模によっては開発会社から人身御供納めたりするのが普通。
サービス提供なら、運用費用確保して判る人間を抑え続ける感じ。
つーか、お前らは何でそんなにドキュメントを信用できるんだよ。
考え方を読み取れるとかそういう意見もあったけど、そもそもその設計が今採用されているか自体は疑わないのか？
結局、人伝いに情報を得るしかないんだよ。
> つーか、お前らは何でそんなにドキュメントを信用できるんだよ。
信用してねーよ。
だから、実装とずれてても気にしない。
一致しないと認めないとか青臭いことを言ってもしょうがないからね。
信用してねーよ。
だから、実装とずれてても気にしない。
一致しないと認めないとか青臭いことを言ってもしょうがないからね。
>>504
つーかそんなに現状とドキュメントがかけ離れててそのことについて何の言及もない現場だったらソースがあってるかどうかも怪しいだろw
お前みたいな極論出して仕様書は役に立たないとか言われても誰も納得しないよ。
つーかそんなに現状とドキュメントがかけ離れててそのことについて何の言及もない現場だったらソースがあってるかどうかも怪しいだろw
お前みたいな極論出して仕様書は役に立たないとか言われても誰も納得しないよ。
>モンキー集めてモノづくりする日本の企業にはドキュメントなんて不要だよね
俺の知っているプロジェクトがある。三社が集まる。本社、分社した技術会社、使用する部署の責任者
で三人は、良い大学出、下請けに出すのがノウハウという人、現場を知らない人
というわけ。開発ということも知らないのが集まっても、ひとりの開発者にはかなわない
俺の知っているプロジェクトがある。三社が集まる。本社、分社した技術会社、使用する部署の責任者
で三人は、良い大学出、下請けに出すのがノウハウという人、現場を知らない人
というわけ。開発ということも知らないのが集まっても、ひとりの開発者にはかなわない
>つーかそんなに現状とドキュメントがかけ離れててそのことについて何の言及もない現場だったらソースがあってるかどうかも怪しいだろw
最近経験したよ、こちらは前のとおりつくった。三年前のやつ。写真にとってあるからそのように配線
そしたら発注元が、前のと違う、ソースコードが対応していない、だって。前のとおり作れ、というわけ。
しかし、こちらに発注元からうちへ送ってきた写真があった。三年前に発注者が説明を求めてきたのだな
それが証拠となって、作り直しを防いだ。
ソースの管理がだめだと迷惑かけるよ
最近経験したよ、こちらは前のとおりつくった。三年前のやつ。写真にとってあるからそのように配線
そしたら発注元が、前のと違う、ソースコードが対応していない、だって。前のとおり作れ、というわけ。
しかし、こちらに発注元からうちへ送ってきた写真があった。三年前に発注者が説明を求めてきたのだな
それが証拠となって、作り直しを防いだ。
ソースの管理がだめだと迷惑かけるよ
>>506
動きがおかしかったらユーザーが文句言うから
動きがおかしかったらユーザーが文句言うから
>>504
業務、担当区分によって設計の認識が違うのかな
例えば組み込みな俺の設計のイメージ
クラス図、シーケンス図、状態遷移図／表、タイミングチャート、フローチャート、運用時の動作解析用ログ出力内容（内部向け）
後はテストケース
業務、担当区分によって設計の認識が違うのかな
例えば組み込みな俺の設計のイメージ
クラス図、シーケンス図、状態遷移図／表、タイミングチャート、フローチャート、運用時の動作解析用ログ出力内容（内部向け）
後はテストケース
512 ：仕様書無しさん：2014/05/04(日) 09:56:34.84
今の現場に出来の悪い外部設計書しか存在していなかったんだが。
いいなぁ、かっこいいドキュメント拝んでみたいよ。
いいなぁ、かっこいいドキュメント拝んでみたいよ。
>>510
だから何？
だから何？
つーか何でクソドキュメントを前提に話をしてるんだよ
そんなの役に立たないどころか邪魔に決まってんだろ
そんなの役に立たないどころか邪魔に決まってんだろ
ドキュメントが糞なのは、
・動かない
・バグがあっても通ってしまう
・矛盾があっても通ってしまう
・テストされていない
・修正した後に回帰テストを行っていない
からだよ。
・動かない
・バグがあっても通ってしまう
・矛盾があっても通ってしまう
・テストされていない
・修正した後に回帰テストを行っていない
からだよ。
噴出しつけとけばでたらめかいてもいいんだよ。
┌────┐
│見直し要 │
└┐┌──┘
| /
┌────┐
│見直し要 │
└┐┌──┘
| /
だいたいは上流で時間使われすぎて、テストフェーズでアレコレ直さなければ
ならなくなって、ドキュメントから修正じゃ間に合わないからとりあえず実装側で
対応して、それを通した後にドキュメントにフィードバックしてないからってのが
かなりの数あるんだろうけどね。契約的に結合の最初の方が終わったら、
はいさようならってのもよくあるし。
ならなくなって、ドキュメントから修正じゃ間に合わないからとりあえず実装側で
対応して、それを通した後にドキュメントにフィードバックしてないからってのが
かなりの数あるんだろうけどね。契約的に結合の最初の方が終わったら、
はいさようならってのもよくあるし。
>>514
だから、うまくいってる所ではどうやって現実的なコストでドキュメントのメンテナンスをしてるんだ？って話をしたいんだが・・。
どいつもこいつも、ドキュメントがクソ化する前に逃げ切った奴しか居ないのかよ。
ドキュメントを維持するためには、人やプロセスを整備する他無いよな？
それじゃ金がかかりすぎるんで、現実は害悪なレベルのクソドキュメントが量産されてます。
ってだけの話なのに、俺は大丈夫だった。お前がおかしいとかとか言われても議論にすらならねーよｗ
2chに議論求める俺が悪いかもしれんけど。
だから、うまくいってる所ではどうやって現実的なコストでドキュメントのメンテナンスをしてるんだ？って話をしたいんだが・・。
どいつもこいつも、ドキュメントがクソ化する前に逃げ切った奴しか居ないのかよ。
ドキュメントを維持するためには、人やプロセスを整備する他無いよな？
それじゃ金がかかりすぎるんで、現実は害悪なレベルのクソドキュメントが量産されてます。
ってだけの話なのに、俺は大丈夫だった。お前がおかしいとかとか言われても議論にすらならねーよｗ
2chに議論求める俺が悪いかもしれんけど。
>>510
客がシステムに対して持つイメージが仕様になります。って職場じゃないの？
客側で仕様まとめてる人間と、ユーザ部門の担当者で認識が乖離するのはよくある話。
都度運用でカバーするから、運用が落ち着く頃には運用部門とユーザ部門間でドキュメントの無い仕様が大量に生まれる。
>>511
詳細設計レベルだよな。
俺のイメージだと、他ブロックへのインターフェースを除くと、内部はモジュールの複雑さによって、担当者の裁量で残したり残さなかったりって感じ。
設計書がプロダクションコードに追いついているのは稀だから、余程コアな所以外は、口伝と引継ぎ時に書くポンチ絵に頼るケースが多かった。
技術継承目的になると、引き継ぐ相手の文化やレベルが判らないから、行間を埋める方法が何かしら必要になるよ。
客がシステムに対して持つイメージが仕様になります。って職場じゃないの？
客側で仕様まとめてる人間と、ユーザ部門の担当者で認識が乖離するのはよくある話。
都度運用でカバーするから、運用が落ち着く頃には運用部門とユーザ部門間でドキュメントの無い仕様が大量に生まれる。
>>511
詳細設計レベルだよな。
俺のイメージだと、他ブロックへのインターフェースを除くと、内部はモジュールの複雑さによって、担当者の裁量で残したり残さなかったりって感じ。
設計書がプロダクションコードに追いついているのは稀だから、余程コアな所以外は、口伝と引継ぎ時に書くポンチ絵に頼るケースが多かった。
技術継承目的になると、引き継ぐ相手の文化やレベルが判らないから、行間を埋める方法が何かしら必要になるよ。
>>519
>詳細設計レベルだよな。
横レスになるけど、組込み系/制御系/通信系だと>>511の
シーケンス図や状態遷移図/表は機能設計レベルの文書になる
言い換えると、実装には依存しない論理的な機能要素の仕様を
こういった図表で定義し、エラー発生時やイベントのすれ違い/衝突時に
正しく振る舞うかを論理レベルで検証するのが機能設計工程の目的
そしてこの論理的な仕様を実装するのが構造設計/詳細設計になる
>詳細設計レベルだよな。
横レスになるけど、組込み系/制御系/通信系だと>>511の
シーケンス図や状態遷移図/表は機能設計レベルの文書になる
言い換えると、実装には依存しない論理的な機能要素の仕様を
こういった図表で定義し、エラー発生時やイベントのすれ違い/衝突時に
正しく振る舞うかを論理レベルで検証するのが機能設計工程の目的
そしてこの論理的な仕様を実装するのが構造設計/詳細設計になる
口伝と引継ぎ時に書くポンチ絵をドキュメントにまとめればいいのに、
なんでやらないんだろう。
なんでやらないんだろう。
>>522
「やらない」んじゃなくて「やれない」んだと思う
口伝と引継ぎってのは開発が一区切りした後にやるものだけど、
でも設計書は開発工程の先頭でまとめるもの
それなのに、設計書を書く時点では最終的な設計イメージを持てず、
お決まりの規則に沿って役人仕事で設計書を書いているだけ
「やらない」んじゃなくて「やれない」んだと思う
口伝と引継ぎってのは開発が一区切りした後にやるものだけど、
でも設計書は開発工程の先頭でまとめるもの
それなのに、設計書を書く時点では最終的な設計イメージを持てず、
お決まりの規則に沿って役人仕事で設計書を書いているだけ
開発一区切り付いた時点で、設計書を実際のコードにあったものに手直しすることしないの？
最後納品用ドキュメント作成する時に設計書の修正もさせられてたけど。
最後納品用ドキュメント作成する時に設計書の修正もさせられてたけど。
>>518
だから修正する度にソース見直して解析する工数>>>>>>内容をつかめるレベルのドキュメントを整備する工数なんだが。
当たり前のとこはちゃんとやってるよ。
ソースに書いた方が早いものはそこに、別資料の方がいいものはそこに。
なんでコストとメリットのバランスが取れるレベルの資料を作ればいいってことが理解できない？
だから修正する度にソース見直して解析する工数>>>>>>内容をつかめるレベルのドキュメントを整備する工数なんだが。
当たり前のとこはちゃんとやってるよ。
ソースに書いた方が早いものはそこに、別資料の方がいいものはそこに。
なんでコストとメリットのバランスが取れるレベルの資料を作ればいいってことが理解できない？
>>521
どこが無茶苦茶だ？
ドキュメントを適切に管理し続けなければ、徐々に負債になるのは事実。
管理しない位なら存在しないほうがマシって言う主張とは相反しないと思うが。
ドキュメントがあるの状況を理想というのは勝手だが、現実問題困難なんだよ。
客がトータルいくらででソリューションを手に入れるかって視点で見ると、まともなドキュメント作るより人を張り付けたほうが安いことも多いんだぜ。
>>522
だから、まとめたものをどうやってメンテしつつ残すんだよ。
>>524
大抵するね。で、その後は？
あくまで「開発時」のドキュメントとして保存され、誰も触らなくなるケースばかりじゃね。
リリース1発、メンテナンスフリーで動き続ける位枯れたロジックなら別だけど、
運用始まった後に大幅乖離するのが殆どじゃない？
どこが無茶苦茶だ？
ドキュメントを適切に管理し続けなければ、徐々に負債になるのは事実。
管理しない位なら存在しないほうがマシって言う主張とは相反しないと思うが。
ドキュメントがあるの状況を理想というのは勝手だが、現実問題困難なんだよ。
客がトータルいくらででソリューションを手に入れるかって視点で見ると、まともなドキュメント作るより人を張り付けたほうが安いことも多いんだぜ。
>>522
だから、まとめたものをどうやってメンテしつつ残すんだよ。
>>524
大抵するね。で、その後は？
あくまで「開発時」のドキュメントとして保存され、誰も触らなくなるケースばかりじゃね。
リリース1発、メンテナンスフリーで動き続ける位枯れたロジックなら別だけど、
運用始まった後に大幅乖離するのが殆どじゃない？
>>525
資料って、誰向けでどのくらいの期間残すものを想定してるんだ？
勝手に推測すると、内部で担当者間の意思疎通のため使うもののように聞こえる。
そういうものって、今現在か精々リリースまでしか想定してないんじゃないか？
で、そういう資料って、往々にして開発チームや担当者間で埋もれてしまう。
理由は体裁が整ってないやら、内輪でしか通じない表現で記されているやら。
(運用チームや客の利害が一致してなきゃ、引き継ぐほうが文書の体裁を求めるのが普通。)
結局組織としてはアリバイ作りのテンプレ文書を量産して、必要なノウハウや思想はドキュメントに残らない。
そうなると、人を残して口伝か教育で引き継がざるえない。
> なんでコストとメリットのバランスが取れるレベルの資料を作ればいいってことが理解できない？
ここを否定するつもりは無いよ。
コスト対効果を取るとドキュメントとして残るものが少ないってだけで。
資料って、誰向けでどのくらいの期間残すものを想定してるんだ？
勝手に推測すると、内部で担当者間の意思疎通のため使うもののように聞こえる。
そういうものって、今現在か精々リリースまでしか想定してないんじゃないか？
で、そういう資料って、往々にして開発チームや担当者間で埋もれてしまう。
理由は体裁が整ってないやら、内輪でしか通じない表現で記されているやら。
(運用チームや客の利害が一致してなきゃ、引き継ぐほうが文書の体裁を求めるのが普通。)
結局組織としてはアリバイ作りのテンプレ文書を量産して、必要なノウハウや思想はドキュメントに残らない。
そうなると、人を残して口伝か教育で引き継がざるえない。
> なんでコストとメリットのバランスが取れるレベルの資料を作ればいいってことが理解できない？
ここを否定するつもりは無いよ。
コスト対効果を取るとドキュメントとして残るものが少ないってだけで。
>>527
内部の関係者の意思疎通のためだが、うちは多くの場合同じ会社のシステムの開発と運用を継続して受けてるけど、ドキュメントに起こせるとこはするし別に埋れもしないが。
体裁が整わないって言うなら整えればいいじゃん。
内部の関係者の意思疎通のためだが、うちは多くの場合同じ会社のシステムの開発と運用を継続して受けてるけど、ドキュメントに起こせるとこはするし別に埋れもしないが。
体裁が整わないって言うなら整えればいいじゃん。
あー、わかった。納品されたものを勝手に改修するケースか。
知るかそんなもの。
普通に外注に出せば改修後の設計書まで作らせる(=その分のコストも支払う)のに、
自分たちで改修したら作らないとかただの手抜きとしか。
知るかそんなもの。
普通に外注に出せば改修後の設計書まで作らせる(=その分のコストも支払う)のに、
自分たちで改修したら作らないとかただの手抜きとしか。
>>528
納品物？大抵、スッカスカのアリバイ用になってるだろ。
ドキュメントは客から中身が見えるから、必要最小限になるのが普通じゃないか？
必要以上に納入した結果、いつの間にか客の手で仕様扱いに。後から不具合だって言われたこと無いのか？
>>529
簡単に言うな。そのコストが高いんだよ。
体裁と一口に言うが、その心は「(受け取る側からして)俺たちがパッと見て解るものもってこい」だ。
文書の項番や章構成、フォント等の指定は序の口。
開発部門/会社の政治力によっては、組織間の文化の違いや読者の知識レベル、視点の違い辺りをドキュメントで吸収させられる。
お前らは引継ぎで苦しんだこと無いのか？
>>530
クソドキュメントで工数削られる位なら、すこしでも工数あるほうがマシ。それだけの話。
納品物？大抵、スッカスカのアリバイ用になってるだろ。
ドキュメントは客から中身が見えるから、必要最小限になるのが普通じゃないか？
必要以上に納入した結果、いつの間にか客の手で仕様扱いに。後から不具合だって言われたこと無いのか？
>>529
簡単に言うな。そのコストが高いんだよ。
体裁と一口に言うが、その心は「(受け取る側からして)俺たちがパッと見て解るものもってこい」だ。
文書の項番や章構成、フォント等の指定は序の口。
開発部門/会社の政治力によっては、組織間の文化の違いや読者の知識レベル、視点の違い辺りをドキュメントで吸収させられる。
お前らは引継ぎで苦しんだこと無いのか？
>>530
クソドキュメントで工数削られる位なら、すこしでも工数あるほうがマシ。それだけの話。
>>531
> 納品物？大抵、スッカスカのアリバイ用になってるだろ。
PSレベルだと、doxygenで出したもの納入することもあるが、SSレベルはないな。
だいたい、客のレビューが入るからそんなスカスカなものは通らない。
> いつの間にか客の手で仕様扱いに。後から不具合だって言われたこと無いのか？
設計は設計でレビューして客の承認取ってるわけだから、設計と違った動作したら不具合だろ。
> 納品物？大抵、スッカスカのアリバイ用になってるだろ。
PSレベルだと、doxygenで出したもの納入することもあるが、SSレベルはないな。
だいたい、客のレビューが入るからそんなスカスカなものは通らない。
> いつの間にか客の手で仕様扱いに。後から不具合だって言われたこと無いのか？
設計は設計でレビューして客の承認取ってるわけだから、設計と違った動作したら不具合だろ。
>>531
開発に役立てるための設計書の話してるのに客へのアリバイ作りのための無意味な設計書の話してどうすんのよ(´･_･`)
開発に役立てるための設計書の話してるのに客へのアリバイ作りのための無意味な設計書の話してどうすんのよ(´･_･`)
>>532
そこそこの規模のSIを想定してる。
組織は客と開発/運用側はバラバラの会社で、下に有象無象の人間がぶら下ってるような一般的なの。
客や開発/運用、有象無象の下請けで各々が自分の利益を最大化するよう動いていて、人がそれなりに入れ替わる感じ。
>>533
全ての挙動/要件をドキュメント化するのは困難。
規模によっては、どんなにレビューしても穴が出るもんだよ。
外部要因を考慮すると、正確に運用後の姿を知る術なんて無いから。
>設計は設計でレビューして客の承認取ってるわけだから、設計と違った動作したら不具合だろ。
設計内容について、徹頭徹尾客の合意とるとか尚更不可能。
レビューを通しても曖昧な部分なんていくらでも残るんだよ。運用が安定しようが、騙し騙しやる部分は必ず出る。
問題が起こったとき、関係者は他の組織にどう責任ふっかけるかを血眼になって探し回るもんだ。
だから、極力安全な部分だけ客のレビューに出して通す。
細かいノウハウやら設計の過程やらも、そこにわずかでも破綻が見えれば拡大解釈して責め立てる道具になる。
>>534
上に書いた通り、その無意味な設計書しか大っぴらに引き継げないんだよ。
そこそこの規模のSIを想定してる。
組織は客と開発/運用側はバラバラの会社で、下に有象無象の人間がぶら下ってるような一般的なの。
客や開発/運用、有象無象の下請けで各々が自分の利益を最大化するよう動いていて、人がそれなりに入れ替わる感じ。
>>533
全ての挙動/要件をドキュメント化するのは困難。
規模によっては、どんなにレビューしても穴が出るもんだよ。
外部要因を考慮すると、正確に運用後の姿を知る術なんて無いから。
>設計は設計でレビューして客の承認取ってるわけだから、設計と違った動作したら不具合だろ。
設計内容について、徹頭徹尾客の合意とるとか尚更不可能。
レビューを通しても曖昧な部分なんていくらでも残るんだよ。運用が安定しようが、騙し騙しやる部分は必ず出る。
問題が起こったとき、関係者は他の組織にどう責任ふっかけるかを血眼になって探し回るもんだ。
だから、極力安全な部分だけ客のレビューに出して通す。
細かいノウハウやら設計の過程やらも、そこにわずかでも破綻が見えれば拡大解釈して責め立てる道具になる。
>>534
上に書いた通り、その無意味な設計書しか大っぴらに引き継げないんだよ。
また完全じゃないものは無意味って言い始めてる。
結局、ドキュメント書きたく無いだけなんでしょ。
パーフェクト症候群か。
話がかみ合ってないぞ
もっと具体的に話をしろ
もっと具体的に話をしろ
>>537
そりゃ、まともなものを見たことがなければ、書きたくなくもなる。
ドキュメントをキッチリして、サクッと終わらせるより、
仕様もロクに明確化しないで、グダグダと残業ばかりやってた方が、
カネをたくさん取れる場合も多いしね。
そりゃ、まともなものを見たことがなければ、書きたくなくもなる。
ドキュメントをキッチリして、サクッと終わらせるより、
仕様もロクに明確化しないで、グダグダと残業ばかりやってた方が、
カネをたくさん取れる場合も多いしね。
>客や開発/運用、有象無象の下請けで各々が自分の利益を最大化するよう動いていて
なんだこの前提は？
よくある事なのか？
迷惑だから開発に関わらないで欲しい
こんな認識の奴は
なんだこの前提は？
よくある事なのか？
迷惑だから開発に関わらないで欲しい
こんな認識の奴は
>>536-538
下手なもの書いたら誰も得しないってだけの話なのにどうしてそうなるんだ？
揶揄するなら建設的な意見だせよ。
>>541
良くある話じゃないか。俺が見るのはこんなのばっか。
客：1円でも安く、1分でも裂く時間を減らしてソリューションを調達したい。(ユーザ側に臨時で入れてる有識者をとっとと切って、工数減らしたい。)
開発会社/部門： 1円でも多く中抜きしてシステムを納めたい。開発終わったら、一刻も早く手を引きたい。
運用会社/部門： 現実的に業務が回り、素人でも運用できるシステムとドキュメントを引き継いで欲しい。
下請け： 素人ぶちこんで中抜きおいしいです。
>>542
どんな設計書なら有用？その設計書を生かすにはどんな前提を用意したら良いんだ？
下手なもの書いたら誰も得しないってだけの話なのにどうしてそうなるんだ？
揶揄するなら建設的な意見だせよ。
>>541
良くある話じゃないか。俺が見るのはこんなのばっか。
客：1円でも安く、1分でも裂く時間を減らしてソリューションを調達したい。(ユーザ側に臨時で入れてる有識者をとっとと切って、工数減らしたい。)
開発会社/部門： 1円でも多く中抜きしてシステムを納めたい。開発終わったら、一刻も早く手を引きたい。
運用会社/部門： 現実的に業務が回り、素人でも運用できるシステムとドキュメントを引き継いで欲しい。
下請け： 素人ぶちこんで中抜きおいしいです。
>>542
どんな設計書なら有用？その設計書を生かすにはどんな前提を用意したら良いんだ？
>>543
君から建設的な意見を聞いたこと無いんだがw
君から建設的な意見を聞いたこと無いんだがw
>>543
だから下手なもの書くの前提の話してるからだろ。
ソース解析する時にこういう情報がまとまってたらいいのにと思ったことはないの？でその中でコレだったらそれほど工数かけずに作れてかつ有用な物は？
自分なら全体の概要図や状態遷移図などは欲しい
だから下手なもの書くの前提の話してるからだろ。
ソース解析する時にこういう情報がまとまってたらいいのにと思ったことはないの？でその中でコレだったらそれほど工数かけずに作れてかつ有用な物は？
自分なら全体の概要図や状態遷移図などは欲しい
ここでグダグダ言っても、設計書が役に立った経験が無いと理解できない思うよ。
(むしろ、設計書がなくソースコードだけ渡されてメンテする経験したほうがありがたさがわかるかな)
バージョン管理システムとか、自動テストとか導入する時に
「面倒が増えるだけ」「メンテナンスしないから無理」
とか言って導入に反対する人と同じ症状になってる。
(むしろ、設計書がなくソースコードだけ渡されてメンテする経験したほうがありがたさがわかるかな)
バージョン管理システムとか、自動テストとか導入する時に
「面倒が増えるだけ」「メンテナンスしないから無理」
とか言って導入に反対する人と同じ症状になってる。
>>544
実態を無視して理想論語ったらいいのか？
俺が挙げた前提が酷いのは重々承知してるが、実態と切り離して意味のある話じゃないだろ。
都合よく挙げると、この位の前提になるぞ。
ソリューション導入の目的が明確かつ全関係者に浸透しており、かつ見込C/Pが現実的。予算は潤沢に供給されている。
士気が高く必要なスキルを持つ人員のみで関係者が構成され、入れ替わりも滅多に存在しない。
当然、ドキュメントのメンテナンスや前提の調査にも専任の担当者を確保。
客や開発/運用会社やチームも同一の文化圏に属し、組織の壁は無く善意で回せるくらい良好な関係が築かれている。
>>545
> 自分なら全体の概要図や状態遷移図などは欲しい
使い物になるレベルで用意できるなら、俺も欲しいよ。
後は、インターフェースの仕様書と全体の担当割辺りがあるといいな。
>>546
ドキュメントの質次第では、ソースコードだけ渡されて必死にヒアリングと仕様起こしする方が確実に楽。
そのたとえ話に乗るなら、開発者のアクセスが十分に確保できないのにSVN入れてみたり、CIせずに自動テストするようなものだろ。
手段による利益よりも害悪が勝ってしまっている状況。
どれだけ前提条件を整えたら、ドキュメントが役に立つんだ？
実態を無視して理想論語ったらいいのか？
俺が挙げた前提が酷いのは重々承知してるが、実態と切り離して意味のある話じゃないだろ。
都合よく挙げると、この位の前提になるぞ。
ソリューション導入の目的が明確かつ全関係者に浸透しており、かつ見込C/Pが現実的。予算は潤沢に供給されている。
士気が高く必要なスキルを持つ人員のみで関係者が構成され、入れ替わりも滅多に存在しない。
当然、ドキュメントのメンテナンスや前提の調査にも専任の担当者を確保。
客や開発/運用会社やチームも同一の文化圏に属し、組織の壁は無く善意で回せるくらい良好な関係が築かれている。
>>545
> 自分なら全体の概要図や状態遷移図などは欲しい
使い物になるレベルで用意できるなら、俺も欲しいよ。
後は、インターフェースの仕様書と全体の担当割辺りがあるといいな。
>>546
ドキュメントの質次第では、ソースコードだけ渡されて必死にヒアリングと仕様起こしする方が確実に楽。
そのたとえ話に乗るなら、開発者のアクセスが十分に確保できないのにSVN入れてみたり、CIせずに自動テストするようなものだろ。
手段による利益よりも害悪が勝ってしまっている状況。
どれだけ前提条件を整えたら、ドキュメントが役に立つんだ？
>>547
> 使い物になるレベルで用意できるなら、俺も欲しいよ。
後は、インターフェースの仕様書と全体の担当割辺りがあるといいな。
そうだよな～、欲しいよな～
じゃ、グダグダ言わずに担当した分の設計資料は残しとけよ無能
後は使い物になるレベルってやつの定義かな
お前が引き継ぎの時に書くチンポ
とりあえずそれでも有用だろ
> 使い物になるレベルで用意できるなら、俺も欲しいよ。
後は、インターフェースの仕様書と全体の担当割辺りがあるといいな。
そうだよな～、欲しいよな～
じゃ、グダグダ言わずに担当した分の設計資料は残しとけよ無能
後は使い物になるレベルってやつの定義かな
お前が引き継ぎの時に書くチンポ
とりあえずそれでも有用だろ
基本的に完璧な設計書は求めてないぞ
でも状態遷移図／表は完璧なもの作っとけよな
でも状態遷移図／表は完璧なもの作っとけよな
ユーザは設計書なんてまともに読まないからなぁ。
>>547
> ドキュメントの質次第では、ソースコードだけ渡されて必死にヒアリングと仕様起こしする方が確実に楽。
ヒアリングって、誰に何を聞くんだよ。
客が設計の詳細知ってるわけでもないし、開発をした担当者はいないんだぞ？
勝手に前担当者がいるという条件を追加してないか？
> ドキュメントの質次第では、ソースコードだけ渡されて必死にヒアリングと仕様起こしする方が確実に楽。
ヒアリングって、誰に何を聞くんだよ。
客が設計の詳細知ってるわけでもないし、開発をした担当者はいないんだぞ？
勝手に前担当者がいるという条件を追加してないか？
>>547
結局、お前が勝手にドキュメントが役に立たない状況を想定して、
この場合はどうする？って駄々こねてるだけじゃないか。
現実は、大半のプロジェクトが「もっとまともなドキュメントはないのか」と思われつつも、
無いよりはよっぽどましだからその場で可能なメンテをしながら運用されてるんだ。
もしお前が本当に「ドキュメントが無い方がマシ」なプロジェクトに当たりつづけてるんなら
かわいそうですね。転職を考えた方がいいですよ。
結局、お前が勝手にドキュメントが役に立たない状況を想定して、
この場合はどうする？って駄々こねてるだけじゃないか。
現実は、大半のプロジェクトが「もっとまともなドキュメントはないのか」と思われつつも、
無いよりはよっぽどましだからその場で可能なメンテをしながら運用されてるんだ。
もしお前が本当に「ドキュメントが無い方がマシ」なプロジェクトに当たりつづけてるんなら
かわいそうですね。転職を考えた方がいいですよ。
>設計は設計でレビューして客の承認取ってるわけだから、設計と違った動作したら不具合だろ。
思ったんだけど、これが根本的に間違ってないか？
政治的問題は置いといて、
設計はレビューして、開発者の承認を取るのが筋じゃないのか？
これを見て開発するわけけだから。
間違った設計を、素人である客が直せるとは思わんし、
素人に見せてもしょうがないだろ？
思ったんだけど、これが根本的に間違ってないか？
政治的問題は置いといて、
設計はレビューして、開発者の承認を取るのが筋じゃないのか？
これを見て開発するわけけだから。
間違った設計を、素人である客が直せるとは思わんし、
素人に見せてもしょうがないだろ？
>>547
>使い物になるレベルで用意できるなら、俺も欲しいよ。
一週間分の実装とテスト分についてのポンチ絵描きや修正なんぞ2時間もかからんと思うんだが。繰り返してけば修正ばかりになるから余計短縮されるな。
>後は、インターフェースの仕様書と全体の担当割辺りがあるといいな。
担当割って何に使うのよw問い合わせ前提かw
てかそれぐらい残すの一瞬だろwww
>使い物になるレベルで用意できるなら、俺も欲しいよ。
一週間分の実装とテスト分についてのポンチ絵描きや修正なんぞ2時間もかからんと思うんだが。繰り返してけば修正ばかりになるから余計短縮されるな。
>後は、インターフェースの仕様書と全体の担当割辺りがあるといいな。
担当割って何に使うのよw問い合わせ前提かw
てかそれぐらい残すの一瞬だろwww
555 ：仕様書無しさん：2014/05/05(月) 14:26:27.73
世の中には、システムを一から作り上げれるＰＧと
出来上がったものをちょこっと手直しすることしかできないＰＧがいるわけ
俺はシステムをゼロかつくるのはできない、 というプログラマと最近会話した
そういうプログラマのために設計書あったほうがいいよね
出来上がったものをちょこっと手直しすることしかできないＰＧがいるわけ
俺はシステムをゼロかつくるのはできない、 というプログラマと最近会話した
そういうプログラマのために設計書あったほうがいいよね
>>548
で、お前はどんな前提想定してるの？
どんな状況下でもドキュメントが生きる訳じゃないのは、散々挙げただろ？
ドキュメントが責任転嫁に使われるようなプロジェクトだと、身を守るために皆最低限しか引き取らない。
ドキュメント残す仕組みがなけりゃ他の担当者の手に渡っていかない。
>>549
状態遷移図／表って包括的に書くものなのか？
業務系だと、大抵のプロジェクトが複雑な部分だけ残してた。
>>551
メンテナンスフリーでもない限り、誰かしら関係者は残っている。
開発した担当者に聞けるのがベストだけど、周辺モジュールの実装者や運用担当者でもいいじゃない。
完全に独立してる物じゃなきゃ、たとえ設計書があったとしても同様のヒアリングが必要。
>>553
組み込みのように、ビジネスロジックの比率低めで実装の難易度が高い分野なら同意。
業務系の場合、ビジネスロジックの比率が高めで比較的実装難易度が低い。
ビジネスロジックの比率が高い分、客側の業務担当者のレビューが意味を持つ。
ユーザ側の不便や設計者の業務知識不足、環境に起因する制約事項等々、開発チームのレビューで発覚しにくい不具合を弾ける。
>>554
だから、作るのが問題じゃなくて作った後が問題なんだって。
で、お前はどんな前提想定してるの？
どんな状況下でもドキュメントが生きる訳じゃないのは、散々挙げただろ？
ドキュメントが責任転嫁に使われるようなプロジェクトだと、身を守るために皆最低限しか引き取らない。
ドキュメント残す仕組みがなけりゃ他の担当者の手に渡っていかない。
>>549
状態遷移図／表って包括的に書くものなのか？
業務系だと、大抵のプロジェクトが複雑な部分だけ残してた。
>>551
メンテナンスフリーでもない限り、誰かしら関係者は残っている。
開発した担当者に聞けるのがベストだけど、周辺モジュールの実装者や運用担当者でもいいじゃない。
完全に独立してる物じゃなきゃ、たとえ設計書があったとしても同様のヒアリングが必要。
>>553
組み込みのように、ビジネスロジックの比率低めで実装の難易度が高い分野なら同意。
業務系の場合、ビジネスロジックの比率が高めで比較的実装難易度が低い。
ビジネスロジックの比率が高い分、客側の業務担当者のレビューが意味を持つ。
ユーザ側の不便や設計者の業務知識不足、環境に起因する制約事項等々、開発チームのレビューで発覚しにくい不具合を弾ける。
>>554
だから、作るのが問題じゃなくて作った後が問題なんだって。
>>556
有用な物をマトモな手続きを確立しないままグダグダとロストして無駄な作業を繰り返してるだけにしか見えんわ
有用な物をマトモな手続きを確立しないままグダグダとロストして無駄な作業を繰り返してるだけにしか見えんわ
とりあえず>>556以外は設計書はうまくやればメンテコストを考慮しても有用だから上手い具合に残しとけってことでいい？
それでよければどういうのがあるとコストかからず有益かの話しようぜ。
もうグダグダと出来ない言い訳を繰り返す奴はお腹いっぱい。
それでよければどういうのがあるとコストかからず有益かの話しようぜ。
もうグダグダと出来ない言い訳を繰り返す奴はお腹いっぱい。
>>559
「うまくやれば有用」は誰も否定してないんじゃない？
＞556は、「うまくない設計書なら要らない」って言ってるんだと思うんだが。
で、SysMLが例に出されたけど、実際やってるやつらはモデリング主体なのかが聞きたい。
「うまくやれば有用」は誰も否定してないんじゃない？
＞556は、「うまくない設計書なら要らない」って言ってるんだと思うんだが。
で、SysMLが例に出されたけど、実際やってるやつらはモデリング主体なのかが聞きたい。
>>560
だから0か1かじゃなくて、どのレベルなら「うまくない設計書」と定義してるの？
世の中ペラ紙1枚でも読むのが苦痛な人がいるからな、そういう人にしてみたら
何か書くのさえ「うまくない設計書」を書いてるつもりになるんだろ。 逆にペラ紙
1枚から驚くほど色々と読み取るのもいるけど。
だから0か1かじゃなくて、どのレベルなら「うまくない設計書」と定義してるの？
世の中ペラ紙1枚でも読むのが苦痛な人がいるからな、そういう人にしてみたら
何か書くのさえ「うまくない設計書」を書いてるつもりになるんだろ。 逆にペラ紙
1枚から驚くほど色々と読み取るのもいるけど。
>>562
建設的かどうかはわからないけれど、556に共鳴する部分もある。
実際、ひどいもんなんだもの。
そういう現場も業務系では多くあって、組込その他で見習うべきものがあるなら
是非とも見習いたい。
きちんとした設計書が当たり前のところから見ると、頭おかしいレベルなんだろうし、
ちゃんとすりゃーそりゃ楽だし確かだし、ってのは当たり前なのは理解している。
建設的かどうかはわからないけれど、556に共鳴する部分もある。
実際、ひどいもんなんだもの。
そういう現場も業務系では多くあって、組込その他で見習うべきものがあるなら
是非とも見習いたい。
きちんとした設計書が当たり前のところから見ると、頭おかしいレベルなんだろうし、
ちゃんとすりゃーそりゃ楽だし確かだし、ってのは当たり前なのは理解している。
まずは概要設計書をどうしているか、うまくできている所に聞きたい。
・モデリングツール使っているのか？何を？
・設計標準を作成しているのか？作成にかかった工数はわかるか？
あたりさわりのない範囲で教えて欲しい。
・モデリングツール使っているのか？何を？
・設計標準を作成しているのか？作成にかかった工数はわかるか？
あたりさわりのない範囲で教えて欲しい。
>>556
> 状態遷移図／表って包括的に書くものなのか？
業務系だと、大抵のプロジェクトが複雑な部分だけ残してた。
当然、作るのは複雑な部分だけでいい
だけど作ったもの位は完璧にメンテしろよ！
って言いたかった
分かりにくくてごめんね
でも正直、包括的に書くわけねーだろ低脳！ っていう思いもある
つーか、資料残してるんだな
当たり前だよな
複雑な状態をもつソフトを突然コーディング出来るわけないもんな
別にかっこいい設計書に仕上げる必要はないけどさ、設計資料は作るべき
> 状態遷移図／表って包括的に書くものなのか？
業務系だと、大抵のプロジェクトが複雑な部分だけ残してた。
当然、作るのは複雑な部分だけでいい
だけど作ったもの位は完璧にメンテしろよ！
って言いたかった
分かりにくくてごめんね
でも正直、包括的に書くわけねーだろ低脳！ っていう思いもある
つーか、資料残してるんだな
当たり前だよな
複雑な状態をもつソフトを突然コーディング出来るわけないもんな
別にかっこいい設計書に仕上げる必要はないけどさ、設計資料は作るべき
>>556
> だから、作るのが問題じゃなくて作った後が問題なんだって。
２時間で作ったものなら、２時間程度で改修できるでしょ。
君はそれをやらずに、ただメンテナンス工数が取れないと文句言ってるだけ。
> だから、作るのが問題じゃなくて作った後が問題なんだって。
２時間で作ったものなら、２時間程度で改修できるでしょ。
君はそれをやらずに、ただメンテナンス工数が取れないと文句言ってるだけ。
２時間で作ったら２０時間かかるでしょ
逆に２０時間かかったら２時間でメンテが終わる
逆に２０時間かかったら２時間でメンテが終わる
>>569
> ２時間で作ったものなら、２時間程度で改修できるでしょ。
できるとは限らないよ。2時間で0から作ったものなら
2時間で0から作り直せるかもしれないけど、
改修が2時間で終わるとは限らない。
2時間じゃ短いから1ヶ月、そして建築物にたとえてみようか？
1ヶ月で2階建の建築物を作りました。
これを4階建に改修するならば、まず土台を4階建に耐えられるように改修しないといけない。
今ある2階建を全部とっぱらい、0に戻してやり直さなきゃいけないから到底1ヶ月では4階建にはできない。
2階建を取り壊す時間 + 目標が4階建だから、2階建よりも強固な作りにしないと
いけないから2階まで作るだけでも、2階建の時よりも時間がかかる。
ソフトウェアも同じで0から作り直すのではなくて改修なら、
既存のソースを読んで理解する時間が必要。
改修だと読む時間のほうが長くかかるので、だから読みやすいコードを書けって言われるわけ。
改修に時間がかかるのは、初期に手を抜いた証拠でもある。
初期に手を抜いても、修正可能な設計になっていればいいけど、そういうことまで手を抜く奴が多い。
こうのうがメンテナンス性。
初期の設計とメンテナンス性が悪い、それは技術不足でもあるが、そういうのが極めて重要。
そしてそれは設計書には書かれない部分でもある。というか設計書を書く人が技術不足なんだよな。
コード書けない人が土台を作ってはダメ。
> ２時間で作ったものなら、２時間程度で改修できるでしょ。
できるとは限らないよ。2時間で0から作ったものなら
2時間で0から作り直せるかもしれないけど、
改修が2時間で終わるとは限らない。
2時間じゃ短いから1ヶ月、そして建築物にたとえてみようか？
1ヶ月で2階建の建築物を作りました。
これを4階建に改修するならば、まず土台を4階建に耐えられるように改修しないといけない。
今ある2階建を全部とっぱらい、0に戻してやり直さなきゃいけないから到底1ヶ月では4階建にはできない。
2階建を取り壊す時間 + 目標が4階建だから、2階建よりも強固な作りにしないと
いけないから2階まで作るだけでも、2階建の時よりも時間がかかる。
ソフトウェアも同じで0から作り直すのではなくて改修なら、
既存のソースを読んで理解する時間が必要。
改修だと読む時間のほうが長くかかるので、だから読みやすいコードを書けって言われるわけ。
改修に時間がかかるのは、初期に手を抜いた証拠でもある。
初期に手を抜いても、修正可能な設計になっていればいいけど、そういうことまで手を抜く奴が多い。
こうのうがメンテナンス性。
初期の設計とメンテナンス性が悪い、それは技術不足でもあるが、そういうのが極めて重要。
そしてそれは設計書には書かれない部分でもある。というか設計書を書く人が技術不足なんだよな。
コード書けない人が土台を作ってはダメ。
>改修に時間がかかるのは、初期に手を抜いた証拠でもある。
>初期に手を抜いても、修正可能な設計になっていればいいけど、そういうことまで手を抜く奴が多い。
>こうのうがメンテナンス性。
おまえのソフトが欲しい、前のより少し変更してくれ、というリピートがくると
俺は保守性をかんがえる。０から作り直す。1300ｃｃの車から、2000ｃｃクラスへ変身させる
追加のオプションを安全に実装できるように作り変える
で、だめなのが、既存のコードに追加していくタイプ。
追加の仕様にあわせ、ifだらけ、フラグだらけになっていたりする
こういうのをメンテしたくない
>初期に手を抜いても、修正可能な設計になっていればいいけど、そういうことまで手を抜く奴が多い。
>こうのうがメンテナンス性。
おまえのソフトが欲しい、前のより少し変更してくれ、というリピートがくると
俺は保守性をかんがえる。０から作り直す。1300ｃｃの車から、2000ｃｃクラスへ変身させる
追加のオプションを安全に実装できるように作り変える
で、だめなのが、既存のコードに追加していくタイプ。
追加の仕様にあわせ、ifだらけ、フラグだらけになっていたりする
こういうのをメンテしたくない
俺はリピートがきたら作り直すといったが
プロトタイプを収め、つぎに注文がくるというのもある
プロトタイプのベースから、ソースが二倍に膨れるともある。
作りなおしだよ
プロトタイプを収め、つぎに注文がくるというのもある
プロトタイプのベースから、ソースが二倍に膨れるともある。
作りなおしだよ
素直に足して済む場合と、構造から変えないといけない場合があるもんな
> 素直に足して済む場合と、構造から変えないといけない場合があるもんな
その通り。そういうのは設計書を見てもわからない。
コードを見ないと判断不可能。
その通り。そういうのは設計書を見てもわからない。
コードを見ないと判断不可能。
>>571
ポンチ絵書く期間の話と、実装する期間の話をわざと混同してるよね？
ポンチ絵書く期間の話と、実装する期間の話をわざと混同してるよね？
実装には時間がかかるから、
実装の時間を極限まで減らすと
やり直しをする時間が取れる。
実際作ってみなきゃわからないこと多いんだしさ。
実装の時間を極限まで減らすと
やり直しをする時間が取れる。
実際作ってみなきゃわからないこと多いんだしさ。
で、今は組み込みや制御系の話？ それとも業務系？
業務系は人とのインタラクションが多くて、要件自体が細かいレベルであとあともコロコロ変わったりするから（結局使ってみなけりゃわからない）、設計文書は最小限にしてクイックに開発サイクルを何回も回すというのはよくある話。
その場合は開発と運用の距離も近くて、それでも何とかなったりする。
一口に業務系といっても、業界や業務領域によって違ったりもするけどね。
業務系は人とのインタラクションが多くて、要件自体が細かいレベルであとあともコロコロ変わったりするから（結局使ってみなけりゃわからない）、設計文書は最小限にしてクイックに開発サイクルを何回も回すというのはよくある話。
その場合は開発と運用の距離も近くて、それでも何とかなったりする。
一口に業務系といっても、業界や業務領域によって違ったりもするけどね。
文書は書いた方が絶対にいい。
プログラマーの仕事の半分は
仕様書書きにしても良いレベル。
SEとかいうゴミにはせめて
完璧な要件分析を期待したい
プログラマーの仕事の半分は
仕様書書きにしても良いレベル。
SEとかいうゴミにはせめて
完璧な要件分析を期待したい
完璧な要件分析とかするよりはざっくりと方向を作ってラウンドトリップで行く仕組みを確立した方が皆が幸せになるよね。
実際は色々と難しいと思うけど。
実際は色々と難しいと思うけど。
>>582
元レスも読めないなら黙ってた方が良いんでは？
元レスも読めないなら黙ってた方が良いんでは？
>>585
それがアジャイルでは？
それがアジャイルでは？
>>586
逃げたとみなすよ。
逃げたとみなすよ。
最近思ったんだけどさ、手描きのデジタル化のコストってものすごく下がったよな。
それほど重要な資料でも無いんだけど、必要だからアレコレ書いて、文章だけだと
ちょっと分かりづらいから図も入れるかってなった時に、前までだとペイントツールや
excelやwordなんかだと組み込みのを四苦八苦しながら作ってた。 今だとスマフォ
連携のノートで書いたのを撮ったり、液タブなんて安いのなんて1万切ってるんだから
そういうのを使うのも有りなんだなあと。 もちろん内部統制とかもあるだろうし、
納品用のドキュメントにはそのまま使えないだろうけど、内部で意識合わせ
する程度には十分なんだよな。
それほど重要な資料でも無いんだけど、必要だからアレコレ書いて、文章だけだと
ちょっと分かりづらいから図も入れるかってなった時に、前までだとペイントツールや
excelやwordなんかだと組み込みのを四苦八苦しながら作ってた。 今だとスマフォ
連携のノートで書いたのを撮ったり、液タブなんて安いのなんて1万切ってるんだから
そういうのを使うのも有りなんだなあと。 もちろん内部統制とかもあるだろうし、
納品用のドキュメントにはそのまま使えないだろうけど、内部で意識合わせ
する程度には十分なんだよな。
591 ：仕様書無しさん：2014/05/06(火) 22:50:35.79
要件定義は必要だな、何作っていいか解らないから
基本設計は必要だな、どう実装していいか解らないから
詳細設計は・・・・・ソース見た方が早くねぇ？
基本設計は必要だな、どう実装していいか解らないから
詳細設計は・・・・・ソース見た方が早くねぇ？
>>590
液タブ買うならホワイトボードに書いたのをスマホで撮るのが安上がり
液タブ買うならホワイトボードに書いたのをスマホで撮るのが安上がり
うちのところは仕様屋と設計屋と実装屋と検査屋がそれぞれ別の部署だから
書かざるを得ないし役立てざるを得ない。
役に立たないものは差し戻す。
書かざるを得ないし役立てざるを得ない。
役に立たないものは差し戻す。
>>592
社内での撮影は普通禁止では。
社内での撮影は普通禁止では。
テクニカルライティングの能力が高くないと本来、設計書を書けないのですが、
日本のソフト技術者のテクニカルライティング能力が低すぎますよね。
設計書を書けと命じても「日本語で書いたコードもどき」を書いてしまう。
コードもどきを書くなと命じるとスカスカの設計書になってしまう。
概念図を描けと命じると些末な事まで描いてしまい何を伝えたいのか分からない図になってしまう。
シーケンス図を書けと命じると矢印に吹き出しを付けてシーケンスでない事をゴチャゴチャ書く。
状態遷移表を書けと命じると些末な事まで状態とみなし表が破綻する。
なぜそうしたか理由を書けと命じると些末な決定事項にまで「後付で無理矢理考えた理由」を書きまくる。
日本のソフト技術者のテクニカルライティング能力が低すぎますよね。
設計書を書けと命じても「日本語で書いたコードもどき」を書いてしまう。
コードもどきを書くなと命じるとスカスカの設計書になってしまう。
概念図を描けと命じると些末な事まで描いてしまい何を伝えたいのか分からない図になってしまう。
シーケンス図を書けと命じると矢印に吹き出しを付けてシーケンスでない事をゴチャゴチャ書く。
状態遷移表を書けと命じると些末な事まで状態とみなし表が破綻する。
なぜそうしたか理由を書けと命じると些末な決定事項にまで「後付で無理矢理考えた理由」を書きまくる。
>>597
部下に具体的に指導出来ない無能な感じがします(´･_･`)
部下に具体的に指導出来ない無能な感じがします(´･_･`)
NEC系、日立系、東芝系などの大手ソフト会社に請負形態で発注した時の話です。
請負形態なので本当は命じてはいけないのですが
設計書があまりにも酷いのでやむにやまれず指導しています。
部下じゃないので指導しても人が替わってしまうと1からまた指導
請負形態なので本当は命じてはいけないのですが
設計書があまりにも酷いのでやむにやまれず指導しています。
部下じゃないので指導しても人が替わってしまうと1からまた指導
597ですが日本のソフト会社の皆さんは中国のソフト会社に
仕事を取られますよ
中国のソフト会社は日本語で仕事を受けてくれますが
単価が安いのに非常に優秀ですよ
日本のソフト会社の優位点は日本語が母国語という事だけです
でもその日本語が怪しい日本人技術者が多いw
仕事を取られますよ
中国のソフト会社は日本語で仕事を受けてくれますが
単価が安いのに非常に優秀ですよ
日本のソフト会社の優位点は日本語が母国語という事だけです
でもその日本語が怪しい日本人技術者が多いw
たしかに最近の中国オフショアは、日本人対策ができてきている感じがする。
>>601
2020年になくなる仕事としてもプログラマーは海外に仕事を取られるとして上がってたけどどうだろうね。
インド人のオフショアと99年ごろ関わってたけど優秀だけど良くも悪くも日本的な仕事の進め方と合わなそうな印象を受けた。
色々と通信環境含め変わって来たけどまだ顔を付き合わすこと、付き合わせられることの優位性も残ってそうだが。
2020年になくなる仕事としてもプログラマーは海外に仕事を取られるとして上がってたけどどうだろうね。
インド人のオフショアと99年ごろ関わってたけど優秀だけど良くも悪くも日本的な仕事の進め方と合わなそうな印象を受けた。
色々と通信環境含め変わって来たけどまだ顔を付き合わすこと、付き合わせられることの優位性も残ってそうだが。
>>595
> 設計書の本来の役割は、"何故そうしたか？"を判るようにする為の物。
> なので、ソース見た方が早い状況というのは、本来の目的を実現出来てない資料だというだけ。
ソースを書く上で行う類いの判断は、設計書に入れる必要は無い。
> 設計書の本来の役割は、"何故そうしたか？"を判るようにする為の物。
> なので、ソース見た方が早い状況というのは、本来の目的を実現出来てない資料だというだけ。
ソースを書く上で行う類いの判断は、設計書に入れる必要は無い。
設計書に理由も書いた方が良い例
例えば動画をストリーミング配信するシステムの開発を担当したとする
サーバーからクライアントアプリに動画のフレームを流すためにUDPを当然選択する
しかしお馬鹿さんはこの選択に対し「何故信頼性の高いTCPでなくメッセージを取りこぼすかもしれないUDPを使うの?」と疑問を持つ
この疑問に先回りし「動画のフレームなんて取りこぼしたら取りこぼしたで問題ないんだよ」「TCPで送信したら要求されたフレームレートを達成できないじゃん」と設計書に理由を書いてあげた方が良い
書いておかないと将来お馬鹿さんがコードの保守を担当した時、TCPを使うように改悪するかもしれないから
例えば動画をストリーミング配信するシステムの開発を担当したとする
サーバーからクライアントアプリに動画のフレームを流すためにUDPを当然選択する
しかしお馬鹿さんはこの選択に対し「何故信頼性の高いTCPでなくメッセージを取りこぼすかもしれないUDPを使うの?」と疑問を持つ
この疑問に先回りし「動画のフレームなんて取りこぼしたら取りこぼしたで問題ないんだよ」「TCPで送信したら要求されたフレームレートを達成できないじゃん」と設計書に理由を書いてあげた方が良い
書いておかないと将来お馬鹿さんがコードの保守を担当した時、TCPを使うように改悪するかもしれないから
597&601です
インドの会社に発注した事もありますがインド人は細かい条件闘争を仕掛けて来ますね
それにイチイチ応対する発注側(日本人)の工数が勿体ないので、インドから中国に切り替えました
中国のソフト会社の方が「損して得取れ」的な理屈が通じます
インドの会社に発注した事もありますがインド人は細かい条件闘争を仕掛けて来ますね
それにイチイチ応対する発注側(日本人)の工数が勿体ないので、インドから中国に切り替えました
中国のソフト会社の方が「損して得取れ」的な理屈が通じます
>中国のソフト会社は日本語で仕事を受けてくれますが 単価が安いのに非常に優秀ですよ
優秀なわけねーだろ
俺が引退した後は知らんが
かれらは商業民族、すぐ結果をもとめる。韓国もな
で、そういう民族は開発とは縁遠いな
日本人が開発するのをまっているよ。日本の引退した技術者歓迎ね
優秀なわけねーだろ
俺が引退した後は知らんが
かれらは商業民族、すぐ結果をもとめる。韓国もな
で、そういう民族は開発とは縁遠いな
日本人が開発するのをまっているよ。日本の引退した技術者歓迎ね
>>613
平均的な日本人と平均的な中国人と比べたら確かに日本人の方が優秀だよ
でも平均的な日本人プログラマと平均的な中国人プログラマを比べたら中国人プログラマの方が優秀
その理由は14億人もいる中国人のうち優秀な層がプログラマになっているから
日本ではプログラマはIT土方だけど中国でプログラマは高給取り
これは事実だから受け入れなよ
平均的な日本人と平均的な中国人と比べたら確かに日本人の方が優秀だよ
でも平均的な日本人プログラマと平均的な中国人プログラマを比べたら中国人プログラマの方が優秀
その理由は14億人もいる中国人のうち優秀な層がプログラマになっているから
日本ではプログラマはIT土方だけど中国でプログラマは高給取り
これは事実だから受け入れなよ
>>607
誰もそんな物を設計書に入れるとかいってないと思うが。
誰もそんな物を設計書に入れるとかいってないと思うが。
>>614
統計はとってないから知らんが、中国人の残したコードが負債のように放置されてるのは見たことがある。
実際たくさんの中から淘汰されてエリートだけが残ってるならイイと思うけど、どこ迄そうなってるかは疑問だわ。
統計はとってないから知らんが、中国人の残したコードが負債のように放置されてるのは見たことがある。
実際たくさんの中から淘汰されてエリートだけが残ってるならイイと思うけど、どこ迄そうなってるかは疑問だわ。
>>616
それは中国に仕事を出した人の要領が悪いだけです
発注先の中国のソフト会社と長期的な安定したWin/Winの関係を築けていないのです
まず、中国のソフト受託開発の業界には
元請け -> 下請け -> 孫受け -> ... というおかしな商習慣があまり無いです
このため日本ソフト会社より安定した関係を築き易いです
私が発注している中国の会社はプトジェクトメンバー全員がその会社の社員です
そのためか、こちらが安定的に発注していれば長期間メンバーを固定してくれます
まぁ工数単価が安いので開発の谷間に「優先度の低い仕事」を出して人員keepしやすいのですけどね
それは中国に仕事を出した人の要領が悪いだけです
発注先の中国のソフト会社と長期的な安定したWin/Winの関係を築けていないのです
まず、中国のソフト受託開発の業界には
元請け -> 下請け -> 孫受け -> ... というおかしな商習慣があまり無いです
このため日本ソフト会社より安定した関係を築き易いです
私が発注している中国の会社はプトジェクトメンバー全員がその会社の社員です
そのためか、こちらが安定的に発注していれば長期間メンバーを固定してくれます
まぁ工数単価が安いので開発の谷間に「優先度の低い仕事」を出して人員keepしやすいのですけどね
618 ：仕様書無しさん：2014/05/07(水) 21:47:42.96
ブリッジSEの給料をみたら
どれだけ困難な仕事か想像つくだろ
どれだけ困難な仕事か想像つくだろ
>>619
オフショア発注先の会社のブリッジSEに頼っていたらダメだよ
海の向こうの開発現場の人達と直接コンタクトする事がオフショア開発成功の秘訣
実は開発現場の人達との直接コンタクトはオフショアの方がやり易い
日本のソフト会社だと請負法の壁がありリーダー以外とコンタクトするなと小煩い事を言われるけど
海の向こうの開発現場には日本の法の支配が及ばない
オフショア発注先の会社のブリッジSEに頼っていたらダメだよ
海の向こうの開発現場の人達と直接コンタクトする事がオフショア開発成功の秘訣
実は開発現場の人達との直接コンタクトはオフショアの方がやり易い
日本のソフト会社だと請負法の壁がありリーダー以外とコンタクトするなと小煩い事を言われるけど
海の向こうの開発現場には日本の法の支配が及ばない
621 ：仕様書無しさん：2014/05/07(水) 22:32:45.90
好き勝手な事を言うカスタマーと開発チームの間で1人か2人の客先常駐者が板挟み
それって日本のソフトハウスを使った時も起きる事じゃね？
それって日本のソフトハウスを使った時も起きる事じゃね？
出来ない理由をあーだこーだ言っているような奴には
到底1時間でアメリカに行くことは出来ないだろうな。
どうやって行くか、答えてみろ。
到底1時間でアメリカに行くことは出来ないだろうな。
どうやって行くか、答えてみろ。
>>601
もう10何年も前からそう言われてるけど、結局中国は仕事が雑で単価が高く
なってきたからインドやらベトナムやら東南アジアあたりにオフショア先が
移ってるんだよね。 それに最近だとアメリカの法律でライセンス違反の
ソフトを使って開発されたものが一部でも組み込まれているような製品は
不正な競争のため元請けの製品そのものも輸入停止にするようなのも
出てきて実際止められてるのもあるし。 遵法精神に乏しい中国を使う
リスクのほうがはるかに高くなってきてるんだよな。 この法律自体は
最近出来たので、それほど知られてないけどね。
もう10何年も前からそう言われてるけど、結局中国は仕事が雑で単価が高く
なってきたからインドやらベトナムやら東南アジアあたりにオフショア先が
移ってるんだよね。 それに最近だとアメリカの法律でライセンス違反の
ソフトを使って開発されたものが一部でも組み込まれているような製品は
不正な競争のため元請けの製品そのものも輸入停止にするようなのも
出てきて実際止められてるのもあるし。 遵法精神に乏しい中国を使う
リスクのほうがはるかに高くなってきてるんだよな。 この法律自体は
最近出来たので、それほど知られてないけどね。
同じサービス業でも介護とかなら国境を越えられないけど
soft開発は簡単に国境を越えられるからなぁ
IT土方さん達は付加価値を付けないと生き残れないよ
soft開発は簡単に国境を越えられるからなぁ
IT土方さん達は付加価値を付けないと生き残れないよ
日本のIT土方はコミュ力低すぎて設計書なんて書けねー
という結論で おK?
という結論で おK?
627 ：仕様書無しさん：2014/05/07(水) 23:44:27.04
ウチの会社は糞真面目なので外注さんとフロアを別にされ
更に社員フロアに外注さんが入室できなくなった
アジャイル開発もへったくれも無くなり窓口のSEとmailを頻繁に投げ合うようになってしまった
でもmailの文面がイミフで話が噛み合わない
小回りが効かないのにLine単価がバカ高い金食い虫化してるんだけど
切った方がいいのかな
更に社員フロアに外注さんが入室できなくなった
アジャイル開発もへったくれも無くなり窓口のSEとmailを頻繁に投げ合うようになってしまった
でもmailの文面がイミフで話が噛み合わない
小回りが効かないのにLine単価がバカ高い金食い虫化してるんだけど
切った方がいいのかな
>>625
・日本はドイツに習って戦勝国に謝罪すべきだー
・日本はドイツに習って原子力発電計画を放棄すべきだー
・日本はプエルトリコに習って一切の軍隊を廃止すべきだー
・日本はスイスに習って永世中立国を目指すべきだー
という結論で おK?
・日本はドイツに習って戦勝国に謝罪すべきだー
・日本はドイツに習って原子力発電計画を放棄すべきだー
・日本はプエルトリコに習って一切の軍隊を廃止すべきだー
・日本はスイスに習って永世中立国を目指すべきだー
という結論で おK?
>>626
NECシステムソリューションに統合されなかった某社(通信機器も売ってる会社)のケース
我が社の民生用機器のサブシステムの開発とそのサブシステムが中核となる機能のシステム設計を委託
システム設計書は他のサブシステムの開発者も読むので当社標準のスタイルで書いて貰った
ここまでは良かったけどサブシステムの基本設計書が酷かった
ページ数の90%がシステム設計書のシーケンス図の焼き直し
システム全体の視点からサブシステムの内部設計に視点を切り替えず
「基本設計書でのシーケンス図」なる謎のページをコピペで大量作成
その後そのコピペシーケンス図をDFDで書き直し
DFDの内容はシステム設計書のシーケンス図とほぼ等価なのにサブシステムの内部設計が完了したと主張
システム設計書に書いた事を無駄に2回書き直しているだけだよね?
と指摘したら「この工程を踏まないと品質を担保できない」と逆切れ
いい加減にしてください
NECシステムソリューションに統合されなかった某社(通信機器も売ってる会社)のケース
我が社の民生用機器のサブシステムの開発とそのサブシステムが中核となる機能のシステム設計を委託
システム設計書は他のサブシステムの開発者も読むので当社標準のスタイルで書いて貰った
ここまでは良かったけどサブシステムの基本設計書が酷かった
ページ数の90%がシステム設計書のシーケンス図の焼き直し
システム全体の視点からサブシステムの内部設計に視点を切り替えず
「基本設計書でのシーケンス図」なる謎のページをコピペで大量作成
その後そのコピペシーケンス図をDFDで書き直し
DFDの内容はシステム設計書のシーケンス図とほぼ等価なのにサブシステムの内部設計が完了したと主張
システム設計書に書いた事を無駄に2回書き直しているだけだよね?
と指摘したら「この工程を踏まないと品質を担保できない」と逆切れ
いい加減にしてください
630 ：仕様書無しさん：2014/05/08(木) 01:16:25.32
>>620
請負法って、何だよｗ
別に法律で規制されてるわけじゃないが、大きいプロジェクトじゃ、
担当者からリーダへの報告系統があやしいから、リーダー通せってだけだろ。
実際、こまごました話を全部担当者直でやられたら、収拾がつかないってのはよくある。
請負法って、何だよｗ
別に法律で規制されてるわけじゃないが、大きいプロジェクトじゃ、
担当者からリーダへの報告系統があやしいから、リーダー通せってだけだろ。
実際、こまごました話を全部担当者直でやられたら、収拾がつかないってのはよくある。
>>631
下請法と派遣法だな。
下請法と派遣法だな。
何度同じ事を繰り返せば生まれ変われるのかな?
1) 顧客と仕様をそれなりに合意
2) コード何行、設計書何ページと成果量を見積もり
3) 成果量と基準単価から金額と開発期間を見積もり顧客に渋々合意させる
4) 儀式的な設計工程で開発期間を食い潰す
5) 設計書はあるけど設計できていないと社内で薄々気づくが顧客にはONスケジュールと報告
6) 見切り発車でコードを書き始めるが頻繁に設計の相談を行うので遅々として進まず
7) 顧客が遅れに気づき騒ぎ出す
8) 挽回のため追加メンバー投入
9) 一番仕事ができる奴が追加メンバーから質問責めになりオーバーフロー
10) 一番仕事ができる奴が倒れプロジェクト崩壊
1) 顧客と仕様をそれなりに合意
2) コード何行、設計書何ページと成果量を見積もり
3) 成果量と基準単価から金額と開発期間を見積もり顧客に渋々合意させる
4) 儀式的な設計工程で開発期間を食い潰す
5) 設計書はあるけど設計できていないと社内で薄々気づくが顧客にはONスケジュールと報告
6) 見切り発車でコードを書き始めるが頻繁に設計の相談を行うので遅々として進まず
7) 顧客が遅れに気づき騒ぎ出す
8) 挽回のため追加メンバー投入
9) 一番仕事ができる奴が追加メンバーから質問責めになりオーバーフロー
10) 一番仕事ができる奴が倒れプロジェクト崩壊
634 ：仕様書無しさん：2014/05/08(木) 02:12:34.45
>>631
偽装請負業者乙
偽装請負業者乙
635 ：仕様書無しさん：2014/05/08(木) 10:43:31.74
>アジャイル開発もへったくれも無くなり窓口のSEとmailを頻繁に投げ合うようになってしまった
でもmailの文面がイミフで話が噛み合わない
海外から、動画でここ直してくれっといってきた。動画がいいよ
近くのとこに納品したやつ。電話で、直してくれ、というのだけど、なにいっているか不明
くるまでとばして現地で確認。相手のいいたいことがわかった
でもmailの文面がイミフで話が噛み合わない
海外から、動画でここ直してくれっといってきた。動画がいいよ
近くのとこに納品したやつ。電話で、直してくれ、というのだけど、なにいっているか不明
くるまでとばして現地で確認。相手のいいたいことがわかった
>>618
無能集団はどんなやつがマネジメントしても無能でしかない
無能集団はどんなやつがマネジメントしても無能でしかない
上に立つものが馬鹿だと、下にいるものはそのレベルにになります
具体例だと、菅直人が馬鹿だったので、民主党はそのレベルになったということ
具体例だと、菅直人が馬鹿だったので、民主党はそのレベルになったということ
638 ：仕様書無しさん：2014/05/08(木) 12:17:22.78
納品物がコードだけならインドに発注した方が良くね?
639 ：仕様書無しさん：2014/05/08(木) 12:24:33.41
日本のsoft会社なんて国際競争力ゼロ
日本語が母国語という事だけが取柄
それしか取柄が無いのだから読んで理解できる文書を書けよ
打ち合わせの時にダラダラと結論不明な報告をするなよ
能無し君たち
日本語が母国語という事だけが取柄
それしか取柄が無いのだから読んで理解できる文書を書けよ
打ち合わせの時にダラダラと結論不明な報告をするなよ
能無し君たち
>>637
菅直人の前も後も、と言うかどれをとっても無能集団だっただろw
菅直人の前も後も、と言うかどれをとっても無能集団だっただろw
>>639
じゃあその能無しに仕事頼まずオフショアで中国人でもインド人でも好きなのに頼めばイイがな(´・ω・｀)
じゃあその能無しに仕事頼まずオフショアで中国人でもインド人でも好きなのに頼めばイイがな(´・ω・｀)
なぜアメリカ人やヨーロッパ人に頼むという発想がないのか
＞日本のsoft会社なんて国際競争力ゼロ
カルロス・ゴーンさんなら国際競争力ある会社にしてくれます。
上があほだと、下まであほになります
日露開戦で勝利したのでいつまでも、それを教科書にした日本軍と同じです
カルロス・ゴーンさんなら国際競争力ある会社にしてくれます。
上があほだと、下まであほになります
日露開戦で勝利したのでいつまでも、それを教科書にした日本軍と同じです
多分、中国でもインドでもいいものは作れない
継続という習慣がないわけ。すぐ会社をかわる。
会社を変わるというのは、彼らにしたらキャリアアップなわけ
そういうところでは技術は育たんよ
継続という習慣がないわけ。すぐ会社をかわる。
会社を変わるというのは、彼らにしたらキャリアアップなわけ
そういうところでは技術は育たんよ
645 ：仕様書無しさん：2014/05/08(木) 15:11:54.82
俺が仕事を出してる中国の会社は大手でkindleのソフト開発も受注している
そこらの日本のソフト会社はkindleのソフト開発の仕事なんて受注できないよね
日本企業の仕事だけだよね
そこらの日本のソフト会社はkindleのソフト開発の仕事なんて受注できないよね
日本企業の仕事だけだよね
>>629
委託元(>>629)としては、与えられたサブシステムの外部仕様を元にして
サブシステムを複数の機能構成要素(コンポーネント)へと適切に分解し、
それら構成要素間の関連が内部シーケンス図として基本設計書へ
記述されることを期待していた、ということでいいのかね？
まずは委託先某社の立場で弁護してみると、
>システム設計書に書いた事を無駄に2回書き直しているだけだよね?
>と指摘したら「この工程を踏まないと品質を担保できない」と逆切れ
の箇所だけど、設計書の表記法や語彙体系は開発組織の文化的側面があるから、
外部から与えられた設計書を自分達が慣れ親しんだ表記/様式へと書き直すというのは
決して一方的に断罪されるべきではないと思う
あと気になる点を挙げる
・この案件のスケジュールや最終的な納期および品質が分からんことには....
・委託契約の内容がどうなっていたのか、
言い換えると、某社の行為が契約違反に該当していたのか？
・>>600によれば、多くの国内メーカ系との間で委託開発があるみたいだけど、
このN系某社は最悪のケースだったのか、それともよくあるケースの具体例なのか？
・もしもありふれているのならば、業務委託の発注元としてリスク管理に何か問題は
無かったのか、一言で言えば、自社として万全を尽くしていたと言い切れるのか？
>>629が同情を期待していたなら厳しすぎる意見かもしれんが、マジレスしてみた
委託元(>>629)としては、与えられたサブシステムの外部仕様を元にして
サブシステムを複数の機能構成要素(コンポーネント)へと適切に分解し、
それら構成要素間の関連が内部シーケンス図として基本設計書へ
記述されることを期待していた、ということでいいのかね？
まずは委託先某社の立場で弁護してみると、
>システム設計書に書いた事を無駄に2回書き直しているだけだよね?
>と指摘したら「この工程を踏まないと品質を担保できない」と逆切れ
の箇所だけど、設計書の表記法や語彙体系は開発組織の文化的側面があるから、
外部から与えられた設計書を自分達が慣れ親しんだ表記/様式へと書き直すというのは
決して一方的に断罪されるべきではないと思う
あと気になる点を挙げる
・この案件のスケジュールや最終的な納期および品質が分からんことには....
・委託契約の内容がどうなっていたのか、
言い換えると、某社の行為が契約違反に該当していたのか？
・>>600によれば、多くの国内メーカ系との間で委託開発があるみたいだけど、
このN系某社は最悪のケースだったのか、それともよくあるケースの具体例なのか？
・もしもありふれているのならば、業務委託の発注元としてリスク管理に何か問題は
無かったのか、一言で言えば、自社として万全を尽くしていたと言い切れるのか？
>>629が同情を期待していたなら厳しすぎる意見かもしれんが、マジレスしてみた
ハードウェアベンダーや、その関連会社が出してる「仕様書」ってひどいものが多いからねぇ。
「システム設計書のシーケンス図」なるものから、直接プログラムをかけるケースは経験上ほぼ皆無。
「システム設計書のシーケンス図」なるものから、直接プログラムをかけるケースは経験上ほぼ皆無。
648 ：仕様書無しさん：2014/05/08(木) 15:23:28.55
>>646
シーケンス図をDFDに書き換えても何も付加価値が生じない事を理解してるの？
シーケンス図をDFDに書き換えても何も付加価値が生じない事を理解してるの？
>中国の会社は大手でkindleのソフト開発も受注している
インドの会社でWindowsの開発にたずさわっている、というのがあったけど
バグとり専門会社だろうとおもった
中国に出すのは、もっぱらコピーOKという部分
インドの会社でWindowsの開発にたずさわっている、というのがあったけど
バグとり専門会社だろうとおもった
中国に出すのは、もっぱらコピーOKという部分
629ですけど同情して頂かなくて結構です
このスレのスレタイと照らし合わせて読んで下さい
設計書が開発に役立った事があるか? という"お題"に対し
NEC系の割と知名度のある会社が役立たずの設計書しか書けなかったと紹介したまでです
システム設計書で書いた事のコピペ分を除くとスカスカの基本設計書しか書けなかったという話です
このスレのスレタイと照らし合わせて読んで下さい
設計書が開発に役立った事があるか? という"お題"に対し
NEC系の割と知名度のある会社が役立たずの設計書しか書けなかったと紹介したまでです
システム設計書で書いた事のコピペ分を除くとスカスカの基本設計書しか書けなかったという話です
>>646
見積書にxxサブシステム基本設計書 xx頁
と書いた以上、それが契約内容になります
表紙に基本設計書と書いてあるだけでは契約を履行した事になりません
見積書に別工程として書いてあるシステム設計書と書いてある事が同じなら
その分は基本設計書の量としてカウントできません
どうしてもコピペで嵩を増やしたければご自由にやってくれて良いですが、
コピペで嵩を増やしても納品物にカウントできません
それが顧客に見積書を提出するという事です
見積書にxxサブシステム基本設計書 xx頁
と書いた以上、それが契約内容になります
表紙に基本設計書と書いてあるだけでは契約を履行した事になりません
見積書に別工程として書いてあるシステム設計書と書いてある事が同じなら
その分は基本設計書の量としてカウントできません
どうしてもコピペで嵩を増やしたければご自由にやってくれて良いですが、
コピペで嵩を増やしても納品物にカウントできません
それが顧客に見積書を提出するという事です
>>644
欧米のエンジニアは会社を転々としてるけど、競争力あるソフト作ってるよ？
欧米のエンジニアは会社を転々としてるけど、競争力あるソフト作ってるよ？
654 ：仕様書無しさん：2014/05/08(木) 22:31:02.56
IT土方ってタチ悪いね
655 ：仕様書無しさん：2014/05/08(木) 22:34:41.87
転職で退社する奴がいるなら
転職で入社する奴もいる
という簡単な事が分からないバカなんじゃないの？
転職で入社する奴もいる
という簡単な事が分からないバカなんじゃないの？
>>651
>>646後半の疑問点についてはどうなの？
閉じた組織内であっても役に立つ開発文書の高品質化は難しい
ましてや外部への開発委託であればなおさら難しくなる
そのために昔からシステム開発ではリスク管理が重要視されてきた
で、発注元として>>651がリスク管理を怠っていたのではないのか？
というのが>>646後半の懸念になる
>>652
もしも言葉とおりに「xxサブシステム基本設計書 xx頁」としか
書かれていなかったのなら、契約不履行にはならんよね
リスク管理における契約では「成果物の曖昧さを排除する」というのが
原則の一つだけど、契約書の付属資料等で
基本設計書の文書構成や要件は具体的に明記されていたの？
単に明記されていなかったのなら、発注側にもリスク管理の問題がある
もしかすると実はN系某社は役に立つ設計書を書けたのかもしれない
>>646後半の疑問点についてはどうなの？
閉じた組織内であっても役に立つ開発文書の高品質化は難しい
ましてや外部への開発委託であればなおさら難しくなる
そのために昔からシステム開発ではリスク管理が重要視されてきた
で、発注元として>>651がリスク管理を怠っていたのではないのか？
というのが>>646後半の懸念になる
>>652
もしも言葉とおりに「xxサブシステム基本設計書 xx頁」としか
書かれていなかったのなら、契約不履行にはならんよね
リスク管理における契約では「成果物の曖昧さを排除する」というのが
原則の一つだけど、契約書の付属資料等で
基本設計書の文書構成や要件は具体的に明記されていたの？
単に明記されていなかったのなら、発注側にもリスク管理の問題がある
もしかすると実はN系某社は役に立つ設計書を書けたのかもしれない
>>653
そこそこ名の知れているのは会社が売られたor売れた、会社でのポジションが
上がりに近いから責任取らされたor引っこ抜かれたって感じだけどね。
中国とかによくいる、給料が高いから転々とするっていうような人だと欧米でも
同じような埋もれて人並み程度に収まってるでしょ。
そこそこ名の知れているのは会社が売られたor売れた、会社でのポジションが
上がりに近いから責任取らされたor引っこ抜かれたって感じだけどね。
中国とかによくいる、給料が高いから転々とするっていうような人だと欧米でも
同じような埋もれて人並み程度に収まってるでしょ。
>>656
キミはスレタイから論点をズラして能力の低い会社を擁護しているとしか思えないんだけど何を言いたいの?
次工程の文書の殆どが前工程の文書のコピペなんて許されないでしょ
そんな事までリスクとしてList upしていたら有り得ない出来事をあれこれと想定しリスクだらけになってしまうよ
キミはスレタイから論点をズラして能力の低い会社を擁護しているとしか思えないんだけど何を言いたいの?
次工程の文書の殆どが前工程の文書のコピペなんて許されないでしょ
そんな事までリスクとしてList upしていたら有り得ない出来事をあれこれと想定しリスクだらけになってしまうよ
659 ：仕様書無しさん：2014/05/09(金) 00:47:17.90
要求仕様書にバグ無き事と書いていた同僚がいたなw
これってリスク管理した事になる?
これってリスク管理した事になる?
やってみせ、言って聞かせて、させてみせ、ほめてやらねば、人は動かじ。
山本五十六
単価が安くて人をコロコロ変えないならそれもアリかな
単価が高ければ出来て当たり前としかw
山本五十六
単価が安くて人をコロコロ変えないならそれもアリかな
単価が高ければ出来て当たり前としかw
>>658
開発委託って発注側と請負側での意思疎通が難しい
請負側にも高い技術力が必要だけど、
発注側にも高いプロジェクト管理能力が要求される
>そんな事までリスクとしてList upしていたら
そんな事と言ってるけど、成果物の曖昧さを排除するため
発注書に文書構成や要件を具体的に明記するのはSIerなら常識
まともなSIerなら社内規約に従って発注書を書いていくから
こんなトラブルは起きないし、起きても契約不履行に持ち込める
納品された設計書が役に立たなかったのは表面の事象であって、
委託開発の発注側として根本原因を探り再発防止策を考えるのは
当たり前の議論じゃないかと思うけどね
単純細胞で相手の技術力不足と見下すだけでは、何も成長しない
開発委託って発注側と請負側での意思疎通が難しい
請負側にも高い技術力が必要だけど、
発注側にも高いプロジェクト管理能力が要求される
>そんな事までリスクとしてList upしていたら
そんな事と言ってるけど、成果物の曖昧さを排除するため
発注書に文書構成や要件を具体的に明記するのはSIerなら常識
まともなSIerなら社内規約に従って発注書を書いていくから
こんなトラブルは起きないし、起きても契約不履行に持ち込める
納品された設計書が役に立たなかったのは表面の事象であって、
委託開発の発注側として根本原因を探り再発防止策を考えるのは
当たり前の議論じゃないかと思うけどね
単純細胞で相手の技術力不足と見下すだけでは、何も成長しない
>>657
> そこそこ名の知れているのは会社が売られたor売れた、会社でのポジションが
> 上がりに近いから責任取らされたor引っこ抜かれたって感じだけどね。
それは、ニュースになるのがそういうケースばかりだからね。
> 中国とかによくいる、給料が高いから転々とするっていうような人だと欧米でも
> 同じような埋もれて人並み程度に収まってるでしょ。
日本と違って、同じ会社に長く勤めたら給料が上がるわけでもないからね。
> そこそこ名の知れているのは会社が売られたor売れた、会社でのポジションが
> 上がりに近いから責任取らされたor引っこ抜かれたって感じだけどね。
それは、ニュースになるのがそういうケースばかりだからね。
> 中国とかによくいる、給料が高いから転々とするっていうような人だと欧米でも
> 同じような埋もれて人並み程度に収まってるでしょ。
日本と違って、同じ会社に長く勤めたら給料が上がるわけでもないからね。
>>661
設計書に何を書くのか分かっていない能力低い会社に設計書の要件を提示しても
結局その会社から期待した成果物が納品されないよ
見積額が高くなり完了予定日が遅くなるだけ
QCDのCとDが悪くなるだけ
開発着手前にふるいにかける目的なら有効だけどね
設計書に何を書くのか分かっていない能力低い会社に設計書の要件を提示しても
結局その会社から期待した成果物が納品されないよ
見積額が高くなり完了予定日が遅くなるだけ
QCDのCとDが悪くなるだけ
開発着手前にふるいにかける目的なら有効だけどね
664 ：仕様書無しさん：2014/05/09(金) 02:03:07.83
ガイドラインとテンプレートと見本を渡せば能力が低い奴でも設計書が書けると考えるのはお花畑
テンプレートのマスに何でもいいから何か埋めて来て「御指示に従った結果です」と言い訳するだけ
ガイドラインなんてあるべき姿を理想論で書く事ができるだけ
自然言語主体で設計書を書く以上、
ガイドラインの遵守度を定量的に計測する事は困難
テンプレートのマスに何でもいいから何か埋めて来て「御指示に従った結果です」と言い訳するだけ
ガイドラインなんてあるべき姿を理想論で書く事ができるだけ
自然言語主体で設計書を書く以上、
ガイドラインの遵守度を定量的に計測する事は困難
666 ：仕様書無しさん：2014/05/09(金) 09:13:50.00
>もしも言葉とおりに「xxサブシステム基本設計書 xx頁」としか 書かれていなかったのなら、契約不履行にはならんよね
>リスク管理における契約では「成果物の曖昧さを排除する」というのが 原則の一つだけど、契約書の付属資料等で 基本設計書の文書構成や要件は具体的に明記されていたの？
おまえ菅直人並みに見えるよ。菅直人は法に則り行動した。
つまりマニュアルどおりしかできない。
彼があほだったかは、知っているだろ？
>リスク管理における契約では「成果物の曖昧さを排除する」というのが 原則の一つだけど、契約書の付属資料等で 基本設計書の文書構成や要件は具体的に明記されていたの？
おまえ菅直人並みに見えるよ。菅直人は法に則り行動した。
つまりマニュアルどおりしかできない。
彼があほだったかは、知っているだろ？
667 ：仕様書無しさん：2014/05/09(金) 09:16:31.97
>>1
おまえが低層の１０００００００００００００００００００次請会社ってことがわかる
おまえが低層の１０００００００００００００００００００次請会社ってことがわかる
669 ：仕様書無しさん：2014/05/09(金) 10:47:21.69
発注元から見ると1次請負ってピンハネしてるだけじゃないの?
と思えてしまう
と思えてしまう
670 ：仕様書無しさん：2014/05/09(金) 10:51:50.74
そもそも、正しい設計書ってなんだろうね？
お客様が満足するもの、ってのも解で、請負ならそれでいいんだろうけど、
発注する側になると、俺が理解できるもの、っていうあいまいな基準じゃ
だめなんだよね。
なんかいい本ある？
お客様が満足するもの、ってのも解で、請負ならそれでいいんだろうけど、
発注する側になると、俺が理解できるもの、っていうあいまいな基準じゃ
だめなんだよね。
なんかいい本ある？
>>
670
横線を1本引き、その左端に仕様書、右端にコードと書いてみて。
設計書とは仕様書とコードの中間の位置に存在する物だよ。
でも中間の位置の設計書をなかなか書けない。
日本語でコードもどきを書いてしまう人がいるけど、
それじゃ右端とほぼ同じ。
仕様書からのコピペだらけの設計書を書いてしまう人がいるけど
それじゃ左端とほぼ同じ。
670
横線を1本引き、その左端に仕様書、右端にコードと書いてみて。
設計書とは仕様書とコードの中間の位置に存在する物だよ。
でも中間の位置の設計書をなかなか書けない。
日本語でコードもどきを書いてしまう人がいるけど、
それじゃ右端とほぼ同じ。
仕様書からのコピペだらけの設計書を書いてしまう人がいるけど
それじゃ左端とほぼ同じ。
672 ：仕様書無しさん：2014/05/09(金) 11:25:30.46
673 ：仕様書無しさん：2014/05/09(金) 11:45:30.08
ありがちなパターン
関数仕様書のテンプレートをexcelで作成して配布
そしてある関数の関数仕様をそのテンプレートを使って書くと...
タイトル記入欄に hogehoge登録関数と書き
関数名はRegisterHogeHogeとか書き
引数欄には引数の名前だけ書き
関数の機能の欄に「hogehoge登録」とだけ書いて完了
タイトルの文の言葉尻を変えただけじゃんと指摘すると
日本語でゴチャゴチャとコードみたいなモノを書き始める
関数仕様書のテンプレートをexcelで作成して配布
そしてある関数の関数仕様をそのテンプレートを使って書くと...
タイトル記入欄に hogehoge登録関数と書き
関数名はRegisterHogeHogeとか書き
引数欄には引数の名前だけ書き
関数の機能の欄に「hogehoge登録」とだけ書いて完了
タイトルの文の言葉尻を変えただけじゃんと指摘すると
日本語でゴチャゴチャとコードみたいなモノを書き始める
674 ：仕様書無しさん：2014/05/09(金) 12:26:12.94
設計書の話じゃないけど本は話半分のつもりで読んだ方がいいよ
昔、新入社員の女の子から「オブジェクト指向は難しいですぅー」と相談された
国立大学の情報系の学部を出た娘でとても真面目な性格
小学校の時に学級委員に立候補しちゃうような娘
その娘にどこが難しいの? と聞いたら
「多重継承を何に使えば良いのか分かりません」、「試しに使ってみても無理矢理使ってる気がします」
「私設計のセンスが無いのでしょうか」と言われた
多重継承が当てはまる事柄が無ければ使わなくていいんだよと教えてあげたら
「目から鱗が落ちました」と感謝された
昔、新入社員の女の子から「オブジェクト指向は難しいですぅー」と相談された
国立大学の情報系の学部を出た娘でとても真面目な性格
小学校の時に学級委員に立候補しちゃうような娘
その娘にどこが難しいの? と聞いたら
「多重継承を何に使えば良いのか分かりません」、「試しに使ってみても無理矢理使ってる気がします」
「私設計のセンスが無いのでしょうか」と言われた
多重継承が当てはまる事柄が無ければ使わなくていいんだよと教えてあげたら
「目から鱗が落ちました」と感謝された
675 ：仕様書無しさん：2014/05/09(金) 12:49:24.61
本は読んだ方がいいけど
本に即効性のある解決策を期待しすぎると教条主義に陥る
そしていつの間にか本に書いてある通りにやる事が目的になってしまう
本に即効性のある解決策を期待しすぎると教条主義に陥る
そしていつの間にか本に書いてある通りにやる事が目的になってしまう
676 ：仕様書無しさん：2014/05/09(金) 13:22:05.92
>設計書の話じゃないけど本は話半分のつもりで読んだ方がいいよ
学校教育という場で、15年マインドコントロールされちゃってるんで
碌な大人にならない。古典は日本の伝統だとか、源氏物語がすぐれている、とかいうのよ
社会科と古典が好きなのはプログラマに向いていないね。
数学好きがいいよ。源氏物語の話なんかあほらしくて聞いていられんね
学校教育という場で、15年マインドコントロールされちゃってるんで
碌な大人にならない。古典は日本の伝統だとか、源氏物語がすぐれている、とかいうのよ
社会科と古典が好きなのはプログラマに向いていないね。
数学好きがいいよ。源氏物語の話なんかあほらしくて聞いていられんね
677 ：仕様書無しさん：2014/05/09(金) 13:30:01.62
678 ：仕様書無しさん：2014/05/09(金) 13:52:33.68
客先に送り込むPGの履歴書?みたいな書類を平気で渡してくれた頃の話しだけど
フランス文学を専攻してました
会社の導入教育を3ヶ月受けました
お客様の現場のOJTで実務を勉強します
なんて事をしゃーしゃーとぬかす会社があったな
最近は履歴書の類を貰えないので経歴がよーわからんけど
今でも畑違いのPGを毎年入社させてるのかな？
フランス文学を専攻してました
会社の導入教育を3ヶ月受けました
お客様の現場のOJTで実務を勉強します
なんて事をしゃーしゃーとぬかす会社があったな
最近は履歴書の類を貰えないので経歴がよーわからんけど
今でも畑違いのPGを毎年入社させてるのかな？
679 ：仕様書無しさん：2014/05/09(金) 14:00:44.65
コックの場合、その店の店員の賄い飯を作らせて先輩達からマズイと厳しい指摘を受け
腕を上げてから客の料理を作らせるよね
情報系の学生以外は即戦力じゃないから畑違いの学生を入社させるなら
自社で使うソフト(賄い飯)でも作らせて経験を積ませてからよこして欲しいよ
腕を上げてから客の料理を作らせるよね
情報系の学生以外は即戦力じゃないから畑違いの学生を入社させるなら
自社で使うソフト(賄い飯)でも作らせて経験を積ませてからよこして欲しいよ
数学科より建築科の方が使えるかも
ガントチャート書いてタスクの依存関係を表現したり
計画のクリティカルパスを見つける手法が同じだから
ガントチャート書いてタスクの依存関係を表現したり
計画のクリティカルパスを見つける手法が同じだから
681 ：仕様書無しさん：2014/05/09(金) 15:08:54.58
土方からピンハネするだけの簡単な仕事です
商品は労力です
コードや設計書はオマケです
商品の量を表す単位は人月です
行数やページ数ではありません
お望みなら人月でなく土方の体重を単位にできますよ
キロ何円で売りましょうか?
商品は労力です
コードや設計書はオマケです
商品の量を表す単位は人月です
行数やページ数ではありません
お望みなら人月でなく土方の体重を単位にできますよ
キロ何円で売りましょうか?
682 ：仕様書無しさん：2014/05/09(金) 15:43:55.46
神経質なガリガリ君よりも図太いデブの方が潰れないから
PG計り売りはアリかもw
ただ期間の概念は必要なので単位はキロ月
体重100kgのPGが1ヶ月仕事したら、100キロ月
体重が50kgのPG 2人が1ヶ月仕事しても100キロ月
PG計り売りはアリかもw
ただ期間の概念は必要なので単位はキロ月
体重100kgのPGが1ヶ月仕事したら、100キロ月
体重が50kgのPG 2人が1ヶ月仕事しても100キロ月
なんか面白いこといってるつもりなのか(´・ω・｀)
たしか、ここは雑談スレだったよね？
壊れたプログラマースレですがなにか
686 ：仕様書無しさん：2014/05/09(金) 16:31:04.74
>>683
人月払いを求めるゲスなソフトハウスへの皮肉だよ
対価は本来、成果物の価値に対して支払うモノ
しかし価値を定量化する事が難しいから次善の策として成果物の量で金を払いたい
人月もキロ月も金払う側には関係の無い話なんだよ
オマエの体重がどうでもいい事と同様に
コードや設計書を書くためにオマエが何時間働いたかなんて
知ったこっちゃねーんだよ
人月払いを求めるゲスなソフトハウスへの皮肉だよ
対価は本来、成果物の価値に対して支払うモノ
しかし価値を定量化する事が難しいから次善の策として成果物の量で金を払いたい
人月もキロ月も金払う側には関係の無い話なんだよ
オマエの体重がどうでもいい事と同様に
コードや設計書を書くためにオマエが何時間働いたかなんて
知ったこっちゃねーんだよ
687 ：仕様書無しさん：2014/05/09(金) 18:00:38.69
顧客から開発を打診されたら簡単ですよと答え
とりあえず開発に着手する
発注先を切り替えられない時期になったら
顧客のせいにして案件がいかに難易度が高いかを力説する
やりかけの案件は人質
保守に役立つ設計書を残してはいけない
残してしまったら別の会社に切り替えるハードルを下げてしまう
という事だよね
とりあえず開発に着手する
発注先を切り替えられない時期になったら
顧客のせいにして案件がいかに難易度が高いかを力説する
やりかけの案件は人質
保守に役立つ設計書を残してはいけない
残してしまったら別の会社に切り替えるハードルを下げてしまう
という事だよね
690 ：仕様書無しさん：2014/05/09(金) 19:18:22.18
>>688
Line単価×Line数の方が人月よりまとも
Line単価×Line数の方が人月よりまとも
691 ：仕様書無しさん：2014/05/09(金) 19:21:53.77
>>688
ピンハネ1次請業者乙
ピンハネ1次請業者乙
692 ：仕様書無しさん：2014/05/09(金) 19:32:11.05
>>688
>>>686
>んじゃ人月より妥当な定量化手段出せよ。
>ソフトウェアを作るのにかかる平均的な技術者の労働量ってのは妥当な数値だと思うが。
キミが言ってる平均的な技術者の労働量が次のモデルを使うという意味なら
仕事の量を労働量、成果量のどちらで表現しても同じ事
平均的な生産性での労働量 = 成果量 / 平均的な生産性
>>>686
>んじゃ人月より妥当な定量化手段出せよ。
>ソフトウェアを作るのにかかる平均的な技術者の労働量ってのは妥当な数値だと思うが。
キミが言ってる平均的な技術者の労働量が次のモデルを使うという意味なら
仕事の量を労働量、成果量のどちらで表現しても同じ事
平均的な生産性での労働量 = 成果量 / 平均的な生産性
693 ：仕様書無しさん：2014/05/09(金) 19:48:23.03
いかにも出世しそうなヤリ手タイプのSEがやってきたら要注意
そいつのヤリ手な能力はボッタくる事に注がれる
出世コースから外れそうなタイプだがソフト開発が大好きなタイプのSEの方が
リーズナブルな金額に収まる
そいつのヤリ手な能力はボッタくる事に注がれる
出世コースから外れそうなタイプだがソフト開発が大好きなタイプのSEの方が
リーズナブルな金額に収まる
694 ：仕様書無しさん：2014/05/09(金) 20:41:07.48
実績工数で金を払って良いのは少数精鋭のチームを作ってくれる場合だけだよね
695 ：仕様書無しさん：2014/05/09(金) 21:14:18.68
>>693
補足しとくけど
ヤリ手SEがボッタくると言っても水増し請求するわけじゃないけどね
上手く回せば3人で開発できる案件に10人投入しようと画策するパターンね
別の案件が終わって手が空く人間を全員ぶち込みたくて必死に仕事を増やそうとするヤリ口の事だよ
頼んでいないのに仕様追加の提案をしたり
別件で起こした重大不具合を分析した結果だと称して
重厚長大なプロセスを提案したりしてプロジェクトを「 おおごと」にしてくるヤリ口ね
補足しとくけど
ヤリ手SEがボッタくると言っても水増し請求するわけじゃないけどね
上手く回せば3人で開発できる案件に10人投入しようと画策するパターンね
別の案件が終わって手が空く人間を全員ぶち込みたくて必死に仕事を増やそうとするヤリ口の事だよ
頼んでいないのに仕様追加の提案をしたり
別件で起こした重大不具合を分析した結果だと称して
重厚長大なプロセスを提案したりしてプロジェクトを「 おおごと」にしてくるヤリ口ね
696 ：仕様書無しさん：2014/05/09(金) 22:43:46.61
>>670
最近組込系で少し流行っているシステムxxという会社の清水某というヤツの本は絶対読んじゃダメ
ウォーターフォールを更にお役所仕事化したコードすぐに書かせない我流の方法論を広めようとしている
アジャイルとか海外でも認められている方法論の勉強をした方がいいよ
最近組込系で少し流行っているシステムxxという会社の清水某というヤツの本は絶対読んじゃダメ
ウォーターフォールを更にお役所仕事化したコードすぐに書かせない我流の方法論を広めようとしている
アジャイルとか海外でも認められている方法論の勉強をした方がいいよ
ヤリ手のSE君(ピンハネ手配師君)にとってアジャイルって禁句だよね?
>>695
実績払いでも水増し請求があるよ
今手元にある4月作業分の請求書の請求額が833万3千円
これ悪魔の数字です
1億円を12で割って千円未満の端数を切り捨てるとジャスト833万3千円w
なんでしょね? 実績払いなのにこのキリが良すぎる請求額
偉い人から本年度の売上ノルマを言い渡されたのかな?
実績払いでも水増し請求があるよ
今手元にある4月作業分の請求書の請求額が833万3千円
これ悪魔の数字です
1億円を12で割って千円未満の端数を切り捨てるとジャスト833万3千円w
なんでしょね? 実績払いなのにこのキリが良すぎる請求額
偉い人から本年度の売上ノルマを言い渡されたのかな?
> 端数を切り捨てるとジャスト
端数がある時点でジャストじゃない
端数がある時点でジャストじゃない
最終月は切り捨て分もぶっこむだけだろ
701 ：仕様書無しさん：2014/05/09(金) 23:58:27.32
>>698
上司か営業か何者かの強烈な意志を感じる数字だよね
上司か営業か何者かの強烈な意志を感じる数字だよね
で、設計書が開発に役立った事は無い
という結論でおK?
という結論でおK?
>>704
コメントだけ書いて、処理実装してないコードから生成すれば？
コメントだけ書いて、処理実装してないコードから生成すれば？
>>705
テキストファイルの一種であるソースファイルから自分で書いたテキストを抜き出す事を生成と言ってはダメだよ
テキストファイルの一種であるソースファイルから自分で書いたテキストを抜き出す事を生成と言ってはダメだよ
>>690
言語によっても書き方によっても変わる数値だろそれw
オブジェクト指向使ったら、関数型使ったら、このフレームワーク使ったらでどんだけ変わるか正確な数値持ってるのかお前は。
>>692
だからその成果量をそれなりに表す数値が他にあるなら教えてくれ。
言語によっても書き方によっても変わる数値だろそれw
オブジェクト指向使ったら、関数型使ったら、このフレームワーク使ったらでどんだけ変わるか正確な数値持ってるのかお前は。
>>692
だからその成果量をそれなりに表す数値が他にあるなら教えてくれ。
708 ：仕様書無しさん：2014/05/10(土) 02:17:14.69
代案も出さずに否定だけするのはカスのやることだろ(´･_･`)
EVMをちゃんとやるなら、人月でも可。
丼勘定やKKDじゃ限界が低いって言う、当たり前の事を言い換えただけのものだが。
丼勘定やKKDじゃ限界が低いって言う、当たり前の事を言い換えただけのものだが。
712 ：仕様書無しさん：2014/05/10(土) 03:21:55.19
なんか舌足らずの奴ばかりで結論が良く分からんなw
要求仕様に対し金額を見積もり
これ以上は請求しませんと事前に請求額を確定する話なんだよね?
要求仕様に対し金額を見積もり
これ以上は請求しませんと事前に請求額を確定する話なんだよね?
ステップ数で見積もるのが某社のやり方
あえて関数化しないという方法が使えたり
あえて関数化しないという方法が使えたり
設計書は契約のために、客に見せるために必要で。
開発に使うためのものになっていない。
開発に使うためのものになっていない。
＞なんか舌足らずの奴ばかりで結論が良く分からんなw
俺もよく分からんかったのだが「丼勘定やKKDじゃ限界が低いって言う、当たり前の事を言い換えた」
という発言、KKDという手法を分かるか？
経験と感と度胸の略だな。じつはこの手法はスピードが優れている。
ここからみると、何をチンタラやっているだろ、としか思えない
俺もよく分からんかったのだが「丼勘定やKKDじゃ限界が低いって言う、当たり前の事を言い換えた」
という発言、KKDという手法を分かるか？
経験と感と度胸の略だな。じつはこの手法はスピードが優れている。
ここからみると、何をチンタラやっているだろ、としか思えない
>>713
社内のコーディング規約があるんですぅーと言い張ってやたら改行するバカな会社がいる
例えばこう書けば3行で済むのに
if( ) {
} else {
}
こんな書き方をして6行も使うw
if( )
{
}
else
{
}
これって成果量を多くカウントするための水増しだよねw
社内のコーディング規約があるんですぅーと言い張ってやたら改行するバカな会社がいる
例えばこう書けば3行で済むのに
if( ) {
} else {
}
こんな書き方をして6行も使うw
if( )
{
}
else
{
}
これって成果量を多くカウントするための水増しだよねw
>>719
どうでもいいよそんなこと
どうでもいいよそんなこと
設計書なんて書いてはいけません
コードを読みやすくしてはいけません
ソフト会社にとって自殺行為です
ソフトの保守性を上げたら単価の安い他社に切り替えられてしまいます
開発中のソフト、開発済のソフトは人質です
開発の継続や保守のために顧客は金を払わざるを得ません
我が社がいなけりゃ顧客の業務が止まる、我が社がいなけりゃ製品を出荷できない
顧客をそんな状況にいかに追い込むかがSEの腕の見せ所です
技術者の良心? そんなモノは今すぐゴミ箱に捨てて下さい
所詮、IT土方からピンハネする手配師なんです
割り切りましょう
という事だよね?
コードを読みやすくしてはいけません
ソフト会社にとって自殺行為です
ソフトの保守性を上げたら単価の安い他社に切り替えられてしまいます
開発中のソフト、開発済のソフトは人質です
開発の継続や保守のために顧客は金を払わざるを得ません
我が社がいなけりゃ顧客の業務が止まる、我が社がいなけりゃ製品を出荷できない
顧客をそんな状況にいかに追い込むかがSEの腕の見せ所です
技術者の良心? そんなモノは今すぐゴミ箱に捨てて下さい
所詮、IT土方からピンハネする手配師なんです
割り切りましょう
という事だよね?
>>723
木を見て森を見ずクンかw
木を見て森を見ずクンかw
726 ：仕様書無しさん：2014/05/10(土) 12:42:22.73
>716
いまだにステップ数(笑)で評価してるのも問題だな
つーか個人的にはわりとわかる
for (略);
{
略
}
と書いて想定通りに動かず小一時間悩んでるアホを見たときはﾜﾛﾀ
いまだにステップ数(笑)で評価してるのも問題だな
つーか個人的にはわりとわかる
for (略);
{
略
}
と書いて想定通りに動かず小一時間悩んでるアホを見たときはﾜﾛﾀ
728 ：仕様書無しさん：2014/05/10(土) 12:52:43.21
改行はステップ数に含まれないのでどうでもいい。
重要なのは一点。コードの読みやすさ。じゃあ改行を入れるのと
入れないのどっちが見やすいかといえば、それは、コードの内容による。
小説を考えればいい。なんでもかんでも改行する/しない と
決められるもんじゃない。その時々でどちらがいいかは変わる。
で、それとは別の話として、行数は短い方がいい。1行、2行を目指すという極端な話ではなくて、
一画面に収まる方がいい。一画面って何行だよ？って言うかも知れないが、行数ではなくて本当に一画面。
なぜなら、スクロールの必要がないのが目的だから、視線移動だけで関数が見渡せるのと
スクロールしないと見渡せないのでは大きな差が出る。
当然 見ること、見やすさが重要なので、見えないほど小さいフォントサイズにするとか
ワイドディスプレイを立てにして、視線移動だけで見れるぞ（疲れるけど）みたいな反論はくだらない。
結論として、この書き方が行数短いのでお勧め。
for( ) {
}
このやり方であれば行数が短いくて、さらにforやifなどが出てきたら、視線を下におとして、} までがブロックだとわかるし、
} が出てきたら視線を上に上げていって、文字にぶち当たった所がブロックの開始だとわかる。
重要なのは一点。コードの読みやすさ。じゃあ改行を入れるのと
入れないのどっちが見やすいかといえば、それは、コードの内容による。
小説を考えればいい。なんでもかんでも改行する/しない と
決められるもんじゃない。その時々でどちらがいいかは変わる。
で、それとは別の話として、行数は短い方がいい。1行、2行を目指すという極端な話ではなくて、
一画面に収まる方がいい。一画面って何行だよ？って言うかも知れないが、行数ではなくて本当に一画面。
なぜなら、スクロールの必要がないのが目的だから、視線移動だけで関数が見渡せるのと
スクロールしないと見渡せないのでは大きな差が出る。
当然 見ること、見やすさが重要なので、見えないほど小さいフォントサイズにするとか
ワイドディスプレイを立てにして、視線移動だけで見れるぞ（疲れるけど）みたいな反論はくだらない。
結論として、この書き方が行数短いのでお勧め。
for( ) {
}
このやり方であれば行数が短いくて、さらにforやifなどが出てきたら、視線を下におとして、} までがブロックだとわかるし、
} が出てきたら視線を上に上げていって、文字にぶち当たった所がブロックの開始だとわかる。
うんー
for (int i=0; i< Size; i++);
{
略
}
何で動かんかわかんないなー
for (int i=0; i< Size; i++);
{
略
}
何で動かんかわかんないなー
こんなのがあるくらいだから、ここでカッコの位置で騒ぐのなんて何周遅れてるん
だよって思うんだよ。
プログラミング言語/宗教論争
ttp://www.bugbearr.jp/?%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0%E8%A8%80%E8%AA%9E%2F%E5%AE%97%E6%95%99%E8%AB%96%E4%BA%89
だよって思うんだよ。
プログラミング言語/宗教論争
ttp://www.bugbearr.jp/?%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0%E8%A8%80%E8%AA%9E%2F%E5%AE%97%E6%95%99%E8%AB%96%E4%BA%89
UMLのシーケンス図の表記法を使いシーケンス図に分岐やループをやたら書きまくるのは止めて欲しいな
その分岐やループの大半はそいつが担当するコンポーネントの振る舞い
他のコンポーネントの担当にはどうでも良い話が多い
お前が担当したコンポーネントの設計書に書いときゃいいだろと言いたい
その分岐やループの大半はそいつが担当するコンポーネントの振る舞い
他のコンポーネントの担当にはどうでも良い話が多い
お前が担当したコンポーネントの設計書に書いときゃいいだろと言いたい
> UMLのシーケンス図の表記法を使いシーケンス図に分岐やループをやたら書きまくるのは止めて欲しいな
必要なものすべてを書くと、場所をとるだけだからね。
図には最小限の重要なものだけを書く。あくまで概要書。
それを設計書とみなしてはいけない。
結局のところ、意味がわかればいいので、わざわざ図を作る必要は限られる。
あ、意味がわかるっていうのは当然技術者にとってという意味。
素人には馬鹿向け図として別に作ればいいが、
そんなのは端折って作った適当なものだから、
そういうのを参考して作るような開発はしていけない。
必要なものすべてを書くと、場所をとるだけだからね。
図には最小限の重要なものだけを書く。あくまで概要書。
それを設計書とみなしてはいけない。
結局のところ、意味がわかればいいので、わざわざ図を作る必要は限られる。
あ、意味がわかるっていうのは当然技術者にとってという意味。
素人には馬鹿向け図として別に作ればいいが、
そんなのは端折って作った適当なものだから、
そういうのを参考して作るような開発はしていけない。
734 ：仕様書無しさん：2014/05/10(土) 13:18:19.69
>>734
最近ね、コードはレビューする人のことを考えて作れって言ってるよ。
ちゃんと動くか、バグがないかっていうのは、当たり前にできてる話で、
その上で、レビューしやすいコードになっているかが重要。
「複雑なものを作りました、あなたにこのコードがよめるか？ドヤ！」
っていうのはだめ。
「これで分かりますか？読んでいただけますか？読みにくいなら直します」
これぐらい謙虚じゃないといけない。
読みにくいコードは、バグを見逃すし、レビューで読むのに時間が掛かるし、
後日修正しようと思った時に、また読みにくいものを読まないといけない。
百害あって一利なし。
最近ね、コードはレビューする人のことを考えて作れって言ってるよ。
ちゃんと動くか、バグがないかっていうのは、当たり前にできてる話で、
その上で、レビューしやすいコードになっているかが重要。
「複雑なものを作りました、あなたにこのコードがよめるか？ドヤ！」
っていうのはだめ。
「これで分かりますか？読んでいただけますか？読みにくいなら直します」
これぐらい謙虚じゃないといけない。
読みにくいコードは、バグを見逃すし、レビューで読むのに時間が掛かるし、
後日修正しようと思った時に、また読みにくいものを読まないといけない。
百害あって一利なし。
まぁお前らたまには自分が数年前に書いた物とか見直せ。
今でも3年前のコードとか見ると稚拙さをかんじるわ。
進化してるのを喜ぶべきか今だに未熟なコードを書くのを嘆くべきか。
今でも3年前のコードとか見ると稚拙さをかんじるわ。
進化してるのを喜ぶべきか今だに未熟なコードを書くのを嘆くべきか。
>>735
顔真っ赤にして長文書いてるんだろうけど、読みやすい読みづらいなんて主観の
問題でしかなんだからあなたの思いなんてどうでもいいんですよ。
必要ならコーディング規約を決めてそれに合わせる方が全員にどう書くかの
ガイドラインが出来て読みやすくなるんだから。 自分の主観でこの書き方は
読みづらいって思うコーディング規約なら、コーディング規約を決めれる
ポジションになればいいだけ。個人的には2タブがいいけどエディターだと
4タブとか8タブが標準だよねとか言い出したらキリがない。
顔真っ赤にして長文書いてるんだろうけど、読みやすい読みづらいなんて主観の
問題でしかなんだからあなたの思いなんてどうでもいいんですよ。
必要ならコーディング規約を決めてそれに合わせる方が全員にどう書くかの
ガイドラインが出来て読みやすくなるんだから。 自分の主観でこの書き方は
読みづらいって思うコーディング規約なら、コーディング規約を決めれる
ポジションになればいいだけ。個人的には2タブがいいけどエディターだと
4タブとか8タブが標準だよねとか言い出したらキリがない。
>>732
後工程でやる事についつい入り込んでしまうパターンだな
大枠をまず決める工程でどこかのパートの詳細がふと気になってしまう
そんな時はメモっておいて後日そのパートの設計書に反映すればいいのだけど
それをぜず前工程の設計書に書いちゃうw
そして一度書いちゃうと消せよと言われても引っ込みがつかなくなって
大事な事なんですと言い張るw
後工程でやる事についつい入り込んでしまうパターンだな
大枠をまず決める工程でどこかのパートの詳細がふと気になってしまう
そんな時はメモっておいて後日そのパートの設計書に反映すればいいのだけど
それをぜず前工程の設計書に書いちゃうw
そして一度書いちゃうと消せよと言われても引っ込みがつかなくなって
大事な事なんですと言い張るw
そのまんまの意味じゃね
743 ：仕様書無しさん：2014/05/10(土) 15:28:34.68
744 ：仕様書無しさん：2014/05/10(土) 15:47:39.57
745 ：仕様書無しさん：2014/05/10(土) 16:06:33.83
表で表現する事にexcelを使うのは良いけど
excelを縦横無限大の方眼紙として使ってる設計書は何故か内容もイマイチ
Wordを使って書かれた設計書の方が内容もちゃんとしている傾向がある
気のせいかな?
excelを縦横無限大の方眼紙として使ってる設計書は何故か内容もイマイチ
Wordを使って書かれた設計書の方が内容もちゃんとしている傾向がある
気のせいかな?
746 ：仕様書無しさん：2014/05/10(土) 17:29:54.83
なんだページって
普通プログラマーならクラスとか１処理っていう単位で見ないか？
色々詰め込められた部屋より殺風景な部屋の方が
何があるかはっきりしているし、
情報量を多くしたほうがいいときとか、
少なくした方が見やすいとか状況によって変わるだろ。
くだらん。
普通プログラマーならクラスとか１処理っていう単位で見ないか？
色々詰め込められた部屋より殺風景な部屋の方が
何があるかはっきりしているし、
情報量を多くしたほうがいいときとか、
少なくした方が見やすいとか状況によって変わるだろ。
くだらん。
747 ：仕様書無しさん：2014/05/10(土) 17:40:00.09
かっこの位置はやっぱこうだろ
for()
{
略
}
かっこ内のコードが多くなるとどれに対応するか目視で追えなくなるんだよ。
改行入れるのがめんどくさいから
for(){
}
こうすることがおおいけどな
for()
{
略
}
かっこ内のコードが多くなるとどれに対応するか目視で追えなくなるんだよ。
改行入れるのがめんどくさいから
for(){
}
こうすることがおおいけどな
こちらは擁護できない木を見て森を見ずクン
if( )
{
}
else
{
}
if( )
{
}
else
{
}
> かっこ内のコードが多くなるとどれに対応するか目視で追えなくなるんだよ。
別に括弧の位置がどっちでも、
同じように追えるけど？
別に括弧の位置がどっちでも、
同じように追えるけど？
前から疑問なのは、なぜブロックの括弧の対応を追いたいのかってこと。
知りたいのは、どこからどこまでがブロックになっているかで、
別に括弧はどうでもよかろう？
閉じ括弧 } に対応する、開始単語を追えばいいじゃないか？
俺はいつもそうしているが？
知りたいのは、どこからどこまでがブロックになっているかで、
別に括弧はどうでもよかろう？
閉じ括弧 } に対応する、開始単語を追えばいいじゃないか？
俺はいつもそうしているが？
751 ：仕様書無しさん：2014/05/10(土) 18:28:45.83
行数水増しが見破られ土方発狂
752 ：仕様書無しさん：2014/05/10(土) 19:14:25.40
だったらこれでいいじゃん。
なんで括弧使ってるの？
ブロック対応してるしこれでいいよね。
if()
test();
;
なんで括弧使ってるの？
ブロック対応してるしこれでいいよね。
if()
test();
;
754 ：仕様書無しさん：2014/05/10(土) 19:22:49.27
あくまで括弧は括弧に対応するものなんだから、
命令に対応させるなら;を使えよ
命令に対応させるなら;を使えよ
755 ：仕様書無しさん：2014/05/10(土) 19:25:27.52
for (int i = 0; i < 10; i++)
System.out.println("1");
System.out.println("2");
;
これ実行したら
1
1
1
1
1
1
1
1
1
1
2
って結果表示された
System.out.println("1");
System.out.println("2");
;
これ実行したら
1
1
1
1
1
1
1
1
1
1
2
って結果表示された
756 ：仕様書無しさん：2014/05/10(土) 19:26:16.68
ああ、そういうことか！
758 ：仕様書無しさん：2014/05/10(土) 19:31:24.29
すいません。
僕
sub test()
end sub
これしか使ったことがないから勘違いしてました。
僕
sub test()
end sub
これしか使ったことがないから勘違いしてました。
759 ：仕様書無しさん：2014/05/10(土) 21:04:51.80
建設土方はセメントと鉄骨を減らして手抜き工事
IT土方は無駄に改行いれて行数増やして水増し請求
IT土方は無駄に改行いれて行数増やして水増し請求
>>739
その時じぶんがイイと思う方向に行ってればいいんじゃ無いかね
その時じぶんがイイと思う方向に行ってればいいんじゃ無いかね
文書書きたくない人は、夏休みの宿題やりたくない症候群だな
いいわけが幼稚。
プログラマの仕事は文書を書くことだ。
観念して書け。
いいわけが幼稚。
プログラマの仕事は文書を書くことだ。
観念して書け。
必要な物なら書きますよｗ
必要ないから要らないと言ってるだけで。
必要ないから要らないと言ってるだけで。
763 ：仕様書無しさん：2014/05/10(土) 21:55:32.33
重厚長大プロセスを採用しお役所仕事をして
小規模の案件で多額の費用を客から毟り取るのがSEのお仕事です
客が金を出し渋ったら
品質ガー
保守性ガー
と建前論を唱え不安を煽ればいいのです
設計書なんて書くのは簡単
上流工程の成果物に書いてある事を何度も蒸し返えせば幾らでもページ数を稼げます
コピペですから2次請に丸投げして大丈夫
2次請の単価を叩けば顧客に提示した単価との差額が丸儲け
おいしい商売です
小規模の案件で多額の費用を客から毟り取るのがSEのお仕事です
客が金を出し渋ったら
品質ガー
保守性ガー
と建前論を唱え不安を煽ればいいのです
設計書なんて書くのは簡単
上流工程の成果物に書いてある事を何度も蒸し返えせば幾らでもページ数を稼げます
コピペですから2次請に丸投げして大丈夫
2次請の単価を叩けば顧客に提示した単価との差額が丸儲け
おいしい商売です
>>762
エスパーかなんかなの？
少なくとも使わなくなったら必要だったか不要だったかは判断できるけど、
先のことなんて何が起きるか断定できんでしょ。備えあれば憂いなしと
いうし、自衛のためにも用意できるなら用意するものだよ。
エスパーかなんかなの？
少なくとも使わなくなったら必要だったか不要だったかは判断できるけど、
先のことなんて何が起きるか断定できんでしょ。備えあれば憂いなしと
いうし、自衛のためにも用意できるなら用意するものだよ。
>>764
まさにYAGNIですなｗ
まさにYAGNIですなｗ
766 ：仕様書無しさん：2014/05/10(土) 22:48:46.44
必死に書いた設計書
備えあれは憂なし
でも誰も読んでいません
そんなのあったっけ?
でオシマイ
備えあれは憂なし
でも誰も読んでいません
そんなのあったっけ?
でオシマイ
767 ：仕様書無しさん：2014/05/11(日) 00:12:04.32
全く勉強してないオッさんSEのために会議を設定し
干からびた過去の経験を基に能書きたれさせて悦に入る場を与えてあげる
それがデザインレビューです
干からびた過去の経験を基に能書きたれさせて悦に入る場を与えてあげる
それがデザインレビューです
768 ：仕様書無しさん：2014/05/11(日) 00:25:38.18
バブル期入社のオッさん
Fラン大学の畑違いの学部卒
入社時に3ヶ月教育を受けただけで投入され上司やお客に迷惑かけまくり
アホ、ボケ、カスと言われながらも面の皮の厚さで生き残り
今や肩書きだけは一人前
プログラミング言語はC言語しか知りません
フレームワーク? 何それ旨いの?
アジャイル? アラブのテロリストだっけ?
オマエがレビューしても何の役にも立たねーんだよw
Fラン大学の畑違いの学部卒
入社時に3ヶ月教育を受けただけで投入され上司やお客に迷惑かけまくり
アホ、ボケ、カスと言われながらも面の皮の厚さで生き残り
今や肩書きだけは一人前
プログラミング言語はC言語しか知りません
フレームワーク? 何それ旨いの?
アジャイル? アラブのテロリストだっけ?
オマエがレビューしても何の役にも立たねーんだよw
ページって書いたのは1スクロールの事で
画面に表示できる範囲程度で一つの関数を収めるべきって意味でした
なので1関数と読み替えてください
コード量水増しって、そんな物差し使ってるから馬鹿なんだよ
見た目にわかりやすく、意味が明確で、状態が少なく、機能が完結なのが綺麗なプログラム
スコープの書き方としては括弧のインデントが揃ってる方が分かり易いけど、基本的にはその文化圏(言語としての標準や、会社など団体としての標準)に合わせるべき
画面に表示できる範囲程度で一つの関数を収めるべきって意味でした
なので1関数と読み替えてください
コード量水増しって、そんな物差し使ってるから馬鹿なんだよ
見た目にわかりやすく、意味が明確で、状態が少なく、機能が完結なのが綺麗なプログラム
スコープの書き方としては括弧のインデントが揃ってる方が分かり易いけど、基本的にはその文化圏(言語としての標準や、会社など団体としての標準)に合わせるべき
771 ：仕様書無しさん：2014/05/11(日) 00:59:27.96
>>771のPJには、リファクタリングって言葉は無いんだろうな。
773 ：仕様書無しさん：2014/05/11(日) 01:14:21.49
完璧な物差しじゃないから物差し要らねーと考えてはダメ
各々のプロジェクトで1人月あたりどれだけコードを生産したか会社として管理した方が良い
まずは生産性を計測しデータを蓄積すること
そしてそれを見積りや計画立案に活用する事
それができるようになったらファンクションポイントとか次のステージに進む
各々のプロジェクトで1人月あたりどれだけコードを生産したか会社として管理した方が良い
まずは生産性を計測しデータを蓄積すること
そしてそれを見積りや計画立案に活用する事
それができるようになったらファンクションポイントとか次のステージに進む
774 ：仕様書無しさん：2014/05/11(日) 01:19:10.49
775 ：仕様書無しさん：2014/05/11(日) 01:25:05.50
良い子の皆さんはコードのリファクタリングをするならテストを自動化してね
>>771
投入工数とコード行数に何の因果関係があるのが教えて欲しい。
そんなもよは客からの要望次第で何倍にも変わる。
過去の実績ってのは、同じことを繰り返す仕事なら役に立つけど、プログラマには当てはまらない。
過去のデータで見積もる位に似た案件なら、そこを自動化して稼ぐべき。
つまり、やったことある事は繰り返さない。
投入工数とコード行数に何の因果関係があるのが教えて欲しい。
そんなもよは客からの要望次第で何倍にも変わる。
過去の実績ってのは、同じことを繰り返す仕事なら役に立つけど、プログラマには当てはまらない。
過去のデータで見積もる位に似た案件なら、そこを自動化して稼ぐべき。
つまり、やったことある事は繰り返さない。
底辺の連中のCMMとか言っても仕方泣くね?
まるでリファクタリングの意味がわかっていないな
崩れるまで積み上げる仕事を頑張ってくれよな
俺は崩れないように積み上げつつ積み替えて行くから、口出さないでくれな
崩れるまで積み上げる仕事を頑張ってくれよな
俺は崩れないように積み上げつつ積み替えて行くから、口出さないでくれな
人材派遣だからline単価を出さなくて良い
派遣だから元々要求仕様書に対し見積なんてしていない
派遣だからコードをリファクタリングしようが何しようが
今月は何時間働いたから幾ら払えで済んでしまう
工数見積もりしたとしてもそれは派遣先の会社の開発計画であって
その工数を超過しても責任を問われない
投入工数とlineを管理されているかもしれないけど派遣先の会社がやってる事だから良くわからない
派遣だから元々要求仕様書に対し見積なんてしていない
派遣だからコードをリファクタリングしようが何しようが
今月は何時間働いたから幾ら払えで済んでしまう
工数見積もりしたとしてもそれは派遣先の会社の開発計画であって
その工数を超過しても責任を問われない
投入工数とlineを管理されているかもしれないけど派遣先の会社がやってる事だから良くわからない
>>780
リファクタリングするコストをどうやって客に請求しているの?
確定見積もりする時にリファクタリングのコストも載せている?
もし載せているならどうやって計算しているの?
派遣とか実質派遣でなく本当に請負型(見積もり時に請求額が確定させるやり方)で仕事してるなら答えてみなよ
多分答えられないと思うけど
リファクタリングするコストをどうやって客に請求しているの?
確定見積もりする時にリファクタリングのコストも載せている?
もし載せているならどうやって計算しているの?
派遣とか実質派遣でなく本当に請負型(見積もり時に請求額が確定させるやり方)で仕事してるなら答えてみなよ
多分答えられないと思うけど
783 ：仕様書無しさん：2014/05/11(日) 05:48:16.88
趣味グラマはリファクタリングし放題でうらやましいなー
俺も趣味を仕事と言えるような大きい男になりたいわ
俺も趣味を仕事と言えるような大きい男になりたいわ
設計書要らないと言う人は、小さいシステムしか作ったことないからでしょ。
1人で作るにしても、最低限としてお客様との仕様確認書は必要だと思うけど。
何も要らないとか言う奴はさすがにプロではありえん。
1人で作るにしても、最低限としてお客様との仕様確認書は必要だと思うけど。
何も要らないとか言う奴はさすがにプロではありえん。
工数とコード行数を管理して何になるんだろうか
>>782
> リファクタリングするコストをどうやって客に請求しているの?
お前馬鹿なの？
リファクタリングっていうのは開発そのものだよ。
開発コストに含まれてるに決まってるだろ。
何かを修正するとき、既存のコードを
一切修正してはならないって、縛りでも有るの？
> リファクタリングするコストをどうやって客に請求しているの?
お前馬鹿なの？
リファクタリングっていうのは開発そのものだよ。
開発コストに含まれてるに決まってるだろ。
何かを修正するとき、既存のコードを
一切修正してはならないって、縛りでも有るの？
>>787
工数は必要だろ。
工数は必要だろ。
>キミの会社は投入工数とコード行数のデータを会社として管理してないの?
>それCMMで言うとレベル0(混沌とした状態)というヤツじゃない?
管理していない。いわゆる属人的というのだな。
プログラミングというのは、三流には分からないもの、それでいいよ
>それCMMで言うとレベル0(混沌とした状態)というヤツじゃない?
管理していない。いわゆる属人的というのだな。
プログラミングというのは、三流には分からないもの、それでいいよ
設計書さえ読めば誰でも実装出来るレベルで詳細設計書を作れと言われる。
んでもそんなもん俺には作れないわ。実際、誰も作ってない。
こういう馬鹿な事言う奴ってほんと何なんだろうか。
そんなものに価値があると本気で思ってるのだろうか。
まぁソースコード1行レベルで文章書いてけば作れるっちゃー作れるんだろうが…
んでもそんなもん俺には作れないわ。実際、誰も作ってない。
こういう馬鹿な事言う奴ってほんと何なんだろうか。
そんなものに価値があると本気で思ってるのだろうか。
まぁソースコード1行レベルで文章書いてけば作れるっちゃー作れるんだろうが…
品管を通すために設計書が必要
何しているのか分かりにくいと言われてもこうしないと品管を通らない
文句があるなら品管に言ってくれ
と仕事をしながら誰もが思っている
思ったことがない奴は幸せ者
あとリファクタリングじゃ金とれない
金がとれるのは機能追加だけだ
何しているのか分かりにくいと言われてもこうしないと品管を通らない
文句があるなら品管に言ってくれ
と仕事をしながら誰もが思っている
思ったことがない奴は幸せ者
あとリファクタリングじゃ金とれない
金がとれるのは機能追加だけだ
未だにフローチャート書けと言われる。あんなもん時間の無駄だと思うんだが…
>>794
> あとリファクタリングじゃ金とれない
> 金がとれるのは機能追加だけだ
当たり前だろう？
機能追加でリファクタリングもやるんだよ。
分けて考えるな。
機能を追加した時、コードが複雑になるなら
そこを修正するだけのこと。
2階建を3階建にする時、2階部分を改修するのは
当たり前のことだ。
> あとリファクタリングじゃ金とれない
> 金がとれるのは機能追加だけだ
当たり前だろう？
機能追加でリファクタリングもやるんだよ。
分けて考えるな。
機能を追加した時、コードが複雑になるなら
そこを修正するだけのこと。
2階建を3階建にする時、2階部分を改修するのは
当たり前のことだ。
それができないんだなー
うちの新人さんも出来ないから
若いなら気にすることはないよ。
若いなら気にすることはないよ。
そんな理想を言ってもそれができないようになっているから誰もが四苦八苦しているわけなんだが
>>771
> それCMMで言うとレベル0(混沌とした状態)というヤツじゃない?
CMMは見直すべきだよな。CMM取得とかそういう話ではなくて
レベルの話、考え方の話。
http://ja.wikipedia.org/wiki/%E8%83%BD%E5%8A%9B%E6%88%90%E7%86%9F%E5%BA%A6%E3%83%A2%E3%83%87%E3%83%AB%E7%B5%B1%E5%90%88
> レベル1 初期 プロセスは場当たり的であり、組織は安定した環境を提供しない。
> レベル2 管理された ソフトウェア開発などの成功を反復して実行することができる
> レベル3 定義された 組織の標準プロセスが確立しており、時が経つにつれ標準プロセスは改善される。
> レベル4 定量的に管理された 正確な測定を行うことで、管理側はソフトウェア開発などの有効性を効果的に制御することができる。
> レベル5 最適化している 段階的および革新的な技術的進歩を通じた継続的なプロセスの有効性の改善を重視する。
>
> レベルに関する表現
> 成熟度レベル5は「最適化しているレベル」であって「最適化されたレベル」ではない。
> これは、プロセス改善に終わりはなく、常に改善し続けていくものだという 考えに基づいている。
この常に改善というのにリファクタリングが含まれるわけだけど、これが通常の開発プロセスに
自然に含まれるようになるには、レベル5までならないといけない。
（もちろんそれ以下でやってもいいしやるべきだけど、属人化状態だから、技術力が高い人しかできない）
> それCMMで言うとレベル0(混沌とした状態)というヤツじゃない?
CMMは見直すべきだよな。CMM取得とかそういう話ではなくて
レベルの話、考え方の話。
http://ja.wikipedia.org/wiki/%E8%83%BD%E5%8A%9B%E6%88%90%E7%86%9F%E5%BA%A6%E3%83%A2%E3%83%87%E3%83%AB%E7%B5%B1%E5%90%88
> レベル1 初期 プロセスは場当たり的であり、組織は安定した環境を提供しない。
> レベル2 管理された ソフトウェア開発などの成功を反復して実行することができる
> レベル3 定義された 組織の標準プロセスが確立しており、時が経つにつれ標準プロセスは改善される。
> レベル4 定量的に管理された 正確な測定を行うことで、管理側はソフトウェア開発などの有効性を効果的に制御することができる。
> レベル5 最適化している 段階的および革新的な技術的進歩を通じた継続的なプロセスの有効性の改善を重視する。
>
> レベルに関する表現
> 成熟度レベル5は「最適化しているレベル」であって「最適化されたレベル」ではない。
> これは、プロセス改善に終わりはなく、常に改善し続けていくものだという 考えに基づいている。
この常に改善というのにリファクタリングが含まれるわけだけど、これが通常の開発プロセスに
自然に含まれるようになるには、レベル5までならないといけない。
（もちろんそれ以下でやってもいいしやるべきだけど、属人化状態だから、技術力が高い人しかできない）
>>799
君の会社はCMMレベルでいうとどのレベルですか？
君の会社はCMMレベルでいうとどのレベルですか？
できないできないっていってるのは
単に、成熟度レベルが低いだけでしょ？
知らんがなｗ うちはレベル低いから出来ないんだ！って
叫ばれても。ならレベル上げろよってだけの話。
単に、成熟度レベルが低いだけでしょ？
知らんがなｗ うちはレベル低いから出来ないんだ！って
叫ばれても。ならレベル上げろよってだけの話。
今やることで精一杯。
改善なんて出来ないんだよ！
改善なんて出来ないんだよ！
CMMなんて土方仕事しか評価出来ないしこんなもん無意味。
まぁ土方会社に勤めてるならこういうの大事にするのもいいかもね。
まぁ土方会社に勤めてるならこういうの大事にするのもいいかもね。
ステップ数で商売するのって
自分が無能だって自慢して歩いてるようなものだよ
作業工数が10人月で、人月屋(ステップ屋)さんだと1000万円でーす！って感じだろ？
でも、このシステムでも3億儲けられるなら、1億でも売れるわけで。
結局価値を生み出せないから、客が詳細設計までしたものを翻訳する「翻訳料」しか受け取れていないのが「ステップ屋」
そんな馬鹿が「うちの会社ば成熟してる！」とか騒いでて、ブラック社畜なんだろうけど、日本人の質の低下が本当に心配になる
自分が無能だって自慢して歩いてるようなものだよ
作業工数が10人月で、人月屋(ステップ屋)さんだと1000万円でーす！って感じだろ？
でも、このシステムでも3億儲けられるなら、1億でも売れるわけで。
結局価値を生み出せないから、客が詳細設計までしたものを翻訳する「翻訳料」しか受け取れていないのが「ステップ屋」
そんな馬鹿が「うちの会社ば成熟してる！」とか騒いでて、ブラック社畜なんだろうけど、日本人の質の低下が本当に心配になる
そんな幼稚な文章をよく恥ずかしくも無くたらたら書けるな
>>808
顔真っ赤()
顔真っ赤()
>>794
＞品管を通すために設計書が必要
組織が自己保存のために、無意味な作業増やしてる可能性あり。
＞あとリファクタリングじゃ金とれない
客から直接取れなくても、内部コスト低減には役立つ。
問題は、リファクタリングによる改善は、品管の手柄にならい事。
＞品管を通すために設計書が必要
組織が自己保存のために、無意味な作業増やしてる可能性あり。
＞あとリファクタリングじゃ金とれない
客から直接取れなくても、内部コスト低減には役立つ。
問題は、リファクタリングによる改善は、品管の手柄にならい事。
>>811
まったくそのとおり
まったくそのとおり
品管、設計書、仕様書の本来の共通点は、トラブル防止・収束なんだよな。
売れなかったり、無事故の時には問題にする人は少ない。
書類にしても、進め方にしても危機管理の一部として考えてるかどうかだ。
売れなかったり、無事故の時には問題にする人は少ない。
書類にしても、進め方にしても危機管理の一部として考えてるかどうかだ。
まぁ一番の目的は現場で役に立たない年寄り共に仕事作る事なんだけどなｗ
>>800
ただ単に「リファクタリングが通常の開発プロセスへ自然に含まれている」だけなら、
レベル3で十分に達成できる
CMMで難しいのは、レベル4の「定量的に管理された(リファクタリングの)正確な測定」
リファクタリングは開発プロセスの一要素にすぎないことを忘れることなかれ
ただ単に「リファクタリングが通常の開発プロセスへ自然に含まれている」だけなら、
レベル3で十分に達成できる
CMMで難しいのは、レベル4の「定量的に管理された(リファクタリングの)正確な測定」
リファクタリングは開発プロセスの一要素にすぎないことを忘れることなかれ
んだからこういうのは土方仕事しか評価出来ないんだよ
リファクタリングをコードをちょこちょこ
修正することだと思っていたら大間違いだからなぁ。
正しいリファクタリングをして、
その前と後で何が違うかわからない人は、
正しいソフトウェア開発を知らないと言ってるのと同じ。
そういう人は大抵動けばよしと思っているんだよ。
じゃあなんでデスマってるのかと。
修正することだと思っていたら大間違いだからなぁ。
正しいリファクタリングをして、
その前と後で何が違うかわからない人は、
正しいソフトウェア開発を知らないと言ってるのと同じ。
そういう人は大抵動けばよしと思っているんだよ。
じゃあなんでデスマってるのかと。
821 ：仕様書無しさん：2014/05/11(日) 13:49:11.61
>それって、レベルの高いところで働いてるひとほど偉いの？
工場とか非常に高そうだけど。カイゼンとか。
偉いよ。で日本が世界に通用しているのはそためだ。
こういうのは韓国や中国が不得意とする。またインドもしかり
インドに教えに行くと、この人にもあの人にも同じことを教えるなければなならない
彼らのポリシーとして、知っていることが自分を守るすべ。
だから、他人には教えない
工場とか非常に高そうだけど。カイゼンとか。
偉いよ。で日本が世界に通用しているのはそためだ。
こういうのは韓国や中国が不得意とする。またインドもしかり
インドに教えに行くと、この人にもあの人にも同じことを教えるなければなならない
彼らのポリシーとして、知っていることが自分を守るすべ。
だから、他人には教えない
んー、なんつーか、こういうのは出世の手段の一つでしかないんだよ。品質だのCMMだのはね。
現場で本当に役に立っているかなんてのは二の次。
それが分らない馬鹿があーだこーだ議論してる。
現場で本当に役に立っているかなんてのは二の次。
それが分らない馬鹿があーだこーだ議論してる。
改善をしないとこほど、
今の仕事で手一杯になってるよね。
今の仕事で手一杯になってるよね。
もうこのCMM馬鹿飽きた
お前が馬鹿なんだよ。
CMMという用語が嫌いなら、
改善と言い換えればいい。
お前の会社、改善なにかやってるか？
一年前とくらべて、やり方は成長したか？
してないだろう？
CMMという用語が嫌いなら、
改善と言い換えればいい。
お前の会社、改善なにかやってるか？
一年前とくらべて、やり方は成長したか？
してないだろう？
会社は成長してないですが
会社は無能なので、あまり働かれると迷惑なのです
私と私の周りは成長してるのでそれで良いです
会社に骨を埋めるつもりはないので
会社は無能なので、あまり働かれると迷惑なのです
私と私の周りは成長してるのでそれで良いです
会社に骨を埋めるつもりはないので
その成長の段階にレベルを定義しただけなんだよね。
CMMって。その根本的な所を分ってないから
馬鹿にされるんだよｗ
CMMって。その根本的な所を分ってないから
馬鹿にされるんだよｗ
ステップ数という文言を見ると発狂するような人がよくいるけど、他人に申告するか
どうかはともかくとしてタイピング速度なんて早々変わらないのだから物理的に
何行書けるかってのを知っておくのは悪くないよ。
品質管理なんかのステップ数であれこれ言ってくるので嫌なのはただ単に、
ステップ数以外のパラメーターもあるだろってのと、現実に出た値より、
期待値を優先させようって点だな。 お前ら確率統計も知らんのかよってのが
いすぎなんだよな。
どうかはともかくとしてタイピング速度なんて早々変わらないのだから物理的に
何行書けるかってのを知っておくのは悪くないよ。
品質管理なんかのステップ数であれこれ言ってくるので嫌なのはただ単に、
ステップ数以外のパラメーターもあるだろってのと、現実に出た値より、
期待値を優先させようって点だな。 お前ら確率統計も知らんのかよってのが
いすぎなんだよな。
>>819
CMMが対象とする開発プロセスとは、
システム設計から総合テストにおよぶソフトウェア開発工程の全行程だ
実装設計レベルではリファクタリングが重要であっても、
CMM全体から見れば、実装設計は単なる一工程にすぎないし、
リファクタリングも実装設計レベルの技法の一つにすぎない
CMMが対象とする開発プロセスとは、
システム設計から総合テストにおよぶソフトウェア開発工程の全行程だ
実装設計レベルではリファクタリングが重要であっても、
CMM全体から見れば、実装設計は単なる一工程にすぎないし、
リファクタリングも実装設計レベルの技法の一つにすぎない
> 物理的に 何行書けるかってのを知っておくのは悪くないよ。
物理的なら、アルファベットで1分間に300文字ぐらいだから
一行100文字フルにあったとして、1時間で180行
1日8時間で1440行だね。
まあ1行に100文字も書くことはなくて、インデントとか
空行とかだと極端に量は減るから、
物理的で言えば、1日で1万行は超えるだろうね。
で、物理的な速度に何の意味があるの？w
物理的なら、アルファベットで1分間に300文字ぐらいだから
一行100文字フルにあったとして、1時間で180行
1日8時間で1440行だね。
まあ1行に100文字も書くことはなくて、インデントとか
空行とかだと極端に量は減るから、
物理的で言えば、1日で1万行は超えるだろうね。
で、物理的な速度に何の意味があるの？w
CMMって要するに、安定して手に入る労働力を使って安定した成果を出せるかどうかの指標だよね。
安定して手に入る労働力という評価で満足してる労働者なら従ってみるのもいいんじゃない？
安定して手に入る労働力という評価で満足してる労働者なら従ってみるのもいいんじゃない？
>>831
そりゃそうだろ？
そもそもプログラマの仕事ってのは
システム設計から統合テストに及ぶソフトウェア開発工程の
全工程なんだから。
プロならどの工程でも、改善していかないといけないよ？
この工程は改善しなくていいとかありえない。
そりゃそうだろ？
そもそもプログラマの仕事ってのは
システム設計から統合テストに及ぶソフトウェア開発工程の
全工程なんだから。
プロならどの工程でも、改善していかないといけないよ？
この工程は改善しなくていいとかありえない。
>>833
「CMMに従う」ってのはおかしい話だよ。
CMMはどういうふうにやれ、なんてことはひとことも言っていない。
CMMがやり方を定義しているわけじゃない。
開発工程全般がどういう状態にあるか？という指標。
改善も何も行われていない、いきあたりばったりな開発なのか、
計測し問題点を認識し、それを改善するという繰り返しが
ちゃんとできているか。
あなた達、ちゃんとプロらしく仕事出来てる？
私が判定してあげる。あなたのレベルは～ これがCMM
「CMMに従う」ってのはおかしい話だよ。
CMMはどういうふうにやれ、なんてことはひとことも言っていない。
CMMがやり方を定義しているわけじゃない。
開発工程全般がどういう状態にあるか？という指標。
改善も何も行われていない、いきあたりばったりな開発なのか、
計測し問題点を認識し、それを改善するという繰り返しが
ちゃんとできているか。
あなた達、ちゃんとプロらしく仕事出来てる？
私が判定してあげる。あなたのレベルは～ これがCMM
まあ参考として
http://monoist.atmarkit.co.jp/mn/articles/0512/20/news103_2.html
> つまり、プラクティスの具体的な実行方法の選択は、実行者に委ねられている。
> プラクティスは、ソフトウェア開発の「要求」と似ている。要求は1つでも実装方法はいろいろある。
> また、CMMIに取り組む目的や達成スケジュールに応じて、実装の“深さ”にもメリハリを付けられる。
> 例えば、工数と費用を精緻に見積もろうとすると、それなりの工学的な手法が必要になる。
> それまでカンで見積もっていた現場へそうした手法を押し付けても負担になるだけだ。
> レベル2～3の段階なら、既存のやり方で間に合わせ、徐々に手法を変えていっても問題ないのだ。
> 何しろ、CMMIは“何をどのようにしろ”とは規定していない。
http://monoist.atmarkit.co.jp/mn/articles/0512/20/news103_2.html
> つまり、プラクティスの具体的な実行方法の選択は、実行者に委ねられている。
> プラクティスは、ソフトウェア開発の「要求」と似ている。要求は1つでも実装方法はいろいろある。
> また、CMMIに取り組む目的や達成スケジュールに応じて、実装の“深さ”にもメリハリを付けられる。
> 例えば、工数と費用を精緻に見積もろうとすると、それなりの工学的な手法が必要になる。
> それまでカンで見積もっていた現場へそうした手法を押し付けても負担になるだけだ。
> レベル2～3の段階なら、既存のやり方で間に合わせ、徐々に手法を変えていっても問題ないのだ。
> 何しろ、CMMIは“何をどのようにしろ”とは規定していない。
> それどころか、いったん定義したプロセスであっても、「プロセスQA（品質監査）」により、
>現場に合わなかったり過剰な負担が掛かったりするのなら見直すように求めている。
>CMMIは意外に柔軟なガイドラインなのである。「CMMIの導入で失敗しやすいのが、
>担当者が本を読んで自分でプロセスを決め、頭ごなしに現場にやらせようとしているケース。
>CMMI教則本を額面どおり受け取り、メリハリを付けずにすべて適用したら、
>それは大変なことになる」（日立ソフトの臼井氏）。逆に、CMMIに取り組む目的を明確にし、
>目的に沿って最も効果が表れるポイント、勘所を押さえる必要があるのだ。
>現場に合わなかったり過剰な負担が掛かったりするのなら見直すように求めている。
>CMMIは意外に柔軟なガイドラインなのである。「CMMIの導入で失敗しやすいのが、
>担当者が本を読んで自分でプロセスを決め、頭ごなしに現場にやらせようとしているケース。
>CMMI教則本を額面どおり受け取り、メリハリを付けずにすべて適用したら、
>それは大変なことになる」（日立ソフトの臼井氏）。逆に、CMMIに取り組む目的を明確にし、
>目的に沿って最も効果が表れるポイント、勘所を押さえる必要があるのだ。
>>821
> インドに教えに行くと、この人にもあの人にも同じことを教えるなければなならない
問題ないのでは。
欧米では新入りでも利用できるマニュアルが揃っていて、
職種によって新入りのオリエンテーション内容も決まってるのが普通だし。
> インドに教えに行くと、この人にもあの人にも同じことを教えるなければなならない
問題ないのでは。
欧米では新入りでも利用できるマニュアルが揃っていて、
職種によって新入りのオリエンテーション内容も決まってるのが普通だし。
>>837
同じ業務を継続することが前提になってるね。
同じ業務を継続することが前提になってるね。
>>839
同じ業務？ それが許されるのはレベル2の段階だね。
http://www.it-mc.jp/article/13208863.html
ＣＭＭでは、ＩＴ業者のソフトウェア開発プロセスの成熟度を、５段階に分けています。
レベル１
仕事のやりかたが個人によって違い、同じやり方を反復できない
レベル２
同じ業務内容であれば、個人レベルでは決まった手順で反復できる
レベル３
仕事のやりかたが文書化されており、他の社員でも同じ手順で行える
レベル４
仕事のやりかたが全社的に管理／標準化されている
レベル５
仕事のやりかたが継続的に見直されており、全社的に最適化されている
同じ業務？ それが許されるのはレベル2の段階だね。
http://www.it-mc.jp/article/13208863.html
ＣＭＭでは、ＩＴ業者のソフトウェア開発プロセスの成熟度を、５段階に分けています。
レベル１
仕事のやりかたが個人によって違い、同じやり方を反復できない
レベル２
同じ業務内容であれば、個人レベルでは決まった手順で反復できる
レベル３
仕事のやりかたが文書化されており、他の社員でも同じ手順で行える
レベル４
仕事のやりかたが全社的に管理／標準化されている
レベル５
仕事のやりかたが継続的に見直されており、全社的に最適化されている
例えばWeb開発と、組み込み開発では行数を比較しても仕方ないと思うのだが。
Webだと比較的コーディングが多くなるのに対して、組み込みだと一ヶ月で
１０００行書かないことも珍しくない。
Webだと比較的コーディングが多くなるのに対して、組み込みだと一ヶ月で
１０００行書かないことも珍しくない。
ソフトウェアは同じ業務は繰り返さないものだから
CMMレベル2程度じゃダメだよ。
業務は変わるからこそ、適切なプロセスと計測
そして改善までともなったレベル5を目指す必要がある。
ここまで到達すると、仕事をしながらどんどん仕事が楽になっていき
それでいながら開発スピードも向上する。
常に改善し続けているのだから当然。
CMMレベル2程度じゃダメだよ。
業務は変わるからこそ、適切なプロセスと計測
そして改善までともなったレベル5を目指す必要がある。
ここまで到達すると、仕事をしながらどんどん仕事が楽になっていき
それでいながら開発スピードも向上する。
常に改善し続けているのだから当然。
一人が書ける行数にそんなに違いはないのだから、
システムを実現するのに必要な行数を減らす必要がある。
システムを実現させるのが目的であり、その中間にあるものは
できるかぎり少ないほうが良い。
設計書もシステムを実現させるのに必要な物は
作った量よりもはるかに少ないだろう？
設計書が開発に役に立ったことが有るかほんきで考えてみよ。
システムを実現するのに必要な行数を減らす必要がある。
システムを実現させるのが目的であり、その中間にあるものは
できるかぎり少ないほうが良い。
設計書もシステムを実現させるのに必要な物は
作った量よりもはるかに少ないだろう？
設計書が開発に役に立ったことが有るかほんきで考えてみよ。
初めてやる仕事について
「仕事のやりかたが継続的に見直されており、全社的に最適化されている」
なんてアホなこと言ってられないわけでねー
レベル１の中で試行錯誤しながらもがくしかないんだよ。
メンテ業務を行うようであれば、そのときにレベル２か３に持っていければいい方。
「仕事のやりかたが継続的に見直されており、全社的に最適化されている」
なんてアホなこと言ってられないわけでねー
レベル１の中で試行錯誤しながらもがくしかないんだよ。
メンテ業務を行うようであれば、そのときにレベル２か３に持っていければいい方。
>>832
＞で、物理的な速度に何の意味があるの？w
実際に手を動かして書き始めてから書き終わるまでの時間が分かれば、
コードを書く以外のことにどれくらいの時間をかけれるのか判断が出来る。
仕事だと無限に時間を使ってもいいわけじゃないからな。
＞で、物理的な速度に何の意味があるの？w
実際に手を動かして書き始めてから書き終わるまでの時間が分かれば、
コードを書く以外のことにどれくらいの時間をかけれるのか判断が出来る。
仕事だと無限に時間を使ってもいいわけじゃないからな。
>>845
一日に書けるコードの量を100行だとする。
物理的にかける行数は10000行。
つまりコードを書く以外のことに一日8時間の99%を使っている
480分中、4.8分がコードを書く時間だ。
なるほど、コードを書くのに約5分、残り7時間55分が
コードを書く以外の時間だ。
判断できたが、これに何の意味があるの？ｗ
一日に書けるコードの量を100行だとする。
物理的にかける行数は10000行。
つまりコードを書く以外のことに一日8時間の99%を使っている
480分中、4.8分がコードを書く時間だ。
なるほど、コードを書くのに約5分、残り7時間55分が
コードを書く以外の時間だ。
判断できたが、これに何の意味があるの？ｗ
コーディングという名前に反して、
コードを書いている時にかかる時間の大半は
読んで理解する量だよ。
だからコードが多ければ多いほど時間がかかる。
同じことを実現するのに、短いコードのほうがいいと言われるのは
書く量が少ないからじゃなくて、読む量が少ないから。
コードを書いている時にかかる時間の大半は
読んで理解する量だよ。
だからコードが多ければ多いほど時間がかかる。
同じことを実現するのに、短いコードのほうがいいと言われるのは
書く量が少ないからじゃなくて、読む量が少ないから。
>>846
見積もりとかしないでコード書いてるの？
見積もりとかしないでコード書いてるの？
何時間掛けるかは見積もるだろうけど、
何行書くかとか見積もるのも普通なの？
何行書くかとか見積もるのも普通なの？
全コントロール数がいくつで、一つのコントロールあたりn行だからこれくらい
とか見積もることが可能なものもあるっちゃあるけど。
とか見積もることが可能なものもあるっちゃあるけど。
同じようなくだらねー受託開発してる企業がCMMなんて言ってんだよ。
常に新しいものを生み出す現場でこんな事言ってる奴はいない。
常に新しいものを生み出す現場でこんな事言ってる奴はいない。
行数云々言ってるのはジジイだろ
他の誰かが読むことを考慮せずに書くなら、プログラムなんてチャットと同じ速さで組める。
そんなコードに何の意味があるのかは知らん。
ステップ屋さんは一生ステップ売っててください
そんなコードに何の意味があるのかは知らん。
ステップ屋さんは一生ステップ売っててください
854 ：仕様書無しさん：2014/05/11(日) 23:10:45.74
１行書くといくらもらえんの？
松井秀樹は１打席400万のバッターとか言うけど、
凄腕プログラマーになれば１行１０万とかもらえんのかｗ？
松井秀樹は１打席400万のバッターとか言うけど、
凄腕プログラマーになれば１行１０万とかもらえんのかｗ？
もらえるんじゃねーの？
ステップ数に女でもNTRたのかね。
誰から貰えるのかによるが
いいアイディアがあって、自分で綺麗に書いて、自分で儲けたら
1行10万の価値はありえる
ステップ屋()じゃ無理だけど
いいアイディアがあって、自分で綺麗に書いて、自分で儲けたら
1行10万の価値はありえる
ステップ屋()じゃ無理だけど
今までだと１０数行のコードで３０万(税込み)が最高かなぁ。
２０行だとして、一行あたり一万５千円。
２０行だとして、一行あたり一万５千円。
>>844
もうすぐ、ダーウィン賞を取れそうだな。
もうすぐ、ダーウィン賞を取れそうだな。
860 ：仕様書無しさん：2014/05/12(月) 01:12:16.92
ステップ数とかファンクションポイント法で見積もりできるのって、大規模開発とかじゃない？
昔SIやってたけど、ほとんど後付けで上司から催促されて計算してた。
まあ、期待した工数とるための根拠に使う以外の価値はないな。客も軽くだまされるし。
嘘の数字ならマネジメントにおける価値もないが、現場からの報告は嘘だらけなのが最大の問題。
やるならちゃんと管理しろ。現場と顔つき合わせろ。自分だけ休みたいなんて夢にも思うな。
つまり、大事なのは表面的な方法論よりも仕事に対するチームの姿勢なんだ。
昔SIやってたけど、ほとんど後付けで上司から催促されて計算してた。
まあ、期待した工数とるための根拠に使う以外の価値はないな。客も軽くだまされるし。
嘘の数字ならマネジメントにおける価値もないが、現場からの報告は嘘だらけなのが最大の問題。
やるならちゃんと管理しろ。現場と顔つき合わせろ。自分だけ休みたいなんて夢にも思うな。
つまり、大事なのは表面的な方法論よりも仕事に対するチームの姿勢なんだ。
861 ：仕様書無しさん：2014/05/13(火) 01:43:52.96
862 ：仕様書無しさん：2014/05/13(火) 19:54:25.13
技術者は貧民奴隷にならないために、
法律
経済
商業
を学べ
法律
経済
商業
を学べ
CMMのレベルがどんなに高くても、予算なし、納期なし、無能ばっかが集まれば必ず炎上する。
だからCMMなんか全然当てにならない。
他の認証規格も一緒。
だからCMMなんか全然当てにならない。
他の認証規格も一緒。
ISOというのがあるけど、書類揃っていますか？ という
そういう、くそ焼くにたたないのがはびこているが社会なわけ。
たてまえが必要なのよ
マニュアルがあり、その通り作業がこなせればいいというのと
プログラミングは正反対。
マックの店員がいやだから、プログラマーやっているよなもんだ
プログラミングは道がないところを開拓していくという感覚
そういうのを創造的という。
で、部下に俺の指示通りやれといっているようでは
プログラマーは育たんよ
そういう、くそ焼くにたたないのがはびこているが社会なわけ。
たてまえが必要なのよ
マニュアルがあり、その通り作業がこなせればいいというのと
プログラミングは正反対。
マックの店員がいやだから、プログラマーやっているよなもんだ
プログラミングは道がないところを開拓していくという感覚
そういうのを創造的という。
で、部下に俺の指示通りやれといっているようでは
プログラマーは育たんよ
>>863
> CMMのレベルがどんなに高くても、予算なし、納期なし、無能ばっかが集まれば必ず炎上する。
CMMのレベルが高いっていうのは、
「常に安定した品質のものを作ており、更に開発プロセスを改善し続けていること」を
満たしていなければ、レベルが高くナラニから、無能には成り得ないけど？
まあ、予算と納期という”外部要因"が悪ければ、
それや本人たちのレベルとは無関係に炎上するだろうさ。
> CMMのレベルがどんなに高くても、予算なし、納期なし、無能ばっかが集まれば必ず炎上する。
CMMのレベルが高いっていうのは、
「常に安定した品質のものを作ており、更に開発プロセスを改善し続けていること」を
満たしていなければ、レベルが高くナラニから、無能には成り得ないけど？
まあ、予算と納期という”外部要因"が悪ければ、
それや本人たちのレベルとは無関係に炎上するだろうさ。
> CMMのレベルが高いっていうのは、
> 「常に安定した品質のものを作ており、更に開発プロセスを改善し続けていること」を
> 満たしていなければ、レベルが高くナラニから、無能には成り得ないけど？
無能でも回るようにするためにCMMやらISO適用するんじゃね？
つーか、適用すると出来る人出て行っちゃうよ。
現場では、可視化されたメトリクスを開発者レベルで扱えるリーダ/マネージャが殆ど居ない。
結果、意識だけは高い裸の王様がカイゼンごっこをした挙句、無駄な規則を増やして開発プロセスが硬直化してしまう。
耐えかねて出来る人が居なくなるまでが一連の流れ。
> 「常に安定した品質のものを作ており、更に開発プロセスを改善し続けていること」を
> 満たしていなければ、レベルが高くナラニから、無能には成り得ないけど？
無能でも回るようにするためにCMMやらISO適用するんじゃね？
つーか、適用すると出来る人出て行っちゃうよ。
現場では、可視化されたメトリクスを開発者レベルで扱えるリーダ/マネージャが殆ど居ない。
結果、意識だけは高い裸の王様がカイゼンごっこをした挙句、無駄な規則を増やして開発プロセスが硬直化してしまう。
耐えかねて出来る人が居なくなるまでが一連の流れ。
>>866
関係ない奴が作ったルールは糞だよな
意味もなく守るコーディングルール並に糞
作ったやつは自分には糞ルールを適用しないから、糞ルールか放置される
開発者以外が開発部にルール強要する会社は逃げた方がいい
関係ない奴が作ったルールは糞だよな
意味もなく守るコーディングルール並に糞
作ったやつは自分には糞ルールを適用しないから、糞ルールか放置される
開発者以外が開発部にルール強要する会社は逃げた方がいい
>>866
> 無能でも回るようにするためにCMMやらISO適用するんじゃね？
ISOはしらんけど、CMMはそういうものじゃない。
CMMは、このような仕様書や設計書的なものを作るんだ
とかいう決まりではない。マニュアルは用意されていない。ルールも決まっていない。
ルールがないのだから「ルールを守っていればだれでも出来るようになる」ものではない。
CMMが見ているのは、その企業、プロジェクトを遂行しているチームのレベル。
日々の仕事で精一杯、成果物にもムラがあるようなレベルか、
いまままでと似た内容なら、同じように作れるレベルなのか、
日々のプロジェクトをこなしながら常に検証、改善していけるレベルなのか
そういったレベルの定義をしているだけ。
> 無能でも回るようにするためにCMMやらISO適用するんじゃね？
ISOはしらんけど、CMMはそういうものじゃない。
CMMは、このような仕様書や設計書的なものを作るんだ
とかいう決まりではない。マニュアルは用意されていない。ルールも決まっていない。
ルールがないのだから「ルールを守っていればだれでも出来るようになる」ものではない。
CMMが見ているのは、その企業、プロジェクトを遂行しているチームのレベル。
日々の仕事で精一杯、成果物にもムラがあるようなレベルか、
いまままでと似た内容なら、同じように作れるレベルなのか、
日々のプロジェクトをこなしながら常に検証、改善していけるレベルなのか
そういったレベルの定義をしているだけ。
CMMの上位レベルでは、決まりをたくさん作るのではなく、
その決まりが無駄だと思うならば、変えたりなくしたりする。
それが本当の意味の改善であり、実情に合っていないルールを作るのは
（作るのは大抵偉い人）CMM的なレベルで言えば下の方。
その決まりが無駄だと思うならば、変えたりなくしたりする。
それが本当の意味の改善であり、実情に合っていないルールを作るのは
（作るのは大抵偉い人）CMM的なレベルで言えば下の方。
現場に決定権があればな
だいたいそんなアホな決まり導入してるところは、アホな上司と自分に不利益のない別のクソ部署が強要するんだよ
だいたいそんなアホな決まり導入してるところは、アホな上司と自分に不利益のない別のクソ部署が強要するんだよ
CMMとかどうせ後数年したら陳腐化してる
今の時代UMLやデザパタをドヤ顔して語るやついない
今の時代UMLやデザパタをドヤ顔して語るやついない
>>868
何年も同じような仕事をしてる組織には有効かもな。
何年も同じような仕事をしてる組織には有効かもな。
>>868
定量的に成果物の評価をするなら、普通は明確なメトリクス用意する。
そして、周囲の状況や会社の意向、技術の進歩に合わせてメトリクスも変化すべき。
でも、環境変化や技術進歩で業務の性質が変わったときに適切なメトリクスを用意するのは困難。
メトリクスを変えるコストがそのまま対応コストに乗っかるんで、プロセスとしては本質的に現状維持へ傾くんだよ。
イノベーションは起こらない。
昔ながらの手順で淡々と進むだけ。
新しいことなんて当然出来ない。
そうなると、無能しか残らなくなるよね？
定量的に成果物の評価をするなら、普通は明確なメトリクス用意する。
そして、周囲の状況や会社の意向、技術の進歩に合わせてメトリクスも変化すべき。
でも、環境変化や技術進歩で業務の性質が変わったときに適切なメトリクスを用意するのは困難。
メトリクスを変えるコストがそのまま対応コストに乗っかるんで、プロセスとしては本質的に現状維持へ傾くんだよ。
イノベーションは起こらない。
昔ながらの手順で淡々と進むだけ。
新しいことなんて当然出来ない。
そうなると、無能しか残らなくなるよね？
>>874
何を言っているのかわからん。
> イノベーションは起こらない。
> 昔ながらの手順で淡々と進むだけ。
> 新しいことなんて当然出来ない。
> そうなると、無能しか残らなくなるよね？
↑ これは言い換えると、CMMのレベルとしては
低いって評価されるってことだよ。
何を言っているのかわからん。
> イノベーションは起こらない。
> 昔ながらの手順で淡々と進むだけ。
> 新しいことなんて当然出来ない。
> そうなると、無能しか残らなくなるよね？
↑ これは言い換えると、CMMのレベルとしては
低いって評価されるってことだよ。
>>874
もしかして、改善にはコストがかかる。という話をしているのか？
そんなの当たり前の話で、ISOやCMMとは全く関係ない話。
「改善にはコストがかかるからしないほうがいい」と
一言で言えばいいのに。
もしかして、改善にはコストがかかる。という話をしているのか？
そんなの当たり前の話で、ISOやCMMとは全く関係ない話。
「改善にはコストがかかるからしないほうがいい」と
一言で言えばいいのに。
ステップ数を評価するというのをプログラマから見るとありえない
たとえば VBで
Text1
Text2
Text3
Text4
.
.
.
と画面に貼り付けていく。
Text1,Text2,Text... にたいしてこれらに変数を渡す場合、
Text1.Text = a
Text2.Text = b
とやるなら、こういう作業はプログラマはバグになりやすいと見ている。
で(c++文法で書くと）
for(int i = 0; i<10; i++){
NewCtrlTxt(i);//Textｺﾝﾄﾛｰﾙの生成
}
とやる
Text1.Text = a
Text2.Text = b
という一個一個の手作業より
ループを使って変数をわたせるようにする。そのためのｺﾝﾄﾛｰﾙの生成だな
バグを起こりにくくする。手作業ではバグがおきるよ
たとえば VBで
Text1
Text2
Text3
Text4
.
.
.
と画面に貼り付けていく。
Text1,Text2,Text... にたいしてこれらに変数を渡す場合、
Text1.Text = a
Text2.Text = b
とやるなら、こういう作業はプログラマはバグになりやすいと見ている。
で(c++文法で書くと）
for(int i = 0; i<10; i++){
NewCtrlTxt(i);//Textｺﾝﾄﾛｰﾙの生成
}
とやる
Text1.Text = a
Text2.Text = b
という一個一個の手作業より
ループを使って変数をわたせるようにする。そのためのｺﾝﾄﾛｰﾙの生成だな
バグを起こりにくくする。手作業ではバグがおきるよ
879 ：仕様書無しさん：2014/05/16(金) 19:32:03.38
>たとえば VBで
>で(c++文法で書くと）
おまえもたいがいありえない
>で(c++文法で書くと）
おまえもたいがいありえない
ISO は書類レベルでの査定、CMM は内容レベルでの査定、ということで良いのだろうか？
だとしたら、ISO は査定できても CMM を査定できる機関はほぼ存在し得ないのと思うのだが…。
仕様書（客に渡す資料）は製品の拠り所で、設計書（内々の資料）は当時の現場の状態を知る資料になる。
で、やっと安心してメンテできる。資料があるのと無いのとでは全然違う…かな。
だとしたら、ISO は査定できても CMM を査定できる機関はほぼ存在し得ないのと思うのだが…。
仕様書（客に渡す資料）は製品の拠り所で、設計書（内々の資料）は当時の現場の状態を知る資料になる。
で、やっと安心してメンテできる。資料があるのと無いのとでは全然違う…かな。
881 ：仕様書無しさん：2014/05/17(土) 00:06:58.73
>>877
改善自体にコストがかかるんじゃなくて、組織的に改善できる体制を設けるのにコストがかかる。
技術力の差は視座の差に直結するから、画一的なメトリックスを用意しても、拾い上げる情報はそれぞれ違う。
ある程度技術力に差があると、そもそも議論すら成り立たなくなる。
そういえば、このスレでも、生産性評価にline数使って揉めてたよね？
そのあやふやな指標をコミットメントとして設定されたらどうなるよ？
こんなの氷山の一角で、可視化すればするほどコミュニケーションコストをはじめとする様々なコストが、出来る人に直接のしかかるわけ。
大抵の人は、諦めて無能化するなり出て行くなりしてしまう。
組織が均一化してくれば収まるんだけど、その頃には思考停止した無能しか居なくなってる。
定型業務を安い金で回すビジネスモデルには適切だけど、クリエイティビティを求められる業務では致命的。
改善自体にコストがかかるんじゃなくて、組織的に改善できる体制を設けるのにコストがかかる。
技術力の差は視座の差に直結するから、画一的なメトリックスを用意しても、拾い上げる情報はそれぞれ違う。
ある程度技術力に差があると、そもそも議論すら成り立たなくなる。
そういえば、このスレでも、生産性評価にline数使って揉めてたよね？
そのあやふやな指標をコミットメントとして設定されたらどうなるよ？
こんなの氷山の一角で、可視化すればするほどコミュニケーションコストをはじめとする様々なコストが、出来る人に直接のしかかるわけ。
大抵の人は、諦めて無能化するなり出て行くなりしてしまう。
組織が均一化してくれば収まるんだけど、その頃には思考停止した無能しか居なくなってる。
定型業務を安い金で回すビジネスモデルには適切だけど、クリエイティビティを求められる業務では致命的。
もうCMMはいいよ。土方現場では大切にしておけばいいと思う。
> そのあやふやな指標をコミットメントとして設定されたらどうなるよ？
それが、実際に役に立つか検証して役に立たないとわかれば
やめるというのがCMMで求められている継続的な改善能力です。
間違えたルールを設定するのは、人間だれでも間違えるのだから
防ぎようがない。それを後から修正することが一番大事なこと。
それが、実際に役に立つか検証して役に立たないとわかれば
やめるというのがCMMで求められている継続的な改善能力です。
間違えたルールを設定するのは、人間だれでも間違えるのだから
防ぎようがない。それを後から修正することが一番大事なこと。
あー、CMMを導入というのは正しくないな。
CMMは評価するものであって導入するようなものじゃない。
CMMという基準で評価してないだけであって、
プロセス改善能力レベルなんだから
どんな企業でもCMMのレベルに当てはめられる。
土方現場はCMMレベル0だろうけど。
CMMは評価するものであって導入するようなものじゃない。
CMMという基準で評価してないだけであって、
プロセス改善能力レベルなんだから
どんな企業でもCMMのレベルに当てはめられる。
土方現場はCMMレベル0だろうけど。
887 ：仕様書無しさん：2014/05/17(土) 00:52:19.32
設計書や仕様書の規格ってある？何を書けばいいとかの規約とか。
いままでお客様の都合にあわせて適当に書いていたから、
新人に教えようと思っても、何が正しいのかわかんないや。
いままでお客様の都合にあわせて適当に書いていたから、
新人に教えようと思っても、何が正しいのかわかんないや。
>>875
組織の変化より環境や仕事の変化が十分遅いという前提に立ってるよね。
>>885
土方現場はCMMレベルゼロというのは正しい。
環境の変化が激しすぎて、レベル上げる頃には次の仕事に移ってる。
組織の変化より環境や仕事の変化が十分遅いという前提に立ってるよね。
>>885
土方現場はCMMレベルゼロというのは正しい。
環境の変化が激しすぎて、レベル上げる頃には次の仕事に移ってる。
>>888
> 環境の変化が激しすぎて、レベル上げる頃には次の仕事に移ってる。
やっぱりCMMわかってねーしｗ
CMMは仕事内容とは関係ない。そこにいる人達、チーム、の能力レベルの話。
なにせ「別の仕事でも安定して生産できること」が高いレベルの条件なんだから。
だから次の仕事に移っても関係ない。
反論したいなら、仕事ごとにノウハウが0の状態から始まるからとか言わなくちゃｗ
で、仕事ごとにノウハウ0から初めてるの？前の仕事の経験は生かさないの？
> 環境の変化が激しすぎて、レベル上げる頃には次の仕事に移ってる。
やっぱりCMMわかってねーしｗ
CMMは仕事内容とは関係ない。そこにいる人達、チーム、の能力レベルの話。
なにせ「別の仕事でも安定して生産できること」が高いレベルの条件なんだから。
だから次の仕事に移っても関係ない。
反論したいなら、仕事ごとにノウハウが0の状態から始まるからとか言わなくちゃｗ
で、仕事ごとにノウハウ0から初めてるの？前の仕事の経験は生かさないの？
COBOLerが初めてのWeb開発に「俺たちにはノウハウがある」って言うのがCMMですか。
何この変な流れ
>>891
> COBOLerが初めてのWeb開発に「俺たちにはノウハウがある」って言うのがCMMですか。
次の仕事に移っているだけの話をしていたはずだが？
次の仕事に移っていてもノウハウはあるだろ。
それを活かして改善していけるのがCMMレベルが高いということを意味する。
で、なに？ 何がいいたくてそんなレスを下の？
> COBOLerが初めてのWeb開発に「俺たちにはノウハウがある」って言うのがCMMですか。
次の仕事に移っているだけの話をしていたはずだが？
次の仕事に移っていてもノウハウはあるだろ。
それを活かして改善していけるのがCMMレベルが高いということを意味する。
で、なに？ 何がいいたくてそんなレスを下の？
>>883
役に立たないと判った頃には既に手遅れだと思うが。
現実問題として、そこまでメトリックスに対する認知が固まる頃には、既にそれ自体が陳腐化していることが多い。
お前の所では、自ら学ばない人たちがその水準に並ぶまで何年も待ってくれるのか？
目的は改善活動それ自体ではなく、業績の向上だよね。
そのために組織内の出来る人間を押さえつけるのは本末転倒だよ。
>>890
仕事ごとにノウハウ0から始めるとか、よくある話じゃないか。
例えば、外から連れてきた経験者とかき集めてきたメンバの組み合わせで新規事業とか。
チームのクリエイティビティに強く左右されるビジネスモデルだと、測定と数値による改善は害悪になることも多いよ。
適切な判断を下せない人間が多数派の状況下で、合議制でプロジェクト進めるようなものだから。
ソフトウエア開発は概ねこの例に当てはまると思うけど、そもそもまともな事例を知らない人ばかりだったりして認知すらされないことも多い。
役に立たないと判った頃には既に手遅れだと思うが。
現実問題として、そこまでメトリックスに対する認知が固まる頃には、既にそれ自体が陳腐化していることが多い。
お前の所では、自ら学ばない人たちがその水準に並ぶまで何年も待ってくれるのか？
目的は改善活動それ自体ではなく、業績の向上だよね。
そのために組織内の出来る人間を押さえつけるのは本末転倒だよ。
>>890
仕事ごとにノウハウ0から始めるとか、よくある話じゃないか。
例えば、外から連れてきた経験者とかき集めてきたメンバの組み合わせで新規事業とか。
チームのクリエイティビティに強く左右されるビジネスモデルだと、測定と数値による改善は害悪になることも多いよ。
適切な判断を下せない人間が多数派の状況下で、合議制でプロジェクト進めるようなものだから。
ソフトウエア開発は概ねこの例に当てはまると思うけど、そもそもまともな事例を知らない人ばかりだったりして認知すらされないことも多い。
>>894
メンバーをかき集めるってそれ素人ってこと？
メンバーをかき集める側も、ノウハウないの？
過去に使ったフレームワークとか、そんなノウハウもなくて0から
スタートなの？
そりゃ、そのプロジェクト失敗するわｗ
メンバーをかき集めるってそれ素人ってこと？
メンバーをかき集める側も、ノウハウないの？
過去に使ったフレームワークとか、そんなノウハウもなくて0から
スタートなの？
そりゃ、そのプロジェクト失敗するわｗ
ノウハウ消費するだけの人と、なにも無いところからノウハウを作り上げていく人じゃ
全然見方が違うだろうなー
全然見方が違うだろうなー
ノウハウ消費ってなんじゃそりゃ？
ノウハウを作ってそして使う人と、
ノウハウを使うだけの人って意味かいな？
どっちみちノウハウは使うし、使わなきゃ意味が無いけど
何がいいたいのかわからん。
ノウハウを作ってそして使う人と、
ノウハウを使うだけの人って意味かいな？
どっちみちノウハウは使うし、使わなきゃ意味が無いけど
何がいいたいのかわからん。
>>895
> メンバーをかき集めるってそれ素人ってこと？
技術に疎いが隣接する業務知識持ってる人間や業務知識の無い技術者、採用フレームワークに慣れていない技術者が混ざるのは仕方ないだろ。
事例自体が存在しないケースだってあるんだし。
>>895は相当温い環境に居るんだろうな。なぁなぁでもなんとなく給料もらえる程度には守られてるに違いない。
不確定要素が大きくなるほど、個人のクリエイティビティに頼る割合は大きくならざる得ないよ。
> メンバーをかき集めるってそれ素人ってこと？
技術に疎いが隣接する業務知識持ってる人間や業務知識の無い技術者、採用フレームワークに慣れていない技術者が混ざるのは仕方ないだろ。
事例自体が存在しないケースだってあるんだし。
>>895は相当温い環境に居るんだろうな。なぁなぁでもなんとなく給料もらえる程度には守られてるに違いない。
不確定要素が大きくなるほど、個人のクリエイティビティに頼る割合は大きくならざる得ないよ。
>>898
よく考えてみようか。
ノウハウが溜まって、それを活かして
次の開発ができる（俺の）所のほうが、
そんな素人同然のメンバーをかき集めて
ノウハウ0、次に何も生かせないような
仕事よりも何倍も優れた環境だよ。
自分もチームも会社もすべてが改善、
成長していっていることを実感できる。
よく考えてみようか。
ノウハウが溜まって、それを活かして
次の開発ができる（俺の）所のほうが、
そんな素人同然のメンバーをかき集めて
ノウハウ0、次に何も生かせないような
仕事よりも何倍も優れた環境だよ。
自分もチームも会社もすべてが改善、
成長していっていることを実感できる。
人それぞれじゃね？
まだ誰もやったことがないことをやるのが面白いと言う人もいるし、
そういうのは嫌だという人もいる。
まだ誰もやったことがないことをやるのが面白いと言う人もいるし、
そういうのは嫌だという人もいる。
自己啓発マンか。若いな。
だからなんだっていうんだ？
まだ誰もやったことがない事をやってこそのプログラマだと思うんだがなぁ。嫌がる奴は確かにいるがゴミクズにしか見えない。
>>899
個人として成長するよ。残るものはある。
チームとしての成長を尊ぶか、それとも個人としての成長を尊ぶか。
そこは価値観の違いの範囲だな。
定型業務ならチームの平均が、
不確定要素の多い業務ならチーム内の最大の個人の能力がスループットに効いてくる。
優劣云々よりも、業務の性質に応じて使い分けるべき。
ただ、現代のソフトウエア開発はクリエイティビティに依る部分が大きいので、多くの場合にできる人の力が原動力になるんだよ。
(開発に付随する定型業務は、年を追う毎に確実に減っているから。)
そんな中、チーム皆でカイゼンとか言われても魅力を感じない。
ノウハウ云々よりも、チームが下限に合わせて均一化されるリスクのほうが高いから。
いくらノウハウ残したって、それを扱える人がごく少数なら組織としてカイゼンしたと言わないよね？
(例えば、飲み込むために前提知識を必要としたり、高い技量がないと効果がない場合等。)
個人として成長するよ。残るものはある。
チームとしての成長を尊ぶか、それとも個人としての成長を尊ぶか。
そこは価値観の違いの範囲だな。
定型業務ならチームの平均が、
不確定要素の多い業務ならチーム内の最大の個人の能力がスループットに効いてくる。
優劣云々よりも、業務の性質に応じて使い分けるべき。
ただ、現代のソフトウエア開発はクリエイティビティに依る部分が大きいので、多くの場合にできる人の力が原動力になるんだよ。
(開発に付随する定型業務は、年を追う毎に確実に減っているから。)
そんな中、チーム皆でカイゼンとか言われても魅力を感じない。
ノウハウ云々よりも、チームが下限に合わせて均一化されるリスクのほうが高いから。
いくらノウハウ残したって、それを扱える人がごく少数なら組織としてカイゼンしたと言わないよね？
(例えば、飲み込むために前提知識を必要としたり、高い技量がないと効果がない場合等。)
ソフト開発で自分も組織もカイゼンとかちゃんちゃら可笑しいね。
受託開発やってる土方だろ、こういうの言ってるの。
受託開発やってる土方だろ、こういうの言ってるの。
>>905
何で壊れた？
何で壊れた？
>>905
支離滅裂だな
支離滅裂だな
cmmってそんな難しいことじゃないだろ。
コードがちゃんと再利用されてて
保守もできてて
お互いにコードレビューできてて
リリース前にテストがちゃんとできている。
資産が属人化していない
当たり前の事ができていれば
レベル3以上になれる。
2以下はプロの職場としては最低のクソということ。
コードがちゃんと再利用されてて
保守もできてて
お互いにコードレビューできてて
リリース前にテストがちゃんとできている。
資産が属人化していない
当たり前の事ができていれば
レベル3以上になれる。
2以下はプロの職場としては最低のクソということ。
んだからそんなもん、土方現場でしかやらんって。下請け自慢片腹痛いわ。
>>911がいってることは、
うちは土方じゃないから改善はしない、
ひたすら汚いコードを作るまでということかｗ
CMMの認定を受けてるところって、
土方企業が一つもないんだよねｗ
どっちが本当の土方なのか、
土方は自分が土方だってことが
わからないんだろうね。
うちは土方じゃないから改善はしない、
ひたすら汚いコードを作るまでということかｗ
CMMの認定を受けてるところって、
土方企業が一つもないんだよねｗ
どっちが本当の土方なのか、
土方は自分が土方だってことが
わからないんだろうね。
>>911は客なんだろう。
だからゼネコンと土方の区別がついてない。
だからゼネコンと土方の区別がついてない。
>>913
片腹痛いの意味を知らない子供だろ。
片腹痛いの意味を知らない子供だろ。
受託開発してる連中なんて例外なく土方だろ
意訳 俺は受託開発じゃないから、土方じゃないんだ！
元請けは開発なんかしないだろ
客も開発はしないぞ。
そりゃ開発しないというのは
技術者じゃないから当然の話。
そりゃ開発しないというのは
技術者じゃないから当然の話。
30億ぐらいのプロジェクトでインフラチームにいた時、一番最初にPMとアプリ屋の頭の中の考えを聞いてそれ通りに実機とジョブの設定して、
これじゃ困るんでジョブ設計書→パラメータシート→詳細設計→基本設計→運用設計の滅茶苦茶な順でドキュメント作った。
俺一人で。
で、俺が設計書いてる間にアプリチームが設定変えまくったので
設計通りには設定されていない、設計書読んでも実機はそれとは違う設定になってる。
でも俺は本来PMかPLを普段やってて、その時は急遽ヘルプでエンジニアやっただけなんで、設計書とか適当で逃げた。
これじゃ困るんでジョブ設計書→パラメータシート→詳細設計→基本設計→運用設計の滅茶苦茶な順でドキュメント作った。
俺一人で。
で、俺が設計書いてる間にアプリチームが設定変えまくったので
設計通りには設定されていない、設計書読んでも実機はそれとは違う設定になってる。
でも俺は本来PMかPLを普段やってて、その時は急遽ヘルプでエンジニアやっただけなんで、設計書とか適当で逃げた。
> 30億ぐらいのプロジェクト
人数がわからんからなんともいえんな。
素人の人数を増やして開発効率をとことん悪くして、
金がかかりますとか詐欺に等しいし。
人数がわからんからなんともいえんな。
素人の人数を増やして開発効率をとことん悪くして、
金がかかりますとか詐欺に等しいし。
>>828
愚民にIT企業での具体的な事例をおなしゃす(´Д` )
愚民にIT企業での具体的な事例をおなしゃす(´Д` )
前おったところは設計書レビューは全員参加、全員で仕様考えよりよいものを考えていくってスタンスだっった。
それで体裁取り繕ってたが全員でレビューかけたから安全安心()って迷信全員で信じ込もうとしてるだけだった。
仕様を理解しているのは設計者だけで意識共有が全くできていない。
上席者はそもそも開発言語を知らない。
参加者の大半は形式的なチェック、が役割と誤認。
そんなレビュー通っても見た目綺麗な日本語のドキュメントができあがるだけ。
練られてないからトラブルも多く、結局故障改修で慌てて直すから
綺麗な設計書()もツギハギだらけの無残なものになる。
コードと詳細設計対になってた筈がここまでの間に乖離する。
とにかく見た目整然とした設計書整形にパワーをかけては自己満足に耽る人が多くて辟易した。
せめて外部に触れるところに気使えばいいものを担当者しかみない文書の外観に全力注いでどうすんのと。
その癖一回レビュー通ったら後は無頓着っていう。
そうなるの解ってるのにそこだけ張り切るのは私は無能ですって言ってるようなもんなのになー・・・
それで体裁取り繕ってたが全員でレビューかけたから安全安心()って迷信全員で信じ込もうとしてるだけだった。
仕様を理解しているのは設計者だけで意識共有が全くできていない。
上席者はそもそも開発言語を知らない。
参加者の大半は形式的なチェック、が役割と誤認。
そんなレビュー通っても見た目綺麗な日本語のドキュメントができあがるだけ。
練られてないからトラブルも多く、結局故障改修で慌てて直すから
綺麗な設計書()もツギハギだらけの無残なものになる。
コードと詳細設計対になってた筈がここまでの間に乖離する。
とにかく見た目整然とした設計書整形にパワーをかけては自己満足に耽る人が多くて辟易した。
せめて外部に触れるところに気使えばいいものを担当者しかみない文書の外観に全力注いでどうすんのと。
その癖一回レビュー通ったら後は無頓着っていう。
そうなるの解ってるのにそこだけ張り切るのは私は無能ですって言ってるようなもんなのになー・・・
>>923
そんな事して遊んでる余裕がある会社って、脳内だけだろ。
そんな事して遊んでる余裕がある会社って、脳内だけだろ。
>>924
脳内ならどんなによかったことか。
余裕あったと思う？
そいつら余裕無いのにそれで仕事してる気になってたんだよ。
俺辞める少し前から採算取れないので潰すって話が聞こえてて、今は敗戦処理やってるそうだよ。
あんな無駄な職場が存在できたのはある意味奇跡だね。
脳内ならどんなによかったことか。
余裕あったと思う？
そいつら余裕無いのにそれで仕事してる気になってたんだよ。
俺辞める少し前から採算取れないので潰すって話が聞こえてて、今は敗戦処理やってるそうだよ。
あんな無駄な職場が存在できたのはある意味奇跡だね。
大企業ならよくある話。
設計書のレビューなのに、技術的な話はするな。俺がわからない。とか素敵なことを言われたことあるぜ。
いっそ無くしてしまいたいが、権力を示す絶好の場だけに生半可では無理。
設計書のレビューなのに、技術的な話はするな。俺がわからない。とか素敵なことを言われたことあるぜ。
いっそ無くしてしまいたいが、権力を示す絶好の場だけに生半可では無理。
>>926
レビューでほぼ同じ事言われたことあるわ。
解らないから完成品以外持ってくるな、って罵倒された事もある。
でもミンナガーなんだよね。
某大企業の、孫受け先の話。
大企業様のルールでドキュメントを資産と称して作ることになってたが
それを履き違えたアホどもが延々無駄な作業に勤しんでた。
忙しくて人手が足りないらしいからそこに雇われたのに老害の巣窟だったって話。
そこにいた期間、ほぼほぼ無駄な作業の手伝いと火消しやってるだけで終わったわ。
権力示す絶好の場ってのもわかるな。
ドヤ顔でてにをは指摘してる姿みてるとお前就職先間違えてる、としか思えんが。
レビューでほぼ同じ事言われたことあるわ。
解らないから完成品以外持ってくるな、って罵倒された事もある。
でもミンナガーなんだよね。
某大企業の、孫受け先の話。
大企業様のルールでドキュメントを資産と称して作ることになってたが
それを履き違えたアホどもが延々無駄な作業に勤しんでた。
忙しくて人手が足りないらしいからそこに雇われたのに老害の巣窟だったって話。
そこにいた期間、ほぼほぼ無駄な作業の手伝いと火消しやってるだけで終わったわ。
権力示す絶好の場ってのもわかるな。
ドヤ顔でてにをは指摘してる姿みてるとお前就職先間違えてる、としか思えんが。
規模の大小に関わらず、他所様のシステム作ってる時点で開発者なんてゴミクズです。土方がんばれ。
んじゃ安藤忠雄とかなに一つ自分の建物作ってないからゴミ屑だな。お前の理論だと。
自社開発様ってガラパゴス化してるから話かみ合わなくて困る。
土方が自分の価値を示すためにシコシコ設計書作ってるとか噴飯ものだね
そんなこと考えて設計書作ってる奴いんの？
このスレじゃ>>931以外いなそう。
このスレじゃ>>931以外いなそう。
土方ぶち切れワロタ
webとかソシャゲみたいな使い捨て上等のシステムってまともに設計書作ってるんだろうか
>>934
作ってる所と、グダグダの二極化してる。
作ってる所と、グダグダの二極化してる。
なんだ普通のシステム屋といっしょじゃん
スピードが命の世界で設計書まともに作ってるのはちょっと信じがたい
急がば回れってやつですよ
>>937
そうだね、人間にやらせるのが間違ってる。
そうだね、人間にやらせるのが間違ってる。
とりあえず誰も読まないけど形が欲しいなら自動生成で十分だろ。
マジな話、俺はメモ書き程度でも設計書のような物は必ず作るけど、お前らそれすら要らないの？
自分のために必要なら作る。
形式的に作らされるのは時間の無駄。
形式的に作らされるのは時間の無駄。
オブジェクト指向は愚かな考え。
http://peace.2ch.net/test/read.cgi/tech/1393660194/1
http://peace.2ch.net/test/read.cgi/tech/1393660194/1
944 ：仕様書無しさん：2014/06/29(日) 16:09:11.46
最近詳細はソース上のコメントっての多い気がする
設計書として必要と感じるのは全体像を記載したもの。
構造設計書、シーケンス図、状態遷移図、設計規約。後、議事録。
メンテナンスを考慮すると上記が欲しいな。
変更・追加機能が既存機能へ影響しないか、設計方針に沿っているか確認するために
構造設計書、シーケンス図、状態遷移図、設計規約。後、議事録。
メンテナンスを考慮すると上記が欲しいな。
変更・追加機能が既存機能へ影響しないか、設計方針に沿っているか確認するために
形式に則っていること自体が将来自分の身を守ることに繋がるから作る
それはそれで有りだと思う
それはそれで有りだと思う
>>945
今後はこの方向。
OMG SysML
www.omgsysml.org/
The OMG systems Modeling Language (OMG SysML) is a general-purpose graphical modeling language for specifying, analyzing, designing, and verifying ...
今後はこの方向。
OMG SysML
www.omgsysml.org/
The OMG systems Modeling Language (OMG SysML) is a general-purpose graphical modeling language for specifying, analyzing, designing, and verifying ...
まあ設計書ってのはいつの間にか開発のメモ帳になっていくよな。
で、あとで清書して提出するんだよな。
一応、役にはたってると思うw
で、あとで清書して提出するんだよな。
一応、役にはたってると思うw
>>948
人によりけりだね、そういう考え方もアリだと思う
ただし、>>945みたいに制御系の上流設計に関わっている人なら、
実装前の設計内容の検証は当然の事として理解しているはず
（検証手段が従来通りなのか形式化/自動化を含むかは、また別の話）
実装設計の過程で問題発生＆対応を進めつつ
設計書は「あとで清書して提出する」なんてこと、
上流工程の経験者であれば口が裂けても言えない
人によりけりだね、そういう考え方もアリだと思う
ただし、>>945みたいに制御系の上流設計に関わっている人なら、
実装前の設計内容の検証は当然の事として理解しているはず
（検証手段が従来通りなのか形式化/自動化を含むかは、また別の話）
実装設計の過程で問題発生＆対応を進めつつ
設計書は「あとで清書して提出する」なんてこと、
上流工程の経験者であれば口が裂けても言えない
svnで更新ログの説明欄？を変更できなくしてるのはどういった意味があるんだ？
文章を間違ったとき変更できないからずっと間違ったまま残るのはどうかと思う。
文章を間違ったとき変更できないからずっと間違ったまま残るのはどうかと思う。
945です。
どのような設計書が必要かは製品によって違うよね。
1000行程度で利用者も限定される製品と100,000行以上で不特定多数の人に使用される製品をひとくくりに語ることもできないと思うので。
どのような設計書が必要かは製品によって違うよね。
1000行程度で利用者も限定される製品と100,000行以上で不特定多数の人に使用される製品をひとくくりに語ることもできないと思うので。
いや、だんだんドキュメントへフィードバックする時間的余裕がなくなって
中途半端なまま納品して
某金融オンラインシステムみたいにあとから見ても全然わからなくてデスマ一直線
中途半端なまま納品して
某金融オンラインシステムみたいにあとから見ても全然わからなくてデスマ一直線
基本的に開発規模が大きくなる程ドキュメントは必要になるだろ
仕様知ってるリーダーが3人に口頭で説明するのと20人に口頭で説明するんじゃスピード段違いだろう
20人とかになるとリーダーは口頭で指示する以外仕事何もできんし、リーダーの指示待ちで待機状態の部下だらけになる
リーダー待ちの間に自力で解決して次の仕事進める奴なんて少数
コーディング中に全体の稼働率を上げたいなら設計書は必要っしょ
仕様知ってるリーダーが3人に口頭で説明するのと20人に口頭で説明するんじゃスピード段違いだろう
20人とかになるとリーダーは口頭で指示する以外仕事何もできんし、リーダーの指示待ちで待機状態の部下だらけになる
リーダー待ちの間に自力で解決して次の仕事進める奴なんて少数
コーディング中に全体の稼働率を上げたいなら設計書は必要っしょ
〇〇と同じとか仕様書に書くのやめろ。
955 ：仕様書無しさん：2014/07/16(水) 01:48:05.31
設計書は基本設計あればいいよ
詳細書くなら自分でコメントだけ付与して、PGにわたす
数千万位の案件ならな
億単位になると、要件からカオスになる
詳細書くなら自分でコメントだけ付与して、PGにわたす
数千万位の案件ならな
億単位になると、要件からカオスになる
設計書をどのレベルまで作るかは、開発規模(人月) * 運用期間見込み(年)で見当は付く。
～10^0=1 ==> プログラム設計書
～10^1=10 ==> 詳細設計書
～10^2=100 ==> 基本設計書
開発が10人月、運用期間見込みが5年なら、10*5=50だから、基本仕様書から。
～10^0=1 ==> プログラム設計書
～10^1=10 ==> 詳細設計書
～10^2=100 ==> 基本設計書
開発が10人月、運用期間見込みが5年なら、10*5=50だから、基本仕様書から。
>>958
>基本仕様書から。
だから、
～10^0=1 ==> プログラム設計書のみ
～10^1=10 ==> 詳細設計書～プログラム設計書
～10^2=100 ==> 基本設計書～プログラム設計書
ってことなんじゃねえの？
>基本仕様書から。
だから、
～10^0=1 ==> プログラム設計書のみ
～10^1=10 ==> 詳細設計書～プログラム設計書
～10^2=100 ==> 基本設計書～プログラム設計書
ってことなんじゃねえの？
自分の記憶力に絶大な信頼をおいているならともかく、そうじゃないなら
メモ書き程度でも残しておくほうがいいけどね。 だいたい今はタブレットや
スマフォ連携のノートがあるわけで、手書きで残すコストがちょっと前では
考えられないくらい低くなってるから。
メモ書き程度でも残しておくほうがいいけどね。 だいたい今はタブレットや
スマフォ連携のノートがあるわけで、手書きで残すコストがちょっと前では
考えられないくらい低くなってるから。