【IT】正直詳細設計書いらないよね？【SE】
全部要件定義で突っ込めばよくない？
インプットアウトプット、DBとか環境設定、処理の概要くらいはみたいけどほとんど使われない設計書を大量生産するのってアホみたい。
現場でも実はソース書いてから設計書つくりましたみたいなことが多いし、客も設計書なんかみてないし、保守のSEも設計書よりも問い合わせではコード見て判断する方が多いし、バグ改修でも設計書みながらバグ改修するやつなんていないでしょ。
だれの為に作られてだれの為にメンテしてるの？日本以外のITの進んだ国でも同じことをやっているのだろうか？
5分でかけるコードのために1ヶ月かけて資料と検証をしているようなものだ。
ソースみたり検索しただけじゃ直ぐにわからない情報をパパッとわかるようにまとめたものは必要だと思うけど、過剰すぎて誰も使ってない求めてない情報まで一生懸命メンテしてない？
まとめ
今みたいな詳細設計書はいらないと思う
IT先進国のアメリカでもエクセルで大量に設計書を作っているのかだれか教えてください。 DBのなんかよくわからんパラメーターの設定一覧ならあったほうがいいと思う
でも基本いらないでしょ、どんなときに使うの？
アメリカとか設計書どうなってるんだろう、調べたら日本みたいな設計書はないって書いてあったけど ソースを見て判断しなければならないのはドキュメントの保守が行われていないせいであってドキュメント自体は必要だろ。 Javadocがあれば、詳細設計書は要らないかも。
ドキュメントは、後で使うものだけにしたほうがいいというのは同意。 上司がドキュメントしかみないしドキュメントをみて判断をするからドキュメント自体は必要なのはわかる。
でも必要最小限にしたい、20以上のフォルダの中にそれぞれ10～50のファイルがあってさらに1冊印刷するだけで数百ページになったりするものもある。
いくらなんでも過剰だとおもうし、保守なんてできないと思う（メンテしてることにしてるだけ）。
しかもどこの現場にいっても設計書のフォーマットが違ってどう読めばいいのか慣れが必要なんだよ
テーブルだけで300以上あるシステムとかだとDB設計書やSQLだけで恐ろしい量になったりするのもわかるけどさ
なにが必要な情報でなにが不要なのか日本中で統一して欲しいし、教科書てきなものも必要だと思う アメリカが世界最先端で生産性も高いならアメリカに習えばいいと思ったけど検索しても情報がでてこないんだよね テスト仕様書ってどの段階で誰が描くのが適切なんでしょうか？ 職場ではプログラム担当者(新卒一年目の私)がプログラムを書き終わってから
テスト仕様書を自分で書いて自分でテストしてるのですが
なんだか違和感というかこれ違うんじゃないかっていう感覚があって自信が持てません… どこの現場いってもそんなもんだよ
マトリクス式で全ての結果にDBと画像の証拠をExcelに貼り付けさせるような時間のかかるテストを要求するところもあるし殆ど時間くれないとこもある(;´д｀)
工程
要件定義 - 基本設計（外部設計）-詳細設計（内部設計）-実装
↓ ↓ ↓ ↓
システムテスト 結合テスト 単体テスト プログラムテスト
的なものを勝手にイメージしてるんだけどPS（プログラムテスト）なんてどこも存在しないから
プログラムテストと単体テストを一緒にやるかんじなるのかな？
単体テストは修正したロジックの分岐を全て試すべき！
とかいわれる
詳細設計で決めたこと全部満たしてるかと修正したロジックの分岐を全部通してみる（そのときにデッドロジックに気づいたりもする）
あとは境界値と異常値の確認くらいかな？
結合テストでは修正とは関係なくてもデータパターンを一通り試したり、あとは要件定義とか外部設計で決められたこと全部満たしてるかとかそんな感じかな？
現場の顔伺いながら自己流でやってきてるから参考にならないかも(^_^;) V字型説明ここにもあった
https://webrage.jp/techblog/v_shaped_mode/
いろんなサイトでいろいろ仰々しいこといってるけどよくわかんないと思うんだよね
でも重要なのは
①ほんとにテストやったんかよ！っていわれるレベルのバグはのがさない
②詳細設計したとこは全部試す
③要求全部達成してるか試す
だと思ってる！ >>12
ありがとうございます。
今の現場は、というか新卒での初の案件ですが…
画面ごとに単体テスト仕様書を書いてテストしてます。
おっしゃる通り画面スクショとDB取得結果を証跡としてエクセルにペタペタ貼ってます。 >>16
元請け？2次受け？3次受け？
ちゃんと教育してもらえそう？ １つの画面を5日で作るのと20日で作るの、お金になるのは後者。だから書類は多ければ多いほどいい。
SIERなら常識。
テストで大事なのはステップ数と件数だから、全部同じ人がやらないと調整しにくいだろ？
バグが多ければテスト項目から削ったり設計書を直したり、少なければバグが出るテスト項目増やしたりして対応できる。 >>17
二次受けっていうんでしょうか。
大きいSIさんが取ってきたお仕事を貰って客先に常駐してます。
教育は(´･ω･`)正直期待できないです…
ピリピリした現場に放り込まれて恐る恐る質問して、
恐る恐るプログラム、テスト。
そんな毎日です。 現場はまじで場所によりけりだからね～
もし先輩がついてないならすごい心細いね、どこの会社に雇われてるのかもわからなくなるしｗ >>18
それまじだから困る
え？それすぐ終わるくね？ってものでも一生懸命大量に資料作って遠回りな実装して毎日残業でやったほうがものすごい褒められてしまう世界 これ参考になるかも
https://geechs-magazine.com/tag/tech/20160114
正常値 異常値 境界値 限界値
あとはマトリクスを書いてパターンを見てみるとか
全部バカ正直にテストやると時間いくらあっても足りないけど
プログラムはどの会社もフレームワークってのがあるはずだからフレームワークの振る舞いを理解する。
そういうふうになってるんだって割り切って理解する
コントローラーとサービスとビューはどういうふうに繋がってるかな？とか
データベースはどういうふうに操作してるのかな？とかね！
あとは頭からお尻までの流れを知る！
ここから入ってきてここから出て行くんだとか
あとデバッグを使いこなすこと！
困ったらデバッグデバッグデバッグ！
デバッグのやり方がわからない場合は最優先で覚えてね、
無理やりありえない値を変数に入れたり処理の途中で各変数の値をみたり
SI系ならもちろんEclipse＋Javaだと思う
ショートカットを覚えてね
F3とALT+←とShift+Ctrl+R
あと呼び出し元を参照とかこの辺は基礎だから(*ﾟ▽ﾟ*)
ふう(o´Д`) >>23
ありがとうございます。
デシジョンテーブルの作り方も分からず、ほぼ総当たりのケースを作ってしまっています。
調べると色々省略できるようで勉強しないとなぁ。 >>25
デシジョンてこれか！
http://gihyo.jp/dev/serial/01/test_up/0005
むかしちょっとだけお世話になったけどこれがなんという手法なのか考えたこともなかった！
勉強になります、ありがとうございます！ http://kikakurui.com/x0/X0125-1986-01.html
規格にもあるから、かなりメジャーな存在。
名のあるSIerだと自動生成するツールがあったりする。 真面目な人はホントに>>18を頭の片隅に入れておいてくれ。
大事なのは誰かの時間と書類の行数。
自分じゃなくてもいいことを忘れないでくれ 保守か開発かにもよるんじゃない？
開発だと遅延に遅延を重ねてとにかく早くやれって空気のとこ多いけど 手動で画面ペタペタとって黙視確認とか何とかならんのかねぇ。。 画面パチパチとって名前つけて保存するくらいならいいけど単体テストから全てのエビデンスとDBの記録をエクセルに貼り付けさせて体裁整えさせるとこあるし。単純にエクセルに貼り付けるって行為が時間かかりすぎるし無駄。まあでもその為の時間くれるならいいんじゃない？ 作業が独立するので、テスト流す人と貼る人と確認する人が並列で動けるので動きが速い現場もある。
一概には何ともいえない。一人で直列にやればいつまでかかるかわからんことにもなる。 めちゃくちゃ上手に設計する人の下で開発できたらすごい楽しく仕事できるんじゃないかという期待を持ってしまう。 パイプラインで作業やるのに、設計情報全部出そろってから開発するわけないんだ。
今はこなれてない設計でも、見切り発車して開発しはじめるパイプライン上等なんだ。 他の人は詳細設計書ある部分プログラミングしてるけど俺の担当してるとこ詳細設計書ないんだけど(;´д｀) 詳細設計書ができる前に開発が始まる、開発がほぼ終わってから詳細設計書に作業がもどるってことが起こるってことは詳細設計書は開発には必要ないんじゃないかって思っちゃうよね。あくまでもそのあとの保守に必要なだけなんじゃないかとか マジレスすると規模がデカいプロジェクトだと詳細設計書は必須
あと、コードより図や一覧表の方が全体を理解しやすい
末端のエンジニアも全体が分からないと困る
詳細設計書を省く場合でもパラメータシートは必要 >>37
全体の概要がわかるような設計書なら、メンテに使うかも知れない。
1ステップごとの処理の内容をいちいち書いてるような設計書は時間のムダ。 >>1
逆だな。詳細設計がちゃんとできていればコーディングはあっと言う間に終わる。 基本設計書は客に納品することが多いからいるよね
詳細はなくていい
基本設計書で不足してる情報を補足する資料があればいい 請負でやる場合、要件定義や基本設計は完了していることが前提だけどな。
準委任契約で開発やってんのかね？ ハラスメントが繰り返し起きている。
焦点となるのは加害者本人で、彼らの下劣で攻撃的で、
場合によっては違法ですらある行為の温床となった企業や業界の体質ではない。
だが、行為が単体で起こることはない。 企業はこうした人間を雇って昇進させ、
その仕事により収益まで得ていたわけだが、原因は構造的なものだ。
加害者の地位が高くなればそれだけ、抑制もバランスも機能しなくなる。
新日鉄住金ソリューションズ代表取締役社長 謝敷宗敬
副社長執行役員 北村公一
専務執行役員 近藤一政
常務執行役員 大城卓
常務執行役員 森田宏之
上席執行役員 國本衛
上席執行役員 福島徹二
上席執行役員 梶原敏弘
上席執行役員 南悦郎
執行役員 吉田佳子
執行役員 玉置和彦
執行役員 吉田勝彦
執行役員 熊本吉弘
執行役員 小池公彦
執行役員 黒木益尚
執行役員 福田成昭
執行役員 北沢聖
執行役員 鶴田進
執行役員 川崎淳
執行役員 齋藤聡 一応書いとかないと貰ったソースで謎のフラグが行ったり来たりしてカオスになるぞw 詳細設計書があればフラグの状態読めるのかよ
馬鹿か 謎のフラグを使うのがNG
詳細設計書を作る暇があるなら
ソースレビューして叩きまくったほうが有意義 Documents can lie.
Source code never lies. >>55
上司「お前らレビューする余裕あるなら人を貰ってくで～」 コードいじくりまわしているプログラマが一番気持ち悪い。 開発の規模感次第じゃね？
俺んとこは2、3人で自社パッケージ製品開発だから全くドキュメントなし 「使用済み下着販売掲示板（画像付き）」で検索。
いい子、かわいい子、いっぱいいるよ。 うちのシステム、設計書で5GBあるんだが
俺一度も開いたことないファイル山ほどあると思う 日鉄ソリューションズ
エロ対決しましょう
／￣￣＼
/ ＼ ／ 丶
｜(● ●) |
(ﾞﾞ )～( ﾞﾞ)
|￣ ￣|
／| |＼
｜ 丶 ノ ｜
｜ ｜
＼＿＿人＿＿／ >>57
これはもう実現されてる。
詳細設計書を特殊な言語で書かなきゃいけないけどな。
COBOLとかの特殊な言語で… 設計書からコードを生成するような仕組みにすると、今度は設計書の書き方に制約がついてそのプログラミング言語の良さをつぶしてしまい、結局、コーディングした方がよくなる。 今やコードファーストがトレンドだろ
詳細設計ってコボラーかよw ドキュメントがいらないといってるのは末端だからじゃないの？
ウォーターフォールで工程間の入れ替え考えたらその発想はあり得ないよ 一人とか少人数でやるなら仕様書要らねぇ。
エンドユーザーがそばにいるならたぶんラフな図位で済ますと思う。
めんどいのはアレだよ、中堅とか大手。
請負前提、裁判沙汰も覚悟の奴。
アレの時は「裁判資料」としてのドキュメントの重要性が爆上がりになる。
正直そんなんどうでもええでっしゃろって思うけどな……どうせ仕様は変わるんで。
まぁDoxygen覚えておくと楽できるスクリプト作れるかも知らん。 ごめん、足りてないものがあった、Graphviz。
あとはGnu Globalが時々役に立つ事がある（バークレーDBの知識は必要だが）。 >>73
そういうのは小さいシステムだろ。大きなシステムでもプロトタイピング、スパイラルモデルを採用しないのは謎だが、あとから優秀な技術者が来ると思っているプロジェクトが多すぎる。 設計書の記述レベルを揃えろと上司に言われたが、それをやると簡単な機能は設計書なんて見なくても作れるし、難しい機能は設計書読んでも作れないんだけどw
そんなわけで無駄な設計書をひたすら時間をかけて作ってる。プログラマあとは任せた。 だいたいまともに設計書が書けるならコーディングはかなりのものがただの作業となる。
設計書がどうのこうのという話は、そもそも設計書が書けない、言葉で説明できない人の話。
言葉で説明できない人間だからプログラムも必ずわかりにくい。 仕様書書けないPGや設計書読めないSE、定義書内の用語が分かってない上席で承認レビューとかするのは不毛だと思うけど、基本いまのSIerの組織編成では一式必要では？(見積上乗せとか懇意なBPへの仕事確保とかは置いとくとしても..)
実際フワッと人事異動でアサインされたりする様な業界事情が何とかならないと(←土方界の宿命)都度細かい仕様を問い合わせまくられる事になるわけで。
PG主体で関係者も全員実用的なコード読み書き出来る部隊で編成すれば削れるかも知れないけど、オンプレな構築が全滅してAWSの環境設定もAIでフルオート構築なんて美味しい話は(SIer界には)やって来ない >>78
文字切れすまそ
つまりH/Wの設定シートやらが必要無くなる位まで技術進歩してくれれば、そっち側の細かい設計書ドキュメントは実用上不要。 >>79
話が理路整然としてない。あんたはダメだ。 読む気が起きない文章ってあるよね
読もうと努力しても全然頭に入ってこない 自分だけ、そのときの自分にしかわからないプログラムを書くやつが多いから、詳細設計書はなおさら必要なんだよな。
設計書を書かせるとおかしな設計であることが一目瞭然となる。 ソースコード読めない奴はソフトウェア開発者として実力不足 >>85
たいていの人のは読める
だけど、たまに
マジで意味わからんソース書くヤツがいる >>86
かなり経験ある奴でコメントがないとか文句言ってる奴はいた。 >>84
わからないやつだな。可読性の高いプログラムが書けるなら、設計書も簡単に作れる。
ドキュメンテーションが苦手でコーディングは得意という人間がまともなプログラムを書くわけがない。 >>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やライブラリ）を記載⇒結合テストで評価 の位置付けかなぁ 
