外部だの内部だの基本だの詳細だの…
曖昧な基準で書かれた、いろいろな名前で呼ばれてて
「これってどうなの？」「意味あるの？」といった物に出くわす事も少なくない
しかし、純粋にプログラミングだけをして食べていくことは、昨今じゃ難しく
避けて通れない、否が応でも作る機会に出くわしてしまう、そんなドキュメントたち
設計書や仕様書についても、マ視点で語ろうぜ
・自分のなかでの仕様書/設計書の呼び方と分け方
・成功談、失敗談
・仕様書/設計書は何を使って作成する？(Word/Excel/HTML/手書き！)
・仕様書/設計書に含める図の作成方法や使っているツール紹介
・炎上プロジェクトでみた(よくない意味で)素晴らしい仕様書/設計書
・そもそも仕様書/設計書って本当に必要なの？
・こんな仕様書/設計書は、ぶっちゃけアリ？ナシ？
などなど、設計書にまつわる話題を募集
2 ：
仕様書無しさん：2011/11/26(土) 11:29:01.67
投げっぱなしもあれなので
・俺の中の定義
外部設計==基本設計、内部設計==詳細設計
プログラム設計はソースコードで代用できるため不要
外部設計/基本設計
UIやエンドユーザーが意識するレベルでのI/O、やりたい事などを纏めた資料
理由があって意図的に制限する場合を除いて、実装方針の変更には影響のしないレベルの情報
内部設計/詳細設計
入出力の詳細や分岐条件、メッセージ、処理順序など並べた
フローチャートのような分岐やループなど、コーディング上で表現する方法が複数あるような
意味のない情報は「明記してはいけない」
プログラム設計
2重管理になるだけで無駄なので、ソースコードが全て
javadocやXMLドキュメントコメント、コード内のコメントなど、コードでは表現できない情報
クラス図などコードより抽出できる情報
・実際の運用
外部設計/基本設計、内部設計/詳細設計
箇条書きの要件定義、またはループや分岐を書いたフローチャート
外部/基本設計が詳しい場合、内部/詳細は内容のコピペか焼き直し
内部/詳細の修正でも必ず外部/基本設計が修正される
プログラム設計
そんなの作ってる余裕なんてないです＞＜；
コピペが何割かを占めるコードだけが絶対でありそれコメント(そもそもない)含めて他は不要
---
正直マ暦はあんまり長くはないのだけれど、これって普通のことなのかな…？
ちなみに作るのに使うのは基本的にExcelです。
もちろん方眼紙です。
図はオブジェクトたち。
たまーにWordもありますが、終盤はファイルがいくつか見事にぶち壊されてます。
レビュアーが意図してる「仕様書」が何かを察することが、うまくやるコツなのかなって
最近思うようになってきました。書きたくない、じゃ通らないですし…。
ソースコードは設計書だと考えるべし。
設計はなるべくコードとして書くべし。
コードから自動生成できるたぐいの情報は、
別にドキュメントにまとめる必要はない。
仕様書はソースコードにコメントとして書くべし。
またはテストとして書くべし。
Excel、他形式のドキュメントはたたき台としての意味はあるが、
最終的にはソースコードに全て記述するべし。
別の形式として見たければ、ソースコードから変換すべし。
7 ：
仕様書無しさん：2011/11/27(日) 16:30:57.65
ケースバイケース
以上終了
8 ：
仕様書無しさん：2011/11/28(月) 23:25:34.20
結局ある程度の実装経験がないと設計なんて出来ないよ
でも、設計から入れ実装は後だっていう微妙な風潮
しかも、つくる設計書の記述内容は、実装前に作るものとしてはイマイチな内容
設計書とプログラムが食い違っていないか、機械的に検証する手段がないから、どんなに頑張って設計書作っても立派なプログラムが出来るわけじゃない。
結局設計書作るのって自己満足でしかないよね。
10 ：
仕様書無しさん：2011/11/29(火) 21:12:13.15
設計書作ること自体が目的になるとページ数だけ多くなって誰も読まなくなるな
そして設計書があるのにまったく見ずにソース見ながら電話対応するようになる
11 ：
仕様書無しさん：2011/12/01(木) 02:11:54.00
ソース見て判断できない人が見てるフリするための資料になってることが多いな
大手だと品質保証のためとか言ってコーディング前に設計書を要求されるけど、
誰もまともにレビューしてなくて結局実コードのテストで
設計段階の間違いがボロボロ発見されるような現場ばかり。
13 ：
仕様書無しさん：2011/12/01(木) 02:33:40.32
設計書なんて大枠だけきっちりしてればいいんだよ
あとインターフェイス部分とエラー処理と
現状のドキュメントはバッチ処理にはソコソコ役に立つけど
オンラインだと矛盾が多い
新しい設計書の技法出来ないかな？
UMLに拡充する形でいいけど
あと、各社マチマチな工程名称も統一して情報処理試験でキッチリ記述と読み取りを出して欲しい
納品の為にしか存在価値のないものがおおすぎる
>>12 想像力があっても実物の挙動は予想不可能なんだぜﾋｧｯﾊｰ
16 ：
仕様書無しさん：2011/12/02(金) 02:08:25.70
文章での説明にしても図説（もちろんフローチャート()）にしても
例外をうまいこと表現できないから、なんか書いてて、ウアーってなる
他のとこだけコードよりの内容が要求されるのにｗｗ
でも他の人みると、そもそも例外なんてアウトオブ思考だったわ
>>14 確かに、設計まわりの明確な名称はあるとかなり嬉しいな
とにかく何もかもが曖昧すぎるんだよな
>>12 レビューしないだけマシだわ
設計書段階で馬鹿みたいレビュー繰り返してる内に
フローチャートを作ってた事あったし
挙げ句に設計書レビューに無駄に時間がかかった結果
実装はデスマーチになってるから本末転倒の極み
設計段階で何するかは煮詰めたほうがいいよ。
実装者がアイディアマンになってしまうのは良くない。
俺が実装して痛い目見た経験から。
>>19 詰めるべきは客先交えて決める外部仕様だろ
設計で内部ロジックなんか詰めてもしょうがねーよ
DB設計と画面のモック作るだけ。
マなんて信用してないから書かせる
23 ：
仕様書無しさん：2011/12/05(月) 23:13:04.70
マはマで設計が信用ならないって言ってたりするからな
どっちであっても、出来る奴と出来ない奴の差が激しすぎるんだよな
なまじ形だけなら誰でも出来るもんだから、ひどい物でもなんとかなってしまうっていう
つか、システム全体の設計はともかく詳細設計書はコード書く本人に書かせてレビューするだろ。
新人とかなら詳細設計書まで書いてやって渡すこともあるけど。
>>24 新人じゃないならそれこそ実装したコードレビューした方が早いだろ
こういうのみると、つくづく設計関連の用語の意味が統一されてないのが
諸悪の根源だって気がしてくるわ
>>26 諸悪の根源は別のところにあります
本質を見抜く目を養わないと一緒ドカタですよ？
28 ：
仕様書無しさん：2011/12/06(火) 22:37:20.22
建築業界って、大工が「俺の作ったもんが設計書だ！」って思う人いるんだろうか
この前ブックオフで「仕様書の書き方」みたいな本があったんだけど、結局サンプルはオマケ程度で中身スカスカだった。
ちなみに俺が超参考になったのは、某大手の社員用サイトにある雛形だった。
しかしそれを下請に見せない理由がよく分からん。
その形式で納品すればそこそこな品質になるはずだが、社外秘なんだよ
基本的にそこらの書店にあるような仕様書サンプルってプログラム素人向け、顧客が理解できる程度のものだからね。
この業界自体土方だけどな
土方根性土方思想がはびこりすぎて個人でどうにかできる状況じゃねーよ(´･ω･｀)はあまじああ
>>28 モジュールを指して設計書という奴は居ないだろう
ソースに該当するのはなんだろうな
>>28 大工が建築物にコメント書くのが許されるんなら設計書にならなくもない
物置程度ならそれで充分なんじゃないかな、よくわからんけど
うちのポストにもたまに印がついてる
書いてるとこ見つけたら器物損壊で訴えれるんだっけ、あれｗ
きっちりかっちりしすぎても、緩すぎても仕様書って成り立たないよな
降車は言うまでもなく、前者も全員が守れない無駄な仕組みになってることが多くて、破綻しやすい
いい仕様書の共通仕様でもできればいいのにな！！
「昔、城を建てた無名の木工は、自分がその仕事に携わった証として、
屋根裏に自分の名を刻んだ工具を態と忘れたそうだ。そんな些細な思いすら、お前達は消し去るのか？」
たまに外科手術で縫合終わった後にﾒｽが一本足りないことに気が付いたりとか？
sierなんかで働くから悪い
ドキュメントの枠だけ用意されて中身の書き方が決まっていない現場って
文章の語順や言い回しとか表現の仕方ばかり気にする人多いけど
正直馬鹿にしか見えないんだよな
共有鯖から過去の資料や既にＯＫ出てる仕様書を真似て作成しても
人によって作り方が違うからＮＧになるし
そもそも同じﾌﾞﾂ出して見る人によってＯＫ・ＮＧ別れる時点でおかしいが
本人たちは指摘して偉い気分にでもなってるのかね
「ここは太線で区切ろう」とか
「ここは①、②を使おう」とか
「ここは図を入れよう」とか
「ここは→・↓・←・↑を使おう」とか
「ここはカッコ使おう」とか
「待てよ！～が～の～を…うーむ」とか…
こんな指摘ばかり受けてる間に
５時間でコーディング終わるＰＧの仕様書に３日かかったし
完全に遅れが発生してこの指摘馬鹿と一緒に毎日２２時過ぎまで残業開始
結局終盤の方からはＰＧの仕様書は時間がないからと指摘馬鹿が作成
どれ程のもん作ってるのかとこっそり覗いたが１時間くらいあれば
作れるような普通の仕様書だった
要するにこいつの趣味の書き方というだけだった
指摘馬鹿は人に「こっちの方がいい」とか指摘する前に
本当にそれをする必要があるのかどうかを考えた方がいいわ
必要ないことに時間掛けてる奴多すぎ
まったくだわ
うちの職場だと、能無しPLとか老害連中や口うるさいバカ女が
しょっちゅうどうでもいいことにばっか力注いでて、もうウンザリ
その決定を行わない無駄なボールの投げあいしてる時間で
解決してしまえる内容をぐだぐだやって、時間が浪費されてく
無駄に細かい仕様を早いうちから書こうとして要点はつめないまま、
後になって仕様変更のなみで外設あたりからいろいろ詰んでるし、頭痛いわ…
>>41 それを顧客側が要求してくることもあるからな。
プログラムは正しくても、仕様書の記述ミスを理由に検収拒否してきたり、
些細な記述漏れを引き合いに、仕様が明確でないシステムは稼働させられないとか言い出して、稼働延期&稼働まで強制的に立会い延長になったり。
アホでもわかりやすいところは詳細に書いて、説明が面倒臭いところは適当にごまかす
初期処理と終了処理はソースコードレベルの細かいこと書いてるのに
肝心の主処理は「ファイル変換を行う」の一言だけ
コーダーのための詳細設計書なんて見たことないんで書き方もわかりません
そうそう。
納品物件としての仕様書は誤りが書いてないこと、体裁が整ってることが最重要。
それを見てコーディングができるかどうかはまったく評価対象外。
だから設計と製造は切り離したほうがある意味確実なんだよね…
保守さえ考えなければ
わかってない奴がわかった気分になるための説明書であることが多いよな
実装を前提とした検討用の設計書になってるものを見たことがない
わかってない奴に見せてわかった気分にさせるための説明書、か
そして出来ない奴ほど体裁に死ぬほどこだわる
まったくこだわらない奴も出来ない奴だけど
あと文体とかかき方にルールを設けるくせに
Excel方眼紙を卒業できない馬鹿も多いよな
自由度が高いツールを強制して、自由に出来ないように無駄なルールをつくりあげ、
仕事を増やすのが得意技！みたいな
Excelで方眼紙で糞ルールたくさん作られるくらいなら、まだ糞Word使ったほうがマシだわ
個人的には、体裁が整ってることは大切であり、
納品物あるいは後々の保守を考えれば最低条件であると考える
問題は文書作成環境にある
Excel/Wordとも短いレポートを手軽に作成するのには最適なツール
ただし、これを数百ページにおよぶ技術系文書(仕様書/設計書/マニュアル等)に
利用する発想が、適材適所という言葉を知らぬ人が犯す基本的な間違い
>>48 > 実装を前提とした検討用の設計書
うちはこういうのばかりだ。
おかげで、他人が見たら「どうコーディングするべきなのか」はわかっても
「どういう意図でそうなってるのか」がまったくわからない状態になってる。
> わかってない奴がわかった気分になるための説明書
メンテナンスする立場で言うと、わかってる奴にしかわからない設計書なんか
残されても、まったく嬉しくないんだ。
>>51 どういう意図で、は要件定義から追えば分かるんじゃないの？
分からないと保守更改で死ねる
>>50 むかし社内で議論したけど、誰でも開けて編集できて、となると他に候補が無いんだよね。
でも開く環境が変わるとテキストがズレて崩れるけど（爆笑
Word使うなら箇条書きの範疇で済ます。
凝りたいならPowerPoint＋PDFかInDesignでごゆっくりどうぞ。
ということにしてる。
「Excel方眼紙滅べ！それで仕様書つくるやつもぜんぶ滅んでしまえ！」
「Wordは糞だが選択肢が他にないんだよな」ってのが前提にある奴です
Wordを推したいわけではないけど、Excel方眼紙で設計書作るくらいならWordのほうがいい
>>50 使いやすいとか最適だとは一切思わんけど、Wordはそういう文書作成に使う物じゃね
もちろんExcelはない。使い捨てのレポートみたいなフリーフォーマットで使い捨てるものなら方眼紙は便利だと思うけど
>>51 言葉足りずで申し訳ない
48で言ってるのは、あくまでも「設計書」に書く内容の話な
そういうわかってない人への説明や方針決めの経緯は、
もっと上流の要件定義だったり、補足資料として別に纏めるものだと思う
そういうのがかかれてないドキュメントに恵まれてるのは、いい環境だと思うけどな
>>53 Wordの基本機能ですら、世間一般に「凝ってる」レベルだって捕らえられちゃうことが一番の原因だと思うわｗ
ドキュメント関連でWordを使う利点は、文章を書く以外のことに気を使わなくてよくなる、ってところと
体裁だけを全体纏めて修正でき、印刷のことも考えなくて済む、ってところ。このあたりが表計算ソフトのExcelにはない
ただ、それぞれの機能が使い難いし、理解しづらい
なにより、そういう基本機能ですら理解出来ない、しようとしない奴が多すぎて、まともに使われることが少なく、
仮にちゃんと作られてるドキュメントでも、そういう理解能力がない馬鹿が一人チームに混じってるだけで
簡単に設定されてる体裁の破壊が出来てしまうから、使えないツールになりがちなのよね
>>51 >おかげで、他人が見たら「どうコーディングするべきなのか」はわかっても
>「どういう意図でそうなってるのか」がまったくわからない状態になってる。
うちではわかってないヤツ向けの仕様書書いてるけど、そのわかってないヤツが
意図とか書くと余計なこと書くなって言ってくる
なもんで「どういう意図でそうなってるのか」は偉い人から口頭で聞いてソースのコメントに書いておく
> メンテナンスする立場で言うと、わかってる奴にしかわからない設計書なんか
> 残されても、まったく嬉しくないんだ。
わかってないヤツの想定が違う
OSって何ですかレベルのヤツを指してる
>>51の組織ならそのプロジェクトに参画してなくてもコーダーなら理解でできる仕様書を書きやすい気がするが
そういう組織に属したことないからよくわからんけど
>>53 あ、あと、PowerPointとかinDesignで設計書はないわｗ
何のための設計書かがわからなくなる
それやるくらいならまだExcel方眼紙にオブジェクト張って済ませばいいと思う
そういや、ここじゃないどっかでみたけど、
Wikiを設計書に使うってのも結構面白い発想だなって思った
バックアップ含めて管理面での自動化できるし、差分や履歴も簡単に見れる
2拠点間での共有も楽で、一元管理もしやすい
図説みたいな自由度への制限とか、環境の構築が必要だとか、他に提出するときどうするの、とか
ドキュメントとレイアウトがどうしても混ざってしまうような欠点もいっぱいあるんだけど、
外に出ないものなら結構便利そうではある
>>55 > わかってないヤツの想定が違う
そうそうｗ
文章を読むことすら出来ないような人とか、特にそういうこといってくるｗ
箇条書き、図説、表あたりしか理解してもらえない。
そういうのは設計書じゃないだろって思うけど、その思いは言葉にしても届かない！
結局本当の設計書は各担当の頭の中で作成されちゃうのよね
自分も他に書ける場所がないする事はできるだけコメントに残したりしちゃう派だけど、
ソース弄る奴にも、先にあげたようなのが混ざったりする事もあるから
保守されないコメントが、現状の実装と異なる状態になるかもしれなくて、コメントに残しすぎるのも怖いんだよな
マに免許とかそういうのはないし、コーダーのレベルもピンキリ激しい
あとコメントじゃレビューとかもないから、誤記ったりしてもそのまま残る可能性が怖い…
はぁ？
設計書って言ったら図だろ。
お前車とか家とかの設計書見たことあるのか？
あはっ♪
設計書って言ったら、ﾌﾂｰ「設計書がどうしたんや！何して欲しいんかちゃんと云いなはれ。そんなんで伝わると思うたらおお間違いや」
設計書是也設計書。
設計書見たことあったらどうなのか？ 無かったらどうなのか？ もったいぶってても大した話じゃないならとっとと話を進めなさい。
つーか、設計書を曖昧に自然言語で書くなよ。
たしかにマも土方だが、そういう方面の土方ではないぞ。
理解能力がない人に見せる資料は設計書とは分けたほうがいいけど、理想どおりにはいかないしな。
結局頭の中が下の連中に合わせないといけなくなる。
>>60 自然言語で表現できないかしづらい内容までドキュメント化しろなんては思ってないよ
シーケンス図とかクラス図で済むことならそっちでやるし
きっちりかっちり自然言語を使わず表現できる部分なら、それはもうコーディングしちゃえばいいんじゃね
>>62 まぁ結局そうなるんだよな
> きっちりかっちり自然言語を使わず表現できる部分なら、それはもうコーディングしちゃえばいいんじゃね
うん。だから設計書＝コードなんだってば。
日本語は、コメントとして書けばいい。
プログラム設計書は要らないと思うが、それより上の工程でのドキュメントは必要。
>>65 ISOなんとかのためなのかどうかは知らないけど、
プログラム設計書は求められる現場が多い。
それより上の工程のドキュメントは無くても。
>>66 上の工程のドキュメントはどんなにわけわからんこと書いてても
我々に文句言う権利ないしね
68 ：
仕様書無しさん：2011/12/29(木) 20:13:18.23
>>4 プログラム設計書は重要じゃないけど
プログラム設計は重要
この重要性が現場でも理解されてないからプログラマの地位は低い
設計書くのは重要だと思うけど、最低限まともにレビューできる奴がいないと、作る意味がないんだよな
的外れな指摘しかされてない、半端な設計書なんて用意しても、結局糞の役にも立たないなんてことになるしなぁ
70 ：
仕様書無しさん：2011/12/29(木) 23:48:36.19
レビューは、その場で見て思いつきで指摘して終わるからな
ちゃんと修正されたか再レビューしないことも多いし
儀式的なものになり果てている
担当を複数人にしてお互いにチェックするという仕組みにしたらいいと思うんだが
>>70 それは単純に開発プロセスの問題な気がする。
プロセス監査とか無いの？
結局開発者自身が本当に改善したいと思ってるかどうかと、
さけるリソースがあるか、によるんだよなぁ。
実際真面目に取り組むとちょーメンドくてしんどい。
けど効果はある。
開発プロセスの問題じゃなくて、
各々の文章チェック能力、設計力の問題だろ。
そら有能な個人の力に頼るのが早いてのは分かるけどさ。
再レビューが無いのが問題だと感じてるなら、
再レビューしたかチェックする機構があるべきだし、
「指摘がその場の思い付き」「儀式的になってる」とか、
不具合流出の分析とそれによる対策がされて無いわけじゃん。
レビュー観点の整理とか、インスペクションの導入とか。
実際
>>70自身言ってる「チェックの仕方」自体プロセスそのものだし。
低レベルでの開発プロセス定義なんて、最低以下の人間に
最低限の仕事させるためのもんだよ。
高生産性や高品質はその次の話。
低レベルの人間に何回チェックさせても無駄。
プロセス重視することと、内容を軽視することは同義。
＞プロセス重視することと、内容を軽視することは同義。
レベル低くて笑える。
それ素振りやっただけで上手くなった気分になって満足してる奴らの話だろ。
まぁ好きにしたらいいよ。
プロセスを突き詰めて問題が解決するなら
docomoの障害は起きなかっただろう
無駄なプロセスばかりが増えていく。
内部統制とかいい例。
プロセスを突き詰めても
人間がある以上トラブルは発生する。
だがプロセスがなければ
もっと多くのトラブルが発生する。
>>73が自分で言っているように
＞低レベルでの開発プロセス定義なんて、最低以下の人間に
＞最低限の仕事させるためのもんだよ。
こういうことなんだろう。
そもそも最低の人間を使わなければいいのに。
自称上級者が簡単なことを
やらないからいけないんだろうな。
低レベルの人間大量に投入してプロジェクト上手く回すのがプロマネの仕事です。
レベル高い人間を集めるられることを前提に計画建ててる時点で破綻してる。
>低レベルの人間大量に投入してプロジェクト上手く回す
ってのは可能なのか？
>>82 ソフトの世界は量ではなく質なので
その方法では一流になれません。
質の良いソフトがビジネス的に成功した例は皆無だよ。
WindowsとかOracleとかのバグの多さを見れば明らかだろう。
86 ：
仕様書無しさん：2011/12/30(金) 17:29:43.68
ビジネス的に成功 と バグの多さ にどういう関係が？
>>85 低レベルの人間を大量に集めて
WindowsとかOracleを作れると思ってるなら
おめでたいな
質より量を重視した結果バグだらけになっても、多機能を売りにビジネス的には成功するって話。
>>87 本気で高レベルの人間が、少数精鋭で作ってると思ってるなら頭おめでたいですね。
90 ：
仕様書無しさん：2011/12/30(金) 17:39:40.42
人が大量にいないと作れんが
その人達は全員がある程度高レベルの人間でないと作れない
特に優秀な人が必要なのはプログラマレベルだろう
例えば日本のゼネコンシステム会社にMFCとか.NETライブラリとか作れるか?
上流工程(藁)SEには作れないし、寄せ集めプログラマ作れるものではない
Microsoftはバグですらビジネスに利用して一流になったわけだし。
新しいバージョンではバクやセキュリティホールが治って価値が上がってる、だから新バージョンを買ってくれってね。
残念ながらOS作ってる奴らの大半は、寄せ集めの短期契約プログラマーだよ。
え、マジで？
デビッドカトラーとかは伝説なの？
94 ：
仕様書無しさん：2011/12/30(金) 17:54:50.00
>>92 正社員か下請けか派遣かとかの所属のことを言ってるんじゃないよ
著名な人間の間違いは指摘できないから、それが正式な仕様としてドキュメント化されるプロセスが定着してしまったんだろうね。
今のwindowsは糞仕様が多すぎる。
96 ：
仕様書無しさん：2011/12/30(金) 18:16:30.51
「仕様がクソ」と多くの人が言うが、「どこがクソ」かを言う人は少ない
97 ：
仕様書無しさん：2011/12/30(金) 18:21:10.54
>>96 そいつが、そういう仕様になってる理由を理解できる頭がなく
分かってないだけのことも多い
単に自分の分担分の作業が増えて面倒だというだけの理由の場合もあるな
バグ報告のサイトで散々言ってるから。
>>87 >>90 多人数大規模の開発ってのをなんか勘違いしてるでしょｗ
まず前提条件として、大規模っていうの数万、十数万人月という工数で
すごいプログラマが通常の10倍の生産性だったとしても
1000ヶ月、83年、そんなに時間かけられますかって話なんだよ。
WindowsとかOracleとかそんなのは難しいだけで工数はそんなに必要ない。
簡単だけど工数は大きいという仕事のほうが世の中には多いんだよ。
OSやDBMSなんて殆どの人は使うだけで作ったりしないでしょ？
そしてOSやDBMSを使うだけの仕事に、OSやDBMSを開発できる人間を
担当させるのは、どう考えても仕事の振り方間違ってるよね？
そして仕事である以上、納期とコストの事を考えないといけない。
工数から考えて、少数のすごいプログラマだけで作れる期間は与えられない。
なら、すごくないプログラマを投入するしかない。これは絶対条件。
じゃあどうするか。ここまで考えてものを言ってる？
>>93 戦うプログラマー読んだけど、優秀な人間を大量に集めてやっとNTが作れた
からな。 アレで分かったことは、大規模開発には大量の人が必要です、
可能な限り優秀な人間が大量に。ただ人を入れればいいというわけでは
ありませんってこと。 人月の神話で言われてる、人を入れてもロスが多い
云々ってのをロスがあっても優秀な人間で底上げするっていうこと。
> 可能な限り優秀な人間が大量に。
それは現実的ではない。
そんなに人捕まえられないし、
優秀な人間はコストがかかる。
俺が提案する方法（普通の方法だが）は
システム全体を難しい部分と簡単な部分に分離していく。
難しい部分は優秀な人間が、簡単なところは技術力が低いプログラマが。
Windowsみたいにいくらでもコストが掛けられるような場合はいいが
実際はこういうふうにして行かないとやっていけないでしょ。
システムに簡単な部分と難しい部分があることに
気づかない人って理解出来ない。
一人でシステムすべてを作っているからその違いを考える必要がないのかな？
上級プログラマ、つまりアーキテクトとしての力があると自然とシステムを
難しいコアの部分と簡単な末端部分に分けると思うんだが。
コアの部分は重要だけど規模としては小さくなる。末端部分は簡単だけど数は多い。
普通こうなるし、こうなるように設計するはずなんだ。
そしてシステムを分離した時、他に人がいるなら簡単な末端部分を
アーキテクトである自分がやるのは効率が悪い。
一介のプログラマで十分って気づくよね？
これが最適化されたシステム開発の姿だと思うんだが。
80:20の法則ってのがある。プログラムのパフォーマンスの80%はソースコードの
20%が出しているっていうやつ。オフショアに出して安く上げることを考えるに
しても、そういうコアな20%の部分を自分の所でキープ出来るかでプロジェクトの
成否が別れたりする。たいがい、まとめてドーンて出してドーンて失敗するん
だけどね。
80歳まで20本の歯をｷｰﾌﾟって歯無し
そもそも大規模な仕事をやる必要があるのか？
金掛けて糞積むようなもんでしょ。
金さえあればどんな仕事もやる必要はないよｗ
>>105 この業界に生きるものとしてそれを言ってはいけないwww
俺らが生活できるのは誰のおかげかwww
あるテーブルの値を合計して別なテーブルに書きこむとかいう処理を
何十万かけて作って、それを何百本と作って、何十億円の巨大プロジェクトとか
作ってて虚しくならないかと思うんだけどだけど
>>99 とかはそういう巨大さに充実感を感じるんだろう
実際に稼働することで開発費以上の利益を生むわけだし、お客が納得してれば別にいいんだけど
>>107 充実感？
お前の個人的な基準を人に押し付けないでね。
>>107 俺にとっての充実感は多くの人を管理して
少ないコストで大規模なシステムを作り上げること。
末端の作業をやって充実感があるわけ無いだろｗ
そんなものは部下にやれと命令する。これもまた充実感。
ソフトは
大規模 = 価値がある
わけじゃないんだよね。
Gmailはシンプルな仕様で工数的にはそんなに掛かってないはず
でも世界中の人が利用してる。
これからの時代、SIerも淘汰が始まると言われている。
金持ちに粗悪品売るような商売も長く続かないだろう。
請負やってりゃ客の金をたくさん取るのが正しいんだろうけど
それがソフトのあり方だと思わないで欲しいね。
自社サービスやってればそんな発想は出てこないだろうに。
>>110 そんなの当たり前だろｗ
なんでそんなことを言うのかしらんが、
もしかして、大規模なら価値がないとでも
言いたいのか？
>>111-112 何をそんなに否定したいのかさっぱりわからんのだが。
話をまとめるぞ。
・優秀なプログラマを必要な数だけ揃えられるとは限らない。
・優秀なプログラマであっても、ものを作るには時間がかかる。
・どこの会社にも、優秀なプログラマよりも、技術力の低いプログラマはいる。
・手に入るカードで最短の時間とコストで作る必要がある
・うまく人を配置しましょう。
・そのためにシステム全体を重要なコアとそうでない部分に分ける必要があります。
（・俺の仕事は重要なコアの作成とそうでない部分の分離です）
・簡単なところは技術力の低いプログラマにまかせます。
・技術力の低いプログラマは経験を積んで技術がついてきたら徐々に重要な所を担当させます。
これのどれを否定したいんだ？ 現実的なやり方だろ。
否定しなきゃならない理由でもあるのか？
>>113 大規模 = コンパクトにする努力をしてない
と思う。
>>114 規模が大きければそうせざるを得ない。
ただ、その規模必要なの？
docomoの障害だってそうだよな
何重ものいらんチェック付けて工数増大させてる割には
肝心なところが抜けてる
>>115がすべて
規模の大小なんて大した問題ではない。
努力が足りないだけ。
>>116 規模の大小に関係なく、
開発期間とコストを下げるには必要なこと。
大規模ではもちろんのこと、小規模であっても
小規模なら会社も小さく、優秀なプログラマを雇う金もないし
人も来ない。
最初から技術力が高い人を手に入れられるわけじゃないんだよ。
金があったとしても、必要なときにすぐに来てくれるわけでもない。
それが現実。
>>117 そうだよね。
難しいコアの部分と簡単なところを分離してないからいけない。
docomoなんかは、コア優秀な人を十分に割り当てられなかったのが原因。
大会社になれば優秀な人は社内のどこかにいるはず。
そういう人がつまらない仕事をしていたのだろう。
コアと簡単な所を分離する。こがまさに大規模なものを
コンパクトにするということだよ。
そして少数のコアと多くの簡単な所に分けられる。
そして優秀な人の仕事を減らしつつ、簡単だが量が多い所に
適当に集めた人材を大量投入する。
神は細部に宿る
これはソフトにも当てはまると思う。
簡単だからといって適当な仕事をされたら、たまったもんじゃない。
アーキテクトの目が届かない範囲にまで規模が膨れたら
それはもう分を超えているのではないか。
プログラマとして、自分の受け持つ設計やコード等に神を宿す努力をするべきだが、ビジネスの場にそれを持ち込むのは、切り分けができていない二流。
全体のレベルが高くある必要があると思うなら、均一なレベルにできるシステムを考えろよ。(そもそも、俺が考えた最強のが多い気がするが)
お前らは、自分ができる奴だと思いたい、出来ない奴を叩きたいだけで、実際はご近所さんで毎日集まって愚痴ばかり並べてる様なそこらの主婦となんら変わらないクズなんだよ。
>>115 100万行のコードをいくらコンパクトにしても一万行に収まるわけじゃないからなぁ。
>>111 > Gmailはシンプルな仕様で工数的にはそんなに掛かってないはず
> でも世界中の人が利用してる。
お前みたいに、UIだけで中身を判断する馬鹿がいるから苦労すんだよ
>>114 理念としては正しい方向性であると思う
というか、昔から同じような事は言われてきた
では、そんな当たり前の事を実践できていないプロジェクトが現実に多いのはナゼか？
という話になる
自分の想像を二点挙げる
まず最初に、
>>114では「優秀」という単語が何度も使われているが、
この優秀度を定量的に(=公平かつ正確に)計測するのが難しい点
いわゆる自己申告というものはアテニナラナイ
次に、それら稀少かつ優秀な人材を「開発に着手する前に」最適に配置するのが難しい
まだシステムが形になっていない段階で最適な配置を決定するのは、
高度な未来予測(いわゆる「見積もり」)能力が要求される
また優秀な人物でもすべての分野で完璧という訳ではなくて得手不得手な分野がある
そして優秀な人物は自己過信になりがちだから、ここでも自己申告はアテニナラナイ
よくある失敗パターンが、システムのコア部分は精鋭を集めて作れたんだけど、
人数集めて作り始めた周辺部分がぐだぐだになってしまうというやつだな。
ユーザの要望や度重なる仕様変更に晒されて肥大していくのは周辺部分なんだから、
ここに大規模ソフト開発や膨大な仕様の把握などに対応し切れない人を当てると
ぐだぐだになる。
目に見えない制御部分が優れていることより、目に見えるUIが優れていることが優先されるからな。
>>96 いろいろとあるが、
OS領域と、ユーザーアプリケーション領域、ユーザーデータ領域が、明確に別れていない部分が糞。
OSが不安定になって再インストールとか、それによってユーザーデータが消えるとか、アプリケーション一つずつ入れ直すとか本来あり得ない思想が前提になってる。
>>130 それは *** Windowsが糞 *** という話だね
すべてはレジストリが癌になっている
>>131 お前、レジストリがシステムデータと
ユーザーデータでファイル自体分離されてるの知ってる？
>>130 それはお前がフォーマットして
インストールするから消えるんだろｗ
134 ：
130：2012/01/03(火) 16:14:34.56
>>132 システムデータとユーザデータの分離なんて当然の事だろ
レジストリが癌なのは、集中型データベースかつバイナリ形式で保存されること
135 ：
131：2012/01/03(火) 16:15:34.55
>>134の名前欄を訂正
X: 130
O: 131
136 ：
130：2012/01/03(火) 19:40:30.02
>>134 ユーザーデータがレジストリとして管理上分離されてても、それのバックアップをとって他環境に復元出来なけりゃ意味ないよ。
ユーザー用のレジストリファイルならコピーして
他環境に持って行って普通に使える。
可能ではないけど手間が段違いだからな
しかもあまり一般的じゃないから情報も少ないし保障もない
そういう事が考慮されていない糞設計ってことには違いないよな
>>41-44 ワロタエナイ
文書表現ばかりこだわる奴が炎上プロジェクトに投入されると、ますます燃え盛るw
>>138 じゃあ、一般的に
レジストリをエクスポートして
インポートすればいいだけじゃね？
何難しく考えてるのよｗ
要件定義がぜんぜんできてない段階で、設計書に着手してるアホばっかだから、
設計書を書いてそれを客に提示して、お伺いを立てるなんて発想が出るんだよ･･･。
だから設計書も設計ではなく要件を書くようになっていって、
肝心の部分がぜんぜん詰められてない状態になって、ただのゴミドキュメントと化す。
全部爆発しろよもう！
っていう愚痴
>>141 「お客は いったいどんなプログラムを作って欲しいのか、
そのプログラムの仕様を自分でも理解していない」
「プログラマは客の要求する仕様に合わせてプログラムを作るのではなくて、
自分の作ったプログラムの仕様を客の仕様だとごまかしている」
144 ：
68：2012/01/05(木) 00:05:27.92
>>141>>142 何でみんな作る前に仕様を決めたがるんだろうね
作りながら仕様決めながら要件定義するスパイラルでいいじゃん
やたら細部の体裁にこだわってる仕様書を改訂する作業は面倒だと思うが
プログラマまで仕様変更を嫌がるんだもんな
>>141 客が設計書を出さないと要件は言わないってさ
しかも要件に合わせて設計書の修正は禁止
>>144 プログラマの立場で仕様変更を嫌がる理由は大抵は仕様改悪にしか見えないから
>>141 SI側も客自身も業務を理解してないし、
どういう仕組みを作ればいいかも明確じゃないんだろうね。
漠然と市販ソフトみたいにシステム入れれば、コストが削減できるとか思ってる。
要求定義書→総合テスト
基本設計書→結合テスト
詳細設計書→単体テスト
設計書にはテスト項目の定義を書く。
テストは設計書の内容が確実に実装された事を確認する。
テストってのは、外部から見た動きだから、設計書も
内部的なとこはわりとどうでもいいんだよね。
>>145 設計書ださないと要件ださないって、、順序おかしくね？
設計書じゃなくてそれは提案だとおもうのだけど 、先に設計書つくらせるのは大手なら先行着手でコンプライアンス違反だな
作る物も教えずに設計図出せってw
マジシャンじゃないんだからw
画面設計書とかある程度の叩き台先に作って見せないと打ち合わせが進まない。
要件がよく分からないからって設計書作らずに打ち合わせ行ったら、何も用意せずやって来て無駄な時間取らせるんじゃないと、一蹴されるよ。
それは設計じゃなく要件定義だろ
>>153 だから、要求を洗い出して、客に提案して、合意をとった上で始めて設計が固まるだろ。
その安価は何が言いたいんだ？
要件定義で画面レイアウト決めるのは要件定義ですか？
外部設計と内部設計の話を混ぜるな
画面仕様を設計だと言い張るSEがいたなぁ。
自分が設計までしたんだから、あとはPGの仕事だと。
今できる最適解は、
プロジェクトやメンバの性質にマッチした仕様書・設計書を適切なタイミングで作成すること。
これに尽きる。
必要な成果物は常に考えながらプロジェクト遂行しなければならない。
成功プロジェクトや経験だけに頼ったやり方はダメ。怠るとデスマ確定。
嫌なら法整備して厳格にすべき。この産業はいつになったら法整備されんだよ。
合意をとった上で始めて設計が固まる と思ってるなら、まだ青臭いな。
合意はその時点での合意でしかない。
>>99 サラリーマン思考で乙としか言えないな。
>WindowsとかOracleとかそんなのは難しいだけで工数はそんなに必要ない。
あんた業務システムしか経験したことないでしょ？
知らない分野のことは安易に言い切るなよ。
一般に高難易度のものは工数積むだろ。
>>160 いや、そうあるべきって話しであって、必ずそうでなければならないとは言っていない。
設計と要件定義をごっちゃにしてる奴がいたから言っただけ。
会社にとって総合的に利益のほうが上回る事が見込まれるのであれば、カチカチの行程なんてたどる必要はない。
顧客要求事項が曖昧なまま設計しても、すぐに行き詰まって、手戻りが起こる。
コストばかり費やして成果物は完成しない。
予算も納期も限られてるのだから、ある程度踏ん切りつけさせろ。
機能を諦めさせるか次の開発に乗っけさせて貰うとか交渉が必要。
>>163 結局、金ある所からなーなーで仕事もらうのが一番無難に儲かるという。
>>159 >プロジェクトやメンバの性質にマッチした仕様書・設計書を適切なタイミングで作成すること。
「性質」やら「適切」とやらの定義が曖昧だね
これが
>成功プロジェクトや経験だけに頼ったやり方はダメ。
の典型例なのかな？
しかも
>必要な成果物は常に考えながらプロジェクト遂行しなければならない。
という精神論
たぶん
>>159の担当プロジェクトは、いつも
>怠るとデスマ確定。
なんだろねw
デスマするかしないかはドキュメントで決まるだろ
デスマで食ってるやつはドキュメントをわざと書かせないから、分かるよドキュメントなくて作業なんか進まないところにザコを沢山投入して上まえハネテ儲ける
そうゆうヤクザなやり方してんだよ
>>162 カチカチの行程のほうが開発会社の利益になるんだ
臨機応変に効率的に要件を満たすソフトを作ってしまったら
工数も次フェーズの仕事も減ってしまう
結局実現可否まで判断しきれないと、ちゃんとした設計はできないし、手戻りも増えるから、
設計担当でも最低限のコーディング知識くらいは必要だよなホンと。
無能なSEやSIが上流に居座ってると、いいことがまったくない。
デスマに必要な要素っていうと
-要件をまとめ切れない、仕様を確定できないままずるずる時間を無駄遣いする
-実現不可能な妄想をして手戻りを起こし時間を無駄遣いする
-時間がないや知識不足で仕様書を作成できず、実装担当に情報を渡さない
-スキル不足で実装ができないか大幅に遅れ、テストや改修時間がなくなる
こういうのがあるんじゃないかなと思うけど、
考えてみたらうちの職場は上3つが全部当てはまってる素敵なところだった
そんな状況で工数が不足し、新人投入しはじめたから4番目のもヒットしそうな勢い
やったね！
>>168 あー…書き方わるかったかな。
カチカチのほうが確実な見込みが取れるから安全だけど、わがままな客やあまり頭の良くない客だとしても、利益が見込まれるなら受けるって話。
デスマってるところは、大概何も考えずに
行き当たりばったりでコーディングしてる。
Railsとかフレームワーク使えば簡単に作れるとかいって
フレームワークの正しい使い方も調べずに
へんなやり方でトライして動いた、じゃあOK。で進めてる。
簡単に作れるというのも考えものだよ。
何も考えずに動いてしまうってことだから。
でへんなやり方になっていって、デスマに陥る。
本来は設計レベルを担当する人が
フレームワークの正しい使い方、ベストプラクティスを調べて
それを下っ端のプログラマに伝えるべき。
だから設計者はプログラミングを高いレベルで習得してなければならない。
デスマってるところは、設計者はプログラミングをしない。
そして全部下っ端プログラマに任せる。
で下っ端は管理されてない状況で好きかってやって
デスマを引き起こす。
昔みたいに要件や仕様をしっかりまとめてから開発するというやり方は変化が激しい今は
通用しなくなってる。だから、素早い開発が重要。そのためには拡張性と柔軟性を
備えたシステム基盤を作れないといけない。
この拡張性や柔軟性というのは、どんなものにも耐えられるものが目標だから、
要件や仕様は参考程度確定していればいい。そして作りたいシステムとは独立した、
汎用的な拡張性、柔軟性を持った設計の基盤の実装をシステム開発よりも先に行う。
作りたいシステムは短いコードですぐに実装できるよう、多くのものを汎用的な基盤に持っていく。
そこまで行っていれば、要件や仕様が変わってもすぐに対応できるし、
実現不可能かどうかを試すのもすぐに出来るようになる。
ここまでの説明でわかったとおり、要件とか仕様とかそういう話よりも
今は基盤の実装技術が極めて重要なんだ。そこができてればあとはどうとでもなる。
（正確には、どうとでもなるようなぐらいに基盤を作り込んでおく）
デスマを起こすところは作りたいものだけを考えて、基盤のことを一切考えていない。
>>171 おまえは何回後付けしてんだよ。
現場にたまにいるわ。
そういう意味じゃないとか言いながら、ジワジワと意味を変えるやつ。
確固たる主張がないなら折れろよ。
言い逃れ野郎は、ひとつ否定されると全人格を否定されてるんじゃないかと思い込むからな。素直に認めろよ。
間違ったことだったとしても認めたらその場だけの馬鹿認定で済むんだぞ？
>>174 君の考える基盤って、いわゆるフレームワークに限定してないか？
基盤というともっと低レベルだったり、ハードウェア選、インフラ系を含んだりする。
>>174 変化が早いから素早い開発が要件されてるわけじゃなくて、
金がないから開発期間を短く設定するしかないんだよ。
本来は、3年5年かける規模をわずか半年で開発しているのが現状。
単にゴールを決めて開発してるに過ぎないんだよ。
だから、出荷後や運用開始後に『保守という名目や、改善という名目でバグ修正』
システム開発の世界では、スカイツリー完成に与えられる期間は半年である。
>>173 システムエンジニアとプログラマを上下関係の階層構造で考えるのは限界があると思うよ
プログラミングを高いレベルで習得してる人と
業務ロジックを高いレベルで基本設計にまとめられる人は別人でもいい
>>174 顧客と折衝し開発範囲と仕様を定義するシステムエンジニアと
それをソフトウェアとして構築するプログラマは別モンてことだな
設計書を書くだけのシステムエンジニアは
詳細設計書見てコーディングするだけのコーダー同様に
要らなくなるかもしれん
設計にプログラムの作成とかやらせたらダメだよ。
本来やるべき設計に手が回らなくなって、デスマ化する。
デスマ化するかはお客との調整がすべてだと思う。
設計者と実装者を別けた時点でデスマ率UP
>>181 > 設計者と実装者を別けた時点でデスマ率UP
現実問題、人・金がないのだから分けるしか無い。
その場合、設計者がサンプル実装を行なって
それにそったやり方で実装するように決めれば良い。
もちろんレビューも行う。
>>181 納期までに一人で何でもかんでも出来るなら、苦労しないんだよ。
>>175 後付してねぇし、言い逃れしてねぇよ。。
言っていることの真意と異なることを返してくるから、細かく答えてるんだろうが。
挑発して勝ったつもりになってんじゃねーぞ。
162で書いた
「会社にとって総合的に利益のほうが上回る事が見込まれるのであれば」
が、何を上回るかって部分をお前は
「カチカチに決めることより利益を上回るなら」
って解釈してイチャモンつけるから
「そうじゃなくて、ビジネスとして利益が上がるのであればという意味だ」
と認識を正してるんだろ。
どこが意味変わっているのか答えてみろよ。
確固たる主張してんだろカス。
>>184 ま、利益優先や短納期だと、工程ごっちゃにしちゃうのは、よくある話。
技術者に無理強いする訳だから、ほぼデスマ化するよね。
>>177 いまどき、ソフト開発に3年もかけてたら製品発売した時点で時代遅れだってw
>>185 それは、利益優先や短納期が悪いっていうより、後出しじゃんけんさせるのが悪いんじゃないの。
新製品のoffice2000向けのツールを作ってたらoffice2003がでました！どうしましょう？
えぇぃ、再設計だ。とわいわいがやがやしてるうちにoffice2007ﾘﾎﾞﾝになってましてどうしましょう？
で、ちんたら勉強してたらoffice2010で標準装備で、実はﾂｰﾙ無用で済みました。てへ。
>>181 両方やれるような優秀な人間にプログラムさせるのはもったいない
>>187 後出しジャンケンは対応次第で次の開発につながったりするから、一概に悪いとは言い切れない。
対応を誤れば、デスマ化するけどね。
>>189 実装しかできない奴に渡してもいいような資料を作る方が時間がかかる。
既に火を噴いてる状況なのに、横から口出してきて
更にいらんことやらせようとする、自称優秀SEがさらに引っ掻き回してくれそうな予感がするこの頃。
>>191 仕事を誰かに割り振るようにできないと
一人に負担がかかり過ぎて、うつ病や廃人になるぞ。
設計を誰かに渡してしまえばいい。
そうか折衝や設計から外注にやらせればいいんだ
不況で人余ってるから買い叩けるし
失敗したら責任取らせて別の会社にやらせればいい
>>195 お前・・・
責任を取ったからって、システムが出来上がるわけじゃないぞ。
失敗した時点で、システムの完成はできていない。
そして儲けが出るほど責任を取らせれられるわけじゃない。
最悪、会社倒産でお前は損して終わりだろ。
だから最後は誰かが必死に仕上げるんだ
俺ら孫受けがな
で仕上がるのか？
>>195 実際はそのとおり。
だけど、それだとお前が間抜けないよな。
って訳で、1枚邪魔がはいるのよ。
>>200 お前の人格まで否定しないから、反論してみろよ。
図星と指摘することが反論そのものだろｗ
ゆとりは会話もできないのな
>>201 やっぱりね。おまえは打たれ慣れてないっつーか、社会に揉まれてないっつーか、そんなところだな。
経験浅いから使ってる言葉に重みがねーんだよ。
後出しジャンケンの意味も履き違えてるみたいだし。
聞きかじった言葉だろ？
すぐに感情的な反応するとこ見ると
あながち間違いじゃなかったみたいだ。認めろよ。
もう一つ言うとだな、お前の思ってる言葉の裏に隠されてる真意なんて誰も知らないって。
何だよ真意って。最初から真意言えばいいのでは？
利益優先だとか工程ガーとか、そんなんじゃ仕様書いたことあるかどうかも疑わしいわ。
背伸びしなくていいよ。等身大でいいんだって。
※関係ない人ごめんなさい。
>>204>>205 話の流れをいったん整理する
設計してから要件を定義するという話をしていたから、俺が
「それは設計ではなく、要件を定義するために顧客から要求を引き出す作業であって、
要件が明確化して、機能が確定した段階ではじめて設計が固まる」
という話をしていたわけだ。
そこで、お前が
「合意をとった上で始めて設計が固まる と思ってるなら、まだ青臭いな。
合意はその時点での合意でしかない。」
って頓珍漢な横槍を入れたよな？(本人？)
合意を取ったことに対して"その時点での"設計が固まって、
後で変更を依頼されたら、仕様変更で再設計だよな？
で、俺が返したのは、
「"俺が"初期段階の決定事項が全てだと思っているわけではなく、
設計と要件定義の区別がついていないやつがいるからそういう答えをした。
会社として利益が見込みがあるのであればそういう仕事もする。」
で、お前が
「カチカチの行程のほうが開発会社の利益になる。
臨機応変に対応したら仕事が減る。」
で、俺が
「カチカチのほうが確実な見込みが取れるから安全だけど、
実際には利益が見込まれるならそういう客にも付き合う。」
で、お前が
「話を後付けするな。確固たる主張がないなら折れろよ。
言い逃れ野郎。人格否定されてると勘違いするな。素直に認めろよ。」
で、俺が
「
>>162で書いたことの意味を正しく認識できていない。
カチカチにするより利益が上がるという意味ではなく、
利益が上がるなら仕事として受けるという意味。」
で、お前が
「どうした？図星すぎてテンパったか？」
で、俺が
「お前の人格まで否定しないから、反論してみろよ。」
で、お前が
「図星と言ったのが反論。」
「経験不足にみえる。言葉に重みがないからわかる。
言葉づかいも間違えている。図星だろ認めろよ。」
「お前の心の中なんか知るか。最初から真意言え。
利益優先だとか工程ガーとか、そんなんじゃ仕様書いたことあるかどうかも疑わしいわ。
背伸びしなくていいよ。等身大でいいんだって。」
ここから、返信 ← new!
「真意って言ったけど、書いてなかったことではなく書いていたこと。
お前が話しの流れを読めていない上に、どんどん話をずらしていった。
そして、図星が反論になっているという意味がいまだにわからない。
冷静に自分のレスとスレの進行を眺めなおしてこい。」
そろそろダルいのと、もうだいぶ他の人に迷惑かけてるから、
次で誤解が埋められなかったら終わりにしよう。
こうゆうやつらがいたらデスマになりそう
細かい事はいいんだよ見たいな奴は危険。
また、一見細かく見えてどんどん話がずれて行く奴も危険。
話の発端は、要件定義やらずに設計書を要求してくる客がいるというところから始まってる。
おそらく、お互いが最終的なシステムをどういったものにしたいかイメージできないからだと思う。
このような場合、試作を見て要件を出してもらうプロトタイプモデルとかがあるわけで、
その変形版って捉え方でいいんじゃないかな？
>>207 あんたまたやらかしてるよ。。認めればいいのに。
頭凝り固まってる。
>>212 相変わらず、何の具体的な指摘も反論も出来ないのな。
という事で終わりな。
>>209 PM,PLだったら最悪だな。
特に行き詰まったときに、精神論や人格論ばかり振りかざす奴。
うつ病患者量産するからな。
PEだったら、チームから外してもらうよ。
そろそろ仕様書、設計書の話に戻そうぜ。
相手の意見なんて一切お構いなしに、自分の信念に基づいた見えない弱点を作り出して、
そこを突くことで勝ちに浸る、って奴はどこにでもいる
そもそも発端が、憶測から相手を過小評価することで気持ちよくなりたい相手なんだろ
んなの、いち早くレスする価値がない相手だって気づいて、スルー決め込むのが最適解だわ
わざわざ同レベルで争い続けるから、無駄レスが続くんだよ
>>204 やべぇ、こういうおっさんうちの職場にいるわｗ
こいつの書く仕様書が半端じゃなく使えないけど、声でかいからみんな困ってる
反論しなければ周りにバカ遺伝子撒き散らすし、やりあえば不毛だし、生きている事自体が害でしかない。
220 ：
仕様書無しさん：2012/01/08(日) 14:08:21.26
討論はどんどんすべきだし、途中まではいい感じだったけど
人格否定が始まったら終わりにすべきだな
「現場にたまにいるわ」のあたりからディベートとして成立しなくなったな
仮想敵設定を誤るとこうなる
はいはいぬるぽ
2chに何か期待した時点で負けだろ。
自分の書き込みに、全部同一人物がレスしてると思うなw
ここはIDもついてない板だぞ
IT開発者は少しくらいはアスペルガー気味なところがあっていいけどもちょっとは気付け
ちなみに
>>144 >>168 >>174 >>178 とかは同一人物
>>168 の書き込みが悪かったな。
>>162のカキコの意図を取り違えていたよ。ていうか半分は論点ずらしだったわけだが
それも2ちゃんだ
設計書の形式、ExcelもWordもダメだとすると、何がいいんだ？
最後に頼りになるのはTEXTでしょう。
jpg
>>224 現場にたまにいるわ。
詭弁使ってドヤ顔してるやつ。
確固たる主張がないなら折れろよ。
>>224 ごめんなさい。
「確固たる主張がないなら折れろよ。」
って言って見たかっただけです。
そもそもマイクロソフト様は設計書は何で書いてるんだろうな？
まさか、Word？
Excelは保守を考えないなら楽だけどな
>>232 技術資料は全てMSDNとして公開されるわけだからHTMLだな。
>>233 ということはhtmlは何で書いてるの？
メモ帳？Ｗord？
ホームページビルダーだよ
プロが包丁でじゃがいもの皮を向いていても
一般の人は皮むき器でいいと思うよ。
真似することはない。
>>235 独自の管理？ツールがあるんだろ。
ドキュメントコメントと関連付けられたフォームに、
入力するとMSDN生成してくれるやつが。
>>238 ドキュメントコメントって設計書か？
少なくともソースが存在しない時点では書けないよな？
>>239 ドキュメントコメントは仕様書だな。
作る順序は作業の進め方によるけど。
何かツールでモデリングしてコードの雛形作ってる事のほうがおおいか。
>>235 HTMLはVisualStudioでだ。
HTML形式で文書を作成するってのが想像つかないんだよな。
一般企業だと、文書は文書作成ソフトで作成して
提出時に用紙に出力するって流れで固まってるよね。
HTML形式を用紙に出力すると、体裁崩れちゃうし…。
>>243 それは、HTMLとCSSが使いこなせていないからでは…？
ﾈｽｹの4がﾃﾞﾌｫだった時代のｵｼﾞｻﾝなんだけれど、今からHTMLとかCSSとか覚えようとしたら
どっから覚えたらいいんだ？ ﾃｰﾌﾞﾙとTRとTDで組むとかしたらｼｰﾗｶﾝｽ級の扱い受けるんだろうなぁ
247 ：
仕様書無しさん：2012/01/10(火) 01:29:42.23
レビューの議事録って誰が書いてる？
レビューされる人(設計を説明する人)？レビューする人(レビューアー)？
特に決めてないけど、される方が書いてるかな。
テーブルレイアウトは、方眼紙の延長だわな。
それだけである程度のレイアウトができてしまうから、
それぞれに適した手段を一つ一つ学ぶ手間がかからないので、馬鹿でもなんとかなる。
HTMLは文章や単語に文字で表せない意味付けをするためのもので、
スタイルシートはその文書などの部品をどう配置するか、どういう見た目にするか、
みたいなただのの設定だから、誰でもすぐ覚えれるし、別に難しいことはないはずなんだけどな。
>>247 れびゅーいが書いてれびゅーあが確認するって事が多いんじゃないかな
指摘事項とかを書き出して、対応内容まで書いて、対応してるかどうかを確認する、って流れになるだろうし
どうでもいいけど、このレビューイって呼び方がなんかこう好きになれない
ｷｬﾊﾊ ﾚﾋﾞｭｰｲ
>>249 CSSには長らく段組という機能が無かった。
また角丸を実現する方法もなかった。
結局は、段組用、角丸用に調整したHTMLを書かないといけず
それを実現するためのテクニック（バッドノウハウ）が必要なので
難しいものとなってる。
CSSは要求するデザインを満たせるものではなかったんだよ。
十数年たってこれからやっとましになるかなってのが現在の状況
ﾈｽｹの4がﾃﾞﾌｫだった時代のｵｼﾞｻﾝ が、Web全盛期の世の中でHTMLを無視してきたってやばいよ。
たとえ、まったく異なる分野の技術者だったとしてもです。
そんなことだから「どっから覚えたら」などという発想になるんです。
ﾈｽｹの4がﾃﾞﾌｫだった時代のｵｼﾞｻﾝなんだけれど
の裏に長年苦労してきて、あんたらの知らないことイッパーイ知ってる俺様
って含みがあるから腹立つ。
↓どうしてこれで止められなかったんだ？HTMLを知らない、それだけでいいじゃん。
HTMLとかCSSとか覚えようとしたらどっから覚えたらいいんだ？
ﾃｰﾌﾞﾙとTRとTDで組むとかでいいの？
>>254 お前、病気じゃないか…？
>>245 今時、Webのフリーツール沢山あるんだし、UIライブラリも沢山あるし、適当に中身覗いてみればいいんで無い？
納品用にhtml印刷した時に目次とページとかフッターとか入れられますか？
>>256 CSSでメディアタイプってのがあってそれを使うと画面表示と印刷するときで
ちょっと違う出力に出来る。
Officeソフトには、オートシェイプ機能があるけど
HTML形式で、オートシェイプと同じように自由に挿入したり、コメント入れたりできるの？
HTMLの印刷だけはもうやりたくないわ…。今はマシになってんのか？
仕様書というか納品物レベルの印刷ロジック組むのが死ぬほど面倒だった。
一画面一ページで収まるように書かれていれば楽なんだがな。
ページまたぎのテーブルとか死ねる。
>>259 SVG対応してるブラウザ少なくない？
それともHTMLで仕様書作るなら、IE9は必須って事なのか？
そんなの客と取り決めろよ…
HTML使いこなせないのと使いたくない理由で、言い訳並べてないか…？
ドキュメントの媒体なんて臨機応変に使い分けろよ。
だからってExcel方眼紙スタイルはないわ
早くて便利なら、理解できる仲間うちで使う分にはいいだろ。
まぁ、俺は使わないけど。
xhtml なら簡単に変換できそう。
xhtmlは出力形式。
何かからxhtmlに出力するのはありだが、
xhtmlから他の何かに変換するものではない。
なぜならXML（データ）にHTML（人間用文書構造）が含まれた結果
データとして処理しにくくなるからだ。
印刷なんて紙の無駄でしかないと思ってるけど、
印刷が前提ならWordあたり使ってちゃんとやるのが一番手っ取り早いわ
あと、ただの愚痴だけど、番号つき段落で処理途中に挿入されて番号がずれる、みたいなものや
変更点の文字色を変えるような必要になるものを、Excel方眼紙で作るな市ね
>>267 さすがに xhtml を直に書きたくはないけれど、
目次付きの印刷品質の pdf にするのは簡単だよ。
見出しも番号を自動で付けてくれるし。
>>267 引っ掛かるんです一応言うがxhtmlは、
htmlをxml基準で曖昧さを排除し、
パーサーの簡略化と互換性の強化を目指したものだぞ。
別に人間用情報が入ってても構わん。
そういう部分を分離したけりゃXSLTを使う
>>269 rest？興味だけで実用してないんだよな。
ツールはやっぱりSphynx？
>>270 曖昧さを排除したからといって扱いやすいとは限らない。
人間用に手を加えたXHTMLはCSSやJavaScriptで
必要なdivやspanがあちこちはいるから純粋なデータではなくなる。
やってみればわかるが、純粋ではないデータ（それはしばしば変更される）
であるXHTMLからXSLTを使って変換するのは苦痛でしかない。
様式に口うるさいヤツいるけど、矛盾点を突くと
「それは別の工程だから」とか「それは前のプロジェクトのでいまはこうだから」
とかいって結局、「いまの自分の書き方が正しいからね、既に書き終えた人は修正してね」の一点張り
>>273 それ、お前の理解力が低いだけじゃないよな…？
一度書き終えてOK貰った書類を、全部書き直せなんてマジキチ。デスマじゃん。
>>275 書き直しの理由くらい添えてレスしろよ。
リクエストパラメータで渡す項目一個一個書いたり、
入力チェックエラー時のメッセージを一個一個書いたり、
これくらいソースだけでいいだろと思ってしまうんだが。
ドキュメントに必要なのは画面イメージと処理フロー図、
簡単な処理詳細と、処理で使うDBのテーブル情報くらいでいいと思うんだが…
>>276 ただ一言、『わかりづらい』という理由だったりする。
ユーザー側の設計者だけでなく、誰が見ても何がどこに書いてあり、内容が即座に理解できるようにと。
それは妥当な理由だ。
理解できない書類作る方が無駄な作業だろ？
わかってないね
金がとれるドキュメントであることが重要なんだよ
日本のプログラマーは嫌儲なのか
金儲けが下手くそ
>>277 パラメータやメッセージは、ちゃんと書かないとプログラム作れないだろ。
不要なのは、項目名の後に項目IDをつけろ、つけるなとか言う文章表現的なものや、
外部設計書なのにプログラマが実装できるように、集計ロジックを書けとか言うもの。
Excel設計書だから、枠から文字がはみ出てるとか、漢字に誤植があるとか…
>>278 それは無理難題かもしれないな。
俺も昔やられた。
プログラムと一緒で、ある一定レベルまではわかりやすく書けるのは事実。
(日本語の使い方や、用語の定義の仕方、書く順番等)
ただ、想定する読者の優先度による可読性のトレードオフが発生する。
だから、誰が見ても解るドキュメントなんてない。
まずやるべきは、ドキュメントが誰にどのように使われるのかを定義する事。
次に、前提とする読者の知識レベルを定義。
次に、読者が複数いる場合、優先順位を決める。
相手の立場になって考える事は重要だが、無理なものは無理だ。
から、先に予防線をはる。
そういう文句を言う上司は多い。
>>277 何に使われるドキュメントか理解してない事が原因だな
そういう見た目や体裁、文体への指摘は、
レビュアー側が自分の好みでレビュー結果のブレが出るから、一概にどっちが悪いとは判断できないな
書式を厳格にするなら、プログラミングでの制約などと同じように
個々の裁量にまかせず仕組みで解決するのが最適解なんだけどな
言語みたいな感じで共通の書式がほしいわ
そういう金に直結しないドキュメント整理に費やす時間が勿体無い
いろんな人が見るようなマニュアルとかだとそりゃちゃんとやるべきだけど
業務系の割と簡単なWebシステムとか、万人が確認するわけでもない
仕様まわりの内部向けドキュメントとかでそういう事繰り返して工数削ってるのは、すごく無駄を感じちゃう
その体裁まわりの時間で、モック作ったりそれでUI検討したり、実装したりテストしたりしたほうが有意義だろうに…
俺自身は、本当に誰にでも理解できる設計書が存在するとは思ってないが、
受け入れを行う顧客担当者が考える「誰にでも理解できる設計書」を求められる。
結果として、顧客担当者が納得するレベルかどうかを手探りで設計書を作るわけだが、
俺はそいつじゃ無いので、何度も何度もやり直しを喰らうハメになる。
>>285 顧客担当者が考える「誰にでも理解できる設計書」の段階で、だいぶ無理があるよな。
審査する人間がどの程度スキルや経験持ってるか分からないから
初心者向けに書くのか、経験者向けに書くのか凄く曖昧なんだよ。
大抵、見積時点では後者向けのドキュメントを想定してるみたいだけど、
開発が進むにつれて人数増えてくると、初心者とかいろんな人間が混じるから、
より詳しいドキュメントが必要になってしまってる現実もある。
俺は、設計書渡されたPEがプログラム作れる最低限必要な条件や項目が記載されていればいいと思ってる。
>>285 そもそも顧客担当者が理解不足をドキュメントのせいにしている可能性もあるな…
>>287 担当者いわく、自分なら今まで打ち合わせをしてるから理解できるけど、今後担当が変わった時に仕様が伝わらないような設計書はダメってことらしい。
俺には、人ん家の未来の担当者レベルを予知する能力は無いっての。
>>288 具体的に指摘してもらって、そこだけなおせ。
自分で考えろって言われたらそのまま出して、これで解るレベルの奴を雇えって言え。
両方ダメなら殴っていいぞ
>>288 レベルの低い担当者だと、自社の業務の流れすら分かってない奴もいるからな。
そんな奴にまで分かる設計書書けとか言われても困るw
説明書とかじゃないんだから、日本語の言い回しレベルでの指摘しかしない奴は、
すぐにでも担当からはずしてほしいわー。
よくそういう指摘をしてる場面を見かけるから、
ああいう人はレビュアーからはずしたほうがいいんじゃないか、って思ってしまう。
レビューする奴が当てにならないときは、わざと間違えた内容を混ぜてみるといいな。
ちゃんと要点を確認する人ならすぐに指摘してくれる。
もし仮に通ってしまっても、そこは後で気づいたことにして再修正かければいいし。
性格悪いやり方だけど、事前に危険回避できるって意味では手のうちだと思う。
誤字脱字はレビュー以前の問題だからな。
勘違いすんなよ。
言い回しへの言及は説明書レベルなら普通にやる。これもレビュー以前の問題だ。
ワザワザレビューで指摘されてんだから有難くおもえ。
>>286 > 俺は、設計書渡されたPEがプログラム作れる最低限必要な条件や項目が記載されていればいいと思ってる。
そんな丁寧に書かれた設計書なんて滅多にないけどな。
その業務特有の用語すら説明されていない設計書ばかりだ。
プログラム仕様書をA HotDocumentで作るから使い方を調べとけといわれてる
で、やってみたら～.designer.vbを読み込んでくれない
やり方わかる人いたら、教えてくださいな
HotDocumentは仕様書を作るものではなく、
仕様がわからないソフトの解析の
ちょっとしたヘルプができるかな？みたいなもの。
あとは、客にこんなに作りました！って
騙すものだから、
designer.vb程度読めなくても
いいじゃないかアハハハはは
>>293 それでどうやってプログラム作ってるの？
知ってる人「知らない」(嘘)
とか、平気であるけどな。
人格破壊の負のスパイラル。
できるできないじゃない。
やるんだ。
302 ：
仕様書無しさん：2012/01/18(水) 21:40:45.99
r.vb程
みんなはＤＦＤとか書いたりしてる？
書かない。そんな暇はない。
DFDって、書きにくくて分かりにくいと思うけど。
業務フローならアクティビテ図がいいと思う。
なんだろう、よくUMLを既存のダイアグラムのスーパーセットのように捉える意見を見るが、そもそもの視点・指向が違うしな。
こっちの方がいい、いやあっちの方がいいという意見は首肯し辛いな。
と思ったが、ちょっと穿った見方だった。すまん。
いや、事実宗教戦争になりつつある
単なる民族間抗争だろ。
アジャイル開発やってる人は何をドキュメントに残しているんだろ。
色々。プログラムに関するドキュメントは殆ど書かないけど
色々って？
赤とか青とか
立体的に見えるやつだな
ホワイトボードに描いた落書きとか、いっぱい入ってるよ。
>>315 ホワイトボードの落書きをドキュメントとして納品してるってことか？
アジャイル開発でも、最終的には確定した仕様書や設計書を納品しなきゃいけないと思うんだが、
どういう形式でやってるのか、よく分からないんだよな。
>>316 最終的に確定したら、それはアジャイルじゃないよ。
アジャイルは常に進化し続ける事にメリットがある。
納品しないのは、誰の都合？
少なくとも顧客の都合じゃないよね？
>>317,
>>318 納品しないってことは、準委任契約で開発するってことか？
それでも、内部設計書くらいは残すんだよな？
自社サービスなら納品て概念が無いんじゃないの
322 ：
仕様書無しさん：2012/01/22(日) 17:00:17.40
偽装請負なら、「作業報告書」って言って週報レベルのものを出してもＯＫだよ
常に進化し続けるシステムを作りつづける方式がアジャイルであるのに、開発費用を抑えたり、要件がまとまらない場合の銀の弾丸みたいな考えでアジャイルやろうとするから、納品物がどうとか話がおかしくなるんだよ。
予算確保→システム作成依頼→納品物受領→プロジェクト終了
これはアジャイルでは無い。
その時々にある予算の範囲内で、無理なくシステムを作り続けることがアジャイルなんだよ。
発注形態なんて作業請負、派遣、定期雇用に決まってる。
本来はマだけど、最近は見積もりするばっかり。
アジャイルって、作る側も顧客側もどっち側にもメリットはあるんだけど、
作る側個々の能力とか結構重要だから、にわかは死ぬし、
理解力の無い顧客の場合もすぐ破綻するし、土方産業には向いてないんだろうな
人売りとか中抜きがしづらいやり方になるから、そういうので食ってるとこにメリットないし
そもそも、上のやり取りからしても、既存の枠が染み付いてるお偉いさんとかは、なかなか理解しきれない
326 ：
仕様書無しさん：2012/01/22(日) 19:12:20.56
うちの場合、アジャイルに対する理解度合いがばらばらで、アジャイルを推進してる人は、要件の管理方法くらいにしか思ってない。技術的な考慮なんて一切なく、WFの考え方から抜け出せていないまま押し付けてくるから、現場は混乱。
現場は現場で、WFでやってた事そのままで、テストコード書けばアジャイルだよね~ってことで始めるが、テストコードのメンテはされずコストだけがかさむ。
>>327 WFとはおそらくウォーターフォールの事だと思うけど、
そういったローカル用語(俺様用語)が飛び交う現場では
混乱と混迷の渦から抜けきれないのは当たり前だな
アジャイル手法うんぬん以前に問題がある
ウォーターフォールって、ローカル用語か？
それに、アジャイル開発なら少数精鋭でチーム組むんだから、ローカル用語でやってもいいんじゃん。
この文脈でWFが何の略語かわからない奴はもぐり
浮いてる奴はもぐり
文脈から推測はできたけど、んな略記は初めて見たな。
使うなとは言わんけど、俺々略語って恥かくことあるし、多用はしないほうがいいとおもう。
同じく推測はできた。
ただ、一般的ではない用語や略語を使う人間は仕事場では混乱を招く人の可能性が高い。
同じ現象がコードにも現れる。
>>331みたいな返しをする所が論外。
自分の勤めてる会社の常識しか知らない人なんだろうね。
井の中の蛙になってる。
瞬間的にワークフローと読んだ
井の中の蛙
大海を知らず
知ったところで
海水じゃぁ蛙は生きていけない
よかったね
知らなくて
特許庁の新システムの開発中断のニュース、
原因が東芝ソリューション側の設計遅れになってるけど、
実際のところ、何が悪かったんだろうな？
ユーザが出す要件が矛盾だらけとか、二転三転したという可能性はないのかな？ とシステム屋を擁護してみる。
中国の特許を日本語で検索できるシステムなんて、嫌な予感しかしない。
50億だかの設計料払って、それは回収しないんでしょ？
原因が東芝側なら損害賠償ものだと思うけど、
そうしないということは特許庁の問題で東芝が泥を被ったか。
>>341 製造までいけてれば東芝はアウトだったろうけど、設計すら終わってないからな。
東芝もダメダメだったろうけど、それ以上に特許庁の担当がダメだったんだろ。
まあ、この展開だと、他の公官庁向けの大型案件に東芝は入れないだろうけど。
管理がアクセンチュアの時点でやな予感しかしない…
344 ：
仕様書無しさん：2012/01/27(金) 08:06:06.70
組み込み系開発で
設計書にRAMマップやROMマップを書いてるんだが、
ほとんど見る機会もないのに、載っける必要性ってあるの？
お前が見ないからって、他の全員が見ないと思い込んでないか？
346 ：
仕様書無しさん：2012/01/27(金) 21:45:40.69
俺も見ないぞ
347 ：
仕様書無しさん：2012/01/27(金) 23:45:08.48
お前が人からシステム預かって
どれどれプログラム見てみるか、まずはメモリマップから・・・ってメモリマップねえじゃん！
って想像してみろよ、どうすんだよ
メモリマップ想像すんのか？
仕様書書き上げるまでコーディングはさせんぞ
349 ：
仕様書無しさん：2012/01/29(日) 12:33:26.05
>>347 メモリマップ見るより、コード見たほうが早くね？
それと、ほぼCとかで書いてるはずだから、システムによっちゃ
メモリマップはそれほど重要でないことが多いし
メモリマップは誰かの頭の中だけにあります
なんて状況よりは、ドキュメントに書いといた方がいいだろ。
351 ：
仕様書無しさん：2012/01/29(日) 23:46:26.87
>>349 コード見る方が遅いだろ
ROMとRAMくらいの分け方ならまだしも
「ここからここまでは揮発、ここからは不揮発」みたいなのも入ってくると大変だろ
コードにコメント書いとけってのは無しな
352 ：
仕様書無しさん：2012/01/29(日) 23:58:35.26
WindowsとかPhotoShopとかの開発ドキュメントってどんなの書いてるんだろう？
353 ：
仕様書無しさん：2012/01/30(月) 22:17:22.55
仕様を完璧に決めるために案件とって来た部署を徹底的に問いつめて
少しでも矛盾や未決定事項が見つかったら追い込みをかけ、次の日
朝一で顧客の所にいかせて仕様をきめさせ、持ち帰りになったら毎晩
催促の電話をさせ.... ってやってたらなんかこっちが悪者にされた。
もう仕様を適当に決めて仕様変更を下請けに吸収させた方が気楽でいいことに
きがついた。よく考えたら上流行程にせっかくいるのにわざわざ苦労することないし。
>>353 >仕様を完璧に決めるために案件とって来た部署を徹底的に問いつめて
>少しでも矛盾や未決定事項が見つかったら追い込みをかけ、次の日
>朝一で顧客の所にいかせて仕様をきめさせ、持ち帰りになったら毎晩
>催促の電話をさせ.... ってやってたらなんかこっちが悪者にされた。
明らかに悪者だろ。
355 ：
仕様書無しさん：2012/01/30(月) 22:47:05.53
>>354 そっか・・
その後の手戻りは明らかに少なく予算内にも収まったんだけどな..
今度から多少の仕様の矛盾は目をつぶることにしたいんだが、どの矛盾は
無視してよくてどの矛盾は指摘しないといけないかの見分けが一瞬でつくほどには
まだスキルがないんだよな。
「矛盾がある・未決定事項である」ってことがわかればそれでいいんじゃね？
どっちに転んでも大した違いが無い項目ならどっちに転んでも大丈夫なように作業進めるし、
そうじゃなきゃ「決めないと作業進まないんですけど」って言ってくるだろ。
357 ：
仕様書無しさん：2012/01/30(月) 23:11:52.78
>>356 確かにいわれてから決めればいいんだけど、その間2,3日下流行程を止めていることに
ものすごい罪悪感を感じちゃうんだよね..
むかし止められる立場だったこともあるからなおさら。
きちんと回る範囲ではきっちりかっちり決めといたほうがいいし、そういう人も一人くらいは居たほうが便利だとは思う
でも人付き合いが下手な人がそれやると、できない連中から敵意向けられたりして
くだらないことで対立始めたりして、あほな気苦労増やすだけになったりするしな
上流のほうはスキルがあるのは最低条件で、人をうまく乗せたり、信頼されるようなとこが重要なんじゃないかな
結果がよくても、悪者にされたのならそのあたりが不足してたってことだと思う
詳細設計書から要件が読み取れないのが厳しい。
目的が書かれず、手段だけ書かれても物理的な矛盾しか指摘できない。
詳細設計書が完璧な前提なら成り立つけど、人が作成する以上、ミスは避けられない。
足元だけを照らす詳細設計書じゃなくて、目的地を見据えた上で「それを実現するためにこの手段が必要ですよ」っていう
詳細設計書がほしい。
>>359 設計者やお客さんに聞いて仕様を確認するのが本来だけど
詳細設計書を元にプログラム作るコーディング請負の仕事なら
わけわからんまま設計書に書いてあるとおり作るしかないんじゃないか
理屈としては指摘するのがただしい。
ただ、人間は正しい正しくないだけで動くとは限らない。
言い方次第では正しく動いてくれなくなる。
相手を見て言い方や伝え方を変えたり、根回しをするなどする事も一つの技術。
仕事の成果を優先するも、自分のやり方を優先するも、あなた次第。
自分の人生に有益な戦略をどうぞ。
>>359 >詳細設計書から要件が読み取れないのが厳しい。
それは、詳細設計書の意義から外れるのではないかと思う
詳細設計書は実装の大まかな枠組み(論理構造)を記述するもの
システムの目的/要求/前提といった事柄は、さらに上流の設計書で記述されるべきで、
詳細設計書での重複した記述は避けるべきだと考える
もしも、
>>359が「詳細設計書だけ」を渡されて実装段階で悩んでいるのなら、
まずはそれを率直に上流工程の担当者に伝えて、上流の設計書を入手することを考えよう
そして、もしもその要請が拒否されたのなら(「オマヘハイハレタコトダケヤレ！！」)、
それを(証拠として)記録した上で、(
>>360の言うように)そのまま実装するしかない
普通は詳細設計書を読んだだけで、要件が分かる訳がない。
要件を満たすために処理をそれぞれ分解して詳細設計書に落とし込んでいるはず。
きっちりと部品化して設計されていれば要件を知ってる必要ない。
そんなに要件が知りたいなら、要件定義書を見せてもらえばいい。
>>357 未決定事項があれば
依頼側にそれらの情報をいつまでに出せるのかをヒアリングして、
製造側にそれで作業スケジュールに問題が出ないかをヒアリングして、
その結果を整理してスケジュール決めてくのも仲介役のお仕事。
もし一件未決定事項があるだけで作業が何日も止まるようなら、
そもそもそんな作業スケジュール(というよりワークフロー？)がおかしい気がする。
365 ：
仕様書無しさん：2012/01/31(火) 07:23:51.68
>>358 できないというか決めないといけないことをそもそも理解していない部署に
その必要性をわかってもらう柔らかい言い方ってどういうんだろうな..
どんな言い方しても相手の考慮不足を指摘している以上反発は食らうわけで
しかものんびり待っていたら1ヶ月以上ほっておかれた過去の経緯もある。
これが組織間の板挟みって言うならそうなんだろうけどなんか違う気がする。
上長を通じて申し立てる。
個人で動くべきでない。
>>365 > どんな言い方しても相手の考慮不足を指摘している以上反発は食らうわけで
考慮不足＝ちゃんと考えろやボケェ！
ってニュアンスになってない？
「このあたりの仕様が抜けてるような気がするんで、いついつまでに確認お願いできませんかね～？(∀｀*ゞ)ﾃﾍｯ」
ってな感じでアプローチしたら、そんなにモメないような気がする。経験上。
そこで決まらなかったら、後は野となれ山となれ～だよ。
エビデンスだけは押さえといてね。
毎日、朝と晩に呼び出されて催促されたら、その担当者が鬱病になっちゃうぜ。
お客さんの事情もあるし、すぐに回答できない質問事項もあるだろうよ。
質問の仕方も
「どうするんだ!?」っていう相手に丸投げの質問するより
「A案とB案のどちらにしますか？」って質問した方が
相手を誘導しやすいし、回答を得やすい。
相手に案を提示できるようになるには、それなりの能力が必要だけどね。
「A案とB案のどちらにしますか？」
客「良くて安い方」
そんなこまめに催促したって、体が二つになるわけじゃ無いんだから、スケジュールのネックになる事を伝えて優先度つけて作業してもらえば済む事だよな。
それで全体が遅れたらそれはそれで仕方がないよな。
自分に非がないと攻撃しちゃうタイプなのかな？無意識？
>>370 世の中には進捗表に優先度の項目があるけど、それが全て高になっている
プロジェクトもあるわけなのだが。
アプリの質にもよるが、推奨案まで持って行けたらベストだわね。
決められない人たちに判断基準を示してあげるのも大事だと思うよ。
上流でやっとけや！(#ﾟДﾟ)って話はあるがね。。。
>>371 俺も見た事あるけどさw
スケジュールの足引っ張る項目を伝えればさすがに優先してもらえるし、ぶつかってたらマネージャーが仕事する番だろ。
>>372 こっちが考えてやると、次から当然の様に仕事押し付けてくるってのもあるなw
375 ：
365：2012/02/01(水) 23:53:42.85
>>368 たしかに担当者を追い込みすぎる癖があることはわかってる。
特に担当者が最初に「何でそんなの決めないといけないんだ」的な
反応をしてきたときに、徹底的に追い込んだことは何度かあるな。
コミュニケーションスキルは本当に難しいな
気持ちは分かるがやっちゃだめだ。
頭にきても手を出しちゃいけないのと同じだ。
足ならいいか！？な？
反感をもたれるような持ち掛け方をしてるか、
既に嫌われてて煙たがられてるかのどちらかって可能性もある
慕われるように仕向けて、自分からやっとこうって思わせれるようにしたほうがメリットあるのにね
>>360 >>362 レスありがとう。
実際それが正論で、そうあるべきだと思う。
けど、(今の現場では)詳細設計書が基本設計書を満たしているか否かのチェックが機能していないんだ。
詳細設計～テスト実施にかかわる人が要件を把握できれば、詳細設計書の漏れや、要件の漏れがある程度チェックできるはずだけどその工数は
なかなか認められない。けど、請負う側はそのリスク(要件の漏れや、詳細設計のミスによる仕様変更)まで背負わされる(「普通に考えればわかるでしょ」って言われる)。
んな事を考えると行き着くところはアジャイルだけど、発注側はリスクを背負いたくないから契約形態は変わらない。
「より良い物を作りたい」だけなのに責任の擦り付け合いになっちゃう。
あ～明日の仕事も憂鬱だなぁ。。。
380 ：
仕様書無しさん：2012/02/02(木) 07:51:31.68
>>378 そりゃ理想論としてはそうだけどそんな平和な現場って実際あるのか？
もっとギスギスしているのが普通だと思ってた
>>379 お前またはお前の会社は、詳細設計書を渡されて実装～単体テストのみを請け負ってるのか？
だとしたら、要件への適合性なんか考える必要無い。
>>379 >(今の現場では)詳細設計書が基本設計書を満たしているか否かのチェックが機能していないんだ。
問題は、詳細設計書から要件を導き出せないことではなくて、これが問題なんだろ？
だったら、詳細設計書をアウトプットする奴らにちゃんとしろと言えよ
それとお前の成果物を受け取る奴の受け入れ基準を聞けよ
>>380 むしろ、わざわざ反感買うような奴が続けられるようなヌルい職場が
まだ残ってるんだと驚いた。
反感買うような言動する奴は徹底的に苛められて追い出されるのが普通じゃね？
>>382 おそらく詳細設計書を複数人でレビューしてなくて
上流で発生する仕様漏れや間違いが発見されずに
実装させられてるんだろう。
SEがスキル不足でPEが毎回墓穴を掘らされてれば、
自衛手段として実装前に要件を確認して、
設計に問題が無いかくらいは確認するようになるよ。
385 ：
sage：2012/02/02(木) 14:48:04.24
プログラマー
>>379 設計担当と実装担当が別会社なら、渡された設計書をそのまま実装した方がいい。
自分の仕事以外の余計な事して、コストをかけるのは無駄。
仕様変更があれば、その仕事分を集計して、請求するか交渉の材料にする。
同じ会社なら、
設計が正しいかSE達でレビューをしっかりやってもらうしかないと思う。
あまりにもミスが目立つなら、リーダーや上司に訴えろ。
388 ：
sage：2012/02/02(木) 15:14:13.03
>>387 全くその通り。
自衛が必要なら、前工程の成果物の妥当性を再検討するのではなくて、別の手段で。
>>384 詳細設計書かく人をSEと呼ぶですか・・・。
おっと、超久しぶりにブラウザで書き込んだもんだから、sage間違い
>>388 詳細設計を素人の客が見るならSEが書いた方がいいよ
PGが書いた詳細設計はいい意味でも悪い意味でも素人には読めません
そもそも、詳細設計を素人が見る必要があるのか？
何のために見せるんだ？
詳細設計なんぞお客に見せない（見たがらない）もんだと思ってた(´・ω・｀)
詳細設計書作成がなかなか進まない
分からないところがあってソースを確認するはずが、気が付いたらコーディングしてる
どうしよう
>>393 その場合はコーディングしてから設計書書いてコード見直す
プログラミング言語のほうが直感的にロジックを記述できるのは自明
で同時に設計書も書くことで仕様が整理されてコードの間違いにも気付く
>>381 >>382 >>387 ありがとう！ふっきれた！
今まで、自分が製造担当した箇所で(要件漏れやドキュメント不備による)不具合、トラブルが発生したとき、
責任を感じてしまってた。
「製造担当」は製造に責任を持つべきで、「設計」の責任まで負う必要はない。
ただ、馬鹿正直に詳細設計書通りに実装するんじゃなくて、気づける箇所があれば要件を聞く。
その結果変更が必要なら変更分を請求すればいい(自社が設計して、変更にかかる工数を確保できなければエスカレーションする)。
(なんか文字に起こすと当たり前のことすぎるね。。)
よし、明日もがんばろう！
>>393 スケジュール通りに成果物(設計書とソース)が上げられるならそれでもいいんじゃない？
けど、try and error だと残工数見積もりにくいよね。
詳細設計書に求めてる粒度が細かすぎるのでは。。。
>>394>>396 アドバイスありがとうございます。
今までは先にコーディングしていたのですが、今回のプロジェクトは詳細設計書だけ先に提出しなければいけなくて…。
細かくやろうとしすぎてるかもですね。
398 ：
仕様書無しさん：2012/02/02(木) 23:53:08.30
>>383 いやな奴や、客観的にみてもその場にいない方がましな奴でも平気で居座るのが
デスマというものなんだが。。
仕事はきついけど連帯感が生まれて現場は和気藹々だとでも妄想しているのか？
詳細設計書の書き方がよく分からなくて、
自分がコーディングした場合を想定したロジックを
そのまま言葉に起こした設計書を提出したことがあったな。
その後に上司に注意されたよw
400 ：
仕様書無しさん：2012/02/12(日) 15:15:49.08
みんなUML使ってる？
クラス図とかシーケンス図とかよく使うな。
ユースケース図とかアクティビティ図とかよく使うな。
>>398 お前かわいそう。人を人として見られなくなったら終わりです。
仕事は仲間とする方が円滑に進む。綺麗事じゃなく。
徹底的に追い込むとかお前何様よ。お前も雇われの身だろーが。
お前の思考回路って、都会的と言うよりも在日じゃねーか？
>>403 アンカは
>>383のタイポかな？
内容については、同感
そういった職場の雰囲気は、リーダの性格によって形成されるのだと思う
405 ：
仕様書無しさん：2012/02/15(水) 19:57:04.45
>>403 仲良し同士で低レベルなシステム作って一生喜んでいればいいじゃん。
そのうちインド人に取って代わられるだろうけどね。
本当のチームはチーム同士切磋琢磨するし、自らの責任を果たさない
フリーライダーはあっという間に排除する。
>>403 お前は草野球。
プロ野球でスタメンになりたければ、人より秀でる必要があるって話。
プロのメンバー選考で手をつないでゴールしても落とされるだけだろ。
仲良しごっこだろうとライバルごっこだろうと結果が出せなければ意味無いな。
408 ：
仕様書無しさん：2012/02/15(水) 23:26:09.20
>>407 その通り。
自分以外の部署の人間が鬱病になろうがそれはその部署のマネジメントの問題。
中ではチームの力を最大限に生かすチームビルディングを行ってマネジメント能力をあぴーるし、
ほかの組織に対しては弱みを見せた瞬間に徹底的に追い込んで弱体化させるのが
組織の中で生き抜く秘訣。
結果を出すことと組織の中で生き抜くことは全く関係ないな。
仕事仲間のことだと思ってるんだが、どこで仲良しに変わったの？
お前らコンプレックスで過剰反応し過ぎじゃね？
この10数年の会社教育は嘘で洗脳だから、そろそろ目覚ましの時間ですよ？
アットホーム()とか、まぁ良くも悪くも日本っぽい事ではあるし、それで成功してるとこもいっぱいある
別に和気藹々やるのがダメだとは思わん
ただ、そういうのを強調する人は、大抵自分から学んぼうとかしないで
低いレベルで仲良しごっこしたがる人が多いからなｗ
仲間意識をつかって停滞することに安心してる、みたいな
無理やりスレタイの話題に振るなら、そういう人が書いた仕様書は、割とひどいｗ
412 ：
仕様書無しさん：2012/02/18(土) 12:34:04.54
新人が作った顧客に出す設計書のタイトルが↓だった
～♪♪ ○○設計書 ♪♪～
客も喜ぶかもよ？
中身がしっかりしてれば、外見なんて気にしない。
中身がなければ、怒りが増すがな。
客によるとしか言えないな。
新人なりに見栄え良く見せようとしたんだろ。
OJTで放し飼いして、ロクな教育してなかった奴が悪い。
417 ：
仕様書無しさん：2012/02/19(日) 17:16:55.09
新人だと思ったら４０才くらいのおっさん個人事業者が作った設計書らしい
ジョエルのファンなんだろ
>>392 完全なエンドユーザーが見るわけじゃなく、
客先のシステム担当が次のシステム改修の際に使うんだろ。
それか、基本設計書にエラーコードとか、要点じゃない
雑多な仕様が記述されてない場合とか。
システム改修など、細かい部分が重要なのに、それが抜けてる仕様書は困るんだよね。
エラーコードとかは分からなければ、ユニークなコードで追加していけば問題ないが
データの抽出条件とかは、複雑だと調査に時間がかかってしまう。
そういうのとても書ける量じゃないときがあるけどどうやって管理してんだろう？
結果の合否判定がやたらと複雑で仕様書にもどこにものってない箇所とか普通にあるんだけど
ソース見ながらでもうんざりするぐらい長いんだけど
管理してないんじゃねｗ
担当が居なくなってから火を噴く、みたいな
出来上がったソフトの動きが仕様です。
そもそも要件が定義されていない。
回路図を渡され、顧客とやりとりしたメールの断片が転送されてきて
1ヵ月後までに仕様書と実装とテストを終わらせておけ
といわれる俺は既に色々あきらめている。
某日本で一番入りたい家電メーカのとある職場の風景
日本の家電メーカーとか最初から終わってんじゃん
入りたくねーｗ
家電とかの電子回路は商品ごとに作り直せるから無問題
日本のものづくりw
技術者を大切にしないから、衰退の一方だなwww
>>421 誰かが何らかの形で残してなければ、何も無いんだよ。
大概は、最初のうちはちゃんと作ってるけど、
プロジェクトがヤバくなると、ドキュメントの修正も手がまわらなくなる。
ある程度、体裁が整った設計書をコピペして使い回すから、
潜在的なバグ・仕様上のバグが爆発的に広がる。
まさに負の連鎖w
>>424 それはマネしたさんではなくてエスプーさんのことですね。
人売りが技術系にはびこってしまったからなぁ
スキルの安売り状態で業界がどんどんだめな方向に向かってる気がするわ
スキルなくても底辺で食ってけるから、そこで安心しちゃってるようなの多いし
仕様書については未だに悩んでる。
1つの提案なんだが、コードにlatexで埋め込んで
仕様書を自動生成するか
そうでなくてもワードよりはtexのほうがいいとおもう。
どうせpdfで出図すればいいんだから。
なんでwordを進めるのだろう。
酷い場合はexcelで書く馬鹿がいる。
しかし上司だからこき下ろすこともできない。
WordもExcelもMicrosoft Office Personalに入っているから
どの会社のPCでも導入時の状態のままで確実に読み書きできる、だろ？
texは他人と共有したいとは思わないね。
環境ごとに使えるテンプレやマクロが違うとかやってらんない。
latexはWYSIWYGじゃないからダメ。
逆にWYSIWYGで編集できるなら、
その中身がなんだろうと関係ないから
latexの必要性がない、
ドキュメントは結局糞Wordしか使えないって事が多いから諦めて一通りは覚えた
使いにくいだけでスタイルと文書は一応分かれてるし
初期設定さえできてしまえばあとは書くだけになるし、そこまで手間はかからない
使いにくいだけで
Excelドキュメント作るやつは全員ばくはつしてしまうといい…
>>431 お前はこれでも読んで勉強するといいよ。
Excelプロトタイピング――表計算ソフトで共有するデザインコンセプト・設計・アイデア
http://www.oreilly.co.jp/books/9784873114415/ なんでExcelはだめなんですかと聞くと、
Excelは表計算なんだから表計算にしか使ったらダメだ！という
それ以外の理由がない。頭が固いと思う。
Excelが優れている理由ならたくさんみつかるな。
ワークシート単位だから、文書が増えてもワードみたいにページが変わったりしない。
ワークシート＝タブと考えれば、タブと同じ便利さがある。
図形を入れられる。それでいて文書も数値計算もできる。
大まかな座標が合わせやすい。
Excel=表計算という固定観念を捨てて、方眼用紙ソフトと考えれば、万能ソフトだって分かるだろう。
万能ソフトだろうが何だろうが、まともに文章が入力ができないソフトはダメだ。
挿入 - オブジェクトで「Microsoft Word 文書」を選べばいいよ
WordよりはExcelの方がいいな
Excelが万能って理由もあるけど、Wordがダメ過ぎるってのもあるんだよ。
>>431 ソフトウェア開発ではなくてネットワーク構築の事例になるけど、
UNIXサーバの設定仕様書をLatexで書いて、PDF文書として納品していたことがある
・Latexを選んだ理由は、文書を自動生成できるから（機械にできることは機械にやらせよう！）
・サーバの設定ファイルからLatexの章/節/リスト/テーブルを生成するスクリプトを開発 - (a)
・自動生成できない部分は、独自の定義言語を設計してその言語からLatexソースを生成 - (b)
・仕様書全体では100ページを超えたけど、Latex手書きは設計方針を記述した先頭20ページだけ
・スクリプト等のツール類の記述言語は、(a) Ruby と (b) Prolog
・事前にPDF文書による納品が可能かどうか確認要(大半の顧客はWordを希望/要求する)
あと、「コードにlatexで埋め込んで仕様書を自動生成する」提案については、
「文芸的プログラミング」という発想がある（詳しくは、ググると解説が見つけられる）
さらに付け加えると、将来性の面で(Latexよりも)「DocBook」と呼ばれるXML文書形式がオヌヌメ
まだ実用上の課題は多いけど、HTML/PDF/EPUB/ODF(Open.Office)等への変換が可能
Excelで作られた文書って、目先しか考えてないからなぁ
文章を書く、ってのが前提にあるなら、Excel使ってる時点で全部糞以下だわ
更改されない使い捨てなら別に何でもいいけど、仕様書とかをアレでやられてると、げんなりする
Excel方眼紙仕様書は高確率で、
章番号段落番号とか、修正自色変えとか、一部分だけ取り消し線とか
挙句の果てには印刷レイアウト見ながら列幅の調整、文章の分割を行わないといけない、とか
糞ルールのおまけがいっぱいついてくるしなｗ
操作性悪いI/Fや、ちょっとした誤操作で設定してるスタイルぶっとばしてしまうような
うんｋWordはダメダメのダメダメダメダメだけど、それでもちゃんと使えばExcelよりかは手抜きできるから使いようだと思う
問題の根本原因は、Wordですら理解できないのが多すぎることだと思う
そういう奴らも仕事に関わる以上、結局サルでもわかるExcel方眼紙！みたいなのに助けてもらうしかない
普通の人はデータそのものと視覚的デザインの分離が正義だとは微塵も思ってない。
いかに正確に、効果的に読ませるかに関してのアプローチにおいて
文章データと視覚デザイン、場合によってはアニメ、効果音すらも一体化しており切り離せない。
だから理系脳の連中がデザインの分離を叫ぶたびにこいつら頭沸いてんじゃねーのかと思ってる。
>>436 別に何でも出来るわけじゃないし、「万能」とはちょい違うと思うなー
Excelは、理解しなくても方眼紙としては使えるので、馬鹿でもわかるって感じだと思う
列幅行高さ変更を禁止される事多い方眼紙を使ってしまうと、改行するだけでカットペースト必要だったり、
笑えないギャグがてんこ盛り状態にはなるけど、それでも方眼紙として使う上での殆どのことは特に理解しなくてもわかるレベルだし
ほんとExcelすごいな…！！１
あと、Excel仕様書の反対理由で、表計算だからって理由を前面押ししてる人はそんな居ないんじゃね
「そもそもあれは表計算ソフトで、文章を書くためのものじゃない」っていうような言われ方ならちょいちょい見るけど
それって「表計算ソフトだからー」、じゃなくて「文章作成機能付いてがないからー」って意味っしょ
もし、前者のように捕らえちゃってたのなら、多分Wordの機能と、Excelの機能の差をちゃんと理解しきれてないんだと思うぽ
修正の履歴つけたり、番号振ってくれたり、用語を参照してくれたり、目次つけたり、段落やレイアウトやってくれたり、
印刷を面倒みてくれたり、みたいな文章の作成向きの機能がExcelには殆どついてないから、
どっちも一通り触ったことある人は、流石に文書作るのにExcelはねーな、ってなるんだと思う
文書を電子データのまま活用するか、プリントアウトして活用するかの文化の違いに見える。
ついてる機能を知らなくても、方眼紙エクセルなら力技で何とかできるからなぁ…。
ワードだとその機能を知らないと出来ない事が多数あるから、学ばない連中は拒絶反応を示すんだと思うよ。
検索や置換機能のあるエディタが手元にあっても、その機能知らないから、全部手作業で単語の書き換えをやる奴いるのと同じ話。
別に個々の仕事で簡潔する事なら、どうぞ好きに力技披露してくって感じだけど、
俺までそれに合わせないといけないってなるのは、すごく面倒。
UMLって全部、多次元配列で表現できるような気がするんだ。
いや、具体的に検討したわけじゃないんだけど。
wiki文法に組み込めないかな。
>>443 ここマ板だしなｗ
仕様の修正で、中身となんも関係ない見た目まで毎度再調整とか、無駄じゃね
ブレブレの仕様とかだと、仕様ちょっと変わるたびに見た目まで再調整とかになったりするんだぜ
基地外じみた章番号の修正とか、気が狂う奴が出兼ねない…！
そういうのがめんどくせぇ、ってのに理系だの文系だのは関係ないと思うｗ
>>445 印刷する気ないのに、印刷レイアウトではみ出しがないかチェックしろ、みたいなアホなルールも結構みるけどなｗ
レビューでんなとこチェックしてる時間あったら、内容の不備がないかをチェックしろよって思うこと多々
基本的に方眼Excelのくせに、一部分だけ表を書きたいためなのか
横長なセルがあったりすると非常に萎える。
プログラマだけど文系だからな俺
Texとかまじわからん
Excelが文章作成ソフトじゃないのはわかるんだが、Wordは不親切な親切が多すぎて使っててイライラする
はっきり言ってどっちも使いたくないけど二択ならExcelの方が扱いやすい
> Texとかまじわからん
HTMLわからんって言ってるようなものなので、ちょっと恥ずかしい。
方眼紙にするだけならまだ許そう。お前ならまだ切り貼りもだいたいできるし、他からのペーストもわりと受け入れてくれる包容力がある。
だがセル結合、テメーはダメだ！
>>450 イライラすんのは理解力がない自分のせいだと思うぞ。
俺も前は、Wordは勝手に○○されるから糞って思ってたけど、結局それはなんでそうなるかを知らないからなわけだし。
項目名が意味フだったり、ヘルプも微妙だったりで、覚えるまで面倒なのはすごく同意できるが、
イライラしてても埒が明かんって調べたら、数十分ありゃ解決するような話だったこと多々。
Texも別に調べりゃすぐわかるレベルだし、わかるわからない以前に単にやる気がないだけだと思うわ。
Wordで章だてから真面目に書けば、そう悲惨なことにはならない。
書式は統一されたものを適応するのみ。
なんでも適当にやるからだろ……
>>450 Wordで文章書くとき、
一つの文なのに改行で行替えしたり、
タブや全角スペースで文字下げしたりインデントしたり、
文の一部を選択してフォントやサイズを変えたり、
目次を手でかいたり
してない？
そりゃ大変だよ。
>>450 TeXなんかなんかプログラム言語の文法と比べると簡単なもんだぞ。
文系と言うのなら不親切な親切って言う表現はおかしいだろう。
Wordは大きなお世話が多いのは確か。
Excel否定する長文をよく読むと
否定する理由の根拠が激しく乏しい件について。
>>453 > Wordで章だてから真面目に書けば
章立てする理由は？
本書いてるわけじゃないんだから
そんなの必要ないよ。
Ctrl+クリック(だっけ？)で即ジャンプできるじゃん
>>457 ぐちゃっと書かれてる仕様書はわけわからん。
いや、書いてる奴自身はわかってるのかもしれないけど。
コードと同じように、スパゲティ仕様書もダメダメだ。
章＝ディレクトリでいいやん
Wordはもうちょっとアウトラインが使いやすければなあ。
ファイルがひとつにまとめられてると
同時編集が面倒なんだよねぇ。
ほら、仕様書作成なんて一人でやらないでしょ普通。
モジュールに分けて仕様書つくればいいんじゃないのか
SEになって数年たつけど、Excelで仕様書作ってるよ。
請負中心だから客先ですでに決まってるフォーマットを使ってる。
Excel設計書に不満があるけど、
だからと言ってWordの利点も見出せないから現状維持。
使う人が使いやすいならエクセルでもいい。
自分しか使わないなら好きなので書けばいい。
ただ、Wordを批判するやつの九割以上がWordを使いこなせないことを責任転嫁しているのは納得いかない。
Word好きじゃないが、Wordでもファイル分けくらいできるぞ。
複数ファイル参照とかは普通に使うでしょ。
>>465 あるあるすぎるｗ
自分も昔そうだったからすごくわかるわ
不勉強だった自分を見てるみたいで、もにょる…
>>465 使いこなせない人には糞にしか見えないってだけだべ
責任転嫁とは違う
>>467 素直に言い給え、Wordも使いこなせないクズと
仕様書はExcelで良いと思うが操作説明書をExcelで作るのは止めて欲しい。
しかも章ごとにブックは分かれているし目次もページ番号も手で振っている。
>>457 仕様書っていう本書いてるんだよ。何言ってんの？
本や説明書って、フォーマットは何を使ってるんだろうな。
>>472 だいたいインデザとか。
所によっては、ページの少ないものはイラレでざくっと作る。
>>472 Adobeの製品ラインナップなら、FrameMaker一択
中小出版社の製本業務や企業の製品マニュアル作成における、
統一されたスタイルによる高品質出版に威力を発揮する
InDesignはSOHOやフリーランス向けの製品(イラレは論外)
あとASCIIの技術系書籍では、TexをエンジンにしたEWBと呼ばれる
独自の出版システムが使われているらしい(詳細はPDF版のマニュアルを参照)
・EWB(Editor's Work Bench)の概要
ttp://ascii.asciimw.jp/ascii/EWB/gaiyo/index.html また海外大手のO'Reilly & Associatesの入稿では、DocBookと呼ばれる
XML文書形式が推奨されている(DocBookについては、まずWikipediaを参照)
実際にDocBook仕様書のソース(原稿)はDocBook自身で書かれ、ソースと
オンライン版は無償公開、印刷版は有償でO'Reilly Mediaから発売されている
>>474 そーなのか。まぁ義弟の勤めてる会社は弱小だからかな。
見開き数Pの特集、小冊子くらいなんかは、チラシの延長でやっちゃうと言ってたけど。
trac + wiki で書いてる
断定できないけど、
本や説明書のフォーマットはWordやExcelを使ってないってこと？
>>477 ちゃんとしたところだと、それ用のソフトは普通DTPと呼ばれる物を使う。
Wordを使ってる場合もあるだろうが。
説明書ならWordで作るのも普通にあるよ
仕様書の表から構造体やクラスＤＢのテーブルまで作ってくれるようなソフトが求められている
ソースコードの構造体やクラスＤＢのテーブルから仕様書作ってくれるソフトのほうがいい。
次点として、そういうことができる専任の人間を雇ってくれ。
texがもう少し使い易かったら広まったろうに。
>>483 texが使いやすくても無理だろうと思う。理由は四つあって、
一つ目は仕事はあくまでも体育会系のパフォーマンスであって、マクロ組んで楽したりすると上司に怒られるという風土。
○○したら作業効率ＵＰするよ、と提案すると「俺の仕事を取るな」と怒られる場合もこれ。
二つ目は一般の人はデザイナーとかイラストレーターみたいな人種に異様な憧れと畏怖を抱いていて
テンプレに必要事項を記入しただけみたいな書類を提出しても、仕事したと見てもらえない風土。
最後、HTMLの歴史を見ても本来データ構造を記述する言語だったのに使う側は見た目とべったり癒着する記述しか知らない。
情報とその表現を分離するというITリテラシの欠如がある。
四つ？
>>484 >一つ目は仕事はあくまでも体育会系のパフォーマンスであって、(....以下略)
確かに、そういった風土はある
対応策としては、Tex活用を個人レベルで(こっそりと)実践して、最終的に業務上で
具体的成果を示す事ができれば、そんな上司も納得せざるをえないのではないかと思う
よくある失敗は、マクロを組む楽しさや細部の装飾ばかりに夢中になってしまうこと
一言で言えば、業務改善という「目的」とTex活用という「手段」の取り違え
>○○したら作業効率ＵＰするよ、と提案すると「俺の仕事を取るな」と怒られる場合もこれ。
これも、人にやらせるのではなく、提案者自身がリスクを背負ってでも実践する姿勢が大切
どこまで自分を信じて有言実行できるか、という話に帰着する
>二つ目は一般の人はデザイナーとかイラストレーターみたいな人種に(....以下略)
これはよく分からないなあ....
提出する書類というのは、最終的なPDF文書または印刷物だと思うから、何が問題なんだろ？
>最後、HTMLの歴史を見ても本来データ構造を記述する言語だったのに(....以下略)
その問題点を改善して文書の論理構造と物理構造を明確に分離した新しい技術が、
>>474で紹介したDocBook(論理: XML, 物理: XSLT)になる
まず論理構造と物理構造を明確に分離する理由がないよね。
488 ：
486：2012/03/04(日) 00:56:36.22
>>486の最初の事柄の補足として、
>>441のLatex活用事例を取り上げる
・Latex文書自動生成ツールは、「上司の目を盗んで」業務の合間に、あるいは
自宅で少しずつ開発/改良を進め、最終的なPDF文書だけを上司に見せた
・独自のTexマクロ定義は一切使わず、標準マクロと流通パッケージ(longtable等)だけで作った
・業務上の成果として、
・Latexから変換したPDF文書を納品物として顧客(大手SIer)に認めてさせた(認めてもらえた)
・当初は単なる構築案件だったのが、保守サポートという追加受注を得る事ができた
・当初はSIerから他社ベンダを介した孫請けだったのを、SIerからの直請けに変えることができた
を上げたことで、以降はLatex活用が「黙認」されるようになった
>>484 デザイナーやらイラストレーターから、本文の体裁とか段落付けとか取り上げると滅茶苦茶喜ぶぞ。
テンプレートエンジン作ったことあるが、狂喜乱舞して、むしろあっちから、ちゃんと表題は表題と表現してくれとMLで流れたり、
タグ定義を増やしてくれと直談判しにきたり、
甘い文書は開発者権限でおまえで止めろ、俺達の事わかってくれてるじゃねーか、と無茶言ってきたり、
色々いい経験をした。
俺が論文のtexのコンパイル環境を毎回解説して構築させんのが面倒だっただけなのにな。
作り話乙ｗ
向いてないのにこういう仕事選ぶ奴が多いのがなー
体育会系脳っぽいのが多くて、土方に拍車がかかる
そういうデザイン部分と文章部分を分けるための道具や仕組みの使い方を
理解できない頭が悪い奴を除けば、そのあたりを分離するデメリットって別に無いからなー
まぁ、そういう頭が悪い奴がいっぱい居る環境にはつかえないっていうのが、ある意味デメリットか
流し込み機能とか使っていれば
内部で自然と文章とデザインが分かれてるからね。
ファイル自体を分けたりして
見るときは合成する。
書くときは分離する。
なんてことやらなくていいからね
WYSIWYGエディタを使えば。
>>491 就職氷河期の時なんかはこの業界以外は人をあんまり募集してなかったからな。
特に専門知識なし未経験者歓迎みたいなのは他に無いし。 今でもそういう業界は
介護位しか無いんじゃない？ 何もない人は介護かITかの究極の選択という。
あーマ等向けの校正ツールが欲しい。
仕様書の何がめんどくせぇってホント誤字脱字がメンドイ。
>>495 そんなの気がついたら直すぐらいでいいよ
致命的なのは別として意味さえ通じれば流す方向で
ところで「あーマ等向け」ってなんだ？
糞リーダーになると設計上のバグよりも
誤字脱字やレイアウトを気にする馬鹿が意外と多い。
誤字脱字指摘してドヤ顔になってるのに、設計やユーザの使用感などの重要なこと指摘してもさっぱり伝わらない。
終いにゃ、やらなくていいって言って、切羽詰まってから自分でひらめいたかのように変更を決めて、丸投げ。
死んでくれ。
だが誤字脱字だらけの仕様書も困るだろ
内容が本当に正しいかすら信用できなくなる
値が一つ違うだけでもかなりマズイ
誤字脱字だったら、印刷した設計書に赤ペン引いておけばいい。
わざわざレビューの時にドヤ顔で指摘することじゃないよ。
いや、指摘するかどうかじゃなくて単に誤字脱字がマズイって話でな
誤字脱字はできるだけしない、レビューでみつけてなくす、ってのはそりゃまぁあたりまえだけど
それだけで満足するバカが多いこと、って話じゃないの
実際内容をきちんと理解できてるレビュアー少ないし
余計なことばっか指摘して、大事な中身まったく見てない糞な奴も結構見かける
能力ないのに長くいて微妙な肩書きだけがついちゃった系のオッサンとか、結構ひどい
>>496 「嗚呼、マ等(ら)向け」、じゃないかな。 == 「あー(感嘆詞)、ぷろぐらまーたちのための～」
糞仕様書の行間を読み解くよりは簡単な問題…！
誤字脱字、正しくない日本語、誤解を招く日本語、全部良くはない事は皆わかってるんだよ。
ただ、物書きのレベルをプログラマに求めるのは酷だろ。
それができるならプログラマ辞めて物書きになってるって。
必要な能力なんだけどね…
時間は限られてるから、なかなかそのレベルをクリアできる人は少ない…
でもあれだぞ。物かけない奴は概してプログラム下手だぞ。
とっちらかった文章だな、と思ったら、案の定プログラムもとっちらかってたりする。
箇条書きをうまく文章にやっつけました。って人の方がプログラムは良いことが多い。
日本人って学校で文章の書き方に関するエッセンスを習わないし教えないからな。
みんな自己流っていう笑えない状況。
とりあえずよ、校正じゃなくても、インテリセンス(オムニ補完)的なツール欲しいなぁ
章名を一部打ったら章の候補が出てきて、「.」押したら商に所属する値や名詞が並んで、
んで、エンター押したら指定の値がフィールドとして埋め込まれるとか。
とにかく下らないミス減らすツールが欲しいわ。どうでもいいことに時間掛けたくない。
形だけは教えられるんだよね。原稿用紙の使い方、とか。
フォーマット地獄は既に小学校から用意されてんのよ。
まぁ、プロの物書きですら難しいからな。
プログラムと一緒で、絶対的な正解ってのが無いのが辛いよな。
コーディング並みにガチガチするって手もあるけど、それこそ形だけのルールで本末転倒になりそうだし。
コードのレビューならコードをレビュー。
文章のレビューなら文章をレビュー。
正しい指摘を毎回できるようにして、プログラマを成長させる環境を作る事が、健全な業界の発展につながって望ましいと思うんだけどなぁー。
正解は本当変わる。読み手次第だよ。
俺は何度となく言葉足らずだと怒られてきた。
「ちょっと考えたら分かることでしょ、pp2-3と、p10で既に説明してるから省いただけです」といった感じで。でも怒られた。
怒られたことを教訓に、いちいち懇切丁寧に書くようになって、怒られる事は減った位の頃、転職した。
「君、これは、馬鹿にしてるのかな？もうpp2-3とp10で説明してることをくどくど書く必要は無いんじゃないの？」と転職先では怒られた。
どっちが正しいか判断はつかんな…
文章って好みがあるからね
だから軋轢生みやすい
ただ、指摘はいいけど怒ったり嫌味言ってくる奴はダメだと思う
表現の違いや誤字脱字なんかはどうしたところで発生するんだから
ドヤ顔してこれでもかと優越感に浸る奴は小物だしたかがしれてる
そういう上司とかリーダーは多いけどなｗ
レビューの場でいろいろと指摘が発生するのは当然のことだと思っているのだが
それを嫌がる管理者がいるのが嫌だな
>>509 このパターンは非常に多い。
好みによっても違うが、同じ人でもコンディションによって言う事が変わるのは腹が立つ。
デファクトスタンダードが無い以上、各組織においては過去の書類を参考にしながら書けということだな。
ごくごく自然にに考えよう。
設計とか分析とか工程というのは、
その次の工程を行うためにやる。
つまり、その次の工程の内容を理解していなければ、
使えないものが出来るのは当たり前の話。
たとえば使えない設計書。これができてしまうその原因は
その次の工程を全く知らないからだ。
自分の担当工程だけやって、下流の内容は知らないじゃだめなんだよ。
プログラミングができないSEはクズと言うのは正しいということが分かる。
>>509 あるあるｗｗｗｗｗｗｗ
内容読みきれず、そのときの気分だけで思いつきの指摘する奴多すぎ
レベルの低いレビュアーに当たったときは何を書いてもなんかしら指摘される
とりあえず「わかりました！」って言っておくのが解決策だと思うようになったわ…
>>514 分析や設計はユーザーの要件を満たすモノを作るためにやる。
それを実現するための技術的な知識は必要だけど、
次の工程はあまり深く気にする必要はない。
>>515 わかりました、というと「課題」扱いになって再レビュー扱いになるから嫌だ。
>>517 通訳と一緒だよ。
間に入る人は、両方のことを
知っていなければならない。
>>517 > 分析や設計はユーザーの要件を満たすモノを作るためにやる。
当たり前の話。それは反論になっていない。
なぜなら、ユーザーの要件を満たすものを
作るためにどうするか？
その答えが、下流に適切な資料を渡すということだからだ。
ユーザーの方だけ見ていてもいいものは作れない。
下流に適切な資料って何だ？
少なくとも通信フォーマットがかっちり決まってる資料
>521
馬鹿な設計になってないこと。
エンドユーザーは素人だから
めちゃくちゃな要求をしてくるのは仕方ないけど
それ以外は、めちゃくちゃな要求しちゃだめだよね。
プロなんだから。
525 ：
524：2012/03/09(金) 00:12:36.91
今言った、「めちゃくちゃな要求」ってのは実現が難しいって意味じゃなくて
ナンセンスな要求ってことね。どう考えても使いづらくなるのがわかりきってる仕様とか
書いてる内容に矛盾があるとか、そのとおりに作ったら破綻するのが目に見えてるシステムとか。
>>523 Ａボタン：ジャンプ
Ａボタン長押し：しゃがむ
プレイヤ「うん？」
>>523 Ａボタン：ジャンプ
Ａボタンまわす：回転
プログラマ「まわす？」
初版
→→（すばやく２回）：ダッシュ
←←（すばやく２回）：ブレーキ
プレイヤ「左にダッシュしたいです」
改訂版
→→（すばやく２回）：ダッシュ
←（長押し）：ブレーキ
プレイヤ「左に行きたいです」
>>522 >少なくとも通信フォーマットがかっちり決まってる資料
通信フォーマットとは、ネットワーク上を流れるメッセージの形式的仕様のことでいいのかな？
たとえばテキストであればXML SchemaとかバイナリならIDLやASN.1で書かれた仕様
で、そういった通信フォーマットは実装に着手する以前に仕様書としてかっちり決めるのが当たり前
もしそれが実践できていないとしたら、
>>714の
>自分の担当工程だけやって、下流の内容は知らないじゃだめなんだよ。
>プログラミングができないSEはクズと言うのは正しいということが分かる。
うんぬんは些細な話で、それ以前のプロジェクト全体の品質管理に致命的な問題があると思う
その、通信フォーマットというのを
通信システム知らない素人が作れるかといったら作れないだろうね。
シリアル通信の通信フォーマットはこんな感じでお願いと
言われた資料に、接続先のポート番号は8080で～とか書いてあったら
お前馬鹿かって思うよ。
>>526 あー…
あるな。
しかも仕様切った奴は「一つのボタンで合理的だろ」とか言ってる感じ。
ワープロって本当に使いやすかったよね。
倍角にしたけりゃ倍角ボタン、平仮名にしたけりゃ無変換ボタン、
単漢字もボタン。罫線ひきたきゃ罫線ボタン
>>528 もう設計書レビュー通して印鑑まで押したから変更はできないよ。
>>532 納品直前にユーザーの怒りを買って、デスマが始まるんだね。
>>532 レビュー通っちゃうとねー。
明らかにヤバそうなのは「試食してもらいませんか？モックアップと評価版で」とか言うと共に、
いけいけな人捕まえて「ちょっとここ突っ込んでもらうように伝えて下さい」と、両方の顔を潰さぬように大打撃を回避してる。
なんで下っ端がこんな事してるのかわからん。
>>519 うちいま両方とも知らない奴が間にはいってるもんだから、手の内ようが無い状況だｗ
納品直前なのにまだドキュメントやらテスト仕様書やらつくってたりするｗｗ
笑えねぇけど笑うしかねぇｗｗｗ
>>534 あー、あるわー
調整する立場の人間が調整する能力なくて、間接的に誘導して調整にもってったりとか…
何の仕事だかわからなくなる
事後と増やす仕事は、内向きにやらないで欲しいな。
空気を読まずに質問ｗ
おまいら、
スタイルシート編集ツール
は何使ってます？
ふつーのてきすとえでぃた
CSS用にエディタって使ったことないな
っていうか仕様書とはちがくねｗ
541 ：
538：2012/03/14(水) 10:38:15.91
あれ、CSSってＧＵＩでグイグイ書けないんですか？
それをキャプチャーして貼り付けたら仕様書、みたいなことを考えていたのですが。
CSS編集ツールの話題はスレ違いだよ
Web製作板の「CSS初心者スレッド＝11th＝」スレヘ逝け
543 ：
538：2012/03/14(水) 16:32:20.70
Web製作板ね。WebProgを見て”無いな～”と思ってました。 つ ㌧
545 ：
仕様書無しさん：2012/03/17(土) 16:37:19.87
UMLで設計を書いている。
asterのフリー版を使っているのだけど、使いにくくて気が狂いそうだ。
>>545 マウスアイコン近づけるだけで線引きモードになる奴か？
あれ、親切のつもりだってんだから、参るよ。
547 ：
仕様書無しさん：2012/04/18(水) 20:33:01.78
ｘｘ設計とか、設計書フォーマットが標準化されてくれりゃいいのになぁ
548 ：
仕様書無しさん：2012/04/18(水) 20:34:14.04
ｘｘ設計とか、
↓
xx設計とかの呼称や、
各々が考えてるレベルが食い違いすぎてて、すれ違い多かったり認識あわせが面倒だったりで
全くいいことないわ…
詳細設計と基本設計のメジャー2つの範囲ですら人によって違うって変な話だよな
っていうか、詳細とか基本みたいな概念で分けようとしてるのがそもそもおかしいんじゃないか
550 ：
仕様書無しさん：2012/04/29(日) 16:10:07.02
仕様が決まってないうちに作り始めたものなんて大抵ろくなもんじゃないよな
つまり、仕様書の仕様が決まってないから、ろくでもないものしか作れないのは至極当然のこと！
自分で仕様書書くよね、普通
552 ：
仕様書無しさん：2012/05/04(金) 11:08:21.59
仕様書というか通信仕様や状態遷移は書くけどね。
会議で了承とかはとらない。
承認をとろうとDRをやっても、あげあし取りばかりで
開発期間が短くなるだけ。まぁ潰れるだろうな。
553 ：
仕様書無しさん：2012/05/04(金) 11:37:25.60
554 ：
仕様書無しさん：2012/05/04(金) 12:09:30.10
>>550 最近は仕様が固まる前から作り始めないと
間に合わない鬼畜納期の案件が多いよ。
555 ：
仕様書無しさん：2012/05/04(金) 12:18:52.12
仕様書設計書程、意味わからんものないな
行く場所行く場所で作法が違うw
まともなところは普通に作れるが、
今いるところだと要件定義が２行くらいしか書いてなかったり
しかも書いた奴が２年前に退社してるとか・・・・
そこから基本設計、詳細設計まで落とすのは苦しいわけで
つか何年前に始まったプロジェクトなんだよとツッコミ入れたくなった
仕様書で、同じ事柄を指す表記がまちまちなのはやめてくれんかね？ と思うことがある。
昔の大規模システム開発だと用語定義から始めたりしたんだが
まあ設計２年とか普通にあったからなぁ
お作法レベルのものじゃなくてもっとグローバルスタンダードなものがほしいよな
この業界の無駄な仕事がかなり減って、残業も減ると思うわ
それで損する奴なんて、いるとしても能無しと中抜きしてる奴くらいだし
>>556 とりあえずプロジェクト開始時につけた名前と、マーケティング的な都合でつけられた名前と、
ソースコード上の名前がバラバラってのはよくあるw
マーケティングの話とか現場まで伝わってこないから、上の人たちが話してるのを
「俺には関係ないや」とおもって聞き流してると、実は自分が担当してる機能の仕様変更
の話だったりしてあとで慌てる。
>>557 基本設計書レベルでも今の詳細設計より詳しかったりするからね。
機能設計:UI設計(ユーザー及び外部装置からの入出力を伴う機能及び画面設計)と、
詳細設計:データ構造、モジュール間IF設計
だと思ってた。
本当に場所によってバラバラなんだね…
ばらばらだって事に気づいてない奴がリーダーとかやってるとマジ糞
俺の知識が正しいを信じてるからな
UIから作るのはまずい手だと私の設計の教科書は言ってる。
プロトタイピングという言葉がなかった時代の教科書か
プロトタイピングって、ハリボテを拡張していくことじゃないと思うんだ。
UIに噛みついてる奴、まともな意見がないな
では、まともな意見どうぞ
友愛に噛みつくのですか？
プロトタイプは所詮ハリボテなんだから途中で捨てないといけないんだけど
現実はハリボテという砂上を拡張して製品作っちゃうんだよな
楼閣の方はどうするの？
>>570 プロトタイプなのに細部に凝り始めるとヤバイ
トリガーとフィードバックのデモ程度で良いのに
仕様書に書かなくてもいいことまで書かないといけないルールがあったりするのがクソ
まともな内容ならむしろ作るほうに賛成なんだけどな
リファクタリングで変わるような内容まで設計書として作成するとかアホ
コードからじゃ判断できないもう少し外から見るための情報をメインに書かないと意味ないだろ･･･
>>573 誰に見せるのか、何の目的で作るのか
ここがキッチリしてないと飛んでも無いものが出来上がるよな…
お前等見ても結局理解しないだろ
んならそれはソースの中の情報で留めておいても問題ないじゃねーか
ってレベルの内容ですら書けっていうこともあったりするからな
仕様書設計書のグローバルスタンダードが欲しい
テレビ番組の制作では、視聴者の知能を小学校低学年程度と想定して作るそうだけど
詳細設計書も作ってると、なんかそんな感じの気分になってくる
これなしでもだいたいのプログラマはコード書けると思うんだけどなあ・・・
詳細設計書＝日本語で実装だからなぁ～
あとは日本語からプログラミング言語（あるいはバイナリ）に変換できれば
ソフトウェアが出来上がるようになるのが理想なんでしょう
>>576 馬鹿にわからないことは書かなかったりウソ書いたりするから
そういう状況で詳細設計の有無とコード書けるかは関係しないと思う
むしろ有ると詳細設計に縛られるせいで実装の難易度が上がることが多い
>>577 詳細設計からコード精製できるぐらい細かい事書いたら
詳細設計を要求する人には読めない複雑な代物になる
特に障害時の処理を漏れなく書くと怒られる
オフショアとかだとうまく書くんだろうけど俺には想像つかない世界
> 詳細設計を要求する人には読めない複雑な代物になる
詳細設計を要求する人っていうのは
プログラマだよ。
プログラマがコードで書いているものを
読めないわけがないじゃないｗ
オフショアはだいたいゴミだよ
あの手この手つくしてごまかして成り立ってる
コーダーはできる連中多いけど、橋渡ししてるところがクソ
>>579 プログラマにプログラムレベルの仕様書見せるなら、自分でプログラム書いた方が早いから意味ないだろ。
かと言って、プログラム組めない奴にプログラムレベルの仕様書見せても理解出来ない。
大いなる無駄なんだよプログラムレベルの仕様書っていうのは。
>>581 なんで仕様書の話になってるんだよｗ
馬鹿じゃないのか？
徹夜で詳細設計書書いて出したけど、どうでもいいところばっかり増やして
肝心なところは仕様わかんねえから抽象的なことに終始した
自分で言うのもなんだが、あれじゃプログラム組めないな
そりゃそうよｗ
コードの内容を省略して書こうとしても絶対に無理。
コード＝設計なんだから省けないものを省けるわけがない。
あれをみて、プログラムを書くのではなく
あんな方針で、プログラムを書く。
方針が書いてあれば良い。
むしろコードに関わる内容が書いてある仕様はクソ
出来ないコーダーにはそういうの渡さないとクソコード上げてくるから難しいとは思うけど
機能のIFなりI/Oなりが変わらないようなコードの修正が、
仕様書の修正を引き起こすような内容で設計書に記載されてたら、基本的にそれらは全部ゴミ仕様書だわ
設計図じゃないんだからそんなに事細かに書く必要なんかない
2重管理するハメになって、管理できずに放置されてゴミに変わるのが目に見えてる
コードを書くまえに仕様書があるのは
当然のことだが、その当然を妨害するものが多すぎる
仕様書の何が嫌だって、
気分屋の上司どものお伺いをたてて
承認をとらなきゃいけないこと。
有意義な指摘なら受け入れるんだが
どうでもいいようなことを指示して、それがしかも曖昧だったりすると
真面目につきあってたら、納期までに仕様書すらあがらない。
仕様書と設計書をごっちゃにしてないか？
仕様書が無いのに作るとかあり得無いだろ
設計って、プログラムレベルの設計の話してんだよな？
詳細仕様書的な物の話だろ？
なんか、何人か噛み合ってなくね？
設計はお客さんに見せたってしょうがない。
プログラマにとって必要な物が設計だ。
プログラマがゴミと言ったらそれはゴミでしか無い。
>>587が言ってるのは設計書そのものではなくレビューに関する愚痴なので、要否ではなく日記だな
仕様書って、作るのしんどいわりにスキル的に得るものがないな
>>592 他のところでも同じフォーマットでやれるなら、それなりに得るものはあるかと。
それ以上に、得たものをどう活かすかの方が大切なことですよ。
> 他のところでも同じフォーマットでやれるなら、
それはない。やるのなら、自分がPMとして仕様書のフォーマットまで決める権限持たないと無理。
フォーマットがあればいいけど、それすらない俺の職場は
仕様書はそもそも使う側、若しくは作る側との決め事を明確にするためにあるんだから労力関係無く無きゃ駄目
それに受け入れテストや品質管理上、作る側は実装の責任範囲の保証にもなる
無いとグダグダで無限ループのデスマ地獄になっちゃうよ(ノД`)
>>596 仕様書があればそうならない環境であれば多分無くてもそうはならないよ
>>597 そういうことじゃないよ。
仕様書がなければそうなる場合でも、仕様書があればそうならない場合もあるということ。
言い換えると、
仕様書があったためにそうならかった場合、仕様書がなければそうなる場合もあるということ。
>>598 > 仕様書がなければそうなる場合でも、仕様書があればそうならない場合もあるということ。
これマジか
どちらかというと仕様書を曲解されるせいでグダグダで無限ループのデスマ地獄のイメージだが
>>599 ハッキリと言っておこう、仕様書を曲解されるとかあり得無い、嫌、あってはなら無い事だからな
コミュニケーション力が低いじゃ済まされ無いですよ
仕様書も設計書も、「伝える」事の為にあるという事をきちんと考えていきましょうか
書く方はわかりやすく誤解をうまないように書くべきだし、読む方は読めるだけの予備知識と読解力が必要。
どっちがかけてもうまくいかないので、両方揃ってるのが理想。
でも、実際にドキュメントだけで作業を渡すと非効率。
ドキュメントとは別に、分担部分の概要を伝えて、一部を作って見せるのが望ましい。
ドキュメント読めって突き放す奴は無能。
>>600 書く側に多くを求めるのは難しいんじゃないかな
待遇的に考えて
>>601 読む側に悪意がないこととそもそも読む気がある、も必要
>>589 それな
実際仕事の現場でもよく見るけど、XX仕様書のレベルが
職場というかもはや人単位ですら微妙に異なってるから、ちょっとしたことのすれ違い多くてめんどくさいわ
いいかげん共通規格が必要だと思うわｗ
>>603 2chはいつもここに気づくまで会話がかみ合わなくて、気づいたところで終わるんだよなw
そしてまた同じ会話をはじめるw
クラス図はいいけど
他はあんまり役に立たない気がする
要件すら定義されてない機種のコードをどうやって書けばいいんだよ？
俺は最底辺なのに、なんで製品の動作の責任までとらされるのか
ステートチャートは捗るぞ
>>606 コード書けまではないけど要件定義前にステップ数出せってのはある
あるな…
で、2,000行1人月な、的な話もちょっと前まではたまにあった。
だから逆算して行数を出すことにしてた。
そもそも行数なんて今日日なんの意味もないことが明白だのに、いまだ使い続けてるあたりがアレだよなぁ
俺が三角関数や微分方程式を駆使して数値を出す計算式を1ステップで書いたら、
何も仕事してねえとか言われたよ。
先輩は単純な放物線を求めるだけで50ステップ以上。
単純な数式をあんなスパゲティでピラミッド構造に作っていたら、修正とかとんでもないことになると思うんだが。
>>608 なんでそんなの出るんだよ
バッカじゃーんって出せって言った奴に言ってみればよくね？
614 ：
仕様書無しさん：2012/05/27(日) 00:28:17.84
洋服に付いている洗濯方法の絵表示が全面変更される。経済産業省は、
日本国内だけで使われている日本工業規格（ＪＩＳ）表示を２０１４年にも改正し、
国際標準化機構（ＩＳＯ）が定めた国際規格にそろえる方針。
ＩＳＯ規格は欧州などで普及している記号がベース。大きな変更点は、洗いの表示から
「洗濯機」がなくなり、「たらい」に統一されること。手洗いは、たらいに手を浸した
絵で表す。
乾燥方法の表示は「服」や「手絞り」の絵が廃止され、「四角」に一本化。乾燥機使用
の表示は「四角の中に丸」。自然乾燥は「四角の中に棒」となる。
http://alp.jpn.org/up/s/9905.jpg >>612 分解がめんどくさいコードは一長一短だけどなー
コスト差ないなら、馬鹿がコードに触る可能性がある場合はあえて崩して書くこともある
まぁその先輩()とやらがやってたのはクソコードなのはなんとなくわかるｗ
ステップ数が多い、ってのは、仕事してるんじゃなく大半はただ無駄が多いだけだからな
公開メソッドの多いクラスなんかのコードだと、行数の1/3はコメントだったりするわ…
ステップ数で仕事量測るくらいなら、ツール使ったユニットテストのケース数とか数えたほうがまだ幾分かマシ
617 ：
仕様書無しさん：2012/06/18(月) 01:38:39.32
無駄な仕様書を減らして、有用な情報だけを残すにはどうすればいいのか…
「既存」の呪いを解呪できるアイテムの実装が必要？(´・ω・｀)
デスマプロジェクトで、詳細設計書が顧客にボロクソに言われて全面修正してるのに
他所で作ってるそこのプログラムは完成して、客にも渡したみたいなんだけど、どういうことなの
コードに合わせて詳細設計書を修正しろってことだろ。
621 ：
仕様書無しさん：2012/06/18(月) 23:42:10.71
世の中にはびこる負の遺産や呪いの術者を殲滅することが次の世代のマに託されてる…？
623 ：
仕様書無しさん：2012/06/19(火) 22:32:12.33
物の品質よりそういうところが重要ってあたりが、土方くさくてやんなるな
とりあえず納品物に仕様書を要求するんじゃなくて読み安いコードを要求するようにしろや
品質に直結してウハウハだぞ
要求が曖昧なら
どういう資料作っても無駄になるだけでしょ
プログラム読めない系の人が完成後に
資料、資料
って騒ぐみたいだよ
>>627 そういう人が欲しいのは、仕様書設計書じゃなくて、多分操作マニュアルが
欲しいんだろうね。
大工さんに、家の作り方を一から書いてください的な、資料？
いいえ、他の大工さんが仕事を引き継げるような資料です。
それ、設計士が図面書いた時点で終わってるでしょ
図面通りじゃないところぐらいじゃ、必要なのは
引き継ぎどころか、一緒にやってるメンバーでさえ見ない(見てもわけわからん)
資料を大金かけて作ってるわけだが。。
SEという人種が要求を噛み砕けんから、おかしくなるんじゃねえの？
客の太鼓道程度じゃ、そのうち...
>>631 一般的に設計士は、どういうものを作れという資料しか作らないので、
どうやって作ったかの資料が必要。
>どうやって作ったかの資料が必要。
はあああああああああああああああああああああああああああああああ
ソースが読めません系？
>>635 なんで資料残しとけば節約できた無駄な工数かけてまでソースを解読しないといけないんだよ。
趣味でやってるんならソース読めで済ませられるけど、職業人でそんな態度なら初心者だね。
ソースが読めないから工数がかかるって言ってるような
ソースしかないけどよろしくっていうプロジェクトの場合、
普通システム解析の工数を計上するだろ。
工数計上しなくて済むのは、数千行程度の極小さなプログラムのときくらい。
読めないのに、ソースの間違い探しができるのかい？
うん、ソース読めるからソース読む工数を計上してるんだね。
書けるのに読めません系が作る完成後の資料ってどういう内容なんだろうね？
読めません系が集団の職場って？
>>641 世の中には驚くほど文章を読めない人が多い。2chの3行以上のレスは
読まないってのがネタじゃなくてマジな奴が普通にいるし、Twitterの
140文字ですら読めてるか怪しい人が数多くいる。
仕様書に明記してあれば数分で済むロジックの目的を、
ソースコード上から解析して文章としての仕様にデコードするのは、面倒なケースも多いぞ
ソースと実装が異なる可能性があるから最終的にはコードを見る必要はあるとしても
それがバグなのか仕様どおりの実装なのかは、コードでしか表現されてないと判断つかない
UTがちゃんと作成されているなら別だが、
日本の土方系プロジェクトでちゃんとしたテストコードを作れてるものなんてかなりレアだし
それが出来てるところはちゃんとした仕様書、設計書に値するドキュメントもある
>>643 仕様的に欲しいのは入力に対する結果であって経緯ではないから。
645 ：
仕様書無しさん：2012/06/23(土) 16:31:17.44
そもそも、有用なドキュメント残せないようなプロジェクトのコード自体信用できるわけねーしな。
何をやりたかったかっていう目的はにコードだけじゃ判別つかん。
コードが絶対だ、既存だからバグじゃないっていう、糞コーダーの言い訳と同じ。
なぜ、仕様書作成に時間を割きながらして、ソースコードはスパゲッティなのかが腑に落ちない。
設計からしてめちゃくちゃな可能性があるけど。
単純な話で、何の意識合わせもなく多人数で手分けしてつくるからだよ。
648 ：
仕様書無しさん：2012/06/23(土) 18:03:33.39
スパゲッティになるのは単純に知識不足だと思うな。興味が持てないから知識が増えないんだろうけど
好きこそ物の上手なれってやつ
よくある系のアルゴリズムについての知識だったり、言語仕様的な通例や制約をしっているかどうかだったり、
デザインパターンみたいなのを知ってるかどうかだったり、こういう差がスパゲッティを作らないうえで重要だと思う
経験から、どう書いてあると後から見るのが大変か、どうなってると後から修正とかしやすいか
なんかを学んでいくだけでもマシにはなるけど、職場が同じようなレベルのとこばっかだと
視野が狭いままで、そんなに学べることは多くない場合が多い
仕様書設計書の話題ではないけどなｗ
スパゲッティになるのは仕様書作成に時間を掛けすぎて、
ソースコードを書く時間が足りないからだよ。
本来なら十分な時間を掛けて、
ソース設計→ソースコードを書く→リファクタリングをやらないといけないのに、
スキルに対して納期が短すぎて「ソースコードを書く」部分だけをするから
スパゲッティになるのは必然。
ソース設計ってより
何作るかわかってないから、ワケワカになるじゃね
問題に対する読解力が足りないと数学解けないのと同じ感じ？
仕様書作りとコーディングが同時に動いてる現場って少なくないけど
そういうのに放り込まれると、本当このEXCEL方眼紙に書きなぐってるものは何なんだろうなって思う
クソ仕様書から正確な仕様書を書く作業から始まる
昔からバグのまったく無いプログラムは作れないといわれているが、
実際には、バグのまったく無いプログラムは見たことあるが、
バグのまったく無い仕様書は見たこと無いw
>>652 地味にそういう事からやるほうがいいんじゃね
余裕があるならコーディングしながら矛盾点を洗い出していくとか
>>652 だいたいそれやってるけど、必ず既存のバグ見つかってアレ
>>655 たしかにそうだけど、それは仕様書再作成作業による机上バグ摘出という成果であると
前向きに考えているよ
>>656 コンパイラができること（エラーチェック）を脳内でヤルわけですね？
コンパイルできることと、バグが無いことは違うよ？
テストがあることと
バグがないことも違うよ。
>>657 何を言いたいのか意味不明なんだが、もしかすると
>>657はコードと
一対一に対応するような設計書(仕様書???)を書いているのか？
それとも
>>657のコンパイラとは、
Z/VDM/CSPのような形式的仕様記述言語の検証系を指しているのかな？
まさかコンパイラが(構文エラー以外の)論理的なバグまで検出できると本気で思っているの？
訳が分からんわwww
>>660 ”コンパイラができること” ってちゃんと書いてますよね？
コンパイラができないことが、コンパイラできるなんて
どうしてそんな変なことを言い出してるの？
>>661 >”コンパイラができること” ってちゃんと書いてますよね？
>>657では、「ちゃんと」書いているつもりなのか？
自分は、”コンパイラができることを” とは構文エラー検査であり、
"脳内でヤル" とは(
>>656の)仕様書再作成作業のことだと解釈し、
「構文エラー検査を仕様書作成作業内でヤル」という
>>657の発想が意味不明だと
>>660で書いた
もしもこの解釈が間違っていたのなら教えて下さいませ
あと、仕様書再作成作業の前に全コードをコンパイル通過させておくのは、常識だと考えているよ
コンパル時にエラー出ても読まない、わからない人が仕様書書くことがあるからね
×コンパル時
○コンパイル時
こんぱそ時
リアル会社でそういう人がいたんですよ
コンパイルのエラーって何？
って、感じの人が
またまたご冗談を
PC触ったことない、持ってないようなのも
口がうまければ普通に入ってくる業界だからな
20世紀末ごろのエラーメッセージが英語の頃はなにそれが普通だった
エラーメッセージが日本語化されてもなにそれは状態な人がいっぱいいそうだけど
エラー出た、で思考停止する馬鹿は結構いるぞ
まじ辞めればいいと思うわ…
工数稼ぐためにそういう人達が完成図書みたいなの作ってるんかね
>>671 赤バッテンのアイコンでエラー表示するとパニクって思考停止するヤツが
後を絶たないので黄色の警告アイコンにしてやったwwww
シイタケ？
｢我々は高い技術力を持っている｣｢業務ソフトを開発した経験がないとわからないだろ｣が口癖のガイキチは、
グローバル変数とローカル変数の違いもわからず、
それこそプログラマ1年目でも小学生でも簡単に作れるようなサンプルプログラムを作らせてみたら
思った通り一目で動作しないとわかるものを出して来やがった。
資料だって言ってる割には、時代についていってないような書き方だけが伝承されてるだけだったりして
＞仕様書再作成作業の前に全コードをコンパイル通過させておくのは、常識
何言ってんだこいつ。
メンテナンス出来ない/しにくい仕様書はいらんな～
679 ：
仕様書無しさん：2012/08/23(木) 17:15:51.25
うちの画面仕様書びっくりするほど横長だった。UXGA×2枚、SXGA×1枚でおさまりきらない。
書くのも大変だけど見るというか読むのも大変そうだ。
まるでWindows8のスタート画面みたいだな。
681 ：
仕様書無しさん：2012/08/24(金) 00:27:36.99
今日気がついた。仕様書を書いてるときってかなりコピペしてる。
似たような記述が仕様書にいっぱいちりばめられてる。
仕様変更時にこれを全部メンテする自信はまったくない。
ソースコードの解読が容易な案件は仕様書なくていい。
糞みたいなソースコードの案件は、仕様書も糞。
仕様書いらね。
>>682 ソースコードの解読が容易だが
バグが含まれているコードの場合はどうなるんだ？
684 ：
仕様書無しさん：2012/08/28(火) 18:59:19.16
>>678 メンテしやすい仕様書ってどうやったらできるんだろう？
使うためのマニュアルをメンテとかならわかるんだけど
プログラムのプの字もわからんでもやれる虎の巻みたいなのが欲しいだけなのかな
仕様書は上司と実際に作った俺の頭の中にしかなく、
しかも上司が実装可能と考えていた仕様はほとんど実装不可能で、大幅に改変せざるを得なかった。
にもかかわらず上司の初期構想の仕様書しかなく、俺にはそんな時間はなかったため
引き継いだ奴らが実装をわからずメンテナンスしたためにとんでもないスパゲティに。
コメント文で仕様書の実装は不可能なのでこう実装したと全て書いたんだけどなあ。
687 ：
仕様書無しさん：2012/08/30(木) 09:18:06.05
>>685 仕様変更あったときに楽に間違いなく書き直せる仕様書であってほしいってことじゃね？
>>687 仕様書直したら、ソースが直ると、思ってるとか？
回路図方面の解説書とか見たことないなあ
見れるのは図面とやれることが書いてあるもんぐらい
690 ：
仕様書無しさん：2012/08/30(木) 16:12:05.41
ソース直してると仕様の漏れが山ほど見つかる。
フィードバックするのもめんどくさいぐらいに。
>>684 う～ん、難しいんだよね。
いま社内で仕様書の標準/統一化を進めてるんだけど、一向に進まないし…
確実に統一できそうなものは目次、表紙だけだわw
そもそも仕様書って誰のためのもの？プログラマ？ユーザー？上司？
ここをまず明確にすべきだと思うな～
それによって、どう書いていった方がメンテナンスしやすいかが定まってくると思う
けど、これも難しいんだよね～。あぁ死にたい。
ソースの中身を検証できるようにするほうがよくねえか？
客、上司に媚びうる資料でもうけようってのならわかるけど
>>691 > そもそも仕様書って誰のためのもの？プログラマ？ユーザー？上司？
一つで済まそうとせずに、それぞれ書き分けたほうがいい。
694 ：
仕様書無しさん：2012/08/30(木) 20:49:05.16
書き分けるとそれぞれの内容が整合しなくてどこかでモメることになりそうな悪寒
分けるにしても
どう分けるか考えんと
>>691 ＞そもそも仕様書って誰のためのもの？プログラマ？ユーザー？上司？
引き継ぎをする人のためのものだよ。 客側、開発側関係なく開発時に
いなかった人間に対して、5W1Hじゃないけどソースを読んだだけじゃ
分からない、ソースを読まなくても最低限のことが分かることが書いて
あればいい。 逆に言うと、ずっと生き字引並にシステムに精通したのが
面倒見てくれるなら仕様書なんていらない。
受験の虎の巻みたいなのが欲しいだけでしょ
ソースの改定記録残したほうが下手な完成図書作るよりマシだろうに
>>697 受験の問題には正解があるけど
仕様書には正解はないからな。
他人の考えや決めたルールを知るには仕様書が必要。
>>698 残すも何も、普通はVSSやCVS、Gitなんかのソースコード管理を使うはずで、
よっぽどアホなことしない限りは履歴は残る。
まあ、そのアホなことをする企業は少なからずあるし、小さい企業より
日常的に使わない大企業のSヨさんとかがやらかしてくれるけどね。
なんでSCM使ってるのに紙で別出しで台帳管理をしようとするかな、、、
ソースコード管理すると言ってる人が
実はソース読めませんというオチが
> なんでSCM使ってるのに紙で別出しで台帳管理をしようとするかな、、、
台帳管理を仕事としてる人の仕事を奪っちゃいけません。
紙で承認受けないと管理したことにならない社内標準があるんだよ。
勘弁してくれ。
電子データになってるのを知らない老害がいるの？
もうボケが始まってて、現代でもパンチカードでプログラム書いてると思ってるんだよ
電子データは見方が判らんし、変更しても判らない。
紙で自分のサインがある書類がなきゃ信用しない老害は多い。
そしてそんな老害は、紙の2ページ目以降が丸ごと差し代わっていることを知らない。
>>691 仕様書の標準化をする上で必ず議題となるのは、
•設計情報の網羅性
•誰が書いても同じ物になる記述レベルの統一性
•ドキュメント間の整合性
•ドキュメントのメンテナンス性
•作成コストおよび作成時間
•納品物件としての仕様書要求レベル
•設計するためのドキュメント
•プログラマーのためのドキュメント
•保守のためのドキュメント
•読ませる奴の技術レベル
•ドキュメント作る奴の技術レベル
•実際ドキュメントがいい加減でもプログラムはちゃんと出来たりする。
これらを考えると、結局みんなが幸せになる標準化なんて不可能って早々に気づく•••
盗撮して御用になる元IBM社長みたいな老害がいっぱいの世の中
大手ほど無能も多いからなー
なまじ職場は同じなだけに、技術職との開発業務に対する温度差が激しい
結局、出来ること出来ないことを理解してない層は調整とかそういうのは無理なんよ
ノウハウがないなら勉強しないといけないけど、そういうのしないでもなーなーでやって桁利するから、余計に成長しない
ドキュメントが詳細に必要になるのは、客と開発の間に人が無駄に入りすぎるせいだわなー
なまじ職場は同じなだけに、同じような仕事に見られるけど
実際に作ってる技術職してる人と、客とのやり取りだったりドキュメント弄繰り回したりする人とだと、
開発業務って部分に対する興味の温度差が激しい
訂正しようとしてたら書き込み押してしまったよ('`)
ちょっとスレ違い気味になるけど、日本の役所はいい加減ウォーターフォールに固執するの止めて欲しい。
役所の仕様基準の元がMILなのは良いけど、そのMILは30年以上前に改訂されとっくに廃止されてる。
かなり前からプロトタイプ推奨に変わったし、今はアジャイルやスパイラル前提だ。
ウォーターフォールの失敗を認めて非推奨にしてる。
で、アジャイル以降の場合、ドキュメントの自動化が必須なんだ。
そんな細かな修正、いちいち直してらんないから。
なのにウォーターフォールと手で作ったドキュメント求め続ける役所。
見積りの精査も出来ず、高々100行程度の改修で億払うって、ほんとバカしか居ない。
> このため現実のウォーターフォール・モデルの開発プロジェクトでは、
> 前工程の完了要件（要件定義局面であれば、要件定義書などの成果物の完成）を
> 徹底して品質を高め、後戻りの発生率を可能な限り低下させるとともに、
> 後戻りが発生する場合は変更管理によって公式に決定し、
> 後戻りや横展開を確実にフォローする。
２０年前ぐらいなら通用した考え方だね
今の情報量は半端じゃないからね
> 要件定義
って、うるさい文系院卒がいたけど
今のコンピュータのことが全然わかってなかった
今だに、非力なパソコンの流行りはじめの事例が通用するとか思ってるんかね
時代についていけてない人は...
紙の上で終わらせたいとか？
昔はのんびりと時間がかけられたからね。
例えば一年単位でプロジェクトを回しているところとかだと、
プログラマに仕事が回ってくるのは年度の後半(10月とか11月～)だったり
したもんだ。SEはそれまでに半年かけて文書の作成をやってればよかった。
ところが、今みたいに同じ作業を3～4ヶ月で終わらせないといけない状況だと、
文書化とコード作成を同時並行で動かさないといけないわ、期間が短い分
精度が落ちてるから手戻りが増えてるわ(しかも、ウォーターフォールだと
手戻りがやたら面倒くさい管理方法とってるから大変)で、破綻してるんだよね。
無理に短納期にして、自分の首絞めてるだけでしょ
人月計算が時代に合わなくなってきてる？
客と作り手の間に挟まる人数をもっと減らすしかない
大手から下請けにっていう構図があれなんだよな
リスク回避のための保険という意味はわかるんだけど
無駄を無駄だって言える人がいればなぁ
大手が下請けって思いたいだけなの、今や
下請けいじめとかTVで報道されて恥ずかしくないのかね、大手系
大手とか関係なく、自社に人が確保出来ないってのは大きいよ。
常に人を確保出来るほどの仕事がある会社は少ないから、必要な時に集める。
実際、土方と同じ理由だよね。
人海戦術が通用しなくなってきてるから、困ってんじゃないの？
短納期にこだわりすぎて
短期で仕様と設計まとめれる人いるんかい
色々無理のある業界だよね。
本当に設計を纏められる人は一握り。
なのに短期間でのウォーターフォールだから、ドキュメントすら作るのに精一杯。
そこにレベルの下がる派遣かき集めても、OJTする時間すらない。
しかも見積りは人月の数字を舐めさえすれば安くなるから営業は無理な案件でも取ってくる。
せめて、プロトタイプ手法でも使えれば、少数精鋭でプロトタイプ作った後、レベルの下がる派遣に展開する手が使えるのに。
721 ：
仕様書無しさん：2012/09/05(水) 16:42:22.18
人海戦術でのソフト開発は、映画作りに似てるね？
原作という要件書があっても
監督のアタマの中のイメージと絵コンテを頼りに
セット制作を指示し、本番突入で何とか試行錯誤で
作り上げる。
映画と違う点は、その後も山のようなバグ取りと運用サポートに忙殺される。
マとSEは時間少なすぎて、残業まみれでしまいに頭おかしくなって
客はバグまみれでちょっと動かすと落ちたり計算結果が狂うシステムにイライラして
携わった人間だけをみると、Lose-Loseな状態だよなあ。こんなITで誰か幸せになってんのか？
余裕のない状況作って、実は喜んでる人がいたりするのがなんとも
安かろう悪かろうの需要がまだあるうちは何とかなるだろうけど、未来はないよね
今の状況がわかってない人達が、自分で自分の首を絞めてるだけ？
726 ：
仕様書無しさん：2012/09/06(木) 06:06:54.00
>>722 ろくな仕事もないのに仕事をした振りできる公益法人やら天下り団体の職員が喜ぶんですよね。
そういう予算だけはあるけど仕事がないところがなんでもかんでも発注するし、
使い勝手とか機能とかがでたらめな内容で発注しまくるものだから
システム開発する側もろくなものを作らず、
結果として無能の再生産をする。
727 ：
仕様書無しさん：2012/09/06(木) 08:08:29.54
基本も詳細も設計書は顧客向けに出すものではなく、V字モデルのテスト設計資料として活用するもの
そうやれてる企業は存在しないけどｗ
顧客向けなんてマニュアルと営業パワポでいい
728 ：
仕様書無しさん：2012/09/08(土) 11:30:54.54
このスレダメすぎ。
仕様書、設計書、言ってる地点でアウトなんだよ。
いいかげん、ウォーターフォールを滅ぼさないと日本が滅びる。
顧客
↓
マニュアル
↓
結合テスト
↓
単体テスト
↓
コーディング
↓
仕様書
どうしてもウォーターフォールやりたいなら、こういう順序がいいと思うよ、本気で。
730 ：
仕様書無しさん：2012/09/08(土) 12:11:47.34
「コードもないのにどうやって結合テストするの？」
とか言ってんの、もうねアホかとバカかと。
これはソフトだけの話じゃないんだよ、ハードだって開発はそういうもんなんだよ。
車の開発をしようとしたら、まずテストコースを準備する。
開発チームごとニュルに行く。
そこから始まる。当たり前の話。
テストコースなんてどこにでもあるじゃん。
俺なんか公道でドリフトの練習しまくったよ。
字乞田けど。
ツーホー
面白いと思って言ってるんだろうから、そっとしておいてあげような
「どこにでもある」
つまり、顧客環境＝開発環境が当たり前の場合、
理論と実際の誤差が生じていてもなんとかなってるんだ。
逆に、特殊環境で動かさなければならないソフトの場合だ。
そのエミュレータを手前に準備しなければコーディングしにくい。
「当たり前にないテスト環境を整えることを先にやらなければならない」
この手順を突き詰めると、ウォーターフォールの誤謬に直面する。
そこから、テスト・ファーストという考えに辿りつく。
> そのエミュレータを手前に準備しなければコーディングしにくい。
そんな事情は考慮しない。設計どおりのコーディングをすれば、
問題なく動くコードが出きるはずだ。
736 ：
仕様書無しさん：2012/09/08(土) 15:50:09.51
>>735 それは、ベテランの人間が小規模なプロジェクトをクリアする場合には当てはまる。
それ以上にはならない。
普通レベルの人間に真似させられないだけでなく、
高品質なプログラムにならない。
結果、顧客のダメだし確率も上がり、開発期間短縮にもならない。
リスクが高いので、趣味の範囲にとどめるべき手法だといえる。
よく、アジャイルは、ウォーターフォールを細かく繰り返すことだと言うけれど、
その認識じゃー、うまくいかないに決まってる。
なぜなら、ウォーターフォールモデルの手順自体が真逆だから。
>>729が正しい順序なのである。
それで、アジャイルがうまくいかないと嘆くことになるんだが、
ウォーターフォールの根源的問題を繰り返したら、
もっとうまくいかなくなるのは当たり前。
ボトムアップ的なやり方だけじゃダメじゃね
ボトムアップとトップダウンを混ぜたようなやり方のほうが
739 ：
仕様書無しさん：2012/09/08(土) 20:07:59.54
顧客←────┐
↓ │
マニュアル←─-┤
↓ │
結合テスト←─-┤
↓ │
単体テスト←─-┤
↓ │
コーディング─→┤
↓ │
詳細設計──→┤
↓ │
基本設計──→┤
↓ │
要求定義──→┘
トップダウンとボトムアップはそうなんだけど、
実際的な流れをより明確にするとこうなる。
テスト⇔コーディングが日常。
より大枠のところで、バージョンアップだ。
>>739 試行錯誤が抜けてる。
全く同じ物のパラメータ違いを
作るなら話は別だけど、
プログラムで同じものは作らない
（自動生成すればいいから）
となると、ほとんどが新しいものであり、
試行錯誤しないと実現可能であるかもわからないものがある。
やってみて（コーディングしてみて）、この方法はダメだから
違う方法にするというのはよくある話。
そういう試行錯誤コーディングで
いちいちテストなんてやっても無駄。
741 ：
仕様書無しさん：2012/09/08(土) 20:29:03.63
>>740 テスト⇔コーディングが試行錯誤だよ？
というか、試行錯誤のコーディングでテストをやらない？
なんて、嘆かわしい。
むしろ、そこはTDDを絶対オススメしたい。
基本的にはテストケース考えながら、作り込む方だな、俺は
底辺部分はテストケースはわりと考えなくてもいいんだけど
中間部分はテストケースを考えながらやるし、単体テストもやりやすい
上位部分は流してみないとわからないから、ラフに作って
全体流すときに徹底的につぶすほうかな
要求が一般的なわりと知られてるやり方が出来るのは
先に設計書作れってうるさいみたいだね
>>742 「テストケース考えながら」って、リストをエクセルなんかで書きなぐりながらってこと？
実行しながらじゃなく？
え、分岐のないやつしかやったことないの？
745 ：
仕様書無しさん：2012/09/08(土) 21:56:30.34
テスト駆動の話なんだけど、テスト用プログラム、走らせてる？
慣れると楽だよ。ある程度使いまわせるし。
なにより、脳内シミュでは完璧だったのに、バグがはじき出される時ある。
焦るけどホッとする。
そして、性能テストも同時にやっちゃう。
劇的な速度増加手段がそこで発見できることもある。
絶対いい。
テスト用プログラムっていっても、うまく作る必要なんか全然なくてさ、
つーか、統合開発環境がすでにテストプログラムなわけだし、
誰でも無意識にやってるはずのものなんだよね。
それを意識的に、プロジェクトフォルダの中には必ずテストソース入れるフォルダも作る。
で、なれると、テストコードを先に作った方がいいことに気づく。
結合テスト←─-┤
↓ │
単体テスト←─-┤
↓ │
コーディング─→┤
結合テストから入るってのは、C言語なら最初main()作って動かす。
PHPならZAMPP入れて動かす。
ただ、それだけのもの。出力真っ白、それがバージョン0.01
それをやるべき。つーか誰でもやってる。当たり前の話。
>>739 続き
どうして要求定義が一番最後なのか？
顧客ヒアリングの段階でまとめなければいけないのではないか？
もうね、アホかとバカかと。
例えば、「wordのドキュメントをそのままwebページにしてくれ」と
顧客が言ってくるとする。
はいはいと言って、見積もって基本設計やって
そして、・・・その要求が不可能なことに「途中で」気づくのだ！
もちろん、これはごく単純な例で最初の段階で無理だと断れるパターンだが、
実際問題、コーディングをちょっとやってみないと、
どんな要求が実際消化できるかわからない！（そして正確な見積も！）
そういうときは、正直に一巡するまで待ってもらう。
もしくはその顧客はあきらめ、次のために研究しておくべきだ。
それを、顧客即要求定義みたいに書くから、それが可能であると
勘違いされてしまう。これは深刻なミステイクだ。
後から顧客に怒鳴られ減額されるのは本当に嫌なものだ！
> 当たり前の話
?
748 ：
仕様書無しさん：2012/09/08(土) 22:32:38.48
当たり前の話！
ウォーターフォール滅びろ！
みんな迷惑してる！
その手の流れにもってくと、勘違いする人が出るような
当たり前だと思ってるだけで、実際にやってる人が...
テスト書く為に早出、退行テストとベンチマークの為にサー残するならやっていいよ。つまり時間外でやれ
みたいなのだから一向に流行らん
それでもやるのが何人かいるのだけがまだ救いか
時間で働いてる人に効率化とか無いですから
>>741 > テスト⇔コーディングが試行錯誤だよ？
> というか、試行錯誤のコーディングでテストをやらない？
やらない。テストの工数ってのをちゃんと意識していれば、
とてもやろうとは思わない。
試行錯誤ってのは、何度も仕様に修正が入るということ。
つまり、テストもそれだけ修正が入るということ。
テストがあればリグレッションを防げるが
試行錯誤中はリグレッションを防げない。
なぜなら仕様が変わるからテストが失敗するのがほとんど。
だからそんな状態では人間が流行ったほうが早い。
工数稼ぎのためにまともそうに書いてるだけですから
一生懸命やってますアピールしても土方の保身には全く役に立たないからね
755 ：
仕様書無しさん：2012/09/08(土) 23:04:23.41
>>752 そこまでカオスな研究段階だったそうだろうか。
それでも、可能な限りテストプログラムの稼働、テスト環境の整備、
テストデータの自動生成など提案したいが・・・
テスト工数は多くなっても自動化すれば、トイレ行ってる間に終わるからな。
> テスト工数は多くなっても自動化すれば、トイレ行ってる間に終わるからな。
どんだけ少ないんだ？
極端な例を出せば、網羅テストなんかやると
数年単位の時間がかかって現実的ではない。
必要ないテストを省くなどして、
どうやってテスト時間を短くするか考えなきゃならないのに。
>>756 そこまでタイトな網羅テストが必要なプログラムかよ！
そんなの知らねーな、今は一般的な話しをしているのだ。
テストがテストになっているかをテストするためのテストで今忙しい
TDDのテストは品質保証が目的ではないいう流儀か
そういう類のテストを工数稼ぎと看做す場では受け入れられんだろうな
自己採点が基本でしょ、プログラム系は
受験みたいに点数つけてくれる人はいない
書いて終わりじゃないところが、紙の試験とは違う
自己採点でクビか契約更新かを決めれたらいいのにね
> クビか契約更新か
それは、人が人を判断してるってことでしょ
なぁんだ
なぁんだとはなんだ
なんだとはなんだとはなんだ
なんだとはなんだとはなんだとはなんだ
オペレーターズサイドもいっかいやってみようっと。あれ？マイクどこにしまったかなぁ・・・
雇用側とかの認識がおかしいから、人集めるにしても、とんでもになってるとか
>>764 テストしたことないでしょ？
スローテストって言葉知ってる？
テストが短時間で終わるためには、
短時間で終わるように工夫しなきゃいけないんだよ。
自動化すればすぐに終わる？
アホだな。
銀の弾丸はない。
自動化してもテストは際限なく増えていく。
増えていけば必ず時間がかかる。
自動テストに時間が掛かるって状況になっていないのなら
それはまだテストが少ない段階なんだなぁとしか思えない。
やってる内容によっては、いくら自動化しようがダメ出し食らうだけじゃね
テスト自動化したら終わりってわけじゃないような
ウォーターフォール否定的なヤツが多いが、一時的に大量に人集めて、大規模システムを納期どおりに一定の完成させるにはウォーターフォールしかないのが現実。
小規模で最適な開発方式をそのまま大規模に適用させられると思ってるおバカさんが多すぎる。
プロマネにも言えるが小規模PJを幾つも上手く回すスキルと、大規模PJを完遂させる能力は質が違う。
ちゃんとした体裁のドキュメントなんて完成に近づいてからやりゃいいけど、
ある程度決めないといけない内容を残す必要もあるから、そういう意味では先に造らないといけない部分はあるんだよなー
でも、ウォーターフォールはその残すためのものを最初から完璧に作ろうとしては
書き直して無駄な工数を裂くことがおおくて、その帳尻あわせにケツが縮まって燃える(´・ω・｀)
まともなとこは、人海戦術的なことはやらんでしょ
TDDはある程度コーディングの実力が伴わないと難しいと思うよ
試行錯誤して手探りしてるレベルの人だと、いきなり適切なテストケースを用意するのはかなり難しい
だって、はじめたばかりだったり知識が足りてない段階だと、
どういうテストを用意すればいいかわからないし、そもそも作るものがどういう実装になるかを想定できないからね
もちろん、要所を押さえれば知識が浅いうちでもそれなりにはできるようにはなるとは思うけれど
試行錯誤があまり必要ないくらいにすぐ目的のコーディングに入れるようになるまでは、いきなりテスト作成はきつい
自分も結構実装前段階でテスト準備はうまくやれないから、そういうのはなんとなくわかる
でも一通りやれる事や実装の見通しが実装に入らなくても想定できるようになってくると、
テスト作成から入るって意味もわかると思うけどなー
網羅テストのような(大して意味がないけどｗ)のがテストとして求められてるようなものなら、そういうわけには行かないけどさー
今の要求は、人がいれば出来るような簡単なもんじゃないと思うけどね
簡単なの探すほうが大変じゃね
つかまずその大規模プロジェクトって物自体が否定されてるようなもんだからなｗ
頭とケツしか考えられないから、ウォーターフォールしか選択肢がない
仕様書とか設計書とかって、この無駄にピザってしまった縦割り開発の
伝言ゲームのためにあるようなもんだし、無駄だよやっぱ
新規じゃないのは、枯れてくれば、少人数になっていくような
>>770 料理人とかでも同じだな、大規模宴会料理と小料理屋の料理じゃ全然違うと。
まあ、どの業種でも言えることだけどね。
料理系とかは下積み長い人達が割と集まる（める）から成り立つんだよ
人がいればこなせるほど、甘い世界じゃないだろ、歴史があるところは
味抜きでやってるとこは、先ないだろうね、料理系
好きこそ物の上手なれっつーか、興味をどれくらい持ってるかでのピンキリ差が激しいし、
実際の土方みたいに体動かしてりゃなんとかなるわけでもないから、数いりゃいいってもんでもないしな。
> 実際の土方
やってる人に経験値高い人達がいるから、成り立ってんじゃねえの？
>>778 > 人がいればこなせるほど、甘い世界じゃないだろ、歴史があるところは
そうでもない。
例えば皮むき。下ごしらえなんかは、時間がかかる上に
テクニックはそんなに必要ない。そういう所に人を入れれば
○人でできる量を増やすことが出来る。
うまく人を配置すれば、一流の料理人をたくさん集めなくても
同じ質で生産量を増やすことが出来る。
そして、現実問題に対応しないといけない。
現実問題というのは、団体さん100人が来た時に対応できないといけない。
できるかどうかではなく、要求が先にある。
機材を増やした所で生産量は増えない。
人を増やすことでしか対応できないこともある。
どっかが、やれば出来るって言って素人に刺身切らせてましたのと同じ発想なのがお笑い
>>781 逆読みすれば、
ど素人でも出来るようなことをやってる
っていってるような
素人 と 刺身を切るスペシャリストの
違いがわかってないの？
一流の料理は作れなくても
刺身を切るのはうまいって人もいるだろう。
料理自慢って言われてる人はいるだろうけど
自分からいう人は、あんまりいないんじゃね
>>783 だれもど素人がやるなんて言ってないしｗ
えとさ、ある作業があっとして、
それを一つスキルが低い人でも出来るようにしたら
その分、生産量は上がるよね。
お前も、この考え方のその恩恵に預かってるはずだが？
例えば音声合成をするための技術はないが、
ライブラリがあれば、スキルが低くても音声合成ができる。
>>786 その時点で開き直ってるような
ま、やらせる相手によるのかもしれんけど
一流でなければど素人って言うような人だからねぇ。
そいつにとっては、一流の野球選手じゃなければ
甲子園に行ったとしてもど素人なんっだろうねｗ
そういう例え方しかできんの？
20年前のやり方が通用せん分野も出てきてるのにね
>>766 そうか。
お自動化して数年かかるようなテストやってるんだろ？
自動化しなかったら、もっと時間がかかるだろw
テストの実行にそんなに時間がかかるのだとしても、
それでもテストは繰り返すべき、だな。
基本、マシンスペックを上げる。放置プレイも重要。
そこまでの規模なら、テストの前にコンパイルで相当時間がかかるはず。
Googleはコンパイル時間が短い言語を独自開発してる。
Cでも満足できないらしい。
これはとどのつまり、テストの周期を短くするためだ。
場合によっては新言語開発さえ必要、ということ。
料理人どうののたとえ話じゃなくて、普通にマの話で説明すべきだろう
マ板住人が料理人の仕事の詳細を例えに使えるほど理解してるわけないだろう
余計ややこしくなるだけ
>>793 > そこまでの規模なら、テストの前にコンパイルで相当時間がかかるはず。
ん？ なんでテストの時間と
コンパイル時間が関係あると思ってんの？
>>792 たとえば新しいOSが増えたら、テストがその分増えるわけ。
ウェブアプリだったら、テスト時間×ブラウザ数になるわけ。
自動化関係なく、テストは時間がかかるもの。
完璧なテストは数年かかるからやれない。
だから手抜きする。
自動化でそれが0になるわけじゃなく減らせるだけ。
自動化してもやっぱり手抜きは必要。
>>796 君が「自動化＝テスト項目の削減をしない」って勝手に定義してるだけだろ。
798 ：
仕様書無しさん：2012/09/09(日) 16:26:27.82
自動化は時間の削減であって項目の削減ではないだろ
区別して考えろよ
日本語化したら、コンピュータが勝手に動いてくれると思ってるのかしら、かしら
テスト自動化したら、問題が減っていくと思いたいのかしら、かしら
800 ：
仕様書無しさん：2012/09/09(日) 16:52:44.47
ランダムテストみたいに入力をランダムに振るテストを「自動化」とか呼んでそうだな
CI
動かすより、テストすること考えて作るほうが難易度高いこともあるのにね
テストの自動化出来ましただけ言ってると誤解する人増えそう
全自動になる前の麻雀で初心者がハマる状況に似てるな、この業界
連チャンに耐えられる人達ってどんくらいいるんだろうね
曖昧な書き方して逃げ道作ってる奴ばっかｗ
保身に拘るのは最早職業病
書いたら、終わりじゃないのにね
>>755 > テスト工数は多くなっても自動化すれば、トイレ行ってる間に終わるからな。
終わらねーよｗ
テストを自動化したって、時間がかかるものはかかる。
make testをしたらわかるだろ？
1.日本は新卒文化
2.経験不要、コミュ力重視で採用。
3.プログラムは下っ端の仕事
上記理由から、プログラマの大部分は
ド素人であることが昔からこの業界の常識。
ド素人集団でもシステムを作り上げられる唯一の開発手法がウォーターフォール。
自動化はJenkinsみたいなCIサーバー使ってコミットされたらビルド→自動テストを
裏で動かせるのが肝だろ。CIサーバー使わなくてもビルドスクリプト使って
ある程度の自動化が出来てないと恩恵は少ないわな。
え、大規模でも統合環境じゃないの？
>>811 うん、コミットする前に自動テストやったら
コミットするまで時間かかるから
自動テストは、コミットが終わった後でやるんだよねｗ
>>813 普通に自分の環境でビルド通して、自分が書いた分の自動テストが通ったら
コミットするだろ。
ただプログラム書いたやつなら分かるが、自分の環境だと問題なくても
他人が修正してコミットしたモジュールと合わせるとビルド環境やデプロイ
環境でビルドが通らなかったりテストが通らなかったりするから、要所要所
でビルドと自動テストをして早い段階でエラーを検知する仕組みにする。
今はCIサーバーとかがあって、そういうのが自動で組み込める便利なツールが
あるからそれを使えるならそういうのを使えばいいだけ。
設計書だけしか書けない人はこういうツール類が昔に比べ遥かに便利で
高速化されてることを知らないのが多いね。 まあ、普通に開発してる
人間でもアンテナ張ってても引っかからないことが多いけどね。
設計書だけしか書けない奴ってホントつかえねーよな
使えなすぎてガンガン首切られてる
スキル0のゴミだから転職もできない
本日見つけた迷言
「フレームワークを使わないのがXXX(言語名)だ。」
「俺のOOPはフレームワークには負けない。」
817 ：
仕様書無しさん：2012/09/11(火) 09:48:33.01
すべてのプロジェクトに当てはまる万能な開発手法はない。
しかし、脱ウォーターフォールは万人にオススメできる。
日常のツール作りから原発まで脱ウォーターフォールを真剣に考えるべきだ。
あなたが、ウォーターフォールでうまくいっていると思っているなら、
実際は、ウォーターフォールが実践されていないからだ。
それは言えてる
ウォーターフォールでも何でもいいけど、下流の馬鹿マが内部設計すら出来ないのは勘弁してくれ。
概要設計から製造までお前んとこで請け負ってるのに、何でもいちいち聞いてくんな!!
「こんな内部変更が必要になるなんて聞いてない。」って、外部インターフェースのプロトコル変更は真っ先に挙げてるし、その対応見積り出したのあんただろ。
しかも、「じゃあ、そのプロトコルのサンプルソースくれ。」とか、知らないで見積ったのかよ!!
100歩譲って知らなかったとしても、今まで何も調べてないのかよ!!
820 ：
仕様書無しさん：2012/09/12(水) 06:54:58.89
印刷設計書が書きにくいから計算結果もDBに書き込むようにしてほしいと言われた。
書きにくいから・・・・そこ書くのがてめぇらの仕事だろ。
>>755 お前、それただのデバッグなんだが。
デバッグのことをテストって言ってね？ｗ
中抜きは下選べるだけマシじゃん
上は選べないんだぞ
>>823 情報漏洩防止手続きとか、レートとかあって、選択肢無いんだよ!!
しかも、中のマはコロコロ変わるし、ハズレが多いんだよ!!
たまに聞くコーディングやインフラまったくできない人の書く仕様書ってどんななんだろう
もう設計以前に、客の要望をそのまま横流しにして見栄えのする紙を作るくらいしか
やれることなさそうなんだが・・・
>>824 ほんと、上も下も誰も幸せになれないお仕事だよなぁ…!!
負の連鎖を断ち切られると困る人達がいるからでしょ
>>826 せめて、お国の仕事だけでもウォーターフォールで、設計審査してから製造って方式止めて欲しい。
某所の基準は30年以上前にMIL和訳して戦前からの基準に合わせただけで、以後ほとんど変わって無いぞ。
MILはウォーターフォールの失敗を認めて数年ごとに改訂を繰り返して、今はISOに移ったのに。
理系が多い某所でこれなんだから...
日本語の説明書読んで、設計審査とかバカじゃねえの？
日本語しか読めない人がこの手分野やってるんだ
そこでドイツ軍採用のVモデルですよ。
うまくいったプロジェクトの最大公約数をとるとウォーターフォールという開発方式が経験則的に導きだされる。
その結果ウォーターフォール適用プロジェクトが多くなるが、開発方式だけで成功するわけじゃないから、失敗プロジェクト担当者にアンチが増える。それがおまいら。
>>828 お国の仕事は、プログラムが動くことよりも規則に則った手続きを踏むことの方が遥かに重視される。
まったく結果が伴わなくとも、定められたルール通りにやりさえすれば、官僚が成功のストーリーをでっち上げてくれる。
そのうち晒し者なるところが出そうな話？
> 経験則的
20年以上前に出来上がったもんのメンテかなんかしてるんか？
日本だと経営者がシステム開発に興味無い老人だから、大規模PJともなると組織の中間管理職10人以上が会議室で顔つきあわせて、あーでもないこーでもないって自分の立場優先の意見しか言わない。アジャイルなんてしてたら仕様が決まる前に予算が尽きるわw
欧米だと外部から来たCEOがまず大規模リストラして、捻出した金(自分が使って良い金)で自分の気にいるシステム導入するからうまく行くわけで。
>>835 > 欧米だと外部から来たCEOがまず大規模リストラして、捻出した金(自分が使って良い金)で自分の気にいるシステム導入するからうまく行くわけで。
その導入したシステムを作った会社の話をしてくれ。
上司は上司で部下潰しに余念が無い
顧客内部での利害関係を解決しないままでも、なんとか落としどころを探して(同意したという証拠を残す)システムを成立させるのが、SIerの仕事。
イテレーションで、理想的な状態に近づけると考えるのは幻想でしかない。
関係者全員にとって理想的なシステムなんて存在しないことの方が多いから、やればやるほど迷走する。
ネゴシエーター
えらくレイアウトぶっ壊れたサイトだな
842 ：
仕様書無しさん：2012/09/16(日) 08:26:57.84
>>831 経験があって、たまたまで一気呵成でできたから、
それをすべてのプロジェクトで真似するのは違うよ。
ウォーターフォールというのは一息でやるってこと。
吐くだけで、吸わないわけで、
これはつまり、呼吸の手順が抜けてるってこと。
上手い歌手が、一息で長いフレーズを素晴らしく歌い上げたとする。
その素晴らしさを真似して、歌全体を一息で歌うのを目指すとか、狂ってるだろ？
そこには呼吸がないんだから、当然、酸欠で死亡することになる。
そういうアホで危険なことは今すぐやめるんだ。
うちの会社ではコーディング仕様とか実装仕様の話になると
すげー嫌な空気がでるんだがうちだけ？
他はそうでもないの？
いやもうなんつーかほんとやだって感じ。
コーディング仕様や実装仕様ってのがどういうのかがよくわからない
多くのところが、(名前なんかは違うと思うけど、)
だいたいこういう3段階+コーディング、みたいな事やってんじゃね
1. 要件定義 客の望むシステムを聞き出して仕様を起こすための情報を纏める
2. 基本設計、外部設計など UIや使用方法的な、外から見える部分の仕様、環境の仕様など
3. 詳細設計、内部設計など 業務ロジック的な仕様
4. プログラム設計、というか実装
頭の中でやる、もしくはソースコード自体をプログラム設計って呼んでいいと思う
この名前のドキュメント起こすプロジェクトも稀にあるけど、中身は詳細設計とかのレベルのものだし
それとも、コーディング規約(コーディングルール)とかの話なのかな？
>>843 そんな下流作業は外注に丸投げしとけって話だろ？
上司からは、そんな暇あるなら客の機嫌とって金巻き上げてこいって顔され、文系ゆとり部下からは泥臭い仕事はお断りって感じだろ？
>>843 うちは嫌って感じではないが、あからさまに逃げられる。
要するにコードも書けないし、設計も出来ないから判断出来ないんだよね。
うちは、お国のソースを長年メンテするけど、元がムチャクチャだから基準作ってもどうしようもないし。
847 ：
仕様書無しさん：2012/09/21(金) 07:14:11.14
設計書の構成とかの標準が古くさすぎて困る。
標準ってだけだから融通きく筈なのに、頭硬い奴のせいで作業やりずれぇ。
SIerの設計書はCOBOLがメインターゲットだからな。
一時期UMLを標準ドキュメントにしようとする流れもあったが、顧客も下請ソフトハウスが読めないから完全に廃れた
849 ：
仕様書無しさん：2012/09/23(日) 16:07:16.65
UML読めるとこに仕事まわせばいいのに
UML読めない客もお断り！
UML以外の設計書を納品する必要があるなら、見積り2倍で出します！キリッ
851 ：
仕様書無しさん：2012/09/23(日) 17:37:55.58
刑法第２４６条詐欺罪（十年以下の懲役)
虚偽のマージン率または派遣料金の明示により労働契約を締結する行為は詐欺罪の「人を欺いて財物を交付」にあたると見られる。
職業安定法第４４条の労働者供給事業の禁止規定違反
偽装請負、多重派遣と同様に、事前面接、履歴書の提出を行うと「派遣労働者を特定する行為」にあたり派遣会社の実態が労働者供給業と見なされるため、職業安定法第４４条の禁止規定違反となる。
罰則の適用には被害者による刑事告訴か関係諸局・内部関係者による刑事告発が必要となる。
・職業安定法第５章第六十四条、1年以下の懲役または100万円以下の罰金
処罰は派遣先、派遣元の両者に科される。職業紹介を行う紹介予定派遣では例外として事前面接が認められている。
労働基準法第１章第６条違反（中間搾取の禁止）
再派遣は労働基準法第６条の違反となる。罰則の適用には被害者による刑事告訴か関係諸局・内部関係者による刑事告発が必要となる。
・労働基準法第１３章第１１８条、1年以下の懲役又は50万円以下の罰金
両罰規定（労働基準法第１２１条）
労働基準法第１章第６条違反については両罰規定が設けられている。労働基準法第１２１条には
この法律の違反行為をした者が、当該事業の労働者に関する事項について、事業主のために行為した代理人、使用人その他の従業者である場合においては、事業主に対しても各本条の罰金刑を科する。
とあり、事業主（中間搾取行為をした事業者の経営担当者、労働者に関する事項について事業主の為に行為をするすべての者）と事業主の代理人についても処罰が科される。被害を受けた労働者は派遣先および派遣元の会社、従業員などに対して刑事告訴を行える。
852 ：
仕様書無しさん：2012/09/23(日) 18:22:46.39
＞ UML読めるとこに仕事まわせばいいのに
UMLとプログラムは相性が悪いんだ。
UML読める奴に限ってプログラムが作れない。
もし作ってもむちゃくちゃで何やりたんだかわからない。
UMLでは大事な情報が抜け落ちてしまうから、
同じ仕事を５年も１０年もやるような大企業ならいいけど。
それ以外では使い物にならないんだ。
UMLがいいと言ってる奴に限ってぐちゃぐちゃの
ソースコードを書くのは、いまとなっては誰でも知ってることだ。
UMLで書けるような仕様なんて、大した仕様じゃないんだよ
それが何のためのシステムなのかを知っていれば、
誰でも類推できてしまう程度のことしか書けない
勤勉な無能が一番厄介なのは知ってるだろ？
そういう無能にはUMLという名の落書きを書かせて
プログラマの仕事の邪魔をさせないようにするんだ
もちろん落書きだから後で使わない
UML読めないって、フローチャート読めないレベルじゃね？
UML、フローチャート読み書きできるのと、コード読み書きできるかは別なんだよ
フローチャート読めないほど頭が弱い奴に、
まともなコードを期待するのは間違ってる。
両方求めるほうがおかしいの
高学歴パー系がそういう無茶なこと要求するからね
859 ：
仕様書無しさん：2012/09/24(月) 00:52:28.63
UMLはwordで書けないから使えない
全部できる奴以外死ねって事だろ
読めないからダメって言ってる人はさすがにアレだと思うわ
別にUMLを使いたいとは思わんけど、簡単だからかじるくらいには覚えたよ
読めないと困るときもあるし
つか、UMLの仕様すら頭に入らない人が、まともなコーディングできるわけないっしょ
862 ：
仕様書無しさん：2012/09/24(月) 06:51:03.86
UMLだから、駄目/完璧ってのは無いよな。
使える図は使う、要らない図は使わない。
まぁ、要らないけど要求されるから、無駄と判っていても作るってのは多いけど。
863 ：
仕様書無しさん：2012/09/24(月) 07:06:13.13
しかし、最近のマってデータ定義疎かにする奴増えた気がする。
どんな言語でも開発手法でも、データ定義決まらなきゃ内部設計出来ないだろ。
むしろデータ定義さえ正しく出来れば、よほど特殊な処理以外はイメージ出来るもの。
データも固めずに内部処理が判らん、って何言ってんだこいつ？
ドメインモデルはニホンザルには無理か
> どんな言語でも開発手法でも、データ定義決まらなきゃ内部設計出来ないだろ。
> むしろデータ定義さえ正しく出来れば、よほど特殊な処理以外はイメージ出来るもの。
そんなのは、ごく一部の領域だけ。
元々、帳票系ベースだから、分野によっては使える使えない（ところ）があるのに
まー閉じた世界にいると、その中で優劣考えるようになって
「あれ、俺できる奴じゃね？」って思っちゃったりすることは、誰にでもあることだしね
868 ：
仕様書無しさん：2012/09/25(火) 06:31:59.18
869 ：
仕様書無しさん：2012/09/28(金) 00:12:11.73
結局EXCEL方眼紙最強ってことだね
いいえ
最狂のうんこ
レビューの時に新たな仕様書の存在を聞かされた
あるあるwww
ワロタwww
ワロタ・・・
872 ：
仕様書無しさん：2012/09/30(日) 09:02:46.71
「設計書」と「テストスクリプト」を一体化したいと漠然と思ってるんだが、何か問題ある？
最近はレビューばっかで自分で書かないからそこまで具体的に考えてる訳じゃないんだけど、
見てると「テストスクリプト」が「設計書」からのコピペと化していて
同じことを二度やっているようにか思えない
書いてある内容は、
＜設計書＞
これをやったら → こうなる
＜テストスクリプト＞
これをやったら → こうなる ＋ 必要なエビデンス ＋ OK/NG欄
の違いでしかない
「設計書」はWordで、何となく章立てや起承転結があるかのような装いをしていて
「テストスクリプト」はExcelで、表と言うか箇条書きと言うか、項目が１意に識別しやすい
というくらいの違いしかない
うちは設計書の右にチェック欄つけて、それをテスト仕様書として提出することにしてる
仕様に書ききれてない処理については別項目のテスト作る感じで
テストコードなんて誰も作ってないまま数年経過したアレプロジェクトだから、こうするしかないってのもある
あ、うんこExcel仕様書なので、一処理が一セルにかかれてるみたいなやつね
改定と仕様変更でちゃんとあってるかはだいぶ怪しくなってるけど、
ドキュメントはそれしかないからテストはそれでやってる感じ
875 ：
仕様書無しさん：2012/09/30(日) 16:09:26.66
ありがとう
出来はともかく、方法としてはそれでいいように思うんだよな
10年前はプログラム作るだけでよかったんだが、
業界の規制が厳しくなってきたのと、会社もISO9001取ったりで文書類作るようになって、
ノウハウの蓄積のない分野を力技でやってる感じで、無駄に時間ばかりくってるんだよね
いつか初めてのところに外注で出したときに
失敗させる訳にいかんかったので考えられる全分岐を書き出してURSを作ったことがあって
（要するにベンダーには何も考えてもらうことを期待しない）、
そんときも、それがそのまま設計になると同時にテストパターンになるなと思った
ISOで設計書の標準規格作ってくれよ
プロジェクト毎に設計書フォーマットが違う、取引先の気分や社内ルール次第で納品書式が変わるのはおかしいだろ。
>>876 UML
すべての仕様を書き切れるなら神
878 ：
仕様書無しさん：2012/09/30(日) 23:19:04.83
UMLでUIはどこに書くんだっけ？
ゆ、ユースケース図
ぶっちゃけUI周りはドキュメントに起こす意味のないものも多いけどな
そんなのしこしこ用意するより動くもの、モックなんかをドキュメントの変わりに使ったほうがいい
結局何か居ても客は理解しないから、触ってからはじめて違うっていい始めるわけだし
結局何か居ても
→結局何書いても
そういや、ダンボールとか切り貼りして工作でWebUIのモックつくるようなの
前にどっかの企業の勉強会かなんかの記事でみたなｗ
>>876 変化についていけない層がへばりついてる会社が多いから、規格が定まっても難しそうな気がするけどなー
あると嬉しいけれど
変化を制御しようって考えのない会社はおおいよな。
変化を抑圧しようって会社はおおいけどｗ
>>879 どうしても、ユースケ・サンタマリアを思い出す。
サタンマリアを思い出す
UMLがいまいち普及しないのは、保守的云々以前に
単純にExcel方眼紙と対等に戦える糞だからじゃね？
UMLで設計したら時間も労力も余分に必要だからだよ。
細部の設計も表現しづらいし。
UMLはモデリング言語の名前の通り、
設計したものを、UMLで記述するという風に使うものであって、
UMLで設計するという言い方はおかしいぞ。
単純に、UMLだけで設計書が完結するわけじゃないからな。
ある程度書き方に自由度があるから、伝えやすいというのと誤解させやすいと
いうのがあるから、結局のところ短納期で毎回違う人とやり取りするには精度の
問題が今までと変わらんから。
実装側に厳密にするとコード書くのと変わらないし、設計側に厳密にすると
実装に支障をきたすし、学習しなければならないというところまできてないよな。
フローチャートレベルで授業のカリキュラムや情報処理技術者試験みたいな
公的な資格試験に組み込まれてれば違ってくるんだろうけどね。
889 ：
仕様書無しさん：2012/10/07(日) 11:16:50.29
>>887 じゃあどうやって設計すんだよ
論理的じゃない設計してそうだな～～お前
UMLで論理的な設計wwww
891 ：
仕様書無しさん：2012/10/07(日) 14:58:29.08
UMLはお客さんも理解できる（ﾄﾞﾔｧ
とか書いてあった時期あったけどそんな奴居た事無いよな
国のエロい人が色々決めてたけどあんなの揃えてたら金いくらあっても足らんし
そもそも、ちゃんとした設計とか学んだことなくてニュアンスでやってるひとは多いと思うわー
893 ：
仕様書無しさん：2012/10/07(日) 18:10:41.62
Excelで結合セルを駆使して設計する方法は完璧に学習した。
途中から別のプロジェクトに入ってまず困るのは、全体を概観できる資料がないこと。
よくあるのが、全体構成図では、「営業サーバ」、「総務サーバ」とか書いてあるのに、
設計資料ではいきなり、「○○（パッケージソフト名）サーバ#1」とかになってて、
「○○#1」と「営業サーバ」の対応は、設定やってる運用グループに聞かないとわからないとか。
UMLってIT業界において、この十年間で最も衰退した技術だよな。
フレームワークや開発手法が成熟するのが早かったから、大部分が実際の開発には不要になってしまった。
本当にドキュメントが必要な部分は、UMLで記述しきれないような複雑な仕様やシステム外の業務的な背景。
いや、普通に書籍等に書いてある図は
UMLなんだが・・・
フレームワークもなぁ。
要件やメカニズムのどの部分が、どのフレームワークのどの機能で実現されてるのかが
分かる資料がつくられてなかったりすると悲惨。
DI多用してたりして、末端のPGのコードとDIしたコードがバッティングしてたりすると、
PGには原因がわからない(開発用と顧客用で切り替えとかをやってたりすると最悪）
それでもそのあたりを設計したアーキテクトがプロジェクトに残ってれば聞けばわかるが、
基本設計行程が終わったら別のプロジェクトに移るなんてやりかたしてたら、
プロジェクト内に問題解決できる人がいない（または解析しないとわからない）
状態になる。
>>895がフレームワークべったりな開発だけしか経験してないんだなとしか。
フレームワーク作る側がUMLを書いてると思ってるのかな？ww
あんなのドカタ専用ツールだと見なして無視してるけどね
とりあえず、本当にフレームワーク・・・というか、
その種のプロジェクトの中心人物は、社交的で、
不用意に他人をけなしたりしないけどね。
社交的で人当たり良くても、内心で「こいつらアホだな～、猿か？」と思ってます
いや、おまえにとってそう見える相手はフレームワーク製作者に限らないだろ。
アホに生まれた子って可哀想。
ただでさえアホだと馬鹿にされてるのに、
死ぬ程働いても給料1000万にも届かないし。
ほんと同じ立場に立ったら自殺するわ。
>>896 だいたい書籍書いてる奴なんて実際の大規開発現場知らない奴ばかりだろ
UMLだけで書くのに都合の悪い例を排除してるというか…そもそも実務経験がなさ過ぎて想像もできないんじゃないか？
UML知らない奴ほど、全部UMLで書こうとする。
ユースケース図は粒度の決め方がアナログ過ぎ、ロバスト図はある程度以上の複雑さを表現しようとすると、2次元じゃ無理ゲー。
ユースケース図の仕様に粒度は定められてない。
どう決めるかは使う側の問題。
ロバストネス図はそもそも、不必要な複雑さを省くために考えられたもので、
本当に複雑なものをわざわざモデリングしようとするのは本末転倒。
というか、批判するなら、規格書とか、発案者の書いた本ちゃんと読めよ。
UMLがない時代でもそれなりに設計なんかしてたんだし、特に必要という訳ではないかもしれんが、
あればより良いものだけど、要る派の言ってる事も要らない派の言ってる事も極端だよ。
まて、ここ最近のレスで要る派なんていたか？
極端なのは、要る派と要らない派しかいない前提の
>>908 の言ってることじゃね？
利用価値0じゃないという意見はあったけど、
アンチからみるとちょっとでも使ってる人は要るよ派に見えてると思ってる
敵を作って戦わわないと気がすまない的な
じゃぁUMLの代わりに何つかう？っていう話になると、
結局UMLが無難ってことになる。
913 ：
仕様書無しさん：2012/10/09(火) 10:19:01.02
Excelのセルをちまちま埋めて仕様書を書いていく快感はUMLごときでは得られはせぬ。
それは仕様書だね。設計書とは違う。
UMLがどうのとかはぶっちゃけどうでもいいよ。求められれば使うだけ
だがな、ドキュメントとして文章めいたこと書くのにExcel使うのはいい加減やめにしてもらいたい
二度と修正を入れない使い捨てなら構わんが、保守を考えたらExcelドキュメントなんてうんこよりひどい
ワードで書くよ～って言ったら嫌な顔するくせに
917 ：
仕様書無しさん：2012/10/09(火) 22:27:10.85
まともに変更履歴も残さないUMLは使い物にならない
設計書で重要なのは変更履歴と変更理由
現状はソース見れば誰でもわかる
それはバージョン管理システムの仕事だろ。
UMLでも、変更ごとにコミットしてコメントちゃんと入れれば無問題。
バージョン管理システム使わずにコメントだけで変更履歴残そうとして
しっちゃかめっちゃかになったソースだと、ろくに流れも追えなくなる。
たとえバージョン管理システム使ってても
diff取れないバイナリで書いてりゃ威力半減
そのあたりは使うツールによりけりだが・・・
とりあえず、diff が取れる代替え手段ってなんかあるの？
diff とか言い出すと、 word や Excel より TeX だよな。
TeXだと冗長になるし、なんかそれ用のエンジン使うのが賢いんだろうな。本当は。
923 ：
仕様書無しさん：2012/10/10(水) 20:40:25.74
>>920 エクセルに1文1セルで書いて、隣の列に
1列1バージョンで改変有無と理由を記載
フィルタを使えば瞬時に差分が見られる
>>923 それで事足りる案件なら、自分だって Diff もバージョン管理システムも、
UML も使わないよ。
そういうのは大抵が打ち消し線だらけだったりカラフルだったりになるから
いろいろ糞だけどね
場当たり対応をコード以外でも多用してるだけだし
技術文章としての体裁を要求されたり、図表使ったら終わるだろ、それ。
927 ：
仕様書無しさん：2012/10/13(土) 13:18:12.48
上流工程の資料の作成が凄いネックになってる気がしてならない。
開発者の視点で厳密に書くと「こんなんじゃユーザがわからん」といってハネられる。
ユーザにわかるように書くと表現があいまいになって、開発者には意味不明になる。
この矛盾に悩みつつ、ダメだしを回避する資料を完成させるのに絶望的に時間がかかって、
プロジェクトの予備工数がほとんど消える。
最後にはタイムオーバでダメ出しする人間が折れることになるが、
なんだかんだで、ユーザにも開発者にも3割方意味不明な資料ができあがる。
この3割方意味不明な資料を使って予備工数がない状態で開発がスタートする・・・。
ユーザー用と開発者用それぞれ別のドキュメント作ればいいだけでは？
むしろ作るべきでは？
まず、そのための工数がとられてるプロジェクトをみたことがない。
あと、開発スタート後に鬼のように湧いてくる仕様変更を、
二重化したドキュメントに反映してメンテナンスしていくコストも大変。
dfdとer(テーブルと多重度のみでOK。カラムは主キーのみでいい)意外不要。
一人で作る程度のシステムで、クライアントがそれで納得してくれて、
その後の運用メンテも同じ担当者が続ける前提なら、それでなんとかなるかもしれん。
成果物が糞じゃない前提なら、ドキュメントの必要性は減ると思うよ
webとかだったら画面遷移とかあると理解度は上がると思うけど、
マニュアルと動くものがあれば事足りるからなくてもいい
クラス図があると関連は理解しやすいけど
名前やパッケージ、IDEの機能で追っかけるのは簡単だからなくてもいい
まぁ作成や保守にかかるコストと教育にかけるコストと、教育対象者の質次第だな
劣悪なのはドキュメントがいくらあっても結局理解しないし、
できる奴は(ちゃんとしたシステムであれば)その場にあるので難なくこなせると思う
技術的なドキュメントとして重要なのは基本設計と運用設計のほうだと思う。
基本設計資料がちゃんとしていれば、詳細設計は無くてもなんとかなる。
でも今、実際は、基本設計、運用設計、詳細設計で、ドキュメント量の比率としては、2:1:7 ぐらいじゃないか。
自分は、6:3:1 ぐらいでもいいと思う。
詳細設計書 = ソースコードだからねぇ。
本当の必要な量で言えば、一番多い。
だけど、ソースコードを補足するものだけに
すれば、逆に少なくなる。
詳細設計の量が多いところは
ソースコードが詳細設計書だって
わかってない。
むしろ、プログラムソースよりも、設定ファイルのほうに
詳細な資料が必要なんだが、JavaDoc みたいな
しくみが設定ファイルには用意されてないから、
ブラックボックス状態、
まぁ大抵はXMLだから妥当性検証は簡単だし、設定不備はコードの修正なく完了できるし
個別の機能設定はコメントくらい入れてくれよとは思うけど
特定の機能のON/OFF とか単純な設定はどうでもいいんだが、
フレームワーク周りの設定はノウハウの塊だったりするから。
そもそも、設定の不備を判定すること自体が難しい。
現象に対してどの設定ファイルのどの設定が対応しているのか、調べるのが大変。
DIするのにRails的にネーミングルールで設定してあって、
そのネーミングルールがドキュメント化されてなかったりとか。
938 ：
仕様書無しさん：2012/10/18(木) 07:05:39.43
本来は設計して実装しなければならない判断を、仕様が不明確だったからと設定ファイルに逃がしドキュメントに残してなかったりする。
その上、その設定値ありきでロジックが組まれてて変更するとバグる。
素敵な罠。
939 ：
仕様書無しさん：2012/10/29(月) 20:16:48.90
でも必要だよね
940 ：
仕様書無しさん：2012/10/29(月) 20:17:10.03
結論、いらなくね？
疑問文で終わる結論なんてねーよ
や ゆ ゆる ゆれ ゆよ
飼い主様が要るといってるなら要るんだろうよ
社内システムでも仕様書必要だよ、途中から参加するPGが何もないところからソース全部読んで全部理解しないと1行すら追加できないって悲惨すぎるだろ・・・
しかもそれをものすごい短時間でやれとかブラック以外のなにものでもないだろ
他人が読んで即理解できる素晴らしいコーディングができるならいいが、そんなやついねーだろ
だから仕様書や設計書は必要
確かに社内システムの場合基本的に設計が腐ってるからな
スパゲッティすぎてドキュメントという見えない幻想にすがりたくなる気持ちはわかる
でもコードと同レベルのドキュメントがあっても結局スパゲッティなんだけどな
外注だと、コードよりもドキュメント（を印刷した時の厚さ）を
充実させるように指示が来るぜ……
>>944 ソーシャルゲームの会社に入ったけど、そんな感じだな。
コンシュマーの普通のゲームだったら売り切りで終わりなんだろうけど、
ソーシャルの場合、サービス終了まで続けなきゃならないから結構きついな。
エンタープライズアーキテクチャ（EA）ってどうよ？
すごくいいよ。
クラス図見せてもらったけどどこかの電子基板よろしくぶわぁぁと線が引いてあっておもしろかった。
950 ：
仕様書無しさん：2013/02/14(木) 13:54:20.38
SEです。
要件定義と外部設計やれと言われました。
プログラミング経験はサンデープログラマレベルです。
仕様・設計書について手短に学ぶのにオススメの本とかサイト教えて下さい。
あと、visioで書きたいんだけど嫌われるんでしょうか?
現場以外でみるとかにはexcelが無難だとは思うけど整形するのが面倒そうで…
要件定義はWordで。
外部設計もWordで。
VisioはOffice基本セットに入ってないので嫌われる。数年後、別の人がそのドキュメントを修正する
可能性を考えること。
952 ：
仕様書無しさん：2013/02/14(木) 16:01:37.42
馬鹿いえ。ドキュメントはすべてExcelにきまってるだろ。Word使う奴は素人。
953 ：
仕様書無しさん：2013/02/14(木) 16:19:30.88
パワハラ犯罪にたいする刑事罰(※本投稿のコピペ歓迎です)
人事原則
１ 現行法では、社員が仕事を怠けたり、能力不足、就業規則違反、目標を達成できなくても解雇をしたり叱責することは違法です。どんな駄目社員、嘘つき社員、怠け者も定年まで解雇が違法なのが現行の正社員制度です。
２ パワハラは社風にあわない社員、成績の振るわない社員を自主退職に追い込む言わば人事的措置として用いられることが多い。
※違法な解雇の和解金相場は、労働審判で３ヶ月、通常裁判で１年以上の報酬、さらに社員が和解を拒めば復職が可能です。弁護士への着手金は12～15万円、和解拒否なら20～50万円程度。
人事部・ホットライン・御用組合へ直訴
メリット： 一時的緩和や人事異動
デメリット： 役員へ情報筒抜け、危険分子の烙印（情報漏洩がホットライン直訴者に多いのは人事部の常識）、パワハラ放置で自主退職に追い込まれる
民事訴訟・調停・労働審判
メリット： 損害賠償
デメリット： 裁判費用、解雇措置、民事不介入で刑事事案化を阻止、長期係争、パワハラ上司の継続雇用
刑事告訴
メリット： １パワハラ上司の解雇・懲戒、または２多額の和解金、１と２どちらでも被害者の雇用は維持
デメリット： 人事異動（出世コースから外れる）
◎録音は一方の当事者が取る限り合法です。※加害者に録音の同意を求める必要はありません。
◎告訴受理後の和解金は加害者の資産・収入に応じて変えてください。犯罪者の昨年の年収の半額程度×最大懲役年数が妥当です。
◎パワハラの被害についての告訴は１侮辱罪２脅迫罪３強要罪４威力業務妨害罪５傷害罪の順序で行ってください。警察・検察の協力（犯罪者の自宅・職場の強制捜査、留置所勾留）により罪の立証が楽になります。
◎刑事告訴した社員を解雇したり処遇面で著しい差別を行うことはないでしょうが、出世や管理職以上の昇進の可能性はあきらめるべきでしょう。
◎刑事告訴は民事訴訟と違って裁判による被害者への2次被害にありません。検察庁が被害者に代わって訴えをおこすので、無料で、時間と手間も告訴状をかくことと音声録音を残すだけです。
◎和解契約（公正証書・即決和解）では告訴した事実は秘匿事項となります。犯罪者が秘密保持契約を違反した場合の損害賠償金は、最低5000万円～にしましょう。
>>950 > 仕様・設計書について手短に学ぶのにオススメの本とかサイト教えて下さい。
今すぐAmazonでよさげなのを5冊買って、土日で読め。
>>944 > だから仕様書や設計書は必要
必要だけど、それがあった所で短時間で修正とか不可能。
なぜなら、その仕様書や設計書にバグ（ミス）がないという保証はないし、
最新のコードに追従しているとは限らないし、たいていは読みきれる量じゃない。
仕様を理解した所で、修正の影響範囲まではわからない。
現実には、仕様書や設計書を見比べながら、コードを読んでいくという作業が発生する。
そして修正した後、影響がありそうだなと想定した部分のテストが必要。何度も。時間がかかる。
それでも結局（全部ではなく）想定した部分のテストだけを行うと、想定外の影響がでてしまう。
じゃあどうするかというと、全体を自動的にテストするためのテストコードが必要になる。
テストコードがあれば、とりあえず修正で影響がない保証は得られる。
もちろんただ単にあればいいって話でもなく、テストコードに漏れや間違いがある可能性もある。
まあそれは間違いが発覚した時点で修正すればいい。何度も同じテストを実行できるのがテストコードのメリット。
他にもテストコードは短時間で実行可能になっていないといけない。
(テストの実行に一日とかかかってたら短時間での修正は無理）
またテストはメンテナンス可能になってないといけない。
仕様変更時のテストの修正箇所の特定や修正そのものに時間がかかるようでもだめ
結論を出すと、アプリコードとテストコードが組で作られており、その両方が
メンテナンスできるよう複雑性を低く保ちながら開発しつづけ
テストの実行を何度も短時間で行えるような体制になっていないといけない。
仕様書や設計書はコードの理解を助けるためにあればいいが、修正のしやすさに関して言えばあまり役に立たない。
結局重要なのは資料よりもプログラミング技術なんだよ。
>955とは仕事したくないな
理由も言えない奴に説得力はない
958 ：
950：2013/02/15(金) 16:05:27.99
>>954 >よさげなのを5冊
よさげなの教えて下さい
とりあえず近くの本屋で「システム開発のすべて」ってのを買いました
>>958 腰が重いわ。
今すぐ要件定義で検索して、1ページ目の★4つ以上を上から5冊買え。
で、土日で全部読め。
ほら、選んでやったぞ。
俺はどの本も読んでないがな。
手戻りなしの要件定義 実践マニュアル 2,940円
プロフェッショナル要件定義の教科書 2,520円
要求定義のチェックポイント427 2,520円
成功する要求仕様 失敗する要求仕様 2,310円
[改訂第2版] [入門+実践]要求を仕様化する技術・表現する技術 2,709円
合計12,999円
それを読み終えたら、ワインバーグの本全部読め
ワインバーグの本を全部読み終えたら、トム・デマルコの本を全部読め
以上で、一ヶ月終わり
それ、一年かかるよ・・・
>>963 月～金4時間ずつ、土日8時間ずつで、4*22+8*8=152時間。
1冊5時間で読めば、30冊読める。
余裕。
テストコードすら実装できないノースキル連中が腐るほどいるから
多少アレでもそれくらいの自動テストとか理解出来てる奴と仕事できるほうがいくらかマシだと思うよ割とマジで
長くいるわりに学んでない頭悪いだけのオッサンとか割とマジでどうしようもない
ワインバーグの本を全部読んだら、
現実感覚を身に着けたソフトウェアエンジニアになるか、
システム開発に絶望して冷笑的で嫌味なだけなキャラになるか・・・。
968 ：
仕様書無しさん：2013/04/24(水) 05:47:20.30
基本設計の範囲や内容が現場によって違うので
プロジェクトに参画するときの面談で話が一致しなくて困る。
中途採用も同じだな。
「できます」「やってます」だけで判断しなきゃいけないのでギャンブル過ぎる。
サッカーの場合にはFWやDFといったポジションに対して選手が複数対応するこ
ともありますし、逆にいない場合もあります。この場合には重複度は"*"にな ります。
さて、前の項でサッカーの場合には重複度のところに11と書いてはいけないと
いう話をしました。では野球では9と書いていいのでしょうか？この答えがこ
の限定子を使った図です。野球では「9人の選手がいる」と書くよりは「ポジ
ションごとに選手が一人ずついる。(そしてポジションが9個ある)」と書いた
方がより的確です。将来、ルールが改正されてポジションが増えたり減ったり
しても対応できるという柔軟性も兼ね備えています
新人SEなのですが内部設計とくにプログラムの詳細設計に存在意義を見出せません
このクラスはどのパッケージでなにを継承してどんなフィールドとメソッドがあり
このメソッドはどんな変数を定義してこれこれこういう処理をしてそれをフローチャートで書くとこうなります
ってバカじゃないのそんなの書いてる暇があればその場でコードとコメント書きなさいよと思ってしまいます
あれはいったい何のために存在しているのでしょうか？
>>971 外部設計書と10万行のコードだけが存在してて、評価やメンテナンスに誰も困らないなら
内部設計書はいらないよ。
>>971 リファレンスが無いと後で大変だからだよ。
リファレンスにコードの日本語訳まで必要なんですか？
>>974 君に現状を変える能力が無いのなら、従うしかないんじゃないの。
詳細設計書はソースコードとコメントから自動生成するものであって、手書きしなきゃならん文書はほんのごく一部
>>977 「手書きしなきゃならんごく一部文書」がいわゆる機能設計書や構造設計書のたぐいではないかと....
前半の詳細設計書うんぬんについては、完全に同意
コードの日本語訳ってどゆこと？
>a = 1; // 変数aに即値1を代入する
981 ：
仕様書無しさん：2013/06/17(月) 12:39:30.82
>>980 へぇー、面倒な事してるんだね。
もっと効率的にやればいいのにとは思うけど
もし、それでお金取ってるんなら仕方ないかもね。
>>979 >コードの日本語訳ってどゆこと？
もしも詳細設計書の現物を見たことが無いのなら、
こんなのがあるので参考になるのではないかと思う。
・島根県松江市 高額合算システム
http://www.tpj.co.jp/ruby/case001_01.html Ruby on Railsで開発された本物の基幹業務アプリだけど、
ソースだけでなく設計書一式もすべて公開されている。
このページ内の節「ダウンロード」にある設計書を解凍し、
その中にある「高額合算システム詳細設計書_別紙３）プログラム仕様書」という
PDF文書を参照してみてほしい。
>>977 >詳細設計書はソースコードとコメントから自動生成するものであって、
理想的にはそのとおりだと思うのだけれど、
上記レベルの文書をコードとコメントだけから自動生成できることが前提になる。
現場ではすでにこういった様式の詳細設計書がまかり通っている訳で、
これと同等水準かあるいは全く異なる視点で生成された画期的なナニカでなければ
現実世界を変えることは難しいと考える。
ちなみにRails(Ruby)にはRDocというJavaDoc風の文書自動生成ツールが付属している。
ただし残念ながら、出力はHTML形式だけだし、たとえそれをPDF向けにフォーマットしたとしても、
それだけでは現場から顧客(発注元やSIer)へ業務改善として提案できるレベルには達しない。
>>971 馬鹿でも出来る仕事を増やすため
そのレベルのアホなドキュメントを要求するような程度の低い環境はさっさと淘汰されるべき
早めに見切りつけるのも手だよ
でもまぁ馬鹿が腐るほど居る業界だから、そういう意味では必要だったりもするってこと
平均が高い職場に巡り会えるといいね
>>971 存在意義は金になるって事。
詳細設計そのものにお金を出す顧客がいるって事だよ。
顧客によっては、詳細設計書は不要であるとか、（どうせ読んでも分らないから）形式として有れば良いと言う場合もある。
こういう時は、Javadoc見たいな自動生成されたドキュメントを代用する事で工数を減らす場合もある。
自社開発だとコメントに書く場合もあるし、Wikiに書くとか、まぁ色々だな。
あと、役所関係は紙文化の職場だから紙の資料に特別な意味がある。
紙に書いてあることがすべてで、書いて無いと不具合って考えてる人が多い。
