【IT】正直詳細設計書いらないよね？【SE】
全部要件定義で突っ込めばよくない？
インプットアウトプット、DBとか環境設定、処理の概要くらいはみたいけどほとんど使われない設計書を大量生産するのってアホみたい。
現場でも実はソース書いてから設計書つくりましたみたいなことが多いし、客も設計書なんかみてないし、保守のSEも設計書よりも問い合わせではコード見て判断する方が多いし、バグ改修でも設計書みながらバグ改修するやつなんていないでしょ。
だれの為に作られてだれの為にメンテしてるの？日本以外のITの進んだ国でも同じことをやっているのだろうか？
5分でかけるコードのために1ヶ月かけて資料と検証をしているようなものだ。
ソースみたり検索しただけじゃ直ぐにわからない情報をパパッとわかるようにまとめたものは必要だと思うけど、過剰すぎて誰も使ってない求めてない情報まで一生懸命メンテしてない？
まとめ
今みたいな詳細設計書はいらないと思う
IT先進国のアメリカでもエクセルで大量に設計書を作っているのかだれか教えてください。 >>88
言いたいことが理解できない。
君は可読性が高くないプログラムは設計書がないと理解できないという解釈でいいんか？ >>89
可読性が低いものを作るにはかなりの理由が必要。
理由がないのに可読性の低いものを作っているのなら最悪のプログラマだ。 自分のコードを簡潔に説明できないのなら、ダメなコードだ。 >>83
そいつのプログラミングスキルが低いだけ。
詳細設計書が必要な理由にはならない。
プログラミングスキルを高めさせろ。 クソコードはコメントがないといっけん、まともに見えるw >>3
>どんなときに使うの？
その工程、やり方、発想が役立ったと思い浮かぶのは、
『(言語スキルない)コードは書けないけど処理書ける人』が経験少ない人に依頼する場面。
逆に超大規模で言語は違う立場で詳細設計書を読んで『(PG書ける現役が読むためなら)作った意味ないな？』感じた
事はあった。
中高年現場責任者レベルがなるべく中身理解できるようにする目的と読めない客へのアピール的な。。。
>>5
>ドキュメント自体は必要だろ。
昔、『仕様は頭の中にある』を案件説明時に必死に説明していた変な人を思い出した。。。
>>83
>自分にしかわからないプログラムを書く
もっとひどい、詳細仕様までおそらくPGが決定しただろうと想像できる成果物(code)を読んで
仕様を満たしてないゴミcodeを読んだ事があるから、仕様、テストができない人を担当にするなら必須かな。 >>37
>作業がもどるってことが起こる
もどるなら当時の記録として貴重だろ。。。作る余裕もない状況(プロジェクト)もあるからまだマシ。
code書いてからドキュメント作成？
>>69
ちょっとスレチになるけど
コボル時代を擁護するつもりもないし、アジャイルも否定はしない。
アジャイル普及前かアジャイル採用してない現場（ウォーターフォール）で
『設計できない＝作りながら考える』なんちゃってアジャイルのような
工程抜きウォーターフォール、きれいでないウォーターフォールを体験したから賛成しにくい。
うまくいくなら、どっちでも。 >>75
>簡単な機能は設計書なんて見なくても作れるし、難しい機能は設計書読んでも作れない
予想するに上司が『難しい機能を簡単につくれるように』と考えた可能性がある。
困ってる感は記憶から伝わるけど、書いてあるコメは
『コルタナ”こんにちは”機能なら見なくても作れるし、難しい機能は【スキル不足・経験不足】で作れない』
みたいな、だから何？しか返せないわ。
>>77
>だいたいまともに設計書が書けるならコーディングはかなりのものがただの作業となる。
同意の一瞬後、言語(ツール)習得済みという前提が思い浮かんだ。
処理書けるけど言語わからないから作れない人と一緒にやった経験を思い出したからかな。
>>78
>分かってない上席で承認レビューとかするのは不毛
その経験が多い成果物管理担当(中高年)からは、書式揃えの依頼・アドバイスだけ何回も聞いた。
上席レビューだか、ユーザーPMレビューだが、内容は書式確認レビューになってるということ。
『誤字脱字を指摘して仕事した気になってる』人と『給料高い人がやる仕事ではない』無駄がむなしい。
学校のくだらなくてつまらない形式行事を思い出しちまったぜ。 >>48
俺の勤め先は、詳細設計とプログラミングも準委任で契約するよう、社内で推奨してる。
リスク回避の為だと。 ドキュメント作りすぎだろ
明らかにいらねーのあるだろ
早く終わっとけ糞業界 あれだけメッセージのやり取りしといて
話したい事があるから電話しろって要件も言わない
どんだけ頭おかしいねんE.T >>1
ハイおまえクビ！
プログラマは詳細設計書をみてプログラムを組む
詳細設計書に書いてないことはしてはいけないし、書いてることは全て満たさなければならない
詳細設計書がないということはプログラミングが存在しないという事だ
というわけでおまえクビ E.Tのぶっこわれようは何とも形容し難い
元々ど底辺のゴミ企業に入ってしまう頭が異常労働でさらに壊れてしまった
あれで自分を正常だと思ってるんだから、マジでやばい >>110
E.Tみたいな危険なエンジニアを放置するな！ このETが誰かわからん限りどうでもいい話でしかないな >>114
ブラック企業なのに社長を尊敬しているE.T
そのためか、社長ではない、役員でもない人間に対し、残業代を請求するとか言い出す。
炎上現場で100%の仕事をしようとか言っちゃう
炎上現場でやる気なく手抜き気味の他の会社を頭おかしいとか言っちゃう。
ユーザーや元請に気に入られるのが大好き。自費の飲み会も積極参加。自分がブラック企業である素振りを一ミリも見せない。
どんなに不満があって社長を非難せず、別の上司を非難する。
明らかに環境に原因があるのに、とことん人のせいにする
ハラスメントも隠蔽し、被害者に罵詈雑言をはく
糞現場を積極保守し、メンバーを使い潰す危険なエンジニア
ちなみに、こんなんでも妻子持ち ＞そのためか、社長ではない、役員でもない人間に対し、残業代を請求するとか言い出す。
妙に具体性ある上にガイ○感が凄いな ＞１
お前全然分かってないよ。意味のないドキュメントをたくさん作って保守容易性を奈落の底まで突き落とす。そうやって俺は３０年SEやってきたんだよ。文句があるなら俺を殺してから言え。 >>115
メンバーを使い潰すって実際どんな感じ？ 半月で1か月分の仕事をやらせたり
残業140Hを越えて働かせて書類送検されたり
そういうのだろ どうせ最後は人依存するんだから設計書なんて書くだけ時間の無駄 詳細設計は、要るだろ。
要らないのはCDI。
今日2022年12月15日現在、
それが事実。
ふ ざ け ん な
詳細設計書がないと単体テストができねえだろうがボケ
お前ひとりで仕事するならアリだろうが
何人もの事情を知らない奴が集まって仕事するんだぞボケカス
少しは足りない脳みそフル回転させて考えたらどうなんだコミュ障ども ドキュメンテーションが苦手なやつは、プログラムを日本語にしたようなのを詳細設計書にするからなあ。
プログラムに詳細設計書の言葉をコメントとして残さないのも多いし、日本人は能力が低い人間をコーダーにしているからこうなる。 私は元CTCの子会社に所属、原子力規制委員会へ派遣の、大澤透（オオサワトオル）にレイプされました。
職場で毎日ねちっこく執拗なセクハラを続け、挙句には既婚者であるにも関わらず交際を申し込んできたりと異常でしたが、私の契約が切れる３ヶ月前を皮切りにレイプをしてきました。
証拠は全てあります。人権なき自称身長160センチ（推定151センチ）の小人よ、震えて眠れ。 今日は、2023年2月6日。
会社に依らない記事が下がっているから
上げておくぜ。
女子小学生最高。
詳細設計書を書くことに意味がある。詳細設計書を省くと実装者の自由になってしまって、仕様まで変ってしまう。
外国は仕様書をたくさん作ってから作らせるが、それでも全然違うものができあがって、勝手な仕様を製品仕様として認めるしかなくなる。
マイクロソフト製品が事前の話とまったく違うのはこのせい。 詳細設計なんてまともにやらずに客先常駐で雇って外部設計ベースで都度都度説明しながらPGPTやらせるのが大半だけど
外部設計の矛盾をPGで吸収するか差し戻して設計やりなおしってのが死ぬほど効率悪いよね
まあ詳細設計とまともなレビューがあってPG前に設計修正するフェーズある案件見たことないけどさ > 外部設計の矛盾をPGで吸収するか差し戻して
> 設計やりなおしってのが死ぬほど効率悪いよね
はあ？ガキかよ・・・むしろこれこそが目的なんだが？
プロジェクト期間を延ばせば延ばすほど儲かる仕組みだぞ
激安単価で連れてきたPGPT担当のゴミどもにすべての責任を背負って貰えるからほぼノーダメｗ
詳細設計書なんてまともに作られたら自分たちの設計がボロボロなのがバレるじゃねえか死ね カットオーバー最初に決めて見積もりして金貰うのに延ばしてさらに金取るとかすげーなどこの敏腕PMだよ いまどきわざの遅延させて、お金を奪う手法は、ただのダメ会社だとしか思われない。 親方日の丸の会社ならゴネ得したらしただけ金払うから安心して良い
だがあいつらワザと遅延させるためならお前を過労死させてでも遅延させるぞ
巻き込まれたら命とられかねないから早く逃げろ！ちゃんと警告したからな！ 今日は2023年4月15日じゃ。
設計は楽しい。。
多少の経験者として意見を言うと貴君の位置付けは全体に右にずれている
要件定義⇒客がシステムをどのように使ってビジネスをするかを記載⇒運用テストあるいはビジネステストで評価
外部設計（基本設計）⇒システムが外部からみてどのようにふるまうかを記載⇒システムテストで評価
内部設計（詳細設計）⇒システムが内部的にどのように動くか（APIやライブラリ）を記載⇒結合テストで評価 の位置付けかなぁ 
