曖昧な基準で書かれた、いろいろな名前で呼ばれてて
「これってどうなの？」「意味あるの？」といった物に出くわす事も少なくない
しかし、純粋にプログラミングだけをして食べていくことは、昨今じゃ難しく
避けて通れない、否が応でも作る機会に出くわしてしまう、そんなドキュメントたち
設計書や仕様書についても、マ視点で語ろうぜ
・自分のなかでの仕様書/設計書の呼び方と分け方
・成功談、失敗談
・仕様書/設計書は何を使って作成する？(Word/Excel/HTML/手書き！)
・仕様書/設計書に含める図の作成方法や使っているツール紹介
・炎上プロジェクトでみた(よくない意味で)素晴らしい仕様書/設計書
・そもそも仕様書/設計書って本当に必要なの？
・こんな仕様書/設計書は、ぶっちゃけアリ？ナシ？
などなど、設計書にまつわる話題を募集
【その２】Excelで仕様書を作る会社の奴の数→
http://hibari.2ch.net/test/read.cgi/prog/1177362668/
DBAがテーブルの仕様の説明資料作らんのだが
http://hibari.2ch.net/test/read.cgi/prog/1318690907/
仕様書の書き方
http://hibari.2ch.net/test/read.cgi/prog/1191806449/
仕様書とか意味あるの？
http://hibari.2ch.net/test/read.cgi/prog/1267241758/
(´･ω･｀)仕様書ぶちす！
http://hibari.2ch.net/test/read.cgi/prog/1195826467/
設計書を作ってるせいで生産性落ちてないか？
http://hibari.2ch.net/test/read.cgi/prog/1169735232/
詳細設計をしても逆にコーディングしにくくなるだけ
http://hibari.2ch.net/test/read.cgi/prog/1280647235/
・俺の中の定義
外部設計==基本設計、内部設計==詳細設計
プログラム設計はソースコードで代用できるため不要
外部設計/基本設計
UIやエンドユーザーが意識するレベルでのI/O、やりたい事などを纏めた資料
理由があって意図的に制限する場合を除いて、実装方針の変更には影響のしないレベルの情報
内部設計/詳細設計
入出力の詳細や分岐条件、メッセージ、処理順序など並べた
フローチャートのような分岐やループなど、コーディング上で表現する方法が複数あるような
意味のない情報は「明記してはいけない」
プログラム設計
2重管理になるだけで無駄なので、ソースコードが全て
javadocやXMLドキュメントコメント、コード内のコメントなど、コードでは表現できない情報
クラス図などコードより抽出できる情報
外部設計/基本設計、内部設計/詳細設計
箇条書きの要件定義、またはループや分岐を書いたフローチャート
外部/基本設計が詳しい場合、内部/詳細は内容のコピペか焼き直し
内部/詳細の修正でも必ず外部/基本設計が修正される
プログラム設計
そんなの作ってる余裕なんてないです＞＜；
コピペが何割かを占めるコードだけが絶対でありそれコメント(そもそもない)含めて他は不要
---
正直マ暦はあんまり長くはないのだけれど、これって普通のことなのかな…？
もちろん方眼紙です。
図はオブジェクトたち。
たまーにWordもありますが、終盤はファイルがいくつか見事にぶち壊されてます。
レビュアーが意図してる「仕様書」が何かを察することが、うまくやるコツなのかなって
最近思うようになってきました。書きたくない、じゃ通らないですし…。
設計はなるべくコードとして書くべし。
コードから自動生成できるたぐいの情報は、
別にドキュメントにまとめる必要はない。
仕様書はソースコードにコメントとして書くべし。
またはテストとして書くべし。
Excel、他形式のドキュメントはたたき台としての意味はあるが、
最終的にはソースコードに全て記述するべし。
別の形式として見たければ、ソースコードから変換すべし。
以上終了
でも、設計から入れ実装は後だっていう微妙な風潮
しかも、つくる設計書の記述内容は、実装前に作るものとしてはイマイチな内容
結局設計書作るのって自己満足でしかないよね。
そして設計書があるのにまったく見ずにソース見ながら電話対応するようになる
誰もまともにレビューしてなくて結局実コードのテストで
設計段階の間違いがボロボロ発見されるような現場ばかり。
あとインターフェイス部分とエラー処理と
オンラインだと矛盾が多い
新しい設計書の技法出来ないかな？
UMLに拡充する形でいいけど
あと、各社マチマチな工程名称も統一して情報処理試験でキッチリ記述と読み取りを出して欲しい
納品の為にしか存在価値のないものがおおすぎる
例外をうまいこと表現できないから、なんか書いてて、ウアーってなる
他のとこだけコードよりの内容が要求されるのにｗｗ
でも他の人みると、そもそも例外なんてアウトオブ思考だったわ
確かに、設計まわりの明確な名称はあるとかなり嬉しいな
とにかく何もかもが曖昧すぎるんだよな
レビューしないだけマシだわ
設計書段階で馬鹿みたいレビュー繰り返してる内に
フローチャートを作ってた事あったし
挙げ句に設計書レビューに無駄に時間がかかった結果
実装はデスマーチになってるから本末転倒の極み
実装者がアイディアマンになってしまうのは良くない。
俺が実装して痛い目見た経験から。
詰めるべきは客先交えて決める外部仕様だろ
設計で内部ロジックなんか詰めてもしょうがねーよ
どっちであっても、出来る奴と出来ない奴の差が激しすぎるんだよな
なまじ形だけなら誰でも出来るもんだから、ひどい物でもなんとかなってしまうっていう
新人とかなら詳細設計書まで書いてやって渡すこともあるけど。
新人じゃないならそれこそ実装したコードレビューした方が早いだろ
諸悪の根源だって気がしてくるわ
諸悪の根源は別のところにあります
本質を見抜く目を養わないと一緒ドカタですよ？
ちなみに俺が超参考になったのは、某大手の社員用サイトにある雛形だった。
しかしそれを下請に見せない理由がよく分からん。
その形式で納品すればそこそこな品質になるはずだが、社外秘なんだよ
土方根性土方思想がはびこりすぎて個人でどうにかできる状況じゃねーよ(´･ω･｀)はあまじああ
モジュールを指して設計書という奴は居ないだろう
ソースに該当するのはなんだろうな
大工が建築物にコメント書くのが許されるんなら設計書にならなくもない
物置程度ならそれで充分なんじゃないかな、よくわからんけど
建材に印ついてたりはするよな
きっちりかっちりしすぎても、緩すぎても仕様書って成り立たないよな
降車は言うまでもなく、前者も全員が守れない無駄な仕組みになってることが多くて、破綻しやすい
いい仕様書の共通仕様でもできればいいのにな！！
墨つぼが大工のコメント
屋根裏に自分の名を刻んだ工具を態と忘れたそうだ。そんな些細な思いすら、お前達は消し去るのか？」
文章の語順や言い回しとか表現の仕方ばかり気にする人多いけど
正直馬鹿にしか見えないんだよな
共有鯖から過去の資料や既にＯＫ出てる仕様書を真似て作成しても
人によって作り方が違うからＮＧになるし
そもそも同じﾌﾞﾂ出して見る人によってＯＫ・ＮＧ別れる時点でおかしいが
本人たちは指摘して偉い気分にでもなってるのかね
「ここは太線で区切ろう」とか
「ここは①、②を使おう」とか
「ここは図を入れよう」とか
「ここは→・↓・←・↑を使おう」とか
「ここはカッコ使おう」とか
「待てよ！～が～の～を…うーむ」とか…
こんな指摘ばかり受けてる間に
５時間でコーディング終わるＰＧの仕様書に３日かかったし
完全に遅れが発生してこの指摘馬鹿と一緒に毎日２２時過ぎまで残業開始
結局終盤の方からはＰＧの仕様書は時間がないからと指摘馬鹿が作成
どれ程のもん作ってるのかとこっそり覗いたが１時間くらいあれば
作れるような普通の仕様書だった
要するにこいつの趣味の書き方というだけだった
指摘馬鹿は人に「こっちの方がいい」とか指摘する前に
本当にそれをする必要があるのかどうかを考えた方がいいわ
必要ないことに時間掛けてる奴多すぎ
うちの職場だと、能無しPLとか老害連中や口うるさいバカ女が
しょっちゅうどうでもいいことにばっか力注いでて、もうウンザリ
その決定を行わない無駄なボールの投げあいしてる時間で
解決してしまえる内容をぐだぐだやって、時間が浪費されてく
無駄に細かい仕様を早いうちから書こうとして要点はつめないまま、
後になって仕様変更のなみで外設あたりからいろいろ詰んでるし、頭痛いわ…
それを顧客側が要求してくることもあるからな。
プログラムは正しくても、仕様書の記述ミスを理由に検収拒否してきたり、
些細な記述漏れを引き合いに、仕様が明確でないシステムは稼働させられないとか言い出して、稼働延期&稼働まで強制的に立会い延長になったり。
それはお前のせいじゃ、ドアホ
初期処理と終了処理はソースコードレベルの細かいこと書いてるのに
肝心の主処理は「ファイル変換を行う」の一言だけ
コーダーのための詳細設計書なんて見たことないんで書き方もわかりません
納品物件としての仕様書は誤りが書いてないこと、体裁が整ってることが最重要。
それを見てコーディングができるかどうかはまったく評価対象外。
保守さえ考えなければ
実装を前提とした検討用の設計書になってるものを見たことがない
そして出来ない奴ほど体裁に死ぬほどこだわる
まったくこだわらない奴も出来ない奴だけど
あと文体とかかき方にルールを設けるくせに
Excel方眼紙を卒業できない馬鹿も多いよな
自由度が高いツールを強制して、自由に出来ないように無駄なルールをつくりあげ、
仕事を増やすのが得意技！みたいな
Excelで方眼紙で糞ルールたくさん作られるくらいなら、まだ糞Word使ったほうがマシだわ
納品物あるいは後々の保守を考えれば最低条件であると考える
問題は文書作成環境にある
Excel/Wordとも短いレポートを手軽に作成するのには最適なツール
ただし、これを数百ページにおよぶ技術系文書(仕様書/設計書/マニュアル等)に
利用する発想が、適材適所という言葉を知らぬ人が犯す基本的な間違い
> 実装を前提とした検討用の設計書
うちはこういうのばかりだ。
おかげで、他人が見たら「どうコーディングするべきなのか」はわかっても
「どういう意図でそうなってるのか」がまったくわからない状態になってる。
> わかってない奴がわかった気分になるための説明書
メンテナンスする立場で言うと、わかってる奴にしかわからない設計書なんか
残されても、まったく嬉しくないんだ。
どういう意図で、は要件定義から追えば分かるんじゃないの？
分からないと保守更改でる
むかし社内で議論したけど、誰でも開けて編集できて、となると他に候補が無いんだよね。
でも開く環境が変わるとテキストがズレて崩れるけど（爆笑
Word使うなら箇条書きの範疇で済ます。
凝りたいならPowerPoint＋PDFかInDesignでごゆっくりどうぞ。
ということにしてる。
「Wordは糞だが選択肢が他にないんだよな」ってのが前提にある奴です
Wordを推したいわけではないけど、Excel方眼紙で設計書作るくらいならWordのほうがいい
>>50
使いやすいとか最適だとは一切思わんけど、Wordはそういう文書作成に使う物じゃね
もちろんExcelはない。使い捨てのレポートみたいなフリーフォーマットで使い捨てるものなら方眼紙は便利だと思うけど
>>51
言葉足りずで申し訳ない
48で言ってるのは、あくまでも「設計書」に書く内容の話な
そういうわかってない人への説明や方針決めの経緯は、
もっと上流の要件定義だったり、補足資料として別に纏めるものだと思う
そういうのがかかれてないドキュメントに恵まれてるのは、いい環境だと思うけどな
>>53
Wordの基本機能ですら、世間一般に「凝ってる」レベルだって捕らえられちゃうことが一番の原因だと思うわｗ
ドキュメント関連でWordを使う利点は、文章を書く以外のことに気を使わなくてよくなる、ってところと
体裁だけを全体纏めて修正でき、印刷のことも考えなくて済む、ってところ。このあたりが表計算ソフトのExcelにはない
ただ、それぞれの機能が使い難いし、理解しづらい
なにより、そういう基本機能ですら理解出来ない、しようとしない奴が多すぎて、まともに使われることが少なく、
仮にちゃんと作られてるドキュメントでも、そういう理解能力がない馬鹿が一人チームに混じってるだけで
簡単に設定されてる体裁の破壊が出来てしまうから、使えないツールになりがちなのよね
>おかげで、他人が見たら「どうコーディングするべきなのか」はわかっても
>「どういう意図でそうなってるのか」がまったくわからない状態になってる。
うちではわかってないヤツ向けの仕様書書いてるけど、そのわかってないヤツが
意図とか書くと余計なこと書くなって言ってくる
なもんで「どういう意図でそうなってるのか」は偉い人から口頭で聞いてソースのコメントに書いておく
> メンテナンスする立場で言うと、わかってる奴にしかわからない設計書なんか
> 残されても、まったく嬉しくないんだ。
わかってないヤツの想定が違う
OSって何ですかレベルのヤツを指してる
>>51の組織ならそのプロジェクトに参画してなくてもコーダーなら理解でできる仕様書を書きやすい気がするが
そういう組織に属したことないからよくわからんけど
あ、あと、PowerPointとかinDesignで設計書はないわｗ
何のための設計書かがわからなくなる
それやるくらいならまだExcel方眼紙にオブジェクト張って済ませばいいと思う
そういや、ここじゃないどっかでみたけど、
Wikiを設計書に使うってのも結構面白い発想だなって思った
バックアップ含めて管理面での自動化できるし、差分や履歴も簡単に見れる
2拠点間での共有も楽で、一元管理もしやすい
図説みたいな自由度への制限とか、環境の構築が必要だとか、他に提出するときどうするの、とか
ドキュメントとレイアウトがどうしても混ざってしまうような欠点もいっぱいあるんだけど、
外に出ないものなら結構便利そうではある
> わかってないヤツの想定が違う
そうそうｗ
文章を読むことすら出来ないような人とか、特にそういうこといってくるｗ
箇条書き、図説、表あたりしか理解してもらえない。
そういうのは設計書じゃないだろって思うけど、その思いは言葉にしても届かない！
結局本当の設計書は各担当の頭の中で作成されちゃうのよね
自分も他に書ける場所がないする事はできるだけコメントに残したりしちゃう派だけど、
ソース弄る奴にも、先にあげたようなのが混ざったりする事もあるから
保守されないコメントが、現状の実装と異なる状態になるかもしれなくて、コメントに残しすぎるのも怖いんだよな
マに免許とかそういうのはないし、コーダーのレベルもピンキリ激しい
あとコメントじゃレビューとかもないから、誤記ったりしてもそのまま残る可能性が怖い…
設計書って言ったら図だろ。
お前車とか家とかの設計書見たことあるのか？
設計書って言ったら、ﾌﾂｰ「設計書がどうしたんや！何して欲しいんかちゃんと云いなはれ。そんなんで伝わると思うたらおお間違いや」
設計書是也設計書。
設計書見たことあったらどうなのか？ 無かったらどうなのか？ もったいぶってても大した話じゃないならとっとと話を進めなさい。
結局頭の中が下の連中に合わせないといけなくなる。
自然言語で表現できないかしづらい内容までドキュメント化しろなんては思ってないよ
シーケンス図とかクラス図で済むことならそっちでやるし
きっちりかっちり自然言語を使わず表現できる部分なら、それはもうコーディングしちゃえばいいんじゃね
>>62
まぁ結局そうなるんだよな
うん。だから設計書＝コードなんだってば。
日本語は、コメントとして書けばいい。
ISOなんとかのためなのかどうかは知らないけど、
プログラム設計書は求められる現場が多い。
それより上の工程のドキュメントは無くても。
上の工程のドキュメントはどんなにわけわからんこと書いてても
我々に文句言う権利ないしね
プログラム設計書は重要じゃないけど
プログラム設計は重要
この重要性が現場でも理解されてないからプログラマの地位は低い
的外れな指摘しかされてない、半端な設計書なんて用意しても、結局糞の役にも立たないなんてことになるしなぁ
ちゃんと修正されたか再レビューしないことも多いし
儀式的なものになり果てている
担当を複数人にしてお互いにチェックするという仕組みにしたらいいと思うんだが
それは単純に開発プロセスの問題な気がする。
プロセス監査とか無いの？
結局開発者自身が本当に改善したいと思ってるかどうかと、
さけるリソースがあるか、によるんだよなぁ。
実際真面目に取り組むとちょーメンドくてしんどい。
けど効果はある。
各々の文章チェック能力、設計力の問題だろ。
再レビューが無いのが問題だと感じてるなら、
再レビューしたかチェックする機構があるべきだし、
「指摘がその場の思い付き」「儀式的になってる」とか、
不具合流出の分析とそれによる対策がされて無いわけじゃん。
レビュー観点の整理とか、インスペクションの導入とか。
実際>>70自身言ってる「チェックの仕方」自体プロセスそのものだし。
低レベルでの開発プロセス定義なんて、最低以下の人間に
最低限の仕事させるためのもんだよ。
高生産性や高品質はその次の話。
プロセス重視することと、内容を軽視することは同義。
レベル低くて笑える。
それ素振りやっただけで上手くなった気分になって満足してる奴らの話だろ。
まぁ好きにしたらいいよ。
docomoの障害は起きなかっただろう
内部統制とかいい例。
人間がある以上トラブルは発生する。
だがプロセスがなければ
もっと多くのトラブルが発生する。
＞低レベルでの開発プロセス定義なんて、最低以下の人間に
＞最低限の仕事させるためのもんだよ。
こういうことなんだろう。
そもそも最低の人間を使わなければいいのに。
やらないからいけないんだろうな。
レベル高い人間を集めるられることを前提に計画建ててる時点で破綻してる。
ってのは可能なのか？
ソフトの世界は量ではなく質なので
その方法では一流になれません。
WindowsとかOracleとかのバグの多さを見れば明らかだろう。
低レベルの人間を大量に集めて
WindowsとかOracleを作れると思ってるなら
おめでたいな
本気で高レベルの人間が、少数精鋭で作ってると思ってるなら頭おめでたいですね。
その人達は全員がある程度高レベルの人間でないと作れない
特に優秀な人が必要なのはプログラマレベルだろう
例えば日本のゼネコンシステム会社にMFCとか.NETライブラリとか作れるか?
上流工程(藁)SEには作れないし、寄せ集めプログラマ作れるものではない
新しいバージョンではバクやセキュリティホールが治って価値が上がってる、だから新バージョンを買ってくれってね。
デビッドカトラーとかは伝説なの？
正社員か下請けか派遣かとかの所属のことを言ってるんじゃないよ
今のwindowsは糞仕様が多すぎる。
そいつが、そういう仕様になってる理由を理解できる頭がなく
分かってないだけのことも多い
単に自分の分担分の作業が増えて面倒だというだけの理由の場合もあるな
多人数大規模の開発ってのをなんか勘違いしてるでしょｗ
まず前提条件として、大規模っていうの数万、十数万人月という工数で
すごいプログラマが通常の10倍の生産性だったとしても
1000ヶ月、83年、そんなに時間かけられますかって話なんだよ。
WindowsとかOracleとかそんなのは難しいだけで工数はそんなに必要ない。
簡単だけど工数は大きいという仕事のほうが世の中には多いんだよ。
OSやDBMSなんて殆どの人は使うだけで作ったりしないでしょ？
そしてOSやDBMSを使うだけの仕事に、OSやDBMSを開発できる人間を
担当させるのは、どう考えても仕事の振り方間違ってるよね？
そして仕事である以上、納期とコストの事を考えないといけない。
工数から考えて、少数のすごいプログラマだけで作れる期間は与えられない。
なら、すごくないプログラマを投入するしかない。これは絶対条件。
じゃあどうするか。ここまで考えてものを言ってる？
TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲
プログラマのオナペット*３* (107)
ちらしの裏 (144)
【経歴詐称】悪徳業者 Part1 (128)
【Cocoa】Macプログラマのスレ【Objective-C】 (216)
(´ー`)男の子と女の子が仲良く会話するスレ('-'*) (224)
フロッピーってなんですか？ (576)
--log9.info------------------
【結成20周年】 BALZAC バルザック (153)
BAD RELIGION/バッド・レリジョン part12 (355)
【名古屋】ＰＡＮＫＳ＆ROKER’S【黄金時代】 (470)
JOE ALCOHOL/ジョーアルコール★STILL ALIVE (160)
名古屋パンク＆スキンズ (170)
激情バンドpart4 (650)
ｱﾅｰｷｰは2ちゃんでなんで過小評価されてるんだ!?!? (910)
でぶコーネリアスはほんとにパンク (370)
【速】STRUNG OUT part4【重】 (592)
The Ataris vol.4 chord wonder (139)
【一言】+++++GAUZE+++++【物申す】２ (768)
ブルーハーツはたいしたことないよね (686)
ｵﾏｴのパンクバンド四天王は？ (396)
それいけラエリアン・ムーヴメント (205)
ハードコアパンクス女の子のSEX事情 (794)
BBQ CHICKENS (101)
--log55.com------------------
オフ板イケメンランキング
【名無し】あの人にもう一度会いたいVol.3【限定】
【出会い厨】バイクの後ろに乗っけてくれ56【R】
【名古屋】雑談して気が向いたらオフ★134
【新潟】いまどこいまひまOFF 100発目【越後】
【福岡】今暇突発オフスレッドPart197
【藤沢・鎌倉】湘南いまひま２４【茅ヶ崎・平塚】
【広島東部】福山備後地方でオフ１２【尾三もドゾ】