契約のために必要とかそういうのはどうでもいい。
ユーザーサイドのやりたい事(仕様書) と
それを実現するコードがあれば十分ではないか?
コードではないエクセルなんかの設計書が
役だったことがあるのか?
ないだろう?
いい加減作るだけ無駄だとはっきりさせようか
2 :
仕様書無しさん:2014/03/11(火) 07:23:55.74
え?
設計書なしでどーやって作ってんの?ww
設計書作るまでがNEC NCSの仕事。
設計書がなかったらNEC NCSは何をすればいいのか。
丸投げだけしろ というのか
中小だと設計書、仕様書がないところだらけ
設計書ないと、設計の意図がわからなかったり、仕様と実装の区別がつかなくなる可能性がある。
つまり、本人が生きてる間忘れずにメンテナンスし続けられるのなら不要。
他人が触る可能性があるなら必要。
コードを日本語にしたような設計書は不要。
>>4 やることの規模が小さい上に、客が「ドキュメントには金払わん!」って言う案件を営業が普通にとってきちゃうからだろうな。
ふつうに考えたら、後で自社が割を食う可能性があるから、ドキュメント書く時間も含めて見積もりするべきなんだが。
>>6 しかし、それだと他の安いところに発注されてしまうというジレンマ
8 :
仕様書無しさん:2014/03/11(火) 20:08:51.84
そうやってコードだけ残った仕事を受けて、
ソースからプログラム仕様書を書き起こして機能拡張して仕事した。
たぶん今でもそれ流用されてると思う、設計の骨子はそこにしかなかった。
仕様書を全部仕上げる前に会社無くなって、次の人が完全版に仕上げたんだと思うけど。
ソース見れば判るって人やチームを雇えていたら安泰だろうけど、
RTOS制御下で動いてたから状態遷移やらの仕様書が必要、1から調査するパワーのあるチームが引き継いだと考える。
でも今なら、RTOSで動いてるからわかんねーよwで通じるのかw
9 :
仕様書無しさん:2014/03/11(火) 23:43:45.47
むしろ設計書が無い現場では死ぬ思いをした記憶しか無い。
>>9 死ぬ思いをしたことがあると「必要なドキュメントは絶対に残すべき」事を身を持って学ぶよね…
現場知らない人が契約で無駄なドキュメント作る約束して、無駄だと分かりながら作る誰も読まないドキュメントは要らない
11 :
仕様書無しさん:2014/03/12(水) 06:18:55.07
バイナリしか残ってないわろちん
前の会社(孫請けやってるような小さい会社)が社内wikiにメモ程度しか書かないところで、改善提案したら「うちは開発スピード重視です」って言われたな
結局後でカオスになって、「急がば回れ」という言葉の重みを知った
>>10 まったく同感だ
死ぬまでの思いは経験したことは無いが、もう20年ほど昔、
同じ部署のプロジェクトが大炎上したことがあった
出荷日程の延長も限度があり見切りでリリースせざるをえなかったが、
結果として6年間に渡って障害対応に追われ、最終的にメンバー全員が退職に追い込まれた
当時は今ほど転職情報も無く終身雇用が当たり前の時代、
しかも協力会社とはいえ大手メーカ系企業へ就職して将来は安泰だと思っていたはず
退職したメンバー達は自分と同じ会社の同僚であり、どれだけ悔しかったか
当時、自分は別プロジェクトでサブリーダをしていたが、
自分と自分のメンバー達には同じ思いをさせたくなかったから、
品質確保を最優先に必死に頑張った
もちろん大炎上した大きな要因の一つがドキュメンテーションであったのは言うまでもない
>>12 当時は、自分のところだち「急がば回れ」よりも「先憂後楽」という言葉が使われていたね
14 :
KAC:2014/03/12(水) 22:03:35.10
「設計書が」とか言ってるうちは駄目だ。
まずは、ちゃんと設計しろ。
開発メンバーでその設計を共有しろ。
コードを書くのはそれからだ。
共有したり、読み返したりするのに設計書が必要なら作ればいい。
設計をレビューするのには必要。
>>14 >まずは、ちゃんと設計しろ。
設計が「ちゃんとしているか」をどうやって判断するのか、それが問題の焦点だよ
自分は、設計の成果物が設計書であると考える
そして(
>>15が指摘しているように、)設計がちゃんとしているかを判断する場がレビューであり、
そのレビューの対象物が設計書になる
17 :
KAC:2014/03/13(木) 01:24:03.12
>>16 設計書作りが目的になったらアウトな。
そんなことになってると、
>>1みたいな疑問が出てくるんだ。
設計書を残すのは当たり前だが、
設計書のレビューは「設計どおりに記載できているか」を見るものだぞ。
ちゃんと設計できてるかも解らないうちからレビューなんてするから
ろくに設計されていないまま突き進むんだよ。
設計より、仕様を固める方が有意義
仕様がキッカリ決まっていて矛盾が無ければ
むしろ設計なんて蛇足でしかない。
日本語ソースコードもどきの設計書なら役には立たないだろうなあ
>>17 レビューしなくても完成された設計ができるほど簡単な仕事で羨ましいな。
22 :
KAC:2014/03/13(木) 21:49:50.07
>>21 設計まともにやったこと無いのか。
ちょっとチームメンバー集めて、話しながら設計してみろ。
>>22 > ちょっとチームメンバー集めて、話しながら設計してみろ。
暇そうだな。もしかしてメンバーはタダ働きだったりする?
話しながら設計だと、なんで暇そうになるんだ?
ただ働き? なんで?
どうしてそんな馬鹿な発想をしたのか
お前の頭のなかが見てみたいから
説明してください。
全員拘束して一つの設計しかできない。
もしかして、一人では設計できない無能なのか。
>>17 >設計書作りが目的になったらアウトな。
言わずもがなで当たり前の前提だよ
>設計書のレビューは「設計どおりに記載できているか」を見るものだぞ。
いや、自分の考えは違うな
記載を見るのではなく、記載を通して「設計がちゃんとしているか(
>>14)」を見るものだと考える
記載という仕様表現は「ちゃんとした設計」を記述する為の手段であり、
手段と「設計がちゃんとしていることを確認する」というレビューの目的を取り違えるべきではない
>ちゃんと設計できてるかも解らないうちからレビューなんてするから
>ろくに設計されていないまま突き進むんだよ。
ここもまた、考え方が違うみたいだね
自分のところでは、レビューの結果として設計がちゃんとしていないと判断されたなら、
設計を差し戻して再レビューを実施することになる
で、日程ぎりぎりでの一発レビュー通過なんてのはリスクが高すぎるから、
メンバーには100%の完成品でなくてもいいから、早め早めにレビュー準備完を報告するよう伝えている
>>17のところのような、レビューしさえすれば無条件に次へ進めるような品質管理は、怖すぎて自分には無理だ
>>26 設計書のレビュー云々は同意
というかそれ以外の意味があるとは思えない…
いや、
>>17のケースは全員で設計するから、設計そのものは最適なはずだという主張だと思うぞ。
>>28 「設計そのものは最適なはず」という前提で進んで、
時には日程通りに終わったり時には大炎上したりするわけか...
冒険的というかギャンブラー的だけど、そんな考え方もあるのかもしれないね
でも自分は気が小さいから、「.....なはず」と確証できるほど自身の技術力に自信がない
だから、一歩一歩、レビューによって設計がちゃんとしているかの確認作業を重ねることで、
品質を積み上げていく方法を選ぶしかないや
こういう話する時、ドキュメントの種類が多すぎて話が噛み合ってないこと多いよね。
hoge仕様書とかいっても、それぞれ定義が会社の風土によって違ったり、プロジェクトの規模によっても作る意味のあるドキュメントが変わってくるから。
一度文書システムに登録された設計書は改版に妙な手間がかかる某社某工場への常駐は
長く関わるとよく人がぶっ壊れる為ぶっ壊れても良い程度の奴が割り当てられる。
出来た製品はお察し。
32 :
KAC:2014/03/14(金) 00:51:51.63
>>29 お前さんの懸念は、それこそ
各自が設計した物を持ち寄って「レビューした物は大丈夫なはず」
って前提で突き進んで大炎上するパターンだろ。
なんで各自まかせでまともな物に仕上がるとか思えるんだ。
ふつうは、みんなで意識を合わせながら設計を進めるもんだよ。
「レビューだけで何とかなる」なんて思ってるから、
ろくに設計できない とか言われるのにそろそろ気づけ。
つか、なにかバグ出したとき設計した本人以外対応できないとか
言い出すパターンなんじゃないか?
設計書も適切なメンテがされてないと無いのと同じくらい厄介なんだよな。
Chromiumなどオープン系はこれで困ったことないな
・svn,git blameでコミットした人、コメント、ハッシュキーを確認
・ハッシュキーでコードレビューを検索、どういう経緯でコードが書き込まれたか確認
・レビューに紐付けられたイシュートラッカーで変更の目的を確認
・構成など全体的な作りはwikiに記入、全文検索できる
コードを書くのは下々の仕事、
設計書は作業指示書なので必須。
というゼネコン思想がまだ強いのでしょうか
うちは下々だけど全部丸投げされてる
箇条書きで要望が書かれてるA4の紙わたされるだけ
設計も全部やってる
だから3回作り直す工数でやればいいんだよ
どうせ設計しても客の要望どうりには作れない
客が要望をわかってないから
38 :
KAC:2014/03/14(金) 16:25:26.37
>>37 要望は客が出してくるもんじゃないぞ?
客から聞き出すもんだ。それ含めての仕事だろ。
何のために要件定義と仕様策定を開発の最初にやるのかよく考えろ。
>>35 コードも書くけど。
設計レベルでクロスシーケンスの際の挙動とか押さえとかないと、
コーディングに入ってその辺の考慮漏れが発覚すると修正が非常に面倒。
結局のところメンバーの質、企業の質による。
信頼して仕事を任せられるメンバーしかいないなら、対面やチャットでアーキテクチャの認識合わせを行って
コードレビューで修正していくだけで十分まともな成果物に辿り着ける。
ウォーターフォールによくある感じの内容の詳細設計書なんてものは、UTやFTの実装で代替できる。
顧客と認識をあわせるための要件定義、触って確かめるためのモック、
アーキテクチャの認識合わせに使った簡単な資料、自動生成されたドキュメント類で十分な感じになると思うよ。
底辺な場所ほど、無知識メンバーが増えるから、コードと対になるような設計書がないとまともなものが作れなくなる。
>>40 それを5年10年続けられるのならそれでいいんだけどな。
情報系の学校を卒業してこの業界に入って10数年やっているけど、入って
驚いたのが、割りとあっさりと書いたコードが本番に流れるのと、思った以上に
長く使われ続けることだな。
当たり前なんだけど、1ライセンス数万でも数十人数百人が使うとなると
数十万、数百万円になるわけで気軽に買い換えれるものじゃないから
長く使われるよな。億単位のシステムならそりゃしがみつくだろうよ。
自衛の意味でも取り残された所に縛り付けられたく無ければドキュメントを
ある程度以上は残しておかないとって考えになれない人はヤバイよ。
>>41 やばいよな、自分がシステムの一部にされる奴
あんな仕事やるならプログラマー辞めた方がマシ
ドキュメントがなくて複雑なコードを相手にしているから
ドキュメントがあれば〜、ドキュメントさえあれば〜っていう
そういう間違った思い込みをしてしまうんだよ。
ドキュメントがあるところなら身を持って知っているはずだけど、
ドキュメントがあっても役に立たない。
作る方は楽だよね。今相手にしているコードのドキュメントを書けばいいだけだから。
コードが変わっても、メンテしなくても動くわけだから必須じゃないんだから
後から読む方は大量にあってそれを読む時間はないし記憶することも不可能。
そして間違っている可能性もある。結局コードを読むことに変わりはない。
問題は複雑なコードを書いてしまう技術力の低さになる。
そういう技術力が低い所はドキュメントの質も低いと見るべき。
結局のところ複雑なものをいかに単純化出来るかにかかってる。
コード見ただけでわからないからドキュメントを書くべきという発想は
複雑さを回避することにはならない。
>>41 つってもドキュメントが動いてるわけじゃないし、時間が経つほど結局実装を見ないと確証とれないってなるじゃん。
そういうのが理解されてきたから、実装に紐付いたドキュメントをしこしこ作る流れから、
読みやすいコードを書いて、コードから生成できるドキュメントを作って、みたいな流れになってきてるんだと思うよ。
あと、転職を念頭に入れてるかって違いもありそう。
低水準用のドキュメントがないと縛り付けられるような企業から
抜け出せないって感じなら、そういう考えなのは理解できなくもないけれど、
自分としては、そういう企業に貢献し続けたいって意識が持てないな。
「わかりやすコード」の定義には二種類あるんだよ。
その一つがCOBOLという言語の特徴にもなってる。
それは「プログラム言語という言語がわかりにくいから
自然言語(英語)と同じであればわかりやすいはず」という考え
本当にそれがわかりやすいかといえば、今のCOBOLの評判をきけば
わかるでしょう? (自然言語に近いから)冗長なコードと言われている。
ドキュメントも同じで「プログラム言語がわかりにくいから
日本語で書けばわかりやすいはず」という発想にすぎない。
そういう、能力が低い原因(つまりプログラム言語がわからない)を
補うための手段は、言語障害を解決した(?)かもしれないが
処理を記述する能力不足を解決する事にはならなかった。
英語で優れた小説が書けない。日本人だから。
じゃあ日本語で書けば優れた小説書けるんじゃない?
↑
書けるわけないよね? つまりそういういこと。
>>43 どういう要求があったか、それによってシステム設計がどういった思想の元にどうなり、プログラム的にどんなインターフェイスで区切られているか。
あとは適切な命名がされているならプログラムのdocがあればほとんどのことはわかる。
そういうレベルの話をしている。
プログラムを日本語に翻訳したアホなドキュメントの話ははなからしてない。
これは、自然言語 と 数式
どちらがわかりやすいか?って話にもなる。
これは「知識を持った人」にとっては明らかに数式の方なんだよ。
x=(-b±√(b2-4ac))/2a
たとえば、これを自然言語になおしたら冗長になる。
知識を持ってる人にとってはこれだけで十分であっても
知識を持ってない人にとってはわからない。
わからないコードを目の前にした時、
自然言語に直して理解するか、数式を直接理解できるようになるか。
どちらもわかるかもしれないが、前者では冗長にならざるを得ない。
自然言語に直すというアプローチは失敗して、
今のプログラム言語を見ればわかるように、数式にかなり近くなっている。
>>44 >自分としては、そういう企業に貢献し続けたいって意識が持てないな。
あなたは不労所得が大量にあるのですか? それともコミュニストですか?
自分のやりたいことをやりたいようにやって、周りから笑顔で受け入れられる
人なんてほんの一握りですよ。不本意であろうがなかろうが生きていくために
受け入れたり抵抗しながらやっているのが人間だと思いますよ。
それに程度が低いと思っている会社で質の高い仕事ができない人が
どこか他の会社に行ったからといって、出来るようになることは無いと
私は思います。 実際そういう人は多いし。
どうでもいいことで話を膨らませてもしょうがない
結局のところ、設計書は大して役に立たないのは時代が証明してるし
それくらいしか任せられない人間のために仕事を作り出してるに過ぎない
ドキュメントもコードと同じで単純にして量を少なくしないといけない。
量を少なくするにはどうすればいいか。それは、量を知識に変えること。
たとえば、微積分を教える時に、掛け算の説明までしないでしょう?
知識があることで、説明するべきことを大幅に減らすことが可能。
だからドキュメントには、知識があれば十分であることは省くべきである。
とはいってもなんでも覚えればいいかというと覚えられるわけがない。
そこで覚えるべき知識と覚える必要はないものを明確にする。
覚えるべき知識というのは、汎用性があってどこでも使える知識。
特定の会社でしか使えないような知識は覚えても、会社辞めれば役に立たないし、
中途で採用した人であっても、使うことが出来ない。
ドキュメントの量を減らすために、世の中で一般的に使われている技術や
設計パターンを取り入れて、ドキュメントの中からはその説明は省くべき。
それが出来るのが技術者であり、それをよめるのも技術者。
ドキュメントは技術力を補うために作るものじゃない。
技術力を補うためのものは教科書である。
自由度が高いプロジェクトなら設計書が無いと無理。
フレームワークとか使いまくって、ある程度誰が書いても同じようなコードになる
プロジェクトなら、設計書無くても何とかなる。
顧客から全関数と変数の説明を書類化してくれと依頼が来た。
今更doxygen用にコメント整形する暇もねえしどうすんよ。
>>53 > doxygen用にコメント整形
そんな楽な仕事やりたいわー
>>54 ごめん、嘘書いた。正確には
ソースにコメントいちから付けていく作業だった。
いずれにせよ、そんな仕事に金だしてくれるいい客じゃないか。
ドキュメントつっても、ファイルで管理してる資料はろくなことないんだよな。
結局管理に失敗するか、無駄な工数吸い取られてく感じだ。
特に、方眼紙が大量にある場合の絶望感はやばい。
印刷レイアウトで見た場合の整形にこだわる老害とかいたりすると、更に酷いことになるw
>>49 え、なに?そんなにそこが気になったんなら謝るよ、ごめんね。
>>56 開発費として既に受け取り済みで、開発期間の最後に思い出したように言われるんだよ。
>>52 まともなコーダーだけで構成されてて、全員声の届く範囲にいるなら、自由度が高くてもなんとかなるし
フレームワーク使っててもアホが混じるとうんコードが生み出される
自由度っていうか、フレームワークで線をひくのはちょっと乱暴な感じもするな
やっぱり人間っていうか技術者のスキルに左右されると思うわ
>>57 wikiが手っ取り早く準備できて使い勝手いいな
検索も履歴も管理できるし章立てた文書も書きやすい
49は図星だったんだろう
ウォーターフォール開発、オフショア開発みたいなのを続けてる大手だと、そういう感じの人間多い
若いヤツは見切りをつけてベンチャーに流れたりもできるが、歳食うとどうにもできなくなるしな
>>58 よくあるやつだなw
契約時に納品物が明確にされてても、言ってくる場合もあるし
そういう時に限って営業がYESしか言わなかったりで…
61 :
仕様書無しさん:2014/03/15(土) 15:26:44.39
>49は図星だったんだろう
2chでこういう勝利宣言みたいなのいらないから
62 :
仕様書無しさん:2014/03/15(土) 15:31:47.90
要件定義や設計思想、インフラの資料は必要だけど、実装の資料はコードに勝るものなし。
読めないコードしか書けない奴に設計書なんて書かせても、読めないものしか書けない。
作った成果物の説明資料や、メンバーとの認識合わせに使った資料は、開発に役立つと思う。
けど、スレタイにある「設計書」っていう括りだと、作業指示を行うためのドキュメントか、
これから実装するコードを自然言語化した資料みたいなイメージ。
大抵そういうのは、コードを読めない人が設計をレビューするために、
Excel方眼紙なんかに自然言語で実装してるだけにすぎない。
このような設計書は殆ど開発には役に立たないと思う。
むしろ、保守がメインになる段階では、負の遺産になってる事のほうが多い。
63 :
仕様書無しさん:2014/03/15(土) 16:14:35.85
>>60 全部を1つで賄う必要はないから、図は別のツールで作ればいいんじゃないかなー。
最近のWebシステムなら画像ファイルとかだってDnDでアップロードできるし、添付もそこまで面倒だとは思わない。
あとで修正するように元データもつけておけば、保守もしやすいしそっちのバージョン管理にもできる。
ER図にしても、クラス図にしても、ポンチ絵にしても、適したツールで編集するのが一番楽できると思う。
あと、Wikiでできないようなとてもステキな資料は、おそらく開発には役立つことがない。
>>62 ひねくれてるなー
設計書っていうからには、設計思想が記述されているのが普通。
> 作業指示を行うためのドキュメント
作業指示書
> これから実装するコードを自然言語化した資料
このレベルになると、普通はコードから自動生成するわな。
> あと、Wikiでできないようなとてもステキな資料は、おそらく開発には役立つことがない。
UML万能だとは思わないが、シーケンス図・状態遷移図は大体どんな開発でも使うなぁ。
あと、ハードが絡めばタイミングチャートも。
>>64-65 UMLツールで作ってWikiに貼ればいいって話じゃ
UMLツールじゃ要件定義書や基本設計書みたいなのは書けないし
道具は使い分けてナンボ
つーても俺はUMLは事後で実装の説明をする必要がある場合くらいしか使わないので
設計ツールとしてUMLを使ったりはしないが
あと「普通」って言い切って突っかかるのは井戸の蛙すぎじゃね
なんたら設計書の認識ズレなんて何年も前からこの板に限らず話題に上がってることだし
そもそも設計思想なんて微塵も書いてない糞の役にも立たない「設計書」なんてごまんとある
情報が存在するかもしれない僅かな可能性にかけてクソ資料を漁ったり
コードの行間から実装者の考えを想像するような、国語の授業みたいな作業をしてる時間が多いと
「そういうのがまとめられてたら、ボクももう少しだけ幸せになれたのかな・・・」って気分になるわ・・・
Wikiは設計メモ集として有益なツールだと思う
プロジェクトが進行する中では様々な検討課題や問題点が生まれる
そういった雑多で不定形であるけれど重要な情報を記録する手段としてWikiは最適
もちろんクラス図や遷移図/表などは別のツールで作成してWikiへ添付すればいい
ただしWikiはあくまでも設計のメモ(断片)であって、Wikiそのものは設計書ではないと考える
Wikiに記録されたメモを最終的に保守に役立つよう筋道をたてて整理し、
最終的に設計書という成果物としてまとめることが望ましい
メインはコードであって
設計書はそれを補佐するもの。
つまり断片にしかならん。
説明不要な小さなコードに設計書は不要。
大きくなったら? 必要な物だけを作ればいいだろう?
>>68 個人でメモを取ってローカルで抱えられるよりは、断片的だろうがwikiみたいなのに
ありがたいんだけどね。皆wiki記法なんて気にしないで手軽に書き込めばいいのに
とは思う。
何かを修正するとき、設計書は見なくても、コードは見ないことはない。
だからドキュメントはコードの近くにあると良い。
そしてコードと同じことをドキュメントと二重管理するのは無駄。
と考えればドキュメントはソースコードそのものか
それを格納しているディレクトリに書くのが良い
ソースコードではない所に、ソースコードの説明を書いたって
意味不明なドキュメントになるだろう?
なぜなら「完全なドキュメント − ソースコードの部分」が
書くべき無駄のないドキュメントなのだから
71 :
KAC:2014/03/15(土) 20:34:37.83
>>70 一行目から間違えてるな。
ソースコードだけ見てるのは、そもそもケアレスミスとか馬鹿みたいな修正だけだろ?
設計に関わるような修正する時は、コードなんて見ない。
設計書を使ってイメージを合わせて、修正を検討してコミットする。
ソースコードなんて見るのは最終的に書き直すときからだよ。
ソースコードだけ見てても、木を見て森が見えないだろ?
・・・・つか、たとえばセキュリティ評価とかソースコードじゃそもそもできないだろうに
いったいどんな品質評価してんだ?
73 :
KAC:2014/03/15(土) 21:25:17.17
>>72 動くなんて当たり前。
いかに品質あげるかが腕の見せ所だぞ?
ドキュメントの品質を上げても
動くコードの品質は上がりません。
75 :
KAC:2014/03/15(土) 21:48:27.32
77 :
仕様書無しさん:2014/03/16(日) 01:43:45.20
>>76 馬鹿にされとる事もわからんとは
底辺恐ろしか
>>77 俺がお前を馬鹿にしていることには
気づいてたかい?w
>>78 おいおい、お前を馬鹿にしていたのは俺だぜ
あ、やっぱり馬鹿にしていたことに気づいていなかったみたいだなw
だね、馬鹿にされていることにまったく気付いていないw
馬鹿ばっか
馬鹿が馬鹿を馬鹿にしているのを見ると
本当に馬鹿馬鹿しく感じるものだな
まさに、馬鹿っていうほうが馬鹿なんだの
格言(笑)通りだね。
85 :
仕様書無しさん:2014/03/16(日) 13:19:44.42
Deoxyge
Doyxgne
>>71 こいつ、これ単体でみると妥当な発言に見えるんだけど、序盤に言ってた事が馬鹿なんだよな。
それが、こんな過疎板で名前付けちゃってる痛さと同時に記憶されてて、名前見るだけで読む気しないほどキモい。
まぁ、一応読んだけど。
くだらない馬鹿にしあいはやめなよ。
それと、あいかわらずお互い話してるドキュメントのレベルがずれてて会話噛み合ってないと思うんだけど。
>>87 つまり何が言いたいの?
馬鹿なんだよなってのはいいんだが、
その理由をお前は何も言ってないよ。
「ばーかばーか」といってるのと同じレベルだって
自分で気づいているのかな?
必要も何も、納品物にリストアップされてんだから作るしか無いだろって
つまりそれは開発に役に立たないという意味でいいのか?
>>90 いいんではないのかな
・コードを日本語にしたような設計書は不要。(
>>5)
という認識は、このスレ住人なら誰でも同意するのではないかと
ただし、残念ながら
・納品物にリストアップされてんだから作るしか無い (
>>89)
のが現状で、役に立たない設計書を「作らされている」と感じている
作れって指示あるから実装完了後にやっつけで書きました
みたいなケースが多いんじゃね
つうか、納品用に作る設計書って、あれは実際はソフトウェア実装説明書だからなぁ
本来の意味の設計書って、作成前に作る青写真であって出来上がりと食い違うのは当たり前なんだよなぁ。
それを出来上がりに合わせて修正する事自体無駄な話だよなぁ
それがえらい人にはわからないのが一番の問題。
ソースにコメント書いてもらった方がよっぽどありがたい
もちろん設計とまでは言わないが処理概要くらいはいる
設計書と同じものを、ソースコードに書いて
納品しても、意味は全く一緒だよな?
大の男がチマチマとポチポチキーボード叩いて
そのうえ、あーでもないこーでもないと細かい話をして
あーくだらないくだらない
さっさといらないドキュメントと、いらないドキュメントを要求する客を抹殺しろお前ら
>>94 何百ファイルとあるソースファイルから目的の部分を見つけるのが簡単だとでも?
趣味や仕事でも小規模なので、自分で作り始めたのならそれでも回せるんだろうけど、
普通の仕事だとそうじゃないってことが理解出来てない人が多いいんだよな。
98 :
KAC:2014/03/16(日) 18:34:31.35
まともな設計やったことがないから「設計書」ときいても
何を書く物なのかすら想像できないんだろう。
そうだな。わかりやすい題材で
テキストエディタを作るとして、
設計書にはどんなことを書くか、
>>98に答えてもらおう。
100 :
KAC:2014/03/16(日) 18:43:35.77
>>99 ここじゃスレ違いだろ。
相手してやるから新しいスレでも立てろ。
で、お前の思いつく限りでいいから仕様を詳細に書いておけ。
足りない部分は訊いてやるから。
>>101 てか、その程度の内容なら「Joel on Software」の中にあったような…
まぁ、やるならそっちでやってくれた方がありがたいけど
103 :
KAC:2014/03/16(日) 22:05:21.47
>>101は逃げたようなので、まともに仕様すら出てこないよ。。
>>103 新スレで
>>99の問いかけに答えるまで、戻ってこなくていいよ
KACなら「テキストエディタの設計書として何をかくべきか」知っているんだろ
とっとと書いてこいや
教えてもらう立場の
>>101があまりにも馬鹿でわろたwwww
あっちでもこっちでも、わかりやすい自演だな
仕様書書けるまで帰ってくんなよ
必死だなww
ユーザだって処理詳細は把握しておきたいわけで、
でもユーザはソースコードが読めないだろ。
その為にも設計書は必要なんだよ。
今10年以上前のシステムをリプレースしているが、
設計書無いし、ユーザは誰も詳細が把握できないから、
早い段階から火吹いてる。
今、急遽客先常住で入れられて>1みたいな奴が作った
ソースコードを解析して設計書におこしているよ。
仕事内容としては楽でいいけどね。
あまり細かく書いてはいかん
設計書よりテスト確認書の方が無駄だわ
あんなん自動化できるだろ
>>111 内容による。シミュレータ作ってる時間が無いこともあるし。
>>95 設計書と同じものを書けば同じだけど、そんなことやるのって相当のマゾじゃね?
俺はやりたくないわ。
設計書のうちのどれを指してるのか分からないが、いくつかは絶対必要だし、いくつかは不要。
客に見せなくても、必要なものは必要。
先日元請けが適当なもの寄越して死にかけた。というか死んだ。
116 :
仕様書無しさん:2014/03/17(月) 21:54:09.96
設計書がいらないと言ってる奴は、設計書を必要とする立場に立ったことが無いんだろうなー
ちなみに、設計書を書く奴にとって、設計書が役に立たないのは当たり前。
「俺が設計理解してるんだから、設計書なんていらないだろ」って言ってるSEと同じ。
>>116 役に立つ設計書の内容の例を
上げてみてよ。
それは、仕様もしくは
コードに書くことのどちらかだろうと思う。
何十万行というソースコードと、仕様書だけ渡されて
「ここの仕様をこう変えるからよろしく」と言われたときは地獄だったなー
モジュール構造とかイベントの伝播経路とか解析しつつ作業進めていったんだけど、
後になって設計思想と違う修正してたところが判明する度に、そのまま進めるか
再修正するかで揉めてたわ。
119 :
118:2014/03/17(月) 22:31:11.77
そういや、怪しい中国語サイトから元になった製品のプレゼン資料とかを
ダウンロードしてなんとか解析を進めてたな。
モジュール構造とかイベントの伝播経路とかって
詳細設計じゃないの?
そんあのSEがやる仕事じゃないと思うけど?
詳細から追っていかないとどうしようもない。
モジュールも書いていない設計って何なんだ?
え? SEはコード書かないでしょ?
設計する前にコード書いたらダメなんだよ。
はははこやつめ
>>123 ずっと昔にそういう従来のやり方だと小さい規模でも複雑さがでかくなりすぎて
どうしようも無くなってるんだけどね。 そういう部分を解消できないから日本の
IT業界、特にSIerとか言われるところの利益率が低いままに何十年と続いている。
126 :
仕様書無しさん:2014/03/18(火) 03:14:25.84
127 :
仕様書無しさん:2014/03/18(火) 04:59:16.80
>>117 役に立たない設計書とやらを紹介してくれ
>>127 >>117 じゃないけど。
・レビューされてないもの
・必要な記述が無いもの
・嘘、紛らわしいもの
いくらでもあるんじゃ
お堅い客相手だと、300行のコードに1000ページの仕様書とか必要になったりする。こういう設計書は明らかに過剰。
ただ3000行のコードに10数ページ程度の仕様書はほしい。
各ソースファイルの概要や構成、全体の動き、要求事項がわかる程度の。
>>128 それは設計書が役に立たないんじゃなくて、
まともに設計書が作れていないだけだろ。残念ながら。
>>117 このスレ見てると、設計できない(というか理解していない)奴が居るのに愕然とするよ。
仕様と設計と実装の区別くらい流石につけろ。
とりあえず、要求仕様書とか要件定義書とか設計書がどんなものか知りたければ、
software requirements specifiction tempalte
software design template
とかでググってみるといいんじゃないかな。
ググっても間違ったものがヒットするから、
わかっている人がググって、
そのリンクを書いてくれよ。
133 :
仕様書無しさん:2014/03/19(水) 01:00:11.63
設計書が古くてコードとの整合性が保たれてないから当てにならない。
元請けが要求する設計書がゴミなだけで役に立つ設計書もあるはずだよ
俺は見たことないけど
設計書ってどう実装するかしか書かれてないからな
実装の意図とか目的を知りたければソースのコメント見るしかない
実装に関してはソースコード見るのが一番。
設計の意図とか目的を知りたければ設計書を見るしかないしな。
設計の意図ってさ、ソースコードの量に比べて
かなり少なくなるはずなんだけど?
設計がコピペじゃない限り、つまりあの画面とこの画面、
画面ごとに同じような設計を書く必要はなく、
設計の意図だけ書けば、ソースコードの量の100分1ぐらいにならないか?
馬鹿じゃねーの
いや、設計の話。
設計に何を書いて何を書かないかをはっきりさせれば
コード以外で書かないといけない部分は
ごくわずかになるのはわかると思う。
書く書かないで考えるからわからない。
意味があるかどうか、実際に役に立ったかで考えてみよう。
画面ごとに設計を書くなんて聞いたこと無いけど。
画面ごとに仕様を書くなら聞いたことある。
画面仕様を設計した結果の仕様書?
禅問答ばかりのくだらんスレだな
仕様書まで自社で作成して、コーディングを外注するとき設計書がいる
裁判沙汰になったときも設計書が必要
>>143 答えは「役に立つ設計書もあるし、役に立たない設計書もある」でしかないからな。
役に立つ設計書って、ソースコードの100分の1程度の量になるよね。
何でもかんでもあったって意味ないし。
文芸的プログラミングをどうぞ
一事が万事、役に立たないとか言ってやらない理由を探すの奴は使えない奴が
多いよな。 お前は未来のことを知ってるエスパーか何かのかと。
どんなことでも役に立てようと心がけがで、出来ないのかと思うよ。
禍福は糾える縄の如し、人間万事塞翁が馬とかいう諺が昔からあるくらい、
将来のことなんか分からんのに、知ってるふりしながら先に備えないのは
ただの馬鹿のやることだよ。
まあ、このようにノイズばかりだと
何を言いたいのかさっぱりなわけです。
>>148を見ればわかるでしょう?
ノイズばかりと切り捨てるのがバカがやる仕事だな。2chなんて十中八九ノイズな
スレばかりなんだから、その中からどう役に立てるかッて言うことが分からんの
だろうな。 まあ、2chに限らずインターネット、リアル共にノイズが溢れてるけどね。
今どき言われているビッグデータなんてのはノイズが大量にあるデータで、
役に立つかどうかもよく分からないのを役に立てようっていう試みなんだけどな。
一々他人を批判しないとモノを言えんのか
はい、そうです。
>>131 最近RDRAっての知ったが、あのシステムの地図を作るという思想は有用だと思う。
>>1 お前が作ってるものが何なのか
それを回りに資料を添えて説明する義務がある
設計書っていうのは意図を伝えるものであって
自分の欲しいものを自分で作る人には関係ない話だよ
自分の欲しいものを他人に作らせるにはどうしても必要
>>157 それは違う。
自分で作るときに、その作り方を間違えないように計画を立てるのが設計。
自分で作るときの計画を単に他人に見せるだけ。
自分が使う計画として何が必要か?を考えれば設計に何が必要で
何が必要ないかがわかってくる。計画書に必要ないものは設計に書く必要はない。
今の設計書の多くは無駄なことばかりなんだよ。
どうせ全部の作成手順なんかかけやしないのに中途半端に書いてある。
中途半端に書くからバグや漏れもある。それを放置するから
設計書と実装が違うということになって混乱を招く。それなら書かない方がいい。
設計書には全体の計画だけを書いておいて、あとはコードレビューをすればいい。
どうせコードレビューは誰かがするもの。コードレビューが必要ないほどの設計書なんてかけやしない。
特に開発の初期に考えた設計書なんて、実際のコードに当てはまるわけがない。
どこにつっこめばいいか迷うレベル
新人なんだろ。
指導してやれよ
>>159 今朝同じこと書き込もうか迷ったまま出勤したが、やっぱそう思うよな…
思い込み激しいのかな
設計書と実装がちぐはぐになっている→書かなければいいじゃん(キリッ)
という極論思考な時点でどうかと思う
「アホなの?」で片付けてしまいたい
言い返せないのなら
レスしなくていいと思うよw
馬鹿にされまくってることにも気付かないのか。可哀想に。
馬鹿にするのではなくて、
言い返せということ。
言い返せないから代わりに馬鹿にするってのは
お前のかーちゃんでーべーそって
言ってるのと同じ。
166 :
仕様書無しさん:2014/04/10(木) 02:01:52.80
ほんと可哀想な頭なんだな
だから言い返せないのなら
レスしなくていいってw
何が目的でレスしてるのさ?
いや、みんなツッコミどころ多すぎて呆れてるだけだから…
今度時間ある時に気が向いたら突っ込むけど、その前に一度自分のレスが噛み合ってるか見直してごらん…
目的は、ばーかーばーかって言うためなんだろうな。
ほんとレスの価値がない。
>>168 いえ、だから言い返す内容がある時に
その内容を書けばいいだけですよ。
内容できてないのになんでレスしちゃったの?
そのレスの価値ないよね。
相当おかしいこと言ってることに全く気付きもしないような馬鹿に何言っても
自分の非を認めるわけないんだから時間の無駄ですわ
論拠が妄想って時点で相手にする価値も無いし
発狂してるアホガキ晒しage
だから、そんなレスすることが目的なのか?
反論できてないってことしかわからんのだが。
結局、なにかムカついて言い返したいんだけど、
それをやる力がないから、
ばーかばーかというようなお前はガキか
みたいな発言しかできんのよ。
お前の目的も謎。
俺の目的は、レスする内容がないのなら
黙っていたほうが、馬鹿に見られなくてすみますよって話。
内容がないただの悪口は、俺には
「ばーか、ばーか」って書いているようにしか見えないから。
長々と馬鹿晒してるお前が言うと説得力ないわ。
俺にレスするからだろw
俺は、これだけしか言ってない。
言い返せないのなら
レスしなくていいと思うよw
キミまだいたの
>>158の言ってることは割と同意なんだが…
計画と言うのはなんだけど全体の構造というかそういう俯瞰図的なのはいるけど詳細なのは意味ない。
まぁ入出力とかは別かもだけど。
181 :
仕様書無しさん:2014/04/10(木) 13:08:56.07
今はタッチパネルが主流だが、昔は専用ボタン等を配置する操作盤を
設計し専門業者に発注してた。 同じように、タッチパネルでもボタンの
配置と機能をあらかじめデザイン(=設計)する作業は必要だろ?
それに始まり、目に見える内容(グラフ、表、印刷帳票)は全て
あらかじめデザインを決め、顧客に提示する必要があるだろ?
さらに、操作仕様の詳細も決める必要がある。 最低でも、これらの
設計を行い、設計書にまとめないと、とても技術者とは云えない。
小規模なスマホアプリのようなものなら、これで組み始めても良いが
大規模なソフトだと、サブシステム間の連携仕様(インターフェース)を
設計しないとダメだわ。
モジュール設計も必要だ。 モジュール内のルーチン設計などは
現代では不要かも知れんな。 上級PGなら、モジュール間の連携を
設計できる技量が必要だな。
あとな、設計作業には実現可能性を細かく探る意味もある。
組み始めてから、それは出来ないでは、手戻り作業が大きすぎて
プロジェクトが破綻する。
デザイン業界に居たけど、マが用意した設計書よりもデザイナーの絵のほうが役に立ってた
センスの無い文書は何であろうが罪
デザイナーが絵でどうやって、モジュール間の連携とかの
設計書を書くっていうの?
いや、設計書がなにかわかってないでしょ?
完成図(絵)は設計というよりも仕様だよ。
>>183 デザイナーが設計書を書いたとは言ってない
プログラマが書いた設計書をデザイナー(?)が見て何をしたいのかよくわからん。
普通の人がクラス構成とか、シーケンス図とか見てなにをするつもりなのか。
>>184 よくわからんけど、たとえば
車を選ぶとき、車のデザインカタログの方が役に立っていた。
エンジンやギアなど、車を作るのに必要な機械的な情報は
役に立たなかったという話?
いやそれは馬鹿な意見だろうw
俺らは車を作る側の人間なわけで。
>>185 いや、デザイナーもコードが書ける仕事環境だった
絵が描けるプログラマとでも言えばいいのか、だから普通の人ではないな
二刀流かよw
189 :
KAC:2014/04/12(土) 19:01:18.10
>>183 だから、設計書よりも仕様書の方が役に立ったって話だろ?
仕様もろくに把握せずに設計書書こうとする馬鹿が多いから
役に立たない仕様書が出来上がるってのはよくある話。
>>189 お前はさっさと設計書をかけ。
仕様はvimと同じ動きだ。
>>189 あなたが言うと説得力ありますね
はやくテキストエディタの設計書書いてきて下さい
>>187 だから、そのデザイナーが書く”絵"の方が役に立ったんだろう?
その"絵"は設計書ではないんだろう?
どんな"絵"なんだよ?w
193 :
KAC:2014/04/12(土) 19:07:09.87
>>190 vim知らん奴にもわかるように文書起こせ。基本中の基本だろ。
>>192 貼る絵、座標、線色、光源、音などを設計書に合わせて補完したもの
それらの用紙を何枚か重ねて動かす
ソフトウェアだけど仕様じゃないよ
それだけ特殊なモノを作ってただけ
ってか仕様にされたら設計書が白紙になる
もしくは作業指示書?
>>199 ソフトウェアの設計をやってないのなら、設計書が無くてもいいんじゃね?
映像を人の手で制御する何かか
ドキュメントをどう呼ぶかは業界によって違うからどうでもいいけど、
「貼る絵、座標、線色、光源、音など」についての設計をプログラマに書かせる意味がわからない。
コンサートホール設計した建築家に、コンサートのセットリスト作らせるようなものだ。
まあ、何故か知らないがデザイナーさんはマをかなり敵視してることが多いよな。
馬鹿「仕様書書いてやるから、仕様教えろ。機能だけ聞いてもわからない」
お前いらねーじゃん
205 :
KAC:2014/04/12(土) 20:28:01.24
>>204 お前は仕様書書いたこと無いのか・・・?
>>205 テキストエディタの仕様書すら書けないKACに言われても....
208 :
KAC:2014/04/12(土) 20:37:26.18
>>207 設計書書く話しかしてないだろ?
1が逃げちまったんだから待ってるだけ
私が1ですが逃げてないですよ。
仕様書はvimと一緒。何度もそう言ってるはずですが?
私が本当の1です。
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 コテ付けたり名無しになったり一人二役で忙しいのだから、見逃してやれ
ゴミだな早く消えろゴミ
213 :
仕様書無しさん:2014/04/13(日) 01:07:34.73
実装仕様を細かく考え文書化すると云うことだな。
目的は、誰か別の人に作らせる場合に、指示書として渡すためと
後で保守する場合、内容理解の助けとし、保守工数を減らさせるため。
実装は、同じ仕様内容でも、デスクトップPC/スマホ/タブレット
メインフレームなどのプラットフォームが違えば、どういうOS使って
どの言語つかって組むかなど、いろいろな方法があるよな。
「デスクトップPC/スマホ/タブレット
メインフレームなどのプラットフォームが違えば、どういうOS使って
どの言語つかって組むかなど」
これは要求仕様。言語は自由に選べるなら設計に含まれるかもしれないレベル。
他のシステムと連携する時はいるな
データベースとか、処理のタイミングとか
ネットワークの構成とか
ユーザしか使わない閉じた系のシステムなら、設計は要らないけどなぁ
設計なしで客が要求した性能をどうやって達成するの?
たとえばレスポンス1秒以内っていわれて、適当なハード買って後から何とかできるの?
LinuxやMySQLで作って、後からWin鯖とOracleじゃないと手に負えませんってなったらどうすんの?
意思疎通と契約確認の2つの意味で設計書は必要だと思うけど
全部口頭でやるってこと?
>>216 それは、設計関係なくね?
性能要件満たせるかどうかは事前にテストしてみればいいだけだし。
>>217 検証可能な程度でいいが、動くものを作らないと
テストなんて出来ないだろ。
だから、最初に作る必要がある。
コードかけないと検証は不可能
>>217 作ってからテストすんの?もしそれがNGで追加予算つかなきゃプロジェクト倒れるって事?
>>219 作ってからしか性能見積もりできません
ってどんだけ低能だよ
いや、作らないきゃ検証できんからw
検証なしに、できます!(根拠なし)って言ってんの?
>>218 必要なら検証用のテストプログラム作ればいいんじゃね?
何か問題でも?
言ってるんだろ?
言うだけなら簡単だからなw
>>222 その検証用のテストプログラムはどこで走らせるんだ?
225 :
KAC:2014/04/13(日) 16:46:09.96
>>221 普通は性能見積りは机上でやるもんだ。
どれだけの仕事量をどのくらいの早さで処理させるのか計算すりゃでるだろ。
経験が少なくてブラックボックスぎみの部分がある場合とか、
ボトルネックが大きそうな所なんかは実測することもあるけど、
それはその部分だけに集中した環境をつくって、確認・計測で十分。
見積りなんてのは、いかに素早く正確にできるかが肝なんだから
作ってからとかアホの極み。
>>221 > いや、作らないきゃ検証できんからw
それはお仕事としては低能。
「作ってみなきゃどれだけ工数かかるのかわかんないでしょ」って言ってるのと同じ。
>>224 特殊なHWが必要とかじゃ無い限り、レンタルできる環境はいくらでもある。
>>227 自社のハードウェアだとしても、無制限に借りられるわけじゃないし
テスト要員の確保だって無料じゃない
どこかの時点で設計と実測のすり合わせはするだろうし
設計の根拠として既存システムやベンチマークは利用すると思うけど
それでもシステムを開発する前に設計するんじゃないの?
それにその方法だとハードウェアの見積もりが提案できない
そして、作ってから性能を全く満たせなかった場合に対策がなくなる
ハードの増強で対策できればいいが、そもそも実現できない要求だった場合に手がなくなる
>>225 >>226 初期のプロジェクト定義の段階では
見積りに60%から160%に及ぶ誤差が生じる
ということが、ソフトウェア開発の経験
(俺の経験じゃないよ)から明らかになってる。
これは研究の結果であり事実だから
これを否定することに意味は無い。
じゃあどうするかと言ったら、短いサイクルで開発とリリースと検証を
繰り返して精度を上げるしかない。
作ってみなきゃわからないことは、作ってみなければわからない。
当たり前の事実。根性論で解決できる問題ではない。
見積もりが甘かった。
それは見積もりをオーバーすることだけではなく、
見積もりを下回った場合も「見積もりが甘い」ことになる。
見積もりをオーバーしないように、見積の数倍をふっかけるのは
仕事が出来ない証拠。責任取りたくないから自己保身でやってるだけ。
高すぎる見積もりは仕事を取られることになるのだから
見積もりは正確でなければいけない。
自称プロ根性ある奴の中には
やる気だけで、それをやるための手段(技術)が伴ってない奴がいるからな。
そういう奴は、それを実現する方法は何かあるのか?って言ったら
頑張りますとかしか言えない。
>>229 「100%なんて、無理じゃないか」は見積もり作れないやつがよく言う言い訳。
100%じゃ無くても見積もり要求されてるんだから、見積もりを出すしか無い。
いやなら、見積もり無しでゴーサインだすように客を説得すること。
>>232 ん? 客を説得できないから
根拠の無いものを提示するの?
詐欺みたいだね。
客は神さまなのだから
こちらから提案するのはなく
言われたものを作ればいいだけ。
>>233 見積もりなんかより、僕を信じてください
の方が詐欺っぽさアップじゃね?
236 :
仕様書無しさん:2014/04/14(月) 03:06:02.24
>>220 性能見積もりも、簡単に精度良く出来る場合と
雲をつかむようなケースもあり、ケースバイケースだな。
前提事項から調査しないと、ハイ直ぐ出来ますと
云う内容では無いよ。 機能保障よりはるかにハードルは
高い。
既にあるシステムの改良なら、どんな巨大で複雑なシステムでも
やりようはあるし、精度もある程度保障は可能だがな。
>>229 160%で収まるなんて、ずいぶん正確な見積もりだな。
この業界、3倍5倍は、ザラで、途中で契約放棄してバックレだって珍しくないだろうよ。
>>225 すげーな
秒間何リクエスト捌けるとか何ミリセクかかるとか具体的な数値あげて言えるわけ?
俺は客からざっくりとこう言うの大丈夫?聞かれてざっくりと試してみないとなんともですがと但し書きつけた上でそれぐらいなら大丈夫とかトントンですかねーとかしか言えんわ。
リクエストが1日50万くるけど1秒以内に返してね
ぐらいの大雑把な要求しかないよね
実際に要求を満たしているかは実機で構築するまでわかんないけど
今これぐらいのスペックで導入機がこれぐらいだから大丈夫っしょぐらいの見積もり
もちろん、DBやWEBサーバで色んなデータ計測してるけどやってみなきゃわからん
>>237 >160%で収まるなんて、ずいぶん正確な見積もりだな。
研究者のアンケートに、正直に回答するか?
241 :
仕様書無しさん:2014/04/17(木) 13:08:38.97
機械設計だって手直しができないから、やらないことが多いが
設計の不具合がでる
つまり設計で見通せる範囲なんちゅもんは全体の1/10程度と思っていい
後で、見通しができていなかったいうのは簡単だが、
見通せることが可能だ、という視点がなんであるのかわからんね
設計書書く前に、せめて要求管理くらいはしろよと思う。
>>241 設計の不具合だとわかるだけでも、設計をやる意味がある。
244 :
仕様書無しさん:2014/04/25(金) 14:37:30.41
>>1 > ユーザーサイドのやりたい事(仕様書) と
> それを実現するコードがあれば十分ではないか?
これ見るだけで、わりと簡単な仕事しかしてこなかったのでは?と思う。
Web系とかモバイルアプリの開発は、一部難しい部分もあるが、
サンプルを見ながら作れば、ほとんどが初心者でもなんとか作れる。
そして、そういう仕事なら設計書は不要だと思うだろう。
コードを直して、設計書を直している時間がもったいないと
感じるのだろう。
>>1のような意見を言う場合、どういうシステムの開発について
述べているのか書いてくれないと、どう評価していいのかわからない。
だから書いてね!
どういうシステムの開発なの?
書類がないとどのサーバにどんなバージョンのどんなアプリが入ってるかわからないじゃないか
そんなもの管理画面とかで見ないか?
特にクラウドとか使っていれば、頻繁にマシン構成や台数とかも変わるし、
書類だと同期取るの大変だろう?実機調べないとわからん状況になるぞ。
247 :
仕様書無しさん:2014/04/26(土) 00:36:24.96
>>246 > 頻繁にマシン構成や台数とかも変わるし、
ここはプログラマ板なんだよ
二度と来るなバカ
>>247 だからなんだよ?
マシン構成なんかChef使って生成してるんだから
そんなのスクリプト読めばわかるわ。
お前今どき手作業で頑張ってんのか?
開発環境と本番環境が違うなんて当たり前のように発生する中で
開発環境にあわせてチューニングしていくのはありえない
250 :
仕様書無しさん:2014/04/26(土) 02:06:35.43
>>248 プログラマがそんなに頻繁にマシン構成変えわきゃねーだろバカ!
といってるんだ!
お前がプログラマじゃなくてバカなインフラ屋だって
すぐわかるわボケナス!
変え(・∀・)わきゃ
> プログラマがそんなに頻繁にマシン構成変えわきゃねーだろバカ!
変えるだろ。テストする以上実行環境に近いものでテストしないといけない。
開発は最新環境で最新ツール使ってやりたいのに
まさか実行環境に合わせて古い開発ツール使ってんのか?
それに違うマシン構成を簡単に作れるようにしておかなきゃ
実行環境のバージョンアップとか出来ねぇだろ。
お前、新旧環境のどちらでも動くように作るとか
テストするとかしないのか?
>>250 これからの時代プログラマもインフラ触れないと話なんないよ
VPS借りて勉強しなさい
わざわざ金出してVPSなんか借りんでも・・
わざわざ金を出すというほどか?
今のVPSの価格を当てはめると、
わざわざ月500円だしてVPSなんかを借りんでも
って言ってるようなもんなんだが。
24時間つけっぱなしした時の電気代よりも
安いぐらいなんだが。
別にレンタルか自鯖かっていうのは本質じゃないよ
257 :
仕様書無しさん:2014/04/26(土) 13:22:28.91
>>252 テストするに決まってるじゃないか!
おまえの言ってるのは、少人数でやるような仕事の話ばかりなんだよ。
どのような仕事をしているから、この仕事では設計書は不要だ、
というように書かないから、たとえば銀行のシステムでも仕様書が
不必要だと主張しているようにしか見えないだろ?
そんな簡単なこともわからんの?
旧実行環境で動作するかなんてテストしないよ
ミドルウェアのバージョンも違うし動くわけがない
そんな揚げ足取りみたいな話はお腹いっぱい。もう少し建設的な話を頼む(´・_・`)
建設的な業界じゃないからそんな話はでない
>>257 前提の話だけどさ?
仕様書ってテストコードの話であってるよね?
262 :
仕様書無しさん:2014/04/26(土) 18:40:54.78
>>258 おれは旧実行環境で動作確認が必要な仕事もずいぶんとやった。
ミドルウェアのバージョンが違っても、なんとか動くようにしてくれ!
というのはときどきあったよ。
>>261 その「仕様書ってテストコードの話」という部分が理解できない
仕様書とテストコードは全く別のものだから
再び書くけど、そもそもどういう仕事を
どのぐらいやっているのかを教えてくれ。
どのような仕事を念頭において、設計書が必要ないと言っているのか
わからないと有意義な話ができない。
仕様書=テストコードじゃなかったら、
仕様にあっているかどうかどうやって
どうやってテストするの?
まさか手作業?
それコードを修正したら、全部手作業で
テストしなおしになるってことじゃない?
仕様を満たしているか機械的にわかるようにしておかなきゃ。
下流向けの仕様はテストコードでいいよな。
下流ってシステムで一番重要なところなんだよな。
その重要な所で必要とされるのがテストコード。
せめて仕様書からテストコード書けるくらいのスキルがあればいいけど。
267 :
仕様書無しさん:2014/04/26(土) 20:39:05.08
>>263 だからどういう仕事をやるとそういう発想になるのか知りたい。
だからさっさとかけ!
この馬鹿が!
意味不明なことばっかり書いてんじゃねーよクズ!
どうせ学生のアルバイトが小さなソフトちょっとつくったからって
マ板にいって、いっぱしのプログラマのふりしてやろう!
というだけのことだろうが、
どういう仕事をやってるのか書かないなら、もう聞かない。
めんどうだから 単にバカよばわりしてやるだけだから。
雑魚がうるせぇなぁ
>>268 せめてテストコード書けるようになってから参加してね。
271 :
KAC:2014/04/26(土) 21:03:06.95
>>263 そのテストコードが仕様に対して正しいかどうかって
誰がどうやって確認するの?
>>271 テストコードを検収に出して
OK貰えばいい。
273 :
KAC:2014/04/26(土) 21:11:50.23
>>272 仕様書無しで検収担当はどうやってチェックするんだ・・・
テストコード=仕様書だよ。
っていうか、仕様書があったとして
その仕様書でOKだってどうやって判断すると思ってるんだ?
わからないから、仕様書があっても
思っていたのと違うって出来てから文句言うんだろ?
設計と実装を別契約にしようぜって話ですか
277 :
KAC:2014/04/26(土) 21:26:24.94
>>274 仕様書ってのは、「仕様が正しく書かれているもの」
これはさすがに異論はないな?
今回の話題は、この「正しく」ってのをどう担保するか。って事だよな。
一般的に仕様とは、システムを要求する者が求めた事に対する答えが記載される。
この仕様書は、仕様を求めている者に対して確認を依頼することで正しさが担保される。
なので、自然言語を使って記載するのが通常。
テストコードを仕様書として扱う特殊な例があることは否定しないが、
ここでそれのみを正しいものとして主張されても困る。
そうやっていつまでも何が「正しい」で仕事してりゃいいさ
スレタイに立ち返る
279 :
KAC:2014/04/26(土) 21:42:20.74
設計書と仕様書の区別すらつかん奴って多いよな・・・
280 :
仕様書無しさん:2014/04/26(土) 21:48:45.34
設計書が書けないKACさんに言われても....
281 :
KAC:2014/04/26(土) 21:50:48.20
>>280 仕様が提示されないのにどうやって設計を書くのか・・・
282 :
仕様書無しさん:2014/04/26(土) 22:10:26.84
1本人からはvimという指定があったはずだ
もともと設計について議論していたのだから、
もしvimの仕様が不満なら自分で仕様を想定してもかまわないはず
対人コミュニケーション不全症でもないかぎり、常識で分かるだろ
283 :
仕様書無しさん:2014/04/27(日) 00:12:23.04
>>282 vimという指定?
なにそれ?
どこにも書いてないじゃないか?
本当におまえはバカだな
284 :
KAC:2014/04/27(日) 00:29:31.46
>>282 結局1が逃げて終わったなだよあのスレ。
せっかくノウハウ教えてやろうと思ったんだけど、
いい加減飽きたからもう書く気ないよ。
>>284 あはは、安心しろ。
逃げまわったのはお前だって
みんな思ってるからw
納品物として必要だからって理由で渋々作った設計書なんて糞の役に立たないよな
俺は組み込みやってて、少人数のチームの一員として1つのソフト開発をしてる
仕様追加/変更/不具合修正を分担して、それぞれで設計/実装/デバッグする感じ
設計書にまとめなくていいけど、有効な設計レビューが出来るレベルの資料は必須だわ
コードレビューでは設計通りに作れているかだけ確認したい
287 :
仕様書無しさん:2014/04/27(日) 02:38:42.46
>>284 >いい加減飽きたからもう書く気ないよ。
書く気がないのではなく書けないんだろ。
口先だけはえらそうなことを言って
いざとなると真っ先に逃げ出す奴って多いよな・・・
288 :
286:2014/04/27(日) 02:49:00.94
最近、異動した先のチームの設計レビューが形骸化してたので、意識改革中
仕様書=テストコード???
関数単位のコーダーなら成り立つのかな
担当業務と経験年数を知りたいな
>>279 どんな区別をしてるんだ?
機能仕様書(機能設計書)、画面設計書(画面仕様書)、基本設計書(基本仕様書)、
構造設計書(構造仕様書)、DB設計書(DB仕様書)、詳細設計書(詳細仕様書)
あたりは、ほぼ区別なしで、現場の用語に準拠してる。
試験仕様書だけは、試験設計書って日本語は聞いたことがない。
基本設計書(基本仕様書)、
機能仕様書(機能設計書)、画面設計書(画面仕様書)
構造設計書(構造仕様書)、DB設計書(DB仕様書)
詳細設計書(詳細仕様書)
機能仕様書(機能設計書)、画面設計書(画面仕様書)
構造設計書(構造仕様書)、DB設計書(DB仕様書)
という感じでいいよ
役立つのは実際のクラス名の表とか、画面を表示している変数名とか
遷移状態を表す命名とかさ、そういうのがまとめられているといいよ
>>290 セキュリティモジュールとか
汎用的なライブラリを作るとか
自動テスト可能な作り方をするとか
ようするに開発工数全般やバグの数や信頼性に
大きく影響する部分ははどこに含まれるの?
292 :
仕様書無しさん:2014/04/27(日) 13:54:52.31
>>291 だから、どういうクソ仕事やったら、そういうバカな質問ができるんだ?
って何度も何人も聞いてるだろバカ。
さっさとかけバカ。
さっさと答えろ。
開発工程が標準化されてないから必要なドキュメントの定義も各社、各自でてんでバラバラというw
295 :
KAC:2014/04/27(日) 14:53:43.13
>>289 仕様書っていうのは仕様を書いたもので、
設計書っていうのは設計されたものを書くものだよ。
プロジェクトによって何を仕様とするかは違うんだから、
それに合わせて呼び方が変わるのは普通の事。
>>291 他所から買ってくるようなモジュールなら、基本設計書だろう。
プロジェクト内で作成する部分の作り方は、構造設計書。
けど、構造設計書をまともに書けるヤツは、極めて少ないな。
業界30年のベテランでも、見たことすらないって人が、ほとんどだろう。
>>295 現実的には、機能仕様ですら、客先とSEで調整しながら決めるから、
機能仕様書とも機能設計書とも言える場合が多いだろう。
仕様書と設計書の区別なんて、ほとんどされてないんじゃないか。
298 :
KAC:2014/04/27(日) 15:23:48.23
>>297 客先と調整して決めたのなら、「機能仕様」だろ。
簡単な考え方としては、設計の内容変更は開発の責任でやってもいいど
仕様の変更は客との合意がいるってこと。
>>255 500円のVPSなんてウンコみたいな性能じゃん
じゃあ1000円だせば?
メリットがない
ソフトウェア設計本を一冊読んだ。だが、読む価値もないというのが感想。
業務用を例にとって、工程管理、画面設計とかユースケースとやっている。
実際、客との立会いで、先に出されていた画面から、
あたらに追加項目が出てくるということがあるわけ。
プログラミングではそうしたことに柔軟に対応できる作り方ができているといい。
プログラマにとって、そういう設計の仕方なんかに言及してあると読む価値があるわけ。
>>302 お前が読んだ、ソフトウェア設計本っていうのは
SE向けの、ようするに仕様書まとめることしか書いてない
エセ本だろうさ。
304 :
仕様書無しさん:2014/04/28(月) 13:18:28.89
>>302 ソフトウェア設計本?
そういうのはほとんどがクソ本で読んでも意味はない。
バカしか買わない本(笑)
>SE向けの、ようするに仕様書まとめることしか書いてない エセ本だろうさ。
多分、ソフトウェア設計という題名の本は、そういう世界だろうと思うよ
また構造化プログラミングという題名やつもだめだな。中身はポンチ絵を描くこと。
そうすると、構造化であるとやっている
俺はある本で、「何万行書いてもバグの出ない書き方がある」という記述を見たが、
その具体例は出ていなかった。そういうのを知りたいな
>俺はある本で、「何万行書いてもバグの出ない書き方がある」という記述を見たが、
俺は、それはありえない、と思うよ。
いやバグの出にくい書き方はあるかも、それは読みやすい書き方だな
最近こういうのを見たが笑っちゃうね。馬鹿みたいな書き方
for (q = &array[i + x + x2]; j <= nSize; j += x, p += x, q += x) {
こういう書き方がいいのよ
for (q = 0; q <= nSize; q++) {
もうKACはマ板から出ていけよ
話すこと話すこと的外れで、あらゆるスレ荒らして歩いて
staticおじさん並に自分は正しいと思ってるから手に負えない
つか質問スレ荒らすのやめてくれ>コテ
馬鹿がこんなところにもきた
もういいから隔離スレ作ってそこで騒いどけよ
「バグではなく仕様」と言えば、バグは無くなる。
バグを直すというのではなく、仕様を変更すると言え。
バグのないプログラムだよ。それが。
そんないいわけさせない為に仕様書が必要なんだよ
このスレでは、「要件定義書」という言葉を使う奴がほんと少ないな
316 :
仕様書無しさん:2014/04/28(月) 20:26:15.82
>>295 ほんとにKACは無知だな....
「仕様」を定める活動を「設計」と呼ぶ
たとえば、機能設計工程では機能仕様を定める
言い換えると、機能設計工程の成果が機能仕様になる
ここで機能仕様を記述した文書の命名について、
工程を視点にすれば機能設計書になるし、成果物を視点にすれば機能仕様書になる
国内では機能設計書という用語と機能仕様書という用語を使う現場があるけど、
両者は同義語だから現場組織内で統一されてさえいれば、どちらでもかまわない(
>>289,290)
317 :
仕様書無しさん:2014/04/28(月) 20:31:18.27
機能仕様書と機能設計書が同じとか、いかれた現場もあるんだなぁ
>>317 それをいかれたと言うのは
自分は井の中の蛙ですと言っているのと同じだと思う。
>>316-317 粘着君がまともなこと書いてるとおもったら
ただの妄想だったというオチwww
320 :
仕様書無しさん:2014/04/28(月) 20:48:20.80
だって仕事を出す側だもんよ
仕様書と設計書なんてまったく別のモンなのになぁ
視点の問題じゃなくてよ、書くべきものが違うんだよ
同じとかいかれているとしかいいようがない
321 :
仕様書無しさん:2014/04/28(月) 20:52:47.03
322 :
仕様書無しさん:2014/04/28(月) 20:55:46.96
>>321 ?
おまえんところは、機能設計書と機能仕様書、納品しないの?
自分のところで好きにドキュメント作って好きに納品して
検収あがるとでも思ってる?新入社員?
323 :
仕様書無しさん:2014/04/28(月) 21:00:48.58
>おまえんところは、機能設計書と機能仕様書、納品しないの?
しないよ。そして納品後、客先にいってデバッグ 。そんあのあたりまえ
324 :
仕様書無しさん:2014/04/28(月) 21:03:41.99
>>320 ということは、1次請けが要求定義と基本設計を担当し、
その基本設計書を仕様として2次請けの
>>320へ機能設計を発注した場合、
>>320が納品してくれるのは「機能設計書」でいいのかな?
325 :
仕様書無しさん:2014/04/28(月) 21:05:07.94
納品後に客先でデバッグ?それ検収どうなってんの?
納期遅延だと違約金がきついだろ
無能なんだな、おまえらも客も
客の担当も相当のペナルティ負ってるんだろうな
なんにせよ、今後のために仕様書と設計書は違うもの、くらいのことは
知っておいたほうがいいよ
326 :
仕様書無しさん:2014/04/28(月) 21:09:46.45
>>322 機能設計書と機能仕様書とを一緒に納品した経験は一度も無いし、
他の案件でも聞いたことが無いな
機能設計書と機能仕様書を納品するというのは、
どういう受発注の形態を指しているの?
327 :
仕様書無しさん:2014/04/28(月) 21:11:40.34
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
>>325 受発注の要求定義文書のことだけを仕様書と呼ぶ現場があり
それが世間の常識で絶対正しいと思い込んでいる蛙がいる、
くらいのことを知っておくことができた
KAC消えろよマジ気持ち悪い
334 :
仕様書無しさん:2014/04/28(月) 21:37:44.59
>>331 >・機能仕様書
>・機能設計書
これらの違いは具体的には何?
機能設計工程で常に2種類の文書を書いているんだよね
文書化作業の無駄のような気がするなあ
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
要は論破されて逃げてるだけじゃん
>>337 >機能仕様書兼設計書のことを仕様書と呼んだり設計書と呼んだりしてる
そんな当たり前のことドヤ顔で言い出すような自称上流の偉い人は、
素直に自宅警備を再開しててください。
>>325 検収なんて客の目の前で俺らがデモ操作して終わりに決まってんだろ
バグが発生する操作はしないんだよ
そもそも1ヶ月の間は無料でバグ直してやるんだから細かいこというなよ
341 :
仕様書無しさん:2014/04/28(月) 22:20:53.34
>>337 >>316で書いたように、機能の「仕様」を定める活動が「設計」だよ
設計は人間の活動を表す言葉だから成果ではないし、活動を文書化しても意味がない
>何をつくるか、と、どう作るかって全然違うだろ?そのくらいわかるよな
「何をつくるか」という中にある「何」こそが「機能」だよ
言い換えると、作ろうとしている何か(=機能)を具体化する活動が「機能設計」で
その成果が「機能仕様」であり、成果物は1つだけ
文書量に応じて分冊することはあるけど、
その場合は具体的に、たとえばUI設計書やDB設計書として命名する
そうではなく機能設計書と機能仕様書とへ曖昧に分けて呼ぶことは
単にプロジェクトへ混乱を招くだけだと考える
そして「どうつくるか」に該当するのは構造設計になる
また、いくら小規模開発であっても機能設計書と構造設計書を合体させることは、
少なくとも自分のいる/いた現場では非常識だと考えられているよ
342 :
仕様書無しさん:2014/04/28(月) 22:22:37.38
設計の成果が仕様?
一生分かり合えないなこいつとは
設計→仕様→PG
こうじゃねーの?
>設計→仕様→PG
あいまいな要件定義だけをどうにか守ったようなトンデモ仕様のものが
出来上がるのは、これが原因だな。
>>302 「デザインパターン」という定本がある。
日本語訳すると「設計規則」だな。
デザインパターンってPGレベルの話だよね?
プログラマー板だからな。
仕様を設計することと、機能を設計することは違うんだぜ。
仕様を設計することを機能設計とはいわん。
@要件定義→A外部設計→B内部設計→C詳細設計→D実装
AとBの成果が仕様
350 :
仕様書無しさん:2014/04/28(月) 22:45:45.28
仕様と設計をわかっていないやつが多いんだな
例のブランコの絵をコピペしたくなる
本当に客がほしかったものってやつ
>>344 同意。
リクエスト側が出すのが、実現して欲しい事を書いた仕様書(スペック)。
それに対して、実現方法を書いたものが設計書(デザイン)。
客===>SE===>PGが仕様書。
逆方向が設計書。
だから本来はPGも設計書を書くべきだが、
日本では、コーダーとプログラマーが混同されて来たから、設計書の書き方を教えて居ない。
もっとも現在では状況によっては、プログラムソースにアノテーションという形で設計情報を埋め込むのも可。
設計手法が確立している分野、例えば航空機産業では、仕様例=高度10,000mで巡航出来る事===>設計例=レシプロではなくジェットエンジンを使う、とかになる。
>>348 仕様は設計するものではなく定義するものじゃね?
>>337 >>341に対してレスが無いけど、
世の中には機能設計(外部仕様)と構造設計(内部仕様)との境界が曖昧な現場が存在する、
ってことでいいのかね
日本では詳細設計を書くのはPGの仕事だとされていますがどう思われますか?
ソースは?
データベースの設計だけはしっかりやった方がいい。
>>351 大抵のPGはまさにその用途で設計書書いてるよ
でこの用途だとSEに理解できるような設計書を書く必要があり
>>1の疑問になる
358 :
仕様書無しさん:2014/04/29(火) 07:36:39.99
>大抵のPGはまさにその用途で設計書書いてるよ
それは普通のプログラマにはありえんだろう。
プログラマがよそにソースコードを渡す場合、まともに設計図というのが付いてきたら
すごいよ。そんなのはまずいないだろうと思う。
よそにコードを渡さない場合というと社内システムだな。
そこはソースコードだけの世界。設計図があったとしても読まない。
普通のプログラマにはソースコードが設計みたいな思考だから。よって書かれない
設計図は、リファクタリングされ、保守ができやすいようになったところから
生まれていないと、機能を果たさないだろう
後のものが設計図から保守できるところをたぐれるようなやつだな。
後のものが、ソースコードをたぐって解析しているようでは設計図とはいわんだろ。
普通のプログラマが設計図を書けないのは、コードがスパゲッティなんで、
本人にもわからなくなっているよ
他人に読まれることを意識してコードを書けると三流プログラマからの脱出しているのだが、
そこまでいかないな
359 :
仕様書無しさん:2014/04/29(火) 08:02:52.24
俺は制御系だが、そこで目にするスパゲッティなのは盤内配線だな
そこで役立つのは、配線図というやつ。
PGに役立つ設計図というのはこういうふうに役に立つものがほしい。
ソースコードというのは変数だらけ。
で、そこをどう探っていくかを示してくれなきゃ。
それがPGに役立つ設計図といえる
変数なんて見たらわかるだろ。
361 :
仕様書無しさん:2014/04/29(火) 10:23:48.85
>変数なんて見たらわかるだろ。
だろ-、これが一般的なPGの反応。一般的なPGの立ち位置
コードというのは変数だらけな。PGにとっては、それがあたりまえという世界に住んでいる
で、ぐちゃぐちゃのコードもあたりまえ
変数が少ないコードの方が怖いわ。
変数は少ないほうが良いけど。
変数という概念が存在しない言語もあるけどね
365 :
仕様書無しさん:2014/04/29(火) 11:30:41.47
>>363 メモリ節約のためか何か知らないが、グローバル変数を複数の関数で使いまわしてる
のは見たことある。
>>366 いやいや、変数じゃなく関数で意味を表現したほうが良いってこと
369 :
仕様書無しさん:2014/04/29(火) 14:36:08.13
>いやいや、変数じゃなく関数で意味を表現したほうが良いってこと
コードというのは関数が羅列されているな
たとえばこんなんだ。
GetWoman();
GetKiss();
GetGirls();
で、こうやると関数名に意味付けがあるとかいう
しかし後から見る者にとって、そのコードはGet**だらけとしか映らないのよ
そして、ここにとどまっているかぎり三流プログラマよ
ここから、ソースコードに基づいた設計図をおこせたらプログラマの進歩だ
370 :
KAC:2014/04/29(火) 14:42:34.94
>>369 何が言いたいのかよく解らん
「どうあるべきだ」ってのが示されてないのと、
Get**だらけの何が問題だと考えているのが示されていない。
ちゃんと説明するか、正しいと思えるソース貼るか
もうちょっと意見をわかりやすく書いてくれ。
糞コテはスレタイも読めないのか
372 :
仕様書無しさん:2014/04/29(火) 15:44:46.57
>何が言いたいのかよく解らん
おまえは、ローカル変数とグローバル変数の違いがわかるか
for(int i = 0; i < 10; i++)){
int a;
a++;
}
変数のiもaも括弧の外では寿命が尽きている。こういうのが寿命が短い変数という
つまりだ、お前は投稿が369,370,371とかわると、話題の寿命が尽きていると映るのではないか
グローバル変数というのが取り上げられていたが、こういうのは寿命がながいやつな
グローバル変数のあつかいにプログラマは悩まされる。
どこでどう変わっているのを把握して行くのが面倒だから。
お前の頭は、長いコードを追いかけていると、プッチンと途切れてしまうから、
グローバル変数みたいなのは使わないほうがいいな。
373 :
KAC:2014/04/29(火) 15:52:08.29
>>372 名前か何か書かないことには前の発言とのリンクなんて取れんだろ。
名無しで書くなら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
要は論破されて逃げてるだけじゃん
>>373 >名無しで書くなら1レスの中に情報詰めろ。
2chは名無しが基本だよ
相手が名無しだからという理由でコミュニケーションができないなら、
2chに向いていないってことだ
あと、板違いスレ違いの話をいつまで続ける気だ?
いいかげんにしろ
また粘着登場か。死ねばいいのに
>>376 なんでいちいちコテ外すの?
本すれと同じタイミングで同じことして、バカなの?死ぬの?
378 :
仕様書無しさん:2014/04/29(火) 19:42:34.08
また粘着認定登場か。いちち書かなきゃいいのに。
>>369が何を言いたいのかは分からん。
色んな関数内で同じグローバル変数使うなってこと?
ごまかそうとしてアラシてんだからさわっちゃだめ
>>336を繰り返す
>>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レベル2以下の場所は
どこもこんなもんだよ。
CMMIレベル3以上とか絶対うそやで。
そんなもん存在しないよ。
存在してたら日本はもっとソフトが強いはず。
CMMIの基準ってもっと評価されるべきだよな。
393 :
仕様書無しさん:2014/05/01(木) 00:46:18.42
>>389 したかなく書くドキュメントも確かにある。
でも、必要なドキュメントもありますよ。
ドキュメントは、作成した分だけ確実に開発速度が落ちるよ。
ある程度以上の精度を求めると、メンテナンス含めてプログラムと同等かそれ以上のコストがかかってしまう。
だから、お役所系の大規模PJを受ける企業だと、ドキュメント周りだけの仕事があったりするくらい。(閑職だったけど。)
組織や発注がアレだと、設計書のC/Pとか考えること無いんだろうな。
で、アリバイのために作って捨てる設計書が量産されると。
本来は、許される属人性の範囲や開発速度をトレードオフして、必要な分だけ作るべきだと思う。
俺は頭の整理のために、要件や会議の記録をもとに
仕様書を書いて、それを元にプログラムを書くよ。
その仕様書はレビューしない。
しても無駄。誰もちゃんと読まないから。
レビュワーにはパワポ10枚くらいで適当に説明して
会議をやった記録だけは残しておく。
ちな大手電機
制御系、盤内配線なんかスパゲッティじょうたい。でも配線図があれば
すぐ探れる。
同じ制御系の話だが、PCLの制御をすこしかえるとき、
開発者だったらすぐに直せるのに、ほかの人にやらせると一周間とかかる
といっていた。スパゲッティでも配線図があればすぐわかるのに。
ソースコードを解き明かす、ほかの人でもすぐにわかるように
という設計図がないから。
そこでは、ソースコードが設計図な。
プログラミングできるだけでは、三流ということ。
設計図をつくれたら、三流プログラマからぬけだしているよ
>ある程度以上の精度を求めると、メンテナンス含めてプログラムと同等かそれ以上のコストがかかってしまう。
三流プログラマにはわからないかもしれないが、
プログラミングというのはソースコードを生産して
しかし、これを捨てるという作業を行う。
ロジックの変更があったりすると、必要でなくなるルーチンがでたりする
最初に考えたロジックより、中途で変更するということは、合理性のためだ
そういうのをペーパに残しとくのよ。
ソースコードが汚くていいとは思わないよ。
ネストは浅くして
コマンド毎の応答処理への分岐部分なんかは
馬鹿でもわかるように
スイッチケース文で箇条書きにする。
人間は時系列で物事を考えるのが一番得意だから
それに合わせて書いてやるのが一番良い。
割り込みやマルチスレッドは必要な場合に使うべき。
>ネストは浅くして コマンド毎の応答処理への分岐部分なんかは
>馬鹿でもわかるように スイッチケース文で箇条書きにする。
そから先があるわけ、設計書を作る作業だな。
画面描画のソースコードがひとかたまり、
ファイル処理のコードがひとかたまり。
そうなっていないと設計図をおこせない
ファイル処理があっちにあり、こっちにあるというのがいけない
>>394 それは、正しいドキュメントを見たことがないんだよ。
適切なドキュメントを作成しながら作業を進めれば、開発工数は、半分にも1/3にもなる。
デスマの多くは、上流担当者のドキュメント作成能力の欠如に起因してる。
まあ、しかし実際に書けるやつが全然いないんで、
もうドキュメントに期待しない開発方法の方が主流になってきてるがな。
>>400 >まあ、しかし実際に書けるやつが全然いないんで、
全然いないわけじゃなくて、いるにはいるけど
必要とされる技術レベルの人材の絶対数が
ぜんぜん足りていないんだと思う
>>400 その工数削減に役立つドキュメントの例を教えてくれ。
どういう場合にあると無いとで工数が半分になったりするのか。
過剰なドキュメントは足がかりじゃなく足枷になるな。
ソースコード以外のドキュメントは補足に過ぎない事を念頭に書くべき。
あと設計者はモジュールのインターフェースとテストコードぐらいは書くべき。
それらは活きた仕様書になる。
なるかよ
405 :
394:2014/05/02(金) 02:24:27.14
>>397 顧客との間に証跡として残すドキュメントなら同意。
内部のコミュニケーションのためというならお前の方が三流だ。
ある程度以上の精度でドキュメント起こすなんて、実質自然言語とプログラム言語の両方で設計するようなもの。
理想像に近づくまでスクラップ&ビルドする間、設計書分のオーバーヘッドが乗っかるんだぞ?
関係者の合意形成が済んでるなら、完全に無駄コストじゃねえか。
例外は、実装コストが高すぎる場合と、ビジネスロジックが密で複雑になる場合くらい。
そうでなければ、設計書作る工数でテスト書くべき。
第一、どうやってソースと設計書を同期取るんだよ。
余程工数があって温い環境なんだろうな。
>>400 正しいドキュメントって何?
設計書が無くて困る場合って、大体は人間同士(顧客や開発者、運用担当者)の摺りあわせ不足だろ。
極端な話、関係者全員に必要な情報が行き渡り、滞りなく合意形成と記録が行われているならドキュメントなんて無くてもシステムは作れるし、運用も回るんじゃないか?
設計書の効力って、正直技術的妥当性よりも政治的な部分が大きいと思うんだ。
逆に言えば、設計書が無ければいちいち人間同士の摺り合わせから行わないといけないということ
摺り合わせた結果を設計書として残しておけば、設計書に従って作業ができるのに。
設計書と一言でいうがどのレベルを指しているのか、システムの規模はどの程度なのか。
これを明確にしないで話しても意味ないと思うんだが…
>>407 規模によって変わる物って、具体的には?
>理想像に近づくまでスクラップ&ビルドする間、設計書分のオーバーヘッドが乗っかるんだぞ?
理想像というのを、設計図を起こせるよな、というところに置いておくといいよ
動きゃいい、というところにとどまっていると三流プログラマ
俺は二時間で書き上げたぞ、と自己満足しているやつも、そう。
410 :
仕様書無しさん:2014/05/02(金) 11:52:52.06
社内向けには、引継ぎ用の詳細仕様書(手書きでもいい、客に見せない)
そして偉い人用のかいつまんで説明したパワポ
客用には外見の動作を記述した納入仕様書
納品用と設計用を一緒にしようとおもったこともあるが
無駄であっても2つは分離したほうがいい。
設計用に書いたドキュメントを、
ある程度設計が固まった時点で納品用に分岐させて詳細部分を消してる。
>>409 どういう形にするかはポンチ絵レベルでも普通書くだろ。
荒く書くところ詳細に書くところ緩急つけてコードと絵をラウンドトリップしながらブラッシュアップするだけ。
設計を念頭できないPG
>第一、どうやってソースと設計書を同期取るんだよ。
>余程工数があって温い環境なんだろうな。
設計ということを念頭におけれるPG
>どういう形にするかはポンチ絵レベルでも普通書くだろ。
>荒く書くところ詳細に書くところ緩急つけてコードと絵をラウンドトリップしながらブラッシュアップするだけ。
複数人で開発する場合のことを考えてみろ。
全く設計書が存在しない場合、コミュニケーションコストは増大し、現場はカオスになることは目に見えている。
そこに、ちょっとした設計情報(整ったドキュメント出なくともよい)が投入されれば、その合意情報分の
コミュニケーションコストは減り、誤ったコードも少し減り、誤ったテストも少し減るだろう。
もう少しましな設計情報が投入されれば、もう少し開発全体のコストが下がる。
ただし、投入する設計情報を増やせば増やすほど、開発全体のコストが下がるかというとそうではなく、
どこかの時点で再びコストが増大し始める。
この境目あたりのまでの分量の設計情報であれば有用。
>>413 設計書にコード実装例が書いていなければ
どっちみちカオスになるよ。
少なくとも、CRUDを備えた機能
一式の(無駄のない)コードが必要。
これがなければ、てんでバラバラのコードになるし
同じ機能をそれぞれが作っちゃうから
誤ったコードもテストも大きく増えてしまう。
>>408 俺は
>>407ではないが、例えば一日以内にで誰でも作れて
それでいて客の業務に深い影響がなく、金を取れる受注。
こんなの特にインタプリタなら設計書作る方がバカレベルだと思うね。
俺なら絶対ソースのバックアップ以外残さない。
>>414 > 設計書にコード実装例が書いていなければ
> どっちみちカオスになるよ。
設計書にコード実装例なんかいるかよ
それっていわゆる詳細設計書か?
そんなの一切不要
>>414 > 設計書にコード実装例が書いていなければ
利用されるコードを書く人の場合?
I/Fだけで足りないなら、テストコードかHogeDocの出力でいいんじゃないの?
っていうか、そのレベルの設計書が無いと
> これがなければ、てんでバラバラのコードになるし
> 同じ機能をそれぞれが作っちゃうから
みたいになるって、レベル低すぎじゃないの?
>>414 なんでだよ。入出力を定義してあるのだから
それに従えよ。
>>414 共通化しろよ。テンプレートメソッドでもいいし。
ははw やっぱこのレベルだ。
たかが設計書どまりで
コードの質が安定すると思ってやがる。
そんなので安定してたら
人によって10倍以上も差がつくかよ。
>>421 設計書がなければ、人によって100倍以上差がつくんだけどな
>>422 差が付く要因は何?
俺は実装者の力量や、関係者間のコミュニケーションの不足だと思う。
これらは設計書書くことでもある程度対処できるが、効率が悪すぎるんだよ。
設計書なんて、合意形成の証跡だけ残せば要らないことが多い。
設計意図なんて、ソースのコメントやテストとして残すべきだろう。
一覧性が無いなら、社内wiki辺りに全体像だけ書けばいい。
自社開発かつ性善説で仕組みを作れる組織に限るだろうけど、どうしてそこまで設計書を求めるのか解らない。
>>423 > 設計意図なんて、ソースのコメントやテストとして残すべきだろう。
詳細レベルの設計意図なんか必要ねーんだよ
>>423 設計情報の可視化と共有が必要だと思ってるんでしょ?
だとしたら、そのアウトプットが「設計書」であっても問題ないと思うけど、なんでそんなに毛嫌いするの?
>>425 コストが高すぎるから。
初期コストはそうでもないが、もろもろのメンテナンスコストが膨大すぎる。
メンテナンスしないなら、作らないほうがまだマシだし。
設計書書くしかないなら仕方ないけど、他の方法で目的が満たせるなら作らずに済ませたいよ。
>>426 コードやコメントの方が早いところとポンチ絵とかのが早いところがあるだろ。
なんで使い分けしないの?バカ?
>設計書書くしかないなら仕方ないけど、他の方法で目的が満たせるなら作らずに済ませたいよ。
書くしかないって。でもってコードの書き直し。
ソースコードの構造を変える。
画面の描画をひとまとめにするとか。
描画ルーチンだけがタイマーで回っているとうように
ほかのクラスは表示変数をかえているだけ。
リアルタイムに表示をしない、ということ。
>>427 で、そのポンチ絵はメンテナンスするのか?
周囲の状況が変わる度に、経年劣化するだろろ?
問題は、伝える道具の種類よりも、その維持にかかるコストなんだよ。
説明の都度ポンチ絵書くような状況を、設計書が存在するって言えるか?
>>428 テストコード+CIじゃだめなのか?
>>429 名前にレス番くらい入れろ
誰が誰かわからん
ああ、IDないんだっけここ。
詳細設計書が無いと、テストの適合性が客観的にわからんと思うのだが。
設計書不要って人はテスト仕様書を別に作ってるとか?
>>429 必要ならメンテすればいいだけ。
お前も必要だからコメントをメンテしてるんだろ?
コードとの距離がコメントより遠くなるからメンテされなくなる可能性が高くなるのはわかるが。
折角だから聞いとくわ。
・お前にとって文章やコードで書くよりも図で描いた方がわかりやすいことは一つもないのか?
・あるのならどうするんだ?エクセル方眼紙並みにコメント使って絵を描くのか?
それがしやすいツールあるならコードとの距離も近くなっていいから教えてくれ。
434 :
429:2014/05/02(金) 21:01:21.15
>>432 作ってる。むしろ設計書よりそっちのほうが重要。
自動テストで対応できるなら、その方が良いけどな。
>>433 > ・お前にとって文章やコードで書くよりも図で描いた方がわかりやすいことは一つもないのか?
ある。
> ・あるのならどうするんだ?エクセル方眼紙並みにコメント使って絵を描くのか?
ホワイトボードに書く。で、その場で説明して終わり。
メンテすればいいと簡単に言うが、コスト対効果を考えてみろよ。
ソフトに改修入る時の影響度調査は?機械的に調査できないんだから、かなりの範囲を確認することになるんだぜ?
大幅改修が入ったときの維持ポリシーは?現状維持とか言われたら、同程度の複雑さの設計、全部図に起こすことになるんだぜ?
余程工数があったり、関係者が多いところなら別かもしれないが、掛けたコストをペイしないだろう。
>それがしやすいツールあるならコードとの距離も近くなっていいから教えてくれ。
残念ながら、実用に耐えるものは知らない。
プログラム言語とそれ以外の表現方法との差が埋まらないから、結局何処かに無駄なコミュニケーションコストが発生する。
コードを書く前に設計レビューしたほうが、結果的に戻り作業が少ない
設計レビューするには、設計意図を伝える最低限の資料が必要
チームで開発してたらそうあるべき
自動生成レベルの納品物としての設計書しか知らない奴は可哀想
あれはマジで意味ないからな
>>434 >ソフトに改修入る時の影響度調査は?機械的に調査できないんだから、かなりの範囲を確認することになるんだぜ?
>大幅改修が入ったときの維持ポリシーは?現状維持とか言われたら、同程度の複雑さの設計、全部図に起こすことになるんだぜ?
何で全体の構造わかるようなポンチ絵かけばいいってんのに、影響範囲とか全部図に起こすとかなんのよ。
改修入るなら新しい構造のポンチ絵描くだけ。そこにざっくり前とどう違うか何で変えるかなどの補足情報があればなをよし。
何をどう捉えてるのか知らんがお前が全ての情報をコンパイルできるソースコードとテストコードに落としてるなら分かるがコメントやWIKIにかいてる時点で論理なりたたんだろ。それらも話し同様だろ。
末端作業員しかいないなw設計書ってのは自分を守るためのもんだよ。
438 :
KAC:2014/05/02(金) 22:12:49.39
>>437 「設計書ってのは自分を守るためのもん」は、
末端作業員くらいしか言わない台詞だぞ。
自分を守るとかそういう本来の目的から外れた事を考えたくないから
サラリーマンになりたくないんだよ
440 :
KAC:2014/05/02(金) 22:19:15.65
>>434 設計をちゃんとやって、結果を残さないのはもったいないぞ。
ホワイトボードに書いて説明したとしても、正しく伝わっている保証はない。
伝えた相手に設計書を書かせてレビューすると伝わりきってないことに気がつくぞ。
メンテナンスや類似開発のときに参照もできるから、残す方がトータルコストは安くなる。
メンテナンスに工数がかかるというのは、後で設計が変更されるということだよな。
それは設計バグであり、設計段階で取り去るべき問題が出てるだけ。
対応としては設計書を諦めるんじゃなくて、設計書を書く段階でバグを取り去る努力をすべき。
結果として後工程でのバグが減って、トータルコストは下がる。
>>423 お前も気づいているだろうが、設計書なしのプロジェクトなんて
・システムについて熟知しているメンテナーが常に存在する
・新しく入ったメンバーがシステムを学ぶ間の
コミュニケーションコストは考慮しなくてよい
などの条件が揃った稀なケースでしか成立しないんだよ。
>>440 「メンテナンスや類似開発のときに参照もできる」ように作成・管理するのはかなりコストがかかるだろう。一つのプロジェクトに押し込めないくらいの。
結果、ただの雛形になったりコピペで済ましちゃったりが現れる弊害があると思うんだが、KAC界隈ではその辺の環境が整備されているということか?
444 :
KAC:2014/05/03(土) 00:54:38.34
>>443 なにか変な事考えてないか?
必要なものを必要なだけ作ったものを記録に残すだけだぞ?
なんで余分なコストの話が出てくる?
>>444 自分の為だけってわけじゃないだろ?
自分が必要な資料は自分にわかるように残すけれど、
開発システムとして再利用を考えるのはかなり大変な作業だと思うんだが。
>>423 > どうしてそこまで設計書を求めるのか解らない。
ソースコードから切り離して設計について議論するため。
プログラム語るときに、ソースコードが無いと語れないというのは3流。
447 :
KAC:2014/05/03(土) 01:15:28.03
>>445 統一された書式で必要事項書いていけば、
再利用できるようなものは勝手に出来上がるよ。
各自でメモ程度に残している感じなんだったら、
設計書としての統一書式を導入する事をおすすめする。
448 :
445:2014/05/03(土) 01:16:40.06
補足すると、再利用の為のコストが決して余計だとは思わないし、
記録を残すことは重要なのは理解している。
ただ、その思想がきちんと引き継がれないと意味がないし、
ここいらでは結果的に前ドキュメントのコピペで済まされて肝心な情報がなにもない記録が溢れてしまっている。
「必要なものを必要なだけ作ったものを記録」する環境が整っていないのさ。
で、KAC界隈ではどうやってるんだろうかと伺っている。
>>429 ポンチ絵のメンテナンスにコストがかかるのは、
ポンチ絵書くのが下手な可能性が高い。
ポンチ絵に必要以上に実装に関わる情報を記載してしまうと、
実装が少し変わるだけで剥離が起きてしまって「つかえねー」と判断される。
450 :
445:2014/05/03(土) 01:22:31.57
>>447 ごめ、前後したな。
「統一された書式」ってのがきちんとしてるんだね。
ここいらで統一された書式っていうと、Excel方眼の納品物で、
いつから使ってるのかわからない上に必要な情報がまるでないものに
なってしまっててさ。
で、「統一された書式」にコストがかかるだろうに、って思った。
451 :
KAC:2014/05/03(土) 01:22:50.46
>>446 いや、設計は当然やるしソース以外でも話はできると思う。
名前つけてないから憶測になるが、434と同一人物だと思う。(違ったらごめん)
ただ
>>423は、それを設計書として残すコストがかかりすぎて
それを使うメリットよりもコストが悪化する要因になるって意見を述べている。
いまは「そんなにかからんだろ」って話に、「いやいやかかるだろ」って状態だから、
>>446の意見はちょっと外してる。
452 :
KAC:2014/05/03(土) 01:45:10.37
>>450 確かに書式がなくて各自が好き勝手に書いてたら
メンテナンスとか再利用とかは難しいと思う。
まあ、敢えてそういう方針でメンテナンス性よりも
出荷速度なんかを優先するのもアリだとは思う。
その場合は、設計書なんて作ってられるかと言ってもいいとは思う。
けど、やっぱり一般的な話としては
「設計書はちゃんと作った方が良い」と言いたいところ。
書けないのに
言いたいんだ
454 :
仕様書無しさん:2014/05/03(土) 07:37:52.28
>ソフトに改修入る時の影響度調査は?機械的に調査できないんだから、かなりの範囲を確認することになるんだぜ?
大幅改修が入ったときの維持ポリシーは?現状維持とか言われたら、同程度の複雑さの設計、全部図に起こすことになるんだぜ?
客先にシステムを導入できたとしよう。一年後にまた注文が来る
するとだな、追加の仕様とか変更とかある。でバージョンアップしていく
作り手のほうも、一回目より、二回目のほうがうまくできる。
一回目はトライアルなのが、二回目は洗練されているとおもうのではないか
ソフトに限らず、機械設計でもそういう。
そういうときがソースコードの改変のチャンス。
また受注がくる、というのが続く、そうするとき、視点が変わってくる、保守しやすい作り方というように
じじいになったお前でなく、後輩がひきつげれるようにとな
>補足すると、再利用の為のコストが決して余計だとは思わないし、 記録を残すことは重要なのは理解している。
ただ、その思想がきちんと引き継がれないと意味がないし、
おれは自分で書いたソースコードを一年後に読めない自信がある
どういう処理だったろうかーと思うだろう
ソースコードを見ながら、
Case文でbreak;を書き落としているとき
バグかもしれないとつぶやく
やがて、それはわざと落としていたことに気づく
無駄な設計書は無駄<==単なるトートロジー。
設計書無しだぜ!<==アノテーションすら無いなら、toyレベルなので設計情報は不要。
自明だな。
>>452 >
>>450 >確かに書式がなくて各自が好き勝手に書いてたら
>メンテナンスとか再利用とかは難しい
(中略)
>出荷速度なんかを優先するのもアリだとは思う。
両立させる為のルールには、例えばSysMLなどが有る。
あと、小規模PGでは設計情報無しで凌げても、大規模になると破綻する。
趣味のレベルを脱したいなら、小規模の案件の時からセルフトレーニング。
458 :
434:2014/05/03(土) 09:19:01.67
>>454 で、その後輩は古びた設計書と変わり果てた姿のシステムを目にした上で、調査に明け暮れる訳だな。
当然、納期は設計書を前提にひかれたまま。
何度も言うが、メンテナンスされてないドキュメントなら無い方がマシ。
お前は、実態とはまるで別物となった設計書を引き継いで一から作り直したことはないのか?
設計書肯定の意見って、実装前に設計を見える化したいからって理由ばかりだよな。
リリースしたら終わりで、運用やったこと無い奴しか居ないのか?
実装開始時やリリース前に設計書の更新止まるなら、ホワイトボードに書くのとあまり差が無いだろ。
ここ見てる奴らに是非聞きたい。
お前らの組織では、リリース時orリリース後に設計書を実態に合わ続ける作業を誰がやってるんだ?
>で、その後輩は古びた設計書と変わり果てた姿のシステムを目にした上で、調査に明け暮れる訳だな。
後輩は古びた黄色く変色した紙にあるブロック図と
今はもはもう廃盤になったNEC98のI/Oインターフェースと
VBのソースがあるわけだな
そいうのは一から作り直したほうがいいな。NEC98を保守できる人が今もっているよ
その人がいなくなったらどうするんだろうな、とおもう
そのよこで、これはいただきとWindows7のを作って収める
あいてもなかなかのもので俺のをコピーする。
俺のを勝手にコピーするな! とやっているのだが
>>458 だからお前のところで文書メンテの工数設けてないだけじゃん。
ソースを見れば分かる様なもの、テストの方がチェックしやすいものはそっちでやって、ソースやコメントに書きにくいものをラフに描いたりしておけば良いだけ。
なんでその加減が分からんのかマジで分からん。
>>460 >だからお前のところで文書メンテの工数設けてないだけじゃん。
文書メンテに工数を割いてくれる場所がこの世に存在するってことだな。
ちょっと希望が持てたよ。
>>461 メンテして効果があると思うなら、そのことに工数かけない意味がわからん。
斧とがないでこの斧きれねーよとか言ってる会社なのか、そこは?
463 :
461:2014/05/03(土) 11:34:02.09
斧の切れ味に興味がある会社なんて、業務系では上から下までで見たことない。
工数割いてくれるのは自社開発限定なのか?
自社でも派遣先でも文書メンテの工数あったよ
というか大手メーカーだと文書メンテ専門部隊いたよ
噂に聞いてた仕様スペシャリストもいたし
やっぱ大手はすげーな
>やっぱ大手はすげーな
文書の中を見てごらん、すごくないから。昔ながらのしきたりと
ソースコードも書かずに小さくなった脳みそのSEの作文
俺の根拠は「ソフトウェア設計」というたぐいの書籍にある。
ここでとりあげられたが、アホが読むものといわれていた
そんなレベルということね
一番馬鹿なのが、何度も設計をしなおすやつ。
プログラマに指摘されるのはもう最悪。
一回で設計をきちんと書け。
>>464 仕様スペシャリストってなに?
仕様くらい全員把握してないとものは作れないだろ。
>>458 > 何度も言うが、メンテナンスされてないドキュメントなら無い方がマシ。
無いよりはあった方がマシ。
バージョン違いの設計書しかなくても、
どんな思想で作られてるか・大まかなモジュール構造がどうなってるか
を理解してるだけで作業効率が全然違う。
> お前は、実態とはまるで別物となった設計書を引き継いで一から作り直したことはないのか?
おまえは、設計書が全くないコードを引き継いで一から設計起こしたこと無いだろ。
>>467 キングファイル数百冊を全員把握してろと? 全部を把握するのが無理だし
無駄が多いから分業するようになっているわけで。 問題は全体や他所との
つなぎ部分を把握しなければならないのまで細部しか見てないことだよな。
>>469 仕様が数百冊に及ぶシステムって例えば何だ?
設計書合わせたらそのくらい行くのは思いつくけど
仕様だけでそんなにいくのはちょっと信じられん
分が悪くなると極論に逃げるのは基地外の基本。
金融系や何十年も続いてるのだと普通にあるぞ。ピーク時に100人月超えるような
プロジェクトなんかだと数百は言い過ぎでも数十〜百数十位になるし。
納品の時に実際に印刷して呆れた記憶があるよ。
>>472 仕様書と設計書の区別ついてないだろ。
100人月超えくらいでそんなに仕様書は膨れ上がらん。
今更だけど設計書と仕様書って何が違うの?
475 :
KAC:2014/05/03(土) 15:29:15.59
>>458 > メンテナンスされてないドキュメントなら無い方がマシ。
↑たとえメンテナンスされていなくても、あったほうがいいぞ。
設計書ってのは、設計担当者が何をしたかったのかが書かれている物だ。
ソースから意図を汲み取るよりも、そういう資料があった方が背景を理解しやすい。
メンテナンスについての情報だったり、そもそもの考え方がおかしかったり、
そのプロジェクトにどう関わっていくべきかの大きな手がかりであり、証拠資料なんだから。
476 :
KAC:2014/05/03(土) 15:35:07.59
>>474 仕様書ってのは、仕様を書いた書類。
設計書ってのは、設計された内容を書いた書類。
大雑把に言えば、
仕様は対外的に決まっている内容。
設計は自分達で自由に設定できる内容。
厶板のお題スレでいえば、
問題は仕様
各自で考えた実現方法は設計
提出された回答が実装
こんな感じと思ってれば大まかには大丈夫。
仕様を書いたのが仕様書
設計を書いたのが設計書
>>463 文書を作成すると、その分、トータル工数が増えるような文書じゃ、作成してる意味がないだろう。
メンテ含めたトータル工数を少なくするために、文書を作成する。
継続的にメンテが必要なシステムなら、担当者が変わったり、
初版開発関係者が何人かいなくなってたりするから、
文書作成による工数削減効果はより大きくなる。
479 :
仕様書無しさん:2014/05/03(土) 19:04:37.66
>今更だけど設計書と仕様書って何が違うの?
マックの店員がマニュアル通りに動けば繁盛する。
それと同じ考えで、ソフト開発にPGに対してマニュアル通りにコーデングすること
それがPGの役目だと。そういうのではプロジェクトの破綻がおきる
ソフト開発は創造の世界だということなわけよ。
多分ソフト開発というのは、できる人に支えられている。それを属人的というが、
そういう世界だろう。
組織というのは、その人がいなくなっても代わりに誰かが役目をはたす
しかしソフトは開発者がいなくなれば、またゼロから作り直し、そういうことがおきる。
>>468 > おまえは、設計書が全くないコードを引き継いで一から設計起こしたこと無いだろ。
あるよ。
信頼できない設計書が存在する場合より、調査の工数もらえるだけマシ。
>>475 他の担当者や会社が手を入れていて、それが設計書に反映されてないパターンを体験したこと無い?
最初のリリース直後ならまだしも、寿命長いものなら思想やモジュール構造すら参考にならない事は多い。
そのほかにも政治的な理由で設計が無視されたり、運用でカバーされて全く異なるユースケースに対応してたり、
設計書が使い物にならないケースはいくらでも見たことがある。
メンテナンスされてなきゃ害悪なんだよ。
ドキュメントのメンテナンスって、担当者だけが頑張ったって仕方ないんだよな。
まともにメンテナンスするなら、ドキュメントの運用ルールを関係者に徹底して、かつ誰かしら必要な知識を持った人間をシステム廃止まで張り付け続けないといけない。
こんなの、一部の金も人もあるプロジェクトしか無理。
>>479 属人資産レベルの開発現場をCMMIレベル1〜2とよぶ
>>476 テンプレに載せたいレベルの素晴らしいレスだと思う。
483 :
仕様書無しさん:2014/05/03(土) 20:08:06.43
>属人資産レベルの開発現場をCMMIレベル1〜2とよぶ
Vistaの失敗は2000人規模の多きさにあったといわれる。
規模の大きさでだめになったというわけ。
多分ソフト開発というのは、属人の世界からぬけていないよ
あほが上に立つとだめになるというパターン。
ソフト開発ばかかりでなく民主党の例なんかそうだね。
糞コテを褒めると調子に乗るぞ
>>480 もうお前と
>>468,475は相入れないから好きにすればいいんじゃないの?
俺も全体の概略がつかめるポンチ絵なり概要の資料はないよりはあった方がいい派。
メンテされてないならないでその旨が付記されてればいいだけ。
よっぽどよく整理されたソースだとしてもソースから仕様を把握するとか無駄なことこの上ない。
>>480 > 信頼できない設計書が存在する場合より、調査の工数もらえるだけマシ。
なんで後付けで調査の工数もらえるとか勝手な条件付けてるんだよw
>>480 > 他の担当者や会社が手を入れていて、それが設計書に反映されてないパターンを体験したこと無い?
ソースコードからじゃ設計わかんなかったから(解析してる時間無かったし)、
とりあえず仕様を満たせばいいやと適当に手を入れたことならある。
>>487 > こんなの、一部の金も人もあるプロジェクトしか無理。
担当者に毎回ソースコードから設計起こさせる無駄な工数割くなんて、
一部の金も人もあるプロジェクトしか無理。
>>480 > そのほかにも政治的な理由で設計が無視されたり、運用でカバーされて全く異なるユースケースに対応してたり、
設計書書かなければそのような事態は回避できると。
>>480 ドキュメントは完璧にメンテナンスされないとダメだと考えているようだが、
どうせ完璧にメンテナンスされないからドキュメント作らないというプロジェクトのほうがダメ。
それに、適切な方法を選べば実際の設計に合わせてドキュメントを改版していくのに
そんなに手間はかからない。
役に立つ設計書しか見たこと無い人と役に立たない設計書しか見たこと無い人で話が噛み合うわけがない
両方見たことある人がうまく説明して欲しい
>>485 メンテされてない旨を誰が残すんだよw
>>486 そりゃ、付くだろ。客観的に考えたら必要なんだから。
ドキュメントのメンテ具合次第では、ドキュメントの裏取りだけで調査より時間食うけどな。
>>488 メンテナンスされていないドキュメントでも、残っていれば解決するのか?
>>487のように、その場しのぎの対処にならざる得ないのが現実じゃね。
その場しのぎが積み重なった先はどうなるか想像してみようよ。
>>489 無理。
その設計書が最新化されていないなら調査するしかない。
そもそも設計者自身が認識し得ないケースも多い。(リリース後にシステムを離れてしまう場合とか。)
>>490 > そんなに手間はかからない。
具体的に書いてよ。きっと、工数に余裕があるプロジェクトなんだろうね。
>>458 俺は簡易なものでも設計資料を作ってレビューしろよ派
今の業務は組み込み、C++、VxWorks
いろんな業務を経験すれば、設計資料を作る重要性に気付くさ
>>475 >そもそもの考え方がおかしかったり、
設計書にいいイメージ持てない理由がわかった
例外なくこれの証拠資料だからだ
じゃぁ設計書を書かないことが解決になるのか?
どうせ役に立たない(と自分は思う)から設計書書きませんって
ただ面倒だから設計書書きたくない言い訳でしかないだろ。
>>492 > メンテナンスされていないドキュメントでも、残っていれば解決するのか?
0か0.1かで言えば、0.1の方が良い。
>>492 > そりゃ、付くだろ。客観的に考えたら必要なんだから。
へー。設計書残しておけばそんな工数掛けなくてすんだのに。
お金と時間がたくさんあるんだね。
> ドキュメントのメンテ具合次第では、ドキュメントの裏取りだけで調査より時間食うけどな。
どう考えても、裏取りができるのと裏取りすらできずにゼロから解析するのでは
裏取り工数 <= ゼロからの解析
だけどな。
他人のドキュメントなんかメンテしたくないです。
自分たちでゼロから作りたいですっていう気持ちはわかるが、それは甘え。
>>492 you転職しちゃいなよ
職場環境が悪い
何年やってるかしらんが経験が足りんよ
今後独立して独り開発だけでやってくなら脳内設計でもいいけど
>>492 > そりゃ、付くだろ。客観的に考えたら必要なんだから。
客の観点から考えたら
・以前の担当者が使ってたもの(ソースコード)はある
・ちょっと変更加えるだけ
なのに、調査費用が必要ですはありえない。
以前の担当者は調査なんかしなかったのに。
>>498 いや、
>>492 みたいな考え方の人が、
部長やPMみたいなポジションにいるプロジェクトがたくさんある。
ドキュメントの有用性を強硬に主張すると、退場になることの方が多いんじゃないか。
おそらく、ドキュメントが役に立ったためしが一度もないから、
ドキュメントを作成するとトータル工数が、激減するというのが理解できない。
502 :
仕様書無しさん:2014/05/04(日) 00:28:47.04
ドキュメントを役に立てるには
猿よりちょっと利ロである
必要があるからね。
モンキー集めてモノづくりする日本の企業にはドキュメントなんて不要だよね
>>495 金融も昔やってた。
耐用年数の長いシステムをやってた事が多かったな。
>>497 お前は、本当に酷いドキュメントを見たことが無いんだな。
インターフェースはおろか、考え方すら全く実態と合わないドキュメントで仕事させられたことは無いのか?
全く収穫がなかったら、その調査コストをドブに捨てたのと一緒なんだぞ。
>>499 契約が不適切じゃね?それ。
ソースごと納めてるんなら、設計情報の維持も当然客の責任。
運用メンバへの引継ぎを契約上で明記したり、規模によっては開発会社から人身御供納めたりするのが普通。
サービス提供なら、運用費用確保して判る人間を抑え続ける感じ。
つーか、お前らは何でそんなにドキュメントを信用できるんだよ。
考え方を読み取れるとかそういう意見もあったけど、そもそもその設計が今採用されているか自体は疑わないのか?
結局、人伝いに情報を得るしかないんだよ。
> つーか、お前らは何でそんなにドキュメントを信用できるんだよ。
信用してねーよ。
だから、実装とずれてても気にしない。
一致しないと認めないとか青臭いことを言ってもしょうがないからね。
>>504 つーかそんなに現状とドキュメントがかけ離れててそのことについて何の言及もない現場だったらソースがあってるかどうかも怪しいだろw
お前みたいな極論出して仕様書は役に立たないとか言われても誰も納得しないよ。
>モンキー集めてモノづくりする日本の企業にはドキュメントなんて不要だよね
俺の知っているプロジェクトがある。三社が集まる。本社、分社した技術会社、使用する部署の責任者
で三人は、良い大学出、下請けに出すのがノウハウという人、現場を知らない人
というわけ。開発ということも知らないのが集まっても、ひとりの開発者にはかなわない
>>507 彼らが開発できると踏んだのが自社開発のVBシステムがあった
それをベースにメンテナンスできるようにというわけ
社外では絶対通用しない、素人が作ったようなシステム
ベースがVBじゃねー。
>つーかそんなに現状とドキュメントがかけ離れててそのことについて何の言及もない現場だったらソースがあってるかどうかも怪しいだろw
最近経験したよ、こちらは前のとおりつくった。三年前のやつ。写真にとってあるからそのように配線
そしたら発注元が、前のと違う、ソースコードが対応していない、だって。前のとおり作れ、というわけ。
しかし、こちらに発注元からうちへ送ってきた写真があった。三年前に発注者が説明を求めてきたのだな
それが証拠となって、作り直しを防いだ。
ソースの管理がだめだと迷惑かけるよ
>>506 動きがおかしかったらユーザーが文句言うから
>>504 業務、担当区分によって設計の認識が違うのかな
例えば組み込みな俺の設計のイメージ
クラス図、シーケンス図、状態遷移図/表、タイミングチャート、フローチャート、運用時の動作解析用ログ出力内容(内部向け)
後はテストケース
512 :
仕様書無しさん:2014/05/04(日) 09:56:34.84
今の現場に出来の悪い外部設計書しか存在していなかったんだが。
いいなぁ、かっこいいドキュメント拝んでみたいよ。
つーか何でクソドキュメントを前提に話をしてるんだよ
そんなの役に立たないどころか邪魔に決まってんだろ
ドキュメントが糞なのは、
・動かない
・バグがあっても通ってしまう
・矛盾があっても通ってしまう
・テストされていない
・修正した後に回帰テストを行っていない
からだよ。
噴出しつけとけばでたらめかいてもいいんだよ。
┌────┐
│見直し要 │
└┐┌──┘
| /
だいたいは上流で時間使われすぎて、テストフェーズでアレコレ直さなければ
ならなくなって、ドキュメントから修正じゃ間に合わないからとりあえず実装側で
対応して、それを通した後にドキュメントにフィードバックしてないからってのが
かなりの数あるんだろうけどね。契約的に結合の最初の方が終わったら、
はいさようならってのもよくあるし。
>>514 だから、うまくいってる所ではどうやって現実的なコストでドキュメントのメンテナンスをしてるんだ?って話をしたいんだが・・。
どいつもこいつも、ドキュメントがクソ化する前に逃げ切った奴しか居ないのかよ。
ドキュメントを維持するためには、人やプロセスを整備する他無いよな?
それじゃ金がかかりすぎるんで、現実は害悪なレベルのクソドキュメントが量産されてます。
ってだけの話なのに、俺は大丈夫だった。お前がおかしいとかとか言われても議論にすらならねーよw
2chに議論求める俺が悪いかもしれんけど。
519 :
518:2014/05/04(日) 17:09:58.87
>>510 客がシステムに対して持つイメージが仕様になります。って職場じゃないの?
客側で仕様まとめてる人間と、ユーザ部門の担当者で認識が乖離するのはよくある話。
都度運用でカバーするから、運用が落ち着く頃には運用部門とユーザ部門間でドキュメントの無い仕様が大量に生まれる。
>>511 詳細設計レベルだよな。
俺のイメージだと、他ブロックへのインターフェースを除くと、内部はモジュールの複雑さによって、担当者の裁量で残したり残さなかったりって感じ。
設計書がプロダクションコードに追いついているのは稀だから、余程コアな所以外は、口伝と引継ぎ時に書くポンチ絵に頼るケースが多かった。
技術継承目的になると、引き継ぐ相手の文化やレベルが判らないから、行間を埋める方法が何かしら必要になるよ。
>>519 >詳細設計レベルだよな。
横レスになるけど、組込み系/制御系/通信系だと
>>511の
シーケンス図や状態遷移図/表は機能設計レベルの文書になる
言い換えると、実装には依存しない論理的な機能要素の仕様を
こういった図表で定義し、エラー発生時やイベントのすれ違い/衝突時に
正しく振る舞うかを論理レベルで検証するのが機能設計工程の目的
そしてこの論理的な仕様を実装するのが構造設計/詳細設計になる
>>518 > ドキュメントを維持するためには、人やプロセスを整備する他無いよな?
とだけ言えばいいのに、ドキュメント無ければトータルコストが削減できるとか
無茶苦茶なことを言うから突っ込まれる。
口伝と引継ぎ時に書くポンチ絵をドキュメントにまとめればいいのに、
なんでやらないんだろう。
>>522 「やらない」んじゃなくて「やれない」んだと思う
口伝と引継ぎってのは開発が一区切りした後にやるものだけど、
でも設計書は開発工程の先頭でまとめるもの
それなのに、設計書を書く時点では最終的な設計イメージを持てず、
お決まりの規則に沿って役人仕事で設計書を書いているだけ
開発一区切り付いた時点で、設計書を実際のコードにあったものに手直しすることしないの?
最後納品用ドキュメント作成する時に設計書の修正もさせられてたけど。
>>518 だから修正する度にソース見直して解析する工数>>>>>>内容をつかめるレベルのドキュメントを整備する工数なんだが。
当たり前のとこはちゃんとやってるよ。
ソースに書いた方が早いものはそこに、別資料の方がいいものはそこに。
なんでコストとメリットのバランスが取れるレベルの資料を作ればいいってことが理解できない?
>>521 どこが無茶苦茶だ?
ドキュメントを適切に管理し続けなければ、徐々に負債になるのは事実。
管理しない位なら存在しないほうがマシって言う主張とは相反しないと思うが。
ドキュメントがあるの状況を理想というのは勝手だが、現実問題困難なんだよ。
客がトータルいくらででソリューションを手に入れるかって視点で見ると、まともなドキュメント作るより人を張り付けたほうが安いことも多いんだぜ。
>>522 だから、まとめたものをどうやってメンテしつつ残すんだよ。
>>524 大抵するね。で、その後は?
あくまで「開発時」のドキュメントとして保存され、誰も触らなくなるケースばかりじゃね。
リリース1発、メンテナンスフリーで動き続ける位枯れたロジックなら別だけど、
運用始まった後に大幅乖離するのが殆どじゃない?
527 :
518:2014/05/04(日) 20:05:56.91
>>525 資料って、誰向けでどのくらいの期間残すものを想定してるんだ?
勝手に推測すると、内部で担当者間の意思疎通のため使うもののように聞こえる。
そういうものって、今現在か精々リリースまでしか想定してないんじゃないか?
で、そういう資料って、往々にして開発チームや担当者間で埋もれてしまう。
理由は体裁が整ってないやら、内輪でしか通じない表現で記されているやら。
(運用チームや客の利害が一致してなきゃ、引き継ぐほうが文書の体裁を求めるのが普通。)
結局組織としてはアリバイ作りのテンプレ文書を量産して、必要なノウハウや思想はドキュメントに残らない。
そうなると、人を残して口伝か教育で引き継がざるえない。
> なんでコストとメリットのバランスが取れるレベルの資料を作ればいいってことが理解できない?
ここを否定するつもりは無いよ。
コスト対効果を取るとドキュメントとして残るものが少ないってだけで。
>>526 > あくまで「開発時」のドキュメントとして保存され、誰も触らなくなるケースばかりじゃね。
そんなの聞いたこと無いぞ。
改修が行われる場合は、普通に改修後の設計書も納品物に入ってるだろ。
>>527 内部の関係者の意思疎通のためだが、うちは多くの場合同じ会社のシステムの開発と運用を継続して受けてるけど、ドキュメントに起こせるとこはするし別に埋れもしないが。
体裁が整わないって言うなら整えればいいじゃん。
あー、わかった。納品されたものを勝手に改修するケースか。
知るかそんなもの。
普通に外注に出せば改修後の設計書まで作らせる(=その分のコストも支払う)のに、
自分たちで改修したら作らないとかただの手抜きとしか。
>>528 納品物?大抵、スッカスカのアリバイ用になってるだろ。
ドキュメントは客から中身が見えるから、必要最小限になるのが普通じゃないか?
必要以上に納入した結果、いつの間にか客の手で仕様扱いに。後から不具合だって言われたこと無いのか?
>>529 簡単に言うな。そのコストが高いんだよ。
体裁と一口に言うが、その心は「(受け取る側からして)俺たちがパッと見て解るものもってこい」だ。
文書の項番や章構成、フォント等の指定は序の口。
開発部門/会社の政治力によっては、組織間の文化の違いや読者の知識レベル、視点の違い辺りをドキュメントで吸収させられる。
お前らは引継ぎで苦しんだこと無いのか?
>>530 クソドキュメントで工数削られる位なら、すこしでも工数あるほうがマシ。それだけの話。
>>531 もうさ、お前の想定してる状況を書いといてくんない?
前提が違いすぎて話にならん。
>>531 > 納品物?大抵、スッカスカのアリバイ用になってるだろ。
PSレベルだと、doxygenで出したもの納入することもあるが、SSレベルはないな。
だいたい、客のレビューが入るからそんなスカスカなものは通らない。
> いつの間にか客の手で仕様扱いに。後から不具合だって言われたこと無いのか?
設計は設計でレビューして客の承認取ってるわけだから、設計と違った動作したら不具合だろ。
>>531 開発に役立てるための設計書の話してるのに客へのアリバイ作りのための無意味な設計書の話してどうすんのよ(´・_・`)
>>532 そこそこの規模のSIを想定してる。
組織は客と開発/運用側はバラバラの会社で、下に有象無象の人間がぶら下ってるような一般的なの。
客や開発/運用、有象無象の下請けで各々が自分の利益を最大化するよう動いていて、人がそれなりに入れ替わる感じ。
>>533 全ての挙動/要件をドキュメント化するのは困難。
規模によっては、どんなにレビューしても穴が出るもんだよ。
外部要因を考慮すると、正確に運用後の姿を知る術なんて無いから。
>設計は設計でレビューして客の承認取ってるわけだから、設計と違った動作したら不具合だろ。
設計内容について、徹頭徹尾客の合意とるとか尚更不可能。
レビューを通しても曖昧な部分なんていくらでも残るんだよ。運用が安定しようが、騙し騙しやる部分は必ず出る。
問題が起こったとき、関係者は他の組織にどう責任ふっかけるかを血眼になって探し回るもんだ。
だから、極力安全な部分だけ客のレビューに出して通す。
細かいノウハウやら設計の過程やらも、そこにわずかでも破綻が見えれば拡大解釈して責め立てる道具になる。
>>534 上に書いた通り、その無意味な設計書しか大っぴらに引き継げないんだよ。
また完全じゃないものは無意味って言い始めてる。
結局、ドキュメント書きたく無いだけなんでしょ。
パーフェクト症候群か。
話がかみ合ってないぞ
もっと具体的に話をしろ
>>537 そりゃ、まともなものを見たことがなければ、書きたくなくもなる。
ドキュメントをキッチリして、サクッと終わらせるより、
仕様もロクに明確化しないで、グダグダと残業ばかりやってた方が、
カネをたくさん取れる場合も多いしね。
>客や開発/運用、有象無象の下請けで各々が自分の利益を最大化するよう動いていて
なんだこの前提は?
よくある事なのか?
迷惑だから開発に関わらないで欲しい
こんな認識の奴は
>>535 だからお前は客に出すためのアリバイ作りの設計書の話をしてるんだろ?
それと開発を継続して行く際のゆうようなせっけいしょの話は別物だろ(´・_・`)
>>536-538 下手なもの書いたら誰も得しないってだけの話なのにどうしてそうなるんだ?
揶揄するなら建設的な意見だせよ。
>>541 良くある話じゃないか。俺が見るのはこんなのばっか。
客:1円でも安く、1分でも裂く時間を減らしてソリューションを調達したい。(ユーザ側に臨時で入れてる有識者をとっとと切って、工数減らしたい。)
開発会社/部門: 1円でも多く中抜きしてシステムを納めたい。開発終わったら、一刻も早く手を引きたい。
運用会社/部門: 現実的に業務が回り、素人でも運用できるシステムとドキュメントを引き継いで欲しい。
下請け: 素人ぶちこんで中抜きおいしいです。
>>542 どんな設計書なら有用?その設計書を生かすにはどんな前提を用意したら良いんだ?
>>543 君から建設的な意見を聞いたこと無いんだがw
>>543 だから下手なもの書くの前提の話してるからだろ。
ソース解析する時にこういう情報がまとまってたらいいのにと思ったことはないの?でその中でコレだったらそれほど工数かけずに作れてかつ有用な物は?
自分なら全体の概要図や状態遷移図などは欲しい
ここでグダグダ言っても、設計書が役に立った経験が無いと理解できない思うよ。
(むしろ、設計書がなくソースコードだけ渡されてメンテする経験したほうがありがたさがわかるかな)
バージョン管理システムとか、自動テストとか導入する時に
「面倒が増えるだけ」「メンテナンスしないから無理」
とか言って導入に反対する人と同じ症状になってる。
>>544 実態を無視して理想論語ったらいいのか?
俺が挙げた前提が酷いのは重々承知してるが、実態と切り離して意味のある話じゃないだろ。
都合よく挙げると、この位の前提になるぞ。
ソリューション導入の目的が明確かつ全関係者に浸透しており、かつ見込C/Pが現実的。予算は潤沢に供給されている。
士気が高く必要なスキルを持つ人員のみで関係者が構成され、入れ替わりも滅多に存在しない。
当然、ドキュメントのメンテナンスや前提の調査にも専任の担当者を確保。
客や開発/運用会社やチームも同一の文化圏に属し、組織の壁は無く善意で回せるくらい良好な関係が築かれている。
>>545 > 自分なら全体の概要図や状態遷移図などは欲しい
使い物になるレベルで用意できるなら、俺も欲しいよ。
後は、インターフェースの仕様書と全体の担当割辺りがあるといいな。
>>546 ドキュメントの質次第では、ソースコードだけ渡されて必死にヒアリングと仕様起こしする方が確実に楽。
そのたとえ話に乗るなら、開発者のアクセスが十分に確保できないのにSVN入れてみたり、CIせずに自動テストするようなものだろ。
手段による利益よりも害悪が勝ってしまっている状況。
どれだけ前提条件を整えたら、ドキュメントが役に立つんだ?
>>547 > 使い物になるレベルで用意できるなら、俺も欲しいよ。
後は、インターフェースの仕様書と全体の担当割辺りがあるといいな。
そうだよな〜、欲しいよな〜
じゃ、グダグダ言わずに担当した分の設計資料は残しとけよ無能
後は使い物になるレベルってやつの定義かな
お前が引き継ぎの時に書くチンポ
とりあえずそれでも有用だろ
基本的に完璧な設計書は求めてないぞ
でも状態遷移図/表は完璧なもの作っとけよな
ユーザは設計書なんてまともに読まないからなぁ。
>>547 > ドキュメントの質次第では、ソースコードだけ渡されて必死にヒアリングと仕様起こしする方が確実に楽。
ヒアリングって、誰に何を聞くんだよ。
客が設計の詳細知ってるわけでもないし、開発をした担当者はいないんだぞ?
勝手に前担当者がいるという条件を追加してないか?
>>547 結局、お前が勝手にドキュメントが役に立たない状況を想定して、
この場合はどうする?って駄々こねてるだけじゃないか。
現実は、大半のプロジェクトが「もっとまともなドキュメントはないのか」と思われつつも、
無いよりはよっぽどましだからその場で可能なメンテをしながら運用されてるんだ。
もしお前が本当に「ドキュメントが無い方がマシ」なプロジェクトに当たりつづけてるんなら
かわいそうですね。転職を考えた方がいいですよ。
>設計は設計でレビューして客の承認取ってるわけだから、設計と違った動作したら不具合だろ。
思ったんだけど、これが根本的に間違ってないか?
政治的問題は置いといて、
設計はレビューして、開発者の承認を取るのが筋じゃないのか?
これを見て開発するわけけだから。
間違った設計を、素人である客が直せるとは思わんし、
素人に見せてもしょうがないだろ?
>>547 >使い物になるレベルで用意できるなら、俺も欲しいよ。
一週間分の実装とテスト分についてのポンチ絵描きや修正なんぞ2時間もかからんと思うんだが。繰り返してけば修正ばかりになるから余計短縮されるな。
>後は、インターフェースの仕様書と全体の担当割辺りがあるといいな。
担当割って何に使うのよw問い合わせ前提かw
てかそれぐらい残すの一瞬だろwww
555 :
仕様書無しさん:2014/05/05(月) 14:26:27.73
世の中には、システムを一から作り上げれるPGと
出来上がったものをちょこっと手直しすることしかできないPGがいるわけ
俺はシステムをゼロかつくるのはできない、 というプログラマと最近会話した
そういうプログラマのために設計書あったほうがいいよね
>>548 で、お前はどんな前提想定してるの?
どんな状況下でもドキュメントが生きる訳じゃないのは、散々挙げただろ?
ドキュメントが責任転嫁に使われるようなプロジェクトだと、身を守るために皆最低限しか引き取らない。
ドキュメント残す仕組みがなけりゃ他の担当者の手に渡っていかない。
>>549 状態遷移図/表って包括的に書くものなのか?
業務系だと、大抵のプロジェクトが複雑な部分だけ残してた。
>>551 メンテナンスフリーでもない限り、誰かしら関係者は残っている。
開発した担当者に聞けるのがベストだけど、周辺モジュールの実装者や運用担当者でもいいじゃない。
完全に独立してる物じゃなきゃ、たとえ設計書があったとしても同様のヒアリングが必要。
>>553 組み込みのように、ビジネスロジックの比率低めで実装の難易度が高い分野なら同意。
業務系の場合、ビジネスロジックの比率が高めで比較的実装難易度が低い。
ビジネスロジックの比率が高い分、客側の業務担当者のレビューが意味を持つ。
ユーザ側の不便や設計者の業務知識不足、環境に起因する制約事項等々、開発チームのレビューで発覚しにくい不具合を弾ける。
>>554 だから、作るのが問題じゃなくて作った後が問題なんだって。
>>556 有用な物をマトモな手続きを確立しないままグダグダとロストして無駄な作業を繰り返してるだけにしか見えんわ
>>556 業務系だけ?
他の経験は?
君の発言は一部の業務系開発に限るってことでいい?
組込み等、設計書が有用な開発があるって納得してもらえた?
とりあえず
>>556以外は設計書はうまくやればメンテコストを考慮しても有用だから上手い具合に残しとけってことでいい?
それでよければどういうのがあるとコストかからず有益かの話しようぜ。
もうグダグダと出来ない言い訳を繰り返す奴はお腹いっぱい。
>>559 「うまくやれば有用」は誰も否定してないんじゃない?
>556は、「うまくない設計書なら要らない」って言ってるんだと思うんだが。
で、SysMLが例に出されたけど、実際やってるやつらはモデリング主体なのかが聞きたい。
>>560 だから0か1かじゃなくて、どのレベルなら「うまくない設計書」と定義してるの?
世の中ペラ紙1枚でも読むのが苦痛な人がいるからな、そういう人にしてみたら
何か書くのさえ「うまくない設計書」を書いてるつもりになるんだろ。 逆にペラ紙
1枚から驚くほど色々と読み取るのもいるけど。
>>560 >>556は何を言ってもそれ無理あれ無理とうまくやる術はあり得ないと言ってるからまたちょっと違うかと。建設的じゃなさすぎる。
563 :
560:2014/05/05(月) 23:06:02.69
>>561 そんな話は今まで誰もしていないと思うけど、
これから始めようってことかい?興味ないけど>定義
それより「うまくやれてる」実例を具体的に知りたい。
564 :
560:2014/05/05(月) 23:14:28.25
>>562 建設的かどうかはわからないけれど、556に共鳴する部分もある。
実際、ひどいもんなんだもの。
そういう現場も業務系では多くあって、組込その他で見習うべきものがあるなら
是非とも見習いたい。
きちんとした設計書が当たり前のところから見ると、頭おかしいレベルなんだろうし、
ちゃんとすりゃーそりゃ楽だし確かだし、ってのは当たり前なのは理解している。
565 :
560:2014/05/05(月) 23:28:07.81
まずは概要設計書をどうしているか、うまくできている所に聞きたい。
・モデリングツール使っているのか?何を?
・設計標準を作成しているのか?作成にかかった工数はわかるか?
あたりさわりのない範囲で教えて欲しい。
>>556 > 状態遷移図/表って包括的に書くものなのか?
業務系だと、大抵のプロジェクトが複雑な部分だけ残してた。
当然、作るのは複雑な部分だけでいい
だけど作ったもの位は完璧にメンテしろよ!
って言いたかった
分かりにくくてごめんね
でも正直、包括的に書くわけねーだろ低脳! っていう思いもある
つーか、資料残してるんだな
当たり前だよな
複雑な状態をもつソフトを突然コーディング出来るわけないもんな
別にかっこいい設計書に仕上げる必要はないけどさ、設計資料は作るべき
>>566 カッコは、大事だぞ。
タイトルと日付が入った表紙と目次ぐらいは、ついてなけりゃ、
メンテされなくなったり、誰も存在に気がつかなくなったりする。
>>556 メンテナンスフリーでもない限り、誰かしら関係者は残っている。
なんでそんな都合のいい前提を置くかな。
ソースコード買った場合など、関係者がいない場合も多いよ。
>>556 > だから、作るのが問題じゃなくて作った後が問題なんだって。
2時間で作ったものなら、2時間程度で改修できるでしょ。
君はそれをやらずに、ただメンテナンス工数が取れないと文句言ってるだけ。
2時間で作ったら20時間かかるでしょ
逆に20時間かかったら2時間でメンテが終わる
>>569 > 2時間で作ったものなら、2時間程度で改修できるでしょ。
できるとは限らないよ。2時間で0から作ったものなら
2時間で0から作り直せるかもしれないけど、
改修が2時間で終わるとは限らない。
2時間じゃ短いから1ヶ月、そして建築物にたとえてみようか?
1ヶ月で2階建の建築物を作りました。
これを4階建に改修するならば、まず土台を4階建に耐えられるように改修しないといけない。
今ある2階建を全部とっぱらい、0に戻してやり直さなきゃいけないから到底1ヶ月では4階建にはできない。
2階建を取り壊す時間 + 目標が4階建だから、2階建よりも強固な作りにしないと
いけないから2階まで作るだけでも、2階建の時よりも時間がかかる。
ソフトウェアも同じで0から作り直すのではなくて改修なら、
既存のソースを読んで理解する時間が必要。
改修だと読む時間のほうが長くかかるので、だから読みやすいコードを書けって言われるわけ。
改修に時間がかかるのは、初期に手を抜いた証拠でもある。
初期に手を抜いても、修正可能な設計になっていればいいけど、そういうことまで手を抜く奴が多い。
こうのうがメンテナンス性。
初期の設計とメンテナンス性が悪い、それは技術不足でもあるが、そういうのが極めて重要。
そしてそれは設計書には書かれない部分でもある。というか設計書を書く人が技術不足なんだよな。
コード書けない人が土台を作ってはダメ。
>>570 イミフ
>>571 まだ出来ない理由をあーだこーだ探してるのか(´・_・`)
この話の流れでそんな極論述べて出来ない可能性がーとかお前現実世界で大丈夫なのか?
>改修に時間がかかるのは、初期に手を抜いた証拠でもある。
>初期に手を抜いても、修正可能な設計になっていればいいけど、そういうことまで手を抜く奴が多い。
>こうのうがメンテナンス性。
おまえのソフトが欲しい、前のより少し変更してくれ、というリピートがくると
俺は保守性をかんがえる。0から作り直す。1300ccの車から、2000ccクラスへ変身させる
追加のオプションを安全に実装できるように作り変える
で、だめなのが、既存のコードに追加していくタイプ。
追加の仕様にあわせ、ifだらけ、フラグだらけになっていたりする
こういうのをメンテしたくない
俺はリピートがきたら作り直すといったが
プロトタイプを収め、つぎに注文がくるというのもある
プロトタイプのベースから、ソースが二倍に膨れるともある。
作りなおしだよ
素直に足して済む場合と、構造から変えないといけない場合があるもんな
> 素直に足して済む場合と、構造から変えないといけない場合があるもんな
その通り。そういうのは設計書を見てもわからない。
コードを見ないと判断不可能。
>>571 ポンチ絵書く期間の話と、実装する期間の話をわざと混同してるよね?
実装には時間がかかるから、
実装の時間を極限まで減らすと
やり直しをする時間が取れる。
実際作ってみなきゃわからないこと多いんだしさ。
で、今は組み込みや制御系の話? それとも業務系?
業務系は人とのインタラクションが多くて、要件自体が細かいレベルであとあともコロコロ変わったりするから(結局使ってみなけりゃわからない)、設計文書は最小限にしてクイックに開発サイクルを何回も回すというのはよくある話。
その場合は開発と運用の距離も近くて、それでも何とかなったりする。
一口に業務系といっても、業界や業務領域によって違ったりもするけどね。
>>576 まともな概要構造が書かれてるのあればコードみなくても大雑把な判断出来るが。
もちろん改修にあたって実際にコードは見るが、概要構造があれば役立つって話と何も内容変わってないよ?
>>576 仕様書と設計書とをゴッチャにしてるだろ。
構造変えるんだから、設計書変えるのは当たり前だ。
>>581 お前の言ってる、構造って
具体的に何?
いくつか言ってみて。
文書は書いた方が絶対にいい。
プログラマーの仕事の半分は
仕様書書きにしても良いレベル。
SEとかいうゴミにはせめて
完璧な要件分析を期待したい
完璧な要件分析とかするよりはざっくりと方向を作ってラウンドトリップで行く仕組みを確立した方が皆が幸せになるよね。
実際は色々と難しいと思うけど。
>>582 元レスも読めないなら黙ってた方が良いんでは?
>>587 いや、アジャイルは開発部隊と顧客が一体になることが
キモの開発技法だから、国内の大半の現場では非現実的
最近思ったんだけどさ、手描きのデジタル化のコストってものすごく下がったよな。
それほど重要な資料でも無いんだけど、必要だからアレコレ書いて、文章だけだと
ちょっと分かりづらいから図も入れるかってなった時に、前までだとペイントツールや
excelやwordなんかだと組み込みのを四苦八苦しながら作ってた。 今だとスマフォ
連携のノートで書いたのを撮ったり、液タブなんて安いのなんて1万切ってるんだから
そういうのを使うのも有りなんだなあと。 もちろん内部統制とかもあるだろうし、
納品用のドキュメントにはそのまま使えないだろうけど、内部で意識合わせ
する程度には十分なんだよな。
591 :
仕様書無しさん:2014/05/06(火) 22:50:35.79
要件定義は必要だな、何作っていいか解らないから
基本設計は必要だな、どう実装していいか解らないから
詳細設計は・・・・・ソース見た方が早くねぇ?
>>590 液タブ買うならホワイトボードに書いたのをスマホで撮るのが安上がり
うちのところは仕様屋と設計屋と実装屋と検査屋がそれぞれ別の部署だから
書かざるを得ないし役立てざるを得ない。
役に立たないものは差し戻す。
>>591 設計書の本来の役割は、"何故そうしたか?"を判るようにする為の物。
なので、ソース見た方が早い状況というのは、本来の目的を実現出来てない資料だというだけ。
>>594 ルール決めて、持ち込み可にしてる処も有るよ。
BYODで検索。
テクニカルライティングの能力が高くないと本来、設計書を書けないのですが、
日本のソフト技術者のテクニカルライティング能力が低すぎますよね。
設計書を書けと命じても「日本語で書いたコードもどき」を書いてしまう。
コードもどきを書くなと命じるとスカスカの設計書になってしまう。
概念図を描けと命じると些末な事まで描いてしまい何を伝えたいのか分からない図になってしまう。
シーケンス図を書けと命じると矢印に吹き出しを付けてシーケンスでない事をゴチャゴチャ書く。
状態遷移表を書けと命じると些末な事まで状態とみなし表が破綻する。
なぜそうしたか理由を書けと命じると些末な決定事項にまで「後付で無理矢理考えた理由」を書きまくる。
>>597 部下に具体的に指導出来ない無能な感じがします(´・_・`)
>>598 部下に文句言ってるやつは、まだマシ。
今、出世してる人のほとんどは、書かせようともしない。
たまに、ちゃんと書いてる部下や外注がいたら、無駄なことするなとやめさせる。
NEC系、日立系、東芝系などの大手ソフト会社に請負形態で発注した時の話です。
請負形態なので本当は命じてはいけないのですが
設計書があまりにも酷いのでやむにやまれず指導しています。
部下じゃないので指導しても人が替わってしまうと1からまた指導
597ですが日本のソフト会社の皆さんは中国のソフト会社に
仕事を取られますよ
中国のソフト会社は日本語で仕事を受けてくれますが
単価が安いのに非常に優秀ですよ
日本のソフト会社の優位点は日本語が母国語という事だけです
でもその日本語が怪しい日本人技術者が多いw
たしかに最近の中国オフショアは、日本人対策ができてきている感じがする。
>>601 2020年になくなる仕事としてもプログラマーは海外に仕事を取られるとして上がってたけどどうだろうね。
インド人のオフショアと99年ごろ関わってたけど優秀だけど良くも悪くも日本的な仕事の進め方と合わなそうな印象を受けた。
色々と通信環境含め変わって来たけどまだ顔を付き合わすこと、付き合わせられることの優位性も残ってそうだが。
>>595 > 設計書の本来の役割は、"何故そうしたか?"を判るようにする為の物。
いやいや、本来の役割は文字通り「設計内容の可視化」であって、そういう設計にした理由は本来は不要でしょ。
>>595 > 設計書の本来の役割は、"何故そうしたか?"を判るようにする為の物。
> なので、ソース見た方が早い状況というのは、本来の目的を実現出来てない資料だというだけ。
ソースを書く上で行う類いの判断は、設計書に入れる必要は無い。
>>604 なぜそういう設計にしたかは必要だろ。設計書に含まれるかは知らんが。
>>605 なぜそうしたかはコードを書く時にだけ出てくる物では無い。
>>606 > なぜそうしたかはコードを書く時にだけ出てくる物では無い。
ソースを書くときだけに出てくるとは言ってない。
ソースを書く上で判断するようなレベルのことを設計書に入れるなということ。
設計書に理由も書いた方が良い例
例えば動画をストリーミング配信するシステムの開発を担当したとする
サーバーからクライアントアプリに動画のフレームを流すためにUDPを当然選択する
しかしお馬鹿さんはこの選択に対し「何故信頼性の高いTCPでなくメッセージを取りこぼすかもしれないUDPを使うの?」と疑問を持つ
この疑問に先回りし「動画のフレームなんて取りこぼしたら取りこぼしたで問題ないんだよ」「TCPで送信したら要求されたフレームレートを達成できないじゃん」と設計書に理由を書いてあげた方が良い
書いておかないと将来お馬鹿さんがコードの保守を担当した時、TCPを使うように改悪するかもしれないから
597&601です
インドの会社に発注した事もありますがインド人は細かい条件闘争を仕掛けて来ますね
それにイチイチ応対する発注側(日本人)の工数が勿体ないので、インドから中国に切り替えました
中国のソフト会社の方が「損して得取れ」的な理屈が通じます
>>608 それは単にお馬鹿さんに常識が無いだけ
その例えで言うならUDPを使いそうな所を何らかの特殊な事情でTCPにした場合にその理由を書くべき
>>608 どちらかっていうとアホがTCPに決めて
コーダーがコメントにそう決まった残念な経緯を残すイメージ
設計の意図が書いてあるものなんてソースのコメント以外で見たこと無い
>>610 お馬鹿さんとは
アベレージプログラマ=不勉強で向上心の無い連中=日本の職業プログラマの過半数
という意味だよ
>中国のソフト会社は日本語で仕事を受けてくれますが 単価が安いのに非常に優秀ですよ
優秀なわけねーだろ
俺が引退した後は知らんが
かれらは商業民族、すぐ結果をもとめる。韓国もな
で、そういう民族は開発とは縁遠いな
日本人が開発するのをまっているよ。日本の引退した技術者歓迎ね
>>613 平均的な日本人と平均的な中国人と比べたら確かに日本人の方が優秀だよ
でも平均的な日本人プログラマと平均的な中国人プログラマを比べたら中国人プログラマの方が優秀
その理由は14億人もいる中国人のうち優秀な層がプログラマになっているから
日本ではプログラマはIT土方だけど中国でプログラマは高給取り
これは事実だから受け入れなよ
>>607 誰もそんな物を設計書に入れるとかいってないと思うが。
>>614 統計はとってないから知らんが、中国人の残したコードが負債のように放置されてるのは見たことがある。
実際たくさんの中から淘汰されてエリートだけが残ってるならイイと思うけど、どこ迄そうなってるかは疑問だわ。
>>616 それは中国に仕事を出した人の要領が悪いだけです
発注先の中国のソフト会社と長期的な安定したWin/Winの関係を築けていないのです
まず、中国のソフト受託開発の業界には
元請け -> 下請け -> 孫受け -> ... というおかしな商習慣があまり無いです
このため日本ソフト会社より安定した関係を築き易いです
私が発注している中国の会社はプトジェクトメンバー全員がその会社の社員です
そのためか、こちらが安定的に発注していれば長期間メンバーを固定してくれます
まぁ工数単価が安いので開発の谷間に「優先度の低い仕事」を出して人員keepしやすいのですけどね
618 :
仕様書無しさん:2014/05/07(水) 21:47:42.96
>>616 オフショア先の事を 使えねー と言う奴は
自分は無能ですと言ってるのと同じ
ブリッジSEの給料をみたら
どれだけ困難な仕事か想像つくだろ
>>619 オフショア発注先の会社のブリッジSEに頼っていたらダメだよ
海の向こうの開発現場の人達と直接コンタクトする事がオフショア開発成功の秘訣
実は開発現場の人達との直接コンタクトはオフショアの方がやり易い
日本のソフト会社だと請負法の壁がありリーダー以外とコンタクトするなと小煩い事を言われるけど
海の向こうの開発現場には日本の法の支配が及ばない
621 :
仕様書無しさん:2014/05/07(水) 22:32:45.90
好き勝手な事を言うカスタマーと開発チームの間で1人か2人の客先常駐者が板挟み
それって日本のソフトハウスを使った時も起きる事じゃね?
出来ない理由をあーだこーだ言っているような奴には
到底1時間でアメリカに行くことは出来ないだろうな。
どうやって行くか、答えてみろ。
>>601 もう10何年も前からそう言われてるけど、結局中国は仕事が雑で単価が高く
なってきたからインドやらベトナムやら東南アジアあたりにオフショア先が
移ってるんだよね。 それに最近だとアメリカの法律でライセンス違反の
ソフトを使って開発されたものが一部でも組み込まれているような製品は
不正な競争のため元請けの製品そのものも輸入停止にするようなのも
出てきて実際止められてるのもあるし。 遵法精神に乏しい中国を使う
リスクのほうがはるかに高くなってきてるんだよな。 この法律自体は
最近出来たので、それほど知られてないけどね。
同じサービス業でも介護とかなら国境を越えられないけど
soft開発は簡単に国境を越えられるからなぁ
IT土方さん達は付加価値を付けないと生き残れないよ
日本のIT土方はコミュ力低すぎて設計書なんて書けねー
という結論で おK?
>>600 というよりその人も外注だろうな
その大手ソフトたちは進捗管理しかやらないからな
627 :
仕様書無しさん:2014/05/07(水) 23:44:27.04
ウチの会社は糞真面目なので外注さんとフロアを別にされ
更に社員フロアに外注さんが入室できなくなった
アジャイル開発もへったくれも無くなり窓口のSEとmailを頻繁に投げ合うようになってしまった
でもmailの文面がイミフで話が噛み合わない
小回りが効かないのにLine単価がバカ高い金食い虫化してるんだけど
切った方がいいのかな
>>625 ・日本はドイツに習って戦勝国に謝罪すべきだー
・日本はドイツに習って原子力発電計画を放棄すべきだー
・日本はプエルトリコに習って一切の軍隊を廃止すべきだー
・日本はスイスに習って永世中立国を目指すべきだー
という結論で おK?
>>626 NECシステムソリューションに統合されなかった某社(通信機器も売ってる会社)のケース
我が社の民生用機器のサブシステムの開発とそのサブシステムが中核となる機能のシステム設計を委託
システム設計書は他のサブシステムの開発者も読むので当社標準のスタイルで書いて貰った
ここまでは良かったけどサブシステムの基本設計書が酷かった
ページ数の90%がシステム設計書のシーケンス図の焼き直し
システム全体の視点からサブシステムの内部設計に視点を切り替えず
「基本設計書でのシーケンス図」なる謎のページをコピペで大量作成
その後そのコピペシーケンス図をDFDで書き直し
DFDの内容はシステム設計書のシーケンス図とほぼ等価なのにサブシステムの内部設計が完了したと主張
システム設計書に書いた事を無駄に2回書き直しているだけだよね?
と指摘したら「この工程を踏まないと品質を担保できない」と逆切れ
いい加減にしてください
630 :
仕様書無しさん:2014/05/08(木) 01:16:25.32
>>629 NTTから仕事貰ってた会社ってそんな感じじゃない?
お役所仕事が染みついてスピード感全くなし
>>620 請負法って、何だよw
別に法律で規制されてるわけじゃないが、大きいプロジェクトじゃ、
担当者からリーダへの報告系統があやしいから、リーダー通せってだけだろ。
実際、こまごました話を全部担当者直でやられたら、収拾がつかないってのはよくある。
何度同じ事を繰り返せば生まれ変われるのかな?
1) 顧客と仕様をそれなりに合意
2) コード何行、設計書何ページと成果量を見積もり
3) 成果量と基準単価から金額と開発期間を見積もり顧客に渋々合意させる
4) 儀式的な設計工程で開発期間を食い潰す
5) 設計書はあるけど設計できていないと社内で薄々気づくが顧客にはONスケジュールと報告
6) 見切り発車でコードを書き始めるが頻繁に設計の相談を行うので遅々として進まず
7) 顧客が遅れに気づき騒ぎ出す
8) 挽回のため追加メンバー投入
9) 一番仕事ができる奴が追加メンバーから質問責めになりオーバーフロー
10) 一番仕事ができる奴が倒れプロジェクト崩壊
634 :
仕様書無しさん:2014/05/08(木) 02:12:34.45
635 :
仕様書無しさん:2014/05/08(木) 10:43:31.74
>アジャイル開発もへったくれも無くなり窓口のSEとmailを頻繁に投げ合うようになってしまった
でもmailの文面がイミフで話が噛み合わない
海外から、動画でここ直してくれっといってきた。動画がいいよ
近くのとこに納品したやつ。電話で、直してくれ、というのだけど、なにいっているか不明
くるまでとばして現地で確認。相手のいいたいことがわかった
>>618 無能集団はどんなやつがマネジメントしても無能でしかない
上に立つものが馬鹿だと、下にいるものはそのレベルにになります
具体例だと、菅直人が馬鹿だったので、民主党はそのレベルになったということ
638 :
仕様書無しさん:2014/05/08(木) 12:17:22.78
納品物がコードだけならインドに発注した方が良くね?
639 :
仕様書無しさん:2014/05/08(木) 12:24:33.41
日本のsoft会社なんて国際競争力ゼロ
日本語が母国語という事だけが取柄
それしか取柄が無いのだから読んで理解できる文書を書けよ
打ち合わせの時にダラダラと結論不明な報告をするなよ
能無し君たち
>>637 菅直人の前も後も、と言うかどれをとっても無能集団だっただろw
>>639 じゃあその能無しに仕事頼まずオフショアで中国人でもインド人でも好きなのに頼めばイイがな(´・ω・`)
なぜアメリカ人やヨーロッパ人に頼むという発想がないのか
>日本のsoft会社なんて国際競争力ゼロ
カルロス・ゴーンさんなら国際競争力ある会社にしてくれます。
上があほだと、下まであほになります
日露開戦で勝利したのでいつまでも、それを教科書にした日本軍と同じです
多分、中国でもインドでもいいものは作れない
継続という習慣がないわけ。すぐ会社をかわる。
会社を変わるというのは、彼らにしたらキャリアアップなわけ
そういうところでは技術は育たんよ
645 :
仕様書無しさん:2014/05/08(木) 15:11:54.82
俺が仕事を出してる中国の会社は大手でkindleのソフト開発も受注している
そこらの日本のソフト会社はkindleのソフト開発の仕事なんて受注できないよね
日本企業の仕事だけだよね
>>629 委託元(
>>629)としては、与えられたサブシステムの外部仕様を元にして
サブシステムを複数の機能構成要素(コンポーネント)へと適切に分解し、
それら構成要素間の関連が内部シーケンス図として基本設計書へ
記述されることを期待していた、ということでいいのかね?
まずは委託先某社の立場で弁護してみると、
>システム設計書に書いた事を無駄に2回書き直しているだけだよね?
>と指摘したら「この工程を踏まないと品質を担保できない」と逆切れ
の箇所だけど、設計書の表記法や語彙体系は開発組織の文化的側面があるから、
外部から与えられた設計書を自分達が慣れ親しんだ表記/様式へと書き直すというのは
決して一方的に断罪されるべきではないと思う
あと気になる点を挙げる
・この案件のスケジュールや最終的な納期および品質が分からんことには....
・委託契約の内容がどうなっていたのか、
言い換えると、某社の行為が契約違反に該当していたのか?
・
>>600によれば、多くの国内メーカ系との間で委託開発があるみたいだけど、
このN系某社は最悪のケースだったのか、それともよくあるケースの具体例なのか?
・もしもありふれているのならば、業務委託の発注元としてリスク管理に何か問題は
無かったのか、一言で言えば、自社として万全を尽くしていたと言い切れるのか?
>>629が同情を期待していたなら厳しすぎる意見かもしれんが、マジレスしてみた
ハードウェアベンダーや、その関連会社が出してる「仕様書」ってひどいものが多いからねぇ。
「システム設計書のシーケンス図」なるものから、直接プログラムをかけるケースは経験上ほぼ皆無。
648 :
仕様書無しさん:2014/05/08(木) 15:23:28.55
>>646 シーケンス図をDFDに書き換えても何も付加価値が生じない事を理解してるの?
>中国の会社は大手でkindleのソフト開発も受注している
インドの会社でWindowsの開発にたずさわっている、というのがあったけど
バグとり専門会社だろうとおもった
中国に出すのは、もっぱらコピーOKという部分
>>648 DFDが何だか理解してるか?
もし付加価値が生じていないとすれば、それはDFDの書き方が悪い。
629ですけど同情して頂かなくて結構です
このスレのスレタイと照らし合わせて読んで下さい
設計書が開発に役立った事があるか? という"お題"に対し
NEC系の割と知名度のある会社が役立たずの設計書しか書けなかったと紹介したまでです
システム設計書で書いた事のコピペ分を除くとスカスカの基本設計書しか書けなかったという話です
>>646 見積書に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系某社は役に立つ設計書を書けたのかもしれない
>>653 そこそこ名の知れているのは会社が売られたor売れた、会社でのポジションが
上がりに近いから責任取らされたor引っこ抜かれたって感じだけどね。
中国とかによくいる、給料が高いから転々とするっていうような人だと欧米でも
同じような埋もれて人並み程度に収まってるでしょ。
>>656 キミはスレタイから論点をズラして能力の低い会社を擁護しているとしか思えないんだけど何を言いたいの?
次工程の文書の殆どが前工程の文書のコピペなんて許されないでしょ
そんな事までリスクとしてList upしていたら有り得ない出来事をあれこれと想定しリスクだらけになってしまうよ
659 :
仕様書無しさん:2014/05/09(金) 00:47:17.90
要求仕様書にバグ無き事と書いていた同僚がいたなw
これってリスク管理した事になる?
やってみせ、言って聞かせて、させてみせ、ほめてやらねば、人は動かじ。
山本五十六
単価が安くて人をコロコロ変えないならそれもアリかな
単価が高ければ出来て当たり前としかw
>>658 開発委託って発注側と請負側での意思疎通が難しい
請負側にも高い技術力が必要だけど、
発注側にも高いプロジェクト管理能力が要求される
>そんな事までリスクとしてList upしていたら
そんな事と言ってるけど、成果物の曖昧さを排除するため
発注書に文書構成や要件を具体的に明記するのはSIerなら常識
まともなSIerなら社内規約に従って発注書を書いていくから
こんなトラブルは起きないし、起きても契約不履行に持ち込める
納品された設計書が役に立たなかったのは表面の事象であって、
委託開発の発注側として根本原因を探り再発防止策を考えるのは
当たり前の議論じゃないかと思うけどね
単純細胞で相手の技術力不足と見下すだけでは、何も成長しない
>>657 > そこそこ名の知れているのは会社が売られたor売れた、会社でのポジションが
> 上がりに近いから責任取らされたor引っこ抜かれたって感じだけどね。
それは、ニュースになるのがそういうケースばかりだからね。
> 中国とかによくいる、給料が高いから転々とするっていうような人だと欧米でも
> 同じような埋もれて人並み程度に収まってるでしょ。
日本と違って、同じ会社に長く勤めたら給料が上がるわけでもないからね。
>>661 設計書に何を書くのか分かっていない能力低い会社に設計書の要件を提示しても
結局その会社から期待した成果物が納品されないよ
見積額が高くなり完了予定日が遅くなるだけ
QCDのCとDが悪くなるだけ
開発着手前にふるいにかける目的なら有効だけどね
664 :
仕様書無しさん:2014/05/09(金) 02:03:07.83
ガイドラインとテンプレートと見本を渡せば能力が低い奴でも設計書が書けると考えるのはお花畑
テンプレートのマスに何でもいいから何か埋めて来て「御指示に従った結果です」と言い訳するだけ
ガイドラインなんてあるべき姿を理想論で書く事ができるだけ
自然言語主体で設計書を書く以上、
ガイドラインの遵守度を定量的に計測する事は困難
>>663 まあ、納品まで途中のチェックもなしにやってる会社も大概だけどね。
業界標準な設計書のフォーマットなんてないからすり合わせのためにも初期に
チェックして意思疎通をはかっておかないと。
666 :
仕様書無しさん:2014/05/09(金) 09:13:50.00
>もしも言葉とおりに「xxサブシステム基本設計書 xx頁」としか 書かれていなかったのなら、契約不履行にはならんよね
>リスク管理における契約では「成果物の曖昧さを排除する」というのが 原則の一つだけど、契約書の付属資料等で 基本設計書の文書構成や要件は具体的に明記されていたの?
おまえ菅直人並みに見えるよ。菅直人は法に則り行動した。
つまりマニュアルどおりしかできない。
彼があほだったかは、知っているだろ?
667 :
仕様書無しさん:2014/05/09(金) 09:16:31.97
>>664 低めに投げろ
ストライクを先行させろ四球を出すな
対角線の配球や緩急で揺さぶれ
ランナーが出たら併殺打を打たせろ
投手に指示した方が良いけれど
指示したから出来る事ではない
>>1 おまえが低層の10000000000000000000次請会社ってことがわかる
669 :
仕様書無しさん:2014/05/09(金) 10:47:21.69
発注元から見ると1次請負ってピンハネしてるだけじゃないの?
と思えてしまう
670 :
仕様書無しさん:2014/05/09(金) 10:51:50.74
そもそも、正しい設計書ってなんだろうね?
お客様が満足するもの、ってのも解で、請負ならそれでいいんだろうけど、
発注する側になると、俺が理解できるもの、っていうあいまいな基準じゃ
だめなんだよね。
なんかいい本ある?
>>
670
横線を1本引き、その左端に仕様書、右端にコードと書いてみて。
設計書とは仕様書とコードの中間の位置に存在する物だよ。
でも中間の位置の設計書をなかなか書けない。
日本語でコードもどきを書いてしまう人がいるけど、
それじゃ右端とほぼ同じ。
仕様書からのコピペだらけの設計書を書いてしまう人がいるけど
それじゃ左端とほぼ同じ。
672 :
仕様書無しさん:2014/05/09(金) 11:25:30.46
>>670 本とは
薄い内容で印税を稼いだり
本の著者ですとハクをつけてコンサル業務で火事場泥棒したり
本に書かれた手法を取り入れたCASEツールを売りつけるためのモノだよ
673 :
仕様書無しさん:2014/05/09(金) 11:45:30.08
ありがちなパターン
関数仕様書のテンプレートを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年マインドコントロールされちゃってるんで
碌な大人にならない。古典は日本の伝統だとか、源氏物語がすぐれている、とかいうのよ
社会科と古典が好きなのはプログラマに向いていないね。
数学好きがいいよ。源氏物語の話なんかあほらしくて聞いていられんね
677 :
仕様書無しさん:2014/05/09(金) 13:30:01.62
>>676 何の話をしてるか意味不明
俺ば、国立大の情報系の学部を出た娘とちゃんと書いたのに
678 :
仕様書無しさん:2014/05/09(金) 13:52:33.68
客先に送り込む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キロ月
なんか面白いこといってるつもりなのか(´・ω・`)
たしか、ここは雑談スレだったよね?
壊れたプログラマースレですがなにか
686 :
仕様書無しさん:2014/05/09(金) 16:31:04.74
>>683 人月払いを求めるゲスなソフトハウスへの皮肉だよ
対価は本来、成果物の価値に対して支払うモノ
しかし価値を定量化する事が難しいから次善の策として成果物の量で金を払いたい
人月もキロ月も金払う側には関係の無い話なんだよ
オマエの体重がどうでもいい事と同様に
コードや設計書を書くためにオマエが何時間働いたかなんて
知ったこっちゃねーんだよ
687 :
仕様書無しさん:2014/05/09(金) 18:00:38.69
>>686 人月請求する会社は生産性向上の意欲ゼロ
生産性の高い設計書の書き方やプロセスを教えても何だかんだと屁理屈をこねて従わない
生産性が上がったら売り上げが減ってしまうからw
>>686 んじゃ人月より妥当な定量化手段出せよ。
ソフトウェアを作るのにかかる平均的な技術者の労働量ってのは妥当な数値だと思うが。
顧客から開発を打診されたら簡単ですよと答え
とりあえず開発に着手する
発注先を切り替えられない時期になったら
顧客のせいにして案件がいかに難易度が高いかを力説する
やりかけの案件は人質
保守に役立つ設計書を残してはいけない
残してしまったら別の会社に切り替えるハードルを下げてしまう
という事だよね
690 :
仕様書無しさん:2014/05/09(金) 19:18:22.18
>>688 Line単価×Line数の方が人月よりまとも
691 :
仕様書無しさん:2014/05/09(金) 19:21:53.77
692 :
仕様書無しさん:2014/05/09(金) 19:32:11.05
>>688 >
>>686 >んじゃ人月より妥当な定量化手段出せよ。
>ソフトウェアを作るのにかかる平均的な技術者の労働量ってのは妥当な数値だと思うが。
キミが言ってる平均的な技術者の労働量が次のモデルを使うという意味なら
仕事の量を労働量、成果量のどちらで表現しても同じ事
平均的な生産性での労働量 = 成果量 / 平均的な生産性
693 :
仕様書無しさん:2014/05/09(金) 19:48:23.03
いかにも出世しそうなヤリ手タイプのSEがやってきたら要注意
そいつのヤリ手な能力はボッタくる事に注がれる
出世コースから外れそうなタイプだがソフト開発が大好きなタイプのSEの方が
リーズナブルな金額に収まる
694 :
仕様書無しさん:2014/05/09(金) 20:41:07.48
実績工数で金を払って良いのは少数精鋭のチームを作ってくれる場合だけだよね
695 :
仕様書無しさん:2014/05/09(金) 21:14:18.68
>>693 補足しとくけど
ヤリ手SEがボッタくると言っても水増し請求するわけじゃないけどね
上手く回せば3人で開発できる案件に10人投入しようと画策するパターンね
別の案件が終わって手が空く人間を全員ぶち込みたくて必死に仕事を増やそうとするヤリ口の事だよ
頼んでいないのに仕様追加の提案をしたり
別件で起こした重大不具合を分析した結果だと称して
重厚長大なプロセスを提案したりしてプロジェクトを「 おおごと」にしてくるヤリ口ね
696 :
仕様書無しさん:2014/05/09(金) 22:43:46.61
>>670 最近組込系で少し流行っているシステムxxという会社の清水某というヤツの本は絶対読んじゃダメ
ウォーターフォールを更にお役所仕事化したコードすぐに書かせない我流の方法論を広めようとしている
アジャイルとか海外でも認められている方法論の勉強をした方がいいよ
ヤリ手のSE君(ピンハネ手配師君)にとってアジャイルって禁句だよね?
>>695 実績払いでも水増し請求があるよ
今手元にある4月作業分の請求書の請求額が833万3千円
これ悪魔の数字です
1億円を12で割って千円未満の端数を切り捨てるとジャスト833万3千円w
なんでしょね? 実績払いなのにこのキリが良すぎる請求額
偉い人から本年度の売上ノルマを言い渡されたのかな?
> 端数を切り捨てるとジャスト
端数がある時点でジャストじゃない
最終月は切り捨て分もぶっこむだけだろ
701 :
仕様書無しさん:2014/05/09(金) 23:58:27.32
>>698 上司か営業か何者かの強烈な意志を感じる数字だよね
で、設計書が開発に役立った事は無い
という結論でおK?
>>673 関数仕様書なら入出力が記述されてれば十分。
最近は自動生成させるのが普通でしょ。
>>703 関数仕様書とは関数の仕様を書いた文書
仕様をどうやってコードから自動生成するの?
>>704 コメントだけ書いて、処理実装してないコードから生成すれば?
>>705 テキストファイルの一種であるソースファイルから自分で書いたテキストを抜き出す事を生成と言ってはダメだよ
>>690 言語によっても書き方によっても変わる数値だろそれw
オブジェクト指向使ったら、関数型使ったら、このフレームワーク使ったらでどんだけ変わるか正確な数値持ってるのかお前は。
>>692 だからその成果量をそれなりに表す数値が他にあるなら教えてくれ。
708 :
仕様書無しさん:2014/05/10(土) 02:17:14.69
>>707 1ヶ月で160h働くから幾ら支払って下さいと
人材派遣みたいな請求をして恥ずかしくないの?
>>708 だから、他に仕事量を見積もるいい指標あんのかよ?
お前ら原価計算って分かってるの?
代案も出さずに否定だけするのはカスのやることだろ(´・_・`)
EVMをちゃんとやるなら、人月でも可。
丼勘定やKKDじゃ限界が低いって言う、当たり前の事を言い換えただけのものだが。
712 :
仕様書無しさん:2014/05/10(土) 03:21:55.19
なんか舌足らずの奴ばかりで結論が良く分からんなw
要求仕様に対し金額を見積もり
これ以上は請求しませんと事前に請求額を確定する話なんだよね?
ステップ数で見積もるのが某社のやり方
あえて関数化しないという方法が使えたり
設計書は契約のために、客に見せるために必要で。
開発に使うためのものになっていない。
>なんか舌足らずの奴ばかりで結論が良く分からんなw
俺もよく分からんかったのだが「丼勘定やKKDじゃ限界が低いって言う、当たり前の事を言い換えた」
という発言、KKDという手法を分かるか?
経験と感と度胸の略だな。じつはこの手法はスピードが優れている。
ここからみると、何をチンタラやっているだろ、としか思えない
>>713 社内のコーディング規約があるんですぅーと言い張ってやたら改行するバカな会社がいる
例えばこう書けば3行で済むのに
if( ) {
} else {
}
こんな書き方をして6行も使うw
if( )
{
}
else
{
}
これって成果量を多くカウントするための水増しだよねw
>>714 >設計書は契約のために、客に見せるために必要で。
>開発に使うためのものになっていない。
その設計書を見せられる客も迷惑してるのでは?
>>716 その書き方に関してはどっちがいいかなんてのは昔から議論になっていて
今だに決着がついていない事案なので、相手をバカ呼ばわりするお前も
無知すぎてバカだよ。
>>718 木を見て森を見ずの頭悪い奴がやたら改行を入れたがるんだよ
百歩譲って改行した方が局所的に読みやすくても
コード行数が増えるとパソコンの画面で同時に表示できる範囲が狭くなる
設計書なんて書いてはいけません
コードを読みやすくしてはいけません
ソフト会社にとって自殺行為です
ソフトの保守性を上げたら単価の安い他社に切り替えられてしまいます
開発中のソフト、開発済のソフトは人質です
開発の継続や保守のために顧客は金を払わざるを得ません
我が社がいなけりゃ顧客の業務が止まる、我が社がいなけりゃ製品を出荷できない
顧客をそんな状況にいかに追い込むかがSEの腕の見せ所です
技術者の良心? そんなモノは今すぐゴミ箱に捨てて下さい
所詮、IT土方からピンハネする手配師なんです
割り切りましょう
という事だよね?
>>721 >ソフトの保守性を上げたら単価の安い他社に切り替えられてしまいます
簡単にコピー出来るレベルのを作ってる連中の世界では、そうらしいね。
>>721 コードの読みやすさなんて主観だからなあ。 カッコの位置を同意してもらえなかった
くらいでそこまで顔赤くなっちゃうの?
>>724 おまいのコードのこだわりがそこ止まりだから
括弧の位置を問題にしちゃうの
726 :
仕様書無しさん:2014/05/10(土) 12:42:22.73
>>725 ある事を話題にしたらその事しか関心が無いと勝手に決めつける
キミ、変な人だねぇ
>716
いまだにステップ数(笑)で評価してるのも問題だな
つーか個人的にはわりとわかる
for (略);
{
略
}
と書いて想定通りに動かず小一時間悩んでるアホを見たときはワロタ
728 :
仕様書無しさん:2014/05/10(土) 12:52:43.21
>>716 トークンの数をカウントするツールを作るといいよ
改行を増やして行数を水増ししてもトークンの数は増えないから
改行はステップ数に含まれないのでどうでもいい。
重要なのは一点。コードの読みやすさ。じゃあ改行を入れるのと
入れないのどっちが見やすいかといえば、それは、コードの内容による。
小説を考えればいい。なんでもかんでも改行する/しない と
決められるもんじゃない。その時々でどちらがいいかは変わる。
で、それとは別の話として、行数は短い方がいい。1行、2行を目指すという極端な話ではなくて、
一画面に収まる方がいい。一画面って何行だよ?って言うかも知れないが、行数ではなくて本当に一画面。
なぜなら、スクロールの必要がないのが目的だから、視線移動だけで関数が見渡せるのと
スクロールしないと見渡せないのでは大きな差が出る。
当然 見ること、見やすさが重要なので、見えないほど小さいフォントサイズにするとか
ワイドディスプレイを立てにして、視線移動だけで見れるぞ(疲れるけど)みたいな反論はくだらない。
結論として、この書き方が行数短いのでお勧め。
for( ) {
}
このやり方であれば行数が短いくて、さらにforやifなどが出てきたら、視線を下におとして、} までがブロックだとわかるし、
} が出てきたら視線を上に上げていって、文字にぶち当たった所がブロックの開始だとわかる。
うんー
for (int i=0; i< Size; i++);
{
略
}
何で動かんかわかんないなー
UMLのシーケンス図の表記法を使いシーケンス図に分岐やループをやたら書きまくるのは止めて欲しいな
その分岐やループの大半はそいつが担当するコンポーネントの振る舞い
他のコンポーネントの担当にはどうでも良い話が多い
お前が担当したコンポーネントの設計書に書いときゃいいだろと言いたい
> UMLのシーケンス図の表記法を使いシーケンス図に分岐やループをやたら書きまくるのは止めて欲しいな
必要なものすべてを書くと、場所をとるだけだからね。
図には最小限の重要なものだけを書く。あくまで概要書。
それを設計書とみなしてはいけない。
結局のところ、意味がわかればいいので、わざわざ図を作る必要は限られる。
あ、意味がわかるっていうのは当然技術者にとってという意味。
素人には馬鹿向け図として別に作ればいいが、
そんなのは端折って作った適当なものだから、
そういうのを参考して作るような開発はしていけない。
734 :
仕様書無しさん:2014/05/10(土) 13:18:19.69
>>729 コードレビューする側になると間延びしたコードは嫌だよね
レビューしてもらう側の人はあまり気にならないのかな
>>734 最近ね、コードはレビューする人のことを考えて作れって言ってるよ。
ちゃんと動くか、バグがないかっていうのは、当たり前にできてる話で、
その上で、レビューしやすいコードになっているかが重要。
「複雑なものを作りました、あなたにこのコードがよめるか?ドヤ!」
っていうのはだめ。
「これで分かりますか?読んでいただけますか?読みにくいなら直します」
これぐらい謙虚じゃないといけない。
読みにくいコードは、バグを見逃すし、レビューで読むのに時間が掛かるし、
後日修正しようと思った時に、また読みにくいものを読まないといけない。
百害あって一利なし。
まぁお前らたまには自分が数年前に書いた物とか見直せ。
今でも3年前のコードとか見ると稚拙さをかんじるわ。
進化してるのを喜ぶべきか今だに未熟なコードを書くのを嘆くべきか。
>>735 顔真っ赤にして長文書いてるんだろうけど、読みやすい読みづらいなんて主観の
問題でしかなんだからあなたの思いなんてどうでもいいんですよ。
必要ならコーディング規約を決めてそれに合わせる方が全員にどう書くかの
ガイドラインが出来て読みやすくなるんだから。 自分の主観でこの書き方は
読みづらいって思うコーディング規約なら、コーディング規約を決めれる
ポジションになればいいだけ。個人的には2タブがいいけどエディターだと
4タブとか8タブが標準だよねとか言い出したらキリがない。
>>732 後工程でやる事についつい入り込んでしまうパターンだな
大枠をまず決める工程でどこかのパートの詳細がふと気になってしまう
そんな時はメモっておいて後日そのパートの設計書に反映すればいいのだけど
それをぜず前工程の設計書に書いちゃうw
そして一度書いちゃうと消せよと言われても引っ込みがつかなくなって
大事な事なんですと言い張るw
>>736 自分は進化だと思っても変化しただけかもよ
もしかすると退化してたりして
>>737 > 顔真っ赤にして長文書いてるんだろうけど、
なんで、この文を入れた?w
ばーかばーか、とかお前の母ちゃん出ベソって
言っているようにみえるんだがw
そのまんまの意味じゃね
>>719 お前バカだな
1ページ内に情報が少ない(纏まっている)方がコードとして優れているんだよ
1行にたくさん詰め込んで悦に浸ってるのは馬鹿
743 :
仕様書無しさん:2014/05/10(土) 15:28:34.68
>>742 密度を下げればその分ページが増えてしまう
そんな簡単な事に気がつかない
見て森を見ずクン
744 :
仕様書無しさん:2014/05/10(土) 15:47:39.57
>>737 >顔真っ赤にして長文書いてるんだろうけど、
鏡を見たのかな?
745 :
仕様書無しさん:2014/05/10(土) 16:06:33.83
表で表現する事にexcelを使うのは良いけど
excelを縦横無限大の方眼紙として使ってる設計書は何故か内容もイマイチ
Wordを使って書かれた設計書の方が内容もちゃんとしている傾向がある
気のせいかな?
746 :
仕様書無しさん:2014/05/10(土) 17:29:54.83
なんだページって
普通プログラマーならクラスとか1処理っていう単位で見ないか?
色々詰め込められた部屋より殺風景な部屋の方が
何があるかはっきりしているし、
情報量を多くしたほうがいいときとか、
少なくした方が見やすいとか状況によって変わるだろ。
くだらん。
747 :
仕様書無しさん:2014/05/10(土) 17:40:00.09
かっこの位置はやっぱこうだろ
for()
{
略
}
かっこ内のコードが多くなるとどれに対応するか目視で追えなくなるんだよ。
改行入れるのがめんどくさいから
for(){
}
こうすることがおおいけどな
こちらは擁護できない木を見て森を見ずクン
if( )
{
}
else
{
}
> かっこ内のコードが多くなるとどれに対応するか目視で追えなくなるんだよ。
別に括弧の位置がどっちでも、
同じように追えるけど?
前から疑問なのは、なぜブロックの括弧の対応を追いたいのかってこと。
知りたいのは、どこからどこまでがブロックになっているかで、
別に括弧はどうでもよかろう?
閉じ括弧 } に対応する、開始単語を追えばいいじゃないか?
俺はいつもそうしているが?
751 :
仕様書無しさん:2014/05/10(土) 18:28:45.83
行数水増しが見破られ土方発狂
752 :
仕様書無しさん:2014/05/10(土) 19:14:25.40
だったらこれでいいじゃん。
なんで括弧使ってるの?
ブロック対応してるしこれでいいよね。
if()
test();
;
>>752 それ一行だけしか使えないし、
ミスが多いだろう?
行数とは別の問題が発生しているから
話が全く違う。
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
って結果表示された
756 :
仕様書無しさん:2014/05/10(土) 19:26:16.68
ああ、そういうことか!
>>754 あの、違う言語の話をしてるの?
文法が同じ言語において、
改行をするかどうかの話をしているのですが?
758 :
仕様書無しさん:2014/05/10(土) 19:31:24.29
すいません。
僕
sub test()
end sub
これしか使ったことがないから勘違いしてました。
759 :
仕様書無しさん:2014/05/10(土) 21:04:51.80
建設土方はセメントと鉄骨を減らして手抜き工事
IT土方は無駄に改行いれて行数増やして水増し請求
>>739 その時じぶんがイイと思う方向に行ってればいいんじゃ無いかね
文書書きたくない人は、夏休みの宿題やりたくない症候群だな
いいわけが幼稚。
プログラマの仕事は文書を書くことだ。
観念して書け。
必要な物なら書きますよw
必要ないから要らないと言ってるだけで。
763 :
仕様書無しさん:2014/05/10(土) 21:55:32.33
重厚長大プロセスを採用しお役所仕事をして
小規模の案件で多額の費用を客から毟り取るのがSEのお仕事です
客が金を出し渋ったら
品質ガー
保守性ガー
と建前論を唱え不安を煽ればいいのです
設計書なんて書くのは簡単
上流工程の成果物に書いてある事を何度も蒸し返えせば幾らでもページ数を稼げます
コピペですから2次請に丸投げして大丈夫
2次請の単価を叩けば顧客に提示した単価との差額が丸儲け
おいしい商売です
>>762 エスパーかなんかなの?
少なくとも使わなくなったら必要だったか不要だったかは判断できるけど、
先のことなんて何が起きるか断定できんでしょ。備えあれば憂いなしと
いうし、自衛のためにも用意できるなら用意するものだよ。
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
ページって書いたのは1スクロールの事で
画面に表示できる範囲程度で一つの関数を収めるべきって意味でした
なので1関数と読み替えてください
コード量水増しって、そんな物差し使ってるから馬鹿なんだよ
見た目にわかりやすく、意味が明確で、状態が少なく、機能が完結なのが綺麗なプログラム
スコープの書き方としては括弧のインデントが揃ってる方が分かり易いけど、基本的にはその文化圏(言語としての標準や、会社など団体としての標準)に合わせるべき
>>745 気のせいじゃない。
Excelで仕様書や設計書を書くヤツはもれなくDQN。
Wordでなけりゃ、まともなものは書けない。
771 :
仕様書無しさん:2014/05/11(日) 00:59:27.96
>>769 キミの会社は投入工数とコード行数のデータを会社として管理してないの?
それCMMで言うとレベル0(混沌とした状態)というヤツじゃない?
>>771のPJには、リファクタリングって言葉は無いんだろうな。
773 :
仕様書無しさん:2014/05/11(日) 01:14:21.49
完璧な物差しじゃないから物差し要らねーと考えてはダメ
各々のプロジェクトで1人月あたりどれだけコードを生産したか会社として管理した方が良い
まずは生産性を計測しデータを蓄積すること
そしてそれを見積りや計画立案に活用する事
それができるようになったらファンクションポイントとか次のステージに進む
774 :
仕様書無しさん:2014/05/11(日) 01:19:10.49
>>772 リファクタリングも生産活動の一部だから
途中でリファクタリングする前提で納品時にコード何行納品するか予測すればいいだけ
775 :
仕様書無しさん:2014/05/11(日) 01:25:05.50
良い子の皆さんはコードのリファクタリングをするならテストを自動化してね
>>771 投入工数とコード行数に何の因果関係があるのが教えて欲しい。
そんなもよは客からの要望次第で何倍にも変わる。
過去の実績ってのは、同じことを繰り返す仕事なら役に立つけど、プログラマには当てはまらない。
過去のデータで見積もる位に似た案件なら、そこを自動化して稼ぐべき。
つまり、やったことある事は繰り返さない。
>>773>>774 う、うわぁwww
これ真性の人やwwwww
ループをマクロ展開してろよカスwwwwwwwwwwww
>>774 > 途中でリファクタリングする前提で納品時にコード何行納品するか予測すればいいだけ
お前、実際に仕事したことないだろ。
底辺の連中のCMMとか言っても仕方泣くね?
まるでリファクタリングの意味がわかっていないな
崩れるまで積み上げる仕事を頑張ってくれよな
俺は崩れないように積み上げつつ積み替えて行くから、口出さないでくれな
人材派遣だからline単価を出さなくて良い
派遣だから元々要求仕様書に対し見積なんてしていない
派遣だからコードをリファクタリングしようが何しようが
今月は何時間働いたから幾ら払えで済んでしまう
工数見積もりしたとしてもそれは派遣先の会社の開発計画であって
その工数を超過しても責任を問われない
投入工数とlineを管理されているかもしれないけど派遣先の会社がやってる事だから良くわからない
>>780 リファクタリングするコストをどうやって客に請求しているの?
確定見積もりする時にリファクタリングのコストも載せている?
もし載せているならどうやって計算しているの?
派遣とか実質派遣でなく本当に請負型(見積もり時に請求額が確定させるやり方)で仕事してるなら答えてみなよ
多分答えられないと思うけど
783 :
仕様書無しさん:2014/05/11(日) 05:48:16.88
趣味グラマはリファクタリングし放題でうらやましいなー
俺も趣味を仕事と言えるような大きい男になりたいわ
>>745 Excelできれいにシーケンス図書いてたのはちょっと感動したわ
全くいらん技術だが
そういう人は設計書が文書ってことを理解してないからね
そりゃメモ書きの延長にしかならんよ
>>771 コード行数管理って、初めて聞いた。
俺はWeb屋だけど他ではそうゆうことするんだー
あ、別に悪い意味じゃなくて、、
でも行数って水増しできません?
規約で縛ればある程度は防げるかもだけど
設計書要らないと言う人は、小さいシステムしか作ったことないからでしょ。
1人で作るにしても、最低限としてお客様との仕様確認書は必要だと思うけど。
何も要らないとか言う奴はさすがにプロではありえん。
工数とコード行数を管理して何になるんだろうか
>>782 > リファクタリングするコストをどうやって客に請求しているの?
お前馬鹿なの?
リファクタリングっていうのは開発そのものだよ。
開発コストに含まれてるに決まってるだろ。
何かを修正するとき、既存のコードを
一切修正してはならないって、縛りでも有るの?
>>784 流石に、Wordは無いけどな。
仕様・設計には、それ用のツールを使うべき。
>>790 ↓ね。工数は当然だろ。工数と行数をセットで管理?でもしてるのかなと思って。
>>771 >キミの会社は投入工数とコード行数のデータを会社として管理してないの?
>キミの会社は投入工数とコード行数のデータを会社として管理してないの?
>それCMMで言うとレベル0(混沌とした状態)というヤツじゃない?
管理していない。いわゆる属人的というのだな。
プログラミングというのは、三流には分からないもの、それでいいよ
設計書さえ読めば誰でも実装出来るレベルで詳細設計書を作れと言われる。
んでもそんなもん俺には作れないわ。実際、誰も作ってない。
こういう馬鹿な事言う奴ってほんと何なんだろうか。
そんなものに価値があると本気で思ってるのだろうか。
まぁソースコード1行レベルで文章書いてけば作れるっちゃー作れるんだろうが…
品管を通すために設計書が必要
何しているのか分かりにくいと言われてもこうしないと品管を通らない
文句があるなら品管に言ってくれ
と仕事をしながら誰もが思っている
思ったことがない奴は幸せ者
あとリファクタリングじゃ金とれない
金がとれるのは機能追加だけだ
未だにフローチャート書けと言われる。あんなもん時間の無駄だと思うんだが…
>>794 > あとリファクタリングじゃ金とれない
> 金がとれるのは機能追加だけだ
当たり前だろう?
機能追加でリファクタリングもやるんだよ。
分けて考えるな。
機能を追加した時、コードが複雑になるなら
そこを修正するだけのこと。
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までならないといけない。
(もちろんそれ以下でやってもいいしやるべきだけど、属人化状態だから、技術力が高い人しかできない)
>>799 君の会社はCMMレベルでいうとどのレベルですか?
できないできないっていってるのは
単に、成熟度レベルが低いだけでしょ?
知らんがなw うちはレベル低いから出来ないんだ!って
叫ばれても。ならレベル上げろよってだけの話。
>>799 今やってる開発で次の開発の仕込みをしとくんだよ
と言ってもルールだなんだと縛りがきつかったら難しいかもしれないけど
今やることで精一杯。
改善なんて出来ないんだよ!
>>801 さあ?その会社の人間じゃないから知らんが
当時の現場を見た感じだとレベル1だったな
人格攻撃ならお断り
CMMなんて土方仕事しか評価出来ないしこんなもん無意味。
まぁ土方会社に勤めてるならこういうの大事にするのもいいかもね。
ステップ数で商売するのって
自分が無能だって自慢して歩いてるようなものだよ
作業工数が10人月で、人月屋(ステップ屋)さんだと1000万円でーす!って感じだろ?
でも、このシステムでも3億儲けられるなら、1億でも売れるわけで。
結局価値を生み出せないから、客が詳細設計までしたものを翻訳する「翻訳料」しか受け取れていないのが「ステップ屋」
そんな馬鹿が「うちの会社ば成熟してる!」とか騒いでて、ブラック社畜なんだろうけど、日本人の質の低下が本当に心配になる
そんな幼稚な文章をよく恥ずかしくも無くたらたら書けるな
>>802 相談してるわけじゃないのに知らんがなと言われても知らんがな
そういうこともあるよねって話
レベルが低いのは同意、マネージャーが気の毒になるくらいに
>>794 >品管を通すために設計書が必要
組織が自己保存のために、無意味な作業増やしてる可能性あり。
>あとリファクタリングじゃ金とれない
客から直接取れなくても、内部コスト低減には役立つ。
問題は、リファクタリングによる改善は、品管の手柄にならい事。
品管、設計書、仕様書の本来の共通点は、トラブル防止・収束なんだよな。
売れなかったり、無事故の時には問題にする人は少ない。
書類にしても、進め方にしても危機管理の一部として考えてるかどうかだ。
まぁ一番の目的は現場で役に立たない年寄り共に仕事作る事なんだけどなw
>>800 それって、レベルの高いところで働いてるひとほど偉いの?
工場とか非常に高そうだけど。カイゼンとか。
>>800 ただ単に「リファクタリングが通常の開発プロセスへ自然に含まれている」だけなら、
レベル3で十分に達成できる
CMMで難しいのは、レベル4の「定量的に管理された(リファクタリングの)正確な測定」
リファクタリングは開発プロセスの一要素にすぎないことを忘れることなかれ
んだからこういうのは土方仕事しか評価出来ないんだよ
>>807 パッケージ・サービス開発と受託を一緒にしてるバカはっけーん。
まぁ受託しかやらないのを堕としてるならまぁありっちゃありかな
>>816 > リファクタリングは開発プロセスの一要素にすぎないことを忘れることなかれ
重要な一要素な。
設計レベルの話だから。
リファクタリングをコードをちょこちょこ
修正することだと思っていたら大間違いだからなぁ。
正しいリファクタリングをして、
その前と後で何が違うかわからない人は、
正しいソフトウェア開発を知らないと言ってるのと同じ。
そういう人は大抵動けばよしと思っているんだよ。
じゃあなんでデスマってるのかと。
821 :
仕様書無しさん:2014/05/11(日) 13:49:11.61
>それって、レベルの高いところで働いてるひとほど偉いの?
工場とか非常に高そうだけど。カイゼンとか。
偉いよ。で日本が世界に通用しているのはそためだ。
こういうのは韓国や中国が不得意とする。またインドもしかり
インドに教えに行くと、この人にもあの人にも同じことを教えるなければなならない
彼らのポリシーとして、知っていることが自分を守るすべ。
だから、他人には教えない
んー、なんつーか、こういうのは出世の手段の一つでしかないんだよ。品質だのCMMだのはね。
現場で本当に役に立っているかなんてのは二の次。
それが分らない馬鹿があーだこーだ議論してる。
>>822 で、お前の現場で役に立っているものは何?
現場を知らないのはお前なんじゃねーの?
もしくはお前の現場にソフトウェア開発をちゃんと知っている人がいないだけ。
改善をしないとこほど、
今の仕事で手一杯になってるよね。
もうこのCMM馬鹿飽きた
お前が馬鹿なんだよ。
CMMという用語が嫌いなら、
改善と言い換えればいい。
お前の会社、改善なにかやってるか?
一年前とくらべて、やり方は成長したか?
してないだろう?
会社は成長してないですが
会社は無能なので、あまり働かれると迷惑なのです
私と私の周りは成長してるのでそれで良いです
会社に骨を埋めるつもりはないので
その成長の段階にレベルを定義しただけなんだよね。
CMMって。その根本的な所を分ってないから
馬鹿にされるんだよw
>>827 ん? 独立でもするの?
今の会社に骨を埋めなくても、
骨を埋める会社が変わるだけの話でしょ?
ステップ数という文言を見ると発狂するような人がよくいるけど、他人に申告するか
どうかはともかくとしてタイピング速度なんて早々変わらないのだから物理的に
何行書けるかってのを知っておくのは悪くないよ。
品質管理なんかのステップ数であれこれ言ってくるので嫌なのはただ単に、
ステップ数以外のパラメーターもあるだろってのと、現実に出た値より、
期待値を優先させようって点だな。 お前ら確率統計も知らんのかよってのが
いすぎなんだよな。
>>819 CMMが対象とする開発プロセスとは、
システム設計から総合テストにおよぶソフトウェア開発工程の全行程だ
実装設計レベルではリファクタリングが重要であっても、
CMM全体から見れば、実装設計は単なる一工程にすぎないし、
リファクタリングも実装設計レベルの技法の一つにすぎない
> 物理的に 何行書けるかってのを知っておくのは悪くないよ。
物理的なら、アルファベットで1分間に300文字ぐらいだから
一行100文字フルにあったとして、1時間で180行
1日8時間で1440行だね。
まあ1行に100文字も書くことはなくて、インデントとか
空行とかだと極端に量は減るから、
物理的で言えば、1日で1万行は超えるだろうね。
で、物理的な速度に何の意味があるの?w
CMMって要するに、安定して手に入る労働力を使って安定した成果を出せるかどうかの指標だよね。
安定して手に入る労働力という評価で満足してる労働者なら従ってみるのもいいんじゃない?
>>831 そりゃそうだろ?
そもそもプログラマの仕事ってのは
システム設計から統合テストに及ぶソフトウェア開発工程の
全工程なんだから。
プロならどの工程でも、改善していかないといけないよ?
この工程は改善しなくていいとかありえない。
>>833 「CMMに従う」ってのはおかしい話だよ。
CMMはどういうふうにやれ、なんてことはひとことも言っていない。
CMMがやり方を定義しているわけじゃない。
開発工程全般がどういう状態にあるか?という指標。
改善も何も行われていない、いきあたりばったりな開発なのか、
計測し問題点を認識し、それを改善するという繰り返しが
ちゃんとできているか。
あなた達、ちゃんとプロらしく仕事出来てる?
私が判定してあげる。あなたのレベルは〜 これがCMM
まあ参考として
http://monoist.atmarkit.co.jp/mn/articles/0512/20/news103_2.html > つまり、プラクティスの具体的な実行方法の選択は、実行者に委ねられている。
> プラクティスは、ソフトウェア開発の「要求」と似ている。要求は1つでも実装方法はいろいろある。
> また、CMMIに取り組む目的や達成スケジュールに応じて、実装の“深さ”にもメリハリを付けられる。
> 例えば、工数と費用を精緻に見積もろうとすると、それなりの工学的な手法が必要になる。
> それまでカンで見積もっていた現場へそうした手法を押し付けても負担になるだけだ。
> レベル2〜3の段階なら、既存のやり方で間に合わせ、徐々に手法を変えていっても問題ないのだ。
> 何しろ、CMMIは“何をどのようにしろ”とは規定していない。
> それどころか、いったん定義したプロセスであっても、「プロセスQA(品質監査)」により、
>現場に合わなかったり過剰な負担が掛かったりするのなら見直すように求めている。
>CMMIは意外に柔軟なガイドラインなのである。「CMMIの導入で失敗しやすいのが、
>担当者が本を読んで自分でプロセスを決め、頭ごなしに現場にやらせようとしているケース。
>CMMI教則本を額面どおり受け取り、メリハリを付けずにすべて適用したら、
>それは大変なことになる」(日立ソフトの臼井氏)。逆に、CMMIに取り組む目的を明確にし、
>目的に沿って最も効果が表れるポイント、勘所を押さえる必要があるのだ。
>>821 > インドに教えに行くと、この人にもあの人にも同じことを教えるなければなならない
問題ないのでは。
欧米では新入りでも利用できるマニュアルが揃っていて、
職種によって新入りのオリエンテーション内容も決まってるのが普通だし。
>>837 同じ業務を継続することが前提になってるね。
>>839 同じ業務? それが許されるのはレベル2の段階だね。
http://www.it-mc.jp/article/13208863.html CMMでは、IT業者のソフトウェア開発プロセスの成熟度を、5段階に分けています。
レベル1
仕事のやりかたが個人によって違い、同じやり方を反復できない
レベル2
同じ業務内容であれば、個人レベルでは決まった手順で反復できる
レベル3
仕事のやりかたが文書化されており、他の社員でも同じ手順で行える
レベル4
仕事のやりかたが全社的に管理/標準化されている
レベル5
仕事のやりかたが継続的に見直されており、全社的に最適化されている
例えばWeb開発と、組み込み開発では行数を比較しても仕方ないと思うのだが。
Webだと比較的コーディングが多くなるのに対して、組み込みだと一ヶ月で
1000行書かないことも珍しくない。
ソフトウェアは同じ業務は繰り返さないものだから
CMMレベル2程度じゃダメだよ。
業務は変わるからこそ、適切なプロセスと計測
そして改善までともなったレベル5を目指す必要がある。
ここまで到達すると、仕事をしながらどんどん仕事が楽になっていき
それでいながら開発スピードも向上する。
常に改善し続けているのだから当然。
一人が書ける行数にそんなに違いはないのだから、
システムを実現するのに必要な行数を減らす必要がある。
システムを実現させるのが目的であり、その中間にあるものは
できるかぎり少ないほうが良い。
設計書もシステムを実現させるのに必要な物は
作った量よりもはるかに少ないだろう?
設計書が開発に役に立ったことが有るかほんきで考えてみよ。
初めてやる仕事について
「仕事のやりかたが継続的に見直されており、全社的に最適化されている」
なんてアホなこと言ってられないわけでねー
レベル1の中で試行錯誤しながらもがくしかないんだよ。
メンテ業務を行うようであれば、そのときにレベル2か3に持っていければいい方。
>>832 >で、物理的な速度に何の意味があるの?w
実際に手を動かして書き始めてから書き終わるまでの時間が分かれば、
コードを書く以外のことにどれくらいの時間をかけれるのか判断が出来る。
仕事だと無限に時間を使ってもいいわけじゃないからな。
>>845 一日に書けるコードの量を100行だとする。
物理的にかける行数は10000行。
つまりコードを書く以外のことに一日8時間の99%を使っている
480分中、4.8分がコードを書く時間だ。
なるほど、コードを書くのに約5分、残り7時間55分が
コードを書く以外の時間だ。
判断できたが、これに何の意味があるの?w
コーディングという名前に反して、
コードを書いている時にかかる時間の大半は
読んで理解する量だよ。
だからコードが多ければ多いほど時間がかかる。
同じことを実現するのに、短いコードのほうがいいと言われるのは
書く量が少ないからじゃなくて、読む量が少ないから。
>>846 見積もりとかしないでコード書いてるの?
何時間掛けるかは見積もるだろうけど、
何行書くかとか見積もるのも普通なの?
全コントロール数がいくつで、一つのコントロールあたりn行だからこれくらい
とか見積もることが可能なものもあるっちゃあるけど。
同じようなくだらねー受託開発してる企業がCMMなんて言ってんだよ。
常に新しいものを生み出す現場でこんな事言ってる奴はいない。
行数云々言ってるのはジジイだろ
他の誰かが読むことを考慮せずに書くなら、プログラムなんてチャットと同じ速さで組める。
そんなコードに何の意味があるのかは知らん。
ステップ屋さんは一生ステップ売っててください
854 :
仕様書無しさん:2014/05/11(日) 23:10:45.74
1行書くといくらもらえんの?
松井秀樹は1打席400万のバッターとか言うけど、
凄腕プログラマーになれば1行10万とかもらえんのかw?
もらえるんじゃねーの?
ステップ数に女でもNTRたのかね。
誰から貰えるのかによるが
いいアイディアがあって、自分で綺麗に書いて、自分で儲けたら
1行10万の価値はありえる
ステップ屋()じゃ無理だけど
今までだと10数行のコードで30万(税込み)が最高かなぁ。
20行だとして、一行あたり一万5千円。
>>844 もうすぐ、ダーウィン賞を取れそうだな。
860 :
仕様書無しさん:2014/05/12(月) 01:12:16.92
ステップ数とかファンクションポイント法で見積もりできるのって、大規模開発とかじゃない?
昔SIやってたけど、ほとんど後付けで上司から催促されて計算してた。
まあ、期待した工数とるための根拠に使う以外の価値はないな。客も軽くだまされるし。
嘘の数字ならマネジメントにおける価値もないが、現場からの報告は嘘だらけなのが最大の問題。
やるならちゃんと管理しろ。現場と顔つき合わせろ。自分だけ休みたいなんて夢にも思うな。
つまり、大事なのは表面的な方法論よりも仕事に対するチームの姿勢なんだ。
861 :
仕様書無しさん:2014/05/13(火) 01:43:52.96
862 :
仕様書無しさん:2014/05/13(火) 19:54:25.13
技術者は貧民奴隷にならないために、
法律
経済
商業
を学べ
CMMのレベルがどんなに高くても、予算なし、納期なし、無能ばっかが集まれば必ず炎上する。
だからCMMなんか全然当てにならない。
他の認証規格も一緒。
ISOというのがあるけど、書類揃っていますか? という
そういう、くそ焼くにたたないのがはびこているが社会なわけ。
たてまえが必要なのよ
マニュアルがあり、その通り作業がこなせればいいというのと
プログラミングは正反対。
マックの店員がいやだから、プログラマーやっているよなもんだ
プログラミングは道がないところを開拓していくという感覚
そういうのを創造的という。
で、部下に俺の指示通りやれといっているようでは
プログラマーは育たんよ
>>863 > CMMのレベルがどんなに高くても、予算なし、納期なし、無能ばっかが集まれば必ず炎上する。
CMMのレベルが高いっていうのは、
「常に安定した品質のものを作ており、更に開発プロセスを改善し続けていること」を
満たしていなければ、レベルが高くナラニから、無能には成り得ないけど?
まあ、予算と納期という”外部要因"が悪ければ、
それや本人たちのレベルとは無関係に炎上するだろうさ。
> CMMのレベルが高いっていうのは、
> 「常に安定した品質のものを作ており、更に開発プロセスを改善し続けていること」を
> 満たしていなければ、レベルが高くナラニから、無能には成り得ないけど?
無能でも回るようにするためにCMMやらISO適用するんじゃね?
つーか、適用すると出来る人出て行っちゃうよ。
現場では、可視化されたメトリクスを開発者レベルで扱えるリーダ/マネージャが殆ど居ない。
結果、意識だけは高い裸の王様がカイゼンごっこをした挙句、無駄な規則を増やして開発プロセスが硬直化してしまう。
耐えかねて出来る人が居なくなるまでが一連の流れ。
>>866 関係ない奴が作ったルールは糞だよな
意味もなく守るコーディングルール並に糞
作ったやつは自分には糞ルールを適用しないから、糞ルールか放置される
開発者以外が開発部にルール強要する会社は逃げた方がいい
>>866 > 無能でも回るようにするためにCMMやらISO適用するんじゃね?
ISOはしらんけど、CMMはそういうものじゃない。
CMMは、このような仕様書や設計書的なものを作るんだ
とかいう決まりではない。マニュアルは用意されていない。ルールも決まっていない。
ルールがないのだから「ルールを守っていればだれでも出来るようになる」ものではない。
CMMが見ているのは、その企業、プロジェクトを遂行しているチームのレベル。
日々の仕事で精一杯、成果物にもムラがあるようなレベルか、
いまままでと似た内容なら、同じように作れるレベルなのか、
日々のプロジェクトをこなしながら常に検証、改善していけるレベルなのか
そういったレベルの定義をしているだけ。
>>867 > 関係ない奴が作ったルールは糞だよな
CMMの上位レベルでは、こういったルールを
変えていく能力が求められる。
CMMの上位レベルでは、決まりをたくさん作るのではなく、
その決まりが無駄だと思うならば、変えたりなくしたりする。
それが本当の意味の改善であり、実情に合っていないルールを作るのは
(作るのは大抵偉い人)CMM的なレベルで言えば下の方。
現場に決定権があればな
だいたいそんなアホな決まり導入してるところは、アホな上司と自分に不利益のない別のクソ部署が強要するんだよ
CMMとかどうせ後数年したら陳腐化してる
今の時代UMLやデザパタをドヤ顔して語るやついない
>>868 何年も同じような仕事をしてる組織には有効かもな。
>>868 定量的に成果物の評価をするなら、普通は明確なメトリクス用意する。
そして、周囲の状況や会社の意向、技術の進歩に合わせてメトリクスも変化すべき。
でも、環境変化や技術進歩で業務の性質が変わったときに適切なメトリクスを用意するのは困難。
メトリクスを変えるコストがそのまま対応コストに乗っかるんで、プロセスとしては本質的に現状維持へ傾くんだよ。
イノベーションは起こらない。
昔ながらの手順で淡々と進むだけ。
新しいことなんて当然出来ない。
そうなると、無能しか残らなくなるよね?
>>873 > 何年も同じような仕事をしてる組織には有効かもな。
逆。CMMの上位レベルは「変化できる組織」でないと
達成できない。
>>874 何を言っているのかわからん。
> イノベーションは起こらない。
> 昔ながらの手順で淡々と進むだけ。
> 新しいことなんて当然出来ない。
> そうなると、無能しか残らなくなるよね?
↑ これは言い換えると、CMMのレベルとしては
低いって評価されるってことだよ。
>>874 もしかして、改善にはコストがかかる。という話をしているのか?
そんなの当たり前の話で、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
という一個一個の手作業より
ループを使って変数をわたせるようにする。そのためのコントロールの生成だな
バグを起こりにくくする。手作業ではバグがおきるよ
879 :
仕様書無しさん:2014/05/16(金) 19:32:03.38
>たとえば VBで
>で(c++文法で書くと)
おまえもたいがいありえない
ISO は書類レベルでの査定、CMM は内容レベルでの査定、ということで良いのだろうか?
だとしたら、ISO は査定できても CMM を査定できる機関はほぼ存在し得ないのと思うのだが…。
仕様書(客に渡す資料)は製品の拠り所で、設計書(内々の資料)は当時の現場の状態を知る資料になる。
で、やっと安心してメンテできる。資料があるのと無いのとでは全然違う…かな。
881 :
仕様書無しさん:2014/05/17(土) 00:06:58.73
>>877 改善自体にコストがかかるんじゃなくて、組織的に改善できる体制を設けるのにコストがかかる。
技術力の差は視座の差に直結するから、画一的なメトリックスを用意しても、拾い上げる情報はそれぞれ違う。
ある程度技術力に差があると、そもそも議論すら成り立たなくなる。
そういえば、このスレでも、生産性評価にline数使って揉めてたよね?
そのあやふやな指標をコミットメントとして設定されたらどうなるよ?
こんなの氷山の一角で、可視化すればするほどコミュニケーションコストをはじめとする様々なコストが、出来る人に直接のしかかるわけ。
大抵の人は、諦めて無能化するなり出て行くなりしてしまう。
組織が均一化してくれば収まるんだけど、その頃には思考停止した無能しか居なくなってる。
定型業務を安い金で回すビジネスモデルには適切だけど、クリエイティビティを求められる業務では致命的。
もうCMMはいいよ。土方現場では大切にしておけばいいと思う。
> そのあやふやな指標をコミットメントとして設定されたらどうなるよ?
それが、実際に役に立つか検証して役に立たないとわかれば
やめるというのがCMMで求められている継続的な改善能力です。
間違えたルールを設定するのは、人間だれでも間違えるのだから
防ぎようがない。それを後から修正することが一番大事なこと。
>>882 逆じゃね?
土方現場にはCMMが導入されていることがないんだから。
あー、CMMを導入というのは正しくないな。
CMMは評価するものであって導入するようなものじゃない。
CMMという基準で評価してないだけであって、
プロセス改善能力レベルなんだから
どんな企業でもCMMのレベルに当てはめられる。
土方現場はCMMレベル0だろうけど。
>>885 どうせ数年後にはそんなものあったっけってなるから。
時間の無駄。
887 :
仕様書無しさん:2014/05/17(土) 00:52:19.32
設計書や仕様書の規格ってある?何を書けばいいとかの規約とか。
いままでお客様の都合にあわせて適当に書いていたから、
新人に教えようと思っても、何が正しいのかわかんないや。
>>875 組織の変化より環境や仕事の変化が十分遅いという前提に立ってるよね。
>>885 土方現場はCMMレベルゼロというのは正しい。
環境の変化が激しすぎて、レベル上げる頃には次の仕事に移ってる。
>>886 あったっけって何が?
CMMという言葉は消えても
「改善能力」はどの企業にも存在している能力だよ。
高いか低いかは別として。
>>888 > 環境の変化が激しすぎて、レベル上げる頃には次の仕事に移ってる。
やっぱりCMMわかってねーしw
CMMは仕事内容とは関係ない。そこにいる人達、チーム、の能力レベルの話。
なにせ「別の仕事でも安定して生産できること」が高いレベルの条件なんだから。
だから次の仕事に移っても関係ない。
反論したいなら、仕事ごとにノウハウが0の状態から始まるからとか言わなくちゃw
で、仕事ごとにノウハウ0から初めてるの?前の仕事の経験は生かさないの?
COBOLerが初めてのWeb開発に「俺たちにはノウハウがある」って言うのがCMMですか。
何この変な流れ
>>891 > COBOLerが初めてのWeb開発に「俺たちにはノウハウがある」って言うのがCMMですか。
次の仕事に移っているだけの話をしていたはずだが?
次の仕事に移っていてもノウハウはあるだろ。
それを活かして改善していけるのがCMMレベルが高いということを意味する。
で、なに? 何がいいたくてそんなレスを下の?
>>883 役に立たないと判った頃には既に手遅れだと思うが。
現実問題として、そこまでメトリックスに対する認知が固まる頃には、既にそれ自体が陳腐化していることが多い。
お前の所では、自ら学ばない人たちがその水準に並ぶまで何年も待ってくれるのか?
目的は改善活動それ自体ではなく、業績の向上だよね。
そのために組織内の出来る人間を押さえつけるのは本末転倒だよ。
>>890 仕事ごとにノウハウ0から始めるとか、よくある話じゃないか。
例えば、外から連れてきた経験者とかき集めてきたメンバの組み合わせで新規事業とか。
チームのクリエイティビティに強く左右されるビジネスモデルだと、測定と数値による改善は害悪になることも多いよ。
適切な判断を下せない人間が多数派の状況下で、合議制でプロジェクト進めるようなものだから。
ソフトウエア開発は概ねこの例に当てはまると思うけど、そもそもまともな事例を知らない人ばかりだったりして認知すらされないことも多い。
>>894 メンバーをかき集めるってそれ素人ってこと?
メンバーをかき集める側も、ノウハウないの?
過去に使ったフレームワークとか、そんなノウハウもなくて0から
スタートなの?
そりゃ、そのプロジェクト失敗するわw
ノウハウ消費するだけの人と、なにも無いところからノウハウを作り上げていく人じゃ
全然見方が違うだろうなー
ノウハウ消費ってなんじゃそりゃ?
ノウハウを作ってそして使う人と、
ノウハウを使うだけの人って意味かいな?
どっちみちノウハウは使うし、使わなきゃ意味が無いけど
何がいいたいのかわからん。
>>895 > メンバーをかき集めるってそれ素人ってこと?
技術に疎いが隣接する業務知識持ってる人間や業務知識の無い技術者、採用フレームワークに慣れていない技術者が混ざるのは仕方ないだろ。
事例自体が存在しないケースだってあるんだし。
>>895は相当温い環境に居るんだろうな。なぁなぁでもなんとなく給料もらえる程度には守られてるに違いない。
不確定要素が大きくなるほど、個人のクリエイティビティに頼る割合は大きくならざる得ないよ。
>>898 よく考えてみようか。
ノウハウが溜まって、それを活かして
次の開発ができる(俺の)所のほうが、
そんな素人同然のメンバーをかき集めて
ノウハウ0、次に何も生かせないような
仕事よりも何倍も優れた環境だよ。
自分もチームも会社もすべてが改善、
成長していっていることを実感できる。
人それぞれじゃね?
まだ誰もやったことがないことをやるのが面白いと言う人もいるし、
そういうのは嫌だという人もいる。
自己啓発マンか。若いな。
だからなんだっていうんだ?
まだ誰もやったことがない事をやってこそのプログラマだと思うんだがなぁ。嫌がる奴は確かにいるがゴミクズにしか見えない。
>>899 個人として成長するよ。残るものはある。
チームとしての成長を尊ぶか、それとも個人としての成長を尊ぶか。
そこは価値観の違いの範囲だな。
定型業務ならチームの平均が、
不確定要素の多い業務ならチーム内の最大の個人の能力がスループットに効いてくる。
優劣云々よりも、業務の性質に応じて使い分けるべき。
ただ、現代のソフトウエア開発はクリエイティビティに依る部分が大きいので、多くの場合にできる人の力が原動力になるんだよ。
(開発に付随する定型業務は、年を追う毎に確実に減っているから。)
そんな中、チーム皆でカイゼンとか言われても魅力を感じない。
ノウハウ云々よりも、チームが下限に合わせて均一化されるリスクのほうが高いから。
いくらノウハウ残したって、それを扱える人がごく少数なら組織としてカイゼンしたと言わないよね?
(例えば、飲み込むために前提知識を必要としたり、高い技量がないと効果がない場合等。)
ソフト開発で自分も組織もカイゼンとかちゃんちゃら可笑しいね。
受託開発やってる土方だろ、こういうの言ってるの。
>>905が言ってることは
1. うちは改善しない
2. 俺らは土方じゃない
これ面白いね。
>>878 guiコンポーネントをループで生成するのは
俺は許さないから。
cmmってそんな難しいことじゃないだろ。
コードがちゃんと再利用されてて
保守もできてて
お互いにコードレビューできてて
リリース前にテストがちゃんとできている。
資産が属人化していない
当たり前の事ができていれば
レベル3以上になれる。
2以下はプロの職場としては最低のクソということ。
んだからそんなもん、土方現場でしかやらんって。下請け自慢片腹痛いわ。
>>911がいってることは、
うちは土方じゃないから改善はしない、
ひたすら汚いコードを作るまでということかw
CMMの認定を受けてるところって、
土方企業が一つもないんだよねw
どっちが本当の土方なのか、
土方は自分が土方だってことが
わからないんだろうね。
>>911は客なんだろう。
だからゼネコンと土方の区別がついてない。
受託開発してる連中なんて例外なく土方だろ
意訳 俺は受託開発じゃないから、土方じゃないんだ!
元請けは開発なんかしないだろ
客も開発はしないぞ。
そりゃ開発しないというのは
技術者じゃないから当然の話。
>>915 カスのような家を作ってる人もいるしライトのようにせがまれて設計してる人もいる。
それすら分からないお前がカスなのは間違いないが
30億ぐらいのプロジェクトでインフラチームにいた時、一番最初にPMとアプリ屋の頭の中の考えを聞いてそれ通りに実機とジョブの設定して、
これじゃ困るんでジョブ設計書→パラメータシート→詳細設計→基本設計→運用設計の滅茶苦茶な順でドキュメント作った。
俺一人で。
で、俺が設計書いてる間にアプリチームが設定変えまくったので
設計通りには設定されていない、設計書読んでも実機はそれとは違う設定になってる。
でも俺は本来PMかPLを普段やってて、その時は急遽ヘルプでエンジニアやっただけなんで、設計書とか適当で逃げた。
> 30億ぐらいのプロジェクト
人数がわからんからなんともいえんな。
素人の人数を増やして開発効率をとことん悪くして、
金がかかりますとか詐欺に等しいし。
>>828 愚民にIT企業での具体的な事例をおなしゃす(´Д` )
前おったところは設計書レビューは全員参加、全員で仕様考えよりよいものを考えていくってスタンスだっった。
それで体裁取り繕ってたが全員でレビューかけたから安全安心()って迷信全員で信じ込もうとしてるだけだった。
仕様を理解しているのは設計者だけで意識共有が全くできていない。
上席者はそもそも開発言語を知らない。
参加者の大半は形式的なチェック、が役割と誤認。
そんなレビュー通っても見た目綺麗な日本語のドキュメントができあがるだけ。
練られてないからトラブルも多く、結局故障改修で慌てて直すから
綺麗な設計書()もツギハギだらけの無残なものになる。
コードと詳細設計対になってた筈がここまでの間に乖離する。
とにかく見た目整然とした設計書整形にパワーをかけては自己満足に耽る人が多くて辟易した。
せめて外部に触れるところに気使えばいいものを担当者しかみない文書の外観に全力注いでどうすんのと。
その癖一回レビュー通ったら後は無頓着っていう。
そうなるの解ってるのにそこだけ張り切るのは私は無能ですって言ってるようなもんなのになー・・・
>>923 そんな事して遊んでる余裕がある会社って、脳内だけだろ。
>>924 脳内ならどんなによかったことか。
余裕あったと思う?
そいつら余裕無いのにそれで仕事してる気になってたんだよ。
俺辞める少し前から採算取れないので潰すって話が聞こえてて、今は敗戦処理やってるそうだよ。
あんな無駄な職場が存在できたのはある意味奇跡だね。
大企業ならよくある話。
設計書のレビューなのに、技術的な話はするな。俺がわからない。とか素敵なことを言われたことあるぜ。
いっそ無くしてしまいたいが、権力を示す絶好の場だけに生半可では無理。
>>926 レビューでほぼ同じ事言われたことあるわ。
解らないから完成品以外持ってくるな、って罵倒された事もある。
でもミンナガーなんだよね。
某大企業の、孫受け先の話。
大企業様のルールでドキュメントを資産と称して作ることになってたが
それを履き違えたアホどもが延々無駄な作業に勤しんでた。
忙しくて人手が足りないらしいからそこに雇われたのに老害の巣窟だったって話。
そこにいた期間、ほぼほぼ無駄な作業の手伝いと火消しやってるだけで終わったわ。
権力示す絶好の場ってのもわかるな。
ドヤ顔でてにをは指摘してる姿みてるとお前就職先間違えてる、としか思えんが。
規模の大小に関わらず、他所様のシステム作ってる時点で開発者なんてゴミクズです。土方がんばれ。
んじゃ安藤忠雄とかなに一つ自分の建物作ってないからゴミ屑だな。お前の理論だと。
自社開発様ってガラパゴス化してるから話かみ合わなくて困る。
土方が自分の価値を示すためにシコシコ設計書作ってるとか噴飯ものだね
そんなこと考えて設計書作ってる奴いんの?
このスレじゃ
>>931以外いなそう。
土方ぶち切れワロタ
webとかソシャゲみたいな使い捨て上等のシステムってまともに設計書作ってるんだろうか
>>934 作ってる所と、グダグダの二極化してる。
なんだ普通のシステム屋といっしょじゃん
スピードが命の世界で設計書まともに作ってるのはちょっと信じがたい
急がば回れってやつですよ
>>937 そうだね、人間にやらせるのが間違ってる。
とりあえず誰も読まないけど形が欲しいなら自動生成で十分だろ。
マジな話、俺はメモ書き程度でも設計書のような物は必ず作るけど、お前らそれすら要らないの?
自分のために必要なら作る。
形式的に作らされるのは時間の無駄。
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 ...
まあ設計書ってのはいつの間にか開発のメモ帳になっていくよな。
で、あとで清書して提出するんだよな。
一応、役にはたってると思うw
>>948 人によりけりだね、そういう考え方もアリだと思う
ただし、
>>945みたいに制御系の上流設計に関わっている人なら、
実装前の設計内容の検証は当然の事として理解しているはず
(検証手段が従来通りなのか形式化/自動化を含むかは、また別の話)
実装設計の過程で問題発生&対応を進めつつ
設計書は「あとで清書して提出する」なんてこと、
上流工程の経験者であれば口が裂けても言えない
svnで更新ログの説明欄?を変更できなくしてるのはどういった意味があるんだ?
文章を間違ったとき変更できないからずっと間違ったまま残るのはどうかと思う。
945です。
どのような設計書が必要かは製品によって違うよね。
1000行程度で利用者も限定される製品と100,000行以上で不特定多数の人に使用される製品をひとくくりに語ることもできないと思うので。
いや、だんだんドキュメントへフィードバックする時間的余裕がなくなって
中途半端なまま納品して
某金融オンラインシステムみたいにあとから見ても全然わからなくてデスマ一直線
基本的に開発規模が大きくなる程ドキュメントは必要になるだろ
仕様知ってるリーダーが3人に口頭で説明するのと20人に口頭で説明するんじゃスピード段違いだろう
20人とかになるとリーダーは口頭で指示する以外仕事何もできんし、リーダーの指示待ちで待機状態の部下だらけになる
リーダー待ちの間に自力で解決して次の仕事進める奴なんて少数
コーディング中に全体の稼働率を上げたいなら設計書は必要っしょ
〇〇と同じとか仕様書に書くのやめろ。
955 :
仕様書無しさん:2014/07/16(水) 01:48:05.31
設計書は基本設計あればいいよ
詳細書くなら自分でコメントだけ付与して、PGにわたす
数千万位の案件ならな
億単位になると、要件からカオスになる
設計書をどのレベルまで作るかは、開発規模(人月) * 運用期間見込み(年)で見当は付く。
〜10^0=1 ==> プログラム設計書
〜10^1=10 ==> 詳細設計書
〜10^2=100 ==> 基本設計書
開発が10人月、運用期間見込みが5年なら、10*5=50だから、基本仕様書から。
>>955 それこそ役に立たない設計書の典型だわ
バカは設計書書かないでくれよw
>>956 逆だろ。小さいプロジェクトになるほど、詳細な設計書は要らなくなる。
一人月のプロジェクトでプログラム設計書まで書いてたら赤字になるわ。
>>958 >基本仕様書から。
だから、
〜10^0=1 ==> プログラム設計書のみ
〜10^1=10 ==> 詳細設計書〜プログラム設計書
〜10^2=100 ==> 基本設計書〜プログラム設計書
ってことなんじゃねえの?
自分の記憶力に絶大な信頼をおいているならともかく、そうじゃないなら
メモ書き程度でも残しておくほうがいいけどね。 だいたい今はタブレットや
スマフォ連携のノートがあるわけで、手書きで残すコストがちょっと前では
考えられないくらい低くなってるから。